[jira] [Commented] (SLING-6826) i18n: Supported nested keys in JSON i18n files
[ https://issues.apache.org/jira/browse/SLING-6826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 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 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
[ 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 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?
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.
[ 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.
[ 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?
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?
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
[ https://issues.apache.org/jira/browse/SLING-6826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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...
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
[ 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 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
[ 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
[ 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?
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?
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
[ 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
[ https://issues.apache.org/jira/browse/SLING-6825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/SLING-6825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 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
[ https://issues.apache.org/jira/browse/SLING-6804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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&names=-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
[ 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
[ https://issues.apache.org/jira/browse/SLING-6806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/SLING-6804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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
[ 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)