8 Replies Latest reply on Nov 14, 2008 3:01 PM by Ales Justin

    how to re-configure class loader policy?

    Eduardo Martins Apprentice

      I have a bean that doesn't define a custom loader, and its class loader policy is doing black listing, how can I disable this?

      Thanks,
      Eduardo

        • 1. Re: how to re-configure class loader policy?
          Ales Justin Master

          What about VFSCLPolicy::setBlackListable(false)?
          Or

          <classloading xmlns="urn:jboss:classloading:1.0"
           name="test"
           blackList="false">
          </classloading>
          


          • 2. Re: how to re-configure class loader policy?
            Eduardo Martins Apprentice

             

            "alesj" wrote:
            What about VFSCLPolicy::setBlackListable(false)?
            Or
            <classloading xmlns="urn:jboss:classloading:1.0"
             name="test"
             blackList="false">
            </classloading>
            


            The first one I have seen but I don't know how can I reach the policy for the bean's classloader , the second doesn't require a custom classloader in the descriptor that won't acess the libs of the server?

            • 3. Re: how to re-configure class loader policy?
              Ales Justin Master

               

              "emmartins" wrote:
              but I don't know how can I reach the policy for the bean's classloader

              You need to configure that CL at the time of creation.
              e.g. proper jboss-classloading.xml in bean's jar

              Or push more info, as I don't see what you're trying to do - again. ;-)

              • 4. Re: how to re-configure class loader policy?
                Eduardo Martins Apprentice

                I'm having issues with Javassist, it seems that the parent of deployment unit created classloader, the one of the mobicents beans jar, is blacklisting generated classes, this is generating further errors, specially if I redeploy a deployable unit and classes have to be generated again.

                What would be content of the class loading descriptor for the same class loader as it is done by default (with no such descriptor) but with blacklisting off.

                Thanks,
                Eduardo

                PS: By the way, what's the idea of the black listing at all? :-)

                • 5. Re: how to re-configure class loader policy?
                  Ales Justin Master

                   

                  "emmartins" wrote:

                  What would be content of the class loading descriptor for the same class loader as it is done by default (with no such descriptor) but with blacklisting off.

                  Try this:
                  <classloading xmlns="urn:jboss:classloading:1.0" name="your-name-here"
                  export-all="NON_EMPTY" import-all="true" blackList="false">
                  </classloading>
                  


                  "emmartins" wrote:

                  PS: By the way, what's the idea of the black listing at all? :-)

                  Very simple and common idea. ;-)
                  Constantly looking up / resolving some classes that already failed is costly.
                  If you can put an early condition on this check, it speeds up things.


                  • 6. Re: how to re-configure class loader policy?
                    Eduardo Martins Apprentice

                    Worked, thanks, this, and the one in the other thread, are good info that could be on MC wiki.

                    Regarding the blacklisting feature, it's kind of confusing why it's not off by default, what is an example of an use case, where the lookup of a class that doesn't exist will benefict from this, won't all result in a java.lang.ClassNotFoundException that is usually a failure?

                    Another thing, lets say I have a domain and 2 class loaders (lets say CL1 and CL2), all with a policy defined as export-all="NON_EMPTY" import-all="true" blackList="false", a loadClass(String) of a class from CL1 in CL2 is failing, is this the expected behavior? Should instead the domain be always used for loading the class?

                    • 7. Re: how to re-configure class loader policy?
                      Eduardo Martins Apprentice

                       

                      "emmartins" wrote:

                      Another thing, lets say I have a domain and 2 class loaders (lets say CL1 and CL2), all with a policy defined as export-all="NON_EMPTY" import-all="true" blackList="false", a loadClass(String) of a class from CL1 in CL2 is failing, is this the expected behavior? Should instead the domain be always used for loading the class?


                      The domain is a no go too, the loadClass returns null.

                      • 8. Re: how to re-configure class loader policy?
                        Ales Justin Master

                         

                        "emmartins" wrote:
                        Should instead the domain be always used for loading the class?

                        I don't think you should be using domain, as that is impl specific.
                        You should be asking yourself why is classloading failing.

                        We have some info exposed, and there was a request from Scott,
                        saying the impl should help as much as possible to resolve why the class couldn't be resolved,
                        but I currently cannot recall what we did about that - apart from JMX exposure.