The Uber Jars will always be more problematic than the "small ones" -
as the testsuite doesn't cover them at the same level, if at all - so
I don't think it would be wise to start having components to depend on
them, especially as this looks like it might become viral: what about
other component X that people will want to use with Spring?
Also when you're deploying on WildFly you probably want to use the
Logger from the application server as it's the one being managed. So
the solution would be wither never use Uber Jars when deploying on the
container, or remove JBoss Logger from the Uber Jars.
Shall I state once more that the whole Uber Jars affair seems a really
bad idea to me?
Thanks,
Sanne
On 1 February 2016 at 11:31, Sebastian Laskawiec <slaskawi(a)redhat.com> wrote:
Hey!
I'm currently trying to solve a tricky class loading issue connected to
Spring, CDI and Uber Jars. Here's the scenario:
Remote Uber Jar contains CDI module
Our Hot Rod client use newer version of JBoss Logging which is present in
Wildfly/EAP modules
However EAP and Wildfly will load (and make available for deployment) their
own version of JBoss Logging [1]
The easiest fix for this is to relocate JBoss Logging package in Uber Jar
Spring module requires some classes from Infinispan Common and they in turn
need BasicLogger from JBoss Logging
If we relocate JBoss Logging and will try to use Uber Jar with Spring - we
will end up with classloading issue [2]
So it seems the best approach is to make Spring depend on Uber Jars instead
of "small ones". Of course, users who use small jars will probably be
affected by this change (they would have to either accept using Uber Jars or
exclude them in their poms and add dependencies manually).
Is anyone against this solution? JIRA tracking ticket: [3].
Thanks
Sebastian
[1] Scenario with Weld enabled WAR
https://docs.jboss.org/author/display/AS7/Implicit+module+dependencies+fo...
[2]
https://bugzilla.redhat.com/show_bug.cgi?id=1266831#c7
[3]
https://issues.jboss.org/browse/ISPN-6132
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev