Clarification of Resource#getResourceSuperType() contract

[Julian Sedding]

Hello all

I stumbled over a behavior in Resource#getResourceSuperType() that is
unexpected to me. I would like to clarify the contract of this method.

The JavaDoc for Resource#getResourceSuperType() states "Returns the
super type of the type of the resource or null if the
getResourceType() has no supertype.". I'll illustrate my understanding
of this contract with a simple example.

/content/resource [sling:resourceType="type"]
/apps/type [sling:resourceSuperType="super"]
/apps/super

Now if I have an instance of the Resource at /content/resource and
call ist getResourceSuperType() method, I'd expect to get the string
"super" as the return value ("the super type of the type of the
resource").

However, the JcrNodeResource[0], and possibly more importantly its
test cases[1] (specifically testResourceSuperType()), implement a
behavior that differs from my understanding of the documented
contract. In the above scenario,
JcrNodeResource#getResourceSuperType() would return null, while the
scenario below would yield "super".

/content/resource [sling:resourceType="type", sling:resourceSuperType="super"]
/apps/type
/apps/super

To me the documented contract is more intuitive, as that is how
inheritance generally works in my experience (i.e. my grandmother can
only be my grandmother transiently via one of my parents). However,
I'm curious to see whether others have other opinions.

BTW, MongoDBResource#getResourceSuperType() seems to implement the
same contract that JcrNodeResource does. Additionally, also
ResourceUtil#findResourceSuperType() supports the logic implemented in
JcrNodeResource.

I noticed this while implementing a possible fix for SLING-2708, which
is concerned with the ResourceUtil#isA() and Resource#isResourceType()
methods. Depending on the implementation of those methods (whether
they rely on Resource#getResourceSuperType() or not), they may yield
different results.

Thank you for your comments.

Regards
Julian


[0] 
http://svn.apache.org/repos/asf/sling/tags/org.apache.sling.jcr.resource-2.2.0/src/main/java/org/apache/sling/jcr/resource/internal/helper/jcr/JcrNodeResource.java
[1] 
http://svn.apache.org/repos/asf/sling/tags/org.apache.sling.jcr.resource-2.2.0/src/test/java/org/apache/sling/jcr/resource/internal/helper/jcr/JcrNodeResourceTest.java

Re: Clarification of Resource#getResourceSuperType() contract

[Carsten Ziegeler]

Hi,

I agree we have a mismatch here. The way we usually handle
getResourceSuperType and how it is implemented is, that it returns a
super type information only if the resource by itself has set this
(for example for a jcr node if it has the property). The method does
not evaluate the resource hierarchy.
As far as I remember (this dates really long way back...) the idea is,
that a resource can either specify a super type by itself - using this
method or if it doesn't, the super type is evaluated using the type
hierarchy from the resource tree. This allows for overriding the
resource super type on a per resource base.

However, I agree that this is a little bit unexpected - so I think we
should update the javadocs of the Resource interface to reflect
realitity.
We could add a method to get the real super type like we have for the isA check.

WDYT?

Carsten

2013/2/11 Julian Sedding :
> Hello all
>
> I stumbled over a behavior in Resource#getResourceSuperType() that is
> unexpected to me. I would like to clarify the contract of this method.
>
> The JavaDoc for Resource#getResourceSuperType() states "Returns the
> super type of the type of the resource or null if the
> getResourceType() has no supertype.". I'll illustrate my understanding
> of this contract with a simple example.
>
> /content/resource [sling:resourceType="type"]
> /apps/type [sling:resourceSuperType="super"]
> /apps/super
>
> Now if I have an instance of the Resource at /content/resource and
> call ist getResourceSuperType() method, I'd expect to get the string
> "super" as the return value ("the super type of the type of the
> resource").
>
> However, the JcrNodeResource[0], and possibly more importantly its
> test cases[1] (specifically testResourceSuperType()), implement a
> behavior that differs from my understanding of the documented
> contract. In the above scenario,
> JcrNodeResource#getResourceSuperType() would return null, while the
> scenario below would yield "super".
>
> /content/resource [sling:resourceType="type", sling:resourceSuperType="super"]
> /apps/type
> /apps/super
>
> To me the documented contract is more intuitive, as that is how
> inheritance generally works in my experience (i.e. my grandmother can
> only be my grandmother transiently via one of my parents). However,
> I'm curious to see whether others have other opinions.
>
> BTW, MongoDBResource#getResourceSuperType() seems to implement the
> same contract that JcrNodeResource does. Additionally, also
> ResourceUtil#findResourceSuperType() supports the logic implemented in
> JcrNodeResource.
>
> I noticed this while implementing a possible fix for SLING-2708, which
> is concerned with the ResourceUtil#isA() and Resource#isResourceType()
> methods. Depending on the implementation of those methods (whether
> they rely on Resource#getResourceSuperType() or not), they may yield
> different results.
>
> Thank you for your comments.
>
> Regards
> Julian
>
>
> [0] 
> http://svn.apache.org/repos/asf/sling/tags/org.apache.sling.jcr.resource-2.2.0/src/main/java/org/apache/sling/jcr/resource/internal/helper/jcr/JcrNodeResource.java
> [1] 
> http://svn.apache.org/repos/asf/sling/tags/org.apache.sling.jcr.resource-2.2.0/src/test/java/org/apache/sling/jcr/resource/internal/helper/jcr/JcrNodeResourceTest.java



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

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

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-2726:
-

I think this would be a little bit against the general principles of Sling 
where we a request is targeting a resource and once the resource is found in 
the tree, a script is called to generate the response for this resource. Sure, 
right now we have this mechanism which allows you to mount a servlet at some 
specific path, but this servlet is mounted as a resource into the resource tree 
and it returns the correct resource type so the servlet is then also picked by 
the script resolution. So, although a little bit stretched, the resource 
resolution mechanism and rendering still works following the basic principles.
If we would allow a Sling servlet to be mounted through a wild card, this would 
get more blurry.
So I think, if you want to represent your data (profiles) as resources, a 
resource provider is the way to go; it's very simple to implement.
Another option would be to register your servlet outside of Sling directly with 
the http service. I think it depends on the exact use case which way is the 
better one

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

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

Re: Clarification of Resource#getResourceSuperType() contract

[Julian Sedding]

Hi Carsten

Thanks for your comments.

> This allows for overriding the
> resource super type on a per resource base.

When you say overriding, do you mean, it eliminates an inherited
resource type, or is it squeezed in between? Example:

/content/resource [sling:resourceType="type",
sling:resourceSuperType="local-super"]
/apps/type [sling:resourceSuperType="inherited-super"]
/apps/local-super [sling:resourceSuperType="local-super-super"]
/apps/inherited-super [sling:resourceSuperType="inherited-super-super"]

Which would be the "correct" inheritance hierarchy in this example?

Option A (eliminates inherited super-type): type, local-super, local-super-super
Option B (injects local super-type) : type, local-super,
inherited-super, inherited-super-super
Option C (injects local-super-type hierarchy: type, local-super,
local-super-super, inherited-super, inherited-super-super

Surely there are more possible options, however, I think these are the
most sensible ones. It might also be worthwhile considering, what
happens if the two hierarchies join back on a common ancestor...

> However, I agree that this is a little bit unexpected - so I think we
> should update the javadocs of the Resource interface to reflect
> realitity.
> We could add a method to get the real super type like we have for the isA 
> check.

I think we need to keep the override-mechanism due to backwards
compatibility, so adjusting the JavaDocs seems sensible. However, I
would like to document that a local sling:resourceSuperType property
overrides the default behavior, which is the traversal of the
inheritance-hierarchy (as is currently documented). In addition, if we
decide for one of the above options, this should also be documented.
This would allow using only the expected/intuitive case (i.e. not to
use any local overrides). At the same time this should provide a
backwards compatible solution.

WDYT?

Regards
Julian


On Mon, Feb 11, 2013 at 9:44 AM, Carsten Ziegeler  wrote:
> Hi,
>
> I agree we have a mismatch here. The way we usually handle
> getResourceSuperType and how it is implemented is, that it returns a
> super type information only if the resource by itself has set this
> (for example for a jcr node if it has the property). The method does
> not evaluate the resource hierarchy.
> As far as I remember (this dates really long way back...) the idea is,
> that a resource can either specify a super type by itself - using this
> method or if it doesn't, the super type is evaluated using the type
> hierarchy from the resource tree. This allows for overriding the
> resource super type on a per resource base.
>
> However, I agree that this is a little bit unexpected - so I think we
> should update the javadocs of the Resource interface to reflect
> realitity.
> We could add a method to get the real super type like we have for the isA 
> check.
>
> WDYT?
>
> Carsten
>
> 2013/2/11 Julian Sedding :
>> Hello all
>>
>> I stumbled over a behavior in Resource#getResourceSuperType() that is
>> unexpected to me. I would like to clarify the contract of this method.
>>
>> The JavaDoc for Resource#getResourceSuperType() states "Returns the
>> super type of the type of the resource or null if the
>> getResourceType() has no supertype.". I'll illustrate my understanding
>> of this contract with a simple example.
>>
>> /content/resource [sling:resourceType="type"]
>> /apps/type [sling:resourceSuperType="super"]
>> /apps/super
>>
>> Now if I have an instance of the Resource at /content/resource and
>> call ist getResourceSuperType() method, I'd expect to get the string
>> "super" as the return value ("the super type of the type of the
>> resource").
>>
>> However, the JcrNodeResource[0], and possibly more importantly its
>> test cases[1] (specifically testResourceSuperType()), implement a
>> behavior that differs from my understanding of the documented
>> contract. In the above scenario,
>> JcrNodeResource#getResourceSuperType() would return null, while the
>> scenario below would yield "super".
>>
>> /content/resource [sling:resourceType="type", 
>> sling:resourceSuperType="super"]
>> /apps/type
>> /apps/super
>>
>> To me the documented contract is more intuitive, as that is how
>> inheritance generally works in my experience (i.e. my grandmother can
>> only be my grandmother transiently via one of my parents). However,
>> I'm curious to see whether others have other opinions.
>>
>> BTW, MongoDBResource#getResourceSuperType() seems to implement the
>> same contract that JcrNodeResource does. Additionally, also
>> ResourceUtil#findResourceSuperType() supports the logic implemented in
>> JcrNodeResource.
>>
>> I noticed this while implementing a possible fix for SLING-2708, which
>> is concerned with the ResourceUtil#isA() and Resource#isResourceType()
>> methods. Depending on the implementation of those methods (whether
>> they rely on Resource#getResourceSuperType() or not), they may yield
>> different results.
>>
>> Thank you for your comments.
>>
>>

Patches needing review

[Robert Munteanu]

Hi,

I have submitted some patches which seem to have fallen under the radar. If 
that's an accident rather than intended, I'd appreciate if someone could take a 
look at them.

SLING-2720: Update exported versions for extension fragments to match 
well-known JAX-WS, JAXB, StAX and JAF versions
https://issues.apache.org/jira/browse/SLING-2720

SLING-2658: Document that the bundle list does not allow selection for the 
HttpService provider
https://issues.apache.org/jira/browse/SLING-2658

SLING-2721: Integration test for JAXB marhsalling
https://issues.apache.org/jira/browse/SLING-2721

Thanks!

Robert

[jira] [Updated] (SLING-2529) Add support for JCR Observation event types: NODE_MOVED and PERSIST

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler updated SLING-2529:


Fix Version/s: (was: JCR Resource 2.2.4)
   JCR Resource 2.2.6

> Add support for JCR Observation event types: NODE_MOVED and PERSIST
> ---
>
> Key: SLING-2529
> URL: https://issues.apache.org/jira/browse/SLING-2529
> Project: Sling
>  Issue Type: Improvement
>  Components: JCR
>Affects Versions: JCR Resource 2.1.0
>Reporter: Felix Meschberger
>Assignee: Felix Meschberger
> Fix For: JCR Resource 2.2.6
>
>
> The JcrResourceListener does not currently support two event types added in 
> the JCR 2.0 specification:
>   * NODE_MOVED
>   * PERSIST
> Particularly NODE_MOVED is an important event which we should support with a 
> properly mapped OSGi event.
> The PERSIST event might be useful in creating event group boundaries.

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

[jira] [Updated] (SLING-2698) Add a minimal resource access gate

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler updated SLING-2698:


Fix Version/s: (was: Resource Resolver 1.0.4)
   Resource Resolver 1.0.6

> Add a minimal resource access gate
> --
>
> Key: SLING-2698
> URL: https://issues.apache.org/jira/browse/SLING-2698
> Project: Sling
>  Issue Type: New Feature
>  Components: ResourceResolver
>Reporter: Mike Müller
>Assignee: Mike Müller
> Fix For: Resource Resolver 1.0.6
>
>
> Adding a minmal resource access gate as discussed in [1].
> First step is to define the API interface and a minimal implementation which 
> allows to define READ access (rest of CRUD can follow later)
> [1] http://markmail.org/thread/4ctczoiy533tquyl

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

[jira] [Updated] (SLING-2698) Add a minimal resource access gate

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler updated SLING-2698:


Component/s: ResourceResolver

> Add a minimal resource access gate
> --
>
> Key: SLING-2698
> URL: https://issues.apache.org/jira/browse/SLING-2698
> Project: Sling
>  Issue Type: New Feature
>  Components: ResourceResolver
>Reporter: Mike Müller
>Assignee: Mike Müller
> Fix For: Resource Resolver 1.0.4
>
>
> Adding a minmal resource access gate as discussed in [1].
> First step is to define the API interface and a minimal implementation which 
> allows to define READ access (rest of CRUD can follow later)
> [1] http://markmail.org/thread/4ctczoiy533tquyl

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

[VOTE RESULT] Drop Java 5 Support in General

[Carsten Ziegeler]

Hi,

thanks everyone - the vote to drop Java 5 support in general passed
with +1 votes: Justin Edelson, Mike Müller, Ian Boston, Felix
Meschberger, Jeff Young, Antonio, Sanso, Carsten Ziegeler, and
Bertrand Delacretaz.

I'll create an issue for this and update our parent pom with some support

Carsten

2013/1/31 Justin Edelson :
> +1
>
>
> On Thu, Jan 31, 2013 at 5:06 PM, Carsten Ziegeler wrote:
>
>> Deal
>>
>> Carsten
>>
>> 2013/1/31 Justin Edelson :
>> > Well again, I'm looking at Robert sending an email rather than just
>> > creating a patch.
>> >
>> > How about this - put this information (modules build against Java 5 by
>> > default, but feel free to change it by doing XYZ) in the root README.
>> >
>> > If no one asks about it again, then my concern will have been
>> unnecessary.
>> > If we get another email like Robert's asking for permission, then we
>> > revisit this.
>> >
>> > WDYT?
>> >
>> >
>> > On Thu, Jan 31, 2013 at 3:24 PM, Carsten Ziegeler > >wrote:
>> >
>> >> I don't see why this makes contributions harder: develop however you
>> >> want and contribute. The only minor thing is, as by default we still
>> >> target java 5 for a module and you use java 6, the build will fail,
>> >> you update the pom (a single property), build again and are happy. Not
>> >> really hard.
>> >>
>> >> But I don't want to be a road blocker here: if the majority thinks we
>> >> should not support Java 5 at all anymore, let's do it.
>> >>
>> >> Carsten
>> >>
>> >> 2013/1/31 Justin Edelson :
>> >> > I understand the use case, but it just seems like a hassle and makes
>> >> > potential contributions like Robert was suggesting harder than they
>> need
>> >> to
>> >> > be.
>> >> >
>> >> > I want people to be able to checkout the Sling source code and make
>> >> changes
>> >> > to it and contribute those changes back. I don't want them wasting
>> time
>> >> > worry about (a) how to write Java 5-compatible code or (b) whether or
>> not
>> >> > to update the particular module they are interested in to Java 6.
>> >> >
>> >> > In other words, in the balance between "something that makes it
>> easier to
>> >> > provide bug fixes for Java 5 users" and "something that makes it
>> easier
>> >> for
>> >> > people to contribute patch", I am thoroughly on the side of the
>> latter.
>> >> >
>> >> > Justin
>> >> >
>> >> > On Thu, Jan 31, 2013 at 3:07 PM, Carsten Ziegeler <
>> cziege...@apache.org
>> >> >wrote:
>> >> >
>> >> >> Yeah, but if I want to fix something let's say in commons scheduler
>> >> >> and this is targetted for existing installations using Java 5 and I
>> >> >> don't need any Java 5 stuff, why should I have to go through the
>> hasle
>> >> >> and create my own release just to have a bundle working with Java 5?
>> >> >>
>> >> >> Having launchpad using Java 6 and only start with Java 6 is pretty
>> >> >> fine, using just Java 6 (and higher) for CI builds is fine as well.
>> >> >> I'm just talking about individual modules.
>> >> >>
>> >> >> Carsten
>> >> >>
>> >> >> 2013/1/31 Felix Meschberger :
>> >> >> > Hi
>> >> >> >
>> >> >> > In reality, the Sling Launchpad will not support Java 5 at all.
>> >> >> >
>> >> >> > We could just as well have the parent POM setup API checks for
>> Java 6
>> >> >> and configure the Bundle-RequiredExecutionEnvironment appropriately.
>> >> >> >
>> >> >> > Regards
>> >> >> > Felix
>> >> >> >
>> >> >> > Am 31.01.2013 um 12:58 schrieb Justin Edelson:
>> >> >> >
>> >> >> >> -0
>> >> >> >>
>> >> >> >> Why even try to support Java 5? Let's just say Java 6 as a minimum
>> >> >> across
>> >> >> >> the board and be done with it.
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >> On Thu, Jan 31, 2013 at 11:47 AM, Carsten Ziegeler <
>> >> >> cziege...@apache.org>wrote:
>> >> >> >>
>> >> >> >>> Hi,
>> >> >> >>>
>> >> >> >>> we see more and more problems with supporting Java 5 and we
>> >> discussed
>> >> >> >>> this several times in the past year(s?). So let's finally call a
>> >> vote
>> >> >> >>> and see where we all are.
>> >> >> >>>
>> >> >> >>> I propose to drop Java 5 support in general - we should try to
>> stick
>> >> >> >>> to it where possible for supporting existing installations, but
>> each
>> >> >> >>> module should be free to set the base to Java 6 if it makes
>> sense.
>> >> >> >>>
>> >> >> >>> We should also mark the bundles which require Java 6 (I think
>> Felix
>> >> >> >>> proposed a way for this some time ago).
>> >> >> >>>
>> >> >> >>> Please cast your votes :)
>> >> >> >>>
>> >> >> >>> Regards
>> >> >> >>> Carsten
>> >> >> >>> --
>> >> >> >>> Carsten Ziegeler
>> >> >> >>> cziege...@apache.org
>> >> >> >>>
>> >> >> >
>> >> >>
>> >> >>
>> >> >>
>> >> >> --
>> >> >> Carsten Ziegeler
>> >> >> cziege...@apache.org
>> >> >>
>> >>
>> >>
>> >>
>> >> --
>> >> Carsten Ziegeler
>> >> cziege...@apache.org
>> >>
>>
>>
>>
>> --
>> Carsten Ziegeler
>> cziege...@apache.org
>>



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

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

[Nicolas Peltier (JIRA)]

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

Nicolas Peltier commented on SLING-2726:


I see. Wouldn't that be possible to add "resource tree" as a possible resource 
type (in addition to servlets and jcr based resource)? A jcr based resource, 
that handles every descendent? 

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

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

[jira] [Created] (SLING-2728) Setup parent POM for Java 6+ development

[Carsten Ziegeler (JIRA)]

Carsten Ziegeler created SLING-2728:
---

 Summary: Setup parent POM for Java 6+ development
 Key: SLING-2728
 URL: https://issues.apache.org/jira/browse/SLING-2728
 Project: Sling
  Issue Type: Improvement
  Components: General
Affects Versions: Parent 14
Reporter: Carsten Ziegeler
Assignee: Carsten Ziegeler
 Fix For: Parent 15


The Sling parent POM should be configured for Java 6 development:

default class files for Java 5
default Java API compat for Java 5
default Bundle-RequiredExecutionEnvironment for Java 5

Projects should be able to easily switch to Java 6 setting a single property



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

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

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-2726:
-

Can you please elaborate a little bit on your idea?

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

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

Re: Clarification of Resource#getResourceSuperType() contract

[Carsten Ziegeler]

Hi,

2013/2/11 Julian Sedding :
> When you say overriding, do you mean, it eliminates an inherited
> resource type, or is it squeezed in between? Example:

It elimantes, so it's:
>
> Option A (eliminates inherited super-type): type, local-super, 
> local-super-super

>
> Surely there are more possible options, however, I think these are the
> most sensible ones. It might also be worthwhile considering, what
> happens if the two hierarchies join back on a common ancestor...

The whole type hierarchy handling is on demand, so there are no checks
enforced, a wrongly setup type hierarchy could e.g. end up in an
endless loop etc.

> I think we need to keep the override-mechanism due to backwards
> compatibility, so adjusting the JavaDocs seems sensible. However, I
> would like to document that a local sling:resourceSuperType property
> overrides the default behavior, which is the traversal of the
> inheritance-hierarchy (as is currently documented). In addition, if we
> decide for one of the above options, this should also be documented.
Which two options are you refering to? :)

Regards
Carsten

> This would allow using only the expected/intuitive case (i.e. not to
> use any local overrides). At the same time this should provide a
> backwards compatible solution.
>
> WDYT?
>
> Regards
> Julian
>
>
> On Mon, Feb 11, 2013 at 9:44 AM, Carsten Ziegeler  
> wrote:
>> Hi,
>>
>> I agree we have a mismatch here. The way we usually handle
>> getResourceSuperType and how it is implemented is, that it returns a
>> super type information only if the resource by itself has set this
>> (for example for a jcr node if it has the property). The method does
>> not evaluate the resource hierarchy.
>> As far as I remember (this dates really long way back...) the idea is,
>> that a resource can either specify a super type by itself - using this
>> method or if it doesn't, the super type is evaluated using the type
>> hierarchy from the resource tree. This allows for overriding the
>> resource super type on a per resource base.
>>
>> However, I agree that this is a little bit unexpected - so I think we
>> should update the javadocs of the Resource interface to reflect
>> realitity.
>> We could add a method to get the real super type like we have for the isA 
>> check.
>>
>> WDYT?
>>
>> Carsten
>>
>> 2013/2/11 Julian Sedding :
>>> Hello all
>>>
>>> I stumbled over a behavior in Resource#getResourceSuperType() that is
>>> unexpected to me. I would like to clarify the contract of this method.
>>>
>>> The JavaDoc for Resource#getResourceSuperType() states "Returns the
>>> super type of the type of the resource or null if the
>>> getResourceType() has no supertype.". I'll illustrate my understanding
>>> of this contract with a simple example.
>>>
>>> /content/resource [sling:resourceType="type"]
>>> /apps/type [sling:resourceSuperType="super"]
>>> /apps/super
>>>
>>> Now if I have an instance of the Resource at /content/resource and
>>> call ist getResourceSuperType() method, I'd expect to get the string
>>> "super" as the return value ("the super type of the type of the
>>> resource").
>>>
>>> However, the JcrNodeResource[0], and possibly more importantly its
>>> test cases[1] (specifically testResourceSuperType()), implement a
>>> behavior that differs from my understanding of the documented
>>> contract. In the above scenario,
>>> JcrNodeResource#getResourceSuperType() would return null, while the
>>> scenario below would yield "super".
>>>
>>> /content/resource [sling:resourceType="type", 
>>> sling:resourceSuperType="super"]
>>> /apps/type
>>> /apps/super
>>>
>>> To me the documented contract is more intuitive, as that is how
>>> inheritance generally works in my experience (i.e. my grandmother can
>>> only be my grandmother transiently via one of my parents). However,
>>> I'm curious to see whether others have other opinions.
>>>
>>> BTW, MongoDBResource#getResourceSuperType() seems to implement the
>>> same contract that JcrNodeResource does. Additionally, also
>>> ResourceUtil#findResourceSuperType() supports the logic implemented in
>>> JcrNodeResource.
>>>
>>> I noticed this while implementing a possible fix for SLING-2708, which
>>> is concerned with the ResourceUtil#isA() and Resource#isResourceType()
>>> methods. Depending on the implementation of those methods (whether
>>> they rely on Resource#getResourceSuperType() or not), they may yield
>>> different results.
>>>
>>> Thank you for your comments.
>>>
>>> Regards
>>> Julian
>>>
>>>
>>> [0] 
>>> http://svn.apache.org/repos/asf/sling/tags/org.apache.sling.jcr.resource-2.2.0/src/main/java/org/apache/sling/jcr/resource/internal/helper/jcr/JcrNodeResource.java
>>> [1] 
>>> http://svn.apache.org/repos/asf/sling/tags/org.apache.sling.jcr.resource-2.2.0/src/test/java/org/apache/sling/jcr/resource/internal/helper/jcr/JcrNodeResourceTest.java
>>
>>
>>
>> --
>> Carsten Ziegeler
>> cziege...@apache.org



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

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

[Apache Jenkins Server]

See 

[jira] [Commented] (SLING-2156) Provide error handling for POST operations

[Antonio Sanso (JIRA)]

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

Antonio Sanso commented on SLING-2156:
--

applied patch from 02/12/11 in rev. 1444749

> Provide error handling for POST operations
> --
>
> Key: SLING-2156
> URL: https://issues.apache.org/jira/browse/SLING-2156
> Project: Sling
>  Issue Type: New Feature
>  Components: Servlets
>Reporter: Antonio Sanso
>Assignee: Antonio Sanso
> Attachments: post_error_handling, SLING-2156-patch.txt, 
> SLING-2156-patch.txt, SLING-2156-patch.txt, SLING-2156-patch.txt
>
>
> The error handling mechanism described here [0] doesn't seem to apply also to 
> POST operations.
> If an error occurs while posting a resource to repository (e.g. 
> avax.jcr.nodetype.ConstraintViolationException: no matching property 
> definition found for) the HtmlResponse.html template is rendered.
> This  can also represent a security issue since information as 
> REFERRER/technology stack are shown.
> IMHO this page should be at least configurable (if the mechanism in [0] 
> doesn't suite here).
> [0] http://sling.apache.org/site/errorhandling.html

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

Re: Clarification of Resource#getResourceSuperType() contract

[Julian Sedding]

Hi Carsten

Agreed, Option A resembles the currently implementation most closely.
This also ensures that there is only a single inheritance hierarchy
(or line of inheritance), so there won't be any problems.

Given the current documentation of the Resource interface and the
implementation of e.g. JcrNodeResource, I suggest that we document
Resource#getResoureSuperType() as follows:

[The method #getResoureSuperType()] Returns the value of the
"sling:resourceSuperType" property of the current resource if
available. Otherwise it returns the super type of the type of the
resource (as per #getResourceType()) or null if the type has no super
type.

Does that sound reasonable?

Regards
Julian


On Mon, Feb 11, 2013 at 11:56 AM, Carsten Ziegeler  wrote:
> Hi,
>
> 2013/2/11 Julian Sedding :
>> When you say overriding, do you mean, it eliminates an inherited
>> resource type, or is it squeezed in between? Example:
>
> It elimantes, so it's:
>>
>> Option A (eliminates inherited super-type): type, local-super, 
>> local-super-super
>
>>
>> Surely there are more possible options, however, I think these are the
>> most sensible ones. It might also be worthwhile considering, what
>> happens if the two hierarchies join back on a common ancestor...
>
> The whole type hierarchy handling is on demand, so there are no checks
> enforced, a wrongly setup type hierarchy could e.g. end up in an
> endless loop etc.
>
>> I think we need to keep the override-mechanism due to backwards
>> compatibility, so adjusting the JavaDocs seems sensible. However, I
>> would like to document that a local sling:resourceSuperType property
>> overrides the default behavior, which is the traversal of the
>> inheritance-hierarchy (as is currently documented). In addition, if we
>> decide for one of the above options, this should also be documented.
> Which two options are you refering to? :)
>
> Regards
> Carsten
>
>> This would allow using only the expected/intuitive case (i.e. not to
>> use any local overrides). At the same time this should provide a
>> backwards compatible solution.
>>
>> WDYT?
>>
>> Regards
>> Julian
>>
>>
>> On Mon, Feb 11, 2013 at 9:44 AM, Carsten Ziegeler  
>> wrote:
>>> Hi,
>>>
>>> I agree we have a mismatch here. The way we usually handle
>>> getResourceSuperType and how it is implemented is, that it returns a
>>> super type information only if the resource by itself has set this
>>> (for example for a jcr node if it has the property). The method does
>>> not evaluate the resource hierarchy.
>>> As far as I remember (this dates really long way back...) the idea is,
>>> that a resource can either specify a super type by itself - using this
>>> method or if it doesn't, the super type is evaluated using the type
>>> hierarchy from the resource tree. This allows for overriding the
>>> resource super type on a per resource base.
>>>
>>> However, I agree that this is a little bit unexpected - so I think we
>>> should update the javadocs of the Resource interface to reflect
>>> realitity.
>>> We could add a method to get the real super type like we have for the isA 
>>> check.
>>>
>>> WDYT?
>>>
>>> Carsten
>>>
>>> 2013/2/11 Julian Sedding :
 Hello all

 I stumbled over a behavior in Resource#getResourceSuperType() that is
 unexpected to me. I would like to clarify the contract of this method.

 The JavaDoc for Resource#getResourceSuperType() states "Returns the
 super type of the type of the resource or null if the
 getResourceType() has no supertype.". I'll illustrate my understanding
 of this contract with a simple example.

 /content/resource [sling:resourceType="type"]
 /apps/type [sling:resourceSuperType="super"]
 /apps/super

 Now if I have an instance of the Resource at /content/resource and
 call ist getResourceSuperType() method, I'd expect to get the string
 "super" as the return value ("the super type of the type of the
 resource").

 However, the JcrNodeResource[0], and possibly more importantly its
 test cases[1] (specifically testResourceSuperType()), implement a
 behavior that differs from my understanding of the documented
 contract. In the above scenario,
 JcrNodeResource#getResourceSuperType() would return null, while the
 scenario below would yield "super".

 /content/resource [sling:resourceType="type", 
 sling:resourceSuperType="super"]
 /apps/type
 /apps/super

 To me the documented contract is more intuitive, as that is how
 inheritance generally works in my experience (i.e. my grandmother can
 only be my grandmother transiently via one of my parents). However,
 I'm curious to see whether others have other opinions.

 BTW, MongoDBResource#getResourceSuperType() seems to implement the
 same contract that JcrNodeResource does. Additionally, also
 ResourceUtil#findResourceSuperType() supports the logic implemented in
 JcrNodeResource.

 I notice

[VOTE] Resource Resolver 1.0.4, JCR Resource 2.2.4

[Carsten Ziegeler]

Hi,

This vote is about

Resource Resolver 1.0.4
https://issues.apache.org/jira/browse/SLING/fixforversion/12323853

JCR Resource 2.2.4
https://issues.apache.org/jira/browse/SLING/fixforversion/12323857


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


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


Please vote to approve this release:

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

This vote will be open for 72 hours.

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

Jenkins build is back to stable : sling-trunk-1.6 » Apache Sling Event Support #1573

[Apache Jenkins Server]

See 

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

[Apache Jenkins Server]

See 

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

[Apache Jenkins Server]

See 

[jira] [Updated] (SLING-2727) Allow PerformanceRunner to run tests provided by a factory method

[Andrei Dulvac (JIRA)]

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

Andrei Dulvac updated SLING-2727:
-

Attachment: (was: performance_factory.patch)

> Allow PerformanceRunner to run tests provided by a factory method
> -
>
> Key: SLING-2727
> URL: https://issues.apache.org/jira/browse/SLING-2727
> Project: Sling
>  Issue Type: Improvement
>  Components: Testing
>Reporter: Andrei Dulvac
>Priority: Minor
>  Labels: PatchAvailable
> Attachments: performance_reportlogger.patch
>
>
> 1. I have modified PerformanceRunner to be able to run tests provided through 
> a factory method annotated with @PerformanceTestFactory. The method should 
> return a scalar, an array or a list of objects which contain methods. 
> annotated with the existent @PerformanceTest. Optionally, the class(es) 
> returned by the factory method can implement an IdentifiableTestCase 
> interface, which gives the ability to have custom names for tests running on 
> different instances. The test collection is done statically, so this works 
> with the existing @Before/AfterMethodInvocation, allowing to have different 
> test setups at once.
> 2. Modified ReportLogger to log the test case name as well. Also, changed the 
> method signatures so that it's clear what is being logged. This is important 
> for patch 1 to distinguish between different test setups.

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

[jira] [Updated] (SLING-2727) Allow PerformanceRunner to run tests provided by a factory method

[Andrei Dulvac (JIRA)]

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

Andrei Dulvac updated SLING-2727:
-

Attachment: performance_factory.patch

> Allow PerformanceRunner to run tests provided by a factory method
> -
>
> Key: SLING-2727
> URL: https://issues.apache.org/jira/browse/SLING-2727
> Project: Sling
>  Issue Type: Improvement
>  Components: Testing
>Reporter: Andrei Dulvac
>Priority: Minor
>  Labels: PatchAvailable
> Attachments: performance_factory.patch, performance_reportlogger.patch
>
>
> 1. I have modified PerformanceRunner to be able to run tests provided through 
> a factory method annotated with @PerformanceTestFactory. The method should 
> return a scalar, an array or a list of objects which contain methods. 
> annotated with the existent @PerformanceTest. Optionally, the class(es) 
> returned by the factory method can implement an IdentifiableTestCase 
> interface, which gives the ability to have custom names for tests running on 
> different instances. The test collection is done statically, so this works 
> with the existing @Before/AfterMethodInvocation, allowing to have different 
> test setups at once.
> 2. Modified ReportLogger to log the test case name as well. Also, changed the 
> method signatures so that it's clear what is being logged. This is important 
> for patch 1 to distinguish between different test setups.

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

[jira] [Updated] (SLING-2727) Allow PerformanceRunner to run tests provided by a factory method

[Andrei Dulvac (JIRA)]

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

Andrei Dulvac updated SLING-2727:
-

Description: 
1. I have modified PerformanceRunner to be able to run tests provided through a 
factory method annotated with @PerformanceTestFactory, when used with 
@PerformanceTestSuites. The method can be used (this is optional) on a "test 
case" object that is added to the ParameterizedTestList returned by the 
@PerformanceTestSuite method. If there is no @PerformanceTestFactory method, 
the behaviour stays the same as before. If a @PerformanceTestFactory exists, 
the PerformanceRunner adds all the test case instances returned by the factory 
to the testObjects list, instead of the test case itself. 
Optionally, the test cases can implement an IdentifiableTestCase interface, 
which gives the ability to have custom names for tests running on different 
instances.

2. Modified ReportLogger to log the test case name as well. Also, changed the 
method signatures so that it's clear what is being logged. This works with 
patch 1 to distinguish between different test case instances


The motivation behind this is that a suite can contain test cases that are 
different logically, but the test case should be able to be parameterized.

  was:
1. I have modified PerformanceRunner to be able to run tests provided through a 
factory method annotated with @PerformanceTestFactory. The method should return 
a scalar, an array or a list of objects which contain methods. annotated with 
the existent @PerformanceTest. Optionally, the class(es) returned by the 
factory method can implement an IdentifiableTestCase interface, which gives the 
ability to have custom names for tests running on different instances. The test 
collection is done statically, so this works with the existing 
@Before/AfterMethodInvocation, allowing to have different test setups at once.

2. Modified ReportLogger to log the test case name as well. Also, changed the 
method signatures so that it's clear what is being logged. This is important 
for patch 1 to distinguish between different test setups.


> Allow PerformanceRunner to run tests provided by a factory method
> -
>
> Key: SLING-2727
> URL: https://issues.apache.org/jira/browse/SLING-2727
> Project: Sling
>  Issue Type: Improvement
>  Components: Testing
>Reporter: Andrei Dulvac
>Priority: Minor
>  Labels: PatchAvailable
> Attachments: performance_factory.patch, performance_reportlogger.patch
>
>
> 1. I have modified PerformanceRunner to be able to run tests provided through 
> a factory method annotated with @PerformanceTestFactory, when used with 
> @PerformanceTestSuites. The method can be used (this is optional) on a "test 
> case" object that is added to the ParameterizedTestList returned by the 
> @PerformanceTestSuite method. If there is no @PerformanceTestFactory method, 
> the behaviour stays the same as before. If a @PerformanceTestFactory exists, 
> the PerformanceRunner adds all the test case instances returned by the 
> factory to the testObjects list, instead of the test case itself. 
> Optionally, the test cases can implement an IdentifiableTestCase interface, 
> which gives the ability to have custom names for tests running on different 
> instances.
> 2. Modified ReportLogger to log the test case name as well. Also, changed the 
> method signatures so that it's clear what is being logged. This works with 
> patch 1 to distinguish between different test case instances
> The motivation behind this is that a suite can contain test cases that are 
> different logically, but the test case should be able to be parameterized.

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

[jira] [Commented] (SLING-2727) Allow PerformanceRunner to run tests provided by a factory method

[Andrei Dulvac (JIRA)]

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

Andrei Dulvac commented on SLING-2727:
--

Updated the description and the patch after looking at the PerformanceTestSuite 
functionality more in-depth.


> Allow PerformanceRunner to run tests provided by a factory method
> -
>
> Key: SLING-2727
> URL: https://issues.apache.org/jira/browse/SLING-2727
> Project: Sling
>  Issue Type: Improvement
>  Components: Testing
>Reporter: Andrei Dulvac
>Priority: Minor
>  Labels: PatchAvailable
> Attachments: performance_factory.patch, performance_reportlogger.patch
>
>
> 1. I have modified PerformanceRunner to be able to run tests provided through 
> a factory method annotated with @PerformanceTestFactory, when used with 
> @PerformanceTestSuites. The method can be used (this is optional) on a "test 
> case" object that is added to the ParameterizedTestList returned by the 
> @PerformanceTestSuite method. If there is no @PerformanceTestFactory method, 
> the behaviour stays the same as before. If a @PerformanceTestFactory exists, 
> the PerformanceRunner adds all the test case instances returned by the 
> factory to the testObjects list, instead of the test case itself. 
> Optionally, the test cases can implement an IdentifiableTestCase interface, 
> which gives the ability to have custom names for tests running on different 
> instances.
> 2. Modified ReportLogger to log the test case name as well. Also, changed the 
> method signatures so that it's clear what is being logged. This works with 
> patch 1 to distinguish between different test case instances
> The motivation behind this is that a suite can contain test cases that are 
> different logically, but the test case should be able to be parameterized.

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

[jira] [Updated] (SLING-2727) Allow PerformanceRunner to run tests provided by a factory method

[Andrei Dulvac (JIRA)]

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

Andrei Dulvac updated SLING-2727:
-

Attachment: (was: performance_factory.patch)

> Allow PerformanceRunner to run tests provided by a factory method
> -
>
> Key: SLING-2727
> URL: https://issues.apache.org/jira/browse/SLING-2727
> Project: Sling
>  Issue Type: Improvement
>  Components: Testing
>Reporter: Andrei Dulvac
>Priority: Minor
>  Labels: PatchAvailable
> Attachments: performance_factory.patch, performance_reportlogger.patch
>
>
> 1. I have modified PerformanceRunner to be able to run tests provided through 
> a factory method annotated with @PerformanceTestFactory, when used with 
> @PerformanceTestSuites. The method can be used (this is optional) on a "test 
> case" object that is added to the ParameterizedTestList returned by the 
> @PerformanceTestSuite method. If there is no @PerformanceTestFactory method, 
> the behaviour stays the same as before. If a @PerformanceTestFactory exists, 
> the PerformanceRunner adds all the test case instances returned by the 
> factory to the testObjects list, instead of the test case itself. 
> Optionally, the test cases can implement an IdentifiableTestCase interface, 
> which gives the ability to have custom names for tests running on different 
> instances.
> 2. Modified ReportLogger to log the test case name as well. Also, changed the 
> method signatures so that it's clear what is being logged. This works with 
> patch 1 to distinguish between different test case instances
> The motivation behind this is that a suite can contain test cases that are 
> different logically, but the test case should be able to be parameterized.

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

[jira] [Updated] (SLING-2727) Allow PerformanceRunner to run tests provided by a factory method

[Andrei Dulvac (JIRA)]

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

Andrei Dulvac updated SLING-2727:
-

Attachment: performance_factory.patch

> Allow PerformanceRunner to run tests provided by a factory method
> -
>
> Key: SLING-2727
> URL: https://issues.apache.org/jira/browse/SLING-2727
> Project: Sling
>  Issue Type: Improvement
>  Components: Testing
>Reporter: Andrei Dulvac
>Priority: Minor
>  Labels: PatchAvailable
> Attachments: performance_factory.patch, performance_reportlogger.patch
>
>
> 1. I have modified PerformanceRunner to be able to run tests provided through 
> a factory method annotated with @PerformanceTestFactory, when used with 
> @PerformanceTestSuites. The method can be used (this is optional) on a "test 
> case" object that is added to the ParameterizedTestList returned by the 
> @PerformanceTestSuite method. If there is no @PerformanceTestFactory method, 
> the behaviour stays the same as before. If a @PerformanceTestFactory exists, 
> the PerformanceRunner adds all the test case instances returned by the 
> factory to the testObjects list, instead of the test case itself. 
> Optionally, the test cases can implement an IdentifiableTestCase interface, 
> which gives the ability to have custom names for tests running on different 
> instances.
> 2. Modified ReportLogger to log the test case name as well. Also, changed the 
> method signatures so that it's clear what is being logged. This works with 
> patch 1 to distinguish between different test case instances
> The motivation behind this is that a suite can contain test cases that are 
> different logically, but the test case should be able to be parameterized.

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

[jira] [Updated] (SLING-2727) Allow PerformanceRunner to run tests provided by a factory method

[Andrei Dulvac (JIRA)]

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

Andrei Dulvac updated SLING-2727:
-

Attachment: performance_factory.patch

> Allow PerformanceRunner to run tests provided by a factory method
> -
>
> Key: SLING-2727
> URL: https://issues.apache.org/jira/browse/SLING-2727
> Project: Sling
>  Issue Type: Improvement
>  Components: Testing
>Reporter: Andrei Dulvac
>Priority: Minor
>  Labels: PatchAvailable
> Attachments: performance_factory.patch, performance_reportlogger.patch
>
>
> 1. I have modified PerformanceRunner to be able to run tests provided through 
> a factory method annotated with @PerformanceTestFactory, when used with 
> @PerformanceTestSuites. The method can be used (this is optional) on a "test 
> case" object that is added to the ParameterizedTestList returned by the 
> @PerformanceTestSuite method. If there is no @PerformanceTestFactory method, 
> the behaviour stays the same as before. If a @PerformanceTestFactory exists, 
> the PerformanceRunner adds all the test case instances returned by the 
> factory to the testObjects list, instead of the test case itself. 
> Optionally, the test cases can implement an IdentifiableTestCase interface, 
> which gives the ability to have custom names for tests running on different 
> instances.
> 2. Modified ReportLogger to log the test case name as well. Also, changed the 
> method signatures so that it's clear what is being logged. This works with 
> patch 1 to distinguish between different test case instances
> The motivation behind this is that a suite can contain test cases that are 
> different logically, but the test case should be able to be parameterized.

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

[jira] [Updated] (SLING-2727) Allow PerformanceRunner to run tests provided by a factory method

[Andrei Dulvac (JIRA)]

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

Andrei Dulvac updated SLING-2727:
-

Attachment: (was: performance_factory.patch)

> Allow PerformanceRunner to run tests provided by a factory method
> -
>
> Key: SLING-2727
> URL: https://issues.apache.org/jira/browse/SLING-2727
> Project: Sling
>  Issue Type: Improvement
>  Components: Testing
>Reporter: Andrei Dulvac
>Priority: Minor
>  Labels: PatchAvailable
> Attachments: performance_factory.patch, performance_reportlogger.patch
>
>
> 1. I have modified PerformanceRunner to be able to run tests provided through 
> a factory method annotated with @PerformanceTestFactory, when used with 
> @PerformanceTestSuites. The method can be used (this is optional) on a "test 
> case" object that is added to the ParameterizedTestList returned by the 
> @PerformanceTestSuite method. If there is no @PerformanceTestFactory method, 
> the behaviour stays the same as before. If a @PerformanceTestFactory exists, 
> the PerformanceRunner adds all the test case instances returned by the 
> factory to the testObjects list, instead of the test case itself. 
> Optionally, the test cases can implement an IdentifiableTestCase interface, 
> which gives the ability to have custom names for tests running on different 
> instances.
> 2. Modified ReportLogger to log the test case name as well. Also, changed the 
> method signatures so that it's clear what is being logged. This works with 
> patch 1 to distinguish between different test case instances
> The motivation behind this is that a suite can contain test cases that are 
> different logically, but the test case should be able to be parameterized.

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

Jenkins build is back to stable : sling-trunk-1.6 » Apache Sling Sample Integration Tests #1574

[Apache Jenkins Server]

See 

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

[Apache Jenkins Server]

See 

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

[Apache Jenkins Server]

See 

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

[Apache Jenkins Server]

See 

[jira] [Commented] (SLING-2728) Setup parent POM for Java 6+ development

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-2728:
-

I've added some changes to our parent pom: we now have a property named 
sling.java.version which is by default set to "5" and can be changed in any 
project to "6".
This property defines the configuration of the java compiler plugin, the animal 
sniffer plugin and sets the Bundle-RequiredExecutionEnvironment manifest entry.

So by default each bundle is still targetting Java 5, but if a bundle requires 
Java 6 it simply sets the property sling.java.version to 6.

> Setup parent POM for Java 6+ development
> 
>
> Key: SLING-2728
> URL: https://issues.apache.org/jira/browse/SLING-2728
> Project: Sling
>  Issue Type: Improvement
>  Components: General
>Affects Versions: Parent 14
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Parent 15
>
>
> The Sling parent POM should be configured for Java 6 development:
> default class files for Java 5
> default Java API compat for Java 5
> default Bundle-RequiredExecutionEnvironment for Java 5
> Projects should be able to easily switch to Java 6 setting a single property

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

[jira] [Resolved] (SLING-2728) Setup parent POM for Java 6+ development

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler resolved SLING-2728.
-

Resolution: Fixed

Added in revision 1444924

> Setup parent POM for Java 6+ development
> 
>
> Key: SLING-2728
> URL: https://issues.apache.org/jira/browse/SLING-2728
> Project: Sling
>  Issue Type: Improvement
>  Components: General
>Affects Versions: Parent 14
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Parent 15
>
>
> The Sling parent POM should be configured for Java 6 development:
> default class files for Java 5
> default Java API compat for Java 5
> default Bundle-RequiredExecutionEnvironment for Java 5
> Projects should be able to easily switch to Java 6 setting a single property

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

Re: [VOTE] Resource Resolver 1.0.4, JCR Resource 2.2.4

[Ian Boston]

Signatures check ok.
The list of unfixed issues look ok, it would have been nice to include
SLING-2708, however the, the change required looks like it might break
the release early and often methodology.

So, I am +1.
Ian

On 12 February 2013 00:30, Carsten Ziegeler  wrote:
> Hi,
>
> This vote is about
>
> Resource Resolver 1.0.4
> https://issues.apache.org/jira/browse/SLING/fixforversion/12323853
>
> JCR Resource 2.2.4
> https://issues.apache.org/jira/browse/SLING/fixforversion/12323857
>
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-224/
>
>
> 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 224 /tmp/sling-staging
>
>
> Please vote to approve this release:
>
>  [ ] +1 Approve the release
>  [ ]  0 Don't care
>  [ ] -1 Don't release, because ...
>
> This vote will be open for 72 hours.
>
> Regards
> Carsten
> --
> Carsten Ziegeler
> cziege...@apache.org

Build failed in Jenkins: sling-trunk-1.6 #1576

[Apache Jenkins Server]

See 

Changes:

[cziegeler] SLING-2728 : Setup parent POM for Java 6+ development

--
Started by an SCM change
Building remotely on ubuntu1 in workspace 

Updating http://svn.apache.org/repos/asf/sling/trunk
U parent/pom.xml
At revision 1444959
[locks-and-latches] Checking to see if we really have the locks
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[lock

[jira] [Resolved] (SLING-2725) Improve Unit Test coverage inside the resource resolver bundle

[Ian Boston (JIRA)]

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

Ian Boston resolved SLING-2725.
---

   Resolution: Fixed
Fix Version/s: Resource Resolver 1.0.6

Coverage now at 68% overall with the major areas covered by unit tests. 
Although this is not perfect it is better than it was. Integration tests cover 
the edge use cases that are hard to cover without a full repository.

In general Mockito was used to minimise the cost of changes to the call 
patterns.

> Improve Unit Test coverage inside the resource resolver bundle
> --
>
> Key: SLING-2725
> URL: https://issues.apache.org/jira/browse/SLING-2725
> Project: Sling
>  Issue Type: Bug
>  Components: ResourceResolver
>Affects Versions: Resource Resolver 1.0.2
>Reporter: Ian Boston
>Assignee: Ian Boston
> Fix For: Resource Resolver 1.0.6
>
>
> Coverage inside this bundle is low. Although it is covered by integration 
> tests, it should be higher.

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

Build failed in Jenkins: sling-trunk-1.6 #1577

[Apache Jenkins Server]

See 

Changes:

[ieb] SLING-2718 Coverage now at 68%, added some coverage for mapping and tests 
for earlier fixed bugs.

--
Started by an SCM change
Building remotely on ubuntu1 in workspace 

Updating http://svn.apache.org/repos/asf/sling/trunk
AU
bundles/resourceresolver/src/test/java/org/apache/sling/resourceresolver/impl/SimpleValueMapImpl.java
U 
bundles/resourceresolver/src/test/java/org/apache/sling/resourceresolver/impl/MockedResourceResolverImplTest.java
At revision 1445022
[locks-and-latches] Checking to see if we really have the locks
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the locks... sleeping for 1 minute
[locks-and-latches] Could not get all the loc

Re: [VOTE] Resource Resolver 1.0.4, JCR Resource 2.2.4

[Carsten Ziegeler]

+1

Carsten

2013/2/11 Ian Boston :
> Signatures check ok.
> The list of unfixed issues look ok, it would have been nice to include
> SLING-2708, however the, the change required looks like it might break
> the release early and often methodology.
>
> So, I am +1.
> Ian
>
> On 12 February 2013 00:30, Carsten Ziegeler  wrote:
>> Hi,
>>
>> This vote is about
>>
>> Resource Resolver 1.0.4
>> https://issues.apache.org/jira/browse/SLING/fixforversion/12323853
>>
>> JCR Resource 2.2.4
>> https://issues.apache.org/jira/browse/SLING/fixforversion/12323857
>>
>>
>> Staging repository:
>> https://repository.apache.org/content/repositories/orgapachesling-224/
>>
>>
>> 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 224 /tmp/sling-staging
>>
>>
>> Please vote to approve this release:
>>
>>  [ ] +1 Approve the release
>>  [ ]  0 Don't care
>>  [ ] -1 Don't release, because ...
>>
>> This vote will be open for 72 hours.
>>
>> Regards
>> Carsten
>> --
>> Carsten Ziegeler
>> cziege...@apache.org



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

Re: Clarification of Resource#getResourceSuperType() contract

[Carsten Ziegeler]

Hi,

> Given the current documentation of the Resource interface and the
> implementation of e.g. JcrNodeResource, I suggest that we document
> Resource#getResoureSuperType() as follows:
>
> [The method #getResoureSuperType()] Returns the value of the
> "sling:resourceSuperType" property of the current resource if
> available. Otherwise it returns the super type of the type of the
> resource (as per #getResourceType()) or null if the type has no super
> type.
>
> Does that sound reasonable?
This would us require to change the getResourceSuperType method of our
implementations to do
the lookup in the resource tree. So I think we should change the docs to state
that this method only returns a value if the "sling:resourceSuperType"
property is set.
Although this property might be implementation specific, so we need
some different wording :)

Looking back, I think adding the isResourceType method to the Resource
interface was wrong
as this is using information outside of the scope of the resource.
getResourceType and getResourceSuperType return the information from a
resource only
if the resource has this information.

If you want to get the (calculated) resource super type of a resource,
we have methods on ResourceUtil to do the trick.
(Although these don't work because the resource tree is read with the
resource resolver from the passed resource).

I have the feeling that we should clean up this area...

Carsten
>
> Regards
> Julian
>
>
> On Mon, Feb 11, 2013 at 11:56 AM, Carsten Ziegeler  
> wrote:
>> Hi,
>>
>> 2013/2/11 Julian Sedding :
>>> When you say overriding, do you mean, it eliminates an inherited
>>> resource type, or is it squeezed in between? Example:
>>
>> It elimantes, so it's:
>>>
>>> Option A (eliminates inherited super-type): type, local-super, 
>>> local-super-super
>>
>>>
>>> Surely there are more possible options, however, I think these are the
>>> most sensible ones. It might also be worthwhile considering, what
>>> happens if the two hierarchies join back on a common ancestor...
>>
>> The whole type hierarchy handling is on demand, so there are no checks
>> enforced, a wrongly setup type hierarchy could e.g. end up in an
>> endless loop etc.
>>
>>> I think we need to keep the override-mechanism due to backwards
>>> compatibility, so adjusting the JavaDocs seems sensible. However, I
>>> would like to document that a local sling:resourceSuperType property
>>> overrides the default behavior, which is the traversal of the
>>> inheritance-hierarchy (as is currently documented). In addition, if we
>>> decide for one of the above options, this should also be documented.
>> Which two options are you refering to? :)
>>
>> Regards
>> Carsten
>>
>>> This would allow using only the expected/intuitive case (i.e. not to
>>> use any local overrides). At the same time this should provide a
>>> backwards compatible solution.
>>>
>>> WDYT?
>>>
>>> Regards
>>> Julian
>>>
>>>
>>> On Mon, Feb 11, 2013 at 9:44 AM, Carsten Ziegeler  
>>> wrote:
 Hi,

 I agree we have a mismatch here. The way we usually handle
 getResourceSuperType and how it is implemented is, that it returns a
 super type information only if the resource by itself has set this
 (for example for a jcr node if it has the property). The method does
 not evaluate the resource hierarchy.
 As far as I remember (this dates really long way back...) the idea is,
 that a resource can either specify a super type by itself - using this
 method or if it doesn't, the super type is evaluated using the type
 hierarchy from the resource tree. This allows for overriding the
 resource super type on a per resource base.

 However, I agree that this is a little bit unexpected - so I think we
 should update the javadocs of the Resource interface to reflect
 realitity.
 We could add a method to get the real super type like we have for the isA 
 check.

 WDYT?

 Carsten

 2013/2/11 Julian Sedding :
> Hello all
>
> I stumbled over a behavior in Resource#getResourceSuperType() that is
> unexpected to me. I would like to clarify the contract of this method.
>
> The JavaDoc for Resource#getResourceSuperType() states "Returns the
> super type of the type of the resource or null if the
> getResourceType() has no supertype.". I'll illustrate my understanding
> of this contract with a simple example.
>
> /content/resource [sling:resourceType="type"]
> /apps/type [sling:resourceSuperType="super"]
> /apps/super
>
> Now if I have an instance of the Resource at /content/resource and
> call ist getResourceSuperType() method, I'd expect to get the string
> "super" as the return value ("the super type of the type of the
> resource").
>
> However, the JcrNodeResource[0], and possibly more importantly its
> test cases[1] (specifically testResourceSuperType()), implement a
> behavior that differs from 

Re: Patches needing review

[Carsten Ziegeler]

Hi Robert,

thanks for the reminder :) I think it's simply: so far none of the
committers had time to have a look at one of these :(

Carsten

2013/2/11 Robert Munteanu :
> Hi,
>
> I have submitted some patches which seem to have fallen under the radar. If 
> that's an accident rather than intended, I'd appreciate if someone could take 
> a look at them.
>
> SLING-2720: Update exported versions for extension fragments to match 
> well-known JAX-WS, JAXB, StAX and JAF versions
> https://issues.apache.org/jira/browse/SLING-2720
>
> SLING-2658: Document that the bundle list does not allow selection for the 
> HttpService provider
> https://issues.apache.org/jira/browse/SLING-2658
>
> SLING-2721: Integration test for JAXB marhsalling
> https://issues.apache.org/jira/browse/SLING-2721
>
> Thanks!
>
> Robert



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

[jira] [Updated] (SLING-920) Jenkins continuous integration setup

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler updated SLING-920:
---

Summary: Jenkins continuous integration setup  (was: Hudson continuous 
integration setup)

> Jenkins continuous integration 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 Hudson continuous environment setup 
> at http://hudson.zones.apache.org/hudson/view/Sling/

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

[jira] [Commented] (SLING-920) Jenkins continuous integration setup

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-920:


The url for the Jenkins server is: https://builds.apache.org/

I've removed the old 1.5 trunk project, switched the samples-1.5 project to 
samples-1.6 and updated the Maven version to 3.0.4 for all three builds.

> Jenkins continuous integration 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 Hudson continuous environment setup 
> at http://hudson.zones.apache.org/hudson/view/Sling/

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

[jira] [Commented] (SLING-2722) Add support for transitive partialbundlelist dependencies with the maven-launchpad-plugin

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-2722:
-

I'm not sure if checking transitive dependencies is the way to go, I rather 
have the feeling that transitive bundle list don't work the way they should.
Let's asume we have a project named "base" which is a partial bundle list, now 
we have another partial bundle list "components" which has "base" as it's 
dependency.
The bundle list of "components" should include the artifacts from "base".
If I have now a project "all" depending on "components", this should bring all 
artifacts from "base" into "all" as these are part of the "components" bundle 
list.

I haven't looked at it yet, but I assume right now "components" does not 
contain the artifacts from "base" - and I would rather change this, then going 
through transitive dependencies

> Add support for transitive partialbundlelist dependencies with the 
> maven-launchpad-plugin
> -
>
> Key: SLING-2722
> URL: https://issues.apache.org/jira/browse/SLING-2722
> Project: Sling
>  Issue Type: Improvement
>  Components: Maven Plugins and Archetypes
>Reporter: Rupert Westenthaler
> Attachments: 
> SLING-2722_maven-launchpad-plugin_transitive_partialbundlelist_dependencies.patch
>
>
> While the "maven-launchpad-plugin" does support the inclusion of 
> "partialbundlelist" by adding dependencies with the 
> partialbundlelist to the pom.xml file. It does only consider 
> direct dependencies and not transitive one.
> Transitive dependencies would allow to create partial bundle list that add to 
> (depend on) others. This allows to make bundle lists self consistent without 
> repeating bundles (e.g. common libraries) over and over again.
> It would also allow to define bundle lists for different 'levels': low level 
> lists for managing modules requires by services that are than merged to an 
> higher level bundle list that covers a user level feature.
> To give a simplified Example: In Apache Stanbol I would like to use this 
> feature to create bundlelists like
> * Apache OpenNLP
> * Stanbol Enhancer component
> * OpenNLP based NLP processing Enhancement Engines
>* depends on OpenNLP
>* depends on Stanbol Enahncer 

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