I'll take a stab at it. I'm familiar with Dynamic Proxies but I've never
implemented one before, so this would be a good experience. The only
drawback is that I think I'm going to have to use reflection on the wrapped
Statement/PreparedStatement since we won't know ahead of time which JDBC
version the person is going to want to use. It's going to have ugly guts,
but hopefully it will remain clean to the user other than the performance
impact of double dynamic dispatch.
Derek
On Tue, Sep 29, 2009 at 9:57 AM, David Pollak <feeder.of.the.be...@gmail.com
> wrote:
>
>
> On Tue, Sep 29, 2009 at 8:32 AM, Naftoli Gugenheim
> <naftoli...@gmail.com>wrote:
>
>>
>> Exactly. Thanks.
>> Is that an opton?
>>
>
> I think DynamicProxy is the way to go.
>
> Derek -- if you want, I can take a crack at getting to code working.
>
>
>>
>> -------------------------------------
>> Viktor Klang<viktor.kl...@gmail.com> wrote:
>>
>> On Tue, Sep 29, 2009 at 4:44 PM, Naftoli Gugenheim <naftoli...@gmail.com
>> >wrote:
>>
>> >
>> > Another option: Java has a way to dynamically implement an interface. I
>> > forgot what the classes are called. You supply a delegate and you can
>> > pattern match on which method is being invoked. In Java 5 the
>> nonexistent
>> > method will simply never be invoked, but it won't break code.
>> >
>>
>> Dynamic proxy?
>>
>>
>> >
>> > -------------------------------------
>> > Viktor Klang<viktor.kl...@gmail.com> wrote:
>> >
>> > On Tue, Sep 29, 2009 at 3:47 PM, Derek Chen-Becker <
>> dchenbec...@gmail.com
>> > >wrote:
>> >
>> > > Can you elaborate on what you mean? I was actually going to look at
>> how
>> > > log4jdbc does it and see if I could replicate it.
>> > >
>> >
>> > I haven't really tried this, but if you do:
>> >
>> > if you implement methods with the correct signatures in the
>> LoggedStatement
>> > and LoggedPreparedStatement, then wrap the invocations to the wrapped
>> > instances in a try->catch, and if there's an NoSuchMethodException,
>> return
>> > some default value?
>> >
>> >
>> >
>> > >
>> > > Derek
>> > >
>> > > On Tue, Sep 29, 2009 at 5:22 AM, Viktor Klang <viktor.kl...@gmail.com
>> > >wrote:
>> > >
>> > >> Is it possible to have a bridge trait for the Statement interface?
>> > >>
>> > >>
>> > >> On Tue, Sep 29, 2009 at 12:16 AM, Derek Chen-Becker <
>> > >> dchenbec...@gmail.com> wrote:
>> > >>
>> > >>> No. I hadn't foreseen this issue, but I understand the importance of
>> > have
>> > >>> Java 5 support. I'm fine with writing and maintaining multiple
>> versions
>> > of
>> > >>> the impls for the various versions, but I wonder if there's any
>> clean
>> > way to
>> > >>> manage this with Maven.
>> > >>>
>> > >>> Derek
>> > >>>
>> > >>>
>> > >>> On Mon, Sep 28, 2009 at 4:00 PM, David Pollak <
>> > >>> feeder.of.the.be...@gmail.com> wrote:
>> > >>>
>> > >>>> Crud. This just isn't going to be easy, is it?
>> > >>>>
>> > >>>>
>> > >>>> On Mon, Sep 28, 2009 at 2:04 PM, Derek Chen-Becker <
>> > >>>> dchenbec...@gmail.com> wrote:
>> > >>>>
>> > >>>>> Another issue, which may be more problematic, is that in my case
>> I'm
>> > >>>>> compiling against the java.sql.Statement interface. If I remove
>> the
>> > >>>>> troublesome methods so that it compiles for 1.5, it no longer
>> > compiles for
>> > >>>>> 1.6 because of the missing methods:
>> > >>>>>
>> > >>>>> [WARNING]
>> > >>>>>
>> >
>> /home/software/liftweb/lift-mapper/src/main/scala/net/liftweb/mapper/LoggingStatementWrappers.scala:70:
>> > >>>>> error: class LoggedStatement needs to be abstract, since method
>> > isPoolable
>> > >>>>> in trait Statement of type ()Boolean is not defined
>> > >>>>> [WARNING] class LoggedStatement(underlying : Statement) extends
>> > >>>>> Statement with DBLog {
>> > >>>>> [WARNING] ^
>> > >>>>> [WARNING]
>> > >>>>>
>> >
>> /home/software/liftweb/lift-mapper/src/main/scala/net/liftweb/mapper/LoggingStatementWrappers.scala:267:
>> > >>>>> error: class LoggedPreparedStatement needs to be abstract, since
>> > method
>> > >>>>> setNClob in trait PreparedStatement of type
>> (Int,java.io.Reader)Unit
>> > is not
>> > >>>>> defined
>> > >>>>> [WARNING] class LoggedPreparedStatement (stmt : String, underlying
>> :
>> > >>>>> PreparedStatement) extends LoggedStatement(underlying) with
>> > >>>>> PreparedStatement {
>> > >>>>> [WARNING] ^
>> > >>>>>
>> > >>>>>
>> > >>>>> Derek
>> > >>>>>
>> > >>>>>
>> > >>>>> On Mon, Sep 28, 2009 at 2:29 PM, David Pollak <
>> > >>>>> feeder.of.the.be...@gmail.com> wrote:
>> > >>>>>
>> > >>>>>>
>> > >>>>>>
>> > >>>>>> On Mon, Sep 28, 2009 at 1:19 PM, Derek Chen-Becker <
>> > >>>>>> dchenbec...@gmail.com> wrote:
>> > >>>>>>
>> > >>>>>>> The issue (and I may be overthinking this) is that we need 1.5
>> > class
>> > >>>>>>> libraries to compile against if we want to be able to verify
>> that
>> > the code
>> > >>>>>>> compiles under 1.5. If I, say, delete my JDK 5 install and
>> decide
>> > to
>> > >>>>>>> reinstall it down the road, it's not going to be available
>> without
>> > a
>> > >>>>>>> purchased license.
>> > >>>>>>>
>> > >>>>>>
>> > >>>>>> I can stash away a bunch of different copies of the JDK and give
>> > them
>> > >>>>>> to you when you need them.
>> > >>>>>>
>> > >>>>>> A 32 bit Linux JDK 1.5 should be enough to at least do smoke test
>> > >>>>>> builds with.
>> > >>>>>>
>> > >>>>>>
>> > >>>>>>>
>> > >>>>>>> Derek
>> > >>>>>>>
>> > >>>>>>>
>> > >>>>>>>
>> > >>>>>>> On Mon, Sep 28, 2009 at 1:33 PM, David Pollak <
>> > >>>>>>> feeder.of.the.be...@gmail.com> wrote:
>> > >>>>>>>
>> > >>>>>>>>
>> > >>>>>>>>
>> > >>>>>>>> On Mon, Sep 28, 2009 at 11:51 AM, Derek Chen-Becker <
>> > >>>>>>>> dchenbec...@gmail.com> wrote:
>> > >>>>>>>>
>> > >>>>>>>>> My main concern is that after October 30, Java 5 costs money
>> (I'm
>> > >>>>>>>>> guessing not a trivial amount, either). I can get the JDK
>> right
>> > now, but if
>> > >>>>>>>>> some bug in the Java libraries pops up that would prevent
>> things
>> > from
>> > >>>>>>>>> working, I don't know how we'll work around that.
>> > >>>>>>>>>
>> > >>>>>>>>
>> > >>>>>>>> I don't see the condition under which that could happen. When
>> we
>> > >>>>>>>> compile against Java 1.5, we are simply defining the contract
>> > between our
>> > >>>>>>>> classes and the library classes. None of the library "seeps"
>> into
>> > our code
>> > >>>>>>>> (this is not true of Scala traits). So, as long as the running
>> > library has
>> > >>>>>>>> the classes/methods that we are calling, we're fine. Compiling
>> > against 1.5
>> > >>>>>>>> simply means that we have fewer calls that we can make. If
>> there
>> > is an
>> > >>>>>>>> issue in 1.5 that a user is experiencing, that is the user's
>> > issue, not
>> > >>>>>>>> ours. If the code compiles (and runs tests) against 1.5 and
>> does
>> > not
>> > >>>>>>>> generate the particular issue that the user is seeing under
>> 1.6,
>> > then that
>> > >>>>>>>> use has to contact Sun, not us.
>> > >>>>>>>>
>> > >>>>>>>>
>> > >>>>>>>>>
>> > >>>>>>>>> Derek
>> > >>>>>>>>>
>> > >>>>>>>>> On Mon, Sep 28, 2009 at 12:29 PM, David Pollak <
>> > >>>>>>>>> feeder.of.the.be...@gmail.com> wrote:
>> > >>>>>>>>>
>> > >>>>>>>>>>
>> > >>>>>>>>>>
>> > >>>>>>>>>> On Mon, Sep 28, 2009 at 11:14 AM, Derek Chen-Becker <
>> > >>>>>>>>>> dchenbec...@gmail.com> wrote:
>> > >>>>>>>>>>
>> > >>>>>>>>>>> I was just about to work on issue #67 (build breaks on Java
>> 5),
>> > >>>>>>>>>>> but when I went to get a Java 5 JDK to compile/test with,
>> Sun
>> > says that it's
>> > >>>>>>>>>>> EOL as of October 30, 2009. I don't have a problem fixing
>> > things to work
>> > >>>>>>>>>>> with Java 5, but I don't want to do work that's going to be
>> > tossed out in a
>> > >>>>>>>>>>> month.
>> > >>>>>>>>>>>
>> > >>>>>>>>>>>
>> > >>>>>>>>>> Lift will be JDK 1.5 compatible for at least 1 year (and
>> > probably
>> > >>>>>>>>>> longer). LinkedIn and SAP are both 1.5 shops. There are
>> tons
>> > of other Bay
>> > >>>>>>>>>> Area companies (Wells Fargo, Kaiser, etc.) that are also 1.5
>> > shops. For the
>> > >>>>>>>>>> next 2-3 years, OS X 10.5 will be common and 10.5 + old
>> MacBooks
>> > == 1.5.
>> > >>>>>>>>>>
>> > >>>>>>>>>> It will not be lost work.
>> > >>>>>>>>>>
>> > >>>>>>>>>>
>> > >>>>>>>>>>> Derek
>> > >>>>>>>>>>>
>> > >>>>>>>>>>>
>> > >>>>>>>>>>>
>> > >>>>>>>>>>
>> > >>>>>>>>>>
>> > >>>>>>>>>> --
>> > >>>>>>>>>> Lift, the simply functional web framework http://liftweb.net
>> > >>>>>>>>>> Beginning Scala http://www.apress.com/book/view/1430219890
>> > >>>>>>>>>> Follow me: http://twitter.com/dpp
>> > >>>>>>>>>> Surf the harmonics
>> > >>>>>>>>>>
>> > >>>>>>>>>>
>> > >>>>>>>>>>
>> > >>>>>>>>>>
>> > >>>>>>>>>
>> > >>>>>>>>>
>> > >>>>>>>>>
>> > >>>>>>>>
>> > >>>>>>>>
>> > >>>>>>>> --
>> > >>>>>>>> Lift, the simply functional web framework http://liftweb.net
>> > >>>>>>>> Beginning Scala http://www.apress.com/book/view/1430219890
>> > >>>>>>>> Follow me: http://twitter.com/dpp
>> > >>>>>>>> Surf the harmonics
>> > >>>>>>>>
>> > >>>>>>>>
>> > >>>>>>>>
>> > >>>>>>>
>> > >>>>>>>
>> > >>>>>>>
>> > >>>>>>
>> > >>>>>>
>> > >>>>>> --
>> > >>>>>> Lift, the simply functional web framework http://liftweb.net
>> > >>>>>> Beginning Scala http://www.apress.com/book/view/1430219890
>> > >>>>>> Follow me: http://twitter.com/dpp
>> > >>>>>> Surf the harmonics
>> > >>>>>>
>> > >>>>>>
>> > >>>>>>
>> > >>>>>
>> > >>>>>
>> > >>>>>
>> > >>>>
>> > >>>>
>> > >>>> --
>> > >>>> Lift, the simply functional web framework http://liftweb.net
>> > >>>> Beginning Scala http://www.apress.com/book/view/1430219890
>> > >>>> Follow me: http://twitter.com/dpp
>> > >>>> Surf the harmonics
>> > >>>>
>> > >>>>
>> > >>>>
>> > >>>
>> > >>>
>> > >>>
>> > >>
>> > >>
>> > >> --
>> > >> Viktor Klang
>> > >>
>> > >> Blog: klangism.blogspot.com
>> > >> Twttr: viktorklang
>> > >>
>> > >> Lift Committer - liftweb.com
>> > >> AKKA Committer - akkasource.org
>> > >> Cassidy - github.com/viktorklang/Cassidy.git
>> > >> SoftPub founder: http://groups.google.com/group/softpub
>> > >>
>> > >>
>> > >>
>> > >>
>> > >
>> > > >
>> > >
>> >
>> >
>> > --
>> > Viktor Klang
>> >
>> > Blog: klangism.blogspot.com
>> > Twttr: viktorklang
>> >
>> > Lift Committer - liftweb.com
>> > AKKA Committer - akkasource.org
>> > Cassidy - github.com/viktorklang/Cassidy.git
>> > SoftPub founder: http://groups.google.com/group/softpub
>> >
>> >
>> >
>> > >
>> >
>>
>>
>> --
>> Viktor Klang
>>
>> Blog: klangism.blogspot.com
>> Twttr: viktorklang
>>
>> Lift Committer - liftweb.com
>> AKKA Committer - akkasource.org
>> Cassidy - github.com/viktorklang/Cassidy.git
>> SoftPub founder: http://groups.google.com/group/softpub
>>
>>
>>
>>
>>
>
>
> --
> Lift, the simply functional web framework http://liftweb.net
> Beginning Scala http://www.apress.com/book/view/1430219890
> Follow me: http://twitter.com/dpp
> Surf the harmonics
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~----------~----~----~----~------~----~------~--~---
