Christian Schneider from the felix project has posted some useful information to the felix dev ML [1]. Maybe we should just add document for using JCL in OSGi (via pax logging for example) to the website?
Benedikt [1] http://www.mail-archive.com/dev%40felix.apache.org/msg28887.html 2013/2/22 Benedikt Ritter <brit...@apache.org> > > > > 2013/2/22 Thomas Neidhart <thomas.neidh...@gmail.com> > >> On 02/22/2013 08:17 PM, Benedikt Ritter wrote: >> > 2013/2/22 Thomas Neidhart <thomas.neidh...@gmail.com> >> > >> >> On 02/22/2013 05:50 PM, Benedikt Ritter wrote: >> >>> Hi Thomas, >> >>> >> >>> >> >>> 2013/2/22 Thomas Neidhart <thomas.neidh...@gmail.com> >> >>> >> >>>> On 02/22/2013 05:35 PM, Thomas Neidhart wrote: >> >>>>> On 02/22/2013 05:09 PM, Thomas Neidhart wrote: >> >>>>>> On 02/20/2013 09:48 PM, Jörg Schaible wrote: >> >>>>>>> Hi Thomas, >> >>>>>>> >> >>>>>>> Thomas Neidhart wrote: >> >>>>>>> >> >>>>>>>> On 02/20/2013 09:33 PM, Oliver Heger wrote: >> >>>>>>>>> Am 20.02.2013 16:42, schrieb t...@apache.org: >> >>>>>>>>>> Author: tn >> >>>>>>>>>> Date: Wed Feb 20 15:42:09 2013 >> >>>>>>>>>> New Revision: 1448251 >> >>>>>>>>>> >> >>>>>>>>>> URL: http://svn.apache.org/r1448251 >> >>>>>>>>>> Log: >> >>>>>>>>>> Update version info >> >>>>>>>>>> >> >>>>>>>>>> Modified: >> >>>>>>>>>> commons/proper/logging/trunk/src/conf/MANIFEST.MF >> >>>>>>>>>> >> >>>>>>>>>> Modified: commons/proper/logging/trunk/src/conf/MANIFEST.MF >> >>>>>>>>>> URL: >> >>>>>>>>>> >> >>>>>>> >> >>>> >> >> >> http://svn.apache.org/viewvc/commons/proper/logging/trunk/src/conf/MANIFEST.MF?rev=1448251&r1=1448250&r2=1448251&view=diff >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>> >> >>>> >> >> >> ============================================================================== >> >>>>>>>>>> >> >>>>>>>>>> --- commons/proper/logging/trunk/src/conf/MANIFEST.MF >> (original) >> >>>>>>>>>> +++ commons/proper/logging/trunk/src/conf/MANIFEST.MF Wed Feb >> 20 >> >>>>>>>>>> 15:42:09 2013 >> >>>>>>>>>> @@ -5,4 +5,4 @@ Specification-Version: 1.0 >> >>>>>>>>>> Implementation-Title: Commons Logging >> >>>>>>>>>> Implementation-Vendor-Id: org.apache >> >>>>>>>>>> Implementation-Vendor: Apache Software Foundation >> >>>>>>>>>> -Implementation-Version: 1.1.1 >> >>>>>>>>>> +Implementation-Version: 1.1.2 >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>> Just wondering whether this is necessary. Doesn't the maven >> build >> >>>>>>>>> automatically generate a fully configured MANIFEST including >> OSGi >> >>>> meta >> >>>>>>>>> data? >> >>>>>>> >> >>>>>>> wondered about exactly the same. >> >>>>>>> >> >>>>>>>> >> >>>>>>>> yes, but somehow the ant build script is still in use (e.g. for >> >> gump) >> >>>>>>>> and both ant & maven refer to this hard-coded manifest. >> >>>>>>> >> >>>>>>> If Gump uses Ant here, this is just for historical reasons. Gump >> can >> >>>> use >> >>>>>>> Maven since quite some time now. >> >>>>>> >> >>>>>> Ok, when I try to remove the hard-coded manifest, the >> >>>>>> maven-bundle-plugin steps in and automatically creates one. >> >>>>>> >> >>>>>> This is fine, but the Import-Package contains all (optional) >> >>>>>> dependencies which are not marked like that. >> >>>>>> >> >>>>>> I am not so familiar with these things, does somebody know how to >> >>>>>> specify this? >> >>>>>> >> >>>>>> Or would this not work at all, as already outlined in LOGGING-124? >> >>>>> >> >>>>> After some research, I started with this: >> >>>>> >> >>>>> <plugin> >> >>>>> <groupId>org.apache.felix</groupId> >> >>>>> <artifactId>maven-bundle-plugin</artifactId> >> >>>>> <inherited>true</inherited> >> >>>>> <configuration> >> >>>>> <instructions> >> >>>>> <Import-Package>*;resolution:=optional</Import-Package> >> >>>>> <DynamicImport-Package>*</DynamicImport-Package> >> >>>>> </instructions> >> >>>>> </configuration> >> >>>>> </plugin> >> >>>>> >> >>>>> All dependencies are optional, so this should be fine. >> >>>>> I added the DynamicImport but this may be to generic, and has to be >> >>>>> limited to the actual packages that are loaded dynamically by the >> >>>>> discovery process. >> >>>>> >> >>>>> Can anybody provide me with a simple test bundle to see if logging >> >> would >> >>>>> work when loaded in e.g. apache felix? >> >>>> >> >>>> Well, I have not yet a clue about osgi, and I see that felix has >> >>>> re-bundled commons-logging in a total different way: >> >>>> >> >>>> >> >> >> http://svn.apache.org/repos/asf/felix/trunk/commons/commons-logging/pom.xml >> >>> >> >>> >> >>> I have some experience with osgi (although I'm no expert either ;-). I >> >> can >> >>> have a look tonight when I'm at home. We can also ask the felix ML. >> They >> >>> have been supportive with OSGi meta data. >> >> >> >> ok thanks, >> >> >> >> another thing I have found as comment in LOGGING-124: >> >> >> >> Spring seems to rebundle commons-logging with proper meta data. >> >> >> >> see >> >> >> >> >> http://www.springsource.com/repository/app/bundle/version/detail?name=com.springsource.org.apache.commons.logging&version=1.1.1&searchType=bundlesByName&searchQuery=logging >> >> >> >> Using these settings from their manifest into our pom: >> >> >> >> <commons.osgi.import> >> >> javax.servlet;version="[2.1.0, 3.0.0)";resolution:=optional, >> >> org.apache.avalon.framework.logger;version="[4.1.3, >> >> 4.1.5]";resolution:=optional, >> >> org.apache.log;version="[1.0.1, 1.0.1]";resolution:=optional, >> >> org.apache.log4j;version="[1.2.15, 2.0.0)";resolution:=optional >> >> </commons.osgi.import> >> >> >> >> Does anybody have experience with using this spring bundle and whether >> >> this works? >> >> >> >> Reading all theses (negative) threads about osgi and commons-logging >> >> makes me wonder if this is really still valid with version 1.1+? >> >> >> >> Lots of things have changed, and there are several bundles of >> >> commons-logging from other sources (spring, felix), so I guess it will >> >> work? >> >> >> >> >> > I'm at home now and have started logging through the build config. >> > There are a few things about OSGi that one should know. >> > OSGi defines special meta data for bundles that allow an OSGi framework >> to >> > start a bundle in different versions. This means, that the class >> > com.example.MyClass can be loaded several times in an OSGi framework by >> > different class loaders. >> > For this to work there are some requirements: >> > - Bundles have to define a versionin a well defined form (called >> semantic >> > versioning [1,2]) >> > - Bundles have to tell the OSGi framework what they provide for other >> > bundles (this is what can be expressed in the bundle Export-Package >> header) >> > - Bundles have to tell the OSGi framework what they need to be resolved >> > (this is what can be expressed in the bundle Import-Package header) >> > >> > Now looking at what you have posted so far I can see that: >> > >> > Without changes to trunk: >> > - the version number looks valid although. I'm not sure about the >> > ".SNAPSHOT" part, but this will be snipped for the release. >> > - we will export the impl package. There is no need to export this >> package >> > as it is internal. Users should always use the interfaces defined in >> > o.a.c.logging (right?). Not exporting this package means, that no other >> > bundle can use for example o.a.c.l.impl.AvalonLogger directly. >> > - we import everthing we have defined a import in one of our classes. >> This >> > means that even if a user decides to use [logging] together with Log4J >> he >> > will have to provide javax.servlet, avalon, o.a.log and o.a.log4j >> > >> > With the configuration you proposed for [logging] >> > - we have defined a DynamicImport [3]. I don't think this is necessary, >> > because we know what optional dependecies we have. >> > - we still export the impl package >> > - we have marked all imports as optional (I think this is correct) >> > >> > What is missing: >> > - I think we should add version info to our imports like spring does >> > >> > Thinks I unsure about: >> > - do we have to export the impl package? Spring does this. Looks like >> they >> > do this to define that thie package is using the optinonal dependencies. >> >> I updated the pom with the bundle data I posted before (should also be >> available from snapshot repository). >> > > The generated MANIFEST looks better. I still wonder if we have to export > the impl package. Users should never use Log implementations directly, > right? So there is no need to export the impl package, I guess. > > I'm wondering if we get problems with all the classloader and > Class.forName stuff LogFactory and LogFactoryImpl do... Because there is no > flat classpath that contains all classes in OSGi, it is not recommended to > use this facilities in an OSGi environment. > > For example: if a bundle contains a commons-logging.properties can the > [logging] bundle classloader discover this resource? Maybe you can add a > properties file to your example bundle and test this. > > >> >> I did a very simple test with it: >> >> * create an example that uses commons-logging as log device >> * install apache felix >> * install the commons-logging bundle >> * install my example bundle >> * start the example bundle -> logging works >> >> so it seems to work, although this was just a very simple example. >> >> Maybe other people can do more tests? >> >> btw. I had to add a definition for the fulljar to the maven-jar-plugin, >> as otherwise the last definition there was used to deploy the project jar: >> >> * before adaptersjar was the last definition >> * the adapters jar was used to deploy the project jar, see output >> below: >> >> [INFO] Installing >> >> /home/tn/workspace/apache/logging/target/commons-logging-adapters-1.1.2-SNAPSHOT.jar >> to >> >> /home/tn/.m2/repository/commons-logging/commons-logging/1.1.2-SNAPSHOT/commons-logging-1.1.2-SNAPSHOT.jar >> >> Weird. >> >> Thomas >> > >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > > > -- > http://people.apache.org/~britter/ > http://www.systemoutprintln.de/ > http://twitter.com/BenediktRitter > http://github.com/britter > -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter
