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 <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>