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
