[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] [Created] (ARIES-854) NullpointerException in TransactionManager when felix configAdmin is used
Balazs Zsoldos created ARIES-854: Summary: NullpointerException in TransactionManager when felix configAdmin is used Key: ARIES-854 URL: https://issues.apache.org/jira/browse/ARIES-854 Project: Aries Issue Type: Bug Components: Transaction Environment: Equinox, org.apache.felix.configadmin-1.2.8, org.apache.aries.transactionmanager-1.0.0-SNAPSHOT Reporter: Balazs Zsoldos When the felix configadmin is in the OSGI container the following exception occurs: java.lang.NullPointerException at org.apache.aries.transaction.TransactionManagerService.getInt(TransactionManagerService.java:181) at org.apache.aries.transaction.TransactionManagerService.init(TransactionManagerService.java:82) at org.apache.aries.transaction.Activator.updated(Activator.java:55) at org.apache.felix.cm.impl.ConfigurationManager$ManagedServiceUpdate.run(ConfigurationManager.java:1160) at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:104) at java.lang.Thread.run(Thread.java:722) This has to do something with a patch applied to ARIES-809 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (ARIES-854) NullpointerException in TransactionManager when felix configAdmin is used
[ https://issues.apache.org/jira/browse/ARIES-854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Balazs Zsoldos updated ARIES-854: - Priority: Critical (was: Major) NullpointerException in TransactionManager when felix configAdmin is used - Key: ARIES-854 URL: https://issues.apache.org/jira/browse/ARIES-854 Project: Aries Issue Type: Bug Components: Transaction Environment: Equinox, org.apache.felix.configadmin-1.2.8, org.apache.aries.transactionmanager-1.0.0-SNAPSHOT Reporter: Balazs Zsoldos Priority: Critical Attachments: TransactionManagerService.java.patch When the felix configadmin is in the OSGI container the following exception occurs: java.lang.NullPointerException at org.apache.aries.transaction.TransactionManagerService.getInt(TransactionManagerService.java:181) at org.apache.aries.transaction.TransactionManagerService.init(TransactionManagerService.java:82) at org.apache.aries.transaction.Activator.updated(Activator.java:55) at org.apache.felix.cm.impl.ConfigurationManager$ManagedServiceUpdate.run(ConfigurationManager.java:1160) at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:104) at java.lang.Thread.run(Thread.java:722) This has to do something with a patch applied to ARIES-809 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (ARIES-854) NullpointerException in TransactionManager when felix configAdmin is used
[ https://issues.apache.org/jira/browse/ARIES-854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Balazs Zsoldos updated ARIES-854: - Environment: Equinox, org.apache.felix.configadmin-1.0.4, org.apache.aries.transactionmanager-1.0.0-SNAPSHOT (was: Equinox, org.apache.felix.configadmin-1.2.8, org.apache.aries.transactionmanager-1.0.0-SNAPSHOT) NullpointerException in TransactionManager when felix configAdmin is used - Key: ARIES-854 URL: https://issues.apache.org/jira/browse/ARIES-854 Project: Aries Issue Type: Bug Components: Transaction Environment: Equinox, org.apache.felix.configadmin-1.0.4, org.apache.aries.transactionmanager-1.0.0-SNAPSHOT Reporter: Balazs Zsoldos Priority: Critical Attachments: TransactionManagerService.java.patch When the felix configadmin is in the OSGI container the following exception occurs: java.lang.NullPointerException at org.apache.aries.transaction.TransactionManagerService.getInt(TransactionManagerService.java:181) at org.apache.aries.transaction.TransactionManagerService.init(TransactionManagerService.java:82) at org.apache.aries.transaction.Activator.updated(Activator.java:55) at org.apache.felix.cm.impl.ConfigurationManager$ManagedServiceUpdate.run(ConfigurationManager.java:1160) at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:104) at java.lang.Thread.run(Thread.java:722) This has to do something with a patch applied to ARIES-809 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[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 ] Balazs Zsoldos updated ARIES-840: - Description: 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. was: 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 a href=https://guest:gu...@source.everit.biz:443/svn/everit-osgi/trunk;https://guest:gu...@source.everit.biz:443/svn/everit-osgi/trunk/a - 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
[jira] [Commented] (ARIES-743) Subclass cannot be created by ProxySubclassGenerator when there is static final method
[ https://issues.apache.org/jira/browse/ARIES-743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13103440#comment-13103440 ] Balazs Zsoldos commented on ARIES-743: -- For all the svn repositories below guest/guest credentials work. Steps to reproduce: Check out https://source.everit.biz/svn/everit-config/everit-parent/trunk/ mvn install Check out https://source.everit.biz/svn/everit-config/everit-checkstyle/trunk/ mvn install Check out https://source.everit.biz/svn/everit-localization/trunk/ mvn install site The site generated by jacoco including the junit and integration tests metrics is located at localization-core/target/site/jacoco Subclass cannot be created by ProxySubclassGenerator when there is static final method -- Key: ARIES-743 URL: https://issues.apache.org/jira/browse/ARIES-743 Project: Aries Issue Type: Bug Components: Proxy Affects Versions: 0.3 Environment: Pax-Exam 2.2.0, Felix 3.2.0, Jacoco 5.3 Reporter: Balazs Zsoldos Attachments: staticMethodSubClass.patch Using Jacoco as a JavaAgent to get coverage reports during the unit tests I get a FinalModifierException. Reason is that Jacoco appends the classes with a private static final function. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (ARIES-743) Subclass cannot be created by ProxySubclassGenerator when there is static final method
Subclass cannot be created by ProxySubclassGenerator when there is static final method -- Key: ARIES-743 URL: https://issues.apache.org/jira/browse/ARIES-743 Project: Aries Issue Type: Bug Components: Proxy Affects Versions: 0.3 Environment: Pax-Exam 2.2.0, Felix 3.2.0, Jacoco 5.3 Reporter: Balazs Zsoldos Using Jacoco as a JavaAgent to get coverage reports during the unit tests I get a FinalModifierException. Reason is that Jacoco appends the classes with a private static final function. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (ARIES-743) Subclass cannot be created by ProxySubclassGenerator when there is static final method
[ https://issues.apache.org/jira/browse/ARIES-743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Balazs Zsoldos updated ARIES-743: - Attachment: staticMethodSubClass.patch With the applied patch everything work for me well. Jacoco test coverage reports are generated on the integration tests as well. Example and steps to reproduce will come tomorrow. Subclass cannot be created by ProxySubclassGenerator when there is static final method -- Key: ARIES-743 URL: https://issues.apache.org/jira/browse/ARIES-743 Project: Aries Issue Type: Bug Components: Proxy Affects Versions: 0.3 Environment: Pax-Exam 2.2.0, Felix 3.2.0, Jacoco 5.3 Reporter: Balazs Zsoldos Attachments: staticMethodSubClass.patch Using Jacoco as a JavaAgent to get coverage reports during the unit tests I get a FinalModifierException. Reason is that Jacoco appends the classes with a private static final function. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (ARIES-691) Add tests for EclipseLink - possibly include fragment for EclipseLink support
[ https://issues.apache.org/jira/browse/ARIES-691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13072254#comment-13072254 ] Balazs Zsoldos commented on ARIES-691: -- Hi, thank you for the explonation. It is clear and I think I understand it :). I tested the newest svn revision and everything works great. Thanks and regards, Balazs Add tests for EclipseLink - possibly include fragment for EclipseLink support - Key: ARIES-691 URL: https://issues.apache.org/jira/browse/ARIES-691 Project: Aries Issue Type: Improvement Components: JPA Affects Versions: 0.4 Reporter: Timothy Ward Assignee: Valentin Mahrwald Fix For: 0.4 Attachments: eclipselinkAdapter.patch, eclipselinkadapter.patch We should test the Aries JPA container with EclipseLink as well as OpenJPA to give us better coverage. This may involve writing code to expose the EclipseLink PersistenceProvider implementation -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (ARIES-691) Add tests for EclipseLink - possibly include fragment for EclipseLink support
[ https://issues.apache.org/jira/browse/ARIES-691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13071815#comment-13071815 ] Balazs Zsoldos commented on ARIES-691: -- Hi, I am really sorry but based on the newest compile now I get the following: java.lang.NoClassDefFoundError: org/osgi/framework/FrameworkUtil at org.apache.aries.jpa.eclipselink.adapter.platform.OSGiTSWrapper.acquireTransactionManager(OSGiTSWrapper.java:32) at org.eclipse.persistence.transaction.JTATransactionController.init(JTATransactionController.java:67) at org.apache.aries.jpa.eclipselink.adapter.platform.OSGiTSWrapper.init(OSGiTSWrapper.java:28) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:513) at java.lang.Class.newInstance0(Class.java:355) at java.lang.Class.newInstance(Class.java:308) at org.eclipse.persistence.internal.security.PrivilegedAccessHelper.newInstanceFromClass(PrivilegedAccessHelper.java:384) at org.eclipse.persistence.platform.server.ServerPlatformBase.initializeExternalTransactionController(ServerPlatformBase.java:284) at org.eclipse.persistence.internal.sessions.DatabaseSessionImpl.preConnectDatasource(DatabaseSessionImpl.java:665) at org.eclipse.persistence.internal.sessions.DatabaseSessionImpl.loginAndDetectDatasource(DatabaseSessionImpl.java:589) at org.eclipse.persistence.internal.jpa.EntityManagerFactoryProvider.login(EntityManagerFactoryProvider.java:233) at org.eclipse.persistence.internal.jpa.EntityManagerSetupImpl.deploy(EntityManagerSetupImpl.java:394) at org.eclipse.persistence.internal.jpa.EntityManagerFactoryImpl.getServerSession(EntityManagerFactoryImpl.java:185) at org.eclipse.persistence.internal.jpa.EntityManagerFactoryImpl.createEntityManagerImpl(EntityManagerFactoryImpl.java:242) at org.eclipse.persistence.internal.jpa.EntityManagerFactoryImpl.createEntityManager(EntityManagerFactoryImpl.java:237) at org.apache.aries.jpa.container.impl.CountingEntityManagerFactory.createEntityManager(CountingEntityManagerFactory.java:71) at org.apache.aries.jpa.container.context.transaction.impl.JTAPersistenceContextRegistry.getCurrentPersistenceContext(JTAPersistenceContextRegistry.java:131) at org.apache.aries.jpa.container.context.transaction.impl.JTAEntityManager.getPersistenceContext(JTAEntityManager.java:83) at org.apache.aries.jpa.container.context.transaction.impl.JTAEntityManager.persist(JTAEntityManager.java:278) at biz.everit.audit.persistence.impl.AuditServiceImpl.saveEvent(AuditServiceImpl.java:22) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.aries.proxy.impl.ProxyHandler$1.invoke(ProxyHandler.java:54) at org.apache.aries.proxy.impl.ProxyHandler.invoke(ProxyHandler.java:119) at biz.everit.audit.persistence.impl.$AuditServiceImpl41607185.saveEvent(Unknown Source) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.aries.proxy.impl.ProxyHandler$1.invoke(ProxyHandler.java:54) at org.apache.aries.proxy.impl.ProxyHandler.invoke(ProxyHandler.java:119) at biz.everit.audit.persistence.impl.$AuditServiceImpl41607185.saveEvent(Unknown Source) at biz.everit.audit.connector.jaxws.AuditService.logEvent(AuditService.java:19) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.glassfish.webservices.InstanceResolverImpl$1.invoke(InstanceResolverImpl.java:143) at com.sun.xml.ws.server.InvokerTube$2.invoke(InvokerTube.java:150) at com.sun.xml.ws.server.sei.EndpointMethodHandler.invoke(EndpointMethodHandler.java:261) at com.sun.xml.ws.server.sei.SEIInvokerTube.processRequest(SEIInvokerTube.java:100) at
[jira] [Commented] (ARIES-691) Add tests for EclipseLink - possibly include fragment for EclipseLink support
[ https://issues.apache.org/jira/browse/ARIES-691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13070276#comment-13070276 ] Balazs Zsoldos commented on ARIES-691: -- Hi, thank you really much for the changes. I really like the transaction solution (I do not have to specify sunas as the server in persistence.xml anymore). I found one more exception that I could solve really easily. In the test bundle there is no one-to-many relationship so I guess it will not come out. I noted before that there is a classnotfound exception. Eclipselink misses the IndirectList class. To solve it was really easy: adding the import-package org.eclipse.persistence.indirection to eclipselink adapter. With that everything works for me with a freshly installed glassfish 3.1. I had a quick look on the eclipselink-core jar and I did not find any other class that might has a similar behavior as the IndirectList so that one may be enough for a long time :). I do not have the rights to re-open this issue but I hope you will check this one before the next release. Thanks and regards, Balazs Add tests for EclipseLink - possibly include fragment for EclipseLink support - Key: ARIES-691 URL: https://issues.apache.org/jira/browse/ARIES-691 Project: Aries Issue Type: Improvement Components: JPA Affects Versions: 0.4 Reporter: Timothy Ward Assignee: Valentin Mahrwald Fix For: 0.4 Attachments: eclipselinkAdapter.patch, eclipselinkadapter.patch We should test the Aries JPA container with EclipseLink as well as OpenJPA to give us better coverage. This may involve writing code to expose the EclipseLink PersistenceProvider implementation -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (ARIES-681) JPA Container BundleDelegatingClassLoader should look for classes in the provider bundle, too
[ https://issues.apache.org/jira/browse/ARIES-681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13060354#comment-13060354 ] Balazs Zsoldos commented on ARIES-681: -- Hi, thank you very much for the fast response. I think as there is a new issue that has the aim to make this work this issue could be closed. I tried the solution compiled from SVN and ran into some exceptions. I will note these at ARIES-691. Regards, Balazs JPA Container BundleDelegatingClassLoader should look for classes in the provider bundle, too - Key: ARIES-681 URL: https://issues.apache.org/jira/browse/ARIES-681 Project: Aries Issue Type: Bug Components: JPA Affects Versions: 0.3 Environment: Glassfish 3.0 (EclipseLink 2.0.2), Glassfish 3.1 (EclipseLink 2.2) Reporter: Balazs Zsoldos Attachments: classloadingFromMultipleProviderDuringQuery.0.3.patch Currently the BundleDelegatingClassLoader in JPA container only looks for classes in the bundle of the entitymanager. However the JPA implementation Eclipselink needs some classes from itself. The reason is that in entity classes the properties that hold mapping of One-To-Many are converted to EclipseLink list type. See the following exception stacktrace: Internal Exception: java.lang.ClassNotFoundException: org.eclipse.persistence.indirection.IndirectList at org.eclipse.persistence.exceptions.ValidationException.classNotFoundWhileConvertingClassNames(ValidationException.java:2317) at org.eclipse.persistence.internal.queries.InterfaceContainerPolicy.convertClassNamesToClasses(InterfaceContainerPolicy.java:123) at org.eclipse.persistence.mappings.CollectionMapping.convertClassNamesToClasses(CollectionMapping.java:788) at org.eclipse.persistence.descriptors.ClassDescriptor.convertClassNamesToClasses(ClassDescriptor.java:1458) at org.eclipse.persistence.sessions.Project.convertClassNamesToClasses(Project.java:362) at org.eclipse.persistence.internal.jpa.EntityManagerSetupImpl.deploy(EntityManagerSetupImpl.java:322) ... 83 more Caused by: java.lang.ClassNotFoundException: org.eclipse.persistence.indirection.IndirectList at org.apache.felix.framework.ModuleImpl.findClassOrResourceByDelegation(ModuleImpl.java:744) at org.apache.felix.framework.ModuleImpl.access$100(ModuleImpl.java:61) at org.apache.felix.framework.ModuleImpl$ModuleClassLoader.loadClass(ModuleImpl.java:1656) at java.lang.ClassLoader.loadClass(ClassLoader.java:247) at org.apache.felix.framework.ModuleImpl.getClassByDelegation(ModuleImpl.java:604) at org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1487) at org.apache.felix.framework.BundleImpl.loadClass(BundleImpl.java:897) at org.apache.aries.jpa.container.unit.impl.BundleDelegatingClassLoader$1.run(BundleDelegatingClassLoader.java:50) at org.apache.aries.jpa.container.unit.impl.BundleDelegatingClassLoader$1.run(BundleDelegatingClassLoader.java:47) at java.security.AccessController.doPrivileged(Native Method) at org.apache.aries.jpa.container.unit.impl.BundleDelegatingClassLoader.findClass(BundleDelegatingClassLoader.java:47) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at java.lang.ClassLoader.loadClass(ClassLoader.java:247) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:247) at org.eclipse.persistence.internal.security.PrivilegedAccessHelper.getClassForName(PrivilegedAccessHelper.java:88) at org.eclipse.persistence.internal.queries.InterfaceContainerPolicy.convertClassNamesToClasses(InterfaceContainerPolicy.java:120) ... 87 more -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (ARIES-691) Add tests for EclipseLink - possibly include fragment for EclipseLink support
[ https://issues.apache.org/jira/browse/ARIES-691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13060408#comment-13060408 ] Balazs Zsoldos commented on ARIES-691: -- Hi, I have tried this solution in Glassfish 3.1. I ran into some problems: - The import-package contains version lower than 2.0 for package javax.persistence and javax.persistence.spi. However Glassfish contains version 2.0.2. (I changed it to move forward) - If there is no other application in Glassfish that uses JPA, Eclipselink bundle remains in RESOLVED state. Therefore the function handlePotentialEclipseLink is never called. I modified the source a bit that it starts the eclipselink bundle if it is in RESOLVED state. It might not be the best solution, I would be happy if you could direct me how to solve this in a better way. - To make transactions work Eclipselink must know in what environment it runs. By default it thinks that it is in a standalone program and JTA does not work. To make JTA work we must have an entry in the persistence.xml that says we are in Glassfish. However it needs a package (as all platform does) to be imported into the adapter: org.eclipse.persistence.platform.server.sunas. I think all of the packages inside platform should be imported into adapter to let the classloader find the platform dependent classes. - It seems to me that in Felix the getBundleContext() function gives back null when the Bundle is in RESOLVED state. The bundlecontext is set only when the function start() is called on the bundle. This is a problem of blueprint. It gives back a nullpointer exception when the blueprint file of a bundle is loaded. (Currently I always debug there and call the start() function by hand :)) Regards, Balazs Add tests for EclipseLink - possibly include fragment for EclipseLink support - Key: ARIES-691 URL: https://issues.apache.org/jira/browse/ARIES-691 Project: Aries Issue Type: Improvement Components: JPA Affects Versions: 0.4 Reporter: Timothy Ward Assignee: Valentin Mahrwald Fix For: 0.4 We should test the Aries JPA container with EclipseLink as well as OpenJPA to give us better coverage. This may involve writing code to expose the EclipseLink PersistenceProvider implementation -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (ARIES-691) Add tests for EclipseLink - possibly include fragment for EclipseLink support
[ https://issues.apache.org/jira/browse/ARIES-691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Balazs Zsoldos updated ARIES-691: - Attachment: eclipselinkadapter.patch Uploading a patch file that does the followings: - If the eclipselink provider bundle is found but it is in RESOLVED state it starts the bundle. - Changes the import-package entry to contain higher versions of javax.persistence and the package that is necessary for glassfish from eclipselink-core bundle With the patch my project still does not work (due to the blueprint problem) but I think it contains some necessary steps to get the goal. Also I would be really happy if I could get some response that my the patch contains changes that will be applied or I should try other solution... Regards, Balazs Add tests for EclipseLink - possibly include fragment for EclipseLink support - Key: ARIES-691 URL: https://issues.apache.org/jira/browse/ARIES-691 Project: Aries Issue Type: Improvement Components: JPA Affects Versions: 0.4 Reporter: Timothy Ward Assignee: Valentin Mahrwald Fix For: 0.4 Attachments: eclipselinkadapter.patch We should test the Aries JPA container with EclipseLink as well as OpenJPA to give us better coverage. This may involve writing code to expose the EclipseLink PersistenceProvider implementation -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (ARIES-681) JPA Container BundleDelegatingClassLoader should look for classes in the provider bundle, too
[ https://issues.apache.org/jira/browse/ARIES-681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Balazs Zsoldos resolved ARIES-681. -- Resolution: Duplicate As there is a final solution in ARIES-691 this issue will be solved as well. JPA Container BundleDelegatingClassLoader should look for classes in the provider bundle, too - Key: ARIES-681 URL: https://issues.apache.org/jira/browse/ARIES-681 Project: Aries Issue Type: Bug Components: JPA Affects Versions: 0.3 Environment: Glassfish 3.0 (EclipseLink 2.0.2), Glassfish 3.1 (EclipseLink 2.2) Reporter: Balazs Zsoldos Attachments: classloadingFromMultipleProviderDuringQuery.0.3.patch Currently the BundleDelegatingClassLoader in JPA container only looks for classes in the bundle of the entitymanager. However the JPA implementation Eclipselink needs some classes from itself. The reason is that in entity classes the properties that hold mapping of One-To-Many are converted to EclipseLink list type. See the following exception stacktrace: Internal Exception: java.lang.ClassNotFoundException: org.eclipse.persistence.indirection.IndirectList at org.eclipse.persistence.exceptions.ValidationException.classNotFoundWhileConvertingClassNames(ValidationException.java:2317) at org.eclipse.persistence.internal.queries.InterfaceContainerPolicy.convertClassNamesToClasses(InterfaceContainerPolicy.java:123) at org.eclipse.persistence.mappings.CollectionMapping.convertClassNamesToClasses(CollectionMapping.java:788) at org.eclipse.persistence.descriptors.ClassDescriptor.convertClassNamesToClasses(ClassDescriptor.java:1458) at org.eclipse.persistence.sessions.Project.convertClassNamesToClasses(Project.java:362) at org.eclipse.persistence.internal.jpa.EntityManagerSetupImpl.deploy(EntityManagerSetupImpl.java:322) ... 83 more Caused by: java.lang.ClassNotFoundException: org.eclipse.persistence.indirection.IndirectList at org.apache.felix.framework.ModuleImpl.findClassOrResourceByDelegation(ModuleImpl.java:744) at org.apache.felix.framework.ModuleImpl.access$100(ModuleImpl.java:61) at org.apache.felix.framework.ModuleImpl$ModuleClassLoader.loadClass(ModuleImpl.java:1656) at java.lang.ClassLoader.loadClass(ClassLoader.java:247) at org.apache.felix.framework.ModuleImpl.getClassByDelegation(ModuleImpl.java:604) at org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1487) at org.apache.felix.framework.BundleImpl.loadClass(BundleImpl.java:897) at org.apache.aries.jpa.container.unit.impl.BundleDelegatingClassLoader$1.run(BundleDelegatingClassLoader.java:50) at org.apache.aries.jpa.container.unit.impl.BundleDelegatingClassLoader$1.run(BundleDelegatingClassLoader.java:47) at java.security.AccessController.doPrivileged(Native Method) at org.apache.aries.jpa.container.unit.impl.BundleDelegatingClassLoader.findClass(BundleDelegatingClassLoader.java:47) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at java.lang.ClassLoader.loadClass(ClassLoader.java:247) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:247) at org.eclipse.persistence.internal.security.PrivilegedAccessHelper.getClassForName(PrivilegedAccessHelper.java:88) at org.eclipse.persistence.internal.queries.InterfaceContainerPolicy.convertClassNamesToClasses(InterfaceContainerPolicy.java:120) ... 87 more -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (ARIES-703) JDKProxyManager cannot proxy blueprint beans
JDKProxyManager cannot proxy blueprint beans Key: ARIES-703 URL: https://issues.apache.org/jira/browse/ARIES-703 Project: Aries Issue Type: Bug Components: Proxy Environment: Glassfish 3.1 Reporter: Balazs Zsoldos When there is no ASM between the bundles and aries proxy is installed the default proxy manager is JDKProxyManager. When there is a bean in a blueprint fragment that has for example tx:transaction inside creating the transactional proxy fails with the following stacktrace: [#|2011-07-06T14:29:24.542+0200|SEVERE|glassfish3.1|org.apache.aries.blueprint.container.BlueprintContainerImpl|_ThreadID=27;_ThreadName=Thread-1;|Unable to start blueprint container for bundle biz.everit.audit.persistence.biz.everit.audit.persistence.impl org.osgi.service.blueprint.container.ComponentDefinitionException: Unable to create proxy for bean eventPersistenceImpl in bundle biz.everit.audit.persistence.biz.everit.audit.persistence.impl version 0.1.0.SNAPSHOT at org.apache.aries.blueprint.container.BeanRecipe.addInterceptors(BeanRecipe.java:695) at org.apache.aries.blueprint.container.BeanRecipe.internalCreate(BeanRecipe.java:730) at org.apache.aries.blueprint.di.AbstractRecipe$1.call(AbstractRecipe.java:71) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:79) at org.apache.aries.blueprint.di.RefRecipe.internalCreate(RefRecipe.java:60) at org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:98) at org.apache.aries.blueprint.container.BlueprintRepository.createInstances(BlueprintRepository.java:220) at org.apache.aries.blueprint.container.BlueprintRepository.createInstance(BlueprintRepository.java:205) at org.apache.aries.blueprint.container.BlueprintRepository.create(BlueprintRepository.java:144) at org.apache.aries.blueprint.container.ServiceRecipe.createRecipe(ServiceRecipe.java:398) at org.apache.aries.blueprint.container.ServiceRecipe.createService(ServiceRecipe.java:271) at org.apache.aries.blueprint.container.ServiceRecipe.internalGetService(ServiceRecipe.java:243) at org.apache.aries.blueprint.container.ServiceRecipe.getService(ServiceRecipe.java:320) at org.apache.aries.blueprint.container.ServiceRecipe$TriggerServiceFactory.getService(ServiceRecipe.java:465) at org.apache.felix.framework.ServiceRegistrationImpl.getFactoryUnchecked(ServiceRegistrationImpl.java:310) at org.apache.felix.framework.ServiceRegistrationImpl.getService(ServiceRegistrationImpl.java:221) at org.apache.felix.framework.ServiceRegistry.getService(ServiceRegistry.java:297) at org.apache.felix.framework.Felix.getService(Felix.java:3014) at org.apache.felix.framework.BundleContextImpl.getService(BundleContextImpl.java:329) at org.jvnet.hk2.osgiadapter.HK2Main$HK2ServiceTrackerCustomizer.addingService(HK2Main.java:260) at org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:896) at org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:261) at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:233) at org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:840) at org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:871) at org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:733) at org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:662) at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:3769) at org.apache.felix.framework.Felix.access$000(Felix.java:80) at org.apache.felix.framework.Felix$2.serviceChanged(Felix.java:722) at org.apache.felix.framework.ServiceRegistry.registerService(ServiceRegistry.java:107) at org.apache.felix.framework.Felix.registerService(Felix.java:2854) at org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:251) at org.apache.aries.blueprint.container.BlueprintContainerImpl.registerService(BlueprintContainerImpl.java:408) at org.apache.aries.blueprint.container.ServiceRecipe.register(ServiceRecipe.java:187) at org.apache.aries.blueprint.container.BlueprintContainerImpl.registerServices(BlueprintContainerImpl.java:666) at org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:334) at org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:230)
[jira] [Updated] (ARIES-704) BundleToClassLoaderAdapter does not implement loadClass(String, boolean)
[ https://issues.apache.org/jira/browse/ARIES-704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Balazs Zsoldos updated ARIES-704: - Attachment: BundleToClassLoaderAdapter fix.patch The patch I created simply implements the loadClass(String, boolean) in a way that if the parameter resolved is true it throws an unsupported exception otherwise the original behavior will be done. BundleToClassLoaderAdapter does not implement loadClass(String, boolean) Key: ARIES-704 URL: https://issues.apache.org/jira/browse/ARIES-704 Project: Aries Issue Type: Bug Components: Util Environment: Glassfish 3.1, aries-eclipselink-adapter, JDK 1.6.0_26 Reporter: Balazs Zsoldos Attachments: BundleToClassLoaderAdapter fix.patch When there is a loadClass(String) to a classloader it simply calls loadClass(String, boolean). The second function checks if a class is available in the parent classloader by checking loadClass(String, boolean). If BundleToClassLoader adapter is used for a ClassLoader as the parent, the loadClass(String) will never be called. Here is a sample stacktrace ( line numbers from JDK 1.6.0_26): at org.apache.felix.framework.ModuleImpl.findClassOrResourceByDelegation(ModuleImpl.java:787) at org.apache.felix.framework.ModuleImpl.access$400(ModuleImpl.java:71) at org.apache.felix.framework.ModuleImpl$ModuleClassLoader.loadClass(ModuleImpl.java:1768) at java.lang.ClassLoader.loadClass(ClassLoader.java:247) at org.apache.aries.jpa.eclipselink.adapter.Activator$PersistenceUnitProxyWithTargetServer$1.findClass(Activator.java:102) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at java.lang.ClassLoader.loadClass(ClassLoader.java:247) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:247) at org.eclipse.persistence.internal.security.PrivilegedAccessHelper.getClassForName(PrivilegedAccessHelper.java:93) at org.eclipse.persistence.descriptors.ClassDescriptor.convertClassNamesToClasses(ClassDescriptor.java:1258) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (ARIES-691) Add tests for EclipseLink - possibly include fragment for EclipseLink support
[ https://issues.apache.org/jira/browse/ARIES-691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Balazs Zsoldos updated ARIES-691: - Attachment: eclipselinkAdapter.patch Hi, I made it work in my environment finally. I upload a patch that contains every change that I did (based on current svn). Please note that I found two problems: ARIES-703 and ARIES-704. The first does not come up if we have ASM in the bundle list. I provided a patch for the second that you may like. So the patch ARIES-704 is also necessary to make this patch work. There is one final problem: - I changed the EntityManagerFactoryManager to create the entitymanager factories only when the bundle is in STARTING state (not RESOLVED). This fixes the nullpointer problem at my side. However two unit tests fail in this case as createEntityManagerFactories is not called during processing them. I have not looked more into but it might be much easier to change the unit test for those who wrote it... BTW: The stacktrace of the nullpointer is the following: [#|2011-07-05T16:05:41.442+0200|SEVERE|glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=43;_ThreadName=Thread-1;|javax.persistence.PersistenceException: Exception [EclipseLink-28018] (Eclipse Persistence Services - 2.2.0.v20110202-r8913): org.eclipse.persistence.exceptions.EntityManagerSetupException Exception Description: Predeployment of PersistenceUnit [biz.everit.audit.persistence.entity] failed. Internal Exception: java.lang.NullPointerException at org.eclipse.persistence.internal.jpa.EntityManagerSetupImpl.predeploy(EntityManagerSetupImpl.java:1127) at org.eclipse.persistence.jpa.PersistenceProvider.createContainerEntityManagerFactory(PersistenceProvider.java:187) at org.apache.aries.jpa.eclipselink.adapter.Activator$EclipseLinkProviderService$1.createContainerEntityManagerFactory(Activator.java:200) at org.apache.aries.jpa.container.impl.EntityManagerFactoryManager.createEntityManagerFactories(EntityManagerFactoryManager.java:261) at org.apache.aries.jpa.container.impl.EntityManagerFactoryManager.bundleStateChange(EntityManagerFactoryManager.java:156) at org.apache.aries.jpa.container.impl.PersistenceBundleManager.modifiedBundle(PersistenceBundleManager.java:285) at org.osgi.util.tracker.BundleTracker$Tracked.customizerModified(BundleTracker.java:453) at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:237) at org.osgi.util.tracker.BundleTracker$Tracked.bundleChanged(BundleTracker.java:413) at org.apache.felix.framework.util.EventDispatcher.invokeBundleListenerCallback(EventDispatcher.java:807) at org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:729) at org.apache.felix.framework.util.EventDispatcher.fireBundleEvent(EventDispatcher.java:610) at org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:3758) at org.apache.felix.framework.Felix.access$600(Felix.java:80) at org.apache.felix.framework.Felix$FelixResolver.fireResolvedEvents(Felix.java:4296) at org.apache.felix.framework.Felix$FelixResolver.resolve(Felix.java:4062) at org.apache.felix.framework.Felix.resolveBundle(Felix.java:3436) at org.apache.felix.framework.Felix.startBundle(Felix.java:1727) at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:922) at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:1175) at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:1153) at org.apache.felix.fileinstall.internal.DirectoryWatcher.processAllBundles(DirectoryWatcher.java:1146) at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:456) at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:263) Caused by: Exception [EclipseLink-28018] (Eclipse Persistence Services - 2.2.0.v20110202-r8913): org.eclipse.persistence.exceptions.EntityManagerSetupException Exception Description: Predeployment of PersistenceUnit [biz.everit.audit.persistence.entity] failed. Internal Exception: java.lang.NullPointerException at org.eclipse.persistence.exceptions.EntityManagerSetupException.predeployFailed(EntityManagerSetupException.java:210) ... 24 more Caused by: java.lang.NullPointerException at org.apache.aries.util.internal.DefaultWorker.setupListener(DefaultWorker.java:98) at org.apache.aries.util.internal.DefaultWorker.getClassLoader(DefaultWorker.java:86) at org.apache.aries.util.AriesFrameworkUtil.getClassLoaderForced(AriesFrameworkUtil.java:93) at org.apache.aries.jpa.container.unit.impl.PersistenceUnitInfoImpl.getClassLoader(PersistenceUnitInfoImpl.java:89) at
[jira] [Commented] (ARIES-681) JPA Container BundleDelegatingClassLoader should look for classes in the provider bundle, too
[ https://issues.apache.org/jira/browse/ARIES-681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13059489#comment-13059489 ] Balazs Zsoldos commented on ARIES-681: -- Hi, I will upload a sample application soon that will show my problem. I do not use the OSGI capabilities of EclipseLink due to the following reason: - I would like to use aries blueprint and jpa:context tag. - I am afraid that if I use the standard Eclipselink solution (persistence.xml into META-INF library) I will face many problems with transaction management and aries blueprint So my solution was that I defined the Meta-Persistence in the manifest header. As EclipseLink does not register the PersistenceProvider as an OSGI service (Aries needs it based on the OSGI 4.2 specification I think) I created a jar file that does nothing else but the service registration. I tried to register the osgi based PersistenceProvider of EclipseLink but I got an exception that createContainerEntityManagerFactory function cannot be called in an OSGI environment (Aries JPA container calls it). Due to this reason I registered the ordinary PersistenceProvider of EclipseLink and that is where this bug came from. Aries JPA container uses ordinary Eclipselink persistence provider. Aries creates the Persistence Unit as well, Eclipselink does not do anything automatically. Regards, Balazs JPA Container BundleDelegatingClassLoader should look for classes in the provider bundle, too - Key: ARIES-681 URL: https://issues.apache.org/jira/browse/ARIES-681 Project: Aries Issue Type: Bug Components: JPA Affects Versions: 0.3 Environment: Glassfish 3.0 (EclipseLink 2.0.2), Glassfish 3.1 (EclipseLink 2.2) Reporter: Balazs Zsoldos Attachments: classloadingFromMultipleProviderDuringQuery.0.3.patch Currently the BundleDelegatingClassLoader in JPA container only looks for classes in the bundle of the entitymanager. However the JPA implementation Eclipselink needs some classes from itself. The reason is that in entity classes the properties that hold mapping of One-To-Many are converted to EclipseLink list type. See the following exception stacktrace: Internal Exception: java.lang.ClassNotFoundException: org.eclipse.persistence.indirection.IndirectList at org.eclipse.persistence.exceptions.ValidationException.classNotFoundWhileConvertingClassNames(ValidationException.java:2317) at org.eclipse.persistence.internal.queries.InterfaceContainerPolicy.convertClassNamesToClasses(InterfaceContainerPolicy.java:123) at org.eclipse.persistence.mappings.CollectionMapping.convertClassNamesToClasses(CollectionMapping.java:788) at org.eclipse.persistence.descriptors.ClassDescriptor.convertClassNamesToClasses(ClassDescriptor.java:1458) at org.eclipse.persistence.sessions.Project.convertClassNamesToClasses(Project.java:362) at org.eclipse.persistence.internal.jpa.EntityManagerSetupImpl.deploy(EntityManagerSetupImpl.java:322) ... 83 more Caused by: java.lang.ClassNotFoundException: org.eclipse.persistence.indirection.IndirectList at org.apache.felix.framework.ModuleImpl.findClassOrResourceByDelegation(ModuleImpl.java:744) at org.apache.felix.framework.ModuleImpl.access$100(ModuleImpl.java:61) at org.apache.felix.framework.ModuleImpl$ModuleClassLoader.loadClass(ModuleImpl.java:1656) at java.lang.ClassLoader.loadClass(ClassLoader.java:247) at org.apache.felix.framework.ModuleImpl.getClassByDelegation(ModuleImpl.java:604) at org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1487) at org.apache.felix.framework.BundleImpl.loadClass(BundleImpl.java:897) at org.apache.aries.jpa.container.unit.impl.BundleDelegatingClassLoader$1.run(BundleDelegatingClassLoader.java:50) at org.apache.aries.jpa.container.unit.impl.BundleDelegatingClassLoader$1.run(BundleDelegatingClassLoader.java:47) at java.security.AccessController.doPrivileged(Native Method) at org.apache.aries.jpa.container.unit.impl.BundleDelegatingClassLoader.findClass(BundleDelegatingClassLoader.java:47) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at java.lang.ClassLoader.loadClass(ClassLoader.java:247) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:247) at org.eclipse.persistence.internal.security.PrivilegedAccessHelper.getClassForName(PrivilegedAccessHelper.java:88) at org.eclipse.persistence.internal.queries.InterfaceContainerPolicy.convertClassNamesToClasses(InterfaceContainerPolicy.java:120) ... 87 more -- This message is automatically generated by JIRA. For more information on
[jira] [Commented] (ARIES-681) JPA Container BundleDelegatingClassLoader should look for classes in the provider bundle, too
[ https://issues.apache.org/jira/browse/ARIES-681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13053687#comment-13053687 ] Balazs Zsoldos commented on ARIES-681: -- Hi, thank you for the fast responses. I do not use classes from Eclipselink at all in my bundle so it may be during deployment time. I will be in the office in two weeks again and I will try the weaving setting you suggested. Also if it does not work I will create a jira issue on Eclipselink side as well with a sample application to see what they say. Thanks, Balazs JPA Container BundleDelegatingClassLoader should look for classes in the provider bundle, too - Key: ARIES-681 URL: https://issues.apache.org/jira/browse/ARIES-681 Project: Aries Issue Type: Bug Components: JPA Affects Versions: 0.3 Environment: Glassfish 3.0 (EclipseLink 2.0.2), Glassfish 3.1 (EclipseLink 2.2) Reporter: Balazs Zsoldos Attachments: classloadingFromMultipleProviderDuringQuery.0.3.patch Currently the BundleDelegatingClassLoader in JPA container only looks for classes in the bundle of the entitymanager. However the JPA implementation Eclipselink needs some classes from itself. The reason is that in entity classes the properties that hold mapping of One-To-Many are converted to EclipseLink list type. See the following exception stacktrace: Internal Exception: java.lang.ClassNotFoundException: org.eclipse.persistence.indirection.IndirectList at org.eclipse.persistence.exceptions.ValidationException.classNotFoundWhileConvertingClassNames(ValidationException.java:2317) at org.eclipse.persistence.internal.queries.InterfaceContainerPolicy.convertClassNamesToClasses(InterfaceContainerPolicy.java:123) at org.eclipse.persistence.mappings.CollectionMapping.convertClassNamesToClasses(CollectionMapping.java:788) at org.eclipse.persistence.descriptors.ClassDescriptor.convertClassNamesToClasses(ClassDescriptor.java:1458) at org.eclipse.persistence.sessions.Project.convertClassNamesToClasses(Project.java:362) at org.eclipse.persistence.internal.jpa.EntityManagerSetupImpl.deploy(EntityManagerSetupImpl.java:322) ... 83 more Caused by: java.lang.ClassNotFoundException: org.eclipse.persistence.indirection.IndirectList at org.apache.felix.framework.ModuleImpl.findClassOrResourceByDelegation(ModuleImpl.java:744) at org.apache.felix.framework.ModuleImpl.access$100(ModuleImpl.java:61) at org.apache.felix.framework.ModuleImpl$ModuleClassLoader.loadClass(ModuleImpl.java:1656) at java.lang.ClassLoader.loadClass(ClassLoader.java:247) at org.apache.felix.framework.ModuleImpl.getClassByDelegation(ModuleImpl.java:604) at org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1487) at org.apache.felix.framework.BundleImpl.loadClass(BundleImpl.java:897) at org.apache.aries.jpa.container.unit.impl.BundleDelegatingClassLoader$1.run(BundleDelegatingClassLoader.java:50) at org.apache.aries.jpa.container.unit.impl.BundleDelegatingClassLoader$1.run(BundleDelegatingClassLoader.java:47) at java.security.AccessController.doPrivileged(Native Method) at org.apache.aries.jpa.container.unit.impl.BundleDelegatingClassLoader.findClass(BundleDelegatingClassLoader.java:47) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at java.lang.ClassLoader.loadClass(ClassLoader.java:247) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:247) at org.eclipse.persistence.internal.security.PrivilegedAccessHelper.getClassForName(PrivilegedAccessHelper.java:88) at org.eclipse.persistence.internal.queries.InterfaceContainerPolicy.convertClassNamesToClasses(InterfaceContainerPolicy.java:120) ... 87 more -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
