underlying jdbc driver support

[David Hadley]

I would like to use a different underlying jdbc driver that is not
already supported. The docs urge me to set a system property,
log4jdbc.drivers to the class name of the additional driver. This
works
great! Thank you.

I do not like the global nature of a system property however. I am
wondering if a secondary method could be used to set this value, for
example a pre defined configuration file somewhere in the class path.
This way two applications running on the same system using different
drivers wouldn't have visibility to each others values.

Do you believe I have identified a problem? Is it solved in a way I
am unaware of? If I were to create a patch do you think this is
something we might consider accepting?

[Arthur Blake]

Sorry for taking so long to get back to you. Not sure why using
system properties is an issue as two apps can have their own set of
system properties at startup (they wouldn't be exposed to the same
system properties by virtue of having different startup command
lines.)

However, I had been thinking about something along these lines for
quite some time (even before you emailed) for another reason.
I think it would be good to have the ability to load the settings from
a properties files in the classpath mainly because the number of
options is starting to grow large and it's just plain cumbersome to
have many options on the command line.

I also was thinking about turning off the feature that tries to auto-
load drivers. It seemed like a neat idea and the goal was to simplify
the configuration. But in practice it can cause the loading of
database drivers that just happen to be on the classpath, but are
never used (a memory hit for sure, and in some cases it can cause
other side effects.)

I was thinking about leaving the current behavior for that for
backward compatibility and just creating a new version of the driver,
in the code.google.com package name space that has the new behavior.
I also want to make the whole think much more modular.

I'm not sure when I'll get a chance to work on this as I'm extremely
busy with other things at the moment, but it's probably the direction
I'd take.

Feel free to make a patch, but I can't guarantee I'll use it. If the
code is of very high quality and well commented, I'd probably be more
inclined to use it.

[David Hadley]

OK, well let's see if I am competent at a few of the basics.

This is a patch that cleans up some of the problems eclipse reported in the src-jdbc4 code.  I added generics and removed some of the type casting just to get my feet wet.

If anyone is using eclipse could you please export your preferences and send them to me so I can use ctrl-shift-f to format the code base without having things shift?

dh

--
You received this message because you are subscribed to the Google Groups "log4jdbc" group.
To post to this group, send email to log4...@googlegroups.com.
To unsubscribe from this group, send email to log4jdbc+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/log4jdbc?hl=en.

[David Hadley]

Sigh.. I hit send before attaching the patch.  My apologies.

dh

On Fri, Mar 19, 2010 at 4:49 PM, Arthur Blake <arthur...@gmail.com> wrote:

[Arthur Blake]

I appreciate the effort, but these are things I definitely do not want
added to the code.
I want to keep the 3 and 4 lines as close as possible so that
differencing remains concise and easy.
It would be OK to add generics to parts of the code that are not in
the 3 line at all-- but there isn't much in that space.

On Mar 21, 3:46 am, David Hadley <david.e.had...@gmail.com> wrote:
> Sigh.. I hit send before attaching the patch.  My apologies.
>
> dh
>

> > log4jdbc+u...@googlegroups.com<log4jdbc%2Bunsubscribe@googlegroups.c om>

> > .
> > For more options, visit this group at
> >http://groups.google.com/group/log4jdbc?hl=en.
>
>
>

>  src-jdbc4.patch
> 11KViewDownload

[Dean Hiller]

I think the original poster meant same apps in an appserver like tomcat so two different log4jdbc drivers with their own properties could be used(ie. same JVM)...interesting scenario I think.  I don't have that use case myself, but I understand his case.  I personally only have the driver once and pool above that and all apps using the same pool to conserver resources.

I think that is what he meant by "same system"....same JVM, so properties doesn't really work for that guy it sounds like.
later,
Dean

--
You received this message because you are subscribed to the Google Groups "log4jdbc" group.
To post to this group, send email to log4...@googlegroups.com.

To unsubscribe from this group, send email to log4jdbc+u...@googlegroups.com.

[Arthur Blake]

I understand, but if that's the case, do either of you have any
suggestions?

Perhaps, we should retain the system properties as a way to set the
properties globally and then use connection properties as a way to
override them on a per connection basis?
This issue doesn't seem to me like it's of very high priority or
importance, but I'm ready to listen to any good ideas you might have
about it.

On Mar 23, 3:32 pm, Dean Hiller <dean.hil...@gmail.com> wrote:
> I think the original poster meant same apps in an appserver like tomcat so
> two different log4jdbc drivers with their own properties could be used(ie.
> same JVM)...interesting scenario I think.  I don't have that use case
> myself, but I understand his case.  I personally only have the driver once
> and pool above that and all apps using the same pool to conserver resources.
>
> I think that is what he meant by "same system"....same JVM, so properties
> doesn't really work for that guy it sounds like.
> later,
> Dean
>

> > log4jdbc+u...@googlegroups.com<log4jdbc%2Bunsubscribe@googlegroups.c om>

[Dean Hiller]

yeah, hard to say, I agree.  In jboss the ds file can be used per single driver and put in extra properties, but that solution seems to specific...not sure how other platforms do it and if they are close enough to the same as how jboss does it.

To unsubscribe from this group, send email to log4jdbc+u...@googlegroups.com.