With the exception of serialization, only users of these classes are jbossws, messaging and ejb3. Serialization is now part of the core transport, so its version has to remain backward compatible with the existing releases. The aop and remoting versions need to be coordinated between jbossws, messaging and ejb3 releases. The theory of backward compatible releases is irrelevant. Either compatibility is demonstrated from the client api ala the compatibility testsuite, or they can't go into the 4.0.x branch

. The existing messaging compatibility tests would need to be updated to ensure there are no jbossmq dependencies as well as expanded to pickup any leakage of these dependencies on the client side.

Ovidiu Feodorov wrote: > I am summarizing a discussion that has been taking place in private for > a while: > > Messaging relies on the latest versions of AOP, Remoting and > Serialization. In oder to make it work in JBoss 4, we need to scope the > broker. This is a pain for users: they also need to deploy scoped MDB > containers, destination and connection factory MBeans, recovery > managers, etc. and from our experience so far, is the fist source of > user trouble, as reflected on our user forum. We tried to compensate by > writing installation scripts, and detailed documentation explaining the > reasons behind this situation and procedures to deal with it, but that > doesn't alleviate too much the fact that the whole thing is a pain. > > All this could be avoided if we start shipping JBoss 4 with the latest > releases of Messaging's dependencies (AOP, Remoting and Serialization). > If Messaging finds the right versions of the dependency classes it needs > in the top-level class repository, the need for scoping disappears. > > Releases (at least theoretically) are supposed to be backward > compatible, so, in theory it should be possible to ship with the latest > versions. > > From discussion with Dimitris , Thomas and Tom Elrod we identified one > compatibility problem in Web Services. I am reproducing the discussion > below: > > Thomas Diesler wrote: >> I believe the underlying problem is that remoting is not backwards >> compatible. >> >> #1 If jbossas-4.0.5 uses the new remoting, jbossws-1.0.3 will break >> #2 If jbossws-1.0.4 switches to the remoting, it won't be usable >> until jbossas-4.0.6 >> >> I suggest TElrod provides backwards compatibility for the new >> remoting. The old API can >> be deprecated but should still work. If that can be done jbossas can >> switch at any time. > > > Tom Elrod wrote: >> Integration work for migrating these projects to remoting 2.0.0 >> release has already been started and can be reviewed at >> http://jira.jboss.com/jira/browse/JBREM-565 (along with the >> corresponding jira issues). >> >> Another one of the big changes between 2.0.0 and previous releases >> is introduction of wire versioning which makes it so that it can not >> communicate with the previous versions out of the box. However, >> there is a configuration setting that can be used to make it so it >> can communicate with previous version and can find more info on that >> at http://labs.jboss.com/portal/jbossremoting/docs/guide/ch12.html. > This looks to me like a issue that can be worked out relatively easily. > > Aside from that, I was wondering if there are other practical > consideration that would prevent us to release JBoss 4 with the latest > versions of AOP, Remoting and Serialization? > > Thanks > Ovidiu > _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development

No. I'm saying the backward compatibility tests need to be covering any new client side dependencies jboss messaging is bringing in (aop, remoting). Ovidiu Feodorov wrote: > >> . The existing messaging compatibility tests would need to be >> updated to ensure there are no jbossmq dependencies as well as >> expanded to pickup any leakage of these dependencies on the client >> side. > > This is a completely different issue, isn't it? JBossMQ has nothing > to do with these dependencies. This last issue you raised is the > subject of http://jira.jboss.org/jira/browse/JBMESSAGING-553 Richard > is working on it, he's very close to getting it done. _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development