Jenkins build is still unstable: sling-contrib-1.7 #62
See https://builds.apache.org/job/sling-contrib-1.7/changes
[jira] [Commented] (SLING-4415) :applyTo should not display changeLog (when operation fails)
[
https://issues.apache.org/jira/browse/SLING-4415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14530005#comment-14530005
]
Antonio Sanso commented on SLING-4415:
--
proposed patch
{code}
Index: src/main/java/org/apache/sling/servlets/post/AbstractPostResponse.java
===
--- src/main/java/org/apache/sling/servlets/post/AbstractPostResponse.java
(revision 1675826)
+++ src/main/java/org/apache/sling/servlets/post/AbstractPostResponse.java
(working copy)
@@ -212,11 +212,11 @@
* @return an error or codenull/code
*/
public Throwable getError() {
-return getProperty(PN_ERROR, Throwable.class);
+return new Throwable(Exception during response processing.);
}
public void setError(Throwable error) {
-setProperty(PN_ERROR, error);
+//NOTHING TO DO
}
/**
{code}
:applyTo should not display changeLog (when operation fails)
Key: SLING-4415
URL: https://issues.apache.org/jira/browse/SLING-4415
Project: Sling
Issue Type: Bug
Components: Servlets
Affects Versions: Servlets Post 2.3.6
Reporter: Lars Krapf
Assignee: Antonio Sanso
When the :applyTo operation fails the change-log leaks information about the
internal path-structure even when the requesting session does not have access
to these paths.
One solution would be to completely omit the ChangeLog (at least when the
operation fails), another option would be to make the :sendError behaviour
configurable in the POST servlet, so that the error message can be reliably
overlaid.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Error Message for Sling Post Servlet
hi *,
as noted in SLING-4415 [0] sometimes the Error Message for Sling Post Servlet
might be a little too specific and disclose some information.
IMHO there is no need for this and in some situation as the one for [0] this
might even seen as a vulnerability.
For this reason I’d propose a really simple patch to avoid this once for all:
Index: src/main/java/org/apache/sling/servlets/post/AbstractPostResponse.java
===
--- src/main/java/org/apache/sling/servlets/post/AbstractPostResponse.java
(revision 1675826)
+++ src/main/java/org/apache/sling/servlets/post/AbstractPostResponse.java
(working copy)
@@ -212,11 +212,11 @@
* @return an error or codenull/code
*/
public Throwable getError() {
-return getProperty(PN_ERROR, Throwable.class);
+return new Throwable(Exception during response processing.);
}
public void setError(Throwable error) {
-setProperty(PN_ERROR, error);
+//NOTHING TO DO
}
/**
WDYT?
regards
antonio
[0] https://issues.apache.org/jira/browse/SLING-4415
[jira] [Created] (SLING-4693) Write Sightly generated classes' source code to disk when the scripting engine is in dev mode
Radu Cotescu created SLING-4693:
---
Summary: Write Sightly generated classes' source code to disk when
the scripting engine is in dev mode
Key: SLING-4693
URL: https://issues.apache.org/jira/browse/SLING-4693
Project: Sling
Issue Type: Improvement
Affects Versions: Scripting Sightly Engine 1.0.2
Reporter: Radu Cotescu
Assignee: Radu Cotescu
Fix For: Scripting Sightly Engine 1.0.4
Previous to SLING-4692 generated Java classes' source were available in the
repository. However, the current implementation doesn't write the source code
anywhere any more.
The source code should be written using the default {{ClassLoaderWriter}} to
its default root, but only when the Sightly scripting engine has its dev mode
enabled - see the
{{org.apache.sling.scripting.sightly.impl.engine.SightlyEngineConfiguration}}
OSGi configuration.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SLING-3944) org.apache.sling.scripting.java bundle exports javax.inject package in wrong version
[ https://issues.apache.org/jira/browse/SLING-3944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Richard updated SLING-3944: Attachment: Screen Shot 2015-05-06 at 12.36.05.png [~olli], the exported version is now 0, but it seems like the imported version has been set to [0.0, 1) because of this (see attached screenshot). Won't that cause further problems? org.apache.sling.scripting.java bundle exports javax.inject package in wrong version Key: SLING-3944 URL: https://issues.apache.org/jira/browse/SLING-3944 Project: Sling Issue Type: Bug Components: Scripting Affects Versions: Scripting Java 2.0.10 Reporter: Markus Haack Assignee: Oliver Lietz Priority: Critical Fix For: Scripting Java 2.0.12 Attachments: Screen Shot 2015-05-06 at 12.36.05.png The org.apache.sling.scripting.java bundle exports the package javax.inject in the version of the bundle, which is wrong and should be fixed. This can lead to bundle version problems for other bundles which depend on javax.inject in version [1.0,2) - the correct version (like Jersey Web Services libraries). Either export javax.inject with version 0.0.0 or even better with the correct version 1.0.0. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4694) SlingWebDavServlet should have a configurable Tika detector
[
https://issues.apache.org/jira/browse/SLING-4694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14530414#comment-14530414
]
Satya Deep Maheshwari commented on SLING-4694:
--
I am working on an approach wherein the Sling webdav servlet would be passed a
tika detector via @Reference . The current SlingTikaDetector would also expose
itself as a service and the webdav servlet will get its reference for further
use. Alternatively, one can pass another tika detector to the webdav servlet by
exposing it as a service. Sling quickstart already includes a Tika Osgi bundle
which provides the default TikaDetector which can be used as an alternative to
the internal SlingTikaDetector .
SlingWebDavServlet should have a configurable Tika detector
---
Key: SLING-4694
URL: https://issues.apache.org/jira/browse/SLING-4694
Project: Sling
Issue Type: Improvement
Components: Servlets
Reporter: Satya Deep Maheshwari
*Problem description:* I am facing a problem with the mime type detection of
a file. While debugging, I see that SlingTikaDetector.detect method is used
for detecting the mime type of my file. See [1]. This method just seems to
rely on the name of the file for detecting its mime type. Even though its
passed an inputstream of the file, it does not seem to use it for mime type
detection. So if my file name is something like xyz.tmp, it detects its mime
type as application/octet-stream (the default) while it may actually be a png
file. This is a common scenario with webdav clients wherein temporary files
get created with such names while being edited.
*Suggested Solution:*
Quoting [~rombert]
{quote}
Following the discussions at SLING-1059 [1] and SLING-255 [2] I can
infer that we more or less opted out of the 'heavy-weight' approach of
actually parsing the input stream. Not sure if we want to revisit that
TBH. At any rate, our MimeTypeService does not have an API for getting
the file content based on the input stream.
I think though there's a way around it, but only at the code level.
The org.apache.sling.jcr.webdav.impl.helper.SlingResourceConfig class
hardcodes the Detector implementation to be a SlingTikaDetector.
I think it is worthwile to raise a Jira issue for this and it would
definitely expedite the fix if you're willing to submit a patch / pull
request. I think it can be as simple as adding a @Reference to a Tika
Detector to the SlingWebDavServlet and then passing that to the
SlingServletConfig.
Cheers,
Robert
[1]: https://issues.apache.org/jira/browse/SLING-1059
[2]: https://issues.apache.org/jira/browse/SLING-255
{quote}
Related mailing-list thread on this:
http://apache-sling.73963.n3.nabble.com/mime-type-detection-td4050586.html
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (SLING-4330) selection of script engines (in SlingScriptAdapterFactory) other than by extension
[
https://issues.apache.org/jira/browse/SLING-4330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oliver Lietz reassigned SLING-4330:
---
Assignee: Oliver Lietz
selection of script engines (in SlingScriptAdapterFactory) other than by
extension
--
Key: SLING-4330
URL: https://issues.apache.org/jira/browse/SLING-4330
Project: Sling
Issue Type: New Feature
Components: Scripting
Affects Versions: Scripting Core 2.0.28
Reporter: Oliver Lietz
Assignee: Oliver Lietz
Running multiple script engines for same script (template) extension should
be possible.
Scripting Thymeleaf already provides that parameter, see
{{org.apache.sling.scripting.thymeleaf.SlingTemplateModeHandler#getPatternSpec():org.thymeleaf.PatternSpec}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-4694) SlingWebDavServlet should have a configurable Tika detector
[
https://issues.apache.org/jira/browse/SLING-4694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14530420#comment-14530420
]
Bertrand Delacretaz commented on SLING-4694:
It would be generally useful IMO to create an extended {{MimeTypeService}} to
be able do to content-based mime type detection.
Maybe something like
{code}
public interface ContentAwareMimeTypeService extends MimeTypeService {
/** @param filename used if content is null or if this service does not
support content-based detection
* @param content optional stream that points to the content to analyze
* (TODO explain any relevant constraints on that stream, does it need to
support mark/reset etc)
*/
String getMimeType(String filename, InputStream content);
}
{code}
The webdav code can then use this if available, preferring it to the basic
MimeTypeService.
SlingWebDavServlet should have a configurable Tika detector
---
Key: SLING-4694
URL: https://issues.apache.org/jira/browse/SLING-4694
Project: Sling
Issue Type: Improvement
Components: Servlets
Reporter: Satya Deep Maheshwari
*Problem description:* I am facing a problem with the mime type detection of
a file. While debugging, I see that SlingTikaDetector.detect method is used
for detecting the mime type of my file. See [1]. This method just seems to
rely on the name of the file for detecting its mime type. Even though its
passed an inputstream of the file, it does not seem to use it for mime type
detection. So if my file name is something like xyz.tmp, it detects its mime
type as application/octet-stream (the default) while it may actually be a png
file. This is a common scenario with webdav clients wherein temporary files
get created with such names while being edited.
*Suggested Solution:*
Quoting [~rombert]
{quote}
Following the discussions at SLING-1059 [1] and SLING-255 [2] I can
infer that we more or less opted out of the 'heavy-weight' approach of
actually parsing the input stream. Not sure if we want to revisit that
TBH. At any rate, our MimeTypeService does not have an API for getting
the file content based on the input stream.
I think though there's a way around it, but only at the code level.
The org.apache.sling.jcr.webdav.impl.helper.SlingResourceConfig class
hardcodes the Detector implementation to be a SlingTikaDetector.
I think it is worthwile to raise a Jira issue for this and it would
definitely expedite the fix if you're willing to submit a patch / pull
request. I think it can be as simple as adding a @Reference to a Tika
Detector to the SlingWebDavServlet and then passing that to the
SlingServletConfig.
Cheers,
Robert
[1]: https://issues.apache.org/jira/browse/SLING-1059
[2]: https://issues.apache.org/jira/browse/SLING-255
{quote}
Related mailing-list thread on this:
http://apache-sling.73963.n3.nabble.com/mime-type-detection-td4050586.html
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (SLING-4695) MockNode.getProperties() does not contains jcr:primaryType
Julian Sedding created SLING-4695: - Summary: MockNode.getProperties() does not contains jcr:primaryType Key: SLING-4695 URL: https://issues.apache.org/jira/browse/SLING-4695 Project: Sling Issue Type: Bug Components: Testing Affects Versions: Testing JCR Mock 1.1.4 Reporter: Julian Sedding Assignee: Julian Sedding Priority: Minor The MockNode implementation does not reflect it's primary node type in its property getters, i.e. hasProperty, getProperty, getProperties. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Jenkins build is still unstable: sling-contrib-1.7 #63
See https://builds.apache.org/job/sling-contrib-1.7/changes
[jira] [Resolved] (SLING-4693) Write Sightly generated classes' source code to disk when the scripting engine is in dev mode
[
https://issues.apache.org/jira/browse/SLING-4693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu resolved SLING-4693.
-
Resolution: Fixed
Fixed in [r1677943|https://svn.us.apache.org/r1677943].
Write Sightly generated classes' source code to disk when the scripting
engine is in dev mode
-
Key: SLING-4693
URL: https://issues.apache.org/jira/browse/SLING-4693
Project: Sling
Issue Type: Improvement
Affects Versions: Scripting Sightly Engine 1.0.2
Reporter: Radu Cotescu
Assignee: Radu Cotescu
Fix For: Scripting Sightly Engine 1.0.4
Previous to SLING-4692 generated Java classes' source were available in the
repository. However, the current implementation doesn't write the source code
anywhere any more.
The source code should be written using the default {{ClassLoaderWriter}} to
its default root, but only when the Sightly scripting engine has its dev mode
enabled - see the
{{org.apache.sling.scripting.sightly.impl.engine.SightlyEngineConfiguration}}
OSGi configuration.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (SLING-4694) SlingWebDavServlet should have a configurable Tika detector
Satya Deep Maheshwari created SLING-4694:
Summary: SlingWebDavServlet should have a configurable Tika
detector
Key: SLING-4694
URL: https://issues.apache.org/jira/browse/SLING-4694
Project: Sling
Issue Type: Improvement
Components: Servlets
Reporter: Satya Deep Maheshwari
*Problem description:* I am facing a problem with the mime type detection of a
file. While debugging, I see that SlingTikaDetector.detect method is used for
detecting the mime type of my file. See [1]. This method just seems to rely on
the name of the file for detecting its mime type. Even though its passed an
inputstream of the file, it does not seem to use it for mime type detection. So
if my file name is something like xyz.tmp, it detects its mime type as
application/octet-stream (the default) while it may actually be a png file.
This is a common scenario with webdav clients wherein temporary files get
created with such names while being edited.
*Suggested Solution:*
Quoting [~rombert]
{quote}
Following the discussions at SLING-1059 [1] and SLING-255 [2] I can
infer that we more or less opted out of the 'heavy-weight' approach of
actually parsing the input stream. Not sure if we want to revisit that
TBH. At any rate, our MimeTypeService does not have an API for getting
the file content based on the input stream.
I think though there's a way around it, but only at the code level.
The org.apache.sling.jcr.webdav.impl.helper.SlingResourceConfig class
hardcodes the Detector implementation to be a SlingTikaDetector.
I think it is worthwile to raise a Jira issue for this and it would
definitely expedite the fix if you're willing to submit a patch / pull
request. I think it can be as simple as adding a @Reference to a Tika
Detector to the SlingWebDavServlet and then passing that to the
SlingServletConfig.
Cheers,
Robert
[1]: https://issues.apache.org/jira/browse/SLING-1059
[2]: https://issues.apache.org/jira/browse/SLING-255
{quote}
Related mailing-list thread on this:
http://apache-sling.73963.n3.nabble.com/mime-type-detection-td4050586.html
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SLING-4694) SlingWebDavServlet should have a configurable Tika detector
[
https://issues.apache.org/jira/browse/SLING-4694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Munteanu updated SLING-4694:
---
Affects Version/s: JCR Webdav 2.2.2
SlingWebDavServlet should have a configurable Tika detector
---
Key: SLING-4694
URL: https://issues.apache.org/jira/browse/SLING-4694
Project: Sling
Issue Type: Improvement
Components: Servlets
Affects Versions: JCR Webdav 2.2.2
Reporter: Satya Deep Maheshwari
*Problem description:* I am facing a problem with the mime type detection of
a file. While debugging, I see that SlingTikaDetector.detect method is used
for detecting the mime type of my file. See [1]. This method just seems to
rely on the name of the file for detecting its mime type. Even though its
passed an inputstream of the file, it does not seem to use it for mime type
detection. So if my file name is something like xyz.tmp, it detects its mime
type as application/octet-stream (the default) while it may actually be a png
file. This is a common scenario with webdav clients wherein temporary files
get created with such names while being edited.
*Suggested Solution:*
Quoting [~rombert]
{quote}
Following the discussions at SLING-1059 [1] and SLING-255 [2] I can
infer that we more or less opted out of the 'heavy-weight' approach of
actually parsing the input stream. Not sure if we want to revisit that
TBH. At any rate, our MimeTypeService does not have an API for getting
the file content based on the input stream.
I think though there's a way around it, but only at the code level.
The org.apache.sling.jcr.webdav.impl.helper.SlingResourceConfig class
hardcodes the Detector implementation to be a SlingTikaDetector.
I think it is worthwile to raise a Jira issue for this and it would
definitely expedite the fix if you're willing to submit a patch / pull
request. I think it can be as simple as adding a @Reference to a Tika
Detector to the SlingWebDavServlet and then passing that to the
SlingServletConfig.
Cheers,
Robert
[1]: https://issues.apache.org/jira/browse/SLING-1059
[2]: https://issues.apache.org/jira/browse/SLING-255
{quote}
Related mailing-list thread on this:
http://apache-sling.73963.n3.nabble.com/mime-type-detection-td4050586.html
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SLING-4695) MockNode.getProperties() does not contain jcr:primaryType
[ https://issues.apache.org/jira/browse/SLING-4695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Sedding updated SLING-4695: -- Summary: MockNode.getProperties() does not contain jcr:primaryType (was: MockNode.getProperties() does not contains jcr:primaryType) MockNode.getProperties() does not contain jcr:primaryType - Key: SLING-4695 URL: https://issues.apache.org/jira/browse/SLING-4695 Project: Sling Issue Type: Bug Components: Testing Affects Versions: Testing JCR Mock 1.1.4 Reporter: Julian Sedding Assignee: Julian Sedding Priority: Minor The MockNode implementation does not reflect it's primary node type in its property getters, i.e. hasProperty, getProperty, getProperties. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Setting parent.relativePath in pom.xml
Hi, I noticed that we are not consistent in setting parent.relativePath on pom.xml files. Some modules set it to the empty value, e.g. parent groupIdorg.apache.sling/groupId artifactIdsling/artifactId version22/version relativePath / /parent while others set it to the relative path of the parent module in the SVN checkout parent groupIdorg.apache.sling/groupId artifactIdsling/artifactId version22/version relativePath../../parent/pom.xml/relativePath /parent We also had a query from Sandro on the users@sling [1] which leads me to believe that different Maven versions handle this property differently. While older versions, like we have on Jenkins, prefer the groupId/artifactId/version coordinates defined in the pom, more recent versions pick up a pom from the relativePath even if the version does not match. To ensure that we get reproducible builds and since we expect to always deploy the parent pom in a Maven repository I propose that we should always set the relativePath to be empty. Thoughts? Cheers, Robert [1]: http://sling-users.markmail.org/search/?q=#query:+page:2+mid:qk3ydifmrkyxbxcp+state:results
[jira] [Created] (SLING-4696) Upgrade to Oak 1.2.2
Robert Munteanu created SLING-4696: -- Summary: Upgrade to Oak 1.2.2 Key: SLING-4696 URL: https://issues.apache.org/jira/browse/SLING-4696 Project: Sling Issue Type: Improvement Components: Launchpad, Oak Reporter: Robert Munteanu Assignee: Robert Munteanu Fix For: Launchpad Builder 8, JCR Oak Server 1.0.0 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12313221version=12331970 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12313221version=12332046 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Setting parent.relativePath in pom.xml
Am 06.05.15 um 15:19 schrieb Robert Munteanu: To ensure that we get reproducible builds and since we expect to always deploy the parent pom in a Maven repository I propose that we should always set the relativePath to be empty. Thoughts? +1 Carsten Cheers, Robert [1]: http://sling-users.markmail.org/search/?q=#query:+page:2+mid:qk3ydifmrkyxbxcp+state:results -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: Setting parent.relativePath in pom.xml
+1, more information is also available at https://jira.codehaus.org/browse/MNG-4687 and indeed Maven seems to prefer local resolution in cases where the relativePath is not set explicitly empty! Konrad Am 06.05.2015 um 15:19 schrieb Robert Munteanu romb...@apache.org: Hi, I noticed that we are not consistent in setting parent.relativePath on pom.xml files. Some modules set it to the empty value, e.g. parent groupIdorg.apache.sling/groupId artifactIdsling/artifactId version22/version relativePath / /parent while others set it to the relative path of the parent module in the SVN checkout parent groupIdorg.apache.sling/groupId artifactIdsling/artifactId version22/version relativePath../../parent/pom.xml/relativePath /parent We also had a query from Sandro on the users@sling [1] which leads me to believe that different Maven versions handle this property differently. While older versions, like we have on Jenkins, prefer the groupId/artifactId/version coordinates defined in the pom, more recent versions pick up a pom from the relativePath even if the version does not match. To ensure that we get reproducible builds and since we expect to always deploy the parent pom in a Maven repository I propose that we should always set the relativePath to be empty. Thoughts? Cheers, Robert [1]: http://sling-users.markmail.org/search/?q=#query:+page:2+mid:qk3ydifmrkyxbxcp+state:results
Simplifying Jira user management
Hi, I took a look at the Jira roles that we have set up for the SLING project.The situation looks roughly like this: - Administrators: most members of the PMC ( missing 6 ), some committers ( 4 ) - Committers: a few members of the PMC, some committers ( missing 4 ) + the sling-developers group Given that we mostly use the extra Administrators group to allow administration of the project in relation to release management, I would suggest the following setup. a) Remove all user entries from the Administrators and Committers group. b) Add the sling-developers group as Administrators. The advantage is that we have a setup which allows committers to handle as much of release management work by default. This of course assumes that: 1. We feel comfortable with allowing all committers administrator permission for the project 2. The sling-developers group actually contains all sling committers For the record, these are the extra permissions that the Administrators group has: - Administer project: Ability to administer a project in JIRA. - Move Issues: Ability to move issues between projects or between workflows of the same project (if applicable). Note the user can only move issues to a project he or she has the create permission for. - Modify Reporter: Ability to modify the reporter when creating or editing an issue. - Delete Issues: Ability to delete issues. - Edit All Comments: Ability to edit all comments made on issues. - Delete All Comments: Ability to delete all comments made on issues. - Delete All Attachments: Users with this permission may delete all attachments. Thoughts? Cheers, Robert
Jenkins build became unstable: sling-trunk-1.7 #1800
See https://builds.apache.org/job/sling-trunk-1.7/1800/changes
[jira] [Commented] (SLING-4696) Upgrade to Oak 1.2.2
[ https://issues.apache.org/jira/browse/SLING-4696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14530583#comment-14530583 ] Robert Munteanu commented on SLING-4696: Fixed in https://svn.apache.org/r1677989 Upgrade to Oak 1.2.2 Key: SLING-4696 URL: https://issues.apache.org/jira/browse/SLING-4696 Project: Sling Issue Type: Improvement Components: Launchpad, Oak Reporter: Robert Munteanu Assignee: Robert Munteanu Fix For: JCR Oak Server 1.0.0, Launchpad Builder 8 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12313221version=12331970 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12313221version=12332046 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (SLING-4696) Upgrade to Oak 1.2.2
[ https://issues.apache.org/jira/browse/SLING-4696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu resolved SLING-4696. Resolution: Fixed Upgrade to Oak 1.2.2 Key: SLING-4696 URL: https://issues.apache.org/jira/browse/SLING-4696 Project: Sling Issue Type: Improvement Components: Launchpad, Oak Reporter: Robert Munteanu Assignee: Robert Munteanu Fix For: JCR Oak Server 1.0.0, Launchpad Builder 8 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12313221version=12331970 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12313221version=12332046 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4556) NPE in DiscoveryServiceImpl#activate
[
https://issues.apache.org/jira/browse/SLING-4556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14530650#comment-14530650
]
Robert Munteanu commented on SLING-4556:
What I see happening is that the OakSlingRepositoryManager is being shutdown
due to the AuthenticationConfigurationImpl being reconfigured.
{noformat}06.05.2015 17:26:03.298 *INFO* [CM Event Dispatcher (Fire
ConfigurationEvent:
pid=org.apache.jackrabbit.oak.security.authentication.AuthenticationConfigurationImpl)]
org.apache.sling.oak.server.OakSlingRepositoryManager stop: Repository still
running, forcing shutdown{noformat}
As a quick fix I tried to move the org.apache.sling.jcr.oak.server bundle to
start level 16, up from 15, but that did not help.
NPE in DiscoveryServiceImpl#activate
Key: SLING-4556
URL: https://issues.apache.org/jira/browse/SLING-4556
Project: Sling
Issue Type: Bug
Components: Extensions
Affects Versions: Discovery Impl 1.1.0
Reporter: Carsten Ziegeler
Fix For: Discovery Impl 1.1.4
31.03.2015 05:33:44.001 *ERROR* [Thread-77] org.apache.sling.discovery.impl
[org.apache.sling.discovery.impl.DiscoveryServiceImpl(85)] The activate
method has thrown an exception (java.lang.NullPointerException)
java.lang.NullPointerException: null
at
org.apache.sling.resourceresolver.impl.ResourceResolverImpl.create(ResourceResolverImpl.java:1123)
at
org.apache.sling.api.resource.ResourceUtil.getOrCreateResourceInternal(ResourceUtil.java:611)
at
org.apache.sling.api.resource.ResourceUtil.getOrCreateResource(ResourceUtil.java:554)
at
org.apache.sling.api.resource.ResourceUtil.getOrCreateResource(ResourceUtil.java:528)
at
org.apache.sling.api.resource.ResourceUtil.getOrCreateResourceInternal(ResourceUtil.java:599)
at
org.apache.sling.api.resource.ResourceUtil.getOrCreateResource(ResourceUtil.java:554)
at
org.apache.sling.api.resource.ResourceUtil.getOrCreateResource(ResourceUtil.java:528)
at
org.apache.sling.api.resource.ResourceUtil.getOrCreateResourceInternal(ResourceUtil.java:599)
at
org.apache.sling.api.resource.ResourceUtil.getOrCreateResource(ResourceUtil.java:554)
at
org.apache.sling.api.resource.ResourceUtil.getOrCreateResource(ResourceUtil.java:528)
at
org.apache.sling.api.resource.ResourceUtil.getOrCreateResourceInternal(ResourceUtil.java:599)
at
org.apache.sling.api.resource.ResourceUtil.getOrCreateResource(ResourceUtil.java:554)
at
org.apache.sling.api.resource.ResourceUtil.getOrCreateResource(ResourceUtil.java:528)
at
org.apache.sling.discovery.impl.common.resource.ResourceHelper.getOrCreateResource(ResourceHelper.java:45)
at
org.apache.sling.discovery.impl.topology.announcement.AnnouncementRegistryImpl.listAnnouncementsInSameCluster(AnnouncementRegistryImpl.java:150)
at
org.apache.sling.discovery.impl.topology.announcement.AnnouncementRegistryImpl.listInstances(AnnouncementRegistryImpl.java:542)
at
org.apache.sling.discovery.impl.DiscoveryServiceImpl.getTopology(DiscoveryServiceImpl.java:443)
at
org.apache.sling.discovery.impl.DiscoveryServiceImpl.activate(DiscoveryServiceImpl.java:149)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Jenkins build became unstable: sling-trunk-1.8 #1089
See https://builds.apache.org/job/sling-trunk-1.8/1089/changes
[jira] [Commented] (SLING-3944) org.apache.sling.scripting.java bundle exports javax.inject package in wrong version
[
https://issues.apache.org/jira/browse/SLING-3944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14530372#comment-14530372
]
Oliver Lietz commented on SLING-3944:
-
I don't think so (it's generated by Bnd). Did you encounter any problems?
Still I think embedding {{javax.inject}} into Sling's bundles is not a good
idea, but [~cziegeler] and [~justinedelson] have a different opinion.
org.apache.sling.scripting.java bundle exports javax.inject package in wrong
version
Key: SLING-3944
URL: https://issues.apache.org/jira/browse/SLING-3944
Project: Sling
Issue Type: Bug
Components: Scripting
Affects Versions: Scripting Java 2.0.10
Reporter: Markus Haack
Assignee: Oliver Lietz
Priority: Critical
Fix For: Scripting Java 2.0.12
Attachments: Screen Shot 2015-05-06 at 12.36.05.png
The org.apache.sling.scripting.java bundle exports the package javax.inject
in the version of the bundle, which is wrong and should be fixed.
This can lead to bundle version problems for other bundles which depend on
javax.inject in version [1.0,2) - the correct version (like Jersey Web
Services libraries).
Either export javax.inject with version 0.0.0 or even better with the correct
version 1.0.0.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (SLING-4695) MockNode.getProperties() does not contain jcr:primaryType
[ https://issues.apache.org/jira/browse/SLING-4695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Sedding resolved SLING-4695. --- Resolution: Fixed Fix Version/s: Testing JCR Mock 1.1.6 Fixed in [r1677969|https://svn.apache.org/r1677969] and [r1677979|https://svn.apache.org/r1677979]. MockNode.getProperties() does not contain jcr:primaryType - Key: SLING-4695 URL: https://issues.apache.org/jira/browse/SLING-4695 Project: Sling Issue Type: Bug Components: Testing Affects Versions: Testing JCR Mock 1.1.4 Reporter: Julian Sedding Assignee: Julian Sedding Priority: Minor Fix For: Testing JCR Mock 1.1.6 The MockNode implementation does not reflect it's primary node type in its property getters, i.e. hasProperty, getProperty, getProperties. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4603) oak-documentMk based discovery.impl
[
https://issues.apache.org/jira/browse/SLING-4603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14530529#comment-14530529
]
Stefan Egli commented on SLING-4603:
Note that meanwhile an alternative approach is suggested in OAK-2844 - pending
comments/reviews. That would change the way SLING-4603 would go forward: the
idea would be to use suggested discovery-light API of OAK-2844 instead of going
via JMX.
oak-documentMk based discovery.impl
---
Key: SLING-4603
URL: https://issues.apache.org/jira/browse/SLING-4603
Project: Sling
Issue Type: New Feature
Components: Extensions
Reporter: Stefan Egli
Assignee: Stefan Egli
When discovery is used in a stack based on jackrabbit oak as the repository,
the current way of discoving instances somewhat sounds like duplicating work:
oak, or more precisely documentnodestore, itself has a low-level [lease
mechanism|http://jackrabbit.apache.org/oak/docs/nodestore/documentmk.html]
where it stores information about the cluster nodes including a {{leaseEnd}}
indicating at what time others can consider a particular node as
dead/crashed. This corresponds pretty much to the discovery.impl heartbeat
mechanism. And in a stack which is built ontop of oak-documentMk, we could be
making use of this fact and delegate the decision about whether a node in a
cluster is alive or not to the oak layer. Also, with OAK-2597 the relevant
information: {{ActiveClusterNodes}} is nicely exposed via JMX - so that can
become the new source of truth defining the cluster view.
When replacing discovery-owned heartbeats with oak-owned ones, there is one
important detail to be watched out for: it can no longer easily be determined
from another instance in the cluster, whether it has this new discovery
bundle activated or not. Hence it is not given that when a voting happens,
that all {{active}} nodes (as reported by oak-documentMk) are actually going
to respond. So the 'silent instance due to deactivated discovery bundle' case
needs special attention/handling.
Other than that, given the normal case of all {{active}} nodes having the
bundle activated, the voting mechanism can stay the same as in
discovery.impl. The topology connectors can be treated the same too (by
storing announcements to their respective
{{/var/discovery/clusterInstances/slingId/announcements/announcerSlingId}}
node. The properties can be handled the same too (by storing to
{{/properties}} node. Only thing that gets replaced is the {{heartbeats}}.
Note that in order for such an oak-based discovery.impl this oak-lease
mechanism must be very robust (it should be so by its own interest already).
However, there are currently a few issues that should probably first be
resolved until discovery can be based on this: OAK-2739, OAK-2682 and
OAK-2681 are currently known in this area.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-4417) HC Annotation should allow to configure immediate SCR property
[ https://issues.apache.org/jira/browse/SLING-4417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14530940#comment-14530940 ] Georg Henzler commented on SLING-4417: -- [~cziegeler] For compatibility reasons I can't really think of a scenario that would cause problems... who would have written checks that rely on instance variables being reset after each run? This is highly unlikely. Also it is only a build-time aspect as long as people don't actively upgrade to the latest version of the annotations they will have the same behaviour. HC Annotation should allow to configure immediate SCR property Key: SLING-4417 URL: https://issues.apache.org/jira/browse/SLING-4417 Project: Sling Issue Type: New Feature Components: Health Check Reporter: Georg Henzler Attachments: SLING-4417-HC-Annotation-with-immediate-setting.patch When using @SlingHealthCheck at the moment, the immediate property is left to false in the SCR descriptor which causes the component object to be created on every call of the health check (making it impossible to keep some state in a private member variable if desired). Let's make the immediate property configurable (the same way it would be provided in the @Component annotation) and make immediate=true the default (this is a slight change in the behaviour that will not break existing code) for the following reasons: - It's more intuitive to think of a HC as singleton (and hence be able to keep some instance variables) - It's a tiny little bit better from a performance perspective (the instance does not have to be created on each execution) The attached patch includes the (fairly simple) change to annotation(-processor) and the change for two sample components that were using @Component because of this issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4645) Update Tika to 1.8
[
https://issues.apache.org/jira/browse/SLING-4645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14531345#comment-14531345
]
Oliver Lietz commented on SLING-4645:
-
{{FullTextIndexingTest}} fails with Tika newer 1.6 - it might be a problem with
the Tika OSGi bundle
Update Tika to 1.8
--
Key: SLING-4645
URL: https://issues.apache.org/jira/browse/SLING-4645
Project: Sling
Issue Type: Improvement
Components: Launchpad
Reporter: Oliver Lietz
Priority: Critical
POI Vulnerabilities: JCR-3871
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-4627) TOPOLOGY_CHANGED in an eventually consistent repository
[ https://issues.apache.org/jira/browse/SLING-4627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14530846#comment-14530846 ] Timothee Maret commented on SLING-4627: --- IIUC, this would mean that whenever the topology changes at a point in time X, each remaining instances in the topology would write a syncToken in the repository. Each instances would deem the data as being replicated up the point X, when they see most (or maybe all remaining) syncTokens. If this understanding is correct, I'd have a few questions: 1. How can this mechanism guarantee that the data written by the instance that crashed at point X is replicated, assuming it can't write its own syncToken ? Assuming this instance is the leader, this may be problematic. 2. How would the syncToken be reused in consecutive consistency checks ? Couldn't it be possible that some instances see an old consistency token and consider it as valid ? I don't know the details of Oak very well, but maybe there is queue of data to be replicated somewhere. Getting a hand on this queue may offer such guarantee that data has been replicated up to the point in time X. Assuming such queue exists each instance could write a piece of data at the time X and wait until it sees it out of the queue (or written in the Journal). This would allow to keep each instance to care only about themselves. TOPOLOGY_CHANGED in an eventually consistent repository --- Key: SLING-4627 URL: https://issues.apache.org/jira/browse/SLING-4627 Project: Sling Issue Type: Improvement Components: Extensions Reporter: Stefan Egli Assignee: Stefan Egli Priority: Critical Attachments: SLING-4627.patch, SLING-4627.patch This is a parent ticket describing the +coordination effort needed between properly sending TOPOLOGY_CHANGED when running ontop of an eventually consistent repository+. These findings are independent of the implementation details used inside the discovery implementation, so apply to discovery.impl, discovery.etcd/.zookeeper/.oak etc. Tickets to implement this for specific implementation are best created separately (eg sub-task or related..). Also note that this assumes immediately sending TOPOLOGY_CHANGING as described [in SLING-3432|https://issues.apache.org/jira/browse/SLING-3432?focusedCommentId=14492494page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14492494] h5. The spectrum of possible TOPOLOGY_CHANGED events include the following scenarios: || scenario || classification || action || | A. change is completely outside of local cluster | (/) uncritical | changes outside the cluster are considered uncritical for this exercise. | | B. a new instance joins the local cluster, this new instance is by contract not the leader (leader must be stable \[0\]) | (/) uncritical | a join of an instance is uncritical due to the fact that it merely joins the cluster and has thus no 'backlog' of changes that might be propagating through the (eventually consistent) repository. | | C. a non-leader *leaves* the local cluster | (x) *critical* | changes that were written by the leaving instance might still not be *seen* by all surviving (ie it can be that discovery is faster than the repository) and this must be assured before sending out TOPOLOGY_CHANGED. This is because the leaving instance could have written changes that are *topology dependent* and thus those changes must first be settled in the repository before continuing with a *new topology*. | | D. the leader *leaves* the local cluster (and thus a new leader is elected) | (x)(x) *very critical* | same as C except that this is more critical due to the fact that the leader left | | E. -the leader of the local cluster changes (without leaving)- this is not supported by contract (leader must be stable \[0\]) | (/) -irrelevant- | | So both C and D are about an instance leaving. And as mentioned above the survivors must assure they have read all changes of the leavers. There are two parts to this: * the leaver could have pending writes that are not yet in mongoD: I don't think this is the case. The only thing that can remain could be an uncommitted branch and that would be rolled back afaik. ** Exception to this is a partition: where the leaver didn't actually crash but is still hooked to the repository. *For this I'm not sure how it can be solved* yet. * the survivers could however not yet have read all changes (pending in the background read) and one way to make sure they did is to have each surviving instance write a (pseudo-) sync token to the repository. Once all survivors have seen this sync token of all other survivors, the assumption is that all pending changes are
[jira] [Updated] (SLING-4645) Update Tika to 1.8
[ https://issues.apache.org/jira/browse/SLING-4645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Lietz updated SLING-4645: Summary: Update Tika to 1.8 (was: Update Tika to 1.7) Update Tika to 1.8 -- Key: SLING-4645 URL: https://issues.apache.org/jira/browse/SLING-4645 Project: Sling Issue Type: Improvement Components: Launchpad Reporter: Oliver Lietz Priority: Critical POI Vulnerabilities: JCR-3871 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Jenkins build is still unstable: sling-trunk-1.8 #1091
See https://builds.apache.org/job/sling-trunk-1.8/changes
Re: Setting parent.relativePath in pom.xml
On Wednesday 06 May 2015 16:19:31 Robert Munteanu wrote: Hi, I noticed that we are not consistent in setting parent.relativePath on pom.xml files. Some modules set it to the empty value, e.g. parent groupIdorg.apache.sling/groupId artifactIdsling/artifactId version22/version relativePath / /parent while others set it to the relative path of the parent module in the SVN checkout parent groupIdorg.apache.sling/groupId artifactIdsling/artifactId version22/version relativePath../../parent/pom.xml/relativePath /parent We also had a query from Sandro on the users@sling [1] which leads me to believe that different Maven versions handle this property differently. While older versions, like we have on Jenkins, prefer the groupId/artifactId/version coordinates defined in the pom, more recent versions pick up a pom from the relativePath even if the version does not match. To ensure that we get reproducible builds and since we expect to always deploy the parent pom in a Maven repository I propose that we should always set the relativePath to be empty. Thoughts? +1 though you have to build parent yourself when SNAPSHOT is used by that module Can we add such best practices to our documentation, please? Regards, O. Cheers, Robert [1]: http://sling-users.markmail.org/search/?q=#query:+page:2+mid:qk3ydifmrkyxbx cp+state:results
Build failed in Jenkins: sling-contrib-1.7 #64
See https://builds.apache.org/job/sling-contrib-1.7/64/ -- [...truncated 63242 lines...] [org.ops4j.pax.exam.spi.intern.DefaultTestAddress] : NEW ADDRESS= PaxExam-c9e15ebf-47e5-4daa-85dd-82d5d9a2ebcd parent=[TestAddress:PaxExam-0bd6b574-1aa6-402f-a555-d3846658259d root:PaxExam-0bd6b574-1aa6-402f-a555-d3846658259d] root=[TestAddress:PaxExam-0bd6b574-1aa6-402f-a555-d3846658259d root:PaxExam-0bd6b574-1aa6-402f-a555-d3846658259d] args=[Ljava.lang.Object;@1222574 [org.ops4j.pax.exam.spi.intern.DefaultTestAddress] : NEW ADDRESS= PaxExam-fc69bd57-5168-4108-8c8c-5a865615395e parent=[TestAddress:PaxExam-79a45eaa-b34a-4727-8062-406f7006b5c1 root:PaxExam-79a45eaa-b34a-4727-8062-406f7006b5c1] root=[TestAddress:PaxExam-79a45eaa-b34a-4727-8062-406f7006b5c1 root:PaxExam-79a45eaa-b34a-4727-8062-406f7006b5c1] args=[Ljava.lang.Object;@c90728 [org.ops4j.pax.exam.spi.intern.DefaultTestAddress] : NEW ADDRESS= PaxExam-11421ee3-c0f3-4201-aa82-101482e15afd parent=[TestAddress:PaxExam-093729ee-1304-4e34-9e74-5592b7b0de49 root:PaxExam-093729ee-1304-4e34-9e74-5592b7b0de49] root=[TestAddress:PaxExam-093729ee-1304-4e34-9e74-5592b7b0de49 root:PaxExam-093729ee-1304-4e34-9e74-5592b7b0de49] args=[Ljava.lang.Object;@1f4dcba [org.ops4j.pax.exam.spi.intern.DefaultTestAddress] : NEW ADDRESS= PaxExam-94009db6-e37e-4c04-9cbc-fdf8cc1a6602 parent=[TestAddress:PaxExam-38fedec0-e684-416d-a266-0d3144a5a917 root:PaxExam-38fedec0-e684-416d-a266-0d3144a5a917] root=[TestAddress:PaxExam-38fedec0-e684-416d-a266-0d3144a5a917 root:PaxExam-38fedec0-e684-416d-a266-0d3144a5a917] args=[Ljava.lang.Object;@c75e4b [org.ops4j.pax.exam.spi.intern.DefaultTestAddress] : NEW ADDRESS= PaxExam-02df228e-59e0-4f6c-a448-1355b9635dc1 parent=[TestAddress:PaxExam-75dc4972-eb14-4a2c-b9d3-7b261e7b52ec root:PaxExam-75dc4972-eb14-4a2c-b9d3-7b261e7b52ec] root=[TestAddress:PaxExam-75dc4972-eb14-4a2c-b9d3-7b261e7b52ec root:PaxExam-75dc4972-eb14-4a2c-b9d3-7b261e7b52ec] args=[Ljava.lang.Object;@ffab0c [org.ops4j.pax.exam.spi.intern.DefaultTestAddress] : NEW ADDRESS= PaxExam-39a9abcd-5422-43ac-8d8d-dadcb82db390 parent=[TestAddress:PaxExam-2d237557-2f82-4cec-9cb0-442295af3a92 root:PaxExam-2d237557-2f82-4cec-9cb0-442295af3a92] root=[TestAddress:PaxExam-2d237557-2f82-4cec-9cb0-442295af3a92 root:PaxExam-2d237557-2f82-4cec-9cb0-442295af3a92] args=[Ljava.lang.Object;@136b5db [org.ops4j.pax.exam.spi.intern.DefaultTestAddress] : NEW ADDRESS= PaxExam-326b2655-8733-4dc8-bfd1-4482825f01dd parent=[TestAddress:PaxExam-60633783-6938-4247-a6d6-d745b5db8022 root:PaxExam-60633783-6938-4247-a6d6-d745b5db8022] root=[TestAddress:PaxExam-60633783-6938-4247-a6d6-d745b5db8022 root:PaxExam-60633783-6938-4247-a6d6-d745b5db8022] args=[Ljava.lang.Object;@dd5200 [org.ops4j.pax.exam.spi.intern.DefaultTestAddress] : NEW ADDRESS= PaxExam-986bd953-a093-4661-9258-6a4ca7cf3f76 parent=[TestAddress:PaxExam-8f23fd44-814f-41c9-8722-e10d2a18c5e8 root:PaxExam-8f23fd44-814f-41c9-8722-e10d2a18c5e8] root=[TestAddress:PaxExam-8f23fd44-814f-41c9-8722-e10d2a18c5e8 root:PaxExam-8f23fd44-814f-41c9-8722-e10d2a18c5e8] args=[Ljava.lang.Object;@32a258 [org.ops4j.pax.exam.spi.intern.DefaultTestAddress] : NEW ADDRESS= PaxExam-e8e01c81-6b72-40dd-9ac2-5eae971733bd parent=[TestAddress:PaxExam-313d0eca-e398-4660-a92b-3fb217c54cc5 root:PaxExam-313d0eca-e398-4660-a92b-3fb217c54cc5] root=[TestAddress:PaxExam-313d0eca-e398-4660-a92b-3fb217c54cc5 root:PaxExam-313d0eca-e398-4660-a92b-3fb217c54cc5] args=[Ljava.lang.Object;@4076e6 [org.ops4j.pax.exam.spi.intern.DefaultTestAddress] : NEW ADDRESS= PaxExam-f6593a8a-53d3-411d-b0e9-16fe3c567482 parent=[TestAddress:PaxExam-00854ea6-a277-431b-b434-56cf23fb7743 root:PaxExam-00854ea6-a277-431b-b434-56cf23fb7743] root=[TestAddress:PaxExam-00854ea6-a277-431b-b434-56cf23fb7743 root:PaxExam-00854ea6-a277-431b-b434-56cf23fb7743] args=[Ljava.lang.Object;@3e2f9d [org.ops4j.pax.exam.spi.intern.DefaultTestAddress] : NEW ADDRESS= PaxExam-041f1fb1-5e37-4778-bdec-26ed8777f564 parent=[TestAddress:PaxExam-49cedcdc-4d57-49fb-aa3d-e516e4b85f6c root:PaxExam-49cedcdc-4d57-49fb-aa3d-e516e4b85f6c] root=[TestAddress:PaxExam-49cedcdc-4d57-49fb-aa3d-e516e4b85f6c root:PaxExam-49cedcdc-4d57-49fb-aa3d-e516e4b85f6c] args=[Ljava.lang.Object;@a7f8da [org.ops4j.pax.exam.spi.intern.DefaultTestAddress] : NEW ADDRESS= PaxExam-2ef89abe-485b-49a6-b40a-7b3ee797f56b parent=[TestAddress:PaxExam-9e966244-1732-4e5e-b5b2-5024045fa743 root:PaxExam-9e966244-1732-4e5e-b5b2-5024045fa743] root=[TestAddress:PaxExam-9e966244-1732-4e5e-b5b2-5024045fa743 root:PaxExam-9e966244-1732-4e5e-b5b2-5024045fa743] args=[Ljava.lang.Object;@1c2bde2 [org.ops4j.pax.exam.spi.intern.DefaultTestAddress] : NEW ADDRESS= PaxExam-5e4a2762-f67d-4a50-8ce6-7754ebcbdfa2 parent=[TestAddress:PaxExam-c14c83ef-7b0d-41a8-8726-01586088162b root:PaxExam-c14c83ef-7b0d-41a8-8726-01586088162b] root=[TestAddress:PaxExam-c14c83ef-7b0d-41a8-8726-01586088162b
Jenkins build is unstable: sling-contrib-1.7 #65
See https://builds.apache.org/job/sling-contrib-1.7/65/
Jenkins build is still unstable: sling-trunk-1.8 #1092
See https://builds.apache.org/job/sling-trunk-1.8/changes
Jenkins build is back to stable : sling-trunk-1.7 #1801
See https://builds.apache.org/job/sling-trunk-1.7/1801/changes
Jenkins build is still unstable: sling-trunk-1.8 #1090
See https://builds.apache.org/job/sling-trunk-1.8/changes
[jira] [Created] (SLING-4697) add support for PROPERTIES_CHANGED to ViewStateManager
Stefan Egli created SLING-4697:
--
Summary: add support for PROPERTIES_CHANGED to ViewStateManager
Key: SLING-4697
URL: https://issues.apache.org/jira/browse/SLING-4697
Project: Sling
Issue Type: Improvement
Components: Extensions
Reporter: Stefan Egli
Assignee: Stefan Egli
Fix For: Discovery Commons 1.0.0
The {{discovery.commons.providers.ViewStateManager}} currently only supports
TOPOLOGY_INIT, TOPOLOGY_CHANGING and TOPOLOGY_CHANGED - it should also support
PROPERTIES_CHANGED.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
