[jira] [Commented] (SLING-2726) allow simple wildcards in servlet paths

2013-02-13 Thread Carsten Ziegeler (JIRA) 

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

Carsten Ziegeler commented on SLING-2726:
-

I'm not against doing such a simple resource provider, however I'm not sure if 
it really helps in this use case.

I'm not in favour of allowing wild cards in registration as this is 
contradicting the idea of the resource tree a little bit and I'm definitly 
against mixing data (= resources) with their rendering (servlets/scripts).

As I noted above, if the resource approach does not work for a use case, there 
is still the possibility to register a servlet using the http service (not the 
Sling engine) and implement the logic here. As this is an OSGi service it can 
access the resource resolver and get resources from the tree. This is very 
simple and straightforward.

> allow simple wildcards in servlet paths
> ---
>
> Key: SLING-2726
> URL: https://issues.apache.org/jira/browse/SLING-2726
> Project: Sling
>  Issue Type: Improvement
>  Components: Servlets
>Reporter: Nicolas Peltier
>Priority: Minor
>
> While i'm a big fan/evangelist of sling unique servlet management. I tend to 
> think this would be nice to allow minimum wildcard for servlet paths, i.e. 
> /a/b/* (no suffix), as some use cases can't be cover right now with jcr based 
> resources + path servlets.
> Basically every resource model where you don't need a jcr node for (while 
> it's very convenient most of the time).
> I'm thinking for example of having a profile servlet with a nice public 
> /profile/jdoe.html url. Right now my possibilities are 
> * to create a flat tree of fake user nodes under a profile node just for the 
> sake of my urls (don't need righs handling, don't need other verbs for the 
> same resource), 
> * to have tons of vanityUrls (not meant for that kind of usage)
> * to create my own ResourceProvider that map that kind of URLs to existing 
> jcr resources.
> * to switch to /profile.jdoe.html, or /profile.html?uid=jdoe
> And i tend to think a tiny wildcard in a path parameter would be nicer :-)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Integration Test for error handling fails

2013-02-13 Thread Carsten Ziegeler 
Hi,

it seems that our new test for the error handler fails:

https://builds.apache.org/job/sling-trunk-1.6/org.apache.sling$org.apache.sling.launchpad.testing/1578/testReport/org.apache.sling.launchpad.webapp.integrationtest.servlets.resolver.errorhandler/ErrorHandlingTest/test_500_errorhandling/

I see this one on my machine as well, however as soon as I start to
hunt it down, the test passes :(

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

Re: Integration Test for error handling fails

2013-02-13 Thread Antonio Sanso 
Hi Carsten,

I have seen it as well failing on and off in Jenkins.
Only for the webapp case though (weird).
I will try to investigate.

Regards

Antonio

On Feb 13, 2013, at 9:49 AM, Carsten Ziegeler wrote:

> Hi,
> 
> it seems that our new test for the error handler fails:
> 
> https://builds.apache.org/job/sling-trunk-1.6/org.apache.sling$org.apache.sling.launchpad.testing/1578/testReport/org.apache.sling.launchpad.webapp.integrationtest.servlets.resolver.errorhandler/ErrorHandlingTest/test_500_errorhandling/
> 
> I see this one on my machine as well, however as soon as I start to
> hunt it down, the test passes :(
> 
> Carsten
> -- 
> Carsten Ziegeler
> cziege...@apache.org

[jira] [Resolved] (SLING-2720) Update exported versions for extension fragments to match well-known JAX-WS, JAXB, StAX and JAF versions

2013-02-13 Thread Carsten Ziegeler (JIRA) 

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

Carsten Ziegeler resolved SLING-2720.
-

   Resolution: Fixed
Fix Version/s: Framework Extension Fragment WS 1.0.2
   Framework Extension Fragment XML 1.0.2
   Framework Extension Fragment Activation 1.0.2

Thanks for your patch, lgtm - applied

> Update exported versions for extension fragments to match well-known JAX-WS, 
> JAXB, StAX and JAF versions
> 
>
> Key: SLING-2720
> URL: https://issues.apache.org/jira/browse/SLING-2720
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: Framework Extension Fragment WS 1.0.0, Framework 
> Extension Fragment XML 1.0.0, Framework Extension Fragment Activation 1.0.0
>Reporter: Robert Munteanu
>Assignee: Carsten Ziegeler
> Fix For: Framework Extension Fragment Activation 1.0.2, Framework 
> Extension Fragment XML 1.0.2, Framework Extension Fragment WS 1.0.2
>
> Attachments: SLING-2720-1.patch, SLING-2720.patch
>
>
> The framework extension packages currently export their packages versioned as 
> 0.0.0_fragment_qualifier. However, some third-party OSGi bundles, notably CXF 
> [1] require specific versions. One example is Jax-WS 2.1.0 or newer.
> To fix this, I propose that we export the packages with well-known package 
> versions for versions which are easily identifiable. The versions are 
> proposed based on specific documentation outlining the inclusion of these 
> frameworks in Java 6 [2], [3] . Also, based on a bug report[4] I have 
> inferred that the StAX version available in Java 6 ( FCS, later updates have 
> newer packages ) is 1.0.0.
> - JAX-WS 2.1, packages
> javax.xml.ws
> javax.xml.ws.handler
> javax.xml.ws.handler.soap
> javax.xml.ws.http
> javax.xml.ws.soap
> javax.xml.ws.spi
> javax.xml.ws.spi.http
> javax.xml.ws.wsaddressing
> - JAXB 2.1 packages
> javax.xml.bind
> javax.xml.bind.annotation
> javax.xml.bind.annotation.adapters
> javax.xml.bind.attachment
> javax.xml.bind.helpers
> javax.xml.bind.util
> javax.xml.datatype
> - STAX 1.0 packages
> javax.xml.stream
> javax.xml.stream.events
> javax.xml.stream.util
> - JAF packages
> javax.activation
> [1]: http://cxf.apache.org/dosgi-releases.html
> [2]: http://jax-ws.java.net/2.2.7/docs/ch02.html#installation-instructions
> [3]: http://www.oracle.com/technetwork/java/javase/downloads/index-135046.html
> [4]: http://bugs.sun.com/view_bug.do?bug_id=6861589

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Assigned] (SLING-2720) Update exported versions for extension fragments to match well-known JAX-WS, JAXB, StAX and JAF versions

2013-02-13 Thread Carsten Ziegeler (JIRA) 

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

Carsten Ziegeler reassigned SLING-2720:
---

Assignee: Carsten Ziegeler

> Update exported versions for extension fragments to match well-known JAX-WS, 
> JAXB, StAX and JAF versions
> 
>
> Key: SLING-2720
> URL: https://issues.apache.org/jira/browse/SLING-2720
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: Framework Extension Fragment WS 1.0.0, Framework 
> Extension Fragment XML 1.0.0, Framework Extension Fragment Activation 1.0.0
>Reporter: Robert Munteanu
>Assignee: Carsten Ziegeler
> Attachments: SLING-2720-1.patch, SLING-2720.patch
>
>
> The framework extension packages currently export their packages versioned as 
> 0.0.0_fragment_qualifier. However, some third-party OSGi bundles, notably CXF 
> [1] require specific versions. One example is Jax-WS 2.1.0 or newer.
> To fix this, I propose that we export the packages with well-known package 
> versions for versions which are easily identifiable. The versions are 
> proposed based on specific documentation outlining the inclusion of these 
> frameworks in Java 6 [2], [3] . Also, based on a bug report[4] I have 
> inferred that the StAX version available in Java 6 ( FCS, later updates have 
> newer packages ) is 1.0.0.
> - JAX-WS 2.1, packages
> javax.xml.ws
> javax.xml.ws.handler
> javax.xml.ws.handler.soap
> javax.xml.ws.http
> javax.xml.ws.soap
> javax.xml.ws.spi
> javax.xml.ws.spi.http
> javax.xml.ws.wsaddressing
> - JAXB 2.1 packages
> javax.xml.bind
> javax.xml.bind.annotation
> javax.xml.bind.annotation.adapters
> javax.xml.bind.attachment
> javax.xml.bind.helpers
> javax.xml.bind.util
> javax.xml.datatype
> - STAX 1.0 packages
> javax.xml.stream
> javax.xml.stream.events
> javax.xml.stream.util
> - JAF packages
> javax.activation
> [1]: http://cxf.apache.org/dosgi-releases.html
> [2]: http://jax-ws.java.net/2.2.7/docs/ch02.html#installation-instructions
> [3]: http://www.oracle.com/technetwork/java/javase/downloads/index-135046.html
> [4]: http://bugs.sun.com/view_bug.do?bug_id=6861589

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[VOTE] Release Parent 15, Extension Fragments 1.0.2

2013-02-13 Thread Carsten Ziegeler 
Hi,

This vote is about the release of

Parent 15
https://issues.apache.org/jira/browse/SLING-2728

And three of our extension fragments: activation, xml, ws - all in
version 1.0.2:
https://issues.apache.org/jira/browse/SLING-2720

Staging repository:
https://repository.apache.org/content/repositories/orgapachesling-229/


You can use this UNIX script to download the release and verify the signatures:
http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh

Usage:
sh check_staged_release.sh 229 /tmp/sling-staging


Please vote to approve this release:

 [ ] +1 Approve the release
 [ ]  0 Don't care
 [ ] -1 Don't release, because ...

This vote will be open for 72 hours.

Regards

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

[jira] [Commented] (SLING-2707) Support of chunked file upload into Sling

2013-02-13 Thread Shashank Gupta (JIRA) 

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

Shashank Gupta commented on SLING-2707:
---

Incorporated all suggestions and updated wiki at 
https://cwiki.apache.org/confluence/display/SLING/Chunked+File+Upload+Support. 
Please review and provide your comments. 
once we finalized the protocol,  I will spec out the design and implementation. 

thanks.

> Support of chunked file upload into Sling
> -
>
> Key: SLING-2707
> URL: https://issues.apache.org/jira/browse/SLING-2707
> Project: Sling
>  Issue Type: New Feature
>  Components: General
>Reporter: Shashank Gupta
> Attachments: uploadclient.jar
>
>
> Use cases: 
> 1. Large file upload - With high speed internet connections, advent of cloud 
> and HD going mainstream, Sling should support large files (> 2GB) upload.
> 2. Fault tolerant uploads - Sling should provide capability to resume upload 
> from failure point. It should not require client to restart the complete 
> upload process. 
> 3. Faster upload: Sling should support its clients to initiate multiple 
> connection and upload file chunks in parallel. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (SLING-2731) Bundle is sometimes not downgraded

2013-02-13 Thread Carsten Ziegeler (JIRA) 
Carsten Ziegeler created SLING-2731:
---

 Summary: Bundle is sometimes not downgraded
 Key: SLING-2731
 URL: https://issues.apache.org/jira/browse/SLING-2731
 Project: Sling
  Issue Type: Bug
  Components: Installer
Affects Versions: Installer Core 3.4.4
Reporter: Carsten Ziegeler
Assignee: Carsten Ziegeler
 Fix For: Installer Core 3.4.6


If a bundle downgrade is detected, the bundle is sometimes not updated to the 
lower version, however the lower version is marked as installed.
The installer uses an attr to mark a bundle resource to be started in the next 
phase (BundleUtil.ATTR_START). It seems that in previous versions of the 
installer, this attribute has not been cleared correctly. Therefore during a 
downgrade, the code first checks for this attr before it checks for the 
downgrade version. If the attribute is still present, the bundle is just 
started and marked as installed.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Jenkins build is still unstable: sling-trunk-1.6 » Apache Sling Launchpad Testing #1579

2013-02-13 Thread Apache Jenkins Server 
See

[jira] [Commented] (SLING-2707) Support of chunked file upload into Sling

2013-02-13 Thread Julian Reschke (JIRA) 

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

Julian Reschke commented on SLING-2707:
---

You can't simply replace POST by PATCH. They have different semantics. You'll 
also need custom media types describing the PATCH format.

> Support of chunked file upload into Sling
> -
>
> Key: SLING-2707
> URL: https://issues.apache.org/jira/browse/SLING-2707
> Project: Sling
>  Issue Type: New Feature
>  Components: General
>Reporter: Shashank Gupta
> Attachments: uploadclient.jar
>
>
> Use cases: 
> 1. Large file upload - With high speed internet connections, advent of cloud 
> and HD going mainstream, Sling should support large files (> 2GB) upload.
> 2. Fault tolerant uploads - Sling should provide capability to resume upload 
> from failure point. It should not require client to restart the complete 
> upload process. 
> 3. Faster upload: Sling should support its clients to initiate multiple 
> connection and upload file chunks in parallel. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (SLING-2731) Bundle is sometimes not downgraded

2013-02-13 Thread Carsten Ziegeler (JIRA) 

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

Carsten Ziegeler resolved SLING-2731.
-

Resolution: Fixed

The attr is now cleared when a downgrade is detected. This should solve the 
problem

> Bundle is sometimes not downgraded
> --
>
> Key: SLING-2731
> URL: https://issues.apache.org/jira/browse/SLING-2731
> Project: Sling
>  Issue Type: Bug
>  Components: Installer
>Affects Versions: Installer Core 3.4.4
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Installer Core 3.4.6
>
>
> If a bundle downgrade is detected, the bundle is sometimes not updated to the 
> lower version, however the lower version is marked as installed.
> The installer uses an attr to mark a bundle resource to be started in the 
> next phase (BundleUtil.ATTR_START). It seems that in previous versions of the 
> installer, this attribute has not been cleared correctly. Therefore during a 
> downgrade, the code first checks for this attr before it checks for the 
> downgrade version. If the attribute is still present, the bundle is just 
> started and marked as installed.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (SLING-2716) JCR Installer does not handle move events

2013-02-13 Thread Carsten Ziegeler (JIRA) 

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

Carsten Ziegeler resolved SLING-2716.
-

Resolution: Fixed
  Assignee: Carsten Ziegeler

I've added an additional observation listener just listening to move events and 
then invalidating potential watchers for source and dest

> JCR Installer does not handle move events
> -
>
> Key: SLING-2716
> URL: https://issues.apache.org/jira/browse/SLING-2716
> Project: Sling
>  Issue Type: Bug
>  Components: Installer
>Affects Versions: JCR Installer 3.1.4
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: JCR Installer 3.1.6
>
>
> The jcr observation listener does not handle move events, therefore moving 
> artifacts in the repository get the installer in a corrupt state

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Jenkins build is still unstable: sling-trunk-1.6 #1579

2013-02-13 Thread Apache Jenkins Server 
See

[jira] [Commented] (SLING-2726) allow simple wildcards in servlet paths

2013-02-13 Thread Nicolas Peltier (JIRA) 

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

Nicolas Peltier commented on SLING-2726:


What i like with jcr based one vs. http service is i have ACLs management for 
free. I can still connect to the repo in my service and test my rights against 
a JCR node.
@Alex, interesting approach, will look into that.

ok, looks like this bug can be closed. May be another one for easily creating 
ResourceProvider should be done?

> allow simple wildcards in servlet paths
> ---
>
> Key: SLING-2726
> URL: https://issues.apache.org/jira/browse/SLING-2726
> Project: Sling
>  Issue Type: Improvement
>  Components: Servlets
>Reporter: Nicolas Peltier
>Priority: Minor
>
> While i'm a big fan/evangelist of sling unique servlet management. I tend to 
> think this would be nice to allow minimum wildcard for servlet paths, i.e. 
> /a/b/* (no suffix), as some use cases can't be cover right now with jcr based 
> resources + path servlets.
> Basically every resource model where you don't need a jcr node for (while 
> it's very convenient most of the time).
> I'm thinking for example of having a profile servlet with a nice public 
> /profile/jdoe.html url. Right now my possibilities are 
> * to create a flat tree of fake user nodes under a profile node just for the 
> sake of my urls (don't need righs handling, don't need other verbs for the 
> same resource), 
> * to have tons of vanityUrls (not meant for that kind of usage)
> * to create my own ResourceProvider that map that kind of URLs to existing 
> jcr resources.
> * to switch to /profile.jdoe.html, or /profile.html?uid=jdoe
> And i tend to think a tiny wildcard in a path parameter would be nicer :-)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (SLING-2726) allow simple wildcards in servlet paths

2013-02-13 Thread Nicolas Peltier (JIRA) 

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

Nicolas Peltier resolved SLING-2726.


Resolution: Won't Fix

see above

> allow simple wildcards in servlet paths
> ---
>
> Key: SLING-2726
> URL: https://issues.apache.org/jira/browse/SLING-2726
> Project: Sling
>  Issue Type: Improvement
>  Components: Servlets
>Reporter: Nicolas Peltier
>Priority: Minor
>
> While i'm a big fan/evangelist of sling unique servlet management. I tend to 
> think this would be nice to allow minimum wildcard for servlet paths, i.e. 
> /a/b/* (no suffix), as some use cases can't be cover right now with jcr based 
> resources + path servlets.
> Basically every resource model where you don't need a jcr node for (while 
> it's very convenient most of the time).
> I'm thinking for example of having a profile servlet with a nice public 
> /profile/jdoe.html url. Right now my possibilities are 
> * to create a flat tree of fake user nodes under a profile node just for the 
> sake of my urls (don't need righs handling, don't need other verbs for the 
> same resource), 
> * to have tons of vanityUrls (not meant for that kind of usage)
> * to create my own ResourceProvider that map that kind of URLs to existing 
> jcr resources.
> * to switch to /profile.jdoe.html, or /profile.html?uid=jdoe
> And i tend to think a tiny wildcard in a path parameter would be nicer :-)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (SLING-2726) allow simple wildcards in servlet paths

2013-02-13 Thread Carsten Ziegeler (JIRA) 

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

Carsten Ziegeler commented on SLING-2726:
-

Just for completeness :) if you write a servlet and register it with the http 
service, you can get the resource resolver and get nodes from the repository, 
so ACLs can be used 

> allow simple wildcards in servlet paths
> ---
>
> Key: SLING-2726
> URL: https://issues.apache.org/jira/browse/SLING-2726
> Project: Sling
>  Issue Type: Improvement
>  Components: Servlets
>Reporter: Nicolas Peltier
>Priority: Minor
>
> While i'm a big fan/evangelist of sling unique servlet management. I tend to 
> think this would be nice to allow minimum wildcard for servlet paths, i.e. 
> /a/b/* (no suffix), as some use cases can't be cover right now with jcr based 
> resources + path servlets.
> Basically every resource model where you don't need a jcr node for (while 
> it's very convenient most of the time).
> I'm thinking for example of having a profile servlet with a nice public 
> /profile/jdoe.html url. Right now my possibilities are 
> * to create a flat tree of fake user nodes under a profile node just for the 
> sake of my urls (don't need righs handling, don't need other verbs for the 
> same resource), 
> * to have tons of vanityUrls (not meant for that kind of usage)
> * to create my own ResourceProvider that map that kind of URLs to existing 
> jcr resources.
> * to switch to /profile.jdoe.html, or /profile.html?uid=jdoe
> And i tend to think a tiny wildcard in a path parameter would be nicer :-)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[VOTE] Installer Core 3.4.6, JCR Installer 3.1.6, and Installer Factory Configuration 1.0.10

2013-02-13 Thread Carsten Ziegeler 
Hi,

This vote is about the release of

Installer Core 3.4.6
https://issues.apache.org/jira/browse/SLING-2731

Installer JCR Provider 3.1.6
https://issues.apache.org/jira/browse/SLING/fixforversion/12321290

Installer Factory Configuration 3.0.10
https://issues.apache.org/jira/browse/SLING-2578


Staging repository:
https://repository.apache.org/content/repositories/orgapachesling-230/


You can use this UNIX script to download the release and verify the signatures:
http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh

Usage:
sh check_staged_release.sh 230 /tmp/sling-staging


Please vote to approve this release:

 [ ] +1 Approve the release
 [ ]  0 Don't care
 [ ] -1 Don't release, because ...

This vote will be open for 72 hours.

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

Re: [VOTE] Release Parent 15, Extension Fragments 1.0.2

2013-02-13 Thread Carsten Ziegeler 
+1

Carsten

2013/2/13 Carsten Ziegeler :
> Hi,
>
> This vote is about the release of
>
> Parent 15
> https://issues.apache.org/jira/browse/SLING-2728
>
> And three of our extension fragments: activation, xml, ws - all in
> version 1.0.2:
> https://issues.apache.org/jira/browse/SLING-2720
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-229/
>
>
> You can use this UNIX script to download the release and verify the 
> signatures:
> http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh
>
> Usage:
> sh check_staged_release.sh 229 /tmp/sling-staging
>
>
> Please vote to approve this release:
>
>  [ ] +1 Approve the release
>  [ ]  0 Don't care
>  [ ] -1 Don't release, because ...
>
> This vote will be open for 72 hours.
>
> Regards
>
> Carsten
> --
> Carsten Ziegeler
> cziege...@apache.org



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

Re: [VOTE] Installer Core 3.4.6, JCR Installer 3.1.6, and Installer Factory Configuration 1.0.10

2013-02-13 Thread Carsten Ziegeler 
+1

Carsten

2013/2/13 Carsten Ziegeler :
> Hi,
>
> This vote is about the release of
>
> Installer Core 3.4.6
> https://issues.apache.org/jira/browse/SLING-2731
>
> Installer JCR Provider 3.1.6
> https://issues.apache.org/jira/browse/SLING/fixforversion/12321290
>
> Installer Factory Configuration 3.0.10
> https://issues.apache.org/jira/browse/SLING-2578
>
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-230/
>
>
> You can use this UNIX script to download the release and verify the 
> signatures:
> http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh
>
> Usage:
> sh check_staged_release.sh 230 /tmp/sling-staging
>
>
> Please vote to approve this release:
>
>  [ ] +1 Approve the release
>  [ ]  0 Don't care
>  [ ] -1 Don't release, because ...
>
> This vote will be open for 72 hours.
>
> Regards
> Carsten
> --
> Carsten Ziegeler
> cziege...@apache.org



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

Jenkins build is still unstable: sling-trunk-1.6 » Apache Sling Launchpad Testing #1580

2013-02-13 Thread Apache Jenkins Server 
See

Jenkins build is still unstable: sling-trunk-1.6 » Apache Sling Launchpad Testing WAR version #1580

2013-02-13 Thread Apache Jenkins Server 
See

Jenkins build is back to stable : sling-trunk-1.6 » Apache Sling Launchpad Base #1580

2013-02-13 Thread Apache Jenkins Server 
See

Jenkins build is still unstable: sling-trunk-1.6 #1580

2013-02-13 Thread Apache Jenkins Server 
See

Re: [VOTE] Release Parent 15, Extension Fragments 1.0.2

2013-02-13 Thread Felix Meschberger 
+1

Regards
Felix

Am 13.02.2013 um 11:25 schrieb Carsten Ziegeler:

> Hi,
> 
> This vote is about the release of
> 
> Parent 15
> https://issues.apache.org/jira/browse/SLING-2728
> 
> And three of our extension fragments: activation, xml, ws - all in
> version 1.0.2:
> https://issues.apache.org/jira/browse/SLING-2720
> 
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-229/
> 
> 
> You can use this UNIX script to download the release and verify the 
> signatures:
> http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh
> 
> Usage:
> sh check_staged_release.sh 229 /tmp/sling-staging
> 
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ]  0 Don't care
> [ ] -1 Don't release, because ...
> 
> This vote will be open for 72 hours.
> 
> Regards
> 
> Carsten
> -- 
> Carsten Ziegeler
> cziege...@apache.org


--
Felix Meschberger | Principal Scientist | Adobe

Re: [VOTE] Installer Core 3.4.6, JCR Installer 3.1.6, and Installer Factory Configuration 1.0.10

2013-02-13 Thread Felix Meschberger 
+1

Regards
Felix

Am 13.02.2013 um 15:05 schrieb Carsten Ziegeler:

> Hi,
> 
> This vote is about the release of
> 
> Installer Core 3.4.6
> https://issues.apache.org/jira/browse/SLING-2731
> 
> Installer JCR Provider 3.1.6
> https://issues.apache.org/jira/browse/SLING/fixforversion/12321290
> 
> Installer Factory Configuration 3.0.10
> https://issues.apache.org/jira/browse/SLING-2578
> 
> 
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-230/
> 
> 
> You can use this UNIX script to download the release and verify the 
> signatures:
> http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh
> 
> Usage:
> sh check_staged_release.sh 230 /tmp/sling-staging
> 
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ]  0 Don't care
> [ ] -1 Don't release, because ...
> 
> This vote will be open for 72 hours.
> 
> Regards
> Carsten
> -- 
> Carsten Ziegeler
> cziege...@apache.org


--
Felix Meschberger | Principal Scientist | Adobe

Re: [VOTE] Installer Core 3.4.6, JCR Installer 3.1.6, and Installer Factory Configuration 1.0.10

2013-02-13 Thread Ian Boston 
+1
Ian

On 14 February 2013 07:50, Felix Meschberger  wrote:
> +1
>
> Regards
> Felix
>
> Am 13.02.2013 um 15:05 schrieb Carsten Ziegeler:
>
>> Hi,
>>
>> This vote is about the release of
>>
>> Installer Core 3.4.6
>> https://issues.apache.org/jira/browse/SLING-2731
>>
>> Installer JCR Provider 3.1.6
>> https://issues.apache.org/jira/browse/SLING/fixforversion/12321290
>>
>> Installer Factory Configuration 3.0.10
>> https://issues.apache.org/jira/browse/SLING-2578
>>
>>
>> Staging repository:
>> https://repository.apache.org/content/repositories/orgapachesling-230/
>>
>>
>> You can use this UNIX script to download the release and verify the 
>> signatures:
>> http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh
>>
>> Usage:
>> sh check_staged_release.sh 230 /tmp/sling-staging
>>
>>
>> Please vote to approve this release:
>>
>> [ ] +1 Approve the release
>> [ ]  0 Don't care
>> [ ] -1 Don't release, because ...
>>
>> This vote will be open for 72 hours.
>>
>> Regards
>> Carsten
>> --
>> Carsten Ziegeler
>> cziege...@apache.org
>
>
> --
> Felix Meschberger | Principal Scientist | Adobe
>
>
>
>
>
>
>

Re: [VOTE] Release Parent 15, Extension Fragments 1.0.2

2013-02-13 Thread Ian Boston 
+1
Ian


On 14 February 2013 07:50, Felix Meschberger  wrote:
> +1
>
> Regards
> Felix
>
> Am 13.02.2013 um 11:25 schrieb Carsten Ziegeler:
>
>> Hi,
>>
>> This vote is about the release of
>>
>> Parent 15
>> https://issues.apache.org/jira/browse/SLING-2728
>>
>> And three of our extension fragments: activation, xml, ws - all in
>> version 1.0.2:
>> https://issues.apache.org/jira/browse/SLING-2720
>>
>> Staging repository:
>> https://repository.apache.org/content/repositories/orgapachesling-229/
>>
>>
>> You can use this UNIX script to download the release and verify the 
>> signatures:
>> http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh
>>
>> Usage:
>> sh check_staged_release.sh 229 /tmp/sling-staging
>>
>>
>> Please vote to approve this release:
>>
>> [ ] +1 Approve the release
>> [ ]  0 Don't care
>> [ ] -1 Don't release, because ...
>>
>> This vote will be open for 72 hours.
>>
>> Regards
>>
>> Carsten
>> --
>> Carsten Ziegeler
>> cziege...@apache.org
>
>
> --
> Felix Meschberger | Principal Scientist | Adobe
>
>
>
>
>
>
>

[jira] [Commented] (SLING-2726) allow simple wildcards in servlet paths

2013-02-13 Thread Felix Meschberger (JIRA) 

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

Felix Meschberger commented on SLING-2726:
--

I am inclined to accept this request. The change is really minimal and we just 
have to improve on the ServletResourceProvider.getResource method: This 
currently checks for path equality. With "wildcard" or "prefix" support we 
would check for prefix equality.

We could implement this requiring an additional service property to be set such 
that existing servlets are still handled with equality test only, while new 
implementations may request the new behaviour.

> allow simple wildcards in servlet paths
> ---
>
> Key: SLING-2726
> URL: https://issues.apache.org/jira/browse/SLING-2726
> Project: Sling
>  Issue Type: Improvement
>  Components: Servlets
>Reporter: Nicolas Peltier
>Priority: Minor
>
> While i'm a big fan/evangelist of sling unique servlet management. I tend to 
> think this would be nice to allow minimum wildcard for servlet paths, i.e. 
> /a/b/* (no suffix), as some use cases can't be cover right now with jcr based 
> resources + path servlets.
> Basically every resource model where you don't need a jcr node for (while 
> it's very convenient most of the time).
> I'm thinking for example of having a profile servlet with a nice public 
> /profile/jdoe.html url. Right now my possibilities are 
> * to create a flat tree of fake user nodes under a profile node just for the 
> sake of my urls (don't need righs handling, don't need other verbs for the 
> same resource), 
> * to have tons of vanityUrls (not meant for that kind of usage)
> * to create my own ResourceProvider that map that kind of URLs to existing 
> jcr resources.
> * to switch to /profile.jdoe.html, or /profile.html?uid=jdoe
> And i tend to think a tiny wildcard in a path parameter would be nicer :-)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (SLING-2726) allow simple wildcards in servlet paths

2013-02-13 Thread Carsten Ziegeler (JIRA) 

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

Carsten Ziegeler commented on SLING-2726:
-

I still think we should not do this :) we mix data and rendering into a single 
piece: the servlet - which is contradictionary to what Sling is about.

> allow simple wildcards in servlet paths
> ---
>
> Key: SLING-2726
> URL: https://issues.apache.org/jira/browse/SLING-2726
> Project: Sling
>  Issue Type: Improvement
>  Components: Servlets
>Reporter: Nicolas Peltier
>Priority: Minor
>
> While i'm a big fan/evangelist of sling unique servlet management. I tend to 
> think this would be nice to allow minimum wildcard for servlet paths, i.e. 
> /a/b/* (no suffix), as some use cases can't be cover right now with jcr based 
> resources + path servlets.
> Basically every resource model where you don't need a jcr node for (while 
> it's very convenient most of the time).
> I'm thinking for example of having a profile servlet with a nice public 
> /profile/jdoe.html url. Right now my possibilities are 
> * to create a flat tree of fake user nodes under a profile node just for the 
> sake of my urls (don't need righs handling, don't need other verbs for the 
> same resource), 
> * to have tons of vanityUrls (not meant for that kind of usage)
> * to create my own ResourceProvider that map that kind of URLs to existing 
> jcr resources.
> * to switch to /profile.jdoe.html, or /profile.html?uid=jdoe
> And i tend to think a tiny wildcard in a path parameter would be nicer :-)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira