[jira] Updated: (OPENJPA-5) OpenJPA doesn't compile with JDBC 4
[ https://issues.apache.org/jira/browse/OPENJPA-5?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marc Prud'hommeaux updated OPENJPA-5: - Attachment: OPENJPA-5.patch 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. OpenJPA doesn't compile with JDBC 4 --- Key: OPENJPA-5 URL: https://issues.apache.org/jira/browse/OPENJPA-5 Project: OpenJPA Issue Type: Improvement Components: build / infrastructure Affects Versions: 0.9.0, 0.9.6 Reporter: Craig Russell Fix For: 1.0.0 Attachments: OPENJPA-5.patch 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. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OPENJPA-5) OpenJPA doesn't compile with JDBC 4
[ https://issues.apache.org/jira/browse/OPENJPA-5?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Sutter updated OPENJPA-5: --- Fix Version/s: 1.0.0 Affects Version/s: 0.9.0 0.9.6 OpenJPA doesn't compile with JDBC 4 --- Key: OPENJPA-5 URL: https://issues.apache.org/jira/browse/OPENJPA-5 Project: OpenJPA Issue Type: Improvement Components: build / infrastructure Affects Versions: 0.9.0, 0.9.6 Reporter: Craig Russell Fix For: 1.0.0 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. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OPENJPA-5) OpenJPA doesn't compile with JDBC 4
[ https://issues.apache.org/jira/browse/OPENJPA-5?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Linskey updated OPENJPA-5: -- Component/s: build / infrastructure OpenJPA doesn't compile with JDBC 4 --- Key: OPENJPA-5 URL: https://issues.apache.org/jira/browse/OPENJPA-5 Project: OpenJPA Issue Type: Improvement Components: build / infrastructure Reporter: Craig Russell 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. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
