[jira] Commented: (SLING-1483) SlingPostServlet saves operations that throw an error in the log but return 200 responses

[Michael Yin (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-1483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12895699#action_12895699
 ] 

Michael Yin commented on SLING-1483:


I believe it is. I no longer work with Sling project that caused that error 
though.

> SlingPostServlet saves operations that throw an error in the log but return 
> 200 responses
> -
>
> Key: SLING-1483
> URL: https://issues.apache.org/jira/browse/SLING-1483
> Project: Sling
>  Issue Type: Bug
>  Components: Servlets
>Reporter: Michael Yin
>Assignee: Eric Norman
>Priority: Minor
> Fix For: API 2.1.0
>
>
> I'm on a fairly recent trunk build, and when I do save operations with the 
> sling post servlet, I'm  getting OK responses back from the servlet but I see 
> errors in the sling log, and trying to retrieve the node again shows that the 
> changes did not happen. 
> Here is one of the stack traces in the log
> org.apache.sling.servlets.post.impl.operations.ModifyOperation Exception 
> during response processing. javax.jcr.nodetype.ConstraintViolationException: 
> Unable to perform operation. Node is protected.
>   at 
> org.apache.jackrabbit.core.ItemValidator.checkCondition(ItemValidator.java:303)
>   at 
> org.apache.jackrabbit.core.ItemValidator.checkModify(ItemValidator.java:277)
>   at 
> org.apache.jackrabbit.core.PropertyImpl.checkSetValue(PropertyImpl.java:235)
>   at 
> org.apache.jackrabbit.core.PropertyImpl.setValue(PropertyImpl.java:690)
>   at org.apache.jackrabbit.core.NodeImpl.setProperty(NodeImpl.java:2418)
>   at org.apache.jackrabbit.core.NodeImpl.setProperty(NodeImpl.java:1560)
>   at org.apache.jackrabbit.core.NodeImpl.setProperty(NodeImpl.java:2139)
>   at 
> org.apache.sling.servlets.post.impl.helper.SlingPropertyValueHandler.setPropertyAsIs(SlingPropertyValueHandler.java:278)
>   at 
> org.apache.sling.servlets.post.impl.helper.SlingPropertyValueHandler.setProperty(SlingPropertyValueHandler.java:106)
>   at 
> org.apache.sling.servlets.post.impl.operations.ModifyOperation.writeContent(ModifyOperation.java:432)
>   at 
> org.apache.sling.servlets.post.impl.operations.ModifyOperation.doRun(ModifyOperation.java:100)
>   at 
> org.apache.sling.servlets.post.AbstractSlingPostOperation.run(AbstractSlingPostOperation.java:87)
>   at 
> org.apache.sling.servlets.post.impl.SlingPostServlet.doPost(SlingPostServlet.java:178)
> The node is not saved yet the http client is given a status of 200 which 
> communicates that the request has succeeded. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: GSoC report

[Bertrand Delacretaz]

Hi Federico,

Thanks for your report.

On Wed, Aug 4, 2010 at 8:23 PM, Federico Paparoni
 wrote:
> ..Progress*:..

I'll look at your code tomorrow, will comment here.

> ...*Perspectives*: When I will close the examples related to scheduler and
> SlingPostOperation (shortly) I don't know what I can do. I would like to
> show in David others interesting features of Sling, so I ask you also to
> suggest or simply open JIRA issues related to...

The GSoC timeline suggests stopping development next Monday, and
spending next week on documentation etc.

I think that would be a good thing for your project. I can do a review
tomorrow and suggest refactorings that might help make things more
obvious, if needed. After that I'd suggest that you also review your
code and comment or improve it where needed, so that it can fulfill
its educational goals.

How about writing docs withing your CMS, and loading them as initial
content where it starts? This would allow you to point directly to
your source code in your docs, to help people understand how the
things works.

I don't think you need tons of docs, it's mostly an overview of the
use cases that points to the code that implements them. The audience
of Sling is programmers, so no need to water down things IMHO.

I'll do my final mentor evaluation of your GSoC work in a week from
now, August 12th or 13th, so make sure everything looks good by then!
And please attach the complete code as a patch to SLING-1438 by that
time, checking the "allow the ASF to use that code" box if you agree,
so that we can integrate it in Sling.

Back tomorrow once I have reviewed the current code.

-Bertrand

Re: Allow modify during "import" operation

[Simon Gaeremynck]

This issue has been reported as [1] SLING-1627 and a patch was provided.
Is it possible to merge this in as this is blocking a Sakai release.

Regards,
Simon

[1] https://issues.apache.org/jira/browse/SLING-1627


On 3 Aug 2010, at 20:06, Eric Norman wrote:

> Hi Mike,
> 
> I would lean toward making the property overwrite a separate import option
> for the same reasons you outlined below.
> 
> Regards,
> -Eric
> 
> On Fri, Jul 30, 2010 at 12:00 PM, Mike Moulton  wrote:
> 
>> I will work on a patch for this.
>> 
>> Should we add ImportOptions.isPropertyOverwrite or should I use the
>> existing ImportOptions.isOverwrite for both nodes and properties? Seems to
>> me using the same option could be dangerous as isOverwrite currently causes
>> the node to be removed before adding the new node. Causing unintended
>> consequences if you only wished to modify properties, not replacing the node
>> altogether.
>> 
>> Thoughts?
>> 
>> -- Mike
>> 
>> 
>> On Jul 30, 2010, at 2:26 AM, Bertrand Delacretaz wrote:
>> 
>>> Hi,
>>> 
>>> On Fri, Jul 30, 2010 at 1:30 AM, Mike Moulton 
>> wrote:
 I have the need to use the "import" operation provided by SLING-1172 to
>> modify a structure, or more specifically a property. Looking at the
>> DefaultContentCreator.java:311 it looks like property modification is turned
>> off for the path the ImportOperation.java takes through the codebase.
 
 Can someone, who knows the content loader codebase better, chime in on
>> what they think the level of effort might be here. Is this something that
>> should be supported by Sling or should I maintain my own codebase for
>> something like this?
>>> 
>>> So basically you want to add an option to continue writing the
>>> property here, instead of returning?
>>> 
>>>   if (node.hasProperty(name)
>>>   && !node.getProperty(name).isNew()) {
>>>   return;
>>>   }
>>> 
>>> That looks simple enough, I think you'd just need to add an
>>> isPropertyOverwrite() method to ImportOptions and its implementations,
>>> and in the ImportOperation class (servlets.post bundle) set that
>>> option according to a request parameter.
>>> 
>>> ImportOptions of part of a public API but hasn't been released yet, so
>>> I think we can still change it.
>>> 
 ...Is this something that should be supported by Sling or should I
>> maintain my own codebase for
 something like this?...
>>> 
>>> I'd be +1 on adding that feature if someone (hint, hint ;-) can
>>> provide a patch including tests.
>>> 
>>> -Bertrand
>> 
>> 

Re: Allow modify during "import" operation

[Mike Moulton]

I would love to have this incorporated into the trunk. At this point my company 
is using a custom operation until the trunk fully supports merging.

Thank you Simon for creating this patch as I never got to it.

Regards,
Mike

On Aug 5, 2010, at 10:36 AM, Simon Gaeremynck wrote:

> This issue has been reported as [1] SLING-1627 and a patch was provided.
> Is it possible to merge this in as this is blocking a Sakai release.
> 
> Regards,
> Simon
> 
> [1] https://issues.apache.org/jira/browse/SLING-1627
> 
> 
> On 3 Aug 2010, at 20:06, Eric Norman wrote:
> 
>> Hi Mike,
>> 
>> I would lean toward making the property overwrite a separate import option
>> for the same reasons you outlined below.
>> 
>> Regards,
>> -Eric
>> 
>> On Fri, Jul 30, 2010 at 12:00 PM, Mike Moulton  wrote:
>> 
>>> I will work on a patch for this.
>>> 
>>> Should we add ImportOptions.isPropertyOverwrite or should I use the
>>> existing ImportOptions.isOverwrite for both nodes and properties? Seems to
>>> me using the same option could be dangerous as isOverwrite currently causes
>>> the node to be removed before adding the new node. Causing unintended
>>> consequences if you only wished to modify properties, not replacing the node
>>> altogether.
>>> 
>>> Thoughts?
>>> 
>>> -- Mike
>>> 
>>> 
>>> On Jul 30, 2010, at 2:26 AM, Bertrand Delacretaz wrote:
>>> 
 Hi,
 
 On Fri, Jul 30, 2010 at 1:30 AM, Mike Moulton 
>>> wrote:
> I have the need to use the "import" operation provided by SLING-1172 to
>>> modify a structure, or more specifically a property. Looking at the
>>> DefaultContentCreator.java:311 it looks like property modification is turned
>>> off for the path the ImportOperation.java takes through the codebase.
> 
> Can someone, who knows the content loader codebase better, chime in on
>>> what they think the level of effort might be here. Is this something that
>>> should be supported by Sling or should I maintain my own codebase for
>>> something like this?
 
 So basically you want to add an option to continue writing the
 property here, instead of returning?
 
  if (node.hasProperty(name)
  && !node.getProperty(name).isNew()) {
  return;
  }
 
 That looks simple enough, I think you'd just need to add an
 isPropertyOverwrite() method to ImportOptions and its implementations,
 and in the ImportOperation class (servlets.post bundle) set that
 option according to a request parameter.
 
 ImportOptions of part of a public API but hasn't been released yet, so
 I think we can still change it.
 
> ...Is this something that should be supported by Sling or should I
>>> maintain my own codebase for
> something like this?...
 
 I'd be +1 on adding that feature if someone (hint, hint ;-) can
 provide a patch including tests.
 
 -Bertrand
>>> 
>>> 
> 

[jira] Created: (SLING-1629) Add methods for externalizing links to SlingHttpServletRequest

[Alexander Klimetschek (JIRA)]

Add methods for externalizing links to SlingHttpServletRequest
--

 Key: SLING-1629
 URL: https://issues.apache.org/jira/browse/SLING-1629
 Project: Sling
  Issue Type: New Feature
  Components: API, Engine
Reporter: Alexander Klimetschek
Priority: Minor


When creating links in responses there are two cases:

1) create it for use by the browser: URLs relative to the current request
2) link used by external apps: absolute URL including hostname etc.

For 1), you can already use ResourceResolver.map(request, path) (important to 
use the request-based here).

For 2), when you explicitly want absolute URLs (eg. for rss feeds, links in 
emails, etc.), the ResourceResolver map methods will only add a host/port if 
such a configuration is part of /etc/map. There is no default to use the 
host/port from the current request.

In order to provide convenient short access to those features, an externalize 
method on the sling request object is better for both cases:

case 1) relative url

slingRequest.externalize("/my/path")

same as slingRequest.getResourceResolver().map(slingRequest, "/my/path"))

case 2) absolute url

slingRequest.externalize("http", "/my/path")

produces e.g. http://localhost:8080/my/path

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (SLING-1629) Add methods for externalizing links to SlingHttpServletRequest

[Alexander Klimetschek (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-1629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexander Klimetschek updated SLING-1629:
-

Attachment: SLING-1629.patch

Patch adding the two externalize() methods, including javadocs and a unit test.

Apart from whether this makes sense at all, there are some questions probably:
- detail of javadocs ok?
- are two methods ok? or only add the one with the new feature: 
externalize(scheme,path)?
  (as noted, the other one is shorter than the identical map call, thus still 
useful)
- changes sling api (but could be included in upcoming release)

> Add methods for externalizing links to SlingHttpServletRequest
> --
>
> Key: SLING-1629
> URL: https://issues.apache.org/jira/browse/SLING-1629
> Project: Sling
>  Issue Type: New Feature
>  Components: API, Engine
>Reporter: Alexander Klimetschek
>Priority: Minor
> Attachments: SLING-1629.patch
>
>
> When creating links in responses there are two cases:
> 1) create it for use by the browser: URLs relative to the current request
> 2) link used by external apps: absolute URL including hostname etc.
> For 1), you can already use ResourceResolver.map(request, path) (important to 
> use the request-based here).
> For 2), when you explicitly want absolute URLs (eg. for rss feeds, links in 
> emails, etc.), the ResourceResolver map methods will only add a host/port if 
> such a configuration is part of /etc/map. There is no default to use the 
> host/port from the current request.
> In order to provide convenient short access to those features, an externalize 
> method on the sling request object is better for both cases:
> case 1) relative url
> slingRequest.externalize("/my/path")
> same as slingRequest.getResourceResolver().map(slingRequest, "/my/path"))
> case 2) absolute url
> slingRequest.externalize("http", "/my/path")
> produces e.g. http://localhost:8080/my/path

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Allow modify during "import" operation

[Simon Gaeremynck]

I cannot take any credit for this. 
It was Zach Thomas who did all the work and it would be totally awesome if it 
got merged in. :-)

Cheers,
Simon


On 5 Aug 2010, at 20:18, Mike Moulton wrote:

> I would love to have this incorporated into the trunk. At this point my 
> company is using a custom operation until the trunk fully supports merging.
> 
> Thank you Simon for creating this patch as I never got to it.
> 
> Regards,
> Mike
> 
> On Aug 5, 2010, at 10:36 AM, Simon Gaeremynck wrote:
> 
>> This issue has been reported as [1] SLING-1627 and a patch was provided.
>> Is it possible to merge this in as this is blocking a Sakai release.
>> 
>> Regards,
>> Simon
>> 
>> [1] https://issues.apache.org/jira/browse/SLING-1627
>> 
>> 
>> On 3 Aug 2010, at 20:06, Eric Norman wrote:
>> 
>>> Hi Mike,
>>> 
>>> I would lean toward making the property overwrite a separate import option
>>> for the same reasons you outlined below.
>>> 
>>> Regards,
>>> -Eric
>>> 
>>> On Fri, Jul 30, 2010 at 12:00 PM, Mike Moulton  wrote:
>>> 
 I will work on a patch for this.
 
 Should we add ImportOptions.isPropertyOverwrite or should I use the
 existing ImportOptions.isOverwrite for both nodes and properties? Seems to
 me using the same option could be dangerous as isOverwrite currently causes
 the node to be removed before adding the new node. Causing unintended
 consequences if you only wished to modify properties, not replacing the 
 node
 altogether.
 
 Thoughts?
 
 -- Mike
 
 
 On Jul 30, 2010, at 2:26 AM, Bertrand Delacretaz wrote:
 
> Hi,
> 
> On Fri, Jul 30, 2010 at 1:30 AM, Mike Moulton 
 wrote:
>> I have the need to use the "import" operation provided by SLING-1172 to
 modify a structure, or more specifically a property. Looking at the
 DefaultContentCreator.java:311 it looks like property modification is 
 turned
 off for the path the ImportOperation.java takes through the codebase.
>> 
>> Can someone, who knows the content loader codebase better, chime in on
 what they think the level of effort might be here. Is this something that
 should be supported by Sling or should I maintain my own codebase for
 something like this?
> 
> So basically you want to add an option to continue writing the
> property here, instead of returning?
> 
> if (node.hasProperty(name)
> && !node.getProperty(name).isNew()) {
> return;
> }
> 
> That looks simple enough, I think you'd just need to add an
> isPropertyOverwrite() method to ImportOptions and its implementations,
> and in the ImportOperation class (servlets.post bundle) set that
> option according to a request parameter.
> 
> ImportOptions of part of a public API but hasn't been released yet, so
> I think we can still change it.
> 
>> ...Is this something that should be supported by Sling or should I
 maintain my own codebase for
>> something like this?...
> 
> I'd be +1 on adding that feature if someone (hint, hint ;-) can
> provide a patch including tests.
> 
> -Bertrand
 
 
>> 
> 

[RT] SlingHttpServletRequest.externalize() methods

[Alexander Klimetschek]

Hi all,

I'd like to have a method on the SlingHttpServletRequest that
externalizes URLs, ie. just as map() in the resource resolver it
converts an internal resource path into a fully valid URL for access
from the outside:

relative: /my/sub/path => /contextpath/my/sub/path
absolute: /my/sub/path => http://server.com/contextpath/my/sub/path

For URLs relative to the current request, this is already possible by
using one of the resource resolver map() methods:

slingRequest.getResourceResolver().map(slingRequest, "/my/path"))

...which is a bit clunky for placing it into JSPs.

For absolute URLs, that must include a host/port, using map() is not
enough. If no host -> path mapping is configured (eg. myserver.80/ ->
/ in /etc/map), you'd typically like to use the current request as the
default, which isn't done by any of the map() methods.

Also, if a hostname is configured and you use the map(request, path),
because that is required for adding the context path, it will _strip_
it from the map call if the current request goes to that hostname,
which is probably the normal case (this is correct, as the
map(request, path) call is aimed at relative URLs).

Therefore additional methods on the request object make sense, I think.

See https://issues.apache.org/jira/browse/SLING-1629 for a patch.

WDYT?

Regards,
Alex

-- 
Alexander Klimetschek
alexander.klimetsc...@day.com

[jira] Updated: (SLING-1629) Add methods for externalizing links to SlingHttpServletRequest

[Alexander Klimetschek (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-1629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexander Klimetschek updated SLING-1629:
-

Description: 
When creating links in responses there are two cases:

1) create it for use by the browser: URLs relative to the current request
2) link used by external apps: absolute URL including hostname etc.

For 1), you can already use ResourceResolver.map(request, path) (important to 
use the request-based here).

For 2), when you explicitly want absolute URLs (eg. for rss feeds, links in 
emails, etc.), the ResourceResolver map methods will only add a host/port if 
such a configuration is part of /etc/map. There is no default to use the 
host/port from the current request.

Also, if a hostname is configured and you use map(request, path), because that 
is required for adding the context path, it will _strip_ it from the map call 
if the current request goes to that hostname, which is probably the normal 
case. The map(request, path) call is clearly aimed at relative URLs, case 1).

In order to provide convenient short access to those features, an externalize 
method on the sling request object is better for both cases:

case 1) relative url

slingRequest.externalize("/my/path")

same as slingRequest.getResourceResolver().map(slingRequest, "/my/path"))

case 2) absolute url

slingRequest.externalize("http", "/my/path")

produces e.g. http://localhost:8080/my/path

  was:
When creating links in responses there are two cases:

1) create it for use by the browser: URLs relative to the current request
2) link used by external apps: absolute URL including hostname etc.

For 1), you can already use ResourceResolver.map(request, path) (important to 
use the request-based here).

For 2), when you explicitly want absolute URLs (eg. for rss feeds, links in 
emails, etc.), the ResourceResolver map methods will only add a host/port if 
such a configuration is part of /etc/map. There is no default to use the 
host/port from the current request.

In order to provide convenient short access to those features, an externalize 
method on the sling request object is better for both cases:

case 1) relative url

slingRequest.externalize("/my/path")

same as slingRequest.getResourceResolver().map(slingRequest, "/my/path"))

case 2) absolute url

slingRequest.externalize("http", "/my/path")

produces e.g. http://localhost:8080/my/path


> Add methods for externalizing links to SlingHttpServletRequest
> --
>
> Key: SLING-1629
> URL: https://issues.apache.org/jira/browse/SLING-1629
> Project: Sling
>  Issue Type: New Feature
>  Components: API, Engine
>Reporter: Alexander Klimetschek
>Priority: Minor
> Attachments: SLING-1629.patch
>
>
> When creating links in responses there are two cases:
> 1) create it for use by the browser: URLs relative to the current request
> 2) link used by external apps: absolute URL including hostname etc.
> For 1), you can already use ResourceResolver.map(request, path) (important to 
> use the request-based here).
> For 2), when you explicitly want absolute URLs (eg. for rss feeds, links in 
> emails, etc.), the ResourceResolver map methods will only add a host/port if 
> such a configuration is part of /etc/map. There is no default to use the 
> host/port from the current request.
> Also, if a hostname is configured and you use map(request, path), because 
> that is required for adding the context path, it will _strip_ it from the map 
> call if the current request goes to that hostname, which is probably the 
> normal case. The map(request, path) call is clearly aimed at relative URLs, 
> case 1).
> In order to provide convenient short access to those features, an externalize 
> method on the sling request object is better for both cases:
> case 1) relative url
> slingRequest.externalize("/my/path")
> same as slingRequest.getResourceResolver().map(slingRequest, "/my/path"))
> case 2) absolute url
> slingRequest.externalize("http", "/my/path")
> produces e.g. http://localhost:8080/my/path

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Assigned: (SLING-1627) import operation does not respect :replace=true for properties

[Eric Norman (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-1627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eric Norman reassigned SLING-1627:
--

Assignee: Eric Norman

> import operation does not respect :replace=true for properties
> --
>
> Key: SLING-1627
> URL: https://issues.apache.org/jira/browse/SLING-1627
> Project: Sling
>  Issue Type: Bug
>  Components: JCR
>Reporter: Zach A. Thomas
>Assignee: Eric Norman
> Attachments: SLING-1627.patch
>
>
> If I want to import some JSON and then update it with a subsequent POST 
> (using the :replace=true flag), the nodes are updated, but not the properties.
> curl -u admin:admin -F":operation=import" -F":contentType=json" 
> -F':content={"columns": {"one":"value"}, "layout": "dev"}' 
> http://localhost:8080/dashboard
> If I do a subsequent POST with the :replace parameter:
> curl -u admin:admin -F":operation=import" -F":contentType=json" 
> -F':content={"columns": {"one":"love"}, "layout": "dev"}' -F":replace=true" 
> http://localhost:8080/dashboard
> The columns object is updated, but the layout property is not. I tracked this 
> down to Sling's DefaultContentCreator, whose createProperty method expressly 
> won't overwrite a property if it already exists.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Allow modify during "import" operation

[Eric Norman]

I will try to find some time to review the patch in the next few days.

Regards,
Eric

On Aug 5, 2010 11:25 AM, "Simon Gaeremynck"  wrote:

I cannot take any credit for this.
It was Zach Thomas who did all the work and it would be totally awesome if
it got merged in. :-)

Cheers,
Simon



On 5 Aug 2010, at 20:18, Mike Moulton wrote:

> I would love to have this incorporated into the tr...

[jira] Commented: (SLING-1629) Add methods for externalizing links to SlingHttpServletRequest

[Alexander Klimetschek (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-1629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12895816#action_12895816
 ] 

Alexander Klimetschek commented on SLING-1629:
--

Hmm, might not be enough. I also noted that quite often you
a) don't have the request object available in your API, as you adapted 
something from resource, and have only the ResourceResolver.map(string) method 
available
b) for background-processes, you might have the need to create feeds etc. with 
absolute URLs

So for b) without any request object at all, you need to solve
- how to get the context path
- what to use as default host/port name if nothing is configured in /etc/map

Regardless how it is solved, a method for that could not reside in 
SlingHttpServletRequest of course...

> Add methods for externalizing links to SlingHttpServletRequest
> --
>
> Key: SLING-1629
> URL: https://issues.apache.org/jira/browse/SLING-1629
> Project: Sling
>  Issue Type: New Feature
>  Components: API, Engine
>Reporter: Alexander Klimetschek
>Priority: Minor
> Attachments: SLING-1629.patch
>
>
> When creating links in responses there are two cases:
> 1) create it for use by the browser: URLs relative to the current request
> 2) link used by external apps: absolute URL including hostname etc.
> For 1), you can already use ResourceResolver.map(request, path) (important to 
> use the request-based here).
> For 2), when you explicitly want absolute URLs (eg. for rss feeds, links in 
> emails, etc.), the ResourceResolver map methods will only add a host/port if 
> such a configuration is part of /etc/map. There is no default to use the 
> host/port from the current request.
> Also, if a hostname is configured and you use map(request, path), because 
> that is required for adding the context path, it will _strip_ it from the map 
> call if the current request goes to that hostname, which is probably the 
> normal case. The map(request, path) call is clearly aimed at relative URLs, 
> case 1).
> In order to provide convenient short access to those features, an externalize 
> method on the sling request object is better for both cases:
> case 1) relative url
> slingRequest.externalize("/my/path")
> same as slingRequest.getResourceResolver().map(slingRequest, "/my/path"))
> case 2) absolute url
> slingRequest.externalize("http", "/my/path")
> produces e.g. http://localhost:8080/my/path

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[VOTE] Grant Jean Christophe write access to the docs [was Re: Scheduler service problem]

[Carsten Ziegeler]

Hi,

I would like to call a vote to give Jean Christophe write access to our
documentation. He is volunteering to help in an area where we definitly
need help and he also did some valuable docs in the past (together with me).

So please cast your votes.

Regards
Carsten

Jean Christophe Kautzmann  wrote
> Hi,
> 
> How about adding a hint to the docs stating that other bundles might be
> needed and that a list of dependencies can be found in the manifest.mf file
> of the scheduler bundle?
> I'd volunteer to adapt the docs (that I happen to draft with Carsten)
> accordingly but I'd need access rights for that :)
> 
> Cheers JC
> 
> On Thu, Aug 5, 2010 at 1:14 PM, Mike Müller  wrote:
> 
>> Hi
>>
>> Such depencies are reflected in the manifest.mf file of each
>> bundle. I don't think it's a good idea, to put them manually
>> into the documentation, as long as they can change over time.
>>
>> best regards
>> mike
>>
>>> -Original Message-
>>> From: Federico Paparoni [mailto:federico.papar...@gmail.com]
>>> Sent: Thursday, August 05, 2010 10:04 AM
>>> To: us...@sling.apache.org
>>> Subject: Re: Scheduler service problem
>>>
>>>
>>> 2010/8/5 Carsten Ziegeler 
>>>
 Hi,

 the scheduler needs two other bundles:

 org.apache.commons.collections (which should be installed)
 org.apache.sling.commons.threads 3.0.0

 Regards
 Carsten


>>> Now everything works, thanks.
>>> Anyway I think these informations should be available on the
>>> documentation (
>>> http://sling.apache.org/site/scheduler-service-commons-schedul
>> er.html
>> ).
>>
>> --
>> Federico
>>
> 


-- 
Carsten Ziegeler
cziege...@apache.org

Re: [RT] SlingHttpServletRequest.externalize() methods

[Carsten Ziegeler]

What about a helper class (static methods) or a jsp taglib?

Regards
Carsten

Alexander Klimetschek  wrote
> Hi all,
> 
> I'd like to have a method on the SlingHttpServletRequest that
> externalizes URLs, ie. just as map() in the resource resolver it
> converts an internal resource path into a fully valid URL for access
> from the outside:
> 
> relative: /my/sub/path => /contextpath/my/sub/path
> absolute: /my/sub/path => http://server.com/contextpath/my/sub/path
> 
> For URLs relative to the current request, this is already possible by
> using one of the resource resolver map() methods:
> 
> slingRequest.getResourceResolver().map(slingRequest, "/my/path"))
> 
> ...which is a bit clunky for placing it into JSPs.
> 
> For absolute URLs, that must include a host/port, using map() is not
> enough. If no host -> path mapping is configured (eg. myserver.80/ ->
> / in /etc/map), you'd typically like to use the current request as the
> default, which isn't done by any of the map() methods.
> 
> Also, if a hostname is configured and you use the map(request, path),
> because that is required for adding the context path, it will _strip_
> it from the map call if the current request goes to that hostname,
> which is probably the normal case (this is correct, as the
> map(request, path) call is aimed at relative URLs).
> 
> Therefore additional methods on the request object make sense, I think.
> 
> See https://issues.apache.org/jira/browse/SLING-1629 for a patch.
> 
> WDYT?
> 
> Regards,
> Alex
> 


-- 
Carsten Ziegeler
cziege...@apache.org

[jira] Created: (SLING-1630) Architecture of Sling

[Alison Heimoz (JIRA)]

Architecture of Sling
-

 Key: SLING-1630
 URL: https://issues.apache.org/jira/browse/SLING-1630
 Project: Sling
  Issue Type: Improvement
  Components: Documentation
Reporter: Alison Heimoz
Priority: Minor


- typos, some of which impact ease of understanding
- OSGi
  -- a sentence or two on why OSGi was chosen would be interesting
--- e.g. the advantages (contracts, dependencies, services are dynamic)
--- link to something like 
http://www.informit.com/articles/article.aspx?p=1565539&seqNum=2 ?
- introductory list:
  -- would move the "Resources" entry further up in the list as it is the 
"central mantra"; i.e. first or second - before it is 
 referenced in any way
...tbc...

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [VOTE] Grant Jean Christophe write access to the docs [was Re: Scheduler service problem]

[Alison Heimoz]

Hi Carsten

+1 for Jean Christophe.

And can I add my own name to the request for access rights to documentation?

I've already entered a few Jiras on documentation after reviewing/testing
some of the getting started/introduction pages.
It would make it quicker if I could update directly as well.

Cheers Alison


On Fri, Aug 6, 2010 at 8:08 AM, Carsten Ziegeler wrote:

> Hi,
>
> I would like to call a vote to give Jean Christophe write access to our
> documentation. He is volunteering to help in an area where we definitly
> need help and he also did some valuable docs in the past (together with
> me).
>
> So please cast your votes.
>
> Regards
> Carsten
>
> Jean Christophe Kautzmann  wrote
> > Hi,
> >
> > How about adding a hint to the docs stating that other bundles might be
> > needed and that a list of dependencies can be found in the manifest.mf
> file
> > of the scheduler bundle?
> > I'd volunteer to adapt the docs (that I happen to draft with Carsten)
> > accordingly but I'd need access rights for that :)
> >
> > Cheers JC
> >
> > On Thu, Aug 5, 2010 at 1:14 PM, Mike Müller  wrote:
> >
> >> Hi
> >>
> >> Such depencies are reflected in the manifest.mf file of each
> >> bundle. I don't think it's a good idea, to put them manually
> >> into the documentation, as long as they can change over time.
> >>
> >> best regards
> >> mike
> >>
> >>> -Original Message-
> >>> From: Federico Paparoni [mailto:federico.papar...@gmail.com]
> >>> Sent: Thursday, August 05, 2010 10:04 AM
> >>> To: us...@sling.apache.org
> >>> Subject: Re: Scheduler service problem
> >>>
> >>>
> >>> 2010/8/5 Carsten Ziegeler 
> >>>
>  Hi,
> 
>  the scheduler needs two other bundles:
> 
>  org.apache.commons.collections (which should be installed)
>  org.apache.sling.commons.threads 3.0.0
> 
>  Regards
>  Carsten
> 
> 
> >>> Now everything works, thanks.
> >>> Anyway I think these informations should be available on the
> >>> documentation (
> >>> http://sling.apache.org/site/scheduler-service-commons-schedul
> >> er.html<
> http://sling.apache.org/site/scheduler-service-commons-schedul%0Aer.html>
> >> ).
> >>
> >> --
> >> Federico
> >>
> >
>
>
> --
> Carsten Ziegeler
> cziege...@apache.org
>

Re: [VOTE] Grant Jean Christophe write access to the docs [was Re: Scheduler service problem]

[Carsten Ziegeler]

+1

Carsten

Carsten Ziegeler  wrote
> Hi,
> 
> I would like to call a vote to give Jean Christophe write access to our
> documentation. He is volunteering to help in an area where we definitly
> need help and he also did some valuable docs in the past (together with me).
> 
> So please cast your votes.
> 
> Regards
> Carsten
> 
> Jean Christophe Kautzmann  wrote
>> Hi,
>>
>> How about adding a hint to the docs stating that other bundles might be
>> needed and that a list of dependencies can be found in the manifest.mf file
>> of the scheduler bundle?
>> I'd volunteer to adapt the docs (that I happen to draft with Carsten)
>> accordingly but I'd need access rights for that :)
>>
>> Cheers JC
>>
>> On Thu, Aug 5, 2010 at 1:14 PM, Mike Müller  wrote:
>>
>>> Hi
>>>
>>> Such depencies are reflected in the manifest.mf file of each
>>> bundle. I don't think it's a good idea, to put them manually
>>> into the documentation, as long as they can change over time.
>>>
>>> best regards
>>> mike
>>>
 -Original Message-
 From: Federico Paparoni [mailto:federico.papar...@gmail.com]
 Sent: Thursday, August 05, 2010 10:04 AM
 To: us...@sling.apache.org
 Subject: Re: Scheduler service problem


 2010/8/5 Carsten Ziegeler 

> Hi,
>
> the scheduler needs two other bundles:
>
> org.apache.commons.collections (which should be installed)
> org.apache.sling.commons.threads 3.0.0
>
> Regards
> Carsten
>
>
 Now everything works, thanks.
 Anyway I think these informations should be available on the
 documentation (
 http://sling.apache.org/site/scheduler-service-commons-schedul
>>> er.html
>>> ).
>>>
>>> --
>>> Federico
>>>
>>
> 
> 


-- 
Carsten Ziegeler
cziege...@apache.org

[VOTE] Grant Alison write access to the docs

[Carsten Ziegeler]

Hi,

I would like to call another vote for a new documentation writer: Alison :)

Like Jean Christophe she is volunteering to help us and has already made
suggestions for improvements and helped with the docs.

So please cast your votes.

Regards
Carsten

Alison Heimoz  wrote
> Hi Carsten
> 
> +1 for Jean Christophe.
> 
> And can I add my own name to the request for access rights to documentation?
> 
> I've already entered a few Jiras on documentation after reviewing/testing
> some of the getting started/introduction pages.
> It would make it quicker if I could update directly as well.
> 
> Cheers Alison
> 
> 
> On Fri, Aug 6, 2010 at 8:08 AM, Carsten Ziegeler wrote:
> 
>> Hi,
>>
>> I would like to call a vote to give Jean Christophe write access to our
>> documentation. He is volunteering to help in an area where we definitly
>> need help and he also did some valuable docs in the past (together with
>> me).
>>
>> So please cast your votes.
>>
>> Regards
>> Carsten
>>
>> Jean Christophe Kautzmann  wrote
>>> Hi,
>>>
>>> How about adding a hint to the docs stating that other bundles might be
>>> needed and that a list of dependencies can be found in the manifest.mf
>> file
>>> of the scheduler bundle?
>>> I'd volunteer to adapt the docs (that I happen to draft with Carsten)
>>> accordingly but I'd need access rights for that :)
>>>
>>> Cheers JC
>>>
>>> On Thu, Aug 5, 2010 at 1:14 PM, Mike Müller  wrote:
>>>
 Hi

 Such depencies are reflected in the manifest.mf file of each
 bundle. I don't think it's a good idea, to put them manually
 into the documentation, as long as they can change over time.

 best regards
 mike

> -Original Message-
> From: Federico Paparoni [mailto:federico.papar...@gmail.com]
> Sent: Thursday, August 05, 2010 10:04 AM
> To: us...@sling.apache.org
> Subject: Re: Scheduler service problem
>
>
> 2010/8/5 Carsten Ziegeler 
>
>> Hi,
>>
>> the scheduler needs two other bundles:
>>
>> org.apache.commons.collections (which should be installed)
>> org.apache.sling.commons.threads 3.0.0
>>
>> Regards
>> Carsten
>>
>>
> Now everything works, thanks.
> Anyway I think these informations should be available on the
> documentation (
> http://sling.apache.org/site/scheduler-service-commons-schedul
 er.html<
>> http://sling.apache.org/site/scheduler-service-commons-schedul%0Aer.html>
 ).

 --
 Federico

>>>
>>
>>
>> --
>> Carsten Ziegeler
>> cziege...@apache.org
>>
> 


-- 
Carsten Ziegeler
cziege...@apache.org

Re: [VOTE] Grant Alison write access to the docs

[Carsten Ziegeler]

+1

Carsten

Carsten Ziegeler  wrote
> Hi,
> 
> I would like to call another vote for a new documentation writer: Alison :)
> 
> Like Jean Christophe she is volunteering to help us and has already made
> suggestions for improvements and helped with the docs.
> 
> So please cast your votes.
> 
> Regards
> Carsten
> 
> Alison Heimoz  wrote
>> Hi Carsten
>>
>> +1 for Jean Christophe.
>>
>> And can I add my own name to the request for access rights to documentation?
>>
>> I've already entered a few Jiras on documentation after reviewing/testing
>> some of the getting started/introduction pages.
>> It would make it quicker if I could update directly as well.
>>
>> Cheers Alison
>>
>>
>> On Fri, Aug 6, 2010 at 8:08 AM, Carsten Ziegeler wrote:
>>
>>> Hi,
>>>
>>> I would like to call a vote to give Jean Christophe write access to our
>>> documentation. He is volunteering to help in an area where we definitly
>>> need help and he also did some valuable docs in the past (together with
>>> me).
>>>
>>> So please cast your votes.
>>>
>>> Regards
>>> Carsten
>>>
>>> Jean Christophe Kautzmann  wrote
 Hi,

 How about adding a hint to the docs stating that other bundles might be
 needed and that a list of dependencies can be found in the manifest.mf
>>> file
 of the scheduler bundle?
 I'd volunteer to adapt the docs (that I happen to draft with Carsten)
 accordingly but I'd need access rights for that :)

 Cheers JC

 On Thu, Aug 5, 2010 at 1:14 PM, Mike Müller  wrote:

> Hi
>
> Such depencies are reflected in the manifest.mf file of each
> bundle. I don't think it's a good idea, to put them manually
> into the documentation, as long as they can change over time.
>
> best regards
> mike
>
>> -Original Message-
>> From: Federico Paparoni [mailto:federico.papar...@gmail.com]
>> Sent: Thursday, August 05, 2010 10:04 AM
>> To: us...@sling.apache.org
>> Subject: Re: Scheduler service problem
>>
>>
>> 2010/8/5 Carsten Ziegeler 
>>
>>> Hi,
>>>
>>> the scheduler needs two other bundles:
>>>
>>> org.apache.commons.collections (which should be installed)
>>> org.apache.sling.commons.threads 3.0.0
>>>
>>> Regards
>>> Carsten
>>>
>>>
>> Now everything works, thanks.
>> Anyway I think these informations should be available on the
>> documentation (
>> http://sling.apache.org/site/scheduler-service-commons-schedul
> er.html<
>>> http://sling.apache.org/site/scheduler-service-commons-schedul%0Aer.html>
> ).
>
> --
> Federico
>

>>>
>>>
>>> --
>>> Carsten Ziegeler
>>> cziege...@apache.org
>>>
>>
> 
> 


-- 
Carsten Ziegeler
cziege...@apache.org