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

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Sebastian Laskawiec
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


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

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

Sanne Grinovero-3
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 <[hidden email]> 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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

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

Sebastian Laskawiec
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 <[hidden email]> 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 <[hidden email]> 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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

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

Sebastian Laskawiec
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev



_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

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

Sebastian Laskawiec

On Wed, Feb 3, 2016 at 3:11 PM, Sebastian Laskawiec <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev




_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

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

Sanne Grinovero-3
In reply to this post by Sanne Grinovero-3
On 1 February 2016 at 14:12, Sanne Grinovero <[hidden email]> 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?

+1 to myself here :) as we're witnessing again reports of issues with them.

Unless someone has a solid explanation about why they are needed,
could we start making plans for their deprecation?

As far as I remember they were introduced to "reduce the number of
dependencies" but this isn't the right way.

Thanks,
Sanne
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

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

Gustavo Fernandes-2
On Wed, Nov 2, 2016 at 11:12 PM, Sanne Grinovero <[hidden email]> wrote:
On 1 February 2016 at 14:12, Sanne Grinovero <[hidden email]> 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?

+1 to myself here :) as we're witnessing again reports of issues with them.

Unless someone has a solid explanation about why they are needed,
could we start making plans for their deprecation?

As far as I remember they were introduced to "reduce the number of
dependencies" but this isn't the right way.


+1

Having an uber jar is mostly a convenience for those not using a proper dependency management
system or doing quick prototypes, but as soon as we start having several uber jars, putting them
inside osgi bundles and creating jboss modules with them, they become really alternate jars and
a maintenance burden for very little benefit.

Gustavo

 

Thanks,
Sanne
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

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

Sebastian Laskawiec
I'm actually on the other side of the table. I really like them!

They are super easy to use - one dependency and off you go. It doesn't matter whether you use CDI, Query or any other feature - everything is there. 

Of course, there is a price to pay - we need to pull additional dependencies and relocate packages. But as Tristan once mentioned - it's only a matter of hammering all the errors out.

On Thu, Nov 3, 2016 at 10:23 AM, Gustavo Fernandes <[hidden email]> wrote:
On Wed, Nov 2, 2016 at 11:12 PM, Sanne Grinovero <[hidden email]> wrote:
On 1 February 2016 at 14:12, Sanne Grinovero <[hidden email]> 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?

+1 to myself here :) as we're witnessing again reports of issues with them.

Unless someone has a solid explanation about why they are needed,
could we start making plans for their deprecation?

As far as I remember they were introduced to "reduce the number of
dependencies" but this isn't the right way.


+1

Having an uber jar is mostly a convenience for those not using a proper dependency management
system or doing quick prototypes, but as soon as we start having several uber jars, putting them
inside osgi bundles and creating jboss modules with them, they become really alternate jars and
a maintenance burden for very little benefit.

Gustavo

 

Thanks,
Sanne
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

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

Sanne Grinovero-3
There are some benefits to it, but it gets extremely tricky and nasty
for end users if they happen to get duplicates of any of our
libraries, or dependencies.

I think the worst problem being that they "sneak in" unexpectedly as
Maven doesn't deal nicely with such situations, and the error messages
one gets are both scary and counter-intuitive.

Maybe we could alleviate for this problem by e.g. testing that some
resources are unique on the classpath? For example, add a marker file
in the infinispan-core.jar and a different marker in the uber jar,
then verify there's a strict either/or of each dependency instance.

FWI I'm confident that the current "benefits" far outweigh all the
problems these introduce, unless you can all spend some time on polish
those errors, and make sure the examples and docs are very clear about
either/or situations, I'd rather drop them.

Thanks,
Sanne

On 28 November 2016 at 12:31, Sebastian Laskawiec <[hidden email]> wrote:

> I'm actually on the other side of the table. I really like them!
>
> They are super easy to use - one dependency and off you go. It doesn't
> matter whether you use CDI, Query or any other feature - everything is
> there.
>
> Of course, there is a price to pay - we need to pull additional dependencies
> and relocate packages. But as Tristan once mentioned - it's only a matter of
> hammering all the errors out.
>
> On Thu, Nov 3, 2016 at 10:23 AM, Gustavo Fernandes <[hidden email]>
> wrote:
>>
>> On Wed, Nov 2, 2016 at 11:12 PM, Sanne Grinovero <[hidden email]>
>> wrote:
>>>
>>> On 1 February 2016 at 14:12, Sanne Grinovero <[hidden email]>
>>> 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?
>>>
>>> +1 to myself here :) as we're witnessing again reports of issues with
>>> them.
>>>
>>> Unless someone has a solid explanation about why they are needed,
>>> could we start making plans for their deprecation?
>>>
>>> As far as I remember they were introduced to "reduce the number of
>>> dependencies" but this isn't the right way.
>>
>>
>>
>> +1
>>
>> Having an uber jar is mostly a convenience for those not using a proper
>> dependency management
>> system or doing quick prototypes, but as soon as we start having several
>> uber jars, putting them
>> inside osgi bundles and creating jboss modules with them, they become
>> really alternate jars and
>> a maintenance burden for very little benefit.
>>
>> Gustavo
>>
>>
>>>
>>>
>>> Thanks,
>>> Sanne
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

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

Sebastian Laskawiec
In reply to this post by 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


On Thu, Feb 25, 2016 at 2:43 PM, Sebastian Laskawiec <[hidden email]> wrote:

On Wed, Feb 3, 2016 at 3:11 PM, Sebastian Laskawiec <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev





_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev