Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [virgo-dev] Including logback.xml in the bundle
Here is the defect https://bugs.eclipse.org/bugs/show_bug.cgi?id=326423

Test bundle is attached.

Regards,

Dmitry

On Mon, Sep 27, 2010 at 12:12 PM, Glyn Normington <gnormington@xxxxxxxxxx> wrote:
That sounds like a plausible explanation of what's going on. I was under the impression that Equinox types would only be loaded once, but I may have missed some of the subtleties of this version of the nested framework support. The newer incarnation currently being discussed in the OSGi Alliance definitely loads all the framework types only once, so that may be what's confusing me.

Do you have a self-contained testcase you could attach to a bug? I think I need to get a debugger on this thing...

Regards,
Glyn

On 27 Sep 2010, at 15:37, Dmitry Sklyut wrote:

Hi Glyn,

Classes are definitely loaded by different classloaders.

delegate.getClassLoader.loadClass("org.eclipse.osgi.internal.loader.BundleLoader"):
Above results in class instance loaded by org.eclipse.osgi.launch.EquinoxFWClassLoader

this.getClass.getClassLoader.loadClass("org.eclipse.osgi.internal.loader.BundleLoader"):
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?

Regards,
Dmitry

On Mon, Sep 27, 2010 at 4:56 AM, Glyn Normington <gnormington@xxxxxxxxxx<mailto: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.

delegate.getClassLoader.loadClass("org.eclipse.osgi.internal.loader.BundleLoader")

and

this.getClass.getClassLoader.loadClass("org.eclipse.osgi.internal.loader.BundleLoader")

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:

delegate.getClassLoader.loadClass("org.eclipse.osgi.internal.loader.BundleLoader").getClassLoader

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!

Regards,
Glyn

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

_______________________________________________
virgo-dev mailing list
virgo-dev@xxxxxxxxxxx<mailto:virgo-dev@xxxxxxxxxxx><mailto:virgo-dev@xxxxxxxxxxx<mailto:virgo-dev@xxxxxxxxxxx>>
https://dev.eclipse.org/mailman/listinfo/virgo-dev

<ATT00001..txt>

_______________________________________________
virgo-dev mailing list
virgo-dev@xxxxxxxxxxx<mailto:virgo-dev@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/virgo-dev

<ATT00001..txt>

_______________________________________________
virgo-dev mailing list
virgo-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/virgo-dev

Back to the top