Hi Nicklas

Thanks for the swift response.

Do you mean I must add the @Inject annotation on the client side? If I do that, I get the same error. Here is my code:

public class Main {

    @Inject @EJB
    private static InjectorService remoteEjb;

    public static void main(String[] args) {
       System.out.println(remoteEjb.doSomething());
       System.out.println(remoteEjb.doSomething());
    }
}

If I remove the @EJB annotation and make it an instance variable, then it simply stays NULL, as if CDI is ignoring the @Inject annotation on my client.

I am of course quite a newbie with CDI, so I may in fact completely miss what you've suggested ...

OK, after some further reading I conclude that my NullPointerException is due to the fact that my client is not running under a CDI context.

I can get the desired behaviour by implementing a custom scope using this tutorial.

However, this is clumsy, as this scope really just behaves like a RequestScoped service would if it was invoked from a servlet container via the EJB's local interface.

Surely the normal request scope context must be available when doing a standard remote EJB invocation?

I don't think my problem is with the client either, because the client of the EJB should not be concerned with its CDI context.

My central question really is just: Is it a bug that Glassfish/Weld is not activating the request scope for remote EJB invocations, or is that how CDI specifies it?

Thanks Nicklas,

I'm not using the SE extension - I'm using EJB's in Glassfish. I think the problem is that my EJB is invoked via RMI/IIOP, not the servlet layer, which means that there is no HTTP context to propagate to CDI.

I was hoping that Weld would activate the standard scopes outside of the servlet context, since the EJB context should provide the same semantics as an HTTP context.

I found the following interceptor in Weld:

org.jboss.weld.ejb.SessionBeanInterceptor

It seems to do exactly what I am looking for here. However, curiously, it does not seem to be active by default, and when I try to switch in on using beans.xml, Glassfish complains that the interceptor does not have the @Interceptor annotation.

I managed to get it working by copying the source code into my own interceptor. I also had to add weld-core.jar to my ejb classpath (for some reason Glassfish cannot load org.jboss.weld.context.beanstore.HashMapBeanStore, probably due to a dependency that is not present is the default distribution).

It does work and, regardless of the nasty interceptor binding I have to add to my EJB, is a far better way to deal with this than defining a custom scope.

However, I still feel that a CDI implementation should provide standard context activation outside of a servlet context, because the Java EE spec does not require access to EJB's to go through a servlet layer.

I suppose doing a similar interceptor-style solution for session and conversation scope could be more tricky as you would have to access the EJB context, which is probably not as standards-driven as the HTTP equivalents. I'll give it a bash over then next few days.

I appreciate the pointers, Nicklas (over a weekend, nothing less!).

What I'm trying to say is that just about the whole of this thread appears to be riddled with misunderstanding.

Yep, I'll take responsibility for that - I am obviously quite a newbie here, so some of these concepts are still taking shape in my mind, so my questions may not be clear. I'll try to fix that now.

First some background: I develop and support an enterprise application that makes extensive use of rich application clients (not RIA, but SWT on the desktop) that invoke EJB's using RMI/IIOP directly. This is not a web application, so we don't make use of any servlet/HTTP based technology - we call the RMI interface directly. My task at the moment is to determine the effort required to bring this app up to Java EE 6 standards, including adopting the excellent CDI approach over our current Guice implementation.

My question is not about the client side of the application at all - I simply included that snippet so that someone with better knowledge can replicate my situation if he/she so chooses. I should have added that it runs inside the Glassfish client container though.

What I want to do is use the standard scopes of CDI (request, session, conversation and application) on my server side EJB's, without going through a servlet engine, but using RMI/IIOP directly.

As you point out (6.7.1), it should work regardless of whether the activation goes through the servlet layer or via RMI. However, as my first example shows, this does not seem to work out of the box with the current Glassfish release, either because:

1. Its a bug in Weld/Glassfish


2. I'm doing something stupid


3. CDI is not required to support RMI activations unless you go through a servlet layer first

In case 1 or 2 I'm not really concerned (but please tell me if I'm doing something stupid!) :)

If it is case 3, then I want the community's opinion on whether RMI/IIOP is still a viable protocol if we want to adopt CDI on the server using the standard scope types.

Thanks for the time, I hope that clears things up a bit.

As you point out (6.7.1), it should work

Just to correct, you said the request scope should work, not necessarily the session or conversation scopes.

Thanks

If I want my RMI server to also support SessionScoped and ConversationScoped contexts (these, as far as I can see, is not required to be supported outside of the servlet context), what are my practical options for doing this?

1. Implement a custom scope


2. Use an interceptor to activate the scope

Neither of these approaches are perfect (but I think 2 is better than 1), is there another way that I'm unaware of?