David Bosschaert updated ZOOKEEPER-425:
The attached patch (named zk_patch3.patch) implements some of the
functionality. Its not fully finished yet, I'm attaching it at this point to
get some feedback.
* Adds the OSGi Metadata to the MANIFEST.MF
* Can be used as just a library bundle if you want to write a zookeeper client
in another OSGi bundle.
* Can be used to run the zookeeper server. To do this the server has to be
configured. Configuration is handled through the OSGi Configuration Admin
service. The bundle has an optional dependency on this service and registers an
org.osgi.service.cm.ManagedService service to be configured by CM. The PID for
this service is org.apache.zookeeper and all of the configuration variables are
the same as in the non-OSGi zoo.cfg file (it uses the same ServerConfig class
to handle them).
All configuration properties have defaults provided, except for the
'clientPort' one, which has to be provided through Config Admin. For the data
directory the OSGi Bundle-private storage directory is used by default.
* The jar has an OSGi BundleActivator class, which will be triggered if run on
an OSGi framework.
* BTW the zookeeper.jar stil also works as a POJ (plain old Jar ;)
note that I updated the ivy.xml file to pull in two OSGi jars that are needed
at build time. However they don't need to be redistributed with the zookeeper
jar as they are provided by the OSGi framework.
There are still a few open questions that I have:
* In OSGi things should really be (re)configurable at runtime. This means that
the Configuration Admin Service may call your ManagedService.updated() callback
with changed properties at any time. I guess the easiest (but not necessarily
the most elegant) way to handle this is by taking down the ZooKeeperServerMain
and relaunching it with the modified properties. ZooKeeperServerMain has a
shutdown() method that I could use for this. Would that be the best idea?
* I'm not (yet) familiar with the cluster setup and am wondering whether the
configuration approach that I took also works in that case.
I also intend to provide some unit tests before closing this off.
BTW I haven't gone into detail how the OSGi Configuration Admin service
typically works. Let me know if I need to provide more info on that.
> Add OSGi metadata to zookeeper.jar
> Key: ZOOKEEPER-425
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-425
> Project: Zookeeper
> Issue Type: Improvement
> Components: build
> Affects Versions: 3.1.1
> Reporter: David Bosschaert
> Attachments: MANIFEST.MF, zk_patch3.patch
> After adding OSGi metadata to zookeeper.jar it can be used as both an OSGi
> bundle as well as an ordinary jar file.
> In the CXF/DOSGi project the buildsystem does this using the
> The MANIFEST.MF generated by maven-bundle-plugin is attached to this bug,
> this works for the CXF/DOSGi project.
> If your buildsystem isn't using maven, I would advise to use bnd
> (http://www.aqute.biz/Code/Bnd). BND defines its own ant task in which you
> should be able to use more or less the same instructions as were used in
> <Bundle-Name>ZooKeeper bundle</Bundle-Name>
> <Bundle-Description>This bundle contains the ZooKeeper
> Oh and one other thing. Is it really necessary to put the source code in the
> Jar file too? I would put that in a separate source distribution :)
> See also:
This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.