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