Re: DateFormat is not thread safe

[Felix Meschberger]

Hi Edgar,

Thanks for the hint. I just fixed it by synchronizing on the respective
DateFormat instance.

Regards
Felix

Am Freitag, den 14.09.2007, 11:15 -0300 schrieb Edgar Poce:
> Hi,
> 
> I've just downloaded the Sling code and I found that the class
> org.apache.sling.obr.Repository instantiates DateFormat
> implementations statically and uses them in instance methods which are
> not synchronized. I'm not familiarized with the code, I'm not sure
> whether the access to those methods is synchronized somewhere else,
> but if they are not the the DateFormat will generate wrong string
> representations of the date under heavy load.
> 
> see http://java.sun.com/j2se/1.4.2/docs/api/java/text/DateFormat.html
> 
> br,
> edgar

Re: Continuum for Sling

[Felix Meschberger]

Hi,

Quite true. How about sending the successfull build notices to
sling-commits and the failures to sling-dev, which is what we do in
Felix ?

Regards
Felix

Am Dienstag, den 18.09.2007, 11:23 +0200 schrieb Roy T. Fielding:
> On Sep 18, 2007, at 8:17 AM, Carsten Ziegeler wrote:
> > with some help from Wendy, we now have Sling in the vmbuild continuum.
> > As you probably noticed, I configured our project with sending
> > notifications to the dev list :)
> 
> I'd rather not receive such notices, and it is filling our mail
> discussion archives with irrelevant dreck.  It should be sent to
> a notices list instead.
> 
> Roy
> 

Re: Continuum for Sling

[Felix Meschberger]

Am Dienstag, den 18.09.2007, 11:45 +0200 schrieb Roy T. Fielding:
> Why do we need successful notices at all? 

For tracking and completeness :-)

Regards
Felix

The Wiki

[Felix Meschberger]

Hi all,

I now got the Wiki space on Confluence for Wiki. Currently I have only
created a single start page at [1]. Over the next few days, I will
migrate the current contents of the Jackrabbit Wiki concerning Sling
over to the new Wiki.

I propose that we eventually use the wiki as the source for our site
(like for example the Apache Felix project does). As such we would have
to place limitations on the rights to edit the content of the wiki as
per [2] to those with a CLA on file.

What do you think ?

Regards
Felix

[1] http://cwiki.apache.org/SLING/
[2] http://cwiki.apache.org/CWIKI/

Re: svn commit: r576841 - /incubator/sling/trunk/sling-app/src/main/java/org/apache/sling/launcher/Sling.java

[Felix Meschberger]

verd Ich habe nur gewusst, dass slingHome null sein kann, aber dass
dieser Test dort schon gemacht wurde, habe ich nicht beachtet. Alles
klar. Sorry.

Gruss
Felix

Am Dienstag, den 18.09.2007, 16:57 +0200 schrieb Carsten Ziegeler:
> [EMAIL PROTECTED] schrieb:
> > @@ -793,7 +874,7 @@
> >  try {
> >  if (is == null && slingHome != null) {
> >  File resFile = new File(file);
> > -if (!resFile.isAbsolute() ) {
> > +if (!resFile.isAbsolute()  && slingHome != null) {
> I think you don't need the second slingHome check as the first if only
> evaluates to true if slingHome is not null.
> 
> Carsten
> 

Re: Location of constants

[Felix Meschberger]

Hi,

Am Mittwoch, den 19.09.2007, 09:33 +0200 schrieb Carsten Ziegeler:
> i'm wondering if we should move some of the constants from
> sling-app/Sling.java to the constants in core?
> 
> For example the new sling.id or sling.home are of general interest in

I partially agree. We should probably have some of the Sling constants
(sling.home, sling.home.url, sling.id) replicated in the
o.a.s.core.Constants class for use in Sling Bundles.

I fear that referring to sling-core from the sling-app project is not
practical either. Therefore, I suggest to just replicate these
constants.

Regards
Felix

Re: JCR Namespace for Sling

[Felix Meschberger]

Hi Carsten,

Thanks for bringing this up, I was about to launch such a discussion for
the taglib URI we have in the sling-scripting-jsp-taglib bundle, which
currently is "http://jackrabbit.apache.org/taglibs/sling/1.0";

How about using a intermediate path for the node type to separate the
node type and taglibs space ? We would then have
http://sling.apache.org/taglibs for tag libs (currently only one) and
http://sling.apache.org/jcr for node types and if there would be DTDs
(there aren't any at the moment, but you never know) this would
http://sling.apache.org/dtds.

All in all we would have the following URIs

   http://sling.apache.org/jcr/sling/1.0 - JCR node type name space,
maps to the prefix sling
   http://sling.apache.org/taglibs/sling/1.0 - The Sling JSP taglib

Regards
Felix

Am Mittwoch, den 19.09.2007, 14:26 +0200 schrieb Carsten Ziegeler:
> What namespace do we want to use for Sling? Currently it's
> "http://jackrabbit.apache.org/sling/1.0";; if we might become a top level
> project some time later (which we don't have to discuss yet), it might
> probably better to use "http://sling.apache.org/sling/1.0"; instead.
> 
> WDYT?
> 
> Carsten

Re: Component -> Slinglet?

[Felix Meschberger]

Am Mittwoch, den 19.09.2007, 15:48 +0200 schrieb Roy T. Fielding:
> I think it might be more interesting to stay within the metaphor
> and call them stones (to be loaded in the sling).

Then what do we call the current Content ?

But stone is ok so we might create DhryStone and WhetStone for
performance measurement :-)

Regards
Felix

JCR Node Type Management Issues

[Felix Meschberger]

Hi all,

Currently, the sling-content-jcr bundle has a ContentManagerFactory
implementation (the JcrContentHelper, used to access Sling
ContentManager instances), which listens for bundles being registered
and registers node types registered in the bundles and loads initial
content stored in those bundles. Additionally, this class cares to setup
the Sling ContentManager instances used to access the OCM functionality.

While working on the sling-event bundle, we discovered a race condition
with node type registration and repository use. To overcome this race
condition, we propose to move the node type registration part from the
ContentManagerFactory implementation to the AbstractSlingRepository
class in the sling-jackrabbit-api bundle. This class is the base class
for services registered to provide the repository. As such, this class
has contact to the repository before the service is registered or made
available to the users of the repository.

Some background information on the race condition: The JcrContentHelper
is implemented as an OSGi Component and requires a repository and as
such will only be activated when the repository is available. The
AbstractRepositoryEventHandler in the sling-event bundle also requires a
repository and is also implemented as an OSGi component. When now both
components are waiting for a repository to become available, the
AbstractRepositoryEventHandler may be activated before the
JcrContentHelper is activated and therefore, the node types required by
the AbstractRepositoryEventHandler are not available yet as the
JcrContentHandler was not able yet to register them ...

What do you think of this change ?

BTW, JIRA is http://issues.apache.org/jira/browse/SLING-12

Regards
Felix

Commons Bundles

[Felix Meschberger]

Hi all,

The Sling trunk contains three bundles in a commons directory, which are
actually just wrapper bundles. The first one is the JSP API required by
Sling, the other two are wrappings for the MX4J and MX4J-Remote
libraries providing JMX implementations.

Assuming that the JSP API bundle might also be required by other OSGi
framework users, we might offer the JSP API wrapping to the Apache Felix
project for their commons initiative.

As for the MX4J and MX4J-Remote wrappings, I would propose to just
remove them as Sling requires Java 5 or higher, which already includes a
JMX implementation and therefore does not require a third party one.

If noone objects, I would do this sometime next week.

Regards
Felix

Re: how does the default content mapping work?

[Felix Meschberger]

Hi Edgar,

It seems that this issue is probably related to your issue JCR-1142 you
reported to Jackrabbit. It seems actually, that OCM tries to resolve the
actual node against another class descriptor (again) without checking
whether such a descriptor really exists.

IMHO this is not really correct, because when calling the
getObject(Session, Class, String) method I expect the object returned to
be at least assignement compatible to the class I have submitted.

I will try to find a solution to that problem together with Christophe.

Regards
Felix

Am Freitag, den 21.09.2007, 11:00 -0300 schrieb Edgar Poce:
> Hi,
> 
>   I'm running Sling and I'm trying to access the repository's root
> node from the browser with the following url: http://localhost:8080.
> According to 
> http://wiki.apache.org/jackrabbit/ApacheSling/SlingGuideDefaultMappings
> the default component must resolve the request if there's no custom
> mapping, however I'm getting "404 not found".
> 
> the wiki says "If no mapping exists for the given node, an exception
> is thrown and the request fails." and bellow it says "In such a case
> of missing content mapping, a default Content mapping is defined in
> the form of the org.apache.sling.content.jcr.DefaultContent class".
> I'm not sure whether the expected behavior is to fail with a 404 error
> or to process the request with the default component. Any idea?
> 
> thanks in advance,
> Edgar

Re: rapid development primer example doesn't work

[Felix Meschberger]

Hi Edgar,

This is actually probably a bug in the sling:Content node type
definition, which reads:

  - sling:contentClass (String)
= 'org.apache.sling.jcr.content.DefaultContent'
copy mandatory

The intent was, that the sling:contentClass property is automatically
created, which does not seem to be the case. I have fixed this in the
core project.

Unfortunately, node type management is a nightmare currently in
Jackrabbit and Sling only has the CND-file install mechanism to register
node types, you will either have to destroy the repository or to
manually modify the node type definition. Sorry.

Hope this helps.

Regards
Felix

Am Freitag, den 21.09.2007, 11:32 -0300 schrieb Edgar Poce:
> Hi,
> 
>  I tried to follow the instructions under the section "Rapid
> Development Primer" at
> http://wiki.apache.org/jackrabbit/ApacheSling/SlingGuideDefaultMappings
> and I couldn't make it work. I think it's probably outdated, the
> repository throws an exception on save with the message "mandatory
> property {http://jackrabbit.apache.org/sling/1.0}cont
> entClass does not exist". Is there any step missing in the docs?
> 
> thanks in advance,
> Edgar

Sling Site

[Felix Meschberger]

Hi all,

I have now migrated the former contents of the Jackrabbit Wiki regarding
Sling to the new Sling wiki at [1]. In addition, I modified the
auto-export template of the Confluence and the CSS to make the export
look like a real web site. Finally the exported Wiki content is synced
into the Sling site at [2].

So now, our site is dynamically generated from the wiki content and will
- with some delay involved due to exporting and syncing - actual with
respect to the wiki.

Thanks go to Marcel Offermans and Luminis for the nice CSS and export
template work.

Please report if you find any issues or problems. Thanks.

Regards
Felix

[1] http://cwiki.apache.org/SLING
[2] http://incubator.apache.org/sling

Re: how does the default content mapping work?

[Felix Meschberger]

Hi,

It seems, that applying the fix I attached to JCR-1142 does do the
trick :-)

Regards
Felix

Am Freitag, den 21.09.2007, 12:17 -0300 schrieb Edgar Poce:
> Hi Felix,
> 
>  thanks for your help, It seems that jcr-mapping tries to get a new
> ClassDescriptor by calling
> classDescriptor.getDescendantClassDescriptor(nodeType) instead of
> using the descriptor which maps to the given class.
> 
> It seems this problem is related to the inheritance strategy. I tried
> to dive into the ocm but I couldn't understand how it works.
> 
> Apparently, given that DefaultContent declares an interface
> (org.apache.sling.component.Content) it uses
> NODETYPE_PER_CONCRETECLASS[1], and for mappings with this strategy if
> the node's nodetype is not the same than the  from classdescriptor's
> nodetype (null for DefaultContent) jcr-mapping tries to get the
> descendant descriptor (which is null for DefaultContent)[2] and
> jcr-mapping fails with NPE.
> 
> [1] see ClassDescriptor.lookupInheritanceSettings()
> [2] see ObjectConverterImpl.getObject(Session session, Class clazz,
> String path) line 349
> 
> br,
> Edgar
> 
> On 9/21/07, Felix Meschberger <[EMAIL PROTECTED]> wrote:
> > Hi Edgar,
> >
> > It seems that this issue is probably related to your issue JCR-1142 you
> > reported to Jackrabbit. It seems actually, that OCM tries to resolve the
> > actual node against another class descriptor (again) without checking
> > whether such a descriptor really exists.
> >
> > IMHO this is not really correct, because when calling the
> > getObject(Session, Class, String) method I expect the object returned to
> > be at least assignement compatible to the class I have submitted.
> >
> > I will try to find a solution to that problem together with Christophe.
> >
> > Regards
> > Felix
> >
> > Am Freitag, den 21.09.2007, 11:00 -0300 schrieb Edgar Poce:
> > > Hi,
> > >
> > >   I'm running Sling and I'm trying to access the repository's root
> > > node from the browser with the following url: http://localhost:8080.
> > > According to 
> > > http://wiki.apache.org/jackrabbit/ApacheSling/SlingGuideDefaultMappings
> > > the default component must resolve the request if there's no custom
> > > mapping, however I'm getting "404 not found".
> > >
> > > the wiki says "If no mapping exists for the given node, an exception
> > > is thrown and the request fails." and bellow it says "In such a case
> > > of missing content mapping, a default Content mapping is defined in
> > > the form of the org.apache.sling.content.jcr.DefaultContent class".
> > > I'm not sure whether the expected behavior is to fail with a 404 error
> > > or to process the request with the default component. Any idea?
> > >
> > > thanks in advance,
> > > Edgar
> >
> >

Re: how does the default content mapping work?

[Felix Meschberger]

Hi Edgar,

I just have attached a patch proposal to your issue, which implements my
opinion that the object returned should be the one I request (or an
extension thereof or nothing, if it is not possible to load the node
with the requested class).

I have to admit, that I do not understand this strategy stuff to the
depth :-)

Regards
Felix

Am Freitag, den 21.09.2007, 12:17 -0300 schrieb Edgar Poce:
> Hi Felix,
> 
>  thanks for your help, It seems that jcr-mapping tries to get a new
> ClassDescriptor by calling
> classDescriptor.getDescendantClassDescriptor(nodeType) instead of
> using the descriptor which maps to the given class.
> 
> It seems this problem is related to the inheritance strategy. I tried
> to dive into the ocm but I couldn't understand how it works.
> 
> Apparently, given that DefaultContent declares an interface
> (org.apache.sling.component.Content) it uses
> NODETYPE_PER_CONCRETECLASS[1], and for mappings with this strategy if
> the node's nodetype is not the same than the  from classdescriptor's
> nodetype (null for DefaultContent) jcr-mapping tries to get the
> descendant descriptor (which is null for DefaultContent)[2] and
> jcr-mapping fails with NPE.
> 
> [1] see ClassDescriptor.lookupInheritanceSettings()
> [2] see ObjectConverterImpl.getObject(Session session, Class clazz,
> String path) line 349
> 
> br,
> Edgar
> 
> On 9/21/07, Felix Meschberger <[EMAIL PROTECTED]> wrote:
> > Hi Edgar,
> >
> > It seems that this issue is probably related to your issue JCR-1142 you
> > reported to Jackrabbit. It seems actually, that OCM tries to resolve the
> > actual node against another class descriptor (again) without checking
> > whether such a descriptor really exists.
> >
> > IMHO this is not really correct, because when calling the
> > getObject(Session, Class, String) method I expect the object returned to
> > be at least assignement compatible to the class I have submitted.
> >
> > I will try to find a solution to that problem together with Christophe.
> >
> > Regards
> > Felix
> >
> > Am Freitag, den 21.09.2007, 11:00 -0300 schrieb Edgar Poce:
> > > Hi,
> > >
> > >   I'm running Sling and I'm trying to access the repository's root
> > > node from the browser with the following url: http://localhost:8080.
> > > According to 
> > > http://wiki.apache.org/jackrabbit/ApacheSling/SlingGuideDefaultMappings
> > > the default component must resolve the request if there's no custom
> > > mapping, however I'm getting "404 not found".
> > >
> > > the wiki says "If no mapping exists for the given node, an exception
> > > is thrown and the request fails." and bellow it says "In such a case
> > > of missing content mapping, a default Content mapping is defined in
> > > the form of the org.apache.sling.content.jcr.DefaultContent class".
> > > I'm not sure whether the expected behavior is to fail with a 404 error
> > > or to process the request with the default component. Any idea?
> > >
> > > thanks in advance,
> > > Edgar
> >
> >

Re: [jira] Created: (SLING-20) jsp scripting depends on servlet api 2.4 but the 2.3 version is declared in the parent pom

[Felix Meschberger]

Hi Edgar,

Have your tried to refresh the packages after uploading the servlet 2.4
bundle ?

Nevertheless, the problem seems to be that the servlet bundle used
includes two old jsp packages which conflict with the requirements of
JSP 2.0.

Regards
Felix

Am Sonntag, den 23.09.2007, 08:13 -0700 schrieb Edgar Poce (JIRA):
> jsp scripting depends on servlet api 2.4 but the 2.3 version is declared in 
> the parent pom
> --
> 
>  Key: SLING-20
>  URL: https://issues.apache.org/jira/browse/SLING-20
>  Project: Sling
>   Issue Type: Bug
> Reporter: Edgar Poce
> Priority: Minor
> 
> 
> Jsp scripting doesn't work out of the box because sling app includes the 
> servlet 2.3 osgi bundle. With the current configuration the servlet 2.4 
> bundle must be deployed later and the server must be restarted because the 
> jsp scripting bundle keeps bound to the 2.3 version.
> 
> proposed patch
> 
> Index: /home/epoce/hd2/projects/sling/trunk/parent/pom.xml
> ===
> --- /home/epoce/hd2/projects/sling/trunk/parent/pom.xml   (revision 
> 578464)
> +++ /home/epoce/hd2/projects/sling/trunk/parent/pom.xml   (working copy)
> @@ -366,7 +366,13 @@
>  
>  javax.servlet
>  servlet-api
> -2.3
> +2.4
> +provided
> +
> +
> +javax.servlet
> +jsp-api
> +2.0
>  provided
>  
>  
> Index: /home/epoce/hd2/projects/sling/trunk/sling-app/pom.xml
> ===
> --- /home/epoce/hd2/projects/sling/trunk/sling-app/pom.xml(revision 
> 578464)
> +++ /home/epoce/hd2/projects/sling/trunk/sling-app/pom.xml(working copy)
> @@ -207,7 +207,7 @@
>  
>  org.apache.felix.commons
>  org.apache.felix.commons.servlet-api
> -2.3.0-0001-SNAPSHOT
> +2.4.0-0002-SNAPSHOT
>  
>  
>  org.apache.sling
> 
> 
> Index: /home/epoce/hd2/projects/sling/trunk/scripting-jsp-taglib/pom.xml
> ===
> --- /home/epoce/hd2/projects/sling/trunk/scripting-jsp-taglib/pom.xml 
> (revision 578464)
> +++ /home/epoce/hd2/projects/sling/trunk/scripting-jsp-taglib/pom.xml 
> (working copy)
> @@ -104,6 +104,10 @@
>  servlet-api
>  
>  
> +javax.servlet
> +jsp-api
> +
> +
>  commons-collections
>  commons-collections
>  
> 
> 

Re: [jira] Created: (SLING-20) jsp scripting depends on servlet api 2.4 but the 2.3 version is declared in the parent pom

[Felix Meschberger]

Hi Edgar,

Ok.

Regards
Felix

Am Sonntag, den 23.09.2007, 12:32 -0300 schrieb Edgar Poce:
> Hi Felix,
> 
> On 9/23/07, Felix Meschberger <[EMAIL PROTECTED]> wrote:
> > Hi Edgar,
> >
> > Have your tried to refresh the packages after uploading the servlet 2.4
> > bundle ?
> >
> 
> No, I haven't. Now I have everything working and I'd like to play a
> little with sling and write a custom component  :). I'll try to
> refresh the packages tomorrow and I'll let you know how it works.
> 
> > Nevertheless, the problem seems to be that the servlet bundle used
> > includes two old jsp packages which conflict with the requirements of
> > JSP 2.0.
> >
> 
> Yes, I think the jsp-api 2.0 is compatible only with servlet 2.4. The
> jsp scripting fails with a ClassNotFoundException (SkipPageException
> is missing) with servlet 2.3.
> 
> br,
> edgar
> 
> > Regards
> > Felix
> >
> > Am Sonntag, den 23.09.2007, 08:13 -0700 schrieb Edgar Poce (JIRA):
> > > jsp scripting depends on servlet api 2.4 but the 2.3 version is declared 
> > > in the parent pom
> > > --
> > >
> > >  Key: SLING-20
> > >  URL: https://issues.apache.org/jira/browse/SLING-20
> > >  Project: Sling
> > >   Issue Type: Bug
> > > Reporter: Edgar Poce
> > > Priority: Minor
> > >
> > >
> > > Jsp scripting doesn't work out of the box because sling app includes the 
> > > servlet 2.3 osgi bundle. With the current configuration the servlet 2.4 
> > > bundle must be deployed later and the server must be restarted because 
> > > the jsp scripting bundle keeps bound to the 2.3 version.
> > >
> > > proposed patch
> > >
> > > Index: /home/epoce/hd2/projects/sling/trunk/parent/pom.xml
> > > ===
> > > --- /home/epoce/hd2/projects/sling/trunk/parent/pom.xml   (revision 
> > > 578464)
> > > +++ /home/epoce/hd2/projects/sling/trunk/parent/pom.xml   (working 
> > > copy)
> > > @@ -366,7 +366,13 @@
> > >  
> > >  javax.servlet
> > >  servlet-api
> > > -2.3
> > > +2.4
> > > +provided
> > > +
> > > +
> > > +javax.servlet
> > > +jsp-api
> > > +2.0
> > >  provided
> > >  
> > >
> > > Index: /home/epoce/hd2/projects/sling/trunk/sling-app/pom.xml
> > > ===
> > > --- /home/epoce/hd2/projects/sling/trunk/sling-app/pom.xml(revision 
> > > 578464)
> > > +++ /home/epoce/hd2/projects/sling/trunk/sling-app/pom.xml(working 
> > > copy)
> > > @@ -207,7 +207,7 @@
> > >  
> > >  org.apache.felix.commons
> > >  org.apache.felix.commons.servlet-api
> > > -2.3.0-0001-SNAPSHOT
> > > +2.4.0-0002-SNAPSHOT
> > >  
> > >  
> > >  org.apache.sling
> > >
> > >
> > > Index: /home/epoce/hd2/projects/sling/trunk/scripting-jsp-taglib/pom.xml
> > > ===
> > > --- /home/epoce/hd2/projects/sling/trunk/scripting-jsp-taglib/pom.xml 
> > > (revision 578464)
> > > +++ /home/epoce/hd2/projects/sling/trunk/scripting-jsp-taglib/pom.xml 
> > > (working copy)
> > > @@ -104,6 +104,10 @@
> > >  servlet-api
> > >  
> > >  
> > > +javax.servlet
> > > +jsp-api
> > > +
> > > +
> > >  commons-collections
> > >  commons-collections
> > >  
> > >
> > >
> >
> >

Servlet 2.4 and JSP 2.0

[Felix Meschberger]

Hi all,

This weekend I fixed a series of bugs reported by Edgar Poce (many
thanks for tracking them down and reporting them). Along this road, I
updated the managed dependencies in the Sling parent pom as follows:
serlvet-api now is set to 2.4 and I added jsp-api set to version 2.0.

As a consequence I also modified the sling-app to contain the
servlet-api 2.4 bundle from the Apache Felix project.

This change is actually just a consequence of a step we did just before
commiting the initial source to the Apache SVN, when we decided to
require Java 5 or higher. In addition, by using a JSP Compiler
supporting JSP 2.0 it is actually not the best of all ideas to use
servlet API 2.3 at all.

Regards
Felix

Re: Hello

[Felix Meschberger]

Hi Bradly,

I am very glad to head, that you are trying to use Sling.

Now, for what you can expect: Currently the code is in an early stage
and we are constantly improving it almost on an hourly basis. Just today
I fixed a few rough bugs around JSP compilation and execution reported
by Edgar.

So, after getting the source, you have - for now - to build it by
yourself and deploy. I added a page [1]  listing the steps to get a
running Sling instance from the SVN checkout.

Of course, it would be great if you would report any issues you find, so
that we can improve the system :-)

Hope this helps.

Regards
Felix

[1] http://incubator.apache.org/sling/site/first-steps.html (may take
some time before you see it due to synchronization issues)

Am Samstag, den 22.09.2007, 14:47 +1000 schrieb Bradley Beddoes:
> Hi All,
> Have spent the afternoon reading about your sling project and I must say 
> I think you've covered some excellent ground in a direction we have been 
> planning to head in here at intient which is great.
> 
> Going to have a play from SVN today/tonight, anything in particular I 
> should be looking out for in regards to current issues?.
> 
> regards,
> Bradley
> 

Re: Hello ... as I hit send I got a Maven resolution error :(.

[Felix Meschberger]

Hi Bradley,

Sorry for that :-)

Yes, this library is currently in an unfortunate state, as in the maven
2 repository, there is only the pom file which points you to download
from the day site. Unfortunately it also does not help pointing maven at
the day repository, as maven keeps trying repo1.

So you will (for the moment, see below) have to manually download and
locally install the jcr.jar file as instructed by maven. I will update
the first-steps page with this information.

Now, why "for the moment": Day is currently investigating whether and
how the jcr-1.0.jar file could be made publicly available in the
official maven repo. The problem is however not of a technical but of a
licensing nature. Until that time, the manual installation is
unfortunately required.

Hope this helps.

Regards
Felix

Am Montag, den 24.09.2007, 21:16 +1000 schrieb Bradley Beddoes:
> Hi,
> Just ran into the following:
> 
> [INFO] 
> 
> [INFO] Building Sling - Repository API and Commons Bundle
> [INFO]task-segment: [install]
> [INFO] 
> 
> Downloading: http://repo1.maven.org/maven2/javax/jcr/jcr/1.0/jcr-1.0.jar
> [INFO] 
> 
> [ERROR] BUILD ERROR
> [INFO] 
> 
> [INFO] Failed to resolve artifact.
> 
> Missing:
> --
> 1) javax.jcr:jcr:jar:1.0
> 
>Try downloading the file manually from:
>http://www.day.com/maven/jsr170/jars/jcr-1.0.jar
> 
>Then, install it using the command:
>mvn install:install-file -DgroupId=javax.jcr -DartifactId=jcr \
>-Dversion=1.0 -Dpackaging=jar -Dfile=/path/to/file
> Alternatively, if you host your own repository you can deploy the file 
> there:   mvn deploy:deploy-file -DgroupId=javax.jcr -DartifactId=jcr \
>-Dversion=1.0 -Dpackaging=jar -Dfile=/path/to/file \
> -Durl=[url] -DrepositoryId=[id]
> 
>Path to dependency:
>  1) 
> org.apache.sling:sling-jackrabbit-api:bundle:2.0.0-incubator-SNAPSHOT
>  2) javax.jcr:jcr:jar:1.0
> 
> --
> 1 required artifact is missing.
> 
> for artifact:
>org.apache.sling:sling-jackrabbit-api:bundle:2.0.0-incubator-SNAPSHOT
> 
> from the specified remote repositories:
>apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository),
>central (http://repo1.maven.org/maven2)
> 
> 
> I seem to be able to resolve the file from www.day.com if that helps you 
> I haven't manually installed it however. It seems weird that the error 
> occurs in the Install task segment which you advise to disable. I did 
> excute the build as:
> [EMAIL PROTECTED] sling]$ mvn -Dsling.install.skip=true install
> 
> Also tired exporting with JAVA_OPTS made no difference. Is latest SVN 
> trunk head code as of a few minutes ago.
> 
> [EMAIL PROTECTED] sling]$ mvn -version
> Maven version: 2.0.7
> Java version: 1.6.0_02
> OS name: "linux" version: "2.6.22.1-41.fc7" arch: "i386"
> 
> Any ideas?
> 
> Bradley
> 
> Bradley Beddoes wrote:
> > Hi Felix,
> > 
> > Felix Meschberger wrote:
> >> Hi Bradly,
> >>
> >> I am very glad to head, that you are trying to use Sling.
> >>
> >> Now, for what you can expect: Currently the code is in an early stage
> >> and we are constantly improving it almost on an hourly basis. Just today
> >> I fixed a few rough bugs around JSP compilation and execution reported
> >> by Edgar.
> > 
> > No problems for me I am used to working on the edge of new codebases its 
> > always interesting until things start becoming more stable.
> > 
> >>
> >> So, after getting the source, you have - for now - to build it by
> >> yourself and deploy. I added a page [1]  listing the steps to get a
> >> running Sling instance from the SVN checkout.
> >>
> >> Of course, it would be great if you would report any issues you find, so
> >> that we can improve the system :-)
> > 
> > Certainly will. Building now, have a few things to do at the present 
> > with our other big project so a response may be a few days.
> > 
> >>
> >> Hope this helps.
> > 
> > Certainly has given I come from an Ivy background not Maven. (Ivy is 
> > another incubating project at Apache which I personally prefer over Maven).
> > 
> > regards,
> > Bradley
> > 
> >>
> >> Regards
> >> Feli

MX4J and JSP-API

[Felix Meschberger]

Hi all,

I just removed the MX4J and jsp-api bundles as well as the commons
directory itself from the Sling project. The reason for this is on the
one hand, that the MX4J bundles are not required by Sling any more as
Sling requires Java 5, which includes JMX. On the other hand, the
jsp-api bund wrapping is now part of the Apache Felix Commons subproject
and therefore, there is no need to keep this in Sling.

Regards
Felix

Re: [jira] Closed: (SLING-22) problem with management console if no obr service is available

[Felix Meschberger]

Am Montag, den 24.09.2007, 06:51 -0700 schrieb Gerodolle (JIRA):
> sorry. I was not aware that the issue was reported.

No problem, better to report it twice than not at all.

Regards
Felix

Re: Configure managed services without metatypes

[Felix Meschberger]

Hi Anne,

Am Dienstag, den 25.09.2007, 15:35 +0200 schrieb GERODOLLE Anne
RD-MAPS-GRE:
> I am interested in the use of the sling console to manage OSGi configurations.

Cool :-)

> Currently, only managed services with datatypes are managed by sling.

Yes, this is a consequence of an issue with the current Felix SCR
implementation, which creates Configuration objects for each component
regardless of whether there might ever be configuration on the one hand
and oversight of configurations in the GUI on the other hand.

> For bundles that provide Managed Services, but no metatypes, I think it would 
> be interesting also to :
> - Display the current configuration.
> - offer the possibility to change the property values
> - offer the possibility to add a new property or remove a property.
> 
> Is there any work foreseen in that direction ? 

Definitely, yes.

Currently the basic code is there, that for configurations without meta
type data simply a text area is displayed which lists the configuration
properties as name value pairs.  We could do better here, in that we for
example list properties as proper text fields and allow for the addition
of properties by adding text fields..

You could of course help us in this respect by requesting this
functionality in a JIRA issue and - which  would be great - by providing
patches, if this would be possible for you.


Regards
Felix

Re: unresolved package on bundle start

[Felix Meschberger]

Hi Bradley,

Am Mittwoch, den 26.09.2007, 22:26 +1000 schrieb Bradley Beddoes:
> Step 5 at http://incubator.apache.org/sling/site/first-steps.html I cant 
> seem to find said directory? (commons or jsp-api-osgi)

This has been moved to the Apache Felix Commons subproject and is also
fixed on the first-steps page.

Regards
Felix

> 
> Bradley
> 
> Bradley Beddoes wrote:
> > Hi Guys,
> > As I am poking around Sling and slowly learning about how its built I am 
> > finding I have a few errors on startup and when trying to start stopped 
> > bundles of the following:
> > 
> > 26.09.2007 21:59:03 *ERROR* o.a.s.sling-console-web: Cannot start 
> > (org.osgi.framework.BundleException: Unresolved package in bundle 22: 
> > package; (package=org.apache.jackrabbit.ocm.mapper.impl.digester))
> > org.osgi.framework.BundleException: Unresolved package in bundle 22: 
> > package; (package=org.apache.jackrabbit.ocm.mapper.impl.digester)
> > at org.apache.felix.framework.Felix._resolveBundle(Felix.java:1650)
> > at org.apache.felix.framework.Felix._startBundle(Felix.java:1517)
> > at org.apache.felix.framework.Felix.startBundle(Felix.java:1470)
> > at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:348)
> > at 
> > org.apache.sling.console.web.internal.StartAction.performAction(StartAction.java:57)
> >  
> > 
> > 
> > 
> > Its pretty clear from that I am missing dependencies. My Question is how 
> > should I resolve it. This code is a few days old from trunk at this 
> > point in time, would an update assist?

Re: Simplifying our component api

[Felix Meschberger]

Am Freitag, den 28.09.2007, 14:23 +0200 schrieb Carsten Ziegeler:
> ComponentRequestDispatch

+1

We use our own implementation internally any just occasinally backed by
the servlet container's request dispatcher if actually needed.

> ComponentContext

+1

The method added here just complements the other getRequestDispatcher
methods by a signature taking a Content object. But this is just a
duplicate of the respective ComponentRequest method, so we do not loose
anything actually.

We also use our own implementation of the context for the components
anyway so have more control over the complete process. No need to have
our own interface, then.


> ComponentSession

+1

This is probably a remains of the days where the Component API still was
a sort-of-copy of the Portlet API, which it is not anymore.

If we are at it, why not go bit further down the road:

ComponentException
We keep that one extending the ServletException, to indicate Component
based exceptions, but we change all signatures to throw ServletException
where currently ComponentException is thrown.

ComponentFilter/ComponentFilterChain
These are actually more or less duplicates of the Serlvet API Filter and
FilterChain interfaces. We could drop these interfaces and just support
plain old Servlet Filters.

Component
The init, service and destroy methods are actually really the same (with
some minor signature differences) as the Serlvet interface methods. We
could have Component extend Servlet and just add the new methods - most
prominently the getId() method.


This of course brings me to another question: the init and destroy
methods of the Servlet, Filter, Component and ComponentFilter interfaces
are used to implement lifecycle support. In OSGi we do not actually this
because we either have a BundleActivator which starts and stops these to
register them as services or we have them declared using Declarative
Services which has activate and deactivate (other solutions might be
IPojo or DependencyManager). So why not have simple interfaces like:

   ComponentFilter with a single doFilter(request, response,
filterChain)
   Component with a single service(request, response)

objects and - already in the API - stipulate there is some environment
support for lifecycle and configuration management, which need not be
reflected in the API.

What do you think ?

Regards
Felix

Re: Avoiding Enumerations

[Felix Meschberger]

Am Freitag, den 28.09.2007, 14:23 +0200 schrieb Carsten Ziegeler:
> Our interfaces often use Enumerations as a return type. Personally, I

java.util.Enumeration is only used in Servlet API environment situations
(because the Servlet API declares them). Otherwise I try to use
java.lang.Iterator. I know, this is nit-picking :-)

> don't like returning enumerations as this makes reusing the returned
> object difficult and you can't just query how many objects are in the
> enumeration etc.
> 
> So I think we sould either return collections or typed arrays. Between
> these I have no real preference.

Depends on the use case. If the intended use is mainly enumeration of
the data, then Iterator is probably ok. It is also easier to prevent
modification of the collection itself. Otherwise we would probably have
create copies...

Additionally, the return type might also stipulate potential
implementations: Iterator allows for a lazy implementation, whereas
Collection or Array always require full data sets. We had on use case
once, where we declared a Set to be returned, which required a complete
scan of a big data set, whereas having defined it as Iterator would have
allowed for much faster iterative implementation.

So, I think, there is no global answer to this question ... But each
case should be identified and discussed.

Regards
Felix

Re: Simplifying our component api

[Felix Meschberger]

Am Freitag, den 28.09.2007, 17:33 +0200 schrieb Carsten Ziegeler:
> ...
> > objects and - already in the API - stipulate there is some
> environment
> > support for lifecycle and configuration management, which need not be
> > reflected in the API.
> > 
> Hmm, there is a certain advantage of using well known interfaces like
> Servlet and Filter. On the other hand, I agree that methods like init
> and destroy do not make that much sense in an OSGi world.
> I assume that Sling could call init and destroy when a service has been
> started or shutdown, so this shouldn't be much of problem.
> I think, if we can call these methods automatically, we should use
> Servlet and Filter - if we can't lets use our own interfaces.

We can as the Component interface is currently defined with an init and
a destroy method, which is called, when Sling takes note of the
respective instance. So we could as well call the Servlet's and Filter's
init and destroy methods. In fact, this is what is already done for JSP
scripts compiled into bundles as Servlets and dropping Component in
favor of Servlet would even simplify that one and remove the need to
implement a wrapper Component for the (JSP) Servlets.

Regards
Felix

Re: DIR was unexpected at this thime

[Felix Meschberger]

Am Samstag, den 29.09.2007, 14:55 -0700 schrieb paksegu:
> Hi, how do I go about this (DIR was unexpected at this time)
>
>   After running this on windows xp?
>
>
>for DIR in commons-io commons-fileupload commons-collections 
> commons-beanutils commons-codec \
>jsp-api commons-el cglib ; \
>do cd ${DIR} mvn package 
> org.apache.sling:maven-sling-plugin:2.0.0-incubator-SNAPSHOT:install ; cd .. 
> ; done

Well Windows shell scripting is really something completely strange and
weird  Anyway, you might have success with some like this:

for %d in (commons-io commons-fileupload commons-collections 
commons-beanutils commons-codec) do ( cd %d & mvn clean & cd .. )

Note that the loop variable must be a single character and the '&' is used to 
separate the commands.

Regards
Felix

Re: Continuum for Sling

[Felix Meschberger]

Am Montag, den 01.10.2007, 09:39 +0300 schrieb Jukka Zitting:
> Hi,
> 
> On 9/18/07, Jukka Zitting <[EMAIL PROTECTED]> wrote:
> > On 9/18/07, Carsten Ziegeler <[EMAIL PROTECTED]> wrote:
> > > The jcr api is not in a public repository, that's the main reason why
> > > our builds currently fail. Any idea how we can solve this?
> >
> > There was earlier a licensing issue that prevented the JCR API jar
> > from being placed on the public repository, but AFAIK that issue was
> > already resolved. I'll follow up within Day to push for the API jar to
> > be uploaded to the Maven repository.
> 
> The JCR API jar is now available on the central Maven repository.

Thanks.

I just updated the First Steps page removing the need for manual JCR
library installation.

Regards
Felix

Re: Simplifying our component api

[Felix Meschberger]

Hi all,

Starting from this discussion thread I created SLING-28 (Simplify the
Sling (aka Component) API, [1]) to start discussion non some real flesh
to the bone.

Please comment. Thanks.

Regards
Felix

[1] http://issues.apache.org/jira/browse/SLING-28


Am Freitag, den 28.09.2007, 14:23 +0200 schrieb Carsten Ziegeler:
> I think we can further simplify our component api and base more on the
> well-known servlet-api.
> 
> ComponentRequestDispatch
> 
> I think we can just remove this one and directly use the
> RequestDispatcher interface. The implementation we provide can inspect
> the passed request object - if its a ComponentRequest it might adds a
> special handling for that.
> 
> ComponentContext
> 
> If we remove the ComponentRequestDispatcher there is no need for an own
> ComponentContext anymore, and we can directly use the ServletContext.
> 
> ComponentSession
> 
> If we remove the ComponentContext, we can also directly use the servlet
> Session object. Currently the ComponentSession has some methods for
> handling component private session data. We could move this into an
> utility class (like the ComponentSessionUtil) - I think session data and
> especially component private session data will be rarely used, so
> there shouldn't be a problem in moving this to an utility class.
> 
> WDYT?
> 
> Carsten
> 
> 

Re: Component -> Slinglet?

[Felix Meschberger]

Hi all,

Based on Carstens proposal to simplify the Sling (formerly known as
Component) API in [1] I created a JIRA issue [2] and a prototype API in
the new sling-api project.

If we go this route of simplifying the API, the discussion for a name is
probably void, as there is no such thing as a Component anymore ...

Regards
Felix

[1]
http://www.mail-archive.com/sling-dev@incubator.apache.org/msg00177.htm
[2] http://issues.apache.org/jira/browse/SLING-28

Am Mittwoch, den 19.09.2007, 08:54 +0200 schrieb Bertrand Delacretaz:
> Hi Slingers,
> 
> The "Component" name, used by Sling to designate objects that render
> parts of content, is a bit confusing, especially w.r.t. OSGi
> Components which are software modules.
> 
> We talked about this at work with Felix, Carsten and others, and we
> agree that a more specific name would help in understanding,
> describing and documenting Sling.
> 
> How about Slinglets?
> 
>   "Slinglets are used by Sling to render pieces of content"
> 
> -Bertrand

Re: Simplifying our component api

[Felix Meschberger]

Am Dienstag, den 02.10.2007, 11:46 +0200 schrieb Carsten Ziegeler:
> Felix Meschberger wrote:
> > Hi all,
> > 
> > Starting from this discussion thread I created SLING-28 (Simplify the
> > Sling (aka Component) API, [1]) to start discussion non some real flesh
> > to the bone.
> > 
> > Please comment. Thanks.
> > 
> >
> Looks very good to me, thanks, Felix!

Thanks.

> Two minor things (going back to my enumeration discussion :) )
> - SlingRequest#getChildren should return an iterator

Basically I agree. I propose Enumeration as this goes in line what is
used throughout the Servlet API.

> - SlingRequest#getResponseContentTypes() should return a String array

Sounds logical. On the other hand: is this method required ??

Regards
Felix

Re: Sample App

[Felix Meschberger]

Hi Ransford,

Sorry for the delay. There was in fact no sample app for Sling except a
small testing bundle I made for myself some time ago. After brushing it
up a bit and adding more content and more diverse use cases, I just
commit it as a new "sample" project to the Sling trunk.

You may install this bundle project to sling and then access the
http://localhost:8080/sample/content/home.html page (assuming you are
running Sling off the sling-app project). It just contains three pages,
of which two are rendered entirely by JSP located in the Repository and
the third (/sample/content/home/moreinfojsp.html) has its inner content
(entitled "JSP Rendered Content") rendered by a JSP compiled into the
bundle. The navigation to the left is rendered by a Navigation component
"called" with synthetic Content object from
the /sample/components/page/jsp/start.jsp.

I have put adding more text regarding this sample up to the Sling site
on my agenda 

Have fun (and provide feedback) !

Regards
Felix

Am Sonntag, den 30.09.2007, 16:12 -0700 schrieb paksegu:
> Hi,
>   Is there any sample app to see sling in action?
> 
> 
> Ransford Segu-Baffoe
> 
> [EMAIL PROTECTED]
> 
> https://serenade.dev.java.net/
> http://www.noqturnalmediasystems.com/
>
> -
> Catch up on fall's hot new shows on Yahoo! TV.  Watch previews, get listings, 
> and more!

Re: Simplifying our component api

[Felix Meschberger]

Hi,

Am Dienstag, den 02.10.2007, 13:45 +0200 schrieb Carsten Ziegeler:
> Felix Meschberger wrote:
> >> - SlingRequest#getResponseContentTypes() should return a String array
> > 
> > Sounds logical. On the other hand: is this method required ??
> > 
> Hmm, unless we want to convert responses from components (eh sorry
> servlets) from one content type to another, we should remove this method
> and change the docs for getResponseContentType(), I think. The content
> type returned there is not the prefered one but the required content type.
> Otherwise we might end up with one component...hmpf...servlet responding
> with content type a and another one deciding to respond with content
> type B. Both included into a single response might create a mess.

Ok, removed that method.

Regards
Felix

Sling @ ApacheCon US 07

[Felix Meschberger]

Hi all,

Just wanted to let you know, that my proposal for a Feather Talk
presentation of Sling at ApacheCon US 07 has been accepted. It is
tentatively scheduled for Thursday at 10:00.

See you there !

Regards
Felix

From Component API to Sling API (was: Simplifying our component api)

[Felix Meschberger]

Hi all,

After the introduction of the topic by Carsten and some initial
discussion, I created issue SLING-28 [1] and committed a first
prototype. After having it around for some days now, I want to call for
a final discussion on this topic.

Is there anything, which would go wrong in this direction ? Would it
basically make sense ? Have we forgotten something ?

Unless a very lifely discussion now starts on this, I would call for a
vote on this change on monday.

Thanks and Regards
Felix

[1] https://issues.apache.org/jira/browse/SLING-28

Sling Report

[Felix Meschberger]

Hi all,

As we are new to the incubator, we have to report monthly and the
reports are due again :-)

I created a page on our wiki [1] to catch what we ultimately would
report. Please add anything you might feel needed such that we can
finalize the report by Oct. 10.

Thanks and Regards
Felix

[1] http://cwiki.apache.org/confluence/x/vAkB

Web Framework Integration (was how to build sling components with complex user interaction and write capabilities?)

[Felix Meschberger]

Hi Edgar,

Sorry for the belated answer, I was busy fixing issues and extending
Sling over the last few days.

Taking your original mail apart for easier tracking of the issues
raised.

Am Montag, den 24.09.2007, 11:34 -0300 schrieb Edgar Poce:
>  First of all congratulations for the good work!. I've been playing
> with sling the last few days and I like the framework very much.

Thank you very much !

As you may have seen I also committed a small sample project which shows
some of the functionality of Sling in action.

> My first impression is that Sling is an integration framework. My
> understanding is that Sling provides the glue to integrate different
> applications but it doesn't provide the tools to build rich web based
> applications as others web frameworks do, e.g. wicket. Is this
> impression correct? and in case it is, would it be a good idea to use
> another web framework to build a Sling component?.

You are probably right, yes. Sling itself provides close to no web
framework support. As such we will probably have to build integration
points for other web frameworks of which Wicket in fact came to my mind
first. What I am thinking of is some Component/Content implementations
to adapt Wicket into Sling. Yet, I have to admit, that I did not yet do
any research in this direction.

Of course any suggestions and patches in this direction would be very
welcome.

Regards
Felix

Components Writing Content (was: how to build sling components with complex user interaction and write capabilities?)

[Felix Meschberger]

Hi,

Am Montag, den 24.09.2007, 11:34 -0300 schrieb Edgar Poce:
> Another doubt is what's the recommended practice to create a simple
> sling component with write capabilities, how the component should
> access the jcr repository to perform write operations? and how the jcr
> session should be acquired?

The nice thing about Sling is, that you do not have to write the data
yourself by acquiring a session and calling all these JCR methods. You
just take the Content you get from the request, update it using the
Content's setter methods and call the ContentManager.store(Content)
method. That is all.

For example: Consider you have a TextComponent and a TextContent, where
the TextContent has a title and a text field. In your
TextComponent.service() method you might do the following:

if ("POST".equalsIgnoreCase(request.getMethod())) {
  TextContext textContent = (TextContent) request.getContent();
  textContent.setTitle(request.getParameter("title"));
  textContent.setText(request.getParameter("text"));

  ContentManager contentManager = (ContentManager) 
request.getAttribute(org.apache.sling.core.Constants.ATTR_CONTENT_MANAGER);
  contentManager.store(textContent);
  contentManager.save();
}

This is more or less the idea. If you look at the
org.apache.sling.core.components.DefaultComponent you will see more
elaborate code showing this intention.

To create content, you would just instantiate your Content object, set
the properties and call the ContentManager.create(String path, Content
content) (currently missing, see SLING-44 [1]) to store the content at
the given path.

Hope this helps.

Regards
Felix

[1] https://issues.apache.org/jira/browse/SLING-44

Move ContentManager to Sling API

[Felix Meschberger]

Hi all,

Upon replying to Edgar's question regarding writing Content, I came to
thinking, that the ContentManager is a core interface of Sling and
probably should be made available more prominently. The most prominent
location for an interface in Sling would be the Sling API itself.

What do you think of moving the o.a.s.content.ContentManager interface
to the Sling API and provide it through the ComponentRequest instead of
having to access a request attribute:

public interface ComponentRequest extends HttpServletRequest {

public ContentManager getContentManager();

}

What do you think ? If feedback is positive, I would also include this
in the Sling API proposal (SLING-28).

Regards
Felix

Re: Move ContentManager to Sling API

[Felix Meschberger]

Am Freitag, den 05.10.2007, 17:14 +0200 schrieb Carsten Ziegeler:
> > What do you think ? If feedback is positive, I would also include this
> > in the Sling API proposal (SLING-28).
> > 
> I'm not sure - it definitly makes repository based components much
> easier, but draws in some stuff into the (now simple) sling api and the
> core. As ContentManager does not have any further dependencies this
> seems to be ok.

That is the point: The ContentManager makes no actual references to any
concrete storage, it is only its (currently only one) extension
JcrContentManager which brings in the JCR Repository. But this would
remain in the content bundle.

> 
> So I'm +0 on this :)
> 
> I'm wondering if it is sufficient to have a single content manager in
> the application? Or could it be that some components might use a
> different content manager than others? For example some components
> writing/reading from one workspace or others doing it with another
> workspace?

Well having the getContentManager method would allow for
ComponentRequestWrapper implementations to overwrite this method and
return a different ContentManager while still allowing access to the
original one by just unwrapping and wrapped requests. This is not as
easy with the request attribute based solution.

On the other hand, nobody is hindered to get the
JcrContentManagerFactory service and acquire a different
JcrContentManager for specific use cases.

Regards
Felix

Re: Move ContentManager to Sling API

[Felix Meschberger]

Hi Torgeir,

Am Freitag, den 05.10.2007, 17:25 +0100 schrieb Torgeir Veimo:
> Having done some work recently with Day Communique, one of the  
> annoying things was that it subclasses HttpServletRequest.

Can you please elaborate on this ? Because we initially did not extend
HttpServletRequest but found that extending it would make the
implementation much easier in multiple places not the least support for
running JSP scripts.

Regards
Felix

Re: Move ContentManager to Sling API

[Felix Meschberger]

Am Freitag, den 05.10.2007, 21:36 +0100 schrieb Torgeir Veimo:
> I feel it's cleaner to fetch the manager from some sort of factory  
> instance. It wouldn't expose the implementation details of how the  
> manager is kept local to the request, nor does it make any dependent  
> code reliant on any such implementation details staying stable.

Well, the implementation in fact is to use a factory to get the
ContentManager. Look at the ContentResolverFilter class.

But this is different from the question on how we provide the
ContentManager to components: As the return value of a declared method
or as a well known request attribute. The first solution locks the
Component into the API and forces the implementation of the API itself
into providing a ContentManager object.

The second solution of just having the request attribute makes the
existence of a ContentManager an implementation detail of the API
implementation but locks the Component into the API implementation,
which IMHO is more of a problem than being locked into the API.

> As you say yourself, you now keep the manager as a request-scoped  
> attribute, but would like to make a subclass of HttpServletRequest  
> include a method to retrieve it. If you used a factory to retrieve  
> the manager, that change wouldn't have any impact on any code that  
> uses that manager.

The ContentManager is core to Sling - without the ContentManager Sling
cannot operate because it is used by Sling - the ContentResolver
implementation to be precise - to resolve paths to Content instances. So
Sling cares to have the ContentManager handy and just provides it to
components to manage the Content.

Regarding extending HttpServletRequest: The ComponentRequest interface
already extends the HttpServletRequest interface, so adding a getter for
the ContentManager would just add to the ComponentRequest interface.

Regards
Felix

Re: From Component API to Sling API (was: Simplifying our component api)

[Felix Meschberger]

Am Montag, den 08.10.2007, 08:58 +0200 schrieb Bertrand Delacretaz:
> I *think* the model below more or less matches the current resource
> processing model, but makes it a bit more general and less dependent
> on JCR. Making it more generic and more plainly REST-oriented might
> help drive Sling acceptance, what do you think?

Definitely a good idea. I am not sure, I completely understand. See
below.

> ** The Sling request processing module (RPM) **
> 
> The RPM helps manage Resources in a REST way, using java code or
> scripted request processors.
> 
> As HTTP Requests come in, they are pre-processed by a series of
> ServletFilters, to select the Resource to process, find out more about
> the client browser and locale, etc.
> 
> The ResourceResolver filter selects the Resource that the current
> request applies to.

This is currently called the ContentResolver and a Resource is currently
called Content manifested by an implementation of the Content interface,
right ?

> The Resource is represented by an URL, using custom procotol handlers
> to map to the actual resource providers (for example,
> jcr:/default/content/mypage to point to a JCR repository resource).

Sounds interesting. So a Resource (aka Content) does not only have a
path but an URL, which might as well be file://... for filesystem based
resources ? Very nice in fact.

Not sure what you mean by "custom protocol handler": is this something
we would have to define an API for or are you referring to the
URLStreamHandler interface ?

> The ServletResolver selects the HttpServlet that will be used to
> process the Resource, and maps the Resource to a base (resource) path
> under which scripts can be found to process the request.

Yes, this task is currently not manifested by a named interface but
implemented by an internal class named ComponentResolverFilter. This
filter yields a Servlet (aka Component) for the Resource (aka Content).

Currently Components are registered OSGi services which are selected by
name. How would you envision resolution of Servlets from the Resources ?
Would the Content.getComponentId be replaced by something which returns
an URI to be interpreted in the context of the used scheme, such as
jcr:, file:, oder osgi-service: ?

Thinking about it, this seems interesting as for example, the
DefaultContent class currently returns the primary node type as its
Component ID (if not overwritten). It could return
jcr:/types/ which could be handled by the JCR handler to find
a Resource which actually is a Servlet ?? Other resources might use
osgi-service: and allow the OSGi service handler to select
a registered Servlet service ?

And then the jcr:/types/ resource may either be another
"descriptor" like today's ScriptedComponent or it may actually be a JSP
script or the root under which the JSP script would be found ? Would
then this JSP script or JSP selector script root have to be of a certain
node type ?

> Like Resources, Scripts are found and loaded using URLs and custom
> protocol handlers.
> 
> The default SlingHttpServlet looks for a request processing script
> based on HTTP uniform interface names, like "get.jsp", "post.jsp" or
> "put.rb" or "delete.js", using a configurable order of possible script
> file extensions which map to script interpreters.

So, in fact the SlingHttpServlet would be much like today's
ScriptedComponent of the scripting-core bundle ?

I like the enhancement of using such uniform names based on the HTTP
method. Would there be some fallback mechanism, say e.g. if there is no
post.* method for a POST request, we would take a get.* ?


> 
> This processing chain is built from OSGi bundles, to make each of its
> elements easy to implement, test and replace.
> 
> -Bertrand

Re: From Component API to Sling API (was: Simplifying our component api)

[Felix Meschberger]

Am Montag, den 08.10.2007, 12:08 +0200 schrieb Bertrand Delacretaz:
> Yes, so my proposal is not much different to what we have now, except
> that, as we see below, Content and Servlets are more decoupled from
> JCR, mostly by using URIs instead of paths.

I like this (further) decoupling. This is what I tried to accomplish by
factoring the ContentManager (no JCR referencees) out of the
JcrContentManager (uses JCR).

> Exactly, the Resource would only have an URL that points to it.
> 
> > ...Not sure what you mean by "custom protocol handler": is this something
> > we would have to define an API for or are you referring to the
> > URLStreamHandler interface ?...
> 
> I'm not sure if URLStreamHandler is enough. Cocoon does similar things
> using the Excalibur source resolver mechanism, see
> http://excalibur.apache.org/sourceresolve/index.html
> 
> Having something similar (or reusing that code) in Sling might help a
> lot in decoupling the resource processing from the actual resources
> and their data sources.

I looked at the Excalibur resolver. This sure lookes very interesting. Yet, I 
have some missing links:

(1) The Excalibur Source provides access to file-like data, where the
intent of our Content was to access mainly "structured" data in terms of
properties and child objects with properties.

(2) The Excalibur Source is intelligent in the sense, that it may
implement additional interfaces like Modifiable, Traversable, ...

Trying to map this on our ContentResolver and Content, I would probably
get something like this:

* A request URL (e.g. http://xy.com/some/index.html) is resolved to some
Resource URL (e.g. jcr:/some/index).
* The Resource URL is resolved to a Resource instance providing
operative API comparable to the API provided by the Excalibur
MovableSource, ModifiableSource, ...
* The Resource provides a method getContent() returning the "mapped"
Content - in case of JCR this might be Jackrabbit OCM mapped, in case of
a filesystem File this might be an XML DOM or a loaded Properties object
(depending on the MIME-type).

What would then be the consequences for the Sling API ? Of course there
is no single ContentManager but comparable to Excalibur something like
ResourceResolver (mapping scheme to ResourceFactory), ResourceFactory
and Resource.

> In the simple case (which is probably all we need now), the Servlet
> URI would be an OSGi service URI, for example
> osgi-service:/ as you suggest.

or even osgi-service:

where ldap filter would be a filter for
BundleContext.getServiceReference(String clazz, String filter) - to
simplify matters a default might be just a class name if the filter
expression does not start with a "(".

> ...

Regards
Felix

Re: Move ContentManager to Sling API

[Felix Meschberger]

Am Montag, den 08.10.2007, 10:44 +0100 schrieb Torgeir Veimo:
> My concern for subclassing core interfaces in the servlet API is due to
> deployment and testing concerns. If you have an API where you allow
> users of the API to rely on there always being subclassed instances of
> HttpServletRequest available, then you also lock any deployment
> configuration into always providing it. 

This was my initial concern with extending the
HttpServletRequest/Response a long time ago :-) In the meantime, I came
to believe, that it is far less problematic to do it this way to provide
some magical to get the additional data.

Regarding Sling, the goal is to implement a piece of code to run inside
Sling and here you expect the additional data available from Sling. If
you implement something, which you might want to run inside of Sling and
inside a standard Servlet Container, you would implement your something
in a way as to be able to handle "missing Sling".

> 
> With my experience with different servlet containers and deployment
> models, one cannot always ensure that specific servlet filters are
> handling requests at all times in a given servlet container. Eg. try
> getting servlet filters to work 100% of the time for error pages in
> tomcat. Thus, I always prefer a mechanism for retrieving manager
> instances which do not rely on subclassing HttpServletRequest or
> employing filters.

ServletFilters in Servlet Containers is always an issue, I agree.

> 
> The testing issue is a bit more simple, mainly concerned with making it
> easier to test code by using interfaces and classes that can easily be
> mocked. HttpServletRequest is not the best in that regard.

Agreed, but ... Objection, this is suggestive :-) 

Regards
Felix

Re: [RT] breaking Sling into smaller pieces?

[Felix Meschberger]

Am Dienstag, den 09.10.2007, 13:36 +0200 schrieb Bertrand Delacretaz: 
> I suggest the following parts:
> 
> 1) Scriptable JCR-based REST resource processing framework (sling-core-*)
> This is the clear focus of the project, other modules are only here to
> support it.
> 
> This module:
> -Maps incoming HTTP requests to resources (JCR nodes or OCM-mapped objects)
> -Uses servlets or scripts to process the requests based on the HTTP
> uniform interface (get, post, put, delete).

How is a resource represented ? I think having an abstraction between
the framework and the real data (be it an OCM mapped object or a JCR
node or a plain file or whatever) helps keeping the framework generic a
lot. Otherwise we would be supporting special cases right from the
start.

Looking at it from this point of view, the Content interface is
certainly a starting point for such an abstraction. Whether the real
data is then provided as part of an implementation of the Content
interface or by a data provider using the Content object as an address
much like an URL is to be discussed.

> A simple example webapp allows developers to test this without
> spending more than 15 minutes to download, run and start exploring it.

Sounds good.

> This is usually the only module that web developers need to learn.
> 
> If possible, the API of this module is independent of OSGi, but that's
> not a priority.

Agreed. Currently, the Sling API is completely agnostic of OSGi. The
implementation of the API, though, is not OSGi agnostic (of course), but
this is IMHO acceptable.


> 3) Scripting tools (sling-scripting-*)
> JSP compiler, future interfaces to other scripting engines, etc.
> 
> These tools could also be useful outside of Sling, but it is not our
> priority to make them standalone.

Depends on how much they integrate with sling-core. I think it is more
the other way around: We should care to reuse as much as possible of
existing tools and just integrate them into sling.

Providing a "glue" to Wicket and others come to mind here.

> If we agree on this, the next step might be to reorganize our code
> base, with those four Maven modules at the top (sling-core,
> sling-osgi, sling-scripting and sling-jcr), and sub-modules below
> them. This entails little or no changes to existing code, just moving
> modules around and renaming some of them to use their parent module's
> name as a prefix.

Well, I tink, if we do not modify anything regarding the resolution of a
request to some piece of code to act upon the request, that is true. But
I fear, if we talk about modifying the handling of the resource (or
Content with OCM Mapping) as we have it today, there might be more to
do ...

Unless I completely misunderstand your thread, there is some changes
ahead.

Regards
Felix

Re: [RT] breaking Sling into smaller pieces?

[Felix Meschberger]

Am Dienstag, den 09.10.2007, 16:35 +0200 schrieb David Nuescheler:
> For me sling has a very simple main purpose:
> It is the JCR centric web application development
> framework of my dreams.

Yes, true, but ... "JCR-centric" is a very vague term in itself :-)

> I think being more osgi than web framework A or
> more restful than framework B does not really justify
> slings existence. I think it is crucial for the success
> of sling to be able to argue why it is different,
> not so much why it is incrementally better.

I do not completely agree here: There are multiple requirements for a
web application framework: Extensibility, Manageability, Stability,
Ease-of-Use, Data Persistence come to mind; certainly there are more.

Now, Sling is probably not revolutionary with respect to a single
requirement (except with regard to Data Persistencew) in that it is
better to extend than framework X, better to manage than framework Y
etc. All-in-all, when counting all parts together, you get a framework
which is dramatically "better" than other frameworks in the field. And
this is IMHO the real value of Sling.

> I think putting the Content Repository at its core
> certainly gives sling a very clear and easy to
> express differentiator.

This is what we do, except that we do not lock the Sling API into the
JCR but say, a Sling application may depend on Sling providing the data
to work with in a uniform fassion and that Sling applications do not
have to care much about persistence issues. This is IMHO a big
differentiator to most if not all frameworks around.

Currently, Sling is of course locked into JCR, as the Content
provisioning only supports JCR and authentication depends on and
requires the JCR repository.

Regards
Felix

Re: Wiki accounts and change notifications

[Felix Meschberger]

Hi,

Am Mittwoch, den 10.10.2007, 12:13 +0300 schrieb Jukka Zitting:
> Do all committers already have Confluence accounts with enough karma
> to edit the wiki?

I granted karma to the Sling Committers I could identify in Confluence.

> What's the process for setting up the accounts and
> giving out the required karma?

I fear, I failed to inform about this matter on the list. A can remember
that I wanted to do this, but never came around to do it. Sorry for
that. So here we go:


* User Account: A user account in confluence can be created by anyone by
themselves. You just sign up for new account from the login page.

* Editing Karma: As the Wiki is the basis for our official site, we have
to limit write karma to those people having submitted a Contributors
License Agreement [1] on file. I can grant this karma on notice.

> Could we set up the wiki to send change notifications to sling-commits?

Yes, I just did it. Thanks for the reminder ...

Hope this helps.

Regards
Felix

[1] http://www.apache.org/licenses/

Re: Sling Report

[Felix Meschberger]

Thanks for the addition. I updated the report on our wiki and submitted
it to the Incubator reports.

Regards
Felix

Am Mittwoch, den 10.10.2007, 12:10 +0300 schrieb Jukka Zitting:
> Hi,
> 
> On 10/5/07, Felix Meschberger <[EMAIL PROTECTED]> wrote:
> > I created a page on our wiki [1] to catch what we ultimately would
> > report. Please add anything you might feel needed such that we can
> > finalize the report by Oct. 10.
> 
> Thanks for the initiative, the report looks good!
> 
> As a closure since the last report I'd mention that also Juan's
> committer account is now set up.
> 
> Also, Bill Rowe asked for some steps towards graduation, and I think
> we should perhaps already outline the main issues before graduation.
> My take would be:
> 
> Issues before graduation
> 
> * Make an incubating Sling release
> * Grow a more diverse community (so far only commits from Day employees)
> 
> BR,
> 
> Jukka Zitting

Re: [RT] breaking Sling into smaller pieces?

[Felix Meschberger]

Hi all,

For completeness sake (Bertrand already noted this page in another
post): I put up a quick recount of the current state of the discussion
in our Wiki at http://cwiki.apache.org/SLING/sling-api-redesign.html.

Regards
Felix


Am Mittwoch, den 10.10.2007, 09:43 +0200 schrieb Bertrand Delacretaz:
> On 10/10/07, Felix Meschberger <[EMAIL PROTECTED]> wrote:
> > Am Dienstag, den 09.10.2007, 13:36 +0200 schrieb Bertrand Delacretaz:
> ...
> > > -Uses servlets or scripts to process the requests based on the HTTP
> > > uniform interface (get, post, put, delete).
> >
> > How is a resource represented ? I think having an abstraction between
> > the framework and the real data (be it an OCM mapped object or a JCR
> > node or a plain file or whatever) helps keeping the framework generic a
> > lot. Otherwise we would be supporting special cases right from the
> > start...
> 
> Maybe a Resource could be an interface with just a getURI()
> method...Sling itself might not care exactly what the Resource is,
> maybe only the user's code needs to know (for rendering, to select
> which Servlet to use, etc).
> 
> > ...Currently, the Sling API is completely agnostic of OSGi. The
> > implementation of the API, though, is not OSGi agnostic (of course), but
> > this is IMHO acceptable
> 
> Cool - of course we'll take full advantage of OSGi at the
> implementation level, but making it possible for newbies to understand
> Sling without caring about OSGi might help.
> 
> > >... These tools could also be useful outside of Sling, but it is not our
> > > priority to make them standalone.
> >
> > Depends on how much they integrate with sling-core. I think it is more
> > the other way around: We should care to reuse as much as possible of
> > existing tools and just integrate them into sling.
> 
> ok, agreed.
> 
> > ...Providing a "glue" to Wicket and others come to mind here...
> 
> Now that'd be really cool!
> 
> > ...I fear, if we talk about modifying the handling of the resource (or
> > Content with OCM Mapping) as we have it today, there might be more to
> > do ...
> 
> Yes, I have not evaluated precisely how much work this needs. But it
> sounds like the right thing to do ;-)
> 
> -Bertrand

Re: Microsling, first shot, feedback is welcome

[Felix Meschberger]

Hi Betrand,

Cool !

"ScriptResolution" works somewhat differently as in current Sling, where
the Component (aka Servlet) is resolved from the Content (aka Resource)
and either directly implements the actions or selects the concrete
script for the request from a limited set of scripts (generally one to
only a very few number). As such the "presentation framework"
integrations (VelocityTemplatesServlet, RhinoJavascriptServlet) operate
in the "background" at the service of the Component and its script
depending on the script selected.

I am also not sure, whether script resolution according to the resource
path is actually a good idea (of course it serves as a simple
placeholder for a general principle).

So further discussion should probably concretate on
Servlet/ScriptResolution, right ?

Or am I missing something ?

Regards
Felix


Am Donnerstag, den 11.10.2007, 18:44 +0200 schrieb Bertrand Delacretaz:
> Hi Sling community,
> 
> I think the current revision of
> http://svn.apache.org/repos/asf/incubator/sling/whiteboard/microsling
> is worth having a look at if you're interested in the current API /
> redesign discussions.
> 
> Fifteen minutes should be enough to build it and have a look at how it
> works, provided you have a JDK 1.5, Maven 2.0.7 and a WebDAV client
> installed. The README.txt explains how to run it.
> 
> I have attached the current microsling webapp homepage (which explains
> what it is in more detail) to
> https://issues.apache.org/jira/browse/SLING-47, just in case.
> 
> -Bertrand

Re: From Component API to Sling API

[Felix Meschberger]

Am Donnerstag, den 11.10.2007, 22:10 +0200 schrieb Tobias Bocanegra:
> > Therefore we always had the dream in Cocoon to use plain java.net
> > classes to access any resource. In the last weeks I developed the
> > excalibur jnet package which hopefully makes this dream come true in the
> > near future. It is a package which is able to install own url handlers
> > in a webapp environment and which is able to make source implementations
> > available through java.net.URL class. The idea is to use well known api
> > and classes to access custom stuff. Even for the XML streaming stuff, I
> > created a prototype which (ab)uses the getContent(Class[]) method.
> 
> i have some concerns if the java.net.URL stream handler works well
> with the OSGI framework since the handlers/factory is a static field
> in the URL class. i just remember some visibility issues.

Well actually, the OSGi core spec is well aware of the restrictions of
the java.net.URL class allowing specifying the URLStreamHandlerFactory
only once in a lifetime (of the VM). And therefore, there is a spec
enabling bundles to register (and unregister) URLStreamHandlerFactories
at will. Felix contains some basic implementation, which fails under
certain circumstances, a first enhanced implementation of mine has not
been used due to uncertainties regarding licensing (the implementation
was developped looking very closely at the Eclipse implementation)...

So implementing URLStreamHandlerFactories in an OSGi environment is not
that big an issue as it is usually.

But I agree with Roys remark of java.net.URL. If find it way to heavy,
so using just a string for URI or the URI class (which just operates on
a string level) might be a better way to go.

Regards
Felix

Regards
Felix

Re: microsling script resolution rewritten (was: Microsling, first shot...)

[Felix Meschberger]

Hi all,

... Oh yeah, and this one gets lengthy, too ...

I have to agree, that microsling really grasps a majority of Sling and
may even be the PHP-programmers dream-come-true :-) Thinking about what
microsling is and where it may be positioned with respect to Sling, I
imagine, we could define microsling as the entry-level Sling and Sling
the "Big One".

As such microsling would have a MicroSlingServlet which has pretty much
everything wired and no OSGi, that is no real lifecycle management and
extensibility. Just the core request handling and scripting dispatching.
Besides this, the use of API would be the same as for the real Sling,
esp. the Resource and HttpServletRequest/Response extensions.

In short, the "features" of microsling are:

* Repository and Session acquiry: Repository is expected as
ServletContext attribute, the
  credentials for the session are acquired through HTTP Basic
Authentication, if missing
  either an anonymous session may be used or a 401 may sent back.
* Resource Resolution: Implementation fixed after session acquiry tries
to cut off the
  URL string until a node is found. Parts of the URL not "used" by the
node node path are
  set on the Resource as selectors, extension and suffix.
* Object Mapping: After Resource Resolution, the node might be mapped to
an object given
  a object mapping would be implemented and a mapping would exist.
* Resource interface: Provides access to the Node (getNode()) as well as
the other parts
  of the URL, such as the extension, selectors and suffix. The
optionally mapped object
  is available as the resource data (getData()) of type Object. The
resource type is
  derived from a special property in the node and defaults to the
primary node type
  name if no such property exists.
* ScriptHandlers: Predefined map of handlers indexed by the script
extension.
* ScriptResolution: Find a script by first looking for a servlet
registered to handle
  resources with the type fo the resource (in microsling there will
typically be
  none). If not found, create a script path from the resource type, the
selectors and
  the request method to locate a script, e.g.: scriptPath is 
 ${scriptRoot}/${resourceType}/${selectors}/${method}.*
  The resolver would get nodes and take the extension of the node(s)
found to use as the
  script type (e.g. vlt or js) to index the ScriptHandlers map. If any
entry is found
  the ScriptHandler is called with the script found. If none would be
found some
  fallback mechanism would be implemented.

Now, to get from microsling to Sling, the MicroSlingServlet is replaced
by the SlingServlet (currently called ComponentRequestHandlerImpl ...)
but the same basic code might be used with some extensions:

* Repository Provisiong: More flexibility might be provided by making
the repository available
  through some OSGi (factory) service
* Authentication: More authentication methods than just HTTP Basic may
be supported
* Resource Resolution: In addition to just taking the URL as is,
different mappings might
  be supported
* ScriptHandlers: Registration of ScriptHandlers is not hard coded but
flexible through
  OSGi services
* ScriptResolution: Add functionality to register Servlets for certain
resource types

The net result of this would be that we do not just have a simple quick
start microsling but also the basis for the full Sling. People starting
with microsling may easily migrate to real sling without having to touch
the scripts. And we may reuse much of the microsling code to implement
the real sling and thus reduce and prevent code duplicity.

Regards
Felix


Am Freitag, den 12.10.2007, 12:35 +0200 schrieb Bertrand Delacretaz:
> On 10/11/07, Felix Meschberger <[EMAIL PROTECTED]> wrote:
> 
> > ...I am also not sure, whether script resolution according to the resource
> > path is actually a good idea...
> 
> You're right, that was a bad idea...I have added a
> 
>   String getResourceType();
> 
> method to the Resource interface, which is meant to point to a
> repository location where scripts and other definitions can be found.
> 
> And rewritten the SlingScriptResolver to use this.
> 
> Script names are also based on the request extension now, so for
> example if a scripting SlingServlet is looking for a script with a
> "vlt" extension:
> 
>   When rendering a Resource with resourceType=/some/stuff
> 
>   For a GET request with  with URL extension=html
> 
>   The SlingScriptResolver looks for a script named
> /sling/scripts/some/stuff/get.html.vlt
> 
> The updated microsling-homepage.html attached to
> https://issues.apache.org/jira/browse/SLING-47 contains links to
> source code for a quick code walkthrough.
> 
> Do you guys think we need to add more stuff to microsling to reflect
> the core ideas of the Sling request processing? ResponseFilters maybe?
> 
> -Bertrand.

Re: microsling script resolution rewritten (was: Microsling, first shot...)

[Felix Meschberger]

Hi,

Some notes regarding the current state of Script resolution: (1) The
script is selected by the HTTP method name. So I see no reason to also
call a ScriptHandler method of the same name. In fact, the current
SlingServlet API pretty much limits the HTTP methods supported, which
IMHO is not really a good idea. Rather the ScriptHandler should just
have a single service method which is called with the request, response
and resolved resource.

(2) I am not sure whether resolving the script with the request
extension is useful. Rather I would use the "selectors" of the request
URL (the dot-separated parts between the node path and the extension) as
further script selectors.

Regarding the resource: I think, we should provide the JCR item to which
the request URL resolved with a proper method, such as "Item getItem();"
and leave the "Object getDate();" method to the object mapping. In
addition, I would provide the selectors, extension and suffix in the
Resource, too, as proposed on the Wiki page.

Providing the JCR Item and mapped object in the Resource interface
itself would of course stipulate, that microsling (and hence Sling, see
my other posting in this thread) would be based on the repository and/or
mapping and there would be no other source such as the filesystem etc.
Of course for "synthetic" Resources, the getItem() and getData() methods
might return null if there would be no more data than the path/URI and
the resource type.

Regards
Felix

Am Freitag, den 12.10.2007, 12:35 +0200 schrieb Bertrand Delacretaz:
> On 10/11/07, Felix Meschberger <[EMAIL PROTECTED]> wrote:
> 
> > ...I am also not sure, whether script resolution according to the resource
> > path is actually a good idea...
> 
> You're right, that was a bad idea...I have added a
> 
>   String getResourceType();
> 
> method to the Resource interface, which is meant to point to a
> repository location where scripts and other definitions can be found.
> 
> And rewritten the SlingScriptResolver to use this.
> 
> Script names are also based on the request extension now, so for
> example if a scripting SlingServlet is looking for a script with a
> "vlt" extension:
> 
>   When rendering a Resource with resourceType=/some/stuff
> 
>   For a GET request with  with URL extension=html
> 
>   The SlingScriptResolver looks for a script named
> /sling/scripts/some/stuff/get.html.vlt
> 
> The updated microsling-homepage.html attached to
> https://issues.apache.org/jira/browse/SLING-47 contains links to
> source code for a quick code walkthrough.
> 
> Do you guys think we need to add more stuff to microsling to reflect
> the core ideas of the Sling request processing? ResponseFilters maybe?
> 
> -Bertrand.

Re: [microsling] SlingServlet interface, HTTP methods (was: microsling script resolution rewritten)

[Felix Meschberger]

Am Montag, den 15.10.2007, 14:00 +0200 schrieb Bertrand Delacretaz:
> What I like about the doGet, doPost, doPut, etc.. methods in the
> current microsling SlingServlet interface is that they help people
> think in terms of HTTP methods.

Sounds reasonable indeed.

> We could for example define that adding a "slingMethod=PUT" parameter
> to the request causes SlingServlet.doPut to be called instead of
> doPost.

Sling (and microsling) could provide the requested method with a Request
wrapper overwriting the getMethod method returning the parameter
overwrite instead of the actuall method.

> To handle additional HTTP methods, we can always keep the service()
> method, maybe renamed to doOtherHttpMethod(), and call it for HTTP
> methods which are not covered by the SlingServlet's doX() methods.

How about doGeneric() ?

And then how about mimiking the way Servlet API HttpServlet does this
(except that we would call doGeneric (or whatever) for any non-standard
methods. The idea mainly is to provide default implementations for the
HEAD, TRACE and OPTIONS method.

Yet, the SlingServlet is something else than a script handler. If we
resolve the resource type to some .xxx script, it would probably
not be worth it to again check the method to call the appropriate doXXX
method because the script itself will know how to handle the correct
method and not the ScriptHandler evaluating the script. There is IMHO no
reason to prevent a JavaScript script from hanlding POST methods.

With respect to the "slingMethod" parameter overwriting the actual
request Method: This may probably be implemented by a Request wrapper
overwriting the getMethod method returning the parameter overwrite
instead of the actuall method.

We probably may need both: The SlingServlet (probably not in microsling)
and an interface for script handlers.

Regards
Felix

Re: [microsling] script resolution and extension (was: microsling script resolution rewritten)

[Felix Meschberger]

Am Montag, den 15.10.2007, 14:03 +0200 schrieb Bertrand Delacretaz:
> On 10/14/07, Felix Meschberger <[EMAIL PROTECTED]> wrote:
> 
> > ...(2) I am not sure whether resolving the script with the request
> > extension is useful. Rather I would use the "selectors" of the request
> > URL (the dot-separated parts between the node path and the extension) as
> > further script selectors
> 
> I thought a bit about this, and I suggest instead adding an additional
> requestFilter that computes the desired Content-Type for the response,
> and stores it in the SlingRequestContext.
> 
> The default implementation could just use the extension or selectors
> to do this, but at the SlingServlet level you get a clean
> "Content-Type=text/html" which tells you what to generate, irrelevant
> of the way this was derived from the request.

Good idea, this mechanism could probably be used to set the default
content type of the response but in any case the request's Accept must
be obeyed. So if for example the Accept header wants to see text/plain,
Sling should not set the content type default to image/gif just because
the extension happens to be gif.

Regards
Felix

Re: [microsling] Resource interface (was: microsling script resolution rewritten)

[Felix Meschberger]

Am Montag, den 15.10.2007, 14:14 +0200 schrieb Bertrand Delacretaz:
> On 10/14/07, Felix Meschberger <[EMAIL PROTECTED]> wrote:
> 
> > ...Regarding the resource: I think, we should provide the JCR item to which
> > the request URL resolved with a proper method, such as "Item getItem();"
> > and leave the "Object getDate();" method to the object mapping. ..
> 
> Fine with me, although this makes the Resource more JCR-specific. But
> I think we're fine with that.

The problem is, that we might want both, the JCR item and the mapped
object. If the getData method would return either of both, how would we
access the other ?

> > ...In
> > addition, I would provide the selectors, extension and suffix in the
> > Resource, too, as proposed on the Wiki page...
> 
> I don't like this - I'd much prefer a ParsedRequestPath object, stored
> in the SlingRequestContext, that's initialized when the Resource is
> resolved.
> 
> I don't think extension, selectors and the like belong in the
> Resource. They describe how the request path was parsed to find the
> Resource, but they are definitely not part of the resource itself.
> 
> And I feel it important to keep the Resource interface as small as
> possible, as it's a central part of microsling - keeping it small
> helps people focus on what's important.

Agreed. I just put them in the resource because the somewhat fit neatly.
But they might as well be put in the request context.

> What do you think? Could we put this info somewhere else?
> 
> > ...Providing the JCR Item and mapped object in the Resource interface
> > itself would of course stipulate, that microsling (and hence Sling, see
> > my other posting in this thread) would be based on the repository and/or
> > mapping and there would be no other source such as the filesystem etc
> 
> Using other data sources would still be possible, in which case
> Resource.getItem() returns null and Resource.getData() returns the
> File or whatever object. But I think we all agree that that's not our
> focus.

Exactly.

Regards
Felix

Re: microsling script resolution rewritten (was: Microsling, first shot...)

[Felix Meschberger]

Am Montag, den 15.10.2007, 14:26 +0200 schrieb Bertrand Delacretaz:
> On 10/14/07, Felix Meschberger <[EMAIL PROTECTED]> wrote:
> 
> > ...As such microsling would have a MicroSlingServlet which has pretty much
> > everything wired and no OSGi, that is no real lifecycle management and
> > extensibility...
> 
> Just a small thing to add here: microsling is extensible indeed, at
> least in a static way, by inheriting from MicroSlingServlet and
> redefining its methods as needed, to use other RequestFilters or
> SlingServlets, or prioritize them differently.

Sure.

> Note also, that if people create microsling extensions as separate
> Maven modules, they should be easy to use in Sling OSGi as well, by
> setting up the Maven POMs for OSGi bundle generation (which is a piece
> of cake with the maven-bundle-plugin and maven-scr-plugin from the
> Felix project).

This is why I want to align Sling and microsling. So that people could
start playing around with microsling and migrate to Sling without major
hassles.

Regards
Felix

[POLL] microsling: Future of microsling

[Felix Meschberger]

Hi all,

After the introduction [1] of microsling as a simple testbed for the
discussions around a new Sling API [2] and some discussions on the list,
I want to poll the communities opionion on the following question:

What do you think of (1) making microsling the "reference
implementation" of the new Sling API and thus (2) promoting it
to the trunk and finally (3) try to reuse parts of microsling
code for the real Sling ?

Of course the discussion on the exact Sling API has not been finalized
yet, and microsling needs some polishing here and there. This is just
about the general question.

Thanks for any replies.

Regards
Felix

microsling: To Servlet or to SlingServlet

[Felix Meschberger]

Hi all,

Currently the SlingServlet is a very simple interface defining doXXX
methods for some HTTP request methods and a canProcess method to ask
whether the SlingServlet is willing to process the request. I think,
this interface is not required as is. I discussed this quickly with
Bertrand yesterday, and we came up with the idea of a SlingGetServlet
and a SlingServlet.

The SlingGetServlet would also provide API for the GET and HEAD methods,
the SlingServlet would add support for the rest of the core HTTP methods
like OPTIONS, TRACE, POST, PUT and DELETE. And finally, an extension of
SlingServlet could add support for more methods, for example a
SlingDAVServlet might add support for WebDAV methods like MKCOL, etc.

While we agree that it is a good idea - also from a educational point of
view - to have such servlets with precanned doXXX methods, we do not
actually agree, where the selection of the doXXX method should be
located.

Bertrand thinks along the ways of the current microsling SlingServlet,
which just has the doXXX methods and some core class in Sling select the
doXXX method based on the request method (and optional method
overwrite).

I think along the lines of the javax.servlet HttpServlet class, which
implements this dispatching in the service method with an important
difference, of course: We would not simply throw on a method not
directly known but dispatch to a doGeneric method, which by default
throws of course.

What is your opinion on this: A separate SlingServlet interface/class
hieararchy or going along the lines of the HttpServlet (yet doing it
better with respect to non-core HTTP methods) ?

Regards
Felix

Re: [microsling] SlingServlet interface, HTTP methods (was: microsling script resolution rewritten)

[Felix Meschberger]

I agree, that we might want to wait for a real-life request.

On the other hand it is not only the end-users fault if not the correct
methods could be used, though browsers are probably the major number of
culprits. Many times it is just a question of firewall limitation which
can by no means be circumvented by the casual user on the internet ...

Regards
Felix

Am Dienstag, den 16.10.2007, 10:47 -0700 schrieb Roy T. Fielding:
> On Oct 16, 2007, at 1:18 AM, Bertrand Delacretaz wrote:
> 
> > On 10/15/07, Bertrand Delacretaz <[EMAIL PROTECTED]> wrote:
> >
> >> ...We could for example define that adding a "slingMethod=PUT"  
> >> parameter
> >> to the request causes SlingServlet.doPut to be called instead of
> >> doPost
> >
> > To clarify, note that I meant this for the POST method only, this
> > should *not* be done with GET or HEAD. And we're still discussing if
> > this should be done at all, see the "Actions (methods) must not appear
> > in URIs" thread started by Roy.
> 
> Unless you have an immediate customer need for it, we should not.
> That is the kind of thing I would only do in combination with
> a very specific user agent string, such that they would see their
> bug when they tested newer versions of the user agent (at least
> until they remove the restrictions from the browser setting of
> header fields).
> 
> Roy
> 

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

[Felix Meschberger]

I completely agree with respect to not using a Filter for
ResourceResolution. Lets make the ResourceResolver a service called by
the SlingRequestContext on demand (btw, the SlingRequestContext must
then probably have a reference to the request, right ?).

Regards
Felix

Am Mittwoch, den 17.10.2007, 09:11 +0200 schrieb Bertrand Delacretaz:
> On 10/17/07, Carsten Ziegeler <[EMAIL PROTECTED]> wrote:
> > Could we please discuss things in the mailing list and not in Jira...
> 
> Sure, let me restate what I said in JIRA-60 here:
> 
> I agree with what Felix says in JIRA-60, about the RequestPathInfo
> (selectors, extension, suffix, etc) being dependent on the way the
> Resource is resolved. So the current microsling
> SlingRequestPathInfoParser is wrong in its current state.
> 
> But I'm not sure if resolving the Resource in a Filter is the best
> idea: how about making the ResourceResolver a first-class Sling API
> citizen instead, and calling that from the SlingRequestContext
> on-demand, when the Resource of the RequestPathInfo is accessed?
> 
> This might make it easier to make the ResourceResolver a plugin (in
> Sling OSGi mostly), and might also make the code clearer to follow?
> 
> I think Filters are good for either manipulating the Request before
> processing it, or enhancing the Request attributes with "small" things
> that are not always needed, like the detected Locale for example.
> 
> But something as fundamental as finding the Resource to act on (and
> computing the RequestPathInfo) should not be "hidden" in a Filter,
> IMHO.
> 
> -Bertrand

To Filter or not to Filter

[Felix Meschberger]

Hi all,

Currently, we love using filtering in both Sling and microsling: Every
part of request processing is implemented using a filter. This was not
always the case: In the days when Sling was still private, there was no
filtering at all.

Probably we must come to a mix of both: There are some tasks, which have
to be executed all the times and there are some tasks which may or may
not be executed. Examples of the former are authentication, proper error
handling, resource resolution and servlet/script resolution. Examples of
the latter are locale resolution, default setting of the response
content type etc.

So, for microsling, I propose to not implement resource resolution as a
filter, in fact leaving default response content type setting the only
filtering task (currently).

For Sling I propose to not implement filtering for authentication
(replace AuthenticationFilter by a service called directly),
errorhandler (replace ErrorHandlerFilter), contentresolution (replace
ContentResolverFilter) and component resolution (replace
ComponentResolver). These tasks are always executed in the listed order
by the Sling request processor. After the component is resolved the
registered filters are called and finally the component itself is
called.

WDYT ?

Regards
Felix

Re: To Filter or not to Filter

[Felix Meschberger]

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.

Regards
Felix

Re: To Filter or not to Filter

[Felix Meschberger]

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]
> >
> 
> 

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

[Felix Meschberger]

I have another use case which comes from a real-world CMS :-)

Consider you have a pages containing paragraphs of text. There may be
crossreferences of even shared paragraphs. It would be nice, if instead
of copying the shared paragraph we could just refer to it.

Another use case probably is content inheritance on another level:
Consider a system for where we have support for multiple languages. We
would have a tree for the default language and additional trees per
language. Instead of just copying the complete default language tree for
each additional language, we could just create page nodes in the
languages and add references to the contents of the default language
tree.

Both use cases will of course define and properly handle the case of
updating the content: The reference paragraph case might just edit to
target paragraph while the multi language case might create a (partial)
copy on write.

Regards
Felix

Am Mittwoch, den 17.10.2007, 16:21 +0200 schrieb Carsten Ziegeler:
> Okay, the main idea is to have some kind of references which allows to
> create virtual trees in a transparent way. I thought that this could be
> useful. :)
> 
> Let's consider an example with a page node which has a header, footer
> and content node. Rendering of the page node is always the same (header,
> content, footer). Now, with these references it's possible to reference
> parts of the page from a template or master page. And the page rendering
> does not need to know these things.
> 
> So, that's the basic idea - now, there might be better/other ways to
> handle such things, but they are not transparent.
> 
> Carsten
> 
> 
> Felix Meschberger (JIRA) wrote:
> >  [ 
> > https://issues.apache.org/jira/browse/SLING-61?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
> >  ]
> > 
> > Felix Meschberger reopened SLING-61:
> > 
> > 
> > 
> > Reopen the issue for further consideration.
> > 
> > Carsten, could you please comment ? Thanks.
> > 
> >> 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.
> > 
> 
> 

Re: svn commit: r585881 - /incubator/sling/whiteboard/microsling/pom.xml

[Felix Meschberger]

Wouldn't it be easier to just configure the JAR plugin to the project
instead of the antrun and attach-artifacts plugin ? IIRC the jar plugin
creates an attachment if it is not run as the main packager of the
project or you may be able to configure the plugin correctly.

Regards
Felix

Am Donnerstag, den 18.10.2007, 06:13 + schrieb
[EMAIL PROTECTED]:
> Author: bdelacretaz
> Date: Wed Oct 17 23:13:56 2007
> New Revision: 585881
> 
> URL: http://svn.apache.org/viewvc?rev=585881&view=rev
> Log:
> SLING-66 : Create a microsling jar artifact in addition to the war file
> 
> Modified:
> incubator/sling/whiteboard/microsling/pom.xml
> 
> Modified: incubator/sling/whiteboard/microsling/pom.xml
> URL: 
> http://svn.apache.org/viewvc/incubator/sling/whiteboard/microsling/pom.xml?rev=585881&r1=585880&r2=585881&view=diff
> ==
> --- incubator/sling/whiteboard/microsling/pom.xml (original)
> +++ incubator/sling/whiteboard/microsling/pom.xml Wed Oct 17 23:13:56 2007
> @@ -90,6 +90,46 @@
>  
>
>
> +
> +maven-antrun-plugin
> +
> +  
> +package
> +
> +  
> + +  
> destfile="${project.build.directory}/${project.name}-${project.version}.jar"/>
> +  
> +
> +
> +  run
> +
> +  
> +
> +  
> +  
> +
> +org.codehaus.mojo
> +build-helper-maven-plugin
> +
> +  
> +attach-artifacts
> +package
> +
> +  attach-artifact
> +
> +
> +
> +  
> +
> ${project.build.directory}/${project.name}-${project.version}.jar
> +jar
> +  
> +
> +
> +  
> +
> +  
> +  
>  org.mortbay.jetty
>  maven-jetty-plugin
>  6.1.5
> 
> 

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

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

[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

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: 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: [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

Re: Caching and spooling (Was: microsling user feedback)

[Felix Meschberger]

Hi,

Am Freitag, den 19.10.2007, 12:54 +0300 schrieb Jukka Zitting:
> I'd rather use "streaming" for the process of passing the data
> directly to the client without spooling (!) it first somewhere on disk
> or in memory.

I completely agree with you and we should probably use the correct
english term instead of the german-english incorrect term. Hence, let's
do a StreamServlet :-) which BTW could also do such things as checking
the last modification time and setting the content length and content
type (in case of nt:resource).

Regards
Felix

Re: We need an equivalent of sling:include in microsling

[Felix Meschberger]

I would not create another interface for this. A simple bean class
should probably suffice it, I think ...

Regards
Felix

Am Freitag, den 19.10.2007, 11:32 +0200 schrieb Bertrand Delacretaz:
> On 10/19/07, Felix Meschberger <[EMAIL PROTECTED]> wrote:
> > So we would probably have:
> >
> > public class Sling {
> ...
> >   public void include(String path) throws ServletException, IOException
> ...
> 
> Yes, something like that.
> 
> I wouldn't call the class "Sling" though, as it's not sling, it's only
> a poor lonesome helper class. But I'd call the variable that holds
> this in scripts "sling".
> 
> > Would this be for scripting-only ?
> 
> It doesn't have to, but as you mentioned it makes less sense in java
> code, where people are expected to know their J2EE stuff.
> 
> That's why I called the interface SlingScriptHelpers in my initial
> suggestion: it's usually meant for scripting, but of course people can
> use it in java code if they want.
> 
> -Bertrand

Re: microsling: Exceptions

[Felix Meschberger]

Am Freitag, den 19.10.2007, 14:53 +0200 schrieb Bertrand Delacretaz:
> > ...I would suggest, that all
> > methods allowed to throw checked exceptions should throw SlingException
> 
> The downside is having to rethrow exceptions which the implementation
> gets and which are not SlingExceptions.
> 
> What's the upside, in your opinion?
> 
> (I'm not being ironic, it's really a question that no one answered in
> a satisfactory way for my pragmatic brain until now)

I am ok with the question - I asked it to myself, too. But then, here is
why I propose this:

We define an API for the Sling realm which has its own exception
hierarchy rooted at SlingException (extends ServletException). We define
an API for Sling (or microsling for that matter) applications, so the
most natural thing counting these two together is to require
SlingExceptions to be thrown.

So applications may catch Exceptions within the core domain model of the
API. So I think, that trying to unwind exceptions would involve
knowledge of the implementation (e.g. interpreting RepositoryException
(or worse SqlException) ) upfront, would link the application into the
implementation too much.

So rather, I would suggest to define more specific exceptions if
required (e.g. if we think Resource resolution failure should be better
visible, define a ResourceResolutionException extends SlingException).

Another point is, that whenever a method is declared throws Exception I
am force to catch(Exception), which is something a definitely do not
like because I might want to let RuntimeException pass through.
Otherwise I would also be required to declare throws Exception and may
not even be able to describe what exact exception I am expected to
throw ...

Moreover, requiring specific API domain exceptions also requires the
implementor (not the user) to think about the possible problems that may
occurr.

There may be more reasons, which do not come to my mind currently. But I
know (unfortunately I  do not have the book handy right now) that Josh
Bloch wrote about this issue in his seminal work Effective Java [1].

Regards
Felix

[1]
http://www.amazon.com/Effective-Java-Programming-Language-Guide/dp/0321356683

Re: microsling user feedback

[Felix Meschberger]

Am Freitag, den 19.10.2007, 17:51 +0200 schrieb Tobias Bocanegra:
> > > Even for resources that are readable for for anonymous users I get the 
> > > basic
> > > authentication popup of the browser. Surely, this can be suppressed (maybe
> > > by wrapping the WebDAV servlet?). But this also made me wonder how the
> > > single-sign-on would work between a (raw, unwrapped) WebDAV-based part 
> > > (that
> > > uses basic authent) and microsling (that uses the jsessionid cookie/Java
> > > appserver mechanisms)? microsling could of course accept the basic
> > > authentication headers if a WebDAV login occurred first, but how would it
> > > work the other way round?
> first, why does microsling do a jesseionid based auth? i don't see the
> need to this at all (at least for the default auth handler). the way
> basic auth should work is:

microsling does no auth at all at the moment !

This must be something that Michael did with his support for WebDAV
redirection stuff. He would have to show the scripts for us to further
help.

Regards
Felix

> 
> - grab the credentials from the request and construct
> SimpleCredentiials. if there are no credentials, use NULL
> - login to the repository
> - if login fails, send a 401
> 
> i don't know why the webdav servlet sends a 401...actually it should
> allow anonymous access.
> regards, toby
> 
> 
> 
> > >
> > > Cheers
> > > Michael
> > >
> > >
> > > On 10/19/07, Felix Meschberger <[EMAIL PROTECTED]> wrote:
> > > >
> > > > Hi,
> > > >
> > > > Am Freitag, den 19.10.2007, 15:09 +0200 schrieb David Nuescheler:
> > > > > Therefore I think that a GET to the exact repository path should
> > > > > generally be handled the same way as the WebDAV GET.
> > > > > I think this is very easy to understand for everybody and
> > > > > means that microsling generally works just like every
> > > > > other WebDAV enabled webserver for everything that is
> > > > > static.
> > > >
> > > > This sounds very plausible, but has some implications, which turn out to
> > > > be somewhat problematic. Therefore, I just added a StreamServlet which
> > > > streams a resource of type nt:file (which is most likely what is
> > > > required by Michael) and in addition support If-Modified-Since header
> > > > such that a 304 may be sent back just in case.
> > > >
> > > > This more or less should match, what WebDAV does in this respect, and I
> > > > think we are done without any special handling.
> > > >
> > > > > Personally, I think that this is a very simple and
> > > > > straightforward solution that leverages a lot of features
> > > > > implemented in WebDAV entirely correctly.
> > > > > Think of etag or modified since behaviour on GET
> > > > > or PUT and DELETE which all would have to be
> > > > > re-implemented in microsling.
> > > >
> > > > Streaming out of a Sling Application currently only discusses reading
> > > > (GET) not updating, which is done as described by Betrand using access
> > > > to the WebDAV servlet included with microsling.
> > > >
> > > > > Generally I think WebDAV is very Restful and a very
> > > > > good basis to start and sort of decorate microsling
> > > > > on top of a webdav enabled server.
> > > >
> > > > This sounds like an interesting point, though: Running Sling/microsling
> > > > ontop of a WebDAV server instead of a repository  :-)
> > > >
> > > > > I think assuming assuming that people add an extension
> > > > > to let's say /content/mypage when GETting /content/mypage.html
> > > > > though microsling is good practice anyway.
> > > >
> > > > Definitely, it also helps determine the default response content type.
> > > >
> > > > Regards
> > > > Felix
> > > >
> > > >
> >
> >
> 
> 

Re: microsling user feedback

[Felix Meschberger]

Another case for my point, that we should keep the WebDAV servlet and
the microsling servlet separate :-)

Regards
Felix

Am Freitag, den 19.10.2007, 17:13 +0200 schrieb Michael Marth:
> Hi,
> 
> I gave it a shot to put the static resources in the repository and access
> them through WebDAV. It worked, but there is one issue that I would like to
> mention in this discussion about the correct implementation:
> 
> Even for resources that are readable for for anonymous users I get the basic
> authentication popup of the browser. Surely, this can be suppressed (maybe
> by wrapping the WebDAV servlet?). But this also made me wonder how the
> single-sign-on would work between a (raw, unwrapped) WebDAV-based part (that
> uses basic authent) and microsling (that uses the jsessionid cookie/Java
> appserver mechanisms)? microsling could of course accept the basic
> authentication headers if a WebDAV login occurred first, but how would it
> work the other way round?
> 
> Cheers
> Michael
> 
> 
> On 10/19/07, Felix Meschberger <[EMAIL PROTECTED]> wrote:
> >
> > Hi,
> >
> > Am Freitag, den 19.10.2007, 15:09 +0200 schrieb David Nuescheler:
> > > Therefore I think that a GET to the exact repository path should
> > > generally be handled the same way as the WebDAV GET.
> > > I think this is very easy to understand for everybody and
> > > means that microsling generally works just like every
> > > other WebDAV enabled webserver for everything that is
> > > static.
> >
> > This sounds very plausible, but has some implications, which turn out to
> > be somewhat problematic. Therefore, I just added a StreamServlet which
> > streams a resource of type nt:file (which is most likely what is
> > required by Michael) and in addition support If-Modified-Since header
> > such that a 304 may be sent back just in case.
> >
> > This more or less should match, what WebDAV does in this respect, and I
> > think we are done without any special handling.
> >
> > > Personally, I think that this is a very simple and
> > > straightforward solution that leverages a lot of features
> > > implemented in WebDAV entirely correctly.
> > > Think of etag or modified since behaviour on GET
> > > or PUT and DELETE which all would have to be
> > > re-implemented in microsling.
> >
> > Streaming out of a Sling Application currently only discusses reading
> > (GET) not updating, which is done as described by Betrand using access
> > to the WebDAV servlet included with microsling.
> >
> > > Generally I think WebDAV is very Restful and a very
> > > good basis to start and sort of decorate microsling
> > > on top of a webdav enabled server.
> >
> > This sounds like an interesting point, though: Running Sling/microsling
> > ontop of a WebDAV server instead of a repository  :-)
> >
> > > I think assuming assuming that people add an extension
> > > to let's say /content/mypage when GETting /content/mypage.html
> > > though microsling is good practice anyway.
> >
> > Definitely, it also helps determine the default response content type.
> >
> > Regards
> > Felix
> >
> >

Re: microsling static files + WebDAV (was: microsling user feedback)

[Felix Meschberger]

Am Freitag, den 19.10.2007, 15:36 +0200 schrieb Tobias Bocanegra:
> > > I do not think, that this is a good idea. It involves magic and leaves
> > > the microsling context in a way we cannot and most probably will not
> > > support in Sling and thus creates an incompatibility.
> > >
> > > Rather I would suggest to implement a SpoolServlet (extends
> > > SlingSafeMethodsServlet) which handles nt:file requests
> > > (MicroSlingServlet.addServlet("nt:file", new SpoolServlet()) and just
> > > pumps out the nt:file (or the Property value to which the
> > > Node.getPrimaryItem() trail leads).
> >
> > i agree with felix that having a spool servlet is a better option.
> > nevertheless, i would provide a webdav servlet with the default setup.
> > so that users can easily upload/manager their static content in the
> > repository.
> 
> i rethought about this. the current webdav servlet in jackrabbit is
> pretty cool and feature complete. especially for GET requests it
> suports etags, if-last-modified-since, etc. and it would silly to
> reimplement this again.

I completely agree with you and will not dispute this :-)

> furthermore, i think for the other methods (PUT, DELETE, MKCOL) etc
> the webdav servlet provides the good defaults.

Same here ...

>  so i suggest to drop
> the StreamServlet idea, and map all exact-match resources per default
> to the webdav servlet.

But not here. The WebDAV servlet is great and provides a number of
useful features for what it is called DAV, namely Authoring.

But, let us now take the other route: How would you implement this in
microsling ?

I have in mind a solution, where the MicroSlingServlet will try to
resolve the resource and check for any selectors, extension and suffix.
If none of these exist, the MicroSlingServlet would delegate to the
WebDAV servlet, right ?

How would this be done ? By RequestDispatcher.include or by a 301/302 ?
However it is done, the MicroSlingServlet must have knowledge of the
WebDAV servlet !

So we have to big issues here: (1) we create a special case (no
extension, selectors, suffix) and (2) we create a dependency to another
servlet in microsling.

Both may be disputed over. But IMHO this construct violates one thing:
Simplicity. Probably it even violates the "separation of concerns"
principle.

Therefore, we should keep the StreamServlet (it is simple and lean and
shows another concept of microsling, namely Servlet selection by
resource type) and just go with it for what it is intended to do.

Regards
Felix

Re: microsling static files + WebDAV

[Felix Meschberger]

Am Freitag, den 19.10.2007, 15:52 +0200 schrieb Carsten Ziegeler:
> Perhaps I'm thinking too complicated here, but does this always work?
> What about if I have
> /content/test
> /content/test.html
> in my repository and try to get /content/test.html ?
> 
> This will be forwarded to the webdav servlet and I don't have any chance
> to get the html view of /content/test.

This is a fundamental problem of resource resolution in Sling and
microsling and has nothing to do with whether we use WebDAV or not

But of course you can access the html view of /content/test
through /content/test.htm ... And yes, I do not like this either, but I
think such collisions cannot be prevented from happening unless we
require that after resolving the content we must have an extension in
the request info. But this is IMHO not a good idea...

Regards
Felix

Re: microsling user feedback

[Felix Meschberger]

Hi,

Am Freitag, den 19.10.2007, 15:09 +0200 schrieb David Nuescheler:
> Therefore I think that a GET to the exact repository path should
> generally be handled the same way as the WebDAV GET.
> I think this is very easy to understand for everybody and
> means that microsling generally works just like every
> other WebDAV enabled webserver for everything that is
> static.

This sounds very plausible, but has some implications, which turn out to
be somewhat problematic. Therefore, I just added a StreamServlet which
streams a resource of type nt:file (which is most likely what is
required by Michael) and in addition support If-Modified-Since header
such that a 304 may be sent back just in case.

This more or less should match, what WebDAV does in this respect, and I
think we are done without any special handling.

> Personally, I think that this is a very simple and
> straightforward solution that leverages a lot of features
> implemented in WebDAV entirely correctly.
> Think of etag or modified since behaviour on GET
> or PUT and DELETE which all would have to be
> re-implemented in microsling.

Streaming out of a Sling Application currently only discusses reading
(GET) not updating, which is done as described by Betrand using access
to the WebDAV servlet included with microsling.

> Generally I think WebDAV is very Restful and a very
> good basis to start and sort of decorate microsling
> on top of a webdav enabled server.

This sounds like an interesting point, though: Running Sling/microsling
ontop of a WebDAV server instead of a repository  :-)

> I think assuming assuming that people add an extension
> to let's say /content/mypage when GETting /content/mypage.html
> though microsling is good practice anyway.

Definitely, it also helps determine the default response content type.

Regards
Felix

microsling: Commit Wave ahead ...

[Felix Meschberger]

Hi all,

I am currently committing some stuff to microsling. Until all is
committed, microsling may fail to build. Will inform you when I am done.

Regards
Felix

PS: I know this is not best known behaviour :-)

Re: We need an equivalent of sling:include in microsling

[Felix Meschberger]

Ok, I will add such a thing while resolving the script stuff.

Regards
Felix

Am Freitag, den 19.10.2007, 14:55 +0200 schrieb Bertrand Delacretaz:
> On 10/19/07, Felix Meschberger <[EMAIL PROTECTED]> wrote:
> > ...I would not create another interface for this. A simple bean class
> > should probably suffice it, I think ...
> 
> The same idea occured to me while riding my bike to lunch. Riding
> bikes is a Good Thing ;-)
> 
> So I agree on using a simple wrapper class, without adding another
> interface to the API.
> 
> -Bertrand

microsling: Exceptions

[Felix Meschberger]

Hi all,

Many methods in microsling are defined to throw Exception. I think this
is bad practice and should not be done. Rather I would suggest, that all
methods allowed to throw checked exceptions should throw SlingException.

Regards
Felix

Re: microsling user feedback

[Felix Meschberger]

Hi,

At first sight, this looks intriguing indeed. But on second sight, it
mixes concepts introduces dependencies and just does not seem right.

In addition to my other post, where I postulate a SpoolServlet, I would
say, that we should not mix microsling/Sling generation and WebDAV
generation as it will never correctly workout, unfortunately.

Rather I would say microsling/Sling generates all output itself. To
support WebDAV through microsling/Sling we should create a different
WebApp which is only responsible for supporting WebDAV.

Regards
Felix

Am Freitag, den 19.10.2007, 09:48 +0200 schrieb David Nuescheler:
> Hi guys,
> 
> > > ...- 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
> > Would an "initial content loader" mechanism be useful? I have some
> > code from another project that copies all resources found under
> > WEB-INF/initial-content into the repository at startup, is that
> > something that would help you in your application setup?
> I think I am missing something...
> 
> Shouldn't you be able to to just put any static file into the repository via
> webdav, and then just use the webdav url to retrieve it again?
> 
> That being said, i think it would be great if microsling ootb handles
> "static resources" properly. I think if someone addresses
> an item with an "exact match" in a url (no additional extensions or selector)
> I think that resource should be taken care of the same way as we do that in 
> the
> WebDAV layer today...
> 
> 
> As an example let's say my repo looks like this.
> 
> /content [nt:unstructured]
> /content/myblog [my:blog]
> /content/docroot [nt:folder]
> /content/docroot/privacy.html [nt:file]
> 
> I think the resolution of GET requests to the following urls should
> work as follows:
> 
> http://myhost/content/myblog.html -> /content/myblog execs the "html.esp"
> http://myhost/content/docroot/privacy.html -> delegates to webdav
> since it was an "exact match"
> http://myhost.content/docroot -> delegates to webdav since it was an
> "exact match"
> http://myhost.content/docroot.html -> /content/docroot execs the "html.esp"
> 
> This should also allow to bind webdav directly to microsling, which i
> find more intuitive.
> 
> Does that make sense?
> 
> regards,
> david

Re: microsling static files + WebDAV (was: microsling user feedback)

[Felix Meschberger]

Hi,

I do not think, that this is a good idea. It involves magic and leaves
the microsling context in a way we cannot and most probably will not
support in Sling and thus creates an incompatibility.

Rather I would suggest to implement a SpoolServlet (extends
SlingSafeMethodsServlet) which handles nt:file requests
(MicroSlingServlet.addServlet("nt:file", new SpoolServlet()) and just
pumps out the nt:file (or the Property value to which the
Node.getPrimaryItem() trail leads).

Regards
Felix

Am Freitag, den 19.10.2007, 10:11 +0200 schrieb Bertrand Delacretaz:
> On 10/19/07, David Nuescheler <[EMAIL PROTECTED]> wrote:
> > > ...Would an "initial content loader" mechanism be useful?...
> 
> > Shouldn't you be able to to just put any static file into the repository via
> > webdav, and then just use the webdav url to retrieve it again?..
> 
> You're right, so the actual problem is that microsling currently
> cannot serve static files.
> 
> > ... think if someone addresses
> > an item with an "exact match" in a url (no additional extensions or 
> > selector)
> > I think that resource should be taken care of the same way as we do that in 
> > the
> > WebDAV layer today...
> 
> Sounds good to me, so the rules might be:
> 
> 1) A WebDAV servlet is configured in the microsling webapp, but not
> mapped to an URL
> 
> 2) The microsling webapp is mapped to /*
> 
> 3) When a Node exists at a path that exactly matches the current
> request path, microsling forwards the request to the WebDAV servlet.
> 
> Is that what you mean?
> 
> Do others see a problem with that?
> 
> -Bertrand

Re: microsling static files + WebDAV

[Felix Meschberger]

Yes, I always liked the sites where the user is thrown an MSSql
Exception in his face ... :-)

Regards
Felix

Am Freitag, den 19.10.2007, 15:58 +0200 schrieb Tobias Bocanegra:
> > Perhaps I'm thinking too complicated here, but does this always work?
> > What about if I have
> > /content/test
> > /content/test.html
> > in my repository and try to get /content/test.html ?
> >
> > This will be forwarded to the webdav servlet and I don't have any chance
> > to get the html view of /content/test.
> 
> right. that's why you won't have a test.html :-)
> regards, toby
> 
> ps: this also forces people of building sites that have links with
> proper extensions (since /conten/test would point to a webdav
> collection and not 'render' the content) which is a good side effect,
> i think.
> 

Re: microsling: Exceptions

[Felix Meschberger]

Examples of this you may see in the microsling DefaultSlingServlet and
StreamServlet.

The DefaultSlingServlet has to catch and threat the ServletException and
IOException separately just to be able to handle the Exception declared
by SlingRequestContext.

Regards
Felix


Am Freitag, den 19.10.2007, 15:37 +0200 schrieb Carsten Ziegeler:
> Felix Meschberger wrote:
> > 
> > Another point is, that whenever a method is declared throws Exception I
> > am force to catch(Exception), which is something a definitely do not
> > like because I might want to let RuntimeException pass through.
> > Otherwise I would also be required to declare throws Exception and may
> > not even be able to describe what exact exception I am expected to
> > throw ...
> > 
> While I usually tend to just throw Exception (as Bertrand does), this
> usually creates nasty code for clients of the api. Imagine you implement
> an interface from another api which has a method that declares to throw
> exception A and B. Now in the implementation of the method you call the
> ms api (ms = microsling :) ) which throws exception. So you have to test
> if the ms api call throws exception A or B and pass this through or if
> it is any other exception, you have to wrap it.
> If the ms api just throws sling exception you catch it, wrap it and
> that's it.
> 
> Carsten
> 

Re: microsling static files + WebDAV (was: microsling user feedback)

[Felix Meschberger]

Am Freitag, den 19.10.2007, 11:43 +0200 schrieb Tobias Bocanegra:
> nevertheless, i would provide a webdav servlet with the default setup.
> so that users can easily upload/manager their static content in the
> repository.

IIRC the microsling setup includes the Jackrabbit WebDAV servlet just
for this 

Regards
Felix

Re: We need an equivalent of sling:include in microsling

[Felix Meschberger]

Hi,

Am Freitag, den 19.10.2007, 10:34 +0200 schrieb Tobias Bocanegra:
> for example:
> document.write(...)   would write to the response writer

JSP defines the writer using the variable out, so we should use that
name. The EspReader will create the out value on demand while for Plain
Javascript files the writer must be explicitly retrieved from the
response.

For Velocity Templates the response writer is used to evaluate the
template in the first place.

> but of course, a convenience class should encapsulate this in order to
> make microsling easy to use. either:
> sling.include(...)
> document.include(...)
> response.include(...)

Would not do that. People know the Servlet API and we should not invent
additional helper stuff, which is just hard to maintain. Rather we will
provide taglibs for JSP (in Sling not microsling, though).

Regards
Felix

Re: microsling user feedback

[Felix Meschberger]

Am Freitag, den 19.10.2007, 11:42 +0200 schrieb Bertrand Delacretaz:
> On 10/19/07, Felix Meschberger <[EMAIL PROTECTED]> wrote:
> 
> > ...I would
> > say, that we should not mix microsling/Sling generation and WebDAV
> > generation as it will never correctly workout, unfortunately
> 
> Why wouldn't that work?

Because a WebDAV GET is not the same as a microsling/Sling GET in the
general case.

> I agree that mixing WebDAV and other protocols in the same URL space
> might not work depending on what the other protocols are, but what
> could go wrong in the simple microsling case?

Just having to explain: A request is passed through Sling Servlet
resolutions unless the RequestURL exactly matches the JCR resource in
which case the request is handled as if it were a WebDAV request ...
This calls for nasty problems and hard to explain special cases.

> 
> I'm curious mostly, I cannot argue 100% that it would work, so if you
> have contrary evidence it'd help me figure out the issues.
> 
> Having a full WebDAV implementation (the Jackrabbit one I assume)
> *plus* our cool resource resolving and scripting stuff in the same URI
> space sounds like a big benefit for microsling...there might be
> downsides, but I'd prefer us to analyze them before dismissing the
> idea.

With the exception that it does not work. We (Day) tried this in other
products (Communiqué for concrete) and always came to the conclusion,
that we have to clearly separate WebDAV from the rest. So in Communiqué
we solved the issue of just prefixing WebDAV requests such that
http://host/dav/xxx/yyy would be a WebDAV request to resource /xxx/yyy
while http://host/xxx/yyy would be the "normal" request to
resource /xxx/yyy.

And as always: Keeping things simple means: Don't create special
cases ...

Regards
Felix

Re: We need an equivalent of sling:include in microsling

[Felix Meschberger]

So we would probably have:

public class Sling {
  private HttpServletRequest request;
  private HttpServletResponse response;

  public void include(String path) throws ServletException, IOException
{
  RequestDispatcher rd = request.getRequestDispatcher(path);
  rd.include(request, response);
  }
}

Would this be for scripting-only ?

Regards
Felix

Am Freitag, den 19.10.2007, 10:57 +0200 schrieb Bertrand Delacretaz:
> On 10/19/07, Felix Meschberger <[EMAIL PROTECTED]> wrote:
> 
> > > ...a convenience class should encapsulate this in order to
> > > make microsling easy to use. either:
> > > sling.include(...)
> > > document.include(...)
> > > response.include(...)
> >
> > Would not do that. People know the Servlet API and we should not invent
> > additional helper stuff, which is just hard to maintain. Rather we will
> > provide taglibs for JSP (in Sling not microsling, though).
> 
> Why taglibs for JSP and no equivalents for other languages?
> 
> In my view of microsling's target audience, people should not need to
> know the Servlet API to do a simple include: that's something people
> do all the time, so it should be obvious.
> 
> And I don't want to cripple microsling either, it's smaller than
> Sling, less extensible, and lacks enterprise-level features maybe, but
> microsling users should not feel like second-class citizens, IMHO.
> 
> So I really think we need a comfortable way to include content in
> microsling scripts.
> 
> -Bertrand

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

[Felix Meschberger]

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: svn commit: r586028 - in /incubator/sling/whiteboard/microsling/src: main/java/org/apache/sling/microsling/api/ main/java/org/apache/sling/microsling/request/ main/java/org/apache/sling/microsling

[Felix Meschberger]

Am Donnerstag, den 18.10.2007, 16:34 + schrieb
[EMAIL PROTECTED]:
> Author: bdelacretaz
> Date: Thu Oct 18 09:34:01 2007
> New Revision: 586028
> ...
> Added: 
> incubator/sling/whiteboard/microsling/src/main/java/org/apache/sling/microsling/services/MicroslingServiceLocator.java
> URL: 
> http://svn.apache.org/viewvc/incubator/sling/whiteboard/microsling/src/main/java/org/apache/sling/microsling/services/MicroslingServiceLocator.java?rev=586028&view=auto
> ==
> --- 
> incubator/sling/whiteboard/microsling/src/main/java/org/apache/sling/microsling/services/MicroslingServiceLocator.java
>  (added)
> +++ 
> incubator/sling/whiteboard/microsling/src/main/java/org/apache/sling/microsling/services/MicroslingServiceLocator.java
>  Thu Oct 18 09:34:01 2007
> ...
> +public Object[] getServices(String serviceName, String filter) 
> +throws InvalidServiceFilterSyntaxException {
> +throw new InvalidServiceFilterSyntaxException(
> +"Sorry, MicroslingServiceLocator.getServices is not 
> implemented");
> +}

I think, the MicroSlingServiceLocator implementation should just return
null and not throw an exception, esp. not an exception which makes no
sense as the filter is not checked for validity.

Regards
Felix

Re: We need an equivalent of sling:include in microsling

[Felix Meschberger]

Hi,

We have the Servlet Request Dispatcher, which IMHO should be used in
microsling (using as much of existing/known API as possible). My
proposal of SLING-64 incorporates a uniform way of calling the scripts
always providing the request, response and context objects. Thus a
script may easily do request.getRequestDispatch(path).include(req, res).

Optionally, we might want to add support for retrieving a
RequestDispatchre using a Resource object, but I am not sure whether we
already require this in microsling.

Regards
Felix

Am Freitag, den 19.10.2007, 10:20 +0200 schrieb Bertrand Delacretaz:
> Hi,
> 
> Maybe an interface like this (to be expanded with more useful
> functions) would be good?
> 
> public interface SlingScriptHelpers {
> /** Include the resource pointed to by the given path in the
> current response */
> void include(String relativeOrAbsolutePath) throws IOException,
> ServletException;
> }
> 
> And this would be made available to scripts as a variable named "sling".
> 
> I haven't looked in detail at the existing Sling stuff, so we might
> need more than that?
> (keeping in mind the minimalism of microsling)
> 
> -Bertrand

Re: svn commit: r586028 - in /incubator/sling/whiteboard/microsling/src: main/java/org/apache/sling/microsling/api/ main/java/org/apache/sling/microsling/request/ main/java/org/apache/sling/microsling

[Felix Meschberger]

Thanks.
Regards
Felix

Am Freitag, den 19.10.2007, 10:27 +0200 schrieb Bertrand Delacretaz:
> On 10/19/07, Felix Meschberger <[EMAIL PROTECTED]> wrote:
> 
> > ...I think, the MicroSlingServiceLocator implementation should just return
> > null and not throw an exception, esp. not an exception which makes no
> > sense as the filter is not checked for validity...
> 
> Agreed, I've changed it as you suggest, in revision 586321.
> 
> -Bertrand

Re: [microsling] Making the Resource in Javascript a little bit more JSON-like

[Felix Meschberger]

Hi Lars,

Am Freitag, den 19.10.2007, 13:44 +0200 schrieb Lars Trieloff:
> 1) Syntax highlighting for ESP: http://weblogs.goshaky.com/weblogs/ 
> lars/entry/esp_javascript_template_language_syntax

Cool. Just one minor note: ESP is not actually inspired by JSTE as it is
used in Day's Communiqué product since the year 2001 :-)

> 2) Making the Javascript objects used in ESP-templates like resource  
> and resource.item a little bit easier to handle by wrapping them in  
> ScriptableObjects. The ESP example could then be simplified to:

Very true. This would in fact be some simplification, though the JCR
purist will of course not like it :-)

I would invite you to contribute such host objects. What do you think ?
Unfortunately, it has been some years (yes it was 2001) since I did my
last ScriptObject implementation ...

Regards
Felix

Re: [microsling] Making the Resource in Javascript a little bit more JSON-like

[Felix Meschberger]

Very good news. Looking forward to it !

Regards
Felix

Am Samstag, den 20.10.2007, 18:59 +0200 schrieb Lars Trieloff:
> >
> > Very true. This would in fact be some simplification, though the JCR
> > purist will of course not like it :-)
> > I would invite you to contribute such host objects. What do you  
> > think ?
> > Unfortunately, it has been some years (yes it was 2001) since I did my
> > last ScriptObject implementation ...
> >
> 
> Great. I will write these objects and keep all the JCR methods, so  
> the JCR-purists can use their Java-API.
> 

Re: svn commit: r586631 - in /incubator/sling/whiteboard/microsling/src: main/java/org/apache/sling/microsling/request/helpers/ main/java/org/apache/sling/microsling/scripting/ main/java/org/apache/sl

[Felix Meschberger]

Hi,

Am Freitag, den 19.10.2007, 22:23 + schrieb [EMAIL PROTECTED]:
> Modified: 
> incubator/sling/whiteboard/microsling/src/main/java/org/apache/sling/microsling/scripting/ScriptEngine.java
> URL: 
> http://svn.apache.org/viewvc/incubator/sling/whiteboard/microsling/src/main/java/org/apache/sling/microsling/scripting/ScriptEngine.java?rev=586631&r1=586630&r2=586631&view=diff
> ==
> --- 
> incubator/sling/whiteboard/microsling/src/main/java/org/apache/sling/microsling/scripting/ScriptEngine.java
>  (original)
> +++ 
> incubator/sling/whiteboard/microsling/src/main/java/org/apache/sling/microsling/scripting/ScriptEngine.java
>  Fri Oct 19 15:23:06 2007
> @@ -30,6 +30,7 @@
>  static final String REQUEST = "request";
>  static final String RESPONSE = "response";
>  static final String RESOURCE = "resource";
> +static final String OUT = "out";
>  

I also had this initially, But in the case of JavaScript the writer
should not be retrieved by the JavaScriptEngine otherwise binary data
may not be generated. Therefore I dropped it again.

We might want to implement some kind of lazy PrintWriter, which only
acquires the response writer when data is to be written to it comparable
to the JSP out.

Regards
Felix