I can't take any credit as this was cemented at the platform-level pretty early. The basic convention is that container provided entries go directly under "java:comp/" while user-defined entries go in "java:comp/env/".
Aside from TransactionSynchronizationRegistry, other items directly under "java:comp/" include:
- java:comp/BeanManager - java:comp/ORB - java:comp/UserTransaction - java:comp/Validator - java:comp/ValidatorFactory
When we added the concept of default datasources, etc, we really expanded it:
- java:comp/DefaultContextService - java:comp/DefaultDataSource - java:comp/DefaultJMSConnectionFactory - java:comp/DefaultManagedExecutorService - java:comp/DefaultManagedScheduledExecutorService - java:comp/DefaultManagedThreadFactory
I don't know how good our TCK tests are, but java:module is an alias for java:comp for webapps, so theoretically people can also use "java:module/Validator", etc.
-David
Hi David,
Thanks for your response. Since TransactionSynchronizationRegistry already defines a standard JNDI java:comp/TransactionSynchronizationRegistry, your proposal to use java:comp/TransactionManager for TransactionManager makes sense. I second that.
GlassFish currently exposes TransactionManager via java:appserver/TransactionManager but it's better to standardize on something like java:comp/TransactionManager.
Ondro
There was a "you shouldn't need that" and a "you can only do harm" perspective on exposing the TransactionManager.
That said, I think we all have a JNDI entry for it anyway. Some of us put it in `java:comp/TransactionManager` despite the high chance users could be mislead into thinking it is portable.
We should consider using `java:comp/TransactionManager` for that reason. Or at least as one of the options.
-David
Hi all,
Jakarta Transactions specifies the type TransactionManager, but no portable way to obtain this. As a result, as of today we still need custom integration for every known server. Most, if not all app servers, already provide TransactionManager via some JNDI name. However, it's not required by the specification and the name used by app servers varies.
There's an issue on Github to Standardise way to obtain the TransactionManager. I'd like to invite you all to the discussion about this issue and express your opinion:
We at OmniFish, who are largely behind the GlassFish project, support this idea. Although it's true that TransactionManager manager has always been intended as an integration API, to be used internally inside application servers, there are other real-world cases where access to the TransactionManager is needed.
Examples: - A container does't provide any Transactions implementation, e.g. Tomcat. Developers often want to add an implementation and integrate it with other components, e.g. EclipseLink or Hibernate.
- A container provides EclipseLink as a Persistence implementation but developers want to replace it with Hibernate and integrate with Transactions
- Spring framework or other frameworks wants to integrate with the Transactions implementation in an app server
In all the cases above, there's a real need to access TransactionManager either from a deployed application or from a library installed into an app server. And in all cases, components that want to integrate with Transactions, e.g. Hibernate, need to retrieve it by means that are specific to the concrete app server or configuration. For example, Hibernate contains different platform classes for different applications servers and the platform needs to be defined as a property in persistence.xml if autodetection fails, e.g. <property name="hibernate.transaction.jta.platform" value="org.hibernate.service.jta.platform.internal.SunOneJtaPlatform"/>
On the other hand, the TransactionSynchronizationRegistry component in the Transactions spec already defines a standard JNDi name. Compared to that, the fact that TransactionManager doesn't define a standard JNDI name looks more like an oversight rather than intention.
Please express your opinion so that we know whether it's worth pursuing this idea and standardize the way how to retrieve the TransactionManager.
All the best,Ondro Mihalyi
Director, Jakarta EE expert
Omnifish OÜ, Narva mnt 5, 10117 Tallinn, Estonia | VAT: EE102487932
_______________________________________________ jta-dev mailing list jta-dev@xxxxxxxxxxxTo unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jta-dev
|