date:20100106


[ 
https://issues.apache.org/jira/browse/SLING-966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12797030#action_12797030
 ] 

Felix Meschberger commented on SLING-966:
-

Deployed SNAPSHOT version 0.9.0-20100106.083211-1 of the Commons Auth bundle.

 Make internal sling authentication publicly available
 -

 Key: SLING-966
 URL: https://issues.apache.org/jira/browse/SLING-966
 Project: Sling
  Issue Type: Improvement
  Components: Commons
Reporter: Felix Meschberger
Assignee: Felix Meschberger
 Fix For: Commons Auth 1.0.0

 Attachments: SLING-966.patch, SLING-966b.patch, SLING-966c.patch


 Currently the SlingAuthenticator is an internal class in the Engine bundle, 
 which is used by the SlingMainServlet to handle the authentication as part of 
 an OSGi HTTP Service specification HttpContext object.
 To use the Sling authentication framework with the Authenticator and the 
 AuthenticationHandlers outside of the SlingMainServlet, that is for other 
 servlets directly registered with the OSGi HttpService the authentication 
 functionality should be made publicly available.
 One approach would be to provide a new authenticate() method in the 
 Authenticator interface. Another option would be to provide an abstract 
 HttpContext which already implements the HttpContext.handleSecurity method 
 using the SlingAuthenticator instance.

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

[jira] Commented: (SLING-966) Make internal sling authentication publicly available


[ 
https://issues.apache.org/jira/browse/SLING-966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12797033#action_12797033
 ] 

Felix Meschberger commented on SLING-966:
-

Removed old authentication code from the engine bundle in Rev. 896351 and 
deployed a Sling Engine SNAPSHOT 2.0.7-20100106.084348-54

 Make internal sling authentication publicly available
 -

 Key: SLING-966
 URL: https://issues.apache.org/jira/browse/SLING-966
 Project: Sling
  Issue Type: Improvement
  Components: Commons
Reporter: Felix Meschberger
Assignee: Felix Meschberger
 Fix For: Commons Auth 1.0.0

 Attachments: SLING-966.patch, SLING-966b.patch, SLING-966c.patch


 Currently the SlingAuthenticator is an internal class in the Engine bundle, 
 which is used by the SlingMainServlet to handle the authentication as part of 
 an OSGi HTTP Service specification HttpContext object.
 To use the Sling authentication framework with the Authenticator and the 
 AuthenticationHandlers outside of the SlingMainServlet, that is for other 
 servlets directly registered with the OSGi HttpService the authentication 
 functionality should be made publicly available.
 One approach would be to provide a new authenticate() method in the 
 Authenticator interface. Another option would be to provide an abstract 
 HttpContext which already implements the HttpContext.handleSecurity method 
 using the SlingAuthenticator instance.

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

Hudson build is back to normal: sling-contrib-1.5 #293

See http://hudson.zones.apache.org/hudson/job/sling-contrib-1.5/293/

Hudson build is still unstable: sling-trun k-1.6 » Apache Sling Launchpad Testing #224

See 
http://hudson.zones.apache.org/hudson/job/sling-trunk-1.6/org.apache.sling$org.apache.sling.launchpad.testing/224/

[jira] Updated: (SLING-1265) Adapt OpenID Authentication Handler to new AuthenticationHandler API


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

Felix Meschberger updated SLING-1265:
-

Fix Version/s: Extensions OpenID Authentication 1.0.0

 Adapt OpenID Authentication Handler to new AuthenticationHandler API
 

 Key: SLING-1265
 URL: https://issues.apache.org/jira/browse/SLING-1265
 Project: Sling
  Issue Type: Sub-task
  Components: Extensions
Affects Versions: Extensions OpenID Authentication 0.9.0
Reporter: Felix Meschberger
Assignee: Felix Meschberger
 Fix For: Extensions OpenID Authentication 1.0.0




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

[jira] Resolved: (SLING-1265) Adapt OpenID Authentication Handler to new AuthenticationHandler API


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

Felix Meschberger resolved SLING-1265.
--

Resolution: Fixed

Rev. 896366: Adapt to new AuthenticationHandler API and replace 
SimpleCredentials credentials with specific (private) OpenID credentials class 
directly conveying the OpenID user to the LoginModule. 

This handler now also directly supports logging out through the 
Authenticator.logout method.

 Adapt OpenID Authentication Handler to new AuthenticationHandler API
 

 Key: SLING-1265
 URL: https://issues.apache.org/jira/browse/SLING-1265
 Project: Sling
  Issue Type: Sub-task
  Components: Extensions
Affects Versions: Extensions OpenID Authentication 0.9.0
Reporter: Felix Meschberger
Assignee: Felix Meschberger



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

[jira] Created: (SLING-1270) Replace Session.logout from SlingMainServlet

Replace Session.logout from SlingMainServlet


 Key: SLING-1270
 URL: https://issues.apache.org/jira/browse/SLING-1270
 Project: Sling
  Issue Type: Task
  Components: Engine
Affects Versions: Engine 2.0.6
Reporter: Felix Meschberger
Assignee: Felix Meschberger
 Fix For: Engine 2.1.0


The new Commons Auth bundle from SLING-966 registers a ServletRequestListener 
to be informed when the request has terminated and the session may be logged 
out. Currently, the Http Service implementation does not support such listeners 
and the session may not be logged out at all.

As a workaround the Commons Auth bundle implements a Java VM finalize() method 
to try to ensure logging the session out.

As a further workaround the SlingMainServlet should - in a finally clause - 
logout the session of the request's resource resolver.

The SlingMainServlet configuration should be removed as soon as we can 
reasonably be sure of ServletRequestListener support.

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

[jira] Commented: (SLING-966) Make internal sling authentication publicly available


[ 
https://issues.apache.org/jira/browse/SLING-966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12797059#action_12797059
 ] 

Felix Meschberger commented on SLING-966:
-

Updated the bundle list in the Launchpad Builder module in Rev. 896376

 Make internal sling authentication publicly available
 -

 Key: SLING-966
 URL: https://issues.apache.org/jira/browse/SLING-966
 Project: Sling
  Issue Type: Improvement
  Components: Commons
Reporter: Felix Meschberger
Assignee: Felix Meschberger
 Fix For: Commons Auth 1.0.0

 Attachments: SLING-966.patch, SLING-966b.patch, SLING-966c.patch


 Currently the SlingAuthenticator is an internal class in the Engine bundle, 
 which is used by the SlingMainServlet to handle the authentication as part of 
 an OSGi HTTP Service specification HttpContext object.
 To use the Sling authentication framework with the Authenticator and the 
 AuthenticationHandlers outside of the SlingMainServlet, that is for other 
 servlets directly registered with the OSGi HttpService the authentication 
 functionality should be made publicly available.
 One approach would be to provide a new authenticate() method in the 
 Authenticator interface. Another option would be to provide an abstract 
 HttpContext which already implements the HttpContext.handleSecurity method 
 using the SlingAuthenticator instance.

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

Re: Creating an authentication support bundle

Hi all,

I have now committed the changes required for SLING-966 [1].

So, if you upgrade the Sling Engine to the latest trunk, you should also
install the new Commons Auth bundle.

Your existing AuthenticationHandler implementations will still be
working. I have upgraded our own HTTP Basic and OpenID Authentication
Handler implementations to make use of the new API from Commons Auth.

I now will turn to documentation and try to clarify what has been
written in [2].

Regards
Felix

[1] https://issues.apache.org/jira/browse/SLING-966
[2] http://sling.apache.org/site/authentication.html

On 02.01.2010 16:29, Felix Meschberger wrote:
 Hi,
 
 I have now implemented a prototype and attached the patch (againt Sling
 trunk) to SLING-966 [1].
 
 This patch relies on ServletRequestListener support (and a finalize()
 method) for Session clean up. We could also (readd) the Sessio.logout
 call in the Engine's SlingMainServlet for now... (though I would really
 prefer pure ServletRequestListener support).
 
 This patch does not yet require the ResourceResolver[Factory] stuff but
 of course would probably benefit from it as been pointed out on this thread.
 
 WDYT ?
 
 Regards
 Felix
 
 [1] https://issues.apache.org/jira/browse/SLING-966
 
 On 18.12.2009 08:20, Felix Meschberger wrote:
 Hi all,

 Currently Sling (the SlingMainServlet) is registered with the OSGi
 HttpService using an OSGi HttpContext whose handleSecurity method is
 implemented by means of the SlingAuthenticator class. This all is
 implemented in the Sling Engine bundle. See the code [1] and the
 documentation [2] for full details.

 This has a number of drawbacks:

   * Evolution of authentication provision and implementation
 is tied to the relatively unrelated Sling core implementation

   * The SlingAuthenticator class can only be used by servlets
 registered with Sling itself. Servlets registered directly
 with the OSGi HttpService have to implement the
 HttpContext.handleSecurity themselves, thus causing code
 duplication

   * The interaction between the SlingAuthenticator logging into
 the repository (Putting the session in a request attribute)
 and the SlingMainServlet using that session and logging it
 out after request termination is somewhat asynchronous.

 To remedy this situation, I propose to create a new bundle with the
 authentication stuff in the Engine bundle: The o.a.s.engine.auth and
 o.a.s.engine.impl.auth packages.

 This allows for re-use of the authentication mechanisms by other servlets.

 To enable authentication support a new Service interface is defined
 which allows to implement the handleSecurity method and which allows for
 proper cleanup at the end of the request.

 There are some options to consider, though, and an optimal solution
 escapes my mind right now...


 Option 1: Provide clean up API in the authentication service interface

 The service interface is defined as:

public interface AuthenticationSupport {
   public boolean handleSecurity(
  HttpServletRequest, HttpServletResponse);
   public void endRequest(HttpServletRequest);
}

 The handleSecurity method is meant to implement the
 HttpService.handleSecurity method. It is speced accordingly -- also
 requiring the request attributes to be set. Additionally, the method
 must set a ResourceResolver attribute (not a JCR session) for use by the
 client.

 The endRequest method must be called by the client when request
 processing has terminated. The intent is for the AuthenticationSupport
 service to cleanup -- namely logout an JCR session.

 The drawback of this option is, that it is assymmetric: HttpContext has
 to call handleSecurity, the registered Servlet has to call endRequest.

 Option 2: Implement ServletRequestListener

 The service interface is defined as:

public interface AuthenticationSupport {
   public boolean handleSecurity(
  HttpServletRequest, HttpServletResponse);
}

 The handleSecurity method is meant to implement the
 HttpService.handleSecurity method. It is speced accordingly -- also
 requiring the request attributes to be set. Additionally, the method
 must set a ResourceResolver attribute (not a JCR session) for use by the
 client.

 In addition the SlingAuthenticator registers itself as a
 ServletRequestListener handling the requestDestroyed method to cleanup
 any setups from the handleSecurity method, namely logging out JCR
 Session(s).

 The drawback of this option is, that it requires support to register a
 ServletRequestListener. This is something which is not supported by the
 HttpService spec and thus may only be supported by extended
 implementation (or any future HttpService or similar spec).


 WDYT ?

 Regards
 Felix


 [1] https://svn.apache.org/repos/asf/sling/trunk/bundles/engine
 [2] http://sling.apache.org/site/authentication.html

Re: [jira] Commented: (SLING-1270) Replace Session.logout from SlingMainServlet

2010-01-06 Thread Ian Boston

Felix, 
I agree that we should use the ServletRequestListener support, but I continue 
to wonder if there isnt a need for a request lifecycle to be exposed by the 
sling main servlet which would avoid having to a) create a stack of 
ServletFilters b) bind the SlingMainServlet to other apis' c) bind to the 
ServletRequestListener which is as you note not always supported ?

At present we have ServletFilters for a XA Transaction manager and Request 
Scope Caching, the stack is good in some senses since we can perform try 
finally but we rely heavily on the programmer knowing exactly what is safe to 
do.

Ian

On 6 Jan 2010, at 10:37, Felix Meschberger (JIRA) wrote:

 
[ 
 https://issues.apache.org/jira/browse/SLING-1270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12797052#action_12797052
  ] 
 
 Felix Meschberger commented on SLING-1270:
 --
 
 Committed temporary session logout in the SlingMainServlet in Rev. 896372.
 
 Replace Session.logout from SlingMainServlet
 
 
Key: SLING-1270
URL: https://issues.apache.org/jira/browse/SLING-1270
Project: Sling
 Issue Type: Task
 Components: Engine
   Affects Versions: Engine 2.0.6
   Reporter: Felix Meschberger
   Assignee: Felix Meschberger
Fix For: Engine 2.1.0
 
 
 The new Commons Auth bundle from SLING-966 registers a 
 ServletRequestListener to be informed when the request has terminated and 
 the session may be logged out. Currently, the Http Service implementation 
 does not support such listeners and the session may not be logged out at all.
 As a workaround the Commons Auth bundle implements a Java VM finalize() 
 method to try to ensure logging the session out.
 As a further workaround the SlingMainServlet should - in a finally clause - 
 logout the session of the request's resource resolver.
 The SlingMainServlet configuration should be removed as soon as we can 
 reasonably be sure of ServletRequestListener support.
 
 -- 
 This message is automatically generated by JIRA.
 -
 You can reply to this email to add a comment to the issue online.

Re: Creating an authentication support bundle

2010-01-06 Thread Ian Boston

Felix,
Were there recent releases of the bundles in question before this change was 
made. I am  1 week away from cutting a release and we have some major bits of 
work in the AuthN area, including container and CAS authn modules. I suspect 
that the porting effort is going to be minimal but the guys who did our CAS 
authn code have been moved off the project. 

Ian
On 6 Jan 2010, at 10:49, Felix Meschberger wrote:

 Hi all,
 
 I have now committed the changes required for SLING-966 [1].
 
 So, if you upgrade the Sling Engine to the latest trunk, you should also
 install the new Commons Auth bundle.
 
 Your existing AuthenticationHandler implementations will still be
 working. I have upgraded our own HTTP Basic and OpenID Authentication
 Handler implementations to make use of the new API from Commons Auth.
 
 I now will turn to documentation and try to clarify what has been
 written in [2].
 
 Regards
 Felix
 
 [1] https://issues.apache.org/jira/browse/SLING-966
 [2] http://sling.apache.org/site/authentication.html
 
 On 02.01.2010 16:29, Felix Meschberger wrote:
 Hi,
 
 I have now implemented a prototype and attached the patch (againt Sling
 trunk) to SLING-966 [1].
 
 This patch relies on ServletRequestListener support (and a finalize()
 method) for Session clean up. We could also (readd) the Sessio.logout
 call in the Engine's SlingMainServlet for now... (though I would really
 prefer pure ServletRequestListener support).
 
 This patch does not yet require the ResourceResolver[Factory] stuff but
 of course would probably benefit from it as been pointed out on this thread.
 
 WDYT ?
 
 Regards
 Felix
 
 [1] https://issues.apache.org/jira/browse/SLING-966
 
 On 18.12.2009 08:20, Felix Meschberger wrote:
 Hi all,
 
 Currently Sling (the SlingMainServlet) is registered with the OSGi
 HttpService using an OSGi HttpContext whose handleSecurity method is
 implemented by means of the SlingAuthenticator class. This all is
 implemented in the Sling Engine bundle. See the code [1] and the
 documentation [2] for full details.
 
 This has a number of drawbacks:
 
  * Evolution of authentication provision and implementation
is tied to the relatively unrelated Sling core implementation
 
  * The SlingAuthenticator class can only be used by servlets
registered with Sling itself. Servlets registered directly
with the OSGi HttpService have to implement the
HttpContext.handleSecurity themselves, thus causing code
duplication
 
  * The interaction between the SlingAuthenticator logging into
the repository (Putting the session in a request attribute)
and the SlingMainServlet using that session and logging it
out after request termination is somewhat asynchronous.
 
 To remedy this situation, I propose to create a new bundle with the
 authentication stuff in the Engine bundle: The o.a.s.engine.auth and
 o.a.s.engine.impl.auth packages.
 
 This allows for re-use of the authentication mechanisms by other servlets.
 
 To enable authentication support a new Service interface is defined
 which allows to implement the handleSecurity method and which allows for
 proper cleanup at the end of the request.
 
 There are some options to consider, though, and an optimal solution
 escapes my mind right now...
 
 
 Option 1: Provide clean up API in the authentication service interface
 
 The service interface is defined as:
 
   public interface AuthenticationSupport {
  public boolean handleSecurity(
 HttpServletRequest, HttpServletResponse);
  public void endRequest(HttpServletRequest);
   }
 
 The handleSecurity method is meant to implement the
 HttpService.handleSecurity method. It is speced accordingly -- also
 requiring the request attributes to be set. Additionally, the method
 must set a ResourceResolver attribute (not a JCR session) for use by the
 client.
 
 The endRequest method must be called by the client when request
 processing has terminated. The intent is for the AuthenticationSupport
 service to cleanup -- namely logout an JCR session.
 
 The drawback of this option is, that it is assymmetric: HttpContext has
 to call handleSecurity, the registered Servlet has to call endRequest.
 
 Option 2: Implement ServletRequestListener
 
 The service interface is defined as:
 
   public interface AuthenticationSupport {
  public boolean handleSecurity(
 HttpServletRequest, HttpServletResponse);
   }
 
 The handleSecurity method is meant to implement the
 HttpService.handleSecurity method. It is speced accordingly -- also
 requiring the request attributes to be set. Additionally, the method
 must set a ResourceResolver attribute (not a JCR session) for use by the
 client.
 
 In addition the SlingAuthenticator registers itself as a
 ServletRequestListener handling the requestDestroyed method to cleanup
 any setups from the handleSecurity method, namely logging out JCR
 Session(s).
 
 The drawback of this option is, that it requires support to register a

Hudson build became unstable: sling-trunk -1.5 » Apache Sling Launchpad Testing #460

See 
http://hudson.zones.apache.org/hudson/job/sling-trunk-1.5/org.apache.sling$org.apache.sling.launchpad.testing/460/

Hudson build became unstable: sling-trunk-1.5 #460

See http://hudson.zones.apache.org/hudson/job/sling-trunk-1.5/460/changes

Hudson build became unstable: sling-contrib-1. 5 » Apache Sling Launchpad Contrib Testing #294

See 
http://hudson.zones.apache.org/hudson/job/sling-contrib-1.5/org.apache.sling$org.apache.sling.launchpad.contrib-testing/294/

Hudson build became unstable: sling-contrib-1.5 #294

See http://hudson.zones.apache.org/hudson/job/sling-contrib-1.5/294/

Hudson build is still unstable: sling-trun k-1.6 » Apache Sling Launchpad Testing #225

See 
http://hudson.zones.apache.org/hudson/job/sling-trunk-1.6/org.apache.sling$org.apache.sling.launchpad.testing/225/

Hudson build is still unstable: sling-trun k-1.5 » Apache Sling Launchpad Testing #461

See 
http://hudson.zones.apache.org/hudson/job/sling-trunk-1.5/org.apache.sling$org.apache.sling.launchpad.testing/461/

Hudson build is still unstable: sling-trunk-1.5 #461

See http://hudson.zones.apache.org/hudson/job/sling-trunk-1.5/461/changes

Re: Creating an authentication support bundle

Hi Ian,

There was an Engine 2.0.6 release, which still contains the old
authentication API.

The combo Engine trunk plus Commons Auth trunk is basically an extended
situation of the Engine 2.0.6 release and all the 2.0.6 authentication
functionality still works.

Hope this helps.

Regards
Felix

On 06.01.2010 12:07, Ian Boston wrote:
 Felix,
 Were there recent releases of the bundles in question before this change was 
 made. I am  1 week away from cutting a release and we have some major bits 
 of work in the AuthN area, including container and CAS authn modules. I 
 suspect that the porting effort is going to be minimal but the guys who did 
 our CAS authn code have been moved off the project. 
 
 Ian
 On 6 Jan 2010, at 10:49, Felix Meschberger wrote:
 
 Hi all,

 I have now committed the changes required for SLING-966 [1].

 So, if you upgrade the Sling Engine to the latest trunk, you should also
 install the new Commons Auth bundle.

 Your existing AuthenticationHandler implementations will still be
 working. I have upgraded our own HTTP Basic and OpenID Authentication
 Handler implementations to make use of the new API from Commons Auth.

 I now will turn to documentation and try to clarify what has been
 written in [2].

 Regards
 Felix

 [1] https://issues.apache.org/jira/browse/SLING-966
 [2] http://sling.apache.org/site/authentication.html

 On 02.01.2010 16:29, Felix Meschberger wrote:
 Hi,

 I have now implemented a prototype and attached the patch (againt Sling
 trunk) to SLING-966 [1].

 This patch relies on ServletRequestListener support (and a finalize()
 method) for Session clean up. We could also (readd) the Sessio.logout
 call in the Engine's SlingMainServlet for now... (though I would really
 prefer pure ServletRequestListener support).

 This patch does not yet require the ResourceResolver[Factory] stuff but
 of course would probably benefit from it as been pointed out on this thread.

 WDYT ?

 Regards
 Felix

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

 On 18.12.2009 08:20, Felix Meschberger wrote:
 Hi all,

 Currently Sling (the SlingMainServlet) is registered with the OSGi
 HttpService using an OSGi HttpContext whose handleSecurity method is
 implemented by means of the SlingAuthenticator class. This all is
 implemented in the Sling Engine bundle. See the code [1] and the
 documentation [2] for full details.

 This has a number of drawbacks:

  * Evolution of authentication provision and implementation
is tied to the relatively unrelated Sling core implementation

  * The SlingAuthenticator class can only be used by servlets
registered with Sling itself. Servlets registered directly
with the OSGi HttpService have to implement the
HttpContext.handleSecurity themselves, thus causing code
duplication

  * The interaction between the SlingAuthenticator logging into
the repository (Putting the session in a request attribute)
and the SlingMainServlet using that session and logging it
out after request termination is somewhat asynchronous.

 To remedy this situation, I propose to create a new bundle with the
 authentication stuff in the Engine bundle: The o.a.s.engine.auth and
 o.a.s.engine.impl.auth packages.

 This allows for re-use of the authentication mechanisms by other servlets.

 To enable authentication support a new Service interface is defined
 which allows to implement the handleSecurity method and which allows for
 proper cleanup at the end of the request.

 There are some options to consider, though, and an optimal solution
 escapes my mind right now...


 Option 1: Provide clean up API in the authentication service interface

 The service interface is defined as:

   public interface AuthenticationSupport {
  public boolean handleSecurity(
 HttpServletRequest, HttpServletResponse);
  public void endRequest(HttpServletRequest);
   }

 The handleSecurity method is meant to implement the
 HttpService.handleSecurity method. It is speced accordingly -- also
 requiring the request attributes to be set. Additionally, the method
 must set a ResourceResolver attribute (not a JCR session) for use by the
 client.

 The endRequest method must be called by the client when request
 processing has terminated. The intent is for the AuthenticationSupport
 service to cleanup -- namely logout an JCR session.

 The drawback of this option is, that it is assymmetric: HttpContext has
 to call handleSecurity, the registered Servlet has to call endRequest.

 Option 2: Implement ServletRequestListener

 The service interface is defined as:

   public interface AuthenticationSupport {
  public boolean handleSecurity(
 HttpServletRequest, HttpServletResponse);
   }

 The handleSecurity method is meant to implement the
 HttpService.handleSecurity method. It is speced accordingly -- also
 requiring the request attributes to be set. Additionally, the method
 must set a ResourceResolver attribute (not a JCR session) for use by

Sling Request Lifecycle events (was: [jira] Commented: (SLING-1270) Replace Session.logout from SlingMainServlet)

Hi Ian,

On 06.01.2010 11:57, Ian Boston wrote:
 I agree that we should use the ServletRequestListener support, but I continue 
 to wonder if there isnt a need for a request lifecycle to be exposed by the 
 sling main servlet which would avoid having to a) create a stack of 
 ServletFilters b) bind the SlingMainServlet to other apis' c) bind to the 
 ServletRequestListener which is as you note not always supported ?

We might want to add request lifecycle events to the SlingMainServlet as
far as the service method is concerned. This would work perfectly fine
for requests handled through the SlingMainServlet (which is the majority
of the requests handled by a Sling instance).

Specifically the WebDAV requests to the /dav subtree would not benefit
from this (unless we add the same lifecycle support there ...)

Still: this would not help in the authentication case because
authentication is handled outside of the SlingMainServlet before the
service method is even called. In fact if authentication fails, the
SlingMainServlet.service method is not called at all.

 
 At present we have ServletFilters for a XA Transaction manager and Request 
 Scope Caching, the stack is good in some senses since we can perform try 
 finally but we rely heavily on the programmer knowing exactly what is safe to 
 do.

How about adding a SlingRequestListener interface, which mimicks the
ServletRequestListener interface:

   public interface SlingRequestListener {
void requestDestroyed(SlingRequestEvent sre);
void requestInitialized(SlingRequestEvent sre);
   }

   public class SlingRequestEvent {
SlingHttpServletRequest getSlingRequest();
   }

The methods would be called at the same time, the RequestLogger methods
are called (lines 252 and 363 in trunk SlingMainServlet).

WDYT ?

Regards
Felix

 
 Ian
 
 On 6 Jan 2010, at 10:37, Felix Meschberger (JIRA) wrote:
 

[ 
 https://issues.apache.org/jira/browse/SLING-1270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12797052#action_12797052
  ] 

 Felix Meschberger commented on SLING-1270:
 --

 Committed temporary session logout in the SlingMainServlet in Rev. 896372.

 Replace Session.logout from SlingMainServlet
 

Key: SLING-1270
URL: https://issues.apache.org/jira/browse/SLING-1270
Project: Sling
 Issue Type: Task
 Components: Engine
   Affects Versions: Engine 2.0.6
   Reporter: Felix Meschberger
   Assignee: Felix Meschberger
Fix For: Engine 2.1.0


 The new Commons Auth bundle from SLING-966 registers a 
 ServletRequestListener to be informed when the request has terminated and 
 the session may be logged out. Currently, the Http Service implementation 
 does not support such listeners and the session may not be logged out at 
 all.
 As a workaround the Commons Auth bundle implements a Java VM finalize() 
 method to try to ensure logging the session out.
 As a further workaround the SlingMainServlet should - in a finally clause - 
 logout the session of the request's resource resolver.
 The SlingMainServlet configuration should be removed as soon as we can 
 reasonably be sure of ServletRequestListener support.

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

mountByFS and Initial Content Loader

2010-01-06 Thread Vidar Ramdal

The maven-sling-plugin has the very useful feature mountByFS, which
automatically sets up FsResourceProviders for the initial-content in
the bundle.
This is great for development, as you can work directly on the files
in the bundle, without having to re-deploy the bundle for each change.

However, the mountByFS feature relies on the Sling-Initial-Content
header to decide which paths should be mapped. This crashes with the
Sling Content Loader bundle, which also looks for that header. So, if
the Content Loader bundle is active when you deploy a bundle with
mountByFS, you'll end up with both FsResourceProviders AND initial
content in the repository. This defies the purpose of mountByFS, and
usually also leads to some unexpected behavior in resource resolution.

So how about letting maven-sling-plugin support another config element
in addition to Sling-Initial-Content, say, Sling-Mount-File-Resources.
That way, the Content Loader bundle should not interfere when the
mountByFS bundle is deployed.

WDYT?

-- 
Vidar S. Ramdal vi...@idium.no - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00 / +47 21 531941, ext 2070

Re: Sling Request Lifecycle events (was: [jira] Commented: (SLING-1270) Replace Session.logout from SlingMainServlet)

2010-01-06 Thread Ian Boston


On 6 Jan 2010, at 13:01, Felix Meschberger wrote:

 Hi Ian,
 
 On 06.01.2010 11:57, Ian Boston wrote:
 I agree that we should use the ServletRequestListener support, but I 
 continue to wonder if there isnt a need for a request lifecycle to be 
 exposed by the sling main servlet which would avoid having to a) create a 
 stack of ServletFilters b) bind the SlingMainServlet to other apis' c) bind 
 to the ServletRequestListener which is as you note not always supported ?
 
 We might want to add request lifecycle events to the SlingMainServlet as
 far as the service method is concerned. This would work perfectly fine
 for requests handled through the SlingMainServlet (which is the majority
 of the requests handled by a Sling instance).
 
 Specifically the WebDAV requests to the /dav subtree would not benefit
 from this (unless we add the same lifecycle support there ...)
 
 Still: this would not help in the authentication case because
 authentication is handled outside of the SlingMainServlet before the
 service method is even called. In fact if authentication fails, the
 SlingMainServlet.service method is not called at all.


good point.

 
 
 At present we have ServletFilters for a XA Transaction manager and Request 
 Scope Caching, the stack is good in some senses since we can perform try 
 finally but we rely heavily on the programmer knowing exactly what is safe 
 to do.
 
 How about adding a SlingRequestListener interface, which mimicks the
 ServletRequestListener interface:
 
   public interface SlingRequestListener {
void requestDestroyed(SlingRequestEvent sre);
void requestInitialized(SlingRequestEvent sre);
   }
 
   public class SlingRequestEvent {
SlingHttpServletRequest getSlingRequest();
   }
 
 The methods would be called at the same time, the RequestLogger methods
 are called (lines 252 and 363 in trunk SlingMainServlet).
 
 WDYT ?


yes that makes perfect sense, the calls obviously wrapped in try catch to 
prevent anything doing bad things on destroy, ie the event is only for 
notification purposes and not for flow control etc

Ian

 
 Regards
 Felix
 
 
 Ian
 
 On 6 Jan 2010, at 10:37, Felix Meschberger (JIRA) wrote:
 
 
   [ 
 https://issues.apache.org/jira/browse/SLING-1270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12797052#action_12797052
  ] 
 
 Felix Meschberger commented on SLING-1270:
 --
 
 Committed temporary session logout in the SlingMainServlet in Rev. 896372.
 
 Replace Session.logout from SlingMainServlet
 
 
   Key: SLING-1270
   URL: https://issues.apache.org/jira/browse/SLING-1270
   Project: Sling
Issue Type: Task
Components: Engine
  Affects Versions: Engine 2.0.6
  Reporter: Felix Meschberger
  Assignee: Felix Meschberger
   Fix For: Engine 2.1.0
 
 
 The new Commons Auth bundle from SLING-966 registers a 
 ServletRequestListener to be informed when the request has terminated and 
 the session may be logged out. Currently, the Http Service implementation 
 does not support such listeners and the session may not be logged out at 
 all.
 As a workaround the Commons Auth bundle implements a Java VM finalize() 
 method to try to ensure logging the session out.
 As a further workaround the SlingMainServlet should - in a finally clause 
 - logout the session of the request's resource resolver.
 The SlingMainServlet configuration should be removed as soon as we can 
 reasonably be sure of ServletRequestListener support.
 
 -- 
 This message is automatically generated by JIRA.
 -
 You can reply to this email to add a comment to the issue online.

Re: mountByFS and Initial Content Loader

2010-01-06 Thread Carsten Ziegeler

Hi,

Vidar Ramdal wrote:
 The maven-sling-plugin has the very useful feature mountByFS, which
 automatically sets up FsResourceProviders for the initial-content in
 the bundle.
 This is great for development, as you can work directly on the files
 in the bundle, without having to re-deploy the bundle for each change.
 
 However, the mountByFS feature relies on the Sling-Initial-Content
 header to decide which paths should be mapped. This crashes with the
 Sling Content Loader bundle, which also looks for that header. So, if
 the Content Loader bundle is active when you deploy a bundle with
 mountByFS, you'll end up with both FsResourceProviders AND initial
 content in the repository. This defies the purpose of mountByFS, and
 usually also leads to some unexpected behavior in resource resolution.
actually the initial idea of this feature was to reduce turnaround times
during development. Instead of copying changed scripts into the
repository (either by deploying the bundle and then using initial
content) or by using a copy through webdav, the scripts get directly
mounted into the resource tree.

My usual development environment uses this feature together with initial
content headers and so far I never experienced a problem - it is true
that the content is also installed into the repository but the resources
mounted through the fs provider take precedence - at least they do it in
my case :)

 
 So how about letting maven-sling-plugin support another config element
 in addition to Sling-Initial-Content, say, Sling-Mount-File-Resources.
 That way, the Content Loader bundle should not interfere when the
 mountByFS bundle is deployed.
I'm not against adding an additonal configuration element for this
purpose. I started with the initial content header as this was already
available and used :)

Now, I think we should a) add the additional config element and b) see
which problems you have when the initial content header is used. Maybe
we can fix them as well.

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

Re: Creating an authentication support bundle

Hi,

On 06.01.2010 14:30, Ian Boston wrote:
 
 On 6 Jan 2010, at 12:51, Felix Meschberger wrote:
 
 Hi Ian,

 There was an Engine 2.0.6 release, which still contains the old
 authentication API.
 
 Ok cool, thanks we will give that a go.
 

 The combo Engine trunk plus Commons Auth trunk is basically an extended
 situation of the Engine 2.0.6 release and all the 2.0.6 authentication
 functionality still works.
 
 I am getting reports of existing authn not working after r896344 (we have a 
 bunch of Ruby tests that do integration tests over http, and they are all 
 failing with authn issues.)

Ok, this is definitely not something which is expected and wanted. So we
should definitely look into this. If you could provide Sling issues, I
could help.

 However we should probably investigate as all the Sling unit tests are 
 passing ok.

Well, there are a few integration tests failing, too. So I am also
investigating this area.

Regards
Felix


 Ian
 
 

 Hope this helps.

 Regards
 Felix

 On 06.01.2010 12:07, Ian Boston wrote:
 Felix,
 Were there recent releases of the bundles in question before this change 
 was made. I am  1 week away from cutting a release and we have some major 
 bits of work in the AuthN area, including container and CAS authn modules. 
 I suspect that the porting effort is going to be minimal but the guys who 
 did our CAS authn code have been moved off the project. 

 Ian
 On 6 Jan 2010, at 10:49, Felix Meschberger wrote:

 Hi all,

 I have now committed the changes required for SLING-966 [1].

 So, if you upgrade the Sling Engine to the latest trunk, you should also
 install the new Commons Auth bundle.

 Your existing AuthenticationHandler implementations will still be
 working. I have upgraded our own HTTP Basic and OpenID Authentication
 Handler implementations to make use of the new API from Commons Auth.

 I now will turn to documentation and try to clarify what has been
 written in [2].

 Regards
 Felix

 [1] https://issues.apache.org/jira/browse/SLING-966
 [2] http://sling.apache.org/site/authentication.html

 On 02.01.2010 16:29, Felix Meschberger wrote:
 Hi,

 I have now implemented a prototype and attached the patch (againt Sling
 trunk) to SLING-966 [1].

 This patch relies on ServletRequestListener support (and a finalize()
 method) for Session clean up. We could also (readd) the Sessio.logout
 call in the Engine's SlingMainServlet for now... (though I would really
 prefer pure ServletRequestListener support).

 This patch does not yet require the ResourceResolver[Factory] stuff but
 of course would probably benefit from it as been pointed out on this 
 thread.

 WDYT ?

 Regards
 Felix

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

 On 18.12.2009 08:20, Felix Meschberger wrote:
 Hi all,

 Currently Sling (the SlingMainServlet) is registered with the OSGi
 HttpService using an OSGi HttpContext whose handleSecurity method is
 implemented by means of the SlingAuthenticator class. This all is
 implemented in the Sling Engine bundle. See the code [1] and the
 documentation [2] for full details.

 This has a number of drawbacks:

 * Evolution of authentication provision and implementation
   is tied to the relatively unrelated Sling core implementation

 * The SlingAuthenticator class can only be used by servlets
   registered with Sling itself. Servlets registered directly
   with the OSGi HttpService have to implement the
   HttpContext.handleSecurity themselves, thus causing code
   duplication

 * The interaction between the SlingAuthenticator logging into
   the repository (Putting the session in a request attribute)
   and the SlingMainServlet using that session and logging it
   out after request termination is somewhat asynchronous.

 To remedy this situation, I propose to create a new bundle with the
 authentication stuff in the Engine bundle: The o.a.s.engine.auth and
 o.a.s.engine.impl.auth packages.

 This allows for re-use of the authentication mechanisms by other 
 servlets.

 To enable authentication support a new Service interface is defined
 which allows to implement the handleSecurity method and which allows for
 proper cleanup at the end of the request.

 There are some options to consider, though, and an optimal solution
 escapes my mind right now...


 Option 1: Provide clean up API in the authentication service interface

 The service interface is defined as:

  public interface AuthenticationSupport {
 public boolean handleSecurity(
HttpServletRequest, HttpServletResponse);
 public void endRequest(HttpServletRequest);
  }

 The handleSecurity method is meant to implement the
 HttpService.handleSecurity method. It is speced accordingly -- also
 requiring the request attributes to be set. Additionally, the method
 must set a ResourceResolver attribute (not a JCR session) for use by the
 client.

 The endRequest method must be called by the client when request
 processing has terminated. The intent is for the AuthenticationSupport

[jira] Created: (SLING-1271) Support mounting FsResourceProviders while avoiding loading content to JCR

2010-01-06 Thread Vidar S. Ramdal (JIRA)

Support mounting FsResourceProviders while avoiding loading content to JCR
--

 Key: SLING-1271
 URL: https://issues.apache.org/jira/browse/SLING-1271
 Project: Sling
  Issue Type: New Feature
  Components: Maven Plugins
Affects Versions: Maven Sling Plugin 2.0.4
Reporter: Vidar S. Ramdal
Assignee: Vidar S. Ramdal
Priority: Minor
 Fix For: Maven Sling Plugin 2.0.6


As described at [1], there mountByFS [2] flag allows you to have 
FsResourceProviders set up automatically on bundle deploy. However, the Content 
Loader bundle still picks up the content and installs it to JCR, even though 
the JCR paths are overridden by FsResourceProviders.

There are cases where you'd want to only configure FsResourceProviders, without 
having the content installed to JCR.

So, we'll introduce support for another pom.xml header, called 
Sling-Mount-File-Resources, which will let maven-sling-plugin setup the 
FsResourceProviders, avoiding the content loader.

maven-sling-plugin will then set up FsResourceProviders if:
1. A Sling-Mount-File-Resources element is present
-- OR --
2. A Sling-Initial-Content element is present, AND the mountByFS configuration 
parameter is true.

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

[jira] Updated: (SLING-1271) Support mounting FsResourceProviders while avoiding loading content to JCR

2010-01-06 Thread Vidar S. Ramdal (JIRA)

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

Vidar S. Ramdal updated SLING-1271:
---

Description:
As described at [1], the mountByFS [2] flag allows you to have
FsResourceProviders set up automatically on bundle deploy. However, the Content
Loader bundle still picks up the content and installs it to JCR, even though
the JCR paths are overridden by FsResourceProviders.

There are cases where you'd want to only configure FsResourceProviders, without
having the content installed to JCR.

So, we'll introduce support for another pom.xml header, called
Sling-Mount-File-Resources, which will let maven-sling-plugin setup the
FsResourceProviders, avoiding the content loader.

maven-sling-plugin will then set up FsResourceProviders if:
1. A Sling-Mount-File-Resources element is present
-- OR --
2. A Sling-Initial-Content element is present, AND the mountByFS configuration
parameter is true.

[1] http://markmail.org/thread/dyytf4zmbcnnbvvr
[2] http://www.osoco.org/blog/?p=69

was:
As described at [1], there mountByFS [2] flag allows you to have
FsResourceProviders set up automatically on bundle deploy. However, the Content
Loader bundle still picks up the content and installs it to JCR, even though
the JCR paths are overridden by FsResourceProviders.

There are cases where you'd want to only configure FsResourceProviders, without
having the content installed to JCR.

So, we'll introduce support for another pom.xml header, called
Sling-Mount-File-Resources, which will let maven-sling-plugin setup the
FsResourceProviders, avoiding the content loader.

Support mounting FsResourceProviders while avoiding loading content to JCR
--

Key: SLING-1271
URL: https://issues.apache.org/jira/browse/SLING-1271
Project: Sling
Issue Type: New Feature
Components: Maven Plugins
Affects Versions: Maven Sling Plugin 2.0.4
Reporter: Vidar S. Ramdal
Assignee: Vidar S. Ramdal
Priority: Minor
Fix For: Maven Sling Plugin 2.0.6

As described at [1], the mountByFS [2] flag allows you to have
FsResourceProviders set up automatically on bundle deploy. However, the
Content Loader bundle still picks up the content and installs it to JCR, even
though the JCR paths are overridden by FsResourceProviders.
There are cases where you'd want to only configure FsResourceProviders,
without having the content installed to JCR.
So, we'll introduce support for another pom.xml header, called
Sling-Mount-File-Resources, which will let maven-sling-plugin setup the
FsResourceProviders, avoiding the content loader.
maven-sling-plugin will then set up FsResourceProviders if:
1. A Sling-Mount-File-Resources element is present
-- OR --
2. A Sling-Initial-Content element is present, AND the mountByFS
configuration parameter is true.
[1] http://markmail.org/thread/dyytf4zmbcnnbvvr
[2] http://www.osoco.org/blog/?p=69

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

[jira] Created: (SLING-1272) Intermittent integration test failures

Intermittent integration test failures
--

 Key: SLING-1272
 URL: https://issues.apache.org/jira/browse/SLING-1272
 Project: Sling
  Issue Type: Bug
Reporter: Felix Meschberger
Assignee: Felix Meschberger


Since I have applied the SLING-966 patches this morning, the integration tests 
intermittently fail: Sometimes tests fail at seemingly random patterns. 
Sometimes all tests succeed.

Currently investigating, what may be the cause of these problems.

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

Re: mountByFS and Initial Content Loader

On Wed, Jan 6, 2010 at 8:53 AM, Vidar Ramdal vi...@idium.no wrote:

  Vidar Ramdal wrote:
  However, the mountByFS feature relies on the Sling-Initial-Content
  header to decide which paths should be mapped. This crashes with the
  Sling Content Loader bundle, which also looks for that header. So, if
  the Content Loader bundle is active when you deploy a bundle with
  mountByFS, you'll end up with both FsResourceProviders AND initial
  content in the repository. This defies the purpose of mountByFS, and
  usually also leads to some unexpected behavior in resource resolution.

Could you explain what unexpected behavior you're referring to? The
FsResourceProvider overrides content in the repository, which I think is the
expected behavior.

On Wed, Jan 6, 2010 at 2:29 PM, Carsten Ziegeler cziege...@apache.org
 wrote:
  [...]
  My usual development environment uses this feature together with initial
  content headers and so far I never experienced a problem - it is true
  that the content is also installed into the repository but the resources
  mounted through the fs provider take precedence - at least they do it in
  my case :)

Me too.


 That's useful information. I just took for granted that mountByFS and
 the content loader combination was not particularly common. I'll keep
 an eye open next time I deploy, to try to see exactly what fails.

  So how about letting maven-sling-plugin support another config element
  in addition to Sling-Initial-Content, say, Sling-Mount-File-Resources.
  That way, the Content Loader bundle should not interfere when the
  mountByFS bundle is deployed.


Sorry, but what's the point of this? If you just want to use
FsResourceProvider(s), do that, but then don't create a bundle because the
bundle isn't usable in that installing it into the OSGi container won't add
the content. So I think this addition would have a strong likelihood of
creating confusion. Imagine this scenario:

1) I start development on a content bundle. 2) I read the plugin docs and
see that I can add a Sling-Mount-File-Resources header for rapid
development (and, hey, who doesn't love rapid development) 3) I run mvn
sling:install (or have sling:install bound to the install phase) 4) Develop,
test, repeat, etc. 5) I'm ready to deploy my content bundle to production, I
use the Felix console to install the bundle. 6) My content doesn't show
up... FAIL

You could also replace #5 with I distribute my content bundle to a
co-worker and they install it into their local instance or I deploy my
bundle to an OBR repository and install it from there

 Now, I think we should a) add the additional config element and b) see
  which problems you have when the initial content header is used. Maybe
  we can fix them as well.

 Great. As I said, I'll gather some more details on b). Nonetheless, I
 too believe it would be useful to have a method of just installing
 FsResourceProviders without loading the content, if only to reduce the
 time it takes to deploy. So a) =
 https://issues.apache.org/jira/browse/SLING-1271

Is this performance issue real? AFAICT, Loading of content into the
repository is asynchronous (if not, that's a separate problem which should
be dealt with).

What may make sense is to create a Maven goal which doesn't require a
project or interact with the lifecycle to easily create new
FsResourceProviders. Something like:

$ mvn sling:add-fs-provider -Dsrc=. -Ddest=/libs/testcontent

(which would create a new FsResourceProvider mapping /libs/testcontent to
the current directory).

Justin

[jira] Created: (SLING-1274) Make Scala Scripting JSR 223 compliant

2010-01-06 Thread JIRA

Make Scala Scripting JSR 223 compliant
--

 Key: SLING-1274
 URL: https://issues.apache.org/jira/browse/SLING-1274
 Project: Sling
  Issue Type: Improvement
  Components: Scripting
Reporter: Michael Dürig
Priority: Minor


As discussed [1] it would be nice if we could decouple the Scala scripting 
engine from Sling making it into a independent JSR 223 compliant script engine 
which is 'just' used by Sling.

[1] http://markmail.org/message/mkvjbuk5dfrekvqv?q=scala+another+sling

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

Hudson build is still unstable: sling-trun k-1.5 » Apache Sling Launchpad Testing #462

See 
http://hudson.zones.apache.org/hudson/job/sling-trunk-1.5/org.apache.sling$org.apache.sling.launchpad.testing/462/

Hudson build is still unstable: sling-trunk-1.5 #462

See http://hudson.zones.apache.org/hudson/job/sling-trunk-1.5/462/changes

[jira] Resolved: (SLING-1268) Remove direct dependency to web console

2010-01-06 Thread Carsten Ziegeler (JIRA)


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

Carsten Ziegeler resolved SLING-1268.
-

   Resolution: Fixed
Fix Version/s: Scripting Core 2.0.10
 Assignee: Carsten Ziegeler

Fixed in revision: 896497

 Remove direct dependency to web console
 ---

 Key: SLING-1268
 URL: https://issues.apache.org/jira/browse/SLING-1268
 Project: Sling
  Issue Type: Improvement
  Components: Scripting
Affects Versions: Scripting Core 2.0.8
Reporter: Carsten Ziegeler
Assignee: Carsten Ziegeler
 Fix For: Scripting Core 2.0.10


 The new web console provides a way to define plugins without a direct 
 dependency to the web console.

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

Reduce dependencies of the scripting core

2010-01-06 Thread Carsten Ziegeler

Hi,

currently our scripting core depends on the jcr api. This is an old
relict to support the optional binding for currentNode. If the current
resource is adaptable to a jcr node, then this binding is set to this node.
This binding is not officially supported :)

We should definitly either remove the dependency to jcr or make it
optional. This allows to use the scripting in a non jcr environment.

I think we should remove this support completly - afaik the only
scripting language that is affected by this change is the javascript
implementation. We could simply add the binding in this scripting
language. JSPs are not affected as we have a taglib there anyway.

So if noone objects, I'll remove the support from the scripting core and
add it to the javascript implementation.

As an alternative we could make the dependency optional and leave this
non official stuff in the core.

WDYT?

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

[jira] Commented: (SLING-1272) Intermittent integration test failures


[ 
https://issues.apache.org/jira/browse/SLING-1272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12797306#action_12797306
 ] 

Felix Meschberger commented on SLING-1272:
--

It looks like the version dependency to the JCR Base bundle must be updated to 
a more recent version in the Jackrabbit Server bundle. Done in Rev. 896660

This solves the integration failure issues on my platform.

I suspect the problems to be related to the older default setting for session 
pooling which seems to break with Jackrabbit 1.6...

 Intermittent integration test failures
 --

 Key: SLING-1272
 URL: https://issues.apache.org/jira/browse/SLING-1272
 Project: Sling
  Issue Type: Bug
Reporter: Felix Meschberger
Assignee: Felix Meschberger

 Since I have applied the SLING-966 patches this morning, the integration 
 tests intermittently fail: Sometimes tests fail at seemingly random patterns. 
 Sometimes all tests succeed.
 Currently investigating, what may be the cause of these problems.

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

Re: Reduce dependencies of the scripting core

A few comments on this:
1) It seems like this would impact every scripting language *except* JSPs.
For example, I reference it on the page which describes the new
JSONGroovyBuilder (
http://cwiki.apache.org/confluence/display/SLING/Using+the+JSONGroovyBuilder
).

2) Removing without deprecation seems extreme, so at minimum,
http://cwiki.apache.org/SLING/scripting-variables.html (amongst others)
should be updated ASAP to explain that currentNode shouldn't be used.

3) I've been kicking around the idea that it would be nice for the scripting
binding to be expandable. Given a service interface like this:

public interface SlingScriptBindingValuesProvider {
 void addBindings(Bindings bindings);
}

DefaultSlingScript could then find all services and invoke them. A service
property could be used to limit the scope of a provider to one or more
scripting languages (for example, the JSONGroovyBuilder should only go into
the binding for Groovy scripts).

If this was done, then currentNode could be kept in the binding by creating
a SlingScriptBindingValuesProvider in one of the jcr bundles and the jcr
dependency could be removed from scripting core. Of course now there's a
dependency between a jcr bundle and scripting API, but perhaps that could be
optional (or, at least, acceptable).

This is somewhat half-baked and I haven't had enough time to figure out if
this is practical, but this did seem like a reasonable time to mention it.

Justin

On Wed, Jan 6, 2010 at 3:14 PM, Carsten Ziegeler cziege...@apache.orgwrote:

 Hi,

 currently our scripting core depends on the jcr api. This is an old
 relict to support the optional binding for currentNode. If the current
 resource is adaptable to a jcr node, then this binding is set to this node.
 This binding is not officially supported :)

 We should definitly either remove the dependency to jcr or make it
 optional. This allows to use the scripting in a non jcr environment.

 I think we should remove this support completly - afaik the only
 scripting language that is affected by this change is the javascript
 implementation. We could simply add the binding in this scripting
 language. JSPs are not affected as we have a taglib there anyway.

 So if noone objects, I'll remove the support from the scripting core and
 add it to the javascript implementation.

 As an alternative we could make the dependency optional and leave this
 non official stuff in the core.

 WDYT?

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

Re: Reduce dependencies of the scripting core

Hi,

On 06.01.2010 21:14, Carsten Ziegeler wrote:
 Hi,
 
 currently our scripting core depends on the jcr api. This is an old
 relict to support the optional binding for currentNode. If the current
 resource is adaptable to a jcr node, then this binding is set to this node.
 This binding is not officially supported :)

Well, actually this variable is documented in the Sling Wiki Scripting
Variables page [1]. And thus it looks like it is kind of officially
supported.

 
 We should definitly either remove the dependency to jcr or make it
 optional. This allows to use the scripting in a non jcr environment.
 
 I think we should remove this support completly - afaik the only
 scripting language that is affected by this change is the javascript
 implementation. We could simply add the binding in this scripting
 language. JSPs are not affected as we have a taglib there anyway.

Yes, for JSPs the currentNode variable is set by the
sling:defineObjects tag.

 So if noone objects, I'll remove the support from the scripting core and
 add it to the javascript implementation.
 
 As an alternative we could make the dependency optional and leave this
 non official stuff in the core.
 
 WDYT?

Upfront I would be for removing. But since the variable is documented
and therefore de-facto API, I think we should implement the workaround
with the optional dependency.

Regards
Felix

 
 Carsten

[1] http://cwiki.apache.org/SLING/scripting-variables.html

Re: Reduce dependencies of the scripting core

Hi,

On 06.01.2010 22:16, Justin Edelson wrote:
 A few comments on this:
 1) It seems like this would impact every scripting language *except* JSPs.
 For example, I reference it on the page which describes the new
 JSONGroovyBuilder (
 http://cwiki.apache.org/confluence/display/SLING/Using+the+JSONGroovyBuilder
 ).
 
 2) Removing without deprecation seems extreme, so at minimum,
 http://cwiki.apache.org/SLING/scripting-variables.html (amongst others)
 should be updated ASAP to explain that currentNode shouldn't be used.
 
 3) I've been kicking around the idea that it would be nice for the scripting
 binding to be expandable. Given a service interface like this:
 
 public interface SlingScriptBindingValuesProvider {
  void addBindings(Bindings bindings);
 }
 
 DefaultSlingScript could then find all services and invoke them. A service
 property could be used to limit the scope of a provider to one or more
 scripting languages (for example, the JSONGroovyBuilder should only go into
 the binding for Groovy scripts).
 
 If this was done, then currentNode could be kept in the binding by creating
 a SlingScriptBindingValuesProvider in one of the jcr bundles and the jcr
 dependency could be removed from scripting core. Of course now there's a
 dependency between a jcr bundle and scripting API, but perhaps that could be
 optional (or, at least, acceptable).

This sounds like an interesting approach, indeed !

Regards
Felix

 
 This is somewhat half-baked and I haven't had enough time to figure out if
 this is practical, but this did seem like a reasonable time to mention it.
 
 Justin
 
 On Wed, Jan 6, 2010 at 3:14 PM, Carsten Ziegeler cziege...@apache.orgwrote:
 
 Hi,

 currently our scripting core depends on the jcr api. This is an old
 relict to support the optional binding for currentNode. If the current
 resource is adaptable to a jcr node, then this binding is set to this node.
 This binding is not officially supported :)

 We should definitly either remove the dependency to jcr or make it
 optional. This allows to use the scripting in a non jcr environment.

 I think we should remove this support completly - afaik the only
 scripting language that is affected by this change is the javascript
 implementation. We could simply add the binding in this scripting
 language. JSPs are not affected as we have a taglib there anyway.

 So if noone objects, I'll remove the support from the scripting core and
 add it to the javascript implementation.

 As an alternative we could make the dependency optional and leave this
 non official stuff in the core.

 WDYT?

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

Hudson build is back to stable: sling-trun k-1.5 » Apache Sling Launchpad Testing #463

See 
http://hudson.zones.apache.org/hudson/job/sling-trunk-1.5/org.apache.sling$org.apache.sling.launchpad.testing/463/

Hudson build is back to stable: sling-trunk-1.5 #463

See http://hudson.zones.apache.org/hudson/job/sling-trunk-1.5/463/changes

Remove Session Pooling

Hi all,

Today I stumbled upon a potential problem with the JCR Session Pooling
we have in the JCR Base bundle.

Some time ago, we disabled session pooling by default. Only today I
actually set this default for the Embedded Jackrabbit bundle (see
SLING-1272).

The problems with session pooling are manyfold, some of the issues are:

  * Only works with SimpleCredentials authentication
  * Wrong level of abstraction: such optimizations are the task of the
   repository implementation and not of the user
  * Cleanup of the session for reuse is brittle and timeconsuming
   (due to a JCR search to ensure unlocking transient locks)
  * Little to no gain in performance (in fact performance is even
   lower than using plain Jackrabbit Sessions.

The only real use of the current session pooling, we might discuss, is
the optional limitation of concurrent requests per user. But even this
feature is disabled by default.

For these reasons, I think we should remove the Session Pooling support
from the JCR base bundle.

WDYT ?

Regards
Felix

Re: Remove Session Pooling


+1

Session pooling is part of Jackrabbit 2 (which is where it belongs)  
anyway. IIRC, you removed it in your JR 2 branch.


On Jan 6, 2010, at 5:11 PM, Felix Meschberger fmesc...@gmail.com  
wrote:



Hi all,

Today I stumbled upon a potential problem with the JCR Session Pooling
we have in the JCR Base bundle.

Some time ago, we disabled session pooling by default. Only today I
actually set this default for the Embedded Jackrabbit bundle (see
SLING-1272).

The problems with session pooling are manyfold, some of the issues  
are:


 * Only works with SimpleCredentials authentication
 * Wrong level of abstraction: such optimizations are the task of the
  repository implementation and not of the user
 * Cleanup of the session for reuse is brittle and timeconsuming
  (due to a JCR search to ensure unlocking transient locks)
 * Little to no gain in performance (in fact performance is even
  lower than using plain Jackrabbit Sessions.

The only real use of the current session pooling, we might discuss, is
the optional limitation of concurrent requests per user. But even this
feature is disabled by default.

For these reasons, I think we should remove the Session Pooling  
support

from the JCR base bundle.

WDYT ?

Regards
Felix

Re: Remove Session Pooling

Hi,

On 06.01.2010 23:20, Justin Edelson wrote:
 +1
 
 Session pooling is part of Jackrabbit 2 (which is where it belongs)
 anyway. IIRC, you removed it in your JR 2 branch.

I actually removed it in that branch exactly for the reasons outlined
below ;-)

Regards
Felix

 
 On Jan 6, 2010, at 5:11 PM, Felix Meschberger fmesc...@gmail.com wrote:
 
 Hi all,

 Today I stumbled upon a potential problem with the JCR Session Pooling
 we have in the JCR Base bundle.

 Some time ago, we disabled session pooling by default. Only today I
 actually set this default for the Embedded Jackrabbit bundle (see
 SLING-1272).

 The problems with session pooling are manyfold, some of the issues are:

  * Only works with SimpleCredentials authentication
  * Wrong level of abstraction: such optimizations are the task of the
   repository implementation and not of the user
  * Cleanup of the session for reuse is brittle and timeconsuming
   (due to a JCR search to ensure unlocking transient locks)
  * Little to no gain in performance (in fact performance is even
   lower than using plain Jackrabbit Sessions.

 The only real use of the current session pooling, we might discuss, is
 the optional limitation of concurrent requests per user. But even this
 feature is disabled by default.

 For these reasons, I think we should remove the Session Pooling support
 from the JCR base bundle.

 WDYT ?

 Regards
 Felix

Hudson build is still unstable: sling-trun k-1.6 » Apache Sling Launchpad Testing #226

See 
http://hudson.zones.apache.org/hudson/job/sling-trunk-1.6/org.apache.sling$org.apache.sling.launchpad.testing/226/

Hudson build is still unstable: sling-trunk-1.6 #226

See http://hudson.zones.apache.org/hudson/job/sling-trunk-1.6/226/changes

Hudson build is back to stable: sling-trun k-1.6 » Apache Sling Launchpad Testing #227

See 
http://hudson.zones.apache.org/hudson/job/sling-trunk-1.6/org.apache.sling$org.apache.sling.launchpad.testing/227/

Hudson build is back to stable: sling-trunk-1.6 #227

See http://hudson.zones.apache.org/hudson/job/sling-trunk-1.6/227/

Re: Remove Session Pooling




On Jan 6, 2010, at 5:26 PM, Felix Meschberger fmesc...@gmail.com  
wrote:



Hi,

On 06.01.2010 23:20, Justin Edelson wrote:

+1

Session pooling is part of Jackrabbit 2 (which is where it belongs)
anyway. IIRC, you removed it in your JR 2 branch.


I actually removed it in that branch exactly for the reasons outlined
below ;-)


And I now realize that it was db connection pooling which was added  
in  JR 2.


Justin


Regards
Felix



On Jan 6, 2010, at 5:11 PM, Felix Meschberger fmesc...@gmail.com  
wrote:



Hi all,

Today I stumbled upon a potential problem with the JCR Session  
Pooling

we have in the JCR Base bundle.

Some time ago, we disabled session pooling by default. Only today I
actually set this default for the Embedded Jackrabbit bundle (see
SLING-1272).

The problems with session pooling are manyfold, some of the issues  
are:


* Only works with SimpleCredentials authentication
* Wrong level of abstraction: such optimizations are the task of the
 repository implementation and not of the user
* Cleanup of the session for reuse is brittle and timeconsuming
 (due to a JCR search to ensure unlocking transient locks)
* Little to no gain in performance (in fact performance is even
 lower than using plain Jackrabbit Sessions.

The only real use of the current session pooling, we might  
discuss, is
the optional limitation of concurrent requests per user. But even  
this

feature is disabled by default.

For these reasons, I think we should remove the Session Pooling  
support

from the JCR base bundle.

WDYT ?

Regards
Felix

Re: Reduce dependencies of the scripting core