Re: [discussion] allow Script Engines to also render components based on paths
I'm in agreement with Justin and Bertrand that the developer (and not the administrator) is the right person to author this information. I'm on the fence regarding whether to put it in the file or use a property. (If we do use a property, it should be inherited so it can be put on entire sub-trees easily.) Cheers, Jeff. On 26/01/2015 09:24, Bertrand Delacretaz bdelacre...@apache.org wrote: On Sat, Jan 24, 2015 at 12:34 PM, Justin Edelson jus...@justinedelson.com wrote: ...Only the developer knows how to map their scripts to the right engine And the developer creates scripts under /apps/foo for project foo, so it makes absolute sense to set a sling:script property on /apps/foo to indicate a preference for one script engine over another under there. -Bertrand
Re: Removing or at least deprecating JcrItemAdapterFactory
+1 (to showing deprecation in console) On 20/08/2014 17:33, Carsten Ziegeler cziege...@apache.org wrote: I think we don't - and for now it would be the factory implementation doing the stuff. It would be great to show something in the console. Maybe through the annotations? Carsten 2014-08-20 18:26 GMT+02:00 Justin Edelson jus...@justinedelson.com: This would be OK with me. Out of curiosity, do we actually have a way of deprecating adapter factories? Or would such a warning be the responsibility of the adapter factory? Should we add something to the web console plugin to indicate that an adaption is deprecated. Justin On Wed, Aug 20, 2014 at 11:57 AM, Carsten Ziegeler cziege...@apache.org wrote: Yes, so how do you feel about deprecating it, log a bold message (once) - and then maybe remove it in one of the next versions? Regards Carsten 2014-08-20 17:48 GMT+02:00 Justin Edelson jus...@justinedelson.com: Hi Carsten, I'd rather keep it, but... I don't actually see a good way to fix SLING-3859, so it might be more expedient to deprecate this. Or at least log a warning that the ResourceResolver must be manually closed. Justin On Wed, Aug 20, 2014 at 11:29 AM, Carsten Ziegeler cziege...@apache.org wrote: Thanks Justin, so either we have to fix the memory leak or go without it :) What do you prefer? Regards Carsten 2014-08-20 13:52 GMT+02:00 Justin Edelson jus...@justinedelson.com: Hi, On Wed, Aug 20, 2014 at 1:47 AM, Bertrand Delacretaz bdelacre...@apache.org wrote: Hi, On Tue, Aug 19, 2014 at 8:38 PM, Carsten Ziegeler cziege...@apache.org wrote: ...I think this adaption is conceptually wrong and I have no idea why we added this in the first place, so adding this to the memory leak problem, I would simply remove this thing It was added by Justin for SLING-2315 - I am ok with deprecating and later removing it, but let's hear Justin. I find this to be of high utility when dealing with legacy code which only makes a Node object available. I don't actually know that I've ever used the Property adaptatation part, but I definitely use the Node - Resource adaptation a few times a year. Could I live without it? Sure, especially as now that the ResourceResolverFactory code is much more complex than it was at the time. Justin -Bertrand -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: Deprecating JcrResource.adaptTo(URL) ?
+1 (to deprecating adaptTo(URL), and to deprecation comments in the other thread) Cheers, Jeff. On 20/08/2014 17:29, Justin Edelson jus...@justinedelson.com wrote: Hi, I'm fine with this, although I'm see my other email about what it means to deprecate an adapter factory. Justin On Wed, Aug 20, 2014 at 11:59 AM, Carsten Ziegeler cziege...@apache.org wrote: Hi, the JCR Resource implementation currently allows to adapt it to a url which internally embeds several jackrabbit classes. The returned object keeps hold of the current session and therefore is a potential memory leak and can't be used once the session is closed. So far I've not seen any real use case for this and especially as other resource implementations do not provide it, what about deprecating this now, logging a big message when used (once) and then we can remove it in one of the next versions? Regards Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: Sling Request Filter filtering
Hi Felix, I think to reduce the unexpected you'd need filter.resourceType to match on the resource's supertype hierarchy too. Cheers, Jeff. On 18/08/2014 10:23, Felix Meschberger fmesc...@adobe.com wrote: Hi all I had various discussions around execution of Servlet API Filters in the Sling Engine. To recap: Currently all filters are always called. The service.ranking (or filter.order) service registration property can be used to define the order in which the filters are called and the filter.scope property is required to indicate at what stage in the request processing a filter has to be called. See [1] for the full story. Turns out, that it would be good to have some simple and global flags to indicate when a filter should actually be called or not. This would be similar to the filter mappings of traditional web applications, where filters are bound to URL paths and/or servlets. So I am proposing to introduce three new service registration properties, which may be set on Servlet Filter services handled by the Sling Engine: * filter.path: The Filter is only called if the path of the current Resource (SlingHttpServletRequest.getResource) matches any of the given paths. If the property is not set, the filter will always be called. * filter.resourceType: The Filter is only called if the resourceType of the current Resource (SlingHttpServletRequest.getResource) matches any of the given resource types. If the property is not set, the filter will always be called. * filter.ignore: The Filter is never called if this property is set to any true. The implementation would be as follows: * The FilterListEntry class is augmented with a method to verify whether to call the filter at all * The AbstractSlingFilterChain.doFilter method is augmented to call this new method and to not call a filter for which the match fails. A RequestProgressTracker entry is generated for filters not called indicating why it has not been called. Further extensions could be: * filter.expression: some scripting expression evaluating to a boolean. If true the filter is called. * Filter service implements a new interface providing an filter expression method returning a boolean. If true the filter is called (comparable to the option servlet). Regards Felix [1] http://sling.apache.org/documentation/the-sling-engine/filters.html
Re: adaptTo and results ....
adaptTo() is currently commonly used as a test, similar to instanceof.
Throwing and catching to return null is a very poor implementation
(performance-wise) for this use.
Adding a hasAdapter() or canAdaptTo() might decrease the number of
implementations that think throwing is OK, but only if the new interface
is visible at the level of the specific implementation. (If they're just
done as wrappers with catches somewhere in the machinery, and the
AdapterFactory writer is unaware of them, then they probably don't help
this issue.)
Cheers,
Jeff.
On 01/07/2014 08:44, Konrad Windszus konra...@gmx.de wrote:
Regarding 1) Having such a Result class would mean that all consumer
would need to unwrap the exception first. So instead of being forced of
implementing a null-check (as with the old solution) one would need to
implement another check. I want to prevent such a burden to the consumers.
Regarding 2) Since the client code knows on which object the
adaptToOrThrow is called I don¹t get why an instanceof check is
necessary. Whether this object implements Adaptable2 is known at
compile-time, so you do have the full IDE-support here.
Regarding 3) In that case I would no longer allow a null value to be
returned. One drawback is, that all the null checks are no longer
effective.
IMHO solution 2) is the best. At the same time I would deprecate the old
Adaptable, because I cannot come up with a real use-case where returning
has an advantage. I would rather implement another method boolean
hasAdapter(ClassAdapterType type) on the Adaptable2 interface.
Regards,
Konrad
On 01 Jul 2014, at 09:07, Felix Meschberger fmesc...@adobe.com wrote:
Hi
There currently are two issues floating around dealing with the
question of returning more information than just null from the
Adaptable.adaptTo(Class) method:
https://issues.apache.org/jira/browse/SLING-3714 and
https://issues.apache.org/jira/browse/SLING-3709. I think these requests
warrant some discussion on the list.
Background: adaptTo can be implemented by Adaptable implementations
themselves or, by extending from SlingAdaptable, they may defer to an
AdapterMananager. AdapterManager itself is extended by AdapterFactory
services. All these interfaces define an adaptTo method. All these
methods return null if adaption is not possible and don't declare or
document to throw an exception.
While not explicitly documented as such, the intention is and was that
adaptTo never throws on the grounds that adaption may fail which is
considered a valid result and thus exceptions are not to be expected and
handled.
Hence all implementations of the methods generally
catch-and-log-but-don't-throw. Interestingly SlingAdaptable.adaptTo and
AdapterManagerImpl.getAdapter don't catch ‹ so any RuntimeException
thrown from an AdapterFactory would be forwarded.
Having said this there are options available:
(1) Add support for a new Result? class. We would probably implement
this in the AdapterManager.getAdapter implementation explicitly handling
this case because it would entail catching the adaptTo/getAdapter calls
to get the exception (the Result.getError should return Throwable
probably not Error)
Use would be limited to new AdapterFactory implementations throwing
RuntimeExcpetion. For Sling Models this would be the case.
(2) Add a new adaptToOrThrow method, which is declared to throw a
RuntimeException and never return null: Either it can adapt or it
throws. This would require a new interface Adaptable2 (probably) to not
break existing Adaptable implementations. The SlingAdaptable base class
would implement the new method of course, probably something like this:
SlingAdaptable implements Adaptable2 {
Š
public AdapterType AdapterType adaptToOrThrow(ClassAdapterType
type) {
AdapterType result = this.adaptTo(type);
if (result != null) {
return result;
}
throw new CannotAdaptException(Š);
}
}
Use is problematic because you would have to know whether you can call
the new method: So instead of an null check you now have an instanceof
check Š Except for the Resource interface which would be extended to
extend from Adaptable2 as well.
(3) Document, that Adaptable.adaptTo may throw a RuntimeException.
The problem here is, that this may conceptually break existing callers
of Adaptable.adaptTo which don't expect an exception at all ‹ presumably
this is a minor nuisance because technically a RuntimeException may
always be thrown.
Regards
Felix
Re: adaptTo and results ....
Hi Carsten, Can you say more? (I'm not sure I understand what you're getting at) Thanks, Jeff. On 01/07/2014 09:56, Carsten Ziegeler cziege...@apache.org wrote: adaption and validation are different concerns Carsten 2014-07-01 10:55 GMT+02:00 Jeff Young j...@adobe.com: We could solve that by defining a specific exception for adaptation-not-possible and then catch only that. Of course that would leak tons of exceptions from code written before that exception became available. Maybe do the catching based on some sort of version clue? Cheers, Jeff. On 01/07/2014 09:40, Konrad Windszus konra...@gmx.de wrote: It is not (only) about throwing exceptions in case no suitable adapter is available. It rather is about the fact, that today the adaptTo is a barrier for all kinds of exceptions. In some cases the adaptation fails for a specific reason (one example is Sling Models where injection fails, another one is the issue mentioned in https://issues.apache.org/jira/browse/SLING-2712 (ValueMap not supporting primitives)). Both would be valid use cases where the client would be interested to catch the exception here. On 01 Jul 2014, at 10:34, Carsten Ziegeler cziege...@apache.org wrote: Adding a new interface would require us to implement it all over the place and as Felix points out, client code would always need to check whether the new interface is implemented or not Having to methods, like hasAdapter and adaptOrThrow does not work very well as between the two calls things might have changed already: while hasAdapter returns true, the underlying factory gets unregistered before adaptOrThrow is called. In many use cases, the current pattern works fine - the client does not care whether an exception is thrown within the adaption - it just cares whether an object is returned or not. And there are valid use cases, where client code does different things whether the adaption works or not (e.g. the post servlet checks for adaptTo(Node) and then does additional things if the resource is backed up by a node.) I see the point that there are also use cases where it would be fine to simpy throw an exception if adaptTo is not successful. This would make the client code easier. However as this most properly is a runtime exception, client code can today just call a method on the object and end up with a NPE - having the same result :) This leaves us with use cases where the client code explicitely wants to catch the exception and then do something depending on the exception. Maybe we should just add something for this explicit use case instead of bloating the general adaptTo mechanism? Regards Carsten 2014-07-01 9:44 GMT+02:00 Konrad Windszus konra...@gmx.de: Regarding 1) Having such a Result class would mean that all consumer would need to unwrap the exception first. So instead of being forced of implementing a null-check (as with the old solution) one would need to implement another check. I want to prevent such a burden to the consumers. Regarding 2) Since the client code knows on which object the adaptToOrThrow is called I don¹t get why an instanceof check is necessary. Whether this object implements Adaptable2 is known at compile-time, so you do have the full IDE-support here. Regarding 3) In that case I would no longer allow a null value to be returned. One drawback is, that all the null checks are no longer effective. IMHO solution 2) is the best. At the same time I would deprecate the old Adaptable, because I cannot come up with a real use-case where returning has an advantage. I would rather implement another method boolean hasAdapter(ClassAdapterType type) on the Adaptable2 interface. Regards, Konrad On 01 Jul 2014, at 09:07, Felix Meschberger fmesc...@adobe.com wrote: Hi There currently are two issues floating around dealing with the question of returning more information than just null from the Adaptable.adaptTo(Class) method: https://issues.apache.org/jira/browse/SLING-3714 and https://issues.apache.org/jira/browse/SLING-3709. I think these requests warrant some discussion on the list. Background: adaptTo can be implemented by Adaptable implementations themselves or, by extending from SlingAdaptable, they may defer to an AdapterMananager. AdapterManager itself is extended by AdapterFactory services. All these interfaces define an adaptTo method. All these methods return null if adaption is not possible and don't declare or document to throw an exception. While not explicitly documented as such, the intention is and was that adaptTo never throws on the grounds that adaption may fail which is considered a valid result and thus exceptions are not to be expected and handled. Hence all implementations of the methods generally catch-and-log-but-don't-throw. Interestingly SlingAdaptable.adaptTo
Re: adaptTo and results ....
Hi Carsten, Sure, but Konrad has a point in that I think sometimes the client *does* care why the adaption failed. For instance, if it had to do with something entirely different from whether or not adaption would normally work. Let's say that I have a resource that should adapt to XYZ, but that my adapter is currently buggy. I'd like to get an exception for that, but said exception is going to get eaten. I do agree that if I have a resource that should NOT adapt to XYZ, that getting back null is fine, and that I don't care why the adaption failed. Cheers, Jeff. On 01/07/2014 10:19, Carsten Ziegeler cziege...@apache.org wrote: Sure :) For the adapter pattern, the client does not care why the adaption failed, the client is just interested in the result (success or not) Validation is a different beast, if validation fails you want to know specific reasons why it failed - and this can be multiple. I tried to explain in my first mail on this thread, that all other use cases mentioned can be handled with the current implementation - with the exception of validation. But I think validation requires a different concept than the adapter pattern. Carsten 2014-07-01 11:09 GMT+02:00 Jeff Young j...@adobe.com: Hi Carsten, Can you say more? (I'm not sure I understand what you're getting at) Thanks, Jeff. On 01/07/2014 09:56, Carsten Ziegeler cziege...@apache.org wrote: adaption and validation are different concerns Carsten 2014-07-01 10:55 GMT+02:00 Jeff Young j...@adobe.com: We could solve that by defining a specific exception for adaptation-not-possible and then catch only that. Of course that would leak tons of exceptions from code written before that exception became available. Maybe do the catching based on some sort of version clue? Cheers, Jeff. On 01/07/2014 09:40, Konrad Windszus konra...@gmx.de wrote: It is not (only) about throwing exceptions in case no suitable adapter is available. It rather is about the fact, that today the adaptTo is a barrier for all kinds of exceptions. In some cases the adaptation fails for a specific reason (one example is Sling Models where injection fails, another one is the issue mentioned in https://issues.apache.org/jira/browse/SLING-2712 (ValueMap not supporting primitives)). Both would be valid use cases where the client would be interested to catch the exception here. On 01 Jul 2014, at 10:34, Carsten Ziegeler cziege...@apache.org wrote: Adding a new interface would require us to implement it all over the place and as Felix points out, client code would always need to check whether the new interface is implemented or not Having to methods, like hasAdapter and adaptOrThrow does not work very well as between the two calls things might have changed already: while hasAdapter returns true, the underlying factory gets unregistered before adaptOrThrow is called. In many use cases, the current pattern works fine - the client does not care whether an exception is thrown within the adaption - it just cares whether an object is returned or not. And there are valid use cases, where client code does different things whether the adaption works or not (e.g. the post servlet checks for adaptTo(Node) and then does additional things if the resource is backed up by a node.) I see the point that there are also use cases where it would be fine to simpy throw an exception if adaptTo is not successful. This would make the client code easier. However as this most properly is a runtime exception, client code can today just call a method on the object and end up with a NPE - having the same result :) This leaves us with use cases where the client code explicitely wants to catch the exception and then do something depending on the exception. Maybe we should just add something for this explicit use case instead of bloating the general adaptTo mechanism? Regards Carsten 2014-07-01 9:44 GMT+02:00 Konrad Windszus konra...@gmx.de: Regarding 1) Having such a Result class would mean that all consumer would need to unwrap the exception first. So instead of being forced of implementing a null-check (as with the old solution) one would need to implement another check. I want to prevent such a burden to the consumers. Regarding 2) Since the client code knows on which object the adaptToOrThrow is called I don¹t get why an instanceof check is necessary. Whether this object implements Adaptable2 is known at compile-time, so you do have the full IDE-support here. Regarding 3) In that case I would no longer allow a null value to be returned. One drawback is, that all the null checks are no longer effective. IMHO solution 2) is the best. At the same time I would deprecate the old Adaptable, because I cannot come up with a real use-case where
Re: adaptTo and results ....
Well, for one thing, display it in the Developer Mode console (or whatever other debugging UIs my app happens to have). Jeff. On 01/07/2014 11:14, Carsten Ziegeler cziege...@apache.org wrote: So if your adapter is buggy and you get an exception, what do you do with it? Carsten 2014-07-01 12:08 GMT+02:00 Jeff Young j...@adobe.com: Hi Carsten, Sure, but Konrad has a point in that I think sometimes the client *does* care why the adaption failed. For instance, if it had to do with something entirely different from whether or not adaption would normally work. Let's say that I have a resource that should adapt to XYZ, but that my adapter is currently buggy. I'd like to get an exception for that, but said exception is going to get eaten. I do agree that if I have a resource that should NOT adapt to XYZ, that getting back null is fine, and that I don't care why the adaption failed. Cheers, Jeff. On 01/07/2014 10:19, Carsten Ziegeler cziege...@apache.org wrote: Sure :) For the adapter pattern, the client does not care why the adaption failed, the client is just interested in the result (success or not) Validation is a different beast, if validation fails you want to know specific reasons why it failed - and this can be multiple. I tried to explain in my first mail on this thread, that all other use cases mentioned can be handled with the current implementation - with the exception of validation. But I think validation requires a different concept than the adapter pattern. Carsten 2014-07-01 11:09 GMT+02:00 Jeff Young j...@adobe.com: Hi Carsten, Can you say more? (I'm not sure I understand what you're getting at) Thanks, Jeff. On 01/07/2014 09:56, Carsten Ziegeler cziege...@apache.org wrote: adaption and validation are different concerns Carsten 2014-07-01 10:55 GMT+02:00 Jeff Young j...@adobe.com: We could solve that by defining a specific exception for adaptation-not-possible and then catch only that. Of course that would leak tons of exceptions from code written before that exception became available. Maybe do the catching based on some sort of version clue? Cheers, Jeff. On 01/07/2014 09:40, Konrad Windszus konra...@gmx.de wrote: It is not (only) about throwing exceptions in case no suitable adapter is available. It rather is about the fact, that today the adaptTo is a barrier for all kinds of exceptions. In some cases the adaptation fails for a specific reason (one example is Sling Models where injection fails, another one is the issue mentioned in https://issues.apache.org/jira/browse/SLING-2712 (ValueMap not supporting primitives)). Both would be valid use cases where the client would be interested to catch the exception here. On 01 Jul 2014, at 10:34, Carsten Ziegeler cziege...@apache.org wrote: Adding a new interface would require us to implement it all over the place and as Felix points out, client code would always need to check whether the new interface is implemented or not Having to methods, like hasAdapter and adaptOrThrow does not work very well as between the two calls things might have changed already: while hasAdapter returns true, the underlying factory gets unregistered before adaptOrThrow is called. In many use cases, the current pattern works fine - the client does not care whether an exception is thrown within the adaption - it just cares whether an object is returned or not. And there are valid use cases, where client code does different things whether the adaption works or not (e.g. the post servlet checks for adaptTo(Node) and then does additional things if the resource is backed up by a node.) I see the point that there are also use cases where it would be fine to simpy throw an exception if adaptTo is not successful. This would make the client code easier. However as this most properly is a runtime exception, client code can today just call a method on the object and end up with a NPE - having the same result :) This leaves us with use cases where the client code explicitely wants to catch the exception and then do something depending on the exception. Maybe we should just add something for this explicit use case instead of bloating the general adaptTo mechanism? Regards Carsten 2014-07-01 9:44 GMT+02:00 Konrad Windszus konra...@gmx.de: Regarding 1) Having such a Result class would mean that all consumer would need to unwrap the exception first. So instead of being forced of implementing a null-check (as with the old solution) one would need to implement another check. I want to prevent such a burden to the consumers. Regarding 2) Since the client code knows on which object
Re: [RT] Support for deep reads from a value map
FWIW, there are lots of calls to resource.adaptTo(ValueMap) in rendering code. Cheers, Jeff. On 14/03/2014 10:19, Bertrand Delacretaz bdelacre...@apache.org wrote: On Fri, Mar 14, 2014 at 11:03 AM, Carsten Ziegeler cziege...@apache.org wrote: ...Just for rendering code, it is quiet handy to have deep reads - and rendering code is using ResourceUtil.getValueMap()... Why would rendering code use this over Resource.adaptTo? Sling makes the current resource available to scripts, so AFAIK there's no incentive to use ResourceUtil more than adaptTo - but maybe I'm missing something. I'm not opposed to changing just ResourceUtil.getValueMap() to provide deep value maps, just trying to understand the reasoning behind it. -Bertrand
Re: Setting the sling.core.current.servletName request attribute
Hi Alex, Me thinks you didn't look hard enough. ;) Adobe CQ's WCMDebugFilter has the following (commented-out) code: /* Currently disabled because misleading information, because the script name is set after the filter chain. SlingBindings bindings = (SlingBindings) req.getAttribute(SlingBindings.class.getName()); SlingScriptHelper scriptHelper = bindings == null ? null :bindings.getSling(); SlingScript script = scriptHelper == null ? null : scriptHelper.getScript(); Resource scriptRes = script == null ? null : script.getScriptResource(); String scriptPath = scriptRes == null ? n/a : scriptRes.getPath(); */ While this doesn't use the request attribute, it is suffering from the same underlying issue. FWIW, the idea came up during the investigation of a similar (but more highly-integrated) debug/developer-mode facility. Cheers, Jeff. On 08/01/2014 00:06, Alexander Klimetschek aklim...@adobe.com wrote: On 07.01.2014, at 11:19, Felix Meschberger fmesc...@adobe.com wrote: The Sling Engine sets the sling.core.current.servletName request attribute to the name of the Servlet (absolut path in case of Scripts) before calling the servlet or script. In essence this means tha the name of the servlet/script to be called is not available to the filters executed before calling the script. What about if me move setting the property to immediately before calling any filters (and resetting it after returning from all filter and script processing) ? Would that break existing functionality ? I don't know any code using that attribute but thinking about it: It could only be an issue, if a filter relies on the fact that the servlet name is NOT set (which would then always be the case atm, so it's not really something where any meaningful logic could be behind). Or if the filter relies that it is from the previously executed servlet (i.e. one that did an include or forward). Not sure if that is feasible... Finally, in our product code (Adobe CQ) I did not find a usage. So I would tend to say it's not a problem. It seems useful to make this available to servlet filters that can do some aspect oriented handling here, to e.g. process rendering resolution insights. OTOH, we already have the request progress tracker, might also make sense to make individual entries more programmatically accessible. Cheers, Alex
Re: Setting the sling.core.current.servletName request attribute
Hi Bertrand, I wouldn't be opposed to using a better-structured RequestProgressTracker log. (I did originally look at the existing one, but wasn't too excited about parsing it to get the info out.) But I don't think it saves adding a new mechanism. The new mechanism's primary job is to weave the debug info into the rendered html so that it can be displayed client-side in the context of the portions of the page it rendered. That's the highly-integrated part. Cheers, Jeff. On 08/01/2014 10:47, Bertrand Delacretaz bdelacre...@apache.org wrote: On Wed, Jan 8, 2014 at 11:42 AM, Jeff Young j...@adobe.com wrote: ...FWIW, the idea came up during the investigation of a similar (but more highly-integrated) debug/developer-mode facility IMO that kind of info should come from the RequestProgressTracker instead of adding new mechanisms. This is a basic log-like structure for now, but improving it with more structure shouldn't be too hard, and making sure it has all the info that a developer would want has other benefits in terms of troubleshooting. -Bertrand
Re: Should ValueMapDecorator implement javax.jcr.Value semantics?
Ping. From: Jeff Young j...@adobe.commailto:j...@adobe.com Date: Wednesday 13 November 2013 11:48 To: dev@sling.apache.orgmailto:dev@sling.apache.org dev@sling.apache.orgmailto:dev@sling.apache.org Cc: Jeff Young j...@adobe.commailto:j...@adobe.com Subject: Should ValueMapDecorator implement javax.jcr.Value semantics? I assume yes, but it doesn't for dates. In particular, org.apache.jackrabbit.value.DateValue converts to ISO8601 when asked for a string, while ValueMapDecorator gives you the string format of the Calendar object. Is this a bug, or should I interpret the Value in ValueMapDecorator more generically than a javax.jcr.Value? Cheers, Jeff. PS: please cc: me on replies; I can't remember if I'm subscribed to the list or not
Should ValueMapDecorator implement javax.jcr.Value semantics?
I assume yes, but it doesn't for dates. In particular, org.apache.jackrabbit.value.DateValue converts to ISO8601 when asked for a string, while ValueMapDecorator gives you the string format of the Calendar object. Is this a bug, or should I interpret the Value in ValueMapDecorator more generically than a javax.jcr.Value? Cheers, Jeff. PS: please cc: me on replies; I can't remember if I'm subscribed to the list or not
[jira] [Commented] (SLING-3028) Support for progress tracking of jobs
[ https://issues.apache.org/jira/browse/SLING-3028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13754518#comment-13754518 ] Jeff Young commented on SLING-3028: --- +1 on keeping failed jobs forever. As for keeping non-failed jobs, you might want an audit trail of some sort. Then again, those jobs could choose to write whatever was needed to the log, so perhaps that's not enough of a reason to allow keeping of other jobs. But then how does the client get info for putting up the finished progress (Copied 934 of 934 files, or whatever)? Support for progress tracking of jobs - Key: SLING-3028 URL: https://issues.apache.org/jira/browse/SLING-3028 Project: Sling Issue Type: Improvement Components: Extensions Reporter: Victor Saar Labels: jobs For long-running jobs, it would be useful to have some means to track progress, which can be shown in a console for the user. This should include the following: * ETA * Completeness value computed from (optional, defaults to 1.0) max and current value (e.g. 42% or 23/100) * Log output stream for detailed progress information * Failure reason in case job failed AFAICS this requires a few changes to the existing implementation: * Jobs need additional support for setting properties, e.g. max and current progress value * Jobs need to be kept at least for a while after they completed/failed to give access to failure information/log stream -- 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-3028) Support for progress tracking of jobs
[ https://issues.apache.org/jira/browse/SLING-3028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13753516#comment-13753516 ] Jeff Young commented on SLING-3028: --- I think jobs that wrote to the log stream might be too auto-magical. I'd be inclined to add a property to a job, but keep failed jobs even if the property isn't set. Support for progress tracking of jobs - Key: SLING-3028 URL: https://issues.apache.org/jira/browse/SLING-3028 Project: Sling Issue Type: Improvement Components: Extensions Reporter: Victor Saar Labels: jobs For long-running jobs, it would be useful to have some means to track progress, which can be shown in a console for the user. This should include the following: * ETA * Completeness value computed from (optional, defaults to 1.0) max and current value (e.g. 42% or 23/100) * Log output stream for detailed progress information * Failure reason in case job failed AFAICS this requires a few changes to the existing implementation: * Jobs need additional support for setting properties, e.g. max and current progress value * Jobs need to be kept at least for a while after they completed/failed to give access to failure information/log stream -- 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: Sling Posthandling - thougts about the current behavior
+1 That would be very nice. Jeff. -Original Message- From: Bertrand Delacretaz [mailto:bdelacre...@apache.org] Sent: 27 June 2013 08:26 To: dev@sling.apache.org Subject: Re: Sling Posthandling - thougts about the current behavior On Thu, Jun 27, 2013 at 12:52 AM, Ian Boston i...@tfd.co.uk wrote: ...I have long thought SlingPostOperations should be registered against the resource type in the same way SlingServlets are registered against a resource type Absolutely - there are other things (validation etc.) where we would benefit from using a similar same resource - X resolution that we have for resource - servlet, so we should generalize the mechanism. If we can also consider the post servlet as a pipeline of operations (validate, pre-process, store etc.) we'd have a flexible mechanism where you can avoid registering too many global things. -Bertrand
RE: Disabling flaky tests
I used to agree as well, but my opinion is now more nuanced. I've experienced projects where a test keeps failing day after day, and after a while developers stop looking at the test results with the same level of discipline. Perhaps Sling is small enough (and the developers are pro-active enough) that this isn't an issue. But it certainly is on some other, larger, more disperse projects (such as CQ). In those, moving a failing test to an issue (which can be assigned to an individual) can produce better results than everyone simply getting used to the build being red. Cheers, Jeff. -Original Message- From: Carsten Ziegeler [mailto:cziege...@apache.org] Sent: 03 June 2013 07:01 To: dev@sling.apache.org Subject: Re: Disabling flaky tests I agree as well, especially for the error handling as this is partially not a problem of the test but really a bug in Sling - we have an issue for that, it just needs to be done :) Carsten 2013/6/3 Felix Meschberger fmesc...@adobe.com I agree here: Disabling the test and having an issue keeps the build green but bears the danger of forgetting about it ... Regards Felix Am 02.06.2013 um 16:04 schrieb Eric Norman: Personally, I'm not a big fan of hiding flaky/failing tests since it tends to remove some of the motivation to stabilize/fix them in a timely manner. That's my 2 cents. Regards, Eric On Fri, May 31, 2013 at 12:14 PM, Robert Munteanu romb...@apache.org wrote: Hi, It seems that the ErrorHandlingTest fails sporadically when run inside a full maven build. I've tried locating the root cause for a couple of hours but failed. For this test, and for future flaky/failing tests, I suggest that we 1. Create an issue for the failing test 2. Disable the test and mark it with the issue key 3. Re-enable the test when it is stable/passing ( which may be considerably later than step 2) 4. Close the issue after the test is re-enabled This has the advantage of keeping the build green and making it easier to find regressions since a failing or unstable build will actually mean something. What do you think? Robert -- Carsten Ziegeler cziege...@apache.org
RE: Support allowed hosts patterns in ReferrerFilter
+1 -Original Message- From: maret.timot...@gmail.com [mailto:maret.timot...@gmail.com] On Behalf Of Timothée Maret Sent: 13 May 2013 11:09 To: dev@sling.apache.org Subject: Support allowed hosts patterns in ReferrerFilter Hi, The current allow.hosts setting of the ReferrerFilter can be configured with a list of trusted hosts. In a setup where the list of allowed hosts is expending as the application runs, it becomes tricky to keep the configuration in sync. As an example, a service which supports wilcard uris such as userId. my.service.com would be required to modify the reference filter configuration for each user which is hardly doable. Thus, I would propose to support regex patterns for the list of allow.hosts. which would still be secure. The example above would be configured as: allow.hosts=*.my.service.com wdyt ? Regards, Timothee.
RE: [VOTE] Release API 2.4.2
+1 (I was about to ask for a test for SLING-2844, but I see you already added one.) Cheers, Jeff. -Original Message- From: Carsten Ziegeler [mailto:cziege...@apache.org] Sent: 30 April 2013 09:16 To: dev@sling.apache.org Subject: [VOTE] Release API 2.4.2 Hi, I just fixed two errors in ResourceUtil (SLING-2844 and SLING-2845) which imho warrant a new release. So here we go Please vote for the release of API 2.4.2 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-155 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 155 /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 Ziegeler cziege...@apache.org
RE: [VOTE] Drop Java 5 Support in General
+1 Jeff. -Original Message- From: Carsten Ziegeler [mailto:cziege...@apache.org] Sent: 31 January 2013 16:48 To: dev@sling.apache.org Subject: [VOTE] Drop Java 5 Support in General 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
RE: Enhancing the RequestPathInfo
+1 Jeff. -Original Message- From: Felix Meschberger [mailto:fmesc...@adobe.com] Sent: 10 January 2013 08:45 To: dev@sling.apache.org Subject: Enhancing the RequestPathInfo Hi all The RequestPathInfo object (retrieved from SlingHttpServletRequest.getRequestPathInfo()) allows access to decomposed request path information. One piece of which is the request suffix which is the part of the URL path after the resource address (incl. selectors and extension). Often times such a suffix is used as a secondary resource address, mostly in administrative console contexts. If would be helpful to be able to get a resource addressed by the suffix directly from the RequestPathInfo project to prevent error-prone template code all-over. For details see also SLING-2670 [1]. I have also attached a complete patch there including the API change, the implementation and the increment in the API export version. The consequence of this API change is, that all implementors of the org.apache.sling.api.request package have to be updated. Looking at the package this is mostly Sling core stuff plus implementors of the SlingRequestListener interface. WDYT ? Regards Felix [1] https://issues.apache.org/jira/browse/SLING-2670
[jira] [Created] (SLING-2572) Redirect validating service
Jeff Young created SLING-2572: - Summary: Redirect validating service Key: SLING-2572 URL: https://issues.apache.org/jira/browse/SLING-2572 Project: Sling Issue Type: Improvement Components: General Reporter: Jeff Young Clients need to validate redirects to esure that they point on-site (or perhaps to an authority on a white-list) to prevent phishing attacks. A Sling service which performed this would allow consistency (and a single point of extension). There already exists AuthUtil.isRedirectValid() [0], but it doesn't handle URLs (only paths), and disallows relative paths (the second of which, at least, is widely used). There is also a referrer validating service [1] which might provide a better starting point. Lastly, if we had backward-compatibility concerns with some of the algorithms encoded in those methods/services, we might choose to provide a very basic default implementation which simply drops any scheme and/or authority from the URL, and let customers do white-lists and/or other more sophisticated checks as customizations. References: [0] https://svn.apache.org/repos/asf/sling/trunk/bundles/auth/core/src/main/java/org/apache/sling/auth/core/AuthUtil.java [1] https://svn.apache.org/repos/asf/sling/trunk/contrib/extensions/security/impl/ReferrerFilter.java -- 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
[POST servlet] Scriptable operations (was: RE: [POST servlet] Wildcard for deleting properties)
This would be a nice feature. There have been several times when I've written a POST servlet which pulls out the :operation, handles one or more custom ones, and then forwards everything else on to the default POST servlet. Jeff. -Original Message- From: Bertrand Delacretaz [mailto:bdelacre...@apache.org] Sent: 17 August 2012 13:05 To: dev@sling.apache.org Subject: Re: [POST servlet] Wildcard for deleting properties On Fri, Aug 17, 2012 at 4:11 AM, Justin Edelson jus...@justinedelson.com wrote: ...WDYT about implementing this as an operation? I don't know what to call it :) but it seems like we should generally stop (or slow) down additions to the modify operation. One alternative is to add special case composite operations like this I don't think we have scriptable POST operations, but that shouldn't be too hard to implement? -Bertrand
RE: [POST servlet] Wildcard for deleting properties
+0 I think this use case (for me) would be just over the line: the correct answer would be to write a custom servlet (as you did). Making the sling POST servlet more complicated doesn't seem worth it. But I don't feel strongly (thus the +0). Jeff. -Original Message- From: Alexander Klimetschek [mailto:aklim...@adobe.com] Sent: 15 August 2012 18:30 To: dev@sling.apache.org Subject: [POST servlet] Wildcard for deleting properties Hi, I had an interesting use case, which could be solved by allowing something like this in the Sling POST servlet: *@Delete = true Which would delete all properties and child nodes of a node, without the client knowing which are there. Similarly, this could also apply to @CopyFrom and @MoveFrom. WDYT? Here is my use case: I want to basically rewrite a node's sub tree (including its properties), while *not* recreating the node. The latter is important because it's an ordered child node. Once I recreate the node in some way (explicitly or using @CopyFrom or @MoveFrom), I am forced to do 2 additional requests - one to get the initial order and remember it, and then a separate one to do the ordering, as the :order operation only works with the request resource, so you can't hook it into a post call which does other things first. And since I really want an atomic operation (one request and one session.save()), this approach is not feasible. With a *@Delete approach I (think I) could do my rewriting (in my case moving the node's sub tree down to a sub node; using two @MoveFrom calls and a temporary node) in one step. Note that I looked at all approaches I could find. This includes a json roundtrip using :content-import, but this also doesn't support rewriting a node's properties without replacing the entire node itself, and it would force another reorder call if I rewrite things. (Note that I really do *not* want to touch the siblings of the node, i.e. doing a larger rewrite). Currently I have a custom servlet doing the necessary steps. Note that I already wrote a special servlet to handle my case, so this might not be too important. Just in case others see the same need. Cheers, Alex
RE: Empty string property values
Hi Carsten, While I don't have any advice on how to proceed, I can tell you that I'd be getting cold feet at about this point too. ;) Jeff. -Original Message- From: Carsten Ziegeler [mailto:cziege...@apache.org] Sent: 13 August 2012 10:48 To: dev@sling.apache.org Subject: Re: Empty string property values While looking into SLING-2534, it seems that (as Alex noted) our docs say something different than the implementation. So I tried to fix the implementation (whic is fairly easy), but then I ran into failing junit tests - I think these tests have wrong assumptions. So after fixing these I run into failing integration tests, e.g. SlingDefaultValuesTest#testDefaultBehaviour posts a new property with an empty value and checks if the property does not exists afterwards. Now, these tests can be fixed as well, but I'm wondering if that's a good thing - it would be correct, but existing applications might rely on the wrong behaviour? On the other hand for rendering a missing value and an empty value usually doesn't make a difference...while it might make a difference for other apps Carsten 2012/7/19 Alexander Klimetschek aklim...@adobe.com: On 16.07.2012, at 17:07, Jeremy Booth wrote: For our app we do need to differentiate between provided empty and not provided. I can imagine that this makes sense sometimes (albeit I haven't come across this yet). On 16 July 2012 15:42, Carsten Ziegeler cziege...@apache.org wrote: the handling of the empty value happens in the Sling Post servlet - afaik this was a decision in the early days of the post servlet to treat an empty value like no value. Yes, that was always in the code (I remember refactoring that once for the @Patch feature). It's clearly commented, albeit the initial reasoning seems lost: // if no value is present or a single empty string is given, // just remove the existing property (if any) removeProperty(parent, prop); However, the sling post servlet docs say something different: http://sling.apache.org/site/manipulating-content-the-slingpostservlet- servletspost.html#ManipulatingContent-TheSlingPostServlet%28servlets.post%29- %7B%7B@IgnoreBlanks%7D%7D The 2nd example in that section: form method=POST action=/content/page/first enctype=multipart/form- data input type=hidden name=stringProperty@TypeHint value=String/ input type=text name=stringProperty value=/ /form This will _not_ result in an empty property, but in no property at all (just tested it). Without knowing the original reasoning for == null, I would say the sling post servlet documentation is king and this is a bug :-) But one needs to be careful here, as there are so many options involved: single- vs. multi-value properties, @IgnoreBlanks, @DefaultValue = :null, @DefaultValue = :ignore ... (see also RequestPropertyTest). Cheers, Alex -- Carsten Ziegeler cziege...@apache.org
[jira] [Commented] (SLING-2320) Current DOS-prevention for infinity.json can prevent enumeration of children
[ https://issues.apache.org/jira/browse/SLING-2320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13289232#comment-13289232 ] Jeff Young commented on SLING-2320: --- The 12/Dec/11 patch still needs to be applied. Without it performance will be impaired (due to 2 exceptions being thrown per node and the result being serialized/de-serialized/re-serialized). Current DOS-prevention for infinity.json can prevent enumeration of children Key: SLING-2320 URL: https://issues.apache.org/jira/browse/SLING-2320 Project: Sling Issue Type: Bug Components: Servlets Affects Versions: Servlets Get 2.1.0 Reporter: Jeff Young Assignee: Felix Meschberger Labels: newbie, patch Fix For: Servlets Get 2.1.4 Attachments: jsonRenderer.diff, json_get_servlet_rewrite.patch, servlet_tests.patch Original Estimate: 1h Remaining Estimate: 1h A request of resource.1.json should always succeed, as it's the primary method for JSON introspection of the repository hierarchy. DOS protection should only apply to deep traversals; that is, anything with a depth greater than 1 (and, in particular, resource.infinity.json). For a fuller discussion, see: http://www.mail-archive.com/dev@sling.apache.org/msg13961.html. -- 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-2467) Define Document-like node type with jcr:content child and default handling servlet
[ https://issues.apache.org/jira/browse/SLING-2467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13272254#comment-13272254 ] Jeff Young commented on SLING-2467: --- How about sling:Container? Define Document-like node type with jcr:content child and default handling servlet -- Key: SLING-2467 URL: https://issues.apache.org/jira/browse/SLING-2467 Project: Sling Issue Type: New Feature Components: JCR Reporter: Felix Meschberger The JCR specification allows for nodes to have a dual nature: As part of a hierarchy containing documents (as a folder in a filesystem) and as a container for actual data (as a file in a filesystem). There are also two node types defined to reflect the filesystem notions: nt:folder for folders and nt:file for Files. The nt:file nodetype requries a child node jcr:content to provide the actual contents of the file. This child node defaults to be of type nt:resource but can actually be anything and as such provide structured data in addition to just plain binary data (in the jcr:data property). Yet, nt:file and nt:folder are just that: nt:file for file data not containing children and nt:file for folders but to not contain structured data. We should define a node type which can be used to really convey this dual nature as a data container (file) and document container (folder) at the same time. So I propose the following node types: [sling:Document] nt:hierarchyNode, sling:Resource - sling:resourcetype (String) = sling/document auto mandatory - * (undefined) - * (undefined) multiple + jcr:content (nt:base) = nt:unstructured mandatory + * (nt:base) = sling:Document version [sling:OrderedDocument] sling:Document orderable + * (nt:base) = sling:OrderedDocument version In addition we create default GET servlet for handling the sling/document resource type: if the resource has a jcr:content child then include jcr:content else sendError 404 -- 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-2457) ResourceUtil.isA() fails if resource has a type, whose super type is not readable
[ https://issues.apache.org/jira/browse/SLING-2457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13254061#comment-13254061 ] Jeff Young commented on SLING-2457: --- Is the fail-over from Resource.isResourceType to isAInternal really buying us anything? Why not just modify the existing isA to use isResourceType? (I presume it has something to do with AbstractResource, since your proposal short-circuits the isResourceType call there, but I'm not able to connect the dots.) ResourceUtil.isA() fails if resource has a type, whose super type is not readable - Key: SLING-2457 URL: https://issues.apache.org/jira/browse/SLING-2457 Project: Sling Issue Type: Bug Components: API Affects Versions: API 2.2.0 Reporter: Tyson Norris * define a resource at /content/component/foo whose type is myapp/components/bar * define bar at /apps/myapp/components/bar * on /apps/myapp/components/bar, set sling:resourceSuperType as /libs/components/bar2 If resolver from resource.getResourceResolver() cannot access /libs/components/bar2, then ResouceUtil.isA(resource, components/bar2) returns false, otherwise it returns true. There could be an argument that it should not return true in any case, however, if you set resourceSuperType on resource as components/bar2, then it returns true with current implementation. At least one of these is wrong, I think. -- 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: [ResourceResolver] sling:alias support
+1 Jeff. -Original Message- From: Felix Meschberger [mailto:fmesc...@adobe.com] Sent: 29 March 2012 19:25 To: dev@sling.apache.org Subject: Re: [ResourceResolver] sling:alias support Hi, This is kind of strong evidence IMHO. Thanks for sharing. Regards Felix Am 29.03.2012 um 11:44 schrieb Antonio Sanso: Hi Jeff, in [0] you can find a kind of evidence for it. Regards Antonio [0] https://issues.apache.org/jira/browse/SLING-2311 On Feb 24, 2012, at 1:48 PM, Jeff Young wrote: Felix, Have we done any profiling to confirm that sling:alias resolution does actually contribute a meaningful percentage? Jeff. -Original Message- From: Felix Meschberger [mailto:fmesc...@adobe.com] Sent: 24 February 2012 10:13 To: dev@sling.apache.org Subject: [ResourceResolver] sling:alias support Hi all, We have had support for sling:alias properties for a long time. This allows to create URL aliases for example for i18n. Yet, it also creates some overhead for resolution of non-existing URLs. Whenever an URL cannot directly be resolved it is split in segments and the resource tree is walked down from the top resolving each segment: If a child resource is not found, all children are inspected for a sling:alias property. Only if none has been found, the iteration terminates and resource resolution fails. This is potentially a costly operation and may not always be required. I wonder, whether we should have a configuration option to be able to switch off sling:alias support (Default would be enabled sling:alias support for backwards compatibility). Regards Felix
[jira] [Commented] (SLING-2441) AuthenticationInfo.put() throws if method is null
[ https://issues.apache.org/jira/browse/SLING-2441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13240489#comment-13240489 ] Jeff Young commented on SLING-2441: --- If we stick with the old behaviour than someone will need to fix AuthenticationInfoPostProcessorBridge. AuthenticationInfo.put() throws if method is null - Key: SLING-2441 URL: https://issues.apache.org/jira/browse/SLING-2441 Project: Sling Issue Type: Bug Components: Authentication Affects Versions: Auth Core 1.0.6 Reporter: Jeff Young Assignee: Justin Edelson Labels: newbie, patch Fix For: Auth Core 1.1.0 Attachments: auth_info_put.patch Historically the AUTH_TYPE of an AuthenitcationInfo had to be defined (ie: non-null), but we're now using it for anonymous access as well, with a null AUTH_TYPE. The put() method, however, throws if passed a null AUTH_TYPE. (This is triggered, for instance, by CQ's AuthenticationInfoPostProcessorBridge, which does a putAll().) -- 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: [jira] [Commented] (SLING-2255) Improve JcrResourceResolver#resolve performance when big number of vanityPath are present
That's quite an improvement. Nice work, guys. -Original Message- From: Antonio Sanso (Commented) (JIRA) [mailto:j...@apache.org] Sent: 26 March 2012 14:36 To: dev@sling.apache.org Subject: [jira] [Commented] (SLING-2255) Improve JcrResourceResolver#resolve performance when big number of vanityPath are present [ https://issues.apache.org/jira/browse/SLING- 2255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment- tabpanelfocusedCommentId=13238379#comment-13238379 ] Antonio Sanso commented on SLING-2255: -- Great work Carsten. I have ran the tests in SLING-2311 and this confirm the magnitude of the improvement. This is the outcome before the patch (in ms) # ResolveWithManyVanityPathTest min 10% 50% 90% max jcr.resource-2.0.11 56 57 60 120 406 and after the patch # ResolveWithManyVanityPathTest min 10% 50% 90% max jcr.resource-2.0.11 12 13 15 19 401 Improve JcrResourceResolver#resolve performance when big number of vanityPath are present - Key: SLING-2255 URL: https://issues.apache.org/jira/browse/SLING-2255 Project: Sling Issue Type: Improvement Components: JCR Affects Versions: JCR Resource 2.0.10 Reporter: Antonio Sanso Assignee: Carsten Ziegeler Priority: Minor Fix For: JCR Resource 2.1.0 Attachments: SLING-2255.txt, performance.pdf At the moment the performance of JcrResourceResolver#resolve is tight with the number of sling:vanityPath present in the repository. Large number of vanityPath means large response time specially in the worse case scenario (namely huge number of vanityPath and request that doesn't match any vanityPath) but also in the average cases. Sling currently employs generic regexps also for vanityPath, but since the regex behind a vanityPath is well know there is room for optimization. I'll attach a graphs that shows the situation and a potential patch. -- 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.jsp a For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (SLING-2446) JCR-1609 added DecimalType, but it didn't get in to Sling's JcrPropertyMap
JCR-1609 added DecimalType, but it didn't get in to Sling's JcrPropertyMap
--
Key: SLING-2446
URL: https://issues.apache.org/jira/browse/SLING-2446
Project: Sling
Issue Type: Bug
Components: JCR
Reporter: Jeff Young
JCR supports the typehint {Decimal} for java.math.BigDecimal, but
JcrPropertyMap doesn't know about it so doing a map.get(propName,
BigDecimal.class) returns null.
--
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
[SLING-2441] AuthenticationInfo.put() throws if method is null
I created an issue for this an uploaded a patch. I can't remember what comes next. (Just this email?) Jeff.
RE: [SLING-2441] AuthenticationInfo.put() throws if method is null
Thanks Justin. (Although I don't remember an API change. Perhaps you're thinking of a different one?) Jeff. -Original Message- From: justinedel...@gmail.com [mailto:justinedel...@gmail.com] On Behalf Of Justin Edelson Sent: 23 March 2012 13:34 To: dev@sling.apache.org Subject: Re: [SLING-2441] AuthenticationInfo.put() throws if method is null Hi Jeff, I was looking at this patch and forgot to update JIRA. It's an API change so I was trying to see if there were other options. I couldn't find any. I should be able to the patch today. Regards, Justin On Fri, Mar 23, 2012 at 9:20 AM, Jeff Young j...@adobe.com wrote: I created an issue for this an uploaded a patch. I can't remember what comes next. (Just this email?) Jeff.
RE: [SLING-2441] AuthenticationInfo.put() throws if method is null
Ah, right. Jeff. -Original Message- From: justinedel...@gmail.com [mailto:justinedel...@gmail.com] On Behalf Of Justin Edelson Sent: 23 March 2012 14:04 To: dev@sling.apache.org Subject: Re: [SLING-2441] AuthenticationInfo.put() throws if method is null AuthenticationInfo is part of the API, i.e. it is exported by the auth.core bundle. Justin On Fri, Mar 23, 2012 at 9:58 AM, Jeff Young j...@adobe.com wrote: Thanks Justin. (Although I don't remember an API change. Perhaps you're thinking of a different one?) Jeff. -Original Message- From: justinedel...@gmail.com [mailto:justinedel...@gmail.com] On Behalf Of Justin Edelson Sent: 23 March 2012 13:34 To: dev@sling.apache.org Subject: Re: [SLING-2441] AuthenticationInfo.put() throws if method is null Hi Jeff, I was looking at this patch and forgot to update JIRA. It's an API change so I was trying to see if there were other options. I couldn't find any. I should be able to the patch today. Regards, Justin On Fri, Mar 23, 2012 at 9:20 AM, Jeff Young j...@adobe.com wrote: I created an issue for this an uploaded a patch. I can't remember what comes next. (Just this email?) Jeff.
[jira] [Commented] (SLING-2446) JCR-1609 added DecimalType, but it didn't get in to Sling's JcrPropertyMap
[
https://issues.apache.org/jira/browse/SLING-2446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13236621#comment-13236621
]
Jeff Young commented on SLING-2446:
---
Hi Justin,
Just to note that I'm working on a patch; should be uploaded in a few hours.
Cheers,
Jeff.
JCR-1609 added DecimalType, but it didn't get in to Sling's JcrPropertyMap
--
Key: SLING-2446
URL: https://issues.apache.org/jira/browse/SLING-2446
Project: Sling
Issue Type: Bug
Components: JCR
Reporter: Jeff Young
Assignee: Justin Edelson
Labels: newbie, patch
Fix For: JCR Resource 2.1.0
JCR supports the typehint {Decimal} for java.math.BigDecimal, but
JcrPropertyMap doesn't know about it so doing a map.get(propName,
BigDecimal.class) returns null.
--
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] [Updated] (SLING-2446) Add support for BigDecimal JCR values
[
https://issues.apache.org/jira/browse/SLING-2446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeff Young updated SLING-2446:
--
Attachment: BigDecimal_tests_.patch
Add support for BigDecimal JCR values
-
Key: SLING-2446
URL: https://issues.apache.org/jira/browse/SLING-2446
Project: Sling
Issue Type: New Feature
Components: JCR
Reporter: Jeff Young
Assignee: Justin Edelson
Labels: newbie, patch
Fix For: JCR Resource 2.1.0
Attachments: BigDecimal_tests_.patch
JCR supports the typehint {Decimal} for java.math.BigDecimal, but
JcrPropertyMap doesn't know about it so doing a map.get(propName,
BigDecimal.class) returns null.
Likewise, you should be able to adapt a Property Resource into a BigDecimal.
--
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-2446) Add support for BigDecimal JCR values
[
https://issues.apache.org/jira/browse/SLING-2446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13236664#comment-13236664
]
Jeff Young commented on SLING-2446:
---
Most of my changes were the same as Justin's, so I just pulled his in. My
tests were slightly more complete, however, so I've uploaded a patch containing
just my extra tests.
Add support for BigDecimal JCR values
-
Key: SLING-2446
URL: https://issues.apache.org/jira/browse/SLING-2446
Project: Sling
Issue Type: New Feature
Components: JCR
Reporter: Jeff Young
Assignee: Justin Edelson
Labels: newbie, patch
Fix For: JCR Resource 2.1.0
Attachments: BigDecimal_tests_.patch
JCR supports the typehint {Decimal} for java.math.BigDecimal, but
JcrPropertyMap doesn't know about it so doing a map.get(propName,
BigDecimal.class) returns null.
Likewise, you should be able to adapt a Property Resource into a BigDecimal.
--
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] [Created] (SLING-2441) AuthenticationInfo.put() throws if method is null
AuthenticationInfo.put() throws if method is null - Key: SLING-2441 URL: https://issues.apache.org/jira/browse/SLING-2441 Project: Sling Issue Type: Bug Components: Authentication Affects Versions: Auth Core 1.0.6 Reporter: Jeff Young Historically the AUTH_TYPE of an AuthenitcationInfo had to be defined (ie: non-null), but we're now using it for anonymous access as well, with a null AUTH_TYPE. The put() method, however, throws if passed a null AUTH_TYPE. (This is triggered, for instance, by CQ's AuthenticationInfoPostProcessorBridge, which does a putAll().) -- 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] [Updated] (SLING-2441) AuthenticationInfo.put() throws if method is null
[ https://issues.apache.org/jira/browse/SLING-2441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Young updated SLING-2441: -- Attachment: auth_info_put.patch AuthenticationInfo.put() throws if method is null - Key: SLING-2441 URL: https://issues.apache.org/jira/browse/SLING-2441 Project: Sling Issue Type: Bug Components: Authentication Affects Versions: Auth Core 1.0.6 Reporter: Jeff Young Labels: newbie, patch Attachments: auth_info_put.patch Historically the AUTH_TYPE of an AuthenitcationInfo had to be defined (ie: non-null), but we're now using it for anonymous access as well, with a null AUTH_TYPE. The put() method, however, throws if passed a null AUTH_TYPE. (This is triggered, for instance, by CQ's AuthenticationInfoPostProcessorBridge, which does a putAll().) -- 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: [ResourceResolver] sling:alias support
Antonio, Not quite direct evidence, but probably close enough to act on. +1 BTW: is it the checking for an alias that slows things down, or the resolution of the alias path? If the later, it'd be nice to spit out a warning to the log if we ever find a sling:alias but the configuration is set to ignore it. Jeff. -Original Message- From: Antonio Sanso [mailto:asa...@adobe.com] Sent: 24 February 2012 13:28 To: dev@sling.apache.org Subject: Re: [ResourceResolver] sling:alias support Hi Jeff On Feb 24, 2012, at 1:48 PM, Jeff Young wrote: Felix, Have we done any profiling to confirm that sling:alias resolution does actually contribute a meaningful percentage? we have a Jira ticket somehow related [0]. Not profiling though. There is some kind of profiling for vanityPath [1] as part of [2]. Regards Antonio [0] https://issues.apache.org/jira/browse/SLING-2239 [1] https://issues.apache.org/jira/secure/attachment/12500677/performance.pdf [2] https://issues.apache.org/jira/browse/SLING-2255 Jeff. -Original Message- From: Felix Meschberger [mailto:fmesc...@adobe.com] Sent: 24 February 2012 10:13 To: dev@sling.apache.org Subject: [ResourceResolver] sling:alias support Hi all, We have had support for sling:alias properties for a long time. This allows to create URL aliases for example for i18n. Yet, it also creates some overhead for resolution of non-existing URLs. Whenever an URL cannot directly be resolved it is split in segments and the resource tree is walked down from the top resolving each segment: If a child resource is not found, all children are inspected for a sling:alias property. Only if none has been found, the iteration terminates and resource resolution fails. This is potentially a costly operation and may not always be required. I wonder, whether we should have a configuration option to be able to switch off sling:alias support (Default would be enabled sling:alias support for backwards compatibility). Regards Felix
RE: The beast that is JcrResourceResolverFactoryImpl
What is a whiteboard? (Is it equivalent to a sandbox?) Thanks, Jeff. -Original Message- From: Felix Meschberger [mailto:fmesc...@adobe.com] Sent: 02 February 2012 13:42 To: dev@sling.apache.org Subject: Re: The beast that is JcrResourceResolverFactoryImpl Hi, Am 02.02.2012 um 14:26 schrieb Vidar Ramdal: 2012/2/2 Vidar Ramdal vidar.ram...@webstep.no: I think some time ago Felix was working on a prototype for this. Not sure what the status is. But that's definitely something we should do in Sling rather sooner than later. I'd be interested in seeing this come to Sling, and could start do to some work on it - at least slowly, piece by piece. Am 02.02.2012 um 09:02 schrieb Carsten Ziegeler: Great! If we could find any references to Felix' prototype, I could start from there. Yes :) Or we can start from scratch - I think as a first step we could copy the jcr resource bundle to the whiteboard and start from there. 2012/2/2 Felix Meschberger fmesc...@adobe.com: Unfortunately I don't have anything code-wise. I once started to separate the ResourceResolverFactory and ResourceResolver part from the JCR part but I didn't come very far (and I fear I lost my work)... The basic idea, really is to split the JCR Resource bundle in a ResourceResolverFactory bundle and a JCR Resource Provider bundle (also providing the JCR Event to OSGi Event bridge) The Domain Mapping functionality would be part of the ResourceResolverFactory bundle but would probably have a new exposed service API to plug into it. Such that for example Vanity URL functionality could in fact be factored out into another bundle. Sounds good. Maybe we also get to solve SLING-2076 [1] as a side-effect :) That's exactly what I had in mind, yes. And yes, this would definitely be something I would be interested in. Could this work be started in a whiteboard location ? I created https://svn.apache.org/repos/asf/sling/whiteboard/resourceresolverfactory for this - will start by copying in the current jcr/resource bundle. Great ! Unfortunately I don't get to do any Sling work in my current job, so don't expect any rapid progress on my part. Anyone interested, please join :) Created https://issues.apache.org/jira/browse/SLING-2396 to track this. Thanks and Regards Felix -- Vidar S. Ramdal vidar.ram...@webstep.no Webstep AS - http://www.webstep.no Besøksadresse: Lilleakerveien 8, 0283 Oslo Postadresse: Postboks 272 Lilleaker, 0216 Oslo
[jira] [Commented] (SLING-2320) Current DOS-prevention for infinity.json can prevent enumeration of children
[ https://issues.apache.org/jira/browse/SLING-2320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13197723#comment-13197723 ] Jeff Young commented on SLING-2320: --- My last patch (which contains all the good bug fixes; see a - d above) still needs committing. Current DOS-prevention for infinity.json can prevent enumeration of children Key: SLING-2320 URL: https://issues.apache.org/jira/browse/SLING-2320 Project: Sling Issue Type: Bug Components: Servlets Affects Versions: Servlets Get 2.1.0 Reporter: Jeff Young Assignee: Felix Meschberger Labels: newbie, patch Fix For: Servlets Get 2.1.4 Attachments: jsonRenderer.diff, json_get_servlet_rewrite.patch, servlet_tests.patch Original Estimate: 1h Remaining Estimate: 1h A request of resource.1.json should always succeed, as it's the primary method for JSON introspection of the repository hierarchy. DOS protection should only apply to deep traversals; that is, anything with a depth greater than 1 (and, in particular, resource.infinity.json). For a fuller discussion, see: http://www.mail-archive.com/dev@sling.apache.org/msg13961.html. -- 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-2236) Default POST servlet reports invalid operation when it should report 404
[ https://issues.apache.org/jira/browse/SLING-2236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13190968#comment-13190968 ] Jeff Young commented on SLING-2236: --- Imagine our poor developer trying to debug this. A workaround isn't very useful if there's no indication that they ought to use the workaround. It's not the operation lookup that's the issue: it's that (conceptually) the WRONG servlet is processing the operation (because we couldn't read the sling:resourceType to get the RIGHT servlet). We at least give our developer a hint with a 404; they're going to be pretty baffled when we report an invalid operation. Default POST servlet reports invalid operation when it should report 404 Key: SLING-2236 URL: https://issues.apache.org/jira/browse/SLING-2236 Project: Sling Issue Type: Bug Components: Servlets Reporter: Jeff Young Priority: Minor In sling/servlets/post/impl/SlingPostServlet.java's doPost() method, we look up the operation (and report an unknown operation) before checking privileges. I'd like to propose that when the operation is not understood, we first check for read access to the resource, and if unsuccessful, report that instead of reporting invalid operation. Here's the issue: say I define my own POST servlet which supports :operation=foo. I set a sling:resourceType so that my POST servlet gets invoked. All fine and good. Now someone without read access to the resource tries to do an :operation=foo. Sling can't read the sling:resourceType (no read access), and so invokes the default POST servlet instead of my custom POST servlet. It looks up :operation=foo and reports invalid operation (which is pretty misleading). -- 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-2236) Default POST servlet reports invalid operation when it should report 404
[ https://issues.apache.org/jira/browse/SLING-2236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=1319#comment-1319 ] Jeff Young commented on SLING-2236: --- OK, one more attempt (and then I promise to shut up): Let's say the :operation -is- one the default servlet knows. In that case, it's going to report a 404. So, conceptually, in the bad operation case the default servlet sees two problems: we can't read the resource and we don't know what the operation is. There's nothing in the Sling contract which states that operation errors have precedence over read-access errors. (And, while this particular instance doesn't appear to have any exploitability, it would seem that in general you'd want to give read-access errors precedence in order to reduce the possibility of leaking resource exists information.) Default POST servlet reports invalid operation when it should report 404 Key: SLING-2236 URL: https://issues.apache.org/jira/browse/SLING-2236 Project: Sling Issue Type: Bug Components: Servlets Reporter: Jeff Young Priority: Minor In sling/servlets/post/impl/SlingPostServlet.java's doPost() method, we look up the operation (and report an unknown operation) before checking privileges. I'd like to propose that when the operation is not understood, we first check for read access to the resource, and if unsuccessful, report that instead of reporting invalid operation. Here's the issue: say I define my own POST servlet which supports :operation=foo. I set a sling:resourceType so that my POST servlet gets invoked. All fine and good. Now someone without read access to the resource tries to do an :operation=foo. Sling can't read the sling:resourceType (no read access), and so invokes the default POST servlet instead of my custom POST servlet. It looks up :operation=foo and reports invalid operation (which is pretty misleading). -- 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-2236) Default POST servlet reports invalid operation when it should report 404
[ https://issues.apache.org/jira/browse/SLING-2236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13191227#comment-13191227 ] Jeff Young commented on SLING-2236: --- Hi Justin, In my first example, if I use a -known- operation on a non-readable resource, then the servlet -will- return a 404. It's true that different operations may have different -specific- access requirements. But they should only handle those -after- checking for basic read access. To do anything else risks information leakage. So, yes, I like your precondition idea, but there's only one, and it's invariant: do we at least have read-access? If not, return a 404. Don't give the caller -any- other information. Default POST servlet reports invalid operation when it should report 404 Key: SLING-2236 URL: https://issues.apache.org/jira/browse/SLING-2236 Project: Sling Issue Type: Bug Components: Servlets Reporter: Jeff Young Priority: Minor In sling/servlets/post/impl/SlingPostServlet.java's doPost() method, we look up the operation (and report an unknown operation) before checking privileges. I'd like to propose that when the operation is not understood, we first check for read access to the resource, and if unsuccessful, report that instead of reporting invalid operation. Here's the issue: say I define my own POST servlet which supports :operation=foo. I set a sling:resourceType so that my POST servlet gets invoked. All fine and good. Now someone without read access to the resource tries to do an :operation=foo. Sling can't read the sling:resourceType (no read access), and so invokes the default POST servlet instead of my custom POST servlet. It looks up :operation=foo and reports invalid operation (which is pretty misleading). -- 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-2353) Prevent sling:include resource=%= null % / to include itself
[ https://issues.apache.org/jira/browse/SLING-2353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13186296#comment-13186296 ] Jeff Young commented on SLING-2353: --- sling:include with a null resource (whether specified as null or defaulted to null) doesn't appear to have any value other than backwards compatibility. It's certainly not an elegant way to include self, nor does it appear to be the only way. Being able to include self (with other selectors/extensions) certainly does have value, but as stated, we don't need include null to accomplish that. So, if we need backward compatibility, then I'd favour WONTFIX. Otherwise, I'd favour throwing an IllegalArgumentException. Prevent sling:include resource=%= null % / to include itself -- Key: SLING-2353 URL: https://issues.apache.org/jira/browse/SLING-2353 Project: Sling Issue Type: Bug Components: Scripting Affects Versions: Scripting JSP-Taglib 2.1.2 Reporter: Tobias Bocanegra Assignee: Carsten Ziegeler Priority: Minor Fix For: Scripting JSP-Taglib 2.1.4 If you add this sling:include to a JSP sling:include resource=%= null % / then it will cause the page to keep including itself recursively making the server slow. there is a recursion limitation though to prevent endless loops. -- 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: [VOTE] Release Scripting API 2.1.4, Scripting Core 2.0.20, Scripting JSP 2.0.20, Scripting JSP-Taglib 2.1.4, Scripting Java 2.0.2, I18N 2.2.0, Installer Core 3.3.2
-1 to JSP taglib (see my comment in SLING-2353) 0 to the others (I'm not up-to-speed on them). Cheers, Jeff. -Original Message- From: justinedel...@gmail.com [mailto:justinedel...@gmail.com] On Behalf Of Justin Edelson Sent: 14 January 2012 16:29 To: dev@sling.apache.org Subject: Re: [VOTE] Release Scripting API 2.1.4, Scripting Core 2.0.20, Scripting JSP 2.0.20, Scripting JSP-Taglib 2.1.4, Scripting Java 2.0.2, I18N 2.2.0, Installer Core 3.3.2 +1 to everything except JSP Taglib 2.1.4 -1 to JSP taglib 2.1.4 due to lack of consensus around SLING-2353 Justin On Fri, Jan 13, 2012 at 8:41 AM, Carsten Ziegeler cziege...@apache.org wrote: +1 Carsten 2012/1/13 Carsten Ziegeler cziege...@apache.org: Hi, This vote is about seven bundles: Apache Sling Scripting JSP-Taglib 2.1.4 https://issues.apache.org/jira/browse/SLING/fixforversion/12316405 Apache Sling Installer Core 3.3.2 https://issues.apache.org/jira/browse/SLING/fixforversion/12319442 Apache Sling Scripting API 2.1.4 https://issues.apache.org/jira/browse/SLING/fixforversion/12316004 Apache Sling Scripting Core 2.0.20 https://issues.apache.org/jira/browse/SLING/fixforversion/12317582 Apache Sling i18n 2.2.0 https://issues.apache.org/jira/browse/SLING/fixforversion/12317346 Apache Sling Scripting JSP 2.0.20 https://issues.apache.org/jira/browse/SLING/fixforversion/12317602 Apache Sling Scripting Java 2.0.2 https://issues.apache.org/jira/browse/SLING/fixforversion/12316001 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-063/ 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 063 /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: Jenkins build is unstable: sling-trunk-1.5 » Apache Sling Launchpad Testing #1478
I was trying to look into the 4th test failure (the JsonRenderingTest), but I can't get to svn.apache.org. Is it down, or is it just my machine? Thanks, Jeff. -Original Message- From: Apache Jenkins Server [mailto:jenk...@builds.apache.org] Sent: 12 December 2011 10:22 To: dev@sling.apache.org Subject: Jenkins build is unstable: sling-trunk-1.5 » Apache Sling Launchpad Testing #1478 See https://builds.apache.org/job/sling-trunk-1.5/org.apache.sling$org.apache.sling.launchpad.testing/1478/
RE: Jenkins test failure
Well, the server is still pretty glacial for me (when it responds at all), but I've gotten enough out of it that I believe the test failure is a result of the bug identified in SLING-2320 (comment 06/Dec/11 23:33), and fixed by the patch servlet_tests.patch (see comment 07/Dec/11 11:48). https://issues.apache.org/jira/browse/SLING-2320 Could I get a committer to apply that patch? (Carsten has looked over it.) I've also got a further patch developed to fix some of the other issues discovered: a) throwing two exceptions per node traversed b) serializing/de-serializing/re-serializing the JSON data but it'll be easier for me to post a clean patch if HEAD is updated first (otherwise I'm likely to get a diff including some of my changes twice). (Yes, I'm sure there's a way around that, but I'm a SVN newbie too, and would just as soon not have my brain explode today.) Thanks, Jeff. -Original Message- From: Jeff Young [mailto:j...@adobe.com] Sent: 12 December 2011 10:50 To: dev@sling.apache.org Subject: RE: Jenkins build is unstable: sling-trunk-1.5 » Apache Sling Launchpad Testing #1478 I was trying to look into the 4th test failure (the JsonRenderingTest), but I can't get to svn.apache.org. Is it down, or is it just my machine? Thanks, Jeff. -Original Message- From: Apache Jenkins Server [mailto:jenk...@builds.apache.org] Sent: 12 December 2011 10:22 To: dev@sling.apache.org Subject: Jenkins build is unstable: sling-trunk-1.5 » Apache Sling Launchpad Testing #1478 See https://builds.apache.org/job/sling-trunk-1.5/org.apache.sling$org.apache.sling.launchpad.testing/1478/
RE: Jenkins test failure
Thanks, Justin. Was svn.apache.org really slow for you, or is it just my connection? Jeff. -Original Message- From: justinedel...@gmail.com [mailto:justinedel...@gmail.com] On Behalf Of Justin Edelson Sent: 12 December 2011 16:48 To: dev@sling.apache.org Subject: Re: Jenkins test failure Patch applied. On Mon, Dec 12, 2011 at 3:58 AM, Jeff Young j...@adobe.com wrote: Well, the server is still pretty glacial for me (when it responds at all), but I've gotten enough out of it that I believe the test failure is a result of the bug identified in SLING-2320 (comment 06/Dec/11 23:33), and fixed by the patch servlet_tests.patch (see comment 07/Dec/11 11:48). https://issues.apache.org/jira/browse/SLING-2320 Could I get a committer to apply that patch? (Carsten has looked over it.) I've also got a further patch developed to fix some of the other issues discovered: a) throwing two exceptions per node traversed b) serializing/de-serializing/re-serializing the JSON data but it'll be easier for me to post a clean patch if HEAD is updated first (otherwise I'm likely to get a diff including some of my changes twice). (Yes, I'm sure there's a way around that, but I'm a SVN newbie too, and would just as soon not have my brain explode today.) Thanks, Jeff. -Original Message- From: Jeff Young [mailto:j...@adobe.com] Sent: 12 December 2011 10:50 To: dev@sling.apache.org Subject: RE: Jenkins build is unstable: sling-trunk-1.5 » Apache Sling Launchpad Testing #1478 I was trying to look into the 4th test failure (the JsonRenderingTest), but I can't get to svn.apache.org. Is it down, or is it just my machine? Thanks, Jeff. -Original Message- From: Apache Jenkins Server [mailto:jenk...@builds.apache.org] Sent: 12 December 2011 10:22 To: dev@sling.apache.org Subject: Jenkins build is unstable: sling-trunk-1.5 » Apache Sling Launchpad Testing #1478 See https://builds.apache.org/job/sling-trunk-1.5/org.apache.sling$org.apache.sling.launchpad.testing/1478/
RE: Jenkins test failure
Hi Justin, In revision 1213304, I only see the change to ResourceTraversor.java. I think you might have applied the wrong patch (there was an earlier diff with just that file, and a later patch with that file and 4 or 5 test files and a POM or two). Or is there a further revision coming? Thanks, Jeff. -Original Message- From: Jeff Young [mailto:j...@adobe.com] Sent: 12 December 2011 16:51 To: dev@sling.apache.org Subject: RE: Jenkins test failure Thanks, Justin. Was svn.apache.org really slow for you, or is it just my connection? Jeff. -Original Message- From: justinedel...@gmail.com [mailto:justinedel...@gmail.com] On Behalf Of Justin Edelson Sent: 12 December 2011 16:48 To: dev@sling.apache.org Subject: Re: Jenkins test failure Patch applied. On Mon, Dec 12, 2011 at 3:58 AM, Jeff Young j...@adobe.com wrote: Well, the server is still pretty glacial for me (when it responds at all), but I've gotten enough out of it that I believe the test failure is a result of the bug identified in SLING-2320 (comment 06/Dec/11 23:33), and fixed by the patch servlet_tests.patch (see comment 07/Dec/11 11:48). https://issues.apache.org/jira/browse/SLING-2320 Could I get a committer to apply that patch? (Carsten has looked over it.) I've also got a further patch developed to fix some of the other issues discovered: a) throwing two exceptions per node traversed b) serializing/de-serializing/re-serializing the JSON data but it'll be easier for me to post a clean patch if HEAD is updated first (otherwise I'm likely to get a diff including some of my changes twice). (Yes, I'm sure there's a way around that, but I'm a SVN newbie too, and would just as soon not have my brain explode today.) Thanks, Jeff. -Original Message- From: Jeff Young [mailto:j...@adobe.com] Sent: 12 December 2011 10:50 To: dev@sling.apache.org Subject: RE: Jenkins build is unstable: sling-trunk-1.5 » Apache Sling Launchpad Testing #1478 I was trying to look into the 4th test failure (the JsonRenderingTest), but I can't get to svn.apache.org. Is it down, or is it just my machine? Thanks, Jeff. -Original Message- From: Apache Jenkins Server [mailto:jenk...@builds.apache.org] Sent: 12 December 2011 10:22 To: dev@sling.apache.org Subject: Jenkins build is unstable: sling-trunk-1.5 » Apache Sling Launchpad Testing #1478 See https://builds.apache.org/job/sling-trunk-1.5/org.apache.sling$org.apache.sling.launchpad.testing/1478/
RE: Jenkins test failure
Yep, got it now. (I think I'm going to have to reboot. Something's decidedly fishy about my connection) Thanks, Jeff. -Original Message- From: justinedel...@gmail.com [mailto:justinedel...@gmail.com] On Behalf Of Justin Edelson Sent: 12 December 2011 16:57 To: dev@sling.apache.org Subject: Re: Jenkins test failure Yep. I did the tests in the next revision. Justin On Mon, Dec 12, 2011 at 8:55 AM, Jeff Young j...@adobe.com wrote: Hi Justin, In revision 1213304, I only see the change to ResourceTraversor.java. I think you might have applied the wrong patch (there was an earlier diff with just that file, and a later patch with that file and 4 or 5 test files and a POM or two). Or is there a further revision coming? Thanks, Jeff. -Original Message- From: Jeff Young [mailto:j...@adobe.com] Sent: 12 December 2011 16:51 To: dev@sling.apache.org Subject: RE: Jenkins test failure Thanks, Justin. Was svn.apache.org really slow for you, or is it just my connection? Jeff. -Original Message- From: justinedel...@gmail.com [mailto:justinedel...@gmail.com] On Behalf Of Justin Edelson Sent: 12 December 2011 16:48 To: dev@sling.apache.org Subject: Re: Jenkins test failure Patch applied. On Mon, Dec 12, 2011 at 3:58 AM, Jeff Young j...@adobe.com wrote: Well, the server is still pretty glacial for me (when it responds at all), but I've gotten enough out of it that I believe the test failure is a result of the bug identified in SLING-2320 (comment 06/Dec/11 23:33), and fixed by the patch servlet_tests.patch (see comment 07/Dec/11 11:48). https://issues.apache.org/jira/browse/SLING-2320 Could I get a committer to apply that patch? (Carsten has looked over it.) I've also got a further patch developed to fix some of the other issues discovered: a) throwing two exceptions per node traversed b) serializing/de-serializing/re-serializing the JSON data but it'll be easier for me to post a clean patch if HEAD is updated first (otherwise I'm likely to get a diff including some of my changes twice). (Yes, I'm sure there's a way around that, but I'm a SVN newbie too, and would just as soon not have my brain explode today.) Thanks, Jeff. -Original Message- From: Jeff Young [mailto:j...@adobe.com] Sent: 12 December 2011 10:50 To: dev@sling.apache.org Subject: RE: Jenkins build is unstable: sling-trunk-1.5 » Apache Sling Launchpad Testing #1478 I was trying to look into the 4th test failure (the JsonRenderingTest), but I can't get to svn.apache.org. Is it down, or is it just my machine? Thanks, Jeff. -Original Message- From: Apache Jenkins Server [mailto:jenk...@builds.apache.org] Sent: 12 December 2011 10:22 To: dev@sling.apache.org Subject: Jenkins build is unstable: sling-trunk-1.5 » Apache Sling Launchpad Testing #1478 See https://builds.apache.org/job/sling-trunk-1.5/org.apache.sling$org.apache.sling.launchpad.testing/1478/
[jira] [Updated] (SLING-2320) Current DOS-prevention for infinity.json can prevent enumeration of children
[ https://issues.apache.org/jira/browse/SLING-2320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Young updated SLING-2320: -- Attachment: json_get_servlet_rewrite.patch No worries, Justin. I've got one more anyway ;) Hopefully this is the final installment. Rewrite of JSON GET servlet to: a) not throw two exceptions per node finding the parent (in fact, we don't look for the parent at all anymore as the JSON rendering is now done via a second-pass, depth-first traversal rather than during the breadth-first depthCheck) b) not serialize/de-serialize/re-serialize the JSON (also due to the above two-pass approach) c) use ArrayLists instead of LinkedLists for breadth-first traversal (to reduce memory allocation calls) d) not use exceptions for limiting depth Current DOS-prevention for infinity.json can prevent enumeration of children Key: SLING-2320 URL: https://issues.apache.org/jira/browse/SLING-2320 Project: Sling Issue Type: Bug Components: Servlets Affects Versions: Servlets Get 2.1.0 Reporter: Jeff Young Assignee: Justin Edelson Labels: newbie, patch Fix For: Servlets Get 2.1.4 Attachments: jsonRenderer.diff, json_get_servlet_rewrite.patch, servlet_tests.patch Original Estimate: 1h Remaining Estimate: 1h A request of resource.1.json should always succeed, as it's the primary method for JSON introspection of the repository hierarchy. DOS protection should only apply to deep traversals; that is, anything with a depth greater than 1 (and, in particular, resource.infinity.json). For a fuller discussion, see: http://www.mail-archive.com/dev@sling.apache.org/msg13961.html. -- 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-2320) Current DOS-prevention for infinity.json can prevent enumeration of children
[ https://issues.apache.org/jira/browse/SLING-2320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13167650#comment-13167650 ] Jeff Young commented on SLING-2320: --- BTW: final installment is json_get_servlet_rewrite.patch. Current DOS-prevention for infinity.json can prevent enumeration of children Key: SLING-2320 URL: https://issues.apache.org/jira/browse/SLING-2320 Project: Sling Issue Type: Bug Components: Servlets Affects Versions: Servlets Get 2.1.0 Reporter: Jeff Young Assignee: Justin Edelson Labels: newbie, patch Fix For: Servlets Get 2.1.4 Attachments: jsonRenderer.diff, json_get_servlet_rewrite.patch, servlet_tests.patch Original Estimate: 1h Remaining Estimate: 1h A request of resource.1.json should always succeed, as it's the primary method for JSON introspection of the repository hierarchy. DOS protection should only apply to deep traversals; that is, anything with a depth greater than 1 (and, in particular, resource.infinity.json). For a fuller discussion, see: http://www.mail-archive.com/dev@sling.apache.org/msg13961.html. -- 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: Jenkins build is still unstable: sling-trunk-1.5 » Apache Sling Launchpad Testing WAR version #1479
Felix recently committed a change by Alex relating to the: org.apache.sling.servlets.get.impl.RedirectServletTest no longer returning absolute paths. It would appear that the failing tests are the same issue, but from: org.apache.sling.launchpad.webapp.integrationtest.VanityPathTest. Cheers, Jeff. -Original Message- From: Apache Jenkins Server [mailto:jenk...@builds.apache.org] Sent: 12 December 2011 19:11 To: dev@sling.apache.org Subject: Jenkins build is still unstable: sling-trunk-1.5 » Apache Sling Launchpad Testing WAR version #1479 See https://builds.apache.org/job/sling-trunk-1.5/org.apache.sling$org.apache.sling.launchpad.testing-war/1479/
[jira] [Updated] (SLING-2320) Current DOS-prevention for infinity.json can prevent enumeration of children
[ https://issues.apache.org/jira/browse/SLING-2320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Young updated SLING-2320: -- Attachment: jsonRenderer.diff Current DOS-prevention for infinity.json can prevent enumeration of children Key: SLING-2320 URL: https://issues.apache.org/jira/browse/SLING-2320 Project: Sling Issue Type: Bug Components: Servlets Affects Versions: Servlets Get 2.1.0 Reporter: Jeff Young Assignee: Felix Meschberger Labels: newbie, patch Fix For: Servlets Get 2.1.4 Attachments: jsonRenderer.diff, jsonRenderer.diff, servlet_tests.patch, servlet_tests.patch Original Estimate: 1h Remaining Estimate: 1h A request of resource.1.json should always succeed, as it's the primary method for JSON introspection of the repository hierarchy. DOS protection should only apply to deep traversals; that is, anything with a depth greater than 1 (and, in particular, resource.infinity.json). For a fuller discussion, see: http://www.mail-archive.com/dev@sling.apache.org/msg13961.html. -- 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] [Updated] (SLING-2320) Current DOS-prevention for infinity.json can prevent enumeration of children
[ https://issues.apache.org/jira/browse/SLING-2320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Young updated SLING-2320: -- Attachment: servlet_tests.patch Current DOS-prevention for infinity.json can prevent enumeration of children Key: SLING-2320 URL: https://issues.apache.org/jira/browse/SLING-2320 Project: Sling Issue Type: Bug Components: Servlets Affects Versions: Servlets Get 2.1.0 Reporter: Jeff Young Assignee: Felix Meschberger Labels: newbie, patch Fix For: Servlets Get 2.1.4 Attachments: jsonRenderer.diff, jsonRenderer.diff, servlet_tests.patch, servlet_tests.patch Original Estimate: 1h Remaining Estimate: 1h A request of resource.1.json should always succeed, as it's the primary method for JSON introspection of the repository hierarchy. DOS protection should only apply to deep traversals; that is, anything with a depth greater than 1 (and, in particular, resource.infinity.json). For a fuller discussion, see: http://www.mail-archive.com/dev@sling.apache.org/msg13961.html. -- 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
Backwards compatibility in Mocks: how far to go?
We've got some Mock... classes in org.apache.sling.commons.testing. Generally speaking, these mock the methods the original author needed, and return null/false for all the rest. However, there comes a time when someone else needs a Mock of the same class, but with a few more of the methods implemented. I've found a couple of cases where the Mock classes were copied into the relevant test cases and then modified, which seems a shame. I've fixed up some of those by introducing secondary constructors. (Most of the modified Mocks needed more constructor parameters to implement the new methods anyway, so this sort of came for free.) So, call these Mocks with the old constructor and you'll get old behaviour; call them with the new and you'll get new behaviour. But I've got one where the implementation of a mocked method was just a little too simplistic. I've modified it to do the right thing, and run all the tests I know about. But of course there might be proprietary tests that I don't know about, and while unlikely, it's conceivable that they could rely on the old (less correct) behaviour. I could add a new constructor with a fake parameter (say, int apiVersion), and let it control the behaviour of the two methods. Or, we could say that's too much noise in the code, and if someone updates their testing bundles to newer versions then they should get the more correct implementation (which might show up some real bugs in their tests anyway). WDYT? Thanks, Jeff.
RE: Backwards compatibility in Mocks: how far to go?
Carsten, Agreed on a preference for runtime mocks (although I find Mockito's syntax much more readable than JMock, which turns my brain into a pretzel). But the compile-time mocks I needed in this particular case already existed (for the most part), so it seemed better to extend them. Jeff. -Original Message- From: Carsten Ziegeler [mailto:cziege...@apache.org] Sent: 07 December 2011 10:29 To: dev@sling.apache.org Subject: Re: Backwards compatibility in Mocks: how far to go? Hi, I'm not against enhancing the current mocks, however I ran into similar problems as you and decided to copy the code or create new mocks. This reduces dependencies and ensures that the mock really behaves as you expect. In addition I prefer using jmock (or similar libs) to create mocks on the fly. Regards Carsten 2011/12/7 Jeff Young j...@adobe.com: We've got some Mock... classes in org.apache.sling.commons.testing. Generally speaking, these mock the methods the original author needed, and return null/false for all the rest. However, there comes a time when someone else needs a Mock of the same class, but with a few more of the methods implemented. I've found a couple of cases where the Mock classes were copied into the relevant test cases and then modified, which seems a shame. I've fixed up some of those by introducing secondary constructors. (Most of the modified Mocks needed more constructor parameters to implement the new methods anyway, so this sort of came for free.) So, call these Mocks with the old constructor and you'll get old behaviour; call them with the new and you'll get new behaviour. But I've got one where the implementation of a mocked method was just a little too simplistic. I've modified it to do the right thing, and run all the tests I know about. But of course there might be proprietary tests that I don't know about, and while unlikely, it's conceivable that they could rely on the old (less correct) behaviour. I could add a new constructor with a fake parameter (say, int apiVersion), and let it control the behaviour of the two methods. Or, we could say that's too much noise in the code, and if someone updates their testing bundles to newer versions then they should get the more correct implementation (which might show up some real bugs in their tests anyway). WDYT? Thanks, Jeff. -- Carsten Ziegeler cziege...@apache.org
[jira] [Commented] (SLING-2320) Current DOS-prevention for infinity.json can prevent enumeration of children
[ https://issues.apache.org/jira/browse/SLING-2320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13163970#comment-13163970 ] Jeff Young commented on SLING-2320: --- Felix, your change to the logic turns off the DOS limitation for infinity as well (which is encoded as -1). The second half of the if stmt should be != 1, not 1. I've just finished writing a unit test for the servlet, so I'll go ahead and fix this as well in the patch. I'm planning to upload two separate patches: first the unit test (with this fix in it), and then a cleanup of the exception behaviour. Sound good? Current DOS-prevention for infinity.json can prevent enumeration of children Key: SLING-2320 URL: https://issues.apache.org/jira/browse/SLING-2320 Project: Sling Issue Type: Bug Components: Servlets Affects Versions: Servlets Get 2.1.0 Reporter: Jeff Young Assignee: Felix Meschberger Labels: newbie, patch Fix For: Servlets Get 2.1.4 Attachments: jsonRenderer.diff Original Estimate: 1h Remaining Estimate: 1h A request of resource.1.json should always succeed, as it's the primary method for JSON introspection of the repository hierarchy. DOS protection should only apply to deep traversals; that is, anything with a depth greater than 1 (and, in particular, resource.infinity.json). For a fuller discussion, see: http://www.mail-archive.com/dev@sling.apache.org/msg13961.html. -- 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] [Created] (SLING-2320) Current DOS-prevention for infinity.json can prevent enumeration of children
Current DOS-prevention for infinity.json can prevent enumeration of children Key: SLING-2320 URL: https://issues.apache.org/jira/browse/SLING-2320 Project: Sling Issue Type: Bug Components: Servlets Affects Versions: Servlets Get 2.1.0 Reporter: Jeff Young A request of resource.1.json should always succeed, as it's the primary method for JSON introspection of the repository hierarchy. DOS protection should only apply to deep traversals; that is, anything with a depth greater than 1 (and, in particular, resource.infinity.json). -- 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] [Updated] (SLING-2320) Current DOS-prevention for infinity.json can prevent enumeration of children
[ https://issues.apache.org/jira/browse/SLING-2320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Young updated SLING-2320: -- Description: A request of resource.1.json should always succeed, as it's the primary method for JSON introspection of the repository hierarchy. DOS protection should only apply to deep traversals; that is, anything with a depth greater than 1 (and, in particular, resource.infinity.json). For a fuller discussion, see: http://www.mail-archive.com/dev@sling.apache.org/msg13961.html. was:A request of resource.1.json should always succeed, as it's the primary method for JSON introspection of the repository hierarchy. DOS protection should only apply to deep traversals; that is, anything with a depth greater than 1 (and, in particular, resource.infinity.json). Current DOS-prevention for infinity.json can prevent enumeration of children Key: SLING-2320 URL: https://issues.apache.org/jira/browse/SLING-2320 Project: Sling Issue Type: Bug Components: Servlets Affects Versions: Servlets Get 2.1.0 Reporter: Jeff Young Labels: newbie, patch Original Estimate: 1h Remaining Estimate: 1h A request of resource.1.json should always succeed, as it's the primary method for JSON introspection of the repository hierarchy. DOS protection should only apply to deep traversals; that is, anything with a depth greater than 1 (and, in particular, resource.infinity.json). For a fuller discussion, see: http://www.mail-archive.com/dev@sling.apache.org/msg13961.html. -- 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] [Updated] (SLING-2320) Current DOS-prevention for infinity.json can prevent enumeration of children
[ https://issues.apache.org/jira/browse/SLING-2320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Young updated SLING-2320: -- Attachment: jsonRenderer.diff Ostensibly, this would just be a one-liner. However, I discovered that the routine ResourceTraversor:check() had a rather large side-effect: it collects all the JSON objects which will later be output. So if you don't do a check(), you don't get any output. So I also renamed the routine (and some of its subroutines) such that the primary action is no longer a side-effect. Current DOS-prevention for infinity.json can prevent enumeration of children Key: SLING-2320 URL: https://issues.apache.org/jira/browse/SLING-2320 Project: Sling Issue Type: Bug Components: Servlets Affects Versions: Servlets Get 2.1.0 Reporter: Jeff Young Labels: newbie, patch Attachments: jsonRenderer.diff Original Estimate: 1h Remaining Estimate: 1h A request of resource.1.json should always succeed, as it's the primary method for JSON introspection of the repository hierarchy. DOS protection should only apply to deep traversals; that is, anything with a depth greater than 1 (and, in particular, resource.infinity.json). For a fuller discussion, see: http://www.mail-archive.com/dev@sling.apache.org/msg13961.html. -- 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] [Issue Comment Edited] (SLING-2320) Current DOS-prevention for infinity.json can prevent enumeration of children
[ https://issues.apache.org/jira/browse/SLING-2320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13162978#comment-13162978 ] Jeff Young edited comment on SLING-2320 at 12/5/11 7:45 PM: Note: the patch has SLING- in it (rather than SLING-2320) because I thought I had to create it before creating the JIRA issue. (And then, of course, I forgot to update it before uploading.) was (Author: jeyjey): Note: the patch has SLING- in it because I thought I had to create it before creating the JIRA issue. (And then, of course, I forgot to update it before uploading.) Current DOS-prevention for infinity.json can prevent enumeration of children Key: SLING-2320 URL: https://issues.apache.org/jira/browse/SLING-2320 Project: Sling Issue Type: Bug Components: Servlets Affects Versions: Servlets Get 2.1.0 Reporter: Jeff Young Labels: newbie, patch Attachments: jsonRenderer.diff Original Estimate: 1h Remaining Estimate: 1h A request of resource.1.json should always succeed, as it's the primary method for JSON introspection of the repository hierarchy. DOS protection should only apply to deep traversals; that is, anything with a depth greater than 1 (and, in particular, resource.infinity.json). For a fuller discussion, see: http://www.mail-archive.com/dev@sling.apache.org/msg13961.html. -- 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-2320) Current DOS-prevention for infinity.json can prevent enumeration of children
[ https://issues.apache.org/jira/browse/SLING-2320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13162978#comment-13162978 ] Jeff Young commented on SLING-2320: --- Note: the patch has SLING- in it because I thought I had to create it before creating the JIRA issue. (And then, of course, I forgot to update it before uploading.) Current DOS-prevention for infinity.json can prevent enumeration of children Key: SLING-2320 URL: https://issues.apache.org/jira/browse/SLING-2320 Project: Sling Issue Type: Bug Components: Servlets Affects Versions: Servlets Get 2.1.0 Reporter: Jeff Young Labels: newbie, patch Attachments: jsonRenderer.diff Original Estimate: 1h Remaining Estimate: 1h A request of resource.1.json should always succeed, as it's the primary method for JSON introspection of the repository hierarchy. DOS protection should only apply to deep traversals; that is, anything with a depth greater than 1 (and, in particular, resource.infinity.json). For a fuller discussion, see: http://www.mail-archive.com/dev@sling.apache.org/msg13961.html. -- 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-2320) Current DOS-prevention for infinity.json can prevent enumeration of children
[ https://issues.apache.org/jira/browse/SLING-2320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13163073#comment-13163073 ] Jeff Young commented on SLING-2320: --- Yeah, I was also somewhat concerned by the fact that ResourceTraversor.getParentJSONObject() will throw two exceptions *for every node traversed*. (The first is thrown because the leading / isn't trimmed off of pathDiff, yielding an empty path segment, and the second because the last path looked for is self, which of course doesn't exist yet. But I didn't want to extend my remit beyond what I had been granted permission to fix Current DOS-prevention for infinity.json can prevent enumeration of children Key: SLING-2320 URL: https://issues.apache.org/jira/browse/SLING-2320 Project: Sling Issue Type: Bug Components: Servlets Affects Versions: Servlets Get 2.1.0 Reporter: Jeff Young Assignee: Felix Meschberger Labels: newbie, patch Attachments: jsonRenderer.diff Original Estimate: 1h Remaining Estimate: 1h A request of resource.1.json should always succeed, as it's the primary method for JSON introspection of the repository hierarchy. DOS protection should only apply to deep traversals; that is, anything with a depth greater than 1 (and, in particular, resource.infinity.json). For a fuller discussion, see: http://www.mail-archive.com/dev@sling.apache.org/msg13961.html. -- 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] [Issue Comment Edited] (SLING-2320) Current DOS-prevention for infinity.json can prevent enumeration of children
[ https://issues.apache.org/jira/browse/SLING-2320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13163073#comment-13163073 ] Jeff Young edited comment on SLING-2320 at 12/5/11 9:45 PM: Yeah, I was also somewhat concerned by the fact that ResourceTraversor.getParentJSONObject() will throw two exceptions *for every node traversed*. (The first is thrown because the leading / isn't trimmed off of pathDiff, yielding an empty path segment, and the second because the last path looked for is self, which of course doesn't exist yet.) But I didn't want to extend my remit beyond what I had been granted permission to fix was (Author: jeyjey): Yeah, I was also somewhat concerned by the fact that ResourceTraversor.getParentJSONObject() will throw two exceptions *for every node traversed*. (The first is thrown because the leading / isn't trimmed off of pathDiff, yielding an empty path segment, and the second because the last path looked for is self, which of course doesn't exist yet. But I didn't want to extend my remit beyond what I had been granted permission to fix Current DOS-prevention for infinity.json can prevent enumeration of children Key: SLING-2320 URL: https://issues.apache.org/jira/browse/SLING-2320 Project: Sling Issue Type: Bug Components: Servlets Affects Versions: Servlets Get 2.1.0 Reporter: Jeff Young Assignee: Felix Meschberger Labels: newbie, patch Attachments: jsonRenderer.diff Original Estimate: 1h Remaining Estimate: 1h A request of resource.1.json should always succeed, as it's the primary method for JSON introspection of the repository hierarchy. DOS protection should only apply to deep traversals; that is, anything with a depth greater than 1 (and, in particular, resource.infinity.json). For a fuller discussion, see: http://www.mail-archive.com/dev@sling.apache.org/msg13961.html. -- 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: FW: Issue with DOS limitation in infinity.json servlet
Hi Justin, Yes, the customer could increase the limit, but realistically only after a support call. But I'm more concerned about the component developer who wants to avoid that support call. Their logical next step is to write their own single-level JSON JSP, and that seems like the platform letting them down. Jeff. -Original Message- From: justinedel...@gmail.com [mailto:justinedel...@gmail.com] On Behalf Of Justin Edelson Sent: 01 December 2011 21:50 To: dev@sling.apache.org Subject: Re: FW: Issue with DOS limitation in infinity.json servlet Hi Jeff, I'm not sure why you can't just increase the limit if you run into this problem, but I am not opposed to making this change on principal. I'm very intrigued by the idea of a PostProcessor which limits the number of nodes at a particular point in the hierarchy, but that's not going to be 100% effective as Sling doesn't own the repository per se. Justin On Thu, Dec 1, 2011 at 4:26 PM, Jeff Young j...@adobe.com wrote: The intent behind the limitation seems sound, but the implementation has (to my mind) a slight flaw. A legitimate client which needs the information could presumably implement its own traversal to descend the tree. But this only works if the json servlet is always allowed to return at least a depth of 1. The current implementation limits the depth to 0 if the node in question has more than the limit number of children. I was discussing this with Alex, who pointed out that the intent was to be defensive. However, if we really want to limit the *number of children* a node can have, then we ought to do that elsewhere. Given that a node *does* have a certain number of children, the json servlet needs to at least support the enumeration of said children. So I'd like to propose that we amend the DOS-protection-algorithm to stop at 1, rather than 0. Thoughts? Thanks, Jeff. (PS: apologies if this gets sent out twice, but I think ezmlm ate the first posting because I hadn't yet cofirmed my subscription so I'm re-sending.) Jeff Young | Principal Scientist | Adobe Distinguished Inventor Adobe Systems Software Ireland Ltd. Registered Office: 4-6 Riverwalk, Citywest Business Campus, Saggart, Dublin 24, Ireland Company No. 344992 P Please consider your environmental responsibility before printing this e-mail.
RE: FW: Issue with DOS limitation in infinity.json servlet
I think it's this know in advance that a tree is going to be big concept that we're currently running afoul of. Let's say that I pretty much know that my tree will be small. So I call x/y/z.infinity.json. All well and good. And in another case, that I know that my tree is likely to be colossal, so I implement a search rather than an enumeration. Good again. But in a third case, I know that my tree might be large-ish, so I implement a lazy walk in steps as needed (say, for instance, through a tree control). But if I can't make a single step, then I'm sunk. One could argue that large-ish and DOS aren't really of the same magnitude, and that we just need to raise the default limit. In the tree control instance, even with type-ahead searching it's hard to imagine it being useful for 10,000 entries. But it's clearly useful for 1000 entries (I've got a customer to prove it ;) -- so maybe we just need to raise the default to something like 8K (it's currently 1K). But I still think limiting to one level is a cleaner solution. If a single level has enough nodes to produce a DOS attack, then it seems like you've got more worries than x/y/z.1.json. Jeff. -Original Message- From: ianbos...@gmail.com [mailto:ianbos...@gmail.com] On Behalf Of Ian Boston Sent: 02 December 2011 00:14 To: dev@sling.apache.org Subject: Re: FW: Issue with DOS limitation in infinity.json servlet On 2 December 2011 10:51, Justin Edelson jus...@justinedelson.com wrote: Hmmm. Good point. I changed my mind (slightly) - the behavior Jeff is describing can be supported, but should be disabled by default. Ian - to your question, with the default configuration, /x/y/z.(anything).json should not output 2M child nodes. IMHO, if you as a system operator decide to let clients request all 2M nodes, that should be your prerogative to do so via configuration. Yes, agreed, if you know in advance that a tree is going to be big, then it should be possible to configure it not to do something nasty when a x.-1.json comes in. IIRC Sling already has this capability with ResourceProvider and Resource.listChildren which can be implemented to return no results. Perhaps the protection against DOS should be removed, and users of Sling should be encouraged to use the core Sling API to do the right thing, just a thought ? I think the implementation originally came from one of my use cases, were we were trying to store billions of items in a multi level tree we stopped doing that for all sorts of other reasons and used the Resource.listChildren approach. In reality, however, if you have that type of structure, I think you're more likely to do content discovery by search rather than browse. WDYT? yes very true, Its interesting/depressing to see how often lists are used as a substitute for what is really search. The feature request shortly follows for sorting, and selecting by first letter, and if you watch a user they use the paging, selecting, sorting in real frustration, when all they wanted was to be able to search for the item slap bang in the middle of the result set. Ian Justin On Thu, Dec 1, 2011 at 5:53 PM, Ian Boston i...@tfd.co.uk wrote: Hi, Thinking about this some more, Assuming the content system can support this for a moment. /x/y/z has 2M direct child nodes, what does /x/y/z.-1.json respond with? 2M links to those child nodes. Does the system need to support paging, in the same way atom does? eg /x/y/z.-1.json?page=1 With Sling built on Jackrabbit this doesn't happen (yet), since Jackrabbit (IIUC) stores child nodes internally as an array of pointers on the parent node, so it may not be a real issue, but Sling on something else may encounter this. In general the solution has been to refuse to list child Resources via the Resource interface, and do something custom with paging enforced, but as soon as paging is introduced, order becomes relevant, and that opens up the validity of ordering a map in json, which IIRC is defined as a bag not a list. Ian On 2 December 2011 08:50, Justin Edelson jus...@justinedelson.com wrote: Hi Jeff, I'm not sure why you can't just increase the limit if you run into this problem, but I am not opposed to making this change on principal. I'm very intrigued by the idea of a PostProcessor which limits the number of nodes at a particular point in the hierarchy, but that's not going to be 100% effective as Sling doesn't own the repository per se. Justin On Thu, Dec 1, 2011 at 4:26 PM, Jeff Young j...@adobe.com wrote: The intent behind the limitation seems sound, but the implementation has (to my mind) a slight flaw. A legitimate client which needs the information could presumably implement its own traversal to descend the tree. But this only works if the json servlet is always allowed to return at least a depth of 1. The current implementation limits the depth to 0 if the node in question has more than the limit number of children
FW: Issue with DOS limitation in infinity.json servlet
The intent behind the limitation seems sound, but the implementation has (to my mind) a slight flaw. A legitimate client which needs the information could presumably implement its own traversal to descend the tree. But this only works if the json servlet is always allowed to return at least a depth of 1. The current implementation limits the depth to 0 if the node in question has more than the limit number of children. I was discussing this with Alex, who pointed out that the intent was to be defensive. However, if we really want to limit the *number of children* a node can have, then we ought to do that elsewhere. Given that a node *does* have a certain number of children, the json servlet needs to at least support the enumeration of said children. So I'd like to propose that we amend the DOS-protection-algorithm to stop at 1, rather than 0. Thoughts? Thanks, Jeff. (PS: apologies if this gets sent out twice, but I think ezmlm ate the first posting because I hadn't yet cofirmed my subscription so I'm re-sending.) Jeff Young | Principal Scientist | Adobe Distinguished Inventor Adobe Systems Software Ireland Ltd. Registered Office: 4-6 Riverwalk, Citywest Business Campus, Saggart, Dublin 24, Ireland Company No. 344992 P Please consider your environmental responsibility before printing this e-mail.
[jira] [Created] (SLING-2236) Default POST servlet reports invalid operation when it should report 404
Default POST servlet reports invalid operation when it should report 404 Key: SLING-2236 URL: https://issues.apache.org/jira/browse/SLING-2236 Project: Sling Issue Type: Bug Components: Servlets Reporter: Jeff Young In sling/servlets/post/impl/SlingPostServlet.java's doPost() method, we look up the operation (and report an unknown operation) before checking privileges. I'd like to propose that when the operation is not understood, we first check for read access to the resource, and if unsuccessful, report that instead of reporting invalid operation. Here's the issue: say I define my own POST servlet which supports :operation=foo. I set a sling:resourceType so that my POST servlet gets invoked. All fine and good. Now someone without read access to the resource tries to do an :operation=foo. Sling can't read the sling:resourceType (no read access), and so invokes the default POST servlet instead of my custom POST servlet. It looks up :operation=foo and reports invalid operation (which is pretty misleading). -- 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
