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) ?

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.

The http transport dependency and its dependency on an http stack needs to be moved into a separate artifact as I outlined in JBREM-705. Whatever its compatible with should be declared in that artifact.

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.

Messaging needs remoting HTTP support and it really doesn't care what version of Apache (or Jetty, or whatever) remoting uses. How would I know what jboss-remoting-http.jar version matches jboss-remoting.jar I am using?

Let's say that Messaging takes a wild guess and arbitrarily decides that it should use Tomcat 5.5.15. That would create a conflict with JBossWeb 2.2.0.

If Messaging instead declares it wants to a Tomcat version that makes JBossWeb happy, we end using Remoting with an untested tomcat version.

How would our dependency map look like if you go for piecemeal jboss-remoting.jar/jboss-remoting-http.jar?

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.

If remoting breaks out http, then jbm has to as well. You cannot have a cross product of dependencies on the same type of component (http stack in this case) in an artifact as its just going to pull in conflicting dependencies for no reason. Its the consumer remoting and jbm that are going to define which remoting and jbm artifact correspond to the http stack. Start breaking project up along the lines of their dependencies so that they can be properly consumed.

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. As its something jbm does not control, it should be a dependency that is isolated in a separate artifact so that the correct stack can be included. The correct stack being whatever is aggregating jbm and http stacks.

For jboss5 that is probably all that is needed. If remoting has to create remotting-http-jbossweb, remoting-http-tomcat5, remoting-http-jetty6, ... then the jbm piece that depends on the http stack needs to be separable so that the required http stack is selected.