[jira] [Updated] (SLING-4347) When a timezone is provided in a Date, it should be stored as provided
[ https://issues.apache.org/jira/browse/SLING-4347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] santiago garcía pimentel updated SLING-4347: Description: Whenever a POST request is made and it contains a date string with a timezone in it. Sling turns it into the JVM local time and looses the provided timezone. The only exception for this is when the date is provided in the ISO8601 format, which uses a different date formatter. Sling should instead preserve the date as it is provided. This happens because Sling uses a SimpleDateFormat object to parse the Date string, which returns a date object. We could follow an approach like org.apache.jackrabbit.util.ISO8601 to achieve this. http://svn.apache.org/repos/asf/jackrabbit/trunk/jackrabbit-jcr-commons/src/main/java/org/apache/jackrabbit/util/ISO8601.java was: Whenever a POST request is made and it contains a date string with a timezone in it. Sling turns it into the JVM local time and looses the provided timezone. The only exception for this is when the date is provided in the ISO8601 format, which uses a different date formatter. Sling should instead preserve the date as it is provided. This happens because Sling uses a SimpleDateFormat object to parse the Date string, which returns a date object. We could follow an approach like org.apache.jackrabbit.util.ISO8601 to achieve this. When a timezone is provided in a Date, it should be stored as provided -- Key: SLING-4347 URL: https://issues.apache.org/jira/browse/SLING-4347 Project: Sling Issue Type: Bug Components: Servlets Reporter: santiago garcía pimentel Whenever a POST request is made and it contains a date string with a timezone in it. Sling turns it into the JVM local time and looses the provided timezone. The only exception for this is when the date is provided in the ISO8601 format, which uses a different date formatter. Sling should instead preserve the date as it is provided. This happens because Sling uses a SimpleDateFormat object to parse the Date string, which returns a date object. We could follow an approach like org.apache.jackrabbit.util.ISO8601 to achieve this. http://svn.apache.org/repos/asf/jackrabbit/trunk/jackrabbit-jcr-commons/src/main/java/org/apache/jackrabbit/util/ISO8601.java -- This message was sent by Atlassian JIRA (v6.3.4#6332)
RE: [PROPOSAL] Context-specific configuration for Apache Sling, Multitenancy
hello oliver. what's the status here? Will you move this project to Sling? this is not decided yet, no precise plans yet. this depends if it is useful for a broader audience in the sling community and projects/applications built with sling. until then just try it out from wcm.io. additionally i wanted to experiment with carstens idea to define configuration parameters using annotation classes as defined in the new OSGi specifications, but i had found no time for this yet. we already use this in production, but surely there is still room for improvement. Is it possible to read/write configurations of the current resource only or are configurations always collected up the tree? this depends on the configuration finder strategey used. our intention is that the configuration is normally not in the current resource, but always somewhere up in the tree. or in a shadow tree like /conf. see [1] and [2] for details. stefan [1] http://wcm.io/config/api/terminology.html [2] http://wcm.io/config/api/usage-spi.html
[jira] [Closed] (SLING-3865) Remove JcrResource.adaptTo(URL
[ https://issues.apache.org/jira/browse/SLING-3865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-3865. --- Remove JcrResource.adaptTo(URL -- Key: SLING-3865 URL: https://issues.apache.org/jira/browse/SLING-3865 Project: Sling Issue Type: Improvement Components: JCR Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: JCR Resource 2.4.2 Once SLING-3864 is done and released we can remove it -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (SLING-4184) Provide path mapping from JCR nodes to resource paths
[ https://issues.apache.org/jira/browse/SLING-4184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-4184. --- Provide path mapping from JCR nodes to resource paths - Key: SLING-4184 URL: https://issues.apache.org/jira/browse/SLING-4184 Project: Sling Issue Type: New Feature Components: JCR Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: JCR Resource 2.4.2 Right now a JCR repository is mounted as is without any way to make this more fine grained, for example if you want to mount a whole repository but a specific sub tree, or you want the whole repository as is, but map just one sub tree to a different path/name, this is currently not possible. The mapping on the resource level is too high level for these things. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (SLING-3867) Remove node/property adaptions
[ https://issues.apache.org/jira/browse/SLING-3867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-3867. --- Remove node/property adaptions -- Key: SLING-3867 URL: https://issues.apache.org/jira/browse/SLING-3867 Project: Sling Issue Type: Improvement Components: JCR Environment: Once SLING-3866 is done and released, we can remove that feature Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: JCR Resource 2.4.2 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (SLING-4116) Content length check in JCRNodeResourceMetadata triggers javax.jcr.ItemNotFoundException: No primary item present on node
[
https://issues.apache.org/jira/browse/SLING-4116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler closed SLING-4116.
---
Content length check in JCRNodeResourceMetadata triggers
javax.jcr.ItemNotFoundException: No primary item present on node
-
Key: SLING-4116
URL: https://issues.apache.org/jira/browse/SLING-4116
Project: Sling
Issue Type: Bug
Components: JCR
Affects Versions: JCR Resource 2.3.12
Reporter: Robert Munteanu
Assignee: Carsten Ziegeler
Fix For: JCR Resource 2.4.2
As reported by [~dsuess] on [dev@sling - ResourceWrapper issue with
ResourceMetadata|http://sling-dev.markmail.org/thread/aauecevkxjnbk4vi] , the
code trying to guess the content-length can cause ItemNotFoundExceptions to
be logged by calling {{Item.getPrimaryItem()}}.
By looking at the Jackrabbit and Oak implementations, the getPrimaryItem()
method does the following
{code:java}
String name = getPrimaryNodeType().getPrimaryItemName();
if (name == null) {
throw new ItemNotFoundException();
}
if (hasProperty(name)) {
return getProperty(name);
} else if (hasNode(name)) {
return getNode(name);
} else {
throw new ItemNotFoundException();
}
{code}
We should replicate this check to make sure that we no longer cause these
exceptions to be thrown and logged.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (SLING-4307) Avoid caching JCR property values
[ https://issues.apache.org/jira/browse/SLING-4307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-4307. --- Avoid caching JCR property values - Key: SLING-4307 URL: https://issues.apache.org/jira/browse/SLING-4307 Project: Sling Issue Type: Improvement Components: JCR Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: JCR Resource 2.4.2 Attachments: SLING-4307_stream_test.patch The support for ValueMap is currently caching the JCR Value objects and also the JCR Property object. If the value map object is held, this might prevent garbage collection within Oak as the value object holds a reference to the revision. We should check whether caching is needed at all or if for example we could just cache the value itself but not the JCR Value object -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SLING-4347) When a timezone is provided in a Date, it should be stored as provided
santiago garcía pimentel created SLING-4347: --- Summary: When a timezone is provided in a Date, it should be stored as provided Key: SLING-4347 URL: https://issues.apache.org/jira/browse/SLING-4347 Project: Sling Issue Type: Bug Components: Servlets Reporter: santiago garcía pimentel Whenever a POST request is made and it contains a date string with a timezone in it. Sling turns it into the JVM local time and looses the provided timezone. The only exception for this is when the date is provided in the ISO8601 format, which uses a different date formatter. Sling should instead preserve the date as it is provided. This happens because Sling uses a SimpleDateFormat object to parse the Date string, which returns a date object. We could follow an approach like org.apache.jackrabbit.util.ISO8601 to achieve this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4258) JSON representation of Calendar values should preserve timezone
[ https://issues.apache.org/jira/browse/SLING-4258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14289514#comment-14289514 ] santiago garcía pimentel commented on SLING-4258: - I'm creating SLING-4347 so we can talk about keeping the timezone in the rest of date formats which have an offset. JSON representation of Calendar values should preserve timezone --- Key: SLING-4258 URL: https://issues.apache.org/jira/browse/SLING-4258 Project: Sling Issue Type: Improvement Components: Commons Affects Versions: Commons JSON 2.0.10 Reporter: santiago garcía pimentel Assignee: Bertrand Delacretaz Priority: Minor Fix For: Commons JSON 2.0.12 Attachments: SLING-4258.patch Im currently doing some things with dates in Sling that involve timezones and I find that the documentation regarding it is not particularly clear. according to https://sling.apache.org/documentation/bundles/manipulating-content-the-slingpostservlet-servlets-post.html#date-properties several formats are defined. I found that the only format that saves a provided timezone is the ISO8601 format, rest of them relies in a Date object, which does not have timezones. Could this be clearly stated? Also, the ISO8601 parser is problematic. It relies on the Jackrabbit parser which uses format ±-MM-DDThh:mm:ss.SSSTZD, but according to http://www.w3.org/TR/NOTE-datetime the ISO format does not have milliseconds on it (SSS). So it is very hard to find a way to keep the timezone information (I had to dig through the code to figure it out) Could we please replace ISO8601 with the actual format ±-MM-DDThh:mm:ss.SSSTZD so it is clearer? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[VOTE RESULT] Release Apache Sling JCR Resource 2.4.2
The vote passed with three binding +1 votes Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
[jira] [Commented] (SLING-4347) When a timezone is provided in a Date, it should be stored as provided
[ https://issues.apache.org/jira/browse/SLING-4347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14289515#comment-14289515 ] santiago garcía pimentel commented on SLING-4347: - [~bdelacretaz] what do you think about this? When a timezone is provided in a Date, it should be stored as provided -- Key: SLING-4347 URL: https://issues.apache.org/jira/browse/SLING-4347 Project: Sling Issue Type: Bug Components: Servlets Reporter: santiago garcía pimentel Whenever a POST request is made and it contains a date string with a timezone in it. Sling turns it into the JVM local time and looses the provided timezone. The only exception for this is when the date is provided in the ISO8601 format, which uses a different date formatter. Sling should instead preserve the date as it is provided. This happens because Sling uses a SimpleDateFormat object to parse the Date string, which returns a date object. We could follow an approach like org.apache.jackrabbit.util.ISO8601 to achieve this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Jenkins build is back to normal : sling-trunk-1.6 #2972
See https://builds.apache.org/job/sling-trunk-1.6/2972/changes
Jenkins build is back to normal : sling-trunk-1.7 #1360
See https://builds.apache.org/job/sling-trunk-1.7/1360/changes
[jira] [Resolved] (SLING-4258) JSON representation of Calendar values should preserve timezone
[ https://issues.apache.org/jira/browse/SLING-4258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bertrand Delacretaz resolved SLING-4258. Resolution: Fixed I have now committed your contribution in http://svn.apache.org/r1654307 - thanks very much for your patience! JSON representation of Calendar values should preserve timezone --- Key: SLING-4258 URL: https://issues.apache.org/jira/browse/SLING-4258 Project: Sling Issue Type: Improvement Components: Commons Affects Versions: Commons JSON 2.0.10 Reporter: santiago garcía pimentel Assignee: Bertrand Delacretaz Priority: Minor Fix For: Commons JSON 2.0.12 Attachments: SLING-4258.patch Im currently doing some things with dates in Sling that involve timezones and I find that the documentation regarding it is not particularly clear. according to https://sling.apache.org/documentation/bundles/manipulating-content-the-slingpostservlet-servlets-post.html#date-properties several formats are defined. I found that the only format that saves a provided timezone is the ISO8601 format, rest of them relies in a Date object, which does not have timezones. Could this be clearly stated? Also, the ISO8601 parser is problematic. It relies on the Jackrabbit parser which uses format ±-MM-DDThh:mm:ss.SSSTZD, but according to http://www.w3.org/TR/NOTE-datetime the ISO format does not have milliseconds on it (SSS). So it is very hard to find a way to keep the timezone information (I had to dig through the code to figure it out) Could we please replace ISO8601 with the actual format ±-MM-DDThh:mm:ss.SSSTZD so it is clearer? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-4212) Sling Models: Allow multiple values from ValueMap in the resource-path injector
[ https://issues.apache.org/jira/browse/SLING-4212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert updated SLING-4212: -- Attachment: resourcePath-API_noRequiredCheck.patch attached is another updated version of the patch, without the required check. injection suceeds only if all path could be resolved. [^resourcePath-API_noRequiredCheck.patch] if this is helpful we can apply it. Sling Models: Allow multiple values from ValueMap in the resource-path injector --- Key: SLING-4212 URL: https://issues.apache.org/jira/browse/SLING-4212 Project: Sling Issue Type: Improvement Components: Extensions Reporter: santiago garcía pimentel Assignee: Stefan Seifert Fix For: Sling Models API 1.2.0, Sling Models Impl 1.2.0 Attachments: resourcePath-API.patch, resourcePath-API_noRequiredCheck.patch, resourcePath-API_updated.patch The current implementation of the resource-path injector does not support multiple values. I think it could be useful to inject a list of paths from the valuemap. I have created a small patch to allow this. Right now it only allows them from the value map since I didn't want to change the API without consulting you first. I you agree I can do this change as well. I also added a test case for it. You can see a pull request in https://github.com/apache/sling/pull/51 If there anything I can do to improve this patch, please let me know. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Jenkins build is unstable: sling-trunk-1.8 #652
See https://builds.apache.org/job/sling-trunk-1.8/652/changes
Jenkins build became unstable: sling-trunk-1.6 #2973
See https://builds.apache.org/job/sling-trunk-1.6/2973/changes
[jira] [Resolved] (SLING-4212) Sling Models: Allow multiple values from ValueMap in the resource-path injector
[ https://issues.apache.org/jira/browse/SLING-4212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert resolved SLING-4212. --- Resolution: Fixed Completed: At revision: 1654430 patch applied Sling Models: Allow multiple values from ValueMap in the resource-path injector --- Key: SLING-4212 URL: https://issues.apache.org/jira/browse/SLING-4212 Project: Sling Issue Type: Improvement Components: Extensions Reporter: santiago garcía pimentel Assignee: Stefan Seifert Fix For: Sling Models API 1.2.0, Sling Models Impl 1.2.0 Attachments: resourcePath-API.patch, resourcePath-API_noRequiredCheck.patch, resourcePath-API_updated.patch The current implementation of the resource-path injector does not support multiple values. I think it could be useful to inject a list of paths from the valuemap. I have created a small patch to allow this. Right now it only allows them from the value map since I didn't want to change the API without consulting you first. I you agree I can do this change as well. I also added a test case for it. You can see a pull request in https://github.com/apache/sling/pull/51 If there anything I can do to improve this patch, please let me know. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[VOTE] Release Apache Sling JCR Resource 2.4.4
Hi, we solved one critical issue https://issues.apache.org/jira/browse/SLING-4343 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-1177/ You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 1177 /tmp/sling-staging Please vote to approve this release: [ ] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... This majority vote is open for at least 72 hours. Regards Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Jenkins build is back to stable : sling-trunk-1.8 #653
See https://builds.apache.org/job/sling-trunk-1.8/653/changes
[jira] [Commented] (SLING-4212) Sling Models: Allow multiple values from ValueMap in the resource-path injector
[ https://issues.apache.org/jira/browse/SLING-4212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14289967#comment-14289967 ] santiago garcía pimentel commented on SLING-4212: - [~sseif...@pro-vision.de] thank you, that will be great! Sling Models: Allow multiple values from ValueMap in the resource-path injector --- Key: SLING-4212 URL: https://issues.apache.org/jira/browse/SLING-4212 Project: Sling Issue Type: Improvement Components: Extensions Reporter: santiago garcía pimentel Assignee: Stefan Seifert Fix For: Sling Models API 1.2.0, Sling Models Impl 1.2.0 Attachments: resourcePath-API.patch, resourcePath-API_noRequiredCheck.patch, resourcePath-API_updated.patch The current implementation of the resource-path injector does not support multiple values. I think it could be useful to inject a list of paths from the valuemap. I have created a small patch to allow this. Right now it only allows them from the value map since I didn't want to change the API without consulting you first. I you agree I can do this change as well. I also added a test case for it. You can see a pull request in https://github.com/apache/sling/pull/51 If there anything I can do to improve this patch, please let me know. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [VOTE] Release Apache Sling JCR Resource 2.4.4
+1 Carsten Am 23.01.15 um 13:20 schrieb Carsten Ziegeler: Hi, we solved one critical issue https://issues.apache.org/jira/browse/SLING-4343 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-1177/ You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 1177 /tmp/sling-staging Please vote to approve this release: [ ] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... This majority vote is open for at least 72 hours. Regards Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: [discussion] allow Script Engines to also render components based on paths
On Fri, Jan 23, 2015 at 1:59 PM, Oliver Lietz apa...@oliverlietz.de wrote: Whatever the approach is, if we want to allow multiple scripting engines to use the same extension we need to refactor the code from the SlingScriptEngineManager. Why? The ScriptEngine itself can decide if it kicks in for a script based on the paths patterns. Because currently the script engines are just template processors. The SlingServletResolver is the component that maps a request to the script engine that will provide the output, with the help of the SlingScriptAdapterFactory and the SlingScriptEngineManager.
[jira] [Updated] (SLING-4346) Sightly: HtmlParser does not parse documents correctly when comments span across internal char buffer size
[
https://issues.apache.org/jira/browse/SLING-4346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vlad Bailescu updated SLING-4346:
-
Attachment:
SLING-4346_Sightly__HtmlParser_does_not_parse_documents_correctly_when_comments_span_acros.patch
- Added helper method to handle comments
- Fixed data handling for comments inside the parser state machine
- Made internal char buffer size configurable
- Added unit tests
Sightly: HtmlParser does not parse documents correctly when comments span
across internal char buffer size
--
Key: SLING-4346
URL: https://issues.apache.org/jira/browse/SLING-4346
Project: Sling
Issue Type: Bug
Components: Scripting
Reporter: Vlad Bailescu
Fix For: Scripting Sightly Engine 1.0.2
Attachments:
SLING-4346_Sightly__HtmlParser_does_not_parse_documents_correctly_when_comments_span_acros.patch
The HTML parser used by Sightly to process templates is parsing incorrectly
comments that span across it's internal char buffer size. Right now the
buffer is set to 2048 characters, making the problem hard to see.
The problem can be exposed by lowering the buffer size to 10 and feeding a
string such as {code:java}test test !--/*comment*/--{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (SLING-4318) Sling resource API does not expose any versioning features - bounty offered.
[
https://issues.apache.org/jira/browse/SLING-4318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14289243#comment-14289243
]
Tomek Rękawek edited comment on SLING-4318 at 1/23/15 1:39 PM:
---
The {{;v=1.0}} parameter support has been implemented in SLING-848. I also
prepared two other features related to versioning, mentioned in the comment
above:
*Version list servlet*
Using *V* selector allows to get the version history for a given resource. Data
are presented in following format:
{code}
curl http://localhost:4502/content/test.V.tidy.json
{
jcr:rootVersion: {
created: Fri Jan 23 2015 11:02:09 GMT+0100,
successors: [1.0],
predecessors: [],
labels: [firstVersion],
baseVersion: false
},
1.0: {
created: Fri Jan 23 2015 11:02:11 GMT+0100,
successors: [1.1],
predecessors: [jcr:rootVersion],
labels: [secondVersion, afterChanges],
baseVersion: true
}
}
{code}
Pull request: https://github.com/apache/sling/pull/58/files
*Restore operation*
The new {{:operation=restore}} parameter allows to restore a resource to a
given version referenced by name or label:
{code}
curl -X POST -F :operation=restore -F :version=1.0
http://localhost:4502/content/test
{code}
Pull request: https://github.com/apache/sling/pull/59/files
I'm looking forward to feedback.
was (Author: tomek.rekawek):
The {{;v=1.0}} parameter support has been implemented in SLING-848. I also
prepared two other features related to versioning, mentioned in the comment
above:
*Version list servlet*
Using *V* selector allows to get the version history for a given resource. Data
are presented in following format:
{code}
curl http://localhost:4502/content/test.V.tidy.json
{
jcr:rootVersion: {
created: Fri Jan 23 2015 11:02:09 GMT+0100,
successors: [1.0],
predecessors: [],
labels: [firstVersion],
baseVersion: false
},
1.0: {
created: Fri Jan 23 2015 11:02:11 GMT+0100,
successors: [1.1],
predecessors: [jcr:rootVersion],
labels: [secondVersion, afterChanges],
baseVersion: true
}
}
{code}
Pull request: https://github.com/apache/sling/pull/58/files
*Restore operation*
The new {{:operation=restore parameter}} allows to restore a resource to a
given version referenced by name or label:
{code}
curl -X POST -F :operation=restore -F :version=1.0
http://localhost:4502/content/test
{code}
Pull request: https://github.com/apache/sling/pull/59/files
I'm looking forward to feedback.
Sling resource API does not expose any versioning features - bounty offered.
Key: SLING-4318
URL: https://issues.apache.org/jira/browse/SLING-4318
Project: Sling
Issue Type: New Feature
Components: Documentation, JCR, Servlets
Affects Versions: Servlets Resolver 2.3.8
Environment: N/A
Reporter: Bruce Edge
Labels: api, crud, servlet-api, versioning, versions
The javax.jcr.version.VersionManager is not exposed in the sling resource API:
http://thread.gmane.org/gmane.comp.apache.sling.user/1610
My company is interested in paying for this development. Please contact if
interested.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (SLING-4342) [Sightly] Reduce the number of repository reads
[ https://issues.apache.org/jira/browse/SLING-4342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger resolved SLING-4342. -- Resolution: Fixed Assignee: Felix Meschberger Thanks for providing the patch. I have applied it in Rev. 1654212 [Sightly] Reduce the number of repository reads --- Key: SLING-4342 URL: https://issues.apache.org/jira/browse/SLING-4342 Project: Sling Issue Type: Improvement Components: Scripting Reporter: Radu Cotescu Assignee: Felix Meschberger Fix For: Scripting Sightly Engine 1.0.0 Attachments: SLING-4342.patch On instances that still use Jackrabbit, repository read operations can become problematic if the system is exposed to a high number of requests. Therefore the Sightly Scripting engine should be optimised to reduce the number of repository reads as much as possible. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [discussion] allow Script Engines to also render components based on paths
Hi Am 23.01.2015 um 13:29 schrieb Radu Cotescu r...@apache.org: On Fri, Jan 23, 2015 at 1:59 PM, Oliver Lietz apa...@oliverlietz.de wrote: Whatever the approach is, if we want to allow multiple scripting engines to use the same extension we need to refactor the code from the SlingScriptEngineManager. Why? The ScriptEngine itself can decide if it kicks in for a script based on the paths patterns. Because currently the script engines are just template processors. The SlingServletResolver is the component that maps a request to the script engine that will provide the output, with the help of the SlingScriptAdapterFactory and the SlingScriptEngineManager. Exactly: The SlingScriptAdapterFactory checks the extension of the script and selects the ScriptEngine for this extension. Only one ScriptEngineFactory of a particular extension can be registered at any one time. So this one is select and called to evaluate the script. If the ScriptEngine decides to not actually evaluate it, nothing more happens. We have to make sure we improve on the ScriptEngine selection mechanism. I don’t want to cycle through multiple ScriptEngine’s until one decides to handle…. Regards Felix
Re: [discussion] allow Script Engines to also render components based on paths
Hi Am 23.01.2015 um 11:55 schrieb Oliver Lietz apa...@oliverlietz.de: On Friday 23 January 2015 10:30:26 Felix Meschberger wrote: Hi Radu Thanks for starting this thread. As I wrote in my other message [1], the ScriptEngine management is currently laid out to have script engines to use disjoint extensions. Having two engines with the same extension is not supported. I also don’t really like to have multiple engines to have the same extension. And using „html“ as the extension of a script really is prone for such collisions. Also I don’t like this path thing because it is very brittle and we have enough troubles with them in the Servlet Resolver already … Lets see how Unix' exec() system call does it: It actually ignores the extension and looks for a magic file pattern at the beginning of the file „#!“. So we could extend our ScriptResolution as well like this. If the file begins with a line of the form #!engine-nameCRLF then the named script engine is selected by its name, which now is considered to be unique. The selection only looks at the first two characters to decide whether to actually read the first line. If the first line is of this form, it is consumed and the script engine will not be able to read it — this way we also prevent script engines from failing due to incorrect commenting. If a script does not start with „#!“ then the regular selection by extension kicks in. WDYT ? Adding a Shebang to XML and HTML makes them invalid. So that won't work. Technically yes, but from a processing perspective no: because the SlingScriptAdapterFactory will it it up and the ScriptEngine should not be able to see it anymore. Regards Felix Regards, O. Regards Felix Am 23.01.2015 um 11:17 schrieb Radu Cotescu r...@apache.org: Hello, In SLING-4330 [0] Oliver suggests that Sightly should be configured to render templates only from some search paths sub-paths, because he'd also like to write some Thymeleaf templates in a project, where the Thymeleaf script engine also binds itself to the *.html extension. However, if we'd like scripting engines to process templates based on allowed paths I think that this should happen at a higher level. AFAIK a scripting engine registers itself for an extension, but that's about it. The behaviour that determines which script engine will provide the rendering for a resource is implemented by the SlingServletResolver, which adapts the component's resource to a ScriptEngine. The AdapterFactory that performs the adaptation is implemented by SlingScriptAdapterFactory, which picks the scripting engine based solely on extension. If we'd change the ScriptEngineFactories to also provide the path patterns for which they register and we'd expose the patterns as a configurable OSGi property I think we'd reach the goal of having scripting engines render templates also based on paths. WDYT? Regards, Radu [0] - https://issues.apache.org/jira/browse/SLING-4330
[jira] [Resolved] (SLING-4344) Modifying i18n language node in a path outside the resource resolver's search path will not invalidate the ResourceBundle cache
[
https://issues.apache.org/jira/browse/SLING-4344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus resolved SLING-4344.
Resolution: Fixed
Fix Version/s: i18n 2.3.4
Modifying i18n language node in a path outside the resource resolver's search
path will not invalidate the ResourceBundle cache
---
Key: SLING-4344
URL: https://issues.apache.org/jira/browse/SLING-4344
Project: Sling
Issue Type: Bug
Components: Extensions
Affects Versions: i18n 2.3.2
Reporter: Konrad Windszus
Fix For: i18n 2.3.4
Attachments: SLING-4344-v02.patch
Currently any modification of a Sling i18n message will not invalidate the
{{resourceBundleCache}} in the {{JcrResourceBundleProvide}}
(https://github.com/apache/sling/blob/trunk/contrib/extensions/i18n/src/main/java/org/apache/sling/i18n/impl/JcrResourceBundleProvider.java#L118),
because the {{languageRoots}} for a {{JcrResourceBundle}} with a unique
basename and contents only outside of the resource resolver's search path are
always empty
(https://github.com/apache/sling/blob/trunk/contrib/extensions/i18n/src/main/java/org/apache/sling/i18n/impl/JcrResourceBundle.java#L211).
I would argue that it should be allowed to place language nodes anywhere in
the repository, which seems to work well except for the cache invalidation.
The problem is in the {{loadFully}} method
(https://github.com/apache/sling/blob/trunk/contrib/extensions/i18n/src/main/java/org/apache/sling/i18n/impl/JcrResourceBundle.java#L155)
which will only set languageRoots if they are below any of the resource
resolver's search paths.
To reproduce the issue you can just add the following node structure
{code}
/content/languages
+-- English (nt:folder, mix:language)
|+-- jcr:language = en
|+-- basename = myuniquebasename
|+-- m1 (sling:messageEntry)
||+-- sling:key = msg001
||+-- sling:message = This is a message
{code}
Then load the key from this resource bundle (by giving the right basename).
It will internally put the resource bundle into the cache (although all
contents of the given resource bundle are outside any of the default search
paths /apps or /libs). Whenever you change the message that won't be
reflected, because the resource bundle cache is not invalidated (caused by
the empty {{languageRoots}}) therefore the old message would still be
exposed, until you restart the Sling i18n bundle.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: [VOTE] Release Apache Sling Launchpad Base 4.6.0-2.5.6
+1 Robert On Thu, Jan 22, 2015 at 11:12 PM, Carsten Ziegeler cziege...@apache.org wrote: Hi, we solved one major deadlock issue https://issues.apache.org/jira/browse/SLING/fixforversion/12329291 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-1176/ You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 1176 /tmp/sling-staging Please vote to approve this release: [ ] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... This majority vote is open for at least 72 hours. Regards Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: SlingQuery - exported API
Hello Robert, On Thu, Jan 22, 2015 at 11:23 AM, Robert Munteanu romb...@apache.org wrote: Hi, While doing a recent build of SlingQuery I realized that all packages are exported with the project's version, so we need to add package-info.java files and start versioning. Thanks for pointing this out. Indeed, we should start versioning the SlingQuery API. However, I am curious whether all packages are actually intended to be exported ( list below ) We should export following packages: * org.apache.sling.query (as it contains SlingQuery class, the entrypoint to the whole library), * org.apache.sling.query.api (Predicate, SearchStrategy and other types for the queries customization), Other packages contains the implementation or the internal API (like org.apache.sling.query.api.function) and don't have to be exposed externally. Could you add appropriate package-info.java files to the two mentioned packages? Best regards, Tomek -- Tomek Rękawek Senior Software Engineer Cognifide Polska Sp. z o.o. skype: trekawek www.cognifide.com
Jenkins build is back to stable : sling-trunk-1.6 #2974
See https://builds.apache.org/job/sling-trunk-1.6/2974/changes
[jira] [Commented] (SLING-4344) Modifying i18n language node in a path outside the resource resolver's search path will not invalidate the ResourceBundle cache
[
https://issues.apache.org/jira/browse/SLING-4344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14288957#comment-14288957
]
Konrad Windszus commented on SLING-4344:
Applied a slightly modified patch in rev 1653136.
Modifying i18n language node in a path outside the resource resolver's search
path will not invalidate the ResourceBundle cache
---
Key: SLING-4344
URL: https://issues.apache.org/jira/browse/SLING-4344
Project: Sling
Issue Type: Bug
Components: Extensions
Affects Versions: i18n 2.3.2
Reporter: Konrad Windszus
Attachments: SLING-4344-v02.patch
Currently any modification of a Sling i18n message will not invalidate the
{{resourceBundleCache}} in the {{JcrResourceBundleProvide}}
(https://github.com/apache/sling/blob/trunk/contrib/extensions/i18n/src/main/java/org/apache/sling/i18n/impl/JcrResourceBundleProvider.java#L118),
because the {{languageRoots}} for a {{JcrResourceBundle}} with a unique
basename and contents only outside of the resource resolver's search path are
always empty
(https://github.com/apache/sling/blob/trunk/contrib/extensions/i18n/src/main/java/org/apache/sling/i18n/impl/JcrResourceBundle.java#L211).
I would argue that it should be allowed to place language nodes anywhere in
the repository, which seems to work well except for the cache invalidation.
The problem is in the {{loadFully}} method
(https://github.com/apache/sling/blob/trunk/contrib/extensions/i18n/src/main/java/org/apache/sling/i18n/impl/JcrResourceBundle.java#L155)
which will only set languageRoots if they are below any of the resource
resolver's search paths.
To reproduce the issue you can just add the following node structure
{code}
/content/languages
+-- English (nt:folder, mix:language)
|+-- jcr:language = en
|+-- basename = myuniquebasename
|+-- m1 (sling:messageEntry)
||+-- sling:key = msg001
||+-- sling:message = This is a message
{code}
Then load the key from this resource bundle (by giving the right basename).
It will internally put the resource bundle into the cache (although all
contents of the given resource bundle are outside any of the default search
paths /apps or /libs). Whenever you change the message that won't be
reflected, because the resource bundle cache is not invalidated (caused by
the empty {{languageRoots}}) therefore the old message would still be
exposed, until you restart the Sling i18n bundle.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: [VOTE] Release Apache Sling Testing JCR Mock 1.1.2, ResourceResolver Mock 1.1.2, Sling Mock 1.1.2, Sling Mock Jackrabbit 0.1.2
+1 Robert On Thu, Jan 22, 2015 at 11:10 PM, Stefan Seifert sseif...@pro-vision.de wrote: Hi, We solved 2 issues in JCR Mock 1.1.2: https://issues.apache.org/jira/browse/SLING/fixforversion/12329091 We solved 2 issues in ResourceResolver Mock 1.1.2: https://issues.apache.org/jira/browse/SLING/fixforversion/12329092 We solved 3 issues in Sling Mock 1.1.2: https://issues.apache.org/jira/browse/SLING/fixforversion/12329089 We solved 2 issues in Sling Mock Jackrabbit 0.1.2: https://issues.apache.org/jira/browse/SLING/fixforversion/12328858 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-1175/ You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 1175 /tmp/sling-staging Please vote to approve this release: [ ] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... This majority vote is open for at least 72 hours. stefan
Re: [VOTE] Release Apache Sling JCR Resource 2.4.2
+1 On Jan 19, 2015, at 6:33 PM, Carsten Ziegeler cziege...@apache.org wrote: Hi, we solved some issues https://issues.apache.org/jira/browse/SLING/fixforversion/12328895 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-1174/ You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 1174 /tmp/sling-staging Please vote to approve this release: [ ] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... This majority vote is open for at least 72 hours. Regards Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: Re: [discussion] allow Script Engines to also render components based on paths
On Fri, Jan 23, 2015 at 1:15 PM, Bertrand Delacretaz bdelacre...@apache.org wrote: Good point - we can consider that notation say anywhere in the first 200 chars of the script, so ?xml version=1.0 encoding=UTF-8? !-- sling:language: thymeleaf -- foo/ would work, the pattern being sling:language followed by whitespace and one word which is the language name. This has the disadvantage that the Servlet Resolver would have to parse the first n characters of the script and then the Script Engine would parse again the whole file. We should not increase the number of resource reads, if not really needed. If we want to have a conflict resolution mechanism we could add a property on component nodes (but they must be sling:Folder / nt:unstructured) that would handle which of the multiple scripting engines registered for the same extension should be used: sling:script - html:thymeleaf This would essentially say that for the *.html scripts for this component, Thymeleaf should be used. However, this adds an unnecessary step for component developers. I think the configurable patterns on the ScriptEngineFactories is simpler, as this is essentially a deployment issue. Whatever the approach is, if we want to allow multiple scripting engines to use the same extension we need to refactor the code from the SlingScriptEngineManager.
Re: [discussion] allow Script Engines to also render components based on paths
On Fri, Jan 23, 2015 at 1:59 PM, Oliver Lietz apa...@oliverlietz.de wrote: Whatever the approach is, if we want to allow multiple scripting engines to use the same extension we need to refactor the code from the SlingScriptEngineManager. Why? The ScriptEngine itself can decide if it kicks in for a script based on the paths patterns. If we configure various ScriptEngine implementations it becomes harder to get an overview of what it configured where. It's even possible to have conflicting patterns in two scripting engines. Robert -- Sent from my (old) computer
Re: [discussion] allow Script Engines to also render components based on paths
On Fri, Jan 23, 2015 at 2:08 PM, Robert Munteanu rob...@lmn.ro wrote: If we configure various ScriptEngine implementations it becomes harder to get an overview of what it configured where. It's even possible to have conflicting patterns in two scripting engines. We could have a master component that provides the needed configuration for all engines, simplifying the configuration issue you mentioned.
Re: [discussion] allow Script Engines to also render components based on paths
On Friday 23 January 2015 13:33:37 Radu Cotescu wrote: On Fri, Jan 23, 2015 at 1:15 PM, Bertrand Delacretaz bdelacre...@apache.org wrote: Good point - we can consider that notation say anywhere in the first 200 chars of the script, so ?xml version=1.0 encoding=UTF-8? !-- sling:language: thymeleaf -- foo/ would work, the pattern being sling:language followed by whitespace and one word which is the language name. This has the disadvantage that the Servlet Resolver would have to parse the first n characters of the script and then the Script Engine would parse again the whole file. We should not increase the number of resource reads, if not really needed. If we want to have a conflict resolution mechanism we could add a property on component nodes (but they must be sling:Folder / nt:unstructured) that would handle which of the multiple scripting engines registered for the same extension should be used: sling:script - html:thymeleaf This would essentially say that for the *.html scripts for this component, Thymeleaf should be used. However, this adds an unnecessary step for component developers. I think the configurable patterns on the ScriptEngineFactories is simpler, as this is essentially a deployment issue. Totally agree. Whatever the approach is, if we want to allow multiple scripting engines to use the same extension we need to refactor the code from the SlingScriptEngineManager. Why? The ScriptEngine itself can decide if it kicks in for a script based on the paths patterns. O.
[jira] [Created] (SLING-4346) Sightly: HtmlParser does not parse documents correctly when comments span across internal char buffer size
Vlad Bailescu created SLING-4346:
Summary: Sightly: HtmlParser does not parse documents correctly
when comments span across internal char buffer size
Key: SLING-4346
URL: https://issues.apache.org/jira/browse/SLING-4346
Project: Sling
Issue Type: Bug
Components: Scripting
Reporter: Vlad Bailescu
Fix For: Scripting Sightly Engine 1.0.2
The HTML parser used by Sightly to process templates is parsing incorrectly
comments that span across it's internal char buffer size. Right now the buffer
is set to 2048 characters, making the problem hard to see.
The problem can be exposed by lowering the buffer size to 10 and feeding a
string such as {code:java}test test !--/*comment*/--{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (SLING-4348) Sync agents do not process the queue anymore
Marius Petria created SLING-4348: Summary: Sync agents do not process the queue anymore Key: SLING-4348 URL: https://issues.apache.org/jira/browse/SLING-4348 Project: Sling Issue Type: Bug Reporter: Marius Petria Sync agents do not process the queue anymore. The queueEnabled flag is always false. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-4348) Sync agents do not process the queue anymore
[ https://issues.apache.org/jira/browse/SLING-4348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marius Petria updated SLING-4348: - Component/s: Distribution Sync agents do not process the queue anymore Key: SLING-4348 URL: https://issues.apache.org/jira/browse/SLING-4348 Project: Sling Issue Type: Bug Components: Distribution Reporter: Marius Petria Sync agents do not process the queue anymore. The queueEnabled flag is always false. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4348) Sync agents do not process the queue anymore
[ https://issues.apache.org/jira/browse/SLING-4348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14290484#comment-14290484 ] Marius Petria commented on SLING-4348: -- Committed revision 1654477. Sync agents do not process the queue anymore Key: SLING-4348 URL: https://issues.apache.org/jira/browse/SLING-4348 Project: Sling Issue Type: Bug Components: Distribution Reporter: Marius Petria Sync agents do not process the queue anymore. The queueEnabled flag is always false. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (SLING-4348) Sync agents do not process the queue anymore
[ https://issues.apache.org/jira/browse/SLING-4348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marius Petria resolved SLING-4348. -- Resolution: Fixed Sync agents do not process the queue anymore Key: SLING-4348 URL: https://issues.apache.org/jira/browse/SLING-4348 Project: Sling Issue Type: Bug Components: Distribution Reporter: Marius Petria Sync agents do not process the queue anymore. The queueEnabled flag is always false. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (SLING-4348) Sync agents do not process the queue anymore
[ https://issues.apache.org/jira/browse/SLING-4348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marius Petria reassigned SLING-4348: Assignee: Marius Petria Sync agents do not process the queue anymore Key: SLING-4348 URL: https://issues.apache.org/jira/browse/SLING-4348 Project: Sling Issue Type: Bug Components: Distribution Reporter: Marius Petria Assignee: Marius Petria Sync agents do not process the queue anymore. The queueEnabled flag is always false. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: org.apache.sling.urlrewriter installation
On Jan 22, 2015, at 6:50 PM, Oliver Lietz apa...@oliverlietz.demailto:apa...@oliverlietz.de wrote: On Thursday 22 January 2015 15:17:37 Antonio Sanso wrote: On Jan 22, 2015, at 3:52 PM, Oliver Lietz apa...@oliverlietz.demailto:apa...@oliverlietz.de wrote: On Thursday 22 January 2015 13:02:05 Antonio Sanso wrote: hi *, hi Antonio, in order to try to solve SLING-3829 [0] I have been tried the approach proposed by Oliver. So I have tried to install org.apache.sling.urlrewriter. First step as suggested is to install mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.urlrewrit ef ilter/4.0.4_1 and this succeeded. But when I try to install the org.apache.sling.urlrewriter bundle I get the error [1]. @Oliver @all any idea? are you installing to Sling or CQ/AEM? Will have a look. both :) I've built the current version from Subversion (and run an IT similar to those others for Launchpad Karaf) and deployed it successfully to my Sling (on Karaf) instance. this might me the thing. I do (as the majority I guess) run Sling on Felix…. any idea? regards antonio Maybe there is something wrong with your javax.servlet- bundle/package-export or the MANIFEST.MF of the o.a.s.urlrewriter is broken - can you check? I killed my settings.xml and can't deploy a snapshot right now, sorry. O. O. regards antonio [0] https://issues.apache.org/jira/browse/SLING-3829 [...]
[jira] [Commented] (SLING-4330) provide a configuration parameter for paths patterns Sightly should handle
[
https://issues.apache.org/jira/browse/SLING-4330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14288996#comment-14288996
]
Oliver Lietz commented on SLING-4330:
-
{{org.apache.sling.scripting.sightly.ResourceResolution}} performs resource
resolution in Sightly. I suggest making it a service and add pattern matching
here. WDYT, [~radu.cotescu]?
provide a configuration parameter for paths patterns Sightly should handle
--
Key: SLING-4330
URL: https://issues.apache.org/jira/browse/SLING-4330
Project: Sling
Issue Type: New Feature
Components: Scripting
Affects Versions: Scripting Sightly Engine 1.0.0
Reporter: 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)
Re: [jira] [Commented] (SLING-4330) provide a configuration parameter for paths patterns Sightly should handle
Threads collide .. lets continue the discussion on Radu’s thread [discussion]
allow Script Engines to also render components based on paths“
Regards
Felix
Am 23.01.2015 um 11:19 schrieb Felix Meschberger fmesc...@adobe.com:
Hi
So we have a problem in that two script engines are using the same
script/template extension ?
I think we cannot handle this with a mechanism such as SLING-4330. I also
think that script engines should not limit themselves in where they would
like to be evaluated. That’s none of their business. They get a script and
they should (try to) evaluate it. It is the ScriptResolver’s task to decide
whether to evaluate a script or not given that it has a certain location.
Now, the deeper problem really is that the ScriptEngine infrastructure is not
intended to support two different script languages with the same extension.
Also the intent of a script extension is to indicate the language the script
is written in.
Also, the ScriptEngineManager as we use it today is *not* able to register
multiple script engines for the same extension — its always one or the other
— unfortunately its the last one registered that wins.
So we really have to fix the underlying problem (and needless to say, that I
really don’t like using the extension „html“ for a script/template…) and
maybe change the extension of one or the other scripting language if they
should be used concurrently on the same instance.
Regards
Felix
Am 19.01.2015 um 11:40 schrieb Oliver Lietz (JIRA) j...@apache.org:
[
https://issues.apache.org/jira/browse/SLING-4330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14282371#comment-14282371
]
Oliver Lietz commented on SLING-4330:
-
bq. Do I understand it correctly, that you propose to limit a ScriptEngine
to only handle scripts found at a certain location ?
Yes. I'm bringing an application to AEM 6 where different teams from
different companies work on the HTML templating in a round-trip manner. I
had to disable Sightly on AEM 6 as it always kicks in for scripts/templates
with extension {{.html}} and fails. This seems not to be a problem right now
as Classic UI is used for authoring and administration and JSPs besides
Thymeleaf for templating, but could (_will_) be a problem in the future of
course. Ideally I can configure Sightly to only handle scripts e.g. in
{{/libs/foundation}} and {{/apps/client/app2}}.
provide a configuration parameter for paths patterns Sightly should handle
--
Key: SLING-4330
URL: https://issues.apache.org/jira/browse/SLING-4330
Project: Sling
Issue Type: New Feature
Components: Scripting
Affects Versions: Scripting Sightly Engine 1.0.0
Reporter: 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)
Re: [discussion] allow Script Engines to also render components based on paths
On Fri, Jan 23, 2015 at 11:30 AM, Felix Meschberger fmesc...@adobe.com wrote: We could extend our ScriptResolution as well like this. If the file begins with a line of the form #!engine-nameCRLF Why not. It's a bit costly as you need to read part of the script during resolution but I suppose this can be cached. I'd make the syntax specific to Sling then, maybe like #!sling:language thymeleaf so that people know where to look for the meaning of that. And of course make the engine's extensions configurable (I hope that's already the case) so if someone wants to use .sly for Sightly and .tlf for Thymeleaf that should be possible. -Bertrand
Re: Re: [discussion] allow Script Engines to also render components based on paths
On Fri, Jan 23, 2015 at 11:55 AM, Oliver Lietz apa...@oliverlietz.de wrote: ...Adding a Shebang to XML and HTML makes them invalid Good point - we can consider that notation say anywhere in the first 200 chars of the script, so ?xml version=1.0 encoding=UTF-8? !-- sling:language: thymeleaf -- foo/ would work, the pattern being sling:language followed by whitespace and one word which is the language name. -Bertrand
[jira] [Commented] (SLING-4330) provide a configuration parameter for paths patterns Sightly should handle
[
https://issues.apache.org/jira/browse/SLING-4330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14289037#comment-14289037
]
Radu Cotescu commented on SLING-4330:
-
The {{ResourceResolution}} class is responsible for identifying components or
use objects relative to a base resource or to a request.
If we'd like scripting engines to process templates based on allowed paths I
think that this should happen at a higher level. AFAIK a scripting engine
registers itself for an extension, but that's about it. The behaviour that
determines which script engine will provide the rendering for a resource is
implemented by the {{SlingServletResolver}}, which adapts the component's
resource to a {{ScriptEngine}}.
The {{AdapterFactory}} that performs the adaptation is implemented by
{{SlingScriptAdapterFactory}}, which picks the scripting engine based solely on
extension. If we'd change the {{ScriptEngineFactories}} to also provide the
path patterns for which they register and we'd expose the patterns as a
configurable OSGi property I think we'd reach the goal of having scripting
engines rendering templates also based on paths.
Let's have this discussion on sling-dev.
provide a configuration parameter for paths patterns Sightly should handle
--
Key: SLING-4330
URL: https://issues.apache.org/jira/browse/SLING-4330
Project: Sling
Issue Type: New Feature
Components: Scripting
Affects Versions: Scripting Sightly Engine 1.0.0
Reporter: 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)
Re: [discussion] allow Script Engines to also render components based on paths
On Friday 23 January 2015 11:52:20 Bertrand Delacretaz wrote: On Fri, Jan 23, 2015 at 11:30 AM, Felix Meschberger fmesc...@adobe.com wrote: We could extend our ScriptResolution as well like this. If the file begins with a line of the form #!engine-nameCRLF Why not. It's a bit costly as you need to read part of the script during resolution but I suppose this can be cached. I'd make the syntax specific to Sling then, maybe like #!sling:language thymeleaf so that people know where to look for the meaning of that. And of course make the engine's extensions configurable (I hope that's already the case) so if someone wants to use .sly for Sightly and .tlf for Thymeleaf that should be possible. That's the case for Thymeleaf. Thymeleaf 3 comes with support for pure templates - HTML/XML without Thymeleaf tags/attributes at all - so pure HTML/XML. O. -Bertrand
Re: [jira] [Commented] (SLING-4330) provide a configuration parameter for paths patterns Sightly should handle
Hi
So we have a problem in that two script engines are using the same
script/template extension ?
I think we cannot handle this with a mechanism such as SLING-4330. I also think
that script engines should not limit themselves in where they would like to be
evaluated. That’s none of their business. They get a script and they should
(try to) evaluate it. It is the ScriptResolver’s task to decide whether to
evaluate a script or not given that it has a certain location.
Now, the deeper problem really is that the ScriptEngine infrastructure is not
intended to support two different script languages with the same extension.
Also the intent of a script extension is to indicate the language the script is
written in.
Also, the ScriptEngineManager as we use it today is *not* able to register
multiple script engines for the same extension — its always one or the other —
unfortunately its the last one registered that wins.
So we really have to fix the underlying problem (and needless to say, that I
really don’t like using the extension „html“ for a script/template…) and maybe
change the extension of one or the other scripting language if they should be
used concurrently on the same instance.
Regards
Felix
Am 19.01.2015 um 11:40 schrieb Oliver Lietz (JIRA) j...@apache.org:
[
https://issues.apache.org/jira/browse/SLING-4330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14282371#comment-14282371
]
Oliver Lietz commented on SLING-4330:
-
bq. Do I understand it correctly, that you propose to limit a ScriptEngine to
only handle scripts found at a certain location ?
Yes. I'm bringing an application to AEM 6 where different teams from
different companies work on the HTML templating in a round-trip manner. I had
to disable Sightly on AEM 6 as it always kicks in for scripts/templates with
extension {{.html}} and fails. This seems not to be a problem right now as
Classic UI is used for authoring and administration and JSPs besides
Thymeleaf for templating, but could (_will_) be a problem in the future of
course. Ideally I can configure Sightly to only handle scripts e.g. in
{{/libs/foundation}} and {{/apps/client/app2}}.
provide a configuration parameter for paths patterns Sightly should handle
--
Key: SLING-4330
URL: https://issues.apache.org/jira/browse/SLING-4330
Project: Sling
Issue Type: New Feature
Components: Scripting
Affects Versions: Scripting Sightly Engine 1.0.0
Reporter: 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)
Re: [discussion] allow Script Engines to also render components based on paths
Hi Radu Thanks for starting this thread. As I wrote in my other message [1], the ScriptEngine management is currently laid out to have script engines to use disjoint extensions. Having two engines with the same extension is not supported. I also don’t really like to have multiple engines to have the same extension. And using „html“ as the extension of a script really is prone for such collisions. Also I don’t like this path thing because it is very brittle and we have enough troubles with them in the Servlet Resolver already … Lets see how Unix' exec() system call does it: It actually ignores the extension and looks for a magic file pattern at the beginning of the file „#!“. So we could extend our ScriptResolution as well like this. If the file begins with a line of the form #!engine-nameCRLF then the named script engine is selected by its name, which now is considered to be unique. The selection only looks at the first two characters to decide whether to actually read the first line. If the first line is of this form, it is consumed and the script engine will not be able to read it — this way we also prevent script engines from failing due to incorrect commenting. If a script does not start with „#!“ then the regular selection by extension kicks in. WDYT ? Regards Felix Am 23.01.2015 um 11:17 schrieb Radu Cotescu r...@apache.org: Hello, In SLING-4330 [0] Oliver suggests that Sightly should be configured to render templates only from some search paths sub-paths, because he'd also like to write some Thymeleaf templates in a project, where the Thymeleaf script engine also binds itself to the *.html extension. However, if we'd like scripting engines to process templates based on allowed paths I think that this should happen at a higher level. AFAIK a scripting engine registers itself for an extension, but that's about it. The behaviour that determines which script engine will provide the rendering for a resource is implemented by the SlingServletResolver, which adapts the component's resource to a ScriptEngine. The AdapterFactory that performs the adaptation is implemented by SlingScriptAdapterFactory, which picks the scripting engine based solely on extension. If we'd change the ScriptEngineFactories to also provide the path patterns for which they register and we'd expose the patterns as a configurable OSGi property I think we'd reach the goal of having scripting engines render templates also based on paths. WDYT? Regards, Radu [0] - https://issues.apache.org/jira/browse/SLING-4330
Re: Re: [discussion] allow Script Engines to also render components based on paths
On Friday 23 January 2015 10:30:26 Felix Meschberger wrote: Hi Radu Thanks for starting this thread. As I wrote in my other message [1], the ScriptEngine management is currently laid out to have script engines to use disjoint extensions. Having two engines with the same extension is not supported. I also don’t really like to have multiple engines to have the same extension. And using „html“ as the extension of a script really is prone for such collisions. Also I don’t like this path thing because it is very brittle and we have enough troubles with them in the Servlet Resolver already … Lets see how Unix' exec() system call does it: It actually ignores the extension and looks for a magic file pattern at the beginning of the file „#!“. So we could extend our ScriptResolution as well like this. If the file begins with a line of the form #!engine-nameCRLF then the named script engine is selected by its name, which now is considered to be unique. The selection only looks at the first two characters to decide whether to actually read the first line. If the first line is of this form, it is consumed and the script engine will not be able to read it — this way we also prevent script engines from failing due to incorrect commenting. If a script does not start with „#!“ then the regular selection by extension kicks in. WDYT ? Adding a Shebang to XML and HTML makes them invalid. So that won't work. Regards, O. Regards Felix Am 23.01.2015 um 11:17 schrieb Radu Cotescu r...@apache.org: Hello, In SLING-4330 [0] Oliver suggests that Sightly should be configured to render templates only from some search paths sub-paths, because he'd also like to write some Thymeleaf templates in a project, where the Thymeleaf script engine also binds itself to the *.html extension. However, if we'd like scripting engines to process templates based on allowed paths I think that this should happen at a higher level. AFAIK a scripting engine registers itself for an extension, but that's about it. The behaviour that determines which script engine will provide the rendering for a resource is implemented by the SlingServletResolver, which adapts the component's resource to a ScriptEngine. The AdapterFactory that performs the adaptation is implemented by SlingScriptAdapterFactory, which picks the scripting engine based solely on extension. If we'd change the ScriptEngineFactories to also provide the path patterns for which they register and we'd expose the patterns as a configurable OSGi property I think we'd reach the goal of having scripting engines render templates also based on paths. WDYT? Regards, Radu [0] - https://issues.apache.org/jira/browse/SLING-4330
Re: Re: [discussion] allow Script Engines to also render components based on paths
On Fri, Jan 23, 2015 at 12:15 PM, Bertrand Delacretaz bdelacre...@apache.org wrote: ... the pattern being sling:language followed by whitespace and one word which is the language name Or maybe sling:script to avoid confusion with human languages. -Bertrand
[GitHub] sling pull request: SLING-4318 Servlet rendering a list of version...
GitHub user trekawek opened a pull request: https://github.com/apache/sling/pull/58 SLING-4318 Servlet rendering a list of versions for the given resource. You can merge this pull request into a Git repository by running: $ git pull https://github.com/trekawek/sling SLING-4318-listing-versions Alternatively you can review and apply these changes as the patch at: https://github.com/apache/sling/pull/58.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #58 commit bf57ec8a5dc0b732945fc2e08e280d5b83b7f945 Author: Tomasz Rękawek treka...@gmail.com Date: 2015-01-23T12:50:26Z Servlet rendering a list of versions for the given resource. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
Re: sling-trunk buildbot CI build causing problems
On Fri, Jan 23, 2015 at 1:03 AM, Mark Thomas ma...@apache.org wrote: Sling developers, The sling-trunk CI build managed to kill one of the buildbot slaves by filling this directory with files until the file system ran out of inodes: /home/buildslave3/slave3/sling-trunk/build/testing/samples/integration-tests/sling/default/jackrabbit/workspaces/default/index There were so many files ls hung for 5+ minutes without any output. I have started to clean this up (rm -rf /home/buildslave3/slave3/sling-trunk) and that looks like it is going to take at least several hours to complete. The next CI build should re-checkout sling-trunk so your CI builds should be unaffected. However, please could you take a look at the buildbot configuration for this build and figure out a) why this happened and b) how to stop it happening again. (Moving the discussion to dev@ only while we try to find a solution) Does anyone have any idea about why this happens? I'm wondering if we still need the buildbot setup as the Jenkins builds seem to be (mostly) stable these days. Robert Cheers, Mark on behalf of the ASF Infra team
[GitHub] sling pull request: SLING-4318 :restore operation for the SlingPos...
GitHub user trekawek opened a pull request: https://github.com/apache/sling/pull/59 SLING-4318 :restore operation for the SlingPostServlet You can merge this pull request into a Git repository by running: $ git pull https://github.com/trekawek/sling SLING-4318-restore-operation Alternatively you can review and apply these changes as the patch at: https://github.com/apache/sling/pull/59.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #59 commit a1aa27f32671bbe4f9968b38e79eb721ffba1f8e Author: Tomasz Rękawek treka...@gmail.com Date: 2015-01-23T13:21:53Z Initial version of the :restore operation. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (SLING-4318) Sling resource API does not expose any versioning features - bounty offered.
[ https://issues.apache.org/jira/browse/SLING-4318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14289229#comment-14289229 ] ASF GitHub Bot commented on SLING-4318: --- GitHub user trekawek opened a pull request: https://github.com/apache/sling/pull/58 SLING-4318 Servlet rendering a list of versions for the given resource. You can merge this pull request into a Git repository by running: $ git pull https://github.com/trekawek/sling SLING-4318-listing-versions Alternatively you can review and apply these changes as the patch at: https://github.com/apache/sling/pull/58.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #58 commit bf57ec8a5dc0b732945fc2e08e280d5b83b7f945 Author: Tomasz Rękawek treka...@gmail.com Date: 2015-01-23T12:50:26Z Servlet rendering a list of versions for the given resource. Sling resource API does not expose any versioning features - bounty offered. Key: SLING-4318 URL: https://issues.apache.org/jira/browse/SLING-4318 Project: Sling Issue Type: New Feature Components: Documentation, JCR, Servlets Affects Versions: Servlets Resolver 2.3.8 Environment: N/A Reporter: Bruce Edge Labels: api, crud, servlet-api, versioning, versions The javax.jcr.version.VersionManager is not exposed in the sling resource API: http://thread.gmane.org/gmane.comp.apache.sling.user/1610 My company is interested in paying for this development. Please contact if interested. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4318) Sling resource API does not expose any versioning features - bounty offered.
[ https://issues.apache.org/jira/browse/SLING-4318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14289231#comment-14289231 ] ASF GitHub Bot commented on SLING-4318: --- GitHub user trekawek opened a pull request: https://github.com/apache/sling/pull/59 SLING-4318 :restore operation for the SlingPostServlet You can merge this pull request into a Git repository by running: $ git pull https://github.com/trekawek/sling SLING-4318-restore-operation Alternatively you can review and apply these changes as the patch at: https://github.com/apache/sling/pull/59.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #59 commit a1aa27f32671bbe4f9968b38e79eb721ffba1f8e Author: Tomasz Rękawek treka...@gmail.com Date: 2015-01-23T13:21:53Z Initial version of the :restore operation. Sling resource API does not expose any versioning features - bounty offered. Key: SLING-4318 URL: https://issues.apache.org/jira/browse/SLING-4318 Project: Sling Issue Type: New Feature Components: Documentation, JCR, Servlets Affects Versions: Servlets Resolver 2.3.8 Environment: N/A Reporter: Bruce Edge Labels: api, crud, servlet-api, versioning, versions The javax.jcr.version.VersionManager is not exposed in the sling resource API: http://thread.gmane.org/gmane.comp.apache.sling.user/1610 My company is interested in paying for this development. Please contact if interested. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4212) Sling Models: Allow multiple values from ValueMap in the resource-path injector
[ https://issues.apache.org/jira/browse/SLING-4212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14289232#comment-14289232 ] santiago garcía pimentel commented on SLING-4212: - [~sseif...@pro-vision.de] Yes, the code to check if it is required or optional is a bit messy, but I could not find any other way. An all or nothing approach would not be ideally for me, but I think it'll work good enough. I think that adding a new interface is too much struggle for only one feature. I can make some additional changes later (I'm not sure I'll have a lot of time recently) and update the patch. Maybe I would just have to check a previous commit. Im not sure. Sling Models: Allow multiple values from ValueMap in the resource-path injector --- Key: SLING-4212 URL: https://issues.apache.org/jira/browse/SLING-4212 Project: Sling Issue Type: Improvement Components: Extensions Reporter: santiago garcía pimentel Assignee: Stefan Seifert Fix For: Sling Models API 1.2.0, Sling Models Impl 1.2.0 Attachments: resourcePath-API.patch, resourcePath-API_updated.patch The current implementation of the resource-path injector does not support multiple values. I think it could be useful to inject a list of paths from the valuemap. I have created a small patch to allow this. Right now it only allows them from the value map since I didn't want to change the API without consulting you first. I you agree I can do this change as well. I also added a test case for it. You can see a pull request in https://github.com/apache/sling/pull/51 If there anything I can do to improve this patch, please let me know. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4258) JSON representation of Calendar values should preserve timezone
[ https://issues.apache.org/jira/browse/SLING-4258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14289234#comment-14289234 ] santiago garcía pimentel commented on SLING-4258: - [~bdelacretaz] do you think the patch can be merged now? Also. what are your thoughts in preserving the timezone in the other formats that includes it? the change would not be particularly large. JSON representation of Calendar values should preserve timezone --- Key: SLING-4258 URL: https://issues.apache.org/jira/browse/SLING-4258 Project: Sling Issue Type: Improvement Components: Commons Affects Versions: Commons JSON 2.0.10 Reporter: santiago garcía pimentel Assignee: Bertrand Delacretaz Priority: Minor Fix For: Commons JSON 2.0.12 Attachments: SLING-4258.patch Im currently doing some things with dates in Sling that involve timezones and I find that the documentation regarding it is not particularly clear. according to https://sling.apache.org/documentation/bundles/manipulating-content-the-slingpostservlet-servlets-post.html#date-properties several formats are defined. I found that the only format that saves a provided timezone is the ISO8601 format, rest of them relies in a Date object, which does not have timezones. Could this be clearly stated? Also, the ISO8601 parser is problematic. It relies on the Jackrabbit parser which uses format ±-MM-DDThh:mm:ss.SSSTZD, but according to http://www.w3.org/TR/NOTE-datetime the ISO format does not have milliseconds on it (SSS). So it is very hard to find a way to keep the timezone information (I had to dig through the code to figure it out) Could we please replace ISO8601 with the actual format ±-MM-DDThh:mm:ss.SSSTZD so it is clearer? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4318) Sling resource API does not expose any versioning features - bounty offered.
[
https://issues.apache.org/jira/browse/SLING-4318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14289243#comment-14289243
]
Tomek Rękawek commented on SLING-4318:
--
The {{;v=1.0}} parameter support has been implemented in SLING-848. I also
prepared two other features related to versioning, mentioned in the comment
above:
*Version list servlet*
Using *V* selector allows to get the version history for a given resource. Data
are presented in following format:
{code}
curl http://localhost:4502/content/test.V.tidy.json
{
jcr:rootVersion: {
created: Fri Jan 23 2015 11:02:09 GMT+0100,
successors: [1.0],
predecessors: [],
labels: [firstVersion],
baseVersion: false
},
1.0: {
created: Fri Jan 23 2015 11:02:11 GMT+0100,
successors: [1.1],
predecessors: [jcr:rootVersion],
labels: [secondVersion, afterChanges],
baseVersion: true
}
}
{code}
Pull request: https://github.com/apache/sling/pull/58/files
*Restore operation*
The new {{:operation=restore parameter}} allows to restore a resource to a
given version referenced by name or label:
{code}
curl -X POST -F :operation=restore -F :version=1.0
http://localhost:4502/content/test
{code}
Pull request: https://github.com/apache/sling/pull/59/files
I'm looking forward to feedback.
Sling resource API does not expose any versioning features - bounty offered.
Key: SLING-4318
URL: https://issues.apache.org/jira/browse/SLING-4318
Project: Sling
Issue Type: New Feature
Components: Documentation, JCR, Servlets
Affects Versions: Servlets Resolver 2.3.8
Environment: N/A
Reporter: Bruce Edge
Labels: api, crud, servlet-api, versioning, versions
The javax.jcr.version.VersionManager is not exposed in the sling resource API:
http://thread.gmane.org/gmane.comp.apache.sling.user/1610
My company is interested in paying for this development. Please contact if
interested.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: [VOTE] Release Apache Sling Testing JCR Mock 1.1.2, ResourceResolver Mock 1.1.2, Sling Mock 1.1.2, Sling Mock Jackrabbit 0.1.2
+1 Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: [VOTE] Release Apache Sling Launchpad Base 4.6.0-2.5.6
+1 Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
RE: [Sightly] provide access to the Script Resource Resolver in RenderContext
I share Felix's concern. If the ServletResolver's resolver is passed around, please ensure it is a service user with minimal permissions required for ServletResolver's needs. We do *not* want to allow a resolver passed around from the ServletResolver to be abused for accessing general content. If Slightly RuntimeExtensions need more access than the ServletResolver they should manage a resolver themselves. Also, this sounds like premature optimization. If ResourceResolver creation is slow the ROI on making it faster is likely significant as multi-thread usage of a session in Oak degrades performance rapidly. -Rob -Original Message- From: Felix Meschberger [mailto:fmesc...@adobe.com] Sent: Friday, January 23, 2015 5:58 AM To: dev@sling.apache.org Subject: Re: [Sightly] provide access to the Script Resource Resolver in RenderContext Hi I am a bit hesitant with shipping ResourceResolver instances around. But since this is for an extension of the scripting language, this might make sense. We just have to properly document that this is not the request processing ResourceResolver but the ServletResolver’s ResourceResolver which is only intended to be used for script resolution tasks. Regards Felix Am 22.01.2015 um 14:21 schrieb Radu Cotescu r...@apache.org: Hi, There are cases when Sightly RuntimeExtensions might need to access the repository. Since creating multiple ResourceResolvers is not a cheap operation, especially with Jackrabbit, wouldn't it be better to enhance the RenderContext to make it provide the ResourceResolver available in the ScriptContext? This ResourceResolver is already used by the Sightly engine for script rendering, so IMO it could also be passed down to RuntimeExtensions: final ResourceResolver scriptResourceResolver = (ResourceResolver) scriptContext.getAttribute(SlingScriptConstants.ATTR_SCRIPT_RESOURCE_R ESOLVER, SlingScriptConstants.SLING_SCOPE); // line 78 of org.apache.sling.scripting.sightly.impl.engine.SightlyScriptEngine WDYT? Cheers, Radu
Re: [discussion] allow Script Engines to also render components based on paths
What about adding an additional property to the script resource? Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: [discussion] allow Script Engines to also render components based on paths
Reminds me of the Mac Resource Forks … :-) It would be neat to be able to set this in/on the script itself without having to manage some out-of-band metadata. Regards Felix Am 23.01.2015 um 15:15 schrieb Carsten Ziegeler cziege...@apache.org: What about adding an additional property to the script resource? Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: [discussion] allow Script Engines to also render components based on paths
Am 23.01.15 um 06:04 schrieb Felix Meschberger: Adding a Shebang to XML and HTML makes them invalid. So that won't work. Technically yes, but from a processing perspective no: because the SlingScriptAdapterFactory will it it up and the ScriptEngine should not be able to see it anymore. But wouldn't that mean that we potentially loose the tooling advantages as the tools might not cope with the extra line at the beginning and consider the file invalid? Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
[jira] [Resolved] (SLING-4346) Sightly: HtmlParser does not parse documents correctly when comments span across internal char buffer size
[
https://issues.apache.org/jira/browse/SLING-4346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Felix Meschberger resolved SLING-4346.
--
Resolution: Fixed
Fix Version/s: (was: Scripting Sightly Engine 1.0.2)
Scripting Sightly Engine 1.0.0
Assignee: Felix Meschberger
Thanks for providing the patch. I have applied it in Rev. 1654218
Sightly: HtmlParser does not parse documents correctly when comments span
across internal char buffer size
--
Key: SLING-4346
URL: https://issues.apache.org/jira/browse/SLING-4346
Project: Sling
Issue Type: Bug
Components: Scripting
Reporter: Vlad Bailescu
Assignee: Felix Meschberger
Fix For: Scripting Sightly Engine 1.0.0
Attachments:
SLING-4346_Sightly__HtmlParser_does_not_parse_documents_correctly_when_comments_span_acros.patch
The HTML parser used by Sightly to process templates is parsing incorrectly
comments that span across it's internal char buffer size. Right now the
buffer is set to 2048 characters, making the problem hard to see.
The problem can be exposed by lowering the buffer size to 10 and feeding a
string such as {code:java}test test !--/*comment*/--{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: [Sightly] provide access to the Script Resource Resolver in RenderContext
Hi Am 23.01.2015 um 15:11 schrieb Rob Ryan rr...@adobe.com: I share Felix's concern. If the ServletResolver's resolver is passed around, please ensure it is a service user with minimal permissions required for ServletResolver's needs. That’s a good point: This resource resolver should really be limited to only have read-only access to the locations the ServletResolver is expected to read scripts from … We do *not* want to allow a resolver passed around from the ServletResolver to be abused for accessing general content. If Slightly RuntimeExtensions need more access than the ServletResolver they should manage a resolver themselves. Also, this sounds like premature optimization. If ResourceResolver creation is slow the ROI on making it faster is likely significant as multi-thread usage of a session in Oak degrades performance rapidly. From some measurements I have done a few months back on Oak creating a session comes with quite some penalty. Regards Felix -Rob -Original Message- From: Felix Meschberger [mailto:fmesc...@adobe.com] Sent: Friday, January 23, 2015 5:58 AM To: dev@sling.apache.org Subject: Re: [Sightly] provide access to the Script Resource Resolver in RenderContext Hi I am a bit hesitant with shipping ResourceResolver instances around. But since this is for an extension of the scripting language, this might make sense. We just have to properly document that this is not the request processing ResourceResolver but the ServletResolver’s ResourceResolver which is only intended to be used for script resolution tasks. Regards Felix Am 22.01.2015 um 14:21 schrieb Radu Cotescu r...@apache.org: Hi, There are cases when Sightly RuntimeExtensions might need to access the repository. Since creating multiple ResourceResolvers is not a cheap operation, especially with Jackrabbit, wouldn't it be better to enhance the RenderContext to make it provide the ResourceResolver available in the ScriptContext? This ResourceResolver is already used by the Sightly engine for script rendering, so IMO it could also be passed down to RuntimeExtensions: final ResourceResolver scriptResourceResolver = (ResourceResolver) scriptContext.getAttribute(SlingScriptConstants.ATTR_SCRIPT_RESOURCE_R ESOLVER, SlingScriptConstants.SLING_SCOPE); // line 78 of org.apache.sling.scripting.sightly.impl.engine.SightlyScriptEngine WDYT? Cheers, Radu
Re: [discussion] allow Script Engines to also render components based on paths
FWIW, I think it would be more natural to set this on the container node, so if you have /apps/foo/bar/something.html, I'd set /apps/foo/bar@sling:script = html:thymeleaf. We could, however, support both per-script and per-container settings, but I don't think it is necessary to go more than one level up. Regards, Justin On Fri, Jan 23, 2015 at 9:18 AM, Felix Meschberger fmesc...@adobe.com wrote: Reminds me of the Mac Resource Forks … :-) It would be neat to be able to set this in/on the script itself without having to manage some out-of-band metadata. Regards Felix Am 23.01.2015 um 15:15 schrieb Carsten Ziegeler cziege...@apache.org: What about adding an additional property to the script resource? Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: [discussion] allow Script Engines to also render components based on paths
On Fri, Jan 23, 2015 at 7:45 PM, Carsten Ziegeler cziege...@apache.org wrote: What about adding an additional property to the script resource? +1. This looks more safer and less disrupting as reading the property is cheaper. The script header approach looks nice but would require changes at quite a few places Chetan Mehrotra
Re: [discussion] allow Script Engines to also render components based on paths
On Fri, Jan 23, 2015 at 4:21 PM, Chetan Mehrotra chetan.mehro...@gmail.com wrote: +1. This looks more safer and less disrupting as reading the property is cheaper. But we'd need a mixin, as scripts are usually nt:file nodes. Right?
[jira] [Commented] (SLING-4337) Sightly should only log errors from use providers if none of the use providers succeeded
[ https://issues.apache.org/jira/browse/SLING-4337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14289353#comment-14289353 ] Justin Edelson commented on SLING-4337: --- Proposed patch: https://codereview.appspot.com/192520043 [~radu.cotescu] please take a look when you have a chance Sightly should only log errors from use providers if none of the use providers succeeded Key: SLING-4337 URL: https://issues.apache.org/jira/browse/SLING-4337 Project: Sling Issue Type: Bug Components: Scripting Reporter: Justin Edelson Fix For: Scripting Sightly Engine 1.0.0 While iterating through the use providers, it is possible that one with fail and a later one will succeed. In this case, it doesn't make sense to log the failure from the first case. However, this is exactly what happens now with the PojoUseProvider which logs an error if a class can't be instantiated. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [discussion] allow Script Engines to also render components based on paths
On Fri, Jan 23, 2015 at 3:41 PM, Chetan Mehrotra chetan.mehro...@gmail.com wrote: On Fri, Jan 23, 2015 at 7:59 PM, Radu Cotescu r...@apache.org wrote: But we'd need a mixin, as scripts are usually nt:file nodes. Right? ...Other way would be to leverage the jcr:mimeType on the child jcr:content node which are mostly of type nt:resource... But setting any of those is not convenient when you're editing scripts via WebDAV for example. I much prefer the suggestion to set a property higher in tree, so for example setting /apps/foo@sling:script = html:thymeleaf. Causes the html extension to be mapped to the thymeleaf engine for any script found under there. That looks efficient, simple to manage, we'd just need to complain loudly including a pointer to that feature if two script engines are configured with the same extension and this is not set. -Bertrand
[jira] [Commented] (SLING-4258) JSON representation of Calendar values should preserve timezone
[ https://issues.apache.org/jira/browse/SLING-4258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14289328#comment-14289328 ] Bertrand Delacretaz commented on SLING-4258: I should be able to apply the patch later today. I think we must be careful to preserve backwards compatibility, so any additional changes should be covered by tests that demonstrate the current behavior first and might then change to show the exact differences with the new behavior. JSON representation of Calendar values should preserve timezone --- Key: SLING-4258 URL: https://issues.apache.org/jira/browse/SLING-4258 Project: Sling Issue Type: Improvement Components: Commons Affects Versions: Commons JSON 2.0.10 Reporter: santiago garcía pimentel Assignee: Bertrand Delacretaz Priority: Minor Fix For: Commons JSON 2.0.12 Attachments: SLING-4258.patch Im currently doing some things with dates in Sling that involve timezones and I find that the documentation regarding it is not particularly clear. according to https://sling.apache.org/documentation/bundles/manipulating-content-the-slingpostservlet-servlets-post.html#date-properties several formats are defined. I found that the only format that saves a provided timezone is the ISO8601 format, rest of them relies in a Date object, which does not have timezones. Could this be clearly stated? Also, the ISO8601 parser is problematic. It relies on the Jackrabbit parser which uses format ±-MM-DDThh:mm:ss.SSSTZD, but according to http://www.w3.org/TR/NOTE-datetime the ISO format does not have milliseconds on it (SSS). So it is very hard to find a way to keep the timezone information (I had to dig through the code to figure it out) Could we please replace ISO8601 with the actual format ±-MM-DDThh:mm:ss.SSSTZD so it is clearer? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: sling-trunk buildbot CI build causing problems
Hi, On Fri, Jan 23, 2015 at 2:23 PM, Robert Munteanu romb...@apache.org wrote: ...I'm wondering if we still need the buildbot setup as the Jenkins builds seem to be (mostly) stable these days Right, I agree that we could remove the buildbot setup for now. -Bertrand
Re: [discussion] allow Script Engines to also render components based on paths
Hi, Isn't it possible to have some form of configuration that allows to register scripting languages based on paths when needed? E.g. by default we could following config: *.jsp = JSP engine *.html = Thymeleaf engine And then by path we could override: *.html in /foo = Sightly engine It would be great if only the default values would be global, and one can apply something like mixin to the /foo path to make everything below it to use Sightly instead of Thymeleaf. I doubt that many projects will mix different HTML template languages to a point where we need to control it on a file level. The reason I'd like to avoid this is that it would make it a pain when serializing/synchronizing the repository content to a file system, as it would create an additional folder structure for each file-level mixin or jcr:mimeType. This structure would then have to be manually created for each newly created template file... I have the impression that not allowing to mix different HTML template languages within the same folder would be an acceptable limitation. I also would like to avoid to have a marker in the template to identify the script engine to use, as it would mess with the HTML/XML validity, having to read the 200 chars, which can be confusing if the marker doesn't have to be (and sometimes really shouldn't be) on the first line. Best, Gabriel
[jira] [Assigned] (SLING-3440) Clarify script resolution documentation with regard to selectors
[ https://issues.apache.org/jira/browse/SLING-3440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus reassigned SLING-3440: -- Assignee: Konrad Windszus Clarify script resolution documentation with regard to selectors Key: SLING-3440 URL: https://issues.apache.org/jira/browse/SLING-3440 Project: Sling Issue Type: Improvement Components: Documentation Reporter: Konrad Windszus Assignee: Konrad Windszus The documentation around URL to Script Resolution [1] is very good, except for three points. a) The resourceType given in the example is confusing. Rather than sling:sample, please make that sling/sample. Maybe you could add a hint, that if no resourceType is given, the fallback is to use the primary node type. b) You should explicitly mention that the order of selectors is relevant. c) You should mention that if less selectors are given in the script name than are given in the request, the selectors given in the script name must be the first selectors from the request (to be a potential match). Maybe an example would be good i.e. script name is print/a4.esp and the request is 1) some resource.print.a4.unspecifiedselector.html (matches) 2) some resource.unspecifiedselector.print.a4.html (does not match) [1] - http://sling.apache.org/documentation/the-sling-engine/url-to-script-resolution.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4340) SLING-4247 created odd side-effects
[ https://issues.apache.org/jira/browse/SLING-4340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14289334#comment-14289334 ] Carsten Ziegeler commented on SLING-4340: - I think we should come to a conclusion here, we have four options: - leave it as is which is a special handling that needs to be explained - pick the highest resource and use that RT - pick the lowest resource and use that RT - do something different SLING-4247 created odd side-effects --- Key: SLING-4340 URL: https://issues.apache.org/jira/browse/SLING-4340 Project: Sling Issue Type: Bug Reporter: Justin Edelson Assignee: Justin Edelson Fix For: Resource Merger 1.2.4 The change made in SLING-4247 created an unfortunate side effect for this scenario: /apps/a/1/a - nt:unstructured node, no sling:resourceType property /apps/a/2/a - sling:resourceType set to foo/bar /apps/a/1 has sling:resourceSuperType set to /apps/a/2 Then resourceResolver.getResource(/mnt/override/apps/a/1/a).getResourceType() will be nt:unstructured This strikes me as wrong. And in fact screws up what is for me the main usage of this feature because it shouldn't be necessary to set the sling:resourceType all the time. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: sling-trunk buildbot CI build causing problems
Hi Mark, On Fri, Jan 23, 2015 at 12:03 AM, Mark Thomas ma...@apache.org wrote: ...However, please could you take a look at the buildbot configuration for this build and figure out a) why this happened and b) how to stop it happening again For now, feel free to disable those jobs while we discuss a solution within the Sling team. -Bertrand
[jira] [Commented] (SLING-3440) Clarify script resolution documentation with regard to selectors
[ https://issues.apache.org/jira/browse/SLING-3440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14289452#comment-14289452 ] Konrad Windszus commented on SLING-3440: I extended the documentation in r1654253. I also extended the example to include some non-matching scripts. Clarify script resolution documentation with regard to selectors Key: SLING-3440 URL: https://issues.apache.org/jira/browse/SLING-3440 Project: Sling Issue Type: Improvement Components: Documentation Reporter: Konrad Windszus Assignee: Konrad Windszus The documentation around URL to Script Resolution [1] is very good, except for three points. a) The resourceType given in the example is confusing. Rather than sling:sample, please make that sling/sample. Maybe you could add a hint, that if no resourceType is given, the fallback is to use the primary node type. b) You should explicitly mention that the order of selectors is relevant. c) You should mention that if less selectors are given in the script name than are given in the request, the selectors given in the script name must be the first selectors from the request (to be a potential match). Maybe an example would be good i.e. script name is print/a4.esp and the request is 1) some resource.print.a4.unspecifiedselector.html (matches) 2) some resource.unspecifiedselector.print.a4.html (does not match) [1] - http://sling.apache.org/documentation/the-sling-engine/url-to-script-resolution.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [Sightly] provide access to the Script Resource Resolver in RenderContext
Hi Rob, The RuntimeExtensions are meant to process the outcome of a Sightly expression. If such an extension would need to perform some processing based on component resolution it's fair to pass it the same resolver that the ServletResolver used. I'll document in the RenderContext that this resolver should only be used for component resolution, explicitly specifying that for content resolution the request's resolver (available from the RenderContext#getBindings) should be used. An extension can be called multiple times during the rendering of the same page; if this extension would be called 20 times for the rendering of one page and if the extension needs a resource resolver to handle its processing, I'd *really* like to avoid creating 20 resource resolvers if I could just use the ServletResolver RR, which is passed down anyways to script engines, through the ScriptContext. Regards, Radu On Fri, Jan 23, 2015 at 4:11 PM, Rob Ryan rr...@adobe.com wrote: We do *not* want to allow a resolver passed around from the ServletResolver to be abused for accessing general content. If Slightly RuntimeExtensions need more access than the ServletResolver they should manage a resolver themselves. Also, this sounds like premature optimization. If ResourceResolver creation is slow the ROI on making it faster is likely significant as multi-thread usage of a session in Oak degrades performance rapidly.
Re: [discussion] allow Script Engines to also render components based on paths
On Fri, Jan 23, 2015 at 4:41 PM, Chetan Mehrotra chetan.mehro...@gmail.com wrote: Other way would be to leverage the jcr:mimeType on the child jcr:content node which are mostly of type nt:resource. text/thymeleaf, text/sightly, text/jsp...? :)
[jira] [Comment Edited] (SLING-4342) [Sightly] Reduce the number of repository reads
[
https://issues.apache.org/jira/browse/SLING-4342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14287633#comment-14287633
]
Radu Cotescu edited comment on SLING-4342 at 1/23/15 12:40 PM:
---
The attached patch ([^SLING-4342.patch]) provides the following improvements:
* reduces the number of repository reads by optimising the
{{SightlyJavaCompilerService}} and {{UnitLoader}}
* enhances documentation for {{UnitChangeMonitor}}
* removes useless {{SightlyRenderException}}
was (Author: radu.cotescu):
The attached patch ([^SLING-4342.patch]) provides the following improvements:
* reduces the number of repository reads by optimising the
{{SIghtlyJavaCompilerService}} and {{UnitLoader}}
* enhances documentation for {{UnitChangeMonitor}}
* removes useless {{SightlyRenderException}}
[Sightly] Reduce the number of repository reads
---
Key: SLING-4342
URL: https://issues.apache.org/jira/browse/SLING-4342
Project: Sling
Issue Type: Improvement
Components: Scripting
Reporter: Radu Cotescu
Fix For: Scripting Sightly Engine 1.0.0
Attachments: SLING-4342.patch
On instances that still use Jackrabbit, repository read operations can become
problematic if the system is exposed to a high number of requests. Therefore
the Sightly Scripting engine should be optimised to reduce the number of
repository reads as much as possible.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (SLING-3440) Clarify script resolution documentation with regard to selectors
[ https://issues.apache.org/jira/browse/SLING-3440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus resolved SLING-3440. Resolution: Fixed Clarify script resolution documentation with regard to selectors Key: SLING-3440 URL: https://issues.apache.org/jira/browse/SLING-3440 Project: Sling Issue Type: Improvement Components: Documentation Reporter: Konrad Windszus Assignee: Konrad Windszus The documentation around URL to Script Resolution [1] is very good, except for three points. a) The resourceType given in the example is confusing. Rather than sling:sample, please make that sling/sample. Maybe you could add a hint, that if no resourceType is given, the fallback is to use the primary node type. b) You should explicitly mention that the order of selectors is relevant. c) You should mention that if less selectors are given in the script name than are given in the request, the selectors given in the script name must be the first selectors from the request (to be a potential match). Maybe an example would be good i.e. script name is print/a4.esp and the request is 1) some resource.print.a4.unspecifiedselector.html (matches) 2) some resource.unspecifiedselector.print.a4.html (does not match) [1] - http://sling.apache.org/documentation/the-sling-engine/url-to-script-resolution.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
