Re: Download of latest snaapshot version Sling Standalone and WebApp
Any pointers? Chetan Mehrotra On Wed, Feb 20, 2013 at 3:45 PM, Chetan Mehrotra chetan.mehro...@gmail.comwrote: I tried to build the latest code from launchpad/builder but it fails due to missing dependencies [1] of some snapshot dependencies. If I check the respective bundle pom it appears that the bundles have been released but the list.xml has not been updated. So before I try to track them and get a latest build running locally wanted to check if the snapshot build of main standalone jar is pushed to some maven repo Chetan Mehrotra [1] [ERROR] Failed to execute goal on project org.apache.sling.launchpad: Could not resolve dependencies for project org.apache.sling:org.apache.sling.launchpad:war:7-SNAPSHOT: The following artifacts could not be resolved: org.apache.sling:org.apache.sling.jcr.resource:jar:2.2.3-SNAPSHOT, org.apache.sling:org.apache.sling.jcr.classloader:jar:3.1.11-SNAPSHOT, org.apache.sling:org.apache.sling.scripting.jsp:jar:2.0.27-SNAPSHOT: Could not find artifact org.apache.sling:org.apache.sling.jcr.resource:jar:2.2.3-SNAPSHOT in apache.snapshots (http://repository.apache.org/snapshots) - [Help 1] [ERROR]
Re: Download of latest snaapshot version Sling Standalone and WebApp
Hi, I think our CI build should push the artifacts to the snapshot repo, but I wouldn't rely on that. The current trunk should build fine, the bundle list should either point to releases or to the current snapshot versions. If that's not the case, this is a bug :) Carsten 2013/2/21 Chetan Mehrotra chetan.mehro...@gmail.com: Any pointers? Chetan Mehrotra On Wed, Feb 20, 2013 at 3:45 PM, Chetan Mehrotra chetan.mehro...@gmail.comwrote: I tried to build the latest code from launchpad/builder but it fails due to missing dependencies [1] of some snapshot dependencies. If I check the respective bundle pom it appears that the bundles have been released but the list.xml has not been updated. So before I try to track them and get a latest build running locally wanted to check if the snapshot build of main standalone jar is pushed to some maven repo Chetan Mehrotra [1] [ERROR] Failed to execute goal on project org.apache.sling.launchpad: Could not resolve dependencies for project org.apache.sling:org.apache.sling.launchpad:war:7-SNAPSHOT: The following artifacts could not be resolved: org.apache.sling:org.apache.sling.jcr.resource:jar:2.2.3-SNAPSHOT, org.apache.sling:org.apache.sling.jcr.classloader:jar:3.1.11-SNAPSHOT, org.apache.sling:org.apache.sling.scripting.jsp:jar:2.0.27-SNAPSHOT: Could not find artifact org.apache.sling:org.apache.sling.jcr.resource:jar:2.2.3-SNAPSHOT in apache.snapshots (http://repository.apache.org/snapshots) - [Help 1] [ERROR] -- Carsten Ziegeler cziege...@apache.org
Re: animal sniffer check failure
Which java version do you use to build? OS? Where does the problem occur? I haven't seen this problem so far (OS X, Java 6) - except for the commons classloader where we did some magic with the test case and java 6. Carsten 2013/2/21 Ian Boston i...@tfd.co.uk: Hi, I am getting ERROR] Failed to execute goal org.codehaus.mojo:animal-sniffer-maven-plugin:1.9:check (default) on project org.apache.sling.event: Execution default of goal org.codehaus.mojo:animal-sniffer-maven-plugin:1.9:check failed: An API incompatibility was encountered while executing org.codehaus.mojo:animal-sniffer-maven-plugin:1.9:check: java.lang.NoSuchMethodError: java.nio.CharBuffer.subSequence(II)Ljava/nio/CharBuffer; [ERROR] - I think is due to a dependency rather (mockito) than the code since indicating JDK 1.6 eliminated the problem. (-Dsling.java.version=6) Going all the way back to mockito 1.8.0 doesn't fix the issue. Has anyone else seen the same problem ? Ian -- Carsten Ziegeler cziege...@apache.org
[jira] [Commented] (SLING-2710) Define TenantManager API
[
https://issues.apache.org/jira/browse/SLING-2710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13583065#comment-13583065
]
Felix Meschberger commented on SLING-2710:
--
Thanks for the feedback. Very appreciated !
addPermissions
I understand that there would be a need to manage permissions. I also agree
with Timothee that this is probably a specific use case. Finally I think this
can be solved by a TenantCustomizer.
removeProperty
While a property can be removed as a side effect with setProperty I agree that
from a orthogonality perspective this might make sense. How about a
removeProperties(Tentant, String...)
method ?
Define TenantManager API
Key: SLING-2710
URL: https://issues.apache.org/jira/browse/SLING-2710
Project: Sling
Issue Type: New Feature
Components: Extensions
Reporter: Felix Meschberger
Fix For: Tenant 1.0
Attachments: SLING-2710.patch
Tenants currently can only be administered (create, update, remove) through
the Web Console. In addition the TenantProvider service interface allows for
looking tenants up (read).
For administrative purposes it would be good to have a TenantManager service
interface which allows for these administrative tasks. Something like:
public interface TenantManager extends TenantProvider {
Tenant create(String tenantId, MapString, Object properties);
void setProperty(Tenant tenant, String name, Object value);
void remove(Tenant tenant);
}
--
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-2710) Define TenantManager API
[
https://issues.apache.org/jira/browse/SLING-2710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Felix Meschberger updated SLING-2710:
-
Attachment: SLING-2710-2.patch
Updated patch with removeProperties method.
Define TenantManager API
Key: SLING-2710
URL: https://issues.apache.org/jira/browse/SLING-2710
Project: Sling
Issue Type: New Feature
Components: Extensions
Reporter: Felix Meschberger
Fix For: Tenant 1.0
Attachments: SLING-2710-2.patch, SLING-2710.patch
Tenants currently can only be administered (create, update, remove) through
the Web Console. In addition the TenantProvider service interface allows for
looking tenants up (read).
For administrative purposes it would be good to have a TenantManager service
interface which allows for these administrative tasks. Something like:
public interface TenantManager extends TenantProvider {
Tenant create(String tenantId, MapString, Object properties);
void setProperty(Tenant tenant, String name, Object value);
void remove(Tenant tenant);
}
--
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
TenantManager API
Hi SLING-2710 [1] proposes the addition of a TenantManager service interface. Thanks for the comments so far. One question that came up in the issue is whether the TenantManager should extend the TenantProvider or not. I am a bit undecided: On the one hand I think that the TenantManager is not a TenantProvider. Also by not extending the TenantProvider the implementation has more freedom and it forces proper access to the service. On the other hand, for administrative tools really using the TenantManager having it extend the TenantProvider might make the code simpler (only one service to get instead of two). WDYT ? Regards Felix [1] https://issues.apache.org/jira/browse/SLING-2710
[jira] [Updated] (SLING-1605) Update documentation
[ https://issues.apache.org/jira/browse/SLING-1605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated SLING-1605: Fix Version/s: (was: Launchpad Base 2.4.0) Launchpad Base 2.5.2 Update documentation Key: SLING-1605 URL: https://issues.apache.org/jira/browse/SLING-1605 Project: Sling Issue Type: Task Components: Launchpad Reporter: Carsten Ziegeler Fix For: Launchpad Base 2.5.2 When releasing version 2.1.0 and 2.2.0 we left some tasks open to be documented: SLING-1157 SLING-922 SLING-1200 SLING-1189 SLING-1443 -- 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-1958) Replace system package export of select XML API packages by bundles
[ https://issues.apache.org/jira/browse/SLING-1958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated SLING-1958: Fix Version/s: (was: Launchpad Base 2.4.0) Launchpad Base 2.5.0 Replace system package export of select XML API packages by bundles --- Key: SLING-1958 URL: https://issues.apache.org/jira/browse/SLING-1958 Project: Sling Issue Type: Improvement Components: Launchpad Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: Launchpad Builder 7, Launchpad Base 2.5.0 Attachments: SLING-1958.patch As discussed on the dev list [1] I propose to change the approach to supporting XML in Sling as follows: - Remove javax.xml.*, org.w3c.*, and org.xml.sax* packages covered by JAX-P from the System bundle exports (that is the jre-1.6 and jre-1.5 properties in the default sling properties) -- Change in the default sling.properties in Launchpad Base - Add the following bundles to the default Sling Build - org.apache.servicemix.specs.jaxp-api-1.3, 1.7.0 - org.apache.servicemix.bundles.xerces, 2.9.1.4 - org.apache.servicemix.bundles.xmlresolver, 1.2.0.3 -- Change to the list.xml in Launchpad Builder Will attach a patch to this issue for feedback. [1] http://markmail.org/message/2fk73koxf4ihjihm -- 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-1958) Replace system package export of select XML API packages by bundles
[ https://issues.apache.org/jira/browse/SLING-1958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13583092#comment-13583092 ] Carsten Ziegeler commented on SLING-1958: - So we can resolve this? Replace system package export of select XML API packages by bundles --- Key: SLING-1958 URL: https://issues.apache.org/jira/browse/SLING-1958 Project: Sling Issue Type: Improvement Components: Launchpad Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: Launchpad Builder 7, Launchpad Base 2.5.0 Attachments: SLING-1958.patch As discussed on the dev list [1] I propose to change the approach to supporting XML in Sling as follows: - Remove javax.xml.*, org.w3c.*, and org.xml.sax* packages covered by JAX-P from the System bundle exports (that is the jre-1.6 and jre-1.5 properties in the default sling properties) -- Change in the default sling.properties in Launchpad Base - Add the following bundles to the default Sling Build - org.apache.servicemix.specs.jaxp-api-1.3, 1.7.0 - org.apache.servicemix.bundles.xerces, 2.9.1.4 - org.apache.servicemix.bundles.xmlresolver, 1.2.0.3 -- Change to the list.xml in Launchpad Builder Will attach a patch to this issue for feedback. [1] http://markmail.org/message/2fk73koxf4ihjihm -- 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-2736) Not able to build the launchpad/builder module
Chetan Mehrotra created SLING-2736: -- Summary: Not able to build the launchpad/builder module Key: SLING-2736 URL: https://issues.apache.org/jira/browse/SLING-2736 Project: Sling Issue Type: Bug Components: Launchpad Reporter: Chetan Mehrotra Priority: Minor While trying to just build the latest snapshot of Sling war/app from launchpad/builder the build fails with following error == [ERROR] Failed to execute goal on project org.apache.sling.launchpad: Could not resolve dependencies for project org.apache.sling:org.apache.sling.launchpad:war:7-SNAPSHOT: The following artifacts could not be resolved: org.apache.sling:org.apache.sling.resourceresolver:jar:1.0.3-SNAPSHOT, org.apache.sling:org.apache.sling.jcr.resource:jar:2.2.3-SNAPSHOT, org.apache.sling:org.apache.sling.jcr.classloader:jar:3.1.11-SNAPSHOT, org.apache.sling:org.apache.sling.scripting.jsp:jar:2.0.27-SNAPSHOT: Could not find artifact org.apache.sling:org.apache.sling.resourceresolver:jar:1.0.3-SNAPSHOT in apache.snapshots (http://repository.apache.org/snapshots) === Note that I have not build the complete Sling trunk but I expect the builder build to fetch dependent module snapshots from Apache maven repo. -- 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-2736) Not able to build the launchpad/builder module
[ https://issues.apache.org/jira/browse/SLING-2736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13583103#comment-13583103 ] Chetan Mehrotra commented on SLING-2736: Looks like there is some issue with the Git mirrors as the code there does not reflect the current codebase. Checking the list.xml from [1] and [2] reveal that [2] is quite stale (last change 13 days older). I also checked from apache git [3] and it also has stale files Also if someone just wants to grab the latest build from Apache Maven repo use following url https://repository.apache.org/service/local/artifact/maven/content?g=org.apache.slinga=org.apache.sling.launchpadv=7-SNAPSHOTe=warr=snapshots Build works fine now with svn checkout. The bug can be closed [1] http://svn.apache.org/viewvc/sling/trunk/launchpad/builder/src/main/bundles/list.xml?view=markup [2] https://github.com/apache/sling/blob/trunk/launchpad/builder/src/main/bundles/list.xml [3] http://git.apache.org/sling.git Not able to build the launchpad/builder module --- Key: SLING-2736 URL: https://issues.apache.org/jira/browse/SLING-2736 Project: Sling Issue Type: Bug Components: Launchpad Reporter: Chetan Mehrotra Priority: Minor While trying to just build the latest snapshot of Sling war/app from launchpad/builder the build fails with following error == [ERROR] Failed to execute goal on project org.apache.sling.launchpad: Could not resolve dependencies for project org.apache.sling:org.apache.sling.launchpad:war:7-SNAPSHOT: The following artifacts could not be resolved: org.apache.sling:org.apache.sling.resourceresolver:jar:1.0.3-SNAPSHOT, org.apache.sling:org.apache.sling.jcr.resource:jar:2.2.3-SNAPSHOT, org.apache.sling:org.apache.sling.jcr.classloader:jar:3.1.11-SNAPSHOT, org.apache.sling:org.apache.sling.scripting.jsp:jar:2.0.27-SNAPSHOT: Could not find artifact org.apache.sling:org.apache.sling.resourceresolver:jar:1.0.3-SNAPSHOT in apache.snapshots (http://repository.apache.org/snapshots) === Note that I have not build the complete Sling trunk but I expect the builder build to fetch dependent module snapshots from Apache maven repo. -- 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
Re: Download of latest snaapshot version Sling Standalone and WebApp
Looks like its a false alarm because code in Git mirrors are stale and not reflect the current code in svn (see SLING-2736) Also one can download it from Apache Maven repo via https://repository.apache.org/service/local/artifact/maven/content?g=org.apache.slinga=org.apache.sling.launchpadv=7-SNAPSHOTe=warr=snapshots Sorry for the noise Chetan Mehrotra On Thu, Feb 21, 2013 at 3:14 PM, Carsten Ziegeler cziege...@apache.orgwrote: Hi, I think our CI build should push the artifacts to the snapshot repo, but I wouldn't rely on that. The current trunk should build fine, the bundle list should either point to releases or to the current snapshot versions. If that's not the case, this is a bug :) Carsten 2013/2/21 Chetan Mehrotra chetan.mehro...@gmail.com: Any pointers? Chetan Mehrotra On Wed, Feb 20, 2013 at 3:45 PM, Chetan Mehrotra chetan.mehro...@gmail.comwrote: I tried to build the latest code from launchpad/builder but it fails due to missing dependencies [1] of some snapshot dependencies. If I check the respective bundle pom it appears that the bundles have been released but the list.xml has not been updated. So before I try to track them and get a latest build running locally wanted to check if the snapshot build of main standalone jar is pushed to some maven repo Chetan Mehrotra [1] [ERROR] Failed to execute goal on project org.apache.sling.launchpad: Could not resolve dependencies for project org.apache.sling:org.apache.sling.launchpad:war:7-SNAPSHOT: The following artifacts could not be resolved: org.apache.sling:org.apache.sling.jcr.resource:jar:2.2.3-SNAPSHOT, org.apache.sling:org.apache.sling.jcr.classloader:jar:3.1.11-SNAPSHOT, org.apache.sling:org.apache.sling.scripting.jsp:jar:2.0.27-SNAPSHOT: Could not find artifact org.apache.sling:org.apache.sling.jcr.resource:jar:2.2.3-SNAPSHOT in apache.snapshots (http://repository.apache.org/snapshots) - [Help 1] [ERROR] -- Carsten Ziegeler cziege...@apache.org
[jira] [Resolved] (SLING-2736) Not able to build the launchpad/builder module
[ https://issues.apache.org/jira/browse/SLING-2736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra resolved SLING-2736. Resolution: Not A Problem Problem with Git mirrors as noted above. Hence not a problem with current code Not able to build the launchpad/builder module --- Key: SLING-2736 URL: https://issues.apache.org/jira/browse/SLING-2736 Project: Sling Issue Type: Bug Components: Launchpad Reporter: Chetan Mehrotra Priority: Minor While trying to just build the latest snapshot of Sling war/app from launchpad/builder the build fails with following error == [ERROR] Failed to execute goal on project org.apache.sling.launchpad: Could not resolve dependencies for project org.apache.sling:org.apache.sling.launchpad:war:7-SNAPSHOT: The following artifacts could not be resolved: org.apache.sling:org.apache.sling.resourceresolver:jar:1.0.3-SNAPSHOT, org.apache.sling:org.apache.sling.jcr.resource:jar:2.2.3-SNAPSHOT, org.apache.sling:org.apache.sling.jcr.classloader:jar:3.1.11-SNAPSHOT, org.apache.sling:org.apache.sling.scripting.jsp:jar:2.0.27-SNAPSHOT: Could not find artifact org.apache.sling:org.apache.sling.resourceresolver:jar:1.0.3-SNAPSHOT in apache.snapshots (http://repository.apache.org/snapshots) === Note that I have not build the complete Sling trunk but I expect the builder build to fetch dependent module snapshots from Apache maven repo. -- 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] [Deleted] (SLING-2737) Add support for war files in BootstrapInstaller
[ https://issues.apache.org/jira/browse/SLING-2737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler deleted SLING-2737: Add support for war files in BootstrapInstaller --- Key: SLING-2737 URL: https://issues.apache.org/jira/browse/SLING-2737 Project: Sling Issue Type: Improvement Reporter: Justin Edelson Assignee: Felix Meschberger BootstrapInstaller only picks up .jar files in the bundles directory. This patch adds support for war files. -- 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-1200) Restart framework if BootstrapInstaller updates a framework extension fragment bundle
[ https://issues.apache.org/jira/browse/SLING-1200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated SLING-1200: Assignee: Carsten Ziegeler (was: Felix Meschberger) Restart framework if BootstrapInstaller updates a framework extension fragment bundle - Key: SLING-1200 URL: https://issues.apache.org/jira/browse/SLING-1200 Project: Sling Issue Type: Improvement Components: Launchpad Affects Versions: Launchpad Base 2.0.4 Reporter: Felix Meschberger Assignee: Carsten Ziegeler Fix For: Launchpad Base 2.1.0 The spec mandates that updating a framework extension (fragment) bundle requires a framework restart for the updated framework extension to become active. If the Sling Launchpad BootstrappInstaller updates such a bundle it would be good to automatically restart the framework after such an update to actually activate this update. -- 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] [Assigned] (SLING-1200) Restart framework if BootstrapInstaller updates a framework extension fragment bundle
[ https://issues.apache.org/jira/browse/SLING-1200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler reassigned SLING-1200: --- Assignee: Felix Meschberger (was: Carsten Ziegeler) Restart framework if BootstrapInstaller updates a framework extension fragment bundle - Key: SLING-1200 URL: https://issues.apache.org/jira/browse/SLING-1200 Project: Sling Issue Type: Improvement Components: Launchpad Affects Versions: Launchpad Base 2.0.4 Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: Launchpad Base 2.1.0 The spec mandates that updating a framework extension (fragment) bundle requires a framework restart for the updated framework extension to become active. If the Sling Launchpad BootstrappInstaller updates such a bundle it would be good to automatically restart the framework after such an update to actually activate this update. -- 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-2737) Add support for war files in BootstrapInstaller
Carsten Ziegeler created SLING-2737: --- Summary: Add support for war files in BootstrapInstaller Key: SLING-2737 URL: https://issues.apache.org/jira/browse/SLING-2737 Project: Sling Issue Type: Improvement Components: Launchpad Affects Versions: Launchpad Base 2.1.0 Reporter: Justin Edelson Assignee: Felix Meschberger Fix For: Launchpad Base 2.1.0 BootstrapInstaller only picks up .jar files in the bundles directory. This patch adds support for war files. -- 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
RE: Vanity Path query
Hi, Does changing FROM sling:VanityPath to FROM nt:base have any noticeable impact on performance or cost of the query ? Ian probably not. it might even be a bit faster because the query does not have to filter by node type. regards marcel
RE: Vanity Path query
one more thing to consider... while it probably won't have that much of an impact with Jackrabbit 2.x the situation is different with Jackrabbit Oak. Oak currently comes with default indexes for jcr:primaryType and jcr:mixinTypes. If you now turn your query into 'FROM nt:base' Oak won't be able to leverage those indexes and the query will be terribly inefficient. You will have to add an index on sling:vanityPath to make if efficient again. regards marcel -Original Message- From: Marcel Reutegger [mailto:mreut...@adobe.com] Sent: Donnerstag, 21. Februar 2013 12:53 To: dev@sling.apache.org Subject: RE: Vanity Path query Hi, Does changing FROM sling:VanityPath to FROM nt:base have any noticeable impact on performance or cost of the query ? Ian probably not. it might even be a bit faster because the query does not have to filter by node type. regards marcel
Launchpad Base Release?
Hi, I'm wondering if we should cut a new launchpad base release, now that we have updated to the new felix framework version? Regards Carsten -- Carsten Ziegeler cziege...@apache.org
[jira] [Assigned] (SLING-2730) Allow JSPs to be excluded from compilation in maven-jspc-plugin
[ https://issues.apache.org/jira/browse/SLING-2730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler reassigned SLING-2730: --- Assignee: Carsten Ziegeler Allow JSPs to be excluded from compilation in maven-jspc-plugin --- Key: SLING-2730 URL: https://issues.apache.org/jira/browse/SLING-2730 Project: Sling Issue Type: Improvement Components: Maven Plugins and Archetypes Affects Versions: Maven JSPC Plugin 2.0.6 Reporter: Ben Peter Assignee: Carsten Ziegeler Priority: Minor Attachments: SLING-2730.patch JSPs may contain symbols that are declared not in the JSP itself, but in a JSP that includes it (although that may be considered bad style). including.jsp: %String foo = bar; % %@include file=included.jsp % included.jsp: %= foo % The result is that such a JSP does not compile on its own and the goal will fail. This can be circumvented if individual JSPs can be excluded from compilation. Excluding them from the resources to start with does not help, as they are still required for the including JSPs to compile. -- 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] [Assigned] (SLING-2724) Error handling doesn't respect servlet spec
[ https://issues.apache.org/jira/browse/SLING-2724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler reassigned SLING-2724: --- Assignee: Carsten Ziegeler Error handling doesn't respect servlet spec --- Key: SLING-2724 URL: https://issues.apache.org/jira/browse/SLING-2724 Project: Sling Issue Type: Bug Components: Servlets Reporter: Antonio Sanso Assignee: Carsten Ziegeler If there is some servlet that is sending a 500 error (response.sendError(500)) and output something after e.g. All good (maybe this is the wrong part...) and a 500.jsp exists, Sling will shows both: - the error page 500.jsp - and the the extra output (e.g. All good) This seems to violate the spec: These methods [sendError, sendRedirect] will have the side effect of committing the response, if it has not already been committed, and terminating it. No further output to the client should be made by the servlet after these methods are called. If data is written to the response after these methods are called, the data is ignored. Integration test showing the issue in [0] Mailing list thread in [1] [0] https://svn.apache.org/repos/asf/sling/trunk/launchpad/integration-tests/src/main/java/org/apache/sling/launchpad/webapp/integrationtest/servlets/resolver/errorhandler/ErrorHandlingTest.java [1] sling.markmail.org/thread/k2t7p5mhi4hgelwb -- 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] [Resolved] (SLING-1958) Replace system package export of select XML API packages by bundles
[ https://issues.apache.org/jira/browse/SLING-1958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger resolved SLING-1958. -- Resolution: Fixed I think this can be resolved: The exports are not in the default system exports any longer and we include the fragements in the bundle list. Replace system package export of select XML API packages by bundles --- Key: SLING-1958 URL: https://issues.apache.org/jira/browse/SLING-1958 Project: Sling Issue Type: Improvement Components: Launchpad Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: Launchpad Builder 7, Launchpad Base 2.5.0 Attachments: SLING-1958.patch As discussed on the dev list [1] I propose to change the approach to supporting XML in Sling as follows: - Remove javax.xml.*, org.w3c.*, and org.xml.sax* packages covered by JAX-P from the System bundle exports (that is the jre-1.6 and jre-1.5 properties in the default sling properties) -- Change in the default sling.properties in Launchpad Base - Add the following bundles to the default Sling Build - org.apache.servicemix.specs.jaxp-api-1.3, 1.7.0 - org.apache.servicemix.bundles.xerces, 2.9.1.4 - org.apache.servicemix.bundles.xmlresolver, 1.2.0.3 -- Change to the list.xml in Launchpad Builder Will attach a patch to this issue for feedback. [1] http://markmail.org/message/2fk73koxf4ihjihm -- 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
Re: Vanity Path query
Hi You mean property exists querying will be slow out of the box ? What does slow mean compared to Jackrabbit 2.x ? Regards Felix Am 21.02.2013 um 12:57 schrieb Marcel Reutegger: one more thing to consider... while it probably won't have that much of an impact with Jackrabbit 2.x the situation is different with Jackrabbit Oak. Oak currently comes with default indexes for jcr:primaryType and jcr:mixinTypes. If you now turn your query into 'FROM nt:base' Oak won't be able to leverage those indexes and the query will be terribly inefficient. You will have to add an index on sling:vanityPath to make if efficient again. regards marcel -Original Message- From: Marcel Reutegger [mailto:mreut...@adobe.com] Sent: Donnerstag, 21. Februar 2013 12:53 To: dev@sling.apache.org Subject: RE: Vanity Path query Hi, Does changing FROM sling:VanityPath to FROM nt:base have any noticeable impact on performance or cost of the query ? Ian probably not. it might even be a bit faster because the query does not have to filter by node type. regards marcel -- Felix Meschberger | Principal Scientist | Adobe
[jira] [Created] (SLING-2738) Log an error if multipart POST request parsing fails
Felix Meschberger created SLING-2738: Summary: Log an error if multipart POST request parsing fails Key: SLING-2738 URL: https://issues.apache.org/jira/browse/SLING-2738 Project: Sling Issue Type: Improvement Components: Engine Affects Versions: Engine 2.2.6 Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: Engine 2.2.8 The Sling Engine supports parsing multipart/form-data POST requests using the Commons FileUpload library. The ParametersSupport.parseMultiPartPost method which causes this parsing catches but does not log any errors parsing the request. Such exceptions (while rare but just occurred in our application with a client-fabricated POST request) are rare but they should be logged nevertheless. -- 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] [Resolved] (SLING-2738) Log an error if multipart POST request parsing fails
[ https://issues.apache.org/jira/browse/SLING-2738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger resolved SLING-2738. -- Resolution: Fixed Logging an error message now in case of request parsing (Rev. 1448641) Log an error if multipart POST request parsing fails Key: SLING-2738 URL: https://issues.apache.org/jira/browse/SLING-2738 Project: Sling Issue Type: Improvement Components: Engine Affects Versions: Engine 2.2.6 Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: Engine 2.2.8 The Sling Engine supports parsing multipart/form-data POST requests using the Commons FileUpload library. The ParametersSupport.parseMultiPartPost method which causes this parsing catches but does not log any errors parsing the request. Such exceptions (while rare but just occurred in our application with a client-fabricated POST request) are rare but they should be logged nevertheless. -- 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
Re: Launchpad Base Release?
+1 Will you do the release ? Regards Felix Am 21.02.2013 um 13:03 schrieb Carsten Ziegeler: Hi, I'm wondering if we should cut a new launchpad base release, now that we have updated to the new felix framework version? Regards Carsten -- Carsten Ziegeler cziege...@apache.org -- Felix Meschberger | Principal Scientist | Adobe
Re: [RT] Accessing the resource type hierarchy
On 21.02.2013, at 13:49, Carsten Ziegeler cziege...@apache.org wrote: I think we should rather add two methods to the resource resolver: isA(Resource, String) and getEffectiveSuperType(Resource) - these methods will be implemented by the resource resolver and use a session which has read access to the whole tree (it could also cache the hierarchy if required). Big +1 Cheers, Alex
Re: Launchpad Base Release?
Yepp, I plan to cut it early next week Carsten 2013/2/21 Felix Meschberger fmesc...@adobe.com: +1 Will you do the release ? Regards Felix Am 21.02.2013 um 13:03 schrieb Carsten Ziegeler: Hi, I'm wondering if we should cut a new launchpad base release, now that we have updated to the new felix framework version? Regards Carsten -- Carsten Ziegeler cziege...@apache.org -- Felix Meschberger | Principal Scientist | Adobe -- Carsten Ziegeler cziege...@apache.org
Re: [RT] Accessing the resource type hierarchy
Hi Carsten Thanks for taking this issue up. It has been nagging us for too long ;-) I agree, that we should handle this centrally with an administrative resource resolver. So maybe the obvious solution is really to do it in the ResourceResolver itself. We should thus deprecate the ResourceUtil.isA method while the Resource.isResourceType method should stay (is easy to use if you already have the Resource) but should this be implemented with the new method. Why getEffectiveSuperType instead if getSuperType ? Regards Felix Am 21.02.2013 um 13:49 schrieb Carsten Ziegeler: Hi, looking again at SLING-2708, I think we have a fundamental misconception in the way we treat the resource type hierarchy. This affects the isA check and the detection of the effective resource super type by looking at the resource tree. In early Sling versions we used the current resource resolver (session) in the implementation of those functions, but as soon as the resource resolver did not have read access to the search paths in the resource tree, these checks failed. After hitting this problem, we implemented the isA check by implementing a resource decorator in the Sling Servlet Resolver (SLING-2693). The idea was to use the same user as we use to resolve scripts. With SLING-2708 we hit another area where this problem occurs. Now, looking back, I think the solution of SLING-2693 is wrong - the resource type hierarchy has nothing to do with execution rights and is completely independent from executing scripts. I think we should rather add two methods to the resource resolver: isA(Resource, String) and getEffectiveSuperType(Resource) - these methods will be implemented by the resource resolver and use a session which has read access to the whole tree (it could also cache the hierarchy if required). With this we have a central implementation at a convenient place. We remove the workaround from the servlet resolver and point all current methods (ResourceUtil and AbstractResource) to the ResourceResolver. WDYT? Carsten -- Carsten Ziegeler cziege...@apache.org -- Felix Meschberger | Principal Scientist | Adobe
Re: [RT] Accessing the resource type hierarchy
2013/2/21 Felix Meschberger fmesc...@adobe.com: Hi Carsten Thanks for taking this issue up. It has been nagging us for too long ;-) I agree, that we should handle this centrally with an administrative resource resolver. So maybe the obvious solution is really to do it in the ResourceResolver itself. We should thus deprecate the ResourceUtil.isA method while the Resource.isResourceType method should stay (is easy to use if you already have the Resource) but should this be implemented with the new method. Why getEffectiveSuperType instead if getSuperType ? I thought to distinguish it from the getSuperType method of the Resource which does not go up the hierarchy. Carsten Regards Felix Am 21.02.2013 um 13:49 schrieb Carsten Ziegeler: Hi, looking again at SLING-2708, I think we have a fundamental misconception in the way we treat the resource type hierarchy. This affects the isA check and the detection of the effective resource super type by looking at the resource tree. In early Sling versions we used the current resource resolver (session) in the implementation of those functions, but as soon as the resource resolver did not have read access to the search paths in the resource tree, these checks failed. After hitting this problem, we implemented the isA check by implementing a resource decorator in the Sling Servlet Resolver (SLING-2693). The idea was to use the same user as we use to resolve scripts. With SLING-2708 we hit another area where this problem occurs. Now, looking back, I think the solution of SLING-2693 is wrong - the resource type hierarchy has nothing to do with execution rights and is completely independent from executing scripts. I think we should rather add two methods to the resource resolver: isA(Resource, String) and getEffectiveSuperType(Resource) - these methods will be implemented by the resource resolver and use a session which has read access to the whole tree (it could also cache the hierarchy if required). With this we have a central implementation at a convenient place. We remove the workaround from the servlet resolver and point all current methods (ResourceUtil and AbstractResource) to the ResourceResolver. WDYT? Carsten -- Carsten Ziegeler cziege...@apache.org -- Felix Meschberger | Principal Scientist | Adobe -- Carsten Ziegeler cziege...@apache.org
Re: [RT] Accessing the resource type hierarchy
Hi, Am 21.02.2013 um 15:43 schrieb Carsten Ziegeler: 2013/2/21 Felix Meschberger fmesc...@adobe.com: Hi Carsten Thanks for taking this issue up. It has been nagging us for too long ;-) I agree, that we should handle this centrally with an administrative resource resolver. So maybe the obvious solution is really to do it in the ResourceResolver itself. We should thus deprecate the ResourceUtil.isA method while the Resource.isResourceType method should stay (is easy to use if you already have the Resource) but should this be implemented with the new method. Why getEffectiveSuperType instead if getSuperType ? I thought to distinguish it from the getSuperType method of the Resource which does not go up the hierarchy. What hierarchy ? ResourceUtil.getSuperType(Resource) first asks the resource for a super type and then falls back to ResourceUtil.getResourceSuperType(ResourceResolver, String) which uses the resource type as a resource and checks that. But yes, the JcrNodeResource does not do this. We should maybe fix this by calling ResourceUtil.getResourceSuperType(ResourceResolver, String) if there is no super type property ? Or maybe something else ? In fact, looking at the ResourceUtil.getSuperType(Resource) method, this should be changed to call into the new ResourceResolver method which in turn gets back to the ResourceUtil.getResourceSuperType(ResourceResolver, String) with the admin resolver. Regards Felix Carsten Regards Felix Am 21.02.2013 um 13:49 schrieb Carsten Ziegeler: Hi, looking again at SLING-2708, I think we have a fundamental misconception in the way we treat the resource type hierarchy. This affects the isA check and the detection of the effective resource super type by looking at the resource tree. In early Sling versions we used the current resource resolver (session) in the implementation of those functions, but as soon as the resource resolver did not have read access to the search paths in the resource tree, these checks failed. After hitting this problem, we implemented the isA check by implementing a resource decorator in the Sling Servlet Resolver (SLING-2693). The idea was to use the same user as we use to resolve scripts. With SLING-2708 we hit another area where this problem occurs. Now, looking back, I think the solution of SLING-2693 is wrong - the resource type hierarchy has nothing to do with execution rights and is completely independent from executing scripts. I think we should rather add two methods to the resource resolver: isA(Resource, String) and getEffectiveSuperType(Resource) - these methods will be implemented by the resource resolver and use a session which has read access to the whole tree (it could also cache the hierarchy if required). With this we have a central implementation at a convenient place. We remove the workaround from the servlet resolver and point all current methods (ResourceUtil and AbstractResource) to the ResourceResolver. WDYT? Carsten -- Carsten Ziegeler cziege...@apache.org -- Felix Meschberger | Principal Scientist | Adobe -- Carsten Ziegeler cziege...@apache.org -- Felix Meschberger | Principal Scientist | Adobe
RE: Vanity Path query
Hi, it means it will traverse the entire workspace to find nodes with a sling:vanityPath property. Regards Marcel -Original Message- From: Felix Meschberger [mailto:fmesc...@adobe.com] Sent: Donnerstag, 21. Februar 2013 14:33 To: dev@sling.apache.org Subject: Re: Vanity Path query Hi You mean property exists querying will be slow out of the box ? What does slow mean compared to Jackrabbit 2.x ? Regards Felix Am 21.02.2013 um 12:57 schrieb Marcel Reutegger: one more thing to consider... while it probably won't have that much of an impact with Jackrabbit 2.x the situation is different with Jackrabbit Oak. Oak currently comes with default indexes for jcr:primaryType and jcr:mixinTypes. If you now turn your query into 'FROM nt:base' Oak won't be able to leverage those indexes and the query will be terribly inefficient. You will have to add an index on sling:vanityPath to make if efficient again. regards marcel -Original Message- From: Marcel Reutegger [mailto:mreut...@adobe.com] Sent: Donnerstag, 21. Februar 2013 12:53 To: dev@sling.apache.org Subject: RE: Vanity Path query Hi, Does changing FROM sling:VanityPath to FROM nt:base have any noticeable impact on performance or cost of the query ? Ian probably not. it might even be a bit faster because the query does not have to filter by node type. regards marcel -- Felix Meschberger | Principal Scientist | Adobe
Re: [RT] Accessing the resource type hierarchy
2013/2/21 Felix Meschberger fmesc...@adobe.com: What hierarchy ? ResourceUtil.getSuperType(Resource) first asks the resource for a super type and then falls back to ResourceUtil.getResourceSuperType(ResourceResolver, String) which uses the resource type as a resource and checks that. But yes, the JcrNodeResource does not do this. We should maybe fix this by calling ResourceUtil.getResourceSuperType(ResourceResolver, String) if there is no super type property ? Or maybe something else ? I think we changed this some time ago to exactly not do this - can't remember why. So the current behaviour should be Resource#getResourceSuperType only returns a value if the resource by itself knows the super type (for jcr resources this means if it has this property). I'm not sure if we should change this. In fact, looking at the ResourceUtil.getSuperType(Resource) method, this should be changed to call into the new ResourceResolver method which in turn gets back to the ResourceUtil.getResourceSuperType(ResourceResolver, String) with the admin resolver. Yes, while implementing this :) I just noticed that we need three methods on the ResourceResolver (notice I now name the method getResourceSuperType :) ): String getResourceSuperType(final Resource resource); String getResourceSuperType(final String resourceType); boolean isResourceType(final Resource resource, final String resourceType); Now, the corresponding three methods on ResourceUtil can be deprecated and call the ResourceResolver methods instead. The AbstractResource#isResourceType(String) method can be changed to call the method on the ResourceResolver as well The final question is the first point in this mail - do we leave the implementations of Resource#getResourceSuperType() as is (= returning null if they don't know it) or do we change that to call the ResourceResolver#getResourceSuperType? In the first case, we need to clarify our docs, in the second we need to change the impls (and clarify the docs) Regards Carsten -- Carsten Ziegeler cziege...@apache.org
Re: Vanity Path query
From my point of view Felix's point is correct in term of definition of how a vanity path can be set. From the Oak query point of view, if I'm not wrong, the Lucene index should chime in for this case since it indexes properties and can return paths so that should be turned into a fielded query on the given WHERE clause property. My 2 cents, Tommaso On 21/feb/2013, at 16:11, Marcel Reutegger wrote: Hi, it means it will traverse the entire workspace to find nodes with a sling:vanityPath property. Regards Marcel -Original Message- From: Felix Meschberger [mailto:fmesc...@adobe.com] Sent: Donnerstag, 21. Februar 2013 14:33 To: dev@sling.apache.org Subject: Re: Vanity Path query Hi You mean property exists querying will be slow out of the box ? What does slow mean compared to Jackrabbit 2.x ? Regards Felix Am 21.02.2013 um 12:57 schrieb Marcel Reutegger: one more thing to consider... while it probably won't have that much of an impact with Jackrabbit 2.x the situation is different with Jackrabbit Oak. Oak currently comes with default indexes for jcr:primaryType and jcr:mixinTypes. If you now turn your query into 'FROM nt:base' Oak won't be able to leverage those indexes and the query will be terribly inefficient. You will have to add an index on sling:vanityPath to make if efficient again. regards marcel -Original Message- From: Marcel Reutegger [mailto:mreut...@adobe.com] Sent: Donnerstag, 21. Februar 2013 12:53 To: dev@sling.apache.org Subject: RE: Vanity Path query Hi, Does changing FROM sling:VanityPath to FROM nt:base have any noticeable impact on performance or cost of the query ? Ian probably not. it might even be a bit faster because the query does not have to filter by node type. regards marcel -- Felix Meschberger | Principal Scientist | Adobe
Re: Vanity Path query
2013/2/21 Marcel Reutegger mreut...@adobe.com: Hi, it means it will traverse the entire workspace to find nodes with a sling:vanityPath property. So this query we're using as well: SELECT sling:alias FROM nt:base WHERE sling:alias IS NOT NULL will already be slow as hell with a large repo, right? Carsten Regards Marcel -Original Message- From: Felix Meschberger [mailto:fmesc...@adobe.com] Sent: Donnerstag, 21. Februar 2013 14:33 To: dev@sling.apache.org Subject: Re: Vanity Path query Hi You mean property exists querying will be slow out of the box ? What does slow mean compared to Jackrabbit 2.x ? Regards Felix Am 21.02.2013 um 12:57 schrieb Marcel Reutegger: one more thing to consider... while it probably won't have that much of an impact with Jackrabbit 2.x the situation is different with Jackrabbit Oak. Oak currently comes with default indexes for jcr:primaryType and jcr:mixinTypes. If you now turn your query into 'FROM nt:base' Oak won't be able to leverage those indexes and the query will be terribly inefficient. You will have to add an index on sling:vanityPath to make if efficient again. regards marcel -Original Message- From: Marcel Reutegger [mailto:mreut...@adobe.com] Sent: Donnerstag, 21. Februar 2013 12:53 To: dev@sling.apache.org Subject: RE: Vanity Path query Hi, Does changing FROM sling:VanityPath to FROM nt:base have any noticeable impact on performance or cost of the query ? Ian probably not. it might even be a bit faster because the query does not have to filter by node type. regards marcel -- Felix Meschberger | Principal Scientist | Adobe -- Carsten Ziegeler cziege...@apache.org
Re: TenantManager API
i was wondering if tenants should work differently and be more transparent to the user by allowing to swotch the osgi properties per tenant. this would allow for a more transparent implementation without forcing the developer to think about tenants that much. Ruben On Feb 21, 2013, at 2:14 AM, Felix Meschberger fmesc...@adobe.com wrote: Hi SLING-2710 [1] proposes the addition of a TenantManager service interface. Thanks for the comments so far. One question that came up in the issue is whether the TenantManager should extend the TenantProvider or not. I am a bit undecided: On the one hand I think that the TenantManager is not a TenantProvider. Also by not extending the TenantProvider the implementation has more freedom and it forces proper access to the service. On the other hand, for administrative tools really using the TenantManager having it extend the TenantProvider might make the code simpler (only one service to get instead of two). WDYT ? Regards Felix [1] https://issues.apache.org/jira/browse/SLING-2710
Re: [RT] Accessing the resource type hierarchy
On 2/21/13 7:25 AM, Carsten Ziegeler cziege...@apache.org wrote: 2013/2/21 Felix Meschberger fmesc...@adobe.com: What hierarchy ? ResourceUtil.getSuperType(Resource) first asks the resource for a super type and then falls back to ResourceUtil.getResourceSuperType(ResourceResolver, String) which uses the resource type as a resource and checks that. But yes, the JcrNodeResource does not do this. We should maybe fix this by calling ResourceUtil.getResourceSuperType(ResourceResolver, String) if there is no super type property ? Or maybe something else ? I think we changed this some time ago to exactly not do this - can't remember why. So the current behaviour should be Resource#getResourceSuperType only returns a value if the resource by itself knows the super type (for jcr resources this means if it has this property). I'm not sure if we should change this. In fact, looking at the ResourceUtil.getSuperType(Resource) method, this should be changed to call into the new ResourceResolver method which in turn gets back to the ResourceUtil.getResourceSuperType(ResourceResolver, String) with the admin resolver. Yes, while implementing this :) I just noticed that we need three methods on the ResourceResolver (notice I now name the method getResourceSuperType :) ): String getResourceSuperType(final Resource resource); String getResourceSuperType(final String resourceType); boolean isResourceType(final Resource resource, final String resourceType); On a related note (IMHO), we ran into a separate irritating problem with SlingServletResolver where the wrapped resource becomes untestable using ResourceUtil.isA() AFTER a call to adaptTo(), because the wrapper delegates to the original resource whose resolver has no access to the types. (see SLING-2708) I think that: - adding ResourceResolver.isResourceType() - replacing some usages of ResourceUtil.isA() with ResourceResolver.isResourceType() Would fix this. So +1 to these changes :) Now, the corresponding three methods on ResourceUtil can be deprecated and call the ResourceResolver methods instead. The AbstractResource#isResourceType(String) method can be changed to call the method on the ResourceResolver as well The final question is the first point in this mail - do we leave the implementations of Resource#getResourceSuperType() as is (= returning null if they don't know it) or do we change that to call the ResourceResolver#getResourceSuperType? In the first case, we need to clarify our docs, in the second we need to change the impls (and clarify the docs) I would prefer Resource.getResourceSuperType() return null when the property is not set. I am trying to think of use cases that would get the super type, other than script resolution (internal to sling), or cases that are testing for type ancestry (which should ONLY use ResourceResolver.isResourceType()), so not sure where this comes up in an application use case? Thanks Tyson Regards Carsten -- Carsten Ziegeler cziege...@apache.org
Re: [RT] Accessing the resource type hierarchy
2013/2/21 Tyson Norris tnor...@adobe.com: On a related note (IMHO), we ran into a separate irritating problem with SlingServletResolver where the wrapped resource becomes untestable using ResourceUtil.isA() AFTER a call to adaptTo(), because the wrapper delegates to the original resource whose resolver has no access to the types. (see SLING-2708) I think that: - adding ResourceResolver.isResourceType() - replacing some usages of ResourceUtil.isA() with ResourceResolver.isResourceType() Would fix this. Yes, that bug exactly made me think about it again :) I would prefer Resource.getResourceSuperType() return null when the property is not set. I am trying to think of use cases that would get the super type, other than script resolution (internal to sling), or cases that are testing for type ancestry (which should ONLY use ResourceResolver.isResourceType()), so not sure where this comes up in an application use case? The use cases should be rare - i've seen people doing checks against the super type, but they always use ResourceUtil . Carsten -- Carsten Ziegeler cziege...@apache.org
[POST] Servlet resolution for non existing resource
Hi,
Wrt to implementation of chunked upload feature SLING-2707[0] and [1], it
require to hit chunkupload servlet (registered on selector chunk) for a non
existing resource. So when I post request as [2], servlet resolves to default
slingpostservlet[3].
Is there a way to resolve servlet to chunkuploadservlet?
Regards,
Shashank
[0]
https://issues.apache.org/jira/browse/SLING-2707
[1]
https://cwiki.apache.org/confluence/display/SLING/Chunked+File+Upload+Support#ChunkedFileUploadSupport-UploadchunkusingPOST
[2]
POST /temp/dam/Desert.jpg.chunk.1.res HTTP/1.1
Host: localhost:4502
If-Match: e0023aa4e
[3]
0 (2013-02-21 21:40:18) TIMER_END{0,ResourceResolution}
URI=/temp/dam/Desert.jpg.chunk.1.res resolves to Resource=,
type=sling:nonexisting, path=/temp/dam/Desert.jpg.chunk.1.res,
resource=[NonExistingResource, path=/temp/dam/Desert.jpg.chunk.1.res]
0 (2013-02-21 21:40:18) LOG Resource Path Info: SlingRequestPathInfo:
path='/temp/dam/Desert.jpg.chunk.1.res', selectorString='jpg.chunk.1',
extension='res', suffix='null'
0 (2013-02-21 21:40:18) TIMER_START{ServletResolution}
0 (2013-02-21 21:40:18) TIMER_START{resolveServlet(,
type=sling:nonexisting, path=/temp/dam/Desert.jpg.chunk.1.res,
resource=[NonExistingResource, path=/temp/dam/Desert.jpg.chunk.1.res])}
0 (2013-02-21 21:40:18) LOG {0}: no servlet found
0 (2013-02-21 21:40:18) TIMER_END{0,resolveServlet(,
type=sling:nonexisting, path=/temp/dam/Desert.jpg.chunk.1.res,
resource=[NonExistingResource, path=/temp/dam/Desert.jpg.chunk.1.res])} Using
servlet org.apache.sling.servlets.post.impl.SlingPostServlet
0 (2013-02-21 21:40:18) TIMER_END{0,ServletResolution}
URI=/temp/dam/Desert.jpg.chunk.1.res handled by
Servlet=org.apache.sling.servlets.post.impl.SlingPostServlet
[jira] [Created] (SLING-2739) Add methods for handling the resource type hierarchy to the resource resolver
Carsten Ziegeler created SLING-2739: --- Summary: Add methods for handling the resource type hierarchy to the resource resolver Key: SLING-2739 URL: https://issues.apache.org/jira/browse/SLING-2739 Project: Sling Issue Type: Task Components: API, ResourceResolver, Servlets Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Servlets Resolver 2.2.2, API 2.3.2, Resource Resolver 1.0.6 Looking again at SLING-2708, I think we have a fundamental misconception in the way we treat the resource type hierarchy. This affects the isA check and the detection of the effective resource super type by looking at the resource tree. In early Sling versions we used the current resource resolver (session) in the implementation of those functions, but as soon as the resource resolver did not have read access to the search paths in the resource tree, these checks failed. After hitting this problem, we implemented the isA check by implementing a resource decorator in the Sling Servlet Resolver (SLING-2693). The idea was to use the same user as we use to resolve scripts. With SLING-2708 we hit another area where this problem occurs. Now, looking back, I think the solution of SLING-2693 is wrong - the resource type hierarchy has nothing to do with execution rights and is completely independent from executing scripts. I think we should rather add three methods to the resource resolver: String getResourceSuperType(final Resource resource); String getResourceSuperType(final String resourceType); boolean isResourceType(final Resource resource, final String resourceType); Now, the corresponding three methods on ResourceUtil can be deprecated and call the ResourceResolver methods instead. The AbstractResource#isResourceType(String) method can be changed to call the method on the ResourceResolver as well With this we have a central implementation at a convenient place. We remove the workaround from the servlet resolver. -- 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
Re: [POST] Servlet resolution for non existing resource
Hi,
Have you tried registering the chunkupload servlet to handle a
sling:resourceType of sling:nonexisting ?
Ian
On 22 February 2013 03:34, Shashank Gupta shgu...@adobe.com wrote:
Hi,
Wrt to implementation of chunked upload feature SLING-2707[0] and [1], it
require to hit chunkupload servlet (registered on selector chunk) for a non
existing resource. So when I post request as [2], servlet resolves to
default slingpostservlet[3].
Is there a way to resolve servlet to chunkuploadservlet?
Regards,
Shashank
[0]
https://issues.apache.org/jira/browse/SLING-2707
[1]
https://cwiki.apache.org/confluence/display/SLING/Chunked+File+Upload+Support#ChunkedFileUploadSupport-UploadchunkusingPOST
[2]
POST /temp/dam/Desert.jpg.chunk.1.res HTTP/1.1
Host: localhost:4502
If-Match: e0023aa4e
[3]
0 (2013-02-21 21:40:18) TIMER_END{0,ResourceResolution}
URI=/temp/dam/Desert.jpg.chunk.1.res resolves to Resource=,
type=sling:nonexisting, path=/temp/dam/Desert.jpg.chunk.1.res,
resource=[NonExistingResource, path=/temp/dam/Desert.jpg.chunk.1.res]
0 (2013-02-21 21:40:18) LOG Resource Path Info: SlingRequestPathInfo:
path='/temp/dam/Desert.jpg.chunk.1.res', selectorString='jpg.chunk.1',
extension='res', suffix='null'
0 (2013-02-21 21:40:18) TIMER_START{ServletResolution}
0 (2013-02-21 21:40:18) TIMER_START{resolveServlet(,
type=sling:nonexisting, path=/temp/dam/Desert.jpg.chunk.1.res,
resource=[NonExistingResource, path=/temp/dam/Desert.jpg.chunk.1.res])}
0 (2013-02-21 21:40:18) LOG {0}: no servlet found
0 (2013-02-21 21:40:18) TIMER_END{0,resolveServlet(,
type=sling:nonexisting, path=/temp/dam/Desert.jpg.chunk.1.res,
resource=[NonExistingResource, path=/temp/dam/Desert.jpg.chunk.1.res])} Using
servlet org.apache.sling.servlets.post.impl.SlingPostServlet
0 (2013-02-21 21:40:18) TIMER_END{0,ServletResolution}
URI=/temp/dam/Desert.jpg.chunk.1.res handled by
Servlet=org.apache.sling.servlets.post.impl.SlingPostServlet
Re: [RT] Accessing the resource type hierarchy
On 22 February 2013 02:25, Carsten Ziegeler cziege...@apache.org wrote: The final question is the first point in this mail - do we leave the implementations of Resource#getResourceSuperType() as is (= returning null if they don't know it) or do we change that to call the ResourceResolver#getResourceSuperType? Yes please, leave as is returning null. I can think of many situations where I have checked that method expecting it yo be the property and not wanting to bind to the Node interface (because the resource might not be a Node). BTW, I thing the getEffectiveSuperType is good as it communicates the result is not the same as the property. Better might be to think of the results in terms of inheritance and give real isolation between the concepts. Newbees are going to find this area confusing (and I might have just proved myself to be a newbee). What about getInheritedType or allow for future expansion with String[] getInheritedTypes(Resource resource) ? Ian In the first case, we need to clarify our docs, in the second we need to change the impls (and clarify the docs) Regards Carsten -- Carsten Ziegeler cziege...@apache.org
Re: animal sniffer check failure
Found the problem, nothing to do with Mockito javax.management.StandardEmitterMBean was introduced in JDK 16 and contains bindings to APIs only available in 1.6 or later. Since this is the standard way of implementing notifications I think I will require JDK 1.6 in the bundle. I hope this is Ok. I can implement in a compliant 1.5 way but that will require writing my own (less performant) implementations of the notification APIs, which is probably not a good idea. Ian On 21 February 2013 21:03, Carsten Ziegeler cziege...@apache.org wrote: Which java version do you use to build? OS? Where does the problem occur? I haven't seen this problem so far (OS X, Java 6) - except for the commons classloader where we did some magic with the test case and java 6. Carsten 2013/2/21 Ian Boston i...@tfd.co.uk: Hi, I am getting ERROR] Failed to execute goal org.codehaus.mojo:animal-sniffer-maven-plugin:1.9:check (default) on project org.apache.sling.event: Execution default of goal org.codehaus.mojo:animal-sniffer-maven-plugin:1.9:check failed: An API incompatibility was encountered while executing org.codehaus.mojo:animal-sniffer-maven-plugin:1.9:check: java.lang.NoSuchMethodError: java.nio.CharBuffer.subSequence(II)Ljava/nio/CharBuffer; [ERROR] - I think is due to a dependency rather (mockito) than the code since indicating JDK 1.6 eliminated the problem. (-Dsling.java.version=6) Going all the way back to mockito 1.8.0 doesn't fix the issue. Has anyone else seen the same problem ? Ian -- Carsten Ziegeler cziege...@apache.org
Re: [POST] Servlet resolution for non existing resource
On 21.02.2013, at 17:34, Shashank Gupta shgu...@adobe.com wrote: Wrt to implementation of chunked upload feature SLING-2707[0] and [1], it require to hit chunkupload servlet (registered on selector chunk) for a non existing resource. So when I post request as [2], servlet resolves to default slingpostservlet[3]. Is there a way to resolve servlet to chunkuploadservlet? That's actually another good reason to not use the chunk selector here, but integrate the resumable upload with the sling post servlet right away as proposed in the issue: https://issues.apache.org/jira/browse/SLING-2707?focusedCommentId=13580754page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13580754 Cheers, Alex
Re: animal sniffer check failure
This is OK. Per our vote on dropping Java 5 support, you should feel free to update the version in the pom to 6 and commit. No per-module vote is required. Justin On Thu, Feb 21, 2013 at 4:49 PM, Ian Boston i...@tfd.co.uk wrote: Found the problem, nothing to do with Mockito javax.management.StandardEmitterMBean was introduced in JDK 16 and contains bindings to APIs only available in 1.6 or later. Since this is the standard way of implementing notifications I think I will require JDK 1.6 in the bundle. I hope this is Ok. I can implement in a compliant 1.5 way but that will require writing my own (less performant) implementations of the notification APIs, which is probably not a good idea. Ian On 21 February 2013 21:03, Carsten Ziegeler cziege...@apache.org wrote: Which java version do you use to build? OS? Where does the problem occur? I haven't seen this problem so far (OS X, Java 6) - except for the commons classloader where we did some magic with the test case and java 6. Carsten 2013/2/21 Ian Boston i...@tfd.co.uk: Hi, I am getting ERROR] Failed to execute goal org.codehaus.mojo:animal-sniffer-maven-plugin:1.9:check (default) on project org.apache.sling.event: Execution default of goal org.codehaus.mojo:animal-sniffer-maven-plugin:1.9:check failed: An API incompatibility was encountered while executing org.codehaus.mojo:animal-sniffer-maven-plugin:1.9:check: java.lang.NoSuchMethodError: java.nio.CharBuffer.subSequence(II)Ljava/nio/CharBuffer; [ERROR] - I think is due to a dependency rather (mockito) than the code since indicating JDK 1.6 eliminated the problem. (-Dsling.java.version=6) Going all the way back to mockito 1.8.0 doesn't fix the issue. Has anyone else seen the same problem ? Ian -- Carsten Ziegeler cziege...@apache.org
Re: Vanity Path query
On Thu, Feb 21, 2013 at 10:29 AM, Carsten Ziegeler cziege...@apache.orgwrote: 2013/2/21 Marcel Reutegger mreut...@adobe.com: Hi, it means it will traverse the entire workspace to find nodes with a sling:vanityPath property. So this query we're using as well: SELECT sling:alias FROM nt:base WHERE sling:alias IS NOT NULL will already be slow as hell with a large repo, right? IIUC, the performance would be improvable by defining an index on the sling:alias property (or sling:vanityPath property in the original case). I suspect that this is going to be a necessity regardless of what node type is used, at least for sling:vanityPath. At least in our commercial product, it's not uncommon to see tens or hundreds of thousands of nodes with the sling:VanityPath mixin (only a vast minority actually have the property set). If Oak is going to get the list of all nodes with that mixin type and then filter out based on property existence, that's better than iterating over EVERY node, but not as performant as it is in JR2. Back to the original question, it might be possible to get the timing information by using our existing vanity path related performance tests. As we've had lots of issues with performance and vanity paths, I'd really like to get some hard numbers before changing direction. I don't have any problems changing the semantics, even though it is non-backwards compatible. Regards, Justin Carsten Regards Marcel -Original Message- From: Felix Meschberger [mailto:fmesc...@adobe.com] Sent: Donnerstag, 21. Februar 2013 14:33 To: dev@sling.apache.org Subject: Re: Vanity Path query Hi You mean property exists querying will be slow out of the box ? What does slow mean compared to Jackrabbit 2.x ? Regards Felix Am 21.02.2013 um 12:57 schrieb Marcel Reutegger: one more thing to consider... while it probably won't have that much of an impact with Jackrabbit 2.x the situation is different with Jackrabbit Oak. Oak currently comes with default indexes for jcr:primaryType and jcr:mixinTypes. If you now turn your query into 'FROM nt:base' Oak won't be able to leverage those indexes and the query will be terribly inefficient. You will have to add an index on sling:vanityPath to make if efficient again. regards marcel -Original Message- From: Marcel Reutegger [mailto:mreut...@adobe.com] Sent: Donnerstag, 21. Februar 2013 12:53 To: dev@sling.apache.org Subject: RE: Vanity Path query Hi, Does changing FROM sling:VanityPath to FROM nt:base have any noticeable impact on performance or cost of the query ? Ian probably not. it might even be a bit faster because the query does not have to filter by node type. regards marcel -- Felix Meschberger | Principal Scientist | Adobe -- Carsten Ziegeler cziege...@apache.org
Re: Vanity Path query
On 22 February 2013 14:13, Justin Edelson jus...@justinedelson.com wrote:
On Thu, Feb 21, 2013 at 10:29 AM, Carsten Ziegeler
cziege...@apache.orgwrote:
2013/2/21 Marcel Reutegger mreut...@adobe.com:
Hi,
it means it will traverse the entire workspace to find nodes with
a sling:vanityPath property.
So this query we're using as well:
SELECT sling:alias FROM nt:base WHERE sling:alias IS NOT NULL
will already be slow as hell with a large repo, right?
IIUC, the performance would be improvable by defining an index on the
sling:alias property (or sling:vanityPath property in the original case). I
suspect that this is going to be a necessity regardless of what node type
is used, at least for sling:vanityPath. At least in our commercial product,
it's not uncommon to see tens or hundreds of thousands of nodes with the
sling:VanityPath mixin (only a vast minority actually have the property
set). If Oak is going to get the list of all nodes with that mixin type and
then filter out based on property existence, that's better than iterating
over EVERY node, but not as performant as it is in JR2.
Back to the original question, it might be possible to get the timing
information by using our existing vanity path related performance tests. As
we've had lots of issues with performance and vanity paths, I'd really like
to get some hard numbers before changing direction. I don't have any
problems changing the semantics, even though it is non-backwards compatible.
I might be going off topic, apologies:
I am sure you know this, but I am going to say it anyway (perhaps for
others that don't).
The query is used to construct the mapping map (in MapEntries) used
by the resource resolver for forward and backward mapping of urls.
Once constructed the map remains static until something else triggers
a rebuild.
Unless you see a cpu spike when modifying a vanity path, I dont think
rebuilding the map will be a performance issue. (note the think. I
dont have hard evidence :( )
repos with 1000s of vanity paths will generate a mapping structure
with 1000s of entries, and although in memory map lookups are super
fast, I am not convinced that the structure is used as a map see [1],
which looks suspiciously like iterating over all entries in the map.
Hence, if you add 1000s then this call
final IteratorMapEntry mapEntriesIterator =
this.factory.getMapEntries().getResolveMapsIterator(requestPath);
in resource resolver map is going to be a hot spot, as its called on
every resolution, and for every match that is found a remapping is
performed.
I could be reading the code wrong, but I think that if this is the
case, the way in which the path is mapped should be changed, so that
the map is used like a map or a hierarchical tree of maps is used in
the same way the resource resolver was converted from a list to that
some time ago.
I think all it would need is:
String[] pathElements = path.split(/);
MapString, ? m = rootMappingEntry;
for (String part : pathElements ) {
MapString, ? nm = m.get(part);
if ( nm == null ) break;
m = nm;
}
what ever is left in m is the closest match for the inbound path wrt
the mapping operation. I think that will scale ?
Ian
1
org.apache.sling.resourceresolver.impl.mapping.MapEntries.MapEntryIterator.seek()
Regards,
Justin
Carsten
Regards
Marcel
-Original Message-
From: Felix Meschberger [mailto:fmesc...@adobe.com]
Sent: Donnerstag, 21. Februar 2013 14:33
To: dev@sling.apache.org
Subject: Re: Vanity Path query
Hi
You mean property exists querying will be slow out of the box ?
What does slow mean compared to Jackrabbit 2.x ?
Regards
Felix
Am 21.02.2013 um 12:57 schrieb Marcel Reutegger:
one more thing to consider...
while it probably won't have that much of an impact with Jackrabbit
2.x
the situation is different with Jackrabbit Oak. Oak currently comes
with
default indexes for jcr:primaryType and jcr:mixinTypes. If you now
turn your query into 'FROM nt:base' Oak won't be able to leverage
those indexes and the query will be terribly inefficient. You will
have
to add an index on sling:vanityPath to make if efficient again.
regards
marcel
-Original Message-
From: Marcel Reutegger [mailto:mreut...@adobe.com]
Sent: Donnerstag, 21. Februar 2013 12:53
To: dev@sling.apache.org
Subject: RE: Vanity Path query
Hi,
Does changing FROM sling:VanityPath to FROM nt:base have any
noticeable impact on performance or cost of the query ?
Ian
probably not. it might even be a bit faster because the query does
not have to filter by node type.
regards
marcel
--
Felix Meschberger | Principal Scientist | Adobe
--
Carsten Ziegeler
cziege...@apache.org
Re: animal sniffer check failure
Ahh, thanks, I much prefer the StandardEmitterMBean approach which makes notifications a doddle. Ian On 22 February 2013 14:05, Justin Edelson jus...@justinedelson.com wrote: This is OK. Per our vote on dropping Java 5 support, you should feel free to update the version in the pom to 6 and commit. No per-module vote is required. Justin On Thu, Feb 21, 2013 at 4:49 PM, Ian Boston i...@tfd.co.uk wrote: Found the problem, nothing to do with Mockito javax.management.StandardEmitterMBean was introduced in JDK 16 and contains bindings to APIs only available in 1.6 or later. Since this is the standard way of implementing notifications I think I will require JDK 1.6 in the bundle. I hope this is Ok. I can implement in a compliant 1.5 way but that will require writing my own (less performant) implementations of the notification APIs, which is probably not a good idea. Ian On 21 February 2013 21:03, Carsten Ziegeler cziege...@apache.org wrote: Which java version do you use to build? OS? Where does the problem occur? I haven't seen this problem so far (OS X, Java 6) - except for the commons classloader where we did some magic with the test case and java 6. Carsten 2013/2/21 Ian Boston i...@tfd.co.uk: Hi, I am getting ERROR] Failed to execute goal org.codehaus.mojo:animal-sniffer-maven-plugin:1.9:check (default) on project org.apache.sling.event: Execution default of goal org.codehaus.mojo:animal-sniffer-maven-plugin:1.9:check failed: An API incompatibility was encountered while executing org.codehaus.mojo:animal-sniffer-maven-plugin:1.9:check: java.lang.NoSuchMethodError: java.nio.CharBuffer.subSequence(II)Ljava/nio/CharBuffer; [ERROR] - I think is due to a dependency rather (mockito) than the code since indicating JDK 1.6 eliminated the problem. (-Dsling.java.version=6) Going all the way back to mockito 1.8.0 doesn't fix the issue. Has anyone else seen the same problem ? Ian -- Carsten Ziegeler cziege...@apache.org
[jira] [Commented] (SLING-2597) Provide interface for monitoring services
[
https://issues.apache.org/jira/browse/SLING-2597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13583895#comment-13583895
]
Ian Boston commented on SLING-2597:
---
Implemented 2 main JMX beans that expose the statistics of queues. One exposes
the JobManager statistics, the other esposes the queues are they are created
and generated JMX notifications when queues are added and removed. As queues
are added they MBeans are registered as services which expose the statistics.
When queues are removed the services are removed. The OSGi JMX whiteboard
pattern takes care of registering the JMX beans.
Main commit in r1448886
In r1448887 I added a test button to the WebConsole to allow an admin to post
and event to a queue, causing the queue to be activated.
I think we could add more JMX beans where appropriate in Sling to give better
monitoring of health, but this is probably enough for the moment.
Provide interface for monitoring services
-
Key: SLING-2597
URL: https://issues.apache.org/jira/browse/SLING-2597
Project: Sling
Issue Type: New Feature
Reporter: Jörg Hoh
Assignee: Ian Boston
There should be an interface which one can query to get information about the
status of a service implementing this interface.
eg.
public interface HealthCheckable {
public int getStatus();
}
For the return value for this method we could use:
static int OK = 0;
static int WARNING = 1;
static int CRITICAL = 2;
static int UNKNOWN = 3;
(these are the values which Nagios uses as return values for its plugins, see
http://nagiosplug.sourceforge.net/developer-guidelines.html#AEN76).
The decision what value is returned is delegated to the service, so maybe
they need to have some configuration to define the points, where a OK
becomes WARNING.
Via OSGI whiteboard pattern we can collect then all services providing status
information and calculate an overall status of the system.
--
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] [Resolved] (SLING-2597) Provide interface for monitoring services
[
https://issues.apache.org/jira/browse/SLING-2597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ian Boston resolved SLING-2597.
---
Resolution: Fixed
Fix Version/s: Extensions Event 3.1.6
Please fee free to reopen (or create a new issue) if you think more needs to be
done here.
Provide interface for monitoring services
-
Key: SLING-2597
URL: https://issues.apache.org/jira/browse/SLING-2597
Project: Sling
Issue Type: New Feature
Reporter: Jörg Hoh
Assignee: Ian Boston
Fix For: Extensions Event 3.1.6
There should be an interface which one can query to get information about the
status of a service implementing this interface.
eg.
public interface HealthCheckable {
public int getStatus();
}
For the return value for this method we could use:
static int OK = 0;
static int WARNING = 1;
static int CRITICAL = 2;
static int UNKNOWN = 3;
(these are the values which Nagios uses as return values for its plugins, see
http://nagiosplug.sourceforge.net/developer-guidelines.html#AEN76).
The decision what value is returned is delegated to the service, so maybe
they need to have some configuration to define the points, where a OK
becomes WARNING.
Via OSGI whiteboard pattern we can collect then all services providing status
information and calculate an overall status of the system.
--
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
Re: Vanity Path query
On 22 February 2013 14:47, Ian Boston i...@tfd.co.uk wrote: repos with 1000s of vanity paths will generate a mapping structure with 1000s of entries, and although in memory map lookups are super fast, I am not convinced that the structure is used as a map see [1], which looks suspiciously like iterating over all entries in the map. Ooops, I take that back, sorry for any alarm. It iterates over a global List of map entries registered at '*' and then over Lists of map entries based on path. Provided the vanity paths have some structure this should be fast. If they don't have any structure then the mapping might not. Please correct that statement if its wrong. Ian
