zookeeper-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From GitBox <...@apache.org>
Subject [GitHub] [zookeeper] JiriOndrusek commented on issue #945: [ZOOKEEPER-3389] Zookeeper does not export all required packages in OSGi (needed for curator)
Date Wed, 15 May 2019 19:43:37 GMT
JiriOndrusek commented on issue #945: [ZOOKEEPER-3389] Zookeeper does not export all required
packages in OSGi (needed for curator)
URL: https://github.com/apache/zookeeper/pull/945#issuecomment-492796520
   Hi @nkalmar @eolivelli,
   let me introduce "a better solution" for the problem with  same package's names of zookeeper-jute
and zookeeper-server.
   If I understand it correctly, maven way of solving this problem is acceptable even if it
causes problems sometimes. From previous comment - "It's not ideal, and even causes problems
like this one with OSGi." Maven solution is that in case that packages DOESN'T contain the
same classes - it works as EXPECTED. If it contains the same classes, then classloader return
class from jar based on ORDER of jars. (so even if I want clas from jute, I can get class
from server) Which is typicalli zookeeper-server and then zookeeper-jute (as jute is dependency
from server)
   I propose to use OSGi merge capability, which brings the same behavior. If someone wants
class from that shared package, in case that classes are differen in both jars, this merge
"feature" will behave as expected and correct class is returned. In case that there are overlapping
classes, we define, which jar has advantage. (so I'd say that zookeeper-server has advantage).
IMHO behavior  will be a little bit better then in maven, because it will behave always in
the same way. (In reality it won't robabnly happen, because the same classes in the shared
packages will probably cause problems elsewhere, so everyone will try to avoid that)
   In other words - behavior of OSGI with merge will be the same as maven if packages contains
different classes. If in the future there will be the overlapping classes, behavior in OSGi
would be defined (in contrast with maven, where it would ddepend on order of jar loading -
so almost "random")
   Possibly (I'm not sure about it in this time) I can also try to add some insurance/condition,
that it will work for 3.5.x only. I mean that after upgrading to higher version of zookeeper,
it will cause error during build (or at least warning), so someone will look into it and will
find a comment explaining, that correct solution is to rename packages -> which is the
correct solution. In case that packages won't be renamed at that time. This condition would
allow us to solve problem in 3.5.x time, where packages couldn't be renamed.
   Just to avoid confusion, this merge capability only defines, how OSGi returns classes if
the class is in package, which is shared in more jars. No actuall merging of compiled classes
is not happening.

This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:

With regards,
Apache Git Services

View raw message