Re: [VOTE] Release Apache Sling JSP Taglib version 2.2.0
In case it's unclear: I meant +1 for the release :) 2013/8/5 Carsten Ziegeler > +1 > > For keys file, it seems https://people.apache.org/keys/group/sling.asc is > the new place. I guess we should add a redirect from dist/sling/KEYS to > that location and update our downloads pae > > Carsten > > > 2013/8/4 Justin Edelson > >> +1 >> >> I did note, however, that http://sling.apache.org/downloads.cgi points >> to a >> GPG keys file which does not contain the current GPG keys. Are we sure >> that >> https://people.apache.org/keys/group/sling.asc is the correct new >> location? >> If so, the downloads page should be updated. >> >> Regards, >> Justin >> >> On Fri, Aug 2, 2013 at 4:07 PM, Daniel Klco wrote: >> >> > Hi, >> > >> > This vote is to release some useful new functionality for the Sling JSP >> > Taglibs. >> > >> > We solved 7 issues in this release: >> > https://issues.apache.org/jira/browse/SLING/fixforversion/12323463 >> > >> > Staging repository: >> > https://repository.apache.org/content/repositories/orgapachesling-054/ >> > >> > You can use this UNIX script to download the release and verify the >> > signatures: >> > http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh >> > >> > Usage: >> > sh check_staged_release.sh 054 /tmp/sling-staging >> > >> > Please vote to approve this release: >> > >> > [ ] +1 Approve the release >> > [ ] 0 Don't care >> > [ ] -1 Don't release, because ... >> > >> > This vote will be open for 96 hours. >> > >> > > > > -- > Carsten Ziegeler > cziege...@apache.org > -- Carsten Ziegeler cziege...@apache.org
Re: [VOTE] Release Apache Sling JSP Taglib version 2.2.0
+1 For keys file, it seems https://people.apache.org/keys/group/sling.asc is the new place. I guess we should add a redirect from dist/sling/KEYS to that location and update our downloads pae Carsten 2013/8/4 Justin Edelson > +1 > > I did note, however, that http://sling.apache.org/downloads.cgi points to > a > GPG keys file which does not contain the current GPG keys. Are we sure that > https://people.apache.org/keys/group/sling.asc is the correct new > location? > If so, the downloads page should be updated. > > Regards, > Justin > > On Fri, Aug 2, 2013 at 4:07 PM, Daniel Klco wrote: > > > Hi, > > > > This vote is to release some useful new functionality for the Sling JSP > > Taglibs. > > > > We solved 7 issues in this release: > > https://issues.apache.org/jira/browse/SLING/fixforversion/12323463 > > > > Staging repository: > > https://repository.apache.org/content/repositories/orgapachesling-054/ > > > > You can use this UNIX script to download the release and verify the > > signatures: > > http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh > > > > Usage: > > sh check_staged_release.sh 054 /tmp/sling-staging > > > > Please vote to approve this release: > > > > [ ] +1 Approve the release > > [ ] 0 Don't care > > [ ] -1 Don't release, because ... > > > > This vote will be open for 96 hours. > > > -- Carsten Ziegeler cziege...@apache.org
Re: Exposing RequestProgressTracker as ThreadLocal
I'm not 100% sure if this is a good thing; the resource resolver can be used without a request, the resource api is not tied to to request/response handling, so with this you add a dependency between resource providers and the Sling engine. At the bare minimum, before using the tracker you would need to check whether it is available. If we would do this, we don't need an additional filter, the Sling engine could do this internally. As this is about resource resolving and finding out what's going on there, I'm wondering if a separate tracker for this would make sense and then finding a way to attach it's output the the request progress tracker. But maybe defining a log category for this is all we need? Regards Carsten 2013/8/5 Chetan Mehrotra > Hi, > > Sling RequestProgressTracker is a valuable feature which helps in > understanding the request flow easily. I tried using it for logging > calls made to MongoDB server for a given thread [1] and it gives a > very good insight in what is happening. As such component do not have > direct access to the RequestProgressTracker or ResourceResolver > associated with current request I had to expose it via ThreadLocal. > > It would be helpful if we can have a Sling Filter and API which > exposes the current thread's RequestProgressTracker (or better > ResourceResolver!!). Such API would allow creating debugging > components which can say track JCR session operations performed in a > given request. > > Thoughts? I can create a patch if people consider it as a good thing > to have as part of Sling. > > [1] https://github.com/chetanmeh/mongo-sling-tracer > > Chetan Mehrotra > -- Carsten Ziegeler cziege...@apache.org
Clarification of RequestProgressTracker#done()
The javadocs of RequestProgressTrackr#done state: "/** * Call this when done processing the request - all calls except the first * one are ignored */ void done(); " I'm wondering what is ment with "the first one"? In addition, looking at the implementation in the Sling engine, though it has a done flag, this flag is not evaluated in most methods. I would expect that after a call to done() only dump is possible and all calls to log etc. are ignored. Is that the intention? Regards Carsten -- Carsten Ziegeler cziege...@apache.org
Re: Clarification of RequestProgressTracker#done()
Ah, so "all calls except the first one" means all calls to the "done" method, yes, thanks. I guess I was reading too much into the comment :) And the implementation fits that comment nicely. Thanks Carsten 2013/8/5 Bertrand Delacretaz > Hi, > > On Mon, Aug 5, 2013 at 9:12 AM, Carsten Ziegeler > wrote: > > The javadocs of RequestProgressTrackr#done state: > > ...Call this when done processing the request - all calls except the > > first one are ignored... > > > ...I would expect that after a call to done() only dump is possible and > all > > calls to log etc. are ignored. Is that the intention?... > > I have vague memories of writing that comment long ago, your > interpretation sounds right but in retrospect I'm not sure if that's > really useful. Maybe just to get the duration of the current request? > In which case multiple calls to done() do not matter, it would be only > the last one that's relevant. > > -Bertrand > -- Carsten Ziegeler cziege...@apache.org
Re: Exposing RequestProgressTracker as ThreadLocal
2013/8/5 Bertrand Delacretaz > Yes, that's long overdue IMO, I could make good use of this for the > health check tool as well. > > We discussed this a few times already, and IIRC the conclusion was > that we should get rid of our custom logging implementation in favor > of logback (see [0] for example). The difficulty might be our custom > configuration mechanisms, which need to stay but might not have > currently enough test coverage to be replaced with confidence, so that > needs work. > > Yepp, right I was wondering where we are with [0] as well as I could make use of it :) Carsten > -Bertrand > > [0] http://markmail.org/message/etcayimn6ili3edr > -- Carsten Ziegeler cziege...@apache.org
Re: Exposing RequestProgressTracker as ThreadLocal
Yes, but why reinventing the wheel than rather do the right thing ?: ) Carsten 2013/8/5 Chetan Mehrotra > Well adding LogBack support might require more effort. What about > adding a Listener API and adding support for that in current logic. > That might be easier to add :) > > Chetan Mehrotra > > > On Mon, Aug 5, 2013 at 1:43 PM, Bertrand Delacretaz > wrote: > > On Mon, Aug 5, 2013 at 10:03 AM, Carsten Ziegeler > wrote: > >>> ...I was wondering where we are with [0] as well as I could make > >> use of it :) > > > > We're probably just missing a volunteer ;-) > > > > -Bertrand > > > >>> [0] http://markmail.org/message/etcayimn6ili3edr > -- Carsten Ziegeler cziege...@apache.org
Re: [VOTE] Release Apache Sling JCR Jackrabbit Server 2.1.2
+1 Carsten 2013/8/5 Felix Meschberger > +1 > > Regards > Felix > > Am 05.08.2013 um 14:47 schrieb Felix Meschberger: > > > Hi, > > > > This vote is to release the Apache Sling JCR Jackrabbit Server 2.1.2 > > bundle. > > > > We solved 10 issues in this release: > > https://issues.apache.org/jira/browse/SLING/fixforversion/12315318 > > > > Staging repository: > > https://repository.apache.org/content/repositories/orgapachesling-061/ > > > > You can use this UNIX script to download the release and verify the > > signatures: > > http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh > > > > Usage: > > sh check_staged_release.sh 061 /tmp/sling-staging > > > > Please vote to approve this release: > > > > [ ] +1 Approve the release > > [ ] 0 Don't care > > [ ] -1 Don't release, because ... > > > > This vote will be open for 72 hours. > > > > Regards > > Felix > > -- Carsten Ziegeler cziege...@apache.org
Re: [DISCUSS] Consider implementors of Sling API
In general I'm fine with this, however as Justin noted adding "final "to some of the classes might break clients of Sling. Marking an interface as ConsumerType means also we shouldn't change it, right? (i'm fine with that, just clarifying) Carsten 2013/8/5 Felix Meschberger > Hi > > Am 05.08.2013 um 19:48 schrieb Justin Edelson: > > > Hi Felix, > > +1 to all of this. > > > > Out of curiosity, would adding the final keyword require a major version > > bump? It isn't backwards compatible, but is perhaps an interesting grey > > area. > > Yes, technically, this is binary incompatible because existing extensions > will fail to load. > > An option would be to omit the final qualifier but add JavaDoc indicating > extension is not intended. > > Regards > Felix > > > > > Justin > > > > On Mon, Aug 5, 2013 at 11:04 AM, Felix Meschberger >wrote: > > > >> Hi all > >> > >> While working on SLING-2944 [1] it occurred to me that we do not > currently > >> take good care to differentiate between interfaces to be implemented by > a > >> single bundle (such as SlingHttpServletRequest) and interfaces which > may be > >> implemented by multiple bundles to extend some functionality (such as > >> ResourceProvider). > >> > >> Also, we have a number of constant, helper, and utility type classes in > >> the Sling API, which we should not make available to extensibility. > >> > >> I have created SLING-2993 [2] and provided a patch to the Sling API such > >> that: > >> > >> * All classes intended for extension remain unchanged > >> * All classes not intended for extension are marked final > >> * All interfaces intended to be implemented by multiple bundles > >> (providers) are marked @ConsumerType > >> * All interfaces intended to be implemented by a single bundle are > marked > >> as @ProviderType > >> > >> This change also requires to update the Maven Bundle Plugin version in > the > >> Sling parent POM to 2.4.0. > >> > >> This change would prevent us from collateral damage such in the context > of > >> SLING-2944 where the Servlet Resolver, Filesystem Resource Provider, and > >> Bundle Resource Provider bundles have to be updated just because the > >> ResourceResolverFactory API has been extended. > >> > >> WDYT ? > >> > >> Regards > >> Felix > >> > >> [1] https://issues.apache.org/jira/browse/SLING-2944 > >> [2] https://issues.apache.org/jira/browse/SLING-2993 > > -- Carsten Ziegeler cziege...@apache.org
[RT] Logging and Logback
Hi, i've the need for a custom log append not logging into a file. This is something our current logging bundles do not support. By looking around using logback could be an answer and I also found [1] where moving to logback has already been discussed. So I'm wondering what/how to this. One solution would be to do this on our own as discussed in that thread, another solution would be to leverage other logging solutions like maybe pax logging and just providing a compatibility layer for our current configurations. WDYT? Regards Carsten [1] http://apache-sling.73963.n3.nabble.com/Trying-to-convert-Sling-Logging-gt-Logback-How-much-backwards-compatibility-do-we-need-td4020965.html -- Carsten Ziegeler cziege...@apache.org
Re: Adding a "usage" service property to BindingsValuesProvider ?
I'm not sure if I understand this 100% - from a scripting pov, how could I set the usage value, let's say in a JSP (or any other script)? Carsten 2013/8/6 Bertrand Delacretaz > Hi, > > I'd like to use BindingsValuesProvider services in my health check > module, to provide bindings like "jmx" for scripted health checks, > which should be ignored for general Sling scripting (or not - some > providers might apply to both general scripting and health checks). > > I'm thinking of adding an optional "usage" service property to > BindingsValuesProvider services, does anyone see a problem with that? > > The Sling script engine would then consider only > BindingsValuesProvider which have no usage property (for backwards > compatibility) or which have usage=scripting. > > And my health checks would consider only BindingsValuesProvider which > have usage=healthcheck. > > -Bertrand > -- Carsten Ziegeler cziege...@apache.org
Re: Adding a "usage" service property to BindingsValuesProvider ?
I guess this only works as you have a special script engine for health
check, right?
What if people want to use the same functionality if they write lets say
workflow scripts or wcm scripts etc?
As long as there is no way to make use of this in every script engine, I
don't see the point of adding it. It's a special requirement for hc, so it
should have a hc solution.
Carsten
2013/8/6 Bertrand Delacretaz
> On Tue, Aug 6, 2013 at 5:13 PM, Carsten Ziegeler
> wrote:
> > I'm not sure if I understand this 100% - from a scripting pov, how could
> I
> > set the usage value, let's say in a JSP (or any other script)?
>
> You set the usage property when you create a BindingsValuesProvider,
> so for my jmx example I'd do:
>
> @Service
> @Property(name="usage", value="healthcheck")
> public class BindingsValuesProvider {
> public void addBindings(Bindings b) {
> b.put("jmx", new SomeObjectThatsSeenAsJmxFromHealthCheckScripts());
> }
> }
>
> that "jmx" object is then available in health check scripts, but not
> in general Sling rendering scripts.
>
> -Bertrand
>
--
Carsten Ziegeler
cziege...@apache.org
Re: Adding a "usage" service property to BindingsValuesProvider ?
I think if we would be in the jsp world, you would do a taglib for this - of course taglibs are not usable within other scripting languages - so depending on your script language you would have to come up with the equivalent. Taglibs in JSP allow exactly what you want - the BVP is more a way to make objects always available to all script engines; so apart from adding the optional node and session objects, we don't use this in Sling at all... Carsten 2013/8/6 Bertrand Delacretaz > On Tue, Aug 6, 2013 at 5:39 PM, Carsten Ziegeler > wrote: > > I guess this only works as you have a special script engine for health > > check, right? > > Not really a special script engine, but I'm using the > ScriptEngineManager directly instead of going through SlingScript. > > See code at [1] where bindings are hardcoded for now - I could invent > my own bindings providers interface but as we already have one why not > reuse it? > > > > > What if people want to use the same functionality if they write lets say > > workflow scripts or wcm scripts etc? > > The bindings service could be marked with > usage=healthcheck,workflow,wcm, or the consumers could be configured > to use bindings which are marked with usage=healthcheck. > > > As long as there is no way to make use of this in every script engine, I > > don't see the point of adding it. It's a special requirement for hc, so > it > > should have a hc solution. > > That's an option of course, that's why I'm asking for opinions. > > -Bertrand > > [1] > https://svn.apache.org/repos/asf/sling/branches/SLING-2987-healthcheck-redesign/hc-core/src/main/java/org/apache/sling/hc/impl/ScriptableHealthCheck.java > -- Carsten Ziegeler cziege...@apache.org
Re: Adding a "usage" service property to BindingsValuesProvider ?
And forgot to mention :) I think your current approach is fine, as these objects are special objects for health checks, you have special execution code and can handle it there. Carsten 2013/8/6 Carsten Ziegeler > I think if we would be in the jsp world, you would do a taglib for this - > of course taglibs are not usable within other scripting languages - so > depending on your script language you would have to come up with the > equivalent. > Taglibs in JSP allow exactly what you want - the BVP is more a way to make > objects always available to all script engines; so apart from adding the > optional node and session objects, we don't use this in Sling at all... > > Carsten > > > 2013/8/6 Bertrand Delacretaz > >> On Tue, Aug 6, 2013 at 5:39 PM, Carsten Ziegeler >> wrote: >> > I guess this only works as you have a special script engine for health >> > check, right? >> >> Not really a special script engine, but I'm using the >> ScriptEngineManager directly instead of going through SlingScript. >> >> See code at [1] where bindings are hardcoded for now - I could invent >> my own bindings providers interface but as we already have one why not >> reuse it? >> >> > >> > What if people want to use the same functionality if they write lets say >> > workflow scripts or wcm scripts etc? >> >> The bindings service could be marked with >> usage=healthcheck,workflow,wcm, or the consumers could be configured >> to use bindings which are marked with usage=healthcheck. >> >> > As long as there is no way to make use of this in every script engine, I >> > don't see the point of adding it. It's a special requirement for hc, so >> it >> > should have a hc solution. >> >> That's an option of course, that's why I'm asking for opinions. >> >> -Bertrand >> >> [1] >> https://svn.apache.org/repos/asf/sling/branches/SLING-2987-healthcheck-redesign/hc-core/src/main/java/org/apache/sling/hc/impl/ScriptableHealthCheck.java >> > > > > -- > Carsten Ziegeler > cziege...@apache.org > -- Carsten Ziegeler cziege...@apache.org
Re: Adding a "usage" service property to BindingsValuesProvider ?
Ok, just to make it clear, as long as there is no support in all script engines, I'm -1 Carsten 2013/8/6 Justin Edelson > Hi Bertrand, > FWIW, I was thinking about something very similar (although I was thinking > of calling it 'scope', not 'usage'), but never got around to implementing > it. > > +1 for me. > > Justin > > > > On Tue, Aug 6, 2013 at 10:58 AM, Bertrand Delacretaz < > bdelacre...@apache.org > > wrote: > > > Hi, > > > > I'd like to use BindingsValuesProvider services in my health check > > module, to provide bindings like "jmx" for scripted health checks, > > which should be ignored for general Sling scripting (or not - some > > providers might apply to both general scripting and health checks). > > > > I'm thinking of adding an optional "usage" service property to > > BindingsValuesProvider services, does anyone see a problem with that? > > > > The Sling script engine would then consider only > > BindingsValuesProvider which have no usage property (for backwards > > compatibility) or which have usage=scripting. > > > > And my health checks would consider only BindingsValuesProvider which > > have usage=healthcheck. > > > > -Bertrand > > > -- Carsten Ziegeler cziege...@apache.org
Re: Adding a "usage" service property to BindingsValuesProvider ?
I'm not totally against this, but just adhoc adding this property without a
complete concept seems wrong to me. Defining the technical selection
process (e.g. as you describe it) is one part, but the other equally
important part, how to select from a script dev point of view. How can I
write a JSP and "tag" this as a "healtcheck" script? And how does this work
for other scripting languages?
Can we find a generic way that works in all / most scripting languages?
Do we really have different existing use cases apart from hc or is this
just a "it would be nice"?
As said, for JSPs we have taglibs which would solve the problem and doesn't
require a BVP, I think for javascript is something equivalent. Of course as
a provider of such support you have to provide different implementations (a
taglib, a javascript lib etc.) - and maybe we should tackle it from this
angle.
Carsten
2013/8/6 Justin Edelson
> Hi Carsten,
> I can't speak for exactly what Bertrand is thinking, but when I was
> thinking about it, the scope/usage was an orthogonal concern to which
> engine is selected.
>
> Whereas today you do:
> ScriptEngineManager.getEngineByExtension("ecma")
>
> You could do
> ScriptEngineManager.getEngineByExtension("ecma", ["healthcheck",
> "workflow"])
>
> (of course, we can't actually do that as ScriptEngineManager is a JDK
> class; we'd have to create an extension)
>
> Alternatively, this could be done after SlingScript object is created:
> SlingScript script = resource.adaptTo(SlingScript.class);
> script.setUsage(["healthcheck"]);
>
> When creating the SlingBindings for the script to execute, the following
> BindingsValuesProviders would be consulted (in order):
> * the generic BVPs (which apply to all scripting languages)
> * the BVPs tagged with the value of the script engine factory's
> compatible.javax.script.name property
> * the BVPs tagged with the script engine factory's name
> * the BVPs tagged with the scope/usage property
>
> Or something like that...
>
> The significant advantage of doing this vs. hardcoding the usage-specific
> bindings at the point of script engine access is that it doesn't allow for
> downstream customization. Which is important IMHO in the case of
> healthcheck - we want to enable custom hc rules which may benefit from a
> custom BVP. This is also true in a workflow engine.
>
> Justin
>
> On Tue, Aug 6, 2013 at 1:41 PM, Carsten Ziegeler >wrote:
>
> > Ok, just to make it clear, as long as there is no support in all script
> > engines, I'm -1
> >
> > Carsten
> >
> >
> > 2013/8/6 Justin Edelson
> >
> > > Hi Bertrand,
> > > FWIW, I was thinking about something very similar (although I was
> > thinking
> > > of calling it 'scope', not 'usage'), but never got around to
> implementing
> > > it.
> > >
> > > +1 for me.
> > >
> > > Justin
> > >
> > >
> > >
> > > On Tue, Aug 6, 2013 at 10:58 AM, Bertrand Delacretaz <
> > > bdelacre...@apache.org
> > > > wrote:
> > >
> > > > Hi,
> > > >
> > > > I'd like to use BindingsValuesProvider services in my health check
> > > > module, to provide bindings like "jmx" for scripted health checks,
> > > > which should be ignored for general Sling scripting (or not - some
> > > > providers might apply to both general scripting and health checks).
> > > >
> > > > I'm thinking of adding an optional "usage" service property to
> > > > BindingsValuesProvider services, does anyone see a problem with that?
> > > >
> > > > The Sling script engine would then consider only
> > > > BindingsValuesProvider which have no usage property (for backwards
> > > > compatibility) or which have usage=scripting.
> > > >
> > > > And my health checks would consider only BindingsValuesProvider which
> > > > have usage=healthcheck.
> > > >
> > > > -Bertrand
> > > >
> > >
> >
> >
> >
> > --
> > Carsten Ziegeler
> > cziege...@apache.org
> >
>
--
Carsten Ziegeler
cziege...@apache.org
Re: Time to release Sling 6 update 1 ? ( Was : Re: Time to release Sling 7? )
I definitely agree that we should try to get Sling 6 out asap - and I think we're pretty close to that. Apart maybe from a release of one or two additional bundles, we need to release the discovery stuff (I plan to do this end of this week/early next week) and the new admin login stuff Felix is working on (hopefully this needs just a few weeks from now). Once these releases are through we can release Sling 6. So I think let's look at the snapshot dependencies in launchpad, see if these artifacts have some urgent open issues, fix them (if there are any) and then release the stuff. For the build server problems, I'm totally unhappy with the Jenkins installation (and this since years) - apart from spamming the mailing list, the value right now seems really very low. Though I have no idea how to change this... Regards Carsten 2013/8/7 Robert Munteanu > Sorry to resurrect such an old thread, but I started this conversation 3 > months ago and we aren't close to releasing Sling 7. > > IMO the build server flakiness contributes to this uncertainty, but so > do a few or our tests, being unstable as well. > > What I'd like to propose now is to make a very minor, specific release > of the Sling Launchpad: build it with org.apache.sling.launchpad.base > 2.5.0 . > > This is a low-risk move - I've tested it myself and has the advantage of > allowing first-time users to get on board with Java 7. Right now I fear > that some of them walk away after an unsuccessful attempt of running > Sling. > > Thoughts? > > Robert > > -- Carsten Ziegeler cziege...@apache.org
Re: Adding a "usage" service property to BindingsValuesProvider ?
2013/8/7 Felix Meschberger
>
> A script, at the end of the day, executes some action and might or might
> not expect some bindings (global variables in some languages). The script
> would have to cope with them missing or of the wrong type or such... But
> there is not currently a way that a script could declare "I am an HC
> script" or "I am a Request Processing script".
Exactly, that's my point - and unless we have a mechanism for this, marking
a BVP is useless.
> Not even a taglib can do that -- at the end of the day a TagLib is
> syntactic sugar for functionality, which must also be usable otherwise.
>
Right - but it fits exactly the needs at least in JSP of what is discussed
here. Instead of saying "I'm a workflow script" , the script uses the
workflow taglib.
Carsten
>
> Regards
> Felix
>
> > As said, for JSPs we have taglibs which would solve the problem and
> doesn't
> > require a BVP, I think for javascript is something equivalent. Of course
> as
> > a provider of such support you have to provide different implementations
> (a
> > taglib, a javascript lib etc.) - and maybe we should tackle it from this
> > angle.
> >
> >
> > Carsten
> >
> >
> >
> > 2013/8/6 Justin Edelson
> >
> >> Hi Carsten,
> >> I can't speak for exactly what Bertrand is thinking, but when I was
> >> thinking about it, the scope/usage was an orthogonal concern to which
> >> engine is selected.
> >>
> >> Whereas today you do:
> >> ScriptEngineManager.getEngineByExtension("ecma")
> >>
> >> You could do
> >> ScriptEngineManager.getEngineByExtension("ecma", ["healthcheck",
> >> "workflow"])
> >>
> >> (of course, we can't actually do that as ScriptEngineManager is a JDK
> >> class; we'd have to create an extension)
> >>
> >> Alternatively, this could be done after SlingScript object is created:
> >> SlingScript script = resource.adaptTo(SlingScript.class);
> >> script.setUsage(["healthcheck"]);
> >>
> >> When creating the SlingBindings for the script to execute, the following
> >> BindingsValuesProviders would be consulted (in order):
> >> * the generic BVPs (which apply to all scripting languages)
> >> * the BVPs tagged with the value of the script engine factory's
> >> compatible.javax.script.name property
> >> * the BVPs tagged with the script engine factory's name
> >> * the BVPs tagged with the scope/usage property
> >>
> >> Or something like that...
> >>
> >> The significant advantage of doing this vs. hardcoding the
> usage-specific
> >> bindings at the point of script engine access is that it doesn't allow
> for
> >> downstream customization. Which is important IMHO in the case of
> >> healthcheck - we want to enable custom hc rules which may benefit from a
> >> custom BVP. This is also true in a workflow engine.
> >>
> >> Justin
> >>
> >> On Tue, Aug 6, 2013 at 1:41 PM, Carsten Ziegeler >>> wrote:
> >>
> >>> Ok, just to make it clear, as long as there is no support in all script
> >>> engines, I'm -1
> >>>
> >>> Carsten
> >>>
> >>>
> >>> 2013/8/6 Justin Edelson
> >>>
> >>>> Hi Bertrand,
> >>>> FWIW, I was thinking about something very similar (although I was
> >>> thinking
> >>>> of calling it 'scope', not 'usage'), but never got around to
> >> implementing
> >>>> it.
> >>>>
> >>>> +1 for me.
> >>>>
> >>>> Justin
> >>>>
> >>>>
> >>>>
> >>>> On Tue, Aug 6, 2013 at 10:58 AM, Bertrand Delacretaz <
> >>>> bdelacre...@apache.org
> >>>>> wrote:
> >>>>
> >>>>> Hi,
> >>>>>
> >>>>> I'd like to use BindingsValuesProvider services in my health check
> >>>>> module, to provide bindings like "jmx" for scripted health checks,
> >>>>> which should be ignored for general Sling scripting (or not - some
> >>>>> providers might apply to both general scripting and health checks).
> >>>>>
> >>>>> I'm thinking of adding an optional "usage" service property to
> >>>>> BindingsValuesProvider services, does anyone see a problem with that?
> >>>>>
> >>>>> The Sling script engine would then consider only
> >>>>> BindingsValuesProvider which have no usage property (for backwards
> >>>>> compatibility) or which have usage=scripting.
> >>>>>
> >>>>> And my health checks would consider only BindingsValuesProvider which
> >>>>> have usage=healthcheck.
> >>>>>
> >>>>> -Bertrand
> >>>>>
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> Carsten Ziegeler
> >>> cziege...@apache.org
> >>>
> >>
> >
> >
> >
> > --
> > Carsten Ziegeler
> > cziege...@apache.org
>
>
--
Carsten Ziegeler
cziege...@apache.org
Re: Adding a "usage" service property to BindingsValuesProvider ?
Again, I'm still missing a suggestion on how to mark a script to run in a given context. Carsten 2013/8/7 Bertrand Delacretaz > On Wed, Aug 7, 2013 at 10:09 AM, Felix Meschberger > wrote: > > ...In fact I would say, that BVPs without the property should just be > used anywhere > > that might work - I was going to say that [1] for example makes no > sense in my health check context, but that provider is being careful > to not add anything if the "resource" binding is not available so > we're fine. > > >> ...3. Provide a service to collect relevant BVPs when setting up > >> scripting, based on a set of context values. > > > > Since the selection is so easy with a service selection filter or target > attribute on a @Reference annotation, such a service would be overkill > ;-)... > > Ok, I'm not a fan of the LDAP-like filter syntax but it's workable, > and except for the DefaultSlingScript which needs to take care of > backwards compatibility the filters should be simple. > > -Bertrand > -- Carsten Ziegeler cziege...@apache.org
Re: Adding a "usage" service property to BindingsValuesProvider ?
Hmm, this doesn't really convince me. So this means there is no way to set the context apart from creating/retrieving a script engine by hand (java code)? So scripts run with the usual Sling script resolution will always just use BVPs not marked for any context and BVPs marked for the context request. I still fail to see the usefulness - but as you all seem to go crazy about it, I wont block this Carsten 2013/8/7 Bertrand Delacretaz > On Wed, Aug 7, 2013 at 10:26 AM, Carsten Ziegeler > wrote: > > Again, I'm still missing a suggestion on how to mark a script to run in a > > given context... > > You don't. > > There are request processing scripts, the ones we have and always had > - there's no change for those, except that with this change they won't > get any BVPs which are marked for a context that is not "request". > Existing BVPs are not marked like that so no change. There's no way > and no need to mark those scripts for a different context, they are > "request" processing scripts. > > Then there are new health check (mini-)scripts which are different > animals: they are provided in OSGi configs as shown earlier in this > thread. Their context is hardcoded to "healthcheck", there's no need > to change that. > > Another way to look at this, and maybe I should have phrased my > proposal like that, is that the goal is to setup different script > engines: currently we're just using a "request processing" script > engine, I need a "healtcheck" script engine with different bindings, > and it makes sense to generalize the idea. > > -Bertrand > -- Carsten Ziegeler cziege...@apache.org
Re: Time to release Sling 6 update 1 ? ( Was : Re: Time to release Sling 7? )
Yepp, let's give it a try - we don't need to publish the artifacts, just getting a success/fail mail is enough Carsten 2013/8/7 Bertrand Delacretaz > On Wed, Aug 7, 2013 at 10:35 AM, Robert Munteanu wrote: > > ...I can take care of setting up the .travis.yml file to make sure that > > Sling builds on Travis. Then we need to find out how to authorize > > Travis to build apache/sling ; OAK did it so it's possible > > Sounds good to me! > -Bertrand > -- Carsten Ziegeler cziege...@apache.org
Re: Sling SVN Dist Access
Hi Dan, only PMC members have write access to that dir, I can do this step for you if you want to. Regards Carsten 2013/8/7 Daniel Klco > All, > > I am attempting to complete the release for Sling JSP TagLib 2.2.0, however > it seems I don't have commit access to the repository for the Sling > project's folder on dist.apache.org ( > https://dist.apache.org/repos/dist/release/sling/). > > When I checked with the infrastructure team, they said that by default only > PMC members have access to the releases directory. Can I be granted access > to that directory? Or should I request the release be completed by a PMC > member. > > Thanks, > Dan > -- Carsten Ziegeler cziege...@apache.org
Re: Sling SVN Dist Access
No, I've got them from nexus - so, once you close the vote, I'll add them to the dir Carsten 2013/8/8 Daniel Klco > Carsten, > > Thank you, do you need me to send you the files? > > Thanks, > Dan > > > On Thu, Aug 8, 2013 at 2:18 AM, Carsten Ziegeler >wrote: > > > Hi Dan, > > > > only PMC members have write access to that dir, I can do this step for > you > > if you want to. > > > > Regards > > Carsten > > > > > > 2013/8/7 Daniel Klco > > > > > All, > > > > > > I am attempting to complete the release for Sling JSP TagLib 2.2.0, > > however > > > it seems I don't have commit access to the repository for the Sling > > > project's folder on dist.apache.org ( > > > https://dist.apache.org/repos/dist/release/sling/). > > > > > > When I checked with the infrastructure team, they said that by default > > only > > > PMC members have access to the releases directory. Can I be granted > > access > > > to that directory? Or should I request the release be completed by a > PMC > > > member. > > > > > > Thanks, > > > Dan > > > > > > > > > > > -- > > Carsten Ziegeler > > cziege...@apache.org > > > -- Carsten Ziegeler cziege...@apache.org
[VOTE] Release Discovery Modules, Settings and Eventing
Hi, this vote is primarily about doing the first release of our discovery implementation modules (we already released the api some time ago). The implementation proofed to be stable/usable. In addition, we need to release a dependency, Sling Settigns 1.3.0 and I've also included the Sling Events as this makes heavy use of the discovery stuff. So please vote for the release of Sling Settings 1.3.0 https://issues.apache.org/jira/browse/SLING/fixforversion/12323581 Sing Discovery Support 1.0.0 Sling Discovery Standalone 1.0.0 Sling Discovery Impl 1.0.0 https://issues.apache.org/jira/browse/SLING/fixforversion/12324346 Sling Eventing 3.2.0 https://issues.apache.org/jira/browse/SLING/fixforversion/12321291 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-079/ You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh Usage: sh check_staged_release.sh079 /tmp/sling-staging Please vote to approve this release: [ ] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... This vote will be open for 72 hours. Regards Carsten -- Carsten Ziegeler cziege...@apache.org
Re: [VOTE] Release Discovery Modules, Settings and Eventing
+1 Carsten 2013/8/9 Carsten Ziegeler > Hi, > > this vote is primarily about doing the first release of our discovery > implementation modules (we already released the api some time ago). The > implementation proofed to be stable/usable. In addition, we need to release > a dependency, Sling Settigns 1.3.0 and I've also included the Sling Events > as this makes heavy use of the discovery stuff. > > So please vote for the release of > > Sling Settings 1.3.0 > https://issues.apache.org/jira/browse/SLING/fixforversion/12323581 > > Sing Discovery Support 1.0.0 > Sling Discovery Standalone 1.0.0 > Sling Discovery Impl 1.0.0 > https://issues.apache.org/jira/browse/SLING/fixforversion/12324346 > > Sling Eventing 3.2.0 > https://issues.apache.org/jira/browse/SLING/fixforversion/12321291 > > Staging repository: > https://repository.apache.org/content/repositories/orgapachesling-079/ > > You can use this UNIX script to download the release and verify the > signatures: > http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh > > Usage: > sh check_staged_release.sh079 /tmp/sling-staging > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] 0 Don't care > [ ] -1 Don't release, because ... > > This vote will be open for 72 hours. > > Regards > Carsten > -- > Carsten Ziegeler > cziege...@apache.org > -- Carsten Ziegeler cziege...@apache.org
Re: [jira] Components and version for IDE tooling
I've created the component, I'm not sure about the version, wouldn't this be more specific like "Sling Eclipse IDE 1.0.0" (or whatever we pick) ? 2013/8/9 Robert Munteanu > Hi, > > Can someone please create an 'IDE' component and 'IDE 1.0.0' version in > Jira? > > Thanks, > > Robert > > -- Carsten Ziegeler cziege...@apache.org
Re: [jira] Components and version for IDE tooling
Ok, done - we can rename later on if required. Carsten 2013/8/9 Robert Munteanu > On Fri, 2013-08-09 at 14:00 +0200, Carsten Ziegeler wrote: > > I've created the component, I'm not sure about the version, wouldn't this > > be more specific like "Sling Eclipse IDE 1.0.0" (or whatever we pick) ? > > Sling Eclipse IDE 1.0.0 sounds fine to me, we're focusing on that > initially anyway. > > Robert > > > > -- Carsten Ziegeler cziege...@apache.org
Re: Data model for HealthCheck results: pass/fail or value based?
Hi,
I've added some comments to the issue about the current api :) I think we
should not relying on log messages as the communication between a HC and
the result. The HC should create a proper result object, and the status
should be a field in that object.
I think a boolean value (failed/ok) might bot be sufficient, so I think an
enum with more values inbetween (like Jörg's API has) is better.
For the range stuff, I think we don't need this.
If we make the Result a class with setter methods, we can later on add
additional stuff if required without breaking anything.
Carsten
2013/8/9 Bertrand Delacretaz
> Hi,
>
> Following up on SLING-2987 I'm wondering about the best way to
> represent the results of health checks.
>
> Right now the health check Result just provides a boolean isOk()
> method, along with a getStatus() that's similar to a log level (ok,
> warn, error etc.).
>
> I haven't been using the status so far, so for now it's just a
> pass/fail (along with a mini-log that provides unstructured details).
>
> Another model that might be more useful (or YAGNI...hence this
> question) would be:
>
> public interface ResultThatHasAValue {
> // The output value of this health check
> public object getValue();
>
> // The acceptable range of our value
> public String getRange();
>
> // True if our value is in range
> public boolean isInRange();
>
>// + logs as now
> }
>
> The advantage of this value-based result is that it can also be used
> to aggregate values that might be analyzed in a finer way by external
> JMX tools (as the healthcheck results are now available via JMX).
>
> The range can be a simple mini-language with ranges like "true",
> "between 12 and 41", "> 16", "some.*Regexp", etc.
>
> WDYT, does anyone have a concrete use case for ResultThatHasAValue?
> Otherwise I'll stick with the current pass/fail (+logs) results.
>
> Note that the docs at [1] are out of date now, but if you want to play
> with the health check just build and install the two bundles found
> under contrib/extensions/healthcheck and open
> /system/console/healthcheck
>
> -Bertrand
>
> [1]
> http://sling.apache.org/documentation/bundles/sling-health-check-tool.html
>
--
Carsten Ziegeler
cziege...@apache.org
Re: Data model for HealthCheck results: pass/fail or value based?
Ok, agreed :) Sounds like a good compromise - however :) I think we should
make Result a class with getter and setter methods; this allows for better
extensibility (we don't need to change any implementation if we add new
methods/features) and also makes the healt check service implementation
easier.
Carsten
2013/8/12 Bertrand Delacretaz
> Hi Carsten,
>
> On Fri, Aug 9, 2013 at 5:00 PM, Carsten Ziegeler
> wrote:
> > I've added some comments to the issue about the current api :) I think we
> > should not relying on log messages as the communication between a HC and
> > the result. The HC should create a proper result object, and the status
> > should be a field in that object...
>
> Ok - I agree that decoupling the results from the logging model gives
> more flexibility and reduces the API's footprint.
>
> However, having a mini-log as part of the result is very useful, and
> being able to have several types of log messages helps make health
> check results self-explaining.
>
> So how about:
>
> a) In the HealthCheck interface, change to "Result execute()", i.e.
> drop the ResultLog.
>
> b) change Result into an interface:
>
> public interface Result {
> Iterator getResultLog();
> Status getStatus();
> }
>
> Where Status is an enum (OK, WARN, CRITICAL, ERROR) and ResultLog is
>
> public class ResultLog {
> ...
> String getType();
> String getMessage();
> }
>
> Using Strings for the log types (not "levels" as there's no notion of
> higher/lower levels) to allow HealthChecks to invent their own types
> if needed. Things like "HOWTOFIX", "PERFORMANCE" etc.
>
> I think this provides a nice balance between rich logs and extensibility,
> WDYT?
>
> -Bertrand
>
--
Carsten Ziegeler
cziege...@apache.org
[VOTE RESULT] Release Discovery Modules, Settings and Eventing
time to tally the vote: +1 Felix Meschberger*, Carsten Ziegeler*, Bertrand Delacretaz*, Mike Müller*, Dan Klco, 0 - -1 - No other votes have been cast. This vote passes with 5 +1 votes (4 of which binding). Thanks for the votes. I will continue publishing the artifacts. Carsten 2013/8/9 Felix Meschberger > +1 > > Regards > Felix > > Am 09.08.2013 um 09:51 schrieb Carsten Ziegeler: > > > Hi, > > > > this vote is primarily about doing the first release of our discovery > > implementation modules (we already released the api some time ago). The > > implementation proofed to be stable/usable. In addition, we need to > release > > a dependency, Sling Settigns 1.3.0 and I've also included the Sling > Events > > as this makes heavy use of the discovery stuff. > > > > So please vote for the release of > > > > Sling Settings 1.3.0 > > https://issues.apache.org/jira/browse/SLING/fixforversion/12323581 > > > > Sing Discovery Support 1.0.0 > > Sling Discovery Standalone 1.0.0 > > Sling Discovery Impl 1.0.0 > > https://issues.apache.org/jira/browse/SLING/fixforversion/12324346 > > > > Sling Eventing 3.2.0 > > https://issues.apache.org/jira/browse/SLING/fixforversion/12321291 > > > > Staging repository: > > https://repository.apache.org/content/repositories/orgapachesling-079/ > > > > You can use this UNIX script to download the release and verify the > > signatures: > > http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh > > > > Usage: > > sh check_staged_release.sh079 /tmp/sling-staging > > > > Please vote to approve this release: > > > > [ ] +1 Approve the release > > [ ] 0 Don't care > > [ ] -1 Don't release, because ... > > > > This vote will be open for 72 hours. > > > > Regards > > Carsten > > -- > > Carsten Ziegeler > > cziege...@apache.org > > -- Carsten Ziegeler cziege...@apache.org
Re: [DISCUSS] move healthcheck under bundles/extensions and release as 0.9.0
I'm not against this in general, I think it would be good to give us a little bit of time to have a look at the latest state before having a release. So maybe targeting next week for a move/release might be good Carsten 2013/8/13 Bertrand Delacretaz > Hi, > > I'm done with the SLING-2987 redesign of the healthcheck modules. > > WDYT about moving it under bundles/extensions instead of contrib? Yes > I intend to maintain it ;-) > > And I think we can also release it as a first version, as V0.9.0 to > indicate that it's still brand new. > > For more info, docs are at > > > http://sling.apache.org/documentation/bundles/sling-health-check-tool.html > > And the API is at > > > http://svn.apache.org/repos/asf/sling/trunk/contrib/extensions/healthcheck/api/src/main/java/org/apache/sling/hc/api/ > > -Bertrand > -- Carsten Ziegeler cziege...@apache.org
[HC] Result and ResultLogEntry
Hi, I'm not sure whether the current handling of log entries and status between the result object and the log entries is a good thing. For one, all log entries added to the result are logged to a logger - I think this can easily result in having the statements logged out more than once and it breaks the contract of having result a simple data object. In addition, when a log message is added, it's level is evaluated to automatically set the status - if a HC check is just doing log statements for informational purpuse with level that leads to automatic status setting, the HC can't set the status to a lower level afterwards. I think there shouldn't be any additional logic in the result class except from just adding the log entries to a collection. Regards Carsten -- Carsten Ziegeler cziege...@apache.org
[HC] Registering HCs as mbeans
Hi, right now, all HCs are registered as mbeans - I'm just wondering if we need an opt-in or opt-out mechanism? Carsten -- Carsten Ziegeler cziege...@apache.org
Re: [HC] Registering HCs as mbeans
Yes, I'm not 100% sure about this - I was just wondering about how to disable a health check and had the idea instead of disabling the check in any way, simply not making it available via JMX. If we need that, we can probably add an opt-out way later on. Carsten 2013/8/13 Bertrand Delacretaz > On Tue, Aug 13, 2013 at 5:09 PM, Carsten Ziegeler > wrote: > > right now, all HCs are registered as mbeans - I'm just wondering if we > need > > an opt-in or opt-out mechanism? > > I think in general they should all be exposed, as long as they can be > organized cleanly which is possible. > > You can place MBeans in a specific place in the JMX tree, if you set > hc.mean.name = foo/thisbean for example, it will appear under > org.apache.sling.healthcheck/foo/thisbean whereas by default MBeans go > under org.apache.sling.healthcheck/HealthCheck. So you can already > create subsets of interesting HC MBeans, without having too many > options to care about. > > -Bertrand > -- Carsten Ziegeler cziege...@apache.org
[HC] Use service registration properties
Hi, we briefly discussed this during the refactoring and I think we agreed :) that the current properties (for which constants are defined) should actually be service registration properties. Therefore I suggest to move the constants into the HC interface class and then we can also remove the getInfo() method and clarify the contract (which service props are required, what default values are used etc.) In addition, the jmx bridge can then get HC services on demand but already register the mbeans without getting the service. If no one objects I'll create an issue for this and do the changes. Carsten -- Carsten Ziegeler cziege...@apache.org
Re: [HC] Use service registration properties
No, I mean not having these at all :) and just have them as service properties. Filtering services based on the tags can be done using the filter expression based on service properties and registering the checks as mbeans works this way as well. Do we have other use cases ? Carsten 2013/8/14 Bertrand Delacretaz > Hi Carsten, > > On Tue, Aug 13, 2013 at 8:27 PM, Carsten Ziegeler > wrote: > > ...we briefly discussed this during the refactoring and I think we > agreed :) > > that the current properties (for which constants are defined) should > > actually be service registration properties > > Not sure what you mean...adding getters for these properties? > > Having HealthCheck.getName(), HealthCheck.getTags() etc. would indeed > allow for removing the getInfo() method which is good. > > If that's what you mean I can make the changes later today, and get > rid of the Constants class as well. > > -Bertrand > -- Carsten Ziegeler cziege...@apache.org
Re: [HC] Use service registration properties
I don't see any use case where it's not possible to have a service reference - and tools could just query the mbeans as an alternative Carsten 2013/8/14 Felix Meschberger > Hi > > Am 14.08.2013 um 11:37 schrieb Bertrand Delacretaz: > > > On Wed, Aug 14, 2013 at 11:33 AM, Carsten Ziegeler > wrote: > >> ...I mean not having these at all :) and just have them as service > >> properties. Filtering services based on the tags can be done using the > >> filter expression based on service properties and registering the > checks as > >> mbeans works this way as well... > > > > Ok, that's how it's done now. > > > >> Do we have other use cases ? > > > > We need some of these values (HC name and tags at least) in the > > webconsole and MBeans when we output a Result. We usually don't have a > > ServiceReference there, just HealthCheck, so it's much more convenient > > to be able to access that info from a HealthCheck. > > Yet: for the MBean the Health Check controller getting the HealthCheck > services and registering MBeans on behalf of them could as well leverage > the ServiceReference properties to setup the MBean's objectname properties > or Attributes. I would assume the actual MBean registered will be a > proxy/wrapper to the HealthCheck service implementing the appropriate MBean > interface and embedding the ServiceReference and HealthCheck objects, or so. > > As for the Web Console: This is one of the reporting tools, I had in mind. > If the WebConsole directly accesses the services through the Service > Registry, it will also have the ServiceReference in hand ... > > But still, there may be report tooling not able to cope with > ServiceReferences ? > > Regards > Felix -- Carsten Ziegeler cziege...@apache.org
Re: [HC] Use service registration properties
Filtering is usually done before you get all services - so this works perfectly well with service properties. Right now, the main use case we have is registering the services as mbeans, followed by showing the results in the web console - and this can easily use service references or the mbeans. Carsten 2013/8/14 Felix Meschberger > Hi > > I think it all depends on who the primary consumer of the data is ... > > In any case, having a generic getInfos() method does not help much if the > infos really help identify the HealthCheck service. > > If the data -- like name, description, and tags -- are usefull in a > reporting context, it might make sense to expose those as explicit API in > the service. > > Those properties, that are used select service -- presumably the tags -- > should be exposed as service registration properties. > > This may result in some properties to be exposed twice: This does not > sounds nice, but maybe it is still better than to force all non-OSGi users > to cope with a ServiceReference or to require getting service objects just > to be able to filter on tags. > > Regards > Felix > > Am 14.08.2013 um 10:16 schrieb Bertrand Delacretaz: > > > Hi Carsten, > > > > On Tue, Aug 13, 2013 at 8:27 PM, Carsten Ziegeler > wrote: > >> ...we briefly discussed this during the refactoring and I think we > agreed :) > >> that the current properties (for which constants are defined) should > >> actually be service registration properties > > > > Not sure what you mean...adding getters for these properties? > > > > Having HealthCheck.getName(), HealthCheck.getTags() etc. would indeed > > allow for removing the getInfo() method which is good. > > > > If that's what you mean I can make the changes later today, and get > > rid of the Constants class as well. > > > > -Bertrand > > -- Carsten Ziegeler cziege...@apache.org
Re: [HC] Registering HCs as mbeans
Just as a general comment, for the object name its good practice to have the type and name property and avoid any other additional properties in the object name. Carsten 2013/8/14 Felix Meschberger > > Am 14.08.2013 um 11:34 schrieb Bertrand Delacretaz: > > > On Wed, Aug 14, 2013 at 11:21 AM, Felix Meschberger > wrote: > >> ...There is no such thing as a JMX Bean tree. Each JMX Bean has an > ObjectName and the only official > >> structuring is by the MBean's domain. The rest of name is just > name-value pairs... > > > > That's technically correct, but from the perspective of a jconsole > > user you see a tree, that's what I meant. > > JConsole is a presentation as is the Sling JMX ResourceProvider. > > What we are dealing with here are MBeans, and they don't care for nor know > of tree structures. Everything else would be crossing the abstraction > barrier. > > > > > The HC MBeans are currently registered under the > > org.apache.sling.healthcheck domain, and their service name and type > > names are configurable. Currently as a single string like > > "service/type", might be better to separate that in two separate > > properties. > > Yes. Leave the presentation to the presentation tools and care for the > correct and intended MBean mechanism > > Regards > Felix > > > > > -Bertrand > > -- Carsten Ziegeler cziege...@apache.org
Re: [HC] Registering HCs as mbeans
Ok, so maybe we should first answer the initial question :) Are all HC services registered as mbeans or not? If not, how do we distinguish? Carsten 2013/8/14 Bertrand Delacretaz > On Wed, Aug 14, 2013 at 11:23 AM, Felix Meschberger > wrote: > > ...Whether a HealthCheck service is exposed in JMX or not, is something > to be > > done by the HealthCheck controller, I think > > Not sure what you mean by that - see > contrib/extensions/healthcheck/jmx for how that works now: if this > bundle is active (which makes the whole thing optional), the > HealthCheckMBeanCreator creates an MBean for each HealthCheck service. > > We can easily make the MBean creation optional, for example by saying > that if no hc.mbean.name service property is set no MBean is created > (currently a default name is used). > > -Bertrand > -- Carsten Ziegeler cziege...@apache.org
Re: [HC] Registering HCs as mbeans
Ok, and the value of the hc.mbean.name is used as the property "name" for the object name, right? So all HCs get the same fixed domain and type, they just differ by name. I already added a TODO to the jmx bridge, that we have to handle the case where two HCs use the same "name". I think we should solve this by using service ranking and only registering the one with the highest ranking. If no one disagrees, I'll do the changes in the next days, along with using service properties. Carsten 2013/8/14 Bertrand Delacretaz > On Wed, Aug 14, 2013 at 3:27 PM, Carsten Ziegeler > wrote: > > ...maybe we should first answer the initial question :) Are all HC > > services registered as mbeans or not?... > > As I said I have at least one use case for making the MBeans > registration optional: when several HC are aggregated by a > CompositeHealthCheck (that executes several of them, selected by > tags), it might be good to expose only the composite as an MBean. > > The simplest seems to be to omit the MBean registration for HC > services that do not supply an hc.mbean.name property. > > -Bertrand > -- Carsten Ziegeler cziege...@apache.org
Re: [HC] Registering HCs as mbeans
The type property should really specify the type - as all these are registered as the same mbean with the same attributes, I don't think we should a HC allow to specify the type. I think using the service ranking approach in combination with the name, is the better option - it's used nearly everywhere else in same situations and it allows you to overwrite a HC e.g. by deploying a better version coming from a different source. We can add a nice log message for these cases. (and have a HC checking this :) ) Regards Carsten 2013/8/14 Bertrand Delacretaz > On Wed, Aug 14, 2013 at 4:18 PM, Carsten Ziegeler > wrote: > > Ok, and the value of the hc.mbean.name is used as the property "name" > for > > the object name, right? > > Yes > > > So all HCs get the same fixed domain and type, they just differ by name. > > If you configure a name like foo/bar foo becomes the type, so you can set > it. > > Might be better to have an explicit hc.mean.type service property. > > > > > ...I already added a TODO to the jmx bridge, that we have to handle the > case > > where two HCs use the same "name". I think we should solve this by using > > service ranking and only registering the one with the highest ranking > > Isn't that hard to troubleshoot? Generating a unique suffix for the > second, instead of not registering it, might make it easier to detect > the error. > > > > > If no one disagrees, I'll do the changes in the next days, along with > using > > service properties. > > works for me. > -Bertrand > -- Carsten Ziegeler cziege...@apache.org
Requiring Java 6 for a Sling bundle
Hi, just a reminder, if your bundle requires Java 6, please simply use the provided functionality of our parent pom and do: 6 This configures all required plugins accordingly and also adds a header to your bundle stating the requirement. Don't configure all the plugins in your pom by hand. Thanks Carsten -- Carsten Ziegeler cziege...@apache.org
Re: [VOTE] Apache Commons Log 3.0.2
+1 Carsten 2013/8/26 Felix Meschberger > +1 > > Regards > Felix > > Am 26.08.2013 um 10:11 schrieb Felix Meschberger: > > > Hi > > > > This is to vote for the Apache Commons Log 3.0.2 release. This is > probably the last release we are cutting with our home grown SLF4J API > implementation embedded. The next release is planned to be 4.0.0 which will > most probably be based on Logback (SLING-2024). > > > > The following issues have been implemented and fixed in this release: > > https://issues.apache.org/jira/browse/SLING/fixforversion/12319554 > > > > Staging repository: > > https://repository.apache.org/content/repositories/orgapachesling-115/ > > > > You can use this UNIX script to download the release and verify the > > signatures: > > http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh > > > > Usage: > > sh check_staged_release.sh 115 /tmp/sling-staging > > > > Please vote to approve this release: > > > > [ ] +1 Approve the release > > [ ] 0 Don't care > > [ ] -1 Don't release, because ... > > > > This vote will be open for 72 hours. > > > > Regards > > Felix > > -- Carsten Ziegeler cziege...@apache.org
Configuration of Health Check Services and MBeans
Hi, right now a Health Check Service can be registered as an mbean (if a specific service reg prop is set). While the underlying HC service has a service PID and this can be used to configure the service, this information gets lost in the registered mbean. By just looking at the mbean, it's not possible to see if/how the HC is configurable. Now, a simple and obvious solution is to add the PID as an attribute of the mbean - I'm wondering if anyone has a better idea or opinion? Regards Carsten -- Carsten Ziegeler cziege...@apache.org
[VOTE] Parent POM 18
Hi, please vote for a release of our parent pom, it basically contains updates of the used plugin versions to their latest release: https://issues.apache.org/jira/browse/SLING/fixforversion/12324745 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-002/ You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 002 /tmp/sling-staging Please vote to approve this release: [ ] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... This vote will be open for 72 hours. Regards Carsten -- Carsten Ziegeler cziege...@apache.org
Re: [VOTE] Parent POM 18
+1 2013/9/3 Carsten Ziegeler > Hi, > > please vote for a release of our parent pom, it basically contains updates > of the used plugin versions to their latest release: > > https://issues.apache.org/jira/browse/SLING/fixforversion/12324745 > > > Staging repository: > https://repository.apache.org/content/repositories/orgapachesling-002/ > > You can use this UNIX script to download the release and verify the > signatures: > http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh > > Usage: > sh check_staged_release.sh 002 /tmp/sling-staging > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] 0 Don't care > [ ] -1 Don't release, because ... > > This vote will be open for 72 hours. > > Regards > Carsten > -- > Carsten Ziegeler > cziege...@apache.org > -- Carsten Ziegeler cziege...@apache.org
Re: JobQueue provider ?
In theory this would be possible, but I guess this would create maybe more problems - an implementation might not be available (anymore), a configuration might point to a non existing implementation etc. A lot more things could go wrong. What's your use case? :) Carsten 2013/9/3 Ian Boston > Hi, > I see that the JobQueues are hard coded into the JobManager. > > Would it be possible to make the JobQueue an API so that its could be > provided by another bundle ? > > Best Regards > Ian > -- Carsten Ziegeler cziege...@apache.org
Re: JobQueue provider ?
I think this is beyond queuing - you can use a topology listener for that by disabling a topic on all instances but the active one. If the active one goes down, an event is fired on the remaining instances, and another one can take over. This will ensure rescheduling of jobs to that instance by the job manager. So all you have to take care of is managing the blacklist of the job consumer manager based on topology events. Carsten 2013/9/3 Ian Boston > Hi, > > I want to be able to submit jobs, distribute those jobs and have those > jobs restart on instance failover in a way not supported by the > current jobs queues in the event bundle, without requiring the event > bundle to be re-released. > > eg > Run only on the active Sling instance in a active/passive pair and if > the active instance changes, then that instance new active instance to > run all the jobs, including jobs that were added, but not run on the > old active instance. > > Ian > > > On 3 September 2013 18:00, Carsten Ziegeler wrote: > > In theory this would be possible, but I guess this would create maybe > more > > problems - an implementation might not be available (anymore), a > > configuration might point to a non existing implementation etc. A lot > more > > things could go wrong. > > > > > > What's your use case? :) > > > > Carsten > > > > > > 2013/9/3 Ian Boston > > > >> Hi, > >> I see that the JobQueues are hard coded into the JobManager. > >> > >> Would it be possible to make the JobQueue an API so that its could be > >> provided by another bundle ? > >> > >> Best Regards > >> Ian > >> > > > > > > > > -- > > Carsten Ziegeler > > cziege...@apache.org > -- Carsten Ziegeler cziege...@apache.org
Re: JobQueue provider ?
Yes, I think this would really make the whole implementation and handling much more compicated. And actually black listing is exactly for these use cases. It gives you control which instance is able to handle what jobs. So you can exclude a specific instance from processing a specific job, in your use case you exclude all but one. This is not blacklisting of event handlers if you're refering to that one. Carsten 2013/9/3 Ian Boston > Hi, > I see how it could work, but it seems an odd way of making a queue > work, to actively blacklist a topic queue on certain instances. I > thought black listing was intended for non responsive consumers. > > Is there something inherently wrong with the concept of a JobQueue > provider ? > Is it because it would make the implementation of the JobManager too > complex where providers are not present at activation ? > > Best Regards > Ian > > On 3 September 2013 19:00, Carsten Ziegeler wrote: > > I think this is beyond queuing - you can use a topology listener for that > > by disabling a topic on all instances but the active one. If the active > one > > goes down, an event is fired on the remaining instances, and another one > > can take over. This will ensure rescheduling of jobs to that instance by > > the job manager. > > So all you have to take care of is managing the blacklist of the job > > consumer manager based on topology events. > > > > Carsten > > > > > > 2013/9/3 Ian Boston > > > >> Hi, > >> > >> I want to be able to submit jobs, distribute those jobs and have those > >> jobs restart on instance failover in a way not supported by the > >> current jobs queues in the event bundle, without requiring the event > >> bundle to be re-released. > >> > >> eg > >> Run only on the active Sling instance in a active/passive pair and if > >> the active instance changes, then that instance new active instance to > >> run all the jobs, including jobs that were added, but not run on the > >> old active instance. > >> > >> Ian > >> > >> > >> On 3 September 2013 18:00, Carsten Ziegeler > wrote: > >> > In theory this would be possible, but I guess this would create maybe > >> more > >> > problems - an implementation might not be available (anymore), a > >> > configuration might point to a non existing implementation etc. A lot > >> more > >> > things could go wrong. > >> > > >> > > >> > What's your use case? :) > >> > > >> > Carsten > >> > > >> > > >> > 2013/9/3 Ian Boston > >> > > >> >> Hi, > >> >> I see that the JobQueues are hard coded into the JobManager. > >> >> > >> >> Would it be possible to make the JobQueue an API so that its could be > >> >> provided by another bundle ? > >> >> > >> >> Best Regards > >> >> Ian > >> >> > >> > > >> > > >> > > >> > -- > >> > Carsten Ziegeler > >> > cziege...@apache.org > >> > > > > > > > > -- > > Carsten Ziegeler > > cziege...@apache.org > -- Carsten Ziegeler cziege...@apache.org
Re: JobQueue provider ?
Yeah, maybe - in fact it's a whitelist and a blacklist or inclusion/exclusion list :) In any case, we released the module already - so the name will stick :) Carsten 2013/9/4 Bertrand Delacretaz > On Tue, Sep 3, 2013 at 7:43 PM, Carsten Ziegeler > wrote: > > ...actually black listing is exactly for these use cases. It gives you > > control which instance is able to handle what jobs. So you can exclude a > > specific instance from processing a specific job, in your use case you > > exclude all but one. > > This is not blacklisting of event handlers if you're refering to that > one... > > So maybe blacklisting is not the right term in the context of jobs? > > IIUC this setting just causes some jobs to be ignored on some nodes, > so it could be just "ignored" instead of "blacklisted". > > -Bertrand > -- Carsten Ziegeler cziege...@apache.org
Re: JobQueue provider ?
Yes, I see your point - and partially agree :) However, the notion of a queue is slightly misleading here - in fact, the real queue is the content stored at a specific location in the resource tree - the location includes the sling instance id, the job topic. The java queue implementation is "just" the execution queue on a single instance - so for example if we would provide an implementation executing jobs via JMS, this wouldn't be a new queue implementation, but would require a different distribution mechanism. In fact, I plan to get away with the queue implementations completely and just have the queues in the resource tree with a simple implementation just picking the "next" job resource from the resource tree and executing it. Carsten 2013/9/4 Ian Boston > Hi, > Thanks for taking the time to explain the approach/work arround, I'll > give it a go. > I still think that it would be better to provide some mechanism to add > a queue behaviour without requiring the bundle to be re-released, as I > don't think we can predict every downstream use case in advance. > However I don't have a concrete requirement at this stage. > Best Regards > Ian > > On 4 September 2013 08:53, Carsten Ziegeler wrote: > > Yeah, maybe - in fact it's a whitelist and a blacklist or > > inclusion/exclusion list :) > > In any case, we released the module already - so the name will stick :) > > > > Carsten > > > > > > 2013/9/4 Bertrand Delacretaz > > > >> On Tue, Sep 3, 2013 at 7:43 PM, Carsten Ziegeler > >> wrote: > >> > ...actually black listing is exactly for these use cases. It gives you > >> > control which instance is able to handle what jobs. So you can > exclude a > >> > specific instance from processing a specific job, in your use case you > >> > exclude all but one. > >> > This is not blacklisting of event handlers if you're refering to that > >> one... > >> > >> So maybe blacklisting is not the right term in the context of jobs? > >> > >> IIUC this setting just causes some jobs to be ignored on some nodes, > >> so it could be just "ignored" instead of "blacklisted". > >> > >> -Bertrand > >> > > > > > > > > -- > > Carsten Ziegeler > > cziege...@apache.org > -- Carsten Ziegeler cziege...@apache.org
Re: Adding a "usage" service property to BindingsValuesProvider ?
What about defining a service (whatever name :) ) that has something like a:
applyBindings(Bindings b , String context)
method?
Internally this service can do whatever magic it has to do, like looking up
all BVPs with the specified context attribute set etc.
You prefill your bindings with the objs you think that should be there
before calling that service.
If you want to support multiple contexts, simply call this method more than
once with the different context names.
Carsten
2013/9/5 Bertrand Delacretaz
> Hi Justin,
>
> On Tuesday, August 6, 2013, Justin Edelson wrote:
>
> > ...Whereas today you do:
> > ScriptEngineManager.getEngineByExtension("ecma")
> >
> > You could do
> > ScriptEngineManager.getEngineByExtension("ecma", ["healthcheck",
> "workflow"]) ...
>
> FYI, I'm getting back to this (SLING-3038) and the above won't work for my
> use case, as I need to setup some initial Bindings that provide context
> objects, before calling BindingValuesProvider.addBindings(...).
>
> The scenario that I'm considering is:
>
> String context = "healthcheck"; // I don't think we need multiple
> contexts??
> ScriptEngine engine = scriptEngineManager.getEngineByExtension("foo");
> Bindings b = engine.createBindings();
> b.put("bar", new SomethingThatOtherBindingsNeed());
> for(BindingValuesProvider bvp : someProvider.getBindings(engine, context))
> {
> bvp.addBindings(b);
> }
>
> where someProvider is a new service that I'm afraid might be called
> BindingValuesProviderProvider...suggestions welcome ;-)
>
> In the above loop, some BVPs use the "bar" object to create their bound
> objects, as we already do with the BVP that provides "currentNode" if
> there's a "resource" bound when it's called.
>
> -Bertrand
>
--
Carsten Ziegeler
cziege...@apache.org
Re: Adding a "usage" service property to BindingsValuesProvider ?
If you need to know the language, can't we pass this as a string into the service? Other than that, add sounds good to me (don't know why I picked apply anyway...) Carsten 2013/9/5 Bertrand Delacretaz > On Thu, Sep 5, 2013 at 10:14 AM, Carsten Ziegeler > wrote: > > What about defining a service (whatever name :) ) that has something > like a: > > applyBindings(Bindings b , String context) > > method?... > > Maybe > > addContextBindings(Bindings b, ScriptEngineFactory f, String context) > > As the ScriptEngineFactory is needed to know what the current language > is, and "add" for consistent naming with the existing > BindingsValuesProvider.addBindings(Bindings b) method. > > WDYT? > > -Bertrand > -- Carsten Ziegeler cziege...@apache.org
Re: Adding a "usage" service property to BindingsValuesProvider ?
As our api is in the api bundle, well api it is :) The package version will be 2.2.0 as this is adding new api Carsten 2013/9/5 Bertrand Delacretaz > On Thursday, September 5, 2013, Carsten Ziegeler wrote: > > > If you need to know the language, can't we pass this as a string into the > > service?... > > It's not only the language, some other ScriptEngineFactory metadata such as > compatible.javax.script.name is used. > > Now, where should that new service interface go, scripting.api bundle or > scripting.core? > > I'd say scripting.api, and we bump the API package's version to 2.1.1 (from > the current 2.1.0). > > -Bertrand > -- Carsten Ziegeler cziege...@apache.org
[VOTE RESULT] Parent POM 18
The vote was successful with 5 binding +1 votes No other votes have been cast Thanks for voting Regards Carsten -- Carsten Ziegeler cziege...@apache.org
Re: Managing Queues based on Topology ?
Hi Ian, no, you don't implement a PropertyProvider for this - this is done by the job implementation for you (JobConsumerManager). The JobConsumerManager collects all active JobConsumer queries their supported topics and provides this information through the topology by registering the PropertyProvider. Basically, you have three choices: either you disable the job consumer on an instance, you change the topics registration property of that service or the consumer manager allows to configure whitelist and blacklist topics. Which in most cases is the easiest solution. A topology change causes the job handling to restart, if you do a consumer change based on that, this results in a new topology event and the job handler will restart again. At least that's how it is implemented right now, as this is the easiest way of implementing it. However, the restart comes with a delay, so if the additional events happen within this delay, you end up with exactly one restart (this is why we have the delay). Regards Carsten 2013/9/6 Ian Boston > Hi, > (Probably a question for Carsten). > > Is the right way to implement topology based queue exclusion by > implementing a topology discovery PropertyProvider that provides the > property: > > org.apache.sling.event.jobs.consumer.topics > > containing a , separated list of topics the instance can handle. > > If so I have 2 questions: > > Since this list is topology dependent (depends on which is master) and > will itself have to be generated after a topology change which may > take some time to filter through the discovery hub spoke > implementation, will it cause the Job Queue to restart multiple times > on a relevant property change. ? > > Also, how are Topics excluded from a list of capabilities for each > instance. I have read through the code in the constructor of > TopologyCapabilities and the getPotentialTargets, detectTartgets and I > cant see how to exclude a topic from an instance, only how to include. > What is the best way of excluding a topic from a instance without > having to whitelist all known topics. ? > > Best Regards > Ian > -- Carsten Ziegeler cziege...@apache.org
Re: Managing Queues based on Topology ?
Hmm, I would rather get the configuration dictionary from the config admin and update that Carsten 2013/9/6 Ian Boston > I meant serviceRegistration not serviceReference, but I cant get it > seems like its not possible to get hold of a serviceRegistration from > another bundle. > > On 6 September 2013 13:31, Ian Boston wrote: > > Hi, > > Just to be clear you are saying programatically manipulate the OSGi > > configuration of the JobConsumerManager when an instance initialises > > or transitions from master<->slave ? > > > > eg > > > > on a topology change > > get a serviceReference to the JobConsumerManager > > using serviceReference.setProperties(Dictionary) > > set a blacklist appropriate to the master/slave status > > of the instance. > > > > > > I am assuming I don't need to worry about the other OSGi properties, > > however the JavaDoc on setProperties is not explicit on what happens > > to properties that are not set ? > > > > I am also assuming this wont interact badly with any stored > > configuration state ? > > > > Best Regards > > Ian > > > > On 6 September 2013 12:35, Ian Boston wrote: > >> Cool, thanks, > >> I'll go down the route you suggest. > >> Ian > >> > >> On 6 September 2013 11:45, Carsten Ziegeler > wrote: > >>> Hi Ian, > >>> > >>> no, you don't implement a PropertyProvider for this - this is done by > the > >>> job implementation for you (JobConsumerManager). > >>> The JobConsumerManager collects all active JobConsumer queries their > >>> supported topics and provides this information through the topology by > >>> registering the PropertyProvider. > >>> Basically, you have three choices: either you disable the job consumer > on > >>> an instance, you change the topics registration property of that > service or > >>> the consumer manager allows to configure whitelist and blacklist > topics. > >>> Which in most cases is the easiest solution. > >>> A topology change causes the job handling to restart, if you do a > consumer > >>> change based on that, this results in a new topology event and the job > >>> handler will restart again. At least that's how it is implemented right > >>> now, as this is the easiest way of implementing it. However, the > restart > >>> comes with a delay, so if the additional events happen within this > delay, > >>> you end up with exactly one restart (this is why we have the delay). > >>> > >>> Regards > >>> Carsten > >>> > >>> > >>> 2013/9/6 Ian Boston > >>> > >>>> Hi, > >>>> (Probably a question for Carsten). > >>>> > >>>> Is the right way to implement topology based queue exclusion by > >>>> implementing a topology discovery PropertyProvider that provides the > >>>> property: > >>>> > >>>> org.apache.sling.event.jobs.consumer.topics > >>>> > >>>> containing a , separated list of topics the instance can handle. > >>>> > >>>> If so I have 2 questions: > >>>> > >>>> Since this list is topology dependent (depends on which is master) and > >>>> will itself have to be generated after a topology change which may > >>>> take some time to filter through the discovery hub spoke > >>>> implementation, will it cause the Job Queue to restart multiple times > >>>> on a relevant property change. ? > >>>> > >>>> Also, how are Topics excluded from a list of capabilities for each > >>>> instance. I have read through the code in the constructor of > >>>> TopologyCapabilities and the getPotentialTargets, detectTartgets and I > >>>> cant see how to exclude a topic from an instance, only how to include. > >>>> What is the best way of excluding a topic from a instance without > >>>> having to whitelist all known topics. ? > >>>> > >>>> Best Regards > >>>> Ian > >>>> > >>> > >>> > >>> > >>> -- > >>> Carsten Ziegeler > >>> cziege...@apache.org > -- Carsten Ziegeler cziege...@apache.org
Re: Managing Queues based on Topology ?
In general yes, but not for the Job Consumer Manager - the configuration has a special property set which excludes it from writing back to the repository and therefore distributing it Carsten 2013/9/6 Ian Boston > If the config is stored in the repository, wont that propagate from > master to slave and visa versa ? > The JavaDocs on Configuration.update(Dictionary) say changes are stored. > > On 6 September 2013 13:40, Carsten Ziegeler wrote: > > Hmm, I would rather get the configuration dictionary from the config > admin > > and update that > > > > Carsten > > > > > > 2013/9/6 Ian Boston > > > >> I meant serviceRegistration not serviceReference, but I cant get it > >> seems like its not possible to get hold of a serviceRegistration from > >> another bundle. > >> > >> On 6 September 2013 13:31, Ian Boston wrote: > >> > Hi, > >> > Just to be clear you are saying programatically manipulate the OSGi > >> > configuration of the JobConsumerManager when an instance initialises > >> > or transitions from master<->slave ? > >> > > >> > eg > >> > > >> > on a topology change > >> > get a serviceReference to the JobConsumerManager > >> > using serviceReference.setProperties(Dictionary) > >> > set a blacklist appropriate to the master/slave status > >> > of the instance. > >> > > >> > > >> > I am assuming I don't need to worry about the other OSGi properties, > >> > however the JavaDoc on setProperties is not explicit on what happens > >> > to properties that are not set ? > >> > > >> > I am also assuming this wont interact badly with any stored > >> > configuration state ? > >> > > >> > Best Regards > >> > Ian > >> > > >> > On 6 September 2013 12:35, Ian Boston wrote: > >> >> Cool, thanks, > >> >> I'll go down the route you suggest. > >> >> Ian > >> >> > >> >> On 6 September 2013 11:45, Carsten Ziegeler > >> wrote: > >> >>> Hi Ian, > >> >>> > >> >>> no, you don't implement a PropertyProvider for this - this is done > by > >> the > >> >>> job implementation for you (JobConsumerManager). > >> >>> The JobConsumerManager collects all active JobConsumer queries their > >> >>> supported topics and provides this information through the topology > by > >> >>> registering the PropertyProvider. > >> >>> Basically, you have three choices: either you disable the job > consumer > >> on > >> >>> an instance, you change the topics registration property of that > >> service or > >> >>> the consumer manager allows to configure whitelist and blacklist > >> topics. > >> >>> Which in most cases is the easiest solution. > >> >>> A topology change causes the job handling to restart, if you do a > >> consumer > >> >>> change based on that, this results in a new topology event and the > job > >> >>> handler will restart again. At least that's how it is implemented > right > >> >>> now, as this is the easiest way of implementing it. However, the > >> restart > >> >>> comes with a delay, so if the additional events happen within this > >> delay, > >> >>> you end up with exactly one restart (this is why we have the delay). > >> >>> > >> >>> Regards > >> >>> Carsten > >> >>> > >> >>> > >> >>> 2013/9/6 Ian Boston > >> >>> > >> >>>> Hi, > >> >>>> (Probably a question for Carsten). > >> >>>> > >> >>>> Is the right way to implement topology based queue exclusion by > >> >>>> implementing a topology discovery PropertyProvider that provides > the > >> >>>> property: > >> >>>> > >> >>>> org.apache.sling.event.jobs.consumer.topics > >> >>>> > >> >>>> containing a , separated list of topics the instance can handle. > >> >>>> > >> >>>> If so I have 2 questions: > >> >>>> > >> >>>> Since this list is topology dependent (depends on which is master) > and > >> >>>> will itself have to be generated after a topology change which may > >> >>>> take some time to filter through the discovery hub spoke > >> >>>> implementation, will it cause the Job Queue to restart multiple > times > >> >>>> on a relevant property change. ? > >> >>>> > >> >>>> Also, how are Topics excluded from a list of capabilities for each > >> >>>> instance. I have read through the code in the constructor of > >> >>>> TopologyCapabilities and the getPotentialTargets, detectTartgets > and I > >> >>>> cant see how to exclude a topic from an instance, only how to > include. > >> >>>> What is the best way of excluding a topic from a instance without > >> >>>> having to whitelist all known topics. ? > >> >>>> > >> >>>> Best Regards > >> >>>> Ian > >> >>>> > >> >>> > >> >>> > >> >>> > >> >>> -- > >> >>> Carsten Ziegeler > >> >>> cziege...@apache.org > >> > > > > > > > > -- > > Carsten Ziegeler > > cziege...@apache.org > -- Carsten Ziegeler cziege...@apache.org
Re: Managing Queues based on Topology ?
Sorry, not slightly correct - if you create the configuration for the first time, make sure to set the property "org.apache.sling.installer.configuration.persist" to the value "false" Carsten 2013/9/6 Carsten Ziegeler > In general yes, but not for the Job Consumer Manager - the configuration > has a special property set which excludes it from writing back to the > repository and therefore distributing it > > Carsten > > > 2013/9/6 Ian Boston > >> If the config is stored in the repository, wont that propagate from >> master to slave and visa versa ? >> The JavaDocs on Configuration.update(Dictionary) say changes are stored. >> >> On 6 September 2013 13:40, Carsten Ziegeler wrote: >> > Hmm, I would rather get the configuration dictionary from the config >> admin >> > and update that >> > >> > Carsten >> > >> > >> > 2013/9/6 Ian Boston >> > >> >> I meant serviceRegistration not serviceReference, but I cant get it >> >> seems like its not possible to get hold of a serviceRegistration from >> >> another bundle. >> >> >> >> On 6 September 2013 13:31, Ian Boston wrote: >> >> > Hi, >> >> > Just to be clear you are saying programatically manipulate the OSGi >> >> > configuration of the JobConsumerManager when an instance initialises >> >> > or transitions from master<->slave ? >> >> > >> >> > eg >> >> > >> >> > on a topology change >> >> > get a serviceReference to the JobConsumerManager >> >> > using serviceReference.setProperties(Dictionary) >> >> > set a blacklist appropriate to the master/slave >> status >> >> > of the instance. >> >> > >> >> > >> >> > I am assuming I don't need to worry about the other OSGi properties, >> >> > however the JavaDoc on setProperties is not explicit on what happens >> >> > to properties that are not set ? >> >> > >> >> > I am also assuming this wont interact badly with any stored >> >> > configuration state ? >> >> > >> >> > Best Regards >> >> > Ian >> >> > >> >> > On 6 September 2013 12:35, Ian Boston wrote: >> >> >> Cool, thanks, >> >> >> I'll go down the route you suggest. >> >> >> Ian >> >> >> >> >> >> On 6 September 2013 11:45, Carsten Ziegeler >> >> wrote: >> >> >>> Hi Ian, >> >> >>> >> >> >>> no, you don't implement a PropertyProvider for this - this is done >> by >> >> the >> >> >>> job implementation for you (JobConsumerManager). >> >> >>> The JobConsumerManager collects all active JobConsumer queries >> their >> >> >>> supported topics and provides this information through the >> topology by >> >> >>> registering the PropertyProvider. >> >> >>> Basically, you have three choices: either you disable the job >> consumer >> >> on >> >> >>> an instance, you change the topics registration property of that >> >> service or >> >> >>> the consumer manager allows to configure whitelist and blacklist >> >> topics. >> >> >>> Which in most cases is the easiest solution. >> >> >>> A topology change causes the job handling to restart, if you do a >> >> consumer >> >> >>> change based on that, this results in a new topology event and the >> job >> >> >>> handler will restart again. At least that's how it is implemented >> right >> >> >>> now, as this is the easiest way of implementing it. However, the >> >> restart >> >> >>> comes with a delay, so if the additional events happen within this >> >> delay, >> >> >>> you end up with exactly one restart (this is why we have the >> delay). >> >> >>> >> >> >>> Regards >> >> >>> Carsten >> >> >>> >> >> >>> >> >> >>> 2013/9/6 Ian Boston >> >> >>> >> >> >>>> Hi, >> >> >>>> (Probably a question for Carsten). >> >> >
[ANN] New committer: Oliver Lietz
The Project Management Committee (PMC) for Apache Slinghas asked Oliver Lietz to become a committer and we are pleased to announce that he has accepted. So please welcome Oliver as a committer! Being a committer enables easier contribution to theproject since there is no need to go via the patchsubmission process. This should enable better productivity.Being a PMC member enables assistance with the managementand to guide the direction of the project. Regards Carsten -- Carsten Ziegeler cziege...@apache.org
Re: Adding a "usage" service property to BindingsValuesProvider ?
The constants should really be defined in the BVP class, this is the service declaring them I don't understand what you mean by "changes to existing code" - this is new, isn't it? Carsten 2013/9/6 Bertrand Delacretaz > On Thu, Sep 5, 2013 at 1:28 PM, Bertrand Delacretaz > wrote: > > ...Maybe > > > > addContextBindings(Bindings b, ScriptEngineFactory f, String context) > > ... > > FYI I didn't do it like that in the end, as that would have caused > more changes than I like to existing code. The new service API is at > > https://svn.apache.org/repos/asf/sling/trunk/bundles/scripting/api/src/main/java/org/apache/sling/scripting/api/BindingsValuesProvidersByContext.java > > Apart from that this is now done, see SLING-3038 for details, > > -Bertrand > -- Carsten Ziegeler cziege...@apache.org
LogBack Support : Adding an appender without changing the log level
Hi, I'm having a look at the new logging support for logback appenders and it seems that I can only attach an Appender to a logger if I specify a log level as well. I have a use case where I just want to add an additional Appender to a logger - without influencing the log level. Is that possible? Regards Carsten -- Carsten Ziegeler cziege...@apache.org
Maven Bundle Plugin 2.4 causing problems
Hi, I updated today to the new parent pom 18 which is using latest Maven Bundle Plugin 2.4.0. Unfortunately this is now causing problems if DymamicImport-Package is used, you can see this in the auth.core bundle for example. With previous versions of the plugin, the Import-Package was calculated with taking DynamicImport-Package in mind, which means a package declared as dynamic import was not added to the import list. With 2.4.0 this changed, and the package is listed in both statements - while browsing through the docs, it looks to me, that this is the wanted behaviour nevertheless... I'Ve reverted those projects which use DynamicImport-Package (only a few) to use the older version of the plugin for now. But I think this is something we should follow up with the Felix project. Carsten -- Carsten Ziegeler cziege...@apache.org
Re: LogBack Support : Adding an appender without changing the log level
As an OSGi service, if I don't specify a log level, it's defaulted to INFO and thus changes the log level to INFO. I think it should be possible to just add an appender Carsten 2013/9/8 Chetan Mehrotra > How are you trying to add an additional appender. Via configuration or > dynamically as OSGi service [1]? > > [1] > https://github.com/chetanmeh/sling-logback#appenders-and-whiteboard-pattern > Chetan Mehrotra > > > On Fri, Sep 6, 2013 at 9:34 PM, Carsten Ziegeler > wrote: > > Hi, > > > > I'm having a look at the new logging support for logback appenders and it > > seems that I can only attach an Appender to a logger if I specify a log > > level as well. > > I have a use case where I just want to add an additional Appender to a > > logger - without influencing the log level. Is that possible? > > > > Regards > > Carsten > > -- > > Carsten Ziegeler > > cziege...@apache.org > -- Carsten Ziegeler cziege...@apache.org
Re: Can we generally drop Java 1.5 compatibility?
Yeah, I guess we could ask our users and if there are no concerns with going to Java 6 all over, let's simply do it. Updating to latest Sling on Java 5 isn't possible anyway as some modules use Java 6 already. Carsten 2013/9/10 Felix Meschberger > Hi > > That means setting sling.java.version=5 on *all* modules which do not > currently have sling.java.version=6 ? I would be fine with that. Then we > can still have an explicit action to actually drop Java 5. Otherwise we > have to analyze each and every bundle now. > > Otherwise: Maybe it is also time to take the next step and just go Java 6 > all over and not consider java 5 at all any longer ? > > Regards > Felix > > Am 10.09.2013 um 11:11 schrieb Bertrand Delacretaz: > > > Hi, > > > > I'm not sure if it's worth the effort keeping that anymore, examples > > like SLING-3042 and SLING-3049 show that it's increasingly getting in > > the way. > > > > IIRC we discussed recently and decided to keep it wherever possible. I > > suggest reversing that and saying that we keep it only for bundles > > where it requires no additional work, and drop it as soon as it's > > bothering us in some way. > > > > In practice, this might mean setting sling.java.version=6 in the > > parent pom, and overriding that with sling.java.version=5 in bundles > > where we feel that's needed. > > > > WDYT? > > > > -Bertrand > > -- Carsten Ziegeler cziege...@apache.org
Committers, please keep team site up to date
Hi, as a committer, please review http://sling.apache.org/project-information/project-team.html and keep it up to date with your information. If you're a new committer, please add yourself. Thanks Carsten -- Carsten Ziegeler cziege...@apache.org
Re: Committers, please keep team site up to date
Yeah, that's fine - I'm wondering how useful this information is anyway... :) Carsten 2013/9/17 Bertrand Delacretaz > On Tue, Sep 17, 2013 at 9:12 AM, Robert Munteanu wrote: > > ...I would either put in +2/+3 or Europe/Bucharest, with a slight > > preference for the latter... > > works for me! > -Bertrand > -- Carsten Ziegeler cziege...@apache.org
Re: [DISCUSS] move healthcheck under bundles/extensions and release as 0.9.0
Hi, I don't feel very strong for moving, but I'm not against it :) I think we can directly go with 1.0.0 release, at least for the modules who expose API. I'm +1 for releasing core and jmx and have no opinion about the others right now :) Carsten 2013/9/17 Bertrand Delacretaz > Hi, > > Coming back to this, is anyone opposed to > > a) moving the contrib/extensions/healthcheck module under > bundles/extensions/healthcheck ? > > b) releasing those modules as V0.9.0 ? > > I'm presenting the tool at adaptTo next week, would be nice to have a > first release. > > I'm resyncing the docs at > http://sling.apache.org/documentation/bundles/sling-health-check-tool.html > now to be consistent with the recent changes. > > -Bertrand > -- Carsten Ziegeler cziege...@apache.org
[VOTE] Drop the time zone info from committers page
Hi, I think we should drop the time zone information from the committers page. I think it doesn't serve any real purpose. Carsten -- Carsten Ziegeler cziege...@apache.org
Re: [VOTE] Drop the time zone info from committers page
+1 2013/9/17 Carsten Ziegeler > Hi, > > I think we should drop the time zone information from the committers page. > I think it doesn't serve any real purpose. > > Carsten > > -- > Carsten Ziegeler > cziege...@apache.org > -- Carsten Ziegeler cziege...@apache.org
[LogBack] Compatibility with current logging
Hi, while trying out the new logback based logging implementation I stumbled across the handling of the current configurations (pre logack impl): if these are used, then if I understand it correctly, a logger is configured with an appender and logger.setAdditive(false) is called which prevents going up the category hierarchy and calling other appenders. This is for compatibility, but imho defeats using a main feature of logback: being able to call mulitple appenders. Is my assumption so far correct? So right now, it seems to me, that we either break compatiblity here (which really shouldn't hurt) or require every user to migrate the configuration, which seems pointless to me. WDYT? Regards Carsten -- Carsten Ziegeler cziege...@apache.org
Re: [VOTE] Drop the time zone info from committers page
Thanks everyone for voting - I think we have enough +1s (and no other vote) So I'll go ahead and remove it Carsten 2013/9/18 Mike Müller > +1 > Best regards > mike > > > -Original Message- > > From: Felix Meschberger [mailto:fmesc...@adobe.com] > > Sent: Wednesday, September 18, 2013 10:00 AM > > To: dev@sling.apache.org > > Subject: Re: [VOTE] Drop the time zone info from committers page > > > > +1 > > > > Regards > > Felix > > > > Am 17.09.2013 um 19:33 schrieb Carsten Ziegeler: > > > > > Hi, > > > > > > I think we should drop the time zone information from the committers > page. > > > I think it doesn't serve any real purpose. > > > > > > Carsten > > > > > > -- > > > Carsten Ziegeler > > > cziege...@apache.org > > -- Carsten Ziegeler cziege...@apache.org
Re: [LogBack] Compatibility with current logging
Hi Chetan, yes, we should make the additivity configurable, defaulting to true for compatiblity sounds good. Thanks Carsten 2013/9/22 Chetan Mehrotra > Hi Carsten, > > Initially I did not set additivity for OSGi configured loggers to > true. That caused issue in some situations where a Sling based app > like CQ defines multiple fine grained config which logs output from > various loggers (request log, query log etc) to separate files. With > new Logback stuff all the logs were also getting recorded in error.log > (defined at root level) hence polluting it > > One thing we can do is add support for configuring additivity in OSGi > config also which by default is true. And then have an upgrade plugin > which can set the default value to false for config in an upgraded > system. > > regards > Chetan > Chetan Mehrotra > > > On Fri, Sep 20, 2013 at 12:05 PM, Carsten Ziegeler > wrote: > > Hi, > > > > while trying out the new logback based logging implementation I stumbled > > across the handling of the current configurations (pre logack impl): if > > these are used, then if I understand it correctly, a logger is configured > > with an appender and logger.setAdditive(false) is called which prevents > > going up the category hierarchy and calling other appenders. > > This is for compatibility, but imho defeats using a main feature of > > logback: being able to call mulitple appenders. > > Is my assumption so far correct? > > > > So right now, it seems to me, that we either break compatiblity here > (which > > really shouldn't hurt) or require every user to migrate the > configuration, > > which seems pointless to me. > > > > WDYT? > > > > Regards > > Carsten > > -- > > Carsten Ziegeler > > cziege...@apache.org > -- Carsten Ziegeler cziege...@apache.org
Re: Resource merging and symlinks - two similar patches, do we unify?
While these are similar concerns, they are different - the symlink stuff (yes, I use the shorter name) creates a new tree based on an existing one and this can be overwritten/changed. The merging approach merges two (or more resources) into a single one - again using a new sub tree. Not quiet the same - but we might be able to share code / functionality Carsten 2013/9/27 Julian Sedding > Hi Betrand > > Agreed. I took a quick glimpse at the code for SLING-2986. My > impression is, that the two contributions should be largely > complementary. > > The focus of SLING-1778 is currently about "mounting" existing > resource (sub-)trees to arbitrary locations in the resource tree. The > merging aspect is currently on per-node granularity (IIRC). In > SLING-2986, the merging aspect seems to have been the main focus (e.g. > sling:hideProperties etc.). > > Regards > Julian > > On Fri, Sep 27, 2013 at 9:40 AM, Bertrand Delacretaz > wrote: > > Hi, > > > > With SLING-1778 and SLING-2986 we have two contributions that allow > > for partial merging/shadowing of resources. > > > > I haven't looked at the code in detail yet but it looks like a single > > extension should cover both use cases. > > > > IIUC, both are about about taking into account another resource B when > > looking at resource A, and using B as a default tree for A, optionally > > overridable. > > > > WDYT? > > > > (let's discuss the name of that feature in a separate thread once we > > agree on how to tackle it) > > > > -Bertrand > -- Carsten Ziegeler cziege...@apache.org
Re: [DISCUSS] ModifiableValueMap java.util.Date Handling
I'm not sure :) One can argue that it's up to the implementation how it stores data. So if I put a date into a MVM and later on read the resource and get the value, I expect a date to be returned. So from a documentation pov, a MVM supports all serializable types - and should ensure that the type you put is the type you get. Carsten 2013/9/26 Daniel Klco > When setting a java.util.Date as the value in the ModifiableValueMap, the > Date object is serialized and saved as the value. This seems like odd > functionality, as java.util.Calendar is supported and the internal datatype > is called 'date'. > > I understand that the reason is that internally the JCR uses > java.util.Calendars to store and access dates, but it's just not a very > intuitive thing to happen. I think one (or more) of the three things > should happen to make the functionality more intuitive: > > - The JavaDocs for the ModifiableValueMap should list the supported types > and what happens when an unsupported type is encountered. This will mean > that all implementations of the ModifiableValueMap will need to support the > same types. > > - The ModifiableValueMap implementations should throw a > java.lang.IllegalArgumentException if an invalid value type is specified. > Of course this is going to require more error checking and definitely > requires some additional documentation. > > - The ModifiableValueMap should have a method for retrieving the supported > types based on the ResourceProvider being used. > > - The JcrModifiableValueMap (and other implementations) should attempt to > coerce reasonable values. For example: java.util.Date -> > java.util.Calendar, byte[] -> InputStream > > Personally, I like a combination of all four options. What do you think? > > Regards, > Dan > -- Carsten Ziegeler cziege...@apache.org
Re: [VOTE] Initial Release of the Apache Sling Health Check Tools
+1 Carsten 2013/9/26 Mike Müller > +1, cool tools ;-) > Best regards > mike > > > -Original Message- > > From: Bertrand Delacretaz [mailto:bdelacre...@apache.org] > > Sent: Thursday, September 26, 2013 5:39 PM > > To: dev > > Subject: [VOTE] Initial Release of the Apache Sling Health Check Tools > > > > Hi, > > > > This is a vote for the initial release of the following Health Check > modules: > > > > org.apache.sling.hc.core-1.0.4 > > org.apache.sling.hc.it-1.0.4 > > org.apache.sling.hc.jmx-1.0.4 > > org.apache.sling.hc.samples-1.0.4 > > org.apache.sling.hc.support-1.0.4 > > org.apache.sling.hc.webconsole-1.0.4 > > org.apache.sling.junit.healthcheck-1.0.6 > > > > Versions are not 1.0.0 as I messed up some releases along the way > > (it's mostly maven -pl's fault). > > > > The docs are up to date at > > > http://sling.apache.org/documentation/bundles/sling-health-check-tool.html > > > > Staging repository: > > https://repository.apache.org/content/repositories/orgapachesling-101 > > > > You can use this UNIX script to download the release and verify the > signatures: > > http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh > > > > Usage: > > sh check_staged_release.sh 101 /tmp/sling-staging > > > > Please vote to approve this release: > > > > [ ] +1 Approve the release > > [ ] 0 Don't care > > [ ] -1 Don't release, because ... > > > > This vote will be open for at least 72 hours. > > > > -Bertrand > -- Carsten Ziegeler cziege...@apache.org
[VOTE] Release Apache Sling Commons Scheduler 2.4.0
Hi, it's time for a new scheduler release: Sling Commons Scheduler https://issues.apache.org/jira/browse/SLING/fixforversion/12319553 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-112/ You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 112 /tmp/sling-staging Please vote to approve this release: [ ] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... This vote will be open for 72 hours. Regards Carsten -- Carsten Ziegeler cziege...@apache.org
[VOTE] Release Apache Sling JMX Provider 0.5.0
Hi, please vote for the first release of our jmx provider which mounts jmx mbeans as resources into the resource tree. Staging repository: https://repository.apache.org/content/repositories/orgapachesling-113/ You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 113 /tmp/sling-staging Please vote to approve this release: [ ] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... This vote will be open for 72 hours. Regards Carsten -- Carsten Ziegeler cziege...@apache.org
Re: [VOTE] Release Apache Sling Commons Scheduler 2.4.0
+1 2013/10/1 Carsten Ziegeler > Hi, > > it's time for a new scheduler release: > > Sling Commons Scheduler > https://issues.apache.org/jira/browse/SLING/fixforversion/12319553 > > > > Staging repository: > https://repository.apache.org/content/repositories/orgapachesling-112/ > > You can use this UNIX script to download the release and verify the > signatures: > http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh > > Usage: > sh check_staged_release.sh 112 /tmp/sling-staging > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] 0 Don't care > [ ] -1 Don't release, because ... > > This vote will be open for 72 hours. > > Regards > Carsten > -- > Carsten Ziegeler > cziege...@apache.org > -- Carsten Ziegeler cziege...@apache.org
Re: [VOTE] Release Apache Sling Resource Inventory
+1 2013/10/1 Carsten Ziegeler > Hi, > > please vote for the first release of our resource inventory which allows > to add json of complete resource trees into the configuration zip. For > example this can be used in combination with the jmx provider to include > json of all mbeans into the config zip. > > > Staging repository: > https://repository.apache.org/content/repositories/orgapachesling-114/ > > You can use this UNIX script to download the release and verify the > signatures: > http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh > > Usage: > sh check_staged_release.sh 114 /tmp/sling-staging > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] 0 Don't care > [ ] -1 Don't release, because ... > > This vote will be open for 72 hours. > > Regards > Carsten > > -- > Carsten Ziegeler > cziege...@apache.org > -- Carsten Ziegeler cziege...@apache.org
Re: [VOTE] Release Apache Sling JMX Provider 0.5.0
+1 2013/10/1 Carsten Ziegeler > Hi, > > please vote for the first release of our jmx provider which mounts jmx > mbeans as resources into the resource tree. > > > Staging repository: > https://repository.apache.org/content/repositories/orgapachesling-113/ > > You can use this UNIX script to download the release and verify the > signatures: > http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh > > Usage: > sh check_staged_release.sh 113 /tmp/sling-staging > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] 0 Don't care > [ ] -1 Don't release, because ... > > This vote will be open for 72 hours. > > Regards > Carsten > -- > Carsten Ziegeler > cziege...@apache.org > -- Carsten Ziegeler cziege...@apache.org
[VOTE] Release Apache Sling Resource Inventory
Hi, please vote for the first release of our resource inventory which allows to add json of complete resource trees into the configuration zip. For example this can be used in combination with the jmx provider to include json of all mbeans into the config zip. Staging repository: https://repository.apache.org/content/repositories/orgapachesling-114/ You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 114 /tmp/sling-staging Please vote to approve this release: [ ] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... This vote will be open for 72 hours. Regards Carsten -- Carsten Ziegeler cziege...@apache.org
Re: [DISCUSS] Generic ServiceMap for ServiceResolver
Hi,
I'm not sure I completely understand your proposal. What's the difference
to looking up the MoveOperation (or other services) directly from the
service registry?
Carsten
2013/9/30 Mike Hummel
> Hi,
>
> with ResourceAccessSecurity there's the first service depending on the
> ServiceResolver and loaded by the ServiceTracker. For further services we
> should use a generic way to handle this.
>
> Another goal is that we can implement operations in this way for different
> ServiceResolver in a generic way. For example default operations like
> 'move' 'copy' 'checkout' 'checkin' can then be implemented for different
> Resources (jcr, mongodb).
>
> On next step it can be used by the post servlet to access it via REST.
>
> I implemented a try like this
>
> public interface ServiceMap {
>
>
> /**
>
> * Return the instance of the Service for the requested interface
>
> *
>
> * @param requestedInterface The Service or null if not found
>
> * @return
>
> */
>
> T getService(Class requestedInterface);
>
> }
>
> public interface ResourceResolver {
>
> …
>
> /**
>
> * Return the service map for this resolver.
>
> *
>
> * @return
>
> */
>
> ServiceMap getServiceMap();
>
> }
>
> To use a service use
>
> ResourceAccessSecurity service =
>
> resource.getResourceResolver().getServiceMap().getService(ResourceAccessSecurity.class);
>
> or maybe
>
> MoveOperation service =
>
> resource.getResourceResolver().getServiceMap().getService(MoveOperation.class);
> service.move(resource,targetPath);
>
> Ok, what's the goal?
>
> 1. We do not need to change resource providers if we initiate a new service
> for resources
> 2. A generic way to access operations if the service implement an
> Operation-Interface via REST / Post-Servlet
>
> What do you think?
>
> Mike
>
--
Carsten Ziegeler
cziege...@apache.org
Re: CWiki delete page permission
Hi Ian, I've added you to the sling-committers group Carsten 2013/10/2 Ian Boston > Hi, > I don't appear to have delete page permission on the Sling cwiki. I > tried yesterday to delete the spam but wasn't able to. > > Could someone grant me that permission please ? > Username is ieb > > Thanks > Ian > -- Carsten Ziegeler cziege...@apache.org
Re: CWiki delete page permission
I've now also corrected the permissions - and only people in the sling commiters group are allowed to edit pages now 2013/10/2 Carsten Ziegeler > Hi Ian, > > I've added you to the sling-committers group > > Carsten > > > 2013/10/2 Ian Boston > >> Hi, >> I don't appear to have delete page permission on the Sling cwiki. I >> tried yesterday to delete the spam but wasn't able to. >> >> Could someone grant me that permission please ? >> Username is ieb >> >> Thanks >> Ian >> > > > > -- > Carsten Ziegeler > cziege...@apache.org > -- Carsten Ziegeler cziege...@apache.org
Re: CWiki delete page permission
Done 2013/10/2 Robert Munteanu > Can you please add me to that group as well? I'm now missing > permission to edit pages. > > On Wed, Oct 2, 2013 at 11:22 AM, Carsten Ziegeler > wrote: > > I've now also corrected the permissions - and only people in the sling > > commiters group are allowed to edit pages now > > > > > > 2013/10/2 Carsten Ziegeler > > > >> Hi Ian, > >> > >> I've added you to the sling-committers group > >> > >> Carsten > >> > >> > >> 2013/10/2 Ian Boston > >> > >>> Hi, > >>> I don't appear to have delete page permission on the Sling cwiki. I > >>> tried yesterday to delete the spam but wasn't able to. > >>> > >>> Could someone grant me that permission please ? > >>> Username is ieb > >>> > >>> Thanks > >>> Ian > >>> > >> > >> > >> > >> -- > >> Carsten Ziegeler > >> cziege...@apache.org > >> > > > > > > > > -- > > Carsten Ziegeler > > cziege...@apache.org > > > > -- > Sent from my (old) computer > -- Carsten Ziegeler cziege...@apache.org
Re: [DISCUSS] Generic ServiceMap for ServiceResolver
Ok, so you're basically suggesting an extension mechanism comparable to the
adapter pattern?
Carsten
2013/10/2 Mike Hummel
> In my understanding the service registry is not able to differ between the
> resource implementations like mongo or jcr. If the operation is provided
> from the resource provider it is specialised for the underlying
> implementation.
>
> This is what you need for ResourceSecurityAccess or manipulating rights on
> the resource - without knowledge of the underlying data store.
>
>
> 2013/10/1 Carsten Ziegeler
>
> > Hi,
> >
> > I'm not sure I completely understand your proposal. What's the difference
> > to looking up the MoveOperation (or other services) directly from the
> > service registry?
> >
> > Carsten
> >
> >
> > 2013/9/30 Mike Hummel
> >
> > > Hi,
> > >
> > > with ResourceAccessSecurity there's the first service depending on the
> > > ServiceResolver and loaded by the ServiceTracker. For further services
> we
> > > should use a generic way to handle this.
> > >
> > > Another goal is that we can implement operations in this way for
> > different
> > > ServiceResolver in a generic way. For example default operations like
> > > 'move' 'copy' 'checkout' 'checkin' can then be implemented for
> different
> > > Resources (jcr, mongodb).
> > >
> > > On next step it can be used by the post servlet to access it via REST.
> > >
> > > I implemented a try like this
> > >
> > > public interface ServiceMap {
> > >
> > >
> > > /**
> > >
> > > * Return the instance of the Service for the requested interface
> > >
> > > *
> > >
> > > * @param requestedInterface The Service or null if not found
> > >
> > > * @return
> > >
> > > */
> > >
> > > T getService(Class requestedInterface);
> > >
> > > }
> > >
> > > public interface ResourceResolver {
> > >
> > > …
> > >
> > > /**
> > >
> > > * Return the service map for this resolver.
> > >
> > > *
> > >
> > > * @return
> > >
> > > */
> > >
> > > ServiceMap getServiceMap();
> > >
> > > }
> > >
> > > To use a service use
> > >
> > > ResourceAccessSecurity service =
> > >
> > >
> >
> resource.getResourceResolver().getServiceMap().getService(ResourceAccessSecurity.class);
> > >
> > > or maybe
> > >
> > > MoveOperation service =
> > >
> > >
> >
> resource.getResourceResolver().getServiceMap().getService(MoveOperation.class);
> > > service.move(resource,targetPath);
> > >
> > > Ok, what's the goal?
> > >
> > > 1. We do not need to change resource providers if we initiate a new
> > service
> > > for resources
> > > 2. A generic way to access operations if the service implement an
> > > Operation-Interface via REST / Post-Servlet
> > >
> > > What do you think?
> > >
> > > Mike
> > >
> >
> >
> >
> > --
> > Carsten Ziegeler
> > cziege...@apache.org
> >
>
--
Carsten Ziegeler
cziege...@apache.org
[VOTE] Apache Sling Auth Core 1.1.4 Release
Hi, I think it time for a new auth core release. We fixed a number of issues: https://issues.apache.org/jira/browse/SLING/fixforversion/12324311 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-125/ You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 125 /tmp/sling-staging Please vote to approve this release: [ ] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... This vote will be open for 72 hours. Regards -- Carsten Ziegeler cziege...@apache.org
Re: [VOTE] Apache Sling Auth Core 1.1.4 Release
+1 2013/10/3 Carsten Ziegeler > Hi, > > I think it time for a new auth core release. We fixed a number of issues: > > https://issues.apache.org/jira/browse/SLING/fixforversion/12324311 > > Staging repository: > https://repository.apache.org/content/repositories/orgapachesling-125/ > > You can use this UNIX script to download the release and verify the > signatures: > http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh > > Usage: > sh check_staged_release.sh 125 /tmp/sling-staging > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] 0 Don't care > [ ] -1 Don't release, because ... > > This vote will be open for 72 hours. > > Regards > > > -- > Carsten Ziegeler > cziege...@apache.org > -- Carsten Ziegeler cziege...@apache.org
Re: [ANN] New committer: Oliver Lietz
Done Carsten 2013/10/3 Oliver Lietz > Am Freitag, 6. September 2013 schrieb Carsten Ziegeler: > > The Project Management Committee (PMC) for Apache Slinghas asked > > Oliver Lietz to become a committer and we are pleased to announce that > > he has accepted. > > > > So please welcome Oliver as a committer! > > > > Being a committer enables easier contribution to theproject since > > there is no need to go via the patchsubmission process. This should > > enable better productivity.Being a PMC member enables assistance with > > the managementand to guide the direction of the project. > > hello Carsten, > > can you configure JIRA so I can assign issues to myself? > > thanks, > O. > > > Regards > > Carsten > -- Carsten Ziegeler cziege...@apache.org
Re: [DISCUSS] Generic ServiceMap for ServiceResolver
You can do: resourceResolver.adaptTo(YourService.class)
Regards
Carsten
2013/10/4 Mike Hummel
> Yes, I already thought about the same implemented with the adapter. But the
> Adapter should return an object representing the resources information. The
> ServiceMap should be used to provide services for the resource.
>
> If you can show me a way to do the same using adaptTo() then this
> discussion would be obsolete. Lets use the ResourceAccessSecurity example I
> see this options:
>
> 1. as discussed ResourceAccessSecurity ras =
>
> resource.getResourceResolver().getServices().getService(ResourceAccessSecurity.class);
>
> 2. direct via adaptTo() ResourceAccessSecurity ras =
> (ResourceAccessSecurity)resource.adaptTo(ResourceAccessSecurity.class)
>
> 3. via ServiceMap and adaptTo() ResourceAccessSecurity ras =
>
> ((ServiceMap)resource.adaptTo(ServiceMap.class)).getService(ResourceAccessSecurity.class)
>
> To have a clear coding I would prefer option 1. Number 2 is short but I'm
> not sure how much overhead it is to implement an adapter for every service.
>
>
>
>
>
> 2013/10/2 Carsten Ziegeler
>
> > Ok, so you're basically suggesting an extension mechanism comparable to
> the
> > adapter pattern?
> >
> > Carsten
> >
> >
> > 2013/10/2 Mike Hummel
> >
> > > In my understanding the service registry is not able to differ between
> > the
> > > resource implementations like mongo or jcr. If the operation is
> provided
> > > from the resource provider it is specialised for the underlying
> > > implementation.
> > >
> > > This is what you need for ResourceSecurityAccess or manipulating rights
> > on
> > > the resource - without knowledge of the underlying data store.
> > >
> > >
> > > 2013/10/1 Carsten Ziegeler
> > >
> > > > Hi,
> > > >
> > > > I'm not sure I completely understand your proposal. What's the
> > difference
> > > > to looking up the MoveOperation (or other services) directly from the
> > > > service registry?
> > > >
> > > > Carsten
> > > >
> > > >
> > > > 2013/9/30 Mike Hummel
> > > >
> > > > > Hi,
> > > > >
> > > > > with ResourceAccessSecurity there's the first service depending on
> > the
> > > > > ServiceResolver and loaded by the ServiceTracker. For further
> > services
> > > we
> > > > > should use a generic way to handle this.
> > > > >
> > > > > Another goal is that we can implement operations in this way for
> > > > different
> > > > > ServiceResolver in a generic way. For example default operations
> like
> > > > > 'move' 'copy' 'checkout' 'checkin' can then be implemented for
> > > different
> > > > > Resources (jcr, mongodb).
> > > > >
> > > > > On next step it can be used by the post servlet to access it via
> > REST.
> > > > >
> > > > > I implemented a try like this
> > > > >
> > > > > public interface ServiceMap {
> > > > >
> > > > >
> > > > > /**
> > > > >
> > > > > * Return the instance of the Service for the requested interface
> > > > >
> > > > > *
> > > > >
> > > > > * @param requestedInterface The Service or null if not found
> > > > >
> > > > > * @return
> > > > >
> > > > > */
> > > > >
> > > > > T getService(Class requestedInterface);
> > > > >
> > > > > }
> > > > >
> > > > > public interface ResourceResolver {
> > > > >
> > > > > …
> > > > >
> > > > > /**
> > > > >
> > > > > * Return the service map for this resolver.
> > > > >
> > > > > *
> > > > >
> > > > > * @return
> > > > >
> > > > > */
> > > > >
> > > > > ServiceMap getServiceMap();
> > > > >
> > > > > }
> > > > >
> > > > > To use a service use
> > > > >
> > > > > ResourceAccessSecurity service =
> > > > >
> > > > >
> > > >
> > >
> >
> resource.getResourceResolver().getServiceMap().getService(ResourceAccessSecurity.class);
> > > > >
> > > > > or maybe
> > > > >
> > > > > MoveOperation service =
> > > > >
> > > > >
> > > >
> > >
> >
> resource.getResourceResolver().getServiceMap().getService(MoveOperation.class);
> > > > > service.move(resource,targetPath);
> > > > >
> > > > > Ok, what's the goal?
> > > > >
> > > > > 1. We do not need to change resource providers if we initiate a new
> > > > service
> > > > > for resources
> > > > > 2. A generic way to access operations if the service implement an
> > > > > Operation-Interface via REST / Post-Servlet
> > > > >
> > > > > What do you think?
> > > > >
> > > > > Mike
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Carsten Ziegeler
> > > > cziege...@apache.org
> > > >
> > >
> >
> >
> >
> > --
> > Carsten Ziegeler
> > cziege...@apache.org
> >
>
--
Carsten Ziegeler
cziege...@apache.org
Re: ResourceProviderFactory vs. ResourceProvider Question
Hi, if you use a factory, once resources from this factory are hit, an instance for the current resource resolver is created exclusively for this resource resolver. As resource resolvers are not thread safe, they shouldn't be used from different threads (at least not concurrently) and therefore the same applies for resource provider instances created by a factory. These instances are never pooled etc, once a resolver is closed, they are freed. Whereas if you register a ResourceProvider directly, this is a singleton which can be used concurrently. In addition if you choose a RPFactory you can implement more functionality as some of the extension interfaces of the RP interface are only used if the instance is created via a factory. Regards Carsten 2013/10/3 dan mcweeney > I've been implementing the ResourceProviderFactory and wanted to find out > if the providers that are returned from the factory are ever used by > different threads or ever dropped into a pool and reused. Are there any > differences between registering a Factory vs. just registering the provider > that I need to be aware of? > > I did some testing and seems like they are never reused nor used by > multiple threads but, I just wanted to confirm my anecdotal testing. > > -d > -- Carsten Ziegeler cziege...@apache.org
Re: [VOTE] Release Apache Sling Commons Scheduler 2.4.0
We're missing one binding vote, anyone? 2013/10/1 Ian Boston > +1 > Ian > > On 1 October 2013 11:02, Carsten Ziegeler wrote: > > +1 > > > > > > 2013/10/1 Carsten Ziegeler > > > >> Hi, > >> > >> it's time for a new scheduler release: > >> > >> Sling Commons Scheduler > >> https://issues.apache.org/jira/browse/SLING/fixforversion/12319553 > >> > >> > >> > >> Staging repository: > >> https://repository.apache.org/content/repositories/orgapachesling-112/ > >> > >> You can use this UNIX script to download the release and verify the > >> signatures: > >> http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh > >> > >> Usage: > >> sh check_staged_release.sh 112 /tmp/sling-staging > >> > >> Please vote to approve this release: > >> > >> [ ] +1 Approve the release > >> [ ] 0 Don't care > >> [ ] -1 Don't release, because ... > >> > >> This vote will be open for 72 hours. > >> > >> Regards > >> Carsten > >> -- > >> Carsten Ziegeler > >> cziege...@apache.org > >> > > > > > > > > -- > > Carsten Ziegeler > > cziege...@apache.org > -- Carsten Ziegeler cziege...@apache.org
Re: [VOTE] Release Apache Sling Resource Inventory
We're missing one binding vote, anyone? 2013/10/1 Ian Boston > +1 > Ian > > On 1 October 2013 15:09, Daniel Klco wrote: > > +1 > > > > > > On Tue, Oct 1, 2013 at 6:02 AM, Carsten Ziegeler >wrote: > > > >> +1 > >> > >> > >> 2013/10/1 Carsten Ziegeler > >> > >> > Hi, > >> > > >> > please vote for the first release of our resource inventory which > allows > >> > to add json of complete resource trees into the configuration zip. For > >> > example this can be used in combination with the jmx provider to > include > >> > json of all mbeans into the config zip. > >> > > >> > > >> > Staging repository: > >> > > https://repository.apache.org/content/repositories/orgapachesling-114/ > >> > > >> > You can use this UNIX script to download the release and verify the > >> > signatures: > >> > http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh > >> > > >> > Usage: > >> > sh check_staged_release.sh 114 /tmp/sling-staging > >> > > >> > Please vote to approve this release: > >> > > >> > [ ] +1 Approve the release > >> > [ ] 0 Don't care > >> > [ ] -1 Don't release, because ... > >> > > >> > This vote will be open for 72 hours. > >> > > >> > Regards > >> > Carsten > >> > > >> > -- > >> > Carsten Ziegeler > >> > cziege...@apache.org > >> > > >> > >> > >> > >> -- > >> Carsten Ziegeler > >> cziege...@apache.org > >> > -- Carsten Ziegeler cziege...@apache.org
Re: [VOTE] Release Apache Sling JMX Provider 0.5.0
We're missing one binding vote, anyone? 2013/10/1 Ian Boston > +1 > Ian > > On 1 October 2013 15:12, Daniel Klco wrote: > > +1 > > > > > > On Tue, Oct 1, 2013 at 6:02 AM, Carsten Ziegeler >wrote: > > > >> +1 > >> > >> > >> 2013/10/1 Carsten Ziegeler > >> > >> > Hi, > >> > > >> > please vote for the first release of our jmx provider which mounts jmx > >> > mbeans as resources into the resource tree. > >> > > >> > > >> > Staging repository: > >> > > https://repository.apache.org/content/repositories/orgapachesling-113/ > >> > > >> > You can use this UNIX script to download the release and verify the > >> > signatures: > >> > http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh > >> > > >> > Usage: > >> > sh check_staged_release.sh 113 /tmp/sling-staging > >> > > >> > Please vote to approve this release: > >> > > >> > [ ] +1 Approve the release > >> > [ ] 0 Don't care > >> > [ ] -1 Don't release, because ... > >> > > >> > This vote will be open for 72 hours. > >> > > >> > Regards > >> > Carsten > >> > -- > >> > Carsten Ziegeler > >> > cziege...@apache.org > >> > > >> > >> > >> > >> -- > >> Carsten Ziegeler > >> cziege...@apache.org > >> > -- Carsten Ziegeler cziege...@apache.org
Re: Karaf features in Launchpad
Hi, you can define partial bundle list and then have a final launchpad project aggregate those by listing them as dependencies in the pom. This would do the trick I guess. However, reusing others work seems like a good idea to me. So if it's feasable, adding support for such features sounds interesting to me. Carsten 2013/10/1 Vidar Ramdal > I'm assembling a Sling Launchpad application, and I'm experiencing > that the Launchpad bundle list is becoming long and difficult to > manage. > > For example, adding Hibernate support requires adding a considerable > number of bundles, to different start levels. Adding other stuff > requires adding more bundles, to the same or different start levels. > > In Apache Karaf, this problem has been solved with features [1]. > > It would be useful if the Launchpad bundle list could support Karaf > feature descriptors, preferably also supporting Karaf's URL handlers > (particularly wrap:). > > Would there be interest in extending the Launchpad bundle list format > to support something like Karaf features? If so, I'll create I Jira > and try to find time to work in it. > > Or does the Launchpad already support something similar? > > Just to clarify: This is not about running Sling in a Karaf runtime, > but rather, using Karaf features with the Sling Launchpad. > > [1] > http://karaf.apache.org/manual/latest-2.3.x/users-guide/provisioning.html > -- > Vidar S. Ramdal > Webstep AS - http://www.webstep.no > Besøksadresse: Lilleakerveien 8, 0283 Oslo > Postadresse: Postboks 272 Lilleaker, 0216 Oslo > -- Carsten Ziegeler cziege...@apache.org
Re: [VOTE] Release Apache Sling Commons Scheduler 2.4.0
Ping 2013/10/4 Carsten Ziegeler > We're missing one binding vote, anyone? > > > 2013/10/1 Ian Boston > >> +1 >> Ian >> >> On 1 October 2013 11:02, Carsten Ziegeler wrote: >> > +1 >> > >> > >> > 2013/10/1 Carsten Ziegeler >> > >> >> Hi, >> >> >> >> it's time for a new scheduler release: >> >> >> >> Sling Commons Scheduler >> >> https://issues.apache.org/jira/browse/SLING/fixforversion/12319553 >> >> >> >> >> >> >> >> Staging repository: >> >> https://repository.apache.org/content/repositories/orgapachesling-112/ >> >> >> >> You can use this UNIX script to download the release and verify the >> >> signatures: >> >> http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh >> >> >> >> Usage: >> >> sh check_staged_release.sh 112 /tmp/sling-staging >> >> >> >> Please vote to approve this release: >> >> >> >> [ ] +1 Approve the release >> >> [ ] 0 Don't care >> >> [ ] -1 Don't release, because ... >> >> >> >> This vote will be open for 72 hours. >> >> >> >> Regards >> >> Carsten >> >> -- >> >> Carsten Ziegeler >> >> cziege...@apache.org >> >> >> > >> > >> > >> > -- >> > Carsten Ziegeler >> > cziege...@apache.org >> > > > > -- > Carsten Ziegeler > cziege...@apache.org > -- Carsten Ziegeler cziege...@apache.org
Re: [VOTE] Release Apache Sling Resource Inventory
Ping 2013/10/4 Carsten Ziegeler > We're missing one binding vote, anyone? > > > 2013/10/1 Ian Boston > >> +1 >> Ian >> >> On 1 October 2013 15:09, Daniel Klco wrote: >> > +1 >> > >> > >> > On Tue, Oct 1, 2013 at 6:02 AM, Carsten Ziegeler > >wrote: >> > >> >> +1 >> >> >> >> >> >> 2013/10/1 Carsten Ziegeler >> >> >> >> > Hi, >> >> > >> >> > please vote for the first release of our resource inventory which >> allows >> >> > to add json of complete resource trees into the configuration zip. >> For >> >> > example this can be used in combination with the jmx provider to >> include >> >> > json of all mbeans into the config zip. >> >> > >> >> > >> >> > Staging repository: >> >> > >> https://repository.apache.org/content/repositories/orgapachesling-114/ >> >> > >> >> > You can use this UNIX script to download the release and verify the >> >> > signatures: >> >> > http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh >> >> > >> >> > Usage: >> >> > sh check_staged_release.sh 114 /tmp/sling-staging >> >> > >> >> > Please vote to approve this release: >> >> > >> >> > [ ] +1 Approve the release >> >> > [ ] 0 Don't care >> >> > [ ] -1 Don't release, because ... >> >> > >> >> > This vote will be open for 72 hours. >> >> > >> >> > Regards >> >> > Carsten >> >> > >> >> > -- >> >> > Carsten Ziegeler >> >> > cziege...@apache.org >> >> > >> >> >> >> >> >> >> >> -- >> >> Carsten Ziegeler >> >> cziege...@apache.org >> >> >> > > > > -- > Carsten Ziegeler > cziege...@apache.org > -- Carsten Ziegeler cziege...@apache.org
Re: [VOTE] Release Apache Sling JMX Provider 0.5.0
Ping 2013/10/4 Carsten Ziegeler > We're missing one binding vote, anyone? > > > 2013/10/1 Ian Boston > >> +1 >> Ian >> >> On 1 October 2013 15:12, Daniel Klco wrote: >> > +1 >> > >> > >> > On Tue, Oct 1, 2013 at 6:02 AM, Carsten Ziegeler > >wrote: >> > >> >> +1 >> >> >> >> >> >> 2013/10/1 Carsten Ziegeler >> >> >> >> > Hi, >> >> > >> >> > please vote for the first release of our jmx provider which mounts >> jmx >> >> > mbeans as resources into the resource tree. >> >> > >> >> > >> >> > Staging repository: >> >> > >> https://repository.apache.org/content/repositories/orgapachesling-113/ >> >> > >> >> > You can use this UNIX script to download the release and verify the >> >> > signatures: >> >> > http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh >> >> > >> >> > Usage: >> >> > sh check_staged_release.sh 113 /tmp/sling-staging >> >> > >> >> > Please vote to approve this release: >> >> > >> >> > [ ] +1 Approve the release >> >> > [ ] 0 Don't care >> >> > [ ] -1 Don't release, because ... >> >> > >> >> > This vote will be open for 72 hours. >> >> > >> >> > Regards >> >> > Carsten >> >> > -- >> >> > Carsten Ziegeler >> >> > cziege...@apache.org >> >> > >> >> >> >> >> >> >> >> -- >> >> Carsten Ziegeler >> >> cziege...@apache.org >> >> >> > > > > -- > Carsten Ziegeler > cziege...@apache.org > -- Carsten Ziegeler cziege...@apache.org
