Re: [cdi-dev] Tomorrow's meeting focused on SE boot
by Werner Keil
Similar here.
Almost every Tue I join the Portlet 3 call (till around 5:30 CET) and as
mentioned unlike free or local German conf calls, IRC is blocked by the
firewall. Wed would be more flexible, e.g. being able to dial in from
hotel, but not today if I had other calls before that.
Werner
On Tue, May 5, 2015 at 4:59 PM, <cdi-dev-request(a)lists.jboss.org> wrote:
> Send cdi-dev mailing list submissions to
> cdi-dev(a)lists.jboss.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.jboss.org/mailman/listinfo/cdi-dev
> or, via email, send a message with subject or body 'help' to
> cdi-dev-request(a)lists.jboss.org
>
> You can reach the person managing the list at
> cdi-dev-owner(a)lists.jboss.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of cdi-dev digest..."
>
>
> Today's Topics:
>
> 1. Re: bean archives (Mark Struberg)
> 2. [JBoss JIRA] (CDI-525) Default names should maybe follow the
> inferring rules from the JavaBean spec (Martin Kouba (JIRA))
> 3. [JBoss JIRA] (CDI-525) Default names should maybe follow the
> inferring rules from the JavaBean spec (Martin Kouba (JIRA))
> 4. Re: bean archives (Jozef Hartinger)
> 5. Re: bean archives (Romain Manni-Bucau)
> 6. Re: Tomorrow's meeting focused on SE boot (John D. Ament)
>
>
> ----------------------------------------------------------------------
>
>
> Message: 6
> Date: Tue, 05 May 2015 14:58:58 +0000
> From: "John D. Ament" <john.d.ament(a)gmail.com>
> Subject: Re: [cdi-dev] Tomorrow's meeting focused on SE boot
> To: Antoine Sabot-Durand <antoine(a)sabot-durand.net>
> Cc: cdi-dev <cdi-dev(a)lists.jboss.org>
> Message-ID:
> <
> CAOqetn-zCCcS5HCrZQeQmLx9_N6MjXvFF7qRH3CF9v7jeNS7kg(a)mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Unfortunately, I'm not going to be able to make today's meeting after all.
>
> Is it possible to schedule for a different day of the week? I know we
> moved from Wednesdays to Tuesdays for the Brno folks, but Tuesdays are
> generally hard for me. I don't recall a discussion thread on the change.
>
> John
>
> On Tue, May 5, 2015 at 1:57 AM Antoine Sabot-Durand <
> antoine(a)sabot-durand.net> wrote:
>
> > I?ve just resen an invite to the list.
> >
> >
> > Le 5 mai 2015 ? 01:58, John D. Ament <john.d.ament(a)gmail.com> a ?crit :
> >
> > It's on IRC, #cdi-dev on freenode, noon eastern time/5 pm GMT.
> >
> > On Mon, May 4, 2015 at 10:33 AM Michael Remijan <mjremijan(a)yahoo.com>
> > wrote:
> >
> >> What are the details of the meeting? I'd like to attend if possible.
> >>
> >>
> >>
> >> On Monday, May 4, 2015 8:43 AM, Antoine Sabot-Durand <
> >> antoine(a)sabot-durand.net> wrote:
> >>
> >>
> >> Hi all,
> >>
> >> For this week meeting, I?d like to have a focus on SE boot and John PR :
> >> https://github.com/cdi-spec/cdi/pull/243
> >>
> >> Take a moment to read his proposal and make your comment if you have
> >> some.
> >>
> >> If we have time left we?ll go back on Event ordering and Mark P. PR :
> >> https://github.com/cdi-spec/cdi/pull/242
> >>
> >> Regards,
> >>
> >> Antoine
> >>
> >> _______________________________________________
> >> cdi-dev mailing list
> >> cdi-dev(a)lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/cdi-dev
> >>
> >> Note that for all code provided on this list, the provider licenses the
> >> code under the Apache License, Version 2 (
> >> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> >> provided on this list, the provider waives all patent and other
> >> intellectual property rights inherent in such information.
> >>
> >> _______________________________________________
> >> cdi-dev mailing list
> >> cdi-dev(a)lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/cdi-dev
> >>
> >> Note that for all code provided on this list, the provider licenses the
> >> code under the Apache License, Version 2 (
> >> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> >> provided on this list, the provider waives all patent and other
> >> intellectual property rights inherent in such information.
> >
> >
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20150505/d93abccb/at...
>
> ------------------------------
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the
> code under the Apache License, Version 2 (
> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other
> intellectual property rights inherent in such information.
>
> End of cdi-dev Digest, Vol 54, Issue 10
> ***************************************
>
9 years
[JBoss JIRA] (CDI-525) Default names should maybe follow the inferring rules from the JavaBean spec
by Martin Kouba (JIRA)
Martin Kouba created CDI-525:
--------------------------------
Summary: Default names should maybe follow the inferring rules from the JavaBean spec
Key: CDI-525
URL: https://issues.jboss.org/browse/CDI-525
Project: CDI Specification Issues
Issue Type: Clarification
Affects Versions: 1.2.Final
Reporter: Martin Kouba
*3.1.5. Default bean name for a managed bean*:
{quote}
The default name for a managed bean is the unqualified class name of the bean class, after converting the first character to lower case.
{quote}
As a result, the default name for a bean class {{URLMatcher}} should be {{uRLMatcher}}. On the other hand the JavaBean spec is using different rules when inferring property names, *8.8 Capitalization of inferred names*:
{quote}
However to support the occasional use of all upper-case names, we check if the first two characters of the name are both upper case and if so leave it alone.
{quote}
I.e. the property name for getter {{getURLMatcher()}} woud be {{URLMatcher}}.
Note that there is no TCK test for this and so implementations may differ (issue is already filed: CDITCK-473). Weld is using {{java.beans.Introspector.decapitalize()}} and so it follows the JavaBean spec even now. I'm not sure about OpenWebBeans.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years
[JBoss JIRA] (CDI-129) Clarify behaviour of @ApplicationScoped in EARs
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-129?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand updated CDI-129:
-------------------------------------
Fix Version/s: 2.0 (discussion)
(was: TBD)
> Clarify behaviour of @ApplicationScoped in EARs
> -----------------------------------------------
>
> Key: CDI-129
> URL: https://issues.jboss.org/browse/CDI-129
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Contexts
> Affects Versions: 1.0
> Reporter: Mark Struberg
> Assignee: Pete Muir
> Labels: application-scoped, visibility
> Fix For: 2.0 (discussion)
>
>
> Since @ApplicationScoped currently is defined in 6.5.2 as to be 'like in the Servlet specification' this means that you will get a new instance for every WebApplication (WAR file).
> There is currently no specified CDI scope for providing a single shared instance for a whole EAR.
> We could (ab-)use @Singleton for that, but this is currently not well defined at all.
> Alternatively we could introduce an own new annotation like @EnterpriseScoped or likes.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years
Observer ordering
by Michael Remijan
Hi everyone,
Is Observer ordering available yet in the RI?
9 years
[JBoss JIRA] (CDI-524) CDI spec make reference to Java EE 6.
by Martin Andersson (JIRA)
[ https://issues.jboss.org/browse/CDI-524?page=com.atlassian.jira.plugin.sy... ]
Martin Andersson updated CDI-524:
---------------------------------
Summary: CDI spec make reference to Java EE 6. (was: Section "1.2.1. Relationship to the Java EE platform specification".)
> CDI spec make reference to Java EE 6.
> -------------------------------------
>
> Key: CDI-524
> URL: https://issues.jboss.org/browse/CDI-524
> Project: CDI Specification Issues
> Issue Type: Epic
> Affects Versions: 1.2.Final
> Reporter: Martin Andersson
> Priority: Minor
>
> Section "1.2.1. Relationship to the Java EE platform specification" says:
> {quote}
> In the Java EE 6 environment, all component classes supporting injection, as defined by the Java EE 6 platform specification, may inject beans via the dependency injection service.
> {quote}
> The reference should be made to EE 7?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years
[JBoss JIRA] (CDI-524) Section "1.2.1. Relationship to the Java EE platform specification".
by Martin Andersson (JIRA)
Martin Andersson created CDI-524:
------------------------------------
Summary: Section "1.2.1. Relationship to the Java EE platform specification".
Key: CDI-524
URL: https://issues.jboss.org/browse/CDI-524
Project: CDI Specification Issues
Issue Type: Epic
Affects Versions: 1.2.Final
Reporter: Martin Andersson
Priority: Minor
Section "1.2.1. Relationship to the Java EE platform specification" says:
{quote}
In the Java EE 6 environment, all component classes supporting injection, as defined by the Java EE 6 platform specification, may inject beans via the dependency injection service.
{quote}
The reference should be made to EE 7?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years
[JBoss JIRA] (CDI-520) 3.6. Java EE components
by Martin Andersson (JIRA)
[ https://issues.jboss.org/browse/CDI-520?page=com.atlassian.jira.plugin.sy... ]
Martin Andersson edited comment on CDI-520 at 5/3/15 9:04 AM:
--------------------------------------------------------------
Mark, I have a hard time trying to understand why you speak mostly about transactions. Also I think you are a bit off looking at the details. I'm a "standards guy" and I have no experience implementing a real Java EE server or containers within. So please correct me if I am wrong, but..
The {{TransactionSynchronizationRegistry}} interface is what you'd call a "facade" for the _transaction manager_; how to enlist transaction-aware resources. This interface has no ability to create an entity manager. The entity manager implementation is provided by the EJB container _or_ a third-party persistence provider.
EJB 3.2, section "11.10.4 Container Provider Responsibility":
{quote}
The EJB Container Provider is responsible for the following: \[..] Provide the implementation of the entity manager factory classes for the persistence units that are configured with the EJB container. The implementation of the entity manager factory classes may be provided by the container directly or by the container in conjunction with a third-party persistence provider, as described in \[Java Persistence API, version 2.1].
{quote}
EJB 3.2, section "11.11.4 Container Provider Responsibility":
{quote}
Provide the implementation of the entity manager classes for the persistence units that are configured with the EJB container. This implementation may be provided by the container directory or by the container in conjunction with a third-party persistence provider, as described in \[Java Persistence API, version 2.1].
{quote}
The EJB container use the _transaction manager_ to control transaction demarcation.
JTA 1.2, §3.2:
{quote}
*For example*, the EJB container manages the transaction states for transactional EJB components; the container uses the TransactionManager interface mainly to demarcate transaction boundaries where operations affect the calling thread’s transaction context.
{quote}
JTA 1.2, §3.6:
{quote}
The javax.transaction.TransactionSynchronizationRegistry interface is intended for use by system level application server components such as persistence managers. This provides the ability to register synchronization objects with special ordering semantics, associate resource objects with the current transaction, get the transaction context of the current transaction, get current transaction status, and mark the current transaction for rollback.
This interface is implemented by the application server as a stateless service object. The same object can be used *by any number of components* with complete thread safety.
{quote}
The entity manager delegate, "[if available|http://docs.oracle.com/javaee/7/api/javax/persistence/EntityMan...]", may be retrieved using {{EntityManager.getDelegate()}}.
Bean-managed transaction demarcation is semantics that applies to EJB:s only, meaning that the EJB component does not want the default container-managed semantics to apply. Container-managed transactions is semantics that used to apply for EJB:s only, but since Java EE 7 (JTA 1.2), even CDI- as well as managed beans may use this service if annotated {{@Transactional}}. This is the ultimate "proof" that transactions themselves are in no way limited to EJB:s only.
JTA 1.2 §1.1:
{quote}
An application server (or TP monitor) provides the infrastructure required to support the application run-time environment which includes transaction state management. An example of such an application server is an EJB server.
\[..]
A component-based transactional application that is developed to operate in a modern application server environment relies on the application server to provide transaction management support through declarative transaction attribute settings. An example of this type of applications is an application developed using the industry standard Enterprise JavaBeans (EJB) component architecture. In addition, some other stand-alone Java client programs may wish to control their transaction boundaries using a high-level interface provided by the application server or the transaction manager.
{quote}
JTA 1.2 §2.1:
{quote}
The UserTransaction interface is intended to be used by both the enterprise bean implementer (for beans with bean-managed transactions) and by the client programmer that wants to explicitly demarcate transaction boundaries within programs that are written in the Java programming language.
{quote}
JTA 1.2 §3.7:
{quote}
The javax.transaction.Transactional annotation provides the application the ability to declaratively control transaction boundaries on *CDI managed beans, as well as classes defined as managed beans* by the Java EE specification \[..].
{quote}
The managed beans specification said that I can use **all resources listed in the umbrella specification chapter 5**. Among those resources is {{UserTransaction}} and {{TransactionSynchronizationRegistry}}, and of course the entity manager - whoever is the one providing the entity manager implementation. Transactions and the entity manager is two different things and both can be used outside the world of EJB:s. Application-managed entity managers are not even limited to JTA transactions only but could use resource-local transactions where the JDBC driver is the only transaction-aware resource.
I tried to find what it is you're referring to in the EJB specification. I think you're using an old specification, chapter 13 in EJB 3.2 is about the timer service. I read chapter 8 in EJB 3.2, and I still can't find that this specification forbid the use of transactions (or entity managers) outside EJB:s. And I still think that if the EJB specification limit transactions and/or entity managers to EJB:s only, then that is a serious issue which should be fixed.
It could very well be that given the history where JPA was entity beans defined in EJB, many containers still have a hard time providing entity managers that live well outside EJB components. It would be very useful for me if you know exactly which containers has this problem. Sooner or later, I think EJB:s should be pruned. All services they offer should be moved to standalone services a bean developer can explicitly use if he want to. Maybe the bean developer can use predefined CDI stereotypes if he want to apply a hole batch of services at once. In particular, I don't think it should be standardized which container has the responsibility to provide entity manager implementations other than then the "Java EE application server provider"?
Everything in the Java EE technology stack is a bit of a mess of course =) If you ask me, we should wipe them all out and start from scratch again.
was (Author: martin.andersson):
Mark, I have a hard time trying to understand why you speak mostly about transactions. Also I think you are a bit off looking at the details. I'm a "standards guy" and I have no experience implementing a real Java EE server or containers within. So please correct me if I am wrong, but..
The {{TransactionSynchronizationRegistry}} interface is what you'd call a "facade" for the _transaction manager_; how to enlist transaction-aware resources. This interface has no ability to create an entity manager. The entity manager implementation is provided by the EJB container _or_ a third-party persistence provider.
EJB 3.2, section "11.10.4 Container Provider Responsibility":
{quote}
The EJB Container Provider is responsible for the following: \[..] Provide the implementation of the entity manager factory classes for the persistence units that are configured with the EJB container. The implementation of the entity manager factory classes may be provided by the container directly or by the container in conjunction with a third-party persistence provider, as described in \[Java Persistence API, version 2.1].
{quote}
EJB 3.2, section "11.11.4 Container Provider Responsibility":
{quote}
Provide the implementation of the entity manager classes for the persistence units that are configured with the EJB container. This implementation may be provided by the container directory or by the container in conjunction with a third-party persistence provider, as described in \[Java Persistence API, version 2.1].
{quote}
The EJB container use the _transaction manager_ to control transaction demarcation.
JTA 1.2, §3.2:
{quote}
*For example*, the EJB container manages the transaction states for transactional EJB components; the container uses the TransactionManager interface mainly to demarcate transaction boundaries where operations affect the calling thread’s transaction context.
{quote}
JTA 1.2, §3.6:
{quote}
The javax.transaction.TransactionSynchronizationRegistry interface is intended for use by system level application server components such as persistence managers. This provides the ability to register synchronization objects with special ordering semantics, associate resource objects with the current transaction, get the transaction context of the current transaction, get current transaction status, and mark the current transaction for rollback.
This interface is implemented by the application server as a stateless service object. The same object can be used *by any number of components* with complete thread safety.
{quote}
The entity manager delegate, "[if available|http://docs.oracle.com/javaee/7/api/javax/persistence/EntityMan...]", may be retrieved using {{EntityManager.getDelegate()}}.
Bean-managed transaction demarcation is semantics that applies to EJB:s only, meaning that the EJB component does not want the default container-managed semantics to apply. Container-managed transactions is semantics that used to apply for EJB:s only, but since Java EE 7 (JTA 1.2), even CDI- as well as managed beans may use this service if annotated {{@Transactional}}. This is the ultimate "proof" that transactions themselves are in no way limited to EJB:s only.
JTA 1.2 §1.1:
{quote}
An application server (or TP monitor) provides the infrastructure required to support the application run-time environment which includes transaction state management. An example of such an application server is an EJB server.
\[..]
A component-based transactional application that is developed to operate in a modern application server environment relies on the application server to provide transaction management support through declarative transaction attribute settings. An example of this type of applications is an application developed using the industry standard Enterprise JavaBeans (EJB) component architecture. In addition, some other stand-alone Java client programs may wish to control their transaction boundaries using a high-level interface provided by the application server or the transaction manager.
{quote}
JTA 1.2 §2.1:
{quote}
The UserTransaction interface is intended to be used by both the enterprise bean implementer (for beans with bean-managed transactions) and by the client programmer that wants to explicitly demarcate transaction boundaries within programs that are written in the Java programming language.
{quote}
JTA 1.2 §3.7:
{quote}
The javax.transaction.Transactional annotation provides the application the ability to declaratively control transaction boundaries on **CDI managed beans, as well as classes defined as managed beans** by the Java EE specification \[..].
{quote}
The managed beans specification said that I can use **all resources listed in the umbrella specification chapter 5**. Among those resources is {{UserTransaction}} and {{TransactionSynchronizationRegistry}}, and of course the entity manager - whoever is the one providing the entity manager implementation. Transactions and the entity manager is two different things and both can be used outside the world of EJB:s. Application-managed entity managers are not even limited to JTA transactions only but could use resource-local transactions where the JDBC driver is the only transaction-aware resource.
I tried to find what it is you're referring to in the EJB specification. I think you're using an old specification, chapter 13 in EJB 3.2 is about the timer service. I read chapter 8 in EJB 3.2, and I still can't find that this specification forbid the use of transactions (or entity managers) outside EJB:s. And I still think that if the EJB specification limit transactions and/or entity managers to EJB:s only, then that is a serious issue which should be fixed.
It could very well be that given the history where JPA was entity beans defined in EJB, many containers still have a hard time providing entity managers that live well outside EJB components. It would be very useful for me if you know exactly which containers has this problem. Sooner or later, I think EJB:s should be pruned. All services they offer should be moved to standalone services a bean developer can explicitly use if he want to. Maybe the bean developer can use predefined CDI stereotypes if he want to apply a hole batch of services at once. In particular, I don't think it should be standardized which container has the responsibility to provide entity manager implementations other than then the "Java EE application server provider"?
Everything in the Java EE technology stack is a bit of a mess of course =) If you ask me, we should wipe them all out and start from scratch again.
> 3.6. Java EE components
> -----------------------
>
> Key: CDI-520
> URL: https://issues.jboss.org/browse/CDI-520
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Java EE integration
> Affects Versions: 1.1.Final
> Reporter: Martin Andersson
> Fix For: TBD
>
>
> I don't understand this text:
> "The instance used by the container to service an invocation of a Java EE component will not be the same instance obtained when using @Inject, instantiated by the container to invoke a producer method, observer method or disposer method, or instantiated by the container to access the value of a producer field."
> More specifically, I am trying to understand how we can use CDI to put a scope on {{EntityManager}} whose life cycle is rather undefined by JPA. I see that the specification use an example of a {{@Disposes}} method to close a container-managed entity manager which throw {{IllegalStateException}} in the disposer (!). Anyways, trying to solve this puzzle has led me to the paragraph quoted previously, of which I understand nothing to be honest.
> My research about the "CDI managed container-managed entity manager" continues. As of now, the example is flawed and a container-managed entity manager remains open after the disposer method. Anyways, I might open up a separate ticket for that.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years
[JBoss JIRA] (CDI-520) 3.6. Java EE components
by Martin Andersson (JIRA)
[ https://issues.jboss.org/browse/CDI-520?page=com.atlassian.jira.plugin.sy... ]
Martin Andersson edited comment on CDI-520 at 5/3/15 8:25 AM:
--------------------------------------------------------------
Mark, I have a hard time trying to understand why you speak mostly about transactions. Also I think you are a bit off looking at the details. I'm a "standards guy" and I have no experience implementing a real Java EE server or containers within. So please correct me if I am wrong, but..
The {{TransactionSynchronizationRegistry}} interface is what you'd call a "facade" for the _transaction manager_; how to enlist transaction-aware resources. This interface has no ability to create an entity manager. The entity manager implementation is provided by the EJB container _or_ a third-party persistence provider.
EJB 3.2, section "11.10.4 Container Provider Responsibility":
{quote}
The EJB Container Provider is responsible for the following: \[..] Provide the implementation of the entity manager factory classes for the persistence units that are configured with the EJB container. The implementation of the entity manager factory classes may be provided by the container directly or by the container in conjunction with a third-party persistence provider, as described in \[Java Persistence API, version 2.1].
{quote}
EJB 3.2, section "11.11.4 Container Provider Responsibility":
{quote}
Provide the implementation of the entity manager classes for the persistence units that are configured with the EJB container. This implementation may be provided by the container directory or by the container in conjunction with a third-party persistence provider, as described in \[Java Persistence API, version 2.1].
{quote}
The EJB container use the _transaction manager_ to control transaction demarcation.
JTA 1.2, §3.2:
{quote}
*For example*, the EJB container manages the transaction states for transactional EJB components; the container uses the TransactionManager interface mainly to demarcate transaction boundaries where operations affect the calling thread’s transaction context.
{quote}
JTA 1.2, §3.6:
{quote}
The javax.transaction.TransactionSynchronizationRegistry interface is intended for use by system level application server components such as persistence managers. This provides the ability to register synchronization objects with special ordering semantics, associate resource objects with the current transaction, get the transaction context of the current transaction, get current transaction status, and mark the current transaction for rollback.
This interface is implemented by the application server as a stateless service object. The same object can be used *by any number of components* with complete thread safety.
{quote}
The entity manager delegate, "[if available|http://docs.oracle.com/javaee/7/api/javax/persistence/EntityMan...]", may be retrieved using {{EntityManager.getDelegate()}}.
Bean-managed transaction demarcation is semantics that applies to EJB:s only, meaning that the EJB component does not want the default container-managed semantics to apply. Container-managed transactions is semantics that used to apply for EJB:s only, but since Java EE 7 (JTA 1.2), even CDI- as well as managed beans may use this service if annotated {{@Transactional}}. This is the ultimate "proof" that transactions themselves are in no way limited to EJB:s only.
JTA 1.2 §1.1:
{quote}
An application server (or TP monitor) provides the infrastructure required to support the application run-time environment which includes transaction state management. An example of such an application server is an EJB server.
\[..]
A component-based transactional application that is developed to operate in a modern application server environment relies on the application server to provide transaction management support through declarative transaction attribute settings. An example of this type of applications is an application developed using the industry standard Enterprise JavaBeans (EJB) component architecture. In addition, some other stand-alone Java client programs may wish to control their transaction boundaries using a high-level interface provided by the application server or the transaction manager.
{quote}
JTA 1.2 §2.1:
{quote}
The UserTransaction interface is intended to be used by both the enterprise bean implementer (for beans with bean-managed transactions) and by the client programmer that wants to explicitly demarcate transaction boundaries within programs that are written in the Java programming language.
{quote}
JTA 1.2 §3.7:
{quote}
The javax.transaction.Transactional annotation provides the application the ability to declaratively control transaction boundaries on **CDI managed beans, as well as classes defined as managed beans** by the Java EE specification \[..].
{quote}
The managed beans specification said that I can use **all resources listed in the umbrella specification chapter 5**. Among those resources is {{UserTransaction}} and {{TransactionSynchronizationRegistry}}, and of course the entity manager - whoever is the one providing the entity manager implementation. Transactions and the entity manager is two different things and both can be used outside the world of EJB:s. Application-managed entity managers are not even limited to JTA transactions only but could use resource-local transactions where the JDBC driver is the only transaction-aware resource.
I tried to find what it is you're referring to in the EJB specification. I think you're using an old specification, chapter 13 in EJB 3.2 is about the timer service. I read chapter 8 in EJB 3.2, and I still can't find that this specification forbid the use of transactions (or entity managers) outside EJB:s. And I still think that if the EJB specification limit transactions and/or entity managers to EJB:s only, then that is a serious issue which should be fixed.
It could very well be that given the history where JPA was entity beans defined in EJB, many containers still have a hard time providing entity managers that live well outside EJB components. It would be very useful for me if you know exactly which containers has this problem. Sooner or later, I think EJB:s should be pruned. All services they offer should be moved to standalone services a bean developer can explicitly use if he want to. Maybe the bean developer can use predefined CDI stereotypes if he want to apply a hole batch of services at once. In particular, I don't think it should be standardized which container has the responsibility to provide entity manager implementations other than then the "Java EE application server provider"?
Everything in the Java EE technology stack is a bit of a mess of course =) If you ask me, we should wipe them all out and start from scratch again.
was (Author: martin.andersson):
Mark, I have a hard time trying to understand why you speak mostly about transactions. Also I think you are a bit off looking at the details. I'm a "standards guy" and I have no experience implementing a real Java EE server or containers within. So please correct me if I am wrong, but..
The {{TransactionSynchronizationRegistry}} interface is what you'd call a "facade" for the _transaction manager_; how to enlist transaction-aware resources. This interface has no ability to create an entity manager. The entity manager implementation is provided by the EJB container _or_ a third-party persistence provider.
EJB 3.2, section "11.10.4 Container Provider Responsibility":
{quote}
The EJB Container Provider is responsible for the following: \[..] Provide the implementation of the entity manager factory classes for the persistence units that are configured with the EJB container. The implementation of the entity manager factory classes may be provided by the container directly or by the container in conjunction with a third-party persistence provider, as described in \[Java Persistence API, version 2.1].
{quote}
EJB 3.2, section "11.11.4 Container Provider Responsibility":
{quote}
Provide the implementation of the entity manager classes for the persistence units that are configured with the EJB container. This implementation may be provided by the container directory or by the container in conjunction with a third-party persistence provider, as described in \[Java Persistence API, version 2.1].
{quote}
The EJB container use the _transaction manager_ to control transaction demarcation.
JTA 1.2, §3.2:
{quote}
**For example**, the EJB container manages the transaction states for transactional EJB components; the container uses the TransactionManager interface mainly to demarcate transaction boundaries where operations affect the calling thread’s transaction context.
{quote}
JTA 1.2, §3.6:
{quote}
The javax.transaction.TransactionSynchronizationRegistry interface is intended for use by system level application server components such as persistence managers. This provides the ability to register synchronization objects with special ordering semantics, associate resource objects with the current transaction, get the transaction context of the current transaction, get current transaction status, and mark the current transaction for rollback.
This interface is implemented by the application server as a stateless service object. The same object can be used **by any number of components** with complete thread safety.
{quote}
The entity manager delegate, "[if available|http://docs.oracle.com/javaee/7/api/javax/persistence/EntityMan...]", may be retrieved using {{EntityManager.getDelegate()}}.
Bean-managed transaction demarcation is semantics that applies to EJB:s only, meaning that the EJB component does not want the default container-managed semantics to apply. Container-managed transactions is semantics that used to apply for EJB:s only, but since Java EE 7 (JTA 1.2), even CDI- as well as managed beans may use this service if annotated {{@Transactional}}. This is the ultimate "proof" that transactions themselves are in no way limited to EJB:s only.
JTA 1.2 §1.1:
{quote}
An application server (or TP monitor) provides the infrastructure required to support the application run-time environment which includes transaction state management. An example of such an application server is an EJB server.
\[..]
A component-based transactional application that is developed to operate in a modern application server environment relies on the application server to provide transaction management support through declarative transaction attribute settings. An example of this type of applications is an application developed using the industry standard Enterprise JavaBeans (EJB) component architecture. In addition, some other stand-alone Java client programs may wish to control their transaction boundaries using a high-level interface provided by the application server or the transaction manager.
{quote}
JTA 1.2 §2.1:
{quote}
The UserTransaction interface is intended to be used by both the enterprise bean implementer (for beans with bean-managed transactions) and by the client programmer that wants to explicitly demarcate transaction boundaries within programs that are written in the Java programming language.
{quote}
JTA 1.2 §3.7:
{quote}
The javax.transaction.Transactional annotation provides the application the ability to declaratively control transaction boundaries on **CDI managed beans, as well as classes defined as managed beans** by the Java EE specification \[..].
{quote}
The managed beans specification said that I can use **all resources listed in the umbrella specification chapter 5**. Among those resources is {{UserTransaction}} and {{TransactionSynchronizationRegistry}}, and of course the entity manager - whoever is the one providing the entity manager implementation. Transactions and the entity manager is two different things and both can be used outside the world of EJB:s. Application-managed entity managers are not even limited to JTA transactions only but could use resource-local transactions where the JDBC driver is the only transaction-aware resource.
I tried to find what it is you're referring to in the EJB specification. I think you're using an old specification, chapter 13 in EJB 3.2 is about the timer service. I read chapter 8 in EJB 3.2, and I still can't find that this specification forbid the use of transactions (or entity managers) outside EJB:s. And I still think that if the EJB specification limit transactions and/or entity managers to EJB:s only, then that is a serious issue which should be fixed.
It could very well be that given the history where JPA was entity beans defined in EJB, many containers still have a hard time providing entity managers that live well outside EJB components. It would be very useful for me if you know exactly which containers has this problem. Sooner or later, I think EJB:s should be pruned. All services they offer should be moved to standalone services a bean developer can explicitly use if he want to. Maybe the bean developer can use predefined CDI stereotypes if he want to apply a hole batch of services at once. In particular, I don't think it should be standardized which container has the responsibility to provide entity manager implementations other than then the "Java EE application server provider"?
Everything in the Java EE technology stack is a bit of a mess of course =) If you ask me, we should wipe them all out and start from scratch again.
> 3.6. Java EE components
> -----------------------
>
> Key: CDI-520
> URL: https://issues.jboss.org/browse/CDI-520
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Java EE integration
> Affects Versions: 1.1.Final
> Reporter: Martin Andersson
> Fix For: TBD
>
>
> I don't understand this text:
> "The instance used by the container to service an invocation of a Java EE component will not be the same instance obtained when using @Inject, instantiated by the container to invoke a producer method, observer method or disposer method, or instantiated by the container to access the value of a producer field."
> More specifically, I am trying to understand how we can use CDI to put a scope on {{EntityManager}} whose life cycle is rather undefined by JPA. I see that the specification use an example of a {{@Disposes}} method to close a container-managed entity manager which throw {{IllegalStateException}} in the disposer (!). Anyways, trying to solve this puzzle has led me to the paragraph quoted previously, of which I understand nothing to be honest.
> My research about the "CDI managed container-managed entity manager" continues. As of now, the example is flawed and a container-managed entity manager remains open after the disposer method. Anyways, I might open up a separate ticket for that.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years
