On 24 Sep 2010, at 19:56, Dmitry Sklyut wrote:
Glyn,
I finally got time to dig into this. Here is what I see (a bit mind numbing btw)
I have a logback.xml in the root of the bundle.
I make a call to LoggerFactory.getLog("someLog").info(....).
This call finally gets to org.eclipse.virgo.medic.log.impl.StandardCallingBundleResolver.getCallingBundle().
That internally figures out the first stack frame that is not from logging packages and tries to figure out the bundle that loaded that by calling into:
packageAdmin.getBundle(loggingCallersClass);
In packageAdmin (equinox impl):
// code from the getBundle().
Bundle getBundlePriv(Class clazz) {
ClassLoader cl = clazz.getClassLoader();
if (cl instanceof BundleClassLoader) {
ClassLoaderDelegate delegate = ((BundleClassLoader) cl).getDelegate();
if (delegate instanceof BundleLoader)
return ((BundleLoader) delegate).getBundle();
}
if (cl == getClass().getClassLoader())
return framework.systemBundle;
return null;
}
This is where fun starts. The check for "if (delegate instanceof BundleLoader)" always returns "false"...
The classloader for the class passed into packageAdmin.getBundle() is KernelBundleClassLoader: [bundle=my.bundle.this.or.that_1.2.0.BUILD-SNAPSHOT]
This passes first check "if (cl instanceof BundleClassLoader)".
delegate: my.bundle.this.or.that_1.2.0.BUILD-SNAPSHOT and looking in debugger is of type org.eclipse.osgi.internal.loader.BundleLoader
Classloaders for both my class and delegate are identical instances of org.eclipse.virgo.userregion.internal.equinox.KernelBundleClassLoader. Both reference object id 171 (from debugger info).
But evaluating this chunk of code: BundleLoader.class.getClassLoader() results in sun.misc.Launcher$AppClassLoader@1f7182c1
Not sure who is right here and how to address this. Maybe try FrameworkUtils.getBundle()???
Any thoughts on how to start tackling this?
Regards,
Dmitry
On Fri, Jul 23, 2010 at 3:39 AM, Glyn Normington <
gnormington@xxxxxxxxxx<mailto:
gnormington@xxxxxxxxxx>> wrote:
Hi Dmitry
I should have mentioned that a user can configure Logback for a given bundle by adding a file called logback.xml (or logback-default.xml) to the root of the bundle.
This function should be exercised by MedicLoggingIntegrationTests. The test naming could be better, but test_bundle_1 and test_bundle_2 both use per-bundle configuration.
Regards,
Glyn
On 23 Jul 2010, at 07:23, Glyn Normington wrote:
> Hi Dmitry
>
> There is support for that built into medic, so perhaps you've found a (basic) bug.
>
> If you want to dig into this, please take a look at the following medic classes.
>
> Reading the config out of a bundle is handled by BundleResourceConfigurationLocator. The different ConfigurationLocators are combined and called in order by CompositeConfigurationLocator which is created in MedicActivator.
>
> Regards,
> Glyn
> On 22 Jul 2010, at 15:35, Dmitry Sklyut wrote:
>
>> Hi,
>>
>> Is there support for including logback.xml together with the deployed bundle? All of the things that I tried did not work.
>> During 2gx last year Rob and Ben mentioned that it is possible. I am wondering if I am missing some manifest header or some magic pixie dust to get it to work.
>>
>> Looking at the medic code I did not see any extender like functionality for look for bundle/logback.xml or bundle/META-INF/logback.xml...
>>
>> I have a use case where I would like to re-use logging framework to write out log file into a separate file per instance of Spring Batch job.
>>
>> Regards,
>>
>> Dmitry
>> <ATT00001..txt>
>
> _______________________________________________
> virgo-dev mailing list
