Jetty

Many thanks Florent, I'll take a look at this.

Have you tried this with EasyBeans inside Jetty? If so, where are you callling setComponentContext()?

Jan,

Yes I've tried this in EasyBeans but I haven't committed this part as it will depend on the solution provided in Jetty
For now I have the following code:

/**

• Sets Jetty ENC context.
• @param invocationContext context with useful attributes on the current
• invocation.
• @return result of the next invocation (to chain interceptors).
• @throws Exception needs for signature of interceptor.
  */
  @Override
  public Object intercept(final EasyBeansInvocationContext invocationContext) throws Exception
  Unknown macro: { // Get the subcontext (comp) Context oldContext = (Context) setComponentContextMethod.invoke(null, invocationContext .getFactory().getJavaContext().lookup("comp")); try { return invocationContext.proceed(); } finally { resetComponentContextMethod.invoke(null, oldContext); } }

Before invoking a business method, the ENC is set on the thread and at the end, the previous context is restored.
And as only comp context can be set (which is OK for me), I bind the comp subcontext extracted from the EJB's factory

Florent, I've solved this a slightly different way but your patch was the starting point for making me think about this, so thank you! The change I've made is to first try the classloader associated with the current webapp context,and falling back to the thread context classloader if there is no current webapp context. There will always be a current webapp context when we are processing a request. When we aren't processing a request, ie we are setting up the ENC, the thread context classloader will be that of the webapp.

I've checked my change into svn trunk. Can you look at it and try it with EasyBeans and see if it works? I'm hoping you won't need the intercept code and JNDi lookups should just work for you.

FYI, the relevant change I made looks like:

org.mortbay.naming.ContextFactory:

public Object getObjectInstance (Object obj, Name name, Context nameCtx, Hashtable env) throws Exception
{
// First, see if we are in a webapp context, if we are, use
// the classloader of the webapp to find the right jndi comp context
ClassLoader loader = null;
if (ContextHandler.getCurrentContext() != null)

if (loader != null)

else

//Get the context matching the classloader
Context ctx = (Context)_contextMap.get(loader);

....
}

cheers
Jan

While I'm thinking about it, is there anything else we can do to make integration easier? For example, I'm thinking there might be something we should do regarding security (short of implementing JACC) ?

regards
Jan

Hi Jan,

EasyBeans is packaged as a war file (with a context listener that starts the embedded container)
So I think it will have a web context associated and it will never use the Thread Context.

I will try but I'm not sure that it will work. This is why I was looking up first the thread context.
This is also the order used in JOnAS application server.

Concerning security/JACC, EasyBeans has a small JACC provider so yes I think we should provide a realm which can use a JACC provider.

Regards,

Florent.

Jan,

Here is a follow-up on the new mechanism (using Thread Context classloader)

Different beans of an ejb-jar can have the same classloader.
And each bean has a different ENC environment. (which is different of web-app. 1 war = 1 CL = 1 ENC)

So, by using the context classloader, I will have a problem because it won't be thread safe.
Bean A may use the ENC of the Bean B as they share the same context classloader.

Florent.

Darn! You're perfectly right. I've been in servlet land so long I forgot all about those ejb ENCs!

So, it looks like your solution is the way to go with a method allowing you to inject your own context. Do you create your own context with your own context impl or do you use Jetty's? If you use your own context, then it's probably best for me to just let you inject it. Otherwise, I could change Jetty so that it doesn't depend on a classloader as the "key" to lookup an ENC - I could change it so it would be possible to use any Object as "key" to attach an ENC to. In the case of webapps, the "key" would be a WebAppContext, and for EJBs it could be ... (guessing here) an EZBContext.

cheers
Jan

> Do you create your own context with your own context impl or do you use Jetty's?
I create my own context with my own context impl so I only need jetty to manage my context previously built.
The context is created before and it's the interceptor (JOnAS, EZB standalone, Tomcat, Jetty, etc) which plug the context into the system where EasyBeans is embedded.

As long as I can set my context in a given way (delegating factory, setters, whatever), it should be OK for me.
So I will use what you will provide

Regards,

Florent

Florent, I've checked in your patch to trunk. Can you test it? Let me know how it goes, I'm excited to get Jetty working with EasyBeans!

cheers
Jan

Jan, I've compiled and tested the SVN trunk which include this patch and it seems to work fine.
I've committed in EasyBeans the change to support Jetty (this is linked to this issue: http://jira.easybeans.org/browse/EZB-135)

I will also provide a Jetty package with a Getting started guide.

So next milestone version of EasyBeans should work with next 6.1.0preXX version.

Regards,

Florent.