OK, here it is:
http://reviewboard.liftweb.net/r/18/
Derek
On Tue, Sep 29, 2009 at 10:10 AM, Derek Chen-Becker
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
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
On Tue, Sep 29, 2009 at 8:32 AM, Naftoli Gugenheim 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 wrote:
>
> On Tue, Sep 29, 2
Exactly. Thanks.
Is that an opton?
-
Viktor Klang wrote:
On Tue, Sep 29, 2009 at 4:44 PM, Naftoli Gugenheim 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
On Tue, Sep 29, 2009 at 3:46 PM, Viktor Klang wrote:
>
>
> On Tue, Sep 29, 2009 at 4:44 PM, Naftoli Gugenheim
> 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
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.
---
On Tue, Sep 29, 2009 at 4:44 PM, Naftoli Gugenheim 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 si
On Tue, Sep 29, 2009 at 3:47 PM, Derek Chen-Becker 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 Logged
Argh. log4jdbc has two source trees, one for JDK 1.4 and one for JDK 6 :(
On Tue, Sep 29, 2009 at 7:47 AM, Derek Chen-Becker 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.
>
> Derek
>
>
> On Tue, Sep 29, 2009 at
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.
Derek
On Tue, Sep 29, 2009 at 5:22 AM, Viktor Klang wrote:
> Is it possible to have a bridge trait for the Statement interface?
>
>
> On Tue, Sep 29, 2009 at 12:16 AM, Derek
Is it possible to have a bridge trait for the Statement interface?
On Tue, Sep 29, 2009 at 12:16 AM, Derek Chen-Becker
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 t
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 Po
In some code we have at work that has to support Java 1.6 and down for
certain things, we had to resort to having multiple versions and
dynamically Class.forName the right one in at runtime. I would be
overjoyed to hear of a better solution :-/
-Ross
On Sep 28, 2009, at 6:00 PM, David Polla
Crud. This just isn't going to be easy, is it?
On Mon, Sep 28, 2009 at 2:04 PM, Derek Chen-Becker 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,
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/m
On Mon, Sep 28, 2009 at 1:19 PM, Derek Chen-Becker 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 t
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
On Mon, Sep 28, 2009 at 11:51 AM, Derek Chen-Becker
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 kn
On Mon, Sep 28, 2009 at 8:51 PM, Derek Chen-Becker 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 kno
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.
Derek
On Mon, Sep 28, 2009 at 12:29
On Mon, Sep 28, 2009 at 11:14 AM, Derek Chen-Becker
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
Hmm - had this problem the other day. The only real downside of not
letting it build on 1.5 from my position is that people on Mac will
need to tweak the PATH because the default JDK is 5, not 6 (which is
installed too, oddly)
Might be some others, but I cant think of them.
Cheers, Tim
On
22 matches
Mail list logo
