[jira] Updated: (SLING-68) Compile fails for sling-sample due to missing dependencies

[Lars Trieloff (JIRA)]

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

Lars Trieloff updated SLING-68:
---

Attachment: sling-sample-logging-dependency.patch

This patch adds the sling-log bundle as a compile time dependency and fixes the 
compilation issue.

> Compile fails for sling-sample due to missing dependencies
> --
>
> Key: SLING-68
> URL: https://issues.apache.org/jira/browse/SLING-68
> Project: Sling
>  Issue Type: Bug
> Environment: Mac OS X, Java 1.5, Maven 2.0.7
>Reporter: Lars Trieloff
>Priority: Minor
> Attachments: sling-sample-logging-dependency.patch
>
>
> The JSP refers to slf4j, which is available at runtime in the container, but 
> not at compile time. This leads to compilation problems.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (SLING-68) Compile fails for sling-sample due to missing dependencies

[Lars Trieloff (JIRA)]

Compile fails for sling-sample due to missing dependencies
--

 Key: SLING-68
 URL: https://issues.apache.org/jira/browse/SLING-68
 Project: Sling
  Issue Type: Bug
 Environment: Mac OS X, Java 1.5, Maven 2.0.7
Reporter: Lars Trieloff
Priority: Minor


The JSP refers to slf4j, which is available at runtime in the container, but 
not at compile time. This leads to compilation problems.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: microsling user feedback

[Tobias Bocanegra]

> conceptual stuff:
>
> - I was wondering how I can have several templates for one content type. I
> could work around this issue in my very simple case, but how can I have e.g.
> an edit template and a view template for a blog entry (depending on some
> request parameter or so)?

you would add a 'selector' for different views of the same content.
eg:
/content/blog/entry1.html for view and
/content/glob/entry1.edit.html for editing

> Related to this: how can I render node X when node Y is requested? In my
> case: I got a blog entry (node Y) that has several comments (nodes X) that I
> want to display on the same page. In Ruby on Rails there is the concept of
> partial templates and I was expecting something similar. I understand that I
> can traverse the JCR and grab the corresponding nodes (which I did) but in
> that case I need to copy template code (re partial templates: the idea is
> basically that an object exposes different methods to render itself. In the
> contect of sling this idea of might clash with sling's concept of pluggable
> presentation scripting engines, though. If so, I'd prefer microsling to be
> opinionated,
> i.e. decide on one scripting engine).
you just iterate over the child content and call  or
whatever the aequivalent in microsling is. we need to elaborate this.

> - the content templates reside in the repository (i.e . on a WebDAV drive in
> my case). However, static html pages need to reside in the war file. In my
> use case this was especially weird, because the comment input forms were in
> the repository (because they are located on the blog entry renderer page)
> where as the "create new blog entry" form was in the war file. I would
> prefer if I could put all my templates and static content in the repository.
usually you would put the 'static' content, in a 'docroot' node as
nt:files and let the
default nt:file script spool them to the client.

> - I was wondering how I can use the repository authentication and
> authorization mechanisms for my app. Could someone give me a pointer,
> please?
this would be the job of the authentication filter / or sling service
and shoud not be of the primary concern of the user (developer).

regards, toby

ps: thanks for summarizing this questions. i think this is a good
starting point for a wiki/faq for [micro]sling.

-- 
-< [EMAIL PROTECTED] >---
Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
T +41 61 226 98 98, F +41 61 226 98 97
---< http://www.day.com >---

[jira] Resolved: (SLING-55) microsling: add ServiceLocator?

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz resolved SLING-55.
--

Resolution: Fixed

Fixed in revisions 586028 and 586029, the ServiceLocator is currently used only 
to access the ResourceResolver.

That's overkill, as in microsling we don't provide a way to use a different 
service, but again the idea is to expose the ServiceLocator in the API, so that 
people aren't surprised when they see it in Sling OSGi.

> microsling: add ServiceLocator?
> ---
>
> Key: SLING-55
> URL: https://issues.apache.org/jira/browse/SLING-55
> Project: Sling
>  Issue Type: Improvement
>  Components: microsling
>Reporter: Bertrand Delacretaz
>
> It might be good to introduce the ServiceLocator interface in microsling. 
> That interface should probably be part of the Sling core API anyway.
> We don't need it right now in microsling, but as soon as there's a good 
> reason to have it (like the OCM maybe) I think we should introduce it, even 
> if it's with a naive implementation, as it's an important part of the power 
> of Sling OSGi.
> Here's the Sling interface:
> public interface ServiceLocator {
> /** The name of the request attribute holding the service locator. */
> String REQUEST_ATTRIBUTE_NAME = "org.apache.sling.core.ServiceLocator";
> /**
>  * Lookup and return the service from the service registry.
>  *
>  * @param serviceName The name (interface) of the service.
>  * @return The service object or null if the service is not available.
>  */
> Object getService(String serviceName);
> /**
>  * Lookup and return the services from the service registry.
>  *
>  * @param serviceName The name (interface) of the service.
>  * @param filter An optional filter
>  * @return The services object or null.
>  */
> Object[] getService(String serviceName, String filter)
> throws InvalidSyntaxException;
> }

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

microsling user feedback

[Michael Marth]

Hi,

Bertrand has asked me to give some user feedback on microsling on this list.
I have been playing with microsling for just one day now and did not have a
look at (full) sling, yet, but from my very limited understanding so far the
issues I found should apply to sling as well.

First of all, I very much like the idea of having a simple, lightweight
framework for creating web apps on top of JCRs. microsling seems to go in
the right direction. I like it.

Some problems I had on the way (my use case was a blogging app):

conceptual stuff:

- I was wondering how I can have several templates for one content type. I
could work around this issue in my very simple case, but how can I have e.g.
an edit template and a view template for a blog entry (depending on some
request parameter or so)?

Related to this: how can I render node X when node Y is requested? In my
case: I got a blog entry (node Y) that has several comments (nodes X) that I
want to display on the same page. In Ruby on Rails there is the concept of
partial templates and I was expecting something similar. I understand that I
can traverse the JCR and grab the corresponding nodes (which I did) but in
that case I need to copy template code (re partial templates: the idea is
basically that an object exposes different methods to render itself. In the
contect of sling this idea of might clash with sling's concept of pluggable
presentation scripting engines, though. If so, I'd prefer microsling to be
opinionated,
i.e. decide on one scripting engine).

- the content templates reside in the repository (i.e . on a WebDAV drive in
my case). However, static html pages need to reside in the war file. In my
use case this was especially weird, because the comment input forms were in
the repository (because they are located on the blog entry renderer page)
where as the "create new blog entry" form was in the war file. I would
prefer if I could put all my templates and static content in the repository.


- it seems to me that content I want to render needs to have the property
"slingResourceType" (is that really correct?). Not a big problem for new web
apps, but really a bit intrusive. I mean, the presentation app shouldnt
require changes on the content.

Some other feedback:

- the SlingPostServlet should provide some mechanism to a) let the user set
the name of the node to be created (I take it that's obvious anyway) and b)
set the node type and mixins. Maybe similar to the "slingResourceType"
mechanism?

- I was wondering how I can use the repository authentication and
authorization mechanisms for my app. Could someone give me a pointer,
please?

Cheers
Michael

Re: ResourceResolver and Resource

[Bertrand Delacretaz]

On 10/18/07, Felix Meschberger <[EMAIL PROTECTED]> wrote:

> ...Well, thinking along these lines: Why do we need a Resource and
> ResourceResolver in the first place then ? ...

Technically, as we're limiting ourselves to JCR content, we don't
really need a Resource, you're right.

But currently the Resource does abstract the fact that a Node might be
mapped to an Object or not. The fact that the Resource interface is
small doesn't make it useless: it makes it beautiful ;-)

OTOH we *do* need the ResourceResolver interface very much: it
encapsulates our "rules" for finding a Resource that the current
request must process.

> ...Honestly, if we abstract the Resource, we also have to take the next
> step and abstract access to relative Resources and children

I might agree about the relative resources, but why the children? And
why just the children axis and not the full
ancestors/descendants/siblings/next/previous axes?

If navigation between Resources is needed and that cannot be covered
by JCR, I'd suggest making that a separate ResourceHierarchyNavigation
interface.

-Bertrand

Re: microsling: ResourceResolver interface and SLING-60

[Bertrand Delacretaz]

On 10/18/07, Tobias Bocanegra <[EMAIL PROTECTED]> wrote:

> ...what about a:
>
> interface ResolvedResource extends Resource {
>public String getResolutionPath();
> }

Even simpler, we weren't really using Resource.getURI until now, so I
simply changed its comment, and will use it instead:

/** The canonical URI that the ResourceResolver used to load this
 *  Resource. As microsling currently access content over JCR only,
 *  URIs without a prefix indicate a JCR path in our Repository.
 *  Microsling uses "/content/xyz" for this URI instead of
"jcr:///content/xyz",
 *  for example.
 */
String getURI();

-Bertrand

Re: [jira] Updated: (SLING-67) Provide extensible default Servlets

[Felix Meschberger]

Am Donnerstag, den 18.10.2007, 16:26 +0200 schrieb Bertrand Delacretaz:
> On 10/18/07, Felix Meschberger (JIRA) <[EMAIL PROTECTED]> 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

[jira] Updated: (SLING-60) SlingRequestPathInfo values must depend on path used by ResourceResolver

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz updated SLING-60:
-

Summary: SlingRequestPathInfo values must depend on path used by 
ResourceResolver  (was: URI path split is content dependent)

> SlingRequestPathInfo values must depend on path used by ResourceResolver
> 
>
> Key: SLING-60
> URL: https://issues.apache.org/jira/browse/SLING-60
> Project: Sling
>  Issue Type: Improvement
>  Components: microsling
>Reporter: Felix Meschberger
>Assignee: Bertrand Delacretaz
> Fix For: 2.0.0
>
>
> I have a conceptual issue with the SlingRequestPathInfoParser because the 
> idea of cutting an URI path into pieces is different and the 
> SlingRequestPathInfoParser just does not have enough knowledge to break the 
> URI path apart.
> The initial intent of breaking the URI apart such, that the resource path is 
> the the longest prefix of the URI path matching a repository item (I think we 
> should move to enabling addressing items and not just nodes...) and the rest 
> of the breakup depends on the first part.
> So a simple implementation would be to cut off pieces of the URI path from 
> the end at dots and slashes until a repository item may be addressed. What 
> has been cut off is then further treated like this:
>* Any pieces separated by a dot from the path in the same path segement 
> are considered the
>  selectors and extension.
>* All pieces together after the last segement of the item path make up the 
> suffix.
> Examples:
> /a/b/c.print.a4.html/some/suffix.pdf with an item at /a/b/c would be broken 
> apart as resourcePath=/a/b/c, selectors=[print,a4], ext=html, 
> suffix=/some/suffix.pdf
> 
> /a/b.special/c.print.a4.html/some/suffix.pdf with an item at /a/b.special/c 
> would be broken apart as resourcePath=/a/b.special/c, selectors=[print,a4], 
> ext=html, suffix=/some/suffix.pdf
> 
> Simple string operations cannot account for this subtelity. For this reason I 
> propse to drop the SlingRequestPathInfoParser class and implement the split 
> up in the ResourceResolverFilter or an abstract base class thereoff.
> See also the ContentResolverFilter in the Sling Core project.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: ResourceResolver and Resource

[Felix Meschberger]

Am Donnerstag, den 18.10.2007, 16:36 +0200 schrieb Bertrand Delacretaz:
> On 10/18/07, Felix Meschberger <[EMAIL PROTECTED]> wrote:
> 
> > ...// return the main content of the current request
> > Content getContent();
> > // return a content address by path
> > Content getContent(String path) throws SlingException;
> > // list the children of the named content
> > Enumeration getChildren(Content content) throws
> > SlingException;
> >...
> 
> Why do we need this in the general case?
> 
> If the Resource is a JCR node, that gives full access to JCR
> navigation features, which cover the above and much more (or am I
> missing something?).

Well, thinking along these lines: Why do we need a Resource and
ResourceResolver in the first place then ? 

Honestly, if we abstract the Resource, we also have to take the next
step and abstract access to relative Resources and children.

> If this is needed for OCM-mapped objects only, then IMHO that's an OCM
> concern, which might warrant a helper class, but does not deserve
> adding stuff to our (currently lean and mean) Resource interface.

That's the reason why probably the second solution (relative and
children from the Resource) is not that good and the first (relative and
children from ResourceResolver) might be better. On the other hand the
second solution puts you in a context (the Resource) and does not force
you to you out-of-context information (the ResourceResolver again).

Regards
Felix

Re: ResourceResolver and Resource

[Bertrand Delacretaz]

On 10/18/07, Felix Meschberger <[EMAIL PROTECTED]> wrote:

> ...// return the main content of the current request
> Content getContent();
> // return a content address by path
> Content getContent(String path) throws SlingException;
> // list the children of the named content
> Enumeration getChildren(Content content) throws
> SlingException;
>...

Why do we need this in the general case?

If the Resource is a JCR node, that gives full access to JCR
navigation features, which cover the above and much more (or am I
missing something?).

If this is needed for OCM-mapped objects only, then IMHO that's an OCM
concern, which might warrant a helper class, but does not deserve
adding stuff to our (currently lean and mean) Resource interface.

-Bertrand

Re: [jira] Updated: (SLING-67) Provide extensible default Servlets

[Bertrand Delacretaz]

On 10/18/07, Felix Meschberger (JIRA) <[EMAIL PROTECTED]> 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

Re: ResourceResolver and Resource

[Carsten Ziegeler]

Felix Meschberger schrieb:
> Hi all,
> 
> The current Component API contains the following methods in the
> SlingRequest interface:
> 
> // return the main content of the current request
> Content getContent();
> // return a content address by path
> Content getContent(String path) throws SlingException;
> // list the children of the named content
> Enumeration getChildren(Content content) throws
> SlingException;
> 
> Presuming that we drop the SlingRequest interface in favor of some
> SlingRequestContext, which should just be a bean available as a request
> attribute, we probably need some replacement API for these methods. I
> could imagine the following solutions:
> 
> (1) Enhance the propsed ResourceResolver interface
> 
> // return the Resource addressed by the request (already
> proposed)
> Resource getResource(ServletRequest request);
> // return the Resource addressed by path, relative path resolved
> // relative to the given resource
> Resource getResource(Resource base, String path) throws
> SlingException;
> // list the children of the named Resource
> Iterator listChildren(Resource resource) throws
> SlingException;
> 
> (2) Enhance the Resource interface by adding the following methods
> 
> // return the resource addressed by the path
> // relative paths resolved relative to this resource
> Resource getResource(String path) throws SlingException;
> // list the children of this resource
> Iterator listChildren() throws SlingException;
> 
> (3) Enhance the SlingRequestContext by methods:
> 
> // return the Resource addressed by path, relative path resolved
> // relative to the request's main resource
> Resource getResource(ServletRequest request, String path) throws
> SlingException;
> // list the children of the named Resource
> Iterator listChildren(Resource resource) throws
> SlingException;
> 
> The first solution clearly detaches the Resource from the
> ResourceResolver on the other hand requires clients to get at the
> ResourceResolver somehow (Probably as another field in the
> SlingRequestContext ?).
> 
> The third solution does not seem right as it breaks the idea that
> SlingRequestContext should probably be just a bean.
> 
> I most like the second solution as it looks similar to what java.io.File
> does. There is one catch, tough, with this solution: The Resource
> returned must have a link into the ResourceResolver.
> 
> WDYT ?
> 
I think the second solution is best and I don't see a problem with the
internal reference from a resource implementation. In the excalibur
sourceresolver stuff we are doing exactly the same :)

Carsten
-- 
Carsten Ziegeler
[EMAIL PROTECTED]

ResourceResolver and Resource

[Felix Meschberger]

Hi all,

The current Component API contains the following methods in the
SlingRequest interface:

// return the main content of the current request
Content getContent();
// return a content address by path
Content getContent(String path) throws SlingException;
// list the children of the named content
Enumeration getChildren(Content content) throws
SlingException;

Presuming that we drop the SlingRequest interface in favor of some
SlingRequestContext, which should just be a bean available as a request
attribute, we probably need some replacement API for these methods. I
could imagine the following solutions:

(1) Enhance the propsed ResourceResolver interface

// return the Resource addressed by the request (already
proposed)
Resource getResource(ServletRequest request);
// return the Resource addressed by path, relative path resolved
// relative to the given resource
Resource getResource(Resource base, String path) throws
SlingException;
// list the children of the named Resource
Iterator listChildren(Resource resource) throws
SlingException;

(2) Enhance the Resource interface by adding the following methods

// return the resource addressed by the path
// relative paths resolved relative to this resource
Resource getResource(String path) throws SlingException;
// list the children of this resource
Iterator listChildren() throws SlingException;

(3) Enhance the SlingRequestContext by methods:

// return the Resource addressed by path, relative path resolved
// relative to the request's main resource
Resource getResource(ServletRequest request, String path) throws
SlingException;
// list the children of the named Resource
Iterator listChildren(Resource resource) throws
SlingException;

The first solution clearly detaches the Resource from the
ResourceResolver on the other hand requires clients to get at the
ResourceResolver somehow (Probably as another field in the
SlingRequestContext ?).

The third solution does not seem right as it breaks the idea that
SlingRequestContext should probably be just a bean.

I most like the second solution as it looks similar to what java.io.File
does. There is one catch, tough, with this solution: The Resource
returned must have a link into the ResourceResolver.

WDYT ?

Regards
Felix

Re: microsling: ResourceResolver interface and SLING-60

[Bertrand Delacretaz]

On 10/18/07, Felix Meschberger <[EMAIL PROTECTED]> wrote:

> ...we could also drop the SlingRequestPathInfoParser as the (default)
> ResourceResolver would by backtracking the path be able to keep track of
> the path parts and create a SlingRequestPathInfo object as a byproduct

I don't like that as the ResourceResolver then does "several things".

I prefer keeping a (simple small testable) SlingRequestPathInfoParser
to have less coupling.

-Bertrand

Re: microsling: ResourceResolver interface and SLING-60

[Bertrand Delacretaz]

On 10/18/07, Tobias Bocanegra <[EMAIL PROTECTED]> wrote:

> > The resolver would set the Resource and SlingRequestPathInfo on the
> > context immediately. ...

> ...this limits the 'resource resolution' to only work with a sling
> request context

I agree with Toby, and also the

 void resolveResource(SlingRequestContext context) throws SlingException;

introduces unnecessary coupling between the ResourceResolver and the
SlingRequestContext

> ...what about a:
>
> interface ResolvedResource extends Resource {
>public String getResolutionPath();
> }...

Good idea, cleaner than my suggestion, I'll do it like that unless
someone objects.

-Bertrand

Re: [RT] Template Handling

[Carsten Ziegeler]

Tobias Bocanegra wrote:
> 
> hi, once again this is display logic. the 'main' component script
> knows that it needs to display
> a header and a footer, so basically you do a:
> 
> 
> 
> then the footer component will check if it actually has content, and
> if not, it fetches it from the parent page or whatsoever.
> 
Yepp, this would solve the use case as well - you're right. It is
somehow more flexible than my template approach. And it doesn't require
changes to the sling core. Hurray :)

Thanks

Carsten

-- 
Carsten Ziegeler
[EMAIL PROTECTED]

Re: microsling: ResourceResolver interface and SLING-60

[Felix Meschberger]

Am Donnerstag, den 18.10.2007, 14:39 +0200 schrieb Tobias Bocanegra:
> > > this limits the 'resource resolution' to only work with a sling
> > > request context. what if i want to resolve a resourse without context
> > > ? e.g. when i want to check if a respective resource exists?
> > > i would have to create a fake request context ?
> >
> > Well, you always have the SlingRequestContext if you have the
> > HttpServletRequest as the former is a request attribute of the latter.
> 
> no, i mean, if the resolver sets the result in the context, i would
> need to create a dummy context so that it does not override the
> original stuff.
> 

Oops, missed that one. Thanks.

Regards
Felix

Re: microsling: ResourceResolver interface and SLING-60

[Tobias Bocanegra]

> > this limits the 'resource resolution' to only work with a sling
> > request context. what if i want to resolve a resourse without context
> > ? e.g. when i want to check if a respective resource exists?
> > i would have to create a fake request context ?
>
> Well, you always have the SlingRequestContext if you have the
> HttpServletRequest as the former is a request attribute of the latter.

no, i mean, if the resolver sets the result in the context, i would
need to create a dummy context so that it does not override the
original stuff.

-- 
-< [EMAIL PROTECTED] >---
Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
T +41 61 226 98 98, F +41 61 226 98 97
---< http://www.day.com >---

Re: microsling: ResourceResolver interface and SLING-60

[Felix Meschberger]

Am Donnerstag, den 18.10.2007, 13:56 +0200 schrieb Tobias Bocanegra:
> > public interface ResourceResolver {
> >   void resolveResource(SlingRequestContext context) throws
> > SlingException;
> > }
> >
> > The resolver would set the Resource and SlingRequestPathInfo on the
> > context immediately. And I think, the SlingRequestContext probably needs
> > a "backlink" to the request it belongs to, which would also help making
> > the RequestParameterMap generation lazy.
> 
> this limits the 'resource resolution' to only work with a sling
> request context. what if i want to resolve a resourse without context
> ? e.g. when i want to check if a respective resource exists?
> i would have to create a fake request context ?

Well, you always have the SlingRequestContext if you have the
HttpServletRequest as the former is a request attribute of the latter.

> what about a:
> 
> interface ResolvedResource extends Resource {
>public String getResolutionPath();
> }

Sounds good. Or even add the getResolutionPath to the Resource ?

Regards
Felix

Re: microsling: ResourceResolver interface and SLING-60

[Tobias Bocanegra]

> public interface ResourceResolver {
>   void resolveResource(SlingRequestContext context) throws
> SlingException;
> }
>
> The resolver would set the Resource and SlingRequestPathInfo on the
> context immediately. And I think, the SlingRequestContext probably needs
> a "backlink" to the request it belongs to, which would also help making
> the RequestParameterMap generation lazy.

this limits the 'resource resolution' to only work with a sling
request context. what if i want to resolve a resourse without context
? e.g. when i want to check if a respective resource exists?
i would have to create a fake request context ?

> > public interface ResourceResolver {
> >
> >   Result resolveResource(HttpServletRequest req) throws Exception;
> >
> >   public static class Result {
> > ...
> > public Resource getResource();
> >
> > // Indicates which part of the request URI path
> > // was used to resolve the resource (see SLING-60)
> > // This is usually the Resource's JCR path, but I have
> > // this vague feeling that decoupling them might be
> > // good (if only to expose this method here)
> > public String getResolutionPath();
> >   }
> > }

what about a:

interface ResolvedResource extends Resource {
   public String getResolutionPath();
}

and:

ResolvedResource resolveResource(HttpServletRequest req) throws Exception;

-- 
-< [EMAIL PROTECTED] >---
Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
T +41 61 226 98 98, F +41 61 226 98 97
---< http://www.day.com >---

Re: microsling: ResourceResolver interface and SLING-60

[Felix Meschberger]

How about this:

public interface ResourceResolver {
  void resolveResource(SlingRequestContext context) throws
SlingException;
}

The resolver would set the Resource and SlingRequestPathInfo on the
context immediately. And I think, the SlingRequestContext probably needs
a "backlink" to the request it belongs to, which would also help making
the RequestParameterMap generation lazy.

Such, we could also drop the SlingRequestPathInfoParser as the (default)
ResourceResolver would by backtracking the path be able to keep track of
the path parts and create a SlingRequestPathInfo object as a byproduct.
Or is this a bad idea ?

Regards
Felix

Am Donnerstag, den 18.10.2007, 13:35 +0200 schrieb Bertrand Delacretaz:
> Hi,
> 
> I'm starting work on SLING-60, and I think I'll add this new interface
> to the microsling.api package:
> 
> public interface ResourceResolver {
> 
>   Result resolveResource(HttpServletRequest req) throws Exception;
> 
>   public static class Result {
> ...
> public Resource getResource();
> 
> // Indicates which part of the request URI path
> // was used to resolve the resource (see SLING-60)
> // This is usually the Resource's JCR path, but I have
> // this vague feeling that decoupling them might be
> // good (if only to expose this method here)
> public String getResolutionPath();
>   }
> }
> 
> In this way the (to be improved) SlingRequestPathInfoParser stays
> decoupled, SlingRequestContext will pass it the above
> getResolutionPath() so that the selectors, extensions and suffix take
> the actual path used for resource resolution into account.
> 
> Comments are welcome (before it's too late ;-)
> 
> -Bertrand

[jira] Updated: (SLING-67) Provide extensible default Servlets

[Felix Meschberger (JIRA)]

 [ 
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: [RT] Template Handling

[Tobias Bocanegra]

On 10/18/07, Carsten Ziegeler <[EMAIL PROTECTED]> wrote:
> Hi, I have thought a little bit more about template handling and I came
> to the conclusion that we could add support for it to the heart of
> Sling. (For now, I'm refering to the "old" sling - current trunk, we can
> adapt this to the new stuff later on).
>
> Ok, let's start with an example. Assume you have a template for a page
> with a header, a footer and content (yes, it's that famous example again
> - but this time its a good one). Now, you want to create pages from this
> template which just refer to the header and footer but obviously have
> their own content. The structure in the repository could look like this:
>
> Template A
>   + footer
>   + header
>   + content
>
> Page One
>   + content
>
> Now, when the page is rendered, the component doing this should know
> that it has to render the header first, then content and then the footer
> (or perhaps it's for upside down people and it renders the footer first,
> who knows).
>
> Ok, so the first information, the Page One needs to store is from which
> template it was generated, so we could add a property like
> "sling:template" to the Page One node which contains the path to
> "Template A".
>
> The component rendering the page could now check if Page One has a child
> header, if not it goes to the "Template A" node and uses that header and
> so on. This would work, but requires a lot of coding in the component. A
> lot of nasty tests.
>
> So, I thought of a more transparent way :)
>
> Currently the request has the getContent(String) method. We could modify
> the implementation that this method does some more checks if the path is
> relative:
> a) If the current node has a child with the relative path, this child is
> used.
> b) If the current node does not have a child with the relative path, the
> current node is checked for a "sling:template" property.
> b)I) if the node has no "sling:template" property, the current node is
> changed to the parent of the current node, and we continue with b)
> b)II) if the node has a "sling:template" property, the referenced
> template node queried of it contains a child with the given relative
> path. If it has such a child, that one is used, if not we go back to b).
>
> Now, if b) is called several times, there will be some path
> concatenation, like in the following:
> Template A
>+ footer
> + copyright
> Page One
>- sling:template = "/Template A"
>+ footer
>
> Now, when the footer node of Page One is rendered it checks for its
> "copyright" child which is not there. Now footer is checked for the
> sling:template property and then Page One is checked. The sling:template
> property points correctly to "Template A", but of course "copyright" is
> a child of footer.
> As our algorithm knows that it has stepped up from "footer" to Page One,
> it will concatenate sling:template + "footer" + copyright (of course
> with the correct path separators etc.)
>
>
> Does this make sense? WDYT?

hi, once again this is display logic. the 'main' component script
knows that it needs to display
a header and a footer, so basically you do a:



then the footer component will check if it actually has content, and
if not, it fetches it from the parent page or whatsoever.

imo, templates are great for copying some default content structure
but are useless for meaningful default content.

regards, toby

-- 
-< [EMAIL PROTECTED] >---
Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
T +41 61 226 98 98, F +41 61 226 98 97
---< http://www.day.com >---

[jira] Created: (SLING-67) Provide extensible default Servlets

[Felix Meschberger (JIRA)]

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


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.

microsling: ResourceResolver interface and SLING-60

[Bertrand Delacretaz]

Hi,

I'm starting work on SLING-60, and I think I'll add this new interface
to the microsling.api package:

public interface ResourceResolver {

  Result resolveResource(HttpServletRequest req) throws Exception;

  public static class Result {
...
public Resource getResource();

// Indicates which part of the request URI path
// was used to resolve the resource (see SLING-60)
// This is usually the Resource's JCR path, but I have
// this vague feeling that decoupling them might be
// good (if only to expose this method here)
public String getResolutionPath();
  }
}

In this way the (to be improved) SlingRequestPathInfoParser stays
decoupled, SlingRequestContext will pass it the above
getResolutionPath() so that the selectors, extensions and suffix take
the actual path used for resource resolution into account.

Comments are welcome (before it's too late ;-)

-Bertrand

[jira] Assigned: (SLING-60) URI path split is content dependent

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz reassigned SLING-60:


Assignee: Bertrand Delacretaz

> URI path split is content dependent
> ---
>
> Key: SLING-60
> URL: https://issues.apache.org/jira/browse/SLING-60
> Project: Sling
>  Issue Type: Improvement
>  Components: microsling
>Reporter: Felix Meschberger
>Assignee: Bertrand Delacretaz
> Fix For: 2.0.0
>
>
> I have a conceptual issue with the SlingRequestPathInfoParser because the 
> idea of cutting an URI path into pieces is different and the 
> SlingRequestPathInfoParser just does not have enough knowledge to break the 
> URI path apart.
> The initial intent of breaking the URI apart such, that the resource path is 
> the the longest prefix of the URI path matching a repository item (I think we 
> should move to enabling addressing items and not just nodes...) and the rest 
> of the breakup depends on the first part.
> So a simple implementation would be to cut off pieces of the URI path from 
> the end at dots and slashes until a repository item may be addressed. What 
> has been cut off is then further treated like this:
>* Any pieces separated by a dot from the path in the same path segement 
> are considered the
>  selectors and extension.
>* All pieces together after the last segement of the item path make up the 
> suffix.
> Examples:
> /a/b/c.print.a4.html/some/suffix.pdf with an item at /a/b/c would be broken 
> apart as resourcePath=/a/b/c, selectors=[print,a4], ext=html, 
> suffix=/some/suffix.pdf
> 
> /a/b.special/c.print.a4.html/some/suffix.pdf with an item at /a/b.special/c 
> would be broken apart as resourcePath=/a/b.special/c, selectors=[print,a4], 
> ext=html, suffix=/some/suffix.pdf
> 
> Simple string operations cannot account for this subtelity. For this reason I 
> propse to drop the SlingRequestPathInfoParser class and implement the split 
> up in the ResourceResolverFilter or an abstract base class thereoff.
> See also the ContentResolverFilter in the Sling Core project.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (SLING-61) Rendering of references within the repository

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler closed SLING-61.
-

Resolution: Fixed

Ok, after some better use cases discussions (see sling dev list), we are all 
happy now. So I'll close the bug.

> Rendering of references within the repository
> -
>
> Key: SLING-61
> URL: https://issues.apache.org/jira/browse/SLING-61
> Project: Sling
>  Issue Type: New Feature
>  Components: Core
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
>
> If compound content is rendered (a node and its children), it would be good 
> to provide a mechanism which references other trees in the repository.
> Example:
> Node A
>+ header
>+ footer
> Node B
>+ content
> Node C
>+ content
> When node B or C are rendered, the header and footer of node A should be 
> rendered as well.
> A new node type sling:Reference with a path property will be introduced to 
> allow such references:
> Node B
>+ header [sling:Reference (path = /A/header)]
>+ content
>+ footer [sling:Reference (path = /A/footer)]
> A new content and component (ReferenceContent and ReferenceComponent) will be 
> added.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [jira] Reopened: (SLING-61) Rendering of references within the repository

[Carsten Ziegeler]

Tobias Bocanegra wrote:
>>> ...So, you have a node storing all documents as sub nodes. Now, you want to
>>> make a view on these documents containing just a bunch of them. With the
>>> references, you create a "view node" containing several reference nodes
>>> and are done
>> The header/footer example was a bit scary though ;-)
> right. i just wanted to make sure, that this header/footer example
> would be the wrong way to use reference components. the other examples
> make more sense.
> 
Yepp, sorry for the dumb example - I just came up with a better proposal
for the templating stuff.
Hopefully this one fits better the page/header/footer use case...

Carsten


-- 
Carsten Ziegeler
[EMAIL PROTECTED]

[RT] Template Handling

[Carsten Ziegeler]

Hi, I have thought a little bit more about template handling and I came
to the conclusion that we could add support for it to the heart of
Sling. (For now, I'm refering to the "old" sling - current trunk, we can
adapt this to the new stuff later on).

Ok, let's start with an example. Assume you have a template for a page
with a header, a footer and content (yes, it's that famous example again
- but this time its a good one). Now, you want to create pages from this
template which just refer to the header and footer but obviously have
their own content. The structure in the repository could look like this:

Template A
  + footer
  + header
  + content

Page One
  + content

Now, when the page is rendered, the component doing this should know
that it has to render the header first, then content and then the footer
(or perhaps it's for upside down people and it renders the footer first,
who knows).

Ok, so the first information, the Page One needs to store is from which
template it was generated, so we could add a property like
"sling:template" to the Page One node which contains the path to
"Template A".

The component rendering the page could now check if Page One has a child
header, if not it goes to the "Template A" node and uses that header and
so on. This would work, but requires a lot of coding in the component. A
lot of nasty tests.

So, I thought of a more transparent way :)

Currently the request has the getContent(String) method. We could modify
the implementation that this method does some more checks if the path is
relative:
a) If the current node has a child with the relative path, this child is
used.
b) If the current node does not have a child with the relative path, the
current node is checked for a "sling:template" property.
b)I) if the node has no "sling:template" property, the current node is
changed to the parent of the current node, and we continue with b)
b)II) if the node has a "sling:template" property, the referenced
template node queried of it contains a child with the given relative
path. If it has such a child, that one is used, if not we go back to b).

Now, if b) is called several times, there will be some path
concatenation, like in the following:
Template A
   + footer
+ copyright
Page One
   - sling:template = "/Template A"
   + footer

Now, when the footer node of Page One is rendered it checks for its
"copyright" child which is not there. Now footer is checked for the
sling:template property and then Page One is checked. The sling:template
property points correctly to "Template A", but of course "copyright" is
a child of footer.
As our algorithm knows that it has stepped up from "footer" to Page One,
it will concatenate sling:template + "footer" + copyright (of course
with the correct path separators etc.)


Does this make sense? WDYT?

Carsten
-- 
Carsten Ziegeler
[EMAIL PROTECTED]

Re: [jira] Reopened: (SLING-61) Rendering of references within the repository

[Tobias Bocanegra]

> > ...So, you have a node storing all documents as sub nodes. Now, you want to
> > make a view on these documents containing just a bunch of them. With the
> > references, you create a "view node" containing several reference nodes
> > and are done
> The header/footer example was a bit scary though ;-)
right. i just wanted to make sure, that this header/footer example
would be the wrong way to use reference components. the other examples
make more sense.

regards, toby
-- 
-< [EMAIL PROTECTED] >---
Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
T +41 61 226 98 98, F +41 61 226 98 97
---< http://www.day.com >---

Re: To Filter or not to Filter

[Tobias Bocanegra]

ok. thanks for the clarification.
in this case, i would avoid the auth filter as well.
regards, toby

On 10/17/07, Felix Meschberger <[EMAIL PROTECTED]> wrote:
> Am Mittwoch, den 17.10.2007, 16:49 +0200 schrieb Tobias Bocanegra:
> > i disagree...eg. when running in a appserver that does authentication
> > sling does not need the default http auth filter, but maybe a
> > jaas-auth filter or sso filter or whatsoever.
> >
> > bottom line: the authentication mechanism needs to be configurable.
>
> This is not question here. Sling is in fact built such, that the method
> of building the credentials is configurable and filters is not the only
> way how sling mechanisms can be "configured" in a flexible way.
>
> So in the case of authentication: We will have an Authentication service
> used by Sling, which in turn may make use of additional helpers.  Both
> the helpers can be added/removed at will and the Authentication service
> may be implemented however we wish.
>
> This is something different than whether we call the authentication
> service directly or as part of some filtering.
>
> Regards
> Felix
>
> > regards, toby
> >
> > On 10/17/07, Carsten Ziegeler <[EMAIL PROTECTED]> wrote:
> > > Felix Meschberger wrote:
> > > > Am Mittwoch, den 17.10.2007, 09:39 +0200 schrieb Carsten Ziegeler:
> > > >> I agree for resource and content resolution. But I'm not sure about
> > > >> authentication. Having a filter which does the authentication is very
> > > >> transparent. If we are using the servlet filter interface for these
> > > >> filters, its easy to use other authentication mechanisms like for
> > > >> example spring authentication (aka acegi) which is based on servlet
> > > >> filters as well.
> > > >> So for now, I personally tend to go with filters except where something
> > > >> is really required for Sling core to work. There we could use an
> > > >> explicit service instead.
> > > >
> > > > Not sure, whether this is the level authentication we require. Sling's
> > > > main purpose, which is also made strongly visible through the upcoming
> > > > Resource interface, is to provide a web application front-end to JCR
> > > > repositories. As such, I assume, that the JCR repository will be used
> > > > for authentication and access control purposes.
> > > >
> > > > As such, the only moving target of authentication is the question on how
> > > > to extract credential data from the request to use it as input to the
> > > > JCR Repository.login method. Currently Sling has an AuthenticationFilter
> > > > which makes use of AuthenticationHandler services (only HTTP Header
> > > > Authentication is implemented for now) to get the credentials or request
> > > > the credentials from the client. How authentication is handled in the
> > > > repository is completely out-of-scope for Sling.
> > > >
> > > > This is why I proposed to not use a filter for authentication.
> > > >
> > > Yes, you're right - so no filter for authentication.
> > >
> > > Carsten
> > >
> > > --
> > > Carsten Ziegeler
> > > [EMAIL PROTECTED]
> > >
> >
> >
>
>


-- 
-< [EMAIL PROTECTED] >---
Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
T +41 61 226 98 98, F +41 61 226 98 97
---< http://www.day.com >---

Re: [jira] Commented: (SLING-64) Refactor Servlets and Script resolution

[Torgeir Veimo]

On 18 Oct 2007, at 07:59, Carsten Ziegeler wrote:


Sorry for trying hard to be a pita :) but again, can we please let all
these discussions take place in the mailing list?
I think it's easy to first discuss a topic in the mailing list and  
then

create a jira which either sums up the discussion or references the
mailing list archives.


Ok, here is my proposal from the Jira issue comment:

How about abstracting this a bit, instead of relying on servlets to  
say themselves if they can handle a request, to use factories, or  
rather, mappers.


A manager would resolve a request to a sling servlet by iterating  
through its configured mappers and stopping once a suitable sling  
servlet is found. If no mapper resolves a servlet, the default sling  
servlet is called.


public interface ServletMapper {
public SlingServlet findServlet(SlingServletRequest request,  
Resource resource) throws Exception;

}

A configuration file would specify the order of the mappers, along  
with any configuration parameters each mapper needs. (A simple  
digester implementation would allow configuration parameters to be  
set using reflection.)


A default mapper which maps to servlets based on url and/or jcr node  
type or resource type can be provided which would be sufficient in  
most cases. For specific needs a sling api user would implement his  
own mapper.


Sitemesh uses a similar setup with great success for decorating web  
pages based on any combination of url patterns, request parameters  
and others. I'm using such a mapper approach successfully in our own  
prototype crm framework.



--
Torgeir Veimo
[EMAIL PROTECTED]

Re: [jira] Commented: (SLING-64) Refactor Servlets and Script resolution

[Bertrand Delacretaz]

On 10/18/07, Carsten Ziegeler <[EMAIL PROTECTED]> wrote:
> ..Sorry for trying hard to be a pita :) but again, can we please let all
> these discussions take place in the mailing list?...

You're right, sorry about that. We should discuss things here, and
move to Jira once we reach consensus.

-Bertrand

Re: [jira] Commented: (SLING-64) Refactor Servlets and Script resolution

[Carsten Ziegeler]

Sorry for trying hard to be a pita :) but again, can we please let all
these discussions take place in the mailing list?
I think it's easy to first discuss a topic in the mailing list and then
create a jira which either sums up the discussion or references the
mailing list archives.

Carsten

Felix Meschberger (JIRA) wrote:
> [ 
> https://issues.apache.org/jira/browse/SLING-64?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12535850
>  ] 
> 
> Felix Meschberger commented on SLING-64:
> 
> 
>> ... to use factories, or rather, mappers.
> 
> Which is at the core of my proposal. Speaking in OSGi terms, Servlets are 
> registered as OSGi services and specify in their service properties the 
> resource type(s) they are willing and able to handle requests for. The 
> Servlet Mapper looks at those registered servlets and selects one on behalf 
> of Sling.
> 
> And yes, I ultimately suggest dropping the SlingServlet interface including 
> the canProcess method. Not because I do not like it per-se, but I think it 
> will not scale - rotating to a possibly big number of servlets asking each in 
> turn whether it may handle the request may prevent the system from working.
> 
> But this proposal is just about modifying the general working : not looping 
> through servlets but (1) look for servlets by resource type, (2) check for a 
> script and (3) fall back to a defaul servlet. There will be another issue 
> handling the first step in more detail.
> 
>> Refactor Servlets and Script resolution
>> ---
>>
>> Key: SLING-64
>> URL: https://issues.apache.org/jira/browse/SLING-64
>> Project: Sling
>>  Issue Type: Improvement
>>  Components: microsling
>>Reporter: Felix Meschberger
>> Fix For: 2.0.0
>>
>> Attachments: SLING-64.patch
>>
>>
>> microsling currently defines a SlingServlet interface which has a canProcess 
>> method used to decide whether a servlet is capable of handling a request or 
>> not. I think, this mechanism will not scale well if we add more script 
>> engines or more servlets.
>> As a first step towards a simpler approach, I propose the following:
>>* Merge the DefaultSlingServlet and the SlingPostServlet to a single 
>> DefaultSlingServlet
>>* Replace Rhino and Velocity servlets by respective ScriptEngines (and 
>> define the interface for that)
>>* Refactor the SlingScriptResolver such that after resolving the script, 
>> it is also evaluated through a ScriptEngine
>>* Refactor MicroSlingServlet such, that
>>  (1) check for a servlet by resource type
>>  (2) try to evaluate a script
>>  (3) fall back to the DefaultSlingServlet
>>* Also in the MicroSlingServlet register servlets by type (currently 
>> there are none of course)
> 


-- 
Carsten Ziegeler
[EMAIL PROTECTED]