[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=13072250#comment-13072250
]
Timothy Ward commented on ARIES-691:
Hi
Is there any reason why you do not use the adaptorBundle.loadClass for loading
the classes coming from packages starting with
org.apache.aries.jpa.eclipselink.adapter? Loading the classes as streams
seems to bit difficult to me. However I did not go deep so may be adaptorBundle
is not even eclipselinkAdapter bundle...
The reason that the code is the way it is is as follows:
There are potentially multiple versions of EclipseLink in the system. Each
version potentially has its own, different view of the
org.eclipse.persistence.platform.server.ServerPlatformBase and
org.eclipse.persistence.transaction.JTATransactionController classes. We need
our plugin to work with *all* of the EclipseLinks, which means that we cannot
use Import-Package as that would wire us to a single view of the classes.
What we do instead is to define the classes on our own classloader, which then
delegates to the relevant EclipseLink bundle to load the rest. This means that
our plugin can work with multiple EclipseLinks at once because it's defined
each time using the correct view of EclipseLink's classes.
I hope this explanation helps.
*
if(name.startsWith(org.osgi.framework.)) {
return adaptorBundle.loadClass(name);
}
*
I did something similar to this, but we also need to check that the name isn't
a class in a sub-package like org.osgi.framework.wiring.BundleWiring. This is
why I added the lastIndexOf check.
Tim
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=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=13071607#comment-13071607 ] Timothy Ward commented on ARIES-691: I have adjusted the existing code to allow it to work with multiple EclipseLink instances at once. I have also unified the Persistence Unit classloader with the EclipseLink JPA bundles. This is a bit unpleasant, but we don't really have a choice if EclipseLink is going to load internal classes from the persistence unit classloader. 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=13071828#comment-13071828 ] Timothy Ward commented on ARIES-691: It appears all our test bundles import org.osgi.framework, hiding this issue. Fortunately it should be easy to fix. 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=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-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] [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=13060494#comment-13060494 ] Valentin Mahrwald commented on ARIES-691: - Hi Balazs, thanks a lot for testing the changes on Glassfish and for the feedback. Highly appreciated. Now, in terms of the issues you have found: - javax.persistence imports absolutely should be able to handle minor version updates. Thanks for spotting that. - Handling RESOLVED Eclipselink bundles also makes sense. However, I think rather than starting the Eclipselink bundle (which is slightly more invasive). I think loading the provider class from the RESOLVED bundle and tracking it in case the Eclipselink bundle is unresolved / uninstalled would be better !? - I have found the same problem, which is why the OSGiTSServer is included now. This retrieves a TransactionManager from the service registry. If that does not work or you want to use the SunAS integration, I would suggest having the import on the persistence bundle rather than the adapter bundle. The reasoning for this is that even when adding all the common server packages from Eclipselink in this way we would not be able to support other providers and they would have to be added in the persistence bundle's import anyway. So I would rather make it consistent and have the responsibility for that import at the persistence bundle, which also defines the dependency. - getBundleContext() returning null is a well-known feature of the OSGi Bundle API :) I am afraid I am not clear though on where exactly this method gets called and how Blueprint gets involved. Could you be more specific in where this interaction comes from and how it goes wrong :) I hope to commit a fix (based on your patch) for the first two issues either today or tomorrow. Regards, Valentin 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
