[JBoss JIRA] Commented: (CDI-33) fire ProcessAnnotatedType for AnnotatedTypes added via BBD.addAnnotatedType()
by Jozef Hartinger (JIRA)
[ https://issues.jboss.org/browse/CDI-33?page=com.atlassian.jira.plugin.sys... ]
Jozef Hartinger commented on CDI-33:
------------------------------------
Pete, I believe you ment
{code:JAVA}
interface ProcessSyntheticAnnotatedType extends ProcessAnnotatedType {
Extension getSource();
}
{code}
> fire ProcessAnnotatedType for AnnotatedTypes added via BBD.addAnnotatedType()
> -----------------------------------------------------------------------------
>
> Key: CDI-33
> URL: https://issues.jboss.org/browse/CDI-33
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Portable Extensions
> Affects Versions: 1.0
> Reporter: Jozef Hartinger
> Assignee: Pete Muir
> Priority: Minor
> Fix For: 1.1 (Confirmed)
>
>
> Currently, the ProcessAnnotatedType event is fired for AnnotatedTypes discovered in a BDA only. However, portable extensions are allowed to register other AnnotatedTypes using addAnnotatedType() during the BeforeBeanDiscovery phase. For these AnnotatedTypes, the ProcessAnnotatedType event is not fired.
> However, an extension A may register an AnnotatedType X via addAnnotatedType() and an extension B might want to react on the presence of AnnotatedType X. Therefore, it would be great to have the ProcessAnnotatedType fired also for AnnotatedTypes registered programatically in the BeforeBeanDiscovery phase.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 10 months
[JBoss JIRA] Updated: (CDI-33) fire ProcessAnnotatedType for AnnotatedTypes added via BBD.addAnnotatedType()
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-33?page=com.atlassian.jira.plugin.sys... ]
Pete Muir updated CDI-33:
-------------------------
Assignee: Pete Muir
Fix Version/s: 1.1 (Confirmed)
(was: 1.1 (Proposed))
Priority: Minor (was: Major)
> fire ProcessAnnotatedType for AnnotatedTypes added via BBD.addAnnotatedType()
> -----------------------------------------------------------------------------
>
> Key: CDI-33
> URL: https://issues.jboss.org/browse/CDI-33
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Portable Extensions
> Affects Versions: 1.0
> Reporter: Jozef Hartinger
> Assignee: Pete Muir
> Priority: Minor
> Fix For: 1.1 (Confirmed)
>
>
> Currently, the ProcessAnnotatedType event is fired for AnnotatedTypes discovered in a BDA only. However, portable extensions are allowed to register other AnnotatedTypes using addAnnotatedType() during the BeforeBeanDiscovery phase. For these AnnotatedTypes, the ProcessAnnotatedType event is not fired.
> However, an extension A may register an AnnotatedType X via addAnnotatedType() and an extension B might want to react on the presence of AnnotatedType X. Therefore, it would be great to have the ProcessAnnotatedType fired also for AnnotatedTypes registered programatically in the BeforeBeanDiscovery phase.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 10 months
CDI-33: Firing ProcessAnnotatedType events for types added by BeforeBeanDiscovery.addAnnotatedType()
by Pete Muir
https://issues.jboss.org/browse/CDI-33
Another proposal for review. The spec does not require that a CDI impl fire a PAT event for types added by BBD.addAnnotatedType() -- it explicitly talks about only firing PAT events for types discovered.
This clearly needs fixing for CDI 1.1, and I think it is important to differentiate between types discovered, and types added, not least so that people can restore CDI 1.0 behavior with minimal fuss. I would propose we use polymorphism to provide this, by adding an interface
interface ProcessSyntheticAnnotatedType extends AnnotatedType {
Extension getSource();
}
A ProcessSyntheticAnnotatedType event would be fired for every AnnotatedType added viaBeforeBeanDiscovery.addAnnotatedType(). This event must be fired after BeforeBeanDiscovery and before the container starts creating beans (IOW at the same time other ProcessAnnotatedType events are fired). The getSource method would return the extension instance which called BBD.addAnnotatedType.
WDYT?
Pete
13 years, 10 months
[JBoss JIRA] Commented: (CDI-33) fire ProcessAnnotatedType for AnnotatedTypes added via BBD.addAnnotatedType()
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-33?page=com.atlassian.jira.plugin.sys... ]
Pete Muir commented on CDI-33:
------------------------------
h1. Proposal
Add this interface
{code}
interface ProcessSyntheticAnnotatedType extends AnnotatedType {
Extension getSource();
}
{code}
A {{ProcessSyntheticAnnotatedType}} event would be fired for every {{AnnotatedType}} added via {{BeforeBeanDiscovery.addAnnotatedType()}}. This event must be fired after {{BeforeBeanDiscovery}} and before the container starts creating beans (IOW at the same time other {{ProcessAnnotatedType}} events are fired). The {{getSource}} method would return the extension instance which called {{BBD.addAnnotatedType}}.
> fire ProcessAnnotatedType for AnnotatedTypes added via BBD.addAnnotatedType()
> -----------------------------------------------------------------------------
>
> Key: CDI-33
> URL: https://issues.jboss.org/browse/CDI-33
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Portable Extensions
> Affects Versions: 1.0
> Reporter: Jozef Hartinger
> Fix For: 1.1 (Proposed)
>
>
> Currently, the ProcessAnnotatedType event is fired for AnnotatedTypes discovered in a BDA only. However, portable extensions are allowed to register other AnnotatedTypes using addAnnotatedType() during the BeforeBeanDiscovery phase. For these AnnotatedTypes, the ProcessAnnotatedType event is not fired.
> However, an extension A may register an AnnotatedType X via addAnnotatedType() and an extension B might want to react on the presence of AnnotatedType X. Therefore, it would be great to have the ProcessAnnotatedType fired also for AnnotatedTypes registered programatically in the BeforeBeanDiscovery phase.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 10 months
[JBoss JIRA] Commented: (CDI-33) fire ProcessAnnotatedType for AnnotatedTypes added via BBD.addAnnotatedType()
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-33?page=com.atlassian.jira.plugin.sys... ]
Pete Muir commented on CDI-33:
------------------------------
h1. Proposal
Add this interface
{code}
interface ProcessSyntheticAnnotatedType extends AnnotatedType {
Extension getSource();
}
{code}
A {{ProcessSyntheticAnnotatedType}} event would be fired for every {{AnnotatedType}} added via {{BeforeBeanDiscovery.addAnnotatedType()}}. This event must be fired after {{BeforeBeanDiscovery}} and before the container starts creating beans (IOW at the same time other {{ProcessAnnotatedType}} events are fired). The {{getSource}} method would return the extension instance which called {{BBD.addAnnotatedType}}.
> fire ProcessAnnotatedType for AnnotatedTypes added via BBD.addAnnotatedType()
> -----------------------------------------------------------------------------
>
> Key: CDI-33
> URL: https://issues.jboss.org/browse/CDI-33
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Portable Extensions
> Affects Versions: 1.0
> Reporter: Jozef Hartinger
> Fix For: 1.1 (Proposed)
>
>
> Currently, the ProcessAnnotatedType event is fired for AnnotatedTypes discovered in a BDA only. However, portable extensions are allowed to register other AnnotatedTypes using addAnnotatedType() during the BeforeBeanDiscovery phase. For these AnnotatedTypes, the ProcessAnnotatedType event is not fired.
> However, an extension A may register an AnnotatedType X via addAnnotatedType() and an extension B might want to react on the presence of AnnotatedType X. Therefore, it would be great to have the ProcessAnnotatedType fired also for AnnotatedTypes registered programatically in the BeforeBeanDiscovery phase.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 10 months
[JBoss JIRA] Commented: (CDI-136) Assumption all @Stateful beans should be passivation capable
by David Blevins (JIRA)
[ https://issues.jboss.org/browse/CDI-136?page=com.atlassian.jira.plugin.sy... ]
David Blevins commented on CDI-136:
-----------------------------------
That's perfect, Pete.
> Assumption all @Stateful beans should be passivation capable
> ------------------------------------------------------------
>
> Key: CDI-136
> URL: https://issues.jboss.org/browse/CDI-136
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Beans, Java EE integration
> Affects Versions: 1.0
> Reporter: David Blevins
> Assignee: Pete Muir
> Fix For: 1.1 (Confirmed)
>
>
> Stateful session beans in transactions can't be passivated and shouldn't have passivation requirements either, like request scope.
> Stateful beans can be any scope. They are the Bertie Bott's Every Flavor Beans of EJB. It's too big of a brush to say that passivation is always required. That's the part we need to fix.
> Stateful session beans that do passivate are pretty rare. They should be assumed to be @NormalScope unless otherwise specified.
> The user should be able to say if they want passivation validation on their stateful bean and dependencies.
> We should at a minimum change the related language of the spec to be "For every bean which declares a passivating scope, and for every stateful session bean ***that requires passivation***, " and discuss how to determine that an SFSB requires passivation.
> From the EJB perspective this has always been a container detail, but we could have a rule in CDI that states the checks are not enforced unless the bean class explicitly implements java.io.Serializable. Alternatively we could make a generic @PassivationScoped annotation for other architectures that have flexible scopes and support passivation concepts.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 10 months