You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Kristian Rosenvold <kr...@gmail.com> on 2014/02/13 08:28:07 UTC
Linkage error
Stuart,
We're seeing java.lang.LinkageError: loader constraint violation: loader
(instance of org/codehaus/plexus/classworlds/realm/ClassRealm) previously
initiated loading for a different type with name
"javax/enterprise/util/TypeLiteral" using the maven-jetty-plugin on 3.1. I
can't really see this seeping through in DefaultClassRealmManager, but
google shows me https://java.net/jira/browse/GLASSFISH-20802
Is this something you understand ?
Kristia
n
Re: Linkage error
Posted by Kristian Rosenvold <kr...@gmail.com>.
It still breaks with 3.1.1; bugger :)
2014-02-13 10:23 GMT+01:00 Tamás Cservenák <ta...@cservenak.net>:
> Maybe related to https://jira.codehaus.org/browse/MNG-5513 ?
>
> As cdi-api is now also in core?
>
>
> Thanks,
> ~t~
>
>
> On Thu, Feb 13, 2014 at 8:28 AM, Kristian Rosenvold <
> kristian.rosenvold@gmail.com> wrote:
>
> > Stuart,
> >
> > We're seeing java.lang.LinkageError: loader constraint violation: loader
> > (instance of org/codehaus/plexus/classworlds/realm/ClassRealm) previously
> > initiated loading for a different type with name
> > "javax/enterprise/util/TypeLiteral" using the maven-jetty-plugin on 3.1.
> I
> > can't really see this seeping through in DefaultClassRealmManager, but
> > google shows me https://java.net/jira/browse/GLASSFISH-20802
> >
> >
> > Is this something you understand ?
> >
> > Kristia
> > n
> >
>
Re: Linkage error
Posted by Tamás Cservenák <ta...@cservenak.net>.
Maybe related to https://jira.codehaus.org/browse/MNG-5513 ?
As cdi-api is now also in core?
Thanks,
~t~
On Thu, Feb 13, 2014 at 8:28 AM, Kristian Rosenvold <
kristian.rosenvold@gmail.com> wrote:
> Stuart,
>
> We're seeing java.lang.LinkageError: loader constraint violation: loader
> (instance of org/codehaus/plexus/classworlds/realm/ClassRealm) previously
> initiated loading for a different type with name
> "javax/enterprise/util/TypeLiteral" using the maven-jetty-plugin on 3.1. I
> can't really see this seeping through in DefaultClassRealmManager, but
> google shows me https://java.net/jira/browse/GLASSFISH-20802
>
>
> Is this something you understand ?
>
> Kristia
> n
>
Re: Linkage error
Posted by Stuart McCulloch <mc...@gmail.com>.
On 13 Feb 2014, at 17:08, Kristian Rosenvold <kr...@gmail.com> wrote:
> Wouldn't it make more sense to roll our own version of "typed" then?
Why roll our own when there’s a standard annotation available? I can always add our own version of @Typed under a different package, but that doesn’t seem to encourage re-use.
> Leaking "ee" stuff from core does not seem like nice thing.
>
> Kristian (Who will only touch "ee" stuff with a pitchfork)
>
> 2014-02-13 18:01 GMT+01:00 Igor Fedorenko <ig...@ifedorenko.com>:
>
>> Please keep @Typed annotation available outside of core.
>>
>> I use @Typed annotation in one of my (private) core extensions where I
>> need a class to implement an interface but not make that interface
>> visible for injection in other components.
>>
>> --
>> Regards,
>> Igor
>>
>>
>> On 2/13/2014, 9:43, Jason van Zyl wrote:
>>
>>>
>>> On Feb 13, 2014, at 8:44 AM, Stuart McCulloch <mc...@gmail.com> wrote:
>>>
>>> On 13 Feb 2014, at 13:30, Jason van Zyl <ja...@takari.io> wrote:
>>>>
>>>> I would consider something like SFL4J as something which is now part of
>>>>> our API think it's fine to expose something like that. I'm not sure the
>>>>> same holds true for CDI. Wouldn't it be better just to completely hide it?
>>>>>
>>>>
>>>> As mentioned in http://wiki.eclipse.org/Sisu/
>>>> PlexusMigration#Type_Override, the @javax.enterprise.inject.Typed
>>>> annotation can be used to restrict the type visibility of components.
>>>>
>>>> Hiding this package means you wouldn't be able to use this feature
>>>> outside of Maven core - so I guess it depends whether you consider CDI's
>>>> @Typed part of the component API like JSR330's @Inject.
>>>>
>>>>
>>> I would say I don't consider it part of our API, so I'd be inclined to
>>> hide it and strictly stick to JSR330. Will Sisu not load without it? I
>>> think we keep running into these issues with App Servers because people are
>>> trying to run their App Server in Maven's runtime environment which doesn't
>>> really make sense. For any of these strange conflicts that arise with SLF4J
>>> or other APIs I think we should just encourage people to run any sort of
>>> test for your App Server with an environment akin to production in that you
>>> should fork once with your own classpath and whatever else you need.
>>> Maven's APIs and runtime environment are for build related activities.
>>> Where we have this cross over like like the jetty/tomcat/wildfly-maven-plugin
>>> I think we should just tell people the best thing to do is fork once and do
>>> what you like.
>>>
>>> The CDI API is at least standardised (one of the reasons why the
>>>> container respects @Typed rather than creating it's own ad-hoc annotation
>>>> which wouldn't be as portable).
>>>>
>>>>
>>> Why would we need it? You have any use cases at hand?
>>>
>>> On Feb 13, 2014, at 5:56 AM, Stuart McCulloch <mc...@gmail.com> wrote:
>>>>>
>>>>> On 13 Feb 2014, at 07:28, Kristian Rosenvold <
>>>>>> kristian.rosenvold@gmail.com> wrote:
>>>>>>
>>>>>> Stuart,
>>>>>>>
>>>>>>> We're seeing java.lang.LinkageError: loader constraint violation:
>>>>>>> loader
>>>>>>> (instance of org/codehaus/plexus/classworlds/realm/ClassRealm)
>>>>>>> previously
>>>>>>> initiated loading for a different type with name
>>>>>>> "javax/enterprise/util/TypeLiteral" using the maven-jetty-plugin on
>>>>>>> 3.1. I
>>>>>>> can't really see this seeping through in DefaultClassRealmManager, but
>>>>>>> google shows me https://java.net/jira/browse/GLASSFISH-20802
>>>>>>>
>>>>>>> Is this something you understand ?
>>>>>>>
>>>>>>
>>>>>> DefaultClassRealmManager currently exposes the complete
>>>>>> javax.enterprise.inject package from CDI-API:
>>>>>>
>>>>>> imports.put( "javax.enterprise.inject.*", coreRealm );
>>>>>>
>>>>>> This package contains annotations, exceptions, and one interface - and
>>>>>> it looks like the interface pulls in a type from javax.enterprise.util:
>>>>>>
>>>>>> http://docs.oracle.com/javaee/6/api/javax/enterprise/inject/
>>>>>> Instance.html#select(javax.enterprise.util.TypeLiteral,%
>>>>>> 20java.lang.annotation.Annotation...)
>>>>>>
>>>>>> Which means that while javax.enterprise.inject.Instance is loaded and
>>>>>> exposed from the core realm, javax.enterprise.util.TypeLiteral will
>>>>>> be loaded from core but not exposed - this is likely the cause of the
>>>>>> constraint violation.
>>>>>>
>>>>>> There are two solutions - first we could narrow the exposure in
>>>>>> DefaultClassRealmManager to:
>>>>>>
>>>>>> imports.put( "javax.enterprise.inject.Typed", coreRealm );
>>>>>>
>>>>>> since that is the only CDI annotation we're really interested in, and
>>>>>> it has no dependencies to other types.
>>>>>>
>>>>>> Alternatively we could widen the exposure to include the
>>>>>> javax.enterprise.util package:
>>>>>>
>>>>>> imports.put( "javax.enterprise.inject.*", coreRealm );
>>>>>> imports.put( "javax.enterprise.util.*", coreRealm );
>>>>>>
>>>>>> which should also fix the loader constraint while not introducing
>>>>>> other issues.
>>>>>>
>>>>>> WDYT?
>>>>>>
>>>>>> Kristian
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>>
>>>>> Thanks,
>>>>>
>>>>> Jason
>>>>>
>>>>> ----------------------------------------------------------
>>>>> Jason van Zyl
>>>>> Founder, Apache Maven
>>>>> http://twitter.com/jvanzyl
>>>>> http://twitter.com/takari_io
>>>>> ---------------------------------------------------------
>>>>>
>>>>> Selfish deeds are the shortest path to self destruction.
>>>>>
>>>>> -- The Seven Samuari, Akira Kurosawa
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>> Thanks,
>>>
>>> Jason
>>>
>>> ----------------------------------------------------------
>>> Jason van Zyl
>>> Founder, Apache Maven
>>> http://twitter.com/jvanzyl
>>> http://twitter.com/takari_io
>>> ---------------------------------------------------------
>>>
>>> Simplex sigillum veri. (Simplicity is the seal of truth.)
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Linkage error
Posted by Kristian Rosenvold <kr...@gmail.com>.
Well we'll always have the cutoff problem once we start leaking classes we
don't really have any control over. Given a fairly marginal use case with
probably just 1 user, I think my point is valid.
These classes are in the javax.enterprise package space. That's "ee" to me.
Even the modern ee stuff is the pinnacle of all that is wrong about java,
but my opinion on this subject is really not the point here.
Either way they go in or out. Keeping "Typed" *in* i going to cause grief
down the line, but you ee users are used to that anyway.
Kristian
Kristian
Re: Linkage error
Posted by Igor Fedorenko <ig...@ifedorenko.com>.
I don't think there is anything 'ee' about @Typed annotation. I would
keep it and would make it the only cdi.jar class exported by the core.
--
Regards,
Igor
On 2/13/2014, 12:08, Kristian Rosenvold wrote:
> Wouldn't it make more sense to roll our own version of "typed" then?
> Leaking "ee" stuff from core does not seem like nice thing.
>
> Kristian (Who will only touch "ee" stuff with a pitchfork)
>
>
> 2014-02-13 18:01 GMT+01:00 Igor Fedorenko <ig...@ifedorenko.com>:
>
>> Please keep @Typed annotation available outside of core.
>>
>> I use @Typed annotation in one of my (private) core extensions where I
>> need a class to implement an interface but not make that interface
>> visible for injection in other components.
>>
>> --
>> Regards,
>> Igor
>>
>>
>> On 2/13/2014, 9:43, Jason van Zyl wrote:
>>
>>>
>>> On Feb 13, 2014, at 8:44 AM, Stuart McCulloch <mc...@gmail.com> wrote:
>>>
>>> On 13 Feb 2014, at 13:30, Jason van Zyl <ja...@takari.io> wrote:
>>>>
>>>> I would consider something like SFL4J as something which is now part of
>>>>> our API think it's fine to expose something like that. I'm not sure the
>>>>> same holds true for CDI. Wouldn't it be better just to completely hide it?
>>>>>
>>>>
>>>> As mentioned in http://wiki.eclipse.org/Sisu/
>>>> PlexusMigration#Type_Override, the @javax.enterprise.inject.Typed
>>>> annotation can be used to restrict the type visibility of components.
>>>>
>>>> Hiding this package means you wouldn't be able to use this feature
>>>> outside of Maven core - so I guess it depends whether you consider CDI's
>>>> @Typed part of the component API like JSR330's @Inject.
>>>>
>>>>
>>> I would say I don't consider it part of our API, so I'd be inclined to
>>> hide it and strictly stick to JSR330. Will Sisu not load without it? I
>>> think we keep running into these issues with App Servers because people are
>>> trying to run their App Server in Maven's runtime environment which doesn't
>>> really make sense. For any of these strange conflicts that arise with SLF4J
>>> or other APIs I think we should just encourage people to run any sort of
>>> test for your App Server with an environment akin to production in that you
>>> should fork once with your own classpath and whatever else you need.
>>> Maven's APIs and runtime environment are for build related activities.
>>> Where we have this cross over like like the jetty/tomcat/wildfly-maven-plugin
>>> I think we should just tell people the best thing to do is fork once and do
>>> what you like.
>>>
>>> The CDI API is at least standardised (one of the reasons why the
>>>> container respects @Typed rather than creating it's own ad-hoc annotation
>>>> which wouldn't be as portable).
>>>>
>>>>
>>> Why would we need it? You have any use cases at hand?
>>>
>>> On Feb 13, 2014, at 5:56 AM, Stuart McCulloch <mc...@gmail.com> wrote:
>>>>>
>>>>> On 13 Feb 2014, at 07:28, Kristian Rosenvold <
>>>>>> kristian.rosenvold@gmail.com> wrote:
>>>>>>
>>>>>> Stuart,
>>>>>>>
>>>>>>> We're seeing java.lang.LinkageError: loader constraint violation:
>>>>>>> loader
>>>>>>> (instance of org/codehaus/plexus/classworlds/realm/ClassRealm)
>>>>>>> previously
>>>>>>> initiated loading for a different type with name
>>>>>>> "javax/enterprise/util/TypeLiteral" using the maven-jetty-plugin on
>>>>>>> 3.1. I
>>>>>>> can't really see this seeping through in DefaultClassRealmManager, but
>>>>>>> google shows me https://java.net/jira/browse/GLASSFISH-20802
>>>>>>>
>>>>>>> Is this something you understand ?
>>>>>>>
>>>>>>
>>>>>> DefaultClassRealmManager currently exposes the complete
>>>>>> javax.enterprise.inject package from CDI-API:
>>>>>>
>>>>>> imports.put( "javax.enterprise.inject.*", coreRealm );
>>>>>>
>>>>>> This package contains annotations, exceptions, and one interface - and
>>>>>> it looks like the interface pulls in a type from javax.enterprise.util:
>>>>>>
>>>>>> http://docs.oracle.com/javaee/6/api/javax/enterprise/inject/
>>>>>> Instance.html#select(javax.enterprise.util.TypeLiteral,%
>>>>>> 20java.lang.annotation.Annotation...)
>>>>>>
>>>>>> Which means that while javax.enterprise.inject.Instance is loaded and
>>>>>> exposed from the core realm, javax.enterprise.util.TypeLiteral will
>>>>>> be loaded from core but not exposed - this is likely the cause of the
>>>>>> constraint violation.
>>>>>>
>>>>>> There are two solutions - first we could narrow the exposure in
>>>>>> DefaultClassRealmManager to:
>>>>>>
>>>>>> imports.put( "javax.enterprise.inject.Typed", coreRealm );
>>>>>>
>>>>>> since that is the only CDI annotation we're really interested in, and
>>>>>> it has no dependencies to other types.
>>>>>>
>>>>>> Alternatively we could widen the exposure to include the
>>>>>> javax.enterprise.util package:
>>>>>>
>>>>>> imports.put( "javax.enterprise.inject.*", coreRealm );
>>>>>> imports.put( "javax.enterprise.util.*", coreRealm );
>>>>>>
>>>>>> which should also fix the loader constraint while not introducing
>>>>>> other issues.
>>>>>>
>>>>>> WDYT?
>>>>>>
>>>>>> Kristian
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>>
>>>>> Thanks,
>>>>>
>>>>> Jason
>>>>>
>>>>> ----------------------------------------------------------
>>>>> Jason van Zyl
>>>>> Founder, Apache Maven
>>>>> http://twitter.com/jvanzyl
>>>>> http://twitter.com/takari_io
>>>>> ---------------------------------------------------------
>>>>>
>>>>> Selfish deeds are the shortest path to self destruction.
>>>>>
>>>>> -- The Seven Samuari, Akira Kurosawa
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>> Thanks,
>>>
>>> Jason
>>>
>>> ----------------------------------------------------------
>>> Jason van Zyl
>>> Founder, Apache Maven
>>> http://twitter.com/jvanzyl
>>> http://twitter.com/takari_io
>>> ---------------------------------------------------------
>>>
>>> Simplex sigillum veri. (Simplicity is the seal of truth.)
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Linkage error
Posted by Kristian Rosenvold <kr...@gmail.com>.
Wouldn't it make more sense to roll our own version of "typed" then?
Leaking "ee" stuff from core does not seem like nice thing.
Kristian (Who will only touch "ee" stuff with a pitchfork)
2014-02-13 18:01 GMT+01:00 Igor Fedorenko <ig...@ifedorenko.com>:
> Please keep @Typed annotation available outside of core.
>
> I use @Typed annotation in one of my (private) core extensions where I
> need a class to implement an interface but not make that interface
> visible for injection in other components.
>
> --
> Regards,
> Igor
>
>
> On 2/13/2014, 9:43, Jason van Zyl wrote:
>
>>
>> On Feb 13, 2014, at 8:44 AM, Stuart McCulloch <mc...@gmail.com> wrote:
>>
>> On 13 Feb 2014, at 13:30, Jason van Zyl <ja...@takari.io> wrote:
>>>
>>> I would consider something like SFL4J as something which is now part of
>>>> our API think it's fine to expose something like that. I'm not sure the
>>>> same holds true for CDI. Wouldn't it be better just to completely hide it?
>>>>
>>>
>>> As mentioned in http://wiki.eclipse.org/Sisu/
>>> PlexusMigration#Type_Override, the @javax.enterprise.inject.Typed
>>> annotation can be used to restrict the type visibility of components.
>>>
>>> Hiding this package means you wouldn't be able to use this feature
>>> outside of Maven core - so I guess it depends whether you consider CDI's
>>> @Typed part of the component API like JSR330's @Inject.
>>>
>>>
>> I would say I don't consider it part of our API, so I'd be inclined to
>> hide it and strictly stick to JSR330. Will Sisu not load without it? I
>> think we keep running into these issues with App Servers because people are
>> trying to run their App Server in Maven's runtime environment which doesn't
>> really make sense. For any of these strange conflicts that arise with SLF4J
>> or other APIs I think we should just encourage people to run any sort of
>> test for your App Server with an environment akin to production in that you
>> should fork once with your own classpath and whatever else you need.
>> Maven's APIs and runtime environment are for build related activities.
>> Where we have this cross over like like the jetty/tomcat/wildfly-maven-plugin
>> I think we should just tell people the best thing to do is fork once and do
>> what you like.
>>
>> The CDI API is at least standardised (one of the reasons why the
>>> container respects @Typed rather than creating it's own ad-hoc annotation
>>> which wouldn't be as portable).
>>>
>>>
>> Why would we need it? You have any use cases at hand?
>>
>> On Feb 13, 2014, at 5:56 AM, Stuart McCulloch <mc...@gmail.com> wrote:
>>>>
>>>> On 13 Feb 2014, at 07:28, Kristian Rosenvold <
>>>>> kristian.rosenvold@gmail.com> wrote:
>>>>>
>>>>> Stuart,
>>>>>>
>>>>>> We're seeing java.lang.LinkageError: loader constraint violation:
>>>>>> loader
>>>>>> (instance of org/codehaus/plexus/classworlds/realm/ClassRealm)
>>>>>> previously
>>>>>> initiated loading for a different type with name
>>>>>> "javax/enterprise/util/TypeLiteral" using the maven-jetty-plugin on
>>>>>> 3.1. I
>>>>>> can't really see this seeping through in DefaultClassRealmManager, but
>>>>>> google shows me https://java.net/jira/browse/GLASSFISH-20802
>>>>>>
>>>>>> Is this something you understand ?
>>>>>>
>>>>>
>>>>> DefaultClassRealmManager currently exposes the complete
>>>>> javax.enterprise.inject package from CDI-API:
>>>>>
>>>>> imports.put( "javax.enterprise.inject.*", coreRealm );
>>>>>
>>>>> This package contains annotations, exceptions, and one interface - and
>>>>> it looks like the interface pulls in a type from javax.enterprise.util:
>>>>>
>>>>> http://docs.oracle.com/javaee/6/api/javax/enterprise/inject/
>>>>> Instance.html#select(javax.enterprise.util.TypeLiteral,%
>>>>> 20java.lang.annotation.Annotation...)
>>>>>
>>>>> Which means that while javax.enterprise.inject.Instance is loaded and
>>>>> exposed from the core realm, javax.enterprise.util.TypeLiteral will
>>>>> be loaded from core but not exposed - this is likely the cause of the
>>>>> constraint violation.
>>>>>
>>>>> There are two solutions - first we could narrow the exposure in
>>>>> DefaultClassRealmManager to:
>>>>>
>>>>> imports.put( "javax.enterprise.inject.Typed", coreRealm );
>>>>>
>>>>> since that is the only CDI annotation we're really interested in, and
>>>>> it has no dependencies to other types.
>>>>>
>>>>> Alternatively we could widen the exposure to include the
>>>>> javax.enterprise.util package:
>>>>>
>>>>> imports.put( "javax.enterprise.inject.*", coreRealm );
>>>>> imports.put( "javax.enterprise.util.*", coreRealm );
>>>>>
>>>>> which should also fix the loader constraint while not introducing
>>>>> other issues.
>>>>>
>>>>> WDYT?
>>>>>
>>>>> Kristian
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>>
>>>> Thanks,
>>>>
>>>> Jason
>>>>
>>>> ----------------------------------------------------------
>>>> Jason van Zyl
>>>> Founder, Apache Maven
>>>> http://twitter.com/jvanzyl
>>>> http://twitter.com/takari_io
>>>> ---------------------------------------------------------
>>>>
>>>> Selfish deeds are the shortest path to self destruction.
>>>>
>>>> -- The Seven Samuari, Akira Kurosawa
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>> Thanks,
>>
>> Jason
>>
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder, Apache Maven
>> http://twitter.com/jvanzyl
>> http://twitter.com/takari_io
>> ---------------------------------------------------------
>>
>> Simplex sigillum veri. (Simplicity is the seal of truth.)
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Linkage error
Posted by Igor Fedorenko <ig...@ifedorenko.com>.
Please keep @Typed annotation available outside of core.
I use @Typed annotation in one of my (private) core extensions where I
need a class to implement an interface but not make that interface
visible for injection in other components.
--
Regards,
Igor
On 2/13/2014, 9:43, Jason van Zyl wrote:
>
> On Feb 13, 2014, at 8:44 AM, Stuart McCulloch <mc...@gmail.com> wrote:
>
>> On 13 Feb 2014, at 13:30, Jason van Zyl <ja...@takari.io> wrote:
>>
>>> I would consider something like SFL4J as something which is now part of our API think it's fine to expose something like that. I'm not sure the same holds true for CDI. Wouldn't it be better just to completely hide it?
>>
>> As mentioned in http://wiki.eclipse.org/Sisu/PlexusMigration#Type_Override, the @javax.enterprise.inject.Typed annotation can be used to restrict the type visibility of components.
>>
>> Hiding this package means you wouldn’t be able to use this feature outside of Maven core - so I guess it depends whether you consider CDI’s @Typed part of the component API like JSR330’s @Inject.
>>
>
> I would say I don't consider it part of our API, so I'd be inclined to hide it and strictly stick to JSR330. Will Sisu not load without it? I think we keep running into these issues with App Servers because people are trying to run their App Server in Maven's runtime environment which doesn't really make sense. For any of these strange conflicts that arise with SLF4J or other APIs I think we should just encourage people to run any sort of test for your App Server with an environment akin to production in that you should fork once with your own classpath and whatever else you need. Maven's APIs and runtime environment are for build related activities. Where we have this cross over like like the jetty/tomcat/wildfly-maven-plugin I think we should just tell people the best thing to do is fork once and do what you like.
>
>> The CDI API is at least standardised (one of the reasons why the container respects @Typed rather than creating it’s own ad-hoc annotation which wouldn’t be as portable).
>>
>
> Why would we need it? You have any use cases at hand?
>
>>> On Feb 13, 2014, at 5:56 AM, Stuart McCulloch <mc...@gmail.com> wrote:
>>>
>>>> On 13 Feb 2014, at 07:28, Kristian Rosenvold <kr...@gmail.com> wrote:
>>>>
>>>>> Stuart,
>>>>>
>>>>> We're seeing java.lang.LinkageError: loader constraint violation: loader
>>>>> (instance of org/codehaus/plexus/classworlds/realm/ClassRealm) previously
>>>>> initiated loading for a different type with name
>>>>> "javax/enterprise/util/TypeLiteral" using the maven-jetty-plugin on 3.1. I
>>>>> can't really see this seeping through in DefaultClassRealmManager, but
>>>>> google shows me https://java.net/jira/browse/GLASSFISH-20802
>>>>>
>>>>> Is this something you understand ?
>>>>
>>>> DefaultClassRealmManager currently exposes the complete javax.enterprise.inject package from CDI-API:
>>>>
>>>> imports.put( "javax.enterprise.inject.*", coreRealm );
>>>>
>>>> This package contains annotations, exceptions, and one interface - and it looks like the interface pulls in a type from javax.enterprise.util:
>>>>
>>>> http://docs.oracle.com/javaee/6/api/javax/enterprise/inject/Instance.html#select(javax.enterprise.util.TypeLiteral,%20java.lang.annotation.Annotation...)
>>>>
>>>> Which means that while javax.enterprise.inject.Instance is loaded and exposed from the core realm, javax.enterprise.util.TypeLiteral will be loaded from core but not exposed - this is likely the cause of the constraint violation.
>>>>
>>>> There are two solutions - first we could narrow the exposure in DefaultClassRealmManager to:
>>>>
>>>> imports.put( "javax.enterprise.inject.Typed", coreRealm );
>>>>
>>>> since that is the only CDI annotation we’re really interested in, and it has no dependencies to other types.
>>>>
>>>> Alternatively we could widen the exposure to include the javax.enterprise.util package:
>>>>
>>>> imports.put( "javax.enterprise.inject.*", coreRealm );
>>>> imports.put( "javax.enterprise.util.*", coreRealm );
>>>>
>>>> which should also fix the loader constraint while not introducing other issues.
>>>>
>>>> WDYT?
>>>>
>>>>> Kristian
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>
>>> Thanks,
>>>
>>> Jason
>>>
>>> ----------------------------------------------------------
>>> Jason van Zyl
>>> Founder, Apache Maven
>>> http://twitter.com/jvanzyl
>>> http://twitter.com/takari_io
>>> ---------------------------------------------------------
>>>
>>> Selfish deeds are the shortest path to self destruction.
>>>
>>> -- The Seven Samuari, Akira Kurosawa
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> http://twitter.com/jvanzyl
> http://twitter.com/takari_io
> ---------------------------------------------------------
>
> Simplex sigillum veri. (Simplicity is the seal of truth.)
>
>
>
>
>
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Linkage error
Posted by Stuart McCulloch <mc...@gmail.com>.
On 13 Feb 2014, at 14:43, Jason van Zyl <ja...@takari.io> wrote:
> On Feb 13, 2014, at 8:44 AM, Stuart McCulloch <mc...@gmail.com> wrote:
>
>> On 13 Feb 2014, at 13:30, Jason van Zyl <ja...@takari.io> wrote:
>>
>>> I would consider something like SFL4J as something which is now part of our API think it's fine to expose something like that. I'm not sure the same holds true for CDI. Wouldn't it be better just to completely hide it?
>>
>> As mentioned in http://wiki.eclipse.org/Sisu/PlexusMigration#Type_Override, the @javax.enterprise.inject.Typed annotation can be used to restrict the type visibility of components.
>>
>> Hiding this package means you wouldn’t be able to use this feature outside of Maven core - so I guess it depends whether you consider CDI’s @Typed part of the component API like JSR330’s @Inject.
>
> I would say I don't consider it part of our API, so I'd be inclined to hide it and strictly stick to JSR330. Will Sisu not load without it?
Hiding this package disables the optional runtime support for @Typed, but does not affect other container features - the container will still load without it.
> I think we keep running into these issues with App Servers because people are trying to run their App Server in Maven's runtime environment which doesn't really make sense. For any of these strange conflicts that arise with SLF4J or other APIs I think we should just encourage people to run any sort of test for your App Server with an environment akin to production in that you should fork once with your own classpath and whatever else you need. Maven's APIs and runtime environment are for build related activities. Where we have this cross over like like the jetty/tomcat/wildfly-maven-plugin I think we should just tell people the best thing to do is fork once and do what you like.
>
>> The CDI API is at least standardised (one of the reasons why the container respects @Typed rather than creating it’s own ad-hoc annotation which wouldn’t be as portable).
>
> Why would we need it? You have any use cases at hand?
I don’t know if anything in Maven uses it at the moment, it’s mainly to aid migration from Plexus (which always restricted a component's type visibility to its specific role class) to the new JSR330 model where a component’s type visibility is open - ie. it’s visible as any type in its hierarchy - unless you use @Typed to limit it to specific roles. I have some examples where it was useful in migrating legacy Plexus applications, but nothing specific to Maven.
>>> On Feb 13, 2014, at 5:56 AM, Stuart McCulloch <mc...@gmail.com> wrote:
>>>
>>>> On 13 Feb 2014, at 07:28, Kristian Rosenvold <kr...@gmail.com> wrote:
>>>>
>>>>> Stuart,
>>>>>
>>>>> We're seeing java.lang.LinkageError: loader constraint violation: loader
>>>>> (instance of org/codehaus/plexus/classworlds/realm/ClassRealm) previously
>>>>> initiated loading for a different type with name
>>>>> "javax/enterprise/util/TypeLiteral" using the maven-jetty-plugin on 3.1. I
>>>>> can't really see this seeping through in DefaultClassRealmManager, but
>>>>> google shows me https://java.net/jira/browse/GLASSFISH-20802
>>>>>
>>>>> Is this something you understand ?
>>>>
>>>> DefaultClassRealmManager currently exposes the complete javax.enterprise.inject package from CDI-API:
>>>>
>>>> imports.put( "javax.enterprise.inject.*", coreRealm );
>>>>
>>>> This package contains annotations, exceptions, and one interface - and it looks like the interface pulls in a type from javax.enterprise.util:
>>>>
>>>> http://docs.oracle.com/javaee/6/api/javax/enterprise/inject/Instance.html#select(javax.enterprise.util.TypeLiteral,%20java.lang.annotation.Annotation...)
>>>>
>>>> Which means that while javax.enterprise.inject.Instance is loaded and exposed from the core realm, javax.enterprise.util.TypeLiteral will be loaded from core but not exposed - this is likely the cause of the constraint violation.
>>>>
>>>> There are two solutions - first we could narrow the exposure in DefaultClassRealmManager to:
>>>>
>>>> imports.put( "javax.enterprise.inject.Typed", coreRealm );
>>>>
>>>> since that is the only CDI annotation we’re really interested in, and it has no dependencies to other types.
>>>>
>>>> Alternatively we could widen the exposure to include the javax.enterprise.util package:
>>>>
>>>> imports.put( "javax.enterprise.inject.*", coreRealm );
>>>> imports.put( "javax.enterprise.util.*", coreRealm );
>>>>
>>>> which should also fix the loader constraint while not introducing other issues.
>>>>
>>>> WDYT?
>>>>
>>>>> Kristian
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>
>>> Thanks,
>>>
>>> Jason
>>>
>>> ----------------------------------------------------------
>>> Jason van Zyl
>>> Founder, Apache Maven
>>> http://twitter.com/jvanzyl
>>> http://twitter.com/takari_io
>>> ---------------------------------------------------------
>>>
>>> Selfish deeds are the shortest path to self destruction.
>>>
>>> -- The Seven Samuari, Akira Kurosawa
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> http://twitter.com/jvanzyl
> http://twitter.com/takari_io
> ---------------------------------------------------------
>
> Simplex sigillum veri. (Simplicity is the seal of truth.)
Re: Linkage error
Posted by Jason van Zyl <ja...@takari.io>.
On Feb 13, 2014, at 8:44 AM, Stuart McCulloch <mc...@gmail.com> wrote:
> On 13 Feb 2014, at 13:30, Jason van Zyl <ja...@takari.io> wrote:
>
>> I would consider something like SFL4J as something which is now part of our API think it's fine to expose something like that. I'm not sure the same holds true for CDI. Wouldn't it be better just to completely hide it?
>
> As mentioned in http://wiki.eclipse.org/Sisu/PlexusMigration#Type_Override, the @javax.enterprise.inject.Typed annotation can be used to restrict the type visibility of components.
>
> Hiding this package means you wouldn’t be able to use this feature outside of Maven core - so I guess it depends whether you consider CDI’s @Typed part of the component API like JSR330’s @Inject.
>
I would say I don't consider it part of our API, so I'd be inclined to hide it and strictly stick to JSR330. Will Sisu not load without it? I think we keep running into these issues with App Servers because people are trying to run their App Server in Maven's runtime environment which doesn't really make sense. For any of these strange conflicts that arise with SLF4J or other APIs I think we should just encourage people to run any sort of test for your App Server with an environment akin to production in that you should fork once with your own classpath and whatever else you need. Maven's APIs and runtime environment are for build related activities. Where we have this cross over like like the jetty/tomcat/wildfly-maven-plugin I think we should just tell people the best thing to do is fork once and do what you like.
> The CDI API is at least standardised (one of the reasons why the container respects @Typed rather than creating it’s own ad-hoc annotation which wouldn’t be as portable).
>
Why would we need it? You have any use cases at hand?
>> On Feb 13, 2014, at 5:56 AM, Stuart McCulloch <mc...@gmail.com> wrote:
>>
>>> On 13 Feb 2014, at 07:28, Kristian Rosenvold <kr...@gmail.com> wrote:
>>>
>>>> Stuart,
>>>>
>>>> We're seeing java.lang.LinkageError: loader constraint violation: loader
>>>> (instance of org/codehaus/plexus/classworlds/realm/ClassRealm) previously
>>>> initiated loading for a different type with name
>>>> "javax/enterprise/util/TypeLiteral" using the maven-jetty-plugin on 3.1. I
>>>> can't really see this seeping through in DefaultClassRealmManager, but
>>>> google shows me https://java.net/jira/browse/GLASSFISH-20802
>>>>
>>>> Is this something you understand ?
>>>
>>> DefaultClassRealmManager currently exposes the complete javax.enterprise.inject package from CDI-API:
>>>
>>> imports.put( "javax.enterprise.inject.*", coreRealm );
>>>
>>> This package contains annotations, exceptions, and one interface - and it looks like the interface pulls in a type from javax.enterprise.util:
>>>
>>> http://docs.oracle.com/javaee/6/api/javax/enterprise/inject/Instance.html#select(javax.enterprise.util.TypeLiteral,%20java.lang.annotation.Annotation...)
>>>
>>> Which means that while javax.enterprise.inject.Instance is loaded and exposed from the core realm, javax.enterprise.util.TypeLiteral will be loaded from core but not exposed - this is likely the cause of the constraint violation.
>>>
>>> There are two solutions - first we could narrow the exposure in DefaultClassRealmManager to:
>>>
>>> imports.put( "javax.enterprise.inject.Typed", coreRealm );
>>>
>>> since that is the only CDI annotation we’re really interested in, and it has no dependencies to other types.
>>>
>>> Alternatively we could widen the exposure to include the javax.enterprise.util package:
>>>
>>> imports.put( "javax.enterprise.inject.*", coreRealm );
>>> imports.put( "javax.enterprise.util.*", coreRealm );
>>>
>>> which should also fix the loader constraint while not introducing other issues.
>>>
>>> WDYT?
>>>
>>>> Kristian
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> Thanks,
>>
>> Jason
>>
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder, Apache Maven
>> http://twitter.com/jvanzyl
>> http://twitter.com/takari_io
>> ---------------------------------------------------------
>>
>> Selfish deeds are the shortest path to self destruction.
>>
>> -- The Seven Samuari, Akira Kurosawa
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
---------------------------------------------------------
Simplex sigillum veri. (Simplicity is the seal of truth.)
Re: Linkage error
Posted by Stuart McCulloch <mc...@gmail.com>.
On 13 Feb 2014, at 13:30, Jason van Zyl <ja...@takari.io> wrote:
> I would consider something like SFL4J as something which is now part of our API think it's fine to expose something like that. I'm not sure the same holds true for CDI. Wouldn't it be better just to completely hide it?
As mentioned in http://wiki.eclipse.org/Sisu/PlexusMigration#Type_Override, the @javax.enterprise.inject.Typed annotation can be used to restrict the type visibility of components.
Hiding this package means you wouldn’t be able to use this feature outside of Maven core - so I guess it depends whether you consider CDI’s @Typed part of the component API like JSR330’s @Inject.
The CDI API is at least standardised (one of the reasons why the container respects @Typed rather than creating it’s own ad-hoc annotation which wouldn’t be as portable).
> On Feb 13, 2014, at 5:56 AM, Stuart McCulloch <mc...@gmail.com> wrote:
>
>> On 13 Feb 2014, at 07:28, Kristian Rosenvold <kr...@gmail.com> wrote:
>>
>>> Stuart,
>>>
>>> We're seeing java.lang.LinkageError: loader constraint violation: loader
>>> (instance of org/codehaus/plexus/classworlds/realm/ClassRealm) previously
>>> initiated loading for a different type with name
>>> "javax/enterprise/util/TypeLiteral" using the maven-jetty-plugin on 3.1. I
>>> can't really see this seeping through in DefaultClassRealmManager, but
>>> google shows me https://java.net/jira/browse/GLASSFISH-20802
>>>
>>> Is this something you understand ?
>>
>> DefaultClassRealmManager currently exposes the complete javax.enterprise.inject package from CDI-API:
>>
>> imports.put( "javax.enterprise.inject.*", coreRealm );
>>
>> This package contains annotations, exceptions, and one interface - and it looks like the interface pulls in a type from javax.enterprise.util:
>>
>> http://docs.oracle.com/javaee/6/api/javax/enterprise/inject/Instance.html#select(javax.enterprise.util.TypeLiteral,%20java.lang.annotation.Annotation...)
>>
>> Which means that while javax.enterprise.inject.Instance is loaded and exposed from the core realm, javax.enterprise.util.TypeLiteral will be loaded from core but not exposed - this is likely the cause of the constraint violation.
>>
>> There are two solutions - first we could narrow the exposure in DefaultClassRealmManager to:
>>
>> imports.put( "javax.enterprise.inject.Typed", coreRealm );
>>
>> since that is the only CDI annotation we’re really interested in, and it has no dependencies to other types.
>>
>> Alternatively we could widen the exposure to include the javax.enterprise.util package:
>>
>> imports.put( "javax.enterprise.inject.*", coreRealm );
>> imports.put( "javax.enterprise.util.*", coreRealm );
>>
>> which should also fix the loader constraint while not introducing other issues.
>>
>> WDYT?
>>
>>> Kristian
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> http://twitter.com/jvanzyl
> http://twitter.com/takari_io
> ---------------------------------------------------------
>
> Selfish deeds are the shortest path to self destruction.
>
> -- The Seven Samuari, Akira Kurosawa
>
>
>
>
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Linkage error
Posted by Jason van Zyl <ja...@takari.io>.
I would consider something like SFL4J as something which is now part of our API think it's fine to expose something like that. I'm not sure the same holds true for CDI. Wouldn't it be better just to completely hide it?
On Feb 13, 2014, at 5:56 AM, Stuart McCulloch <mc...@gmail.com> wrote:
> On 13 Feb 2014, at 07:28, Kristian Rosenvold <kr...@gmail.com> wrote:
>
>> Stuart,
>>
>> We're seeing java.lang.LinkageError: loader constraint violation: loader
>> (instance of org/codehaus/plexus/classworlds/realm/ClassRealm) previously
>> initiated loading for a different type with name
>> "javax/enterprise/util/TypeLiteral" using the maven-jetty-plugin on 3.1. I
>> can't really see this seeping through in DefaultClassRealmManager, but
>> google shows me https://java.net/jira/browse/GLASSFISH-20802
>>
>> Is this something you understand ?
>
> DefaultClassRealmManager currently exposes the complete javax.enterprise.inject package from CDI-API:
>
> imports.put( "javax.enterprise.inject.*", coreRealm );
>
> This package contains annotations, exceptions, and one interface - and it looks like the interface pulls in a type from javax.enterprise.util:
>
> http://docs.oracle.com/javaee/6/api/javax/enterprise/inject/Instance.html#select(javax.enterprise.util.TypeLiteral,%20java.lang.annotation.Annotation...)
>
> Which means that while javax.enterprise.inject.Instance is loaded and exposed from the core realm, javax.enterprise.util.TypeLiteral will be loaded from core but not exposed - this is likely the cause of the constraint violation.
>
> There are two solutions - first we could narrow the exposure in DefaultClassRealmManager to:
>
> imports.put( "javax.enterprise.inject.Typed", coreRealm );
>
> since that is the only CDI annotation we’re really interested in, and it has no dependencies to other types.
>
> Alternatively we could widen the exposure to include the javax.enterprise.util package:
>
> imports.put( "javax.enterprise.inject.*", coreRealm );
> imports.put( "javax.enterprise.util.*", coreRealm );
>
> which should also fix the loader constraint while not introducing other issues.
>
> WDYT?
>
>> Kristian
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
---------------------------------------------------------
Selfish deeds are the shortest path to self destruction.
-- The Seven Samuari, Akira Kurosawa
Re: Linkage error
Posted by Kristian Rosenvold <kr...@gmail.com>.
Much as I hate leaking stuff like this, it would appear to me that
extending the import (alternative 2) is the correct thing to do.
Of course, if imports.put( "javax.enterprise.inject.Typed", coreRealm
); doesn't break any tests we could always start with that. I'll give it a
shot tonight.
Kristian
2014-02-13 11:56 GMT+01:00 Stuart McCulloch <mc...@gmail.com>:
> On 13 Feb 2014, at 07:28, Kristian Rosenvold <kr...@gmail.com>
> wrote:
>
> > Stuart,
> >
> > We're seeing java.lang.LinkageError: loader constraint violation: loader
> > (instance of org/codehaus/plexus/classworlds/realm/ClassRealm) previously
> > initiated loading for a different type with name
> > "javax/enterprise/util/TypeLiteral" using the maven-jetty-plugin on 3.1.
> I
> > can't really see this seeping through in DefaultClassRealmManager, but
> > google shows me https://java.net/jira/browse/GLASSFISH-20802
> >
> > Is this something you understand ?
>
> DefaultClassRealmManager currently exposes the complete
> javax.enterprise.inject package from CDI-API:
>
> imports.put( "javax.enterprise.inject.*", coreRealm );
>
> This package contains annotations, exceptions, and one interface - and it
> looks like the interface pulls in a type from javax.enterprise.util:
>
>
> http://docs.oracle.com/javaee/6/api/javax/enterprise/inject/Instance.html#select(javax.enterprise.util.TypeLiteral,%20java.lang.annotation.Annotation..
> .)
>
> Which means that while javax.enterprise.inject.Instance is loaded and
> exposed from the core realm, javax.enterprise.util.TypeLiteral will be
> loaded from core but not exposed - this is likely the cause of the
> constraint violation.
>
> There are two solutions - first we could narrow the exposure in
> DefaultClassRealmManager to:
>
> imports.put( "javax.enterprise.inject.Typed", coreRealm );
>
> since that is the only CDI annotation we're really interested in, and it
> has no dependencies to other types.
>
> Alternatively we could widen the exposure to include the
> javax.enterprise.util package:
>
> imports.put( "javax.enterprise.inject.*", coreRealm );
> imports.put( "javax.enterprise.util.*", coreRealm );
>
> which should also fix the loader constraint while not introducing other
> issues.
>
> WDYT?
>
> > Kristian
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Linkage error
Posted by Stuart McCulloch <mc...@gmail.com>.
On 13 Feb 2014, at 07:28, Kristian Rosenvold <kr...@gmail.com> wrote:
> Stuart,
>
> We're seeing java.lang.LinkageError: loader constraint violation: loader
> (instance of org/codehaus/plexus/classworlds/realm/ClassRealm) previously
> initiated loading for a different type with name
> "javax/enterprise/util/TypeLiteral" using the maven-jetty-plugin on 3.1. I
> can't really see this seeping through in DefaultClassRealmManager, but
> google shows me https://java.net/jira/browse/GLASSFISH-20802
>
> Is this something you understand ?
DefaultClassRealmManager currently exposes the complete javax.enterprise.inject package from CDI-API:
imports.put( "javax.enterprise.inject.*", coreRealm );
This package contains annotations, exceptions, and one interface - and it looks like the interface pulls in a type from javax.enterprise.util:
http://docs.oracle.com/javaee/6/api/javax/enterprise/inject/Instance.html#select(javax.enterprise.util.TypeLiteral,%20java.lang.annotation.Annotation...)
Which means that while javax.enterprise.inject.Instance is loaded and exposed from the core realm, javax.enterprise.util.TypeLiteral will be loaded from core but not exposed - this is likely the cause of the constraint violation.
There are two solutions - first we could narrow the exposure in DefaultClassRealmManager to:
imports.put( "javax.enterprise.inject.Typed", coreRealm );
since that is the only CDI annotation we’re really interested in, and it has no dependencies to other types.
Alternatively we could widen the exposure to include the javax.enterprise.util package:
imports.put( "javax.enterprise.inject.*", coreRealm );
imports.put( "javax.enterprise.util.*", coreRealm );
which should also fix the loader constraint while not introducing other issues.
WDYT?
> Kristian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org