10 Replies Latest reply on Mar 28, 2018 3:14 PM by tcunning

    ESB java library isolation from JBoss kernel


      I have an ESB built on 4.12 that has been working for years, but recently my data provider changed their interface to be dependent on Wildfly technology (JBoss libraries in their class path).


      Now, when I call the data providers connect method from within the action of the ESB, I get the following error:


      org.jboss.soa.esb.actions.ActionProcessingException: open: org.jboss.logging.Logger.debugf(Ljava/lang/String;Ljava/lang/Object;)V


      So, there is a conflict between the data provider's jboss-logging-3.2.1.Final.jar and $JBOSS_HOME/lib/jboss-common.jar.


      I have tried all of the class loader isolation suggestions posted, and still no joy.


      Can this be made to work?




        • 1. Re: ESB java library isolation from JBoss kernel

          Hi David,


          That's unfortunate, but a little confusing - when you say that the data provider has changed their interface to be dependent on WildFly, what's the interaction here?  What version of EAP or JBoss AS is your installation of ESB being hosted on?    What version was it hosted on?   Is that what changed here?   Or has something remote to your ESB changed?


          Also, can you give a little more of the stack trace, and maybe a bit of your jboss-esb.xml that highlights the issue (obviously not interested in connection information, but action names / classes would be helpful)?   


          I think there's a few possible workaround here - using AOP to remove that debugf, changing the load order / dependencies, possibly changing the log configuration but without the version number / container information, and a little more information it's hard to pinpoint one.

          • 2. Re: ESB java library isolation from JBoss kernel

            Hi Tom,


            Thanks for the quick response!


            What changed is that the data provider now has a server based on Wildfly, and their client interface has changed to accommodate.


            Below are at least some of the JBoss libraries  that are supplied as part of their client libraries.






            I am hosting my ESB in the JBossESB 4.12 standalone distribution.


            Here is the expanded stack trace starting with the call from the ActionProcessor.  Probably not much help.  The DMSPlmHandler is my action processor, and all  of the datafusion/is3 stuff is the data provider’s API stack.


            Caused by: java.lang.NoSuchMethodError: org.jboss.logging.Logger.debugf(Ljava/lang/String;Ljava/lang/Object;)V

                            at com.mentor.is3.sec.client.connector.IS3ConnectorInstance.connect(IS3ConnectorInstance.java:132)

                            at com.mentor.is3.sec.client.connector.IS3ConnectorInstance.connect(IS3ConnectorInstance.java:126)

                            at com.mentor.is3.client.login.connector.LoginProcessor.login(LoginProcessor.java:122)

                            at com.mentor.is3.client.login.BatchLogin.loginFromCredentials(BatchLogin.java:288)

                            at com.mentor.is3.client.login.BatchLogin.doBatchLogin(BatchLogin.java:261)

                            at com.mentor.is3.client.login.Login.doBatchLogin(Login.java:656)

                            at com.mentor.is3.client.login.Login.doBatchLogin(Login.java:873)

                            at com.mentor.is3.client.login.Login.doBatchLogin(Login.java:990)

                            at com.mentor.datafusion.dfo.is3.login.IS3LoginUtil.performBatchLoginToIS3Server(IS3LoginUtil.java:211)

                            at com.mentor.datafusion.dfo.is3.login.IS3BatchAuthenticate.loginImpl(IS3BatchAuthenticate.java:68)

                            at com.mentor.datafusion.dfo.login.BatchAuthenticateImpl.login(BatchAuthenticateImpl.java:102)

                            at com.mentor.datafusion.dfo.login.BatchAuthenticate.login(BatchAuthenticate.java:53)

                            at com.mentor.datafusion.oi.internal.login.AuthenticateWrapper.login(AuthenticateWrapper.java:24)

                            at com.mentor.datafusion.oi.internal.login.AuthenticateWrapper.login(AuthenticateWrapper.java:19)

                            at com.mentor.dms.ws.api.DmsPlmHandler.open(DmsPlmHandler.java:198)

                            at com.mentor.dms.ws.api.DmsPlmHandler.open(DmsPlmHandler.java:154)

                            at com.mentor.dms.ws.jboss.JBossPlmHandler.open(JBossPlmHandler.java:414)




            • 3. Re: ESB java library isolation from JBoss kernel

              Just making sure I understand - the exception you are seeing is in the jbossesb-server-4.12 because you had to install a new client (including JARs) to connect to the data provider - and we're seeing collisions between jboss-logging-3.2.1Final.jar and the version of jboss-common.jar in /lib?


              If the above is true, where did you put the new JARs?   Did you put them inside your ESB or in a common /lib directory?


              I think this is going to be hard to work around because the JARs you are using are essentially incompatible - you've got a duplicate class with one of the fundamental server JARs.    Since it's just logging, you could try compiling a version of jboss-common 1.2.1.GA that has all the missing methods (source : http://anonsvn.jboss.org/repos/common/common-old/tags/JBossCommon_1_2_1_GA/ ) and hope there aren't any other duplicate classes, or you could try and change the client so that you don't need to bring in jboss-logging-3.2.1.jar, or your could use aspect interceptors to redirect the method calls (JBoss AOP).    None of these are options are really clean, but we're also talking about keeping an old JBoss ESB project going, so I think we're in the land of do-what-works.

              • 4. Re: ESB java library isolation from JBoss kernel

                Yes, you are understanding correctly!


                Because the data provider's client API installation is a file structure of jars which include other jars with relative Class-Paths, I decided to add a <classpath codebase="file://<root api library path>" archives="*"/> to the $JBOSS_HOME/server/default/conf/jboss-service.xml.  This ESB will be the only application running in this JBossESB instance, so no issue with the path being applied to all apps.   I could have followed all the Class_Path references and gathered up all of the required jars and included in the ESB.  However, with each new release, the data provider updates the API jars, so maintenance of the contents of the ESB becomes problematic.


                I have no ability to change the API client, so would only be left with option 1 or 3.


                I also have the same concern that this may not be the only duplicate class, but only way to know would be to get past this one and see what happens next.


                Which option of 1 and 3 would you recommend?

                • 5. Re: ESB java library isolation from JBoss kernel

                  Option 1 should take 5 minutes.   It's likely not a proper solution and I think you'll probably end up having to do #3, but I'd try #1 first because it'll tell you if there are more duplicate classes or further issues.

                  • 6. Re: ESB java library isolation from JBoss kernel

                    So, tried option 1, and it was like pulling the thread on a sweater.  More and more of the jboss-logging-3.2.1Final implementation missing/required...


                    Can you give me a brief description of how AOP might be applied to get around this issue?  Not familiar with this technology, but if you can give me basic idea of what you had in mind I can research further.


                    Thanks again for your help!

                    • 7. Re: ESB java library isolation from JBoss kernel

                      Check this out : Chapter 3. Introduction to JBossAop


                      I'm a little unsure of what version of JBoss AOP applies to JBoss AS 4.2.3.GA (the version of JBoss AS you are using in the 4.12GA server), so that'll take a little bit of research, but basically an interceptor it should allow you to do something like this - if org.jboss.logging.* is called from com.mentor.is3.sec.client.connector.ISConnectorInstance, run this method I provide instead.  

                      • 8. Re: ESB java library isolation from JBoss kernel

                        Looks interesting, but I'm unclear how I would be able to get around the original classloader limitation?

                        • 9. Re: ESB java library isolation from JBoss kernel

                          Also, do you know what kind of effort would be involved in moving a 4.12 ESB implementation to current JBoss equivalent?  The Enterprise IT department at this customer is trying to get them to move off this older platform anyway.

                          • 10. Re: ESB java library isolation from JBoss kernel

                            davidbrock  wrote:


                            Looks interesting, but I'm unclear how I would be able to get around the original classloader limitation?


                            The idea is that the AOP interceptor would have priority over either version of the class.      You'd intercept the method calls made to org.jboss.logging.* only when called from com.mentor.is3.sec.client.connector.ISConnectorInstance.


                            This could end up being a lot of work - I'm not sure how big your ESB implementation is but you might be able to replace it in WildFly + Camel quicker than replacing all of the calls.