commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benedikt Ritter <brit...@apache.org>
Subject Re: svn commit: r1448251 - /commons/proper/logging/trunk/src/conf/MANIFEST.MF
Date Sat, 23 Feb 2013 16:53:03 GMT
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 <britter@apache.org>

>
>
>
> 2013/2/22 Thomas Neidhart <thomas.neidhart@gmail.com>
>
>> On 02/22/2013 08:17 PM, Benedikt Ritter wrote:
>> > 2013/2/22 Thomas Neidhart <thomas.neidhart@gmail.com>
>> >
>> >> On 02/22/2013 05:50 PM, Benedikt Ritter wrote:
>> >>> Hi Thomas,
>> >>>
>> >>>
>> >>> 2013/2/22 Thomas Neidhart <thomas.neidhart@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 tn@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-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message