[VOTE] Release Apache Sling Pipe version 1.1.0

[Nicolas Peltier]

Hi,

We solved 7 issues in this release:
https://issues.apache.org/jira/projects/SLING/versions/12341593

There are still some outstanding issues:
https://issues.apache.org/jira/browse/SLING-6593

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

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 1791 /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] [Assigned] (SLING-7117) add jsonpath expression for jsonpipe

[Nicolas Peltier (JIRA)]

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

Nicolas Peltier reassigned SLING-7117:
--

Assignee: Nicolas Peltier

> add jsonpath expression for jsonpipe
> 
>
> Key: SLING-7117
> URL: https://issues.apache.org/jira/browse/SLING-7117
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: Pipes 1.0.4
>Reporter: Nicolas Peltier
>Assignee: Nicolas Peltier
> Fix For: pipes 1.1.0
>
>
> it's not always that on the internet json streams are arrays of objects that 
> interest us. More often you find the array you want to use somewhere within 
> the json. 
> To adapt to this, JsonPipe configuration should mention where to fetch the 
> array it will use for generating its output.
> using JsonPath (http://goessner.net/articles/JsonPath/) seems good enough 
> {{$.results}} e.g.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (SLING-7117) add jsonpath expression for jsonpipe

[Nicolas Peltier (JIRA)]

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

Nicolas Peltier resolved SLING-7117.


fixed in r1809079

> add jsonpath expression for jsonpipe
> 
>
> Key: SLING-7117
> URL: https://issues.apache.org/jira/browse/SLING-7117
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: Pipes 1.0.4
>Reporter: Nicolas Peltier
> Fix For: pipes 1.1.0
>
>
> it's not always that on the internet json streams are arrays of objects that 
> interest us. More often you find the array you want to use somewhere within 
> the json. 
> To adapt to this, JsonPipe configuration should mention where to fetch the 
> array it will use for generating its output.
> using JsonPath (http://goessner.net/articles/JsonPath/) seems good enough 
> {{$.results}} e.g.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: [git] Which git system do we want to use?

[Karl Pauls]

On Wed, Sep 20, 2017 at 9:06 PM, Robert Munteanu  wrote:
> Hi Justin,
>
> On Wed, 2017-09-20 at 16:06 +, Justin Edelson wrote:
>> Hi,
>> While it is true that this project does not have an existing Github-
>> centric
>> workflow, I suspect that most of us use such a workflow on other
>> projects,
>> so I would be more in favor of the dual-master system.
>
> Right, we can benefit from a Github-centric model, even if we don't
> have the whole setup ready by the time we complete the migration.

Personally, I think if we move to git we should move to github as much
as possible. Otherwise, what is the point.

regards,

Karl

> Thanks,
>
> Robert
>
>>
>> Regards,
>> Justin
>>
>> On Wed, Sep 20, 2017 at 11:48 AM Robert Munteanu 
>> wrote:
>>
>> > Hi,
>> >
>> > According to http://git.apache.org/ , there are two systems in use
>> > at
>> > the ASF:
>> >
>> > - the "Git Wip" system
>> > - the "Github Dual Master"
>> >
>> > I have not found any more information about these - Ian referenced
>> > the
>> > dual master some time ago [1], but AFAICT the "Wip" system is
>> > basically
>> > ASF hosted git mirrored to Github, while the "Dual Master" system
>> > allows us to push to Github as well as to the ASF Git.
>> >
>> > IMO the dual master system is for projects with a Github-centric
>> > workflow coming to the ASF, which is not our situation at all, so
>> > I'd
>> > go with the "Wip" system.
>> >
>> > What do others think?
>> >
>> > Thanks,
>> >
>> > Robert
>> >
>> >
>> > [1]: https://lists.apache.org/thread.html/b8b0003cf9fcb1c365a9ed354
>> > fe7c
>> > 20c2c4c5b465c952829e0eb4c78@1458668880@%3Cdev.sling.apache.org%3E
>> >
>



-- 
Karl Pauls
karlpa...@gmail.com

Re: [git] Which git system do we want to use?

[Robert Munteanu]

Hi Justin,

On Wed, 2017-09-20 at 16:06 +, Justin Edelson wrote:
> Hi,
> While it is true that this project does not have an existing Github-
> centric
> workflow, I suspect that most of us use such a workflow on other
> projects,
> so I would be more in favor of the dual-master system.

Right, we can benefit from a Github-centric model, even if we don't
have the whole setup ready by the time we complete the migration.

Thanks,

Robert

> 
> Regards,
> Justin
> 
> On Wed, Sep 20, 2017 at 11:48 AM Robert Munteanu 
> wrote:
> 
> > Hi,
> > 
> > According to http://git.apache.org/ , there are two systems in use
> > at
> > the ASF:
> > 
> > - the "Git Wip" system
> > - the "Github Dual Master"
> > 
> > I have not found any more information about these - Ian referenced
> > the
> > dual master some time ago [1], but AFAICT the "Wip" system is
> > basically
> > ASF hosted git mirrored to Github, while the "Dual Master" system
> > allows us to push to Github as well as to the ASF Git.
> > 
> > IMO the dual master system is for projects with a Github-centric
> > workflow coming to the ASF, which is not our situation at all, so
> > I'd
> > go with the "Wip" system.
> > 
> > What do others think?
> > 
> > Thanks,
> > 
> > Robert
> > 
> > 
> > [1]: https://lists.apache.org/thread.html/b8b0003cf9fcb1c365a9ed354
> > fe7c
> > 20c2c4c5b465c952829e0eb4c78@1458668880@%3Cdev.sling.apache.org%3E
> > 

Re: [git] Which git system do we want to use?

[Robert Munteanu]

Hi Tommaso,

On Wed, 2017-09-20 at 18:17 +, Tommaso Teofili wrote:
> in Apache OpenNLP we were on wip and then switched to gitbox
> afterwards
> because we found that easier when merging pull requests (less
> forks/origins
> to maintain) and wanted to enforce a stricter review process for
> commits so
> that now every contribution goes through a PR which needs +1s, on the
> other
> hand in Apache Lucene / Solr we have git-wip because we use it not
> much
> differently from how we used SVN in terms of development workflows.
> So I would say it depends on what we look for.

Do you recall any issues with using both github and the asf git repo as
masters? Or did you just settle with pushing to github and ignored the
asf repos? 

I would like to avoid any potential issues with getting the two masters
out of sync.

Thanks,

Robert

> For now I would opt for git-wip, but I see Justin's point and if more
> people want to go that way I can see the benefits.
> 
> My 2 cents,
> Tommaso
> 
> Il giorno mer 20 set 2017 alle ore 18:06 Justin Edelson <
> jus...@justinedelson.com> ha scritto:
> 
> > Hi,
> > While it is true that this project does not have an existing
> > Github-centric
> > workflow, I suspect that most of us use such a workflow on other
> > projects,
> > so I would be more in favor of the dual-master system.
> > 
> > Regards,
> > Justin
> > 
> > On Wed, Sep 20, 2017 at 11:48 AM Robert Munteanu  > g>
> > wrote:
> > 
> > > Hi,
> > > 
> > > According to http://git.apache.org/ , there are two systems in
> > > use at
> > > the ASF:
> > > 
> > > - the "Git Wip" system
> > > - the "Github Dual Master"
> > > 
> > > I have not found any more information about these - Ian
> > > referenced the
> > > dual master some time ago [1], but AFAICT the "Wip" system is
> > > basically
> > > ASF hosted git mirrored to Github, while the "Dual Master" system
> > > allows us to push to Github as well as to the ASF Git.
> > > 
> > > IMO the dual master system is for projects with a Github-centric
> > > workflow coming to the ASF, which is not our situation at all, so
> > > I'd
> > > go with the "Wip" system.
> > > 
> > > What do others think?
> > > 
> > > Thanks,
> > > 
> > > Robert
> > > 
> > > 
> > > [1]: https://lists.apache.org/thread.html/b8b0003cf9fcb1c365a9ed3
> > > 54fe7c
> > > 20c2c4c5b465c952829e0eb4c78@1458668880@%3Cdev.sling.apache.org%3E
> > > 

Re: [git] Which git system do we want to use?

[Robert Munteanu]

Hi Ian,

On Wed, 2017-09-20 at 19:32 +0100, Ian Boston wrote:
> Hi,
> If we can implement automation ontop of  the pull request using
> travis etc,
> then that would be a benefit of going for a github centric workflow.
> I dont
> if this is appropriate for Apache projects in general, or Slings
> workflow,
> but do know it works exceedingly well for other projects, even where
> there
> are high volumes of pull requests.
> 
> It also fosters open discussion of the code, which imho is good for
> the
> wider community.

That's a good point, thanks for raising it. As far as I can tell, there
is nothing stopping us from doing the same process in the git-wip
system, just that there is no 'merge' button, we have to do it
manually.

But I think that Justin has a good point with developing a Github-
centric workflow and enabling merging on Github would be quite
beneficial.

Thanks,

Robert

> Best Regards
> Ian
> 
> 
> On 20 September 2017 at 19:17, Tommaso Teofili  .com>
> wrote:
> 
> > in Apache OpenNLP we were on wip and then switched to gitbox
> > afterwards
> > because we found that easier when merging pull requests (less
> > forks/origins
> > to maintain) and wanted to enforce a stricter review process for
> > commits so
> > that now every contribution goes through a PR which needs +1s, on
> > the other
> > hand in Apache Lucene / Solr we have git-wip because we use it not
> > much
> > differently from how we used SVN in terms of development workflows.
> > So I would say it depends on what we look for.
> > For now I would opt for git-wip, but I see Justin's point and if
> > more
> > people want to go that way I can see the benefits.
> > 
> > My 2 cents,
> > Tommaso
> > 
> > Il giorno mer 20 set 2017 alle ore 18:06 Justin Edelson <
> > jus...@justinedelson.com> ha scritto:
> > 
> > > Hi,
> > > While it is true that this project does not have an existing
> > 
> > Github-centric
> > > workflow, I suspect that most of us use such a workflow on other
> > 
> > projects,
> > > so I would be more in favor of the dual-master system.
> > > 
> > > Regards,
> > > Justin
> > > 
> > > On Wed, Sep 20, 2017 at 11:48 AM Robert Munteanu  > > org>
> > > wrote:
> > > 
> > > > Hi,
> > > > 
> > > > According to http://git.apache.org/ , there are two systems in
> > > > use at
> > > > the ASF:
> > > > 
> > > > - the "Git Wip" system
> > > > - the "Github Dual Master"
> > > > 
> > > > I have not found any more information about these - Ian
> > > > referenced the
> > > > dual master some time ago [1], but AFAICT the "Wip" system is
> > > > basically
> > > > ASF hosted git mirrored to Github, while the "Dual Master"
> > > > system
> > > > allows us to push to Github as well as to the ASF Git.
> > > > 
> > > > IMO the dual master system is for projects with a Github-
> > > > centric
> > > > workflow coming to the ASF, which is not our situation at all,
> > > > so I'd
> > > > go with the "Wip" system.
> > > > 
> > > > What do others think?
> > > > 
> > > > Thanks,
> > > > 
> > > > Robert
> > > > 
> > > > 
> > > > [1]: https://lists.apache.org/thread.html/
> > 
> > b8b0003cf9fcb1c365a9ed354fe7c
> > > > 20c2c4c5b465c952829e0eb4c78@1458668880@%3Cdev.sling.apache.org%
> > > > 3E
> > > > 

Re: [git] Which git system do we want to use?

[Justin Edelson]

Hi Tommaso,
Was it a pain to switch from wip to gitbox?

Regards,
Justin

On Wed, Sep 20, 2017 at 2:17 PM Tommaso Teofili 
wrote:

> in Apache OpenNLP we were on wip and then switched to gitbox afterwards
> because we found that easier when merging pull requests (less forks/origins
> to maintain) and wanted to enforce a stricter review process for commits so
> that now every contribution goes through a PR which needs +1s, on the other
> hand in Apache Lucene / Solr we have git-wip because we use it not much
> differently from how we used SVN in terms of development workflows.
> So I would say it depends on what we look for.
> For now I would opt for git-wip, but I see Justin's point and if more
> people want to go that way I can see the benefits.
>
> My 2 cents,
> Tommaso
>
> Il giorno mer 20 set 2017 alle ore 18:06 Justin Edelson <
> jus...@justinedelson.com> ha scritto:
>
> > Hi,
> > While it is true that this project does not have an existing
> Github-centric
> > workflow, I suspect that most of us use such a workflow on other
> projects,
> > so I would be more in favor of the dual-master system.
> >
> > Regards,
> > Justin
> >
> > On Wed, Sep 20, 2017 at 11:48 AM Robert Munteanu 
> > wrote:
> >
> > > Hi,
> > >
> > > According to http://git.apache.org/ , there are two systems in use at
> > > the ASF:
> > >
> > > - the "Git Wip" system
> > > - the "Github Dual Master"
> > >
> > > I have not found any more information about these - Ian referenced the
> > > dual master some time ago [1], but AFAICT the "Wip" system is basically
> > > ASF hosted git mirrored to Github, while the "Dual Master" system
> > > allows us to push to Github as well as to the ASF Git.
> > >
> > > IMO the dual master system is for projects with a Github-centric
> > > workflow coming to the ASF, which is not our situation at all, so I'd
> > > go with the "Wip" system.
> > >
> > > What do others think?
> > >
> > > Thanks,
> > >
> > > Robert
> > >
> > >
> > > [1]:
> https://lists.apache.org/thread.html/b8b0003cf9fcb1c365a9ed354fe7c
> > > 20c2c4c5b465c952829e0eb4c78@1458668880@%3Cdev.sling.apache.org%3E
> > >
> >
>

Re: [git] Which git system do we want to use?

[Ian Boston]

Hi,
If we can implement automation ontop of  the pull request using travis etc,
then that would be a benefit of going for a github centric workflow. I dont
if this is appropriate for Apache projects in general, or Slings workflow,
but do know it works exceedingly well for other projects, even where there
are high volumes of pull requests.

It also fosters open discussion of the code, which imho is good for the
wider community.
Best Regards
Ian


On 20 September 2017 at 19:17, Tommaso Teofili 
wrote:

> in Apache OpenNLP we were on wip and then switched to gitbox afterwards
> because we found that easier when merging pull requests (less forks/origins
> to maintain) and wanted to enforce a stricter review process for commits so
> that now every contribution goes through a PR which needs +1s, on the other
> hand in Apache Lucene / Solr we have git-wip because we use it not much
> differently from how we used SVN in terms of development workflows.
> So I would say it depends on what we look for.
> For now I would opt for git-wip, but I see Justin's point and if more
> people want to go that way I can see the benefits.
>
> My 2 cents,
> Tommaso
>
> Il giorno mer 20 set 2017 alle ore 18:06 Justin Edelson <
> jus...@justinedelson.com> ha scritto:
>
> > Hi,
> > While it is true that this project does not have an existing
> Github-centric
> > workflow, I suspect that most of us use such a workflow on other
> projects,
> > so I would be more in favor of the dual-master system.
> >
> > Regards,
> > Justin
> >
> > On Wed, Sep 20, 2017 at 11:48 AM Robert Munteanu 
> > wrote:
> >
> > > Hi,
> > >
> > > According to http://git.apache.org/ , there are two systems in use at
> > > the ASF:
> > >
> > > - the "Git Wip" system
> > > - the "Github Dual Master"
> > >
> > > I have not found any more information about these - Ian referenced the
> > > dual master some time ago [1], but AFAICT the "Wip" system is basically
> > > ASF hosted git mirrored to Github, while the "Dual Master" system
> > > allows us to push to Github as well as to the ASF Git.
> > >
> > > IMO the dual master system is for projects with a Github-centric
> > > workflow coming to the ASF, which is not our situation at all, so I'd
> > > go with the "Wip" system.
> > >
> > > What do others think?
> > >
> > > Thanks,
> > >
> > > Robert
> > >
> > >
> > > [1]: https://lists.apache.org/thread.html/
> b8b0003cf9fcb1c365a9ed354fe7c
> > > 20c2c4c5b465c952829e0eb4c78@1458668880@%3Cdev.sling.apache.org%3E
> > >
> >
>

Re: [git] Which git system do we want to use?

[Tommaso Teofili]

in Apache OpenNLP we were on wip and then switched to gitbox afterwards
because we found that easier when merging pull requests (less forks/origins
to maintain) and wanted to enforce a stricter review process for commits so
that now every contribution goes through a PR which needs +1s, on the other
hand in Apache Lucene / Solr we have git-wip because we use it not much
differently from how we used SVN in terms of development workflows.
So I would say it depends on what we look for.
For now I would opt for git-wip, but I see Justin's point and if more
people want to go that way I can see the benefits.

My 2 cents,
Tommaso

Il giorno mer 20 set 2017 alle ore 18:06 Justin Edelson <
jus...@justinedelson.com> ha scritto:

> Hi,
> While it is true that this project does not have an existing Github-centric
> workflow, I suspect that most of us use such a workflow on other projects,
> so I would be more in favor of the dual-master system.
>
> Regards,
> Justin
>
> On Wed, Sep 20, 2017 at 11:48 AM Robert Munteanu 
> wrote:
>
> > Hi,
> >
> > According to http://git.apache.org/ , there are two systems in use at
> > the ASF:
> >
> > - the "Git Wip" system
> > - the "Github Dual Master"
> >
> > I have not found any more information about these - Ian referenced the
> > dual master some time ago [1], but AFAICT the "Wip" system is basically
> > ASF hosted git mirrored to Github, while the "Dual Master" system
> > allows us to push to Github as well as to the ASF Git.
> >
> > IMO the dual master system is for projects with a Github-centric
> > workflow coming to the ASF, which is not our situation at all, so I'd
> > go with the "Wip" system.
> >
> > What do others think?
> >
> > Thanks,
> >
> > Robert
> >
> >
> > [1]: https://lists.apache.org/thread.html/b8b0003cf9fcb1c365a9ed354fe7c
> > 20c2c4c5b465c952829e0eb4c78@1458668880@%3Cdev.sling.apache.org%3E
> >
>

Re: [VOTE] Release Apache Sling Thread Support 3.2.8, Apache Sling Scripting Core implementation 2.0.48, Apache Event Support 4.2.8, Apache Sling SlingStart Maven Plugin 1.7.10, Apache Sling JUnit Tes

[Daniel Klco]

+1

On Wed, Sep 20, 2017 at 8:57 AM, Robert Munteanu  wrote:

> On Wed, 2017-09-20 at 15:56 +0300, Robert Munteanu wrote:
> > Please vote to approve this release:
>
> +1
>
> Robert

Re: [git] Which git system do we want to use?

[Justin Edelson]

Hi,
While it is true that this project does not have an existing Github-centric
workflow, I suspect that most of us use such a workflow on other projects,
so I would be more in favor of the dual-master system.

Regards,
Justin

On Wed, Sep 20, 2017 at 11:48 AM Robert Munteanu  wrote:

> Hi,
>
> According to http://git.apache.org/ , there are two systems in use at
> the ASF:
>
> - the "Git Wip" system
> - the "Github Dual Master"
>
> I have not found any more information about these - Ian referenced the
> dual master some time ago [1], but AFAICT the "Wip" system is basically
> ASF hosted git mirrored to Github, while the "Dual Master" system
> allows us to push to Github as well as to the ASF Git.
>
> IMO the dual master system is for projects with a Github-centric
> workflow coming to the ASF, which is not our situation at all, so I'd
> go with the "Wip" system.
>
> What do others think?
>
> Thanks,
>
> Robert
>
>
> [1]: https://lists.apache.org/thread.html/b8b0003cf9fcb1c365a9ed354fe7c
> 20c2c4c5b465c952829e0eb4c78@1458668880@%3Cdev.sling.apache.org%3E
>

[git] Whiteboard migration

[Robert Munteanu]

Hi,

If we plan to migrate to git we'd need to migrate the whiteboard as
well, as the SVN repository will become read-only after the migration.

Given that we have a limited number of whiteboard entries, my
suggestion would be to create one git repo per individual whiteboard
folder _if_ someone thinks they should be moved. Otherwise we can leave
them in SVN and migrate them later if needed.

The interested committer can perform the migration directly using the
self-service tool at [1].

Thoughts?

Thanks,

Robert

[1]: http://reporeq.apache.org/

[git] Which git system do we want to use?

[Robert Munteanu]

Hi,

According to http://git.apache.org/ , there are two systems in use at
the ASF:

- the "Git Wip" system
- the "Github Dual Master"

I have not found any more information about these - Ian referenced the
dual master some time ago [1], but AFAICT the "Wip" system is basically
ASF hosted git mirrored to Github, while the "Dual Master" system
allows us to push to Github as well as to the ASF Git.

IMO the dual master system is for projects with a Github-centric
workflow coming to the ASF, which is not our situation at all, so I'd
go with the "Wip" system.

What do others think?

Thanks,

Robert


[1]: https://lists.apache.org/thread.html/b8b0003cf9fcb1c365a9ed354fe7c
20c2c4c5b465c952829e0eb4c78@1458668880@%3Cdev.sling.apache.org%3E

[git] Please test sample migrated git projects and repo setup

[Robert Munteanu]

Hi,

I did a dry run migration of two sling bundles:

  https://github.com/rombert/TMP-sling-org.apache.sling.api
  https://github.com/rombert/TMP-sling-org.apache.sling.jcr.repoinit

Please take a look and check if _anything_ is wrong. I think that I
have the process narrowed down more or less using the scripts at [1].

What I know is missing is move tracking. For some reason, the
jcr.repoinit module move is not captured and history starts after the
move from bundles/extensions. ( SVN [2], git [3] ). Any help with what
would be great.

Also I've created a small repo tool setup at 

  https://github.com/rombert/TMP-sling-manifest

The instructions are in the README, but you need to install repo

$ curl https://storage.googleapis.com/git-repo-downloads/repo >
~/bin/repo
$ chmod a+x ~/bin/repo

And then sync your local checkout

$ repo init -u https://github.com/rombert/TMP-sling-manifest.git
$ repo sync

Any feedback is welcome, please do look into the migrated repositories
or maybe propose some tougher migrations. If you are so inclined, the
scripts at tooling/scm/scripts [1] can also use a second pair of eyes
:-)

I'm going to leave this open for a week or so, but maybe after that we
can start migrating from SVN.

Thanks,

Robert


[1]: https://svn.apache.org/repos/asf/sling/trunk/tooling/scm/scripts/
[2]: http://svn.apache.org/viewvc?view=revision=1752162
[3]: https://github.com/apache/sling/commit/087f2d0504dc0b8c38fd298ab9c
29f896321f8c8

Re: [VOTE] Release Apache Sling Maven Sling Plugin 2.3.2

[Daniel Klco]

+1

On Wed, Sep 20, 2017 at 8:57 AM, Robert Munteanu  wrote:

> On Wed, 2017-09-20 at 10:59 +, Stefan Seifert wrote:
> > Please vote to approve this release:
>
> +1
>
> Robert

[jira] [Closed] (SLING-5026) Allow to set multiple validation error messages in one Validator

[Robert Munteanu (JIRA)]

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

Robert Munteanu closed SLING-5026.
--

> Allow to set multiple validation error messages in one Validator
> 
>
> Key: SLING-5026
> URL: https://issues.apache.org/jira/browse/SLING-5026
> Project: Sling
>  Issue Type: Improvement
>  Components: Validation
>Affects Versions: Validation 1.0.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: Validation 1.0.0
>
>
> Currently each {{Validator}} can only set one error message through the 
> String return value (SLING-4010). It should be possible for one 
> {{Validator.validate}} call to set multiple validation messages at once.
> Maybe the solution [~radu.cotescu] proposed in 
> https://issues.apache.org/jira/browse/SLING-4027?focusedCommentId=14219170=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14219170
>  can be used here to just pass the ValidationResult around.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (SLING-4419) [Regression] Sling Models cannot be used with Sightly Java Use-API

[Robert Munteanu (JIRA)]

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

Robert Munteanu closed SLING-4419.
--

> [Regression] Sling Models cannot be used with Sightly Java Use-API
> --
>
> Key: SLING-4419
> URL: https://issues.apache.org/jira/browse/SLING-4419
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Affects Versions: Scripting Sightly JS Use Provider 1.0.0, Scripting 
> Sightly Engine 1.0.0
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
> Fix For: Scripting Sightly Engine 1.0.0
>
>
> SLING-4206 introduced a regression: Sling Models cannot be correctly 
> instantiated for the Sightly Java Use-API as they're treated as regular POJOs 
> instead of allowing the models to be adapted with the {{ModelAdapterFactory}}.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (SLING-4606) Move validation from contrib to /

[Robert Munteanu (JIRA)]

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

Robert Munteanu closed SLING-4606.
--

> Move validation from contrib to /
> -
>
> Key: SLING-4606
> URL: https://issues.apache.org/jira/browse/SLING-4606
> Project: Sling
>  Issue Type: Improvement
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: Validation 1.0.0
>
>
> As agreed in SLING-4161 and 
> http://apache-sling.73963.n3.nabble.com/Models-depends-on-Validation-API-td4049634.html
>  Sling Validation should be moved out of contrib. Please also see the 
> implications of this in 
> https://cwiki.apache.org/confluence/display/SLING/Sling+SVN+repository+structure.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (SLING-4922) Validator should be allowed to get the resource on which validation was triggered

[Robert Munteanu (JIRA)]

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

Robert Munteanu closed SLING-4922.
--

> Validator should be allowed to get the resource on which validation was 
> triggered
> -
>
> Key: SLING-4922
> URL: https://issues.apache.org/jira/browse/SLING-4922
> Project: Sling
>  Issue Type: Bug
>  Components: Validation
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: Validation 1.0.0
>
>
> Currently the {{Validator}} interface only gets the {{ValueMap}} on which the 
> validation has been called 
> (https://github.com/apache/sling/blob/trunk/bundles/extensions/validation/api/src/main/java/org/apache/sling/validation/Validator.java#L75).
>  But sometimes this is not enough because more information need to be 
> evaluated in the validator.
> For example the resource path or even the original resource is now completely 
> inaccessible (except via weird workaround like casting to {{JcrPropertyMap}} 
> and calling the deprecated {{getPath()}} on it). Therefore the validator 
> should also get the resource on which the validation has been called 
> originally (this must be {{null}} in case the validation has been triggered 
> directly on a {{ValueMap}}). 
> That way it would be possible to e.g. get information about the container 
> resource or get a Sling Model of that resource.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (SLING-4388) Use sling mocks for the validation core tests

[Robert Munteanu (JIRA)]

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

Robert Munteanu closed SLING-4388.
--

> Use sling mocks for the validation core tests
> -
>
> Key: SLING-4388
> URL: https://issues.apache.org/jira/browse/SLING-4388
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions, Testing
>Reporter: Robert Munteanu
>Assignee: Konrad Windszus
> Fix For: Validation 1.0.0
>
>
> The org.apache.sling.validation.core bundle has its own utility mocks in 
> https://svn.apache.org/repos/asf/sling/trunk/contrib/extensions/validation/core/src/test/java/org/apache/sling/validation/impl/setup/
>  . All of these can be replaced by the new Sling mocks.
> The benefits would be:
> - less maintenance for the validation core project
> - more exposure/coverage for the Sling mocks



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (SLING-5446) DefaultSharedDistributionPackageBuilder should not be tight to the VLT builder

[Robert Munteanu (JIRA)]

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

Robert Munteanu closed SLING-5446.
--

> DefaultSharedDistributionPackageBuilder should not be tight to the VLT builder
> --
>
> Key: SLING-5446
> URL: https://issues.apache.org/jira/browse/SLING-5446
> Project: Sling
>  Issue Type: Improvement
>  Components: Content Distribution
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
> Fix For: Content Distribution Core 0.1.14
>
>
> {{DefaultSharedDistributionPackageBuilder}} is used for fetching 
> {{SharedDistributionPackages}} only in the 
> {{VaultDistributionPackageBuilderFactory}} while it'd be good to make this 
> used by default by all the {{DistributionPackageBuilders}} (e.g. the Kryo and 
> Avro ones in _extensions_) without having to manually instantiate it (and 
> thus expose the API).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (SLING-6581) Use Trie from Commons Collections

[Robert Munteanu (JIRA)]

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

Robert Munteanu closed SLING-6581.
--

> Use Trie from Commons Collections
> -
>
> Key: SLING-6581
> URL: https://issues.apache.org/jira/browse/SLING-6581
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions, Validation
>Reporter: Oliver Lietz
>Assignee: Konrad Windszus
> Fix For: Validation 1.0.0
>
>
> replace Trie by implementation from Commons Collections



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (SLING-4310) Deactivating Sling Validators will not remove them from the cache in ValidationServiceImpl

[Robert Munteanu (JIRA)]

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

Robert Munteanu closed SLING-4310.
--

> Deactivating Sling Validators will not remove them from the cache in 
> ValidationServiceImpl
> --
>
> Key: SLING-4310
> URL: https://issues.apache.org/jira/browse/SLING-4310
> Project: Sling
>  Issue Type: Bug
>  Components: Validation
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: Validation 1.0.0
>
>
> Currently the validationModelsCache will not be invalidated if Validators are 
> unbound from the {{ValidationServiceImpl}}. That leads to references to 
> inactive validators in the validationModelsCache. Therefore the validate 
> method might be called on inactive validators.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (SLING-5630) Update distribution ITs to use latest vault release

[Robert Munteanu (JIRA)]

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

Robert Munteanu closed SLING-5630.
--

> Update distribution ITs to use latest vault release 
> 
>
> Key: SLING-5630
> URL: https://issues.apache.org/jira/browse/SLING-5630
> Project: Sling
>  Issue Type: Test
>  Components: Content Distribution
>Reporter: Marius Petria
>Assignee: Marius Petria
> Fix For: Content Distribution Core 0.1.18
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (SLING-4609) Add JSR305 nullness annotations to Validation API

[Robert Munteanu (JIRA)]

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

Robert Munteanu closed SLING-4609.
--

> Add JSR305 nullness annotations to Validation API
> -
>
> Key: SLING-4609
> URL: https://issues.apache.org/jira/browse/SLING-4609
> Project: Sling
>  Issue Type: Improvement
>  Components: Validation
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: Validation 1.0.0
>
>
> Add JSR 305 annotations to the Validation API bundle, similar to what was 
> done in SLING-4377 for the Sling API bundle.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (SLING-6610) DefaultValidationFailure and DefaultValidationResult should use ValidationContext as parameter

[Robert Munteanu (JIRA)]

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

Robert Munteanu closed SLING-6610.
--

> DefaultValidationFailure and DefaultValidationResult should use 
> ValidationContext as parameter
> --
>
> Key: SLING-6610
> URL: https://issues.apache.org/jira/browse/SLING-6610
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions, Validation
>Reporter: Oliver Lietz
>Assignee: Konrad Windszus
> Fix For: Validation 1.0.0
>
>
> {{ValidationContext}}:
> {noformat}
> public DefaultValidationFailure(@Nonnull ValidationContext validationContext, 
> @Nonnull String messageKey, Object... messageArguments)
> {noformat}
> instead of {{location}}, {{severity}} and {{ResourceBundle}} from 
> {{ValidationContext}}:
> {noformat}
> public DefaultValidationFailure(@Nonnull String location, Integer severity, 
> @Nonnull ResourceBundle defaultResourceBundle, @Nonnull String messageKey, 
> Object... messageArguments)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (SLING-4876) Support resource type inheritance for validator models

[Robert Munteanu (JIRA)]

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

Robert Munteanu closed SLING-4876.
--

> Support resource type inheritance for validator models
> --
>
> Key: SLING-4876
> URL: https://issues.apache.org/jira/browse/SLING-4876
> Project: Sling
>  Issue Type: Improvement
>  Components: Validation
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: Validation 1.0.0
>
>
> Currently there must be a direct match of the resource type given in the 
> validation model and the resource type of the content resource. 
> But resource type inheritance should also be taken into account, so the 
> validation model of the given resource type and the one for the super 
> resource types should all be taken into account and the results should be 
> merged!



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (SLING-4381) Sling NoSQL Resource Provider for Couchbase

[Robert Munteanu (JIRA)]

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

Robert Munteanu closed SLING-4381.
--

> Sling NoSQL Resource Provider for Couchbase
> ---
>
> Key: SLING-4381
> URL: https://issues.apache.org/jira/browse/SLING-4381
> Project: Sling
>  Issue Type: New Feature
>  Components: NoSQL
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>Priority: Minor
> Fix For: NoSQL Generic Resource Provider 1.0.0, NoSQL Couchbase 
> Client 1.0.0, NoSQL Couchbase Resource Provider 1.0.0
>
> Attachments: SLING-4381_Preserve_order_of_changed_resources_.patch
>
>
> we want to create a lightweight sling resource provider for using 
> [Couchbase|http://www.couchbase.com/] as storage backend without the need to 
> have an underlying JCR or Oak infrastructure. this is a similar approach like 
> the [MongoDB resource 
> provider|https://svn.apache.org/repos/asf/sling/trunk/contrib/extensions/mongodb].
> as [discussed in the mailing 
> list|http://apache-sling.73963.n3.nabble.com/RT-Sling-Resource-Providers-for-NoSQL-databases-MongoDB-Couchbase-tt4046669.html]
>  it would make sense to create a generic shared codebase for nosql resource 
> providers. this shared module could be used for other NoSQL databases as well.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (SLING-5300) Set defaults for distribution components target references

[Robert Munteanu (JIRA)]

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

Robert Munteanu closed SLING-5300.
--

> Set defaults for distribution components target references
> --
>
> Key: SLING-5300
> URL: https://issues.apache.org/jira/browse/SLING-5300
> Project: Sling
>  Issue Type: Improvement
>  Components: Content Distribution
>Reporter: Marius Petria
>Assignee: Marius Petria
> Fix For: Content Distribution Core 0.1.12
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (SLING-4013) Allow validator model to refer to non-required properties and child resources

[Robert Munteanu (JIRA)]

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

Robert Munteanu closed SLING-4013.
--

> Allow validator model to refer to non-required properties and child resources
> -
>
> Key: SLING-4013
> URL: https://issues.apache.org/jira/browse/SLING-4013
> Project: Sling
>  Issue Type: Improvement
>  Components: Validation
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>  Labels: validation
> Fix For: Validation 1.0.0
>
>
> Currently all properties which are bound to a validator are automatically 
> mandatory 
> (https://github.com/apache/sling/blob/trunk/contrib/validation/core/src/main/java/org/apache/sling/validation/impl/ValidationServiceImpl.java#L384),
>  i.e. if the property is not set a validation error will occur. 
> In some cases the property is not required but if it is there it should be 
> valid according to the validator. 
> I propose a new attribute {{optional}} with a boolean value below the 
> properties resource or child resource of a validation model resource. The 
> default should be false (i.e. property/child resource is required).
> In case of {{nameRegex}} (SLING-4011) the requirement is fulfilled, if at 
> least one property/child resource name is matching the pattern.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (SLING-6578) Use "validator.id" property instead of class name to reference validators

[Robert Munteanu (JIRA)]

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

Robert Munteanu closed SLING-6578.
--

> Use "validator.id" property instead of class name to reference validators
> -
>
> Key: SLING-6578
> URL: https://issues.apache.org/jira/browse/SLING-6578
> Project: Sling
>  Issue Type: Improvement
>  Components: Validation
>Affects Versions: Validation 1.0.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: Validation 1.0.0
>
> Attachments: SLING-6578-v01.patch
>
>
> Leveraging the component's "validator.id" property value instead of its 
> classname is more stable (even if implementation changes, the PID might stay 
> the same) and also allows for configuration factories to refer to a specific 
> validator configuration. Using a predefined property like "service.pid" or 
> "component.name" is not possible/recommended, as those are used for other 
> purposes and are not necessarily there under all circumstances.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (SLING-4011) Allow ValidationModel nodes in the JCR contain wildcards below children and properties

[Robert Munteanu (JIRA)]

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

Robert Munteanu closed SLING-4011.
--

> Allow ValidationModel nodes in the JCR contain wildcards below children and 
> properties 
> ---
>
> Key: SLING-4011
> URL: https://issues.apache.org/jira/browse/SLING-4011
> Project: Sling
>  Issue Type: Improvement
>  Components: Validation
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>  Labels: validator
> Fix For: Validation 1.0.0
>
>
> According to 
> https://github.com/apache/sling/blob/trunk/contrib/validation/README.md the 
> nodes in the JCR specifying a validation model must always give an explicit 
> property name or child node name. This is sometimes not possible if the 
> subnodes/properties are generated automatically. Therefore it would be great 
> if the elements directly below {{children}} and {{properties}} would allow 
> wildcards.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (SLING-5660) Validation is using outdated sling/validation/model

[Robert Munteanu (JIRA)]

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

Robert Munteanu closed SLING-5660.
--

> Validation is using outdated sling/validation/model
> ---
>
> Key: SLING-5660
> URL: https://issues.apache.org/jira/browse/SLING-5660
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Reporter: Oliver Lietz
>Assignee: Konrad Windszus
> Fix For: Validation 1.0.0
>
>
> The new {{sling/validation/model}} (one property removed) was used only after 
> restarting Validation bundles: 
> {{sling.validator.missing-required-property-with-name}}, {{location}} was 
> empty.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (SLING-4194) Validator should take ValueMap instead of regular Map as type for the validator arguments

[Robert Munteanu (JIRA)]

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

Robert Munteanu closed SLING-4194.
--

> Validator should take ValueMap instead of regular Map as type for the 
> validator arguments
> -
>
> Key: SLING-4194
> URL: https://issues.apache.org/jira/browse/SLING-4194
> Project: Sling
>  Issue Type: Improvement
>  Components: Validation
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: Validation 1.0.0
>
>
> That way it is easily possible to convert the argument values to the 
> appropriate type.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (SLING-4159) Always close ResourceResolver in ValidationServiceImpl.searchAndStoreValidationModel

[Robert Munteanu (JIRA)]

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

Robert Munteanu closed SLING-4159.
--

> Always close ResourceResolver in 
> ValidationServiceImpl.searchAndStoreValidationModel
> 
>
> Key: SLING-4159
> URL: https://issues.apache.org/jira/browse/SLING-4159
> Project: Sling
>  Issue Type: Bug
>  Components: Validation
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Minor
> Fix For: Validation 1.0.0
>
>
> Currently the resource resolver being opened in 
> {{ValidationServiceImpl.searchAndStoreValidationModel}} is only closed if no 
> RuntimeException is thrown. Generally resource resolvers should always be 
> closed within a {{finally}} block.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (SLING-5432) Implement binaryless distribution

[Robert Munteanu (JIRA)]

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

Robert Munteanu closed SLING-5432.
--

> Implement binaryless distribution
> -
>
> Key: SLING-5432
> URL: https://issues.apache.org/jira/browse/SLING-5432
> Project: Sling
>  Issue Type: Improvement
>  Components: Content Distribution
>Reporter: Marius Petria
>Assignee: Marius Petria
> Fix For: Content Distribution Core 0.1.14
>
> Attachments: 0001-GRANITE-3581-Binary-less-distribution.patch
>
>
> We should allow configuration of vault package builders not to include 
> binaries using JCRVLT-97



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (SLING-5150) Allow configuration of selective queues for forward and queue agents.

[Robert Munteanu (JIRA)]

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

Robert Munteanu closed SLING-5150.
--

> Allow configuration of selective queues for forward and queue agents.
> -
>
> Key: SLING-5150
> URL: https://issues.apache.org/jira/browse/SLING-5150
> Project: Sling
>  Issue Type: Improvement
>  Components: Content Distribution
>Reporter: Marius Petria
>Assignee: Marius Petria
> Fix For: Content Distribution Core 0.1.10
>
>
> Content on specific paths should be delivered with dedicated queues.
> One currently can define the delivery queues as follows:
> packageImporter.endpoints : ["publisher1=http://...;, "publisher2=http://...;]
> That will create two queues (publisher1, publisher2) that are used to deliver 
> to the specified uris.
> We can extend these queues with dedicated queues using the selectiveQueues 
> property.
> selectiveQueues : ["news|publish.*=/content/news.*"]
> That means extend all matching queues (by regexp publish.*) with prefix 
> "news" for matching content (under /content/news). That will produce to new 
> queues (news-publisher1 and news-publisher2) that will be used whenever news 
> content is delivered. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (SLING-5400) Cannot checkout GIT Repo on Windows 7

[Robert Munteanu (JIRA)]

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

Robert Munteanu closed SLING-5400.
--

> Cannot checkout GIT Repo on Windows 7
> -
>
> Key: SLING-5400
> URL: https://issues.apache.org/jira/browse/SLING-5400
> Project: Sling
>  Issue Type: Bug
>  Components: Content Distribution
> Environment: Windows 7, JDK 1.7, Git 2.4.6
>Reporter: Andreas Schaefer
>Assignee: Marius Petria
>  Labels: Git, Windows
> Fix For: Content Distribution Core 0.1.14
>
>
> When I tried to checkout the latest Sling GIT Repo I ran into an issue where 
> Git reports a file too long issue. That file is created, though, but 
> subsequent interactions with Git fail as the file is marked as deleted but 
> cannot be handled.
> The file is:
> contrib/extensions/distribution/sample/src/main/resources/SLING-
> CONTENT/libs/sling/distribution/install.author/impersonate-publish-
> reverse/org.apache.sling.distribution.trigger.impl.ScheduledDistribut
> ionTriggerFactory-impersonate-publish-reverse-scheduled.json
> The rest seems to checkout fine and I was able to build.
> There is also another file in 'install-publish' that deals with impersonate 
> reverse.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (SLING-4213) Support i18n on validation messages

[Robert Munteanu (JIRA)]

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

Robert Munteanu closed SLING-4213.
--

> Support i18n on validation messages
> ---
>
> Key: SLING-4213
> URL: https://issues.apache.org/jira/browse/SLING-4213
> Project: Sling
>  Issue Type: Improvement
>  Components: Validation
>Affects Versions: Validation 1.0.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: Validation 1.0.0
>
>
> Currently validation messages must be internationalized outside of the Sling 
> Validation Bundle. The Sling i18n requires the SlingHttpServletRequest to get 
> the locale as well as the bundle 
> (http://sling.apache.org/site/internationalization-support.html). It would be 
> good if the validation bundle would support the Sling i18n out of the box.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (SLING-5674) Validation: IAE thrown in case validation is triggered on a NonExistingResource

[Robert Munteanu (JIRA)]

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

Robert Munteanu closed SLING-5674.
--

> Validation: IAE thrown in case validation is triggered on a 
> NonExistingResource
> ---
>
> Key: SLING-5674
> URL: https://issues.apache.org/jira/browse/SLING-5674
> Project: Sling
>  Issue Type: Bug
>  Components: Validation
>Affects Versions: Validation 1.0.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: Validation 1.0.0
>
>
> The stack trace whenever the validation is triggered on a 
> {{NonExistingResource}} looks like this
> {code}
> java.lang.IllegalArgumentException: ValueMap may not be null
>   at 
> org.apache.sling.validation.impl.ValidationServiceImpl.validateValueMap(ValidationServiceImpl.java:226)
>   at 
> org.apache.sling.validation.impl.ValidationServiceImpl.validate(ValidationServiceImpl.java:150)
>   at 
> org.apache.sling.validation.impl.ValidationServiceImpl.validate(ValidationServiceImpl.java:140)
>   at 
> ...
> {code}
> In case the validation model only contains optional validations this should 
> be silently ignored, in all other cases there must be a reasonable 
> {{ValidationFailure}} be returned instead of this exception.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (SLING-5395) Correctly set either ProviderType or ConsumerType on the interfaces of the validation api bundle

[Robert Munteanu (JIRA)]

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

Robert Munteanu closed SLING-5395.
--

> Correctly set either ProviderType or ConsumerType on the interfaces of the 
> validation api bundle
> 
>
> Key: SLING-5395
> URL: https://issues.apache.org/jira/browse/SLING-5395
> Project: Sling
>  Issue Type: Bug
>  Components: Validation
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: Validation 1.0.0
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (SLING-4160) Log error in case invalid validator has been specified in the validation model

[Robert Munteanu (JIRA)]

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

Robert Munteanu closed SLING-4160.
--

> Log error in case invalid validator has been specified in the validation model
> --
>
> Key: SLING-4160
> URL: https://issues.apache.org/jira/browse/SLING-4160
> Project: Sling
>  Issue Type: Bug
>  Components: Validation
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: Validation 1.0.0
>
>
> In case an invalid validator name has been specified an error should be 
> logged. Currently just an NPE is thrown
> {code}
> Caused by: java.lang.NullPointerException: null
>   at 
> org.apache.sling.validation.impl.ValidationServiceImpl.validatePropertyValue(ValidationServiceImpl.java:388)
>   at 
> org.apache.sling.validation.impl.ValidationServiceImpl.validateResourceProperties(ValidationServiceImpl.java:251)
>   at 
> org.apache.sling.validation.impl.ValidationServiceImpl.validate(ValidationServiceImpl.java:116)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (SLING-5633) Importing users fails with OakConstraint0022: Authorizable property rep:principalName may not be altered after user/group creation

[Robert Munteanu (JIRA)]

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

Robert Munteanu closed SLING-5633.
--

> Importing users fails with OakConstraint0022: Authorizable property 
> rep:principalName may not be altered after user/group creation
> --
>
> Key: SLING-5633
> URL: https://issues.apache.org/jira/browse/SLING-5633
> Project: Sling
>  Issue Type: Bug
>  Components: Content Distribution
>Affects Versions: Content Distribution Core 0.1.8
>Reporter: Marius Petria
>Assignee: Marius Petria
> Fix For: Content Distribution Core 0.1.18
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (SLING-6569) NPE in DefaultValidationFailure when resource bundle is null

[Robert Munteanu (JIRA)]

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

Robert Munteanu closed SLING-6569.
--

> NPE in DefaultValidationFailure when resource bundle is null
> 
>
> Key: SLING-6569
> URL: https://issues.apache.org/jira/browse/SLING-6569
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions, Validation
>Reporter: Oliver Lietz
>Assignee: Konrad Windszus
> Fix For: Validation 1.0.0
>
>
> Before:
> {noformat}
> [...]
> 2017-03-02 15:39:42,933 ERROR [127.0.0.1 [1488465582809] POST 
> /validation/testing/fakeFolder1/resource HTTP/1.1] 
> o.a.s.e.i.SlingRequestProcessorImpl [SlingRequestProcessorImpl.java : 225] 
> service: Uncaught Throwable
> java.lang.NullPointerException: null
>   at 
> org.apache.sling.validation.spi.DefaultValidationFailure.getMessage(DefaultValidationFailure.java:64)
>   at 
> org.apache.sling.validation.testservices.internal.ValidationPostResponse.doSend(ValidationPostResponse.java:63)
>   at 
> org.apache.sling.servlets.post.AbstractPostResponse.send(AbstractPostResponse.java:387)
>   at 
> org.apache.sling.servlets.post.impl.SlingPostServlet.doPost(SlingPostServlet.java:226)
> [...]
> {noformat}
> After:
> {noformat}
> [...]
> 2017-03-02 15:46:33,866 ERROR [127.0.0.1 [1488465993738] POST 
> /validation/testing/fakeFolder1/resource HTTP/1.1] 
> o.a.s.e.i.SlingRequestProcessorImpl [SlingRequestProcessorImpl.java : 225] 
> service: Uncaught Throwable
> java.lang.NullPointerException: ResourceBundle must not be null
>   at 
> org.apache.sling.validation.spi.DefaultValidationFailure.getMessage(DefaultValidationFailure.java:65)
>   at 
> org.apache.sling.validation.testservices.internal.ValidationPostResponse.doSend(ValidationPostResponse.java:63)
>   at 
> org.apache.sling.servlets.post.AbstractPostResponse.send(AbstractPostResponse.java:387)
>   at 
> org.apache.sling.servlets.post.impl.SlingPostServlet.doPost(SlingPostServlet.java:226)
> [...]
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (SLING-5399) Clear info logging for distribution

[Robert Munteanu (JIRA)]

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

Robert Munteanu closed SLING-5399.
--

> Clear info logging for distribution
> ---
>
> Key: SLING-5399
> URL: https://issues.apache.org/jira/browse/SLING-5399
> Project: Sling
>  Issue Type: Improvement
>  Components: Content Distribution
>Reporter: Marius Petria
>Assignee: Marius Petria
> Fix For: Content Distribution Core 0.1.14
>
>
> Improve info logging for distribution.
> Agent should log on info level:
> EXECUTE requestDetails noOfPackages exportTime noOfQueues enqueueTime
> DELIVER queueName packageDetails importTime
> Standalone exporter should log
> EXPORT requestDetails exportTime
> Standalone importer should log
> IMPORT packageDetail importTime



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (SLING-5749) Validation: IAE thrown in case validation is triggered on a SyntheticResource

[Robert Munteanu (JIRA)]

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

Robert Munteanu closed SLING-5749.
--

> Validation: IAE thrown in case validation is triggered on a SyntheticResource
> -
>
> Key: SLING-5749
> URL: https://issues.apache.org/jira/browse/SLING-5749
> Project: Sling
>  Issue Type: Bug
>  Components: Validation
>Affects Versions: Validation 1.0.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: Validation 1.0.0
>
>
> The stack trace whenever the validation is triggered on a 
> {{SyntheticResource}} looks like this
> {code}
> java.lang.IllegalArgumentException: ValueMap may not be null
>   at 
> org.apache.sling.validation.impl.ValidationServiceImpl.validateValueMap(ValidationServiceImpl.java:226)
>   at 
> org.apache.sling.validation.impl.ValidationServiceImpl.validate(ValidationServiceImpl.java:150)
>   at 
> org.apache.sling.validation.impl.ValidationServiceImpl.validate(ValidationServiceImpl.java:140)
>   at 
> ...
> {code}
> In case the validation model only contains optional validations this should 
> be silently ignored, in all other cases there must be a reasonable 
> {{ValidationFailure}} be returned instead of this exception.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (SLING-5397) Use priorityQueues instead of selectiveQueues

[Robert Munteanu (JIRA)]

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

Robert Munteanu closed SLING-5397.
--

> Use priorityQueues instead of selectiveQueues
> -
>
> Key: SLING-5397
> URL: https://issues.apache.org/jira/browse/SLING-5397
> Project: Sling
>  Issue Type: Improvement
>  Components: Content Distribution
>Affects Versions: Content Distribution Core 0.1.10
>Reporter: Marius Petria
>Assignee: Marius Petria
> Fix For: Content Distribution Core 0.1.14
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[Robert Munteanu (JIRA)]

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

Robert Munteanu closed SLING-4010.
--

> Allow validator to set a custom failure message
> ---
>
> Key: SLING-4010
> URL: https://issues.apache.org/jira/browse/SLING-4010
> Project: Sling
>  Issue Type: Improvement
>  Components: Validation
>Reporter: Konrad Windszus
>Assignee: Bertrand Delacretaz
>  Labels: validation, validator
> Fix For: Validation 1.0.0
>
>
> Currently the Validator may only return a boolean value or an exception in 
> case the validator was called with invalid parametrization 
> (https://github.com/apache/sling/blob/trunk/contrib/validation/api/src/main/java/org/apache/sling/validation/api/Validator.java).
> In some cases the validator could give some important information about why 
> the validation failed. This is e.g. the cause for a reference validator where 
> the cause for a failed validation could be:
> # referenced resource is not existent
> # referenced resource is not having the right resource type
> # referenced resource is not activated
> So instead of only returning a boolean value, it should also be possible to 
> return a failure message.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (SLING-4822) Allow to skip validation of sub resources based on arbitrary predicates

[Robert Munteanu (JIRA)]

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

Robert Munteanu closed SLING-4822.
--

> Allow to skip validation of sub resources based on arbitrary predicates
> ---
>
> Key: SLING-4822
> URL: https://issues.apache.org/jira/browse/SLING-4822
> Project: Sling
>  Issue Type: Bug
>  Components: Validation
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: Validation 1.0.0
>
>
> Sometimes it is useful to skip some resources in 
> {{ValidationService.validateAllResourceTypesInResource}} not only depending 
> on the actual resource type but based on some other condition. To keep things 
> simple I would suggest to replace the {{ignoredResourceTypes}} parameter with 
> just a {{org.apache.commons.collection.Predicate}} parameter which acts as 
> filter.
> Only resources which fulfill the given predicate are validated.
> Then either filtering based on a resource type or based on any other property 
> of the resource could be easily done.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (SLING-5183) Use a single DistributionException across distribution API

[Robert Munteanu (JIRA)]

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

Robert Munteanu closed SLING-5183.
--

> Use a single DistributionException across distribution API
> --
>
> Key: SLING-5183
> URL: https://issues.apache.org/jira/browse/SLING-5183
> Project: Sling
>  Issue Type: Improvement
>  Components: Content Distribution
>Reporter: Marius Petria
>Assignee: Marius Petria
> Fix For: Content Distribution Core 0.1.10
>
>
> Use a single DistributionException across distribution API



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (SLING-5440) DistributionAgentJobConsumer should only fetch the entry

[Robert Munteanu (JIRA)]

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

Robert Munteanu closed SLING-5440.
--

> DistributionAgentJobConsumer should only fetch the entry
> 
>
> Key: SLING-5440
> URL: https://issues.apache.org/jira/browse/SLING-5440
> Project: Sling
>  Issue Type: Improvement
>  Components: Content Distribution
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
>Priority: Trivial
> Fix For: Content Distribution Core 0.1.14
>
>
> {{DistributionAgentJobConsumer}} fetches both {{DistributionQueueEntry}} and 
> the name of the queue to process from the Sling {{Job}} while only getting 
> the first one is enough as it contains information about the 
> {{DistributionQueueItemStatus}} which also contains the queue name.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (SLING-5373) Allow different severities per validator

[Robert Munteanu (JIRA)]

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

Robert Munteanu closed SLING-5373.
--

> Allow different severities per validator
> 
>
> Key: SLING-5373
> URL: https://issues.apache.org/jira/browse/SLING-5373
> Project: Sling
>  Issue Type: Bug
>  Components: Validation
>Reporter: Konrad Windszus
> Fix For: Validation 1.0.0
>
>
> It would be good to be able to define a severity either on the validator 
> itself or within the validation model. That would allow to later on 
> differentiate the handling on how to treat those violations. 
> Depending on the violation severity one could decide to either throw an 
> exception or just expose the violation failure message for informational 
> purposes.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (SLING-6725) Building validation core fails with test errors

[Robert Munteanu (JIRA)]

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

Robert Munteanu closed SLING-6725.
--

> Building validation core fails with test errors
> ---
>
> Key: SLING-6725
> URL: https://issues.apache.org/jira/browse/SLING-6725
> Project: Sling
>  Issue Type: Bug
>  Components: Validation
>Reporter: Karl Pauls
>Assignee: Oliver Lietz
> Fix For: Validation 1.0.0
>
>
> Doing:
> cd bundles/extensions/validation/core 
> mvn clean install
> fails with test errors.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (SLING-4777) Decouple the model provider from the actual validation service

[Robert Munteanu (JIRA)]

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

Robert Munteanu closed SLING-4777.
--

> Decouple the model provider from the actual validation service
> --
>
> Key: SLING-4777
> URL: https://issues.apache.org/jira/browse/SLING-4777
> Project: Sling
>  Issue Type: Improvement
>  Components: Validation
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: Validation 1.0.0
>
>
> As being mentioned in SLING-4027, it would be good to completely decouple the 
> model providing capabilities from the actual validation, as that would
> a) make the codebase cleaner (and would ease testing)
> b) allow to plug-in other services which provide models (e.g. based on 
> annotations on some files)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (SLING-5426) Expose size to distribution packages

[Robert Munteanu (JIRA)]

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

Robert Munteanu closed SLING-5426.
--

> Expose size to distribution packages
> 
>
> Key: SLING-5426
> URL: https://issues.apache.org/jira/browse/SLING-5426
> Project: Sling
>  Issue Type: Improvement
>  Components: Content Distribution
>Reporter: Marius Petria
>Assignee: Marius Petria
> Fix For: Content Distribution Core 0.1.14
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (SLING-3553) Run FindBugs (and fix accordingly) on Sling Replication code

[Robert Munteanu (JIRA)]

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

Robert Munteanu closed SLING-3553.
--

> Run FindBugs (and fix accordingly) on Sling Replication code
> 
>
> Key: SLING-3553
> URL: https://issues.apache.org/jira/browse/SLING-3553
> Project: Sling
>  Issue Type: Improvement
>  Components: Content Distribution
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
>Priority: Trivial
> Fix For: Content Distribution Core 0.1.14
>
>
> Sling Replication code has grown over time and I'd like to a) fix current 
> problems as reported by FindBugs b) add a reporting entry to the pom.xml in 
> order to be continuously able to check eventual problems.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (SLING-5576) Optimize queue items listing for big number of items by using iterators

[Robert Munteanu (JIRA)]

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

Robert Munteanu closed SLING-5576.
--

> Optimize queue items listing for big number of items by using iterators
> ---
>
> Key: SLING-5576
> URL: https://issues.apache.org/jira/browse/SLING-5576
> Project: Sling
>  Issue Type: Improvement
>  Components: Content Distribution
>Reporter: Marius Petria
>Assignee: Marius Petria
> Fix For: Content Distribution Core 0.1.18
>
>
> We should an iterator when retrieving queue items as it can happen to have 
> tens of thousands of items in the queue.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (SLING-4608) Can not extract validator type from arrays of classes in Java6

[Robert Munteanu (JIRA)]

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

Robert Munteanu closed SLING-4608.
--

> Can not extract validator type from arrays of classes in Java6
> --
>
> Key: SLING-4608
> URL: https://issues.apache.org/jira/browse/SLING-4608
> Project: Sling
>  Issue Type: Bug
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: Validation 1.0.0
>
>
> Due to http://bugs.java.com/view_bug.do?bug_id=5041784, the type extraction 
> from a validator for any array classes does not work in Java < 7.
> This leads to the following failure in the test:
> {code}
> ValidatorTypeUtilTest
> org.apache.sling.validation.impl.util.ValidatorTypeUtilTest
> testGetValidatorTypeWithArrayType(org.apache.sling.validation.impl.util.ValidatorTypeUtilTest)
> java.lang.IllegalArgumentException: Validators may not use parameterized 
> types as type parameter. Only simple class types and arrays of class types 
> are allowed.
>   at 
> org.apache.sling.validation.impl.util.ValidatorTypeUtil.getValidatorType(ValidatorTypeUtil.java:50)
>   at 
> org.apache.sling.validation.impl.util.ValidatorTypeUtilTest.testGetValidatorTypeWithArrayType(ValidatorTypeUtilTest.java:91)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>   at java.lang.reflect.Method.invoke(Method.java:597)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
>   at 
> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
>   at 
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>   at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
>   at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675)
>   at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
>   at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (SLING-5577) Distribution package implementation should be independent of serialization

[Robert Munteanu (JIRA)]

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

Robert Munteanu closed SLING-5577.
--

> Distribution package implementation should be independent of serialization
> --
>
> Key: SLING-5577
> URL: https://issues.apache.org/jira/browse/SLING-5577
> Project: Sling
>  Issue Type: Improvement
>  Components: Content Distribution
>Reporter: Tommaso Teofili
>Assignee: Marius Petria
> Fix For: Content Distribution Core 0.1.18
>
> Attachments: SLING-5577.0.patch, SLING-5577.1.patch, 
> SLING-5577.2.patch
>
>
> Currently we have different implementations of {{DistributionPackage}} 
> interface in _org.apache.sling.distribution.core_ and 
> _org.apache.sling.distribution.extensions_, some are based on plain files, 
> some on FileVault packages (backed by files or JCR content) however it'd be 
> good that packages would be agnostic to serialization type, simply based on 
> {{Resources}}.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (SLING-5657) Distribution packages persisted in files should also have their refs in files

[Robert Munteanu (JIRA)]

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

Robert Munteanu closed SLING-5657.
--

> Distribution packages persisted in files should also have their refs in files
> -
>
> Key: SLING-5657
> URL: https://issues.apache.org/jira/browse/SLING-5657
> Project: Sling
>  Issue Type: Improvement
>  Components: Content Distribution
>Reporter: Marius Petria
> Fix For: Content Distribution Core 0.1.18
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (SLING-5367) Allow specification of include/exclude patterns at request level

[Robert Munteanu (JIRA)]

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

Robert Munteanu closed SLING-5367.
--

> Allow specification of include/exclude patterns at request level
> 
>
> Key: SLING-5367
> URL: https://issues.apache.org/jira/browse/SLING-5367
> Project: Sling
>  Issue Type: Improvement
>  Components: Content Distribution
>Reporter: Marius Petria
>Assignee: Marius Petria
> Fix For: Content Distribution Core 0.1.12
>
>
> We should allow filters to be specified at request level
> {noformat}
>  * | Pattern| Matches
>  * | /foo   | exactly "/foo"
>  * | /foo.* | all paths starting with "/foo"
>  * | ^.* /foo[^/]*$ | all files starting with "foo"
>  * | /foo/[^/]*$| all direct children of /foo
>  * | /foo/.*| all children of /foo
>  * | /foo(/.*)? | all children of /foo and foo itself
> {noformat}
> [1] 
> https://svn.apache.org/repos/asf/jackrabbit/commons/filevault/trunk/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/filter/DefaultPathFilter.java



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (SLING-5316) Expose user id in distribution queue resources

[Robert Munteanu (JIRA)]

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

Robert Munteanu closed SLING-5316.
--

> Expose user id in distribution queue resources
> --
>
> Key: SLING-5316
> URL: https://issues.apache.org/jira/browse/SLING-5316
> Project: Sling
>  Issue Type: Improvement
>  Components: Content Distribution
>Reporter: Marius Petria
>Assignee: Marius Petria
> Fix For: Content Distribution Core 0.1.12
>
>
> We should expose a property that contains the calling userid in queue 
> resources.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (SLING-5438) Avoid reopening the JcrPackage during installation

[Robert Munteanu (JIRA)]

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

Robert Munteanu closed SLING-5438.
--

> Avoid reopening the JcrPackage during installation
> --
>
> Key: SLING-5438
> URL: https://issues.apache.org/jira/browse/SLING-5438
> Project: Sling
>  Issue Type: Improvement
>  Components: Content Distribution
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
> Fix For: Content Distribution Core 0.1.14
>
>
> During {{JcrVaultDistributionPackageBuilder#installPackageInternal}} the 
> {{JcrPackage}} contained in the {{DistributionPackage}} is re opened using 
> its id. That is avoidable as the {{JcrPackage}} is already available inside 
> the {{DistributionPackage}}.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (SLING-4138) Allow validator to support arbitrary types

[Robert Munteanu (JIRA)]

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

Robert Munteanu closed SLING-4138.
--

> Allow validator to support arbitrary types
> --
>
> Key: SLING-4138
> URL: https://issues.apache.org/jira/browse/SLING-4138
> Project: Sling
>  Issue Type: Improvement
>  Components: Validation
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: Validation 1.0.0
>
>
> Currently the {{Validator.validate}} method only act on String values. 
> Since type conversion is already built into the ValueMap, it would be good to 
> leverage that and to allow Validator to act on arbitrary types there!
> Also the type conversion from ValueMap should be leveraged to do the type 
> check in {{ValidationServiceImpl.validatePropertyValue}} rather than 
> implementing a new thing in {{Type.isValid()}}.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (SLING-4027) Improvement of the validation API

[Robert Munteanu (JIRA)]

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

Robert Munteanu closed SLING-4027.
--

> Improvement of the validation API
> -
>
> Key: SLING-4027
> URL: https://issues.apache.org/jira/browse/SLING-4027
> Project: Sling
>  Issue Type: Improvement
>  Components: Validation
>Reporter: Carsten Ziegeler
>Assignee: Konrad Windszus
> Fix For: Validation 1.0.0
>
>
> Some comments / thoughts about the validation api:
> a) Why is there a validator lookup service? I don't think we need this in the 
> API - it's a simple OSGI service lookup.
> b) A Validator can only validate a single value - what if a property is an 
> array and the validation needs to validate based on all supplied values? Same 
> goes with dependencies between two properties?
> c) The Validator interface returns null on success and a String (message) if 
> validation fails. But it can also throw an exception if e.g. the provided 
> value is null. I think a null value should be treated the same as a wrong 
> value. Throwing the exception if some configuration like the regexp for the 
> regexp validator is missing, is fine. but all errors of validating a value 
> should be treated the same.
> d) NonExistingTypeException I don't think we need this - 
> IllegalArgumentException is fine to throw from the type enumeration
> e) Maybe we can also remove the SlingValidationException - it is only thrown 
> (see c) if a validator does not get its required configuration - which can be 
> seen as an IllegalStateException
> f) It would be nice to have a ValidationModelProvider interface - we will 
> then have the current way of defining models as the default implememtation. 
> But can allow other means of defining the validation model



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (SLING-4218) Throw exception for ValidationService.getValidationModel(...) if invalid validation model is found

[Robert Munteanu (JIRA)]

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

Robert Munteanu closed SLING-4218.
--

> Throw exception for ValidationService.getValidationModel(...) if invalid 
> validation model is found
> --
>
> Key: SLING-4218
> URL: https://issues.apache.org/jira/browse/SLING-4218
> Project: Sling
>  Issue Type: Bug
>  Components: Validation
>Affects Versions: Validation 1.0.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: Validation 1.0.0
>
>
> Currently {{ValidationService.getValidationModel(...)}} always returns null 
> either if there is no validation model found for the given resource type or 
> the one being found is invalid.
> To be able to distinguish those cases and also to ease fixing of invalid 
> validation models I propose that this method is allowed to throw 
> IllegalStateException's in case the matching validation model is invalid 
> (i.e. if it contains an invalid Validator or does not have at least 
> properties subnode or children subnode being set).
> That should of course be explicitly stated in the Javadoc.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (SLING-5281) Allow execution of distribution requests using calling user session

[Robert Munteanu (JIRA)]

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

Robert Munteanu closed SLING-5281.
--

> Allow execution of distribution requests using calling user session
> ---
>
> Key: SLING-5281
> URL: https://issues.apache.org/jira/browse/SLING-5281
> Project: Sling
>  Issue Type: Improvement
>  Components: Content Distribution
>Reporter: Marius Petria
>Assignee: Marius Petria
> Fix For: Content Distribution Core 0.1.10
>
>
> If for an agent the serviceName is not provided then it should execute with a 
> defaultAgentService that will impersonate the calling user session for async 
> operations. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (SLING-6562) Remove getAdministrativeResourceResolver from Sling Validation

[Robert Munteanu (JIRA)]

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

Robert Munteanu closed SLING-6562.
--

> Remove getAdministrativeResourceResolver from Sling Validation
> --
>
> Key: SLING-6562
> URL: https://issues.apache.org/jira/browse/SLING-6562
> Project: Sling
>  Issue Type: Improvement
>  Components: Validation
>Affects Versions: Validation 1.0.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: Validation 1.0.0
>
>
> 3 occurrences in
> # {{o.a.s.validation.impl.resourcemodel.ResourceValidationModelProviderImpl}},
> # {{o.a.s.validation.impl.ValidationModelRetrieverImpl}} (most probably the 
> latter should not deal with resource resolvers at all (compare with 
> http://www.mail-archive.com/dev@sling.apache.org/msg64770.html))
> # {{o.a.s.validation.impl.ValidationServiceImpl}} to retrieve the search 
> paths (for relativizing resource types)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (SLING-6663) ResourceToValidationResultAdapterFactory fails adapting to ValidationResult

[Robert Munteanu (JIRA)]

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

Robert Munteanu closed SLING-6663.
--

> ResourceToValidationResultAdapterFactory fails adapting to ValidationResult
> ---
>
> Key: SLING-6663
> URL: https://issues.apache.org/jira/browse/SLING-6663
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions, Validation
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
> Fix For: Validation 1.0.0
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (SLING-4157) Allow Sling validation to pick up models in any location in the repository

[Robert Munteanu (JIRA)]

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

Robert Munteanu closed SLING-4157.
--

> Allow Sling validation to pick up models in any location in the repository
> --
>
> Key: SLING-4157
> URL: https://issues.apache.org/jira/browse/SLING-4157
> Project: Sling
>  Issue Type: Improvement
>  Components: Validation
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>  Labels: patch
> Fix For: Validation 1.0.0
>
>
> Currently only validation models being defined below
> * /apps/sling/validation/models/ and
> * /libs/sling/validation/models/ 
> are picked up
> This is due to the XPath query containing the path restriction (in 
> https://github.com/apache/sling/blob/trunk/contrib/validation/core/src/main/java/org/apache/sling/validation/impl/ValidationServiceImpl.java#L295).
> Similar to the JCR Repository based ResourceBundleProvider ( 
> http://sling.apache.org/site/internationalization-support.html) the 
> validation models should be allowed  everywhere in the repository (where apps 
> should still have higher priority than libs). That should not have a major 
> performance drawback.
> This is especially useful, if multiple different applications are deployed on 
> the same Sling instance. To be able to distinguish their scripts and 
> validation models in the repository (and to not overwrite other applications' 
> models) it should be allowed that everything belonging to that one 
> application is located below one common entry node (e.g. 
> /apps/mycoolslingapp/)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (SLING-4955) NPE in ValidationModelRetrieverImpl

[Robert Munteanu (JIRA)]

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

Robert Munteanu closed SLING-4955.
--

> NPE in ValidationModelRetrieverImpl
> ---
>
> Key: SLING-4955
> URL: https://issues.apache.org/jira/browse/SLING-4955
> Project: Sling
>  Issue Type: Bug
>  Components: Validation
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: Validation 1.0.0
>
>
> Due to the changes introduced with SLING-4876 there has been a potential NPE 
> been introduced in the {{o.a.s.validation.impl.ValidationModelRetrieverImpl}}.
> The stack trace looks like this 
> {code}
> java.lang.NullPointerException: null
>   at 
> org.apache.sling.validation.impl.model.MergedValidationModel.(MergedValidationModel.java:60)
>   at 
> org.apache.sling.validation.impl.ValidationModelRetrieverImpl.getModel(ValidationModelRetrieverImpl.java:121)
>   at 
> org.apache.sling.validation.impl.ValidationModelRetrieverImpl.getModel(ValidationModelRetrieverImpl.java:94)
>   at 
> org.apache.sling.validation.impl.ValidationServiceImpl.getValidationModel(ValidationServiceImpl.java:93)
>   at 
> org.apache.sling.validation.impl.ValidationServiceImpl.getValidationModel(ValidationServiceImpl.java:125)
> ...
> {code}
> This happens whenever there is a model found for the requested resource type 
> but not for one of its super resource types.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (SLING-6588) More granularly invalidate the cached ValidationModels

[Robert Munteanu (JIRA)]

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

Robert Munteanu closed SLING-6588.
--

> More granularly invalidate the cached ValidationModels
> --
>
> Key: SLING-6588
> URL: https://issues.apache.org/jira/browse/SLING-6588
> Project: Sling
>  Issue Type: Improvement
>  Components: Validation
>Affects Versions: Validation 1.0.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: Validation 1.0.0
>
>
> Currently {{ValidationModelProviders}} are asked once for validation models 
> for a specific resource type. The result is cached, which may be invalidated 
> as a whole by the {{ValidationModelProvider}} as well. 
> While this works, it always requires a full cache invalidation whenever a new 
> model come into play. Consider the following use case:
> # Only one model for resource type {{a}} is available with {{applicablePath}} 
> = {{/content}}
> # The model is retrieved from the {{ValidationModelProvider}} for a 
> validation of a resource below {{/content/test/c}}
> # A new model for resource type {{a}} becomes available with 
> {{applicablePath}} = {{/content/test}}
> That new model should take precedence because its applicable path is more 
> specific. This would only work if between 2. and 3. the cache is fully 
> invalidated.
> The new model is actually never leveraged unless the full cache is 
> invalidated in between.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (SLING-5368) Update to Sling Event 4.0.0

[Robert Munteanu (JIRA)]

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

Robert Munteanu closed SLING-5368.
--

> Update to Sling Event 4.0.0
> ---
>
> Key: SLING-5368
> URL: https://issues.apache.org/jira/browse/SLING-5368
> Project: Sling
>  Issue Type: Improvement
>  Components: Content Distribution
>Reporter: Carsten Ziegeler
>Assignee: Marius Petria
> Fix For: Content Distribution Core 0.1.12
>
>
> The distribution should use the latest in Eventing and make sure that it's 
> not using any deprecated/removed functionality
> [~mpetria] Could you please update the dependency to Sling event 4.0.0?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (SLING-4262) Make ValidationService.getValidationModel accept also relative resource types

[Robert Munteanu (JIRA)]

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

Robert Munteanu closed SLING-4262.
--

> Make ValidationService.getValidationModel accept also relative resource types
> -
>
> Key: SLING-4262
> URL: https://issues.apache.org/jira/browse/SLING-4262
> Project: Sling
>  Issue Type: Improvement
>  Components: Validation
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: Validation 1.0.0
>
> Attachments: SLING-4262-v01.patch
>
>
> Currently there must be a direct match between the validation models resource 
> type given in validatedResourceType and the resourceType given as a parameter 
> to {{ValidationService.getValidationModel}}.
> It would be good if in both directions also the search path of the resource 
> resolver would be considered (if one of the given values does not start with 
> a "/")



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (SLING-5295) Use slingRepository.impersonateFromService to impersonate distribution user

[Robert Munteanu (JIRA)]

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

Robert Munteanu closed SLING-5295.
--

> Use slingRepository.impersonateFromService to impersonate distribution user
> ---
>
> Key: SLING-5295
> URL: https://issues.apache.org/jira/browse/SLING-5295
> Project: Sling
>  Issue Type: Bug
>  Components: Content Distribution
>Reporter: Marius Petria
>Assignee: Marius Petria
> Fix For: Content Distribution Core 0.1.12
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (SLING-5429) JcrPackageBuilder should not require access to root

[Robert Munteanu (JIRA)]

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

Robert Munteanu closed SLING-5429.
--

> JcrPackageBuilder should not require access to root
> ---
>
> Key: SLING-5429
> URL: https://issues.apache.org/jira/browse/SLING-5429
> Project: Sling
>  Issue Type: Improvement
>  Components: Content Distribution
>Reporter: Marius Petria
>Assignee: Marius Petria
> Fix For: Content Distribution Core 0.1.14
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (SLING-5336) Investigate concurrency issue for shared distribution packages

[Robert Munteanu (JIRA)]

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

Robert Munteanu closed SLING-5336.
--

> Investigate concurrency issue for shared distribution packages
> --
>
> Key: SLING-5336
> URL: https://issues.apache.org/jira/browse/SLING-5336
> Project: Sling
>  Issue Type: Bug
>  Components: Content Distribution
>Reporter: Marius Petria
>Assignee: Marius Petria
> Fix For: Content Distribution Core 0.1.12
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (SLING-5473) Improve parallelism of package acquire/release

[Robert Munteanu (JIRA)]

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

Robert Munteanu closed SLING-5473.
--

> Improve parallelism of package acquire/release
> --
>
> Key: SLING-5473
> URL: https://issues.apache.org/jira/browse/SLING-5473
> Project: Sling
>  Issue Type: Bug
>  Components: Content Distribution
>Reporter: Marius Petria
>Assignee: Marius Petria
> Fix For: Content Distribution Core 0.1.14
>
>
> We should not use locks when acquiring/releasing packages



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (SLING-4158) NPE in case applicablePaths property is not set for a validation model

[Robert Munteanu (JIRA)]

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

Robert Munteanu closed SLING-4158.
--

> NPE in case applicablePaths property is not set for a validation model
> --
>
> Key: SLING-4158
> URL: https://issues.apache.org/jira/browse/SLING-4158
> Project: Sling
>  Issue Type: Bug
>  Components: Validation
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: Validation 1.0.0
>
>
> According to https://github.com/raducotescu/org.apache.sling.validation the 
> property {{applicablePaths}} should be optional. But in case a model is found 
> which does not have this property the following NPE is thrown:
> {code}
> java.lang.NullPointerException: null
>   at 
> org.apache.sling.validation.impl.ValidationServiceImpl.searchAndStoreValidationModel(ValidationServiceImpl.java:321)
>   at 
> org.apache.sling.validation.impl.ValidationServiceImpl.getValidationModel(ValidationServiceImpl.java:93)
>   at 
> org.apache.sling.validation.impl.ValidationServiceImpl.getValidationModel(ValidationServiceImpl.java:103)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (SLING-5430) Allow item move between distribution queues

[Robert Munteanu (JIRA)]

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

Robert Munteanu closed SLING-5430.
--

> Allow item move between distribution queues
> ---
>
> Key: SLING-5430
> URL: https://issues.apache.org/jira/browse/SLING-5430
> Project: Sling
>  Issue Type: Bug
>  Components: Content Distribution
>Reporter: Marius Petria
>Assignee: Marius Petria
> Fix For: Content Distribution Core 0.1.14
>
>
> {noformat}
> POST /libs/.../agents/agentName/queues/queueName
> operation=move=sourceQueueName=idsToMove
> {noformat} 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (SLING-5439) HttpEntity in SimpleHttpTransport should be consumed / discarded

[Robert Munteanu (JIRA)]

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

Robert Munteanu closed SLING-5439.
--

> HttpEntity in SimpleHttpTransport should be consumed / discarded
> 
>
> Key: SLING-5439
> URL: https://issues.apache.org/jira/browse/SLING-5439
> Project: Sling
>  Issue Type: Improvement
>  Components: Content Distribution
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
> Fix For: Content Distribution Core 0.1.14
>
>
> {{SimpleHttpDistributionTransport#deliverPackage}} returns Http {{Content}} 
> but doesn't use it. While it seems it's not possible to just let it go (as 
> that would leak as an unconsumed resource) such content should be discarded.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (SLING-4221) ArrayIndexOutOfBoundException in case of empty multivalue property

[Robert Munteanu (JIRA)]

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

Robert Munteanu closed SLING-4221.
--

> ArrayIndexOutOfBoundException in case of empty multivalue property
> --
>
> Key: SLING-4221
> URL: https://issues.apache.org/jira/browse/SLING-4221
> Project: Sling
>  Issue Type: Bug
>  Components: Validation
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: Validation 1.0.0
>
>
> The following exception is thrown whenever an empty multivalue property is 
> validated 
> {code}
> java.lang.ArrayIndexOutOfBoundsException: 0
> at 
> org.apache.sling.validation.impl.ValidationServiceImpl.validatePropertyValue(ValidationServiceImpl.java:420)
> at 
> org.apache.sling.validation.impl.ValidationServiceImpl.validateValueMap(ValidationServiceImpl.java:277)
> at 
> org.apache.sling.validation.impl.ValidationServiceImpl.validateValueMap(ValidationServiceImpl.java:256)
> at 
> org.apache.sling.validation.impl.ValidationServiceImpl.validate(ValidationServiceImpl.java:175)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (SLING-5472) Some distribution packages are leaked because delete is called on closed objects

[Robert Munteanu (JIRA)]

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

Robert Munteanu closed SLING-5472.
--

> Some distribution packages are leaked because delete is called on closed 
> objects
> 
>
> Key: SLING-5472
> URL: https://issues.apache.org/jira/browse/SLING-5472
> Project: Sling
>  Issue Type: Bug
>  Components: Content Distribution
>Reporter: Marius Petria
>Assignee: Marius Petria
> Fix For: Content Distribution Core 0.1.14
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (SLING-5444) Display nameHints in webConsole for distribution factories

[Robert Munteanu (JIRA)]

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

Robert Munteanu closed SLING-5444.
--

> Display nameHints in webConsole for distribution factories
> --
>
> Key: SLING-5444
> URL: https://issues.apache.org/jira/browse/SLING-5444
> Project: Sling
>  Issue Type: Improvement
>Reporter: Marius Petria
>Assignee: Marius Petria
> Fix For: Content Distribution Core 0.1.14
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (SLING-6727) Align accessors in API

[Robert Munteanu (JIRA)]

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

Robert Munteanu closed SLING-6727.
--

> Align accessors in API
> --
>
> Key: SLING-6727
> URL: https://issues.apache.org/jira/browse/SLING-6727
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions, Validation
>Reporter: Oliver Lietz
>Assignee: Konrad Windszus
> Fix For: Validation 1.0.0
>
>
> We currently have {{getValidationModel(...)}} and 
> {{getModel(...)}}/{{getModels(...)}}, but should use one or the other.
> Also we should remove _Validated_ from 
> {{ValidationModel#getValidatedResourceType()}}.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (SLING-4214) Support children without root properties on the validation model resource

[Robert Munteanu (JIRA)]

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

Robert Munteanu closed SLING-4214.
--

> Support children without root properties on the validation model resource
> -
>
> Key: SLING-4214
> URL: https://issues.apache.org/jira/browse/SLING-4214
> Project: Sling
>  Issue Type: Improvement
>  Components: Validation
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: Validation 1.0.0
>
>
> Currently the validation model cannot be found in case there is no 
> {{properties}} resource on the root level.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (SLING-6600) Support multivalue validator argument values in ResourceValidationModelProviderImpl

[Robert Munteanu (JIRA)]

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

Robert Munteanu closed SLING-6600.
--

> Support multivalue validator argument values in 
> ResourceValidationModelProviderImpl
> ---
>
> Key: SLING-6600
> URL: https://issues.apache.org/jira/browse/SLING-6600
> Project: Sling
>  Issue Type: Improvement
>  Components: Validation
>Affects Versions: Validation 1.0.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: Validation 1.0.0
>
>
> Currently only singlevalue argument values are allowed for property 
> {{validatorArguments}} in {{ResourceValidationModelProviderImpl}}. If you 
> give the following multivalue string
> {code}{"key1=value1", "key1=value2"}{code} the second item will just 
> overwrite the first one.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (SLING-5346) Clarify distribution queue statuses

[Robert Munteanu (JIRA)]

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

Robert Munteanu closed SLING-5346.
--

> Clarify distribution queue statuses
> ---
>
> Key: SLING-5346
> URL: https://issues.apache.org/jira/browse/SLING-5346
> Project: Sling
>  Issue Type: Bug
>  Components: Content Distribution
>Reporter: Marius Petria
>Assignee: Marius Petria
> Fix For: Content Distribution Core 0.1.12
>
>
> A distribution queue can be passive or active. Passive is when it does not 
> have an associated processing action, and active when it does (for eg. 
> delivery to an endpoint).
> An active queue can be in three states: Idle, Running, Blocked or Paused.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (SLING-6534) Optionally cache results of ValidationService.validate(Resource, ValidationModel) and expose the cached result via an AdapterFactory

[Robert Munteanu (JIRA)]

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

Robert Munteanu closed SLING-6534.
--

> Optionally cache results of ValidationService.validate(Resource, 
> ValidationModel) and expose the cached result via an AdapterFactory
> 
>
> Key: SLING-6534
> URL: https://issues.apache.org/jira/browse/SLING-6534
> Project: Sling
>  Issue Type: Improvement
>  Components: Validation
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: Validation 1.0.0
>
>
> At least for the Sling Validation being triggered from the 
> ModelAdapterFactory it would be beneficial to be able to look up the result 
> of the last validation of a specific resource in a cache. That is especially 
> useful when exceptions cannot be used to propagate this information to a 
> different place in the code (e.g. to a Servlet filter). A concrete use case 
> for this is SLING-6531 where the cached result is accessible even if all 
> failures are below the threshold.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (SLING-4387) Validation: Support validation of resource and all child resources

[Robert Munteanu (JIRA)]

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

Robert Munteanu closed SLING-4387.
--

> Validation: Support validation of resource and all child resources
> --
>
> Key: SLING-4387
> URL: https://issues.apache.org/jira/browse/SLING-4387
> Project: Sling
>  Issue Type: Improvement
>  Components: Validation
>Affects Versions: Validation 1.0.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: Validation 1.0.0
>
>
> Currently through {{ValidationService.validate}} it is only possible to 
> trigger validation being connected to a single JCR validation model.
> It would be useful to be able to trigger validation on a resource which would 
> also comprise validation of all child resource (with their own dedicated 
> validation models, being determined automatically through their resourceType).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (SLING-5619) 3 IT failures in org.apache.sling.distribution.it

[Robert Munteanu (JIRA)]

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

Robert Munteanu closed SLING-5619.
--

> 3 IT failures in org.apache.sling.distribution.it
> -
>
> Key: SLING-5619
> URL: https://issues.apache.org/jira/browse/SLING-5619
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Reporter: Robert Munteanu
>Assignee: Marius Petria
> Fix For: Content Distribution Core 0.1.16
>
>
> Both locally and on Jenkins I get the following test failures:
> {noformat}  
> MultipleForwardDistributionTest.testAddContentCheckPassiveQueue:88 
> expected:<0> but was:<1>
>   MultipleQueueDistributionTest.testCopyDistributeQueues:132 expected:<0> but 
> was:<1>
>   MultipleQueueDistributionTest.testDistributeQueues:80 expected:<2> but 
> was:<1>{noformat}
> [~teofili], [~mpetria], any ideas?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (SLING-4012) Do not catch SlingValidationExceptions in the ValidationServiceImpl.java

[Robert Munteanu (JIRA)]

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

Robert Munteanu closed SLING-4012.
--

> Do not catch SlingValidationExceptions in the ValidationServiceImpl.java
> 
>
> Key: SLING-4012
> URL: https://issues.apache.org/jira/browse/SLING-4012
> Project: Sling
>  Issue Type: Improvement
>  Components: Validation
>Reporter: Konrad Windszus
>Assignee: Bertrand Delacretaz
>  Labels: validator
> Fix For: Validation 1.0.0
>
>
> Currently all SlingValidationExceptions are caught in the 
> ValidationServiceImpl.java 
> (https://github.com/apache/sling/blob/trunk/contrib/validation/core/src/main/java/org/apache/sling/validation/impl/ValidationServiceImpl.java#L384).
>  Since those exceptions should only happen during development, it would be 
> very good, if those exceptions would not be caught by the 
> ValidationServiceImpl. That way the exception is printed in most of the cases 
> directly into the response (i.e. is easier to see during development time). 
> Also features like a custom exception handler (through a servlet filter) or 
> the AEM error filter could be used to expose that exception.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (SLING-5283) Allow item copy between distribution queues

[Robert Munteanu (JIRA)]

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

Robert Munteanu closed SLING-5283.
--

> Allow item copy between distribution queues
> ---
>
> Key: SLING-5283
> URL: https://issues.apache.org/jira/browse/SLING-5283
> Project: Sling
>  Issue Type: Improvement
>  Components: Content Distribution
>Reporter: Marius Petria
>Assignee: Marius Petria
> Fix For: Content Distribution Core 0.1.10
>
>
> In order to retry items from an error queue we should be able to copy items 
> from an error queue to an original queue.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (SLING-5436) Do not move distribution packages to error queues after connection problems

[Robert Munteanu (JIRA)]

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

Robert Munteanu closed SLING-5436.
--

> Do not move distribution packages to error queues after connection problems
> ---
>
> Key: SLING-5436
> URL: https://issues.apache.org/jira/browse/SLING-5436
> Project: Sling
>  Issue Type: Bug
>  Components: Content Distribution
>Reporter: Marius Petria
>Assignee: Marius Petria
> Fix For: Content Distribution Core 0.1.14
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (SLING-5209) Have all package data under /var/sling/distribution/packages

[Robert Munteanu (JIRA)]

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

Robert Munteanu closed SLING-5209.
--

> Have all package data under /var/sling/distribution/packages
> 
>
> Key: SLING-5209
> URL: https://issues.apache.org/jira/browse/SLING-5209
> Project: Sling
>  Issue Type: Bug
>  Components: Content Distribution
>Reporter: Marius Petria
>Assignee: Marius Petria
> Fix For: Content Distribution Core 0.1.10
>
>
> Currently package data is scattered across the repo and that makes it hard to 
> view it and manage it.
> We should have the following package data hierarchy:
> /var/sling/distribution/packages/{builderName}/shared - for the shared 
> packages references
> /var/sling/distribution/packages/{builderName}/data - for the actual binary 
> packages



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (SLING-6659) ValidationModelRetrieverImpl does not respect changes to Validator's service properties

[Robert Munteanu (JIRA)]

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

Robert Munteanu closed SLING-6659.
--

> ValidationModelRetrieverImpl does not respect changes to Validator's service 
> properties
> ---
>
> Key: SLING-6659
> URL: https://issues.apache.org/jira/browse/SLING-6659
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions, Validation
>Reporter: Oliver Lietz
>Assignee: Konrad Windszus
> Fix For: Validation 1.0.0
>
>
> {{ValidationModelRetrieverImpl}} is using service properties of validators 
> (service ranking and validator id) to set up a list (map) of known 
> validators, but is agnostic to changes happening at runtime. The list is 
> built only on validator activation/deactivation but not on modification.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (SLING-2803) Create a Validation module capable of validating POST requests or Resources

[Robert Munteanu (JIRA)]

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

Robert Munteanu closed SLING-2803.
--

> Create a Validation module capable of validating POST requests or Resources
> ---
>
> Key: SLING-2803
> URL: https://issues.apache.org/jira/browse/SLING-2803
> Project: Sling
>  Issue Type: New Feature
>  Components: Validation
>Reporter: Radu Cotescu
>Assignee: Bertrand Delacretaz
> Fix For: Validation 1.0.0
>
> Attachments: org.apache.sling.validation.zip, 
> org.apache.sling.validation.zip.sha1
>
>
> Several Sling users have asked in the past [1] about a Validation mechanism 
> in Sling that's able to validate data coming from the user. However, such a 
> module is still missing.
> This issue is meant to track the work progress on such a module.
> Ideally the module should be able to validate both request parameters and 
> Resources, by obtaining their properties via a ValueMap and provide feedback 
> in case of a validation error.
> [1] - http://sling.markmail.org/search/?q=validation



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (SLING-6662) Move DefaultValidationFailure and DefaultValidationResult out of package org.apache.sling.validation.spi

[Robert Munteanu (JIRA)]

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

Robert Munteanu closed SLING-6662.
--

> Move DefaultValidationFailure and DefaultValidationResult out of package 
> org.apache.sling.validation.spi
> 
>
> Key: SLING-6662
> URL: https://issues.apache.org/jira/browse/SLING-6662
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions, Validation
>Reporter: Oliver Lietz
>Assignee: Konrad Windszus
> Fix For: Validation 1.0.0
>
>
> Move DefaultValidationFailure and DefaultValidationResult to Validation Core 
> (package {{org.apache.sling.validation.support|base}}) to keep Validation API 
> lean.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (SLING-6515) Sling Post Processor considering validation model as well

[Robert Munteanu (JIRA)]

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

Robert Munteanu closed SLING-6515.
--

> Sling Post Processor considering validation model as well
> -
>
> Key: SLING-6515
> URL: https://issues.apache.org/jira/browse/SLING-6515
> Project: Sling
>  Issue Type: Improvement
>  Components: Validation
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: Validation 1.0.0
>
> Attachments: SLING-6515-v01.patch
>
>
> It should be possible to optionally enable a Sling Post Processor which 
> validates the incoming parameters against a validation model. In case the 
> incoming parameters are not valid, there must be an error response. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)