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

[Sebastian Laskawiec]

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/20160225/64370833/attachment.html