Imagine my surprise that we now have duplicates in our tiny JIRA repo!
Craig On Jul 31, 2006, at 11:07 PM, Brett Porter wrote:
Hmm, did we all create the same JIRA issue? :) I crated OPENJPA-4 at the same time as the other issue, but it seems -5 and -6 are both about the same thing. - Brett On 01/08/06, Craig L Russell <[EMAIL PROTECTED]> wrote:This definitely needs a JIRA issue. We should use the JIRA to track our discussion of the issue, unless folks think it's better to use our wiki. Is it set up yet? Craig On Jul 31, 2006, at 10:15 PM, Patrick Linskey wrote: Yes, 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 ofreasons: to resolve database-specific bugs in a transparent fashion, toprovide logging, to handle reference counting, etc.The pressing issue is that we must provide implementations of all of themethods in the various java.sql interfaces. The fact that we do notimplement the new JDBC4 methods is why OpenJPA won't currently compileagainst JDK6. This is pretty easy to fix; take a look at org.apache.openjpa.lib.jdbc.DelegatingStatement to see how we handledthis 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 Kododoesn't use any of these methods, our mechanism for implementing them islimiting, in that users who obtain Connections from Kodo will not beable to use the new JDBC3/JDBC4 methods in their own code. Ideally, weshould provide some means for people to designate to OpenJPA that itshould use a dynamic proxy to implement the unimplemented methods. Thisshouldn't be the default behavior, as the dynamic proxy will addoverhead, but certainly could be desirable for some. I'll file an issue.> > -Patrick > > -- > Patrick Linskey > BEA Systems, Inc. > >> -----Original Message----- >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] >> Sent: Monday, July 31, 2006 10:02 PM >> To: open-jpa-dev@incubator.apache.org >> Subject: Re: JDBC 4 (was: Was it just me?) >> >> You can access earlier versions of jdbc to compile against >> using special javac properties for library jars. But I don't >> know how maven deals with this. >>>> What specific errors are you getting when compiling against jdbc 4?>> I'm not aware of any additions that would make programs that >> compile against jdbc 3 not compile against jdbc 4. You don't >> *implement* any jdbc interfaces, do you? >> >> Craig >> >> On Jul 31, 2006, at 8:37 PM, Patrick Linskey wrote: >> >>>>>> BTW, you may be aware, but it doesn't compile on Java 6 >>>> due to the >>>>>> JDBC interface changes. I'll add that to JIRA if its not there >>>>>> already. >>>>> >>>>> Yeah, we've had this problem in the past as well. >>>> Historically, we've >>>>> created special modified JDBC jars so that we can compile >>>> on earlier >>>>> VM versions. How is this type of problem typically handled >>>> in Apache-land? >>>> >>>> Isn't this the other way around? If the additional methods are >>>> implemented to make it compile on Java 6, it will continue to be >>>> binary compatible with the earlier JDBC versions. >>> >>> Yes, that. Meant "so that we can run on earlier VM versions." >>> >>> So... how does Apache typically deal with this? The only >> alternate to >>> the way we've done things in the past is an approach that >> uses dynamic >>> proxies / auto-generated proxies / dynamically-modified classes. >>> >>> -Patrick >>>>> _____________________________________________________________________>> _ >>> _ >>> Notice: This email message, together with any attachments, may >>> contain >>> information of BEA Systems, Inc., its subsidiaries and >>> affiliated >>> entities, that may be confidential, proprietary, copyrighted >>> and/or >>> legally privileged, and is intended solely for the use of the >>> individual or entity named in this message. If you are not the>>> intended recipient, and have received this message in error, please>>> immediately return this by email and then delete it. >> >> Craig Russell>> Architect, Sun Java Enterprise System http://java.sun.com/ products/>> jdo>> 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!>> >>> _____________________________________________________________________ _> _ > Notice: This email message, together with any attachments, may > contain > information of BEA Systems, Inc., its subsidiaries and > affiliated > entities, that may be confidential, proprietary, copyrighted > and/or > legally privileged, and is intended solely for the use of the > individual > or entity named in this message. If you are not the intended > recipient, > and have received this message in error, please immediately return > this > by email and then delete it. Craig RussellArchitect, Sun Java Enterprise System http://java.sun.com/products/ jdo408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!-- Apache Maven - http://maven.apache.org "Better Builds with Maven" book - http://library.mergere.com/
Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
smime.p7s
Description: S/MIME cryptographic signature
