OpenJPA
  1. OpenJPA
  2. OPENJPA-5

OpenJPA doesn't compile with JDBC 4

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 0.9.0, 0.9.6
    • Fix Version/s: 2.0.0-M3
    • Component/s: build / infrastructure
    • Labels:
      None

      Description

      Patrick opines:
      OpenJPA implements Statement, ResultSet, Connection, and maybe a
      couple other JDBC interfaces. See
      org.apache.openjpa.lib.jdbc.Delegating*. We do this for a number of
      reasons: to resolve database-specific bugs in a transparent fashion, to
      provide logging, to handle reference counting, etc.

      The pressing issue is that we must provide implementations of all of the
      methods in the various java.sql interfaces. The fact that we do not
      implement the new JDBC4 methods is why OpenJPA won't currently compile
      against JDK6. This is pretty easy to fix; take a look at
      org.apache.openjpa.lib.jdbc.DelegatingStatement to see how we handled
      this for JDBC3. Since we know that we never invoke the new methods, we
      can happily throw unsupported operation exceptions for the new methods.

      However, these unsupported methods do provide a challenge. While Kodo
      doesn't use any of these methods, our mechanism for implementing them is
      limiting, in that users who obtain Connections from Kodo will not be
      able to use the new JDBC3/JDBC4 methods in their own code. Ideally, we
      should provide some means for people to designate to OpenJPA that it
      should use a dynamic proxy to implement the unimplemented methods. This
      shouldn't be the default behavior, as the dynamic proxy will add
      overhead, but certainly could be desirable for some. I'll file an issue.

      1. OPENJPA-5.patch
        70 kB
        Marc Prud'hommeaux
      2. openjpa-5.patch.2.txt
        81 kB
        Pinaki Poddar
      3. openjpa-5.patch.3.txt
        99 kB
        Pinaki Poddar

        Issue Links

          Activity

          Hide
          Marc Prud'hommeaux added a comment -

          I think that unfortunately the only code-based solution to this will be to do some pre-processing on the source code by having formatted comments that surround JDBC3 and JDBC4 methods, similar to how DBCP does it (e.g, see http://svn.apache.org/repos/asf/jakarta/commons/proper/dbcp/trunk/src/java/org/apache/commons/dbcp/DelegatingResultSet.java ).

          Another solution that would be pretty easy would just be to make all the Statement/PreparedStatement/ResultSet/Connection wrappers be abstract, and then use bytecode generation to create a concrete subclass implementation at runtime. This would have the advantage that we wouldn't need stubs or pre-processing, and since Java allows you to load a comcrete class that doesn't fully implement an interface, the generated subclass wouldn't need to have any logic in it at all. If we cache the generated classes, it would probably also be quite fast (after the first time). The only code change I can think of is that all "new DelegatingStatement()" type statements would need to be replaced with something like JDBCClassFactory.createConcreteWrapperSubclass(Statement) methods.

          Show
          Marc Prud'hommeaux added a comment - I think that unfortunately the only code-based solution to this will be to do some pre-processing on the source code by having formatted comments that surround JDBC3 and JDBC4 methods, similar to how DBCP does it (e.g, see http://svn.apache.org/repos/asf/jakarta/commons/proper/dbcp/trunk/src/java/org/apache/commons/dbcp/DelegatingResultSet.java ). Another solution that would be pretty easy would just be to make all the Statement/PreparedStatement/ResultSet/Connection wrappers be abstract, and then use bytecode generation to create a concrete subclass implementation at runtime. This would have the advantage that we wouldn't need stubs or pre-processing, and since Java allows you to load a comcrete class that doesn't fully implement an interface, the generated subclass wouldn't need to have any logic in it at all. If we cache the generated classes, it would probably also be quite fast (after the first time). The only code change I can think of is that all "new DelegatingStatement()" type statements would need to be replaced with something like JDBCClassFactory.createConcreteWrapperSubclass(Statement) methods.
          Hide
          Patrick Linskey added a comment -

          I think that merely adding the new methods should be sufficient for OpenJPA to compile against JDBC 4. I think that your solution describes the steps needed to make the new delegate methods actually work. That's issue OPENJPA-6.

          Show
          Patrick Linskey added a comment - I think that merely adding the new methods should be sufficient for OpenJPA to compile against JDBC 4. I think that your solution describes the steps needed to make the new delegate methods actually work. That's issue OPENJPA-6 .
          Hide
          Marc Prud'hommeaux added a comment -

          The problem is that we can't add methods like http://java.sun.com/javase/6/docs/api/java/sql/PreparedStatement.html#setNClob(int,%20java.sql.NClob) , since NClob is a new interface in Java 1.6. So unless we make some sort of jar of stubs, or do code pre-processing, the only solution AFAIK is to use bytecode generation.

          Note that my solution could also make the methods actually work, but it would be a bit more difficult to implement. This is just something that would get it to compile under Java 1.6.

          Show
          Marc Prud'hommeaux added a comment - The problem is that we can't add methods like http://java.sun.com/javase/6/docs/api/java/sql/PreparedStatement.html#setNClob(int,%20java.sql.NClob ) , since NClob is a new interface in Java 1.6. So unless we make some sort of jar of stubs, or do code pre-processing, the only solution AFAIK is to use bytecode generation. Note that my solution could also make the methods actually work, but it would be a bit more difficult to implement. This is just something that would get it to compile under Java 1.6.
          Hide
          Patrick Linskey added a comment -

          So it turns out that a dynamic-proxy-based approach is not as trivial as it could be, since we often create anonymous inner classes that extend various of the org.apache.openjpa.lib.jdbc.Delegating* classes.

          Craig alleges that Sun has made the JDBC4 jars available somewhere. It sounds like we either need to find their home in a maven repo, convince Sun to put them in a maven repo, or add the jar to a lib directory in openjpa.

          Does anyone know what JVM bytecode version the JDBC4 jars are compiled to? Ideally, it'd be nice if they were compiled to the 1.3 VM level (47?).

          Show
          Patrick Linskey added a comment - So it turns out that a dynamic-proxy-based approach is not as trivial as it could be, since we often create anonymous inner classes that extend various of the org.apache.openjpa.lib.jdbc.Delegating* classes. Craig alleges that Sun has made the JDBC4 jars available somewhere. It sounds like we either need to find their home in a maven repo, convince Sun to put them in a maven repo, or add the jar to a lib directory in openjpa. Does anyone know what JVM bytecode version the JDBC4 jars are compiled to? Ideally, it'd be nice if they were compiled to the 1.3 VM level (47?).
          Hide
          Patrick Linskey added a comment -

          I forgot to write up the other option that I see:

          We could replace the anonymous inner classes that extend Delegating* with anonymous inner classes that implement the corresponding JDBC interface, and then create some sort of interceptor-style interface that those classes are hydrated with. Imagine that a driver throws a bogus FooException from time to time when Connection.createStatement() is invoked. This could be fixed like so:

          Connection rawConnection = ...;

          Connection wrappedConnection = DelegateFactory.newConnection(
          new ConnectionInterceptor(rawConnection) {
          public Statement createStatement() throws SQLException {
          try

          { return super.createStatement(); }

          catch (FooException fe)

          { throw new SQLException(fe); }

          }
          });

          This is similar to our current approach, except that ConnectionInterceptor need not actually implement Connection, so we could just provide those methods that we actually use, and the DelegateFactory could in turn create a dynamic proxy that uses the ConnectionInterceptor.

          Thoughts?

          Show
          Patrick Linskey added a comment - I forgot to write up the other option that I see: We could replace the anonymous inner classes that extend Delegating* with anonymous inner classes that implement the corresponding JDBC interface, and then create some sort of interceptor-style interface that those classes are hydrated with. Imagine that a driver throws a bogus FooException from time to time when Connection.createStatement() is invoked. This could be fixed like so: Connection rawConnection = ...; Connection wrappedConnection = DelegateFactory.newConnection( new ConnectionInterceptor(rawConnection) { public Statement createStatement() throws SQLException { try { return super.createStatement(); } catch (FooException fe) { throw new SQLException(fe); } } }); This is similar to our current approach, except that ConnectionInterceptor need not actually implement Connection, so we could just provide those methods that we actually use, and the DelegateFactory could in turn create a dynamic proxy that uses the ConnectionInterceptor. Thoughts?
          Hide
          Marc Prud'hommeaux added a comment -

          The dynamic proxy option is different from the bytecode generation option: the former requires that we algorithnmically create implementations of all the methods to do what our current DelegatingStatement/ResultSet/etc implementations do. With bytecode generation, all we would need to do is change "public class DelegatingStatement" to "public abstract class DelegatingStatement", and then just change any constructor to instead call the factory method to create new instances. This can work for inner classes as well, but probably not anonymous inner classes (which I don't think we use for the JDBC wrappers anyway).

          The interceptor approach also sounds like it would work, although it would be a lot more effort to implement.

          Having a separate JDBC4 jar might also work, although I'd be surprised if it was compiled with a bytecode version that can be understood by the Java 1.3 compiler. We might also have licensing issues with committing it to the Apache repository.

          Show
          Marc Prud'hommeaux added a comment - The dynamic proxy option is different from the bytecode generation option: the former requires that we algorithnmically create implementations of all the methods to do what our current DelegatingStatement/ResultSet/etc implementations do. With bytecode generation, all we would need to do is change "public class DelegatingStatement" to "public abstract class DelegatingStatement", and then just change any constructor to instead call the factory method to create new instances. This can work for inner classes as well, but probably not anonymous inner classes (which I don't think we use for the JDBC wrappers anyway). The interceptor approach also sounds like it would work, although it would be a lot more effort to implement. Having a separate JDBC4 jar might also work, although I'd be surprised if it was compiled with a bytecode version that can be understood by the Java 1.3 compiler. We might also have licensing issues with committing it to the Apache repository.
          Hide
          Kevin Sutter added a comment -

          To follow on to one of Marc's earlier comments... These updates to support the new JDBC 4 interfaces brings up another question. What about the support for the new data types introduced by JDBC 4 (NCHAR, NVARCHAR, LONGNVARCHAR, NCLOB)? Or, some of the new functionality provided by JDBC 4 (SQLException extensions, event listeners, etc).

          There is a lot of overlap between OPENJPA-4 and OPENJPA-5. Are these new JDBC 4 features another new JIRA issue? Maybe we have two main goals – 1) Is just to get us buildable and runnable in a JDK 6 (JDBC 4) environment, and 2) exploit the new functions provided by JDK 6 (JDBC 4). Is (1) for OPENJPA-4 and (2) for OPENJPA-5? The discussions seem be blurring the lines and I'm just trying to get a handle on how much we're going to bite off with each JIRA Issue. Thanks.

          Show
          Kevin Sutter added a comment - To follow on to one of Marc's earlier comments... These updates to support the new JDBC 4 interfaces brings up another question. What about the support for the new data types introduced by JDBC 4 (NCHAR, NVARCHAR, LONGNVARCHAR, NCLOB)? Or, some of the new functionality provided by JDBC 4 (SQLException extensions, event listeners, etc). There is a lot of overlap between OPENJPA-4 and OPENJPA-5 . Are these new JDBC 4 features another new JIRA issue? Maybe we have two main goals – 1) Is just to get us buildable and runnable in a JDK 6 (JDBC 4) environment, and 2) exploit the new functions provided by JDK 6 (JDBC 4). Is (1) for OPENJPA-4 and (2) for OPENJPA-5 ? The discussions seem be blurring the lines and I'm just trying to get a handle on how much we're going to bite off with each JIRA Issue. Thanks.
          Hide
          Marc Prud'hommeaux added a comment -

          I feel that this issue is merely to make it possible for OpenJPA to be compilable against Java 6/JDBC 4.

          My personal opinion is that if we see new features in JDBC 4 that we want to take advantage of, a separate issue should be filed (with this issue as a dependency).

          Show
          Marc Prud'hommeaux added a comment - I feel that this issue is merely to make it possible for OpenJPA to be compilable against Java 6/JDBC 4. My personal opinion is that if we see new features in JDBC 4 that we want to take advantage of, a separate issue should be filed (with this issue as a dependency).
          Hide
          Kevin Sutter added a comment -

          Oops... We have so many of these JDBC 4 type Issues that I screwed up with my earlier comment. I should have been referencing this Issue (OPENJPA-5) as the "make it buildable" Issue. And, the OPENJPA-6 should be the "exploitable" Issue. But, maybe Marc is right. OPENJPA-6 could be used to make the Connection objects returned by OpenJPA more JDBC like. And, then create a totally separate Issue for exploiting new JDBC 4 features. I'll do that.

          Show
          Kevin Sutter added a comment - Oops... We have so many of these JDBC 4 type Issues that I screwed up with my earlier comment. I should have been referencing this Issue ( OPENJPA-5 ) as the "make it buildable" Issue. And, the OPENJPA-6 should be the "exploitable" Issue. But, maybe Marc is right. OPENJPA-6 could be used to make the Connection objects returned by OpenJPA more JDBC like. And, then create a totally separate Issue for exploiting new JDBC 4 features. I'll do that.
          Hide
          Marc Prud'hommeaux added a comment -

          The attached patch solves this problem by making all the JDBC implementations abstract, and handles construction them using a new ConcreteClassGenerator class, which will synamically create a concrete subclass and return it. I've been able to build and run all the tests under JDK 1.6 (which includes JDBC 4) after applying this patch.

          The instance construction is somewhat cumbersome, and loses some compiler validation, but as far as I can tell this is the only way to resolve the problem without having separate builds for JDK 1.5 and JDK 1.6.

          Show
          Marc Prud'hommeaux added a comment - The attached patch solves this problem by making all the JDBC implementations abstract, and handles construction them using a new ConcreteClassGenerator class, which will synamically create a concrete subclass and return it. I've been able to build and run all the tests under JDK 1.6 (which includes JDBC 4) after applying this patch. The instance construction is somewhat cumbersome, and loses some compiler validation, but as far as I can tell this is the only way to resolve the problem without having separate builds for JDK 1.5 and JDK 1.6.
          Hide
          Patrick Linskey added a comment -

          We do similar work for mutable type proxies. Is there an opportunity to unify the two different mechanisms in some way? Also, we pre-build some mutable type proxy classes during our compilation to reduce initialization time; should we look at doing a similar thing here? Without significant build changes, we should at least be able to pre-build the JDK1.5 classes.

          Show
          Patrick Linskey added a comment - We do similar work for mutable type proxies. Is there an opportunity to unify the two different mechanisms in some way? Also, we pre-build some mutable type proxy classes during our compilation to reduce initialization time; should we look at doing a similar thing here? Without significant build changes, we should at least be able to pre-build the JDK1.5 classes.
          Hide
          Pinaki Poddar added a comment -

          The time for this change has come.

          JPA 2.0 requires quite a lot of compile-time annotation processing to support newly added meta-model related features (source code generation etc.). Two issues in this regard make JDK version dependecy a critical factor.
          1. The spec requires generated meta-model classes to import javax.annotation.GeneratedValue. This is a JDK6 annotation. Does the spec implicitly saying that JPA2.0 applications require JDK6?
          2. Annotation processing has gone through some core changes from JDK5 to JDK6. In JDK5 it is supported by a tool apt – and a com.sun.* class library in tools.jar. While in JDK6 it is more closely bundled with javax.annotation package. Moreover, the lifecycle/API in apt vs. javax.annotation are not the same. It is possible to build two different implementations and switch based on available JDK version – but is it worth the effort?

          Given that this important issue has been dormant for 2 years – it is time to revive this thread.

          I have integrated Marc's patch (with few minor changes) and found that working locally with Slice test cases because a) Slice is not covered in Marc's patch and b) they heavily exercise construction of the JDBC counterparts of OpenJPA (which are the main focus of Marc's solution and dynamically generated in his approach). I will post the changes shortly.

          Show
          Pinaki Poddar added a comment - The time for this change has come. JPA 2.0 requires quite a lot of compile-time annotation processing to support newly added meta-model related features (source code generation etc.). Two issues in this regard make JDK version dependecy a critical factor. 1. The spec requires generated meta-model classes to import javax.annotation.GeneratedValue. This is a JDK6 annotation. Does the spec implicitly saying that JPA2.0 applications require JDK6? 2. Annotation processing has gone through some core changes from JDK5 to JDK6. In JDK5 it is supported by a tool apt – and a com.sun.* class library in tools.jar. While in JDK6 it is more closely bundled with javax.annotation package. Moreover, the lifecycle/API in apt vs. javax.annotation are not the same. It is possible to build two different implementations and switch based on available JDK version – but is it worth the effort? Given that this important issue has been dormant for 2 years – it is time to revive this thread. I have integrated Marc's patch (with few minor changes) and found that working locally with Slice test cases because a) Slice is not covered in Marc's patch and b) they heavily exercise construction of the JDBC counterparts of OpenJPA (which are the main focus of Marc's solution and dynamically generated in his approach). I will post the changes shortly.
          Hide
          Pinaki Poddar added a comment -

          Patch to compile OpenJPA with JDK6. Makes implementations of JDBC artifacts abstract. Dynamically generates the concrete type.

          Show
          Pinaki Poddar added a comment - Patch to compile OpenJPA with JDK6. Makes implementations of JDBC artifacts abstract. Dynamically generates the concrete type.
          Hide
          Donald Woods added a comment -

          For #2, the @Generated annotation was implemented by Geronimo as part of the JEE5 spec in geronimo-annotation_1.0_spec-1.1.1

          Show
          Donald Woods added a comment - For #2, the @Generated annotation was implemented by Geronimo as part of the JEE5 spec in geronimo-annotation_1.0_spec-1.1.1
          Hide
          Michael Dick added a comment -

          Hi Pinaki. Looks like the new patch is missing ConcreteClassGenerator. Should we apply Marc's patch and then yours to give it a test drive?

          Show
          Michael Dick added a comment - Hi Pinaki. Looks like the new patch is missing ConcreteClassGenerator. Should we apply Marc's patch and then yours to give it a test drive?
          Hide
          Pinaki Poddar added a comment -

          The previous OPENJPA-5.2.patch missed the new files.

          I faced some access protection issue with Marc's patch directly and surely the Slice was not covered.

          Show
          Pinaki Poddar added a comment - The previous OPENJPA-5 .2.patch missed the new files. I faced some access protection issue with Marc's patch directly and surely the Slice was not covered.
          Hide
          Michael Dick added a comment -

          Full disclosure : I've only built with the patch, I have not run any tests.

          Setting the compiler level to 1.6 in the root pom means that we won't compile with java 1.5 which was one of the main goals of Marc's patch. We'll need to set this back to 1.5 (which does at least compile) if we want to support using both versions.

          I don't think support for compiling with 1.5 is important anymore. From Sun's website JDK 5.0 will reach end of life October 30th 2009 which isn't really that far away. Introducing a lot of extra code (ConcreteClassGenerator) just adds extra complications with (IMHO) very little benefit.

          Just adding the required interfaces makes more sense to me.

          Show
          Michael Dick added a comment - Full disclosure : I've only built with the patch, I have not run any tests. Setting the compiler level to 1.6 in the root pom means that we won't compile with java 1.5 which was one of the main goals of Marc's patch. We'll need to set this back to 1.5 (which does at least compile) if we want to support using both versions. I don't think support for compiling with 1.5 is important anymore. From Sun's website JDK 5.0 will reach end of life October 30th 2009 which isn't really that far away. Introducing a lot of extra code (ConcreteClassGenerator) just adds extra complications with (IMHO) very little benefit. Just adding the required interfaces makes more sense to me.
          Hide
          Albert Lee added a comment -

          With Java security enabled, the following exception occurred:

          **Exception: Caught unexpected Exception during test execution.
          org.apache.openjpa.persistence.PersistenceException:There were errors initializing your configuration: java.lang.ExceptionInInitializerError
          at org.apache.openjpa.lib.jdbc.ConfiguringConnectionDecorator.(ConfiguringConnectionDecorator.java:49)
          at java.lang.J9VMInternals.initializeImpl(Native Method)
          at java.lang.J9VMInternals.initialize(J9VMInternals.java:200)
          at org.apache.openjpa.jdbc.schema.DataSourceFactory.installDBDictionary(DataSourceFactory.java:211)
          at org.apache.openjpa.jdbc.conf.JDBCConfigurationImpl.getConnectionFactory(JDBCConfigurationImpl.java:714)
          at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
          at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
          at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
          at java.lang.reflect.Method.invoke(Method.java:599)
          at org.apache.openjpa.lib.conf.ConfigurationImpl.instantiateAll(ConfigurationImpl.java:288)
          at org.apache.openjpa.conf.OpenJPAConfigurationImpl.instantiateAll(OpenJPAConfigurationImpl.java:1549)
          at org.apache.openjpa.kernel.AbstractBrokerFactory.makeReadOnly(AbstractBrokerFactory.java:700)
          at org.apache.openjpa.kernel.AbstractBrokerFactory.newBroker(AbstractBrokerFactory.java:198)
          at org.apache.openjpa.kernel.DelegatingBrokerFactory.newBroker(DelegatingBrokerFactory.java:160)
          at org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntityManager(EntityManagerFactoryImpl.java:212)
          at com.ibm.ws.persistence.EntityManagerFactoryImpl.createEntityManager(EntityManagerFactoryImpl.java:42)
          at com.ibm.ws.persistence.EntityManagerFactoryImpl.createEntityManager(EntityManagerFactoryImpl.java:27)
          at suite.jpafvt.common.testvehicle.JPAFVTGenericBMTTestEJB.executeTestCase(JPAFVTGenericBMTTestEJB.java:85)
          at suite.r80.base.jpaspec.annoxml.ordercolumn.test.jee.ejb.EJSLocal0SLOrderColumnTestSLEJB_52ec6ee4.executeTestCase(EJSLocal0SLOrderColumnTestSLEJB_52ec6ee4.java)
          at suite.jpafvt.common.testvehicle.JPAFVTGenericEJBVehicleServlet.executeTestCase(JPAFVTGenericEJBVehicleServlet.java:58)
          at suite.jpafvt.common.testvehicle.AbstractJPATestServletVehicle.doPost(AbstractJPATestServletVehicle.java:102)
          at javax.servlet.http.HttpServlet.service(HttpServlet.java:738)
          at javax.servlet.http.HttpServlet.service(HttpServlet.java:831)
          at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1530)
          at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:829)
          at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:458)
          at com.ibm.ws.webcontainer.servlet.ServletWrapperImpl.handleRequest(ServletWrapperImpl.java:175)
          at com.ibm.ws.webcontainer.webapp.WebApp.handleRequest(WebApp.java:3742)
          at com.ibm.ws.webcontainer.webapp.WebGroup.handleRequest(WebGroup.java:276)
          at com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:929)
          at com.ibm.ws.webcontainer.WSWebContainer.handleRequest(WSWebContainer.java:1580)
          at com.ibm.ws.webcontainer.channel.WCChannelLink.ready(WCChannelLink.java:177)
          at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleDiscrimination(HttpInboundLink.java:455)
          at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleNewInformation(HttpInboundLink.java:384)
          at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.ready(HttpInboundLink.java:288)
          at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.sendToDiscriminators(NewConnectionInitialReadCallback.java:214)
          at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.complete(NewConnectionInitialReadCallback.java:113)
          at com.ibm.ws.tcp.channel.impl.AioReadCompletionListener.futureCompleted(AioReadCompletionListener.java:165)
          at com.ibm.io.async.AbstractAsyncFuture.invokeCallback(AbstractAsyncFuture.java:217)
          at com.ibm.io.async.AsyncChannelFuture$1.run(AsyncChannelFuture.java:205)
          at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1550)
          Caused by: java.security.AccessControlException: Access denied (java.lang.RuntimePermission getClassLoader)
          at java.security.AccessController.checkPermission(AccessController.java:108)
          at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
          at com.ibm.ws.security.core.SecurityManager.checkPermission(SecurityManager.java:211)
          at java.lang.Thread.getContextClassLoader(Thread.java:456)
          at serp.bytecode.Project.loadClass(Project.java:95)
          at serp.bytecode.Project.loadClass(Project.java:67)
          at org.apache.openjpa.lib.util.ConcreteClassGenerator.makeConcrete(ConcreteClassGenerator.java:61)
          at org.apache.openjpa.lib.jdbc.ConfiguringConnectionDecorator.(ConfiguringConnectionDecorator.java:46)
          ... 40 more

          and

          Caused by: java.security.AccessControlException: Access denied (java.lang.RuntimePermission createClassLoader)
          at java.security.AccessController.checkPermission(AccessController.java:108)
          at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
          at com.ibm.ws.security.core.SecurityManager.checkPermission(SecurityManager.java:211)
          at java.lang.SecurityManager.checkCreateClassLoader(SecurityManager.java:594)
          at java.lang.ClassLoader.(ClassLoader.java:143)
          at serp.bytecode.BCClassLoader.(BCClassLoader.java:25)
          at org.apache.openjpa.lib.util.ConcreteClassGenerator.makeConcrete(ConcreteClassGenerator.java:54)
          at org.apache.openjpa.lib.jdbc.ConfiguringConnectionDecorator.(ConfiguringConnectionDecorator.java:46)
          ... 40 more

          Need DoPrivilege() around the "new BCClassLoader" and "project.loadClass()";

          Show
          Albert Lee added a comment - With Java security enabled, the following exception occurred: **Exception: Caught unexpected Exception during test execution. org.apache.openjpa.persistence.PersistenceException:There were errors initializing your configuration: java.lang.ExceptionInInitializerError at org.apache.openjpa.lib.jdbc.ConfiguringConnectionDecorator.(ConfiguringConnectionDecorator.java:49) at java.lang.J9VMInternals.initializeImpl(Native Method) at java.lang.J9VMInternals.initialize(J9VMInternals.java:200) at org.apache.openjpa.jdbc.schema.DataSourceFactory.installDBDictionary(DataSourceFactory.java:211) at org.apache.openjpa.jdbc.conf.JDBCConfigurationImpl.getConnectionFactory(JDBCConfigurationImpl.java:714) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) at java.lang.reflect.Method.invoke(Method.java:599) at org.apache.openjpa.lib.conf.ConfigurationImpl.instantiateAll(ConfigurationImpl.java:288) at org.apache.openjpa.conf.OpenJPAConfigurationImpl.instantiateAll(OpenJPAConfigurationImpl.java:1549) at org.apache.openjpa.kernel.AbstractBrokerFactory.makeReadOnly(AbstractBrokerFactory.java:700) at org.apache.openjpa.kernel.AbstractBrokerFactory.newBroker(AbstractBrokerFactory.java:198) at org.apache.openjpa.kernel.DelegatingBrokerFactory.newBroker(DelegatingBrokerFactory.java:160) at org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntityManager(EntityManagerFactoryImpl.java:212) at com.ibm.ws.persistence.EntityManagerFactoryImpl.createEntityManager(EntityManagerFactoryImpl.java:42) at com.ibm.ws.persistence.EntityManagerFactoryImpl.createEntityManager(EntityManagerFactoryImpl.java:27) at suite.jpafvt.common.testvehicle.JPAFVTGenericBMTTestEJB.executeTestCase(JPAFVTGenericBMTTestEJB.java:85) at suite.r80.base.jpaspec.annoxml.ordercolumn.test.jee.ejb.EJSLocal0SLOrderColumnTestSLEJB_52ec6ee4.executeTestCase(EJSLocal0SLOrderColumnTestSLEJB_52ec6ee4.java) at suite.jpafvt.common.testvehicle.JPAFVTGenericEJBVehicleServlet.executeTestCase(JPAFVTGenericEJBVehicleServlet.java:58) at suite.jpafvt.common.testvehicle.AbstractJPATestServletVehicle.doPost(AbstractJPATestServletVehicle.java:102) at javax.servlet.http.HttpServlet.service(HttpServlet.java:738) at javax.servlet.http.HttpServlet.service(HttpServlet.java:831) at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1530) at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:829) at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:458) at com.ibm.ws.webcontainer.servlet.ServletWrapperImpl.handleRequest(ServletWrapperImpl.java:175) at com.ibm.ws.webcontainer.webapp.WebApp.handleRequest(WebApp.java:3742) at com.ibm.ws.webcontainer.webapp.WebGroup.handleRequest(WebGroup.java:276) at com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:929) at com.ibm.ws.webcontainer.WSWebContainer.handleRequest(WSWebContainer.java:1580) at com.ibm.ws.webcontainer.channel.WCChannelLink.ready(WCChannelLink.java:177) at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleDiscrimination(HttpInboundLink.java:455) at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleNewInformation(HttpInboundLink.java:384) at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.ready(HttpInboundLink.java:288) at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.sendToDiscriminators(NewConnectionInitialReadCallback.java:214) at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.complete(NewConnectionInitialReadCallback.java:113) at com.ibm.ws.tcp.channel.impl.AioReadCompletionListener.futureCompleted(AioReadCompletionListener.java:165) at com.ibm.io.async.AbstractAsyncFuture.invokeCallback(AbstractAsyncFuture.java:217) at com.ibm.io.async.AsyncChannelFuture$1.run(AsyncChannelFuture.java:205) at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1550) Caused by: java.security.AccessControlException: Access denied (java.lang.RuntimePermission getClassLoader) at java.security.AccessController.checkPermission(AccessController.java:108) at java.lang.SecurityManager.checkPermission(SecurityManager.java:532) at com.ibm.ws.security.core.SecurityManager.checkPermission(SecurityManager.java:211) at java.lang.Thread.getContextClassLoader(Thread.java:456) at serp.bytecode.Project.loadClass(Project.java:95) at serp.bytecode.Project.loadClass(Project.java:67) at org.apache.openjpa.lib.util.ConcreteClassGenerator.makeConcrete(ConcreteClassGenerator.java:61) at org.apache.openjpa.lib.jdbc.ConfiguringConnectionDecorator.(ConfiguringConnectionDecorator.java:46) ... 40 more and Caused by: java.security.AccessControlException: Access denied (java.lang.RuntimePermission createClassLoader) at java.security.AccessController.checkPermission(AccessController.java:108) at java.lang.SecurityManager.checkPermission(SecurityManager.java:532) at com.ibm.ws.security.core.SecurityManager.checkPermission(SecurityManager.java:211) at java.lang.SecurityManager.checkCreateClassLoader(SecurityManager.java:594) at java.lang.ClassLoader.(ClassLoader.java:143) at serp.bytecode.BCClassLoader.(BCClassLoader.java:25) at org.apache.openjpa.lib.util.ConcreteClassGenerator.makeConcrete(ConcreteClassGenerator.java:54) at org.apache.openjpa.lib.jdbc.ConfiguringConnectionDecorator.(ConfiguringConnectionDecorator.java:46) ... 40 more Need DoPrivilege() around the "new BCClassLoader" and "project.loadClass()";

            People

            • Assignee:
              Unassigned
              Reporter:
              Craig L Russell
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development