logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roland <...@ids.de>
Subject Re: [ANNOUNCEMENT] Apache Log4j 2.0-beta9 released
Date Fri, 27 Sep 2013 07:53:17 GMT
Hi Gary,
It is best practise to provide an implementation within a separate bundle
whereas the interface is provided by an other bundle. You can update or
replace the implementation at runtime without stopping the interface bundle.
This is called "hot update". But there are some reasons why an
implementation should be in the same bundle as the interface. For instance
if the "interface" needs to know which implementation is installed (e.g. if
you have to register some implementations to a proxy). In this case the
implementation has to be in the classpath of the interface bundle. The
interface can "see" the implementations if the packages are imported by the
bundle (BTW this is bad practise, because an interface should not know
anything about implementations and should not import them! This problem is
often solved with reflection.). But what about non java resources like some
settings or reflection files? They can not be imported. We can achieve this
with fragmented bundles. All resources of a fragment are in the classpath of
the host bundle at startup time. You do not need to parse resources within
bundles within subdirectories, which is very time consuming  because you
have to install and start all bundles before you can access them. With
fragmented bundles they are just there.


Gary Gregory-4 wrote
> [...]
> It's not clear to me that we have the OSGi architecture settles with the
> use of bundle fragments instead of plain bundles. It would be nice to have
> an explanation of what our options are...
> [...]

View this message in context: http://apache-logging.6191.n7.nabble.com/ANNOUNCEMENT-Apache-Log4j-2-0-beta9-released-tp40819p40910.html
Sent from the Log4j - Users mailing list archive at Nabble.com.

To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org

View raw message