date:20190109

JEBailey commented on a change in pull request #1: Sling 3270
URL: 
https://github.com/apache/sling-org-apache-sling-commons-html/pull/1#discussion_r246518430
 
 

 ##
 File path: pom.xml
 ##
 @@ -37,25 +37,36 @@
 
 
 8
-4.11.0
+4.12.0
+UTF-8
+
UTF-8
 
 
 
 
scm:git:https://gitbox.apache.org/repos/asf/sling-org-apache-sling-commons-html.git
 
scm:git:https://gitbox.apache.org/repos/asf/sling-org-apache-sling-commons-html.git
 
https://gitbox.apache.org/repos/asf?p=sling-org-apache-sling-commons-html.git
-  HEAD
-  
+HEAD
+
 
 
 
 
-biz.aQute.bnd
-bnd-maven-plugin
 
 Review comment:
   @rombert Some additional details on this. This bundle was using 
maven-bundle-plugin up until the prior release when there a desire to install a 
pax exam test and it was discovered there was a problem with the pax exam.  see 
https://issues.apache.org/jira/browse/SLING-7351. This particular bundle had a 
more complex solution then the one detailed in the link, with a bnd.bnd file 
specified and a change to bnd-maven-plugin. The maven-bundle-plugin provides a 
far better experience from a build perspective with a more detailed generation 
of a baseline report and with less configuration. So I took the suggested 
comment in that JIRA and updated this code accordingly


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[jira] [Assigned] (SLING-7256) Sling Models injector for CAConfig

2019-01-09 Thread Stefan Seifert (JIRA)



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

Stefan Seifert reassigned SLING-7256:
-

Assignee: Stefan Seifert

> Sling Models injector for CAConfig
> --
>
> Key: SLING-7256
> URL: https://issues.apache.org/jira/browse/SLING-7256
> Project: Sling
>  Issue Type: New Feature
>Affects Versions: Sling Models Impl 1.4.4
>Reporter: Henry Kuijpers
>Assignee: Stefan Seifert
>Priority: Major
>
> It would be great to have a Sling Models injector for CAConfig.
> An example could be:
> {code}
> @Component
> public class ContextAwareConfigurationInjector implements Injector {
> public String getName() {
> return "ca-config";
> }
> public Object getValue(Object adaptable, String name, Type declaredType, 
> AnnotatedElement element,
>DisposalCallbackRegistry callbackRegistry) {
> if (isConfigurationObject(declaredType)) {
> final Resource resource;
> if (adaptable instanceof Resource) {
> resource = (Resource) adaptable;
> } else if (adaptable instanceof SlingHttpServletRequest) {
> // TODO: Is this always the correct resource? (Most often we 
> want the one in /content)
> // So we do not want /conf/... for example
> final SlingHttpServletRequest request = 
> (SlingHttpServletRequest)adaptable;
> final ResourceResolver resourceResolver = 
> request.getResourceResolver();
> resource = resourceResolver.resolve(request, 
> request.getRequestURI());
> } else {
> throw new IllegalArgumentException("Either a resource or the 
> request should be used");
> }
> final ConfigurationBuilder builder = 
> resource.adaptTo(ConfigurationBuilder.class);
> if (builder != null) {
> return builder.as((Class) declaredType);
> }
> }
> return null;
> }
> private static boolean isConfigurationObject(Type type) {
> if (!(type instanceof Class)) {
> return false;
> }
> Class clazz = (Class) type;
> return clazz.isAnnotation() && 
> clazz.isAnnotationPresent(Configuration.class);
> }
> }
> {code}
> + annotation:
> {code}
> @Target({ ElementType.FIELD, ElementType.METHOD, ElementType.PARAMETER })
> @Retention(RetentionPolicy.RUNTIME)
> @InjectAnnotation
> @Source("ca-config")
> @Qualifier
> public @interface CaConfig {
> }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SLING-7256) Sling Models injector for CAConfig

2019-01-09 Thread Stefan Seifert (JIRA)



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

Stefan Seifert commented on SLING-7256:
---

we will create a separate git repository 
*sling-org-apache-sling-models-caconfig* for this type of extensions.

coming back to the API discussion - [~Sc0rpic0m] why do you think the @Via 
approach is better?

from my point of view the following features need to be supported by this type 
of integration:
* take the current resource as context resource (adapted from request or 
resource), and lookup the matching context-aware configuration
* the variable to inject to can be either
** an annotation class describing the configuration (type-safe, automatically 
defines the name of the caconfig)
** or a ValueMap (in which case the caconfig name has to be provided manually)
** or for lowlevel access the resource itself (in this case the bucket name has 
to be specified as well)
* we also need to support collections of all those for configuration lists

this can be easily done in a Injector annotation. does it also work using Via? 
please keep in mind that the value map returned from caconfig is not the same 
as adapted from the lowlevel resource, as it respects also default values, 
inheritance etc.

> Sling Models injector for CAConfig
> --
>
> Key: SLING-7256
> URL: https://issues.apache.org/jira/browse/SLING-7256
> Project: Sling
>  Issue Type: New Feature
>Affects Versions: Sling Models Impl 1.4.4
>Reporter: Henry Kuijpers
>Priority: Major
>
> It would be great to have a Sling Models injector for CAConfig.
> An example could be:
> {code}
> @Component
> public class ContextAwareConfigurationInjector implements Injector {
> public String getName() {
> return "ca-config";
> }
> public Object getValue(Object adaptable, String name, Type declaredType, 
> AnnotatedElement element,
>DisposalCallbackRegistry callbackRegistry) {
> if (isConfigurationObject(declaredType)) {
> final Resource resource;
> if (adaptable instanceof Resource) {
> resource = (Resource) adaptable;
> } else if (adaptable instanceof SlingHttpServletRequest) {
> // TODO: Is this always the correct resource? (Most often we 
> want the one in /content)
> // So we do not want /conf/... for example
> final SlingHttpServletRequest request = 
> (SlingHttpServletRequest)adaptable;
> final ResourceResolver resourceResolver = 
> request.getResourceResolver();
> resource = resourceResolver.resolve(request, 
> request.getRequestURI());
> } else {
> throw new IllegalArgumentException("Either a resource or the 
> request should be used");
> }
> final ConfigurationBuilder builder = 
> resource.adaptTo(ConfigurationBuilder.class);
> if (builder != null) {
> return builder.as((Class) declaredType);
> }
> }
> return null;
> }
> private static boolean isConfigurationObject(Type type) {
> if (!(type instanceof Class)) {
> return false;
> }
> Class clazz = (Class) type;
> return clazz.isAnnotation() && 
> clazz.isAnnotationPresent(Configuration.class);
> }
> }
> {code}
> + annotation:
> {code}
> @Target({ ElementType.FIELD, ElementType.METHOD, ElementType.PARAMETER })
> @Retention(RetentionPolicy.RUNTIME)
> @InjectAnnotation
> @Source("ca-config")
> @Qualifier
> public @interface CaConfig {
> }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [DISCUSS] Deprecate query part of Sling Event API


On 09.01.19 16:41, Daniel Klco wrote:

Because I was looking at the Sling 7 JavaDoc :-) Strangely the Job
interface doesn't seem to be present in the newer JavaDocs.


That must be a mistake. Perhaps related to separating the API from the 
implementation bundle?


Cheers,
Stefan

Re: [DISCUSS] Deprecate query part of Sling Event API

On 09.01.19 15:38, Jason E Bailey wrote:

On Wed, Jan 9, 2019, at 3:05 AM, Stefan Egli wrote:

(a) having to support job queries makes messaging-based implementations
hard. You typically don't want to do queries against a messaging system.
So this is not only about the default resource-based implementation but
allowing alternatives better.

I don't support your logic. It's a poor design to perform queries via a messaging system, but you absolutely need to be able to query 'that which is doing the processing' as to the state of the jobs.

Right, some implementation might need that, but why do you absolutely
need to expose that state in the API.

This is almost moot with a resource based implementation because it's really
easy to find that information out by looking at the resource tree. However if
the goal is to implement it in another manner then you'll need a consistent
interface to access that data.

If you're talking about doing a PDMS and you're looking at the Sling Event API
as the model for message generation across distinct micro service
implementations. I do agree that the API for the queries should be pulled out
to a separate API, that makes sense since your doing a CQRS pattern. But you're
replacing the methods not eliminating them.

What would you suggest replacing the methods with?

The problem is that your using oak queries to process data that is in a
specific location. That's not a good practice. Doing a JCR query to find
disparate resources is useful when you have a large set. When you already know
where the set of data is and your effectively using a query to filter through
the nodes. You end up killing yourself.

I can modify the code this week to be as performant as you are currently
getting with an index, without using an index, with less memory , eliminating
the whole concern of maintaining indexes.

I don't know the full history of why the index was introduced - I'm
guessing it was considered an improvement to traversing the tree
manually for doing rescans..

Cheers,
Stefan

Re: [DISCUSS] Deprecate query part of Sling Event API

2019-01-09 Thread Daniel Klco

Because I was looking at the Sling 7 JavaDoc :-) Strangely the Job
interface doesn't seem to be present in the newer JavaDocs.

On Wed, Jan 9, 2019 at 10:31 AM Stefan Egli  wrote:

> On 09.01.19 15:01, Daniel Klco wrote:
> > I would argue though that there is a significant loss of functionality by
> > eliminating the ability to see what jobs exist on an instance.
>
> Agree, that's why I suggested B over A.
>
> > What if
> > rather than eliminating the functionality entirely a new interface was
> > created for a "LocalJobManager" and the query based functionality moved
> > there?  This interface would only be supported for the resource-based
> > implementation and would allow for querying only the local instance (e.g.
> > it may not accurately reflect distributed jobs).
>
> If the LocalJobManager interface becomes optional, then what is a user
> of that interface to do when it is not available (eg in an alternative
> event implementation)?
>
> > On another topic, what does everyone think of adding a method into the
> Job
> > interface for getting the entire ValueMap / java.util.Map of properties?
> > Right now it's very cumbersome to work with jobs via Expression Language.
>
> Not sure I understand - why would Job.getProperties() not suffice?
>
> Cheers,
> Stefan
>
> >
> > On Wed, Jan 9, 2019 at 3:05 AM Stefan Egli 
> wrote:
> >
> >> The problem is two fold:
> >>
> >> (a) having to support job queries makes messaging-based implementations
> >> hard. You typically don't want to do queries against a messaging system.
> >> So this is not only about the default resource-based implementation but
> >> allowing alternatives better.
> >>
> >> (b) in order to support queries in the existing resource-based
> >> implementation we're using indexes already. So the query itself is not
> >> expensive - but maintaining the index is a cost which you don't need to
> >> do if there wouldn't be any query to support in the first place.
> >>
> >> So it's two different aspects which both would benefit if there were no
> >> queries to support.
> >>
> >> With variant A we'd get rid of them long term, with variant B we're
> >> selectively getting rid of them on a case-by-case basis.
> >>
> >> Cheers,
> >> Stefan
> >>
> >> On 09.01.19 01:32, Daniel Klco wrote:
> >>> Yeah I must admit I'm confused as well, looking through the email
> threads
> >>> the original proposal is to return and a iterator rather than a
> >> collection.
> >>> If the problem is that too many jobs being returned causes heap
> issues, I
> >>> would think this would resolve that problem. Is there some other
> problem
> >>> here? If it is in query performance, could it possibly be solved using
> >> oak
> >>> indexes?
> >>>
> >>> On Tue, Jan 8, 2019, 3:50 PM Jason E Bailey  >> wrote:
> >>>
>  So I'm missing something here, from what I gather so far, the methods
> >> that
>  are being deprecated are to prevent a performance issue but the node
>  structure that represents the jobs is in one place isn't it? How in
> the
>  world are we getting a performance issue from that?
> 
>  Is there a use case to demonstrate the performance problem?
> 
>  --
>  Jason
> 
>  On Tue, Jan 8, 2019, at 11:12 AM, Carsten Ziegeler wrote:
> > Hi,
> >
> > I agree, variant B sounds like the better option due to the reasons
> you
> > mention. It also provides a step by step way of moving a single type
> of
> > jobs to not use search anymore.
> >
> > The only downside is that this doesn't force anyone to think about
> her
> > job usage as everything just runs as before. Only if you want to
> >> improve
> > you can and adjust the configurations.
> >
> >
> > Regards
> >
> > Carsten
> >
> >
> > Stefan Egli wrote
> >> Hi,
> >>
> >> I've given this job query issue some more thought and would like us
> to
> >> discuss and hopefully soon agree on which way we go:
> >>
> >>
> >> Variant A: deprecate job query methods (as suggested originally):
> >> * upside: eventually we'll have a cleaner job API
> >> * downside: users of the job query API need to find alternatives to
> >> queries, individually
> >>
> >>
> >> Variant B: allow disabling job queries (https://s.apache.org/68ys):
> >> * upside: allows performance optimizations on a case-by-case basis
> >> (optimizations include not requiring indexing), thereby promoting
> >> query-less use cases going forward without API deprecation
>  nevertheless.
> >> * downside: we stick to the current job API
> >>
> >>
> >> Note that in both cases the 'org.apache.sling.event.jobs' export
>  version
> >> will have to be updated from 2.0.1 to 2.1.0 - which will affect
> >> users/customers that implement interfaces from that package (that's
>  not
> >> something typical though, but there are a few exotic cases where
>  that's
> >> the case).
>

RE: [DISCUSS] integration of sling models with context-aware configuration - which way around

2019-01-09 Thread Stefan Seifert

result: most prefer c) = a separate module - i'm fine with it.

i propose "sling-org-apache-sling-models-caconfig" as name for the new git 
repository. i will take care of creating the repo.


> PS I think @Via is the way to go, not @Source, so a @ViaProvider. From there 
> you can adapt it to ValueMap or Resource or whatever you wish.

this is a second step! - we can continue the discussion about the best approach 
for the API in SLING-7256

stefan


>-Original Message-
>From: Stefan Seifert [mailto:sseif...@pro-vision.de]
>Sent: Monday, January 7, 2019 1:33 PM
>To: dev@sling.apache.org
>Subject: [DISCUSS] integration of sling models with context-aware
>configuration - which way around
>
>there is a wish to integrate sling models with context-aware configuration
>to add a new injector and injector annotation that allows to inject
>context-aware configuration typed objects or property values in your sling
>models. we have contributions for two approaches, one from the sling models
>side [1] and one from the caconfig side [2][3].
>
>i'm currently not sure what is the best approach. it is clear that we want
>to avoid hard dependency of sling models to caconfig and vice versa.
>
>there are basically three options:
>
>a) add support for it in sling models API+impl with an optional dependency
>to caconfig API (injector will not be available when caconfig bundles is
>not there)
>b) add support for it in caconfig API+impl with an optional dependency to
>models API
>c) create a separate module integrating both, as it is done e.g. for sling
>models and sling validation [4], requiring to deploy an additional bundle
>
>I would prefer a) or c).
>
>WDYT?
>
>stefan
>
>[1] https://issues.apache.org/jira/browse/SLING-7256
>[2] https://github.com/apache/sling-org-apache-sling-caconfig-api/pull/1
>[3] https://github.com/apache/sling-org-apache-sling-caconfig-impl/pull/1
>[4] https://github.com/apache/sling-org-apache-sling-models-validation-impl
>
>

Re: [DISCUSS] Deprecate query part of Sling Event API


On 09.01.19 15:01, Daniel Klco wrote:

I would argue though that there is a significant loss of functionality by
eliminating the ability to see what jobs exist on an instance. 


Agree, that's why I suggested B over A.


What if
rather than eliminating the functionality entirely a new interface was
created for a "LocalJobManager" and the query based functionality moved
there?  This interface would only be supported for the resource-based
implementation and would allow for querying only the local instance (e.g.
it may not accurately reflect distributed jobs).


If the LocalJobManager interface becomes optional, then what is a user 
of that interface to do when it is not available (eg in an alternative 
event implementation)?



On another topic, what does everyone think of adding a method into the Job
interface for getting the entire ValueMap / java.util.Map of properties?
Right now it's very cumbersome to work with jobs via Expression Language.


Not sure I understand - why would Job.getProperties() not suffice?

Cheers,
Stefan



On Wed, Jan 9, 2019 at 3:05 AM Stefan Egli  wrote:


The problem is two fold:

(a) having to support job queries makes messaging-based implementations
hard. You typically don't want to do queries against a messaging system.
So this is not only about the default resource-based implementation but
allowing alternatives better.

(b) in order to support queries in the existing resource-based
implementation we're using indexes already. So the query itself is not
expensive - but maintaining the index is a cost which you don't need to
do if there wouldn't be any query to support in the first place.

So it's two different aspects which both would benefit if there were no
queries to support.

With variant A we'd get rid of them long term, with variant B we're
selectively getting rid of them on a case-by-case basis.

Cheers,
Stefan

On 09.01.19 01:32, Daniel Klco wrote:

Yeah I must admit I'm confused as well, looking through the email threads
the original proposal is to return and a iterator rather than a

collection.

If the problem is that too many jobs being returned causes heap issues, I
would think this would resolve that problem. Is there some other problem
here? If it is in query performance, could it possibly be solved using

oak

indexes?

On Tue, Jan 8, 2019, 3:50 PM Jason E Bailey 
wrote:



So I'm missing something here, from what I gather so far, the methods

that

are being deprecated are to prevent a performance issue but the node
structure that represents the jobs is in one place isn't it? How in the
world are we getting a performance issue from that?

Is there a use case to demonstrate the performance problem?

--
Jason

On Tue, Jan 8, 2019, at 11:12 AM, Carsten Ziegeler wrote:

Hi,

I agree, variant B sounds like the better option due to the reasons you
mention. It also provides a step by step way of moving a single type of
jobs to not use search anymore.

The only downside is that this doesn't force anyone to think about her
job usage as everything just runs as before. Only if you want to

improve

you can and adjust the configurations.


Regards

Carsten


Stefan Egli wrote

Hi,

I've given this job query issue some more thought and would like us to
discuss and hopefully soon agree on which way we go:


Variant A: deprecate job query methods (as suggested originally):
* upside: eventually we'll have a cleaner job API
* downside: users of the job query API need to find alternatives to
queries, individually


Variant B: allow disabling job queries (https://s.apache.org/68ys):
* upside: allows performance optimizations on a case-by-case basis
(optimizations include not requiring indexing), thereby promoting
query-less use cases going forward without API deprecation

nevertheless.

* downside: we stick to the current job API


Note that in both cases the 'org.apache.sling.event.jobs' export

version

will have to be updated from 2.0.1 to 2.1.0 - which will affect
users/customers that implement interfaces from that package (that's

not

something typical though, but there are a few exotic cases where

that's

the case).


At this stage I'm in favour of variant B as I don't see a good
alternative for job queries other than users re-implementing a fair
chunk of the sling event implementation themselves (which would sort

of

defeat the purpose, besides the fact that it would not be trivial as
there aren't enough hooks in the API for anyone other than the
implementor to do this consistently).


Cheers,
Stefan

On 17.12.18 16:08, Stefan Egli wrote:

We could introduce a config option which would allow a job queue to
opt-out of job queries voluntarily. That would allow the
implementation to treat those jobs differently (cheaper, without
indexing them).

I guess such a new opt-out of queries mechanism could be less
controversial and provide at least some short-term gain. It doesn't
answer the question how job queries should be replaced though..



--
Carsten Ziegeler
Adobe

Re: [DISCUSS] Deprecate query part of Sling Event API

2019-01-09 Thread Jason E Bailey

On Wed, Jan 9, 2019, at 3:05 AM, Stefan Egli wrote:
> The problem is two fold:
> 
> (a) having to support job queries makes messaging-based implementations 
> hard. You typically don't want to do queries against a messaging system. 
> So this is not only about the default resource-based implementation but 
> allowing alternatives better.

I don't support your logic. It's a poor design to perform queries via a 
messaging system, but you absolutely need to be able to query 'that which is 
doing the processing'  as to the state of the jobs.  This is almost moot with a 
resource based implementation because it's really easy to find that information 
out by looking at the resource tree. However if the goal is to implement it in 
another manner then you'll need a consistent interface to access that data.

If you're talking about doing a PDMS and you're looking at the Sling Event API 
as the model for message generation across distinct micro service 
implementations. I do agree that the API for the queries should be pulled out 
to a separate API, that makes sense since your doing a CQRS pattern. But you're 
replacing the methods not eliminating them.

> (b) in order to support queries in the existing resource-based 
> implementation we're using indexes already. So the query itself is not 
> expensive - but maintaining the index is a cost which you don't need to 
> do if there wouldn't be any query to support in the first place.

The problem is that your using oak queries to process data that is in a 
specific location.  That's not a good practice. Doing a JCR query to find 
disparate resources is useful when you have a large set. When you already know 
where the set of data is and your effectively using a query to filter through 
the nodes. You end up killing yourself.

I can modify the code this week to be as performant as you are currently 
getting with an index, without using an index, with less memory , eliminating 
the whole concern of maintaining indexes.

Re: [DISCUSS] Deprecate query part of Sling Event API

2019-01-09 Thread Daniel Klco

I would argue though that there is a significant loss of functionality by
eliminating the ability to see what jobs exist on an instance. What if
rather than eliminating the functionality entirely a new interface was
created for a "LocalJobManager" and the query based functionality moved
there?  This interface would only be supported for the resource-based
implementation and would allow for querying only the local instance (e.g.
it may not accurately reflect distributed jobs).

On another topic, what does everyone think of adding a method into the Job
interface for getting the entire ValueMap / java.util.Map of properties?
Right now it's very cumbersome to work with jobs via Expression Language.

On Wed, Jan 9, 2019 at 3:05 AM Stefan Egli  wrote:

> The problem is two fold:
>
> (a) having to support job queries makes messaging-based implementations
> hard. You typically don't want to do queries against a messaging system.
> So this is not only about the default resource-based implementation but
> allowing alternatives better.
>
> (b) in order to support queries in the existing resource-based
> implementation we're using indexes already. So the query itself is not
> expensive - but maintaining the index is a cost which you don't need to
> do if there wouldn't be any query to support in the first place.
>
> So it's two different aspects which both would benefit if there were no
> queries to support.
>
> With variant A we'd get rid of them long term, with variant B we're
> selectively getting rid of them on a case-by-case basis.
>
> Cheers,
> Stefan
>
> On 09.01.19 01:32, Daniel Klco wrote:
> > Yeah I must admit I'm confused as well, looking through the email threads
> > the original proposal is to return and a iterator rather than a
> collection.
> > If the problem is that too many jobs being returned causes heap issues, I
> > would think this would resolve that problem. Is there some other problem
> > here? If it is in query performance, could it possibly be solved using
> oak
> > indexes?
> >
> > On Tue, Jan 8, 2019, 3:50 PM Jason E Bailey  wrote:
> >
> >> So I'm missing something here, from what I gather so far, the methods
> that
> >> are being deprecated are to prevent a performance issue but the node
> >> structure that represents the jobs is in one place isn't it? How in the
> >> world are we getting a performance issue from that?
> >>
> >> Is there a use case to demonstrate the performance problem?
> >>
> >> --
> >> Jason
> >>
> >> On Tue, Jan 8, 2019, at 11:12 AM, Carsten Ziegeler wrote:
> >>> Hi,
> >>>
> >>> I agree, variant B sounds like the better option due to the reasons you
> >>> mention. It also provides a step by step way of moving a single type of
> >>> jobs to not use search anymore.
> >>>
> >>> The only downside is that this doesn't force anyone to think about her
> >>> job usage as everything just runs as before. Only if you want to
> improve
> >>> you can and adjust the configurations.
> >>>
> >>>
> >>> Regards
> >>>
> >>> Carsten
> >>>
> >>>
> >>> Stefan Egli wrote
>  Hi,
> 
>  I've given this job query issue some more thought and would like us to
>  discuss and hopefully soon agree on which way we go:
> 
> 
>  Variant A: deprecate job query methods (as suggested originally):
>  * upside: eventually we'll have a cleaner job API
>  * downside: users of the job query API need to find alternatives to
>  queries, individually
> 
> 
>  Variant B: allow disabling job queries (https://s.apache.org/68ys):
>  * upside: allows performance optimizations on a case-by-case basis
>  (optimizations include not requiring indexing), thereby promoting
>  query-less use cases going forward without API deprecation
> >> nevertheless.
>  * downside: we stick to the current job API
> 
> 
>  Note that in both cases the 'org.apache.sling.event.jobs' export
> >> version
>  will have to be updated from 2.0.1 to 2.1.0 - which will affect
>  users/customers that implement interfaces from that package (that's
> >> not
>  something typical though, but there are a few exotic cases where
> >> that's
>  the case).
> 
> 
>  At this stage I'm in favour of variant B as I don't see a good
>  alternative for job queries other than users re-implementing a fair
>  chunk of the sling event implementation themselves (which would sort
> >> of
>  defeat the purpose, besides the fact that it would not be trivial as
>  there aren't enough hooks in the API for anyone other than the
>  implementor to do this consistently).
> 
> 
>  Cheers,
>  Stefan
> 
>  On 17.12.18 16:08, Stefan Egli wrote:
> > We could introduce a config option which would allow a job queue to
> > opt-out of job queries voluntarily. That would allow the
> > implementation to treat those jobs differently (cheaper, without
> > indexing them).
> >
> > I guess such a new opt-out of queries

[jira] [Assigned] (SLING-8205) Stop using Class.getField() in order to avoid throwing NoSuchFieldException



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

Radu Cotescu reassigned SLING-8205:
---

Assignee: Radu Cotescu  (was: Nicolas Peltier)

> Stop using Class.getField() in order to avoid throwing NoSuchFieldException
> ---
>
> Key: SLING-8205
> URL: https://issues.apache.org/jira/browse/SLING-8205
> Project: Sling
>  Issue Type: Improvement
>  Components: Scripting
>Affects Versions: Scripting HTL Runtime 1.0.0-1.4.0
>Reporter: Nicolas Peltier
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: Scripting HTL Runtime 1.0.2-1.4.0
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> According to java mission control, exceptions are bad for performances, and 
> o.a.s.scripting.sightly.compiler.util.ObjectModel uses Class.getField first 
> to check if a use member is a simple field or a method, which generates 
> *lots* of exceptions.
> Switching to simple lookup through getFields (that looks also to super 
> classes fields) _looks_ quicker (this of course would need to be thoroughly 
> tested)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (SLING-8205) Stop using Class.getField() in order to avoid throwing NoSuchFieldException



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

Radu Cotescu updated SLING-8205:

Fix Version/s: Scripting HTL Runtime 1.0.2-1.4.0

> Stop using Class.getField() in order to avoid throwing NoSuchFieldException
> ---
>
> Key: SLING-8205
> URL: https://issues.apache.org/jira/browse/SLING-8205
> Project: Sling
>  Issue Type: Improvement
>  Components: Scripting
>Affects Versions: Scripting HTL Runtime 1.0.0-1.4.0
>Reporter: Nicolas Peltier
>Assignee: Nicolas Peltier
>Priority: Major
> Fix For: Scripting HTL Runtime 1.0.2-1.4.0
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> According to java mission control, exceptions are bad for performances, and 
> o.a.s.scripting.sightly.compiler.util.ObjectModel uses Class.getField first 
> to check if a use member is a simple field or a method, which generates 
> *lots* of exceptions.
> Switching to simple lookup through getFields (that looks also to super 
> classes fields) _looks_ quicker (this of course would need to be thoroughly 
> tested)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (SLING-8205) Stop using Class.getField() in order to avoid throwing NoSuchFieldException



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

Radu Cotescu resolved SLING-8205.
-
Resolution: Fixed

> Stop using Class.getField() in order to avoid throwing NoSuchFieldException
> ---
>
> Key: SLING-8205
> URL: https://issues.apache.org/jira/browse/SLING-8205
> Project: Sling
>  Issue Type: Improvement
>  Components: Scripting
>Affects Versions: Scripting HTL Runtime 1.0.0-1.4.0
>Reporter: Nicolas Peltier
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: Scripting HTL Runtime 1.0.2-1.4.0
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> According to java mission control, exceptions are bad for performances, and 
> o.a.s.scripting.sightly.compiler.util.ObjectModel uses Class.getField first 
> to check if a use member is a simple field or a method, which generates 
> *lots* of exceptions.
> Switching to simple lookup through getFields (that looks also to super 
> classes fields) _looks_ quicker (this of course would need to be thoroughly 
> tested)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (SLING-8205) Stop using Class.getField() in order to avoid throwing NoSuchFieldException



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

Radu Cotescu updated SLING-8205:

Affects Version/s: Scripting HTL Runtime 1.0.0-1.4.0

> Stop using Class.getField() in order to avoid throwing NoSuchFieldException
> ---
>
> Key: SLING-8205
> URL: https://issues.apache.org/jira/browse/SLING-8205
> Project: Sling
>  Issue Type: Improvement
>  Components: Scripting
>Affects Versions: Scripting HTL Runtime 1.0.0-1.4.0
>Reporter: Nicolas Peltier
>Assignee: Nicolas Peltier
>Priority: Major
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> According to java mission control, exceptions are bad for performances, and 
> o.a.s.scripting.sightly.compiler.util.ObjectModel uses Class.getField first 
> to check if a use member is a simple field or a method, which generates 
> *lots* of exceptions.
> Switching to simple lookup through getFields (that looks also to super 
> classes fields) _looks_ quicker (this of course would need to be thoroughly 
> tested)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [VOTE] Release Apache Sling Servlets Post 2.3.28

2019-01-09 Thread Radu Cotescu

+1

> On 9 Jan 2019, at 11:30, Radu Cotescu  wrote:
> 
> Please vote to approve this release:
> 
>   [ ] +1 Approve the release
>   [ ]  0 Don't care
>   [ ] -1 Don't release, because ...
> 
> This majority vote is open for at least 72 hours.
>

[jira] [Commented] (SLING-8186) Moved node is deleted if @Delete parameter points to its name



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

Burkhard Pauli commented on SLING-8186:
---

I don't see a name collision problem in the provided example. The file resource 
is located at {{/content/file}} and the delete operation is against the 
resource {{/content/test}}. In the provided curl command the file should be 
moved from {{/content/file}} to {{/content/test/file}}. This done with the 
relative path {{./test}} against the target url 
{{http://localhost:4502/content}}. Maybe the example is a bit misleading by 
mixing relative and absolute path parameters - sorry for that.  

Changing the order of the operation will not change the behaviour of delete 
operation itself.

> Moved node is deleted if @Delete parameter points to its name
> -
>
> Key: SLING-8186
> URL: https://issues.apache.org/jira/browse/SLING-8186
> Project: Sling
>  Issue Type: Bug
>  Components: Servlets
>Affects Versions: Servlets Post 2.3.26
>Reporter: Burkhard Pauli
>Assignee: Bertrand Delacretaz
>Priority: Major
> Attachments: patch.diff
>
>
> If a file is moved to a new location with the @MoveFrom parameter and the 
> request contains the @Delete parameter at the same time, the file is dropped 
> and never saved to the new location.
> Step to reproduce the issue:
>  # Create a node of type nt:file at the location {{/content/file}}
>  # Execute the following curl command:
>  {{curl -u admin:admin -F './test/title=Hello World' -F 
> './test/file@MoveFrom=/content/file' -F './test@Delete=true' 
> [http://localhost:4502/content]}}
> Observed behaviour:
>  The file is not saved at the new location at {{/content/test/file}} and it 
> is not available anymore at the old location {{/content/file}}
> Expected:
>  The file is saved at the new location {{/content/test/file}} as long as 
> other properties are saved when the request contains the delete operation 
> (like the title property in the example above).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (SLING-8186) Moved node is deleted if @Delete parameter points to its name



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

Burkhard Pauli edited comment on SLING-8186 at 1/9/19 11:20 AM:


I don't see a name collision problem in the provided example. The file resource 
is located at {{/content/file}} and the delete operation is against the 
resource {{/content/test}}. In the provided curl command the file should be 
moved from {{/content/file}} to {{/content/test/file}}. This is done with the 
relative path {{./test}} against the target url 
{{http://localhost:4502/content}}. Maybe the example is a bit misleading by 
mixing relative and absolute path parameters - sorry for that.  

Changing the order of the operation will not change the behaviour of delete 
operation itself.


was (Author: bupauli):
I don't see a name collision problem in the provided example. The file resource 
is located at {{/content/file}} and the delete operation is against the 
resource {{/content/test}}. In the provided curl command the file should be 
moved from {{/content/file}} to {{/content/test/file}}. This done with the 
relative path {{./test}} against the target url 
{{http://localhost:4502/content}}. Maybe the example is a bit misleading by 
mixing relative and absolute path parameters - sorry for that.  

Changing the order of the operation will not change the behaviour of delete 
operation itself.

> Moved node is deleted if @Delete parameter points to its name
> -
>
> Key: SLING-8186
> URL: https://issues.apache.org/jira/browse/SLING-8186
> Project: Sling
>  Issue Type: Bug
>  Components: Servlets
>Affects Versions: Servlets Post 2.3.26
>Reporter: Burkhard Pauli
>Assignee: Bertrand Delacretaz
>Priority: Major
> Attachments: patch.diff
>
>
> If a file is moved to a new location with the @MoveFrom parameter and the 
> request contains the @Delete parameter at the same time, the file is dropped 
> and never saved to the new location.
> Step to reproduce the issue:
>  # Create a node of type nt:file at the location {{/content/file}}
>  # Execute the following curl command:
>  {{curl -u admin:admin -F './test/title=Hello World' -F 
> './test/file@MoveFrom=/content/file' -F './test@Delete=true' 
> [http://localhost:4502/content]}}
> Observed behaviour:
>  The file is not saved at the new location at {{/content/test/file}} and it 
> is not available anymore at the old location {{/content/file}}
> Expected:
>  The file is saved at the new location {{/content/test/file}} as long as 
> other properties are saved when the request contains the delete operation 
> (like the title property in the example above).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SLING-8186) Moved node is deleted if @Delete parameter points to its name

2019-01-09 Thread Bertrand Delacretaz (JIRA)



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

Bertrand Delacretaz commented on SLING-8186:


Don't you think we would have the same name collision problem if we change the 
order of operations?

@Delete tries to delete a property but if it doesn't find it it deletes a 
Resource with that name under the current parent node if found.

So changing the order of operations would solve your use case but might break 
others.

But maybe I'm missing something?

> Moved node is deleted if @Delete parameter points to its name
> -
>
> Key: SLING-8186
> URL: https://issues.apache.org/jira/browse/SLING-8186
> Project: Sling
>  Issue Type: Bug
>  Components: Servlets
>Affects Versions: Servlets Post 2.3.26
>Reporter: Burkhard Pauli
>Assignee: Bertrand Delacretaz
>Priority: Major
> Attachments: patch.diff
>
>
> If a file is moved to a new location with the @MoveFrom parameter and the 
> request contains the @Delete parameter at the same time, the file is dropped 
> and never saved to the new location.
> Step to reproduce the issue:
>  # Create a node of type nt:file at the location {{/content/file}}
>  # Execute the following curl command:
>  {{curl -u admin:admin -F './test/title=Hello World' -F 
> './test/file@MoveFrom=/content/file' -F './test@Delete=true' 
> [http://localhost:4502/content]}}
> Observed behaviour:
>  The file is not saved at the new location at {{/content/test/file}} and it 
> is not available anymore at the old location {{/content/file}}
> Expected:
>  The file is saved at the new location {{/content/test/file}} as long as 
> other properties are saved when the request contains the delete operation 
> (like the title property in the example above).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (SLING-8205) Stop using Class.getField() in order to avoid throwing NoSuchFieldException



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

Radu Cotescu updated SLING-8205:

Summary: Stop using Class.getField() in order to avoid throwing 
NoSuchFieldException  (was: stop using Class.getField() to stop spitting out 
NoSuchFieldException)

> Stop using Class.getField() in order to avoid throwing NoSuchFieldException
> ---
>
> Key: SLING-8205
> URL: https://issues.apache.org/jira/browse/SLING-8205
> Project: Sling
>  Issue Type: Improvement
>  Components: Scripting
>Reporter: Nicolas Peltier
>Assignee: Nicolas Peltier
>Priority: Major
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> According to java mission control, exceptions are bad for performances, and 
> o.a.s.scripting.sightly.compiler.util.ObjectModel uses Class.getField first 
> to check if a use member is a simple field or a method, which generates 
> *lots* of exceptions.
> Switching to simple lookup through getFields (that looks also to super 
> classes fields) _looks_ quicker (this of course would need to be thoroughly 
> tested)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (SLING-7756) Improve logging for Job retries

2019-01-09 Thread Konrad Windszus (JIRA)



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

Konrad Windszus reassigned SLING-7756:
--

Assignee: Konrad Windszus

> Improve logging for Job retries
> ---
>
> Key: SLING-7756
> URL: https://issues.apache.org/jira/browse/SLING-7756
> Project: Sling
>  Issue Type: Improvement
>  Components: Event
>Affects Versions: Event 4.2.10
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Currently a {{JobConsumer}} returning {{JobResult.FAILED}} is usually retried 
> (https://sling.apache.org/documentation/bundles/apache-sling-eventing-and-job-handling.html).
>  Unfortunately this is not exposed in the logs, so in case a JobConsumer logs 
> an error before returning {{JobResult.FAILED}} the job is silently retried 
> without any particular log message. I think each failed job should lead to a 
> WARN in the log (in case the job is retried) with the attempt number and 
> outstanding attempts in the log message. In case a job is not retried, an 
> ERROR should be emitted to the log for every failed job.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] bosschaert closed pull request #11: SLING-8113 - defining file in registryhome to capture executionplan s…

bosschaert closed pull request #11: SLING-8113 - defining file in registryhome 
to capture executionplan s…
URL: 
https://github.com/apache/sling-org-apache-sling-feature-extension-content/pull/11
 
 
   

This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:

As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):

diff --git 
a/src/main/java/org/apache/sling/feature/extension/content/ContentHandler.java 
b/src/main/java/org/apache/sling/feature/extension/content/ContentHandler.java
index ddc7682..673d626 100644
--- 
a/src/main/java/org/apache/sling/feature/extension/content/ContentHandler.java
+++ 
b/src/main/java/org/apache/sling/feature/extension/content/ContentHandler.java
@@ -44,8 +44,6 @@
 public class ContentHandler implements ExtensionHandler {
 public static final String PACKAGEREGISTRY_HOME = "packageregistry.home";
 
-private static final char FACTORY_CONFIG_SEPARATOR = '~';
-
 private static final String REPOSITORY_HOME = "repository.home";
 
 private static final String REGISTRY_FOLDER = "packageregistry";
@@ -121,6 +119,7 @@ public boolean handle(Extension extension, 
LauncherPrepareContext prepareContext
 // Workaround for too bold relocation mechanism - corresponding 
details at https://issues.apache.org/jira/browse/MSHADE-156
 final Configuration initcfg = new 
Configuration("org.UNSHADE.apache.sling.jcr.packageinit.impl.ExecutionPlanRepoInitializer");
 initcfg.getProperties().put("executionplans", 
executionPlans.toArray(new String[executionPlans.size()]));
+initcfg.getProperties().put("statusfilepath", 
registryHome.getAbsolutePath() + "/executedplans.file");
 installationContext.addConfiguration(initcfg.getPid(), null, 
initcfg.getProperties());
 // Workaround for too bold relocation mechanism - corresponding 
details at https://issues.apache.org/jira/browse/MSHADE-156
 final Configuration registrycfg = new 
Configuration("org.UNSHADE.apache.jackrabbit.vault.packaging.registry.impl.FSPackageRegistry");
diff --git 
a/src/test/java/org/apache/sling/feature/extension/content/ContentHandlerTest.java
 
b/src/test/java/org/apache/sling/feature/extension/content/ContentHandlerTest.java
index 662dfb7..5721457 100644
--- 
a/src/test/java/org/apache/sling/feature/extension/content/ContentHandlerTest.java
+++ 
b/src/test/java/org/apache/sling/feature/extension/content/ContentHandlerTest.java
@@ -108,7 +108,11 @@ public void testMultipleStartOrders() throws Exception {
 
verify(installationContext).addConfiguration(eq("org.UNSHADE.apache.sling.jcr.packageinit.impl.ExecutionPlanRepoInitializer"),
 any(), executionPlanCaptor.capture());
 
verify(installationContext).addConfiguration(eq("org.UNSHADE.apache.jackrabbit.vault.packaging.registry.impl.FSPackageRegistry"),
 any(), any());
 Iterator> dictIt = 
executionPlanCaptor.getAllValues().iterator();
-final String[] executionplans = (String[]) 
dictIt.next().get("executionplans");
+Dictionary dict = dictIt.next();
+final String[] executionplans = (String[]) dict.get("executionplans");
+final String statusFileHome = (String)dict.get("statusfilepath");
+File executedPlansFile = new File(testFolder.getRoot(), 
"executedplans.file");
+assertEquals(executedPlansFile.getAbsolutePath(), statusFileHome);
 final String expected_0 =
 "\n" +
 "\n" +


 


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[jira] [Comment Edited] (SLING-8186) Moved node is deleted if @Delete parameter points to its name



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

Burkhard Pauli edited comment on SLING-8186 at 1/9/19 10:29 AM:


[~bdelacretaz], Thank you for having a look into this issue! I think in this 
edge case the question is if we can reorder the modify operations like in the 
attached  [^patch.diff] , so that the move and copy operation is done after the 
delete. Otherwise the delete will remove the copied or moved file right after 
in the same request. 

Sure, this will change the old (undocumented) behaviour but I can't imagine use 
cases where the old behaviour is intended because the move operation will 
delete the resource anyway and the motivation to copy a resource is to keep the 
source resource. Otherwise the move operation should be used. Or do I miss 
something? 

cc [~cziegeler]


was (Author: bupauli):
[~bdelacretaz], Thank you for having a look into this issue! I think in this 
edge case the question is if we can reorder the modify operations like in the 
attached  [^patch.diff] , so that the move and copy operation is done after the 
delete. Otherwise the delete will remove the copied or moved file right after 
in the same request. 

Sure, this will change the old (undocumented) behaviour but I can't imagine use 
cases where the old behaviour is intended because the move operation will 
delete the resource anyway and the motivation to copy a resource is to keep the 
old example. Otherwise the move operation should be used. Or do I miss 
something? 

cc [~cziegeler]

> Moved node is deleted if @Delete parameter points to its name
> -
>
> Key: SLING-8186
> URL: https://issues.apache.org/jira/browse/SLING-8186
> Project: Sling
>  Issue Type: Bug
>  Components: Servlets
>Affects Versions: Servlets Post 2.3.26
>Reporter: Burkhard Pauli
>Assignee: Bertrand Delacretaz
>Priority: Major
> Attachments: patch.diff
>
>
> If a file is moved to a new location with the @MoveFrom parameter and the 
> request contains the @Delete parameter at the same time, the file is dropped 
> and never saved to the new location.
> Step to reproduce the issue:
>  # Create a node of type nt:file at the location {{/content/file}}
>  # Execute the following curl command:
>  {{curl -u admin:admin -F './test/title=Hello World' -F 
> './test/file@MoveFrom=/content/file' -F './test@Delete=true' 
> [http://localhost:4502/content]}}
> Observed behaviour:
>  The file is not saved at the new location at {{/content/test/file}} and it 
> is not available anymore at the old location {{/content/file}}
> Expected:
>  The file is saved at the new location {{/content/test/file}} as long as 
> other properties are saved when the request contains the delete operation 
> (like the title property in the example above).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SLING-8186) Moved node is deleted if @Delete parameter points to its name



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

Burkhard Pauli commented on SLING-8186:
---

[~bdelacretaz], Thank you for having a look into this issue! I think in this 
edge case the question is if we can reorder the modify operations like in the 
attached  [^patch.diff] , so that the move and copy operation is done after the 
delete. Otherwise the delete will remove the copied or moved file right after 
in the same request. 

Sure, this will change the old (undocumented) behaviour but I can't imagine use 
cases where the old behaviour is intended because the move operation will 
delete the resource anyway and the motivation to copy a resource is to keep the 
old example. Otherwise the move operation should be used. Or do I miss 
something? 

cc [~cziegeler]

> Moved node is deleted if @Delete parameter points to its name
> -
>
> Key: SLING-8186
> URL: https://issues.apache.org/jira/browse/SLING-8186
> Project: Sling
>  Issue Type: Bug
>  Components: Servlets
>Affects Versions: Servlets Post 2.3.26
>Reporter: Burkhard Pauli
>Assignee: Bertrand Delacretaz
>Priority: Major
> Attachments: patch.diff
>
>
> If a file is moved to a new location with the @MoveFrom parameter and the 
> request contains the @Delete parameter at the same time, the file is dropped 
> and never saved to the new location.
> Step to reproduce the issue:
>  # Create a node of type nt:file at the location {{/content/file}}
>  # Execute the following curl command:
>  {{curl -u admin:admin -F './test/title=Hello World' -F 
> './test/file@MoveFrom=/content/file' -F './test@Delete=true' 
> [http://localhost:4502/content]}}
> Observed behaviour:
>  The file is not saved at the new location at {{/content/test/file}} and it 
> is not available anymore at the old location {{/content/file}}
> Expected:
>  The file is saved at the new location {{/content/test/file}} as long as 
> other properties are saved when the request contains the delete operation 
> (like the title property in the example above).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (SLING-8186) Moved node is deleted if @Delete parameter points to its name



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

Burkhard Pauli updated SLING-8186:
--
Attachment: patch.diff

> Moved node is deleted if @Delete parameter points to its name
> -
>
> Key: SLING-8186
> URL: https://issues.apache.org/jira/browse/SLING-8186
> Project: Sling
>  Issue Type: Bug
>  Components: Servlets
>Affects Versions: Servlets Post 2.3.26
>Reporter: Burkhard Pauli
>Assignee: Bertrand Delacretaz
>Priority: Major
> Attachments: patch.diff
>
>
> If a file is moved to a new location with the @MoveFrom parameter and the 
> request contains the @Delete parameter at the same time, the file is dropped 
> and never saved to the new location.
> Step to reproduce the issue:
>  # Create a node of type nt:file at the location {{/content/file}}
>  # Execute the following curl command:
>  {{curl -u admin:admin -F './test/title=Hello World' -F 
> './test/file@MoveFrom=/content/file' -F './test@Delete=true' 
> [http://localhost:4502/content]}}
> Observed behaviour:
>  The file is not saved at the new location at {{/content/test/file}} and it 
> is not available anymore at the old location {{/content/file}}
> Expected:
>  The file is saved at the new location {{/content/test/file}} as long as 
> other properties are saved when the request contains the delete operation 
> (like the title property in the example above).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (SLING-8205) stop using Class.getField() to stop spitting out NoSuchFieldException



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

Nicolas Peltier edited comment on SLING-8205 at 1/9/19 9:58 AM:


[~radu.cotescu] raised the PR 
https://github.com/apache/sling-org-apache-sling-scripting-sightly-compiler/pull/4


was (Author: npeltier):
raised the PR 
https://github.com/apache/sling-org-apache-sling-scripting-sightly-compiler/pull/4

> stop using Class.getField() to stop spitting out NoSuchFieldException
> -
>
> Key: SLING-8205
> URL: https://issues.apache.org/jira/browse/SLING-8205
> Project: Sling
>  Issue Type: Improvement
>  Components: Scripting
>Reporter: Nicolas Peltier
>Assignee: Nicolas Peltier
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> According to java mission control, exceptions are bad for performances, and 
> o.a.s.scripting.sightly.compiler.util.ObjectModel uses Class.getField first 
> to check if a use member is a simple field or a method, which generates 
> *lots* of exceptions.
> Switching to simple lookup through getFields (that looks also to super 
> classes fields) _looks_ quicker (this of course would need to be thoroughly 
> tested)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SLING-8205) stop using Class.getField() to stop spitting out NoSuchFieldException



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

Nicolas Peltier commented on SLING-8205:


raised the PR 
https://github.com/apache/sling-org-apache-sling-scripting-sightly-compiler/pull/4

> stop using Class.getField() to stop spitting out NoSuchFieldException
> -
>
> Key: SLING-8205
> URL: https://issues.apache.org/jira/browse/SLING-8205
> Project: Sling
>  Issue Type: Improvement
>  Components: Scripting
>Reporter: Nicolas Peltier
>Assignee: Nicolas Peltier
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> According to java mission control, exceptions are bad for performances, and 
> o.a.s.scripting.sightly.compiler.util.ObjectModel uses Class.getField first 
> to check if a use member is a simple field or a method, which generates 
> *lots* of exceptions.
> Switching to simple lookup through getFields (that looks also to super 
> classes fields) _looks_ quicker (this of course would need to be thoroughly 
> tested)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [VOTE] Release Apache Sling Servlets Post 2.3.28

2019-01-09 Thread Carsten Ziegeler


+1


Carsten


Radu Cotescu wrote

Hi,

We solved 1 issue in this release:
https://issues.apache.org/jira/projects/SLING/versions/12344817 


Staging repository:
https://repository.apache.org/content/repositories/orgapachesling-2034 


You can use this UNIX script to download the release and verify the signatures:
https://github.com/apache/sling-tooling-release/blob/master/check_staged_release.sh 


Usage:
curl 
https://raw.githubusercontent.com/apache/sling-tooling-release/master/check_staged_release.sh
 | bash -s 2034

Please vote to approve this release:

   [ ] +1 Approve the release
   [ ]  0 Don't care
   [ ] -1 Don't release, because ...

This majority vote is open for at least 72 hours.

Cheers,
Radu


--
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

RE: [VOTE] Release Apache Sling Servlets Post 2.3.28

2019-01-09 Thread Stefan Seifert

+1

RE: [VOTE] Release Apache Sling Tenant 1.1.4

2019-01-09 Thread Stefan Seifert

+1

[GitHub] bosschaert commented on issue #11: SLING-8113 - defining file in registryhome to capture executionplan s…

bosschaert commented on issue #11: SLING-8113 - defining file in registryhome 
to capture executionplan s…
URL: 
https://github.com/apache/sling-org-apache-sling-feature-extension-content/pull/11#issuecomment-452632007
 
 
   LGTM


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[VOTE] Release Apache Sling Servlets Post 2.3.28

2019-01-09 Thread Radu Cotescu

Hi,

We solved 1 issue in this release:
https://issues.apache.org/jira/projects/SLING/versions/12344817 


Staging repository:
https://repository.apache.org/content/repositories/orgapachesling-2034 


You can use this UNIX script to download the release and verify the signatures:
https://github.com/apache/sling-tooling-release/blob/master/check_staged_release.sh
 


Usage:
curl 
https://raw.githubusercontent.com/apache/sling-tooling-release/master/check_staged_release.sh
 | bash -s 2034

Please vote to approve this release:

  [ ] +1 Approve the release
  [ ]  0 Don't care
  [ ] -1 Don't release, because ...

This majority vote is open for at least 72 hours.

Cheers,
Radu

[GitHub] DominikSuess opened a new pull request #11: SLING-8113 - defining file in registryhome to capture executionplan s…

DominikSuess opened a new pull request #11: SLING-8113 - defining file in 
registryhome to capture executionplan s…
URL: 
https://github.com/apache/sling-org-apache-sling-feature-extension-content/pull/11
 
 
   …tatus.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] DominikSuess closed pull request #10: SLING-8113 - defining file in registryhome to capture executionplan s…

DominikSuess closed pull request #10: SLING-8113 - defining file in 
registryhome to capture executionplan s…
URL: 
https://github.com/apache/sling-org-apache-sling-feature-extension-content/pull/10
 
 
   

This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:

As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):

diff --git 
a/src/main/java/org/apache/sling/feature/extension/content/ContentHandler.java 
b/src/main/java/org/apache/sling/feature/extension/content/ContentHandler.java
index dd94747..8d4c494 100644
--- 
a/src/main/java/org/apache/sling/feature/extension/content/ContentHandler.java
+++ 
b/src/main/java/org/apache/sling/feature/extension/content/ContentHandler.java
@@ -122,6 +122,7 @@ public boolean handle(Extension extension, 
LauncherPrepareContext prepareContext
 // Workaround for too bold relocation mechanism - corresponding 
details at https://issues.apache.org/jira/browse/MSHADE-156 
 final Configuration initcfg = new 
Configuration("org.UNSHADE.apache.sling.jcr.packageinit.impl.ExecutionPlanRepoInitializer");
 initcfg.getProperties().put("executionplans", 
executionPlans.toArray(new String[executionPlans.size()]));
+initcfg.getProperties().put("statusfilepath", 
registryHome.getAbsolutePath() + "/executedplans.file");
 installationContext.addConfiguration(initcfg.getPid(), 
initcfg.getFactoryPid(), initcfg.getProperties());
  // Workaround for too bold relocation mechanism - corresponding 
details at https://issues.apache.org/jira/browse/MSHADE-156 
 final Configuration registrycfg = new 
Configuration("org.UNSHADE.apache.jackrabbit.vault.packaging.registry.impl.FSPackageRegistry");
diff --git 
a/src/test/java/org/apache/sling/feature/extension/content/ContentHandlerTest.java
 
b/src/test/java/org/apache/sling/feature/extension/content/ContentHandlerTest.java
index 06b7cff..a78457a 100644
--- 
a/src/test/java/org/apache/sling/feature/extension/content/ContentHandlerTest.java
+++ 
b/src/test/java/org/apache/sling/feature/extension/content/ContentHandlerTest.java
@@ -108,7 +108,11 @@ public void testMultipleStartOrders() throws Exception {
 
verify(installationContext).addConfiguration(eq("org.UNSHADE.apache.sling.jcr.packageinit.impl.ExecutionPlanRepoInitializer"),
 any(), executionPlanCaptor.capture());
 
verify(installationContext).addConfiguration(eq("org.UNSHADE.apache.jackrabbit.vault.packaging.registry.impl.FSPackageRegistry"),
 any(), any());
 Iterator> dictIt = 
executionPlanCaptor.getAllValues().iterator();
-final String[] executionplans = (String[]) 
dictIt.next().get("executionplans");
+Dictionary dict = dictIt.next();
+final String[] executionplans = (String[]) dict.get("executionplans");
+final String statusFileHome = (String)dict.get("statusfilepath");
+File executedPlansFile = new File(testFolder.getRoot(), 
"executedplans.file");
+assertEquals(executedPlansFile.getAbsolutePath(), statusFileHome);
 final String expected_0 =
 "\n" +
 "\n" +


 


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[jira] [Closed] (SLING-7648) Sling Post Servlet Throws NullPointerException On :order Last



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

Radu Cotescu closed SLING-7648.
---

> Sling Post Servlet Throws NullPointerException On :order Last
> -
>
> Key: SLING-7648
> URL: https://issues.apache.org/jira/browse/SLING-7648
> Project: Sling
>  Issue Type: Improvement
>Affects Versions: Servlets Post 2.3.24
>Reporter: Dan Klco
>Assignee: Dan Klco
>Priority: Major
> Fix For: Servlets Post 2.3.26
>
> Attachments: nullpointer.log
>
>
> When using the SlingPostServlet to reorder a resource to the last position 
> (either by the "last" string or index) among it's siblings the request throws 
> a NullPointerException when the JSONResponse attempts to build the response. 
> This seems to be due to an unexpected null argument.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (SLING-2534) Strings of zero length on update in post servlet delete the property



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

Radu Cotescu updated SLING-2534:

Fix Version/s: (was: Servlets Post 2.3.26)
   Servlets Post 2.3.28

> Strings of zero length on update in post servlet delete the property
> 
>
> Key: SLING-2534
> URL: https://issues.apache.org/jira/browse/SLING-2534
> Project: Sling
>  Issue Type: Bug
>  Components: Servlets
>Affects Versions: Servlets Post 2.1.2
>Reporter: Endolf
>Assignee: Carsten Ziegeler
>Priority: Major
> Fix For: Servlets Post 2.3.28
>
> Attachments: SLING-2534-diff.txt, blankstrings.patch
>
>
> According to JCR specs, for string type properties, a blank string should be 
> a valid value. Currently the post servlet delets any property where 1 or less 
> values are specifed and the 1 value has a 0 length. I think string properties 
> with a zero length should be blanked instead of deleted.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [VOTE] Release Apache Sling Tenant 1.1.4

2019-01-09 Thread Carsten Ziegeler


+1


Carsten


Robert Munteanu wrote

Hi,

We solved 1 issue in this release:
https://issues.apache.org/jira/browse/SLING/fixforversion/12343999

Staging repository:
https://repository.apache.org/content/repositories/orgapachesling-2033

You can use this UNIX script to download the release and verify the
signatures:
https://gitbox.apache.org/repos/asf?p=sling-tooling-release.git;a=blob;f=check_staged_release.sh;hb=HEAD

Usage:
sh check_staged_release.sh 2033 /tmp/sling-staging

Please vote to approve this release:

   [ ] +1 Approve the release
   [ ]  0 Don't care
   [ ] -1 Don't release, because ...

This majority vote is open for at least 72 hours.

Thanks,

Robert


--
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

[jira] [Assigned] (SLING-8205) stop using Class.getField() to stop spitting out NoSuchFieldException



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

Nicolas Peltier reassigned SLING-8205:
--

Assignee: Nicolas Peltier

> stop using Class.getField() to stop spitting out NoSuchFieldException
> -
>
> Key: SLING-8205
> URL: https://issues.apache.org/jira/browse/SLING-8205
> Project: Sling
>  Issue Type: Improvement
>  Components: Scripting
>Reporter: Nicolas Peltier
>Assignee: Nicolas Peltier
>Priority: Major
>
> According to java mission control, exceptions are bad for performances, and 
> o.a.s.scripting.sightly.compiler.util.ObjectModel uses Class.getField first 
> to check if a use member is a simple field or a method, which generates 
> *lots* of exceptions.
> Switching to simple lookup through getFields (that looks also to super 
> classes fields) _looks_ quicker (this of course would need to be thoroughly 
> tested)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SLING-8205) stop using Class.getField() to stop spitting out NoSuchFieldException



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

Nicolas Peltier commented on SLING-8205:


cc [~radu.cotescu] did some tests as follow: on a blank adobe experience 
manager 6.4 (using compiler 1.0.20-1.3.1) hit 1000 times the sample page 
/content/we-retail/us/en/men.html with apache benchmark and 10 concurrent users 
(which is {{ab -n 1000 -c 10 -A admin:admin 
http://localhost:4502/content/we-retail/us/en/men.html\?wcmmode\=disabled}}). 
1.13 M NoSuchFieldExceptions are spit. 0 with the fix i'll PR.
Moreover, the time taken (after "heating" the instance by running several times 
this test) i get 
With NSFE 
{Code}
Server Hostname:localhost
Server Port:4502

Document Path:  /content/we-retail/us/en/men.html?wcmmode=disabled
Document Length:65759 bytes

Concurrency Level:  10
Time taken for tests:   28.536 seconds
Complete requests:  1000
Failed requests:0
Total transferred:  65887000 bytes
HTML transferred:   65759000 bytes
Requests per second:35.04 [#/sec] (mean)
Time per request:   285.360 [ms] (mean)
Time per request:   28.536 [ms] (mean, across all concurrent requests)
Transfer rate:  2254.79 [Kbytes/sec] received

Connection Times (ms)
  min  mean[+/-sd] median   max
Connect:00   0.1  0   1
Processing:   117  283  45.5277 573
Waiting:  106  262  42.7256 553
Total:117  284  45.5277 573

Percentage of the requests served within a certain time (ms)
  50%277
  66%295
  75%306
  80%317
  90%342
  95%367
  98%394
  99%417
 100%573 (longest request)
{Code}
and without:
{Code}
Server Hostname:localhost
Server Port:4502

Document Path:  /content/we-retail/us/en/men.html?wcmmode=disabled
Document Length:65759 bytes

Concurrency Level:  10
Time taken for tests:   21.382 seconds
Complete requests:  1000
Failed requests:0
Total transferred:  65887000 bytes
HTML transferred:   65759000 bytes
Requests per second:46.77 [#/sec] (mean)
Time per request:   213.825 [ms] (mean)
Time per request:   21.382 [ms] (mean, across all concurrent requests)
Transfer rate:  3009.14 [Kbytes/sec] received

Connection Times (ms)
  min  mean[+/-sd] median   max
Connect:00   0.1  0   3
Processing:   101  212  37.4206 438
Waiting:   86  188  33.8182 407
Total:101  212  37.4206 438

Percentage of the requests served within a certain time (ms)
  50%206
  66%223
  75%235
  80%242
  90%262
  95%279
  98%298
  99%338
 100%438 (longest request)
{Code}

> stop using Class.getField() to stop spitting out NoSuchFieldException
> -
>
> Key: SLING-8205
> URL: https://issues.apache.org/jira/browse/SLING-8205
> Project: Sling
>  Issue Type: Improvement
>  Components: Scripting
>Reporter: Nicolas Peltier
>Assignee: Nicolas Peltier
>Priority: Major
>
> According to java mission control, exceptions are bad for performances, and 
> o.a.s.scripting.sightly.compiler.util.ObjectModel uses Class.getField first 
> to check if a use member is a simple field or a method, which generates 
> *lots* of exceptions.
> Switching to simple lookup through getFields (that looks also to super 
> classes fields) _looks_ quicker (this of course would need to be thoroughly 
> tested)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [VOTE] Release Apache Sling Tenant 1.1.4

2019-01-09 Thread Robert Munteanu

On Wed, 2019-01-09 at 09:56 +0100, Robert Munteanu wrote:
> Please vote to approve this release:

+1

Robert


signature.asc
Description: This is a digitally signed message part

[VOTE] Release Apache Sling Tenant 1.1.4

2019-01-09 Thread Robert Munteanu

Hi,

We solved 1 issue in this release:
https://issues.apache.org/jira/browse/SLING/fixforversion/12343999

Staging repository:
https://repository.apache.org/content/repositories/orgapachesling-2033

You can use this UNIX script to download the release and verify the
signatures:
https://gitbox.apache.org/repos/asf?p=sling-tooling-release.git;a=blob;f=check_staged_release.sh;hb=HEAD

Usage:
sh check_staged_release.sh 2033 /tmp/sling-staging

Please vote to approve this release:

  [ ] +1 Approve the release
  [ ]  0 Don't care
  [ ] -1 Don't release, because ...

This majority vote is open for at least 72 hours.

Thanks,

Robert

Re: [RESULT] [VOTE] Release Apache Sling Tenant 1.1.2

2019-01-09 Thread Robert Munteanu

On Fri, 2019-01-04 at 08:18 -0800, Andreas Schaefer wrote:
> In an Adobe AEM beta build Tenant 1.1.2 was used and it fails to
> deploy its services as it is missing the OSGI-INF folder. The current
> master (1.1.1-SNAPHOST ??) is just doing fine.

For the record, this was reported and fixed with 
https://issues.apache.org/jira/browse/SLING-8197 .

Robert

Re: [DISCUSS] Deprecate query part of Sling Event API