afaik nightly build is the alpha version (7.1.0.Alpha)...and... i'm used that alphas have every but maybe broken feature...
Any nightly build which has support for remote EJB invocation ? Any thoughts on how the older remote EJB clients (which used the JBoss specific JNDI mappings for lookup) will work with JBoss AS 7 (which has moved to the EE 6.0 standard JNDI mappings) ?
Remote clients can use any mapping they want. The setup is done via configuration.
Here is a preview that uses jnpserver as JNDI storage and configuration is done using JNDI API: StatelessTestCase.java
The final solution will look a bit different, so don't read too much into the beforeClass method.
Will any changes be required in the remote EJB clients (which worked with AS 4.2.3) to make them work with AS 7.0 ?
I am quite positive this will indeed require updating the clients. You are skipping by three major version of AS! :-)
It'll require installing updates on your clients, because we use new client jars and configuration files.
But I'm pretty confident that the code itself doesn't need any changes, at most a recompile.
I see that there is a JBoss version compatibility matrix at the link http://community.jboss.org/wiki/JBossVersionCompatibilityMatrix. Is such backward compatibility not supported in later versions (beyond 4.2.x) of JBoss ? Or is it documented somewhere else ? We have remote EJB clients (not sitting on the same machine as the server) using 4.2.3 Jboss client jars deployed which currently communicate with a 4.2.3 JBoss server. Now we want to upgrade the server to AS 7.x but want the clients to work without doing any changes (i.e. no upgrades at the clients). Is this possible at all ?
Dattaram Porob wrote:
We have remote EJB clients (not sitting on the same machine as the server) using 4.2.3 Jboss client jars deployed which currently communicate with a 4.2.3 JBoss server. Now we want to upgrade the server to AS 7.x but want the clients to work without doing any changes (i.e. no upgrades at the clients). Is this possible at all ?
That's not going to be possible for a number of reasons (actually given the way we are developing our new EJB remote client API, it might be possible to make it work by adding some jars on the client side, but it all depends on how we go about with the JNDI lookups).
The reasons why it might not be straightforward or feasible actually depends on how the client interacted with the server in those previous versions. Typically you would use the JBoss specific JNDI names for EJBs to do a lookup from the client side and invoke on that proxy. In AS7, we no longer have JBoss specific JNDI names for EJBs and we just bind to the EJB3.1 spec mandated JNDI names (which weren't there in 4.2.x days). Effectively, this means that you have to change your client code to (at the very least) change the JNDI names being looked up. There are some other changes that will be required too (like adding the new EJB remote API jar and its dependencies to the client classpath).
Oh, that will make it very difficult for us to take the decision to upgrade to AS 7.x. This would be true for AS 6.x also, right ? In 6.x, I believe the old JNDI mapings are retained so that should not be a problem, but the new EJB remote API jar would still have to be added in the client classpath right? Is there absolutley no way to make this possible in at least a AS 6.x (where the old JNDI mappings should work) ?
Dattaram Porob wrote:
This would be true for AS 6.x also, right ? In 6.x, I believe the old JNDI mapings are retained so that should not be a problem, but the new EJB remote API jar would still have to be added in the client classpath right?
The EJB remote API jar is available starting AS7. If you are using AS6, you would still need the AS6 specific client jars on the client side. We haven't supported EJB invocations from a different version of AS against AS5 or AS6 server.
We are planning to go with JBoss AS 6.1.0 as of now. So we will be upgrading from AS 4.2.3 to 6.1.0. Now, we need to have this backward compatibility working i.e. need remote EJB clients using AS 4.2.3 client jars to be able to communicate with AS 6.1.0. I believe what you saying in the above mail is that this impossible unless we change the jars at the client and this is not a feasible solution for us.
So as a workaround, what I tried to do is run a slim version (with only the ejb3 deployer) of Jboss AS 4.2.3 on the same machine as 6.1.0 but using a different JNDI port. Use the 4.2.3 as a proxy for the lookup i.e deploy the same EJBs in both the server instances but the EJBs deployed in 4.2.3 will not contain any business logic but will just remote lookup and invoke the same EJB on the 6.1.0 instance. I packaged the required 6.1.0 client jars in my EAR packaged in 4.2.3 and set the EAR isolation to true so that these classes do not clash with the 6.1.0 classes. This seems to be working fine for me i.e. I was able to lookup and execute EJB methods in my remote client using AS 4.2.3 client jars since that client is pointing to the AS 4.2.3 instance. Any comments on this approach ?
Now, even though this is a working model, I do not think it will be feasible to deploy another JBoss container on my server just for this proxying; considering maintenance/resource constraints etc. Will it be feasible to somehow do such proxying within the AS 6.1.0 instance itself ?
I was trying to debug on why this old client is not able to lookup AS 6.1.0 instance and I found that the object which is bound in JNDI itself has been changed from 4.2.3 to 6.1.0. In 4.2.3 a proxy object was bound by the ProxyDeployer but 6.1.0 seems to be binding a Reference object and hence the ClassCastException (javax.naming.Reference cannot be cast to ...) when trying to do a lookup from a 4.2.3 client.
Could I, may be, do some modifications in the AS 6.1.0 code to deploy AS 4.2.3 type proxy objects instead of References ? Any pointers in this direction would help.
Or, may be, we could somehow use 2 types of EJB3 deployers in AS 6.1.0 one each for old and new clients. Is that possible and if yes, how could this be achieved ?
Thanks for the pointer, Wolf.
May be I am missing something, but I think this blog is providing a way to do a ejb lookup between JBoss server instances of different versions. So it would help me in doing a EJB lookup from AS 4.2.3 to AS 6.1.0. But I already have that working just by using EAR isolation as mentioned in my previous post. I could also try the method given in this blog; but my main issue right now is that I want to solve this backward compatibility problem using a single JBoss AS 6.1.0 instance.
Any suggestions on how that can be achieved ?
Dattaram Porob wrote:
May be I am missing something, but I think this blog is providing a way to do a ejb lookup between JBoss server instances of different versions. So it would help me in doing a EJB lookup from AS 4.2.3 to AS 6.1.0. But I already have that working just by using EAR isolation as mentioned in my previous post.
I'm confused on what you are saying above, because your previous post said:
Now, we need to have this backward compatibility working i.e. need remote EJB clients using AS 4.2.3 client jars to be able to communicate with AS 6.1.0.
What you mean is forwards compatibility.
Without some severe modifications I don't think that's possible with AS 6. Somehow it would need to run an isolated environment capable of receiving AS 4 calls and translating plus forwarding them into the AS 6 environment.
With AS 7 at least we can setup the isolated environment, with a combination of Alunite and Modules we could then call the AS 7 environment.