EAR-wide singleton component

[leigh.anderson]

I have been trying to find a Seam-ish way of creating a singleton component where there is one instance for the entire EAR, rather than one per WAR as seems to be the behaviour when using the APPLICATION scope.

Our use case is for a LicenseManager component that tracks various licensable resources, which is accessed from 3 separate WARs -- the main UI for the application, the admin application, and a web-services API application. All three are deployed in the same EAR, along with the EJB jars containing the business components.

The component is currently a POJO declared in the APPLICATION scope, in one of the EJB modules deployed in the EAR. I have also tried the STATELESS scope, using a SLSB and POJO, and also using the JBoss-specific annotation @Service. All of these result in multiple instances of the LicenseManager being created.

We'd prefer not to persist this state into the DB, as most of what we're tracking does not need to persist across restarts.

For the time being, I've implemented this using a static member on the component to hold the state, but this seems something of a hackish solution to me.

Is there a way to accomplish this with Seam, or am I missing something obvious?

[lvdberg]

Hi,

why don'y you put the bean at the EAR-level (for instance in a separate JAR), this will solve your problem of an instance per WAR. So the obvious way is to add it to your EJB module, or am I missing something ?

Leo

[leigh.anderson]

Hi Leo,

Thanks for the response. The bean is in (one of) the EJB jar, not in the WAR -- as noted above I have tried it as a SLSB as well as a POJO. I still get multiple instances of the bean. This is kind of why I'm puzzled -- it would seem sensible to me that a bean with APPLICATION scope at the EAR level would be one-per-EAR, as that is the scope of the application in this context.

Leigh

[lvdberg]

Leigh,

Just guesssing now, but maybe it's because of the scanning Seam does in each WAR, so for each WAR deployment it finds the bean in the EAR-jar and creates one in the context of the WAR. If that's the case, try to solve it with the Install annotation which has some nice tricks to install (or-not) depending on the presence of another component.

Leo

[kapitanpetko]

Leigh Anderson wrote on Nov 11, 2010 08:45:


Thanks for the response. The bean is in (one of) the EJB jar, not in the WAR -- as noted above I have tried it as a SLSB as well as a POJO. I still get multiple instances of the bean. This is kind of why I'm puzzled -- it would seem sensible to me that a bean with APPLICATION scope at the EAR level would be one-per-EAR, as that is the scope of the application in this context.

There is not such thing as an 'APPLICATION scope at the EAR level', application scope is per web application (WAR). Don't let Seam instantiate your component, do it yourself in a postInitialization observer and only create one if it doesn't already exist. Something like:

    @Observer("org.jboss.seam.postInitialization")
    public void startup() {

        String[] names = Contexts.getApplicationContext().getNames();
        if (!Arrays.asList(names).contains("mycomponent")) {
            return;
        }
        // otherwise create it
   }

Still, it is better to have stuff in the DB, especially if you need clustering.

HTH

[leigh.anderson]

Many thanks for the responses, guys. Seems from what you're saying that Seam's idea of an application is a WAR, not an EAR, so there's no real way to have an EAR-wide singleton without using static members. So, I'll stick with that.

[kapitanpetko]

Leigh Anderson wrote on Nov 16, 2010 04:38:


Many thanks for the responses, guys. Seems from what you're saying that Seam's idea of an application is a WAR, not an EAR, so there's no real way to have an EAR-wide singleton without using static members. So, I'll stick with that.

As usual, this is how Java EE (in this case, 5) works. Seam didn't event it, is just uses it. Be wary of static members in an application server environment, and do consider other alternatives.