Hi Julian, I'll create a Jira-Task as soon as I'll have time for that. As far as I'm informed, you and me are going to meet at march, 31st in Frankfurt. Let's discuss the use case and our solutions then.
Regards, Thomas Praxl Software Engineer -------------------------------------------------- namics (deutschland) gmbh - a PubliGroupe company Gutleutstrasse 96 D-60329 Frankfurt am Main T +49 (0) 69 36 50 59 263 http://www.namics.com, http://blog.namics.com mailto: [email protected] -------------------------------------------------- Handelsregister B des Amtsgerichts Frankfurt a.M. Reg.-Nr. HRB 57721 / Sitz: Frankfurt a.M. Geschäftsführerin: Elke Schreckenbach ?????????????????????????????????- > Europäisches Accessibility Forum 27.03.09 in Frankfurt am Main http://www.namics.com/accessibility_mm > Referat: JAX '09 20.-24.04.09 in Mainz Buildsysteme: Welches hätten Sie denn gerne? Markus Stäuble, namics (deutschland) gmbh http://it-republik.de/jaxenter/jax/sessions/?tid=1054#session-7 > E-Commerce Conference in München 30.04.09 Conversion Rate Optimization, Eva Johannis, namics (deutschland) gmbh http://www.namics.com/events-wissen/daten-events/e-commerce-conference.html Julian Sedding <[email protected]> wrote on 25.03.2009 11:00:25: > From: > > Julian Sedding <[email protected]> > > To: > > [email protected] > > Date: > > 25.03.2009 11:01 > > Subject: > > Re: JcrResourceResolver getSearchPath never called from JcrResourceResolver? > > Hi Thomas > > I agree that your suggestion to wrap factory.getSearchPath() in a > method getSearchPathInternal() would simplify sub-classing > JcrResourceResolver. And even though I believe it is an edge use-case, > you may create a Jira and attach a patch. > > It would be interesting if you could explain your use-case. At the > moment, I cannot imagine why you would want to change your search path > dynamically. > > Regards > Julian > > > > On Wed, Mar 25, 2009 at 9:54 AM, Thomas Praxl <[email protected]> wrote: > > Hi Julian, > > > > thanks for your reply. > > However we need dynamic search-paths and thus cannot just configure them. > > It's not a problem though, I just wanted to tell you, that there's a more > > convenient way from my cases' point of view. > > Maybe you're going to change the implementation slightly in order to have > > it behave more like one would expect (at least I would). > > > > Regards, > > > > Thomas Praxl > > Software Engineer > > -------------------------------------------------- > > namics (deutschland) gmbh - a PubliGroupe company > > Gutleutstrasse 96 > > D-60329 Frankfurt am Main > > > > T +49 (0) 69 36 50 59 263 > > http://www.namics.com, http://blog.namics.com > > mailto: [email protected] > > -------------------------------------------------- > > Handelsregister B des Amtsgerichts Frankfurt a.M. > > Reg.-Nr. HRB 57721 / Sitz: Frankfurt a.M. > > Geschäftsführerin: Elke Schreckenbach > > ?????????????????????????????????- > >> Europäisches Accessibility Forum > > 27.03.09 in Frankfurt am Main > > http://www.namics.com/accessibility_mm > > > >> Referat: JAX '09 20.-24.04.09 in Mainz > > Buildsysteme: Welches hätten Sie denn gerne? Markus Stäuble, namics > > (deutschland) gmbh > > http://it-republik.de/jaxenter/jax/sessions/?tid=1054#session-7 > > > >> E-Commerce Conference in München > > 30.04.09 Conversion Rate Optimization, Eva Johannis, namics (deutschland) > > gmbh > > http://www.namics.com/events-wissen/daten-events/e-commerce-conference.html > > > > > > > > > > Julian Sedding <[email protected]> wrote on 20.03.2009 21:50:00: > > > >> From: > >> > >> Julian Sedding <[email protected]> > >> > >> To: > >> > >> [email protected] > >> > >> Date: > >> > >> 20.03.2009 21:50 > >> > >> Subject: > >> > >> Re: JcrResourceResolver getSearchPath never called from > > JcrResourceResolver? > >> > >> Hi Thomas > >> > >> You can change the search paths via configuration. Select the > >> "Configuration" tab in the Felix console and select "Apache Sling > >> Resource Resolver" in the drop-down (or simply [1]). In the Resource > >> Resolver config panel you can add and remove search paths as you like. > >> > >> Regards, > >> Julian > >> > >> [1] http://<host>:<port>/system/console/configMgr/ > >> org.apache.sling.jcr.resource.internal.JcrResourceResolverFactoryImpl > >> > >> > >> On Fri, Mar 20, 2009 at 8:21 PM, Thomas Praxl <[email protected]> > > wrote: > >> > Hi, > >> > > >> > I just wanted to decorate JcrResourceResolver in order to extend the > >> > search-path. > >> > However, the fact that JcrResourceResolver doesn't call it's own > > method > >> > getSearchPath, but factory.getSearchPath, forces me not just to > > decorate > >> > getSearchPath, but also getResource. > >> > That behaviour is kind of weird for my cases' point of view. There's a > >> > comment though indicating, that this.getSearchPath should not be > > called, > >> > in order to save a few cycles. > >> > > >> > getResource: > >> > // (don't use this.getSearchPath() to save a few cycle for not > > cloning) > >> > for (String prefix : factory.getSearchPath()) { > >> > > >> > The method getSearchPath of JcrResourceResolver clones the result of > >> > factory.getSearchPath. > >> > > >> > public String[] getSearchPath() { > >> > return factory.getSearchPath().clone(); > >> > } > >> > > >> > It saves few cycles not to clone the result, but is just not very > >> > convenient from my point of view. > >> > I'd propose to change the implementation in the following way: > >> > > >> > getResource: > >> > for(String prefix:getSearchPathInternal()){ > >> > > >> > public String[] getSearchPath(){ > >> > return getSearchPathInternal().clone(); > >> > } > >> > protected String[] getSearchPathInternal(){ > >> > return factory.getSearchPath(); > >> > } > >> > > >> > That way, I could just decorate the internal method, the defensive > > copy > >> > would reside for public usage and there would be just one additional > >> > method-call. > >> > > >> > Greetings, > >> > > >> > > >> > > >> > Thomas Praxl > >> > Software Engineer > >> > -------------------------------------------------- > >> > namics (deutschland) gmbh - a PubliGroupe company > >> > Gutleutstrasse 96 > >> > D-60329 Frankfurt am Main > >> > > >> > T +49 (0) 69 36 50 59 263 > >> > http://www.namics.com, http://blog.namics.com > >> > mailto: [email protected] > >> > -------------------------------------------------- > >> > Handelsregister B des Amtsgerichts Frankfurt a.M. > >> > Reg.-Nr. HRB 57721 / Sitz: Frankfurt a.M. > >> > Geschäftsführerin: Elke Schreckenbach > >> > ?????????????????????????????????- > >> >> Europäisches Accessibility Forum > >> > 27.03.09 in Frankfurt am Main > >> > http://www.namics.com/accessibility_mm > >> > > >> >> Referat: JAX '09 20.-24.04.09 in Mainz > >> > Buildsysteme: Welches hätten Sie denn gerne? Markus Stäuble, namics > >> > (deutschland) gmbh > >> > http://it-republik.de/jaxenter/jax/sessions/?tid=1054#session-7 > >> > > >> >> E-Commerce Conference in München > >> > 30.04.09 Conversion Rate Optimization, Eva Johannis, namics > > (deutschland) > >> > gmbh > >> > > > http://www.namics.com/events-wissen/daten-events/e-commerce-conference.html > > > >> > > >> > > >> > > > > >
