[jira] [Commented] (SLING-7508) StackOverflowError adapting ServletResource to Sling Mode with impl picker

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph commented on SLING-7508:
-

As far as I can see the issue is caused by the 
[ResourceTypeBasedResourcePicker.java#L46|https://github.com/apache/sling-org-apache-sling-models-impl/blob/master/src/main/java/org/apache/sling/models/impl/ResourceTypeBasedResourcePicker.java#L46]
 calling [AdapterImplementations#getModelClassForResource()| 
https://github.com/apache/sling-org-apache-sling-models-impl/blob/master/src/main/java/org/apache/sling/models/impl/AdapterImplementations.java#L321]
 which walks up the resourceType hierarchy until it finds an implementation. 
For the SerlvetResource in that case the resourceSuperTypes are 
"sling/bundle/resource" and null, so it ends up getting the resource of the 
originalResourceType of the ServletResource which is again the ServletResource 
causing the endless loop.

> StackOverflowError adapting ServletResource to Sling Mode with impl picker
> --
>
> Key: SLING-7508
> URL: https://issues.apache.org/jira/browse/SLING-7508
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: Sling Models Impl 1.4.8
>Reporter: Dirk Rudolph
>Priority: Major
>
> Adapting a {{SlingHttpServletRequest}} to a servlet that is registered using 
> sling.servlet.paths to a {{@Model}} fails in the following StackOverflowError:
> {code}
> java.lang.StackOverflowError: null
> ...
> at 
> org.apache.sling.models.impl.AdapterImplementations.getModelClassForResource(AdapterImplementations.java:318)
> at 
> org.apache.sling.models.impl.AdapterImplementations.getModelClassForResource(AdapterImplementations.java:322)
> at 
> org.apache.sling.models.impl.AdapterImplementations.getModelClassForResource(AdapterImplementations.java:322)
> {code}
> See for example the following pseudo code:
> {code}
> class MyServlet extends SlingSafeMethodsServlet {
>  doGet(request) { request.adaptTo(Model.class); }
> }
> interface Model {
>  ...
> }
> @Model(adaptables = SlingHttpServletRequest.class, adapters = 
> {ModelImpl.class, Model.class})
> class ModelImpl implements Model {
>  ...
> }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (SLING-7510) UriProvider throws unchecked IllegalArgumentException that must be handled by consumers

[Alexander Klimetschek (JIRA)]

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

Alexander Klimetschek updated SLING-7510:
-
Summary: UriProvider throws unchecked IllegalArgumentException that must be 
handled by consumers  (was: UriProvider should throw a checked exception 
instead of IllegalArgumentException)

> UriProvider throws unchecked IllegalArgumentException that must be handled by 
> consumers
> ---
>
> Key: SLING-7510
> URL: https://issues.apache.org/jira/browse/SLING-7510
> Project: Sling
>  Issue Type: Improvement
>  Components: API
>Affects Versions: API 2.16.4
>Reporter: Alexander Klimetschek
>Priority: Major
>
> h3. Status quo
> A consumer of the 
> [UriProvider|https://github.com/apache/sling-org-apache-sling-api/blob/dfc41640031bc87ec271c648b22073e65f4f171a/src/main/java/org/apache/sling/api/resource/external/URIProvider.java#L45]
>  currently is required to handle an unchecked {{IllegalArgumentException}}, 
> which is thrown when the provider is not able to handle the binary. Note that 
> it is not supposed to ever return null per the javadoc. The 
> [JcrNodeResource|https://github.com/apache/sling-org-apache-sling-jcr-resource/blob/0e2ebd0f1a5c7cb2044b2d754945eb0ee7641081/src/main/java/org/apache/sling/jcr/resource/internal/helper/jcr/JcrNodeResource.java#L233-L242]
>  shows a typical consumer code (although it still does do a null check).
> For the use case of asking multiple providers and taking the first one that 
> responds it's not an optimal pattern to rely on an unchecked exception for 
> the expected failure case that one provider by design cannot handle a certain 
> binary or request. Throwing an {{IllegalArgumentException}} if there is no 
> problem with the argument passed from the client, but a limit or 
> configuration setting of the provider, is misleading. Also, given there are 
> multiple providers active, a client cannot know upfront which provider is the 
> right one for a given binary and somehow prevent the "illegal argument" call 
> in the first place.
> h3. Suggestion
> Often, {{null}} return values are used in such a case. The provider can log 
> any possible useful information itself, on why it could not handle it, if 
> needed. This would simplify the consumer code (no try/catch necessary) and 
> remove unnecessary cost of exception handling for normal code paths. 
> JcrNodeResource itself it uses a null return value to pass on the "could not 
> retrieve anything" state to the upper layers.
> If the goal really is to use exceptions here, the API should add a 
> {{@Nonnull}} annotation for the return value _and_ the expected failure 
> exception should be a checked one such as a new {{UriProviderException}}. 
> Then for any unexpected faults (e.g. network error), it's fine to allow 
> providers to throw a unchecked runtime exception, and usually that's not 
> something that is explicitly mentioned in javadoc, but would definitely not 
> hurt.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (SLING-7510) UriProvider should throw a checked exception instead of IllegalArgumentException

[Alexander Klimetschek (JIRA)]

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

Alexander Klimetschek updated SLING-7510:
-
Description: 
h3. Status quo

A consumer of the 
[UriProvider|https://github.com/apache/sling-org-apache-sling-api/blob/dfc41640031bc87ec271c648b22073e65f4f171a/src/main/java/org/apache/sling/api/resource/external/URIProvider.java#L45]
 currently is required to handle an unchecked {{IllegalArgumentException}}, 
which is thrown when the provider is not able to handle the binary. Note that 
it is not supposed to ever return null per the javadoc. The 
[JcrNodeResource|https://github.com/apache/sling-org-apache-sling-jcr-resource/blob/0e2ebd0f1a5c7cb2044b2d754945eb0ee7641081/src/main/java/org/apache/sling/jcr/resource/internal/helper/jcr/JcrNodeResource.java#L233-L242]
 shows a typical consumer code (although it still does do a null check).

For the use case of asking multiple providers and taking the first one that 
responds it's not an optimal pattern to rely on an unchecked exception for the 
expected failure case that one provider by design cannot handle a certain 
binary or request. Throwing an {{IllegalArgumentException}} if there is no 
problem with the argument passed from the client, but a limit or configuration 
setting of the provider, is misleading. Also, given there are multiple 
providers active, a client cannot know upfront which provider is the right one 
for a given binary and somehow prevent the "illegal argument" call in the first 
place.
h3. Suggestion

Often, {{null}} return values are used in such a case. The provider can log any 
possible useful information itself, on why it could not handle it, if needed. 
This would simplify the consumer code (no try/catch necessary) and remove 
unnecessary cost of exception handling for normal code paths. JcrNodeResource 
itself it uses a null return value to pass on the "could not retrieve anything" 
state to the upper layers.

If the goal really is to use exceptions here, the API should add a {{@Nonnull}} 
annotation for the return value _and_ the expected failure exception should be 
a checked one such as a new {{UriProviderException}}. Then for any unexpected 
faults (e.g. network error), it's fine to allow providers to throw a unchecked 
runtime exception, and usually that's not something that is explicitly 
mentioned in javadoc, but would definitely not hurt.

  was:
h3. Status quo

A consumer of the 
[UriProvider|https://github.com/apache/sling-org-apache-sling-api/blob/dfc41640031bc87ec271c648b22073e65f4f171a/src/main/java/org/apache/sling/api/resource/external/URIProvider.java#L45]
 currently is required to handle an unchecked {{IllegalArgumentException}}, 
which is thrown when the provider is not able to handle the binary. Note that 
it is not supposed to ever return null per the javadoc. The 
[JcrNodeResource|https://github.com/apache/sling-org-apache-sling-jcr-resource/blob/0e2ebd0f1a5c7cb2044b2d754945eb0ee7641081/src/main/java/org/apache/sling/jcr/resource/internal/helper/jcr/JcrNodeResource.java#L233-L242]
 shows a typical consumer code (although it does do a null check).

For the use case of asking multiple providers and taking the first one that 
responds it's not an optimal pattern to rely on an unchecked exception for the 
expected failure case that one provider by design cannot handle a certain 
binary or request. Throwing an {{IllegalArgumentException}} if there is no 
problem with the argument passed from the client, but a limit or configuration 
setting of the provider, is misleading. Also, given there are multiple 
providers active, a client cannot know upfront which provider is the right one 
for a given binary and somehow prevent the "illegal argument" call in the first 
place.
h3. Suggestion

Often, {{null}} return values are used in such a case. The provider can log any 
possible useful information itself, on why it could not handle it, if needed. 
This would simplify the consumer code (no try/catch necessary) and remove 
unnecessary cost of exception handling for normal code paths. JcrNodeResource 
itself it uses a null return value to pass on the "could not retrieve anything" 
state to the upper layers.

If the goal really is to use exceptions here, the API should add a {{@Nonnull}} 
annotation for the return value _and_ the expected failure exception should be 
a checked one such as a new {{UriProviderException}}. Then for any unexpected 
faults (e.g. network error), it's fine to allow providers to throw a unchecked 
runtime exception, and usually that's not something that is explicitly 
mentioned in javadoc, but would definitely not hurt.


> UriProvider should throw a checked exception instead of 
> IllegalArgumentException
> 
>
> Key: SLING-7510
> URL: 

[jira] [Created] (SLING-7510) UriProvider should throw a checked exception instead of IllegalArgumentException

[Alexander Klimetschek (JIRA)]

Alexander Klimetschek created SLING-7510:


 Summary: UriProvider should throw a checked exception instead of 
IllegalArgumentException
 Key: SLING-7510
 URL: https://issues.apache.org/jira/browse/SLING-7510
 Project: Sling
  Issue Type: Improvement
  Components: API
Affects Versions: API 2.16.4
Reporter: Alexander Klimetschek


h3. Status quo

A consumer of the 
[UriProvider|https://github.com/apache/sling-org-apache-sling-api/blob/dfc41640031bc87ec271c648b22073e65f4f171a/src/main/java/org/apache/sling/api/resource/external/URIProvider.java#L45]
 currently is required to handle an unchecked {{IllegalArgumentException}}, 
which is thrown when the provider is not able to handle the binary. Note that 
it is not supposed to ever return null per the javadoc. The 
[JcrNodeResource|https://github.com/apache/sling-org-apache-sling-jcr-resource/blob/0e2ebd0f1a5c7cb2044b2d754945eb0ee7641081/src/main/java/org/apache/sling/jcr/resource/internal/helper/jcr/JcrNodeResource.java#L233-L242]
 shows a typical consumer code (although it does do a null check).

For the use case of asking multiple providers and taking the first one that 
responds it's not an optimal pattern to rely on an unchecked exception for the 
expected failure case that one provider by design cannot handle a certain 
binary or request. Throwing an {{IllegalArgumentException}} if there is no 
problem with the argument passed from the client, but a limit or configuration 
setting of the provider, is misleading. Also, given there are multiple 
providers active, a client cannot know upfront which provider is the right one 
for a given binary and somehow prevent the "illegal argument" call in the first 
place.
h3. Suggestion

Often, {{null}} return values are used in such a case. The provider can log any 
possible useful information itself, on why it could not handle it, if needed. 
This would simplify the consumer code (no try/catch necessary) and remove 
unnecessary cost of exception handling for normal code paths. JcrNodeResource 
itself it uses a null return value to pass on the "could not retrieve anything" 
state to the upper layers.

If the goal really is to use exceptions here, the API should add a {{@Nonnull}} 
annotation for the return value _and_ the expected failure exception should be 
a checked one such as a new {{UriProviderException}}. Then for any unexpected 
faults (e.g. network error), it's fine to allow providers to throw a unchecked 
runtime exception, and usually that's not something that is explicitly 
mentioned in javadoc, but would definitely not hurt.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (SLING-7509) Add QueryClient

[Valentin Olteanu (JIRA)]

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

Valentin Olteanu updated SLING-7509:

Description: 
Currently, there is no way to run queries in sling using the clients. This is 
needed in several tests to search content and assert the effects of a feature.

 

The solution proposed in 
[https://github.com/apache/sling-org-apache-sling-testing-clients/pull/5] 
 * installs a custom query servlet
 * runs the query in any of the supported format
 * returns results as json

  was:
Currently, there is no way to run queries in sling using the clients. This is 
needed in several tests to search content and assert the effects of a feature.

 

 


> Add QueryClient
> ---
>
> Key: SLING-7509
> URL: https://issues.apache.org/jira/browse/SLING-7509
> Project: Sling
>  Issue Type: New Feature
>  Components: Apache Sling Testing Clients
>Reporter: Valentin Olteanu
>Priority: Major
>
> Currently, there is no way to run queries in sling using the clients. This is 
> needed in several tests to search content and assert the effects of a feature.
>  
> The solution proposed in 
> [https://github.com/apache/sling-org-apache-sling-testing-clients/pull/5] 
>  * installs a custom query servlet
>  * runs the query in any of the supported format
>  * returns results as json



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SLING-7509) Add QueryClient

[ASF GitHub Bot (JIRA)]

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

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

volteanu opened a new pull request #5: SLING-7509 - Add QueryClient
URL: https://github.com/apache/sling-org-apache-sling-testing-clients/pull/5
 
 
   @dulvac @rombert could please review the new client?
   
   I'm not sure about the paths where content is created, should we use a 
`test` _namespace_ that can be easily identified and deleted?


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Add QueryClient
> ---
>
> Key: SLING-7509
> URL: https://issues.apache.org/jira/browse/SLING-7509
> Project: Sling
>  Issue Type: New Feature
>  Components: Apache Sling Testing Clients
>Reporter: Valentin Olteanu
>Priority: Major
>
> Currently, there is no way to run queries in sling using the clients. This is 
> needed in several tests to search content and assert the effects of a feature.
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] Buuhuu opened a new pull request #4: SLING-7508: fixed endless recursion getModelClassForResource()

[GitBox]

Buuhuu opened a new pull request #4: SLING-7508: fixed endless recursion 
getModelClassForResource()
URL: https://github.com/apache/sling-org-apache-sling-models-impl/pull/4
 
 
   check if the resourceTypeResource differs from the resource to prevent 
endless recursion


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[jira] [Commented] (SLING-7508) StackOverflowError adapting ServletResource to Sling Mode with impl picker

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph commented on SLING-7508:
-

To reproduce use the AdaptFromServletResourceRequestIT integration test in 
[SLING-7508-integration-test-for-endless-recursion|https://github.com/Buuhuu/sling-org-apache-sling-models-integration-tests/tree/SLING-7508-integration-test-for-endless-recursion]

> StackOverflowError adapting ServletResource to Sling Mode with impl picker
> --
>
> Key: SLING-7508
> URL: https://issues.apache.org/jira/browse/SLING-7508
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: Sling Models Impl 1.4.8
>Reporter: Dirk Rudolph
>Priority: Major
>
> Adapting a {{SlingHttpServletRequest}} to a servlet that is registered using 
> sling.servlet.paths to a {{@Model}} fails in the following StackOverflowError:
> {code}
> java.lang.StackOverflowError: null
> ...
> at 
> org.apache.sling.models.impl.AdapterImplementations.getModelClassForResource(AdapterImplementations.java:318)
> at 
> org.apache.sling.models.impl.AdapterImplementations.getModelClassForResource(AdapterImplementations.java:322)
> at 
> org.apache.sling.models.impl.AdapterImplementations.getModelClassForResource(AdapterImplementations.java:322)
> {code}
> See for example the following pseudo code:
> {code}
> class MyServlet extends SlingSafeMethodsServlet {
>  doGet(request) { request.adaptTo(Model.class); }
> }
> interface Model {
>  ...
> }
> @Model(adaptables = SlingHttpServletRequest.class, adapters = 
> {ModelImpl.class, Model.class})
> class ModelImpl implements Model {
>  ...
> }
> {code}
> See the example here: 
> https://github.com/Buuhuu/sling-org-apache-sling-models-integration-tests/commit/db174f7a8d43432e4445f4e0aa90487827f66f72



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (SLING-7508) StackOverflowError adapting ServletResource to Sling Model with impl picker

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph updated SLING-7508:

Affects Version/s: (was: Sling Models Impl 1.4.8)

> StackOverflowError adapting ServletResource to Sling Model with impl picker
> ---
>
> Key: SLING-7508
> URL: https://issues.apache.org/jira/browse/SLING-7508
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: Sling Models Impl 1.4.2
>Reporter: Dirk Rudolph
>Priority: Major
>
> Adapting a {{SlingHttpServletRequest}} to a servlet that is registered using 
> sling.servlet.paths to a {{@Model}} fails in the following StackOverflowError:
> {code}
> java.lang.StackOverflowError: null
> ...
> at 
> org.apache.sling.models.impl.AdapterImplementations.getModelClassForResource(AdapterImplementations.java:318)
> at 
> org.apache.sling.models.impl.AdapterImplementations.getModelClassForResource(AdapterImplementations.java:322)
> at 
> org.apache.sling.models.impl.AdapterImplementations.getModelClassForResource(AdapterImplementations.java:322)
> {code}
> See for example the following pseudo code:
> {code}
> @SlingServlet(paths = "/apps/mypath")
> class MyServlet extends SlingSafeMethodsServlet {
>  doGet(request) { request.adaptTo(Model.class); }
> }
> interface Model {
>  ...
> }
> @Model(adaptables = SlingHttpServletRequest.class, adapters = 
> {ModelImpl.class, Model.class})
> class ModelImpl implements Model {
>  ...
> }
> {code}
> See the example here: 
> https://github.com/Buuhuu/sling-org-apache-sling-models-integration-tests/commit/db174f7a8d43432e4445f4e0aa90487827f66f72



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (SLING-7509) Add QueryClient

[Valentin Olteanu (JIRA)]

Valentin Olteanu created SLING-7509:
---

 Summary: Add QueryClient
 Key: SLING-7509
 URL: https://issues.apache.org/jira/browse/SLING-7509
 Project: Sling
  Issue Type: New Feature
  Components: Apache Sling Testing Clients
Reporter: Valentin Olteanu


Currently, there is no way to run queries in sling using the clients. This is 
needed in several tests to search content and assert the effects of a feature.

 

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (SLING-7508) StackOverflowError adapting ServletResource to Sling Mode with impl picker

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph updated SLING-7508:

Affects Version/s: Sling Models Impl 1.4.8
  Description: 
Adapting a {{SlingHttpServletRequest}} to a servlet that is registered using 
sling.servlet.paths to a {{@Model}} fails in the following StackOverflowError:

{code}
java.lang.StackOverflowError: null
...
at 
org.apache.sling.models.impl.AdapterImplementations.getModelClassForResource(AdapterImplementations.java:318)
at 
org.apache.sling.models.impl.AdapterImplementations.getModelClassForResource(AdapterImplementations.java:322)
at 
org.apache.sling.models.impl.AdapterImplementations.getModelClassForResource(AdapterImplementations.java:322)
{code}

See for example the following pseudo code:

{code}
class MyServlet extends SlingSafeMethodsServlet {
 doGet(request) { request.adaptTo(Model.class); }
}

interface Model {
 ...
}

@Model(adaptables = SlingHttpServletRequest.class, adapters = {ModelImpl.class, 
Model.class})
class ModelImpl implements Model {
 ...
}
{code}
  Component/s: Extensions
  Summary: StackOverflowError adapting ServletResource to Sling 
Mode with impl picker  (was: StackOverflowError adapting ServletResource to 
Sling Mode with imp )

> StackOverflowError adapting ServletResource to Sling Mode with impl picker
> --
>
> Key: SLING-7508
> URL: https://issues.apache.org/jira/browse/SLING-7508
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: Sling Models Impl 1.4.8
>Reporter: Dirk Rudolph
>Priority: Major
>
> Adapting a {{SlingHttpServletRequest}} to a servlet that is registered using 
> sling.servlet.paths to a {{@Model}} fails in the following StackOverflowError:
> {code}
> java.lang.StackOverflowError: null
> ...
> at 
> org.apache.sling.models.impl.AdapterImplementations.getModelClassForResource(AdapterImplementations.java:318)
> at 
> org.apache.sling.models.impl.AdapterImplementations.getModelClassForResource(AdapterImplementations.java:322)
> at 
> org.apache.sling.models.impl.AdapterImplementations.getModelClassForResource(AdapterImplementations.java:322)
> {code}
> See for example the following pseudo code:
> {code}
> class MyServlet extends SlingSafeMethodsServlet {
>  doGet(request) { request.adaptTo(Model.class); }
> }
> interface Model {
>  ...
> }
> @Model(adaptables = SlingHttpServletRequest.class, adapters = 
> {ModelImpl.class, Model.class})
> class ModelImpl implements Model {
>  ...
> }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (SLING-7508) StackOverflowError adapting ServletResource to Sling Model with impl picker

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph updated SLING-7508:

Affects Version/s: Sling Models Impl 1.4.2

> StackOverflowError adapting ServletResource to Sling Model with impl picker
> ---
>
> Key: SLING-7508
> URL: https://issues.apache.org/jira/browse/SLING-7508
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: Sling Models Impl 1.4.2, Sling Models Impl 1.4.8
>Reporter: Dirk Rudolph
>Priority: Major
>
> Adapting a {{SlingHttpServletRequest}} to a servlet that is registered using 
> sling.servlet.paths to a {{@Model}} fails in the following StackOverflowError:
> {code}
> java.lang.StackOverflowError: null
> ...
> at 
> org.apache.sling.models.impl.AdapterImplementations.getModelClassForResource(AdapterImplementations.java:318)
> at 
> org.apache.sling.models.impl.AdapterImplementations.getModelClassForResource(AdapterImplementations.java:322)
> at 
> org.apache.sling.models.impl.AdapterImplementations.getModelClassForResource(AdapterImplementations.java:322)
> {code}
> See for example the following pseudo code:
> {code}
> @SlingServlet(paths = "/apps/mypath")
> class MyServlet extends SlingSafeMethodsServlet {
>  doGet(request) { request.adaptTo(Model.class); }
> }
> interface Model {
>  ...
> }
> @Model(adaptables = SlingHttpServletRequest.class, adapters = 
> {ModelImpl.class, Model.class})
> class ModelImpl implements Model {
>  ...
> }
> {code}
> See the example here: 
> https://github.com/Buuhuu/sling-org-apache-sling-models-integration-tests/commit/db174f7a8d43432e4445f4e0aa90487827f66f72



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (SLING-7508) StackOverflowError adapting ServletResource to Sling Mode with impl picker

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph updated SLING-7508:

Description: 
Adapting a {{SlingHttpServletRequest}} to a servlet that is registered using 
sling.servlet.paths to a {{@Model}} fails in the following StackOverflowError:

{code}
java.lang.StackOverflowError: null
...
at 
org.apache.sling.models.impl.AdapterImplementations.getModelClassForResource(AdapterImplementations.java:318)
at 
org.apache.sling.models.impl.AdapterImplementations.getModelClassForResource(AdapterImplementations.java:322)
at 
org.apache.sling.models.impl.AdapterImplementations.getModelClassForResource(AdapterImplementations.java:322)
{code}

See for example the following pseudo code:

{code}
@SlingServlet(paths = "/apps/mypath")
class MyServlet extends SlingSafeMethodsServlet {
 doGet(request) { request.adaptTo(Model.class); }
}

interface Model {
 ...
}

@Model(adaptables = SlingHttpServletRequest.class, adapters = {ModelImpl.class, 
Model.class})
class ModelImpl implements Model {
 ...
}
{code}

See the example here: 
https://github.com/Buuhuu/sling-org-apache-sling-models-integration-tests/commit/db174f7a8d43432e4445f4e0aa90487827f66f72

  was:
Adapting a {{SlingHttpServletRequest}} to a servlet that is registered using 
sling.servlet.paths to a {{@Model}} fails in the following StackOverflowError:

{code}
java.lang.StackOverflowError: null
...
at 
org.apache.sling.models.impl.AdapterImplementations.getModelClassForResource(AdapterImplementations.java:318)
at 
org.apache.sling.models.impl.AdapterImplementations.getModelClassForResource(AdapterImplementations.java:322)
at 
org.apache.sling.models.impl.AdapterImplementations.getModelClassForResource(AdapterImplementations.java:322)
{code}

See for example the following pseudo code:

{code}
class MyServlet extends SlingSafeMethodsServlet {
 doGet(request) { request.adaptTo(Model.class); }
}

interface Model {
 ...
}

@Model(adaptables = SlingHttpServletRequest.class, adapters = {ModelImpl.class, 
Model.class})
class ModelImpl implements Model {
 ...
}
{code}

See the example here: 
https://github.com/Buuhuu/sling-org-apache-sling-models-integration-tests/commit/db174f7a8d43432e4445f4e0aa90487827f66f72


> StackOverflowError adapting ServletResource to Sling Mode with impl picker
> --
>
> Key: SLING-7508
> URL: https://issues.apache.org/jira/browse/SLING-7508
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: Sling Models Impl 1.4.8
>Reporter: Dirk Rudolph
>Priority: Major
>
> Adapting a {{SlingHttpServletRequest}} to a servlet that is registered using 
> sling.servlet.paths to a {{@Model}} fails in the following StackOverflowError:
> {code}
> java.lang.StackOverflowError: null
> ...
> at 
> org.apache.sling.models.impl.AdapterImplementations.getModelClassForResource(AdapterImplementations.java:318)
> at 
> org.apache.sling.models.impl.AdapterImplementations.getModelClassForResource(AdapterImplementations.java:322)
> at 
> org.apache.sling.models.impl.AdapterImplementations.getModelClassForResource(AdapterImplementations.java:322)
> {code}
> See for example the following pseudo code:
> {code}
> @SlingServlet(paths = "/apps/mypath")
> class MyServlet extends SlingSafeMethodsServlet {
>  doGet(request) { request.adaptTo(Model.class); }
> }
> interface Model {
>  ...
> }
> @Model(adaptables = SlingHttpServletRequest.class, adapters = 
> {ModelImpl.class, Model.class})
> class ModelImpl implements Model {
>  ...
> }
> {code}
> See the example here: 
> https://github.com/Buuhuu/sling-org-apache-sling-models-integration-tests/commit/db174f7a8d43432e4445f4e0aa90487827f66f72



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SLING-7508) StackOverflowError adapting ServletResource to Sling Model with impl picker

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph commented on SLING-7508:
-

The smartes that came to my mind to resolve that is checking if the 
resourceTypeResource is not the same as the resource before stepping further 
into the recursion. Equality is checked based on the resources' path.

> StackOverflowError adapting ServletResource to Sling Model with impl picker
> ---
>
> Key: SLING-7508
> URL: https://issues.apache.org/jira/browse/SLING-7508
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: Sling Models Impl 1.4.8
>Reporter: Dirk Rudolph
>Priority: Major
>
> Adapting a {{SlingHttpServletRequest}} to a servlet that is registered using 
> sling.servlet.paths to a {{@Model}} fails in the following StackOverflowError:
> {code}
> java.lang.StackOverflowError: null
> ...
> at 
> org.apache.sling.models.impl.AdapterImplementations.getModelClassForResource(AdapterImplementations.java:318)
> at 
> org.apache.sling.models.impl.AdapterImplementations.getModelClassForResource(AdapterImplementations.java:322)
> at 
> org.apache.sling.models.impl.AdapterImplementations.getModelClassForResource(AdapterImplementations.java:322)
> {code}
> See for example the following pseudo code:
> {code}
> @SlingServlet(paths = "/apps/mypath")
> class MyServlet extends SlingSafeMethodsServlet {
>  doGet(request) { request.adaptTo(Model.class); }
> }
> interface Model {
>  ...
> }
> @Model(adaptables = SlingHttpServletRequest.class, adapters = 
> {ModelImpl.class, Model.class})
> class ModelImpl implements Model {
>  ...
> }
> {code}
> See the example here: 
> https://github.com/Buuhuu/sling-org-apache-sling-models-integration-tests/commit/db174f7a8d43432e4445f4e0aa90487827f66f72



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SLING-7508) StackOverflowError adapting ServletResource to Sling Model with impl picker

[ASF GitHub Bot (JIRA)]

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

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

Buuhuu opened a new pull request #4: SLING-7508: fixed endless recursion 
getModelClassForResource()
URL: https://github.com/apache/sling-org-apache-sling-models-impl/pull/4
 
 
   check if the resourceTypeResource differs from the resource to prevent 
endless recursion


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> StackOverflowError adapting ServletResource to Sling Model with impl picker
> ---
>
> Key: SLING-7508
> URL: https://issues.apache.org/jira/browse/SLING-7508
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: Sling Models Impl 1.4.8
>Reporter: Dirk Rudolph
>Priority: Major
>
> Adapting a {{SlingHttpServletRequest}} to a servlet that is registered using 
> sling.servlet.paths to a {{@Model}} fails in the following StackOverflowError:
> {code}
> java.lang.StackOverflowError: null
> ...
> at 
> org.apache.sling.models.impl.AdapterImplementations.getModelClassForResource(AdapterImplementations.java:318)
> at 
> org.apache.sling.models.impl.AdapterImplementations.getModelClassForResource(AdapterImplementations.java:322)
> at 
> org.apache.sling.models.impl.AdapterImplementations.getModelClassForResource(AdapterImplementations.java:322)
> {code}
> See for example the following pseudo code:
> {code}
> @SlingServlet(paths = "/apps/mypath")
> class MyServlet extends SlingSafeMethodsServlet {
>  doGet(request) { request.adaptTo(Model.class); }
> }
> interface Model {
>  ...
> }
> @Model(adaptables = SlingHttpServletRequest.class, adapters = 
> {ModelImpl.class, Model.class})
> class ModelImpl implements Model {
>  ...
> }
> {code}
> See the example here: 
> https://github.com/Buuhuu/sling-org-apache-sling-models-integration-tests/commit/db174f7a8d43432e4445f4e0aa90487827f66f72



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (SLING-7508) StackOverflowError adapting ServletResource to Sling Model with impl picker

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph updated SLING-7508:

Summary: StackOverflowError adapting ServletResource to Sling Model with 
impl picker  (was: StackOverflowError adapting ServletResource to Sling Mode 
with impl picker)

> StackOverflowError adapting ServletResource to Sling Model with impl picker
> ---
>
> Key: SLING-7508
> URL: https://issues.apache.org/jira/browse/SLING-7508
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: Sling Models Impl 1.4.8
>Reporter: Dirk Rudolph
>Priority: Major
>
> Adapting a {{SlingHttpServletRequest}} to a servlet that is registered using 
> sling.servlet.paths to a {{@Model}} fails in the following StackOverflowError:
> {code}
> java.lang.StackOverflowError: null
> ...
> at 
> org.apache.sling.models.impl.AdapterImplementations.getModelClassForResource(AdapterImplementations.java:318)
> at 
> org.apache.sling.models.impl.AdapterImplementations.getModelClassForResource(AdapterImplementations.java:322)
> at 
> org.apache.sling.models.impl.AdapterImplementations.getModelClassForResource(AdapterImplementations.java:322)
> {code}
> See for example the following pseudo code:
> {code}
> @SlingServlet(paths = "/apps/mypath")
> class MyServlet extends SlingSafeMethodsServlet {
>  doGet(request) { request.adaptTo(Model.class); }
> }
> interface Model {
>  ...
> }
> @Model(adaptables = SlingHttpServletRequest.class, adapters = 
> {ModelImpl.class, Model.class})
> class ModelImpl implements Model {
>  ...
> }
> {code}
> See the example here: 
> https://github.com/Buuhuu/sling-org-apache-sling-models-integration-tests/commit/db174f7a8d43432e4445f4e0aa90487827f66f72



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (SLING-7508) StackOverflowError adapting ServletResource to Sling Mode with impl picker

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph updated SLING-7508:

Description: 
Adapting a {{SlingHttpServletRequest}} to a servlet that is registered using 
sling.servlet.paths to a {{@Model}} fails in the following StackOverflowError:

{code}
java.lang.StackOverflowError: null
...
at 
org.apache.sling.models.impl.AdapterImplementations.getModelClassForResource(AdapterImplementations.java:318)
at 
org.apache.sling.models.impl.AdapterImplementations.getModelClassForResource(AdapterImplementations.java:322)
at 
org.apache.sling.models.impl.AdapterImplementations.getModelClassForResource(AdapterImplementations.java:322)
{code}

See for example the following pseudo code:

{code}
class MyServlet extends SlingSafeMethodsServlet {
 doGet(request) { request.adaptTo(Model.class); }
}

interface Model {
 ...
}

@Model(adaptables = SlingHttpServletRequest.class, adapters = {ModelImpl.class, 
Model.class})
class ModelImpl implements Model {
 ...
}
{code}

See the example here: 
https://github.com/Buuhuu/sling-org-apache-sling-models-integration-tests/commit/db174f7a8d43432e4445f4e0aa90487827f66f72

  was:
Adapting a {{SlingHttpServletRequest}} to a servlet that is registered using 
sling.servlet.paths to a {{@Model}} fails in the following StackOverflowError:

{code}
java.lang.StackOverflowError: null
...
at 
org.apache.sling.models.impl.AdapterImplementations.getModelClassForResource(AdapterImplementations.java:318)
at 
org.apache.sling.models.impl.AdapterImplementations.getModelClassForResource(AdapterImplementations.java:322)
at 
org.apache.sling.models.impl.AdapterImplementations.getModelClassForResource(AdapterImplementations.java:322)
{code}

See for example the following pseudo code:

{code}
class MyServlet extends SlingSafeMethodsServlet {
 doGet(request) { request.adaptTo(Model.class); }
}

interface Model {
 ...
}

@Model(adaptables = SlingHttpServletRequest.class, adapters = {ModelImpl.class, 
Model.class})
class ModelImpl implements Model {
 ...
}
{code}


> StackOverflowError adapting ServletResource to Sling Mode with impl picker
> --
>
> Key: SLING-7508
> URL: https://issues.apache.org/jira/browse/SLING-7508
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: Sling Models Impl 1.4.8
>Reporter: Dirk Rudolph
>Priority: Major
>
> Adapting a {{SlingHttpServletRequest}} to a servlet that is registered using 
> sling.servlet.paths to a {{@Model}} fails in the following StackOverflowError:
> {code}
> java.lang.StackOverflowError: null
> ...
> at 
> org.apache.sling.models.impl.AdapterImplementations.getModelClassForResource(AdapterImplementations.java:318)
> at 
> org.apache.sling.models.impl.AdapterImplementations.getModelClassForResource(AdapterImplementations.java:322)
> at 
> org.apache.sling.models.impl.AdapterImplementations.getModelClassForResource(AdapterImplementations.java:322)
> {code}
> See for example the following pseudo code:
> {code}
> class MyServlet extends SlingSafeMethodsServlet {
>  doGet(request) { request.adaptTo(Model.class); }
> }
> interface Model {
>  ...
> }
> @Model(adaptables = SlingHttpServletRequest.class, adapters = 
> {ModelImpl.class, Model.class})
> class ModelImpl implements Model {
>  ...
> }
> {code}
> See the example here: 
> https://github.com/Buuhuu/sling-org-apache-sling-models-integration-tests/commit/db174f7a8d43432e4445f4e0aa90487827f66f72



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (SLING-7508) StackOverflowError adapting ServletResource to Sling Mode with imp

[Dirk Rudolph (JIRA)]

Dirk Rudolph created SLING-7508:
---

 Summary: StackOverflowError adapting ServletResource to Sling Mode 
with imp 
 Key: SLING-7508
 URL: https://issues.apache.org/jira/browse/SLING-7508
 Project: Sling
  Issue Type: Bug
Reporter: Dirk Rudolph






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [Sling Feature Model] Expanded requirements

[Dominik Süß]

Good point - I just had to think of star imports that make it impossible to
declare the dependency vector purely based on the metadata

Cheers
Dominik

Oliver Lietz  schrieb am Mi. 21. Feb. 2018 um 16:07:

> On Tuesday 20 February 2018 16:48:08 David Bosschaert wrote:
> > Hi all,
>
> Hi David,
>
> > Over the recent past some additions have been made to the requirements of
> > the Sling Feature Model. The updated requirements can be found here:
> >
> https://github.com/apache/sling-whiteboard/blob/master/featuremodel/readme.m
> > d
> >
> > Any additional requirements, let us know!
>
> the readme says in section "Requirements and Capabilities of Artifacts":
>
> "The feature model does not allow to explicitly list requirements or
> capabilities for artifacts. An artifact, for example a bundle, contains
> this
> information as part of its metadata."
>
> Some bundles (from Sling and Oak also) do not provide proper metadata and
> it
> would be quite useful to add missing capabilities in the model until the
> artifacts are fixed (if that ever happens).
>
> Regards,
> O.
>
> > I'm hoping to start contributing to the implementation of some of these
> in
> > the near term and was wondering - is there a reason why the feature model
> > still in the sling-whiteboard? Or would it make sense to put it in its
> own
> > Sling git repo or repos?
> >
> > Best regards,
> >
> > David
>
>

FINAL REMINDER: CFP for Apache EU Roadshow Closes 25th February

[Sharan F]

Hello Apache Supporters and Enthusiasts

This is your FINAL reminder that the Call for Papers (CFP) for the 
Apache EU Roadshow is closing soon. Our Apache EU Roadshow will focus on 
Cloud, IoT, Apache Tomcat, Apache Http and will run from 13-14 June 2018 
in Berlin.
Note that the CFP deadline has been extended to *25*^*th* *February *and 
it will be your final opportunity to submit a talk for thisevent.


Please make your submissions at http://apachecon.com/euroadshow18/

Also note that early bird ticket registrations to attend FOSS Backstage 
including the Apache EU Roadshow, have also been extended and will be 
available until 23^rd February. Please register at 
https://foss-backstage.de/tickets


We look forward to seeing you in Berlin!

Thanks
Sharan Foga, VP Apache Community Development

PLEASE NOTE: You are receiving this message because you are subscribed 
to a user@ or dev@ list of one or more Apache Software Foundation projects.

Re: repoinit just with oak

[Bertrand Delacretaz]

Hi,

On Wed, Feb 21, 2018 at 2:47 PM, Ioan Eugen Stan  wrote:
> ...I saw that I need to implement
> |SlingRepositoryInitializer that brings in Sling API, which I shouldn't
> need

I think you can bypass that requirement. If you look at the
RepositoryInitializer.processRepository method [1] the gist is parsing
the statements and using JcrRepoInitOpsProcessor to process the
result.

However, as running outside of Sling hasn't been a requirement so far,
I suppose there might be non-essential dependencies that get in the
way of doing that, but depending on your environment they might not
matter, maybe you just won't be able to use certain non-essential
classes.

The alternative is to extract the pure JCR parts out of the jcr
repoinit bundle, if you need that I think that would be a useful
contribution.

You're right that technically the JCR parts of this belong to the Oak
level, but as it's the Sling community which needed that the modules
have been created here for convenience.

-Bertrand

[1] 
https://github.com/apache/sling-org-apache-sling-jcr-repoinit/blob/master/src/main/java/org/apache/sling/jcr/repoinit/impl/RepositoryInitializer.java

Re: [Sling Feature Model] Expanded requirements

[Oliver Lietz]

On Tuesday 20 February 2018 16:48:08 David Bosschaert wrote:
> Hi all,

Hi David,

> Over the recent past some additions have been made to the requirements of
> the Sling Feature Model. The updated requirements can be found here:
> https://github.com/apache/sling-whiteboard/blob/master/featuremodel/readme.m
> d
> 
> Any additional requirements, let us know!

the readme says in section "Requirements and Capabilities of Artifacts":

"The feature model does not allow to explicitly list requirements or 
capabilities for artifacts. An artifact, for example a bundle, contains this 
information as part of its metadata."

Some bundles (from Sling and Oak also) do not provide proper metadata and it 
would be quite useful to add missing capabilities in the model until the 
artifacts are fixed (if that ever happens).

Regards,
O.

> I'm hoping to start contributing to the implementation of some of these in
> the near term and was wondering - is there a reason why the feature model
> still in the sling-whiteboard? Or would it make sense to put it in its own
> Sling git repo or repos?
> 
> Best regards,
> 
> David

Re: repoinit just with oak

[Ioan Eugen Stan]

I've sent this by mistake to sling-dev instead of sling-users.

Sorry. I will re-post on Sling users, please ignore the message.


On 21.02.2018 15:47, Ioan Eugen Stan wrote:
> Hello,
>
> I've been looking for a way to initialize an Oak repository and I came
> across repoinit module [1].
>
> However, I'm using Oak outside of OSGI and I don't need all of Sling.
>
> Is that a use case that can be handled easily? If yes, I'll investigate
> and put up some documentation.
>
> Looking at the documentation, it seems to me that in theory it should be
> possible, however I saw that I need to implement
> |SlingRepositoryInitializer that brings in Sling API, which I shouldn't
> need.|
>
> To me repoinit language is similar to how SQL migrations are done and
> IMO that is a responsibility of the content store, not the web app
> especially since the store can be used by more then one micro service.
>
> |The application that uses Oak repo is not a web application and neither
> OSGI, and it will cost us to migrate so that is not an option.
> |
>
>
> Regards,
>
> Eugen
>
>
> [1]
> https://sling.apache.org/documentation/bundles/repository-initialization.html
>
>
>
>




signature.asc
Description: OpenPGP digital signature

repoinit just with oak

[Ioan Eugen Stan]

Hello,

I've been looking for a way to initialize an Oak repository and I came
across repoinit module [1].

However, I'm using Oak outside of OSGI and I don't need all of Sling.

Is that a use case that can be handled easily? If yes, I'll investigate
and put up some documentation.

Looking at the documentation, it seems to me that in theory it should be
possible, however I saw that I need to implement
|SlingRepositoryInitializer that brings in Sling API, which I shouldn't
need.|

To me repoinit language is similar to how SQL migrations are done and
IMO that is a responsibility of the content store, not the web app
especially since the store can be used by more then one micro service.

|The application that uses Oak repo is not a web application and neither
OSGI, and it will cost us to migrate so that is not an option.
|


Regards,

Eugen


[1]
https://sling.apache.org/documentation/bundles/repository-initialization.html






signature.asc
Description: OpenPGP digital signature

[jira] [Resolved] (SLING-7267) Update commons johnzon to johnzon 1.1.4 and make it work with java7

[Karl Pauls (JIRA)]

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

Karl Pauls resolved SLING-7267.
---
   Resolution: Won't Fix
Fix Version/s: (was: Commons Johnzon 1.1.4)

I agree.

> Update commons johnzon to johnzon 1.1.4 and make it work with java7
> ---
>
> Key: SLING-7267
> URL: https://issues.apache.org/jira/browse/SLING-7267
> Project: Sling
>  Issue Type: Improvement
>  Components: Commons
>Affects Versions: Commons Johnzon 1.1.0
>Reporter: Karl Pauls
>Assignee: Karl Pauls
>Priority: Major
>
> We should update to the latest johnzon 1.1.4 and while we are at it, we 
> should fork that source code and make it work with java7 to be able to use 
> commons.johnzon on java7.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SLING-7507) Tracker open to early which can cause a NPE.

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-7507:
-

Lgtm, thanks

> Tracker open to early which can cause a NPE.
> 
>
> Key: SLING-7507
> URL: https://issues.apache.org/jira/browse/SLING-7507
> Project: Sling
>  Issue Type: Bug
>  Components: Commons
>Affects Versions: Commons Log 5.1.0
>Reporter: Karl Pauls
>Priority: Major
> Fix For: Commons Log 5.1.2
>
>
> The FilterTracker and TurboFilterTracker service tracker are opened in the 
> constructor of the LogbackManager at a time when it isn't fully configured 
> yet. That can lead to an NPE if there is a service found right away.  
> {code:java}
> Caused by: java.lang.NullPointerException: null
> at 
> org.apache.sling.commons.log.logback.internal.LogbackManager$LoggerStateContext.(LogbackManager.java:733)
> at 
> org.apache.sling.commons.log.logback.internal.LogbackManager.determineLoggerState(LogbackManager.java:663)
> at 
> org.apache.sling.commons.log.logback.internal.FilterTracker.getAppenderMap(FilterTracker.java:173)
> at 
> org.apache.sling.commons.log.logback.internal.FilterTracker.addingService(FilterTracker.java:67)
> at 
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:941)
> at 
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:870)
> at 
> org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256)
> at 
> org.osgi.util.tracker.AbstractTracked.trackInitial(AbstractTracked.java:183)
> at org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:318)
> at org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:261)
> at 
> org.apache.sling.commons.log.logback.internal.FilterTracker.(FilterTracker.java:55)
> at 
> org.apache.sling.commons.log.logback.internal.LogbackManager.(LogbackManager.java:153)
> at 
> org.apache.sling.commons.log.logback.internal.Activator.initializeLogbackManager(Activator.java:75)
> at 
> org.apache.sling.commons.log.logback.internal.Activator.start(Activator.java:55)
> at 
> org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:697)
> at org.apache.felix.framework.Felix.activateBundle(Felix.java:2240)
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SLING-7507) Tracker open to early which can cause a NPE.

[ASF GitHub Bot (JIRA)]

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

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

karlpauls closed pull request #2: SLING-7507: open the service tracker when the 
LogbackManager is inita…
URL: https://github.com/apache/sling-org-apache-sling-commons-log/pull/2
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Tracker open to early which can cause a NPE.
> 
>
> Key: SLING-7507
> URL: https://issues.apache.org/jira/browse/SLING-7507
> Project: Sling
>  Issue Type: Bug
>  Components: Commons
>Affects Versions: Commons Log 5.1.0
>Reporter: Karl Pauls
>Priority: Major
> Fix For: Commons Log 5.1.2
>
>
> The FilterTracker and TurboFilterTracker service tracker are opened in the 
> constructor of the LogbackManager at a time when it isn't fully configured 
> yet. That can lead to an NPE if there is a service found right away.  
> {code:java}
> Caused by: java.lang.NullPointerException: null
> at 
> org.apache.sling.commons.log.logback.internal.LogbackManager$LoggerStateContext.(LogbackManager.java:733)
> at 
> org.apache.sling.commons.log.logback.internal.LogbackManager.determineLoggerState(LogbackManager.java:663)
> at 
> org.apache.sling.commons.log.logback.internal.FilterTracker.getAppenderMap(FilterTracker.java:173)
> at 
> org.apache.sling.commons.log.logback.internal.FilterTracker.addingService(FilterTracker.java:67)
> at 
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:941)
> at 
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:870)
> at 
> org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256)
> at 
> org.osgi.util.tracker.AbstractTracked.trackInitial(AbstractTracked.java:183)
> at org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:318)
> at org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:261)
> at 
> org.apache.sling.commons.log.logback.internal.FilterTracker.(FilterTracker.java:55)
> at 
> org.apache.sling.commons.log.logback.internal.LogbackManager.(LogbackManager.java:153)
> at 
> org.apache.sling.commons.log.logback.internal.Activator.initializeLogbackManager(Activator.java:75)
> at 
> org.apache.sling.commons.log.logback.internal.Activator.start(Activator.java:55)
> at 
> org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:697)
> at org.apache.felix.framework.Felix.activateBundle(Felix.java:2240)
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (SLING-7507) Tracker open to early which can cause a NPE.

[Karl Pauls (JIRA)]

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

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

> Tracker open to early which can cause a NPE.
> 
>
> Key: SLING-7507
> URL: https://issues.apache.org/jira/browse/SLING-7507
> Project: Sling
>  Issue Type: Bug
>  Components: Commons
>Affects Versions: Commons Log 5.1.0
>Reporter: Karl Pauls
>Priority: Major
> Fix For: Commons Log 5.1.2
>
>
> The FilterTracker and TurboFilterTracker service tracker are opened in the 
> constructor of the LogbackManager at a time when it isn't fully configured 
> yet. That can lead to an NPE if there is a service found right away.  
> {code:java}
> Caused by: java.lang.NullPointerException: null
> at 
> org.apache.sling.commons.log.logback.internal.LogbackManager$LoggerStateContext.(LogbackManager.java:733)
> at 
> org.apache.sling.commons.log.logback.internal.LogbackManager.determineLoggerState(LogbackManager.java:663)
> at 
> org.apache.sling.commons.log.logback.internal.FilterTracker.getAppenderMap(FilterTracker.java:173)
> at 
> org.apache.sling.commons.log.logback.internal.FilterTracker.addingService(FilterTracker.java:67)
> at 
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:941)
> at 
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:870)
> at 
> org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256)
> at 
> org.osgi.util.tracker.AbstractTracked.trackInitial(AbstractTracked.java:183)
> at org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:318)
> at org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:261)
> at 
> org.apache.sling.commons.log.logback.internal.FilterTracker.(FilterTracker.java:55)
> at 
> org.apache.sling.commons.log.logback.internal.LogbackManager.(LogbackManager.java:153)
> at 
> org.apache.sling.commons.log.logback.internal.Activator.initializeLogbackManager(Activator.java:75)
> at 
> org.apache.sling.commons.log.logback.internal.Activator.start(Activator.java:55)
> at 
> org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:697)
> at org.apache.felix.framework.Felix.activateBundle(Felix.java:2240)
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] karlpauls closed pull request #2: SLING-7507: open the service tracker when the LogbackManager is inita?

[GitBox]

karlpauls closed pull request #2: SLING-7507: open the service tracker when the 
LogbackManager is inita?
URL: https://github.com/apache/sling-org-apache-sling-commons-log/pull/2
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

Re: [Sling Feature Model] Expanded requirements

[Carsten Ziegeler]

Hi,

good point, makes sense. We'll update the document

Thanks

Carsten


Ioan Eugen Stan wrote
> Hi,
> 
> Thank you both for the clarification. I think it is a reasonable approach.
> 
> It's always best to validate specs with one or more implementations.
> 
> Then I propose that in the interest of greater adoption, maybe a name
> change is in order.
> 
> Something that says: we install osgi packages and we are used by Sling
> instead of having Sling in the name and inducing the idea of being Sling
> specific or worst, Sling only.
> 
> Thank you,
> 
> On 21.02.2018 12:59, Carsten Ziegeler wrote:
>> Hi,
>>
>> thanks! One major point of the feature model is to separate between the
>> model and how it is used later on. All current existing approaches mix
>> these two things in most cases.
>>
>> There is a lot of overlap with the Karaf feature model, but the idea is
>> to get a common model that works for everyone and as David pointed out
>> potentially creating an OSGi spec out of this. So the model should work
>> for Karaf users, for people creating sub systems etc.
>>
>> In fact, the prototype we have in our whiteboard creates a Karaf kar
>> file out of a feature which can then easily be used within Karaf. But
>> that's just one way doing it
>>
>> Regards
>>
>> Carsten
>>
>>
>> Ioan Eugen Stan wrote
>>> Hi,
>>>
>>> I've looked on the specification and I've noticed that it also overlaps
>>> with the Karaf Feature functionality.
>>>
>>> Is there any relation between the two? Is there collaboration between
>>> the projects?
>>>
>>> As a user/consumer of technology I enjoy when technologies are
>>> compatible and the tooling support is great.
>>>
>>> I believe collaboration in this area is beneficial. I would like to be
>>> able to provision Sling features in Karaf and Karaf features in Sling
>>> with ease.
>>>
>>> If you put the spec side by side they share a LOT of things, but there
>>> are also some minor differences, like file format. Karaf uses XML which
>>> has much better tooling support IMO, but this is a persistence format
>>> and can be easily changed.
>>>
>>>
>>> p.s. I like the spec, I imagine it took quite some time to write. Kudos !
>>>
>>> Regards,
>>>
>>> [1] https://karaf.apache.org/manual/latest/provisioning
>>>
>>>
>>>
>>> On 21.02.2018 09:10, Carsten Ziegeler wrote:
 Thanks David

 We're neither 100% clear on the requirements nor on the structure,
 meaning we don't know how many and what modules this will be. As we're
 following the one module per git repo rule, it's currently impossible to
 create the correct git repositories. And I guess it doesn't make sense
 to rename them or remove them every now and then.

 As the collaboration with the whiteboard is the same as with separate
 modules, I don't think there is anything wrong with having this in the
 whiteboard for now. Moving it out now creates more problems than it solves.

 Regards

 Carsten


 David Bosschaert wrote
> Hi all,
>
> Over the recent past some additions have been made to the requirements of
> the Sling Feature Model. The updated requirements can be found here:
> https://github.com/apache/sling-whiteboard/blob/master/featuremodel/readme.md
>
> Any additional requirements, let us know!
>
> I'm hoping to start contributing to the implementation of some of these in
> the near term and was wondering - is there a reason why the feature model
> still in the sling-whiteboard? Or would it make sense to put it in its own
> Sling git repo or repos?
>
> Best regards,
>
> David
>
>>>
> 
> 
-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

Re: [Sling Feature Model] Expanded requirements

[Ioan Eugen Stan]

Hi,

Thank you both for the clarification. I think it is a reasonable approach.

It's always best to validate specs with one or more implementations.

Then I propose that in the interest of greater adoption, maybe a name
change is in order.

Something that says: we install osgi packages and we are used by Sling
instead of having Sling in the name and inducing the idea of being Sling
specific or worst, Sling only.

Thank you,

On 21.02.2018 12:59, Carsten Ziegeler wrote:
> Hi,
>
> thanks! One major point of the feature model is to separate between the
> model and how it is used later on. All current existing approaches mix
> these two things in most cases.
>
> There is a lot of overlap with the Karaf feature model, but the idea is
> to get a common model that works for everyone and as David pointed out
> potentially creating an OSGi spec out of this. So the model should work
> for Karaf users, for people creating sub systems etc.
>
> In fact, the prototype we have in our whiteboard creates a Karaf kar
> file out of a feature which can then easily be used within Karaf. But
> that's just one way doing it
>
> Regards
>
> Carsten
>
>
> Ioan Eugen Stan wrote
>> Hi,
>>
>> I've looked on the specification and I've noticed that it also overlaps
>> with the Karaf Feature functionality.
>>
>> Is there any relation between the two? Is there collaboration between
>> the projects?
>>
>> As a user/consumer of technology I enjoy when technologies are
>> compatible and the tooling support is great.
>>
>> I believe collaboration in this area is beneficial. I would like to be
>> able to provision Sling features in Karaf and Karaf features in Sling
>> with ease.
>>
>> If you put the spec side by side they share a LOT of things, but there
>> are also some minor differences, like file format. Karaf uses XML which
>> has much better tooling support IMO, but this is a persistence format
>> and can be easily changed.
>>
>>
>> p.s. I like the spec, I imagine it took quite some time to write. Kudos !
>>
>> Regards,
>>
>> [1] https://karaf.apache.org/manual/latest/provisioning
>>
>>
>>
>> On 21.02.2018 09:10, Carsten Ziegeler wrote:
>>> Thanks David
>>>
>>> We're neither 100% clear on the requirements nor on the structure,
>>> meaning we don't know how many and what modules this will be. As we're
>>> following the one module per git repo rule, it's currently impossible to
>>> create the correct git repositories. And I guess it doesn't make sense
>>> to rename them or remove them every now and then.
>>>
>>> As the collaboration with the whiteboard is the same as with separate
>>> modules, I don't think there is anything wrong with having this in the
>>> whiteboard for now. Moving it out now creates more problems than it solves.
>>>
>>> Regards
>>>
>>> Carsten
>>>
>>>
>>> David Bosschaert wrote
 Hi all,

 Over the recent past some additions have been made to the requirements of
 the Sling Feature Model. The updated requirements can be found here:
 https://github.com/apache/sling-whiteboard/blob/master/featuremodel/readme.md

 Any additional requirements, let us know!

 I'm hoping to start contributing to the implementation of some of these in
 the near term and was wondering - is there a reason why the feature model
 still in the sling-whiteboard? Or would it make sense to put it in its own
 Sling git repo or repos?

 Best regards,

 David

>>




signature.asc
Description: OpenPGP digital signature

[jira] [Commented] (SLING-7507) Tracker open to early which can cause a NPE.

[Karl Pauls (JIRA)]

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

Karl Pauls commented on SLING-7507:
---

[~cziegeler], the PR seems to fix it. WDYT?

> Tracker open to early which can cause a NPE.
> 
>
> Key: SLING-7507
> URL: https://issues.apache.org/jira/browse/SLING-7507
> Project: Sling
>  Issue Type: Bug
>  Components: Commons
>Affects Versions: Commons Log 5.1.0
>Reporter: Karl Pauls
>Priority: Major
> Fix For: Commons Log 5.1.2
>
>
> The FilterTracker and TurboFilterTracker service tracker are opened in the 
> constructor of the LogbackManager at a time when it isn't fully configured 
> yet. That can lead to an NPE if there is a service found right away.  
> {code:java}
> Caused by: java.lang.NullPointerException: null
> at 
> org.apache.sling.commons.log.logback.internal.LogbackManager$LoggerStateContext.(LogbackManager.java:733)
> at 
> org.apache.sling.commons.log.logback.internal.LogbackManager.determineLoggerState(LogbackManager.java:663)
> at 
> org.apache.sling.commons.log.logback.internal.FilterTracker.getAppenderMap(FilterTracker.java:173)
> at 
> org.apache.sling.commons.log.logback.internal.FilterTracker.addingService(FilterTracker.java:67)
> at 
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:941)
> at 
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:870)
> at 
> org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256)
> at 
> org.osgi.util.tracker.AbstractTracked.trackInitial(AbstractTracked.java:183)
> at org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:318)
> at org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:261)
> at 
> org.apache.sling.commons.log.logback.internal.FilterTracker.(FilterTracker.java:55)
> at 
> org.apache.sling.commons.log.logback.internal.LogbackManager.(LogbackManager.java:153)
> at 
> org.apache.sling.commons.log.logback.internal.Activator.initializeLogbackManager(Activator.java:75)
> at 
> org.apache.sling.commons.log.logback.internal.Activator.start(Activator.java:55)
> at 
> org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:697)
> at org.apache.felix.framework.Felix.activateBundle(Felix.java:2240)
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SLING-7507) Tracker open to early which can cause a NPE.

[ASF GitHub Bot (JIRA)]

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

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

karlpauls opened a new pull request #2: SLING-7507: open the service tracker 
when the LogbackManager is inita…
URL: https://github.com/apache/sling-org-apache-sling-commons-log/pull/2
 
 
   …lized to prevent an NPE.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Tracker open to early which can cause a NPE.
> 
>
> Key: SLING-7507
> URL: https://issues.apache.org/jira/browse/SLING-7507
> Project: Sling
>  Issue Type: Bug
>  Components: Commons
>Affects Versions: Commons Log 5.1.0
>Reporter: Karl Pauls
>Priority: Major
> Fix For: Commons Log 5.1.2
>
>
> The FilterTracker and TurboFilterTracker service tracker are opened in the 
> constructor of the LogbackManager at a time when it isn't fully configured 
> yet. That can lead to an NPE if there is a service found right away.  
> {code:java}
> Caused by: java.lang.NullPointerException: null
> at 
> org.apache.sling.commons.log.logback.internal.LogbackManager$LoggerStateContext.(LogbackManager.java:733)
> at 
> org.apache.sling.commons.log.logback.internal.LogbackManager.determineLoggerState(LogbackManager.java:663)
> at 
> org.apache.sling.commons.log.logback.internal.FilterTracker.getAppenderMap(FilterTracker.java:173)
> at 
> org.apache.sling.commons.log.logback.internal.FilterTracker.addingService(FilterTracker.java:67)
> at 
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:941)
> at 
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:870)
> at 
> org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256)
> at 
> org.osgi.util.tracker.AbstractTracked.trackInitial(AbstractTracked.java:183)
> at org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:318)
> at org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:261)
> at 
> org.apache.sling.commons.log.logback.internal.FilterTracker.(FilterTracker.java:55)
> at 
> org.apache.sling.commons.log.logback.internal.LogbackManager.(LogbackManager.java:153)
> at 
> org.apache.sling.commons.log.logback.internal.Activator.initializeLogbackManager(Activator.java:75)
> at 
> org.apache.sling.commons.log.logback.internal.Activator.start(Activator.java:55)
> at 
> org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:697)
> at org.apache.felix.framework.Felix.activateBundle(Felix.java:2240)
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] karlpauls opened a new pull request #2: SLING-7507: open the service tracker when the LogbackManager is inita?

[GitBox]

karlpauls opened a new pull request #2: SLING-7507: open the service tracker 
when the LogbackManager is inita?
URL: https://github.com/apache/sling-org-apache-sling-commons-log/pull/2
 
 
   ?lized to prevent an NPE.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[jira] [Created] (SLING-7507) Tracker open to early which can cause a NPE.

[Karl Pauls (JIRA)]

Karl Pauls created SLING-7507:
-

 Summary: Tracker open to early which can cause a NPE.
 Key: SLING-7507
 URL: https://issues.apache.org/jira/browse/SLING-7507
 Project: Sling
  Issue Type: Bug
  Components: Commons
Affects Versions: Commons Log 5.1.0
Reporter: Karl Pauls
 Fix For: Commons Log 5.1.2


The FilterTracker and TurboFilterTracker service tracker are opened in the 
constructor of the LogbackManager at a time when it isn't fully configured yet. 
That can lead to an NPE if there is a service found right away.  
{code:java}
Caused by: java.lang.NullPointerException: null
at 
org.apache.sling.commons.log.logback.internal.LogbackManager$LoggerStateContext.(LogbackManager.java:733)
at 
org.apache.sling.commons.log.logback.internal.LogbackManager.determineLoggerState(LogbackManager.java:663)
at 
org.apache.sling.commons.log.logback.internal.FilterTracker.getAppenderMap(FilterTracker.java:173)
at 
org.apache.sling.commons.log.logback.internal.FilterTracker.addingService(FilterTracker.java:67)
at 
org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:941)
at 
org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:870)
at 
org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256)
at 
org.osgi.util.tracker.AbstractTracked.trackInitial(AbstractTracked.java:183)
at org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:318)
at org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:261)
at 
org.apache.sling.commons.log.logback.internal.FilterTracker.(FilterTracker.java:55)
at 
org.apache.sling.commons.log.logback.internal.LogbackManager.(LogbackManager.java:153)
at 
org.apache.sling.commons.log.logback.internal.Activator.initializeLogbackManager(Activator.java:75)
at 
org.apache.sling.commons.log.logback.internal.Activator.start(Activator.java:55)
at 
org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:697)
at org.apache.felix.framework.Felix.activateBundle(Felix.java:2240)
{code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [Sling Feature Model] Expanded requirements

[Carsten Ziegeler]

Hi,

thanks! One major point of the feature model is to separate between the
model and how it is used later on. All current existing approaches mix
these two things in most cases.

There is a lot of overlap with the Karaf feature model, but the idea is
to get a common model that works for everyone and as David pointed out
potentially creating an OSGi spec out of this. So the model should work
for Karaf users, for people creating sub systems etc.

In fact, the prototype we have in our whiteboard creates a Karaf kar
file out of a feature which can then easily be used within Karaf. But
that's just one way doing it

Regards

Carsten


Ioan Eugen Stan wrote
> Hi,
> 
> I've looked on the specification and I've noticed that it also overlaps
> with the Karaf Feature functionality.
> 
> Is there any relation between the two? Is there collaboration between
> the projects?
> 
> As a user/consumer of technology I enjoy when technologies are
> compatible and the tooling support is great.
> 
> I believe collaboration in this area is beneficial. I would like to be
> able to provision Sling features in Karaf and Karaf features in Sling
> with ease.
> 
> If you put the spec side by side they share a LOT of things, but there
> are also some minor differences, like file format. Karaf uses XML which
> has much better tooling support IMO, but this is a persistence format
> and can be easily changed.
> 
> 
> p.s. I like the spec, I imagine it took quite some time to write. Kudos !
> 
> Regards,
> 
> [1] https://karaf.apache.org/manual/latest/provisioning
> 
> 
> 
> On 21.02.2018 09:10, Carsten Ziegeler wrote:
>> Thanks David
>>
>> We're neither 100% clear on the requirements nor on the structure,
>> meaning we don't know how many and what modules this will be. As we're
>> following the one module per git repo rule, it's currently impossible to
>> create the correct git repositories. And I guess it doesn't make sense
>> to rename them or remove them every now and then.
>>
>> As the collaboration with the whiteboard is the same as with separate
>> modules, I don't think there is anything wrong with having this in the
>> whiteboard for now. Moving it out now creates more problems than it solves.
>>
>> Regards
>>
>> Carsten
>>
>>
>> David Bosschaert wrote
>>> Hi all,
>>>
>>> Over the recent past some additions have been made to the requirements of
>>> the Sling Feature Model. The updated requirements can be found here:
>>> https://github.com/apache/sling-whiteboard/blob/master/featuremodel/readme.md
>>>
>>> Any additional requirements, let us know!
>>>
>>> I'm hoping to start contributing to the implementation of some of these in
>>> the near term and was wondering - is there a reason why the feature model
>>> still in the sling-whiteboard? Or would it make sense to put it in its own
>>> Sling git repo or repos?
>>>
>>> Best regards,
>>>
>>> David
>>>
> 
> 
-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

Re: [Sling Feature Model] Expanded requirements

[David Bosschaert]

Hi Ioan,

Yes, there are indeed similarities with the Karaf feature functionality and
actually also similarities with the OSGi Subsystem specification [0]. The
interesting thing is that even though that there is an OSGi specification
in this area, there seems to be a need for something a little bit
different. This can also be seen by the recent contribution to Apache Felix
of the Bundle Archive installer [1].

The requirements here are really aiming to provide a 'next generation' of
the Sling Provisioning model that has already existed for quite some time.

These are all technologies that have some overlap but were still developed
because what was there just didn't quite fit the use cases. I think that
once we are a little further along the implementation of the Sling Feature
Model we could try to see if a common set of requirements can be extracted
that can then be proposed as an RFP for a new OSGi specification. One great
benefit of having such an independent spec would be that tooling would work
with all the implementations, as you say. But obviously the spec needs to
work for all different users so there is definitely a lot of work needed
there.

Best regards,

David

PS @Carsten I guess you're right - maybe this time would be a bit too early
to move it out of the whiteboard.

[0] https://osgi.org/specification/osgi.cmpn/7.0.0/service.subsystem.html
[1] https://www.mail-archive.com/dev@felix.apache.org/msg45002.html

On 21 February 2018 at 07:45, Ioan Eugen Stan  wrote:

> Hi,
>
> I've looked on the specification and I've noticed that it also overlaps
> with the Karaf Feature functionality.
>
> Is there any relation between the two? Is there collaboration between
> the projects?
>
> As a user/consumer of technology I enjoy when technologies are
> compatible and the tooling support is great.
>
> I believe collaboration in this area is beneficial. I would like to be
> able to provision Sling features in Karaf and Karaf features in Sling
> with ease.
>
> If you put the spec side by side they share a LOT of things, but there
> are also some minor differences, like file format. Karaf uses XML which
> has much better tooling support IMO, but this is a persistence format
> and can be easily changed.
>
>
> p.s. I like the spec, I imagine it took quite some time to write. Kudos !
>
> Regards,
>
> [1] https://karaf.apache.org/manual/latest/provisioning
>
>
>
> On 21.02.2018 09:10, Carsten Ziegeler wrote:
> > Thanks David
> >
> > We're neither 100% clear on the requirements nor on the structure,
> > meaning we don't know how many and what modules this will be. As we're
> > following the one module per git repo rule, it's currently impossible to
> > create the correct git repositories. And I guess it doesn't make sense
> > to rename them or remove them every now and then.
> >
> > As the collaboration with the whiteboard is the same as with separate
> > modules, I don't think there is anything wrong with having this in the
> > whiteboard for now. Moving it out now creates more problems than it
> solves.
> >
> > Regards
> >
> > Carsten
> >
> >
> > David Bosschaert wrote
> >> Hi all,
> >>
> >> Over the recent past some additions have been made to the requirements
> of
> >> the Sling Feature Model. The updated requirements can be found here:
> >> https://github.com/apache/sling-whiteboard/blob/master/featu
> remodel/readme.md
> >>
> >> Any additional requirements, let us know!
> >>
> >> I'm hoping to start contributing to the implementation of some of these
> in
> >> the near term and was wondering - is there a reason why the feature
> model
> >> still in the sling-whiteboard? Or would it make sense to put it in its
> own
> >> Sling git repo or repos?
> >>
> >> Best regards,
> >>
> >> David
> >>
>
>
>

[jira] [Commented] (SLING-7271) Make it possible to mount packages via Import Mapping

[Gaurav Gupta (JIRA)]

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

Gaurav Gupta commented on SLING-7271:
-

[~simone.tripodi] [~teofili] [~marett] Hi, Can you please advise on this issue 
if this can be fixed? Thanks

> Make it possible to mount packages via Import Mapping 
> --
>
> Key: SLING-7271
> URL: https://issues.apache.org/jira/browse/SLING-7271
> Project: Sling
>  Issue Type: Improvement
>  Components: Content Distribution
>Reporter: Tanu Singla
>Priority: Major
>
> In some scenarios(e.g. multi tenant instances), it may be useful to be able 
> to mount packages at configurable paths considering the import path mapping 
> specified on target instance rather than author instance.
> e.g. mounting a package for /foo/bar at /tenant/foo/bar by specifying import 
> path mapping configuration property on the tenantized system.
> We can update *importFromStream ()*of *FileVaultContentSerializer* file, to 
> consider import path mapping option as well. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)