7 Replies Latest reply on Dec 13, 2006 6:21 AM by wolfc

ClientContainer enc handling

starksm64 Dec 10, 2006 11:53 PM

The ejb3 ClientContainer is expecting to find an env entry under the applicationClientName name on the server:

 public ClientContainer(ApplicationClientDD xml, Class<?> mainClass, String applicationClientName) throws Exception
 {
 this.xml = xml;
 this.mainClass = mainClass;
 this.applicationClientName = applicationClientName;

 //Context ctx = getInitialContext();
 Context ctx = new InitialContext();
 enc = (Context) ctx.lookup(applicationClientName);
 NamingEnumeration<NameClassPair> e = enc.list("");
 while(e.hasMore())
 {
 NameClassPair ncp = e.next();
 log.debug(" " + ncp);
 }
 encEnv = (Context) enc.lookup("env");

However, how the client enc is expected to function is that the lookup of "java:comp/env" maps to the server side context bound under the applicationClientName. There is no server side env under the client. The deployment was a j2ee 1.4 deployment. We need to merge the client deployer logic and client container. What refactoring were you going to be doing on the ejb3 client?

1. Re: ClientContainer enc handling

wolfc Dec 11, 2006 5:05 AM (in response to starksm64)

In EJB3 the lookup of java:comp/env should be used. I don't recall why I didn't do this in the first place.

I'm going to refactor injection. Now xml descriptors are interwoven into the framework, I want that out. Second thing is to make the separation between setup and injection more clearly.

On the client side this means that it will only use the injection phase with metadata provided via JNDI.
Actions
2. Re: ClientContainer enc handling

starksm64 Dec 11, 2006 11:54 AM (in response to starksm64)

What I'm wondering is whether we can collapse the ee5-1.2 client containers into the same one where injection is simply a noop for the legacy container.
Actions
3. Re: ClientContainer enc handling

wolfc Dec 11, 2006 2:26 PM (in response to starksm64)

I think if you send a deployment descriptor to the EJB3 client container with metadata complete 'true' you're probably (almost) there.
Actions
4. Re: ClientContainer enc handling

starksm64 Dec 11, 2006 2:33 PM (in response to starksm64)

Ok, then let's work toward replacing the old ClientDeployer with such a mechanism.
Actions
5. Re: ClientContainer enc handling

wolfc Dec 13, 2006 3:43 AM (in response to starksm64)

What if we bind a collection of injectors (org.jboss.injection.Injector) under java:comp/jboss/injectors?

Then you get something like this:
1. parse XML for injectors
2. if(!metadata complete) parse annotations for injectors
3. bind in JNDI
-- server is done
4. client (/ EJBContainer serverside) looks up injectors and fires them

All injectors should be JndiPropertyInjector with a mapped name somewhere in JNDI space.

During steps 1 & 2 parsing for env entries can also be done, but these should be treated separately.

This would simplify injection a lot, but would need a bit more functionality on the setup-env phase. It would also mean that the client uses only JavaEE API's and a simple injection framework, thus it can become a separate project / module.
Actions
6. Re: ClientContainer enc handling

starksm64 Dec 13, 2006 4:49 AM (in response to starksm64)

Sounds good. Currently doesn't the ejb3 processing build the jndi env during the injection phase?

We would essentially need to take the existing j2ee1.4 client deployer jndi behavior and then add the javaee5 injectors for use by the client container?
Actions
7. Re: ClientContainer enc handling

wolfc Dec 13, 2006 6:21 AM (in response to starksm64)

Yup, except that the server environment should start at java:comp and not java:comp/env like now in the EJB3 client container. Then we can use java:comp/jboss for our own stuff.

I've committed a prototype of injection in https://svn.jboss.org/repos/jbossas/projects/ejb3/trunk/injection. It is a standalone project which should be usable in the 1.4 client launcher.

The client launcher will then work more or less like org.jboss.injection.test.annotated.unit.AnnotatedTestCase. With the injector setup coming from JNDI.

Note/ToDo: check getHandle in Java URL factory. I think there might be a conflict there.
Actions

Go to original post