[JBoss AS7 Development] - EJB3/JPA 2.0 support for AS7
by Scott Marlow
Scott Marlow [http://community.jboss.org/people/smarlow%40redhat.com] modified the document:
"EJB3/JPA 2.0 support for AS7"
To view the document, visit: http://community.jboss.org/docs/DOC-16271
--------------------------------------------------------------
This is about the AS7 JPA layer and related concerns. Its a rough draft, mostly points copied from the JPA 2.0 spec.
1. Container-managed persistence context
1. Transaction scope (JPA 7.6.1)
1. Transaction active invocation
1. …
[View More]Persistence context is created if none already associated with transaction
2. Created persistence context ends when transaction ends
3. An extended persistence context can also be used, which survives when transaction ends.
4. Managed entities are detached at transaction end time.
2. No transaction invocation
1. Managed entities are detached at end of bean method call.
2. Extended scope (JPA 7.6.2)
1. Only supported for stateful session beans.
2. Entity modifications can be made outside of a transaction and are applied on the next joined transaction (anywhere on the cluster).
3. Extended persistence context (XPC) is created when stateful bean that depends on a XPC is created.
4. Managed entities continue to be managed at transaction commit time.
5. Managed entities are detached at transaction rollback time.
6. XPC is closed when dependent session bean(s) are closed (via @remove method).
7. Inheritance
1. Stateful beans that create other (local) stateful beans, share the same XPC.
3. Persistence context propagation (JPA 7.6.3)
1. A persistence context will be propagated to multiple entity managers (instances) within the same local transaction.
2. Remote invocations do not propagate the persistence context.
4. Persistence context propagation requirements for component invocations (JPA 7.6.3.1)
1. no propagation if component is invoked without a JTA transaction or without the JTA transaction propagating:
1. Transaction scoped entity manager used within the invoked component, will create a new persistence context.
2. Extended scoped entity manager used within the invoked component, will use the XPC already bound to the (invoked stateful) bean.
3. If the entity manager is invoked within a JTA transaction, the persistence context is bound to the JTA transaction.
2. If a component is invoked and the JTA transaction is propagated into the component:
1. If (SFSB) component has a XPC and the transaction already has a different persistence context associated with it, an EJBException is thrown by the container.
2. If a persistence context is bound to the JTA transaction, it is propagated into any entity managers used in the invocation.
2. Container requirements review
1. Application-managed persistence context (JPA 7.8.1)
1. Container needs to inject entity manager factory into jndi for application use.
2. Must use PersistenceProvider.createContainerEntityManagerFactory method for 3^rd^ party support. Internal APIs are fine for our persistence provider.
3. Must use EntityManagerFactory.close method to close the entity manager factory prior to shutdown (again for 3^rd^ party support).
2. Container-managed persistence context (JPA 7.9.1)
1. For 3^rd^ party support, use EntityManagerFactory.createEntityManager . Consider using for our persistence provider as well.
2. May pass (PersistenceProperty (http://download.oracle.com/javaee/6/api/javax/persistence/PersistenceProp... PersistenceContext.properties to EntityManagerFactory.createEntityManager(Map).
3. Container EM wrapper could implement some EntityManager.unwrap(Class<T> cls) calls but should default to underlying EM for unhandled classes.
3. Deployment
1. Extract persistence metadata from persistence.xml
2. Determine the PersistenceProvider classname for each persistence unit (PU). The default class is currently org.hibernate.ejb.HibernatePersistence.
3. Invoke the PersistenceProvider.createContainerEntityManagerFactory(PersistenceUnitInfo, Map) to create the EMF that will be used to create all EntityManager's for the PU. The properties read from the PU are passed as the second parameter.
4. Also pass the “javax.persistence.validation.factory ” property if validation mode is not set to NONE. The validator factory value appears to be org.hibernate.validator.engine.ValidatorFactoryImpl. Consult ValidatorFactoryProvider which is currently used to bootstrap the validator factory in AS6.
5. The PU classes shouldn't be loaded until after the EMF is created.
6. The EntityManagerFactory is closed at undeploy time, which also closes all EntityManager's opened by each factory.
7. Switchboard changes for PU + PC???
8. Fill in other deployment steps...
4. Clustering
1. Determine impact on http://community.jboss.org/docs/DOC-13822 http://community.jboss.org/wiki/OptimizingentityandXPCreplication which may need to be tweaked for clustering other persistence providers. Judging by the jira status, this optimization is not in place yet (although Hibernate persistence provider HHH-2762 is done).
2. Determine impact on http://community.jboss.org/docs/DOC-9565 http://community.jboss.org/wiki/DevEJB3NewSFSBCache (consider support for other persistence providers).
3. Other changes?
5. Weld integration (JpaInjectionServices implementation is wired in at boot time).
6. Determine Hibernate release to target integration with.
7. EJB Container interaction
1. TBD
8. Desires1. Maintainable code (a ten minute fix will take ten minutes :)
2. Would like to do a better job of showing what is going on at the EM level (e.g. logging the EM units of work grouped by transaction).
3. Consider any EM (container) extensions that make it easier to measure performance (perhaps based on Hibernate statistics). Its always nice to see how long each transaction took and the units of work within the transaction. It would be nice if we could do this with any persistence provider (for performance comparison).
4. Deal with the Hibernate persistence provider via the same way as we would interact with other persistence providers (via PersistenceProvider mentioned above).
5. It should be easy to switch to a new persistence provider.
6. If an application bundles a persistence provider that is referenced from their persistence unit(s), use the bundled persistence provider (even if its a different version of a JPA 2.0 provider that is also available to all applications). This should handle bundling a different version of Hibernate.
7. Peace.
9. Questions1. The JPA specification section 7.9.1 (Container Responsibilities) implies that only one (container managed) entity manager will be associated with the JTA transaction. However, what if someone injects multiple persistence contexts (different persistent units) in separate entity managers for the same bean. Should that be considered an application error or allowed behaviour (e.g. each separate entity manager is joined to the JTA transaction).
Illustration of how a stateful session bean (SFSB) named SFSB_XPC1 interacts with a stateless session bean (SLSB) named SLSB_PC2. Note that the extended persistence context (XPC) is injected into SFSB_XPC1 at bean creation time. Also note that the SFSB_XPC1 persistence context is bound to the JTA transaction and will be injected into the SLSB_PC2 by the EJB container as part of each invocation. The XPC1 will retain changes made by each invocation to SLSB_PC2 until the transaction commits.
|| *Action* || *Transaction* || *PersistenceContext
* ||
| SFSB_XPC1 created |
| XPC1 injected into SFSB_XPC1 |
| SFSB_XPC1.updateInventory | T1 started | XPC1 bound to T1 |
| SFSB_XPC1 calls SLSB_PC2 | T1 |
|
| SLSB_PC2.dowork | T1 | XPC1 injected into SLSB_PC2 EM instance |
| SLSB_PC2 loads entity item1 | T1 | item1 is loaded |
| SLSB_PC2 persists new entity order1 | T1 | order1 will be saved at commit time |
| SLSB_PC2 returns | T1 |
|
| SFSB_XPC1 calls SLB_PC2 again | T1 |
|
| SLSB_PC2.morework | T1 | XPC1 injected into SLSB_PC2 EM instance |
| SLSB_PC2 loads entity order1 | T1 | order1 is returned from XPC1 |
| SLSB_PC2 calls order1.increase(4) | T1 | change made in XPC1 held entity |
| SLSB_PC2 returns | T1 |
|
| SFSB_XPC1 returns | T1 commit | XPC1 changes are saved, item1 + order1 remain in XPC1 |
| SFSB_XPC1 removed |
| XPC1 is closed |
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-16271]
Create a new document in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
[View Less]
14 years, 2 months
[JBoss AS7 Development] - [jboss-modules] Volunteering to work on MODULES-3
by Olaf Bergner
Olaf Bergner [http://community.jboss.org/people/O.Bergner] created the discussion
"[jboss-modules] Volunteering to work on MODULES-3"
To view the discussion, visit: http://community.jboss.org/message/579882#579882
--------------------------------------------------------------
I recently discovered jboss-modules and instantly liked it. Having been looking around for some open source project to contribute to I searched jboss-modules' JIRA instance and chose [MODULES-3| https://issues.jboss.org/…
[View More]browse/MODULES-3 https://issues.jboss.org/browse/MODULES-3 - Support loading modules from a single jar. The preliminary results can be viewed at [ https://github.com/obergner/jboss-modules/tree/ob-modules-3 https://github.com/obergner/jboss-modules/tree/ob-modules-3], i.e. I developed my solution in a topic branch called +ob-modules-3+.
Current status:
1. I implemented JarRepositoryResourceLoader, a ResourceLoader implementation for loading resource from - you guessed it - a repository that has been compressed into a jar. Taking the existing JarResourceLoaderTest as a blueprint I implemented JarRepositoryResourceLoaderTest. This test passes.
2. I implemented JarRepositoryModuleLoader, a ModuleLoader for loading modules from a repository that has been compressed into a jar. Again, I took the LocalModuleLoaderTest as a blueprint and implemented JarRepositoryModuleLoaderTest. This test passes.
3. To avoid code duplication I extracted an abstract base class out of JarFileResourceLoader. Now, JarFileResourceLoader and JarRepositoryResourceLoader derive from this common base class.
4. To avoid confusion between JarFileResourceLoader and JarRepositoryResourceLoader I renamed JarResourceLoaderTest to JarFileResourceLoaderTest.
5. In order to be able to reuse ModuleXmlParser I modified it so that most of its methods now take an URL instead of a File in their parameter list.
6. The JIRA task mentions maven plugins, ant and gradle tasks for converting a file based repository into a jar repository. I haven't started working on those yet.
So if someone from the core developers could have a look at what little I have so far and give me some feedback I would be more than happy to continue working on jboss-modules.
Regards,
Olaf
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/579882#579882]
Start a new discussion in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
[View Less]
14 years, 2 months
[JBoss Cache Development] - cache NULL each time I hit a button
by barbara b
barbara b [http://community.jboss.org/people/barbaraboie] created the discussion
"cache NULL each time I hit a button"
To view the discussion, visit: http://community.jboss.org/message/579794#579794
--------------------------------------------------------------
Hello
Before, I used a previous version of JBoss Cache where I simply could use in every bean CacheProvider:
@In(create=true)
CacheProvider cacheProvider
public void method(){
&…
[View More]nbsp; ...
List) cacheProvider.get("tree-"+id);
if (rubriek == null){
cacheProvider.put("tree-"+id,getTree());
}
...
}
and the caching worked just fine through the whole site.
Now I'm trying to work with JBoss Cache 3.2.5.GA and it's not working. Every time I click on a button, the cache is empty.
I started changing the code in each bean into
CacheFactory factory = new DefaultCacheFactory();
Cache cache = factory.createCache("cache-configuration.xml");
public void method(){
...
Fqn fqn = Fqn.fromString("/id"+id)
List) cache.get(fqn,"tree");
if (rubriek == null){
cache.put(fqn,"tree",getTree());
}
...
}
When I tried this code, I saw that the cache was emptied each time I hit a button. I thought the problem was that I start in each bean a new Cache by using factory.createCache("cache-configuration.xml")
So I made a new class that can be used in every bean, so that the cache is only started once:
public class CacheHelper{
public static CacheFactory factory = new DefaultCacheFactory();
public static Cache cache = factory.createCache("cache-configuration.xml");
}
and in each bean
public void method(){
...
List) CacheHelper.cache.get(fqn,"tree");
if (rubriek == null){
CacheHelper.cache.put(fqn,"tree",getTree());
}
...
}
But the cache is still empty each time I click on a button.
Is there anyone who can tell me what I'm doing wrong?
Thanks a lot in advance!
Barbara
O, this is my cache-configuration.xml
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/579794#579794]
Start a new discussion in JBoss Cache Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
[View Less]
14 years, 2 months
[IronJacamar Development] - TestSuite - mapping test cases for AS6 and IronJacamar
by Stefano Maestri
Stefano Maestri [http://community.jboss.org/people/maeste] modified the document:
"TestSuite - mapping test cases for AS6 and IronJacamar"
To view the document, visit: http://community.jboss.org/docs/DOC-16266
--------------------------------------------------------------
h1. 1. General Note
1. Every deployment related test should be written with Arquillian
2. Every test that depends on some external deployment into the environment (for example jdbc driver) should be carefully evaluated to …
[View More]consider possible difference in AS7 env
3. Stress tests are not reported in this list because they are out of our unit test suite scope. It easy to keep track of them because all class names of this kind o tests contain the word "Stress" :)
4. InFlow test should be carefully evaluated too.
5. Also some integration tests are out of unit tests suite scope, but they are listed and commented here to keep track of them and open a discussion about integration tests.
*2. Test List*
|| Stressed condition || AS6 Implementation
(ClassName.methodName)
package is always
org.jboss.test.jca.test || IronJacamar Implementation
(packageName.ClassName.methodName)
||
JIRA
||
| verify AdminObject deployment, obj types and properties | AdminObjectUnitTestCase.testAdminObject() | TODO. We only verify atm that annotated AdminObject class is correctly processed from an annotation point of view in org.jboss.jca.deployers.annotations.AnnotationsTestCase.
testProcessAdministeredObject. | https://issues.jboss.org/browse/JBJCA-485 |
| Test for connection background validation | BackgroundValidationUnitTestCase | To be evaluated: we are testing our Validation mechanism directly, but this test should be ported to stress Validation framework indirectly at deploy time. IOW we can verify with this test if and when validation should stop the deployment. |
|
| stress various condition on CM (changing config and/or using it to get connection and so on) | BaseConnectionManagerUnitTestCase | TODO. In fact we have org/jboss/jca/core/connectionmanager/unit/AbstractConnectionManagerTestCase
That is the class with right tests. We have to complete it and moreover to check also TxConnectionManagerTestCase and XATxConnectionManagerTestCase. Finally we have to move and complete also NonTxConnectionManagerTestCase | https://issues.jboss.org/browse/JBJCA-486
https://issues.jboss.org/browse/JBJCA-487
https://issues.jboss.org/browse/JBJCA-488
https://issues.jboss.org/browse/JBJCA-489 |
|
| CachedConnectionErrorUnitTestCase | To be analysed. Maybe it don't make sense as is for ironjacamar |
|
|
| CachedConnectionSessionUnitTestCase | To be analysed. Maybe it don't make sense as is for ironjacamar |
|
| verify cf (datasource) correct serialization/deserialization | ConnectionFactorySerializationUnitTestCase | TODO |
|
| verify dependency define in jboss-ra.xml | DependsRARUnitTestCase | Does not make sense for ironjacamar |
|
| Check deployment of a -ds | DeploymentUnitTestCase | /ironjacamar-adapters/src/test/java/org/jboss/jca/adapters/jdbc/unit/H2TestCase
/ironjacamar-adapters/src/test/java/org/jboss/jca/adapters/jdbc/unit/H2XATestCase
NOTE: here we are just testing that deployment is working, while in old test suite also some properties setting are verified |
|
| Test HA connection both Local and XA | HAConnectionFactoryUnitTestCase | Does not make sense since we are not supporting HA connection right now. |
|
| test in flow RA using a Message Driven Bean | InflowUnitTestCase | TODO. We need to set up a messaging system in our test suite to do that |
|
| test correct behavior of ConnectionPool | InternalManagedConnection
PoolStatUnitTestCase | TODO |
|
| test that calling .close() 2 times on rs, statement, and connection does not throw Exception | JDBCComplianceUnitTestCase | To be evaluated, it's a jdbc compliance test, not directly related to JCA |
|
| test that after -ds redeployment connection are obtainable. | JDBCDriverRedeployUnitTestCase | TODO: extending/ironjacamar-adapters/src/test/java/org/jboss/jca/adapters/jdbc/unit/H2TestCase
and
/ironjacamar-adapters/src/test/java/org/jboss/jca/adapters/jdbc/unit/H2XATestCase
Note: the old test suite is redeploying driver too. It have to be evaluated in our new environment if it make sense and if AS7 would permit driver hot redeployment |
|
| test various jdbc statement method | JDBCStatementTestsConnectionUnitTestCase | It's a JDBC test, not a JCA test. To be evaluated |
|
| test Local transaction states | LocalTransactionTidyupUnitTestCase | TODO: byteman to be evaluated. Probably not needed here |
|
| test Local transaction commits and rollbacks | LocalWrapperCleanupUnitTestCase | TODO: byteman to be evaluated. Maybe useful here. |
|
| test marsha/unmarshal of ManagedConnectionFactory and some deployment injection for it | ManagedDeploymentUnitTestCase.java | TODO: the marshal/unmarshal part. The injection is already covered |
|
| Verify multi thread correct behavior for DS and JCA adapter in a Tx context | MultiThreadedTxDsUnitTestCase
MultiThreadedTxUnitTestCase | TODO for sure, but we have to postpone this after other unit tests porting/implementation, since we need to understand if the AS6 tests in this classes are enough (probably not) or if we need to stress other condition in a mutithread env. Probably we could use for all (or at least almost) of this test the Tx fake implementation we have. If we need (or decite to) use the real arjuna one we probably would need Byteman here, but it have to be carefully evaluated since we are writing pure JCA tests that should not depend on Tx framework used. The best solution frm a Unit test point of view would be to use our fake implementation for every test, but we need to verify if it is possible. |
|
| Verify pooling behaviours< | PoolingUnitTestCase.java
PreFillPoolingUnitTestCase.java
PoolingUnitTestCase
PreFillPoolingUnitTestCase.java | TODO: we have 2 classes that should do that in package org.jboss.jca.core.connectionmanager.unit.pool named PoolingTestCase and PreFillPoolingTestCase but all test methods are empty |
|
| Test case for resource adapters with primitive config-property definitions | PrimitiveUnitTestCase.java | ConnectionFactories does not make sense anymore. Moreover we are verifying config-property settings and mainly mandatory ones in parser's test cases |
|
| ests of the prepared statement cache | PSCacheUnitTestCase.java | TODO, but Not a pure JCA. It's a JDBC tests we have to evaluate if we are going to provide JDBC tests too. |
|
| tests if CachedConnectionManager works with reentrant ejbs | ReentrantUnitTestCase.java | It's a JCA/EJB test. It's more an integration test. It would make sense to have it into AS7, but not ironjacamar standalone because we need an EJB environment to do that. |
|
| Tests of remote access to a jdbc datasource. | RemoteDSUnitTestCase.java | It would be implemented as integration test, not as part of our unit test suite. Like stress tests. |
|
| Unit test for the RetryableResourceException | RetryableResourceUnitTestCase.java | does not make sense we haven't this exception in ironjacamar impl |
|
| RollbackOnlyReleaseConnectionUnitTestCase | RollbackOnlyReleaseConnectionUnitTestCase.java | TODO. Our Tx fake implementation should be enough here |
|
| tests scoped rar inside ear | ScopedRARNoJBossAppUnitTestCase.java
ScopedRARUnitTestCase.java | Integration tests. Suitable for AS7, ironjacamar standalone does not support ear |
|
| Tests of how security context interact with the JCA layer. | SecurityContextUnitTestCase | TODO after security integration :) |
|
| StaleConnectionCheckerUnitTestCase | StaleConnectionCheckerUnitTestCase.java | org/jboss/jca/adapters/jdbc/spi/StaleConnectionCheckerTestCase |
|
| StatisticsFormatterUnitTestCase | StatisticsFormatterUnitTestCase.java
StatisticsReporterUnitTestCase.java | Does not make sense. It will be covered by RHQ integration tests |
|
| Unit test for the TestConnection method | TestConnectionUnitTestCase.java | does not make sense is a jmx sever method |
|
| Transaction Active test | TransactionActiveUnitTestCase.java | TODO. AS6' one is based on a jms queue. Maybe it should be redefined in another way. To be evaluated. |
|
| Unit test for class TxConnectionManager | Unit test for class TxConnectionManager | TODO. Probably we could use for all (or at least almost) of this test the Tx fake implementation we have. If we need (or decite to) use the real arjuna one we probably would need Byteman here, but it have to be carefully evaluated since we are writing pure JCA tests that should not depend on Tx framework used. The best solution from a Unit test point of view would be to use our fake implementation for every test, but we need to verify if it is possible. |
|
| Tests unshared connections | UnsharedConnectionUnitTestCase.java | TODO |
|
| Test correct deployment of UserTx | UserTxUnitTestCase.java | Doable extending deployers' tes cases. |
|
| Inflow unit tests | WorkManagerUnitTestCase.java
TimerUnitTestCase.java
TxInflowUnitTestCase.java | TO be evaluated |
|
| XADSUnitTestCase.java | XADSUnitTestCase.java | done on H2XATestCase |
|
| verify correct thrown of XAException | XAExceptionUnitTestCase.java | TODO |
|
| Unit test for class XATxConnectionManager | XATxConnectionManagerUnitTestCase.java | TODO. Probably we could use for all (or at least almost) of this test the Tx fake implementation we have. If we need (or decite to) use the real arjuna one we probably would need Byteman here, but it have to be carefully evaluated since we are writing pure JCA tests that should not depend on Tx framework used. The best solution from a Unit test point of view would be to use our fake implementation for every test, but we need to verify if it is possible. |
|
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-16266]
Create a new document in IronJacamar Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
[View Less]
14 years, 2 months
[JBoss AS7 Development] - EJB3/JPA 2.0 support for AS7
by Scott Marlow
Scott Marlow [http://community.jboss.org/people/smarlow%40redhat.com] modified the document:
"EJB3/JPA 2.0 support for AS7"
To view the document, visit: http://community.jboss.org/docs/DOC-16271
--------------------------------------------------------------
This is about the AS7 JPA layer and related concerns. Its a rough draft, mostly points copied from the JPA 2.0 spec.
1. Container-managed persistence context
1. Transaction scope (JPA 7.6.1)
1. Transaction active invocation
1. …
[View More]Persistence context is created if none already associated with transaction
2. Created persistence context ends when transaction ends
3. An extended persistence context can also be used, which survives when transaction ends.
4. Managed entities are detached at transaction end time.
2. No transaction invocation
1. Managed entities are detached at end of bean method call.
2. Extended scope (JPA 7.6.2)
1. Only supported for stateful session beans.
2. Entity modifications can be made outside of a transaction and are applied on the next joined transaction (anywhere on the cluster).
3. Extended persistence context (XPC) is created when stateful bean that depends on a XPC is created.
4. Managed entities continue to be managed at transaction commit time.
5. Managed entities are detached at transaction rollback time.
6. XPC is closed when dependent session bean(s) are closed (via @remove method).
7. Inheritance
1. Stateful beans that create other (local) stateful beans, share the same XPC.
3. Persistence context propagation (JPA 7.6.3)
1. A persistence context will be propagated to multiple entity managers (instances) within the same local transaction.
2. Remote invocations do not propagate the persistence context.
4. Persistence context propagation requirements for component invocations (JPA 7.6.3.1)
1. no propagation if component is invoked without a JTA transaction or without the JTA transaction propagating:
1. Transaction scoped entity manager used within the invoked component, will create a new persistence context.
2. Extended scoped entity manager used within the invoked component, will use the XPC already bound to the (invoked stateful) bean.
3. If the entity manager is invoked within a JTA transaction, the persistence context is bound to the JTA transaction.
2. If a component is invoked and the JTA transaction is propagated into the component:
1. If (SFSB) component has a XPC and the transaction already has a different persistence context associated with it, an EJBException is thrown by the container.
2. If a persistence context is bound to the JTA transaction, it is propagated into any entity managers used in the invocation.
2. Container requirements review
1. Application-managed persistence context (JPA 7.8.1)
1. Container needs to inject entity manager factory into jndi for application use.
2. Must use PersistenceProvider.createContainerEntityManagerFactory method for 3^rd^ party support. Internal APIs are fine for our persistence provider.
3. Must use EntityManagerFactory.close method to close the entity manager factory prior to shutdown (again for 3^rd^ party support).
2. Container-managed persistence context (JPA 7.9.1)
1. For 3^rd^ party support, use EntityManagerFactory.createEntityManager . Consider using for our persistence provider as well.
2. May pass (PersistenceProperty (http://download.oracle.com/javaee/6/api/javax/persistence/PersistenceProp... PersistenceContext.properties to EntityManagerFactory.createEntityManager(Map).
3. Container EM wrapper could implement some EntityManager.unwrap(Class<T> cls) calls but should default to underlying EM for unhandled classes.
3. Deployment
1. Extract persistence metadata from persistence.xml
2. Determine the PersistenceProvider classname for each persistence unit (PU). The default class is currently org.hibernate.ejb.HibernatePersistence.
3. Invoke the PersistenceProvider.createContainerEntityManagerFactory(PersistenceUnitInfo, Map) to create the EMF that will be used to create all EntityManager's for the PU. The properties read from the PU are passed as the second parameter.
4. Also pass the “javax.persistence.validation.factory ” property if validation mode is not set to NONE. The validator factory value appears to be org.hibernate.validator.engine.ValidatorFactoryImpl. Consult ValidatorFactoryProvider which is currently used to bootstrap the validator factory in AS6.
5. The PU classes shouldn't be loaded until after the EMF is created.
6. The EntityManagerFactory is closed at undeploy time, which also closes all EntityManager's opened by each factory.
7. Switchboard changes for PU + PC???
8. Fill in other deployment steps...
4. Clustering
1. Determine impact on http://community.jboss.org/docs/DOC-13822 http://community.jboss.org/wiki/OptimizingentityandXPCreplication which may need to be tweaked for clustering other persistence providers. Judging by the jira status, this optimization is not in place yet (although Hibernate persistence provider HHH-2762 is done).
2. Determine impact on http://community.jboss.org/docs/DOC-9565 http://community.jboss.org/wiki/DevEJB3NewSFSBCache (consider support for other persistence providers).
3. Other changes?
5. Weld integration (JpaInjectionServices implementation is wired in at boot time).
6. Determine Hibernate release to target integration with.
7. EJB Container interaction
1. TBD
8. Desires1. Maintainable code (a ten minute fix will take ten minutes :)
2. Would like to do a better job of showing what is going on at the EM level (e.g. logging the EM units of work grouped by transaction).
3. Consider any EM (container) extensions that make it easier to measure performance (perhaps based on Hibernate statistics). Its always nice to see how long each transaction took and the units of work within the transaction. It would be nice if we could do this with any persistence provider (for performance comparison).
4. Deal with the Hibernate persistence provider via the same way as we would interact with other persistence providers (via PersistenceProvider mentioned above).
5. It should be easy to switch to a new persistence provider.
6. If an application bundles a persistence provider that is referenced from their persistence unit(s), use the bundled persistence provider (even if its a different version of a JPA 2.0 provider that is also available to all applications). This should handle bundling a different version of Hibernate.
7. Peace.
Illustration of how a stateful session bean (SFSB) named SFSB_XPC1 interacts with a stateless session bean (SLSB) named SLSB_PC2. Note that the extended persistence context (XPC) is injected into SFSB_XPC1 at bean creation time. Also note that the SFSB_XPC1 persistence context is bound to the JTA transaction and will be injected into the SLSB_PC2 by the EJB container as part of each invocation. The XPC1 will retain changes made by each invocation to SLSB_PC2 until the transaction commits.
|| *Action* || *Transaction* || *PersistenceContext
* ||
| SFSB_XPC1 created |
| XPC1 injected into SFSB_XPC1 |
| SFSB_XPC1.updateInventory | T1 started | XPC1 bound to T1 |
| SFSB_XPC1 calls SLSB_PC2 | T1 |
|
| SLSB_PC2.dowork | T1 | XPC1 injected into SLSB_PC2 EM instance |
| SLSB_PC2 loads entity item1 | T1 | item1 is loaded |
| SLSB_PC2 persists new entity order1 | T1 | order1 will be saved at commit time |
| SLSB_PC2 returns | T1 |
|
| SFSB_XPC1 calls SLB_PC2 again | T1 |
|
| SLSB_PC2.morework | T1 | XPC1 injected into SLSB_PC2 EM instance |
| SLSB_PC2 loads entity order1 | T1 | order1 is returns from XPC1 |
| SLSB_PC2 calls order1.increase(4) | T1 | change made in XPC1 held entity |
| SLSB_PC2 returns | T1 |
|
| SFSB_XPC1 returns | T1 commit | XPC1 changes are saved, item1 + order1 remain in XPC1 |
| SFSB_XPC1 removed |
| XPC1 is closed |
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-16271]
Create a new document in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
[View Less]
14 years, 2 months
[IronJacamar Development] - TestSuite - mapping test cases for AS6 and IronJacamar
by Stefano Maestri
Stefano Maestri [http://community.jboss.org/people/maeste] modified the document:
"TestSuite - mapping test cases for AS6 and IronJacamar"
To view the document, visit: http://community.jboss.org/docs/DOC-16266
--------------------------------------------------------------
h1. 1. General Note
1. Every deployment related test should be written with Arquillian
2. Every test that depends on some external deployment into the environment (for example jdbc driver) should be carefully evaluated to …
[View More]consider possible difference in AS7 env
3. Stress tests are not reported in this list because they are out of our unit test suite scope. It easy to keep track of them because all class names of this kind o tests contain the word "Stress" :)
4. InFlow test should be carefully evaluated too.
5. Also some integration tests are out of unit tests suite scope, but they are listed and commented here to keep track of them and open a discussion about integration tests.
*2. Test List*
|| Stressed condition || AS6 Implementation
(ClassName.methodName)
package is always
org.jboss.test.jca.test || IronJacamar Implementation
(packageName.ClassName.methodName)
||
JIRA
||
| verify AdminObject deployment, obj types and properties | AdminObjectUnitTestCase.testAdminObject() | TODO. We only verify atm that annotated AdminObject class is correctly processed from an annotation point of view in org.jboss.jca.deployers.annotations.AnnotationsTestCase.
testProcessAdministeredObject. | https://issues.jboss.org/browse/JBJCA-485 |
| Test for connection background validation | BackgroundValidationUnitTestCase | To be evaluated: we are testing our Validation mechanism directly, but this test should be ported to stress Validation framework indirectly at deploy time. IOW we can verify with this test if and when validation should stop the deployment. |
|
| stress various condition on CM (changing config and/or using it to get connection and so on) | BaseConnectionManagerUnitTestCase | TODO |
|
|
| CachedConnectionErrorUnitTestCase | To be analysed. Maybe it don't make sense as is for ironjacamar |
|
|
| CachedConnectionSessionUnitTestCase | To be analysed. Maybe it don't make sense as is for ironjacamar |
|
| verify cf (datasource) correct serialization/deserialization | ConnectionFactorySerializationUnitTestCase | TODO |
|
| verify dependency define in jboss-ra.xml | DependsRARUnitTestCase | Does not make sense for ironjacamar |
|
| Check deployment of a -ds | DeploymentUnitTestCase | /ironjacamar-adapters/src/test/java/org/jboss/jca/adapters/jdbc/unit/H2TestCase
/ironjacamar-adapters/src/test/java/org/jboss/jca/adapters/jdbc/unit/H2XATestCase
NOTE: here we are just testing that deployment is working, while in old test suite also some properties setting are verified |
|
| Test HA connection both Local and XA | HAConnectionFactoryUnitTestCase | Does not make sense since we are not supporting HA connection right now. |
|
| test in flow RA using a Message Driven Bean | InflowUnitTestCase | TODO. We need to set up a messaging system in our test suite to do that |
|
| test correct behavior of ConnectionPool | InternalManagedConnection
PoolStatUnitTestCase | TODO |
|
| test that calling .close() 2 times on rs, statement, and connection does not throw Exception | JDBCComplianceUnitTestCase | To be evaluated, it's a jdbc compliance test, not directly related to JCA |
|
| test that after -ds redeployment connection are obtainable. | JDBCDriverRedeployUnitTestCase | TODO: extending/ironjacamar-adapters/src/test/java/org/jboss/jca/adapters/jdbc/unit/H2TestCase
and
/ironjacamar-adapters/src/test/java/org/jboss/jca/adapters/jdbc/unit/H2XATestCase
Note: the old test suite is redeploying driver too. It have to be evaluated in our new environment if it make sense and if AS7 would permit driver hot redeployment |
|
| test various jdbc statement method | JDBCStatementTestsConnectionUnitTestCase | It's a JDBC test, not a JCA test. To be evaluated |
|
| test Local transaction states | LocalTransactionTidyupUnitTestCase | TODO: byteman to be evaluated. Probably not needed here |
|
| test Local transaction commits and rollbacks | LocalWrapperCleanupUnitTestCase | TODO: byteman to be evaluated. Maybe useful here. |
|
| test marsha/unmarshal of ManagedConnectionFactory and some deployment injection for it | ManagedDeploymentUnitTestCase.java | TODO: the marshal/unmarshal part. The injection is already covered |
|
| Verify multi thread correct behavior for DS and JCA adapter in a Tx context | MultiThreadedTxDsUnitTestCase
MultiThreadedTxUnitTestCase | TODO for sure, but we have to postpone this after other unit tests porting/implementation, since we need to understand if the AS6 tests in this classes are enough (probably not) or if we need to stress other condition in a mutithread env. Probably we could use for all (or at least almost) of this test the Tx fake implementation we have. If we need (or decite to) use the real arjuna one we probably would need Byteman here, but it have to be carefully evaluated since we are writing pure JCA tests that should not depend on Tx framework used. The best solution frm a Unit test point of view would be to use our fake implementation for every test, but we need to verify if it is possible. |
|
| Verify pooling behaviours< | PoolingUnitTestCase.java
PreFillPoolingUnitTestCase.java
PoolingUnitTestCase
PreFillPoolingUnitTestCase.java | TODO: we have 2 classes that should do that in package org.jboss.jca.core.connectionmanager.unit.pool named PoolingTestCase and PreFillPoolingTestCase but all test methods are empty |
|
| Test case for resource adapters with primitive config-property definitions | PrimitiveUnitTestCase.java | ConnectionFactories does not make sense anymore. Moreover we are verifying config-property settings and mainly mandatory ones in parser's test cases |
|
| ests of the prepared statement cache | PSCacheUnitTestCase.java | TODO, but Not a pure JCA. It's a JDBC tests we have to evaluate if we are going to provide JDBC tests too. |
|
| tests if CachedConnectionManager works with reentrant ejbs | ReentrantUnitTestCase.java | It's a JCA/EJB test. It's more an integration test. It would make sense to have it into AS7, but not ironjacamar standalone because we need an EJB environment to do that. |
|
| Tests of remote access to a jdbc datasource. | RemoteDSUnitTestCase.java | It would be implemented as integration test, not as part of our unit test suite. Like stress tests. |
|
| Unit test for the RetryableResourceException | RetryableResourceUnitTestCase.java | does not make sense we haven't this exception in ironjacamar impl |
|
| RollbackOnlyReleaseConnectionUnitTestCase | RollbackOnlyReleaseConnectionUnitTestCase.java | TODO. Our Tx fake implementation should be enough here |
|
| tests scoped rar inside ear | ScopedRARNoJBossAppUnitTestCase.java
ScopedRARUnitTestCase.java | Integration tests. Suitable for AS7, ironjacamar standalone does not support ear |
|
| Tests of how security context interact with the JCA layer. | SecurityContextUnitTestCase | TODO after security integration :) |
|
| StaleConnectionCheckerUnitTestCase | StaleConnectionCheckerUnitTestCase.java | org/jboss/jca/adapters/jdbc/spi/StaleConnectionCheckerTestCase |
|
| StatisticsFormatterUnitTestCase | StatisticsFormatterUnitTestCase.java
StatisticsReporterUnitTestCase.java | Does not make sense. It will be covered by RHQ integration tests |
|
| Unit test for the TestConnection method | TestConnectionUnitTestCase.java | does not make sense is a jmx sever method |
|
| Transaction Active test | TransactionActiveUnitTestCase.java | TODO. AS6' one is based on a jms queue. Maybe it should be redefined in another way. To be evaluated. |
|
| Unit test for class TxConnectionManager | Unit test for class TxConnectionManager | TODO. Probably we could use for all (or at least almost) of this test the Tx fake implementation we have. If we need (or decite to) use the real arjuna one we probably would need Byteman here, but it have to be carefully evaluated since we are writing pure JCA tests that should not depend on Tx framework used. The best solution from a Unit test point of view would be to use our fake implementation for every test, but we need to verify if it is possible. |
|
| Tests unshared connections | UnsharedConnectionUnitTestCase.java | TODO |
|
| Test correct deployment of UserTx | UserTxUnitTestCase.java | Doable extending deployers' tes cases. |
|
| Inflow unit tests | WorkManagerUnitTestCase.java
TimerUnitTestCase.java
TxInflowUnitTestCase.java | TO be evaluated |
|
| XADSUnitTestCase.java | XADSUnitTestCase.java | done on H2XATestCase |
|
| verify correct thrown of XAException | XAExceptionUnitTestCase.java | TODO |
|
| Unit test for class XATxConnectionManager | XATxConnectionManagerUnitTestCase.java | TODO. Probably we could use for all (or at least almost) of this test the Tx fake implementation we have. If we need (or decite to) use the real arjuna one we probably would need Byteman here, but it have to be carefully evaluated since we are writing pure JCA tests that should not depend on Tx framework used. The best solution from a Unit test point of view would be to use our fake implementation for every test, but we need to verify if it is possible. |
|
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-16266]
Create a new document in IronJacamar Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
[View Less]
14 years, 2 months
[JBoss AS7 Development] - EJB3/JPA 2.0 support for AS7
by Scott Marlow
Scott Marlow [http://community.jboss.org/people/smarlow%40redhat.com] modified the document:
"EJB3/JPA 2.0 support for AS7"
To view the document, visit: http://community.jboss.org/docs/DOC-16271
--------------------------------------------------------------
This is about the AS7 JPA layer and related concerns. Its a rough draft, mostly points copied from the JPA 2.0 spec.
1. Container-managed persistence context
1. Transaction scope (JPA 7.6.1)
1. Transaction active invocation
1. …
[View More]Persistence context is created if none already associated with transaction
2. Created persistence context ends when transaction ends
3. An extended persistence context can also be used, which survives when transaction ends.
4. Managed entities are detached at transaction end time.
2. No transaction invocation
1. Managed entities are detached at end of method call.
2. Extended scope (JPA 7.6.2)
1. Only supported for stateful session beans.
2. Entity modifications can be made outside of a transaction and are applied on the next joined transaction (anywhere on the cluster).
3. Extended persistence context (XPC) is created when stateful bean that depends on a XPC is created.
4. Managed entities continue to be managed at transaction commit time.
5. Managed entities are detached at transaction rollback time.
6. XPC is closed when dependent session bean(s) are closed (via @remove method).
7. Inheritance
1. Stateful beans that create other (local) stateful beans, share the same XPC.
3. Persistence context propagation (JPA 7.6.3)
1. A persistence context will be propagated to multiple entity managers (instances) within the same local transaction.
2. Remote invocations do not propagate the persistence context.
4. Persistence context propagation requirements for component invocations (JPA 7.6.3.1)
1. no propagation if component is invoked without a JTA transaction or without the JTA transaction propagating:
1. Transaction scoped entity manager used within the invoked component, will create a new persistence context.
2. Extended scoped entity manager used within the invoked component, will use the XPC already bound to the (invoked stateful) bean.
3. If the entity manager is invoked within a JTA transaction, the persistence context is bound to the JTA transaction.
2. If a component is invoked and the JTA transaction is propagated into the component:
1. If (SFSB) component has a XPC and the transaction already has a different persistence context associated with it, an EJBException is thrown by the container.
2. If a persistence context is bound to the JTA transaction, it is propagated into any entity managers used in the invocation.
2. Container requirements review
1. Application-managed persistence context (JPA 7.8.1)
1. Container needs to inject entity manager factory into jndi for application use.
2. Must use PersistenceProvider.createContainerEntityManagerFactory method for 3^rd^ party support. Internal APIs are fine for our persistence provider.
3. Must use EntityManagerFactory.close method to close the entity manager factory prior to shutdown (again for 3^rd^ party support).
2. Container-managed persistence context (JPA 7.9.1)
1. For 3^rd^ party support, use EntityManagerFactory.createEntityManager . Consider using for our persistence provider as well.
2. May pass (PersistenceProperty (http://download.oracle.com/javaee/6/api/javax/persistence/PersistenceProp... PersistenceContext.properties to EntityManagerFactory.createEntityManager(Map).
3. Container EM wrapper could implement some EntityManager.unwrap(Class<T> cls) calls but should default to underlying EM for unhandled classes.
3. Deployment
1. Extract persistence metadata from persistence.xml
2. Determine the PersistenceProvider classname for each persistence unit (PU). The default class is currently org.hibernate.ejb.HibernatePersistence.
3. Invoke the PersistenceProvider.createContainerEntityManagerFactory(PersistenceUnitInfo, Map) to create the EMF that will be used to create all EntityManager's for the PU. The properties read from the PU are passed as the second parameter.
4. Also pass the “javax.persistence.validation.factory ” property if validation mode is not set to NONE. The validator factory value appears to be org.hibernate.validator.engine.ValidatorFactoryImpl. Consult ValidatorFactoryProvider which is currently used to bootstrap the validator factory in AS6.
5. The PU classes shouldn't be loaded until after the EMF is created.
6. The EntityManagerFactory is closed at undeploy time, which also closes all EntityManager's opened by each factory.
7. Switchboard changes for PU + PC???
8. Fill in other deployment steps...
4. Clustering
1. Determine impact on http://community.jboss.org/docs/DOC-13822 http://community.jboss.org/wiki/OptimizingentityandXPCreplication which may need to be tweaked for clustering other persistence providers. Judging by the jira status, this optimization is not in place yet (although Hibernate persistence provider HHH-2762 is done).
2. Determine impact on http://community.jboss.org/docs/DOC-9565 http://community.jboss.org/wiki/DevEJB3NewSFSBCache (consider support for other persistence providers).
3. Other changes?
5. Weld integration (JpaInjectionServices implementation is wired in at boot time).
6. Determine Hibernate release to target integration with.
7. EJB Container interaction
1. TBD
8. Desires1. Maintainable code (a ten minute fix will take ten minutes :)
2. Would like to do a better job of showing what is going on at the EM level (e.g. logging the EM units of work grouped by transaction).
3. Consider any EM (container) extensions that make it easier to measure performance (perhaps based on Hibernate statistics). Its always nice to see how long each transaction took and the units of work within the transaction. It would be nice if we could do this with any persistence provider (for performance comparison).
4. Deal with the Hibernate persistence provider via the same way as we would interact with other persistence providers (via PersistenceProvider mentioned above).
5. It should be easy to switch to a new persistence provider.
6. If an application bundles a persistence provider that is referenced from their persistence unit(s), use the bundled persistence provider (even if its a different version of Hibernate that supports JPA 2.0).
7. Peace.
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-16271]
Create a new document in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
[View Less]
14 years, 2 months
