[jira] [Created] (ARIES-1353) NullpointerException when trying to log an exception
Jürgen Kindler created ARIES-1353:
-
Summary: NullpointerException when trying to log an exception
Key: ARIES-1353
URL: https://issues.apache.org/jira/browse/ARIES-1353
Project: Aries
Issue Type: Bug
Components: Blueprint
Affects Versions: blueprint-core-1.4.3
Reporter: Jürgen Kindler
During installation of a feature in Karaf, I get the following exception in
blueprint core 1.4.3:
{panel}
Caused by: java.lang.NullPointerException
at
org.apache.aries.blueprint.container.BeanRecipe.getInstance(BeanRecipe.java:300)[15:org.apache.aries.blueprint.core:1.4.3]
at
org.apache.aries.blueprint.container.BeanRecipe.internalCreate2(BeanRecipe.java:806)[15:org.apache.aries.blueprint.core:1.4.3]
at
org.apache.aries.blueprint.container.BeanRecipe.internalCreate(BeanRecipe.java:787)[15:org.apache.aries.blueprint.core:1.4.3]
at
org.apache.aries.blueprint.di.AbstractRecipe$1.call(AbstractRecipe.java:79)[15:org.apache.aries.blueprint.core:1.4.3]
at java.util.concurrent.FutureTask.run(FutureTask.java:262)[:1.7.0_67]
at
org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:88)[15:org.apache.aries.blueprint.core:1.4.3]
at
org.apache.aries.blueprint.di.RefRecipe.internalCreate(RefRecipe.java:62)[15:org.apache.aries.blueprint.core:1.4.3]
at
org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:106)[15:org.apache.aries.blueprint.core:1.4.3]
at
org.apache.aries.blueprint.container.ServiceRecipe.createService(ServiceRecipe.java:284)[15:org.apache.aries.blueprint.core:1.4.3]
... 38 more
{panel}
Looks like when logging the exception in the exception handler getType()
returns null :
{code}
try {
Map.EntryMethod, ListObject match =
matches.entrySet().iterator().next();
instance = invoke(match.getKey(), factoryObj,
match.getValue().toArray());
} catch (Throwable e) {
/* line 300! */ throw new
ComponentDefinitionException(Error when instantiating bean + getName() +
of class + getType().getName(), getRealCause(e));
}
{code}
So it is not clear what the real reason for the problem is ... :-(
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (ARIES-1353) NullpointerException when trying to log an exception
[
https://issues.apache.org/jira/browse/ARIES-1353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schneider updated ARIES-1353:
---
Fix Version/s: blueprint-core-1.4.5
NullpointerException when trying to log an exception
Key: ARIES-1353
URL: https://issues.apache.org/jira/browse/ARIES-1353
Project: Aries
Issue Type: Bug
Components: Blueprint
Affects Versions: blueprint-core-1.4.3
Reporter: Jürgen Kindler
Fix For: blueprint-core-1.4.5
During installation of a feature in Karaf, I get the following exception in
blueprint core 1.4.3:
{panel}
Caused by: java.lang.NullPointerException
at
org.apache.aries.blueprint.container.BeanRecipe.getInstance(BeanRecipe.java:300)[15:org.apache.aries.blueprint.core:1.4.3]
at
org.apache.aries.blueprint.container.BeanRecipe.internalCreate2(BeanRecipe.java:806)[15:org.apache.aries.blueprint.core:1.4.3]
at
org.apache.aries.blueprint.container.BeanRecipe.internalCreate(BeanRecipe.java:787)[15:org.apache.aries.blueprint.core:1.4.3]
at
org.apache.aries.blueprint.di.AbstractRecipe$1.call(AbstractRecipe.java:79)[15:org.apache.aries.blueprint.core:1.4.3]
at java.util.concurrent.FutureTask.run(FutureTask.java:262)[:1.7.0_67]
at
org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:88)[15:org.apache.aries.blueprint.core:1.4.3]
at
org.apache.aries.blueprint.di.RefRecipe.internalCreate(RefRecipe.java:62)[15:org.apache.aries.blueprint.core:1.4.3]
at
org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:106)[15:org.apache.aries.blueprint.core:1.4.3]
at
org.apache.aries.blueprint.container.ServiceRecipe.createService(ServiceRecipe.java:284)[15:org.apache.aries.blueprint.core:1.4.3]
... 38 more
{panel}
Looks like when logging the exception in the exception handler getType()
returns null :
{code}
try {
Map.EntryMethod, ListObject match =
matches.entrySet().iterator().next();
instance = invoke(match.getKey(), factoryObj,
match.getValue().toArray());
} catch (Throwable e) {
/* line 300! */ throw new
ComponentDefinitionException(Error when instantiating bean + getName() +
of class + getType().getName(), getRealCause(e));
}
{code}
So it is not clear what the real reason for the problem is ... :-(
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (ARIES-712) Supporting application specific variables
[ https://issues.apache.org/jira/browse/ARIES-712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Balazs Zsoldos closed ARIES-712. Resolution: Won't Fix Closing this issue as it is not relevant for the reporter anymore and no one else is interested in such solution. Supporting application specific variables - Key: ARIES-712 URL: https://issues.apache.org/jira/browse/ARIES-712 Project: Aries Issue Type: Brainstorming Components: Blueprint, JPA Reporter: Balazs Zsoldos Starting with OSGI I met a problem that I could not solve in any general way till now: I would like to use the same module from different applications but with slightly different configuration. More specifically: I would like to create a bundle that contains persistence services. I would like to use this bundle from several applications but with different database which means I would like to use different persistence units. Currently I can use jpa:context ... to define a container managed EntityManager in my service beans. It is a very nice way however I cannot make the unit-name dynamic in this tag. My database schema is used as part of many different application (schema to handle permissions). I am thinking since days and it seems to me that a solution like the following would solve my problem: - Having a service called ApplicationService. This has methods: setApplicationParameter(String paramName, Object value); getApplicationParameter... The parameters of the current application are stored in a thread local variable. - Having a new blueprint tag: app:parameter name=someName ref=... /. This tag does the followings: - Works the same as PropertyPlaceHolderConfigurer to eliminate possible duplicate configurations - Wraps all services in the way that when a function is called on them the application parameters are set and when it returns the olda application parameters are re-set (if there were any) - Having a possibility inside jpa:context .../ where the unit-name comes from application parameters. With that the bundle is re-usable while many different applications can use it with their database. - Better would be not to define unit-name but entity manager factory itself as an application parameter as it makes it necessary that the persistence unit exists when the bundle that contains the application parameters is deployed. Note that I do not talk here about the Aries EBA solution. I would like to have as less jars in my JVM as it is possible. Please let me know if you like this kind of approach as in that case I will check if I have time to implement it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARIES-736) Aries does not take into account the concept of complete/incomplete Persistence Units
[ https://issues.apache.org/jira/browse/ARIES-736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider updated ARIES-736: -- Fix Version/s: (was: jpa-2.0.0) jpa-2.1.0 Aries does not take into account the concept of complete/incomplete Persistence Units - Key: ARIES-736 URL: https://issues.apache.org/jira/browse/ARIES-736 Project: Aries Issue Type: Bug Components: JPA Affects Versions: 0.3 Reporter: Christoph Läubrich Assignee: Christian Schneider Fix For: jpa-2.1.0 The OSGi spec states (r4.2 127.3.1): Entity Manager Factory service - Provides an EntityManagerFactory object that depends on a complete Persistence Unit. That is, it is associated with a registered Data Source Factory service. The current behaiviour is, that aries registers a Entity Manager Factory service regardles of the precence of a matching Data Source Factory service (Also see 127.5.3 Data Source Factory Service Matching). If no such matching is performed, it alternateively must register a Entity Manager Factory Builder service (not currently supported by Aries see ARIES-735 for reference). What infact is unclear to me is: 127.5.3 states that: Once the Data Source Factory is obtained, the JPA Provider must obtain a DataSource object. This Data Source object must then be used for all relational database access. It does not state how this DataSource could be handed over to the PersistenceProvider for later usage. It might be suitable to insert a level of indirection here: - Aries just reads the persitence units and registers an Entity Manager Factory Builder service - PersistencProvider specific bundles match these with the required data source and register the Entity Manager Factory service -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (ARIES-841) JPA PersistenceBundleManager does not wait for TransactionSynchronizationRegistry to be available
[ https://issues.apache.org/jira/browse/ARIES-841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved ARIES-841. --- Resolution: Fixed Assignee: Christian Schneider Fix Version/s: jpa-2.0.0 In Aries JPA 2.0.0 the EntityManagerFactory service for JTA persistence units will only be created if PersistenceProvider, TransactionManager and DataSource are available and be closed if one of this goes away. JPA PersistenceBundleManager does not wait for TransactionSynchronizationRegistry to be available - Key: ARIES-841 URL: https://issues.apache.org/jira/browse/ARIES-841 Project: Aries Issue Type: Bug Components: JPA Environment: Apache Aries Transaction Manager and JPA Reporter: Balazs Zsoldos Assignee: Christian Schneider Fix For: jpa-2.0.0 If a persistence unit uses JTA as transaction type it would be useful if the Aries JPA would take that PU live only when TransactionSynchronizationRegistry OSGI service is available. Without that we have to take care that the aries transaction* bundles are before the aries JPA bundles in the starting queue. Please note that this issue is similar to ARIES-840. Steps to reproduce: - Check out https://guest:gu...@source.everit.biz:443/svn/everit-osgi/trunk - Run mvn clean install. As a result you will see that hibernate tests run from the hibernate/tests/core project - Edit the hibernate/tests/core/pom.xml file: Take the org.apache.aries.transaction.manager dependency to the end of the dependency list - Run the mvn clean install again. As now the DataSourceFactory will be available later than the aries.jpa.container is initialized the solution will not work -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARIES-1295) container-context - unit map properties not used to create EntityManager
[ https://issues.apache.org/jira/browse/ARIES-1295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14631014#comment-14631014 ] Christian Schneider commented on ARIES-1295: Does this issue still occur with the current code base? container-context - unit map properties not used to create EntityManager Key: ARIES-1295 URL: https://issues.apache.org/jira/browse/ARIES-1295 Project: Aries Issue Type: Bug Components: JPA Affects Versions: jpa-container-context-1.0.4 Reporter: Giuseppe Gerla properties that are defined with jpa:map in jpa:unit section are NOT used to create the EnetityManager. Properties specified in jpa:map section are passed to JTAEntityManagerHandler to create an EnetityManager managed with the call manager = emf.createEntityManager (props); where emf is an instance of QuiesceEMFHandler. The EntityManagerFactory implementation first create an EntityManager and then add properties passed. So properties are NOT used for the creation. I created a test to show that this does not work. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARIES-933) IllegalStateException when the peristence bundle gets resolved.
[ https://issues.apache.org/jira/browse/ARIES-933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14630950#comment-14630950 ] Christian Schneider commented on ARIES-933: --- Can you retest the issue with Aries jpa 2. There I have implemented a 2 staged approach. When the bundle gets resolved the EntityManagerFactory is created without a DataSource just too give the persistence provider a chance to enhance the classes. Then in a second stage the real EntityManagerFactory is created when the DataSource or DataSourceFactory service is available. IllegalStateException when the peristence bundle gets resolved. --- Key: ARIES-933 URL: https://issues.apache.org/jira/browse/ARIES-933 Project: Aries Issue Type: Bug Components: JPA Affects Versions: 0.3, 1.0 Reporter: Ioannis Canellos Assignee: Christian Schneider Fix For: jpa-2.0.0 Attachments: ARIES-933.patch Aries JPA tries to create the entity manager factories when the persistence bundle gets in resolved state. With some persistence providers this can cause issues. For example Hibernate will try to access the datasource via jndi when creating the EMF, causing the IllegalStateException due to the fact that the persistnce bundle still has not context (is in resolved state). Even worse it will leave the EntityManagerFactoryManager is a wrong state, preventing it to create the EMF when the bundle is created. There are two ways of approaching this issue: i) Don't try to create EMF when the persistence bundle gets resolved. ii) Catch possible errors and cleanup, so that EMF can be created when the bundle gets started. I am going to attach a patch for the first appraoch, unless there is a good way for creating EMF when the bundle gets resolved. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (ARIES-933) IllegalStateException when the peristence bundle gets resolved.
[ https://issues.apache.org/jira/browse/ARIES-933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved ARIES-933. --- Resolution: Fixed Fix Version/s: jpa-2.0.0 IllegalStateException when the peristence bundle gets resolved. --- Key: ARIES-933 URL: https://issues.apache.org/jira/browse/ARIES-933 Project: Aries Issue Type: Bug Components: JPA Affects Versions: 0.3, 1.0 Reporter: Ioannis Canellos Assignee: Christian Schneider Fix For: jpa-2.0.0 Attachments: ARIES-933.patch Aries JPA tries to create the entity manager factories when the persistence bundle gets in resolved state. With some persistence providers this can cause issues. For example Hibernate will try to access the datasource via jndi when creating the EMF, causing the IllegalStateException due to the fact that the persistnce bundle still has not context (is in resolved state). Even worse it will leave the EntityManagerFactoryManager is a wrong state, preventing it to create the EMF when the bundle is created. There are two ways of approaching this issue: i) Don't try to create EMF when the persistence bundle gets resolved. ii) Catch possible errors and cleanup, so that EMF can be created when the bundle gets started. I am going to attach a patch for the first appraoch, unless there is a good way for creating EMF when the bundle gets resolved. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (ARIES-516) Aries JPA container is very chatty when discovering persistence units
[ https://issues.apache.org/jira/browse/ARIES-516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved ARIES-516. --- Resolution: Fixed Assignee: Christian Schneider Fix Version/s: jpa-2.0.0 Can you check if this still applies for current versions and reopen if applicable? Aries JPA container is very chatty when discovering persistence units - Key: ARIES-516 URL: https://issues.apache.org/jira/browse/ARIES-516 Project: Aries Issue Type: Bug Components: JPA Affects Versions: 0.1, 0.2, 0.3 Reporter: Timothy Ward Assignee: Christian Schneider Fix For: jpa-2.0.0 The JPA container outputs several INFO messages for each bundle it processes, which is quite a lot of log. These should be debug level. Also the messages output when processing a WAB are wrong. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (ARIES-970) EntityManager service factory
[ https://issues.apache.org/jira/browse/ARIES-970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved ARIES-970. --- Resolution: Fixed Assignee: Christian Schneider Fix Version/s: jpa-2.0.0 Aries JPA 2 introduced the concept of an EmSupplier instead of the context bundle. EntityManagers are created when preCall is called the first time on the thread and closed when postCall is called on the outermost call. This allows to support other frameworks than blueprint. Additionally JPATemplate is introduced. It automates the transaction and EntityManager lifecycle and for example works nicely in declarative services. For Aries JPA 2.1.0 the EntityManager lifecycle will be controlled using the OSGi Coordinator service. So the boundaries can be either declared programmatically or by using @Transactional annotations. EntityManager service factory -- Key: ARIES-970 URL: https://issues.apache.org/jira/browse/ARIES-970 Project: Aries Issue Type: New Feature Components: JPA Reporter: Tuomas Kiviaho Assignee: Christian Schneider Fix For: jpa-2.0.0 It is fairly simple to utilize GlobalPersistenceManager via ServiceFactory interface to register contexts when asked for. Couple of things would make this more robust. 1) Introduction/Implementation of PersistenceContextProvider.unregisterContext() which would require counting of registration calls so that unregistration would not be premature. 2) Returning of EntityManagerFactory from PersistenceContextProvider.registerContext call which omit the roundtrip via bundle context I guess that container context project could provide this kind of implementation out of the box to support other than blueprint environments -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARIES-1026) JPA Temporary classloader cannot traverse the OSGi ClassLoader Graph
[ https://issues.apache.org/jira/browse/ARIES-1026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14631013#comment-14631013 ] Christian Schneider commented on ARIES-1026: Can you check if this still applies? As I did not change the Temporary Classloader it may still be a problem. Could you maybe create a test case for it so we can track this better? JPA Temporary classloader cannot traverse the OSGi ClassLoader Graph Key: ARIES-1026 URL: https://issues.apache.org/jira/browse/ARIES-1026 Project: Aries Issue Type: Bug Components: JPA Affects Versions: 1.0 Reporter: Timothy Ward Assignee: Timothy Ward The JPA container provides a Temporary Classloader to help JPA providers with Class Transformation. This works reasonably well, but it is possible to break it: Bundle A contains an Entity Foo Bundle A imports a package bar from bundle B bundle B contains a class bar.Baz which extends a class fizz.Buzz. Currently the Temporary ClassLoader for A cannot load bar.Baz. It successfully finds bar.Baz, but when defining it it fails to locate fizz.Buzz in the context of A. It really needs to look for it in B (without causing the class to actually be loaded!) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (ARIES-1173) 'No persistence descriptors' message confuses more people than it helps
[ https://issues.apache.org/jira/browse/ARIES-1173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved ARIES-1173. Resolution: Fixed Assignee: Christian Schneider (was: Mark Nuttall) Fix Version/s: jpa-2.0.0 The warning should not be logged anymore for Aries JPA 2.0.0 'No persistence descriptors' message confuses more people than it helps --- Key: ARIES-1173 URL: https://issues.apache.org/jira/browse/ARIES-1173 Project: Aries Issue Type: Bug Components: JPA Affects Versions: 0.4 Reporter: Mark Nuttall Assignee: Christian Schneider Priority: Minor Fix For: jpa-2.0.0 org.apache.aries.jpa.container.impl.PersistenceBundleHelper.findPersistenceXmlFiles() scans bundles for persistence.xml files. Unlike most bundles, it scans WABs even if they contain no Meta-Persistence: header in their bundle manifest. If no persistence.xml is found, it issues the no.persistence.descriptor warning, No persistence descriptors could be located in the bundle In practice this message is confusing a lot of people whose WABs don't contain persistence.xml files, and are not intended to. I propose to delete the warning altogether. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (ARIES-1347) Working example of @Transaction annotation
[ https://issues.apache.org/jira/browse/ARIES-1347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved ARIES-1347. Resolution: Fixed Fix Version/s: transaction-blueprint-1.1.0 Working example of @Transaction annotation -- Key: ARIES-1347 URL: https://issues.apache.org/jira/browse/ARIES-1347 Project: Aries Issue Type: Improvement Components: Transaction Affects Versions: transaction-blueprint-1.0.2 Environment: karaf-4.0.0, java 8 Reporter: Michał Woś Assignee: Christian Schneider Fix For: transaction-blueprint-1.1.0 Attachments: AnnotationParser.java, TxElementHandler.java Attaching working example (code) of transaction annotation. Places for improvement: - inline beans are not scanned (beanMetaData is null in that case) - ones without id service ... bean .../ /service -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (ARIES-1083) Create either a synchronised entity manager or a proxy which creates an entity manager for each request
[ https://issues.apache.org/jira/browse/ARIES-1083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved ARIES-1083. Resolution: Fixed Assignee: Christian Schneider Fix Version/s: jpa-2.0.0 In Aries JPA 2 the EntityManagers are stored per thread now. So this should not happen anymore. Create either a synchronised entity manager or a proxy which creates an entity manager for each request --- Key: ARIES-1083 URL: https://issues.apache.org/jira/browse/ARIES-1083 Project: Aries Issue Type: Improvement Components: JPA Affects Versions: jpa-container-context-1.0.1 Reporter: Joe Qiang Luo Assignee: Christian Schneider Fix For: jpa-2.0.0 When using Apache Aries (container managed Transactions, JTA) with Hibernate for persistence, if we start multiple threads to read from the database without transactions (Transaction Annotation is ommited), we get the following stacktrace: org.hibernate.AssertionFailure: possible non-threadsafe access to the session at org.hibernate.engine.internal.TwoPhaseLoad.initializeEntity(TwoPhaseLoad.java:130) at org.hibernate.loader.Loader.initializeEntitiesAndCollections(Loader.java:1103) at org.hibernate.loader.Loader.processResultSet(Loader.java:960) at org.hibernate.loader.Loader.doQuery(Loader.java:910) at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:341) at org.hibernate.loader.Loader.doList(Loader.java:2516) at org.hibernate.loader.Loader.doList(Loader.java:2502) at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2332) at org.hibernate.loader.Loader.list(Loader.java:2327) at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:490) at org.hibernate.hql.internal.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:355) at org.hibernate.engine.query.spi.HQLQueryPlan.performList(HQLQueryPlan.java:195) at org.hibernate.internal.SessionImpl.list(SessionImpl.java:1247) at org.hibernate.internal.QueryImpl.list(QueryImpl.java:101) The reason we got this exception in a non-transacted mode is that we inject EntityManager in our implementation and use it for different requests from multiple threads. Unfortunately, the EntityManager is not thread safe and we have to refactor the code to inject EntityManagerFactory instead since EntityManagerFactory is thread safe and then create EntityManagers in each method programmatically. From Aries stand point, we should be able to improve it in order to ease the pain by creating a synchronized entity manager, or a proxy which creates entity managers for each request. And the proxy would probably do the following: 1. create EntityManager; 2. perform request; 3. close EntityManager; -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (ARIES-735) Aries should support the org.osgi.service.jpa.EntityManagerFactoryBuilder service
[ https://issues.apache.org/jira/browse/ARIES-735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved ARIES-735. --- Resolution: Fixed Assignee: Christian Schneider (was: Timothy Ward) Fix Version/s: jpa-2.0.0 Aries JPA 2 now supports creation of the EntityManagerFactoryBuilder service. Aries should support the org.osgi.service.jpa.EntityManagerFactoryBuilder service - Key: ARIES-735 URL: https://issues.apache.org/jira/browse/ARIES-735 Project: Aries Issue Type: Improvement Components: JPA Affects Versions: 0.3 Reporter: Christoph Läubrich Assignee: Christian Schneider Fix For: jpa-2.0.0 The OSGi Specification describes the service as follows: This service interface offers JPA clients the ability to create instances of EntityManagerFactory for a given named persistence unit. located in org.osgi.service.jpa / JPA Package Version 1.0. Bundles wishing to use this package must list the package in the Import-Package header of the bundle's manifest. For example: Import-Package: org.osgi.service.jpa; version=[1.0,2.0) Aries seems not using this package, nor registering any service against this interface. Preffered solution: Either include this interface in the base jpa bundle or provide a seperate one and import it to register EntityManagerFactoryBuilder as described in the specification -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARIES-1296) Upgrade to transaction api 1.2
[ https://issues.apache.org/jira/browse/ARIES-1296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider updated ARIES-1296: --- Fix Version/s: transaction-blueprint-1.1.0 Upgrade to transaction api 1.2 -- Key: ARIES-1296 URL: https://issues.apache.org/jira/browse/ARIES-1296 Project: Aries Issue Type: Dependency upgrade Components: Transaction Affects Versions: transaction-manager-1.1.1 Reporter: Christian Schneider Fix For: transaction-blueprint-1.1.0 The transaction API 1.2 is needed by the most current Java EE spec. Besiides that it contains the @Transactional annotation that would allows to specify JPA without xml. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (ARIES-933) IllegalStateException when the peristence bundle gets resolved.
[ https://issues.apache.org/jira/browse/ARIES-933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider reassigned ARIES-933: - Assignee: Christian Schneider IllegalStateException when the peristence bundle gets resolved. --- Key: ARIES-933 URL: https://issues.apache.org/jira/browse/ARIES-933 Project: Aries Issue Type: Bug Components: JPA Affects Versions: 0.3, 1.0 Reporter: Ioannis Canellos Assignee: Christian Schneider Attachments: ARIES-933.patch Aries JPA tries to create the entity manager factories when the persistence bundle gets in resolved state. With some persistence providers this can cause issues. For example Hibernate will try to access the datasource via jndi when creating the EMF, causing the IllegalStateException due to the fact that the persistnce bundle still has not context (is in resolved state). Even worse it will leave the EntityManagerFactoryManager is a wrong state, preventing it to create the EMF when the bundle is created. There are two ways of approaching this issue: i) Don't try to create EMF when the persistence bundle gets resolved. ii) Catch possible errors and cleanup, so that EMF can be created when the bundle gets started. I am going to attach a patch for the first appraoch, unless there is a good way for creating EMF when the bundle gets resolved. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARIES-712) Supporting application specific variables
[ https://issues.apache.org/jira/browse/ARIES-712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14630966#comment-14630966 ] Christian Schneider commented on ARIES-712: --- I am not sure if it is a good idea to support this. It makes the code much more complicated and is only needed very seldomly. Supporting application specific variables - Key: ARIES-712 URL: https://issues.apache.org/jira/browse/ARIES-712 Project: Aries Issue Type: Brainstorming Components: Blueprint, JPA Reporter: Balazs Zsoldos Starting with OSGI I met a problem that I could not solve in any general way till now: I would like to use the same module from different applications but with slightly different configuration. More specifically: I would like to create a bundle that contains persistence services. I would like to use this bundle from several applications but with different database which means I would like to use different persistence units. Currently I can use jpa:context ... to define a container managed EntityManager in my service beans. It is a very nice way however I cannot make the unit-name dynamic in this tag. My database schema is used as part of many different application (schema to handle permissions). I am thinking since days and it seems to me that a solution like the following would solve my problem: - Having a service called ApplicationService. This has methods: setApplicationParameter(String paramName, Object value); getApplicationParameter... The parameters of the current application are stored in a thread local variable. - Having a new blueprint tag: app:parameter name=someName ref=... /. This tag does the followings: - Works the same as PropertyPlaceHolderConfigurer to eliminate possible duplicate configurations - Wraps all services in the way that when a function is called on them the application parameters are set and when it returns the olda application parameters are re-set (if there were any) - Having a possibility inside jpa:context .../ where the unit-name comes from application parameters. With that the bundle is re-usable while many different applications can use it with their database. - Better would be not to define unit-name but entity manager factory itself as an application parameter as it makes it necessary that the persistence unit exists when the bundle that contains the application parameters is deployed. Note that I do not talk here about the Aries EBA solution. I would like to have as less jars in my JVM as it is possible. Please let me know if you like this kind of approach as in that case I will check if I have time to implement it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARIES-840) DataSourceFactory must be available when persistence unit is picked up
[ https://issues.apache.org/jira/browse/ARIES-840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider updated ARIES-840: -- Fix Version/s: jpa-2.0.0 DataSourceFactory must be available when persistence unit is picked up -- Key: ARIES-840 URL: https://issues.apache.org/jira/browse/ARIES-840 Project: Aries Issue Type: Bug Components: JPA Environment: Equinox and Felix, Hibernate Reporter: Balazs Zsoldos Fix For: jpa-2.0.0 I created a hibernate adapter and tests and the following problem came out: If there is not DataSourceFactory service for the necessary JDBC driver Hibernate will not work. The reason is that with many settings Hibernate wants to access the database during creating the EntityManagerFactory. As much as I saw currently Aries works in the following way: - A DelayedLookupDataSource is created for the PersistenceUnitInfo - createContainerEntityManagerFactory is called. Here an exception may occur (Nullpointer if DataSourceFactory is used and Naming exception if service is polled via JNDI). In my opinion it would be very useful if: - Instead of DelayedLookupDataSource another DS is created which can check if the real DataSource is already available and it can access the database - If datasource and database is available the createEntityManagerFactories function is called It would be even better if: - not createEntityManagerFactories but createEntityManagerFactory would be called which means that the different DataSources would be handled separately As the best solution could be: - Handling the JNDI urls that contain service references as well in the way that a service tracker is created and closes the EntityManagerFactory if the original DS is not available anymore. (if the OSGI spec could provide a new class like JNDIUrlServiceTracker than this solution could be done in a standard way. However no such class exist in the osgi spec yet (as much as I know)). Steps to reproduce: - Check out https://guest:gu...@source.everit.biz:443/svn/everit-osgi/trunk - Run mvn clean install. As a result you will see that hibernate tests run from the hibernate/tests/core project - Edit the hibernate/tests/core/pom.xml file: Take the biz.everit.osgi.jdbc.h2 dependency to the end of the dependency list - Run the mvn clean install again. As now the DataSourceFactory will be available later than the aries.jpa.container is initialized the solution will not work For a more detailed information about this kind of testing project hierarcy (with the possibility of debugging in eclipse) please see the tutorial at http://projects.everit.biz/everit-osgi/testing/step-by-step-guide.html As much as I looked into the code of PersistenceBundleManager and related classes some refactor and code cleaning could be done (e.g. not calling always bundleStateChanged function and trying to find out inside that function why it was called...). If you are interested I could provide a patch within the next weeks how I imagine the code could be changed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (ARIES-840) DataSourceFactory must be available when persistence unit is picked up
[ https://issues.apache.org/jira/browse/ARIES-840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved ARIES-840. --- Resolution: Fixed Assignee: Christian Schneider Aries JPA 2.0.0 will detect if a persistence unit requires a DataSourceFactory. The EntityManagerFactory will only be created when the DataSourceFactory is available. DataSourceFactory must be available when persistence unit is picked up -- Key: ARIES-840 URL: https://issues.apache.org/jira/browse/ARIES-840 Project: Aries Issue Type: Bug Components: JPA Environment: Equinox and Felix, Hibernate Reporter: Balazs Zsoldos Assignee: Christian Schneider Fix For: jpa-2.0.0 I created a hibernate adapter and tests and the following problem came out: If there is not DataSourceFactory service for the necessary JDBC driver Hibernate will not work. The reason is that with many settings Hibernate wants to access the database during creating the EntityManagerFactory. As much as I saw currently Aries works in the following way: - A DelayedLookupDataSource is created for the PersistenceUnitInfo - createContainerEntityManagerFactory is called. Here an exception may occur (Nullpointer if DataSourceFactory is used and Naming exception if service is polled via JNDI). In my opinion it would be very useful if: - Instead of DelayedLookupDataSource another DS is created which can check if the real DataSource is already available and it can access the database - If datasource and database is available the createEntityManagerFactories function is called It would be even better if: - not createEntityManagerFactories but createEntityManagerFactory would be called which means that the different DataSources would be handled separately As the best solution could be: - Handling the JNDI urls that contain service references as well in the way that a service tracker is created and closes the EntityManagerFactory if the original DS is not available anymore. (if the OSGI spec could provide a new class like JNDIUrlServiceTracker than this solution could be done in a standard way. However no such class exist in the osgi spec yet (as much as I know)). Steps to reproduce: - Check out https://guest:gu...@source.everit.biz:443/svn/everit-osgi/trunk - Run mvn clean install. As a result you will see that hibernate tests run from the hibernate/tests/core project - Edit the hibernate/tests/core/pom.xml file: Take the biz.everit.osgi.jdbc.h2 dependency to the end of the dependency list - Run the mvn clean install again. As now the DataSourceFactory will be available later than the aries.jpa.container is initialized the solution will not work For a more detailed information about this kind of testing project hierarcy (with the possibility of debugging in eclipse) please see the tutorial at http://projects.everit.biz/everit-osgi/testing/step-by-step-guide.html As much as I looked into the code of PersistenceBundleManager and related classes some refactor and code cleaning could be done (e.g. not calling always bundleStateChanged function and trying to find out inside that function why it was called...). If you are interested I could provide a patch within the next weeks how I imagine the code could be changed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (ARIES-1052) Multichain dependency between Camel-CXF and aries blueprint in ServiceMix
[ https://issues.apache.org/jira/browse/ARIES-1052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved ARIES-1052. Resolution: Won't Fix Assignee: Christian Schneider I think this problem is caused by having two blueprint bundles present in the system. So I think this is not a bug in Aries. Multichain dependency between Camel-CXF and aries blueprint in ServiceMix - Key: ARIES-1052 URL: https://issues.apache.org/jira/browse/ARIES-1052 Project: Aries Issue Type: Bug Components: Blueprint, JPA Affects Versions: 1.0 Environment: ServiceMix 4.5.1 Felix Reporter: Monish Sen Assignee: Christian Schneider Priority: Minor Hi Aries Team, I tried installing Aries JPA components 1.0.0 on Servicemix 4.5.1 which is bundled with aries blueprint/proxy/util 0.3.1 version. Updated the existing aries bundles to 1.0.0 but this failed my shell. So updated startup.properties to the latest version, removed the old jars from the system folder and added the new jars in the system folders for blueprint, util, proxy. Now I'm able to startup the karaf shell, but running into Multi Chain dependency with aries blueprint export as below karaf@root ERROR: Bundle org.apache.camel.camel-cxf [175] Error starting mvn:org.apache.camel/camel-cxf/2.10.4 (org.osgi.framework.BundleException: Uses constraint violation. Unable to resolve module org.apache.camel.camel-cxf [175.0] because it is exposed to package 'org.apache.aries.blueprint' from modules org.apache.aries.blueprint [45.0] and org.apache.aries.blueprint [9.0] via two dependency chains. Chain 1: org.apache.camel.camel-cxf [175.0] import: ((package=org.apache.aries.blueprint)(version=0.3.0)(!(version=2.0.0))) | export: package=org.apache.aries.blueprint org.apache.aries.blueprint [45.0] Chain 2: org.apache.camel.camel-cxf [175.0] import: ((package=org.apache.camel.blueprint)(version=2.10.0)(!(version=3.0.0))) | export: package=org.apache.camel.blueprint; uses:=org.apache.aries.blueprint org.apache.camel.camel-blueprint [102.0] import: ((package=org.apache.aries.blueprint)(version=0.2.0)(!(version=2.0.0))) | export: package=org.apache.aries.blueprint org.apache.aries.blueprint [9.0]) org.osgi.framework.BundleException: Uses constraint violation. Unable to resolve module org.apache.camel.camel-cxf [175.0] because it is exposed to package 'org.apache.aries.blueprint' from modules org.apache.aries.blueprint [45.0] and org.apache.aries.blueprint [9.0] via two dependency chains. Chain 1: org.apache.camel.camel-cxf [175.0] import: ((package=org.apache.aries.blueprint)(version=0.3.0)(!(version=2.0.0))) | export: package=org.apache.aries.blueprint org.apache.aries.blueprint [45.0] Chain 2: org.apache.camel.camel-cxf [175.0] import: ((package=org.apache.camel.blueprint)(version=2.10.0)(!(version=3.0.0))) | export: package=org.apache.camel.blueprint; uses:=org.apache.aries.blueprint org.apache.camel.camel-blueprint [102.0] import: ((package=org.apache.aries.blueprint)(version=0.2.0)(!(version=2.0.0))) | export: package=org.apache.aries.blueprint org.apache.aries.blueprint [9.0] at org.apache.felix.framework.Felix.resolveBundle(Felix.java:3570) at org.apache.felix.framework.Felix.startBundle(Felix.java:1797) at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1192) at org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:266) at java.lang.Thread.run(Thread.java:680) ^C karaf@root Regards, Monish Sen -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (ARIES-1347) Working example of @Transaction annotation
[ https://issues.apache.org/jira/browse/ARIES-1347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider reassigned ARIES-1347: -- Assignee: Christian Schneider Working example of @Transaction annotation -- Key: ARIES-1347 URL: https://issues.apache.org/jira/browse/ARIES-1347 Project: Aries Issue Type: Improvement Components: Transaction Affects Versions: transaction-blueprint-1.0.2 Environment: karaf-4.0.0, java 8 Reporter: Michał Woś Assignee: Christian Schneider Attachments: AnnotationParser.java, TxElementHandler.java Attaching working example (code) of transaction annotation. Places for improvement: - inline beans are not scanned (beanMetaData is null in that case) - ones without id service ... bean .../ /service -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (ARIES-628) Support JTA attributes by annotations
[
https://issues.apache.org/jira/browse/ARIES-628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schneider resolved ARIES-628.
---
Resolution: Fixed
The Aries annotation @Transaction as well as the JTA 1.2 @Transactional now
both should work.
Support JTA attributes by annotations
-
Key: ARIES-628
URL: https://issues.apache.org/jira/browse/ARIES-628
Project: Aries
Issue Type: New Feature
Components: Transaction
Reporter: Jean-Baptiste Onofré
Assignee: Timothy Ward
currently, we can use a Blueprint descriptor to define the transaction
attribute associated to methods:
bean id=myPojo class=myPojo init-method=init
tx:transaction method=set* value=Required/
tx:transaction method=get* value=Supported/
/bean
I think it could be interesting for the users to define transaction
attributes directly in the POJO using annotations.
For instance, it could be helpful to support the following annotations:
@PostConstruct
@PreDestroy
@Resource
@TransactionAttribute
For instance, myPojo will look like:
public class MyPojo {
@TransactionAttribute=Required
public void setData(Data data) {
...
}
}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (ARIES-628) Support JTA attributes by annotations
[
https://issues.apache.org/jira/browse/ARIES-628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schneider updated ARIES-628:
--
Fix Version/s: transaction-blueprint-1.1.0
Support JTA attributes by annotations
-
Key: ARIES-628
URL: https://issues.apache.org/jira/browse/ARIES-628
Project: Aries
Issue Type: New Feature
Components: Transaction
Reporter: Jean-Baptiste Onofré
Assignee: Timothy Ward
Fix For: transaction-blueprint-1.1.0
currently, we can use a Blueprint descriptor to define the transaction
attribute associated to methods:
bean id=myPojo class=myPojo init-method=init
tx:transaction method=set* value=Required/
tx:transaction method=get* value=Supported/
/bean
I think it could be interesting for the users to define transaction
attributes directly in the POJO using annotations.
For instance, it could be helpful to support the following annotations:
@PostConstruct
@PreDestroy
@Resource
@TransactionAttribute
For instance, myPojo will look like:
public class MyPojo {
@TransactionAttribute=Required
public void setData(Data data) {
...
}
}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ARIES-964) Support for bundle fragments
[ https://issues.apache.org/jira/browse/ARIES-964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14630959#comment-14630959 ] Christian Schneider commented on ARIES-964: --- Can you check if the issue still exists with Aries JPA 2 ? Support for bundle fragments Key: ARIES-964 URL: https://issues.apache.org/jira/browse/ARIES-964 Project: Aries Issue Type: New Feature Components: JPA Reporter: Tuomas Kiviaho Attachments: PersistenceBundleHelper.java, PersistenceBundleHelper.java, PersistenceBundleManager.patch Currently it's possible to have both persistence.xml and Meta-Persistence: attribute declared on fragment bundle, but it's not very practical because PersistenceUnitInfo#getClassLoader() will return null causing providers to fall apart and there won't be any emf's available because the bundle stays at RESOLVED state. I tried to circumvent this by declaring Meta-Persistence: at fragment's host, but required a bit modification to PersistenceBundleHelper#findPersistenceXmlFiles to use BundleWiring#findEntries (when it's available) Update: Although ACTIVE state is now considered instead of resolved state, this issue is still valid for (multiple) fragment support. Patches are not that out-of-date, but I'd gladly send repatches if so deemed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARIES-1153) EntityManagerFactoryManager: No Exception logging during EMF creation
[ https://issues.apache.org/jira/browse/ARIES-1153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14630962#comment-14630962 ] Christian Schneider commented on ARIES-1153: This should be fixed in aries jpa 2. EntityManagerFactoryManager: No Exception logging during EMF creation - Key: ARIES-1153 URL: https://issues.apache.org/jira/browse/ARIES-1153 Project: Aries Issue Type: Bug Components: JPA Affects Versions: jpa-container-context-1.0.1 Reporter: Alexander Grzesik Fix For: jpa-2.0.0 In EntityManagerFactoryManager.createEntityManagerFactories the loop to create the EntityManagerFactories is surrounded by try block, but there is no catch and log of an exception that occurs during creating the EntityManagerFactory. Any exception is silently catched and the EMF is not created. There is no trace in the log what went wrong. Adding a catch with log of an exception that occured here would be very helpfull to track problems with persistence configuration. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARIES-1153) EntityManagerFactoryManager: No Exception logging during EMF creation
[ https://issues.apache.org/jira/browse/ARIES-1153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider updated ARIES-1153: --- Fix Version/s: jpa-2.0.0 EntityManagerFactoryManager: No Exception logging during EMF creation - Key: ARIES-1153 URL: https://issues.apache.org/jira/browse/ARIES-1153 Project: Aries Issue Type: Bug Components: JPA Affects Versions: jpa-container-context-1.0.1 Reporter: Alexander Grzesik Fix For: jpa-2.0.0 In EntityManagerFactoryManager.createEntityManagerFactories the loop to create the EntityManagerFactories is surrounded by try block, but there is no catch and log of an exception that occurs during creating the EntityManagerFactory. Any exception is silently catched and the EMF is not created. There is no trace in the log what went wrong. Adding a catch with log of an exception that occured here would be very helpfull to track problems with persistence configuration. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (ARIES-1153) EntityManagerFactoryManager: No Exception logging during EMF creation
[ https://issues.apache.org/jira/browse/ARIES-1153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved ARIES-1153. Resolution: Fixed Assignee: Christian Schneider EntityManagerFactoryManager: No Exception logging during EMF creation - Key: ARIES-1153 URL: https://issues.apache.org/jira/browse/ARIES-1153 Project: Aries Issue Type: Bug Components: JPA Affects Versions: jpa-container-context-1.0.1 Reporter: Alexander Grzesik Assignee: Christian Schneider Fix For: jpa-2.0.0 In EntityManagerFactoryManager.createEntityManagerFactories the loop to create the EntityManagerFactories is surrounded by try block, but there is no catch and log of an exception that occurs during creating the EntityManagerFactory. Any exception is silently catched and the EMF is not created. There is no trace in the log what went wrong. Adding a catch with log of an exception that occured here would be very helpfull to track problems with persistence configuration. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (ARIES-736) Aries does not take into account the concept of complete/incomplete Persistence Units
[ https://issues.apache.org/jira/browse/ARIES-736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved ARIES-736. --- Resolution: Fixed Assignee: Christian Schneider (was: Timothy Ward) Fix Version/s: jpa-2.0.0 Since version 2.0.0 Aries JPA also supports creating an EntityManagerFactoryBuilder. See test org.apache.aries.jpa.container.itest.EclipseAdditionalTest Aries does not take into account the concept of complete/incomplete Persistence Units - Key: ARIES-736 URL: https://issues.apache.org/jira/browse/ARIES-736 Project: Aries Issue Type: Bug Components: JPA Affects Versions: 0.3 Reporter: Christoph Läubrich Assignee: Christian Schneider Fix For: jpa-2.0.0 The OSGi spec states (r4.2 127.3.1): Entity Manager Factory service - Provides an EntityManagerFactory object that depends on a complete Persistence Unit. That is, it is associated with a registered Data Source Factory service. The current behaiviour is, that aries registers a Entity Manager Factory service regardles of the precence of a matching Data Source Factory service (Also see 127.5.3 Data Source Factory Service Matching). If no such matching is performed, it alternateively must register a Entity Manager Factory Builder service (not currently supported by Aries see ARIES-735 for reference). What infact is unclear to me is: 127.5.3 states that: Once the Data Source Factory is obtained, the JPA Provider must obtain a DataSource object. This Data Source object must then be used for all relational database access. It does not state how this DataSource could be handed over to the PersistenceProvider for later usage. It might be suitable to insert a level of indirection here: - Aries just reads the persitence units and registers an Entity Manager Factory Builder service - PersistencProvider specific bundles match these with the required data source and register the Entity Manager Factory service -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (ARIES-1296) Upgrade to transaction api 1.2
[ https://issues.apache.org/jira/browse/ARIES-1296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved ARIES-1296. Resolution: Fixed Assignee: Christian Schneider Transaction blueprint now works with JTA 1.2. It is not necessary to upgrade the version in transaction manager as it is compatible. Upgrade to transaction api 1.2 -- Key: ARIES-1296 URL: https://issues.apache.org/jira/browse/ARIES-1296 Project: Aries Issue Type: Dependency upgrade Components: Transaction Affects Versions: transaction-blueprint-1.0.2 Reporter: Christian Schneider Assignee: Christian Schneider Fix For: transaction-blueprint-1.1.0 The transaction API 1.2 is needed by the most current Java EE spec. Besiides that it contains the @Transactional annotation that would allows to specify JPA without xml. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARIES-1296) Upgrade to transaction api 1.2
[ https://issues.apache.org/jira/browse/ARIES-1296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider updated ARIES-1296: --- Affects Version/s: (was: transaction-manager-1.1.1) transaction-blueprint-1.0.2 Upgrade to transaction api 1.2 -- Key: ARIES-1296 URL: https://issues.apache.org/jira/browse/ARIES-1296 Project: Aries Issue Type: Dependency upgrade Components: Transaction Affects Versions: transaction-blueprint-1.0.2 Reporter: Christian Schneider Fix For: transaction-blueprint-1.1.0 The transaction API 1.2 is needed by the most current Java EE spec. Besiides that it contains the @Transactional annotation that would allows to specify JPA without xml. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARIES-1295) container-context - unit map properties not used to create EntityManager
[ https://issues.apache.org/jira/browse/ARIES-1295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14631156#comment-14631156 ] Giuseppe Gerla commented on ARIES-1295: --- No. In the current code base we introduce configuration parameters to manage this functionality. I think also that jpa:map has no sense with current code base. Wdyt? container-context - unit map properties not used to create EntityManager Key: ARIES-1295 URL: https://issues.apache.org/jira/browse/ARIES-1295 Project: Aries Issue Type: Bug Components: JPA Affects Versions: jpa-container-context-1.0.4 Reporter: Giuseppe Gerla properties that are defined with jpa:map in jpa:unit section are NOT used to create the EnetityManager. Properties specified in jpa:map section are passed to JTAEntityManagerHandler to create an EnetityManager managed with the call manager = emf.createEntityManager (props); where emf is an instance of QuiesceEMFHandler. The EntityManagerFactory implementation first create an EntityManager and then add properties passed. So properties are NOT used for the creation. I created a test to show that this does not work. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARIES-1295) container-context - unit map properties not used to create EntityManager
[ https://issues.apache.org/jira/browse/ARIES-1295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14631166#comment-14631166 ] Christian Schneider commented on ARIES-1295: I have not seen jpa:map in any persistence.xml. So I am not really sure what this issue is about. As you created I think you can decide best if it is still valid. container-context - unit map properties not used to create EntityManager Key: ARIES-1295 URL: https://issues.apache.org/jira/browse/ARIES-1295 Project: Aries Issue Type: Bug Components: JPA Affects Versions: jpa-container-context-1.0.4 Reporter: Giuseppe Gerla properties that are defined with jpa:map in jpa:unit section are NOT used to create the EnetityManager. Properties specified in jpa:map section are passed to JTAEntityManagerHandler to create an EnetityManager managed with the call manager = emf.createEntityManager (props); where emf is an instance of QuiesceEMFHandler. The EntityManagerFactory implementation first create an EntityManager and then add properties passed. So properties are NOT used for the creation. I created a test to show that this does not work. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARIES-1295) container-context - unit map properties not used to create EntityManager
[ https://issues.apache.org/jira/browse/ARIES-1295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14631175#comment-14631175 ] Giuseppe Gerla commented on ARIES-1295: --- OK. So as I said we can remove this section. I saw that it is already removed in jpa1.0.xsd Il 17/lug/2015 12:38, Christian Schneider (JIRA) j...@apache.org ha container-context - unit map properties not used to create EntityManager Key: ARIES-1295 URL: https://issues.apache.org/jira/browse/ARIES-1295 Project: Aries Issue Type: Bug Components: JPA Affects Versions: jpa-container-context-1.0.4 Reporter: Giuseppe Gerla properties that are defined with jpa:map in jpa:unit section are NOT used to create the EnetityManager. Properties specified in jpa:map section are passed to JTAEntityManagerHandler to create an EnetityManager managed with the call manager = emf.createEntityManager (props); where emf is an instance of QuiesceEMFHandler. The EntityManagerFactory implementation first create an EntityManager and then add properties passed. So properties are NOT used for the creation. I created a test to show that this does not work. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] aries pull request: ARIES-628 fix transaction itests
GitHub user maxbruecken opened a pull request: https://github.com/apache/aries/pull/26 ARIES-628 fix transaction itests use right version of org.apache.aries.transaction.blueprint to fix transaction itests after commit 70e39b6 You can merge this pull request into a Git repository by running: $ git pull https://github.com/maxbruecken/aries ARIES-628-itests Alternatively you can review and apply these changes as the patch at: https://github.com/apache/aries/pull/26.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #26 commit 50436efbe6e414ce18a106d6149cd2d716634d0d Author: maxbruecken maxim.bec...@gmx.de Date: 2015-07-17T19:10:16Z ARIES-628 use right version of org.apache.aries.transaction.blueprint to fix itests after commit 70e39b6 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] aries pull request: ARIES-1324: allow to use annotations and confi...
Github user maxbruecken closed the pull request at: https://github.com/apache/aries/pull/23 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (ARIES-628) Support JTA attributes by annotations
[
https://issues.apache.org/jira/browse/ARIES-628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14631769#comment-14631769
]
ASF GitHub Bot commented on ARIES-628:
--
GitHub user maxbruecken opened a pull request:
https://github.com/apache/aries/pull/26
ARIES-628 fix transaction itests
use right version of org.apache.aries.transaction.blueprint to fix
transaction itests after commit 70e39b6
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/maxbruecken/aries ARIES-628-itests
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/aries/pull/26.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #26
commit 50436efbe6e414ce18a106d6149cd2d716634d0d
Author: maxbruecken maxim.bec...@gmx.de
Date: 2015-07-17T19:10:16Z
ARIES-628 use right version of org.apache.aries.transaction.blueprint to
fix itests after commit 70e39b6
Support JTA attributes by annotations
-
Key: ARIES-628
URL: https://issues.apache.org/jira/browse/ARIES-628
Project: Aries
Issue Type: New Feature
Components: Transaction
Reporter: Jean-Baptiste Onofré
Assignee: Timothy Ward
Fix For: transaction-blueprint-1.1.0
currently, we can use a Blueprint descriptor to define the transaction
attribute associated to methods:
bean id=myPojo class=myPojo init-method=init
tx:transaction method=set* value=Required/
tx:transaction method=get* value=Supported/
/bean
I think it could be interesting for the users to define transaction
attributes directly in the POJO using annotations.
For instance, it could be helpful to support the following annotations:
@PostConstruct
@PreDestroy
@Resource
@TransactionAttribute
For instance, myPojo will look like:
public class MyPojo {
@TransactionAttribute=Required
public void setData(Data data) {
...
}
}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ARIES-1324) Allow to use Blueprint annotations and configuration files simultaneously
[ https://issues.apache.org/jira/browse/ARIES-1324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14631770#comment-14631770 ] ASF GitHub Bot commented on ARIES-1324: --- Github user maxbruecken closed the pull request at: https://github.com/apache/aries/pull/23 Allow to use Blueprint annotations and configuration files simultaneously - Key: ARIES-1324 URL: https://issues.apache.org/jira/browse/ARIES-1324 Project: Aries Issue Type: Improvement Components: Blueprint Affects Versions: blueprint-core-1.3.0 Reporter: Maxim Becker Assignee: Guillaume Nodet Fix For: blueprint-core-1.4.4 Currently it is not possible to mix Blueprint annotations and configuration files in same bundle. In some cases (e.g. using of tx:enable-annotation or autzh:enable) it is necessary to use configuration file, but on the other side the annotations are closer to the code. It would be great to allow to use Blueprint annotations and configuration files simultaneously. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (ARIES-955) EventDispatcher: Error during dispatch. java.lang.NullPointerException
[
https://issues.apache.org/jira/browse/ARIES-955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14632172#comment-14632172
]
Alexander Klimetschek edited comment on ARIES-955 at 7/18/15 12:53 AM:
---
Same here, both NPEs (only different line no for ServiceReferenceImpl), using
Apache Sling + Felix (where both NPEs occur). FELIX-4520 seems related (the
ResolverImpl NPE).
Happened while developing a BundleListener that sometimes threw exceptions (not
sure if related) and continuous start/stop/update/install/uninstall of bundles.
{noformat}
16.07.2015 19:28:04.011 *ERROR* [OsgiInstallerImpl]
org.apache.sling.installer.core.impl.OsgiInstallerImpl Uncaught exception
during task execution!
java.lang.NullPointerException: null
at
org.apache.felix.framework.resolver.ResolverImpl.calculatePackageSpaces(ResolverImpl.java:553)
at
org.apache.felix.framework.resolver.ResolverImpl.calculatePackageSpaces(ResolverImpl.java:629)
at
org.apache.felix.framework.resolver.ResolverImpl.resolve(ResolverImpl.java:183)
at
org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:412)
at
org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:4088)
at org.apache.felix.framework.Felix.startBundle(Felix.java:2114)
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:977)
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:964)
at
org.apache.sling.installer.core.impl.tasks.RestartActiveBundlesTask.execute(RestartActiveBundlesTask.java:75)
at
org.apache.sling.installer.core.impl.OsgiInstallerImpl.doExecuteTasks(OsgiInstallerImpl.java:847)
at
org.apache.sling.installer.core.impl.OsgiInstallerImpl.executeTasks(OsgiInstallerImpl.java:689)
at
org.apache.sling.installer.core.impl.OsgiInstallerImpl.run(OsgiInstallerImpl.java:265)
at java.lang.Thread.run(Thread.java:745)
16.07.2015 19:30:49.836 *ERROR* [FelixDispatchQueue]
com.adobe.cq.cq-creativecloud-ui FrameworkEvent ERROR
(java.lang.NullPointerException)
java.lang.NullPointerException: null
at
org.apache.felix.framework.ServiceRegistrationImpl$ServiceReferenceImpl.isAssignableTo(ServiceRegistrationImpl.java:617)
at
org.apache.felix.framework.util.Util.isServiceAssignable(Util.java:315)
at
org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:971)
at
org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:838)
at
org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:545)
at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4547)
at org.apache.felix.framework.Felix.registerService(Felix.java:3521)
at
org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:348)
at
org.apache.felix.scr.impl.manager.AbstractComponentManager$3.register(AbstractComponentManager.java:869)
at
org.apache.felix.scr.impl.manager.AbstractComponentManager$3.register(AbstractComponentManager.java:857)
at
org.apache.felix.scr.impl.manager.RegistrationManager.changeRegistration(RegistrationManager.java:133)
at
org.apache.felix.scr.impl.manager.AbstractComponentManager.registerService(AbstractComponentManager.java:915)
at
org.apache.felix.scr.impl.manager.AbstractComponentManager.activateInternal(AbstractComponentManager.java:715)
at
org.apache.felix.scr.impl.manager.AbstractComponentManager.enable(AbstractComponentManager.java:399)
at
org.apache.felix.scr.impl.config.ConfigurableComponentHolder.enableComponents(ConfigurableComponentHolder.java:669)
at
org.apache.felix.scr.impl.BundleComponentActivator.initialEnable(BundleComponentActivator.java:184)
at
org.apache.felix.scr.impl.Activator.loadComponents(Activator.java:332)
at org.apache.felix.scr.impl.Activator.access$000(Activator.java:49)
at
org.apache.felix.scr.impl.Activator$ScrExtension.start(Activator.java:257)
at
org.apache.felix.utils.extender.AbstractExtender.createExtension(AbstractExtender.java:259)
at
org.apache.felix.utils.extender.AbstractExtender.modifiedBundle(AbstractExtender.java:232)
at
org.osgi.util.tracker.BundleTracker$Tracked.customizerModified(BundleTracker.java:482)
at
org.osgi.util.tracker.BundleTracker$Tracked.customizerModified(BundleTracker.java:415)
at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:232)
at
org.osgi.util.tracker.BundleTracker$Tracked.bundleChanged(BundleTracker.java:444)
at
org.apache.felix.framework.util.EventDispatcher.invokeBundleListenerCallback(EventDispatcher.java:913)
at
[jira] [Commented] (ARIES-955) EventDispatcher: Error during dispatch. java.lang.NullPointerException
[
https://issues.apache.org/jira/browse/ARIES-955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14632172#comment-14632172
]
Alexander Klimetschek commented on ARIES-955:
-
Same here, both NPEs (only different line no for ServiceReferenceImpl), using
Apache Felix (where both NPEs occur). FELIX-4520 seems related (the
ResolverImpl NPE).
Happened while developing a BundleListener that sometimes threw exceptions (not
sure if related) and continuous start/stop/update/install/uninstall of bundles.
{noformat}
16.07.2015 19:28:04.011 *ERROR* [OsgiInstallerImpl]
org.apache.sling.installer.core.impl.OsgiInstallerImpl Uncaught exception
during task execution!
java.lang.NullPointerException: null
at
org.apache.felix.framework.resolver.ResolverImpl.calculatePackageSpaces(ResolverImpl.java:553)
at
org.apache.felix.framework.resolver.ResolverImpl.calculatePackageSpaces(ResolverImpl.java:629)
at
org.apache.felix.framework.resolver.ResolverImpl.resolve(ResolverImpl.java:183)
at
org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:412)
at
org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:4088)
at org.apache.felix.framework.Felix.startBundle(Felix.java:2114)
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:977)
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:964)
at
org.apache.sling.installer.core.impl.tasks.RestartActiveBundlesTask.execute(RestartActiveBundlesTask.java:75)
at
org.apache.sling.installer.core.impl.OsgiInstallerImpl.doExecuteTasks(OsgiInstallerImpl.java:847)
at
org.apache.sling.installer.core.impl.OsgiInstallerImpl.executeTasks(OsgiInstallerImpl.java:689)
at
org.apache.sling.installer.core.impl.OsgiInstallerImpl.run(OsgiInstallerImpl.java:265)
at java.lang.Thread.run(Thread.java:745)
16.07.2015 19:30:49.836 *ERROR* [FelixDispatchQueue]
com.adobe.cq.cq-creativecloud-ui FrameworkEvent ERROR
(java.lang.NullPointerException)
java.lang.NullPointerException: null
at
org.apache.felix.framework.ServiceRegistrationImpl$ServiceReferenceImpl.isAssignableTo(ServiceRegistrationImpl.java:617)
at
org.apache.felix.framework.util.Util.isServiceAssignable(Util.java:315)
at
org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:971)
at
org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:838)
at
org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:545)
at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4547)
at org.apache.felix.framework.Felix.registerService(Felix.java:3521)
at
org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:348)
at
org.apache.felix.scr.impl.manager.AbstractComponentManager$3.register(AbstractComponentManager.java:869)
at
org.apache.felix.scr.impl.manager.AbstractComponentManager$3.register(AbstractComponentManager.java:857)
at
org.apache.felix.scr.impl.manager.RegistrationManager.changeRegistration(RegistrationManager.java:133)
at
org.apache.felix.scr.impl.manager.AbstractComponentManager.registerService(AbstractComponentManager.java:915)
at
org.apache.felix.scr.impl.manager.AbstractComponentManager.activateInternal(AbstractComponentManager.java:715)
at
org.apache.felix.scr.impl.manager.AbstractComponentManager.enable(AbstractComponentManager.java:399)
at
org.apache.felix.scr.impl.config.ConfigurableComponentHolder.enableComponents(ConfigurableComponentHolder.java:669)
at
org.apache.felix.scr.impl.BundleComponentActivator.initialEnable(BundleComponentActivator.java:184)
at
org.apache.felix.scr.impl.Activator.loadComponents(Activator.java:332)
at org.apache.felix.scr.impl.Activator.access$000(Activator.java:49)
at
org.apache.felix.scr.impl.Activator$ScrExtension.start(Activator.java:257)
at
org.apache.felix.utils.extender.AbstractExtender.createExtension(AbstractExtender.java:259)
at
org.apache.felix.utils.extender.AbstractExtender.modifiedBundle(AbstractExtender.java:232)
at
org.osgi.util.tracker.BundleTracker$Tracked.customizerModified(BundleTracker.java:482)
at
org.osgi.util.tracker.BundleTracker$Tracked.customizerModified(BundleTracker.java:415)
at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:232)
at
org.osgi.util.tracker.BundleTracker$Tracked.bundleChanged(BundleTracker.java:444)
at
org.apache.felix.framework.util.EventDispatcher.invokeBundleListenerCallback(EventDispatcher.java:913)
at
org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:834)
at
