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
problem
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!
https://issues.apache.org/jira/browse/DERBY-1228
I think if we could think of a good solution, someone would likely pick
it up.
Kathey
