[jira] [Comment Edited] (SLING-6778) [Sling Models] Support Delegate Pattern for Models adapted from interfaces

2017-04-11 Thread Justin Edelson (JIRA) 

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

Justin Edelson edited comment on SLING-6778 at 4/11/17 10:57 PM:
-

proposed change implementing the vocabulary from the description. Assumes that 
SLING-5379 has been implemented.


was (Author: justinedelson):
proposed change implementing the vocabulary from the description.

> [Sling Models] Support Delegate Pattern for Models adapted from interfaces
> --
>
> Key: SLING-6778
> URL: https://issues.apache.org/jira/browse/SLING-6778
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>Reporter: Justin Edelson
> Attachments: SLING-6778.diff
>
>
> Consider this interface:
> {code}
> public interface Something {
>   
>   String getText();
> String getOther();
> }
> {code}
> With this model implementation:
> {code}
> @Model(adaptable = Resource.class, adapter = Something.class, resourceType = 
> "myco/something")
> public class SomethingImpl implements Something {
>   
>   @Inject
>   private String text;
> @Inject
> private String other;
>   public String getText() {
>   return text;
>   }
> public String getOther() {
> return other;
>  }
> }
> {code}
> And let's say that there is a resource with the type {{myco/somethingelse}} 
> and that {{myco/something}} is the super type of {{myco/somethingelse}}.
> In order to create a model class associated with {{myco/somethingelse}} and 
> have that model class access the original class using the Delegate pattern, 
> it is quite difficult to do so since you need to manually create a wrapping 
> resource and then adapt that. I think we can facilitate this pattern through 
> SLING-5739 and a new @Via provider.
> The syntax would be something along the lines of
> {code}
> @Self @Via(type = SuperResourceType.class)
> private Something delegate;
> {code}
> Assuming you wanted the super type
> We could also support manually setting the resource type, i.e.
> {code}
> @Self @Via(value = “some/other/resourceType”, type = 
> ForcedResourceType.class)
> private Something delegate;
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (SLING-6778) [Sling Models] Support Delegate Pattern for Models adapted from interfaces

2017-04-11 Thread Justin Edelson (JIRA) 

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

Justin Edelson updated SLING-6778:
--
Description: 
Consider this interface:

{code}
public interface Something {

String getText();

String getOther();

}
{code}

With this model implementation:

{code}
@Model(adaptable = Resource.class, adapter = Something.class, resourceType = 
"myco/something")
public class SomethingImpl implements Something {

@Inject
private String text;

@Inject
private String other;

public String getText() {
return text;
}
public String getOther() {
return other;
 }

}
{code}

And let's say that there is a resource with the type {{myco/somethingelse}} and 
that {{myco/something}} is the super type of {{myco/somethingelse}}.

In order to create a model class associated with {{myco/somethingelse}} and 
have that model class access the original class using the Delegate pattern, it 
is quite difficult to do so since you need to manually create a wrapping 
resource and then adapt that. I think we can facilitate this pattern through 
SLING-5739 and a new @Via provider.

The syntax would be something along the lines of

{code}
@Self @Via(type = SuperResourceType.class)
private Something delegate;
{code}

Assuming you wanted the super type

We could also support manually setting the resource type, i.e.

{code}
@Self @Via(value = “some/other/resourceType”, type = 
ForcedResourceType.class)
private Something delegate;
{code}

  was:
Consider this interface:

{code}
public interface Something {

String getText();

String getOther();

}
{code}

With this model implementation:

{code}
@Model(adaptable = Resource.class, adapter = Something.class, resourceType = 
"myco/something")
public class SomethingImpl implements Something {

@Inject
private String text;

@Inject
private String other;

public String getText() {
return text;
}
public String getOther() {
return other;
 }

}
{code}

And let's say that there is a resource with the type myco/somethingelse and 
that myco/something is the super type of myco/somethingelse.

In order to create a model class associated with myco/somethingelse and have 
that model class access the original class using the Delegate pattern, it is 
quite difficult to do so since you need to manually create a wrapping resource 
and then adapt that. I think we can facilitate this pattern through SLING-5739 
and a new @Via provider.

The syntax would be something along the lines of

{code}
@Self @Via(type = SuperResourceType.class)
private Something delegate;
{code}

Assuming you wanted the super type

We could also support manually setting the resource type, i.e.

{code}
@Self @Via(value = “some/other/resourceType”, type = 
ForcedResourceType.class)
private Something delegate;
{code}


> [Sling Models] Support Delegate Pattern for Models adapted from interfaces
> --
>
> Key: SLING-6778
> URL: https://issues.apache.org/jira/browse/SLING-6778
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>Reporter: Justin Edelson
> Attachments: SLING-6778.diff
>
>
> Consider this interface:
> {code}
> public interface Something {
>   
>   String getText();
> String getOther();
> }
> {code}
> With this model implementation:
> {code}
> @Model(adaptable = Resource.class, adapter = Something.class, resourceType = 
> "myco/something")
> public class SomethingImpl implements Something {
>   
>   @Inject
>   private String text;
> @Inject
> private String other;
>   public String getText() {
>   return text;
>   }
> public String getOther() {
> return other;
>  }
> }
> {code}
> And let's say that there is a resource with the type {{myco/somethingelse}} 
> and that {{myco/something}} is the super type of {{myco/somethingelse}}.
> In order to create a model class associated with {{myco/somethingelse}} and 
> have that model class access the original class using the Delegate pattern, 
> it is quite difficult to do so since you need to manually create a wrapping 
> resource and then adapt that. I think we can facilitate this pattern through 
> SLING-5739 and a new @Via provider.
> The syntax would be something along the lines of
> {code}
> @Self @Via(type = SuperResourceType.class)
> private Something delegate;
> {code}
> Assuming you wanted the super type
> We

[jira] [Updated] (SLING-6778) [Sling Models] Support Delegate Pattern for Models adapted from interfaces

2017-04-11 Thread Justin Edelson (JIRA) 

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

Justin Edelson updated SLING-6778:
--
Attachment: SLING-6778.diff

proposed change implementing the vocabulary from the description.

> [Sling Models] Support Delegate Pattern for Models adapted from interfaces
> --
>
> Key: SLING-6778
> URL: https://issues.apache.org/jira/browse/SLING-6778
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>Reporter: Justin Edelson
> Attachments: SLING-6778.diff
>
>
> Consider this interface:
> {code}
> public interface Something {
>   
>   String getText();
> String getOther();
> }
> {code}
> With this model implementation:
> {code}
> @Model(adaptable = Resource.class, adapter = Something.class, resourceType = 
> "myco/something")
> public class SomethingImpl implements Something {
>   
>   @Inject
>   private String text;
> @Inject
> private String other;
>   public String getText() {
>   return text;
>   }
> public String getOther() {
> return other;
>  }
> }
> {code}
> And let's say that there is a resource with the type myco/somethingelse and 
> that myco/something is the super type of myco/somethingelse.
> In order to create a model class associated with myco/somethingelse and have 
> that model class access the original class using the Delegate pattern, it is 
> quite difficult to do so since you need to manually create a wrapping 
> resource and then adapt that. I think we can facilitate this pattern through 
> SLING-5739 and a new @Via provider.
> The syntax would be something along the lines of
> {code}
> @Self @Via(type = SuperResourceType.class)
> private Something delegate;
> {code}
> Assuming you wanted the super type
> We could also support manually setting the resource type, i.e.
> {code}
> @Self @Via(value = “some/other/resourceType”, type = 
> ForcedResourceType.class)
> private Something delegate;
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

2017-04-11 Thread Justin Edelson (JIRA) 

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

Justin Edelson updated SLING-5739:
--
Attachment: SLING-5739.diff

Given the use case in SLING-6778, I would like to revive this issue. I think 
that issue pretty well illustrates how having multiple @Via options is a good 
idea.

Attaching an updated version of the diff. The only significant change between 
this and the original from last year is that a ViaProvider can specify a 
special value to indicate that the original adaptable should be used.

> [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
> Attachments: SLING-5739.diff
>
>
> 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.15#6346)

[jira] [Created] (SLING-6778) [Sling Models] Support Delegate Pattern for Models adapted from interfaces

2017-04-11 Thread Justin Edelson (JIRA) 
Justin Edelson created SLING-6778:
-

 Summary: [Sling Models] Support Delegate Pattern for Models 
adapted from interfaces
 Key: SLING-6778
 URL: https://issues.apache.org/jira/browse/SLING-6778
 Project: Sling
  Issue Type: New Feature
  Components: Extensions
Reporter: Justin Edelson


Consider this interface:

{code}
public interface Something {

String getText();

String getOther();

}
{code}

With this model implementation:

{code}
@Model(adaptable = Resource.class, adapter = Something.class, resourceType = 
"myco/something")
public class SomethingImpl implements Something {

@Inject
private String text;

@Inject
private String other;

public String getText() {
return text;
}
public String getOther() {
return other;
 }

}
{code}

And let's say that there is a resource with the type myco/somethingelse and 
that myco/something is the super type of myco/somethingelse.

In order to create a model class associated with myco/somethingelse and have 
that model class access the original class using the Delegate pattern, it is 
quite difficult to do so since you need to manually create a wrapping resource 
and then adapt that. I think we can facilitate this pattern through SLING-5739 
and a new @Via provider.

The syntax would be something along the lines of

{code}
@Self @Via(type = SuperResourceType.class)
private Something delegate;
{code}

Assuming you wanted the super type

We could also support manually setting the resource type, i.e.

{code}
@Self @Via(value = “some/other/resourceType”, type = 
ForcedResourceType.class)
private Something delegate;
{code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (SLING-6739) split sling.event into event.api and event.impl

2017-04-11 Thread Stefan Egli (JIRA) 

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

Stefan Egli commented on SLING-6739:


h6. step 7: event/api/pom.xml : removed unnecessary properties 
(http://svn.apache.org/viewvc?rev=1790997=rev)

> split sling.event into event.api and event.impl
> ---
>
> Key: SLING-6739
> URL: https://issues.apache.org/jira/browse/SLING-6739
> Project: Sling
>  Issue Type: Task
>  Components: Extensions
>Affects Versions: Event 4.2.2
>Reporter: Stefan Egli
>Assignee: Stefan Egli
>
> Currently sling.event contains both API and implementation. In order to 
> support different implementation variants it would be good to have two 
> separate bundles, one containing just the API and one with the (current) 
> implementation. I would suggest to create
> bundles/extensions/event-api
> bundles/extensions/event-impl
> and to remove the current
> bundles/extensions/event



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Comment Edited] (SLING-6261) ThreadExpiringThreadPool is relying on uncaught exceptions to kill threads

2017-04-11 Thread Konrad Windszus (JIRA) 

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

Konrad Windszus edited comment on SLING-6261 at 4/11/17 2:53 PM:
-

Thanks for the feedback, will rework the patch to make the API backwards 
compatible. 

Regarding supporting weird Java Runtimes where the reflection trick does not 
work: I would rather log explicitly that thread locals are not cleaned up in 
that case instead of falling back to the {{ThreadExpiringThreadPool}}. I assume 
that this should almost never happen and I don't think it is worth the effort 
to maintain the code for {{ThreadExpiringThreadPool}} for those JREs. Also it 
is not clear whether those non-Oracle JREs are compliant with the 
{{ThreadExpiringThreadPool}} in its current form because even that relies on 
the undocumented feature that throwing an exception from its {{afterExecute}} 
method leads to discarding the thread.


was (Author: kwin):
Thanks for the feedback, will rework the patch to make the API still 
compatible. 

Regarding supporting weird Java Runtimes where the reflection trick does not 
work: I would rather log explicitly that thread locals are not cleaned up in 
that case instead of falling back to the {{ThreadExpiringThreadPool}}. I assume 
that this should almost never happen and I don't think it is worth the effort 
to maintain the code for {{ThreadExpiringThreadPool}} for those JREs. Also it 
is not clear whether those non-Oracle JREs are compliant with the 
{{ThreadExpiringThreadPool}} in its current form because even that relies on 
the undocumented feature that throwing an exception from its {{afterExecute}} 
method leads to discarding the thread.

> ThreadExpiringThreadPool is relying on uncaught exceptions to kill threads
> --
>
> Key: SLING-6261
> URL: https://issues.apache.org/jira/browse/SLING-6261
> Project: Sling
>  Issue Type: Improvement
>  Components: Commons
>Affects Versions: Commons Threads 3.2.6
>Reporter: Konrad Windszus
> Fix For: Commons Threads 3.2.8
>
> Attachments: SLING-6261-v01.patch
>
>
> In {{o.a.s.commons.threads.impl.ThreadExpiringThreadPool}} a 
> {{RuntimeException}} with message "Kill old thread" is used in 
> {{checkMaxThreadAge(final Thread thread)}}. This leads by default to a 
> suspension of the thread when debugging with Eclipse (as since Neon JDT will 
> suspend the thread on all uncaught exceptions). More information is available 
> in 
> http://stackoverflow.com/questions/6290470/eclipse-debugger-always-blocks-on-threadpoolexecutor-without-any-obvious-excepti.
>  There should be a different mechanism to kill the thread than an uncaught 
> exception.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (SLING-6261) ThreadExpiringThreadPool is relying on uncaught exceptions to kill threads

2017-04-11 Thread Konrad Windszus (JIRA) 

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

Konrad Windszus commented on SLING-6261:


Thanks for the feedback, will rework the patch to make the API still 
compatible. 

Regarding supporting weird Java Runtimes where the reflection trick does not 
work: I would rather log explicitly that thread locals are not cleaned up in 
that case instead of falling back to the {{ThreadExpiringThreadPool}}. I assume 
that this should almost never happen and I don't think it is worth the effort 
to maintain the code for {{ThreadExpiringThreadPool}} for those JREs. Also it 
is not clear whether those non-Oracle JREs are compliant with the 
{{ThreadExpiringThreadPool}} in its current form because even that relies on 
the undocumented feature that throwing an exception from its {{afterExecute}} 
method leads to discarding the thread.

> ThreadExpiringThreadPool is relying on uncaught exceptions to kill threads
> --
>
> Key: SLING-6261
> URL: https://issues.apache.org/jira/browse/SLING-6261
> Project: Sling
>  Issue Type: Improvement
>  Components: Commons
>Affects Versions: Commons Threads 3.2.6
>Reporter: Konrad Windszus
> Fix For: Commons Threads 3.2.8
>
> Attachments: SLING-6261-v01.patch
>
>
> In {{o.a.s.commons.threads.impl.ThreadExpiringThreadPool}} a 
> {{RuntimeException}} with message "Kill old thread" is used in 
> {{checkMaxThreadAge(final Thread thread)}}. This leads by default to a 
> suspension of the thread when debugging with Eclipse (as since Neon JDT will 
> suspend the thread on all uncaught exceptions). More information is available 
> in 
> http://stackoverflow.com/questions/6290470/eclipse-debugger-always-blocks-on-threadpoolexecutor-without-any-obvious-excepti.
>  There should be a different mechanism to kill the thread than an uncaught 
> exception.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (SLING-6763) Remove org.apache.sling.commons.json dependency from esx engine

2017-04-11 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on SLING-6763:
---

GitHub user labertasch opened a pull request:

https://github.com/apache/sling/pull/212

SLING-6763 |  fixed typo in readme for the test script foo.esx and up…

SLING-6763 |  fixed typo in readme for the test script foo.esx and updated 
parent pom to 30

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/labertasch/sling SLING-6763

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/sling/pull/212.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #212


commit a553ad0172a0757273c027f522acdedfbf2cf22f
Author: labertasch 
Date:   2017-04-11T13:07:25Z

SLING-6763 |  fixed typo in readme for the test script foo.esx and updated 
parent pom to 30




> Remove org.apache.sling.commons.json dependency from esx engine
> ---
>
> Key: SLING-6763
> URL: https://issues.apache.org/jira/browse/SLING-6763
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Reporter: Senol Tas
>Assignee: Bertrand Delacretaz
> Fix For: Scripting ESX 0.2.0
>
>
> remove org.apache.sling.commons.json dependency from esx engine and replace 
> with native build in nashorn JSON parser
> + minor updates in the demo package to showcase the usage of dynamically 
> changing handlebars templates based on selector.
> + added experimental es6 transpiler as preperation for sandboxing the engine
> + updated demo with es6 classes and imports
> i created a pull request on github:
> https://github.com/apache/sling/pull/209



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] sling pull request #212: SLING-6763 | fixed typo in readme for the test scri...

2017-04-11 Thread labertasch 
GitHub user labertasch opened a pull request:

https://github.com/apache/sling/pull/212

SLING-6763 |  fixed typo in readme for the test script foo.esx and up…

SLING-6763 |  fixed typo in readme for the test script foo.esx and updated 
parent pom to 30

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/labertasch/sling SLING-6763

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/sling/pull/212.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #212


commit a553ad0172a0757273c027f522acdedfbf2cf22f
Author: labertasch 
Date:   2017-04-11T13:07:25Z

SLING-6763 |  fixed typo in readme for the test script foo.esx and updated 
parent pom to 30




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Resolved] (SLING-6772) Provide default mapping for service users

2017-04-11 Thread Carsten Ziegeler (JIRA) 

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

Carsten Ziegeler resolved SLING-6772.
-
Resolution: Fixed

> Provide default mapping for service users
> -
>
> Key: SLING-6772
> URL: https://issues.apache.org/jira/browse/SLING-6772
> Project: Sling
>  Issue Type: Improvement
>  Components: Service User Mapper
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Service User Mapper 1.3.0
>
> Attachments: SLING-6772.karaf.patch, SLING-6772.repoinit.patch
>
>
> As discussed in [1] we should aim at making Sling configurationless again. 
> One part which currently always needs configurations is the service user 
> mapper. We should add a default mapping, from a bundle symblic name and sub 
> service to 
> {noformat}
> "serviceuser@" + {bundle.symblicName} + [":" + sub service]
> {noformat}
> [1] 
> https://lists.apache.org/thread.html/6f90d751ddd20d7041475ba5d5fc89beda1906048ff91cc2f564e63e@%3Cdev.sling.apache.org%3E



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] sling pull request #209: [contrib esx] removed org.apache.sling.commons.json...

2017-04-11 Thread labertasch 
Github user labertasch closed the pull request at:

https://github.com/apache/sling/pull/209


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (SLING-6773) Separate HeathCheck API from Implementation

2017-04-11 Thread Justin Edelson (JIRA) 

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

Justin Edelson commented on SLING-6773:
---

thanks [~rombert]

> Separate HeathCheck API from Implementation
> ---
>
> Key: SLING-6773
> URL: https://issues.apache.org/jira/browse/SLING-6773
> Project: Sling
>  Issue Type: Improvement
>  Components: Health Check
>Affects Versions: Health Check Core 1.2.6
>Reporter: Justin Edelson
>Assignee: Justin Edelson
> Fix For: Health Check Core 1.2.8, Health Check API 1.0.0
>
> Attachments: SLING-6773.diff
>
>
> Currently, the HealthCheck API and implementation are bundled together in one 
> bundle. In order for implementors of HealthChecks to only need to depend upon 
> a minimal dependency, we should package the API separately.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (SLING-5983) Remove deprecated jcr resource API

2017-04-11 Thread Karl Pauls (JIRA) 

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

Karl Pauls resolved SLING-5983.
---
Resolution: Fixed

Thanks, I commited the patch in r1790951 and subsequently, adapted testing to 
work with it in r1790952 as well as adding it to the launchpad in r1790953.


> Remove deprecated jcr resource API
> --
>
> Key: SLING-5983
> URL: https://issues.apache.org/jira/browse/SLING-5983
> Project: Sling
>  Issue Type: Improvement
>  Components: JCR
>Reporter: Carsten Ziegeler
>Assignee: Karl Pauls
> Fix For: JCR Resource 2.9.4
>
> Attachments: SLING-5983.patch
>
>
> The jcr resource API has been deprecated for some time and not used anymore 
> in our codebase, we should now remove it from the jcr resource bundle
> We should also remove the deprecated PathMapper



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (SLING-6763) Remove org.apache.sling.commons.json dependency from esx engine

2017-04-11 Thread Bertrand Delacretaz (JIRA) 

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

Bertrand Delacretaz commented on SLING-6763:


I have committed your contribution, thank you very much!

And also created a sibling org.apache.sling.fragment.nashorn fragment bundle 
which means you don't need to edit sling.properties anymore, just install that 
bundle to export the Nashorn API package.

However at revision 1790948 the minimal example from the README does not work 
for me, it outputs 

{code}
${currentNode.properties.title}Here's some example text
{code}

Without interpreting the {{currentNode.properties.title}} variable.

What I did is:
* Start a Sling trunk launchpad from scratch
* Install the org.apache.sling.fragment.nashorn fragment and esx bundles, 
verify that esx is active
* Run the minimal example from the README

The ESX engine is activated, it's just the interpretation of the readme test 
example variable that does not happen.


> Remove org.apache.sling.commons.json dependency from esx engine
> ---
>
> Key: SLING-6763
> URL: https://issues.apache.org/jira/browse/SLING-6763
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Reporter: Senol Tas
>Assignee: Bertrand Delacretaz
> Fix For: Scripting ESX 0.2.0
>
>
> remove org.apache.sling.commons.json dependency from esx engine and replace 
> with native build in nashorn JSON parser
> + minor updates in the demo package to showcase the usage of dynamically 
> changing handlebars templates based on selector.
> + added experimental es6 transpiler as preperation for sandboxing the engine
> + updated demo with es6 classes and imports
> i created a pull request on github:
> https://github.com/apache/sling/pull/209



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (SLING-6773) Separate HeathCheck API from Implementation

2017-04-11 Thread Robert Munteanu (JIRA) 

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

Robert Munteanu commented on SLING-6773:


Added hc.api to Jenkins in https://svn.apache.org/r1790929

> Separate HeathCheck API from Implementation
> ---
>
> Key: SLING-6773
> URL: https://issues.apache.org/jira/browse/SLING-6773
> Project: Sling
>  Issue Type: Improvement
>  Components: Health Check
>Affects Versions: Health Check Core 1.2.6
>Reporter: Justin Edelson
>Assignee: Justin Edelson
> Fix For: Health Check Core 1.2.8, Health Check API 1.0.0
>
> Attachments: SLING-6773.diff
>
>
> Currently, the HealthCheck API and implementation are bundled together in one 
> bundle. In order for implementors of HealthChecks to only need to depend upon 
> a minimal dependency, we should package the API separately.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)