On 10/19/2011 05:43 PM, David M. Lloyd wrote:
> b) The Context.PROVIDER_URL used in the jndi.properties or
the
> > properties being passed to the InitialContext apply to the entire
> > context and aren't anything specific to EJB invocations. i.e. the user
> > could use that context to do lookup/invocations on non-EJB objects bound
> > to JNDI. I'm not sure how non-EJB JNDI lookup outside of the server VM
> > is being implemented/planned, so using that EJB specific(?) remoting
> > connector info (remote://<localhost:ejb-remote-connector-port>) in the
> > jndi.properties isn't probably a good idea.
Yeah, that's also a good point. There are many other JNDI schemes out
in the wild and we should stop assuming we're the only ones.
I don't see
how a property specified as org.jboss.ejb.client.<something>
interferes with anything but our own stuff. The ObjectFactory can just
pick that up from the environment.
As for other JNDI name, they can be simple LinkRefs into the ejb: context.
We could even bind an ObjectFactory that simulates EAP 5 bindings. That
would make migration a bit easier.
I showcased all these possibilities in the PoC.
I like the standalone global EJBClientContext. Forget about lifecycle in
standalone, it's just not there.
Carlo