You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "Felix Meschberger (JIRA)" <ji...@apache.org> on 2007/10/18 13:43:51 UTC
[jira] Updated: (SLING-67) Provide extensible default Servlets
[ https://issues.apache.org/jira/browse/SLING-67?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Felix Meschberger updated SLING-67:
-----------------------------------
Attachment: SLING-67.patch
Proposed SlingGetServlet and GenericSlingServlet
> Provide extensible default Servlets
> -----------------------------------
>
> Key: SLING-67
> URL: https://issues.apache.org/jira/browse/SLING-67
> Project: Sling
> Issue Type: New Feature
> Components: microsling
> Reporter: Felix Meschberger
> Fix For: 2.0.0
>
> Attachments: SLING-67.patch
>
>
> microsling has the SlingServlet and the AbstractSlingServlet which define a new API better exposing the fact, that HTTP methods should map to Java Methods. At the same time there is a clear path towards making this extensible. The drawback of the current implementation is, that the dispatching by HTTP method name happens in the MicroSlingServlet and is limited to the core HTTP methods. So adding support for more HTTP methods is not actually easily doable.
> I propose to replace the SlingServlet and AbstractSlingServlet by a SlingGetServlet (extends GenericServlet) and a GenericSlingServlet (extends SlingGetServlet).
> The SlingGetServlet incorporates support for the GET, HEAD, OPTIONS and TRACE methods and is intended for read-only applications. It may easily be extended to add support for more HTTP methods. While there can be no technical barrier here, we intend this class to be extended only with support for reader methods.
> The GenericSlingServlet extends the SlingGetServlet and adds support for the POST, PUT and DELETE methods and may also be extended with support for more HTTP methods. This class now is intended to also be extended with data modification methods.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Updated: (SLING-67) Provide extensible default Servlets
Posted by Felix Meschberger <fm...@gmail.com>.
Hi Betrand,
Am Freitag, den 19.10.2007, 09:05 +0200 schrieb Bertrand Delacretaz:
> As you note, that sounds a bit funny...thinking In HTTP terms, those
> servlets could also be called SlingSafeMethodsServlet and
> SlingAllMethodsServlet.
Good thing. Will use these names.
Regards
Felix
Re: [jira] Updated: (SLING-67) Provide extensible default Servlets
Posted by Bertrand Delacretaz <bd...@apache.org>.
On 10/18/07, Felix Meschberger <fm...@gmail.com> wrote:
> ...Bertrand Delacretaz:
> > 2) For names I'd prefer SlingGetServlet (or maybe
> > SlingReadonlyServlet?) and SlingFullServlet, to better express the
> > relationship between them.
>
> Or SlingReadWriteServlet :-) ?
As you note, that sounds a bit funny...thinking In HTTP terms, those
servlets could also be called SlingSafeMethodsServlet and
SlingAllMethodsServlet.
The names are a bit long, but they might prompt people to ask "what's
a safe method" which is a Good Question if one doesn't know about
that.
-Bertrand
Re: [jira] Updated: (SLING-67) Provide extensible default Servlets
Posted by Felix Meschberger <fm...@gmail.com>.
Am Donnerstag, den 18.10.2007, 16:26 +0200 schrieb Bertrand Delacretaz:
> On 10/18/07, Felix Meschberger (JIRA) <ji...@apache.org> wrote:
>
> > ...Attachment: SLING-67.patch
> > Proposed SlingGetServlet and GenericSlingServlet...
>
> I like the idea, and the patch looks good to me, with a few
> (hmmm...say "some" ;-) suggestions:
:-)
> 1) I think we should rename the "etc" package to "helpers" to be
> consistent with existing "helpers" packages. Those new classes would
> then go to microsling.helpers.servlets
Of course, I just placed them at the same location where the current
AbstractSlingServlet is.
> 2) For names I'd prefer SlingGetServlet (or maybe
> SlingReadonlyServlet?) and SlingFullServlet, to better express the
> relationship between them.
Or SlingReadWriteServlet :-) ?
In fact GenericSlingServlet sounds similar as GenericServlet, which is
why I chose that name and SlingGetServlet is mainly used for the GET
method, which is the reason for that name. But I am not linked into
these names ...
> 3) Can we keep the HTTP method names constants in the HttpConstants
> interface? Or maybe keep them there, but make HttpConstants a class
> and use static imports to access the constants. I think they are
> general constants, not specific to these servlets
Sure, no problem.
> 4) Using method names like doHttpGET, doHttpPOST would avoid having to
> map names in getAllowedRequestMethods: if we have a public doHttpXXX
> method with the expected signature, HTTP method XXX is available, and
> this can be found doing just a substring() on the java method name.
Have to think more on that :-)
> 5) To me, the mayService() method name does not imply that the request
> is actually serviced by the method, I'd use maybeService() instead.
I though about this. maybeService is ok for me, too.
> 6) Could we use more concise javadocs when most or all methods have
> the exact same signature and semantics? IMHO the class comments could
> explain how doXXX methods work, and the doXXX methods could have just
> a very short comment. That would make the whole thing more readable,
> again IMHO.
well... :-)
>
> Phew...lots of remarks ;-)
That's ok.
Regards
Felix
Re: [jira] Updated: (SLING-67) Provide extensible default Servlets
Posted by Bertrand Delacretaz <bd...@apache.org>.
On 10/18/07, Felix Meschberger (JIRA) <ji...@apache.org> wrote:
> ...Attachment: SLING-67.patch
> Proposed SlingGetServlet and GenericSlingServlet...
I like the idea, and the patch looks good to me, with a few
(hmmm...say "some" ;-) suggestions:
1) I think we should rename the "etc" package to "helpers" to be
consistent with existing "helpers" packages. Those new classes would
then go to microsling.helpers.servlets
2) For names I'd prefer SlingGetServlet (or maybe
SlingReadonlyServlet?) and SlingFullServlet, to better express the
relationship between them.
3) Can we keep the HTTP method names constants in the HttpConstants
interface? Or maybe keep them there, but make HttpConstants a class
and use static imports to access the constants. I think they are
general constants, not specific to these servlets
4) Using method names like doHttpGET, doHttpPOST would avoid having to
map names in getAllowedRequestMethods: if we have a public doHttpXXX
method with the expected signature, HTTP method XXX is available, and
this can be found doing just a substring() on the java method name.
5) To me, the mayService() method name does not imply that the request
is actually serviced by the method, I'd use maybeService() instead.
6) Could we use more concise javadocs when most or all methods have
the exact same signature and semantics? IMHO the class comments could
explain how doXXX methods work, and the doXXX methods could have just
a very short comment. That would make the whole thing more readable,
again IMHO.
Phew...lots of remarks ;-)
Several of my remarks have to do with keeping the "important"
microsling code as small as possible, and separating "interesting"
code from "boring" stuff. To me these are important goals of
microsling - but of course balancing this with the required power is
hard to achieve.
-Bertrand