You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Justin Edelson <ju...@gmail.com> on 2010/07/08 23:57:19 UTC
closing out remaining API 2.1.0 issues
I'd like to see us start the Sling 6 release train soon, even if we
haven't nailed down the final Launchpad contents (chiefly the discussion
about httpauth vs. formauth needs to be nailed down).
IMHO, we need to start with API 2.1.0. Looking at JIRA, there are just a
few outstanding issues:
Issues which appear to resolved:
SLING-1566 - adding ResourceResolver.isLive()
SLING-1262 - implementing ResourceResolverFactory
Issues for which patches are available:
SLING-1575 - moving auth API to Sling API (Felix to apply?)
SLING-1521 - removing license header from HtmlResponse (is the RAT
exclusion OK?)
Assuming these can be resolved, that only leaves SLING-1193 as targetted
at API 2.1.0 and not resolved.
Justin
Re: closing out remaining API 2.1.0 issues
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Sorry for the vacation induced delay ;-)
I will apply the proposed changes for SLING-1575.
As for SLING-1193: Yes I have the patch ready and will apply it.
As for Mike's reference to SLING-1593: I think this is not relevant for
the Sling API but still probably is important for the Commons Auth 1.0
release.
Regards
Felix
On 08.07.2010 23:57, Justin Edelson wrote:
> I'd like to see us start the Sling 6 release train soon, even if we
> haven't nailed down the final Launchpad contents (chiefly the discussion
> about httpauth vs. formauth needs to be nailed down).
>
> IMHO, we need to start with API 2.1.0. Looking at JIRA, there are just a
> few outstanding issues:
>
> Issues which appear to resolved:
> SLING-1566 - adding ResourceResolver.isLive()
> SLING-1262 - implementing ResourceResolverFactory
>
> Issues for which patches are available:
> SLING-1575 - moving auth API to Sling API (Felix to apply?)
> SLING-1521 - removing license header from HtmlResponse (is the RAT
> exclusion OK?)
>
> Assuming these can be resolved, that only leaves SLING-1193 as targetted
> at API 2.1.0 and not resolved.
>
> Justin
>
Re: closing out remaining API 2.1.0 issues
Posted by Carsten Ziegeler <cz...@apache.org>.
>
> Great. Do you agree that SLING-1262 can be marked as resolved?
Yes, I just resolved it.
Carsten
>>
>> Regards
>> Carsten
>> --
>> Carsten Ziegeler
>> cziegeler@apache.org
>
--
Carsten Ziegeler
cziegeler@apache.org
Re: closing out remaining API 2.1.0 issues
Posted by Justin Edelson <ju...@gmail.com>.
On Jul 9, 2010, at 7:56 AM, Carsten Ziegeler <cz...@apache.org> wrote:
> Justin Edelson wrote
>> I'd like to see us start the Sling 6 release train soon, even if we
>> haven't nailed down the final Launchpad contents (chiefly the discussion
>> about httpauth vs. formauth needs to be nailed down).
>>
>> IMHO, we need to start with API 2.1.0. Looking at JIRA, there are just a
>> few outstanding issues:
>>
>> Issues which appear to resolved:
>> SLING-1566 - adding ResourceResolver.isLive()
>> SLING-1262 - implementing ResourceResolverFactory
>>
>> Issues for which patches are available:
>> SLING-1575 - moving auth API to Sling API (Felix to apply?)
>> SLING-1521 - removing license header from HtmlResponse (is the RAT
>> exclusion OK?)
>>
>> Assuming these can be resolved, that only leaves SLING-1193 as targetted
>> at API 2.1.0 and not resolved.
>>
> I completly agree that we should try to get the API finished. I think we
> should include SLING-1193. I think Felix has already a patch for this -
> if not I can do that.
Great. Do you agree that SLING-1262 can be marked as resolved?
>
> Regards
> Carsten
> --
> Carsten Ziegeler
> cziegeler@apache.org
Re: closing out remaining API 2.1.0 issues
Posted by Carsten Ziegeler <cz...@apache.org>.
Justin Edelson wrote
> I'd like to see us start the Sling 6 release train soon, even if we
> haven't nailed down the final Launchpad contents (chiefly the discussion
> about httpauth vs. formauth needs to be nailed down).
>
> IMHO, we need to start with API 2.1.0. Looking at JIRA, there are just a
> few outstanding issues:
>
> Issues which appear to resolved:
> SLING-1566 - adding ResourceResolver.isLive()
> SLING-1262 - implementing ResourceResolverFactory
>
> Issues for which patches are available:
> SLING-1575 - moving auth API to Sling API (Felix to apply?)
> SLING-1521 - removing license header from HtmlResponse (is the RAT
> exclusion OK?)
>
> Assuming these can be resolved, that only leaves SLING-1193 as targetted
> at API 2.1.0 and not resolved.
>
I completly agree that we should try to get the API finished. I think we
should include SLING-1193. I think Felix has already a patch for this -
if not I can do that.
Regards
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: closing out remaining API 2.1.0 issues
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
On 29.07.2010 10:39, Bertrand Delacretaz wrote:
> On Thu, Jul 29, 2010 at 8:45 AM, Carsten Ziegeler <cz...@apache.org> wrote:
>> ...I think the AuthenticationInfo is something which might move to the
>> Sling API - when using the ResourceResolverFactory to get a resolver, it
>> would be a little bit nicer to be able to use the AuthenticationInfo
>> class instead of a plain map (for using the constructors and the constants)...
>
> +1 to that, I'm also using that interface in [1] and having to depend
> on org.apache.sling.commons.auth just for this feels wrong.
But having the AuthenticationInfo as a request attribute feels even
wronger. Which is why I reopened SLING-1445.
> [1] http://svn.apache.org/repos/asf/sling/trunk/contrib/extensions/bgservlets/src/main/java/org/apache/sling/bgservlets/impl/BackgroundRequestExecutionJob.java
You could also use something like ResourceResolver.clone(), right ?
Regards
Felix
Re: closing out remaining API 2.1.0 issues
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Thu, Jul 29, 2010 at 8:45 AM, Carsten Ziegeler <cz...@apache.org> wrote:
> ...I think the AuthenticationInfo is something which might move to the
> Sling API - when using the ResourceResolverFactory to get a resolver, it
> would be a little bit nicer to be able to use the AuthenticationInfo
> class instead of a plain map (for using the constructors and the constants)...
+1 to that, I'm also using that interface in [1] and having to depend
on org.apache.sling.commons.auth just for this feels wrong.
-Bertrand
[1] http://svn.apache.org/repos/asf/sling/trunk/contrib/extensions/bgservlets/src/main/java/org/apache/sling/bgservlets/impl/BackgroundRequestExecutionJob.java
Re: closing out remaining API 2.1.0 issues
Posted by Carsten Ziegeler <cz...@apache.org>.
Felix Meschberger wrote
>
> Agreed for the constants: How about moving them to the API ?
>
> Why is using the AuthenticationInfo constructor more elegant than using
> the Map constructor and setting a property. And where would such a thing
> be used ?
>
Yes, I think the constants USER, PASSWORD should be enough to be moved.
We could just add them to the ResourceResolverFactory.
We should move the CREDENTIALS constant to the JcrResourceConstants
class as these constant is only relevant for a jcr backed resource
resolver. We can then remove the credentials class check as well.
We should also move the commons auth module out of commons as this
module now depends on Sling API and therefore does not meet the criteria
for commons :)
Regards
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: closing out remaining API 2.1.0 issues
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
On 29.07.2010 08:45, Carsten Ziegeler wrote:
> Felix Meschberger wrote
>> Hi,
>>
>> It took me some time to complete, but here we are...
>>
>> I have finished SLING-1193 (Resource API extension) and SLING-1575
>> (moving Authenticator interface to Sling API).
>>
> Great, thanks for the work Felix!
>
>> I think this finishes all open tasks for Sling 2.1.0. Looking back at
>> what we did, this looks like the biggest extension to API since 2.0 ;-)
>>
>> Before cutting a release, lets wait few days for people to review the API.
>>
> Ok, here we go :)
>
> I think the AuthenticationInfo is something which might move to the
> Sling API - when using the ResourceResolverFactory to get a resolver, it
> would be a little bit nicer to be able to use the AuthenticationInfo
> class instead of a plain map (for using the constructors and the constants).
Agreed for the constants: How about moving them to the API ?
Why is using the AuthenticationInfo constructor more elegant than using
the Map constructor and setting a property. And where would such a thing
be used ?
>
> I can't remember our old discussions in detail, but I thought we move
> the api part (including the spi) from the auth module to the Sling api
> module and just leave the implementation in the auth module.
> So basically the problematic part is the auth module which contains api
> and impl.
> The urge to change this is not that high as it only affects people using
> the Sling API without the Auth module, but still it would be nice :)
My point was, that the SPI part of the Commons Auth API is more tied to
how the Commons Auth bundle implements the org.apache.sling.api.auth
API. As such it is of no interest to most Sling Application developers.
Regards
Felix
>
> Regards
> Carsten
Re: closing out remaining API 2.1.0 issues
Posted by Carsten Ziegeler <cz...@apache.org>.
Felix Meschberger wrote
> Hi,
>
> It took me some time to complete, but here we are...
>
> I have finished SLING-1193 (Resource API extension) and SLING-1575
> (moving Authenticator interface to Sling API).
>
Great, thanks for the work Felix!
> I think this finishes all open tasks for Sling 2.1.0. Looking back at
> what we did, this looks like the biggest extension to API since 2.0 ;-)
>
> Before cutting a release, lets wait few days for people to review the API.
>
Ok, here we go :)
I think the AuthenticationInfo is something which might move to the
Sling API - when using the ResourceResolverFactory to get a resolver, it
would be a little bit nicer to be able to use the AuthenticationInfo
class instead of a plain map (for using the constructors and the constants).
I can't remember our old discussions in detail, but I thought we move
the api part (including the spi) from the auth module to the Sling api
module and just leave the implementation in the auth module.
So basically the problematic part is the auth module which contains api
and impl.
The urge to change this is not that high as it only affects people using
the Sling API without the Auth module, but still it would be nice :)
Regards
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: closing out remaining API 2.1.0 issues
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
It took me some time to complete, but here we are...
I have finished SLING-1193 (Resource API extension) and SLING-1575
(moving Authenticator interface to Sling API).
I think this finishes all open tasks for Sling 2.1.0. Looking back at
what we did, this looks like the biggest extension to API since 2.0 ;-)
Before cutting a release, lets wait few days for people to review the API.
Regards
Felix
On 08.07.2010 23:57, Justin Edelson wrote:
> I'd like to see us start the Sling 6 release train soon, even if we
> haven't nailed down the final Launchpad contents (chiefly the discussion
> about httpauth vs. formauth needs to be nailed down).
>
> IMHO, we need to start with API 2.1.0. Looking at JIRA, there are just a
> few outstanding issues:
>
> Issues which appear to resolved:
> SLING-1566 - adding ResourceResolver.isLive()
> SLING-1262 - implementing ResourceResolverFactory
>
> Issues for which patches are available:
> SLING-1575 - moving auth API to Sling API (Felix to apply?)
> SLING-1521 - removing license header from HtmlResponse (is the RAT
> exclusion OK?)
>
> Assuming these can be resolved, that only leaves SLING-1193 as targetted
> at API 2.1.0 and not resolved.
>
> Justin
>
RE: closing out remaining API 2.1.0 issues
Posted by Mike Müller <mi...@mysign.ch>.
> I'd like to see us start the Sling 6 release train soon, even if we
> haven't nailed down the final Launchpad contents (chiefly the
> discussion
> about httpauth vs. formauth needs to be nailed down).
>
> IMHO, we need to start with API 2.1.0. Looking at JIRA, there
> are just a
> few outstanding issues:
>
> Issues which appear to resolved:
> SLING-1566 - adding ResourceResolver.isLive()
> SLING-1262 - implementing ResourceResolverFactory
>
> Issues for which patches are available:
> SLING-1575 - moving auth API to Sling API (Felix to apply?)
> SLING-1521 - removing license header from HtmlResponse (is the RAT
> exclusion OK?)
>
> Assuming these can be resolved, that only leaves SLING-1193
> as targetted
> at API 2.1.0 and not resolved.
>
> Justin
As discussed at [1] we should include the decoupling of the
authentication mechanism from the JCR, which I know filed as
a new issue under [2]. Because we're changing the API with
SLING-1575 I think we should come up with a new API which
solves all the known issues. Otherwise we're forced to change
the API once again the next release which can turn into work
for users of Sling.
WDYT?
best regards
mike
[1] http://markmail.org/message/aovh7lll4w6uwepv
[2] https://issues.apache.org/jira/browse/SLING-1593