On Feb 13, 2014, at 8:44 AM, Stuart McCulloch <mccu...@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 <mccu...@gmail.com> wrote: >> >>> On 13 Feb 2014, at 07:28, Kristian Rosenvold <kristian.rosenv...@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-unsubscr...@maven.apache.org >>> For additional commands, e-mail: dev-h...@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-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@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.)
