Re: [Status Update] Apache Cassandra backend for Sling

[Bertrand Delacretaz]

Hi Dishara,

On Tue, Jul 2, 2013 at 6:51 PM, Dishara Wijewardana
 wrote:
> ...Does each bundle in sling made to run their junit tests separately at build
> time...

Could you start new threads with new subject lines when you start a
new question or discussion?

Otherwise it's very hard to find things in our mailing list archives.

Thanks, and keep up the good work!
-Bertrand

Re: FYI, working on @AdapterMethod

[Bertrand Delacretaz]

On Tue, Jul 2, 2013 at 7:39 PM, Alexander Klimetschek
 wrote:
> Felix wrote:
>>> ...(3) Maybe we can find a better name for the AdapterMethodProvider 
>>> interface -- something
>>> which is more in line with the AdapterFactory service name.
>>
> What about simply "AdapterProvider"?...

Good idea, I'll change to that!
-Bertrand

[jira] [Commented] (SLING-2002) Migrate the Sling website to the ASF CMS

[Felix Meschberger (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-2002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13698716#comment-13698716
 ] 

Felix Meschberger commented on SLING-2002:
--

I have added more hints yet in Revs 1499230, 1499232, 1499237, 1499238:

* On the old site pages which can be traced to new pages I added a link to the 
new pages (yet hinting they are just migrated but not fully beautified yet).
* On the new pages, which still have corresponding pages under /site I finally 
added the "translation_pending" flag to indicate with a note box that there is 
work to be done and an old page still exists.

Some pages in the /site folder don't seem to have a correspondence in the new 
documentation. We need to find out, what's going on there. Maybe these are 
pages, which have been removed in the old Confluence-based site and did not 
exist any longer in the export for CMS.

> Migrate the Sling website to the ASF CMS
> 
>
> Key: SLING-2002
> URL: https://issues.apache.org/jira/browse/SLING-2002
> Project: Sling
>  Issue Type: Task
>  Components: Site
>Reporter: Bertrand Delacretaz
> Attachments: sling-site-2012-12-12.txt, 
> sling-site-from-confluence.tar.gz
>
>
> As discussed at http://markmail.org/thread/vbdqqnbaghpcxwp5
> I'll try the tools mentioned at 
> http://wiki.apache.org/general/ApacheCms2010#Migrating_from_Confluence

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Sling Posthandling - thougts about the current behavior

[Dominik Süß]

Hi Alex,

why do you think registering logic by path is bad. Especially if I look at
potential for multitenantsupport it would be great to be able to register
postbehavior that is tenantspecific. And the tenantsupport of Sling is
completely based on paths.

Regarding usage of Servlet Filters as pipelline I personally think this
could probably get a bit intransparent for develpers. As previously
mentioned the various phases should/would give the option to have a
contract about what can be done during that phase. A filterbased handling
just would give the option to control order of execution, but any filter
could break this "transactional" contract.
The injection of such a pipeline without the need to touch the existing
servlet could be done via a filter, but I think it would make sense to
optimize the current implementation when introducing such a mechanism.

Just my 2 cents
Dominik


On Tue, Jul 2, 2013 at 8:38 PM, Alexander Klimetschek wrote:

> Ack on the overall goal.
>
> The way I see it, it boils down to having the sling post servlet (or more
> specifically that new POST-pipeline) not "just" one special servlet out of
> many, but an integral part of Sling.
>
>
> Registering operations, post processors or whatever we need by resource
> type sounds good. By path not so much, don't know.
>
> IMHO, the rt would be taken from the addressed resource (what the URL
> addresses, to be 1:1 with how GET servlet resolution works; not any
> resources that additional request parameters might address) and if not
> present (creating a new resource) from the sling:resourceType param.
>
> It would actually be nice if those operations or postprocessor could
> become servlets or servlet filters again. They could get the necessary
> state passed via a request attribute for example + a utility to fetch them.
> And thinking about it, filters are actually the right thing, they are
> designed for pipelines.
>
> I am not sure if adding a :selector parameter as proposed by Justin
> (SLING-2936) is a good idea - maybe the integration with this new pipeline
> is the better long-term approach. You'd register by resource type + http
> method + :operation. Having both :operation and :selector (in the combined
> overall picture) seems like duplication. But it's difficult.
>
> It was mentioned that using selectors in the URL for POST requests, such
> as POST /content/page.createChild.html, is not RESTful. Is that really the
> case? As long as the server provides the URL instead of the client building
> it himself, such as  + ".createChild.html" as it happens way too
> much, and you use the right HTTP methods for changing/deleting content,
> nothing here would be unRESTful afaics.
>
> It would only look nicer if you put all the POST related information into
> the request parameters instead of into the URL. But then it's the old
> "action=create" topic again, which should be covered very well with the
> default features of the Sling post servlet already, which only requires you
> to add custom code (actions) for very specific things.
>
> This is even less once we have a validation framework in place (also
> resource type based), where Radu did a lot of work already!
>
> Cheers,
> Alex
>
>
> On 02.07.2013, at 15:26, Dominik Süß  wrote:
>
> > Well, if locking is just about permission I do agree with ACLs being the
> > right solution (the permission set on the node itself might be sufficient
> > for that case) - if it is about businessconstraints that need to be
> > fullfilled an ACL cannot solve this requirement[0]. This is why
> validation
> > and so on should be performed first, I would think of a pipeline having a
> > contract on each phase what can be done and what cannot be done, while a
> > first phase might not write any data (even as transient changes) the next
> > phase might be perform (transient) change, then the postoperations would
> be
> > performed in a transient followed by another phase that might perform
> > transient changes and/or stop the processing, followed by a last phase
> that
> > is called after the resourceResolve has performed a commit().
> >
> > This is purely about giving developers a contract on what they can and
> > cannot do (and therefore what they can expect 3rd party code to do) at a
> > specific point in this pipeline.
> >
> > [0] a businessconstraint to control sepecific operations by permissions
> > could be solved by a shadowstructure like proposed by Bertrand.
> >
> > --
> > Dominik
> >
> >
> > On Tue, Jul 2, 2013 at 2:47 PM, Bertrand Delacretaz
> > wrote:
> >
> >> On Tue, Jul 2, 2013 at 2:38 PM, Dominik Süß 
> >> wrote:
> >>> Facing some questions about how to prevent the SlingPostServlet to be
> >> able
> >>> to perform a change I had a closer look at the current implementation
> and
> >>> it looks like there is currently no "secure" way of doing that beside
> >>> locking the target on persistancelevel (alias setting ACLs)...
> >>
> >> ...which looks to me like the right way of locking things.
>

Re: Sling Posthandling - thougts about the current behavior

[Bertrand Delacretaz]

Hi,

On Wed, Jul 3, 2013 at 12:55 PM, Dominik Süß  wrote:
> ...why do you think registering logic by path is bad. Especially if I look at
> potential for multitenantsupport it would be great to be able to register
> postbehavior that is tenantspecific. And the tenantsupport of Sling is
> completely based on paths

In general we want people to get away from the notion that paths drive
your app, it should be resource types that do.

Also, the problem with paths is that they are usually hidden in code,
whereas resource types are transparently exposed in the content.

For the POST handling, we could very well take the resource type of
the parent/ancestors into account, instead of relying on paths.

-Bertrand

Re: Sling Posthandling - thougts about the current behavior

[Dominik Süß]

Hi Bertrand,

while I agree that paths should not drive the app they might build a scope
for the logic, since the content is organized in a tree structure and not
in by it's resourceType hierarchy, Therefore you often do have pathspecific
operations (just think of workflows and workflowlaunchers in CQ). Or to
come up with another scenario.
Changing resourceTypes depending on the location of the same data on the
other hand would be redundant information.

So - the main Driver should be the resourceType is what is defining the
behavior of a component while the contentpath in my eyes could act as
restricting criteria.

WDYT?


On Wed, Jul 3, 2013 at 1:22 PM, Bertrand Delacretaz
wrote:

> Hi,
>
> On Wed, Jul 3, 2013 at 12:55 PM, Dominik Süß 
> wrote:
> > ...why do you think registering logic by path is bad. Especially if I
> look at
> > potential for multitenantsupport it would be great to be able to register
> > postbehavior that is tenantspecific. And the tenantsupport of Sling is
> > completely based on paths
>
> In general we want people to get away from the notion that paths drive
> your app, it should be resource types that do.
>
> Also, the problem with paths is that they are usually hidden in code,
> whereas resource types are transparently exposed in the content.
>
> For the POST handling, we could very well take the resource type of
> the parent/ancestors into account, instead of relying on paths.
>
> -Bertrand
>

Re: Sling Posthandling - thougts about the current behavior

[Justin Edelson]

Hi Dominik,
Wouldn't a ResourceDecorator be a better solution in those case? I.e. if a
resource is of type app/foo and is under /content/bar, decorate the
resource to app/bar ?

The fact that you can register servlets by path should *not* in my opinion
be a reason to extend behavior-by-path to other parts of Sling.

Regards,
Justin


On Wed, Jul 3, 2013 at 8:22 AM, Dominik Süß  wrote:

> Hi Bertrand,
>
> while I agree that paths should not drive the app they might build a scope
> for the logic, since the content is organized in a tree structure and not
> in by it's resourceType hierarchy, Therefore you often do have pathspecific
> operations (just think of workflows and workflowlaunchers in CQ). Or to
> come up with another scenario.
> Changing resourceTypes depending on the location of the same data on the
> other hand would be redundant information.
>
> So - the main Driver should be the resourceType is what is defining the
> behavior of a component while the contentpath in my eyes could act as
> restricting criteria.
>
> WDYT?
>
>
> On Wed, Jul 3, 2013 at 1:22 PM, Bertrand Delacretaz
> wrote:
>
> > Hi,
> >
> > On Wed, Jul 3, 2013 at 12:55 PM, Dominik Süß 
> > wrote:
> > > ...why do you think registering logic by path is bad. Especially if I
> > look at
> > > potential for multitenantsupport it would be great to be able to
> register
> > > postbehavior that is tenantspecific. And the tenantsupport of Sling is
> > > completely based on paths
> >
> > In general we want people to get away from the notion that paths drive
> > your app, it should be resource types that do.
> >
> > Also, the problem with paths is that they are usually hidden in code,
> > whereas resource types are transparently exposed in the content.
> >
> > For the POST handling, we could very well take the resource type of
> > the parent/ancestors into account, instead of relying on paths.
> >
> > -Bertrand
> >
>

Re: @Adapter methods, ready to integrate in trunk, WDYT?

[Justin Edelson]

Bertrand-
This all looks good to me. I would like to see condition metadata provided
in the @Adapter annotation. But this can be added after you commit (just
ideally before the release).

Regards,
Justin


On Tue, Jul 2, 2013 at 10:09 AM, Bertrand Delacretaz  wrote:

> Hi,
>
> As this touches the sling.api bundle, I have attached a patch [1] for
> review ,see SLING-2938 for more details. All the TODOs in that issue
> have been implemented.
>
> I plan to commit this later this week, unless someone objects.
>
> -Bertrand
>
> [1]
> https://issues.apache.org/jira/secure/attachment/12590435/SLING-2938-api.patch
>

Re: [DISCUSS] SLING-2936 - passing selector as POST parameter

[Justin Edelson]

Hi,


On Tue, Jul 2, 2013 at 5:39 AM, Bertrand Delacretaz
wrote:

> Hi,
>
> On Thu, Jun 27, 2013 at 5:46 PM, Justin Edelson
>  wrote:
> >...I think there is a significant need to be able to "select"
> > amongst multiple POST servlets for a particular resource. Thus, I propose
> > that we allow for the selector to be passed via a request parameter
>
> Why is that better than using a selector?
>

Chiefly because the resource is the same yet there are two different paths.
So rather than using the path to purely describe a noun, you are also
embedding a verb into it.

For example, consider a polling resource. You want to be able to vote and
clear results. The poll is the noun and "vote" and "clear" are the verbs.

With a path-based selector, you have:
POST /content/site/poll.vote.html
item=one

POST /content/site/poll.clear.html

With a parameter-based selector:
POST /content/site/poll.html
:selector=vote&item=one

POST /conetnt/site/poll.clear.html
:selector=clear

Regards,
Justin


>
> -Bertrand (not contesting, trying to understand ;-)
>

Re: Sling Posthandling - thougts about the current behavior

[Bertrand Delacretaz]

On Wed, Jul 3, 2013 at 2:38 PM, Justin Edelson  wrote:
>... Wouldn't a ResourceDecorator be a better solution in those case? I.e. if a
> resource is of type app/foo and is under /content/bar, decorate the
> resource to app/bar ?...

Note that we already have something like that in
http://svn.apache.org/repos/asf/sling/trunk/samples/path-based-rtp/

-Bertrand

Re: Sling Posthandling - thougts about the current behavior

[Dominik Süß]

As said before - I would never register a Servlet by path, but a Servlet
serving a specific ResourceType might just be valid for a specific path.
(like extension or selector can filter the selection of the matching
Servlet/Script). I agree that in contrast to Servlets and Extensions it's
not feasible to encode this in the script, but I bet a bunch of
scripts/servlet currently check the contentpath first and react on this

Dominik


On Wed, Jul 3, 2013 at 2:38 PM, Justin Edelson wrote:

> Hi Dominik,
> Wouldn't a ResourceDecorator be a better solution in those case? I.e. if a
> resource is of type app/foo and is under /content/bar, decorate the
> resource to app/bar ?
>
> The fact that you can register servlets by path should *not* in my opinion
> be a reason to extend behavior-by-path to other parts of Sling.
>
> Regards,
> Justin
>
>
> On Wed, Jul 3, 2013 at 8:22 AM, Dominik Süß 
> wrote:
>
> > Hi Bertrand,
> >
> > while I agree that paths should not drive the app they might build a
> scope
> > for the logic, since the content is organized in a tree structure and not
> > in by it's resourceType hierarchy, Therefore you often do have
> pathspecific
> > operations (just think of workflows and workflowlaunchers in CQ). Or to
> > come up with another scenario.
> > Changing resourceTypes depending on the location of the same data on the
> > other hand would be redundant information.
> >
> > So - the main Driver should be the resourceType is what is defining the
> > behavior of a component while the contentpath in my eyes could act as
> > restricting criteria.
> >
> > WDYT?
> >
> >
> > On Wed, Jul 3, 2013 at 1:22 PM, Bertrand Delacretaz
> > wrote:
> >
> > > Hi,
> > >
> > > On Wed, Jul 3, 2013 at 12:55 PM, Dominik Süß 
> > > wrote:
> > > > ...why do you think registering logic by path is bad. Especially if I
> > > look at
> > > > potential for multitenantsupport it would be great to be able to
> > register
> > > > postbehavior that is tenantspecific. And the tenantsupport of Sling
> is
> > > > completely based on paths
> > >
> > > In general we want people to get away from the notion that paths drive
> > > your app, it should be resource types that do.
> > >
> > > Also, the problem with paths is that they are usually hidden in code,
> > > whereas resource types are transparently exposed in the content.
> > >
> > > For the POST handling, we could very well take the resource type of
> > > the parent/ancestors into account, instead of relying on paths.
> > >
> > > -Bertrand
> > >
> >
>

Re: @Adapter methods, ready to integrate in trunk, WDYT?

[Bertrand Delacretaz]

hi Justin,

On Wed, Jul 3, 2013 at 2:41 PM, Justin Edelson  wrote:
>...I would like to see condition metadata provided
> in the @Adapter annotation...

I'm generating that, see the bottom of this SLING-2938 screenshot
which describes an Adapter method:
https://issues.apache.org/jira/secure/attachment/12590436/console.jpg

Does that work for you or are you thinking of something else?

-Bertrand

Re: Sling Posthandling - thougts about the current behavior

[Bertrand Delacretaz]

On Wed, Jul 3, 2013 at 2:53 PM, Dominik Süß  wrote:
> ...I bet a bunch of
> scripts/servlet currently check the contentpath first and react on this...

Those servlets should die ;-)

-Bertrand

Re: Sling Posthandling - thougts about the current behavior

[Justin Edelson]

Hi,


On Tue, Jul 2, 2013 at 2:38 PM, Alexander Klimetschek wrote:

> Ack on the overall goal.
>
> The way I see it, it boils down to having the sling post servlet (or more
> specifically that new POST-pipeline) not "just" one special servlet out of
> many, but an integral part of Sling.


>
> Registering operations, post processors or whatever we need by resource
> type sounds good. By path not so much, don't know.
>
> IMHO, the rt would be taken from the addressed resource (what the URL
> addresses, to be 1:1 with how GET servlet resolution works; not any
> resources that additional request parameters might address) and if not
> present (creating a new resource) from the sling:resourceType param.
>
> It would actually be nice if those operations or postprocessor could
> become servlets or servlet filters again. They could get the necessary
> state passed via a request attribute for example + a utility to fetch them.
> And thinking about it, filters are actually the right thing, they are
> designed for pipelines.


> I am not sure if adding a :selector parameter as proposed by Justin
> (SLING-2936) is a good idea - maybe the integration with this new pipeline
> is the better long-term approach. You'd register by resource type + http
> method + :operation. Having both :operation and :selector (in the combined
> overall picture) seems like duplication. But it's difficult.
>

Why wouldn't you register by resource type + method + selector? After all,
that's what you do now. For pipeline components, we could add a "phase"
registration property (or maybe ranking is enough).

IMHO :operation is an aspect of the current default POST servlet. If we are
going to move more POST-specific handling into the engine, then we should
be using selectors.

Justin


> It was mentioned that using selectors in the URL for POST requests, such
> as POST /content/page.createChild.html, is not RESTful. Is that really the
> case? As long as the server provides the URL instead of the client building
> it himself, such as  + ".createChild.html" as it happens way too
> much, and you use the right HTTP methods for changing/deleting content,
> nothing here would be unRESTful afaics.
>
> It would only look nicer if you put all the POST related information into
> the request parameters instead of into the URL. But then it's the old
> "action=create" topic again, which should be covered very well with the
> default features of the Sling post servlet already, which only requires you
> to add custom code (actions) for very specific things.


> This is even less once we have a validation framework in place (also
> resource type based), where Radu did a lot of work already!


> Cheers,
> Alex
>
>
> On 02.07.2013, at 15:26, Dominik Süß  wrote:
>
> > Well, if locking is just about permission I do agree with ACLs being the
> > right solution (the permission set on the node itself might be sufficient
> > for that case) - if it is about businessconstraints that need to be
> > fullfilled an ACL cannot solve this requirement[0]. This is why
> validation
> > and so on should be performed first, I would think of a pipeline having a
> > contract on each phase what can be done and what cannot be done, while a
> > first phase might not write any data (even as transient changes) the next
> > phase might be perform (transient) change, then the postoperations would
> be
> > performed in a transient followed by another phase that might perform
> > transient changes and/or stop the processing, followed by a last phase
> that
> > is called after the resourceResolve has performed a commit().
> >
> > This is purely about giving developers a contract on what they can and
> > cannot do (and therefore what they can expect 3rd party code to do) at a
> > specific point in this pipeline.
> >
> > [0] a businessconstraint to control sepecific operations by permissions
> > could be solved by a shadowstructure like proposed by Bertrand.
> >
> > --
> > Dominik
> >
> >
> > On Tue, Jul 2, 2013 at 2:47 PM, Bertrand Delacretaz
> > wrote:
> >
> >> On Tue, Jul 2, 2013 at 2:38 PM, Dominik Süß 
> >> wrote:
> >>> Facing some questions about how to prevent the SlingPostServlet to be
> >> able
> >>> to perform a change I had a closer look at the current implementation
> and
> >>> it looks like there is currently no "secure" way of doing that beside
> >>> locking the target on persistancelevel (alias setting ACLs)...
> >>
> >> ...which looks to me like the right way of locking things.
> >>
> >> But maybe for the post servlet we need a parallel structure to define
> >> who's allowed to do what. You could for example have
> >>
> >>  /user-rights/sling/post-servlet/post/content/foo
> >>
> >> and whoever's allowed to read that is allowed to post to /content/foo,
> >> barring other ACL limitations.
> >>
> >> Just thinking outloud mostly...my point is that any security-related
> >> stuff should be driven by ACLs, and in some case "indirect" ACLs can
> >> be useful.
> >>
> >> -Bertrand
> >>
>

Re: Sling Posthandling - thougts about the current behavior

[Bertrand Delacretaz]

On Wed, Jul 3, 2013 at 2:58 PM, Justin Edelson  wrote:
> ...Why wouldn't you register by resource type + method + selector? After all,
> that's what you do now. For pipeline components, we could add a "phase"
> registration property (or maybe ranking is enough)

And phase could be just a fake selector, PPP_foo or something where
PP_ means "POST Pipeline Phase".

-Bertrand

Re: [Discovery] missing features and 3rd party implementation of discovery.api

[Carsten Ziegeler]

Thanks for taking this up, Stefan.

I think we should also try to close down the first version of the discovery
api and release this, so other parts of our code can really rely on this
api.

Apart from that, I don't have a strong preference, although it would be
nice to just use Apache stuff :)

Regards
Carsten


2013/7/1 Stefan Egli 

> Hi,
>
> I've created SLING-2939 [0] to track an additional, 3rd party based
> implementation of the discovery.api. The idea is to complement the
> discovery.impl (which is ootb, entirely sling-based) with a more mature,
> specialized, scalable implementation based on a clustering library. I've
> summarized some pros/cons of possible candidates, including some already
> received feedback in the ticket. I would appreciated further feedback!
>
> It looks like Zookeeper/Curator would be a very good fit, requirement-wise
> – but there was also an argument for using JGroups (or something like
> Infinispan ontop of it), although that's LGPL at the moment.
>
> At the same time, it might be a good time to discuss if there's any need
> for api changes, like 'topology-wide leader' or
> 'grouping/spliting/organizing topologies'. In discussions surrounding
> topologies, other more consensus-like topics came up (things which
> zookeeper/curator would cover nicely). The question here is though if that
> fits into the discovery api itself or if that's not something completely
> different and out-of-scope of discovery.
>
> Thanks,
> Cheers,
> Stefan
> --
> [0] - https://issues.apache.org/jira/browse/SLING-2939
>
>


-- 
Carsten Ziegeler
cziege...@apache.org

Re: @Adapter methods, ready to integrate in trunk, WDYT?

[Justin Edelson]

Hi Bertrand,


On Wed, Jul 3, 2013 at 8:55 AM, Bertrand Delacretaz
wrote:

> hi Justin,
>
> On Wed, Jul 3, 2013 at 2:41 PM, Justin Edelson 
> wrote:
> >...I would like to see condition metadata provided
> > in the @Adapter annotation...
>
> I'm generating that, see the bottom of this SLING-2938 screenshot
> which describes an Adapter method:
> https://issues.apache.org/jira/secure/attachment/12590436/console.jpg
>
> Does that work for you or are you thinking of something else?
>

I was thinking @Adapter("if the resource type is slingbucks/list") or
@Adapter(condition="if the resource type is slingbucks/list").

I think what you have in that screenshot is good default behavior, but we
should let the implementor provide additional metadata if they feel it is
appropriate.

Justin


>
> -Bertrand
>

[jira] [Assigned] (SLING-2925) Wasted work in InternalQueueConfiguration.checkIsValid()

[Carsten Ziegeler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-2925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carsten Ziegeler reassigned SLING-2925:
---

Assignee: Carsten Ziegeler

> Wasted work in InternalQueueConfiguration.checkIsValid()
> 
>
> Key: SLING-2925
> URL: https://issues.apache.org/jira/browse/SLING-2925
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
> Environment: any
>Reporter: Adrian Nistor
>Assignee: Carsten Ziegeler
>  Labels: patch, performance
> Attachments: patch.diff
>
>
> The problem appears in version 6 and in revision 1495454.  I attached
> a one-line patch that fixes it.
> In method "InternalQueueConfiguration.checkIsValid", the loop over
> "matchers" should break immediately after "hasMatchers" is set to
> "true".  All the iterations after "hasMatchers" is set to "true" do
> not perform any useful work, at best they just set "hasMatchers" again
> to "true".
> Method "isLive" in class "ResourceResolverContext" has a similar loop
> (over "dynamicProviders"), and this loop breaks immediately after
> "result" is set to "false", just like in the proposed patch.  Other
> methods (e.g., "FactoryPreconditions.checkPreconditions",
> "JspUtil.checkAttributes", "EclipseJavaCompiler.compile",
> "SecondPassVisitor.appendPageDirective") also have similar loops with
> similar breaks, just like in the proposed patch.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (SLING-2925) Wasted work in InternalQueueConfiguration.checkIsValid()

[Carsten Ziegeler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-2925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carsten Ziegeler updated SLING-2925:


Fix Version/s: Extensions Event 3.2.0

> Wasted work in InternalQueueConfiguration.checkIsValid()
> 
>
> Key: SLING-2925
> URL: https://issues.apache.org/jira/browse/SLING-2925
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
> Environment: any
>Reporter: Adrian Nistor
>Assignee: Carsten Ziegeler
>  Labels: patch, performance
> Fix For: Extensions Event 3.2.0
>
> Attachments: patch.diff
>
>
> The problem appears in version 6 and in revision 1495454.  I attached
> a one-line patch that fixes it.
> In method "InternalQueueConfiguration.checkIsValid", the loop over
> "matchers" should break immediately after "hasMatchers" is set to
> "true".  All the iterations after "hasMatchers" is set to "true" do
> not perform any useful work, at best they just set "hasMatchers" again
> to "true".
> Method "isLive" in class "ResourceResolverContext" has a similar loop
> (over "dynamicProviders"), and this loop breaks immediately after
> "result" is set to "false", just like in the proposed patch.  Other
> methods (e.g., "FactoryPreconditions.checkPreconditions",
> "JspUtil.checkAttributes", "EclipseJavaCompiler.compile",
> "SecondPassVisitor.appendPageDirective") also have similar loops with
> similar breaks, just like in the proposed patch.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (SLING-2925) Wasted work in InternalQueueConfiguration.checkIsValid()

[Carsten Ziegeler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-2925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carsten Ziegeler resolved SLING-2925.
-

Resolution: Fixed

Thanks for your patch Adrian, it's applied

> Wasted work in InternalQueueConfiguration.checkIsValid()
> 
>
> Key: SLING-2925
> URL: https://issues.apache.org/jira/browse/SLING-2925
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
> Environment: any
>Reporter: Adrian Nistor
>Assignee: Carsten Ziegeler
>  Labels: patch, performance
> Fix For: Extensions Event 3.2.0
>
> Attachments: patch.diff
>
>
> The problem appears in version 6 and in revision 1495454.  I attached
> a one-line patch that fixes it.
> In method "InternalQueueConfiguration.checkIsValid", the loop over
> "matchers" should break immediately after "hasMatchers" is set to
> "true".  All the iterations after "hasMatchers" is set to "true" do
> not perform any useful work, at best they just set "hasMatchers" again
> to "true".
> Method "isLive" in class "ResourceResolverContext" has a similar loop
> (over "dynamicProviders"), and this loop breaks immediately after
> "result" is set to "false", just like in the proposed patch.  Other
> methods (e.g., "FactoryPreconditions.checkPreconditions",
> "JspUtil.checkAttributes", "EclipseJavaCompiler.compile",
> "SecondPassVisitor.appendPageDirective") also have similar loops with
> similar breaks, just like in the proposed patch.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (SLING-2925) Wasted work in InternalQueueConfiguration.checkIsValid()

[Carsten Ziegeler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-2925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carsten Ziegeler updated SLING-2925:


Component/s: (was: Scripting)
 Extensions

> Wasted work in InternalQueueConfiguration.checkIsValid()
> 
>
> Key: SLING-2925
> URL: https://issues.apache.org/jira/browse/SLING-2925
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
> Environment: any
>Reporter: Adrian Nistor
>Assignee: Carsten Ziegeler
>  Labels: patch, performance
> Attachments: patch.diff
>
>
> The problem appears in version 6 and in revision 1495454.  I attached
> a one-line patch that fixes it.
> In method "InternalQueueConfiguration.checkIsValid", the loop over
> "matchers" should break immediately after "hasMatchers" is set to
> "true".  All the iterations after "hasMatchers" is set to "true" do
> not perform any useful work, at best they just set "hasMatchers" again
> to "true".
> Method "isLive" in class "ResourceResolverContext" has a similar loop
> (over "dynamicProviders"), and this loop breaks immediately after
> "result" is set to "false", just like in the proposed patch.  Other
> methods (e.g., "FactoryPreconditions.checkPreconditions",
> "JspUtil.checkAttributes", "EclipseJavaCompiler.compile",
> "SecondPassVisitor.appendPageDirective") also have similar loops with
> similar breaks, just like in the proposed patch.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (SLING-2938) AdapterMethods annotation and adapter proxy service

[Bertrand Delacretaz (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-2938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13698933#comment-13698933
 ] 

Bertrand Delacretaz commented on SLING-2938:


TODOs after integration in trunk:
* Add an integration test
* Add an optional condition like @Adapter(condition="if the resource type is 
slingbucks/list") that completes the webconsole description

> AdapterMethods annotation and adapter proxy service
> ---
>
> Key: SLING-2938
> URL: https://issues.apache.org/jira/browse/SLING-2938
> Project: Sling
>  Issue Type: Bug
>  Components: Engine, Extensions
>Affects Versions: Adapter 2.1.0
>Reporter: Bertrand Delacretaz
>Priority: Minor
> Attachments: console.jpg, SLING-2938-api.patch
>
>
> Following up on an idea that Olaf Otto presented at CQCon last week, I've 
> been working on an @AdapterMethod annotation that makes it easier to create 
> Sling adapters, as in
>   @Component
>   @Service
>   public class MyAdapters implements AdapterMethodProvider {
> @AdapterMethod
> public Bar toBar(Foo f) { ... adapt Foo to Bar ... }
>   }
> As this requires changes to the sling.api bundle, I'll commit to my 
> whiteboard first, for review

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: @Adapter methods, ready to integrate in trunk, WDYT?

[Bertrand Delacretaz]

On Wed, Jul 3, 2013 at 3:07 PM, Justin Edelson  wrote:
...
> @Adapter(condition="if the resource type is slingbucks/list").
...

Makes sense, noted in SLING-2938
-Bertrand

[jira] [Commented] (SLING-2938) AdapterMethods annotation and adapter proxy service

[Carsten Ziegeler (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-2938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13698943#comment-13698943
 ] 

Carsten Ziegeler commented on SLING-2938:
-

Who is processing this annotation and when (build time, run time..) ?


> AdapterMethods annotation and adapter proxy service
> ---
>
> Key: SLING-2938
> URL: https://issues.apache.org/jira/browse/SLING-2938
> Project: Sling
>  Issue Type: Bug
>  Components: Engine, Extensions
>Affects Versions: Adapter 2.1.0
>Reporter: Bertrand Delacretaz
>Priority: Minor
> Attachments: console.jpg, SLING-2938-api.patch
>
>
> Following up on an idea that Olaf Otto presented at CQCon last week, I've 
> been working on an @AdapterMethod annotation that makes it easier to create 
> Sling adapters, as in
>   @Component
>   @Service
>   public class MyAdapters implements AdapterMethodProvider {
> @AdapterMethod
> public Bar toBar(Foo f) { ... adapt Foo to Bar ... }
>   }
> As this requires changes to the sling.api bundle, I'll commit to my 
> whiteboard first, for review

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (SLING-2938) AdapterMethods annotation and adapter proxy service

[Bertrand Delacretaz (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-2938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13698948#comment-13698948
 ] 

Bertrand Delacretaz commented on SLING-2938:


The @Adapter annotation is processed at runtime, all the "magic" is in
http://svn.apache.org/repos/asf/sling/whiteboard/bdelacretaz/adapter-methods/extensions-adapter/src/main/java/org/apache/sling/adapter/internal/AdapterMethodsManagerImpl.java

> AdapterMethods annotation and adapter proxy service
> ---
>
> Key: SLING-2938
> URL: https://issues.apache.org/jira/browse/SLING-2938
> Project: Sling
>  Issue Type: Bug
>  Components: Engine, Extensions
>Affects Versions: Adapter 2.1.0
>Reporter: Bertrand Delacretaz
>Priority: Minor
> Attachments: console.jpg, SLING-2938-api.patch
>
>
> Following up on an idea that Olaf Otto presented at CQCon last week, I've 
> been working on an @AdapterMethod annotation that makes it easier to create 
> Sling adapters, as in
>   @Component
>   @Service
>   public class MyAdapters implements AdapterMethodProvider {
> @AdapterMethod
> public Bar toBar(Foo f) { ... adapt Foo to Bar ... }
>   }
> As this requires changes to the sling.api bundle, I'll commit to my 
> whiteboard first, for review

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: @Adapter methods, ready to integrate in trunk, WDYT?

[Carsten Ziegeler]

Hi,

sounds interesting - could you please elaborate a little bit on who is
processing this annotation and when?

Thanks
Carsten


2013/7/3 Bertrand Delacretaz 

> On Wed, Jul 3, 2013 at 3:07 PM, Justin Edelson 
> wrote:
> ...
> > @Adapter(condition="if the resource type is slingbucks/list").
> ...
>
> Makes sense, noted in SLING-2938
> -Bertrand
>



-- 
Carsten Ziegeler
cziege...@apache.org

Re: Sling Posthandling - thougts about the current behavior

[Dominik Süß]

If I got the implementation right you always trigger exactly one, so this
is not an aspect, this is wat actualy is done to perform the post.
Aspects are handled via PostProcessors.


On Wed, Jul 3, 2013 at 2:58 PM, Justin Edelson wrote:

> Hi,
>
>
> On Tue, Jul 2, 2013 at 2:38 PM, Alexander Klimetschek  >wrote:
>
> > Ack on the overall goal.
> >
> > The way I see it, it boils down to having the sling post servlet (or more
> > specifically that new POST-pipeline) not "just" one special servlet out
> of
> > many, but an integral part of Sling.
>
>
> >
> > Registering operations, post processors or whatever we need by resource
> > type sounds good. By path not so much, don't know.
> >
> > IMHO, the rt would be taken from the addressed resource (what the URL
> > addresses, to be 1:1 with how GET servlet resolution works; not any
> > resources that additional request parameters might address) and if not
> > present (creating a new resource) from the sling:resourceType param.
> >
> > It would actually be nice if those operations or postprocessor could
> > become servlets or servlet filters again. They could get the necessary
> > state passed via a request attribute for example + a utility to fetch
> them.
> > And thinking about it, filters are actually the right thing, they are
> > designed for pipelines.
>
>
> > I am not sure if adding a :selector parameter as proposed by Justin
> > (SLING-2936) is a good idea - maybe the integration with this new
> pipeline
> > is the better long-term approach. You'd register by resource type + http
> > method + :operation. Having both :operation and :selector (in the
> combined
> > overall picture) seems like duplication. But it's difficult.
> >
>
> Why wouldn't you register by resource type + method + selector? After all,
> that's what you do now. For pipeline components, we could add a "phase"
> registration property (or maybe ranking is enough).
>
> IMHO :operation is an aspect of the current default POST servlet. If we are
> going to move more POST-specific handling into the engine, then we should
> be using selectors.
>
> Justin
>
>
> > It was mentioned that using selectors in the URL for POST requests, such
> > as POST /content/page.createChild.html, is not RESTful. Is that really
> the
> > case? As long as the server provides the URL instead of the client
> building
> > it himself, such as  + ".createChild.html" as it happens way too
> > much, and you use the right HTTP methods for changing/deleting content,
> > nothing here would be unRESTful afaics.
> >
> > It would only look nicer if you put all the POST related information into
> > the request parameters instead of into the URL. But then it's the old
> > "action=create" topic again, which should be covered very well with the
> > default features of the Sling post servlet already, which only requires
> you
> > to add custom code (actions) for very specific things.
>
>
> > This is even less once we have a validation framework in place (also
> > resource type based), where Radu did a lot of work already!
>
>
> > Cheers,
> > Alex
> >
> >
> > On 02.07.2013, at 15:26, Dominik Süß  wrote:
> >
> > > Well, if locking is just about permission I do agree with ACLs being
> the
> > > right solution (the permission set on the node itself might be
> sufficient
> > > for that case) - if it is about businessconstraints that need to be
> > > fullfilled an ACL cannot solve this requirement[0]. This is why
> > validation
> > > and so on should be performed first, I would think of a pipeline
> having a
> > > contract on each phase what can be done and what cannot be done, while
> a
> > > first phase might not write any data (even as transient changes) the
> next
> > > phase might be perform (transient) change, then the postoperations
> would
> > be
> > > performed in a transient followed by another phase that might perform
> > > transient changes and/or stop the processing, followed by a last phase
> > that
> > > is called after the resourceResolve has performed a commit().
> > >
> > > This is purely about giving developers a contract on what they can and
> > > cannot do (and therefore what they can expect 3rd party code to do) at
> a
> > > specific point in this pipeline.
> > >
> > > [0] a businessconstraint to control sepecific operations by permissions
> > > could be solved by a shadowstructure like proposed by Bertrand.
> > >
> > > --
> > > Dominik
> > >
> > >
> > > On Tue, Jul 2, 2013 at 2:47 PM, Bertrand Delacretaz
> > > wrote:
> > >
> > >> On Tue, Jul 2, 2013 at 2:38 PM, Dominik Süß 
> > >> wrote:
> > >>> Facing some questions about how to prevent the SlingPostServlet to be
> > >> able
> > >>> to perform a change I had a closer look at the current implementation
> > and
> > >>> it looks like there is currently no "secure" way of doing that beside
> > >>> locking the target on persistancelevel (alias setting ACLs)...
> > >>
> > >> ...which looks to me like the right way of locking things.
> > >>
> > >> But maybe for the post serv

Re: Sling Posthandling - thougts about the current behavior

[Dominik Süß]

Rereading my post:
you always trigger exactly one :operation, so this is not an
aspect, this is wat actualy is done to perform the post.


On Wed, Jul 3, 2013 at 3:27 PM, Dominik Süß  wrote:

> If I got the implementation right you always trigger exactly one, so this
> is not an aspect, this is wat actualy is done to perform the post.
> Aspects are handled via PostProcessors.
>
>
> On Wed, Jul 3, 2013 at 2:58 PM, Justin Edelson 
> wrote:
>
>> Hi,
>>
>>
>> On Tue, Jul 2, 2013 at 2:38 PM, Alexander Klimetschek > >wrote:
>>
>> > Ack on the overall goal.
>> >
>> > The way I see it, it boils down to having the sling post servlet (or
>> more
>> > specifically that new POST-pipeline) not "just" one special servlet out
>> of
>> > many, but an integral part of Sling.
>>
>>
>> >
>> > Registering operations, post processors or whatever we need by resource
>> > type sounds good. By path not so much, don't know.
>> >
>> > IMHO, the rt would be taken from the addressed resource (what the URL
>> > addresses, to be 1:1 with how GET servlet resolution works; not any
>> > resources that additional request parameters might address) and if not
>> > present (creating a new resource) from the sling:resourceType param.
>> >
>> > It would actually be nice if those operations or postprocessor could
>> > become servlets or servlet filters again. They could get the necessary
>> > state passed via a request attribute for example + a utility to fetch
>> them.
>> > And thinking about it, filters are actually the right thing, they are
>> > designed for pipelines.
>>
>>
>> > I am not sure if adding a :selector parameter as proposed by Justin
>> > (SLING-2936) is a good idea - maybe the integration with this new
>> pipeline
>> > is the better long-term approach. You'd register by resource type + http
>> > method + :operation. Having both :operation and :selector (in the
>> combined
>> > overall picture) seems like duplication. But it's difficult.
>> >
>>
>> Why wouldn't you register by resource type + method + selector? After all,
>> that's what you do now. For pipeline components, we could add a "phase"
>> registration property (or maybe ranking is enough).
>>
>> IMHO :operation is an aspect of the current default POST servlet. If we
>> are
>> going to move more POST-specific handling into the engine, then we should
>> be using selectors.
>>
>> Justin
>>
>>
>> > It was mentioned that using selectors in the URL for POST requests, such
>> > as POST /content/page.createChild.html, is not RESTful. Is that really
>> the
>> > case? As long as the server provides the URL instead of the client
>> building
>> > it himself, such as  + ".createChild.html" as it happens way too
>> > much, and you use the right HTTP methods for changing/deleting content,
>> > nothing here would be unRESTful afaics.
>> >
>> > It would only look nicer if you put all the POST related information
>> into
>> > the request parameters instead of into the URL. But then it's the old
>> > "action=create" topic again, which should be covered very well with the
>> > default features of the Sling post servlet already, which only requires
>> you
>> > to add custom code (actions) for very specific things.
>>
>>
>> > This is even less once we have a validation framework in place (also
>> > resource type based), where Radu did a lot of work already!
>>
>>
>> > Cheers,
>> > Alex
>> >
>> >
>> > On 02.07.2013, at 15:26, Dominik Süß  wrote:
>> >
>> > > Well, if locking is just about permission I do agree with ACLs being
>> the
>> > > right solution (the permission set on the node itself might be
>> sufficient
>> > > for that case) - if it is about businessconstraints that need to be
>> > > fullfilled an ACL cannot solve this requirement[0]. This is why
>> > validation
>> > > and so on should be performed first, I would think of a pipeline
>> having a
>> > > contract on each phase what can be done and what cannot be done,
>> while a
>> > > first phase might not write any data (even as transient changes) the
>> next
>> > > phase might be perform (transient) change, then the postoperations
>> would
>> > be
>> > > performed in a transient followed by another phase that might perform
>> > > transient changes and/or stop the processing, followed by a last phase
>> > that
>> > > is called after the resourceResolve has performed a commit().
>> > >
>> > > This is purely about giving developers a contract on what they can and
>> > > cannot do (and therefore what they can expect 3rd party code to do)
>> at a
>> > > specific point in this pipeline.
>> > >
>> > > [0] a businessconstraint to control sepecific operations by
>> permissions
>> > > could be solved by a shadowstructure like proposed by Bertrand.
>> > >
>> > > --
>> > > Dominik
>> > >
>> > >
>> > > On Tue, Jul 2, 2013 at 2:47 PM, Bertrand Delacretaz
>> > > wrote:
>> > >
>> > >> On Tue, Jul 2, 2013 at 2:38 PM, Dominik Süß > >
>> > >> wrote:
>> > >>> Facing some questions about how to prevent the SlingPostServlet to
>> be
>> > >> able
>> > >>

Re: @Adapter methods, ready to integrate in trunk, WDYT?

[Bertrand Delacretaz]

On Wed, Jul 3, 2013 at 3:26 PM, Carsten Ziegeler  wrote:
> ...could you please elaborate a little bit on who is
> processing this annotation and when?...

As I said in SLING-2938: The @Adapter annotation is processed at
runtime, all the "magic" is in

http://svn.apache.org/repos/asf/sling/whiteboard/bdelacretaz/adapter-methods/extensions-adapter/src/main/java/org/apache/sling/adapter/internal/AdapterMethodsManagerImpl.java

-Bertrand

Re: @Adapter methods, ready to integrate in trunk, WDYT?

[Carsten Ziegeler]

Just read the answer in the issue :)

I like the general intention - however it feels a little bit strange to
register a AdapterProvider, annotate a method and then this gets picked up
at runtime and a new AdapterFactory is registered.
Can't we make this annoation build time only - as an extensions of the SCR
annotations?

Carsten


2013/7/3 Carsten Ziegeler 

> Hi,
>
> sounds interesting - could you please elaborate a little bit on who is
> processing this annotation and when?
>
> Thanks
> Carsten
>
>
> 2013/7/3 Bertrand Delacretaz 
>
>> On Wed, Jul 3, 2013 at 3:07 PM, Justin Edelson 
>> wrote:
>> ...
>> > @Adapter(condition="if the resource type is slingbucks/list").
>> ...
>>
>> Makes sense, noted in SLING-2938
>> -Bertrand
>>
>
>
>
> --
> Carsten Ziegeler
> cziege...@apache.org
>



-- 
Carsten Ziegeler
cziege...@apache.org

Re: Wrong handling of service.ranking property in Sling Filter ordering

[Carsten Ziegeler]

I'm more in the camp of fix-the-docs :) One could argue that higher
priority means they have the most power and therefore are run last and can
overrule everything previous filters have done - this again would be
somehow in line with service ranking in general.
In general, when there is a doubt and it's not clearly a bug, I would think
that the implementation is right and the docs are wrong. Because this is
what people are using and they might rely on current ordering. We can fix
our code/configuration, but we can't fix custom code/installations out
there.

Carsten


2013/7/2 Alexander Klimetschek 

> On 18.06.2013, at 15:19, Felix Meschberger  wrote:
>
> > So, I tend to switch over to the fix-the-implementation-camp.
>
> +1
>
> It's what you expect (higher service ranking picked up first) and if the
> wrong cases are few and can be easily handled (big documentation note to
> sling users) that's definitely better.
>
> Cheers,
> Alex
>
>


-- 
Carsten Ziegeler
cziege...@apache.org

[jira] [Commented] (SLING-2803) Create a Validation module capable of validating POST requests or Resources

[Bertrand Delacretaz (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-2803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13698982#comment-13698982
 ] 

Bertrand Delacretaz commented on SLING-2803:


I briefly reviewed the validation-2.zip code, here's some comments - I also 
have a few conceptual things to discuss, will do that on the dev list.

ValidationModel.getValidatedResourceType - shouldn't a model apply to 1..N 
resource types?

Does ValidationResult apply to a single Field? If not it should IMO return a 
list of failures, not just a single message.

ValidationResult.getValidationResultFailureMessage can be called just 
getFailureMessage()

public enum Type: can't you use standard java types for that?

Shouldn't ValidatorLookupService provide an Iterator over existing Validators?

> Create a Validation module capable of validating POST requests or Resources
> ---
>
> Key: SLING-2803
> URL: https://issues.apache.org/jira/browse/SLING-2803
> Project: Sling
>  Issue Type: New Feature
>Reporter: Radu Cotescu
> Attachments: org.apache.sling.validation-2.zip, 
> org.apache.sling.validation.zip
>
>
> Several Sling users have asked in the past [1] about a Validation mechanism 
> in Sling that's able to validate data coming from the user. However, such a 
> module is still missing.
> This issue is meant to track the work progress on such a module.
> Ideally the module should be able to validate both request parameters and 
> Resources, by obtaining their properties via a ValueMap and provide feedback 
> in case of a validation error.
> [1] - http://sling.markmail.org/search/?q=validation

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Wrong handling of service.ranking property in Sling Filter ordering

[Bertrand Delacretaz]

On Wed, Jul 3, 2013 at 4:00 PM, Carsten Ziegeler  wrote:
> ...In general, when there is a doubt and it's not clearly a bug, I would think
> that the implementation is right and the docs are wrong...

yes, yes, yes, +1 !

People have been running our code, not our docs...changing the former
has much more impact than the latter, and in this case the ordering
direction is mostly a matter of taste.

-Bertrand

SLING-2803 validation module, hierarchical structures and extensible types

[Bertrand Delacretaz]

Hi Radu,

I've briefly reviewed your SLING-2803 code and it looks quite good to me!

I'm wondering if it supports the following use cases:

1) Validating hierarchical structures
Say I'm POSTing a small tree of resources rooted at /foo, can you
validate for example that /foo/customer/email is present and valid
according to an email validator?

How about validating any property named "email" found somewhere within
that posted tree?

2) Extensible types
In the above example, can you also validate that the specified email
is present in an external system, to which a custom OSGi service
provides access?

We might not need these features immediately, but IMO they should at
least be supported at the API/code design level.

-Bertrand

Jenkins build is unstable: sling-trunk-1.6 » Apache Sling Resource-Based Discovery Service #1711

[Apache Jenkins Server]

See 

Jenkins build is back to normal : sling-trunk-1.6 » Apache Sling Maven Plugin to create Jackrabbit OCM descriptors #1711

[Apache Jenkins Server]

See 

Jenkins build is back to normal : sling-trunk-1.6 » Apache Sling JSON Library #1711

[Apache Jenkins Server]

See 

Jenkins build is unstable: sling-trunk-1.6 » Apache Sling Launchpad Testing WAR version #1711

[Apache Jenkins Server]

See 

Jenkins build is back to normal : sling-trunk-1.6 » Sling Adapter Annotations #1711

[Apache Jenkins Server]

See 

Build failed in Jenkins: sling-trunk-1.7 » Apache Sling Engine Implementation #81

[Apache Jenkins Server]

See 


--
[INFO] 
[INFO] 
[INFO] Building Apache Sling Engine Implementation 2.2.9-SNAPSHOT
[INFO] 
[INFO] 
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ 
org.apache.sling.engine ---[INFO] Deleting 


[INFO] 
[INFO] --- maven-enforcer-plugin:1.0.1:enforce (enforce-java) @ 
org.apache.sling.engine ---
[INFO] 
[INFO] --- maven-antrun-plugin:1.7:run 
(set-bundle-required-execution-environment) @ org.apache.sling.engine ---
[INFO] Executing tasks

main:
[INFO] Executed tasks
[INFO] 
[INFO] --- maven-remote-resources-plugin:1.4:process (default) @ 
org.apache.sling.engine ---
[INFO] 
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ 
org.apache.sling.engine ---[INFO] Using 'UTF-8' encoding to copy filtered 
resources.

[INFO] Copying 1 resource
[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-antrun-plugin:1.7:run (check-memory-task) @ 
org.apache.sling.engine ---
[INFO] Executing tasks

main:
 [echo]  WARNING (SLING-443/SLING-1782) 
**
 [echo] On most platforms, you'll get OutOfMemoryErrors when building 
unless you set
 [echo] on 32bit platforms: MAVEN_OPTS="-Xmx256M -XX:MaxPermSize=256M", see 
SLING-443
 [echo] on 64bit platforms: MAVEN_OPTS="-Xmx512M -XX:MaxPermSize=512M", see 
SLING-1782
 [echo] 
**
[INFO] Executed tasks
[INFO] 
[INFO] --- maven-compiler-plugin:2.5.1:compile (default-compile) @ 
org.apache.sling.engine ---
[INFO] Compiling 53 source files to 

[INFO] 
[INFO] --- maven-scr-plugin:1.12.0:scr (generate-scr-scrdescriptor) @ 
org.apache.sling.engine ---[WARNING] 

 [0:0]: Property filter.scope in class 
org.apache.sling.engine.impl.debug.RequestProgressTrackerLogFilter is set as 
private. This is redundant as no metatype will be generated.
[INFO] Generating 1 MetaType Descriptors in 

[INFO] Generating 1 MetaType Descriptors in 

[INFO] Generating 1 MetaType Descriptors in 

[INFO] Writing 1 Service Component Descriptors to 

[INFO] Writing 1 Service Component Descriptors to 

[INFO] Writing 1 Service Component Descriptors to 

[INFO] Writing 1 Service Component Descriptors to 

[INFO] Writing 1 Service Component Descriptors to 

[INFO] Writing 1 Service Component Descriptors to 


[INFO] [INFO] Using 'UTF-8' encoding to copy filtered resources.

[INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @ 
org.apache.sling.engine ---[INFO] Copying 3 resources
[INFO] Copying 3 resources

[INFO] 
[INFO] --- maven-compiler-plugin:2.5.1:testCom

Jenkins build is unstable: sling-trunk-1.6 #1711

[Apache Jenkins Server]

See 

[jira] [Commented] (SLING-2803) Create a Validation module capable of validating POST requests or Resources

[Radu Cotescu (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-2803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13699066#comment-13699066
 ] 

Radu Cotescu commented on SLING-2803:
-

Thanks for the review, Bertrand!

I tried to bind a ValidationModel to a specific resource type because I expect 
that resources aren't that similar between each other if their types are 
different. However if you have a valid use case where you'd bind a 
ValidationModel to multiple resource types we could definitely change this.

In the default implementation I'm currently stopping the validation check as 
soon as I discover the first inconsistency; if we decide to perform the whole 
validation in one go, no matter what intermediary results we get, we could also 
change the use of the ValidationResult to return a list of failures.

For the Type object I preferred an enum due to its intrinsic advantages: 
singleton by default and thread safe (after I'll cleanup the SDF mess - I 
forgot that SDF is not thread-safe); also I can use the constants for the 
isValid check really easy.

The name of the parameter sent to ValidatorLookupService.getValidator is 
misleading now: I expect to have a validator name sent as parameter, not a 
type; also I expect the names to be unique. For the current implementation I'm 
using the class names.

> Create a Validation module capable of validating POST requests or Resources
> ---
>
> Key: SLING-2803
> URL: https://issues.apache.org/jira/browse/SLING-2803
> Project: Sling
>  Issue Type: New Feature
>Reporter: Radu Cotescu
> Attachments: org.apache.sling.validation-2.zip, 
> org.apache.sling.validation.zip
>
>
> Several Sling users have asked in the past [1] about a Validation mechanism 
> in Sling that's able to validate data coming from the user. However, such a 
> module is still missing.
> This issue is meant to track the work progress on such a module.
> Ideally the module should be able to validate both request parameters and 
> Resources, by obtaining their properties via a ValueMap and provide feedback 
> in case of a validation error.
> [1] - http://sling.markmail.org/search/?q=validation

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Build failed in Jenkins: sling-trunk-1.7 #81

[Apache Jenkins Server]

See 

Changes:

[cziegeler] SLING-2925 : Wasted work in 
InternalQueueConfiguration.checkIsValid(). Apply patch from Adrian Nistor

--
[...truncated 5708 lines...]
[INFO] Sling JCRInstall Bundle Archetype . SUCCESS [28.114s]
[INFO] Sling Taglib Archetype  SUCCESS [31.899s]
[INFO] Apache Sling API .. SUCCESS [1:42.933s]
[INFO] Apache Sling Resource Resolver  SUCCESS [1:58.961s]
[INFO] Apache Sling System Bundle Extension: Java Transaction API  SUCCESS 
[42.974s]
[INFO] Apache Sling System Bundle Extension: XML APIs  SUCCESS [32.432s]
[INFO] Apache Sling System Bundle Extension: Activation API  SUCCESS [41.973s]
[INFO] Apache Sling System Bundle Extension: WS APIs . SUCCESS [34.144s]
[INFO] Apache Sling Dynamic Class Loader Support . SUCCESS [1:21.147s]
[INFO] Apache Sling JSON Library . SUCCESS [2:11.198s]
[INFO] Apache Sling SLF4J Implementation . SUCCESS [2:33.765s]
[INFO] Apache Sling OSGi LogService Implementation ... SUCCESS [57.481s]
[INFO] Apache Sling MIME type mapping support  SUCCESS [3:02.514s]
[INFO] Apache Sling Commons OSGi support . SUCCESS [1:56.205s]
[INFO] Apache Sling Scheduler Support  SUCCESS [46.069s]
[INFO] Apache Sling Testing Utilities  SUCCESS [2:25.205s]
[INFO] Apache Sling Thread Support ... SUCCESS [31.417s]
[INFO] Apache Sling Authentication Service ... SUCCESS [1:00.280s]
[INFO] Apache Sling OpenID Authentication  SUCCESS [1:31.718s]
[INFO] Apache Sling Form Based Authentication Handler  SUCCESS [1:40.711s]
[INFO] Apache Sling Authentication Selector .. SUCCESS [51.300s]
[INFO] Apache Sling Engine Implementation  FAILURE [1:22.238s]
[INFO] Apache Sling Repository API Bundle  SKIPPED
[INFO] Apache Sling JCR Base Bundle .. SKIPPED
[INFO] Apache Sling JCR ClassLoader .. SKIPPED
[INFO] Apache Sling Initial Content Loader ... SKIPPED
[INFO] Apache Sling Jackrabbit Embedded Repository ... SKIPPED
[INFO] Apache Sling Jackrabbit UserManager Support ... SKIPPED
[INFO] Apache Sling Jackrabbit JSR-283 Access Control Manager Support  SKIPPED
[INFO] Apache Sling Wrapper Bundle for the JCR API ... SKIPPED
[INFO] Apache Sling Object Content Mapping ... SKIPPED
[INFO] Apache Sling JCR Resource Resolver  SKIPPED
[INFO] Apache Sling JCR Repository Registration .. SKIPPED
[INFO] Apache Sling Simple WebDAV Access to repositories . SKIPPED
[INFO] Apache Sling DavEx Access to repositories . SKIPPED
[INFO] Apache Sling JCR WebConsole Bundle  SKIPPED
[INFO] Apache Sling Servlet Resolver . SKIPPED
[INFO] Apache Sling Default GET Servlets . SKIPPED
[INFO] Apache Sling Default POST Servlets  SKIPPED
[INFO] Apache Sling Compat Servlets .. SKIPPED
[INFO] Apache Sling Scripting Implementation API . SKIPPED
[INFO] Apache Sling Scripting Core implementation  SKIPPED
[INFO] Apache Sling Scripting JavaScript Support . SKIPPED
[INFO] Apache Sling Scripting JSP Support  SKIPPED
[INFO] Apache Sling JSP Tag Library .. SKIPPED
[INFO] Apache Sling JSP Standard Tag Library . SKIPPED
[INFO] Apache Sling Adapter Manager Implementation ... SKIPPED
[INFO] Apache Sling Bundle Resource Provider . SKIPPED
[INFO] Apache Sling Discovery API  SKIPPED
[INFO] Apache Sling Resource-Based Discovery Service . SKIPPED
[INFO] Apache Sling Discovery Support Bundle . SKIPPED
[INFO] Apache Sling Discovery Standalone Implementation .. SKIPPED
[INFO] Apache Sling Event Support  SKIPPED
[INFO] Apache Sling Filesystem Resource Provider . SKIPPED
[INFO] Apache Sling javax.activation bundle .. SKIPPED
[INFO] Apache Sling Settings . SKIPPED
[INFO] Apache Sling Thread Dumper  SKIPPED
[INFO] Apache Sling Web Console Branding . SKIPPED
[INFO] Apache Sling Web Console Security Provider  SKIPPED
[INFO] Apache Sling Groovy Extensions  SKIPPED
[INFO] Apache Sling Explorer . SKIPPED
[INFO] Apache Sling Test Tools ... SKIPPED
[INFO] Apache Sling JUnit Core ... SKIPPED
[INFO] Apache Sling JUnit Scriptable Tests Provider .. SKIPPED
[INFO] Apache Sling JUnit Remote Tests Runners ... SKIPPED
[INFO] Apache Sling Testing Resource Resolver Mock ... SKIPPED
[INFO] Apache Sling Installer API ..

Re: SLING-2803 validation module, hierarchical structures and extensible types

[Radu Cotescu]

Hi Bertrand,

1. Currently there's no support for hierarchical structures. ValueMap
doesn't provide this kind of support. I see two solutions here (the first
is your idea from the private chat we had earlier):
a. create a HierarchicalValueMap and perform validation on top of this;
this also implies that we change the SlingHttpServletRequestAF to create
HierarchicalValueMap adapters;
b. bake this only in the implementation of the ValidationService - have
it transform path-like property names into hierarchical structures for
validation

The hierarchical structures validation should also be reflected on the way
the Fields are defined - initially I considered that Fields are mapped 1:1
to a resource's property.

2. As long as the Field from the ValidationModel specifies a certain
Validator to be used for validating the field's value I don't see why we
couldn't have a Validator that checks the data in an external system. The
single current constraint of a Validator is that it has to provide a
validate method, returning a boolean. The implementation can be done
however the developer  sees fit.

I hope this helps.

Regards,
Radu




On Wed, Jul 3, 2013 at 5:08 PM, Bertrand Delacretaz
wrote:

> Hi Radu,
>
> I've briefly reviewed your SLING-2803 code and it looks quite good to me!
>
> I'm wondering if it supports the following use cases:
>
> 1) Validating hierarchical structures
> Say I'm POSTing a small tree of resources rooted at /foo, can you
> validate for example that /foo/customer/email is present and valid
> according to an email validator?
>
> How about validating any property named "email" found somewhere within
> that posted tree?
>
> 2) Extensible types
> In the above example, can you also validate that the specified email
> is present in an external system, to which a custom OSGi service
> provides access?
>
> We might not need these features immediately, but IMO they should at
> least be supported at the API/code design level.
>
> -Bertrand
>

[jira] [Created] (SLING-2943) Classloader might not be invalidated in a cluster

[Carsten Ziegeler (JIRA)]

Carsten Ziegeler created SLING-2943:
---

 Summary: Classloader might not be invalidated in a cluster
 Key: SLING-2943
 URL: https://issues.apache.org/jira/browse/SLING-2943
 Project: Sling
  Issue Type: Bug
  Components: JCR
Affects Versions: JCR Classloader 3.1.12
Reporter: Carsten Ziegeler
Assignee: Carsten Ziegeler
 Fix For: JCR ClassLoader 3.1.14


The jcr classloader is invalided based on the fact if a previous class file can 
be deleted (through the class loader writer).
In a clustered installation, usually only the first instance receiving the 
changed event for a jsp is able to remove the class file; the other instances 
can't delete it, as it is already gone

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (SLING-2943) Classloader might not be invalidated in a cluster

[Carsten Ziegeler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-2943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carsten Ziegeler resolved SLING-2943.
-

Resolution: Fixed

Fixed in revision 1499459

> Classloader might not be invalidated in a cluster
> -
>
> Key: SLING-2943
> URL: https://issues.apache.org/jira/browse/SLING-2943
> Project: Sling
>  Issue Type: Bug
>  Components: JCR
>Affects Versions: JCR Classloader 3.1.12
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: JCR ClassLoader 3.1.14
>
>
> The jcr classloader is invalided based on the fact if a previous class file 
> can be deleted (through the class loader writer).
> In a clustered installation, usually only the first instance receiving the 
> changed event for a jsp is able to remove the class file; the other instances 
> can't delete it, as it is already gone

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Jenkins build is unstable: sling-trunk-1.7 » Apache Sling Launchpad Testing WAR version #82

[Apache Jenkins Server]

See 

Jenkins build is unstable: sling-trunk-1.7 » Apache Sling Sample Integration Tests #82

[Apache Jenkins Server]

See 

Jenkins build is back to normal : sling-trunk-1.7 » Apache Sling Engine Implementation #82

[Apache Jenkins Server]

See 

Jenkins build is unstable: sling-trunk-1.7 » Apache Sling Launchpad Testing #82

[Apache Jenkins Server]

See 

Jenkins build is unstable: sling-trunk-1.7 » Apache Sling Resource-Based Discovery Service #82

[Apache Jenkins Server]

See 

Jenkins build is unstable: sling-trunk-1.7 #82

[Apache Jenkins Server]

See 

Build failed in Jenkins: sling-trunk-1.6 » Apache Sling Jackrabbit Embedded Repository #1712

[Apache Jenkins Server]

See 


--
[INFO] 
[INFO] 
[INFO] Building Apache Sling Jackrabbit Embedded Repository 2.1.1-SNAPSHOT
[INFO] 
[INFO] 
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ 
org.apache.sling.jcr.jackrabbit.server ---[INFO] Deleting 


[INFO] 
[INFO] --- maven-enforcer-plugin:1.0.1:enforce (enforce-java) @ 
org.apache.sling.jcr.jackrabbit.server ---
[INFO] 
[INFO] --- maven-antrun-plugin:1.7:run 
(set-bundle-required-execution-environment) @ 
org.apache.sling.jcr.jackrabbit.server ---
[INFO] Executing tasks

main:
[INFO] Executed tasks
[INFO] 
[INFO] --- maven-remote-resources-plugin:1.4:process (default) @ 
org.apache.sling.jcr.jackrabbit.server ---
[INFO] 
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ 
org.apache.sling.jcr.jackrabbit.server ---[INFO] Using 'UTF-8' encoding to copy 
filtered resources.

[INFO] Copying 4 resources
[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-antrun-plugin:1.7:run (check-memory-task) @ 
org.apache.sling.jcr.jackrabbit.server ---
[INFO] Executing tasks

main:
 [echo]  WARNING (SLING-443/SLING-1782) 
**
 [echo] On most platforms, you'll get OutOfMemoryErrors when building 
unless you set
 [echo] on 32bit platforms: MAVEN_OPTS="-Xmx256M -XX:MaxPermSize=256M", see 
SLING-443
 [echo] on 64bit platforms: MAVEN_OPTS="-Xmx512M -XX:MaxPermSize=512M", see 
SLING-1782
 [echo] 
**
[INFO] Executed tasks
[INFO] 
[INFO] --- maven-compiler-plugin:2.5.1:compile (default-compile) @ 
org.apache.sling.jcr.jackrabbit.server ---
[INFO] Compiling 18 source files to 

[INFO] 
[INFO] --- maven-scr-plugin:1.12.0:scr (generate-scr-scrdescriptor) @ 
org.apache.sling.jcr.jackrabbit.server ---[INFO] Generating 1 MetaType 
Descriptors in 

[INFO] Writing 1 Service Component Descriptors to 

[INFO] Writing 1 Service Component Descriptors to 


[INFO] [INFO] Using 'UTF-8' encoding to copy filtered resources.

[INFO] Copying 3 resources
[INFO] --- maven-resources-plugin:2.6:copy-resources (copy-resources) @ 
org.apache.sling.jcr.jackrabbit.server ---
[INFO] 
[INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @ 
org.apache.sling.jcr.jackrabbit.server ---[INFO] Using 'UTF-8' encoding to copy 
filtered resources.
[INFO] skip non existing resourceDirectory 

[INFO] Copying 3 resources

[INFO] [INFO] No sources to compile

[INFO] --- maven-compiler-plugin:2.5.1:testCompile (default-testCompile) @ 
org.apache.sling.jcr.jackrabbit.server ---
[INFO] 
[INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @ 
org.apache.sling.jcr.jackrabbit.server ---
[JENKINS] Recording test results
[INFO] 
[INFO] Checking unresolved references to org.codehaus.mojo.signature:java15:1.0
[INFO] --- animal-sniffer-maven-plugin:1.9:check (default) @ 
org.apache.sling.jcr.jackrabbit.server ---
[INFO] 
[INFO] --- maven-bundle-plugin:2.3.7:bundle (default-bundle) @ 
org.apache.sling.jcr.jackrabbit.server ---
[WARNING] Bundle 
org.apache.sling:org.apache.sling.jcr.jackrabbit.server:bundle:2.1.1-SNAPSHOT : 
Did not find matching referal for org.apache.commons.collections.*
[WARNING] Bundle 
org.apache.sling:org.apache.sling.jcr.jackrabbit.server:bundle:2.1.1-SNAPSHOT : 
Did not find matching referal for org.apache.commons.io.*
[WARNING] Bundle 
org.apache.sling:org.apache.sling.jcr.jackrabbit.server:bundle:2.1.1-SNAPSHOT : 
Did not find matching referal for org.apache.jackrabbit.spi.commons.*
[INFO] 
[INFO] --- maven-enforcer-plugin:1.0.1:enforce (enforce-java) @ 
org.apache.sling.jcr.jackrabbit.se

Build failed in Jenkins: sling-trunk-1.6 #1712

[Apache Jenkins Server]

See 

Changes:

[cziegeler] SLING-2943 :  Classloader might not be invalidated in a cluster

--
[...truncated 6356 lines...]
[INFO] Apache Sling JCR ClassLoader .. SUCCESS [1:45.817s]
[INFO] Apache Sling Initial Content Loader ... SUCCESS [2:01.602s]
[INFO] Apache Sling Jackrabbit Embedded Repository ... FAILURE [1:01.672s]
[INFO] Apache Sling Jackrabbit UserManager Support ... SKIPPED
[INFO] Apache Sling Jackrabbit JSR-283 Access Control Manager Support  SKIPPED
[INFO] Apache Sling Wrapper Bundle for the JCR API ... SKIPPED
[INFO] Apache Sling Object Content Mapping ... SKIPPED
[INFO] Apache Sling JCR Resource Resolver  SKIPPED
[INFO] Apache Sling JCR Repository Registration .. SKIPPED
[INFO] Apache Sling Simple WebDAV Access to repositories . SKIPPED
[INFO] Apache Sling DavEx Access to repositories . SKIPPED
[INFO] Apache Sling JCR WebConsole Bundle  SKIPPED
[INFO] Apache Sling Servlet Resolver . SKIPPED
[INFO] Apache Sling Default GET Servlets . SKIPPED
[INFO] Apache Sling Default POST Servlets  SKIPPED
[INFO] Apache Sling Compat Servlets .. SKIPPED
[INFO] Apache Sling Scripting Implementation API . SKIPPED
[INFO] Apache Sling Scripting Core implementation  SKIPPED
[INFO] Apache Sling Scripting JavaScript Support . SKIPPED
[INFO] Apache Sling Scripting JSP Support  SKIPPED
[INFO] Apache Sling JSP Tag Library .. SKIPPED
[INFO] Apache Sling JSP Standard Tag Library . SKIPPED
[INFO] Apache Sling Adapter Manager Implementation ... SKIPPED
[INFO] Apache Sling Bundle Resource Provider . SKIPPED
[INFO] Apache Sling Discovery API  SKIPPED
[INFO] Apache Sling Resource-Based Discovery Service . SKIPPED
[INFO] Apache Sling Discovery Support Bundle . SKIPPED
[INFO] Apache Sling Discovery Standalone Implementation .. SKIPPED
[INFO] Apache Sling Event Support  SKIPPED
[INFO] Apache Sling Filesystem Resource Provider . SKIPPED
[INFO] Apache Sling javax.activation bundle .. SKIPPED
[INFO] Apache Sling Settings . SKIPPED
[INFO] Apache Sling Thread Dumper  SKIPPED
[INFO] Apache Sling Web Console Branding . SKIPPED
[INFO] Apache Sling Web Console Security Provider  SKIPPED
[INFO] Apache Sling Groovy Extensions  SKIPPED
[INFO] Apache Sling Explorer . SKIPPED
[INFO] Apache Sling Test Tools ... SKIPPED
[INFO] Apache Sling JUnit Core ... SKIPPED
[INFO] Apache Sling JUnit Scriptable Tests Provider .. SKIPPED
[INFO] Apache Sling JUnit Remote Tests Runners ... SKIPPED
[INFO] Apache Sling Testing Resource Resolver Mock ... SKIPPED
[INFO] Apache Sling Installer API  SKIPPED
[INFO] Apache Sling Installer  SKIPPED
[INFO] Apache Sling Installer WebConsole Plugin .. SKIPPED
[INFO] Apache Sling File Installer ... SKIPPED
[INFO] Apache Sling JCR Installer  SKIPPED
[INFO] Apache Sling Installer Configuration Admin Support  SKIPPED
[INFO] Apache Sling Deployment Package Installer . SKIPPED
[INFO] Apache Sling Installer Integration Tests .. SKIPPED
[INFO] Apache Sling Launchpad API  SKIPPED
[INFO] Apache Sling Launchpad Base ... SKIPPED
[INFO] Apache Sling Launchpad Installer .. SKIPPED
[INFO] Apache Sling Launchpad Content  SKIPPED
[INFO] Apache Sling Launchpad Application Builder  SKIPPED
[INFO] Apache Sling Sample Server-Side Tests . SKIPPED
[INFO] Apache Sling Failing Server-Side Tests  SKIPPED
[INFO] Apache Sling Sample Integration Tests . SKIPPED
[INFO] Apache Sling Launchpad Testing Services ... SKIPPED
[INFO] Apache Sling Launchpad Testing Services WAR ... SKIPPED
[INFO] Apache Sling Launchpad Testing Fragment Bundle  SKIPPED
[INFO] Apache Sling Launchpad Test Bundles ... SKIPPED
[INFO] Apache Sling Integration Tests  SKIPPED
[INFO] Apache Sling Launchpad Testing  SKIPPED
[INFO] Apache Sling Launchpad Testing WAR version  SKIPPED
[INFO] Apache Sling (Builder)  SKIPPED
[INFO] 
[INFO] BUILD FAILURE
[INFO] 
[INFO] Total time: 49:50.009s
[INFO] Finished at: Wed Jul 03 18:00:35 GMT+00:00 2013
[INFO] Final Memory: 109M/308M
[INFO] 

Re: Sling Posthandling - thougts about the current behavior

[Alexander Klimetschek]

On 03.07.2013, at 14:58, Justin Edelson  wrote:

> IMHO :operation is an aspect of the current default POST servlet. If we are
> going to move more POST-specific handling into the engine, then we should
> be using selectors.

Yes, my main point was to have only one. You are right, selector is the broader 
concept, so we could drop operation here.

Looking at the existing operations [0], IMO all of them could/should be 
replaced by a param@Something style notation. We do this with @CopyFrom 
already, same could be done with @Checkin etc. Even "import" can be done this 
way.

This moves it down from some request-global operation to a parameter specific 
option, with the benefit of allowing multiple ones in a single request. Then 
the POST is always the default create-or-modify operation.

With the new pipeline, things can hook in and either overlay the default 
behaviour for certain parameters or handle custom ones (as PostProcessors 
typically do). We should make it simpler to read and modify the special 
RequestParameter map that is passed through, it is currently quite some work to 
read a custom @Something and get the right path for it etc.

[0] 
http://sling.apache.org/site/manipulating-content-the-slingpostservlet-servletspost.html#ManipulatingContent-TheSlingPostServlet%2528servlets.post%2529-SlingPostServletOperations

Cheers,
Alex

Re: SLING-2803 validation module, hierarchical structures and extensible types

[Alexander Klimetschek]

On 03.07.2013, at 17:34, Radu Cotescu  wrote:

> 1. Currently there's no support for hierarchical structures. ValueMap
> doesn't provide this kind of support.

Yes, the jcr property value map implementation supports relative paths. This 
should definitely be supported, as you very quickly have a nested structure 
with JCR and the sling post servlet.

So field names supporting relative paths should all there is required - this is 
in line with the sling post servlet.

> 2. As long as the Field from the ValidationModel specifies a certain
> Validator to be used for validating the field's value I don't see why we
> couldn't have a Validator that checks the data in an external system. The
> single current constraint of a Validator is that it has to provide a
> validate method, returning a boolean. The implementation can be done
> however the developer  sees fit.

If the Validator is a service/component, then it can easily reference other 
services.

Cheers,
Alex

Re: Issue Adding GPG Key

[Daniel Klco]

Justin,

Thanks for the response, I was able to check out the code there, but when I
tried to check my changes back in a received the following error:

dklco@dk6d-laptop:~/Development/6ddev/workspaces/sling/sling$ svn ci -m
"Adding my GPG key"
SendingKEYS
svn: E195023: Commit failed (details follow):
svn: E195023: Changing file
'/Users/dklco/Development/6ddev/workspaces/sling/sling/KEYS' is forbidden
by the server
svn: E175013: Access to '/repos/dist/!svn/ver/1272/release/sling/KEYS'
forbidden

I imagine I will need access to that directory as well to create the actual
release.

Thanks,
Dan


On Tue, Jul 2, 2013 at 5:02 PM, Justin Edelson wrote:

> Dan-
> I'm not 100% sure, but I believe you need to "svn co
> https://dist.apache.org/repos/dist/release/sling/"; and edit the KEYS file
> there. When you commit your update, it should auto-replicate to the
> /x1/www/... directory.
>
> It looks like when the page was updated after we switched to SVN PubSub,
> Appendix A wasn't updated as well.
>
> Regards,
> Justin
>
>
> On Tue, Jul 2, 2013 at 3:13 PM, Daniel Klco  wrote:
>
> > All,
> >
> > I am getting ready to create a release for the Sling taglib changes,
> > unfortunately, I seem to have run into a snag trying to add my GPG
> > key.  According to the directions here:
> >
> >
> >
> http://sling.apache.org/documentation/development/release-management.html#appendix-a-create-and-add-your-key-to-httpwwwapacheorgdistslingkeys
> >
> > I should be able to copy the exported key into /x1/www/
> > www.apache.org/dist/sling/KEYS, however I am getting a permission denied
> > error:
> >
> > -bash: /x1/www/www.apache.org/dist/sling/KEYS: Permission denied
> >
> > Is there a new procedure or do I need to get additional permissions?  I
> > have reached out to the infrastructure team, but have not heard back.
> >
> > Thanks,
> >
> > Dan
> >
>

Re: SLING-2803 validation module, hierarchical structures and extensible types

[Carsten Ziegeler]

2013/7/3 Alexander Klimetschek 

> On 03.07.2013, at 17:34, Radu Cotescu  wrote:
>
> > 1. Currently there's no support for hierarchical structures. ValueMap
> > doesn't provide this kind of support.
>
> Yes, the jcr property value map implementation supports relative paths.
> This should definitely be supported, as you very quickly have a nested
> structure with JCR and the sling post servlet.
>
> So field names supporting relative paths should all there is required -
> this is in line with the sling post servlet.
>
>
It was a mistake to add support for paths to the jcr value map - note that
the jcr implementation of the modifiable value map does not support setting
a property with a path - same with the whole create and update stuff in
Sling's resource api. Other resource implementations don't allow paths for
properties.
If I could turn back the time I wouldn't add path support to the value map.
It creates several problems implementation wise and blures the difference
between a resource and its properties.
For all future things we should have clean approaches.

There might be resource types which require child resource (types) to exist
- and we need a way to validate this. I think the correct way would be to
have a validator which checks for such a child resource of a type and have
separate validator sets for both, the parent and the child resource.

Carsten

> 2. As long as the Field from the ValidationModel specifies a certain
> > Validator to be used for validating the field's value I don't see why we
> > couldn't have a Validator that checks the data in an external system. The
> > single current constraint of a Validator is that it has to provide a
> > validate method, returning a boolean. The implementation can be done
> > however the developer  sees fit.
>
> If the Validator is a service/component, then it can easily reference
> other services.
>
> Cheers,
> Alex
>
>


-- 
Carsten Ziegeler
cziege...@apache.org

[jira] [Commented] (SLING-2939) 3rd-party based implementation of discovery.api

[Robert Munteanu (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-2939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13699411#comment-13699411
 ] 

Robert Munteanu commented on SLING-2939:


[~egli] - JGroups can function well with UDP or TCP. I actually switched to TCP 
at some point in my cluster for more reliability, but I guess things have 
changed in the last 4 years.

As for dedicated servers vs embedded, since JGroups is easily embeddable I 
solved this problem by running a mini-app which just embedded JGroups and 
(IIRC) was designated to be the JGroups coordinator. This application being 
always available and under low load, it was a perfect fit for a coordinator. 
The details are a bit unclear for me right now, but I can dig them up if needed.

> 3rd-party based implementation of discovery.api
> ---
>
> Key: SLING-2939
> URL: https://issues.apache.org/jira/browse/SLING-2939
> Project: Sling
>  Issue Type: Task
>  Components: Extensions
>Affects Versions: Discovery API 1.0.0
>Reporter: Stefan Egli
>Assignee: Stefan Egli
>
> The Sling Discovery API introduces the abstraction of a topology which 
> contains (Sling) clusters and instances, supports liveliness-detection, 
> leader-election within a cluster and property-propagation between the 
> instances. As a default and reference implementation a resource-based, OOTB 
> implementation was created (org.apache.sling.discovery.impl).
> Pros and cons of the discovery.impl
> Although the discovery.impl supports everything required in discovery.api, it 
> has a few limitations. Here's a list of pros and cons:
> Pros
> No additional software required (leverages repository for intra-cluster 
> communication/storage and HTTP-REST calls for cross-cluster communication)
> Very small footprint
> Perfectly suited for a single clusters, instance and for small, rather 
> stable hub-based topologies
> Cons
> Config-/deployment-limitations (aka embedded-limitation): connections 
> between clusters are peer-to-peer and explicit. To span a topology, a number 
> of instances must (be made) know (to) each other, changes in the topology 
> typically requires config adjustments to guarantee high availability of the 
> discovery service
> Except if a natural "hub cluster" exists that can serve as connection 
> point for all "satellite clusters"
> Other than that, it is less suited for large and/or dynamic topologies
> Change propagation (for topology parts reported via connectors) is 
> non-atomic and slow, hop-by-hop based
> No guarantee on order of TopologyEvents sent in individual instances - ie 
> different instances might see different orders of TopologyEvents (ie changes 
> in the topology) but eventually the topology is guaranteed to be consistent
> Robustness of discovery.impl wrt storm situations depends on robustness 
> of underlying cluster (not a real negative but discovery.impl might in theory 
> unveil repository bugs which would otherwise not have been a problem)
> Rather new, little tested code which might have issues with edge cases 
> wrt network problems
> although partitioning-support is not a requirement per se, similar 
> edge-cases might exist wrt network-delays/timing/crashes
> Reusing a suitable 3rd party library
> To provide an additional option as implementation of the discovery.api one 
> idea is to use a suitable 3rd party library.
> Requirements
> The following is a list of requirements a 3rd party library must support:
> liveliness detection: detect whether an instance is up and running
> stable leader election within a cluster: stable describes the fact that a 
> leader will remain leader until it leaves/crashes and no new, joining 
> instance shall take over while a leader exists
> stable instance ordering: the list of instances within a cluster is 
> ordered and stable, new, joining instances are put at the end of the list
> property propagation: propagate the properties provided within one 
> instance to everybody in the topology. there are no timing requirements bound 
> to this but the intention of this is not to be used as messaging but to 
> announce config parameters to the topology
> support large, dynamic clusters: configuration of the new discovery 
> implementation should be easy and support frequent changes in the (large) 
> topology
> no single point of failure: this is obvious, there should of course be no 
> single point of failure in the setup
> embedded or dedicated: this might be a hot topic: embedding a library has 
> the advantages of not having to install anything additional. a dedicated 
> service on the other hand requires additional handling in deployment. 
> embedding implies a peer-to-peer setup: nodes communicate peer-t

Re: SLING-2803 validation module, hierarchical structures and extensible types

[Radu Cotescu]

Hi,

Found what Alex was talking about in the
org.apache.sling.jcr.resource.JcrPropertyMap class. I'm sorry for my
previous answer. The implementation wasn't that obvious at first.

What do you think the best approach would be given the hierarchical
structures problem and the currently proposed validation API? The
ValidationModel could describe the expected tree structure if we change the
Fields to allow them to have children (in which case, judging from a JCR
perspective, these Fields would actually translate to nodes instead of
properties).

Thanks,
Radu


Radu Cotescu | Software Engineer, Tech Blogger, Author
Web:radu.cotescu.comEmail:radu@cotescu.comCell:+40 744 406 353


On Wed, Jul 3, 2013 at 10:18 PM, Carsten Ziegeler wrote:

> 2013/7/3 Alexander Klimetschek 
>
> > On 03.07.2013, at 17:34, Radu Cotescu  wrote:
> >
> > > 1. Currently there's no support for hierarchical structures. ValueMap
> > > doesn't provide this kind of support.
> >
> > Yes, the jcr property value map implementation supports relative paths.
> > This should definitely be supported, as you very quickly have a nested
> > structure with JCR and the sling post servlet.
> >
> > So field names supporting relative paths should all there is required -
> > this is in line with the sling post servlet.
> >
> >
> It was a mistake to add support for paths to the jcr value map - note that
> the jcr implementation of the modifiable value map does not support setting
> a property with a path - same with the whole create and update stuff in
> Sling's resource api. Other resource implementations don't allow paths for
> properties.
> If I could turn back the time I wouldn't add path support to the value map.
> It creates several problems implementation wise and blures the difference
> between a resource and its properties.
> For all future things we should have clean approaches.
>
> There might be resource types which require child resource (types) to exist
> - and we need a way to validate this. I think the correct way would be to
> have a validator which checks for such a child resource of a type and have
> separate validator sets for both, the parent and the child resource.
>
> Carsten
>
> > 2. As long as the Field from the ValidationModel specifies a certain
> > > Validator to be used for validating the field's value I don't see why
> we
> > > couldn't have a Validator that checks the data in an external system.
> The
> > > single current constraint of a Validator is that it has to provide a
> > > validate method, returning a boolean. The implementation can be done
> > > however the developer  sees fit.
> >
> > If the Validator is a service/component, then it can easily reference
> > other services.
> >
> > Cheers,
> > Alex
> >
> >
>
>
> --
> Carsten Ziegeler
> cziege...@apache.org
>

Re: SLING-2803 validation module, hierarchical structures and extensible types

[Carsten Ziegeler]

As I wrote, a hierarchy is only supported by a single implementation for
reading - not for writing, so it doesn't make sense to me to support this
in validation as this can't be written through the resource api in the same
way. The post servlet is splitting paths and creates a resource for each
part of the path except the last part which is the property on the last
resource.

Carsten


2013/7/4 Radu Cotescu 

> Hi,
>
> Found what Alex was talking about in the
> org.apache.sling.jcr.resource.JcrPropertyMap class. I'm sorry for my
> previous answer. The implementation wasn't that obvious at first.
>
> What do you think the best approach would be given the hierarchical
> structures problem and the currently proposed validation API? The
> ValidationModel could describe the expected tree structure if we change the
> Fields to allow them to have children (in which case, judging from a JCR
> perspective, these Fields would actually translate to nodes instead of
> properties).
>
> Thanks,
> Radu
>
>
> Radu Cotescu | Software Engineer, Tech Blogger, Author
> Web:radu.cotescu.comEmail:radu@cotescu.comCell:+40 744 406 353
>
>
> On Wed, Jul 3, 2013 at 10:18 PM, Carsten Ziegeler  >wrote:
>
> > 2013/7/3 Alexander Klimetschek 
> >
> > > On 03.07.2013, at 17:34, Radu Cotescu  wrote:
> > >
> > > > 1. Currently there's no support for hierarchical structures. ValueMap
> > > > doesn't provide this kind of support.
> > >
> > > Yes, the jcr property value map implementation supports relative paths.
> > > This should definitely be supported, as you very quickly have a nested
> > > structure with JCR and the sling post servlet.
> > >
> > > So field names supporting relative paths should all there is required -
> > > this is in line with the sling post servlet.
> > >
> > >
> > It was a mistake to add support for paths to the jcr value map - note
> that
> > the jcr implementation of the modifiable value map does not support
> setting
> > a property with a path - same with the whole create and update stuff in
> > Sling's resource api. Other resource implementations don't allow paths
> for
> > properties.
> > If I could turn back the time I wouldn't add path support to the value
> map.
> > It creates several problems implementation wise and blures the difference
> > between a resource and its properties.
> > For all future things we should have clean approaches.
> >
> > There might be resource types which require child resource (types) to
> exist
> > - and we need a way to validate this. I think the correct way would be to
> > have a validator which checks for such a child resource of a type and
> have
> > separate validator sets for both, the parent and the child resource.
> >
> > Carsten
> >
> > > 2. As long as the Field from the ValidationModel specifies a certain
> > > > Validator to be used for validating the field's value I don't see why
> > we
> > > > couldn't have a Validator that checks the data in an external system.
> > The
> > > > single current constraint of a Validator is that it has to provide a
> > > > validate method, returning a boolean. The implementation can be done
> > > > however the developer  sees fit.
> > >
> > > If the Validator is a service/component, then it can easily reference
> > > other services.
> > >
> > > Cheers,
> > > Alex
> > >
> > >
> >
> >
> > --
> > Carsten Ziegeler
> > cziege...@apache.org
> >
>



-- 
Carsten Ziegeler
cziege...@apache.org

Re: @Adapter methods, ready to integrate in trunk, WDYT?

[Carsten Ziegeler]

For now I'm against committing this to trunk, as previously mentioned I
would prefer having a build time annotation. If this is not possible, then
the annotation and the AdapterProvider should be in the same package as
there is no use case for using one without the other.

One solution for a build time annotation would be to define a server
registration property for a AdapterProvider containing the method names and
at  build time the value of this property would be generated by using the
annotation. This would be similar to the bind/unbind methods of DS.

Regards
Carsten


2013/7/3 Carsten Ziegeler 

> Just read the answer in the issue :)
>
> I like the general intention - however it feels a little bit strange to
> register a AdapterProvider, annotate a method and then this gets picked up
> at runtime and a new AdapterFactory is registered.
> Can't we make this annoation build time only - as an extensions of the SCR
> annotations?
>
> Carsten
>
>
> 2013/7/3 Carsten Ziegeler 
>
>> Hi,
>>
>> sounds interesting - could you please elaborate a little bit on who is
>> processing this annotation and when?
>>
>> Thanks
>> Carsten
>>
>>
>> 2013/7/3 Bertrand Delacretaz 
>>
>>> On Wed, Jul 3, 2013 at 3:07 PM, Justin Edelson 
>>> wrote:
>>> ...
>>> > @Adapter(condition="if the resource type is slingbucks/list").
>>> ...
>>>
>>> Makes sense, noted in SLING-2938
>>> -Bertrand
>>>
>>
>>
>>
>> --
>> Carsten Ziegeler
>> cziege...@apache.org
>>
>
>
>
> --
> Carsten Ziegeler
> cziege...@apache.org
>



-- 
Carsten Ziegeler
cziege...@apache.org