Implemented: https://github.com/infinispan/infinispan/pull/4039
Thanks Sebastian On Wed, Feb 3, 2016 at 3:11 PM, Sebastian Laskawiec <slask...@redhat.com> wrote: > 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
