from:"Konrad Windszus"

content-package-maven-plugin and tooling around it

2013-10-29 Thread Konrad Windszus

Hi,

unfortunately right now Sling only supports OSGi bundles as a deployable 
artifacts (however, the bundles might be extended by JCR content with the help 
of [0]). On the other hand there is already the content-package-maven-plugin 
from Adobe [1], which wraps parts of a JCR repository into a deployable 
artifact (leveraging the JackrabbitFileVaultFS [2]). I would like to extend the 
Sling IDE Tooling with a custom m2e project configurator for the packaging 
“content-package”. Right now the patch is not integrated because of the unclear 
status of the content-package-maven-plugin [3]. Is it supposed to become Open 
Source like FileVault as indicated in [4]? Do you think that such a m2e project 
configurator should become part of the Sling IDE Tooling?

Thanks for your input on this topic,
Konrad

[0] - http://sling.apache.org/site/content-loading-jcrcontentloader.html
[1] - 
http://dev.day.com/docs/en/cq/current/core/how_to/how_to_use_the_vlttool/vlt-mavenplugin.html
[2] - http://wiki.apache.org/jackrabbit/JackrabbitFileVaultFS
[3] - https://issues.apache.org/jira/browse/SLING-3100
[4] - 
http://mail-archives.apache.org/mod_mbox/jackrabbit-dev/201305.mbox/%3CCAB+dfim97qLN=mv+dleddovvsh5j6puq_2nd9gbr7djo3in...@mail.gmail.com%3E

Re: Disabling our jenkins builds?

2013-12-11 Thread Konrad Windszus

Yes, disabling those jobs for now is a good idea. Could someone add links to 
the buildbot to 
http://sling.apache.org/project-information.html#continuous-integration?
Thanks,
Konrad

On 11 Dec 2013, at 10:02, Carsten Ziegeler cziege...@apache.org wrote:

 +1 for disabling
 
 
 2013/12/11 Bertrand Delacretaz bdelacre...@apache.org
 
 Hi,
 
 Our SLING-3234 buildbot builds are working fine now, there's very few
 remaining intermittent test failures (marked as blockers to that
 issue) and buildbot itself looks very stable. See
 http://ci.apache.org/builders/sling-trunk and
 http://ci.apache.org/builders/sling-trunk-oak
 
 Is anyone willing and able to fix our jenkins builds? Currently, those
 mostly produce noise with intermittent failures due to Jenkins itself.
 
 If not, I suggest disabling the Jenkins builds - not deleting them for
 now, but just turning them off.
 
 -Bertrand
 
 
 
 
 -- 
 Carsten Ziegeler
 cziege...@apache.org

Re: [RFC] YAMF - Yet Another Model Factory

2013-12-19 Thread Konrad Windszus

HI Justin,
thank a lot for that. I am assuming a lot of developers were waiting for just 
that. Could you extend the wiki page with an example on how the model bean 
should then be used from within the view (i.e. the JSP) and also some words 
about the scope of one instance?
One very good addition to the annotations would probably be a default value in 
case there is nothing reasonable to be injected (very useful for resource 
values which are not yet set).
Thanks,
Konrad

Am 19.12.2013 um 18:07 schrieb Justin Edelson jus...@justinedelson.com:

 Hi,
 I've published a page to the wiki about a concept I've been working on
 to consolidate the various appproaches I have seen in the wild to
 model object creation. I'm calling this YAMF for now, although ideally
 we'll just call it Sling Models :)
 
 Without repeating the whole contents of the wiki page, at a high
 level, this is a purely annotation driven approach supporting both
 classes and interfaces. Your model class simply needs to declare from
 which other classes it can be adapted:
 
 @Model(adaptables=Resource.class)
 
 And then annotate the fields (for classes) and methods (for
 interfaces) which need injection:
 
 @Inject
 private String propertyName;
 
 You can inject properties, OSGi services, request attributes, and
 entries from SlingBindings.
 
 New injector types can be created through an SPI.
 
 Additional annotations are supported for special cases:
 
 @Optional - mark a field/method as optional.
 @Filter - provide a filter (i.e. for OSGi services)
 @Named - specify a name (other than the default field/method name) to
 use for the inejction lookup.
 
 More detail can be found here:
 https://cwiki.apache.org/confluence/display/SLING/YAMF+-+Yet+Another+Model+Factory
 
 The working code is up in my whiteboard:
 https://svn.apache.org/repos/asf/sling/whiteboard/justin/yamf/
 
 Look forward to your feedback.
 
 Regards,
 Justin

Re: [RFC] YAMF - Yet Another Model Factory

2013-12-19 Thread Konrad Windszus

Hi Justin, 
thanks a lot. I would like to see a section in the wiki where required 
injections are described in detail. I guess in case for injected Sling values 
which are not there the instantiation fails (i.e. adaptTo will return null). 
What happens in case a default value is specified? In my regard the annotations 
Optional and Default should not be combined. 
Regards,
Konrad
Am 19.12.2013 um 22:33 schrieb Justin Edelson jus...@justinedelson.com:

 Hi Konrad,
 Defaults have been implemented. Check the wiki.
 
 Regards,
 Justin
 
 On Thu, Dec 19, 2013 at 12:21 PM, Konrad Windszus konra...@gmx.de wrote:
 HI Justin,
 thank a lot for that. I am assuming a lot of developers were waiting for 
 just that. Could you extend the wiki page with an example on how the model 
 bean should then be used from within the view (i.e. the JSP) and also some 
 words about the scope of one instance?
 One very good addition to the annotations would probably be a default value 
 in case there is nothing reasonable to be injected (very useful for resource 
 values which are not yet set).
 Thanks,
 Konrad
 
 Am 19.12.2013 um 18:07 schrieb Justin Edelson jus...@justinedelson.com:
 
 Hi,
 I've published a page to the wiki about a concept I've been working on
 to consolidate the various appproaches I have seen in the wild to
 model object creation. I'm calling this YAMF for now, although ideally
 we'll just call it Sling Models :)
 
 Without repeating the whole contents of the wiki page, at a high
 level, this is a purely annotation driven approach supporting both
 classes and interfaces. Your model class simply needs to declare from
 which other classes it can be adapted:
 
 @Model(adaptables=Resource.class)
 
 And then annotate the fields (for classes) and methods (for
 interfaces) which need injection:
 
 @Inject
 private String propertyName;
 
 You can inject properties, OSGi services, request attributes, and
 entries from SlingBindings.
 
 New injector types can be created through an SPI.
 
 Additional annotations are supported for special cases:
 
 @Optional - mark a field/method as optional.
 @Filter - provide a filter (i.e. for OSGi services)
 @Named - specify a name (other than the default field/method name) to
 use for the inejction lookup.
 
 More detail can be found here:
 https://cwiki.apache.org/confluence/display/SLING/YAMF+-+Yet+Another+Model+Factory
 
 The working code is up in my whiteboard:
 https://svn.apache.org/repos/asf/sling/whiteboard/justin/yamf/
 
 Look forward to your feedback.
 
 Regards,
 Justin

Re: [RFC] YAMF - Yet Another Model Factory

2013-12-20 Thread Konrad Windszus

Hi Justin, 
another useful feature just came to my mind (in fact we are using it in our own 
annotation framework) which is composition. Would it be much effort to allow 
injecting one model into another?
We do have the following usecase for that (although this is CQ, I guess there 
is a similar usecase in Sling only):

You have a model for an image with title, alternative text.
You have a model for multiline text fields and alignment.
There exist resourceTypes for each of the models as well as a composite 
resourceType multilineImage.
For the composite resourceType I would like to reuse the existing models, but I 
cannot split up the view (i.e. the JSPs and work with sling:include), because 
the html is somehow intertwined.
Therefore I would define another composite model exposing the models for both 
image and multiline and use that composite model in my JSP.

It would be great if for the injection of other models it would be possible to 
switch the current resource as well (i.e. descent into subnode image).
That do you think about that?

Thanks in advance,
Konrad



Am 19.12.2013 um 18:07 schrieb Justin Edelson jus...@justinedelson.com:

 Hi,
 I've published a page to the wiki about a concept I've been working on
 to consolidate the various appproaches I have seen in the wild to
 model object creation. I'm calling this YAMF for now, although ideally
 we'll just call it Sling Models :)
 
 Without repeating the whole contents of the wiki page, at a high
 level, this is a purely annotation driven approach supporting both
 classes and interfaces. Your model class simply needs to declare from
 which other classes it can be adapted:
 
 @Model(adaptables=Resource.class)
 
 And then annotate the fields (for classes) and methods (for
 interfaces) which need injection:
 
 @Inject
 private String propertyName;
 
 You can inject properties, OSGi services, request attributes, and
 entries from SlingBindings.
 
 New injector types can be created through an SPI.
 
 Additional annotations are supported for special cases:
 
 @Optional - mark a field/method as optional.
 @Filter - provide a filter (i.e. for OSGi services)
 @Named - specify a name (other than the default field/method name) to
 use for the inejction lookup.
 
 More detail can be found here:
 https://cwiki.apache.org/confluence/display/SLING/YAMF+-+Yet+Another+Model+Factory
 
 The working code is up in my whiteboard:
 https://svn.apache.org/repos/asf/sling/whiteboard/justin/yamf/
 
 Look forward to your feedback.
 
 Regards,
 Justin

Re: [RFC] YAMF - Yet Another Model Factory

2013-12-20 Thread Konrad Windszus

Hi Justin,
let me give a concrete example where switching resource nodes is actually 
useful: I do have a composition model of two image models (i.e. the same 
class). Obviously they cannot share the same node, as both models are referring 
to the same value names. Therefore an approach similar to sling:include 
path=... resourceType=.. would be very useful on the model side. I admit 
that in the case of models it is a little bit different, because we are not 
doing real request dispatching here. Rather I want to have a way to tell the 
factory (or only the ValueMap injector) to act on a certain sub node of the 
request resource instead of the request resource itself. That way we could tell 
the instance1 of the image model to act on subnode 'image1 and the instance2 
of that model to act on subnode image2.

Regards,
Konrad

Am 20.12.2013 um 13:41 schrieb Justin Edelson jus...@justinedelson.com:

 Hi Konrad,
 This makes sense, except for the part about switch the current
 resource? What do you mean by this? It seems we should be treating
 the request resource (which is what I think of as the current
 resource) as immutable.
 
 Regards,
 Justin
 
 On Fri, Dec 20, 2013 at 5:31 AM, Konrad Windszus konra...@gmx.de wrote:
 Hi Justin,
 another useful feature just came to my mind (in fact we are using it in our 
 own annotation framework) which is composition. Would it be much effort to 
 allow injecting one model into another?
 We do have the following usecase for that (although this is CQ, I guess 
 there is a similar usecase in Sling only):
 
 You have a model for an image with title, alternative text.
 You have a model for multiline text fields and alignment.
 There exist resourceTypes for each of the models as well as a composite 
 resourceType multilineImage.
 For the composite resourceType I would like to reuse the existing models, 
 but I cannot split up the view (i.e. the JSPs and work with sling:include), 
 because the html is somehow intertwined.
 Therefore I would define another composite model exposing the models for 
 both image and multiline and use that composite model in my JSP.
 
 It would be great if for the injection of other models it would be possible 
 to switch the current resource as well (i.e. descent into subnode image).
 That do you think about that?
 
 Thanks in advance,
 Konrad
 
 
 
 Am 19.12.2013 um 18:07 schrieb Justin Edelson jus...@justinedelson.com:
 
 Hi,
 I've published a page to the wiki about a concept I've been working on
 to consolidate the various appproaches I have seen in the wild to
 model object creation. I'm calling this YAMF for now, although ideally
 we'll just call it Sling Models :)
 
 Without repeating the whole contents of the wiki page, at a high
 level, this is a purely annotation driven approach supporting both
 classes and interfaces. Your model class simply needs to declare from
 which other classes it can be adapted:
 
 @Model(adaptables=Resource.class)
 
 And then annotate the fields (for classes) and methods (for
 interfaces) which need injection:
 
 @Inject
 private String propertyName;
 
 You can inject properties, OSGi services, request attributes, and
 entries from SlingBindings.
 
 New injector types can be created through an SPI.
 
 Additional annotations are supported for special cases:
 
 @Optional - mark a field/method as optional.
 @Filter - provide a filter (i.e. for OSGi services)
 @Named - specify a name (other than the default field/method name) to
 use for the inejction lookup.
 
 More detail can be found here:
 https://cwiki.apache.org/confluence/display/SLING/YAMF+-+Yet+Another+Model+Factory
 
 The working code is up in my whiteboard:
 https://svn.apache.org/repos/asf/sling/whiteboard/justin/yamf/
 
 Look forward to your feedback.
 
 Regards,
 Justin

Re: [RFC] YAMF - Yet Another Model Factory

2014-01-07 Thread Konrad Windszus

Hi Justin,
thanks for the additions.
It would be great if you could extend the documentation in the wiki with the 
following information:
- which injectors are available for which adaptables
- the order in which the injectors are called
- some more information about @Projection (when it is necessary to call it, 
i.e. if a desired injector can only act on a child object of the adaptable)
- some example code on how to use @Source

Maybe a table with the different injectors in the rows and the behaviour in 
terms of the injection-specific annotations like @Named, @Filter as well as the 
supported adaptable would be the best.

Regarding the OSGiServiceInjector: I did not see the ungetService, therefore 
the service reference is probably never released.

Cheers,
Konrad


On 24 Dec 2013, at 22:16, Justin Edelson jus...@justinedelson.com wrote:

 Thanks everyone for your feedback. I've updated both the wiki and
 implementation to include support for:
 * declaring an injection as being provided specifically by a
 particular injector, using the @Source annotation (as well as adding
 this annotation to @Filter)
 * composition support (without new annotations)
 * switched package to .annotations from .api
 * using BundleTracker rather than BundleListener
 * a new injector type for child resources
 
 I also tried to add some reference information to the wiki.
 
 I think this captured all of the feedback received so far. Thanks again.
 
 Justin
 
 On Sat, Dec 21, 2013 at 1:47 AM, Georg Henzler
 sl...@cq-eclipse-plugin.net wrote:
 Hi all,
 
 first of all I have to say that I'm really happy to see that effort is being
 made to come up with a annotation based model binding mechansim. We've been
 using our own-grown for a while, but a standard is better! :)
 
 I also think it would be useful to inject sub models. Using only the
 @Inject annotation is ambiguous though, as the class could be either an OSGi
 Service or a sub model. A solution for this could be to use an annotation
 like @SubModel and make OSGi services the default.
 
 @Inject @SubModel
 private ImageModel image; // using the field name as context path for the
 sub model as default, in this case ./image
 
 @Inject @SubModel(path=image2) // path explicitly provided, here ./image2
 private ImageModel anotherImage;
 
 @Inject // assumed to be an OSGi service for non-primitive types
 private SomeOtherClass myService;
 
 
 -Georg
 
 
 Am 20.12.2013 15:19, schrieb Justin Edelson:
 
 Hi Konrad,
 Thanks for the clarification.
 
 It seems straightforward enough to be able to adapt the injected value
 if it is not assignable to the field's class.
 
 @Inject
 private ImageModel image
 
 image would be a Resource object natively which could then be adapted
 to the ImageModel class.
 
 Justin
 
 
 
 On Fri, Dec 20, 2013 at 8:08 AM, Konrad Windszus konra...@gmx.de wrote:
 
 Hi Justin,
 let me give a concrete example where switching resource nodes is actually
 useful: I do have a composition model of two image models (i.e. the same
 class). Obviously they cannot share the same node, as both models are
 referring to the same value names. Therefore an approach similar to
 sling:include path=... resourceType=.. would be very useful on the
 model side. I admit that in the case of models it is a little bit 
 different,
 because we are not doing real request dispatching here. Rather I want to
 have a way to tell the factory (or only the ValueMap injector) to act on a
 certain sub node of the request resource instead of the request resource
 itself. That way we could tell the instance1 of the image model to act on
 subnode 'image1 and the instance2 of that model to act on subnode 
 image2.
 
 Regards,
 Konrad
 
 Am 20.12.2013 um 13:41 schrieb Justin Edelson jus...@justinedelson.com:
 
 Hi Konrad,
 This makes sense, except for the part about switch the current
 resource? What do you mean by this? It seems we should be treating
 the request resource (which is what I think of as the current
 resource) as immutable.
 
 Regards,
 Justin
 
 On Fri, Dec 20, 2013 at 5:31 AM, Konrad Windszus konra...@gmx.de
 wrote:
 
 Hi Justin,
 another useful feature just came to my mind (in fact we are using it in
 our own annotation framework) which is composition. Would it be much 
 effort
 to allow injecting one model into another?
 We do have the following usecase for that (although this is CQ, I guess
 there is a similar usecase in Sling only):
 
 You have a model for an image with title, alternative text.
 You have a model for multiline text fields and alignment.
 There exist resourceTypes for each of the models as well as a composite
 resourceType multilineImage.
 For the composite resourceType I would like to reuse the existing
 models, but I cannot split up the view (i.e. the JSPs and work with
 sling:include), because the html is somehow intertwined.
 Therefore I would define another composite model exposing the models
 for both image and multiline and use that composite model in my JSP

Impact of having a lot of short-living session objects

2014-01-10 Thread Konrad Windszus

In SLING-3285 there was an issue reported and supposably fixed related to many 
short-living sessions. I want to discuss here what the real problem is related 
to having so many short-living sessions

The open questions are:
1) Is creating a short-living session expensive?
2) Are closed sessions a problem within the Jackrabbit code (do closed (but not 
yet garbage collected) sessions impose any overhead in the JCR)?
3) Is the problem that those session objects with a finalizer cannot be 
released fast enough (because the JVM  doesn’t trigger the finalizer methods 
fast enough as described in http://www.fasterj.com/articles/finalizer1.shtml)

The general question is: Under which circumstances is it worth to cache a 
session (for a single thread) instead of just creating new ones and close them 
directly afterwards?
Thanks,
Konrad

Re: [RFC] YAMF - Yet Another Model Factory

2014-01-10 Thread Konrad Windszus

, but a standard is better! :)
 
 I also think it would be useful to inject sub models. Using only the
 @Inject annotation is ambiguous though, as the class could be either an
 OSGi
 Service or a sub model. A solution for this could be to use an
 annotation
 like @SubModel and make OSGi services the default.
 
 @Inject @SubModel
 private ImageModel image; // using the field name as context path for
 the
 sub model as default, in this case ./image
 
 @Inject @SubModel(path=image2) // path explicitly provided, here
 ./image2
 private ImageModel anotherImage;
 
 @Inject // assumed to be an OSGi service for non-primitive types
 private SomeOtherClass myService;
 
 
 -Georg
 
 
 Am 20.12.2013 15:19, schrieb Justin Edelson:
 
 Hi Konrad,
 Thanks for the clarification.
 
 It seems straightforward enough to be able to adapt the injected value
 if it is not assignable to the field's class.
 
 @Inject
 private ImageModel image
 
 image would be a Resource object natively which could then be adapted
 to the ImageModel class.
 
 Justin
 
 
 
 On Fri, Dec 20, 2013 at 8:08 AM, Konrad Windszus konra...@gmx.de
 wrote:
 
 
 Hi Justin,
 let me give a concrete example where switching resource nodes is
 actually
 useful: I do have a composition model of two image models (i.e. the
 same
 class). Obviously they cannot share the same node, as both models are
 referring to the same value names. Therefore an approach similar to
 sling:include path=... resourceType=.. would be very useful on
 the
 model side. I admit that in the case of models it is a little bit
 different,
 because we are not doing real request dispatching here. Rather I want
 to
 have a way to tell the factory (or only the ValueMap injector) to act
 on a
 certain sub node of the request resource instead of the request
 resource
 itself. That way we could tell the instance1 of the image model to
 act on
 subnode 'image1 and the instance2 of that model to act on subnode
 image2.
 
 Regards,
 Konrad
 
 Am 20.12.2013 um 13:41 schrieb Justin Edelson
 jus...@justinedelson.com:
 
 Hi Konrad,
 This makes sense, except for the part about switch the current
 resource? What do you mean by this? It seems we should be treating
 the request resource (which is what I think of as the current
 resource) as immutable.
 
 Regards,
 Justin
 
 On Fri, Dec 20, 2013 at 5:31 AM, Konrad Windszus konra...@gmx.de
 wrote:
 
 
 Hi Justin,
 another useful feature just came to my mind (in fact we are using
 it in
 our own annotation framework) which is composition. Would it be
 much effort
 to allow injecting one model into another?
 We do have the following usecase for that (although this is CQ, I
 guess
 there is a similar usecase in Sling only):
 
 You have a model for an image with title, alternative text.
 You have a model for multiline text fields and alignment.
 There exist resourceTypes for each of the models as well as a
 composite
 resourceType multilineImage.
 For the composite resourceType I would like to reuse the existing
 models, but I cannot split up the view (i.e. the JSPs and work with
 sling:include), because the html is somehow intertwined.
 Therefore I would define another composite model exposing the
 models
 for both image and multiline and use that composite model in my
 JSP.
 
 It would be great if for the injection of other models it would be
 possible to switch the current resource as well (i.e. descent into
 subnode
 image).
 That do you think about that?
 
 Thanks in advance,
 Konrad
 
 
 
 Am 19.12.2013 um 18:07 schrieb Justin Edelson
 jus...@justinedelson.com:
 
 Hi,
 I've published a page to the wiki about a concept I've been
 working on
 to consolidate the various appproaches I have seen in the wild to
 model object creation. I'm calling this YAMF for now, although
 ideally
 we'll just call it Sling Models :)
 
 Without repeating the whole contents of the wiki page, at a high
 level, this is a purely annotation driven approach supporting both
 classes and interfaces. Your model class simply needs to declare
 from
 which other classes it can be adapted:
 
 @Model(adaptables=Resource.class)
 
 And then annotate the fields (for classes) and methods (for
 interfaces) which need injection:
 
 @Inject
 private String propertyName;
 
 You can inject properties, OSGi services, request attributes, and
 entries from SlingBindings.
 
 New injector types can be created through an SPI.
 
 Additional annotations are supported for special cases:
 
 @Optional - mark a field/method as optional.
 @Filter - provide a filter (i.e. for OSGi services)
 @Named - specify a name (other than the default field/method name)
 to
 use for the inejction lookup.
 
 More detail can be found here:
 
 
 
 
 https://cwiki.apache.org/confluence/display/SLING/YAMF+-+Yet+Another+Model+Factory
 
 The working code is up in my whiteboard:
 
 https://svn.apache.org/repos/asf/sling/whiteboard/justin/yamf/
 
 Look forward to your feedback.
 
 Regards,
 Justin

Performance and stability of Sling Models

2014-03-17 Thread Konrad Windszus

Hi,
I am a little bit worried that model classes which leverage the Sling Models 
annotations might be slow and break fast. 

If you use the annotation @Inject without @Source all injectors are asked until 
one returns a value.
Since almost all injectors depend on the fieldname and cover the same 
namespace, models can break very easily.
Let me give three examples for broken models:

a) If I use in my model
@Inject
String myattribute;
which used to be resolved by the ValueMap injector and I just introduced a new 
Scripting variable with the name “myattribute” 
(https://cwiki.apache.org/confluence/display/SLING/Adding+New+Scripting+Variables),
 my model would no longer work.
b) The same would apply, if I have a Sling resource with a value named 
“service” which used to be (by coincidence) also the field name of my injected 
OSGi service in the model.
c) The same for a new request attribute, whose name conflicts with the field 
name of my injected OSGi service in the model

Regarding the performance, I fear that the lookup in the value map from the 
second injector might take some time (since JCR access is necessary in most 
cases to do that). For example if I have a model class only relying on OSGi 
services a lot of time would be wasted by asking other injectors.

To summarize: Isn’t it always advisable to use the @Source annotation to 
prevent those kind of name clashes and performance issues? Shouldn’t that be 
explicitly stated in the documentation?
What is your opinion on that?

What about making the @Source mandatory for all injectors but the ValueMap 
injector?
Thanks,
Konrad

Re: Performance and stability of Sling Models

2014-03-18 Thread Konrad Windszus

Hi Justin,
thanks for your answer. What about if I come up with a patch for additional
annotations like
@InjectSlingValue and @InjectOsgiService
which are just another way of annotating fields/methods and combine logically
both the Inject and the Source. In case of InjectOsgiService one could even
include the optional attribute filter which would add the @Filter then. For
that I would like to use the meta annotation concept (i.e. annotation the
@InjectSlingValue with @Inject and @Source). Since Java does not come with
support for meta annotations out of the box, one could just copy the according
method from the Spring Core:
https://github.com/spring-projects/spring-framework/blob/master/spring-core/src/main/java/org/springframework/core/annotation/AnnotationUtils.java#L94
and use that in the ModelAdapterFactory.

Would you accept such a patch which would basically comprise of
a) an additional annotation per injector
b) additionally evaluating the annotations on annotations within the
ModelAdapterFactory

Thanks,
Konrad

On 17 Mar 2014, at 19:01, Justin Edelson jus...@justinedelson.com wrote:

Hi Konrad,
(a) is correct and is intentional. Is there an actual situation where
this would happen accidentially? In my experience, a new BVP is not
added every day and has a broad impact. If you add a BVP without
regressing your application, that's a problem into itself.

(b) and (c) would only be correct if the type of the OSGi service is
something to which your child resource or request attribute could be
adapted, which seems highly unlikely to me.

The JCR operations (property lookup and child node lookups) should be
well-optimized by implementations. If there was an injector which
executed a query, that would be an example of a place where the
injector *should* require @Source or some other annotation to
explicitly include the injector.

If you want to introduce a strict mode which requires @Source, feel
free to submit a patch. But I don't think this makes sense as the
default.

Regards,
Justin

On Mon, Mar 17, 2014 at 1:24 PM, Konrad Windszus konra...@gmx.de wrote:
Hi,
I am a little bit worried that model classes which leverage the Sling Models
annotations might be slow and break fast.

If you use the annotation @Inject without @Source all injectors are asked
until one returns a value.
Since almost all injectors depend on the fieldname and cover the same
namespace, models can break very easily.
Let me give three examples for broken models:

a) If I use in my model
@Inject
String myattribute;
which used to be resolved by the ValueMap injector and I just introduced a
new Scripting variable with the name myattribute
(https://cwiki.apache.org/confluence/display/SLING/Adding+New+Scripting+Variables),
my model would no longer work.
b) The same would apply, if I have a Sling resource with a value named
service which used to be (by coincidence) also the field name of my
injected OSGi service in the model.
c) The same for a new request attribute, whose name conflicts with the field
name of my injected OSGi service in the model

Regarding the performance, I fear that the lookup in the value map from the
second injector might take some time (since JCR access is necessary in most
cases to do that). For example if I have a model class only relying on OSGi
services a lot of time would be wasted by asking other injectors.

To summarize: Isn't it always advisable to use the @Source annotation to
prevent those kind of name clashes and performance issues? Shouldn't that be
explicitly stated in the documentation?
What is your opinion on that?

What about making the @Source mandatory for all injectors but the ValueMap
injector?
Thanks,
Konrad

Re: Performance and stability of Sling Models

2014-03-18 Thread Konrad Windszus

Hi Justin,
great. Thanks a lot for that fix. What do you think of the following
annotations:

@SlingProperty (implies @Inject and @Source(“valuemap”))
@OsgiService (implies @Inject and @Source(“osgi-service”))
@SlingChildResource (implies @Inject and @Source(“child-resource”))

In my regard they could also provide the optional attributes
- name (for SlingProperty and ChildResource only)
- filter (for OsgiService only)
- and via (for SlingProperty and ChildResource only)

but that would require additional refactoring on either the injector or the
adapterFactory side. The advantage is, that it is easier for the developer to
look up what is supported for a specific injector (by leveraging code
completion in his IDE), instead of remembering annotations (even if those are
standard CDI annotations) and look up in the documentation whether that feature
is supported for a specific injector.

WDYT?

Thanks,
Konrad

On 18 Mar 2014, at 16:08, Justin Edelson jus...@justinedelson.com wrote:

Hi Konrad,
I don't know about those names (@InjectSlingValue specifically -
what's a Sling Value?), but I think making @Inject work via
meta-annotations make sense. That support already exists for @Source,
would just need to be extended to work with @Inject as well. I just
did a little refactoring to make the meta-annotation support easier to
extend in the future.

Whatever you submit, please just ensure there are tests included.

Regards,
Justin

On Tue, Mar 18, 2014 at 10:54 AM, Konrad Windszus konra...@gmx.de wrote:
Hi Justin,
thanks for your answer. What about if I come up with a patch for additional
annotations like
@InjectSlingValue and @InjectOsgiService
which are just another way of annotating fields/methods and combine
logically both the Inject and the Source. In case of InjectOsgiService one
could even include the optional attribute filter which would add the @Filter
then. For that I would like to use the meta annotation concept (i.e.
annotation the @InjectSlingValue with @Inject and @Source). Since Java does
not come with support for meta annotations out of the box, one could just
copy the according method from the Spring Core:
https://github.com/spring-projects/spring-framework/blob/master/spring-core/src/main/java/org/springframework/core/annotation/AnnotationUtils.java#L94
and use that in the ModelAdapterFactory.

Would you accept such a patch which would basically comprise of
a) an additional annotation per injector
b) additionally evaluating the annotations on annotations within the
ModelAdapterFactory

Thanks,
Konrad

On 17 Mar 2014, at 19:01, Justin Edelson jus...@justinedelson.com wrote:

(b) and (c) would only be correct if the type of the OSGi service is
something to which your child resource or request attribute could be
adapted, which seems highly unlikely to me.

If you want to introduce a strict mode which requires @Source, feel
free to submit a patch. But I don't think this makes sense as the
default.

Regards,
Justin

On Mon, Mar 17, 2014 at 1:24 PM, Konrad Windszus konra...@gmx.de wrote:
Hi,
I am a little bit worried that model classes which leverage the Sling
Models annotations might be slow and break fast.

a) If I use in my model
@Inject
String myattribute;
which used to be resolved by the ValueMap injector and I just introduced a
new Scripting variable with the name myattribute
(https://cwiki.apache.org/confluence/display/SLING/Adding+New+Scripting+Variables),
my model would no longer work.
b) The same would apply, if I have a Sling resource with a value named
service which used to be (by coincidence) also the field name of my
injected OSGi service in the model.
c) The same for a new request attribute, whose name conflicts with the
field name of my injected OSGi service in the model

Regarding the performance, I fear that the lookup in the value map from
the second injector might take some time (since JCR access is necessary in
most cases to do that). For example if I have a model class only relying
on OSGi services a lot of time would be wasted by asking other

Re: Performance and stability of Sling Models

2014-03-20 Thread Konrad Windszus

Hi Justin,
Unfortunately to annotate an annotation with @Inject is not allowed. The
annotation is only allowed on methods, constructors and fields.
Do you think that it would be acceptable to come up with another
inject-annotation which is also allowed on annotations?
That should just be an alternative to the standard CDI @Inject, but otherwise
it is not that simple to construct those injector-specific annotations.
Thanks,
Konrad

On 18 Mar 2014, at 16:08, Justin Edelson jus...@justinedelson.com wrote:

Whatever you submit, please just ensure there are tests included.

Regards,
Justin

Would you accept such a patch which would basically comprise of
a) an additional annotation per injector
b) additionally evaluating the annotations on annotations within the
ModelAdapterFactory

Thanks,
Konrad

On 17 Mar 2014, at 19:01, Justin Edelson jus...@justinedelson.com wrote:

(b) and (c) would only be correct if the type of the OSGi service is
something to which your child resource or request attribute could be
adapted, which seems highly unlikely to me.

If you want to introduce a strict mode which requires @Source, feel
free to submit a patch. But I don't think this makes sense as the
default.

Regards,
Justin

On Mon, Mar 17, 2014 at 1:24 PM, Konrad Windszus konra...@gmx.de wrote:
Hi,
I am a little bit worried that model classes which leverage the Sling
Models annotations might be slow and break fast.

a) If I use in my model
@Inject
String myattribute;
which used to be resolved by the ValueMap injector and I just introduced a
new Scripting variable with the name myattribute
(https://cwiki.apache.org/confluence/display/SLING/Adding+New+Scripting+Variables),
my model would no longer work.
b) The same would apply, if I have a Sling resource with a value named
service which used to be (by coincidence) also the field name of my
injected OSGi service in the model.
c) The same for a new request attribute, whose name conflicts with the
field name of my injected OSGi service in the model

Regarding the performance, I fear that the lookup in the value map from
the second injector might take some time (since JCR access is necessary in
most cases to do that). For example if I have a model class only relying
on OSGi services a lot of time would be wasted by asking other injectors.

To summarize: Isn't it always advisable to use the @Source annotation to
prevent those kind of name clashes and performance issues? Shouldn't that
be explicitly stated in the documentation?
What is your opinion on that?

What about making the @Source mandatory for all injectors but the ValueMap
injector?
Thanks,
Konrad

Status Sling IDE Tooling

2014-03-31 Thread Konrad Windszus

Hi everyone,
what is the status around the Sling IDE Tooling [0]?
There was no commit for a pretty long time there [2].
At the adaptTo 2013 there was a roadmap presented [1], but nothing happened 
basically in the last 5 months.
Could you give a short update on that?
Thanks,
Konrad

[0] - 
https://cwiki.apache.org/confluence/display/SLING/Sling+IDE+tooling+Roadmap
[1] - http://www.slideshare.net/rombertw/sling-ide-tooling-adaptto-2013
[2] - https://github.com/apache/sling/tree/trunk/tooling/ide

Re: Status Sling IDE Tooling

2014-03-31 Thread Konrad Windszus

Hi Stefan and Robert,
thanks a lot for your answers. I’m glad to hear that the project is not dead.
I might come up with some patches as well then :-)
Cheers,
Konrad

On 31 Mar 2014, at 14:20, Stefan Egli stefane...@apache.org wrote:

 Hi Konrad,
 
 On 3/31/14 12:14 PM, Robert Munteanu rob...@lmn.ro wrote:
 
 Hi Konrad,
 
 On Mon, Mar 31, 2014 at 12:59 PM, Konrad Windszus konra...@gmx.de wrote:
 Hi everyone,
 what is the status around the Sling IDE Tooling [0]?
 There was no commit for a pretty long time there [2].
 At the adaptTo 2013 there was a roadmap presented [1], but nothing
 happened basically in the last 5 months.
 Could you give a short update on that?
 
 I hope to get more time in the coming weeks to stabilize the codebase
 and release a 1.0 version.
 
 Same here.
 
 Cheers,
 Stefan
 
 
 Robert
 
 Thanks,
 Konrad
 
 [0] - 
 https://cwiki.apache.org/confluence/display/SLING/Sling+IDE+tooling+Roadm
 ap
 [1] - http://www.slideshare.net/rombertw/sling-ide-tooling-adaptto-2013
 [2] - https://github.com/apache/sling/tree/trunk/tooling/ide
 
 
 
 -- 
 Sent from my (old) computer

Re: Performance and stability of Sling Models

2014-04-17 Thread Konrad Windszus

Hi,
I am not sure about the best names for the annotations. Sling is not really
consistent whether the resource has properties (which smells a bit like JCR) or
values. Actually the name ValueMap indicates, that the proper name for Sling is
rather value than property, but even the Javadoc mentions “property (e.g. at
http://sling.apache.org/apidocs/sling6/org/apache/sling/api/resource/ValueMap.html).
What do you think about the annotations @Value (for source value-map),
@OsgiService, @ChildResource, @ScriptVariable, @RequestAttribute?

Regards,
Konrad

On 19 Mar 2014, at 09:19, Georg Henzler sl...@cq-eclipse-plugin.net wrote:

Hi all,

+1 for having meta annotations, I think they make model classes a lot more
readable and give a small performance boost (outweighs the use of
standardised @Inject IMHO).

Regarding the naming I'd choose @ResourceProperty avoiding the name clash
with @org.apache.felix.scr.annotations.Property and making it immediately
visible to new developers that @ResourceProperty is different from @Property.
I think @ChildResource and @OsgiService are good names for the other two.

Regards
Georg

Am 18.03.2014 18:12, schrieb Justin Edelson:
Hi Konrad,
How about just @Property and @ChildResource ? As with the @Model
annotation, I don't see a reason to add sling as it is already in
the package name.

@Property has overlap with SCR annotations, but I can't think of a
reason you would have them in the same class (and in any case, that's
what packages are for).

While I'm not opposed to the optional attributes, I'm worried that the
extra attributes will make the code more convoluted. If you have the
time, I say try to do it, just be on the lookout for adding
complexity. And also make sure that there aren't any dependencies on
these new annotations in the core AdaptorFactory. Someone else will
need to implement their own annotations to imply @Inject
@Source(my-custom-source) with @MyCustomSource

Regards,
Justin

On Tue, Mar 18, 2014 at 11:55 AM, Konrad Windszus konra...@gmx.de wrote:
Hi Justin,
great. Thanks a lot for that fix. What do you think of the following
annotations:

@SlingProperty (implies @Inject and @Source(valuemap))
@OsgiService (implies @Inject and @Source(osgi-service))
@SlingChildResource (implies @Inject and @Source(child-resource))

In my regard they could also provide the optional attributes
- name (for SlingProperty and ChildResource only)
- filter (for OsgiService only)
- and via (for SlingProperty and ChildResource only)

but that would require additional refactoring on either the injector or the
adapterFactory side. The advantage is, that it is easier for the developer
to look up what is supported for a specific injector (by leveraging code
completion in his IDE), instead of remembering annotations (even if those
are standard CDI annotations) and look up in the documentation whether that
feature is supported for a specific injector.

WDYT?

Thanks,
Konrad

On 18 Mar 2014, at 16:08, Justin Edelson jus...@justinedelson.com wrote:

Whatever you submit, please just ensure there are tests included.

Regards,
Justin

On Tue, Mar 18, 2014 at 10:54 AM, Konrad Windszus konra...@gmx.de wrote:
Hi Justin,
thanks for your answer. What about if I come up with a patch for
additional annotations like
@InjectSlingValue and @InjectOsgiService
which are just another way of annotating fields/methods and combine
logically both the Inject and the Source. In case of InjectOsgiService
one could even include the optional attribute filter which would add the
@Filter then. For that I would like to use the meta annotation concept
(i.e. annotation the @InjectSlingValue with @Inject and @Source). Since
Java does not come with support for meta annotations out of the box, one
could just copy the according method from the Spring Core:
https://github.com/spring-projects/spring-framework/blob/master/spring-core/src/main/java/org/springframework/core/annotation/AnnotationUtils.java#L94
and use that in the ModelAdapterFactory.

Would you accept such a patch which would basically comprise of
a) an additional annotation per injector
b) additionally evaluating the annotations on annotations within the
ModelAdapterFactory

Thanks,
Konrad

On 17 Mar 2014, at 19:01, Justin Edelson jus...@justinedelson.com wrote:

Re: TagExtraInfo for sling:adaptTo/ tag

2014-04-23 Thread Konrad Windszus

I definitely agree here. Including the TEI is almost no risk but it helps a lot 
during development (at least with IntelliJ, because Eclipse still lacks decent 
EL code completion support)

On 23 Apr 2014, at 16:52, Julian Sedding jsedd...@gmail.com wrote:

 Hi all
 
 It would be great to get the patch for SLING-3475 applied soon.
 
 The added TagExtraInfo should be low risk, as it should not impact
 run-time behavior at all.
 
 However, enabling my IDE to help prevent small bugs would be very
 helpful. Especially in conjunction with Sling Models, which make the
 sling:adaptTo/ tag much more useful.
 
 Thanks  regards
 Julian
 
 https://issues.apache.org/jira/browse/SLING-3475

Re: content-package-maven-plugin and tooling around it

2014-05-14 Thread Konrad Windszus

Is there any news about that? Maybe a rough timeline, when the
content-package-maven-plugin is becoming Open Source? I would like to get my
patch https://issues.apache.org/jira/browse/SLING-3100 in the Sling IDE Tooling
in one of the first releases if possible.
Thanks,
Konrad

On 30 Oct 2013, at 08:18, Tobias Bocanegra tri...@day.com wrote:

Hi,

we will donate the content-package maven plugin (and package manager)
to Apache Jackrabbit soon. we just need some time to finalize the
contribution.

Thanks for your understanding and patience.
Regards. Toby

On Tue, Oct 29, 2013 at 6:42 AM, Robert Munteanu rob...@lmn.ro wrote:
Hi Konrad,

On Tue, Oct 29, 2013 at 2:34 PM, Konrad Windszus konra...@gmx.de wrote:
Hi,

unfortunately right now Sling only supports OSGi bundles as a deployable
artifacts (however, the bundles might be extended by JCR content with the
help of [0]). On the other hand there is already the
content-package-maven-plugin from Adobe [1], which wraps parts of a JCR
repository into a deployable artifact (leveraging the JackrabbitFileVaultFS
[2]). I would like to extend the Sling IDE Tooling with a custom m2e
project configurator for the packaging “content-package”. Right now the
patch is not integrated because of the unclear status of the
content-package-maven-plugin [3]. Is it supposed to become Open Source like
FileVault as indicated in [4]? Do you think that such a m2e project
configurator should become part of the Sling IDE Tooling?

Just to restate my opinion, I definitely think this configurator
should be part of the Sling tooling.

However, I'm reluctant to include it until the actual maven plugin is
open-sourced. The main reason is that this will not be applicable
for/testable by many users, due to its licensing/availability.

Robert

Thanks for your input on this topic,
Konrad

[0] - http://sling.apache.org/site/content-loading-jcrcontentloader.html
[1] -
http://dev.day.com/docs/en/cq/current/core/how_to/how_to_use_the_vlttool/vlt-mavenplugin.html
[2] - http://wiki.apache.org/jackrabbit/JackrabbitFileVaultFS
[3] - https://issues.apache.org/jira/browse/SLING-3100
[4] -
http://mail-archives.apache.org/mod_mbox/jackrabbit-dev/201305.mbox/%3CCAB+dfim97qLN=mv+dleddovvsh5j6puq_2nd9gbr7djo3in...@mail.gmail.com%3E

--
Sent from my (old) computer

Re: Silng Models Validation Framework

2014-05-20 Thread Konrad Windszus

The problem with connecting something like that with Sling Models is the way 
the adaptTo method was specified. 
It is supposed to return null and never throw an exception. So all exceptions 
being caused by e.g. validation errors must be caught within Sling Models. 
Currently I don’t see any way to propagate those exceptions across the adaptTo 
boundary. That might already be a problem when for example some required 
properties are missing. It is much harder to debug because the exception is 
caught within the Sling Models framework.
I would like to have the possibility to instantiate a model class and to be 
able to catch all potential exceptions within my own code.
Konrad

On 19 May 2014, at 14:53, Bertrand Delacretaz bdelacre...@apache.org wrote:

 On Mon, May 19, 2014 at 1:43 PM, Radu Cotescu r...@cotescu.com wrote:
 ...Maybe we can revive that topic and merge the two ideas
 
 That would be great, IIRC Radu's SLING-2803 validator is meant to be
 generic, using it within Sling models should then just be another use
 case.
 
 -Bertrand

Re: Git mirror issues

2014-05-28 Thread Konrad Windszus

I opened ticket https://issues.apache.org/jira/browse/INFRA-7828 for that.
Am 28.05.2014 um 12:07 schrieb Robert Munteanu rob...@lmn.ro:

 Hi Konrad,
 
 On Wed, May 28, 2014 at 12:41 PM, Konrad Windszus konra...@gmx.de wrote:
 Currently the GIT read-only mirror at git://git.apache.org/sling.git and 
 therefore also the mirror at github is lagging behind. The last commit there 
 was 15 days ago. Can someone take a look?
 
 We don't manage this, you probably want to ask in...@apache.org ( Jira
 issue or otherwise ).
 
 Robert
 
 Thanks,
 Konrad
 
 
 
 
 
 -- 
 Sent from my (old) computer

Release of Sling Models

2014-06-16 Thread Konrad Windszus

Hi everyone,
what about a new release of Sling Models? Two issues were fixed (although 
https://issues.apache.org/jira/browse/SLING-3510 does not have the fix version 
set yet) and another improvement was made. No further open issues are reported.
WDYT?

Thanks,
Konrad

Re: [VOTE] Release Apache Sling IDE Tooling 1.0.0

2014-06-23 Thread Konrad Windszus

I just tested it and get the following exception when trying to export or 
import content via Right click “Sling - Export Content” on a content project 
which was already added as a module to the Sling Server:

The selected project is not configured with/added to any Sling server.

Do you want me to open a bug about that?

Thanks,
Konrad



On 23 Jun 2014, at 13:58, Robert Munteanu romb...@apache.org wrote:

 Hi,
 
 We solved 140 issues in this release:
 https://issues.apache.org/jira/browse/SLING/fixforversion/12324873
 
 There are still some outstanding issues:
 https://issues.apache.org/jira/browse/SLING/component/12320908
 
 The release candidate has been uploaded at
 https://dist.apache.org/repos/dist/dev/sling,
 and can be built using
 
mvn clean package
 
 The resulting binaries can be installed into an Eclipse instance by
 installing from the update site which is found at
 p2update/target/repository after building the project.
 
 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: [VOTE] Release Apache Sling IDE Tooling 1.0.0

2014-06-23 Thread Konrad Windszus


On 23 Jun 2014, at 14:25, Robert Munteanu romb...@apache.org wrote:

 On Mon, Jun 23, 2014 at 3:19 PM, Konrad Windszus konra...@gmx.de wrote:
 I just tested it and get the following exception when trying to export or 
 import content via Right click “Sling - Export Content” on a content 
 project which was already added as a module to the Sling Server:
 
 The selected project is not configured with/added to any Sling server.
 
 Do you want me to open a bug about that?
 
 Please do, since I can't reproduce it locally.

Done with https://issues.apache.org/jira/browse/SLING-3687
 
 Thanks,
 
 Robert
 
 
 Thanks,
 Konrad
 
 
 
 On 23 Jun 2014, at 13:58, Robert Munteanu romb...@apache.org wrote:
 
 Hi,
 
 We solved 140 issues in this release:
 https://issues.apache.org/jira/browse/SLING/fixforversion/12324873
 
 There are still some outstanding issues:
 https://issues.apache.org/jira/browse/SLING/component/12320908
 
 The release candidate has been uploaded at
 https://dist.apache.org/repos/dist/dev/sling,
 and can be built using
 
   mvn clean package
 
 The resulting binaries can be installed into an Eclipse instance by
 installing from the update site which is found at
 p2update/target/repository after building the project.
 
 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: adaptTo and results ....

2014-07-01 Thread Konrad Windszus

Regarding 1) Having such a Result class would mean that all consumer would need 
to unwrap the exception first. So instead of being forced of implementing a 
null-check (as with the old solution) one would need to implement another 
check. I want to prevent such a burden to the consumers.
Regarding 2) Since the client code knows on which object the adaptToOrThrow is 
called I don’t get why an instanceof check is necessary. Whether this object 
implements Adaptable2 is known at compile-time, so you do have the full 
IDE-support here.
Regarding 3) In that case I would no longer allow a null value to be returned. 
One drawback is, that all the null checks are no longer effective.

IMHO solution 2) is the best. At the same time I would deprecate the old 
Adaptable, because I cannot come up with a real use-case where returning has an 
advantage. I would rather implement another method boolean 
hasAdapter(ClassAdapterType type) on the Adaptable2 interface.
Regards,
Konrad

On 01 Jul 2014, at 09:07, Felix Meschberger fmesc...@adobe.com wrote:

 Hi
 
 There currently are two issues floating around dealing with the question of 
 returning more information than just null from the Adaptable.adaptTo(Class) 
 method: https://issues.apache.org/jira/browse/SLING-3714 and 
 https://issues.apache.org/jira/browse/SLING-3709. I think these requests 
 warrant some discussion on the list.
 
 Background: adaptTo can be implemented by Adaptable implementations 
 themselves or, by extending from SlingAdaptable, they may defer to an 
 AdapterMananager. AdapterManager itself is extended by AdapterFactory 
 services. All these interfaces define an adaptTo method. All these methods 
 return null if adaption is not possible and don't declare or document to 
 throw an exception.
 
 While not explicitly documented as such, the intention is and was that 
 adaptTo never throws on the grounds that adaption may fail which is 
 considered a valid result and thus exceptions are not to be expected and 
 handled.
 
 Hence all implementations of the methods generally 
 catch-and-log-but-don't-throw. Interestingly SlingAdaptable.adaptTo and 
 AdapterManagerImpl.getAdapter don't catch — so any RuntimeException thrown 
 from an AdapterFactory would be forwarded.
 
 Having said this there are options available:
 
 (1) Add support for a new Result? class. We would probably implement this 
 in the AdapterManager.getAdapter implementation explicitly handling this case 
 because it would entail catching the adaptTo/getAdapter calls to get the 
 exception (the Result.getError should return Throwable probably not Error)
 
 Use would be limited to new AdapterFactory implementations throwing 
 RuntimeExcpetion. For Sling Models this would be the case.
 
 (2) Add a new adaptToOrThrow method, which is declared to throw a 
 RuntimeException and never return null: Either it can adapt or it throws. 
 This would require a new interface Adaptable2 (probably) to not break 
 existing Adaptable implementations. The SlingAdaptable base class would 
 implement the new method of course, probably something like this:
 
 SlingAdaptable implements Adaptable2 {
  …
  public AdapterType AdapterType adaptToOrThrow(ClassAdapterType type) {
  AdapterType result = this.adaptTo(type);
  if (result != null) {
  return result;
  }
  throw new CannotAdaptException(…);
  }
 }
 
 
 Use is problematic because you would have to know whether you can call the 
 new method: So instead of an null check you now have an instanceof check … 
 Except for the Resource interface which would be extended to extend from 
 Adaptable2 as well.
 
 (3) Document, that Adaptable.adaptTo may throw a RuntimeException.
 
 The problem here is, that this may conceptually break existing callers of 
 Adaptable.adaptTo which don't expect an exception at all — presumably this is 
 a minor nuisance because technically a RuntimeException may always be thrown.
 
 Regards
 Felix

Re: adaptTo and results ....

2014-07-01 Thread Konrad Windszus

It is not (only) about throwing exceptions in case no suitable adapter is 
available. It rather is about the fact, that today the adaptTo is a barrier for 
all kinds of exceptions. In some cases the adaptation fails for a specific 
reason (one example is Sling Models where injection fails, another one is the 
issue mentioned in https://issues.apache.org/jira/browse/SLING-2712 (ValueMap 
not supporting primitives)). Both would be valid use cases where the client 
would be interested to catch the exception here.

On 01 Jul 2014, at 10:34, Carsten Ziegeler cziege...@apache.org wrote:

 Adding a new interface would require us to implement it all over the place
 and as Felix points out, client code would always need to check whether the
 new interface is implemented or not Having to methods, like hasAdapter and
 adaptOrThrow does not work very well as between the two calls things might
 have changed already: while hasAdapter returns true, the underlying factory
 gets unregistered before adaptOrThrow is called.
 In many use cases, the current pattern works fine - the client does not
 care whether an exception is thrown within the adaption - it just cares
 whether an object is returned or not. And there are valid use cases, where
 client code does different things whether the adaption works or not (e.g.
 the post servlet checks for adaptTo(Node) and then does additional things
 if the resource is backed up by a node.)
 
 I see the point that there are also use cases where it would be fine to
 simpy throw an exception if adaptTo is not successful. This would make the
 client code easier. However as this most properly is a runtime exception,
 client code can today just call a method on the object and end up with a
 NPE - having the same result :)
 
 This leaves us with use cases where the client code explicitely wants to
 catch the exception and then do something depending on the exception. Maybe
 we should just add something for this explicit use case instead of bloating
 the general adaptTo mechanism?
 
 Regards
 Carsten
 
 
 
 
 2014-07-01 9:44 GMT+02:00 Konrad Windszus konra...@gmx.de:
 
 Regarding 1) Having such a Result class would mean that all consumer would
 need to unwrap the exception first. So instead of being forced of
 implementing a null-check (as with the old solution) one would need to
 implement another check. I want to prevent such a burden to the consumers.
 Regarding 2) Since the client code knows on which object the
 adaptToOrThrow is called I don’t get why an instanceof check is necessary.
 Whether this object implements Adaptable2 is known at compile-time, so you
 do have the full IDE-support here.
 Regarding 3) In that case I would no longer allow a null value to be
 returned. One drawback is, that all the null checks are no longer effective.
 
 IMHO solution 2) is the best. At the same time I would deprecate the old
 Adaptable, because I cannot come up with a real use-case where returning
 has an advantage. I would rather implement another method boolean
 hasAdapter(ClassAdapterType type) on the Adaptable2 interface.
 Regards,
 Konrad
 
 On 01 Jul 2014, at 09:07, Felix Meschberger fmesc...@adobe.com wrote:
 
 Hi
 
 There currently are two issues floating around dealing with the question
 of returning more information than just null from the
 Adaptable.adaptTo(Class) method:
 https://issues.apache.org/jira/browse/SLING-3714 and
 https://issues.apache.org/jira/browse/SLING-3709. I think these requests
 warrant some discussion on the list.
 
 Background: adaptTo can be implemented by Adaptable implementations
 themselves or, by extending from SlingAdaptable, they may defer to an
 AdapterMananager. AdapterManager itself is extended by AdapterFactory
 services. All these interfaces define an adaptTo method. All these methods
 return null if adaption is not possible and don't declare or document to
 throw an exception.
 
 While not explicitly documented as such, the intention is and was that
 adaptTo never throws on the grounds that adaption may fail which is
 considered a valid result and thus exceptions are not to be expected and
 handled.
 
 Hence all implementations of the methods generally
 catch-and-log-but-don't-throw. Interestingly SlingAdaptable.adaptTo and
 AdapterManagerImpl.getAdapter don't catch — so any RuntimeException thrown
 from an AdapterFactory would be forwarded.
 
 Having said this there are options available:
 
 (1) Add support for a new Result? class. We would probably implement
 this in the AdapterManager.getAdapter implementation explicitly handling
 this case because it would entail catching the adaptTo/getAdapter calls to
 get the exception (the Result.getError should return Throwable probably not
 Error)
 
 Use would be limited to new AdapterFactory implementations throwing
 RuntimeExcpetion. For Sling Models this would be the case.
 
 (2) Add a new adaptToOrThrow method, which is declared to throw a
 RuntimeException and never return null: Either it can adapt

Re: adaptTo and results ....

2014-07-01 Thread Konrad Windszus

I like that approach. It is backwards-compatible and allows the developers to 
decide whether they want to check for null or to rely on exceptions.
The AdapterManagerImpl indeed would need to deal with such a parametrisation 
and in addition the javadocs would need to be adjusted to make it clear that 
AdapterFactories may throw RuntimeExceptions. 
Those exceptions should be caught by the AdapterManagerImpl when the 
RequireAdapter was not requested and in the other case just passed along.


On 01 Jul 2014, at 09:44, Bertrand Delacretaz bdelacre...@apache.org wrote:

 On Tue, Jul 1, 2014 at 9:41 AM, Bertrand Delacretaz
 bdelacre...@apache.org wrote:
 ...how about this:
 
  Foo f = someObject.adaptTo(RequireAdapter.for(Foo.class));
 
 Actually, rereading SLING-3714, this can be made simpler with generics
 
  Foo f = someObject.adaptTo(RequireAdapterFoo.class));
 
 where RequireAdapter causes AdapterManagerImpl to wrap the adapters to
 throw an exception if adaption returns null.
 
 -Bertrand

Re: adaptTo and results ....

2014-07-01 Thread Konrad Windszus


On 01 Jul 2014, at 12:05, Stefan Seifert sseif...@pro-vision.de wrote:

 Foo f = someObject.adaptTo(RequireAdapterFoo.class));
 
 this would still require an unwrapping of the object out of the 
 RequireAdapterFoo instance.
In my regard there is an instanceof RequireAdapter check within the 
AdapterManagerImpl which would in that case just pass/throw exceptions. So no 
need to unwrap anything for the client.
The only questions is how to get the generic type at runtime (within the 
AdapterManagerImpl), but there are solutions to that as well: 
http://stackoverflow.com/questions/3403909/get-generic-type-of-class-at-runtime


 
 Foo f = someObject.adaptTo(RequireAdapter.for(Foo.class));
 
 this looks interesting, and does not need unwrapping if the return value is 
 the input class.
 i assume it could be implemented using a ThreadLocal or similar as well?
 
 stefan
 
 
 -Original Message-
 From: Konrad Windszus [mailto:konra...@gmx.de]
 Sent: Tuesday, July 01, 2014 11:58 AM
 To: dev@sling.apache.org
 Cc: Bertrand Delacretaz
 Subject: Re: adaptTo and results 
 
 I like that approach. It is backwards-compatible and allows the developers to
 decide whether they want to check for null or to rely on exceptions.
 The AdapterManagerImpl indeed would need to deal with such a parametrisation
 and in addition the javadocs would need to be adjusted to make it clear that
 AdapterFactories may throw RuntimeExceptions.
 Those exceptions should be caught by the AdapterManagerImpl when the
 RequireAdapter was not requested and in the other case just passed along.
 
 
 On 01 Jul 2014, at 09:44, Bertrand Delacretaz bdelacre...@apache.org wrote:
 
 On Tue, Jul 1, 2014 at 9:41 AM, Bertrand Delacretaz
 bdelacre...@apache.org wrote:
 ...how about this:
 
 Foo f = someObject.adaptTo(RequireAdapter.for(Foo.class));
 
 Actually, rereading SLING-3714, this can be made simpler with generics
 
 Foo f = someObject.adaptTo(RequireAdapterFoo.class));
 
 where RequireAdapter causes AdapterManagerImpl to wrap the adapters to
 throw an exception if adaption returns null.
 
 -Bertrand

Re: adaptTo and results ....

2014-07-01 Thread Konrad Windszus

I just fix it in the code ;-). Those exceptions should only happen during
runtime (due to some false assumptions).
For the same reasons methods do throw IllegalArgumentExceptions in case a given
parameter is null
(http://stackoverflow.com/questions/5172948/should-we-always-check-each-parameter-of-method-in-java-for-null-in-the-first-li).
This is mainly for the developer, but makes the life much easier as with that
information it is obvious how to fix :-)
Konrad

On 01 Jul 2014, at 12:14, Carsten Ziegeler cziege...@apache.org wrote:

So if your adapter is buggy and you get an exception, what do you do with
it?

Carsten

2014-07-01 12:08 GMT+02:00 Jeff Young j...@adobe.com:

Hi Carsten,

Sure, but Konrad has a point in that I think sometimes the client *does*
care why the adaption failed. For instance, if it had to do with
something entirely different from whether or not adaption would normally
work.

Let's say that I have a resource that should adapt to XYZ, but that my
adapter is currently buggy. I'd like to get an exception for that, but
said exception is going to get eaten.

I do agree that if I have a resource that should NOT adapt to XYZ, that
getting back null is fine, and that I don't care why the adaption failed.

Cheers,
Jeff.

On 01/07/2014 10:19, Carsten Ziegeler cziege...@apache.org wrote:

Sure :) For the adapter pattern, the client does not care why the adaption
failed, the client is just interested in the result (success or not)
Validation is a different beast, if validation fails you want to know
specific reasons why it failed - and this can be multiple.
I tried to explain in my first mail on this thread, that all other use
cases mentioned can be handled with the current implementation - with the
exception of validation. But I think validation requires a different
concept than the adapter pattern.

Carsten

2014-07-01 11:09 GMT+02:00 Jeff Young j...@adobe.com:

Hi Carsten,

Can you say more? (I'm not sure I understand what you're getting
at)

Thanks,
Jeff.

On 01/07/2014 09:56, Carsten Ziegeler cziege...@apache.org wrote:

adaption and validation are different concerns

Carsten

2014-07-01 10:55 GMT+02:00 Jeff Young j...@adobe.com:

We could solve that by defining a specific exception for
adaptation-not-possible and then catch only that.

Of course that would leak tons of exceptions from code written before
that
exception became available. Maybe do the catching based on some
sort of
version clue?

Cheers,
Jeff.

On 01/07/2014 09:40, Konrad Windszus konra...@gmx.de wrote:

It is not (only) about throwing exceptions in case no suitable
adapter
is
available. It rather is about the fact, that today the adaptTo is a
barrier for all kinds of exceptions. In some cases the adaptation
fails
for a specific reason (one example is Sling Models where injection
fails,
another one is the issue mentioned in
https://issues.apache.org/jira/browse/SLING-2712 (ValueMap not
supporting
primitives)). Both would be valid use cases where the client would
be
interested to catch the exception here.

On 01 Jul 2014, at 10:34, Carsten Ziegeler cziege...@apache.org
wrote:

Adding a new interface would require us to implement it all over
the
place
and as Felix points out, client code would always need to check
whether
the
new interface is implemented or not Having to methods, like
hasAdapter
and
adaptOrThrow does not work very well as between the two calls
things
might
have changed already: while hasAdapter returns true, the
underlying
factory
gets unregistered before adaptOrThrow is called.
In many use cases, the current pattern works fine - the client
does
not
care whether an exception is thrown within the adaption - it just
cares
whether an object is returned or not. And there are valid use
cases,
where
client code does different things whether the adaption works or
not
(e.g.
the post servlet checks for adaptTo(Node) and then does additional
things
if the resource is backed up by a node.)

I see the point that there are also use cases where it would be
fine
to
simpy throw an exception if adaptTo is not successful. This would
make
the
client code easier. However as this most properly is a runtime
exception,
client code can today just call a method on the object and end up
with a
NPE - having the same result :)

This leaves us with use cases where the client code explicitely
wants to
catch the exception and then do something depending on the
exception.
Maybe
we should just add something for this explicit use case instead of
bloating
the general adaptTo mechanism?

Regards
Carsten

2014-07-01 9:44 GMT+02:00 Konrad Windszus konra...@gmx.de:

Regarding 1) Having such a Result class would mean that all
consumer
would
need to unwrap the exception first. So instead of being forced of
implementing a null-check (as with the old solution) one would

Re: adaptTo and results ....

2014-07-01 Thread Konrad Windszus

That would be solved by just stating that RuntimeExceptions are allowed as 
alternative to returning null for all AdapterFactories (i.e. no API change 
necessary) and making sure that those exceptions are either being caught within 
the AdapterManagerImpl or just propagated to the caller.

On 01 Jul 2014, at 13:08, Carsten Ziegeler cziege...@apache.org wrote:

 Ok, this would solve the throw if adaption is not possible case, what about
 the validation use case?
 
 Carsten
 
 
 2014-07-01 12:50 GMT+02:00 Bertrand Delacretaz bdelacre...@apache.org:
 
 On Tue, Jul 1, 2014 at 12:38 PM, Stefan Egli stefane...@apache.org
 wrote:
 I like the idea too, but I guess it's merely a question of taste as to
 which of the following two options is nicer:
 * Foo f = someObject.adaptTo(RequireAdapterFoo.class));
 * Foo f = someObject.adaptToUnchecked(Foo.class);
 
 The big difference is that the first variant requires no API changes
 and only requires code changes in AdapterManagerImpl (I think -
 haven't looked in full detail ;-)
 
 -Bertrand
 
 
 
 
 -- 
 Carsten Ziegeler
 Adobe Research Switzerland
 cziege...@apache.org

Re: adaptTo and results ....

2014-07-01 Thread Konrad Windszus

I quickly tried to implement a POC, but due to type erasure the interface is 
not as simple as just putting RequireAdapterFoo.class
I found the following reference: 
http://gafter.blogspot.de/2006/12/super-type-tokens.html and tried to implement 
something like that but could not get it to work in a simple fashion.
@Bertrand: Do you have an example in mind on how to get the wrapped type of 
RequireAdapter?
Thanks,
Konrad

On 01 Jul 2014, at 12:09, Konrad Windszus konra...@gmx.de wrote:

 
 On 01 Jul 2014, at 12:05, Stefan Seifert sseif...@pro-vision.de wrote:
 
 Foo f = someObject.adaptTo(RequireAdapterFoo.class));
 
 this would still require an unwrapping of the object out of the 
 RequireAdapterFoo instance.
 In my regard there is an instanceof RequireAdapter check within the 
 AdapterManagerImpl which would in that case just pass/throw exceptions. So no 
 need to unwrap anything for the client.
 The only questions is how to get the generic type at runtime (within the 
 AdapterManagerImpl), but there are solutions to that as well: 
 http://stackoverflow.com/questions/3403909/get-generic-type-of-class-at-runtime
 
 
 
 Foo f = someObject.adaptTo(RequireAdapter.for(Foo.class));
 
 this looks interesting, and does not need unwrapping if the return value is 
 the input class.
 i assume it could be implemented using a ThreadLocal or similar as well?
 
 stefan
 
 
 -Original Message-
 From: Konrad Windszus [mailto:konra...@gmx.de]
 Sent: Tuesday, July 01, 2014 11:58 AM
 To: dev@sling.apache.org
 Cc: Bertrand Delacretaz
 Subject: Re: adaptTo and results 
 
 I like that approach. It is backwards-compatible and allows the developers 
 to
 decide whether they want to check for null or to rely on exceptions.
 The AdapterManagerImpl indeed would need to deal with such a parametrisation
 and in addition the javadocs would need to be adjusted to make it clear that
 AdapterFactories may throw RuntimeExceptions.
 Those exceptions should be caught by the AdapterManagerImpl when the
 RequireAdapter was not requested and in the other case just passed along.
 
 
 On 01 Jul 2014, at 09:44, Bertrand Delacretaz bdelacre...@apache.org 
 wrote:
 
 On Tue, Jul 1, 2014 at 9:41 AM, Bertrand Delacretaz
 bdelacre...@apache.org wrote:
 ...how about this:
 
 Foo f = someObject.adaptTo(RequireAdapter.for(Foo.class));
 
 Actually, rereading SLING-3714, this can be made simpler with generics
 
 Foo f = someObject.adaptTo(RequireAdapterFoo.class));
 
 where RequireAdapter causes AdapterManagerImpl to wrap the adapters to
 throw an exception if adaption returns null.
 
 -Bertrand

Re: adaptTo and results ....

2014-07-03 Thread Konrad Windszus


On 03 Jul 2014, at 10:50, Alexander Klimetschek aklim...@adobe.com wrote:

 
 I guess it would make sense to have adapterfactories et. al. to work like 
 this:
 a) if it is not of the desired type, i.e. cannot semantically be adapted, 
 return null
 b) if it fails due to some actual exception, throw a runtimexception

I would be fine with that approach. So the only change is a clarification in 
the Javadocs that adaptTo in fact may throw a RuntimeException (if the 
AdapterFactory has thrown an exception) and also that AdapterFactory may throw 
a RuntimeException.
As Felix Meschberger already pointed out, neither the SlingAdaptable nor the 
AdapterManager currently catch any exceptions so that would work already with 
existing code and Sling Models could start right away throwing 
RuntimeExceptions for validation purposes.

 
 But not sure if that will work.
 
 Cheers,
 Alex

Re: adaptTo and results ....

2014-07-07 Thread Konrad Windszus

Provide a meaningful error message to the author or at least to the developer 
(leveraging the WCMDeveloperMode). By meaningful I don’t talk about something 
hidden within the logs.
Konrad

On 07 Jul 2014, at 18:27, Carsten Ziegeler cziege...@apache.org wrote:

 2014-07-07 18:14 GMT+02:00 Justin Edelson jus...@justinedelson.com:
 
 Hi,
 
 
 I found a more concrete example in the AEM codebase (so apologies to
 the non-Adobe people on this thread who will just have to take my word
 for it). The adapter factory which adapts Resources into Scene7 set
 objects makes a number of validations before returning a non-null
 result:
 1) Is the Resource an Asset?
 2) Does the Asset represet a Scene7 set? (which is done by looking at
 a property)
 3) Does the requested set class correspond to the set type of the Asset?
 
 
 But again, what different action would a client take depending on the error
 condition 1, 2 or 3?
 
 Carsten
 
 
 Regards,
 Justin
 
 
 Cheers,
 Alex
 
 
 
 
 
 -- 
 Carsten Ziegeler
 Adobe Research Switzerland
 cziege...@apache.org

Sling IDE Tooling P2-Update-Site URL

2014-07-08 Thread Konrad Windszus


Currently the update site for Eclipse is deployed at 
Apache-Mirror-Prefix//sling/eclipse/1.0.0. If installing from there, one 
would never get notified about updates, because that Update Site will always 
only contain 1.0.0. Once there is a new version a new Update Site will be 
deployed at a different URL. 
Please provide a stable update URL which always points to the most recent 
(release) version of Sling IDE Tools.
Thanks,
Konrad

P.S. The table of contents within http://sling.apache.org/downloads.cgi (in the 
second paragraph below headline downloads) does not mention Sling IDE Tooling.

Re: adaptTo and results ....

2014-07-28 Thread Konrad Windszus

I just came up with another example from CQ:

In Sightly you can instantiate a model via the use API [1]. 
Since that logic will first try to adapt from Resource then from Request and as 
fallback tries to instantiate the class leveraging the default constructor, you 
won’t get any exceptions in case required properties cannot be injected (and 
the default constructor is available).

In most of the cases instantiating the class via the default constructor is not 
the right thing to do, because if the class is annotated with @Model and 
instanciation fails that should be propagated to the user. In this case it 
defers the error message to an NPE being thrown whenever someone is trying to 
access the field (which was not instantiated because the object was not created 
with Sling Models but as a regular POJO with no injections at all). 
That takes quite some time to figure out during development, that actually 
Sling Models cannot really instantiate the class and therefore the Sightly Use 
Extension will instantiate it as simple Pojo.
That would not have happened, if Sling Models would be allowed to throw 
exceptions in case the instanciation was not successfull!

[1] - 
http://docs.adobe.com/docs/en/aem/6-0/develop/sightly/use-api-in-java.html#Alternatives%20to%20WCMUse

On 07 Jul 2014, at 18:42, Carsten Ziegeler cziege...@apache.org wrote:

 2014-07-07 18:29 GMT+02:00 Konrad Windszus konra...@gmx.de:
 
 Provide a meaningful error message to the author or at least to the
 developer (leveraging the WCMDeveloperMode). By meaningful I don’t talk
 about something hidden within the logs.
 
 
 This doesn't really convince me - the same argument would hold true for
 every API where the exception (cause) is logged, but the method just gives
 back true/false,object/null. Even for APIs throwing an exception it might
 be hard to get a meaningful message to developer. So this isn't done for
 other APIs, why should we do it differently for adaptTo?
 In addition, if you have a lot of client code using the adapter pattern,
 then you end up in converting the exception to a meaningful message in
 various places.
 
 It would be so easy to let the adapter factory do a meaningful log
 statement and there are tools/apis to pick up this log message and display
 it to the dev without requiring the developer to go to the log
 
 Carsten
 
 
 
 Konrad
 
 On 07 Jul 2014, at 18:27, Carsten Ziegeler cziege...@apache.org wrote:
 
 2014-07-07 18:14 GMT+02:00 Justin Edelson jus...@justinedelson.com:
 
 Hi,
 
 
 I found a more concrete example in the AEM codebase (so apologies to
 the non-Adobe people on this thread who will just have to take my word
 for it). The adapter factory which adapts Resources into Scene7 set
 objects makes a number of validations before returning a non-null
 result:
 1) Is the Resource an Asset?
 2) Does the Asset represet a Scene7 set? (which is done by looking at
 a property)
 3) Does the requested set class correspond to the set type of the Asset?
 
 
 But again, what different action would a client take depending on the
 error
 condition 1, 2 or 3?
 
 Carsten
 
 
 Regards,
 Justin
 
 
 Cheers,
 Alex
 
 
 
 
 
 --
 Carsten Ziegeler
 Adobe Research Switzerland
 cziege...@apache.org
 
 
 
 
 -- 
 Carsten Ziegeler
 Adobe Research Switzerland
 cziege...@apache.org

Re: adaptTo and results ....

2014-07-28 Thread Konrad Windszus

In my regard in this case a RuntimeException would be fine. That would be 
propagated correctly to the script level.
So whenever a model class has the model annotation and something went wrong 
during the injection throwing a runtime exception would be correctly propagated 
and no other option would be tried (even when using Sightlies Use Extension)

On 28 Jul 2014, at 18:03, Justin Edelson jus...@justinedelson.com wrote:

 Hi Konrad,
 In this case, I don't see how any of the options in this thread would
 actually help because the code which calls adaptTo() is not under your
 control. So there would be no way for the caller (i.e. your Sightly
 script) to indicate that such an exception should be thrown.
 
 Regards,
 Justin
 
 On Mon, Jul 28, 2014 at 11:44 AM, Konrad Windszus konra...@gmx.de wrote:
 I just came up with another example from CQ:
 
 In Sightly you can instantiate a model via the use API [1].
 Since that logic will first try to adapt from Resource then from Request and 
 as fallback tries to instantiate the class leveraging the default 
 constructor, you won’t get any exceptions in case required properties cannot 
 be injected (and the default constructor is available).
 
 In most of the cases instantiating the class via the default constructor is 
 not the right thing to do, because if the class is annotated with @Model and 
 instanciation fails that should be propagated to the user. In this case it 
 defers the error message to an NPE being thrown whenever someone is trying 
 to access the field (which was not instantiated because the object was not 
 created with Sling Models but as a regular POJO with no injections at all).
 That takes quite some time to figure out during development, that actually 
 Sling Models cannot really instantiate the class and therefore the Sightly 
 Use Extension will instantiate it as simple Pojo.
 That would not have happened, if Sling Models would be allowed to throw 
 exceptions in case the instanciation was not successfull!
 
 [1] - 
 http://docs.adobe.com/docs/en/aem/6-0/develop/sightly/use-api-in-java.html#Alternatives%20to%20WCMUse
 
 On 07 Jul 2014, at 18:42, Carsten Ziegeler cziege...@apache.org wrote:
 
 2014-07-07 18:29 GMT+02:00 Konrad Windszus konra...@gmx.de:
 
 Provide a meaningful error message to the author or at least to the
 developer (leveraging the WCMDeveloperMode). By meaningful I don’t talk
 about something hidden within the logs.
 
 
 This doesn't really convince me - the same argument would hold true for
 every API where the exception (cause) is logged, but the method just gives
 back true/false,object/null. Even for APIs throwing an exception it might
 be hard to get a meaningful message to developer. So this isn't done for
 other APIs, why should we do it differently for adaptTo?
 In addition, if you have a lot of client code using the adapter pattern,
 then you end up in converting the exception to a meaningful message in
 various places.
 
 It would be so easy to let the adapter factory do a meaningful log
 statement and there are tools/apis to pick up this log message and display
 it to the dev without requiring the developer to go to the log
 
 Carsten
 
 
 
 Konrad
 
 On 07 Jul 2014, at 18:27, Carsten Ziegeler cziege...@apache.org wrote:
 
 2014-07-07 18:14 GMT+02:00 Justin Edelson jus...@justinedelson.com:
 
 Hi,
 
 
 I found a more concrete example in the AEM codebase (so apologies to
 the non-Adobe people on this thread who will just have to take my word
 for it). The adapter factory which adapts Resources into Scene7 set
 objects makes a number of validations before returning a non-null
 result:
 1) Is the Resource an Asset?
 2) Does the Asset represet a Scene7 set? (which is done by looking at
 a property)
 3) Does the requested set class correspond to the set type of the Asset?
 
 
 But again, what different action would a client take depending on the
 error
 condition 1, 2 or 3?
 
 Carsten
 
 
 Regards,
 Justin
 
 
 Cheers,
 Alex
 
 
 
 
 
 --
 Carsten Ziegeler
 Adobe Research Switzerland
 cziege...@apache.org
 
 
 
 
 --
 Carsten Ziegeler
 Adobe Research Switzerland
 cziege...@apache.org

Sling Models: Clarification around Type Conversions

2014-08-07 Thread Konrad Windszus

Currently in Sling Models we do have support for four different kind of type 
conversions

a) from primitive to wrapper and vice-versa (also within arrays), e.g. Integer 
to int
b) from single item to one item collection (both List and Collection), e.g. 
ListInteger to Integer
c) from Adaptable to supported AdapterType
d) from subtype to super type

That conversion logic must either be implemented in the Injector itself (if it 
does evaluate the type) or the ModelAdapterFactory is taking care of that. In 
the latter case the support differs for field and method:
- Method injection supports only c), d)
- Field injection supports a), b), c) and d)

The support for these conversions differs a lot between the different injectors.
1) BindingsInjector, checks for type itself, does neither support a), b), c) 
nor d)!
2) ChildResource does no type checking, therefore uses the ModelAdapterFactory 
for the conversions
3) OSGiService checks for the type itself, does neither support a), b), c) nor 
d)!
4) RequestAttribute checks for type itself, does neither support a), b), c) nor 
d)!
5) ResourceResolverInjector does no type checking, therefore uses the 
ModelAdapterFactory for the conversions
6) ValueMapInjector, checks for type itself, supports a), b), c)


I have several proposals regarding that:
==
- let all injectors support all conversions
- let both method and field injection support all conversions
- consolidate the code in one place
- document the conversions which are supported.

WDYT?
Konrad

Re: Sling Models: Clarification around Type Conversions

2014-08-07 Thread Konrad Windszus

Hi Justin,
I listed the places down below. Do you agree with the other points raised?

On 07 Aug 2014, at 22:05, Justin Edelson jus...@justinedelson.com wrote:

 Hi Konrad,
 Where are (a) and (b) implemented in the ModelAdapterFactory for fields?
 
 Justin
 
 On Thu, Aug 7, 2014 at 1:30 PM, Konrad Windszus konra...@gmx.de wrote:
 Currently in Sling Models we do have support for four different kind of type 
 conversions
 
 a) from primitive to wrapper and vice-versa (also within arrays), e.g. 
 Integer to int
 b) from single item to one item collection (both List and Collection), e.g. 
 ListInteger to Integer
 c) from Adaptable to supported AdapterType
 d) from subtype to super type
 
 That conversion logic must either be implemented in the Injector itself (if 
 it does evaluate the type) or the ModelAdapterFactory is taking care of 
 that. In the latter case the support differs for field and method:
 - Method injection supports only c), d)
 - Field injection supports a), b), c) and d)

a) is implemented at 
https://github.com/apache/sling/blob/trunk/bundles/extensions/models/impl/src/main/java/org/apache/sling/models/impl/ModelAdapterFactory.java#L724
- the actual conversion is done through reflection though I admit

b) is implemented at 
https://github.com/apache/sling/blob/trunk/bundles/extensions/models/impl/src/main/java/org/apache/sling/models/impl/ModelAdapterFactory.java#L651

 
 The support for these conversions differs a lot between the different 
 injectors.
 1) BindingsInjector, checks for type itself, does neither support a), b), c) 
 nor d)!
 2) ChildResource does no type checking, therefore uses the 
 ModelAdapterFactory for the conversions
 3) OSGiService checks for the type itself, does neither support a), b), c) 
 nor d)!
 4) RequestAttribute checks for type itself, does neither support a), b), c) 
 nor d)!
 5) ResourceResolverInjector does no type checking, therefore uses the 
 ModelAdapterFactory for the conversions
 6) ValueMapInjector, checks for type itself, supports a), b), c)
 
 
 I have several proposals regarding that:
 ==
 - let all injectors support all conversions
 - let both method and field injection support all conversions
 - consolidate the code in one place
 - document the conversions which are supported.
 
 WDYT?
 Konrad

Re: [jira] [Resolved] (SLING-4010) Allow validator to set a custom failure message

2014-10-08 Thread Konrad Windszus

I am fine with changing the return value to something more sophisticated, 
although currently I don’t see a reason for a validator to return multiple 
failure messages.
Functionality-wise the possible String return values 1) null, 2) empty string 
and 3 ) non-empty string cover the three main use cases for me:
1) validation successful
2) validation not successful with standard error message
3) validation not successful with custom error message
Konrad



On 08 Oct 2014, at 11:21, Radu Cotescu r...@apache.org wrote:

 Hi,
 
 While I do understand the need for clearer messages about why a validator
 returns false for a simple validation operation I would not rely on Strings
 for getting the result.
 
 Instead I would return something similar to the ValidationResult - an
 object encapsulating a boolean value for the result, together with a
 ListString for retrieving more detailed messages about the Validator's
 reasons for returning false.
 
 WDYT?
 
 On Wed, Oct 8, 2014 at 12:14 PM, Bertrand Delacretaz (JIRA) j...@apache.org
 wrote:
 
 
 [
 https://issues.apache.org/jira/browse/SLING-4010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]
 
 Bertrand Delacretaz resolved SLING-4010.
 
Resolution: Fixed
  Assignee: Bertrand Delacretaz
 
 That was quick! Committed in revision 1630039, thanks for your
 contribution.
 
 Allow validator to set a custom failure message
 ---
 
Key: SLING-4010
URL: https://issues.apache.org/jira/browse/SLING-4010
Project: Sling
 Issue Type: Improvement
 Components: Extensions
   Reporter: Konrad Windszus
   Assignee: Bertrand Delacretaz
 Labels: validation, validator
 
 Currently the Validator may only return a boolean value or an exception
 in case the validator was called with invalid parametrization (
 https://github.com/apache/sling/blob/trunk/contrib/validation/api/src/main/java/org/apache/sling/validation/api/Validator.java
 ).
 In some cases the validator could give some important information about
 why the validation failed. This is e.g. the cause for a reference validator
 where the cause for a failed validation could be:
 # referenced resource is not existent
 # referenced resource is not having the right resource type
 # referenced resource is not activated
 So instead of only returning a boolean value, it should also be possible
 to return a failure message.
 
 
 
 --
 This message was sent by Atlassian JIRA
 (v6.3.4#6332)

Re: [ANN] New Apache Sling Committers: Konrad Windszus and Julian Sedding

2014-11-12 Thread Konrad Windszus

Thanks Carsten,
some words about myself:
I live in Munich and I am involved with Apache Jackrabbit and Apache Sling 
since 2009. I work at Netcentric (http://www.netcentric.biz 
http://www.netcentric.biz/).
In Apache Sling I contributed some patches to Sling Models in the past. 
Currently I am focussing my work on Sling Validation and want to come up with 
some patches for that in the near future.
I feel honoured that I was invited to become Apache Sling Committer and I am 
really looking forward to work together with you guys.

Regards,
Konrad

I work at Netcentric (http://www.netcentric.biz http://www.netcentric.biz/)

 On 12 Nov 2014, at 15:01, Carsten Ziegeler cziege...@apache.org wrote:
 
 Hi
 
 it's my pleasure to announce that the Apache Sling PMC has invited
 Konrad Windszus and Julian Sedding as new Sling committers...and I'm
 very happy that both accepted.
 
 Please join me in welcoming Konrad and Julian.
 
 @Konrad, @Julian you might wanna introduce yourself
 
 Regards
 Carsten
 -- 
 Carsten Ziegeler
 Adobe Research Switzerland
 cziege...@apache.org

Validation Documentation

2014-11-24 Thread Konrad Windszus

There is currently no documentation at all on the Sling Validation stuff 
(https://issues.apache.org/jira/browse/SLING-2803 
https://issues.apache.org/jira/browse/SLING-2803).
Previously there was a readme.md describing the node structure of validation 
nodes at https://github.com/raducotescu/org.apache.sling.validation 
https://github.com/raducotescu/org.apache.sling.validation.
Unfortunately that repo was removed (or is no longer publicly visible).
Until we have something documented in 
http://sling.apache.org/documentation/bundles.html 
http://sling.apache.org/documentation/bundles.html would it be possible to 
restore the readme.md in Github?
Thanks,
Konrad

Re: [website] don't expect control on the staging process/timing

2014-11-24 Thread Konrad Windszus

Thanks for that hint Betrand. I just added such a note and published my 
changes, so you can have a look at that 
http://sling.apache.org/documentation/bundles/validation.html 
http://sling.apache.org/documentation/bundles/validation.html.
Konrad

 On 24 Nov 2014, at 11:46, Bertrand Delacretaz bdelacre...@apache.org wrote:
 
 Hi,
 
 On Mon, Nov 24, 2014 at 11:42 AM, Konrad Windszus (JIRA)
 j...@apache.org wrote:
 ...I just pushed an initial documentation with rev 1641359.
 [~radu.cotescu] Can you please review at 
 http://sling.staging.apache.org/documentation/bundles/validation.html?...
 
 Note that you can't count on this staying in the staging area, as soon
 as someone publishes other site changes this will go live as well.
 
 If you're unsure about that content I'd suggest adding a work in
 progress note at the top of the page.
 
 -Bertrand

Re: Validation Documentation

2014-11-24 Thread Konrad Windszus

I published an initial draft of the documentation to 
http://sling.apache.org/documentation/bundles/validation.html 
http://sling.apache.org/documentation/bundles/validation.html.
It would be great if someone else could have a look at that.
Thanks,
Konrad

 On 24 Nov 2014, at 09:50, Konrad Windszus konra...@gmx.de wrote:
 
 There is currently no documentation at all on the Sling Validation stuff 
 (https://issues.apache.org/jira/browse/SLING-2803 
 https://issues.apache.org/jira/browse/SLING-2803).
 Previously there was a readme.md describing the node structure of validation 
 nodes at https://github.com/raducotescu/org.apache.sling.validation 
 https://github.com/raducotescu/org.apache.sling.validation.
 Unfortunately that repo was removed (or is no longer publicly visible).
 Until we have something documented in 
 http://sling.apache.org/documentation/bundles.html 
 http://sling.apache.org/documentation/bundles.html would it be possible to 
 restore the readme.md in Github?
 Thanks,
 Konrad

Debugging Sling Models IT

2014-12-05 Thread Konrad Windszus


HI,
I need some help with resolving failures in the models.integration-tests module 
(don’t worry, those only fail for me due to some local changes).
I tried to run the integration-tests with mvn install with the option  
keepJarRunningtrue/keepJarRunning (set inside the pom.xml) and to start the 
launchpad with the remote debugging options set.
Now I get the following exception when executing the integration test

32492 [main] ERROR org.apache.sling.models.it.RemoteIT - Exception in 
maybeStartServer()
java.lang.IllegalMonitorStateException
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:503)
at 
org.apache.sling.testing.tools.sling.SlingTestBase.blockIfRequested(SlingTestBase.java:234)
at 
org.apache.sling.testing.tools.sling.SlingTestBase.startServerIfNeeded(SlingTestBase.java:152)
at 
org.apache.sling.testing.tools.sling.SlingTestBase.getServerBaseUrl(SlingTestBase.java:211)
at 
org.apache.sling.models.it.RemoteIT.getJunitServletUrl(RemoteIT.java:28)
at 
org.apache.sling.junit.remote.testrunner.SlingRemoteTestRunner.maybeExecuteTests(SlingRemoteTestRunner.java:95)
at 
org.apache.sling.junit.remote.testrunner.SlingRemoteTestRunner.getChildren(SlingRemoteTestRunner.java:138)
at 
org.junit.runners.ParentRunner.getFilteredChildren(ParentRunner.java:363)
at org.junit.runners.ParentRunner.getDescription(ParentRunner.java:297)
at org.junit.runners.ParentRunner.run(ParentRunner.java:305)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
at 
org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
at 
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
at 
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)

I don’t know why the IllegalMonitorStateException is triggered there.
Any idea?
Thanks in advance,
Konrad

Re: Debugging Sling Models IT

2014-12-05 Thread Konrad Windszus

Hi Robert,
I found the according issue: https://issues.apache.org/jira/browse/SLING-3819 
https://issues.apache.org/jira/browse/SLING-3819.
Thanks for the hint.
What about a new release of the sling testing tools?
Thanks again,
Konrad

 On 05 Dec 2014, at 17:16, Robert Munteanu robert.munte...@gmail.com wrote:
 
 Hi Konrad,
 On Dec 5, 2014 5:42 PM, Konrad Windszus konra...@gmx.de wrote:
 
 
 HI,
 I need some help with resolving failures in the models.integration-tests
 module (don’t worry, those only fail for me due to some local changes).
 I tried to run the integration-tests with mvn install with the option
 keepJarRunningtrue/keepJarRunning (set inside the pom.xml) and to start
 the launchpad with the remote debugging options set.
 Now I get the following exception when executing the integration test
 
 32492 [main] ERROR org.apache.sling.models.it.RemoteIT - Exception in
 maybeStartServer()
 java.lang.IllegalMonitorStateException
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:503)
at
 org.apache.sling.testing.tools.sling.SlingTestBase.blockIfRequested(SlingTestBase.java:234)
at
 org.apache.sling.testing.tools.sling.SlingTestBase.startServerIfNeeded(SlingTestBase.java:152)
at
 org.apache.sling.testing.tools.sling.SlingTestBase.getServerBaseUrl(SlingTestBase.java:211)
at
 org.apache.sling.models.it.RemoteIT.getJunitServletUrl(RemoteIT.java:28)
at
 org.apache.sling.junit.remote.testrunner.SlingRemoteTestRunner.maybeExecuteTests(SlingRemoteTestRunner.java:95)
at
 org.apache.sling.junit.remote.testrunner.SlingRemoteTestRunner.getChildren(SlingRemoteTestRunner.java:138)
at
 org.junit.runners.ParentRunner.getFilteredChildren(ParentRunner.java:363)
at
 org.junit.runners.ParentRunner.getDescription(ParentRunner.java:297)
at org.junit.runners.ParentRunner.run(ParentRunner.java:305)
at
 org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264)
at
 org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
at
 org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
at
 org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
at
 org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
at
 org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
 
 I don’t know why the IllegalMonitorStateException is triggered there.
 Any idea?
 Thanks in advance,
 Konrad
 
 Looks familiar. Can you try depending on a more recent version of the Sling
 testing tools? Can't dig up the issue right now since I'm on mobile...
 
 Robert

Classloading issues with Sling Models IT

2014-12-07 Thread Konrad Windszus

I am experiencing a weird bug in Sling Models IT.
It seems that both Models API 1.1.1-SNAPSHOT and Models Impl 1.1.1-SNAPSHOT are 
part of the Sling Launchpad 8-SNAPSHOT.
If I now run the Sling Models IT and deploy my own versions of those bundles, 
the API bundle is replaced by the newer version (which is correct), but both 
bundles are still available in Felix (due to class loading caching issues I 
guess).
The following happens:
1.) Sling Launchpad starts up with its own version of Models API (has bundle id 
108)
2.) Models IT deploys its own version of Models API (gets bundle id 110)
3.) Now the web console only exposes the bundle 110 and no longer bundle 108.

When I try to execute some test now I get the following exception:

Caused by: java.lang.ClassNotFoundException: 
org.apache.sling.models.factory.ModelClassException not found by 
org.apache.sling.models.api [108]
at 
org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1556)
at 
org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:77)
at 
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1993)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
at 
org.apache.felix.framework.BundleWiringImpl.getClassByDelegation(BundleWiringImpl.java:1397)
at 
org.apache.felix.framework.BundleWiringImpl.searchImports(BundleWiringImpl.java:1577)
at 
org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1507)
at 
org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:77)
at 
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1993)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
... 79 common frames omitted

This is due to the fact that the Models Impl is bound to the two different 
version of Models API at the same time:

This is the import package section of the Models Impl Bundle:
==
javax.annotation,version=0.0.0.1_007_JavaSE from org.apache.felix.framework (0) 
http://localhost:58498/system/console/bundles/0
javax.inject,version=0.0.0 from org.apache.sling.models.api (110) 
http://localhost:58498/system/console/bundles/110
javax.servlet,version=2.6.0 from org.apache.felix.http.servlet-api (24) 
http://localhost:58498/system/console/bundles/24
javax.servlet,version=3.0.0 from org.apache.felix.http.servlet-api (24) 
http://localhost:58498/system/console/bundles/24
javax.servlet.http,version=2.6.0 from org.apache.felix.http.servlet-api (24) 
http://localhost:58498/system/console/bundles/24
javax.servlet.http,version=3.0.0 from org.apache.felix.http.servlet-api (24) 
http://localhost:58498/system/console/bundles/24
org.apache.commons.collections.comparators,version=3.2.1 from 
org.apache.commons.collections (60) 
http://localhost:58498/system/console/bundles/60
org.apache.commons.collections.keyvalue,version=3.2.1 from 
org.apache.commons.collections (60) 
http://localhost:58498/system/console/bundles/60
org.apache.commons.collections.list,version=3.2.1 from 
org.apache.commons.collections (60) 
http://localhost:58498/system/console/bundles/60
org.apache.commons.collections.set,version=3.2.1 from 
org.apache.commons.collections (60) 
http://localhost:58498/system/console/bundles/60
org.apache.commons.lang,version=2.6.0 from org.apache.commons.lang (64) 
http://localhost:58498/system/console/bundles/64
org.apache.commons.logging,version=1.1.1 from jcl.over.slf4j (1) 
http://localhost:58498/system/console/bundles/1
org.apache.sling.api,version=2.3.0 from org.apache.sling.api (71) 
http://localhost:58498/system/console/bundles/71
org.apache.sling.api.adapter,version=2.2.0 from org.apache.sling.api (71) 
http://localhost:58498/system/console/bundles/71
org.apache.sling.api.resource,version=2.6.0 from org.apache.sling.api (71) 
http://localhost:58498/system/console/bundles/71
org.apache.sling.api.scripting,version=2.1.0 from org.apache.sling.api (71) 
http://localhost:58498/system/console/bundles/71
org.apache.sling.commons.osgi,version=2.2.0 from org.apache.sling.commons.osgi 
(78) http://localhost:58498/system/console/bundles/78
org.apache.sling.models.annotations,version=1.2.0 from 
org.apache.sling.models.api (110) 
http://localhost:58498/system/console/bundles/110
org.apache.sling.models.annotations.injectorspecific,version=1.1.0 from 
org.apache.sling.models.api (110) 
http://localhost:58498/system/console/bundles/110
org.apache.sling.models.factory,version=1.0.0 from org.apache.sling.models.api 
(108) http://localhost:58498/system/console/bundles/108
org.apache.sling.models.spi,version=1.0.2 from org.apache.sling.models.api 
(108) http://localhost:58498/system/console/bundles/108
org.apache.sling.models.spi.injectorspecific,version=1.1.0 from 
org.apache.sling.models.api (110) 
http://localhost:58498/system/console/bundles/110

Re: Classloading issues with Sling Models IT

2014-12-07 Thread Konrad Windszus

It does work, if I I modify 
org.apache.sling.testing.tools.sling.BundlesInstaller to not uninstall the 
previous SNAPSHOT bundle before installing the new version (comment out line 
80). What was the reason for first uninstalling the bundle? Usually an upgrade 
works much smoother (at least if the version is not downgraded).
So what about the following change: Uninstall only if the previously installed 
versionis higher than the version which is about to be installed. Otherwise we 
might easily run into the same problems for other bundles, which cannot easily 
be uninstalled.


 On 07 Dec 2014, at 14:34, Konrad Windszus konra...@gmx.de wrote:
 
 I am experiencing a weird bug in Sling Models IT.
 It seems that both Models API 1.1.1-SNAPSHOT and Models Impl 1.1.1-SNAPSHOT 
 are part of the Sling Launchpad 8-SNAPSHOT.
 If I now run the Sling Models IT and deploy my own versions of those bundles, 
 the API bundle is replaced by the newer version (which is correct), but both 
 bundles are still available in Felix (due to class loading caching issues I 
 guess).
 The following happens:
 1.) Sling Launchpad starts up with its own version of Models API (has bundle 
 id 108)
 2.) Models IT deploys its own version of Models API (gets bundle id 110)
 3.) Now the web console only exposes the bundle 110 and no longer bundle 108.
 
 When I try to execute some test now I get the following exception:
 
 Caused by: java.lang.ClassNotFoundException: 
 org.apache.sling.models.factory.ModelClassException not found by 
 org.apache.sling.models.api [108]
   at 
 org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1556)
   at 
 org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:77)
   at 
 org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1993)
   at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
   at 
 org.apache.felix.framework.BundleWiringImpl.getClassByDelegation(BundleWiringImpl.java:1397)
   at 
 org.apache.felix.framework.BundleWiringImpl.searchImports(BundleWiringImpl.java:1577)
   at 
 org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1507)
   at 
 org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:77)
   at 
 org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1993)
   at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
   ... 79 common frames omitted
 
 This is due to the fact that the Models Impl is bound to the two different 
 version of Models API at the same time:
 
 This is the import package section of the Models Impl Bundle:
 ==
 javax.annotation,version=0.0.0.1_007_JavaSE from org.apache.felix.framework 
 (0) http://localhost:58498/system/console/bundles/0
 javax.inject,version=0.0.0 from org.apache.sling.models.api (110) 
 http://localhost:58498/system/console/bundles/110
 javax.servlet,version=2.6.0 from org.apache.felix.http.servlet-api (24) 
 http://localhost:58498/system/console/bundles/24
 javax.servlet,version=3.0.0 from org.apache.felix.http.servlet-api (24) 
 http://localhost:58498/system/console/bundles/24
 javax.servlet.http,version=2.6.0 from org.apache.felix.http.servlet-api (24) 
 http://localhost:58498/system/console/bundles/24
 javax.servlet.http,version=3.0.0 from org.apache.felix.http.servlet-api (24) 
 http://localhost:58498/system/console/bundles/24
 org.apache.commons.collections.comparators,version=3.2.1 from 
 org.apache.commons.collections (60) 
 http://localhost:58498/system/console/bundles/60
 org.apache.commons.collections.keyvalue,version=3.2.1 from 
 org.apache.commons.collections (60) 
 http://localhost:58498/system/console/bundles/60
 org.apache.commons.collections.list,version=3.2.1 from 
 org.apache.commons.collections (60) 
 http://localhost:58498/system/console/bundles/60
 org.apache.commons.collections.set,version=3.2.1 from 
 org.apache.commons.collections (60) 
 http://localhost:58498/system/console/bundles/60
 org.apache.commons.lang,version=2.6.0 from org.apache.commons.lang (64) 
 http://localhost:58498/system/console/bundles/64
 org.apache.commons.logging,version=1.1.1 from jcl.over.slf4j (1) 
 http://localhost:58498/system/console/bundles/1
 org.apache.sling.api,version=2.3.0 from org.apache.sling.api (71) 
 http://localhost:58498/system/console/bundles/71
 org.apache.sling.api.adapter,version=2.2.0 from org.apache.sling.api (71) 
 http://localhost:58498/system/console/bundles/71
 org.apache.sling.api.resource,version=2.6.0 from org.apache.sling.api (71) 
 http://localhost:58498/system/console/bundles/71
 org.apache.sling.api.scripting,version=2.1.0 from org.apache.sling.api (71) 
 http://localhost:58498/system/console/bundles/71
 org.apache.sling.commons.osgi,version=2.2.0 from 
 org.apache.sling.commons.osgi (78) 
 http://localhost:58498/system/console/bundles/78

Re: Classloading issues with Sling Models IT

2014-12-07 Thread Konrad Windszus

Ok, that modification did not solve everything. With that change the 
integration tests are executed too fast (before the actual upgrade of the 
bundle took place). I guess the waitForBundlesInstalled method needs to be 
changed as well.

 On 07 Dec 2014, at 15:17, Konrad Windszus konra...@gmx.de wrote:
 
 It does work, if I I modify 
 org.apache.sling.testing.tools.sling.BundlesInstaller to not uninstall the 
 previous SNAPSHOT bundle before installing the new version (comment out line 
 80). What was the reason for first uninstalling the bundle? Usually an 
 upgrade works much smoother (at least if the version is not downgraded).
 So what about the following change: Uninstall only if the previously 
 installed versionis higher than the version which is about to be installed. 
 Otherwise we might easily run into the same problems for other bundles, which 
 cannot easily be uninstalled.
 
 
 On 07 Dec 2014, at 14:34, Konrad Windszus konra...@gmx.de wrote:
 
 I am experiencing a weird bug in Sling Models IT.
 It seems that both Models API 1.1.1-SNAPSHOT and Models Impl 1.1.1-SNAPSHOT 
 are part of the Sling Launchpad 8-SNAPSHOT.
 If I now run the Sling Models IT and deploy my own versions of those 
 bundles, the API bundle is replaced by the newer version (which is correct), 
 but both bundles are still available in Felix (due to class loading caching 
 issues I guess).
 The following happens:
 1.) Sling Launchpad starts up with its own version of Models API (has bundle 
 id 108)
 2.) Models IT deploys its own version of Models API (gets bundle id 110)
 3.) Now the web console only exposes the bundle 110 and no longer bundle 108.
 
 When I try to execute some test now I get the following exception:
 
 Caused by: java.lang.ClassNotFoundException: 
 org.apache.sling.models.factory.ModelClassException not found by 
 org.apache.sling.models.api [108]
  at 
 org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1556)
  at 
 org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:77)
  at 
 org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1993)
  at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
  at 
 org.apache.felix.framework.BundleWiringImpl.getClassByDelegation(BundleWiringImpl.java:1397)
  at 
 org.apache.felix.framework.BundleWiringImpl.searchImports(BundleWiringImpl.java:1577)
  at 
 org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1507)
  at 
 org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:77)
  at 
 org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1993)
  at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
  ... 79 common frames omitted
 
 This is due to the fact that the Models Impl is bound to the two different 
 version of Models API at the same time:
 
 This is the import package section of the Models Impl Bundle:
 ==
 javax.annotation,version=0.0.0.1_007_JavaSE from org.apache.felix.framework 
 (0) http://localhost:58498/system/console/bundles/0
 javax.inject,version=0.0.0 from org.apache.sling.models.api (110) 
 http://localhost:58498/system/console/bundles/110
 javax.servlet,version=2.6.0 from org.apache.felix.http.servlet-api (24) 
 http://localhost:58498/system/console/bundles/24
 javax.servlet,version=3.0.0 from org.apache.felix.http.servlet-api (24) 
 http://localhost:58498/system/console/bundles/24
 javax.servlet.http,version=2.6.0 from org.apache.felix.http.servlet-api (24) 
 http://localhost:58498/system/console/bundles/24
 javax.servlet.http,version=3.0.0 from org.apache.felix.http.servlet-api (24) 
 http://localhost:58498/system/console/bundles/24
 org.apache.commons.collections.comparators,version=3.2.1 from 
 org.apache.commons.collections (60) 
 http://localhost:58498/system/console/bundles/60
 org.apache.commons.collections.keyvalue,version=3.2.1 from 
 org.apache.commons.collections (60) 
 http://localhost:58498/system/console/bundles/60
 org.apache.commons.collections.list,version=3.2.1 from 
 org.apache.commons.collections (60) 
 http://localhost:58498/system/console/bundles/60
 org.apache.commons.collections.set,version=3.2.1 from 
 org.apache.commons.collections (60) 
 http://localhost:58498/system/console/bundles/60
 org.apache.commons.lang,version=2.6.0 from org.apache.commons.lang (64) 
 http://localhost:58498/system/console/bundles/64
 org.apache.commons.logging,version=1.1.1 from jcl.over.slf4j (1) 
 http://localhost:58498/system/console/bundles/1
 org.apache.sling.api,version=2.3.0 from org.apache.sling.api (71) 
 http://localhost:58498/system/console/bundles/71
 org.apache.sling.api.adapter,version=2.2.0 from org.apache.sling.api (71) 
 http://localhost:58498/system/console/bundles/71
 org.apache.sling.api.resource,version=2.6.0 from org.apache.sling.api (71) 
 http://localhost

Re: Review Request 28758: @AdapterReference annotation prototype

2014-12-10 Thread Konrad Windszus

Does this already refer to a specific Sling issue? Was it an alternative 
solution for the problem listed in 
https://issues.apache.org/jira/browse/SLING-4217? 
https://issues.apache.org/jira/browse/SLING-4217?
Sorry, I may have missed the point here.
Thanks for any clarification,
Konrad

 On 05 Dec 2014, at 21:03, Felix Meschberger fmesc...@apache.org wrote:
 
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/28758/
 ---
 
 Review request for sling.
 
 
 Summary (updated)
 -
 
 @AdapterReference annotation prototype
 
 
 Repository: sling
 
 
 Description (updated)
 ---
 
 SLING-4217 - Register OSGi services corresponding to available adapter 
 factories
 
 
 Diffs (updated)
 -
 
  bundles/extensions/adapter/pom.xml 1643271 
  
 bundles/extensions/adapter/src/main/java/org/apache/sling/adapter/ds/AdapterReference.java
  PRE-CREATION 
  
 bundles/extensions/adapter/src/main/java/org/apache/sling/adapter/ds/AdapterReferenceAnnotationProcessor.java
  PRE-CREATION 
  
 bundles/extensions/adapter/src/main/resources/META-INF/services/org.apache.felix.scrplugin.annotations.AnnotationProcessor
  PRE-CREATION 
 
 Diff: https://reviews.apache.org/r/28758/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 Felix Meschberger

Whitespace handling in Sightly

2014-12-11 Thread Konrad Windszus

Hi,
since JSP 2.1 it is possible to remove extra whitespace characters from the 
generated servlet by leveraging the trim-directive-whitespaces element on the 
page directive (JSP 2.1 Spec, $JSP.3.3.8). Does Sightly comes with something 
similar?
One example which leads to unwanted empty lines is like

link data-sly-call=“templatea data-sly-test.condition=“${true} 
data-sly-unwrap/link
link data-sly-call=“templateb data-sly-test=${!condition} 
data-sly-unwrap/link

Since either the first or second template is called you would end up with one 
empty newline (which is not wanted).

Maybe data-sly-unwrap should also remove the line break from the output?
WDYT?

Konrad

Re: JSR305

2015-02-05 Thread Konrad Windszus

I created https://issues.apache.org/jira/browse/SLING-4377 
https://issues.apache.org/jira/browse/SLING-4377 to track that.
But I just faced another problem:
I can make Eclipse only understand one type of nullable annotation: So either 
@Nullable or @CheckForNull.
The problem now is, that I would need to rely on both for Findbugs if I also 
want to leverage the @ParametersAreNonNullByDefault. I opened the bug 
https://sourceforge.net/p/findbugs/bugs/1355/ 
https://sourceforge.net/p/findbugs/bugs/1355/ about this different behaviour 
between Eclipse and Windbags

In Oak Solr this was solved by not using the class/package annotation 
@ParametersAreNonNullByDefault. But that way writing the annotations is quite 
verbose, because in most of the cases, parameters are not supposed to be null!
I would need to annotate all of those with @NonNull (because @Nullable is the 
default then!)

Do you have any other idea how to deal with that except for limiting oneself to 
only @CheckForNull and @NonNull?

Thanks a lot for any input on that
Konrad


 On 02 Feb 2015, at 09:10, Konrad Windszus konra...@gmx.de wrote:
 
 Indeed Eclipse supports configurable annotations. You can find the 
 information at 
 http://help.eclipse.org/juno/index.jsp?topic=%2Forg.eclipse.jdt.doc.user%2Freference%2Fpreferences%2Fjava%2Fcompiler%2Fref-preferences-errors-warnings.htmanchor=null_annotation_names
  
 http://help.eclipse.org/juno/index.jsp?topic=/org.eclipse.jdt.doc.user/reference/preferences/java/compiler/ref-preferences-errors-warnings.htmanchor=null_annotation_names.
  Therefore it will probably make sense to use the JSR305 annotations.
 I will create a feature branch where I will add those annotations for Sling 
 API as well as Sling Models and Sling Validation.
 Thanks for your input.
 
 On 30 Jan 2015, at 13:59, Robert Munteanu rob...@lmn.ro 
 mailto:rob...@lmn.ro wrote:
 
 On Fri, Jan 30, 2015 at 2:55 PM, Konrad Windszus konra...@gmx.de 
 mailto:konra...@gmx.de wrote:
 The question for me is whether we should rely on the dormant standard 
 (which did never release anything officially) 305, because that is not 
 supported by Eclipse or whether we should use something else?
 Any ideas, opinions on that?
 What is your experience with the JSR305 javax.annotation support in major 
 IDEs (see also 
 http://stackoverflow.com/questions/4963300/which-notnull-java-annotation-should-i-use
  
 http://stackoverflow.com/questions/4963300/which-notnull-java-annotation-should-i-use
  
 http://stackoverflow.com/questions/4963300/which-notnull-java-annotation-should-i-use
  
 http://stackoverflow.com/questions/4963300/which-notnull-java-annotation-should-i-use)?
 
 AFAIR for Eclipse you can configure the annotation types to use ( see
 [1] ) . But of course we'd need to validate this before starting
 conversions.
 
 Robert
 
 
 [1]: 
 http://help.eclipse.org/luna/index.jsp?topic=%2Forg.eclipse.jdt.doc.user%2Ftasks%2Ftask-using_null_annotations.htm
  
 http://help.eclipse.org/luna/index.jsp?topic=%2Forg.eclipse.jdt.doc.user%2Ftasks%2Ftask-using_null_annotations.htm
 
 Konrad
 
 On 30 Jan 2015, at 13:37, Robert Munteanu romb...@apache.org 
 mailto:romb...@apache.org wrote:
 
 On Fri, Jan 30, 2015 at 2:15 PM, Konrad Windszus konra...@gmx.de 
 mailto:konra...@gmx.de wrote:
 What about adding annotations like 
 https://code.google.com/p/jsr-305/source/browse/trunk/ri/src/main/java/javax/annotation/CheckForNull.java
  
 https://code.google.com/p/jsr-305/source/browse/trunk/ri/src/main/java/javax/annotation/CheckForNull.java
  
 https://code.google.com/p/jsr-305/source/browse/trunk/ri/src/main/java/javax/annotation/CheckForNull.java
  
 https://code.google.com/p/jsr-305/source/browse/trunk/ri/src/main/java/javax/annotation/CheckForNull.java
  to the Sling API?
 
 +1
 
 I wonder if there is a static analyser which can fail the build when
 violations are found, e.g. immediately dereferencing the result of a
 method which is @Nullable.
 
 Robert
 
 
 
 
 -- 
 Sent from my (old) computer

Sightly Integration Test execution fails for me

2015-02-19 Thread Konrad Windszus

I just tried to execute the Sightly Integration Tests and I get the following 
error:

...
Tests run: 336, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 3.994 sec  
FAILURE! - in io.sightly.tck.TestsRunner
String Expressions: String quotes and escaping - 
#unicode_escape(io.sightly.tck.tests.TestBuilder$1)  Time elapsed: 0.007 sec  
 FAILURE!
junit.framework.AssertionFailedError: Expected value 'This 'Atilde;' is a 
string with unicode escaping' for selector '#unicode_escape'. Instead we got 
'This '??' is a string with unicode escaping'. Please check the expected markup 
from /testfiles/output/exprlang/strings.html.
at junit.framework.Assert.fail(Assert.java:47)
at junit.framework.Assert.assertTrue(Assert.java:20)
at io.sightly.tck.tests.TestBuilder$1.runTest(TestBuilder.java:146)


Results :

Failed tests: 
  TestBuilder$1.runTest:146 Expected value 'This 'Atilde;' is a string with 
unicode escaping' for selector '#unicode_escape'. Instead we got 'This '??' is 
a string with unicode escaping'. Please check the expected markup from 
/testfiles/output/exprlang/strings.html.

Tests run: 340, Failures: 1, Errors: 0, Skipped: 0
...

This happens with the most recent trunk and I just recompiled the XSS module on 
my own before that.

I am using JDK 1.7.0_55 on a Mac.

Any ideas what might be wrong?
Is the code relying on the default encoding maybe?


Thanks,
Konrad

Re: Sightly Integration Test execution fails for me

2015-02-19 Thread Konrad Windszus

Hi Radu,
I use UTF-8 as default encoding as well.
The issue only occurs when using it with JDK 1.7.0_55. Using JDK 1.7.0_60 or 
later solves the issue. So it is probably related to one issue being fixed in 
1.7.0_60: 
http://www.oracle.com/technetwork/java/javase/2col/7u60-bugfixes-2202029.html 
http://www.oracle.com/technetwork/java/javase/2col/7u60-bugfixes-2202029.html
Konrad


 On 20 Feb 2015, at 02:33, Radu Cotescu r...@cotescu.com wrote:
 
 Hi Konrad,
 
 The code does indeed rely on the default platform encoding. However, on my
 Mac, the default encoding is UTF-8.
 
 mvn -version
 Apache Maven 3.2.5 (12a6b3acb947671f09b81f49094c53f426d8cea1;
 2014-12-14T09:29:23-08:00)
 Maven home: /usr/local/Cellar/maven/3.2.5/libexec
 Java version: 1.7.0_67, vendor: Oracle Corporation
 Java home:
 /Library/Java/JavaVirtualMachines/jdk1.7.0_67.jdk/Contents/Home/jre
 Default locale: en_US, platform encoding: UTF-8
 OS name: mac os x, version: 10.10.2, arch: x86_64, family: mac
 
 Is the encoding different on your box?
 
 Regards,
 Radu
 
 On Thu, Feb 19, 2015 at 4:13 AM, Konrad Windszus konra...@gmx.de wrote:
 
 I just tried to execute the Sightly Integration Tests and I get the
 following error:
 
 ...
 Tests run: 336, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 3.994
 sec  FAILURE! - in io.sightly.tck.TestsRunner
 String Expressions: String quotes and escaping -
 #unicode_escape(io.sightly.tck.tests.TestBuilder$1)  Time elapsed: 0.007
 sec   FAILURE!
 junit.framework.AssertionFailedError: Expected value 'This 'Atilde;' is a
 string with unicode escaping' for selector '#unicode_escape'. Instead we
 got 'This '??' is a string with unicode escaping'. Please check the
 expected markup from /testfiles/output/exprlang/strings.html.
at junit.framework.Assert.fail(Assert.java:47)
at junit.framework.Assert.assertTrue(Assert.java:20)
at io.sightly.tck.tests.TestBuilder$1.runTest(TestBuilder.java:146)
 
 
 Results :
 
 Failed tests:
  TestBuilder$1.runTest:146 Expected value 'This 'Atilde;' is a string
 with unicode escaping' for selector '#unicode_escape'. Instead we got 'This
 '??' is a string with unicode escaping'. Please check the expected markup
 from /testfiles/output/exprlang/strings.html.
 
 Tests run: 340, Failures: 1, Errors: 0, Skipped: 0
 ...
 
 This happens with the most recent trunk and I just recompiled the XSS
 module on my own before that.
 
 I am using JDK 1.7.0_55 on a Mac.
 
 Any ideas what might be wrong?
 Is the code relying on the default encoding maybe?
 
 
 Thanks,
 Konrad

Re: JSR305

2015-02-02 Thread Konrad Windszus

Indeed Eclipse supports configurable annotations. You can find the information 
at 
http://help.eclipse.org/juno/index.jsp?topic=%2Forg.eclipse.jdt.doc.user%2Freference%2Fpreferences%2Fjava%2Fcompiler%2Fref-preferences-errors-warnings.htmanchor=null_annotation_names
 
http://help.eclipse.org/juno/index.jsp?topic=/org.eclipse.jdt.doc.user/reference/preferences/java/compiler/ref-preferences-errors-warnings.htmanchor=null_annotation_names.
 Therefore it will probably make sense to use the JSR305 annotations.
I will create a feature branch where I will add those annotations for Sling API 
as well as Sling Models and Sling Validation.
Thanks for your input.

 On 30 Jan 2015, at 13:59, Robert Munteanu rob...@lmn.ro wrote:
 
 On Fri, Jan 30, 2015 at 2:55 PM, Konrad Windszus konra...@gmx.de 
 mailto:konra...@gmx.de wrote:
 The question for me is whether we should rely on the dormant standard (which 
 did never release anything officially) 305, because that is not supported by 
 Eclipse or whether we should use something else?
 Any ideas, opinions on that?
 What is your experience with the JSR305 javax.annotation support in major 
 IDEs (see also 
 http://stackoverflow.com/questions/4963300/which-notnull-java-annotation-should-i-use
  
 http://stackoverflow.com/questions/4963300/which-notnull-java-annotation-should-i-use
  
 http://stackoverflow.com/questions/4963300/which-notnull-java-annotation-should-i-use
  
 http://stackoverflow.com/questions/4963300/which-notnull-java-annotation-should-i-use)?
 
 AFAIR for Eclipse you can configure the annotation types to use ( see
 [1] ) . But of course we'd need to validate this before starting
 conversions.
 
 Robert
 
 
 [1]: 
 http://help.eclipse.org/luna/index.jsp?topic=%2Forg.eclipse.jdt.doc.user%2Ftasks%2Ftask-using_null_annotations.htm
  
 http://help.eclipse.org/luna/index.jsp?topic=%2Forg.eclipse.jdt.doc.user%2Ftasks%2Ftask-using_null_annotations.htm
 
 Konrad
 
 On 30 Jan 2015, at 13:37, Robert Munteanu romb...@apache.org wrote:
 
 On Fri, Jan 30, 2015 at 2:15 PM, Konrad Windszus konra...@gmx.de wrote:
 What about adding annotations like 
 https://code.google.com/p/jsr-305/source/browse/trunk/ri/src/main/java/javax/annotation/CheckForNull.java
  
 https://code.google.com/p/jsr-305/source/browse/trunk/ri/src/main/java/javax/annotation/CheckForNull.java
  to the Sling API?
 
 +1
 
 I wonder if there is a static analyser which can fail the build when
 violations are found, e.g. immediately dereferencing the result of a
 method which is @Nullable.
 
 Robert
 
 
 
 
 -- 
 Sent from my (old) computer

Re: JSR305

2015-02-05 Thread Konrad Windszus

Hi Thommaso,
thanks for your input.
I observed that Oak is using both @Nullable and @CheckForNull. What is the 
reason why you use both?
I would assume that all tools implicitly assume @Nullable in case no annotation 
is set, and as I already explained, Eclipse can only be configured to either 
understand
@Nullable or @CheckForNull. 

Could you enlighten me, why you don’t leave out the @Nullable for parameters at 
all?
Is this only to make implementors of that Interface aware of that fact? Or is 
it giving any additional value for semantic code checks (e.g. for Findbugs?)

Thanks,
Konrad


 On 05 Feb 2015, at 11:34, Tommaso Teofili tommaso.teof...@gmail.com wrote:
 
 2015-02-05 9:59 GMT+01:00 Konrad Windszus konra...@gmx.de:
 
 I created https://issues.apache.org/jira/browse/SLING-4377 
 https://issues.apache.org/jira/browse/SLING-4377 to track that.
 But I just faced another problem:
 I can make Eclipse only understand one type of nullable annotation: So
 either @Nullable or @CheckForNull.
 The problem now is, that I would need to rely on both for Findbugs if I
 also want to leverage the @ParametersAreNonNullByDefault. I opened the bug
 https://sourceforge.net/p/findbugs/bugs/1355/ 
 https://sourceforge.net/p/findbugs/bugs/1355/ about this different
 behaviour between Eclipse and Windbags
 
 In Oak Solr this was solved by not using the class/package annotation
 @ParametersAreNonNullByDefault. But that way writing the annotations is
 quite verbose, because in most of the cases, parameters are not supposed to
 be null!
 I would need to annotate all of those with @NonNull (because @Nullable is
 the default then!)
 
 
 actually it's like that for Oak generally, not just for Oak Solr; apart
 from that the side effect of what you noticed is, in my experience, not so
 negative: meaning that your IDE (Eclipse, IDEA do it IIRC) will suggest you
 to add the relevant annotations also to the implementors of a certain API
 to avoid seeing warnings, which in the end leads to a better awareness of
 the contract to who's writing such an API implementation ending up with
 annotating also the implementation methods with the right one
 (@CheckForNull or @Nullable).
 
 My 2 cents,
 Tommaso
 
 
 
 Do you have any other idea how to deal with that except for limiting
 oneself to only @CheckForNull and @NonNull?
 
 Thanks a lot for any input on that
 Konrad
 
 
 On 02 Feb 2015, at 09:10, Konrad Windszus konra...@gmx.de wrote:
 
 Indeed Eclipse supports configurable annotations. You can find the
 information at
 http://help.eclipse.org/juno/index.jsp?topic=%2Forg.eclipse.jdt.doc.user%2Freference%2Fpreferences%2Fjava%2Fcompiler%2Fref-preferences-errors-warnings.htmanchor=null_annotation_names
 
 http://help.eclipse.org/juno/index.jsp?topic=/org.eclipse.jdt.doc.user/reference/preferences/java/compiler/ref-preferences-errors-warnings.htmanchor=null_annotation_names.
 Therefore it will probably make sense to use the JSR305 annotations.
 I will create a feature branch where I will add those annotations for
 Sling API as well as Sling Models and Sling Validation.
 Thanks for your input.
 
 On 30 Jan 2015, at 13:59, Robert Munteanu rob...@lmn.ro mailto:
 rob...@lmn.ro wrote:
 
 On Fri, Jan 30, 2015 at 2:55 PM, Konrad Windszus konra...@gmx.de
 mailto:konra...@gmx.de wrote:
 The question for me is whether we should rely on the dormant standard
 (which did never release anything officially) 305, because that is not
 supported by Eclipse or whether we should use something else?
 Any ideas, opinions on that?
 What is your experience with the JSR305 javax.annotation support in
 major IDEs (see also
 http://stackoverflow.com/questions/4963300/which-notnull-java-annotation-should-i-use
 
 http://stackoverflow.com/questions/4963300/which-notnull-java-annotation-should-i-use
 
 http://stackoverflow.com/questions/4963300/which-notnull-java-annotation-should-i-use
 
 http://stackoverflow.com/questions/4963300/which-notnull-java-annotation-should-i-use
 )?
 
 AFAIR for Eclipse you can configure the annotation types to use ( see
 [1] ) . But of course we'd need to validate this before starting
 conversions.
 
 Robert
 
 
 [1]:
 http://help.eclipse.org/luna/index.jsp?topic=%2Forg.eclipse.jdt.doc.user%2Ftasks%2Ftask-using_null_annotations.htm
 
 http://help.eclipse.org/luna/index.jsp?topic=%2Forg.eclipse.jdt.doc.user%2Ftasks%2Ftask-using_null_annotations.htm
 
 
 Konrad
 
 On 30 Jan 2015, at 13:37, Robert Munteanu romb...@apache.org
 mailto:romb...@apache.org wrote:
 
 On Fri, Jan 30, 2015 at 2:15 PM, Konrad Windszus konra...@gmx.de
 mailto:konra...@gmx.de wrote:
 What about adding annotations like
 https://code.google.com/p/jsr-305/source/browse/trunk/ri/src/main/java/javax/annotation/CheckForNull.java
 
 https://code.google.com/p/jsr-305/source/browse/trunk/ri/src/main/java/javax/annotation/CheckForNull.java
 
 https://code.google.com/p/jsr-305/source/browse/trunk/ri/src/main/java/javax/annotation/CheckForNull.java
 
 https://code.google.com/p/jsr

Re: Redirect to arbitrary host via the Sling Post Servlet

2015-03-03 Thread Konrad Windszus

Great, I provided a patch in https://issues.apache.org/jira/browse/SLING-4469 
https://issues.apache.org/jira/browse/SLING-4469.
Would you mind having a look at that?
Thanks,
Konrad

 On 03 Mar 2015, at 08:01, Antonio Sanso asa...@adobe.com wrote:
 
 hi Konrad
 On Mar 2, 2015, at 5:55 PM, Konrad Windszus konra...@gmx.de wrote:
 
 Hi,
 
 in https://issues.apache.org/jira/browse/SLING-3141 
 https://issues.apache.org/jira/browse/SLING-3141 there was an issue fixed 
 which made it possible to redirect from a Sling instance to another server 
 with a forged GET-request (although there was a hop in the middle necessary 
 which was the Login Form being provided by Sling).
 
 Currently the Sling Post Servlet 
 (https://github.com/apache/sling/blob/trunk/bundles/servlets/post/src/main/java/org/apache/sling/servlets/post/impl/SlingPostServlet.java#L305
  
 https://github.com/apache/sling/blob/trunk/bundles/servlets/post/src/main/java/org/apache/sling/servlets/post/impl/SlingPostServlet.java#L305)
  does not validate the value being passed for parameter :redirect 
 (http://sling.apache.org/documentation/bundles/manipulating-content-the-slingpostservlet-servlets-post.html#redirect
  
 http://sling.apache.org/documentation/bundles/manipulating-content-the-slingpostservlet-servlets-post.html#redirect).
  Although I think it can only be exploited similarly to SLING-3141 in case 
 there is vulnerability also in the script rendering the form, it should 
 still not be allowed to pass arbitrary hosts IMHO. I think the same 
 restrictions as for resources in the Sling Authenticators make sense here. 
 For that we could leverage the method AuthUtil.isRedirectValid 
 (https://github.com/apache/sling/blob/trunk/bundles/auth/core/src/main/java/org/apache/sling/auth/core/AuthUtil.java#L451
  
 https://github.com/apache/sling/blob/trunk/bundles/auth/core/src/main/java/org/apache/sling/auth/core/AuthUtil.java#L451),
  although one probably needs to move that method somewhere else to prevent a 
 direct dependency from Sling Servlets Post Bundle to the Sling Auth Core 
 Bundle 
 
 WDYT?
 
 In case you agree I would create a JIRA issue for that and try to come up 
 with a fix.
 
 it sounds like a plan :)
 
 regards
 
 antonio
 
 Thanks,
 Konrad

Re: Downloads page returning 500 Internal Server Error?

2015-03-02 Thread Konrad Windszus

Maybe that was me. I just noticed that the URL to the Sling IDE always 
contained two slashes (because the variable “preferred always ends with a 
slash). Therefore I changed in the downloads.html from 

pIf you want to install the convenience binaries for the IDE tooling, it's 
recommended that you add a 
href=[preferred]/sling/eclipse[preferred]/sling/eclipse/a as an update 
site URL. This way you will receive updates every time a new version is 
released. For specific versions and zipped update site download, see the table 
below./p
to 
pIf you want to install the convenience binaries for the IDE tooling, it's 
recommended that you add a 
href=[preferred]sling/eclipse[preferred]/sling/eclipse/a as an update site 
URL. This way you will receive updates every time a new version is released. 
For specific versions and zipped update site download, see the table below./p

May that have caused the issue?
Konrad


 On 02 Mar 2015, at 15:13, Robert Munteanu romb...@apache.org wrote:
 
 Hi,
 
 I keep getting 500 Internal Server Error from
 http://sling.apache.org/downloads.cgi . Is it just me ?
 
 Robert

Redirect to arbitrary host via the Sling Post Servlet

2015-03-02 Thread Konrad Windszus

Hi,

in https://issues.apache.org/jira/browse/SLING-3141 
https://issues.apache.org/jira/browse/SLING-3141 there was an issue fixed 
which made it possible to redirect from a Sling instance to another server with 
a forged GET-request (although there was a hop in the middle necessary which 
was the Login Form being provided by Sling).

Currently the Sling Post Servlet 
(https://github.com/apache/sling/blob/trunk/bundles/servlets/post/src/main/java/org/apache/sling/servlets/post/impl/SlingPostServlet.java#L305
 
https://github.com/apache/sling/blob/trunk/bundles/servlets/post/src/main/java/org/apache/sling/servlets/post/impl/SlingPostServlet.java#L305)
 does not validate the value being passed for parameter :redirect 
(http://sling.apache.org/documentation/bundles/manipulating-content-the-slingpostservlet-servlets-post.html#redirect
 
http://sling.apache.org/documentation/bundles/manipulating-content-the-slingpostservlet-servlets-post.html#redirect).
 Although I think it can only be exploited similarly to SLING-3141 in case 
there is vulnerability also in the script rendering the form, it should still 
not be allowed to pass arbitrary hosts IMHO. I think the same restrictions as 
for resources in the Sling Authenticators make sense here. For that we could 
leverage the method AuthUtil.isRedirectValid 
(https://github.com/apache/sling/blob/trunk/bundles/auth/core/src/main/java/org/apache/sling/auth/core/AuthUtil.java#L451
 
https://github.com/apache/sling/blob/trunk/bundles/auth/core/src/main/java/org/apache/sling/auth/core/AuthUtil.java#L451),
 although one probably needs to move that method somewhere else to prevent a 
direct dependency from Sling Servlets Post Bundle to the Sling Auth Core Bundle 

WDYT?

In case you agree I would create a JIRA issue for that and try to come up with 
a fix.
Thanks,
Konrad

Re: [VOTE] Release Apache Sling API version 2.9.0

2015-02-23 Thread Konrad Windszus

Yes, my vote is non-binding. I will add that in the future whenever I vote.

 On 23 Feb 2015, at 11:17, Robert Munteanu romb...@apache.org wrote:
 
 On Feb 23, 2015 12:15 PM, Tomek Rękawek tomasz.reka...@cognifide.com
 wrote:
 
 On Mon, Feb 23, 2015 at 10:35 AM, Konrad Windszus konra...@gmx.de wrote:
 
 +1
 
 
 Thanks Konrad! I didn't find it anywhere in the Sling documentation, but I
 think that only the PMC members have binding votes, so we need one more
 PMC
 member to vote.
 
 That's correct, only PMC votes are binding.
 
 Robert
 
 Regards,
 Tomek
 
 --
 Tomek Rękawek
 Senior Software Engineer
 
 Cognifide Polska Sp. z o.o.
 skype: trekawek
 
 www.cognifide.com

Re: [VOTE] Release Apache Sling API version 2.9.0

2015-02-23 Thread Konrad Windszus

+1

Konrad

 On 20 Feb 2015, at 11:25, Robert Munteanu romb...@apache.org wrote:
 
 +1
 
 Robert
 
 On Fri, Feb 20, 2015 at 12:09 PM, Robert Munteanu romb...@apache.org wrote:
 On Fri, Feb 20, 2015 at 12:04 PM, Tomek Rękawek
 tomasz.reka...@cognifide.com wrote:
 Hello Robert,
 
 On Fri, Feb 20, 2015 at 10:13 AM, Robert Munteanu rob...@lmn.ro wrote:
 
 I think you should cancel this vote and start a new one, please see [1]
 
 
 I thought about this, but I don't think there is a need to rollback changes
 in the SVN, as they are not affected by the GPG key. The only place
 affected by my invalid key was Nexus staging, which I removed and deployed
 again, with the correct signature. I can repeat the whole process, but the
 final result (in terms of contents of the SVN and Nexus staging) will be
 the same as there is right now.
 
 Yup, makes sense.
 
 Thanks,
 
 Robert
 
 
 Also, Carsten gave his +1 :)
 
 Regards,
 Tomek
 
 --
 Tomek Rękawek
 Senior Software Engineer
 
 Cognifide Polska Sp. z o.o.
 skype: trekawek
 
 www.cognifide.com

Fwd: svn commit: r1662434 - in /sling/trunk/bundles/extensions/models/impl: pom.xml src/main/java/org/apache/sling/models/impl/sightly/ src/main/java/org/apache/sling/models/impl/sightly/ModelFactoryU

2015-02-26 Thread Konrad Windszus

Unfortunately the build still fails 
(https://builds.apache.org/job/sling-trunk-1.6/3114/console):

…
[INFO] 
[INFO] Building Apache Sling Models Implementation 1.1.1-SNAPSHOT
[INFO] 
Downloading: 
http://repository.apache.org/snapshots/org/apache/sling/org.apache.sling.scripting.sightly/1.0.0-SNAPSHOT/org.apache.sling.scripting.sightly-1.0.0-SNAPSHOT.pom
[WARNING] The POM for 
org.apache.sling:org.apache.sling.scripting.sightly:jar:1.0.0-SNAPSHOT is 
missing, no dependency information available

Downloading: 
http://repository.apache.org/snapshots/org/apache/sling/org.apache.sling.scripting.sightly/1.0.0-SNAPSHOT/org.apache.sling.scripting.sightly-1.0.0-SNAPSHOT.jar
…

Any idea why this still happens?
I uploaded the Sightly Snapshots and they seem to be there now 
(http://repository.apache.org/snapshots/org/apache/sling/org.apache.sling.scripting.sightly/1.0.0-SNAPSHOT/).
The only problem I see is that they are requested through this URL: 
http://repository.apache.org/snapshots/org/apache/sling/org.apache.sling.scripting.sightly/1.0.0-SNAPSHOT/org.apache.sling.scripting.sightly-1.0.0-SNAPSHOT.pom,
 but they are uploaded with the unique versions timestamp. Usually Nexus takes 
care of that and also the maven-metadata.xml at 
https://repository.apache.org/content/groups/snapshots/org/apache/sling/org.apache.sling.scripting.sightly/1.0.0-SNAPSHOT/maven-metadata.xml
 looks correct to me.
Konrad


 Begin forwarded message:
 
 Reply-To: dev@sling.apache.org
 Subject: Re: svn commit: r1662434 - in 
 /sling/trunk/bundles/extensions/models/impl: pom.xml 
 src/main/java/org/apache/sling/models/impl/sightly/ 
 src/main/java/org/apache/sling/models/impl/sightly/ModelFactoryUseProvider.java
 From: Konrad Windszus konra...@gmx.de
 Date: 26 Feb 2015 14:59:38 CET
 To: dev@sling.apache.org
 
 I just deployed Sightly SNAPSHOTs to the Apache Snapshots repository. The 
 next build should not longer fail due to this.
 Regarding moving the Sling Models UseProvider to its own bundle I would like 
 to hear other opinions on that. For me that one class does not necessarily 
 call for a dedicated bundle.
 Is it in general not allowed to have dependencies from the main build towards 
 the contrib section?
 Are there any plans on moving Sightly to the main build?
 Thanks for your input on that,
 Konrad
 
 On 26 Feb 2015, at 14:37, Konrad Windszus konra...@gmx.de wrote:
 
 Hi Robert,
 yes, I just noticed that.
 Since this is an optional dependency I would rather argue that this should 
 be fine. 
 Can you for now push the sightly SNAPSHOT release since I am having 
 difficulties to build that due to issue with the Company Maven repo?
 Once we do have a Sightly release that should no longer be a problem.
 Konrad
 
 
 
 
 On 26 Feb 2015, at 14:34, Robert Munteanu romb...@apache.org wrote:
 
 Hi Konrad,
 
 On Thu, 2015-02-26 at 12:27 +, k...@apache.org wrote:
 Modified: sling/trunk/bundles/extensions/models/impl/pom.xml
 URL: 
 http://svn.apache.org/viewvc/sling/trunk/bundles/extensions/models/impl/pom.xml?rev=1662434r1=1662433r2=1662434view=diff
 ==
 --- sling/trunk/bundles/extensions/models/impl/pom.xml (original)
 +++ sling/trunk/bundles/extensions/models/impl/pom.xml Thu Feb 26 12:27:25 
 2015
 @@ -146,5 +146,19 @@
   scopeprovided/scope
   optionaltrue/optional
   /dependency
 +dependency
 +groupIdorg.apache.sling/groupId
 +artifactIdorg.apache.sling.scripting.sightly/artifactId
 +version1.0.0-SNAPSHOT/version
 +scopeprovided/scope
 +optionaltrue/optional
 +/dependency
 +dependency
 +groupIdorg.apache.sling/groupId
 +artifactIdorg.apache.sling.commons.classloader/artifactId
 +version1.3.0/version
 +scopeprovided/scope
 +optionaltrue/optional
 +/dependency
   /dependencies
 /project
 
 (snip)
 
 This breaks the main build, since it can't find a sightly SNAPSHOT in
 its reactor or on a repo. We could do a quick fix and deploy a sightly
 SNAPSHOT but the question is whether this is the right thing to do.
 
 Since models is in bundles/extensions ( i.e. in the main build ) and
 sightly in contrib I would argue that it's not right to place such
 dependencies, and I would rather see an addon in contrib which provides
 this functionality.
 
 WDYT?
 
 Cheers,
 
 Robert

Re: svn commit: r1662434 - in /sling/trunk/bundles/extensions/models/impl: pom.xml src/main/java/org/apache/sling/models/impl/sightly/ src/main/java/org/apache/sling/models/impl/sightly/ModelFactoryUs

2015-02-26 Thread Konrad Windszus

Hi Robert,
yes, I just noticed that.
Since this is an optional dependency I would rather argue that this should be 
fine. 
Can you for now push the sightly SNAPSHOT release since I am having 
difficulties to build that due to issue with the Company Maven repo?
Once we do have a Sightly release that should no longer be a problem.
Konrad




 On 26 Feb 2015, at 14:34, Robert Munteanu romb...@apache.org wrote:
 
 Hi Konrad,
 
 On Thu, 2015-02-26 at 12:27 +, k...@apache.org wrote:
 Modified: sling/trunk/bundles/extensions/models/impl/pom.xml
 URL: 
 http://svn.apache.org/viewvc/sling/trunk/bundles/extensions/models/impl/pom.xml?rev=1662434r1=1662433r2=1662434view=diff
 ==
 --- sling/trunk/bundles/extensions/models/impl/pom.xml (original)
 +++ sling/trunk/bundles/extensions/models/impl/pom.xml Thu Feb 26 12:27:25 
 2015
 @@ -146,5 +146,19 @@
 scopeprovided/scope
 optionaltrue/optional
 /dependency
 +dependency
 +groupIdorg.apache.sling/groupId
 +artifactIdorg.apache.sling.scripting.sightly/artifactId
 +version1.0.0-SNAPSHOT/version
 +scopeprovided/scope
 +optionaltrue/optional
 +/dependency
 +dependency
 +groupIdorg.apache.sling/groupId
 +artifactIdorg.apache.sling.commons.classloader/artifactId
 +version1.3.0/version
 +scopeprovided/scope
 +optionaltrue/optional
 +/dependency
 /dependencies
 /project
 
 (snip)
 
 This breaks the main build, since it can't find a sightly SNAPSHOT in
 its reactor or on a repo. We could do a quick fix and deploy a sightly
 SNAPSHOT but the question is whether this is the right thing to do.
 
 Since models is in bundles/extensions ( i.e. in the main build ) and
 sightly in contrib I would argue that it's not right to place such
 dependencies, and I would rather see an addon in contrib which provides
 this functionality.
 
 WDYT?
 
 Cheers,
 
 Robert

Re: svn commit: r1662434 - in /sling/trunk/bundles/extensions/models/impl: pom.xml src/main/java/org/apache/sling/models/impl/sightly/ src/main/java/org/apache/sling/models/impl/sightly/ModelFactoryUs

2015-02-26 Thread Konrad Windszus

I just deployed Sightly SNAPSHOTs to the Apache Snapshots repository. The next 
build should not longer fail due to this.
Regarding moving the Sling Models UseProvider to its own bundle I would like to 
hear other opinions on that. For me that one class does not necessarily call 
for a dedicated bundle.
Is it in general not allowed to have dependencies from the main build towards 
the contrib section?
Are there any plans on moving Sightly to the main build?
Thanks for your input on that,
Konrad

 On 26 Feb 2015, at 14:37, Konrad Windszus konra...@gmx.de wrote:
 
 Hi Robert,
 yes, I just noticed that.
 Since this is an optional dependency I would rather argue that this should be 
 fine. 
 Can you for now push the sightly SNAPSHOT release since I am having 
 difficulties to build that due to issue with the Company Maven repo?
 Once we do have a Sightly release that should no longer be a problem.
 Konrad
 
 
 
 
 On 26 Feb 2015, at 14:34, Robert Munteanu romb...@apache.org wrote:
 
 Hi Konrad,
 
 On Thu, 2015-02-26 at 12:27 +, k...@apache.org wrote:
 Modified: sling/trunk/bundles/extensions/models/impl/pom.xml
 URL: 
 http://svn.apache.org/viewvc/sling/trunk/bundles/extensions/models/impl/pom.xml?rev=1662434r1=1662433r2=1662434view=diff
 ==
 --- sling/trunk/bundles/extensions/models/impl/pom.xml (original)
 +++ sling/trunk/bundles/extensions/models/impl/pom.xml Thu Feb 26 12:27:25 
 2015
 @@ -146,5 +146,19 @@
scopeprovided/scope
optionaltrue/optional
/dependency
 +dependency
 +groupIdorg.apache.sling/groupId
 +artifactIdorg.apache.sling.scripting.sightly/artifactId
 +version1.0.0-SNAPSHOT/version
 +scopeprovided/scope
 +optionaltrue/optional
 +/dependency
 +dependency
 +groupIdorg.apache.sling/groupId
 +artifactIdorg.apache.sling.commons.classloader/artifactId
 +version1.3.0/version
 +scopeprovided/scope
 +optionaltrue/optional
 +/dependency
/dependencies
 /project
 
 (snip)
 
 This breaks the main build, since it can't find a sightly SNAPSHOT in
 its reactor or on a repo. We could do a quick fix and deploy a sightly
 SNAPSHOT but the question is whether this is the right thing to do.
 
 Since models is in bundles/extensions ( i.e. in the main build ) and
 sightly in contrib I would argue that it's not right to place such
 dependencies, and I would rather see an addon in contrib which provides
 this functionality.
 
 WDYT?
 
 Cheers,
 
 Robert

Re: JSR305

2015-01-30 Thread Konrad Windszus

The question for me is whether we should rely on the dormant standard (which 
did never release anything officially) 305, because that is not supported by 
Eclipse or whether we should use something else?
Any ideas, opinions on that?
What is your experience with the JSR305 javax.annotation support in major IDEs 
(see also 
http://stackoverflow.com/questions/4963300/which-notnull-java-annotation-should-i-use
 
http://stackoverflow.com/questions/4963300/which-notnull-java-annotation-should-i-use)?
Konrad

 On 30 Jan 2015, at 13:37, Robert Munteanu romb...@apache.org wrote:
 
 On Fri, Jan 30, 2015 at 2:15 PM, Konrad Windszus konra...@gmx.de wrote:
 What about adding annotations like 
 https://code.google.com/p/jsr-305/source/browse/trunk/ri/src/main/java/javax/annotation/CheckForNull.java
  
 https://code.google.com/p/jsr-305/source/browse/trunk/ri/src/main/java/javax/annotation/CheckForNull.java
  to the Sling API?
 
 +1
 
 I wonder if there is a static analyser which can fail the build when
 violations are found, e.g. immediately dereferencing the result of a
 method which is @Nullable.
 
 Robert

Re: Sling IDE Tooling for IntelliJ IDEA

2015-04-23 Thread Konrad Windszus

More or less. You find more information about it in 
https://wiki.eclipse.org/M2E_compatible_maven_plugins#.3Cexecute.2F.3E_mapping.
The SCR Mojo is indeed called from Eclipse.
Maybe you can call that in IntelliJ directly?
Konrad

 Am 23.04.2015 um 18:50 schrieb Andreas Schaefer Sr. schaef...@me.com:
 
 Hi Konrad
 
 Thanks for the quick response.
 
 So Eclipse is running a “Maven Build” for a class whenever it is compiled?
 
 - Andy
 
 On Apr 23, 2015, at 1:55 AM, Konrad Windszus konra...@gmx.de wrote:
 
 Hi Andy,
 regarding 1) I am not aware of any existing effort to port this to IntelliJ. 
 Regarding 2) there is the maven-scr-plugin which was made compatible with 
 m2e (the Maven Eclipse Integration) in 
 https://issues.apache.org/jira/browse/FELIX-3358.
 Basically Eclipse is executing a special maven goal whenever it triggers a 
 compilation which will lead to the modification of the class file (i.e. the 
 bind methods are being added).
 I am not aware though of a similar mechanism in IntelliJ though.
 Hope this information helps,
 Konrad
 
 Am 23.04.2015 um 02:47 schrieb Andreas Schaefer Sr. schaef...@me.com:
 
 Hi
 
 Ruben and I are working on a port of the AEM Sling Tooling for Eclipse to 
 IntelliJ. So I have a few questions:
 
 1) Did anyone already try that? If so is the code available and for which 
 IntelliJ version?
 
 2) Ran into some problems with the HotSwap of code deployed in Sling. It 
 turned out that 'maven-scr-plugin’ (I think) is generating bind and unbind 
 methods for @Reference which are not there with simple class compilation 
 and hence the HotSwap fails. Now Eclipse is working fine and I am wondering 
 if anyone knows what part of Eclipse or the Sling IDE Tooling is doing that.
 
 Cheers - Andy Schaefer

Re: Exporting ServletResolverConstants in org.apache.sling.servlets.resolver

2015-04-24 Thread Konrad Windszus

Hi Dirk,
that class only contains constants. If you reference those constants within 
your own bundle they are usually inlined (i.e. there is no run-time dependency 
to the providing package). Therefore it is totally fine to add that dependency 
to your Maven module and to directly use those constants in your code. In the 
end though (i.e. during run-time) there is no longer a dependency 
(http://blog.bjhargrave.com/2014/04/java-8-bnd-and-references-to-compile.html, 
http://www.javaspecialists.eu/archive/Issue114.html).
Therefore I don’t think there is a need to move this package somewhere else, 
although the package name org.apache.sling.servlets.resolver.internal might be 
confusing.
Cheers,
Konrad

 Am 24.04.2015 um 10:09 schrieb Dirk Rudolph dirk.rudo...@netcentric.biz:
 
 Hi devs,
 
 why is the class ServletResolverConstants in the Apache Sling Servlet 
 Resolver not accessible in an exported package?
 
 I’m currently implementing a SCR component that registers multiple Services 
 based on some configurations shared between them. One of this Services 
 implements javax.servlet.Servlet as a Sling Servlet. Now I was wondering why 
 those constants are not exported, because I think it can be a quite common 
 use case to register services not using SCR (especially the @SlingServlet 
 annotation).
 
 Cheers, 
 
 Dirk Rudolph | Senior Software Engineer
 
 Netcentric AG
 
 M: +41 79 642 37 11
 D: +49 174 966 84 34
 
 dirk.rudo...@netcentric.biz | www.netcentric.biz

Re: Sling IDE Tooling for IntelliJ IDEA

2015-04-23 Thread Konrad Windszus

Hi Andy,
regarding 1) I am not aware of any existing effort to port this to IntelliJ. 
Regarding 2) there is the maven-scr-plugin which was made compatible with m2e 
(the Maven Eclipse Integration) in 
https://issues.apache.org/jira/browse/FELIX-3358.
Basically Eclipse is executing a special maven goal whenever it triggers a 
compilation which will lead to the modification of the class file (i.e. the 
bind methods are being added).
I am not aware though of a similar mechanism in IntelliJ though.
Hope this information helps,
Konrad

 Am 23.04.2015 um 02:47 schrieb Andreas Schaefer Sr. schaef...@me.com:
 
 Hi
 
 Ruben and I are working on a port of the AEM Sling Tooling for Eclipse to 
 IntelliJ. So I have a few questions:
 
 1) Did anyone already try that? If so is the code available and for which 
 IntelliJ version?
 
 2) Ran into some problems with the HotSwap of code deployed in Sling. It 
 turned out that 'maven-scr-plugin’ (I think) is generating bind and unbind 
 methods for @Reference which are not there with simple class compilation and 
 hence the HotSwap fails. Now Eclipse is working fine and I am wondering if 
 anyone knows what part of Eclipse or the Sling IDE Tooling is doing that.
 
 Cheers - Andy Schaefer

Re: Setting parent.relativePath in pom.xml

2015-05-06 Thread Konrad Windszus

+1, more information is also available at 
https://jira.codehaus.org/browse/MNG-4687 and indeed Maven seems to prefer 
local resolution in cases where the relativePath is not set explicitly empty!
Konrad

 Am 06.05.2015 um 15:19 schrieb Robert Munteanu romb...@apache.org:
 
 Hi,
 
 I noticed that we are not consistent in setting parent.relativePath on
 pom.xml files. Some modules set it to the empty value, e.g.
 
parent
groupIdorg.apache.sling/groupId
artifactIdsling/artifactId
version22/version
relativePath /
/parent
 
 while others set it to the relative path of the parent module in the
 SVN checkout
 
parent
groupIdorg.apache.sling/groupId
artifactIdsling/artifactId
version22/version
relativePath../../parent/pom.xml/relativePath
/parent
 
 We also had a query from Sandro on the users@sling [1] which leads me
 to believe that different Maven versions handle this property
 differently. While older versions, like we have on Jenkins, prefer the
 groupId/artifactId/version coordinates defined in the pom, more recent
 versions pick up a pom from the relativePath even if the version does
 not match.
 
 To ensure that we get reproducible builds and since we expect to
 always deploy the parent pom in a Maven repository I propose that we
 should always set the relativePath to be empty.
 
 Thoughts?
 
 Cheers,
 
 Robert
 
 
 [1]: 
 http://sling-users.markmail.org/search/?q=#query:+page:2+mid:qk3ydifmrkyxbxcp+state:results

Re: Validation integration tests fails

2015-04-14 Thread Konrad Windszus

Sorry for that. Should be fixed now.
Konrad

 Am 14.04.2015 um 18:12 schrieb Carsten Ziegeler cziege...@apache.org:
 
 It seems our jenkins jobs fail because of tests in the validation fail
 
 Could someone please look into it?
 
 Thanks
 Carsten
 -- 
 Carsten Ziegeler
 Adobe Research Switzerland
 cziege...@apache.org

Re: Build failed in Jenkins: sling-trunk-1.6 #3256

2015-04-07 Thread Konrad Windszus

I just committed a potential fix for that. It seems that the Sightly
1.0.0-SNAPSHOT is no longer available (since now we do have a 1.0.0 release and
a newer SNAPSHOT). Obviously the Apache repo will remove old SNAPSHOT versions.
I therefore now rely on Sightly 1.0.0 until the proper fix for SLING-4447 is
implemented.
Sorry for that.
Konrad

Am 07.04.2015 um 09:14 schrieb Robert Munteanu rob...@lmn.ro:

Hi Sandro,

I strongly suspect the failure is unrelated to your checkin.

Robert

On Tue, Apr 7, 2015 at 10:09 AM, Sandro Boehme sandro.boe...@gmx.de wrote:
Hi,

ok the build is not broken anymore. Just in time to leave Germany to fly to
Dubai in 2h :-).

Best,

Sandro

Am 07.04.15 um 06:59 schrieb Sandro Boehme:

Hi,

I reverted my changes in 'r1671740' and hope it fixes the build.

Best,

Sandro

Am 06.04.15 um 22:14 schrieb Sandro Boehme:

Hi,

somehow I managed to break the build of 'sling-trunk-1.6' by checking
something in to 'contrib/explorers/resourceeditor'. From what I
understand it should not have a dependency to that build, right?
It looks like an integration test of the Event Support project failed.
But I cannot reproduce it.
The failsafe plugin version has been updated at a commit before but the
build was blue.
Does someone have a pointer? The problem is, that I will probably have
no or not a good internet connection during the next 8 days. I will do
my best to fix it. I guess I will not commit short before a vacation
again.

Best,

Sandro

Am 06.04.15 um 20:29 schrieb Apache Jenkins Server:

[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-failsafe-plugin:2.16:integration-test
(default) on project org.apache.sling.event: Execution default of goal
org.apache.maven.plugins:maven-failsafe-plugin:2.16:integration-test
failed: The forked VM terminated without saying properly goodbye. VM
crash or System.exit called ?
[ERROR] Command was/bin/sh -c cd

https://builds.apache.org/job/sling-trunk-1.6/ws/trunk/bundles/extensions/event

/home/jenkins/tools/java/jdk1.6.0_45-32/jre/bin/java -Xmx2048m
-XX:MaxPermSize=512m -jar

https://builds.apache.org/job/sling-trunk-1.6/ws/trunk/bundles/extensions/event/target/surefire/surefirebooter8966558270306960395.jar

https://builds.apache.org/job/sling-trunk-1.6/ws/trunk/bundles/extensions/event/target/surefire/surefire4336694494544216414tmp

https://builds.apache.org/job/sling-trunk-1.6/ws/trunk/bundles/extensions/event/target/surefire/surefire_23694121237566832733tmp

--
Sent from my (old) computer

Re: Simplifying Jira user management

2015-05-21 Thread Konrad Windszus

Me neither (JIRA user kwin). Something seems to be definitely wrong. My profile 
page in JIRA exposes also that I am only in the group jira-users.
Konrad

 On 20 May 2015, at 18:17, Stefan Seifert sseif...@pro-vision.de wrote:
 
 it looks that my JIRA user (sseifert) does not longer have administration 
 privileges on the SLING project - i cannot manage JIRA versions any longer.
 
 stefan
 
 -Original Message-
 From: Robert Munteanu [mailto:romb...@apache.org]
 Sent: Tuesday, May 19, 2015 1:29 PM
 To: dev@sling.apache.org
 Subject: Re: Simplifying Jira user management
 
 I've now performed the changes, please shout if anything is broken.
 
 As an initial test I've moved the sling-developers group to the
 Administrators role and removed explicit entries for my user. After
 logging out and logging in I still have admin access, so this should
 work.
 
 Cheers,
 
 Robert
 
 On Fri, May 15, 2015 at 4:25 PM, Daniel Klco dk...@apache.org wrote:
 Agree +1
 
 On Fri, May 15, 2015 at 9:01 AM, Carsten Ziegeler cziege...@apache.org
 wrote:
 
 Makes sense, +1
 
 Carsten
 
 Am 06.05.15 um 15:31 schrieb Robert Munteanu:
 Hi,
 
 I took a look at the Jira roles that we have set up for the SLING
 project.The situation looks roughly like this:
 
 - Administrators: most members of the PMC ( missing 6 ), some committers
 ( 4 )
 - Committers: a few members of the PMC, some committers ( missing 4 )
 + the sling-developers group
 
 Given that we mostly use the extra Administrators group to allow
 administration of the project in relation to release management, I
 would suggest the following setup.
 
 a) Remove all user entries from the Administrators and Committers group.
 b) Add the sling-developers group as Administrators.
 
 The advantage is that we have a setup which allows committers to
 handle as much of release management work by default. This of course
 assumes that:
 
 1. We feel comfortable with allowing all committers administrator
 permission for the project
 2. The sling-developers group actually contains all sling committers
 
 For the record, these are the extra permissions that the
 Administrators group has:
 
 - Administer project:  Ability to administer a project in JIRA.
 - Move Issues: Ability to move issues between projects or between
 workflows of the same project (if applicable). Note the user can only
 move issues to a project he or she has the create permission for.
 - Modify Reporter: Ability to modify the reporter when creating or
 editing an issue.
 - Delete Issues: Ability to delete issues.
 - Edit All Comments: Ability to edit all comments made on issues.
 - Delete All Comments: Ability to delete all comments made on issues.
 - Delete All Attachments: Users with this permission may delete all
 attachments.
 
 Thoughts?
 
 Cheers,
 
 Robert
 
 
 
 --
 Carsten Ziegeler
 Adobe Research Switzerland
 cziege...@apache.org

Re: sling models api + impl 1.2 release soon?

2015-06-23 Thread Konrad Windszus

Hi Stefan,
although I didn’t have the time for further testing I have no objections for 
making a Models release.
Thanks for taking this up,
Konrad

 On 22 Jun 2015, at 23:52, Stefan Seifert sseif...@pro-vision.de wrote:
 
 @konrad: did you found the time for some more testing?
 
 any objections for making a sling models 1.2 release?
 
 stefan
 
 -Original Message-
 From: Konrad Windszus [mailto:konra...@gmx.de]
 Sent: Thursday, June 11, 2015 6:26 PM
 To: dev@sling.apache.org
 Subject: Re: sling models api + impl 1.2 release soon?
 
 Makes a lot of sense.
 I will do some more testing with a real project on the most recent SNAPSHOT
 early next week.
 If you could start the release process afterwards, that would be great.
 
 Konrad
 
 On 11 Jun 2015, at 17:52, Stefan Seifert sseif...@pro-vision.de wrote:
 
 it's a long time since sling models 1.1 release, and a bunch of new features
 was added since then.
 
 what do you think about making a 1.2.0 release soon? i currently see no
 outstanding issues assigned to the versions in JIRA, and due to the 
 separation
 of the validation in a separate bundle we no longer have a dependency to the
 release of the validation bundle.
 
 stefan

Re: sling models api + impl 1.2 release soon?

2015-06-11 Thread Konrad Windszus

Makes a lot of sense.
I will do some more testing with a real project on the most recent SNAPSHOT 
early next week.
If you could start the release process afterwards, that would be great.

Konrad

 On 11 Jun 2015, at 17:52, Stefan Seifert sseif...@pro-vision.de wrote:
 
 it's a long time since sling models 1.1 release, and a bunch of new features 
 was added since then.
 
 what do you think about making a 1.2.0 release soon? i currently see no 
 outstanding issues assigned to the versions in JIRA, and due to the 
 separation of the validation in a separate bundle we no longer have a 
 dependency to the release of the validation bundle.
 
 stefan

Re: Deprecating the json.org parser in sling commons json

2015-05-28 Thread Konrad Windszus

If we deprecate the parsing functionality of commons.json we should rather 
point to JSR 353 
(https://json-processing-spec.java.net/nonav/releases/1.0/fcs/javadocs/index.html)
 and one of the implementations (https://jsonp.java.net/ or 
http://owlike.github.io/genson/ AFAIK) as an alternative instead of the not 
really maintained json.org implementation 
(https://github.com/douglascrockford/JSON-java/blob/master/README).
Since JSR 353 does provide a streaming API 
(https://json-processing-spec.java.net/nonav/releases/1.0/fcs/javadocs/javax/json/stream/package-summary.html)
 and JSR 353 together with the reference implementation is part of Java EE 7 I 
consider it the most reasonable choice nowadays.

I cannot really say whether that would be a good choice for writing JSON 
objects in Sling as well, because i guess its streaming API keeps the order.
Konrad



 Am 28.05.2015 um 21:06 schrieb Alexander Klimetschek aklim...@adobe.com:
 
 tl;dr deprecate json.org classes in sling commons json, and point people to 
 use the real json.org library
 
 Hi,
 
 Sling commons.json includes a very old version of the json.org 
 implementations (state pre 2009, apart from few important bug fixes).
 
 Most notably, it is not useful for parsing json, since the sling version can 
 only work with strings [1] as input. This is obviously bad for memory usage 
 and performance, espcially with larger json files, if you have to convert a 
 request stream or binary (from a resource) into a string first, meaning you 
 end up with potentially 3 in-memory representations of the json (binary 
 stream, string  parsed jsonobject structure). json.org has stream  reader 
 support for a long time [2]. (Also, Apache Jackrabbit has a streaming parser 
 that can be useful for some cases, but that's a different topic [3]).
 
 However, just updating the copy of these classes in commons.json to the 
 newest version or json.org won't work, since the APIs are not backwards 
 compatible (most notably, JsonTokener methods now throwing JsonExceptions 
 they did not before). You could find a hacky way to port it, but then future 
 updates will be again difficult.
 
 The sling commons.json was added and used in Sling mainly for _generating_ 
 json, not _parsing_ it (to dump jcr structures as json or write servlets 
 generating json for client-side consumption). It also has a bunch of extra 
 stuff for that case (groovy, jsonwriter etc.). IIRC, it also keeps the order 
 when writing json objects, which isn't standardized in json, and doesn't 
 apply when you parse json (and sling has an option to use arrays nowadays for 
 exporting jcr as json).
 
 However, people using the sling stack will naturally start using Sling 
 commons json for all their json stuff, so they unknowingly will run into the 
 above problem(s) when they use it for parsing.
 
 Therefore I think there should be a clear deprecation note on the JSONObject 
 et al classes, when you use this for parsing json, use org.json instead.
 
 wdyt?
 
 [1] 
 https://github.com/apache/sling/blob/trunk/bundles/commons/json/src/main/java/org/apache/sling/commons/json/JSONTokener.java#L53
 [2] 
 https://github.com/douglascrockford/JSON-java/blob/master/JSONTokener.java#L74
 [3] 
 http://jackrabbit.apache.org/api/2.2/org/apache/jackrabbit/commons/json/JsonParser.html
 
 Cheers,
 Alex

Release 2.4.0 of org.apache.sling.i18n not on Maven Central

2015-07-03 Thread Konrad Windszus

What happened to that release?
It can’t be found on Maven Central: 
http://search.maven.org/#search|gav|1|g%3A%22org.apache.sling%22%20AND%20a%3A%22org.apache.sling.i18n%22
 
http://search.maven.org/#search%7Cgav%7C1%7Cg:%22org.apache.sling%22%20AND%20a:%22org.apache.sling.i18n%22
Other versions (older and newer) are there.
Can someone push that release to Maven Central as well?
Thanks,
Konrad

Apache CMS issues

2015-06-29 Thread Konrad Windszus


Are there currently some known issues with the Apache CMS? Although I committed 
some changes to 
https://svn.apache.org/repos/asf/sling/site/trunk/content/documentation/bundles/validation.mdtext
 
https://svn.apache.org/repos/asf/sling/site/trunk/content/documentation/bundles/validation.mdtext
 I don’t see those in 
http://sling.staging.apache.org/documentation/bundles/validation.html 
http://sling.staging.apache.org/documentation/bundles/validation.html
Konrad

Re: Compilation error in models.validation-impl ( was: Build failed in Jenkins: sling-trunk-1.8 #1370 )

2015-07-29 Thread Konrad Windszus

Fixed it already. Sorry for that.

 On 29 Jul 2015, at 10:13, Robert Munteanu romb...@apache.org wrote:
 
 On Wed, 2015-07-29 at 08:05 +, Apache Jenkins Server wrote:
 See https://builds.apache.org/job/sling-trunk-1.8/1370/changes
 
 Changes:
 
 [kwin] SLING-4876 support resource type inheritance for validator 
 models
 
 This closes #100
 
 [chetanm] SLING-4914 - LogPanel should pass appender name as request 
 parameter
 
 Changed the tailer approach. Now use url ending with tailer.txt and 
 specify appender name as part of 'name' request param
 
 
 (snip)
 
 This looks like an actual error :-) and possibly related to SLING-4876.
 
 
 [ERROR] Failed to execute goal 
 org.apache.maven.plugins:mavenorg.apache.sling.models.validation
 -impl: Compilation failure
 [ERROR] https://builds.apache.org/job/sling-trunk-1.8/ws/trunk/bundl
 es/extensions/models/validation
 -impl/src/main/java/org/apache/sling/models/validation/impl/ModelVali
 dationImpl.java:[74,57] no suitable method found for 
 getValidationModel(org.apache.sling.api.resource.Resource)
 [ERROR] method 
 org.apache.sling.validation.ValidationService.getValidationModel(java
 .lang.String,java.lang.String,boolean) is not applicable
 [ERROR] (actual and formal argument lists differ in length)
 [ERROR] method 
 org.apache.sling.validation.ValidationService.getValidationModel(org.
 apache.sling.api.resource.Resource,boolean) is not applicable
 [ERROR] (actual and formal argument lists differ in length)
 
 Robert

Problem with embedding newer version of a referenced class

2015-08-03 Thread Konrad Windszus

Hi,
in https://issues.apache.org/jira/browse/SLING-4779 
https://issues.apache.org/jira/browse/SLING-4779 we had a discussion about 
how to leverage a class from the bundle Commons OSGi 2.3 while still leaving 
the dependency at 2.2.
The outcome was to use the approach listed in 
http://njbartlett.name/2014/05/26/static-linking.html 
http://njbartlett.name/2014/05/26/static-linking.html to embed one package 
from Commons OSGi in Sling Models Impl (but not export it, of course).

There is a drawback with that approach, related to the way how the 
maven-bundle-plugin and bnd works internally.
Actually if you depend on both Sling Models Impl (1.2) and Commons OSGi (2.2) 
in your own bundle you might end up having an import-package statement with the 
wrong version range [2.3, 3) instead of [2.2, 3).
This is because bnd figures out the version range by looking at the compile 
class path and just looks at the first package (and extracting the version in 
this case from its package-info).
If the first dependency on the class path is now Sling Models Impl, bnd 
implicitly assumes, that the package is exported from the dependency (without 
looking at the manifest).
I opened a bug at bnd on that: https://github.com/bndtools/bnd/issues/1017 
https://github.com/bndtools/bnd/issues/1017.

Should we do anything about it now in the Sling code base until the bug of bnd 
is fixed upstream. Probably just stripping the package-info.class from 
org.apache.sling.commons.osgi in Sling Models Impl would be enough, but then we 
can no longer use the automatism of “Conditional-Package”.
This issue would affect right now Sling Mock 
(https://github.com/apache/sling/blob/trunk/testing/mocks/sling-mock/pom.xml 
https://github.com/apache/sling/blob/trunk/testing/mocks/sling-mock/pom.xml) 
because that one depends first on org.apache.sling.models.impl and only after 
that on org.apache.sling.commons.osgi. At least that we should fix.

Do you have any other idea on how to fix that?
Thanks,
Konrad

Re: Quoted string format in https://sling.apache.org/documentation/bundles/configuration-installer-factory.html

2015-08-11 Thread Konrad Windszus

Thank you Carsten. Can you quickly review my proposed update at 
http://sling.staging.apache.org/documentation/bundles/configuration-installer-factory.html?
 
http://sling.staging.apache.org/documentation/bundles/configuration-installer-factory.html?
In case that fits, I will publish it.
Konrad
 On 11 Aug 2015, at 17:55, Carsten Ziegeler cziege...@apache.org wrote:
 
 Am 11.08.15 um 17:49 schrieb Konrad Windszus:
 Currently in 
 https://sling.apache.org/documentation/bundles/configuration-installer-factory.html
  the format for Configuration Files ending with .config is pretty well 
 described. One point missing there is what exactly must be quoted within 
 stringsimple. Actually just using quoted-string is not specific enough as 
 also every “=“ need to be preceded by a “/“. What about extending the 
 grammar like following
 stringsimple ::= quoted string representation of the value, where both “ 
 and = need to be quoted with a leading “/“
 Do I need to quote any other characters in string simple?
 
 I think those are the only two, however I would call this escaping :)
 In fact I have the feeling that the special handling of = within a
 quoted string is wrong, but that's in there for ages, so it probably
 good not to change it.
 
 Regards
 Carsten
 -- 
 Carsten Ziegeler
 Adobe Research Switzerland
 cziege...@apache.org

Quoted string format in https://sling.apache.org/documentation/bundles/configuration-installer-factory.html

2015-08-11 Thread Konrad Windszus

Currently in 
https://sling.apache.org/documentation/bundles/configuration-installer-factory.html
 the format for Configuration Files ending with .config is pretty well 
described. One point missing there is what exactly must be quoted within 
stringsimple. Actually just using quoted-string is not specific enough as also 
every “=“ need to be preceded by a “/“. What about extending the grammar like 
following
stringsimple ::= quoted string representation of the value, where both “ and = 
need to be quoted with a leading “/“
Do I need to quote any other characters in string simple?
Thanks,
Konrad

Re: Sling JCR Mocks, testing dependencies and imported ranges

2015-08-07 Thread Konrad Windszus

Actually this does also affect sling-mocks IMHO (please compare with 
https://issues.apache.org/jira/browse/SLING-4932 
https://issues.apache.org/jira/browse/SLING-4932). Therefore I suggest to 
also do the embedding in sling-mocks 
(https://issues.apache.org/jira/browse/SLING-4934 
https://issues.apache.org/jira/browse/SLING-4934).
Usually in our projects we have one big dependency management section 
reflecting the actual versions being running in Apache Felix (i.e. the runtime 
version). This may be newer versions than the ones sling-mocks is using. 
Unfortunately the dependency management does also affect the transitive 
dependencies of sling-mock at run-time (i.e. while executing the tests).
Anything speaks against embedding all transitive dependencies there?
Konrad

 On 11 Jun 2015, at 16:43, Stefan Seifert sseif...@pro-vision.de wrote:
 
 hello robert.
 
 to clarify for the others, this does not affect the primary mocks jcr-mock 
 and sling-mock, but only if you want to use one of the (more experimental) 
 mocks with real repository underneath, namely sling-mock-jackrabbit and 
 sling-mock-oak. for most usecases the resourcresolver-mock or jcr-mock will 
 suffice and has not this problem.
 
 but if a real repository like oak or jackrabbit is required one hits the 
 problem as described by robert.
 
 1+2 are real no options, 3 is quite inconvenient and complicates code 
 coverage checks a lot.
 
 yes, embedding the oak/jackrabbit dependencies in the 
 sling-mock-jackrabbit/sling-mock-oak artifacts could be a good option. the 
 only small drawback i see is the bloating of the JAR file. perhaps we should 
 give it a try.
 
 stefan
 
 -Original Message-
 From: Robert Munteanu [mailto:romb...@apache.org]
 Sent: Wednesday, June 10, 2015 5:08 PM
 To: Sling Dev
 Subject: Sling JCR Mocks, testing dependencies and imported ranges
 
 Hi,
 
 I'm starting to be very much convinced that the Sling Mocks are the
 simplest way to add fast, repository and OSGi-enabled tests. Since they
 are executed out-of-container, they can live in the same module as the
 code under test.
 
 One conflict that I found with this approach is that while the Sling
 JCR mocks - namely JCR_JACKRABBIT and JCR_OAK - require recent versions
 of jackrabbit ( api, commons ), while we typically aim to keep the
 dependency versions as low as possible. One example is the recent
 change I added to the jcr.contentloader module [1], bumping the
 jackrabbit-api version from 2.2.0 to 2.10.1 (!).
 
 I have considered various approaches, but none of them looks good.
 
 1. Declaring two dependencies with different scopes - used to work with
 Maven 3, no longer works with Maven 2.
 2. Just live with the more strict import range - a bad idea to restrict
 bundles from running on older versions just because the tests need new
 versions.
 3. Split the tests in a different module - defies the purpose of having
 the tests live with the code under test
 4. Manually set the import-package versions in the pom.xml file -
 manual and error-prone
 
 Hm ... writing this email I just got the idea of the JCR mocks
 packaging all dependencies using the maven-shade-plugin [2] so that the
 actual dependencies used for testing are not the ones used at compile
 time and implicitly not the ones used to calculate dependencies.
 
 This means that for instance org.apache.sling.testing.sling-mock-oak
 will embed all of oak and the dependendent jackrabbit apis.
 
 Thoughts? Alternatives?
 
 Thanks,
 
 Robert
 
 [1]: http://svn.apache.org/viewvc?view=revisionrevision=r1684450
 [2]: https://maven.apache.org/plugins/maven-shade-plugin/

Re: Sling JCR Mocks, testing dependencies and imported ranges

2015-08-13 Thread Konrad Windszus

Hi Stefan,

 On 12 Aug 2015, at 21:26, Stefan Seifert sseif...@pro-vision.de wrote:
 
 hello konrad.
 
 i'm not sure if embedding more dependencies into the sling-mock JAR is a good 
 idea.
 
 one main idea when designing sling-mock was that it should not be tied to a 
 certain (esp. not only the newest) sling version/dependencies to still allow 
 using it in projects that are using a sling version that is a bit older. in 
 fact up to now sling-mocks imports only dependencies from ~mid 2013 and is 
 thus quite compatible with most sling versions from then up to now for the 
 most common testing use cases.
Is thus quite compatible sounds too fuzzy for me. Since it is way too much 
effort to list which dependency versions are supported I would rather support 
only one version (which is the newest) and make that version unchangeable 
through e.g. dependencyManagement by embedding it. 

 
 when new features are added to APIs that need implementations we implement 
 them in the mocks as well, but to not raise the dependency version to not 
 force all users to this update. each project that uses sling-mocks usually 
 has some dependencies already declared (e.g. the sling api version it uses), 
 so this overwrites the dependencies from sling-mock. this approach has 
 limitations: when a new interface we want to be upwards compatible to but not 
 update the dependency version references a class not available in the old 
 dependencies this way is no longer possible. fortunately this happens quite 
 rarely. SLING-4932 may be such a case.
Updating sling-mock to a newer version which e.g. depends on a brand new 
version of sling API does not mean your code does need to depend on the same 
version of Sling API. You can easily override that by explicitly stating 
another dependency in your pom. That also won’t interfere with the 
maven-bundle-plugin as that will only evaluate the Maven compile class path 
(which sling-mock should never be part of) to figure out the import version 
range for packages.

 
 aem-mock [1] for example overwrites all related dependencies with those from 
 AEM6 because this is the main version the wcm.io libraries are currently 
 targeted at. but with a different set of dependencies it should be possible 
 to use sling mock with newer or older sling versions as well. of course it 
 can be a bit brittle to get the dependencies right which may be inconvenient 
 for the user.
 
 but when we embed some dependencies with a fixed version this may breaks this 
 wide-range version compatibility, or at least may introduce a different 
 behavior e.g. for the JCR-sling-resource mapping than is used really in the 
 project itself, lessening the trustability of the unit tests. for oak or 
 jackrabbit embedding the dependencies is not problematic, because sling and 
 oak/jackrabbit are only loosely coupled via their respective APIs which are 
 quite stable.
Since most of the API is backwards compatible anyways I don’t really see the 
risk here, if you use a different implementation in your unit test leveraging 
sling-mock as in your production environment. In the end you don’t want to test 
if the Sling/Jackrabbit/Oak implementation is correct rather than if your own 
code is correct. Could you give a good example where using sling-mock with a 
newer version of some Sling/Jackrabbit/Oak dependency lead to compatibility 
problems (i.e. your code runs in sling-mock, but not in your production 
environment)? 
What exactly has been changed in the jcr-resource mapping that would require 
testing with an older Sling dependency?

 
 obviously i want to avoid to have to maintain an own sling-mock version for 
 each sling version or combination of sling api/jcr resource mapping/etc. 
 version.
I completely understand and therefore would only support the newest version 
(because testing should still cover old API usages, because it should be 
backwards compatible in most of the cases).
Thanks,
Konrad

 
 stefan
 
 [1] http://wcm.io/testing/aem-mock/
 
 
 -Original Message-
 From: Konrad Windszus [mailto:konra...@gmx.de]
 Sent: Friday, August 07, 2015 3:04 PM
 To: dev@sling.apache.org
 Subject: Re: Sling JCR Mocks, testing dependencies and imported ranges
 
 Actually this does also affect sling-mocks IMHO (please compare with
 https://issues.apache.org/jira/browse/SLING-4932
 https://issues.apache.org/jira/browse/SLING-4932). Therefore I suggest to
 also do the embedding in sling-mocks
 (https://issues.apache.org/jira/browse/SLING-4934
 https://issues.apache.org/jira/browse/SLING-4934).
 Usually in our projects we have one big dependency management section
 reflecting the actual versions being running in Apache Felix (i.e. the 
 runtime
 version). This may be newer versions than the ones sling-mocks is using.
 Unfortunately the dependency management does also affect the transitive
 dependencies of sling-mock at run-time (i.e. while executing the tests).
 Anything speaks against embedding all transitive

Re: Sling JCR Mocks, testing dependencies and imported ranges

2015-08-10 Thread Konrad Windszus

Hi Robert,
thanks for your comments on that.

 On 10 Aug 2015, at 12:21, Robert Munteanu romb...@apache.org wrote:
 
 On Fri, 2015-08-07 at 15:04 +0200, Konrad Windszus wrote:
 Actually this does also affect sling-mocks IMHO (please compare with 
 https://issues.apache.org/jira/browse/SLING-4932 
 https://issues.apache.org/jira/browse/SLING-4932). Therefore I 
 suggest to also do the embedding in sling-mocks (
 https://issues.apache.org/jira/browse/SLING-4934 
 https://issues.apache.org/jira/browse/SLING-4934).
 Usually in our projects we have one big dependency management section 
 reflecting the actual versions being running in Apache Felix (i.e. 
 the runtime version). This may be newer versions than the ones sling
 -mocks is using. Unfortunately the dependency management does also 
 affect the transitive dependencies of sling-mock at run-time (i.e. 
 while executing the tests).
 Anything speaks against embedding all transitive dependencies there?
 
 I don't think there's a problem with embedding the dependencies here.
 
 Two questions related to your patch:
 
 1. Is there a way to ensure that we embed the same versions? I think
 that if we use sling-mock and sling-mock-oak for instance, and they
 embed different versions we will get classpath clashes. Maybe we could
 set up some IT projects where this gets verified…
 
Yeah, very true. Especially if we would pass classes around being embedded by 
both JARs like ResourceResolverFactory or SlingRepository from 
ResourceResolverTypeAdapter.
Unfortunately I don’t have a very good idea on how to check that with an IT. 
Probably at least the Sling API should never be embedded, as that will for sure 
clash.
Do you have any idea, on how we could test that sufficiently?

 2. Why did you set createDependencyReducedPom = false? IIUC this means
 that some depending on sling-mock will pull in transitive dependencies
 in the classpath anyway.

Yes, that is true. But when I enable that the dependency-reduced-pom.xml is 
generated without the Apache License Header and therefore the apache-rat-plugin 
does complain.
I could disable the check of the apache-rat-plugin but that would mean, we 
would deploy a pom.xml without a Apache License Header to Maven Central (and I 
am not sure this is allowed).
Also I didn’t have any problems with the transitive dependencies.
How did you solve that for sling-mock-oak?

 
 Thanks,
 
 Robert
 
 Konrad
 
 On 11 Jun 2015, at 16:43, Stefan Seifert sseif...@pro-vision.de 
 wrote:
 
 hello robert.
 
 to clarify for the others, this does not affect the primary mocks 
 jcr-mock and sling-mock, but only if you want to use one of the 
 (more experimental) mocks with real repository underneath, namely 
 sling-mock-jackrabbit and sling-mock-oak. for most usecases the 
 resourcresolver-mock or jcr-mock will suffice and has not this 
 problem.
 
 but if a real repository like oak or jackrabbit is required one 
 hits the problem as described by robert.
 
 1+2 are real no options, 3 is quite inconvenient and complicates 
 code coverage checks a lot.
 
 yes, embedding the oak/jackrabbit dependencies in the sling-mock
 -jackrabbit/sling-mock-oak artifacts could be a good option. the 
 only small drawback i see is the bloating of the JAR file. perhaps 
 we should give it a try.
 
 stefan
 
 -Original Message-
 From: Robert Munteanu [mailto:romb...@apache.org]
 Sent: Wednesday, June 10, 2015 5:08 PM
 To: Sling Dev
 Subject: Sling JCR Mocks, testing dependencies and imported 
 ranges
 
 Hi,
 
 I'm starting to be very much convinced that the Sling Mocks are 
 the
 simplest way to add fast, repository and OSGi-enabled tests. 
 Since they
 are executed out-of-container, they can live in the same module 
 as the
 code under test.
 
 One conflict that I found with this approach is that while the 
 Sling
 JCR mocks - namely JCR_JACKRABBIT and JCR_OAK - require recent 
 versions
 of jackrabbit ( api, commons ), while we typically aim to keep 
 the
 dependency versions as low as possible. One example is the recent
 change I added to the jcr.contentloader module [1], bumping the
 jackrabbit-api version from 2.2.0 to 2.10.1 (!).
 
 I have considered various approaches, but none of them looks 
 good.
 
 1. Declaring two dependencies with different scopes - used to 
 work with
 Maven 3, no longer works with Maven 2.
 2. Just live with the more strict import range - a bad idea to 
 restrict
 bundles from running on older versions just because the tests 
 need new
 versions.
 3. Split the tests in a different module - defies the purpose of 
 having
 the tests live with the code under test
 4. Manually set the import-package versions in the pom.xml file -
 manual and error-prone
 
 Hm ... writing this email I just got the idea of the JCR mocks
 packaging all dependencies using the maven-shade-plugin [2] so 
 that the
 actual dependencies used for testing are not the ones used at 
 compile
 time and implicitly not the ones used to calculate dependencies

Sightly warnings by GlobalShadowChecker

2015-08-14 Thread Konrad Windszus

In our code I see a lot of warnings like this one:
org.apache.sling.scripting.sightly.impl.compiler.util.GlobalShadowChecker 
Global variable 'component' is being overridden in template
It seems that the Sightly compiler always emits that warning in case a global 
variable name has been newly defined in a Sightly script like this sly 
data-sly-use.someGlobalVariableName=“someClass”…/sly
While I do understand that this might lead to issues, I would rather make that 
GlobalShadowChecker functionality configurable.
This is especially useful as previous versions of the Sightly compiler didn’t 
have that feature.
WDYT?
Konrad

Fwd: Resource Resolvers in OSGi Service APIs

2015-07-24 Thread Konrad Windszus

I just found out about ResourceResolver.getThreadResourceResolver 
(https://issues.apache.org/jira/browse/SLING-3868 
https://issues.apache.org/jira/browse/SLING-3868). Although this might speed 
up things, I am not sure on when to use this. I basically share Jörgs concerns 
from  
http://mail-archives.apache.org/mod_mbox/sling-users/201506.mbox/%3ccamzpi1o0qlkrkbxcvz0xpdix7wuh+tappkpa2xnqf7rgcl2...@mail.gmail.com%3E
 
http://mail-archives.apache.org/mod_mbox/sling-users/201506.mbox/%3ccamzpi1o0qlkrkbxcvz0xpdix7wuh+tappkpa2xnqf7rgcl2...@mail.gmail.com%3E.
Also a quick search for getThreadResourceResolver proved that nobody is using 
that within the Sling Codebase 
(https://github.com/apache/sling/search?utf8=%E2%9C%93q=getThreadResourceResolvertype=Code
 
https://github.com/apache/sling/search?utf8=%E2%9C%93q=getThreadResourceResolvertype=Code).
What is the idea behind that concept? Under which circumstances does a client 
not care about which resource resolver is returned (with which permissions)?
It would be much more useful if that resource resolver would always be bound to 
the user’s account which triggered the request (and null if no request is 
behind the current thread).

 Hi Carsten,
 thanks a lot for your answer. There is one question remaining though:
 Given that you don’t want to pass the resource resolver from the client, 
 under which circumstances would you pick which one from the following two 
 approaches:
 
 a) Create a resource resolver in the activate method and release in the 
 deactivate (and live with the drawback that concurrent read access is then 
 synchronised and the session is open for a very long time, 
 https://issues.apache.org/jira/browse/OAK-2045 
 https://issues.apache.org/jira/browse/OAK-2045). I have seen this pattern a 
 lot in the past.
 b) Create the resource resolver on demand for each call.
 
 How big is the overhead to create new resolvers on demand?
 At least in Jackrabbit 2 there is the drawback that those aren’t GCed quickly 
 enough due to their finalizers 
 (https://issues.apache.org/jira/browse/JCR-2768 
 https://issues.apache.org/jira/browse/JCR-2768)
 What about Oak? How big is the overhead there?
 Thanks for your input
 Konrad
 
 
 On 24 Jul 2015, at 08:06, Carsten Ziegeler cziege...@apache.org wrote:
 
 Am 23.07.15 um 18:19 schrieb Konrad Windszus:
 For Sling Validation I just came across the issue that I need a resource 
 resolver in the implementation (e.g. for triggering a search to find the 
 validation models in the repository or to figure out the resource super 
 type).
 Currently the API is designed that no resolver is passed when any service 
 method is called 
 (https://github.com/apache/sling/blob/trunk/bundles/extensions/validation/api/src/main/java/org/apache/sling/validation/ValidationService.java
  
 https://github.com/apache/sling/blob/trunk/bundles/extensions/validation/api/src/main/java/org/apache/sling/validation/ValidationService.java)
 In theory there could also be validation model providers, which are not 
 using the resource resolver (maybe based on files or an OSGi 
 configuration). Therefore initially it seemed reasonable to not pass any 
 resolvers into the API calls.
 
 But now I am not so sure, because for the implementation I would need to 
 rely either on the admin resource resolver (which is considered bad 
 practice from a security point of view) or some service resource resolver 
 (which need to be configured). Also creating new resource resolver comes 
 with a price (therefore it is often done in the activate, which is not good 
 practice either)
 What is you general opinion on the API design of an OSGi service, which may 
 need a resource resolver for some implementations:
 Should those API methods always get a resource resolver (if at least one 
 implementation may use that) or should the implementation get the resource 
 resolver then on its own (through a service)?
 
 I guess this depends :) I would go with something along these lines:
 
 If the operation must be done with the permissions of the client of your
 API, you have to pass the resource resolver as part of the api.
 If the operation could be done with the permissions of the client of
 your API, you should pass the resource resolver.
 
 In the other cases, definitely avoid login administrative and also long
 running session, and be aware that a session is not thread safe, and
 using a shared session for reading comes with a performance penalty.
 
 Getting a session is not that cheap, therefore getting a session for a
 service user within the implementation for each and every call of your
 API does not look like a good idea either. I guess here you need to make
 the trade off between a nice to use API, performance and security setup.
 If your api is called often, you might want to put the burden on the
 client to create the service user. However this might bloat the service
 user configurations.
 If it's called rarely, creating a service user within

Re: Resource Resolvers in OSGi Service APIs

2015-07-24 Thread Konrad Windszus

Hi Carsten,
thanks a lot for your answer. There is one question remaining though:
Given that you don’t want to pass the resource resolver from the client, under 
which circumstances would you pick which one from the following two approaches:

a) Create a resource resolver in the activate method and release in the 
deactivate (and live with the drawback that concurrent read access is then 
synchronised and the session is open for a very long time, 
https://issues.apache.org/jira/browse/OAK-2045 
https://issues.apache.org/jira/browse/OAK-2045). I have seen this pattern a 
lot in the past.
b) Create the resource resolver on demand for each call.

How big is the overhead to create new resolvers on demand?
At least in Jackrabbit 2 there is the drawback that those aren’t GCed quickly 
enough due to their finalizers (https://issues.apache.org/jira/browse/JCR-2768 
https://issues.apache.org/jira/browse/JCR-2768)
What about Oak? How big is the overhead there?
Thanks for your input
Konrad


 On 24 Jul 2015, at 08:06, Carsten Ziegeler cziege...@apache.org wrote:
 
 Am 23.07.15 um 18:19 schrieb Konrad Windszus:
 For Sling Validation I just came across the issue that I need a resource 
 resolver in the implementation (e.g. for triggering a search to find the 
 validation models in the repository or to figure out the resource super 
 type).
 Currently the API is designed that no resolver is passed when any service 
 method is called 
 (https://github.com/apache/sling/blob/trunk/bundles/extensions/validation/api/src/main/java/org/apache/sling/validation/ValidationService.java
  
 https://github.com/apache/sling/blob/trunk/bundles/extensions/validation/api/src/main/java/org/apache/sling/validation/ValidationService.java)
 In theory there could also be validation model providers, which are not 
 using the resource resolver (maybe based on files or an OSGi configuration). 
 Therefore initially it seemed reasonable to not pass any resolvers into the 
 API calls.
 
 But now I am not so sure, because for the implementation I would need to 
 rely either on the admin resource resolver (which is considered bad practice 
 from a security point of view) or some service resource resolver (which need 
 to be configured). Also creating new resource resolver comes with a price 
 (therefore it is often done in the activate, which is not good practice 
 either)
 What is you general opinion on the API design of an OSGi service, which may 
 need a resource resolver for some implementations:
 Should those API methods always get a resource resolver (if at least one 
 implementation may use that) or should the implementation get the resource 
 resolver then on its own (through a service)?
 
 I guess this depends :) I would go with something along these lines:
 
 If the operation must be done with the permissions of the client of your
 API, you have to pass the resource resolver as part of the api.
 If the operation could be done with the permissions of the client of
 your API, you should pass the resource resolver.
 
 In the other cases, definitely avoid login administrative and also long
 running session, and be aware that a session is not thread safe, and
 using a shared session for reading comes with a performance penalty.
 
 Getting a session is not that cheap, therefore getting a session for a
 service user within the implementation for each and every call of your
 API does not look like a good idea either. I guess here you need to make
 the trade off between a nice to use API, performance and security setup.
 If your api is called often, you might want to put the burden on the
 client to create the service user. However this might bloat the service
 user configurations.
 If it's called rarely, creating a service user within the implementation
 shouldn't be a problem.
 
 Carsten
 -- 
 Carsten Ziegeler
 Adobe Research Switzerland
 cziege...@apache.org

Resource Resolvers in OSGi Service APIs

2015-07-23 Thread Konrad Windszus

For Sling Validation I just came across the issue that I need a resource 
resolver in the implementation (e.g. for triggering a search to find the 
validation models in the repository or to figure out the resource super type).
Currently the API is designed that no resolver is passed when any service 
method is called 
(https://github.com/apache/sling/blob/trunk/bundles/extensions/validation/api/src/main/java/org/apache/sling/validation/ValidationService.java
 
https://github.com/apache/sling/blob/trunk/bundles/extensions/validation/api/src/main/java/org/apache/sling/validation/ValidationService.java)
In theory there could also be validation model providers, which are not using 
the resource resolver (maybe based on files or an OSGi configuration). 
Therefore initially it seemed reasonable to not pass any resolvers into the API 
calls.

But now I am not so sure, because for the implementation I would need to rely 
either on the admin resource resolver (which is considered bad practice from a 
security point of view) or some service resource resolver (which need to be 
configured). Also creating new resource resolver comes with a price (therefore 
it is often done in the activate, which is not good practice either)
What is you general opinion on the API design of an OSGi service, which may 
need a resource resolver for some implementations:
Should those API methods always get a resource resolver (if at least one 
implementation may use that) or should the implementation get the resource 
resolver then on its own (through a service)?

Thanks for your input on that
Konrad

Building Sling IDE

2015-11-04 Thread Konrad Windszus

I do have problems building the Sling IDE. While it works on the CLI with Tycho 
I have errors within Eclipse due to unresolved dependencies for the package 
“javax.jcr.nodetype".
This is a dependency of module o.a.s.ide.api but neither the Target Definition 
nor any dependent bundles do contain that package.
Where is it supposed to come from?

Thanks a lot in advance,
Konrad

Konrad Windszus | Senior Solutions Architect
Netcentric Deutschland GmbH
Landsberger Str. 110, D-80339 München
M: +49 151 6285 78 79
konrad.winds...@netcentric.biz | www.netcentric.biz/contact.html
Other disclosures according to § 35a GmbHG, § 161, 125a HGB: 
www.netcentric.biz/imprint.html

Re: Debugging Implementation when running ITs

2015-10-06 Thread Konrad Windszus

Just set a breakpoint to 
org.apache.sling.testing.tools.jarexec.JarExecutor.start() and then start the 
debugging on the client side (also documented at 
https://sling.apache.org/documentation/development/sling-testing-tools.html).
You should see now which JVM options are used to start the instance.
The problem usually is, that Surefire itself forks Maven and therefore does not 
inherit the original system properties. Just set the configuration option 
forkCount from 
http://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html to 0 to 
prevent forking. Otherwise you have to set the jar.executor.vm.options through 
the configuration option args.

Remember that this does only work, if you provision a new server instance, but 
not if your a connecting to an already running server.
Konrad

> On 06 Oct 2015, at 10:59, Dominik Süß  wrote:
> 
> Hi everybody,
> 
> I currently want to hook in a debugger to the implementation of the
> installer when running the corresponding ITs as I want to inspect the
> implementation behavior and see if I could add a patch that helps in
> upgrade scenarios.
> 
> Yet I had no success getting the IT start in a way that I could hook in a
> remote debugger.
> If I get the documentation right it should be
> 
> mvn test
> -Djar.executor.vm.options="-agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=8000"
> 
> (picked up from
> https://sling.apache.org/documentation/development/sling-testing-tools.html)
> 
> Yet the tests just run through (and just fyi failed for
> BundleInstallStressTest.testSemiRandomInstall) without waiting for a remote
> connection.
> 
> Cheers
> 
> Dominik

Re: content-package-maven-plugin and tooling around it

2015-08-26 Thread Konrad Windszus

Almost two years passed and still no sign of the content-package-maven-plugin
in the open-source world.
Is it probable that this will happen soon?
Thanks,
Konrad
On 14 May 2014, at 15:01, Konrad Windszus konra...@gmx.de wrote:

Is there any news about that? Maybe a rough timeline, when the
content-package-maven-plugin is becoming Open Source? I would like to get my
patch https://issues.apache.org/jira/browse/SLING-3100 in the Sling IDE
Tooling in one of the first releases if possible.
Thanks,
Konrad

On 30 Oct 2013, at 08:18, Tobias Bocanegra tri...@day.com wrote:

Hi,

we will donate the content-package maven plugin (and package manager)
to Apache Jackrabbit soon. we just need some time to finalize the
contribution.

Thanks for your understanding and patience.
Regards. Toby

On Tue, Oct 29, 2013 at 6:42 AM, Robert Munteanu rob...@lmn.ro wrote:
Hi Konrad,

On Tue, Oct 29, 2013 at 2:34 PM, Konrad Windszus konra...@gmx.de wrote:
Hi,

unfortunately right now Sling only supports OSGi bundles as a deployable
artifacts (however, the bundles might be extended by JCR content with the
help of [0]). On the other hand there is already the
content-package-maven-plugin from Adobe [1], which wraps parts of a JCR
repository into a deployable artifact (leveraging the
JackrabbitFileVaultFS [2]). I would like to extend the Sling IDE Tooling
with a custom m2e project configurator for the packaging
“content-package”. Right now the patch is not integrated because of the
unclear status of the content-package-maven-plugin [3]. Is it supposed to
become Open Source like FileVault as indicated in [4]? Do you think that
such a m2e project configurator should become part of the Sling IDE
Tooling?

Just to restate my opinion, I definitely think this configurator
should be part of the Sling tooling.

However, I'm reluctant to include it until the actual maven plugin is
open-sourced. The main reason is that this will not be applicable
for/testable by many users, due to its licensing/availability.

Robert

Thanks for your input on this topic,
Konrad

--
Sent from my (old) computer

Re: double slash in WebDAV URL -> default workspace, was that by design?

2015-08-31 Thread Konrad Windszus

If I understood Carsten correctly the double slash should be accepted by the 
implementation. So IMHO the old behaviour described in SLING-4976 is the 
correct one (i.e. falling back to the default workspace).
> On 31 Aug 2015, at 11:37, Bertrand Delacretaz  wrote:
> 
> Hi,
> 
> On Mon, Aug 31, 2015 at 8:05 AM, Carsten Ziegeler  
> wrote:
>> ...If I'm not mistaken, most
>> servers handle a double slash as a single slash, so whatever changed in
>> the implementation seems to be now according to what everyone else is 
>> doing...
> 
> Yeah that sounds right - I have added a test at SLING-4976 that
> clarifies this behavior and would detect any future changes.
> 
> -Bertrand

Re: double slash in WebDAV URL -> default workspace, was that by design?

2015-08-31 Thread Konrad Windszus

But this is not what the test case in 
https://issues.apache.org/jira/browse/SLING-4976 
<https://issues.apache.org/jira/browse/SLING-4976> validates.
It now validates /dav//… (which should be fine and is 
fine)
But /dav// On 31 Aug 2015, at 11:49, Carsten Ziegeler <cziege...@apache.org> wrote:
> 
> Am 31.08.15 um 11:42 schrieb Konrad Windszus:
>> If I understood Carsten correctly the double slash should be accepted by the 
>> implementation. So IMHO the old behaviour described in SLING-4976 is the 
>> correct one (i.e. falling back to the default workspace).
> No :) What I meant is that usually urls with a double slash are treated
> as with a double slash, so
> 
> /a//b/c is the same as /a/b/c
> 
> Therefore if the implementation assumes that the second path element is
> the workspace name, with the above urls, the name is always "b" and does
> not default to anything
> 
> Regards
> Carsten
> -- 
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org

ResourceResolverFactory restart behaviour

2015-09-14 Thread Konrad Windszus

Currently if the resource resolver factory is restarted (e.g. because the 
configuration has been changed) all resource resolvers which were being 
requested beforehand become almost useless, because they have no longer any 
providers being bound! This means those resolvers can only be used to retrieve 
the entry points below “/“ but nothing beyond that.
Therefore if you forget to refresh a resource resolver after the resource 
resolver factory has been restarted you get very weird results. One example of 
this behaviour is being described in 
https://issues.apache.org/jira/browse/SLING-5023.
What about marking those resource resolvers as invalid (because they do no 
longer have the required resource providers being bound) and let all methods 
being called on those resource resolvers fail with an IllegalStateException?
That way those kind of programming mistakes would be more obvious!
Thanks for your opinions on that.
Konrad

Re: ResourceResolverFactory restart behaviour

2015-09-14 Thread Konrad Windszus

Thanks Carsten, indeed I am hitting SLING-4974.
Could you point me to the commit which closes the resource resolvers after the 
restart of the factory (or after some required providers become unavailable)?
I couldn’t find any related commit in 
https://github.com/apache/sling/commits/trunk/bundles/resourceresolver/src/main/java/org/apache/sling/resourceresolver/impl

<https://github.com/apache/sling/commits/trunk/bundles/resourceresolver/src/main/java/org/apache/sling/resourceresolver/impl>.
In which version of the resource resolver bundle is that implemented?
At least with resource resolver 1.2.4 this is not the case.
Thanks,
Konrad

> On 14 Sep 2015, at 17:55, Carsten Ziegeler <cziege...@apache.org> wrote:
> 
> Am 14.09.15 um 17:51 schrieb Konrad Windszus:
>> Currently if the resource resolver factory is restarted (e.g. because the 
>> configuration has been changed) all resource resolvers which were being 
>> requested beforehand become almost useless, because they have no longer any 
>> providers being bound! This means those resolvers can only be used to 
>> retrieve the entry points below “/“ but nothing beyond that.
>> Therefore if you forget to refresh a resource resolver after the resource 
>> resolver factory has been restarted you get very weird results. One example 
>> of this behaviour is being described in 
>> https://issues.apache.org/jira/browse/SLING-5023.
>> What about marking those resource resolvers as invalid (because they do no 
>> longer have the required resource providers being bound) and let all methods 
>> being called on those resource resolvers fail with an IllegalStateException?
>> That way those kind of programming mistakes would be more obvious!
>> Thanks for your opinions on that.
>> Konrad
>> 
>> 
> Hi
> 
> I think you're hitting a dub of SLING-4974 and afaik with the latest
> resource resolver impl we mark the resolvers as closed :)
> 
> Carsten
> 
> -- 
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org

Re: Compatibility of Sling with Oak 1.2

2015-09-16 Thread Konrad Windszus

Unfortunately not as I need the fix for 
https://issues.apache.org/jira/browse/SLING-4974 
<https://issues.apache.org/jira/browse/SLING-4974> (JCR Resource 2.5.6).
But the compatibility to Oak 1.2 was removed with 
https://issues.apache.org/jira/browse/SLING-4820 
<https://issues.apache.org/jira/browse/SLING-4820> (JCR Resource 2.5.2)

Konrad

> On 16 Sep 2015, at 11:41, Bertrand Delacretaz <bdelacre...@apache.org> wrote:
> 
> Hi,
> 
> On Tue, Sep 15, 2015 at 11:35 AM, Konrad Windszus <konra...@gmx.de> wrote:
>> ...In the case of https://issues.apache.org/jira/browse/SLING-4820
>> there is no simple solution to support both Oak 1.2 and 1.3
> 
> I'm not sure what to suggest...would using older released versions of
> the affected Sling modules work for you?
> 
> -Bertrand

Re: ResourceResolverFactory restart behaviour

2015-09-15 Thread Konrad Windszus

Yes, SLING-4360 added a check if the RRF is live to the method 
ResourceResolver.isLive(). The problem is that you have to call that method 
explicitly.
For me the use case is rather to detect programming mistakes like not listening 
for ResourceResolverFactory restarts. 
What about implicitly calling RR.isLive for every other method?
Actually the Javadoc for all RR methods already states it will throw an 
IllegalArgumentException if the RR has been closed already. I would expect the 
same exception in case the resource resolver factory has been closed (maybe 
with a different, more explicit error message).
What was the reason why only the RR.isLive method was modified with SLING-4360?
Konrad


> On 14 Sep 2015, at 20:57, Carsten Ziegeler <cziege...@apache.org> wrote:
> 
> Am 14.09.15 um 18:04 schrieb Konrad Windszus:
>> Thanks Carsten, indeed I am hitting SLING-4974.
>> Could you point me to the commit which closes the resource resolvers after 
>> the restart of the factory (or after some required providers become 
>> unavailable)?
>> I couldn’t find any related commit in 
>> https://github.com/apache/sling/commits/trunk/bundles/resourceresolver/src/main/java/org/apache/sling/resourceresolver/impl
>>  
>> <https://github.com/apache/sling/commits/trunk/bundles/resourceresolver/src/main/java/org/apache/sling/resourceresolver/impl>.
>> In which version of the resource resolver bundle is that implemented?
>> At least with resource resolver 1.2.4 this is not the case.
> 
> Then we might have a bug still in there, it's SLING-4360 which is
> version 1.1.12. Afaik, we did some tests back then and it seemed to
> work, but maybe it's not handling all cases properly?
> 
> Regards
> Carsten
> 
>> Thanks,
>> Konrad
>> 
>>> On 14 Sep 2015, at 17:55, Carsten Ziegeler <cziege...@apache.org> wrote:
>>> 
>>> Am 14.09.15 um 17:51 schrieb Konrad Windszus:
>>>> Currently if the resource resolver factory is restarted (e.g. because the 
>>>> configuration has been changed) all resource resolvers which were being 
>>>> requested beforehand become almost useless, because they have no longer 
>>>> any providers being bound! This means those resolvers can only be used to 
>>>> retrieve the entry points below “/“ but nothing beyond that.
>>>> Therefore if you forget to refresh a resource resolver after the resource 
>>>> resolver factory has been restarted you get very weird results. One 
>>>> example of this behaviour is being described in 
>>>> https://issues.apache.org/jira/browse/SLING-5023.
>>>> What about marking those resource resolvers as invalid (because they do no 
>>>> longer have the required resource providers being bound) and let all 
>>>> methods being called on those resource resolvers fail with an 
>>>> IllegalStateException?
>>>> That way those kind of programming mistakes would be more obvious!
>>>> Thanks for your opinions on that.
>>>> Konrad
>>>> 
>>>> 
>>> Hi
>>> 
>>> I think you're hitting a dub of SLING-4974 and afaik with the latest
>>> resource resolver impl we mark the resolvers as closed :)
>>> 
>>> Carsten
>>> 
>>> -- 
>>> Carsten Ziegeler
>>> Adobe Research Switzerland
>>> cziege...@apache.org
>> 
>> 
> 
> 
> -- 
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org

Re: ResourceResolverFactory restart behaviour

2015-09-15 Thread Konrad Windszus

Ok, thanks for the confirmation. I created issue 
https://issues.apache.org/jira/browse/SLING-5025 for that.
The only question is, whether the check for context.isLive() should also be 
done within the checkClosed()?

In theory I guess one could still use a resource resolver if one of the used 
providers is gone. Of course this is not the case for the JcrResourceProvider 
but since this is a required provider it would lead to an unregistration of the 
whole RRF.

> On 15 Sep 2015, at 09:35, Carsten Ziegeler <cziege...@apache.org> wrote:
> 
> Am 15.09.15 um 08:37 schrieb Konrad Windszus:
>> Yes, SLING-4360 added a check if the RRF is live to the method 
>> ResourceResolver.isLive(). The problem is that you have to call that method 
>> explicitly.
>> For me the use case is rather to detect programming mistakes like not 
>> listening for ResourceResolverFactory restarts. 
>> What about implicitly calling RR.isLive for every other method?
> 
> Oh, I see, every method calls checkClosed() which doesn't check the
> active flag. I think we should add this there as well.
> 
>> Actually the Javadoc for all RR methods already states it will throw an 
>> IllegalArgumentException if the RR has been closed already. I would expect 
>> the same exception in case the resource resolver factory has been closed 
>> (maybe with a different, more explicit error message).
>> What was the reason why only the RR.isLive method was modified with 
>> SLING-4360?
> 
> Good question :) I guess, it's just an oversight (aka bug) :)
> 
> Carsten
> 
>> Konrad
>> 
>> 
>>> On 14 Sep 2015, at 20:57, Carsten Ziegeler <cziege...@apache.org> wrote:
>>> 
>>> Am 14.09.15 um 18:04 schrieb Konrad Windszus:
>>>> Thanks Carsten, indeed I am hitting SLING-4974.
>>>> Could you point me to the commit which closes the resource resolvers after 
>>>> the restart of the factory (or after some required providers become 
>>>> unavailable)?
>>>> I couldn’t find any related commit in 
>>>> https://github.com/apache/sling/commits/trunk/bundles/resourceresolver/src/main/java/org/apache/sling/resourceresolver/impl
>>>>  
>>>> <https://github.com/apache/sling/commits/trunk/bundles/resourceresolver/src/main/java/org/apache/sling/resourceresolver/impl>.
>>>> In which version of the resource resolver bundle is that implemented?
>>>> At least with resource resolver 1.2.4 this is not the case.
>>> 
>>> Then we might have a bug still in there, it's SLING-4360 which is
>>> version 1.1.12. Afaik, we did some tests back then and it seemed to
>>> work, but maybe it's not handling all cases properly?
>>> 
>>> Regards
>>> Carsten
>>> 
>>>> Thanks,
>>>> Konrad
>>>> 
>>>>> On 14 Sep 2015, at 17:55, Carsten Ziegeler <cziege...@apache.org> wrote:
>>>>> 
>>>>> Am 14.09.15 um 17:51 schrieb Konrad Windszus:
>>>>>> Currently if the resource resolver factory is restarted (e.g. because 
>>>>>> the configuration has been changed) all resource resolvers which were 
>>>>>> being requested beforehand become almost useless, because they have no 
>>>>>> longer any providers being bound! This means those resolvers can only be 
>>>>>> used to retrieve the entry points below “/“ but nothing beyond that.
>>>>>> Therefore if you forget to refresh a resource resolver after the 
>>>>>> resource resolver factory has been restarted you get very weird results. 
>>>>>> One example of this behaviour is being described in 
>>>>>> https://issues.apache.org/jira/browse/SLING-5023.
>>>>>> What about marking those resource resolvers as invalid (because they do 
>>>>>> no longer have the required resource providers being bound) and let all 
>>>>>> methods being called on those resource resolvers fail with an 
>>>>>> IllegalStateException?
>>>>>> That way those kind of programming mistakes would be more obvious!
>>>>>> Thanks for your opinions on that.
>>>>>> Konrad
>>>>>> 
>>>>>> 
>>>>> Hi
>>>>> 
>>>>> I think you're hitting a dub of SLING-4974 and afaik with the latest
>>>>> resource resolver impl we mark the resolvers as closed :)
>>>>> 
>>>>> Carsten
>>>>> 
>>>>> -- 
>>>>> Carsten Ziegeler
>>>>> Adobe Research Switzerland
>>>>> cziege...@apache.org
>>>> 
>>>> 
>>> 
>>> 
>>> -- 
>>> Carsten Ziegeler
>>> Adobe Research Switzerland
>>> cziege...@apache.org
>> 
>> 
> 
> 
> -- 
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org

Compatibility of Sling with Oak 1.2

2015-09-15 Thread Konrad Windszus

I just ran into the problem that the package version of 
org/apache/jackrabbit/oak/plugins/observation changed from 1.0 (in Oak prior 
1.3) to 2.0  (since Oak 1.3).
This is a major version change not compatible with any version ranges being 
generated by the maven-bundle-plugin.

Due to this fact the dependency to Oak Core was raised to 1.3 in the JCR 
Resource bundle (in https://issues.apache.org/jira/browse/SLING-4820 
).
This leads to the fact, that now the JCR Resource bundle is no longer 
compatible with older versions of Oak (at least the OakResourceListener isn’t)
Since Oak 1.2 is considered the stable release branch it would be beneficial if 
Sling could support this version.

What is the policy of supporting Oak 1.2 in Sling?
Thanks for your input,
Konrad

Re: Compatibility of Sling with Oak 1.2

2015-09-15 Thread Konrad Windszus

In the case of https://issues.apache.org/jira/browse/SLING-4820 
<https://issues.apache.org/jira/browse/SLING-4820> there is no simple solution 
to support both Oak 1.2 and 1.3.
Since Oak incremented the major version of the package (although at first 
glance the used interfaces from 
https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/observation/NodeObserver.java

<https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/observation/NodeObserver.java>
 look like they haven’t been changed), the only solution would be to increase 
the version range of the Import-Package statement within the JCR Resource 
bundle manually to cover both 1.0 and 2.0. But this looks really like a hack 
and is IMHO too dangerous, as it may lead to not-running bundles although all 
dependencies could be resolved.
This is exactly what we want to prevent with semantic versioning.
Konrad

> On 15 Sep 2015, at 11:22, Bertrand Delacretaz <bdelacre...@apache.org> wrote:
> 
> Hi,
> 
> On Tue, Sep 15, 2015 at 9:26 AM, Konrad Windszus <konra...@gmx.de> wrote:
>> ...What is the policy of supporting Oak 1.2 in Sling?...
> 
> I don't think we have a defined policy so far - in general I like our
> tests to run against the latest Oak to stay on top of things, but
> you're right that it makes sense to also support the latest stable
> version.
> 
> Do you know what changes are needed for that?
> 
> -Bertrand

Re: FYI, TeleporterRule + reorganized server-side tests docs

2015-09-29 Thread Konrad Windszus

Hi,
the TeleporterRule-based tests look indeed much cleaner and leaner than with 
the old approach. But I was wondering whether it would be good to extend the 
teleporter module with some customizer rules which would allow to run the test 
on an already provisioned instance.
Currently we only have the customizer available in 
https://github.com/apache/sling/tree/trunk/launchpad/integration-tests 
, but 
the integration tests for Sling Models reside in 
https://github.com/apache/sling/tree/trunk/bundles/extensions/models/integration-tests

.
What about a customizer which can be parameterised equally to the former 
SlingTestBase 
(http://labs.6dglobal.com/blog/2013-06-05/creating-integration-tests-apache-sling/

)?
The requirements for such a customizer are IMHO:
- customizable base URL
- customizable credentials
- optionally deploys additional dependencies
- debug option

WDYT?
Konrad

> On 23 Sep 2015, at 16:58, Bertrand Delacretaz  wrote:
> 
> Hi,
> 
> FYI I have created a new docs page at
> 
> http://sling.apache.org/documentation/bundles/org-apache-sling-junit-bundles.html
> 
> which replaces this one, which is now mostly obsolete:
> 
> https://sling.apache.org/documentation/development/sling-testing-tools.html
> 
> I have created a TeleporterRule, described on the new docs page, which
> makes it much easier to create server-side tests. It's using the same
> JUnitServlet-based mechanism as before, but the low-level details of
> that are now hidden from the user.
> 
> Feedback is welcome of course, for now I have converted/created a
> number of tests that use the TeleporterRule under
> launchpad/integration-tests, and it seems to work fine.
> 
> -Bertrand

Re: Problem with embedding newer version of a referenced class

2015-09-30 Thread Konrad Windszus

Just for completeness: This issue is solved with bnd 3.0 
(https://github.com/bndtools/bnd/issues/1017 
<https://github.com/bndtools/bnd/issues/1017>) and therefore also with 
maven-bundle-plugin 3.0.0.
But since Sling is not yet using that, we should at least fix 
https://github.com/apache/sling/blob/trunk/testing/mocks/sling-mock/pom.xml 
<https://github.com/apache/sling/blob/trunk/testing/mocks/sling-mock/pom.xml> 
and invert the inclusion order of the dependencies models.impl and commons.osgi.
Konrad
> On 03 Aug 2015, at 14:52, Justin Edelson <jus...@justinedelson.com> wrote:
> 
> Hi Konrad,
> Is it possible to just embed the necessary classes rather than the whole
> package? I think we do that in other cases and would (I think) eliminate
> this issue.
> 
> Regards,
> Justin
> On Mon, Aug 3, 2015 at 8:26 AM Konrad Windszus <konra...@gmx.de> wrote:
> 
>> Hi,
>> in https://issues.apache.org/jira/browse/SLING-4779 <
>> https://issues.apache.org/jira/browse/SLING-4779> we had a discussion
>> about how to leverage a class from the bundle Commons OSGi 2.3 while still
>> leaving the dependency at 2.2.
>> The outcome was to use the approach listed in
>> http://njbartlett.name/2014/05/26/static-linking.html <
>> http://njbartlett.name/2014/05/26/static-linking.html> to embed one
>> package from Commons OSGi in Sling Models Impl (but not export it, of
>> course).
>> 
>> There is a drawback with that approach, related to the way how the
>> maven-bundle-plugin and bnd works internally.
>> Actually if you depend on both Sling Models Impl (1.2) and Commons OSGi
>> (2.2) in your own bundle you might end up having an import-package
>> statement with the wrong version range [2.3, 3) instead of [2.2, 3).
>> This is because bnd figures out the version range by looking at the
>> compile class path and just looks at the first package (and extracting the
>> version in this case from its package-info).
>> If the first dependency on the class path is now Sling Models Impl, bnd
>> implicitly assumes, that the package is exported from the dependency
>> (without looking at the manifest).
>> I opened a bug at bnd on that: https://github.com/bndtools/bnd/issues/1017
>> <https://github.com/bndtools/bnd/issues/1017>.
>> 
>> Should we do anything about it now in the Sling code base until the bug of
>> bnd is fixed upstream. Probably just stripping the package-info.class from
>> org.apache.sling.commons.osgi in Sling Models Impl would be enough, but
>> then we can no longer use the automatism of “Conditional-Package”.
>> This issue would affect right now Sling Mock (
>> https://github.com/apache/sling/blob/trunk/testing/mocks/sling-mock/pom.xml
>> <
>> https://github.com/apache/sling/blob/trunk/testing/mocks/sling-mock/pom.xml>)
>> because that one depends first on org.apache.sling.models.impl and only
>> after that on org.apache.sling.commons.osgi. At least that we should fix.
>> 
>> Do you have any other idea on how to fix that?
>> Thanks,
>> Konrad
>> 
>>

1 2 3 4 5 6 7 8 9 10 >

1 - 100 of 7057 matches

Mail list logo