date:20080618

[jira] Commented: (SLING-533) Support multi-value type hints (eg. @TypeHint=String[])

2008-06-18 Thread Carsten Ziegeler (JIRA)


[ 
https://issues.apache.org/jira/browse/SLING-533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12605870#action_12605870
 ] 

Carsten Ziegeler commented on SLING-533:


I applied your docs - many thanks!

> Support multi-value type hints (eg. @TypeHint=String[])
> ---
>
> Key: SLING-533
> URL: https://issues.apache.org/jira/browse/SLING-533
> Project: Sling
>  Issue Type: New Feature
>  Components: Servlets Post
>Reporter: Alexander Klimetschek
>Assignee: Carsten Ziegeler
> Fix For: 2.0.1
>
> Attachments: multival-post-test.html
>
>
> As discussed in SLING-522, when posting a single value to a property that 
> should be multi-valued, an extension to the @TypeHint is needed that allows 
> the explicit definition of a multi-value type. For example, for Strings this 
> would be @TypeHint=String[].
> Based on a quick look at the code, it should happen in 
> o.a.s.servlets.post.impl.helper.SlingPropertyValueHandler.setPropertyAsIs(). 
> First of all the parsing of the getTypeHint() must be changed to look for an 
> ending [] first, and then this "isMultiValued" information must be used to 
> call the multi-value version of setProperty() in all cases (values.length >= 
> 0).

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

Re: [Vote] Release Apache Sling

2008-06-18 Thread Stefan Bodewig

On Tue, 17 Jun 2008, Carsten Ziegeler <[EMAIL PROTECTED]> wrote:

> 9b6d622afc6094d58352e56fd1054642
> sling-3-incubator-source-release.tar.gz
> 4d023f46fda25a99d2b1a4fe8a64dcdd
> sling-3-incubator-source-release.zip

I've not done any functional tests in any way (not competent to do so
anyway 8-) but did the oversight stuff that IPMC members are supposed
to do.

In the past missing license headers have been raised as issues when
the vote was transferred from the project's list over to the Incubator
general list.  Whether this has been right or not may be a different
issue.

Other than that I'd recommend that Carsten uploads his PGP key to a
public keyserver.  I have it in my keyring (I've signed it in
Stuttgart), but searches on keyservers came up empty.

Stefan

Re: [Vote] Release Apache Sling

2008-06-18 Thread Felix Meschberger

Hi Stefan,

Am Mittwoch, den 18.06.2008, 09:21 +0200 schrieb Stefan Bodewig:
> On Tue, 17 Jun 2008, Carsten Ziegeler <[EMAIL PROTECTED]> wrote:
> Other than that I'd recommend that Carsten uploads his PGP key to a
> public keyserver.  I have it in my keyring (I've signed it in
> Stuttgart), but searches on keyservers came up empty.

It should be. At least I found it at [1].

Regards
Felix

[1] http://pgp.mit.edu:11371/pks/lookup?search=cziegeler&op=vindex

Re: [Vote] Release Apache Sling

2008-06-18 Thread Stefan Bodewig

On Wed, 18 Jun 2008, Stefan Bodewig <[EMAIL PROTECTED]> wrote:

> Other than that I'd recommend that Carsten uploads his PGP key to a
> public keyserver.  I have it in my keyring (I've signed it in
> Stuttgart), but searches on keyservers came up empty.

Forget that, user error on my side, it is there.

Sorry

Stefan

Re: [Vote] Release Apache Sling

2008-06-18 Thread pih

+1 everything looks good on our end
Sent via BlackBerry by AT&T

-Original Message-
From: Felix Meschberger <[EMAIL PROTECTED]>

Date: Wed, 18 Jun 2008 07:27:14 
To:sling-dev@incubator.apache.org
Subject: Re: [Vote] Release Apache Sling


Hi Gilles,

Am Dienstag, den 17.06.2008, 22:36 +0200 schrieb Gilles Scokart:
> I run RAT on it.  You can find the result on
> 

Thanks a lot for this !

> There are a few headers missing.  For the
> commons/json/src/main/java/org/apache/sling/commons/json/*.java files,
> I guess it is normal.   But for the other files you should probably
> add the headers.

The classes from commons/json are from http://www.json.org and are not
ASL2 licensed. Therefore these files do _not_ carry the ASL2 header.

Otherfiles without a license header are mostly files, for which there is
no way to define comments (e.g. txt files).

For some files, esp. html and css files, we should probably add these
headers.

> 
> I let you see if you want to fix it before the release or not :-).

I don't think these are a release blockers. Nevertheless I created an
issue [1] to track the addition of these headers ASAP.

Regards
Felix

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


> 
> Gilles
> 
> 2008/6/17 Christophe Lombart <[EMAIL PROTECTED]>:
> > +1 for the release. I have tested the binary archive for app and it works
> > fine with my small demo apps. Good job to the Sling team.
> >
> > Christophe
> >
> > On Tue, Jun 17, 2008 at 3:03 PM, Carsten Ziegeler <[EMAIL PROTECTED]>
> > wrote:
> >
> >> Hi,
> >>
> >> Felix found out that the source release did contain the ".svn" directories
> >> - so I recreated the archive without these dirs.
> >>
> >> Therefore we have new source archives with the following md5 on the server
> >> - everything else is as before:
> >>
> >> 9b6d622afc6094d58352e56fd1054642 sling-3-incubator-source-release.tar.gz
> >> 4d023f46fda25a99d2b1a4fe8a64dcdd sling-3-incubator-source-release.zip
> >>
> >> Sorry for the inconvenience
> >>
> >>
> >> Carsten
> >> --
> >> Carsten Ziegeler
> >> [EMAIL PROTECTED]
> >>
> >
> 
> 
>

Re: [Vote] Release Apache Sling

2008-06-18 Thread Felix Meschberger

NP ;-)

Regards
Felix


Am Mittwoch, den 18.06.2008, 09:33 +0200 schrieb Stefan Bodewig:
> On Wed, 18 Jun 2008, Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> 
> > Other than that I'd recommend that Carsten uploads his PGP key to a
> > public keyserver.  I have it in my keyring (I've signed it in
> > Stuttgart), but searches on keyservers came up empty.
> 
> Forget that, user error on my side, it is there.
> 
> Sorry
> 
> Stefan

Re: [Vote] Release Apache Sling

2008-06-18 Thread Erik Buene


+1.

Nice work

Regards,
Erik Buene



Carsten Ziegeler wrote:

Hello everyone,

it's that special time again! I've cut a new candidate to vote on.
You'll find the releases at:

http://people.apache.org/~cziegeler/releases/sling/releases

The main release is a release of the source tree with the version 
3-incubator as discussed. For convenience we have two additional 
binary releases here: the launchpad app and webapp.


The files to vote with md5 hash are:
27da9cbbb952b4aaf6b67c46e27a22fc 
org.apache.sling.launchpad.app-3-incubator.tar.gz


083f0f664dba790a54fd5ec2fb851858 
org.apache.sling.launchpad.app-3-incubator.zip


702690a9adbe3c0628863c736c8cf74f 
org.apache.sling.launchpad.webapp-3-incubator.tar.gz


841db6bda3ba9f4843a2ffdcaa380646
org.apache.sling.launchpad.webapp-3-incubator.zip

6ec54152886e779e409c9543e51813a7 sling-3-incubator-source-release.tar.gz
56f46217094195ee2fae27deb8f924d7 sling-3-incubator-source-release.zip


In addition I've built the corresponding maven artifacts of all 
modules  which can be found here:


http://people.apache.org/~cziegeler/releases/sling/maven

The KEYS file to check my signature is at
http://people.apache.org/~cziegeler/releases/sling/

This is basically just one big release, so please cast your votes, the 
vote will be open for 72 hours.


Thanks
Carsten

Re: [Vote] Release Apache Sling

2008-06-18 Thread Bertrand Delacretaz

On Tue, Jun 17, 2008 at 12:26 PM, Carsten Ziegeler <[EMAIL PROTECTED]> wrote:
> ...You'll find the releases at:
>
> http://people.apache.org/~cziegeler/releases/sling/releases...

http://people.apache.org/~cziegeler/releases/sling/releases/org.apache.sling.launchpad.app-3-incubator.zip.md5
is empty there.

-Bertrand

Re: [Vote] Release Apache Sling

2008-06-18 Thread Carsten Ziegeler


Bertrand Delacretaz wrote:

On Tue, Jun 17, 2008 at 12:26 PM, Carsten Ziegeler <[EMAIL PROTECTED]> wrote:

...You'll find the releases at:

http://people.apache.org/~cziegeler/releases/sling/releases...


http://people.apache.org/~cziegeler/releases/sling/releases/org.apache.sling.launchpad.app-3-incubator.zip.md5
is empty there.


Thanks for reporting - it's fixed now.

The strange thing is that it wasn't empty yesterday when I generated the 
vote mail out of it. Anyway the md5 is still 
"083f0f664dba790a54fd5ec2fb851858" for that file of course.


Carsten

--
Carsten Ziegeler
[EMAIL PROTECTED]

Re: [Vote] Release Apache Sling

2008-06-18 Thread Bertrand Delacretaz

Hi,

+1 to the release, thanks Carsten for preparing it!

List of what I've checked follows (macosx 10.4.11, java version
"1.5.0_13", mvn 2.0.7).

-Bertrand

On Tue, Jun 17, 2008 at 3:03 PM, Carsten Ziegeler <[EMAIL PROTECTED]> wrote:
> 9b6d622afc6094d58352e56fd1054642 sling-3-incubator-source-release.tar.gz
> 4d023f46fda25a99d2b1a4fe8a64dcdd sling-3-incubator-source-release.zip

md5, sha1 and signatures match.

Contents match exactly what's under
http://svn.apache.org/repos/asf/incubator/sling/tags/sling-3-incubator-source-release/

That code builds and passes all tests (with export MAVEN_OPTS="-Xmx256M")

27da9cbbb952b4aaf6b67c46e27a22fc
org.apache.sling.launchpad.app-3-incubator.tar.gz
083f0f664dba790a54fd5ec2fb851858 org.apache.sling.launchpad.app-3-incubator.zip

Those have .DS_Store remains in them - not a blocker for the release.
The runnable jars found in those pass all launchpad/webapp tests.

702690a9adbe3c0628863c736c8cf74f
org.apache.sling.launchpad.webapp-3-incubator.tar.gz
841db6bda3ba9f4843a2ffdcaa380646
org.apache.sling.launchpad.webapp-3-incubator.zip

Those also contain some macosx junk, not a blocker for the release.
The war file found inside passes all the launchpad/webapp integration
tests, except RedirectTest and HttpPingTest, apparently because under
the tomcat 5.5.16 version that I used for my tests the redirects are
made to /index.html? instead of /index.html - not a blocker.

> In addition I've built the corresponding maven artifacts of all modules  
> which can be found here:
> http://people.apache.org/~cziegeler/releases/sling/maven

Checked signatures and digests, ok.
Checked the jar files by using them in the launchpad/webapp jar - all
integration tests pass.

-Bertrand

[jira] Created: (SLING-544) RAT report for sling-3-incubator-source-release

2008-06-18 Thread Bertrand Delacretaz (JIRA)

RAT report for sling-3-incubator-source-release
---

 Key: SLING-544
 URL: https://issues.apache.org/jira/browse/SLING-544
 Project: Sling
  Issue Type: Task
Reporter: Bertrand Delacretaz
Priority: Minor
 Fix For: 2.0.0


I'll attach the RAT report for  
http://svn.apache.org/repos/asf/incubator/sling/tags/sling-3-incubator-source-release
 to this issue, with comments

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

[jira] Updated: (SLING-544) RAT report for sling-3-incubator-source-release

2008-06-18 Thread Bertrand Delacretaz (JIRA)


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

Bertrand Delacretaz updated SLING-544:
--

Attachment: sling-3-incubator-source-release.txt

Here's the RAT report, generated using 

  java -jar rat-app-0.6-SNAPSHOT.jar . 

After building rat from its revision 669133.

> RAT report for sling-3-incubator-source-release
> ---
>
> Key: SLING-544
> URL: https://issues.apache.org/jira/browse/SLING-544
> Project: Sling
>  Issue Type: Task
>Reporter: Bertrand Delacretaz
>Priority: Minor
> Fix For: 2.0.0
>
> Attachments: sling-3-incubator-source-release.txt
>
>
> I'll attach the RAT report for  
> http://svn.apache.org/repos/asf/incubator/sling/tags/sling-3-incubator-source-release
>  to this issue, with comments

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

[jira] Commented: (SLING-544) RAT report for sling-3-incubator-source-release

2008-06-18 Thread Felix Meschberger (JIRA)


[ 
https://issues.apache.org/jira/browse/SLING-544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12605913#action_12605913
 ] 

Felix Meschberger commented on SLING-544:
-

This sounds like a duplicate of SLING-543 ;-)

> RAT report for sling-3-incubator-source-release
> ---
>
> Key: SLING-544
> URL: https://issues.apache.org/jira/browse/SLING-544
> Project: Sling
>  Issue Type: Task
>Reporter: Bertrand Delacretaz
>Priority: Minor
> Fix For: 2.0.0
>
> Attachments: sling-3-incubator-source-release.txt
>
>
> I'll attach the RAT report for  
> http://svn.apache.org/repos/asf/incubator/sling/tags/sling-3-incubator-source-release
>  to this issue, with comments

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

Re: svn commit: r668178 - in /incubator/sling/trunk: jcr/api/src/main/resources/META-INF/ launchpad/app/ launchpad/app/src/main/resources/META-INF/ launchpad/webapp/src/main/webapp/WEB-INF/

2008-06-18 Thread Felix Meschberger

Hi Roy,

You mean, just add this text like in
http://svn.apache.org/viewvc?rev=669137&view=rev ?

Thanks and Regards
Felix


Am Dienstag, den 17.06.2008, 14:00 +0200 schrieb Roy T. Fielding:
> Umm, this is incomplete.  Apache doesn't redistribute the JCR jar under
> the Specification License.  Apache can distribute the binary under the
> additional terms that are posted on the Day maven site
> 
> http://www.day.com/maven/jsr170/jars/LICENSE.txt
> 
> so that should be included in the launchpad LICENSE for JCR.
> 
> This is not a showstopper for release (just a documentation bug).
> 
> Roy
> 
> On Jun 16, 2008, at 4:56 PM, [EMAIL PROTECTED] wrote:
> 
> > Author: jukka
> > Date: Mon Jun 16 07:56:04 2008
> > New Revision: 668178
> >
> > URL: http://svn.apache.org/viewvc?rev=668178&view=rev
> > Log:
> > SLING-539: Merge LICENSE.* information to LICENSE files
> > - JCR API license
> >
> > Removed:
> > incubator/sling/trunk/jcr/api/src/main/resources/META-INF/ 
> > LICENSE.jcr
> > incubator/sling/trunk/launchpad/app/src/main/resources/META-INF/ 
> > LICENSE.jcr
> > incubator/sling/trunk/launchpad/webapp/src/main/webapp/WEB-INF/ 
> > LICENSE.jcr
> > Modified:
> > incubator/sling/trunk/jcr/api/src/main/resources/META-INF/LICENSE
> > incubator/sling/trunk/launchpad/app/pom.xml
> > incubator/sling/trunk/launchpad/app/src/main/resources/META-INF/ 
> > LICENSE
> > incubator/sling/trunk/launchpad/webapp/src/main/webapp/WEB-INF/ 
> > LICENSE
> > ...

[jira] Updated: (SLING-544) RAT report for sling-3-incubator-source-release

2008-06-18 Thread Bertrand Delacretaz (JIRA)


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

Bertrand Delacretaz updated SLING-544:
--

Attachment: rat-missing-headers.txt

This attachment contains the lines that contain  in the rat report.

Apart from the commons/json code, where we kept the original headers, those are 
small test or utility files with no creative content.

The only files that could arguably be considered creative are IMO:

  launchpad/content/src/main/resources/content/sling.css
  launchpad/content/src/main/resources/content/index.html

To which I added the Apache License header in revision 669136 - I don't think 
that's a blocker for the current release.

> RAT report for sling-3-incubator-source-release
> ---
>
> Key: SLING-544
> URL: https://issues.apache.org/jira/browse/SLING-544
> Project: Sling
>  Issue Type: Task
>Reporter: Bertrand Delacretaz
>Priority: Minor
> Fix For: 2.0.0
>
> Attachments: rat-missing-headers.txt, 
> sling-3-incubator-source-release.txt
>
>
> I'll attach the RAT report for  
> http://svn.apache.org/repos/asf/incubator/sling/tags/sling-3-incubator-source-release
>  to this issue, with comments

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

[jira] Closed: (SLING-544) RAT report for sling-3-incubator-source-release

2008-06-18 Thread Bertrand Delacretaz (JIRA)


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

Bertrand Delacretaz closed SLING-544.
-

Resolution: Fixed

Sorry about the duplicate with SLING-543 - as this issue has the complete RAT 
report that might be useful for the Incubator release vote, let's keep it as 
is, and use SLING-543 to work on the remaining missing headers.

Closing this issue now.

> RAT report for sling-3-incubator-source-release
> ---
>
> Key: SLING-544
> URL: https://issues.apache.org/jira/browse/SLING-544
> Project: Sling
>  Issue Type: Task
>Reporter: Bertrand Delacretaz
>Priority: Minor
> Fix For: 2.0.0
>
> Attachments: rat-missing-headers.txt, 
> sling-3-incubator-source-release.txt
>
>
> I'll attach the RAT report for  
> http://svn.apache.org/repos/asf/incubator/sling/tags/sling-3-incubator-source-release
>  to this issue, with comments

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

Re: [Vote] Release Apache Sling

2008-06-18 Thread Bertrand Delacretaz

On Wed, Jun 18, 2008 at 12:52 PM, Bertrand Delacretaz
<[EMAIL PROTECTED]> wrote:
> ...+1 to the release, thanks Carsten for preparing it!...

I have also added the full RAT report to
https://issues.apache.org/jira/browse/SLING-544, it might be useful
once we ask the Incubator PMC to vote on the release.

-Bertrand

Json Rendering

2008-06-18 Thread Christophe Lombart

Hi all,

I would like to modify the Json rendering. I want to add the node path &
name. What is the best way to extend the JsonServlet for this kind of
requirements ? I would like to do it for any kind of resource types & Jcr
Node types. That's why I would like to avoid to add a new scripts for each
types. I thought to build my own json servlet bur I'm just wondering if
there is not another way to do that.


Thanks,
Christophe

Re: Json Rendering

2008-06-18 Thread Bertrand Delacretaz

Hi Christophe,

On Wed, Jun 18, 2008 at 1:42 PM, Christophe Lombart
<[EMAIL PROTECTED]> wrote:
> ...I would like to modify the Json rendering. I want to add the node path &
> name. What is the best way to extend the JsonServlet for this kind of
> requirements ?...

The JSON rendering is done by the DefaultGetServlet, which is
hardwired to use the JsonRendererServlet for .json extensions.

If you create a Servlet that extends JsonRendererServlet, and register
it in the same way than the DefaultGetServlet, with an additional

  @scr.property name="sling.servlet.extensions" value="json"

it should be used for .json requests instead of the DefaultGetServlet.

Note that JsonRendererServlet does not currently provide an easy way
to replace just the node-dumping method, we might need to refactor it
to make that easier.

-Bertrand

Re: Json Rendering

2008-06-18 Thread Christophe Lombart

Hi Bertrand,

Thanks for the info.

On Wed, Jun 18, 2008 at 1:51 PM, Bertrand Delacretaz <[EMAIL PROTECTED]>
wrote:

>
> Note that JsonRendererServlet does not currently provide an easy way
> to replace just the node-dumping method, we might need to refactor it
> to make that easier.
>

Something like providing a new JsonWriter component at runtime ?

> -Bertrand
>

Re: Json Rendering

2008-06-18 Thread Bertrand Delacretaz

On Wed, Jun 18, 2008 at 2:01 PM, Christophe Lombart
<[EMAIL PROTECTED]> wrote:

> On Wed, Jun 18, 2008 at 1:51 PM, Bertrand Delacretaz <[EMAIL PROTECTED]>
>> ...Note that JsonRendererServlet does not currently provide an easy way
>> to replace just the node-dumping method, we might need to refactor it
>> to make that easier
>>
> Something like providing a new JsonWriter component at runtime ?

Yes, that would work. We could also have a JsonWriterFactory that's an
OSGi service, but that feels like overkill right now.

-Bertrand

Using selectors for script resolution

2008-06-18 Thread Erik Buene


Hi

Can I use a selector for script resolution using a collection 
(nt:folder), or just part of the name of an nt:file node in the script?


Given resource type "foo" on a node "content", this mapping

 /content.sel.ext -> /apps/foo/sel.ext.esp

works, but

 /content.sel.ext -> /apps/foo/sel/ext.esp

does not seem to work.

I would like to store some other files along with the script, therefore 
a collection would be more suitable.



Regards,
Erik Buene

Re: [Vote] Release Apache Sling

2008-06-18 Thread Jukka Zitting

Hi,

On Tue, Jun 17, 2008 at 1:26 PM, Carsten Ziegeler <[EMAIL PROTECTED]> wrote:
> it's that special time again! I've cut a new candidate to vote on.
> You'll find the releases at:
>
> http://people.apache.org/~cziegeler/releases/sling/releases
> [...]
> This is basically just one big release, so please cast your votes, the vote
> will be open for 72 hours.

+1 Looks good. Thanks for the great work (and for addressing my
previous concerns)!

I checked the signatures, built and tested the code (on RHEL 4, Sun
Java 1.5.0_10, Maven 2.0.9), checked the LICENSE and NOTICE files,
etc. Everything OK.

BR,

Jukka Zitting

Re: Using selectors for script resolution

2008-06-18 Thread Alexander Klimetschek

Have a look at the issue and the discussion on this topic:

https://issues.apache.org/jira/browse/SLING-387

http://markmail.org/message/tksvk4xfwapdpkwo

Regards,
Alex

On Wed, Jun 18, 2008 at 2:05 PM, Erik Buene <[EMAIL PROTECTED]> wrote:
> Hi
>
> Can I use a selector for script resolution using a collection (nt:folder),
> or just part of the name of an nt:file node in the script?
>
> Given resource type "foo" on a node "content", this mapping
>
>  /content.sel.ext -> /apps/foo/sel.ext.esp
>
> works, but
>
>  /content.sel.ext -> /apps/foo/sel/ext.esp
>
> does not seem to work.
>
> I would like to store some other files along with the script, therefore a
> collection would be more suitable.
>
>
> Regards,
> Erik Buene
>
>

-- 
Alexander Klimetschek
[EMAIL PROTECTED]

Re: Using selectors for script resolution

2008-06-18 Thread Bertrand Delacretaz

On Wed, Jun 18, 2008 at 3:09 PM, Alexander Klimetschek <[EMAIL PROTECTED]> 
wrote:
> ...
> https://issues.apache.org/jira/browse/SLING-387
> http://markmail.org/message/tksvk4xfwapdpkwo
>...

Note that 
http://svn.apache.org/repos/asf/incubator/sling/trunk/servlets/resolver/src/test/java/org/apache/sling/servlets/resolver/helper/ScriptSelectionTest.java
is meant to contain the Absolute Truth about how scripts are selected.
Patches to this Absolute Truth are welcome, of course ;-)

-Bertrand

Re: Json Rendering

2008-06-18 Thread Alexander Klimetschek

On Wed, Jun 18, 2008 at 2:04 PM, Bertrand Delacretaz
<[EMAIL PROTECTED]> wrote:
>> Something like providing a new JsonWriter component at runtime ?
>
> Yes, that would work. We could also have a JsonWriterFactory that's an
> OSGi service, but that feels like overkill right now.

Yes, I have the same feeling. I think it is a general issue: as the
default servlets are a core feature in Sling (ie. simple updating of
JCR content), but very often you want to customize the behaviour for
certain properties or nodes, this seems like a general pattern, that
yet needs to be solved. Having a different plugin architecture in each
default servlet (providing custom writers, request objects etc.) feels
like the wrong solution. Especially if you consider the elegant way of
script/servlet resolution in Sling by using resource-types with
inheritance etc.

IMHO this is the same (development) problem that Ruby on Rails solved
very well: using scaffolding to provide a working out-of-the-box
experience but then also allowing you to refine the default behaviour
step-by-step. The way it's done in Ruby is a combination of source
generating scripts, code generating logic in the classes itself (easy
with a dynamic language) and also using Ruby's missing-method (that is
called when a method is called that is not defined on the object).

I have no clear solution in my head, but I think it's a place where
Sling could improve. WDYT?

Regards,
Alex

-- 
Alexander Klimetschek
[EMAIL PROTECTED]

Re: Json Rendering

2008-06-18 Thread Carsten Ziegeler


Alexander Klimetschek wrote:

On Wed, Jun 18, 2008 at 2:04 PM, Bertrand Delacretaz
<[EMAIL PROTECTED]> wrote:

Something like providing a new JsonWriter component at runtime ?

Yes, that would work. We could also have a JsonWriterFactory that's an
OSGi service, but that feels like overkill right now.


Yes, I have the same feeling. I think it is a general issue: as the
default servlets are a core feature in Sling (ie. simple updating of
JCR content), but very often you want to customize the behaviour for
certain properties or nodes, this seems like a general pattern, that
yet needs to be solved. Having a different plugin architecture in each
default servlet (providing custom writers, request objects etc.) feels
like the wrong solution. Especially if you consider the elegant way of
script/servlet resolution in Sling by using resource-types with
inheritance etc.

IMHO this is the same (development) problem that Ruby on Rails solved
very well: using scaffolding to provide a working out-of-the-box
experience but then also allowing you to refine the default behaviour
step-by-step. The way it's done in Ruby is a combination of source
generating scripts, code generating logic in the classes itself (easy
with a dynamic language) and also using Ruby's missing-method (that is
called when a method is called that is not defined on the object).

I have no clear solution in my head, but I think it's a place where
Sling could improve. WDYT?

Not sure :) Can we first collect the possible use cases? Is one use case 
to replace the json renderer completely? Or do you want to use a 
different json renderer depending on the path or the resource type?


Carsten

--
Carsten Ziegeler
[EMAIL PROTECTED]

Re: Json Rendering

2008-06-18 Thread Christophe Lombart

In my use case, only one thing is missing in the current implementation.
Maybe I'm wrong but I think it is not possible to apply the same script for
all kind of Sling resource types and/or Jcr Node types.

For example :
If the case of a GET with a Json extension (with or without selectors) is
required, I would like to resolve the same esp script.  Is it not a simple
solution ? WDYT?

On Wed, Jun 18, 2008 at 3:41 PM, Carsten Ziegeler <[EMAIL PROTECTED]>
wrote:

> Alexander Klimetschek wrote:
>
>> On Wed, Jun 18, 2008 at 2:04 PM, Bertrand Delacretaz
>> <[EMAIL PROTECTED]> wrote:
>>
>>> Something like providing a new JsonWriter component at runtime ?

>>> Yes, that would work. We could also have a JsonWriterFactory that's an
>>> OSGi service, but that feels like overkill right now.
>>>
>>
>> Yes, I have the same feeling. I think it is a general issue: as the
>> default servlets are a core feature in Sling (ie. simple updating of
>> JCR content), but very often you want to customize the behaviour for
>> certain properties or nodes, this seems like a general pattern, that
>> yet needs to be solved. Having a different plugin architecture in each
>> default servlet (providing custom writers, request objects etc.) feels
>> like the wrong solution. Especially if you consider the elegant way of
>> script/servlet resolution in Sling by using resource-types with
>> inheritance etc.
>>
>> IMHO this is the same (development) problem that Ruby on Rails solved
>> very well: using scaffolding to provide a working out-of-the-box
>> experience but then also allowing you to refine the default behaviour
>> step-by-step. The way it's done in Ruby is a combination of source
>> generating scripts, code generating logic in the classes itself (easy
>> with a dynamic language) and also using Ruby's missing-method (that is
>> called when a method is called that is not defined on the object).
>>
>> I have no clear solution in my head, but I think it's a place where
>> Sling could improve. WDYT?
>>
>>  Not sure :) Can we first collect the possible use cases? Is one use case
> to replace the json renderer completely? Or do you want to use a different
> json renderer depending on the path or the resource type?
>
> Carsten
>
> --
> Carsten Ziegeler
> [EMAIL PROTECTED]
>

Re: Json Rendering

2008-06-18 Thread Alexander Klimetschek

On Wed, Jun 18, 2008 at 3:41 PM, Carsten Ziegeler <[EMAIL PROTECTED]> wrote:
> Not sure :) Can we first collect the possible use cases?

Of course. I just wanted to start a discussion.

> Is one use case to
> replace the json renderer completely? Or do you want to use a different json
> renderer depending on the path or the resource type?

I am talking about all default servlets, including the POST servlet.
Here you might want to handle certain properties differently. Maybe
filters are the way to go, but extensible default servlets are needed
as well, so that you basically only have to write your custom code (in
servlets and scripts) but don't have to copy-and-paste existing
default logic.

Regards,
Alex

-- 
Alexander Klimetschek
[EMAIL PROTECTED]

Re: Json Rendering

2008-06-18 Thread Felix Meschberger

Hi,

Am Mittwoch, den 18.06.2008, 15:52 +0200 schrieb Christophe Lombart:
> In my use case, only one thing is missing in the current implementation.
> Maybe I'm wrong but I think it is not possible to apply the same script for
> all kind of Sling resource types and/or Jcr Node types.
> 
> For example :
> If the case of a GET with a Json extension (with or without selectors) is
> required, I would like to resolve the same esp script.  Is it not a simple
> solution ? WDYT?

Yes, for sure. The simple way to provide a default servlet just for JSON
is to create a script such as /apps/sling/servlet/default/json.esp or
register a servlet with the json extension as Betrand said.

This allows you to completely replace the existing default JSON renderer
for all resource types which do not have their on json servlet or
script.

Hope this helps.

Regads
Felix


> 
> On Wed, Jun 18, 2008 at 3:41 PM, Carsten Ziegeler <[EMAIL PROTECTED]>
> wrote:
> 
> > Alexander Klimetschek wrote:
> >
> >> On Wed, Jun 18, 2008 at 2:04 PM, Bertrand Delacretaz
> >> <[EMAIL PROTECTED]> wrote:
> >>
> >>> Something like providing a new JsonWriter component at runtime ?
> 
> >>> Yes, that would work. We could also have a JsonWriterFactory that's an
> >>> OSGi service, but that feels like overkill right now.
> >>>
> >>
> >> Yes, I have the same feeling. I think it is a general issue: as the
> >> default servlets are a core feature in Sling (ie. simple updating of
> >> JCR content), but very often you want to customize the behaviour for
> >> certain properties or nodes, this seems like a general pattern, that
> >> yet needs to be solved. Having a different plugin architecture in each
> >> default servlet (providing custom writers, request objects etc.) feels
> >> like the wrong solution. Especially if you consider the elegant way of
> >> script/servlet resolution in Sling by using resource-types with
> >> inheritance etc.
> >>
> >> IMHO this is the same (development) problem that Ruby on Rails solved
> >> very well: using scaffolding to provide a working out-of-the-box
> >> experience but then also allowing you to refine the default behaviour
> >> step-by-step. The way it's done in Ruby is a combination of source
> >> generating scripts, code generating logic in the classes itself (easy
> >> with a dynamic language) and also using Ruby's missing-method (that is
> >> called when a method is called that is not defined on the object).
> >>
> >> I have no clear solution in my head, but I think it's a place where
> >> Sling could improve. WDYT?
> >>
> >>  Not sure :) Can we first collect the possible use cases? Is one use case
> > to replace the json renderer completely? Or do you want to use a different
> > json renderer depending on the path or the resource type?
> >
> > Carsten
> >
> > --
> > Carsten Ziegeler
> > [EMAIL PROTECTED]
> >

Re: Json Rendering

2008-06-18 Thread Christophe Lombart

On Wed, Jun 18, 2008 at 3:58 PM, Felix Meschberger <[EMAIL PROTECTED]>
wrote:

> Hi,
>
> Am Mittwoch, den 18.06.2008, 15:52 +0200 schrieb Christophe Lombart:
> > In my use case, only one thing is missing in the current implementation.
> > Maybe I'm wrong but I think it is not possible to apply the same script
> for
> > all kind of Sling resource types and/or Jcr Node types.
> >
> > For example :
> > If the case of a GET with a Json extension (with or without selectors) is
> > required, I would like to resolve the same esp script.  Is it not a
> simple
> > solution ? WDYT?
>
> Yes, for sure. The simple way to provide a default servlet just for JSON
> is to create a script such as /apps/sling/servlet/default/json.esp


 ok thanks :-) I didn't know that

or
> register a servlet with the json extension as Betrand said.




>
> This allows you to completely replace the existing default JSON renderer
> for all resource types which do not have their on json servlet or
> script.
>
> Hope this helps.
>
> Regads
> Felix
>
>
> >
> > On Wed, Jun 18, 2008 at 3:41 PM, Carsten Ziegeler <[EMAIL PROTECTED]>
> > wrote:
> >
> > > Alexander Klimetschek wrote:
> > >
> > >> On Wed, Jun 18, 2008 at 2:04 PM, Bertrand Delacretaz
> > >> <[EMAIL PROTECTED]> wrote:
> > >>
> > >>> Something like providing a new JsonWriter component at runtime ?
> > 
> > >>> Yes, that would work. We could also have a JsonWriterFactory that's
> an
> > >>> OSGi service, but that feels like overkill right now.
> > >>>
> > >>
> > >> Yes, I have the same feeling. I think it is a general issue: as the
> > >> default servlets are a core feature in Sling (ie. simple updating of
> > >> JCR content), but very often you want to customize the behaviour for
> > >> certain properties or nodes, this seems like a general pattern, that
> > >> yet needs to be solved. Having a different plugin architecture in each
> > >> default servlet (providing custom writers, request objects etc.) feels
> > >> like the wrong solution. Especially if you consider the elegant way of
> > >> script/servlet resolution in Sling by using resource-types with
> > >> inheritance etc.
> > >>
> > >> IMHO this is the same (development) problem that Ruby on Rails solved
> > >> very well: using scaffolding to provide a working out-of-the-box
> > >> experience but then also allowing you to refine the default behaviour
> > >> step-by-step. The way it's done in Ruby is a combination of source
> > >> generating scripts, code generating logic in the classes itself (easy
> > >> with a dynamic language) and also using Ruby's missing-method (that is
> > >> called when a method is called that is not defined on the object).
> > >>
> > >> I have no clear solution in my head, but I think it's a place where
> > >> Sling could improve. WDYT?
> > >>
> > >>  Not sure :) Can we first collect the possible use cases? Is one use
> case
> > > to replace the json renderer completely? Or do you want to use a
> different
> > > json renderer depending on the path or the resource type?
> > >
> > > Carsten
> > >
> > > --
> > > Carsten Ziegeler
> > > [EMAIL PROTECTED]
> > >
>
>

RE: Can't resource.adaptTo my AbstractMappedObject

2008-06-18 Thread Craig L. Ching

Anybody have any ideas on how I get my class into this factory?  Just
some general pointers would help, e.g. how am I supposed to get my SCR
registered class into this factory so that I can adapt to it? 

> -Original Message-
> From: Craig L. Ching [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, June 17, 2008 3:18 PM
> To: sling-dev@incubator.apache.org
> Subject: Can't resource.adaptTo my AbstractMappedObject
> 
> Hi all,
> 
> Just updated to trunk and I'm seeing the following problem.  
> If I deploy the sling/samples/simple-demo bundle, I get the 
> following error:
> 
> org.apache.sling.scripting.jsp.jasper.JasperException: An 
> exception occurred processing JSP page 
> /apps/sling/SamplePage/html.jsp at line 34 null Stacktrace: (500)
> 
> The requested URL /sample/content/home.html resulted in an 
> error in /apps/sling/SamplePage/html.jsp.
> Exception:
> 
> org.apache.sling.api.SlingServletException:
> org.apache.sling.scripting.jsp.jasper.JasperException: An 
> exception occurred processing JSP page 
> /apps/sling/SamplePage/html.jsp at line 34
> 
> null
> 
> Stacktrace:
>   at
> org.apache.sling.scripting.jsp.JspServletWrapperAdapter.servic
> e(JspServl
> etWrapperAdapter.java:66)
>   at
> org.apache.sling.scripting.jsp.JspScriptEngineFactory.callJsp(
> JspScriptE
> ngineFactory.java:134)
>   at
> org.apache.sling.scripting.jsp.JspScriptEngineFactory.access$0
> 00(JspScri
> ptEngineFactory.java:72)
>   at
> org.apache.sling.scripting.jsp.JspScriptEngineFactory$JspScrip
> tEngine.ev
> al(JspScriptEngineFactory.java:281)
>   at
> org.apache.sling.scripting.core.impl.DefaultSlingScript.call(D
> efaultSlin
> gScript.java:135)
>   at
> org.apache.sling.scripting.core.impl.DefaultSlingScript.eval(D
> efaultSlin
> gScript.java:106)
>   at
> org.apache.sling.scripting.core.impl.DefaultSlingScript.servic
> e(DefaultS
> lingScript.java:219)
>   at
> org.apache.sling.engine.impl.request.RequestData.service(Reque
> stData.jav
> a:462)
>   at
> org.apache.sling.engine.impl.SlingMainServlet.processRequest(S
> lingMainSe
> rvlet.java:419)
>   at
> org.apache.sling.engine.impl.filter.RequestSlingFilterChain.re
> nder(Reque
> stSlingFilterChain.java:48)
>   at
> org.apache.sling.engine.impl.filter.AbstractSlingFilterChain.d
> oFilter(Ab
> stractSlingFilterChain.java:54)
>   at
> org.apache.sling.engine.impl.debug.RequestProgressTrackerLogFi
> lter.doFil
> ter(RequestProgressTrackerLogFilter.java:59)
>   at
> org.apache.sling.engine.impl.filter.AbstractSlingFilterChain.d
> oFilter(Ab
> stractSlingFilterChain.java:52)
>   at
> org.apache.sling.engine.impl.SlingMainServlet.service(SlingMai
> nServlet.j
> ava:273)
>   at
> org.apache.sling.engine.impl.SlingMainServlet.service(SlingMai
> nServlet.j
> ava:171)
>   at
> org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487)
>   at
> org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler
> .java:362)
>   at
> org.ops4j.pax.web.service.internal.HttpServiceServletHandler.h
> andle(Http
> ServiceServletHandler.java:51)
>   at
> org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler
> .java:181)
>   at
> org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler
> .java:722)
>   at
> org.ops4j.pax.web.service.internal.HttpServiceContext.handle(H
> ttpService
> Context.java:87)
>   at
> org.ops4j.pax.web.service.internal.JettyServerHandlerCollectio
> n.handle(J
> ettyServerHandlerCollection.java:63)
>   at
> org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper
> .java:139)
>   at org.mortbay.jetty.Server.handle(Server.java:324)
>   at
> org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.
> java:505)
>   at
> org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete
> (HttpConne
> ction.java:828)
>   at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:514)
>   at
> org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211)
>   at
> org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380)
>   at
> org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketCon
> nector.jav
> a:228)
>   at
> org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThr
> eadPool.ja
> va:450)
> Caused by: 
> org.apache.sling.scripting.jsp.jasper.JasperException: An 
> exception occurred processing JSP page 
> /apps/sling/SamplePage/html.jsp at line 34
> 
> null
> 
> Stacktrace:
>   at
> org.apache.sling.scripting.jsp.jasper.servlet.JspServletWrappe
> r.handleJs
> pException(JspServletWrapper.java:524)
>   at
> org.apache.sling.scripting.jsp.jasper.servlet.JspServletWrappe
> r.service(
> JspServletWrapper.java:435)
>   at
> org.apache.sling.scripting.jsp.JspServletWrapperAdapter.servic
> e(JspServl
> etWrapperAdapter.java:59)
>   ... 30 more
> Caused by: java.lang.NullPointerException
>   at
> org.apache.jsp.apps.sling.SamplePage.html_jsp._jspService(html
> _jsp.java:
> 11

RE: Json Rendering

2008-06-18 Thread Craig L. Ching

Hi Christophe,

I'm not sure if this interests you or not, but I have a similar need
with respect to the JCR explorer.  I have a patch here
(https://issues.apache.org/jira/browse/SLING-518) that I'm waiting for
someone to give guidance on.  I'd be happy to hear what you come up with
and maybe we can find a good, extensible solution together.  If nothing
else, maybe it gives you an idea of how to proceed.

Cheers,
Craig

> -Original Message-
> From: Christophe Lombart [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, June 18, 2008 6:43 AM
> To: sling-dev@incubator.apache.org
> Subject: Json Rendering
> 
> Hi all,
> 
> I would like to modify the Json rendering. I want to add the 
> node path & name. What is the best way to extend the 
> JsonServlet for this kind of requirements ? I would like to 
> do it for any kind of resource types & Jcr Node types. That's 
> why I would like to avoid to add a new scripts for each 
> types. I thought to build my own json servlet bur I'm just 
> wondering if there is not another way to do that.
> 
> 
> Thanks,
> Christophe
> 
>

[jira] Resolved: (SLING-466) JST scripting engine: render indexable HTML and separate javascript code

2008-06-18 Thread Bertrand Delacretaz (JIRA)


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

Bertrand Delacretaz resolved SLING-466.
---

Resolution: Fixed

Unit tests added in r669182, closing this for now.

> JST scripting engine: render indexable HTML and separate javascript code
> 
>
> Key: SLING-466
> URL: https://issues.apache.org/jira/browse/SLING-466
> Project: Sling
>  Issue Type: Improvement
>  Components: Scripting
>Reporter: Bertrand Delacretaz
>Priority: Minor
>
> The JST scripting engine should output a default HTML rendering, meant to be 
> indexed by search engines, with a

Re: Json Rendering

2008-06-18 Thread Christophe Lombart

ok I will look at this.

Thanks
Christophe


On Wed, Jun 18, 2008 at 4:18 PM, Craig L. Ching <[EMAIL PROTECTED]>
wrote:

> Hi Christophe,
>
> I'm not sure if this interests you or not, but I have a similar need
> with respect to the JCR explorer.  I have a patch here
> (https://issues.apache.org/jira/browse/SLING-518) that I'm waiting for
> someone to give guidance on.  I'd be happy to hear what you come up with
> and maybe we can find a good, extensible solution together.  If nothing
> else, maybe it gives you an idea of how to proceed.
>
> Cheers,
> Craig
>
> > -Original Message-
> > From: Christophe Lombart [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, June 18, 2008 6:43 AM
> > To: sling-dev@incubator.apache.org
> > Subject: Json Rendering
> >
> > Hi all,
> >
> > I would like to modify the Json rendering. I want to add the
> > node path & name. What is the best way to extend the
> > JsonServlet for this kind of requirements ? I would like to
> > do it for any kind of resource types & Jcr Node types. That's
> > why I would like to avoid to add a new scripts for each
> > types. I thought to build my own json servlet bur I'm just
> > wondering if there is not another way to do that.
> >
> >
> > Thanks,
> > Christophe
> >
> >
>

RE: Json Rendering

2008-06-18 Thread Craig L. Ching

Hi Alexander, 

> -Original Message-
> From: Alexander Klimetschek [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, June 18, 2008 8:31 AM
> To: sling-dev@incubator.apache.org
> Subject: Re: Json Rendering
> 
> On Wed, Jun 18, 2008 at 2:04 PM, Bertrand Delacretaz 
> <[EMAIL PROTECTED]> wrote:
> >> Something like providing a new JsonWriter component at runtime ?
> >
> > Yes, that would work. We could also have a 
> JsonWriterFactory that's an 
> > OSGi service, but that feels like overkill right now.
> 
> Yes, I have the same feeling. I think it is a general issue: 
> as the default servlets are a core feature in Sling (ie. 
> simple updating of JCR content), but very often you want to 
> customize the behaviour for certain properties or nodes, this 
> seems like a general pattern, that yet needs to be solved. 
> Having a different plugin architecture in each default 
> servlet (providing custom writers, request objects etc.) 
> feels like the wrong solution. Especially if you consider the 
> elegant way of script/servlet resolution in Sling by using 
> resource-types with inheritance etc.
> 
> IMHO this is the same (development) problem that Ruby on 
> Rails solved very well: using scaffolding to provide a 
> working out-of-the-box experience but then also allowing you 
> to refine the default behaviour step-by-step. The way it's 
> done in Ruby is a combination of source generating scripts, 
> code generating logic in the classes itself (easy with a 
> dynamic language) and also using Ruby's missing-method (that 
> is called when a method is called that is not defined on the object).
> 
> I have no clear solution in my head, but I think it's a place 
> where Sling could improve. WDYT?
> 

You had suggested that I use a selector for my special json rendering,
would maybe allowing the user to map a rendering output to a selector in
a general way be a good way to do this?  You might need to "namespace"
the selectors so that you don't collide with potential future
sling-provided selectors, but I'm not sure if that's a valid idea or not
given the fairly strict rules govering URI composition.  Something like
this would help me with the JCR explorer and my need for more
information about the nodes than the current JSON rendering provides
today.  Just a thought.

> Regards,
> Alex
> 
> --
> Alexander Klimetschek
> [EMAIL PROTECTED]
> 

Cheers,
Craig

Re: Json Rendering

2008-06-18 Thread Bertrand Delacretaz

On Wed, Jun 18, 2008 at 3:58 PM, Felix Meschberger <[EMAIL PROTECTED]> wrote:

> ...The simple way to provide a default servlet just for JSON
> is to create a script such as /apps/sling/servlet/default/json.esp...

Good one - I forgot about this option, but you're right that it's the
simplest way to experiment.

I have added the explanation to the FAQ at
http://cwiki.apache.org/SLING/faq.html .

-Bertrand

Re: Can't resource.adaptTo my AbstractMappedObject

2008-06-18 Thread Alexander Klimetschek

On Wed, Jun 18, 2008 at 4:11 PM, Craig L. Ching <[EMAIL PROTECTED]> wrote:
>> Looking into it further, I don't seem to have a factory for
>> my class, according to this code in AdapterManagerImpl.java:
>>
>> // get the factory for the target type
>> AdapterFactory factory = factories.get(type.getName());

I think implementing an AdapterFactory and providing scr properties
"adaptables" and "adapters" should do the trick. Have a look at the
javadocs:

http://svn.apache.org/repos/asf/incubator/sling/trunk/api/src/main/java/org/apache/sling/api/adapter/AdapterFactory.java

Regards,
Alex

-- 
Alexander Klimetschek
[EMAIL PROTECTED]

RE: Can't resource.adaptTo my AbstractMappedObject

2008-06-18 Thread Craig L. Ching

Hi Alex, 

> -Original Message-
> From: Alexander Klimetschek [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, June 18, 2008 10:01 AM
> To: sling-dev@incubator.apache.org
> Subject: Re: Can't resource.adaptTo my AbstractMappedObject
> 
> On Wed, Jun 18, 2008 at 4:11 PM, Craig L. Ching 
> <[EMAIL PROTECTED]> wrote:
> >> Looking into it further, I don't seem to have a factory 
> for my class, 
> >> according to this code in AdapterManagerImpl.java:
> >>
> >> // get the factory for the target type
> >> AdapterFactory factory = factories.get(type.getName());
> 
> I think implementing an AdapterFactory and providing scr 
> properties "adaptables" and "adapters" should do the trick. 
> Have a look at the
> javadocs:
> 
> http://svn.apache.org/repos/asf/incubator/sling/trunk/api/src/
> main/java/org/apache/sling/api/adapter/AdapterFactory.java
> 

Is that something new then?  I didn't have to do this before ...  I
thought that the OCM or SCR or something took care of doing that for me,
at least I assumed that ;-)

> Regards,
> Alex
> 
> --
> Alexander Klimetschek
> [EMAIL PROTECTED]
>

Re: Json Rendering

2008-06-18 Thread Bertrand Delacretaz

Hi Craig,

On Wed, Jun 18, 2008 at 4:18 PM, Craig L. Ching <[EMAIL PROTECTED]> wrote:
> ... have a patch here
> (https://issues.apache.org/jira/browse/SLING-518) that I'm waiting for
> someone to give guidance on

I had a quick look, and I think creating a custom JSON rendering
servlet, by inheriting from the JsonRendererServlet, and wirting that
to the json extension and a specific selector might be better that the
proposed patch. Unless you guys can come up with a simple generalized
way of "flavoring" the JSON output.

-Bertrand

RE: Json Rendering

2008-06-18 Thread Craig L. Ching

Hi Bertrand, 

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On 
> Behalf Of Bertrand Delacretaz
> Sent: Wednesday, June 18, 2008 10:08 AM
> To: sling-dev@incubator.apache.org
> Subject: Re: Json Rendering
> 
> Hi Craig,
> 
> On Wed, Jun 18, 2008 at 4:18 PM, Craig L. Ching 
> <[EMAIL PROTECTED]> wrote:
> > ... have a patch here
> > (https://issues.apache.org/jira/browse/SLING-518) that I'm 
> waiting for 
> > someone to give guidance on
> 
> I had a quick look, and I think creating a custom JSON 
> rendering servlet, by inheriting from the 
> JsonRendererServlet, and wirting that to the json extension 
> and a specific selector might be better that the proposed 
> patch. Unless you guys can come up with a simple generalized 
> way of "flavoring" the JSON output.
> 
Ok, you didn't like my hard-coded meta selector in the existing servlet
then? ;-)  I kind of figured that a whole new servlet would have been
overkill for this, but I'm happy to do what you guys think is best.
Question then, how do I map the selector to my new servlet?  In other
words, is there a way to map to a servlet based on selector?  I may be
showing my sling noobness here ;-)  Feel free to point me to the
documentation if it's documented, I have a feeling I've read about this
already and I'm just not recalling ...

Thanks for the input!

> -Bertrand
> 

Cheers,
Craig

Re: Json Rendering

2008-06-18 Thread Bertrand Delacretaz

Hi,

On Wed, Jun 18, 2008 at 5:13 PM, Craig L. Ching <[EMAIL PROTECTED]> wrote:
> ...how do I map the selector to my new servlet?  In other
> words, is there a way to map to a servlet based on selector? ...

Yes, http://incubator.apache.org/sling/site/servlet-resolution.html
has the docs (didn't check if they're fully up to date), and the
JsonQueryServlet [1] is a good example:

 * @scr.property name="sling.servlet.resourceTypes"
 *   value="sling/servlet/default"
 * @scr.property name="sling.servlet.extensions" value="json"
 * @scr.property name="sling.servlet.selectors" value="query"

In this case the servlets handles .query.json requests.

So you just have to invent a selector, extend the JsonRendererServlet,
register it as above and that should work.

-Bertrand

[1] 
http://svn.apache.org/repos/asf/incubator/sling/trunk/servlets/get/src/main/java/org/apache/sling/servlets/get/JsonQueryServlet.java

RE: Json Rendering

2008-06-18 Thread Craig L. Ching

 

> selector?  I may be showing my sling noobness here ;-)  Feel 
> free to point me to the documentation if it's documented, I 
> have a feeling I've read about this already and I'm just not 
> recalling ...
> 
Ok, think I found the doc [1], let me see if I can put something
together based on this then.  Thanks!


[1] -- http://incubator.apache.org/sling/site/servlet-resolution.html
> 
> Cheers,
> Craig
> 

Cheers,
Craig

Re: Can't resource.adaptTo my AbstractMappedObject

2008-06-18 Thread Alexander Klimetschek

On Wed, Jun 18, 2008 at 5:07 PM, Craig L. Ching <[EMAIL PROTECTED]> wrote:
> Is that something new then?  I didn't have to do this before ...

I think it is quite new. But AFAIK it is an additional feature
compared to the standard way of implementing Adaptable in your
Resource class. It allows to build "adaptation" outside the affected
classes.

> I thought that the OCM or SCR or something took care of doing that for me,
> at least I assumed that ;-)

OCM is not involved here. SCR is a generic component /
dependency-injection framework in Apache Felix. You always have to
configure it, preferrably with the @scr.* javadoc tags that are
converted into the actual component xml description files by the
maven-scr-plugin. That's how its done throughout Sling. What
properties are available and who will be picking up the component or
service depends on the service. For the AdaptableFactory it's the
AdaptableManagerImpl, that you debugged, which referencs all
AdapterFactories that are registered as scr components/services.

Regards,
Alex

-- 
Alexander Klimetschek
[EMAIL PROTECTED]

Re: More customizable standard GET and POST servlets (was: Json Rendering)

2008-06-18 Thread Alexander Klimetschek

On Wed, Jun 18, 2008 at 5:04 PM, Bertrand Delacretaz
<[EMAIL PROTECTED]> wrote:
> I have two use cases in mind where this would be useful:
>
> 1) Generating different flavors of JSON output, probably based on selectors
>
> 2) Allowing scripts to reuse part of the POST servlet functionality,
> while customizing part of the POST request processing.

Agreed. So far I haven't seen another use case, too. Although there
might be some...

> I think 1) is fairly easy to solve by making the JsonRendererServlet
> more expandable, maybe simply factoring out the instantiation of the
> JsonItemWriter so that people can provide custom variants, by
> registering servlets that extend JsonRendererServlet. I think this
> "standard rendering customization" only makes sense for the JSON
> format currently, so no need for a generalized framework.

Sounds good.

> Solving 2) looks like a different problem, where the SlingPostServlet
> functionality might need to be broken down in smaller services and
> components that scripts can reuse in a modular way.

I would try to make it extendable (in the OO-sense). That would be
consistent with 1) and is IMHO the natural choice in Java. Having to
register a new set of services seems like overkill to me. Although
this doesn't allow scripts as a replacement for the post servlet - at
least if you don't want to copy the code.

> I don't see other use cases for customizing our standard servlets at
> the moment, so I feel the above two cases can be handled "locally"
> without creating a generalized (and possibly complex) customization
> framework.

That was my point: I don't want a complex customization framework. A
simple and consistent way like inheritance is good, I think.

Regards,
Alex

-- 
Alexander Klimetschek
[EMAIL PROTECTED]

RE: Can't resource.adaptTo my AbstractMappedObject

2008-06-18 Thread Craig L. Ching

 

> -Original Message-
> From: Alexander Klimetschek [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, June 18, 2008 12:39 PM
> To: sling-dev@incubator.apache.org
> Subject: Re: Can't resource.adaptTo my AbstractMappedObject
> 
> On Wed, Jun 18, 2008 at 5:07 PM, Craig L. Ching 
> <[EMAIL PROTECTED]> wrote:
> > Is that something new then?  I didn't have to do this before ...
> 
> I think it is quite new. But AFAIK it is an additional 
> feature compared to the standard way of implementing 
> Adaptable in your Resource class. It allows to build 
> "adaptation" outside the affected classes.
> 
Ok, so do I just need to implement Adaptable?  The sample doesn't do
that, but, since you say this is new, I presume the sample just hasn't
been updated.  I can submit a patch when I figure this out completely.

> > I thought that the OCM or SCR or something took care of 
> doing that for 
> > me, at least I assumed that ;-)
> 
> OCM is not involved here. SCR is a generic component / 
> dependency-injection framework in Apache Felix. You always 
> have to configure it, preferrably with the @scr.* javadoc 
> tags that are converted into the actual component xml 
> description files by the maven-scr-plugin. That's how its 
> done throughout Sling. What properties are available and who 
> will be picking up the component or service depends on the 
> service. For the AdaptableFactory it's the 
> AdaptableManagerImpl, that you debugged, which referencs all 
> AdapterFactories that are registered as scr components/services.
> 
Ok, this was all that was necessary before (apparently, it did at least
work):

package org.apache.sling.sample;

import org.apache.sling.jcr.ocm.AbstractMappedObject;

/**
 * The SamplePage is a page level sample content object
 *
 * @ocm.mapped jcrType="sling:SamplePage"
 */
public class SamplePage extends AbstractMappedObject {

/** @ocm.field */
private String title;

public String getTitle() {
return title;
}

public void setTitle(String title) {
this.title = title;
}
}

So to get this to work, should I just need to implement Adaptable?
Thanks for the help!

> Regards,
> Alex
> 
> --
> Alexander Klimetschek
> [EMAIL PROTECTED]
> 
Cheers,
Craig

Re: Can't resource.adaptTo my AbstractMappedObject

2008-06-18 Thread Alexander Klimetschek

Oh, did not notice that you use the sling jcr ocm stuff... No idea,
quite likely the code changed and broke the adaptTo behaviour. Felix,
Carsten?

Regards,
Alex



-- 
Alexander Klimetschek
[EMAIL PROTECTED]

Re: svn commit: r668178 - in /incubator/sling/trunk: jcr/api/src/main/resources/META-INF/ launchpad/app/ launchpad/app/src/main/resources/META-INF/ launchpad/webapp/src/main/webapp/WEB-INF/

2008-06-18 Thread Roy T. Fielding


On Jun 18, 2008, at 1:28 PM, Felix Meschberger wrote:

You mean, just add this text like in
http://svn.apache.org/viewvc?rev=669137&view=rev ?


Yes, that should be sufficient.

Roy

[jira] Created: (SLING-545) Node with primary node type set to nt:unstructured (via json), overridden to nt:folder

2008-06-18 Thread Bryce Ewing (JIRA)

Node with primary node type set to nt:unstructured (via json), overridden to 
nt:folder
--

 Key: SLING-545
 URL: https://issues.apache.org/jira/browse/SLING-545
 Project: Sling
  Issue Type: Bug
  Components: JCR
Affects Versions: JCR Contentloader 2.0.2
 Environment: Ubuntu 8.04, Java 1.6
Reporter: Bryce Ewing
Priority: Minor


As stated in sample_readme.txt (in simple-demo):

Directories
---

Unless a node with the name of the directory already exists or has been defined
in an XML or JSON descriptor file (see below) a directory is created as a node
with the primary node type "nt:folder" in the repository.

I have the following structure in my content folder:
pages.json
pages/home.json

pages.json has:
{
"jcr:primaryType":"nt:unstructured",
"title" : "test"
}

home.json has:
{
"jcr:primaryType":"nt:unstructured"
}

When the bundle is loaded I get the following exception:
19.06.2008 15:54:44.971 *ERROR* [Background Updatenz.co.smx.sling.test (37)] 
org.apache.sling.jcr.contentloader.internal.Loader Cannot load initial content 
for bundle nz.co.smx.sling.test : no definition found in parent node's node 
type for new node: no matching child node definition found for {}home 
javax.jcr.nodetype.ConstraintViolationException: no definition found in parent 
node's node type for new node: no matching child node definition found for 
{}home: no matching child node definition found for {}home
at 
org.apache.jackrabbit.core.NodeImpl.internalAddChildNode(NodeImpl.java:752)
at 
org.apache.jackrabbit.core.NodeImpl.internalAddNode(NodeImpl.java:718)
at 
org.apache.jackrabbit.core.NodeImpl.internalAddNode(NodeImpl.java:665)
at org.apache.jackrabbit.core.NodeImpl.addNode(NodeImpl.java:1987)
at 
org.apache.sling.jcr.contentloader.internal.Loader.createNode(Loader.java:470)
at 
org.apache.sling.jcr.contentloader.internal.Loader.createNode(Loader.java:416)

Having stepped through the loader code in the debugger I found the following:
Loader.java:361 - when pages.json is being processed
if (foundProvider) {
if (createNode(parent, getName(entry), file, overwrite,
versionables, checkin) != null) {
ignoreEntry.add(file);
continue;
}
}
Loader.java:324 - when pages directory is being processed
// if we have a descriptor, which has not been processed yet,
// otherwise call createFolder, which creates an nt:folder or
// returns an existing node (created by a descriptor)
Node node = null;
if (nodeDescriptor != null
&& !ignoreEntry.contains(nodeDescriptor)) {
node = createNode(parent, name, nodeDescriptor, overwrite,
versionables, checkin);
ignoreEntry.add(nodeDescriptor);
} else {
node = createFolder(parent, name, overwrite);
}

>From the first code fragment the pages node has the node type nt:unstructured 
>but this is overridden to nt:folder in the second code fragment, which causes 
>the home.json node to fail.  When stepping through in the debugger in the 
>second code fragment I removed the node descriptor from the ignoreEntry list 
>and the content all loaded correctly, so I might wonder why it is being put in 
>there in the first place (or whether the node from the first code fragment 
>should be used in the second?).

Have created a patch, but for some reason I am not able to compile at the 
moment, get:
org.apache.maven.reactor.MavenExecutionException: Cannot find parent: 
org.apache.sling:sling for project: 
null:org.apache.sling.jcr.contentloader:bundle:2.0.3-incubator-SNAPSHOT for 
project null:org.apache.sling.jcr.contentloader:bundle:2.0.3-incubator-SNAPSHOT

So this patch may not work, also due to only starting looking at Sling a couple 
of days ago I am unsure as to what issues I may not know about in regards to 
what I have changed.

P.S. The project looks great, I am very excited by the possibilities of what 
can be done with this.

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

[jira] Updated: (SLING-545) Node with primary node type set to nt:unstructured (via json), overridden to nt:folder

2008-06-18 Thread Bryce Ewing (JIRA)


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

Bryce Ewing updated SLING-545:
--

Attachment: loader.patch

> Node with primary node type set to nt:unstructured (via json), overridden to 
> nt:folder
> --
>
> Key: SLING-545
> URL: https://issues.apache.org/jira/browse/SLING-545
> Project: Sling
>  Issue Type: Bug
>  Components: JCR
>Affects Versions: JCR Contentloader 2.0.2
> Environment: Ubuntu 8.04, Java 1.6
>Reporter: Bryce Ewing
>Priority: Minor
> Attachments: loader.patch
>
>
> As stated in sample_readme.txt (in simple-demo):
> Directories
> ---
> Unless a node with the name of the directory already exists or has been 
> defined
> in an XML or JSON descriptor file (see below) a directory is created as a node
> with the primary node type "nt:folder" in the repository.
> I have the following structure in my content folder:
> pages.json
> pages/home.json
> pages.json has:
> {
> "jcr:primaryType":"nt:unstructured",
> "title" : "test"
> }
> home.json has:
> {
> "jcr:primaryType":"nt:unstructured"
> }
> When the bundle is loaded I get the following exception:
> 19.06.2008 15:54:44.971 *ERROR* [Background Updatenz.co.smx.sling.test (37)] 
> org.apache.sling.jcr.contentloader.internal.Loader Cannot load initial 
> content for bundle nz.co.smx.sling.test : no definition found in parent 
> node's node type for new node: no matching child node definition found for 
> {}home javax.jcr.nodetype.ConstraintViolationException: no definition found 
> in parent node's node type for new node: no matching child node definition 
> found for {}home: no matching child node definition found for {}home
>   at 
> org.apache.jackrabbit.core.NodeImpl.internalAddChildNode(NodeImpl.java:752)
>   at 
> org.apache.jackrabbit.core.NodeImpl.internalAddNode(NodeImpl.java:718)
>   at 
> org.apache.jackrabbit.core.NodeImpl.internalAddNode(NodeImpl.java:665)
>   at org.apache.jackrabbit.core.NodeImpl.addNode(NodeImpl.java:1987)
>   at 
> org.apache.sling.jcr.contentloader.internal.Loader.createNode(Loader.java:470)
>   at 
> org.apache.sling.jcr.contentloader.internal.Loader.createNode(Loader.java:416)
> Having stepped through the loader code in the debugger I found the following:
> Loader.java:361 - when pages.json is being processed
> if (foundProvider) {
> if (createNode(parent, getName(entry), file, overwrite,
> versionables, checkin) != null) {
> ignoreEntry.add(file);
> continue;
> }
> }
> Loader.java:324 - when pages directory is being processed
> // if we have a descriptor, which has not been processed yet,
> // otherwise call createFolder, which creates an nt:folder or
> // returns an existing node (created by a descriptor)
> Node node = null;
> if (nodeDescriptor != null
> && !ignoreEntry.contains(nodeDescriptor)) {
> node = createNode(parent, name, nodeDescriptor, overwrite,
> versionables, checkin);
> ignoreEntry.add(nodeDescriptor);
> } else {
> node = createFolder(parent, name, overwrite);
> }
> From the first code fragment the pages node has the node type nt:unstructured 
> but this is overridden to nt:folder in the second code fragment, which causes 
> the home.json node to fail.  When stepping through in the debugger in the 
> second code fragment I removed the node descriptor from the ignoreEntry list 
> and the content all loaded correctly, so I might wonder why it is being put 
> in there in the first place (or whether the node from the first code fragment 
> should be used in the second?).
> Have created a patch, but for some reason I am not able to compile at the 
> moment, get:
> org.apache.maven.reactor.MavenExecutionException: Cannot find parent: 
> org.apache.sling:sling for project: 
> null:org.apache.sling.jcr.contentloader:bundle:2.0.3-incubator-SNAPSHOT for 
> project 
> null:org.apache.sling.jcr.contentloader:bundle:2.0.3-incubator-SNAPSHOT
> So this patch may not work, also due to only starting looking at Sling a 
> couple of days ago I am unsure as to what issues I may not know about in 
> regards to what I have changed.
> P.S. The project looks great, I am very excited by the possibilities of what 
> can be done with this.

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

Re: svn commit: r668178 - in /incubator/sling/trunk: jcr/api/src/main/resources/META-INF/ launchpad/app/ launchpad/app/src/main/resources/META-INF/ launchpad/webapp/src/main/webapp/WEB-INF/

2008-06-18 Thread Felix Meschberger

Hi,

Am Donnerstag, den 19.06.2008, 00:02 +0200 schrieb Roy T. Fielding:
> On Jun 18, 2008, at 1:28 PM, Felix Meschberger wrote:
> > You mean, just add this text like in
> > http://svn.apache.org/viewvc?rev=669137&view=rev ?
> 
> Yes, that should be sufficient.

Thanks will update the license files of the launchpad modules
accordingly.

Regards
Felix

Re: More customizable standard GET and POST servlets (was: Json Rendering)

2008-06-18 Thread Felix Meschberger

Hi,

Am Mittwoch, den 18.06.2008, 17:04 +0200 schrieb Bertrand Delacretaz:
> I agree that replacing parts of the behavior of the standard GET and
> POST servlets can be useful, but I'm not sure if this can be fully
> generalized without making things too complex.

Agreed. And we should take extreme care to find out, what exactly we are
trying to do !

> I have two use cases in mind where this would be useful:
> 
> 1) Generating different flavors of JSON output, probably based on selectors

Well, the JsonRendererServlet is fairly simple. If you need your own
rendering, just register a servlet for json rendering (or whatever
selector and/or extension you choose), copy that servlet and adapt it to
suit your needs. Done. No need to worry about OO extensibility and stuff
in this special case IMHO ...

This was really the goal behind _not_ registering the default get
servlet for specific extensions. This allows for user-supplied
better/different renderings for specific extensions.

If we go this way (and for simplicity etc. sake I would suggest to go
this way), we might want to beautify the JsonRendererServlet to make it
easier to hack up.

I think the key part behind this is, that "sling/servlet/default" is
actually an implicit root resource type just as java.lang.Object is the
root class for all Java classes. So registering something for the
"sling/servlet/default" resource type will allow you to register your
own default servlets and scripts. Documentation on this is still pending
(SLING-421 [2]).

> 2) Allowing scripts to reuse part of the POST servlet functionality,
> while customizing part of the POST request processing.

This is already possible to a certain extent: The servlets/post bundle
exports the SlingPostOperation interface and the
AbstractSlingPostOperation abstract class to make the POST servlet
extensible. Using this mechanism -- namely registering a
SlingPostOperation servlet, see the interface java doc for more info --
it is possible to extend the SlingPostServlet easily.

This is documented at [1].

If this does not suit your needs, we welcome any new use cases which we
will certainly seek to support.

Regards
Felix

[1]
http://incubator.apache.org/sling/site/manipulating-content-the-slingpostservlet.html
[2] https://issues.apache.org/jira/browse/SLING-421

> 
> I think 1) is fairly easy to solve by making the JsonRendererServlet
> more expandable, maybe simply factoring out the instantiation of the
> JsonItemWriter so that people can provide custom variants, by
> registering servlets that extend JsonRendererServlet. I think this
> "standard rendering customization" only makes sense for the JSON
> format currently, so no need for a generalized framework.
> 
> Solving 2) looks like a different problem, where the SlingPostServlet
> functionality might need to be broken down in smaller services and
> components that scripts can reuse in a modular way.
> 
> I don't see other use cases for customizing our standard servlets at
> the moment, so I feel the above two cases can be handled "locally"
> without creating a generalized (and possibly complex) customization
> framework.
> 
> -Bertrand

RE: Can't resource.adaptTo my AbstractMappedObject

2008-06-18 Thread Felix Meschberger

Hi Craig,

Sorry, that I did not follow up to this yesterday -- I just did not find
any time 

Anyway, your are right, the OCM functionality should register the
AdapterFactories based on the registered mappings for the scripts to use
them. It is an error of the simple-sample project or the OCM project
that this does not take place. I will have to look into this.

Regards
Felix


Am Mittwoch, den 18.06.2008, 09:11 -0500 schrieb Craig L. Ching:
> Anybody have any ideas on how I get my class into this factory?  Just
> some general pointers would help, e.g. how am I supposed to get my SCR
> registered class into this factory so that I can adapt to it? 
> 
> > -Original Message-
> > From: Craig L. Ching [mailto:[EMAIL PROTECTED] 
> > Sent: Tuesday, June 17, 2008 3:18 PM
> > To: sling-dev@incubator.apache.org
> > Subject: Can't resource.adaptTo my AbstractMappedObject
> > 
> > Hi all,
> > 
> > Just updated to trunk and I'm seeing the following problem.  
> > If I deploy the sling/samples/simple-demo bundle, I get the 
> > following error:
> > 
> > org.apache.sling.scripting.jsp.jasper.JasperException: An 
> > exception occurred processing JSP page 
> > /apps/sling/SamplePage/html.jsp at line 34 null Stacktrace: (500)
> > 
> > The requested URL /sample/content/home.html resulted in an 
> > error in /apps/sling/SamplePage/html.jsp.
> > Exception:
> > 
> > org.apache.sling.api.SlingServletException:
> > org.apache.sling.scripting.jsp.jasper.JasperException: An 
> > exception occurred processing JSP page 
> > /apps/sling/SamplePage/html.jsp at line 34
> > 
> > null
> > 
> > Stacktrace:
> > at
> > org.apache.sling.scripting.jsp.JspServletWrapperAdapter.servic
> > e(JspServl
> > etWrapperAdapter.java:66)
> > at
> > org.apache.sling.scripting.jsp.JspScriptEngineFactory.callJsp(
> > JspScriptE
> > ngineFactory.java:134)
> > at
> > org.apache.sling.scripting.jsp.JspScriptEngineFactory.access$0
> > 00(JspScri
> > ptEngineFactory.java:72)
> > at
> > org.apache.sling.scripting.jsp.JspScriptEngineFactory$JspScrip
> > tEngine.ev
> > al(JspScriptEngineFactory.java:281)
> > at
> > org.apache.sling.scripting.core.impl.DefaultSlingScript.call(D
> > efaultSlin
> > gScript.java:135)
> > at
> > org.apache.sling.scripting.core.impl.DefaultSlingScript.eval(D
> > efaultSlin
> > gScript.java:106)
> > at
> > org.apache.sling.scripting.core.impl.DefaultSlingScript.servic
> > e(DefaultS
> > lingScript.java:219)
> > at
> > org.apache.sling.engine.impl.request.RequestData.service(Reque
> > stData.jav
> > a:462)
> > at
> > org.apache.sling.engine.impl.SlingMainServlet.processRequest(S
> > lingMainSe
> > rvlet.java:419)
> > at
> > org.apache.sling.engine.impl.filter.RequestSlingFilterChain.re
> > nder(Reque
> > stSlingFilterChain.java:48)
> > at
> > org.apache.sling.engine.impl.filter.AbstractSlingFilterChain.d
> > oFilter(Ab
> > stractSlingFilterChain.java:54)
> > at
> > org.apache.sling.engine.impl.debug.RequestProgressTrackerLogFi
> > lter.doFil
> > ter(RequestProgressTrackerLogFilter.java:59)
> > at
> > org.apache.sling.engine.impl.filter.AbstractSlingFilterChain.d
> > oFilter(Ab
> > stractSlingFilterChain.java:52)
> > at
> > org.apache.sling.engine.impl.SlingMainServlet.service(SlingMai
> > nServlet.j
> > ava:273)
> > at
> > org.apache.sling.engine.impl.SlingMainServlet.service(SlingMai
> > nServlet.j
> > ava:171)
> > at
> > org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487)
> > at
> > org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler
> > .java:362)
> > at
> > org.ops4j.pax.web.service.internal.HttpServiceServletHandler.h
> > andle(Http
> > ServiceServletHandler.java:51)
> > at
> > org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler
> > .java:181)
> > at
> > org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler
> > .java:722)
> > at
> > org.ops4j.pax.web.service.internal.HttpServiceContext.handle(H
> > ttpService
> > Context.java:87)
> > at
> > org.ops4j.pax.web.service.internal.JettyServerHandlerCollectio
> > n.handle(J
> > ettyServerHandlerCollection.java:63)
> > at
> > org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper
> > .java:139)
> > at org.mortbay.jetty.Server.handle(Server.java:324)
> > at
> > org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.
> > java:505)
> > at
> > org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete
> > (HttpConne
> > ction.java:828)
> > at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:514)
> > at
> > org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211)
> > at
> > org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380)
> > at
> > org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketCon
> > nector.jav
> > a:228)
> > at
> > org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThr
> > eadPool.ja
> > va:450)
> > Caused by: 
> > org.apache.sling.scriptin

Re: Can't resource.adaptTo my AbstractMappedObject

2008-06-18 Thread Felix Meschberger

Hi Alex,

Am Mittwoch, den 18.06.2008, 17:01 +0200 schrieb Alexander Klimetschek:
> On Wed, Jun 18, 2008 at 4:11 PM, Craig L. Ching <[EMAIL PROTECTED]> wrote:
> >> Looking into it further, I don't seem to have a factory for
> >> my class, according to this code in AdapterManagerImpl.java:
> >>
> >> // get the factory for the target type
> >> AdapterFactory factory = factories.get(type.getName());
> 
> I think implementing an AdapterFactory and providing scr properties
> "adaptables" and "adapters" should do the trick. Have a look at the
> javadocs:
> 
> http://svn.apache.org/repos/asf/incubator/sling/trunk/api/src/main/java/org/apache/sling/api/adapter/AdapterFactory.java

Your are partly right of course. But in the case of OCM, it is the
jcr/ocm module, which takes care for registering the correct adapter
factories based on the mapping descriptors. If  this does not take place
(anymore), I consider this a bug.

I will have to look into this.

Regards
Felix

55 matches

Mail list logo