[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [virgo-dev] Including logback.xml in the bundle


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:


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?



On Fri, Jul 23, 2010 at 3:39 AM, Glyn Normington <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.

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
> virgo-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/virgo-dev

virgo-dev mailing list