[infinispan-dev] Spring module - change dependencies to Uber Jars

[Sebastian Laskawiec]

I think the plan is to cover more integration tests (if not all) with Uber
Jars - right Martin?

WRT the logger - yes you are absolutely correct and that's why logger
implementations are excluded from Uber Jars (Ubers contain only APIs - like
SLF4J-API or LOG4J-API).

I think the uber jar vs small jar is more about what configurations are
preferred. Note that you can always (even now) exclude all dependencies
from Spring Remote and add Remote Uber Jar manually. Switching Spring
Remote module to Uber Jars will only change the default behavior (we will
still be able to exclude dependencies and add small jars if you prefer
them).
If we proceed with this change - of course I will document this excluding
part in the docs (currently it is not written anywhere and it is
not-so-obvious solution).

On Mon, Feb 1, 2016 at 3:12 PM, Sanne Grinovero <sanne at infinispan.org>
wrote:

> 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 at 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+for+deployments
> > [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 at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20160202/6e038eb1/attachment.html