6 Replies Latest reply on May 8, 2002 10:27 AM by chrismein

    ClassLoading behaviour with static singleton pattern

    chrismein

      Congratulations on the new Release Candidate, I think the configuration changes have helped with things being quite intuitive. Hope the final release is soon!

      I have a JBoss question about something I'm not finding that intuitive...


      A common thing I am used to doing is having a static AppParams class that loads in a property file with some overall settings in it, config like stuff...

      In our system we have several web applications and separate EJB modules that we deploy on different machines running JBoss with their own configuration. Each has a module name as part of their configuration. They communicate by JMS. And all is well...

      We would like to run them all on the same machine in some circumstances, but...

      Under JBoss immediately running one web application and the central module is fine. Both have separate classloaders (I think) and two different static AppParam classes and all is well. When I deploy a second EJB module however it will share a classloader (I think) with the central module and will have the wrong config information.

      Under JBoss 3.0.0(alpha and beta) this sort of behavior is the same.

      Under JBoss 3.0.0(RC2) this has changed and now everything has the same classloader (I think) so even the web application and one EJB uses the same classloader and gets the same config information...

      Now I have read things about JBoss introducing a Unified Class Loader architecture in this release, due to problems with JMX MBeans I think. Does this change explain what I am seeing?

      The overall question is - is there some way that I can configure my jar files to use there own classloader. I have only found the classloader tag used in a service xml definition.

      Any help, gratefully accepted.

      Regards

      Chris Mein
      Chris

        • 1. Re: ClassLoading behaviour with static singleton pattern

          The 2.3 classloader has been turned off in RC2 to
          avoid ClassCastExceptions when the ejb jar
          is in WEB-INF/lib.

          The reason for the UnifiedClassLoader is to have
          truly local processing. The servlet and the ejb
          share the same classes rather than marshalling objects
          between the different classloaders.

          You can turn the 2.3 classloader back on in
          tomcat4-service.xml.
          Set Java2ClassLoadingCompliance to false.

          Regards,
          Adrian

          • 2. Re: ClassLoading behaviour with static singleton pattern
            chrismein

            Thanks Adrian, I was wondering why the change in behavior for war files.

            I still have a problem with my other deployed files however. In effect we have developed a handful of independent applications (deployed as ear files) communicating through JMS when required. Having developed these independently we would now like to have some more flexibility in how we deploy them. Due to our practice of using a static singleton class to load certain basic system data we run into problems due to the UnifiedClassLoader.

            Is there any way of switching this class loading behavior off? If I understand your previous message it is used to reduce the need to serialize objects in inter jar communications. As we use JMS we will never have this situation so get no benefit from this so would like to turn it off.

            It would be nice to know if this behavior can be configured or whether we will have to alter the way we load and access system information. If you have a sensible pattern for doing this I would appreciate it (one that does not involve JNDI or a database ideally!).

            Thanks in advance

            Chris

            • 3. Re: ClassLoading behaviour with static singleton pattern
              davidjencks

              Forgive my moral tone but static singletons are kind of evil;-) Would you consider using an mbean instead? Then you can either include the config info directly in the mbean configuration, eliminating the properties file (what I would do) or have the location of the properties file as an mbean attribute, allowing it to load. The mbean approach has the added advantage of making the configuration editable at runtime (this may require more work to propagate change notifications to those that need them).

              • 4. Re: ClassLoading behaviour with static singleton pattern
                chrismein

                I do agree with you that what I am doing is not ideal.

                However besides that the problem of a shared class loader does have other issues in my opinion. What happens when after running for some time I deploy a slightly different version of a class in a new jar file? I have some common code that goes into all my modules and this shouldn't really need to be kept in sink. But with the UnifiedClassLoader I will be forced to update everything.

                What I really need to know is is there a way of defining, in the jboss configuration, that I don't want to use the UnifiedClassLoader and that a certain jar needs to be run independantly.

                Regards

                Chris

                • 5. Re: ClassLoading behaviour with static singleton pattern
                  davidjencks

                  You have to use the UnifiedClassLoader, however the point behind it is that you can redeploy your classes and the new version will be used. This is exactly the problem it is designed to solve. (You do have to make sure there are no instances of the old classes hanging around, but if the instances are mbeans, this will be taken care of for you).

                  • 6. Re: ClassLoading behaviour with static singleton pattern
                    chrismein

                    Thanks very much! That is the clarification I wanted and I will change my config code accordingly.

                    It does raise a few minor issues though due to our architecture with independent modules, they will all have to be updated at once which doesn't make them very independent!

                    Not a real problem though as modules on the same machine will tend to be related, modules deployed apart not so we should get the independence we require.

                    Minor hassle, great product!

                    Thanks for you help.

                    Chris