Hey guys! Just FYI - recently I was thinking about putting Spring integration modules inside uber jars [1].
This could potentially lower the number of dependencies for our clients (they would just need Spring (either Boot or standard jars) and infinispan-embedded to get going) however after a longer thought I decided to kill this idea. The main reason is that placing both infinispan-embedded and infinispan-spring4-embedded would result in duplicated classes on the classpath. And this might cause many weird errors. I documented it in my comment [2]. Please let me know if you have any other thoughts and comments regarding this... Thanks Sebastian [1] https://issues.jboss.org/browse/ISPN-7237 [2] https://issues.jboss.org/browse/ISPN-7237?focusedCommentId=13331339#comment-13331339 On Thu, Feb 25, 2016 at 2:43 PM, Sebastian Laskawiec <slask...@redhat.com> wrote: > 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
