7 Replies Latest reply on Jan 25, 2008 10:45 AM by Adrian Brock

    Context ClassLoader - POJO

    Adrian Brock Master

      Most of the containers are already setting the correct context classloader,
      e.g. MBeans and EJB do it

      But the POJO deployment runs with a "random" context classloader.

      The changes required to fix this are:

      1) Set the context classloader in the callbacks (e.g. instantiate, configure, create, start, etc.)

      2) Add ClassLoaderMetaData - the POJO version of this class, not be confused with the
      deployment metadata with the same name :-( - to use the classloader of the deployment
      (if the -beans.xml or bean does not already override it to use an explicit classloader).

      My preference in the past would be to make this an aspect (since it should arguably do it
      for methods that are not part of the IOC protocol, e.g. runtime methods),
      but I'm now convinced that the MC should be doing it itself.

      First the MC should be able to run without AOP, so it isn't really the full solution.
      (Of course you could argue that the feature is only available with AOP :-)

      Second, there are times when you might want the correct classloader during
      configuration, but use the caller's context classloader at runtime.

      Third, configuring the aspect (even with a simple annotation) on every relevant POJO
      would be a configuration nightmare.

      So the solution I propose is set the context classloader in the IOC callbacks,
      but require the aspect for this behaviour at runtime.

      Also, this won't change the behaviour for standalone MC usage
      since if the classloader is not configured (it will be always inside JBoss
      since it will set to the deployment classloader when not configured)
      it will just "redundantly" reset the classloader to context classloader, i.e. no change

        • 1. Re: Context ClassLoader - POJO
          Scott Stark Master

          Who is going to have to configure the aspect, the bean deployment, or would this be setup by the deployer in the absence an override config? (not sure you can detect that other than a flag saying not to install the aspect).

          • 3. Re: Context ClassLoader - POJO
            Adrian Brock Master

             

            "scott.stark@jboss.org" wrote:
            Who is going to have to configure the aspect, the bean deployment, or would this be setup by the deployer in the absence an override config? (not sure you can detect that other than a flag saying not to install the aspect).


            There is no aspect. The classloader will set automatically from the configured classloader.
            For beans created from the deployment layer, it will be the classloader of the deployment
            unless there is a specific one in the xml.

            • 4. Re: Context ClassLoader - POJO
              Adrian Brock Master

               

              "adrian@jboss.org" wrote:
              JIRA issue: http://jira.jboss.com/jira/browse/JBMICROCONT-230


              I've done this. There are two issues remaining.

              I wasn't really sure how the Callbacks hang together so I've done the setting
              of the context classloader in a very fine grained way. i.e. setting the classloader
              before doing any callbacks rather than on a per callback basis.

              The other issue is that there are somethings not tested (and may not work :-)
              e.g. the KernelContextAware callbacks and I'm not entirely sure what
              class attribute callbacks are, so I don't know how to test them :-)

              Ales, can you see what other callbacks onto the bean that you've added
              might also need this processing and add tests?

              • 5. Re: Context ClassLoader - POJO
                Adrian Brock Master

                 

                "adrian@jboss.org" wrote:
                "scott.stark@jboss.org" wrote:
                Who is going to have to configure the aspect, the bean deployment, or would this be setup by the deployer in the absence an override config? (not sure you can detect that other than a flag saying not to install the aspect).


                There is no aspect. The classloader will set automatically from the configured classloader.
                For beans created from the deployment layer, it will be the classloader of the deployment
                unless there is a specific one in the xml.


                We should probably raise a feature request for such an aspect for runtime invocations?

                i.e. write an aspect that introduces a KernelControllerContextAware onto the POJO and
                steals the classloader from it during deployment.
                Then it sets the context classloader to that classloader during invocations on the object.

                • 6. Re: Context ClassLoader - POJO
                  Ales Justin Master

                   

                  "adrian@jboss.org" wrote:

                  Ales, can you see what other callbacks onto the bean that you've added
                  might also need this processing and add tests?

                  OK, I'll have a look.

                  btw: the installs have different CL usage as callbacks
                  Installs have it per install instance, where callbacks are grouped in a single set.
                  Why the difference?

                  • 7. Re: Context ClassLoader - POJO
                    Adrian Brock Master

                     

                    "alesj" wrote:

                    btw: the installs have different CL usage as callbacks
                    Installs have it per install instance, where callbacks are grouped in a single set.
                    Why the difference?


                    I thought I explained it above? Let me reword it :-)

                    * The classloader usage is the same from the user's point of view.
                    e.g. The addDeployer() invocation on the MainDeployer will have the context classloader
                    of the Deployer being added regardless of which mechanism is used.
                    It's different from our point of view because install and incallback are implemented
                    in different ways.

                    * I didn't understand how the callbacks hang together so I just wrapped all the
                    processing inside the classloader change. If it causes problems then
                    we (most likely you :-) will have to workout how to do it more fine-grained.
                    I also assumed this would take care of the callbacks like the class attribute
                    that I didn't know existed, let alone understand.