2 Replies Latest reply on Jan 6, 2010 3:58 PM by maxradin

    Injection of application scope class at startup

    maxradin

      Hi all-


      We have a startup class (call it Class2 - Application scope) which has as a @Startup dependency another Application scope class (call it Class1). Class1 has org.jboss.core.jndi and org.jboss.core.jta as its startup dependency. (Class2 has Class1 as its startup dependency.)
      The idea is to make sure class 1 is instantiated before class2.


      This has been working for us for well over a year but recently, on one of our deployments, Class2 has been shown to be null intermittently on startup.


      One of our developers has attempted to remedy this by making the annotation for Class1 in Class2 create true. He says this works but I am concerned about multiple copies of what I consider to be a Singleton.


      Up until now the annotation for Class2 anywhere in our app has not had a create true anywhere and we have not had a problem. Note: this new deployment has a very large DB behind it and is quite sluggish on startup.


      I suspect that upping memory or another env. variable should the preferred way to go. Instatiating an application scope class like this by hand bothers me.


      Any comments/ideas?


      thanks
      Max

        • 1. Re: Injection of application scope class at startup
          germanescobar

          There is no way two instances of Class2 are created if you are using application scope (unless you use the new operator elsewhere).


          What do you mean by:





          Class2 has been shown to be null intermittently on startup.



          How do you realize about this? Maybe you are trying to inject it in another component and this component sometimes startup first.

          • 2. Re: Injection of application scope class at startup
            maxradin

            We get null pointer exceptions intermittently out of Class2 when referencing Class1 on startup. Class1 has not been initialized yet, it seems, even though Class2 has a startup dependency on it. It looks like Class2 is jumping the gun on startup. That's why a 'create new' was put in for it in Class2 - to force it to initialize. I didn't think this was right. This hasn't been needed up until now and we have had many successful deployments.


            thanks for your comment
            Max