You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Bertrand Delacretaz <bd...@apache.org> on 2008/11/11 12:31:04 UTC
Re: Sling breaks with pax-web 0.5.1
Hi Mark,
Going through my mail backlog I notice that we haven't replied to your
question, is that still current?
If yes it might be safer to create a JIRA issue so that doesn't fall
into the cracks - apparently none of us had an answer off the top of
their head.
-Bertrand
On Sun, Oct 19, 2008 at 11:55 PM, Mark Derricutt <ma...@talios.com> wrote:
> Hi all,
>
> We recently updated our sling based application (based around the
> sling-launchpad osgi deployer) to use pax-web-server 0.5.1 (which uses NIO)
> and have noticed that for some reason none of sling content gets returned
> anymore, instead we see:
>
> ** Node dumped by StreamRendererServlet**
> Node path:/
> Resource metadata: {sling.resolutionPath=/}
>
> ** Node properties **
> jcr:primaryType: rep:root
>
>
> being output to the browser. Is this a known issue or something new? Is
> there anything I can look at to try and diagnose whats going on?
>
> Mark
>
> --
> "It is easier to optimize correct code than to correct optimized code." --
> Bill Harlan
>
Re: Sling breaks with pax-web 0.5.1
Posted by Felix Meschberger <fm...@gmail.com>.
Hi Mark,
Mark Derricutt schrieb:
> This approach sounds reasonable - is there a SNAPSHOT bundle I can pull in
> with this applied at all? If not, I'll pull out the sling code and apply
> the patch locally to confirm everything works locally here.
No there is no SNAPSHOT yet. I just created SLING-736 and attached a
slightly modified patch which includes hard-coding the path of the
SlingMainServlet.
If you could grab the code and apply the patch for testing, this would
be cool ! Thanks alot. Otherwise just drop me a node and I can send it
to you off-list.
Regards
Felix
>
> On Mon, Nov 17, 2008 at 2:44 AM, Felix Meschberger <fm...@gmail.com>wrote:
>
>
>> * The SlingMainServlet is always registered with the HttpService with
>> the servlet path "/". This cannot be configurable.
>> * The SlingHttpServletRequestImpl, which is instantiated by the
>> SlingMainServlet to provide the SlingHttpServletRequest interface, is
>> modified to overwrite the getServletPath() and getPathInfo() methods as
>> follows (see also Section SRV.4.4 in Servlet API 2.4 spec) :
>> * getServletPath() always returns ""
>> * getPathInfo() always returns the getServletPath()+getPathInfo()
>> called on the servlet container (or HttpService provided)
>> HttpServletRequest object
>>
>> This should reproduce the behaviour of registering the SlingMainServlet
>> as "/*" no matter how the HttpService would handle this. See the
>> proposed patch attached below.
>>
>> WDYT ?
>>
>> BTW: We had a similar issue running a modified Sling Web App in Weblogic
>> 9, where getPathInfo() return null even though the request URL was not
>> addressed at the Servlet itself. This may be related.
>>
>>
>> Regards
>> Felix
>>
>> [1] http://www.mail-archive.com/osgi-dev@mail.osgi.org/msg00440.html
>>
>>
>> Proposed patch:
>>
>> Index:
>>
>> /usr/src/sling/head/engine/src/main/java/org/apache/sling/engine/impl/SlingHttpServletRequestImpl.java
>> ===================================================================
>> ---
>>
>> /usr/src/sling/head/engine/src/main/java/org/apache/sling/engine/impl/SlingHttpServletRequestImpl.java
>> (revision 713054)
>> +++
>>
>> /usr/src/sling/head/engine/src/main/java/org/apache/sling/engine/impl/SlingHttpServletRequestImpl.java
>> (working copy)
>> @@ -59,6 +59,7 @@
>> SlingHttpServletRequest {
>>
>> private final RequestData requestData;
>> + private final String pathInfo;
>> private String responseContentType;
>>
>> public SlingHttpServletRequestImpl(RequestData requestData,
>> @@ -65,6 +66,13 @@
>> HttpServletRequest servletRequest) {
>> super(servletRequest);
>> this.requestData = requestData;
>> +
>> + // prepare the pathInfo property
>> + String pathInfo = servletRequest.getServletPath();
>> + if (servletRequest.getPathInfo() != null) {
>> + pathInfo = pathInfo.concat(servletRequest.getPathInfo());
>> + }
>> + this.pathInfo = pathInfo;
>> }
>>
>> /**
>> @@ -275,6 +283,25 @@
>> }
>>
>> /**
>> + * Always returns the empty string since the actual servlet
>> registered with
>> + * the servlet container (the HttpService actually) is registered as
>> if
>> + * the servlet path is "/*".
>> + */
>> + @Override
>> + public String getServletPath() {
>> + return "";
>> + }
>> +
>> + /**
>> + * Returns the part of the request URL without the leading servlet
>> context
>> + * path.
>> + */
>> + @Override
>> + public String getPathInfo() {
>> + return pathInfo;
>> + }
>> +
>> + /**
>> * A <code>UserPrincipal</code> ...
>> */
>> private static class UserPrincipal implements Principal, Serializable {
>>
>>> Mark
>>>
>>>
>>> On Wed, Nov 12, 2008 at 10:14 AM, Bertrand Delacretaz <
>>> bdelacretaz@apache.org> wrote:
>>>
>>>> On Tue, Nov 11, 2008 at 9:34 PM, Mark Derricutt <ma...@talios.com>
>> wrote:
>>>>> ....We've raised a ticket over at OPS4J and
>>>>> the issue is scheduled for a 0.5.2 release:..
>>>> Cool, thanks for the info!
>>>> -Bertrand
>>>>
>>>
>>>
>
>
>
Re: Sling breaks with pax-web 0.5.1
Posted by Mark Derricutt <ma...@talios.com>.
This approach sounds reasonable - is there a SNAPSHOT bundle I can pull in
with this applied at all? If not, I'll pull out the sling code and apply
the patch locally to confirm everything works locally here.
On Mon, Nov 17, 2008 at 2:44 AM, Felix Meschberger <fm...@gmail.com>wrote:
> * The SlingMainServlet is always registered with the HttpService with
> the servlet path "/". This cannot be configurable.
> * The SlingHttpServletRequestImpl, which is instantiated by the
> SlingMainServlet to provide the SlingHttpServletRequest interface, is
> modified to overwrite the getServletPath() and getPathInfo() methods as
> follows (see also Section SRV.4.4 in Servlet API 2.4 spec) :
> * getServletPath() always returns ""
> * getPathInfo() always returns the getServletPath()+getPathInfo()
> called on the servlet container (or HttpService provided)
> HttpServletRequest object
>
> This should reproduce the behaviour of registering the SlingMainServlet
> as "/*" no matter how the HttpService would handle this. See the
> proposed patch attached below.
>
> WDYT ?
>
> BTW: We had a similar issue running a modified Sling Web App in Weblogic
> 9, where getPathInfo() return null even though the request URL was not
> addressed at the Servlet itself. This may be related.
>
>
> Regards
> Felix
>
> [1] http://www.mail-archive.com/osgi-dev@mail.osgi.org/msg00440.html
>
>
> Proposed patch:
>
> Index:
>
> /usr/src/sling/head/engine/src/main/java/org/apache/sling/engine/impl/SlingHttpServletRequestImpl.java
> ===================================================================
> ---
>
> /usr/src/sling/head/engine/src/main/java/org/apache/sling/engine/impl/SlingHttpServletRequestImpl.java
> (revision 713054)
> +++
>
> /usr/src/sling/head/engine/src/main/java/org/apache/sling/engine/impl/SlingHttpServletRequestImpl.java
> (working copy)
> @@ -59,6 +59,7 @@
> SlingHttpServletRequest {
>
> private final RequestData requestData;
> + private final String pathInfo;
> private String responseContentType;
>
> public SlingHttpServletRequestImpl(RequestData requestData,
> @@ -65,6 +66,13 @@
> HttpServletRequest servletRequest) {
> super(servletRequest);
> this.requestData = requestData;
> +
> + // prepare the pathInfo property
> + String pathInfo = servletRequest.getServletPath();
> + if (servletRequest.getPathInfo() != null) {
> + pathInfo = pathInfo.concat(servletRequest.getPathInfo());
> + }
> + this.pathInfo = pathInfo;
> }
>
> /**
> @@ -275,6 +283,25 @@
> }
>
> /**
> + * Always returns the empty string since the actual servlet
> registered with
> + * the servlet container (the HttpService actually) is registered as
> if
> + * the servlet path is "/*".
> + */
> + @Override
> + public String getServletPath() {
> + return "";
> + }
> +
> + /**
> + * Returns the part of the request URL without the leading servlet
> context
> + * path.
> + */
> + @Override
> + public String getPathInfo() {
> + return pathInfo;
> + }
> +
> + /**
> * A <code>UserPrincipal</code> ...
> */
> private static class UserPrincipal implements Principal, Serializable {
>
> >
> > Mark
> >
> >
> > On Wed, Nov 12, 2008 at 10:14 AM, Bertrand Delacretaz <
> > bdelacretaz@apache.org> wrote:
> >
> >> On Tue, Nov 11, 2008 at 9:34 PM, Mark Derricutt <ma...@talios.com>
> wrote:
> >>> ....We've raised a ticket over at OPS4J and
> >>> the issue is scheduled for a 0.5.2 release:..
> >> Cool, thanks for the info!
> >> -Bertrand
> >>
> >
> >
> >
>
--
"It is easier to optimize correct code than to correct optimized code." --
Bill Harlan
Re: Sling breaks with pax-web 0.5.1
Posted by Felix Meschberger <fm...@gmail.com>.
Hi Mark,
Mark Derricutt schrieb:
> Hi Bertrand,
>
> Looks like the paxweb ticket we raised (
> http://issues.ops4j.org/jira/browse/PAXWEB-108) has been closed "wont-fix"
> as its actually now doing the correct thing according to the Servlet 2.4
> spec, section 11.2 reads:
>
> "A string containing only the '/' character indicates the "default" servlet
> of
> the application. In this case the servlet path is the request URI minus the
> context
> path and the path info is null."
>
> I've not yet tried it, but I'm wondering if the sling servlet gets mounted
> as '/*' then we'd see the path info being restored. Shall I go raise this
> as a Sling issue?
After digging around a bit (and also reading a post by Alin Dereghiciu
on the OSGi dev list [1]), I think we should fix something in the Sling
engine ...
How about this approach (all in the engine module) :
* The SlingMainServlet is always registered with the HttpService with
the servlet path "/". This cannot be configurable.
* The SlingHttpServletRequestImpl, which is instantiated by the
SlingMainServlet to provide the SlingHttpServletRequest interface, is
modified to overwrite the getServletPath() and getPathInfo() methods as
follows (see also Section SRV.4.4 in Servlet API 2.4 spec) :
* getServletPath() always returns ""
* getPathInfo() always returns the getServletPath()+getPathInfo()
called on the servlet container (or HttpService provided)
HttpServletRequest object
This should reproduce the behaviour of registering the SlingMainServlet
as "/*" no matter how the HttpService would handle this. See the
proposed patch attached below.
WDYT ?
BTW: We had a similar issue running a modified Sling Web App in Weblogic
9, where getPathInfo() return null even though the request URL was not
addressed at the Servlet itself. This may be related.
Regards
Felix
[1] http://www.mail-archive.com/osgi-dev@mail.osgi.org/msg00440.html
Proposed patch:
Index:
/usr/src/sling/head/engine/src/main/java/org/apache/sling/engine/impl/SlingHttpServletRequestImpl.java
===================================================================
---
/usr/src/sling/head/engine/src/main/java/org/apache/sling/engine/impl/SlingHttpServletRequestImpl.java
(revision 713054)
+++
/usr/src/sling/head/engine/src/main/java/org/apache/sling/engine/impl/SlingHttpServletRequestImpl.java
(working copy)
@@ -59,6 +59,7 @@
SlingHttpServletRequest {
private final RequestData requestData;
+ private final String pathInfo;
private String responseContentType;
public SlingHttpServletRequestImpl(RequestData requestData,
@@ -65,6 +66,13 @@
HttpServletRequest servletRequest) {
super(servletRequest);
this.requestData = requestData;
+
+ // prepare the pathInfo property
+ String pathInfo = servletRequest.getServletPath();
+ if (servletRequest.getPathInfo() != null) {
+ pathInfo = pathInfo.concat(servletRequest.getPathInfo());
+ }
+ this.pathInfo = pathInfo;
}
/**
@@ -275,6 +283,25 @@
}
/**
+ * Always returns the empty string since the actual servlet
registered with
+ * the servlet container (the HttpService actually) is registered as if
+ * the servlet path is "/*".
+ */
+ @Override
+ public String getServletPath() {
+ return "";
+ }
+
+ /**
+ * Returns the part of the request URL without the leading servlet
context
+ * path.
+ */
+ @Override
+ public String getPathInfo() {
+ return pathInfo;
+ }
+
+ /**
* A <code>UserPrincipal</code> ...
*/
private static class UserPrincipal implements Principal, Serializable {
>
> Mark
>
>
> On Wed, Nov 12, 2008 at 10:14 AM, Bertrand Delacretaz <
> bdelacretaz@apache.org> wrote:
>
>> On Tue, Nov 11, 2008 at 9:34 PM, Mark Derricutt <ma...@talios.com> wrote:
>>> ....We've raised a ticket over at OPS4J and
>>> the issue is scheduled for a 0.5.2 release:..
>> Cool, thanks for the info!
>> -Bertrand
>>
>
>
>
Re: Sling breaks with pax-web 0.5.1
Posted by Mark Derricutt <ma...@talios.com>.
Hi Bertrand,
Looks like the paxweb ticket we raised (
http://issues.ops4j.org/jira/browse/PAXWEB-108) has been closed "wont-fix"
as its actually now doing the correct thing according to the Servlet 2.4
spec, section 11.2 reads:
"A string containing only the '/' character indicates the "default" servlet
of
the application. In this case the servlet path is the request URI minus the
context
path and the path info is null."
I've not yet tried it, but I'm wondering if the sling servlet gets mounted
as '/*' then we'd see the path info being restored. Shall I go raise this
as a Sling issue?
Mark
On Wed, Nov 12, 2008 at 10:14 AM, Bertrand Delacretaz <
bdelacretaz@apache.org> wrote:
> On Tue, Nov 11, 2008 at 9:34 PM, Mark Derricutt <ma...@talios.com> wrote:
> > ....We've raised a ticket over at OPS4J and
> > the issue is scheduled for a 0.5.2 release:..
>
> Cool, thanks for the info!
> -Bertrand
>
--
"It is easier to optimize correct code than to correct optimized code." --
Bill Harlan
Re: Sling breaks with pax-web 0.5.1
Posted by Mark Derricutt <ma...@talios.com>.
Hi Bertrand,
Thanks for the followup - we've since traced the problem down to being
paxweb 0.5.1 itself and not sling. We've raised a ticket over at OPS4J and
the issue is scheduled for a 0.5.2 release:
http://issues.ops4j.org/jira/browse/PAXWEB-108
Mark
On Wed, Nov 12, 2008 at 12:31 AM, Bertrand Delacretaz <
bdelacretaz@apache.org> wrote:
> Hi Mark,
>
> Going through my mail backlog I notice that we haven't replied to your
> question, is that still current?
>
> If yes it might be safer to create a JIRA issue so that doesn't fall
> into the cracks - apparently none of us had an answer off the top of
> their head.
>
> -Bertrand
>
> On Sun, Oct 19, 2008 at 11:55 PM, Mark Derricutt <ma...@talios.com> wrote:
> > Hi all,
> >
> > We recently updated our sling based application (based around the
> > sling-launchpad osgi deployer) to use pax-web-server 0.5.1 (which uses
> NIO)
> > and have noticed that for some reason none of sling content gets returned
> > anymore, instead we see:
> >
> > ** Node dumped by StreamRendererServlet**
> > Node path:/
> > Resource metadata: {sling.resolutionPath=/}
> >
> > ** Node properties **
> > jcr:primaryType: rep:root
> >
> >
> > being output to the browser. Is this a known issue or something new? Is
> > there anything I can look at to try and diagnose whats going on?
> >
> > Mark
> >
> > --
> > "It is easier to optimize correct code than to correct optimized code."
> --
> > Bill Harlan
> >
>
--
"It is easier to optimize correct code than to correct optimized code." --
Bill Harlan