[jira] Commented: (SLING-917) Use repository.apache.org for deployments
[ https://issues.apache.org/jira/browse/SLING-917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12718001#action_12718001 ] Carsten Ziegeler commented on SLING-917: Added a profile for rat and the ianal plugin to check legal files in revision 783270 > Use repository.apache.org for deployments > - > > Key: SLING-917 > URL: https://issues.apache.org/jira/browse/SLING-917 > Project: Sling > Issue Type: Task > Components: General >Affects Versions: Parent 5 >Reporter: Bertrand Delacretaz > Fix For: Parent 6 > > Attachments: SLING-917.patch > > > See INFRA-1896 for getting access to repository.apache.org . > Once that's done, we'll need to configure http://vmbuild.apache.org to push > snapshots there. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Pax Exam based integration testing (before: "mvn clean" should delete "sling" work folders)
Hi, I have just finished a rough draft [1] of our integration tests using Pax Exam [2]. Only "CreateNodeTest" until now. I have had to make some changes in order to re-use our prior integration testing stuff: * HttpTestBase [3] doesn´t extend TestCase anymore and extends PaxExamTestBase [4] instead. * commons-httpclient and commons-codec has been provided as bundles from servicemix bundles distribution [5] for convenience. * o.a.s.commons.testing has been provided in a wrapped way. Maybe we could make a bundle of this later. In the other hand, I have used the jcrinstall Bertrand´s code to make all system properties available to OSGi framework VM instance and set optional debugging. Thanks Bertrand :). IMO the main drawback of this approach is that test execution become slower than before because every test is run in its own container instance. Although there is an opened issue to look for a workaround [6], this could not be so bad in order to run each test kept in isolation. As far this is concerned, I have not a clear opinion right now. In the other hand, this kind of testing offers some advantages such as OSGi container vendor pluggability. WDYT?. [1] http://svn.apache.org/repos/asf/incubator/sling/whiteboard/jvazquez/testing [2] http://wiki.ops4j.org/display/paxexam/Pax+Exam [3] http://svn.apache.org/repos/asf/incubator/sling/whiteboard/jvazquez/testing/src/test/java/org/apache/sling/itest/HttpTestBase.java [4] http://svn.apache.org/repos/asf/incubator/sling/whiteboard/jvazquez/testing/src/test/java/org/apache/sling/itest/PaxExamTestBase.java [5] http://repo2.maven.org/maven2/org/apache/servicemix/bundles/ [6] http://issues.ops4j.org/browse/PAXEXAM-79 On Mon, Apr 6, 2009 at 11:08 AM, Felix Meschberger wrote: > Hi, > > Juan José Vázquez Delgado schrieb: >>> Do you know it a bit ? Can you take a stab at converting the current >>> Cargo based setup to be using Pax Exam ? >> >> First time for me. I´m gonna try this and tell us. > > Great ! Thanks. > > Regards > Felix > > >
[jira] Commented: (SLING-904) jcrinstall - take three
[ https://issues.apache.org/jira/browse/SLING-904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12718022#action_12718022 ] Bertrand Delacretaz commented on SLING-904: --- Start level changes removed in revision 783282 > jcrinstall - take three > --- > > Key: SLING-904 > URL: https://issues.apache.org/jira/browse/SLING-904 > Project: Sling > Issue Type: Improvement > Components: JCR Install >Reporter: Bertrand Delacretaz > > Refactor and reengineer jcrinstall based on the accumulated experiences of > the "take two", SLING-646. > See discussion in http://markmail.org/message/ld6tkz6fdseknntx -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Caching for ResourceResolver.map()
Hi, I have a case where we're doing lots of reverse mappings with the ResourceResolver.map() method and all the repository accesses caused by that are hurting performance. In general I'm not a big fan of extra caching, but in this case it seems like the only easy way to solve the problem. Would it make sense to embed such caching into JcrResourceResolver2 or should it rather be a separate add-on layer? The former approach would avoid complexities with the HttpServletRequest argument affecting the caching, while the latter would make it easier to only apply the caching in limited cases where it's truly needed (though at the cost of the cache not being global). BR, Jukka Zitting
Re: Caching for ResourceResolver.map()
Hi, Jukka Zitting schrieb: > Hi, > > I have a case where we're doing lots of reverse mappings with the > ResourceResolver.map() method and all the repository accesses caused > by that are hurting performance. In general I'm not a big fan of extra > caching, but in this case it seems like the only easy way to solve the > problem. > > Would it make sense to embed such caching into JcrResourceResolver2 or > should it rather be a separate add-on layer? The former approach would > avoid complexities with the HttpServletRequest argument affecting the > caching, while the latter would make it easier to only apply the > caching in limited cases where it's truly needed (though at the cost > of the cache not being global). I think we should embed the caching rather deeply into the JcrResourceResolver2 to leverage as much globally valid cache data as possible. What we might consider is doing per-user caches to leverage access control of the repository. And while implementing a cache for the map() methods, implementing a cache for the resolve() methods would probably come in handy and almost free, since both methods internally use the same resolveInternal() method. Regards Felix
Hudson build became unstable: sling-contrib-1. 5 » Apache Sling Launchpad Contrib Testing #71
See http://hudson.zones.apache.org/hudson/job/sling-contrib-1.5/org.apache.sling$org.apache.sling.launchpad.contrib-testing/71/
Re: Caching for ResourceResolver.map()
Jukka Zitting wrote: > Hi, > > I have a case where we're doing lots of reverse mappings with the > ResourceResolver.map() method and all the repository accesses caused > by that are hurting performance. In general I'm not a big fan of extra > caching, but in this case it seems like the only easy way to solve the > problem. > > Would it make sense to embed such caching into JcrResourceResolver2 or > should it rather be a separate add-on layer? The former approach would > avoid complexities with the HttpServletRequest argument affecting the > caching, while the latter would make it easier to only apply the > caching in limited cases where it's truly needed (though at the cost > of the cache not being global). > While caching in the resource resolver might be a good idea anyway, perhaps caching one layer above might give even more benefit. Instead of querying the resource resolver a lot, caching above the resolver would even avoid querying the resolver. Carsten -- Carsten Ziegeler cziege...@apache.org
Re: Moving rewriter to contrib
Bertrand Delacretaz wrote: > Hi Carsten, > > On Tue, Jun 9, 2009 at 2:17 PM, Carsten Ziegeler wrote: >> ...I'm planning to move this from the whiteboard to the contrib section. >> If noone objects, I'll do this in the next days > > In principle I'm all for it, but > > > http://svn.apache.org/repos/asf/incubator/sling/whiteboard/rewriter/src/test > > returns a 404 ;-) :) > > Can I haz tests? Or maybe a simple smoke-test-the-whole-thing test in > launchpad/testing is easier? I guess testing this in launchpad should be easier. Regards Carsten -- Carsten Ziegeler cziege...@apache.org
Re: Integrate a Servlet Filter: init-params
Ok, I am a step further with the integration: I still have to find out about the dynamic providing of init-params, but I do see that the filterConfig is there & populated with the @scr.property values. Good stuff! Now, there is a problem within the chain handling: the webcastellum filter uses it's own wrapper for requests and response, and supplies it to the chain in the chain.doFilter() call. This leads to a ClassCastException on line 54 of AbstractSlingFilterChain: ... RequestProgressTracker tracker = ((SlingHttpServletRequest) request).getRequestProgressTracker(); ... I am not sure if this cast is valid in the context of a filter chain. On the other hand I am not sure wether such a use case (filter that manipulates request and response) has a chance to run in Sling. WDYT? java.lang.ClassCastException: org.webcastellum.RequestWrapper cannot be cast to org.apache.sling.api.SlingHttpServletRequest at org.apache.sling.engine.impl.filter.AbstractSlingFilterChain.doFilter (AbstractSlingFilterChain.java:54) at org.webcastellum.WebCastellumFilter.internalDoFilter(WebCastellumFilt er.java:2610) at org.webcastellum.WebCastellumFilter.doFilter(WebCastellumFilter.java: 1710)
Re: Integrate a Servlet Filter: init-params
Hi Christian, Christian Sprecher schrieb: > Ok, I am a step further with the integration: I still have to find out > about the dynamic providing of init-params, but I do see that the > filterConfig is there & populated with the @scr.property values. Good > stuff! ;-) > > Now, there is a problem within the chain handling: the webcastellum > filter uses it's own wrapper for requests and response, and supplies it > to the chain in the chain.doFilter() call. This leads to a > ClassCastException on line 54 of AbstractSlingFilterChain: > ... >RequestProgressTracker tracker = ((SlingHttpServletRequest) > request).getRequestProgressTracker(); > ... > > I am not sure if this cast is valid in the context of a filter chain. On > the other hand I am not sure wether such a use case (filter that > manipulates request and response) has a chance to run in Sling. > > WDYT? I would say, that this is really not a good thing. The AbstractSlingFilterChain should use internal API of the Engine bundle to access the real request progress tracker. Could you please file an issue ? Thanks alot. Regards Felix > > > java.lang.ClassCastException: org.webcastellum.RequestWrapper cannot be > cast to > org.apache.sling.api.SlingHttpServletRequest >at > org.apache.sling.engine.impl.filter.AbstractSlingFilterChain.doFilter > (AbstractSlingFilterChain.java:54) >at > org.webcastellum.WebCastellumFilter.internalDoFilter(WebCastellumFilt > er.java:2610) >at > org.webcastellum.WebCastellumFilter.doFilter(WebCastellumFilter.java: > 1710) > >
Re: Integrate a Servlet Filter: init-params
Hi, Christian Sprecher schrieb: > Hi Felix > > Felix Meschberger schrieb: >> >> Actually, the Sling Main Servlet initializes servlets and filters by >> calling the respective init(ServletConfig) and init(FilterConfig) >> methods. >> >> The parameters provided by the ServletConfig and/or FilterConfig (the >> traditional init-param settings) are taken from the OSGi service >> registration properties. >> >> This is actually quite interesting: For example by using declarative >> services you may have OSGi Configuration (from ConfigurationAdmin) added >> as service registration properties and thus as ServletConfig or >> FilterConfig parameters. This means you will have live-configuration >> support for such parameters ! >> >> > > Interesting indeed! Could you plz elaborate a bit? What do I have to do > to have such a servlet of filter properly configurated? Using the > scr-plugin, are all @scr.property automatically made available to the > filter? Yes. And if you have the scr plugin generate the Metatype data (not setting metatype="no" on the @scr.component tag) you will be able to configure the properties on the Configuration page of the Web Console. > > This live-configuration possibility sounds superb for my use case: I am > trying to integrate WebCastellum (http://www.webcastellum.org) with > Sling. WebCastellum is a web application firewall implemented as filter. > This WAF is configured via init-param. The possibilty to configure that > WAF in real-time is intriguing... Interesting. Would you be able to provide some description of this in the Wiki ? Thanks in advance. Regards Felix > > Cheers > > CSp >
[jira] Created: (SLING-1001) Take the Maven -SNAPSHOT convention into account when comparing bundle version numbers
Take the Maven -SNAPSHOT convention into account when comparing bundle version numbers -- Key: SLING-1001 URL: https://issues.apache.org/jira/browse/SLING-1001 Project: Sling Issue Type: Improvement Components: JCR Install Affects Versions: JCR Install 2.0.4 Reporter: Bertrand Delacretaz When doing Maven-based development, it is common to create a new version of a bundle with the same xyz-SNAPSHOT version number as the previous one. Currently, jcrinstall does not update the bundle if a new one with the same xyz-SNAPSHOT version number is copied into the repository. It should update in this case, i.e. consider the bundle as a new version if the version string is the same as the installed one but contains -SNAPSHOT. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1001) Take the Maven -SNAPSHOT convention into account when comparing bundle version numbers
[ https://issues.apache.org/jira/browse/SLING-1001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12718321#action_12718321 ] Bertrand Delacretaz commented on SLING-1001: This behavior should be configurable (configure the -SNAPSHOT string, empty means no special behavior), as there could be unwanted side effects. > Take the Maven -SNAPSHOT convention into account when comparing bundle > version numbers > -- > > Key: SLING-1001 > URL: https://issues.apache.org/jira/browse/SLING-1001 > Project: Sling > Issue Type: Improvement > Components: JCR Install >Affects Versions: JCR Install 2.0.4 >Reporter: Bertrand Delacretaz > > When doing Maven-based development, it is common to create a new version of a > bundle with the same xyz-SNAPSHOT version number as the previous one. > Currently, jcrinstall does not update the bundle if a new one with the same > xyz-SNAPSHOT version number is copied into the repository. > It should update in this case, i.e. consider the bundle as a new version if > the version string is the same as the installed one but contains -SNAPSHOT. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
