[jira] [Assigned] (SLING-6126) Ability to specify TTL for separate health check

[Georg Henzler (JIRA)]

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

Georg Henzler reassigned SLING-6126:


Assignee: Georg Henzler

> Ability to specify TTL for separate health check
> 
>
> Key: SLING-6126
> URL: https://issues.apache.org/jira/browse/SLING-6126
> Project: Sling
>  Issue Type: Improvement
>  Components: Health Check
>Reporter: Evgeniy Fitsner
>    Assignee: Georg Henzler
>
> Currently there is no ability to specify TTL for separate health check.
> Ex.: in my case "hc" validating against repository about 3-5 minutes 
> therefore I couldn't specify TTL globally to not impact on other "hc" 
> results. This "hc" I couldn't execute by scheduler to prevent CPU from high 
> loading, also results for this check remains relevant for an 1-3 hours.
> Therefore if it make sense not only for me I've added "[pull 
> request|https://github.com/apache/sling/pull/180]; for this functionality:
> * If property "hc.ttl" specified within HC - it will be used as TTL for 
> result, otherwise cache will use default TTL value



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-5827) HealthCheckMetadata wrongly assumes (String) SERVICE_PID

[Georg Henzler (JIRA)]

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

Georg Henzler commented on SLING-5827:
--

[~kwin]  [~cziegeler]'s changes for SLING-5839 fixed it to use SERVICE_ID 
instead of SERVICE_PID (although the SERVICE_PID is still used to derive a more 
speaking HC name if available). Generally it's best to explicitly set the 
service property "hc.name" (the use of SERVICE_ID/SERVICE_PID in 
getHealthCheckTitle() is only a fallback mechanism)

> HealthCheckMetadata wrongly assumes (String) SERVICE_PID 
> -
>
> Key: SLING-5827
> URL: https://issues.apache.org/jira/browse/SLING-5827
> Project: Sling
>  Issue Type: Bug
>  Components: Health Check
>Affects Versions: Health Check Core 1.2.4
>Reporter: Ivo Leitão
>Assignee: Bertrand Delacretaz
>Priority: Critical
> Fix For: Health Check Core 1.2.6
>
>
> I'm getting a classcastexception in the healthcheck component. This is 
> happenning only for my components (don't know why :-S).
> I have looked at the source code and in my case at the 
> AsyncHelthCheckExecutor the code passes the lines bellow
> {code:title=AsyncHelthCheckExecutor.java|borderStyle=solid}
> ServiceReference serviceReference = event.getServiceReference();
> final boolean isHealthCheck = 
> serviceReference.isAssignableTo(bundleContext.getBundle(), 
> HealthCheck.class.getName());
> if (isHealthCheck) {
> // True at my case
> }
> {code}
> Later in the method getHealthCheckTitle of the class HealthCheckMetadata at 
> the line bellow:
> {code:title=HealthCheckMetadata.java|borderStyle=solid}
>  if (StringUtils.isBlank(name)) {
> name = (String) ref.getProperty(Constants.SERVICE_PID);
> }
> {code}
> ref.getProperty(Constants.SERVICE_PID) is returning an ArrayList and I have 
> the stacktrace bellow as a result
> {code:title=Stacktrace|borderStyle=solid}
> java.lang.ClassCastException: java.util.ArrayList cannot be cast to 
> java.lang.String
>   at 
> org.apache.sling.hc.util.HealthCheckMetadata.getHealthCheckTitle(HealthCheckMetadata.java:146)
>   at 
> org.apache.sling.hc.util.HealthCheckMetadata.(HealthCheckMetadata.java:53)
>   at 
> org.apache.sling.hc.core.impl.executor.AsyncHealthCheckExecutor.serviceChanged(AsyncHealthCheckExecutor.java:114)
>   at 
> org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:991)
>   at 
> org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:839)
>   at 
> org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:546)
>   at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4557)
>   at org.apache.felix.framework.Felix.registerService(Felix.java:3549)
>   at 
> org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:348)
>   at 
> org.apache.felix.scr.impl.manager.AbstractComponentManager$3.register(AbstractComponentManager.java:869)
>   at 
> org.apache.felix.scr.impl.manager.AbstractComponentManager$3.register(AbstractComponentManager.java:857)
>   at 
> org.apache.felix.scr.impl.manager.RegistrationManager.changeRegistration(RegistrationManager.java:133)
>   at 
> org.apache.felix.scr.impl.manager.AbstractComponentManager.registerService(AbstractComponentManager.java:915)
>   at 
> org.apache.felix.scr.impl.manager.AbstractComponentManager.activateInternal(AbstractComponentManager.java:715)
>   at 
> org.apache.felix.scr.impl.manager.AbstractComponentManager.enable(AbstractComponentManager.java:399)
>   at 
> org.apache.felix.scr.impl.config.ConfigurableComponentHolder.enableComponents(ConfigurableComponentHolder.java:676)
>   at 
> org.apache.felix.scr.impl.BundleComponentActivator.initialEnable(BundleComponentActivator.java:339)
>   at 
> org.apache.felix.scr.impl.Activator.loadComponents(Activator.java:360)
>   at org.apache.felix.scr.impl.Activator.access$000(Activator.java:53)
>   at 
> org.apache.felix.scr.impl.Activator$ScrExtension.start(Activator.java:260)
>   at 
> org.apache.felix.utils.extender.AbstractExtender.createExtension(AbstractExtender.java:259)
>   at 
> org.apache.felix.utils.extender.AbstractExtender.modifiedBundle(AbstractExtender.java:232)
>   at 
> org.osgi.util.tracker.BundleTracker$Tracked.customizerModified(BundleTracker.java:482)
>   at 
&g

Re: [context-aware config] java package name

[Georg Henzler]

just removing the ".".


+1 for removing the dot (if it was to be kept, at least it would have to 
be "o.a.s.config.contextaware" instead of "o.a.s.contextaware.config" to 
be a meaningful hierarchy).


regarding d) other proposals:

As o.a.s.contextawareconfig gets fairly long, using the brief 
"o.a.s.caconfig" could be better. Although a little bit cryptic at 
first, it still clearly shows that it is about a configuration mechanism 
and people will quickly get used to what "ca" means. Also "caconfig" 
will be fairly unique when googling it.


-Georg

[jira] [Commented] (SLING-6126) Ability to specify TTL for separate health check

[Georg Henzler (JIRA)]

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

Georg Henzler commented on SLING-6126:
--

If it is a DevOps Setup that checks for the health of an instance after 
deployment, probably it's better to first call
/system/health/regularcheckstag.txt <-- returns quickly for the case something 
basic went wrong
and then 
/system/health/longrunningchecktag.txt?timeout=360 <-- this can be waited 
for synchronously and will return exactly after the long running check is 
finished.

Would that work for you? If not, I'm not opposed to add the TTL config setting 
for individual HCs (see my comments in PR), just questioning if it really 
provides value or just adds additional complexity.

> Ability to specify TTL for separate health check
> 
>
> Key: SLING-6126
> URL: https://issues.apache.org/jira/browse/SLING-6126
> Project: Sling
>  Issue Type: Improvement
>  Components: Health Check
>Reporter: Evgeniy Fitsner
>
> Currently there is no ability to specify TTL for separate health check.
> Ex.: in my case "hc" validating against repository about 3-5 minutes 
> therefore I couldn't specify TTL globally to not impact on other "hc" 
> results. This "hc" I couldn't execute by scheduler to prevent CPU from high 
> loading, also results for this check remains relevant for an 1-3 hours.
> Therefore if it make sense not only for me I've added "[pull 
> request|https://github.com/apache/sling/pull/180]; for this functionality:
> * If property "hc.ttl" specified within HC - it will be used as TTL for 
> result, otherwise cache will use default TTL value



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-6126) Ability to specify TTL for separate health check

[Georg Henzler (JIRA)]

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

Georg Henzler commented on SLING-6126:
--

[~drfits] Would using hc.async.cronExpression (see 
https://sling.apache.org/documentation/bundles/sling-health-check-tool.html#configuring-health-checks)
 be an option? The problem of just extending the TTL is, that users calling the 
long-running HC after a TTL has expired will not receive a result but a timeout 
(only a reload after 3-5 minutes gives an adequate result then). Using an async 
HC will never return a timeout (but always the last result).

> Ability to specify TTL for separate health check
> 
>
> Key: SLING-6126
> URL: https://issues.apache.org/jira/browse/SLING-6126
> Project: Sling
>  Issue Type: Improvement
>  Components: Health Check
>Reporter: Evgeniy Fitsner
>
> Currently there is no ability to specify TTL for separate health check.
> Ex.: in my case "hc" validating against repository about 3-5 minutes 
> therefore I couldn't specify TTL globally to not impact on other "hc" 
> results. This "hc" I couldn't execute by scheduler to prevent CPU from high 
> loading, also results for this check remains relevant for an 1-3 hours.
> Therefore if it make sense not only for me I've added "[pull 
> request|https://github.com/apache/sling/pull/180]; for this functionality:
> * If property "hc.ttl" specified within HC - it will be used as TTL for 
> result, otherwise cache will use default TTL value



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Sling IDE: Lifecycle Mapping Extension Point

[Georg Henzler]

If I remember it correctly, it was needed to make the project 
configurator work at all. Note that ContentPackageLifecycleMapping is 
not just empty but extends AbstractCustomizableLifecycleMapping [1] and 
this code only becomes active for content packages because of the 
reference chain [2]. But maybe the situation has changed with current 
m2e versions, might be worth checking what impact removing the 
ContentPackageLifecycleMapping has.


Regards
Georg

[1]
https://github.com/jvanzyl/m2e-core/blob/master/org.eclipse.m2e.core/src/org/eclipse/m2e/core/project/configurator/AbstractCustomizableLifecycleMapping.java

[2]
packaging "content-package" -> id 
"org.apache.sling.ide.eclipse.m2e.contentPackageLifecycleMapping" -> 
ContentPackageLifecycleMapping that extends 
AbstractCustomizableLifecycleMapping

https://github.com/apache/sling/blob/trunk/tooling/ide/eclipse-m2e-ui/lifecycle-mapping-metadata.xml#L40
https://github.com/apache/sling/blob/trunk/tooling/ide/eclipse-m2e-ui/lifecycle-mapping-metadata.xml#L41
https://github.com/apache/sling/blob/trunk/tooling/ide/eclipse-m2e-ui/plugin.xml#L64
https://github.com/apache/sling/blob/trunk/tooling/ide/eclipse-m2e-ui/plugin.xml#L65


On 2016-10-10 15:05, Konrad Windszus wrote:

In
https://github.com/apache/sling/blob/trunk/tooling/ide/eclipse-m2e-ui/lifecycle-mapping-metadata.xml#L41
<https://github.com/apache/sling/blob/trunk/tooling/ide/eclipse-m2e-ui/lifecycle-mapping-metadata.xml#L41>
we have referenced the explicit lifecycle mapping id from
https://github.com/apache/sling/blob/trunk/tooling/ide/eclipse-m2e-ui/plugin.xml#L62
<https://github.com/apache/sling/blob/trunk/tooling/ide/eclipse-m2e-ui/plugin.xml#L62>
which references the class
https://github.com/apache/sling/blob/trunk/tooling/ide/eclipse-m2e-ui/src/org/apache/sling/ide/eclipse/m2e/internal/ContentPackageLifecycleMapping.java
<https://github.com/apache/sling/blob/trunk/tooling/ide/eclipse-m2e-ui/src/org/apache/sling/ide/eclipse/m2e/internal/ContentPackageLifecycleMapping.java>.
The latter is empty.
I am wondering why the lifecycle mapping extension point was ever
necessary because we do nothing specific in
ContentPackageLifecycleMapping.java
<https://github.com/apache/sling/blob/trunk/tooling/ide/eclipse-m2e-ui/src/org/apache/sling/ide/eclipse/m2e/internal/ContentPackageLifecycleMapping.java>
and m2e should be able to come up with a a default lifecycle id based
on the configured plugin executions.

If there is no good reason for that, I would rather get rid of the
explicit lifecycle mapping id and only configure the plugin execution
similar to the one for maven-bundle-plugin.

@Georg Henzler: Because the original source code was contributed by
you in https://issues.apache.org/jira/browse/SLING-3100
<https://issues.apache.org/jira/browse/SLING-3100> maybe you can share
your thoughts.

Thanks,
Konrad

Re: [ANN] Welcome Georg Henzler as our latest Sling committer!

[Georg Henzler]

Hi all,

thanks for the warm welcome. Regarding my brief introduction: I opened 
my first html tag in 1998 and have mostly worked in the "Java Web Space" 
since then (with some short detours to PHP and .NET). I came across 
Sling in 2009 the first time and starting contributing in 2013 with some 
additions to the Sling Health Checks.


Great to be on board!

Georg

On 2016-10-01 13:34, Konrad Windszus wrote:

Welcome Georg!
Good to have you on board.
Konrad


Am 01.10.2016 um 00:56 schrieb Robert Munteanu <romb...@apache.org>:

Welcome, Georg!

Looking forward to more free time now that you can commit your own
patches :-)

Robert

On Fri, 2016-09-30 at 21:42 +0530, Chetan Mehrotra wrote:

Welcome Georg!
Chetan Mehrotra


On Fri, Sep 30, 2016 at 9:24 PM, Stefan Seifert <sseifert@pro-vision.
de> wrote:

welcome, georg!

stefan


-Original Message-
From: Bertrand Delacretaz [mailto:bdelacre...@apache.org]
Sent: Friday, September 30, 2016 3:41 PM
To: dev
Subject: [ANN] Welcome Georg Henzler as our latest Sling
committer!

Hi,

I'm pleased to announce that the Sling PMC has elected Georg as
our
new Sling committer, and he has accepted, please welcome
ghenz...@apache.org !

Georg we do know you a bit already but if you want to honor the
old
tradition of new committers briefly introducing themselves to the
list, feel free.

-Bertrand

Re: [VOTE] Release Apache Sling Oak Restrictions version 1.0.0

[Georg Henzler]

+1 (and thanks for taking care of the release)

Georg


On 2016-09-27 23:17, Daniel Klco wrote:

+1

I updated my GPG keys as such:

wget https://people.apache.org/keys/group/sling.asc -q -O 
/tmp/sling.asc

gpg --import /tmp/sling.asc &> /dev/null

And the signatures look good.

On Tue, Sep 27, 2016 at 5:13 PM, Robert Munteanu  
wrote:



On Tue, 2016-09-27 at 22:50 +0200, Karl Pauls wrote:
> I'm getting bad sigs. I think i don't see your key in
> https://people.apache.org/keys/group/sling.asc - is it possible that
> you
> didn't add your gpg key id to your id.apache.org account (or that it
> is not
> available via a public server)?

Hm, that's weird.

My public key is set as 4F63EC54 via id.apache.org . Also

$ gpg --recv-keys 4F63EC54
gpg: key 339508654F63EC54: "Robert Munteanu " not
changed
gpg: Total number processed: 1
gpg:  unchanged: 1

Robert

>
> regards,
>
> Karl
>
> On Tue, Sep 27, 2016 at 10:32 PM, Robert Munteanu  >
> wrote:
>
> > Hi,
> >
> > We solved 4 issues in this release:
> > https://issues.apache.org/jira/browse/SLING/fixforversion/12337877
> >
> > Staging repository:
> > https://repository.apache.org/content/repositories/orgapachesling-1
> > 527
> >
> > You can use this UNIX script to download the release and verify the
> > signatures:
> > http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh
> >
> > Usage:
> > sh check_staged_release.sh 1527 /tmp/sling-staging
> >
> > Please vote to approve this release:
> >
> >   [ ] +1 Approve the release
> >   [ ]  0 Don't care
> >   [ ] -1 Don't release, because ...
> >
> > This majority vote is open for at least 72 hours.
> >
>
>
>
>
>

Re: Sling Oak Restrictions - Release 1.0.0 now?

[Georg Henzler]

Hi,

this makes sense, so I updated SLING-6045 and created a PR [1]. If 
everyone is happy with this version, maybe we can merge and create a 
first release?


Regards
Georg

[1]
https://github.com/apache/sling/pull/173

On 2016-09-09 15:08, Konrad Windszus wrote:

I am also in favour of putting it in contrib/extensions and name the
package/artifact id org.apache.sling.oak.restriction.
Konrad


Am 08.09.2016 um 22:32 schrieb Oliver Lietz <apa...@oliverlietz.de>:

On Thursday 08 September 2016 17:48:24 Georg Henzler wrote:

Hi Oliver,


Hi Georg,

if we call it "oak", we probably would have to also create a sub 
folder

contrib/oak (as all modules in contrib/jcr have the group id
org.apache.sling.jcr)... that's probably more confusing than just
leaving it in contrib/jcr (having jcr and oak side by side when oak 
also

provides the jcr). Robert, what do you think?


I'm fine with it in contrib/extensions and moving it around in SVN is 
not a

problem in contrast to changing packages later.

Regards,
O.


Regards
Georg

[...]

[jira] [Commented] (SLING-6045) Improve java package and GAV for oak restrictions

[Georg Henzler (JIRA)]

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

Georg Henzler commented on SLING-6045:
--

Adjusted Ticket Title/Description after discussion in mailing list: 
https://www.mail-archive.com/dev@sling.apache.org/msg59177.html

> Improve java package and GAV for oak restrictions
> -
>
> Key: SLING-6045
> URL: https://issues.apache.org/jira/browse/SLING-6045
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>    Reporter: Georg Henzler
>Assignee: Robert Munteanu
>
> Right now the Bundle-SymbolicName is org.apache.sling.sling-oak-
> restrictions and it's placed under contrib/extensions . It should rather be 
> named org.apache.sling.oak.restrictions.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLING-6045) Improve java package and GAV for oak restrictions

[Georg Henzler (JIRA)]

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

Georg Henzler updated SLING-6045:
-
Summary: Improve java package and GAV for oak restrictions  (was: Move 
oak-restrictions bundle to contrib/jcr, rename java package and GAV)

> Improve java package and GAV for oak restrictions
> -
>
> Key: SLING-6045
> URL: https://issues.apache.org/jira/browse/SLING-6045
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>    Reporter: Georg Henzler
>Assignee: Robert Munteanu
>
> Right now the Bundle-SymbolicName is org.apache.sling.sling-oak-
> restrictions and it's placed under contrib/extensions . It should rather be 
> named org.apache.sling.jcr.oak-restrictions and placed under
> contrib/jcr.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLING-6045) Improve java package and GAV for oak restrictions

[Georg Henzler (JIRA)]

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

Georg Henzler updated SLING-6045:
-
Description: 
Right now the Bundle-SymbolicName is org.apache.sling.sling-oak-
restrictions and it's placed under contrib/extensions . It should rather be 
named org.apache.sling.oak.restrictions.

  was:
Right now the Bundle-SymbolicName is org.apache.sling.sling-oak-
restrictions and it's placed under contrib/extensions . It should rather be 
named org.apache.sling.jcr.oak-restrictions and placed under
contrib/jcr.


> Improve java package and GAV for oak restrictions
> -
>
> Key: SLING-6045
> URL: https://issues.apache.org/jira/browse/SLING-6045
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>    Reporter: Georg Henzler
>Assignee: Robert Munteanu
>
> Right now the Bundle-SymbolicName is org.apache.sling.sling-oak-
> restrictions and it's placed under contrib/extensions . It should rather be 
> named org.apache.sling.oak.restrictions.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Sling Oak Restrictions - Release 1.0.0 now?

[Georg Henzler]

Hi Oliver,

if we call it "oak", we probably would have to also create a sub folder 
contrib/oak (as all modules in contrib/jcr have the group id 
org.apache.sling.jcr)... that's probably more confusing than just 
leaving it in contrib/jcr (having jcr and oak side by side when oak also 
provides the jcr). Robert, what do you think?


Regards
Georg

On 2016-09-07 22:33, Oliver Lietz wrote:

On Monday 01 August 2016 13:37:26 Robert Munteanu wrote:

Hi Georg,


Hi,


On Sat, 2016-07-30 at 10:14 +0200, Georg Henzler wrote:
> Hi all,
>
> with SLING-5768/SLING-5891 fixed and the documentation in
> https://sling.apache.org/documentation/bundles/sling-oak-restrictions
> .html
> we have everything needed to cut a first release IMHO - could
> someone
> take care of it?

I think we need to clarify two issues:

1. Bundle name and location

Right now the Bundle-SymbolicName is org.apache.sling.sling-oak-
restrictions and it's placed under contrib/extensions . I would rather
see it named org.apache.sling.jcr.oak-restrictions and placed under
contrib/jcr .


the bundle is not using JCR API but Oak API only
(org.apache.jackrabbit.oak.spi.security.authorization.restriction). 
Shouldn't
we go for a simple module and package name 
org.apache.sling.oak.restriction?


Regards,
O.


2. Naming of the restrictions

There was some discussion related to the name of the
'sling:resourceTypesWithChildren' restriction [1]. I want to make sure
that we have agreement that this is the best name what we could come 
up

with before releasing and committing to this name "forever".

Once these are agreed on, I can take care of an initial release.

Robert

[1]: https://issues.apache.org/jira/browse/SLING-5768

Re: Sling Oak Restrictions - Release 1.0.0 now?

[Georg Henzler]

Hi Robert,

thanks for merging SLING-6042. For your comment regarding the better 
location contrib/jcr I created SLING-6045 including a PR. So if everyone 
is happy with this version then, it would be great to have a first 
release!


Regards
Georg

On 2016-08-01 12:37, Robert Munteanu wrote:


1. Bundle name and location

Right now the Bundle-SymbolicName is org.apache.sling.sling-oak-
restrictions and it's placed under contrib/extensions . I would rather
see it named org.apache.sling.jcr.oak-restrictions and placed under
contrib/jcr .

[jira] [Created] (SLING-6045) Move oak-restrictions bundle to contrib/jcr, rename java package and GAV

[Georg Henzler (JIRA)]

Georg Henzler created SLING-6045:


 Summary: Move oak-restrictions bundle to contrib/jcr, rename java 
package and GAV
 Key: SLING-6045
 URL: https://issues.apache.org/jira/browse/SLING-6045
 Project: Sling
  Issue Type: Improvement
  Components: Extensions
Reporter: Georg Henzler
Assignee: Robert Munteanu


Right now the Bundle-SymbolicName is org.apache.sling.sling-oak-
restrictions and it's placed under contrib/extensions . It should rather be 
named org.apache.sling.jcr.oak-restrictions and placed under
contrib/jcr.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-5768) Introduce sling:resourceTypes as extension to Oak permission system

[Georg Henzler (JIRA)]

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

Georg Henzler commented on SLING-5768:
--

Created follow up ticket for PR: SLING-6042

> Introduce sling:resourceTypes as extension to Oak permission system
> ---
>
> Key: SLING-5768
> URL: https://issues.apache.org/jira/browse/SLING-5768
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>    Reporter: Georg Henzler
>Assignee: Robert Munteanu
> Fix For: Oak Restrictions 1.0.0
>
>
> Oak allows to extend its permissions management by using custom restrictions 
> \[1], also the standard oak restrictions are based on this and are 
> implemented in a fairly straight-forward way \[2] (example is for 
> rep:ntNames). 
> It would be nice to have sling level restrictions using sling properties in 
> general. This issue is about introducing a restriction on resource types - 
> the following should be possible:
> {code}
> - /content/mynode 
>- rep:policy (rep:ACL)
>  - allow (rep:GrantACE)
>+ principalName (String) = "myAuthorizable"
>+ rep:privileges (Name[]) = "rep:write"
>- rep:restrictions (rep:Restrictions)
>   +   sling:resourceTypes (String[]) = 
> [myproj/resourcetype1,myproj/resourcetype2]
> {code}
> The example would only grant "rep:write" for the resource types 
> myproj/resourcetype1 and myproj/resourcetype2 in path /content/mynode, other 
> resources under path /content/mynode would not have "rep:write" permissions. 
> Additionally to strict resource type matching it shall be possible to 
> automatically match a resource with a given resource type including all 
> children. Also, not all content nodes have a resource type, therefore it 
> should be possible to match against a child node by appending \@path to the 
> resource type: 
> {code}
> - /content/myprj 
>- rep:policy (rep:ACL)
>  - allow (rep:GrantACE)
>+ principalName (String) = "myAuthorizable"
>+ rep:privileges (Name[]) = "rep:write"
>- rep:restrictions (rep:Restrictions)
>   +   sling:resourceTypesWithChildren (String[]) = 
> [myproj/resourcetype1@jcr:content]
> {code}
> To achieve this any path match attempt traverses the parents and checks for a 
> match (but only up to the base path, /content/myprj in this example). For AEM 
> use cases, this can match a whole page structure (e.g. something like 
> /content/myprj/path/to/newsoverview, the whole news section can be easily 
> matched by having a distinct news overview template). 
> \[1]
> https://jackrabbit.apache.org/oak/docs/security/authorization/restriction.html#Pluggability
> \[2]
> https://github.com/apache/jackrabbit-oak/blob/cea167f5bf70d818d58b1ffcc6bc65b3c0f9a5a4/oak-core/src/main/java/org/apache/jackrabbit/oak/security/authorization/restriction/NodeTypePattern.java#L50)
> https://github.com/apache/jackrabbit-oak/blob/cea167f5bf70d818d58b1ffcc6bc65b3c0f9a5a4/oak-core/src/main/java/org/apache/jackrabbit/oak/security/authorization/restriction/RestrictionProviderImpl.java



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (SLING-6042) Use sling:resourceTypesWithDescendants instead of sling:resourceTypesWithChildren

[Georg Henzler (JIRA)]

Georg Henzler created SLING-6042:


 Summary: Use sling:resourceTypesWithDescendants instead of 
sling:resourceTypesWithChildren
 Key: SLING-6042
 URL: https://issues.apache.org/jira/browse/SLING-6042
 Project: Sling
  Issue Type: Improvement
  Components: Extensions
Reporter: Georg Henzler
Assignee: Robert Munteanu
 Fix For: Oak Restrictions 1.0.0


After some discussion at [1], the current version of the oak restrictions 
initially committed with SLING-5768 should be updated to use 
sling:resourceTypesWithDescendants instead of sling:resourceTypesWithChildren 
(the latter is semantically not correct as not only the children are matched 
but all descendants, thanks [~jsedding] for pointing this out). 

The documentation has already been updated via SLING-5890 and is available at 
[2]

[1] https://www.mail-archive.com/dev@sling.apache.org/msg58935.html
[2] https://sling.apache.org/documentation/bundles/sling-oak-restrictions.html




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Sling Oak Restrictions - Release 1.0.0 now?

[Georg Henzler]

Hi Robert,

I updated SLING-5768 and SLING-5890 (markdown docu) for using 
sling:resourceTypesWithDescendants. If everyone is reasonably happy with 
it, I think we should just go with that :)


Regards
Georg


On 2016-08-01 13:56, Georg Henzler wrote:

Hi Julian,

good point that "descendants" is actually clearer than "children"...
that gives two options IMHO:

- sling:resourceTypesDeep <-- less descriptive but also shorter
- sling:resourceTypesWithDescendants <-- I think clearer, but longer

For the simple match, I would stick with the short name 
sling:resourceTypes

as it is more in line with the standard oak restrictions.

Regards
Georg

On 2016-08-01 13:48, Julian Sedding wrote:

Hi Georg

I think "...WithChildren" is misleading, because, per my understanding
of the documentation, it means "with descendants".

Maybe restriction names with "shallow" and/or "deep" would be more
self-documenting?

E.g. "sling:resourceTypesShallow" and "sling:resourceTypesDeep".

WDYT?

Regards
Julian


On Mon, Aug 1, 2016 at 1:32 PM, Georg Henzler <slin...@ghenzler.de> 
wrote:

Hi Robert,

... I would rather see it named 
org.apache.sling.jcr.oak-restrictions

and placed under contrib/jcr .



That sounds like a better location, +1 to move


There was some discussion related to the name of the
'sling:resourceTypesWithChildren' restriction [1]. I want to make 
sure

that we have agreement that this is the best name



I think sling:resourceTypesWithChildren is the clearest suggestion up 
to now
([1] gives an example). From a pure user point of view, the terms 
"parent"
or "ancestry" would be rather misleading, because what is matched by 
the
restriction in the end are nodes below (and not above) the matched 
node with
the given resource type, e.g. the restriction matches a node with 
resource

type "myproj/news" with (or including) all children.

Regards
Georg


[1]
https://sling.apache.org/documentation/bundles/sling-oak-restrictions.html#restriction-slingresourcetypeswithchildren

[jira] [Commented] (SLING-5890) Documentation for the new sling oak restrictions from SLING-5768

[Georg Henzler (JIRA)]

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

Georg Henzler commented on SLING-5890:
--

Updated attached sling-oak-restrictions.mdtext

> Documentation for the new sling oak restrictions from SLING-5768
> 
>
> Key: SLING-5890
> URL: https://issues.apache.org/jira/browse/SLING-5890
> Project: Sling
>  Issue Type: Task
>  Components: Documentation
>    Reporter: Georg Henzler
>Assignee: Robert Munteanu
> Attachments: sling-oak-restrictions.mdtext
>
>
> Attached the markdown file for the documentation of SLING-5768, I suppose the 
> best location for it is 
> sling/site/trunk/content/documentation/bundles/sling-oak-restrictions.mdtext 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLING-5890) Documentation for the new sling oak restrictions from SLING-5768

[Georg Henzler (JIRA)]

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

Georg Henzler updated SLING-5890:
-
Attachment: (was: sling-oak-restrictions.mdtext)

> Documentation for the new sling oak restrictions from SLING-5768
> 
>
> Key: SLING-5890
> URL: https://issues.apache.org/jira/browse/SLING-5890
> Project: Sling
>  Issue Type: Task
>  Components: Documentation
>    Reporter: Georg Henzler
>Assignee: Robert Munteanu
> Attachments: sling-oak-restrictions.mdtext
>
>
> Attached the markdown file for the documentation of SLING-5768, I suppose the 
> best location for it is 
> sling/site/trunk/content/documentation/bundles/sling-oak-restrictions.mdtext 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLING-5890) Documentation for the new sling oak restrictions from SLING-5768

[Georg Henzler (JIRA)]

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

Georg Henzler updated SLING-5890:
-
Attachment: sling-oak-restrictions.mdtext

> Documentation for the new sling oak restrictions from SLING-5768
> 
>
> Key: SLING-5890
> URL: https://issues.apache.org/jira/browse/SLING-5890
> Project: Sling
>  Issue Type: Task
>  Components: Documentation
>    Reporter: Georg Henzler
>Assignee: Robert Munteanu
> Attachments: sling-oak-restrictions.mdtext, 
> sling-oak-restrictions.mdtext
>
>
> Attached the markdown file for the documentation of SLING-5768, I suppose the 
> best location for it is 
> sling/site/trunk/content/documentation/bundles/sling-oak-restrictions.mdtext 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-5992) Provide a way to map Sling Model classes to resource types

[Georg Henzler (JIRA)]

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

Georg Henzler commented on SLING-5992:
--

How is this different from just calling {{resource.adaptTo(MyModel.class)}} or 
{{request.adaptTo(MyModel.class)}}?

> Provide a way to map Sling Model classes to resource types
> --
>
> Key: SLING-5992
> URL: https://issues.apache.org/jira/browse/SLING-5992
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>Reporter: Justin Edelson
> Fix For: Sling Models API 1.3.0, Sling Models Impl 1.3.0
>
> Attachments: SLING-5992.patch
>
>
> For ease of script development, I would like to introduce a mechanism for 
> mapping Sling Model classes to resource types for Resource and 
> SlingHttpServletRequest objects.
> From an API perspective, this introduces two new methods on ModelFactory:
> {code}
> public Object getModelFromResource(@Nonnull Resource resource);
> public Object getModelFromRequest(@Nonnull SlingHttpServletRequest request);
> {code}
> And a new attribute on the @Model annotations
> {code}
> public String resourceType() default "";
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Sling Oak Restrictions bundle

[Georg Henzler]

There is an open discussion regarding naming [1] that needs to be
resolved before
the first release, maybe you want to add your 50cents?

[1]
http://markmail.org/message/tktlvizm6fmo2wam

Sent from my phone

On 05.08.2016, at 14:15, Nitin Nizhawan  wrote:

Hi,

  We  have a use case where we need to use resourceType based restrictions
as described in [0], but this [1] bundle which implements this is not yet
available in maven central.  Could someone please release  this bundle?
Please let me know if I can help in anyway.

[0]
https://sling.apache.org/documentation/bundles/sling-oak-restrictions.html
[1]
https://github.com/apache/sling/tree/trunk/contrib/extensions/sling-oak-restrictions
Thanks
Nitin

Re: [Context Aware Configs] Merging?

[Georg Henzler]

>> * Puppet (not too sure about the others) is not exactly great at dealing
>> with xml files
>> * FileVault [1] is only available in Java, if you want to create proper
>> packages with it you have to call out to java from other languages
>
> Packages are zip files with a defined structure and some required files.
> If you have a template, a few lines of bash (cp -r, sed, zip) will create
> a package containing OSGi configs. This works well in Kubernetes within
> Docker images. (btw, without a package and its version number, the
> OSGIPackageInstaller doesnt install replacement config files)

Simple property filtering works fine yes, but to implement a
replacement for server side config merging you quickly come to a
situation where you  would have to read the structure of xml files and
add config xml files and filter rules for it dynamically (think of
creating a config /conf/tenant/myprof/path/to/my/page/myconfig.xml iff
the prop 
puppetproproot.myprof.path.to.my.page.myconfig.theOneConfigPropToBeOverWrittenHere
exists), doing so using FileVault/XmlApis is more robust/easier than
using manual, text-based assembly.

-Georg

Re: [Context Aware Configs] Merging?

[Georg Henzler]

On 2016-08-01 13:29, Konrad Windszus wrote:

Can't we just use the resource merger approach for merging configs
(http://sling.staging.apache.org/documentation/bundles/resource-merger.html
)?
There probably needs to be a dedicated resource picker for
configurations, because neither the search path approach nor the
resource super type approach is applicable for configurations.


Sounds like a good match, I could imagine that way we could implement 
merged configs fairly easily!



Clearly with devops automation you have some tooling already in place
which is using text files and does something to start AEM, so you can
add the stuff there - or - the configuration are content packages 
after
all, so if the automation supports content packages in some form, 
you're

done.



Agreed.


DevOps automation is nice, but for generating CRX packages with xml 
config files it's not a great match:
* Puppet (not too sure about the others) is not exactly great at dealing 
with xml files
* FileVault [1] is only available in Java, if you want to create proper 
packages with it you have to call out to java from other languages
* Not having a standard approach makes every project implement their 
homegrown solution (and waste budget where it could really be standard). 
I've have seen a few awkward solutions for generating OSGi configs
* Alternatively  (and this is what I've seen happening the most for OSGi 
configs), people just accept the fact that they have to duplicate 
configuration sets and then run into all the frustration Justin 
described earlier


So I'm still in big favour of having a runtime solution.

Best Regards
Georg

[1]
http://jackrabbit.apache.org/filevault/

Re: Sling Oak Restrictions - Release 1.0.0 now?

[Georg Henzler]

On 2016-08-02 09:41, Konrad Windszus wrote:

I think sling:resourceTypesWithChildren is the clearest suggestion up 
to now ([1] gives an example). From a pure user point of view, the 
terms "parent" or "ancestry" would be rather misleading, because what 
is matched by the restriction in the end are nodes below (and not 
above) the matched node with the given resource type, e.g. the 
restriction matches a node with resource type "myproj/news" with (or 
including) all children.



For me the matched node is the one I want to modify/insert, not the
one carrying the ACE with the restriction.


correct - the node carrying the ACE is the upper boundary of possible 
matches (this is oak standard for all restrictions and does not really 
have to be repeated)



Maybe we should clarify
that even more in the documentation, because when it comes to applying
ACEs you are dealing with two different nodes: the one you try to
modify and the one where the ACE is set (this is not necessarily the
same node).


We have "Naturally (as with any oak restrictions), the rule is limited 
to its base path. In case the node /content/myprj/othernode is of 
resource type myproj/comp1, it will still not match." in the 
documenation, but I'm sure it can be improved...



For me the documentation at [1] is not clear enough in
that regard, especially how inheritance is being treated. On which
level is the resourceType being compared? On the level where the ACE
is set or on the matched node level?


Like for all oak restrictions, any ACE is only applied if all given 
restrictions apply. sling:resourceTypesWithChildren (or probably better 
sling:resourceTypesWithDescendants) will be clever and also match 
descendants, even if it is not a direct match of a particular node.


@Konrad regarding the naming, which one of the following would you 
prefer?


- sling:resourceTypesDeep <-- less descriptive but also shorter
- sling:resourceTypesWithDescendants <-- I think clearer, but longer

Regards
Georg

Re: Sling Oak Restrictions - Release 1.0.0 now?

[Georg Henzler]

Hi Julian,

good point that "descendants" is actually clearer than "children"... 
that gives two options IMHO:


- sling:resourceTypesDeep <-- less descriptive but also shorter
- sling:resourceTypesWithDescendants <-- I think clearer, but longer

For the simple match, I would stick with the short name 
sling:resourceTypes

as it is more in line with the standard oak restrictions.

Regards
Georg

On 2016-08-01 13:48, Julian Sedding wrote:

Hi Georg

I think "...WithChildren" is misleading, because, per my understanding
of the documentation, it means "with descendants".

Maybe restriction names with "shallow" and/or "deep" would be more
self-documenting?

E.g. "sling:resourceTypesShallow" and "sling:resourceTypesDeep".

WDYT?

Regards
Julian


On Mon, Aug 1, 2016 at 1:32 PM, Georg Henzler <slin...@ghenzler.de> 
wrote:

Hi Robert,


... I would rather see it named org.apache.sling.jcr.oak-restrictions
and placed under contrib/jcr .



That sounds like a better location, +1 to move


There was some discussion related to the name of the
'sling:resourceTypesWithChildren' restriction [1]. I want to make 
sure

that we have agreement that this is the best name



I think sling:resourceTypesWithChildren is the clearest suggestion up 
to now
([1] gives an example). From a pure user point of view, the terms 
"parent"
or "ancestry" would be rather misleading, because what is matched by 
the
restriction in the end are nodes below (and not above) the matched 
node with
the given resource type, e.g. the restriction matches a node with 
resource

type "myproj/news" with (or including) all children.

Regards
Georg


[1]
https://sling.apache.org/documentation/bundles/sling-oak-restrictions.html#restriction-slingresourcetypeswithchildren

Re: Sling Oak Restrictions - Release 1.0.0 now?

[Georg Henzler]

Hi Robert,


... I would rather see it named org.apache.sling.jcr.oak-restrictions
and placed under contrib/jcr .


That sounds like a better location, +1 to move


There was some discussion related to the name of the
'sling:resourceTypesWithChildren' restriction [1]. I want to make sure
that we have agreement that this is the best name


I think sling:resourceTypesWithChildren is the clearest suggestion up to 
now ([1] gives an example). From a pure user point of view, the terms 
"parent" or "ancestry" would be rather misleading, because what is 
matched by the restriction in the end are nodes below (and not above) 
the matched node with the given resource type, e.g. the restriction 
matches a node with resource type "myproj/news" with (or including) all 
children.


Regards
Georg


[1]
https://sling.apache.org/documentation/bundles/sling-oak-restrictions.html#restriction-slingresourcetypeswithchildren

[jira] [Updated] (SLING-5874) Health Check Executor unnecessarily wastes 50ms

[Georg Henzler (JIRA)]

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

Georg Henzler updated SLING-5874:
-
Assignee: Bertrand Delacretaz  (was: Georg Henzler)

> Health Check Executor unnecessarily wastes 50ms 
> 
>
> Key: SLING-5874
> URL: https://issues.apache.org/jira/browse/SLING-5874
> Project: Sling
>  Issue Type: Improvement
>  Components: Health Check
>    Reporter: Georg Henzler
>Assignee: Bertrand Delacretaz
>
> Currently the HC executor boldly waits for 50ms util it checks again if all 
> relevant futures have finished within the given timeout:
> https://github.com/apache/sling/blob/eecc7e401a0894984a5eaa8992dedfcb5a18e0e5/bundles/extensions/healthcheck/core/src/main/java/org/apache/sling/hc/core/impl/executor/HealthCheckExecutorImpl.java#L365
> This has the following disadvantages:
> * The HC executor never returns a request under 50ms (even if the actual 
> check only takes 1ms like a "all OSGi bundle started" check does)
> * Setting timeout values (e.g. via the HC servlet) lower than 50ms does not 
> work (effectively the timeout is increased to 50ms then)
> For most cases the current behaviour is not really a problem, but for using 
> the HC for a load balancer when response time should be optimised as much as 
> possible, the HC servlet should be able to return in only slightly more time 
> than the longest check requires (so if a request checks for started bundles 
> only it should return in ~3ms instead of the current ~53ms).
> To fix this the sleep shall be replaced with a 
> Object.wait()/Object.notifyAll() setup.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [Context Aware Configs] Merging?

[Georg Henzler]

... if you have merging (or inheritance) then you change the
attribute of a parent and this influences all childs and you
have no idea what happens there...


We can create a felix console plugin that shows for a given
context path and config name the value of the property and the
path from where it was taken - that way both developers and ops
can quickly check what's going wrong if results are unexpected.


I personally think this comes all down to tooling ...


So this could mean e.g. an additional maven plugin, which handles
merging of configurations and then the runtime can work without
merging. The problem I see with that is that
* you end up having two similar configuration model types (one in
  the source code that supports merging and one effective one for
  the runtime) - this makes the mechanism harder to understand
  for everyone
* the tooling has to be created and IMHO it'll not be easier/less
  code than creating a smarter runtime (even if we take into
  account that we have to create the felix console plugin to make
  it traceable)

Regards
Georg

Sling Health Check Executor Optimisation

[Georg Henzler]

As it turned out the HC executor wastes 50ms by using a hardcoded 
Thread.sleep() which does not sound like a lot (and often it's not a 
problem), but some use cases it's not ideal (e.g. when calling it from a 
load balancer). The pull request in SLING-5874 fixes it... Carsten or 
Betrand, the two of you were involved in this particular piece of code 
(the very line with the sleep came from myself, blaming myself ;-)), 
maybe you could have a look and commit it? I tested it with JMeter, 
there should not be any problems with it.


Regards
Georg

Sling Oak Restrictions - Release 1.0.0 now?

[Georg Henzler]

Hi all,

with SLING-5768/SLING-5891 fixed and the documentation in 
https://sling.apache.org/documentation/bundles/sling-oak-restrictions.html 
we have everything needed to cut a first release IMHO - could someone 
take care of it?


Thanks & Regards
Georg

Re: [Context Aware Configs] Merging?

[Georg Henzler]

A big +1 from my side to support merging (all the way down to property 
level) from the very first release. IMHO it's not that hard to implement 
and it saves a lot of frustration downstream.


On 2016-07-29 17:10, Justin Edelson wrote:
Allow me to disagree. This lack of merging is actually one of the key 
pain

points I have with OSGi ConfigAdmin and I would really love to see it
accommodated here. The problem with not merging is that it results in a 
lot
of error-prone duplication and you can easily get into a state where 
new
default values (in the global configuration) are not propagated as 
expected

because once override any configuration property you are effectively
hard-coding the *current* global configuration in your override. Future
changes (or even additions) to that global configuration does not have 
the

expected result.

Consider this case:

Global: {
'services' : {
'serviceA' {
'endpoint' : 'https://api.com/foo'
}
}
}


Site: {
'services' : {
'serviceA' {
'endpoint' : 'https://stage.api.com/foo'
}
}
}

Works OK. But at some point down the line, the developer of the 
component

consuming this configuration finds that a timeout value needs to be
specified. They do the needful and modify the global configuration to 
be:


{
'services' : {
'serviceA' {
'endpoint' : 'https://api.com/foo',
'timeout' : 500
}
}
}

I'd suggest that the reasonable expectation is that the timeout would 
apply

to all contexts. But without merging, this won't happen.

Merging is hard to add after-the-fact because it is almost impossible 
to
make backwards-compatible. Since we are starting with a blank slate 
here,

I'd strongly suggest that this new capability support merging from the
start.

I would also disagree that this isn't a problem already. The adoption 
of
service users is a recent specific case where the failure of 
JcrInstaller

to support merging was an impediment. We had to add the "amended"
configuration PID specifically to work around that problem because it 
was

pretty clearly nonscalable to have a centralized list of service user
configurations. I could go through my archives of 6 years of AEM 
projects

and easily find hundreds of overridden sling:OsgiConfig nodes which had
properties totally unrelated to the desired configuration change. But 
since

the configuration is all there, there's no real way to know (save for
documentation) what *specific* configuration change was desired vs. 
what
properties had to be copied just to get a component to retain its 
original

behavior.

Caveat - In a former life, I worked extensively with the dependency
injection framework ATG Nucleus for a large, multi-property, multi-site
deployment which supported configuration merging and I've spent the 
last

many years pining away over this one aspect of Nucleus.

Justin

On Fri, Jul 29, 2016 at 10:39 AM Carsten Ziegeler 


wrote:


> Hi,
> Properties should not be merged, as that will produce undesirable side
> effects, however some things need to be merged.
>
> Having attempted to write documentation I found it easiest to describe in
> terms of json documents.
> Using the examples in
> https://gist.github.com/ieb/460504e79c861cb980f4f0154210a869
>
> given 2 configs from different locations
>
> Location A
>
> {
> "socialmedia" : {
> "youtube" : {
> "enabled" : false,
> "url" : "https://youtube.com;
> },
> "facebook" : {
> "enabled" : false,
> "apiusage" : false,
> "url" : "https://youtube.com;
> },
>
> Location B
>
>  {
> "socialmedia" : {
> "facebook" : {
> "enabled" : true,
> "url" : "https://facebook.com;
> }
> }
> }
>
>
> The result of A then B should be
>
> {
> "socialmedia" : {
> "youtube" : {
> "enabled" : false,
> "url" : "https://youtube.com;
> },
> "facebook" : {
> "enabled" : true,
> "url" : "https://facebook.com;
> }
> }
> }
>
>
> ie Objects are merged but properties are not. socialmedia.facebook from A
> does not add @apiusage to the result, as socialmedia.facebook form B
> overwrites socialmedia.facebook from A.
>
> That will allow a deployer to completely replace a configuration "object"
> without having to get their head around more complex inheritance rules.
> This does assume that configurations are collected together into
"objects".
> I think its is important to keep it simple.
> If this isnt simple enough then it needs some more thought.
>

Yes, I think we agree on this, and that's how my implementation
currently works). So for your above example if we have "A then B" and
you get the collection for "socialmedia" you 

[jira] [Commented] (SLING-5768) Introduce sling:resourceTypes as extension to Oak permission system

[Georg Henzler (JIRA)]

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

Georg Henzler commented on SLING-5768:
--

Created SLING-5891 to make it compatible to a broader range of oak versions.

> Introduce sling:resourceTypes as extension to Oak permission system
> ---
>
> Key: SLING-5768
> URL: https://issues.apache.org/jira/browse/SLING-5768
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>    Reporter: Georg Henzler
>Assignee: Robert Munteanu
> Fix For: Oak Restrictions 1.0.0
>
>
> Oak allows to extend its permissions management by using custom restrictions 
> \[1], also the standard oak restrictions are based on this and are 
> implemented in a fairly straight-forward way \[2] (example is for 
> rep:ntNames). 
> It would be nice to have sling level restrictions using sling properties in 
> general. This issue is about introducing a restriction on resource types - 
> the following should be possible:
> {code}
> - /content/mynode 
>- rep:policy (rep:ACL)
>  - allow (rep:GrantACE)
>+ principalName (String) = "myAuthorizable"
>+ rep:privileges (Name[]) = "rep:write"
>- rep:restrictions (rep:Restrictions)
>   +   sling:resourceTypes (String[]) = 
> [myproj/resourcetype1,myproj/resourcetype2]
> {code}
> The example would only grant "rep:write" for the resource types 
> myproj/resourcetype1 and myproj/resourcetype2 in path /content/mynode, other 
> resources under path /content/mynode would not have "rep:write" permissions. 
> Additionally to strict resource type matching it shall be possible to 
> automatically match a resource with a given resource type including all 
> children. Also, not all content nodes have a resource type, therefore it 
> should be possible to match against a child node by appending \@path to the 
> resource type: 
> {code}
> - /content/myprj 
>- rep:policy (rep:ACL)
>  - allow (rep:GrantACE)
>+ principalName (String) = "myAuthorizable"
>+ rep:privileges (Name[]) = "rep:write"
>- rep:restrictions (rep:Restrictions)
>   +   sling:resourceTypesWithChildren (String[]) = 
> [myproj/resourcetype1@jcr:content]
> {code}
> To achieve this any path match attempt traverses the parents and checks for a 
> match (but only up to the base path, /content/myprj in this example). For AEM 
> use cases, this can match a whole page structure (e.g. something like 
> /content/myprj/path/to/newsoverview, the whole news section can be easily 
> matched by having a distinct news overview template). 
> \[1]
> https://jackrabbit.apache.org/oak/docs/security/authorization/restriction.html#Pluggability
> \[2]
> https://github.com/apache/jackrabbit-oak/blob/cea167f5bf70d818d58b1ffcc6bc65b3c0f9a5a4/oak-core/src/main/java/org/apache/jackrabbit/oak/security/authorization/restriction/NodeTypePattern.java#L50)
> https://github.com/apache/jackrabbit-oak/blob/cea167f5bf70d818d58b1ffcc6bc65b3c0f9a5a4/oak-core/src/main/java/org/apache/jackrabbit/oak/security/authorization/restriction/RestrictionProviderImpl.java



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (SLING-5891) Make oak restrictions compatible to oak > 1.2

[Georg Henzler (JIRA)]

Georg Henzler created SLING-5891:


 Summary: Make oak restrictions compatible to oak > 1.2
 Key: SLING-5891
 URL: https://issues.apache.org/jira/browse/SLING-5891
 Project: Sling
  Issue Type: Improvement
  Components: Extensions
Reporter: Georg Henzler
Assignee: Robert Munteanu


The initial version was tested with oak-core v1.2.7, however some users might 
want to use it with more recent versions (especially 1.4.x). 

The problematic packages are {{org.apache.jackrabbit.oak.api}} and 
{{org.apache.jackrabbit.oak.util}}. Usually it is not a good idea to tweak 
package imports manually, but I think for this particular case there is no 
other solution to provide compatibility across oak versions. The functionality 
that is actually used from those two packages is also very basic (Tree, Type, 
PropertyState and TreeUtil), therefore providing a version range for them is 
not problematic IMHO.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-5768) Introduce sling:resourceTypes as extension to Oak permission system

[Georg Henzler (JIRA)]

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

Georg Henzler commented on SLING-5768:
--

Created SLING-5890 for the documentation (and while writing it up, I came to 
the conclusion that {{sling:resourceTypesWithChildren}} is still the best name 
for it, so let's just leave it as is). 

> Introduce sling:resourceTypes as extension to Oak permission system
> ---
>
> Key: SLING-5768
> URL: https://issues.apache.org/jira/browse/SLING-5768
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>    Reporter: Georg Henzler
>Assignee: Robert Munteanu
> Fix For: Oak Restrictions 1.0.0
>
>
> Oak allows to extend its permissions management by using custom restrictions 
> \[1], also the standard oak restrictions are based on this and are 
> implemented in a fairly straight-forward way \[2] (example is for 
> rep:ntNames). 
> It would be nice to have sling level restrictions using sling properties in 
> general. This issue is about introducing a restriction on resource types - 
> the following should be possible:
> {code}
> - /content/mynode 
>- rep:policy (rep:ACL)
>  - allow (rep:GrantACE)
>+ principalName (String) = "myAuthorizable"
>+ rep:privileges (Name[]) = "rep:write"
>- rep:restrictions (rep:Restrictions)
>   +   sling:resourceTypes (String[]) = 
> [myproj/resourcetype1,myproj/resourcetype2]
> {code}
> The example would only grant "rep:write" for the resource types 
> myproj/resourcetype1 and myproj/resourcetype2 in path /content/mynode, other 
> resources under path /content/mynode would not have "rep:write" permissions. 
> Additionally to strict resource type matching it shall be possible to 
> automatically match a resource with a given resource type including all 
> children. Also, not all content nodes have a resource type, therefore it 
> should be possible to match against a child node by appending \@path to the 
> resource type: 
> {code}
> - /content/myprj 
>- rep:policy (rep:ACL)
>  - allow (rep:GrantACE)
>+ principalName (String) = "myAuthorizable"
>+ rep:privileges (Name[]) = "rep:write"
>- rep:restrictions (rep:Restrictions)
>   +   sling:resourceTypesWithChildren (String[]) = 
> [myproj/resourcetype1@jcr:content]
> {code}
> To achieve this any path match attempt traverses the parents and checks for a 
> match (but only up to the base path, /content/myprj in this example). For AEM 
> use cases, this can match a whole page structure (e.g. something like 
> /content/myprj/path/to/newsoverview, the whole news section can be easily 
> matched by having a distinct news overview template). 
> \[1]
> https://jackrabbit.apache.org/oak/docs/security/authorization/restriction.html#Pluggability
> \[2]
> https://github.com/apache/jackrabbit-oak/blob/cea167f5bf70d818d58b1ffcc6bc65b3c0f9a5a4/oak-core/src/main/java/org/apache/jackrabbit/oak/security/authorization/restriction/NodeTypePattern.java#L50)
> https://github.com/apache/jackrabbit-oak/blob/cea167f5bf70d818d58b1ffcc6bc65b3c0f9a5a4/oak-core/src/main/java/org/apache/jackrabbit/oak/security/authorization/restriction/RestrictionProviderImpl.java



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLING-5890) Documentation for the new sling oak restrictions from SLING-5768

[Georg Henzler (JIRA)]

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

Georg Henzler updated SLING-5890:
-
Attachment: sling-oak-restrictions.mdtext

> Documentation for the new sling oak restrictions from SLING-5768
> 
>
> Key: SLING-5890
> URL: https://issues.apache.org/jira/browse/SLING-5890
> Project: Sling
>  Issue Type: Task
>  Components: Extensions
>    Reporter: Georg Henzler
>Assignee: Robert Munteanu
> Attachments: sling-oak-restrictions.mdtext
>
>
> Attached the markdown file for the documentation of SLING-5768, I suppose the 
> best location for it is 
> sling/site/trunk/content/documentation/bundles/sling-oak-restrictions.mdtext 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (SLING-5890) Documentation for the new sling oak restrictions from SLING-5768

[Georg Henzler (JIRA)]

Georg Henzler created SLING-5890:


 Summary: Documentation for the new sling oak restrictions from 
SLING-5768
 Key: SLING-5890
 URL: https://issues.apache.org/jira/browse/SLING-5890
 Project: Sling
  Issue Type: Task
  Components: Extensions
Reporter: Georg Henzler
Assignee: Robert Munteanu


Attached the markdown file for the documentation of SLING-5768, I suppose the 
best location for it is 
sling/site/trunk/content/documentation/bundles/sling-oak-restrictions.mdtext 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-5874) Health Check Executor unnecessarily wastes 50ms

[Georg Henzler (JIRA)]

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

Georg Henzler commented on SLING-5874:
--

With the PR the HC executor reliably returns after the time the longest HC 
needs (without adding 50ms). Tested it also with JMeter to ensure it behaves 
well under load.

> Health Check Executor unnecessarily wastes 50ms 
> 
>
> Key: SLING-5874
> URL: https://issues.apache.org/jira/browse/SLING-5874
> Project: Sling
>  Issue Type: Improvement
>  Components: Health Check
>    Reporter: Georg Henzler
>    Assignee: Georg Henzler
>
> Currently the HC executor boldly waits for 50ms util it checks again if all 
> relevant futures have finished within the given timeout:
> https://github.com/apache/sling/blob/eecc7e401a0894984a5eaa8992dedfcb5a18e0e5/bundles/extensions/healthcheck/core/src/main/java/org/apache/sling/hc/core/impl/executor/HealthCheckExecutorImpl.java#L365
> This has the following disadvantages:
> * The HC executor never returns a request under 50ms (even if the actual 
> check only takes 1ms like a "all OSGi bundle started" check does)
> * Setting timeout values (e.g. via the HC servlet) lower than 50ms does not 
> work (effectively the timeout is increased to 50ms then)
> For most cases the current behaviour is not really a problem, but for using 
> the HC for a load balancer when response time should be optimised as much as 
> possible, the HC servlet should be able to return in only slightly more time 
> than the longest check requires (so if a request checks for started bundles 
> only it should return in ~3ms instead of the current ~53ms).
> To fix this the sleep shall be replaced with a 
> Object.wait()/Object.notifyAll() setup.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLING-5874) Health Check Executor unnecessarily wastes 50ms

[Georg Henzler (JIRA)]

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

Georg Henzler updated SLING-5874:
-
Flags: Patch

> Health Check Executor unnecessarily wastes 50ms 
> 
>
> Key: SLING-5874
> URL: https://issues.apache.org/jira/browse/SLING-5874
> Project: Sling
>  Issue Type: Improvement
>  Components: Health Check
>    Reporter: Georg Henzler
>    Assignee: Georg Henzler
>
> Currently the HC executor boldly waits for 50ms util it checks again if all 
> relevant futures have finished within the given timeout:
> https://github.com/apache/sling/blob/eecc7e401a0894984a5eaa8992dedfcb5a18e0e5/bundles/extensions/healthcheck/core/src/main/java/org/apache/sling/hc/core/impl/executor/HealthCheckExecutorImpl.java#L365
> This has the following disadvantages:
> * The HC executor never returns a request under 50ms (even if the actual 
> check only takes 1ms like a "all OSGi bundle started" check does)
> * Setting timeout values (e.g. via the HC servlet) lower than 50ms does not 
> work (effectively the timeout is increased to 50ms then)
> For most cases the current behaviour is not really a problem, but for using 
> the HC for a load balancer when response time should be optimised as much as 
> possible, the HC servlet should be able to return in only slightly more time 
> than the longest check requires (so if a request checks for started bundles 
> only it should return in ~3ms instead of the current ~53ms).
> To fix this the sleep shall be replaced with a 
> Object.wait()/Object.notifyAll() setup.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (SLING-5874) Health Check Executor unnecessarily wastes 50ms

[Georg Henzler (JIRA)]

Georg Henzler created SLING-5874:


 Summary: Health Check Executor unnecessarily wastes 50ms 
 Key: SLING-5874
 URL: https://issues.apache.org/jira/browse/SLING-5874
 Project: Sling
  Issue Type: Improvement
  Components: Health Check
Reporter: Georg Henzler
Assignee: Georg Henzler


Currently the HC executor boldly waits for 50ms util it checks again if all 
relevant futures have finished within the given timeout:
https://github.com/apache/sling/blob/eecc7e401a0894984a5eaa8992dedfcb5a18e0e5/bundles/extensions/healthcheck/core/src/main/java/org/apache/sling/hc/core/impl/executor/HealthCheckExecutorImpl.java#L365

This has the following disadvantages:
* The HC executor never returns a request under 50ms (even if the actual check 
only takes 1ms like a "all OSGi bundle started" check does)
* Setting timeout values (e.g. via the HC servlet) lower than 50ms does not 
work (effectively the timeout is increased to 50ms then)

For most cases the current behaviour is not really a problem, but for using the 
HC for a load balancer when response time should be optimised as much as 
possible, the HC servlet should be able to return in only slightly more time 
than the longest check requires (so if a request checks for started bundles 
only it should return in ~3ms instead of the current ~53ms).

To fix this the sleep shall be replaced with a Object.wait()/Object.notifyAll() 
setup.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-5867) SlingRequestStatusHealthCheck should add timeout support

[Georg Henzler (JIRA)]

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

Georg Henzler commented on SLING-5867:
--

Correct, stopping/interrupting a HC thread can potentially be dangerous (e.g. 
corrupting the repository), that's why this is never done. But the HC executor 
ensures that per HC there is at most one thread running even if that one threat 
hangs indefinitely (if for one particular thread there is already an existing 
future, this is always reused). 

But to come back to the initial issue: It could be useful to make maximum 
execution time thresholds configurable for the request status health check 
(e.g. {{maxExecutionTimeThresholdWarnInMs}} and 
{{maxExecutionTimeThresholdCriticalInMs}}). The setting in theory could be per 
line of config {{paths}}, but to benefit from parallel execution and since 
SlingRequestStatusHealthCheck has {{configurationFactory=true}} it would be 
more useful to have this as root level configuration values of 
SlingRequestStatusHealthCheck. If   {{maxExecutionTimeThresholdCriticalInMs}} 
is longer than the timeout as set in the executor for a particular request 
status config, it can always be set to async to avoid timeouts. 

[~kwin] What about renaming this issue to "SlingRequestStatusHealthCheck should 
support WARN/CRITICAL thresholds for maximum execution time"

> SlingRequestStatusHealthCheck should add timeout support
> 
>
> Key: SLING-5867
> URL: https://issues.apache.org/jira/browse/SLING-5867
> Project: Sling
>  Issue Type: Bug
>  Components: Health Check
>Affects Versions: Health Check Support 1.0.4
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>
> Currently {{o.a.s.hc.support.impl.SlingRequestStatusHealthCheck}} just 
> synchronously calls {{SlingRequestProcessor.processResponse}}.
> That means in case of a non-returning response (e.g. caused by a deadlock 
> like SLING-5847) the health check will just timeout but never actually really 
> fail (even after a very long time).
> In this case it is good to create a dedicated timeout handling within the 
> {{SlingRequestStatusHealthCheck}} (separate from the timeout in 
> {{HealthCheckExecutorImpl}}) because for each individual request health check 
> configuration you might want to set different timeouts.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-5867) SlingRequestStatusHealthCheck should add timeout support

[Georg Henzler (JIRA)]

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

Georg Henzler commented on SLING-5867:
--

bq. ... in case of a non-returning response ... the health check will just 
timeout but never actually really fail (even after a very long time).

This should not be true: 
https://github.com/apache/sling/blob/eecc7e401a0894984a5eaa8992dedfcb5a18e0e5/bundles/extensions/healthcheck/core/src/main/java/org/apache/sling/hc/core/impl/executor/HealthCheckExecutorImpl.java#L432
 should make it fail eventually after 5 minutes (configurable via 
https://github.com/apache/sling/blob/eecc7e401a0894984a5eaa8992dedfcb5a18e0e5/bundles/extensions/healthcheck/core/src/main/java/org/apache/sling/hc/core/impl/executor/HealthCheckExecutorImpl.java#L88)

bq. ... create a dedicated timeout handling within the 
SlingRequestStatusHealthCheck (separate from the timeout in 
HealthCheckExecutorImpl) because for each individual request health check 
configuration you might want to set different timeouts.

I think the maximum time you can wait for a response depends a lot more on from 
where you are calling (e.g. load balancer or human for a dashboard) than to a 
fixed set of tags or a particular check (hence configuring this per check or 
tag does not make much sense IMHO). So at the moment, timeout handling is done 
by using
* a global default
* a per call setting when using the HC Executor (e.g. the request param 
"timeout" of the HC servlet that set the HC executor option at 
https://github.com/apache/sling/blob/eecc7e401a0894984a5eaa8992dedfcb5a18e0e5/bundles/extensions/healthcheck/core/src/main/java/org/apache/sling/hc/api/execution/HealthCheckExecutionOptions.java#L26)



> SlingRequestStatusHealthCheck should add timeout support
> 
>
> Key: SLING-5867
> URL: https://issues.apache.org/jira/browse/SLING-5867
> Project: Sling
>  Issue Type: Bug
>  Components: Health Check
>Affects Versions: Health Check Support 1.0.4
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>
> Currently {{o.a.s.hc.support.impl.SlingRequestStatusHealthCheck}} just 
> synchronously calls {{SlingRequestProcessor.processResponse}}.
> That means in case of a non-returning response (e.g. caused by a deadlock 
> like SLING-5847) the health check will just timeout but never actually really 
> fail (even after a very long time).
> In this case it is good to create a dedicated timeout handling within the 
> {{SlingRequestStatusHealthCheck}} (separate from the timeout in 
> {{HealthCheckExecutorImpl}}) because for each individual request health check 
> configuration you might want to set different timeouts.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (SLING-5768) Introduce sling:resourceTypes as extension to Oak permission system

[Georg Henzler (JIRA)]

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

Georg Henzler edited comment on SLING-5768 at 7/8/16 4:15 PM:
--

bq. I am not so fond of the naming sling:resourceTypesWithChildren

I don't think the name is perfect either, I could just not think of a better 
name. You suggested {{sling:resourceTypesInAncestry}} at some point (this would 
actually be more in line with the algorithm that traverses the parents), but 
when writing the rule, I think it feels more natural to think about a node with 
a resource type and match all the children along with it. [~rombert], as a 
third opinion, what do you think?

bq. I am not sure whether this would rather be a good proposal for Oak as a 
general property matcher restriction. 

I think at some point oak should also introduce a more flexible "property 
matcher restriction", but the sling one will always make sense as it is more 
concise and easier to write (in the domain of sling it's nicer to write 
directly {{sling:resourceTypes=myproject/type1,myproject/type2}} instead of 
{{rep:propertyMatch=sling:resourceType=myproject/type1,sling:resourceType=myproject/type2}})

bq. Also when we talk about resourceTypes in Sling ... or from the *node type*

This is a bit of an academic discussion - the restriction could be extended to 
support the node type fallback, but on the other hand it's not that useful 
(because most sling applications don't work with a wide range of node types) 
and also, standard oak rep:ntNames does exactly this. 

Regarding the documentation: Where exactly is the source of pages like 
https://sling.apache.org/documentation/bundles/sling-health-check-tool.html? I 
suggest adding a new page for the sling restrictions (as it is its own module). 
  


was (Author: henzlerg):
bq. I am not so fond of the naming sling:resourceTypesWithChildren

I don't think the name is perfect either, I could just not think of a better 
name. You suggested {{sling:resourceTypesInAncestry}} as some point (this would 
actually be more in line with the algorithm that traverses the parents), but 
when writing the rule, I think it feels more natural to think about a node with 
a resource type and match all the children along with it. [~rombert] as a third 
opinion, what do you think?

bq. I am not sure whether this would rather be a good proposal for Oak as a 
general property matcher restriction. 

I think at some point oak should also introduce more flexible "matcher 
restrictions", but the sling one will always make sense as it is more concise 
and easier to write. 

bq. Also when we talk about resourceTypes in Sling ... or from the *node type*

This is a bit of an academic discussion - the restriction could be extended to 
support the node type fallback, but on the other hand it's not that useful 
(because most sling applications don't work with a wide range of node types) 
and also, standard oak rep:ntNames does exactly this. 

Regarding the documentation: Where exactly is the source of pages like 
https://sling.apache.org/documentation/bundles/sling-health-check-tool.html? I 
suggest adding a new page for the sling restrictions (as it is its own module). 
  

> Introduce sling:resourceTypes as extension to Oak permission system
> ---
>
> Key: SLING-5768
> URL: https://issues.apache.org/jira/browse/SLING-5768
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>Reporter: Georg Henzler
>Assignee: Robert Munteanu
> Fix For: Oak Restrictions 1.0.0
>
>
> Oak allows to extend its permissions management by using custom restrictions 
> \[1], also the standard oak restrictions are based on this and are 
> implemented in a fairly straight-forward way \[2] (example is for 
> rep:ntNames). 
> It would be nice to have sling level restrictions using sling properties in 
> general. This issue is about introducing a restriction on resource types - 
> the following should be possible:
> {code}
> - /content/mynode 
>- rep:policy (rep:ACL)
>  - allow (rep:GrantACE)
>+ principalName (String) = "myAuthorizable"
>+ rep:privileges (Name[]) = "rep:write"
>- rep:restrictions (rep:Restrictions)
>   +   sling:resourceTypes (String[]) = 
> [myproj/resourcetype1,myproj/resourcetype2]
> {code}
> The example would only grant "rep:write" for the resource types 
> myproj/resourcetype1 and myproj/resourcetype2 in path /content/mynode, other 
> resources under path /content/mynode would not have "rep:write" permissions. 
> Additionally to strict resource type ma

[jira] [Commented] (SLING-5768) Introduce sling:resourceTypes as extension to Oak permission system

[Georg Henzler (JIRA)]

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

Georg Henzler commented on SLING-5768:
--

bq. I am not so fond of the naming sling:resourceTypesWithChildren

I don't think the name is perfect either, I could just not think of a better 
name. You suggested {{sling:resourceTypesInAncestry}} as some point (this would 
actually be more in line with the algorithm that traverses the parents), but 
when writing the rule, I think it feels more natural to think about a node with 
a resource type and match all the children along with it. [~rombert] as a third 
opinion, what do you think?

bq. I am not sure whether this would rather be a good proposal for Oak as a 
general property matcher restriction. 

I think at some point oak should also introduce more flexible "matcher 
restrictions", but the sling one will always make sense as it is more concise 
and easier to write. 

bq. Also when we talk about resourceTypes in Sling ... or from the *node type*

This is a bit of an academic discussion - the restriction could be extended to 
support the node type fallback, but on the other hand it's not that useful 
(because most sling applications don't work with a wide range of node types) 
and also, standard oak rep:ntNames does exactly this. 

Regarding the documentation: Where exactly is the source of pages like 
https://sling.apache.org/documentation/bundles/sling-health-check-tool.html? I 
suggest adding a new page for the sling restrictions (as it is its own module). 
  

> Introduce sling:resourceTypes as extension to Oak permission system
> ---
>
> Key: SLING-5768
> URL: https://issues.apache.org/jira/browse/SLING-5768
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>Reporter: Georg Henzler
>Assignee: Robert Munteanu
> Fix For: Oak Restrictions 1.0.0
>
>
> Oak allows to extend its permissions management by using custom restrictions 
> \[1], also the standard oak restrictions are based on this and are 
> implemented in a fairly straight-forward way \[2] (example is for 
> rep:ntNames). 
> It would be nice to have sling level restrictions using sling properties in 
> general. This issue is about introducing a restriction on resource types - 
> the following should be possible:
> {code}
> - /content/mynode 
>- rep:policy (rep:ACL)
>  - allow (rep:GrantACE)
>+ principalName (String) = "myAuthorizable"
>+ rep:privileges (Name[]) = "rep:write"
>- rep:restrictions (rep:Restrictions)
>   +   sling:resourceTypes (String[]) = 
> [myproj/resourcetype1,myproj/resourcetype2]
> {code}
> The example would only grant "rep:write" for the resource types 
> myproj/resourcetype1 and myproj/resourcetype2 in path /content/mynode, other 
> resources under path /content/mynode would not have "rep:write" permissions. 
> Additionally to strict resource type matching it shall be possible to 
> automatically match a resource with a given resource type including all 
> children. Also, not all content nodes have a resource type, therefore it 
> should be possible to match against a child node by appending \@path to the 
> resource type: 
> {code}
> - /content/myprj 
>- rep:policy (rep:ACL)
>  - allow (rep:GrantACE)
>+ principalName (String) = "myAuthorizable"
>+ rep:privileges (Name[]) = "rep:write"
>- rep:restrictions (rep:Restrictions)
>   +   sling:resourceTypesWithChildren (String[]) = 
> [myproj/resourcetype1@jcr:content]
> {code}
> To achieve this any path match attempt traverses the parents and checks for a 
> match (but only up to the base path, /content/myprj in this example). For AEM 
> use cases, this can match a whole page structure (e.g. something like 
> /content/myprj/path/to/newsoverview, the whole news section can be easily 
> matched by having a distinct news overview template). 
> \[1]
> https://jackrabbit.apache.org/oak/docs/security/authorization/restriction.html#Pluggability
> \[2]
> https://github.com/apache/jackrabbit-oak/blob/cea167f5bf70d818d58b1ffcc6bc65b3c0f9a5a4/oak-core/src/main/java/org/apache/jackrabbit/oak/security/authorization/restriction/NodeTypePattern.java#L50)
> https://github.com/apache/jackrabbit-oak/blob/cea167f5bf70d818d58b1ffcc6bc65b3c0f9a5a4/oak-core/src/main/java/org/apache/jackrabbit/oak/security/authorization/restriction/RestrictionProviderImpl.java



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-5799) Request Status HC does not log any INFO logs

[Georg Henzler (JIRA)]

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

Georg Henzler commented on SLING-5799:
--

The requested paths are already logged when activating debug (hcDebug=true when 
using the health check servlet). If debug is not enabled, there is just no log 
output at all ATM. For that case, there should be at least one info line as 
overview of what was done (it is just good UX practice to give feedback on user 
actions, see use case \[1]).  Logging all paths on info is too much IMHO 
because potentially many can be configured.

\[1] 
https://cwiki.apache.org/confluence/display/SLING/Health+Checks+Executor+Design#HealthChecksExecutorDesign-B)Humanuser,webconsole

> Request Status HC does not log any INFO logs
> 
>
> Key: SLING-5799
> URL: https://issues.apache.org/jira/browse/SLING-5799
> Project: Sling
>  Issue Type: Improvement
>  Components: Health Check
>Affects Versions: Health Check Support 1.0.4
>    Reporter: Georg Henzler
>
> For the case that all requests answer with response codes as expected, the 
> SlingRequestStatusHealthCheck (org.apache.sling.hc.support) is currently not 
> giving feedback in the logs (only the bare status itself). To improve this 
> the following line should be changed from logging debug to logging info: 
> https://github.com/apache/sling/blob/trunk/bundles/extensions/healthcheck/support/src/main/java/org/apache/sling/hc/support/impl/SlingRequestStatusHealthCheck.java#L144



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (SLING-5799) Request Status HC does not log any INFO logs

[Georg Henzler (JIRA)]

Georg Henzler created SLING-5799:


 Summary: Request Status HC does not log any INFO logs
 Key: SLING-5799
 URL: https://issues.apache.org/jira/browse/SLING-5799
 Project: Sling
  Issue Type: Improvement
  Components: Health Check
Affects Versions: Health Check Support 1.0.4
Reporter: Georg Henzler


For the case that all requests answer with response codes as expected, the 
SlingRequestStatusHealthCheck (org.apache.sling.hc.support) is currently not 
giving feedback in the logs (only the bare status itself). To improve this the 
following line should be changed from logging debug to logging info: 
https://github.com/apache/sling/blob/trunk/bundles/extensions/healthcheck/support/src/main/java/org/apache/sling/hc/support/impl/SlingRequestStatusHealthCheck.java#L144




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLING-5768) Introduce sling:resourceTypes as extension to Oak permission system

[Georg Henzler (JIRA)]

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

Georg Henzler updated SLING-5768:
-
Description: 
Oak allows to extend its permissions management by using custom restrictions 
\[1], also the standard oak restrictions are based on this and are implemented 
in a fairly straight-forward way \[2] (example is for rep:ntNames). 

It would be nice to have sling level restrictions using sling properties in 
general. This issue is about introducing a restriction on resource types - the 
following should be possible:

{code}
- /content/mynode 
   - rep:policy (rep:ACL)
 - allow (rep:GrantACE)
   + principalName (String) = "myAuthorizable"
   + rep:privileges (Name[]) = "rep:write"
   - rep:restrictions (rep:Restrictions)
  + sling:resourceTypes (String[]) = 
[myproj/resourcetype1,myproj/resourcetype2]
{code}

The example would only grant "rep:write" for the resource types 
myproj/resourcetype1 and myproj/resourcetype2 in path /content/mynode, other 
resources under path /content/mynode would not have "rep:write" permissions. 

Additionally to strict resource type matching it shall be possible to 
automatically match a resource with a given resource type including all 
children. Also, not all content nodes have a resource type, therefore it should 
be possible to match against a child node by appending \@path to the resource 
type: 
{code}
- /content/myprj 
   - rep:policy (rep:ACL)
 - allow (rep:GrantACE)
   + principalName (String) = "myAuthorizable"
   + rep:privileges (Name[]) = "rep:write"
   - rep:restrictions (rep:Restrictions)
  + sling:resourceTypesWithChildren (String[]) = 
[myproj/resourcetype1@jcr:content]
{code}
To achieve this any path match attempt traverses the parents and checks for a 
match (but only up to the base path, /content/myprj in this example). For AEM 
use cases, this can match a whole page structure (e.g. something like 
/content/myprj/path/to/newsoverview, the whole news section can be easily 
matched by having a distinct news overview template). 

\[1]
https://jackrabbit.apache.org/oak/docs/security/authorization/restriction.html#Pluggability

\[2]
https://github.com/apache/jackrabbit-oak/blob/cea167f5bf70d818d58b1ffcc6bc65b3c0f9a5a4/oak-core/src/main/java/org/apache/jackrabbit/oak/security/authorization/restriction/NodeTypePattern.java#L50)
https://github.com/apache/jackrabbit-oak/blob/cea167f5bf70d818d58b1ffcc6bc65b3c0f9a5a4/oak-core/src/main/java/org/apache/jackrabbit/oak/security/authorization/restriction/RestrictionProviderImpl.java

  was:
Oak allows to extend its permissions management by using custom restrictions 
\[1], also the standard oak restrictions are based on this and are implemented 
in a fairly straight-forward way \[2] (example is for rep:ntNames). 

It would be nice to have sling level restrictions using sling properties in 
general. This issue is about introducing a restriction on resource types - the 
following should be possible:

{code}
- /content/mynode 
   - rep:policy (rep:ACL)
 - allow (rep:GrantACE)
   + principalName (String) = "myAuthorizable"
   + rep:privileges (Name[]) = "rep:write"
   - rep:restrictions (rep:Restrictions)
  + rep:resourceTypes (String[]) = 
[myproj/resourcetype1,myproj/resourcetype2]
{code}

The example would only grant "rep:write" for the resource types 
myproj/resourcetype1 and myproj/resourcetype2 in path /content/mynode, other 
resources under path /content/mynode would not have "rep:write" permissions. 

Additionally to strict resource type matching it shall be possible to 
automatically match a resource with a given resource type including all 
children. Also, not all content nodes have a resource type, therefore it should 
be possible to match against a child node by appending \@path to the resource 
type: 
{code}
- /content/myprj 
   - rep:policy (rep:ACL)
 - allow (rep:GrantACE)
   + principalName (String) = "myAuthorizable"
   + rep:privileges (Name[]) = "rep:write"
   - rep:restrictions (rep:Restrictions)
  + rep:resourceTypesWithChildren (String[]) = 
[myproj/resourcetype1@jcr:content]
{code}
To achieve this any path match attempt traverses the parents and checks for a 
match (but only up to the base path, /content/myprj in this example). For AEM 
use cases, this can match a whole page structure (e.g. something like 
/content/myprj/path/to/newsoverview, the whole news section can be easily 
matched by having a distinct news overview template). 

\[1]
https://jackrabbit.apache.org/oak/docs/security/authorization/restriction.html#Pluggability

\[2]
https://github.com/apache/jackrabbit-oak/blob/cea167f5bf70d818d58b1ffcc6bc65b3c0f9a5a4/oak-core/src/main/java/org/apache/j

[jira] [Updated] (SLING-5768) Introduce sling:resourceTypes as extension to Oak permission system

[Georg Henzler (JIRA)]

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

Georg Henzler updated SLING-5768:
-
Summary: Introduce sling:resourceTypes as extension to Oak permission 
system  (was: Introduce rep:resourceTypes as extension to Oak permission system)

> Introduce sling:resourceTypes as extension to Oak permission system
> ---
>
> Key: SLING-5768
> URL: https://issues.apache.org/jira/browse/SLING-5768
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>    Reporter: Georg Henzler
>
> Oak allows to extend its permissions management by using custom restrictions 
> \[1], also the standard oak restrictions are based on this and are 
> implemented in a fairly straight-forward way \[2] (example is for 
> rep:ntNames). 
> It would be nice to have sling level restrictions using sling properties in 
> general. This issue is about introducing a restriction on resource types - 
> the following should be possible:
> {code}
> - /content/mynode 
>- rep:policy (rep:ACL)
>  - allow (rep:GrantACE)
>+ principalName (String) = "myAuthorizable"
>+ rep:privileges (Name[]) = "rep:write"
>- rep:restrictions (rep:Restrictions)
>   +   rep:resourceTypes (String[]) = 
> [myproj/resourcetype1,myproj/resourcetype2]
> {code}
> The example would only grant "rep:write" for the resource types 
> myproj/resourcetype1 and myproj/resourcetype2 in path /content/mynode, other 
> resources under path /content/mynode would not have "rep:write" permissions. 
> Additionally to strict resource type matching it shall be possible to 
> automatically match a resource with a given resource type including all 
> children. Also, not all content nodes have a resource type, therefore it 
> should be possible to match against a child node by appending \@path to the 
> resource type: 
> {code}
> - /content/myprj 
>- rep:policy (rep:ACL)
>  - allow (rep:GrantACE)
>+ principalName (String) = "myAuthorizable"
>+ rep:privileges (Name[]) = "rep:write"
>- rep:restrictions (rep:Restrictions)
>   +   rep:resourceTypesWithChildren (String[]) = 
> [myproj/resourcetype1@jcr:content]
> {code}
> To achieve this any path match attempt traverses the parents and checks for a 
> match (but only up to the base path, /content/myprj in this example). For AEM 
> use cases, this can match a whole page structure (e.g. something like 
> /content/myprj/path/to/newsoverview, the whole news section can be easily 
> matched by having a distinct news overview template). 
> \[1]
> https://jackrabbit.apache.org/oak/docs/security/authorization/restriction.html#Pluggability
> \[2]
> https://github.com/apache/jackrabbit-oak/blob/cea167f5bf70d818d58b1ffcc6bc65b3c0f9a5a4/oak-core/src/main/java/org/apache/jackrabbit/oak/security/authorization/restriction/NodeTypePattern.java#L50)
> https://github.com/apache/jackrabbit-oak/blob/cea167f5bf70d818d58b1ffcc6bc65b3c0f9a5a4/oak-core/src/main/java/org/apache/jackrabbit/oak/security/authorization/restriction/RestrictionProviderImpl.java



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-5768) Introduce rep:resourceTypes as extension to Oak permission system

[Georg Henzler (JIRA)]

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

Georg Henzler commented on SLING-5768:
--

[~justinedelson] Thanks for pointing this out, for some reason I didn't 
consider using a namespace different than rep:* in the beginning (I'm just too 
used to rep:glob restrictions I guess). After testing it actually works just 
all fine with sling:* restrictions and I agree that it is cleaner to use the 
sling namespace. I have updated the pull request (and will update the ticket 
name/description). 

> Introduce rep:resourceTypes as extension to Oak permission system
> -
>
> Key: SLING-5768
> URL: https://issues.apache.org/jira/browse/SLING-5768
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>    Reporter: Georg Henzler
>
> Oak allows to extend its permissions management by using custom restrictions 
> \[1], also the standard oak restrictions are based on this and are 
> implemented in a fairly straight-forward way \[2] (example is for 
> rep:ntNames). 
> It would be nice to have sling level restrictions using sling properties in 
> general. This issue is about introducing a restriction on resource types - 
> the following should be possible:
> {code}
> - /content/mynode 
>- rep:policy (rep:ACL)
>  - allow (rep:GrantACE)
>+ principalName (String) = "myAuthorizable"
>+ rep:privileges (Name[]) = "rep:write"
>- rep:restrictions (rep:Restrictions)
>   +   rep:resourceTypes (String[]) = 
> [myproj/resourcetype1,myproj/resourcetype2]
> {code}
> The example would only grant "rep:write" for the resource types 
> myproj/resourcetype1 and myproj/resourcetype2 in path /content/mynode, other 
> resources under path /content/mynode would not have "rep:write" permissions. 
> Additionally to strict resource type matching it shall be possible to 
> automatically match a resource with a given resource type including all 
> children. Also, not all content nodes have a resource type, therefore it 
> should be possible to match against a child node by appending \@path to the 
> resource type: 
> {code}
> - /content/myprj 
>- rep:policy (rep:ACL)
>  - allow (rep:GrantACE)
>+ principalName (String) = "myAuthorizable"
>+ rep:privileges (Name[]) = "rep:write"
>- rep:restrictions (rep:Restrictions)
>   +   rep:resourceTypesWithChildren (String[]) = 
> [myproj/resourcetype1@jcr:content]
> {code}
> To achieve this any path match attempt traverses the parents and checks for a 
> match (but only up to the base path, /content/myprj in this example). For AEM 
> use cases, this can match a whole page structure (e.g. something like 
> /content/myprj/path/to/newsoverview, the whole news section can be easily 
> matched by having a distinct news overview template). 
> \[1]
> https://jackrabbit.apache.org/oak/docs/security/authorization/restriction.html#Pluggability
> \[2]
> https://github.com/apache/jackrabbit-oak/blob/cea167f5bf70d818d58b1ffcc6bc65b3c0f9a5a4/oak-core/src/main/java/org/apache/jackrabbit/oak/security/authorization/restriction/NodeTypePattern.java#L50)
> https://github.com/apache/jackrabbit-oak/blob/cea167f5bf70d818d58b1ffcc6bc65b3c0f9a5a4/oak-core/src/main/java/org/apache/jackrabbit/oak/security/authorization/restriction/RestrictionProviderImpl.java



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLING-5768) Introduce rep:resourceTypes as extension to Oak permission system

[Georg Henzler (JIRA)]

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

Georg Henzler updated SLING-5768:
-
Description: 
Oak allows to extend its permissions management by using custom restrictions 
\[1], also the standard oak restrictions are based on this and are implemented 
in a fairly straight-forward way \[2] (example is for rep:ntNames). 

It would be nice to have sling level restrictions using sling properties in 
general. This issue is about introducing a restriction on resource types - the 
following should be possible:

{code}
- /content/mynode 
   - rep:policy (rep:ACL)
 - allow (rep:GrantACE)
   + principalName (String) = "myAuthorizable"
   + rep:privileges (Name[]) = "rep:write"
   - rep:restrictions (rep:Restrictions)
  + rep:resourceTypes (String[]) = 
[myproj/resourcetype1,myproj/resourcetype2]
{code}

The example would only grant "rep:write" for the resource types 
myproj/resourcetype1 and myproj/resourcetype2 in path /content/mynode, other 
resources under path /content/mynode would not have "rep:write" permissions. 

Additionally to strict resource type matching it shall be possible to 
automatically match a resource with a given resource type including all 
children. Also, not all content nodes have a resource type, therefore it should 
be possible to match against a child node by appending \@path to the resource 
type: 
{code}
- /content/myprj 
   - rep:policy (rep:ACL)
 - allow (rep:GrantACE)
   + principalName (String) = "myAuthorizable"
   + rep:privileges (Name[]) = "rep:write"
   - rep:restrictions (rep:Restrictions)
  + rep:resourceTypesWithChildren (String[]) = 
[myproj/resourcetype1@jcr:content]
{code}
To achieve this any path match attempt traverses the parents and checks for a 
match (but only up to the base path, /content/myprj in this example). For AEM 
use cases, this can match a whole page structure (e.g. something like 
/content/myprj/path/to/newsoverview, the whole news section can be easily 
matched by having a distinct news overview template). 

\[1]
https://jackrabbit.apache.org/oak/docs/security/authorization/restriction.html#Pluggability

\[2]
https://github.com/apache/jackrabbit-oak/blob/cea167f5bf70d818d58b1ffcc6bc65b3c0f9a5a4/oak-core/src/main/java/org/apache/jackrabbit/oak/security/authorization/restriction/NodeTypePattern.java#L50)
https://github.com/apache/jackrabbit-oak/blob/cea167f5bf70d818d58b1ffcc6bc65b3c0f9a5a4/oak-core/src/main/java/org/apache/jackrabbit/oak/security/authorization/restriction/RestrictionProviderImpl.java

  was:
Oak allows to extend its permissions management by using custom restrictions 
\[1], also the standard oak restrictions are based on this and are implemented 
in a fairly straight-forward way \[2] (example is for rep:ntNames). 

It would be nice to have sling level restrictions using sling properties in 
general. This issue is about introducing a restriction on resource types - the 
following should be possible:

{code}
- /content/mynode 
   - rep:policy (rep:ACL)
 - allow (rep:GrantACE)
   + principalName (String) = "myAuthorizable"
   + rep:privileges (Name[]) = "rep:write"
   - rep:restrictions (rep:Restrictions)
  + rep:resourceTypes (String[]) = 
[myproj/resourcetype1,myproj/resourcetype2]
{code}

The example would only grant "rep:write" for the resource types 
myproj/resourcetype1 and myproj/resourcetype2 in path /content/mynode, other 
resources under path /content/mynode would not have "rep:write" permissions. 

Additionally to strict resource type matching it shall be possible to 
automatically match a resource with a given resource type including all 
children. Also, not all content nodes have a resource type, therefore it should 
be possible to match against a child node by appending \@path to the resource 
type: 
{code}
- /content/mynode 
   - rep:policy (rep:ACL)
 - allow (rep:GrantACE)
   + principalName (String) = "myAuthorizable"
   + rep:privileges (Name[]) = "rep:write"
   - rep:restrictions (rep:Restrictions)
  + rep:resourceTypesWithChildren (String[]) = 
[myproj/resourcetype1@jcr:content]
{code}
To achieve this any path match attempt traverses the parents and checks for a 
match (but only up to the base path, /content/mynode in this example). For AEM 
use cases, this can match whole page structure (e.g. something like 
/content/myprj/path/to/newsoverview, the whole news section can be easily 
matched by having a distinct news overview template). 

\[1]
https://jackrabbit.apache.org/oak/docs/security/authorization/restriction.html#Pluggability

\[2]
https://github.com/apache/jackrabbit-oak/blob/cea167f5bf70d818d58b1ffcc6bc65b3c0f9a5a4/oak-core/src/main/java/org/apache/j

[jira] [Updated] (SLING-5768) Introduce rep:resourceTypes as extension to Oak permission system

[Georg Henzler (JIRA)]

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

Georg Henzler updated SLING-5768:
-
Description: 
Oak allows to extend its permissions management by using custom restrictions 
\[1], also the standard oak restrictions are based on this and are implemented 
in a fairly straight-forward way \[2] (example is for rep:ntNames). 

It would be nice to have sling level restrictions using sling properties in 
general. This issue is about introducing a restriction on resource types - the 
following should be possible:

{code}
- /content/mynode 
   - rep:policy (rep:ACL)
 - allow (rep:GrantACE)
   + principalName (String) = "myAuthorizable"
   + rep:privileges (Name[]) = "rep:write"
   - rep:restrictions (rep:Restrictions)
  + rep:resourceTypes (String[]) = 
[myproj/resourcetype1,myproj/resourcetype2]
{code}

The example would only grant "rep:write" for the resource types 
myproj/resourcetype1 and myproj/resourcetype2 in path /content/mynode, other 
resources under path /content/mynode would not have "rep:write" permissions. 

Additionally to strict resource type matching it shall be possible to 
automatically match a resource with a given resource type including all 
children. Also, not all content nodes have a resource type, therefore it should 
be possible to match against a child node by appending \@path to the resource 
type: 
{code}
- /content/mynode 
   - rep:policy (rep:ACL)
 - allow (rep:GrantACE)
   + principalName (String) = "myAuthorizable"
   + rep:privileges (Name[]) = "rep:write"
   - rep:restrictions (rep:Restrictions)
  + rep:resourceTypesWithChildren (String[]) = 
[myproj/resourcetype1@jcr:content]
{code}
To achieve this any path match attempt traverses the parents and checks for a 
match (but only up to the base path, /content/mynode in this example). For AEM 
use cases, this can match whole page structure (e.g. something like 
/content/myprj/path/to/newsoverview, the whole news section can be easily 
matched by having a distinct news overview template). 

\[1]
https://jackrabbit.apache.org/oak/docs/security/authorization/restriction.html#Pluggability

\[2]
https://github.com/apache/jackrabbit-oak/blob/cea167f5bf70d818d58b1ffcc6bc65b3c0f9a5a4/oak-core/src/main/java/org/apache/jackrabbit/oak/security/authorization/restriction/NodeTypePattern.java#L50)
https://github.com/apache/jackrabbit-oak/blob/cea167f5bf70d818d58b1ffcc6bc65b3c0f9a5a4/oak-core/src/main/java/org/apache/jackrabbit/oak/security/authorization/restriction/RestrictionProviderImpl.java

  was:
Oak allows to extend its permissions management by using custom restrictions 
\[1], also the standard oak restrictions are based on this and are implemented 
in a fairly straight-forward way \[2] (example is for rep:ntNames). 

It would be nice to have sling level restrictions using sling properties in 
general. This issue is about introducing a restriction on resource types - the 
following should be possible:

{code}
- /content/mynode 
   - rep:policy (rep:ACL)
 - allow (rep:GrantACE)
   + principalName (String) = "myAuthorizable"
   + rep:privileges (Name[]) = "rep:write"
   - rep:restrictions (rep:Restrictions)
  + rep:resourceTypes (String[]) = 
[myproj/resourcetype1,myproj/resourcetype2]
{code}

The example would only grant "rep:write" for the resource types 
myproj/resourcetype1 and myproj/resourcetype2 in path /content/mynode, other 
resources under path /content/mynode would not have "rep:write" permissions. 

Additionally to strict resource type matching it shall be possible to 
automatically match a resource with a given resource type including all 
children. Also, not all content nodes have a resource type, therefore it should 
be possible to match against a child node by appending \@path to the resource 
type: 
{code}
- /content/mynode 
   - rep:policy (rep:ACL)
 - allow (rep:GrantACE)
   + principalName (String) = "myAuthorizable"
   + rep:privileges (Name[]) = "rep:write"
   - rep:restrictions (rep:Restrictions)
  + rep:resourceTypesWithChildren (String[]) = 
[myproj/resourcetype1@jcr:content]
{code}
For AEM use cases, this can match whole page structure. 

\[1]
https://jackrabbit.apache.org/oak/docs/security/authorization/restriction.html#Pluggability

\[2]
https://github.com/apache/jackrabbit-oak/blob/cea167f5bf70d818d58b1ffcc6bc65b3c0f9a5a4/oak-core/src/main/java/org/apache/jackrabbit/oak/security/authorization/restriction/NodeTypePattern.java#L50)
https://github.com/apache/jackrabbit-oak/blob/cea167f5bf70d818d58b1ffcc6bc65b3c0f9a5a4/oak-core/src/main/java/org/apache/jackrabbit/oak/security/authorization/restriction/RestrictionProviderImpl.java


> Introduce rep:resourceTypes as ext

[jira] [Updated] (SLING-5768) Introduce rep:resourceTypes as extension to Oak permission system

[Georg Henzler (JIRA)]

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

Georg Henzler updated SLING-5768:
-
Description: 
Oak allows to extend its permissions management by using custom restrictions 
\[1], also the standard oak restrictions are based on this and are implemented 
in a fairly straight-forward way \[2] (example is for rep:ntNames). 

It would be nice to have sling level restrictions using sling properties in 
general. This issue is about introducing a restriction on resource types - the 
following should be possible:

{code}
- /content/mynode 
   - rep:policy (rep:ACL)
 - allow (rep:GrantACE)
   + principalName (String) = "myAuthorizable"
   + rep:privileges (Name[]) = "rep:write"
   - rep:restrictions (rep:Restrictions)
  + rep:resourceTypes (String[]) = 
[myproj/resourcetype1,myproj/resourcetype2]
{code}

The example would only grant "rep:write" for the resource types 
myproj/resourcetype1 and myproj/resourcetype2 in path /content/mynode, other 
resources under path /content/mynode would not have "rep:write" permissions. 

Additionally to strict resource type matching it shall be possible to 
automatically match a resource with a given resource type including all 
children. Also, not all content nodes have a resource type, therefore it should 
be possible to match against a child node by appending \@path to the resource 
type: 
{code}
- /content/mynode 
   - rep:policy (rep:ACL)
 - allow (rep:GrantACE)
   + principalName (String) = "myAuthorizable"
   + rep:privileges (Name[]) = "rep:write"
   - rep:restrictions (rep:Restrictions)
  + rep:resourceTypesWithChildren (String[]) = 
[myproj/resourcetype1@jcr:content]
{code}
For AEM use cases, this can match whole page structure. 

\[1]
https://jackrabbit.apache.org/oak/docs/security/authorization/restriction.html#Pluggability

\[2]
https://github.com/apache/jackrabbit-oak/blob/cea167f5bf70d818d58b1ffcc6bc65b3c0f9a5a4/oak-core/src/main/java/org/apache/jackrabbit/oak/security/authorization/restriction/NodeTypePattern.java#L50)
https://github.com/apache/jackrabbit-oak/blob/cea167f5bf70d818d58b1ffcc6bc65b3c0f9a5a4/oak-core/src/main/java/org/apache/jackrabbit/oak/security/authorization/restriction/RestrictionProviderImpl.java

  was:
Oak allows to extend its permissions management by using custom restrictions 
\[1], also the standard oak restrictions are based on this and are implemented 
in a fairly straight-forward way \[2] (example is for rep:ntNames). 

It would be nice to have sling level restrictions using sling properties in 
general. This issue is about introducing a restriction on resource types - the 
following should be possible:

{code}
- /content/mynode 
   - rep:policy (rep:ACL)
 - allow (rep:GrantACE)
   + principalName (String) = "myAuthorizable"
   + rep:privileges (Name[]) = "rep:write"
   - rep:restrictions (rep:Restrictions)
  + rep:slingResourceTypes (String[]) = 
[myproj/resourcetype1,myproj/resourcetype2]
{code}

The example would only grant "rep:write" for the resource types 
myproj/resourcetype1 and myproj/resourcetype2 in path /content/mynode, other 
resources under path /content/mynode would not have "rep:write" permissions. 

See github PR for a first simple implementation (adding a bundle 
org.apache.sling.sling-oak-restrictions to contributions, not sure if this is 
the best spot). 

\[1]
https://jackrabbit.apache.org/oak/docs/security/authorization/restriction.html#Pluggability

\[2]
https://github.com/apache/jackrabbit-oak/blob/cea167f5bf70d818d58b1ffcc6bc65b3c0f9a5a4/oak-core/src/main/java/org/apache/jackrabbit/oak/security/authorization/restriction/NodeTypePattern.java#L50)
https://github.com/apache/jackrabbit-oak/blob/cea167f5bf70d818d58b1ffcc6bc65b3c0f9a5a4/oak-core/src/main/java/org/apache/jackrabbit/oak/security/authorization/restriction/RestrictionProviderImpl.java


> Introduce rep:resourceTypes as extension to Oak permission system
> -
>
> Key: SLING-5768
> URL: https://issues.apache.org/jira/browse/SLING-5768
>     Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>Reporter: Georg Henzler
>
> Oak allows to extend its permissions management by using custom restrictions 
> \[1], also the standard oak restrictions are based on this and are 
> implemented in a fairly straight-forward way \[2] (example is for 
> rep:ntNames). 
> It would be nice to have sling level restrictions using sling properties in 
> general. This issue is about introducing a restriction on resource types - 
> the following should be possible:
> {code}
> - /c

[jira] [Commented] (SLING-5768) Introduce rep:slingResourceTypes as extension to Oak permission system

[Georg Henzler (JIRA)]

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

Georg Henzler commented on SLING-5768:
--

[~rombert] Thanks for looking into this. I fixed your suggestions and made 
further improvements:
* Got rid of the google guava dependency (the oak restrictions use it, but we 
don't really need it)
* Fixed mvn structure (sling parent, scope provided)
* Improved path matching matching resource types in sub nodes, e.g. 
myproj/mypagetype@jcr:content (will also update ticket description for that)
* Resource type inheritance is not supported by design at the moment. I think 
it would require a cache of the resource type hierarchy (and listeners etc.) to 
not degrade performance too much. Also, usually hierarchy should be not too 
complicated and it is always possible to list all resource types of a 
hierarchy. Can be considered for a later version.  
* rep:slingResourceTypes is quite verbose, and a name clash with other 
"resource types" is very unlikely, therefore I decided to got for the simpler 
rep:resourceTypes (also in respect to next bullet)
* Introduced rep:resourceTypesWithChildren that matches all resource types 
matches including all of their children (that's the best name I could think of, 
using "inheritance" in the name would not be a good idea). I think this is 
useful for all container types (think jcr:content or accordions). 
* Added JUnit tests with decent coverage 

> Introduce rep:slingResourceTypes as extension to Oak permission system
> --
>
> Key: SLING-5768
> URL: https://issues.apache.org/jira/browse/SLING-5768
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>Reporter: Georg Henzler
>
> Oak allows to extend its permissions management by using custom restrictions 
> \[1], also the standard oak restrictions are based on this and are 
> implemented in a fairly straight-forward way \[2] (example is for 
> rep:ntNames). 
> It would be nice to have sling level restrictions using sling properties in 
> general. This issue is about introducing a restriction on resource types - 
> the following should be possible:
> {code}
> - /content/mynode 
>- rep:policy (rep:ACL)
>  - allow (rep:GrantACE)
>+ principalName (String) = "myAuthorizable"
>+ rep:privileges (Name[]) = "rep:write"
>- rep:restrictions (rep:Restrictions)
>   +   rep:slingResourceTypes (String[]) = 
> [myproj/resourcetype1,myproj/resourcetype2]
> {code}
> The example would only grant "rep:write" for the resource types 
> myproj/resourcetype1 and myproj/resourcetype2 in path /content/mynode, other 
> resources under path /content/mynode would not have "rep:write" permissions. 
> See github PR for a first simple implementation (adding a bundle 
> org.apache.sling.sling-oak-restrictions to contributions, not sure if this is 
> the best spot). 
> \[1]
> https://jackrabbit.apache.org/oak/docs/security/authorization/restriction.html#Pluggability
> \[2]
> https://github.com/apache/jackrabbit-oak/blob/cea167f5bf70d818d58b1ffcc6bc65b3c0f9a5a4/oak-core/src/main/java/org/apache/jackrabbit/oak/security/authorization/restriction/NodeTypePattern.java#L50)
> https://github.com/apache/jackrabbit-oak/blob/cea167f5bf70d818d58b1ffcc6bc65b3c0f9a5a4/oak-core/src/main/java/org/apache/jackrabbit/oak/security/authorization/restriction/RestrictionProviderImpl.java



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLING-5768) Introduce rep:resourceTypes as extension to Oak permission system

[Georg Henzler (JIRA)]

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

Georg Henzler updated SLING-5768:
-
Summary: Introduce rep:resourceTypes as extension to Oak permission system  
(was: Introduce rep:slingResourceTypes as extension to Oak permission system)

> Introduce rep:resourceTypes as extension to Oak permission system
> -
>
> Key: SLING-5768
> URL: https://issues.apache.org/jira/browse/SLING-5768
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>    Reporter: Georg Henzler
>
> Oak allows to extend its permissions management by using custom restrictions 
> \[1], also the standard oak restrictions are based on this and are 
> implemented in a fairly straight-forward way \[2] (example is for 
> rep:ntNames). 
> It would be nice to have sling level restrictions using sling properties in 
> general. This issue is about introducing a restriction on resource types - 
> the following should be possible:
> {code}
> - /content/mynode 
>- rep:policy (rep:ACL)
>  - allow (rep:GrantACE)
>+ principalName (String) = "myAuthorizable"
>+ rep:privileges (Name[]) = "rep:write"
>- rep:restrictions (rep:Restrictions)
>   +   rep:slingResourceTypes (String[]) = 
> [myproj/resourcetype1,myproj/resourcetype2]
> {code}
> The example would only grant "rep:write" for the resource types 
> myproj/resourcetype1 and myproj/resourcetype2 in path /content/mynode, other 
> resources under path /content/mynode would not have "rep:write" permissions. 
> See github PR for a first simple implementation (adding a bundle 
> org.apache.sling.sling-oak-restrictions to contributions, not sure if this is 
> the best spot). 
> \[1]
> https://jackrabbit.apache.org/oak/docs/security/authorization/restriction.html#Pluggability
> \[2]
> https://github.com/apache/jackrabbit-oak/blob/cea167f5bf70d818d58b1ffcc6bc65b3c0f9a5a4/oak-core/src/main/java/org/apache/jackrabbit/oak/security/authorization/restriction/NodeTypePattern.java#L50)
> https://github.com/apache/jackrabbit-oak/blob/cea167f5bf70d818d58b1ffcc6bc65b3c0f9a5a4/oak-core/src/main/java/org/apache/jackrabbit/oak/security/authorization/restriction/RestrictionProviderImpl.java



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (SLING-5768) Introduce rep:slingResourceTypes as extension to Oak permission system

[Georg Henzler (JIRA)]

Georg Henzler created SLING-5768:


 Summary: Introduce rep:slingResourceTypes as extension to Oak 
permission system
 Key: SLING-5768
 URL: https://issues.apache.org/jira/browse/SLING-5768
 Project: Sling
  Issue Type: New Feature
  Components: Extensions
Reporter: Georg Henzler


Oak allows to extend its permissions management by using custom restrictions 
\[1], also the standard oak restrictions are based on this and are implemented 
in a fairly straight-forward way \[2] (example is for rep:ntNames). 

It would be nice to have sling level restrictions using sling properties in 
general. This issue is about introducing a restriction on resource types - the 
following should be possible:

{code}
- /content/mynode 
   - rep:policy (rep:ACL)
 - allow (rep:GrantACE)
   + principalName (String) = "myAuthorizable"
   + rep:privileges (Name[]) = "rep:write"
   - rep:restrictions (rep:Restrictions)
  + rep:slingResourceTypes (String[]) = 
[myproj/resourcetype1,myproj/resourcetype2]
{code}

The example would only grant "rep:write" for the resource types 
myproj/resourcetype1 and myproj/resourcetype2 in path /content/mynode, other 
resources under path /content/mynode would not have "rep:write" permissions. 

See github PR for a first simple implementation (adding a bundle 
org.apache.sling.sling-oak-restrictions to contributions, not sure if this is 
the best spot). 

\[1]
https://jackrabbit.apache.org/oak/docs/security/authorization/restriction.html#Pluggability

\[2]
https://github.com/apache/jackrabbit-oak/blob/cea167f5bf70d818d58b1ffcc6bc65b3c0f9a5a4/oak-core/src/main/java/org/apache/jackrabbit/oak/security/authorization/restriction/NodeTypePattern.java#L50)
https://github.com/apache/jackrabbit-oak/blob/cea167f5bf70d818d58b1ffcc6bc65b3c0f9a5a4/oak-core/src/main/java/org/apache/jackrabbit/oak/security/authorization/restriction/RestrictionProviderImpl.java



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Dependency Management

[Georg Henzler]

On 2016-05-26 14:36, Bertrand Delacretaz wrote:

My opinion, and I think this is what we've been doing in Sling forever
even if we didn't explicitly document it, is that if a bundle B
depends on another *for its API* then the dependency should list the
lowest possible version.


I agree to this.

... just tried to run the latest with hc-core [1] to test something 
completely else and obviously it does not work with AEM anymore unless 
you deploy commons lang3 elsewhere - IMHO there is no need to make 
everyone go through this hassle (for me it was easier to revert the 
commit to test what I was testing...)


Regards
Georg

[1]
https://github.com/apache/sling/commit/7203dc7ec1b7b85ecca93450179bbefa78f7bd02?diff=unified

[jira] [Commented] (SLING-5754) Sightly renders form attributes always in lowercase

[Georg Henzler (JIRA)]

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

Georg Henzler commented on SLING-5754:
--

As it turned out this is not a Sightly problem, but rather happens in 
com.day.cq.rewriter.htmlparser.TagTokenizer#attributeEnded(...) for all tags 
that are configured to be rewritten via includeTags configuration. The standard 
sling generator 
(org.apache.sling.rewriter.impl.components.HtmlGeneratorFactory) does not do 
this. 

[~kwin] Please close as invalid (as I don't have permissions to do so).  

> Sightly renders form attributes always in lowercase
> ---
>
> Key: SLING-5754
> URL: https://issues.apache.org/jira/browse/SLING-5754
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Affects Versions: Scripting Sightly Engine 1.0.2
>Reporter: Erik Grijzen
>
> Sightly always renders all HTML attributes of a  element in lowercase:
> HTML source:
> {code}
> 
> {code}
> Actual output:
> {code}
> 
> {code}
> Expected output:
> {code}
> 
> {code}
> For other HTML tags like , , , etc. it works fine.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Resource.getParent() on NonExistingResource

[Georg Henzler]

Hi Konrad,

+1 for making the behaviour of NonExistingResource more consistent - I 
personally can't think of any places this would break existing code.


Regards
Georg


On 2016-06-01 15:09, Konrad Windszus wrote:

Hi Robert,
thanks for your input.



I am not sure whether this would confuse existing clients though...


I am also a bit worried about that but the only example I could think
of is a code trying to create the parent nodes or collecting the
non-existing ones by checking getParent() for null.

This would be pretty bad style IMHO therefore I would deliberately be
willing to break that code. I wonder what do others think about
changing the semantics of getParent() for NonExistingResource and
probably also SyntheticResource.
Konrad

[jira] [Commented] (SLING-5721) Extend Sling Models to allow mapping of ValueMap values to custom types

[Georg Henzler (JIRA)]

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

Georg Henzler commented on SLING-5721:
--

*Value Converter SPI in general*
Before we just light-heatedly introduce a ValueConverter SPI just for this 
issue we should probably go through a discussion thread in the mailing list or 
even better, create a wiki page to discuss what we expect from it - a few 
things to consider:
* Hibernate has custom types (e.g. 
http://what-when-how.com/hibernate/inheritance-and-custom-types-hibernate/) 
that allows to map multiple DB properties to one Type (people are complaining 
that JPA is still not supporting this in version 2.1). For this use case the 
current SPI does not work
* "I don't expect the list/array conversion could be migrated into 
ValueConverters as it is actually one level below where the SPI operates" - 
does this have to be like that? I feel like this is a decision that has to be 
taken carefully (I already fear the interface ValueConverter2)
* What about interfaces and class hierarchies? (currently the ValueConverter 
SPI is just maintaining a Map<Type,Converter> and only converting if it is an 
exact type match)

*For this particular use case* 

bq. Your pull request also makes the same (bad) assumption I originally made 
with respect to a single-argument constructor. What happens when the converted 
type can only be constructed using a multi-argument constructor or through a 
static method?

To have solution with a converter for complicated mappings where I don't have 
the  control over the code is nice, but is relevant for 1% of the use cases (if 
even). Most of the time I do have the custom type under my control (but it must 
not be limited to just one constructor, that was my main problem with your 
initial ModelFactoryPatch). And for those 99% of the cases, I do not want to 
write code when the framework can make the correct assumptions. (an example of 
how bad things can get was J2EE, that did not have nice defaults and was not 
easy to use - let's not make Sling Models to a J2EE-ish framework)

In general I think a cross-cutting solution would be nice - but I think it will 
not work until Injector.getValue(...) will not pass in the type to the 
injector. This is probably something to think about for Sling Models 2.0 (and 
not just for a "little feature")

bq. performance
I really (still) don't want to implement com.mycomp.myproj.LinkValueConverter 
and a com.mycomp.myproj.EventDateValueConverter for my use case in the 
description - to allow this with the current ValueConverter SPI we would have 
to add a {{DefaultValueConverter implements ValueConverter<Object,Object>}} 
that runs through any value that Sling Models injects => bad performance. 
Additionally to even make it possible, {{valueConverters.put(container.to, 
container);}} in {{bindValueConverter()}} would also have to be changed to 
support inheritance.

> Extend Sling Models to allow mapping of ValueMap values to custom types
> ---
>
> Key: SLING-5721
> URL: https://issues.apache.org/jira/browse/SLING-5721
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>Affects Versions: Sling Models API 1.2.2
>Reporter: Georg Henzler
> Attachments: SLING-5721-valueconverter-spi.diff, 
> SLING-5721-valueconverter-spi2.diff, SLING-5721.patch
>
>
> At the moment it is already possible to map child resources via 
> @ChildResource to a custom type (that itself only needs to be adaptable from 
> that child resource), but for a plain property it is not yet possible: 
> {code}
> @Inject
> com.mycomp.myproj.Link homePath; // jcr property of type String, does not 
> work currently
> @Inject
> com.mycomp.myproj.EventDate eventDate; // jcr property of type Date, does not 
> work currently
> @Inject
> java.util.Date regularDate; // jcr property of type Date, already works due 
> to standard type conversion available in ValueMap
> {code}
> For custom types, the convention would be that there needs to be a public 
> constructor with one argument with the type of the object as returned by 
> valueMap.get(name). That way a custom type can easily work with situations, 
> where the type of the JCR property is not fixed (e.g. if a property can be of 
> type String or Date, the custom type can just provide both constructors).
> {code}
> @ValueMapObject // opposed to @ValueMapValue
> com.mycomp.myproj.Link homePath; // will call constructor new 
> Link(homePathString) if possible as homePath property exists with type String 
> {code}
> Furthermore it should be possible to map JCR array types:
>

[jira] [Commented] (SLING-5721) Extend Sling Models to allow mapping of ValueMap values to custom types

[Georg Henzler (JIRA)]

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

Georg Henzler commented on SLING-5721:
--

*For this particular use case*
[~justinedelson] Using value converters here is too complicated IMHO, because 
it would force a project to register a value converter for each type that 
should be allowed in models (for the two properties given in the description I 
would already have to register a com.mycomp.myproj.LinkValueConverter and a 
com.mycomp.myproj.EventDateValueConverter. This really should happen 
automatically - [PR 138|https://github.com/apache/sling/pull/138] does this 
already without extra complexity and without introducing a performance penalty.

*Value Converter SPI in general*

bq. What kind of converters would be shipped then with Sling Models OOTB

I agree with [~kwin]'s comment that we should know more than just this one use 
case (for which it even does not work in an easy way) to justify a 
ValueConverter SPI. Also there is already a lot of type conversion going on in 
the injectors (as the interface asks for the expected type in 
https://github.com/apache/sling/blob/trunk/bundles/extensions/models/api/src/main/java/org/apache/sling/models/spi/Injector.java#L52)
 - If we really go down the ValueConverter SPI path I would like to see a 
feature branch that proves that at least all this List/array conversion code in 
the injectors can be then moved centrally to a ValueConverter. 

So my suggestion is to refactor [PR 
138|https://github.com/apache/sling/pull/138] a bit to use @ValueMapValue 
(instead of a new API) - I will have time to do this next week.

> Extend Sling Models to allow mapping of ValueMap values to custom types
> ---
>
> Key: SLING-5721
> URL: https://issues.apache.org/jira/browse/SLING-5721
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>Affects Versions: Sling Models API 1.2.2
>    Reporter: Georg Henzler
> Attachments: SLING-5721-valueconverter-spi.diff, 
> SLING-5721-valueconverter-spi2.diff, SLING-5721.patch
>
>
> At the moment it is already possible to map child resources via 
> @ChildResource to a custom type (that itself only needs to be adaptable from 
> that child resource), but for a plain property it is not yet possible: 
> {code}
> @Inject
> com.mycomp.myproj.Link homePath; // jcr property of type String, does not 
> work currently
> @Inject
> com.mycomp.myproj.EventDate eventDate; // jcr property of type Date, does not 
> work currently
> @Inject
> java.util.Date regularDate; // jcr property of type Date, already works due 
> to standard type conversion available in ValueMap
> {code}
> For custom types, the convention would be that there needs to be a public 
> constructor with one argument with the type of the object as returned by 
> valueMap.get(name). That way a custom type can easily work with situations, 
> where the type of the JCR property is not fixed (e.g. if a property can be of 
> type String or Date, the custom type can just provide both constructors).
> {code}
> @ValueMapObject // opposed to @ValueMapValue
> com.mycomp.myproj.Link homePath; // will call constructor new 
> Link(homePathString) if possible as homePath property exists with type String 
> {code}
> Furthermore it should be possible to map JCR array types:
> {code}
> @ValueMapObject 
> List links; // would expect a String[] and should put 
> the corresponding Link objects into a list (if the JCR type is String, it 
> should use that one element to fill the list with one Link
> @ValueMapObject 
> com.mycomp.myproj.Link[] links; // arrays should work in the same way
> {code}
> See github patch for a fairly straight-forward implementation the above 
> approach. An alternative approach would be to extend @ValueMapValue (I'm open 
> for both approaches, @ValueMapObject is more explicit in model classes).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-5739) [Sling Models] Allow for extensible @Via providers

[Georg Henzler (JIRA)]

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

Georg Henzler commented on SLING-5739:
--

Having thought about this a bit more, I think the @Via for "switching" the 
resource to a different place makes actually sense - you are right that 
probably only the JcrResourceProvider supports deep paths like 
"jcr:content/myProperty". 

I think that the {{@Via(value = "jcr:content", type = ChildResource.class)}} is 
not a very nice way of mapping it though, would maybe something like 
{{@ViaResource("jcr:content")}} or {{@Via @Path("jcr:content")}} be nicer? 
Maybe introducing {{@ViaResource}} would be better, this new annotation would 
allow a syntax like {{@ViaResource(pathLookupProperty="fileReference")}}, this 
would make it really clear if the path is taken as such or if a mapping via the 
ValueMap is done (in the current {{@ResourcePath}} annotation, the behaviour 
that given paths are taken as is and the fallback is the property name that is 
looked up via ValueMap is confusing to understand IMHO).

The main driver here should not be how things are implemented but rather how 
they look like in the mapping IMHO. WDYT?

> [Sling Models] Allow for extensible @Via providers
> --
>
> Key: SLING-5739
> URL: https://issues.apache.org/jira/browse/SLING-5739
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>Reporter: Justin Edelson
>
> Currently, @Via support in Sling Models is limited to JavaBean properties. It 
> would be useful to be able to extend this and allow for downstream projects 
> to add new @Via providers.
> Proposing to support this by extending the @Via annotation
> {code}
> @Via(value = "jcr:content", type = ChildResource.class)
> {code}
> The default type is BeanProperty (the current behavior).
> New providers can be added by implementing a ViaProvider SPI and provide a 
> marker class for use in the annotation.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-5726) Allow ValueMapInjector and ResourcePathInjector to act directly on SlingHttpServletRequest

[Georg Henzler (JIRA)]

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

Georg Henzler commented on SLING-5726:
--

I think the main driver should be ease of use from a developers perspective 
(maybe we should create a wiki page with example mappings to make it more 
visual how typical scenarios look like!). Mappings should be easy to read and 
write. So introducing something like {{@Inject @Via(value = "resource", 
forAdaptable = SlingHttpServletRequest.class)}} makes sense iff {{@Inject}} 
alone has a different behaviour, but if {{@Inject}} alone is just defunct (when 
it really could just work), then adding the burden to make all developers add 
{{@Via(value = "resource", forAdaptable = SlingHttpServletRequest.class)}} is 
not reasonable (good framework should have good defaults). 

For me the main point is: Sling Models is about mapping resources to java 
Pojos. We have added the ability to map request context to be able to use the 
models in a controller like fashion. In the end a request is (from a Sling 
Models point of view) just a resource with a "a bit of context".  I would 
therefore handle adaptations from requests/resources almost identical (the only 
difference that the information from the request context is missing, but 
setters can be used to set these values in non-request context use-cases).

> Allow ValueMapInjector and ResourcePathInjector to act directly on 
> SlingHttpServletRequest
> --
>
> Key: SLING-5726
> URL: https://issues.apache.org/jira/browse/SLING-5726
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: Sling Models Impl 1.2.8
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Attachments: SLING-5726.patch
>
>
> Currently both injectors only work correctly on objects being adaptable to a 
> {{ValueMap}}. For {{ValueMapInjector}} this is documented but for 
> {{ResourcePathInjector}} it is not 
> (http://sling.apache.org/documentation/bundles/models.html#available-injectors),
>  although for the latter it does only matter if the path is given through a 
> resource property and not in a static way.
> This should be relaxed that both also work with {{SlingHttpServletRequest}} 
> as that always carries the current resource from which the {{ValueMap}} can 
> be easily retrieved.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-5721) Extend Sling Models to allow mapping of ValueMap values to custom types

[Georg Henzler (JIRA)]

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

Georg Henzler commented on SLING-5721:
--

This approach is nice as it allows to use simple classes with one-arg 
constructors for  e.g. {{@RequestAttribute}} as well. Just a few things that 
should be considered:
* the pull request 138 also supports Lists (and arrays) like 
{{List links}} (derived from a String[] JCR Property) - 
could you support this with your patch as well?
* Checking {{constructors.length==1}} is problematic - you don't always have 
control over the classes to be used here (might be part of some other API) and 
even if it can be controlled, there are many cases where more than one 
constructor makes sense for other use cases (e.g. the Link class in my 
particular real-life example has a clone constructor besides the one-arg String 
constructor)
* Performance:  {{elementClass.getConstructors()}} and 
{{candidateConstructor.getGenericParameterTypes()}} will be called many times 
for injectors where this approach is not applicable - not sure if there is a 
real impact. Maybe adding an additional clause to {{else if (elementType 
instanceof Class)}} to ensure {{java.lang.*}} classes are excluded generally 
would be enough to ensure there is no problem here.

> Extend Sling Models to allow mapping of ValueMap values to custom types
> ---
>
> Key: SLING-5721
> URL: https://issues.apache.org/jira/browse/SLING-5721
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>Affects Versions: Sling Models API 1.2.2
>    Reporter: Georg Henzler
> Attachments: SLING-5721.patch
>
>
> At the moment it is already possible to map child resources via 
> @ChildResource to a custom type (that itself only needs to be adaptable from 
> that child resource), but for a plain property it is not yet possible: 
> {code}
> @Inject
> com.mycomp.myproj.Link homePath; // jcr property of type String, does not 
> work currently
> @Inject
> com.mycomp.myproj.EventDate eventDate; // jcr property of type Date, does not 
> work currently
> @Inject
> java.util.Date regularDate; // jcr property of type Date, already works due 
> to standard type conversion available in ValueMap
> {code}
> For custom types, the convention would be that there needs to be a public 
> constructor with one argument with the type of the object as returned by 
> valueMap.get(name). That way a custom type can easily work with situations, 
> where the type of the JCR property is not fixed (e.g. if a property can be of 
> type String or Date, the custom type can just provide both constructors).
> {code}
> @ValueMapObject // opposed to @ValueMapValue
> com.mycomp.myproj.Link homePath; // will call constructor new 
> Link(homePathString) if possible as homePath property exists with type String 
> {code}
> Furthermore it should be possible to map JCR array types:
> {code}
> @ValueMapObject 
> List links; // would expect a String[] and should put 
> the corresponding Link objects into a list (if the JCR type is String, it 
> should use that one element to fill the list with one Link
> @ValueMapObject 
> com.mycomp.myproj.Link[] links; // arrays should work in the same way
> {code}
> See github patch for a fairly straight-forward implementation the above 
> approach. An alternative approach would be to extend @ValueMapValue (I'm open 
> for both approaches, @ValueMapObject is more explicit in model classes).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-5739) [Sling Models] Allow for extensible @Via providers

[Georg Henzler (JIRA)]

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

Georg Henzler commented on SLING-5739:
--

{quote}
this is actually about injecting a property of the child resource, not the 
child resource itself.
{quote}
This is already possible with 
{code}
@Inject @Named("path/to/resource/jcr:title") @Source("valuemap") // or 
@ValueMapValue
private String titleFromSubResource;
{code}
{quote}
In terms of other `@Via` providers, one more that could make sense is a path 
reference provider.
{quote}
Generally, I think it will almost always be better to create its own model for 
those use cases (flattening into one Pojo on java side what is structured in 
the JCR will not make the code better readable or maintainable). However if 
really needed, this we can already almost achieve today:
{code}
@Inject @Named("otherPath") @Source("resource-path") // or 
@ResourePath(name="otherPath")
private Resource propertyFromSomeOtherResource; // we can get that resource 
today, but not yet only the property "otherProperty"
{code}
But for this I would probably fairly easy to just extend @ResourcePath a bit to 
make the following work:
{code}
@Inject @Named("otherPath") @TargetProperty("otherProperty") 
@Source("resource-path") // or @ResourePath(name="otherPath", 
targetProperty="otherProperty")
private String propertyFromSomeOtherResource;
{code}
It would fairly easy to extend @ResourcePath to lookup the resource's ValueMap 
and use the target property name to lookup the value to inject.

Certainly, this would be more light-weight than introducing another fairly 
complicated ViaProvider SPI.

> [Sling Models] Allow for extensible @Via providers
> --
>
> Key: SLING-5739
> URL: https://issues.apache.org/jira/browse/SLING-5739
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>Reporter: Justin Edelson
>
> Currently, @Via support in Sling Models is limited to JavaBean properties. It 
> would be useful to be able to extend this and allow for downstream projects 
> to add new @Via providers.
> Proposing to support this by extending the @Via annotation
> {code}
> @Via(value = "jcr:content", type = ChildResource.class)
> {code}
> The default type is BeanProperty (the current behavior).
> New providers can be added by implementing a ViaProvider SPI and provide a 
> marker class for use in the annotation.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-5739) [Sling Models] Allow for extensible @Via providers

[Georg Henzler (JIRA)]

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

Georg Henzler commented on SLING-5739:
--

I think the use case from this ticket already works using the "child-resources" 
injector (both for injecting plain resources or the corresponding model):
{code}
@Inject @Source("child-resources") // or @ChildResource
@Named("path/to/resource")
private Resource plainResource;

@Inject  @Source("child-resources") // or @ChildResource
@Named("path/to/resource")
private MyModel resourceAdaptedToMyModel;
{code}
[~justinedelson] Are there other scenarios for @Via providers that would make 
sense? Otherwise this is maybe just introducing unnecessary complexity...

> [Sling Models] Allow for extensible @Via providers
> --
>
> Key: SLING-5739
> URL: https://issues.apache.org/jira/browse/SLING-5739
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>Reporter: Justin Edelson
>
> Currently, @Via support in Sling Models is limited to JavaBean properties. It 
> would be useful to be able to extend this and allow for downstream projects 
> to add new @Via providers.
> Proposing to support this by extending the @Via annotation
> {code}
> @Via(value = "jcr:content", type = ChildResource.class)
> {code}
> The default type is BeanProperty (the current behavior).
> New providers can be added by implementing a ViaProvider SPI and provide a 
> marker class for use in the annotation.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-5721) Extend Sling Models to allow mapping of ValueMap values to custom types

[Georg Henzler (JIRA)]

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

Georg Henzler commented on SLING-5721:
--

[~kwin] As mentioned in the description I'm quite happy to extend 
@ValueMapValue and ValueMapInjector for this (instead of introducing the new 
annotation, also this would not require an API version bump)...  however I 
don't know the code of ValueMapInjector as well as you - it might be safer if 
you merge the code from ValueMapObjectInjector into ValueMapInjector - would 
you have time for it?

> Extend Sling Models to allow mapping of ValueMap values to custom types
> ---
>
> Key: SLING-5721
> URL: https://issues.apache.org/jira/browse/SLING-5721
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>Affects Versions: Sling Models API 1.2.2
>    Reporter: Georg Henzler
>
> At the moment it is already possible to map child resources via 
> @ChildResource to a custom type (that itself only needs to be adaptable from 
> that child resource), but for a plain property it is not yet possible: 
> {code}
> @Inject
> com.mycomp.myproj.Link homePath; // jcr property of type String, does not 
> work currently
> @Inject
> com.mycomp.myproj.EventDate eventDate; // jcr property of type Date, does not 
> work currently
> @Inject
> java.util.Date regularDate; // jcr property of type Date, already works due 
> to standard type conversion available in ValueMap
> {code}
> For custom types, the convention would be that there needs to be a public 
> constructor with one argument with the type of the object as returned by 
> valueMap.get(name). That way a custom type can easily work with situations, 
> where the type of the JCR property is not fixed (e.g. if a property can be of 
> type String or Date, the custom type can just provide both constructors).
> {code}
> @ValueMapObject // opposed to @ValueMapValue
> com.mycomp.myproj.Link homePath; // will call constructor new 
> Link(homePathString) if possible as homePath property exists with type String 
> {code}
> Furthermore it should be possible to map JCR array types:
> {code}
> @ValueMapObject 
> List links; // would expect a String[] and should put 
> the corresponding Link objects into a list (if the JCR type is String, it 
> should use that one element to fill the list with one Link
> @ValueMapObject 
> com.mycomp.myproj.Link[] links; // arrays should work in the same way
> {code}
> See github patch for a fairly straight-forward implementation the above 
> approach. An alternative approach would be to extend @ValueMapValue (I'm open 
> for both approaches, @ValueMapObject is more explicit in model classes).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: svn commit: r1743648 - in /sling: site/trunk/content/documentation/bundles/ trunk/bundles/extensions/models/impl/src/main/java/org/apache/sling/models/impl/injectors/ trunk/bundles/extensions/mode

[Georg Henzler]

It wasn't my intention to trigger this already very polarized discussion 
with SLING-5721, but now that it has started my 50cents:


For me the most important is that I can create models, that behave well 
in request context (for rendering pages) and in async context (jobs, 
workflows etc.), see [1] for an example. Thanks to the now correct order 
of adaptions for request/resource in Sightly (SLING-5031) and the fact 
that @ValueMapValue automatically assumes @Via("resource"), I can 
currently achieve it as long as I don't use @ResourcePath. I believe 
either a) all injectors that somehow operate on a resource should 
automatically assume @Via("resource") if adapted from request 
(@ResourcePath is *not* doing this ATM) or alternatively (and more 
reasonable I believe) AbstractInjector.getValueMap() just does that for 
all injectors (including future ones) automatically.


Using @Via would force me to write two models for [1]. So I would 
suggest reapplying SLING-5726 (and get rid of assuming @Via("resource") 
for @ValueMapValue that is then not needed anymore).


Best Regards
Georg

[1]
@Model(adaptables = { SlingHttpServletRequest.class, Resource.class }, 
defaultInjectionStrategy = DefaultInjectionStrategy.OPTIONAL)

public class ProductModel {

@ValueMapValue
@Named(JcrConstants.JCR_TITLE)
private String productTitle;

@ValueMapValue
@Named(JcrConstants.JCR_DESCRIPTION)
private String productDescription;

@RequestAttribute
private boolean isSale;

public void setIsSale(boolean isSale) {
this.isSale = isSale;
}

// ... code that somehow behaves differently depending on isSale

// For Sightly isSale may be set using Sightly parameters, for async 
usages the setter setIsSale() can be used

// ... but generally the class works fine for both
//  request.adaptTo(ProductModel.class) and 
resource.adaptTo(ProductModel.class)


}


On 2016-05-13 13:39, Konrad Windszus wrote:

I reverted the commit now and reopened
https://issues.apache.org/jira/browse/SLING-5726.

To clarify my point of view:
I think each injector can decide on its own which adaptable to support
natively. Whether or not a specific injector also supports accessing
the value map from the underlying request's resource or not is IMHO a
thing which
a) needs to be documented
b) is mostly driven by the fact how often consumer will try to use the
injector with which adaptable

Regarding the point of consistency I think it would be even better if
all OOTB injectors support SlingHttpRequestServlet! Some injectors may
in addition support other adaptables. That way using those would be
much easier.
I think not every developer remembers the details of each injector, so
it might not be obvious which adaptable is supported. Instead of each
time looking at the documentation, just supporting the minimum (i.e.
SlingHttpServletRequest) seems to be the better choice here. Some
developers do not even care which injector is injecting the value and
where it comes from, but in case something does not work, very often
the problem is, that just the wrong adaptable has been used (which
fails silently and can only be traced down by increasing the log
level, or just by knowing what is wrong).

Having via in addition does not do any harm IMHO, but to be honest I
have not seen the usage of "via" very often in the past and to use
"via" properly you have to know some details on the injector that I
don't want every developer to be aware of.
That was also the reason, why for the annotation "ValueMapValue" the
via element was automatically set to "resource" in case you were
dealing with a SlingHttpServletRequest
(https://github.com/apache/sling/blob/c431b4a0504f79a463593b7509cefb5ba15cda2c/bundles/extensions/models/impl/src/main/java/org/apache/sling/models/impl/injectors/ValueMapInjector.java#L174).

I hope my point is more clear now.
Konrad



On 13 May 2016, at 13:11, Justin Edelson  
wrote:


Hi Konrad,
I think you are missing the point. The current recommended practice 
(to use

@Via) is consistent across injectors. Once you start adding this
functionality to individual injectors, this level of consistency is 
lost.

If @Via isn't well understood, let's fix that problem. But making it
unnecessary in some (but not all) cases just adds confusion.

Please go ahead and revert while you solicit other feedback. I'm 
doubtful
that other feedback will cause me to revoke my veto, but I'm open to 
the

idea.

Regards,
Justin
On Fri, May 13, 2016 at 11:57 AM Konrad Windszus  
wrote:



I know that you can use Via for that purpose, but it is very often
forgotten. And due to the way how injectors are asked this oversight 
is

very hard to debug and trace down.

Just allowing to directly adapt from a request for both injectors, 
makes

using those injectors a lot more comfortable.

The additional complexity I don't really see here, the only real 
change is

in

[jira] [Updated] (SLING-5721) Extend Sling Models to allow mapping of ValueMap values to custom types

[Georg Henzler (JIRA)]

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

Georg Henzler updated SLING-5721:
-
Description: 
At the moment it is already possible to map child resources via @ChildResource 
to a custom type (that itself only needs to be adaptable from that child 
resource), but for a plain property it is not yet possible: 

{code}
@Inject
com.mycomp.myproj.Link homePath; // jcr property of type String, does not work 
currently

@Inject
com.mycomp.myproj.EventDate eventDate; // jcr property of type Date, does not 
work currently

@Inject
java.util.Date regularDate; // jcr property of type Date, already works due to 
standard type conversion available in ValueMap
{code}

For custom types, the convention would be that there needs to be a public 
constructor with one argument with the type of the object as returned by 
valueMap.get(name). That way a custom type can easily work with situations, 
where the type of the JCR property is not fixed (e.g. if a property can be of 
type String or Date, the custom type can just provide both constructors).

{code}
@ValueMapObject // opposed to @ValueMapValue
com.mycomp.myproj.Link homePath; // will call constructor new 
Link(homePathString) if possible as homePath property exists with type String 
{code}

Furthermore it should be possible to map JCR array types:
{code}
@ValueMapObject 
List links; // would expect a String[] and should put 
the corresponding Link objects into a list (if the JCR type is String, it 
should use that one element to fill the list with one Link

@ValueMapObject 
com.mycomp.myproj.Link[] links; // arrays should work in the same way
{code}

See github patch for a fairly straight-forward implementation the above 
approach. An alternative approach would be to extend @ValueMapValue (I'm open 
for both approaches, @ValueMapObject is more explicit in model classes).


  was:
At the moment it is already possible to map child resources via @ChildResource 
to a custom type (that itself only needs to be adaptable from that child 
resource), but for a plain property it is not yet possible: 

{code}
@Inject
com.mycomp.myproj.Link homePath; // jcr property of type String, does not work 
currently

@Inject
com.mycomp.myproj.EventDate eventDate; // jcr property of type Date, does not 
work currently

@Inject
java.util.Date regularDate; // jcr property of type Date, already works due to 
standard type conversion available in ValueMap
{code}

For custom types, the convention would be that there needs to be a public 
constructor with one argument with the type of the object as returned by 
valueMap.get(name). That way a custom type can easily work with situations, 
where the type of the JCR property is not fixed (e.g. if a property can be of 
type String or String[], the custom type can just provide both constructors).

{code}
@ValueMapObject // opposed to @ValueMapValue
com.mycomp.myproj.Link homePath; // will call constructor new 
Link(homePathString) if possible as homePath property exists with type String 
{code}

See github patch for a fairly straight-forward implementation the above 
approach. An alternative approach would be to extend @ValueMapValue (I'm open 
for both approaches, @ValueMapObject is more explicit in model classes).



> Extend Sling Models to allow mapping of ValueMap values to custom types
> ---
>
> Key: SLING-5721
> URL: https://issues.apache.org/jira/browse/SLING-5721
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>Affects Versions: Sling Models API 1.2.2
>    Reporter: Georg Henzler
>
> At the moment it is already possible to map child resources via 
> @ChildResource to a custom type (that itself only needs to be adaptable from 
> that child resource), but for a plain property it is not yet possible: 
> {code}
> @Inject
> com.mycomp.myproj.Link homePath; // jcr property of type String, does not 
> work currently
> @Inject
> com.mycomp.myproj.EventDate eventDate; // jcr property of type Date, does not 
> work currently
> @Inject
> java.util.Date regularDate; // jcr property of type Date, already works due 
> to standard type conversion available in ValueMap
> {code}
> For custom types, the convention would be that there needs to be a public 
> constructor with one argument with the type of the object as returned by 
> valueMap.get(name). That way a custom type can easily work with situations, 
> where the type of the JCR property is not fixed (e.g. if a property can be of 
> type String or Date, the custom type can just provide both constructors).
> {code}
> @ValueMapObject // opposed to @ValueMapValue
> com.mycomp.myproj.Link homePath; // will call constructor new 
>

[jira] [Commented] (SLING-5721) Extend Sling Models to allow mapping of ValueMap values to custom types

[Georg Henzler (JIRA)]

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

Georg Henzler commented on SLING-5721:
--

There are two open questions from my side (also see comments in line 67/72 of 
ValueMapObjectInjector.java):
* Currently the injector only reacts if the annotation @ValueMapObject is 
present (@Inject does not work) - this is in line with what SelfInjector does 
(and probably is a good idea to avoid all the reflection calls on existing 
@Inject usages) 
* AbstractInjector.getValueMap() does not "unfold" a request adaptable to a 
value map (but only a resource) - should this be added in 
AbstractInjector.getValueMap() and the corresponding code removed from 
ValueMapObjectInjector? 

Maybe someone with a good overview of the Sling Models module can help here.

> Extend Sling Models to allow mapping of ValueMap values to custom types
> ---
>
> Key: SLING-5721
> URL: https://issues.apache.org/jira/browse/SLING-5721
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>Affects Versions: Sling Models API 1.2.2
>Reporter: Georg Henzler
>
> At the moment it is already possible to map child resources via 
> @ChildResource to a custom type (that itself only needs to be adaptable from 
> that child resource), but for a plain property it is not yet possible: 
> {code}
> @Inject
> com.mycomp.myproj.Link homePath; // jcr property of type String, does not 
> work currently
> @Inject
> com.mycomp.myproj.EventDate eventDate; // jcr property of type Date, does not 
> work currently
> @Inject
> java.util.Date regularDate; // jcr property of type Date, already works due 
> to standard type conversion available in ValueMap
> {code}
> For custom types, the convention would be that there needs to be a public 
> constructor with one argument with the type of the object as returned by 
> valueMap.get(name). That way a custom type can easily work with situations, 
> where the type of the JCR property is not fixed (e.g. if a property can be of 
> type String or Date, the custom type can just provide both constructors).
> {code}
> @ValueMapObject // opposed to @ValueMapValue
> com.mycomp.myproj.Link homePath; // will call constructor new 
> Link(homePathString) if possible as homePath property exists with type String 
> {code}
> Furthermore it should be possible to map JCR array types:
> {code}
> @ValueMapObject 
> List links; // would expect a String[] and should put 
> the corresponding Link objects into a list (if the JCR type is String, it 
> should use that one element to fill the list with one Link
> @ValueMapObject 
> com.mycomp.myproj.Link[] links; // arrays should work in the same way
> {code}
> See github patch for a fairly straight-forward implementation the above 
> approach. An alternative approach would be to extend @ValueMapValue (I'm open 
> for both approaches, @ValueMapObject is more explicit in model classes).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-5721) Extend Sling Models to allow mapping of ValueMap values to custom types

[Georg Henzler (JIRA)]

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

Georg Henzler commented on SLING-5721:
--

[~kwin] Thanks for your comments in the pull request. I updated the the PR 
accordingly (including a unit test). Also injection of arrays/lists is 
supported now (also included in PR update and Unit Test).

> Extend Sling Models to allow mapping of ValueMap values to custom types
> ---
>
> Key: SLING-5721
> URL: https://issues.apache.org/jira/browse/SLING-5721
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>Affects Versions: Sling Models API 1.2.2
>    Reporter: Georg Henzler
>
> At the moment it is already possible to map child resources via 
> @ChildResource to a custom type (that itself only needs to be adaptable from 
> that child resource), but for a plain property it is not yet possible: 
> {code}
> @Inject
> com.mycomp.myproj.Link homePath; // jcr property of type String, does not 
> work currently
> @Inject
> com.mycomp.myproj.EventDate eventDate; // jcr property of type Date, does not 
> work currently
> @Inject
> java.util.Date regularDate; // jcr property of type Date, already works due 
> to standard type conversion available in ValueMap
> {code}
> For custom types, the convention would be that there needs to be a public 
> constructor with one argument with the type of the object as returned by 
> valueMap.get(name). That way a custom type can easily work with situations, 
> where the type of the JCR property is not fixed (e.g. if a property can be of 
> type String or Date, the custom type can just provide both constructors).
> {code}
> @ValueMapObject // opposed to @ValueMapValue
> com.mycomp.myproj.Link homePath; // will call constructor new 
> Link(homePathString) if possible as homePath property exists with type String 
> {code}
> Furthermore it should be possible to map JCR array types:
> {code}
> @ValueMapObject 
> List links; // would expect a String[] and should put 
> the corresponding Link objects into a list (if the JCR type is String, it 
> should use that one element to fill the list with one Link
> @ValueMapObject 
> com.mycomp.myproj.Link[] links; // arrays should work in the same way
> {code}
> See github patch for a fairly straight-forward implementation the above 
> approach. An alternative approach would be to extend @ValueMapValue (I'm open 
> for both approaches, @ValueMapObject is more explicit in model classes).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (SLING-5721) Extend Sling Models to allow mapping of ValueMap values to custom types

[Georg Henzler (JIRA)]

Georg Henzler created SLING-5721:


 Summary: Extend Sling Models to allow mapping of ValueMap values 
to custom types
 Key: SLING-5721
 URL: https://issues.apache.org/jira/browse/SLING-5721
 Project: Sling
  Issue Type: New Feature
  Components: Extensions
Affects Versions: Sling Models API 1.2.2
Reporter: Georg Henzler


At the moment it is already possible to map child resources via @ChildResource 
to a custom type (that itself only needs to be adaptable from that child 
resource), but for a plain property it is not yet possible: 

{code}
@Inject
com.mycomp.myproj.Link homePath; // jcr property of type String, does not work 
currently

@Inject
com.mycomp.myproj.EventDate eventDate; // jcr property of type Date, does not 
work currently

@Inject
java.util.Date regularDate; // jcr property of type Date, already works due to 
standard type conversion available in ValueMap
{code}

For custom types, the convention would be that there needs to be a public 
constructor with one argument with the type of the object as returned by 
valueMap.get(name). That way a custom type can easily work with situations, 
where the type of the JCR property is not fixed (e.g. if a property can be of 
type String or String[], the custom type can just provide both constructors).

{code}
@ValueMapObject // opposed to @ValueMapValue
com.mycomp.myproj.Link homePath; // will call constructor new 
Link(homePathString) if possible as homePath property exists with type String 
{code}

See github patch for a fairly straight-forward implementation the above 
approach. An alternative approach would be to extend @ValueMapValue (I'm open 
for both approaches, @ValueMapObject is more explicit in model classes).




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [RT] Improve resource type handling

[Georg Henzler]

Hi,

I think it's a good idea to deprecate exotic use cases like defining
both resourceType and resourceSuperType  on a content node. IMHO it is
a bad idea though to create a new location for scripts (e.g.
"/foo/apps"). Having scripts co-located with other artifacts (I don't
call it clutter) in /apps/myapp has never caused a problem in my
projects (they are easy to distinguish after all) - in fact another
aspect is a lot more important: Grouping of project artifacts should
first happen according business requirement/feature (e.g.
/apps/blog/blogpage) and then according technical aspects (scripts,
component descriptors etc. that belong to it). That way the
implementation of a feature is more cohesive, easier to understand and
undesired cross-references between features are easier to spot. In AEM
implementations we already have at least three locations where a
feature "blog page" would contribute: in apps, in /etc/designs and in
the corresponding java package - let's not open another location...

Regards
Georg

> On 19.03.2016, at 14:48, Justin Edelson  wrote:
>
> Hi,
>
> On Sat, Mar 19, 2016 at 6:11 AM Carsten Ziegeler 
> wrote:
>
>> Justin Edelson wrote
>>>
>>> I guess I'm not really understanding the advantage of this flat list
>> (which
>>> wouldn't be a single flat list, but multiple flat lists). What is the the
>>> difference between
>>>
>>> /apps/myco/components/bar
>>> /libs/myco/components/bar
>>>
>>> and
>>>
>>> /foo/apps/myco:components:bar
>>> /foo/libs/myco:components:bar
>> With /foo you have resource type resources only, nothing else, no
>> clutter. It is true, that having /foo/apps and /foo/libs spoils the
>> whole thing and my initial idea was actually to just have
>> /foo/resourcetypehierarchy - no overlays for the resource type
>> hierarchy. But that would go against or overlay principle.
>
> In your mind, does /foo contain scripts inside the resource type resources?
>
>
>>
>> Maybe my idea is not the best, that's why it is an RT :) But I strongly
>> believe that we should move the hierarchy definition out of the /libs,
>> /apps bags of random stuff.
>
>
> I'm still not 100% sure I understand the problem, but it sounds to me like
> the better solution would be to move the random stuff out of /libs and
> /apps :) Unless I'm missing something (which is very possible), nothing
> would stop this same "random stuff" from showing up in /foo/libs and
> /foo/apps.
>
> It sounds like we need something like FHS (
> http://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html). For better or
> worse, however, I think such a document needs to really encompass the scope
> of AEM (and possibly other downstream platforms based on Sling) to be truly
> meaningful.
>
> Regards,
> Justin
>
>
>>
>> Regards
>> Carsten
>> --
>> Carsten Ziegeler
>> Adobe Research Switzerland
>> cziege...@apache.org
>>

Re: [VOTE] release Health Checks Core 1.2.4 and Health Checks Annotations 1.0.4

[Georg Henzler]

+1 (non-binding)

-Georg

On 2016-03-02 15:43, Bertrand Delacretaz wrote:

Hi,

We solved 6 issues in this release:
  https://issues.apache.org/jira/browse/SLING/fixforversion/12332272

Staging repository:
  
https://repository.apache.org/content/repositories/orgapachesling-1437


You can use this UNIX script to download the release and verify the 
signatures:

http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh

Usage:
sh check_staged_release.sh 1437 /tmp/sling-staging

Please vote to approve this release:

  [ ] +1 Approve the release
  [ ]  0 Don't care
  [ ] -1 Don't release, because ...

This majority vote is open for at least 72 hours.

Here's my +1

-Bertrand

[jira] [Commented] (SLING-3100) Provide a m2e project configurator for packaging "content-package"

[Georg Henzler (JIRA)]

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

Georg Henzler commented on SLING-3100:
--

Sounds good to me!

> Provide a m2e project configurator for packaging "content-package"
> --
>
> Key: SLING-3100
> URL: https://issues.apache.org/jira/browse/SLING-3100
> Project: Sling
>  Issue Type: New Feature
>  Components: IDE
>Affects Versions: Sling Eclipse IDE 1.0.0
>Reporter: Konrad Windszus
>Assignee: Robert Munteanu
> Fix For: Sling Eclipse IDE 1.1.0
>
> Attachments: 0001-WIP-do-not-push.patch, 
> SLING-3100-m2e-integration.patch
>
>
> To set up the appropriate project configuration just from the POM an 
> according m2e project configurator is needed 
> (http://wiki.eclipse.org/M2E_plugin_execution_not_covered#delegate_to_a_project_configurator_.28recommended.29)
> The m2e-war-plugin comes with a project configurator which works also for 
> content-packages pretty well but it is currently hard to reuse for any other 
> packaging than "war" (due to the delegate pattern being used internally, 
> compare with https://bugs.eclipse.org/bugs/show_bug.cgi?id=412213). Only if 
> the project is having the dynamic web project facet the following features in 
> Eclipse are supported:
> - JSP include directives (considered for validation and supports ctrl+click 
> to open linked file)
> - Tag Library Support ( 
> http://wiki.eclipse.org/WTP_FAQ#Why_isn.27t_the_JSP_editor.2Fvalidator_finding_my_custom_tag_libraries.3F
>  )
> - probably other features as well.
> Apart from that a feature like overlays should be supported ( 
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=384154 ), as often 
> content-package projects are referencing JSPs from other projects, and the 
> IDE needs to know those, to complete the validation.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Health Check Tickets

[Georg Henzler]

Hi Bertrand,

I created tests for both SLING-5415 and SLING-4941 (see pull requests in 
tickets).


Let me know if you need more, otherwise it would be great if you could 
release both hc.core and hc.annotations.


-Georg

On 2016-02-25 14:22, Bertrand Delacretaz wrote:

Hi,

On Thu, Feb 25, 2016 at 9:50 AM, Konrad Windszus  
wrote:

...I applied both outstanding patches in SLING-5415 and SLING-4417...


I don't see any tests for these patches - considering that this is
about health checks I'm not keen on releasing without having solid
tests.

At least for SLING-5415 - the other one is just an annotation, less
critical I guess.

Do you guys have plans for adding tests?

The same goes for SLING-4941 which was committed a while ago.

-Bertrand

Health Check Tickets

[Georg Henzler]

Hi

apart from some sporadic patches from my side, there has not been much 
activity regarding health checks in the last few months. There are a few 
changes that I would love to see committed and released:


*** Health Check Core ***
Not committed yet:
  https://issues.apache.org/jira/browse/SLING-5415 <-- better timeout 
handling, patch attached

Committed, needs release:
  https://issues.apache.org/jira/browse/SLING-4941 <-- OK/NOK-Check for 
testing purposes
  https://issues.apache.org/jira/browse/SLING-5076 <-- active flag for 
HC servlet


*** Health Check Annotation ***
Not committed yet:
  https://issues.apache.org/jira/browse/SLING-4417 <-- allow to set 
immediate=true on @HealthCheck annotation


It would be great if someone could take care of it!

Regards
Georg

Support for "pattern" property in @SlingFilter annotation

[Georg Henzler]

Hi,

the issue https://issues.apache.org/jira/browse/FELIX-5072 is not part 
of Sling, but it's probably more relevant to ask here: Who could create 
a release for it? (fix version 1.10.0 as set in ticket is not released 
yet).


Best Regards
Georg

Health Check Tickets

[Georg Henzler]

Hi

scattered across the last few months I created a few tickets/patches 
that seem to be a bit lost in "JIRA space" - it would be great to see 
them committed and released:


*** Health Check Core ***
Not committed yet:
  https://issues.apache.org/jira/browse/SLING-5415 <-- better timeout 
handling, patch attached
Committed, needs release (fix version 1.2.4 as set in tickets is not 
actually released):
  https://issues.apache.org/jira/browse/SLING-4941 <-- OK/NOK-Check for 
testing purposes
  https://issues.apache.org/jira/browse/SLING-5076 <-- active flag for 
HC servlet


*** Health Check Annotation ***
Not committed yet:
  https://issues.apache.org/jira/browse/SLING-4417 <-- allow to set 
immediate=true on @HealthCheck annotation


It would be great if someone could take care of it!

Regards
Georg

[jira] [Updated] (SLING-4417) HC Annotation should allow to configure "immediate" SCR property

[Georg Henzler (JIRA)]

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

Georg Henzler updated SLING-4417:
-
Attachment: 
SLING-4417-HC-Annotation-with-immediate-setting-default-false.patch.txt

Attaching patch that uses false as default for "immediate" property of 
@HealthCheck annotation.

> HC Annotation should allow to configure "immediate" SCR property
> 
>
> Key: SLING-4417
> URL: https://issues.apache.org/jira/browse/SLING-4417
> Project: Sling
>  Issue Type: New Feature
>  Components: Health Check
>Reporter: Georg Henzler
> Attachments: 
> SLING-4417-HC-Annotation-with-immediate-setting-default-false.patch.txt, 
> SLING-4417-HC-Annotation-with-immediate-setting.patch
>
>
> When using @SlingHealthCheck at the moment, the "immediate" property is left 
> to "false" in the SCR descriptor which causes the component object to be 
> created on every call of the health check (making it impossible to keep some 
> state in a private member variable if desired). 
> Let's make the immediate property configurable (the same way it would be 
> provided in the @Component annotation) and make immediate="true" the default 
> (this is a slight change in the behaviour that will not break existing code) 
> for the following reasons:
> - It's more intuitive to think of a HC as singleton (and hence be able to 
> keep some instance variables)
> - It's a tiny little bit better from a performance perspective (the instance 
> does not have to be created on each execution)
> The attached patch includes the (fairly simple) change to 
> annotation(-processor) and the change for two sample components that were 
> using @Component because of this issue.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-3100) Provide a m2e project configurator for packaging "content-package"

[Georg Henzler (JIRA)]

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

Georg Henzler commented on SLING-3100:
--

Well, also for me two years have passed - digging in my memory... ;)

{{M2E_ACTIVE}}: I think that one is easy to keep and it is just useful in that 
1 promille of the cases, where you run into strange issues and you want to 
disable it  (maybe incompatibility with some other facet). 
{{M2E_NATURES}}: Can definitely be removed
{{M2E_JCR_ROOT_PATH}}: Inferring it from {{build/resources/resource/directory}} 
sounds good, if there is more than one resource tag, the one containing the 
string "/jcr_root" could be taken. More exotic setups probably shouldn't even 
be supported...
{{M2E_USE_WTP_PROJECT_SETUP}} if I remember it correctly, it was javascript 
validations that didn't work without this - but today (and from my gut feeling) 
I would definitely try without WTP (and trigger other file type validations 
explicitly)
{{M2E_JAVA_FACET_VERSION}} is inferred already in the code  
({{JavaFacetUtil.getCompilerLevel(project)}}) and is there for overriding the 
inferred value only (probably worthwhile to leave it in?) 
{{M2E_WEB_FACET_VERSION}} Inferring would be nice here as well, allowing to 
override gives flexibility if things go wrong.

So in general it sounds all good, great to see that we are making progress here!


> Provide a m2e project configurator for packaging "content-package"
> --
>
> Key: SLING-3100
> URL: https://issues.apache.org/jira/browse/SLING-3100
> Project: Sling
>  Issue Type: New Feature
>  Components: IDE
>Affects Versions: Sling Eclipse IDE 1.0.0
>Reporter: Konrad Windszus
>Assignee: Robert Munteanu
> Fix For: Sling Eclipse IDE 1.1.0
>
> Attachments: 0001-WIP-do-not-push.patch, 
> SLING-3100-m2e-integration.patch
>
>
> To set up the appropriate project configuration just from the POM an 
> according m2e project configurator is needed 
> (http://wiki.eclipse.org/M2E_plugin_execution_not_covered#delegate_to_a_project_configurator_.28recommended.29)
> The m2e-war-plugin comes with a project configurator which works also for 
> content-packages pretty well but it is currently hard to reuse for any other 
> packaging than "war" (due to the delegate pattern being used internally, 
> compare with https://bugs.eclipse.org/bugs/show_bug.cgi?id=412213). Only if 
> the project is having the dynamic web project facet the following features in 
> Eclipse are supported:
> - JSP include directives (considered for validation and supports ctrl+click 
> to open linked file)
> - Tag Library Support ( 
> http://wiki.eclipse.org/WTP_FAQ#Why_isn.27t_the_JSP_editor.2Fvalidator_finding_my_custom_tag_libraries.3F
>  )
> - probably other features as well.
> Apart from that a feature like overlays should be supported ( 
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=384154 ), as often 
> content-package projects are referencing JSPs from other projects, and the 
> IDE needs to know those, to complete the validation.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (SLING-5415) For timed-out health checks, show result of last finished result

[Georg Henzler (JIRA)]

Georg Henzler created SLING-5415:


 Summary: For timed-out health checks, show result of last finished 
result 
 Key: SLING-5415
 URL: https://issues.apache.org/jira/browse/SLING-5415
 Project: Sling
  Issue Type: Improvement
  Components: Health Check
Reporter: Georg Henzler


For the case a HC times out, it would be nice to include the log of the last 
result in the timeout result. That way it gets clearer what the health of the 
actual aspect being checked for is. Also, if the last result was CRITICAL, a 
timeout cannot invalidly "downgrade" an actual CRITICAL system state to WARN.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLING-5415) For timed-out health checks, show result of last finished result

[Georg Henzler (JIRA)]

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

Georg Henzler updated SLING-5415:
-
Attachment: SLING-5415-enrich-timeout-results-with-last-result.patch

Attached patch. It also includes some cosmetic changes to improve the code 
(deleted unused method, better method naming, fixed comments)

> For timed-out health checks, show result of last finished result 
> -
>
> Key: SLING-5415
> URL: https://issues.apache.org/jira/browse/SLING-5415
> Project: Sling
>  Issue Type: Improvement
>  Components: Health Check
>    Reporter: Georg Henzler
> Attachments: SLING-5415-enrich-timeout-results-with-last-result.patch
>
>
> For the case a HC times out, it would be nice to include the log of the last 
> result in the timeout result. That way it gets clearer what the health of the 
> actual aspect being checked for is. Also, if the last result was CRITICAL, a 
> timeout cannot invalidly "downgrade" an actual CRITICAL system state to WARN.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-4294) Servlet Filter Support adding sling.filter.pattern support

[Georg Henzler (JIRA)]

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

Georg Henzler commented on SLING-4294:
--

[~asanso] Created FELIX-5072 in order to support the pattern setting in 
annotation @SlingFilter as well.

> Servlet Filter Support adding sling.filter.pattern support
> --
>
> Key: SLING-4294
> URL: https://issues.apache.org/jira/browse/SLING-4294
> Project: Sling
>  Issue Type: Improvement
>  Components: Engine
>Reporter: Antonio Sanso
>Assignee: Antonio Sanso
> Fix For: Engine 2.4.0
>
> Attachments: SLING-4294-patch.txt
>
>
> the current Sling Servlet Filter Support [0] allows to have scope dependent 
> filter (e.g. REQUEST, INCLUDE, FORWARD, ERROR, COMPONENT).
> It would be nice to extend this support to have a specific filter being taken 
> in consideration only for specific path (adding sling.filter.pattern) a bit 
> like what currently can be done for Apache Felix filters.
> mailing list discussion in [1] 
> [0] http://sling.apache.org/documentation/the-sling-engine/filters.html
> [1] http://markmail.org/message/lzp7qcienk3blwpk



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-4862) Sling Health Checks Servlet

[Georg Henzler (JIRA)]

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

Georg Henzler commented on SLING-4862:
--

Created SLING-5076

> Sling Health Checks Servlet
> ---
>
> Key: SLING-4862
> URL: https://issues.apache.org/jira/browse/SLING-4862
> Project: Sling
>  Issue Type: Improvement
>  Components: Health Check
>Reporter: Bertrand Delacretaz
>Priority: Minor
> Fix For: Health Check Core 1.2.4
>
> Attachments: SLING-4862-HealthCheckExecutorServlet-v2.patch, 
> SLING-4862-HealthCheckExecutorServlet.patch
>
>
> A Servlet that can execute health checks would be useful.
> It can take as input the tags of the HCs to execute, and output their results 
> in JSON format.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (SLING-5076) Allow health check servlet to be disabled

[Georg Henzler (JIRA)]

Georg Henzler created SLING-5076:


 Summary: Allow health check servlet to be disabled
 Key: SLING-5076
 URL: https://issues.apache.org/jira/browse/SLING-5076
 Project: Sling
  Issue Type: Improvement
  Components: Health Check
Reporter: Georg Henzler
 Fix For: Health Check Core 1.2.4


This is an extension to SLING-4862 (that I cannot reopen).
Even though the default registration path of the /system/console is secure by 
default to a certain extent it would be good to have the option to disable the 
servlet (just to be safe in case a security policy of a deployment requires 
this). By default the servlet should remain active.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLING-5076) Allow health check servlet to be disabled

[Georg Henzler (JIRA)]

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

Georg Henzler updated SLING-5076:
-
Attachment: SLING-5076-allow-disable.patch

The patch introduces the configuration property "disabled" (false by default). 
Also it allows to pass the tags in the path (to be consistent with format that 
can be passed as part of the path as well)

> Allow health check servlet to be disabled
> -
>
> Key: SLING-5076
> URL: https://issues.apache.org/jira/browse/SLING-5076
> Project: Sling
>  Issue Type: Improvement
>  Components: Health Check
>Reporter: Georg Henzler
> Fix For: Health Check Core 1.2.4
>
> Attachments: SLING-5076-allow-disable.patch
>
>
> This is an extension to SLING-4862 (that I cannot reopen).
> Even though the default registration path of the /system/console is secure by 
> default to a certain extent it would be good to have the option to disable 
> the servlet (just to be safe in case a security policy of a deployment 
> requires this). By default the servlet should remain active.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLING-5076) Allow health check servlet to be disabled

[Georg Henzler (JIRA)]

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

Georg Henzler updated SLING-5076:
-
Flags: Patch

> Allow health check servlet to be disabled
> -
>
> Key: SLING-5076
> URL: https://issues.apache.org/jira/browse/SLING-5076
> Project: Sling
>  Issue Type: Improvement
>  Components: Health Check
>    Reporter: Georg Henzler
> Fix For: Health Check Core 1.2.4
>
> Attachments: SLING-5076-allow-disable.patch
>
>
> This is an extension to SLING-4862 (that I cannot reopen).
> Even though the default registration path of the /system/console is secure by 
> default to a certain extent it would be good to have the option to disable 
> the servlet (just to be safe in case a security policy of a deployment 
> requires this). By default the servlet should remain active.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLING-5076) Allow health check servlet to be disabled

[Georg Henzler (JIRA)]

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

Georg Henzler updated SLING-5076:
-
Description: 
This is an extension to SLING-4862 (that I cannot reopen).
Even though the default registration path of the /system/health is secure by 
default to a certain extent it would be good to have the option to disable the 
servlet (just to be safe in case a security policy of a deployment requires 
this). By default the servlet should remain active.

  was:
This is an extension to SLING-4862 (that I cannot reopen).
Even though the default registration path of the /system/console is secure by 
default to a certain extent it would be good to have the option to disable the 
servlet (just to be safe in case a security policy of a deployment requires 
this). By default the servlet should remain active.


> Allow health check servlet to be disabled
> -
>
> Key: SLING-5076
> URL: https://issues.apache.org/jira/browse/SLING-5076
> Project: Sling
>  Issue Type: Improvement
>  Components: Health Check
>    Reporter: Georg Henzler
> Fix For: Health Check Core 1.2.4
>
> Attachments: SLING-5076-allow-disable.patch
>
>
> This is an extension to SLING-4862 (that I cannot reopen).
> Even though the default registration path of the /system/health is secure by 
> default to a certain extent it would be good to have the option to disable 
> the servlet (just to be safe in case a security policy of a deployment 
> requires this). By default the servlet should remain active.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (SLING-5049) Scheduled tasks should set a meaningful thread name during execution

[Georg Henzler (JIRA)]

Georg Henzler created SLING-5049:


 Summary: Scheduled tasks should set a meaningful thread name 
during execution
 Key: SLING-5049
 URL: https://issues.apache.org/jira/browse/SLING-5049
 Project: Sling
  Issue Type: Improvement
Affects Versions: Commons Scheduler 2.4.10
Reporter: Georg Henzler


It would be useful for log file analysis purposes to set a meaningful thread 
name during the execution of scheduled tasks 
(https://sling.apache.org/documentation/bundles/scheduler-service-commons-scheduler.html).
 Both Sling requests and jobs do this already: Requests set Method + URL, Jobs 
set the name to pool id + queue name + topic. For scheduled tasks I would 
propose to reuse "QuartzJobScheduler.JobName" that is already used internally 
(and is derived by OSGi service property "scheduler.name"). This can fairly 
easily be achieved by a few lines of code in QuartzJobExecutor, see attached 
patch.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLING-5049) Scheduled tasks should set a meaningful thread name during execution

[Georg Henzler (JIRA)]

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

Georg Henzler updated SLING-5049:
-
Attachment: SLING-5049-set-thread-name-for-scheduled-tasks.patch

> Scheduled tasks should set a meaningful thread name during execution
> 
>
> Key: SLING-5049
> URL: https://issues.apache.org/jira/browse/SLING-5049
> Project: Sling
>  Issue Type: Improvement
>Affects Versions: Commons Scheduler 2.4.10
>    Reporter: Georg Henzler
> Attachments: SLING-5049-set-thread-name-for-scheduled-tasks.patch
>
>
> It would be useful for log file analysis purposes to set a meaningful thread 
> name during the execution of scheduled tasks 
> (https://sling.apache.org/documentation/bundles/scheduler-service-commons-scheduler.html).
>  Both Sling requests and jobs do this already: Requests set Method + URL, 
> Jobs set the name to pool id + queue name + topic. For scheduled tasks I 
> would propose to reuse "QuartzJobScheduler.JobName" that is already used 
> internally (and is derived by OSGi service property "scheduler.name"). This 
> can fairly easily be achieved by a few lines of code in QuartzJobExecutor, 
> see attached patch.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLING-4941) JMX-configurable OK/NOK-Check for testing purposes

[Georg Henzler (JIRA)]

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

Georg Henzler updated SLING-4941:
-
Attachment: JMX-adjustable-HC-for-testing.png

[~npeltier] See attached screenshot on how this patch would allow you to 
dynamically add a WARN/CRITICAL health check result for given tags. reset() 
removes the test check again. Would this fulfil your requirement?

 JMX-configurable OK/NOK-Check for testing purposes
 --

 Key: SLING-4941
 URL: https://issues.apache.org/jira/browse/SLING-4941
 Project: Sling
  Issue Type: New Feature
  Components: Health Check
Reporter: Georg Henzler
 Attachments: JMX-adjustable-HC-for-testing.png, 
 SLING-4941-JMX-adjustable-HC.patch


 For testing purposes (infrastructure tests with load balancers etc.) it can 
 be useful to make the result for a given tag(s) fail manually. 
 There are two options:
 # provide a check that is configurable via JCR (using metatype 
 configuration). 
 # provide a check that can be dynamically added via JMX
 The second options is IMHO nicer, because it's easier to run a JMX operation 
 (compared to adding/changing a configuration in JCR). Also if this feature is 
 not being used, it should not clutter the list of available health checks.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-4862) Sling Health Checks Servlet

[Georg Henzler (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-4862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14694800#comment-14694800
 ] 

Georg Henzler commented on SLING-4862:
--

[~bdelacretaz] Looks all good to me, I like the minimal text rendering that can 
be quite useful in shell scripts.

Maybe the following two descriptions in the parameter documentation could be 
improved:
- forceInstantExecution: Forces instant execution by executing async checks 
directly and circumventing the cache (2sec by default) of the health check 
executor
- timeout: Timeout in ms - a timeout status is returned for any check still 
running after this period (this overrides the default timeout of the health 
check executor)


 Sling Health Checks Servlet
 ---

 Key: SLING-4862
 URL: https://issues.apache.org/jira/browse/SLING-4862
 Project: Sling
  Issue Type: Improvement
  Components: Health Check
Reporter: Bertrand Delacretaz
Priority: Minor
 Fix For: Health Check Core 1.2.4

 Attachments: SLING-4862-HealthCheckExecutorServlet-v2.patch, 
 SLING-4862-HealthCheckExecutorServlet.patch


 A Servlet that can execute health checks would be useful.
 It can take as input the tags of the HCs to execute, and output their results 
 in JSON format.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLING-4862) Sling Health Checks Servlet

[Georg Henzler (JIRA)]

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

Georg Henzler updated SLING-4862:
-
Attachment: SLING-4862-HealthCheckExecutorServlet-v2.patch

 Sling Health Checks Servlet
 ---

 Key: SLING-4862
 URL: https://issues.apache.org/jira/browse/SLING-4862
 Project: Sling
  Issue Type: Improvement
  Components: Health Check
Reporter: Bertrand Delacretaz
Priority: Minor
 Attachments: SLING-4862-HealthCheckExecutorServlet-v2.patch, 
 SLING-4862-HealthCheckExecutorServlet.patch


 A Servlet that can execute health checks would be useful.
 It can take as input the tags of the HCs to execute, and output their results 
 in JSON format.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-4862) Sling Health Checks Servlet

[Georg Henzler (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-4862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14682429#comment-14682429
 ] 

Georg Henzler commented on SLING-4862:
--

Thanks for your comments [~bdelacretaz], updated the patch as follows:
- Output is encoded using org.apache.commons.lang.StringEscapeUtils (commons 
lang is already a dependency)
- format can be given as extension, but a helper segment has to be given in 
path: /system/health/result.json or just /system/health/.json. Unfortunately 
/system/health.json does not work as there has to be at least one slash after 
the base path that is registered using httpService.registerServlet()
- removed modified method
- using css class status + status.name() now
- changed method service to doGet (you are right, other methods do not make 
sense)
- status mapping can be configured ala 
httpStatus=CRITICAL:503,HEALTH_CHECK_ERROR:500
- added a unit test for the servlet (this required to add an equals() to 
HealthCheckExecutionOptions)



 Sling Health Checks Servlet
 ---

 Key: SLING-4862
 URL: https://issues.apache.org/jira/browse/SLING-4862
 Project: Sling
  Issue Type: Improvement
  Components: Health Check
Reporter: Bertrand Delacretaz
Priority: Minor
 Attachments: SLING-4862-HealthCheckExecutorServlet.patch


 A Servlet that can execute health checks would be useful.
 It can take as input the tags of the HCs to execute, and output their results 
 in JSON format.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLING-4862) Sling Health Checks Servlet

[Georg Henzler (JIRA)]

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

Georg Henzler updated SLING-4862:
-
Attachment: SLING-4862-HealthCheckExecutorServlet.patch

Attached a patch for a servlet that lives at /sling/health. The following 
request parameters can be used:

- tags: The health check tags to take into account (comma-separated list)
- format: html|json|jsonpbr/
- includeDebug: If true, debug messages from result log are included
- callback: For jsonp, the JS callback function name (defaults to 
processHealthCheckResults)
- onCriticalHttp503: Will send Http code 503 Service Unavailable if overall 
status is critical (useful in combination with load balancers)


 Sling Health Checks Servlet
 ---

 Key: SLING-4862
 URL: https://issues.apache.org/jira/browse/SLING-4862
 Project: Sling
  Issue Type: Improvement
  Components: Health Check
Reporter: Bertrand Delacretaz
Priority: Minor
 Attachments: SLING-4862-HealthCheckExecutorServlet.patch


 A Servlet that can execute health checks would be useful.
 It can take as input the tags of the HCs to execute, and output their results 
 in JSON format.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLING-4941) JMX-configurable OK/NOK-Check for testing purposes

[Georg Henzler (JIRA)]

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

Georg Henzler updated SLING-4941:
-
Flags: Patch

 JMX-configurable OK/NOK-Check for testing purposes
 --

 Key: SLING-4941
 URL: https://issues.apache.org/jira/browse/SLING-4941
 Project: Sling
  Issue Type: New Feature
  Components: Health Check
Reporter: Georg Henzler
 Attachments: SLING-4941-JMX-adjustable-HC.patch


 For testing purposes (infrastructure tests with load balancers etc.) it can 
 be useful to make the result for a given tag(s) fail manually. 
 There are two options:
 # provide a check that is configurable via JCR (using metatype 
 configuration). 
 # provide a check that can be dynamically added via JMX
 The second options is IMHO nicer, because it's easier to run a JMX operation 
 (compared to adding/changing a configuration in JCR). Also if this feature is 
 not being used, it should not clutter the list of available health checks.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLING-4941) JMX-configurable OK/NOK-Check for testing purposes

[Georg Henzler (JIRA)]

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

Georg Henzler updated SLING-4941:
-
Attachment: SLING-4941-JMX-adjustable-HC.patch

Attached patch for option 2.

 JMX-configurable OK/NOK-Check for testing purposes
 --

 Key: SLING-4941
 URL: https://issues.apache.org/jira/browse/SLING-4941
 Project: Sling
  Issue Type: New Feature
  Components: Health Check
Reporter: Georg Henzler
 Attachments: SLING-4941-JMX-adjustable-HC.patch


 For testing purposes (infrastructure tests with load balancers etc.) it can 
 be useful to make the result for a given tag(s) fail manually. 
 There are two options:
 # provide a check that is configurable via JCR (using metatype 
 configuration). 
 # provide a check that can be dynamically added via JMX
 The second options is IMHO nicer, because it's easier to run a JMX operation 
 (compared to adding/changing a configuration in JCR). Also if this feature is 
 not being used, it should not clutter the list of available health checks.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-4862) Sling Health Checks Servlet

[Georg Henzler (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-4862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14680231#comment-14680231
 ] 

Georg Henzler commented on SLING-4862:
--

[~npeltier] [~bdelacretaz] Created SLING-4941 for the configurable HC and 
attached another patch.

 Sling Health Checks Servlet
 ---

 Key: SLING-4862
 URL: https://issues.apache.org/jira/browse/SLING-4862
 Project: Sling
  Issue Type: Improvement
  Components: Health Check
Reporter: Bertrand Delacretaz
Priority: Minor
 Attachments: SLING-4862-HealthCheckExecutorServlet.patch


 A Servlet that can execute health checks would be useful.
 It can take as input the tags of the HCs to execute, and output their results 
 in JSON format.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (SLING-4941) JMX-configurable OK/NOK-Check for testing purposes

[Georg Henzler (JIRA)]

Georg Henzler created SLING-4941:


 Summary: JMX-configurable OK/NOK-Check for testing purposes
 Key: SLING-4941
 URL: https://issues.apache.org/jira/browse/SLING-4941
 Project: Sling
  Issue Type: New Feature
Reporter: Georg Henzler


For testing purposes (infrastructure tests with load balancers etc.) it can be 
useful to make the result for a given tag(s) fail manually. 

There are two options:
# provide a check that is configurable via JCR (using metatype configuration). 
# provide a check that can be dynamically added via JMX

The second options is IMHO nicer, because it's easier to run a JMX operation 
(compared to adding/changing a configuration in JCR). Also if this feature is 
not being used, it should not clutter the list of available health checks.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)