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 <i...@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 <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.) >> >> >> >> >> >> >> >> >> >> >> > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
