date:20171013

Re: Upgrade to Oak 1.7.9

2017-10-13 Thread Oliver Lietz

On Friday 13 October 2017 14:17:03 Ian Boston wrote:
> Hi,

Hi Ian,

> On 13 October 2017 at 13:24, Oliver Lietz  wrote:
> > On Friday 13 October 2017 10:51:31 Ian Boston wrote:
> > > Hi,
> > 
> > Hi,
> > 
> > > I would like to upgrade Sling to depend on Oak 1.7.9 as it was just
> > > released. The patch be the same as [1] with 1.7.8 replaced by 1.7.9.
> > > 
> > > Any objections ?
> > 
> > I prefer sticking to stable and wait for 1.8.0.
> 
> Is that a strong preference ?

yes, very strong. I hadn't the time to argue today, but Julian explained it 
well in the other thread (though I don't see how branching could help in 
general* as we are not able to cut releases anyway).

> Not upgrading blocks the availability of OAK-6575 until 1.8.0 is released,
> which creates delays in that feature being available downstream.

[*] You can create private releases of course (which Adobe did in the past 
already, not recommended).

Regards,
O.

> Best Regards
> Ian
> 
> > Regards,
> > O.
> > 
> > > Best Regards
> > > Ian
> > > 
> > > 1 https://github.com/apache/sling/compare/trunk...ieb:
> > > upgradeToOak178?expand=1

[jira] [Commented] (SLING-7185) Content Parser: Support for ISO-8601

2017-10-13 Thread Jason E Bailey (JIRA)


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

Jason E Bailey commented on SLING-7185:
---

I found the formatting for the date to be odd and specific since Sling is 
specifically looking for a specific date format in a US locale formatting. Then 
it was brought to my attention that Sling is exporting the date field in this 
format as well.

So my assumptions at this point is that the main focus of JSON output was to 
create JSON specifically for browsers and at *that* point in time the 
formatting of dates in javascript was the US focused format currently being 
used by Sling 

Notes:
* JavaScript has supported an ISO8601 subset since EcmaScript 5.1
* In JavaScript the default implementation of Date.toJSON() is an ISO8601 
string. see 
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/toJSON
* ISO8601 is the standard for String representations of dates. see 
https://xkcd.com/1179/

 Would there be support in adding this to the Content Parser? 



> Content Parser: Support for ISO-8601
> 
>
> Key: SLING-7185
> URL: https://issues.apache.org/jira/browse/SLING-7185
> Project: Sling
>  Issue Type: Improvement
>Reporter: Jason E Bailey
>Priority: Minor
>
> The class org.apache.sling.jcr.contentparser.impl.ParserHelper defines the 
> Json format for a date to a defined value of ECMA_DATE_FORMAT. 
> Please support ISO-8601 as a date format. 



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

Re: Depending on Oak 1.7.x

2017-10-13 Thread Ian Boston

Hi,
The bundles are

Sling API
Sling ResourceResolver
Sling JCR Resource
Sling GET Servlets.

given these will probably get fixed between now and when Oak 2.0 is
released and could end up in a product I don't think an internal release is
a viable low risk option.

I think the only viable option is to wait for Oak 2.0 to be released, given
the Oak backport policy of no new features or API changes in stable
branches.
Best Regards
Ian


On 13 October 2017 at 17:25, Chetan Mehrotra 
wrote:

> Another possible option can be to branch such bundles which depend on
> Oak API and do unstable releases for them i.e. only odd version
> release. This would allow implementing parts in Sling which rely on
> new features implement in Oak trunk

Chetan Mehrotra
>
>
> On Fri, Oct 13, 2017 at 8:25 PM, Ian Boston  wrote:
> > Hi,
> >
> > On 13 October 2017 at 15:46, Julian Sedding  wrote:
> >
> >> AFAIK Oak does not use semantic versioning for packages within uneven
> >> minor version changes (i.e. 1.8 will be baselined against 1.6). This
> >> gives the Oak dev team freedom to experiment with API changes within
> >> the uneven "development" version (i.e. currently 1.7).
> >>
> >> Sling, on the other hand uses semantic versioning and (implicitly?)
> >> requires that any bundle can be released at any point. This
> >> requirement conflicts with Oak's "unstable" development releases in so
> >> far as Sling should not create any releases that reference Oak's
> >> intermittent (non semantic) package versions. Doing so could lead to
> >> update problems or badly wired OSGi bundles down the line.
> >>
> >> IMHO the "unstable" label of Oak's uneven minor versions refers not to
> >> unstable or poorly tested code, but acknowledges that semantic
> >> versioning is only enforced in releases with even minor version
> >> numbers.
> >>
> >> This implies that using "unstable" Oak for testing within Sling should
> >> be fine. Releasing bundles with "unstable" Oak dependencies is
> >> definitely slippery slope, even though it does not have to lead to
> >> problems.
> >>
> >
> > Underlined by the appearance of some new bundles in 1.7.9 that were not
> > there in 1.7.8, however AFAIK the package versions were not changed.
> >
> > Since I was wrong to assert 1.7.8 was close to 1.8.0 (see other thread),
> I
> > have asked oak-dev to clarify it it is or not. If its not, I also dont
> want
> > to slip down that slope.
> > Best Regards
> > Ian
> >
> >
> >
> >>
> >> Remains the tricky question: how do we build on cutting edge Oak
> >> features? Branches could be one option (especially once we're on Git),
> >> with no (official) releases from the branch.
> >>
> >> Regards
> >> Julian
> >>
> >>
> >> On Fri, Oct 13, 2017 at 11:56 AM, Ian Boston  wrote:
> >> > Hi,
> >> > My View is that it would be dangerous to depend on 1.11.1 but safe to
> >> > depend on 1.11.25 if 1.11.25 was known to be near to the branch to
> >> 1.12.x.
> >> > The closer to 1.11.1, the greater the risk of instability, the closer
> to
> >> > 1.12.x the less the risk.
> >> >
> >> > IIUC Oak have started to discuss the possibility of branching 1.8.x,
> >> which
> >> > makes 1.7.9 relatively close to that branch. That said, I made an API
> >> > change that appeared in 1.7.9 ;). It all depends on the detail in
> every
> >> > case. There are no rules that always work.
> >> >
> >> > Best Regards
> >> > Ian
> >> >
> >> >
> >> >
> >> > On 12 October 2017 at 16:28, Matt Ryan  wrote:
> >> >
> >> >> Hi,
> >> >>
> >> >> I’m curious to explore the reasoning behind the general principle of
> >> only
> >> >> having dependencies on stable Oak releases.  Of course I understand
> the
> >> >> importance of keeping the codebase on a solid foundation and thus to
> >> want
> >> >> stable releases for dependencies.  My question is, what exactly is
> >> meant by
> >> >> “stable”?
> >> >>
> >> >> I expect we regard even-numbered minor versions in Oak as stable
> >> releases
> >> >> because that’s how the Oak project refers to such releases.  Based on
> >> that
> >> >> reasoning, Oak 1.7.8 is unstable by definition.  I’d then argue that
> if
> >> Oak
> >> >> were to change their versioning model (which I’m not proposing - and
> I
> >> >> wouldn’t propose it here if I was proposing such a thing anyway) such
> >> that
> >> >> a “stable” Oak release is defined by some other means (say, any
> version
> >> >> that passes the entire test suite), Oak 1.7.10 may be considered
> stable
> >> -
> >> >> in which case the concern to rely on that version would be lower.  In
> >> other
> >> >> words:  If Oak were to declare a version as stable, is that
> sufficient
> >> for
> >> >> us to rely on those package versions?  Or would we do our own
> validation
> >> >> anyway?
> >> >>
> >> >> My point is that it appears the resistance to use a particular Oak
> >> version
> >> >> is based on Oak not declaring it as stable.  Yet Sling

Re: Depending on Oak 1.7.x

2017-10-13 Thread Chetan Mehrotra

Another possible option can be to branch such bundles which depend on
Oak API and do unstable releases for them i.e. only odd version
release. This would allow implementing parts in Sling which rely on
new features implement in Oak trunk
Chetan Mehrotra


On Fri, Oct 13, 2017 at 8:25 PM, Ian Boston  wrote:
> Hi,
>
> On 13 October 2017 at 15:46, Julian Sedding  wrote:
>
>> AFAIK Oak does not use semantic versioning for packages within uneven
>> minor version changes (i.e. 1.8 will be baselined against 1.6). This
>> gives the Oak dev team freedom to experiment with API changes within
>> the uneven "development" version (i.e. currently 1.7).
>>
>> Sling, on the other hand uses semantic versioning and (implicitly?)
>> requires that any bundle can be released at any point. This
>> requirement conflicts with Oak's "unstable" development releases in so
>> far as Sling should not create any releases that reference Oak's
>> intermittent (non semantic) package versions. Doing so could lead to
>> update problems or badly wired OSGi bundles down the line.
>>
>> IMHO the "unstable" label of Oak's uneven minor versions refers not to
>> unstable or poorly tested code, but acknowledges that semantic
>> versioning is only enforced in releases with even minor version
>> numbers.
>>
>> This implies that using "unstable" Oak for testing within Sling should
>> be fine. Releasing bundles with "unstable" Oak dependencies is
>> definitely slippery slope, even though it does not have to lead to
>> problems.
>>
>
> Underlined by the appearance of some new bundles in 1.7.9 that were not
> there in 1.7.8, however AFAIK the package versions were not changed.
>
> Since I was wrong to assert 1.7.8 was close to 1.8.0 (see other thread), I
> have asked oak-dev to clarify it it is or not. If its not, I also dont want
> to slip down that slope.
> Best Regards
> Ian
>
>
>
>>
>> Remains the tricky question: how do we build on cutting edge Oak
>> features? Branches could be one option (especially once we're on Git),
>> with no (official) releases from the branch.
>>
>> Regards
>> Julian
>>
>>
>> On Fri, Oct 13, 2017 at 11:56 AM, Ian Boston  wrote:
>> > Hi,
>> > My View is that it would be dangerous to depend on 1.11.1 but safe to
>> > depend on 1.11.25 if 1.11.25 was known to be near to the branch to
>> 1.12.x.
>> > The closer to 1.11.1, the greater the risk of instability, the closer to
>> > 1.12.x the less the risk.
>> >
>> > IIUC Oak have started to discuss the possibility of branching 1.8.x,
>> which
>> > makes 1.7.9 relatively close to that branch. That said, I made an API
>> > change that appeared in 1.7.9 ;). It all depends on the detail in every
>> > case. There are no rules that always work.
>> >
>> > Best Regards
>> > Ian
>> >
>> >
>> >
>> > On 12 October 2017 at 16:28, Matt Ryan  wrote:
>> >
>> >> Hi,
>> >>
>> >> I’m curious to explore the reasoning behind the general principle of
>> only
>> >> having dependencies on stable Oak releases.  Of course I understand the
>> >> importance of keeping the codebase on a solid foundation and thus to
>> want
>> >> stable releases for dependencies.  My question is, what exactly is
>> meant by
>> >> “stable”?
>> >>
>> >> I expect we regard even-numbered minor versions in Oak as stable
>> releases
>> >> because that’s how the Oak project refers to such releases.  Based on
>> that
>> >> reasoning, Oak 1.7.8 is unstable by definition.  I’d then argue that if
>> Oak
>> >> were to change their versioning model (which I’m not proposing - and I
>> >> wouldn’t propose it here if I was proposing such a thing anyway) such
>> that
>> >> a “stable” Oak release is defined by some other means (say, any version
>> >> that passes the entire test suite), Oak 1.7.10 may be considered stable
>> -
>> >> in which case the concern to rely on that version would be lower.  In
>> other
>> >> words:  If Oak were to declare a version as stable, is that sufficient
>> for
>> >> us to rely on those package versions?  Or would we do our own validation
>> >> anyway?
>> >>
>> >> My point is that it appears the resistance to use a particular Oak
>> version
>> >> is based on Oak not declaring it as stable.  Yet Sling probably depends
>> on
>> >> other packages that have different criteria for being considered stable
>> -
>> >> some which may not even declare a particular version as such.  I don’t
>> have
>> >> concrete knowledge about that of course, just a hunch.
>> >>
>> >> But if that’s the case, perhaps it is worthwhile to consider the reason
>> >> this policy was adopted for Oak packages, and maybe in understanding
>> what
>> >> the real goal is we can find a way where we don’t feel concerned
>> updating
>> >> dependencies to an “unstable” Oak release.  For example, if such a
>> release
>> >> passes all Oak tests and all Sling tests, maybe that’s acceptable.
>> >>
>> >> -MR
>> >>
>> >>
>> >> On October 12, 2017 at 8:34:50 AM, Ian Boston (i...@tfd.co.uk)

Re: Upgrade to Oak 1.7.9

2017-10-13 Thread Ian Boston

Hi,
Please ignore this thread now. Upgrading to 1.7.9 is not safe.

Oak 1.7.9 is not stable or close to 1.8 and the Oak team has indicated
there will be more changes before 1.8 potentially to exported packages. In
fact, so many that a discussion thread for Oak 2.0 thread was just started
on oak-dev.
Best Regards
Ian

On 13 October 2017 at 14:26, Ian Boston  wrote:

> Hi,
>
> On 13 October 2017 at 13:25, Oliver Lietz  wrote:
>
>> On Friday 13 October 2017 13:00:53 Ian Boston wrote:
>> > On 13 October 2017 at 11:16, Robert Munteanu 
>> wrote:
>> > > Hi Ian,
>>
>> Hi,
>>
>> > > On Fri, 2017-10-13 at 10:51 +0100, Ian Boston wrote:
>> > > > Hi,
>> > > > I would like to upgrade Sling to depend on Oak 1.7.9 as it was just
>> > > > released. The patch be the same as [1] with 1.7.8 replaced by 1.7.9.
>> > > >
>> > > > Any objections ?
>> > >
>> > > No objections here.
>> > >
>> > > Related to the pull request - is it required for bundles consuming
>> > > testing.paxexam to bump up their dependency version?
>> >
>> > If those bundles want to perform integration tests on Oak 1.7.9 then
>> they
>> > need to bump the dependency.
>> > Some do, some dont, so I bumped all to make certain all would still
>> build
>> > on Oak 1.7.9.
>> >
>> > The first one that needs to do a release, will have to release paxexam
>> at
>> > the same time... and fix the references to the 0.0.5-SNAPSHOT version.
>> >
>> > I assume that was done before since all were on 0.0.4.
>>
>> no need for a new release of Testing PaxExam (but will do a release soon
>> anyway), you can override the version for Oak with the one from POM (was
>> done
>> in the past e.g. for Oak Server):
>>
>
>
> Between Oak 1.6.5 and Oak 1.7.9 there has been a modularisation effort.
> Whereas selecting a version of Oak prior to 1.7.9 was a simple task of
> changing a single oak-core version number (actually 2 since Jackrabbit API
> is versioned with Oak releases), between 1.7.9 and later there are 6
> additional bundles. It is true I could have done that in oak-server,
> however that wouldn't be appropriate for other bundles, some of which
> broke.
>
> Not building with ITs having Oak 1.7.9 or later for every bundle risks
> releasing a Sling bundle that wont work with that version of the Oak
> server. So far I have not seen a breakage of that nature, but that is no
> longer an unknown risk.
>
> I hope that makes sense and is clear from the patch itself.
>
> Best Regards
> Ian
>
>
>>
>> https://github.com/apache/sling/tree/trunk/testing/org.apach
>> e.sling.testing.paxexam
>>
>> Regards,
>> O.
>>
>> > Best Regards
>> > Ian
>> >
>> > > I think they can
>> > > run their tests just fine on the old dependencies and in case of a
>> > > release of that module we don't need to wait for a release of
>> > > testing.paxexam.
>> > >
>> > > I'm looking at
>> > >
>> > > - bundles/commons/contentdetection
>> > > - bundles/commons/metrics
>> > > - bundles/extensions/org.apache.sling.resource.presence
>> > > - bundles/scripting/core
>> > > - contrib/extensions/rewriter
>> > > - contrib/extensions/sling
>> > > - contrib/scripting/freemarker
>> > > - contrib/scripting/org.apache.sling.scripting.thymeleaf
>> > >
>> > > Thanks,
>> > >
>> > > Robert
>>
>>
>>
>

Re: Depending on Oak 1.7.x

2017-10-13 Thread Ian Boston

Hi,

On 13 October 2017 at 15:46, Julian Sedding  wrote:

> AFAIK Oak does not use semantic versioning for packages within uneven
> minor version changes (i.e. 1.8 will be baselined against 1.6). This
> gives the Oak dev team freedom to experiment with API changes within
> the uneven "development" version (i.e. currently 1.7).
>
> Sling, on the other hand uses semantic versioning and (implicitly?)
> requires that any bundle can be released at any point. This
> requirement conflicts with Oak's "unstable" development releases in so
> far as Sling should not create any releases that reference Oak's
> intermittent (non semantic) package versions. Doing so could lead to
> update problems or badly wired OSGi bundles down the line.
>
> IMHO the "unstable" label of Oak's uneven minor versions refers not to
> unstable or poorly tested code, but acknowledges that semantic
> versioning is only enforced in releases with even minor version
> numbers.
>
> This implies that using "unstable" Oak for testing within Sling should
> be fine. Releasing bundles with "unstable" Oak dependencies is
> definitely slippery slope, even though it does not have to lead to
> problems.
>

Underlined by the appearance of some new bundles in 1.7.9 that were not
there in 1.7.8, however AFAIK the package versions were not changed.

Since I was wrong to assert 1.7.8 was close to 1.8.0 (see other thread), I
have asked oak-dev to clarify it it is or not. If its not, I also dont want
to slip down that slope.
Best Regards
Ian



>
> Remains the tricky question: how do we build on cutting edge Oak
> features? Branches could be one option (especially once we're on Git),
> with no (official) releases from the branch.
>
> Regards
> Julian
>
>
> On Fri, Oct 13, 2017 at 11:56 AM, Ian Boston  wrote:
> > Hi,
> > My View is that it would be dangerous to depend on 1.11.1 but safe to
> > depend on 1.11.25 if 1.11.25 was known to be near to the branch to
> 1.12.x.
> > The closer to 1.11.1, the greater the risk of instability, the closer to
> > 1.12.x the less the risk.
> >
> > IIUC Oak have started to discuss the possibility of branching 1.8.x,
> which
> > makes 1.7.9 relatively close to that branch. That said, I made an API
> > change that appeared in 1.7.9 ;). It all depends on the detail in every
> > case. There are no rules that always work.
> >
> > Best Regards
> > Ian
> >
> >
> >
> > On 12 October 2017 at 16:28, Matt Ryan  wrote:
> >
> >> Hi,
> >>
> >> I’m curious to explore the reasoning behind the general principle of
> only
> >> having dependencies on stable Oak releases.  Of course I understand the
> >> importance of keeping the codebase on a solid foundation and thus to
> want
> >> stable releases for dependencies.  My question is, what exactly is
> meant by
> >> “stable”?
> >>
> >> I expect we regard even-numbered minor versions in Oak as stable
> releases
> >> because that’s how the Oak project refers to such releases.  Based on
> that
> >> reasoning, Oak 1.7.8 is unstable by definition.  I’d then argue that if
> Oak
> >> were to change their versioning model (which I’m not proposing - and I
> >> wouldn’t propose it here if I was proposing such a thing anyway) such
> that
> >> a “stable” Oak release is defined by some other means (say, any version
> >> that passes the entire test suite), Oak 1.7.10 may be considered stable
> -
> >> in which case the concern to rely on that version would be lower.  In
> other
> >> words:  If Oak were to declare a version as stable, is that sufficient
> for
> >> us to rely on those package versions?  Or would we do our own validation
> >> anyway?
> >>
> >> My point is that it appears the resistance to use a particular Oak
> version
> >> is based on Oak not declaring it as stable.  Yet Sling probably depends
> on
> >> other packages that have different criteria for being considered stable
> -
> >> some which may not even declare a particular version as such.  I don’t
> have
> >> concrete knowledge about that of course, just a hunch.
> >>
> >> But if that’s the case, perhaps it is worthwhile to consider the reason
> >> this policy was adopted for Oak packages, and maybe in understanding
> what
> >> the real goal is we can find a way where we don’t feel concerned
> updating
> >> dependencies to an “unstable” Oak release.  For example, if such a
> release
> >> passes all Oak tests and all Sling tests, maybe that’s acceptable.
> >>
> >> -MR
> >>
> >>
> >> On October 12, 2017 at 8:34:50 AM, Ian Boston (i...@tfd.co.uk) wrote:
> >>
> >> Hi,
> >> Here is a patch to make Sling work with Oak 1.7.8. Once I fixed a full
> >> build (just did a pull request) it passes a full IT build. The patch
> >> updates the paxexam setup so IT tests that uses that will test against
> Oak
> >> 1.7.8. I also tested with 1.8-SNAPSHOT so this should be good for
> anything
> >> after 1.7.8. We might wait till 1.7.10 comes out as IIUC this will
> >> include OAK-6575.
> >>
> >> wdyt, mege when

Re: Depending on Oak 1.7.x

2017-10-13 Thread Julian Sedding

AFAIK Oak does not use semantic versioning for packages within uneven
minor version changes (i.e. 1.8 will be baselined against 1.6). This
gives the Oak dev team freedom to experiment with API changes within
the uneven "development" version (i.e. currently 1.7).

Sling, on the other hand uses semantic versioning and (implicitly?)
requires that any bundle can be released at any point. This
requirement conflicts with Oak's "unstable" development releases in so
far as Sling should not create any releases that reference Oak's
intermittent (non semantic) package versions. Doing so could lead to
update problems or badly wired OSGi bundles down the line.

IMHO the "unstable" label of Oak's uneven minor versions refers not to
unstable or poorly tested code, but acknowledges that semantic
versioning is only enforced in releases with even minor version
numbers.

This implies that using "unstable" Oak for testing within Sling should
be fine. Releasing bundles with "unstable" Oak dependencies is
definitely slippery slope, even though it does not have to lead to
problems.

Remains the tricky question: how do we build on cutting edge Oak
features? Branches could be one option (especially once we're on Git),
with no (official) releases from the branch.

Regards
Julian


On Fri, Oct 13, 2017 at 11:56 AM, Ian Boston  wrote:
> Hi,
> My View is that it would be dangerous to depend on 1.11.1 but safe to
> depend on 1.11.25 if 1.11.25 was known to be near to the branch to 1.12.x.
> The closer to 1.11.1, the greater the risk of instability, the closer to
> 1.12.x the less the risk.
>
> IIUC Oak have started to discuss the possibility of branching 1.8.x, which
> makes 1.7.9 relatively close to that branch. That said, I made an API
> change that appeared in 1.7.9 ;). It all depends on the detail in every
> case. There are no rules that always work.
>
> Best Regards
> Ian
>
>
>
> On 12 October 2017 at 16:28, Matt Ryan  wrote:
>
>> Hi,
>>
>> I’m curious to explore the reasoning behind the general principle of only
>> having dependencies on stable Oak releases.  Of course I understand the
>> importance of keeping the codebase on a solid foundation and thus to want
>> stable releases for dependencies.  My question is, what exactly is meant by
>> “stable”?
>>
>> I expect we regard even-numbered minor versions in Oak as stable releases
>> because that’s how the Oak project refers to such releases.  Based on that
>> reasoning, Oak 1.7.8 is unstable by definition.  I’d then argue that if Oak
>> were to change their versioning model (which I’m not proposing - and I
>> wouldn’t propose it here if I was proposing such a thing anyway) such that
>> a “stable” Oak release is defined by some other means (say, any version
>> that passes the entire test suite), Oak 1.7.10 may be considered stable -
>> in which case the concern to rely on that version would be lower.  In other
>> words:  If Oak were to declare a version as stable, is that sufficient for
>> us to rely on those package versions?  Or would we do our own validation
>> anyway?
>>
>> My point is that it appears the resistance to use a particular Oak version
>> is based on Oak not declaring it as stable.  Yet Sling probably depends on
>> other packages that have different criteria for being considered stable -
>> some which may not even declare a particular version as such.  I don’t have
>> concrete knowledge about that of course, just a hunch.
>>
>> But if that’s the case, perhaps it is worthwhile to consider the reason
>> this policy was adopted for Oak packages, and maybe in understanding what
>> the real goal is we can find a way where we don’t feel concerned updating
>> dependencies to an “unstable” Oak release.  For example, if such a release
>> passes all Oak tests and all Sling tests, maybe that’s acceptable.
>>
>> -MR
>>
>>
>> On October 12, 2017 at 8:34:50 AM, Ian Boston (i...@tfd.co.uk) wrote:
>>
>> Hi,
>> Here is a patch to make Sling work with Oak 1.7.8. Once I fixed a full
>> build (just did a pull request) it passes a full IT build. The patch
>> updates the paxexam setup so IT tests that uses that will test against Oak
>> 1.7.8. I also tested with 1.8-SNAPSHOT so this should be good for anything
>> after 1.7.8. We might wait till 1.7.10 comes out as IIUC this will
>> include OAK-6575.
>>
>> wdyt, mege when 1.7.10 is out and upgrade to a stable 1.8 when its cut ?
>> Best Regards
>> Ian
>>
>> 1
>> https://github.com/apache/sling/compare/trunk...ieb:
>> upgradeToOak178?expand=1
>>
>> On 11 October 2017 at 11:38, Ian Boston  wrote:
>>
>> >
>> >
>> > On 11 October 2017 at 11:25, Robert Munteanu 
>> wrote:
>> >
>> >> On Wed, 2017-10-11 at 11:16 +0100, Ian Boston wrote:
>> >> > Hi,
>> >> > Switching to depend on Oak 1.7 requires upgrading oak-server to use
>> >> > 1.7 or
>> >> > later.
>> >> > There has been some incompatible changes at a bundle level and
>> >> > package
>> >> > level between 1.6 and 1.7 so its

Re: [NOTICE] Getting ready to start the SVN → Git migration

2017-10-13 Thread Julian Sedding

I cannot see users@infra either, issues@infra is visible after login.

Regards
Julian

On Fri, Oct 13, 2017 at 11:52 AM, Robert Munteanu  wrote:
> On Fri, 2017-10-13 at 09:30 +, Stefan Seifert wrote:
>> > > What I see is that when I try to go to
>> > > https://lists.apache.org/list.html?us...@infra.apache.org, after
>> > > authenticating, I end up on
>> > > https://lists.apache.org/list.html?iss...@infra.apache.org
>> >
>> > Just to make sure - did you authenticate with your ASF credentials?
>>
>> yes, i did!
>> (but i did not try to subscribe to the users@ list)
>>
>> stefan
>>
>
> I am not sure that is required - I am not subscribed. Maybe it's best
> to ask infra :-) ? Quickest I guess woudl be http://infra.chat/ .
>
> Robert

Re: Upgrade to Oak 1.7.9

2017-10-13 Thread Ian Boston

Hi,

On 13 October 2017 at 13:25, Oliver Lietz  wrote:

> On Friday 13 October 2017 13:00:53 Ian Boston wrote:
> > On 13 October 2017 at 11:16, Robert Munteanu  wrote:
> > > Hi Ian,
>
> Hi,
>
> > > On Fri, 2017-10-13 at 10:51 +0100, Ian Boston wrote:
> > > > Hi,
> > > > I would like to upgrade Sling to depend on Oak 1.7.9 as it was just
> > > > released. The patch be the same as [1] with 1.7.8 replaced by 1.7.9.
> > > >
> > > > Any objections ?
> > >
> > > No objections here.
> > >
> > > Related to the pull request - is it required for bundles consuming
> > > testing.paxexam to bump up their dependency version?
> >
> > If those bundles want to perform integration tests on Oak 1.7.9 then they
> > need to bump the dependency.
> > Some do, some dont, so I bumped all to make certain all would still build
> > on Oak 1.7.9.
> >
> > The first one that needs to do a release, will have to release paxexam at
> > the same time... and fix the references to the 0.0.5-SNAPSHOT version.
> >
> > I assume that was done before since all were on 0.0.4.
>
> no need for a new release of Testing PaxExam (but will do a release soon
> anyway), you can override the version for Oak with the one from POM (was
> done
> in the past e.g. for Oak Server):
>


Between Oak 1.6.5 and Oak 1.7.9 there has been a modularisation effort.
Whereas selecting a version of Oak prior to 1.7.9 was a simple task of
changing a single oak-core version number (actually 2 since Jackrabbit API
is versioned with Oak releases), between 1.7.9 and later there are 6
additional bundles. It is true I could have done that in oak-server,
however that wouldn't be appropriate for other bundles, some of which
broke.

Not building with ITs having Oak 1.7.9 or later for every bundle risks
releasing a Sling bundle that wont work with that version of the Oak
server. So far I have not seen a breakage of that nature, but that is no
longer an unknown risk.

I hope that makes sense and is clear from the patch itself.

Best Regards
Ian


>
> https://github.com/apache/sling/tree/trunk/testing/org.
> apache.sling.testing.paxexam
>
> Regards,
> O.
>
> > Best Regards
> > Ian
> >
> > > I think they can
> > > run their tests just fine on the old dependencies and in case of a
> > > release of that module we don't need to wait for a release of
> > > testing.paxexam.
> > >
> > > I'm looking at
> > >
> > > - bundles/commons/contentdetection
> > > - bundles/commons/metrics
> > > - bundles/extensions/org.apache.sling.resource.presence
> > > - bundles/scripting/core
> > > - contrib/extensions/rewriter
> > > - contrib/extensions/sling
> > > - contrib/scripting/freemarker
> > > - contrib/scripting/org.apache.sling.scripting.thymeleaf
> > >
> > > Thanks,
> > >
> > > Robert
>
>
>

Re: Upgrade to Oak 1.7.9

2017-10-13 Thread Ian Boston

Hi,

On 13 October 2017 at 13:24, Oliver Lietz  wrote:

> On Friday 13 October 2017 10:51:31 Ian Boston wrote:
> > Hi,
>
> Hi,
>
> > I would like to upgrade Sling to depend on Oak 1.7.9 as it was just
> > released. The patch be the same as [1] with 1.7.8 replaced by 1.7.9.
> >
> > Any objections ?
>
> I prefer sticking to stable and wait for 1.8.0.
>

Is that a strong preference ?

Not upgrading blocks the availability of OAK-6575 until 1.8.0 is released,
which creates delays in that feature being available downstream.
Best Regards
Ian


>
> Regards,
> O.
>
> > Best Regards
> > Ian
> >
> > 1 https://github.com/apache/sling/compare/trunk...ieb:
> > upgradeToOak178?expand=1
>
>

[jira] [Resolved] (SLING-7198) Duplicated lookup for mapping without subserviceName

2017-10-13 Thread Karl Pauls (JIRA)


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

Karl Pauls resolved SLING-7198.
---
Resolution: Fixed

[~anchela] - nice catch! 

I removed it in r1812124. Thanks a lot!

> Duplicated lookup for mapping without subserviceName
> 
>
> Key: SLING-7198
> URL: https://issues.apache.org/jira/browse/SLING-7198
> Project: Sling
>  Issue Type: Bug
>  Components: Service User Mapper
>Affects Versions: Service User Mapper 1.3.4
>Reporter: angela
>Assignee: Karl Pauls
>Priority: Minor
> Fix For: Service User Mapper 1.3.6
>
>
> [~kpauls] If I am not mistaken there is an extra lookup in the following 
> method:
> {code}
> private Iterable internalGetPrincipalNames(final String 
> serviceName, final String subServiceName) {
> log.debug(
> "internalGetPrincipalNames: {} active mappings, looking for 
> mapping for {}/{}",
> new Object[] { this.activeMappings.length, serviceName, 
> subServiceName });
> for (final Mapping mapping : this.activeMappings) {
> final Iterable principalNames = 
> mapping.mapPrincipals(serviceName, subServiceName);
> if (principalNames != null) {
> log.debug("Got principalNames [{}] from {}/{}", new Object[] 
> {principalNames, serviceName, subServiceName });
> return principalNames;
> }
> }
> for (Mapping mapping : this.activeMappings) {
> final Iterable principalNames = 
> mapping.mapPrincipals(serviceName, null);
> if (principalNames != null) {
> log.debug("Got principalNames [{}] from {}/{}", new Object[] 
> {principalNames, serviceName });
> return principalNames;
> }
> }
> // second round without serviceInfo
> log.debug(
> "internalGetPrincipalNames: {} active mappings, looking for 
> mapping for {}/",
> this.activeMappings.length, serviceName);
> for (Mapping mapping : this.activeMappings) {
> final Iterable principalNames = 
> mapping.mapPrincipals(serviceName, null);
> if (principalNames != null) {
> log.debug("Got principalNames [{}] from {}/ subServiceName>", principalNames, serviceName);
> return principalNames;
> }
> }
> log.debug("internalGetPrincipalNames: no mapping found.");
> return null;
> }
> {code}
> If I read the code properly the lookup that is logged by being the 'second 
> round' is actually the third perform once again the lookup without 
> 'subServiceName'. If that is correct I would suggest to remove the following 
> code:
> {code}
> for (Mapping mapping : this.activeMappings) {
> final Iterable principalNames = 
> mapping.mapPrincipals(serviceName, null);
> if (principalNames != null) {
> log.debug("Got principalNames [{}] from {}/{}", new Object[] 
> {principalNames, serviceName });
> return principalNames;
> }
> }
> {code}
> or the third one that is called the second round ;-)
> But please double check to make sure I didn't just overlook some subtle diff 
> :-)



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

[jira] [Assigned] (SLING-7198) Duplicated lookup for mapping without subserviceName

2017-10-13 Thread Karl Pauls (JIRA)


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

Karl Pauls reassigned SLING-7198:
-

Assignee: Karl Pauls

> Duplicated lookup for mapping without subserviceName
> 
>
> Key: SLING-7198
> URL: https://issues.apache.org/jira/browse/SLING-7198
> Project: Sling
>  Issue Type: Bug
>  Components: Service User Mapper
>Affects Versions: Service User Mapper 1.3.4
>Reporter: angela
>Assignee: Karl Pauls
>Priority: Minor
> Fix For: Service User Mapper 1.3.6
>
>
> [~kpauls] If I am not mistaken there is an extra lookup in the following 
> method:
> {code}
> private Iterable internalGetPrincipalNames(final String 
> serviceName, final String subServiceName) {
> log.debug(
> "internalGetPrincipalNames: {} active mappings, looking for 
> mapping for {}/{}",
> new Object[] { this.activeMappings.length, serviceName, 
> subServiceName });
> for (final Mapping mapping : this.activeMappings) {
> final Iterable principalNames = 
> mapping.mapPrincipals(serviceName, subServiceName);
> if (principalNames != null) {
> log.debug("Got principalNames [{}] from {}/{}", new Object[] 
> {principalNames, serviceName, subServiceName });
> return principalNames;
> }
> }
> for (Mapping mapping : this.activeMappings) {
> final Iterable principalNames = 
> mapping.mapPrincipals(serviceName, null);
> if (principalNames != null) {
> log.debug("Got principalNames [{}] from {}/{}", new Object[] 
> {principalNames, serviceName });
> return principalNames;
> }
> }
> // second round without serviceInfo
> log.debug(
> "internalGetPrincipalNames: {} active mappings, looking for 
> mapping for {}/",
> this.activeMappings.length, serviceName);
> for (Mapping mapping : this.activeMappings) {
> final Iterable principalNames = 
> mapping.mapPrincipals(serviceName, null);
> if (principalNames != null) {
> log.debug("Got principalNames [{}] from {}/ subServiceName>", principalNames, serviceName);
> return principalNames;
> }
> }
> log.debug("internalGetPrincipalNames: no mapping found.");
> return null;
> }
> {code}
> If I read the code properly the lookup that is logged by being the 'second 
> round' is actually the third perform once again the lookup without 
> 'subServiceName'. If that is correct I would suggest to remove the following 
> code:
> {code}
> for (Mapping mapping : this.activeMappings) {
> final Iterable principalNames = 
> mapping.mapPrincipals(serviceName, null);
> if (principalNames != null) {
> log.debug("Got principalNames [{}] from {}/{}", new Object[] 
> {principalNames, serviceName });
> return principalNames;
> }
> }
> {code}
> or the third one that is called the second round ;-)
> But please double check to make sure I didn't just overlook some subtle diff 
> :-)



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

[jira] [Updated] (SLING-7198) Duplicated lookup for mapping without subserviceName

2017-10-13 Thread Karl Pauls (JIRA)


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

Karl Pauls updated SLING-7198:
--
Fix Version/s: Service User Mapper 1.3.6

> Duplicated lookup for mapping without subserviceName
> 
>
> Key: SLING-7198
> URL: https://issues.apache.org/jira/browse/SLING-7198
> Project: Sling
>  Issue Type: Bug
>  Components: Service User Mapper
>Affects Versions: Service User Mapper 1.3.4
>Reporter: angela
>Priority: Minor
> Fix For: Service User Mapper 1.3.6
>
>
> [~kpauls] If I am not mistaken there is an extra lookup in the following 
> method:
> {code}
> private Iterable internalGetPrincipalNames(final String 
> serviceName, final String subServiceName) {
> log.debug(
> "internalGetPrincipalNames: {} active mappings, looking for 
> mapping for {}/{}",
> new Object[] { this.activeMappings.length, serviceName, 
> subServiceName });
> for (final Mapping mapping : this.activeMappings) {
> final Iterable principalNames = 
> mapping.mapPrincipals(serviceName, subServiceName);
> if (principalNames != null) {
> log.debug("Got principalNames [{}] from {}/{}", new Object[] 
> {principalNames, serviceName, subServiceName });
> return principalNames;
> }
> }
> for (Mapping mapping : this.activeMappings) {
> final Iterable principalNames = 
> mapping.mapPrincipals(serviceName, null);
> if (principalNames != null) {
> log.debug("Got principalNames [{}] from {}/{}", new Object[] 
> {principalNames, serviceName });
> return principalNames;
> }
> }
> // second round without serviceInfo
> log.debug(
> "internalGetPrincipalNames: {} active mappings, looking for 
> mapping for {}/",
> this.activeMappings.length, serviceName);
> for (Mapping mapping : this.activeMappings) {
> final Iterable principalNames = 
> mapping.mapPrincipals(serviceName, null);
> if (principalNames != null) {
> log.debug("Got principalNames [{}] from {}/ subServiceName>", principalNames, serviceName);
> return principalNames;
> }
> }
> log.debug("internalGetPrincipalNames: no mapping found.");
> return null;
> }
> {code}
> If I read the code properly the lookup that is logged by being the 'second 
> round' is actually the third perform once again the lookup without 
> 'subServiceName'. If that is correct I would suggest to remove the following 
> code:
> {code}
> for (Mapping mapping : this.activeMappings) {
> final Iterable principalNames = 
> mapping.mapPrincipals(serviceName, null);
> if (principalNames != null) {
> log.debug("Got principalNames [{}] from {}/{}", new Object[] 
> {principalNames, serviceName });
> return principalNames;
> }
> }
> {code}
> or the third one that is called the second round ;-)
> But please double check to make sure I didn't just overlook some subtle diff 
> :-)



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

Re: Upgrade to Oak 1.7.9

2017-10-13 Thread Oliver Lietz

On Friday 13 October 2017 13:00:53 Ian Boston wrote:
> On 13 October 2017 at 11:16, Robert Munteanu  wrote:
> > Hi Ian,

Hi,

> > On Fri, 2017-10-13 at 10:51 +0100, Ian Boston wrote:
> > > Hi,
> > > I would like to upgrade Sling to depend on Oak 1.7.9 as it was just
> > > released. The patch be the same as [1] with 1.7.8 replaced by 1.7.9.
> > > 
> > > Any objections ?
> > 
> > No objections here.
> > 
> > Related to the pull request - is it required for bundles consuming
> > testing.paxexam to bump up their dependency version?
> 
> If those bundles want to perform integration tests on Oak 1.7.9 then they
> need to bump the dependency.
> Some do, some dont, so I bumped all to make certain all would still build
> on Oak 1.7.9.
> 
> The first one that needs to do a release, will have to release paxexam at
> the same time... and fix the references to the 0.0.5-SNAPSHOT version.
> 
> I assume that was done before since all were on 0.0.4.

no need for a new release of Testing PaxExam (but will do a release soon 
anyway), you can override the version for Oak with the one from POM (was done 
in the past e.g. for Oak Server):

https://github.com/apache/sling/tree/trunk/testing/org.apache.sling.testing.paxexam

Regards,
O.

> Best Regards
> Ian
> 
> > I think they can
> > run their tests just fine on the old dependencies and in case of a
> > release of that module we don't need to wait for a release of
> > testing.paxexam.
> > 
> > I'm looking at
> > 
> > - bundles/commons/contentdetection
> > - bundles/commons/metrics
> > - bundles/extensions/org.apache.sling.resource.presence
> > - bundles/scripting/core
> > - contrib/extensions/rewriter
> > - contrib/extensions/sling
> > - contrib/scripting/freemarker
> > - contrib/scripting/org.apache.sling.scripting.thymeleaf
> > 
> > Thanks,
> > 
> > Robert

[jira] [Updated] (SLING-7198) Duplicated lookup for mapping without subserviceName

2017-10-13 Thread Karl Pauls (JIRA)


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

Karl Pauls updated SLING-7198:
--
Affects Version/s: Service User Mapper 1.3.4

> Duplicated lookup for mapping without subserviceName
> 
>
> Key: SLING-7198
> URL: https://issues.apache.org/jira/browse/SLING-7198
> Project: Sling
>  Issue Type: Bug
>  Components: Service User Mapper
>Affects Versions: Service User Mapper 1.3.4
>Reporter: angela
>Priority: Minor
>
> [~kpauls] If I am not mistaken there is an extra lookup in the following 
> method:
> {code}
> private Iterable internalGetPrincipalNames(final String 
> serviceName, final String subServiceName) {
> log.debug(
> "internalGetPrincipalNames: {} active mappings, looking for 
> mapping for {}/{}",
> new Object[] { this.activeMappings.length, serviceName, 
> subServiceName });
> for (final Mapping mapping : this.activeMappings) {
> final Iterable principalNames = 
> mapping.mapPrincipals(serviceName, subServiceName);
> if (principalNames != null) {
> log.debug("Got principalNames [{}] from {}/{}", new Object[] 
> {principalNames, serviceName, subServiceName });
> return principalNames;
> }
> }
> for (Mapping mapping : this.activeMappings) {
> final Iterable principalNames = 
> mapping.mapPrincipals(serviceName, null);
> if (principalNames != null) {
> log.debug("Got principalNames [{}] from {}/{}", new Object[] 
> {principalNames, serviceName });
> return principalNames;
> }
> }
> // second round without serviceInfo
> log.debug(
> "internalGetPrincipalNames: {} active mappings, looking for 
> mapping for {}/",
> this.activeMappings.length, serviceName);
> for (Mapping mapping : this.activeMappings) {
> final Iterable principalNames = 
> mapping.mapPrincipals(serviceName, null);
> if (principalNames != null) {
> log.debug("Got principalNames [{}] from {}/ subServiceName>", principalNames, serviceName);
> return principalNames;
> }
> }
> log.debug("internalGetPrincipalNames: no mapping found.");
> return null;
> }
> {code}
> If I read the code properly the lookup that is logged by being the 'second 
> round' is actually the third perform once again the lookup without 
> 'subServiceName'. If that is correct I would suggest to remove the following 
> code:
> {code}
> for (Mapping mapping : this.activeMappings) {
> final Iterable principalNames = 
> mapping.mapPrincipals(serviceName, null);
> if (principalNames != null) {
> log.debug("Got principalNames [{}] from {}/{}", new Object[] 
> {principalNames, serviceName });
> return principalNames;
> }
> }
> {code}
> or the third one that is called the second round ;-)
> But please double check to make sure I didn't just overlook some subtle diff 
> :-)



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

Re: Upgrade to Oak 1.7.9

2017-10-13 Thread Oliver Lietz

On Friday 13 October 2017 10:51:31 Ian Boston wrote:
> Hi,

Hi,

> I would like to upgrade Sling to depend on Oak 1.7.9 as it was just
> released. The patch be the same as [1] with 1.7.8 replaced by 1.7.9.
> 
> Any objections ?

I prefer sticking to stable and wait for 1.8.0.

Regards,
O.

> Best Regards
> Ian
> 
> 1 https://github.com/apache/sling/compare/trunk...ieb:
> upgradeToOak178?expand=1

Re: Upgrade to Oak 1.7.9

2017-10-13 Thread Ian Boston

On 13 October 2017 at 11:16, Robert Munteanu  wrote:

> Hi Ian,
>
> On Fri, 2017-10-13 at 10:51 +0100, Ian Boston wrote:
> > Hi,
> > I would like to upgrade Sling to depend on Oak 1.7.9 as it was just
> > released. The patch be the same as [1] with 1.7.8 replaced by 1.7.9.
> >
> > Any objections ?
>
> No objections here.
>
> Related to the pull request - is it required for bundles consuming
> testing.paxexam to bump up their dependency version?



If those bundles want to perform integration tests on Oak 1.7.9 then they
need to bump the dependency.
Some do, some dont, so I bumped all to make certain all would still build
on Oak 1.7.9.

The first one that needs to do a release, will have to release paxexam at
the same time... and fix the references to the 0.0.5-SNAPSHOT version.

I assume that was done before since all were on 0.0.4.

Best Regards
Ian


> I think they can
> run their tests just fine on the old dependencies and in case of a
> release of that module we don't need to wait for a release of
> testing.paxexam.
>
> I'm looking at
>
> - bundles/commons/contentdetection
> - bundles/commons/metrics
> - bundles/extensions/org.apache.sling.resource.presence
> - bundles/scripting/core
> - contrib/extensions/rewriter
> - contrib/extensions/sling
> - contrib/scripting/freemarker
> - contrib/scripting/org.apache.sling.scripting.thymeleaf
>
> Thanks,
>
> Robert
>

[jira] [Created] (SLING-7199) Improve the JcrSystemUserValidatorTest

2017-10-13 Thread Karl Pauls (JIRA)

Karl Pauls created SLING-7199:
-

 Summary: Improve the JcrSystemUserValidatorTest
 Key: SLING-7199
 URL: https://issues.apache.org/jira/browse/SLING-7199
 Project: Sling
  Issue Type: Test
  Components: JCR
Affects Versions: JCR Resource 3.0.4
Reporter: Karl Pauls


[~anchela] added an improved JcrSystemUserValidatorTest along with her patch 
for SLING-7144. However, it doesn't work yet because we are still on 
Jackrabbit. We should make sure we apply her patch when we migrated.



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

[jira] [Resolved] (SLING-7144) JcrSystemUserValidator should identify disabled users as invalid

2017-10-13 Thread Karl Pauls (JIRA)


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

Karl Pauls resolved SLING-7144.
---
Resolution: Fixed

I think we can resolve this issue.  [~anchela], please reopen this issue if I 
messed it up.

> JcrSystemUserValidator should identify disabled users as invalid
> 
>
> Key: SLING-7144
> URL: https://issues.apache.org/jira/browse/SLING-7144
> Project: Sling
>  Issue Type: Bug
>  Components: JCR
>Affects Versions: JCR Resource 3.0.4
>Reporter: angela
>Assignee: Karl Pauls
> Fix For: JCR Resource 3.0.6
>
> Attachments: JcrSystemUserValidatorTest.patch, SLING-7144.patch
>
>
> The {{JcrSystemUserValidator}} verifies that a given service mapping points 
> to an existing, valid system user. However, it doesn't take 
> {{User.isDisabled()}} into account.



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

[jira] [Commented] (SLING-7144) JcrSystemUserValidator should identify disabled users as invalid

2017-10-13 Thread Karl Pauls (JIRA)


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

Karl Pauls commented on SLING-7144:
---

[~anchela], I looked at your patch and I think it makes a lot of sense - thanks 
a lot! I applied it in r1812116. 

However, I don't have the time to look into adjusting RepositoryBaseTest away 
from Jackrabbit in order to make your test work (and probably are the wrong 
person due to lack of knowledge to begin with). But I definitely agree that it 
is a needed test - hence, I create SLING-7199. Hopefully, somebody with more 
knowledge than I can pick it up later. 

Do you need a release of the jcr.resource bundle? 

> JcrSystemUserValidator should identify disabled users as invalid
> 
>
> Key: SLING-7144
> URL: https://issues.apache.org/jira/browse/SLING-7144
> Project: Sling
>  Issue Type: Bug
>  Components: JCR
>Affects Versions: JCR Resource 3.0.4
>Reporter: angela
>Assignee: Karl Pauls
> Fix For: JCR Resource 3.0.6
>
> Attachments: JcrSystemUserValidatorTest.patch, SLING-7144.patch
>
>
> The {{JcrSystemUserValidator}} verifies that a given service mapping points 
> to an existing, valid system user. However, it doesn't take 
> {{User.isDisabled()}} into account.



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

[jira] [Created] (SLING-7198) Duplicated lookup for mapping without subserviceName

2017-10-13 Thread angela (JIRA)

angela created SLING-7198:
-

 Summary: Duplicated lookup for mapping without subserviceName
 Key: SLING-7198
 URL: https://issues.apache.org/jira/browse/SLING-7198
 Project: Sling
  Issue Type: Bug
  Components: Service User Mapper
Reporter: angela
Priority: Minor


[~kpauls] If I am not mistaken there is an extra lookup in the following method:

{code}
private Iterable internalGetPrincipalNames(final String 
serviceName, final String subServiceName) {
log.debug(
"internalGetPrincipalNames: {} active mappings, looking for 
mapping for {}/{}",
new Object[] { this.activeMappings.length, serviceName, 
subServiceName });

for (final Mapping mapping : this.activeMappings) {
final Iterable principalNames = 
mapping.mapPrincipals(serviceName, subServiceName);
if (principalNames != null) {
log.debug("Got principalNames [{}] from {}/{}", new Object[] 
{principalNames, serviceName, subServiceName });
return principalNames;
}
}

for (Mapping mapping : this.activeMappings) {
final Iterable principalNames = 
mapping.mapPrincipals(serviceName, null);
if (principalNames != null) {
log.debug("Got principalNames [{}] from {}/{}", new Object[] 
{principalNames, serviceName });
return principalNames;
}
}

// second round without serviceInfo
log.debug(
"internalGetPrincipalNames: {} active mappings, looking for 
mapping for {}/",
this.activeMappings.length, serviceName);

for (Mapping mapping : this.activeMappings) {
final Iterable principalNames = 
mapping.mapPrincipals(serviceName, null);
if (principalNames != null) {
log.debug("Got principalNames [{}] from {}/", principalNames, serviceName);
return principalNames;
}
}

log.debug("internalGetPrincipalNames: no mapping found.");
return null;
}
{code}

If I read the code properly the lookup that is logged by being the 'second 
round' is actually the third perform once again the lookup without 
'subServiceName'. If that is correct I would suggest to remove the following 
code:

{code}
for (Mapping mapping : this.activeMappings) {
final Iterable principalNames = 
mapping.mapPrincipals(serviceName, null);
if (principalNames != null) {
log.debug("Got principalNames [{}] from {}/{}", new Object[] 
{principalNames, serviceName });
return principalNames;
}
}
{code}

or the third one that is called the second round ;-)

But please double check to make sure I didn't just overlook some subtle diff :-)






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

[jira] [Assigned] (SLING-7144) JcrSystemUserValidator should identify disabled users as invalid

2017-10-13 Thread Karl Pauls (JIRA)


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

Karl Pauls reassigned SLING-7144:
-

Assignee: Karl Pauls

> JcrSystemUserValidator should identify disabled users as invalid
> 
>
> Key: SLING-7144
> URL: https://issues.apache.org/jira/browse/SLING-7144
> Project: Sling
>  Issue Type: Bug
>  Components: JCR
>Affects Versions: JCR Resource 3.0.4
>Reporter: angela
>Assignee: Karl Pauls
> Fix For: JCR Resource 3.0.6
>
> Attachments: JcrSystemUserValidatorTest.patch, SLING-7144.patch
>
>
> The {{JcrSystemUserValidator}} verifies that a given service mapping points 
> to an existing, valid system user. However, it doesn't take 
> {{User.isDisabled()}} into account.



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

Re: Upgrade to Oak 1.7.9

2017-10-13 Thread Robert Munteanu

Hi Ian,

On Fri, 2017-10-13 at 10:51 +0100, Ian Boston wrote:
> Hi,
> I would like to upgrade Sling to depend on Oak 1.7.9 as it was just
> released. The patch be the same as [1] with 1.7.8 replaced by 1.7.9.
> 
> Any objections ?

No objections here.

Related to the pull request - is it required for bundles consuming
testing.paxexam to bump up their dependency version? I think they can
run their tests just fine on the old dependencies and in case of a
release of that module we don't need to wait for a release of
testing.paxexam.

I'm looking at 

- bundles/commons/contentdetection
- bundles/commons/metrics
- bundles/extensions/org.apache.sling.resource.presence
- bundles/scripting/core
- contrib/extensions/rewriter
- contrib/extensions/sling
- contrib/scripting/freemarker
- contrib/scripting/org.apache.sling.scripting.thymeleaf

Thanks,

Robert

Re: Depending on Oak 1.7.x

2017-10-13 Thread Ian Boston

Hi,
My View is that it would be dangerous to depend on 1.11.1 but safe to
depend on 1.11.25 if 1.11.25 was known to be near to the branch to 1.12.x.
The closer to 1.11.1, the greater the risk of instability, the closer to
1.12.x the less the risk.

IIUC Oak have started to discuss the possibility of branching 1.8.x, which
makes 1.7.9 relatively close to that branch. That said, I made an API
change that appeared in 1.7.9 ;). It all depends on the detail in every
case. There are no rules that always work.

Best Regards
Ian



On 12 October 2017 at 16:28, Matt Ryan  wrote:

> Hi,
>
> I’m curious to explore the reasoning behind the general principle of only
> having dependencies on stable Oak releases.  Of course I understand the
> importance of keeping the codebase on a solid foundation and thus to want
> stable releases for dependencies.  My question is, what exactly is meant by
> “stable”?
>
> I expect we regard even-numbered minor versions in Oak as stable releases
> because that’s how the Oak project refers to such releases.  Based on that
> reasoning, Oak 1.7.8 is unstable by definition.  I’d then argue that if Oak
> were to change their versioning model (which I’m not proposing - and I
> wouldn’t propose it here if I was proposing such a thing anyway) such that
> a “stable” Oak release is defined by some other means (say, any version
> that passes the entire test suite), Oak 1.7.10 may be considered stable -
> in which case the concern to rely on that version would be lower.  In other
> words:  If Oak were to declare a version as stable, is that sufficient for
> us to rely on those package versions?  Or would we do our own validation
> anyway?
>
> My point is that it appears the resistance to use a particular Oak version
> is based on Oak not declaring it as stable.  Yet Sling probably depends on
> other packages that have different criteria for being considered stable -
> some which may not even declare a particular version as such.  I don’t have
> concrete knowledge about that of course, just a hunch.
>
> But if that’s the case, perhaps it is worthwhile to consider the reason
> this policy was adopted for Oak packages, and maybe in understanding what
> the real goal is we can find a way where we don’t feel concerned updating
> dependencies to an “unstable” Oak release.  For example, if such a release
> passes all Oak tests and all Sling tests, maybe that’s acceptable.
>
> -MR
>
>
> On October 12, 2017 at 8:34:50 AM, Ian Boston (i...@tfd.co.uk) wrote:
>
> Hi,
> Here is a patch to make Sling work with Oak 1.7.8. Once I fixed a full
> build (just did a pull request) it passes a full IT build. The patch
> updates the paxexam setup so IT tests that uses that will test against Oak
> 1.7.8. I also tested with 1.8-SNAPSHOT so this should be good for anything
> after 1.7.8. We might wait till 1.7.10 comes out as IIUC this will
> include OAK-6575.
>
> wdyt, mege when 1.7.10 is out and upgrade to a stable 1.8 when its cut ?
> Best Regards
> Ian
>
> 1
> https://github.com/apache/sling/compare/trunk...ieb:
> upgradeToOak178?expand=1
>
> On 11 October 2017 at 11:38, Ian Boston  wrote:
>
> >
> >
> > On 11 October 2017 at 11:25, Robert Munteanu 
> wrote:
> >
> >> On Wed, 2017-10-11 at 11:16 +0100, Ian Boston wrote:
> >> > Hi,
> >> > Switching to depend on Oak 1.7 requires upgrading oak-server to use
> >> > 1.7 or
> >> > later.
> >> > There has been some incompatible changes at a bundle level and
> >> > package
> >> > level between 1.6 and 1.7 so its not as simple has changing the
> >> > versions.
> >> > For instance oak-api bundle didnt existi in 1.6 and NodeAggregator
> >> > class
> >> > doesn't appear to exist in 1.7. oak-server wont build without a
> >> > patch.
> >> >
> >> > Obviously, if you have an oak-server or equivalent that already
> >> > depends on
> >> > 1.7 or later, then its trivial, but Sling doesn't.
> >>
> >> So we need need to make oak-server and jcr.resource dependent on Oak
> >> 1.7, right?
> >>
> >
> > Yes, working on a patch now.
> > Compiles but all ITs fail.
> >
> >
> >>
> >> I would guess that oak-server is not such a big issue. Is it possible
> >> to make the dependency from jcr.resource to the newer oak api optional?
> >> If the bundle would also run on Oak 1.6 I guess there would be no
> >> issue.
> >>
> >
> >
> > In the original patch with AdapterFactories that would have been simple
> as
> > it was very loosly coupled for exactly this reason, however that patch
> was
> > rejected by this list, and a much more tightly bound patch[1] was
> > required. Making HelperData, core to Sling GET Servlets, load safely
> with
> > one of its imports optional will be messy and will make its method calls
> > nasty.
> >
> > Best Regards
> > Ian
> >
> > 1 https://github.com/apache/sling/compare/trunk...ieb:OAK-6575-3-2
> >
> >
> >
> >>
> >> Thanks,
> >>
> >> Robert
> >>
> >> > Best Regards
> >> > Ian
> >> >
> >> > On 11 October 2017 at 11:07, Stefan

Re: [NOTICE] Getting ready to start the SVN → Git migration

2017-10-13 Thread Robert Munteanu

On Fri, 2017-10-13 at 09:30 +, Stefan Seifert wrote:
> > > What I see is that when I try to go to
> > > https://lists.apache.org/list.html?us...@infra.apache.org, after
> > > authenticating, I end up on
> > > https://lists.apache.org/list.html?iss...@infra.apache.org
> > 
> > Just to make sure - did you authenticate with your ASF credentials?
> 
> yes, i did!
> (but i did not try to subscribe to the users@ list)
> 
> stefan
> 

I am not sure that is required - I am not subscribed. Maybe it's best
to ask infra :-) ? Quickest I guess woudl be http://infra.chat/ .

Robert

Upgrade to Oak 1.7.9

2017-10-13 Thread Ian Boston

Hi,
I would like to upgrade Sling to depend on Oak 1.7.9 as it was just
released. The patch be the same as [1] with 1.7.8 replaced by 1.7.9.

Any objections ?

Best Regards
Ian

1 https://github.com/apache/sling/compare/trunk...ieb:
upgradeToOak178?expand=1

RE: [NOTICE] Getting ready to start the SVN → Git migration

2017-10-13 Thread Stefan Seifert


>> What I see is that when I try to go to
>> https://lists.apache.org/list.html?us...@infra.apache.org, after
>> authenticating, I end up on
>> https://lists.apache.org/list.html?iss...@infra.apache.org
>
>Just to make sure - did you authenticate with your ASF credentials?

yes, i did!
(but i did not try to subscribe to the users@ list)

stefan

Re: [NOTICE] Getting ready to start the SVN → Git migration

2017-10-13 Thread Robert Munteanu

On Thu, 2017-10-12 at 20:55 +, Justin Edelson wrote:
> On Thu, Oct 12, 2017 at 4:42 PM Stefan Seifert  e>
> wrote:
> 
> > > BTW, not sure what the access rule for users@infra are, but you
> > > should
> > > be able to access https://lists.apache.org/list.html?users@infra.
> > > apache
> > > .org and then log in with your ASF credentials. I think it works
> > > for
> > > committers.
> > 
> > even if i login:
> > i cannot access https://lists.apache.org/list.html?us...@infra.apac
> > he.org
> > i can access https://lists.apache.org/list.html?issues@infra.apache
> > .org
> > 
> > stefan
> > 
> 
> What I see is that when I try to go to
> https://lists.apache.org/list.html?us...@infra.apache.org, after
> authenticating, I end up on
> https://lists.apache.org/list.html?iss...@infra.apache.org

Just to make sure - did you authenticate with your ASF credentials?

I am not sure whether the archive is open just to members or just
committers. Since [1] states that "The infra@ mailing list should be
considered a semipublic list as many Apache committers --- not only
Team members --- are subscribed" I guess it should be open to
committers that are not members.

Thanks,

Robert


[1]: https://www.apache.org/dev/infra-contact

[jira] [Updated] (SLING-7197) API support to get completed Scheduled Job

2017-10-13 Thread Praful Vaishnav (JIRA)


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

Praful Vaishnav updated SLING-7197:
---
Description: Scheuled jobs are created as _slingevent:TimedEvent_ under 
path _/var/eventing/scheduled-jobs_. When these jobs execution are complete, 
they are moved under /var/eventing/jobs/finished. Prior to completion, we can 
get scheduled jobs using [API JobManager.getScheduledJobs|  
https://sling.apache.org/apidocs/sling7/org/apache/sling/event/jobs/JobManager.html#getScheduledJobs-java.lang.String-long-java.util.Map...-
 ]. But I could not find any API to get scheduled jobs which are completed. 
[API JobManager.findJobs| 
https://sling.apache.org/apidocs/sling7/org/apache/sling/event/jobs/JobManager.html#findJobs-org.apache.sling.event.jobs.JobManager.QueryType-java.lang.String-long-java.util.Map...-]
 returns only jobs of type _slingevent:Job_  (was: Scheuled jobs are created as 
_slingevent:TimedEvent_ under path _/var/eventing/scheduled-jobs_. When these 
jobs execution are complete, they are moved under /var/eventing/jobs/finished. 
Prior to completion, we can get scheduled jobs using [this API |  
https://sling.apache.org/apidocs/sling7/org/apache/sling/event/jobs/JobManager.html#getScheduledJobs-java.lang.String-long-java.util.Map...-
 ]. But I could not find any API to get scheduled jobs which are completed. 
[This API | 
https://sling.apache.org/apidocs/sling7/org/apache/sling/event/jobs/JobManager.html#findJobs-org.apache.sling.event.jobs.JobManager.QueryType-java.lang.String-long-java.util.Map...-]
 returns only jobs of type _slingevent:Job_)

> API support to get completed Scheduled Job
> --
>
> Key: SLING-7197
> URL: https://issues.apache.org/jira/browse/SLING-7197
> Project: Sling
>  Issue Type: Bug
>  Components: API
>Affects Versions: Event 4.2.8
>Reporter: Praful Vaishnav
>
> Scheuled jobs are created as _slingevent:TimedEvent_ under path 
> _/var/eventing/scheduled-jobs_. When these jobs execution are complete, they 
> are moved under /var/eventing/jobs/finished. Prior to completion, we can get 
> scheduled jobs using [API JobManager.getScheduledJobs|  
> https://sling.apache.org/apidocs/sling7/org/apache/sling/event/jobs/JobManager.html#getScheduledJobs-java.lang.String-long-java.util.Map...-
>  ]. But I could not find any API to get scheduled jobs which are completed. 
> [API JobManager.findJobs| 
> https://sling.apache.org/apidocs/sling7/org/apache/sling/event/jobs/JobManager.html#findJobs-org.apache.sling.event.jobs.JobManager.QueryType-java.lang.String-long-java.util.Map...-]
>  returns only jobs of type _slingevent:Job_



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

[jira] [Updated] (SLING-7197) API support to get completed Scheduled Job

2017-10-13 Thread Praful Vaishnav (JIRA)


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

Praful Vaishnav updated SLING-7197:
---
Description: Scheuled jobs are created as _slingevent:TimedEvent_ under 
path _/var/eventing/scheduled-jobs_. When these jobs execution are complete, 
they are moved under path `/var/eventing/jobs/finished`. Prior to completion, 
we can get scheduled jobs using [API JobManager.getScheduledJobs|  
https://sling.apache.org/apidocs/sling7/org/apache/sling/event/jobs/JobManager.html#getScheduledJobs-java.lang.String-long-java.util.Map...-
 ]. But I could not find any API to get scheduled jobs which are completed. 
[API JobManager.findJobs| 
https://sling.apache.org/apidocs/sling7/org/apache/sling/event/jobs/JobManager.html#findJobs-org.apache.sling.event.jobs.JobManager.QueryType-java.lang.String-long-java.util.Map...-]
 returns only jobs of type _slingevent:Job_  (was: Scheuled jobs are created as 
_slingevent:TimedEvent_ under path _/var/eventing/scheduled-jobs_. When these 
jobs execution are complete, they are moved under /var/eventing/jobs/finished. 
Prior to completion, we can get scheduled jobs using [API 
JobManager.getScheduledJobs|  
https://sling.apache.org/apidocs/sling7/org/apache/sling/event/jobs/JobManager.html#getScheduledJobs-java.lang.String-long-java.util.Map...-
 ]. But I could not find any API to get scheduled jobs which are completed. 
[API JobManager.findJobs| 
https://sling.apache.org/apidocs/sling7/org/apache/sling/event/jobs/JobManager.html#findJobs-org.apache.sling.event.jobs.JobManager.QueryType-java.lang.String-long-java.util.Map...-]
 returns only jobs of type _slingevent:Job_)

> API support to get completed Scheduled Job
> --
>
> Key: SLING-7197
> URL: https://issues.apache.org/jira/browse/SLING-7197
> Project: Sling
>  Issue Type: Bug
>  Components: API
>Affects Versions: Event 4.2.8
>Reporter: Praful Vaishnav
>
> Scheuled jobs are created as _slingevent:TimedEvent_ under path 
> _/var/eventing/scheduled-jobs_. When these jobs execution are complete, they 
> are moved under path `/var/eventing/jobs/finished`. Prior to completion, we 
> can get scheduled jobs using [API JobManager.getScheduledJobs|  
> https://sling.apache.org/apidocs/sling7/org/apache/sling/event/jobs/JobManager.html#getScheduledJobs-java.lang.String-long-java.util.Map...-
>  ]. But I could not find any API to get scheduled jobs which are completed. 
> [API JobManager.findJobs| 
> https://sling.apache.org/apidocs/sling7/org/apache/sling/event/jobs/JobManager.html#findJobs-org.apache.sling.event.jobs.JobManager.QueryType-java.lang.String-long-java.util.Map...-]
>  returns only jobs of type _slingevent:Job_



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

[jira] [Created] (SLING-7197) API support to get completed Scheduled Job

2017-10-13 Thread Praful Vaishnav (JIRA)

Praful Vaishnav created SLING-7197:
--

 Summary: API support to get completed Scheduled Job
 Key: SLING-7197
 URL: https://issues.apache.org/jira/browse/SLING-7197
 Project: Sling
  Issue Type: Bug
  Components: API
Affects Versions: Event 4.2.8
Reporter: Praful Vaishnav


Scheuled jobs are created as _slingevent:TimedEvent_ under path 
_/var/eventing/scheduled-jobs_. When these jobs execution are complete, they 
are moved under /var/eventing/jobs/finished. Prior to completion, we can get 
scheduled jobs using [this API |  
https://sling.apache.org/apidocs/sling7/org/apache/sling/event/jobs/JobManager.html#getScheduledJobs-java.lang.String-long-java.util.Map...-
 ]. But I could not find any API to get scheduled jobs which are completed. 
[This API | 
https://sling.apache.org/apidocs/sling7/org/apache/sling/event/jobs/JobManager.html#findJobs-org.apache.sling.event.jobs.JobManager.QueryType-java.lang.String-long-java.util.Map...-]
 returns only jobs of type _slingevent:Job_



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

Re: [VOTE] Release Apache Sling Servlet Helpers 1.0.2, Servlet Helpers 1.1.2, JCR Mock 1.3.2, ResourceResolver Mock 1.1.20, OSGi Mock 1.9.8, OSGi Mock 2.3.4, Sling Mock 1.9.10, Sling Mock 2.2.14

2017-10-13 Thread Robert Munteanu

On Thu, 2017-10-12 at 20:33 +, Stefan Seifert wrote:
> Please vote to approve this release:

+1

Robert

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

Re: Upgrade to Oak 1.7.9

[jira] [Commented] (SLING-7185) Content Parser: Support for ISO-8601

Re: Depending on Oak 1.7.x

Re: Depending on Oak 1.7.x

Re: Upgrade to Oak 1.7.9

Re: Depending on Oak 1.7.x

Re: Depending on Oak 1.7.x

Re: [NOTICE] Getting ready to start the SVN → Git migration

Re: Upgrade to Oak 1.7.9

Re: Upgrade to Oak 1.7.9

[jira] [Resolved] (SLING-7198) Duplicated lookup for mapping without subserviceName

[jira] [Assigned] (SLING-7198) Duplicated lookup for mapping without subserviceName

[jira] [Updated] (SLING-7198) Duplicated lookup for mapping without subserviceName

Re: Upgrade to Oak 1.7.9

[jira] [Updated] (SLING-7198) Duplicated lookup for mapping without subserviceName

Re: Upgrade to Oak 1.7.9

Re: Upgrade to Oak 1.7.9

[jira] [Created] (SLING-7199) Improve the JcrSystemUserValidatorTest

[jira] [Resolved] (SLING-7144) JcrSystemUserValidator should identify disabled users as invalid

[jira] [Commented] (SLING-7144) JcrSystemUserValidator should identify disabled users as invalid

[jira] [Created] (SLING-7198) Duplicated lookup for mapping without subserviceName

[jira] [Assigned] (SLING-7144) JcrSystemUserValidator should identify disabled users as invalid

Re: Upgrade to Oak 1.7.9

Re: Depending on Oak 1.7.x

Re: [NOTICE] Getting ready to start the SVN → Git migration

Upgrade to Oak 1.7.9

RE: [NOTICE] Getting ready to start the SVN → Git migration

Re: [NOTICE] Getting ready to start the SVN → Git migration

[jira] [Updated] (SLING-7197) API support to get completed Scheduled Job

[jira] [Updated] (SLING-7197) API support to get completed Scheduled Job

[jira] [Created] (SLING-7197) API support to get completed Scheduled Job

Re: [VOTE] Release Apache Sling Servlet Helpers 1.0.2, Servlet Helpers 1.1.2, JCR Mock 1.3.2, ResourceResolver Mock 1.1.20, OSGi Mock 1.9.8, OSGi Mock 2.3.4, Sling Mock 1.9.10, Sling Mock 2.2.14

32 matches

Site Navigation

Mail list logo

Footer information