Re: Revisiting the resource super type handling
On Fri, Jun 26, 2009 at 10:30 AM, Carsten Ziegeler wrote: > Hi, > > while changing the script resolution in the last days a little bit to > make it cacheable, I stumbled across the handling of the resource super > type. > The jcr resource implementation checks if the node has the > sling:resourceSuperType property and returns this value if existent. > If not, it tries to find a resource under the search paths (usually libs > and apps) with the resource type converted to a path. So if a resource > has the type "a/b", the resources /apps/a/b and /libs/a/b are tested if > they exist and contain a resource super type property. > > Other resource implementations like the bundle resource always returns > null. The fs resource implemenations returns a special resource type for > the resource super type. > > I think this behaviour is a little bit inconsistent. I would change it > that if a resource does not know it's super type, it should return null. > So basically this effects the implementation of the jcr resource. > The script resolver already checks if the resource super type is null > and then applies the above algoritm from the jcr resource as well. > > Otherwise each resource implemenation should apply the algorithm to be > consistent. But I would prefer the first solution. > > While the change is incompatible, I think this doesn't have any real effect. i agree that the resource should not know about search paths. imo, the resource resolver should be used for 'resolving' the resource super type. regards, toby
Re: ACL permissions on nodes.
hi,
according to jsr283 (see 16.2.3), the jcr:write is an aggregate privilege:
• jcr:write: An aggregate privilege that contains:
o jcr:modifyProperties
o jcr:addChildNodes
o jcr:removeNode
o jcr:removeChildNodes
so, jcr:write should be sufficient. i can imagine, that the individual
privilege are expanded when applying the privilege on the node, but i
don't know for sure. how exactly do you set the privilege? using the
AccessControllManager ?
if you think this is a bug, please file a jackrabbit jira issue (if
possible with a test-case).
thanks.
regards, toby
On Tue, Jun 23, 2009 at 1:04 PM, Ian Boston wrote:
> Hi,
>
> If I set jcr:write granted on a node, I can upload content to that node with
> a multipart post but I cant overwrite the content.
>
> to make that work I appear to need at least
>
> curl
> http://admin:ad...@localhost:8080/_user/private/d9/31/78/03/ian5.acl.json
>
> {"ian5":{"granted":["jcr:write","jcr:removeChildNodes","jcr:modifyProperties","jcr:addChildNodes","jcr:removeNode"]}}
>
> to avoid getting an access denied on remove jcr:content.
>
> This sounds a little odd, since write usually implies overwrite.
>
> Was this intentional.. or a fact of jcr ?
> Ian
>
>
>
[jira] Commented: (SLING-649) checkboxes not handled by SlingPostServlet
[ https://issues.apache.org/jira/browse/SLING-649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12713080#action_12713080 ] Tobias Bocanegra commented on SLING-649: > Even with the value attribute included it does not work properly. Setting the > corresponding property to true works. Setting it to false doesn't. you should always delete the properties first: the problem is, that the browser does not send the parameter at all, if not checked. > checkboxes not handled by SlingPostServlet > -- > > Key: SLING-649 > URL: https://issues.apache.org/jira/browse/SLING-649 > Project: Sling > Issue Type: Improvement > Components: Servlets Post > Environment: Ubuntu AMD64 FF3 >Reporter: Renaud Richardet >Priority: Minor > > I am trying to use checkboxes with the SlingPostServlet, as described in > http://incubator.apache.org/sling/site/manipulating-content-the-slingpostservlet.html > > > > > >... > > > All elements work fine, excepte the checkbox: the "checked" node property is > always set to false in JCR after a POST. Can anyone confirm? > I guess it's because the POST request parameters are: > width 1234 > wi...@typehint Long > checked on > chec...@typehint Boolean > So, the passed checkbox parameter is "on" instead of "true" > I guess I would have to modify SlingPropertyValueHandler.setPropertyAsIs() to > handle "on" values as "true" if @TypeHint is Boolean. Similar to how dates > values are handled if @TypeHint = date. > If it's the right way to go, I will create a patch. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: creating new properties with HTTP request
try '&' as delimiter.
see: http://en.wikipedia.org/wiki/Query_string
and:
https://developer.mozilla.org/en/Core_JavaScript_1.5_Reference/Global_Functions/encodeURIComponent
regards, toby
2009/5/12 vkrejcirik :
> I need to create more properties with HTTP request. When I send HTTP request
> with query string, which contents only one property, it's ok.
> I don't know, how can I separate more properties. (I tried coma and
> semicolon )
>
> example:
>
> var queryString = "newContent=" + newContent + ";mep=" + mep + ";endpoint="
> + endpoint;
>
> xmlHttp = createXMLHttpRequest();
> xmlHttp.onreadystatechange = processSave;
> xmlHttp.open("POST", url, true);
> xmlHttp.setRequestHeader("Content-Type",
> "application/x-www-form-urlencoded;");
> xmlHttp.send(queryString);
>
> Thanks.
>
> --
> /**/
> Best regards / S pozdravem
> Vladislav Krejčiřík
>
> http://www.vkrejcirik.info
>
>
Re: Event Listeners
On Tue, May 5, 2009 at 5:04 PM, Carsten Ziegeler wrote: > Tobias Bocanegra wrote: >> >> sorry to bring this up again - but i'm a bit concerned that every JCR >> api functionality is duplicated in sling. i think it should not be to >> goal to replace the JCR api in sling, but to leverage it. the main >> focus of sling should be to build a framework on JCR and not try to >> make JCR replaceable. >> the JCR api might be a bit clumsy to use, but at least it is well >> documented and standardized. >> > One of the aims of Sling is to make building apps on top of JCR easier. > And the described functionality makes observation in many use cases > easier. So it's not a duplication. It's a simplified interface. frankly, i a bit worried about the overall performance, when the zillions of JCR observation events will be pushed through the event admin :-) but maybe you can prove me wrong with some good performance comparisons. regards, toby
Re: Event Listeners
On Tue, May 5, 2009 at 3:26 PM, Carsten Ziegeler wrote: > Ian Boston wrote: >> Are there any facilities in sling for registering jcr event listeners ? >> >> Both the external javax.jcr.observation.EventListener and the >> SynchronousEventListener type. >> > No we don't have extra support in Sling atm. One of the problems here is > that the jcr listeners are tied to a session. > > But we're working on a resource based eventing which leverages the OSGi > eventing: > > https://issues.apache.org/jira/browse/SLING-944 sorry to bring this up again - but i'm a bit concerned that every JCR api functionality is duplicated in sling. i think it should not be to goal to replace the JCR api in sling, but to leverage it. the main focus of sling should be to build a framework on JCR and not try to make JCR replaceable. the JCR api might be a bit clumsy to use, but at least it is well documented and standardized. regards, toby
Re: Security in Sling
On Wed, Apr 22, 2009 at 12:41 PM, Felix Meschberger wrote: > Hi, > > Jukka Zitting schrieb: >> Hi, >> >> I was thinking about the implications of giving a user write access to >> a subtree of the repository. With that access the user could now >> upload a new script and create a node that invokes that script when >> rendered. >> >> What if the script contains something like System.exit(1)? Or >> something even more malicious? >> >> Do we have mechanisms for preventing attack scenarios like that? > > No, unless Java platform security (SecurityManager) is enabled, in which > case the "exitVM" PlatformPersmission would be required to call > System.exit() and likewise for other actions. System.exit() bears IMO no real risk, since it can be prevented by java security. scripts that heavily consume resources and/or eat CPU in endless loops are more dangerous and much harder to detect and prevent. regards, toby
Re: svn commit: r766087 - in /incubator/sling/trunk/bundles/commons/json/src: main/java/org/apache/sling/commons/json/jcr/JsonJcrNode.java test/java/org/apache/sling/commons/json/jcr/JsonJcrNodeTest
hi,
those 2 files are missing the apache license header.
regards, toby
btw: i think .* imports are discouraged by apache coding conventions.
On Fri, Apr 17, 2009 at 7:12 PM, wrote:
> Author: vramdal
> Date: Fri Apr 17 17:12:57 2009
> New Revision: 766087
>
> URL: http://svn.apache.org/viewvc?rev=766087&view=rev
> Log:
> SLING-930 Adding o.a.s.c.json.jcr.JsonJcrNode + testcase
>
> Added:
>
> incubator/sling/trunk/bundles/commons/json/src/main/java/org/apache/sling/commons/json/jcr/JsonJcrNode.java
>
> incubator/sling/trunk/bundles/commons/json/src/test/java/org/apache/sling/commons/json/jcr/JsonJcrNodeTest.java
>
> Added:
> incubator/sling/trunk/bundles/commons/json/src/main/java/org/apache/sling/commons/json/jcr/JsonJcrNode.java
> URL:
> http://svn.apache.org/viewvc/incubator/sling/trunk/bundles/commons/json/src/main/java/org/apache/sling/commons/json/jcr/JsonJcrNode.java?rev=766087&view=auto
> ==
> ---
> incubator/sling/trunk/bundles/commons/json/src/main/java/org/apache/sling/commons/json/jcr/JsonJcrNode.java
> (added)
> +++
> incubator/sling/trunk/bundles/commons/json/src/main/java/org/apache/sling/commons/json/jcr/JsonJcrNode.java
> Fri Apr 17 17:12:57 2009
> @@ -0,0 +1,132 @@
> +package org.apache.sling.commons.json.jcr;
> +
> +import org.apache.sling.commons.json.JSONObject;
> +import org.apache.sling.commons.json.JSONException;
> +
> +import javax.jcr.*;
> +import java.util.Set;
> +import java.util.List;
> +import java.util.ArrayList;
> +
> +/**
> + * This class makes it easy to create a JSON object out of a JCR node. It is
> a shameless copy of {...@link JsonItemWriter},
> + * but instead of writing the resulting JSON directly to an output, you get
> a JSONObject that you can deal with.
> + *
> + * @author vi...@idium.no
> + * @since Apr 17, 2009 6:55:30 PM
> + */
> +public class JsonJcrNode extends JSONObject {
> +
> + private Node node;
> + private Set propertyNamesToIgnore;
> +
> + /**
> + * Creates a JSONObject out of node. All
> node's properties will be reflected in the JSON
> + * object. In addition, properties jcr:path and
> jcr:name are added. Their values are
> + * those returned by node.getPath() and
> node.getName(), respectively.
> + * @param node The JCR node to use
> + * @throws JSONException If there's a problem generating the JSON object
> + * @throws RepositoryException If there's a problem reading data from
> the JCR repository
> + */
> + public JsonJcrNode(Node node) throws JSONException, RepositoryException {
> + this(node, null);
> + }
> +
> + /**
> + * Creates a JSONObject out of node. All
> node's properties will be reflected
> + * in the JSON object, except those in
> propertyNamesToIgnore. In addition, properties
> + * jcr:path and jcr:name are added. Their
> values are those returned by
> + * node.getPath() and node.getName(),
> respectively.
> + * @param node The JCR node to use
> + * @param propertyNamesToIgnore A set of property names that should
> not be reflected in the resulting
> + * JSON object.
> + * @throws JSONException If there's a problem generating the JSON object
> + * @throws RepositoryException If there's a problem reading data from
> the JCR repository
> + */
> + public JsonJcrNode(Node node, Set propertyNamesToIgnore) throws
> JSONException, RepositoryException {
> + this.node = node;
> + this.propertyNamesToIgnore = propertyNamesToIgnore;
> + this.populate();
> + }
> +
> + private void populate() throws JSONException, RepositoryException {
> + PropertyIterator properties = node.getProperties();
> + addNative("jcr:path", node.getPath());
> + addNative("jcr:name", node.getName());
> + while (properties.hasNext()) {
> + Property prop = properties.nextProperty();
> + String name = prop.getName();
> + if (propertyNamesToIgnore != null &&
> propertyNamesToIgnore.contains(name)) {
> + continue;
> + }
> + addProperty(prop);
> + }
> + }
> +
> + private void addNative(String key, String value) throws JSONException,
> RepositoryException {
> + if (propertyNamesToIgnore == null ||
> !propertyNamesToIgnore.contains(key)) {
> + this.put(key, value);
> + }
> + }
> +
> + protected void addProperty(Property p)
> + throws ValueFormatException, RepositoryException, JSONException {
> + // special handling for binaries: we dump the length and not the
> length
> + if (p.getType() == PropertyType.BINARY) {
> + // TODO for now we mark binary properties with an initial colon
> in
> + // their name
> + // (colon is not allowed as a JCR property name)
> + // in the name, and the value should be the size of the binary
> data
> + S
[jira] Commented: (SLING-902) add java annotation support for sling scr components/servlets
[
https://issues.apache.org/jira/browse/SLING-902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12693622#action_12693622
]
Tobias Bocanegra commented on SLING-902:
see also my suggestions in http://markmail.org/message/4nu226ueie25dxgt
> add java annotation support for sling scr components/servlets
> -
>
> Key: SLING-902
> URL: https://issues.apache.org/jira/browse/SLING-902
> Project: Sling
> Issue Type: New Feature
> Components: Servlets Resolver
>Reporter: Stefan Seifert
> Attachments: 090329_sling_scr_annotations.zip
>
>
> please note: this proposal depends on a felix-scr-plugin proposal described in
> https://issues.apache.org/jira/browse/FELIX-1010
> with the described scr plugin enhancement it is possible to define SCR
> component definitions via annotations. furthermore it is possible for
> felix/SCR based projects to define their own and less verbose annotations for
> specific need, together with a provider class mapping them to the SCR tags
> needed by the plugin internally.
> the attached zip file provides such a implemented for one new annotation
> "SlingServlet", see example below.
> i was not sure into which project and classpath this classes should be
> placed, so i attached a ZIP file for discussion and try-out. the best
> solution would be to split them up into two projects - one project containing
> only the annotation, and the other containing the provider and tag mapping.
> the first project has no dependencies and can be referenced by any other
> project needing the annotation. the second has to import the felix-scr-plugin
> as dependency, this results in a lot of transitive dependency not to be
> wished in a normal project.
> Example
> ---
> QDox version:
> /**
> * Sample servlet with sling mappings.
> *
> * @scr.component immediate="true"
> * @scr.service interface="javax.servlet.Servlet"
> * @scr.property name="sling.servlet.methods" value="GET"
> * @scr.property name="sling.servlet.resourceTypes"
> * value="/apps/test/components/samplecomponent"
> * @scr.property name="sling.servlet.extensions" values.0="html"
> values.1="json"
> */
> public class SlingServletQDox implements Servlet {
> Annotation version:
> /**
> * Sample servlet with sling mappings.
> */
> @SlingServlet(methods = "GET", resourceTypes =
> "/apps/test/components/samplecomponent", extensions = { "html", "json" })
> public class SlingServletAnnotation implements Servlet {
> Custom annotation mappings can be integrated by defining a class implementing
> "org.apache.felix.scrplugin.tags.annotation.AnnotationTagProvider" for the
> new plugin property "annotationTagProviders" in the pom.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: JSON Validation
On 3/28/09, Carsten Ziegeler wrote:
> Hi,
>
> while implementing the additional json validation to the sling maven
> plugin, I noticed that the current json commons module we have is very
> failure tolerant.
>
> It allows for example trailing separators, like in "{,}" or { a:"1",}
> It also allows duplicate keys like in "{a:"1",a:"2"}.
> I've looked at the latest code at JSON.org - the new code there at least
> throws an exception for duplicate keys while it still accepts the
> trailing separator.
> Now the json definition is imho clearly stating that a trailing
> separator is not allowed.
>
> While I'm all for not being failure tolerant to avoid any problems with
> possible other json code trying to parse this stuff, I'm not sure how we
> really should handle this.
> I think we should make the parsing as strict as possible (although this
> might introduce incompatibilities)
i agree partially - since the JSON parsing is only needed when reading
json from the initial content, or used as transport via http, it can
be really tolerant. rejecting duplicate keys might be an option, since
the result is undefined.
regards, toby
[jira] Commented: (SLING-538) SlingPropertyValueHelper.setPropertyAsIs() handles impossible empty-value-list case
[
https://issues.apache.org/jira/browse/SLING-538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12680619#action_12680619
]
Tobias Bocanegra commented on SLING-538:
the value handling should work like this:
prop = "foo"
p...@defaultvalue = "xyz"
--> set "foo"
prop = ""
p...@defaultvalue = "xyz"
--> set "xyz"
prop = ""
p...@defaultvalue = ":null"
--> remove
prop = ""
p...@defaultvalue = ":ignore"
--> don't create new values
the use case for the :ignore is the following:
if you have a form (basic html, no dhml or ajax) where you have several input
fields that are initially empty,
and you don't want to create all the properties if the user doesn't fill them,
then you need the ":ignore", since the
browser sends a value for all fields that are not disabled.
if the properties already have a value, then you want the empty string to clear
them (:ignore) or even remove them (:null).
so i guess, this code is correct, but maybe a bit a questionable use case.
> SlingPropertyValueHelper.setPropertyAsIs() handles impossible
> empty-value-list case
> ---
>
> Key: SLING-538
> URL: https://issues.apache.org/jira/browse/SLING-538
> Project: Sling
> Issue Type: Bug
> Components: Servlets Post
>Reporter: Alexander Klimetschek
>Assignee: Carsten Ziegeler
>Priority: Minor
> Attachments: SLING-538.patch
>
>
> The list of values of the request property can never have the length of null
> - RequestProperty.getStringValues() ensures this, and it also does not make
> any sense with form posts, since a request parameter must always have at
> least one value, otherwise it would simply not exist in the request. So this
> code is superfluous (also for single-value property handling):
> } else if (values.length == 0) {
> // do not create new prop here, but clear existing
> if (parent.hasProperty(prop.getName())) {
> response.onModified(
> parent.setProperty(prop.getName(), "").getPath()
> );
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-590) Add resource.adaptTo(ValueMap.class) to page context attributes
[ https://issues.apache.org/jira/browse/SLING-590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12679593#action_12679593 ] Tobias Bocanegra commented on SLING-590: while a think that backward compatibility is important, some sacrifices need to be done, too. if this is marked clearly, i'd had no problem with it. the 2nd solution is good, too. but it would invert the flag. so that people running into problems can easily turn that off. however, what about an other default name, like: - resourceProperties ? - resourceMap > Add resource.adaptTo(ValueMap.class) to page context attributes > --- > > Key: SLING-590 > URL: https://issues.apache.org/jira/browse/SLING-590 > Project: Sling > Issue Type: New Feature > Components: Scripting JSP >Affects Versions: Scripting JSP-Taglib 2.0.2 >Reporter: Tobias Bocanegra >Assignee: Carsten Ziegeler >Priority: Minor > Fix For: Scripting JSP-Taglib 2.0.4 > > > should add a 'properties' as page context variable from > resource.adaptTo(ValueMap.class) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] Source Tree Restructuring
On 2/18/09, Carsten Ziegeler wrote: > Tobias Bocanegra wrote: > > just out of curiosity: why is jcrinstall not in "jcr" ? i find it > > awkward, that a JCR based framework keeps a JCR based bundle/config > > loading in "contrib" :-) > > :) > > Actually I agree that jcrinstall should be moved into jcr but into > contrib/jcr :) We're moving all stuff which is not ready to be released > into the contrib folder and jcrinstall is one of them. why not "promote" certain extensions ? > > > Carsten > -- > Carsten Ziegeler > cziege...@apache.org >
Re: [VOTE] Source Tree Restructuring
just out of curiosity: why is jcrinstall not in "jcr" ? i find it awkward, that a JCR based framework keeps a JCR based bundle/config loading in "contrib" :-) regards, toby On 2/17/09, Carsten Ziegeler wrote: > Hi, > > we recently discussed the new structure for our source tree. To finalize > this, I'll start this vote (lazy consensus applies). > > The following is the initial setup - we can of course move a bundle to > one or the other location after the initial restructuring. But as we are > heading for a release real soon now, we should do this asap! > > The outline above splits up the integration tests for the bundles and > the contrib area (both tests are in the corresponding launchpad > directories). This is in order to be able to build and test Sling > without the contrib stuff. The contrib stuff will be buildable by a > profile - as well as the example. > > So please cast your votes. > > > trunk/ > +-- maven (Maven Plugins) > +-- parent/ (Parent Project) > +-- launchpad (Launchpad Application) > +-- app > +-- webapp > +-- base > +-- bundles > +-- content > +-- tests > +-- bundles/ > +-- api (The Sling API) > +-- engine (The Sling Core Engine) > +-- scripting (ScriptEngines) > +-- api > +-- core > +-- javascript > +-- jsp > +-- jsp-taglib > +-- commons (Helper libraries) > +-- log > +-- json > +-- osgi > +-- mime > +-- testing > +-- scheduler > +-- threads > +-- jcr (JCR related modules) > +-- api > +-- base > +-- classloader > +-- contentloader > +-- jackrabbit-api > +-- jackrabbit-server > +-- ocm > +-- resource > +-- webdav > +-- servlets (Servlet Support) > +-- get > +-- post > +-- resolver > +-- extensions (Extension bundles) > +-- adapter > +-- bundleresource > +-- httpauth > +-- event > +-- openidauth > +-- threaddump > +-- contrib (Contributions etc.) > +-- commons > +-- scripting (ScriptEngines) >+-- freemarker >+-- java >+-- jst >+-- python >+-- ruby >+-- scala >+-- velocity > +-- jcr (JCR related modules) >+-- jackrabbit-client > +-- launchpad (Launchpad Application) >+-- jcrapp >+-- testing (contrib stuff) > +-- extensions (Extension bundles) >+-- apt >+-- dojo >+-- dojo-sling >+-- i18n >+-- gwt >+-- jcrinstall >+-- obr (OBR Server, was osgi/obr) >+-- runmode > +-- samples > +-- ... existing samples ... > > Thanks > Carsten > > -- > Carsten Ziegeler > cziege...@apache.org >
[jira] Commented: (SLING-848) Support getting versioned resources by using uri path parameters
[ https://issues.apache.org/jira/browse/SLING-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12672286#action_12672286 ] Tobias Bocanegra commented on SLING-848: > Resource.adaptTo(Version.class): This would be > Resource.adaptTo(Node.class).getBaseVersion(), right ? no, the node addressed by the versioned path is the jcr:frozenNode of the version. so actually it would be: Resource.adaptTo(Node.class).getParent() > Support getting versioned resources by using uri path parameters > > > Key: SLING-848 > URL: https://issues.apache.org/jira/browse/SLING-848 > Project: Sling > Issue Type: New Feature > Components: JCR Resource >Affects Versions: JCR Resource 2.0.2 >Reporter: Carsten Ziegeler > > Getting versioned content should be support thorough uri path parameters, > like /something/hello;v=1.1 > For jcr based resources the value of the version should either point to a > version name or label. > In order to not change our existing apis, we introduce a new utility method > which removes all uri path parameters > and returns a map of these. Every resource provider could use this utility > method and then decide to act on these > parameters. > If a requested version does not exists, a 404 is returned. > If the requested node does not directly point to a versionable node, the > algorithm checks the parent hierarchy until a versionable node is found, and > tries to get the version of this node and then goes down the path again. If > the versionable node does not have the requested version or the child, a 404 > is returned. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-848) Support getting versioned resources by using uri path parameters
[ https://issues.apache.org/jira/browse/SLING-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12672270#action_12672270 ] Tobias Bocanegra commented on SLING-848: i'm still not convinced that this does not lead to severe inconsistencies in the way resources are used. to achieve better stability, i also suggest to * mark those resources clearly with an own interface, eg: VersionedResource * add Resource.getName() which returns the last segment of the path, without any parameter * versioned resource should be adaptable to javax.jcr.Version (although this is NOT the actual resource, i.e. frozen node) > Support getting versioned resources by using uri path parameters > > > Key: SLING-848 > URL: https://issues.apache.org/jira/browse/SLING-848 > Project: Sling > Issue Type: New Feature > Components: JCR Resource >Affects Versions: JCR Resource 2.0.2 >Reporter: Carsten Ziegeler > > Getting versioned content should be support thorough uri path parameters, > like /something/hello;v=1.1 > For jcr based resources the value of the version should either point to a > version name or label. > In order to not change our existing apis, we introduce a new utility method > which removes all uri path parameters > and returns a map of these. Every resource provider could use this utility > method and then decide to act on these > parameters. > If a requested version does not exists, a 404 is returned. > If the requested node does not directly point to a versionable node, the > algorithm checks the parent hierarchy until a versionable node is found, and > tries to get the version of this node and then goes down the path again. If > the versionable node does not have the requested version or the child, a 404 > is returned. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-850) PostServlet :order does not set any changes
PostServlet :order does not set any changes --- Key: SLING-850 URL: https://issues.apache.org/jira/browse/SLING-850 Project: Sling Issue Type: Bug Components: Servlets Post Affects Versions: Servlets Post 2.0.2 Reporter: Tobias Bocanegra Priority: Minor when sending a POST with only an order parameter, no changes are recorded. eg: POST /content/a :order before b i see 3 solutions: 1) either a new modification type "order" should be added, 2) or the parent node (/content) should be marked as modified 3) or it should be recorded as move where src and dst are equals. possibly with an extra argument which reflects the "before" node. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-848) Support getting versioned resources by using uri path parameters
[ https://issues.apache.org/jira/browse/SLING-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12670740#action_12670740 ] Tobias Bocanegra commented on SLING-848: > content/home/tobi.selector.html?sling:v=1.5 that's what i meant. > Support getting versioned resources by using uri path parameters > > > Key: SLING-848 > URL: https://issues.apache.org/jira/browse/SLING-848 > Project: Sling > Issue Type: New Feature > Components: JCR Resource >Affects Versions: JCR Resource 2.0.2 >Reporter: Carsten Ziegeler > > Getting versioned content should be support thorough uri path parameters, > like /something/hello;v=1.1 > For jcr based resources the value of the version should either point to a > version name or label. > In order to not change our existing apis, we introduce a new utility method > which removes all uri path parameters > and returns a map of these. Every resource provider could use this utility > method and then decide to act on these > parameters. > If a requested version does not exists, a 404 is returned. > If the requested node does not directly point to a versionable node, the > algorithm checks the parent hierarchy until a versionable node is found, and > tries to get the version of this node and then goes down the path again. If > the versionable node does not have the requested version or the child, a 404 > is returned. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-848) Support getting versioned resources by using uri path parameters
[ https://issues.apache.org/jira/browse/SLING-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12670288#action_12670288 ] Tobias Bocanegra commented on SLING-848: that's was i feared. using the ; parameters is not widely used, and causes problems, as marc pointed out. i think it's ok to use the parameters for the resource resolver - but then you can also extend the api. i would avoid using them on the URI from the request, especially, because the generation of such links is a bit special. i'd rather see a "global" query parameter or cookie that controls the version selection. > Support getting versioned resources by using uri path parameters > > > Key: SLING-848 > URL: https://issues.apache.org/jira/browse/SLING-848 > Project: Sling > Issue Type: New Feature > Components: JCR Resource >Affects Versions: JCR Resource 2.0.2 >Reporter: Carsten Ziegeler > > Getting versioned content should be support thorough uri path parameters, > like /something/hello;v=1.1 > For jcr based resources the value of the version should either point to a > version name or label. > In order to not change our existing apis, we introduce a new utility method > which removes all uri path parameters > and returns a map of these. Every resource provider could use this utility > method and then decide to act on these > parameters. > If a requested version does not exists, a 404 is returned. > If the requested node does not directly point to a versionable node, the > algorithm checks the parent hierarchy until a versionable node is found, and > tries to get the version of this node and then goes down the path again. If > the versionable node does not have the requested version or the child, a 404 > is returned. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (SLING-848) Support getting versioned resources by using uri path parameters
[ https://issues.apache.org/jira/browse/SLING-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12670136#action_12670136 ] tripod edited comment on SLING-848 at 2/3/09 2:06 PM: so consequently (according to rfc3986) , the v= parameter should be applicable to each segment. eg: /content/home;v=1.0/tobi;v=1.5 (assuming /content/home/tobi is currently deleted and did only exist in the version 1.0 of the 'home') what is the "external" form of this?, probably: /content/home;v=1.0/tobi.html;v=1.5 having the .html at the end makes no sense. but this makes every script logic that just appends the .html to the resource path pretty useless. the problem you have is: - if you include the v= to the resource.getPath() the resource gets unusable for "normal" scripts, - if you omit it from the path, the getResource() / getPath() is not symmetric so maybe this is not such a good idea after all? btw: i think the "component" of this issue is wrong. was (Author: tripod): so consequently (according to rfc3986) , the v= parameter should be applicable to each segment. eg: /content/home;v=1.0/tobi;v=1.5 (assuming /content/home/tobi is currently deleted and did only exist in the version 1.0 of the 'home') what is the "external" form of this?, probably: /content/home;v=1.0/tobi.html;v=1.5 having the .html at the end makes no sense. but this makes each script logic that just appends the .html to the resource path pretty useless. the problem you have is: - if you include the v= to the resource.getPath() the resource gets unusable for "normal" scripts, - if you omit it from the path, the getResource() / getPath() is not symmetric so maybe this is not such a good idea after all? btw: i think the "component" of this issue is wrong. > Support getting versioned resources by using uri path parameters > > > Key: SLING-848 > URL: https://issues.apache.org/jira/browse/SLING-848 > Project: Sling > Issue Type: New Feature > Components: JCR Install >Affects Versions: JCR Resource 2.0.2 >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Fix For: JCR Resource 2.0.4 > > > Getting versioned content should be support thorough uri path parameters, > like /something/hello;v=1.1 > For jcr based resources the value of the version should either point to a > version name or label. > In order to not change our existing apis, we introduce a new utility method > which removes all uri path parameters > and returns a map of these. Every resource provider could use this utility > method and then decide to act on these > parameters. > If a requested version does not exists, a 404 is returned. > If the requested node does not directly point to a versionable node, the > algorithm checks the parent hierarchy until a versionable node is found, and > tries to get the version of this node and then goes down the path again. If > the versionable node does not have the requested version or the child, a 404 > is returned. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-848) Support getting versioned resources by using uri path parameters
[ https://issues.apache.org/jira/browse/SLING-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12670136#action_12670136 ] Tobias Bocanegra commented on SLING-848: so consequently (according to rfc3986) , the v= parameter should be applicable to each segment. eg: /content/home;v=1.0/tobi;v=1.5 (assuming /content/home/tobi is currently deleted and did only exist in the version 1.0 of the 'home') what is the "external" form of this?, probably: /content/home;v=1.0/tobi.html;v=1.5 having the .html at the end makes no sense. but this makes each script logic that just appends the .html to the resource path pretty useless. the problem you have is: - if you include the v= to the resource.getPath() the resource gets unusable for "normal" scripts, - if you omit it from the path, the getResource() / getPath() is not symmetric so maybe this is not such a good idea after all? btw: i think the "component" of this issue is wrong. > Support getting versioned resources by using uri path parameters > > > Key: SLING-848 > URL: https://issues.apache.org/jira/browse/SLING-848 > Project: Sling > Issue Type: New Feature > Components: JCR Install >Affects Versions: JCR Resource 2.0.2 >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Fix For: JCR Resource 2.0.4 > > > Getting versioned content should be support thorough uri path parameters, > like /something/hello;v=1.1 > For jcr based resources the value of the version should either point to a > version name or label. > In order to not change our existing apis, we introduce a new utility method > which removes all uri path parameters > and returns a map of these. Every resource provider could use this utility > method and then decide to act on these > parameters. > If a requested version does not exists, a 404 is returned. > If the requested node does not directly point to a versionable node, the > algorithm checks the parent hierarchy until a versionable node is found, and > tries to get the version of this node and then goes down the path again. If > the versionable node does not have the requested version or the child, a 404 > is returned. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-848) Support getting versioned resources by using uri path parameters
[
https://issues.apache.org/jira/browse/SLING-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12669988#action_12669988
]
Tobias Bocanegra commented on SLING-848:
but do you want to add this to the resource resolver, or the request resolver?
so should a ResourceResolver.getResource("/something/hello;v=1.1") return a
different version?
or should a request to "/something/hello.html;v=1.1" trigger a resource
resolution to the respective version? (which eventually needs the former, too)
> Support getting versioned resources by using uri path parameters
>
>
> Key: SLING-848
> URL: https://issues.apache.org/jira/browse/SLING-848
> Project: Sling
> Issue Type: New Feature
> Components: JCR Install
>Affects Versions: JCR Resource 2.0.2
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: JCR Resource 2.0.4
>
>
> Getting versioned content should be support thorough uri path parameters,
> like /something/hello;v=1.1
> For jcr based resources the value of the version should either point to a
> version name or label.
> In order to not change our existing apis, we introduce a new utility method
> which removes all uri path parameters
> and returns a map of these. Every resource provider could use this utility
> method and then decide to act on these
> parameters.
> If a requested version does not exists, a 404 is returned.
> If the requested node does not directly point to a versionable node, the
> algorithm checks the parent hierarchy until a versionable node is found, and
> tries to get the version of this node and then goes down the path again. If
> the versionable node does not have the requested version or the child, a 404
> is returned.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-848) Support getting versioned resources by using uri path parameters
[ https://issues.apache.org/jira/browse/SLING-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12669953#action_12669953 ] Tobias Bocanegra commented on SLING-848: you mean: something/hello.html;v=1.1 ? this will set a resource resolver option v=1.1 ? so in general, the resource resolver should have a new method: getResource(String path, Sring versionName) or should there be a 'VersionSelector' interface, that is resposible to select the proper version for a requested path? > Support getting versioned resources by using uri path parameters > > > Key: SLING-848 > URL: https://issues.apache.org/jira/browse/SLING-848 > Project: Sling > Issue Type: New Feature > Components: JCR Install >Affects Versions: JCR Resource 2.0.2 >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Fix For: JCR Resource 2.0.4 > > > Getting versioned content should be support thorough uri path parameters, > like /something/hello;v=1.1 > For jcr based resources the value of the version should either point to a > version name or label. > In order to not change our existing apis, we introduce a new utility method > which removes all uri path parameters > and returns a map of these. Every resource provider could use this utility > method and then decide to act on these > parameters. > If a requested version does not exists, a 404 is returned. > If the requested node does not directly point to a versionable node, the > algorithm checks the parent hierarchy until a versionable node is found, and > tries to get the version of this node and then goes down the path again. If > the versionable node does not have the requested version or the child, a 404 > is returned. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-809) Add possibility to force a reprocess of an queued job entry
[ https://issues.apache.org/jira/browse/SLING-809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tobias Bocanegra updated SLING-809: --- Comment: was deleted > Add possibility to force a reprocess of an queued job entry > --- > > Key: SLING-809 > URL: https://issues.apache.org/jira/browse/SLING-809 > Project: Sling > Issue Type: New Feature > Components: Event >Affects Versions: Extensions Event 2.0.2 >Reporter: Tobias Bocanegra >Assignee: Carsten Ziegeler > Fix For: Extensions Event 2.0.4 > > > A FIFO job event queue processes the jobs in proper sequence. when a job > cannot be processed it can be scheduled for retry after a certain period. > when the queue waits for that retry delay to pass, new job can be added to > the queue. sometime it might be useful to bypass the wait time "manually" and > let the queue re-process the job immediately. for example after a config > change or per user-interaction via a GUI. > add something like: > JobStatusProvider.forceReProcess(String queueName) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-809) Add possibility to force a reprocess of an queued job entry
[ https://issues.apache.org/jira/browse/SLING-809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12667986#action_12667986 ] Tobias Bocanegra commented on SLING-809: danke! ich probiers gleich aus. gruss,t > Add possibility to force a reprocess of an queued job entry > --- > > Key: SLING-809 > URL: https://issues.apache.org/jira/browse/SLING-809 > Project: Sling > Issue Type: New Feature > Components: Event >Affects Versions: Extensions Event 2.0.2 >Reporter: Tobias Bocanegra >Assignee: Carsten Ziegeler > Fix For: Extensions Event 2.0.4 > > > A FIFO job event queue processes the jobs in proper sequence. when a job > cannot be processed it can be scheduled for retry after a certain period. > when the queue waits for that retry delay to pass, new job can be added to > the queue. sometime it might be useful to bypass the wait time "manually" and > let the queue re-process the job immediately. for example after a config > change or per user-interaction via a GUI. > add something like: > JobStatusProvider.forceReProcess(String queueName) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-838) Remove/reduce 90 seconds wait time
Remove/reduce 90 seconds wait time -- Key: SLING-838 URL: https://issues.apache.org/jira/browse/SLING-838 Project: Sling Issue Type: Wish Components: Event Reporter: Tobias Bocanegra the current event processor waits 90 seconds (since service activation) until it start processing jobs. this might be too long for small/fast systems, or even too low for very big/slow systems. especially job processing should start as soon the respective queue listeners are registered. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-832) ValueMapDecorator does not support arrays.
[
https://issues.apache.org/jira/browse/SLING-832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tobias Bocanegra updated SLING-832:
---
Attachment: ValueMapDecorator.r735030.patch
fixes this issues by supported array types.
> ValueMapDecorator does not support arrays.
> --
>
> Key: SLING-832
> URL: https://issues.apache.org/jira/browse/SLING-832
> Project: Sling
> Issue Type: Improvement
> Components: API
>Affects Versions: Scripting API 2.0.2
>Reporter: Tobias Bocanegra
> Attachments: ValueMapDecorator.r735030.patch
>
>
> albeit the JcrPropertyMap supports arrays, the wrapper does not and yields to
> unexpected problems when using it.
> eg: i use the following code, to get a detached copy of a jcr property map:
> Node content = node.getNode("jcr:content");
> ValueMap props = new JcrPropertyMap(content);
> // create detached copy
> ValueMap properties = new ValueMapDecorator(new
> HashMap(props));
> and the following does not work:
>String[] values = properties.get("myProp", new String[0]);
> although it works on the JcrPropertyMap
> ps: will provide a 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-832) ValueMapDecorator does not support arrays.
ValueMapDecorator does not support arrays.
--
Key: SLING-832
URL: https://issues.apache.org/jira/browse/SLING-832
Project: Sling
Issue Type: Improvement
Components: API
Affects Versions: Scripting API 2.0.2
Reporter: Tobias Bocanegra
albeit the JcrPropertyMap supports arrays, the wrapper does not and yields to
unexpected problems when using it.
eg: i use the following code, to get a detached copy of a jcr property map:
Node content = node.getNode("jcr:content");
ValueMap props = new JcrPropertyMap(content);
// create detached copy
ValueMap properties = new ValueMapDecorator(new HashMap(props));
and the following does not work:
String[] values = properties.get("myProp", new String[0]);
although it works on the JcrPropertyMap
ps: will provide a patch
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Script Naming Convention
On 1/16/09, Felix Meschberger wrote: > Hi all, > > Prompted by Shane Johnson's comments on the naming conventions for > servlets in the repository [1], I come to think, that there might be > another solution or way to look at it. > > Currently a script must basically be named according to the following > convention: > >[ selector "." ] method | >[ selector "." ] extension | // GET only >selector // GET html only > > All matches are done case-sensitive. This works find with general > scripts, which may have as many dots in the file name as we like. For > Servlets (stored in the repository) it is more problematic, since class > files must be named after ther class name and class names are not > allowed to have dots in it. > > To workaround this, I could imagine, that we extend the convention for > script file names: > >[ selector "." ] method | >Selector method | >[ selector "." ] extension | // GET only >Selector Extension | // GET only >selector | // GET html only >Selector // GET html only > > (uppercase signifies camelcased name). > > So the request "GET /some/path.print.html" could be handled by any of > the following scripts > >path.GET.jsp >GET.jsp >PathGET.java >path.html.esp >html.esp >PathHtml.vlt >path.gsp >Path.groovy > > This would of course extend the list of checks to apply for finding > scripts, but would certainly gelp Java developers. > > The drawback of this is, that the request "GET /path.PrintA4.html" might > be handled by the same script as "GET /path.Print.A4.html". But this may > be a hypothetical collision and problem. > > WDYT ? i like this idea. with the scripted servlets, you get the "power" of servlets, and the ease-of-use for deployment and development as with jsps. until now, the only draw back is that the class and package names mess up the IDE. so this solution is great. regards, toby
Re: Can't use some JCR classes in Sling
hi josh, only the packages exported by the bundles or the ones specified as bootclasspath (via sling.properties config) are visible by other bundles and jsps. in this case it's a bit difficult, since the crx-explorer stuff is not available as bundle and i doubt that it will work. why would you need to CRXContext in a non-crx webapp ? regards, toby On 1/5/09, Joshua Oransky wrote: > Is there a reason I keep getting this error in my JSP sling templates? > > org.apache.sling.scripting.jsp.jasper.JasperException: > Unable to compile class for JSP: An error occurred at line: 1 in the jsp > file: /apps/cms/admin/global/replicate.jsp > com.day.crx.j2ee.CRXContext cannot be resolved to a type null > > I've tried importing specifically, and even fully qualifying the class name > in my JSP code, to no avail. > > -Josh >
[jira] Created: (SLING-809) Add possibility to force a reprocess of an queued job entry
Add possibility to force a reprocess of an queued job entry --- Key: SLING-809 URL: https://issues.apache.org/jira/browse/SLING-809 Project: Sling Issue Type: New Feature Components: Event Affects Versions: Extensions Event 2.0.2 Reporter: Tobias Bocanegra A FIFO job event queue processes the jobs in proper sequence. when a job cannot be processed it can be scheduled for retry after a certain period. when the queue waits for that retry delay to pass, new job can be added to the queue. sometime it might be useful to bypass the wait time "manually" and let the queue re-process the job immediately. for example after a config change or per user-interaction via a GUI. add something like: JobStatusProvider.forceReProcess(String queueName) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-799) Job Folder is not ordered and results in unordered queue
[
https://issues.apache.org/jira/browse/SLING-799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12660456#action_12660456
]
Tobias Bocanegra commented on SLING-799:
> now I would prefer to use a sorted query
why a query? iterating over the child nodes should be sufficient.
> An ordered collection in jcr only means that it is "somehow" ordered.
i disagree. i would leverage the ordering capability of the repository and rely
on the node ordering.
this has also the advantage that you don't need to have (and calculate) a
sequence number, which can be difficult to obtain in the cluster scenario.
> Job Folder is not ordered and results in unordered queue
>
>
> Key: SLING-799
> URL: https://issues.apache.org/jira/browse/SLING-799
> Project: Sling
> Issue Type: Bug
> Components: Event
>Affects Versions: Extensions Event 2.0.2
>Reporter: Tobias Bocanegra
>
> check code of
> AbstractRepositoryEventHandler.ensureRepositoryPath()
> /**
> * Check if the repository path already exists. If not, create it.
> */
> protected Node ensureRepositoryPath()
> throws RepositoryException {
> final Node node = JcrResourceUtil.createPath(this.repositoryPath,
>EventHelper.NODETYPE_FOLDER,
>EventHelper.NODETYPE_FOLDER,
>this.writerSession, true);
> return node;
> }
> this should use a "sling:OrderedFolder"
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-799) Job Folder is not ordered and results in unordered queue
[
https://issues.apache.org/jira/browse/SLING-799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12660385#action_12660385
]
Tobias Bocanegra commented on SLING-799:
the net effect should be that the JobStatusProvider.getAllJobs(...) should
return an ordered collection of the jobs in the same sequence as they were
scheduled.
> Job Folder is not ordered and results in unordered queue
>
>
> Key: SLING-799
> URL: https://issues.apache.org/jira/browse/SLING-799
> Project: Sling
> Issue Type: Bug
> Components: Event
>Affects Versions: Extensions Event 2.0.2
>Reporter: Tobias Bocanegra
>
> check code of
> AbstractRepositoryEventHandler.ensureRepositoryPath()
> /**
> * Check if the repository path already exists. If not, create it.
> */
> protected Node ensureRepositoryPath()
> throws RepositoryException {
> final Node node = JcrResourceUtil.createPath(this.repositoryPath,
>EventHelper.NODETYPE_FOLDER,
>EventHelper.NODETYPE_FOLDER,
>this.writerSession, true);
> return node;
> }
> this should use a "sling:OrderedFolder"
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-799) Job Folder is not ordered and results in unordered queue
Job Folder is not ordered and results in unordered queue
Key: SLING-799
URL: https://issues.apache.org/jira/browse/SLING-799
Project: Sling
Issue Type: Bug
Components: Event
Affects Versions: Extensions Event 2.0.2
Reporter: Tobias Bocanegra
check code of
AbstractRepositoryEventHandler.ensureRepositoryPath()
/**
* Check if the repository path already exists. If not, create it.
*/
protected Node ensureRepositoryPath()
throws RepositoryException {
final Node node = JcrResourceUtil.createPath(this.repositoryPath,
EventHelper.NODETYPE_FOLDER,
EventHelper.NODETYPE_FOLDER,
this.writerSession, true);
return node;
}
this should use a "sling:OrderedFolder"
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-797) EventUtil.getNodePropertyValue wrong check for basic types
EventUtil.getNodePropertyValue wrong check for basic types -- Key: SLING-797 URL: https://issues.apache.org/jira/browse/SLING-797 Project: Sling Issue Type: Bug Components: Event Affects Versions: Extensions Event 2.0.2 Reporter: Tobias Bocanegra Attachments: EventUtil-r712058.patch The type checks in getNodePropertyValue() are the wrong way around and never find the respective JCR property type. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-797) EventUtil.getNodePropertyValue wrong check for basic types
[ https://issues.apache.org/jira/browse/SLING-797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tobias Bocanegra updated SLING-797: --- Attachment: EventUtil-r712058.patch patch that fixes this issue. > EventUtil.getNodePropertyValue wrong check for basic types > -- > > Key: SLING-797 > URL: https://issues.apache.org/jira/browse/SLING-797 > Project: Sling > Issue Type: Bug > Components: Event >Affects Versions: Extensions Event 2.0.2 >Reporter: Tobias Bocanegra > Attachments: EventUtil-r712058.patch > > > The type checks in getNodePropertyValue() are the wrong way around and never > find the respective JCR property type. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Programmatically Triggering Replication
hi josh, this is not quite the correct place to ask this question :-) however, take a look at the browser/content.jsp in crx how to do it. regards, toby On 12/30/08, Joshua Oransky wrote: > How exactly can I programmatically trigger replication on a node on > CRX? > > I see the com.day.crx.replication.Replicator class, > but I don't know what to use as the configuration in its constructor. I > figure it's a mix of the getSyndicators() and the replicate() methods, but I > need to get access to the service first. > > Any help is appreciated! > > -Josh >
Re: User identity for event scripts (was: [jira] Created: (SLING-788)...)
On 12/19/08, Torgeir Veimo wrote: > > On 19 Dec 2008, at 23:44, Felix Meschberger wrote: > > > > > > Really, so then we have be slightly different: > > > > > > +--- admin > >+ crontab of admin > > +--- xyz > >+ crontab of user xyz > > > > > If you're sneaking in user management the back way, why not just define > user directories as /xyz and then define cron files to have > certain names, or live under /xyz/crontab or similar? > > User management is standard in most web application these days so it will > sooner or later find its way into sling in any case. i agree... having the crontabs below the user homes makes much more sense. regards, toby
[jira] Commented: (SLING-784) SlingPostServlet does not allow setting mixin types on existing nodes
[ https://issues.apache.org/jira/browse/SLING-784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12657739#action_12657739 ] Tobias Bocanegra commented on SLING-784: either you create a new node, and then you know all the mixins you want to set, or you alter en existing page, and then you read the mixins beforehand. so no need for @Add=mixin, or @Delete=mixin > SlingPostServlet does not allow setting mixin types on existing nodes > - > > Key: SLING-784 > URL: https://issues.apache.org/jira/browse/SLING-784 > Project: Sling > Issue Type: Improvement > Components: Servlets Post >Reporter: Alexander Saar > Attachments: post-servlet-change-mixins.diff > > > the current implementation of the sling POST servlet allows to specify mixin > node types when a new node is created, but it is not possible to add/change > mixin node types of existing nodes. I suggest to add this funtionality > because it is a common use case that you want to set properties which are > defined in mixin node types (eg adding some meta data to a file). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-784) SlingPostServlet does not allow setting mixin types on existing nodes
[ https://issues.apache.org/jira/browse/SLING-784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12657520#action_12657520 ] Tobias Bocanegra commented on SLING-784: imo the mixins should work the same as other MV properties. eg: POST /test ./title = "Hello" --> no mixins altered POST/ /test ./title = "hello" ./jcr:mixinTypes = "a" ./jcr:mixinTypes = "b" --> has the effect, that "test' has the mixins "a" and "b" irrespective what it had before POST/ /test ./title = "hello" ./jcr:mixinty...@delete --> removes all mixins from 'test' > SlingPostServlet does not allow setting mixin types on existing nodes > - > > Key: SLING-784 > URL: https://issues.apache.org/jira/browse/SLING-784 > Project: Sling > Issue Type: Improvement > Components: Servlets Post >Reporter: Alexander Saar > Attachments: post-servlet-change-mixins.diff > > > the current implementation of the sling POST servlet allows to specify mixin > node types when a new node is created, but it is not possible to add/change > mixin node types of existing nodes. I suggest to add this funtionality > because it is a common use case that you want to set properties which are > defined in mixin node types (eg adding some meta data to a file). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [RT] Handling html output
On 12/14/08, Carsten Ziegeler wrote: > Tobias Bocanegra wrote: > > what's wrong with commons-lang StringEscapeUtils.escapeHTML [0] ? > > or with jstl c:out [1] ? > > Nothing, but it adds another dependency. Writing an escape function is > not rocket science, so we might rather add our own instead of adding > a dep to another lib just because of ten lines of code. for 1 escaping, yes, for 5 escapings not :-) > >> 5. Optional: we could add a method to HtmlEncodingValueMap which allows > >> to get the unencoded value. > > i would rather add a method that gives access to the underlying map, eg: > > ValueMap getUnencodedMap() > > Yepp, sounds good. > > > > from my experience you usually need both during the "lifetime" of a > > jsp. i would find it irritating, if i need to deal with 2 maps. > > Yes, this depends on your use case - from my experience you really > rarely need unescaped output - but of course everyone has a different > backgroudn. > > > > i would rather have a new methods on ValueMap, like: > > > > T getHtmlEscaped(java.lang.String s, java.lang.Class tClass); > > > > T getHtmlEscaped(java.lang.String s, T t); > > Yes, but the value map is an interface implemented by resource > providers. Resource providers do not care about any output format, being > this html, xml, pdf, whatever. We would end up with adding special > methods for each "relevant" output format. And in turn require > implementors to implement these methods over and over again instead of > doing it exactly once for an output format. ok. but then i would rather add a public class, like: EscapingValueMap that just wrapps any value map, eg: EscapingValueMap myMap = new EscapingValueMap(valueMap, Escaping.HTML); this can be a simple helper class and does not need to have an adapter factory at all. regards, toby
Re: [RT] Handling html output
hi all,
On 12/13/08, Carsten Ziegeler wrote:
> Hi,
>
> currently we don't have support in Sling for encoding outputted text
> according to HTML. Values of properties are directly written into the
> output stream. If these values contain angle brackets the content will
> be written out as an html tag which is usally not what you want.
> So the correct way is to encode outgoing text. Now, it's usually up to
> the application developer to decide if something needs to be escaped or
> not. Usually most of the text is escaped will sometimes it might make
> sense to not escape as you might have stored html snippets that you want
> to directly include.
>
> The usage of the encoding should be as easy as possible and nearly
> require no extra work for the app developer. I briefly discussed this
> with Felix and we came up with this idea:
>
> 1. We add a new utility class RequestUtil to the API and add a static
> method encodeHTML(String) to this utility class.
what's wrong with commons-lang StringEscapeUtils.escapeHTML [0] ?
or with jstl c:out [1] ?
> 2. We add a new interface HtmlEncodingValueMap which extends the
> ValueMap interface and is just a marker interface. The idea is that impl
> of this interface act like a value map but encode all string values to html.
>
> 3. We add a new adapter factory which maps a resource to a
> HtmlEncodingValueMap. The implementation will adapt the resource to a
> ValueMap and add a wrapper around the value map which implements the
> html encoding.
>
> 4. We add an utility method to the ResourceUtil class to directly get a
> HtmlEncodingValueMap for a resource like we have the getValueMap already.
>
> 5. Optional: we could add a method to HtmlEncodingValueMap which allows
> to get the unencoded value.
i would rather add a method that gives access to the underlying map, eg:
ValueMap getUnencodedMap()
> So whenever you output html, you use the html encoding value map. Only
> if you know that you want to output html snippets and you're really sure
> that the snipped is not malicous, you use the value map.
from my experience you usually need both during the "lifetime" of a
jsp. i would find it irritating, if i need to deal with 2 maps.
i would rather have a new methods on ValueMap, like:
T getHtmlEscaped(java.lang.String s, java.lang.Class tClass);
T getHtmlEscaped(java.lang.String s, T t);
or with an extra boolean parameter:
T get(java.lang.String s, java.lang.Class tClass, boolean
escapeHtml);
T get(java.lang.String s, T t, boolean escapeHtml);
or to have it more generic, with a typed escape marker, eg:
T get(java.lang.String s, java.lang.Class tClass, Escaping esc);
T get(java.lang.String s, T t, boolean, Escaping esc);
Escaping enum { NONE, XML, HTML, URL, JAVA, JAVA_SCRIPT }
btw: i find that full HTML escaping, i.e. replace all special
characters by their ISO equivalents is overkill, and not needed just
to have proper HTML.
regards, toby
[0]
http://commons.apache.org/lang/api/org/apache/commons/lang/StringEscapeUtils.html#escapeHtml(java.lang.String)
[1] http://java.sun.com/products/jsp/jstl/1.1/docs/tlddocs/c/out.html
[jira] Commented: (SLING-760) Filter characters in http error messages
[ https://issues.apache.org/jira/browse/SLING-760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12653712#action_12653712 ] Tobias Bocanegra commented on SLING-760: me neither - i think it's the task of the respective error handler. otherwise you'll have to unescape the message again, in order to get the correct one. > Filter characters in http error messages > > > Key: SLING-760 > URL: https://issues.apache.org/jira/browse/SLING-760 > Project: Sling > Issue Type: Bug > Components: Servlets Get >Affects Versions: Engine 2.0.2 >Reporter: Bertrand Delacretaz >Priority: Minor > Fix For: Engine 2.0.4 > > > The default get servlet includes the supplied extension as is in the "No > renderer for extension" error page, it should filter it to avoid garbling the > error page depending on the extension. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: List of available resource types
On 11/28/08, Alexander Klimetschek <[EMAIL PROTECTED]> wrote: > IMHO a good practice for sling apps is to always define a node type > for all the resources (or at least a mixin) they will handle. This > node type > a) defines a sling:resourceType with a default value (but one that can > be changed later) and > b) which allows residual properties (for the full JCR flexibility - > although YMMV here). well, i think not :-) one power of sling is its flexibility when it comes to resource/script resolution. the hassle you have changing a node type is very big and defining a mixin does not make sense, since you normally create the node before you assign a mixin. changing a node type last is also troublesome - so i would stick to the very few nodetypes that are really needed. IMO you should only need 3: sling:Folder, nt:file for the hierarchy of the scripts, nt:unstructured for content. i still don't see the need for a list of all resource types. since each primary type, each node in /content, each node with a sling:resourceType property, each OCM mapped object can be a 'resource type'. so you would end up in a list of gazillion resource types which you would present in a UI ?? and if you just go for the scripts - you have a similar problem, since most of the scripts/servlets can render html. another issue you'll face is that you mandate that all the resources types need to provide a 'selector' script of you snippet. this is of course a natural idea, but results in problems as soon as you add more resource types. the new resource types needs to know about your snippet-selector and needs to provide one - otherwise it will destroy your snipped-aggregator. the only way to prevent this would be to extend it from your base resource type. regards, toby
Re: Servlet Resolution
On 11/26/08, Felix Meschberger <[EMAIL PROTECTED]> wrote: > Hi all, > > After the big reorganization of servlet resolution in April of this year > and some more experiences with using Sling, I propose the extension of > our servlet/script resolution process. > > Actually it is a single change only: Consider request selectors for all > requests. Currently request selectors are only considered for GET or > HEAD requests and ignored for any other requests. > > Over time use cases arose, which would be easier implementable if we > would support using selectors to influence servlet/script resolution for > all methods. > > Example: Say you are building an application providing a configurable > input form system. The most important configuration would be the action > upon form submission. Submitted forms are sent back to the resource > providing the form. The actual action would be encoded as a request > selector: > > For example we would like to be able to send a form based mail message. > We would have script "/apps/myapp/form/mail/POST.esp", which handles the > "myapp/form" resource type and is called using the "mail" selector. The > form itself together with some nice GUI surroundings etc. would be > stored in the /content/feedback resource. > > Now updating the /content/feedback resource should be handled by Sling's > default POST servlet. Thus POSTing to /content/feedback would update the > content. Submitting the form would POST to /content/feedback.mail.html > and should thus not store any form input but trigger the mail/POST.esp > script. > > I have prepared a prototype implementation of this new mechanism in my > sandbox at [1]. > > A nice side effect of this prototype is, that it is much simpler codewise. > > WDYT? +1 to allow selector mapping for all methods. regards, toby > > Regards > Felix > > [1] > > http://svn.apache.org/repos/asf/incubator/sling/whiteboard/fmeschbe/servlet_resolver >
Re: Making jcrinstall folder names runmode aware
On 11/17/08, Bertrand Delacretaz <[EMAIL PROTECTED]> wrote: > Hi, > > Currently the names of folders where jcrinstall looks for bundles and > configuration nodes are based on configurable regular expressions, > independent from the RunMode service. > > Rethinking that, I'd like to introduce a runmode-based naming > convention, so that jcrinstall would be configured by default to look > in these folders, using the existing configuration mechanism: > > /libs/*/install (* means "anything" here, not regexp notation) > /libs/*/config > (and same in /apps) > > And jcrinstall would also look in these folders if the current active > run modes (as provided by the RunMode service) are "foo, bar" > > /libs/*/install.foo > /libs/*/install.bar > /libs/*/config.foo > /libs/*/config.bar > (and same in /apps) > > I think this simplifies configuration, people can hopefully use the > defaults settings and drive the rest freely with run modes. > > WDYT? +1 good idea
[jira] Commented: (SLING-728) JcrInstall should prefer config in /apps/{xyz} over /libs/{xyz}
[
https://issues.apache.org/jira/browse/SLING-728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12646846#action_12646846
]
Tobias Bocanegra commented on SLING-728:
i will try to provide a patch...
> JcrInstall should prefer config in /apps/{xyz} over /libs/{xyz}
> ---
>
> Key: SLING-728
> URL: https://issues.apache.org/jira/browse/SLING-728
> Project: Sling
> Issue Type: Bug
> Components: JCR Install
>Affects Versions: JCR Install 2.0.4
>Reporter: Tobias Bocanegra
> Fix For: JCR Install 2.0.4
>
>
> currently jcrinstall does not respect the search paths correctly.
> the idea is, that configuration (and bundles) residing in /apps/{path} should
> win over /libs/{path}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-728) JcrInstall should prefer config in /apps/{xyz} over /libs/{xyz}
JcrInstall should prefer config in /apps/{xyz} over /libs/{xyz}
---
Key: SLING-728
URL: https://issues.apache.org/jira/browse/SLING-728
Project: Sling
Issue Type: Bug
Components: JCR Install
Affects Versions: JCR Install 2.0.4
Reporter: Tobias Bocanegra
Fix For: JCR Install 2.0.4
currently jcrinstall does not respect the search paths correctly.
the idea is, that configuration (and bundles) residing in /apps/{path} should
win over /libs/{path}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Replacing JcrResourceResolverFactory by a Sling ResourceResolverFactory
On 11/10/08, Alexander Klimetschek <[EMAIL PROTECTED]> wrote: > Hi all! > > > On Sun, Nov 9, 2008 at 11:35 PM, David Nuescheler <[EMAIL PROTECTED]> wrote: > > starting to expose services like access control on the resource tree is > > something that i find dangerous and problematic. access control should > > really be enforced at the data (jcr) layer > > > I think it's only the credentials that are passed through the resource > API, the underlying JCR will still provide the ACL handling. > > > > and slowly copying the entire jcr > > api into a proprietary resource api with the same feature set seriously > > is the wrong path. > > i would really like to get rid of the duality of these two api's that > > essentially > > will do the same same thing in the long run. > > > Currently main advantage of the resource tree in Sling is that it is > simpler to plug-in different implementations (eg. > bundleresourceprovider, external databases, external jcrs, etc.) than > with JCR (Jackrabbit) itself. but the main goal/focus of sling is to provide a framework for web development based on a JCR repository. "mounting" different technologies is the wrong approach. those resources should be virtualized on the repository level and not on the sling level. > Jackrabbit's SPI tries to simplify the > implementation of a JCR repository backend or adapter to an existing > repository or database, but it is still a lot of work and it is not > standardized on the JCR level. IMHO Sling could work on the JCR API if > the API itself would have > > 1) a "mount-repository"-feature (ie. allows to mount a remote JCR > inside the tree) and if you need that you can use a product that support virtual repositories and provide connectors to 3rd party technologies. > 2) if there was a pre-built implementation of the JCR API that just > requires to implement a simple filesystem-style API itself to quickly > implement simple things such as the bundleresourceprovider for eg. > loading classes from JARs while being still fully JCR compatible. that would be a 'filesystem/jar connector' :-) regards, toby
[jira] Created: (SLING-723) Add configuration to default GET servlet to produce other kinds of responses.
Add configuration to default GET servlet to produce other kinds of responses.
-
Key: SLING-723
URL: https://issues.apache.org/jira/browse/SLING-723
Project: Sling
Issue Type: Improvement
Components: Servlets Get
Reporter: Tobias Bocanegra
it would be desirable to configure the default behavior for the default GET
servlet. eg:
report=dump -> wil generate some sort of dump (as it does today)
report=dirlisting -> will generate a dir listing of the subnodes.
report={number} -> send an error, eg: 403
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: adding namespaces via a URL query
On 10/29/08, Dan Tenenbaum <[EMAIL PROTECTED]> wrote: > Is it possible? Similarly, can one add a node type via a URL query? unfortunately, not. regards, toby
Re: Can't get JSPs to execute
hi, can you check the node type of the jcr:content node of your jsp file? if it's nt:unstructured, try to change it to nt:resource and see if it works. regards, toby On 10/29/08, Joshua Oransky <[EMAIL PROTECTED]> wrote: > I'm at a loss here... for some reason, I can not get JSPs to execute... a > file with just text in it, and an ESP extension outputs the text. Change the > extension, and Sling acts like the file isn't there, and just dumps the > node. Even the Notes app from dev.day.com doesn't work... but somehow the > CRX app JSPs are still working... > > Any ideas? > > -Josh >
Re: SlingRepository: Dropping Session Pooling
On 10/21/08, Felix Meschberger <[EMAIL PROTECTED]> wrote: > Hi all, > > Just out of curiosity, I profiled, my stupid test. And this profiling > revealed an intersting situation > > Without the session pool, logging out is fast. Logging in is not that > fast at all. > > With the session pool, logging in is really fast -- once the pool is > filled with sessions and the pool does not overrun. Logging out a pooled > session, though, is expensive. > > Looking at what is so expensive when logging out pooled sessions, I > found out that executing the query takes roughly 99% of the processing > time of releasing a pooled session ! > > Now, what is this query for ? It finds all locks owned by the user whose > session is about to be released and checks all locks found for whether > they are session scoped or not. This is required to release session > scoped locks to prevent handing these over to next user of the pooled > session. > > Removing the query turns the picture over: running the test with session > pooling is 10 times faster than without the pool ! > > Hmm, looking at these results, I am tempted to say "let's find a way to > prevent the query" ... it's easy: do not use session scoped locks! they only exist for applications that are too lazy to clean up afterwards (with concurrent locks, you need to release your locks, too). after all, i still think that the session pool should be implemented on the repository level and on on the client level. the repository has all means to optimize and recycle the sessions correctly. keeping a session pool on the client is problematic also in respect to resources. only the repository knows how 'expensive' a session is. having too many 'idle' sessions can kill the performance easily. if we think that the sessions of the repository (i.e. of jackrabbit) are to 'heavy' we should rather focus on making them more lightweight and implement some pooling there. +1 for disabling the session pool per default -0.5 for keeping the session pool regards, toby > > > Hi all, > > > > Sling's support for accessing JCR repositories always included a session > > pool. This session pool dates back some years before Day contributed > > Sling to the ASF at a time, where Jackrabbit and, more importantly then, > > Day's CRX were early release stuff and Session setup was dead slow. > > > > In the meantime, Jackrabbit went through a number of release cycles and > > Session setup time improved a lot. In fact using the Session pool is > > even slower than not using it ! > > > > So, I propose we drop the Session pool from the jcr/base module > > altogether and just keep the (optional) functionality to limit the > > number of simultaneous sessions per user. > > > > WDYT ? > > > > Regards > > Felix > > > > PS: Regarding timing: I did a stupid test of logging in and out 1000 > > Sessions (at most 5 Sessions concurrently open). Running the test with a > > session pool of 10 sessions took roughly 3 times as long as running with > > the pool disabled ! > > >
[jira] Created: (SLING-706) Change default value of max idle pool sessions to 0
Change default value of max idle pool sessions to 0 --- Key: SLING-706 URL: https://issues.apache.org/jira/browse/SLING-706 Project: Sling Issue Type: Wish Components: JCR Affects Versions: JCR Jackrabbit Client 2.0.2 Reporter: Tobias Bocanegra the JCR repository client session pool should initially be disabled. change the default value of max idle pool sessions to 0. the overhead of acquiring and releasing sessions is bigger than the performance gain from keeping the cached sessions. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-686) Change i18n storage structure for less redundancy
[
https://issues.apache.org/jira/browse/SLING-686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12635838#action_12635838
]
Tobias Bocanegra commented on SLING-686:
another drawback of this suggestion is, that you can't export/import just an
entire tree (eg. for let it translate by an external company). also adding a
new language/translation later on results probably in a big mess.
> ... and it would make it more easy to create quickly the different
> translation for a given key.
which in real life is difficult to find a language genius that speaks 4
different languages :-). usually the messages are translated language by
language by the same person.
> Change i18n storage structure for less redundancy
> -
>
> Key: SLING-686
> URL: https://issues.apache.org/jira/browse/SLING-686
> Project: Sling
> Issue Type: Improvement
> Components: Extensions
>Affects Versions: Extensions i18n 2.0.2
>Reporter: Thierry Yge
>Priority: Minor
>
> it would be nicer to structure the i18n nodes as follow
> {
> "en": "hi",
> "sling:key": "hi",
> "de": "hallo",
> "jcr:primaryType": "sling:Message",
> "fr": "bonjour",
> "it": "bonjourno"
> }
> This it would avoid so many redundancy as in the actual solution, and it
> would make it more easy to create quickly the different translation for a
> given key.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-684) JcrInstall fails to read multivalued properties from config
[ https://issues.apache.org/jira/browse/SLING-684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tobias Bocanegra updated SLING-684: --- Attachment: jcrinstall-r698192.patch uses ConfigurationHandler to read the properties > JcrInstall fails to read multivalued properties from config > --- > > Key: SLING-684 > URL: https://issues.apache.org/jira/browse/SLING-684 > Project: Sling > Issue Type: Bug > Components: JCR Install > Reporter: Tobias Bocanegra > Attachments: jcrinstall-r698192.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-684) JcrInstall fails to read multivalued properties from config
JcrInstall fails to read multivalued properties from config --- Key: SLING-684 URL: https://issues.apache.org/jira/browse/SLING-684 Project: Sling Issue Type: Bug Components: JCR Install Reporter: Tobias Bocanegra -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Trying to upload a package in CRX from dev to test... getting error
hi josh,
make sure you installed all recent sling bundles on your target crx.
it seems that some node have a wrong nodetype.
regards, toby
On 9/29/08, Joshua Oransky <[EMAIL PROTECTED]> wrote:
> I create and download a package fine on my dev machine. I upload the zip to
> the main test in CRX and I get:
>
> javax.jcr.RepositoryException: Unable to import node.: no matching property
> definition found for
> {http://sling.apache.org/jcr/sling/1.0}resourceSuperType:
> Unable to import node.: no matching property definition found for
> {http://sling.apache.org/jcr/sling/1.0}resourceSuperType
> at
> com.day.jcr.vault.fs.imprt.GenericArtifactHandler.accept(GenericArtifactHandler.java:75)
>
> Any ideas?
>
> -Josh
>
Re: prefix :jcr: in json
hi,
i think this is intended and the value is the length of the binary property.
regards, toby
On 9/23/08, Michael Marth <[EMAIL PROTECTED]> wrote:
> Hi,
>
> for the json presentation of nt:resource nodes I get one property with
> prefix :jcr: instead of jcr:. Is this the expected behavior?
>
> "Creek.jpg":{
> "jcr:created":"Tue Sep 23 2008 10:44:54 GMT+0200",
> "jcr:primaryType":"nt:file",
> "jcr:content":{
> "jcr:uuid":"2cd77618-dae5-4e45-bd91-800da6bf48cf",
> *":jcr:data":264409,*
> "jcr:mimeType":"image/jpeg",
> "jcr:lastModified":"Thu Sep 04 2008 14:44:56 GMT+0200",
> "jcr:primaryType":"nt:resource"
> }
> }
>
> (using the Sling version that came with CRX Quickstart)
>
> Michael
>
>
> --
> Michael Marth | Day JCR Cup 08 | Win a MacBook Pro: http://dev.day.com/
>
Re: sling:Folder vs. nt:unstructured
On 9/19/08, Felix Meschberger <[EMAIL PROTECTED]> wrote: > Hi all, > > Until SLING-663 [1] the sling:Folder node type was turned into an > extension of nt:folder. This is basically good. > > The consequence of this is more restrictions on child nodes: Before > SLING-663 a sling:Folder a child node of any type, most notably > nt:unstructured. With the changes brought by SLING-663, nt:unstructured > cannot be used as a child node of a sling:Folder node any more. > > As a "fix" I have basically three options : > > (1) Use sling:Folder instead of nt:unstructured > (2) Change sling:Folder such that the required primary > type is nt:base instead of nt:hierarchyNode > (3) Create a node type sling:Unstructured extending > from nt:hierarchyNode and nt:unstructured. > > (1) works perfectly, but is kind of strange: Creating a folder just to > store some unsrtuctured properties looks weird. > > (2) might not work because an extended node type might not be allowed to > change the required primary type over overwritten child node definitions > (though overwriting the default primary type seems to work sling:Folder > shows). > > (3) sounds like a good workaround if (2) would not work. > > I quickly tested solution (2) and it seems to work. hi, i think (2) makes sense. regards, toby
Re: Static includes
hi josh, one solution is to use another selector or resource type for your included script. eg: /page page.jsp content.jsp and in page.jsp you do: this will select the content.jsp as script when including 'this' resource. the draw back of this is, that you 'destroy' any selectors from the request, i.e. you can't propagate them into your content.jsp without some manual magic. another solution is using another resource type. eg: /page page.jsp /content content.jsp and in page.jsp you do: you could even make this work 'relative' eg: String rt = resource.getResourceType() + "/content"; regards, toby ps: i wrote an extended include tag that allows direct execution of other scripts without having an extra 'include'. this is somewhat contradictory to the sling philosophy that tries to hide the script-resolution-magic from the user by the paradigm that only 'resources' are included. imo, in some cases, you really know what you do, and you want to execute/include a designated script. On 9/17/08, Joshua Oransky <[EMAIL PROTECTED]> wrote: > Hello, > > How can I statically include code from another script? That is, > include it into execution in the context of the currentNode. Sling.include > does not work for me, because it executes in the context of the included > node. I have several instances where I need to reuse code in different > visual layouts. It seems inefficient to write the same code over and over, > and is a maintenance nightmare. I know there's the sling:superResourceType, > but that doesn't really solve my issue, as I want to have reusable snippets. > > Thanks - Josh >
[jira] Created: (SLING-663) Make sling:Folder more folder like
Make sling:Folder more folder like -- Key: SLING-663 URL: https://issues.apache.org/jira/browse/SLING-663 Project: Sling Issue Type: Wish Components: API Reporter: Tobias Bocanegra the current sling:Folder looks like this: [sling:Folder] > nt:hierarchyNode, nt:unstructured orderable + * (nt:base) = sling:Folder version this is very convenient since it allows all kind of properties and nodes. But imo it's wrong that it is orderable. since folders dont have an order (at least in no FS is know). furthermore, i find it 'wrong' to allow * child nodes. if you want to add an arbitrary child node to a folder, we should use the sling:HierarchyNode mixin. as for the * properties, i think they are ok and should stay. the only inconvenience about nt:folder is, that is does not define a default primary type. so i suggest to change sling:Folder to: [sling:Folder] > nt:folder - * (undefined) multiple - * (undefined) + * (nt:hierarchyNode) = sling:Folder version and add: [sling:HierarchyNode] > nt:hierarchyNode mixin [sling:OrderedFolder] > sling:Folder orderable + * (nt:hierarchyNode) = sling:OrderedFolder version -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-662) ValueMap#get(java.lang.String name, T defaultValue) should support arrays transparently
ValueMap#get(java.lang.String name, T defaultValue) should support arrays
transparently
---
Key: SLING-662
URL: https://issues.apache.org/jira/browse/SLING-662
Project: Sling
Issue Type: Improvement
Components: JCR Resource
Reporter: Tobias Bocanegra
when calling ValueMap.get("name", String[].class) and empty array is returned
if the underlying jcr property is not
multivalued. this is very inconvenient.
imo get() for arrays or single values should work transparently regardless of
the underlying property multivalueness.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Created: (SLING-646) jcrinstall - take two
On 9/7/08, Carsten Ziegeler <[EMAIL PROTECTED]> wrote: > Bertrand Delacretaz wrote: > > > > IIUC what you're saying is that you wouldn't want to support reading > > OSGi configurations from text files found in the repository? > > > > That is supported by the Felix fileinstall stuff (IIRC), and we'd like > > to have similar features, that's one reason to support them. > > > > Yes, that's right. > > > > Also, there's currently no easy way for a Sling user to transfer a > > configuration to someone else: if you install some bundles and play > > with their configs from the OSGi console until they work as you'd > > like, the only way to send the configs to someone else is currently to > > do screenshots of the OSGi console. Not nice, error-prone, and that > > console is not very user-friendly at the moment. > > > > Having config files in the repository makes it much easier - one can > > copy a few bundles and configs in a repository folder, play with the > > configs as needed, and then simply copy those files to reproduce the > > behavior in another Sling instance. > > > > Deployment packages are obviously better when we're speaking of > > distributing collection of components that are prepared by a > > developer. The above scenario would provide "sling admnistrators" with > > a similar mechanism, without them needing any tools besides > > jcrinstall. > > > > Supporting configurations in jcrinstall is simple and useful, I dont > > see why we wouldn't do that. > > > > Hmm, ok, rethinking it, I'm not against this. If it's small and simple, > do it. But I don't see the real value. :) > Fiddling with a configuration in the repository does not provide > any means of what configuration options/values are possible. So you > have to have a very deep knowledge of what you're doing. > The web console provides a much better way of playing around with > configurations. sure. afaik, the goal is not to allow modification to the configuration directly on the storage. like you wouldn't mess with the properties files of the filebase config. managing the config would still go through the normal osgi config admin, but the store would be in the repository. this has the big advantage, that everything your application needs, can be stored in the repository (bundles, scripts, content, config) and can be backed-up, replicated, clustered, etc. with repository means. so a sysadmin does not need to backup the filesystem based config separately. regards, toby
Re: Annoyance during update of bundles
On 8/30/08, Alexander Klimetschek <[EMAIL PROTECTED]> wrote: > On Fri, Aug 29, 2008 at 8:33 PM, Tobias Bocanegra > <[EMAIL PROTECTED]> wrote: > > > how about stalling requests until the update is complete ? > > > Good idea. This would also save one from all the other problems you > can get (html node render servlet triggered, jsp compile errors, > etc.). > > But I am not sure if this is what you want in a production system - if > you have high traffic and most requests don't use the servlets or > services provided by the bundle that is updated. Maybe it's possible > to stall only requests to the servlets that are provided by the bundle > in question. well. rather having no requests than broken ones. after all, a bundle update should not take longer than a couple of seconds...so i think this is acceptable. regards, toby
Re: Annoyance during update of bundles
how about stalling requests until the update is complete ? regards, toby On 8/29/08, Alexander Klimetschek <[EMAIL PROTECTED]> wrote: > Hi all, > > when I update a bundle containing a servlet (eg. servlet path = > /bin/myservlet) and I hit my curl command for testing that servlet > (POST to /bin/myservlet + a few specific params) too fast, ie. in the > time when the old version of the bundle is gone, but the new version > is not yet started, and hence nothing is registered under > /bin/myservlet, the request is handled by the SlingPostServlet, which > in this case creates a new JCR node under /bin/myservlet. > > Any ideas how to circumvent this little annoyance during development? > > Regards, > Alex > > PS: I would like to have a nice "ding" sound once the bundle update > completed successfully ;-) > > > -- > Alexander Klimetschek > [EMAIL PROTECTED] >
Re: Creating paths in the post servlet
On 8/29/08, Alexander Klimetschek <[EMAIL PROTECTED]> wrote: > Hi all, > > I currently have the need to create a path by posting to the > SlingPostServlet, eg. /some/very/long/path, where only /some exists, > and very/long/path has to be created in the repo. Now I miss two > features in the current SlingPostServlet: > > a) specify only one intermediate jcr:primaryType (instead of > /some/very/jcr:primaryType=my:type, > /some/very/long/jcr:primaryType=my:type, etc.) for all the > intermediate nodes that have to be created are you able to specify the default nodetypes for new nodes in the nodetype of "/some" ? if yes, this should work automatically since the repository selects the correct nodetype. > b) the path is built right from the user input, so I need a nameHint > path (eg. user enters "Verü/Lon g/Path", => pathHint = "/some/Verü/Lon > g/Path" sent to server, => generated node path is > "/some/ver_/lon_g/path"); I could do this on the client-side, but I > don't want to reimplement the nameHint -> valid name conversion, it's > good to have a central place for it but how would you differentiate from the case where a '/' is present in the hint but should not create deep paths? > A different solution would be to make several HTTP requests, one for > each node in the path, but this would also be more code complexity on > the client side and not transactional. > > WDYT? Overkill or nice-to-have feature? i would create the path clientsided... regards, toby
[jira] Commented: (SLING-601) Request Inclusion Counter operating too rigid
[ https://issues.apache.org/jira/browse/SLING-601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12625487#action_12625487 ] Tobias Bocanegra commented on SLING-601: initially the counter just counted the number of includes. so if you had more than 50 includes on your page it aborted. imo (and of carstens) this was wrong and he changed it to count nested includes (so decrementing after the include). endless loops are not easy detectable. there is nothing you can do to prevent people writing a "while(true);". of course there can be counter measures, like killing a 100% thread, or checking that the output of a HTML doesn't get too big...but i think this is a tedious work. > Request Inclusion Counter operating too rigid > - > > Key: SLING-601 > URL: https://issues.apache.org/jira/browse/SLING-601 > Project: Sling > Issue Type: Bug > Components: Engine >Affects Versions: Engine 2.0.2 >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: Engine 2.0.4 > > > The SlingMainServlet implements a recursion level counter to prevent > recursions going too deep in the checkRecursionLevel method. What this method > does is incrementing a counter stored as a request attribute everytime > RequestDispatcher.include is called (by whatever means). > The drawback of this mechanism is, that the counter is only incremented and > never decremented after an inclusion returns. This in fact is not a recursion > level counter but a counter limiting the number of times > RequestDispatcher.include may be called. Another drawback of this is, that > the implementation is overcomplicated, because the RequestData object created > for each request keeps a stack of a inclusions and hence could easily > implement a real recursion level checker by just checking the size of the > stack. > I think, we should drop the SlingMainServlet.checkRecursionLevel method > altogether and replace it with a new RequestData.checkAbort method which > throws in case any of two cases occurrs: >* Recursion Level is too deep (50 seems like useful) >* Number of includes exceeds a given number (something like 1000 or more ?) > In addition the Exception should be made public in the Sling engine module > such that users of any include mechanism could handle it if need be. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-627) Virtual URLs break script resolution
[ https://issues.apache.org/jira/browse/SLING-627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12625354#action_12625354 ] Tobias Bocanegra commented on SLING-627: i think virtual url should just allow mapping of 'directories' and not full urls. so /sample could map to /content/some/where/samples mapping requests from http://host/sample to another path should only be done with (http) redirects. otherwise the confusion is endless as you problem shows. > Virtual URLs break script resolution > > > Key: SLING-627 > URL: https://issues.apache.org/jira/browse/SLING-627 > Project: Sling > Issue Type: Bug > Components: API, JCR Resource >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: API 2.0.4, JCR Resource 2.0.4 > > > Consider a virtual URL configuration in the JcrResourceResolver mapping the > URL "/sample" to "/content/some/where/in/the/path.print.a4.html". > When using the URL "/content/some/where/in/the/path.print.a4.html", the > resource resolver correctly resolves the "/content/some/where/in/the/path" > resource and sets the selector string (print.a4) and extension (html) > correctly. When accessing the URL "/sample", the resource is correclty > resolved again to "/content/some/where/in/the/path". But the selector string > and extension are empty. > The reason for this is the cooperation between the JcrResourceResovler and > the SlingRequestPathInfo and the RequestData class. The JcrResourceResolver > sets up the Resoure correctly with the ResourceMetadata containing a property > sling.resolutionPath set to "/content/some/where/in/the/path". The > RequestData.initServlet method uses the Resource (with the correct > sling.resolutionPath field) and the servlet request's path info > (ServletRequest.getPathInfo()) to find the selectors and extension etc. > The problem with virtual URLs is, that the path info is the originally > requested URL -- /sample in this case -- while the resource resolution path > is something completely different. Hence the request path info details cannot > be extracted. > To be able to fix this situation, we should add a new field in the > ResourceMetadata, which takes the part of the URL path used to resolve the > resoure, which is not path of the resource path, such that: > resolutionFullPath = sling.resolutionPath + sling.resolutionPathInfo > The SlingRequestPathInfo class will then only inspoect the > sling.resolutionPathInfo field to split that into selectors, extension and > suffix. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (SLING-619) Add a java servlet scripting engine
[ https://issues.apache.org/jira/browse/SLING-619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12624982#action_12624982 ] tripod edited comment on SLING-619 at 8/22/08 2:20 PM: - there is a minor problem when working with an IDE that it marks those servlets as invalid since the class name differs from the filename. the workaround is to exclude them from compilation but this is suboptimal. would it be possible to apply another resolution logic for .java servlets and use the underscore as selector/extension delimiter? eg: /apps/my/type/main_html.java Package: apps.my.type Class main_html was (Author: tripod): there is a minor problem when working with a IDE that it marks those servlets as invalid since the class name does differs from the filename. the workaround is to exclude them from compilation but this is suboptimal. would it be possible to apply another resolution logic for .java servlets and use the underscore as selector/extension delimiter? eg: /apps/my/type/main_html.java Package: apps.my.type Class main_html > Add a java servlet scripting engine > --- > > Key: SLING-619 > URL: https://issues.apache.org/jira/browse/SLING-619 > Project: Sling > Issue Type: New Feature > Components: Scripting Java >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > > For easier scripting it would be nice to have a scripting engine that > compiles a java servlet out of a java file which is stored in the repository, > like /apps/my/app/html.java -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-619) Add a java servlet scripting engine
[ https://issues.apache.org/jira/browse/SLING-619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12624982#action_12624982 ] Tobias Bocanegra commented on SLING-619: there is a minor problem when working with a IDE that it marks those servlets as invalid since the class name does differs from the filename. the workaround is to exclude them from compilation but this is suboptimal. would it be possible to apply another resolution logic for .java servlets and use the underscore as selector/extension delimiter? eg: /apps/my/type/main_html.java Package: apps.my.type Class main_html > Add a java servlet scripting engine > --- > > Key: SLING-619 > URL: https://issues.apache.org/jira/browse/SLING-619 > Project: Sling > Issue Type: New Feature > Components: Scripting Java >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > > For easier scripting it would be nice to have a scripting engine that > compiles a java servlet out of a java file which is stored in the repository, > like /apps/my/app/html.java -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-587) JcrBundlesManager
[ https://issues.apache.org/jira/browse/SLING-587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tobias Bocanegra updated SLING-587: --- Attachment: jcr_bundles-r687661.patch provided patch implements a very simple queue for bundles that could not be resolved when installed. the manager thread checks if any of the queued bundles are resolved and starts them. this can probably be done more generic and/or with bundle events rather than polling. > JcrBundlesManager > - > > Key: SLING-587 > URL: https://issues.apache.org/jira/browse/SLING-587 > Project: Sling > Issue Type: Improvement > Components: OSGi >Reporter: Bertrand Delacretaz > Attachments: jcr_bundles-r687661.patch > > > See http://markmail.org/message/wey5dod7cm7oalhr for a tentative spec -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Umlaut problem
hi,
the FormEncoding parameter was renamed to _charset_ (see [0]):
so:
should do the trick.
regards, toby
[0] https://issues.apache.org/jira/browse/SLING-298
On 8/19/08, Juerg Meier <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> This problem is driving me nuts...
>
> I don't get UTF-8 Umlaute correctly into the JCR. I double-checked
> everything to ensure the page is *really* UTF-8, and lately I discovered
> the thing with the hidden "FormEncoding" parameter. But instead of
> getting a clean 'ü', I still get something like "ü" (two byte UFT-8),
> and additionally a string property named "FormEncoding" on that node...
>
>
> Here's the JSP:
>
>
> <%@ page language="java" contentType="text/html; charset=UTF-8"
> pageEncoding="UTF-8"%>
> <[EMAIL PROTECTED] import="javax.jcr.query.*, javax.jcr.*,
> org.apache.sling.api.resource.Resource"%>
> <[EMAIL PROTECTED] session="false"%>
> <[EMAIL PROTECTED] prefix="sling"
> uri="http://sling.apache.org/taglibs/sling/1.0"%>
>
>
>
>"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";>
> http://www.w3.org/1999/xhtml";>
>
>
> Insert title here
>
>
>
> >
>
>
> Titel:
> maxlength="128" value="<%= currentNode.getProperty("title").getString()
> %>">
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Here what the browser sends:
> POSTDATA=title=Hilfe+bei+Wetterf%C3%BChligkeit&FormEncoding=UTF-8
>
>
> Any help is highly appreciated!
>
> Regards,
>
> Juerg
>
>
>
>
>
Re: Script resolution based on node types in /libs/*/my/type instead of just /libs/my/type?
On 8/15/08, Alexander Klimetschek <[EMAIL PROTECTED]> wrote: > Hi all, > > if you use both the "standard" servlet/script resolution using an > explicit resource type (eg. myapp/foobar) and sometimes (for > convenience) via the node type (eg. my:type) you get mixed locations > for both scripts: > > /libs/myapp/foobar > /libs/my/type > > Often you'd like to put them together, which would organize your > repository much better, ie. like this: > > /libs/myapp/foobar > /libs/myapp/my/type > > Therefore do you think it is possible to extend the script resolution > for node types to search not only > > /apps// > /libs// > > but also to search via wildcards: > > /apps/*// > /libs/*// > > ? > > The first match would win. It's up to the developers to ensure only > one occurence of my:type under /apps/* or /libs/*. i don't think that is a good idea. the script resolution is complicated enough and this would even add more complexity to it. regards, toby > > WDYT? > > Regards, > Alex > > > -- > Alexander Klimetschek > [EMAIL PROTECTED] >
[jira] Commented: (SLING-611) Save OSGi event properties as JCR properties
[ https://issues.apache.org/jira/browse/SLING-611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12622331#action_12622331 ] Tobias Bocanegra commented on SLING-611: > ... only props who's name or type ... the name can be escaped. see http://jackrabbit.apache.org/api/1.4/org/apache/jackrabbit/util/ISO9075.html as a possible escaping. > Save OSGi event properties as JCR properties > > > Key: SLING-611 > URL: https://issues.apache.org/jira/browse/SLING-611 > Project: Sling > Issue Type: Improvement > Components: Event >Affects Versions: Extensions Event 2.0.2 >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Fix For: Extensions Event 2.0.4 > > > Currently all OSGi event properties are saved in a single JCR property (as > serialized java object) > If possible the event properties can directly be saved as JCR properties - > only props who's name or type is not directly usable get saved as a > serialized java object -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Scripts for Basic Versioning
On 8/13/08, Felix Meschberger <[EMAIL PROTECTED]> wrote: > Hi Outta, > > Outta Sight schrieb: > > > I'm looking for an example of how to perform versioned POSTs (POST.esp) > and also how to access a list of these versions (versions.esp) for any node. > It seems that this sort of capability must be scripted using Sling scripts. > Does anybody have examples using Javascript? Because Sling is built on top > of a content repository where one of the primary features is versioning - > I'd like to know how to do this. you can use the JSP api directly in the script, so eg. node.checkin() should work. > Currently the SlingPostServlet does not do versioning. This would be an > extension to be built in. > > Regarding versioning there are probably two use cases: > > * checkpointing - create a new version of the modified node > before modifying it > * versioning - create a new version of the modified node > after modifying it > > In addition, I think, the SlingPostServlet should automatically check out a > versionable node before modification if the nodes happens to be checked in. this is not always desired. for example if a node is checked in, it could also mean that it should not to be altered until explicitly checked-out. > It also needs to be discussed, whether the node remains checked out after > the operation or is checked in. Probably, it should be in the state it was > before the operation: If the node was checked in, it must be checked in > after the operation. If it was checked out, it must be checked out after the > operation. i think that the versioning operations: checkin, checkout, checkpoint, restore need separate operations with clear additional parameters. i think too much magic in this case is not desirable. > Regarding access to the versions: There are two cases again: > > * Access to a certain (known) version > * Listing all versions of a node > > The first case might be implemented by the resource resolver as noted in > another thread by supporting parametrized URLs of the form > http://host/path;v=1. in the case you have an entire site versioned this is not very practical, since the names of the versions of each node are different. what you probably want is some sort of time-based version selector, eg: http://host/path;vdate=2008-08-13T08:11:00 which selects the most recent version before that date. a rewriter could adjust all links to resources and other pages so that the entire site is 'put' into an old state. > > The second case could be handled by the JSON default get servlet, which > could be enhanced to return a list of the versions for a given node... i would issue a second request to the version history of that nodethis provides much more information. regards, toby
Using java annotations for servlet resolution mapping
hi,
currently sling uses @scr javadoc comments to specify the bindings
from the request infos to servlets. for example:
/**
* @scr.service
* @scr.property name="sling.servlet.resourceTypes" values="bin/test"
* @scr.property name="sling.servlet.extensions" values="txt, html"
*/
public class TestServlet extends SlingAllMethodsServlet {
...
}
this has the following drawbacks:
- the possible @scr properties are hard to guess if not documented
- the @scr properties are not "type safe"
- no intellisense support on IDEs
- only works if servlets are compiled using the maven scr plugin
i suggest to introduce a couple of java annotations that provide the
same mechanism.
they provide all missing features mentioned above.
example:
public interface SlingServletBinding {
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.TYPE)
public @interface RESOURCE_TYPE {
String[] value();
}
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.TYPE)
public @interface EXTENSION {
String[] value();
}
}
the servlet can then be annotated like this:
@SlingServletBinding.RESOURCE_TYPE("bin/test")
@SlingServletBinding.EXTENSION({"txt", "html"})
public class TestServlet extends SlingAllMethodsServlet {
}
and the annotations can be determined like this:
TestServlet servlet = new TestServlet();
for (Annotation a: servlet.getClass().getAnnotations()) {
if (a.annotationType() == SlingServletBinding.EXTENSION.class) {
for (String e: ((SlingServletBinding.EXTENSION) a).value()) {
System.out.printf("%s extension %s%n",
servlet.getClass().getName(), e);
}
}
if (a.annotationType() == SlingServletBinding.RESOURCE_TYPE.class) {
for (String e: ((SlingServletBinding.RESOURCE_TYPE)
a).value()) {
System.out.printf("%s restype %s%n",
servlet.getClass().getName(), e);
}
}
}
i think this would provide more stable code. unfortunately it does not
free it from using
the scr plugin, since the servlet needs to be registered as osgi
component nevertheless.
WDYT?
regards, toby
Re: listing nodes in the root
hi, afaik, not on the root node, but on any other node you can request a JSON serialization. eg: http://localhost:8080/content.1.json regards, toby On 8/8/08, Ruben Reusser <[EMAIL PROTECTED]> wrote: > hi. > > is there a way to do a http request to the launch pad to list all nodes in > the root or in any other path? > > Thanks > > Ruben >
Re: Build error (dojo)
On 8/7/08, Felix Meschberger <[EMAIL PROTECTED]> wrote:
> Hi,
>
> It seems that your cached version of the dojo release file is corrupt. Just
> remove the download-cache folder and rebuild. This should do the trick.
ok, i'll try. thanks.
--
toby
>
> Regards
> Felix
>
> Tobias Bocanegra schrieb:
>
>
> > hi,
> > with the current checkout i get:
> >
> > [INFO]
>
> > [INFO] Building Sling - Dojo JavaScript Library
> > [INFO]task-segment: [clean, install]
> > [INFO]
>
> > [INFO] [clean:clean]
> > [INFO] Deleting directory
> >
> /Users/tripod/codez/cq5/trunk/sling/extensions/dojo/target
> > [INFO] [enforcer:enforce {execution: enforce-java}]
> > [INFO] [resources:resources]
> > [INFO] Using default encoding to copy filtered resources.
> > [INFO] [antrun:run {execution: default}]
> > [INFO] Executing tasks
> >[mkdir] Created dir:
> >
> /Users/tripod/codez/cq5/trunk/sling/extensions/dojo/target/dojo
> > [get] Getting:
> >
> http://download.dojotoolkit.org/release-1.1.1/dojo-release-1.1.1-src.tar.gz
> > [get] To:
> >
> /Users/tripod/codez/cq5/trunk/sling/extensions/dojo/download-cache/dojo-release-1.1.1-src.tar.gz
> > [get] Not modified - so not downloaded
> > [INFO]
>
> > [ERROR] BUILD ERROR
> > [INFO]
>
> > [INFO] Error executing ant tasks
> >
> > Embedded error: Dojo Toolkit Package checksum does not match, please
> > check ./download-cache/dojo-release-1.1.1-src.tar.gz.
> >
> >
> > regards, toby
> >
> >
>
Build error (dojo)
hi,
with the current checkout i get:
[INFO]
[INFO] Building Sling - Dojo JavaScript Library
[INFO]task-segment: [clean, install]
[INFO]
[INFO] [clean:clean]
[INFO] Deleting directory
/Users/tripod/codez/cq5/trunk/sling/extensions/dojo/target
[INFO] [enforcer:enforce {execution: enforce-java}]
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [antrun:run {execution: default}]
[INFO] Executing tasks
[mkdir] Created dir:
/Users/tripod/codez/cq5/trunk/sling/extensions/dojo/target/dojo
[get] Getting:
http://download.dojotoolkit.org/release-1.1.1/dojo-release-1.1.1-src.tar.gz
[get] To:
/Users/tripod/codez/cq5/trunk/sling/extensions/dojo/download-cache/dojo-release-1.1.1-src.tar.gz
[get] Not modified - so not downloaded
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Error executing ant tasks
Embedded error: Dojo Toolkit Package checksum does not match, please
check ./download-cache/dojo-release-1.1.1-src.tar.gz.
regards, toby
Re: Need more information on replaceSuffix and flush
On 8/4/08, janandith jayawardena <[EMAIL PROTECTED]> wrote: > Hi, > > Another question Toby how do I create file.bin stated in the following. Is > it an extention for resource file. just upload a file via webdav, for example. or place it as initial content into a bundle. regards, toby > > no quite. if you have a file, eg. a document in > >/content/mynode/file.bin which you > >want to provide a download link, you write > > > regards, > > Janandith > > > On Tue, Aug 5, 2008 at 12:53 AM, janandith jayawardena > > <[EMAIL PROTECTED]>wrote: > > > Hi Toby, > > > > >afaik, there is not way of checking this. you can check if the > > >response was already comitted by response.isComitted() but this does > > >not reflect the actual state of the jsp output buffer. see: > > > > I used response.isCommited() to test flush in sling:include it works fine. > > > > Thanks alot. I'm really greatfull for pointing me to this option :-). > > > > Janandith. > > > > > > > > > > On Mon, Aug 4, 2008 at 6:42 PM, Tobias Bocanegra <[EMAIL PROTECTED] > > > wrote: > > > >> On 8/4/08, janandith jayawardena <[EMAIL PROTECTED]> wrote: > >> > Hi Toby, > >> > > >> > > >> > > >> > >i see mainly 2 purposes for the suffix,: > >> > >1. as an additional way of transporting a path like parameter > >> > >2. as a hint for filenames for browsers when downloading a resource. > >> > >eg, if your resource is addressable under /foo/bar.res and you want to > >> > >provide a download link, > >> > >you don't want to browser to store the file as 'bar.res'. so you add > >> > >for example the original filename: /foo/bar.res/myfile.pdf > >> > > >> > > >> > does this mean if I have a html.jsp which is accessible using > >> > http://localhost:/content/mynode.html. > >> > > >> > If I have another file like test.txt in the same place html.jsp > >> > http://localhost:/content/mynode.html/test.txt will download the > >> file > >> > according purpose 2. > >> no quite. if you have a file, eg. a document in > >> /content/mynode/file.bin which you > >> want to provide a download link, you write > >> report for example. > >> sling selects the /content/mynode/file.bin as resource, but the > >> browser will store it under "My Report.pdf". this is just a convenient > >> way of suggesting a file name for browsers. > >> > >> > else in the purpose 1 to have a link to test.txt like a href in > >> html.jsp. > >> > > >> > In a script can I use suffixes instead of giving a browser path. > >> actually i don't know of a really good use case for suffixes as > >> parameters to be used in scripts. > >> > >> > > the "flush" attribute just specifies, that the output buffer is > >> > > flushed before executing the include. usually you can leave this to > >> > > 'false'. this has the advantage, that the output buffer is only > >> > > comitted when it's either full, or the end of the response is > >> reached. > >> > > this allows the included script still to change response headers and > >> > > allows for a better error handling. but it depends on the size of the > >> > > output buffer, and you should not rely on an uncomitted buffer. as > >> > > soon as you write directly on the response.getWriter() you need to > >> > > flush the buffer before hand. otherwise you don't get the correct > >> > > sequence of output. > >> > > >> > > >> > Is there a way I can know whether the buffer is flushed. can I get the > >> > buffer in a script and check this. > >> afaik, there is not way of checking this. you can check if the > >> response was already comitted by response.isComitted() but this does > >> not reflect the actual state of the jsp output buffer. see: > >> > >> > >> > http://java.sun.com/products/servlet/2.2/javadoc/javax/servlet/ServletResponse.html#isCommitted()<http://java.sun.com/products/servlet/2.2/javadoc/javax/servlet/ServletResponse.html#isCommitted%28%29> > >> > >> regards, toby > >> > >> > On
Re: SlingPostServlet: How to handle resource paths when creating content (Re: [jira] Commented: (SLING-588) Sling ignores specified node path when creating content)
On 8/4/08, Felix Meschberger <[EMAIL PROTECTED]> wrote: > Hi all, > > After following this discussion, I fear we are missing some facts. Let > me recount them here: > > (1) Not (only) the SlingPostServlet treats existing and > non-existing resources differently. Sling's resource > resolver right from the start does this. > > (2) Handling existing and non-existing resources differently > is part of the game of finding out about the request. > There is just nothing to be found out about a non-existing > resource (except its non-existence). > > (3) I think different handling in SlingPostServlet is wrong > because SlingPostServlet has no way of guessing what the > intentions of the programmers are. Rather the programmer > must be careful enough to clearly declare his intentions > and SlingPostServlet must be flexible enough to cope with > these requirements. This particularly means to _not_ apply > any "hidden" wizardry like breaking a resource path apart. > > > To illustrate the points about the system not being able to guess the > intentions of a programmer: Consider the resource resolver tries to > resolve resources relative to the root and to the /content node such > that for example a request for /a may be resolved to /content/a. > > Now a request is posted to /b with the programmer's intent to have the > resource /content/b created. Given that no resource at /content/b exists > (and neither at /b), the SlingPostServlet would in fact create a > resource /b, which clearly is not the intention of the programmer. > > So here, the programmer has to request for /content/b explicitly and > thus treating existing resources (like /content/a) and non-existing > (like /content/b) resources differently. > > Why should a programmer not be able to do the same with respect to the > selectors and extensions ? > > In fact, there is another point about why SlingPostSerlvet's current > handling of resources is wrong: Consider the name of a resource would > contain a dot, say /foo.bar. You may now POST to /foo.bar.selector.hml > and be sure to modify the resource /foo.bar. Posting to > /foo.baz.selector.html with the intent to create a resource /foo.baz > should it not exist would not work as SlingPostServlet cuts off at the > first dot thus creating resource /foo instead of /foo.baz. > > > So, to come to an end, I think, we can easily document this (new) > behaviour: "For GET/HEAD requests you ask for a presentation (or > representation) of a resource and Sling helps out by using parts of the > URL for the selection of the concrete representation (script). For other > requests (POST, DELETE, ...) you want to modify the resource (and don't > care for the representation) and hence _should_ address the resource > directly without any representational detail such as selectors and > extensions." although i only agree partially, for the sake of clarity and simplicity, i support your suggestion :-) unless anyone has better arguments (david, roy ?) regards, toby
Re: Need more information on replaceSuffix and flush
On 8/4/08, janandith jayawardena <[EMAIL PROTECTED]> wrote: > Hi Toby, > > > > >i see mainly 2 purposes for the suffix,: > >1. as an additional way of transporting a path like parameter > >2. as a hint for filenames for browsers when downloading a resource. > >eg, if your resource is addressable under /foo/bar.res and you want to > >provide a download link, > >you don't want to browser to store the file as 'bar.res'. so you add > >for example the original filename: /foo/bar.res/myfile.pdf > > > does this mean if I have a html.jsp which is accessible using > http://localhost:/content/mynode.html. > > If I have another file like test.txt in the same place html.jsp > http://localhost:/content/mynode.html/test.txt will download the file > according purpose 2. no quite. if you have a file, eg. a document in /content/mynode/file.bin which you want to provide a download link, you write report for example. sling selects the /content/mynode/file.bin as resource, but the browser will store it under "My Report.pdf". this is just a convenient way of suggesting a file name for browsers. > else in the purpose 1 to have a link to test.txt like a href in html.jsp. > > In a script can I use suffixes instead of giving a browser path. actually i don't know of a really good use case for suffixes as parameters to be used in scripts. > > the "flush" attribute just specifies, that the output buffer is > > flushed before executing the include. usually you can leave this to > > 'false'. this has the advantage, that the output buffer is only > > comitted when it's either full, or the end of the response is reached. > > this allows the included script still to change response headers and > > allows for a better error handling. but it depends on the size of the > > output buffer, and you should not rely on an uncomitted buffer. as > > soon as you write directly on the response.getWriter() you need to > > flush the buffer before hand. otherwise you don't get the correct > > sequence of output. > > > Is there a way I can know whether the buffer is flushed. can I get the > buffer in a script and check this. afaik, there is not way of checking this. you can check if the response was already comitted by response.isComitted() but this does not reflect the actual state of the jsp output buffer. see: http://java.sun.com/products/servlet/2.2/javadoc/javax/servlet/ServletResponse.html#isCommitted() regards, toby > On Mon, Aug 4, 2008 at 1:19 AM, Tobias Bocanegra > <[EMAIL PROTECTED]>wrote: > > > > On 8/3/08, janandith jayawardena <[EMAIL PROTECTED]> wrote: > > > Hi, > > > > > > *replaceSuffix:* > > > > > > I read the following blog post while exploring replaceSuffix for > > SLING-475. > > > > > > > > > http://weblogs.goshaky.com/weblogs/lars/entry/an_architecture_for_content_centric2 > > > > > > it says , > > > > > > "With the suffix you could for instance address parts of a resource." > > > > > > under suffix: description. > > i see mainly 2 purposes for the suffix,: > > 1. as an additional way of transporting a path like parameter > > 2. as a hint for filenames for browsers when downloading a resource. > > eg, if your resource is addressable under /foo/bar.res and you want to > > provide a download link, > > you don't want to browser to store the file as 'bar.res'. so you add > > for example the original filename: /foo/bar.res/myfile.pdf > > > > > > > How can I create a suffix for a resource and use it. I've tried to > > figure it > > > out but it's still not clear. > > > Perhaps a simple example will help. > > you can't "create" a suffix, you just use it, for example in a link or > > an image reference. > > > > > *flush:* > > > > > > What I have in mind about flush is that it completely erases everything > > that > > > was created in the same script prior to flush="1" so that any formatting > > > after flush will be the result of the jsp script. > > > > > > I want to clear this also. A simple example will help here too. > > no, you can't erase anything. flush means here: flush the buffer to > > the response. > > > > the "flush" attribute just specifies, that the output buffer is > > flushed before executing the include. usually you can leave this to > > 'false'. this has the advantage, that the output buffer is only > > comitted when it's either full, or the end of the response is reached. > > this allows the included script still to change response headers and > > allows for a better error handling. but it depends on the size of the > > output buffer, and you should not rely on an uncomitted buffer. as > > soon as you write directly on the response.getWriter() you need to > > flush the buffer before hand. otherwise you don't get the correct > > sequence of output. > > > > regards, toby > > >
Re: Need more information on replaceSuffix and flush
On 8/3/08, janandith jayawardena <[EMAIL PROTECTED]> wrote: > Hi, > > *replaceSuffix:* > > I read the following blog post while exploring replaceSuffix for SLING-475. > > > http://weblogs.goshaky.com/weblogs/lars/entry/an_architecture_for_content_centric2 > > it says , > > "With the suffix you could for instance address parts of a resource." > > under suffix: description. i see mainly 2 purposes for the suffix,: 1. as an additional way of transporting a path like parameter 2. as a hint for filenames for browsers when downloading a resource. eg, if your resource is addressable under /foo/bar.res and you want to provide a download link, you don't want to browser to store the file as 'bar.res'. so you add for example the original filename: /foo/bar.res/myfile.pdf > How can I create a suffix for a resource and use it. I've tried to figure it > out but it's still not clear. > Perhaps a simple example will help. you can't "create" a suffix, you just use it, for example in a link or an image reference. > *flush:* > > What I have in mind about flush is that it completely erases everything that > was created in the same script prior to flush="1" so that any formatting > after flush will be the result of the jsp script. > > I want to clear this also. A simple example will help here too. no, you can't erase anything. flush means here: flush the buffer to the response. the "flush" attribute just specifies, that the output buffer is flushed before executing the include. usually you can leave this to 'false'. this has the advantage, that the output buffer is only comitted when it's either full, or the end of the response is reached. this allows the included script still to change response headers and allows for a better error handling. but it depends on the size of the output buffer, and you should not rely on an uncomitted buffer. as soon as you write directly on the response.getWriter() you need to flush the buffer before hand. otherwise you don't get the correct sequence of output. regards, toby
Re: SlingPostServlet: How to handle resource paths when creating content (Re: [jira] Commented: (SLING-588) Sling ignores specified node path when creating content)
On 8/3/08, Felix Meschberger <[EMAIL PROTECTED]> wrote: > Hi, > > Tobias Bocanegra schrieb: > > > > > > Not necessarily. The HTTP spec mentions headers explicitly for content > > > negotiation > > > > (http://www.w3.org/Protocols/rfc2616/rfc2616-sec12.html) > > > and there might be enough cases where a resource (!) happens to have a > name > > > ending with .html without implying that it is actually HTML. The server > > > selects the representation that is being sent and the server determines > how > > > to value headers or not. > > > > > content negotiation is certainly an interesting capability, but IMO > > poses a lot of problems. for example, i don't want another > > representation of a document (for the same url) just because my > > browser locale is different. if the urls are not stable, the documents > > can't be cached, which is bad. > > > > Well, the URLs are stable in that they always select the same resource. But > the representation differs and hence the resulting representation is not > cacheable. ...which is not favorable. at least not for GET requests. > HTTP provides various ways for the response to be selectively cache in the > form of the Cache-Control and Vary headers. > > Regards > Felix >
Re: SlingPostServlet: How to handle resource paths when creating content (Re: [jira] Commented: (SLING-588) Sling ignores specified node path when creating content)
On 8/1/08, Lars Trieloff <[EMAIL PROTECTED]> wrote: > Hi, > > > > > Not necessarily. The HTTP spec mentions headers explicitly for content > > > negotiation > > > (http://www.w3.org/Protocols/rfc2616/rfc2616-sec12.html) > > > and there might be enough cases where a resource (!) happens to have a > > name > > > ending with .html without implying that it is actually HTML. The server > > > selects the representation that is being sent and the server determines > > how > > > to value headers or not. > > content negotiation is certainly an interesting capability, but IMO > > poses a lot of problems. for example, i don't want another > > representation of a document (for the same url) just because my > > browser locale is different. if the urls are not stable, the documents > > can't be cached, which is bad. > > > > Correct, but we are talking about POST, PUT and DELETE requests that are not > being cached, so that does not matter. > > > > > > > it's very logical, that a foo.html and foo.pdf are different > > > > representations of the resource foo. > > > > > > > > > > Only if you forbid having foo.pdf and foo.html as two different > > resources > > > in the same path. In that case you would have foo.pdf.html and > > foo.html.pdf > > > and foo.html.html and foo.pdf.pdf. > > which i would find very confusing. > > > > Then we should forbid JCR nodes with a dot in the name. This would mean > there are certain applications, where I cannot use Sling anymore, for > instance because it is impossible to get an HTML preview of a PDF or an XML > with extracted XMP metadata for a JPEG, but it might be less confusing. I > wonder how you could fulfill anything except a narrow set of requirements > with these restrictions. > > > > > > I have read this before, but I still do not understand why. You mention > > not > > > a single real use case that would be broken through my proposal. > > as i said, i fear problems if non-existent and existent resources are > > treated differently. > > > > What are the problems that you fear? Fear, uncertainty and doubt are no good > basis to brush away my valid requests for a broken behavior. > > Furthermore, we are not treating existent and non-existent resources > differently. You POST, PUT, DELETE to the base URL of the resource, you GET > from the base URL plus selectors and extensions. This is not treating > existent and non-existent resources differently, it is treating GET requests > differently, which is a good thing and something we are doing anyway (or > where is POST.html.esp) but the patch in your jira issue treats them differently. if you're talking about always addressing the 'resource' in a POST request, then there is another problem, that you can't create any selector, or extension servlets anymore. regards, toby
Re: SlingPostServlet: How to handle resource paths when creating content (Re: [jira] Commented: (SLING-588) Sling ignores specified node path when creating content)
hi, On 7/31/08, Lars Trieloff <[EMAIL PROTECTED]> wrote: > Hi Toby, > > On Jul 31, 2008, at 21:01 , Tobias Bocanegra wrote: > > > > > > > > > > > > > > > Hi, > > > > > we are not violating the idempotency of the PUT (disguised as a > POST) > > > > > > > > > > 1. POST /foo.bar.html (foo=bar) > > > > > 2. GET /foo.bar.html > > > > > 3. POST /foo.bar.html (foo=bar) > > > > > 4. GET /foo.bar.html > > > > > > > > > > If request 1 and 3 are identical, responses 2 and 4 will be > identical as > > > > > well. > > > > > > > > > does not compute :-) > > > > > > > What I meant is: you can post the same request parameters > (representation) > > > as often as you like, the resource will have the same state afterwards. > The > > > POST has no side-effects and it does not work additive. So it is > idempotent > > > and can work as a replacement for a PUT. > > > > > yes, but only if the addressing does not change in respect if the > > resource is present or not. > > > > David's original point was that cutting off extensions might be necessary > to preserve the idempotency of the POST request. I have shown that it is not > necessary. > > > > > > > > > > > as far as i understood REST, the url always addresses a representation > > > > of a resource. > > > > so when you GET a /foo.html you get for example the HTML > > > > representation of the resource /foo. if you post to /foo.html, you > > > > want to update the HTML representation of the resource /foo. > > > > > > > The URL locates the resource. What gets transferred is the > representation. > > > We are using extensions and selectors only due to limitations of our > > > browsers that do not allow us to set the Accept header for GET requests > > > (which would be the proper way of indicating what representation you can > > > deal with). I think extensions and selectors are a neat workaround, but > we > > > should not overuse them were we do not rely on them (e.g. everywhere > where > > > we can send request headers or a request entity) > > > > > > > no, the URL (and only the url) locates the representation of the > > resource, which is in most cases the same, of course. > > > > URL (Uniform Resource Locator) locate resources in a uniform way. Resources > and representations are not the same or identical, as they describe > different concepts. Even if there is only one representation of the resource > (which is almost never the case with Sling where we have a txt and a json > representation for every resource). > > > > no matter what > > headers are set, if i request a .html, i want a HTML document (or i > > should always get the same, irrespective of the headers). > > > > Not necessarily. The HTTP spec mentions headers explicitly for content > negotiation > (http://www.w3.org/Protocols/rfc2616/rfc2616-sec12.html) > and there might be enough cases where a resource (!) happens to have a name > ending with .html without implying that it is actually HTML. The server > selects the representation that is being sent and the server determines how > to value headers or not. content negotiation is certainly an interesting capability, but IMO poses a lot of problems. for example, i don't want another representation of a document (for the same url) just because my browser locale is different. if the urls are not stable, the documents can't be cached, which is bad. > > it's very logical, that a foo.html and foo.pdf are different > > representations of the resource foo. > > > > Only if you forbid having foo.pdf and foo.html as two different resources > in the same path. In that case you would have foo.pdf.html and foo.html.pdf > and foo.html.html and foo.pdf.pdf. which i would find very confusing. > > so actually, if i want to change > > representation independent properties, i need to post to /foo, if i > > want to change PDF representation properties, e.g.. a watermark, i > > post to foo.pdf. > > > > If your representation has distinct properties that can be changed > individually, you do not have a representation, you have another resource. > If you want to upload a new thumbnail, you should PUT it to the appropriate > resource and indicate the content type accordingly. > > > > however, this does not help us here. > > > > i suggest to leave the resolution the way it is, &g
[jira] Commented: (SLING-594) Add pre and post processing hooks to the sling post servlet
[
https://issues.apache.org/jira/browse/SLING-594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12618813#action_12618813
]
Tobias Bocanegra commented on SLING-594:
> As there is no real use case for pre processing...
yes there is:
example: validation
you need to validate the input before storing. but you don't want to reject
the POST, but maybe just
adjust some value.
stupid example: transformation
you want to change all 'title' properties to uppercase before storing.
> Add pre and post processing hooks to the sling post servlet
> ---
>
> Key: SLING-594
> URL: https://issues.apache.org/jira/browse/SLING-594
> Project: Sling
> Issue Type: Improvement
> Components: Servlets Post
>Affects Versions: Servlets Post 2.0.2
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Servlets Post 2.0.4
>
>
> Currently during a post, a SlingPostOperation is selected and then executed.
> The post operation does "everything", performing the changes and saving them.
> I think we could reintroduce a Changes interface with several implementations
> like Add, Remove, Copy etc. This interface has all knowledge of what to
> change.
> The SlingPostOperation would then return a list of changes:
> interface SlingPostOperation {
>List prepare(SlingHttpServletRequest);
> }
> So the first step when a post comes in, is still to select the post
> operation, but then this operation just generates a list of changes without
> changing anything in the repository.
> We then introduce pre and post processor interfaces (these are no final names
> yet:)
> interface PreProcessor {
> void process(SlingHttpServletRequest, List);
> }
> interface PostProcessor {
> void process(SlingHttpServletRequest, List);
> }
> There can be several pre and post processor registered, a property of a
> processor is used to order them and guarantee an ordered execution.
> A pre processor can alter the list of changes.
> When all pre processors are run, the changes are applied to the repository by
> Sling, then all post processors are executed.
> Finally all changes are saved.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: SlingPostServlet: How to handle resource paths when creating content (Re: [jira] Commented: (SLING-588) Sling ignores specified node path when creating content)
On 7/31/08, Lars Trieloff <[EMAIL PROTECTED]> wrote: > Hi Toby, > > On Thu, Jul 31, 2008 at 1:27 PM, Tobias Bocanegra > > <[EMAIL PROTECTED]>wrote: > > > > On 7/30/08, Lars Trieloff <[EMAIL PROTECTED]> wrote: > > > Hi, > > > we are not violating the idempotency of the PUT (disguised as a POST) > > > > > > 1. POST /foo.bar.html (foo=bar) > > > 2. GET /foo.bar.html > > > 3. POST /foo.bar.html (foo=bar) > > > 4. GET /foo.bar.html > > > > > > If request 1 and 3 are identical, responses 2 and 4 will be identical as > > > well. > > does not compute :-) > > > > What I meant is: you can post the same request parameters (representation) > as often as you like, the resource will have the same state afterwards. The > POST has no side-effects and it does not work additive. So it is idempotent > and can work as a replacement for a PUT. yes, but only if the addressing does not change in respect if the resource is present or not. > > as far as i understood REST, the url always addresses a representation > > of a resource. > > so when you GET a /foo.html you get for example the HTML > > representation of the resource /foo. if you post to /foo.html, you > > want to update the HTML representation of the resource /foo. > > > > The URL locates the resource. What gets transferred is the representation. > We are using extensions and selectors only due to limitations of our > browsers that do not allow us to set the Accept header for GET requests > (which would be the proper way of indicating what representation you can > deal with). I think extensions and selectors are a neat workaround, but we > should not overuse them were we do not rely on them (e.g. everywhere where > we can send request headers or a request entity) no, the URL (and only the url) locates the representation of the resource, which is in most cases the same, of course. no matter what headers are set, if i request a .html, i want a HTML document (or i should always get the same, irrespective of the headers). it's very logical, that a foo.html and foo.pdf are different representations of the resource foo. so actually, if i want to change representation independent properties, i need to post to /foo, if i want to change PDF representation properties, e.g.. a watermark, i post to foo.pdf. however, this does not help us here. i suggest to leave the resolution the way it is, and you need to find a workaround for your upload-a-css-file problem (which should be done via webdav anyways :-) regards, toby > > > > > and i think here is the problem, since .css (or .pdf, ...) is treated > > > the same way. in your example, if you want to 'upload' the /foo.css, > > > then in this case, the resource and the representation URL are the > > same: /foo.css. but i don't know how to discover that in a smart way. > > maybe because there is a file parameter pointing to "." ? > > > > I think we do not need to be smart here. All we need to do is trust the > client (or the developer) that she is able to correctly locate the resource. > Do not use magic that could stab you in the back. > > regards, > > > Lars > > > > > > > regards, toby > > > > > On Wed, Jul 30, 2008 at 1:59 PM, David Nuescheler <[EMAIL PROTECTED]> > > wrote: > > > > > > > hi guys, > > > > > > > > i think it is dangerous if we have a different behavior on a POST > > (that > > > > originally should have been a PUT anyway, but due to browser > > > > limitations...) > > > > based on the existence of a node. I think that would violate the > > idempotent > > > > behavior that we had on the "PUT oriented" operations in the > > > > slingpostservlet. > > > > > > > > regards, > > > > david > > > > > > > > On Wed, Jul 30, 2008 at 1:46 PM, Tobias Bocanegra > > > > <[EMAIL PROTECTED]> wrote: > > > > > On 7/30/08, Felix Meschberger <[EMAIL PROTECTED]> wrote: > > > > >> Hi, > > > > >> > > > > >> all taking this to the list for discussion because Lars it making > > some > > > > >> important points. > > > > >> > > > > >> Lars Trieloff (JIRA) schrieb: > > > > >> > > > > >> > If you could decide for a way of fixing the NPE, I would be glad > > > > >> > &g
Re: SlingPostServlet: How to handle resource paths when creating content (Re: [jira] Commented: (SLING-588) Sling ignores specified node path when creating content)
On 7/30/08, Lars Trieloff <[EMAIL PROTECTED]> wrote: > Hi, > we are not violating the idempotency of the PUT (disguised as a POST) > > 1. POST /foo.bar.html (foo=bar) > 2. GET /foo.bar.html > 3. POST /foo.bar.html (foo=bar) > 4. GET /foo.bar.html > > If request 1 and 3 are identical, responses 2 and 4 will be identical as > well. does not compute :-) as far as i understood REST, the url always addresses a representation of a resource. so when you GET a /foo.html you get for example the HTML representation of the resource /foo. if you post to /foo.html, you want to update the HTML representation of the resource /foo. and i think here is the problem, since .css (or .pdf, ...) is treated the same way. i your example, if you want to 'upload' the /foo.css, then in this case, the resource and the representation URL are the same: /foo.css. but i don't know how to discover that in a smart way. maybe because there is a file parameter pointing to "." ? regards, toby > On Wed, Jul 30, 2008 at 1:59 PM, David Nuescheler <[EMAIL PROTECTED]> wrote: > > > hi guys, > > > > i think it is dangerous if we have a different behavior on a POST (that > > originally should have been a PUT anyway, but due to browser > > limitations...) > > based on the existence of a node. I think that would violate the idempotent > > behavior that we had on the "PUT oriented" operations in the > > slingpostservlet. > > > > regards, > > david > > > > On Wed, Jul 30, 2008 at 1:46 PM, Tobias Bocanegra > > <[EMAIL PROTECTED]> wrote: > > > On 7/30/08, Felix Meschberger <[EMAIL PROTECTED]> wrote: > > >> Hi, > > >> > > >> all taking this to the list for discussion because Lars it making some > > >> important points. > > >> > > >> Lars Trieloff (JIRA) schrieb: > > >> > > >> > If you could decide for a way of fixing the NPE, I would be glad > > >> > > > >> > to have a working workaround. (and close this bug) However I still > > >> > think it is quite easy to find out which case the servlet is dealing > > >> > with. As the user is free to specify the action of the form, he can > > >> > post to /some/sample if he wants no dot and /some/sample.html if he > > >> > wants a dot. > > >> > > >> > > > >> > Speaking more broadly we are increasingly introducing "tricks", > > >> > > > >> > special cases and magic post parameters to deal with a very specific > > >> > use case "most of the times in a CMS or such" while ignoring the > > needs > > >> > of other use cases like DAM, Blog, Wiki, social networking, forum, > > >> > online shop, podcast, file sharing and other content-centric web > > >> > applications. Having a RESTful web application framework implies in > > >> > my opinion to respect concepts like Resource, Representation, URI > > >> > and to avoid RPC-like interaction if not necessary. > > >> > > >> I agree and thinking about it the SlingPostServlet is more about > > modifying > > >> (create, update, delete) content and less about content representation. > > As > > >> such the URL fired at the SlingPostServlet should probably be more > > treated > > >> as the actual path than it is today. > > >> > > >> The actual code, which does this is buried in the > > >> ModifyOperation.getItemPath method, which tries to locate the item to > > work > > >> on from the resource. For an existing resource, there is nothing much to > > be > > >> done, as we have the item through the resource. > > >> > > >> For a non-existing resource, the resource path, contains the full path > > from > > >> the URL (actually it is ServletRequest.getPathInfo()) including anything > > >> which might be interpreted as selectors and extensions and even suffix. > > The > > >> idea of this was, that the SlingPostServlet might redirect to this URL > > after > > >> the update. > > >> > > >> Now, in the meantime we have applied various changes to the > > >> SlingPostServlet, which influence the creation of the name of a node to > > >> create: > > >> > > >> * :name and :nameHint to handle how names are generated > >
[jira] Commented: (SLING-592) add SNS (Same Name Siblings) support
[ https://issues.apache.org/jira/browse/SLING-592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12618647#action_12618647 ] Tobias Bocanegra commented on SLING-592: i think in this picture the node name just happens to be the same as the value of the property 'name'. which is the default behavior when creating nodes via the sling post servlet. however, your statement "Often the node name reflects a property value" is simply wrong. i would say: "in some cases, the name of the node is the same as a value of one of it's properties". there are a lot of problems with SNS, especially the no-consistent addressing. for example, if you address one of your shops by: /shops/shop[2].html (i wonder if this works, at all), and then afterwards delete the first shop, the same address refers now to the prior 3rd shop node. which makes the entire addressing unstable. in this respect, i makes absolutely no sense of having node resources with the same name in sling. further more, you'll just get a lot of problems, even if it would work. if the "node name" does not matter, just use some random name, or a number, or anything. > add SNS (Same Name Siblings) support > > > Key: SLING-592 > URL: https://issues.apache.org/jira/browse/SLING-592 > Project: Sling > Issue Type: Improvement >Reporter: Oliver Lietz > > support SNS to simplify adding content without a single unique (meaningful) > property -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-592) add SNS (Same Name Siblings) support
[ https://issues.apache.org/jira/browse/SLING-592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12618460#action_12618460 ] Tobias Bocanegra commented on SLING-592: no, a jcr node name does never reflect a jcr property value. please explain what you try to do and what should be added. > add SNS (Same Name Siblings) support > > > Key: SLING-592 > URL: https://issues.apache.org/jira/browse/SLING-592 > Project: Sling > Issue Type: Improvement >Reporter: Oliver Lietz > > support SNS to simplify adding content without a single unique (meaningful) > property -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-592) add SNS (Same Name Siblings) support
[ https://issues.apache.org/jira/browse/SLING-592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12618368#action_12618368 ] Tobias Bocanegra commented on SLING-592: what do you mean by property ? SNS is about nodes. > add SNS (Same Name Siblings) support > > > Key: SLING-592 > URL: https://issues.apache.org/jira/browse/SLING-592 > Project: Sling > Issue Type: Improvement >Reporter: Oliver Lietz > > support SNS to simplify adding content without a single unique (meaningful) > property -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: SlingPostServlet: How to handle resource paths when creating content (Re: [jira] Commented: (SLING-588) Sling ignores specified node path when creating content)
On 7/30/08, Felix Meschberger <[EMAIL PROTECTED]> wrote: > Hi, > > Tobias Bocanegra schrieb: > > > On 7/30/08, Felix Meschberger <[EMAIL PROTECTED]> wrote: > > > > > Now, in the meantime we have applied various changes to the > > > SlingPostServlet, which influence the creation of the name of a node to > > > create: > > > > > > * :name and :nameHint to handle how names are generated > > >in the case of Slash-Star request (trailing / or /*) > > > * :redirect to indicate whether to redirect to the modified > > >or created node after the request. > > > > > > Taking all this into account, I come to agree with Lars, that the > > > SlingPostSerlvet should treat the resource path of a non-existing > resource > > > (to be created) as is without modification. > > > > > i don't think that this is a good idea. otherwise you would need to > > know on the client if a resource already exists or not. ii find it > > very dangerous if the resolution is not symmetric. > > > > IMO, with the extension, you choose the type of response you want. eg, > > with .json you get a json response, with .html you get a html > > response. etc... > > > > Yes, but for the moment, the SlingPostServlet is only able to return an > HTML response status. Hence the extension is not used anyway. In other > words: posting as xyz.pdf expecting the response as a PDF is not going to > work anyway. > > Also, posting to sample.css to create a node with name sample.css, you > don't expect the answer to be text/css (or so) but probably text/html or > probably even just the status code or a redirect. > > In addition, you always have to know the actual resource you are modifying, > only that Sling is able to cut pieces off the name for existing resource, > but not for non-existing resources. > > Plus: consider a POST to sample.ext.html and expecting a resource named > sample.ext to be created > > In the end it boils down to: Are you using the POST with extension to > create new content without extension or not ? If you are using: Would > changing the behaviour create a problem for you ? > > A simple use-case could convince us to consider other options ... yes, a simple form, that posts to a resource irrespective if it exists or not: regards, toby
Re: SlingPostServlet: How to handle resource paths when creating content (Re: [jira] Commented: (SLING-588) Sling ignores specified node path when creating content)
On 7/30/08, Felix Meschberger <[EMAIL PROTECTED]> wrote: > Hi, > > all taking this to the list for discussion because Lars it making some > important points. > > Lars Trieloff (JIRA) schrieb: > > > If you could decide for a way of fixing the NPE, I would be glad > > > > to have a working workaround. (and close this bug) However I still > > think it is quite easy to find out which case the servlet is dealing > > with. As the user is free to specify the action of the form, he can > > post to /some/sample if he wants no dot and /some/sample.html if he > > wants a dot. > > > > > Speaking more broadly we are increasingly introducing "tricks", > > > > special cases and magic post parameters to deal with a very specific > > use case "most of the times in a CMS or such" while ignoring the needs > > of other use cases like DAM, Blog, Wiki, social networking, forum, > > online shop, podcast, file sharing and other content-centric web > > applications. Having a RESTful web application framework implies in > > my opinion to respect concepts like Resource, Representation, URI > > and to avoid RPC-like interaction if not necessary. > > I agree and thinking about it the SlingPostServlet is more about modifying > (create, update, delete) content and less about content representation. As > such the URL fired at the SlingPostServlet should probably be more treated > as the actual path than it is today. > > The actual code, which does this is buried in the > ModifyOperation.getItemPath method, which tries to locate the item to work > on from the resource. For an existing resource, there is nothing much to be > done, as we have the item through the resource. > > For a non-existing resource, the resource path, contains the full path from > the URL (actually it is ServletRequest.getPathInfo()) including anything > which might be interpreted as selectors and extensions and even suffix. The > idea of this was, that the SlingPostServlet might redirect to this URL after > the update. > > Now, in the meantime we have applied various changes to the > SlingPostServlet, which influence the creation of the name of a node to > create: > > * :name and :nameHint to handle how names are generated > in the case of Slash-Star request (trailing / or /*) > * :redirect to indicate whether to redirect to the modified > or created node after the request. > > Taking all this into account, I come to agree with Lars, that the > SlingPostSerlvet should treat the resource path of a non-existing resource > (to be created) as is without modification. i don't think that this is a good idea. otherwise you would need to know on the client if a resource already exists or not. ii find it very dangerous if the resolution is not symmetric. IMO, with the extension, you choose the type of response you want. eg, with .json you get a json response, with .html you get a html response. etc... > We still have to deal with the / and /* suffixes, but we do not cut off any > extensions any more from the path. > > In the case of a redirect, the :redirect parameter could just be set with > *.selectors.ext to redirect to the newly create resource with selectors and > extensions, where the SlingPostServlet replaces "*" with the actual location > URL of it. regards, toby
[jira] Commented: (SLING-589) JcrPropertyMap shoud allow retrieving of properties
[ https://issues.apache.org/jira/browse/SLING-589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12618296#action_12618296 ] Tobias Bocanegra commented on SLING-589: yes. sorry, i was a bit unclear :-) > JcrPropertyMap shoud allow retrieving of properties > --- > > Key: SLING-589 > URL: https://issues.apache.org/jira/browse/SLING-589 > Project: Sling > Issue Type: New Feature > Components: JCR Resource > Reporter: Tobias Bocanegra >Priority: Minor > > the JcrPropertyMap should check for a javax.jcr.Property type class and > return the property if exists. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-590) Add resource.adaptTo(ValueMap.class) to page context attributes
[ https://issues.apache.org/jira/browse/SLING-590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12618280#action_12618280 ] Tobias Bocanegra commented on SLING-590: that would be fine, with the default of ValueMap.class > Add resource.adaptTo(ValueMap.class) to page context attributes > --- > > Key: SLING-590 > URL: https://issues.apache.org/jira/browse/SLING-590 > Project: Sling > Issue Type: New Feature > Components: Scripting JSP > Reporter: Tobias Bocanegra >Priority: Minor > > should add a 'properties' as page context variable from > resource.adaptTo(ValueMap.class) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-589) JcrPropertyMap shoud allow retrieving of properties
[
https://issues.apache.org/jira/browse/SLING-589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12618278#action_12618278
]
Tobias Bocanegra commented on SLING-589:
i want to 'inspect' a jcr property of the underlying node. eg to determine the
MV type, or the property type. currently i have to adapt the resource to the
node and then get the property. in some places, i don't have the resource
anymore.
eg: properties.get("foo", Property.class);
> JcrPropertyMap shoud allow retrieving of properties
> ---
>
> Key: SLING-589
> URL: https://issues.apache.org/jira/browse/SLING-589
> Project: Sling
> Issue Type: New Feature
> Components: JCR Resource
>Reporter: Tobias Bocanegra
>Priority: Minor
>
> the JcrPropertyMap should check for a javax.jcr.Property type class and
> return the property if exists.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-590) Add resource.adaptTo(ValueMap.class) to page context attributes
Add resource.adaptTo(ValueMap.class) to page context attributes --- Key: SLING-590 URL: https://issues.apache.org/jira/browse/SLING-590 Project: Sling Issue Type: New Feature Components: Scripting JSP Reporter: Tobias Bocanegra Priority: Minor should add a 'properties' as page context variable from resource.adaptTo(ValueMap.class) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-589) JcrPropertyMap shoud allow retrieving of properties
JcrPropertyMap shoud allow retrieving of properties --- Key: SLING-589 URL: https://issues.apache.org/jira/browse/SLING-589 Project: Sling Issue Type: New Feature Components: API Reporter: Tobias Bocanegra Priority: Minor the JcrPropertyMap should check for a javax.jcr.Property type class and return the property if exists. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
