log4j companions

[Curt Arnold <ca...@apache.org>]

There are several features from the discontinued log4j 1.3 development  
that have been backported to work with log4j 1.2 and have been  
packaged (along with some new features) as "companions" to log4j 1.2  
which are packaged and released independently of log4j.  Several of  
these companions introduce new classes into packages that are provided  
by log4j 1.2.x.  For example, the extras companion adds an  
org.apache.log4j.EnhancedPatternLayout class to the org.apache.log4j  
package from log4j 1.2.

My understanding is having a package split between bundles is not  
supported by OSGi, so I was thinking about introducing an OSGi  
friendly class in addition to the original class needed for  
compatibility with earlier applications.  For example, the  
EnhancedPatternLayout could be accessed as either  
org.apache.log4j.EnhancedPatternLayout or  
org.apache.log4j.extras.EnhancedPatternLayout where only the  
org.apache.log4j.extras package was exported by the extras companion.   
Is that approach necessary or valid and if so should  
org.apache.log4j.extras.EnhancedPatternLayout extend  
org.apache.log4j.EnhancedPatternLayout or vice-versa?

Can a companion use a non-exported class from its jar in a package  
exported by log4j or will the import that package from log4j cause the  
non-exported local class to not resolve?

Anything else that needs to be considered?

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org

Re: log4j companions

[Stuart McCulloch <st...@jayway.net>]

2008/8/19 Curt Arnold <ca...@apache.org>

> There are several features from the discontinued log4j 1.3 development that
> have been backported to work with log4j 1.2 and have been packaged (along
> with some new features) as "companions" to log4j 1.2 which are packaged and
> released independently of log4j.  Several of these companions introduce new
> classes into packages that are provided by log4j 1.2.x.  For example, the
> extras companion adds an org.apache.log4j.EnhancedPatternLayout class to the
> org.apache.log4j package from log4j 1.2.
>
> My understanding is having a package split between bundles is not supported
> by OSGi,


Actually OSGi does support packages split between bundles - it's just not
recommended.
See section 3.13 of the core specs (pages 65-68) for how to get
split-packages working.
However, you do need to have control over both bundle manifests to add the
necessary
mandatory attributes and Require-Bundle headers to wire up the combined
contents.

For example, one possible solution is to have the following in the Log4J
bundle:

   Require-Bundle:
org.apache.log4j.companions;visibility:=reexport;resolution:=optional
   Export-Package: org.apache.log4j, ...etc...

and the following in the companion bundle, say
"org.apache.log4j.companions":

   Export-Package: org.apache.log4j;partial=true;mandatory:=partial

(warning: I just typed this out quickly, haven't actually tried it ;)

so I was thinking about introducing an OSGi friendly class in addition to
> the original class needed for compatibility with earlier applications.  For
> example, the EnhancedPatternLayout could be accessed as either
> org.apache.log4j.EnhancedPatternLayout or
> org.apache.log4j.extras.EnhancedPatternLayout where only the
> org.apache.log4j.extras package was exported by the extras companion.  Is
> that approach necessary or valid and if so should
> org.apache.log4j.extras.EnhancedPatternLayout extend
> org.apache.log4j.EnhancedPatternLayout or vice-versa?
>

things to consider: overhead of maintaining these 2 class locations, and
potential
developer confusion of having the same class available from different
packages.

Can a companion use a non-exported class from its jar in a package exported
> by log4j or will the import that package from log4j cause the non-exported
> local class to not resolve?
>
> Anything else that needs to be considered?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>


-- 
Cheers, Stuart