My $0.02 is that it's worth the effort to evolve JSR-330 for the community
as a whole. I've been on projects where they tend to use those annotations
even in a CDI environment, and it makes it much easier to switch between
Spring and CDI if necessary.
On Wed, Jul 2, 2014 at 4:43 PM, Antoine Sabot-Durand <
antoine(a)sabot-durand.net> wrote:
Hi all,
Since the first mention of CDI 2.0 preparation work, we've received a lot
of comment about JSR 330 evolution. With the release of the proposal draft
yesterday, this topic came up again. So let me give my point of view on
this subject to have an open discussion here.
When we started to discuss about modularity with Pete in last november, my
first idea was to go see what we could add in JSR 330 to make it a true
specification that could be the first module of CDI. My idea at that time
was to discuss with JSR 330 owner to see if we could bring basic concept we
have in CDI to AtInject spec. In my mind the main features would have been:
- Enhance the javax.inject.Provider<T> interface to bring it at the same
level than javax.enterprise.inject.Instance<T>. That would have included
support for AnnotationLiteral and TypeLiteral as well
- Add a Container interface (a very light BeanManger) in JSR 330 to be
able to resolve beans instance from outside managed beans
- Add a mechanism to get this Container from non managed beans (like we
get access to BeanManager from JNDI or CDI class)
At that time, I contacted Bob Lee without success (didn't tried Pivotal
since I don't have contact there). I checked with JCP what could be done if
we'd like to see an evolution of JSR 330 and the owner doesn't care, there
seems to have solutions but I let it aside since we were in the middle of
CDI 1.2 MR at that time.
Today I'm a bit torn about this point. Working on opening JSR 330 could be
like opening pandora box, since I see 2 scenarios :
1) former JSR 330 owners wake up and are ok to get for a new spec version
they lead:
Knowing the history of JSR 330 vs JSR 299 I'm not sure everything we'd
need would be heard and even if the people leading this would be
cooperative, a lot of discussion and negotiation would be needed to be sure
that this new AtInject wouldn't contain features incompatible with CDI. So
it'd be very time consuming with no guarantee to get what we'd need at the
end.
2) former JSR 330 owner don't mind others take ownership of their spec to
enhance it and we (Red Hat) are the one to take this ownership to secure
CDI:
The best solution to minimize risk. But leading a new specification is a
lot more work than just deciding that we have a specific basic inject <<
part >> in CDI 2.0. Leading a spec is very time consuming, so it could be
better on the paper but will impact CDI 2.0 new features.
To sum up, as a Java EE user (like I have been for 10 years) I'd be happy
to see this (scenario 2), but as CDI spec lead I fear that it could lead us
in a trap (going to scenario 1 or consuming precious time on AtInject+1
instead of CDI 2.0)
Your input, solutions or comment would be appreciated on this point.
Antoine
_______________________________________________
cdi-dev mailing list
cdi-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev