During our talk on IRC Tristan proposed to mark Spring dependencies as provided. Another similar approach would be to make them optional.
I think both approaches are even better than making Spring module depend on Uber Jars. However there is a price to pay - each user will probably have to declare in his pom what dependencies he'd like to use (uber or small jars). On Tue, Feb 2, 2016 at 7:53 AM, Sebastian Laskawiec <slask...@redhat.com> wrote: > 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 <sa...@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 <slask...@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@lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/infinispan-dev >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> > >
_______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
