[jboss-dev] Releasing JBoss 4 with the latest versions of AOP, Remoting, Serialization, etc.

Ovidiu Feodorov ovidiu at jboss.org
Fri Oct 20 18:31:53 EDT 2006


Scott M Stark wrote:
> 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
Correct. I will add JIRA issues to that effect.

> . 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.
>
> 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
>





More information about the jboss-development mailing list