7 Replies Latest reply on Feb 23, 2007 8:39 AM by Rex Sheridan

    Scoped class loading

    Rex Sheridan Newbie

      The jboss-service.xml for jbossesb.sar has the following code:


      I assume this has to do with using the Apache Scout implementation instead of whatever the default implementation of JAXR is inside the application server. I make this assumption based on the registry being the first thing that breaks when I take out the loder-repository from the configuration.

      Now, my question: Is there any way we can change this to use the regular UCL? My application is packaged in SARs that stand alone. I don't want to put them in as part of the jbossesb.sar.

        • 1. Re: Scoped class loading
          Kurt Stam Master

          Your assumption is right.

          If you don't want scoping at all you can remove the offending jaxr and scout jars from jbossas.

          However, before you go down that road, do you have problems with the 2 sars not seeing eachother or something? We are working on other deployment options too. So I'd like to learn what you are seeing.


          • 2. Re: Scoped class loading
            Rex Sheridan Newbie

            Yes, the sars cannot see each other. I am inserting an ESB Message into the jBPM context. Later, when an org.jbpm.graph.def.ActionHandler tries to retrieve the message from the context it cannot deserialize it because it cant find the classes.

            A simple fix (I guess) would be to include the ESB jars inside my SAR that has jBPM code. It doesn't feel right though.

            Now, should jBPM actions even be aware that they are running inside an ESB? I am not sure. Its something we've debated over my company.

            btw, where do the offending jaxr and scout jars live in jbossas?

            • 3. Re: Scoped class loading
              Kurt Stam Master

              Can you use the same classloader for both sars? I did this to get JBossMessaging working. That seems like the easy fix here. See also:

              • 4. Re: Scoped class loading
                Esteban Schifman Newbie

                Despite the fact that we are going to have the methods that allow to include the ESB message in the jBPM context, I thing it would be much cleaner to keep both applications as unaware as possible of each other.
                I'd rather have some core class that allows for easy transformation of the esb message into jBPM context variables (in the lines of Ronald's suggestion), instead of including the whole message itself. We would thus avoid the hazard of tight coupling.

                • 5. Re: Scoped class loading
                  Rex Sheridan Newbie


                  It is possible but I worry about this constraint being propagated further into other sars as well. For instance, any sars that depend on the one that shares with ESB will now have to be added too.


                  I am starting to lean in this direction too.

                  • 6. Re: Scoped class loading
                    Kurt Stam Master

                    1. It's not something we will have to live with for long. Hopefully soon enough the jaxr/scout jars in JBossAS will be in sync with what we need for ESB.

                    2. Also Bill Burke has been working on a jar deployment, rather then a sar deployment. IFAIK this work is pretty much completed but needs some further testing. It's currently on the BBurke branch.

                    3. We can stll go down the road of removing/updating the 'older' jaxr/scout jars from JBossAS. But I'd rather not do this as I'm not sure what the consequences are.


                    • 7. Re: Scoped class loading
                      Rex Sheridan Newbie

                      Thanks for the info, Kurt. I will follow your advice about not updating the JAXR jars on my deployment and just work around it for now. It shouldn't be a big deal since the Message class was the only thing I was trying to access.