I'd say they should both (all) work closely together.
If something affects more than one JSR, while this is rarely done in the
"umbrella" JSRs, maybe THIS spec might even be the best place, at least we
have to overlook and coordinate with all affected JSRs, EGs and Sped Leads.
Werner
On Mon, Oct 29, 2012 at 4:05 PM, Pete Muir <pmuir_at_bleepbleep.org.uk> wrote:
> Hi Antonio,
>
> I think this is perfectly achievable, technically. Each of these
> specifications could provide beans to inject the relevant objects in.
>
> However, I'm reluctant to start specifying this in the CDI spec, I would
> prefer that EJB, WS, Servlet etc. specified this. Otherwise CDI will just
> become a dumping ground for integrations...
>
> On 28 Oct 2012, at 09:21, Antonio Goncalves wrote:
>
> > Hi all,
> >
> > I'm coming back to this topic which I would like to broad a bit to :
> injecting context in general. At the moment we have to use @Resource to
> inject different types of context and other tricks in Servlets or JAX-RS :
> >
> >
> > On a SAOP Web Service :
> >
> > @WebService
> > public class MyWS {
> >
> > @Resource
> > private WebServiceContext context;
> > ...
> > }
> >
> >
> > In an EJB :
> >
> > @Stateless
> > public class MyEJB {
> >
> > @Resource
> > private SessionContext context;
> > ...
> > }
> >
> >
> > In a Servlet
> >
> > @WebServlet
> > public class MyServlet {
> >
> > private ServletContext context;
> >
> > protected void doGet(HttpServletRequest request, HttpServletResponse
> response) {
> > context = request.getContext();
> > }
> > ...
> > }
> >
> >
> > REST Service
> > We've already talked about @Context
> >
> > @Path("/resource")
> > public class MyResource {
> > @Context
> > private UriInfo info;
> > }
> >
> >
> >
> > Wouldn't it be clearer to unify all these injections with @Inject ?
> >
> > Antonio
> >
> >
> > On Thu, Oct 11, 2012 at 5:18 AM, Yoon Kyung Koo <
> kyungkoo_yoon_at_tmax.co.kr> wrote:
> > Hi, all.
> > Sorry for late feedback.
> > I think CDI is more and more important feature of Java EE and should be
> aligned with annotations in other SPECs.
> > Though there may be some backward compatibility issues, I prefer the
> option C.
> > And I have some concerns in annotations and CDI with respect to
> deployment performance.
> > I hope the annotation features can be more finely defined and can be
> scoped in view of the deployment performance in the future.
> >
> > --
> > --------------------
> > Software Innovation Evangelist
> > Researcher & Executive Director / WAS Lab / TmaxSoft R&D Center
> > PGP http://www.javadom.com/personal/yoonforhatgmaildotcom.asc
> >
> >
> >
> >
> > 2012. 9. 21., 오후 3:56, Bill Shannon <bill.shannon_at_oracle.com> 작성:
> >
> >>
> >> I've heard from a few of you on this, but I'd like to get feedback
> >> from the rest of the expert group. There's 20 people on this
> >> expert group, surely you all joined the expert group because you had
> >> opinions about Java EE, right? You wanted to help us direct the
> >> future of Java EE. You wanted to give us the benefit of your
> experience.
> >> If you just wanted to watch, you could've joined the users list instead
> >> of the expert group...
> >>
> >> Let's hear it! What do you guys think?!?
> >>
> >> (If you already responded to this thread, please resist the temptation
> >> to jump in again. Let's let the others have their say.)
> >>
> >> Thanks.
> >>
> >>
> >> Bill Shannon wrote on 08/30/2012 01:58 PM:
> >>> From many of our recent discussions, it seems clear that CDI is
> >>> becoming more central to the Java EE programming model. For example:
> >>>
> >>> - The expanded use of @Stereotype in my previous message.
> >>>
> >>> - The use of CDI interceptors to provide container managed
> >>> transaction support beyond EJB.
> >>>
> >>> - The potential future use of CDI interceptors to provide container
> >>> managed security support beyond EJB.
> >>>
> >>> - The use of CDI interceptors to support Bean Validation method
> >>> level validation.
> >>>
> >>> - The discussion of "implicit producers" to allow use of @Inject
> >>> instead of @Resource to inject Java EE resources.
> >>>
> >>> - The discussion around alignment of CDI managed beans and the
> >>> separate @ManagedBean spec.
> >>>
> >>> - The introduction of a transaction scope and its use in the JMS
> >>> spec to simplify the programming model.
> >>>
> >>> - The change being considered by the CDI expert group to enable
> >>> CDI by default, making it more attractive to use it for all
> >>> the items above.
> >>>
> >>>
> >>> At the same time we're finding that some specs, e.g., JAX-RS, are
> >>> hesitant to introduce a hard, or even soft, dependency on CDI,
> >>> instead insisting that all their new features must work in an
> >>> environment where there is no CDI.
> >>>
> >>> In many ways this parallels what we saw with annotations. In
> >>> the beginning we found many people who didn't want to use annotations
> >>> and wanted us to make sure everything worked without use of
> >>> annotations. Now we're seeing many things that *only* work with
> >>> annotations, and annotations are well accepted by Java EE developers.
> >>> I suppose there's a natural lifecycle to acceptance of new
> >>> technologies, and I wonder where we are in that lifecycle with CDI?
> >>> Has CDI become a mature and accepted technology that we should use
> >>> widely?
> >>>
> >>>
> >>> I'd like to get a sense from this group as to what direction we
> >>> should provide to all the Java EE specs in regards to their use
> >>> of CDI. Here's a few obvious options:
> >>>
> >>> A. Technologies that see a significant standalone (non-Java EE) use
> >>> should be fully functional without CDI. If necessary, any
> >>> required features that are similar to CDI features should be
> >>> defined and implemented in a way that doesn't depend on CDI.
> >>>
> >>> B. Technologies should provide all major features in a way that
> >>> works without CDI. Some features may also be provided in a
> >>> different way that works well with CDI. Some less essential
> >>> features may only work with CDI. The implementation should
> >>> only have a soft dependency on CDI at most.
> >>>
> >>> C. Technologies should provide features that work well with CDI
> >>> without duplicating any functionality in CDI. Use CDI wherever
> >>> it fits. The implementation may have a hard dependency on CDI
> >>> and may require CDI even when used in a standalone environment.
> >>>
> >>> I'm sure you can think of other options as well.
> >>>
> >>> What advice do you think we should give to other Java EE specs?
> >>>
> >>
> >
> >
> >
> >
> > --
> > Antonio Goncalves
> > Software architect and Java Champion
> >
> > Web site | Twitter | LinkedIn | Paris JUG | Devoxx France
>
>