[jira] [Issue Comment Deleted] (SLING-3657) Create a ResourceMerger-style ResourceProvider which merges based on resource super types

[Justin Edelson (JIRA)]

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

Justin Edelson updated SLING-3657:
--

Comment: was deleted

(was: I am out of office, back on June 22.

regards

antonio


)

> Create a ResourceMerger-style ResourceProvider which merges based on resource 
> super types
> -
>
> Key: SLING-3657
> URL: https://issues.apache.org/jira/browse/SLING-3657
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>    Reporter: Justin Edelson
> Attachments: SLING-3657.patch
>
>
> The current MergingResourceProvider does a good job of a single use case - 
> merging resources relative to the search paths. A second use case for merging 
> is to merge resources based on their sling:resourceSuperType inheritance, i.e.
> /content/siteA@sling:resourceSuperType=/content/siteB
> /content/siteB@sling:resourceSuperType=/content/siteC
> It should be possible to generate a merged resource which combines 
> /content/siteA, /content/siteB, and /content/siteC (in reverse order so that 
> siteA overrides siteB, etc.).



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Issue Comment Deleted] (SLING-3657) Create a ResourceMerger-style ResourceProvider which merges based on resource super types

[Justin Edelson (JIRA)]

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

Justin Edelson updated SLING-3657:
--

Comment: was deleted

(was: I am out of office, back on June 22.

regards

antonio


)

> Create a ResourceMerger-style ResourceProvider which merges based on resource 
> super types
> -
>
> Key: SLING-3657
> URL: https://issues.apache.org/jira/browse/SLING-3657
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>    Reporter: Justin Edelson
> Attachments: SLING-3657.patch
>
>
> The current MergingResourceProvider does a good job of a single use case - 
> merging resources relative to the search paths. A second use case for merging 
> is to merge resources based on their sling:resourceSuperType inheritance, i.e.
> /content/siteA@sling:resourceSuperType=/content/siteB
> /content/siteB@sling:resourceSuperType=/content/siteC
> It should be possible to generate a merged resource which combines 
> /content/siteA, /content/siteB, and /content/siteC (in reverse order so that 
> siteA overrides siteB, etc.).



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Issue Comment Deleted] (SLING-3657) Create a ResourceMerger-style ResourceProvider which merges based on resource super types

[Justin Edelson (JIRA)]

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

Justin Edelson updated SLING-3657:
--

Comment: was deleted

(was: I am out of office, back on June 22.

regards

antonio


)

> Create a ResourceMerger-style ResourceProvider which merges based on resource 
> super types
> -
>
> Key: SLING-3657
> URL: https://issues.apache.org/jira/browse/SLING-3657
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>    Reporter: Justin Edelson
> Attachments: SLING-3657.patch
>
>
> The current MergingResourceProvider does a good job of a single use case - 
> merging resources relative to the search paths. A second use case for merging 
> is to merge resources based on their sling:resourceSuperType inheritance, i.e.
> /content/siteA@sling:resourceSuperType=/content/siteB
> /content/siteB@sling:resourceSuperType=/content/siteC
> It should be possible to generate a merged resource which combines 
> /content/siteA, /content/siteB, and /content/siteC (in reverse order so that 
> siteA overrides siteB, etc.).



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (SLING-3869) Sling Models: Apache Branding in Bundle Name

[Justin Edelson (JIRA)]

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

Justin Edelson commented on SLING-3869:
---

patch applied in r1619575

Thanks!

> Sling Models: Apache Branding in Bundle Name
> 
>
> Key: SLING-3869
> URL: https://issues.apache.org/jira/browse/SLING-3869
> Project: Sling
>  Issue Type: Task
>  Components: Extensions
>Affects Versions: Sling Models Implementation 1.0.6, Sling Models API 1.0.2
>Reporter: Stefan Seifert
>Assignee: Justin Edelson
>Priority: Trivial
>  Labels: models
> Fix For: Sling Models Implementation 1.0.8, Sling Models API 1.0.4
>
> Attachments: 140821_SLING-3869_models_branding.patch
>
>   Original Estimate: 0h
>  Remaining Estimate: 0h
>
> unlike the most other sling models the two sling models projects have no 
> "Apache" prefix in their artifact name (which becomes the bundle name as 
> well).
> the attached patch fixes this, and fixes a last remnant of the old "YAMF" 
> name in the API JavaDocs as well.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (SLING-3869) Sling Models: Apache Branding in Bundle Name

[Justin Edelson (JIRA)]

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

Justin Edelson updated SLING-3869:
--

  Assignee: Justin Edelson
Remaining Estimate: 0h
 Original Estimate: 0h

> Sling Models: Apache Branding in Bundle Name
> 
>
> Key: SLING-3869
> URL: https://issues.apache.org/jira/browse/SLING-3869
> Project: Sling
>  Issue Type: Task
>  Components: Extensions
>Affects Versions: Sling Models Implementation 1.0.6, Sling Models API 1.0.2
>Reporter: Stefan Seifert
>    Assignee: Justin Edelson
>Priority: Trivial
>  Labels: models
> Fix For: Sling Models Implementation 1.0.8, Sling Models API 1.0.4
>
> Attachments: 140821_SLING-3869_models_branding.patch
>
>   Original Estimate: 0h
>  Remaining Estimate: 0h
>
> unlike the most other sling models the two sling models projects have no 
> "Apache" prefix in their artifact name (which becomes the bundle name as 
> well).
> the attached patch fixes this, and fixes a last remnant of the old "YAMF" 
> name in the API JavaDocs as well.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (SLING-3869) Sling Models: Apache Branding in Bundle Name

[Justin Edelson (JIRA)]

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

Justin Edelson resolved SLING-3869.
---

Resolution: Fixed

> Sling Models: Apache Branding in Bundle Name
> 
>
> Key: SLING-3869
> URL: https://issues.apache.org/jira/browse/SLING-3869
> Project: Sling
>  Issue Type: Task
>  Components: Extensions
>Affects Versions: Sling Models Implementation 1.0.6, Sling Models API 1.0.2
>Reporter: Stefan Seifert
>    Assignee: Justin Edelson
>Priority: Trivial
>  Labels: models
> Fix For: Sling Models Implementation 1.0.8, Sling Models API 1.0.4
>
> Attachments: 140821_SLING-3869_models_branding.patch
>
>   Original Estimate: 0h
>  Remaining Estimate: 0h
>
> unlike the most other sling models the two sling models projects have no 
> "Apache" prefix in their artifact name (which becomes the bundle name as 
> well).
> the attached patch fixes this, and fixes a last remnant of the old "YAMF" 
> name in the API JavaDocs as well.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (SLING-3870) Add ability for Adapter Web Console Plugin to display deprecated adapter factories

[Justin Edelson (JIRA)]

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

Justin Edelson updated SLING-3870:
--

Remaining Estimate: 0h
 Original Estimate: 0h

> Add ability for Adapter Web Console Plugin to display deprecated adapter 
> factories
> --
>
> Key: SLING-3870
> URL: https://issues.apache.org/jira/browse/SLING-3870
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>    Reporter: Justin Edelson
>    Assignee: Justin Edelson
> Fix For: Adapter 2.1.2
>
>   Original Estimate: 0h
>  Remaining Estimate: 0h
>
> As discussed in http://sling.markmail.org/thread/cvmnd4rulaockem5, there 
> should be an indication in the web console that an adapter factory is 
> deprecated.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (SLING-3870) Add ability for Adapter Web Console Plugin to display deprecated adapter factories

[Justin Edelson (JIRA)]

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

Justin Edelson resolved SLING-3870.
---

Resolution: Fixed

> Add ability for Adapter Web Console Plugin to display deprecated adapter 
> factories
> --
>
> Key: SLING-3870
> URL: https://issues.apache.org/jira/browse/SLING-3870
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>    Reporter: Justin Edelson
>    Assignee: Justin Edelson
> Fix For: Adapter 2.1.2
>
>   Original Estimate: 0h
>  Remaining Estimate: 0h
>
> As discussed in http://sling.markmail.org/thread/cvmnd4rulaockem5, there 
> should be an indication in the web console that an adapter factory is 
> deprecated.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (SLING-3870) Add ability for Adapter Web Console Plugin to display deprecated adapter factories

[Justin Edelson (JIRA)]

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

Justin Edelson commented on SLING-3870:
---

fixed in r1619572

Property name is adapter.deprecated

> Add ability for Adapter Web Console Plugin to display deprecated adapter 
> factories
> --
>
> Key: SLING-3870
> URL: https://issues.apache.org/jira/browse/SLING-3870
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>    Reporter: Justin Edelson
>Assignee: Justin Edelson
> Fix For: Adapter 2.1.2
>
>   Original Estimate: 0h
>  Remaining Estimate: 0h
>
> As discussed in http://sling.markmail.org/thread/cvmnd4rulaockem5, there 
> should be an indication in the web console that an adapter factory is 
> deprecated.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (SLING-3869) Sling Models: Apache Branding in Bundle Name

[Justin Edelson (JIRA)]

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

Justin Edelson updated SLING-3869:
--

Labels: models  (was: )

> Sling Models: Apache Branding in Bundle Name
> 
>
> Key: SLING-3869
> URL: https://issues.apache.org/jira/browse/SLING-3869
> Project: Sling
>  Issue Type: Task
>  Components: Extensions
>Affects Versions: Sling Models Implementation 1.0.6, Sling Models API 1.0.2
>Reporter: Stefan Seifert
>Priority: Trivial
>  Labels: models
> Fix For: Sling Models Implementation 1.0.8, Sling Models API 1.0.4
>
> Attachments: 140821_SLING-3869_models_branding.patch
>
>
> unlike the most other sling models the two sling models projects have no 
> "Apache" prefix in their artifact name (which becomes the bundle name as 
> well).
> the attached patch fixes this, and fixes a last remnant of the old "YAMF" 
> name in the API JavaDocs as well.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Re: [VOTE] Release Apache Sling Commons Mime 2.1.8, Commons Scheduler 2.4.4, and Event 3.3.14

[Justin Edelson]

+1

On Thu, Aug 21, 2014 at 9:24 AM, Robert Munteanu  wrote:
> +1
>
> Robert
>
> On Thu, Aug 21, 2014 at 2:35 PM, Carsten Ziegeler  
> wrote:
>> Hi,
>>
>> some more releases for Sling 7:
>>
>> Commons Mime 2.1.8
>> https://issues.apache.org/jira/browse/SLING/fixforversion/12327650
>>
>> Commons Scheduler 2.4.4
>> https://issues.apache.org/jira/browse/SLING/fixforversion/12325300
>> 
>>
>> Event 3.3.14
>> https://issues.apache.org/jira/browse/SLING/fixforversion/12327555
>>
>> Staging repository:
>> https://repository.apache.org/content/repositories/orgapachesling-1092
>>
>> You can use this UNIX script to download the release and verify the
>> signatures:
>> http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh
>>
>> Usage:
>> sh check_staged_release.sh 1092 /tmp/sling-staging
>>
>> Please vote to approve this release:
>>
>>   [ ] +1 Approve the release
>>   [ ]  0 Don't care
>>   [ ] -1 Don't release, because ...
>>
>> This majority vote is open for at least 72 hours.
>>
>> Regards
>> Carsten
>> --
>> Carsten Ziegeler
>> Adobe Research Switzerland
>> cziege...@apache.org

Re: Deprecating JcrResource.adaptTo(URL) ?

[Justin Edelson]

Ugh. I realized this one is a bit more complicated to deprecate in the
way I was thinking. JcrResource.adaptTo(URL.class) is implemented as
an adaptation within JcrResource along with several others. I was
thinking that we would flag the whole adapter factory as deprecated. I
don't see a practical way to mark a single adapation within an
adaptable or an adapter factory as deprecated.

Sigh...

On Thu, Aug 21, 2014 at 7:19 AM, Jeff Young  wrote:
> +1 (to deprecating adaptTo(URL), and to deprecation comments in the other
> thread)
>
> Cheers,
> Jeff.
>
>
> On 20/08/2014 17:29, "Justin Edelson"  wrote:
>
>>Hi,
>>I'm fine with this, although I'm see my other email about what it
>>means to deprecate an adapter factory.
>>
>>Justin
>>
>>On Wed, Aug 20, 2014 at 11:59 AM, Carsten Ziegeler 
>>wrote:
>>> Hi,
>>>
>>> the JCR Resource implementation currently allows to adapt it to a url
>>>which
>>> internally embeds several jackrabbit classes. The returned object keeps
>>> hold of the current session and therefore is a potential memory leak and
>>> can't be used once the session is closed.
>>> So far I've not seen any real use case for this and especially as other
>>> resource implementations do not provide it, what about deprecating this
>>> now, logging a big message when used (once) and then we can remove it in
>>> one of the next versions?
>>>
>>> Regards
>>> Carsten
>>> --
>>> Carsten Ziegeler
>>> Adobe Research Switzerland
>>> cziege...@apache.org
>

[jira] [Created] (SLING-3870) Add ability for Adapter Web Console Plugin to display deprecated adapter factories

[Justin Edelson (JIRA)]

Justin Edelson created SLING-3870:
-

 Summary: Add ability for Adapter Web Console Plugin to display 
deprecated adapter factories
 Key: SLING-3870
 URL: https://issues.apache.org/jira/browse/SLING-3870
 Project: Sling
  Issue Type: Improvement
  Components: Extensions
Reporter: Justin Edelson
Assignee: Justin Edelson
 Fix For: Adapter 2.1.2


As discussed in http://sling.markmail.org/thread/cvmnd4rulaockem5, there should 
be an indication in the web console that an adapter factory is deprecated.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Re: Removing or at least deprecating JcrItemAdapterFactory

[Justin Edelson]

OK. For now, let's leave the logging as the responsibilty of the
factory and add an adapter.deprecated service registration property
for the console to pick up.

Justin

On Wed, Aug 20, 2014 at 12:33 PM, Carsten Ziegeler  wrote:
> I think we don't - and for now it would be the factory implementation doing
> the stuff. It would be great to show something in the console. Maybe
> through the annotations?
>
> Carsten
>
>
> 2014-08-20 18:26 GMT+02:00 Justin Edelson :
>
>> This would be OK with me. Out of curiosity, do we actually have a way
>> of deprecating adapter factories? Or would such a warning be the
>> responsibility of the adapter factory? Should we add something to the
>> web console plugin to indicate that an adaption is deprecated.
>>
>> Justin
>>
>> On Wed, Aug 20, 2014 at 11:57 AM, Carsten Ziegeler 
>> wrote:
>> > Yes,
>> >
>> > so how do you feel about deprecating it, log a bold message (once) - and
>> > then maybe remove it in one of the next versions?
>> >
>> > Regards
>> > Carsten
>> >
>> >
>> > 2014-08-20 17:48 GMT+02:00 Justin Edelson :
>> >
>> >> Hi Carsten,
>> >> I'd rather keep it, but... I don't actually see a good way to fix
>> >> SLING-3859, so it might be more expedient to deprecate this. Or at
>> >> least log a warning that the ResourceResolver must be manually closed.
>> >>
>> >> Justin
>> >>
>> >> On Wed, Aug 20, 2014 at 11:29 AM, Carsten Ziegeler <
>> cziege...@apache.org>
>> >> wrote:
>> >> > Thanks Justin,
>> >> >
>> >> > so either we have to fix the memory leak or go without it :) What do
>> you
>> >> > prefer?
>> >> >
>> >> > Regards
>> >> > Carsten
>> >> >
>> >> >
>> >> > 2014-08-20 13:52 GMT+02:00 Justin Edelson :
>> >> >
>> >> >> Hi,
>> >> >>
>> >> >> On Wed, Aug 20, 2014 at 1:47 AM, Bertrand Delacretaz
>> >> >>  wrote:
>> >> >> > Hi,
>> >> >> >
>> >> >> > On Tue, Aug 19, 2014 at 8:38 PM, Carsten Ziegeler <
>> >> cziege...@apache.org>
>> >> >> wrote:
>> >> >> >> ...I think this adaption is conceptually wrong and I have no idea
>> why
>> >> >> we added
>> >> >> >> this in the first place, so adding this to the memory leak
>> problem, I
>> >> >> would
>> >> >> >> simply remove this thing
>> >> >> >
>> >> >> > It was added by Justin for SLING-2315 - I am ok with deprecating
>> and
>> >> >> > later removing it, but let's hear Justin.
>> >> >>
>> >> >> I find this to be of high utility when dealing with legacy code which
>> >> >> only makes a Node object available. I don't actually know that I've
>> >> >> ever used the Property adaptatation part, but I definitely use the
>> >> >> Node -> Resource adaptation a few times a year. Could I live without
>> >> >> it? Sure, especially as now that the ResourceResolverFactory code is
>> >> >> much more complex than it was at the time.
>> >> >>
>> >> >> Justin
>> >> >>
>> >> >> >
>> >> >> > -Bertrand
>> >> >>
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > Carsten Ziegeler
>> >> > Adobe Research Switzerland
>> >> > cziege...@apache.org
>> >>
>> >
>> >
>> >
>> > --
>> > Carsten Ziegeler
>> > Adobe Research Switzerland
>> > cziege...@apache.org
>>
>
>
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org

[jira] [Commented] (SLING-3715) Sling Models: Support for class-based dependency injection

[Justin Edelson (JIRA)]

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

Justin Edelson commented on SLING-3715:
---

At first glance, I think this is a fair approach. It recognizes that these are 
special cases. The only one I'm worried about is the Resource object, but I 
need to tease that scenario about a bit more in my head.

> Sling Models: Support for class-based dependency injection
> --
>
> Key: SLING-3715
> URL: https://issues.apache.org/jira/browse/SLING-3715
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Stefan Seifert
>Priority: Minor
>  Labels: models
> Attachments: 140820_SLING-3715_sling-object-injector.patch
>
>
> Currently Sling Models dependency injection is primary based on parameter 
> name-based injection, and not on class-based injection (the latter is more 
> common in Spring and comparable frameworks).
> here is Justins opinion on this topic (from the mailing list) and why he 
> prefers name-based injection:
> {quote}
> Hi Stefan,
> The big problem IMHO with injecting by class vs. name is that by class
> is too ambigious in many cases. For example, in AEM, it is relatively
> common to want to inject a Page object, but in fact there are two
> different page objects which come into play (currentPage and
> resourcePage) and getting the wrong one could be highly problematic.
> You are correct that things like the request and response could
> presumably be injected by class rather than by name, but the question
> then becomes how do we judge these cases? In my opinion, the bindings
> names are sensible. I personally don't find myself wanting to write
> this very often:
> {code:java}
> @Inject
> private SlingHttpServletRequest somenameOtherThanRequest;
> {code}
> \[...\]
> Regards,
> Justin
> {quote}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (SLING-3863) Sling Models: Injections fails for optional primitive types without default values

[Justin Edelson (JIRA)]

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

Justin Edelson commented on SLING-3863:
---

Thanks. I neglected to account for that case. It is fixed now in r1619212.

> Sling Models: Injections fails for optional primitive types without default 
> values
> --
>
> Key: SLING-3863
> URL: https://issues.apache.org/jira/browse/SLING-3863
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: Sling Models Implementation 1.0.6
>Reporter: Stefan Seifert
>Assignee: Justin Edelson
>Priority: Minor
>  Labels: models
> Fix For: Sling Models Implementation 1.0.8
>
> Attachments: 140820_SLING-3863_additional_unit_tests.patch, 
> 140820_SLING-3863_primitives_optional.patch
>
>   Original Estimate: 0h
>  Remaining Estimate: 0h
>
> Sling models injections for interfaces and constructor fails if:
> * the type to inject is a primitive type
> * its marked as optional
> * and there is no value to inject
> in this case it is tried to inject null which fails because null is not 
> allowed for a primitive.
> patch attached.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (SLING-3863) Sling Models: Injections fails for optional primitive types without default values

[Justin Edelson (JIRA)]

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

Justin Edelson resolved SLING-3863.
---

Resolution: Fixed

> Sling Models: Injections fails for optional primitive types without default 
> values
> --
>
> Key: SLING-3863
> URL: https://issues.apache.org/jira/browse/SLING-3863
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: Sling Models Implementation 1.0.6
>Reporter: Stefan Seifert
>Assignee: Justin Edelson
>Priority: Minor
>  Labels: models
> Fix For: Sling Models Implementation 1.0.8
>
> Attachments: 140820_SLING-3863_additional_unit_tests.patch, 
> 140820_SLING-3863_primitives_optional.patch
>
>   Original Estimate: 0h
>  Remaining Estimate: 0h
>
> Sling models injections for interfaces and constructor fails if:
> * the type to inject is a primitive type
> * its marked as optional
> * and there is no value to inject
> in this case it is tried to inject null which fails because null is not 
> allowed for a primitive.
> patch attached.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (SLING-3863) Sling Models: Injections fails for optional primitive types without default values

[Justin Edelson (JIRA)]

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

Justin Edelson commented on SLING-3863:
---

Thanks Stefan. I modified the patch a bit and applied it in r1619199. I found 
the two Type parameters a bit confusing, so instead I have the Callback object 
decide whether or not the initial primitive value should be injected.

> Sling Models: Injections fails for optional primitive types without default 
> values
> --
>
> Key: SLING-3863
> URL: https://issues.apache.org/jira/browse/SLING-3863
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: Sling Models Implementation 1.0.6
>Reporter: Stefan Seifert
>Assignee: Justin Edelson
>Priority: Minor
>  Labels: models
> Fix For: Sling Models Implementation 1.0.8
>
> Attachments: 140820_SLING-3863_primitives_optional.patch
>
>   Original Estimate: 0h
>  Remaining Estimate: 0h
>
> Sling models injections for interfaces and constructor fails if:
> * the type to inject is a primitive type
> * its marked as optional
> * and there is no value to inject
> in this case it is tried to inject null which fails because null is not 
> allowed for a primitive.
> patch attached.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (SLING-3863) Sling Models: Injections fails for optional primitive types without default values

[Justin Edelson (JIRA)]

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

Justin Edelson updated SLING-3863:
--

  Assignee: Justin Edelson
Remaining Estimate: 0h
 Original Estimate: 0h

> Sling Models: Injections fails for optional primitive types without default 
> values
> --
>
> Key: SLING-3863
> URL: https://issues.apache.org/jira/browse/SLING-3863
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: Sling Models Implementation 1.0.6
>Reporter: Stefan Seifert
>Assignee: Justin Edelson
>Priority: Minor
>  Labels: models
> Fix For: Sling Models Implementation 1.0.8
>
> Attachments: 140820_SLING-3863_primitives_optional.patch
>
>   Original Estimate: 0h
>  Remaining Estimate: 0h
>
> Sling models injections for interfaces and constructor fails if:
> * the type to inject is a primitive type
> * its marked as optional
> * and there is no value to inject
> in this case it is tried to inject null which fails because null is not 
> allowed for a primitive.
> patch attached.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (SLING-3863) Sling Models: Injections fails for optional primitive types without default values

[Justin Edelson (JIRA)]

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

Justin Edelson resolved SLING-3863.
---

Resolution: Fixed

> Sling Models: Injections fails for optional primitive types without default 
> values
> --
>
> Key: SLING-3863
> URL: https://issues.apache.org/jira/browse/SLING-3863
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: Sling Models Implementation 1.0.6
>Reporter: Stefan Seifert
>Assignee: Justin Edelson
>Priority: Minor
>  Labels: models
> Fix For: Sling Models Implementation 1.0.8
>
> Attachments: 140820_SLING-3863_primitives_optional.patch
>
>   Original Estimate: 0h
>  Remaining Estimate: 0h
>
> Sling models injections for interfaces and constructor fails if:
> * the type to inject is a primitive type
> * its marked as optional
> * and there is no value to inject
> in this case it is tried to inject null which fails because null is not 
> allowed for a primitive.
> patch attached.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Re: Deprecating JcrResource.adaptTo(URL) ?

[Justin Edelson]

Hi,
I'm fine with this, although I'm see my other email about what it
means to deprecate an adapter factory.

Justin

On Wed, Aug 20, 2014 at 11:59 AM, Carsten Ziegeler  wrote:
> Hi,
>
> the JCR Resource implementation currently allows to adapt it to a url which
> internally embeds several jackrabbit classes. The returned object keeps
> hold of the current session and therefore is a potential memory leak and
> can't be used once the session is closed.
> So far I've not seen any real use case for this and especially as other
> resource implementations do not provide it, what about deprecating this
> now, logging a big message when used (once) and then we can remove it in
> one of the next versions?
>
> Regards
> Carsten
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org

Re: Removing or at least deprecating JcrItemAdapterFactory

[Justin Edelson]

This would be OK with me. Out of curiosity, do we actually have a way
of deprecating adapter factories? Or would such a warning be the
responsibility of the adapter factory? Should we add something to the
web console plugin to indicate that an adaption is deprecated.

Justin

On Wed, Aug 20, 2014 at 11:57 AM, Carsten Ziegeler  wrote:
> Yes,
>
> so how do you feel about deprecating it, log a bold message (once) - and
> then maybe remove it in one of the next versions?
>
> Regards
> Carsten
>
>
> 2014-08-20 17:48 GMT+02:00 Justin Edelson :
>
>> Hi Carsten,
>> I'd rather keep it, but... I don't actually see a good way to fix
>> SLING-3859, so it might be more expedient to deprecate this. Or at
>> least log a warning that the ResourceResolver must be manually closed.
>>
>> Justin
>>
>> On Wed, Aug 20, 2014 at 11:29 AM, Carsten Ziegeler 
>> wrote:
>> > Thanks Justin,
>> >
>> > so either we have to fix the memory leak or go without it :) What do you
>> > prefer?
>> >
>> > Regards
>> > Carsten
>> >
>> >
>> > 2014-08-20 13:52 GMT+02:00 Justin Edelson :
>> >
>> >> Hi,
>> >>
>> >> On Wed, Aug 20, 2014 at 1:47 AM, Bertrand Delacretaz
>> >>  wrote:
>> >> > Hi,
>> >> >
>> >> > On Tue, Aug 19, 2014 at 8:38 PM, Carsten Ziegeler <
>> cziege...@apache.org>
>> >> wrote:
>> >> >> ...I think this adaption is conceptually wrong and I have no idea why
>> >> we added
>> >> >> this in the first place, so adding this to the memory leak problem, I
>> >> would
>> >> >> simply remove this thing
>> >> >
>> >> > It was added by Justin for SLING-2315 - I am ok with deprecating and
>> >> > later removing it, but let's hear Justin.
>> >>
>> >> I find this to be of high utility when dealing with legacy code which
>> >> only makes a Node object available. I don't actually know that I've
>> >> ever used the Property adaptatation part, but I definitely use the
>> >> Node -> Resource adaptation a few times a year. Could I live without
>> >> it? Sure, especially as now that the ResourceResolverFactory code is
>> >> much more complex than it was at the time.
>> >>
>> >> Justin
>> >>
>> >> >
>> >> > -Bertrand
>> >>
>> >
>> >
>> >
>> > --
>> > Carsten Ziegeler
>> > Adobe Research Switzerland
>> > cziege...@apache.org
>>
>
>
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org

[jira] [Commented] (SLING-3822) Sling Models Documentation: Please document the separator for

[Justin Edelson (JIRA)]

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

Justin Edelson commented on SLING-3822:
---

good suggestion. site has been updated.

> Sling Models Documentation: Please document the separator for 
> 
> 
>
> Key: SLING-3822
> URL: https://issues.apache.org/jira/browse/SLING-3822
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>Affects Versions: Sling Models API 1.0.2
>Reporter: Konrad Windszus
>Assignee: Justin Edelson
>  Labels: models
>   Original Estimate: 0h
>  Remaining Estimate: 0h
>
> Currently in http://sling.apache.org/documentation/bundles/models.html there 
> is only an example on how to use the Sling-Model-Packages header. 
> Please add the information, that one may list multiple packages within that  
> header separated by ",". Also please explicitly state that only one such 
> header is allowed per Bundle manifest.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (SLING-3822) Sling Models Documentation: Please document the separator for

[Justin Edelson (JIRA)]

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

Justin Edelson resolved SLING-3822.
---

Resolution: Fixed

> Sling Models Documentation: Please document the separator for 
> 
> 
>
> Key: SLING-3822
> URL: https://issues.apache.org/jira/browse/SLING-3822
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>Affects Versions: Sling Models API 1.0.2
>Reporter: Konrad Windszus
>Assignee: Justin Edelson
>  Labels: models
>   Original Estimate: 0h
>  Remaining Estimate: 0h
>
> Currently in http://sling.apache.org/documentation/bundles/models.html there 
> is only an example on how to use the Sling-Model-Packages header. 
> Please add the information, that one may list multiple packages within that  
> header separated by ",". Also please explicitly state that only one such 
> header is allowed per Bundle manifest.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (SLING-3822) Sling Models Documentation: Please document the separator for

[Justin Edelson (JIRA)]

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

Justin Edelson updated SLING-3822:
--

  Assignee: Justin Edelson
Remaining Estimate: 0h
 Original Estimate: 0h

> Sling Models Documentation: Please document the separator for 
> 
> 
>
> Key: SLING-3822
> URL: https://issues.apache.org/jira/browse/SLING-3822
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>Affects Versions: Sling Models API 1.0.2
>Reporter: Konrad Windszus
>Assignee: Justin Edelson
>  Labels: models
>   Original Estimate: 0h
>  Remaining Estimate: 0h
>
> Currently in http://sling.apache.org/documentation/bundles/models.html there 
> is only an example on how to use the Sling-Model-Packages header. 
> Please add the information, that one may list multiple packages within that  
> header separated by ",". Also please explicitly state that only one such 
> header is allowed per Bundle manifest.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (SLING-3861) Sling Models: Add support for the condition field

[Justin Edelson (JIRA)]

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

Justin Edelson commented on SLING-3861:
---

Fixed in r1619134

> Sling Models: Add support for the condition field
> -
>
> Key: SLING-3861
> URL: https://issues.apache.org/jira/browse/SLING-3861
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Jason E Bailey
>    Assignee: Justin Edelson
>Priority: Trivial
>  Labels: models
> Fix For: Sling Models Implementation 1.0.8, Sling Models API 1.0.4
>
>   Original Estimate: 0h
>  Remaining Estimate: 0h
>
> Provide the option to define a condition field within the Model annotation 
> that will be used by the adapter web console plugin to provide additional 
> information about the adaptable



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (SLING-3861) Sling Models: Add support for the condition field

[Justin Edelson (JIRA)]

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

Justin Edelson resolved SLING-3861.
---

Resolution: Fixed

> Sling Models: Add support for the condition field
> -
>
> Key: SLING-3861
> URL: https://issues.apache.org/jira/browse/SLING-3861
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Jason E Bailey
>    Assignee: Justin Edelson
>Priority: Trivial
>  Labels: models
> Fix For: Sling Models Implementation 1.0.8, Sling Models API 1.0.4
>
>   Original Estimate: 0h
>  Remaining Estimate: 0h
>
> Provide the option to define a condition field within the Model annotation 
> that will be used by the adapter web console plugin to provide additional 
> information about the adaptable



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (SLING-3861) Sling Models: Add support for the condition field

[Justin Edelson (JIRA)]

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

Justin Edelson updated SLING-3861:
--

 Fix Version/s: Sling Models API 1.0.4
Sling Models Implementation 1.0.8
  Assignee: Justin Edelson
Remaining Estimate: 0h
 Original Estimate: 0h

> Sling Models: Add support for the condition field
> -
>
> Key: SLING-3861
> URL: https://issues.apache.org/jira/browse/SLING-3861
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Jason E Bailey
>    Assignee: Justin Edelson
>Priority: Trivial
>  Labels: models
> Fix For: Sling Models Implementation 1.0.8, Sling Models API 1.0.4
>
>   Original Estimate: 0h
>  Remaining Estimate: 0h
>
> Provide the option to define a condition field within the Model annotation 
> that will be used by the adapter web console plugin to provide additional 
> information about the adaptable



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Re: Removing or at least deprecating JcrItemAdapterFactory

[Justin Edelson]

Hi Carsten,
I'd rather keep it, but... I don't actually see a good way to fix
SLING-3859, so it might be more expedient to deprecate this. Or at
least log a warning that the ResourceResolver must be manually closed.

Justin

On Wed, Aug 20, 2014 at 11:29 AM, Carsten Ziegeler  wrote:
> Thanks Justin,
>
> so either we have to fix the memory leak or go without it :) What do you
> prefer?
>
> Regards
> Carsten
>
>
> 2014-08-20 13:52 GMT+02:00 Justin Edelson :
>
>> Hi,
>>
>> On Wed, Aug 20, 2014 at 1:47 AM, Bertrand Delacretaz
>>  wrote:
>> > Hi,
>> >
>> > On Tue, Aug 19, 2014 at 8:38 PM, Carsten Ziegeler 
>> wrote:
>> >> ...I think this adaption is conceptually wrong and I have no idea why
>> we added
>> >> this in the first place, so adding this to the memory leak problem, I
>> would
>> >> simply remove this thing
>> >
>> > It was added by Justin for SLING-2315 - I am ok with deprecating and
>> > later removing it, but let's hear Justin.
>>
>> I find this to be of high utility when dealing with legacy code which
>> only makes a Node object available. I don't actually know that I've
>> ever used the Property adaptatation part, but I definitely use the
>> Node -> Resource adaptation a few times a year. Could I live without
>> it? Sure, especially as now that the ResourceResolverFactory code is
>> much more complex than it was at the time.
>>
>> Justin
>>
>> >
>> > -Bertrand
>>
>
>
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org

Re: Removing or at least deprecating JcrItemAdapterFactory

[Justin Edelson]

Hi,

On Wed, Aug 20, 2014 at 1:47 AM, Bertrand Delacretaz
 wrote:
> Hi,
>
> On Tue, Aug 19, 2014 at 8:38 PM, Carsten Ziegeler  
> wrote:
>> ...I think this adaption is conceptually wrong and I have no idea why we 
>> added
>> this in the first place, so adding this to the memory leak problem, I would
>> simply remove this thing
>
> It was added by Justin for SLING-2315 - I am ok with deprecating and
> later removing it, but let's hear Justin.

I find this to be of high utility when dealing with legacy code which
only makes a Node object available. I don't actually know that I've
ever used the Property adaptatation part, but I definitely use the
Node -> Resource adaptation a few times a year. Could I live without
it? Sure, especially as now that the ResourceResolverFactory code is
much more complex than it was at the time.

Justin

>
> -Bertrand

[jira] [Created] (SLING-3860) Sling Models - max recursion depth should be configurable

[Justin Edelson (JIRA)]

Justin Edelson created SLING-3860:
-

 Summary: Sling Models - max recursion depth should be configurable
 Key: SLING-3860
 URL: https://issues.apache.org/jira/browse/SLING-3860
 Project: Sling
  Issue Type: Improvement
  Components: Extensions
Reporter: Justin Edelson


Currently, the maximum recursion depth is hard set at 20 in 
ModelAdapterFactory. This should be made configurable.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (SLING-3718) Sling Models: Add self Injector for supporting chains of object injecting dependencies from a common source

[Justin Edelson (JIRA)]

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

Justin Edelson resolved SLING-3718.
---

Resolution: Fixed

Resolved in r1619007. See SLING-3716 for more details.

> Sling Models: Add self Injector for supporting chains of object injecting 
> dependencies from a common source
> ---
>
> Key: SLING-3718
> URL: https://issues.apache.org/jira/browse/SLING-3718
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Stefan Seifert
>    Assignee: Justin Edelson
>Priority: Minor
> Fix For: Sling Models Implementation 1.0.8, Sling Models API 1.0.4
>
> Attachments: 
> 140701_SLING-3716_slingmodes_constructorinjection_SLING-3718_selfinjector.patch
>
>
> as discussed in my post on the sling mailing list
> http://mail-archives.apache.org/mod_mbox/sling-dev/201406.mbox/%3c580afa6c6dab8a4196956da5ee17c8ca8f7619e...@feanor.pro-vision.de%3E
> it would be very helpful to have a "self-adapting" injector to support chains 
> of objects (e.g. controller classes depending on business classes) that all 
> can adapt themselves from a common source, e.g. a SlingHttpServletRequest or 
> a ResourceResolver.
> souch an injector can be simple like this:
> {code:java}
> @Component
> @Service
> @Property(name = Constants.SERVICE_RANKING, intValue = 50)
> public class SelfAdaptInjector implements Injector {
>   public String getName() {
> return "selfadapt";
>   }
>   public Object getValue(Object pAdaptable, String pName, Type pType, 
> AnnotatedElement pElement,
> DisposalCallbackRegistry pCallbackRegistry) {
> if (!(pType instanceof Class)) {
>   return null;
> }
> if (!(pAdaptable instanceof Adaptable)) {
>   return null;
> }
> return ((Adaptable)pAdaptable).adaptTo((Class)pType);
>   }
> }
> {code}
> comment from Justin on this in the mailing list:
> {quote}
> The self injector is interesting. I held off on that initially because
> it seems too easy to create a circular injection. Any thoughts on how
> that can be avoided?
> \[...\]
> Regards,
> Justin
> {quote}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (SLING-3716) Sling Models: Add support for constructor dependency injection

[Justin Edelson (JIRA)]

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

Justin Edelson resolved SLING-3716.
---

Resolution: Fixed

Patch applied in r1619007. Thanks and sorry for the delay!

I made a few changes, mostly formatting and refactoring a few of the inner 
classes out of ModelInjectorFactory which has grown a bit too large.

The only significant change worth noting is that the patch changed the contract 
of the Injector interface to allow the use of a null name. Since this is 
potentially not backwards compatible, I instead decided to use a marker 
interface (AcceptsNullName).

I did not deal with the need to make the recursion depth configurable. Will 
create a separate issue for that.

> Sling Models: Add support for constructor dependency injection
> --
>
> Key: SLING-3716
> URL: https://issues.apache.org/jira/browse/SLING-3716
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Stefan Seifert
>    Assignee: Justin Edelson
>Priority: Minor
>  Labels: models
> Fix For: Sling Models Implementation 1.0.8, Sling Models API 1.0.4
>
> Attachments: 140701_SLING-3716_slingmodes_constructorinjection.patch
>
>
> Currently, Sling Models only supports dependency injection for fields (or 
> interface getter methods), but not for constructor arguments. This ticket is 
> for discussing what this constructor dependency injection should support, and 
> perhaps finally provide a patch to implement it.
> This is somewhat related to SLING-3715 for class-based dependency injection, 
> because this would come in especially handy for constructor injection.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Assigned] (SLING-3718) Sling Models: Add self Injector for supporting chains of object injecting dependencies from a common source

[Justin Edelson (JIRA)]

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

Justin Edelson reassigned SLING-3718:
-

Assignee: Justin Edelson

> Sling Models: Add self Injector for supporting chains of object injecting 
> dependencies from a common source
> ---
>
> Key: SLING-3718
> URL: https://issues.apache.org/jira/browse/SLING-3718
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Stefan Seifert
>    Assignee: Justin Edelson
>Priority: Minor
> Fix For: Sling Models Implementation 1.0.8, Sling Models API 1.0.4
>
> Attachments: 
> 140701_SLING-3716_slingmodes_constructorinjection_SLING-3718_selfinjector.patch
>
>
> as discussed in my post on the sling mailing list
> http://mail-archives.apache.org/mod_mbox/sling-dev/201406.mbox/%3c580afa6c6dab8a4196956da5ee17c8ca8f7619e...@feanor.pro-vision.de%3E
> it would be very helpful to have a "self-adapting" injector to support chains 
> of objects (e.g. controller classes depending on business classes) that all 
> can adapt themselves from a common source, e.g. a SlingHttpServletRequest or 
> a ResourceResolver.
> souch an injector can be simple like this:
> {code:java}
> @Component
> @Service
> @Property(name = Constants.SERVICE_RANKING, intValue = 50)
> public class SelfAdaptInjector implements Injector {
>   public String getName() {
> return "selfadapt";
>   }
>   public Object getValue(Object pAdaptable, String pName, Type pType, 
> AnnotatedElement pElement,
> DisposalCallbackRegistry pCallbackRegistry) {
> if (!(pType instanceof Class)) {
>   return null;
> }
> if (!(pAdaptable instanceof Adaptable)) {
>   return null;
> }
> return ((Adaptable)pAdaptable).adaptTo((Class)pType);
>   }
> }
> {code}
> comment from Justin on this in the mailing list:
> {quote}
> The self injector is interesting. I held off on that initially because
> it seems too easy to create a circular injection. Any thoughts on how
> that can be avoided?
> \[...\]
> Regards,
> Justin
> {quote}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (SLING-3718) Sling Models: Add self Injector for supporting chains of object injecting dependencies from a common source

[Justin Edelson (JIRA)]

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

Justin Edelson updated SLING-3718:
--

Fix Version/s: Sling Models API 1.0.4
   Sling Models Implementation 1.0.8

> Sling Models: Add self Injector for supporting chains of object injecting 
> dependencies from a common source
> ---
>
> Key: SLING-3718
> URL: https://issues.apache.org/jira/browse/SLING-3718
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Stefan Seifert
>    Assignee: Justin Edelson
>Priority: Minor
> Fix For: Sling Models Implementation 1.0.8, Sling Models API 1.0.4
>
> Attachments: 
> 140701_SLING-3716_slingmodes_constructorinjection_SLING-3718_selfinjector.patch
>
>
> as discussed in my post on the sling mailing list
> http://mail-archives.apache.org/mod_mbox/sling-dev/201406.mbox/%3c580afa6c6dab8a4196956da5ee17c8ca8f7619e...@feanor.pro-vision.de%3E
> it would be very helpful to have a "self-adapting" injector to support chains 
> of objects (e.g. controller classes depending on business classes) that all 
> can adapt themselves from a common source, e.g. a SlingHttpServletRequest or 
> a ResourceResolver.
> souch an injector can be simple like this:
> {code:java}
> @Component
> @Service
> @Property(name = Constants.SERVICE_RANKING, intValue = 50)
> public class SelfAdaptInjector implements Injector {
>   public String getName() {
> return "selfadapt";
>   }
>   public Object getValue(Object pAdaptable, String pName, Type pType, 
> AnnotatedElement pElement,
> DisposalCallbackRegistry pCallbackRegistry) {
> if (!(pType instanceof Class)) {
>   return null;
> }
> if (!(pAdaptable instanceof Adaptable)) {
>   return null;
> }
> return ((Adaptable)pAdaptable).adaptTo((Class)pType);
>   }
> }
> {code}
> comment from Justin on this in the mailing list:
> {quote}
> The self injector is interesting. I held off on that initially because
> it seems too easy to create a circular injection. Any thoughts on how
> that can be avoided?
> \[...\]
> Regards,
> Justin
> {quote}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Assigned] (SLING-3716) Sling Models: Add support for constructor dependency injection

[Justin Edelson (JIRA)]

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

Justin Edelson reassigned SLING-3716:
-

Assignee: Justin Edelson

> Sling Models: Add support for constructor dependency injection
> --
>
> Key: SLING-3716
> URL: https://issues.apache.org/jira/browse/SLING-3716
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Stefan Seifert
>    Assignee: Justin Edelson
>Priority: Minor
>  Labels: models
> Fix For: Sling Models Implementation 1.0.8, Sling Models API 1.0.4
>
> Attachments: 140701_SLING-3716_slingmodes_constructorinjection.patch
>
>
> Currently, Sling Models only supports dependency injection for fields (or 
> interface getter methods), but not for constructor arguments. This ticket is 
> for discussing what this constructor dependency injection should support, and 
> perhaps finally provide a patch to implement it.
> This is somewhat related to SLING-3715 for class-based dependency injection, 
> because this would come in especially handy for constructor injection.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (SLING-3716) Sling Models: Add support for constructor dependency injection

[Justin Edelson (JIRA)]

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

Justin Edelson updated SLING-3716:
--

Fix Version/s: Sling Models API 1.0.4
   Sling Models Implementation 1.0.8

> Sling Models: Add support for constructor dependency injection
> --
>
> Key: SLING-3716
> URL: https://issues.apache.org/jira/browse/SLING-3716
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Stefan Seifert
>    Assignee: Justin Edelson
>Priority: Minor
>  Labels: models
> Fix For: Sling Models Implementation 1.0.8, Sling Models API 1.0.4
>
> Attachments: 140701_SLING-3716_slingmodes_constructorinjection.patch
>
>
> Currently, Sling Models only supports dependency injection for fields (or 
> interface getter methods), but not for constructor arguments. This ticket is 
> for discussing what this constructor dependency injection should support, and 
> perhaps finally provide a patch to implement it.
> This is somewhat related to SLING-3715 for class-based dependency injection, 
> because this would come in especially handy for constructor injection.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (SLING-3822) Sling Models Documentation: Please document the separator for

[Justin Edelson (JIRA)]

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

Justin Edelson updated SLING-3822:
--

Labels: models  (was: )

> Sling Models Documentation: Please document the separator for 
> 
> 
>
> Key: SLING-3822
> URL: https://issues.apache.org/jira/browse/SLING-3822
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>Affects Versions: Sling Models API 1.0.2
>Reporter: Konrad Windszus
>  Labels: models
>
> Currently in http://sling.apache.org/documentation/bundles/models.html there 
> is only an example on how to use the Sling-Model-Packages header. 
> Please add the information, that one may list multiple packages within that  
> header separated by ",". Also please explicitly state that only one such 
> header is allowed per Bundle manifest.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (SLING-3715) Sling Models: Support for class-based dependency injection

[Justin Edelson (JIRA)]

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

Justin Edelson updated SLING-3715:
--

Labels: models  (was: )

> Sling Models: Support for class-based dependency injection
> --
>
> Key: SLING-3715
> URL: https://issues.apache.org/jira/browse/SLING-3715
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Stefan Seifert
>Priority: Minor
>  Labels: models
>
> Currently Sling Models dependency injection is primary based on parameter 
> name-based injection, and not on class-based injection (the latter is more 
> common in Spring and comparable frameworks).
> here is Justins opinion on this topic (from the mailing list) and why he 
> prefers name-based injection:
> {quote}
> Hi Stefan,
> The big problem IMHO with injecting by class vs. name is that by class
> is too ambigious in many cases. For example, in AEM, it is relatively
> common to want to inject a Page object, but in fact there are two
> different page objects which come into play (currentPage and
> resourcePage) and getting the wrong one could be highly problematic.
> You are correct that things like the request and response could
> presumably be injected by class rather than by name, but the question
> then becomes how do we judge these cases? In my opinion, the bindings
> names are sensible. I personally don't find myself wanting to write
> this very often:
> {code:java}
> @Inject
> private SlingHttpServletRequest somenameOtherThanRequest;
> {code}
> \[...\]
> Regards,
> Justin
> {quote}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (SLING-3716) Sling Models: Add support for constructor dependency injection

[Justin Edelson (JIRA)]

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

Justin Edelson updated SLING-3716:
--

Labels: models  (was: )

> Sling Models: Add support for constructor dependency injection
> --
>
> Key: SLING-3716
> URL: https://issues.apache.org/jira/browse/SLING-3716
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Stefan Seifert
>Priority: Minor
>  Labels: models
> Attachments: 140701_SLING-3716_slingmodes_constructorinjection.patch
>
>
> Currently, Sling Models only supports dependency injection for fields (or 
> interface getter methods), but not for constructor arguments. This ticket is 
> for discussing what this constructor dependency injection should support, and 
> perhaps finally provide a patch to implement it.
> This is somewhat related to SLING-3715 for class-based dependency injection, 
> because this would come in especially handy for constructor injection.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (SLING-3709) Sling Models: Allow caller to deal with exceptions

[Justin Edelson (JIRA)]

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

Justin Edelson updated SLING-3709:
--

Component/s: Extensions

> Sling Models: Allow caller to deal with exceptions
> --
>
> Key: SLING-3709
> URL: https://issues.apache.org/jira/browse/SLING-3709
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: Sling Models Implementation 1.0.4, Sling Models 
> Implementation 1.0.6
>Reporter: Konrad Windszus
>  Labels: models
>
> Currently due to the specification of the adaptTo-method to return null if 
> adaptation is not possible, the caller is not notified about any exceptions 
> (because they are caught within the ModelAdapterFactory).
> This is e.g. necessary to deal with validation exceptions properly (i.e. 
> required field injection not possible).  The problem was also discussed 
> briefly in 
> http://apache-sling.73963.n3.nabble.com/Silng-Models-Validation-Framework-td4033411.html.
> All exceptions either being thrown by the 
> @PostConstruct method or caused by the field/method injection are not 
> propagated but basically swallowed by Sling Models.
> It would be great to be able to catch those exceptions either in the view or 
> in a servlet filter. I think it should be possible to throw unchecked 
> exceptions in the ModelAdapterFactory.getFactory() method if it is requested 
> (i.e. through a global OSGi configuration flag for Sling Models).
> WDYT?
> Would you accept such a patch or do you think this breaks the API (also 
> compare with 
> https://issues.apache.org/jira/browse/SLING-2712?focusedCommentId=13561516&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13561516).
> If it does not work through the adaptTo, SlingModels should provide an 
> alternative way of instanciating models (and propagating exceptions), 
> although this is kind of tricky, because it internally relies on adaptTo as 
> well (e.g. in 
> https://github.com/apache/sling/blob/trunk/bundles/extensions/models/impl/src/main/java/org/apache/sling/models/impl/ModelAdapterFactory.java#L647)



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (SLING-3709) Sling Models: Allow caller to deal with exceptions

[Justin Edelson (JIRA)]

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

Justin Edelson updated SLING-3709:
--

Labels: models  (was: )

> Sling Models: Allow caller to deal with exceptions
> --
>
> Key: SLING-3709
> URL: https://issues.apache.org/jira/browse/SLING-3709
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: Sling Models Implementation 1.0.4, Sling Models 
> Implementation 1.0.6
>Reporter: Konrad Windszus
>  Labels: models
>
> Currently due to the specification of the adaptTo-method to return null if 
> adaptation is not possible, the caller is not notified about any exceptions 
> (because they are caught within the ModelAdapterFactory).
> This is e.g. necessary to deal with validation exceptions properly (i.e. 
> required field injection not possible).  The problem was also discussed 
> briefly in 
> http://apache-sling.73963.n3.nabble.com/Silng-Models-Validation-Framework-td4033411.html.
> All exceptions either being thrown by the 
> @PostConstruct method or caused by the field/method injection are not 
> propagated but basically swallowed by Sling Models.
> It would be great to be able to catch those exceptions either in the view or 
> in a servlet filter. I think it should be possible to throw unchecked 
> exceptions in the ModelAdapterFactory.getFactory() method if it is requested 
> (i.e. through a global OSGi configuration flag for Sling Models).
> WDYT?
> Would you accept such a patch or do you think this breaks the API (also 
> compare with 
> https://issues.apache.org/jira/browse/SLING-2712?focusedCommentId=13561516&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13561516).
> If it does not work through the adaptTo, SlingModels should provide an 
> alternative way of instanciating models (and propagating exceptions), 
> although this is kind of tricky, because it internally relies on adaptTo as 
> well (e.g. in 
> https://github.com/apache/sling/blob/trunk/bundles/extensions/models/impl/src/main/java/org/apache/sling/models/impl/ModelAdapterFactory.java#L647)



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Re: Sling Request Filter "filtering"

[Justin Edelson]

Hi Carsten,
Here's a few:
* I need to be able to modify a JSON object returned by a servlet, for
example to reorder objects in an array. In these cases, I have written
a filter which gets the serialized object returned by the servlet,
parses it, transforms it, and serializes it.
* I need to be able to skip an included resource based on some
criteria (a feature flag, a user profile, etc.). This can be done by
logic in the resource type's script, having it in a filter would be a
nicer separation of concerns.
* Something like CORS (which IMHO should be configurable on a
resource-type-level basis) would benefit from declarative
configuration.

TBC, nothing that Felix wrote originally can't be done today by
writing code inside the filter. But I think it would be more obvious
(and easier to configure) if it was done declaratively.

Justin


On Tue, Aug 19, 2014 at 12:27 PM, Carsten Ziegeler  wrote:
> Right, can we list some use cases for that stuff here?
>
> Carsten
>
>
> 2014-08-19 16:46 GMT+02:00 Justin Edelson :
>
>> Hi Carsten,
>> While path-based filtering can be done with plain servlet filters,
>> those don't have access to a ResourceResolver/Session/current
>> Resource. Which makes them suitable for some use cases, but not
>> others.
>>
>> Regards,
>> Justin
>>
>> On Mon, Aug 18, 2014 at 7:17 AM, Carsten Ziegeler 
>> wrote:
>> > Do we really really need this? At least path based filtering can be done
>> > with plain servlet filters already.
>> >
>> > What are the use cases for this?
>> >
>> > Carsten
>> >
>> >
>> > 2014-08-18 13:07 GMT+02:00 Felix Meschberger :
>> >
>> >> Hi
>> >>
>> >> I am not sure, whether we should go down that route.
>> >>
>> >> A filter ist something which is a cross-cutting concern that the
>> >> application places on the request processing. As such it is transparent
>> to
>> >> the client and it should not be client adressable. Otherwise unexpected
>> >> behaviour is guaranteed.
>> >>
>> >> Regards
>> >> Felix
>> >>
>> >> Am 18.08.2014 um 11:32 schrieb Bertrand Delacretaz <
>> bdelacre...@apache.org
>> >> >:
>> >>
>> >> > Hi,
>> >> >
>> >> > On Mon, Aug 18, 2014 at 11:23 AM, Felix Meschberger <
>> fmesc...@adobe.com>
>> >> wrote:
>> >> >> ... * filter.resourceType: The Filter is only called if the
>> resourceType
>> >> >>   of the current Resource (SlingHttpServletRequest.getResource)
>> >> >>   matches any of the given resource types...
>> >> >
>> >> > I've long been thinking that we should allow Sling's script/servlet
>> >> > resolution logic to be used for more than finding request processing
>> >> > servlets.
>> >> >
>> >> > Is it something that would apply here?
>> >> >
>> >> > I'm not sure how that could work, but as an initial experiment we
>> >> > could add a SLING-FILTER selector to the request, resolve that to a
>> >> > servlet and expect that to be a Filter. And if that works define that
>> >> > better as presented like this it's quite a hack ;-)
>> >> >
>> >> > -Bertrand
>> >>
>> >>
>> >
>> >
>> > --
>> > Carsten Ziegeler
>> > Adobe Research Switzerland
>> > cziege...@apache.org
>>
>
>
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org

Re: [VOTE] Apache Sling Commons Mime 2.1.6 and Apache Sling Commons OSGi 2.2.2

[Justin Edelson]

+1

On Tue, Aug 19, 2014 at 1:49 PM, Carsten Ziegeler  wrote:
> We're still missing a vote, anyone, please?
>
>
> 2014-08-19 5:30 GMT+02:00 Carsten Ziegeler :
>
>> I agree that the current way is not nice, but I think it's nothing which
>> should block the release.
>>
>> Anyone else who wants to vote?
>>
>> Regards
>> Carsten
>>
>>
>> 2014-08-18 23:44 GMT+02:00 Oliver Lietz :
>>
>> On Monday 18 August 2014 23:21:44 Oliver Lietz wrote:
>>> > On Monday 18 August 2014 13:38:15 Carsten Ziegeler wrote:
>>> > > Oliver, could you please revert your -1? Tika is not required and the
>>> > > bundle runs without it, the Tika provider does not run, but that's
>>> > > expected  - and I think this has already been the case for 2.1.4. So
>>> no
>>> > > new requirements for this bundle.
>>>
>>> The optional Tika import is new in 2.1.6. Maybe missing Tika can be
>>> handled
>>> more gracefully?
>>>
>>> O.
>>>
>>> > There is a problem with 2.1.6 as it throws the exception when running
>>> the
>>> > tests for Karaf - but I withdraw my vote as I do currently have no time
>>> to
>>> > investigate further.
>>> >
>>> > O.
>>> >
>>> > > Thanks
>>> > > Carsten
>>> > >
>>> > > 2014-08-18 12:44 GMT+02:00 Carsten Ziegeler :
>>> > > > Hmm, org.apache.tika.mime;resolution:=optional;version="[1.0,2)
>>> > > >
>>> > > >
>>> > > > 2014-08-17 19:24 GMT+02:00 Oliver Lietz :
>>> > > >
>>> > > > On Tuesday 12 August 2014 08:37:18 Carsten Ziegeler wrote:
>>> > > >> > Hi,
>>> > > >> >
>>> > > >> > in order to get Launchpad 7 out, this is a vote to release
>>> > > >> >
>>> > > >> > Commons Mime 2.1.6
>>> > > >> >
>>> https://issues.apache.org/jira/browse/SLING/fixforversion/12314795
>>> > > >> > <
>>> https://issues.apache.org/jira/browse/SLING/fixforversion/12326055>
>>> > > >>
>>> > > >> -1 as Commons Mime now depends also on Tika[1] and this should be
>>> > > >> reflected in
>>> > > >> the version
>>> > > >>
>>> > > >> > Commons OSGi 2.2.2
>>> > > >> >
>>> https://issues.apache.org/jira/browse/SLING/fixforversion/12323512
>>> > > >> > <
>>> https://issues.apache.org/jira/browse/SLING/fixforversion/12316095>
>>> > > >>
>>> > > >> +1
>>> > > >>
>>> > > >> O.
>>> > > >>
>>> > > >>
>>> > > >> [1]:
>>> > > >>
>>> > > >> 2014-08-17 17:55:24,354 | ERROR | FelixStartLevel  | mime
>>> > > >>
>>> > > >> | 118 - org.apache.sling.commons.mime - 2.1.6 |
>>> > > >>
>>> > > >> [org.apache.sling.commons.mime.internal.TikaMimeTypeProvider(21)]
>>> > > >> Error during
>>> > > >> instantiation of the implementation object
>>> > > >> java.lang.NoClassDefFoundError:
>>> org/apache/tika/mime/MimeTypeException
>>> > > >>
>>> > > >> at java.lang.Class.getDeclaredConstructors0(Native
>>> > > >>
>>> > > >> Method)[:1.6.0_65]
>>> > > >>
>>> > > >> at
>>> > > >>
>>>  java.lang.Class.privateGetDeclaredConstructors(Class.java:2446
>>> > > >> )
>>> > > >>
>>> > > >> [:1.6.0_65]
>>> > > >>
>>> > > >> at
>>> java.lang.Class.getConstructor0(Class.java:2756)[:1.6.0_65]
>>> > > >> at java.lang.Class.newInstance0(Class.java:328)[:1.6.0_65]
>>> > > >> at java.lang.Class.newInstance(Class.java:310)[:1.6.0_65]
>>> > > >>
>>> > > >> [...]
>>> > > >> Caused by: java.lang.ClassNotFoundException:
>>> > > >> org.apache.tika.mime.MimeTypeException not found by
>>> > > >> org.apache.sling.commons.mime [118]
>>> > > >>
>>> > > >> at
>>> > > >>
>>> > > >>
>>> org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDeleg
>>> > > >> at ion(BundleWiringImpl.java:1532)
>>> > > >> [org.apache.felix.framework-4.2.1.jar:]
>>> > > >>
>>> > > >> at
>>> > > >>
>>> > > >>
>>> org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImp
>>> > > >> l. java:75) [org.apache.felix.framework-4.2.1.jar:]
>>> > > >>
>>> > > >> at
>>> > > >>
>>> > > >>
>>> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClas
>>> > > >> s( BundleWiringImpl.java:1955)
>>> > > >>
>>> > > >> at
>>> > > >>
>>> > > >> java.lang.ClassLoader.loadClass(ClassLoader.java:247)[:1.6.0_65]
>>> > > >>
>>> > > >> ... 59 more
>>> > > >>
>>> > > >> 2014-08-17 17:55:24,356 | ERROR | FelixStartLevel  | mime
>>> > > >>
>>> > > >> | 118 - org.apache.sling.commons.mime - 2.1.6 |
>>> > > >>
>>> > > >> [org.apache.sling.commons.mime.internal.TikaMimeTypeProvider(21)]
>>> > > >> Failed creating the component instance; see log for reason
>>> > > >
>>> > > > --
>>> > > > Carsten Ziegeler
>>> > > > Adobe Research Switzerland
>>> > > > cziege...@apache.org
>>>
>>
>>
>>
>> --
>> Carsten Ziegeler
>> Adobe Research Switzerland
>> cziege...@apache.org
>>
>
>
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org

Re: Sling Request Filter "filtering"

[Justin Edelson]

Hi Carsten,
While path-based filtering can be done with plain servlet filters,
those don't have access to a ResourceResolver/Session/current
Resource. Which makes them suitable for some use cases, but not
others.

Regards,
Justin

On Mon, Aug 18, 2014 at 7:17 AM, Carsten Ziegeler  wrote:
> Do we really really need this? At least path based filtering can be done
> with plain servlet filters already.
>
> What are the use cases for this?
>
> Carsten
>
>
> 2014-08-18 13:07 GMT+02:00 Felix Meschberger :
>
>> Hi
>>
>> I am not sure, whether we should go down that route.
>>
>> A filter ist something which is a cross-cutting concern that the
>> application places on the request processing. As such it is transparent to
>> the client and it should not be client adressable. Otherwise unexpected
>> behaviour is guaranteed.
>>
>> Regards
>> Felix
>>
>> Am 18.08.2014 um 11:32 schrieb Bertrand Delacretaz > >:
>>
>> > Hi,
>> >
>> > On Mon, Aug 18, 2014 at 11:23 AM, Felix Meschberger 
>> wrote:
>> >> ... * filter.resourceType: The Filter is only called if the resourceType
>> >>   of the current Resource (SlingHttpServletRequest.getResource)
>> >>   matches any of the given resource types...
>> >
>> > I've long been thinking that we should allow Sling's script/servlet
>> > resolution logic to be used for more than finding request processing
>> > servlets.
>> >
>> > Is it something that would apply here?
>> >
>> > I'm not sure how that could work, but as an initial experiment we
>> > could add a SLING-FILTER selector to the request, resolve that to a
>> > servlet and expect that to be a Filter. And if that works define that
>> > better as presented like this it's quite a hack ;-)
>> >
>> > -Bertrand
>>
>>
>
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org

Re: Sling Request Filter "filtering"

[Justin Edelson]

Hi Dominik,
IIUC, the idea of Felix's original proposal was that the filter
developer and deployer could declaratively determine the specific set
of resource types to which a filter should be executed (whereas
currently that can only be done programatically and is largely ad hoc
when done at all). That would seem to solve for the problem you
identify where a filter only should get executed for certain resource
types. Because the platform doesn't have this capability today, *of
course* there are cases now where filters are executed when they
shouldn't.

IMHO, adding a negative configuration option, i.e. only execute this
filter *unless* the resource type doesn't match, is adding unnecessary
complexity. And even if it is deemed necessary, what Felix proposed
should be done first and then the need to have a negative option can
be reevaluated.

Regards,
Justin

On Mon, Aug 18, 2014 at 1:38 PM, Dominik Süß  wrote:
> Hi Justin,
> I'm not talking about global disable because the filter often is extremely
> necessary but to be able to disable it for dedicated cases. I just remember
> some obscure ColumnControlFilter only checking for the Pathending colctrl
> and autorewriting the node underneath. Turning off that filter would break
> a lot of funcitonality but it did mess around with nodes with a specific
> resourcetype, so I was missing an option to deactivate it for this very
> specific resourceType.
>
> Best regards
> Dominik
>
>
> On Mon, Aug 18, 2014 at 7:33 PM, Justin Edelson 
> wrote:
>
>> Hi,
>>
>> On Mon, Aug 18, 2014 at 1:30 PM, Dominik Süß 
>> wrote:
>> > Hi Felix,
>> >
>> > you probably remember our discussion - I checked and found out that
>> > resourceresolution is done with adminsession anyways and
>> superTypeHierarchy
>> > being cached (at least from what I remember) therefore this shouldn't add
>> > much overhead.
>> >
>> > IMHO an important point is that it needs to be possible to add rules
>> > without deployment. What I have in mind is some kind of blacklisting of
>> > filters that "by accident" act in a situation where they shouldn't. In an
>> > ideal world a dev directly can fix that, in reallity the filter might be
>> > owned by a third party and cannot be directly fixed and therefore be a
>> > blocker.
>>
>> Assuming this is all done by service registration properties, it is
>> all configurable. Just set the filter.ignore property to true. Whether
>> or not this counts as a "deployment" is up to you I suppose :)
>>
>> Regards,
>> Justin
>>
>> >
>> > Cheers
>> > Dominik
>> >
>> >
>> > On Mon, Aug 18, 2014 at 1:06 PM, Felix Meschberger 
>> > wrote:
>> >
>> >> Hi
>> >>
>> >> Am 18.08.2014 um 12:08 schrieb Jeff Young :
>> >>
>> >> > Hi Felix,
>> >> >
>> >> > I think to reduce the unexpected you'd need filter.resourceType to
>> match
>> >> > on the resource's supertype hierarchy too.
>> >>
>> >> Yeah, match could be ResourceUtil.isA(). But it should not be adding to
>> >> much overhead for the request processing.
>> >>
>> >> Regards
>> >> Felix
>> >>
>> >> >
>> >> > Cheers,
>> >> > Jeff.
>> >> >
>> >> >
>> >> > On 18/08/2014 10:23, "Felix Meschberger"  wrote:
>> >> >
>> >> >> Hi all
>> >> >>
>> >> >> I had various discussions around execution of Servlet API Filters in
>> the
>> >> >> Sling Engine.
>> >> >>
>> >> >> To recap: Currently all filters are always called. The
>> service.ranking
>> >> >> (or filter.order) service registration property can be used to define
>> >> the
>> >> >> order in which the filters are called and the filter.scope property
>> is
>> >> >> required to indicate at what stage in the request processing a filter
>> >> has
>> >> >> to be called. See [1] for the full story.
>> >> >>
>> >> >> Turns out, that it would be good to have some simple and global
>> flags to
>> >> >> indicate when a filter should actually be called or not. This would
>> be
>> >> >> similar to the filter mappings of traditional web applications, where
>> >> >> filters are bound to URL paths and

Re: Sling Request Filter "filtering"

[Justin Edelson]

Hi,

On Mon, Aug 18, 2014 at 1:30 PM, Dominik Süß  wrote:
> Hi Felix,
>
> you probably remember our discussion - I checked and found out that
> resourceresolution is done with adminsession anyways and superTypeHierarchy
> being cached (at least from what I remember) therefore this shouldn't add
> much overhead.
>
> IMHO an important point is that it needs to be possible to add rules
> without deployment. What I have in mind is some kind of blacklisting of
> filters that "by accident" act in a situation where they shouldn't. In an
> ideal world a dev directly can fix that, in reallity the filter might be
> owned by a third party and cannot be directly fixed and therefore be a
> blocker.

Assuming this is all done by service registration properties, it is
all configurable. Just set the filter.ignore property to true. Whether
or not this counts as a "deployment" is up to you I suppose :)

Regards,
Justin

>
> Cheers
> Dominik
>
>
> On Mon, Aug 18, 2014 at 1:06 PM, Felix Meschberger 
> wrote:
>
>> Hi
>>
>> Am 18.08.2014 um 12:08 schrieb Jeff Young :
>>
>> > Hi Felix,
>> >
>> > I think to reduce the unexpected you'd need filter.resourceType to match
>> > on the resource's supertype hierarchy too.
>>
>> Yeah, match could be ResourceUtil.isA(). But it should not be adding to
>> much overhead for the request processing.
>>
>> Regards
>> Felix
>>
>> >
>> > Cheers,
>> > Jeff.
>> >
>> >
>> > On 18/08/2014 10:23, "Felix Meschberger"  wrote:
>> >
>> >> Hi all
>> >>
>> >> I had various discussions around execution of Servlet API Filters in the
>> >> Sling Engine.
>> >>
>> >> To recap: Currently all filters are always called. The service.ranking
>> >> (or filter.order) service registration property can be used to define
>> the
>> >> order in which the filters are called and the filter.scope property is
>> >> required to indicate at what stage in the request processing a filter
>> has
>> >> to be called. See [1] for the full story.
>> >>
>> >> Turns out, that it would be good to have some simple and global flags to
>> >> indicate when a filter should actually be called or not. This would be
>> >> similar to the filter mappings of traditional web applications, where
>> >> filters are bound to URL paths and/or servlets.
>> >>
>> >> So I am proposing to introduce three new service registration
>> properties,
>> >> which may be set on Servlet Filter services handled by the Sling Engine:
>> >>
>> >> * filter.path: The Filter is only called if the path of the
>> >>  current Resource (SlingHttpServletRequest.getResource)
>> >>  matches any of the given paths. If the property is
>> >>  not set, the filter will always be called.
>> >> * filter.resourceType: The Filter is only called if the resourceType
>> >>  of the current Resource (SlingHttpServletRequest.getResource)
>> >>  matches any of the given resource types. If the property is
>> >>  not set, the filter will always be called.
>> >> * filter.ignore: The Filter is never called if this property
>> >>  is set to any "true".
>> >>
>> >>
>> >> The implementation would be as follows:
>> >>
>> >> * The FilterListEntry class is augmented with a method to verify whether
>> >> to call the filter at all
>> >> * The AbstractSlingFilterChain.doFilter method is augmented to call this
>> >> new method and to not call a filter for which the match fails. A
>> >> RequestProgressTracker entry is generated for filters not called
>> >> indicating why it has not been called.
>> >>
>> >> Further extensions could be:
>> >>
>> >> * filter.expression: some scripting expression evaluating to
>> >>   a boolean. If true the filter is called.
>> >> * Filter service implements a new interface providing an filter
>> >>   expression method returning a boolean. If true the filter
>> >>   is called (comparable to the option servlet).
>> >>
>> >> Regards
>> >> Felix
>> >>
>> >> [1] http://sling.apache.org/documentation/the-sling-engine/filters.html
>> >
>>
>>

[jira] [Commented] (SLING-3850) Add comments to the OSGi configuration files stored in the repository generated by configuration writeback

[Justin Edelson (JIRA)]

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

Justin Edelson commented on SLING-3850:
---

Made a few corrections above... TBC, the file isn't a properties file; the 
values are actually quoted, which actually makes the issue [~asanso] raises all 
the more important.

> Add comments to the OSGi configuration files stored in the repository 
> generated by configuration writeback
> --
>
> Key: SLING-3850
> URL: https://issues.apache.org/jira/browse/SLING-3850
> Project: Sling
>  Issue Type: Improvement
>  Components: Installer
>Reporter: Antonio Sanso
>Assignee: Carsten Ziegeler
>Priority: Minor
> Fix For: JCR Installer 3.1.8
>
>
> It would be nice add coment to the OSGi configuration files stored in the 
> repository.
> e.g. 
> {code}
> #generated by .. 
> {code}
> This will have as a wanted side effect to not have the file being a valid 
> javascript



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Comment Edited] (SLING-3850) Add comments to the OSGi configuration files stored in the repository generated by configuration writeback

[Justin Edelson (JIRA)]

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

Justin Edelson edited comment on SLING-3850 at 8/15/14 7:57 PM:


bq. and because it is not JS but just name value properties more like a 
properties file. 

[~fmeschbe]
that syntactically is a valid JS :P
So it seems there is some interested to know the full story so here it  is :)

Imagine this osgi property file is stored under 
/apps/system/config/org.apache.sling.Configuration.config

and looks like

{code}
username="admin"
password="admin"
{code}

Now I can put on my blog a page that looks like

{code}
http://localhost:8080</a> 
/apps/system/config/org.apache.sling.Configuration.config">
alert(username+'\n'+password)
{code}

Now guess which one is going to be the output if a Sling admin visit my blog :) 
...


was (Author: asanso):
bq. and because it is not JS but just name value properties more like a 
properties file. 

[~fmeschbe]
that syntactically is a valid JS :P
So it seems there is some interested to know the full story so here it  is :)

Imagine this osgi property file is stored under 
/apps/system/config/org.apache.sling.Configuration.config

and looks like

{code}
username = admin
password = admin
{code}

Now I can put on my blog a page that looks like

{code}
http://localhost:8080</a> 
/apps/system/config/org.apache.sling.Configuration.config">
alert(username+'\n'+password)
{code}

Now guess which one is going to be the output if a Sling admin visit my blog :) 
...

> Add comments to the OSGi configuration files stored in the repository 
> generated by configuration writeback
> --
>
> Key: SLING-3850
> URL: https://issues.apache.org/jira/browse/SLING-3850
> Project: Sling
>  Issue Type: Improvement
>  Components: Installer
>Reporter: Antonio Sanso
>Assignee: Carsten Ziegeler
>Priority: Minor
> Fix For: JCR Installer 3.1.8
>
>
> It would be nice add coment to the OSGi configuration files stored in the 
> repository.
> e.g. 
> {code}
> #generated by .. 
> {code}
> This will have as a wanted side effect to not have the file being a valid 
> javascript



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (SLING-3850) Add comments to the OSGi configuration files stored in the repository generated by configuration writeback

[Justin Edelson (JIRA)]

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

Justin Edelson updated SLING-3850:
--

Summary: Add comments to the OSGi configuration files stored in the 
repository generated by configuration writeback  (was: Add comments to the OSGi 
configuration files stored in the repository)

> Add comments to the OSGi configuration files stored in the repository 
> generated by configuration writeback
> --
>
> Key: SLING-3850
> URL: https://issues.apache.org/jira/browse/SLING-3850
> Project: Sling
>  Issue Type: Improvement
>  Components: Installer
>Reporter: Antonio Sanso
>Assignee: Carsten Ziegeler
>Priority: Minor
> Fix For: JCR Installer 3.1.8
>
>
> It would be nice add coment to the OSGi configuration files stored in the 
> repository.
> e.g. 
> {code}
> #generated by .. 
> {code}
> This will have as a wanted side effect to not have the file being a valid 
> javascript



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Re: Sling Models: Clarification around Type Conversions

[Justin Edelson]

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  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. 
> List 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

[jira] [Commented] (SLING-3709) Sling Models: Allow caller to deal with exceptions

[Justin Edelson (JIRA)]

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

Justin Edelson commented on SLING-3709:
---

[~kwin] I'm not sure I understand what you are proposing - how would an 
AdapterFactory (ModelAdapterFactory in this case) know that it was being 
invoked from Sightly vs. Java vs. a JSP? By inspecting the call stack?

I would be more inclined to introduce a direct method of accessing the 
ModelAdapterFactory, i.e. a new service interface. This would, to your point, 
require that the ModelAdapterFactory vary behavior for composed models based on 
whether or not the child model is adapter by ModelAdapterFactory vs. some other 
AdapterFactory, but this doesn't strike me as too challenging to implement. Or 
perhaps this can be skipped and only throw an exception for a single model 
class (and not children).

> Sling Models: Allow caller to deal with exceptions
> --
>
> Key: SLING-3709
> URL: https://issues.apache.org/jira/browse/SLING-3709
> Project: Sling
>  Issue Type: Improvement
>Affects Versions: Sling Models Implementation 1.0.4, Sling Models 
> Implementation 1.0.6
>Reporter: Konrad Windszus
>
> Currently due to the specification of the adaptTo-method to return null if 
> adaptation is not possible, the caller is not notified about any exceptions 
> (because they are caught within the ModelAdapterFactory).
> This is e.g. necessary to deal with validation exceptions properly (i.e. 
> required field injection not possible).  The problem was also discussed 
> briefly in 
> http://apache-sling.73963.n3.nabble.com/Silng-Models-Validation-Framework-td4033411.html.
> All exceptions either being thrown by the 
> @PostConstruct method or caused by the field/method injection are not 
> propagated but basically swallowed by Sling Models.
> It would be great to be able to catch those exceptions either in the view or 
> in a servlet filter. I think it should be possible to throw unchecked 
> exceptions in the ModelAdapterFactory.getFactory() method if it is requested 
> (i.e. through a global OSGi configuration flag for Sling Models).
> WDYT?
> Would you accept such a patch or do you think this breaks the API (also 
> compare with 
> https://issues.apache.org/jira/browse/SLING-2712?focusedCommentId=13561516&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13561516).
> If it does not work through the adaptTo, SlingModels should provide an 
> alternative way of instanciating models (and propagating exceptions), 
> although this is kind of tricky, because it internally relies on adaptTo as 
> well (e.g. in 
> https://github.com/apache/sling/blob/trunk/bundles/extensions/models/impl/src/main/java/org/apache/sling/models/impl/ModelAdapterFactory.java#L647)



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Re: adaptTo and results ....

[Justin Edelson]

You're missing my point. How would your Sightly script indicate that a
RuntimeException should be thrown in the first place? Or are you
suggesting that Sightly assume that this is always the case?

On Mon, Jul 28, 2014 at 12:07 PM, Konrad Windszus  wrote:
> 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  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  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  wrote:
>>>
>>>> 2014-07-07 18:29 GMT+02:00 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.
>>>>>
>>>>
>>>> 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  wrote:
>>>>>
>>>>>> 2014-07-07 18:14 GMT+02:00 Justin Edelson :
>>>>>>
>>>>>>> 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 ....

[Justin Edelson]

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  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  wrote:
>
>> 2014-07-07 18:29 GMT+02:00 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.
>>>
>>
>> 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  wrote:
>>>
>>>> 2014-07-07 18:14 GMT+02:00 Justin Edelson :
>>>>
>>>>> 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: Removing OCM Support from Launchapd

[Justin Edelson]

Hi,

On Mon, Jul 28, 2014 at 5:36 AM, Carsten Ziegeler  wrote:
> Hi,
>
>
> the OCM stuff isn't really used and we never recommend to use it - however,
> it's still in our launchpad.
> No one has worked on OCM since we left the incubator and looking at the
> currently included version and the package imports I doubt that it actually
> really works.
>
> While fixing an obvious bug in the code base, I've updated to the latest
> SNAPSHOT and this doesn't resolve anymore (SLING-3806) which leaves us with
> three options
>
> a) continue with the 2.0.4-incubator release in our launchpad
> b) fix the problem in the OCM code (this seems to require updates to newer
> jackrabbit versions)
> c) remove it from the launchpad and move it to the contrib secion until
> someone who really needs it comes along and fixes it

+1

>
> Given all of the above, I'm really in favour of c)
>
>
> WDYT?
>
> Carsten
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org

[jira] [Resolved] (SLING-3703) Dependency on org.apache.sling.commons.osgi in version 2.2

[Justin Edelson (JIRA)]

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

Justin Edelson resolved SLING-3703.
---

Resolution: Fixed
  Assignee: Justin Edelson

fixed in r1613413

> Dependency on org.apache.sling.commons.osgi in version 2.2
> --
>
> Key: SLING-3703
> URL: https://issues.apache.org/jira/browse/SLING-3703
> Project: Sling
>  Issue Type: Improvement
>Affects Versions: Sling Models Implementation 1.0.4, Sling Models 
> Implementation 1.0.6
>Reporter: Konrad Windszus
>    Assignee: Justin Edelson
>Priority: Minor
> Fix For: Sling Models Implementation 1.0.8
>
>
> Currently it is not possible to start the bundle org.apache.sling.models.impl 
> in version 5.5 of Adobe CQ 5.5 due to the dependency on 
> org.apache.sling.commons.osgi in version 2.2. Can you lower the dependency to 
> version 2.1? To me it doesn't look that you actually rely on functionality 
> being introduced with version 2.2 
> (https://issues.apache.org/jira/browse/SLING/fixforversion/12317581).



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (SLING-3703) Dependency on org.apache.sling.commons.osgi in version 2.2

[Justin Edelson (JIRA)]

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

Justin Edelson updated SLING-3703:
--

Fix Version/s: Sling Models Implementation 1.0.8

> Dependency on org.apache.sling.commons.osgi in version 2.2
> --
>
> Key: SLING-3703
> URL: https://issues.apache.org/jira/browse/SLING-3703
> Project: Sling
>  Issue Type: Improvement
>Affects Versions: Sling Models Implementation 1.0.4, Sling Models 
> Implementation 1.0.6
>Reporter: Konrad Windszus
>Priority: Minor
> Fix For: Sling Models Implementation 1.0.8
>
>
> Currently it is not possible to start the bundle org.apache.sling.models.impl 
> in version 5.5 of Adobe CQ 5.5 due to the dependency on 
> org.apache.sling.commons.osgi in version 2.2. Can you lower the dependency to 
> version 2.1? To me it doesn't look that you actually rely on functionality 
> being introduced with version 2.2 
> (https://issues.apache.org/jira/browse/SLING/fixforversion/12317581).



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (SLING-3772) Query to load initial vanity path set includes unnecessary ORDER BY clause

[Justin Edelson (JIRA)]

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

Justin Edelson resolved SLING-3772.
---

Resolution: Fixed

fixed in r1611664

> Query to load initial vanity path set includes unnecessary ORDER BY clause
> --
>
> Key: SLING-3772
> URL: https://issues.apache.org/jira/browse/SLING-3772
> Project: Sling
>  Issue Type: Improvement
>  Components: ResourceResolver
>        Reporter: Justin Edelson
>    Assignee: Justin Edelson
> Fix For: Resource Resolver 1.1.2
>
>
> With the recent changes to MapEntries, MapEntries will automatically sort 
> vanity paths internally. As such it is no longer necessary to execute an 
> ordered query.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Assigned] (SLING-3772) Query to load initial vanity path set includes unnecessary ORDER BY clause

[Justin Edelson (JIRA)]

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

Justin Edelson reassigned SLING-3772:
-

Assignee: Justin Edelson

> Query to load initial vanity path set includes unnecessary ORDER BY clause
> --
>
> Key: SLING-3772
> URL: https://issues.apache.org/jira/browse/SLING-3772
> Project: Sling
>  Issue Type: Improvement
>  Components: ResourceResolver
>        Reporter: Justin Edelson
>    Assignee: Justin Edelson
> Fix For: Resource Resolver 1.1.2
>
>
> With the recent changes to MapEntries, MapEntries will automatically sort 
> vanity paths internally. As such it is no longer necessary to execute an 
> ordered query.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (SLING-3772) Query to load initial vanity path set includes unnecessary ORDER BY clause

[Justin Edelson (JIRA)]

Justin Edelson created SLING-3772:
-

 Summary: Query to load initial vanity path set includes 
unnecessary ORDER BY clause
 Key: SLING-3772
 URL: https://issues.apache.org/jira/browse/SLING-3772
 Project: Sling
  Issue Type: Improvement
  Components: ResourceResolver
Reporter: Justin Edelson
 Fix For: Resource Resolver 1.1.2


With the recent changes to MapEntries, MapEntries will automatically sort 
vanity paths internally. As such it is no longer necessary to execute an 
ordered query.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Re: [VOTE] accept the SLING-3667 Sling Query contribution

[Justin Edelson]

+1

On Thu, Jul 17, 2014 at 8:32 AM, Bertrand Delacretaz
 wrote:
> Hi,
>
> See SLING-3667 for details - please vote to accept this contribution
>
> SHA1(sling-query.zip)= 4a0488f00ac81f6ce29eb87e15255418b39bd5a4
>
> This majority vote is open for at least 72 hours. I'm taking care of
> the IP clearance process in parallel.
>
> -Bertrand

[jira] [Commented] (SLING-3759) Support viewing/tailing logs for a defined Sling server

[Justin Edelson (JIRA)]

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

Justin Edelson commented on SLING-3759:
---

Actually, it looks like Beagle doesn't work on Kepler or Luna (see 
jira.qos.ch/browse/CONSPLUG-44), but perhaps one of our Eclipse plugin experts 
can fix that issue :)

> Support viewing/tailing logs for a defined Sling server
> ---
>
> Key: SLING-3759
> URL: https://issues.apache.org/jira/browse/SLING-3759
> Project: Sling
>  Issue Type: New Feature
>  Components: IDE
>Affects Versions: Sling Eclipse IDE 1.0.0
>Reporter: Robert Munteanu
> Fix For: Sling Eclipse IDE 1.1.0
>
>
> It would be very useful to be able to directly inspect / tail the logs of the 
> Sling runtime instance from a dedicated Eclipse view.
> We should be able to infer the location if we know that the instance is 
> local, but that probably requires a bit of infrastructure work to be able to 
> distinguish local/remote instances.
> For an example involving AEM and a dedicated plugin, see 
> http://labs.sixdimensions.com/blog/2014-07-07/tailing-aem-logs-in-eclipse/



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (SLING-3759) Support viewing/tailing logs for a defined Sling server

[Justin Edelson (JIRA)]

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

Justin Edelson commented on SLING-3759:
---

Since we have support for Logback, why not just use Logback-beagle 
(http://logback.qos.ch/beagle/)?

> Support viewing/tailing logs for a defined Sling server
> ---
>
> Key: SLING-3759
> URL: https://issues.apache.org/jira/browse/SLING-3759
> Project: Sling
>  Issue Type: New Feature
>  Components: IDE
>Affects Versions: Sling Eclipse IDE 1.0.0
>Reporter: Robert Munteanu
> Fix For: Sling Eclipse IDE 1.1.0
>
>
> It would be very useful to be able to directly inspect / tail the logs of the 
> Sling runtime instance from a dedicated Eclipse view.
> We should be able to infer the location if we know that the instance is 
> local, but that probably requires a bit of infrastructure work to be able to 
> distinguish local/remote instances.
> For an example involving AEM and a dedicated plugin, see 
> http://labs.sixdimensions.com/blog/2014-07-07/tailing-aem-logs-in-eclipse/



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Closed] (SLING-3677) Array to list conversion in ValueMap

[Justin Edelson (JIRA)]

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

Justin Edelson closed SLING-3677.
-


> Array to list conversion in ValueMap
> 
>
> Key: SLING-3677
> URL: https://issues.apache.org/jira/browse/SLING-3677
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: Sling Models Implementation 1.0.4
>Reporter: Krystian Panek
>    Assignee: Justin Edelson
>Priority: Minor
>  Labels: models
> Fix For: Sling Models Implementation 1.0.6
>
> Attachments: valuemap-injector-list-support.diff
>
>
> I suppose that many people prefer lists more than arrays.
> Automatic conversion in value map would be useful.
> See attachment (svn diff this time as Justin asked).
> Only default value support is missing...



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Closed] (SLING-3499) Support custom annotations with Sling Models

[Justin Edelson (JIRA)]

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

Justin Edelson closed SLING-3499.
-


> Support custom annotations with Sling Models
> 
>
> Key: SLING-3499
> URL: https://issues.apache.org/jira/browse/SLING-3499
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>Affects Versions: Sling Models API 1.0.0, Sling Models Implementation 1.0.2
>Reporter: Konrad Windszus
>    Assignee: Justin Edelson
> Fix For: Sling Models Implementation 1.0.6, Sling Models API 1.0.2
>
> Attachments: SLING-3499-Documentation-v1.patch, 
> SLING-3499-Documentation-v2.patch
>
>
> To support custom annotations the API needs to be extended. 
> The reasons for custom annotations are listed in 
> http://www.mail-archive.com/dev%40sling.apache.org/msg27918.html. Also it is 
> much more comfortable for developers, since they can use code completion in 
> the IDE to see which options are available for each injector-specific 
> annotation, apart from that it is less code to write (instead of multiple 
> annotations on one field/method I would only have to write one annotation 
> with some attributes).



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Closed] (SLING-3547) Default handling for numerical types on Sling Models broken

[Justin Edelson (JIRA)]

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

Justin Edelson closed SLING-3547.
-


> Default handling for numerical types on Sling Models broken
> ---
>
> Key: SLING-3547
> URL: https://issues.apache.org/jira/browse/SLING-3547
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: Sling Models Implementation 1.0.2, Sling Models 
> Implementation 1.0.4
>Reporter: Konrad Windszus
>Assignee: Justin Edelson
> Fix For: Sling Models Implementation 1.0.6
>
>
> Currently all default annotations on numeric types lead to the following 
> warning: 
> org.apache.sling.models.impl.ModelAdapterFactory Default values for class 
> java.lang.Boolean are not supported and the default is not used.
> This is due to the fact that first all types are converted from Primitives to 
> Object Wrapper Classes (in mapPrimitiveClasses). Then the comparison against 
> that type only considers Primitives (in getDefaultValue, except for Strings), 
> which obviously failed, because either those were Object Wrapper Classes 
> right from the beginning, or they were converted to those. 
> In my regard you should compare the Type against e.g. Integer.class instead 
> of Integer.TYPE (ModelAdapterFactory, line 428ff). Otherwise defaults for 
> numerical types will not work.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Closed] (SLING-3516) Sling Models Resource Child List Injector

[Justin Edelson (JIRA)]

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

Justin Edelson closed SLING-3516.
-


> Sling Models Resource Child List Injector
> -
>
> Key: SLING-3516
> URL: https://issues.apache.org/jira/browse/SLING-3516
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>Affects Versions: Sling Models Implementation 1.0.2
>Reporter: Igor Sechyn
>    Assignee: Justin Edelson
>Priority: Minor
> Fix For: Sling Models Implementation 1.0.6
>
> Attachments: ChildResourceInjectorPatch.diff
>
>
> Hi All,
> We have decided to use the sling models to process some hierarchical data in 
> our project and are facing the following issue right now.
> Our content structure looks as follows:
> {code}
> +- dealer
>   |
>   +- addresses
>  |
>  + -address1
>  |
>  +- address2
> {code}
> Dealer and address nodes have attributes, that can be injected through the 
> ValueMapInjector, so everything works fine here. Our goal however is also to 
> inject the List of AddressModel objects into the DealerModel object, 
> something like this:
> {code}
> @Inject
> List addresses
> {code}
> The desired behavior would be:
> - the injector resolves addresses as a child resource of the adaptable object
> - iterates over the children of this resource (in this case „addresses")
> - adapts each child to the actual type argument of the parameterized list type
> - returns the list of adapted model objects
> I have tried to play around with @Named but could not get it to work. The 
> only way of making it work, was to write a custom injector, which worked out 
> pretty fine. 
> But I was still wondering, if there might be an OOTB functionality, which can 
> be used for this use case
> Cheers, Igor.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Closed] (SLING-3696) Allow a model class to be annotated so that by default injections are optional

[Justin Edelson (JIRA)]

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

Justin Edelson closed SLING-3696.
-


> Allow a model class to be annotated so that by default injections are optional
> --
>
> Key: SLING-3696
> URL: https://issues.apache.org/jira/browse/SLING-3696
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>        Reporter: Justin Edelson
>    Assignee: Justin Edelson
>  Labels: models
> Fix For: Sling Models Implementation 1.0.6, Sling Models API 1.0.2
>
>
> By default, injections are required and individual injections can be declared 
> as optional. It should be possible to flip this - the default being optional 
> and individual injections can be required.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Closed] (SLING-3683) Sling Models: ModelAdapterFactory mixes up annotationProcessor in injectFieldOrMethod method

[Justin Edelson (JIRA)]

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

Justin Edelson closed SLING-3683.
-


> Sling Models: ModelAdapterFactory mixes up annotationProcessor in 
> injectFieldOrMethod method
> 
>
> Key: SLING-3683
> URL: https://issues.apache.org/jira/browse/SLING-3683
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Reporter: Stefan Seifert
>    Assignee: Justin Edelson
>Priority: Minor
> Fix For: Sling Models Implementation 1.0.6
>
> Attachments: 140620_SLING-3683_annotationProcessor.patch
>
>
> the method AdapterFactory.injectFieldOrMethod gets an annotationProcessor 
> from the injectors if they implement the InjectAnnotationProcessorFactory.
> currently, if a injector does not implement this interface, the instance  
> assigned to the annotationProcessor may be re-used from the previous injector 
> which is not intended.
> patch attached.
> not tested, is there already a unit test where a test for this can should be 
> added?



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Closed] (SLING-3674) Array of wrappers to primitives conversion in Sling Models

[Justin Edelson (JIRA)]

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

Justin Edelson closed SLING-3674.
-


> Array of wrappers to primitives conversion in Sling Models
> --
>
> Key: SLING-3674
> URL: https://issues.apache.org/jira/browse/SLING-3674
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: Sling Models Implementation 1.0.4
>Reporter: Krystian Panek
>    Assignee: Justin Edelson
>  Labels: models
> Fix For: Sling Models Implementation 1.0.6
>
> Attachments: ArrayPrimitivesModel.java, ResourceModelClassesTest.java
>
>
> Problem is related with: https://issues.apache.org/jira/browse/SLING-3547
> Suppose that I have:
> {quote}
> @Inject
> private int[] scores;
> @Inject
> private Integer[] scores;
> {quote}
> For first declaration injection does not work, because in my environment 
> ValueMap contains array of wrapped integers and type cast to array of 
> primitives cannot be done. I noticed an exception:
> {quote}
> 27 [main] ERROR org.apache.sling.models.impl.ModelAdapterFactory - unable to 
> create object
> java.lang.ClassCastException: [I cannot be cast to [Ljava.lang.Object;
>   at 
> org.apache.sling.api.wrappers.ValueMapDecorator.convertToArray(ValueMapDecorator.java:100)
> {quote}
> Second declaration seems to work but how to apply default value for it? 
> According to Sling Models documentation, example with default value for array 
> of integers currently it is not possible to get it working. Same error as for 
> first declaration.
> I wrote unit test for it. I hope, useful for reproducing problem, see 
> attachments.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Closed] (SLING-3679) Required fields validation

[Justin Edelson (JIRA)]

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

Justin Edelson closed SLING-3679.
-


> Required fields validation
> --
>
> Key: SLING-3679
> URL: https://issues.apache.org/jira/browse/SLING-3679
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: Sling Models Implementation 1.0.4
>Reporter: Krystian Panek
>  Labels: models
> Fix For: Sling Models Implementation 1.0.6
>
>
> Currently if some field cannot be injected (and it is not annotated with 
> @Optional), model adapter factory returns null. However fact that some field 
> has null and all other are properly injected is acceptable in my context.
> Proposal:
> * model adapter factory does not return null if not all required fields are 
> injected,
> * result of requirement validation is serviced as for example:
> ** injecting it to some extra annotated field: @Valid boolean valid; (with 
> default false),
> ** passing bool parameter in @PostConstruct callback, for example 'valid' 
> (true if all required field are injected, false otherwise),
> * behave current behavior, new available only with extra model class 
> annotation, for example @NotNull .



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Closed] (SLING-3700) Add a simple injector to get the resource resolver

[Justin Edelson (JIRA)]

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

Justin Edelson closed SLING-3700.
-


> Add a simple injector to get the resource resolver
> --
>
> Key: SLING-3700
> URL: https://issues.apache.org/jira/browse/SLING-3700
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>        Reporter: Justin Edelson
>    Assignee: Justin Edelson
> Fix For: Sling Models Implementation 1.0.6
>
>
> Currently, injecting a ResourceResolver into a model class which is adapted 
> from a resource is not possible - you have to use constructor injection of 
> the Resource and then get the Resource Resolver from the Resource. This is 
> non-intuitive and should be fixed.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (SLING-3499) Support custom annotations with Sling Models

[Justin Edelson (JIRA)]

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

Justin Edelson commented on SLING-3499:
---

[~kwin] Sorry for the delay; I have pushed the documentation changes. I did 
remove the bit about performance improvements as, AFAIK, we don't have any 
tests to show what the performance difference is. That would be interesting to 
add at a later point.

> Support custom annotations with Sling Models
> 
>
> Key: SLING-3499
> URL: https://issues.apache.org/jira/browse/SLING-3499
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>Affects Versions: Sling Models API 1.0.0, Sling Models Implementation 1.0.2
>Reporter: Konrad Windszus
>Assignee: Justin Edelson
> Fix For: Sling Models Implementation 1.0.6, Sling Models API 1.0.2
>
> Attachments: SLING-3499-Documentation-v1.patch, 
> SLING-3499-Documentation-v2.patch
>
>
> To support custom annotations the API needs to be extended. 
> The reasons for custom annotations are listed in 
> http://www.mail-archive.com/dev%40sling.apache.org/msg27918.html. Also it is 
> much more comfortable for developers, since they can use code completion in 
> the IDE to see which options are available for each injector-specific 
> annotation, apart from that it is less code to write (instead of multiple 
> annotations on one field/method I would only have to write one annotation 
> with some attributes).



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Re: [VOTE] Release Apache Sling Settings 1.3.2

[Justin Edelson]

+1

On Tue, Jul 8, 2014 at 5:20 PM, Carsten Ziegeler  wrote:
> Hi,
>
> We solved 1 issue in this release:
> https://issues.apache.org/jira/browse/SLING-3737
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-1080
>
> You can use this UNIX script to download the release and verify the
> signatures:
> http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh
>
> Usage:
> sh check_staged_release.sh 1080 /tmp/sling-staging
>
> Please vote to approve this release:
>
>   [ ] +1 Approve the release
>   [ ]  0 Don't care
>   [ ] -1 Don't release, because ...
>
> This majority vote is open for at least 72 hours.
>
> Regards,
> Carsten
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org

Re: adaptTo and results ....

[Justin Edelson]

Hi,

On Mon, Jul 7, 2014 at 5:57 PM, Alexander Klimetschek
 wrote:
> On 07.07.2014, at 17:08, Carsten Ziegeler  wrote:
>
>> 2014-07-07 14:55 GMT+02:00 Justin Edelson :
>>
>>> Here's a sightly more real world case... let's say you have a call like
>>> this:
>>>
>>> Comment comment = resource.adaptTo(Comment.class);
>>>
>>> And for a Resource to be successfully adapted to a Comment, it must
>>> satisfy two criteria:
>>> 1) The resource type must be myco/comment
>>> 2) It must have a property called "commentType" (OK, this part isn't
>>> so real world).
>>>
>>> Right now, the caller has no way of knowing which of these critera
>>> wasn't met. That's IMHO the crux of this request - to provide a way
>>> for AdapterFactories to surface the failure reason back to the caller.
>>>
>>>
>> Hmm, this assumes the caller can do something meaningful with it. Given
>> your example, what could the client do?

Konrad could probably articulate this better than I can :)

>
> Right.
>
> In this case I would assume that if 1) is present, you get a Comment back, 
> otherwise null. Then Comment has a getter method for the type 2), which would 
> also handle the case of a missing type: usually you would fall back to a 
> default if no type is specified, since that reduces the constraints the 
> content has to follow; but you could also have the application handle the 
> no-type case itself and fail in some way (as you were trying to with an 
> exception that is passed through from adapterfactory to application code).
>
> Next example please :D

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?

Regards,
Justin

>
> Cheers,
> Alex
>

Re: adaptTo and results ....

[Justin Edelson]

Hi,

On Thu, Jul 3, 2014 at 3:07 PM, Alexander Klimetschek
 wrote:
> On 03.07.2014, at 13:58, Justin Edelson  wrote:
>
>> It won't work :) This is a hugely non-backwards compatible change. It
>> happens to be binary compatible, but it is not semantically compatible
>> (which is in some ways just as important). Callers of adaptTo() assume
>> (because we have told them to assume) that null will be returned if
>> the adaptation can't be done. We can't now start throwing exceptions.
>> Callers won't expect this.
>
> There is a conflict with the other stated problem: that most callers don't 
> expect null either :) So if we change something, this will have an effect on 
> at least some callers either way, unless we add a new method with a different 
> semantic.
>
> But I'd say this is just adding complexity for no notable benefit. And just 
> improving the logging in case of exceptions in AdpaterFactories and 
> Adaptables or that static adaptOrThrow helper should be enough.
>
> Maybe some actual real world cases would help (i.e. no "Foo.class" 
> adaptations :). The only one I see is the Sling Models validation case as 
> originally outlined here [1] - but could you elaborate? I probably miss the 
> knowledge about sling models to see the issue.

Here's a sightly more real world case... let's say you have a call like this:

Comment comment = resource.adaptTo(Comment.class);

And for a Resource to be successfully adapted to a Comment, it must
satisfy two criteria:
1) The resource type must be myco/comment
2) It must have a property called "commentType" (OK, this part isn't
so real world).

Right now, the caller has no way of knowing which of these critera
wasn't met. That's IMHO the crux of this request - to provide a way
for AdapterFactories to surface the failure reason back to the caller.

Regards,
Justin


>
> [1] http://markmail.org/message/lcujo4flwek3liez
>
> Cheers,
> Alex

[jira] [Commented] (SLING-3709) Sling Models: Allow caller to deal with exceptions

[Justin Edelson (JIRA)]

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

Justin Edelson commented on SLING-3709:
---

No. Such a change violates the contract of AdapterFactory and goes against Java 
best practices.

The current behavior must stay as is unless we have a way for the caller to 
explicitly indicate that she wants something else to happen. A configuration 
switch is not appropriate as that leaves the decision in the hands of the 
administrator, not the caller.

> Sling Models: Allow caller to deal with exceptions
> --
>
> Key: SLING-3709
> URL: https://issues.apache.org/jira/browse/SLING-3709
> Project: Sling
>  Issue Type: Improvement
>Affects Versions: Sling Models Implementation 1.0.4, Sling Models 
> Implementation 1.0.6
>Reporter: Konrad Windszus
>
> Currently due to the specification of the adaptTo-method to return null if 
> adaptation is not possible, the caller is not notified about any exceptions 
> (because they are caught within the ModelAdapterFactory).
> This is e.g. necessary to deal with validation exceptions properly (i.e. 
> required field injection not possible).  The problem was also discussed 
> briefly in 
> http://apache-sling.73963.n3.nabble.com/Silng-Models-Validation-Framework-td4033411.html.
> All exceptions either being thrown by the 
> @PostConstruct method or caused by the field/method injection are not 
> propagated but basically swallowed by Sling Models.
> It would be great to be able to catch those exceptions either in the view or 
> in a servlet filter. I think it should be possible to throw unchecked 
> exceptions in the ModelAdapterFactory.getFactory() method if it is requested 
> (i.e. through a global OSGi configuration flag for Sling Models).
> WDYT?
> Would you accept such a patch or do you think this breaks the API (also 
> compare with 
> https://issues.apache.org/jira/browse/SLING-2712?focusedCommentId=13561516&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13561516).
> If it does not work through the adaptTo, SlingModels should provide an 
> alternative way of instanciating models (and propagating exceptions), 
> although this is kind of tricky, because it internally relies on adaptTo as 
> well (e.g. in 
> https://github.com/apache/sling/blob/trunk/bundles/extensions/models/impl/src/main/java/org/apache/sling/models/impl/ModelAdapterFactory.java#L647)



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Re: adaptTo and results ....

[Justin Edelson]

Hi,

On Thu, Jul 3, 2014 at 4:50 AM, Alexander Klimetschek
 wrote:
> On 03.07.2014, at 09:12, Konrad Windszus  wrote:
>
>> - The client can decide how to expose that error (whether just logging is 
>> fine or something more obvious). This cannot be achieved by just setting up 
>> a utility method, because that one does only see the null return value and 
>> not the original reason for that.
>
> Yes, but my question is whether there is any need to pass through the 
> exception at all.
>
>> - Tracing problems during development is much easier (instead of looking at 
>> the log I can see the full exception)
>
> You can debug exceptions inside the adapterfactories as well (after seeing 
> them in the log).
>
>> - It allows to use it for something like validation in Sling Models
>
> How would that work? (I saw the reference earlier in the thread, but I don't 
> know how you'd use adaptTo for validation and can't really imagine it's a 
> good fit)

Validation means a lot of things; I would say that your example below
where a resource has to be a certain type to be adapted to a resource
collection is a form of validation. As you note, using exceptions for
validation use cases is wrong.

>
>> - It is less error-prone to the developers (you can easily forget to either 
>> use the utility method or check for null)
>
> The null-returning method is out there, it cannot be changed to throw a 
> checked exception (which is the only way to force handling for devs)
>
>> - In my regard in most of the cases if adaptation fails, there is something 
>> wrong with the deployment (required bundles are not installed, components 
>> are not running, ….) and I cannot reasonably work around that issue in the 
>> code -> that calls for an exception
>
> It's not only exception, it's also a way to check if something is of a 
> certain type (say adapting a resource to a resourcecollection). In this case 
> an exception is not the right thing.
>
> 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
>
> But not sure if that will work.

It won't work :) This is a hugely non-backwards compatible change. It
happens to be binary compatible, but it is not semantically compatible
(which is in some ways just as important). Callers of adaptTo() assume
(because we have told them to assume) that null will be returned if
the adaptation can't be done. We can't now start throwing exceptions.
Callers won't expect this.

The caller *must* indicate in some way that she wants behavior which
is different than the current. AFAICT, there are only two viable
solutions:

* My original suggestion of using a Result interface. This requires
more verbose code on the caller side -- the caller needs to check a
success flag -- but allows for fine-grained information (which would
be appropriate for a validation use case).
* Bertrand's suggestion of using some kind of ThreadLocal. Less
verbose code on the caller side. Would seem to violate Effective Java
#57 in that it is using exceptions for control flow.

Both cases can be implemented without impacting existing callers or
adapter factories. Adapter factories would need indicate that they
support the Result interface or exception throwing via a service
property. For factories without the property, the AdapterManagerImpl
would simulate the proper behavior.

Justin

>
> Cheers,
> Alex

[VOTE] [RESULT] Release Apache Sling Models API 1.0.2 & Implementation 1.0.6

[Justin Edelson]

Hi,

The vote has passed with the following result :

+1 (binding): Justin Edelson, Robert Munteanu, Antonio Sanso
+1 (non binding): Stefan Seifert

I will copy this release to the Sling dist directory and
promote the artifacts to the central Maven repository.


On Wed, Jun 25, 2014 at 12:01 PM, Justin Edelson
 wrote:
> Hi,
>
> We solved 9 issues in these releases:
> https://issues.apache.org/jira/browse/SLING/fixforversion/12326850
> https://issues.apache.org/jira/browse/SLING/fixforversion/12327153
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-1070/
>
> You can use this UNIX script to download the release and verify the 
> signatures:
> http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh
>
> Usage:
> sh check_staged_release.sh 1070 /tmp/sling-staging
>
> Please vote to approve this release:
>
>   [ ] +1 Approve the release
>   [ ]  0 Don't care
>   [ ] -1 Don't release, because ...
>
> This majority vote is open for at least 72 hours.

Re: [VOTE] Release Apache Sling Scripting JSP 2.1.2 and Apache Sling Scripting Java 2.0.8

[Justin Edelson]

+1

On Wed, Jul 2, 2014 at 9:28 AM, Robert Munteanu  wrote:
> +1
>
> Robert
>
> On Wed, Jul 2, 2014 at 2:51 PM, Carsten Ziegeler 
> wrote:
>> Hi,
>>
>> We solved two issues for each scripting bundle, especially with SLING-3724
>> these bundles now provide a better experience with Java 8 as they run
>> without configuration changes on Java 8 as well as previous versions.
>>
>> Scripting JSP
>> https://issues.apache.org/jira/browse/SLING/fixforversion/12326855
>> Scripting Java
>> https://issues.apache.org/jira/browse/SLING/fixforversion/12321863
>>
>> Staging repository:
>> https://repository.apache.org/content/repositories/orgapachesling-1073
>>
>> You can use this UNIX script to download the release and verify the
>> signatures:
>> http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh
>>
>> Usage:
>> sh check_staged_release.sh 1073 /tmp/sling-staging
>>
>> Please vote to approve this release:
>>
>> [ ] +1 Approve the release
>> [ ] 0 Don't care
>> [ ] -1 Don't release, because ...
>>
>> This majority vote is open for at least 72 hours.
>>
>> Regards
>>
>> --
>> Carsten Ziegeler
>> Adobe Research Switzerland
>> cziege...@apache.org

Re: [VOTE] Release Apache Sling Installer Core 3.5.2 and Installer Configuration Factoy 1.0.14

[Justin Edelson]

+1

On Tue, Jul 1, 2014 at 12:05 PM, Carsten Ziegeler  wrote:
> It seems we're still missing a vote on this pretty old vote thread...
>
> Carsten
>
>
> 2014-06-04 9:30 GMT+02:00 Carsten Ziegeler :
>
>> +1
>>
>> Carsten
>>
>>
>> 2014-06-04 8:13 GMT+02:00 Ian Boston :
>>
>> +1
>>> Signatures checked.
>>> Ian
>>>
>>> On 4 June 2014 07:06, Carsten Ziegeler  wrote:
>>> > Hi,
>>> >
>>> > We solved 3 issues in Installer Core 3.5.2
>>> > https://issues.apache.org/jira/browse/SLING/fixforversion/12325943
>>> >
>>> > We solved 1 issue in Installer Configuration Factory 1.0.14
>>> > https://issues.apache.org/jira/browse/SLING/fixforversion/12326553
>>> >
>>> > Staging repository:
>>> > https://repository.apache.org/content/repositories/orgapachesling-1068
>>> >
>>> > You can use this UNIX script to download the release and verify the
>>> > signatures:
>>> > http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh
>>> >
>>> > Usage:
>>> > sh check_staged_release.sh 1068 /tmp/sling-staging
>>> >
>>> > Please vote to approve this release:
>>> >
>>> >   [ ] +1 Approve the release
>>> >   [ ]  0 Don't care
>>> >   [ ] -1 Don't release, because ...
>>> >
>>> > This majority vote is open for at least 72 hours.
>>> >
>>> > Regards
>>> > Carsten
>>> > --
>>> > Carsten Ziegeler
>>> > cziege...@apache.org
>>>
>>
>>
>>
>> --
>> Carsten Ziegeler
>> cziege...@apache.org
>>
>
>
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org

Re: [VOTE] Release Apache Sling Models API 1.0.2 & Implementation 1.0.6

[Justin Edelson]

Need one more binding vote

On Friday, June 27, 2014, Stefan Seifert  wrote:

> +1 (non-binding)
>
> p.s. integration tests are running fine on my machine
>
>
> >-Original Message-
> >From: justinedel...@gmail.com  [mailto:
> justinedel...@gmail.com ] On Behalf Of
> >Justin Edelson
> >Sent: Wednesday, June 25, 2014 6:02 PM
> >To: dev@sling.apache.org 
> >Subject: [VOTE] Release Apache Sling Models API 1.0.2 & Implementation
> 1.0.6
> >
> >Hi,
> >
> >We solved 9 issues in these releases:
> >https://issues.apache.org/jira/browse/SLING/fixforversion/12326850
> >https://issues.apache.org/jira/browse/SLING/fixforversion/12327153
> >
> >Staging repository:
> >https://repository.apache.org/content/repositories/orgapachesling-1070/
> >
> >You can use this UNIX script to download the release and verify the
> >signatures:
> >http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh
> >
> >Usage:
> >sh check_staged_release.sh 1070 /tmp/sling-staging
> >
> >Please vote to approve this release:
> >
> >  [ ] +1 Approve the release
> >  [ ]  0 Don't care
> >  [ ] -1 Don't release, because ...
> >
> >This majority vote is open for at least 72 hours.
>

[jira] [Commented] (SLING-3718) Sling Models: Add self Injector for supporting chains of object injecting dependencies from a common source

[Justin Edelson (JIRA)]

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

Justin Edelson commented on SLING-3718:
---

Also, it is poor separation of concerns to have the adapt to call in the 
injector. That is centralized already in the ModelAdapterFactory.

This might be a case for an annotation like @Self.

> Sling Models: Add self Injector for supporting chains of object injecting 
> dependencies from a common source
> ---
>
> Key: SLING-3718
> URL: https://issues.apache.org/jira/browse/SLING-3718
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Stefan Seifert
>Priority: Minor
>
> as discussed in my post on the sling mailing list
> http://mail-archives.apache.org/mod_mbox/sling-dev/201406.mbox/%3c580afa6c6dab8a4196956da5ee17c8ca8f7619e...@feanor.pro-vision.de%3E
> it would be very helpful to have a "self-adapting" injector to support chains 
> of objects (e.g. controller classes depending on business classes) that all 
> can adapt themselves from a common source, e.g. a SlingHttpServletRequest or 
> a ResourceResolver.
> souch an injector can be simple like this:
> {code:java}
> @Component
> @Service
> @Property(name = Constants.SERVICE_RANKING, intValue = 50)
> public class SelfAdaptInjector implements Injector {
>   public String getName() {
> return "selfadapt";
>   }
>   public Object getValue(Object pAdaptable, String pName, Type pType, 
> AnnotatedElement pElement,
> DisposalCallbackRegistry pCallbackRegistry) {
> if (!(pType instanceof Class)) {
>   return null;
> }
> if (!(pAdaptable instanceof Adaptable)) {
>   return null;
> }
> return ((Adaptable)pAdaptable).adaptTo((Class)pType);
>   }
> }
> {code}
> comment from Justin on this in the mailing list:
> {quote}
> The self injector is interesting. I held off on that initially because
> it seems too easy to create a circular injection. Any thoughts on how
> that can be avoided?
> \[...\]
> Regards,
> Justin
> {quote}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (SLING-3718) Sling Models: Add self Injector for supporting chains of object injecting dependencies from a common source

[Justin Edelson (JIRA)]

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

Justin Edelson commented on SLING-3718:
---

Yes, these are both examples of what am concerned about. Neither of these are 
illegal class design.

> Sling Models: Add self Injector for supporting chains of object injecting 
> dependencies from a common source
> ---
>
> Key: SLING-3718
> URL: https://issues.apache.org/jira/browse/SLING-3718
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Stefan Seifert
>Priority: Minor
>
> as discussed in my post on the sling mailing list
> http://mail-archives.apache.org/mod_mbox/sling-dev/201406.mbox/%3c580afa6c6dab8a4196956da5ee17c8ca8f7619e...@feanor.pro-vision.de%3E
> it would be very helpful to have a "self-adapting" injector to support chains 
> of objects (e.g. controller classes depending on business classes) that all 
> can adapt themselves from a common source, e.g. a SlingHttpServletRequest or 
> a ResourceResolver.
> souch an injector can be simple like this:
> {code:java}
> @Component
> @Service
> @Property(name = Constants.SERVICE_RANKING, intValue = 50)
> public class SelfAdaptInjector implements Injector {
>   public String getName() {
> return "selfadapt";
>   }
>   public Object getValue(Object pAdaptable, String pName, Type pType, 
> AnnotatedElement pElement,
> DisposalCallbackRegistry pCallbackRegistry) {
> if (!(pType instanceof Class)) {
>   return null;
> }
> if (!(pAdaptable instanceof Adaptable)) {
>   return null;
> }
> return ((Adaptable)pAdaptable).adaptTo((Class)pType);
>   }
> }
> {code}
> comment from Justin on this in the mailing list:
> {quote}
> The self injector is interesting. I held off on that initially because
> it seems too easy to create a circular injection. Any thoughts on how
> that can be avoided?
> \[...\]
> Regards,
> Justin
> {quote}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (SLING-3715) Sling Models: Support for class-based dependency injection

[Justin Edelson (JIRA)]

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

Justin Edelson commented on SLING-3715:
---

To be clear, Sling Models already supports class-based injection; the OSGi 
Service injector is an example of class-based injection. Is there some specific 
change you see as necessary?

The distinction between currentPage and resourcePage isn't something that the 
BindingsInjector is going to be aware of.

> Sling Models: Support for class-based dependency injection
> --
>
> Key: SLING-3715
> URL: https://issues.apache.org/jira/browse/SLING-3715
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Stefan Seifert
>Priority: Minor
>
> Currently Sling Models dependency injection is primary based on parameter 
> name-based injection, and not on class-based injection (the latter is more 
> common in Spring and comparable frameworks).
> here is Justins opinion on this topic (from the mailing list) and why he 
> prefers name-based injection:
> {quote}
> Hi Stefan,
> The big problem IMHO with injecting by class vs. name is that by class
> is too ambigious in many cases. For example, in AEM, it is relatively
> common to want to inject a Page object, but in fact there are two
> different page objects which come into play (currentPage and
> resourcePage) and getting the wrong one could be highly problematic.
> You are correct that things like the request and response could
> presumably be injected by class rather than by name, but the question
> then becomes how do we judge these cases? In my opinion, the bindings
> names are sensible. I personally don't find myself wanting to write
> this very often:
> {code:java}
> @Inject
> private SlingHttpServletRequest somenameOtherThanRequest;
> {code}
> \[...\]
> Regards,
> Justin
> {quote}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Re: [VOTE] Release Apache Sling IDE Tooling 1.0.0

[Justin Edelson]

+1

On Mon, Jun 30, 2014 at 12:14 PM, Robert Munteanu  wrote:
> I think I've gotten the right Maven/Tycho incantations set up and
> deployed the 1.0.0 artifacts to
>
> https://repository.apache.org/content/repositories/orgapachesling-1072/
>
> The single compromise that I had to make is that the integration tests
> were not included in the reactor build and therefore not deployed to
> the nexus repo. Hopefully that's acceptable for the release.
>
> I can restart the release vote if needed ( third time's the charm? )
> but it would be good to know that I got things right this time.
>
> Note: check_staged_release.sh took about 30 minutes to complete for me.
>
> Thanks,
>
> Robert
>
> On Mon, Jun 30, 2014 at 1:53 PM, Carsten Ziegeler  
> wrote:
>> Thanks for the info, Robert - I'm not sure what the best approach is,
>> however the zip now contains 1.0.0-SNAPSHOT as versions but I guess the
>> final release should be 1.0.0. This would mean we're voting on something
>> which is then not released. On the other hand, if we put up 1.0.0 in a
>> globally available space everyone can simply download it from there and
>> voting, especially withdrawing the release is way harder.
>>
>> Carsten
>>
>>
>> 2014-06-30 10:06 GMT+02:00 Robert Munteanu :
>>
>>> Hi Carsten,
>>>
>>> On Mon, Jun 30, 2014 at 8:57 AM, Carsten Ziegeler 
>>> wrote:
>>> > Why is this release not following the normal release procedure and
>>> > available via the staging maven repo?
>>>
>>> There are two main reasons.
>>>
>>> 1. While the build is driven by Maven, building Eclipse plug-ins with
>>> Tycho means that some of the regular Maven plugins don't work. For
>>> instance, the source and javadoc plugin, see [1],[2] . Since IIUC the
>>> release is based on the source code, and the binaries are just for
>>> convenience, I opted not to make the release run on the output of
>>> individual projects, but on the whole source zip.
>>>
>>> 2. If I were to deploy the plug-ins by themselves to the repo, it
>>> would not be trivial to assemble back an p2/Eclipse update which can
>>> be used to test the functionality of the release.
>>>
>>> That being said, I'd be more than happy to refine this process, so
>>> suggestions on how to do that are welcome :-)
>>>
>>> Thanks,
>>>
>>> Robert
>>>
>>>
>>> [1]: https://dev.eclipse.org/mhonarc/lists/tycho-user/msg05730.html
>>> [2]: https://bugs.eclipse.org/bugs/show_bug.cgi?id=398061
>>>
>>> >
>>> > Carsten
>>> >
>>> >
>>> > 2014-06-29 21:32 GMT+02:00 Robert Munteanu :
>>> >
>>> >> Anyone?
>>> >>
>>> >> Robert
>>> >>
>>> >> On Thu, Jun 26, 2014 at 11:32 AM, Robert Munteanu 
>>> >> wrote:
>>> >> > Hi,
>>> >> >
>>> >> > We solved 144 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.
>>> >>
>>> >
>>> >
>>> >
>>> > --
>>> > Carsten Ziegeler
>>> > Adobe Research Switzerland
>>> > cziege...@apache.org
>>>
>>
>>
>>
>> --
>> Carsten Ziegeler
>> Adobe Research Switzerland
>> cziege...@apache.org
>
>
>
> --
> Sent from my (old) computer

[jira] [Commented] (SLING-3709) Sling Models: Allow caller to deal with exceptions

[Justin Edelson (JIRA)]

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

Justin Edelson commented on SLING-3709:
---

Created SLING-3714 for the generic concept of extending the Adaptable 
interface. Personally, I would prefer the approach I put in there to throwing 
an exception as it doesn't require an API change per se.

> Sling Models: Allow caller to deal with exceptions
> --
>
> Key: SLING-3709
> URL: https://issues.apache.org/jira/browse/SLING-3709
> Project: Sling
>  Issue Type: Improvement
>Affects Versions: Sling Models Implementation 1.0.4, Sling Models 
> Implementation 1.0.6
>Reporter: Konrad Windszus
>
> Currently due to the specification of the adaptTo-method to return null if 
> adaptation is not possible, the caller is not notified about any exceptions 
> (because they are caught within the ModelAdapterFactory).
> This is e.g. necessary to deal with validation exceptions properly (i.e. 
> required field injection not possible).  The problem was also discussed 
> briefly in 
> http://apache-sling.73963.n3.nabble.com/Silng-Models-Validation-Framework-td4033411.html.
> All exceptions either being thrown by the 
> @PostConstruct method or caused by the field/method injection are not 
> propagated but basically swallowed by Sling Models.
> It would be great to be able to catch those exceptions either in the view or 
> in a servlet filter. I think it should be possible to throw unchecked 
> exceptions in the ModelAdapterFactory.getFactory() method if it is requested 
> (i.e. through a global OSGi configuration flag for Sling Models).
> WDYT?
> Would you accept such a patch or do you think this breaks the API (also 
> compare with 
> https://issues.apache.org/jira/browse/SLING-2712?focusedCommentId=13561516&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13561516).
> If it does not work through the adaptTo, SlingModels should provide an 
> alternative way of instanciating models (and propagating exceptions), 
> although this is kind of tricky, because it internally relies on adaptTo as 
> well (e.g. in 
> https://github.com/apache/sling/blob/trunk/bundles/extensions/models/impl/src/main/java/org/apache/sling/models/impl/ModelAdapterFactory.java#L647)



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (SLING-3714) Allow for a caller to request a non-null response from adaptTo()

[Justin Edelson (JIRA)]

Justin Edelson created SLING-3714:
-

 Summary: Allow for a caller to request a non-null response from 
adaptTo()
 Key: SLING-3714
 URL: https://issues.apache.org/jira/browse/SLING-3714
 Project: Sling
  Issue Type: Improvement
Reporter: Justin Edelson


See SLING-3709 for a Sling Models-specific request. As I commented there, I 
think this makes more sense as a core change to the Adaptable interface.

One option:

resource.adaptTo(Result.class)

Which returns a Result object, which has an API like:

interface Result {
boolean isSuccess();
T getObject();
List getErrors();
}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Re: [RT] Sling Models as scoped Dependency Injection Framework

[Justin Edelson]

Hi Stefan,
The big problem IMHO with injecting by class vs. name is that by class
is too ambigious in many cases. For example, in AEM, it is relatively
common to want to inject a Page object, but in fact there are two
different page objects which come into play (currentPage and
resourcePage) and getting the wrong one could be highly problematic.
You are correct that things like the request and response could
presumably be injected by class rather than by name, but the question
then becomes how do we judge these cases? In my opinion, the bindings
names are sensible. I personally don't find myself wanting to write
this very often:

@Inject
private SlingHttpServletRequest somenameOtherThanRequest;

The self injector is interesting. I held off on that initially because
it seems too easy to create a circular injection. Any thoughts on how
that can be avoided?

I'm certainly open to patches which broaden the scope for constructor
injection and @PreDestroy.

Regards,
Justin

On Mon, Jun 30, 2014 at 10:13 AM, Stefan Seifert  wrote:
> in the last days we played around with Sling Models as underpinning of our 
> views in a Sling+Sightly based application. it works fantastic. but during 
> our experiments we detected that we were not using Sling Models for accessing 
> resource content, i.e. we are not adapting resources to models to access its 
> data. this is not required when using JSP or Sightly because you can access 
> the properties directly. but we were using Sling Models as Dependency 
> Injection frameworks for our java controller classes which are used behind 
> the views, which need access to scoped objects of the current request like 
> resource resolver and others. and if those controller classes need other 
> business classes which depend on scope objects, we use Sling Models injection 
> for them as well.
>
> a very simple example for illustration:
>
> this is a controller class behind the view:
>
> @Model(adaptables = SlingHttpServletRequest.class)
> public class MyController {
>
>   @Inject
>   private MyBusinessClass businessClass;
>
>   private String result;
>
>   @PostConstruct
>   protected void activate() {
> result = this.businessClass.calculateTheResult();
>   }
>
>   public String getResult() {
> return this.result;
>   }
>
> }
>
> and this is the business classes used by the controller
>
> @Model(adaptables = SlingHttpServletRequest.class)
> public class MyBusinessClass {
>
>   @Inject
>   private ResourceResolver resourceResolver;
>
>   public String calculateTheResult() {
> // access resources using resource resolver
> return "myResult";
>   }
>
> }
>
> effectively we can use Sling Models to navigate through a hierarchy of loose 
> coupled POJOs all using DI for getting the dependencies they need - much like 
> in Spring. we have already dependency injection in Felix SCR/OSGi? that's 
> right, but only for OSGi services, and not for "scoped" objects depending on 
> a current request or resource resolver instance.
>
> using the adapter concept to adapt the controller and business classes from 
> the scope object they depend on (e.g. from SlingHttpServletRequest for 
> request scope, from ResourceResolver if they need access to resources in 
> context of a JCR user session etc.) they get all scope context objects they 
> need, and those that can be adapted from them. and of course it's still 
> possible to inject OSGi services as well.
>
> out of the box the sample displayed above will not work with Sling Models - a 
> small custom injector is required:
>
> @Component
> @Service
> @Property(name = Constants.SERVICE_RANKING, intValue = 50)
> public class SelfAdaptInjector implements Injector {
>
>   public String getName() {
> return "selfadapt";
>   }
>
>   public Object getValue(Object pAdaptable, String pName, Type pType, 
> AnnotatedElement pElement, DisposalCallbackRegistry pCallbackRegistry) {
> if (!(pType instanceof Class)) {
>   return null;
> }
> if (!(pAdaptable instanceof Adaptable)) {
>   return null;
> }
> return ((Adaptable)pAdaptable).adaptTo((Class)pType);
>   }
>
> }
>
> which effectively supports navigation through a graph of objects which share 
> the same scope adaptable. using another custom injector which allows indirect 
> adaption from SlingHttpServletRequest->ResourceResolver->CustomClass it is 
> possible to have classes that can be used both in request scope, and in 
> ResourceResolver-only scope as well (the latter may be a resource resolver 
> instance which is opened in context of an OSGi service or event handler). 
> this is already possible via "via", but i want to avoid boilerplate code as 
> much as possible for much-used context objects.
>
> additionally all relevant "context" objects that can be derived from the 
> adaptable should be supported for injection. Justin already added in 
> SLING-3700 as custom injector for resource resolver, but it should support 
> others as well, e.g. injecting the request, t

[jira] [Commented] (SLING-3709) Sling Models: Allow caller to deal with exceptions

[Justin Edelson (JIRA)]

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

Justin Edelson commented on SLING-3709:
---

I think this needs to be handled at the Adaptable API. Having a separate API 
for Sling Models violates one of the key design principals (and, as you note, 
won't actually work for complex object graphs). Of course, changing the 
Adaptable API is non-trival, but if it worth doing for Sling Models-based 
adaptables, it is worth doing for all adaptables.

> Sling Models: Allow caller to deal with exceptions
> --
>
> Key: SLING-3709
> URL: https://issues.apache.org/jira/browse/SLING-3709
> Project: Sling
>  Issue Type: Improvement
>Affects Versions: Sling Models Implementation 1.0.4, Sling Models 
> Implementation 1.0.6
>Reporter: Konrad Windszus
>
> Currently due to the specification of the adaptTo-method to return null if 
> adaptation is not possible, the caller is not notified about any exceptions 
> (because they are caught within the ModelAdapterFactory).
> This is e.g. necessary to deal with validation exceptions properly (i.e. 
> required field injection not possible).  The problem was also discussed 
> briefly in 
> http://apache-sling.73963.n3.nabble.com/Silng-Models-Validation-Framework-td4033411.html.
> All exceptions either being thrown by the 
> @PostConstruct method or caused by the field/method injection are not 
> propagated but basically swallowed by Sling Models.
> It would be great to be able to catch those exceptions either in the view or 
> in a servlet filter. I think it should be possible to throw unchecked 
> exceptions in the ModelAdapterFactory.getFactory() method if it is requested 
> (i.e. through a global OSGi configuration flag for Sling Models).
> WDYT?
> Would you accept such a patch or do you think this breaks the API (also 
> compare with 
> https://issues.apache.org/jira/browse/SLING-2712?focusedCommentId=13561516&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13561516).
> If it does not work through the adaptTo, SlingModels should provide an 
> alternative way of instanciating models (and propagating exceptions), 
> although this is kind of tricky, because it internally relies on adaptTo as 
> well (e.g. in 
> https://github.com/apache/sling/blob/trunk/bundles/extensions/models/impl/src/main/java/org/apache/sling/models/impl/ModelAdapterFactory.java#L647)



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Re: [VOTE] Release Apache Sling IDE Tooling 1.0.0

[Justin Edelson]

Robert-
Are you going to re-call the vote? I see some activity from you which
makes it look like you are.

Regards,
Justin

On Mon, Jun 30, 2014 at 6:53 AM, Carsten Ziegeler  wrote:
> Thanks for the info, Robert - I'm not sure what the best approach is,
> however the zip now contains 1.0.0-SNAPSHOT as versions but I guess the
> final release should be 1.0.0. This would mean we're voting on something
> which is then not released. On the other hand, if we put up 1.0.0 in a
> globally available space everyone can simply download it from there and
> voting, especially withdrawing the release is way harder.
>
> Carsten
>
>
> 2014-06-30 10:06 GMT+02:00 Robert Munteanu :
>
>> Hi Carsten,
>>
>> On Mon, Jun 30, 2014 at 8:57 AM, Carsten Ziegeler 
>> wrote:
>> > Why is this release not following the normal release procedure and
>> > available via the staging maven repo?
>>
>> There are two main reasons.
>>
>> 1. While the build is driven by Maven, building Eclipse plug-ins with
>> Tycho means that some of the regular Maven plugins don't work. For
>> instance, the source and javadoc plugin, see [1],[2] . Since IIUC the
>> release is based on the source code, and the binaries are just for
>> convenience, I opted not to make the release run on the output of
>> individual projects, but on the whole source zip.
>>
>> 2. If I were to deploy the plug-ins by themselves to the repo, it
>> would not be trivial to assemble back an p2/Eclipse update which can
>> be used to test the functionality of the release.
>>
>> That being said, I'd be more than happy to refine this process, so
>> suggestions on how to do that are welcome :-)
>>
>> Thanks,
>>
>> Robert
>>
>>
>> [1]: https://dev.eclipse.org/mhonarc/lists/tycho-user/msg05730.html
>> [2]: https://bugs.eclipse.org/bugs/show_bug.cgi?id=398061
>>
>> >
>> > Carsten
>> >
>> >
>> > 2014-06-29 21:32 GMT+02:00 Robert Munteanu :
>> >
>> >> Anyone?
>> >>
>> >> Robert
>> >>
>> >> On Thu, Jun 26, 2014 at 11:32 AM, Robert Munteanu 
>> >> wrote:
>> >> > Hi,
>> >> >
>> >> > We solved 144 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.
>> >>
>> >
>> >
>> >
>> > --
>> > Carsten Ziegeler
>> > Adobe Research Switzerland
>> > cziege...@apache.org
>>
>
>
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org

[jira] [Resolved] (SLING-3706) Sling Resource Resolver - NPE with oak for vanity paths

[Justin Edelson (JIRA)]

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

Justin Edelson resolved SLING-3706.
---

   Resolution: Fixed
Fix Version/s: Resource Resolver 1.1.2

> Sling Resource Resolver - NPE with oak for vanity paths
> ---
>
> Key: SLING-3706
> URL: https://issues.apache.org/jira/browse/SLING-3706
> Project: Sling
>  Issue Type: Bug
>  Components: ResourceResolver
>Affects Versions: Resource Resolver 1.1.2
>Reporter: Andrei Dulvac
>    Assignee: Justin Edelson
>  Labels: oak
> Fix For: Resource Resolver 1.1.2
>
>
> The sling resource resolver fails on OAK if you add the sling:vanityPath 
> property quasi-concurrently. Just add nodes and add the property in an 
> automated way, without wait.
> This works on sling on jackrabbit, fails with oak.
> I get:
> {code}
> 23.06.2014 17:47:17.760 WARN [pool-5-thread-4] org.apache.felix.eventadmin 
> Service [Map Entries Observation,2923] EventAdmin: Exception during event 
> dispatch [org.osgi.service.event.Event 
> [topic=org/apache/sling/api/resource/Resource/CHANGED] | 
> [org.osgi.service.event.EventHandler] | 
> Bundle(org.apache.sling.resourceresolver [217])] 
> (java.lang.NullPointerException)
> java.lang.NullPointerException: null
> at 
> org.apache.sling.resourceresolver.impl.mapping.MapEntries.loadVanityPath(MapEntries.java:748)
> at 
> org.apache.sling.resourceresolver.impl.mapping.MapEntries.doAddVanity(MapEntries.java:292)
> at 
> org.apache.sling.resourceresolver.impl.mapping.MapEntries.doAddAttributes(MapEntries.java:209)
> at 
> org.apache.sling.resourceresolver.impl.mapping.MapEntries.handleEvent(MapEntries.java:505)
> at 
> org.apache.felix.eventadmin.impl.handler.EventHandlerProxy.sendEvent(EventHandlerProxy.java:412)
> at 
> org.apache.felix.eventadmin.impl.tasks.SyncDeliverTasks.execute(SyncDeliverTasks.java:118)
> at 
> org.apache.felix.eventadmin.impl.handler.EventAdminImpl.sendEvent(EventAdminImpl.java:114)
> at 
> org.apache.felix.eventadmin.impl.security.EventAdminSecurityDecorator.sendEvent(EventAdminSecurityDecorator.java:96)
> at 
> org.apache.sling.jcr.resource.internal.OakResourceListener.sendOsgiEvent(OakResourceListener.java:243)
> at 
> org.apache.sling.jcr.resource.internal.OakResourceListener.changed(OakResourceListener.java:133)
> at 
> org.apache.jackrabbit.oak.plugins.observation.NodeObserver$NodeEventHandler.leave(NodeObserver.java:204)
> at 
> org.apache.jackrabbit.oak.plugins.observation.FilteredHandler.leave(FilteredHandler.java:51)
> at 
> org.apache.jackrabbit.oak.plugins.observation.EventGenerator$Continuation.run(EventGenerator.java:154)
> at 
> org.apache.jackrabbit.oak.plugins.observation.EventGenerator.generate(EventGenerator.java:98)
> at 
> org.apache.jackrabbit.oak.plugins.observation.NodeObserver.contentChanged(NodeObserver.java:155)
> at 
> org.apache.jackrabbit.oak.spi.commit.BackgroundObserver$1$1.call(BackgroundObserver.java:117)
> at 
> org.apache.jackrabbit.oak.spi.commit.BackgroundObserver$1$1.call(BackgroundObserver.java:111)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:722)
> {code}
> After debugging this, the problem is that resource is null in 
> MapEntries.java:291 :
> {code}
>  private void doAddVanity(String path) {
> Resource resource = resolver.getResource(path);
> loadVanityPath(resource, resolveMapsMap, vanityTargets);
> }
> {code}
> Introduced by r1605423



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (SLING-3706) Sling Resource Resolver - NPE with oak for vanity paths

[Justin Edelson (JIRA)]

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

Justin Edelson commented on SLING-3706:
---

It seems that under high load, the oak refresh time of 1 second for 
non-observation sessions isn't sufficient. I fixed this in r1606130 by forcing 
a refresh when a processable change occurs. While this adds a bit of 
inefficiency, since the change in SLING-3505 dramatically *increased* 
efficiency, I think this is OK.

> Sling Resource Resolver - NPE with oak for vanity paths
> ---
>
> Key: SLING-3706
> URL: https://issues.apache.org/jira/browse/SLING-3706
> Project: Sling
>  Issue Type: Bug
>  Components: ResourceResolver
>Affects Versions: Resource Resolver 1.1.2
>Reporter: Andrei Dulvac
>Assignee: Justin Edelson
>  Labels: oak
> Fix For: Resource Resolver 1.1.2
>
>
> The sling resource resolver fails on OAK if you add the sling:vanityPath 
> property quasi-concurrently. Just add nodes and add the property in an 
> automated way, without wait.
> This works on sling on jackrabbit, fails with oak.
> I get:
> {code}
> 23.06.2014 17:47:17.760 WARN [pool-5-thread-4] org.apache.felix.eventadmin 
> Service [Map Entries Observation,2923] EventAdmin: Exception during event 
> dispatch [org.osgi.service.event.Event 
> [topic=org/apache/sling/api/resource/Resource/CHANGED] | 
> [org.osgi.service.event.EventHandler] | 
> Bundle(org.apache.sling.resourceresolver [217])] 
> (java.lang.NullPointerException)
> java.lang.NullPointerException: null
> at 
> org.apache.sling.resourceresolver.impl.mapping.MapEntries.loadVanityPath(MapEntries.java:748)
> at 
> org.apache.sling.resourceresolver.impl.mapping.MapEntries.doAddVanity(MapEntries.java:292)
> at 
> org.apache.sling.resourceresolver.impl.mapping.MapEntries.doAddAttributes(MapEntries.java:209)
> at 
> org.apache.sling.resourceresolver.impl.mapping.MapEntries.handleEvent(MapEntries.java:505)
> at 
> org.apache.felix.eventadmin.impl.handler.EventHandlerProxy.sendEvent(EventHandlerProxy.java:412)
> at 
> org.apache.felix.eventadmin.impl.tasks.SyncDeliverTasks.execute(SyncDeliverTasks.java:118)
> at 
> org.apache.felix.eventadmin.impl.handler.EventAdminImpl.sendEvent(EventAdminImpl.java:114)
> at 
> org.apache.felix.eventadmin.impl.security.EventAdminSecurityDecorator.sendEvent(EventAdminSecurityDecorator.java:96)
> at 
> org.apache.sling.jcr.resource.internal.OakResourceListener.sendOsgiEvent(OakResourceListener.java:243)
> at 
> org.apache.sling.jcr.resource.internal.OakResourceListener.changed(OakResourceListener.java:133)
> at 
> org.apache.jackrabbit.oak.plugins.observation.NodeObserver$NodeEventHandler.leave(NodeObserver.java:204)
> at 
> org.apache.jackrabbit.oak.plugins.observation.FilteredHandler.leave(FilteredHandler.java:51)
> at 
> org.apache.jackrabbit.oak.plugins.observation.EventGenerator$Continuation.run(EventGenerator.java:154)
> at 
> org.apache.jackrabbit.oak.plugins.observation.EventGenerator.generate(EventGenerator.java:98)
> at 
> org.apache.jackrabbit.oak.plugins.observation.NodeObserver.contentChanged(NodeObserver.java:155)
> at 
> org.apache.jackrabbit.oak.spi.commit.BackgroundObserver$1$1.call(BackgroundObserver.java:117)
> at 
> org.apache.jackrabbit.oak.spi.commit.BackgroundObserver$1$1.call(BackgroundObserver.java:111)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:722)
> {code}
> After debugging this, the problem is that resource is null in 
> MapEntries.java:291 :
> {code}
>  private void doAddVanity(String path) {
> Resource resource = resolver.getResource(path);
> loadVanityPath(resource, resolveMapsMap, vanityTargets);
> }
> {code}
> Introduced by r1605423



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (SLING-3707) changing/removing a vanity path from a node named jcr:content doesn't correctly remove the vanity path

[Justin Edelson (JIRA)]

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

Justin Edelson resolved SLING-3707.
---

Resolution: Fixed

Fixed in r1606124

> changing/removing a vanity path from a node named jcr:content doesn't 
> correctly remove the vanity path
> --
>
> Key: SLING-3707
> URL: https://issues.apache.org/jira/browse/SLING-3707
> Project: Sling
>  Issue Type: Bug
>Reporter: Justin Edelson
>    Assignee: Justin Edelson
> Fix For: Resource Resolver 1.1.2
>
>
> This is due to a typo in SLING-3505's changes.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (SLING-3707) changing/removing a vanity path from a node named jcr:content doesn't correctly remove the vanity path

[Justin Edelson (JIRA)]

Justin Edelson created SLING-3707:
-

 Summary: changing/removing a vanity path from a node named 
jcr:content doesn't correctly remove the vanity path
 Key: SLING-3707
 URL: https://issues.apache.org/jira/browse/SLING-3707
 Project: Sling
  Issue Type: Bug
Reporter: Justin Edelson
Assignee: Justin Edelson
 Fix For: Resource Resolver 1.1.2


This is due to a typo in SLING-3505's changes.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Assigned] (SLING-3706) Sling Resource Resolver - NPE with oak for vanity paths

[Justin Edelson (JIRA)]

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

Justin Edelson reassigned SLING-3706:
-

Assignee: Justin Edelson

> Sling Resource Resolver - NPE with oak for vanity paths
> ---
>
> Key: SLING-3706
> URL: https://issues.apache.org/jira/browse/SLING-3706
> Project: Sling
>  Issue Type: Bug
>  Components: ResourceResolver
>Affects Versions: Resource Resolver 1.1.2
>Reporter: Andrei Dulvac
>    Assignee: Justin Edelson
>  Labels: oak
>
> The sling resource resolver fails on OAK if you add the sling:vanityPath 
> property quasi-concurrently. Just add nodes and add the property in an 
> automated way, without wait.
> This works on sling on jackrabbit, fails with oak.
> I get:
> {code}
> 23.06.2014 17:47:17.760 WARN [pool-5-thread-4] org.apache.felix.eventadmin 
> Service [Map Entries Observation,2923] EventAdmin: Exception during event 
> dispatch [org.osgi.service.event.Event 
> [topic=org/apache/sling/api/resource/Resource/CHANGED] | 
> [org.osgi.service.event.EventHandler] | 
> Bundle(org.apache.sling.resourceresolver [217])] 
> (java.lang.NullPointerException)
> java.lang.NullPointerException: null
> at 
> org.apache.sling.resourceresolver.impl.mapping.MapEntries.loadVanityPath(MapEntries.java:748)
> at 
> org.apache.sling.resourceresolver.impl.mapping.MapEntries.doAddVanity(MapEntries.java:292)
> at 
> org.apache.sling.resourceresolver.impl.mapping.MapEntries.doAddAttributes(MapEntries.java:209)
> at 
> org.apache.sling.resourceresolver.impl.mapping.MapEntries.handleEvent(MapEntries.java:505)
> at 
> org.apache.felix.eventadmin.impl.handler.EventHandlerProxy.sendEvent(EventHandlerProxy.java:412)
> at 
> org.apache.felix.eventadmin.impl.tasks.SyncDeliverTasks.execute(SyncDeliverTasks.java:118)
> at 
> org.apache.felix.eventadmin.impl.handler.EventAdminImpl.sendEvent(EventAdminImpl.java:114)
> at 
> org.apache.felix.eventadmin.impl.security.EventAdminSecurityDecorator.sendEvent(EventAdminSecurityDecorator.java:96)
> at 
> org.apache.sling.jcr.resource.internal.OakResourceListener.sendOsgiEvent(OakResourceListener.java:243)
> at 
> org.apache.sling.jcr.resource.internal.OakResourceListener.changed(OakResourceListener.java:133)
> at 
> org.apache.jackrabbit.oak.plugins.observation.NodeObserver$NodeEventHandler.leave(NodeObserver.java:204)
> at 
> org.apache.jackrabbit.oak.plugins.observation.FilteredHandler.leave(FilteredHandler.java:51)
> at 
> org.apache.jackrabbit.oak.plugins.observation.EventGenerator$Continuation.run(EventGenerator.java:154)
> at 
> org.apache.jackrabbit.oak.plugins.observation.EventGenerator.generate(EventGenerator.java:98)
> at 
> org.apache.jackrabbit.oak.plugins.observation.NodeObserver.contentChanged(NodeObserver.java:155)
> at 
> org.apache.jackrabbit.oak.spi.commit.BackgroundObserver$1$1.call(BackgroundObserver.java:117)
> at 
> org.apache.jackrabbit.oak.spi.commit.BackgroundObserver$1$1.call(BackgroundObserver.java:111)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:722)
> {code}
> After debugging this, the problem is that resource is null in 
> MapEntries.java:291 :
> {code}
>  private void doAddVanity(String path) {
> Resource resource = resolver.getResource(path);
> loadVanityPath(resource, resolveMapsMap, vanityTargets);
> }
> {code}
> Introduced by r1605423



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (SLING-3704) Provide better examples/documentation on how to test an injector

[Justin Edelson (JIRA)]

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

Justin Edelson updated SLING-3704:
--

Summary: Provide better examples/documentation on how to test an injector  
(was: Custom injectors)

Changing the title to better reflect the issue (I think). Although the impl 
bundle has reasonable examples of how to write an injector, but currently the 
test code is wrapped up in both testing the framework and the injectors. There 
are a examples of testing just an injector, but they are few and far between.

> Provide better examples/documentation on how to test an injector
> 
>
> Key: SLING-3704
> URL: https://issues.apache.org/jira/browse/SLING-3704
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: Sling Models Implementation 1.0.6, Sling Models API 1.0.2
>Reporter: Krystian Panek
>
> In the future, I plan to create a custom injector for Sling Models. It would 
> be great if documentation will have some section which describes how do it in 
> a most simple way.
> Also API / Impl could be improved for that perspective of usage.
> I would like to use in my package following snippet which I found in unit 
> tests:
> {quote}
> factory = new ModelAdapterFactory();
> factory.activate(componentCtx);
> factory.bindInjector(new MyCustomInjector(), new 
> ServicePropertiesMap(1, 1));
> {quote}
> But methods in factory have protected scope and I cannot use them directly in 
> my package without using a reflection.
> I realize that maybe custom injectors are not planned in design but I hope 
> that suggested improvement could make SM more extensible.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (SLING-3512) All dependencies referenced from TEI classes should have "compile" scope

[Justin Edelson (JIRA)]

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

Justin Edelson resolved SLING-3512.
---

Resolution: Fixed

> All dependencies referenced from TEI classes should have "compile" scope
> 
>
> Key: SLING-3512
> URL: https://issues.apache.org/jira/browse/SLING-3512
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Affects Versions: Scripting JSP-Taglib 2.2.0
>Reporter: Konrad Windszus
>Assignee: Justin Edelson
> Fix For: Scripting JSP-Taglib 2.2.2
>
>
> Currently some classes which are referenced from TEI classes (e.g. 
> DefineObjectsTEI) cannot be resolved within an IDE, because the according 
> dependency is given with scope "provided". Since provided dependencies are 
> not evaluated if given in a transitive way [0], the classpath of the 
> referencing JSP does not necessarily contain those transitive dependencies, 
> but they are necessary for the TEI to be instanciated within the IDE.
> For example the DefineObjectsTEI references classes from org.apache.sling.api 
> and slf4j-api. Therefore both dependencies should have the "compile" scope.
> [0] - 
> http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (SLING-3700) Add a simple injector to get the resource resolver

[Justin Edelson (JIRA)]

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

Justin Edelson commented on SLING-3700:
---

[~kwin] That's true, but the bindings are only available if you are adapting 
from a SlingHttpServletRequest (and are in the context of a script).

> Add a simple injector to get the resource resolver
> --
>
> Key: SLING-3700
> URL: https://issues.apache.org/jira/browse/SLING-3700
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Justin Edelson
>Assignee: Justin Edelson
> Fix For: Sling Models Implementation 1.0.6
>
>
> Currently, injecting a ResourceResolver into a model class which is adapted 
> from a resource is not possible - you have to use constructor injection of 
> the Resource and then get the Resource Resolver from the Resource. This is 
> non-intuitive and should be fixed.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Re: [VOTE] Release Apache Sling Models API 1.0.2 & Implementation 1.0.6

[Justin Edelson]

Hi Robert,
Can you try a local build again (after updating from trunk)?

Regards,
Justin

On Wed, Jun 25, 2014 at 4:40 PM, Robert Munteanu  wrote:
> On Wed, Jun 25, 2014 at 7:01 PM, Justin Edelson
>  wrote:
>> Please vote to approve this release:
>>
>>   [ ] +1 Approve the release
>>   [ ]  0 Don't care
>>   [ ] -1 Don't release, because ...
>
> +1.
>
> On a related note, the Models ITs seem to be failing for a month now
> on Jenkins [1] , and they fail locally as well. It would be nice to
> see them pass.
>
> Robert
>
> [1]: 
> https://builds.apache.org/view/S-Z/view/Sling/job/sling-trunk-1.6/org.apache.sling$org.apache.sling.models.integration-tests/