Please try and run a simple tutorial example. The ant script adds a directory that has a jndi.properties file in it. This directory is made a part of the classpath when the client is run.
Also, please make sure that you're using JBoss 4.0.1RC1 as RC2 seems to have broken EJB 3.
Dumb question - it's in the remoting-service.xml.
I guess if multiple transports are defined, it just grabs one?
Sorry for the post
SOAP isn't supported yet. Remoting is in transition and so far, we've only tested EJB 3.0 with the socket connector that comes packaged with EJB 3.0 in ejb3.deployer/meta-inf/jboss-service.xml
Check out JBoss Remoting docs:
Also read this EJB3 doc here:
Sorry to point you to documentation, but I need to know if the docs are sufficient to answer your questions.
Thanks for the docs - I'm currently swamped but they looks as though they're just what we need. I'll post as soon as I've tried it - we've got one customer that has a bit of a Heath-Robinson transport and so we've build ontop of the remoting sockets ... can't wait to try it out!
Incidently, the BLOB issue for EJB3s is becoming a real show stopper ... as we begin to discover how much binary is embedded in our and our customers code.
Many thanks for your comments.
Will post as soon as possible
On the blob issue...It has been discussed on the EG and should be added in the next release of the spec.
As in the next release of the current 3.0 or next release as in 3.1?
Finally made it back to this. Just spent the last 3 days trying to get up to speed with the whole framework. I've worked out how to do my unique remoting transport. However, I still haven't managed to work out how to do the following ... I'm trying to drive an ejb3 via remoting, and there is no way of doing an 'InitialContext' to get the remote proxy due to the nature of the transport.
AmI right in suggesting that org.jboss.aspects.remoting.Remoting.createRemoteProxy is the way forward on this? ... ie
org.jboss.tutorial.entity.bean.ShoppingCart sc = (org.jboss.tutorial.entity.bean.ShoppingCart)
Remoting.createRemoteProxy(new UID(), org.jboss.tutorial.entity.bean.ShoppingCart.class, new InvokerLocator(myUniqueTransportURI));
I haven't been able to track down another way of doing this.
Any input very gratefully received
Do you mean on the client side?
Sorry, I must sound like a complete goon.
I think I understand what you mean re. @RemoteBinding - this is part of the ejb3 bean and I can modify the jndi binding. How do I get a client proxy if I am unable to create an initial context? .... my transport is being routed all over the place and there is no way of getting the remote proxy using InitialContext. - I suspect I'm missing something blindingly obvious.
The @RemoteBinding will bind an EJB proxy into jndi under a specific JNDI name. Then you can use JNDI to get a reference to that proxy so that you can communicate to it.
So, if I understand you, all I have to do is (for example)
Modify org.jboss.tutorial.entity.bean.ShoppingCart to include ..
public class ShoppingCartBean implements ShoppingCart
Modify the transport.Connector in ejb3.deployer jboss.service.xml to reflect the new transport
Finally, do a simple new InitialContext (without any properties relating to a hostname/port server) and do a lookup on the default, bound, fully qualified name of the remote interface.
... if this all that needs to be done, then this really is a work of true genius.
Just got to point with my test harness where I've written all of the remoting transport and set up all of the server instances.
When I tried to add a client url resolver and add this to the bean, I get an 'attribute value must be constant'.
So it seems that I will have to recompile the bean locally each time I want to run the client.
Bill, anybody, is there any way I can get around this? Perhaps I can alter the local jndi server with the appropriate clientUrl directly before doing a lookup?
You are running into a limitation of JDK 5. eventually, there will be XML overrides.
The system we have done all of the ejb3/transport work for is real-time, in the sense that servers come and go - thus XLM overrides is still a no-go for us.
Am I right in thinking that the only way forward for me is to go through all of your ejb3/aspecs/aop code and the jnp code to try and work out a solution for this?