Hi think I wrote it on the list but to keep it in this thread:
we got several (numerous enough) users willing to deploy spring+cxf apps in TomEE. Several got conflicts with our built in CXF libraries. We then isolated CXF of the container from applications when relevant ( CxfContainerClassLoader). Issue doing it is all container CXF usages are wrapped in this particular classloader. By itself it is fine - and what does some container - but Tomcat is doing a caching by classloader in a HashTable and no luck for us the equals is done in the way we cant handle (ie yourClassLoader.equals(ourWrapper)). Since this is the first custom loader issue we got reported - vs several for the other issue - I think our default is still good. Potential fix would be to have 1 bus by application (either war or even jaxrs application) and skip this wrapping when the app doesnt have CXF but this would break an important part of our config so guess we are not that bad. If we got a bunch of custom loader usage then we ll need to consider our defaults again I think. Any opinion on this (tried to summarize the jira discussion)? Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber <http://www.tomitribe.com> 2015-07-21 8:52 GMT-07:00 Anne Stellingwerf <[email protected]>: > Dear all, > > Starting with the just released TomEE 1.7.2, we're facing issues with our > product. Our product uses a custom Loader to set a custom classloader. It > turns out, that even when I set the Loader in our context to the Tomcat > default (while I presume that setting it to the default shouldn't have any > effect), all of a sudden, it breaks resolving EJB Beans in a "new > InitialContext()". This was working OK on TomEE 1.7.1, but no longer in > 1.7.2. > Be aware that I'm talking about Loaders, not Classloaders. > > Setting the (undocumented) property > "openejb.cxf.CxfContainerClassLoader=false" in "conf/system.properties" > appears to work around the issue. What are my other options? Although I > sense this issue is about Loaders, Romain Manni-Bucau suggested to > implement "equals()" on the custom class loader in another way. What are > the requirements for doing that? > > Kind regards, > Anne Stellingwerf > > PS: This mail is sent in reference to > https://issues.apache.org/jira/browse/TOMEE-1616
