Re: Health Check Core Release?
I've just committed a potential fix for SLING-3321 (Jira is currently down so I'll update the issue later). The result is now only put into the cache, if it's a real result - a timeout result is never cached. As soon as the future now finishes, the result is put into the cache and the future is removed from the list of futures Carsten 2014/1/22 Carsten Ziegeler > Thanks, ok I'll start the vote either on Friday or next Monday. > > Carsten > > > 2014/1/22 Bertrand Delacretaz > >> Hi, >> >> On Wed, Jan 22, 2014 at 2:18 AM, Carsten Ziegeler >> wrote: >> > I'm planning to cut a health check core release, do we have any open >> issues? >> >> There's SLING-3321, I'm not happy with the current executor behavior >> w.r.t slow health checks and caching. >> >> We can release without fixing that right now IMO - even if we need to >> change the executor API to add an options parameters to the executor >> to better handle such cases, that would be a new method, so backwards >> compatible. >> >> -Bertrand >> > > > > -- > Carsten Ziegeler > cziege...@apache.org > -- Carsten Ziegeler cziege...@apache.org
Server Side Tests - do we need two separate projects?
Hi, I was setting up the server side tests for Sling Models in Subversion and wanted to raise this concern now that I have a concrete example to point to. When using Sling's JUnit Server Side support, I think you need two projects: The first project (http://svn.apache.org/repos/asf/sling/trunk/bundles/extensions/models/server-side-tests/) contains the actual tests. The second project (http://svn.apache.org/repos/asf/sling/trunk/bundles/extensions/models/integration-tests/) invokes the tests. Am I correct that both projects are necessary? Or is there a clever way to combine them? Also, assuming that both are necessary, do we have a defined naming convention for these modules? NOTE - this is similar to some of the questions Joerg raised in http://sling.markmail.org/thread/veuy6mglsdjqwqbb Regards, Justin
Re: [jira] [Resolved] (SLING-3313) Provide annotation-driven approach to create Model objects
Hi, On Wed, Jan 22, 2014 at 1:26 PM, Bertrand Delacretaz wrote: > On Wed, Jan 22, 2014 at 6:39 PM, Justin Edelson (JIRA) > wrote: >> Justin Edelson resolved SLING-3313. > .. >> Resolution: Fixed > ... > > Are you planning to add some docs? > > Even something as basic as > http://sling.apache.org/documentation/bundles/caching-services.html > helps people find out about our extensions, and for now I guess that > can point to your yamf wiki page. > > -Bertrand Yes - I'm going to try to migrate the content from the wiki.
Re: rename YAMF to Sling Models
FYI - I have completed this move. On Fri, Jan 10, 2014 at 11:28 AM, Justin Edelson wrote: > I'd like to move YAMF from my whiteboard in to extensions and rename > it as Sling Models. > > https://issues.apache.org/jira/browse/SLING-3313 > > Please speak up if you have an objection. > > Regards, > > Justin
Re: [jira] [Resolved] (SLING-3313) Provide annotation-driven approach to create Model objects
On Wed, Jan 22, 2014 at 6:39 PM, Justin Edelson (JIRA) wrote: > Justin Edelson resolved SLING-3313. .. > Resolution: Fixed ... Are you planning to add some docs? Even something as basic as http://sling.apache.org/documentation/bundles/caching-services.html helps people find out about our extensions, and for now I guess that can point to your yamf wiki page. -Bertrand
Re: [VOTE] Apache Sling API 2.5.0
+1 On Mon, Jan 20, 2014 at 8:57 PM, Carsten Ziegeler wrote: > Hi, > > its finally time for a new API release, we didn't have one for a long time: > > https://issues.apache.org/jira/browse/SLING/fixforversion/12324378 > > Staging repository: > https://repository.apache.org/content/repositories/orgapachesling-1002/ > > 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 1002 /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
[jira] [Resolved] (SLING-3313) Provide annotation-driven approach to create Model objects
[ https://issues.apache.org/jira/browse/SLING-3313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Edelson resolved SLING-3313. --- Resolution: Fixed initial version committed in r1560437 > Provide annotation-driven approach to create Model objects > -- > > Key: SLING-3313 > URL: https://issues.apache.org/jira/browse/SLING-3313 > Project: Sling > Issue Type: New Feature > Components: Extensions >Reporter: Justin Edelson >Assignee: Justin Edelson > Fix For: Sling Models API 1.0.0, Sling Models Implementation 1.0.0 > > > I've been working on a model factory approach in my whiteboard and think it > is at the state to be formally named Sling Models and moved into extensions. > http://svn.apache.org/repos/asf/sling/whiteboard/justin/yamf/ > Code would be repackage and renamed where appropriate. > See > https://cwiki.apache.org/confluence/display/SLING/YAMF+-+Yet+Another+Model+Factory -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (SLING-2938) AdapterMethods annotation and adapter proxy service
[
https://issues.apache.org/jira/browse/SLING-2938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13878882#comment-13878882
]
Konrad Windszus commented on SLING-2938:
I see, thanks for the explanation. When is that gonna be integrated?
> AdapterMethods annotation and adapter proxy service
> ---
>
> Key: SLING-2938
> URL: https://issues.apache.org/jira/browse/SLING-2938
> Project: Sling
> Issue Type: Bug
> Components: Engine, Extensions
>Affects Versions: Adapter 2.1.0
>Reporter: Bertrand Delacretaz
>Priority: Minor
> Attachments: SLING-2938-api.patch, console.jpg
>
>
> Following up on an idea that Olaf Otto presented at CQCon last week, I've
> been working on an @AdapterMethod annotation that makes it easier to create
> Sling adapters, as in
> @Component
> @Service
> public class MyAdapters implements AdapterMethodProvider {
> @AdapterMethod
> public Bar toBar(Foo f) { ... adapt Foo to Bar ... }
> }
> As this requires changes to the sling.api bundle, I'll commit to my
> whiteboard first, for review
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (SLING-3313) Provide annotation-driven approach to create Model objects
[ https://issues.apache.org/jira/browse/SLING-3313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Edelson updated SLING-3313: -- Fix Version/s: Sling Models Implementation 1.0.0 Sling Models API 1.0.0 > Provide annotation-driven approach to create Model objects > -- > > Key: SLING-3313 > URL: https://issues.apache.org/jira/browse/SLING-3313 > Project: Sling > Issue Type: New Feature > Components: Extensions >Reporter: Justin Edelson > Fix For: Sling Models API 1.0.0, Sling Models Implementation 1.0.0 > > > I've been working on a model factory approach in my whiteboard and think it > is at the state to be formally named Sling Models and moved into extensions. > http://svn.apache.org/repos/asf/sling/whiteboard/justin/yamf/ > Code would be repackage and renamed where appropriate. > See > https://cwiki.apache.org/confluence/display/SLING/YAMF+-+Yet+Another+Model+Factory -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Assigned] (SLING-3313) Provide annotation-driven approach to create Model objects
[ https://issues.apache.org/jira/browse/SLING-3313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Edelson reassigned SLING-3313: - Assignee: Justin Edelson > Provide annotation-driven approach to create Model objects > -- > > Key: SLING-3313 > URL: https://issues.apache.org/jira/browse/SLING-3313 > Project: Sling > Issue Type: New Feature > Components: Extensions >Reporter: Justin Edelson >Assignee: Justin Edelson > Fix For: Sling Models API 1.0.0, Sling Models Implementation 1.0.0 > > > I've been working on a model factory approach in my whiteboard and think it > is at the state to be formally named Sling Models and moved into extensions. > http://svn.apache.org/repos/asf/sling/whiteboard/justin/yamf/ > Code would be repackage and renamed where appropriate. > See > https://cwiki.apache.org/confluence/display/SLING/YAMF+-+Yet+Another+Model+Factory -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (SLING-2938) AdapterMethods annotation and adapter proxy service
[
https://issues.apache.org/jira/browse/SLING-2938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13878876#comment-13878876
]
Justin Edelson commented on SLING-2938:
---
Doing the same thing at build time would require additional code generation.
{code}
@Component
@Service
public class MyAdapters implements AdapterMethodProvider {
@AdapterMethod
public Bar toBar(Foo f) { ... adapt Foo to Bar ... }
}
{code}
needs to become (in bytecode terms):
{code}
public class MyAdapters implements AdapterFactory {
public T getAdapter(Object adaptable, Class type) {
return toBar(adaptable);
}
public Bar toBar(Foo f) { ... adapt Foo to Bar ... }
}
{code}
> AdapterMethods annotation and adapter proxy service
> ---
>
> Key: SLING-2938
> URL: https://issues.apache.org/jira/browse/SLING-2938
> Project: Sling
> Issue Type: Bug
> Components: Engine, Extensions
>Affects Versions: Adapter 2.1.0
>Reporter: Bertrand Delacretaz
>Priority: Minor
> Attachments: SLING-2938-api.patch, console.jpg
>
>
> Following up on an idea that Olaf Otto presented at CQCon last week, I've
> been working on an @AdapterMethod annotation that makes it easier to create
> Sling adapters, as in
> @Component
> @Service
> public class MyAdapters implements AdapterMethodProvider {
> @AdapterMethod
> public Bar toBar(Foo f) { ... adapt Foo to Bar ... }
> }
> As this requires changes to the sling.api bundle, I'll commit to my
> whiteboard first, for review
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
Re: [FeatureFlags] Handling of sling:features property
+1 to both. Regards Felix Am 22.01.2014 um 16:34 schrieb Carsten Ziegeler : > Great, I'm fine with this - I just want to make sure that we're all on the > same page :) > > Carsten > > > 2014/1/22 Bertrand Delacretaz > >> On Wed, Jan 22, 2014 at 4:05 PM, Carsten Ziegeler >> wrote: >>> ...Final question, is this still an OR then? So if you have ["-A", "-B"] >> or >>> ["-A", "B"] what does it mean?... >> >> I think we agree on OR so to me >> >> [-A, -B] means "this resource is visible if feature A is disabled OR >> feature B is disabled. >> >> [-A, B] means "this resource is visible if feature A is disabled OR >> feature B is enabled. >> >> And people can implement their own composite Features if they need >> more complex combinations. >> >> -Bertrand >> > > > > -- > Carsten Ziegeler > cziege...@apache.org
RE: [VOTE] Apache Sling Event 3.3.4
+1 best regards mike > -Original Message- > From: Carsten Ziegeler [mailto:cziege...@apache.org] > Sent: Tuesday, January 21, 2014 8:45 PM > To: dev@sling.apache.org > Subject: [VOTE] Apache Sling Event 3.3.4 > > Hi, > > I just discovery a regression bug in the eventing (SLING-3329). Therefore I > would like to call for a vote with a fix: > > > Staging repository: > https://repository.apache.org/content/repositories/orgapachesling-1003/ > > 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 1003 /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
RE: [VOTE] Apache Sling API 2.5.0
+1 best regards mike > -Original Message- > From: Carsten Ziegeler [mailto:cziege...@apache.org] > Sent: Tuesday, January 21, 2014 2:57 AM > To: dev@sling.apache.org > Subject: [VOTE] Apache Sling API 2.5.0 > > Hi, > > its finally time for a new API release, we didn't have one for a long time: > > https://issues.apache.org/jira/browse/SLING/fixforversion/12324378 > > Staging repository: > https://repository.apache.org/content/repositories/orgapachesling-1002/ > > 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 1002 /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
Re: [FeatureFlags] Handling of sling:features property
Great, I'm fine with this - I just want to make sure that we're all on the same page :) Carsten 2014/1/22 Bertrand Delacretaz > On Wed, Jan 22, 2014 at 4:05 PM, Carsten Ziegeler > wrote: > > ...Final question, is this still an OR then? So if you have ["-A", "-B"] > or > > ["-A", "B"] what does it mean?... > > I think we agree on OR so to me > > [-A, -B] means "this resource is visible if feature A is disabled OR > feature B is disabled. > > [-A, B] means "this resource is visible if feature A is disabled OR > feature B is enabled. > > And people can implement their own composite Features if they need > more complex combinations. > > -Bertrand > -- Carsten Ziegeler cziege...@apache.org
Re: [FeatureFlags] Handling of sling:features property
On Wed, Jan 22, 2014 at 4:05 PM, Carsten Ziegeler wrote: > ...Final question, is this still an OR then? So if you have ["-A", "-B"] or > ["-A", "B"] what does it mean?... I think we agree on OR so to me [-A, -B] means "this resource is visible if feature A is disabled OR feature B is disabled. [-A, B] means "this resource is visible if feature A is disabled OR feature B is enabled. And people can implement their own composite Features if they need more complex combinations. -Bertrand
Re: [FeatureFlags] Handling of sling:features property
Great, thanks, yeah I'm fine with "-" Final question, is this still an OR then? So if you have ["-A", "-B"] or ["-A", "B"] what does it mean? Carsten 2014/1/22 Felix Meschberger > Hi > > I am ok, this is easy to implement and I am fine with using "-" as the > indicator — we also use that prefix to indicate URLs which don't need > authentication (AuthConstants.AUTH_REQUIREMENTS). > > Regards > Felix > > Am 22.01.2014 um 15:04 schrieb Carsten Ziegeler : > > > @Felix, wdyt? > > > > Carsten > > > > > > 2014/1/21 Bertrand Delacretaz > > > >> Hi, > >> > >> On Tue, Jan 21, 2014 at 2:38 AM, Carsten Ziegeler > > >> wrote: > >>> ...Can we get some consensus, whether we need to specify that a > resource > >> is > >>> hidden if a feature is enabled?... > >> > >> We need this to implement the "Alternate between resources based on > >> feature flags" use case described at > >> > >> > https://cwiki.apache.org/confluence/display/SLING/Sling+Feature+Flags+support > >> > >>> > >>> The use case I heard of, is that e.g. a button/link(navigation entry is > >>> switched depending whether the feature is available. If it's available > >>> button A is rendered, if not button B - this could be easily done with > >> two > >>> resources, one enabled for the feature and the other one disabled > >> > >> That's what the above use case describes. > >> > >> -Bertrand > >> > > > > > > > > -- > > Carsten Ziegeler > > cziege...@apache.org > > -- Carsten Ziegeler cziege...@apache.org
Re: [FeatureFlags] Handling of sling:features property
Hi I am ok, this is easy to implement and I am fine with using "-" as the indicator — we also use that prefix to indicate URLs which don't need authentication (AuthConstants.AUTH_REQUIREMENTS). Regards Felix Am 22.01.2014 um 15:04 schrieb Carsten Ziegeler : > @Felix, wdyt? > > Carsten > > > 2014/1/21 Bertrand Delacretaz > >> Hi, >> >> On Tue, Jan 21, 2014 at 2:38 AM, Carsten Ziegeler >> wrote: >>> ...Can we get some consensus, whether we need to specify that a resource >> is >>> hidden if a feature is enabled?... >> >> We need this to implement the "Alternate between resources based on >> feature flags" use case described at >> >> https://cwiki.apache.org/confluence/display/SLING/Sling+Feature+Flags+support >> >>> >>> The use case I heard of, is that e.g. a button/link(navigation entry is >>> switched depending whether the feature is available. If it's available >>> button A is rendered, if not button B - this could be easily done with >> two >>> resources, one enabled for the feature and the other one disabled >> >> That's what the above use case describes. >> >> -Bertrand >> > > > > -- > Carsten Ziegeler > cziege...@apache.org
buildbot success in ASF Buildbot on sling-trunk
The Buildbot has detected a restored build on builder sling-trunk while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/sling-trunk/builds/160 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: osiris_ubuntu Build Reason: forced: by IRC user (privmsg): retry failed build Build Source Stamp: HEAD Blamelist: Build succeeded! sincerely, -The Buildbot
Re: [FeatureFlags] Handling of sling:features property
@Felix, wdyt? Carsten 2014/1/21 Bertrand Delacretaz > Hi, > > On Tue, Jan 21, 2014 at 2:38 AM, Carsten Ziegeler > wrote: > > ...Can we get some consensus, whether we need to specify that a resource > is > > hidden if a feature is enabled?... > > We need this to implement the "Alternate between resources based on > feature flags" use case described at > > https://cwiki.apache.org/confluence/display/SLING/Sling+Feature+Flags+support > > > > > The use case I heard of, is that e.g. a button/link(navigation entry is > > switched depending whether the feature is available. If it's available > > button A is rendered, if not button B - this could be easily done with > two > > resources, one enabled for the feature and the other one disabled > > That's what the above use case describes. > > -Bertrand > -- Carsten Ziegeler cziege...@apache.org
Re: Health Check Core Release?
Thanks, ok I'll start the vote either on Friday or next Monday. Carsten 2014/1/22 Bertrand Delacretaz > Hi, > > On Wed, Jan 22, 2014 at 2:18 AM, Carsten Ziegeler > wrote: > > I'm planning to cut a health check core release, do we have any open > issues? > > There's SLING-3321, I'm not happy with the current executor behavior > w.r.t slow health checks and caching. > > We can release without fixing that right now IMO - even if we need to > change the executor API to add an options parameters to the executor > to better handle such cases, that would be a new method, so backwards > compatible. > > -Bertrand > -- Carsten Ziegeler cziege...@apache.org
[jira] [Commented] (SLING-2938) AdapterMethods annotation and adapter proxy service
[
https://issues.apache.org/jira/browse/SLING-2938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13878657#comment-13878657
]
Konrad Windszus commented on SLING-2938:
Why isn't this a pure build time annotation (similar to @SlingServlet)?
> AdapterMethods annotation and adapter proxy service
> ---
>
> Key: SLING-2938
> URL: https://issues.apache.org/jira/browse/SLING-2938
> Project: Sling
> Issue Type: Bug
> Components: Engine, Extensions
>Affects Versions: Adapter 2.1.0
>Reporter: Bertrand Delacretaz
>Priority: Minor
> Attachments: SLING-2938-api.patch, console.jpg
>
>
> Following up on an idea that Olaf Otto presented at CQCon last week, I've
> been working on an @AdapterMethod annotation that makes it easier to create
> Sling adapters, as in
> @Component
> @Service
> public class MyAdapters implements AdapterMethodProvider {
> @AdapterMethod
> public Bar toBar(Foo f) { ... adapt Foo to Bar ... }
> }
> As this requires changes to the sling.api bundle, I'll commit to my
> whiteboard first, for review
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
buildbot failure in ASF Buildbot on sling-trunk
The Buildbot has detected a new failure on builder sling-trunk while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/sling-trunk/builds/159 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: osiris_ubuntu Build Reason: scheduler Build Source Stamp: [branch sling/trunk] 1560342 Blamelist: bdelacretaz BUILD FAILED: failed compile sincerely, -The Buildbot
Re: SLING-3203 - rejecting POST/delete if any selector, extension or suffix?
Thanks everybody for your suggestions, I have now implemented SLING-3203 using status code 403 with a descriptive message. And an integration test. -Bertrand
[jira] [Resolved] (SLING-3203) Post servlet's delete operation deletes parent of nonexisting node
[ https://issues.apache.org/jira/browse/SLING-3203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bertrand Delacretaz resolved SLING-3203. Resolution: Fixed Fix Version/s: Servlets Post 2.3.4 Assignee: Bertrand Delacretaz Implemented in http://svn.apache.org/r1560342 , with integration test. POST :delete now returns 403 with a descriptive message if the request includes selectors, extension or suffix. All integration tests pass. > Post servlet's delete operation deletes parent of nonexisting node > -- > > Key: SLING-3203 > URL: https://issues.apache.org/jira/browse/SLING-3203 > Project: Sling > Issue Type: Bug > Components: Servlets >Affects Versions: Servlets Post 2.3.2 >Reporter: Bertrand Delacretaz >Assignee: Bertrand Delacretaz > Fix For: Servlets Post 2.3.4 > > Attachments: SLING-3203.patch > > > In the below scenario, /tmp/test is gone after the delete operation - the > resource resolver goes up the path of the nonexisting node, and it's > /tmp/test that's provided to the DeleteOperation. > I think we should change this (maybe with a backwards compatibility switch), > as it's clear that the user's intention in this case is not to delete > /tmp/test. Maybe just reject :delete operations if the request has any > selector or extensions. > curl -u admin:admin -X POST http://localhost:8080/tmp/test/some.node > curl -u admin:admin http://localhost:8080/tmp/test.tidy.2.json # looks good > curl -u admin:admin -F:operation=delete > http://localhost:8080/tmp/test.other/nothing > curl -u admin:admin http://localhost:8080/tmp/test.tidy.2.json # 404 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
Re: SLING-3203 - rejecting POST/delete if any selector, extension or suffix?
Hi Am 22.01.2014 um 13:12 schrieb Dominik Süß : > I just checked the RFC for statuscodes and 403 seems appropriate while 409 > seems to be wrong. > Although you could argue the user can resolve the conflict by changing the > URI the new URI has a new target (since the URI does not know about > concepts like selectors or suffixes) and therefore is a different request > (the versioning example indicates that the intention is a conflict created > by the payload). Yes, that was my idea for 409. But I am fine with 403, too. Regards Felix > IMHO 403 would be good and could return an info what > exactly was wrong with the request (like "Found suffix [extension | > selectors] for POST request"). > > Regards, > Dominik > > > On Wed, Jan 22, 2014 at 10:34 AM, Bertrand Delacretaz < > bdelacre...@apache.org> wrote: > >> On Wed, Jan 22, 2014 at 9:58 AM, Felix Meschberger >> wrote: >>> ...I am not sure about the 404 response. How about 409/CONFLICT or >> 403/FORBIDDEN ? >> >> 403/FORBIDDEN sounds good, will do that. >> >>> >>> Finally: Lets consider not allowing selector, extension, and suffix on >> all requests handled by the SlingPostServlet ? >> >> That's a different topic. >> -Bertrand >>
Re: SLING-3203 - rejecting POST/delete if any selector, extension or suffix?
I just checked the RFC for statuscodes and 403 seems appropriate while 409 seems to be wrong. Although you could argue the user can resolve the conflict by changing the URI the new URI has a new target (since the URI does not know about concepts like selectors or suffixes) and therefore is a different request (the versioning example indicates that the intention is a conflict created by the payload). IMHO 403 would be good and could return an info what exactly was wrong with the request (like "Found suffix [extension | selectors] for POST request"). Regards, Dominik On Wed, Jan 22, 2014 at 10:34 AM, Bertrand Delacretaz < bdelacre...@apache.org> wrote: > On Wed, Jan 22, 2014 at 9:58 AM, Felix Meschberger > wrote: > > ...I am not sure about the 404 response. How about 409/CONFLICT or > 403/FORBIDDEN ? > > 403/FORBIDDEN sounds good, will do that. > > > > > Finally: Lets consider not allowing selector, extension, and suffix on > all requests handled by the SlingPostServlet ? > > That's a different topic. > -Bertrand >
[jira] [Resolved] (SLING-3049) Make Logback Stacktrace Packaging data support OSGi aware
[ https://issues.apache.org/jira/browse/SLING-3049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra resolved SLING-3049. Resolution: Won't Fix Fix Version/s: (was: Commons Log 4.0.0) Resolving as Won't Fix for now given the issue in supporting such a feature in OSGi env. If later need arises for same and we have a working solution we can enable it > Make Logback Stacktrace Packaging data support OSGi aware > - > > Key: SLING-3049 > URL: https://issues.apache.org/jira/browse/SLING-3049 > Project: Sling > Issue Type: Improvement > Components: Commons >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra > Labels: logback > Attachments: SLING-3049.patch, > buildbot-exceptions-while-stopping-jetty.txt > > > Logback provides a useful feature where it dumps the Class packaging Data > along with the stacktrace [1]. This provides a quick view of the location > from where classes in a given stacktrace are coming. Its default logic does > not work properly in OSGi env. Hence it would be useful to patch its logic to > become OSGi aware > [1] http://logback.qos.ch/reasonsToSwitch.html#packagingData -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (SLING-3049) Make Logback Stacktrace Packaging data support OSGi aware
[ https://issues.apache.org/jira/browse/SLING-3049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13878558#comment-13878558 ] Chetan Mehrotra commented on SLING-3049: I need to rework the pull request. However the problem is (as explained in my last comment above) this feature is tricky to implement in OSGi env. So better to disable it for now. So its bit low priority now > Make Logback Stacktrace Packaging data support OSGi aware > - > > Key: SLING-3049 > URL: https://issues.apache.org/jira/browse/SLING-3049 > Project: Sling > Issue Type: Improvement > Components: Commons >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra > Labels: logback > Fix For: Commons Log 4.0.0 > > Attachments: SLING-3049.patch, > buildbot-exceptions-while-stopping-jetty.txt > > > Logback provides a useful feature where it dumps the Class packaging Data > along with the stacktrace [1]. This provides a quick view of the location > from where classes in a given stacktrace are coming. Its default logic does > not work properly in OSGi env. Hence it would be useful to patch its logic to > become OSGi aware > [1] http://logback.qos.ch/reasonsToSwitch.html#packagingData -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (SLING-3252) Remove checked in Logback related classes before 4.x release
[ https://issues.apache.org/jira/browse/SLING-3252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13878555#comment-13878555 ] Chetan Mehrotra commented on SLING-3252: bq. Assuming the current logback trunk was released, would it allow use to remove the logback classes that we currently include? Yup. * [LOGBACK-384|http://jira.qos.ch/browse/LOGBACK-384] is critical and is fixed. * [LOGBACK-899|http://jira.qos.ch/browse/LOGBACK-899] is kind of good to have feature and optional. Further it causes issue in OSGi env as explained in [SLING-3049|https://issues.apache.org/jira/browse/SLING-3049?focusedCommentId=13847427] > Remove checked in Logback related classes before 4.x release > > > Key: SLING-3252 > URL: https://issues.apache.org/jira/browse/SLING-3252 > Project: Sling > Issue Type: Task > Components: Commons >Affects Versions: Commons Log 4.0.0 >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra >Priority: Blocker > Fix For: Commons Log 4.0.0 > > > Currently the Common Log bundle has checked in 2 Logback classes as a fix for > SLING-3037 and SLING-3049. These classes are under EPL and cannot be part of > released bundle > See http://sling.markmail.org/thread/ilixl3ebdd3hxxts -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (SLING-3330) Allow asynchronous package import
[ https://issues.apache.org/jira/browse/SLING-3330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tommaso Teofili resolved SLING-3330. Resolution: Fixed resolved in r1560302 > Allow asynchronous package import > - > > Key: SLING-3330 > URL: https://issues.apache.org/jira/browse/SLING-3330 > Project: Sling > Issue Type: Improvement > Components: Extensions >Reporter: Tommaso Teofili >Assignee: Tommaso Teofili > Labels: replication > > Let the ReplicationPackageImporter be able to import replication package > streams asynchronously, this will involve having its own queue. > In the future it may be worth moving such functionalities directly into > polling agents so that existing queue providers and queue distribution > strategy can be used also for package imports. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (SLING-3330) Allow asynchronous package import
Tommaso Teofili created SLING-3330: -- Summary: Allow asynchronous package import Key: SLING-3330 URL: https://issues.apache.org/jira/browse/SLING-3330 Project: Sling Issue Type: Improvement Components: Extensions Reporter: Tommaso Teofili Assignee: Tommaso Teofili Let the ReplicationPackageImporter be able to import replication package streams asynchronously, this will involve having its own queue. In the future it may be worth moving such functionalities directly into polling agents so that existing queue providers and queue distribution strategy can be used also for package imports. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
Re: [VOTE] Apache Sling Event 3.3.4
+1 Ian On 22 January 2014 09:31, Tommaso Teofili wrote: > +1 > > Tommaso > > > 2014/1/21 Carsten Ziegeler > >> Hi, >> >> I just discovery a regression bug in the eventing (SLING-3329). Therefore I >> would like to call for a vote with a fix: >> >> >> Staging repository: >> https://repository.apache.org/content/repositories/orgapachesling-1003/ >> >> 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 1003 /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 >>
Re: Health Check Core Release?
Hi, On Wed, Jan 22, 2014 at 2:18 AM, Carsten Ziegeler wrote: > I'm planning to cut a health check core release, do we have any open issues? There's SLING-3321, I'm not happy with the current executor behavior w.r.t slow health checks and caching. We can release without fixing that right now IMO - even if we need to change the executor API to add an options parameters to the executor to better handle such cases, that would be a new method, so backwards compatible. -Bertrand
[jira] [Updated] (SLING-3321) Incorrect caching/timeout behavior with slow health check
[ https://issues.apache.org/jira/browse/SLING-3321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bertrand Delacretaz updated SLING-3321: --- Component/s: (was: Extensions) Health Check > Incorrect caching/timeout behavior with slow health check > - > > Key: SLING-3321 > URL: https://issues.apache.org/jira/browse/SLING-3321 > Project: Sling > Issue Type: Bug > Components: Health Check >Affects Versions: Health Check Core 1.0.8 >Reporter: Bertrand Delacretaz >Assignee: Bertrand Delacretaz > Attachments: SLING-3321-log.txt > > > We might not need to fix this right now, just making a note of some tests I > did with the SlowHealthCheckSample. > By default SlowHealthCheckSample takes 1200-3700 msec to execute, and I have > set the cache lifetime to 5 seconds. > With these settings, executing the health check every second should always > provide a result: even if a particular execute call takes more than the > default 2 seconds execution timeout, an older cached result should still be > available as 3700 (max execution time) + 1000 (execution period) is smaller > than 5000 (time to live in cache) > I'll attach an execution log which shows that this is not the case. I see two > problems: > # A result which times out is cached and reused, even though the actual > execution might have finished in the meantime. We then get a timeout result > and the actual result is thrown away. There's no " execution counter=2" > result in my log for example. > # There's no way to say "execute the health check, but if it times out use an > older result if still valid". We might need an execution option for that, as > you don't always want that. > I think this is a realistic use case, checking external systems for example > might have that kind of timing characteristics. I should be able to call the > executor for such an HC every second, for example, and get a result every > time,. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
Re: SLING-3203 - rejecting POST/delete if any selector, extension or suffix?
On Wed, Jan 22, 2014 at 9:58 AM, Felix Meschberger wrote: > ...I am not sure about the 404 response. How about 409/CONFLICT or > 403/FORBIDDEN ? 403/FORBIDDEN sounds good, will do that. > > Finally: Lets consider not allowing selector, extension, and suffix on all > requests handled by the SlingPostServlet ? That's a different topic. -Bertrand
Re: [VOTE] Apache Sling Event 3.3.4
+1 Tommaso 2014/1/21 Carsten Ziegeler > Hi, > > I just discovery a regression bug in the eventing (SLING-3329). Therefore I > would like to call for a vote with a fix: > > > Staging repository: > https://repository.apache.org/content/repositories/orgapachesling-1003/ > > 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 1003 /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 >
Re: [VOTE] Apache Sling Event 3.3.4
+1 Regards Felix Am 21.01.2014 um 20:45 schrieb Carsten Ziegeler : > Hi, > > I just discovery a regression bug in the eventing (SLING-3329). Therefore I > would like to call for a vote with a fix: > > > Staging repository: > https://repository.apache.org/content/repositories/orgapachesling-1003/ > > 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 1003 /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
[jira] [Commented] (SLING-3203) Post servlet's delete operation deletes parent of nonexisting node
[ https://issues.apache.org/jira/browse/SLING-3203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13878438#comment-13878438 ] Bertrand Delacretaz commented on SLING-3203: I agree that something "worse" than 404 is good to express the problem clearly. I wouldn't use 409 as http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html says "this code is only allowed in situations where it is expected that the user might be able to resolve the conflict and resubmit the request" but here resubmitting will fail every time. My (current ;-) favorite is 403, "the server understood the request, but is refusing to fulfill it - authorization will not help and the request SHOULD NOT be repeated". I'll implement it like that then. bq. I wonder, whether we should not forbid selectors and extensions completely on the SlingPostServlet I'm not in favor of that but let's discuss on the dev list if needed, that's a distinct topic. > Post servlet's delete operation deletes parent of nonexisting node > -- > > Key: SLING-3203 > URL: https://issues.apache.org/jira/browse/SLING-3203 > Project: Sling > Issue Type: Bug > Components: Servlets >Affects Versions: Servlets Post 2.3.2 >Reporter: Bertrand Delacretaz > Attachments: SLING-3203.patch > > > In the below scenario, /tmp/test is gone after the delete operation - the > resource resolver goes up the path of the nonexisting node, and it's > /tmp/test that's provided to the DeleteOperation. > I think we should change this (maybe with a backwards compatibility switch), > as it's clear that the user's intention in this case is not to delete > /tmp/test. Maybe just reject :delete operations if the request has any > selector or extensions. > curl -u admin:admin -X POST http://localhost:8080/tmp/test/some.node > curl -u admin:admin http://localhost:8080/tmp/test.tidy.2.json # looks good > curl -u admin:admin -F:operation=delete > http://localhost:8080/tmp/test.other/nothing > curl -u admin:admin http://localhost:8080/tmp/test.tidy.2.json # 404 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
Re: SLING-3203 - rejecting POST/delete if any selector, extension or suffix?
Hi As noted in the issue: I agree that we should do this. I am not sure about the 404 response. How about 409/CONFLICT or 403/FORBIDDEN ? Finally: Lets consider not allowing selector, extension, and suffix on all requests handled by the SlingPostServlet ? Regards Felix Am 21.01.2014 um 14:44 schrieb Bertrand Delacretaz : > Hi, > > What do people think about applying the SLING-3203 patch? > > It causes the POST servlet to reject any :delete operation that has a > selector, extension or suffix - might cause some backward incompatible > behavior but the current behavior feels wrong to me. > > The patch returns a status 400 when rejecting the request, we'd change > that to 404 as discussed there. > > WDYT? > -Bertrand
[jira] [Commented] (SLING-3203) Post servlet's delete operation deletes parent of nonexisting node
[ https://issues.apache.org/jira/browse/SLING-3203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13878420#comment-13878420 ] Felix Meschberger commented on SLING-3203: -- I agree with the 400 part not being appropriate. I am not really sure about 404 being the right code, though. Rather I think it would be 403/FORBIDDEN (we don't allow this operation on this resource [URL]) or maybe even 409/CONFLICT (because we generally allow this method on this URL but in this context) WDYT ? Going a step further: I wonder, whether we should not forbid selectors and extensions completely on the SlingPostServlet ? > Post servlet's delete operation deletes parent of nonexisting node > -- > > Key: SLING-3203 > URL: https://issues.apache.org/jira/browse/SLING-3203 > Project: Sling > Issue Type: Bug > Components: Servlets >Affects Versions: Servlets Post 2.3.2 >Reporter: Bertrand Delacretaz > Attachments: SLING-3203.patch > > > In the below scenario, /tmp/test is gone after the delete operation - the > resource resolver goes up the path of the nonexisting node, and it's > /tmp/test that's provided to the DeleteOperation. > I think we should change this (maybe with a backwards compatibility switch), > as it's clear that the user's intention in this case is not to delete > /tmp/test. Maybe just reject :delete operations if the request has any > selector or extensions. > curl -u admin:admin -X POST http://localhost:8080/tmp/test/some.node > curl -u admin:admin http://localhost:8080/tmp/test.tidy.2.json # looks good > curl -u admin:admin -F:operation=delete > http://localhost:8080/tmp/test.other/nothing > curl -u admin:admin http://localhost:8080/tmp/test.tidy.2.json # 404 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
