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.
Regards Roland 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-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
