Community
Participate
Working Groups
AFAIK it isn't necessary to package logback in medic.core anymore and by moving it out we'll make the logging bundle relations clearer and more understandable.
(In reply to comment #0) > AFAIK it isn't necessary to package logback in medic.core anymore and by moving > it out we'll make the logging bundle relations clearer and more understandable. Correct. We used to embed logback because we wove it to support in-memory trace and we didn't want users seeing the woven logback and getting surprised that it was different from vanilla logback. Since in-memory trace was costly and mostly useless, we dropped it and so there is no longer any need to weave logback or embed it in medic.core. The only complication of moving it out is that medic.core and logback will then have independent lifecycles, which probably complicates startup and perhaps shutdown.
(In reply to comment #1) > The only complication of moving it out is that medic.core and logback will then > have independent lifecycles, which probably complicates startup and perhaps > shutdown. A quick check in EBR shows both logback.core[1] and logback.classic[2] don't have any active parts. So just proper wiring is required, no activation. To clear this up for the implementor, doesn't that leave logback to the mercy of the medic.core's lifecycle only? [1]http://ebr.springsource.com/repository/app/bundle/version/download?name=com.springsource.ch.qos.logback.core&version=0.9.28&type=binary [2]http://ebr.springsource.com/repository/app/bundle/version/download?name=com.springsource.ch.qos.logback.classic&version=0.9.28&type=binary
(In reply to comment #2) > (In reply to comment #1) > > The only complication of moving it out is that medic.core and logback will then > > have independent lifecycles, which probably complicates startup and perhaps > > shutdown. > > A quick check in EBR shows both logback.core[1] and logback.classic[2] don't > have any active parts. So just proper wiring is required, no activation. > To clear this up for the implementor, doesn't that leave logback to the mercy > of the medic.core's lifecycle only? Well spotted. In fact, logback would perform its own function perfectly adequately without medic.core ACTIVE or even present.
I am developiong this change on the branch bug362095-move-logback-out-of-medic-core. Fragments containing custom appenders now need to specify: Fragment-Host: com.springsource.ch.qos.logback.classic instead of: Fragment-Host: org.eclipse.virgo.medic.core This has been noted in the migration guide ([1]). Integration tests need extra dependencies in ivy.xml: <dependency org="org.eclipse.virgo.medic" name="org.eclipse.virgo.medic.logbackcorefragment" rev="${org.eclipse.virgo.medic}" conf="test->runtime"/> <dependency org="org.eclipse.virgo.medic" name="org.eclipse.virgo.medic.logbackclassicfragment" rev="${org.eclipse.virgo.medic}" conf="test->runtime"/> <dependency org="ch.qos.logback" name="com.springsource.ch.qos.logback.classic" rev="${ch.qos.logback}" conf="test->runtime"/> <dependency org="ch.qos.logback" name="com.springsource.ch.qos.logback.core" rev="${ch.qos.logback}" conf="test->runtime"/> These are typically addded after the line: <dependency org="org.eclipse.virgo.medic" name="org.eclipse.virgo.medic.core" rev="${org.eclipse.virgo.medic}" conf="test->runtime"/> Integration tests also need additional bundles and fragments in src/test/resources/META-INF/test.config.properties: file:../ivy-cache/repository/org.eclipse.virgo.medic/org.eclipse.virgo.medic.logbackcorefragment/${org.eclipse.virgo.medic}/org.eclipse.virgo.medic.logbackcorefragment-${org.eclipse.virgo.medic}.jar,\ file:../ivy-cache/repository/org.eclipse.virgo.medic/org.eclipse.virgo.medic.logbackclassicfragment/${org.eclipse.virgo.medic}/org.eclipse.virgo.medic.logbackclassicfragment-${org.eclipse.virgo.medic}.jar,\ file:../ivy-cache/repository/ch.qos.logback/com.springsource.ch.qos.logback.core/${ch.qos.logback}/com.springsource.ch.qos.logback.core-${ch.qos.logback}.jar,\ file:../ivy-cache/repository/ch.qos.logback/com.springsource.ch.qos.logback.classic/${ch.qos.logback}/com.springsource.ch.qos.logback.classic-${ch.qos.logback}.jar,\ These are typically added after the line: file:../ivy-cache/repository/org.eclipse.virgo.medic/org.eclipse.virgo.medic/${org.eclipse.virgo.medic}/org.eclipse.virgo.medic-${org.eclipse.virgo.medic}.jar@start,\ [1] http://wiki.eclipse.org/Virgo/Community/Migrating_from_3.0.x_to_3.5.0#Custom_Logback_Appenders
Fixed in the following medic commits (and some trivial commits in between) and various other commits in other repos. 7082838769497acfa825530b6d4b3d1b8f9e7fbf a80a6b1a5a5ee0c1496d1dc8be76801ceb780f61 7116d25aa8cc0c32c78149066a5b65c2c5001d8d Note that a80a6b1a5a5ee0c1496d1dc8be76801ceb780f61 sets the system property logback.ignoreTCL to true in medic core to prevent logback from attempting to load DelegatingContextSelector from the TCCL which in the kernel deployer tests, for example, includes medic core and give rise to obscure class loading errors. This will also help anyone launching Virgo who accidentally has medic core on their application classpath.
Note targetting 3.5.0.M02 since we probably missed the 3.5.0.M01 branch.
Moved some of the necessary configurations to the nano repo from where the medic bundles are inherited. Fixed that with commit 91475b6.
