Skip to main content

[javaee-spec users] [jsr342-experts] Re: Re: CDI positioning

  • From: Antonio Goncalves <antonio.goncalves@...>
  • To: jsr342-experts@...
  • Subject: [javaee-spec users] [jsr342-experts] Re: Re: CDI positioning
  • Date: Mon, 29 Oct 2012 19:53:47 +0100
  • List-id: <jsr342-experts.javaee-spec.java.net>

Pete, I hope Java EE is the right place to have integration between specs rather than CDI. But what I can see is that Java EE does not mandate on other specs. JAX-WS could be update with Bean Validation, interception and @Inject. But without the spec lead working with us, there is not much we can do :o(

On Mon, Oct 29, 2012 at 4:05 PM, Pete Muir <pmuir@...> 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@...> 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@...> 작성:
>
>>
>> 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




--
Antonio Goncalves
Software architect and Java Champion

Web site | TwitterLinkedInParis JUG | Devoxx France


[javaee-spec users] [jsr342-experts] Re: Re: CDI positioning

Yoon Kyung Koo 10/11/2012

[javaee-spec users] [jsr342-experts] Re: Re: CDI positioning

Antonio Goncalves 10/28/2012

[javaee-spec users] [jsr342-experts] Re: Re: CDI positioning

Pete Muir 10/29/2012

[javaee-spec users] [jsr342-experts] Re: Re: CDI positioning

Werner Keil 10/29/2012

[javaee-spec users] [jsr342-experts] Re: Re: CDI positioning

Antonio Goncalves 10/29/2012
 
 
Close
loading
Please Confirm
Close