Re: [virgo-dev] Confused about medic.core packaging.

[Glyn Normington <gnormington@xxxxxxxxxx>]

Hi Dmitry

You really got me scratching my head and asking around. I hope the answers interspersed below are readable after this email has been distributed to virgo-dev...

Regards,
Glyn
On 15 Jul 2010, at 04:03, Dmitry Sklyut wrote:

> Hi,
> 
> So after a bit of hiatus I finally got some time to work on maven build for virgo. 

Glad to hear it.

> 
> It was mostly a smooth running till I hit medic component.
> 
> Here is what I understand up to this moment:
> 
> 1. *.medic == API bundle
>    Code here is woven with EntryExitTrace aspect

That used to be true, but medic is now excluded from the EntryExitTrace joinpoint specification as part of the recent "5x" startup performance improvement. (The aspect build can probably be tidied up in due course.)

> 2. medic.weaving == Aspect library
>   LoggingInterceptor

This can be deleted in due course as the aspect which used to depend on it was deleted in the performance work. Some other code probably needs changing to remove all references to LoggingInterceptor.

> 3. org.eclipse.virgo.ch.qos.logback.classic.woven
>   As the name says - a woven logback.classic with medic.weaving aspect

I think this is now equivalent to the Logback classic JAR as the weaving is now a no-op.

> 4. medic.core = implementation of API
> 
> Now the issues that is throwing me off is a manifest generated for medic.core (attached).  
> 
> So my questions:
> 1. Why is all of the logback.classic and logback.core packages are exported with medic.core version?

That seems to be an oversight. They should be exported with the logback version. If you raise a bug and ideally provide a patch, this can be changed very easily. (I believe no-one is using these exports as they are not imported in the kernel region. In particular these exports are not imported into the user region and so are not available for applications to import.)

> 2. Should those exports be there?  

Yes. Medic is designed so that people can write their own Logback appenders which therefore need access to the Logback appender type.

> 3. Is that by design or just because jars got copied to target/classes and bundlor was happy to use them?  

By design. There is a testcase that implements a Logback appender.

> 4. template.mf does not specify Bundle-ClassPath, is it bundlor that adds it when it finds jars?  (did not know it can do it).

Apparently so.

> 
> And just out of curiosity: 
> 5. Why do those bundles need to be embedded?  

I believe the original reasoning may have been to place the Logback core and classic classes in a single class loader to address some class loading scenarios, but we do not appear to have taken advantage of that. Another reason may have been to (partially) hide the existence of the woven Logback classic JAR to avoid confusion with a vanilla Logback classic JAR, but that isn't important now that we are no longer weaving Logback classic.

However, I quite like these JARs being embedded in medic core as it avoids unnecessary bundle loading at startup.

> 6. Why do they need to be weaved (I have not dug too deep into code yet to get it)?

The purpose of weaving was to enable in-memory logging, which we no longer provide.

> 
> Regards,
> 
> Dmitry
> <MANIFEST.MF><ATT00001..txt>