Hi Hantsy
On 12 Sep 2012, at 09:16, <hantsy_at_live.cn> <hantsy_at_live.cn> wrote:
> I noticed there is a topic in the expert mail list,
>
> http://java.net/projects/javaee-spec/lists/jsr342-experts/archive/2012-
> 03/message/74
>
> As an end developer, I only want to express my idea here.
>
> Currently I dislike CDI treat all classes(which has a constructor with
> no arguments) as CDI managed bean, I know Jboss Solder provides a @Veto
> to resolve this issue.
@Vetoed has been added to CDI 1.1 :-)
It can be used on package-info.java as well to ignore a package.
We are also looking at adding scanning control to the beans.xml deployment descriptor.
>
> I think the matrix 2 is clear. I like the two classes solution.
I agree.
>
> 1. the first level, the bean is injectable, has own scope. such EJB,
> basic Pojo(annotated with @ManagedBean), @Named etc.
AIUI you are asking that CDI not consider all classes as managed beans, but solely those with a an annotation? If so, this can't be done in a backwards compatible way in CDI, so we would need to look at either:
a) optionally turning this mode on
b) some other way to achieve the same e.g. adding explicit binding like Guice.
>
> And other bean such as EJB can improve the lifecyle support
> transaction, security etc.
>
> Compare to spring framework, it provides @Component, and @Controller,
> @Service etc. but the later are refined from the @Component.
> Why the @Named, @EJB can not be refined to use @ManagedBean(JEE)?
I don't understand the benefit of this?
>
> ...
> @ManagedBean
> .....
> interface @Named{
> }
>
> ...
> @ManagedBean
> .....
> interface @Stateful{
> }
>
> 2. such as entity listener, faces converter, faces validator, bean
> validator, servlet & servlet listener, filter, etc, can inject other
> beans.
>
> For example, it should allow us inject EmtityManager in faces
> conventer.
>
> But it can NOT be injected in other bean, and can NOT be defined in its
> own scope.
>
> In fact, as an end developer I only want to simplify programming, but
> do not want to change their lifecyle.
I agree here.
>
> But besides the CDI interceptors, decorators, I think it should be
> optional, developer can select if use CDI to manage it.
>
> For the 2, is there a better solution to make it managed? Spring
> provides another @Configurable. In JEE 7, the jee7 expert group can
> consider a similar solution, for example, provides a @Managed
> annotation to improve the lifecyle.
>
> @WebServlet
> @Managed
> class MyServlet extends HttpServlet{ //you can use @Inject now, }
>
> if it is not annotated with @Managed...it is no relation to CDI, only a
> generic servlet.
>
> @WebServlet
> class MyServlet extends HttpServlet{ //_at_Inject is NOT supported, }
I'm not sure of the benefit of this? Can you elaborate why you like this mode?
>
> This maybe force the different spec providers leave some space for the
> CDI hooks in their lifecycle.
>
> In summary, I hope all JEE specs looks smooth and seamless to
> developers.
>
> Additionally, the @Entity, I can use @PostLoad, etc. I think it is can
> also be managed when JPA process the jpa lifecyle, sush as persist,
> merge etc.
>
> @Entity
> @Managed
> class MyEntity{
>
> ......
> @Inject Entitymanager em;
>
> @Inject @Loggedin User currentUser;
>
> ......
> @Prepersist
> public void prepersist(){
> setCreatedBy(currentUser);
> setCreatedOn(new Date());
> }
>
> }