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

[Sebastian Laskawiec]

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 <slaskawi at redhat.com>
wrote:

> Implemented: https://github.com/infinispan/infinispan/pull/4039
>
> Thanks
> Sebastian
>
> On Wed, Feb 3, 2016 at 3:11 PM, Sebastian Laskawiec <slaskawi at 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 <slaskawi at 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 <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/20161130/f7e2ae86/attachment.html