[jira] [Commented] (SLING-5965) Metrics and a Health-Check for Scheduler to detect long-running Quartz-Jobs

[Stefan Egli (JIRA)]

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

Stefan Egli commented on SLING-5965:


+1

> Metrics and a Health-Check for Scheduler to detect long-running Quartz-Jobs
> ---
>
> Key: SLING-5965
> URL: https://issues.apache.org/jira/browse/SLING-5965
> Project: Sling
>  Issue Type: New Feature
>  Components: Commons
>Affects Versions: Commons Scheduler 2.5.0
>Reporter: Stefan Egli
>Assignee: Stefan Egli
> Fix For: Commons Scheduler 2.6.4
>
> Attachments: numRunningJobs.jpg, oldestRunningJob.jpg, patch.txt, 
> SchedulerHealthCheck.jpg, SLING-5965.patch, SLING-5965.v2.patch.txt, 
> SLING-5965.v3.patch.txt, SLING-5965.v4.patch.txt, SLING-5965.v5.patch.txt, 
> timers.jpg
>
>
> Sling Scheduler jobs (aka Quartz-Jobs) should typically be fast running jobs. 
> They are served from a thread-pool and should occupy that thread only for a 
> short amount of time.
> If there are 'misbehaving' quartz-jobs that run for a very long time, they 
> start to occupy threads from that thread-pool, thus have an influence on the 
> performance of other scheduled/quartz-jobs.
> We should have metrics (using 
> [sling.commons.metrics|https://sling.apache.org/documentation/bundles/metrics.html])
>  that provide information about internas of Sling Scheduler, such as average, 
> max etc duration of scheduled jobs, as well as how many jobs are currently 
> running and since when was the oldest job running.
> Based on this, a Health-Check can monitor the 'oldest job running' metric and 
> flag {{critical}} when eg the oldest job is older than {{60'000ms}} 
> (configurable, default).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: [VOTE] Release Apache Sling Scripting JSP 2.3.2

[Daniel Klco]

+1

On Mon, Aug 21, 2017 at 7:01 AM, Stefan Egli  wrote:

> +1
>
> Cheers,
> Stefan
>
> On 21/08/17 11:47, "Carsten Ziegeler"  wrote:
>
> >Hi,
> >
> >We solved 1 issues in this release:
> >https://issues.apache.org/jira/browse/SLING/fixforversion/12340247
> >
> >
> >Staging repository:
> >https://repository.apache.org/content/repositories/orgapachesling-1770/
> >
> >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 1770 /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.
> >
> >Regards
> >Carsten
> >--
> >Carsten Ziegeler
> >Adobe Research Switzerland
> >cziege...@apache.org
>
>
>

[jira] [Created] (SLING-7069) CompositeHealthcheck combines subchecks with AND

[JIRA]

Jörg Hoh created SLING-7069:
---

 Summary: CompositeHealthcheck combines subchecks with AND
 Key: SLING-7069
 URL: https://issues.apache.org/jira/browse/SLING-7069
 Project: Sling
  Issue Type: Bug
  Components: Health Check
Affects Versions: Health Check Core 1.2.8
Reporter: Jörg Hoh


I have a CompositeHealthcheck like this

{code}
http://sling.apache.org/jcr/sling/1.0; 
xmlns:cq="http://www.day.com/jcr/cq/1.0; xmlns:jcr="http://www.jcp.org/jcr/1.0; 
xmlns:nt="http://www.jcp.org/jcr/nt/1.0;
jcr:primaryType="sling:OsgiConfig"
hc.name="Health Checks (Runtime)"
hc.mbean.name="runtime-monitoring"
filter.tags="[tag1,tag2,tag3]"
hc.tags="[runtime-monitoring]"
hc.async.cronExpression="50 0/1 * 1/1 * ? *"/>
{code}
whenever I run a healthcheck on the tag "runtime-monitoring" the healthchecks 
tagged with "tag1", "tag2" and "tage3" should be executed.
But whenever I run the healthceck on "runtime-monitoring", noone is executed at 
all.

I tracked it down to the fact, that only these healthchecks are executed which 
have all tags (tag1,tag2 and tag3) configured. Which of course none of my tags 
are.

{code}
21.08.2017 17:06:00.502 *DEBUG* [HealthCheck Health Checks (Runtime)] 
org.apache.sling.hc.util.HealthCheckFilter OSGi service filter in 
getTaggedHealthCheckServiceReferences(): 
(&(objectClass=org.apache.sling.hc.api.HealthCheck)(hc.tags=tag1)(hc.tags=tag2)(hc.tags=tag3))
{code}

It seems to me that instead of the AND it should be an OR.





--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: [VOTE] Release Apache Sling Provisioning Model 1.8.4

[Justin Edelson]

+1 (with the same comment as Robert)

On Fri, Aug 18, 2017 at 7:28 AM Carsten Ziegeler 
wrote:

> +1
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org
>

[jira] [Commented] (SLING-5965) Metrics and a Health-Check for Scheduler to detect long-running Quartz-Jobs

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-5965:
-

[~egli] How about we go with solution a) for now? If there is a decision later 
on to do a MetricRegistry equivalent we can still switch with another release.

> Metrics and a Health-Check for Scheduler to detect long-running Quartz-Jobs
> ---
>
> Key: SLING-5965
> URL: https://issues.apache.org/jira/browse/SLING-5965
> Project: Sling
>  Issue Type: New Feature
>  Components: Commons
>Affects Versions: Commons Scheduler 2.5.0
>Reporter: Stefan Egli
>Assignee: Stefan Egli
> Fix For: Commons Scheduler 2.6.4
>
> Attachments: numRunningJobs.jpg, oldestRunningJob.jpg, patch.txt, 
> SchedulerHealthCheck.jpg, SLING-5965.patch, SLING-5965.v2.patch.txt, 
> SLING-5965.v3.patch.txt, SLING-5965.v4.patch.txt, SLING-5965.v5.patch.txt, 
> timers.jpg
>
>
> Sling Scheduler jobs (aka Quartz-Jobs) should typically be fast running jobs. 
> They are served from a thread-pool and should occupy that thread only for a 
> short amount of time.
> If there are 'misbehaving' quartz-jobs that run for a very long time, they 
> start to occupy threads from that thread-pool, thus have an influence on the 
> performance of other scheduled/quartz-jobs.
> We should have metrics (using 
> [sling.commons.metrics|https://sling.apache.org/documentation/bundles/metrics.html])
>  that provide information about internas of Sling Scheduler, such as average, 
> max etc duration of scheduled jobs, as well as how many jobs are currently 
> running and since when was the oldest job running.
> Based on this, a Health-Check can monitor the 'oldest job running' metric and 
> flag {{critical}} when eg the oldest job is older than {{60'000ms}} 
> (configurable, default).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (SLING-7037) Scheduler does not retain provided name

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler resolved SLING-7037.
-
Resolution: Fixed

> Scheduler does not retain provided name
> ---
>
> Key: SLING-7037
> URL: https://issues.apache.org/jira/browse/SLING-7037
> Project: Sling
>  Issue Type: Bug
>  Components: Commons
>Affects Versions: Commons Scheduler 2.6.0
>Reporter: Marcel Reutegger
>Assignee: Carsten Ziegeler
>Priority: Minor
> Fix For: Commons Scheduler 2.6.4
>
> Attachments: SLING-7037-test.patch
>
>
> The scheduler does not retain the provided name for the job as introduced in 
> SLING-5387.
> The value returned by the JobDataMap is a generated name that include the 
> service id.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (SLING-7066) Support mixins in repoinit "create path" statements

[Timothee Maret (JIRA)]

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

Timothee Maret commented on SLING-7066:
---

Thanks [~bdelacretaz]! Fine with me, this way we could still add default mixin 
later if it becomes a strong requirement. 

> Support mixins in repoinit "create path" statements
> ---
>
> Key: SLING-7066
> URL: https://issues.apache.org/jira/browse/SLING-7066
> Project: Sling
>  Issue Type: New Feature
>  Components: Repoinit
>Reporter: Bertrand Delacretaz
>Assignee: Timothee Maret
>Priority: Minor
>
> The repoinit "create path" statement currently supports nodetypes but no 
> mixins, we should add support for them.
> The current create path syntax is like
> {code}
> create path (sling:Folder) /var/discovery(nt:unstructured)/somefolder
> create path /one/two/three
> create path /three/four(nt:folk)/five(nt:jazz)/six
> {code}
> Where the first bracketed statement, before the path, is the default nodetype 
> for all subpaths, and each subpath can have a specific nodetype.
> To add mixin support I suggest the syntax of these examples for these 
> bracketed statements:
> {code}
> (sling:Folder mixin mix:A, mix:B)
> (nt:unstructured mixin mix:C)
> (mixin mix:A)
> (mixin mix:A, mix:B)
> {code}
> The last two forms without a nodeteype meaning "set mixins only but keep the 
> default nodetype", which in this example
> {code}
> create path (sling:Folder) /var/foo(mixin mix:B)
> {code}
> means /var/foo is of type sling:Folder with mixin mix:B
> whereas in this example
> {code}
> create /var/bar(mixin mix:C)
> {code}
> /var/bar uses the default type defined by /var's type, with mix:C added.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (SLING-7068) Upgrade to Oak 1.6.4

[Robert Munteanu (JIRA)]

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

Robert Munteanu resolved SLING-7068.

Resolution: Fixed

Fixed in [r1805626|https://svn.apache.org/r1805626]

> Upgrade to Oak 1.6.4
> 
>
> Key: SLING-7068
> URL: https://issues.apache.org/jira/browse/SLING-7068
> Project: Sling
>  Issue Type: Improvement
>  Components: Launchpad
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>  Labels: Sling-10-ReleaseNotes
> Fix For: Launchpad Builder 10
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (SLING-7066) Support mixins in repoinit "create path" statements

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz commented on SLING-7066:


Maybe it's better to disallow mixins in the bracketed statement that defines 
defaults?

So this would be invalid for example:

{code}
create path (sling:Folder mixin mix:A) /var/foo
{code}

And a valid statement would be 
{code}
create path (sling:Folder) /var/foo(mixin mix:A)
{code}

I don't think setting the same mixin on each level of a path is a common use 
case, and if that's really needed that remains possible.

WDYT?


> Support mixins in repoinit "create path" statements
> ---
>
> Key: SLING-7066
> URL: https://issues.apache.org/jira/browse/SLING-7066
> Project: Sling
>  Issue Type: New Feature
>  Components: Repoinit
>Reporter: Bertrand Delacretaz
>Assignee: Timothee Maret
>Priority: Minor
>
> The repoinit "create path" statement currently supports nodetypes but no 
> mixins, we should add support for them.
> The current create path syntax is like
> {code}
> create path (sling:Folder) /var/discovery(nt:unstructured)/somefolder
> create path /one/two/three
> create path /three/four(nt:folk)/five(nt:jazz)/six
> {code}
> Where the first bracketed statement, before the path, is the default nodetype 
> for all subpaths, and each subpath can have a specific nodetype.
> To add mixin support I suggest the syntax of these examples for these 
> bracketed statements:
> {code}
> (sling:Folder mixin mix:A, mix:B)
> (nt:unstructured mixin mix:C)
> (mixin mix:A)
> (mixin mix:A, mix:B)
> {code}
> The last two forms without a nodeteype meaning "set mixins only but keep the 
> default nodetype", which in this example
> {code}
> create path (sling:Folder) /var/foo(mixin mix:B)
> {code}
> means /var/foo is of type sling:Folder with mixin mix:B
> whereas in this example
> {code}
> create /var/bar(mixin mix:C)
> {code}
> /var/bar uses the default type defined by /var's type, with mix:C added.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (SLING-7068) Upgrade to Oak 1.6.4

[Robert Munteanu (JIRA)]

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

Robert Munteanu updated SLING-7068:
---
Labels: Sling-10-ReleaseNotes  (was: )

> Upgrade to Oak 1.6.4
> 
>
> Key: SLING-7068
> URL: https://issues.apache.org/jira/browse/SLING-7068
> Project: Sling
>  Issue Type: Improvement
>  Components: Launchpad
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>  Labels: Sling-10-ReleaseNotes
> Fix For: Launchpad Builder 10
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (SLING-7066) Support mixins in repoinit "create path" statements

[Timothee Maret (JIRA)]

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

Timothee Maret commented on SLING-7066:
---

[~bdelacretaz] Thanks for the spec. I think that one behaviour needs to be 
clarified.
How are mixins merged between the default mixins and those specific to a given 
path element ?

I think we could either

1. Merge the two sets of mixins ; or
2. Use the most specific set of mixins (path specific > default > empty)

wdyt ?

> Support mixins in repoinit "create path" statements
> ---
>
> Key: SLING-7066
> URL: https://issues.apache.org/jira/browse/SLING-7066
> Project: Sling
>  Issue Type: New Feature
>  Components: Repoinit
>Reporter: Bertrand Delacretaz
>Assignee: Timothee Maret
>Priority: Minor
>
> The repoinit "create path" statement currently supports nodetypes but no 
> mixins, we should add support for them.
> The current create path syntax is like
> {code}
> create path (sling:Folder) /var/discovery(nt:unstructured)/somefolder
> create path /one/two/three
> create path /three/four(nt:folk)/five(nt:jazz)/six
> {code}
> Where the first bracketed statement, before the path, is the default nodetype 
> for all subpaths, and each subpath can have a specific nodetype.
> To add mixin support I suggest the syntax of these examples for these 
> bracketed statements:
> {code}
> (sling:Folder mixin mix:A, mix:B)
> (nt:unstructured mixin mix:C)
> (mixin mix:A)
> (mixin mix:A, mix:B)
> {code}
> The last two forms without a nodeteype meaning "set mixins only but keep the 
> default nodetype", which in this example
> {code}
> create path (sling:Folder) /var/foo(mixin mix:B)
> {code}
> means /var/foo is of type sling:Folder with mixin mix:B
> whereas in this example
> {code}
> create /var/bar(mixin mix:C)
> {code}
> /var/bar uses the default type defined by /var's type, with mix:C added.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (SLING-7068) Upgrade to Oak 1.6.4

[Robert Munteanu (JIRA)]

Robert Munteanu created SLING-7068:
--

 Summary: Upgrade to Oak 1.6.4
 Key: SLING-7068
 URL: https://issues.apache.org/jira/browse/SLING-7068
 Project: Sling
  Issue Type: Improvement
  Components: Launchpad
Reporter: Robert Munteanu
Assignee: Robert Munteanu
 Fix For: Launchpad Builder 10






--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (SLING-7067) TagFileTest fails with launchpad.testing-war only

[Robert Munteanu (JIRA)]

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

Robert Munteanu resolved SLING-7067.

Resolution: Fixed

Fixed in [r1805625|https://svn.apache.org/r1805625]

> TagFileTest fails with launchpad.testing-war only
> -
>
> Key: SLING-7067
> URL: https://issues.apache.org/jira/browse/SLING-7067
> Project: Sling
>  Issue Type: Bug
>  Components: Launchpad
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
> Fix For: Launchpad Testing 9
>
>
> {noformat}testTagFileDeployedInBundle(org.apache.sling.launchpad.webapp.jsp.TagFileTest)
>   Time elapsed: 0.031 sec  <<< ERROR!
> java.lang.NoSuchMethodError: 
> org.osgi.framework.Version.compareTo(Lorg/osgi/framework/Version;)I
>   at 
> org.apache.sling.commons.testing.integration.HttpTestBase.isBundleVersionAtLeast(HttpTestBase.java:601)
>   at 
> org.apache.sling.launchpad.webapp.jsp.TagFileTest.testTagFileDeployedInBundle(TagFileTest.java:42){noformat}
> It seems that applying the same fix as for launchpad.testing does not work.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (SLING-7067) TagFileTest fails with launchpad.testing-war only

[Robert Munteanu (JIRA)]

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

Robert Munteanu updated SLING-7067:
---
Priority: Minor  (was: Major)

> TagFileTest fails with launchpad.testing-war only
> -
>
> Key: SLING-7067
> URL: https://issues.apache.org/jira/browse/SLING-7067
> Project: Sling
>  Issue Type: Bug
>  Components: Launchpad
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Minor
> Fix For: Launchpad Testing 9
>
>
> {noformat}testTagFileDeployedInBundle(org.apache.sling.launchpad.webapp.jsp.TagFileTest)
>   Time elapsed: 0.031 sec  <<< ERROR!
> java.lang.NoSuchMethodError: 
> org.osgi.framework.Version.compareTo(Lorg/osgi/framework/Version;)I
>   at 
> org.apache.sling.commons.testing.integration.HttpTestBase.isBundleVersionAtLeast(HttpTestBase.java:601)
>   at 
> org.apache.sling.launchpad.webapp.jsp.TagFileTest.testTagFileDeployedInBundle(TagFileTest.java:42){noformat}
> It seems that applying the same fix as for launchpad.testing does not work.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: Restricting sling health checks

[Oliver Lietz]

On Monday 21 August 2017 15:06:19 Robert Munteanu wrote:
> Hi Andrei,
> 
> On Mon, 2017-08-21 at 11:55 +, Andrei Kalfas wrote:
> > Hi,
> > 
> > Well, as far as I can tell, out of the box that URL can be called
> > from anywhere. Thing is that I don’t quite care what would be the
> > means to restrict access to the health check url as long as I don’t
> > have to configure proxies.
> 
> I don't think you have something like that in Sling.

You can use Sling URL Rewriter (contrib/extensions/urlrewriter) to deny access 
to those URLs.

Regards,
O.

> It's a good idea to restrict access to the whole /system when running
> Sling apps. In the AEM world you would use the dispatcher. In the Sling
> world, ... well anything else than the dispatcher :-)
> 
> Hope this helps,
> 
> Robert

Re: Restricting sling health checks

[Bertrand Delacretaz]

On Mon, Aug 21, 2017 at 2:06 PM, Robert Munteanu  wrote:
>>..I don’t quite care what would be the
>> means to restrict access to the health check url as long as I don’t
>> have to configure proxies

If you really want to restrict access with Sling itself, I suppose you
could implement your own Filter.

-Bertrand

Re: Restricting sling health checks

[Andrei Kalfas]

Thank you !
Andrei

> On Aug 21, 2017, at 3:06 PM, Robert Munteanu  wrote:
> 
> Hi Andrei,
> 
> On Mon, 2017-08-21 at 11:55 +, Andrei Kalfas wrote:
>> Hi,
>> 
>> Well, as far as I can tell, out of the box that URL can be called
>> from anywhere. Thing is that I don’t quite care what would be the
>> means to restrict access to the health check url as long as I don’t
>> have to configure proxies. 
> 
> 
> I don't think you have something like that in Sling.
> 
> It's a good idea to restrict access to the whole /system when running
> Sling apps. In the AEM world you would use the dispatcher. In the Sling
> world, ... well anything else than the dispatcher :-)
> 
> Hope this helps,
> 
> Robert



smime.p7s
Description: S/MIME cryptographic signature

Re: Restricting sling health checks

[Robert Munteanu]

Hi Andrei,

On Mon, 2017-08-21 at 11:55 +, Andrei Kalfas wrote:
> Hi,
> 
> Well, as far as I can tell, out of the box that URL can be called
> from anywhere. Thing is that I don’t quite care what would be the
> means to restrict access to the health check url as long as I don’t
> have to configure proxies. 


I don't think you have something like that in Sling.

It's a good idea to restrict access to the whole /system when running
Sling apps. In the AEM world you would use the dispatcher. In the Sling
world, ... well anything else than the dispatcher :-)

Hope this helps,

Robert

[jira] [Created] (SLING-7067) TagFileTest fails with launchpad.testing-war only

[Robert Munteanu (JIRA)]

Robert Munteanu created SLING-7067:
--

 Summary: TagFileTest fails with launchpad.testing-war only
 Key: SLING-7067
 URL: https://issues.apache.org/jira/browse/SLING-7067
 Project: Sling
  Issue Type: Bug
  Components: Launchpad
Reporter: Robert Munteanu
Assignee: Robert Munteanu
 Fix For: Launchpad Testing 9


{noformat}testTagFileDeployedInBundle(org.apache.sling.launchpad.webapp.jsp.TagFileTest)
  Time elapsed: 0.031 sec  <<< ERROR!
java.lang.NoSuchMethodError: 
org.osgi.framework.Version.compareTo(Lorg/osgi/framework/Version;)I
at 
org.apache.sling.commons.testing.integration.HttpTestBase.isBundleVersionAtLeast(HttpTestBase.java:601)
at 
org.apache.sling.launchpad.webapp.jsp.TagFileTest.testTagFileDeployedInBundle(TagFileTest.java:42){noformat}

It seems that applying the same fix as for launchpad.testing does not work.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: Restricting sling health checks

[Andrei Kalfas]

Hi,

Well, as far as I can tell, out of the box that URL can be called from 
anywhere. Thing is that I don’t quite care what would be the means to restrict 
access to the health check url as long as I don’t have to configure proxies. 

Thanks,
Andrei


> On Aug 21, 2017, at 2:46 PM, Nicolas Peltier  
> wrote:
> 
> Hi,
> 
> wouldn't you already have that restriction on an operation level for
> all /system/* URIs ?
> 
> Nicolas
> 
> 2017-08-21 13:10 GMT+02:00 Andrei Kalfas :
>> Hi,
>> 
>> I’m reading about sling health checks [1] and I was wondering if there is a
>> built in capability to restrict the IPs that are allowed to call the health
>> check url exposed by the health check servlet.
>> 
>> More specifically what I would like to achieve: once I’ve configured the
>> health check servlet to respond on /system/health I would like to be able to
>> restrict which IPs are may call that, given that I would use this to check
>> when AEM is up from 2 places, from a script running on the local machine and
>> from different load balancers so whitelisting something like
>> [127.0.0.1/32,10.0.0.0/16].
>> 
>> [1]
>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsling.apache.org%2Fdocumentation%2Fbundles%2Fsling-health-check-tool.html=02%7C01%7C%7Cd7896567df8d4a33488c08d4e88a4d53%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636389128078835407=FEB%2BMd2ycAIXYvIwqCP3RYCnkMVVXS8eOXS%2Bqu%2FqxTc%3D=0
>> 
>> Thank you,
>> Andrei
>> 



smime.p7s
Description: S/MIME cryptographic signature

Re: Restricting sling health checks

[Nicolas Peltier]

Hi,

wouldn't you already have that restriction on an operation level for
all /system/* URIs ?

Nicolas

2017-08-21 13:10 GMT+02:00 Andrei Kalfas :
> Hi,
>
> I’m reading about sling health checks [1] and I was wondering if there is a
> built in capability to restrict the IPs that are allowed to call the health
> check url exposed by the health check servlet.
>
> More specifically what I would like to achieve: once I’ve configured the
> health check servlet to respond on /system/health I would like to be able to
> restrict which IPs are may call that, given that I would use this to check
> when AEM is up from 2 places, from a script running on the local machine and
> from different load balancers so whitelisting something like
> [127.0.0.1/32,10.0.0.0/16].
>
> [1]
> https://sling.apache.org/documentation/bundles/sling-health-check-tool.html
>
> Thank you,
> Andrei
>

Restricting sling health checks

[Andrei Kalfas]

Hi,

I’m reading about sling health checks [1] and I was wondering if there is a 
built in capability to restrict the IPs that are allowed to call the health 
check url exposed by the health check servlet.

More specifically what I would like to achieve: once I’ve configured the health 
check servlet to respond on /system/health I would like to be able to restrict 
which IPs are may call that, given that I would use this to check when AEM is 
up from 2 places, from a script running on the local machine and from different 
load balancers so whitelisting something like [127.0.0.1/32,10.0.0.0/16]. 

[1] https://sling.apache.org/documentation/bundles/sling-health-check-tool.html 


Thank you,
Andrei



smime.p7s
Description: S/MIME cryptographic signature

Re: [VOTE] Release Apache Sling Scripting JSP 2.3.2

[Stefan Egli]

+1

Cheers,
Stefan

On 21/08/17 11:47, "Carsten Ziegeler"  wrote:

>Hi,
>
>We solved 1 issues in this release:
>https://issues.apache.org/jira/browse/SLING/fixforversion/12340247
>
>
>Staging repository:
>https://repository.apache.org/content/repositories/orgapachesling-1770/
>
>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 1770 /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.
>
>Regards
>Carsten
>-- 
>Carsten Ziegeler
>Adobe Research Switzerland
>cziege...@apache.org

[jira] [Commented] (SLING-7047) Update Dropwizard Metrics bundles to 3.2 to eliminate sun.misc dependency.

[Chetan Mehrotra (JIRA)]

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

Chetan Mehrotra commented on SLING-7047:


bq. with that hand crafted import statement if a client sees this issue, 
updates to commons metrics 1.2.4 this issue is not resolved and there is no 
indication that you also have to update another bundle. 

If the client read the issue then he also sees a reference to update Dropwizard 
Metrics bundle to 3.2.! So should not be much of an issue. But yes having OSGi 
import resolution failing would be a better indicator of the requirement

> Update Dropwizard Metrics bundles to 3.2 to eliminate sun.misc dependency.
> --
>
> Key: SLING-7047
> URL: https://issues.apache.org/jira/browse/SLING-7047
> Project: Sling
>  Issue Type: Task
>Reporter: Ian Boston
>Assignee: Chetan Mehrotra
> Fix For: commons metrics 1.2.4, Launchpad Builder 10
>
>
> as per https://github.com/ieb/slingmetrics/issues/1
> Not certain where the Dropwizard Metrics bundle is included, but it would be 
> good to make it work for any JDK, not just the Sun/Oracle JDK.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (SLING-7047) Update Dropwizard Metrics bundles to 3.2 to eliminate sun.misc dependency.

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-7047:
-

[~chetanm] Thanks - but just to clarifiy: with that hand crafted import 
statement if a client sees this issue, updates to commons metrics 1.2.4 this 
issue is not resolved and there is no indication that you also have to update 
another bundle. Without that import statement, this bundle will not resolve, 
giving a clear indication.

> Update Dropwizard Metrics bundles to 3.2 to eliminate sun.misc dependency.
> --
>
> Key: SLING-7047
> URL: https://issues.apache.org/jira/browse/SLING-7047
> Project: Sling
>  Issue Type: Task
>Reporter: Ian Boston
>Assignee: Chetan Mehrotra
> Fix For: commons metrics 1.2.4, Launchpad Builder 10
>
>
> as per https://github.com/ieb/slingmetrics/issues/1
> Not certain where the Dropwizard Metrics bundle is included, but it would be 
> good to make it work for any JDK, not just the Sun/Oracle JDK.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: [VOTE] Release Apache Sling Scripting JSP 2.3.2

[Robert Munteanu]

On Mon, 2017-08-21 at 11:47 +0200, Carsten Ziegeler wrote:
> Please vote to approve this release:

+1

Robert

signature.asc
Description: This is a digitally signed message part

[jira] [Comment Edited] (SLING-7047) Update Dropwizard Metrics bundles to 3.2 to eliminate sun.misc dependency.

[Chetan Mehrotra (JIRA)]

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

Chetan Mehrotra edited comment on SLING-7047 at 8/21/17 10:16 AM:
--

bq. This issue says commons metrics 1.2.4 has no dependency on sun.misc anymore 
- which is wrong; it still works with dropwizard 3.1, so it implicitely has 
this dependency

Thats going into nitty gritty. Commons Metrics 1.2.4 can work with either of 
Metrics 3.1.0 or 3.2.x. So it does not enforce requirement of sun.misc. If 
setup has Metrics 3.2.x then sun.misc is not required. 

Anyways I would remove that import statement

Update - Removed the import statement with 1805618


was (Author: chetanm):
bq. This issue says commons metrics 1.2.4 has no dependency on sun.misc anymore 
- which is wrong; it still works with dropwizard 3.1, so it implicitely has 
this dependency

Thats going into nitty gritty. Commons Metrics 1.2.4 can work with either of 
Metrics 3.1.0 or 3.2.x. So it does not enforce requirement of sun.misc. If 
setup has Metrics 3.2.x then sun.misc is not required. 

Anyways I would remove that import statement

> Update Dropwizard Metrics bundles to 3.2 to eliminate sun.misc dependency.
> --
>
> Key: SLING-7047
> URL: https://issues.apache.org/jira/browse/SLING-7047
> Project: Sling
>  Issue Type: Task
>Reporter: Ian Boston
>Assignee: Chetan Mehrotra
> Fix For: commons metrics 1.2.4, Launchpad Builder 10
>
>
> as per https://github.com/ieb/slingmetrics/issues/1
> Not certain where the Dropwizard Metrics bundle is included, but it would be 
> good to make it work for any JDK, not just the Sun/Oracle JDK.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (SLING-7047) Update Dropwizard Metrics bundles to 3.2 to eliminate sun.misc dependency.

[Chetan Mehrotra (JIRA)]

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

Chetan Mehrotra commented on SLING-7047:


bq. This issue says commons metrics 1.2.4 has no dependency on sun.misc anymore 
- which is wrong; it still works with dropwizard 3.1, so it implicitely has 
this dependency

Thats going into nitty gritty. Commons Metrics 1.2.4 can work with either of 
Metrics 3.1.0 or 3.2.x. So it does not enforce requirement of sun.misc. If 
setup has Metrics 3.2.x then sun.misc is not required. 

Anyways I would remove that import statement

> Update Dropwizard Metrics bundles to 3.2 to eliminate sun.misc dependency.
> --
>
> Key: SLING-7047
> URL: https://issues.apache.org/jira/browse/SLING-7047
> Project: Sling
>  Issue Type: Task
>Reporter: Ian Boston
>Assignee: Chetan Mehrotra
> Fix For: commons metrics 1.2.4, Launchpad Builder 10
>
>
> as per https://github.com/ieb/slingmetrics/issues/1
> Not certain where the Dropwizard Metrics bundle is included, but it would be 
> good to make it work for any JDK, not just the Sun/Oracle JDK.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (SLING-7047) Update Dropwizard Metrics bundles to 3.2 to eliminate sun.misc dependency.

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-7047:
-

[~chetanm] I just realized that it's not ok :) This issue says commons metrics 
1.2.4 has no dependency on sun.misc anymore - which is wrong; it still works 
with dropwizard 3.1, so it implicitely has this dependency. So, either we move 
this issue to the next version or remove the hand craftet import package 
statement.

> Update Dropwizard Metrics bundles to 3.2 to eliminate sun.misc dependency.
> --
>
> Key: SLING-7047
> URL: https://issues.apache.org/jira/browse/SLING-7047
> Project: Sling
>  Issue Type: Task
>Reporter: Ian Boston
>Assignee: Chetan Mehrotra
> Fix For: commons metrics 1.2.4, Launchpad Builder 10
>
>
> as per https://github.com/ieb/slingmetrics/issues/1
> Not certain where the Dropwizard Metrics bundle is included, but it would be 
> good to make it work for any JDK, not just the Sun/Oracle JDK.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (SLING-7047) Update Dropwizard Metrics bundles to 3.2 to eliminate sun.misc dependency.

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-7047:
-

[~chetanm] I guess that's ok, however I think it makes sense to update the 
dropwizard metrics lib for existing setups as well

> Update Dropwizard Metrics bundles to 3.2 to eliminate sun.misc dependency.
> --
>
> Key: SLING-7047
> URL: https://issues.apache.org/jira/browse/SLING-7047
> Project: Sling
>  Issue Type: Task
>Reporter: Ian Boston
>Assignee: Chetan Mehrotra
> Fix For: commons metrics 1.2.4, Launchpad Builder 10
>
>
> as per https://github.com/ieb/slingmetrics/issues/1
> Not certain where the Dropwizard Metrics bundle is included, but it would be 
> good to make it work for any JDK, not just the Sun/Oracle JDK.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (SLING-7047) Update Dropwizard Metrics bundles to 3.2 to eliminate sun.misc dependency.

[Chetan Mehrotra (JIRA)]

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

Chetan Mehrotra commented on SLING-7047:


bq. How do we ensure that we don't use 3.2 API?

Yeah that would be tricky (no automated check). I was thinking to remove that 
once 1.2.4 version is released as that would allow the bundle to be usable on 
older setup. Would that be ok?

> Update Dropwizard Metrics bundles to 3.2 to eliminate sun.misc dependency.
> --
>
> Key: SLING-7047
> URL: https://issues.apache.org/jira/browse/SLING-7047
> Project: Sling
>  Issue Type: Task
>Reporter: Ian Boston
>Assignee: Chetan Mehrotra
> Fix For: commons metrics 1.2.4, Launchpad Builder 10
>
>
> as per https://github.com/ieb/slingmetrics/issues/1
> Not certain where the Dropwizard Metrics bundle is included, but it would be 
> good to make it work for any JDK, not just the Sun/Oracle JDK.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: [VOTE] Release Apache Sling Scripting JSP 2.3.2

[Carsten Ziegeler]

+1

 

-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

[VOTE] Release Apache Sling Scripting JSP 2.3.2

[Carsten Ziegeler]

Hi,

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


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

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 1770 /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.

Regards
Carsten
-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

[jira] [Commented] (SLING-7047) Update Dropwizard Metrics bundles to 3.2 to eliminate sun.misc dependency.

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-7047:
-

[~chetanm] I think the new import directive is causing for trouble. How do we 
ensure that we don't use 3.2 API?

> Update Dropwizard Metrics bundles to 3.2 to eliminate sun.misc dependency.
> --
>
> Key: SLING-7047
> URL: https://issues.apache.org/jira/browse/SLING-7047
> Project: Sling
>  Issue Type: Task
>Reporter: Ian Boston
>Assignee: Chetan Mehrotra
> Fix For: commons metrics 1.2.4, Launchpad Builder 10
>
>
> as per https://github.com/ieb/slingmetrics/issues/1
> Not certain where the Dropwizard Metrics bundle is included, but it would be 
> good to make it work for any JDK, not just the Sun/Oracle JDK.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (SLING-7066) Support mixins in repoinit "create path" statements

[Timothee Maret (JIRA)]

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

Timothee Maret reassigned SLING-7066:
-

Assignee: Timothee Maret

> Support mixins in repoinit "create path" statements
> ---
>
> Key: SLING-7066
> URL: https://issues.apache.org/jira/browse/SLING-7066
> Project: Sling
>  Issue Type: New Feature
>  Components: Repoinit
>Reporter: Bertrand Delacretaz
>Assignee: Timothee Maret
>Priority: Minor
>
> The repoinit "create path" statement currently supports nodetypes but no 
> mixins, we should add support for them.
> The current create path syntax is like
> {code}
> create path (sling:Folder) /var/discovery(nt:unstructured)/somefolder
> create path /one/two/three
> create path /three/four(nt:folk)/five(nt:jazz)/six
> {code}
> Where the first bracketed statement, before the path, is the default nodetype 
> for all subpaths, and each subpath can have a specific nodetype.
> To add mixin support I suggest the syntax of these examples for these 
> bracketed statements:
> {code}
> (sling:Folder mixin mix:A, mix:B)
> (nt:unstructured mixin mix:C)
> (mixin mix:A)
> (mixin mix:A, mix:B)
> {code}
> The last two forms without a nodeteype meaning "set mixins only but keep the 
> default nodetype", which in this example
> {code}
> create path (sling:Folder) /var/foo(mixin mix:B)
> {code}
> means /var/foo is of type sling:Folder with mixin mix:B
> whereas in this example
> {code}
> create /var/bar(mixin mix:C)
> {code}
> /var/bar uses the default type defined by /var's type, with mix:C added.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (SLING-7066) Support mixins in repoinit "create path" statements

[Bertrand Delacretaz (JIRA)]

Bertrand Delacretaz created SLING-7066:
--

 Summary: Support mixins in repoinit "create path" statements
 Key: SLING-7066
 URL: https://issues.apache.org/jira/browse/SLING-7066
 Project: Sling
  Issue Type: New Feature
  Components: Repoinit
Reporter: Bertrand Delacretaz
Priority: Minor


The repoinit "create path" statement currently supports nodetypes but no 
mixins, we should add support for them.

The current create path syntax is like

{code}
create path (sling:Folder) /var/discovery(nt:unstructured)/somefolder
create path /one/two/three
create path /three/four(nt:folk)/five(nt:jazz)/six
{code}

Where the first bracketed statement, before the path, is the default nodetype 
for all subpaths, and each subpath can have a specific nodetype.

To add mixin support I suggest the syntax of these examples for these bracketed 
statements:
{code}
(sling:Folder mixin mix:A, mix:B)
(nt:unstructured mixin mix:C)
(mixin mix:A)
(mixin mix:A, mix:B)
{code}

The last two forms without a nodeteype meaning "set mixins only but keep the 
default nodetype", which in this example

{code}
create path (sling:Folder) /var/foo(mixin mix:B)
{code}

means /var/foo is of type sling:Folder with mixin mix:B

whereas in this example

{code}
create /var/bar(mixin mix:C)
{code}

/var/bar uses the default type defined by /var's type, with mix:C added.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (SLING-7061) Access control setup of repository-level permissions (i.e. null path)

[Timothee Maret (JIRA)]

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

Timothee Maret updated SLING-7061:
--
Affects Version/s: Repoinit Parser 1.1.0

> Access control setup of repository-level permissions (i.e. null path)
> -
>
> Key: SLING-7061
> URL: https://issues.apache.org/jira/browse/SLING-7061
> Project: Sling
>  Issue Type: Improvement
>  Components: Repoinit
>Affects Versions: Repoinit Parser 1.1.0
>Reporter: angela
>Assignee: Timothee Maret
>
> If I am not mistaken it is currently not possible to create access control 
> setup for principals at the 'null' path, which according to JSR 283 is to be 
> used to setup repository level permissions such as 
> - node type definition management (i.e. registering new node types)
> - namespace management (i.e. registering new namespaces)
> - privilege management (i.e. registering new privileges)
> - workspace management (i.e. creating/removing workspaces)
> All of these operations are not bound to a path (like e.g. removing an item 
> or creating a new version for a given node) but instead take global effect on 
> the whole JCR repository... that's why permissions for these operations 
> cannot be granted at a given path.
> In the default authorization model shipped with Jackrabbit and Oak the -null- 
> path access control policy is stored with a dedicated _rep:repoPolicy_ node 
> located with the root node and 
> For service user definitions we need to be able to define entries for the 
> -null- path policy for the reasons explained above. Thanks for extending the 
> repo-init accordingly.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (SLING-7061) Access control setup of repository-level permissions (i.e. null path)

[Timothee Maret (JIRA)]

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

Timothee Maret reassigned SLING-7061:
-

Assignee: Timothee Maret

> Access control setup of repository-level permissions (i.e. null path)
> -
>
> Key: SLING-7061
> URL: https://issues.apache.org/jira/browse/SLING-7061
> Project: Sling
>  Issue Type: Improvement
>  Components: Repoinit
>Reporter: angela
>Assignee: Timothee Maret
>
> If I am not mistaken it is currently not possible to create access control 
> setup for principals at the 'null' path, which according to JSR 283 is to be 
> used to setup repository level permissions such as 
> - node type definition management (i.e. registering new node types)
> - namespace management (i.e. registering new namespaces)
> - privilege management (i.e. registering new privileges)
> - workspace management (i.e. creating/removing workspaces)
> All of these operations are not bound to a path (like e.g. removing an item 
> or creating a new version for a given node) but instead take global effect on 
> the whole JCR repository... that's why permissions for these operations 
> cannot be granted at a given path.
> In the default authorization model shipped with Jackrabbit and Oak the -null- 
> path access control policy is stored with a dedicated _rep:repoPolicy_ node 
> located with the root node and 
> For service user definitions we need to be able to define entries for the 
> -null- path policy for the reasons explained above. Thanks for extending the 
> repo-init accordingly.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (SLING-7047) Update Dropwizard Metrics bundles to 3.2 to eliminate sun.misc dependency.

[Chetan Mehrotra (JIRA)]

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

Chetan Mehrotra updated SLING-7047:
---
Issue Type: Task  (was: Bug)

> Update Dropwizard Metrics bundles to 3.2 to eliminate sun.misc dependency.
> --
>
> Key: SLING-7047
> URL: https://issues.apache.org/jira/browse/SLING-7047
> Project: Sling
>  Issue Type: Task
>Reporter: Ian Boston
>Assignee: Chetan Mehrotra
> Fix For: commons metrics 1.2.4, Launchpad Builder 10
>
>
> as per https://github.com/ieb/slingmetrics/issues/1
> Not certain where the Dropwizard Metrics bundle is included, but it would be 
> good to make it work for any JDK, not just the Sun/Oracle JDK.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (SLING-7047) Update Dropwizard Metrics bundles to 3.2 to eliminate sun.misc dependency.

[Chetan Mehrotra (JIRA)]

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

Chetan Mehrotra resolved SLING-7047.

Resolution: Fixed

> Update Dropwizard Metrics bundles to 3.2 to eliminate sun.misc dependency.
> --
>
> Key: SLING-7047
> URL: https://issues.apache.org/jira/browse/SLING-7047
> Project: Sling
>  Issue Type: Task
>Reporter: Ian Boston
>Assignee: Chetan Mehrotra
> Fix For: commons metrics 1.2.4, Launchpad Builder 10
>
>
> as per https://github.com/ieb/slingmetrics/issues/1
> Not certain where the Dropwizard Metrics bundle is included, but it would be 
> good to make it work for any JDK, not just the Sun/Oracle JDK.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (SLING-7047) Update Dropwizard Metrics bundles to 3.2 to eliminate sun.misc dependency.

[Chetan Mehrotra (JIRA)]

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

Chetan Mehrotra reassigned SLING-7047:
--

Assignee: Chetan Mehrotra

> Update Dropwizard Metrics bundles to 3.2 to eliminate sun.misc dependency.
> --
>
> Key: SLING-7047
> URL: https://issues.apache.org/jira/browse/SLING-7047
> Project: Sling
>  Issue Type: Bug
>Reporter: Ian Boston
>Assignee: Chetan Mehrotra
> Fix For: commons metrics 1.2.4, Launchpad Builder 10
>
>
> as per https://github.com/ieb/slingmetrics/issues/1
> Not certain where the Dropwizard Metrics bundle is included, but it would be 
> good to make it work for any JDK, not just the Sun/Oracle JDK.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (SLING-7047) Update Dropwizard Metrics bundles to 3.2 to eliminate sun.misc dependency.

[Chetan Mehrotra (JIRA)]

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

Chetan Mehrotra commented on SLING-7047:


Updated the builder with 1805604

> Update Dropwizard Metrics bundles to 3.2 to eliminate sun.misc dependency.
> --
>
> Key: SLING-7047
> URL: https://issues.apache.org/jira/browse/SLING-7047
> Project: Sling
>  Issue Type: Bug
>Reporter: Ian Boston
> Fix For: commons metrics 1.2.4, Launchpad Builder 10
>
>
> as per https://github.com/ieb/slingmetrics/issues/1
> Not certain where the Dropwizard Metrics bundle is included, but it would be 
> good to make it work for any JDK, not just the Sun/Oracle JDK.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)