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

Hi Glyn,

Classes are definitely loaded by different classloaders.

Above results in class instance loaded by org.eclipse.osgi.launch.EquinoxFWClassLoader

Results in a different class instance loaded by sun.misc.Launcher$AppCL

Is this because of nested frameworks?  I am not exactly sure how CompositeBundleFactory/CompositeBundle/SurrogateBundle work its magic.  I can only assume that because there is a new Framework instance created and because org.eclipse.virgo.kernel.userregion is loaded by the new "inner" framework, this causes the PackageAdmin check to fail.

What do you think?


On Mon, Sep 27, 2010 at 4:56 AM, Glyn Normington <gnormington@xxxxxxxxxx> wrote:
Hi Dmitry

"delegate instanceof BundleLoader" is of course the _expression_ to probe.

You observe in the debugger that delegate is an instance of BundleLoader, but the big question is whether this is the same BundleLoader runtime type that package admin sees.

Use the debugger (while in the stack frame for getBundle) to evaluate the following expressions.




If the expressions yield distinct class instances, then that will be why the instanceof is failing and you'll need to try to determine why those are distinct. Read on.

BundleLoader.class.getClassLoader will return Equinox's class loader which is the JRE's application class loader, as you observe. Next, take a look at:


to get the defining class loader of that instance of the BundleLoader class.

(If the expressions yield the same class instance, then I cannot explain why the instanceof is failing, but will think harder if that turns out to be the case!)

Hope that helps!


On 24 Sep 2010, at 19:56, Dmitry Sklyut wrote:


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<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.

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

virgo-dev mailing list


virgo-dev mailing list