Community
Participate
Working Groups
The zookeeper provider currently depends upon org.apache.log4j bundle, but this bundle is not included in the zookeeper feature: org.eclipse.ecf.discovery.zookeeper.feature This makes it more difficult to use the zookeeper feature in non-eclipse target platforms (i.e. target platforms that do not already include log4j), as it's then explicitly necessary to include org.apache.log4j bundle in order to install the zookeeper provider. There are several p2-based solutions possible I believe...I don't immediately know what the best one is, but it would be helpful to make things so that the org.apache.log4j bundle can be easily installed as part of zookeeper provider installation.
Adding wim, ahmed, and markus for comment/thoughts.
Setting target milestone to 3.5
*** Bug 335784 has been marked as a duplicate of this bug. ***
(In reply to comment #3) > *** Bug 335784 has been marked as a duplicate of this bug. *** Bug 335784 requires an independence on org.apache.log4j and this bug requires org.apache.log4j to be bundled in some form. How are they duplicates. @Ekke: would import package org.apache.log4j be enough? No other packages required to be imported? I wonder if we could make this an optional dependency. Let me ask the zookeeper guys what happens if there is no log4j available. This would also solve 335237.
(In reply to comment #4) > (In reply to comment #3) > > *** Bug 335784 has been marked as a duplicate of this bug. *** > > Bug 335784 requires an independence on org.apache.log4j and this bug requires > org.apache.log4j to be bundled in some form. How are they duplicates. > > > @Ekke: would import package org.apache.log4j be enough? No other packages > required to be imported? I wonder if we could make this an optional dependency. > Let me ask the zookeeper guys what happens if there is no log4j available. This > would also solve 335237. org.apache log4j should be enough per ex. you can use SLF4J where the bundle Log4JOverSLF4J then provides org.apache.log4j
(In reply to comment #4) > (In reply to comment #3) > > *** Bug 335784 has been marked as a duplicate of this bug. *** > > Bug 335784 requires an independence on org.apache.log4j and this bug requires > org.apache.log4j to be bundled in some form. How are they duplicates. I suppose they are not really duplicates...my mistake.
(In reply to comment #5) > (In reply to comment #4) > > (In reply to comment #3) > > > *** Bug 335784 has been marked as a duplicate of this bug. *** > > > > Bug 335784 requires an independence on org.apache.log4j and this bug requires > > org.apache.log4j to be bundled in some form. How are they duplicates. > > > > > > @Ekke: would import package org.apache.log4j be enough? No other packages > > required to be imported? I wonder if we could make this an optional dependency. > > Let me ask the zookeeper guys what happens if there is no log4j available. This > > would also solve 335237. > > org.apache log4j should be enough > > per ex. you can use SLF4J where the bundle Log4JOverSLF4J then provides > org.apache.log4j Ekke, due to the way log4j resolves its config file we need to register log4j as a buddy: Eclipse-RegisterBuddy: org.apache.log4j This will add zk plugin to the classpath of log4j even though log4j has no business with zk. Does this need to be the same for your logger or any other implementers of log4j? If so how do you suggest we handle them. Is there a list of log4j implementers available so that we can essentially add all of them to the buddy list. Scott, Markus. Can I apply the patches I made to ZK so that Hudson can run tests or do I need to work on getting the tests to run on my PC. My problem is that I work on another machine. I would need to
> that I work on another machine. I would need to setup my environment on the machine i carry with me.
(In reply to comment #8) > > that I work on another machine. I would need to > > setup my environment on the machine i carry with me. I'm ok with you checking in with your changes for this bug, as long as you are reasonably sure that it won't break the build. If we need to deal with test cases then we can do so over the next few days. This would probably be required anyway...given that the build/test network environment can be hard to duplicate. In any event...I'm in favor of you committing your changes for this bug...and we'll deal with any consequences WRT the build/test as they come up. I'm not sure if you are looking at it, but we probably need to coordinate wrt bug 335419. I'm nearly ready to commit these fixes, but I don't wish to do so without first merging with your changes with this bug, and verifying with someone with more familiarity with the zookeeper provider than myself that the changes aren't going to cause major problems.
> > Ekke, due to the way log4j resolves its config file we need to register log4j > as a buddy: > > Eclipse-RegisterBuddy: org.apache.log4j > > This will add zk plugin to the classpath of log4j even though log4j has no > business with zk. > > Does this need to be the same for your logger or any other implementers of > log4j? if there's still a required bundle entry then it won't work if there's no required bundle it's fine have you run your unit tests if they run using package import only ? If so how do you suggest we handle them. Is there a list of log4j > implementers available so that we can essentially add all of them to the buddy > list. > no - there's no such list there are so many implementations: SLF4J, PAX Logging and much much more there were some eclipse projects with hard coded dependencies (require bundle) to log4j or commons logging - and all switched to package import and it works
Hi, In this conversation Patrick Hunt states that ZK needs a log4j implementation. If we loosen our requirement to the package to optional, it could mean that ZD would fail if there was no implementation. Now two bugs got mixed a bit: Ekke: You are just fine with a required dependency on log4j package, right? Scott: You say, if there is a required dependency then zd might not install so we should package a log4j implementation, right? How to fix this? Correct - the JVM will exit if it can't find the log4j implementation. Patrick - Hide quoted text - On Tue, Feb 1, 2011 at 9:25 AM, Wim Jongman <wim.jongman@gmail.com> wrote: > Hi Guys, > > Just a quick question: will ZK fail if it is run without a log4j > implementation on the classpath? > > Best regards, > Wim Jongman > > Eclipse Communication Project >
(In reply to comment #11) <stuff deleted> > Scott: You say, if there is a required dependency then zd might not install so > we should package a log4j implementation, right? Yes, that's my suggestion. The reason is that otherwise we will continually get complaints about the ECF target components not being installable (because log4j dependency can't be satisfied)...and of course people will blame that on us. See Ekke on that. So IMHO we should include log4j implementation in our repository, so that people will be able to easily install zd into an arbitrary target platform (Eclipse, Equinox server, Felix server, etc)...without having to manually fuss with resolving the Apache zoodiscovery deps (log4j).
(In reply to comment #11) > ... > > Ekke: You are just fine with a required dependency on log4j package, right? yes
(In reply to comment #13) > (In reply to comment #11) > > ... > > > > Ekke: You are just fine with a required dependency on log4j package, right? > yes And you are also fine that we bundle org.apache.log4j with zookeeper?
(In reply to comment #14) > (In reply to comment #13) > > (In reply to comment #11) > > > ... > > > > > > Ekke: You are just fine with a required dependency on log4j package, right? > > yes > > And you are also fine that we bundle org.apache.log4j with zookeeper? if you import and export the log4j package this should work
> > > > And you are also fine that we bundle org.apache.log4j with zookeeper? > > if you import and export the log4j package this should work I'm not sure what you mean by that. Can you elaborate.
(In reply to comment #16) > > > > > > And you are also fine that we bundle org.apache.log4j with zookeeper? > > > > if you import and export the log4j package this should work > > I'm not sure what you mean by that. Can you elaborate. if I understood right: you want to bundle a PlugIn providing log4j, so I expect that this bundle will export log4j package and the zookeeper will import the same. then it would be great if this bundle not only exports the package but also imports the same package log4j. now if there will be another bundle like SLF4J PAXLogging etc already exporting log4j package and its started with a lower start-level then OSGI Framework will choose this and not the origin log4j --- or - if I misunderstood you and you only want to include the unchanged log4j bundle with your distribution, then it would be good if this bundle would be placed in an extra Feature, because then someone using other log4j - providers can exclude this logging-dependency-feature in TargetPlatform definition
Hi Ekke, If I include org.apache.log4j from orbit, will the importing/exporting work?
(In reply to comment #18) > Hi Ekke, > > If I include org.apache.log4j from orbit, will the importing/exporting work? Hi Wim, most important is that the dependencies to the bundle are via package import and not required bundle. then its ok. if using another bundle implementing log4j I can choose this plugin from launch config. ekke
Changes pushed to master: updated ecf.rmap and ecf.b3aggr added zookeeper from orbit to zk feature added org.apache.log4j to zk feature change require bundle to import package (however this change was nullified by using the zookeeper bundle from orbit) mylyn context attached
Created attachment 189064 [details] mylyn/context/zip
Closing
