OK, here it is:
http://reviewboard.liftweb.net/r/18/
Derek
On Tue, Sep 29, 2009 at 10:10 AM, Derek Chen-Becker
<dchenbec...@gmail.com>wrote:
> 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
-~----------~----~----~----~------~----~------~--~---
