[jira] [Commented] (SLING-7476) XSSAPI.filterHTML() fails if source > 200k
[
https://issues.apache.org/jira/browse/SLING-7476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16355621#comment-16355621
]
Tobias Bocanegra commented on SLING-7476:
-
well, this is a limitation of the underlying library, which can't be configured
via OSGi config.
I'm ok with that, since it's insane to have such long strings :-)
but the error is a bit misleading. I would expect:
- either an IllegalArgumentException that explains why it fails
- or better, the text being truncated to the limit.
> XSSAPI.filterHTML() fails if source > 200k
> --
>
> Key: SLING-7476
> URL: https://issues.apache.org/jira/browse/SLING-7476
> Project: Sling
> Issue Type: Bug
> Components: XSS Protection API
>Affects Versions: XSS Protection API 2.0.4
>Reporter: Tobias Bocanegra
>Priority: Major
>
> when filtering a source that is larger than 200k, the xss api fails with:
> {noformat}
> java.lang.RuntimeException: Unable to scan input
> at
> org.apache.sling.xss.impl.HtmlToHtmlContentContext.filter(HtmlToHtmlContentContext.java:73)
> at
> org.apache.sling.xss.impl.XSSFilterImpl.filter(XSSFilterImpl.java:190)
> at
> org.apache.sling.xss.impl.XSSFilterImpl.filter(XSSFilterImpl.java:123)
> at org.apache.sling.xss.impl.XSSAPIImpl.filterHTML(XSSAPIImpl.java:466)
> at
> org.apache.sling.xss.impl.XSSAPIImplTest.testFilterLargeHTML(XSSAPIImplTest.java:223)
> {noformat}
> Test:
> {code}
> @Test
> public void testFilterLargeHTML() {
> final int SIZE = 21;
> StringBuilder b = new StringBuilder(SIZE);
> while (b.length() < SIZE) {
> b.append("Lorem ipsum dolor sit amet, consectetur adipiscing
> elit. Donec at enim et dui egestas accumsan amet.");
> }
> String source = b.toString();
> TestCase.assertEquals("Filtering large source", source,
> xssAPI.filterHTML(source));
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (SLING-7476) XSSAPI.filterHTML() fails if source > 200k
Tobias Bocanegra created SLING-7476:
---
Summary: XSSAPI.filterHTML() fails if source > 200k
Key: SLING-7476
URL: https://issues.apache.org/jira/browse/SLING-7476
Project: Sling
Issue Type: Bug
Components: XSS Protection API
Affects Versions: XSS Protection API 2.0.4
Reporter: Tobias Bocanegra
when filtering a source that is larger than 200k, the xss api fails with:
{noformat}
java.lang.RuntimeException: Unable to scan input
at
org.apache.sling.xss.impl.HtmlToHtmlContentContext.filter(HtmlToHtmlContentContext.java:73)
at
org.apache.sling.xss.impl.XSSFilterImpl.filter(XSSFilterImpl.java:190)
at
org.apache.sling.xss.impl.XSSFilterImpl.filter(XSSFilterImpl.java:123)
at org.apache.sling.xss.impl.XSSAPIImpl.filterHTML(XSSAPIImpl.java:466)
at
org.apache.sling.xss.impl.XSSAPIImplTest.testFilterLargeHTML(XSSAPIImplTest.java:223)
{noformat}
Test:
{code}
@Test
public void testFilterLargeHTML() {
final int SIZE = 21;
StringBuilder b = new StringBuilder(SIZE);
while (b.length() < SIZE) {
b.append("Lorem ipsum dolor sit amet, consectetur adipiscing elit.
Donec at enim et dui egestas accumsan amet.");
}
String source = b.toString();
TestCase.assertEquals("Filtering large source", source,
xssAPI.filterHTML(source));
}
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SLING-7155) htl-maven-plugin: Add option to precompile the HTL scripts
[
https://issues.apache.org/jira/browse/SLING-7155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16212006#comment-16212006
]
Tobias Bocanegra commented on SLING-7155:
-
thanks. works like a charm!
> htl-maven-plugin: Add option to precompile the HTL scripts
> --
>
> Key: SLING-7155
> URL: https://issues.apache.org/jira/browse/SLING-7155
> Project: Sling
> Issue Type: Improvement
> Components: Maven Plugins and Archetypes
>Affects Versions: HTL Maven Plugin 1.0.8
>Reporter: Tobias Bocanegra
>Assignee: Radu Cotescu
> Fix For: HTL Maven Plugin 1.1.0
>
>
> It would be cool if the HTL Maven Plugin could precompile the HTL scripts,
> similar to the JSPC plugin.
> This would have the following advantages:
> * the project needs to specify all the (compile time) dependencies the
> scripts needs; this makes the project more robust and changes in dependencies
> are easier detectable;
> * the compiled classes could be used as source to generate the import-package
> statements for the {{filevault-package-maven-plugin}}.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (SLING-7155) htl-maven-plugin: Add option to precompile the HTL scripts
[
https://issues.apache.org/jira/browse/SLING-7155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16210402#comment-16210402
]
Tobias Bocanegra commented on SLING-7155:
-
[~radu.cotescu] cool, thanks!
it has one flaw, though: the use classes are not used as class references in
the java but via reflection, which causes them to be removed from the compiled
class file.
eg:
html script:
{code}
{code}
generated java:
{code}
import com.day.cq.wcm.foundation.model.responsivegrid.ResponsiveGrid;
import com.adobe.cq.wcm.core.components.models.form.Container;
...
public final class container_html extends RenderUnit {
...
_global_container = renderContext.call("use",
"com.adobe.cq.wcm.core.components.models.form.Container", obj());
_global_grid = renderContext.call("use",
"com.day.cq.wcm.foundation.model.responsivegrid.ResponsiveGrid", obj());
{code}
but the class {{com.adobe.cq.wcm.core.components.models.form.Container}} is
never referenced as such in the code, so it is not visible in the class file
and not detected as dependency by the class scanner.
ideally, the htl compiler should do something like:
{code}
_global_container = renderContext.call("use",
com.adobe.cq.wcm.core.components.models.form.Container.class.getName(), obj());
{code}
or the {{renderContext}} also offers a signature with the class instead of just
the string, eg:
{code}
_global_container = renderContext.call("use",
com.adobe.cq.wcm.core.components.models.form.Container.class, obj());
{code}
WDYT?
> htl-maven-plugin: Add option to precompile the HTL scripts
> --
>
> Key: SLING-7155
> URL: https://issues.apache.org/jira/browse/SLING-7155
> Project: Sling
> Issue Type: Improvement
> Components: Maven Plugins and Archetypes
>Affects Versions: HTL Maven Plugin 1.0.8
>Reporter: Tobias Bocanegra
>Assignee: Radu Cotescu
>
> It would be cool if the HTL Maven Plugin could precompile the HTL scripts,
> similar to the JSPC plugin.
> This would have the following advantages:
> * the project needs to specify all the (compile time) dependencies the
> scripts needs; this makes the project more robust and changes in dependencies
> are easier detectable;
> * the compiled classes could be used as source to generate the import-package
> statements for the {{filevault-package-maven-plugin}}.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (SLING-7155) htl-maven-plugin: Add option to precompile the HTL scripts
[
https://issues.apache.org/jira/browse/SLING-7155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16182330#comment-16182330
]
Tobias Bocanegra commented on SLING-7155:
-
bq. Ok, but as mentioned before, precompiling the classes is useless for Sling
but couldn't it generate a bundle that contains a servlet that executes the
compiled classes? this way you would have robust, precompiled, immutable
scripts.
bq. what about if the plugin would just transpile HTL to Java and add these
Java classes to the list of source folders for the project?
that would be ideal. java source code or java classes. both ok.
> htl-maven-plugin: Add option to precompile the HTL scripts
> --
>
> Key: SLING-7155
> URL: https://issues.apache.org/jira/browse/SLING-7155
> Project: Sling
> Issue Type: Improvement
> Components: Maven Plugins and Archetypes
>Affects Versions: HTL Maven Plugin 1.0.8
>Reporter: Tobias Bocanegra
>
> It would be cool if the HTL Maven Plugin could precompile the HTL scripts,
> similar to the JSPC plugin.
> This would have the following advantages:
> * the project needs to specify all the (compile time) dependencies the
> scripts needs; this makes the project more robust and changes in dependencies
> are easier detectable;
> * the compiled classes could be used as source to generate the import-package
> statements for the {{filevault-package-maven-plugin}}.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (SLING-7155) htl-maven-plugin: Add option to precompile the HTL scripts
[
https://issues.apache.org/jira/browse/SLING-7155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16182316#comment-16182316
]
Tobias Bocanegra commented on SLING-7155:
-
one use case could be to pre-compile the scripts, so that they don't need to be
recompiled during runtime. and as I said above, it would improve the robustness
of the validation. e.g. detect typos in the use class references, or changes in
the dependencies.
> htl-maven-plugin: Add option to precompile the HTL scripts
> --
>
> Key: SLING-7155
> URL: https://issues.apache.org/jira/browse/SLING-7155
> Project: Sling
> Issue Type: Improvement
> Components: Maven Plugins and Archetypes
>Affects Versions: HTL Maven Plugin 1.0.8
>Reporter: Tobias Bocanegra
>
> It would be cool if the HTL Maven Plugin could precompile the HTL scripts,
> similar to the JSPC plugin.
> This would have the following advantages:
> * the project needs to specify all the (compile time) dependencies the
> scripts needs; this makes the project more robust and changes in dependencies
> are easier detectable;
> * the compiled classes could be used as source to generate the import-package
> statements for the {{filevault-package-maven-plugin}}.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (SLING-7155) htl-maven-plugin: Add option to precompile the HTL scripts
Tobias Bocanegra created SLING-7155: --- Summary: htl-maven-plugin: Add option to precompile the HTL scripts Key: SLING-7155 URL: https://issues.apache.org/jira/browse/SLING-7155 Project: Sling Issue Type: Improvement Components: Maven Plugins and Archetypes Reporter: Tobias Bocanegra it would be cool, if the htl plugin could precompile the HTL scripts, similar to the JSPC plugin. this would have the following advantages: - the project needs to specify all the (compile time) dependencies the scripts needs. this makes the project more robust and changes in dependencies are easier detectable. - the compiled classes could be used as source to generate the import-package statements for the filevault-package-maven-plugin. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (SLING-6423) Allow for specifying ACL merge mode (ACHandling) in repoinit
[ https://issues.apache.org/jira/browse/SLING-6423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16140024#comment-16140024 ] Tobias Bocanegra commented on SLING-6423: - IIRC, the filevault merge also applies the ACE declarations on existing nodes. and IIUC, in the repoinit, the same must happen; i.e. the repo init defines the changed ACEs that should be applied to nodes. > Allow for specifying ACL merge mode (ACHandling) in repoinit > > > Key: SLING-6423 > URL: https://issues.apache.org/jira/browse/SLING-6423 > Project: Sling > Issue Type: New Feature > Components: Repoinit >Reporter: Nitin Nizhawan >Assignee: Timothee Maret > Fix For: Repoinit Parser 1.1.2 > > Attachments: SLING-6423_parser_changes.patch, > SLING-6423_testcases.patch, SLING_6423_testcasesV2.patch > > > Repoinit by default just add new ACLs if they are not already present. > By contract package manager provides various strategies for ACL merging > Extend repoinit to allow specifying these strategies > https://jackrabbit.apache.org/filevault/apidocs/org/apache/jackrabbit/vault/fs/io/AccessControlHandling.html#MERGE -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (SLING-6982) JSPC plugin should support additional resource roots
[
https://issues.apache.org/jira/browse/SLING-6982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16069270#comment-16069270
]
Tobias Bocanegra commented on SLING-6982:
-
thanks!
> JSPC plugin should support additional resource roots
>
>
> Key: SLING-6982
> URL: https://issues.apache.org/jira/browse/SLING-6982
> Project: Sling
> Issue Type: Improvement
> Components: Maven Plugins and Archetypes
>Affects Versions: Maven JSPC Plugin 2.1.0
>Reporter: Tobias Bocanegra
>Assignee: Karl Pauls
> Fix For: Maven JSPC Plugin 2.1.2
>
>
> When trying to compile JSPs that have includes to dependent resources, it is
> not possible to compile them. you can't put the includes into the same
> sources, otherwise they will also be compiled.
> suggestion:
> - create new property: {{resourceDirectories}} that is used during resource
> lookup.
> example:
> {noformat}
>
> maven-dependency-plugin
>
>
> extract-deps
> generate-sources
>
> unpack-dependencies
>
>
>
> cq-foundation-content
> zip
> true
>
> ${project.build.directory}/dependencies
>
>
>
>
>
>
> org.apache.sling
> jspc-maven-plugin
> 2.1.1-SNAPSHOT
>
>
> ${project.basedir}/jcr_root
>
>
> ${project.build.directory}/dependencies/jcr_root
>
> false
> false
> 1.8
> 1.8
>
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (SLING-6982) JSPC plugin should support additional resource roots
[
https://issues.apache.org/jira/browse/SLING-6982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16062557#comment-16062557
]
Tobias Bocanegra commented on SLING-6982:
-
patch: https://github.com/apache/sling/pull/244
> JSPC plugin should support additional resource roots
>
>
> Key: SLING-6982
> URL: https://issues.apache.org/jira/browse/SLING-6982
> Project: Sling
> Issue Type: Improvement
> Components: Maven Plugins and Archetypes
>Affects Versions: Maven JSPC Plugin 2.1.0
>Reporter: Tobias Bocanegra
> Fix For: Maven JSPC Plugin 2.1.2
>
>
> When trying to compile JSPs that have includes to dependent resources, it is
> not possible to compile them. you can't put the includes into the same
> sources, otherwise they will also be compiled.
> suggestion:
> - create new property: {{resourceDirectories}} that is used during resource
> lookup.
> example:
> {noformat}
>
> maven-dependency-plugin
>
>
> extract-deps
> generate-sources
>
> unpack-dependencies
>
>
>
> cq-foundation-content
> zip
> true
>
> ${project.build.directory}/dependencies
>
>
>
>
>
>
> org.apache.sling
> jspc-maven-plugin
> 2.1.1-SNAPSHOT
>
>
> ${project.basedir}/jcr_root
>
>
> ${project.build.directory}/dependencies/jcr_root
>
> false
> false
> 1.8
> 1.8
>
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (SLING-6982) JSPC plugin should support additional resource roots
Tobias Bocanegra created SLING-6982:
---
Summary: JSPC plugin should support additional resource roots
Key: SLING-6982
URL: https://issues.apache.org/jira/browse/SLING-6982
Project: Sling
Issue Type: Improvement
Components: Maven Plugins and Archetypes
Affects Versions: Maven JSPC Plugin 2.1.0
Reporter: Tobias Bocanegra
Fix For: Maven JSPC Plugin 2.1.2
When trying to compile JSPs that have includes to dependent resources, it is
not possible to compile them. you can't put the includes into the same sources,
otherwise they will also be compiled.
suggestion:
- create new property: {{resourceDirectories}} that is used during resource
lookup.
example:
{noformat}
maven-dependency-plugin
extract-deps
generate-sources
unpack-dependencies
cq-foundation-content
zip
true
${project.build.directory}/dependencies
org.apache.sling
jspc-maven-plugin
2.1.1-SNAPSHOT
${project.basedir}/jcr_root
${project.build.directory}/dependencies/jcr_root
false
false
1.8
1.8
{noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (SLING-6940) JSPC plugin violates Maven naming convention
[
https://issues.apache.org/jira/browse/SLING-6940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16050529#comment-16050529
]
Tobias Bocanegra commented on SLING-6940:
-
new maven coordinates:
{noformat}
org.apache.sling
jspc-maven-plugin
2.1.0
{noformat}
> JSPC plugin violates Maven naming convention
>
>
> Key: SLING-6940
> URL: https://issues.apache.org/jira/browse/SLING-6940
> Project: Sling
> Issue Type: Bug
> Components: Maven Plugins and Archetypes
>Affects Versions: Maven JSPC Plugin 2.0.8
>Reporter: Tobias Bocanegra
>Assignee: Carsten Ziegeler
> Fix For: Maven JSPC Plugin 2.1.0
>
>
> the current plugin name {{maven-jspc-plugin}} violates the maven plugin
> convention, as it starts with "maven-":
> {noformat}
> [INFO] --- maven-plugin-plugin:3.4:helpmojo (help-goal) @ maven-jspc-plugin
> ---
> [ERROR]
> Artifact Ids of the format maven-___-plugin are reserved for
> plugins in the Group Id org.apache.maven.plugins
> Please change your artifactId to the format ___-maven-plugin
> In the future this error will break the build.
> {noformat}
> Suggest to rename it to: {{sling-jspc-maven-plugin}}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (SLING-6940) JSPC plugin violates Maven naming convention
Tobias Bocanegra created SLING-6940:
---
Summary: JSPC plugin violates Maven naming convention
Key: SLING-6940
URL: https://issues.apache.org/jira/browse/SLING-6940
Project: Sling
Issue Type: Bug
Components: Maven Plugins and Archetypes
Affects Versions: Maven JSPC Plugin 2.0.8
Reporter: Tobias Bocanegra
the current plugin name {{maven-jspc-plugin}} violates the maven plugin
convention, as it starts with "maven-":
{noformat}
[INFO] --- maven-plugin-plugin:3.4:helpmojo (help-goal) @ maven-jspc-plugin ---
[ERROR]
Artifact Ids of the format maven-___-plugin are reserved for
plugins in the Group Id org.apache.maven.plugins
Please change your artifactId to the format ___-maven-plugin
In the future this error will break the build.
{noformat}
Suggest to rename it to: {{sling-jspc-maven-plugin}}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (SLING-5763) ClassFormatException when using java 8 lambda expressions
[
https://issues.apache.org/jira/browse/SLING-5763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16040050#comment-16040050
]
Tobias Bocanegra commented on SLING-5763:
-
[~bobi] I fixed SLING-6923. can you test again if it now works with the latest
changes?
> ClassFormatException when using java 8 lambda expressions
> -
>
> Key: SLING-5763
> URL: https://issues.apache.org/jira/browse/SLING-5763
> Project: Sling
> Issue Type: Bug
> Components: Maven Plugins and Archetypes
>Affects Versions: Maven JSPC Plugin 2.0.8
>Reporter: Andrey Bardashevsky
>
> When i try to jsp:useBean with Java 8 lambda expression jspc plugin throws
> following exception:
> {code}
> org.eclipse.jdt.internal.compiler.classfmt.ClassFormatException
> at
> org.eclipse.jdt.internal.compiler.classfmt.ClassFileReader.(ClassFileReader.java:329)
> at
> org.apache.sling.scripting.jsp.jasper.compiler.JDTCompiler$1.findType(JDTCompiler.java:204)
> at
> org.apache.sling.scripting.jsp.jasper.compiler.JDTCompiler$1.findType(JDTCompiler.java:176)
> at
> org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:123)
> at
> org.eclipse.jdt.internal.compiler.lookup.PackageBinding.getTypeOrPackage(PackageBinding.java:178)
> at
> org.eclipse.jdt.internal.compiler.lookup.Scope.getPackage(Scope.java:2046)
> at
> org.eclipse.jdt.internal.compiler.ast.QualifiedTypeReference.getTypeBinding(QualifiedTypeReference.java:69)
> at
> org.eclipse.jdt.internal.compiler.ast.TypeReference.resolveType(TypeReference.java:130)
> at
> org.eclipse.jdt.internal.compiler.ast.LocalDeclaration.resolve(LocalDeclaration.java:138)
> at
> org.eclipse.jdt.internal.compiler.ast.Block.resolveUsing(Block.java:115)
> at
> org.eclipse.jdt.internal.compiler.ast.TryStatement.resolve(TryStatement.java:751)
> at
> org.eclipse.jdt.internal.compiler.ast.AbstractMethodDeclaration.resolveStatements(AbstractMethodDeclaration.java:432)
> at
> org.eclipse.jdt.internal.compiler.ast.MethodDeclaration.resolveStatements(MethodDeclaration.java:190)
> at
> org.eclipse.jdt.internal.compiler.ast.AbstractMethodDeclaration.resolve(AbstractMethodDeclaration.java:403)
> at
> org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.resolve(TypeDeclaration.java:1047)
> at
> org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.resolve(TypeDeclaration.java:1094)
> at
> org.eclipse.jdt.internal.compiler.ast.CompilationUnitDeclaration.resolve(CompilationUnitDeclaration.java:353)
> at org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:596)
> at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:411)
> at
> org.apache.sling.scripting.jsp.jasper.compiler.JDTCompiler.generateClass(JDTCompiler.java:410)
> at
> org.apache.sling.scripting.jsp.jasper.compiler.Compiler.compile(Compiler.java:313)
> at org.apache.sling.maven.jspc.JspcMojo.processFile(JspcMojo.java:367)
> at
> org.apache.sling.maven.jspc.JspcMojo.executeInternal(JspcMojo.java:321)
> at org.apache.sling.maven.jspc.JspcMojo.execute(JspcMojo.java:240)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
>
[jira] [Issue Comment Deleted] (SLING-6936) JSPC plugin should save compilation report
[ https://issues.apache.org/jira/browse/SLING-6936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tobias Bocanegra updated SLING-6936: Comment: was deleted (was: I will provide a patch...) > JSPC plugin should save compilation report > -- > > Key: SLING-6936 > URL: https://issues.apache.org/jira/browse/SLING-6936 > Project: Sling > Issue Type: Improvement > Components: Maven Plugins and Archetypes >Affects Versions: Maven JSPC Plugin 2.0.8 >Reporter: Tobias Bocanegra > > SLING-6925 introduced a new jsp compilation report that shows which java > packages are used by the JSPs. it would be useful is this report is also > written in machine readable form into a file, so that other scripts can use > use it. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (SLING-6936) JSPC plugin should save compilation report
[ https://issues.apache.org/jira/browse/SLING-6936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16036439#comment-16036439 ] Tobias Bocanegra commented on SLING-6936: - I will provide a patch... > JSPC plugin should save compilation report > -- > > Key: SLING-6936 > URL: https://issues.apache.org/jira/browse/SLING-6936 > Project: Sling > Issue Type: Improvement > Components: Maven Plugins and Archetypes >Affects Versions: Maven JSPC Plugin 2.0.8 >Reporter: Tobias Bocanegra > > SLING-6925 introduced a new jsp compilation report that shows which java > packages are used by the JSPs. it would be useful is this report is also > written in machine readable form into a file, so that other scripts can use > use it. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (SLING-6936) JSPC plugin should save compilation report
Tobias Bocanegra created SLING-6936: --- Summary: JSPC plugin should save compilation report Key: SLING-6936 URL: https://issues.apache.org/jira/browse/SLING-6936 Project: Sling Issue Type: Improvement Components: Maven Plugins and Archetypes Affects Versions: Maven JSPC Plugin 2.0.8 Reporter: Tobias Bocanegra SLING-6925 introduced a new jsp compilation report that shows which java packages are used by the JSPs. it would be useful is this report is also written in machine readable form into a file, so that other scripts can use use it. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (SLING-6925) Make JSPC plugin useful to validation and analysis
[
https://issues.apache.org/jira/browse/SLING-6925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16034391#comment-16034391
]
Tobias Bocanegra commented on SLING-6925:
-
strange... the PR only showed the diff.
[~cziegeler] I updated the PR. now it is "clean"
> Make JSPC plugin useful to validation and analysis
> --
>
> Key: SLING-6925
> URL: https://issues.apache.org/jira/browse/SLING-6925
> Project: Sling
> Issue Type: Improvement
> Components: Maven Plugins and Archetypes
>Affects Versions: Maven JSPC Plugin 2.0.8
>Reporter: Tobias Bocanegra
>Assignee: Carsten Ziegeler
>Priority: Minor
> Fix For: Maven JSPC Plugin 2.0.10
>
>
> the JSPs plugin is very useful to validate the JSPs before they get packaged
> into the artifact. --but the deployment unit might not need to class files
> but there is currently no way to disable their attachment--. further it might
> be valuable to know which dependencies in the project are really used by the
> JSPs. this helps developers to optimize the runtime dependencies of their
> code.
> suggest:
> - --add new flag: {{attachClasses}} (default true)--
> - analyze the java packages of the class path used to compile the JSPs and
> report which dependencies are not used.
> - add new flag: {{reportUnusedDependencies}} (default true)
> - add new flag: {{dumpClassPathUsage}} (default false)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (SLING-6925) Make JSPC plugin useful to validation and analysis
[
https://issues.apache.org/jira/browse/SLING-6925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tobias Bocanegra updated SLING-6925:
Summary: Make JSPC plugin useful to validation and analysis (was: Make
JSPC plugin useful to validation and analysys)
> Make JSPC plugin useful to validation and analysis
> --
>
> Key: SLING-6925
> URL: https://issues.apache.org/jira/browse/SLING-6925
> Project: Sling
> Issue Type: Improvement
> Components: Maven Plugins and Archetypes
>Affects Versions: Maven JSPC Plugin 2.0.8
>Reporter: Tobias Bocanegra
>Assignee: Carsten Ziegeler
>Priority: Minor
> Fix For: Maven JSPC Plugin 2.0.10
>
>
> the JSPs plugin is very useful to validate the JSPs before they get packaged
> into the artifact. --but the deployment unit might not need to class files
> but there is currently no way to disable their attachment--. further it might
> be valuable to know which dependencies in the project are really used by the
> JSPs. this helps developers to optimize the runtime dependencies of their
> code.
> suggest:
> - --add new flag: {{attachClasses}} (default true)--
> - analyze the java packages of the class path used to compile the JSPs and
> report which dependencies are not used.
> - add new flag: {{reportUnusedDependencies}} (default true)
> - add new flag: {{dumpClassPathUsage}} (default false)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (SLING-6923) Update JSPC plugin to support java 1.8
[ https://issues.apache.org/jira/browse/SLING-6923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tobias Bocanegra resolved SLING-6923. - Resolution: Fixed perfect, thanks. I will provide a PR for SLING-6925 shortly > Update JSPC plugin to support java 1.8 > -- > > Key: SLING-6923 > URL: https://issues.apache.org/jira/browse/SLING-6923 > Project: Sling > Issue Type: Improvement > Components: Maven Plugins and Archetypes >Affects Versions: Maven JSPC Plugin 2.0.8 >Reporter: Tobias Bocanegra >Assignee: Carsten Ziegeler > Fix For: Maven JSPC Plugin 2.0.10 > > > The current 2.0.8 version of the JSPC plugin only supports java version 1.6. > task: > - update code of JSPC plugin to also support 1.7 and 1.8 > - use latest org.apache.sling.scripting.jsp:2.3.0 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (SLING-6925) Make JSPC plugin useful to validation and analysys
[
https://issues.apache.org/jira/browse/SLING-6925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16032492#comment-16032492
]
Tobias Bocanegra commented on SLING-6925:
-
work tracked in https://github.com/tripodsan/sling/tree/SLING-6925, waiting for
SLING-6923 to be merged before creating new PR.
> Make JSPC plugin useful to validation and analysys
> --
>
> Key: SLING-6925
> URL: https://issues.apache.org/jira/browse/SLING-6925
> Project: Sling
> Issue Type: Improvement
> Components: Maven Plugins and Archetypes
>Affects Versions: Maven JSPC Plugin 2.0.8
>Reporter: Tobias Bocanegra
>Priority: Minor
>
> the JSPs plugin is very useful to validate the JSPs before they get packaged
> into the artifact. --but the deployment unit might not need to class files
> but there is currently no way to disable their attachment--. further it might
> be valuable to know which dependencies in the project are really used by the
> JSPs. this helps developers to optimize the runtime dependencies of their
> code.
> suggest:
> - --add new flag: {{attachClasses}} (default true)--
> - analyze the java packages of the class path used to compile the JSPs and
> report which dependencies are not used.
> - add new flag: {{reportUnusedDependencies}} (default true)
> - add new flag: {{dumpClassPathUsage}} (default false)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (SLING-6925) Make JSPC plugin useful to validation and analysys
[
https://issues.apache.org/jira/browse/SLING-6925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16032487#comment-16032487
]
Tobias Bocanegra commented on SLING-6925:
-
added new flag: {{printCompilationReport}} which produces a detail report of
what classes were used.
example output:
{noformat}
[INFO] JSP compilation report:
Package Dependency
---
java.io n/a
java.lang n/a
java.util n/a
javax.jcr
javax.jcr:jcr:jar:2.0
javax.jcr.security
javax.jcr:jcr:jar:2.0
javax.servlet
javax.servlet:servlet-api:jar:2.5
javax.servlet.jsp
javax.servlet.jsp:jsp-api:jar:2.1
javax.servlet.jsp.jstl.core
javax.servlet:jstl:jar:1.2
javax.servlet.jsp.tagext
javax.servlet.jsp:jsp-api:jar:2.1
javax.xml.parsers n/a
org.apache.commons.codec.binary
commons-codec:commons-codec:jar:1.10,
org.apache.sling:org.apache.sling.auth.core:jar:1.1.4
org.apache.commons.collections
commons-collections:commons-collections:jar:3.2.2
org.apache.commons.collections.iterators
commons-collections:commons-collections:jar:3.2.2
org.apache.commons.lang
commons-lang:commons-lang:jar:2.5
org.apache.jackrabbit
org.apache.jackrabbit:jackrabbit-jcr-commons:jar:2.3.2
org.apache.jackrabbit.api
org.apache.jackrabbit:jackrabbit-api:jar:2.3.5
org.apache.jackrabbit.api.security.principal
org.apache.jackrabbit:jackrabbit-api:jar:2.3.5
org.apache.jackrabbit.api.security.user
org.apache.jackrabbit:jackrabbit-api:jar:2.3.5
org.apache.jackrabbit.commons.jackrabbit.user
org.apache.jackrabbit:jackrabbit-jcr-commons:jar:2.3.2
org.apache.jackrabbit.util
org.apache.jackrabbit:jackrabbit-jcr-commons:jar:2.3.2
org.apache.sling.api
org.apache.sling:org.apache.sling.api:jar:2.7.0
org.apache.sling.api.resource
org.apache.sling:org.apache.sling.api:jar:2.7.0
org.apache.sling.api.scripting
org.apache.sling:org.apache.sling.api:jar:2.7.0
org.apache.sling.auth.core
org.apache.sling:org.apache.sling.auth.core:jar:1.1.4
org.apache.sling.commons.json
org.apache.sling:org.apache.sling.commons.json:jar:2.0.6
org.apache.sling.commons.json.io
org.apache.sling:org.apache.sling.commons.json:jar:2.0.6
org.apache.sling.featureflags
org.apache.sling:org.apache.sling.featureflags:jar:1.0.0
org.apache.sling.resourcemerger.api
org.apache.sling:org.apache.sling.resourcemerger:jar:1.0.0
org.apache.sling.scripting.jsp.taglib
org.apache.sling:org.apache.sling.scripting.jsp.taglib:jar:2.2.6
org.apache.sling.scripting.jsp.taglib.tei
org.apache.sling:org.apache.sling.scripting.jsp.taglib:jar:2.2.6
org.apache.taglibs.standard.tag.rt.core
javax.servlet:jstl:jar:1.2
org.apache.taglibs.standard.tei
javax.servlet:jstl:jar:1.2
org.apache.taglibs.standard.tlv
javax.servlet:jstl:jar:1.2
org.joda.time
joda-time:joda-time:jar:2.7
org.joda.time.base
joda-time:joda-time:jar:2.7
org.joda.time.format
joda-time:joda-time:jar:2.7
org.osgi.framework
org.osgi:org.osgi.core:jar:5.0.0
org.slf4j
org.slf4j:slf4j-api:jar:1.7.6
org.xml.sax n/a
org.xml.sax.helpers n/a
sun.reflect n/a
7 dependencies not
[jira] [Commented] (SLING-6925) Make JSPC plugin useful to validation and analysys
[
https://issues.apache.org/jira/browse/SLING-6925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16032342#comment-16032342
]
Tobias Bocanegra commented on SLING-6925:
-
silly me, of course we can avoid attachment of the classes by changing the
output directory:
{noformat}
...
${project.build.directory}/jspc-validation-output
...
{noformat}
> Make JSPC plugin useful to validation and analysys
> --
>
> Key: SLING-6925
> URL: https://issues.apache.org/jira/browse/SLING-6925
> Project: Sling
> Issue Type: Improvement
> Components: Maven Plugins and Archetypes
>Affects Versions: Maven JSPC Plugin 2.0.8
>Reporter: Tobias Bocanegra
>Priority: Minor
>
> the JSPs plugin is very useful to validate the JSPs before they get packaged
> into the artifact. but the deployment unit might not need to class files but
> there is currently no way to disable their attachment. further it might be
> valuable to know which dependencies in the project are really used by the
> JSPs. this helps developers to optimize the runtime dependencies of their
> code.
> suggest:
> - add new flag: {{attachClasses}} (default true)
> - analyze the java packages of the class path used to compile the JSPs and
> report which dependencies are not used.
> - add new flag: {{reportUnusedDependencies}} (default true)
> - add new flag: {{dumpClassPathUsage}} (default false)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (SLING-6925) Make JSPC plugin useful to validation and analysys
[
https://issues.apache.org/jira/browse/SLING-6925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tobias Bocanegra updated SLING-6925:
Description:
the JSPs plugin is very useful to validate the JSPs before they get packaged
into the artifact. --but the deployment unit might not need to class files but
there is currently no way to disable their attachment--. further it might be
valuable to know which dependencies in the project are really used by the JSPs.
this helps developers to optimize the runtime dependencies of their code.
suggest:
- --add new flag: {{attachClasses}} (default true)--
- analyze the java packages of the class path used to compile the JSPs and
report which dependencies are not used.
- add new flag: {{reportUnusedDependencies}} (default true)
- add new flag: {{dumpClassPathUsage}} (default false)
was:
the JSPs plugin is very useful to validate the JSPs before they get packaged
into the artifact. but the deployment unit might not need to class files but
there is currently no way to disable their attachment. further it might be
valuable to know which dependencies in the project are really used by the JSPs.
this helps developers to optimize the runtime dependencies of their code.
suggest:
- add new flag: {{attachClasses}} (default true)
- analyze the java packages of the class path used to compile the JSPs and
report which dependencies are not used.
- add new flag: {{reportUnusedDependencies}} (default true)
- add new flag: {{dumpClassPathUsage}} (default false)
> Make JSPC plugin useful to validation and analysys
> --
>
> Key: SLING-6925
> URL: https://issues.apache.org/jira/browse/SLING-6925
> Project: Sling
> Issue Type: Improvement
> Components: Maven Plugins and Archetypes
>Affects Versions: Maven JSPC Plugin 2.0.8
>Reporter: Tobias Bocanegra
>Priority: Minor
>
> the JSPs plugin is very useful to validate the JSPs before they get packaged
> into the artifact. --but the deployment unit might not need to class files
> but there is currently no way to disable their attachment--. further it might
> be valuable to know which dependencies in the project are really used by the
> JSPs. this helps developers to optimize the runtime dependencies of their
> code.
> suggest:
> - --add new flag: {{attachClasses}} (default true)--
> - analyze the java packages of the class path used to compile the JSPs and
> report which dependencies are not used.
> - add new flag: {{reportUnusedDependencies}} (default true)
> - add new flag: {{dumpClassPathUsage}} (default false)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (SLING-6925) Make JSPC plugin useful to validation and analysys
[
https://issues.apache.org/jira/browse/SLING-6925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16032331#comment-16032331
]
Tobias Bocanegra commented on SLING-6925:
-
I will provide a patch
> Make JSPC plugin useful to validation and analysys
> --
>
> Key: SLING-6925
> URL: https://issues.apache.org/jira/browse/SLING-6925
> Project: Sling
> Issue Type: Improvement
> Components: Maven Plugins and Archetypes
>Affects Versions: Maven JSPC Plugin 2.0.8
>Reporter: Tobias Bocanegra
>Priority: Minor
>
> the JSPs plugin is very useful to validate the JSPs before they get packaged
> into the artifact. but the deployment unit might not need to class files but
> there is currently no way to disable their attachment. further it might be
> valuable to know which dependencies in the project are really used by the
> JSPs. this helps developers to optimize the runtime dependencies of their
> code.
> suggest:
> - add new flag: {{attachClasses}} (default true)
> - analyze the java packages of the class path used to compile the JSPs and
> report which dependencies are not used.
> - add new flag: {{reportUnusedDependencies}} (default true)
> - add new flag: {{dumpClassPathUsage}} (default false)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (SLING-6925) Make JSPC plugin useful to validation and analysys
Tobias Bocanegra created SLING-6925:
---
Summary: Make JSPC plugin useful to validation and analysys
Key: SLING-6925
URL: https://issues.apache.org/jira/browse/SLING-6925
Project: Sling
Issue Type: Improvement
Components: Maven Plugins and Archetypes
Affects Versions: Maven JSPC Plugin 2.0.8
Reporter: Tobias Bocanegra
Priority: Minor
the JSPs plugin is very useful to validate the JSPs before they get packaged
into the artifact. but the deployment unit might not need to class files but
there is currently no way to disable their attachment. further it might be
valuable to know which dependencies in the project are really used by the JSPs.
this helps developers to optimize the runtime dependencies of their code.
suggest:
- add new flag: {{attachClasses}} (default true)
- analyze the java packages of the class path used to compile the JSPs and
report which dependencies are not used.
- add new flag: {{reportUnusedDependencies}} (default true)
- add new flag: {{dumpClassPathUsage}} (default false)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (SLING-6923) Update JSPC plugin to support java 1.8
[ https://issues.apache.org/jira/browse/SLING-6923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16030492#comment-16030492 ] Tobias Bocanegra commented on SLING-6923: - I try to provide a patch... > Update JSPC plugin to support java 1.8 > -- > > Key: SLING-6923 > URL: https://issues.apache.org/jira/browse/SLING-6923 > Project: Sling > Issue Type: Improvement > Components: Maven Plugins and Archetypes >Affects Versions: Maven JSPC Plugin 2.0.8 >Reporter: Tobias Bocanegra > > The current 2.0.8 version of the JSPC plugin only supports java version 1.6. > task: > - update code of JSPC plugin to also support 1.7 and 1.8 > - use latest org.apache.sling.scripting.jsp:2.3.0 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (SLING-6923) Update JSPC plugin to support java 1.8
Tobias Bocanegra created SLING-6923: --- Summary: Update JSPC plugin to support java 1.8 Key: SLING-6923 URL: https://issues.apache.org/jira/browse/SLING-6923 Project: Sling Issue Type: Improvement Components: Maven Plugins and Archetypes Affects Versions: Maven JSPC Plugin 2.0.8 Reporter: Tobias Bocanegra The current 2.0.8 version of the JSPC plugin only supports java version 1.6. task: - update code of JSPC plugin to also support 1.7 and 1.8 - use latest org.apache.sling.scripting.jsp:2.3.0 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (SLING-4154) Discuss distribution components creation and configuration
[ https://issues.apache.org/jira/browse/SLING-4154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14208231#comment-14208231 ] Tobias Bocanegra commented on SLING-4154: - I agree with [~cziegeler] here. It is clearer if the individual components are loosely coupled. You can still write a HTTP endpoint that consolidates the configuration of an agent and auto-configures all parts. Discuss distribution components creation and configuration --- Key: SLING-4154 URL: https://issues.apache.org/jira/browse/SLING-4154 Project: Sling Issue Type: Task Components: Distribution Reporter: Marius Petria Fix For: Content Distribution 0.2.0 Distribution has one main component (agent) and several secondary components (triggers, exporters and importers). These can be created as java objects using a DistributionComponentFactory. The core framework provides a DefaultDistributionComponentFactory that will create the components implemented in the core but a client can define its own components and factory and the default component factory will use those to create a component it does not know of. The core framework also provides two ways of registering such a java object as an OSGI service: 1. using osgi configs, the osgi properties are parsed and passed to the factory, a component is created and registered (GenericDistributionComponentFactory) 2. resource configs, the properties of a resource are parsed and passed to the factory, a component is created and registered (ResourceBasedDistributionComponentFactory) Components registered as OSGI services are available as resources via OsgiServicePropertiesResourceProvider. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-3481) AbstractSlingRepository2.login().getRepository() not symmetric
[ https://issues.apache.org/jira/browse/SLING-3481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13951094#comment-13951094 ] Tobias Bocanegra commented on SLING-3481: - not only the session proxy, but also the AbstractSlingRepository2 which delegates to the real JCR repository. AbstractSlingRepository2.login().getRepository() not symmetric -- Key: SLING-3481 URL: https://issues.apache.org/jira/browse/SLING-3481 Project: Sling Issue Type: Bug Components: General Affects Versions: JCR Base 2.2.2 Reporter: Tobias Bocanegra Priority: Minor Fix For: JCR Base 2.2.4 Attachments: SLING-3481.r1582018..patch the AbstractSlingRepository2.login() returns a session, which does not return the same repository object in 'getRepository()'. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (SLING-3481) AbstractSlingRepository2.login().getRepository() not symmetric
[
https://issues.apache.org/jira/browse/SLING-3481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13949616#comment-13949616
]
Tobias Bocanegra commented on SLING-3481:
-
Well, the problem is not only in the proxy but with all classes that decorate a
JCR interface.
I don't know what the best pattern is - should they always returns decorators
so that the symmetry is preserved?
the JCR javadoc is a big vague here, if the same == identical object should
be returned in the reverse methods, eg:
http://www.day.com/maven/jsr170/javadocs/jcr-2.0/javax/jcr/Item.html#getSession():
{quote}
Returns the Session through which this Item was acquired.
{quote}
and:
http://www.day.com/maven/jsr170/javadocs/jcr-2.0/javax/jcr/Session.html#getRepository()
{quote}
Returns the Repository object through which this session was acquired.
{quote}
If you take the javadoc literally, I think the contract indeed is, that the
identical object needs to be returned. So a compliant implementation should
ensure that all returned objects are properly decorated, so that they can
return the original session and/or repository.
AbstractSlingRepository2.login().getRepository() not symmetric
--
Key: SLING-3481
URL: https://issues.apache.org/jira/browse/SLING-3481
Project: Sling
Issue Type: Bug
Components: General
Affects Versions: JCR Base 2.2.2
Reporter: Tobias Bocanegra
Priority: Minor
Fix For: JCR Base 2.2.4
Attachments: SLING-3481.r1582018..patch
the AbstractSlingRepository2.login() returns a session, which does not return
the same repository object in 'getRepository()'.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (SLING-3481) AbstractSlingRepository2.login().getRepository() not symmetric
[
https://issues.apache.org/jira/browse/SLING-3481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13948270#comment-13948270
]
Tobias Bocanegra commented on SLING-3481:
-
for example, this does not work:
{code}
@Refererence
SlingRepository repo;
Session s = repo.login(...);
SlingRepository r = (SlingRepository) s.getRepository();
{code}
AbstractSlingRepository2.login().getRepository() not symmetric
--
Key: SLING-3481
URL: https://issues.apache.org/jira/browse/SLING-3481
Project: Sling
Issue Type: Bug
Components: General
Affects Versions: JCR Base 2.2.2
Reporter: Tobias Bocanegra
Fix For: JCR Base 2.2.4
the AbstractSlingRepository2.login() returns a session, which does not return
the same repository object in 'getRepository()'.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (SLING-3481) AbstractSlingRepository2.login().getRepository() not symmetric
[
https://issues.apache.org/jira/browse/SLING-3481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13948297#comment-13948297
]
Tobias Bocanegra commented on SLING-3481:
-
the problem goes further, even if the session is decorated to return the
correct repository, all items created from the session would need to return the
outer session.
eg:
{code}
session.getNode().getSession() != session;
{code}
AbstractSlingRepository2.login().getRepository() not symmetric
--
Key: SLING-3481
URL: https://issues.apache.org/jira/browse/SLING-3481
Project: Sling
Issue Type: Bug
Components: General
Affects Versions: JCR Base 2.2.2
Reporter: Tobias Bocanegra
Fix For: JCR Base 2.2.4
the AbstractSlingRepository2.login() returns a session, which does not return
the same repository object in 'getRepository()'.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (SLING-3481) AbstractSlingRepository2.login().getRepository() not symmetric
Tobias Bocanegra created SLING-3481: --- Summary: AbstractSlingRepository2.login().getRepository() not symmetric Key: SLING-3481 URL: https://issues.apache.org/jira/browse/SLING-3481 Project: Sling Issue Type: Bug Components: General Affects Versions: JCR Base 2.2.2 Reporter: Tobias Bocanegra Fix For: JCR Base 2.2.4 the AbstractSlingRepository2.login() returns a session, which does not return the same repository object in 'getRepository()'. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (SLING-3481) AbstractSlingRepository2.login().getRepository() not symmetric
[ https://issues.apache.org/jira/browse/SLING-3481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tobias Bocanegra updated SLING-3481: Priority: Minor (was: Major) AbstractSlingRepository2.login().getRepository() not symmetric -- Key: SLING-3481 URL: https://issues.apache.org/jira/browse/SLING-3481 Project: Sling Issue Type: Bug Components: General Affects Versions: JCR Base 2.2.2 Reporter: Tobias Bocanegra Priority: Minor Fix For: JCR Base 2.2.4 the AbstractSlingRepository2.login() returns a session, which does not return the same repository object in 'getRepository()'. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (SLING-3481) AbstractSlingRepository2.login().getRepository() not symmetric
[
https://issues.apache.org/jira/browse/SLING-3481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13948336#comment-13948336
]
Tobias Bocanegra edited comment on SLING-3481 at 3/26/14 7:10 PM:
--
Attached patch that solves the top most problem within the SessionProxy. But
I'm not sure if this is the correct place, nor worth the effort as the original
session object gets lost over {{getItem(*)}} calls anyways.
was (Author: tripod):
Attached patch that solves the top most problem within the SessionProxy. But
I'm not sure if this is the correct place, nor worth the effort as the original
repository object gets lost over getItem(*) calls anyways.
AbstractSlingRepository2.login().getRepository() not symmetric
--
Key: SLING-3481
URL: https://issues.apache.org/jira/browse/SLING-3481
Project: Sling
Issue Type: Bug
Components: General
Affects Versions: JCR Base 2.2.2
Reporter: Tobias Bocanegra
Priority: Minor
Fix For: JCR Base 2.2.4
Attachments: SLING-3481.r1582018..patch
the AbstractSlingRepository2.login() returns a session, which does not return
the same repository object in 'getRepository()'.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (SLING-3481) AbstractSlingRepository2.login().getRepository() not symmetric
[ https://issues.apache.org/jira/browse/SLING-3481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tobias Bocanegra updated SLING-3481: Attachment: SLING-3481.r1582018..patch Attached patch that solves the top most problem within the SessionProxy. But I'm not sure if this is the correct place, nor worth the effort as the original repository object gets lost over getItem(*) calls anyways. AbstractSlingRepository2.login().getRepository() not symmetric -- Key: SLING-3481 URL: https://issues.apache.org/jira/browse/SLING-3481 Project: Sling Issue Type: Bug Components: General Affects Versions: JCR Base 2.2.2 Reporter: Tobias Bocanegra Priority: Minor Fix For: JCR Base 2.2.4 Attachments: SLING-3481.r1582018..patch the AbstractSlingRepository2.login() returns a session, which does not return the same repository object in 'getRepository()'. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (SLING-3481) AbstractSlingRepository2.login().getRepository() not symmetric
[
https://issues.apache.org/jira/browse/SLING-3481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13948336#comment-13948336
]
Tobias Bocanegra edited comment on SLING-3481 at 3/26/14 7:10 PM:
--
Attached patch that solves the top most problem within the SessionProxy. But
I'm not sure if this is the correct place, nor worth the effort as the original
session object gets lost over {{getItem()}} calls anyways.
was (Author: tripod):
Attached patch that solves the top most problem within the SessionProxy. But
I'm not sure if this is the correct place, nor worth the effort as the original
session object gets lost over {{getItem(*)}} calls anyways.
AbstractSlingRepository2.login().getRepository() not symmetric
--
Key: SLING-3481
URL: https://issues.apache.org/jira/browse/SLING-3481
Project: Sling
Issue Type: Bug
Components: General
Affects Versions: JCR Base 2.2.2
Reporter: Tobias Bocanegra
Priority: Minor
Fix For: JCR Base 2.2.4
Attachments: SLING-3481.r1582018..patch
the AbstractSlingRepository2.login() returns a session, which does not return
the same repository object in 'getRepository()'.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (SLING-3465) Wrong description for user.mapping property of ServiceUserMapperImpl
Tobias Bocanegra created SLING-3465: --- Summary: Wrong description for user.mapping property of ServiceUserMapperImpl Key: SLING-3465 URL: https://issues.apache.org/jira/browse/SLING-3465 Project: Sling Issue Type: Bug Components: Service User Mapper Affects Versions: Service User Mapper 1.0.0 Reporter: Tobias Bocanegra Priority: Minor the description of the user.mapping property of the ServiceUserMapperImpl is wrong. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (SLING-3465) Wrong description for user.mapping property of ServiceUserMapperImpl
[
https://issues.apache.org/jira/browse/SLING-3465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13940755#comment-13940755
]
Tobias Bocanegra commented on SLING-3465:
-
the current text is:
{code}
description = Provides mappings from service name to user names.
+ Each entry is of the form 'serviceName [ \:\
subServiceName ] \=\ userName'
+ where serviceName and subServiceName identify the service
and userName
+ defines the name of the user to provide to the service.
Invalid entries are logged and ignored.,
{code}
but the mapping is not based on service name, but on the bundle id. so it
should read:
{code}
description = Provides mappings from service name to user names.
+ Each entry is of the form 'bundleId [ \:\ subServiceName ]
\=\ userName'
+ where bundleId and subServiceName identify the service and
userName
+ defines the name of the user to provide to the service.
Invalid entries are logged and ignored.,
{code}
Wrong description for user.mapping property of ServiceUserMapperImpl
--
Key: SLING-3465
URL: https://issues.apache.org/jira/browse/SLING-3465
Project: Sling
Issue Type: Bug
Components: Service User Mapper
Affects Versions: Service User Mapper 1.0.0
Reporter: Tobias Bocanegra
Priority: Minor
the description of the user.mapping property of the ServiceUserMapperImpl
is wrong.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (SLING-3465) Wrong description for user.mapping property of ServiceUserMapperImpl
[ https://issues.apache.org/jira/browse/SLING-3465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tobias Bocanegra updated SLING-3465: Attachment: sling-3465-r1579316.patch Wrong description for user.mapping property of ServiceUserMapperImpl -- Key: SLING-3465 URL: https://issues.apache.org/jira/browse/SLING-3465 Project: Sling Issue Type: Bug Components: Service User Mapper Affects Versions: Service User Mapper 1.0.0 Reporter: Tobias Bocanegra Priority: Minor Attachments: sling-3465-r1579316.patch the description of the user.mapping property of the ServiceUserMapperImpl is wrong. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (SLING-3385) Expose replication agents actions and information via HTTP.
[
https://issues.apache.org/jira/browse/SLING-3385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13898073#comment-13898073
]
Tobias Bocanegra commented on SLING-3385:
-
For replication actions (commands) one would store the content of a command
and a task (or event handler) would pick it up, pass it to the agent and
then move it to outbox
store the 'commands' in the content - IMO that's nonsense.
From what I found out that is the only secure way in sling to expose REST
APIs OOTB. Any servlet based approach (registered by path or by resourcetype)
is unsecure by default and must be protected inside the servlet.
I see your point, but defining a purely content driven command interface is not
very practical - especially in respect to error handling. and you have to deal
with clustering problematics, too.
Expose replication agents actions and information via HTTP.
-
Key: SLING-3385
URL: https://issues.apache.org/jira/browse/SLING-3385
Project: Sling
Issue Type: Bug
Components: Extensions
Reporter: Marius Petria
Labels: replication
We need a safe way to expose replication agents actions via HTTP.
Replication agents are OSGI services that can do the following actions:
- replicate a content tree (build a content package and add it to a queue)
- add a content package into a queue
- remove a content package from its queue
A replication agent also exposes information about packages in its queues.
We have to expose all this actions and information over HTTP in order to be
available to authorized users.
Actions:
- Replicate (schedules a replication action)
POST /system/replication/agents
X-replication-action: ADD/DELETE
X-replication-path: /content/mycontent
X-replication-agent: {agentName}
- Import/Export (adds or removes a package from a queue)
POST /system/replication/packages
X-replication-action: PACKAGE_OFFER/PACKAGE_POLL
X-replication-queue: {queueName}
X-replication-agent: {agentName}
-Information about agents, queues, packages
GET /system/replication/agents?agent={agentName}
GET /system/replication/queues?agent={agentName}
GET /system/replication/packages?queue={queueName}agent={agentName}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (SLING-3385) Expose replication agents actions and information via HTTP.
[
https://issues.apache.org/jira/browse/SLING-3385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13896810#comment-13896810
]
Tobias Bocanegra commented on SLING-3385:
-
I don't like the use of http headers to transport the information. this is
highly unusable for ajax clients and for debugging. And it might not go through
proxies.
also, is there a documentation how the REST (or let's call it HTTP) API looks
like? what are the parameters for? how is the error handling? what is the
payload? what is the response?
Expose replication agents actions and information via HTTP.
-
Key: SLING-3385
URL: https://issues.apache.org/jira/browse/SLING-3385
Project: Sling
Issue Type: Bug
Components: Extensions
Reporter: Marius Petria
Labels: replication
We need a safe way to expose replication agents actions via HTTP.
Replication agents are OSGI services that can do the following actions:
- replicate a content tree (build a content package and add it to a queue)
- add a content package into a queue
- remove a content package from its queue
A replication agent also exposes information about packages in its queues.
We have to expose all this actions and information over HTTP in order to be
available to authorized users.
Actions:
- Replicate (schedules a replication action)
POST /system/replication/agents
X-replication-action: ADD/DELETE
X-replication-path: /content/mycontent
X-replication-agent: {agentName}
- Import/Export (adds or removes a package from a queue)
POST /system/replication/packages
X-replication-action: PACKAGE_OFFER/PACKAGE_POLL
X-replication-queue: {queueName}
X-replication-agent: {agentName}
-Information about agents, queues, packages
GET /system/replication/agents?agent={agentName}
GET /system/replication/queues?agent={agentName}
GET /system/replication/packages?queue={queueName}agent={agentName}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (SLING-3385) Expose replication agents actions and information via HTTP.
[
https://issues.apache.org/jira/browse/SLING-3385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13897139#comment-13897139
]
Tobias Bocanegra commented on SLING-3385:
-
I'm not saying you should store the 'commands' in the content - IMO that's
nonsense. but avoid HTTP headers to transport any action or parameter. they
belong to the HTTP layer, not your application :-)
A better REST way would be to upload the package first, get a location URL, and
then issue the commands referring to the packages. this also mitigates the
multiple-agents problem a bit.
Expose replication agents actions and information via HTTP.
-
Key: SLING-3385
URL: https://issues.apache.org/jira/browse/SLING-3385
Project: Sling
Issue Type: Bug
Components: Extensions
Reporter: Marius Petria
Labels: replication
We need a safe way to expose replication agents actions via HTTP.
Replication agents are OSGI services that can do the following actions:
- replicate a content tree (build a content package and add it to a queue)
- add a content package into a queue
- remove a content package from its queue
A replication agent also exposes information about packages in its queues.
We have to expose all this actions and information over HTTP in order to be
available to authorized users.
Actions:
- Replicate (schedules a replication action)
POST /system/replication/agents
X-replication-action: ADD/DELETE
X-replication-path: /content/mycontent
X-replication-agent: {agentName}
- Import/Export (adds or removes a package from a queue)
POST /system/replication/packages
X-replication-action: PACKAGE_OFFER/PACKAGE_POLL
X-replication-queue: {queueName}
X-replication-agent: {agentName}
-Information about agents, queues, packages
GET /system/replication/agents?agent={agentName}
GET /system/replication/queues?agent={agentName}
GET /system/replication/packages?queue={queueName}agent={agentName}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (SLING-3352) Expose OSGI configuration as JCR nodes
[ https://issues.apache.org/jira/browse/SLING-3352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13887568#comment-13887568 ] Tobias Bocanegra commented on SLING-3352: - the advantage is that you have a resource with atype for each agent that can be controlled. this saves you from doing weird path and suffix tricks in the servlet. of ocurse a full sync is favorable, but I understand Felix concerns. this would be a compromise. Expose OSGI configuration as JCR nodes -- Key: SLING-3352 URL: https://issues.apache.org/jira/browse/SLING-3352 Project: Sling Issue Type: Improvement Reporter: Marius Petria Labels: replication We need a safe way to expose OSGI configuration via HTTP. Requirements: - all configs for a certain factory should be manageable - they should have associated JCR nodes that contain the config properties - only configs that are available through ConfigurationAdmin should be available - the HTTP urls should have friendly names - (Optional) the implementation should be general enough to be used for other configs other than replication if needed For example: a configuration with name publish for org.apache.sling.replication.agent.impl.ReplicationAgentServiceFactory should be mapped to /etc/replication/agent/publish Problems with current implementation of JCR nodes created by JCR installed: - Configuration files are read and created from /apps/.../config or /libs/.../config, and there is no easy way to determine which are active in the ConfigurationAdmin - There is no way to restrict a repository path to create only configuration from a specified factory (making it unusable with relaxed ACLs) - The url of a configuration is unfriendly (it contains the fully qualified name of the factory) - The node types are not homogenous making it hard to use in a client application (some are nt:file, some are sling:OsgiConfig) -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (SLING-3352) Expose OSGI configuration as JCR nodes
[ https://issues.apache.org/jira/browse/SLING-3352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13888115#comment-13888115 ] Tobias Bocanegra commented on SLING-3352: - An option not mentioned here is to improve the JCR installer in such a way that it can be configured (by config id) to enforce osgi:config nodes in specific locations (for writing and reading) and also syncs those with the config admin on startup. Expose OSGI configuration as JCR nodes -- Key: SLING-3352 URL: https://issues.apache.org/jira/browse/SLING-3352 Project: Sling Issue Type: Improvement Reporter: Marius Petria Labels: replication We need a safe way to expose OSGI configuration via HTTP. Requirements: - all configs for a certain factory should be manageable - they should have associated JCR nodes that contain the config properties - only configs that are available through ConfigurationAdmin should be available - the HTTP urls should have friendly names - (Optional) the implementation should be general enough to be used for other configs other than replication if needed For example: a configuration with name publish for org.apache.sling.replication.agent.impl.ReplicationAgentServiceFactory should be mapped to /etc/replication/agent/publish Problems with current implementation of JCR nodes created by JCR installed: - Configuration files are read and created from /apps/.../config or /libs/.../config, and there is no easy way to determine which are active in the ConfigurationAdmin - There is no way to restrict a repository path to create only configuration from a specified factory (making it unusable with relaxed ACLs) - The url of a configuration is unfriendly (it contains the fully qualified name of the factory) - The node types are not homogenous making it hard to use in a client application (some are nt:file, some are sling:OsgiConfig) -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (SLING-3352) Expose OSGI configuration as JCR nodes
[ https://issues.apache.org/jira/browse/SLING-3352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13886852#comment-13886852 ] Tobias Bocanegra commented on SLING-3352: - bq. You might also want to provide the HTTP endpoint as a node in the repository that you protect. let's look at the special case of replication agents: IMO what is needed is to have 1 JCR node for each replication agent (or agent group) that has a special resource type and will be protected by JCR ACLs. If those nodes also contain the properties of the respective OSGi configuration is not relevant. the servlet behind the resource type should create a response derived from the OSGi config. but it might also include other, more dynamic information, like # of pending items. the service should also listen for config admin changes and create/remove(/update) the nodes. I agree with felix, that adding a 2-way sync might result it a mess - but would simplify the management of course. note: if the config properties are also mapped to the node, you can use the norma json-get to read the data. Expose OSGI configuration as JCR nodes -- Key: SLING-3352 URL: https://issues.apache.org/jira/browse/SLING-3352 Project: Sling Issue Type: Improvement Reporter: Marius Petria Labels: replication We need a safe way to expose OSGI configuration via HTTP. Requirements: - all configs for a certain factory should be manageable - they should have associated JCR nodes that contain the config properties - only configs that are available through ConfigurationAdmin should be available - the HTTP urls should have friendly names - (Optional) the implementation should be general enough to be used for other configs other than replication if needed For example: a configuration with name publish for org.apache.sling.replication.agent.impl.ReplicationAgentServiceFactory should be mapped to /etc/replication/agent/publish Problems with current implementation of JCR nodes created by JCR installed: - Configuration files are read and created from /apps/.../config or /libs/.../config, and there is no easy way to determine which are active in the ConfigurationAdmin - There is no way to restrict a repository path to create only configuration from a specified factory (making it unusable with relaxed ACLs) - The url of a configuration is unfriendly (it contains the fully qualified name of the factory) - The node types are not homogenous making it hard to use in a client application (some are nt:file, some are sling:OsgiConfig) -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (SLING-3179) Implement solution to the Authentication Handler Credential Validation Problem
[ https://issues.apache.org/jira/browse/SLING-3179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13868845#comment-13868845 ] Tobias Bocanegra commented on SLING-3179: - bq. I don't see how this is adding security other than reintroducing the TrustedInfo again, just with different and more complex code. yes, but on a different level. IMO the JCR resource provider must come with a LoginModule counterpart that establishes the trust. bq. complex doAs() logic, which really exposes internal JCR/repository user logic this is how JAAS works and also referred to in [Repository.login()|http://www.day.com/maven/javax.jcr/javadocs/jcr-2.0/javax/jcr/Repository.html#login(javax.jcr.Credentials, java.lang.String)]. AFAICS, the only problem is the population of the subject and that's why I'd prefer the LoginModule approach. Implement solution to the Authentication Handler Credential Validation Problem -- Key: SLING-3179 URL: https://issues.apache.org/jira/browse/SLING-3179 Project: Sling Issue Type: Bug Components: API, JCR, ResourceResolver Affects Versions: JCR Base 2.1.2, API 2.4.2, Resource Resolver 1.0.6 Reporter: Felix Meschberger Assignee: Antonio Sanso Attachments: SLING-3179.diff, SLING-3179.patch The proposal [Solving the Authentication Handler Credential Validation Problem|https://cwiki.apache.org/confluence/display/SLING/Solving+the+Authentication+Handler+Credential+Validation+Problem] should be implemented. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (SLING-2881) [I18N][Performance] JcrResourceBundleProvider clears the cache on mix:language changes
[ https://issues.apache.org/jira/browse/SLING-2881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tobias Bocanegra updated SLING-2881: Attachment: sling-2881.r1551665.patch proposed patch that implements alex's suggestion. however, it might be better to not go this way and implement the new dictionary approach as discussed on the list: http://www.mail-archive.com/dev@sling.apache.org/msg25686.html [I18N][Performance] JcrResourceBundleProvider clears the cache on mix:language changes -- Key: SLING-2881 URL: https://issues.apache.org/jira/browse/SLING-2881 Project: Sling Issue Type: Bug Components: Extensions Affects Versions: i18n 2.2.4 Environment: CQ5.6 Reporter: Rob Ryan Labels: performance Attachments: sling-2881.r1551665.patch Performance of an appplication using Sling i18n JcrResourceBundleProvider suffers drastically if nodes with mixin type mix:language are modified frequently. The reason for the performance degradation is that JcrResourceBundleProvider registers a JCR event listener for node types: mix:language and sling:Message. It then clears the i18n resource bundle cache whenever a node with these types appears in an event. The JCR 2.0 spec indicates applications should use a mix:language type as the standard way to provide a property specifying the natural language which the content of a node is expressed. Therefore clearing the resource bundle cache on a change to *any* node with a mix:language type is inappropriately broad. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Created] (SLING-3256) Regression by SLING-3255: StreamRendererServlet writes wrong output
Tobias Bocanegra created SLING-3256:
---
Summary: Regression by SLING-3255: StreamRendererServlet writes
wrong output
Key: SLING-3256
URL: https://issues.apache.org/jira/browse/SLING-3256
Project: Sling
Issue Type: Bug
Components: Servlets
Affects Versions: Servlets Get 2.1.4
Reporter: Tobias Bocanegra
the changes introduced by SLING-3255 contained a bug, which produces wrong
output.
on line 548, only {{read}} bytes should be written, not {{len}} :
{code}
543 while (position end) {
544 int len = (int) Math.min(end - position, buffer.length);
545 int read = istream.read(buffer, 0, len);
546 if (read != -1) {
547 position += read;
548 ostream.write(buffer, 0, len);
549 } else {
550 break;
551 }
552 }
553 }
{code}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (SLING-3256) Regression by SLING-3255: StreamRendererServlet writes wrong output
[
https://issues.apache.org/jira/browse/SLING-3256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13831991#comment-13831991
]
Tobias Bocanegra commented on SLING-3256:
-
on line 548, only {{read}} bytes should be written, not {{len}} :
{code}
543 while (position end) {
544 int len = (int) Math.min(end - position, buffer.length);
545 int read = istream.read(buffer, 0, len);
546 if (read != -1) {
547 position += read;
548 ostream.write(buffer, 0, len);
549 } else {
550 break;
551 }
552 }
553 }
{code}
Regression by SLING-3255: StreamRendererServlet writes wrong output
---
Key: SLING-3256
URL: https://issues.apache.org/jira/browse/SLING-3256
Project: Sling
Issue Type: Bug
Components: Servlets
Affects Versions: Servlets Get 2.1.4
Reporter: Tobias Bocanegra
the changes introduced by SLING-3255 contained a bug, which produces wrong
output.
on line 548, only {{read}} bytes should be written, not {{len}} :
{code}
543 while (position end) {
544 int len = (int) Math.min(end - position, buffer.length);
545 int read = istream.read(buffer, 0, len);
546 if (read != -1) {
547 position += read;
548 ostream.write(buffer, 0, len);
549 } else {
550 break;
551 }
552 }
553 }
{code}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (SLING-3256) Regression by SLING-3255: StreamRendererServlet writes wrong output
[
https://issues.apache.org/jira/browse/SLING-3256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tobias Bocanegra updated SLING-3256:
Description: the changes introduced by SLING-3255 contained a bug, which
produces wrong output. (was: the changes introduced by SLING-3255 contained a
bug, which produces wrong output.
on line 548, only {{read}} bytes should be written, not {{len}} :
{code}
543 while (position end) {
544 int len = (int) Math.min(end - position, buffer.length);
545 int read = istream.read(buffer, 0, len);
546 if (read != -1) {
547 position += read;
548 ostream.write(buffer, 0, len);
549 } else {
550 break;
551 }
552 }
553 }
{code})
Regression by SLING-3255: StreamRendererServlet writes wrong output
---
Key: SLING-3256
URL: https://issues.apache.org/jira/browse/SLING-3256
Project: Sling
Issue Type: Bug
Components: Servlets
Affects Versions: Servlets Get 2.1.4
Reporter: Tobias Bocanegra
the changes introduced by SLING-3255 contained a bug, which produces wrong
output.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (SLING-3147) Oak: i18n dictionaries observation no longer works
[ https://issues.apache.org/jira/browse/SLING-3147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13823337#comment-13823337 ] Tobias Bocanegra commented on SLING-3147: - ...or create the session with auto-refresh. see OAK-803 Oak: i18n dictionaries observation no longer works -- Key: SLING-3147 URL: https://issues.apache.org/jira/browse/SLING-3147 Project: Sling Issue Type: Bug Components: Extensions, Oak Affects Versions: i18n 2.2.6 Reporter: Alexander Klimetschek Labels: i18n When running Sling with Oak, the JcrResourceBundleProvider [0] in the i18n bundle apparently no longer gets the observation events for sling:message nodes in the JCR. This means that changing a string in the repo or installing a package with new translations won't have an effect if the resource bundle is already loaded in memory. Workaround is to restart the i18n bundle after every string change. [0] http://svn.apache.org/repos/asf/sling/trunk/contrib/extensions/i18n/src/main/java/org/apache/sling/i18n/impl/JcrResourceBundleProvider.java -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (SLING-3223) Donation of a replication module for Sling
[ https://issues.apache.org/jira/browse/SLING-3223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13815155#comment-13815155 ] Tobias Bocanegra commented on SLING-3223: - btw: how is deactivate implemented? not via an empty content package? an empty package (see VoidReplicationPackage) but then, is there really a difference between _activate_ and _deacticate_ ? they \[_the authentication handlers_] are used for authenticate TransportHandlers which may deliver content to either an HTTP endpoint (most often) or not (e.g. file system, or other) ok. consider using a different name, then. the adapter from SlingRequest to ReplicationPackage is really questionable in IMO. It is used in a very specific case and the adaption is considerably expensive. Or do you foresee that other clients of this API adapt a request to a ReplicationPackage ? I agree that can be much improved, that's just used from the receiving servlet for reading a replication package stream to install the package on the receiving instance. I would get rid of it and put it into an utility class, or into the servlet where you need it. it just pollutes the set of adapters in sling. Donation of a replication module for Sling -- Key: SLING-3223 URL: https://issues.apache.org/jira/browse/SLING-3223 Project: Sling Issue Type: Task Components: Extensions Reporter: Tommaso Teofili Attachments: SLING-3223.patch Issue to track donation of a replication module for Sling, see thread at http://markmail.org/thread/ic62k5pc34ppb5ko -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (SLING-3223) Donation of a replication module for Sling
[
https://issues.apache.org/jira/browse/SLING-3223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13814130#comment-13814130
]
Tobias Bocanegra commented on SLING-3223:
-
some quick comments:
- way to little documentation (javadoc, general architecture)
- Don't use HTTP headers to transport additional information. this makes it
harder to get request correctly though proxies and firewalls
- If you use customer HTTP headers, it's best practice to prepend an app
specific prefix, eg: {{X-Sling-Replication-Action}}.
- why do you expose a {{ReplicationConfigurationServlet}} and not rely on
default mechanisms to update config, e.g. update the config via
SlingPostServlet or via felix console? (Is there some functionality missing in
Sling or does every component needs to provide it's own management REST API?)
- {{ReplicationActionType}} names are probably coming from Adobe's replication
- I would reconsider if _Activate_ and _Deactivate_ really are good names. btw:
how is _deactivate_ implemented? not via an empty content package?
-- alternative names for activate: add, put, import, post
-- alternative names for deactivate: delete
- I don't know if {{TriggerPathReplicationRule}} is really a sufficient filter.
Usually it's hard to determined at what point a modified subtree is ready to
replicate. you would probably need to add much more logic to it
- I don't quite understand {{AuthenticationHandler}}. Are those providers that
are used to add authentication to the HTTP requests, or are they consumers that
are used to authenticate replication payloads?
-- If the first, I would rename them to something more specific, like:
{{ReplicationCredentialsProvider}}
-- If the latter, I would really not reinvent the wheel here, and rely on
authentication already present in Sling.
- the adapter from {{SlingRequest}} to {{ReplicationPackage}} is really
questionable in IMO. It is used in a very specific case and the adaption is
considerably expensive. Or do you foresee that other clients of this API adapt
a request to a ReplicationPackage ?
- suggest to add package-info.java files with the bundle export information
over Export-Package elements in the pom.xml
Donation of a replication module for Sling
--
Key: SLING-3223
URL: https://issues.apache.org/jira/browse/SLING-3223
Project: Sling
Issue Type: Task
Components: Extensions
Reporter: Tommaso Teofili
Attachments: SLING-3223.patch
Issue to track donation of a replication module for Sling, see thread at
http://markmail.org/thread/ic62k5pc34ppb5ko
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Created] (SLING-2877) Regression: changes off SLING-2775 fail to set jcr:lastModified property on existing nodes
Tobias Bocanegra created SLING-2877: --- Summary: Regression: changes off SLING-2775 fail to set jcr:lastModified property on existing nodes Key: SLING-2877 URL: https://issues.apache.org/jira/browse/SLING-2877 Project: Sling Issue Type: Bug Components: Servlets Affects Versions: Servlets Post 2.2.0 Reporter: Tobias Bocanegra Fix For: Servlets Post 2.3.2 Posting to an existing node with empty jcr:lastModified value does not set the date value if the property is autocreated and the node already exists. another bug is that it looks for property definitions in all NodeType subtypes (instead of the super types). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SLING-2877) Regression: changes off SLING-2775 fail to set jcr:lastModified property on existing nodes
[ https://issues.apache.org/jira/browse/SLING-2877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13664629#comment-13664629 ] Tobias Bocanegra commented on SLING-2877: - another bug is, that the search for the property definition does not include the property type, but this is a detail, as non of the auto-props is ambiguous. Regression: changes off SLING-2775 fail to set jcr:lastModified property on existing nodes -- Key: SLING-2877 URL: https://issues.apache.org/jira/browse/SLING-2877 Project: Sling Issue Type: Bug Components: Servlets Affects Versions: Servlets Post 2.2.0 Reporter: Tobias Bocanegra Fix For: Servlets Post 2.3.2 Posting to an existing node with empty jcr:lastModified value does not set the date value if the property is autocreated and the node already exists. another bug is that it looks for property definitions in all NodeType subtypes (instead of the super types). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (SLING-2877) Regression: changes off SLING-2775 fail to set jcr:lastModified property on existing nodes
[ https://issues.apache.org/jira/browse/SLING-2877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tobias Bocanegra updated SLING-2877: Attachment: sling_2877.r1485465.patch proposed patch (untested) Regression: changes off SLING-2775 fail to set jcr:lastModified property on existing nodes -- Key: SLING-2877 URL: https://issues.apache.org/jira/browse/SLING-2877 Project: Sling Issue Type: Bug Components: Servlets Affects Versions: Servlets Post 2.2.0 Reporter: Tobias Bocanegra Fix For: Servlets Post 2.3.2 Attachments: sling_2877.r1485465.patch Posting to an existing node with empty jcr:lastModified value does not set the date value if the property is autocreated and the node already exists. another bug is that it looks for property definitions in all NodeType subtypes (instead of the super types). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (SLING-2670) Add support for suffix addressed resources
Tobias Bocanegra created SLING-2670:
---
Summary: Add support for suffix addressed resources
Key: SLING-2670
URL: https://issues.apache.org/jira/browse/SLING-2670
Project: Sling
Issue Type: Improvement
Components: API
Reporter: Tobias Bocanegra
Priority: Minor
For web applications like user consoles or administration panels, it's common
to store the layout information in the content (resource). This content can
then be addressed naturally and the respective scripts then used to render the
GUI of the console. When the console need to display information of existing
resources, their path needs to be passed in the URL as well. one option is a
query parameter, another the request suffix.
eg:
http://localhost:8080/content/webconsole/grid.html/content/products
Every script or servlet needs to transform the suffix into a resource with
something like:
Resource targetResource =
request.getResourceResolver().getResource(request.getRequestPathInfo().getSuffix());
which is a bit repetitive, error prone and not cached.
therefor I sugest to introduce:
org.apache.sling.api.request.RequestPathInfo {
/**
* Returns the resource addressed by the suffix or null if the resource
does not exist. The suffix is
* considered to address the resource directly as path.
*/
Resource getSuffixResource();
}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SLING-2467) Define Document-like node type with jcr:content child and default handling servlet
[ https://issues.apache.org/jira/browse/SLING-2467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13437997#comment-13437997 ] Tobias Bocanegra commented on SLING-2467: - so back to a very generic name like: sling:Content ? Define Document-like node type with jcr:content child and default handling servlet -- Key: SLING-2467 URL: https://issues.apache.org/jira/browse/SLING-2467 Project: Sling Issue Type: New Feature Components: JCR Reporter: Felix Meschberger The JCR specification allows for nodes to have a dual nature: As part of a hierarchy containing documents (as a folder in a filesystem) and as a container for actual data (as a file in a filesystem). There are also two node types defined to reflect the filesystem notions: nt:folder for folders and nt:file for Files. The nt:file nodetype requries a child node jcr:content to provide the actual contents of the file. This child node defaults to be of type nt:resource but can actually be anything and as such provide structured data in addition to just plain binary data (in the jcr:data property). Yet, nt:file and nt:folder are just that: nt:file for file data not containing children and nt:file for folders but to not contain structured data. We should define a node type which can be used to really convey this dual nature as a data container (file) and document container (folder) at the same time. So I propose the following node types: [sling:Document] nt:hierarchyNode, sling:Resource - sling:resourcetype (String) = sling/document auto mandatory - * (undefined) - * (undefined) multiple + jcr:content (nt:base) = nt:unstructured mandatory + * (nt:base) = sling:Document version [sling:OrderedDocument] sling:Document orderable + * (nt:base) = sling:OrderedDocument version In addition we create default GET servlet for handling the sling/document resource type: if the resource has a jcr:content child then include jcr:content else sendError 404 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SLING-2467) Define Document-like node type with jcr:content child and default handling servlet
[ https://issues.apache.org/jira/browse/SLING-2467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13434853#comment-13434853 ] Tobias Bocanegra commented on SLING-2467: - why not nt:file in the first place ? because nt:file does not allow other child nodes than jcr:content, which is mandatory. so sling:File would be the most logical name (having already sling:Folder as a softer definition than nt:folder) Define Document-like node type with jcr:content child and default handling servlet -- Key: SLING-2467 URL: https://issues.apache.org/jira/browse/SLING-2467 Project: Sling Issue Type: New Feature Components: JCR Reporter: Felix Meschberger The JCR specification allows for nodes to have a dual nature: As part of a hierarchy containing documents (as a folder in a filesystem) and as a container for actual data (as a file in a filesystem). There are also two node types defined to reflect the filesystem notions: nt:folder for folders and nt:file for Files. The nt:file nodetype requries a child node jcr:content to provide the actual contents of the file. This child node defaults to be of type nt:resource but can actually be anything and as such provide structured data in addition to just plain binary data (in the jcr:data property). Yet, nt:file and nt:folder are just that: nt:file for file data not containing children and nt:file for folders but to not contain structured data. We should define a node type which can be used to really convey this dual nature as a data container (file) and document container (folder) at the same time. So I propose the following node types: [sling:Document] nt:hierarchyNode, sling:Resource - sling:resourcetype (String) = sling/document auto mandatory - * (undefined) - * (undefined) multiple + jcr:content (nt:base) = nt:unstructured mandatory + * (nt:base) = sling:Document version [sling:OrderedDocument] sling:Document orderable + * (nt:base) = sling:OrderedDocument version In addition we create default GET servlet for handling the sling/document resource type: if the resource has a jcr:content child then include jcr:content else sendError 404 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SLING-2467) Define Document-like node type with jcr:content child and default handling servlet
[ https://issues.apache.org/jira/browse/SLING-2467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13434864#comment-13434864 ] Tobias Bocanegra commented on SLING-2467: - I don't think we need an orderable variant because this relates to the child nodes, right ? yes, I think we need this. For example in a WCM system, where you have nesting documents/pages (aka sling:Files), they might need a stable order. Define Document-like node type with jcr:content child and default handling servlet -- Key: SLING-2467 URL: https://issues.apache.org/jira/browse/SLING-2467 Project: Sling Issue Type: New Feature Components: JCR Reporter: Felix Meschberger The JCR specification allows for nodes to have a dual nature: As part of a hierarchy containing documents (as a folder in a filesystem) and as a container for actual data (as a file in a filesystem). There are also two node types defined to reflect the filesystem notions: nt:folder for folders and nt:file for Files. The nt:file nodetype requries a child node jcr:content to provide the actual contents of the file. This child node defaults to be of type nt:resource but can actually be anything and as such provide structured data in addition to just plain binary data (in the jcr:data property). Yet, nt:file and nt:folder are just that: nt:file for file data not containing children and nt:file for folders but to not contain structured data. We should define a node type which can be used to really convey this dual nature as a data container (file) and document container (folder) at the same time. So I propose the following node types: [sling:Document] nt:hierarchyNode, sling:Resource - sling:resourcetype (String) = sling/document auto mandatory - * (undefined) - * (undefined) multiple + jcr:content (nt:base) = nt:unstructured mandatory + * (nt:base) = sling:Document version [sling:OrderedDocument] sling:Document orderable + * (nt:base) = sling:OrderedDocument version In addition we create default GET servlet for handling the sling/document resource type: if the resource has a jcr:content child then include jcr:content else sendError 404 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SLING-2467) Define Document-like node type with jcr:content child and default handling servlet
[ https://issues.apache.org/jira/browse/SLING-2467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13434261#comment-13434261 ] Tobias Bocanegra commented on SLING-2467: - I wouldn't try to overstructure the hierarchy. after all, jcr:content should stay unstructured. Define Document-like node type with jcr:content child and default handling servlet -- Key: SLING-2467 URL: https://issues.apache.org/jira/browse/SLING-2467 Project: Sling Issue Type: New Feature Components: JCR Reporter: Felix Meschberger The JCR specification allows for nodes to have a dual nature: As part of a hierarchy containing documents (as a folder in a filesystem) and as a container for actual data (as a file in a filesystem). There are also two node types defined to reflect the filesystem notions: nt:folder for folders and nt:file for Files. The nt:file nodetype requries a child node jcr:content to provide the actual contents of the file. This child node defaults to be of type nt:resource but can actually be anything and as such provide structured data in addition to just plain binary data (in the jcr:data property). Yet, nt:file and nt:folder are just that: nt:file for file data not containing children and nt:file for folders but to not contain structured data. We should define a node type which can be used to really convey this dual nature as a data container (file) and document container (folder) at the same time. So I propose the following node types: [sling:Document] nt:hierarchyNode, sling:Resource - sling:resourcetype (String) = sling/document auto mandatory - * (undefined) - * (undefined) multiple + jcr:content (nt:base) = nt:unstructured mandatory + * (nt:base) = sling:Document version [sling:OrderedDocument] sling:Document orderable + * (nt:base) = sling:OrderedDocument version In addition we create default GET servlet for handling the sling/document resource type: if the resource has a jcr:content child then include jcr:content else sendError 404 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SLING-1391) Make JcrModifiablePropertyMap write changes directly
[
https://issues.apache.org/jira/browse/SLING-1391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13415811#comment-13415811
]
Tobias Bocanegra commented on SLING-1391:
-
what about adding a method: save(boolean persist)
that only pushes the cached entries to the node but does not call
session.save() (if persist is false).
Make JcrModifiablePropertyMap write changes directly
Key: SLING-1391
URL: https://issues.apache.org/jira/browse/SLING-1391
Project: Sling
Issue Type: Improvement
Components: JCR
Affects Versions: JCR Resource 2.0.6
Reporter: Vidar S. Ramdal
As discussed on http://markmail.org/thread/io2dnkykjnayydwz, the current
JcrModifiablePropertyMap implementation of the PersistableValueMap interface
uses a cached map to store changed values. The cached values are not written
to the underlying node until a PVM.save() is called - at which point JMPM
calles Node.save() to persist the changes. Thus, reverting changes made in a
session is impossible.
This makes atomic operations such as this difficult to implement:
try {
// Modify a property through PersistableValueMap
PersistableValueMap props = resource.adaptTo(PersistableValueMap.class);
props.put(prop, value);
props.save();
// Do some other, unrelated changes
Node sibling = resource.adaptTo(Node.class).getParent().addNode(child);
sibling.doSomeChange(); // This may throw an exception
session.save();
} catch(Exception e) {
session.refresh(false); // Cancel the pending changes of this session
}
Felix suggests (http://markmail.org/message/5fae3cwsshbnemrf):
* Enable the PersistableValueMap to write through to the JCR
transient space on put().
* Write-through is configurable on a global level (in the
JcrResourceResolver providing the PersistableValueMap
instances upon adapt()). By default it is switched off
(backwards compatiblity).
* Write-through can also be switched on/off on a per-instance
level of the PersistableValueMap object (setWriteThrough(boolean))
* PersistableValueMap.save() first writes back local changes
not already stored using write-through and then calls node.save()
* PersistableValueMap.reset() drops local changes not already stored
using write-through and then calls node.refresh(false)
* When we finally do full CRUD in the ResourceResolver, we should
add save/reset methods, which would call Session.save() or
refresh(false), resp. For now the Session methods must be called
directly.
This task is about implementing Felix' suggestions.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SLING-2467) Define Document-like node type with jcr:content child and default handling servlet
[ https://issues.apache.org/jira/browse/SLING-2467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13271748#comment-13271748 ] Tobias Bocanegra commented on SLING-2467: - I don't think that the sling:resourceType should be mandatory or auto created. it is implied by the primary node type. Same for jcr:content, leaving this optional allows for empty documents. Define Document-like node type with jcr:content child and default handling servlet -- Key: SLING-2467 URL: https://issues.apache.org/jira/browse/SLING-2467 Project: Sling Issue Type: New Feature Components: JCR Reporter: Felix Meschberger The JCR specification allows for nodes to have a dual nature: As part of a hierarchy containing documents (as a folder in a filesystem) and as a container for actual data (as a file in a filesystem). There are also two node types defined to reflect the filesystem notions: nt:folder for folders and nt:file for Files. The nt:file nodetype requries a child node jcr:content to provide the actual contents of the file. This child node defaults to be of type nt:resource but can actually be anything and as such provide structured data in addition to just plain binary data (in the jcr:data property). Yet, nt:file and nt:folder are just that: nt:file for file data not containing children and nt:file for folders but to not contain structured data. We should define a node type which can be used to really convey this dual nature as a data container (file) and document container (folder) at the same time. So I propose the following node types: [sling:Document] nt:hierarchyNode, sling:Resource - sling:resourcetype (String) = sling/document auto mandatory - * (undefined) - * (undefined) multiple + jcr:content (nt:base) = nt:unstructured mandatory + * (nt:base) = granite:Document version [sling:OrderedDocument] sling:Document orderable + * (nt:base) = sling:OrderedDocument version In addition we create default GET servlet for handling the sling/document resource type: if the resource has a jcr:content child then include jcr:content else sendError 404 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SLING-2467) Define Document-like node type with jcr:content child and default handling servlet
[ https://issues.apache.org/jira/browse/SLING-2467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13271932#comment-13271932 ] Tobias Bocanegra commented on SLING-2467: - The idea of the explicit resource type allows for better inheritance. I agree, but making property mandatory just uses more persistence space in 99% of the cases when it's not needed. sling:Document indeed is a bit too domain specific. sling:Content is the best alternative so far. Other possible names: sling:HierarchyContent Define Document-like node type with jcr:content child and default handling servlet -- Key: SLING-2467 URL: https://issues.apache.org/jira/browse/SLING-2467 Project: Sling Issue Type: New Feature Components: JCR Reporter: Felix Meschberger The JCR specification allows for nodes to have a dual nature: As part of a hierarchy containing documents (as a folder in a filesystem) and as a container for actual data (as a file in a filesystem). There are also two node types defined to reflect the filesystem notions: nt:folder for folders and nt:file for Files. The nt:file nodetype requries a child node jcr:content to provide the actual contents of the file. This child node defaults to be of type nt:resource but can actually be anything and as such provide structured data in addition to just plain binary data (in the jcr:data property). Yet, nt:file and nt:folder are just that: nt:file for file data not containing children and nt:file for folders but to not contain structured data. We should define a node type which can be used to really convey this dual nature as a data container (file) and document container (folder) at the same time. So I propose the following node types: [sling:Document] nt:hierarchyNode, sling:Resource - sling:resourcetype (String) = sling/document auto mandatory - * (undefined) - * (undefined) multiple + jcr:content (nt:base) = nt:unstructured mandatory + * (nt:base) = sling:Document version [sling:OrderedDocument] sling:Document orderable + * (nt:base) = sling:OrderedDocument version In addition we create default GET servlet for handling the sling/document resource type: if the resource has a jcr:content child then include jcr:content else sendError 404 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (SLING-2158) JsonSerialization: Add new :oder JSON array to transport child node ordering when needed
JsonSerialization: Add new :oder JSON array to transport child node ordering
when needed
--
Key: SLING-2158
URL: https://issues.apache.org/jira/browse/SLING-2158
Project: Sling
Issue Type: New Feature
Components: Servlets
Reporter: Tobias Bocanegra
Priority: Minor
as discussed in:
http://mail-archives.apache.org/mod_mbox/sling-dev/201104.mbox/%3cbanlktimau-cv5fhyyrx-z5ktn4afmfq...@mail.gmail.com%3E
i suggest to add a new array property containing the child node names to the
default JSON renderer if 'requested' with an 'order' selector.
i would include the child node names also on the end of the depth limit. this
allows to get the child node names without the need to load them with a deeper
request:
eg:
GET /content/en.0.order.json would return:
{
title: Hello, world,
:oder: [sub1, sub2]
}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (SLING-2158) JsonSerialization: Add new :order JSON array to transport child node ordering when needed
[
https://issues.apache.org/jira/browse/SLING-2158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tobias Bocanegra updated SLING-2158:
Summary: JsonSerialization: Add new :order JSON array to transport child
node ordering when needed (was: JsonSerialization: Add new :oder JSON array
to transport child node ordering when needed)
JsonSerialization: Add new :order JSON array to transport child node
ordering when needed
---
Key: SLING-2158
URL: https://issues.apache.org/jira/browse/SLING-2158
Project: Sling
Issue Type: New Feature
Components: Servlets
Reporter: Tobias Bocanegra
Priority: Minor
as discussed in:
http://mail-archives.apache.org/mod_mbox/sling-dev/201104.mbox/%3cbanlktimau-cv5fhyyrx-z5ktn4afmfq...@mail.gmail.com%3E
i suggest to add a new array property containing the child node names to the
default JSON renderer if 'requested' with an 'order' selector.
i would include the child node names also on the end of the depth limit. this
allows to get the child node names without the need to load them with a
deeper request:
eg:
GET /content/en.0.order.json would return:
{
title: Hello, world,
:oder: [sub1, sub2]
}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SLING-2141) Add a way to check the referrer for modification requests
[ https://issues.apache.org/jira/browse/SLING-2141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13065985#comment-13065985 ] Tobias Bocanegra commented on SLING-2141: - the localhost check should also include IPv6 address: if ( localhost.equals(host) || 127.0.0.1.equals(host) ) Add a way to check the referrer for modification requests - Key: SLING-2141 URL: https://issues.apache.org/jira/browse/SLING-2141 Project: Sling Issue Type: New Feature Components: Extensions Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Security 1.0.0 To prevent CSRF we could add an additional module which checks the referrer (referer header) in combination with a configurable whitelist. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SLING-1905) Custom LocaleResolver cannot fall back to using the locale from the request's Accept-Language header
[ https://issues.apache.org/jira/browse/SLING-1905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13052839#comment-13052839 ] Tobias Bocanegra commented on SLING-1905: - i don' think that the behavior of request.getLocales() is correct. according to the servlet spec: Returns an Enumeration of Locale objects indicating, in decreasing order starting with the preferred locale, the locales that are acceptable to the client based on the Accept-Language header. If the client request doesn't provide an Accept-Language header, this method returns an Enumeration containing one Locale, the default locale for the server. so the condition that request.getLocale() returns the default one, but request.getLocales() is empty, is invalid. Further the case where a configured localeResolver returns an empty list should be delegated back to the original servlet request - or this behavior should at least be configurable. (can you please clarify or re-open the bug) Custom LocaleResolver cannot fall back to using the locale from the request's Accept-Language header Key: SLING-1905 URL: https://issues.apache.org/jira/browse/SLING-1905 Project: Sling Issue Type: Improvement Components: Extensions Affects Versions: I18n 2.0.4 Reporter: Alexander Klimetschek Assignee: Felix Meschberger Fix For: I18n 2.1.0 It is difficult for a custom LocaleResolver to use the default request locale (based on the HTTP Accept-Language header), because: 1) the I18NFilter passes its own wrapped request object to the LocaleResolver (instead of the original one), resulting in an endless loop if request.getLocales() is used inside the LocaleResolver 2) LocaleResolver.resolveLocale() returns a ListLocale whereas request.getLocales() returns EnumerationLocale, making conversion unnecessarily difficult 3) the default LocaleResolver which uses the original request's getLocale() is not available as a fallback, it is solely used if no custom LocaleResolver is used at all Ideas: 1) could easily be solved by passing this.getSlingRequest() 2) + 3) a public DefaultLocaleResolver class (as base for custom ones) could provide this fallback in its resolveLocale() implementation -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SLING-2082) XSS vulnerability: HtmlResponse output does not escape URLs in HTML
[ https://issues.apache.org/jira/browse/SLING-2082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13051797#comment-13051797 ] Tobias Bocanegra commented on SLING-2082: - the escaping changed the readability of the response, because it now escapes the pre and br tags. which now don't look nice in the browser anymore. the intention of the xhtml response was that it is human and machine readable. further, it alters the DOM of the chagelog entry which might cause backward compatibility. IMO it would be better to only escape the actual changelog entries instead of the entire changelog. eg: tdChangeLog/td tddiv id=ChangeLog lt;pregt;created(/foo.txt);lt;br/gt;created(/bar.txt);lt;br/gt;lt;/pregt; /div/td XSS vulnerability: HtmlResponse output does not escape URLs in HTML --- Key: SLING-2082 URL: https://issues.apache.org/jira/browse/SLING-2082 Project: Sling Issue Type: Bug Components: API, Servlets Affects Versions: Servlets Post 2.1.0, API 2.2.0 Reporter: Alexander Klimetschek Assignee: Bertrand Delacretaz Fix For: Servlets Post 2.1.2, API 2.2.2 A POST request including a script in the URL can lead to execution of that script in the browser: http://localhost:4502/does/not/exist.html/%22%3e%3cscript%3ealert(29679)%3c/script%3e Test with curl: curl -X POST http://localhost:4502/does/not/exist.html/%22%3e%3cscript%3ealert(29679)%3c/script%3e I think this applies to both org/apache/sling/api/servlets/HtmlResponse and org/apache/sling/servlets/post/HtmlResponse, but not sure how to trigger the first one. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (SLING-2090) Simplify deletion of child nodes through the Sling Post Servlet
Simplify deletion of child nodes through the Sling Post Servlet --- Key: SLING-2090 URL: https://issues.apache.org/jira/browse/SLING-2090 Project: Sling Issue Type: Improvement Components: Servlets Affects Versions: Servlets Post 2.1.0 Reporter: Tobias Bocanegra use case is to delete all child nodes of a specific node in one request. currently it's only possible by providing a bunch of :applyTo parameters. would be nice if it supports something like: :applyTo=/content/testnode/*. or even a POST to: /content/testnode/* with an :operation=delete parameter. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (SLING-2074) Defining vanity path to target where user has no read permissions leads to redirect-loop
Defining vanity path to target where user has no read permissions leads to redirect-loop Key: SLING-2074 URL: https://issues.apache.org/jira/browse/SLING-2074 Project: Sling Issue Type: Bug Reporter: Tobias Bocanegra 1. create a resource the anonymous user has no read access. e.g. /secrect/test 2. define a vanity url: path=/test redirect=true 3. request /test as admin - redirect works 4. request /test as anonymous - redirects to /test.html - redirects to /test.html -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (SLING-2049) Wrong URL unescaping
Wrong URL unescaping Key: SLING-2049 URL: https://issues.apache.org/jira/browse/SLING-2049 Project: Sling Issue Type: Bug Reporter: Tobias Bocanegra Priority: Minor there is a difference when requesting with or without an escaped url. for example: curl -v -u admin:admin http://localhost:4502/content/foo test.html ... pThe requested URL /content/foo was not found on this server./p and curl -v -u admin:admin http://localhost:4502/content/foo%20test.html; ... pThe requested URL /content/foo%20test.html was not found on this server./p Expected that the %20 is unescaped before resolved. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (SLING-2049) Wrong URL unescaping
[ https://issues.apache.org/jira/browse/SLING-2049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tobias Bocanegra resolved SLING-2049. - Resolution: Invalid sorry my bad. the %20 actually works. i.e. if there is a resource at /content/foo test it is resolved. the error lies in the servlet container that did not produce the correct url. Wrong URL unescaping Key: SLING-2049 URL: https://issues.apache.org/jira/browse/SLING-2049 Project: Sling Issue Type: Bug Reporter: Tobias Bocanegra Priority: Minor there is a difference when requesting with or without an escaped url. for example: curl -v -u admin:admin http://localhost:4502/content/foo test.html ... pThe requested URL /content/foo was not found on this server./p and curl -v -u admin:admin http://localhost:4502/content/foo%20test.html; ... pThe requested URL /content/foo%20test.html was not found on this server./p Expected that the %20 is unescaped before resolved. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SLING-1897) SlingHttpServletResponseImpl.flushBuffer() does not flush parent response
SlingHttpServletResponseImpl.flushBuffer() does not flush parent response - Key: SLING-1897 URL: https://issues.apache.org/jira/browse/SLING-1897 Project: Sling Issue Type: Bug Components: Engine Affects Versions: Engine 2.1.0 Reporter: Tobias Bocanegra example: slingResponse.setBufferSize(0); slingResponse.getOutputStream().write(123); slingResponse.flushBuffer() does actually bypass the buffer in ContentData, but the flushBuffer is not passed to the wrapped response (neither is setBufferSize()) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-1864) Queue.resume() has no effect
Queue.resume() has no effect
Key: SLING-1864
URL: https://issues.apache.org/jira/browse/SLING-1864
Project: Sling
Issue Type: Bug
Components: Extensions
Reporter: Tobias Bocanegra
Queue.resume() has no effect although the eventing console show it is sleeping.
bug in OrderedJobQueue:
@Override
public void resume() {
if ( this.isSleepingUntil == -1 ) {
final Thread thread = this.sleepingThread;
if ( thread != null ) {
thread.interrupt();
}
}
super.resume();
}
the first if should be:
if ( this.isSleepingUntil != -1 ) {
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1862) Add possibility to get position of a job inside a queue
[ https://issues.apache.org/jira/browse/SLING-1862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12929293#action_12929293 ] Tobias Bocanegra commented on SLING-1862: - for an ordered queue this can easily be implemented using a sequence number for all events. Add possibility to get position of a job inside a queue --- Key: SLING-1862 URL: https://issues.apache.org/jira/browse/SLING-1862 Project: Sling Issue Type: New Feature Components: Extensions Reporter: Tobias Bocanegra would be good, if there was a possibility to determine the position of a job within a queue. something like: int Queue.getPosition(Event) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-1862) Add possibility to get position of a job inside a queue
Add possibility to get position of a job inside a queue --- Key: SLING-1862 URL: https://issues.apache.org/jira/browse/SLING-1862 Project: Sling Issue Type: New Feature Components: Extensions Reporter: Tobias Bocanegra would be good, if there was a possibility to determine the position of a job within a queue. something like: int Queue.getPosition(Event) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-1649) AbstractDispatcherTagHandler should override release() and free resources
AbstractDispatcherTagHandler should override release() and free resources - Key: SLING-1649 URL: https://issues.apache.org/jira/browse/SLING-1649 Project: Sling Issue Type: Bug Components: Scripting Reporter: Tobias Bocanegra Priority: Minor especially: resource see: http://download-llnw.oracle.com/javaee/1.4/api/javax/servlet/jsp/tagext/Tag.html#release() -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1649) AbstractDispatcherTagHandler should override release() and free resources
[ https://issues.apache.org/jira/browse/SLING-1649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12897862#action_12897862 ] Tobias Bocanegra commented on SLING-1649: - not really, just saw some stray resources in a heap dump. especially for JcrResources it might be good not to retain them. AbstractDispatcherTagHandler should override release() and free resources - Key: SLING-1649 URL: https://issues.apache.org/jira/browse/SLING-1649 Project: Sling Issue Type: Bug Components: Scripting Reporter: Tobias Bocanegra Priority: Minor especially: resource see: http://download-llnw.oracle.com/javaee/1.4/api/javax/servlet/jsp/tagext/Tag.html#release() -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1530) Endless iteration in LocationIterator with circular resource super types
[ https://issues.apache.org/jira/browse/SLING-1530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12871756#action_12871756 ] Tobias Bocanegra commented on SLING-1530: - oops. sorry. posting the first issue responded with proxy error, so i though it wasn't created. i should have double checked. Endless iteration in LocationIterator with circular resource super types Key: SLING-1530 URL: https://issues.apache.org/jira/browse/SLING-1530 Project: Sling Issue Type: Bug Components: Servlets Reporter: Tobias Bocanegra If resources build a circular reference by their resource super types, the location iterator produces endless iteration, which results in a endless loop in the servlet resolver. imo the iterator should break if it detects such a circularity. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1529) Endless iteration in LocationIterator with circular resource super types
[ https://issues.apache.org/jira/browse/SLING-1529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12871760#action_12871760 ] Tobias Bocanegra commented on SLING-1529: - use case: resource A with sling:resourceSuperType B resource B with sling:resourceSuperType A request to node C with sling:resourceType A - servlet resolver ends in an endless loop Endless iteration in LocationIterator with circular resource super types Key: SLING-1529 URL: https://issues.apache.org/jira/browse/SLING-1529 Project: Sling Issue Type: Bug Components: Servlets Affects Versions: Servlets Resolver 2.0.8 Reporter: Tobias Bocanegra The location iterator does not detect resource super type circular references and causes script resolution to loop endlessly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-1253) org.apache.sling.jcr.resource.JcrPropertyMap does not expose ValueMap interface
org.apache.sling.jcr.resource.JcrPropertyMap does not expose ValueMap interface --- Key: SLING-1253 URL: https://issues.apache.org/jira/browse/SLING-1253 Project: Sling Issue Type: Bug Components: JCR Environment: using org.apache.sling.jcr.resource of revision R891543 Reporter: Tobias Bocanegra when trying to create a JcrPropertyMap in a jsp i get: An error occurred at line: 1 in the generated java file The type org.apache.sling.jcr.resource.internal.JcrPropertyMap cannot be resolved. It is indirectly referenced from required .class files An error occurred at line: 33 in the jsp file: /apps/foo/center.jsp Type mismatch: cannot convert from JcrPropertyMap to ValueMap null i guess the reason is that only the internal JcrPropertyMap implements the ValueMap interface, but ont the public one. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1178) Preserve request parameter order throughout the entire request stack
[ https://issues.apache.org/jira/browse/SLING-1178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12776384#action_12776384 ] Tobias Bocanegra commented on SLING-1178: - ok. i agree that the servlet spec does not define the order of the request parameters. however, multipart/form-data does: http://www.w3.org/TR/html401/interact/forms.html, 17.13.4 Form content types ... A multipart/form-data message contains a series of parts, each representing a successful control. The parts are sent to the processing agent in the same order the corresponding controls appear in the document stream. Part boundaries should not occur in any of the data; how this is done lies outside the scope of this specification. ... and since a multipart-post is also exposed via the request parameter map, i have no possibility to decompose the multipart post myself if i want to preserve the order of the parameters (parts). Preserve request parameter order throughout the entire request stack Key: SLING-1178 URL: https://issues.apache.org/jira/browse/SLING-1178 Project: Sling Issue Type: Improvement Components: Engine, Servlets Affects Versions: Servlets Post 2.0.4, Engine 2.0.6 Reporter: Tobias Bocanegra Priority: Minor Attachments: ordered_params-r834673.patch When posting a form to the sling post servlet i encountered that the order of the request parameters is not preserved, even the browser sends the params according to the submitted form. for example the following form: form name=input action=/content/testform method=POST input type=hidden name=./sen...@delete/br/ Address 0: input type=text name=./sendTo/0/address /br/ Text 0: input type=text name=./sendTo/0/text /br/ Address 1: input type=text name=./sendTo/1/address /br/ Text 1: input type=text name=./sendTo/1/text /br/ Address 2: input type=text name=./sendTo/2/address /br/ Text 2: input type=text name=./sendTo/2/text /br/ input type=submit value=Submit / /form results in: deleted(/content/testform/sendTo); created(/content/testform/sendTo); created(/content/testform/sendTo/2); modified(/content/testform/sendTo/2/address); modified(/content/testform/sendTo/2/text); created(/content/testform/sendTo/1); modified(/content/testform/sendTo/1/text); created(/content/testform/sendTo/0); modified(/content/testform/sendTo/0/text); modified(/content/testform/sendTo/0/address); modified(/content/testform/sendTo/1/address); i first thought it's just the ModifyOperation which uses a HashMap instead of a LinkedHashMap: MapString, RequestProperty reqProperties = new HashMapString, RequestProperty(); but the params arrive out of order already from the request.getParameterMap(). i guess the ParameterMap needs to extend from LinkedHashMap, too: class ParameterMap extends LinkedHashMapString, RequestParameter[] ... after fixing those 2 classes, the order is correct: deleted(/content/testform/sendTo); created(/content/testform/sendTo); created(/content/testform/sendTo/0); modified(/content/testform/sendTo/0/address); modified(/content/testform/sendTo/0/text); created(/content/testform/sendTo/1); modified(/content/testform/sendTo/1/address); modified(/content/testform/sendTo/1/text); created(/content/testform/sendTo/2); modified(/content/testform/sendTo/2/address); modified(/content/testform/sendTo/2/text); i'll attach the patch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-1178) Preserve request parameter order throughout the entire request stack
Preserve request parameter order throughout the entire request stack Key: SLING-1178 URL: https://issues.apache.org/jira/browse/SLING-1178 Project: Sling Issue Type: Improvement Components: Engine, Servlets Affects Versions: Engine 2.0.6, Servlets Post 2.0.4 Reporter: Tobias Bocanegra Priority: Minor Attachments: ordered_params-r834673.patch When posting a form to the sling post servlet i encountered that the order of the request parameters is not preserved, even the browser sends the params according to the submitted form. for example the following form: form name=input action=/content/testform method=POST input type=hidden name=./sen...@delete/br/ Address 0: input type=text name=./sendTo/0/address /br/ Text 0: input type=text name=./sendTo/0/text /br/ Address 1: input type=text name=./sendTo/1/address /br/ Text 1: input type=text name=./sendTo/1/text /br/ Address 2: input type=text name=./sendTo/2/address /br/ Text 2: input type=text name=./sendTo/2/text /br/ input type=submit value=Submit / /form results in: deleted(/content/testform/sendTo); created(/content/testform/sendTo); created(/content/testform/sendTo/2); modified(/content/testform/sendTo/2/address); modified(/content/testform/sendTo/2/text); created(/content/testform/sendTo/1); modified(/content/testform/sendTo/1/text); created(/content/testform/sendTo/0); modified(/content/testform/sendTo/0/text); modified(/content/testform/sendTo/0/address); modified(/content/testform/sendTo/1/address); i first thought it's just the ModifyOperation which uses a HashMap instead of a LinkedHashMap: MapString, RequestProperty reqProperties = new HashMapString, RequestProperty(); but the params arrive out of order already from the request.getParameterMap(). i guess the ParameterMap needs to extend from LinkedHashMap, too: class ParameterMap extends LinkedHashMapString, RequestParameter[] ... after fixing those 2 classes, the order is correct: deleted(/content/testform/sendTo); created(/content/testform/sendTo); created(/content/testform/sendTo/0); modified(/content/testform/sendTo/0/address); modified(/content/testform/sendTo/0/text); created(/content/testform/sendTo/1); modified(/content/testform/sendTo/1/address); modified(/content/testform/sendTo/1/text); created(/content/testform/sendTo/2); modified(/content/testform/sendTo/2/address); modified(/content/testform/sendTo/2/text); i'll attach the patch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-1178) Preserve request parameter order throughout the entire request stack
[ https://issues.apache.org/jira/browse/SLING-1178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tobias Bocanegra updated SLING-1178: Attachment: ordered_params-r834673.patch patch that solves this issue Preserve request parameter order throughout the entire request stack Key: SLING-1178 URL: https://issues.apache.org/jira/browse/SLING-1178 Project: Sling Issue Type: Improvement Components: Engine, Servlets Affects Versions: Servlets Post 2.0.4, Engine 2.0.6 Reporter: Tobias Bocanegra Priority: Minor Attachments: ordered_params-r834673.patch When posting a form to the sling post servlet i encountered that the order of the request parameters is not preserved, even the browser sends the params according to the submitted form. for example the following form: form name=input action=/content/testform method=POST input type=hidden name=./sen...@delete/br/ Address 0: input type=text name=./sendTo/0/address /br/ Text 0: input type=text name=./sendTo/0/text /br/ Address 1: input type=text name=./sendTo/1/address /br/ Text 1: input type=text name=./sendTo/1/text /br/ Address 2: input type=text name=./sendTo/2/address /br/ Text 2: input type=text name=./sendTo/2/text /br/ input type=submit value=Submit / /form results in: deleted(/content/testform/sendTo); created(/content/testform/sendTo); created(/content/testform/sendTo/2); modified(/content/testform/sendTo/2/address); modified(/content/testform/sendTo/2/text); created(/content/testform/sendTo/1); modified(/content/testform/sendTo/1/text); created(/content/testform/sendTo/0); modified(/content/testform/sendTo/0/text); modified(/content/testform/sendTo/0/address); modified(/content/testform/sendTo/1/address); i first thought it's just the ModifyOperation which uses a HashMap instead of a LinkedHashMap: MapString, RequestProperty reqProperties = new HashMapString, RequestProperty(); but the params arrive out of order already from the request.getParameterMap(). i guess the ParameterMap needs to extend from LinkedHashMap, too: class ParameterMap extends LinkedHashMapString, RequestParameter[] ... after fixing those 2 classes, the order is correct: deleted(/content/testform/sendTo); created(/content/testform/sendTo); created(/content/testform/sendTo/0); modified(/content/testform/sendTo/0/address); modified(/content/testform/sendTo/0/text); created(/content/testform/sendTo/1); modified(/content/testform/sendTo/1/address); modified(/content/testform/sendTo/1/text); created(/content/testform/sendTo/2); modified(/content/testform/sendTo/2/address); modified(/content/testform/sendTo/2/text); i'll attach the patch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
