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_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
>
>
--
Antonio Goncalves
Software architect and Java Champion
Web site <http://www.antoniogoncalves.org> |
Twitter<http://twitter.com/agoncal>|
LinkedIn <http://www.linkedin.com/in/agoncal> | Paris
JUG<http://www.parisjug.org> |
Devoxx France <http://www.devoxx.fr>