7 Replies Latest reply on Jan 25, 2008 10:45 AM by adrian.brock

    Context ClassLoader - POJO

      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
          starksm64

          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).

          • 2. Re: Context ClassLoader - POJO
            • 3. Re: Context ClassLoader - POJO

               

              "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@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@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
                    alesj

                     

                    "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

                       

                      "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.