[JBoss JIRA] Updated: (CDI-27) Support declarative transactions on managed beans
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-27?page=com.atlassian.jira.plugin.sys... ]
Pete Muir updated CDI-27:
-------------------------
Issue Type: Tracker (was: Feature Request)
Assignee: Pete Muir
Fix Version/s: 1.1 (Confirmed)
(was: 1.1 (Proposed))
This issue will be handled by the EJB EG, likely by extracting transactional capabilities out of the EJB spec into a shared document (like interceptors).
This issue is now just a tracking issue, in place to keep the CDI community up to date on plans. I will provide any updates on this issue, for example when a draft of the proposal is available.
> Support declarative transactions on managed beans
> -------------------------------------------------
>
> Key: CDI-27
> URL: https://issues.jboss.org/browse/CDI-27
> Project: CDI Specification Issues
> Issue Type: Tracker
> Components: Java EE integration
> Affects Versions: 1.0
> Reporter: Pete Muir
> Assignee: Pete Muir
> Fix For: 1.1 (Confirmed)
>
>
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 10 months
Fwd: [jsr338-experts] Integration of EntityListeners Classes with CDI (Java EE 7)
by Pete Muir
FYI
Begin forwarded message:
> From: Pete Muir <pmuir(a)redhat.com>
> Date: 21 June 2011 14:53:57 GMT+01:00
> To: Werner Keil <werner.keil(a)gmail.com>
> Cc: users(a)javaee-spec.java.net
> Subject: Re: [jsr338-experts] Integration of EntityListeners Classes with CDI (Java EE 7)
>
> Thanks Werner. I'll forward to the CDI EG (address is cdi-dev(a)lists.jboss.org).
>
> I don't think you should be able to make an EntityListener into a bean, as the listener is stateless, there is little point in being able to inject it into another bean. Instead, I would propose that EntityListeners are simply added to the list of Java EE components which are able to be injected. This means they can be injected, but are not available for injection into other components.
>
> On 21 Jun 2011, at 14:48, Werner Keil wrote:
>
>> Forwarding it to other aliases and Pete (although there must be a CDI 1.1 alias by now, too<347.gif>)
>>
>> ---------- Forwarded message ----------
>> From: Adam Bien <abien(a)adam-bien.com>
>> Date: Tue, Jun 21, 2011 at 5:48 PM
>> Subject: [jsr338-experts] Integration of EntityListeners Classes with CDI (Java EE 7)
>> To: jsr338-experts(a)jpa-spec.java.net
>>
>>
>> Hi *
>>
>> EntityListeners should be integrated with CDI / EJB 3.2. It means: Java EE 7 DI should work in EntityListener classes. An EntityListener could be annotated with @Singleton / @Stateless / @RequestScoped etc. (everything what is stateless)
>>
>> We should extend the sentence: "Entity listeners are stateless. The lifecycle of an entity listener is unspecified" at the page 95 of the Expert Group Draft 2. to "The lifecycle of an entity listener is unspecified in unmanaged environments. An EJB 3.2 @Stateless, @Singleton or CDI managed bean can also receive callback events",
>>
>> What do you think?
>>
>> adam
>>
>>
>>
>> --
>> Werner Keil | UOMo Lead | Eclipse Foundation | Agile Coach, Principal Consultant | emergn limited
>> 590 Madison Avenue. New York. NY 10022 | 68 Lombard Street. London EC3V 9LJ UK
>> US Toll Free: +1-877.964.1981 | Worldwide Toll Free: +800.225.53482
>> Twitter @wernerkeil | Skype: werner.keil | www.emergn.com | Reshaping IT
>>
>
12 years, 10 months
[JBoss JIRA] Updated: (CDI-136) Assumption all @Stateful beans should be passivation capable
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-136?page=com.atlassian.jira.plugin.sy... ]
Pete Muir updated CDI-136:
--------------------------
Assignee: Pete Muir
Fix Version/s: 1.1 (Confirmed)
(was: 1.1 (Proposed))
> 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
12 years, 10 months
CDI-127: Support for Enums
by Pete Muir
https://issues.jboss.org/browse/CDI-127
I have written up a proposal for how to add support for enums:
================================================
Notes
-------
Enums are somewhat different to normal classes, as Java guarantees that any instances are singletons. Therefore we cannot treat them as classes. Furthermore, do we want to support them as beans, allowing them to be injected?
Differences are:
* No callback on instantiation, when do we inject?
* Shared between deployments as singletons, how do we handle dependent scoped injections?
* We do not control instantiation, cannot perform constructor injection
Proposal
------------
We should support enums as non-contextual objects, performing field and method injection only. Enums should be assumed to be injected only after the application is fully initialized for portability.
If an enum is on a shared classloader, any injections should correctly resolve to the deployment of the calling context. In other words, if a shared library or installed library has an enum A:
enum A {
FOO, BAR;
@Inject B b;
String getName() {
return b.name;
}
}
where B is a class defined in the shared library
@ApplicationScoped
class B {
String name;
}
Then assuming that the name has been set to Pete in deployment 1, and Marius in deployment 2, when the enum A is used in deployment 1, the method getName() should return Pete, and in deployment 2 it should return Marius.
================================================
In my opinion, it's fairly obvious that supporting only field and method injection for enums makes sense, as does injecting them at application startup. This proposal also won't allow you to inject enum instances into other beans (this seems to go against the point of enums to me).
How we handle enums in shared libraries (as the instances are shared between all apps then) is tricker, and the only way I can see to handle this is to
a) say this results in non-portable behavior - punt on it
b) require that the container can bridge to the correct calling context
I believe it's possible to implement (b) in a non-pathological fashion, but would love to hear from Stuart, Siva, and the OWB team on how this would work for JBoss AS, GlassFIsh etc.
Thoughts?
Pete
12 years, 10 months
[JBoss JIRA] Commented: (CDI-136) Assumption all @Stateful beans should be passivation capable
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-136?page=com.atlassian.jira.plugin.sy... ]
Pete Muir commented on CDI-136:
-------------------------------
Personally, I have no idea why we impose this additional rule for SFSBs, it seems to stray into specifying how EJBs actually work. I would prefer to remove this, making the paragraph say:
{quote}
For every bean which declares a passivating scope, the container must validate that the bean truly is passivation capable and that, in addition, its dependencies are passivation capable.
{quote}
This then removes any special case for EJBs and restricts the checks to those that make sense for CDI itself. If EJB wishes to introduce additional checks for SFSBs then they are free to do so.
David, WDYT? AIUI this solves the problem you have raised, but perhaps I have missed something?
> 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
> Fix For: 1.1 (Proposed)
>
>
> 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
12 years, 10 months
[JBoss JIRA] Commented: (CDI-136) Assumption all @Stateful beans should be passivation capable
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-136?page=com.atlassian.jira.plugin.sy... ]
Pete Muir commented on CDI-136:
-------------------------------
David and I had a long discussion on this topic, and the key issue right now revolves around the paragraph
{quote}For every bean which declares a passivating scope, and for every stateful session bean, the container must validate that the bean truly is passivation capable and that, in addition, its dependencies are passivation capable.
{quote}
This is imposing additional requirements on SFSBs.
> 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
> Fix For: 1.1 (Proposed)
>
>
> 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
12 years, 10 months