[jira] [Commented] (SLING-3829) Add support for Content-Disposition attachment

2015-01-13 Thread Antonio Sanso (JIRA)

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

Antonio Sanso commented on SLING-3829:
--

[~olli] it looks like an option indeed thanks.
Question: which bundle do you use for 

{code}
  org.tuckey
   urlrewritefilter
{code}
?

> Add support for Content-Disposition attachment 
> ---
>
> Key: SLING-3829
> URL: https://issues.apache.org/jira/browse/SLING-3829
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Antonio Sanso
>Assignee: Antonio Sanso
>Priority: Minor
>
> In some situation will be useful (and safer) to force Content-Disposition 
> attachment for some Content-Type (configurable ) under some specific (and 
> sensitive) path (configurable)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Resolved] (SLING-4288) JSONObject.toString() returns null when having a value of type map with a null value

2015-01-13 Thread Carsten Ziegeler (JIRA)

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

Carsten Ziegeler resolved SLING-4288.
-
Resolution: Fixed

Fixed in rev 1651577 and updated test case to reflect the problem

> JSONObject.toString() returns null when having a value of type map with a 
> null value
> 
>
> Key: SLING-4288
> URL: https://issues.apache.org/jira/browse/SLING-4288
> Project: Sling
>  Issue Type: Bug
>  Components: Commons
>Affects Versions: Commons JSON 2.0.8
>Reporter: Pulkit Agarwal
>Assignee: Carsten Ziegeler
>  Labels: JSON
> Fix For: Commons JSON 2.0.10
>
>
> I am having a test case where I have to place a map in a JSONObject. Below is 
> the sample code for the same.
> @Test
>   public void testSample() throws JSONException
>   {
> HashMap map=new HashMap();
> map.put("abc", "123456");
> map.put("id", null);
> List list=new ArrayList();
> list.add("Admin");
> list.add("password");
> map.put("groups", list);
> JSONObject response=new JSONObject();
> response.put("key", map);
> System.out.println(response.get("key"));
>   }
> Now when I execute the code keeping org.apache.sling.commons.json version 
> 2.0.8 in the classpath then response.get("key")returns null where as in case 
> of bundle version 2.0.6 its returns map. 
> Please note this issue is reproducible when the map is an element of type 
> list.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (SLING-4288) JSONObject.toString() returns null when having a value of type map with a null value

2015-01-13 Thread Carsten Ziegeler (JIRA)

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

Carsten Ziegeler commented on SLING-4288:
-

After a discussion with [~pulkagar] we found the problem: If there is a key 
with null value in map along with any other valid key-value pairs, and if we 
assign this map to a key in JSONObject, the toString method returns null.
This has been introduced by the refactoring of SLING-3786

> JSONObject.toString() returns null when having a value of type map with a 
> null value
> 
>
> Key: SLING-4288
> URL: https://issues.apache.org/jira/browse/SLING-4288
> Project: Sling
>  Issue Type: Bug
>  Components: Commons
>Affects Versions: Commons JSON 2.0.8
>Reporter: Pulkit Agarwal
>Assignee: Carsten Ziegeler
>  Labels: JSON
> Fix For: Commons JSON 2.0.10
>
>
> I am having a test case where I have to place a map in a JSONObject. Below is 
> the sample code for the same.
> @Test
>   public void testSample() throws JSONException
>   {
> HashMap map=new HashMap();
> map.put("abc", "123456");
> map.put("id", null);
> List list=new ArrayList();
> list.add("Admin");
> list.add("password");
> map.put("groups", list);
> JSONObject response=new JSONObject();
> response.put("key", map);
> System.out.println(response.get("key"));
>   }
> Now when I execute the code keeping org.apache.sling.commons.json version 
> 2.0.8 in the classpath then response.get("key")returns null where as in case 
> of bundle version 2.0.6 its returns map. 
> Please note this issue is reproducible when the map is an element of type 
> list.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (SLING-4288) JSON object returns null when JSON object is having a value of type map and the map is having a list as one of its element

2015-01-13 Thread Carsten Ziegeler (JIRA)

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

Carsten Ziegeler updated SLING-4288:

Summary: JSON object returns null when JSON object is having a value of 
type map and the map is having a list as one of its element  (was: JSON object 
provided by org.apache.sling.commons.json 2.0.8 version returns null when JSON 
object is having a value of type map and the map is having a list as one of its 
element)

> JSON object returns null when JSON object is having a value of type map and 
> the map is having a list as one of its element
> --
>
> Key: SLING-4288
> URL: https://issues.apache.org/jira/browse/SLING-4288
> Project: Sling
>  Issue Type: Bug
>  Components: Commons
>Affects Versions: Commons JSON 2.0.8
>Reporter: Pulkit Agarwal
>Assignee: Carsten Ziegeler
>  Labels: JSON
> Fix For: Commons JSON 2.0.10
>
>
> I am having a test case where I have to place a map in a JSONObject. Below is 
> the sample code for the same.
> @Test
>   public void testSample() throws JSONException
>   {
> HashMap map=new HashMap();
> map.put("abc", "123456");
> map.put("id", null);
> List list=new ArrayList();
> list.add("Admin");
> list.add("password");
> map.put("groups", list);
> JSONObject response=new JSONObject();
> response.put("key", map);
> System.out.println(response.get("key"));
>   }
> Now when I execute the code keeping org.apache.sling.commons.json version 
> 2.0.8 in the classpath then response.get("key")returns null where as in case 
> of bundle version 2.0.6 its returns map. 
> Please note this issue is reproducible when the map is an element of type 
> list.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (SLING-4288) JSONObject.toString() returns null when having a value of type map with a null value

2015-01-13 Thread Carsten Ziegeler (JIRA)

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

Carsten Ziegeler updated SLING-4288:

Summary: JSONObject.toString() returns null when having a value of type map 
with a null value  (was: JSON object returns null when JSON object is having a 
value of type map and the map is having a list as one of its element)

> JSONObject.toString() returns null when having a value of type map with a 
> null value
> 
>
> Key: SLING-4288
> URL: https://issues.apache.org/jira/browse/SLING-4288
> Project: Sling
>  Issue Type: Bug
>  Components: Commons
>Affects Versions: Commons JSON 2.0.8
>Reporter: Pulkit Agarwal
>Assignee: Carsten Ziegeler
>  Labels: JSON
> Fix For: Commons JSON 2.0.10
>
>
> I am having a test case where I have to place a map in a JSONObject. Below is 
> the sample code for the same.
> @Test
>   public void testSample() throws JSONException
>   {
> HashMap map=new HashMap();
> map.put("abc", "123456");
> map.put("id", null);
> List list=new ArrayList();
> list.add("Admin");
> list.add("password");
> map.put("groups", list);
> JSONObject response=new JSONObject();
> response.put("key", map);
> System.out.println(response.get("key"));
>   }
> Now when I execute the code keeping org.apache.sling.commons.json version 
> 2.0.8 in the classpath then response.get("key")returns null where as in case 
> of bundle version 2.0.6 its returns map. 
> Please note this issue is reproducible when the map is an element of type 
> list.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Assigned] (SLING-4288) JSON object provided by org.apache.sling.commons.json 2.0.8 version returns null when JSON object is having a value of type map and the map is having a list as one of it

2015-01-13 Thread Carsten Ziegeler (JIRA)

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

Carsten Ziegeler reassigned SLING-4288:
---

Assignee: Carsten Ziegeler

> JSON object provided by org.apache.sling.commons.json 2.0.8 version returns 
> null when JSON object is having a value of type map and the map is having a 
> list as one of its element
> --
>
> Key: SLING-4288
> URL: https://issues.apache.org/jira/browse/SLING-4288
> Project: Sling
>  Issue Type: Bug
>  Components: Commons
>Affects Versions: Commons JSON 2.0.8
>Reporter: Pulkit Agarwal
>Assignee: Carsten Ziegeler
>  Labels: JSON
> Fix For: Commons JSON 2.0.10
>
>
> I am having a test case where I have to place a map in a JSONObject. Below is 
> the sample code for the same.
> @Test
>   public void testSample() throws JSONException
>   {
> HashMap map=new HashMap();
> map.put("abc", "123456");
> map.put("id", null);
> List list=new ArrayList();
> list.add("Admin");
> list.add("password");
> map.put("groups", list);
> JSONObject response=new JSONObject();
> response.put("key", map);
> System.out.println(response.get("key"));
>   }
> Now when I execute the code keeping org.apache.sling.commons.json version 
> 2.0.8 in the classpath then response.get("key")returns null where as in case 
> of bundle version 2.0.6 its returns map. 
> Please note this issue is reproducible when the map is an element of type 
> list.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


Re: Servlet Filter Support adding sling.filter.pattern support

2015-01-13 Thread Antonio Sanso
hi Alex

On Jan 14, 2015, at 4:14 AM, Alexander Klimetschek  wrote:

> The use case is SLING-3829 - does this necessarily require the change? It 
> could be a normal servlet filter that checks the paths itself, right?

true, this can be done and it is was many other filter have been doing. That is 
why would be good to handle this boilerplate out of the box (IMHO). At the end 
of the day this is already possible for Apache Felix filters.

> 
> From the use case description in http://markmail.org/message/czrlmikxe2fj6sx4 
> you refer to uploaded files... I could imagine the configurable evolves to 
> something other than just path patterns, where you'd have to check these in 
> the filter anyway.

a resource type based filter has been also proposed and could also be added 
(and it makes also sense if you ask me :))/

> 
> And why does it require a servlet filter and is not a feature of the default 
> Sling GET servlet? To catch all servlets who provide a "download"? But what 
> if you have a custom servlet where you know you want a certain mime type and 
> not the force-download one?

that is the point indeed. Under certain locations (e.g. where a user can upload 
his own content) you do not want to serve this content as is, hence the 
Content-Disposition attachment header.
This must be true in all the cases being it a default Sling GET servlet or a 
custom servlet.
A better solution would be to support  sandbox domain for user generated 
content (e.g. http://foo.usercontent.com), since we do not have yet this 
feature (just yet..) the mitigation we can use here is the  Content-Disposition 
attachment header mentioned in SLING-3829

regards

antonio
> 
> Cheers,
> Alex
> 
> 
>> On 13.01.2015, at 02:12, Antonio Sanso  wrote:
>> 
>> hi *,
>> 
>> I have tracked the issue and added a straw man patch in 
>> https://issues.apache.org/jira/browse/SLING-4294
>> 
>> WDYT?
>> 
>> regards
>> 
>> antonio
>> 
>> On Dec 5, 2014, at 12:00 PM, Felix Meschberger  wrote:
>> 
>>> Hi
>>> 
>>> The point is that we should implement what we need and ignore what we don’t 
>>> need.
>>> 
>>> For some use cases it would indeed be good to be simply able to filter on 
>>> the URL path (or resource path) like in the Servlet API itself. Consider 
>>> for example a content management system where you want to apply a filter to 
>>> all requests to user generated content which might live at /content/public.
>>> 
>>> For other cases, being able to filter on a resource type is more 
>>> appropriate. Again, consider a content management system and you want to 
>>> apply the filter to all requests for web page resources of resource type 
>>> cms/webpage.
>>> 
>>> Then there is a combination even, where you might have resources spread all 
>>> over but you want to apply the filter only to, say, web pages in user 
>>> generated content, so you filter on the /content/public location further 
>>> finer graining it to cms/webpage.
>>> 
>>> These could be use cases. Do we need it ? I don’t know. For SLING-3829 it 
>>> would be use full to have it.
>>> 
>>> Regards
>>> Felix
>>> 
 Am 05.12.2014 um 11:07 schrieb Antonio Sanso :
 
 hi Julian
 
 On Dec 5, 2014, at 10:31 AM, Julian Sedding  wrote:
 
> Hi Antonio
> 
> I agree with Justin that we should start with support for resource-types.
 
 as said I agree we should have support for both.
 E.g. sling.filter.pattern, sling.filter.resourceType
 
 
> 
> Using path-based restrictions strongly couples configuration to
> content, which IMO is not a good practice.
 
 At the end of the day is the developer choice to choose the one she needs.
 In my case for example I cannot use the resource type approach.
 See also https://issues.apache.org/jira/browse/SLING-3829
 
 regards
 
 antonio
 
> 
> Regards
> Julian
> 
> 
> On Thu, Dec 4, 2014 at 3:54 PM, Antonio Sanso  wrote:
>> thanks Justin for your feedback,
>> 
>> if you would not mind I would try to do the opposite :)
>> The only reason is that I have already a Pocs for this that it actually 
>> requires really few modifications.. (Felix gave me some good hints on 
>> how to implement it :))
>> It would probably be the same for resource type though :)
>> 
>> regards
>> 
>> antonio
>> 
>> On Dec 4, 2014, at 2:29 PM, Justin Edelson  
>> wrote:
>> 
>>> Hi Antonio,
>>> I'd suggest starting with support for resource type and *then* add path 
>>> support.
>>> 
>>> Justin
>>> 
>>> On Thu, Dec 4, 2014 at 5:46 AM, Antonio Sanso  wrote:
 hi *,
 
 the current Sling Servlet Filter Support [0] allows to have scope 
 dependent filter (e.g. REQUEST, INCLUDE, FORWARD, ERROR, COMPONENT).
 It would be nice to extend this support to have a specific filter 
 being taken in consideration only for specific path (adding 

Re: Servlet Filter Support adding sling.filter.pattern support

2015-01-13 Thread Alexander Klimetschek
The use case is SLING-3829 - does this necessarily require the change? It could 
be a normal servlet filter that checks the paths itself, right?

>From the use case description in http://markmail.org/message/czrlmikxe2fj6sx4 
>you refer to uploaded files... I could imagine the configurable evolves to 
>something other than just path patterns, where you'd have to check these in 
>the filter anyway.

And why does it require a servlet filter and is not a feature of the default 
Sling GET servlet? To catch all servlets who provide a "download"? But what if 
you have a custom servlet where you know you want a certain mime type and not 
the force-download one?

Cheers,
Alex


> On 13.01.2015, at 02:12, Antonio Sanso  wrote:
> 
> hi *,
> 
> I have tracked the issue and added a straw man patch in 
> https://issues.apache.org/jira/browse/SLING-4294
> 
> WDYT?
> 
> regards
> 
> antonio
> 
> On Dec 5, 2014, at 12:00 PM, Felix Meschberger  wrote:
> 
>> Hi
>> 
>> The point is that we should implement what we need and ignore what we don’t 
>> need.
>> 
>> For some use cases it would indeed be good to be simply able to filter on 
>> the URL path (or resource path) like in the Servlet API itself. Consider for 
>> example a content management system where you want to apply a filter to all 
>> requests to user generated content which might live at /content/public.
>> 
>> For other cases, being able to filter on a resource type is more 
>> appropriate. Again, consider a content management system and you want to 
>> apply the filter to all requests for web page resources of resource type 
>> cms/webpage.
>> 
>> Then there is a combination even, where you might have resources spread all 
>> over but you want to apply the filter only to, say, web pages in user 
>> generated content, so you filter on the /content/public location further 
>> finer graining it to cms/webpage.
>> 
>> These could be use cases. Do we need it ? I don’t know. For SLING-3829 it 
>> would be use full to have it.
>> 
>> Regards
>> Felix
>> 
>>> Am 05.12.2014 um 11:07 schrieb Antonio Sanso :
>>> 
>>> hi Julian
>>> 
>>> On Dec 5, 2014, at 10:31 AM, Julian Sedding  wrote:
>>> 
 Hi Antonio
 
 I agree with Justin that we should start with support for resource-types.
>>> 
>>> as said I agree we should have support for both.
>>> E.g. sling.filter.pattern, sling.filter.resourceType
>>> 
>>> 
 
 Using path-based restrictions strongly couples configuration to
 content, which IMO is not a good practice.
>>> 
>>> At the end of the day is the developer choice to choose the one she needs.
>>> In my case for example I cannot use the resource type approach.
>>> See also https://issues.apache.org/jira/browse/SLING-3829
>>> 
>>> regards
>>> 
>>> antonio
>>> 
 
 Regards
 Julian
 
 
 On Thu, Dec 4, 2014 at 3:54 PM, Antonio Sanso  wrote:
> thanks Justin for your feedback,
> 
> if you would not mind I would try to do the opposite :)
> The only reason is that I have already a Pocs for this that it actually 
> requires really few modifications.. (Felix gave me some good hints on how 
> to implement it :))
> It would probably be the same for resource type though :)
> 
> regards
> 
> antonio
> 
> On Dec 4, 2014, at 2:29 PM, Justin Edelson  
> wrote:
> 
>> Hi Antonio,
>> I'd suggest starting with support for resource type and *then* add path 
>> support.
>> 
>> Justin
>> 
>> On Thu, Dec 4, 2014 at 5:46 AM, Antonio Sanso  wrote:
>>> hi *,
>>> 
>>> the current Sling Servlet Filter Support [0] allows to have scope 
>>> dependent filter (e.g. REQUEST, INCLUDE, FORWARD, ERROR, COMPONENT).
>>> It would be nice to extend this support to have a specific filter being 
>>> taken in consideration only for specific path (adding 
>>> sling.filter.pattern) a bit like what currently can be done for Apache 
>>> Felix filters.
>>> 
>>> WDYT?
>>> 
>>> regards
>>> 
>>> antonio
>>> 
>>> [0] http://sling.apache.org/documentation/the-sling-engine/filters.html
> 
>>> 
>> 
> 



Re: [Authentication] option to close session passed as "user.jcr.session"

2015-01-13 Thread Alexander Klimetschek
On 12.01.2015, at 14:53, Alexander Klimetschek  wrote:
> Ack, sounds good. I created https://issues.apache.org/jira/browse/SLING-4301

I attached a patch.

But while testing it, I had a problem, see 
https://issues.apache.org/jira/browse/SLING-4301?focusedCommentId=14276415&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14276415

We currently have to use HttpServlets directly registered with the osgi 
HttpService (since we need to handle wildcard paths), i.e. not sling servlets, 
but we reuse the sling authenticator in handleSecurity.

This works fine with other, normal ways of logging in to the JCR using e.g. 
jackrabbit tokens, this problem only comes up with the user.jcr.session + 
logout approach.

Any ideas?

Cheers,
Alex

[jira] [Comment Edited] (SLING-4301) Support user.jcr.session.logout option for the jcr resource provider

2015-01-13 Thread Alexander Klimetschek (JIRA)

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

Alexander Klimetschek edited comment on SLING-4301 at 1/14/15 2:59 AM:
---

Attached a quick patch [^SLING-4301.patch].

But there is a problem, at least when used with servlets that directly register 
with the osgi HttpService: the session gets closed before the 
HttpServlet.service() method is called, thus code that gets the resource 
resolver from the request attributes will get "session already closed" 
exceptions. (This case does not use sling servlets at the moment, but it uses 
the sling authenticator in handleSecurity).

This is weird, below are 2 stack traces illustrating this. Note the bottom part 
below ServletHolder.java:684 are exactly the same for both, so I left them out.

1. session getting closed too early:
{code}
at 
org.apache.sling.jcr.resource.internal.helper.jcr.RepositoryHolder.release(RepositoryHolder.java:52)
at 
org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProvider.close(JcrResourceProvider.java:246)
at 
org.apache.sling.resourceresolver.impl.helper.ResourceResolverContext.close(ResourceResolverContext.java:140)
at 
org.apache.sling.resourceresolver.impl.ResourceResolverImpl.close(ResourceResolverImpl.java:144)
at 
org.apache.sling.auth.core.impl.SlingAuthenticator.requestDestroyed(SlingAuthenticator.java:626)
at 
org.apache.felix.http.base.internal.listener.ServletRequestListenerManager.requestDestroyed(ServletRequestListenerManager.java:46)
at 
org.apache.felix.http.base.internal.DispatcherServlet.service(DispatcherServlet.java:71)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
at 
org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:684)
{code}

2. servlet runs, tries to access session
{code}
java.lang.IllegalStateException: This session has been closed
at 
com.google.common.base.Preconditions.checkState(Preconditions.java:150)
at 
org.apache.jackrabbit.oak.core.ContentSessionImpl.checkLive(ContentSessionImpl.java:85)
at 
org.apache.jackrabbit.oak.core.MutableRoot.checkLive(MutableRoot.java:172)
at 
org.apache.jackrabbit.oak.core.MutableRoot.getQueryEngine(MutableRoot.java:301)
at 
org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.getQueryEngine(SessionDelegate.java:557)
at 
org.apache.jackrabbit.oak.jcr.query.QueryManagerImpl.(QueryManagerImpl.java:69)
at 
org.apache.jackrabbit.oak.jcr.session.WorkspaceImpl.(WorkspaceImpl.java:76)
at 
org.apache.jackrabbit.oak.jcr.session.SessionContext.createWorkspace(SessionContext.java:173)
at 
org.apache.jackrabbit.oak.jcr.session.SessionContext.getWorkspace(SessionContext.java:149)
at 
org.apache.jackrabbit.oak.jcr.session.SessionImpl.getWorkspace(SessionImpl.java:279)
at sun.reflect.GeneratedMethodAccessor21.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
org.apache.sling.jcr.base.SessionProxyHandler$SessionProxyInvocationHandler.invoke(SessionProxyHandler.java:113)
at com.sun.proxy.$Proxy4.getWorkspace(Unknown Source)
at 
com.adobe.cq.creativecloud.filesync.DesktopSyncServlet.service(DesktopSyncServlet.java:142)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
at 
org.apache.felix.http.base.internal.handler.ServletHandler.doHandle(ServletHandler.java:339)
at 
org.apache.felix.http.base.internal.handler.ServletHandler.handle(ServletHandler.java:300)
at 
org.apache.felix.http.base.internal.dispatch.ServletPipeline.handle(ServletPipeline.java:93)
at 
org.apache.felix.http.base.internal.dispatch.InvocationFilterChain.doFilter(InvocationFilterChain.java:50)
at 
org.apache.felix.http.base.internal.dispatch.HttpFilterChain.doFilter(HttpFilterChain.java:31)
at org.apache.sling.i18n.impl.I18NFilter.doFilter(I18NFilter.java:129)
at 
org.apache.felix.http.base.internal.handler.FilterHandler.doHandle(FilterHandler.java:108)
at 
org.apache.felix.http.base.internal.handler.FilterHandler.handle(FilterHandler.java:80)
at 
org.apache.felix.http.base.internal.dispatch.InvocationFilterChain.doFilter(InvocationFilterChain.java:46)
at 
org.apache.felix.http.base.internal.dispatch.HttpFilterChain.doFilter(HttpFilterChain.java:31)
at 
com.adobe.granite.license.impl.LicenseCheckFilter.doFilter(LicenseCheckFilter.java:300)
at 
org.apache.felix.http.base.internal.handler.FilterHandler.doHandle(FilterHandler.java:108)
at 
org.apache.felix.http.base.internal.handler.FilterHandler.handle(FilterHandler.java:80)
at 
org.apache.feli

[jira] [Updated] (SLING-4301) Support user.jcr.session.logout option for the jcr resource provider

2015-01-13 Thread Alexander Klimetschek (JIRA)

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

Alexander Klimetschek updated SLING-4301:
-
Attachment: SLING-4301.patch

Attached a quick patch [^SLING-4301.patch].

But there is a problem, at least when used with servlets that directly register 
with the osgi HttpService: the session gets closed before the 
HttpServlet.service() method is called, thus code that gets the resource 
resolver from the request attributes will get "session already closed" 
exceptions. (This case does not use sling servlets at the moment, but it uses 
the sling authenticator in handleSecurity).

This is weird, below are 2 stack traces illustrating this. Note the bottom part 
below ServletHolder.java:684 are exactly the same for both, so I left them out.

1. session getting closed too early:
{code}
at 
org.apache.sling.jcr.resource.internal.helper.jcr.RepositoryHolder.release(RepositoryHolder.java:52)
at 
org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProvider.close(JcrResourceProvider.java:246)
at 
org.apache.sling.resourceresolver.impl.helper.ResourceResolverContext.close(ResourceResolverContext.java:140)
at 
org.apache.sling.resourceresolver.impl.ResourceResolverImpl.close(ResourceResolverImpl.java:144)
at 
org.apache.sling.auth.core.impl.SlingAuthenticator.requestDestroyed(SlingAuthenticator.java:626)
at 
org.apache.felix.http.base.internal.listener.ServletRequestListenerManager.requestDestroyed(ServletRequestListenerManager.java:46)
at 
org.apache.felix.http.base.internal.DispatcherServlet.service(DispatcherServlet.java:71)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
at 
org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:684)
{code}

2. servlet runs, tries to access session
{code}
java.lang.IllegalStateException: This session has been closed
at 
com.google.common.base.Preconditions.checkState(Preconditions.java:150)
at 
org.apache.jackrabbit.oak.core.ContentSessionImpl.checkLive(ContentSessionImpl.java:85)
at 
org.apache.jackrabbit.oak.core.MutableRoot.checkLive(MutableRoot.java:172)
at 
org.apache.jackrabbit.oak.core.MutableRoot.getQueryEngine(MutableRoot.java:301)
at 
org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.getQueryEngine(SessionDelegate.java:557)
at 
org.apache.jackrabbit.oak.jcr.query.QueryManagerImpl.(QueryManagerImpl.java:69)
at 
org.apache.jackrabbit.oak.jcr.session.WorkspaceImpl.(WorkspaceImpl.java:76)
at 
org.apache.jackrabbit.oak.jcr.session.SessionContext.createWorkspace(SessionContext.java:173)
at 
org.apache.jackrabbit.oak.jcr.session.SessionContext.getWorkspace(SessionContext.java:149)
at 
org.apache.jackrabbit.oak.jcr.session.SessionImpl.getWorkspace(SessionImpl.java:279)
at sun.reflect.GeneratedMethodAccessor21.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
org.apache.sling.jcr.base.SessionProxyHandler$SessionProxyInvocationHandler.invoke(SessionProxyHandler.java:113)
at com.sun.proxy.$Proxy4.getWorkspace(Unknown Source)
at 
com.adobe.cq.creativecloud.filesync.DesktopSyncServlet.service(DesktopSyncServlet.java:142)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
at 
org.apache.felix.http.base.internal.handler.ServletHandler.doHandle(ServletHandler.java:339)
at 
org.apache.felix.http.base.internal.handler.ServletHandler.handle(ServletHandler.java:300)
at 
org.apache.felix.http.base.internal.dispatch.ServletPipeline.handle(ServletPipeline.java:93)
at 
org.apache.felix.http.base.internal.dispatch.InvocationFilterChain.doFilter(InvocationFilterChain.java:50)
at 
org.apache.felix.http.base.internal.dispatch.HttpFilterChain.doFilter(HttpFilterChain.java:31)
at org.apache.sling.i18n.impl.I18NFilter.doFilter(I18NFilter.java:129)
at 
org.apache.felix.http.base.internal.handler.FilterHandler.doHandle(FilterHandler.java:108)
at 
org.apache.felix.http.base.internal.handler.FilterHandler.handle(FilterHandler.java:80)
at 
org.apache.felix.http.base.internal.dispatch.InvocationFilterChain.doFilter(InvocationFilterChain.java:46)
at 
org.apache.felix.http.base.internal.dispatch.HttpFilterChain.doFilter(HttpFilterChain.java:31)
at 
com.adobe.granite.license.impl.LicenseCheckFilter.doFilter(LicenseCheckFilter.java:300)
at 
org.apache.felix.http.base.internal.handler.FilterHandler.doHandle(FilterHandler.java:108)
at 
org.apache.felix.http.base.internal.handler.FilterHandler.handle(FilterHandler.java:80)
at 
org.apache.felix.http.base.internal.dispatch.InvocationFilterChain.doFilter(InvocationFi

Re: Jenkins build became unstable: sling-trunk-1.7 #1317

2015-01-13 Thread Stefan Egli
This time the failure was 'java.lang.OutOfMemoryError: Java heap space'

Looks like we should give the tests more memory..

Cheers,
Stefan

On 1/13/15 6:32 PM, "Apache Jenkins Server" 
wrote:

>See 
>




Jenkins build became unstable: sling-trunk-1.7 #1317

2015-01-13 Thread Apache Jenkins Server
See 



[jira] [Updated] (SLING-1794) ConfigInstallTest fails semi-randomly: Configuration is still present

2015-01-13 Thread Robert Munteanu (JIRA)

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

Robert Munteanu updated SLING-1794:
---
Labels: it,intermittent sling-IT  (was: it,intermittent)

> ConfigInstallTest fails semi-randomly: Configuration is still present
> -
>
> Key: SLING-1794
> URL: https://issues.apache.org/jira/browse/SLING-1794
> Project: Sling
>  Issue Type: Bug
>  Components: Installer
>Reporter: Andreas Kuckartz
>Assignee: Carsten Ziegeler
>  Labels: it,intermittent, sling-IT
> Attachments: stdio.txt
>
>
> ---
> Test set: org.apache.sling.installer.it.ConfigInstallTest
> ---
> Tests run: 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 17.044 sec 
> <<< FAILURE!
> testDeferredConfigInstall 
> [felix](org.apache.sling.installer.it.ConfigInstallTest)  Time elapsed: 
> 10.072 sec  <<< FAILURE!
> java.lang.AssertionError: Config must be removed once ConfigurationAdmin 
> restarts: Configuration is still present 
> (ConfigInstallTest.deferred.1285097628299)
> at org.junit.Assert.fail(Assert.java:74)
> at 
> org.apache.sling.installer.it.OsgiInstallerTestBase.waitForConfiguration(OsgiInstallerTestBase.java:246)
> at 
> org.apache.sling.installer.it.ConfigInstallTest.testDeferredConfigInstall(ConfigInstallTest.java:149)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at 
> org.ops4j.pax.exam.junit.extender.impl.internal.CallableTestMethodImpl.injectContextAndInvoke(CallableTestMethodImpl.java:143)
> at 
> org.ops4j.pax.exam.junit.extender.impl.internal.CallableTestMethodImpl.call(CallableTestMethodImpl.java:105)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at 
> org.ops4j.pax.exam.rbc.internal.RemoteBundleContextImpl.remoteCall(RemoteBundleContextImpl.java:80)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:305)
> at sun.rmi.transport.Transport$1.run(Transport.java:159)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.rmi.transport.Transport.serviceCall(Transport.java:155)
> at 
> sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:535)
> at 
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:790)
> at 
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:649)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:619)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (SLING-4294) Servlet Filter Support adding sling.filter.pattern support

2015-01-13 Thread Carsten Ziegeler (JIRA)

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

Carsten Ziegeler commented on SLING-4294:
-

Patch looks basically good, I suggest two changes:
- update of the version of the exported package
- I would collapse the two filter case into one and then if the filter is not 
selected and is the last one, call the renderer. This minimizes the code 
duplication

> Servlet Filter Support adding sling.filter.pattern support
> --
>
> Key: SLING-4294
> URL: https://issues.apache.org/jira/browse/SLING-4294
> Project: Sling
>  Issue Type: Improvement
>  Components: Engine
>Reporter: Antonio Sanso
>Assignee: Antonio Sanso
> Attachments: SLING-4294-patch.txt
>
>
> the current Sling Servlet Filter Support [0] allows to have scope dependent 
> filter (e.g. REQUEST, INCLUDE, FORWARD, ERROR, COMPONENT).
> It would be nice to extend this support to have a specific filter being taken 
> in consideration only for specific path (adding sling.filter.pattern) a bit 
> like what currently can be done for Apache Felix filters.
> mailing list discussion in [1] 
> [0] http://sling.apache.org/documentation/the-sling-engine/filters.html
> [1] http://markmail.org/message/lzp7qcienk3blwpk



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


Re: [jenkins] more history on jenkin builds

2015-01-13 Thread Robert Munteanu
On Tue, Jan 13, 2015 at 5:14 PM, Stefan Egli  wrote:
> Hi Robert,
>
> On 1/13/15 4:02 PM, "Robert Munteanu"  wrote:
>
>>I guess it's limited to not overload Jenkins ( both memory and disk
>>space ) with history.
>
> Do we know how much a build needs in terms of disk space? I would have
> assumed that it keeps only the test/console results not the workspaces -
> in which case it should be rather small - but I'm not sure.

I think it's less disk space and more Jenkins memory with e.g. the
console output.

>
>>I can make this change ( but can't grant you karma ) . Right now we keep
>>the last 10 builds. How many builds do you think we should keep?
>
> Depends on the above I guess - and with the assumption that it uses only
> very little space, I would have suggested 50 :)

Done, let's see how that turns out :-)

Robert

>
> Cheers,
> Stefan
>
>


[jira] [Commented] (SLING-920) Sling Jenkins setup

2015-01-13 Thread Robert Munteanu (JIRA)

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

Robert Munteanu commented on SLING-920:
---

Updated sling-trunk-{1.6,1.7,1.8} to hold up to 50 builds, to make debugging 
easier as discussed at http://markmail.org/thread/kxlouxylpnneabsy

> Sling Jenkins setup
> ---
>
> Key: SLING-920
> URL: https://issues.apache.org/jira/browse/SLING-920
> Project: Sling
>  Issue Type: Task
>  Components: Testing
>Reporter: Bertrand Delacretaz
>
> Use this issue to record changes to the Jenkins setup at 
> https://builds.apache.org/view/S-Z/view/Sling/



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (SLING-4261) WriteableResourcesProxyTest.runWriteableResourcesTest test failure

2015-01-13 Thread Robert Munteanu (JIRA)

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

Robert Munteanu updated SLING-4261:
---
Description: 
{noformat}java.lang.AssertionError: POST request to 
http://localhost:35847/system/sling/junit/org.apache.sling.launchpad.testservices.serversidetests.WriteableResourcesTest.json:
 expecting status 200 expected:<200> but was:<404>
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:743)
at org.junit.Assert.assertEquals(Assert.java:118)
at org.junit.Assert.assertEquals(Assert.java:555)
at 
org.apache.sling.testing.tools.http.RequestExecutor.assertStatus(RequestExecutor.java:155)
at 
org.apache.sling.junit.remote.httpclient.RemoteTestHttpClient.runTests(RemoteTestHttpClient.java:134)
at 
org.apache.sling.launchpad.webapp.integrationtest.util.ServerSideTestClient.runTests(ServerSideTestClient.java:76)
at 
org.apache.sling.launchpad.webapp.integrationtest.util.ServerSideTestClient.assertTestsPass(ServerSideTestClient.java:100)
at 
org.apache.sling.launchpad.webapp.integrationtest.WriteableResourcesProxyTest.runWriteableResourcesTest(WriteableResourcesProxyTest.java:26)
{noformat}

Recorded failures:

* [sling-trunk-1.7 build 
1255|https://builds.apache.org/job/sling-trunk-1.7/1255/]
* [sling-trunk-1.8 build 
610|https://builds.apache.org/job/sling-trunk-1.8/610/] at revision 1651385

  was:
{noformat}java.lang.AssertionError: POST request to 
http://localhost:35847/system/sling/junit/org.apache.sling.launchpad.testservices.serversidetests.WriteableResourcesTest.json:
 expecting status 200 expected:<200> but was:<404>
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:743)
at org.junit.Assert.assertEquals(Assert.java:118)
at org.junit.Assert.assertEquals(Assert.java:555)
at 
org.apache.sling.testing.tools.http.RequestExecutor.assertStatus(RequestExecutor.java:155)
at 
org.apache.sling.junit.remote.httpclient.RemoteTestHttpClient.runTests(RemoteTestHttpClient.java:134)
at 
org.apache.sling.launchpad.webapp.integrationtest.util.ServerSideTestClient.runTests(ServerSideTestClient.java:76)
at 
org.apache.sling.launchpad.webapp.integrationtest.util.ServerSideTestClient.assertTestsPass(ServerSideTestClient.java:100)
at 
org.apache.sling.launchpad.webapp.integrationtest.WriteableResourcesProxyTest.runWriteableResourcesTest(WriteableResourcesProxyTest.java:26)
{noformat}

Recorded failures:

* [sling-trunk-1.7 build 
1255|https://builds.apache.org/job/sling-trunk-1.7/1255/]


> WriteableResourcesProxyTest.runWriteableResourcesTest test failure
> --
>
> Key: SLING-4261
> URL: https://issues.apache.org/jira/browse/SLING-4261
> Project: Sling
>  Issue Type: Bug
>  Components: Testing
>Reporter: Robert Munteanu
>  Labels: sling-IT
>
> {noformat}java.lang.AssertionError: POST request to 
> http://localhost:35847/system/sling/junit/org.apache.sling.launchpad.testservices.serversidetests.WriteableResourcesTest.json:
>  expecting status 200 expected:<200> but was:<404>
>   at org.junit.Assert.fail(Assert.java:88)
>   at org.junit.Assert.failNotEquals(Assert.java:743)
>   at org.junit.Assert.assertEquals(Assert.java:118)
>   at org.junit.Assert.assertEquals(Assert.java:555)
>   at 
> org.apache.sling.testing.tools.http.RequestExecutor.assertStatus(RequestExecutor.java:155)
>   at 
> org.apache.sling.junit.remote.httpclient.RemoteTestHttpClient.runTests(RemoteTestHttpClient.java:134)
>   at 
> org.apache.sling.launchpad.webapp.integrationtest.util.ServerSideTestClient.runTests(ServerSideTestClient.java:76)
>   at 
> org.apache.sling.launchpad.webapp.integrationtest.util.ServerSideTestClient.assertTestsPass(ServerSideTestClient.java:100)
>   at 
> org.apache.sling.launchpad.webapp.integrationtest.WriteableResourcesProxyTest.runWriteableResourcesTest(WriteableResourcesProxyTest.java:26)
> {noformat}
> Recorded failures:
> * [sling-trunk-1.7 build 
> 1255|https://builds.apache.org/job/sling-trunk-1.7/1255/]
> * [sling-trunk-1.8 build 
> 610|https://builds.apache.org/job/sling-trunk-1.8/610/] at revision 1651385



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Resolved] (SLING-4291) NPE if optional prefix is not configured

2015-01-13 Thread Carsten Ziegeler (JIRA)

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

Carsten Ziegeler resolved SLING-4291.
-
Resolution: Fixed

> NPE if optional prefix is not configured
> 
>
> Key: SLING-4291
> URL: https://issues.apache.org/jira/browse/SLING-4291
> Project: Sling
>  Issue Type: Bug
>  Components: JCR
>Affects Versions: JCR Resource Security 1.0.0
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: JCR Resource Security 1.0.2
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


Jenkins build became unstable: sling-trunk-1.8 #610

2015-01-13 Thread Apache Jenkins Server
See 



[jira] [Closed] (SLING-4291) NPE if optional prefix is not configured

2015-01-13 Thread Carsten Ziegeler (JIRA)

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

Carsten Ziegeler closed SLING-4291.
---

> NPE if optional prefix is not configured
> 
>
> Key: SLING-4291
> URL: https://issues.apache.org/jira/browse/SLING-4291
> Project: Sling
>  Issue Type: Bug
>  Components: JCR
>Affects Versions: JCR Resource Security 1.0.0
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: JCR Resource Security 1.0.2
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[VOTE RESULT] Release Apache Sling JCR Resource Security 1.0.2

2015-01-13 Thread Carsten Ziegeler
The vote passed with three binding +1 votes.

Thanks!

Carsten
-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org


Re: [VOTE] Release Apache Sling JCR Resource Security 1.0.2

2015-01-13 Thread Carsten Ziegeler
We still need a third binding vote, please :)

Carsten

Am 13.01.15 um 08:59 schrieb Carsten Ziegeler:
> Anyone else?
> 
> Carsten
> 
> Am 09.01.15 um 14:01 schrieb Carsten Ziegeler:
>> Hi,
>>
>> the 1.0.0 release has unfortunately a nasty bug which is fixed with this
>> release:
>> https://issues.apache.org/jira/browse/SLING-4291
>>
>> Staging repository:
>> https://repository.apache.org/content/repositories/orgapachesling-1164/
>>
>> 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 1164 /tmp/sling-staging
>>
>> Please vote to approve this release:
>>
>>   [ ] +1 Approve the release
>>   [ ]  0 Don't care
>>   [ ] -1 Don't release, because ...
>>
>> This majority vote is open for at least 72 hours.
>>
>> Regards
>> Carsten
>>
> 
> 


-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org


Re: [VOTE] Release Apache Sling JCR Resource Security 1.0.2

2015-01-13 Thread Stefan Egli
+1
(verified md5/sha1)

Cheers,
Stefan


On 1/13/15 8:59 AM, "Carsten Ziegeler"  wrote:

>Anyone else?
>
>Carsten
>
>Am 09.01.15 um 14:01 schrieb Carsten Ziegeler:
>> Hi,
>> 
>> the 1.0.0 release has unfortunately a nasty bug which is fixed with this
>> release:
>> https://issues.apache.org/jira/browse/SLING-4291
>> 
>> Staging repository:
>> https://repository.apache.org/content/repositories/orgapachesling-1164/
>> 
>> 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 1164 /tmp/sling-staging
>> 
>> Please vote to approve this release:
>> 
>>   [ ] +1 Approve the release
>>   [ ]  0 Don't care
>>   [ ] -1 Don't release, because ...
>> 
>> This majority vote is open for at least 72 hours.
>> 
>> Regards
>> Carsten
>> 
>
>
>-- 
>Carsten Ziegeler
>Adobe Research Switzerland
>cziege...@apache.org




Re: storing dates with timezones in Sling

2015-01-13 Thread Konrad Windszus
Maybe you can explain a bit more in detail why you want to keep the original 
timezone? Usually you are only interested in the absolute UTC time (no matter 
in which timezone the date is given initially) when it comes to date/time 
comparisons/calculations. What do you want to do with the timezone information?
Do you need that for printing date information i.e. for converting it to a 
string (e.g. with the SimpleDateFormat)?
Konrad


> Am 12.01.2015 um 14:15 schrieb Santiago García Pimentel 
> :
> 
> Hello,
> 
> In a current project I have the need to store dates with specific timezones. 
> The current behavior stores all given dates in the server local time, even 
> when a timezone is specified. (see 
> https://issues.apache.org/jira/browse/SLING-4258 ).
> 
> Is there a way I can accomplish this? If no, how could this be changed 
> without breaking backward compatibility?
> 
> Greetings
> -- 
> *Santiago García Pimentel* | Software Engineer
> Netcentric Ibérica SL
> Av. Diagonal 123 -8ª
> 08005 Barcelona
> España
> Skype: santiago.garciapimentel
> santiago.pimen...@netcentric.biz | www.netcentric.es



[jira] [Resolved] (SLING-4306) Disable trigger method does not unregister trigger

2015-01-13 Thread Marius Petria (JIRA)

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

Marius Petria resolved SLING-4306.
--
   Resolution: Fixed
Fix Version/s: Content Distribution 0.1.0
 Assignee: Marius Petria

> Disable trigger method does not unregister trigger
> --
>
> Key: SLING-4306
> URL: https://issues.apache.org/jira/browse/SLING-4306
> Project: Sling
>  Issue Type: Bug
>  Components: Distribution
>Reporter: Marius Petria
>Assignee: Marius Petria
> Fix For: Content Distribution 0.1.0
>
>
> SimpleDistributionAgent.disableTrigger actually enables the trigger instead 
> of disabling it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (SLING-4306) Disable trigger method does not unregister trigger

2015-01-13 Thread Marius Petria (JIRA)

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

Marius Petria commented on SLING-4306:
--

Committed revision 1651383.


> Disable trigger method does not unregister trigger
> --
>
> Key: SLING-4306
> URL: https://issues.apache.org/jira/browse/SLING-4306
> Project: Sling
>  Issue Type: Bug
>  Components: Distribution
>Reporter: Marius Petria
> Fix For: Content Distribution 0.1.0
>
>
> SimpleDistributionAgent.disableTrigger actually enables the trigger instead 
> of disabling it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (SLING-4306) Disable trigger method does not unregister trigger

2015-01-13 Thread Marius Petria (JIRA)
Marius Petria created SLING-4306:


 Summary: Disable trigger method does not unregister trigger
 Key: SLING-4306
 URL: https://issues.apache.org/jira/browse/SLING-4306
 Project: Sling
  Issue Type: Bug
  Components: Distribution
Reporter: Marius Petria


SimpleDistributionAgent.disableTrigger actually enables the trigger instead of 
disabling it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


Re: [jenkins] more history on jenkin builds

2015-01-13 Thread Stefan Egli
Hi Robert,

On 1/13/15 4:02 PM, "Robert Munteanu"  wrote:

>I guess it's limited to not overload Jenkins ( both memory and disk
>space ) with history.

Do we know how much a build needs in terms of disk space? I would have
assumed that it keeps only the test/console results not the workspaces -
in which case it should be rather small - but I'm not sure.

>I can make this change ( but can't grant you karma ) . Right now we keep
>the last 10 builds. How many builds do you think we should keep?

Depends on the above I guess - and with the assumption that it uses only
very little space, I would have suggested 50 :)

Cheers,
Stefan




Re: [jenkins] more history on jenkin builds

2015-01-13 Thread Robert Munteanu
On Tue, 2015-01-13 at 15:24 +0100, Stefan Egli wrote:
> Hi,
> 
> Are there particular reasons against having a larger history (number) of
> jenkins builds (eg at [0])? Sometimes useful to go back more than 1-2 days..
> 
> If not, who could change this (I don't seem to have the karma)?
> 
> Cheers,
> Stefan
> --
> [0] - https://builds.apache.org/job/sling-trunk-1.6/
> 
> 

Hi Stefan,

I guess it's limited to not overload Jenkins ( both memory and disk
space ) with history. However, I think we can increase it temporarily
for debugging.

I can make this change ( but can't grant you karma ) . Right now we keep
the last 10 builds. How many builds do you think we should keep?

I think you can also search in the mail archives for failures, but
that's not always easy.

Robert



[jira] [Created] (SLING-4305) Refactor the Record interface

2015-01-13 Thread Radu Cotescu (JIRA)
Radu Cotescu created SLING-4305:
---

 Summary: Refactor the Record interface
 Key: SLING-4305
 URL: https://issues.apache.org/jira/browse/SLING-4305
 Project: Sling
  Issue Type: Sub-task
  Components: Scripting
Reporter: Radu Cotescu
 Fix For: Scripting Sightly Engine 1.0.0, Scripting Sightly JS Use 
Provider 1.0.0


The {{Record}} interface methods should be renamed:

{{get}} -> {{getValue}}
{{properties}} -> {{getPropertiesNames}}

See http://markmail.org/thread/47e65whixp454ocj.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (SLING-4304) Refactor the ResourceResolution class and improve its JavaDoc

2015-01-13 Thread Radu Cotescu (JIRA)

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

Radu Cotescu updated SLING-4304:

Description: 
The {{ResourceResolution}} class provides two static methods used for 
identifying resources based on resource inheritance. Since these methods could 
be extracted to a more generic place than the Sightly bundles, their naming and 
documentation should be clearer.

See http://markmail.org/thread/uvewfnf3c7a74xoz.

  was:The {{ResourceResolution}} class provides two static methods used for 
identifying resources based on resource inheritance. Since these methods could 
be extracted to a more generic place than the Sightly bundles, their naming and 
documentation should be clearer.


> Refactor the ResourceResolution class and improve its JavaDoc
> -
>
> Key: SLING-4304
> URL: https://issues.apache.org/jira/browse/SLING-4304
> Project: Sling
>  Issue Type: Sub-task
>  Components: Scripting
>Reporter: Radu Cotescu
> Fix For: Scripting Sightly Engine 1.0.0, Scripting Sightly JS Use 
> Provider 1.0.0
>
>
> The {{ResourceResolution}} class provides two static methods used for 
> identifying resources based on resource inheritance. Since these methods 
> could be extracted to a more generic place than the Sightly bundles, their 
> naming and documentation should be clearer.
> See http://markmail.org/thread/uvewfnf3c7a74xoz.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (SLING-4304) Refactor the ResourceResolution class and improve its JavaDoc

2015-01-13 Thread Radu Cotescu (JIRA)

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

Radu Cotescu updated SLING-4304:

Fix Version/s: Scripting Sightly JS Use Provider 1.0.0

> Refactor the ResourceResolution class and improve its JavaDoc
> -
>
> Key: SLING-4304
> URL: https://issues.apache.org/jira/browse/SLING-4304
> Project: Sling
>  Issue Type: Sub-task
>  Components: Scripting
>Reporter: Radu Cotescu
> Fix For: Scripting Sightly Engine 1.0.0, Scripting Sightly JS Use 
> Provider 1.0.0
>
>
> The {{ResourceResolution}} class provides two static methods used for 
> identifying resources based on resource inheritance. Since these methods 
> could be extracted to a more generic place than the Sightly bundles, their 
> naming and documentation should be clearer.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


Re: [SLING-4275] API: Record Interface

2015-01-13 Thread Carsten Ziegeler
Am 13.01.15 um 15:36 schrieb Radu Cotescu:
> Hi,
> 
> We could do this, but in this case I'd suggest to go for something like:
> 
> T getValueForProperty(String propertyName) instead of T get(String name)
> 
> Set getPropertyNames() instead of Set properties()
> 
> WDYT?

Yes get() doesn't look nice either :) I would go for getValue() but
getValueForProperty is fine as well

Carsten

> 
> Radu
> 
> On Tue, Jan 13, 2015 at 12:49 PM, Carsten Ziegeler 
> wrote:
> 
>> Can we at least rename the properties() method to getPropertyNames()
>>
>> Carsten
>>
>> Am 12.01.15 um 18:55 schrieb Radu Cotescu:
>>> Hi,
>>>
>>> The Record interface is more complex. Besides being used in the JS Use
>>> Provider code for injecting global objects to the current bindings, the
>>> interface is also used to allow Sightly templates (defined through
>>> data-sly-template) to contain other templates (imbricated
>> data-sly-template
>>> block elements).
>>>
>>> Since Sightly templates are loaded through the Use API (e.g. >> data-sly-use.tmplLibrary="/apps/myproj/components/templates.html">...),
>>> templates become objects in a Sightly script. Templates embedded in
>> another
>>> template become properties of the main template object. The Record
>>> interface provides this flexibility.
>>>
>>> HTH,
>>> Radu
>>>
>>> On Mon, Jan 12, 2015 at 11:44 AM, Felix Meschberger 
>>> wrote:
>>>
 Hi all

 Carsten started to review the Sightly Engine API in SLING-4275 [1].
>> Since
 this issue covers 4 topics, I think it would be best to quickly discuss
 these topic in separate threads.

 #3 Record Interface

 The Record interface is used primarily by the Java POJO UseProvider to
 inject properties back into the Sightly template bindings: If the object
 loaded by the provider happens to implement the Record interface, the
 respective properties are injected into the current bindings.

 The Question is whether this interface is specific to the Java POJO
 UseProvider or not ?

 If it is specific, it should probably be moved into a pojo sub package.

 WDYT ?

 Regards
 Felix

 [1] https://issues.apache.org/jira/browse/SLING-4275
>>>
>>
>>
>> --
>> Carsten Ziegeler
>> Adobe Research Switzerland
>> cziege...@apache.org
>>
> 


-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org


Re: [SLING-4275] API: ResourceResolution helper

2015-01-13 Thread Radu Cotescu
Sure. I created https://issues.apache.org/jira/browse/SLING-4304.

On Tue, Jan 13, 2015 at 12:56 PM, Carsten Ziegeler 
wrote:

> Alright, so what about doing the renaming/javadoc update first and then
> see where to put it?
>


[jira] [Created] (SLING-4304) Refactor the ResourceResolution class and improve its JavaDoc

2015-01-13 Thread Radu Cotescu (JIRA)
Radu Cotescu created SLING-4304:
---

 Summary: Refactor the ResourceResolution class and improve its 
JavaDoc
 Key: SLING-4304
 URL: https://issues.apache.org/jira/browse/SLING-4304
 Project: Sling
  Issue Type: Sub-task
  Components: Scripting
Reporter: Radu Cotescu
 Fix For: Scripting Sightly Engine 1.0.0


The {{ResourceResolution}} class provides two static methods used for 
identifying resources based on resource inheritance. Since these methods could 
be extracted to a more generic place than the Sightly bundles, their naming and 
documentation should be clearer.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (SLING-4303) ClusterLoadTest.testFourInstances sometimes fails

2015-01-13 Thread Stefan Egli (JIRA)

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

Stefan Egli commented on SLING-4303:


Added more logging (and avoided a NPE - but that one is likely unrelated) in 
svn.apache.org/viewvc?view=revision&revision=r1651360 - keeping ticket open to 
get it reproduced and fixed based on additional logging

> ClusterLoadTest.testFourInstances sometimes fails
> -
>
> Key: SLING-4303
> URL: https://issues.apache.org/jira/browse/SLING-4303
> Project: Sling
>  Issue Type: Test
>  Components: Extensions
>Affects Versions: Discovery Impl 1.0.12
>Reporter: Stefan Egli
>Assignee: Stefan Egli
> Fix For: Discovery Impl 1.0.14
>
>
> ClusterLoadTest.testFourInstances sometimes fails - eg 
> https://builds.apache.org/job/sling-trunk-1.6/org.apache.sling$org.apache.sling.discovery.impl/2932/testReport/org.apache.sling.discovery.impl.cluster/ClusterLoadTest/testFourInstances/
> {code}
> Tests run: 7, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 81.261 sec 
> <<< FAILURE! - in org.apache.sling.discovery.impl.cluster.ClusterLoadTest
> testFourInstances(org.apache.sling.discovery.impl.cluster.ClusterLoadTest)  
> Time elapsed: 0.194 sec  <<< ERROR!
> java.lang.reflect.InvocationTargetException: null
>   at org.apache.jackrabbit.core.ItemManager.getNode(ItemManager.java:577)
>   at 
> org.apache.jackrabbit.core.session.SessionItemOperation$6.perform(SessionItemOperation.java:129)
>   at 
> org.apache.jackrabbit.core.session.SessionItemOperation$6.perform(SessionItemOperation.java:125)
>   at 
> org.apache.jackrabbit.core.session.SessionItemOperation.perform(SessionItemOperation.java:187)
>   at 
> org.apache.jackrabbit.core.session.SessionState.perform(SessionState.java:200)
>   at org.apache.jackrabbit.core.SessionImpl.perform(SessionImpl.java:355)
>   at org.apache.jackrabbit.core.SessionImpl.getNode(SessionImpl.java:1054)
>   at 
> org.apache.sling.discovery.impl.setup.MockedResource.adaptTo(MockedResource.java:89)
>   at 
> org.apache.sling.discovery.impl.setup.MockedResourceResolver.listChildren(MockedResourceResolver.java:160)
>   at 
> org.apache.sling.api.resource.AbstractResource.listChildren(AbstractResource.java:93)
>   at 
> org.apache.sling.api.resource.AbstractResource$1.iterator(AbstractResource.java:103)
>   at 
> org.apache.sling.discovery.impl.common.resource.EstablishedClusterView.(EstablishedClusterView.java:68)
>   at 
> org.apache.sling.discovery.impl.cluster.ClusterViewServiceImpl.getClusterView(ClusterViewServiceImpl.java:141)
>   at 
> org.apache.sling.discovery.impl.DiscoveryServiceImpl.getTopology(DiscoveryServiceImpl.java:418)
>   at 
> org.apache.sling.discovery.impl.DiscoveryServiceImpl.activate(DiscoveryServiceImpl.java:159)
>   at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>   at java.lang.reflect.Method.invoke(Method.java:597)
>   at 
> org.apache.sling.discovery.impl.setup.OSGiMock.activate(OSGiMock.java:69)
>   at 
> org.apache.sling.discovery.impl.setup.OSGiMock.activateAll(OSGiMock.java:57)
>   at 
> org.apache.sling.discovery.impl.setup.Instance.(Instance.java:349)
>   at 
> org.apache.sling.discovery.impl.setup.Instance.newClusterInstance(Instance.java:387)
>   at 
> org.apache.sling.discovery.impl.cluster.ClusterLoadTest.doDoTest(ClusterLoadTest.java:148)
>   at 
> org.apache.sling.discovery.impl.cluster.ClusterLoadTest.doTest(ClusterLoadTest.java:124)
>   at 
> org.apache.sling.discovery.impl.cluster.ClusterLoadTest.testFourInstances(ClusterLoadTest.java:100)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


Jenkins build is back to stable : sling-trunk-1.8 #608

2015-01-13 Thread Apache Jenkins Server
See 



Re: [SLING-4275] API: Record Interface

2015-01-13 Thread Radu Cotescu
Hi,

We could do this, but in this case I'd suggest to go for something like:

T getValueForProperty(String propertyName) instead of T get(String name)

Set getPropertyNames() instead of Set properties()

WDYT?

Radu

On Tue, Jan 13, 2015 at 12:49 PM, Carsten Ziegeler 
wrote:

> Can we at least rename the properties() method to getPropertyNames()
>
> Carsten
>
> Am 12.01.15 um 18:55 schrieb Radu Cotescu:
> > Hi,
> >
> > The Record interface is more complex. Besides being used in the JS Use
> > Provider code for injecting global objects to the current bindings, the
> > interface is also used to allow Sightly templates (defined through
> > data-sly-template) to contain other templates (imbricated
> data-sly-template
> > block elements).
> >
> > Since Sightly templates are loaded through the Use API (e.g.  > data-sly-use.tmplLibrary="/apps/myproj/components/templates.html">...),
> > templates become objects in a Sightly script. Templates embedded in
> another
> > template become properties of the main template object. The Record
> > interface provides this flexibility.
> >
> > HTH,
> > Radu
> >
> > On Mon, Jan 12, 2015 at 11:44 AM, Felix Meschberger 
> > wrote:
> >
> >> Hi all
> >>
> >> Carsten started to review the Sightly Engine API in SLING-4275 [1].
> Since
> >> this issue covers 4 topics, I think it would be best to quickly discuss
> >> these topic in separate threads.
> >>
> >> #3 Record Interface
> >>
> >> The Record interface is used primarily by the Java POJO UseProvider to
> >> inject properties back into the Sightly template bindings: If the object
> >> loaded by the provider happens to implement the Record interface, the
> >> respective properties are injected into the current bindings.
> >>
> >> The Question is whether this interface is specific to the Java POJO
> >> UseProvider or not ?
> >>
> >> If it is specific, it should probably be moved into a pojo sub package.
> >>
> >> WDYT ?
> >>
> >> Regards
> >> Felix
> >>
> >> [1] https://issues.apache.org/jira/browse/SLING-4275
> >
>
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org
>


[jira] [Created] (SLING-4303) ClusterLoadTest.testFourInstances sometimes fails

2015-01-13 Thread Stefan Egli (JIRA)
Stefan Egli created SLING-4303:
--

 Summary: ClusterLoadTest.testFourInstances sometimes fails
 Key: SLING-4303
 URL: https://issues.apache.org/jira/browse/SLING-4303
 Project: Sling
  Issue Type: Test
  Components: Extensions
Affects Versions: Discovery Impl 1.0.12
Reporter: Stefan Egli
Assignee: Stefan Egli
 Fix For: Discovery Impl 1.0.14


ClusterLoadTest.testFourInstances sometimes fails - eg 
https://builds.apache.org/job/sling-trunk-1.6/org.apache.sling$org.apache.sling.discovery.impl/2932/testReport/org.apache.sling.discovery.impl.cluster/ClusterLoadTest/testFourInstances/

{code}
Tests run: 7, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 81.261 sec <<< 
FAILURE! - in org.apache.sling.discovery.impl.cluster.ClusterLoadTest
testFourInstances(org.apache.sling.discovery.impl.cluster.ClusterLoadTest)  
Time elapsed: 0.194 sec  <<< ERROR!
java.lang.reflect.InvocationTargetException: null
at org.apache.jackrabbit.core.ItemManager.getNode(ItemManager.java:577)
at 
org.apache.jackrabbit.core.session.SessionItemOperation$6.perform(SessionItemOperation.java:129)
at 
org.apache.jackrabbit.core.session.SessionItemOperation$6.perform(SessionItemOperation.java:125)
at 
org.apache.jackrabbit.core.session.SessionItemOperation.perform(SessionItemOperation.java:187)
at 
org.apache.jackrabbit.core.session.SessionState.perform(SessionState.java:200)
at org.apache.jackrabbit.core.SessionImpl.perform(SessionImpl.java:355)
at org.apache.jackrabbit.core.SessionImpl.getNode(SessionImpl.java:1054)
at 
org.apache.sling.discovery.impl.setup.MockedResource.adaptTo(MockedResource.java:89)
at 
org.apache.sling.discovery.impl.setup.MockedResourceResolver.listChildren(MockedResourceResolver.java:160)
at 
org.apache.sling.api.resource.AbstractResource.listChildren(AbstractResource.java:93)
at 
org.apache.sling.api.resource.AbstractResource$1.iterator(AbstractResource.java:103)
at 
org.apache.sling.discovery.impl.common.resource.EstablishedClusterView.(EstablishedClusterView.java:68)
at 
org.apache.sling.discovery.impl.cluster.ClusterViewServiceImpl.getClusterView(ClusterViewServiceImpl.java:141)
at 
org.apache.sling.discovery.impl.DiscoveryServiceImpl.getTopology(DiscoveryServiceImpl.java:418)
at 
org.apache.sling.discovery.impl.DiscoveryServiceImpl.activate(DiscoveryServiceImpl.java:159)
at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at 
org.apache.sling.discovery.impl.setup.OSGiMock.activate(OSGiMock.java:69)
at 
org.apache.sling.discovery.impl.setup.OSGiMock.activateAll(OSGiMock.java:57)
at 
org.apache.sling.discovery.impl.setup.Instance.(Instance.java:349)
at 
org.apache.sling.discovery.impl.setup.Instance.newClusterInstance(Instance.java:387)
at 
org.apache.sling.discovery.impl.cluster.ClusterLoadTest.doDoTest(ClusterLoadTest.java:148)
at 
org.apache.sling.discovery.impl.cluster.ClusterLoadTest.doTest(ClusterLoadTest.java:124)
at 
org.apache.sling.discovery.impl.cluster.ClusterLoadTest.testFourInstances(ClusterLoadTest.java:100)
{code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jenkins] more history on jenkin builds

2015-01-13 Thread Stefan Egli
Hi,

Are there particular reasons against having a larger history (number) of
jenkins builds (eg at [0])? Sometimes useful to go back more than 1-2 days..

If not, who could change this (I don't seem to have the karma)?

Cheers,
Stefan
--
[0] - https://builds.apache.org/job/sling-trunk-1.6/




Re: VOTE] Release Apache Sling Resource Resolver 1.1.10

2015-01-13 Thread Carsten Ziegeler
Am 13.01.15 um 14:30 schrieb Antonio Sanso:
> Hi,
> 
> We solved 4 issues in this release:
> https://issues.apache.org/jira/browse/SLING/fixforversion/12329053
> 
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-1167/
> 
> 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 1167 /tmp/sling-staging
> 
> Please vote to approve this release:
> 
>  [ ] +1 Approve the release
>  [ ]  0 Don't care
>  [ ] -1 Don't release, because ...
> 
> This majority vote is open for at least 72 hours.
> 
+1

Carsten

-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org


[jira] [Commented] (SLING-4302) ClusterTest.testStableClusterId sometimes fails

2015-01-13 Thread Stefan Egli (JIRA)

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

Stefan Egli commented on SLING-4302:


Increased timeouts in 
http://svn.apache.org/viewvc?view=revision&revision=r1651345 - keeping this 
ticket open for verification though

> ClusterTest.testStableClusterId sometimes fails
> ---
>
> Key: SLING-4302
> URL: https://issues.apache.org/jira/browse/SLING-4302
> Project: Sling
>  Issue Type: Test
>  Components: Extensions
>Affects Versions: Discovery Impl 1.0.12
>Reporter: Stefan Egli
>Assignee: Stefan Egli
> Fix For: Discovery Impl 1.0.14
>
>
> Recently, ClusterTest.testStableClusterId sometimes fails, eg 
> https://builds.apache.org/job/sling-trunk-1.8/org.apache.sling$org.apache.sling.discovery.impl/607/testReport/org.apache.sling.discovery.impl.cluster/ClusterTest/testStableClusterId/
> {code}
> Error Message
> expected:<2> but was:<1>
> Stacktrace
> java.lang.AssertionError: expected:<2> but was:<1>
>   at org.junit.Assert.fail(Assert.java:88)
>   at org.junit.Assert.failNotEquals(Assert.java:743)
>   at org.junit.Assert.assertEquals(Assert.java:118)
>   at org.junit.Assert.assertEquals(Assert.java:555)
>   at org.junit.Assert.assertEquals(Assert.java:542)
>   at 
> org.apache.sling.discovery.impl.cluster.ClusterTest.testStableClusterId(ClusterTest.java:184)
> Standard Output
> 13.01.2015 12:03:06 *INFO * [main] Instance: : starting 
> slingId=e997787e-e6f2-4d54-af7d-19dcfb9fbc9a, debugName=firstInstance
> 13.01.2015 12:03:06 *INFO * [ObservationManager] VotingHelper: 
> getWinningVoting: no ongoing votings parent resource found
> 13.01.2015 12:03:06 *INFO * [ObservationManager] VotingHelper: 
> listOpenNonWinningVotings: no ongoing votings parent resource found
> 13.01.2015 12:03:08 *INFO * [main] Instance: : starting 
> slingId=808c627d-fc2f-472c-8b39-bdcdc8ead24f, debugName=secondInstance
> 13.01.2015 12:03:18 *INFO * [main] ClusterTest: testStableClusterId: start
> 13.01.2015 12:03:18 *INFO * [main] Instance: stop: stopping 
> slingId=808c627d-fc2f-472c-8b39-bdcdc8ead24f, debugName=secondInstance
> 13.01.2015 12:03:18 *INFO * [main] Instance: stop: removing listener for 
> slingId=808c627d-fc2f-472c-8b39-bdcdc8ead24f: 
> org.apache.sling.discovery.impl.setup.Instance$1@13e880b5
> 13.01.2015 12:03:18 *INFO * [main] Instance: stop: stopped 
> slingId=808c627d-fc2f-472c-8b39-bdcdc8ead24f, debugName=secondInstance
> 13.01.2015 12:03:18 *INFO * [main] Instance: stop: stopping 
> slingId=e997787e-e6f2-4d54-af7d-19dcfb9fbc9a, debugName=firstInstance
> 13.01.2015 12:03:18 *INFO * [main] Instance: stop: removing listener for 
> slingId=e997787e-e6f2-4d54-af7d-19dcfb9fbc9a: 
> org.apache.sling.discovery.impl.setup.Instance$1@73c7a727
> 13.01.2015 12:03:18 *INFO * [main] Instance: stop: stopped 
> slingId=e997787e-e6f2-4d54-af7d-19dcfb9fbc9a, debugName=firstInstance
> 13.01.2015 12:03:18 *INFO * [main] Instance: : starting 
> slingId=64d74699-661e-42aa-be7f-076c93773326, debugName=firstInstance
> 13.01.2015 12:03:18 *INFO * [main] Instance: : starting 
> slingId=de74b83b-c913-40b0-a958-eba71d12a867, debugName=secondInstance
> 13.01.2015 12:03:20 *INFO * [main] Instance: Instance 
> [64d74699-661e-42aa-be7f-076c93773326] issues a heartbeat now Tue Jan 13 
> 12:03:20 UTC 2015
> 13.01.2015 12:03:20 *INFO * [main] HeartbeatHandler: doCheckView: 
> votingHandler is null!
> 13.01.2015 12:03:20 *INFO * [main] VotingHelper: getWinningVoting: no ongoing 
> votings parent resource found
> 13.01.2015 12:03:20 *INFO * [main] VotingHelper: listOpenNonWinningVotings: 
> no ongoing votings parent resource found
> 13.01.2015 12:03:20 *INFO * [main] Instance: Instance 
> [de74b83b-c913-40b0-a958-eba71d12a867] issues a heartbeat now Tue Jan 13 
> 12:03:20 UTC 2015
> 13.01.2015 12:03:57 *INFO * [main] HeartbeatHandler: doCheckView: 
> votingHandler is null!
> 13.01.2015 12:03:57 *INFO * [pool-1-thread-2] HeartbeatHandler: doCheckView: 
> votingHandler is null!
> 13.01.2015 12:03:57 *INFO * [main] Instance: Instance 
> [64d74699-661e-42aa-be7f-076c93773326] issues a heartbeat now Tue Jan 13 
> 12:03:57 UTC 2015
> 13.01.2015 12:03:57 *INFO * [main] ClusterViewServiceImpl: 
> getEstablishedView: the existing established view does not incude the local 
> instance yet! Assuming isolated mode. If this occurs at runtime - other than 
> at startup - it could cause a pseudo-network-partition, see SLING-3432. 
> Consider increasing heartbeatTimeout then!
> 13.01.2015 12:03:58 *INFO * [main] HeartbeatHandler: doCheckView: 
> votingHandler is null!
> 13.01.2015 12:03:58 *INFO * [main] Instance: Instance 
> [de74b83b-c913-40b0-a958-eba71d12a867] issues a heartbeat now Tue Jan 13 
> 12:03:58 UTC 2015
> 13.01.2015 12:03:59 

Re: [VOTE] Release Apache Sling i18n 2.3.2

2015-01-13 Thread Robert Munteanu
+1

Robert

On Tue, Jan 13, 2015 at 3:31 PM, Antonio Sanso  wrote:
> +1
> On Jan 13, 2015, at 9:29 AM, Carsten Ziegeler  wrote:
>
>> Hi,
>>
>> we cancelled the 2.3.0 release to fix an issue introduced in 2.2.8
>> https://issues.apache.org/jira/browse/SLING-4299
>>
>> Staging repository:
>> https://repository.apache.org/content/repositories/orgapachesling-1165/
>>
>> 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 1165 /tmp/sling-staging
>>
>> Please vote to approve this release:
>>
>>  [ ] +1 Approve the release
>>  [ ]  0 Don't care
>>  [ ] -1 Don't release, because ...
>>
>> This majority vote is open for at least 72 hours.
>>
>> Regards
>> Carsten--
>> Carsten Ziegeler
>> Adobe Research Switzerland
>> cziege...@apache.org
>


Re: VOTE] Release Apache Sling Resource Resolver 1.1.10

2015-01-13 Thread Robert Munteanu
+1

Robert

On Tue, Jan 13, 2015 at 3:33 PM, Antonio Sanso  wrote:
> +1
> On Jan 13, 2015, at 2:30 PM, Antonio Sanso  wrote:
>
>> Hi,
>>
>> We solved 4 issues in this release:
>> https://issues.apache.org/jira/browse/SLING/fixforversion/12329053
>>
>> Staging repository:
>> https://repository.apache.org/content/repositories/orgapachesling-1167/
>>
>> 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 1167 /tmp/sling-staging
>>
>> Please vote to approve this release:
>>
>> [ ] +1 Approve the release
>> [ ]  0 Don't care
>> [ ] -1 Don't release, because ...
>>
>> This majority vote is open for at least 72 hours.
>


Re: [VOTE] Release Apache Sling Installer Core 3.6.2

2015-01-13 Thread Robert Munteanu
+1

Robert

On Tue, Jan 13, 2015 at 3:33 PM, Antonio Sanso  wrote:
> +1
>
> On Jan 13, 2015, at 9:25 AM, Carsten Ziegeler  wrote:
>
>> Hi,
>>
>> the 3.6.0 release has unfortunately a nasty bug which is fixed with this
>> release:
>> https://issues.apache.org/jira/browse/SLING/fixforversion/12329251/
>>
>> Staging repository:
>> https://repository.apache.org/content/repositories/orgapachesling-1166/
>>
>> 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 1166 /tmp/sling-staging
>>
>> Please vote to approve this release:
>>
>>  [ ] +1 Approve the release
>>  [ ]  0 Don't care
>>  [ ] -1 Don't release, because ...
>>
>> This majority vote is open for at least 72 hours.
>>
>> Regards
>> Carsten
>> --
>> Carsten Ziegeler
>> Adobe Research Switzerland
>> cziege...@apache.org
>


[jira] [Created] (SLING-4302) ClusterTest.testStableClusterId sometimes fails

2015-01-13 Thread Stefan Egli (JIRA)
Stefan Egli created SLING-4302:
--

 Summary: ClusterTest.testStableClusterId sometimes fails
 Key: SLING-4302
 URL: https://issues.apache.org/jira/browse/SLING-4302
 Project: Sling
  Issue Type: Test
  Components: Extensions
Affects Versions: Discovery Impl 1.0.12
Reporter: Stefan Egli
Assignee: Stefan Egli
 Fix For: Discovery Impl 1.0.14


Recently, ClusterTest.testStableClusterId sometimes fails, eg 
https://builds.apache.org/job/sling-trunk-1.8/org.apache.sling$org.apache.sling.discovery.impl/607/testReport/org.apache.sling.discovery.impl.cluster/ClusterTest/testStableClusterId/

{code}
Error Message

expected:<2> but was:<1>

Stacktrace

java.lang.AssertionError: expected:<2> but was:<1>
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:743)
at org.junit.Assert.assertEquals(Assert.java:118)
at org.junit.Assert.assertEquals(Assert.java:555)
at org.junit.Assert.assertEquals(Assert.java:542)
at 
org.apache.sling.discovery.impl.cluster.ClusterTest.testStableClusterId(ClusterTest.java:184)

Standard Output

13.01.2015 12:03:06 *INFO * [main] Instance: : starting 
slingId=e997787e-e6f2-4d54-af7d-19dcfb9fbc9a, debugName=firstInstance
13.01.2015 12:03:06 *INFO * [ObservationManager] VotingHelper: 
getWinningVoting: no ongoing votings parent resource found
13.01.2015 12:03:06 *INFO * [ObservationManager] VotingHelper: 
listOpenNonWinningVotings: no ongoing votings parent resource found
13.01.2015 12:03:08 *INFO * [main] Instance: : starting 
slingId=808c627d-fc2f-472c-8b39-bdcdc8ead24f, debugName=secondInstance
13.01.2015 12:03:18 *INFO * [main] ClusterTest: testStableClusterId: start
13.01.2015 12:03:18 *INFO * [main] Instance: stop: stopping 
slingId=808c627d-fc2f-472c-8b39-bdcdc8ead24f, debugName=secondInstance
13.01.2015 12:03:18 *INFO * [main] Instance: stop: removing listener for 
slingId=808c627d-fc2f-472c-8b39-bdcdc8ead24f: 
org.apache.sling.discovery.impl.setup.Instance$1@13e880b5
13.01.2015 12:03:18 *INFO * [main] Instance: stop: stopped 
slingId=808c627d-fc2f-472c-8b39-bdcdc8ead24f, debugName=secondInstance
13.01.2015 12:03:18 *INFO * [main] Instance: stop: stopping 
slingId=e997787e-e6f2-4d54-af7d-19dcfb9fbc9a, debugName=firstInstance
13.01.2015 12:03:18 *INFO * [main] Instance: stop: removing listener for 
slingId=e997787e-e6f2-4d54-af7d-19dcfb9fbc9a: 
org.apache.sling.discovery.impl.setup.Instance$1@73c7a727
13.01.2015 12:03:18 *INFO * [main] Instance: stop: stopped 
slingId=e997787e-e6f2-4d54-af7d-19dcfb9fbc9a, debugName=firstInstance
13.01.2015 12:03:18 *INFO * [main] Instance: : starting 
slingId=64d74699-661e-42aa-be7f-076c93773326, debugName=firstInstance
13.01.2015 12:03:18 *INFO * [main] Instance: : starting 
slingId=de74b83b-c913-40b0-a958-eba71d12a867, debugName=secondInstance
13.01.2015 12:03:20 *INFO * [main] Instance: Instance 
[64d74699-661e-42aa-be7f-076c93773326] issues a heartbeat now Tue Jan 13 
12:03:20 UTC 2015
13.01.2015 12:03:20 *INFO * [main] HeartbeatHandler: doCheckView: votingHandler 
is null!
13.01.2015 12:03:20 *INFO * [main] VotingHelper: getWinningVoting: no ongoing 
votings parent resource found
13.01.2015 12:03:20 *INFO * [main] VotingHelper: listOpenNonWinningVotings: no 
ongoing votings parent resource found
13.01.2015 12:03:20 *INFO * [main] Instance: Instance 
[de74b83b-c913-40b0-a958-eba71d12a867] issues a heartbeat now Tue Jan 13 
12:03:20 UTC 2015
13.01.2015 12:03:57 *INFO * [main] HeartbeatHandler: doCheckView: votingHandler 
is null!
13.01.2015 12:03:57 *INFO * [pool-1-thread-2] HeartbeatHandler: doCheckView: 
votingHandler is null!
13.01.2015 12:03:57 *INFO * [main] Instance: Instance 
[64d74699-661e-42aa-be7f-076c93773326] issues a heartbeat now Tue Jan 13 
12:03:57 UTC 2015
13.01.2015 12:03:57 *INFO * [main] ClusterViewServiceImpl: getEstablishedView: 
the existing established view does not incude the local instance yet! Assuming 
isolated mode. If this occurs at runtime - other than at startup - it could 
cause a pseudo-network-partition, see SLING-3432. Consider increasing 
heartbeatTimeout then!
13.01.2015 12:03:58 *INFO * [main] HeartbeatHandler: doCheckView: votingHandler 
is null!
13.01.2015 12:03:58 *INFO * [main] Instance: Instance 
[de74b83b-c913-40b0-a958-eba71d12a867] issues a heartbeat now Tue Jan 13 
12:03:58 UTC 2015
13.01.2015 12:03:59 *INFO * [main] HeartbeatHandler: doCheckView: votingHandler 
is null!
13.01.2015 12:03:59 *INFO * [main] Instance: Instance 
[64d74699-661e-42aa-be7f-076c93773326] issues a heartbeat now Tue Jan 13 
12:03:59 UTC 2015
13.01.2015 12:03:59 *INFO * [pool-1-thread-3] HeartbeatHandler: doCheckView: 
votingHandler is null!
13.01.2015 12:03:59 *INFO * [main] ClusterViewServiceImpl: getEstablishedView: 
the existing established view does not incude the local instance yet! Assuming 
isolated m

Re: [VOTE] Release Apache Sling Installer Core 3.6.2

2015-01-13 Thread Antonio Sanso
+1

On Jan 13, 2015, at 9:25 AM, Carsten Ziegeler  wrote:

> Hi,
> 
> the 3.6.0 release has unfortunately a nasty bug which is fixed with this
> release:
> https://issues.apache.org/jira/browse/SLING/fixforversion/12329251/
> 
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-1166/
> 
> 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 1166 /tmp/sling-staging
> 
> Please vote to approve this release:
> 
>  [ ] +1 Approve the release
>  [ ]  0 Don't care
>  [ ] -1 Don't release, because ...
> 
> This majority vote is open for at least 72 hours.
> 
> Regards
> Carsten
> -- 
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org



Re: VOTE] Release Apache Sling Resource Resolver 1.1.10

2015-01-13 Thread Antonio Sanso
+1
On Jan 13, 2015, at 2:30 PM, Antonio Sanso  wrote:

> Hi,
> 
> We solved 4 issues in this release:
> https://issues.apache.org/jira/browse/SLING/fixforversion/12329053
> 
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-1167/
> 
> 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 1167 /tmp/sling-staging
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ]  0 Don't care
> [ ] -1 Don't release, because ...
> 
> This majority vote is open for at least 72 hours.



Re: [VOTE] Release Apache Sling i18n 2.3.2

2015-01-13 Thread Antonio Sanso
+1
On Jan 13, 2015, at 9:29 AM, Carsten Ziegeler  wrote:

> Hi,
> 
> we cancelled the 2.3.0 release to fix an issue introduced in 2.2.8
> https://issues.apache.org/jira/browse/SLING-4299
> 
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-1165/
> 
> 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 1165 /tmp/sling-staging
> 
> Please vote to approve this release:
> 
>  [ ] +1 Approve the release
>  [ ]  0 Don't care
>  [ ] -1 Don't release, because ...
> 
> This majority vote is open for at least 72 hours.
> 
> Regards
> Carsten--
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org



VOTE] Release Apache Sling Resource Resolver 1.1.10

2015-01-13 Thread Antonio Sanso
Hi,

We solved 4 issues in this release:
https://issues.apache.org/jira/browse/SLING/fixforversion/12329053

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

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 1167 /tmp/sling-staging

Please vote to approve this release:

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

This majority vote is open for at least 72 hours.


Jenkins build is back to stable : sling-trunk-1.6 #2933

2015-01-13 Thread Apache Jenkins Server
See 



Jenkins build became unstable: sling-trunk-1.8 #607

2015-01-13 Thread Apache Jenkins Server
See 



Jenkins build is back to stable : sling-trunk-1.7 #1314

2015-01-13 Thread Apache Jenkins Server
See 



Re: [SLING-4275] API: RenderContext Object Traversal

2015-01-13 Thread Radu Cotescu
However, I just realised that those methods need to be accessible outside
of the o.a.s.s.sightly bundle for people who implement RuntimeExtensions.

On Tue, Jan 13, 2015 at 12:54 PM, Carsten Ziegeler 
wrote:

> Am 13.01.15 um 10:03 schrieb Radu Cotescu:
> > Hi,
> >
> > We could extract those methods into a utility class.
>
> I would prefer that, but on the other hand if its just me... :)
>
> Carsten
>
> >
> > Cheers,
> > Radu
> >
> > On Mon, Jan 12, 2015 at 1:45 PM, Carsten Ziegeler 
> > wrote:
> >
> >> Am 12.01.15 um 10:44 schrieb Felix Meschberger:
> >>> Hi all
> >>>
> >>> Carsten started to review the Sightly Engine API in SLING-4275 [1].
> >> Since this issue covers 4 topics, I think it would be best to quickly
> >> discuss these topic in separate threads.
> >>>
> >>> #4 RenderContext Object Traversal
> >>>
> >>> The Sightly Engine provides functionality for extensions to
> >> transparently travers object hierarchies to implement Sightly
> Expressions.
> >>>
> >>> The methods to do so are currently exposed in the RenderContext object
> >> which is created for each evaluation of a Sightly Template/Script.
> >>>
> >>> Question is whether we should expose this traversal functionality as a
> >> service. As such this traversal would be „globally applicable“ and could
> >> not be adapted to each call. Also extensions would have another
> reference
> >> to a service.
> >>>
> >>
> >> We also have the option to make an utility class out of it. I think this
> >> stuff has general purpose and the RenderContext class itself is not
> >> really the right place for it.
> >>
> >> The least we should do is move this to a separate interface and have a
> >> getXYZ method in the RenderContext to avoid bloating of that
> >> RenderContext interface with utility stuff.
> >>
> >> Carsten
> >> --
> >> Carsten Ziegeler
> >> Adobe Research Switzerland
> >> cziege...@apache.org
> >>
> >
>
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org
>


Re: [SLING-4275] API: ResourceResolution helper

2015-01-13 Thread Carsten Ziegeler
Am 13.01.15 um 09:11 schrieb Radu Cotescu:
> Hi,
> 
> The ResourceResolution class provides helper methods for resource
> resolution which are not available directly from the ResourceResolver /
> ResourceUtil classes. The most important one,  albeit named poorly,
> is 
> org.apache.sling.scripting.sightly.ResourceResolution#resolveComponentRelative,
> which handles resource inheritance chains.

Alright, so what about doing the renaming/javadoc update first and then
see where to put it?

Carsten

> 
> I would argue that their use is more general than just scripting and that
> the Sling API would be the correct place for them. However, I also don't
> like the fact that we'd have to depend on a newer Sling API version in
> Sightly.
> 
> Regards,
> Radu
> 
> On Mon, Jan 12, 2015 at 1:43 PM, Carsten Ziegeler 
> wrote:
> 
>> Am 12.01.15 um 10:44 schrieb Felix Meschberger:
>>> Hi all
>>>
>>> Carsten started to review the Sightly Engine API in SLING-4275 [1].
>> Since this issue covers 4 topics, I think it would be best to quickly
>> discuss these topic in separate threads.
>>>
>>> #5 ResourceResolution helper
>>>
>>> The ResourceResolution helper kind of duplicates and/or extends
>> functionality attributable to Script and Servlet Resolution.
>>>
>>> The question is whether we want to move this API to the Sling API at the
>> expense of increasing the respective API package version and thus requiring
>> an update to other bundles just to cope with this extended methods …
>>>
>>> (This actually blends into another discussion we should be having on the
>> evolution of the Sling API itself: Whenever we update something in the
>> Sling API, it has a potential dramatic ripple-down effect to other bundles.
>> Lets not discuss this here and now, though)
>>>
>> If this API is of general (scripting) use, we should put it into a
>> common place; if it's just for scripting we have the scripting api; if
>> it's more general, I think Sling API is the place.
>>
>>
>> Carsten
>> --
>> Carsten Ziegeler
>> Adobe Research Switzerland
>> cziege...@apache.org
>>
> 


-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org


Re: [SLING-4275] API: RenderContext Object Traversal

2015-01-13 Thread Carsten Ziegeler
Am 13.01.15 um 10:03 schrieb Radu Cotescu:
> Hi,
> 
> We could extract those methods into a utility class.

I would prefer that, but on the other hand if its just me... :)

Carsten

> 
> Cheers,
> Radu
> 
> On Mon, Jan 12, 2015 at 1:45 PM, Carsten Ziegeler 
> wrote:
> 
>> Am 12.01.15 um 10:44 schrieb Felix Meschberger:
>>> Hi all
>>>
>>> Carsten started to review the Sightly Engine API in SLING-4275 [1].
>> Since this issue covers 4 topics, I think it would be best to quickly
>> discuss these topic in separate threads.
>>>
>>> #4 RenderContext Object Traversal
>>>
>>> The Sightly Engine provides functionality for extensions to
>> transparently travers object hierarchies to implement Sightly Expressions.
>>>
>>> The methods to do so are currently exposed in the RenderContext object
>> which is created for each evaluation of a Sightly Template/Script.
>>>
>>> Question is whether we should expose this traversal functionality as a
>> service. As such this traversal would be „globally applicable“ and could
>> not be adapted to each call. Also extensions would have another reference
>> to a service.
>>>
>>
>> We also have the option to make an utility class out of it. I think this
>> stuff has general purpose and the RenderContext class itself is not
>> really the right place for it.
>>
>> The least we should do is move this to a separate interface and have a
>> getXYZ method in the RenderContext to avoid bloating of that
>> RenderContext interface with utility stuff.
>>
>> Carsten
>> --
>> Carsten Ziegeler
>> Adobe Research Switzerland
>> cziege...@apache.org
>>
> 


-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org


Jenkins build became unstable: sling-trunk-1.7 #1313

2015-01-13 Thread Apache Jenkins Server
See 



Jenkins build became unstable: sling-trunk-1.6 #2932

2015-01-13 Thread Apache Jenkins Server
See 



Re: [SLING-4275] API: Record Interface

2015-01-13 Thread Carsten Ziegeler
Can we at least rename the properties() method to getPropertyNames()

Carsten

Am 12.01.15 um 18:55 schrieb Radu Cotescu:
> Hi,
> 
> The Record interface is more complex. Besides being used in the JS Use
> Provider code for injecting global objects to the current bindings, the
> interface is also used to allow Sightly templates (defined through
> data-sly-template) to contain other templates (imbricated data-sly-template
> block elements).
> 
> Since Sightly templates are loaded through the Use API (e.g.  data-sly-use.tmplLibrary="/apps/myproj/components/templates.html">...),
> templates become objects in a Sightly script. Templates embedded in another
> template become properties of the main template object. The Record
> interface provides this flexibility.
> 
> HTH,
> Radu
> 
> On Mon, Jan 12, 2015 at 11:44 AM, Felix Meschberger 
> wrote:
> 
>> Hi all
>>
>> Carsten started to review the Sightly Engine API in SLING-4275 [1]. Since
>> this issue covers 4 topics, I think it would be best to quickly discuss
>> these topic in separate threads.
>>
>> #3 Record Interface
>>
>> The Record interface is used primarily by the Java POJO UseProvider to
>> inject properties back into the Sightly template bindings: If the object
>> loaded by the provider happens to implement the Record interface, the
>> respective properties are injected into the current bindings.
>>
>> The Question is whether this interface is specific to the Java POJO
>> UseProvider or not ?
>>
>> If it is specific, it should probably be moved into a pojo sub package.
>>
>> WDYT ?
>>
>> Regards
>> Felix
>>
>> [1] https://issues.apache.org/jira/browse/SLING-4275
> 


-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org


Re: [VOTE] Release Apache Sling Installer Core 3.6.2

2015-01-13 Thread Carsten Ziegeler
+1

Carsten

Am 13.01.15 um 09:25 schrieb Carsten Ziegeler:
> Hi,
> 
> the 3.6.0 release has unfortunately a nasty bug which is fixed with this
> release:
> https://issues.apache.org/jira/browse/SLING/fixforversion/12329251/
> 
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-1166/
> 
> 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 1166 /tmp/sling-staging
> 
> Please vote to approve this release:
> 
>   [ ] +1 Approve the release
>   [ ]  0 Don't care
>   [ ] -1 Don't release, because ...
> 
> This majority vote is open for at least 72 hours.
> 
> Regards
> Carsten
> 


-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org


Re: [VOTE] Release Apache Sling i18n 2.3.2

2015-01-13 Thread Carsten Ziegeler
+1

Carsten

Am 13.01.15 um 09:29 schrieb Carsten Ziegeler:
> Hi,
> 
> we cancelled the 2.3.0 release to fix an issue introduced in 2.2.8
> https://issues.apache.org/jira/browse/SLING-4299
> 
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-1165/
> 
> 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 1165 /tmp/sling-staging
> 
> Please vote to approve this release:
> 
>   [ ] +1 Approve the release
>   [ ]  0 Don't care
>   [ ] -1 Don't release, because ...
> 
> This majority vote is open for at least 72 hours.
> 
> Regards
> Carsten--
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org
> 


-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org


[jira] [Commented] (SLING-1794) ConfigInstallTest fails semi-randomly: Configuration is still present

2015-01-13 Thread Carsten Ziegeler (JIRA)

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

Carsten Ziegeler commented on SLING-1794:
-

Actually I was wrong, it still occurs on Jenkins with Java7

> ConfigInstallTest fails semi-randomly: Configuration is still present
> -
>
> Key: SLING-1794
> URL: https://issues.apache.org/jira/browse/SLING-1794
> Project: Sling
>  Issue Type: Bug
>  Components: Installer
>Reporter: Andreas Kuckartz
>Assignee: Carsten Ziegeler
>  Labels: it,intermittent
> Attachments: stdio.txt
>
>
> ---
> Test set: org.apache.sling.installer.it.ConfigInstallTest
> ---
> Tests run: 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 17.044 sec 
> <<< FAILURE!
> testDeferredConfigInstall 
> [felix](org.apache.sling.installer.it.ConfigInstallTest)  Time elapsed: 
> 10.072 sec  <<< FAILURE!
> java.lang.AssertionError: Config must be removed once ConfigurationAdmin 
> restarts: Configuration is still present 
> (ConfigInstallTest.deferred.1285097628299)
> at org.junit.Assert.fail(Assert.java:74)
> at 
> org.apache.sling.installer.it.OsgiInstallerTestBase.waitForConfiguration(OsgiInstallerTestBase.java:246)
> at 
> org.apache.sling.installer.it.ConfigInstallTest.testDeferredConfigInstall(ConfigInstallTest.java:149)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at 
> org.ops4j.pax.exam.junit.extender.impl.internal.CallableTestMethodImpl.injectContextAndInvoke(CallableTestMethodImpl.java:143)
> at 
> org.ops4j.pax.exam.junit.extender.impl.internal.CallableTestMethodImpl.call(CallableTestMethodImpl.java:105)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at 
> org.ops4j.pax.exam.rbc.internal.RemoteBundleContextImpl.remoteCall(RemoteBundleContextImpl.java:80)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:305)
> at sun.rmi.transport.Transport$1.run(Transport.java:159)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.rmi.transport.Transport.serviceCall(Transport.java:155)
> at 
> sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:535)
> at 
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:790)
> at 
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:649)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:619)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


Re: Servlet Filter Support adding sling.filter.pattern support

2015-01-13 Thread Antonio Sanso
hi *,

I have tracked the issue and added a straw man patch in 
https://issues.apache.org/jira/browse/SLING-4294

WDYT?

regards

antonio

On Dec 5, 2014, at 12:00 PM, Felix Meschberger  wrote:

> Hi
> 
> The point is that we should implement what we need and ignore what we don’t 
> need.
> 
> For some use cases it would indeed be good to be simply able to filter on the 
> URL path (or resource path) like in the Servlet API itself. Consider for 
> example a content management system where you want to apply a filter to all 
> requests to user generated content which might live at /content/public.
> 
> For other cases, being able to filter on a resource type is more appropriate. 
> Again, consider a content management system and you want to apply the filter 
> to all requests for web page resources of resource type cms/webpage.
> 
> Then there is a combination even, where you might have resources spread all 
> over but you want to apply the filter only to, say, web pages in user 
> generated content, so you filter on the /content/public location further 
> finer graining it to cms/webpage.
> 
> These could be use cases. Do we need it ? I don’t know. For SLING-3829 it 
> would be use full to have it.
> 
> Regards
> Felix
> 
>> Am 05.12.2014 um 11:07 schrieb Antonio Sanso :
>> 
>> hi Julian
>> 
>> On Dec 5, 2014, at 10:31 AM, Julian Sedding  wrote:
>> 
>>> Hi Antonio
>>> 
>>> I agree with Justin that we should start with support for resource-types.
>> 
>> as said I agree we should have support for both.
>> E.g. sling.filter.pattern, sling.filter.resourceType
>> 
>> 
>>> 
>>> Using path-based restrictions strongly couples configuration to
>>> content, which IMO is not a good practice.
>> 
>> At the end of the day is the developer choice to choose the one she needs.
>> In my case for example I cannot use the resource type approach.
>> See also https://issues.apache.org/jira/browse/SLING-3829
>> 
>> regards
>> 
>> antonio
>> 
>>> 
>>> Regards
>>> Julian
>>> 
>>> 
>>> On Thu, Dec 4, 2014 at 3:54 PM, Antonio Sanso  wrote:
 thanks Justin for your feedback,
 
 if you would not mind I would try to do the opposite :)
 The only reason is that I have already a Pocs for this that it actually 
 requires really few modifications.. (Felix gave me some good hints on how 
 to implement it :))
 It would probably be the same for resource type though :)
 
 regards
 
 antonio
 
 On Dec 4, 2014, at 2:29 PM, Justin Edelson  
 wrote:
 
> Hi Antonio,
> I'd suggest starting with support for resource type and *then* add path 
> support.
> 
> Justin
> 
> On Thu, Dec 4, 2014 at 5:46 AM, Antonio Sanso  wrote:
>> hi *,
>> 
>> the current Sling Servlet Filter Support [0] allows to have scope 
>> dependent filter (e.g. REQUEST, INCLUDE, FORWARD, ERROR, COMPONENT).
>> It would be nice to extend this support to have a specific filter being 
>> taken in consideration only for specific path (adding 
>> sling.filter.pattern) a bit like what currently can be done for Apache 
>> Felix filters.
>> 
>> WDYT?
>> 
>> regards
>> 
>> antonio
>> 
>> [0] http://sling.apache.org/documentation/the-sling-engine/filters.html
 
>> 
> 



[jira] [Updated] (SLING-4294) Servlet Filter Support adding sling.filter.pattern support

2015-01-13 Thread Antonio Sanso (JIRA)

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

Antonio Sanso updated SLING-4294:
-
Attachment: SLING-4294-patch.txt

added straw man patch

> Servlet Filter Support adding sling.filter.pattern support
> --
>
> Key: SLING-4294
> URL: https://issues.apache.org/jira/browse/SLING-4294
> Project: Sling
>  Issue Type: Improvement
>  Components: Engine
>Reporter: Antonio Sanso
>Assignee: Antonio Sanso
> Attachments: SLING-4294-patch.txt
>
>
> the current Sling Servlet Filter Support [0] allows to have scope dependent 
> filter (e.g. REQUEST, INCLUDE, FORWARD, ERROR, COMPONENT).
> It would be nice to extend this support to have a specific filter being taken 
> in consideration only for specific path (adding sling.filter.pattern) a bit 
> like what currently can be done for Apache Felix filters.
> mailing list discussion in [1] 
> [0] http://sling.apache.org/documentation/the-sling-engine/filters.html
> [1] http://markmail.org/message/lzp7qcienk3blwpk



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


Jenkins build is back to stable : sling-trunk-1.7 #1312

2015-01-13 Thread Apache Jenkins Server
See 



[jira] [Commented] (SLING-4298) make BufferedServletOutputStream and CaptureResponseWrapper available to other scripting implementations

2015-01-13 Thread Oliver Lietz (JIRA)

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

Oliver Lietz commented on SLING-4298:
-

Sling's Scripting API only relates to Java Scripting API ({{javax.script}}) and 
doesn't depend on Servlet API ({{javax.servlet}}) - so Scripting Core seemed to 
be a better place

> make BufferedServletOutputStream and CaptureResponseWrapper available to 
> other scripting implementations
> 
>
> Key: SLING-4298
> URL: https://issues.apache.org/jira/browse/SLING-4298
> Project: Sling
>  Issue Type: Improvement
>  Components: Scripting
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
> Fix For: Scripting Core 2.0.30, Scripting JSP-Taglib 2.2.6
>
>
> move private (inner) classes {{BufferedServletOutputStream}} and 
> {{CaptureResponseWrapper}} 
> ({{org.apache.sling.scripting.jsp.taglib.IncludeTagHandler}}) from _Scripting 
> JSP Taglib_ to _Scripting Core_



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Issue Comment Deleted] (SLING-4298) make BufferedServletOutputStream and CaptureResponseWrapper available to other scripting implementations

2015-01-13 Thread Oliver Lietz (JIRA)

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

Oliver Lietz updated SLING-4298:

Comment: was deleted

(was: Sling's Scripting API only relates to Java Scripting API 
({{javax.script}}) and doesn't depend on Servlet API ({{javax.servlet}}) - so 
Scripting Core seemed to be a better place)

> make BufferedServletOutputStream and CaptureResponseWrapper available to 
> other scripting implementations
> 
>
> Key: SLING-4298
> URL: https://issues.apache.org/jira/browse/SLING-4298
> Project: Sling
>  Issue Type: Improvement
>  Components: Scripting
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
> Fix For: Scripting Core 2.0.30, Scripting JSP-Taglib 2.2.6
>
>
> move private (inner) classes {{BufferedServletOutputStream}} and 
> {{CaptureResponseWrapper}} 
> ({{org.apache.sling.scripting.jsp.taglib.IncludeTagHandler}}) from _Scripting 
> JSP Taglib_ to _Scripting Core_



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (SLING-4298) make BufferedServletOutputStream and CaptureResponseWrapper available to other scripting implementations

2015-01-13 Thread Oliver Lietz (JIRA)

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

Oliver Lietz commented on SLING-4298:
-

Sling's Scripting API only relates to Java Scripting API ({{javax.script}}) and 
doesn't depend on Servlet API ({{javax.servlet}}) - so Scripting Core seemed to 
be a better place

> make BufferedServletOutputStream and CaptureResponseWrapper available to 
> other scripting implementations
> 
>
> Key: SLING-4298
> URL: https://issues.apache.org/jira/browse/SLING-4298
> Project: Sling
>  Issue Type: Improvement
>  Components: Scripting
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
> Fix For: Scripting Core 2.0.30, Scripting JSP-Taglib 2.2.6
>
>
> move private (inner) classes {{BufferedServletOutputStream}} and 
> {{CaptureResponseWrapper}} 
> ({{org.apache.sling.scripting.jsp.taglib.IncludeTagHandler}}) from _Scripting 
> JSP Taglib_ to _Scripting Core_



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


Re: [SLING-4275] API: RenderContext Object Traversal

2015-01-13 Thread Radu Cotescu
Hi,

We could extract those methods into a utility class.

Cheers,
Radu

On Mon, Jan 12, 2015 at 1:45 PM, Carsten Ziegeler 
wrote:

> Am 12.01.15 um 10:44 schrieb Felix Meschberger:
> > Hi all
> >
> > Carsten started to review the Sightly Engine API in SLING-4275 [1].
> Since this issue covers 4 topics, I think it would be best to quickly
> discuss these topic in separate threads.
> >
> > #4 RenderContext Object Traversal
> >
> > The Sightly Engine provides functionality for extensions to
> transparently travers object hierarchies to implement Sightly Expressions.
> >
> > The methods to do so are currently exposed in the RenderContext object
> which is created for each evaluation of a Sightly Template/Script.
> >
> > Question is whether we should expose this traversal functionality as a
> service. As such this traversal would be „globally applicable“ and could
> not be adapted to each call. Also extensions would have another reference
> to a service.
> >
>
> We also have the option to make an utility class out of it. I think this
> stuff has general purpose and the RenderContext class itself is not
> really the right place for it.
>
> The least we should do is move this to a separate interface and have a
> getXYZ method in the RenderContext to avoid bloating of that
> RenderContext interface with utility stuff.
>
> Carsten
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org
>


[jira] [Reopened] (SLING-1794) ConfigInstallTest fails semi-randomly: Configuration is still present

2015-01-13 Thread Carsten Ziegeler (JIRA)

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

Carsten Ziegeler reopened SLING-1794:
-

> ConfigInstallTest fails semi-randomly: Configuration is still present
> -
>
> Key: SLING-1794
> URL: https://issues.apache.org/jira/browse/SLING-1794
> Project: Sling
>  Issue Type: Bug
>  Components: Installer
>Reporter: Andreas Kuckartz
>Assignee: Carsten Ziegeler
>  Labels: it,intermittent
> Attachments: stdio.txt
>
>
> ---
> Test set: org.apache.sling.installer.it.ConfigInstallTest
> ---
> Tests run: 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 17.044 sec 
> <<< FAILURE!
> testDeferredConfigInstall 
> [felix](org.apache.sling.installer.it.ConfigInstallTest)  Time elapsed: 
> 10.072 sec  <<< FAILURE!
> java.lang.AssertionError: Config must be removed once ConfigurationAdmin 
> restarts: Configuration is still present 
> (ConfigInstallTest.deferred.1285097628299)
> at org.junit.Assert.fail(Assert.java:74)
> at 
> org.apache.sling.installer.it.OsgiInstallerTestBase.waitForConfiguration(OsgiInstallerTestBase.java:246)
> at 
> org.apache.sling.installer.it.ConfigInstallTest.testDeferredConfigInstall(ConfigInstallTest.java:149)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at 
> org.ops4j.pax.exam.junit.extender.impl.internal.CallableTestMethodImpl.injectContextAndInvoke(CallableTestMethodImpl.java:143)
> at 
> org.ops4j.pax.exam.junit.extender.impl.internal.CallableTestMethodImpl.call(CallableTestMethodImpl.java:105)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at 
> org.ops4j.pax.exam.rbc.internal.RemoteBundleContextImpl.remoteCall(RemoteBundleContextImpl.java:80)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:305)
> at sun.rmi.transport.Transport$1.run(Transport.java:159)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.rmi.transport.Transport.serviceCall(Transport.java:155)
> at 
> sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:535)
> at 
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:790)
> at 
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:649)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:619)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (SLING-1794) ConfigInstallTest fails semi-randomly: Configuration is still present

2015-01-13 Thread Carsten Ziegeler (JIRA)

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

Carsten Ziegeler updated SLING-1794:

Fix Version/s: (was: Installer Core 3.6.2)

> ConfigInstallTest fails semi-randomly: Configuration is still present
> -
>
> Key: SLING-1794
> URL: https://issues.apache.org/jira/browse/SLING-1794
> Project: Sling
>  Issue Type: Bug
>  Components: Installer
>Reporter: Andreas Kuckartz
>Assignee: Carsten Ziegeler
>  Labels: it,intermittent
> Attachments: stdio.txt
>
>
> ---
> Test set: org.apache.sling.installer.it.ConfigInstallTest
> ---
> Tests run: 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 17.044 sec 
> <<< FAILURE!
> testDeferredConfigInstall 
> [felix](org.apache.sling.installer.it.ConfigInstallTest)  Time elapsed: 
> 10.072 sec  <<< FAILURE!
> java.lang.AssertionError: Config must be removed once ConfigurationAdmin 
> restarts: Configuration is still present 
> (ConfigInstallTest.deferred.1285097628299)
> at org.junit.Assert.fail(Assert.java:74)
> at 
> org.apache.sling.installer.it.OsgiInstallerTestBase.waitForConfiguration(OsgiInstallerTestBase.java:246)
> at 
> org.apache.sling.installer.it.ConfigInstallTest.testDeferredConfigInstall(ConfigInstallTest.java:149)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at 
> org.ops4j.pax.exam.junit.extender.impl.internal.CallableTestMethodImpl.injectContextAndInvoke(CallableTestMethodImpl.java:143)
> at 
> org.ops4j.pax.exam.junit.extender.impl.internal.CallableTestMethodImpl.call(CallableTestMethodImpl.java:105)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at 
> org.ops4j.pax.exam.rbc.internal.RemoteBundleContextImpl.remoteCall(RemoteBundleContextImpl.java:80)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:305)
> at sun.rmi.transport.Transport$1.run(Transport.java:159)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.rmi.transport.Transport.serviceCall(Transport.java:155)
> at 
> sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:535)
> at 
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:790)
> at 
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:649)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:619)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[VOTE] Release Apache Sling i18n 2.3.2

2015-01-13 Thread Carsten Ziegeler
Hi,

we cancelled the 2.3.0 release to fix an issue introduced in 2.2.8
https://issues.apache.org/jira/browse/SLING-4299

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

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 1165 /tmp/sling-staging

Please vote to approve this release:

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

This majority vote is open for at least 72 hours.

Regards
Carsten--
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org


Jenkins build is still unstable: sling-trunk-1.7 #1311

2015-01-13 Thread Apache Jenkins Server
See 



[VOTE] Release Apache Sling Installer Core 3.6.2

2015-01-13 Thread Carsten Ziegeler
Hi,

the 3.6.0 release has unfortunately a nasty bug which is fixed with this
release:
https://issues.apache.org/jira/browse/SLING/fixforversion/12329251/

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

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 1166 /tmp/sling-staging

Please vote to approve this release:

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

This majority vote is open for at least 72 hours.

Regards
Carsten
-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org


Re: [SLING-4275] API: ResourceResolution helper

2015-01-13 Thread Chetan Mehrotra
On Tue, Jan 13, 2015 at 1:41 PM, Radu Cotescu  wrote:
> However, I also don't
> like the fact that we'd have to depend on a newer Sling API version in
> Sightly.

Another option which can be looked into would be to add the new
methods in Sling API and then embed/inline that class within Sightly.
This assumes that added class is self sufficient and not dependent on
other class

Chetan Mehrotra


Re: [SLING-4275] API: ResourceResolution helper

2015-01-13 Thread Radu Cotescu
Hi,

The ResourceResolution class provides helper methods for resource
resolution which are not available directly from the ResourceResolver /
ResourceUtil classes. The most important one,  albeit named poorly,
is 
org.apache.sling.scripting.sightly.ResourceResolution#resolveComponentRelative,
which handles resource inheritance chains.

I would argue that their use is more general than just scripting and that
the Sling API would be the correct place for them. However, I also don't
like the fact that we'd have to depend on a newer Sling API version in
Sightly.

Regards,
Radu

On Mon, Jan 12, 2015 at 1:43 PM, Carsten Ziegeler 
wrote:

> Am 12.01.15 um 10:44 schrieb Felix Meschberger:
> > Hi all
> >
> > Carsten started to review the Sightly Engine API in SLING-4275 [1].
> Since this issue covers 4 topics, I think it would be best to quickly
> discuss these topic in separate threads.
> >
> > #5 ResourceResolution helper
> >
> > The ResourceResolution helper kind of duplicates and/or extends
> functionality attributable to Script and Servlet Resolution.
> >
> > The question is whether we want to move this API to the Sling API at the
> expense of increasing the respective API package version and thus requiring
> an update to other bundles just to cope with this extended methods …
> >
> > (This actually blends into another discussion we should be having on the
> evolution of the Sling API itself: Whenever we update something in the
> Sling API, it has a potential dramatic ripple-down effect to other bundles.
> Lets not discuss this here and now, though)
> >
> If this API is of general (scripting) use, we should put it into a
> common place; if it's just for scripting we have the scripting api; if
> it's more general, I think Sling API is the place.
>
>
> Carsten
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org
>


[jira] [Resolved] (SLING-1794) ConfigInstallTest fails semi-randomly: Configuration is still present

2015-01-13 Thread Carsten Ziegeler (JIRA)

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

Carsten Ziegeler resolved SLING-1794.
-
Resolution: Fixed

It seems this is fixed now

> ConfigInstallTest fails semi-randomly: Configuration is still present
> -
>
> Key: SLING-1794
> URL: https://issues.apache.org/jira/browse/SLING-1794
> Project: Sling
>  Issue Type: Bug
>  Components: Installer
>Reporter: Andreas Kuckartz
>Assignee: Carsten Ziegeler
>  Labels: it,intermittent
> Fix For: Installer Core 3.6.2
>
> Attachments: stdio.txt
>
>
> ---
> Test set: org.apache.sling.installer.it.ConfigInstallTest
> ---
> Tests run: 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 17.044 sec 
> <<< FAILURE!
> testDeferredConfigInstall 
> [felix](org.apache.sling.installer.it.ConfigInstallTest)  Time elapsed: 
> 10.072 sec  <<< FAILURE!
> java.lang.AssertionError: Config must be removed once ConfigurationAdmin 
> restarts: Configuration is still present 
> (ConfigInstallTest.deferred.1285097628299)
> at org.junit.Assert.fail(Assert.java:74)
> at 
> org.apache.sling.installer.it.OsgiInstallerTestBase.waitForConfiguration(OsgiInstallerTestBase.java:246)
> at 
> org.apache.sling.installer.it.ConfigInstallTest.testDeferredConfigInstall(ConfigInstallTest.java:149)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at 
> org.ops4j.pax.exam.junit.extender.impl.internal.CallableTestMethodImpl.injectContextAndInvoke(CallableTestMethodImpl.java:143)
> at 
> org.ops4j.pax.exam.junit.extender.impl.internal.CallableTestMethodImpl.call(CallableTestMethodImpl.java:105)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at 
> org.ops4j.pax.exam.rbc.internal.RemoteBundleContextImpl.remoteCall(RemoteBundleContextImpl.java:80)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:305)
> at sun.rmi.transport.Transport$1.run(Transport.java:159)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.rmi.transport.Transport.serviceCall(Transport.java:155)
> at 
> sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:535)
> at 
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:790)
> at 
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:649)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:619)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


Jenkins build is back to normal : sling-trunk-1.6 #2931

2015-01-13 Thread Apache Jenkins Server
See