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