Description of problem: From the last update of document "Backward compatibility between EAP releases" [1] by Andrig Miller we should support backward compatibility of JMS clients communicating with HornetQ provider across EAP releases. Backward compatibility for JMS clients means that old JMS clients with EAP 5 client libraries will be able to communicate to EAP 6 server. There is new implementation of JNDI in EAP 6 which is incompatible with JNDI in EAP 5. This breaks backward compatibility of JMS clients because they need to look up connection factories and queues/topics in JNDI. [1] https://docspace.corp.redhat.com/docs/DOC-111225 Additional info: JMS client with JNDI in EAP 5 uses following EAP 5 client libraries: hornetq-core-client.jar hornetq-jms-client.jar jnp-client.jar jboss-javaee.jar netty.jar and should without modification communicate to EAP 6 server. Testing showed that old EAP 5 HornetQ client libraries are compatible and can communicate to newer HornetQ server/component in EAP 6. Problematic components are remoting and JNDI.
Changing component and removing target release. Should be set by pm.
Reassigning to David as remoting3 is in EAP 6.
We have no plans now or in the future to create an EAP 5-compatible Remoting or JNDI layer.
Hi Andy, it seems that there are no plans to create an EAP 5-compatible Remoting or JNDI layer. Could you review the document for "Backward compatibility between EAP releases" [1] if it's really necessary. (see comment above from David) We would like to have your feedback if it's blocker or we're fine with current status. Thanks, Mirek [1] https://docspace.corp.redhat.com/docs/DOC-111225
Not sure if it's the right workflow but I'm '-' the blocker flag. This issue may be important but it's unrealistic to hold the 6.1.0 release since we don't have either the time and resources and clear technical idea how exactly will be solved. It has to go either in the planning for 6.2 or be a change request for 6.1 after is released, although in both case it will be developed upstream and ported back, with the know caveat of resourcing/priorities, etc.
Also changing the type to 'Enhancement'.
In order for this RFE to be met, NO changes on the client side is allowed.
There is work on this thanks to Emmanuel Hugonnet and Carlo de Wolf. More info can be found in [1][2]. At this moment this is still under development. [1] https://mojo.redhat.com/docs/DOC-928901 [2] https://mojo.redhat.com/docs/DOC-929745