[JBoss JIRA] (CDI-16) Improve EE 6 Managed Bean integration
by hantsy bai (JIRA)
[ https://issues.jboss.org/browse/CDI-16?page=com.atlassian.jira.plugin.sys... ]
hantsy bai commented on CDI-16:
-------------------------------
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());
}
}
> Improve EE 6 Managed Bean integration
> -------------------------------------
>
> Key: CDI-16
> URL: https://issues.jboss.org/browse/CDI-16
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Java EE integration
> Affects Versions: 1.0
> Reporter: Pete Muir
> Fix For: TBD
>
>
> Try to work out if we can improve on this.
> At least, we should clarify what happens if a CDI managed bean is annotated with @ManagedBean
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 7 months
[JBoss JIRA] (CDI-16) Improve EE 6 Managed Bean integration
by hantsy bai (JIRA)
[ https://issues.jboss.org/browse/CDI-16?page=com.atlassian.jira.plugin.sys... ]
hantsy bai edited comment on CDI-16 at 9/2/12 9:30 PM:
-------------------------------------------------------
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.
I think the matrix 2 is clear. I like the two classes solution.
1. the first level, the bean is injectable, has own scope. such EJB, basic Pojo(annotated with @ManagedBean), @Named etc.
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)?
...
@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 a developer I only want to simplify programming, but do not want to change their lifecyle.
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{
//@Inject is NOT supported,
}
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.
Regards
Hantsy
was (Author: hantsy):
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.
I think the matrix 2 is clear. I like the two classes solution.
1. the first level, the bean is injectable, has own scope. such EJB, basic Pojo(annotated with @ManagedBean), @Named etc.
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)?
...
@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 a developer I only want to simplify programming, but do not want to change their lifecyle.
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{
//@Inject is NOT supported,
}
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.
Regards
Hantsy
> Improve EE 6 Managed Bean integration
> -------------------------------------
>
> Key: CDI-16
> URL: https://issues.jboss.org/browse/CDI-16
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Java EE integration
> Affects Versions: 1.0
> Reporter: Pete Muir
> Fix For: TBD
>
>
> Try to work out if we can improve on this.
> At least, we should clarify what happens if a CDI managed bean is annotated with @ManagedBean
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 7 months
[JBoss JIRA] (CDI-16) Improve EE 6 Managed Bean integration
by hantsy bai (JIRA)
[ https://issues.jboss.org/browse/CDI-16?page=com.atlassian.jira.plugin.sys... ]
hantsy bai commented on CDI-16:
-------------------------------
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.
I think the matrix 2 is clear. I like the two classes solution.
1. the first level, the bean is injectable, has own scope. such EJB, basic Pojo(annotated with @ManagedBean), @Named etc.
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)?
...
@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 a developer I only want to simplify programming, but do not want to change their lifecyle.
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{
//@Inject is NOT supported,
}
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.
Regards
Hantsy
> Improve EE 6 Managed Bean integration
> -------------------------------------
>
> Key: CDI-16
> URL: https://issues.jboss.org/browse/CDI-16
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Java EE integration
> Affects Versions: 1.0
> Reporter: Pete Muir
> Fix For: TBD
>
>
> Try to work out if we can improve on this.
> At least, we should clarify what happens if a CDI managed bean is annotated with @ManagedBean
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 7 months
[JBoss JIRA] (CDI-20) @Observes(propagate = false) - stop event propagation after being handled by an observer
by Jens Schumann (JIRA)
[ https://issues.jboss.org/browse/CDI-20?page=com.atlassian.jira.plugin.sys... ]
Jens Schumann commented on CDI-20:
----------------------------------
I personally would love to see more something like Provider<X> or Instance<X>, which is way more consistent to the current CDI/@Inject behavior. Due to the catch/solder merge I was unable to find "catch".
So I would go for something like
public void onEvent(@Observes @QualifierA @QualifierB EventTarget<X> event) {
}
where the (name TBD) "EventTarget" interface allows me to stop event propagation and access the event payload. EventTarget is obviously not right name though.
> @Observes(propagate = false) - stop event propagation after being handled by an observer
> ----------------------------------------------------------------------------------------
>
> Key: CDI-20
> URL: https://issues.jboss.org/browse/CDI-20
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Events
> Affects Versions: 1.0
> Environment: any
> Reporter: Walter White
> Fix For: TBD
>
>
> I would like to have the ability to stop event propagation after it is handled by any observer only for certain situations. Is it possible to add a property to the annotation indicating whether the propagation should continue after being handled by the observer? Alternatively, would it be more concise to add a qualifier annotation which specifies the propagation.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 7 months
[JBoss JIRA] (CDI-17) Change name of the @Observes Reception attribute to "notified"
by Jens Schumann (JIRA)
[ https://issues.jboss.org/browse/CDI-17?page=com.atlassian.jira.plugin.sys... ]
Jens Schumann commented on CDI-17:
----------------------------------
I believe there is no way to fix this anymore. Should be better closed as 'won't fix' since it will break backwards compatibility.
> Change name of the @Observes Reception attribute to "notified"
> --------------------------------------------------------------
>
> Key: CDI-17
> URL: https://issues.jboss.org/browse/CDI-17
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Javadoc and API
> Affects Versions: 1.0
> Reporter: Dan Allen
> Priority: Minor
> Fix For: TBD
>
>
> As of the CDI 1.0 specification, the name of the Reception attribute on @Observes is "receive". The patch release of the API (SP1) changes the name to "notifyObserver", so a change is already being considered. Therefore, I'd like to suggest a better name that would read more fluently. That name is "notified".
> Let us compare the three cases:
> 1. @Observes(receive = IF_EXISTS)
> 2. @Observes(notifyObserver = IF_EXISTS)
> 3. @Observes(notified = IF_EXISTS)
> Of the three, notifyObserver breaks the flow of the sentence the most. On the other hand, notified reads nicely, including with the TransactionPhase attribute included:
> @Observes(notified = IF_EXISTS, during = TransactionPhase.AFTER_SUCCESS)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 7 months
[JBoss JIRA] (CDI-43) Allow Extensions to specify the annotations that they are interested in
by Jozef Hartinger (JIRA)
[ https://issues.jboss.org/browse/CDI-43?page=com.atlassian.jira.plugin.sys... ]
Jozef Hartinger commented on CDI-43:
------------------------------------
I wonder if this could be implemented as a qualifier taking advantage of CDI-234 outcome. The container would then appear to be firing PAT with @WithAnnotations() qualifier that would contain every annotation found on the type and the observer method would be filtering PAT events using the qualifier. Of course, this would still allow container to optimize and do not actually fire all the events nor enumerate all the annotations of the type. However, from the extension developer perspective using existing concept - qualifiers - would be more natural than introducing a special annotation.
However, this would require CDI-234 resolved with support for non-standard array comparison where the required and provided qualifier would be distinguished - array comparison would be asymmetric (e.g. a value of a array member value of a required qualifier is a subset of the value of the matching member of the event qualifier)
> Allow Extensions to specify the annotations that they are interested in
> -----------------------------------------------------------------------
>
> Key: CDI-43
> URL: https://issues.jboss.org/browse/CDI-43
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Portable Extensions
> Affects Versions: 1.0
> Reporter: Stuart Douglas
> Assignee: Pete Muir
> Fix For: 1.1.PRD
>
>
> Currently portable extensions that wish to look for a specific annotation have to look through all availible classes in the ProcessAnnotatatedType event, which is quite inefficient. It would be good if extensions could do something like:
> public void processAnnotatedType(@Observes @RequireAnnotations({(a)Unwraps.class}) ProcessAnnotatedType pat)
> This could allow the container to take advantage of annotation indexing to improve boot time performance, as well as reducing uneeded processing in the observer.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 7 months