[GitHub] DominikSuess opened a new pull request #1: SLING-8284 - updating parent pom & eliminating dependency on JcrResou…
DominikSuess opened a new pull request #1: SLING-8284 - updating parent pom & eliminating dependency on JcrResou… URL: https://github.com/apache/sling-org-apache-sling-resourcecollection/pull/1 …rceConstants 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-8284) Eliminate dependency of o.a.s.resourcecollection on o.a.s.jcr.resource
Dominik Süß created SLING-8284: -- Summary: Eliminate dependency of o.a.s.resourcecollection on o.a.s.jcr.resource Key: SLING-8284 URL: https://issues.apache.org/jira/browse/SLING-8284 Project: Sling Issue Type: Improvement Reporter: Dominik Süß Althought dependencies between resourcecollection on the jcr.resource api was limited to accessing the constants that should be inlined at compiletime it was observed in at least 2 cases that an import of the jcr.resource API was added to the manifest causing corresponding analysers to fail. To eliminate the scenario all together the dependency on those constants of a deprecated API should be eliminated. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] rombert commented on issue #4: SLING-8283 provide non render blocking version of Sling.getSessionInf…
rombert commented on issue #4: SLING-8283 provide non render blocking version of Sling.getSessionInf… URL: https://github.com/apache/sling-org-apache-sling-servlets-post/pull/4#issuecomment-465300077 A SonarQube report for the changes added _only by this pull request_ was generated. Please review it at https://builds.apache.org/job/Sling/job/sling-org-apache-sling-servlets-post/job/PR-4/1/artifact/target/sonar/issues-report/issues-report-light.html 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-8281) Exceptions in the ConfigInstallTasks should lead to log messages with category "WARN"
[
https://issues.apache.org/jira/browse/SLING-8281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16772312#comment-16772312
]
Carsten Ziegeler commented on SLING-8281:
-
I guess there is a reason why its currently debug, and I think this was due to
getting a lot of exceptions in the log which later on where recovered from. I
would assume that IOExceptions thrown by configadmin fall into this category.
Not sure what else there is. Everything else should be regarded as an error,
properly logged in the audit log and the resource needs to be marked so its not
retried again
> Exceptions in the ConfigInstallTasks should lead to log messages with
> category "WARN"
> -
>
> Key: SLING-8281
> URL: https://issues.apache.org/jira/browse/SLING-8281
> Project: Sling
> Issue Type: Bug
> Components: Installer
>Affects Versions: Installer Configuration Factory 1.2.0
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently any exception being issued in {{ConfigInstallTask}} only leads to a
> debug level log entry
> (https://github.com/apache/sling-org-apache-sling-installer-factory-configuration/blob/fc2a63c8036843ba0db96686c33c10aeff99b74d/src/main/java/org/apache/sling/installer/factories/configuration/impl/ConfigInstallTask.java#L87).
> Instead those exceptions should be logged with level "WARN". Otherwise it
> will be quite hard to track issues like the one being outlined in SLING-8280.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SLING-8281) Exceptions in the ConfigInstallTasks should lead to log messages with category "WARN"
[
https://issues.apache.org/jira/browse/SLING-8281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16772306#comment-16772306
]
Konrad Windszus commented on SLING-8281:
Which exceptions could we expect here which are recoverable? IMHO primarily the
non-recoverable ones should lead to exceptions.
> Exceptions in the ConfigInstallTasks should lead to log messages with
> category "WARN"
> -
>
> Key: SLING-8281
> URL: https://issues.apache.org/jira/browse/SLING-8281
> Project: Sling
> Issue Type: Bug
> Components: Installer
>Affects Versions: Installer Configuration Factory 1.2.0
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently any exception being issued in {{ConfigInstallTask}} only leads to a
> debug level log entry
> (https://github.com/apache/sling-org-apache-sling-installer-factory-configuration/blob/fc2a63c8036843ba0db96686c33c10aeff99b74d/src/main/java/org/apache/sling/installer/factories/configuration/impl/ConfigInstallTask.java#L87).
> Instead those exceptions should be logged with level "WARN". Otherwise it
> will be quite hard to track issues like the one being outlined in SLING-8280.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SLING-8281) Exceptions in the ConfigInstallTasks should lead to log messages with category "WARN"
[
https://issues.apache.org/jira/browse/SLING-8281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16772294#comment-16772294
]
Carsten Ziegeler commented on SLING-8281:
-
There are recoverable errors and non recoverable ones, for the later ones it
makes sense to log them as error. For the first category debug is fine.
Or in other words, if the error is not logged as debug. the configuration
should not be retried. In this case this should go to the audit logger
> Exceptions in the ConfigInstallTasks should lead to log messages with
> category "WARN"
> -
>
> Key: SLING-8281
> URL: https://issues.apache.org/jira/browse/SLING-8281
> Project: Sling
> Issue Type: Bug
> Components: Installer
>Affects Versions: Installer Configuration Factory 1.2.0
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently any exception being issued in {{ConfigInstallTask}} only leads to a
> debug level log entry
> (https://github.com/apache/sling-org-apache-sling-installer-factory-configuration/blob/fc2a63c8036843ba0db96686c33c10aeff99b74d/src/main/java/org/apache/sling/installer/factories/configuration/impl/ConfigInstallTask.java#L87).
> Instead those exceptions should be logged with level "WARN". Otherwise it
> will be quite hard to track issues like the one being outlined in SLING-8280.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] rombert commented on issue #1: Sling 8243 - support merge options
rombert commented on issue #1: Sling 8243 - support merge options URL: https://github.com/apache/sling-org-apache-sling-jcr-contentloader/pull/1#issuecomment-465203715 A SonarQube report for the changes added _only by this pull request_ was generated. Please review it at https://builds.apache.org/job/Sling/job/sling-org-apache-sling-jcr-contentloader/job/PR-1/1/artifact/target/sonar/issues-report/issues-report-light.html 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
[GitHub] JEBailey commented on issue #1: Sling 8243 - support merge options
JEBailey commented on issue #1: Sling 8243 - support merge options URL: https://github.com/apache/sling-org-apache-sling-jcr-contentloader/pull/1#issuecomment-465175044 unable to replicate failure locally. investigating, 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
[GitHub] JEBailey opened a new pull request #1: Sling 8243 - support merge options
JEBailey opened a new pull request #1: Sling 8243 - support merge options URL: https://github.com/apache/sling-org-apache-sling-jcr-contentloader/pull/1 Implement a merge option for properties and nodes that will allow you to automatically delete items that aren't imported. Touched a bunch of things here so this pull request is also for me to run through and make sure I didn't leave something touched that I shouldn't have and for my own review. feel free to comment. 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-7269) Update DataSource provider to use Tomcat 8.5.23
[ https://issues.apache.org/jira/browse/SLING-7269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16771976#comment-16771976 ] Julian Reschke commented on SLING-7269: --- :) Please update to the latest applicable. If Java 7 support is needed, please use 7.0.92. Otherwise 8.5.38. > Update DataSource provider to use Tomcat 8.5.23 > --- > > Key: SLING-7269 > URL: https://issues.apache.org/jira/browse/SLING-7269 > Project: Sling > Issue Type: Task > Components: Extensions >Affects Versions: DataSource Provider 1.0.2 >Reporter: Julian Reschke >Assignee: Chetan Mehrotra >Priority: Major > Fix For: DataSource Provider 1.0.4 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SLING-8278) improve chrome audit score
[ https://issues.apache.org/jira/browse/SLING-8278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16771972#comment-16771972 ] Ruben Reusser commented on SLING-8278: -- https://issues.apache.org/jira/browse/SLING-8283 is needed to get the best practices score up > improve chrome audit score > -- > > Key: SLING-8278 > URL: https://issues.apache.org/jira/browse/SLING-8278 > Project: Sling > Issue Type: Improvement > Components: Starter >Reporter: Ruben Reusser >Priority: Trivial > Time Spent: 0.5h > Remaining Estimate: 0h > > google chrome audit currently lists a set of accessibility and seo problems > with the sling starter content. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SLING-8283) httpGet in system/sling.js uses depricated main thread blocking code
[
https://issues.apache.org/jira/browse/SLING-8283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16771970#comment-16771970
]
Ruben Reusser commented on SLING-8283:
--
https://github.com/apache/sling-org-apache-sling-servlets-post/pull/4
> httpGet in system/sling.js uses depricated main thread blocking code
>
>
> Key: SLING-8283
> URL: https://issues.apache.org/jira/browse/SLING-8283
> Project: Sling
> Issue Type: Improvement
> Components: Best practices
>Reporter: Ruben Reusser
>Priority: Major
>
> the sling starter homepage throws the following error in the browser console.
> sling.js:75 [Deprecation] Synchronous XMLHttpRequest on the main thread is
> deprecated because of its detrimental effects to the end user's experience.
> For more help, check
> [https://xhr.spec.whatwg.org/.|https://xhr.spec.whatwg.org/]
> As the error mentions this is due to the fact that sling is using main thread
> blocking calls in /system/sling.js - this is generally not recommended
> anymore as it blocks the ability for a user to interact with the browser
> The problem can easily be solved by using callbacks instead of main thread
> blocking code.
> by altering Sling.httpGet to support callbacks this change can be made
> gradually over time without a break in backwards compatibility
>
> {code:java}
> /**
> * HTTP GET XHR Helper
> * @param {String} url The URL
> * @param {Function} optional second parameter for async version of the
> method.
> *The callback will get the XHR object, method returns immediately
> * @return the XHR object, use .responseText for the data
> * @type String
> */
> Sling.httpGet = function(url, callback) {
> var httpcon = Sling.getXHR();
> if (httpcon) {
> if(callback) {
> httpcon.onload = function() { callback(this); };
> httpcon.open('GET', url);
> httpcon.send(null);
> } else {
> httpcon.open('GET', url, false);
> httpcon.send(null);
> return httpcon;
> }
> } else {
> return null;
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (SLING-8279) Having a Resource + ResourceMetadata should be sufficient for roundtrip link mapping.
[ https://issues.apache.org/jira/browse/SLING-8279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16771962#comment-16771962 ] Brett Birschbach edited comment on SLING-8279 at 2/19/19 2:29 PM: -- Though we could debate the merits of where code should live and probably never come to an agreement... Here's my opinion, in agreement with Mark. 1) The option to construct a URL in a model is already possible since the `request` is available - this is just making it more streamlined. 2) The `requestResolver.map(resource)` and other similar functions that take a resource give a potentially unexpected behavior of ignoring the current request (since the resource conceivably is tied to the request, per Mark's notes) - requiring a developer to explicitly pass `null` in the case that they *actually* want the function to be evaluated outside the context of a request seems like a better coding pattern. 3) Constructing the URL often has additional java logic in a CMS - perhaps you want to inject some logic to translate external URLs that your translation provider doesn't translate (just an example). Ideally that code can stay in the model rather than requiring HTL to jump thru another hoop. I know we can use a `Use` object to do this from the model, but at that point it just feels we are adding code complexity for no objective benefit. 4) For sling model exporters, there is no explicit "view" layer that the developer creates "above" the model - it's a generic request handler. If we don't do the externalization in the model, where would we do it? was (Author: brett.birschbach): Though we could debate the merits of where code should live and probably never come to an agreement... Here's my opinion, in agreement with Mark. 1) The option to construct a URL in a model is already possible since the `request` is available - this is just making it more streamlined 2) The `requestResolver.map(resource)` and other similar functions that take a resource give a potentially unexpected behavior of ignoring the current request (since the resource conceivably is tied to the request, per Mark's notes) - requiring a developer to explicitly pass `null` in the case that they *actually* want the function to be evaluated outside the context of a request seems like a better coding pattern. 3) Constructing the URL often has additional java logic in a CMS - perhaps you want to inject some logic to translate external URLs that your translation provider doesn't translate (just an example). Ideally that code can stay in the model rather than requiring HTL to jump thru another hoop. 4) For sling model exporters, there is no explicit "view" layer that the developer creates "above" the model - it's a generic request handler. If we don't do the externalization in the model, where would we do it? > Having a Resource + ResourceMetadata should be sufficient for roundtrip link > mapping. > - > > Key: SLING-8279 > URL: https://issues.apache.org/jira/browse/SLING-8279 > Project: Sling > Issue Type: Wish > Components: ResourceResolver >Reporter: Mark Adamcin >Priority: Major > > With Sling Models, it is very easy to construct composite model types from > more than one resource, usually addressable as a subtree of the repository. > However, a pattern is emerging where mapping is being performed to create > related links within the model, which mandates that SlingHttpServletRequest > be used as the adaptable type, because a Resource adaptable would not provide > sufficient context for ResourceResolver.map(). Without a request for context, > .map() would likely return incorrect links based on a default base request > URL of "http://localhost/;. > While on one hand, it might be argued that link mapping should only occur in > the view, after the model graph has been constructed, on the other hand, link > resolution and resource mapping are so fundamental to the correct behavior of > a web application that we should take advantage of every opportunity to make > these activities more convenient and less error prone. > If you trace the code for resource resolution and mapping, you will find that > it relies on just four discrete contextual properties that are currently > available only from a request object (i.e. not available from a Resource or > its ResourceMetadata): > # scheme > # host > # port > # contextPath > In addition, given that the ResourceResolver used by servlets when handling a > request is generally retrieved from the Sling Request itself using > getResourceResolver(), it seems redundant in concept, not to mention clumsy > in practice, to require passing the request as an argument back to the > resource resolver (that
[jira] [Commented] (SLING-8279) Having a Resource + ResourceMetadata should be sufficient for roundtrip link mapping.
[ https://issues.apache.org/jira/browse/SLING-8279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16771962#comment-16771962 ] Brett Birschbach commented on SLING-8279: - Though we could debate the merits of where code should live and probably never come to an agreement... Here's my opinion, in agreement with Mark. 1) The option to construct a URL in a model is already possible since the `request` is available - this is just making it more streamlined 2) The `requestResolver.map(resource)` and other similar functions that take a resource give a potentially unexpected behavior of ignoring the current request (since the resource conceivably is tied to the request, per Mark's notes) - requiring a developer to explicitly pass `null` in the case that they *actually* want the function to be evaluated outside the context of a request seems like a better coding pattern. 3) Constructing the URL often has additional java logic in a CMS - perhaps you want to inject some logic to translate external URLs that your translation provider doesn't translate (just an example). Ideally that code can stay in the model rather than requiring HTL to jump thru another hoop. 4) For sling model exporters, there is no explicit "view" layer that the developer creates "above" the model - it's a generic request handler. If we don't do the externalization in the model, where would we do it? > Having a Resource + ResourceMetadata should be sufficient for roundtrip link > mapping. > - > > Key: SLING-8279 > URL: https://issues.apache.org/jira/browse/SLING-8279 > Project: Sling > Issue Type: Wish > Components: ResourceResolver >Reporter: Mark Adamcin >Priority: Major > > With Sling Models, it is very easy to construct composite model types from > more than one resource, usually addressable as a subtree of the repository. > However, a pattern is emerging where mapping is being performed to create > related links within the model, which mandates that SlingHttpServletRequest > be used as the adaptable type, because a Resource adaptable would not provide > sufficient context for ResourceResolver.map(). Without a request for context, > .map() would likely return incorrect links based on a default base request > URL of "http://localhost/;. > While on one hand, it might be argued that link mapping should only occur in > the view, after the model graph has been constructed, on the other hand, link > resolution and resource mapping are so fundamental to the correct behavior of > a web application that we should take advantage of every opportunity to make > these activities more convenient and less error prone. > If you trace the code for resource resolution and mapping, you will find that > it relies on just four discrete contextual properties that are currently > available only from a request object (i.e. not available from a Resource or > its ResourceMetadata): > # scheme > # host > # port > # contextPath > In addition, given that the ResourceResolver used by servlets when handling a > request is generally retrieved from the Sling Request itself using > getResourceResolver(), it seems redundant in concept, not to mention clumsy > in practice, to require passing the request as an argument back to the > resource resolver (that was created specifically for the request in question) > in order to render links for any resources resolved while servicing that > request. > I think it is time to change the expected behavior of > ResourceResolver.resolve(String), ResourceResolver.map(String path), and > other ResourceResolver methods that return resources without an explicit > HttpServletRequest parameter, such that: > # request.getResourceResolver().resolve(path) returns the same Resource as > (any ResourceResolver).resolve(request, path) > # request.getResourceResolver().map(path) returns the same String as (any > ResourceResolver).map(request, path) > # > request.getResourceResolver().getResource(somePath).getResourceResolver().resolve(path) > returns the same Resource as request.getResourceResolver().resolve(path) > # > request.getResourceResolver().findResources(someQuery).next().getResourceResolver().resolve(path) > returns the same Resource as request.getResourceResolver().resolve(path) > # etc. > # ResourceResolverFactory.getResourceResolver(Map) and > ResourceResolverFactory.getServiceResourceResolver(Map) would return > ResourceResolvers that continue to use > [http://localhost:80|http://localhost/] as the default context url. > If these constraints can not be satisfied reasonably using the existing > resolve(String) and map(String) methods, I would propose adding overloads > that accept a context Resource in place of the context
[GitHub] reusr1 opened a new pull request #4: SLING-8278 provide non render blocking version of Sling.getSessionInf…
reusr1 opened a new pull request #4: SLING-8278 provide non render blocking version of Sling.getSessionInf… URL: https://github.com/apache/sling-org-apache-sling-servlets-post/pull/4 …o and Sling.httpGet 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] [Updated] (SLING-7270) Update paxexam dependency to 3.5.0
[ https://issues.apache.org/jira/browse/SLING-7270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu updated SLING-7270: --- Fix Version/s: (was: DataSource Provider 1.0.4) DataSource Provider 1.0.6 > Update paxexam dependency to 3.5.0 > -- > > Key: SLING-7270 > URL: https://issues.apache.org/jira/browse/SLING-7270 > Project: Sling > Issue Type: Task > Components: Commons >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra >Priority: Minor > Fix For: DataSource Provider 1.0.6 > > > Update the dependencies for pax exam > * Pax Exam 3.5.0 > * Felix Framework 5.6.2 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SLING-4397) JDBC Datasource: Add support for system/framework properties
[ https://issues.apache.org/jira/browse/SLING-4397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu updated SLING-4397: --- Fix Version/s: (was: DataSource Provider 1.0.4) DataSource Provider 1.0.6 > JDBC Datasource: Add support for system/framework properties > > > Key: SLING-4397 > URL: https://issues.apache.org/jira/browse/SLING-4397 > Project: Sling > Issue Type: Improvement > Components: Extensions >Reporter: Amit Jain >Priority: Major > Fix For: DataSource Provider 1.0.6 > > > Currently, the DB properties are configured through a file. For db connection > properties like url, username, password it is better to provide an override > mechanism through the system properties. > This would enable applications to bundle a default config which can be > overridden through command-line. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SLING-7269) Update DataSource provider to use Tomcat 8.5.23
[ https://issues.apache.org/jira/browse/SLING-7269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16771956#comment-16771956 ] Robert Munteanu commented on SLING-7269: [~reschke] - in SLING-7799 you asked for an update to 7.0.90, and in this ticket to 8.5.23 . I'm planning to make a release, do you think it's useful to update to another version before doing that? > Update DataSource provider to use Tomcat 8.5.23 > --- > > Key: SLING-7269 > URL: https://issues.apache.org/jira/browse/SLING-7269 > Project: Sling > Issue Type: Task > Components: Extensions >Affects Versions: DataSource Provider 1.0.2 >Reporter: Julian Reschke >Assignee: Chetan Mehrotra >Priority: Major > Fix For: DataSource Provider 1.0.4 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (SLING-8283) httpGet in system/sling.js uses depricated main thread blocking code
Ruben Reusser created SLING-8283:
Summary: httpGet in system/sling.js uses depricated main thread
blocking code
Key: SLING-8283
URL: https://issues.apache.org/jira/browse/SLING-8283
Project: Sling
Issue Type: Improvement
Components: Best practices
Reporter: Ruben Reusser
the sling starter homepage throws the following error in the browser console.
sling.js:75 [Deprecation] Synchronous XMLHttpRequest on the main thread is
deprecated because of its detrimental effects to the end user's experience. For
more help, check [https://xhr.spec.whatwg.org/.|https://xhr.spec.whatwg.org/]
As the error mentions this is due to the fact that sling is using main thread
blocking calls in /system/sling.js - this is generally not recommended anymore
as it blocks the ability for a user to interact with the browser
The problem can easily be solved by using callbacks instead of main thread
blocking code.
by altering Sling.httpGet to support callbacks this change can be made
gradually over time without a break in backwards compatibility
{code:java}
/**
* HTTP GET XHR Helper
* @param {String} url The URL
* @param {Function} optional second parameter for async version of the method.
*The callback will get the XHR object, method returns immediately
* @return the XHR object, use .responseText for the data
* @type String
*/
Sling.httpGet = function(url, callback) {
var httpcon = Sling.getXHR();
if (httpcon) {
if(callback) {
httpcon.onload = function() { callback(this); };
httpcon.open('GET', url);
httpcon.send(null);
} else {
httpcon.open('GET', url, false);
httpcon.send(null);
return httpcon;
}
} else {
return null;
}
}
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (SLING-7157) metatype.properties file must not be in OSGI-INF/metatype
[ https://issues.apache.org/jira/browse/SLING-7157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu updated SLING-7157: --- Description: According to the spec the metatype.properties file must not be inside the OSGI-INF/metatype directory. This is against the spec, so we should move it to OSGI-INF/l10n We probably should also upgrade the maven-scr-plugin for this 1.25.0 or rather switch to OSGi annotations. I found the following files: ./bundles/auth/core/src/main/resources/OSGI-INF/metatype/metatype.properties ./bundles/auth/form/src/main/resources/OSGI-INF/metatype/metatype.properties ./bundles/commons/log/src/main/resources/OSGI-INF/metatype/metatype.properties ./bundles/commons/threads/src/main/resources/OSGI-INF/metatype/metatype.properties ./bundles/extensions/discovery/impl/src/main/resources/OSGI-INF/metatype/metatype.properties ./bundles/extensions/discovery/oak/src/main/resources/OSGI-INF/metatype/metatype.properties ./bundles/extensions/settings/src/main/resources/OSGI-INF/metatype/metatype.properties ./bundles/jcr/classloader/src/main/resources/OSGI-INF/metatype/metatype.properties ./bundles/jcr/davex/src/main/resources/OSGI-INF/metatype/metatype.properties ./bundles/jcr/registration/src/main/resources/OSGI-INF/metatype/metatype.properties ./bundles/jcr/webconsole/src/main/resources/OSGI-INF/metatype/metatype.properties ./bundles/jcr/webdav/src/main/resources/OSGI-INF/metatype/metatype.properties ./contrib/auth/org.apache.sling.auth.xing.login/src/main/resources/OSGI-INF/metatype/metatype.properties ./contrib/auth/org.apache.sling.auth.xing.oauth/src/main/resources/OSGI-INF/metatype/metatype.properties ./contrib/extensions/datasource/src/main/resources/OSGI-INF/metatype/metatype.properties ./contrib/extensions/mongodb/src/main/resources/OSGI-INF/metatype/metatype.properties ./contrib/extensions/slf4j-mdc/src/main/resources/OSGI-INF/metatype/metatype.properties ./contrib/extensions/startup-filter/src/main/resources/OSGI-INF/metatype/metatype.properties ./contrib/extensions/urlrewriter/src/main/resources/OSGI-INF/metatype/metatype.properties ./installer/providers/jcr/src/main/resources/OSGI-INF/metatype/metatype.properties ./samples/path-based-rtp/src/main/resources/OSGI-INF/metatype/metatype.properties ./samples/workspacepicker/src/main/resources/OSGI-INF/metatype/metatype.properties ./testing/junit/core/src/main/resources/OSGI-INF/metatype/metatype.properties ./testing/junit/healthcheck/src/main/resources/OSGI-INF/metatype/metatype.properties ||Module||Status|| |Auth Core| | |Auth Form|(/)| |Commons Log|(/)| |Commons Threads|(/)| |Discovery Impl| | |Discovery Oak| | |Settings|(/)| |JCR ClassLoader| | |JCR DavEx| | |JCR Registration|(/)| |JCR WebConsole| | |JCR WebDav| | |Auth XING Login| | |Auth XING Oauth| | |Datasource| (/) SLING-8282| |MongoDB Resource Provider| | |SLF4J MDC Filter| | |Startup Filter| | |URL Rewriter| | |Installer JCR Providers| | |Samples Path-based RTP| | |Samples Workspacepicker| | |Testing JUnit Core| | |Testing JUnit Healthcheck| | was: According to the spec the metatype.properties file must not be inside the OSGI-INF/metatype directory. This is against the spec, so we should move it to OSGI-INF/l10n We probably should also upgrade the maven-scr-plugin for this 1.25.0 or rather switch to OSGi annotations. I found the following files: ./bundles/auth/core/src/main/resources/OSGI-INF/metatype/metatype.properties ./bundles/auth/form/src/main/resources/OSGI-INF/metatype/metatype.properties ./bundles/commons/log/src/main/resources/OSGI-INF/metatype/metatype.properties ./bundles/commons/threads/src/main/resources/OSGI-INF/metatype/metatype.properties ./bundles/extensions/discovery/impl/src/main/resources/OSGI-INF/metatype/metatype.properties ./bundles/extensions/discovery/oak/src/main/resources/OSGI-INF/metatype/metatype.properties ./bundles/extensions/settings/src/main/resources/OSGI-INF/metatype/metatype.properties ./bundles/jcr/classloader/src/main/resources/OSGI-INF/metatype/metatype.properties ./bundles/jcr/davex/src/main/resources/OSGI-INF/metatype/metatype.properties ./bundles/jcr/registration/src/main/resources/OSGI-INF/metatype/metatype.properties ./bundles/jcr/webconsole/src/main/resources/OSGI-INF/metatype/metatype.properties ./bundles/jcr/webdav/src/main/resources/OSGI-INF/metatype/metatype.properties ./contrib/auth/org.apache.sling.auth.xing.login/src/main/resources/OSGI-INF/metatype/metatype.properties ./contrib/auth/org.apache.sling.auth.xing.oauth/src/main/resources/OSGI-INF/metatype/metatype.properties ./contrib/extensions/datasource/src/main/resources/OSGI-INF/metatype/metatype.properties ./contrib/extensions/mongodb/src/main/resources/OSGI-INF/metatype/metatype.properties ./contrib/extensions/slf4j-mdc/src/main/resources/OSGI-INF/metatype/metatype.properties
[jira] [Updated] (SLING-7157) metatype.properties file must not be in OSGI-INF/metatype
[ https://issues.apache.org/jira/browse/SLING-7157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu updated SLING-7157: --- Fix Version/s: (was: DataSource Provider 1.0.4) > metatype.properties file must not be in OSGI-INF/metatype > - > > Key: SLING-7157 > URL: https://issues.apache.org/jira/browse/SLING-7157 > Project: Sling > Issue Type: Bug >Affects Versions: JCR Web Console 1.0.2, JCR Registration 1.0.2, JCR > ClassLoader 3.2.2, Form Based Authentication 1.0.8, Settings 1.3.8, Commons > Threads 3.2.6, Auth Core 1.4.0, SLF4J MDC Filter 1.0.0, Authentication XING > OAuth 0.0.2, Authentication XING Login 0.0.2, URL Rewriter 0.0.2, DataSource > Provider 1.0.4, NoSQL MongoDB Resource Provider 1.1.0, Commons Log 5.0.2, > Discovery Impl 1.2.12, Discovery Oak 1.2.18, JCR Davex 1.3.8, JCR Webdav > 2.3.8, JCR Installer 3.1.26 >Reporter: Carsten Ziegeler >Priority: Blocker > Fix For: JCR Web Console 1.0.4, Settings 1.3.10, Auth Core 1.4.4, > Mongo Resource Provider 1.0.0, Authentication XING OAuth 0.0.4, > Authentication XING Login 0.0.4, URL Rewriter 0.0.4, Commons Log 5.1.0, > Commons Threads 3.2.10, SLF4J MDC Filter 1.0.2, JCR Webdav 2.3.10, JCR > Installer 3.1.28, Discovery Impl 1.2.14, Discovery Oak 1.2.30, JCR Davex > 1.3.12, JCR ClassLoader 3.2.6 > > > According to the spec the metatype.properties file must not be inside the > OSGI-INF/metatype directory. This is against the spec, so we should move it > to OSGI-INF/l10n > We probably should also upgrade the maven-scr-plugin for this 1.25.0 or > rather switch to OSGi annotations. > I found the following files: > ./bundles/auth/core/src/main/resources/OSGI-INF/metatype/metatype.properties > ./bundles/auth/form/src/main/resources/OSGI-INF/metatype/metatype.properties > ./bundles/commons/log/src/main/resources/OSGI-INF/metatype/metatype.properties > ./bundles/commons/threads/src/main/resources/OSGI-INF/metatype/metatype.properties > ./bundles/extensions/discovery/impl/src/main/resources/OSGI-INF/metatype/metatype.properties > ./bundles/extensions/discovery/oak/src/main/resources/OSGI-INF/metatype/metatype.properties > ./bundles/extensions/settings/src/main/resources/OSGI-INF/metatype/metatype.properties > ./bundles/jcr/classloader/src/main/resources/OSGI-INF/metatype/metatype.properties > ./bundles/jcr/davex/src/main/resources/OSGI-INF/metatype/metatype.properties > ./bundles/jcr/registration/src/main/resources/OSGI-INF/metatype/metatype.properties > ./bundles/jcr/webconsole/src/main/resources/OSGI-INF/metatype/metatype.properties > ./bundles/jcr/webdav/src/main/resources/OSGI-INF/metatype/metatype.properties > ./contrib/auth/org.apache.sling.auth.xing.login/src/main/resources/OSGI-INF/metatype/metatype.properties > ./contrib/auth/org.apache.sling.auth.xing.oauth/src/main/resources/OSGI-INF/metatype/metatype.properties > ./contrib/extensions/datasource/src/main/resources/OSGI-INF/metatype/metatype.properties > ./contrib/extensions/mongodb/src/main/resources/OSGI-INF/metatype/metatype.properties > ./contrib/extensions/slf4j-mdc/src/main/resources/OSGI-INF/metatype/metatype.properties > ./contrib/extensions/startup-filter/src/main/resources/OSGI-INF/metatype/metatype.properties > ./contrib/extensions/urlrewriter/src/main/resources/OSGI-INF/metatype/metatype.properties > ./installer/providers/jcr/src/main/resources/OSGI-INF/metatype/metatype.properties > ./samples/path-based-rtp/src/main/resources/OSGI-INF/metatype/metatype.properties > ./samples/workspacepicker/src/main/resources/OSGI-INF/metatype/metatype.properties > ./testing/junit/core/src/main/resources/OSGI-INF/metatype/metatype.properties > ./testing/junit/healthcheck/src/main/resources/OSGI-INF/metatype/metatype.properties > || Module || Status || > |Auth Core| | > |Auth Form|(/)| > |Commons Log|(/)| > |Commons Threads|(/)| > |Discovery Impl| | > |Discovery Oak| | > |Settings|(/)| > |JCR ClassLoader| | > |JCR DavEx| | > |JCR Registration|(/)| > |JCR WebConsole| | > |JCR WebDav| | > |Auth XING Login| | > |Auth XING Oauth| | > |Datasource| | > |MongoDB Resource Provider| | > |SLF4J MDC Filter| | > |Startup Filter| | > |URL Rewriter| | > |Installer JCR Providers| | > |Samples Path-based RTP| | > |Samples Workspacepicker| | > |Testing JUnit Core| | > |Testing JUnit Healthcheck| | -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (SLING-8282) DataSource: metattype.properties must not be in OSGI-INF/metatype
Robert Munteanu created SLING-8282: -- Summary: DataSource: metattype.properties must not be in OSGI-INF/metatype Key: SLING-8282 URL: https://issues.apache.org/jira/browse/SLING-8282 Project: Sling Issue Type: Sub-task Components: Extensions Reporter: Robert Munteanu Assignee: Robert Munteanu Fix For: DataSource Provider 1.0.4 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (SLING-8282) DataSource: metatype.properties must not be in OSGI-INF/metatype
[ https://issues.apache.org/jira/browse/SLING-8282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu resolved SLING-8282. Resolution: Fixed Fixed with [sling-org-apache-sling-datasource commit cc105d5|https://github.com/apache/sling-org-apache-sling-datasource/commit/cc105d5] > DataSource: metatype.properties must not be in OSGI-INF/metatype > > > Key: SLING-8282 > URL: https://issues.apache.org/jira/browse/SLING-8282 > Project: Sling > Issue Type: Sub-task > Components: Extensions >Reporter: Robert Munteanu >Assignee: Robert Munteanu >Priority: Major > Fix For: DataSource Provider 1.0.4 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SLING-8282) DataSource: metatype.properties must not be in OSGI-INF/metatype
[ https://issues.apache.org/jira/browse/SLING-8282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu updated SLING-8282: --- Summary: DataSource: metatype.properties must not be in OSGI-INF/metatype (was: DataSource: metattype.properties must not be in OSGI-INF/metatype) > DataSource: metatype.properties must not be in OSGI-INF/metatype > > > Key: SLING-8282 > URL: https://issues.apache.org/jira/browse/SLING-8282 > Project: Sling > Issue Type: Sub-task > Components: Extensions >Reporter: Robert Munteanu >Assignee: Robert Munteanu >Priority: Major > Fix For: DataSource Provider 1.0.4 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SLING-8280) OSGi Installer stuck if config file with primitive array was once deployed
[
https://issues.apache.org/jira/browse/SLING-8280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated SLING-8280:
---
Affects Version/s: (was: Installer Configuration Factory 1.2.0)
Installer Configuration Factory 1.1.2
> OSGi Installer stuck if config file with primitive array was once deployed
> --
>
> Key: SLING-8280
> URL: https://issues.apache.org/jira/browse/SLING-8280
> Project: Sling
> Issue Type: Bug
> Components: Installer
>Affects Versions: Installer Configuration Factory 1.1.2
>Reporter: Konrad Windszus
>Priority: Major
>
> After a {{.config}} file is either deployed via the {{JcrInstaller}} or the
> {{FileInstaller}} with a primitive array type (e.g. with a upper case "I"
> character type code,
> https://sling.apache.org/documentation/bundles/configuration-installer-factory.html#configuration-files-config)
> it can no longer be updated. Even if afterwards the config file is modified
> the according config won't be updated.
> The following exception can be found in the log
> {code}
> 19.02.2019 12:36:24.698 *DEBUG* [OsgiInstallerImpl]
> org.apache.sling.installer.factories.configuration.impl.ConfigInstallTask
> Exception during installation of config
> TaskResource(url=jcrinstall:/apps/onemarketing/config/caconfig/io.wcm.caconfig.extensions.contextpath.impl.AbsoluteParentContextPathStrategy-onemarketing.config,
>
> entity=config:io.wcm.caconfig.extensions.contextpath.impl.AbsoluteParentContextPathStrategy.onemarketing,
> state=INSTALL,
> attributes=[org.apache.sling.installer.api.tasks.ResourceTransformer=:32:,
> service.factoryPid=io.wcm.caconfig.extensions.contextpath.impl.AbsoluteParentContextPathStrategy,
> service.pid=onemarketing], digest=80a2f771b2a0f7c91bfdc3fe69a9a1d4) : [I
> cannot be cast to [Ljava.lang.Object;. Retrying later.
> java.lang.ClassCastException: [I cannot be cast to [Ljava.lang.Object;
> at
> org.apache.sling.installer.factories.configuration.impl.ConfigUtil.isSameData(ConfigUtil.java:88)
> [org.apache.sling.installer.factory.configuration:1.1.2]
> at
> org.apache.sling.installer.factories.configuration.impl.ConfigInstallTask.execute(ConfigInstallTask.java:66)
> [org.apache.sling.installer.factory.configuration:1.1.2]
> at
> org.apache.sling.installer.core.impl.OsgiInstallerImpl.doExecuteTasks(OsgiInstallerImpl.java:902)
> [org.apache.sling.installer.core:3.8.12]
> at
> org.apache.sling.installer.core.impl.OsgiInstallerImpl.executeTasks(OsgiInstallerImpl.java:737)
> [org.apache.sling.installer.core:3.8.12]
> at
> org.apache.sling.installer.core.impl.OsgiInstallerImpl.run(OsgiInstallerImpl.java:287)
> [org.apache.sling.installer.core:3.8.12]
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SLING-5779) Packaged OSGi config intermittently do not get installed before bundle start
[
https://issues.apache.org/jira/browse/SLING-5779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16771871#comment-16771871
]
Konrad Windszus commented on SLING-5779:
[~cziegeler] Could you document this property in
https://sling.apache.org/documentation/bundles/osgi-installer.html?
> Packaged OSGi config intermittently do not get installed before bundle start
>
>
> Key: SLING-5779
> URL: https://issues.apache.org/jira/browse/SLING-5779
> Project: Sling
> Issue Type: Bug
> Components: Installer
>Reporter: Robert Munteanu
>Assignee: Carsten Ziegeler
>Priority: Major
> Fix For: Installer Core 3.8.0, Installer Configuration Factory
> 1.2.0
>
> Attachments: error.log.gz, stdout.log.gz
>
>
> (Setting version to Launchpad for now until we find out the root cause).
> From time to time I see the launchpad failing to start properly. The first
> error that is visible is {noformat}10.06.2016 18:18:48.826 *ERROR*
> [OsgiInstallerImpl] org.apache.jackrabbit.oak-lucene
> [org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexProviderService(31)]
> The activate method has thrown an exception (java.lang.NullPointerException:
> Index directory cannot be determined as neither index directory path
> [localIndexDir] nor repository home [repository.home] defined)
> java.lang.NullPointerException: Index directory cannot be determined as
> neither index directory path [localIndexDir] nor repository home
> [repository.home] defined
> at
> com.google.common.base.Preconditions.checkNotNull(Preconditions.java:236){noformat}
> That's weird since the provisioning model holds all the configurations and
> the relevant bundles are present in the {{:boot}} feature → Start Level 1.
> My launchpad jar was built from r1747733 ( but of course SNAPSHOT
> dependencies mean that someone else building the launchpad will not get the
> same exact output ).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SLING-7787) Support official JSON format for configurations
[ https://issues.apache.org/jira/browse/SLING-7787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16771868#comment-16771868 ] Konrad Windszus commented on SLING-7787: [~cziegeler] Can you add some documentation around that in https://sling.apache.org/documentation/bundles/configuration-installer-factory.html#configurations? > Support official JSON format for configurations > --- > > Key: SLING-7787 > URL: https://issues.apache.org/jira/browse/SLING-7787 > Project: Sling > Issue Type: Improvement > Components: Installer >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler >Priority: Major > Fix For: Installer Configuration Factory 1.2.0, Installer Core > 3.9.0 > > > The OSGi R7 configurator specification defines a JSON format for > configurations which is an official format to represent an OSGi configuration > as text. > We should support this format -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SLING-8281) Exceptions in the ConfigInstallTasks should lead to log messages with category "WARN"
[
https://issues.apache.org/jira/browse/SLING-8281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16771859#comment-16771859
]
Konrad Windszus commented on SLING-8281:
[~cziegeler] WDYT about changing
https://github.com/apache/sling-org-apache-sling-installer-factory-configuration/blob/fc2a63c8036843ba0db96686c33c10aeff99b74d/src/main/java/org/apache/sling/installer/factories/configuration/impl/ConfigInstallTask.java#L87
to log level warn?
> Exceptions in the ConfigInstallTasks should lead to log messages with
> category "WARN"
> -
>
> Key: SLING-8281
> URL: https://issues.apache.org/jira/browse/SLING-8281
> Project: Sling
> Issue Type: Bug
> Components: Installer
>Affects Versions: Installer Configuration Factory 1.2.0
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently any exception being issued in {{ConfigInstallTask}} only leads to a
> debug level log entry
> (https://github.com/apache/sling-org-apache-sling-installer-factory-configuration/blob/fc2a63c8036843ba0db96686c33c10aeff99b74d/src/main/java/org/apache/sling/installer/factories/configuration/impl/ConfigInstallTask.java#L87).
> Instead those exceptions should be logged with level "WARN". Otherwise it
> will be quite hard to track issues like the one being outlined in SLING-8280.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (SLING-8281) Exceptions in the ConfigInstallTasks should lead to log messages with category "WARN"
Konrad Windszus created SLING-8281:
--
Summary: Exceptions in the ConfigInstallTasks should lead to log
messages with category "WARN"
Key: SLING-8281
URL: https://issues.apache.org/jira/browse/SLING-8281
Project: Sling
Issue Type: Bug
Components: Installer
Affects Versions: Installer Configuration Factory 1.2.0
Reporter: Konrad Windszus
Currently any exception being issued in {{ConfigInstallTask}} only leads to a
debug level log entry
(https://github.com/apache/sling-org-apache-sling-installer-factory-configuration/blob/fc2a63c8036843ba0db96686c33c10aeff99b74d/src/main/java/org/apache/sling/installer/factories/configuration/impl/ConfigInstallTask.java#L87).
Instead those exceptions should be logged with level "WARN". Otherwise it will
be quite hard to track issues like the one being outlined in SLING-8280.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (SLING-8280) OSGi Installer stuck if config file with primitive array was once deployed
[
https://issues.apache.org/jira/browse/SLING-8280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated SLING-8280:
---
Summary: OSGi Installer stuck if config file with primitive array was once
deployed (was: OSGi Installer stuck if config file with wrong type information
given once)
> OSGi Installer stuck if config file with primitive array was once deployed
> --
>
> Key: SLING-8280
> URL: https://issues.apache.org/jira/browse/SLING-8280
> Project: Sling
> Issue Type: Bug
> Components: Installer
>Affects Versions: Installer Configuration Factory 1.2.0
>Reporter: Konrad Windszus
>Priority: Major
>
> After a {{.config}} file is either deployed via the {{JcrInstaller}} or the
> {{FileInstaller}} with a wrong type information (e.g. with a lower-case 1
> character type code,
> https://sling.apache.org/documentation/bundles/configuration-installer-factory.html#configuration-files-config)
> it is stuck in the state "INSTALL". Even if afterwards the config file is
> fixed to have the correct format, the new config won't be deployed
> successfully.
> The following exception can be found in the log
> {code}
> 19.02.2019 12:36:24.698 *DEBUG* [OsgiInstallerImpl]
> org.apache.sling.installer.factories.configuration.impl.ConfigInstallTask
> Exception during installation of config
> TaskResource(url=jcrinstall:/apps/onemarketing/config/caconfig/io.wcm.caconfig.extensions.contextpath.impl.AbsoluteParentContextPathStrategy-onemarketing.config,
>
> entity=config:io.wcm.caconfig.extensions.contextpath.impl.AbsoluteParentContextPathStrategy.onemarketing,
> state=INSTALL,
> attributes=[org.apache.sling.installer.api.tasks.ResourceTransformer=:32:,
> service.factoryPid=io.wcm.caconfig.extensions.contextpath.impl.AbsoluteParentContextPathStrategy,
> service.pid=onemarketing], digest=80a2f771b2a0f7c91bfdc3fe69a9a1d4) : [I
> cannot be cast to [Ljava.lang.Object;. Retrying later.
> java.lang.ClassCastException: [I cannot be cast to [Ljava.lang.Object;
> at
> org.apache.sling.installer.factories.configuration.impl.ConfigUtil.isSameData(ConfigUtil.java:88)
> [org.apache.sling.installer.factory.configuration:1.1.2]
> at
> org.apache.sling.installer.factories.configuration.impl.ConfigInstallTask.execute(ConfigInstallTask.java:66)
> [org.apache.sling.installer.factory.configuration:1.1.2]
> at
> org.apache.sling.installer.core.impl.OsgiInstallerImpl.doExecuteTasks(OsgiInstallerImpl.java:902)
> [org.apache.sling.installer.core:3.8.12]
> at
> org.apache.sling.installer.core.impl.OsgiInstallerImpl.executeTasks(OsgiInstallerImpl.java:737)
> [org.apache.sling.installer.core:3.8.12]
> at
> org.apache.sling.installer.core.impl.OsgiInstallerImpl.run(OsgiInstallerImpl.java:287)
> [org.apache.sling.installer.core:3.8.12]
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SLING-8280) OSGi Installer stuck if config file with wrong type information given once
[
https://issues.apache.org/jira/browse/SLING-8280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16771846#comment-16771846
]
Konrad Windszus commented on SLING-8280:
This is actually a duplicate of SLING-6247.
> OSGi Installer stuck if config file with wrong type information given once
> --
>
> Key: SLING-8280
> URL: https://issues.apache.org/jira/browse/SLING-8280
> Project: Sling
> Issue Type: Bug
> Components: Installer
>Affects Versions: Installer Configuration Factory 1.2.0
>Reporter: Konrad Windszus
>Priority: Major
>
> After a {{.config}} file is either deployed via the {{JcrInstaller}} or the
> {{FileInstaller}} with a wrong type information (e.g. with a lower-case 1
> character type code,
> https://sling.apache.org/documentation/bundles/configuration-installer-factory.html#configuration-files-config)
> it is stuck in the state "INSTALL". Even if afterwards the config file is
> fixed to have the correct format, the new config won't be deployed
> successfully.
> The following exception can be found in the log
> {code}
> 19.02.2019 12:36:24.698 *DEBUG* [OsgiInstallerImpl]
> org.apache.sling.installer.factories.configuration.impl.ConfigInstallTask
> Exception during installation of config
> TaskResource(url=jcrinstall:/apps/onemarketing/config/caconfig/io.wcm.caconfig.extensions.contextpath.impl.AbsoluteParentContextPathStrategy-onemarketing.config,
>
> entity=config:io.wcm.caconfig.extensions.contextpath.impl.AbsoluteParentContextPathStrategy.onemarketing,
> state=INSTALL,
> attributes=[org.apache.sling.installer.api.tasks.ResourceTransformer=:32:,
> service.factoryPid=io.wcm.caconfig.extensions.contextpath.impl.AbsoluteParentContextPathStrategy,
> service.pid=onemarketing], digest=80a2f771b2a0f7c91bfdc3fe69a9a1d4) : [I
> cannot be cast to [Ljava.lang.Object;. Retrying later.
> java.lang.ClassCastException: [I cannot be cast to [Ljava.lang.Object;
> at
> org.apache.sling.installer.factories.configuration.impl.ConfigUtil.isSameData(ConfigUtil.java:88)
> [org.apache.sling.installer.factory.configuration:1.1.2]
> at
> org.apache.sling.installer.factories.configuration.impl.ConfigInstallTask.execute(ConfigInstallTask.java:66)
> [org.apache.sling.installer.factory.configuration:1.1.2]
> at
> org.apache.sling.installer.core.impl.OsgiInstallerImpl.doExecuteTasks(OsgiInstallerImpl.java:902)
> [org.apache.sling.installer.core:3.8.12]
> at
> org.apache.sling.installer.core.impl.OsgiInstallerImpl.executeTasks(OsgiInstallerImpl.java:737)
> [org.apache.sling.installer.core:3.8.12]
> at
> org.apache.sling.installer.core.impl.OsgiInstallerImpl.run(OsgiInstallerImpl.java:287)
> [org.apache.sling.installer.core:3.8.12]
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (SLING-8280) OSGi Installer stuck if config file with primitive array was once deployed
[
https://issues.apache.org/jira/browse/SLING-8280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated SLING-8280:
---
Description:
After a {{.config}} file is either deployed via the {{JcrInstaller}} or the
{{FileInstaller}} with a primitive array type (e.g. with a upper case "I"
character type code,
https://sling.apache.org/documentation/bundles/configuration-installer-factory.html#configuration-files-config)
it can no longer be updated. Even if afterwards the config file is modified
the according config won't be updated.
The following exception can be found in the log
{code}
19.02.2019 12:36:24.698 *DEBUG* [OsgiInstallerImpl]
org.apache.sling.installer.factories.configuration.impl.ConfigInstallTask
Exception during installation of config
TaskResource(url=jcrinstall:/apps/onemarketing/config/caconfig/io.wcm.caconfig.extensions.contextpath.impl.AbsoluteParentContextPathStrategy-onemarketing.config,
entity=config:io.wcm.caconfig.extensions.contextpath.impl.AbsoluteParentContextPathStrategy.onemarketing,
state=INSTALL,
attributes=[org.apache.sling.installer.api.tasks.ResourceTransformer=:32:,
service.factoryPid=io.wcm.caconfig.extensions.contextpath.impl.AbsoluteParentContextPathStrategy,
service.pid=onemarketing], digest=80a2f771b2a0f7c91bfdc3fe69a9a1d4) : [I
cannot be cast to [Ljava.lang.Object;. Retrying later.
java.lang.ClassCastException: [I cannot be cast to [Ljava.lang.Object;
at
org.apache.sling.installer.factories.configuration.impl.ConfigUtil.isSameData(ConfigUtil.java:88)
[org.apache.sling.installer.factory.configuration:1.1.2]
at
org.apache.sling.installer.factories.configuration.impl.ConfigInstallTask.execute(ConfigInstallTask.java:66)
[org.apache.sling.installer.factory.configuration:1.1.2]
at
org.apache.sling.installer.core.impl.OsgiInstallerImpl.doExecuteTasks(OsgiInstallerImpl.java:902)
[org.apache.sling.installer.core:3.8.12]
at
org.apache.sling.installer.core.impl.OsgiInstallerImpl.executeTasks(OsgiInstallerImpl.java:737)
[org.apache.sling.installer.core:3.8.12]
at
org.apache.sling.installer.core.impl.OsgiInstallerImpl.run(OsgiInstallerImpl.java:287)
[org.apache.sling.installer.core:3.8.12]
at java.lang.Thread.run(Thread.java:748)
{code}
was:
After a {{.config}} file is either deployed via the {{JcrInstaller}} or the
{{FileInstaller}} with a wrong type information (e.g. with a lower-case 1
character type code,
https://sling.apache.org/documentation/bundles/configuration-installer-factory.html#configuration-files-config)
it is stuck in the state "INSTALL". Even if afterwards the config file is
fixed to have the correct format, the new config won't be deployed successfully.
The following exception can be found in the log
{code}
19.02.2019 12:36:24.698 *DEBUG* [OsgiInstallerImpl]
org.apache.sling.installer.factories.configuration.impl.ConfigInstallTask
Exception during installation of config
TaskResource(url=jcrinstall:/apps/onemarketing/config/caconfig/io.wcm.caconfig.extensions.contextpath.impl.AbsoluteParentContextPathStrategy-onemarketing.config,
entity=config:io.wcm.caconfig.extensions.contextpath.impl.AbsoluteParentContextPathStrategy.onemarketing,
state=INSTALL,
attributes=[org.apache.sling.installer.api.tasks.ResourceTransformer=:32:,
service.factoryPid=io.wcm.caconfig.extensions.contextpath.impl.AbsoluteParentContextPathStrategy,
service.pid=onemarketing], digest=80a2f771b2a0f7c91bfdc3fe69a9a1d4) : [I
cannot be cast to [Ljava.lang.Object;. Retrying later.
java.lang.ClassCastException: [I cannot be cast to [Ljava.lang.Object;
at
org.apache.sling.installer.factories.configuration.impl.ConfigUtil.isSameData(ConfigUtil.java:88)
[org.apache.sling.installer.factory.configuration:1.1.2]
at
org.apache.sling.installer.factories.configuration.impl.ConfigInstallTask.execute(ConfigInstallTask.java:66)
[org.apache.sling.installer.factory.configuration:1.1.2]
at
org.apache.sling.installer.core.impl.OsgiInstallerImpl.doExecuteTasks(OsgiInstallerImpl.java:902)
[org.apache.sling.installer.core:3.8.12]
at
org.apache.sling.installer.core.impl.OsgiInstallerImpl.executeTasks(OsgiInstallerImpl.java:737)
[org.apache.sling.installer.core:3.8.12]
at
org.apache.sling.installer.core.impl.OsgiInstallerImpl.run(OsgiInstallerImpl.java:287)
[org.apache.sling.installer.core:3.8.12]
at java.lang.Thread.run(Thread.java:748)
{code}
> OSGi Installer stuck if config file with primitive array was once deployed
> --
>
> Key: SLING-8280
> URL: https://issues.apache.org/jira/browse/SLING-8280
> Project: Sling
> Issue Type: Bug
> Components: Installer
>Affects Versions: Installer Configuration Factory 1.2.0
>Reporter: Konrad Windszus
>
[jira] [Updated] (SLING-8280) OSGi Installer stuck if config file with wrong type information given once
[
https://issues.apache.org/jira/browse/SLING-8280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated SLING-8280:
---
Description:
After a {{.config}} file is either deployed via the {{JcrInstaller}} or the
{{FileInstaller}} with a wrong type information (e.g. with a lower-case 1
character type code,
https://sling.apache.org/documentation/bundles/configuration-installer-factory.html#configuration-files-config)
it is stuck in the state "INSTALL". Even if afterwards the config file is
fixed to have the correct format, the new config won't be deployed successfully.
The following exception can be found in the log
{code}
19.02.2019 12:36:24.698 *DEBUG* [OsgiInstallerImpl]
org.apache.sling.installer.factories.configuration.impl.ConfigInstallTask
Exception during installation of config
TaskResource(url=jcrinstall:/apps/onemarketing/config/caconfig/io.wcm.caconfig.extensions.contextpath.impl.AbsoluteParentContextPathStrategy-onemarketing.config,
entity=config:io.wcm.caconfig.extensions.contextpath.impl.AbsoluteParentContextPathStrategy.onemarketing,
state=INSTALL,
attributes=[org.apache.sling.installer.api.tasks.ResourceTransformer=:32:,
service.factoryPid=io.wcm.caconfig.extensions.contextpath.impl.AbsoluteParentContextPathStrategy,
service.pid=onemarketing], digest=80a2f771b2a0f7c91bfdc3fe69a9a1d4) : [I
cannot be cast to [Ljava.lang.Object;. Retrying later.
java.lang.ClassCastException: [I cannot be cast to [Ljava.lang.Object;
at
org.apache.sling.installer.factories.configuration.impl.ConfigUtil.isSameData(ConfigUtil.java:88)
[org.apache.sling.installer.factory.configuration:1.1.2]
at
org.apache.sling.installer.factories.configuration.impl.ConfigInstallTask.execute(ConfigInstallTask.java:66)
[org.apache.sling.installer.factory.configuration:1.1.2]
at
org.apache.sling.installer.core.impl.OsgiInstallerImpl.doExecuteTasks(OsgiInstallerImpl.java:902)
[org.apache.sling.installer.core:3.8.12]
at
org.apache.sling.installer.core.impl.OsgiInstallerImpl.executeTasks(OsgiInstallerImpl.java:737)
[org.apache.sling.installer.core:3.8.12]
at
org.apache.sling.installer.core.impl.OsgiInstallerImpl.run(OsgiInstallerImpl.java:287)
[org.apache.sling.installer.core:3.8.12]
at java.lang.Thread.run(Thread.java:748)
{code}
was:
After a .config file is either deployed via the {{JCRInstaller}} or the
{{FileInstaller}} with a wrong type information (e.g. with a lower-case 1
character type code,
https://sling.apache.org/documentation/bundles/configuration-installer-factory.html#configuration-files-config)
it is stuck in the state "INSTALL". Even if afterwards the config file is
fixed to have the correct format, the new config won't be deployed successfully.
The following exception can be found in the log
{code}
19.02.2019 12:36:24.698 *DEBUG* [OsgiInstallerImpl]
org.apache.sling.installer.factories.configuration.impl.ConfigInstallTask
Exception during installation of config
TaskResource(url=jcrinstall:/apps/onemarketing/config/caconfig/io.wcm.caconfig.extensions.contextpath.impl.AbsoluteParentContextPathStrategy-onemarketing.config,
entity=config:io.wcm.caconfig.extensions.contextpath.impl.AbsoluteParentContextPathStrategy.onemarketing,
state=INSTALL,
attributes=[org.apache.sling.installer.api.tasks.ResourceTransformer=:32:,
service.factoryPid=io.wcm.caconfig.extensions.contextpath.impl.AbsoluteParentContextPathStrategy,
service.pid=onemarketing], digest=80a2f771b2a0f7c91bfdc3fe69a9a1d4) : [I
cannot be cast to [Ljava.lang.Object;. Retrying later.
java.lang.ClassCastException: [I cannot be cast to [Ljava.lang.Object;
at
org.apache.sling.installer.factories.configuration.impl.ConfigUtil.isSameData(ConfigUtil.java:88)
[org.apache.sling.installer.factory.configuration:1.1.2]
at
org.apache.sling.installer.factories.configuration.impl.ConfigInstallTask.execute(ConfigInstallTask.java:66)
[org.apache.sling.installer.factory.configuration:1.1.2]
at
org.apache.sling.installer.core.impl.OsgiInstallerImpl.doExecuteTasks(OsgiInstallerImpl.java:902)
[org.apache.sling.installer.core:3.8.12]
at
org.apache.sling.installer.core.impl.OsgiInstallerImpl.executeTasks(OsgiInstallerImpl.java:737)
[org.apache.sling.installer.core:3.8.12]
at
org.apache.sling.installer.core.impl.OsgiInstallerImpl.run(OsgiInstallerImpl.java:287)
[org.apache.sling.installer.core:3.8.12]
at java.lang.Thread.run(Thread.java:748)
{code}
> OSGi Installer stuck if config file with wrong type information given once
> --
>
> Key: SLING-8280
> URL: https://issues.apache.org/jira/browse/SLING-8280
> Project: Sling
> Issue Type: Bug
> Components: Installer
>Affects Versions: Installer Configuration Factory 1.2.0
>
[jira] [Created] (SLING-8280) OSGi Installer stuck if config file with wrong type information given once
Konrad Windszus created SLING-8280:
--
Summary: OSGi Installer stuck if config file with wrong type
information given once
Key: SLING-8280
URL: https://issues.apache.org/jira/browse/SLING-8280
Project: Sling
Issue Type: Bug
Components: Installer
Affects Versions: Installer Configuration Factory 1.2.0
Reporter: Konrad Windszus
After a .config file is either deployed via the {{JCRInstaller}} or the
{{FileInstaller}} with a wrong type information (e.g. with a lower-case 1
character type code,
https://sling.apache.org/documentation/bundles/configuration-installer-factory.html#configuration-files-config)
it is stuck in the state "INSTALL". Even if afterwards the config file is
fixed to have the correct format, the new config won't be deployed successfully.
The following exception can be found in the log
{code}
19.02.2019 12:36:24.698 *DEBUG* [OsgiInstallerImpl]
org.apache.sling.installer.factories.configuration.impl.ConfigInstallTask
Exception during installation of config
TaskResource(url=jcrinstall:/apps/onemarketing/config/caconfig/io.wcm.caconfig.extensions.contextpath.impl.AbsoluteParentContextPathStrategy-onemarketing.config,
entity=config:io.wcm.caconfig.extensions.contextpath.impl.AbsoluteParentContextPathStrategy.onemarketing,
state=INSTALL,
attributes=[org.apache.sling.installer.api.tasks.ResourceTransformer=:32:,
service.factoryPid=io.wcm.caconfig.extensions.contextpath.impl.AbsoluteParentContextPathStrategy,
service.pid=onemarketing], digest=80a2f771b2a0f7c91bfdc3fe69a9a1d4) : [I
cannot be cast to [Ljava.lang.Object;. Retrying later.
java.lang.ClassCastException: [I cannot be cast to [Ljava.lang.Object;
at
org.apache.sling.installer.factories.configuration.impl.ConfigUtil.isSameData(ConfigUtil.java:88)
[org.apache.sling.installer.factory.configuration:1.1.2]
at
org.apache.sling.installer.factories.configuration.impl.ConfigInstallTask.execute(ConfigInstallTask.java:66)
[org.apache.sling.installer.factory.configuration:1.1.2]
at
org.apache.sling.installer.core.impl.OsgiInstallerImpl.doExecuteTasks(OsgiInstallerImpl.java:902)
[org.apache.sling.installer.core:3.8.12]
at
org.apache.sling.installer.core.impl.OsgiInstallerImpl.executeTasks(OsgiInstallerImpl.java:737)
[org.apache.sling.installer.core:3.8.12]
at
org.apache.sling.installer.core.impl.OsgiInstallerImpl.run(OsgiInstallerImpl.java:287)
[org.apache.sling.installer.core:3.8.12]
at java.lang.Thread.run(Thread.java:748)
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SLING-6815) Allow for suppression of warning about adapter classes being in private packages
[ https://issues.apache.org/jira/browse/SLING-6815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16771745#comment-16771745 ] Ankit Agarwal commented on SLING-6815: -- [~justinedelson] Please let me know , Shouldn't this property "adapter.allowed.in.private.package" should be documented. Is there any reason why this property was not exposed during this improvement ? > Allow for suppression of warning about adapter classes being in private > packages > > > Key: SLING-6815 > URL: https://issues.apache.org/jira/browse/SLING-6815 > Project: Sling > Issue Type: Improvement > Components: Extensions >Reporter: Justin Edelson >Assignee: Justin Edelson >Priority: Major > Fix For: Adapter 2.1.10, Sling Models Impl 1.4.2 > > > Issue SLING-6658 exposed (at least for me) that while the warning about > adapter classes being in private packages is helpful, there is no way to > suppress it when done intentionally. In the case of Sling Model classes, post > SLING-6658, there is a need for a way to suppress this warning. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
