Ok. I'm personally fine with not having the dependency listed within the component-info.xml at all (but guess can see why would be good to declare it).

Problem for me is testing all the different versions. Remoting would probably work with most anything in the 5 series, but getting all the versions and testing each of them is a huge time drain. Especially if include apr as well.

Our jboss messaging test run now fails to run, since the build no long pulls in apache-tomcat because (needed for our tests that involve the remoting http transport) it is not listed in the remoting dependencies.

I have added an explicit dependency to apache-tomcat in our project, but I have no idea what version to use now, since it is not listed as an explicit remoting depency.

How can I find out which version I should use? (I have guessed 5.5.20 for now)

Surely I should only be using the version that remoting is tested against which should be that listed in the remoting dependencies (and is not anymore) ?

Ok, I can see it is 5.15 by looking at the commented out section in component-info.xml.

What is the long term solution for this? I don't think us manually enforcing dependencies by looking at commented out sections in other projects' component-info.xml is a good way to go...

apache-tomcat is a dependency of Remoting. Remoting can't do HTTP unless those jars are present. Messaging, as a Remoting dependent, shouldn't be in the position to decide what apache-tomcat version Remoting uses. From our perspective, we don't care, and we don't want to be forced to care.

All we care about is that our tests pass with the specific Remoting version listed in our dependency metadata.

So, having to list apache-tomcat among our dependencies is wrong.

If Remoting declares itself compatible on apache-tomcat 5.5.15, and this breaks compatibility with jbossweb 2.0.0, then jbossweb and Remoting teams need to work this out and qualify a apache-tomcat that is acceptable for both parties.

Also, they need to do this in such a way that doesn't require uncomment stuff in configuration-info.xml and leave Tim and I wondering for hours why is that our testsuite fails.

Looks like only solution so that JBossAS does not have conflict (where remoting specifies dependency on apache-tomcat) is to remove import of apache-tomcat from the remoting component-info.xml (as well as declaration of jboss-remoting-http.jar as an artifact). Then create a new jboss/remoting-http within the repository that declares jboss-remoting-http.jar as artifact and export with apache-tomcat as import.

Doing this would mean that messaging would then need to either pick out all the componentized remoting artifacts they need (i.e. jboss-remoting-core.jar, jboss-remoting-http.jar, etc.) or just get jboss-remoting.jar and jboss-remoting-http.jar.

"tom.elrod@jboss.com" wrote:
Doing this would mean that messaging would then need to either pick out all the componentized remoting artifacts they need (i.e. jboss-remoting-core.jar, jboss-remoting-http.jar, etc.) or just get jboss-remoting.jar and jboss-remoting-http.jar.

If went piecemeal, would need to reference http://labs.jboss.com/portal/jbossremoting/docs/guide/ch04.html for the components.

As for the tomcat libs, should only be a problem if web container is using the same classloader as jbossas (which at least used to not be the default). If web container is using same classloader, then is certainly a problem (and a known one for a while - http://jira.jboss.com/jira/browse/JBAS-2766). I don't know how to solve this other than making sure remoting is tested with all the different tomcat releases and hope that there are no changes to the tomcat api between its releases that would cause remoting to not be compatible with all the versions.

On top of all this is JBossWeb which seems to not be using apache-tomcat libs at all. Don't know what their API looks like, but if is different from tomcat connector api, will need to re-write a remoting http server for it.

I don't understand.

What dependency do I need to break out? I don't touch HTTP code, I don't care about HTTP code.

My only dependency is Remoting and I only have a piece of configuration that says "bisocket" or "http". Remoting can implement HTTP using smoke signals, for what I care.

IF we start to get into this, maybe it's time to ditch remoting and start thinking about our own transport.

"scott.stark@jboss.org" wrote:
If you don't care about http, then why did you say "Messaging needs remoting HTTP support...". That dependency links to an http stack regardless of what it is.

Beautiful.

We're looking forward to remoting-http-jbossweb, remoting-http-tomcat5, etc.

Maybe this will also solve our HTTP stress test failures? :)