[jira] [Commented] (SLING-6826) i18n: Supported nested keys in JSON i18n files

[Alexander Klimetschek (JIRA)]

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

Alexander Klimetschek commented on SLING-6826:
--

What is the use case for supporting nested json files?

At first glance, it only increases complexity to me (well, only a bit, but 
looking at future maintenance it might be). The json format is kind of 
proprietary (albeit it's dead simple) and is assumed to be converted from other 
dictionaries such as xliff etc. anyway...

Thus I also would be surprised if people are using it with nested json today, 
where not all contents would be used by sling i18n (to answer your question).


> i18n: Supported nested keys in JSON i18n files
> --
>
> Key: SLING-6826
> URL: https://issues.apache.org/jira/browse/SLING-6826
> Project: Sling
>  Issue Type: New Feature
>  Components: i18n
>Affects Versions: i18n 2.5.8
>Reporter: Stefan Seifert
>
> i18n supports resource files stored as JSON binary files in the repository:
> https://sling.apache.org/documentation/bundles/internationalization-support-i18n.html#json-file-based
> currently nested key structures are not really supported - from the docs 
> page: 
> {quote}
> The parser will take any "key":"value" pair in the JSON file, including those 
> in nested objects or arrays. Normally, a dictionary will be just a single 
> json object = hash map though.
> {quote}
> that means that these two JSON example will produc the same result:
> A)
> {code:javascript}
> {
>   "key1": "value1",
>   "key2": "value2",
>   "key3": "value3"
> }
> {code}
> B)
> {code:javascript}
> {
>   "level1": {
> "key1": "value1",
> "level2: {
>   "key2": "value2",
>   "level3": {
> "key3": "value3"
>   }
> }
>   }
> }
> {code}
> in both cases the keys are just
> {noformat}
> key1
> key2
> key3
> {noformat}
> the goal of this ticket is to interpret the nested JSON object structure as 
> parts of the i18n keys, so that example B would produce these keys:
> {noformat}
> level1.key1
> level1.level2.key2
> level1.level2.level3.key3
> {noformat}
> as statet in the documentation in most cases people will only use the JSON as 
> key/value map file with no hierarchies at all. in this case the result is the 
> same. but if someone used hierarchies this ticket will create a backward 
> compatibility issue. i will start a discussion on the sling-dev list about 
> this.



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

[jira] [Created] (SLING-6829) FSResource: Support node descriptor files for folders and binary files

[Stefan Seifert (JIRA)]

Stefan Seifert created SLING-6829:
-

 Summary: FSResource: Support node descriptor files for folders and 
binary files
 Key: SLING-6829
 URL: https://issues.apache.org/jira/browse/SLING-6829
 Project: Sling
  Issue Type: New Feature
  Components: Extensions
Affects Versions: File System Resource Provider 2.0.0, File System Resource 
Provider 1.3.0
Reporter: Stefan Seifert
Assignee: Stefan Seifert
 Fix For: File System Resource Provider 1.3.2, File System Resource 
Provider 2.0.2


for binary files and folders it is possible to add additional content 
definition files with the same name which add additional mixins or properties 
to the imported nt:file/nt:folder resource, or change the JCR primary type.

this has to be supported by fsresource as well.

with this we should also add support for the XML descriptor file format (see 
SLING-6828).



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

[jira] [Created] (SLING-6828) JCR Content Parser: Support XML Descriptor Files

[Stefan Seifert (JIRA)]

Stefan Seifert created SLING-6828:
-

 Summary: JCR Content Parser: Support XML Descriptor Files
 Key: SLING-6828
 URL: https://issues.apache.org/jira/browse/SLING-6828
 Project: Sling
  Issue Type: New Feature
  Components: JCR
Affects Versions: JCR Content Parser 1.0.0
Reporter: Stefan Seifert
Assignee: Stefan Seifert
 Fix For: JCR Content Parser 1.1.0


we should also support the XML descriptor file format supported by the JCR 
content loader:
https://sling.apache.org/documentation/bundles/content-loading-jcr-contentloader.html#xml-descriptor-files

this is in some special usecases useful, e.g. when adding an descriptor for 
binary files with additional properties - e.g. additional mixin and language 
property for i18n json binary file.



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

[jira] [Resolved] (SLING-6827) JCR Content Parser: Ignore 'jcr:name:' and 'jcr:uri:' prefixes by default

[Stefan Seifert (JIRA)]

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

Stefan Seifert resolved SLING-6827.
---
Resolution: Fixed

Completed: At revision: 1793721  


> JCR Content Parser: Ignore 'jcr:name:' and 'jcr:uri:' prefixes by default
> -
>
> Key: SLING-6827
> URL: https://issues.apache.org/jira/browse/SLING-6827
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: JCR Content Parser 1.0.0
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>Priority: Minor
> Fix For: JCR Content Parser 1.1.0
>
>
> JCR conent loader also supports the special property name prefixes 
> 'jcr:name:' and 'jcr:uri:' for JSON files. they should be removed by default 
> from the property names.
> (this can be overridden via ParserOptions).



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

[jira] [Created] (SLING-6827) JCR Content Parser: Ignore 'jcr:name:' and 'jcr:uri:' prefixes by default

[Stefan Seifert (JIRA)]

Stefan Seifert created SLING-6827:
-

 Summary: JCR Content Parser: Ignore 'jcr:name:' and 'jcr:uri:' 
prefixes by default
 Key: SLING-6827
 URL: https://issues.apache.org/jira/browse/SLING-6827
 Project: Sling
  Issue Type: Improvement
  Components: Extensions
Affects Versions: JCR Content Parser 1.0.0
Reporter: Stefan Seifert
Assignee: Stefan Seifert
Priority: Minor
 Fix For: JCR Content Parser 1.1.0


JCR conent loader also supports the special property name prefixes 'jcr:name:' 
and 'jcr:uri:' for JSON files. they should be removed by default from the 
property names.
(this can be overridden via ParserOptions).



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

Re: JCR content loader - release soon?

[Karl Pauls]

On Wed, May 3, 2017 at 10:10 PM, Karl Pauls  wrote:
> On Wed, May 3, 2017 at 7:10 PM, Robert Munteanu  wrote:
>> On Wed, 2017-05-03 at 17:03 +, Stefan Seifert wrote:
>>> i would like to release JCR content loader soon - it's several years
>>> since the last release.
>>>
>>> unfortunately there are 5 unresolved issues assigned to the next
>>> version [1]
>>>
>>> most of them are over three years old. do we have to wait for the
>>> completion, or can we move them to the next release?
>>
>>
>> None of these look critical to me, so I would say just go ahead and do
>> the release.
>
> Granted, that is a bug that exists in the current version already so
> you wouldn't make things worse but SLING-6640 is effectively causing
> content to potentially not getting unloaded...
>
> Let me see if I can fix it quickly.

Should be fixed now.

regards,

Karl

> regards,
>
> Karl
>
>> Robert
>>
>>>
>>> this also blocks sling 9.
>>>
>>> stefan
>>>
>>> [1] https://issues.apache.org/jira/issues/?jql=fixVersion%20%3D%20%22
>>> JCR%20ContentLoader%202.2.0%22%20AND%20project%20%3D%20SLING%20AND%20
>>> resolution%20%3D%20Unresolved%20ORDER%20BY%20key%20ASC
>>>
>>>
>>
>
>
>
> --
> Karl Pauls
> karlpa...@gmail.com



-- 
Karl Pauls
karlpa...@gmail.com

[jira] [Resolved] (SLING-6640) Race condition in JCR Contentloader deactivate can cause NullPointerException.

[Karl Pauls (JIRA)]

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

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

Fixed in r1793718.

> Race condition in JCR Contentloader deactivate can cause NullPointerException.
> --
>
> Key: SLING-6640
> URL: https://issues.apache.org/jira/browse/SLING-6640
> Project: Sling
>  Issue Type: Bug
>  Components: JCR
>Affects Versions: JCR ContentLoader 2.1.10
>Reporter: Karl Pauls
>Assignee: Karl Pauls
> Fix For: JCR ContentLoader 2.2.0
>
>
> The ContentLoaderService registers itself as a SynchronousBundleListener with 
> the framework on activate and unregisters in the deactivate method. After it 
> unregistered it turns around and first calls:
> this.bundleContentLoader.dispose();
> and then the bundleContentLoader is set to null. The bundleContentLoader is 
> used in the bundleChanged(BundleEvent) callback of the listener interface. 
> There seems to be an assumption that there will be no more events received 
> after the unregistering as a listener - however, that assumption doesn't 
> hold. The framework gets a snapshot of listeners and calls them so there is a 
> window where bundleChanged can be invoked after the call to 
> bundleContentLoader.dispose() or after it is set to null. 
> Both cases can lead to an NPE (either in the bundleChanged directly because 
> the bundleContentLoader is null already or inside the bundleContentLoader 
> itself as it has been disposed) when there is a race between the service 
> being deactivated and a bundle changing state concurrently. 



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

[jira] [Assigned] (SLING-6640) Race condition in JCR Contentloader deactivate can cause NullPointerException.

[Karl Pauls (JIRA)]

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

Karl Pauls reassigned SLING-6640:
-

Assignee: Karl Pauls

> Race condition in JCR Contentloader deactivate can cause NullPointerException.
> --
>
> Key: SLING-6640
> URL: https://issues.apache.org/jira/browse/SLING-6640
> Project: Sling
>  Issue Type: Bug
>  Components: JCR
>Affects Versions: JCR ContentLoader 2.1.10
>Reporter: Karl Pauls
>Assignee: Karl Pauls
> Fix For: JCR ContentLoader 2.2.0
>
>
> The ContentLoaderService registers itself as a SynchronousBundleListener with 
> the framework on activate and unregisters in the deactivate method. After it 
> unregistered it turns around and first calls:
> this.bundleContentLoader.dispose();
> and then the bundleContentLoader is set to null. The bundleContentLoader is 
> used in the bundleChanged(BundleEvent) callback of the listener interface. 
> There seems to be an assumption that there will be no more events received 
> after the unregistering as a listener - however, that assumption doesn't 
> hold. The framework gets a snapshot of listeners and calls them so there is a 
> window where bundleChanged can be invoked after the call to 
> bundleContentLoader.dispose() or after it is set to null. 
> Both cases can lead to an NPE (either in the bundleChanged directly because 
> the bundleContentLoader is null already or inside the bundleContentLoader 
> itself as it has been disposed) when there is a race between the service 
> being deactivated and a bundle changing state concurrently. 



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

Re: JCR content loader - release soon?

[Karl Pauls]

On Wed, May 3, 2017 at 7:10 PM, Robert Munteanu  wrote:
> On Wed, 2017-05-03 at 17:03 +, Stefan Seifert wrote:
>> i would like to release JCR content loader soon - it's several years
>> since the last release.
>>
>> unfortunately there are 5 unresolved issues assigned to the next
>> version [1]
>>
>> most of them are over three years old. do we have to wait for the
>> completion, or can we move them to the next release?
>
>
> None of these look critical to me, so I would say just go ahead and do
> the release.

Granted, that is a bug that exists in the current version already so
you wouldn't make things worse but SLING-6640 is effectively causing
content to potentially not getting unloaded...

Let me see if I can fix it quickly.

regards,

Karl

> Robert
>
>>
>> this also blocks sling 9.
>>
>> stefan
>>
>> [1] https://issues.apache.org/jira/issues/?jql=fixVersion%20%3D%20%22
>> JCR%20ContentLoader%202.2.0%22%20AND%20project%20%3D%20SLING%20AND%20
>> resolution%20%3D%20Unresolved%20ORDER%20BY%20key%20ASC
>>
>>
>



-- 
Karl Pauls
karlpa...@gmail.com

i18n json files - support for nested key structures?

[Stefan Seifert]

i propose a change how the i18n implementation interprets the keys in i18n JSON 
files. details are described in [1].

this change is fully backward compatible when the JSON files are just used as 
key-value map-like structure without any hierarchy - which is done by most 
users i assume. but if someone has used nested JSON files this change breaks 
with compatibility to the past releases.

do you think anyone currently used these nested JSON structures not really well 
supported?
can we break the behavior as described in the ticket (and document it properly)?

making this feature configurable does no really help - it would always affect 
all i18n json files in the system.

WDYT?

stefan

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

[jira] [Commented] (SLING-6826) i18n: Supported nested keys in JSON i18n files

[ASF GitHub Bot (JIRA)]

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

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

GitHub user stefanseifert opened a pull request:

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

SLING-6826 i18n: Supported nested keys in JSON i18n files



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

$ git pull https://github.com/stefanseifert/sling 
feature/SLING-6826-i18n-json-hierarchy

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

https://github.com/apache/sling/pull/222.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 #222


commit 83447b43a445cb1ead08f318d8613397548eee6b
Author: sseifert 
Date:   2017-05-03T19:51:08Z

SLING-6826 i18n: Supported nested keys in JSON i18n files




> i18n: Supported nested keys in JSON i18n files
> --
>
> Key: SLING-6826
> URL: https://issues.apache.org/jira/browse/SLING-6826
> Project: Sling
>  Issue Type: New Feature
>  Components: i18n
>Affects Versions: i18n 2.5.8
>Reporter: Stefan Seifert
>
> i18n supports resource files stored as JSON binary files in the repository:
> https://sling.apache.org/documentation/bundles/internationalization-support-i18n.html#json-file-based
> currently nested key structures are not really supported - from the docs 
> page: 
> {quote}
> The parser will take any "key":"value" pair in the JSON file, including those 
> in nested objects or arrays. Normally, a dictionary will be just a single 
> json object = hash map though.
> {quote}
> that means that these two JSON example will produc the same result:
> A)
> {code:javascript}
> {
>   "key1": "value1",
>   "key2": "value2",
>   "key3": "value3"
> }
> {code}
> B)
> {code:javascript}
> {
>   "level1": {
> "key1": "value1",
> "level2: {
>   "key2": "value2",
>   "level3": {
> "key3": "value3"
>   }
> }
>   }
> }
> {code}
> in both cases the keys are just
> {noformat}
> key1
> key2
> key3
> {noformat}
> the goal of this ticket is to interpret the nested JSON object structure as 
> parts of the i18n keys, so that example B would produce these keys:
> {noformat}
> level1.key1
> level1.level2.key2
> level1.level2.level3.key3
> {noformat}
> as statet in the documentation in most cases people will only use the JSON as 
> key/value map file with no hierarchies at all. in this case the result is the 
> same. but if someone used hierarchies this ticket will create a backward 
> compatibility issue. i will start a discussion on the sling-dev list about 
> this.



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

[GitHub] sling pull request #222: SLING-6826 i18n: Supported nested keys in JSON i18n...

[stefanseifert]

GitHub user stefanseifert opened a pull request:

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

SLING-6826 i18n: Supported nested keys in JSON i18n files



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

$ git pull https://github.com/stefanseifert/sling 
feature/SLING-6826-i18n-json-hierarchy

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

https://github.com/apache/sling/pull/222.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 #222


commit 83447b43a445cb1ead08f318d8613397548eee6b
Author: sseifert 
Date:   2017-05-03T19:51:08Z

SLING-6826 i18n: Supported nested keys in JSON i18n files




---
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] [Updated] (SLING-6826) i18n: Supported nested keys in JSON i18n files

[Stefan Seifert (JIRA)]

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

Stefan Seifert updated SLING-6826:
--
Fix Version/s: (was: i18n 2.5.10)
  Description: 
i18n supports resource files stored as JSON binary files in the repository:
https://sling.apache.org/documentation/bundles/internationalization-support-i18n.html#json-file-based

currently nested key structures are not really supported - from the docs page: 
{quote}
The parser will take any "key":"value" pair in the JSON file, including those 
in nested objects or arrays. Normally, a dictionary will be just a single json 
object = hash map though.
{quote}

that means that these two JSON example will produc the same result:
A)
{code:javascript}
{
  "key1": "value1",
  "key2": "value2",
  "key3": "value3"
}
{code}

B)

{code:javascript}
{
  "level1": {
"key1": "value1",
"level2: {
  "key2": "value2",
  "level3": {
"key3": "value3"
  }
}
  }
}
{code}

in both cases the keys are just
{noformat}
key1
key2
key3
{noformat}

the goal of this ticket is to interpret the nested JSON object structure as 
parts of the i18n keys, so that example B would produce these keys:
{noformat}
level1.key1
level1.level2.key2
level1.level2.level3.key3
{noformat}

as statet in the documentation in most cases people will only use the JSON as 
key/value map file with no hierarchies at all. in this case the result is the 
same. but if someone used hierarchies this ticket will create a backward 
compatibility issue. i will start a discussion on the sling-dev list about this.

  was:
i18n supports resource files stored as JSON binary files in the repository:
https://sling.apache.org/documentation/bundles/internationalization-support-i18n.html#json-file-based

currently nested key structures are not really supported - from the docs page: 
{quote}
The parser will take any "key":"value" pair in the JSON file, including those 
in nested objects or arrays. Normally, a dictionary will be just a single json 
object = hash map though.
{quote}

that means that these two JSON example will produc the same result:
A)
{code:javascript}
{
  "key1": "value1",
  "key2": "value2",
  "key3": "value3"
}
{code}

B)

{code:javascript}
{
  "level1": {
"key1": "value1",
"level2: {
  "key2": "value2",
  "level3": {
"key3": "value3"
  }
}
  }
}
{code}

in both cases the keys are just
{noformat}
key1
key2
key3
{noformat}

the goal of this ticket is to interpret the nested JSON object structure as 
parts of the i18n keys, so that example B would produce these keys:
{noformat}
key1
level2.key2
level2.level3.key3
{noformat}

as statet in the documentation in most cases people will only use the JSON as 
key/value map file with no hierarchies at all. in this case the result is the 
same. but if someone used hierarchies this ticket will create a backward 
compatibility issue. i will start a discussion on the sling-dev list about this.


> i18n: Supported nested keys in JSON i18n files
> --
>
> Key: SLING-6826
> URL: https://issues.apache.org/jira/browse/SLING-6826
> Project: Sling
>  Issue Type: New Feature
>  Components: i18n
>Affects Versions: i18n 2.5.8
>Reporter: Stefan Seifert
>
> i18n supports resource files stored as JSON binary files in the repository:
> https://sling.apache.org/documentation/bundles/internationalization-support-i18n.html#json-file-based
> currently nested key structures are not really supported - from the docs 
> page: 
> {quote}
> The parser will take any "key":"value" pair in the JSON file, including those 
> in nested objects or arrays. Normally, a dictionary will be just a single 
> json object = hash map though.
> {quote}
> that means that these two JSON example will produc the same result:
> A)
> {code:javascript}
> {
>   "key1": "value1",
>   "key2": "value2",
>   "key3": "value3"
> }
> {code}
> B)
> {code:javascript}
> {
>   "level1": {
> "key1": "value1",
> "level2: {
>   "key2": "value2",
>   "level3": {
> "key3": "value3"
>   }
> }
>   }
> }
> {code}
> in both cases the keys are just
> {noformat}
> key1
> key2
> key3
> {noformat}
> the goal of this ticket is to interpret the nested JSON object structure as 
> parts of the i18n keys, so that example B would produce these keys:
> {noformat}
> level1.key1
> level1.level2.key2
> level1.level2.level3.key3
> {noformat}
> as statet in the documentation in most cases people will only use the JSON as 
> key/value map file with no hierarchies at all. in this case the result is the 
> same. but if someone used hierarchies this ticket will create a backward 
> compatibility issue. i will start a discussion on the sling-dev list about 
> this.



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

[jira] [Created] (SLING-6826) i18n: Supported nested keys in JSON i18n files

[Stefan Seifert (JIRA)]

Stefan Seifert created SLING-6826:
-

 Summary: i18n: Supported nested keys in JSON i18n files
 Key: SLING-6826
 URL: https://issues.apache.org/jira/browse/SLING-6826
 Project: Sling
  Issue Type: New Feature
  Components: i18n
Affects Versions: i18n 2.5.8
Reporter: Stefan Seifert
 Fix For: i18n 2.5.10


i18n supports resource files stored as JSON binary files in the repository:
https://sling.apache.org/documentation/bundles/internationalization-support-i18n.html#json-file-based

currently nested key structures are not really supported - from the docs page: 
{quote}
The parser will take any "key":"value" pair in the JSON file, including those 
in nested objects or arrays. Normally, a dictionary will be just a single json 
object = hash map though.
{quote}

that means that these two JSON example will produc the same result:
A)
{code:javascript}
{
  "key1": "value1",
  "key2": "value2",
  "key3": "value3"
}
{code}

B)

{code:javascript}
{
  "level1": {
"key1": "value1",
"level2: {
  "key2": "value2",
  "level3": {
"key3": "value3"
  }
}
  }
}
{code}

in both cases the keys are just
{noformat}
key1
key2
key3
{noformat}

the goal of this ticket is to interpret the nested JSON object structure as 
parts of the i18n keys, so that example B would produce these keys:
{noformat}
key1
level2.key2
level2.level3.key3
{noformat}

as statet in the documentation in most cases people will only use the JSON as 
key/value map file with no hierarchies at all. in this case the result is the 
same. but if someone used hierarchies this ticket will create a backward 
compatibility issue. i will start a discussion on the sling-dev list about this.



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

[jira] [Updated] (SLING-6804) Request to allow the health check servlet to directly query a single health check by name

[Justin Edelson (JIRA)]

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

Justin Edelson updated SLING-6804:
--
Attachment: (was: SLING-6804.diff)

> Request to allow the health check servlet to directly query a single health 
> check by name
> -
>
> Key: SLING-6804
> URL: https://issues.apache.org/jira/browse/SLING-6804
> Project: Sling
>  Issue Type: Improvement
>  Components: Health Check
>Reporter: Clinton H Goudie-Nice
>Assignee: Justin Edelson
>Priority: Minor
> Attachments: SLING-6804.diff
>
>
> AMS has a request to be able to access an individual health check by name
> For example: 
> http://localhost:4502/system/health/named/Sling%20Get%20Servlet.json
> And have it return the results for only this named health check.



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

[jira] [Updated] (SLING-6804) Request to allow the health check servlet to directly query a single health check by name

[Justin Edelson (JIRA)]

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

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

> Request to allow the health check servlet to directly query a single health 
> check by name
> -
>
> Key: SLING-6804
> URL: https://issues.apache.org/jira/browse/SLING-6804
> Project: Sling
>  Issue Type: Improvement
>  Components: Health Check
>Reporter: Clinton H Goudie-Nice
>Assignee: Justin Edelson
>Priority: Minor
> Attachments: SLING-6804.diff
>
>
> AMS has a request to be able to access an individual health check by name
> For example: 
> http://localhost:4502/system/health/named/Sling%20Get%20Servlet.json
> And have it return the results for only this named health check.



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

Re: JCR content loader - release soon?

[Robert Munteanu]

On Wed, 2017-05-03 at 17:03 +, Stefan Seifert wrote:
> i would like to release JCR content loader soon - it's several years
> since the last release.
> 
> unfortunately there are 5 unresolved issues assigned to the next
> version [1]
> 
> most of them are over three years old. do we have to wait for the
> completion, or can we move them to the next release?


None of these look critical to me, so I would say just go ahead and do
the release.

Robert

> 
> this also blocks sling 9.
> 
> stefan
> 
> [1] https://issues.apache.org/jira/issues/?jql=fixVersion%20%3D%20%22
> JCR%20ContentLoader%202.2.0%22%20AND%20project%20%3D%20SLING%20AND%20
> resolution%20%3D%20Unresolved%20ORDER%20BY%20key%20ASC
> 
> 

JCR content loader - release soon?

[Stefan Seifert]

i would like to release JCR content loader soon - it's several years since the 
last release.

unfortunately there are 5 unresolved issues assigned to the next version [1]

most of them are over three years old. do we have to wait for the completion, 
or can we move them to the next release?

this also blocks sling 9.

stefan

[1] 
https://issues.apache.org/jira/issues/?jql=fixVersion%20%3D%20%22JCR%20ContentLoader%202.2.0%22%20AND%20project%20%3D%20SLING%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20key%20ASC

[jira] [Resolved] (SLING-6825) JCR Content Loader: Restore Node Descriptor Functionality

[Stefan Seifert (JIRA)]

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

Stefan Seifert resolved SLING-6825.
---
Resolution: Fixed

i've also updated the docs and added an example for loading i18n JSON files 
with content loader:
http://sling.apache.org/documentation/bundles/content-loading-jcr-contentloader.html
(changes not yet visible live)

> JCR Content Loader: Restore Node Descriptor Functionality
> -
>
> Key: SLING-6825
> URL: https://issues.apache.org/jira/browse/SLING-6825
> Project: Sling
>  Issue Type: Bug
>  Components: JCR
>Affects Versions: JCR ContentLoader 2.1.8, JCR ContentLoader 2.1.10
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
> Fix For: JCR ContentLoader 2.2.0
>
>
> in SLING-579 a feature was introduced which allowed to add "node descriptor 
> files" for content loading process, e.g. adding some additional JCR mixins or 
> properties to a file imported via sling content loader.
> this feature was broken by rev. 1528790 since JCR content loader 2.1.8.
> we should also add unit test for this feature and some documentation.



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

[jira] [Commented] (SLING-6825) JCR Content Loader: Restore Node Descriptor Functionality

[Stefan Seifert (JIRA)]

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

Stefan Seifert commented on SLING-6825:
---

Completed: At revision: 1793674  

added integration tests for files and folders with additional node descriptors

> JCR Content Loader: Restore Node Descriptor Functionality
> -
>
> Key: SLING-6825
> URL: https://issues.apache.org/jira/browse/SLING-6825
> Project: Sling
>  Issue Type: Bug
>  Components: JCR
>Affects Versions: JCR ContentLoader 2.1.8, JCR ContentLoader 2.1.10
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
> Fix For: JCR ContentLoader 2.2.0
>
>
> in SLING-579 a feature was introduced which allowed to add "node descriptor 
> files" for content loading process, e.g. adding some additional JCR mixins or 
> properties to a file imported via sling content loader.
> this feature was broken by rev. 1528790 since JCR content loader 2.1.8.
> we should also add unit test for this feature and some documentation.



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

[jira] [Commented] (SLING-6825) JCR Content Loader: Restore Node Descriptor Functionality

[Stefan Seifert (JIRA)]

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

Stefan Seifert commented on SLING-6825:
---

Completed: At revision: 1793667  

fixed the issue

> JCR Content Loader: Restore Node Descriptor Functionality
> -
>
> Key: SLING-6825
> URL: https://issues.apache.org/jira/browse/SLING-6825
> Project: Sling
>  Issue Type: Bug
>  Components: JCR
>Affects Versions: JCR ContentLoader 2.1.8, JCR ContentLoader 2.1.10
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
> Fix For: JCR ContentLoader 2.2.0
>
>
> in SLING-579 a feature was introduced which allowed to add "node descriptor 
> files" for content loading process, e.g. adding some additional JCR mixins or 
> properties to a file imported via sling content loader.
> this feature was broken by rev. 1528790 since JCR content loader 2.1.8.
> we should also add unit test for this feature and some documentation.



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

[jira] [Created] (SLING-6825) JCR Content Loader: Restore Node Descriptor Functionality

[Stefan Seifert (JIRA)]

Stefan Seifert created SLING-6825:
-

 Summary: JCR Content Loader: Restore Node Descriptor Functionality
 Key: SLING-6825
 URL: https://issues.apache.org/jira/browse/SLING-6825
 Project: Sling
  Issue Type: Bug
  Components: JCR
Affects Versions: JCR ContentLoader 2.1.10, JCR ContentLoader 2.1.8
Reporter: Stefan Seifert
Assignee: Stefan Seifert
 Fix For: JCR ContentLoader 2.2.0


in SLING-579 a feature was introduced which allowed to add "node descriptor 
files" for content loading process, e.g. adding some additional JCR mixins or 
properties to a file imported via sling content loader.

this feature was broken by rev. 1528790 since JCR content loader 2.1.8.

we should also add unit test for this feature and some documentation.



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

[jira] [Commented] (SLING-6804) Request to allow the health check servlet to directly query a single health check by name

[Justin Edelson (JIRA)]

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

Justin Edelson commented on SLING-6804:
---

Attached my proposed change. It supports names as a query parameter only, which 
I think is sufficient for Clint's use case.

If you specify names and tags both, you get the union. Negative names are also 
supported which allows you to do something like tags=foo=-Something to 
get all the HC's with the tag "foo" except the one named "Something"

> Request to allow the health check servlet to directly query a single health 
> check by name
> -
>
> Key: SLING-6804
> URL: https://issues.apache.org/jira/browse/SLING-6804
> Project: Sling
>  Issue Type: Improvement
>  Components: Health Check
>Reporter: Clinton H Goudie-Nice
>Assignee: Justin Edelson
>Priority: Minor
> Attachments: SLING-6804.diff
>
>
> AMS has a request to be able to access an individual health check by name
> For example: 
> http://localhost:4502/system/health/named/Sling%20Get%20Servlet.json
> And have it return the results for only this named health check.



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

[jira] [Updated] (SLING-6804) Request to allow the health check servlet to directly query a single health check by name

[Justin Edelson (JIRA)]

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

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

> Request to allow the health check servlet to directly query a single health 
> check by name
> -
>
> Key: SLING-6804
> URL: https://issues.apache.org/jira/browse/SLING-6804
> Project: Sling
>  Issue Type: Improvement
>  Components: Health Check
>Reporter: Clinton H Goudie-Nice
>Assignee: Justin Edelson
>Priority: Minor
> Attachments: SLING-6804.diff
>
>
> AMS has a request to be able to access an individual health check by name
> For example: 
> http://localhost:4502/system/health/named/Sling%20Get%20Servlet.json
> And have it return the results for only this named health check.



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

[jira] [Commented] (SLING-6806) Health Check servlet does not show associated tags in the html or json

[Justin Edelson (JIRA)]

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

Justin Edelson commented on SLING-6806:
---

thanks [~henzlerg] for the feedback. I moved it to the first column prefixed 
with "Tags" in r1793654.

> Health Check servlet does not show associated tags in the html or json
> --
>
> Key: SLING-6806
> URL: https://issues.apache.org/jira/browse/SLING-6806
> Project: Sling
>  Issue Type: Improvement
>  Components: Health Check
>Reporter: Clinton H Goudie-Nice
>Assignee: Justin Edelson
>Priority: Minor
> Fix For: Health Check Core 1.2.8
>
>
> From the health check servlet, you cannot determine what tags are associated 
> with a given health check. You can visit the system console itself, but it 
> seems this information should be presented here.



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

[jira] [Commented] (SLING-6804) Request to allow the health check servlet to directly query a single health check by name

[Justin Edelson (JIRA)]

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

Justin Edelson commented on SLING-6804:
---

IMHO, the class name is an implementation detail. We should use the {{hc.name}} 
property. I'm not sure what you mean about it not working nicely in URLs.

I'm basically complete with a patch which supports names via query parameters. 
Will post that in a few minutes. For some reason yesterday I was unable to 
connect to the ASF JIRA instance.

> Request to allow the health check servlet to directly query a single health 
> check by name
> -
>
> Key: SLING-6804
> URL: https://issues.apache.org/jira/browse/SLING-6804
> Project: Sling
>  Issue Type: Improvement
>  Components: Health Check
>Reporter: Clinton H Goudie-Nice
>Assignee: Justin Edelson
>Priority: Minor
>
> AMS has a request to be able to access an individual health check by name
> For example: 
> http://localhost:4502/system/health/named/Sling%20Get%20Servlet.json
> And have it return the results for only this named health check.



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

[jira] [Assigned] (SLING-5952) Add support for configurable SO and connection timeouts

[Timothee Maret (JIRA)]

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

Timothee Maret reassigned SLING-5952:
-

Assignee: Tommaso Teofili  (was: Timothee Maret)

> Add support for configurable SO and connection timeouts
> ---
>
> Key: SLING-5952
> URL: https://issues.apache.org/jira/browse/SLING-5952
> Project: Sling
>  Issue Type: Improvement
>  Components: Content Distribution
>Affects Versions: Content Distribution Core 0.1.18
>Reporter: Timothee Maret
>Assignee: Tommaso Teofili
> Fix For: Content Distribution Core 0.2.8
>
> Attachments: SLING-SLING-5952.0.patch
>
>
> Currently the SDC transport is using the default HTTP client timeouts
> 1. Connection Timeout (by default it is infinite)
> 2. SO Socket Timeout (by default it is infinite)
> Allowing to configure a bounded timeouts is needed in most deployments in 
> order to avoid leaving a resource stuck.



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

[jira] [Updated] (SLING-5952) Add support for configurable SO and connection timeouts

[Tommaso Teofili (JIRA)]

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

Tommaso Teofili updated SLING-5952:
---
Attachment: SLING-SLING-5952.0.patch

attaching trivial patch with fixed socket / connect timeout of 10s.

> Add support for configurable SO and connection timeouts
> ---
>
> Key: SLING-5952
> URL: https://issues.apache.org/jira/browse/SLING-5952
> Project: Sling
>  Issue Type: Improvement
>  Components: Content Distribution
>Affects Versions: Content Distribution Core 0.1.18
>Reporter: Timothee Maret
>Assignee: Timothee Maret
> Fix For: Content Distribution Core 0.2.8
>
> Attachments: SLING-SLING-5952.0.patch
>
>
> Currently the SDC transport is using the default HTTP client timeouts
> 1. Connection Timeout (by default it is infinite)
> 2. SO Socket Timeout (by default it is infinite)
> Allowing to configure a bounded timeouts is needed in most deployments in 
> order to avoid leaving a resource stuck.



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

[jira] [Issue Comment Deleted] (SLING-6804) Request to allow the health check servlet to directly query a single health check by name

[Georg Henzler (JIRA)]

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

Georg Henzler updated SLING-6804:
-
Comment: was deleted

(was: To not complicate things, why not use the hc.name as in implicit, 
automatic tag? Access would work with  
http://localhost:4502/system/health/My%20Health%Check, or one particular check 
could be excluded using 
http://localhost:4502/system/health/mytag,-My%20Health%Check (Also in respect 
to SLING-6805)

[~justinedelson] I'm happy to take care of this issue if you have not started 
yet.)

> Request to allow the health check servlet to directly query a single health 
> check by name
> -
>
> Key: SLING-6804
> URL: https://issues.apache.org/jira/browse/SLING-6804
> Project: Sling
>  Issue Type: Improvement
>  Components: Health Check
>Reporter: Clinton H Goudie-Nice
>Assignee: Justin Edelson
>Priority: Minor
>
> AMS has a request to be able to access an individual health check by name
> For example: 
> http://localhost:4502/system/health/named/Sling%20Get%20Servlet.json
> And have it return the results for only this named health check.



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

[jira] [Commented] (SLING-6804) Request to allow the health check servlet to directly query a single health check by name

[Georg Henzler (JIRA)]

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

Georg Henzler commented on SLING-6804:
--

To not complicate things, why not use the fully qualified class name as in 
implicit, automatic tag? (better than the hc.name property that does not work 
nicely in URLs). Access would work with 
http://localhost:4502/system/health/org.comp.proj.MyHealthCheck, or one 
particular check could be excluded using 
http://localhost:4502/system/health/mytag,-org.comp.proj.MyHealthCheck (also in 
respect to SLING-6805)

[~justinedelson] I'm happy to take care of this issue if you have not started 
yet.

> Request to allow the health check servlet to directly query a single health 
> check by name
> -
>
> Key: SLING-6804
> URL: https://issues.apache.org/jira/browse/SLING-6804
> Project: Sling
>  Issue Type: Improvement
>  Components: Health Check
>Reporter: Clinton H Goudie-Nice
>Assignee: Justin Edelson
>Priority: Minor
>
> AMS has a request to be able to access an individual health check by name
> For example: 
> http://localhost:4502/system/health/named/Sling%20Get%20Servlet.json
> And have it return the results for only this named health check.



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

[jira] [Commented] (SLING-6804) Request to allow the health check servlet to directly query a single health check by name

[Georg Henzler (JIRA)]

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

Georg Henzler commented on SLING-6804:
--

To not complicate things, why not use the hc.name as in implicit, automatic 
tag? Access would work with  
http://localhost:4502/system/health/My%20Health%Check, or one particular check 
could be excluded using 
http://localhost:4502/system/health/mytag,-My%20Health%Check (Also in respect 
to SLING-6805)

[~justinedelson] I'm happy to take care of this issue if you have not started 
yet.

> Request to allow the health check servlet to directly query a single health 
> check by name
> -
>
> Key: SLING-6804
> URL: https://issues.apache.org/jira/browse/SLING-6804
> Project: Sling
>  Issue Type: Improvement
>  Components: Health Check
>Reporter: Clinton H Goudie-Nice
>Assignee: Justin Edelson
>Priority: Minor
>
> AMS has a request to be able to access an individual health check by name
> For example: 
> http://localhost:4502/system/health/named/Sling%20Get%20Servlet.json
> And have it return the results for only this named health check.



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