db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Katherine Marsden <kmarsdende...@sbcglobal.net>
Subject Re: Changing logging mechanism for derby.log
Date Fri, 13 Jul 2012 17:23:13 GMT
On 7/12/2012 11:15 PM, Suat Gonul wrote:
> Hi Libor,
> Yes, I am aware of the option for getting a system property in an OSGi 
> bundle. Well, in the system, there may be other bundles (which I'm not 
> aware of/responsible) consuming Derby and they may have their own 
> configurations for logging. Even I may have two different components 
> using different schemas. For instance,
>   * "jdbc:derby:schema1"
>   * "jdbc:derby:schema2"
> are two schemas which are completely disjoint and used by different 
> components. That's way I wanted to have different logging 
> configurations for different components/bundles.
> I think the solution lies in a system-wide, common logging class which 
> is aware of the source class calling the logging method. So, it can 
> direct the log to corresponding OutputStreams.
I am not familiar with OSGI, but it seems to be a specific case of the 
that  system properties are problematic in multiple classloader contexts 
especially when those contexts might be totally logically disconnected.  
The worst is derby.system.home if we could find a way to diferentiate 
that then other properties could be get picked up from derby.properties 
in various location, but even that requires some coordination between 
applications.  I think actually currently there may be problems with 
derby.log getting clobbered in multiple classLoader contexts even when 
left in the standard location.

It would be ideal to be able to bundle embedded Derby in an application 
and especially in a component  with total isolation and no need for 
coordination with the embedding application, especially when that 
embedding application also may use derby.

So is there a good mechanism for classLoader scope setttings like this 
that might be good to add to derby?  I have thought about this but don't 
really know of a good solution. The best thing I have been able to come 
up with is to maybe have a DataSource property to set either the name of 
a resource file to pickup the properties or an alternate 
derby.system.home where a derby.properties could be picked up.  I don't 
like this because it seems like the wrong scope and if Derby is already 
booted these settings obviously have no meaning.

There is actually  a Jira issue for this problem filed in 2006!

I think if we could think of a good solution, someone would likely pick 
it up.


View raw message