You are viewing a plain text version of this content. The canonical link for it is here.
Posted to slide-dev@jakarta.apache.org by Christopher Lenz <cm...@gmx.de> on 2002/04/19 14:06:00 UTC
[VOTE] ContentInterceptor API changes
Jean-Philippe Courson has provided patches and discussion for making the
org.apache.slide.content.ContentInterceptor more usable. As there were never any
implementations of that class (at least none that I'm aware of), usability of
it's API has not been tested in the real world.
Jean-Philippe worked on a UserQuotaContentInterceptor to add support for user-
quotas to Slide, based on the ContentInterceptor API. This usage revealed some
serious shortcomings of the API that we should fix as soon as possible.
As these changes qualify as API changes, I hereby call for a vote to determine
agreement/objections in general, as well as opinions on how far the changes
should go.
Most of the proposed changes have been submitted by Jean-Philippe as patches,
and I've reviewed and partially enhanced these patches, as well as incorporated
them with my local copy, so there are only yes/don't care/no options in this
vote.
[apologies in advance if I've missed some formal conventions on votes]
1. Enable ContentInterceptors to be configured via parameters
[ ] +1. I agree with the change.
[ ] +0. I don't care.
[ ] -1. I don't agree, because:
2. Add a postRemoveContent() method to ContentInterceptor, to be
called when the content of all revisions or one particular
revision of a node has been removed from the namespace
[ ] +1. I agree with the change.
[ ] +0. I don't care.
[ ] -1. I don't agree, because:
3. Allow the preXXX()/postXXX() methods of ContentInterceptor to
throw exceptions, in particular: AccessDeniedException,
ObjectNotFoundException, LinkedObjectNotFoundException,
ObjectLockedException and ServiceAccessException. This is to
allow interceptors to truly intercept content operations, and
to not force implementors to "swallow" important errors.
[ ] +1. I agree with the change.
[ ] +0. I don't care.
[ ] -1. I don't agree, because:
4. Allow ContentInterceptors to access the namespace via a
NamespaceAccessToken to permit operations like logging to the
namespace logger etc.
[ ] +1. I agree with the change.
[ ] +0. I don't care.
[ ] -1. I don't agree, because:
5. Make ContentInterceptor an interface, and provide a basic (mostly
empty) implementation as AbstractContentInterceptor, to make the
API contract clearer. (*)
[ ] +1. I agree with the change.
[ ] +0. I don't care.
[ ] -1. I don't agree, because:
6. To round up the ContentInterceptor interface, also add the methods
preRetrieveContent() and preRemoveContent(), so that all event
types have pre and post hooks. (*)
[ ] +1. I agree with the change.
[ ] +0. I don't care.
[ ] -1. I don't agree, because:
7. Implement the agreed upon changes in the SLIDE_1_0 branch for
the upcoming release 1.1.0, as well as in the HEAD branch.
[ ] +1. I agree with the change.
[ ] +0. I don't care.
[ ] -1. I don't agree, because:
(*) The last two points would qualify as API changes that might not be strictly
necessary at the moment. But as I stated before, if we're changing the API
anyway, we might as well try to get it right. ;-)
-chris
_______________________________________________
/=/ cmlenz at gmx.de
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] ContentInterceptor API changes
Posted by Akileswar <as...@swbell.net>.
I have used the ContentInterceptor to provide a document search service. I
used JP's initial code.
It works great. Currently in the process of integrating it with certain
other pieces. I do need to make adjustments to account for JP's latest
proposals.
Hope this helps
Akil
PS Count me as a +1 on all the points below. Thanks.
----- Original Message -----
From: "Christopher Lenz" <cm...@gmx.de>
To: "Slide Developer Discussion" <sl...@jakarta.apache.org>
Sent: Friday, April 19, 2002 7:06 AM
Subject: [VOTE] ContentInterceptor API changes
> Jean-Philippe Courson has provided patches and discussion for making the
> org.apache.slide.content.ContentInterceptor more usable. As there were
never any
> implementations of that class (at least none that I'm aware of), usability
of
> it's API has not been tested in the real world.
>
> Jean-Philippe worked on a UserQuotaContentInterceptor to add support for
user-
> quotas to Slide, based on the ContentInterceptor API. This usage revealed
some
> serious shortcomings of the API that we should fix as soon as possible.
>
> As these changes qualify as API changes, I hereby call for a vote to
determine
> agreement/objections in general, as well as opinions on how far the
changes
> should go.
>
> Most of the proposed changes have been submitted by Jean-Philippe as
patches,
> and I've reviewed and partially enhanced these patches, as well as
incorporated
> them with my local copy, so there are only yes/don't care/no options in
this
> vote.
>
> [apologies in advance if I've missed some formal conventions on votes]
>
> 1. Enable ContentInterceptors to be configured via parameters
> [ ] +1. I agree with the change.
> [ ] +0. I don't care.
> [ ] -1. I don't agree, because:
>
> 2. Add a postRemoveContent() method to ContentInterceptor, to be
> called when the content of all revisions or one particular
> revision of a node has been removed from the namespace
> [ ] +1. I agree with the change.
> [ ] +0. I don't care.
> [ ] -1. I don't agree, because:
>
> 3. Allow the preXXX()/postXXX() methods of ContentInterceptor to
> throw exceptions, in particular: AccessDeniedException,
> ObjectNotFoundException, LinkedObjectNotFoundException,
> ObjectLockedException and ServiceAccessException. This is to
> allow interceptors to truly intercept content operations, and
> to not force implementors to "swallow" important errors.
> [ ] +1. I agree with the change.
> [ ] +0. I don't care.
> [ ] -1. I don't agree, because:
>
> 4. Allow ContentInterceptors to access the namespace via a
> NamespaceAccessToken to permit operations like logging to the
> namespace logger etc.
> [ ] +1. I agree with the change.
> [ ] +0. I don't care.
> [ ] -1. I don't agree, because:
>
> 5. Make ContentInterceptor an interface, and provide a basic (mostly
> empty) implementation as AbstractContentInterceptor, to make the
> API contract clearer. (*)
> [ ] +1. I agree with the change.
> [ ] +0. I don't care.
> [ ] -1. I don't agree, because:
>
> 6. To round up the ContentInterceptor interface, also add the methods
> preRetrieveContent() and preRemoveContent(), so that all event
> types have pre and post hooks. (*)
> [ ] +1. I agree with the change.
> [ ] +0. I don't care.
> [ ] -1. I don't agree, because:
>
> 7. Implement the agreed upon changes in the SLIDE_1_0 branch for
> the upcoming release 1.1.0, as well as in the HEAD branch.
> [ ] +1. I agree with the change.
> [ ] +0. I don't care.
> [ ] -1. I don't agree, because:
>
> (*) The last two points would qualify as API changes that might not be
strictly
> necessary at the moment. But as I stated before, if we're changing the API
> anyway, we might as well try to get it right. ;-)
>
> -chris
> _______________________________________________
> /=/ cmlenz at gmx.de
>
>
>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[VOTE] Content and ContentInterceptor API changes
Posted by Jean-Philippe Courson <co...@noos.fr>.
I am working on a UserQuotaContentInterceptor to add support for
user-quotas to Slide using ContentInterceptor API.
To be able to achieve this, I need to add to Slide the ability
to notify clients that their quota has been exhausted (507 http
status code).
As Remy suggested, I added InsufficientStorageException to content
package that is thrown by UserQuotaContentInterceptor in such cases.
To integrate my work into Slide, I would need to modify
ContentInterceptor and Content interface to allow some of their methods
to throw this InsufficientStorageException :
For ContentInterceptor interface, methods :
void preStoreContent(SlideToken token,
NodeRevisionDescriptors revisionDescriptors,
NodeRevisionDescriptor revisionDescriptor,
NodeRevisionContent revisionContent)
public void postStoreContent(SlideToken token,
NodeRevisionDescriptors revisionDescriptors,
NodeRevisionDescriptor revisionDescriptor,
NodeRevisionContent revisionContent)
For Content interface, methods :
void create(SlideToken token, String strUri,
NodeRevisionDescriptor revisionDescriptor,
NodeRevisionContent revisionContent)
void create(SlideToken token, String strUri, String branch,
NodeRevisionDescriptor newRevisionDescriptor,
NodeRevisionContent revisionContent)
void fork(SlideToken token, String strUri, String branchName,
NodeRevisionDescriptor basedOnRevisionDescriptor)
void fork(SlideToken token, String strUri, String branchName,
NodeRevisionNumber basedOnRevisionNumber)
void merge(SlideToken token, String strUri,
NodeRevisionDescriptor mainBranch,
NodeRevisionDescriptor branch,
NodeRevisionDescriptor newRevisionDescriptor,
NodeRevisionContent revisionContent)
void merge(SlideToken token, String strUri,
String mainBranch, String branch,
NodeRevisionDescriptor newRevisionDescriptor,
NodeRevisionContent revisionContent)
void store(SlideToken token, String strUri,
NodeRevisionDescriptor revisionDescriptor,
NodeRevisionContent revisionContent)
As I think these changes qualify as API changes, I call for a vote to
determine agreement/objections, both for SLIDE_1_0 and HEAD branches.
I have already written (and tested) patches for these changes on
SLIDE_1_0 branch as well as UserQuotaContentInterceptor.
If you want to have a look on them, you will find them enclosed.
Apologies in advance if I've missed some formal conventions on votes.
1. Add InsufficientStorageException to content package.
[ ] +1. I agree with the change.
[ ] +0. I don't care.
[ ] -1. I don't agree, because:
2. Allow the above stated methods of ContentInterceptor interface to
throw InsufficientStorageException into HEAD branch.
[ ] +1. I agree with the change.
[ ] +0. I don't care.
[ ] -1. I don't agree, because:
3. Allow the above stated methods of Content interface to throw
InsufficientStorageException into HEAD branch.
[ ] +1. I agree with the change.
[ ] +0. I don't care.
[ ] -1. I don't agree, because:
4. Allow the above stated methods of ContentInterceptor interface to
throw InsufficientStorageException into SLIDE_1_0 branch.
[ ] +1. I agree with the change.
[ ] +0. I don't care.
[ ] -1. I don't agree, because:
5. Allow the above stated methods of Content interface to throw
InsufficientStorageException into SLIDE_1_0 branch.
[ ] +1. I agree with the change.
[ ] +0. I don't care.
[ ] -1. I don't agree, because:
Regards
Jp
Re: [VOTE] ContentInterceptor API changes
Posted by Remy Maucherat <re...@apache.org>.
> Jean-Philippe Courson has provided patches and discussion for making the
> org.apache.slide.content.ContentInterceptor more usable. As there were
never any
> implementations of that class (at least none that I'm aware of), usability
of
> it's API has not been tested in the real world.
>
> Jean-Philippe worked on a UserQuotaContentInterceptor to add support for
user-
> quotas to Slide, based on the ContentInterceptor API. This usage revealed
some
> serious shortcomings of the API that we should fix as soon as possible.
>
> As these changes qualify as API changes, I hereby call for a vote to
determine
> agreement/objections in general, as well as opinions on how far the
changes
> should go.
>
> Most of the proposed changes have been submitted by Jean-Philippe as
patches,
> and I've reviewed and partially enhanced these patches, as well as
incorporated
> them with my local copy, so there are only yes/don't care/no options in
this
> vote.
>
> [apologies in advance if I've missed some formal conventions on votes]
>
> 1. Enable ContentInterceptors to be configured via parameters
> [X] +1. I agree with the change.
> [ ] +0. I don't care.
> [ ] -1. I don't agree, because:
(obviously)
> 2. Add a postRemoveContent() method to ContentInterceptor, to be
> called when the content of all revisions or one particular
> revision of a node has been removed from the namespace
> [X] +1. I agree with the change.
> [ ] +0. I don't care.
> [ ] -1. I don't agree, because:
> 3. Allow the preXXX()/postXXX() methods of ContentInterceptor to
> throw exceptions, in particular: AccessDeniedException,
> ObjectNotFoundException, LinkedObjectNotFoundException,
> ObjectLockedException and ServiceAccessException. This is to
> allow interceptors to truly intercept content operations, and
> to not force implementors to "swallow" important errors.
> [X] +1. I agree with the change.
> [ ] +0. I don't care.
> [ ] -1. I don't agree, because:
>
> 4. Allow ContentInterceptors to access the namespace via a
> NamespaceAccessToken to permit operations like logging to the
> namespace logger etc.
> [X] +1. I agree with the change.
> [ ] +0. I don't care.
> [ ] -1. I don't agree, because:
There's the possibility of abusing this feature, though.
> 5. Make ContentInterceptor an interface, and provide a basic (mostly
> empty) implementation as AbstractContentInterceptor, to make the
> API contract clearer. (*)
> [X] +1. I agree with the change.
> [ ] +0. I don't care.
> [ ] -1. I don't agree, because:
>
> 6. To round up the ContentInterceptor interface, also add the methods
> preRetrieveContent() and preRemoveContent(), so that all event
> types have pre and post hooks. (*)
> [X] +1. I agree with the change.
> [ ] +0. I don't care.
> [ ] -1. I don't agree, because:
>
> 7. Implement the agreed upon changes in the SLIDE_1_0 branch for
> the upcoming release 1.1.0, as well as in the HEAD branch.
> [X] +1. I agree with the change.
> [ ] +0. I don't care.
> [ ] -1. I don't agree, because:
>
> (*) The last two points would qualify as API changes that might not be
strictly
> necessary at the moment. But as I stated before, if we're changing the API
> anyway, we might as well try to get it right. ;-)
Yes, I agree.
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>