Build failed in Jenkins: sling-trunk-1.5 #1718

2012-07-24 Thread Apache Jenkins Server
See 

Changes:

[cziegeler] SLING-2524 : Improve package refresh behaviour

--
[...truncated 224 lines...]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 1 resource
[INFO] Copying 3 resources
mojoSucceeded 
org.apache.maven.plugins:maven-resources-plugin:2.4.3(default-resources)
mojoStarted 
org.apache.maven.plugins:maven-compiler-plugin:2.3.2(default-compile)
[INFO] 
[INFO] --- maven-compiler-plugin:2.3.2:compile (default-compile) @ 
apache-sling-jar-resource-bundle ---
[INFO] No sources to compile
mojoSucceeded 
org.apache.maven.plugins:maven-compiler-plugin:2.3.2(default-compile)
mojoStarted 
org.apache.maven.plugins:maven-resources-plugin:2.4.3(default-testResources)[INFO]
 Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 

[INFO] Copying 3 resources

[INFO] 
[INFO] --- maven-resources-plugin:2.4.3:testResources (default-testResources) @ 
apache-sling-jar-resource-bundle ---
mojoSucceeded 
org.apache.maven.plugins:maven-resources-plugin:2.4.3(default-testResources)
mojoStarted 
org.apache.maven.plugins:maven-compiler-plugin:2.3.2(default-testCompile)[INFO] 
No sources to compile

[INFO] 
[INFO] --- maven-compiler-plugin:2.3.2:testCompile (default-testCompile) @ 
apache-sling-jar-resource-bundle ---
mojoSucceeded 
org.apache.maven.plugins:maven-compiler-plugin:2.3.2(default-testCompile)
mojoStarted org.apache.maven.plugins:maven-surefire-plugin:2.7.2(default-test)
[INFO] 
[INFO] --- maven-surefire-plugin:2.7.2:test (default-test) @ 
apache-sling-jar-resource-bundle ---
[INFO] Surefire report directory: 


---
 T E S T S
---
There are no tests to run.

Results :

Tests run: 0, Failures: 0, Errors: 0, Skipped: 0

mojoSucceeded org.apache.maven.plugins:maven-surefire-plugin:2.7.2(default-test)
[JENKINS] Recording test results
mojoStarted org.apache.maven.plugins:maven-jar-plugin:2.3.1(default-jar)
[INFO] 
[INFO] --- maven-jar-plugin:2.3.1:jar (default-jar) @ 
apache-sling-jar-resource-bundle ---
[INFO] Building jar: 

mojoSucceeded org.apache.maven.plugins:maven-jar-plugin:2.3.1(default-jar)
mojoStarted org.apache.maven.plugins:maven-install-plugin:2.3.1(default-install)
[INFO] 
[INFO] --- maven-install-plugin:2.3.1:install (default-install) @ 
apache-sling-jar-resource-bundle ---
[INFO] Installing 

 to 
/home/jenkins/jenkins-slave/maven-repositories/0/org/apache/sling/apache-sling-jar-resource-bundle/1.0.1-SNAPSHOT/apache-sling-jar-resource-bundle-1.0.1-SNAPSHOT.jar
[INFO] Installing 

 to 
/home/jenkins/jenkins-slave/maven-repositories/0/org/apache/sling/apache-sling-jar-resource-bundle/1.0.1-SNAPSHOT/apache-sling-jar-resource-bundle-1.0.1-SNAPSHOT.pom
mojoSucceeded 
org.apache.maven.plugins:maven-install-plugin:2.3.1(default-install)
mojoStarted org.apache.maven.plugins:maven-deploy-plugin:2.5(default-deploy)
[INFO] 
[INFO] --- maven-deploy-plugin:2.5:deploy (default-deploy) @ 
apache-sling-jar-resource-bundle ---
Downloading: 
https://repository.apache.org/content/repositories/snapshots/org/apache/sling/apache-sling-jar-resource-bundle/1.0.1-SNAPSHOT/maven-metadata.xml
Downloaded: 
https://repository.apache.org/content/repositories/snapshots/org/apache/sling/apache-sling-jar-resource-bundle/1.0.1-SNAPSHOT/maven-metadata.xml
 (804 B at 0.8 KB/sec)
Uploading: 
https://repository.apache.org/content/repositories/snapshots/org/apache/sling/apache-sling-jar-resource-bundle/1.0.1-SNAPSHOT/apache-sling-jar-resource-bundle-1.0.1-20120724.080649-372.jar
Uploaded: 
https://repository.apache.org/content/repositories/snapshots/org/apache/sling/apache-sling-jar-resource-bundle/1.0.1-SNAPSHOT/apache-sling-jar-resource-bundle-1.0.1-20120724.080649-372.jar
 (8 KB at 18.4 KB/sec)
Uploading: 
https://repository.apache.org/content/repositories/snapshots/org/apache/sling/apache-sling-jar-resource-bundle/1.0.1-SNAPSHOT/apache-sling-jar-resource-bundle-1.0.1-20120724.080649-372.pom
Uploaded: 
https://repository.apache.org/content/repositories/snapshots/org/apache/sling/apache-sling-jar-resource-bundle/1.0.1-SNAPSHOT/apache-sling-jar-resource-bundle-1.0.1-20120724.080649-372.pom
 (2 KB at 9.7 KB/sec)
Downloading: 
https://r

[jira] [Commented] (SLING-2536) JcrResourceBundle breaks the contract of getLocale

2012-07-24 Thread Endolf (JIRA)

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

Endolf commented on SLING-2536:
---

That doesn't appear to be how it is working.

I only have english bundle installed, I set my browser language to only allow 
zh-hk, hong kong chinese, I can see that my Accept-Langauge in the request 
headers only contains that language. Sling is set to default to english. 

The response contains a content-language header of zh-hk, all the properties 
are resolved to their english values, not the keys.

> JcrResourceBundle breaks the contract of getLocale
> --
>
> Key: SLING-2536
> URL: https://issues.apache.org/jira/browse/SLING-2536
> Project: Sling
>  Issue Type: Bug
>Affects Versions: i18n 2.2.2
>Reporter: Endolf
>
> The javadoc for getLocale state that it should return the locale of this 
> bundle or the locale of the fallback. Currently JcrResourceBundle always 
> returns the requested locale even if there is no mix:language for that locale.
> e.g. Only a mix:language with a jcr:language en is in the jcr, a request for 
> a resource bundle of sv will return a ResourceBundle object where getLocale 
> returns sv. This should return en according to the javadoc.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Assigned] (SLING-2542) Readd initial workspace support

2012-07-24 Thread Carsten Ziegeler (JIRA)

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

Carsten Ziegeler reassigned SLING-2542:
---

Assignee: Carsten Ziegeler

> Readd initial workspace support
> ---
>
> Key: SLING-2542
> URL: https://issues.apache.org/jira/browse/SLING-2542
> Project: Sling
>  Issue Type: Bug
>  Components: JCR, ResourceResolver
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: JCR Resource 2.1.2, Resource Resolver 1.0.0
>
>
> With the split of the resolver from jcr we dropped the workspace support 
> completeley.
> We had two ways: specifying the workspace through a request attribute or as a 
> value inside the authentication map.
> Which one do we want to support?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (SLING-2536) JcrResourceBundle breaks the contract of getLocale

2012-07-24 Thread Alexander Klimetschek (JIRA)

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

Alexander Klimetschek commented on SLING-2536:
--

That's probably because it resolves the english resource bundle. The default 
locale resolver does not use the accept-language header afaik.

> JcrResourceBundle breaks the contract of getLocale
> --
>
> Key: SLING-2536
> URL: https://issues.apache.org/jira/browse/SLING-2536
> Project: Sling
>  Issue Type: Bug
>Affects Versions: i18n 2.2.2
>Reporter: Endolf
>
> The javadoc for getLocale state that it should return the locale of this 
> bundle or the locale of the fallback. Currently JcrResourceBundle always 
> returns the requested locale even if there is no mix:language for that locale.
> e.g. Only a mix:language with a jcr:language en is in the jcr, a request for 
> a resource bundle of sv will return a ResourceBundle object where getLocale 
> returns sv. This should return en according to the javadoc.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Resolved] (SLING-2542) Readd initial workspace support

2012-07-24 Thread Carsten Ziegeler (JIRA)

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

Carsten Ziegeler resolved SLING-2542.
-

Resolution: Fixed

Right :)

I've readded both

> Readd initial workspace support
> ---
>
> Key: SLING-2542
> URL: https://issues.apache.org/jira/browse/SLING-2542
> Project: Sling
>  Issue Type: Bug
>  Components: JCR, ResourceResolver
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: JCR Resource 2.1.2, Resource Resolver 1.0.0
>
>
> With the split of the resolver from jcr we dropped the workspace support 
> completeley.
> We had two ways: specifying the workspace through a request attribute or as a 
> value inside the authentication map.
> Which one do we want to support?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (SLING-2544) Restore tests included in the no longer existing JcrResourceResolverTest

2012-07-24 Thread Carsten Ziegeler (JIRA)

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

Carsten Ziegeler commented on SLING-2544:
-

Thanks for the work, Antonio!

As you commented we should not add them to the resourceresolver project due to 
the dependencies. I'm not 100% sure where to put this, but maybe the launchpad 
test services is a good place? I think these tests should run in a launed 
instance on the server side, so we always test the latest combination of the 
resourceresolver and jcr resource bundle

> Restore tests included in the no longer existing JcrResourceResolverTest 
> -
>
> Key: SLING-2544
> URL: https://issues.apache.org/jira/browse/SLING-2544
> Project: Sling
>  Issue Type: New Feature
>  Components: ResourceResolver
>Reporter: Antonio Sanso
> Attachments: JcrResourceResolverTest.java, 
> SynchronousJcrResourceListener.java
>
>
> With SLING-2396 almost all the testsincluded in the no longer existing 
> JcrResourceResolverTest e.g. testResolveVirtualHostHttp80()/ 
> testResolveResourceAlias()/ ... have been "lost in translation".
> I think it would be really useful to restore them specially for regression 
> detection

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (SLING-2536) JcrResourceBundle breaks the contract of getLocale

2012-07-24 Thread Endolf (JIRA)

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

Endolf commented on SLING-2536:
---

If I choose sv, or any of it's variations and have the sv bundle in the 
repository it resolves that fine from just the accept-language header.

> JcrResourceBundle breaks the contract of getLocale
> --
>
> Key: SLING-2536
> URL: https://issues.apache.org/jira/browse/SLING-2536
> Project: Sling
>  Issue Type: Bug
>Affects Versions: i18n 2.2.2
>Reporter: Endolf
>
> The javadoc for getLocale state that it should return the locale of this 
> bundle or the locale of the fallback. Currently JcrResourceBundle always 
> returns the requested locale even if there is no mix:language for that locale.
> e.g. Only a mix:language with a jcr:language en is in the jcr, a request for 
> a resource bundle of sv will return a ResourceBundle object where getLocale 
> returns sv. This should return en according to the javadoc.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Comment Edited] (SLING-2544) Restore tests included in the no longer existing JcrResourceResolverTest

2012-07-24 Thread Carsten Ziegeler (JIRA)

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

Carsten Ziegeler edited comment on SLING-2544 at 7/24/12 9:24 AM:
--

Thanks for the work, Antonio!

As you commented we should not add them to the resourceresolver project due to 
the dependencies. I'm not 100% sure where to put this, but maybe the launchpad 
test services is a good place? I think these tests should run in a launched 
instance on the server side, so we always test the latest combination of the 
resourceresolver and jcr resource bundle

  was (Author: cziegeler):
Thanks for the work, Antonio!

As you commented we should not add them to the resourceresolver project due to 
the dependencies. I'm not 100% sure where to put this, but maybe the launchpad 
test services is a good place? I think these tests should run in a launed 
instance on the server side, so we always test the latest combination of the 
resourceresolver and jcr resource bundle
  
> Restore tests included in the no longer existing JcrResourceResolverTest 
> -
>
> Key: SLING-2544
> URL: https://issues.apache.org/jira/browse/SLING-2544
> Project: Sling
>  Issue Type: New Feature
>  Components: ResourceResolver
>Reporter: Antonio Sanso
> Attachments: JcrResourceResolverTest.java, 
> SynchronousJcrResourceListener.java
>
>
> With SLING-2396 almost all the testsincluded in the no longer existing 
> JcrResourceResolverTest e.g. testResolveVirtualHostHttp80()/ 
> testResolveResourceAlias()/ ... have been "lost in translation".
> I think it would be really useful to restore them specially for regression 
> detection

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Resolved] (SLING-2524) Improve package refresh behaviour

2012-07-24 Thread Carsten Ziegeler (JIRA)

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

Carsten Ziegeler resolved SLING-2524.
-

   Resolution: Fixed
Fix Version/s: Installer Core 3.3.8

> Improve package refresh behaviour
> -
>
> Key: SLING-2524
> URL: https://issues.apache.org/jira/browse/SLING-2524
> Project: Sling
>  Issue Type: Improvement
>  Components: Installer
>Affects Versions: Installer Core 3.3.6
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Installer Core 3.3.8
>
>
> Right now when packages are installed or updated, there is a refresh on all 
> bundles.
> We could improve this by collecting all changed/installed bundles resp host 
> bundles for fragments and just refresh those

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Resolved] (SLING-2525) Improve internal task handling

2012-07-24 Thread Carsten Ziegeler (JIRA)

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

Carsten Ziegeler resolved SLING-2525.
-

   Resolution: Fixed
Fix Version/s: Installer Core 3.3.8

> Improve internal task handling
> --
>
> Key: SLING-2525
> URL: https://issues.apache.org/jira/browse/SLING-2525
> Project: Sling
>  Issue Type: Improvement
>  Components: Installer
>Affects Versions: Installer Core 3.3.6
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Installer Core 3.3.8
>
>
> Currently internal task handling like the restarting of bundles or package 
> refreshs are not handled properly, especially they do not survice a restart 
> of the installer.
> I guess the easiest way would be to create artifical resources for this and 
> handle them by special task factories. This would persists these tasks ootb 
> and would also allow to add arbitrary information to each task

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Assigned] (SLING-2311) Sling Performance Testing tool

2012-07-24 Thread Carsten Ziegeler (JIRA)

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

Carsten Ziegeler reassigned SLING-2311:
---

Assignee: (was: Carsten Ziegeler)

> Sling Performance Testing tool
> --
>
> Key: SLING-2311
> URL: https://issues.apache.org/jira/browse/SLING-2311
> Project: Sling
>  Issue Type: New Feature
>  Components: Testing
>Reporter: Antonio Sanso
>Priority: Minor
> Attachments: ResolveWithManyAliasTest.java, 
> ResolveWithManyVanityPath.png, SLING-2311-patch.txt
>
>
> As described/discussed in [0] it would be nice to have a performance test 
> tool in Sling .
> This can be useful in different situations (e.g. micro benchmarks of a 
> feature and so on).
> Patch to follow
> [0] http://sling.markmail.org/message/bz44im7aqeae4r57

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




Jenkins build is unstable: sling-trunk-1.5 #1719

2012-07-24 Thread Apache Jenkins Server
See 



[jira] [Resolved] (SLING-2487) Check / Improve installer logging

2012-07-24 Thread Carsten Ziegeler (JIRA)

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

Carsten Ziegeler resolved SLING-2487.
-

Resolution: Fixed

> Check / Improve installer logging
> -
>
> Key: SLING-2487
> URL: https://issues.apache.org/jira/browse/SLING-2487
> Project: Sling
>  Issue Type: Bug
>  Components: Installer
>Affects Versions: Installer Core 3.3.6
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Installer Core 3.3.8
>
>
> We should check the logging of the installer and its task and see where we 
> might need additional log messages. Especially all tasks should do proper 
> logging.
> For example the refresh bundle task does not log its action

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




Jenkins build is back to stable : sling-trunk-1.5 » Apache Sling Installer Integration Tests #1720

2012-07-24 Thread Apache Jenkins Server
See 




Jenkins build is back to stable : sling-trunk-1.5 » Apache Sling JCR Resource Resolver #1720

2012-07-24 Thread Apache Jenkins Server
See 




Jenkins build is still unstable: sling-trunk-1.5 » Apache Sling Launchpad Testing #1720

2012-07-24 Thread Apache Jenkins Server
See 




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

2012-07-24 Thread Apache Jenkins Server
See 




Jenkins build is still unstable: sling-trunk-1.5 #1720

2012-07-24 Thread Apache Jenkins Server
See 



[jira] [Commented] (SLING-2536) JcrResourceBundle breaks the contract of getLocale

2012-07-24 Thread Alexander Klimetschek (JIRA)

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

Alexander Klimetschek commented on SLING-2536:
--

What does request.getLocale() return? How does your code look like?

> JcrResourceBundle breaks the contract of getLocale
> --
>
> Key: SLING-2536
> URL: https://issues.apache.org/jira/browse/SLING-2536
> Project: Sling
>  Issue Type: Bug
>Affects Versions: i18n 2.2.2
>Reporter: Endolf
>
> The javadoc for getLocale state that it should return the locale of this 
> bundle or the locale of the fallback. Currently JcrResourceBundle always 
> returns the requested locale even if there is no mix:language for that locale.
> e.g. Only a mix:language with a jcr:language en is in the jcr, a request for 
> a resource bundle of sv will return a ResourceBundle object where getLocale 
> returns sv. This should return en according to the javadoc.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (SLING-2536) JcrResourceBundle breaks the contract of getLocale

2012-07-24 Thread Endolf (JIRA)

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

Endolf commented on SLING-2536:
---

getLocale() always returns the locale that was asked for, even when it's fallen 
back to something else. I can't paste the code in here, but here is what I've 
done.

I've extended the SetBundleTag from the standard el tag library, in the 
doEndTag I get the locale from the request from pageContext, then I get the 
request, cast to a SlingHttpServletRequest and call the getResourceBundle 
method passing in the bundle basename and the locale I just got from the 
request.

I think store that in javax.servlet.jsp.jstl.fmt.localizationContext in page 
context so that the standard fmt tags can use the bundle.

We then just use the standard tags to access the bundle as we would in any 
other j2ee app.



> JcrResourceBundle breaks the contract of getLocale
> --
>
> Key: SLING-2536
> URL: https://issues.apache.org/jira/browse/SLING-2536
> Project: Sling
>  Issue Type: Bug
>Affects Versions: i18n 2.2.2
>Reporter: Endolf
>
> The javadoc for getLocale state that it should return the locale of this 
> bundle or the locale of the fallback. Currently JcrResourceBundle always 
> returns the requested locale even if there is no mix:language for that locale.
> e.g. Only a mix:language with a jcr:language en is in the jcr, a request for 
> a resource bundle of sv will return a ResourceBundle object where getLocale 
> returns sv. This should return en according to the javadoc.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




Re: [RT] API for modifying resources

2012-07-24 Thread Carsten Ziegeler
Thanks Tobi,

so I think we'll go with the update() method.

Carsten

2012/7/21 Tobias Bocanegra :
> Hi,
> I like the 2nd idea better, as you get direct feedback when operating
> on the map, e.g. if a property can't be set.
>
> however, the writing map methods are:
> - put()
> - putAll()
> - remove()
> - clear()
>
> and I would throw a IllegalStateException if they fail (clear() will
> most likely never succeed, since jcr:primaryType is not deletable :-)
>
> and there are also indirect operations that modify the map:
> - keySet().* writing ops
> - values().* writing ops
> - entrySet().* wrirting ops
>
> so given the complexity, I think it's better to delay the writeback
> until update() is called. You loose the fine granular information of
> what failed, but in my experience the user cannot really do anything
> when e.g. a setProperty() fails, but just retry.
> (and there is stil the workaround to update() after each put())
>
> Additionally, the PersistException (or whatever update() throws) could
> have a 'getFailedOperations()' method that list the failed operations.
>
> regards, toby
>
> On Wed, Jul 18, 2012 at 12:30 AM, Carsten Ziegeler  
> wrote:
>> Hi,
>>
>> I'm currently working on CRUD support for Sling based on the resource
>> API. Current trunk contains already a version of it.
>> I'm wondering what the best api for modifying resources is.
>>
>> Right now, the idea is to adapt a resource to ModifiableValueMap which
>> is an extension of the ValueMap. Like the PersistableValueMap this map
>> collects all changes internally. It provides an update() method which
>> pushes the changes into the transient persistence layer (e.g. jcr
>> session). A call to the resource resolver finally persists all
>> transient changes (let's forget about different resource providers and
>> transactions for now)
>> This approach has the advantage to reuse the map interface to change
>> values, no exceptions are thrown on put and remove. - but it requires
>> to additional calls, update on the map and commit on the resource
>> resolver to get the changes persisted.
>>
>> I thought of changing this and push each change directly into the
>> transient store, so a call to put() or remove() on the map is directly
>> pushed through - this avoids the extra call to update(), however put()
>> and remove() have no checked exceptions declared. So we can either
>> throw undeclared exceptions (which I think is not really a good idea
>> in this case) or defer exception throwing until the commit call on the
>> resource resolver. But obviously this gets nasty if e.g. a put() is
>> not successful, doesn't throw an exception and one is doing a get on
>> the same property etc.
>>
>> So, final solution would be to add special methods like set and delete
>> which might throw PersistenceException - and avoid reuse of modifying
>> methods from the map interface. Simpler to use compared to the current
>> version in trunk but additional methods.
>>
>> Right now I'm undecided between the first and the last solution - with
>> a slight preference of the current version from trunk.
>>
>> But maybe there are other/better options?
>>
>> Regards
>> Carsten
>> --
>> Carsten Ziegeler
>> cziege...@apache.org



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