Karaf features in Launchpad

[Vidar Ramdal]

I'm assembling a Sling Launchpad application, and I'm experiencing
that the Launchpad bundle list is becoming long and difficult to
manage.

For example, adding Hibernate support requires adding a considerable
number of bundles, to different start levels. Adding other stuff
requires adding more bundles, to the same or different start levels.

In Apache Karaf, this problem has been solved with features [1].

It would be useful if the Launchpad bundle list could support Karaf
feature descriptors, preferably also supporting Karaf's URL handlers
(particularly wrap:).

Would there be interest in extending the Launchpad bundle list format
to support something like Karaf features? If so, I'll create I Jira
and try to find time to work in it.

Or does the Launchpad already support something similar?

Just to clarify: This is not about running Sling in a Karaf runtime,
but rather, using Karaf features with the Sling Launchpad.

[1] http://karaf.apache.org/manual/latest-2.3.x/users-guide/provisioning.html
-- 
Vidar S. Ramdal 
Webstep AS - http://www.webstep.no
Besøksadresse: Lilleakerveien 8, 0283 Oslo
Postadresse: Postboks 272 Lilleaker, 0216 Oslo

SLING-2530 (CRUD) Persisting changes

[Vidar Ramdal]

>From https://cwiki.apache.org/confluence/display/SLING/Supporting+CRUD :
"Changes are not persisted immediately but stored transient. When all
changes are done, a save/commit calls needs to be done trying to
persist all changes to all resource providers."

Let's say a changeset involves several resource providers, which in
turn are called to save the changes, and the second resoure providers
fails.
What will happen to the changes already saved by the first resource
provider? Should these be rolled back?

-- 
Vidar S. Ramdal 
Webstep AS - http://www.webstep.no
Besøksadresse: Lilleakerveien 8, 0283 Oslo
Postadresse: Postboks 272 Lilleaker, 0216 Oslo

Re: [VOTE] Moving SLING-2396 to trunk

[Vidar Ramdal]

2012/6/10 Carsten Ziegeler :
> I really would like to move forward with SLING-2396 (Make
> ResourceResolverFactory independent from JCR) in order to implement
> other features (like CRUD support for the resource resolver) on top of
> this.
>
> Unfortunately this change introduces an incompatibility wrt
> workspaces, therefore I thought it's safer to call a vote and see what
> the community things about it.
> The vote is not about implementing SLING-2396 in exactly the way it is
> right now, its just to move the code to trunk and continue to work
> there.
>
> For the workspace support, right now, it's possible to address other
> workspaces by specifying an artificial path {workspacename}:{/path} .
> This won't be possible anymore, however it would be possible to mount
> a workspace at any path in the resource tree (and that would happen on
> demand).
>
> I think, if someone really needs the special path access to a
> workspace like it is today, then we could add a wrapper for the
> resource resolver which does this special logic in the wrapper.
> However, if we don't need it, i don't want to spent time on that :)
>
> I think SLING-2396 is one of the most important changes to our code
> base, which will make it easier to implement new features in the
> resource resolving area, e.g. we get adding different search providers
> for free etc.
>
> Please vote, thanks :)

+1

This is so cool in a million ways!


-- 
Vidar S. Ramdal 
Webstep AS - http://www.webstep.no
Besøksadresse: Lilleakerveien 8, 0283 Oslo
Postadresse: Postboks 272 Lilleaker, 0216 Oslo

Re: The beast that is JcrResourceResolverFactoryImpl

[Vidar Ramdal]

2012/2/2 Vidar Ramdal :
>>>>> I think some time ago Felix was working on a prototype for this. Not
>>>>> sure what the status is.
>>>>>
>>>>> But that's definitely something we should do in Sling rather sooner than 
>>>>> later.
>>>>
>>>> I'd be interested in seeing this come to Sling, and could start do to
>>>> some work on it - at least slowly, piece by piece.
>
>> Am 02.02.2012 um 09:02 schrieb Carsten Ziegeler:
>>> Great!
>>>
>>>> If we could find any references to Felix' prototype, I could start from 
>>>> there.
>>>
>>> Yes :) Or we can start from scratch - I think as a first step we could
>>> copy the jcr resource bundle to the whiteboard and start from there.
>
> 2012/2/2 Felix Meschberger :
>> Unfortunately I don't have anything code-wise. I once started to separate 
>> the ResourceResolverFactory and ResourceResolver part from the JCR part but 
>> I didn't come very far (and I fear I lost my work)...
>>
>> The basic idea, really is to split the JCR Resource bundle in a 
>> ResourceResolverFactory bundle and a JCR Resource Provider bundle (also 
>> providing the JCR Event to OSGi Event bridge)
>>
>> The Domain Mapping functionality would be part of the 
>> ResourceResolverFactory bundle but would probably have a new exposed service 
>> API to plug into it. Such that for example Vanity URL functionality could in 
>> fact be factored out into another bundle.
>
> Sounds good. Maybe we also get to solve SLING-2076 [1] as a side-effect :)
>
>>
>> And yes, this would definitely be something I would be interested in.
>>
>> Could this work be started in a whiteboard location ?
>
> I created 
> https://svn.apache.org/repos/asf/sling/whiteboard/resourceresolverfactory
> for this - will start by copying in the current jcr/resource bundle.
>
> Unfortunately I don't get to do any Sling work in my current job, so
> don't expect any rapid progress on my part. Anyone interested, please
> join :)

Created https://issues.apache.org/jira/browse/SLING-2396 to track this.

-- 
Vidar S. Ramdal 
Webstep AS - http://www.webstep.no
Besøksadresse: Lilleakerveien 8, 0283 Oslo
Postadresse: Postboks 272 Lilleaker, 0216 Oslo

Re: The beast that is JcrResourceResolverFactoryImpl

[Vidar Ramdal]

 I think some time ago Felix was working on a prototype for this. Not
 sure what the status is.

 But that's definitely something we should do in Sling rather sooner than 
 later.
>>>
>>> I'd be interested in seeing this come to Sling, and could start do to
>>> some work on it - at least slowly, piece by piece.

> Am 02.02.2012 um 09:02 schrieb Carsten Ziegeler:
>> Great!
>>
>>> If we could find any references to Felix' prototype, I could start from 
>>> there.
>>
>> Yes :) Or we can start from scratch - I think as a first step we could
>> copy the jcr resource bundle to the whiteboard and start from there.

2012/2/2 Felix Meschberger :
> Unfortunately I don't have anything code-wise. I once started to separate the 
> ResourceResolverFactory and ResourceResolver part from the JCR part but I 
> didn't come very far (and I fear I lost my work)...
>
> The basic idea, really is to split the JCR Resource bundle in a 
> ResourceResolverFactory bundle and a JCR Resource Provider bundle (also 
> providing the JCR Event to OSGi Event bridge)
>
> The Domain Mapping functionality would be part of the ResourceResolverFactory 
> bundle but would probably have a new exposed service API to plug into it. 
> Such that for example Vanity URL functionality could in fact be factored out 
> into another bundle.

Sounds good. Maybe we also get to solve SLING-2076 [1] as a side-effect :)

>
> And yes, this would definitely be something I would be interested in.
>
> Could this work be started in a whiteboard location ?

I created 
https://svn.apache.org/repos/asf/sling/whiteboard/resourceresolverfactory
for this - will start by copying in the current jcr/resource bundle.

Unfortunately I don't get to do any Sling work in my current job, so
don't expect any rapid progress on my part. Anyone interested, please
join :)

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

-- 
Vidar S. Ramdal 
Webstep AS - http://www.webstep.no
Besøksadresse: Lilleakerveien 8, 0283 Oslo
Postadresse: Postboks 272 Lilleaker, 0216 Oslo

Re: The beast that is JcrResourceResolverFactoryImpl

[Vidar Ramdal]

> 2012/2/1 Vidar Ramdal :
>> I am experimenting with using Sling in a non-JCR application, that is,
>> I want to leverage Sling's templating support, OSGi goodies, resource
>> resolution etc, without using JCR, but in this case, a regular
>> relational database. I have created a ResourceProvider which turns DB
>> data into resources, so far so good.
>>
>> But I'd like to avoid any JCR dependency whatsoever. The changes
>> outlined in [1] did a lot to allow custom ResourceResolverFactories.
>> Still, much basic functionality happens in
>> JcrResourceResolverFactoryImpl that makes it hard to avoid, without
>> reimplementing:
>> .
>> - Domain mappings (o.a.s.jcr.resource.internal.helper.MapEntries,
>> MapEntry, Mapping) (JCR independant since SLING-1463 [2])
>> - Redirect resouces (o.a.s.jcr.resource.internal.helper.RedirectResource)
>> - Resource iterator (o.a.s.jcr.resource.internal.helper.ResourceIterator)
>> - Star Resource 
>> (o.a.s.jcr.resource.internal.helper.starresource.StarResource)
>> - Resource provider resolution logic
>> (o.a.s.jcr.resource.internal.helper.ResourceProviderEntry)
>> - (maybe others)
>>
>> In fact, none of the classes listed above imports any packages from 
>> javax.jcr.
>>
>> So, if we accept that a non-JCR ResourceResolverFactory would have to
>> implement these features, shouldn't they be available somewhere
>> outside JcrResourceResolverFactoryImpl?
>>
>> I'm not sure what is the best approach - an
>> AbstractResourceResolverFactory, or turning these features into
>> separate components.
>> Any thoughts?
>>
>>
>> [1] 
>> https://cwiki.apache.org/SLING/add-resourceresolverfactory-service-interface.html
>> [2] https://issues.apache.org/jira/browse/SLING-1463

2012/2/1 Carsten Ziegeler :

> yes, this is an unfinished area - the ResourceResolverFactory should
> have no ties to JCR and just use ResourceProvider services.

Great, that's what I thought.

> So the basic idea is to create a new module for the implementation of the
> ResourceResolverFactory which has all the functionality that is not
> deferred to resource providers.

By "all the functionality that is not deferred to resource providers",
do you mean for instance those bullets I posted above (domain mappings
etc)?

> I think some time ago Felix was working on a prototype for this. Not
> sure what the status is.
>
> But that's definitely something we should do in Sling rather sooner than 
> later.

I'd be interested in seeing this come to Sling, and could start do to
some work on it - at least slowly, piece by piece. If we could find
any references to Felix' prototype, I could start from there.

-- 
Vidar S. Ramdal 
Webstep AS - http://www.webstep.no
Besøksadresse: Lilleakerveien 8, 0283 Oslo
Postadresse: Postboks 272 Lilleaker, 0216 Oslo

The beast that is JcrResourceResolverFactoryImpl

[Vidar Ramdal]

I am experimenting with using Sling in a non-JCR application, that is,
I want to leverage Sling's templating support, OSGi goodies, resource
resolution etc, without using JCR, but in this case, a regular
relational database. I have created a ResourceProvider which turns DB
data into resources, so far so good.

But I'd like to avoid any JCR dependency whatsoever. The changes
outlined in [1] did a lot to allow custom ResourceResolverFactories.
Still, much basic functionality happens in
JcrResourceResolverFactoryImpl that makes it hard to avoid, without
reimplementing:
.
- Domain mappings (o.a.s.jcr.resource.internal.helper.MapEntries,
MapEntry, Mapping) (JCR independant since SLING-1463 [2])
- Redirect resouces (o.a.s.jcr.resource.internal.helper.RedirectResource)
- Resource iterator (o.a.s.jcr.resource.internal.helper.ResourceIterator)
- Star Resource (o.a.s.jcr.resource.internal.helper.starresource.StarResource)
- Resource provider resolution logic
(o.a.s.jcr.resource.internal.helper.ResourceProviderEntry)
- (maybe others)

In fact, none of the classes listed above imports any packages from javax.jcr.

So, if we accept that a non-JCR ResourceResolverFactory would have to
implement these features, shouldn't they be available somewhere
outside JcrResourceResolverFactoryImpl?

I'm not sure what is the best approach - an
AbstractResourceResolverFactory, or turning these features into
separate components.
Any thoughts?


[1] 
https://cwiki.apache.org/SLING/add-resourceresolverfactory-service-interface.html
[2] https://issues.apache.org/jira/browse/SLING-1463

-- 
Vidar S. Ramdal 
Webstep AS - http://www.webstep.no
Besøksadresse: Lilleakerveien 8, 0283 Oslo
Postadresse: Postboks 272 Lilleaker, 0216 Oslo

Re: Providers for non-JCR data storage? (was: [RT] Improving access control)

[Vidar Ramdal]

2011/11/23 Alexander Klimetschek :
> On 23.11.11 12:57, "Vidar Ramdal"  wrote:
>>2011/11/23 Tobias Bocanegra :
>>> I would rather put effort in creating connectors in jackrabbit. So
>>> having a LDAP, noSQL, etc. mapped into JCR brings much more value and
>>> having them on the resource level.
>>
>>Out of curiosity, for what reasons?
>
> Because all the infrastructure level things like ACLs (as in this
> discussion) won't have to be reinvented. The Sling resource API would
> evolve and become more complicated - and loose it's original purpose of a
> simple read oriented API, simpler than JCR in comparison. But not a
> standard.

Well, but you would be locked in with Jackrabbit, right? So it's not
really plugging in to JCR, but Jackrabbit, if I understand correctly.


-- 
Vidar S. Ramdal 
Webstep AS - http://www.webstep.no
Besøksadresse: Lilleakerveien 8, 0283 Oslo
Postadresse: Postboks 272 Lilleaker, 0216 Oslo

Re: Providers for non-JCR data storage? (was: [RT] Improving access control)

[Vidar Ramdal]

> On Wed, Nov 23, 2011 at 11:10 AM, Vidar Ramdal  
> wrote:
>> 2011/11/23 Carsten Ziegeler :
>>> I know that some people have developed such things but don't want to
>>> contribute them (which is totally fine). I'm planning to work on such
>>> providers in the near future. If others are interested to use their
>>> favorite data storage with Sling, I'm happy to apply contributions or
>>> discuss the best way to integrate them :)

2011/11/23 Tobias Bocanegra :
> I would rather put effort in creating connectors in jackrabbit. So
> having a LDAP, noSQL, etc. mapped into JCR brings much more value and
> having them on the resource level.

Out of curiosity, for what reasons?


-- 
Vidar S. Ramdal 
Webstep AS - http://www.webstep.no
Besøksadresse: Lilleakerveien 8, 0283 Oslo
Postadresse: Postboks 272 Lilleaker, 0216 Oslo

Re: Providers for non-JCR data storage? (was: [RT] Improving access control)

[Vidar Ramdal]

2011/11/23 Carsten Ziegeler :
> I know that some people have developed such things but don't want to
> contribute them (which is totally fine). I'm planning to work on such
> providers in the near future. If others are interested to use their
> favorite data storage with Sling, I'm happy to apply contributions or
> discuss the best way to integrate them :)

Some time ago I commited a LDAP resource provider to my whiteboard:
http://sling.markmail.org/thread/v5nortsbwm3vwlur
It might need some brushing up, but if there's interest, it could be
made into a nice example of integrating other data stores into Sling.

-- 
Vidar S. Ramdal 
Webstep AS - http://www.webstep.no
Besøksadresse: Lilleakerveien 8, 0283 Oslo
Postadresse: Postboks 272 Lilleaker, 0216 Oslo

Re: [RT] Improving access control

[Vidar Ramdal]

2011/11/23 Mike Müller :
> I think the discussion here is missunderstood. It's neither about
> to redefine existing ACLs nor about reinventing something already
> existing. It's just about introducing hooks or entrypoint to let
> developers define some other access controlling rules if needed.
> Sling will NOT have to deal with permissions or policies, users and so
> on. That's all up to the developer which want's to use the hooks.
> So if you're are fine with the ACLs from JCR, you don't have to
> change anything, if you are not, this would give you the chance
> to solve your problem (like my example to give access to a
> resource from 8.00 to 17.00).
> So
> It would help not only for special rules like the one above, it would
> also help to handle access controlling on resources which are provided
> from another resource provider than JCR, like the file system provider,
> where no access controlling can be attached today.

Being picky here: We could provide access control by extending the
file system provider to support it. And your example of
time-restricted access could be implemented in Jackrabbit's existing
AccessManager.

I'm worried we're introducing a layer of resource filtering that will
be hard to enforce across all scenarios, without breaking useability.
I've been thinking more about the search issue. Jackrabbit's Lucene
will report, say 200 results for a query. But Lucene does only know of
Jackrabbit's access rules, not the Sling ones. So out of those 200
results, the user may only have access to 100 of them, or perhaps none
at all. How are we going to report the number of search results to the
end user, without iterating all search results while filtering them
through Sling access control?

The same, I guess, will affect for search features of other resource providers.

OK, maybe the search result size problem is a small one, but I suspect
there are other such cases (that I haven't been able to think about
yet).

-- 
Vidar S. Ramdal 
Webstep AS - http://www.webstep.no
Besøksadresse: Lilleakerveien 8, 0283 Oslo
Postadresse: Postboks 272 Lilleaker, 0216 Oslo

Re: [RT] Improving access control

[Vidar Ramdal]

2011/11/22 Carsten Ziegeler :
> This idea is about to provide a general approach for resource
> checking. Noone prevents you from doing a virtual tree in the jcr
> repository to check access of resources provided by other providers.
> But that's an implementation detail which I don't want to require
> upfront!

I'm coming late to this party, but having read the thread I'm not sure
if the proposal is about a) specifying access control APIs to be
implemented by resource providers, or b) implement access control
logic independently from (on top of) resource providers.
Can someone clarify?

With b), it would be easy to re-use access control logic across
resource providers (like the 9:00-17:00 rule), but I suspect it will
introduce other problems, such as with Jackrabbit's Lucene search
results - you don't want to return a search result that the user don't
have access to.

With a), we simply delegate all access control to resource providers
(like JCR), which will pretend a resource does not exist if the user
has no access to it. But then, what will be the point of having Sling
APIs for access control? In other words, why does Sling need to know
that a resource exists, when it is unaccessible for the user?

-- 
Vidar S. Ramdal 
Webstep AS - http://www.webstep.no
Besøksadresse: Lilleakerveien 8, 0283 Oslo
Postadresse: Postboks 272 Lilleaker, 0216 Oslo

Re: [RT] Improving access control

[Vidar Ramdal]

2011/11/22 Bertrand Delacretaz :
> On Tue, Nov 22, 2011 at 1:45 PM, Alexander Klimetschek
>  wrote:
>> ...Personally I think it is much better to put such additional ACL
>> implementations into the JCR (e.g. a custom Jackrabbit access control
>> provider). The problem is that anytime your code is using JCR (such as for
>> complex operations not possible through the simple resource API) your
>> sling-based access control won't be used at all
>
> Right...adding an ACL layer that's not based on JCR might generate a
> lot of confusion IMO.
> [...]
> To keep things simple I'd suggest using a "shadow resource tree" in
> JCR if we need to define access control for ResourceResolvers which
> are not JCR: have the /SLING-ACL/resolvers/com.example.bar/foo
> repository node define ACL for resource /foo provided by provider
> com.example.bar, for example.

Hmm, so you are thinking about delegating access control for all kind
of resources to JCR? Wouldn't that just duplicate resource trees from
(all) other resource providers into JCR, just for the sake of access
control?


-- 
Vidar S. Ramdal 
Webstep AS - http://www.webstep.no
Besøksadresse: Lilleakerveien 8, 0283 Oslo
Postadresse: Postboks 272 Lilleaker, 0216 Oslo

Re: [VOTE] Abandon Maven 2.x support in maven-launchpad-plugin

[Vidar Ramdal]

2011/11/10 Justin Edelson :
> All-
> In order to handle SLING-2273, I need to update the various
> dependencies from the maven-launchpad-plugin from Maven 2 to Maven 3.
> As this is a backwards-incompatible change, I think it is worth voting
> on. Logically, the next version of the launchpad plugin will be 3.0,
> but we can cross that bridge when we get to it.
>
> Please vote to approve this change:
>
>  [ ] +1 Approve the change, depend upon Maven 3 libraries
>  [ ]  0 Don't care
>  [ ] -1 Keep dependency on Maven 2 ...
>
> This vote will be open for 72 hours.

+1

-- 
Vidar S. Ramdal 
Webstep AS - http://www.webstep.no
Besøksadresse: Lilleakerveien 8, 0283 Oslo
Postadresse: Postboks 272 Lilleaker, 0216 Oslo

Re: Removing the query servlet

[Vidar Ramdal]

> 2011/9/19 Felix Meschberger :
>> How about:
>>
>>  * Creating a separate bundle taking this servlet
> Yeah, that's an option - though if noone needs it, we could as well remove it 
> :)
>
>>  * Use the request's resource path as a final filter when dumping the
>> result ?

2011/9/19 Carsten Ziegeler :
> Sure, that's possible but again if noone is using this anyway, way
> spending time in this one :)

Well, I do know that my former employer Idium is using it.
But then, anyone is free to take the existing code and package it in a
self-made bundle, I guess.

-- 
Vidar S. Ramdal 
Webstep AS - http://www.webstep.no
Besøksadresse: Lilleakerveien 8, 0283 Oslo
Postadresse: Postboks 272 Lilleaker, 0216 Oslo

Re: SLING-2191 - multiple OptingServlets with same registration parameters don't work

[Vidar Ramdal]

2011/8/22 Bertrand Delacretaz :
> Hi,
>
> I've been looking at SLING-2191 - it looks like if several
> OptingServlets have the exact same registration parameters, only one
> is actually used.
>
> In Reto's example there we have two servlets registered with
>
>    @Property(name="sling.servlet.resourceTypes", value={
>            "sling/servlet/default",
>            "sling/nonexisting"
>    }),
>    @Property(name="sling.servlet.methods", value={"POST","GET"})
>
> which differ only in the results of their OptingServlet.accepts method.
>
> This causes their ServletResourceProviders to have the same provider
> roots, am I correct to assume that this is what causes one of the
> servlets to mask the other?

Probably. But isn't this how other Sling servlets work - that if more
than one servlet is registered on the same path (/apps/...) only one
is invoked?

One workaround is to register a delegating OptingServlet, which holds
references to a set of other servlets, and invokes them in turn.

> If I'm correct, we might need to use a single ServletResourceProvider
> in such a case, and allow it to point to a set of OptingServlet.



-- 
Vidar S. Ramdal 
Webstep AS - http://www.webstep.no
Besøksadresse: Lilleakerveien 8, 0283 Oslo
Postadresse: Postboks 272 Lilleaker, 0216 Oslo

Re: LDAP Resource Provider

[Vidar Ramdal]

> 2011/8/12 Felix Meschberger :
>> This would probably benefit from the ResourceProviderFactory approach
>> which are called to create the ResourceProvider using the provided user
>> credentials ...

2011/8/12 Vidar Ramdal :
> You mean binding to the LDAP server with credentials supplied by the
> request? Interesting. I'll have a go at implementing it, and update
> you when I have something.

Hmm, looking for a ResourceProviderFactory interface to implement, but
can't find one. From the mailing list I found your proposal from 2008
[1].
Was this ever added to the Sling codebase?

[1] 
https://cwiki.apache.org/SLING/add-resourceresolverfactory-service-interface.html#AddResourceResolverFactoryServiceInterface-5ResourceProviderFactory

-- 
Vidar S. Ramdal 
Webstep AS - http://www.webstep.no
Besøksadresse: Lilleakerveien 8, 0283 Oslo
Postadresse: Postboks 272 Lilleaker, 0216 Oslo

Re: LDAP Resource Provider

[Vidar Ramdal]

2011/8/12 Felix Meschberger :
> Technically +1
>
> Looks interesting. I would assume the LDAP bind is currently anonymous ?

Well, no. The bind DN/password is configured per LdapResourceProvider instance.

> This would probably benefit from the ResourceProviderFactory approach
> which are called to create the ResourceProvider using the provided user
> credentials ...

You mean binding to the LDAP server with credentials supplied by the
request? Interesting. I'll have a go at implementing it, and update
you when I have something.

> What frightens me a bit is the list of embedded dependencies. I always
> thought the L in LDAP stands for light-weight ;-)

You're right, half of them were unnecessary. I have cleaned up a bit.

> Nit-picking on the code: I think the LdapResource should not copy all
> methods from the Resource interface.

Right. Cleaned that up.


-- 
Vidar S. Ramdal 
Webstep AS - http://www.webstep.no
Besøksadresse: Lilleakerveien 8, 0283 Oslo
Postadresse: Postboks 272 Lilleaker, 0216 Oslo

Re: [VOTE] New Module Releases

[Vidar Ramdal]

2011/8/10 Carsten Ziegeler :
> Hi,
>
> I think it's time for some releases - some of them are long overdue
> while others fix serious bugs.
>
> This vote is about
>
> Apache Sling API 2.2.2
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310710&version=12315961
>
> Apache Sling Commons OSGi 2.1.0
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310710&version=12314974
>
> Apache Sling Commons Scheduler 2.3.0
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310710&version=12314478
>
> Apache Sling Scripting Core 2.0.18
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310710&version=12316110
>
> Apache Sling Installer Core 3.2.2
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310710&version=12317043
>
> Apache Sling Installer Configuration Factory 1.0.2
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310710&version=12317150
>
> Apache Sling File Installer 1.0.2
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310710&version=12317043
>
> Apache Sling Launchpad Installer 1.0.4
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310710&version=12317045
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-014/
>
> You can use this UNIX script to download the release and verify the 
> signatures:
> http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh
>
> Usage:
> sh check_staged_release.sh 014 /tmp/sling-staging
>
> Please vote to approve this release:

+1

-- 
Vidar S. Ramdal 
Webstep AS - http://www.webstep.no
Besøksadresse: Lilleakerveien 8, 0283 Oslo
Postadresse: Postboks 272 Lilleaker, 0216 Oslo

LDAP Resource Provider

[Vidar Ramdal]

Hi, I have been working on an LDAP web client, and found that it could
be a nice thing if Sling supported LDAP directories.

So I wrote up a rudimentary LDAP resource provider, which basically
serves up an LDAP directory as a Sling resource tree.

The first objectClass value of an LDAP entry is used as
sling:resourceType, so that a GUI can be supplied by putting scripts
in /apps/ldap/organizationalPerson, /apps/ldap/organizationalUnit and
so on.
The entry's attributes are available by adapting the LdapResource to ValueMap.

I have committed the code to my whiteboard directory:
http://svn.apache.org/viewvc/sling/whiteboard/vramdal/ldapresource/

Would this be something that should be added to sling/samples?

-- 
Vidar S. Ramdal 
Webstep AS - http://www.webstep.no
Besøksadresse: Lilleakerveien 8, 0283 Oslo
Postadresse: Postboks 272 Lilleaker, 0216 Oslo

Re: Sling Authentication

[Vidar Ramdal]

2011/6/10 David G. :
> Vidar,
>
> Hrm - i think i misspoke.
>
> I am trying to figure out the mechanics of
> Authentication/De-Authentication (Sign-In/Sign-Out) for web apps using
> Sling.
>
> Essentially I want to create two entry points, one that Authenticates
> the user to my web app (sign-in) and one that de-authenticates the
> user (sign-out).
>
> For sign-in i am using a custom Authentication Handler, which through
> the extractCredentials method, creates/retrieves a JCR user and
> creates an AuthenticationInfo object for said user - and returns it.
>
> I was under the impression this was enough to "authenticate" the user
> and allow a session cookie to be created, etc. (basically treat the
> user as logged in).
>
> For some reason, even when I pass back a "valid" AutheticationInfo
> object (and by valid, i mean it represents the user) from the
> AuthenticationHandler's extractcredentials my user is not recognized
> as being "signed in" by Sling (ProfileUtil.isAnonymous(slingReqest) ==
> true).
>
> Im trying to figure out what the mechanics are for having Sling/JCR
> persist recognition of my user as signed in accross the life of their
> visit to the web site.
>
> Also, I am tyring to undetstand how to create a logout mechanism that
> operates in a similar fashion.

OK, I haven't worked with the latest versions of the Auth stuff, but
I'm pretty sure you must set and parse the cookie yourself (in your
authentication handler). By default, Sling does not use sessions, so
you must pass the credentials on every request.
One way of doing it could be:
1. The user logs in through a specially designated servlet (see
o.a.s.auth.core.impl.LoginServlet for an example). The servlet sets a
cookie containing the user's credentials (or a session ID, if you want
to implement that)
2. On succeeding requests, your AuthenticationHandler looks for the
cookie, parses it and returns the AuthenticationInfo object
3. On logout, another servlet is used, which deletes the cookie

Again, I'm not totally familiar with the current state of Sling
authentication, so anybody please correct and fill in the missing
stuff.


-- 
Vidar S. Ramdal 
Webstep AS - http://www.webstep.no
Besøksadresse: Lilleakerveien 8, 0283 Oslo
Postadresse: Postboks 66, 1324 Lysaker

Re: Sling Authentication

[Vidar Ramdal]

2011/6/9 David G. :
> I am writing a custom Sling Authentication Handler and am having
> trouble understanding where the actual "authentication" to sling takes
> place.
>
> Currently my Authentication Handler validates credentials against a
> third party system, creates a user in JCR as necessary, gets an
> AuthenticationInfo object based on that user ,and returns that
> AuthenticationInfo object.
>
> I was under the impression that returning  a non-null
> AuthenticationInfo object was enough for sling to authenticate the
> user, however this does not appear to be the case (unless I my
> Authentication Info obj isnt properly formed i suppose).
>
> Should all I have to do is return an AuthenticationInfo obj from
> extractCredentials in my Custom Authenication Handler to authenticate
> the user to Sling? Or is there something else I have to do?
> If not, is there anything special in how the AuthenticationInfo is created?

There is basically no such thing as "authentication to Sling" - the
authentication is done to the underlying JCR. I'm not sure what you
mean with "actual authentication", but in JCR terms it is the
LoginModule who do that work.
Also, make sure your AuthenticationHandler is actually called.


-- 
Vidar S. Ramdal 
Webstep AS - http://www.webstep.no
Besøksadresse: Lilleakerveien 8, 0283 Oslo
Postadresse: Postboks 66, 1324 Lysaker

Separating MapEntries from JcrResourceResolver

[Vidar Ramdal]

The o.a.s.jcr.resource.internal.JcrResourceResolverFactoryImpl relies
on a set of MapEntries to map URLs to paths. The current
implementation of MapEntries reads the mapping specifications from
/etc/map on initialization, and reloads the entire map when it
receives a JCR event.

In some scenarios it would be nice to be able to store mapping specs
other places (scattered around the repository/resource tree, for
instance). That is possible by registering a resource provider at
/etc/map (thus overriding any JCR resource there), and populate the
resource provider with whatever mappings you have. Then you need to
trigger a JCR event at /etc/map to have JcrResourceResolverFactoryImpl
reload its MapEntries.

But this is a bit of a hack - the entire mapping mechanism is somewhat
"JCR biased". IMO it would be better if the entire map specification
was provided by a separate component, say a PathMapProvider (in lack
of a better name):

public interface PathMapProvider {
   public List getResolveMaps();
   public Collection getMapMaps();
}

This is a bit rough, but it resembles the current MapEntries class. We
might want to let PathMapProvider do more than just return those
MapEntry'ies, but then we'll soon end up re-implementing
JcrResourceResolver.map and .resolve.

WDYT?

-- 
Vidar S. Ramdal 
Webstep AS - http://www.webstep.no
Besøksadresse: Lilleakerveien 8, 0283 Oslo
Postadresse: Postboks 66, 1324 Lysaker

Re: Welcome new committer Carl Hall

[Vidar Ramdal]

On Sat, Feb 26, 2011 at 5:42 PM, Felix Meschberger  wrote:
> Hi all,
>
> I want to let you know that the Apache Sling PMC decided to invite Carl
> Hall as a committer to the Apache Sling project based on his sustained
> support and work on Sling; an invitation which Carl accepted. Thanks.
>
> Please join me in welcoming Carl Hall as a new committer !

Great to have you on the team, Carl!

-- 
Vidar S. Ramdal  - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00
Quando omni flunkus moritatus!

Re: [VOTE] Release Apache Sling Scripting JavaScript 2.0.12

[Vidar Ramdal]

On Sun, Feb 20, 2011 at 9:34 PM, Felix Meschberger  wrote:
> Hi all
>
> Here is the Apache Sling Scripting JavaScript 2.0.12 release. This fixes
> one major issue with respect to running the same script concurrently
> (SLING-1972).
>
> The two fixes included in this release:
> https://issues.apache.org/jira/browse/SLING/fixforversion/12316006
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-029/
>
> You can use this UNIX script to download the release and verify the
> signatures:
> http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh
>
> Usage:
> sh check_staged_release.sh 029 /tmp/sling-staging
>
> Please vote to approve this release:
>
>  [ ] +1 Approve the release
>  [ ]  0 Don't care
>  [ ] -1 Don't release, because ...

+1

-- 
Vidar S. Ramdal  - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00
Quando omni flunkus moritatus!

Re: [VOTE] Release JCR Resource 2.0.10 and Engine 2.2.2

[Vidar Ramdal]

On Mon, Feb 21, 2011 at 8:15 AM, Carsten Ziegeler  wrote:
> Hi,
>
> in order to have a nicer version number for the Engine
> moduleehm...to fix some annoying bugs wrt the web console, this is
> another vote for SLING-6. It contains two fixes for
>
> - Apache Sling JCR Resource 2.0.10
> https://issues.apache.org/jira/browse/SLING/fixforversion/12315298
>
> and one for
>
> - Apache Sling Engine 2.2.2
> https://issues.apache.org/jira/browse/SLING/fixforversion/12316094
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-032/
>
> You can use this UNIX script to download the release and verify the
> signatures:
> http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh
>
> Usage:
> sh check_staged_release.sh 032 /tmp/sling-staging
>
> Please vote to approve this release:
>
>  [ ] +1 Approve the release
>  [ ]  0 Don't care
>  [ ] -1 Don't release, because ...

+1

-- 
Vidar S. Ramdal  - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00
Quando omni flunkus moritatus!

Re: [VOTE] Release Apache Sling Commons Testing 2.0.8

[Vidar Ramdal]

On Tue, Feb 15, 2011 at 3:24 AM, Justin Edelson
 wrote:
> Hi,
> We solved 1 issue in this release:
>
> https://issues.apache.org/jira/browse/SLING/fixforversion/12315350
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-004/
>
> You can use this UNIX script to download the release and verify the
> signatures: 
> http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh
>
> Usage:
> sh check_staged_release.sh 004 /tmp/sling-staging
>
> Please vote to approve this release:
>    [ ] +1 Approve the release
>    [ ]  0 Don't care
>    [ ] -1 Don't release, because ...

+1

-- 
Vidar S. Ramdal  - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00
Quando omni flunkus moritatus!

Re: [VOTE] Release Apache Sling Launchpad API 1.0.0, Launchpad Installer 1.0.0 Launchpad Base 2.3.0, Maven Launchpad Plugin 2.0.10

[Vidar Ramdal]

On Tue, Feb 15, 2011 at 3:17 AM, Justin Edelson
 wrote:
> Hi,
> We solved 13 issues in this release:
>
> https://issues.apache.org/jira/browse/SLING/fixforversion/12316173
> https://issues.apache.org/jira/browse/SLING/fixforversion/12316174
> https://issues.apache.org/jira/browse/SLING/fixforversion/12314956
> https://issues.apache.org/jira/browse/SLING/fixforversion/12315980
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-003/

+1


-- 
Vidar S. Ramdal  - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00
Quando omni flunkus moritatus!

Re: [POST servlet] Patching multi-value properties

[Vidar Ramdal]

On Mon, Jan 31, 2011 at 2:19 PM, Alexander Klimetschek
 wrote:
> Hi again,
>
> could I assume silent agreement to this feature? ;-)

No. I agree loudly :)


-- 
Vidar S. Ramdal  - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00
Quando omni flunkus moritatus!

Re: [VOTE] New releases for SLING-6

[Vidar Ramdal]

On Mon, Jan 24, 2011 at 1:10 PM, Carsten Ziegeler  wrote:
> Hi,
>
> this is another set of new releases for SLING-6. With this we're through
> except from launchpad!
>
> This vote is about the release of:
>
> - Apache Sling JCR Resource 2.0.8 [1]
> - Apache Sling Engine 2.2.0 [2]
> - Apache Sling Bundle Resource Provider 2.0.6 [3]
> - Apache Sling File Resource Provider 1.0.2 [4]
>
>
> We solved some important issues in each release to get SLING-6 going:
>
> [1]
> https://issues.apache.org/jira/browse/SLING/fixforversion/12314286
>
> [2]
> https://issues.apache.org/jira/browse/SLING/fixforversion/12315291
>
> [3]
> https://issues.apache.org/jira/browse/SLING/fixforversion/12315239
>
> [4]
> https://issues.apache.org/jira/browse/SLING/fixforversion/12314796
>
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-063/
>
> You can use this UNIX script to download the release and verify the
> signatures:
> http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh
>
> Usage:
> sh check_staged_release.sh 063 /tmp/sling-staging
>
> Please vote to approve this release:
>
>  [ ] +1 Approve the release
>  [ ]  0 Don't care
>  [ ] -1 Don't release, because ...
>
> This vote will be open for 72 hours.

+1

-- 
Vidar S. Ramdal  - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00
Quando omni flunkus moritatus!

Re: Mass-upgrading bundles

[Vidar Ramdal]

On Thu, Jan 20, 2011 at 10:47 PM, Mike Moulton  wrote:
> We deploy our sling instances inside a Karaf [1] or ServiceMix [2] container, 
> as opposed to the launchpad, so we can use features [3] to deploy sling and 
> our applications. This allows us to deploy builds rather quickly, while also 
> providing a central location for us to track the matrix of versions of our 
> bundles and roll them all up into a single version of our feature. This also 
> lets us pull bundles in from either a maven repo (Nexus) or and ORB repo 
> (also Nexus for us).

Great tip, looks promising!

>
> [1] http://karaf.apache.org/
> [2] http://servicemix.apache.org/home.html
> [3] http://karaf.apache.org/46-provisioning.html
>
> -- Mike
>
>
> --
>
> mike moulton | meltmedia
>
> m...@meltmedia.com
> w | 602.648.6810
> c | 602.432.2568
> @mmoulton
>
>
>
> On Jan 20, 2011, at 8:11 AM, Vidar Ramdal wrote:
>
>> I have been thinking about an easier way to upgrade our application,
>> which now consists of something like 100 bundles. We run on multiple
>> servers, and upgrading them bundle-by-bundle is really tedious.
>>
>> I know I can update bundles directly from an OSGi repository, via the
>> web console at http://localhost:8080/system/console/obr, but it still
>> requires to locate and deploy one bundle at a time.
>>
>> So how about a web console which allows me to upload an XML list, for
>> example on the same format used by the Maven Launchpad plugin.
>> The list of bundles will be compared to the set of currently deployed
>> bundles. Any bundle in the list which is not currently deployed, will
>> be downloaded, installed and started. Updated bundles, that is, the
>> bundle list contains a bundle in a newer version than a bundle
>> currently running, will be updated. And finally, bundles that are
>> currently deployed, but not in the list, will be uninstalled.
>>
>> Does this make sense as an extension to Sling?
>>
>> --
>> Vidar S. Ramdal  - http://www.idium.no
>> Sommerrogata 13-15, N-0255 Oslo, Norway
>> + 47 22 00 84 00
>> Quando omni flunkus moritatus!
>
>



-- 
Vidar S. Ramdal  - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00
Quando omni flunkus moritatus!

Re: Mass-upgrading bundles

[Vidar Ramdal]

> On Thu, Jan 20, 2011 at 4:11 PM, Vidar Ramdal  wrote:
>> I have been thinking about an easier way to upgrade our application,
>> which now consists of something like 100 bundles. We run on multiple
>> servers, and upgrading them bundle-by-bundle is really tedious.
>>
>> I know I can update bundles directly from an OSGi repository, via the
>> web console at http://localhost:8080/system/console/obr, but it still
>> requires to locate and deploy one bundle at a time.
>>
>> So how about a web console which allows me to upload an XML list, for
>> example on the same format used by the Maven Launchpad plugin.
>> The list of bundles will be compared to the set of currently deployed
>> bundles. Any bundle in the list which is not currently deployed, will
>> be downloaded, installed and started. Updated bundles, that is, the
>> bundle list contains a bundle in a newer version than a bundle
>> currently running, will be updated. And finally, bundles that are
>> currently deployed, but not in the list, will be uninstalled.
>>
>> Does this make sense as an extension to Sling?

On Thu, Jan 20, 2011 at 4:14 PM, Karl Pauls  wrote:
> Did you have a look at ace already (http://incubator.apache.org/ace/)?

Ooooh, sweeet!
At first look, it seems a little overkill, but I'll definitely look
more into it.
Thanks for the tip!

-- 
Vidar S. Ramdal  - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00
Quando omni flunkus moritatus!

Mass-upgrading bundles

[Vidar Ramdal]

I have been thinking about an easier way to upgrade our application,
which now consists of something like 100 bundles. We run on multiple
servers, and upgrading them bundle-by-bundle is really tedious.

I know I can update bundles directly from an OSGi repository, via the
web console at http://localhost:8080/system/console/obr, but it still
requires to locate and deploy one bundle at a time.

So how about a web console which allows me to upload an XML list, for
example on the same format used by the Maven Launchpad plugin.
The list of bundles will be compared to the set of currently deployed
bundles. Any bundle in the list which is not currently deployed, will
be downloaded, installed and started. Updated bundles, that is, the
bundle list contains a bundle in a newer version than a bundle
currently running, will be updated. And finally, bundles that are
currently deployed, but not in the list, will be uninstalled.

Does this make sense as an extension to Sling?

-- 
Vidar S. Ramdal  - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00
Quando omni flunkus moritatus!

Re: Sling sometimes return 404 on all requests after startup

[Vidar Ramdal (Kolibri)]

> On Tue, Nov 30, 2010 at 1:20 PM, Vidar Ramdal  wrote:
>>>... There is also a large number of lines saying *INFO* [SCR Component
>>> Actor] org.apache.sling.servlets.resolver
>>> [org.apache.sling.servlets.resolver.SlingServletResolver] Dependency
>>> not satisfied: servletContext
>>
>> Digging around, I see that o.a.felix.http.jetty.internal.JettyService
>> is started, the thread's run method is invoked, but then almost
>> immediately interrupted from the updated method, when JettyService
>> receives its configuration.
>> This again triggers initializeJetty(), which calls new Server()

On Tue, Nov 30, 2010 at 1:34 PM, Bertrand Delacretaz
 wrote:
> I don't have a solution but FWIW I've also seen this behavior in
> testing framework startup: components are activated, deactivated and
> reactivated quickly as the framework tries to startup things and fails
> because not all required components are available. From what you're
> seeing it seems like the JettyService does not handle this scenario
> correctly.

Thanks Bertrand!

It seems (for now) that the problem can be made much less frequent by
moving the o.a.f..http.whiteboard bundle to a lower start level. I'll
give it some time and see if it helps.


-- 
Vidar S. Ramdal  - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00 / +47 22 00 84 76
Quando omni flunkus moritatus!

Re: Sling sometimes return 404 on all requests after startup

[Vidar Ramdal]

On Tue, Nov 30, 2010 at 12:00 PM, Vidar Ramdal  wrote:
> Hi, we're having a problem with our Sling-based app. On about 50% of
> the cases, the app returns 404 on all requests immediately after
> startup.
> A random number of restarts usually solves the problem, with the app
> responding properly again.
>
> In the startup log I see two lines saying "*INFO* [Jetty HTTP Service]
> org.apache.felix.http.jetty Started jetty 6.1.x at port 80" - is this
> normal?
> I suspect, that for some reason, two instances of Jetty is started,
> and that this may cause servlets to bind to the one instance that is
> not active when the startup procedure is done.
>
> But why is Jetty started twice?
>
> There is also a large number of lines saying *INFO* [SCR Component
> Actor] org.apache.sling.servlets.resolver
> [org.apache.sling.servlets.resolver.SlingServletResolver] Dependency
> not satisfied: servletContext

Digging around, I see that o.a.felix.http.jetty.internal.JettyService
is started, the thread's run method is invoked, but then almost
immediately interrupted from the updated method, when JettyService
receives its configuration.
This again triggers initializeJetty(), which calls new Server().

Would this cause servlets that happen to be registered before the
configuration is updated, to become unreachable?

> Any help appreciated.

-- 
Vidar S. Ramdal  - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00 / +47 22 00 84 76
Quando omni flunkus moritatus!

Sling sometimes return 404 on all requests after startup

[Vidar Ramdal]

Hi, we're having a problem with our Sling-based app. On about 50% of
the cases, the app returns 404 on all requests immediately after
startup.
A random number of restarts usually solves the problem, with the app
responding properly again.

In the startup log I see two lines saying "*INFO* [Jetty HTTP Service]
org.apache.felix.http.jetty Started jetty 6.1.x at port 80" - is this
normal?
I suspect, that for some reason, two instances of Jetty is started,
and that this may cause servlets to bind to the one instance that is
not active when the startup procedure is done.

But why is Jetty started twice?

There is also a large number of lines saying *INFO* [SCR Component
Actor] org.apache.sling.servlets.resolver
[org.apache.sling.servlets.resolver.SlingServletResolver] Dependency
not satisfied: servletContext

Any help appreciated.

-- 
Vidar S. Ramdal  - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00 / +47 22 00 84 76
Quando omni flunkus moritatus!

Re: Welcome new committer Michael Duerig

[Vidar Ramdal (Kolibri)]

On Tue, Nov 30, 2010 at 10:46 AM, Felix Meschberger  wrote:
> Hi all,
>
> I want to let you know that the Apache Sling PMC decided to invite
> Michael Duerig as a committer to the Apache Sling project based on his
> work on adding Scala scripting to Sling; an invitation which Michael
> accepted. Thanks.
>
> Please join me in welcoming Michael Duerig as a new committer !
>
> Keep up the good work, Michael, and thanks for your contributions. And
> feel free to briefly introduce yourself if you want ;-)

Welcome Michael, good do have you on the team!


-- 
Vidar S. Ramdal  - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00 / +47 22 00 84 76
Quando omni flunkus moritatus!

Re: Leverage new ASF CMS ?

[Vidar Ramdal]

On Tue, Nov 9, 2010 at 3:19 PM, Felix Meschberger  wrote:
> Hi all,
>
> We currently use Confluence to maintain our site. At the time this tool
> offered IMHO the best cost-value tradeoff between ease-of-use (for those
> of us not born with the APT gene) and functionality.
>
> Last week the fabulous infra guys now put the Apache CMS into life, see
> [1]. This basically provides a user-friendly editing environment;
> storing files in SVN and automatically generating the site on update.
>
> Since we always had the debate on Confluence vs. SVN-based site, I would
> like to pick this debate up again with the following idea.
>
> We convert from Confluence to using the new Apache CMS leveraging the
> subversion as a versioned store for the site.
>
> Not only would this give us close to immediate site updates (as compared
> to today's 1-3 hours delay) but also more stable updates.

Sounds good.

> Finally we could embark on another journey we once discussed in the dark
> ages of Sling: Bundle the complete Sling documentation with the actual
> Sling downloadable (e.g. as a docs bundle with bundle-resource provided
> content).

Well, the perhaps too obvious way to go is to host
http://sling.apache.org on *Sling*.
Maybe an idea for next year's GSoC?

-- 
Vidar S. Ramdal  - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00 / +47 22 00 84 76
Quando omni flunkus moritatus!

Re: SlingPostServletClient, helper class?

[Vidar Ramdal]

On Tue, Sep 28, 2010 at 2:44 PM, Clemens Wyss  wrote:
> Do we somewhere in the sling-repo/sources have a helper class for posting 
> data to Sling(PostServlet)?
>
> Asked the other way round:
> given a legacy database with lots of data, how would you inject 
> (export/import) this data into Sling/JCR?
>
> Thx in advance for your advices/hints

How about exporting the legacy content to an XML structure, and import
it as initial content?
If you know XSLT, you can use almost any XML structure that seems fit.

See http://sling.apache.org/site/content-loading-jcrcontentloader.html

-- 
Vidar S. Ramdal  - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00 / +47 22 00 84 76
Quando omni flunkus moritatus!

Re: "Node added" event type filter applies to parent node

[Vidar Ramdal]

>> Vidar Ramdal  wrote
>>> I'm adding nodes to a parent node. The parent node has
>>> nt:primaryType=sling:OrderedFolder, while the child node I'm adding
>>> has nt:primaryType=slingevent:Event.
>>>
>>> Now, I have an event listener set up to receive NODE_ADDED events with
>>> nodetype slingevent:Event.
>>>
>>> The event listener is never invoked, but I can see that an event is
>>> being triggered, by having a breakpoing in
>>> o.a.j.c.observation.EventConsumer.
>>>
>>> Upon investigating, it seems the event is filtered out, because it
>>> reports the node type of the parent node (sling:OrderedFolder) instead
>>> of the node type of the child node being added (slingevent:Event). Is
>>> this the expected behaviour?
>
> On Mon, Sep 27, 2010 at 6:34 PM, Carsten Ziegeler  
> wrote:
>> Funnily I stumbled across the same problem last week - actually the
>> behaviour is correct. The spec states that the node type of the parent
>> item is checked - in case of node added/removed events, this is the
>> parent node.
>> I think this limits its usage but its the spec...

On Mon, Sep 27, 2010 at 6:54 PM, Vidar Ramdal  wrote:
> Thanks for the clarification! Looks like we have a bug in Sling, then.
> I'll investigate some more and post a bug there.

Never mind this - it seems it was fixed with SLING-1494.

-- 
Vidar S. Ramdal  - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00 / +47 22 00 84 76
Quando omni flunkus moritatus!

Re: "Node added" event type filter applies to parent node

[Vidar Ramdal]

> Vidar Ramdal  wrote
>> I'm adding nodes to a parent node. The parent node has
>> nt:primaryType=sling:OrderedFolder, while the child node I'm adding
>> has nt:primaryType=slingevent:Event.
>>
>> Now, I have an event listener set up to receive NODE_ADDED events with
>> nodetype slingevent:Event.
>>
>> The event listener is never invoked, but I can see that an event is
>> being triggered, by having a breakpoing in
>> o.a.j.c.observation.EventConsumer.
>>
>> Upon investigating, it seems the event is filtered out, because it
>> reports the node type of the parent node (sling:OrderedFolder) instead
>> of the node type of the child node being added (slingevent:Event). Is
>> this the expected behaviour?

On Mon, Sep 27, 2010 at 6:34 PM, Carsten Ziegeler  wrote:
> Funnily I stumbled across the same problem last week - actually the
> behaviour is correct. The spec states that the node type of the parent
> item is checked - in case of node added/removed events, this is the
> parent node.
> I think this limits its usage but its the spec...

Thanks for the clarification! Looks like we have a bug in Sling, then.
I'll investigate some more and post a bug there.
(Cross-posting to d...@sling)

-- 
Vidar S. Ramdal  - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00 / +47 22 00 84 76
Quando omni flunkus moritatus!

Re: Welcome Mike Mueller as a new member of the Sling PMC

[Vidar Ramdal]

On Mon, Sep 20, 2010 at 8:07 PM, Felix Meschberger  wrote:
> Hi all,
>
> It is with utmost pleasure that I announce that the Apache Sling PMC
> recently voted to invite Mike Müller as a new PMC member and he accepted.
>
> Mike has been doing and is continuing to do a great job on all fronts
> of Sling, most notably documentation and mentoring our new committer
> Clemens Wyss. So his inclusion in the PMC is well deserved.

Absolutely. Welcome, Mike!


-- 
Vidar S. Ramdal  - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00 / +47 22 00 84 76
Quando omni flunkus moritatus!

Re: [VOTE] Release Commons Testing 2.0.6, OSGi Installer 3.0.0, JCR Installer 3.0.0, and File Installer 1.0.0

[Vidar Ramdal]

On Thu, Sep 16, 2010 at 6:23 PM, Bertrand Delacretaz
 wrote:
> On Thu, Sep 16, 2010 at 5:27 PM, Vidar Ramdal  wrote:
>>...
>> 
>>                          CHECK SIGNATURES AND DIGESTS
>> 
>> sling-staging/039/.index/nexus-maven-repository-index.gz
>> gpg:  
>> md5:  BAD
>> sha1: BAD
>
> Should be SLING-1780, can you svn up and try again?

Thanks, that did it, so I'm happy to give my
+1

-- 
Vidar S. Ramdal  - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00 / +47 22 00 84 76
Quando omni flunkus moritatus!

Re: Welcome Clemens Wyss

[Vidar Ramdal]

On Fri, Sep 17, 2010 at 9:06 AM, Clemens Wyss  wrote:
> A few words about myself (feel free to skip ;-) ):
> I (aged 42, married and father of 3 children) live in
> Switzerland where I studied information technologies at
> the ETH Zurich quite a long time ago.
> I then worked for approx 4 years with Smalltalk (still lovin' it),
> switched over to C#/.NET (dito), Python (where I (not only) played
> around with bobo(*)) and Ruby/Rails (dito), before entering the
> Java world at the beginning of this year. That said, since the
> beginning of this year I work for MySign (http://www.mysign.ch)
>
> Looking forward to further contribute to Sling...
>
> (*)bobo, very RESTy, but that was 1998! :-)

Welcome, Clemens!

So when will we see Smalltalk scripting support in Sling? :)

-- 
Vidar S. Ramdal  - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00 / +47 22 00 84 76
Quando omni flunkus moritatus!

Re: [VOTE] Release Commons Testing 2.0.6, OSGi Installer 3.0.0, JCR Installer 3.0.0, and File Installer 1.0.0

[Vidar Ramdal]

On Thu, Sep 16, 2010 at 9:48 AM, Carsten Ziegeler  wrote:
> Hi,
>
> as announced it's time for some more releases :)
>
> Apart from our first releases of
> OSGi Installer 3.0.0
> JCR Installer 3.0.0
> File Installer 1.0.0
>
> I've added Commons Testing 2.0.6 (which is a dep of jcr installer)
> https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&pid=12310710&fixfor=12314354
>
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-039/
>
> You can use this UNIX script to download the release and verify the
> signatures:
> http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh
>
> Usage:
> sh check_staged_release.sh 039 /tmp/sling-staging

Don't know if this is just me, but I'm getting reports on bad
signatures for all artifacts:


  CHECK SIGNATURES AND DIGESTS

sling-staging/039/.index/nexus-maven-repository-index.gz
gpg:  
md5:  BAD
sha1: BAD
sling-staging/039/.index/nexus-maven-repository-index.properties
gpg:  
md5:  BAD
sha1: BAD
sling-staging/039/.meta/p2-metadata.properties
gpg:  
md5:  
sha1: 
sling-staging/039/.meta/repository-metadata.xml
gpg:  
md5:  
sha1: 
sling-staging/039/org/apache/sling/org.apache.sling.commons.testing/2.0.6/org.apache.sling.commons.testing-2.0.6-javadoc.jar
gpg:  BAD
md5:  BAD
sha1: BAD
sling-staging/039/org/apache/sling/org.apache.sling.commons.testing/2.0.6/org.apache.sling.commons.testing-2.0.6-source-release.zip
gpg:  BAD
md5:  BAD
sha1: BAD
sling-staging/039/org/apache/sling/org.apache.sling.commons.testing/2.0.6/org.apache.sling.commons.testing-2.0.6-sources.jar
gpg:  BAD
md5:  BAD
sha1: BAD
sling-staging/039/org/apache/sling/org.apache.sling.commons.testing/2.0.6/org.apache.sling.commons.testing-2.0.6.jar
gpg:  BAD
md5:  BAD
sha1: BAD
sling-staging/039/org/apache/sling/org.apache.sling.commons.testing/2.0.6/org.apache.sling.commons.testing-2.0.6.pom
gpg:  BAD
md5:  BAD
sha1: BAD
sling-staging/039/org/apache/sling/org.apache.sling.commons.testing/maven-metadata.xml
gpg:  
md5:  BAD
sha1: BAD
sling-staging/039/org/apache/sling/org.apache.sling.install.fileinstall/1.0.0/org.apache.sling.install.fileinstall-1.0.0-source-release.zip
gpg:  BAD
md5:  BAD
sha1: BAD
sling-staging/039/org/apache/sling/org.apache.sling.install.fileinstall/1.0.0/org.apache.sling.install.fileinstall-1.0.0-sources.jar
gpg:  BAD
md5:  BAD
sha1: BAD
sling-staging/039/org/apache/sling/org.apache.sling.install.fileinstall/1.0.0/org.apache.sling.install.fileinstall-1.0.0.jar
gpg:  BAD
md5:  BAD
sha1: BAD
sling-staging/039/org/apache/sling/org.apache.sling.install.fileinstall/1.0.0/org.apache.sling.install.fileinstall-1.0.0.pom
gpg:  BAD
md5:  BAD
sha1: BAD
sling-staging/039/org/apache/sling/org.apache.sling.install.fileinstall/maven-metadata.xml
gpg:  
md5:  BAD
sha1: BAD
sling-staging/039/org/apache/sling/org.apache.sling.jcr.jcrinstall/3.0.0/org.apache.sling.jcr.jcrinstall-3.0.0-source-release.zip
gpg:  BAD
md5:  BAD
sha1: BAD
sling-staging/039/org/apache/sling/org.apache.sling.jcr.jcrinstall/3.0.0/org.apache.sling.jcr.jcrinstall-3.0.0-sources.jar
gpg:  BAD
md5:  BAD
sha1: BAD
sling-staging/039/org/apache/sling/org.apache.sling.jcr.jcrinstall/3.0.0/org.apache.sling.jcr.jcrinstall-3.0.0.jar
gpg:  BAD
md5:  BAD
sha1: BAD
sling-staging/039/org/apache/sling/org.apache.sling.jcr.jcrinstall/3.0.0/org.apache.sling.jcr.jcrinstall-3.0.0.pom
gpg:  BAD
md5:  BAD
sha1: BAD
sling-staging/039/org/apache/sling/org.apache.sling.jcr.jcrinstall/maven-metadata.xml
gpg:  
md5:  BAD
sha1: BAD
sling-staging/039/org/apache/sling/org.apache.sling.osgi.installer/3.0.0/org.apache.sling.osgi.installer-3.0.0-javadoc.jar
gpg:  BAD
md5:  BAD
sha1: BAD
sling-staging/039/org/apache/sling/org.apache.sling.osgi.installer/3.0.0/org.apache.sling.osgi.installer-3.0.0-source-release.zip
gpg:  BAD
md5:  BAD
sha1: BAD
sling-staging/039/org/apache/sling/org.apache.sling.osgi.installer/3.0.0/org.apache.sling.osgi.installer-3.0.0-sources.jar
gpg:  BAD
md5:  BAD
sha1: BAD
sling-staging/039/org/apache/sling/org.apache.sling.osgi.installer/3.0.0/org.apache.sling.osgi.installer-3.0.0.jar
gpg:  BAD
md5:  BAD
sha1: BAD
sling-staging/039/org/apache/sling/org.apache.sling.osgi.installer/3.0.0/org.apache.sling.osgi.installer-3.0.0.pom
gpg:  BAD
md5:  BAD
sha1: BAD

Re: Releasing installer bundles?

[Vidar Ramdal]

On Tue, Sep 14, 2010 at 6:46 PM, Carsten Ziegeler  wrote:
> I think the osgi installer is now ready for a release, the api looks now
> fine to me and the implementation now finally seems to pass all our
> integration tests. In addition I tried the latest code within our
> product and couldn't find any problems so far.
>
> So I think it's time to finally cut a first release of the installer
> stuff. This would include:
>
> osgi installer 3.0.0
> jcr installer 3.0.0
> file installer 1.0.0
>
> I briefly tested the file installer and it seems to do what it should :)
>
> If noone objects I'll cut the releases in the next days.
>
> I think we should do a release regardless if we include these bundles in
> SLING-6 or not; we now worked for several years on this stuff without
> any real release :)

+1

-- 
Vidar S. Ramdal  - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00 / +47 22 00 84 76
Quando omni flunkus moritatus!

Re: [VOTE] Release Apache Sling JCR API, JCR Base, JCR Content Loader, and Jackrabbit Server 2.1.0

[Vidar Ramdal]

On Mon, Sep 6, 2010 at 5:10 PM, Justin Edelson  wrote:
> We solved a total of 33 issues in these releases:
>
> JCR API - 1 issue:
> https://issues.apache.org/jira/browse/SLING/fixforversion/12314564
>
> JCR Base - 6 issues:
> https://issues.apache.org/jira/browse/SLING/fixforversion/12314768
>
> JCR Content Loader - 16 issues:
> https://issues.apache.org/jira/browse/SLING/fixforversion/12314472
>
> Embedded Jackrabbit Server - 10 issues:
> https://issues.apache.org/jira/browse/SLING/fixforversion/12314769
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-038/
>
> You can use this UNIX script to download the release and verify the 
> signatures:
> http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh
>
> Usage:
> sh check_staged_release.sh 038 /tmp/sling-staging
>
> Please vote to approve this release:
>
>  [ ] +1 Approve the release
>  [ ]  0 Don't care
>  [ ] -1 Don't release, because ...
>
> This vote will be open for 72 hours.

+1

-- 
Vidar S. Ramdal  - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00 / +47 22 00 84 76
Quando omni flunkus moritatus!

Re: [DISCUSS] ResourceResolver with multiple resource providers bound to the same path?

[Vidar Ramdal]

On Tue, Sep 7, 2010 at 12:51 AM, Justin Edelson  wrote:
> And all of the SLING-1672-related changes should only impact listChildren(), 
> not individual resource resolution. So the use of the file system provider to 
> shadow resources from JCR should remain unchanged.

Ah, good :)

>
> On Sep 6, 2010, at 6:29 PM, Eric Norman  wrote:
>
>> Hi Vidar,
>>
>> My proposed patch affects only the BundleResourceProvider so I don't think
>> it would affect the scenario you have described.
>>
>> Regards,
>> Eric
>>
>> On Mon, Sep 6, 2010 at 1:30 PM, Vidar Ramdal  wrote:
>>
>>>> On 06.09.2010 19:48, Eric Norman wrote:
>>>>> Hi All,
>>>>>
>>>>> This seems kind of similar to*
>>>>> SLING-1672<https://issues.apache.org/jira/browse/SLING-1672>
>>>>> * which has been marked as resolved.  However, with the latest trunk
>>> code, I
>>>>> am still running into some difficulties when multiple bundles are
>>> providing
>>>>> Sling-Bundle-Resources with the same path.  I would assume that the
>>> children
>>>>> of all the providers at the same path should be merged together?
>>> Currently,
>>>>> it seems that the first parent resource found wins, and listing the
>>> children
>>>>> only return the scripts in that bundle.  The scripts provided by the
>>> other
>>>>> bundles are not visible.  Obviously, this makes it difficult to have
>>> modular
>>>>> bundles if all the scripts need to be inside the same bundle to be
>>> found.
>>>>> .
>>>>> For example:
>>>>>
>>>>> Bundle 1 contains these scripts:
>>>>> /libs/sling/servlet/default/script1.html.esp
>>>>> /libs/sling/servlet/default/script2.html.esp
>>>>>
>>>>> And the resource is provided as:
>>>>> 
>>>>>    /libs/sling/servlet/default
>>>>> 
>>>>>
>>>>> Bundle 2 contains these scripts:
>>>>> /libs/sling/servlet/default/script2.html.esp
>>>>> /libs/sling/servlet/default/script3.html.esp
>>>>>
>>>>> And the resource is provided as:
>>>>> 
>>>>>    /libs/sling/servlet/default
>>>>> 
>>>>>
>>>>>
>>>>> With both bundles installed, you either see the scripts from bundle1 or
>>> the
>>>>> scripts from bundle2 but not both.
>>>>>
>>>>> Thoughts?
>>>
>>> On Mon, Sep 6, 2010 at 8:56 PM, Felix Meschberger 
>>> wrote:
>>>> I would say, your use case is perfectly valid and really should work.
>>>>
>>>> If not, we would have to analyze where in the listChildren
>>>> implementation the problem lies.
>>>>
>>>> At least we would have to have an issue to track this.
>>>
>>> If a (hypothetic) patch should apply to all kinds of resource
>>> providers (not just bundle resource providers, as in the example
>>> above) it would probably break a very common use case:
>>> Bundles that provides initial content. During development, it is
>>> useful to map the resource paths to disk directories, using
>>> FsResourceProviders. This currently works, because FsResourceProvider
>>> overrides the JCR content paths.
>>> Example:
>>> - Bundle A provides /apps/something/scripts as initial content. During
>>> development, /apps/something/scripts is mapped to
>>> /Users/somebody/something/scripts, for a short round-trip development
>>> cycle.
>>> If the above suggestion is implemented, the resource path
>>> /apps/something/scripts would list content from both JCR and disk.
>>>
>>> --
>>> Vidar S. Ramdal  - http://www.idium.no
>>> Sommerrogata 13-15, N-0255 Oslo, Norway
>>> + 47 22 00 84 00 / +47 22 00 84 76
>>> Quando omni flunkus moritatus!
>>>
>



-- 
Vidar S. Ramdal  - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00 / +47 22 00 84 76
Quando omni flunkus moritatus!

Re: [DISCUSS] ResourceResolver with multiple resource providers bound to the same path?

[Vidar Ramdal]

> On 06.09.2010 19:48, Eric Norman wrote:
>> Hi All,
>>
>> This seems kind of similar to*
>> SLING-1672
>> * which has been marked as resolved.  However, with the latest trunk code, I
>> am still running into some difficulties when multiple bundles are providing
>> Sling-Bundle-Resources with the same path.  I would assume that the children
>> of all the providers at the same path should be merged together?  Currently,
>> it seems that the first parent resource found wins, and listing the children
>> only return the scripts in that bundle.  The scripts provided by the other
>> bundles are not visible.  Obviously, this makes it difficult to have modular
>> bundles if all the scripts need to be inside the same bundle to be found.
>> .
>> For example:
>>
>> Bundle 1 contains these scripts:
>> /libs/sling/servlet/default/script1.html.esp
>> /libs/sling/servlet/default/script2.html.esp
>>
>> And the resource is provided as:
>> 
>>     /libs/sling/servlet/default
>> 
>>
>> Bundle 2 contains these scripts:
>> /libs/sling/servlet/default/script2.html.esp
>> /libs/sling/servlet/default/script3.html.esp
>>
>> And the resource is provided as:
>> 
>>     /libs/sling/servlet/default
>> 
>>
>>
>> With both bundles installed, you either see the scripts from bundle1 or the
>> scripts from bundle2 but not both.
>>
>> Thoughts?

On Mon, Sep 6, 2010 at 8:56 PM, Felix Meschberger  wrote:
> I would say, your use case is perfectly valid and really should work.
>
> If not, we would have to analyze where in the listChildren
> implementation the problem lies.
>
> At least we would have to have an issue to track this.

If a (hypothetic) patch should apply to all kinds of resource
providers (not just bundle resource providers, as in the example
above) it would probably break a very common use case:
Bundles that provides initial content. During development, it is
useful to map the resource paths to disk directories, using
FsResourceProviders. This currently works, because FsResourceProvider
overrides the JCR content paths.
Example:
- Bundle A provides /apps/something/scripts as initial content. During
development, /apps/something/scripts is mapped to
/Users/somebody/something/scripts, for a short round-trip development
cycle.
If the above suggestion is implemented, the resource path
/apps/something/scripts would list content from both JCR and disk.

-- 
Vidar S. Ramdal  - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00 / +47 22 00 84 76
Quando omni flunkus moritatus!

Re: outstanding Sling 6 issues

[Vidar Ramdal]

On Fri, Sep 3, 2010 at 9:56 PM, Felix Meschberger  wrote:
> Hi,
>
> On 02.09.2010 14:07, Carsten Ziegeler wrote:
>> Justin Edelson  wrote
>>> Servlets
>>> * SLING-1069 - Servlets registered with default resource type responds
>>> to all extensions
>>> * SLING-892 - Allow servlets to be regsitered with extensions for all
>>> request methods
>> While these two would be nice to have, I think they should not block
>> Sling 6; there is no patch for SLING-892 and we didn't come to a
>> conclusion for SLING-1069. If we can solve this in the next days, I'm
>> fine - if not, let's move them to the next release.
>
> I have been looking at these issues again (see updates).
>
> For 892 I had a patch lying in my workspace for quite some time now ...
> never came around attaching it. Anyway, this small patch would allow
> non-GET servlets to be considered with selector and extension.
>
> As for 1069 the issue is, thar probably a full permutation of the
> declared selectors, extensions, and method names should be used for
> registering. I have attached an alternate patch to Vidar's patch which
> looks more complete. As such this would make 1069 dependent on 892
> because there's no value registering non-GET servlets for selectors and
> extensions... Maybe this was the reason to not use full permutations for
> registration at that time.
>
> So, if there is no opposition, I would like to apply these patches and
> try to come up with some tests for the 2.1.0 release of the resolver.
>
> WDYT ?

Looks good to me.
+1

-- 
Vidar S. Ramdal  - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00 / +47 22 00 84 76
Quando omni flunkus moritatus!

Re: Exception in finalizer: org.apache.felix.http.jetty header full: java.lang.NullPointerException

[Vidar Ramdal]

> On 31.08.2010 14:00, Vidar Ramdal wrote:
>> We are currently experiencing memory leaks in our Sling-based app, and
>> one possible suspect is that some HttpRequests are not being garbage
>> collected.
>> The log shows a good deal of these lines:
>> *WARN* [Finalizer] org.apache.felix.http.jetty header full:
>> java.lang.NullPointerException
>>
>> 'Header full' is a message that is returned to the client when the
>> Cookie header is too long.
>>
>> Have someone seen this log message before, and would it be correct to
>> assume that this prevents some objects from being GCed?

On Thu, Sep 2, 2010 at 4:50 PM, Felix Meschberger  wrote:
> Hi,
>
> Sorry for the delay.
>
> I have to admit, that I never saw such an error message.
>
> Could this be related to http://jira.codehaus.org/browse/JETTY-874 ?

Felix, thanks for your response. I'll look further into JETTY-874.

-- 
Vidar S. Ramdal  - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00 / +47 22 00 84 76
Quando omni flunkus moritatus!

Exception in finalizer: org.apache.felix.http.jetty header full: java.lang.NullPointerException

[Vidar Ramdal]

We are currently experiencing memory leaks in our Sling-based app, and
one possible suspect is that some HttpRequests are not being garbage
collected.
The log shows a good deal of these lines:
*WARN* [Finalizer] org.apache.felix.http.jetty header full:
java.lang.NullPointerException

'Header full' is a message that is returned to the client when the
Cookie header is too long.

Have someone seen this log message before, and would it be correct to
assume that this prevents some objects from being GCed?

-- 
Vidar S. Ramdal  - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00 / +47 22 00 84 76
Quando omni flunkus moritatus!

Re: Welcome Justin Edelson as a new member of the Sling PMC

[Vidar Ramdal]

On Fri, Aug 27, 2010 at 12:49 PM, Felix Meschberger  wrote:
> Hi all,
>
> It is with utmost pleasure that I announce that the Apache Sling PMC
> recently voted to invite Justin Edelson as a new PMC member and he
> accepted.
>
> Justin has been doing and is continuing to do a great job on all fronts
> of Sling, most notably his recent push to get Sling 6 out of the house,
> as well as to provide feedback and guidance to both users and
> developers. So his inclusion in the PMC is well deserved.
>
> On behalf of the PMC, congratulations Justin and keep up the great work.

Welcome Justin, and thanks for all the great contributions you have
made to the project already.
Great to have you on board.

-- 
Vidar S. Ramdal  - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00 / +47 22 00 84 76
Quando omni flunkus moritatus!

Re: [VOTE] Release Sling API 2.1.0

[Vidar Ramdal]

On Wed, Aug 18, 2010 at 6:28 PM, Felix Meschberger  wrote:
> Hi,
>
> At long last here it is: The Sling API 2.1.0 release vote.
>
> We solved 25 issues in this release:
> https://issues.apache.org/jira/browse/SLING/fixforversion/12314252
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-124/
>
> You can use this UNIX script to download the release and verify the
> signatures:
> http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh
>
> Usage:
> sh check_staged_release.sh 124 /tmp/sling-staging
>
> Please vote to approve this release:
>
>  [ ] +1 Approve the release
>  [ ]  0 Don't care
>  [ ] -1 Don't release, because ...
>
> This vote will be open for 72 hours.

+1

-- 
Vidar S. Ramdal  - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00 / +47 22 00 84 76
Quando omni flunkus moritatus!

Re: [VOTE] Grant Jean Christophe write access to the docs [was Re: Scheduler service problem]

[Vidar Ramdal]

On Fri, Aug 6, 2010 at 8:08 AM, Carsten Ziegeler  wrote:
> Hi,
>
> I would like to call a vote to give Jean Christophe write access to our
> documentation. He is volunteering to help in an area where we definitly
> need help and he also did some valuable docs in the past (together with me).
>
> So please cast your votes.

+1

-- 
Vidar S. Ramdal  - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00 / +47 22 00 84 76
Quando omni flunkus moritatus!

Re: [VOTE] Grant Alison write access to the docs

[Vidar Ramdal]

On Fri, Aug 6, 2010 at 8:21 AM, Carsten Ziegeler  wrote:
> Hi,
>
> I would like to call another vote for a new documentation writer: Alison :)
>
> Like Jean Christophe she is volunteering to help us and has already made
> suggestions for improvements and helped with the docs.
>
> So please cast your votes.

+1

-- 
Vidar S. Ramdal  - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00 / +47 22 00 84 76
Quando omni flunkus moritatus!

Unified authentication/authorization in Sling? [WAS: Preventing Listing of child nodes of a resource.]

[Vidar Ramdal]

On Thu, Jul 1, 2010 at 1:52 PM, Ian Boston  wrote:
> Hi,
> I want to be able to stop the listing of all child nodes at specific urls, 
> but still allow direct access to items in a subtree.

Not really related to Ian's post at all, but it got me thinking: Sling
currently implements a way authenticating to a JCR repository via
HTTP, and lets JCR handle authorization.
But how about resources from other sources, like file system folders,
databases etc?

Should we start thinking about a common interface for
authorization/authentication for an arbitrary resource, not just JCR
resources?
The ResourceProvider interface has a getResource(ResourceResolver,
HttpServletRequest, String) method, so I guess implementors could
handle authentication and access control there. But it seems it would
be nice if authentication/authorization stuff was done centrally.

WDYT?

-- 
Vidar S. Ramdal  - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00 / +47 22 00 84 76
Quando omni flunkus moritatus!

Re: Preventing Listing of child nodes of a resource.

[Vidar Ramdal]

>> On Thu, Jul 1, 2010 at 1:52 PM, Ian Boston  wrote:
>>> Hi,
>>> I want to be able to stop the listing of all child nodes at specific urls, 
>>> but still allow direct access to items in a subtree.
>>> Any ideas how this is best done in Sling? (and webdav)
>>>
>>> I have lots, but dont know which is going to be best.
>>> eg
>>> Use a ServletFilter to filter all access to /_user
>>> Patch/Configure webdav to only PROPFIND etc /_user/ieb if ieb is the logged 
>>> in user.
>>> [...]

> On 1 Jul 2010, at 14:19, Vidar Ramdal wrote:
>> This would be fairly easy to implement using a custom AccessManager.
>> But maybe that is not an option.

On Thu, Jul 1, 2010 at 5:07 PM, Ian Boston  wrote:
> That is a good point,
> however doing it at that level will prevent getting child nodes of a node 
> which is needed to get the burried public resource
>
> /_user/ieb/public/xyz.pdf
>
> to get that the jcr resolver is going to need to effectively do
> session.getNode("/_user").childNodes()
>
> and the AccessManager wont be able to tell if thats for getting xyz.pdf or to 
> get the child nodes.
>
> ie, at JCR level all the elements of the path have to be resolvable for the 
> target resource to be readable.

Ah, sorry, I misread your original post. So you want to be able to
receive the child resource if you know the address, right?

Then a custom AccessManager won't do. Unless you can deny access to
only the parent node, then I'm pretty sure you won't be able to list
child nodes - but you won't be able to read the parent node either, of
course.

-- 
Vidar S. Ramdal  - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00 / +47 22 00 84 76
Quando omni flunkus moritatus!

Re: Preventing Listing of child nodes of a resource.

[Vidar Ramdal]

On Thu, Jul 1, 2010 at 1:52 PM, Ian Boston  wrote:
> Hi,
> I want to be able to stop the listing of all child nodes at specific urls, 
> but still allow direct access to items in a subtree.
> Any ideas how this is best done in Sling? (and webdav)
>
> I have lots, but dont know which is going to be best.
> eg
> Use a ServletFilter to filter all access to /_user
> Patch/Configure webdav to only PROPFIND etc /_user/ieb if ieb is the logged 
> in user.
> [...]

This would be fairly easy to implement using a custom AccessManager.
But maybe that is not an option.

-- 
Vidar S. Ramdal  - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00 / +47 22 00 84 76
Quando omni flunkus moritatus!

Re: Content loading on Jackrabbit 1.6.2

[Vidar Ramdal]

On Tue, Jun 8, 2010 at 8:18 PM, Vidar Ramdal  wrote:
> We're running a patched version of the Jackrabbit Server bundle
> (o.a.s.jcr.jr.server) 2.0.6, where we have upgraded the Jackrabbit
> bundles to 1.6.2.This in order to get a fix for the nasty JCR-2554
> bug, which was crashing our application daily.
>
> Now we have an issue with initial loading of files:
> 08.06.2010 20:12:33.786 *ERROR* [Background Update kolibri-files (42)]
> org.apache.sling.jcr.contentloader.internal.Loader Cannot load initial
> content for bundle kolibri-files : no matching property definition
> found for {http://www.jcp.org/jcr/1.0}lastModified
> javax.jcr.nodetype.ConstraintViolationException: no matching property
> definition found for {http://www.jcp.org/jcr/1.0}lastModified
> [...]
> The problem seems to be that the createFileAndResourceNode method
> attempts to create a nt:resource node, and set the jcr:lastModified
> property to a Long value, whereas the jcr:lastModified property is
> defined as a Date.
>
> But this definition hasn't changed between Jackrabbit 1.6.0 and 1.6.2.
>
> So why does this suddenly break? And, perhaps more interesting, why
> did it work in the first place?

Should have realised that this is most of all a Jackrabbit issue. See
the thread at d...@jackrabbit.apache.org [2] for more details.

> [1] https://issues.apache.org/jira/browse/JCR-2554

[2] http://markmail.org/thread/4v2v6qzpvk75kv4h

-- 
Vidar S. Ramdal  - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00 / +47 22 00 84 76
Quando omni flunkus moritatus!

Content loading on Jackrabbit 1.6.2

[Vidar Ramdal]

We're running a patched version of the Jackrabbit Server bundle
(o.a.s.jcr.jr.server) 2.0.6, where we have upgraded the Jackrabbit
bundles to 1.6.2.This in order to get a fix for the nasty JCR-2554
bug, which was crashing our application daily.

Now we have an issue with initial loading of files:
08.06.2010 20:12:33.786 *ERROR* [Background Update kolibri-files (42)]
org.apache.sling.jcr.contentloader.internal.Loader Cannot load initial
content for bundle kolibri-files : no matching property definition
found for {http://www.jcp.org/jcr/1.0}lastModified
javax.jcr.nodetype.ConstraintViolationException: no matching property
definition found for {http://www.jcp.org/jcr/1.0}lastModified
at 
org.apache.jackrabbit.core.nodetype.EffectiveNodeType.getApplicablePropertyDef(EffectiveNodeType.java:770)
at 
org.apache.jackrabbit.core.NodeImpl.getApplicablePropertyDefinition(NodeImpl.java:911)
at 
org.apache.jackrabbit.core.ItemManager.getDefinition(ItemManager.java:224)
at org.apache.jackrabbit.core.ItemData.getDefinition(ItemData.java:97)
at 
org.apache.jackrabbit.core.PropertyData.getPropertyDefinition(PropertyData.java:53)
at 
org.apache.jackrabbit.core.PropertyImpl.getDefinition(PropertyImpl.java:729)
at org.apache.jackrabbit.core.NodeImpl.setProperty(NodeImpl.java:2512)
at 
org.apache.sling.jcr.contentloader.internal.DefaultContentCreator.createProperty(DefaultContentCreator.java:435)
at 
org.apache.sling.jcr.contentloader.internal.DefaultContentCreator.createFileAndResourceNode(DefaultContentCreator.java:659)
at 
org.apache.sling.jcr.contentloader.internal.Loader.createFile(Loader.java:576)
at 
org.apache.sling.jcr.contentloader.internal.Loader.handleFile(Loader.java:462)
at 
org.apache.sling.jcr.contentloader.internal.Loader.installFromPath(Loader.java:409)
at 
org.apache.sling.jcr.contentloader.internal.Loader.installFromPath(Loader.java:404)
at 
org.apache.sling.jcr.contentloader.internal.Loader.installContent(Loader.java:275)
at 
org.apache.sling.jcr.contentloader.internal.Loader.registerBundleInternal(Loader.java:183)
at 
org.apache.sling.jcr.contentloader.internal.Loader.registerBundle(Loader.java:122)
at 
org.apache.sling.jcr.contentloader.internal.ContentLoaderService.bundleChanged(ContentLoaderService.java:146)
at 
org.apache.felix.framework.util.EventDispatcher.invokeBundleListenerCallback(EventDispatcher.java:800)

The problem seems to be that the createFileAndResourceNode method
attempts to create a nt:resource node, and set the jcr:lastModified
property to a Long value, whereas the jcr:lastModified property is
defined as a Date.

But this definition hasn't changed between Jackrabbit 1.6.0 and 1.6.2.

So why does this suddenly break? And, perhaps more interesting, why
did it work in the first place?

[1] https://issues.apache.org/jira/browse/JCR-2554

-- 
Vidar S. Ramdal  - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00 / +47 22 00 84 76
Quando omni flunkus moritatus!

Re: GSoC project

[Vidar Ramdal]

On Wed, May 26, 2010 at 12:35 PM, Federico Paparoni
 wrote:
> Hi all,
>
> In this period I explored Apache Sling features and now I'm starting with
> GSoC project.
> There is a blog where I will write every step done with project (
> http://davidgsoc.wordpress.com/). When GSoC will end, these posts will be
> reorganized to became a useful guide.
> I also opened an account on Google code (
> http://code.google.com/p/davidgsoc2010/) where I'll syncronize my project.
> The first milestone of this project will be a simple mini cms, with basic
> features:
>
> - Autentication for different user with different level
> - Administration panel to create/edit/delete content (there are a lot of JS
> WYSIWYG editor). The content can also have file attachments
> - Standard view of CMS (anonymous), with the possibility to populate
> different panel with different content (like a portlet container).
>
> The first milestone should be available for the midterm evaluation of GSoC
> (16 July).
> The second milestone will be more focused on the development of different
> features like:
>
>   - Notification when some documents are modified (JCR observation)
>   - ATOM and RSS feed of entries
>   - Search in the entries and in the attached files (Lucene integration
>   works ad default with Sling?)
>   - A stupid tag cloud for the entries submitted
>   - Also a synchronization of entries with svn as you told me (using a
>   library like SVNKit http://svnkit.com/)
>   - Future ideas
>
> I haven't a clear idea about the feature I will develop in the second
> milestone, so every comments/ideas/criticisms.

Looks like a fun and useful project. Don't hesitate to ask on this
list if (when) you run into problems.

-- 
Vidar S. Ramdal  - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00 / +47 22 00 84 76
Quando omni flunkus moritatus!

Re: Unable to add factory configs through config admin web console

[Vidar Ramdal]

>>> On 19.05.2010 10:31, Vidar Ramdal wrote:
>>>> I find myself unable to add factory configurations through the web
>>>> console. Can anyone else confirm this?
>>>>
>>>> To reproduce:
>>>> 1. Go to http://localhost:8080/system/console/configMgr
>>>> 2. Find the Apache Sling Logger Configuration factory configuration,
>>>> and click the "+" next to it
>>>> 3. Fill in the form
>>>> 4. Click Save
>>>>
>>>> Expected result:
>>>> - The new configuration is listed under "Apache Sling Logger Configuration"
>>>>
>>>> Actual result:
>>>> - The new configuration is not listed as expected. Instead, on the top
>>>> of the configuration list, I find an item named
>>>> [Temporary%20PID%20replaced%20by%20real%20PID%20upon%20save] which is
>>>> empty upon inspection.
>>>>
>>>> This occurs in both Chrome and Firefox.

>> On Wed, May 19, 2010 at 11:18 AM, Felix Meschberger  
>> wrote:
>>> What happends after reloading the page ?

> On 5/19/10 7:35 AM, Vidar Ramdal wrote:
>> Nothing, that is, the bogus item
>> [Temporary%20PID%20replaced%20by%20real%20PID%20upon%20save]  is
>> listed on top.

>>>> Is this a bug in the Felix web console, or something Sling specific?
>>> This would definitely be a bug in the webconsole.
>> OK, I'll look more into it - but in the mean time, is anyone else seeing 
>> this?

On Wed, May 19, 2010 at 3:36 PM, Justin Edelson  wrote:
> Confirming that I can reproduce this in Firefox, Chrome, and Safari with
> a clean trunk build of Sling (i.e. webconsole 3.0.0)

Thanks!

> Vidar-
> Do you want to file a bug about this?

Will do - I'll just work out a reduced testcase for it first.

-- 
Vidar S. Ramdal  - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00 / +47 21 531941, ext 2070
"Quando omni flunkus moritatus! "

Re: Unable to add factory configs through config admin web console

[Vidar Ramdal]

On Wed, May 19, 2010 at 11:18 AM, Felix Meschberger  wrote:
> Hi,
>
> On 19.05.2010 10:31, Vidar Ramdal wrote:
>> Hi;
>>
>> I find myself unable to add factory configurations through the web
>> console. Can anyone else confirm this?
>>
>> To reproduce:
>> 1. Go to http://localhost:8080/system/console/configMgr
>> 2. Find the Apache Sling Logger Configuration factory configuration,
>> and click the "+" next to it
>> 3. Fill in the form
>> 4. Click Save
>>
>> Expected result:
>> - The new configuration is listed under "Apache Sling Logger Configuration"
>>
>> Actual result:
>> - The new configuration is not listed as expected. Instead, on the top
>> of the configuration list, I find an item named
>> [Temporary%20PID%20replaced%20by%20real%20PID%20upon%20save] which is
>> empty upon inspection.
>>
>> This occurs in both Chrome and Firefox.
>
> What happends after reloading the page ?

Nothing, that is, the bogus item
[Temporary%20PID%20replaced%20by%20real%20PID%20upon%20save]  is
listed on top.

>> Is this a bug in the Felix web console, or something Sling specific?
> This would definitely be a bug in the webconsole.

OK, I'll look more into it - but in the mean time, is anyone else seeing this?


-- 
Vidar S. Ramdal  - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00 / +47 21 531941, ext 2070
"Quando omni flunkus moritatus! "

Unable to add factory configs through config admin web console

[Vidar Ramdal]

Hi;

I find myself unable to add factory configurations through the web
console. Can anyone else confirm this?

To reproduce:
1. Go to http://localhost:8080/system/console/configMgr
2. Find the Apache Sling Logger Configuration factory configuration,
and click the "+" next to it
3. Fill in the form
4. Click Save

Expected result:
- The new configuration is listed under "Apache Sling Logger Configuration"

Actual result:
- The new configuration is not listed as expected. Instead, on the top
of the configuration list, I find an item named
[Temporary%20PID%20replaced%20by%20real%20PID%20upon%20save] which is
empty upon inspection.

This occurs in both Chrome and Firefox.

Is this a bug in the Felix web console, or something Sling specific?

-- 
Vidar S. Ramdal  - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00 / +47 21 531941, ext 2070

Re: Application packaging

[Vidar Ramdal]

On Tue, May 11, 2010 at 4:30 PM, Federico Paparoni
 wrote:
> Hi all,
>
> I read the documentation available on the Sling website and tested the basic
> examples.
> Everything works, but now I want to create something like espblog, to better
> examine Sling features.
> I created a maven project and deployed it using the Felix console but it
> doesn't work.
> In this example I created some jsp but when i try to call them, the browser
> downloads it.
> In the log I can see
>
> 11.05.2010 16:18:10.516 *INFO* [FelixDispatchQueue] slingblog BundleEvent
> INSTALLED
> 11.05.2010 16:18:10.516 *INFO* [FelixDispatchQueue] slingblog BundleEvent
> RESOLVED
> 11.05.2010 16:18:10.548 *INFO* [Background Install
> C:\DOCUME~1\a155876\IMPOST~1\Temp\install1474139204158110668.tmp]
> org.apache.sling.jcr.co
> ntentloader.internal.ContentLoaderService createFile: Cannot find content
> type for created.html.jsp, using application/octet-stream
> 11.05.2010 16:18:10.704 *INFO* [Background Install
> C:\DOCUME~1\a155876\IMPOST~1\Temp\install1474139204158110668.tmp]
> org.apache.sling.jcr.co
> ntentloader.internal.ContentLoaderService createFile: Cannot find content
> type for home.html.jsp, using application/octet-stream
> 11.05.2010 16:18:10.735 *INFO* [Background Install
> C:\DOCUME~1\a155876\IMPOST~1\Temp\install1474139204158110668.tmp]
> org.apache.sling.jcr.co
> ntentloader.internal.ContentLoaderService createFile: Cannot find content
> type for new.html.jsp, using application/octet-stream
> 11.05.2010 16:18:10.986 *INFO* [FelixDispatchQueue] slingblog BundleEvent
> STARTED
>
> How can I tell Sling these are JSP?

I don't think you have to. Those messages are from the content loader,
which is the component responsible for registering the files in the
repository. That does not affect script resolution later.

You shouldn't request the JSP files directly from the browser, but
rather request a resource (like a JCR node) which has it's
sling:resourceType property set to correspond to a script.

-- 
Vidar S. Ramdal  - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00 / +47 21 531941, ext 2070

Re: Caching Support Request Filter

[Vidar Ramdal]

On Wed, Apr 28, 2010 at 5:23 PM, Felix Meschberger  wrote:
> Now, taken a step further: do we really want to build a cache into
> Sling ? Shouldn't we rather rely on some existing caching proxy for
> this, like Squid or mod_cache/mod_proxy ?

Thinking about this a bit more; instead of building a cache mecanism
ourselves, how about providing a good integration point for caching
proxies?

This component would be a filter or similar, which must track which
resources are being accessed during a request. The component would
register as a resource event listener, to be notified when resources
are changed, so that the corresponding request URIs can be
invalidated.
When invalidating a request URI, the component should call a pluggable
adapter (e.g. a SquidAdapter), which in turn will notify Squid of the
invalidation.

-- 
Vidar S. Ramdal  - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00 / +47 21 531941, ext 2070

Re: Caching Support Request Filter

[Vidar Ramdal]

On Wed, Apr 28, 2010 at 5:23 PM, Felix Meschberger  wrote:
> Hi,
>
> Wow !
>
> I didn't expect to have this discussion get in this direction, but excellent !
>
> For illustration what I originally had in mind, I have commited my
> prototype in [1].
>
> Please note, that this *only* is about setting the Last-Modified and
> Cache-Control headers.
>
> Now, taken a step further: do we really want to build a cache into
> Sling ? Shouldn't we rather rely on some existing caching proxy for
> this, like Squid or mod_cache/mod_proxy ?

Again from our project, we use Varnish [1] in front of our Sling app,
and then remove objects from Varnish when there's a resource change
event in Sling.

Caching HTTP proxies are highly optimized to do just that, and trying
to implement a good enough system in Sling seems to be duplicating
work.

What *would* be useful, is more low-level caching. Without having
investigated any such possibilities, I can think of resource
resolution, script results, access control ...

[1] http://varnish-cache.org/

-- 
Vidar S. Ramdal  - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00 / +47 21 531941, ext 2070

Re: Caching Support Request Filter

[Vidar Ramdal]

On Wed, Apr 28, 2010 at 1:13 PM, Felix Meschberger
 wrote:
> Hi all,
>
> I have been resonating with a collegue about a request level Filter
> for Sling to support caching.
>
> The idea (and partly implemented by a prototype) is to have the
> request filter setup default caching behaviour of the response (if the
> response is cacheable at, that is the request method must be GET and
> there are no request parameters):
>
> * The Cache-Control header is preset with values from configuration
> matching the request URI (or resource path)
> * The Last-Modified header is preset with the jcr:lastModified
> property of the requet's resource
> * Eager responding with 304/NOT MODIFIED if the If-Modified-Since
> header is set and a last modification time of the resource can be
> resolved.

The question is how useful such a filter would be if only the
last-modified date of the requested resource is used.

In our application at least, there is a large number of resources
involved when serving a request. Most CMSs list out menus, for
example, where the menu items are other resources. If one of those
resources have changed, or if there has been a new menu item created,
it means the menu will be out of date if the requested resource itself
is unmodified.

To solve this, we could introduce a resource tracker, which tracks
which resources are being invoked on a request. The latest
last-modified date of these resources will then be matched with the
requests If-Modified-Since header.

-- 
Vidar S. Ramdal  - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00 / +47 21 531941, ext 2070

Re: multiple websitest on same sling instance

[Vidar Ramdal]

(Cross-posting to dev@sling.apache.org)
>>>> On Tue, Apr 27, 2010 at 12:24 PM, Markus Blaurock  wrote:
>>>>> currently we have the need to run multiple websites on the same
>>>>> sling-instance. That is, serving the same or similar content in
>>>>> different ways, defined by the hostname.
>>>>> For this we would like to have a single pool of sling-app-servers and
>>>>> each one should be possible to serve all websites. Otherwise we would
>>>>> need to have one pool for each (small) site, which is not feasible.
>>>>>
>>>>> Our solution was to patch the sling SevletResolver (2.0.9) to accompany
>>>>> each entry in the search-path with a hostname (defined by a regular
>>>>> expression).
>>>>> Resolving a servlet would now evaluate the hostname to "create" a
>>>>> specific search-path for this hostname (with entries valid for this
>>>>> hostname).
>>>>> Probably this could be named "virtual hosts"?
>>>>>
>>>>> Whith this some questions arise for us:
>>>>>
>>>>> 1. does somebody have a similar requirement of running multiple websites
>>>>> on the same sling instance? Somebody like to share experience?
>>>>>
>>>>> 2. is there another possible (easier?) solution for our problem?
>>>>>
>>>>> 3. would this be a feature for sling in general?
>>>>>
>>>>> What do you think?

>>> Vidar Ramdal schrieb:
>>>> Already Sling supports at least parts of your requirements.
>>>> Take a look at:
>>>> http://sling.apache.org/site/mappings-for-resource-resolution.html

>> On Tue, Apr 27, 2010 at 1:25 PM, Markus Blaurock  wrote:
>>> we thought of that, but it only works for the first request coming
>>> from the server. e.g. if we include another resource inside a resource
>>> then the hostname is no longer available and the default servlets will
>>> be found.
>>>
>>> The ResourceResolver.resolve()-Method gets called with null
>>> HttpRequest-Parameter
>>> (in Sling-Jsp-Tag-Support) - the
>>> ServerletResolver.resolveServlet()-Method gets called every time with
>>> the HttpRquest and we just used it.

> Vidar Ramdal schrieb:
>> Ok, so you want not only host-specific content, but also host-specific
>> rendering (servlets and scripts) - is that right?
>>
>> In that case, you'll currently have to roll your own ServletResolver,
>> but I'd say such a feature would be a nice addition to Sling.
>>
>> Felix has written up a draft for a "multitenancy" concept, that you
>> might find interesting:
>> https://cwiki.apache.org/SLING/multitenancy-support.html

On Tue, Apr 27, 2010 at 2:25 PM, Markus Blaurock  wrote:
> yes, exactly, host-specific-rendering.
>
> The "multitenancy" concept also perfectly fits our problem.
>
> How can this concept change its status from DRAFT to "we will do it like
> this" ?

You can start by filing a "new feature" issue at
https://issues.apache.org/jira/ - and then, hope that someone picks it
up, or start coding yourself :)

If you can come up with a backwards-compliant patch, IMO it will have
a good chance of being accepted.

-- 
Vidar S. Ramdal  - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00 / +47 21 531941, ext 2070

Re: Set of released Sling bundles working together?

[Vidar Ramdal]

> On Thu, Apr 22, 2010 at 6:27 PM, Bertrand Delacretaz
>  wrote:
>> Hi Vidar,
>>
>> On Thu, Apr 15, 2010 at 11:32 AM, Vidar Ramdal  wrote:
>>> ...does anyone know a full set of recently released Sling bundles
>>> that are known to work together?...
>>
>> I'll try to break this loud silence ;-)
>>
>> I think starting with the launchpad from trunk, and going back to the
>> last released version of each bundle is the way to go. If that leads
>> to missing dependencies, as your tests seem to indicate, I'd suggest
>> releasing the minimal set of bundles that fixes this problem, and then
>> make a launchpad release. Once that's done, repeat at very regular
>> intervals (every 2 months?) to avoid the problem in the future.
>>
>> I have no idea how much work "releasing the minimal set of bundles"
>> represents now, maybe you could post more details about your tests so
>> that we can collectively look at what's needed?

On Thu, Apr 22, 2010 at 9:30 PM, Vidar Ramdal  wrote:
> [...]

There's an inconcistency with these two:

> - o.a.s.sling.scripting.core 2.0.10
> - o.a.s.jcr.resource 2.0.6

Since SLING-1304 [1], the currentNode binding is no longer set in
scripting.core, but instead in jcr.resource. This means that running
these two bundles in those versions leaves me with no currentNode
binding.

PS: Justin - SLING-1304 does not have the 'version' field set - we
should probably set it, so that the issue will be listed in the
generated release notes. It seems the change affects scripting.core
2.0.10 and jcr.resource 2.0.8 - can you confirm?

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

-- 
Vidar S. Ramdal  - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00 / +47 21 531941, ext 2070

Re: Set of released Sling bundles working together?

[Vidar Ramdal]

On Thu, Apr 22, 2010 at 9:38 PM, Justin Edelson  wrote:
> Two comments:
>
> o.a.s.jcr.webconsole probably doesn't deserve to be in the default
> bundle list. I haven't been able to put nearly enough time into this to
> make it useful.
>
> You don't need tika unless you're running Jackrabbit 2, but I don't
> think it hurts anything to have it included.

OK, thanks!



-- 
Vidar S. Ramdal  - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00 / +47 21 531941, ext 2070

Re: Set of released Sling bundles working together?

[Vidar Ramdal]

On Thu, Apr 22, 2010 at 6:27 PM, Bertrand Delacretaz
 wrote:
> Hi Vidar,
>
> On Thu, Apr 15, 2010 at 11:32 AM, Vidar Ramdal  wrote:
>> ...does anyone know a full set of recently released Sling bundles
>> that are known to work together?...
>
> I'll try to break this loud silence ;-)
>
> I think starting with the launchpad from trunk, and going back to the
> last released version of each bundle is the way to go. If that leads
> to missing dependencies, as your tests seem to indicate, I'd suggest
> releasing the minimal set of bundles that fixes this problem, and then
> make a launchpad release. Once that's done, repeat at very regular
> intervals (every 2 months?) to avoid the problem in the future.
>
> I have no idea how much work "releasing the minimal set of bundles"
> represents now, maybe you could post more details about your tests so
> that we can collectively look at what's needed?

Yes, I think I have a somewhat working set now. There are still a few
snapshot bundles, but at least one of them (commons.osgi) is about to
be released (thanks, Justin). A couple of others (jcr.webconsole and
webconsolebranding) are not important.

My focus has been to get a working installation, so there might very
well be newer versions of some bundles that will work.

Anyway, here's what I've got so far:

Start level 1:
- o.a.s.commons.log 2.0.6

Start level 5:
- o.a.f.webconsole 3.0.0
- o.a.f.webconsole.plugins.event 1.0.2
- o.a.f.webconsole.plugins.memoryusage 1.0.0
- o.a.s.commons.json 2.0.4-incubator
- o.a.s.extensions.threaddump 0.2.0
- o.a.s.extensions.webconsolebranding 0.0.1-SNAPSHOT
- o.a.s.jcr.webconsole 1.0.0-SNAPSHOT
- commons-collections 3.2.1

Start level 10:
- o.a.f.configadmin 1.2.4
- o.a.f.eventadmin 1.0.0
- o.a.f.metatype 1.0.4
- o.a.f.scr 1.4.0
- o.a.s.jcr.api 2.0.2-incubator

Start level 12:
- pax-web-service 0.6.0

Start level 14:
- commons-io 1.4
- o.a.s.jcr.jackrabbit.server 2.0.6
- jackrabbit-api 1.6.0
- jackrabbit-jcr-commons 1.5.5
- jackrabbit-jcr-rmi 1.5.0
- o.a.s.jcr.base 2.0.6

Start level 16:
- o.a.s.jcr.jackrabbit.accessmanager 2.0.4
- o.a.s.jcr.jackrabbit.usermanager 2.0.4
- o.a.s.jcr.webdav 2.0.8
- tika-bundle 0.6

Start level 17:
- sanselan 0.97-incubator
- mail (o.a.f.commons) 1.4.0-0001
- o.a.s.runmode 2.0.3-SNAPSHOT
- o.a.s.jcr.jcrinstall 3.0.0-SNAPSHOT
- o.a.s.osgi.installer 3.0.0-SNAPSHOT

Start level 20:
- o.a.s.commons.threads 3.0.0
- o.a.s.commons.scheduler 2.2.0
- commons-fileupload 1.2.1
- commons-lang 2.5
- o.a.f.http.whiteboard 2.0.4
- o.a.s.adapter 2.0.4
- o.a.s.api 2.0.8
- o.a.s.bundleresource.impl 2.0.4-incubator
- o.a.s.commons.auth 0.9.0-SNAPSHOT
- o.a.s.commons.classloader 1.1.4
- o.a.s.commons.mime 2.1.4
- o.a.s.commons.osgi 2.0.5-SNAPSHOT (2.0.6 about to be released)
- o.a.s.engine 2.0.6
- o.a.s.fsresource 1.0.0
- o.a.s.httpauth 2.0.4-incubator
- o.a.s.jcr.classloader 3.1.0
- o.a.s.jcr.contentloader 2.0.6
- o.a.s.jcr.ocm 2.0.4-incubator
- o.a.s.jcr.resource 2.0.6
- o.a.s.launchpad.content 2.0.4-incubator
- o.a.s.sling.scripting.api 2.1.0
- o.a.s.sling.scripting.core 2.0.10
- o.a.s.sling.scripting.javascript 2.0.6
- o.a.s.scripting.jsp 2.0.8
- o.a.s.scripting.jsp.taglib 2.0.6
- o.a.s.servlets.get 2.0.8
- o.a.s.servlets.post 2.0.4-incubator
- o.a.s.servlets.resolver 2.0.8

This set gives me no unresolved dependencies, and all components start.
AFAIK all these bundles are available from repository.apache.org.

-- 
Vidar S. Ramdal  - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00 / +47 21 531941, ext 2070

Re: [VOTE] Release Apache Sling Launchpad Maven Plugin 2.0.6

[Vidar Ramdal]

On Thu, Apr 22, 2010 at 1:54 AM, Ian Boston  wrote:
> -1,
> I get a problem when downloading

Me too:
Vidars-MacBook:sling-clean vramdal$ sh check_staged_release.sh 003
~/Desktop/sling-staging

   DOWNLOAD STAGED REPOSITORY

https://repository.apache.org/content/repositories/orgapachesling-003/org/apache/sling/:
02:13:18 ERROR 404: Not Found.
unlink: No such file or directory



-- 
Vidar S. Ramdal  - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00 / +47 21 531941, ext 2070

Re: [VOTE] Release Apache Sling Launchpad Base 2.2.0

[Vidar Ramdal]

On Wed, Apr 21, 2010 at 4:16 PM, Justin Edelson  wrote:
> We solved 14 issues in this release:
> https://issues.apache.org/jira/browse/SLING/fixforversion/12314411
>
> There are still one outstanding issue:
> https://issues.apache.org/jira/browse/SLING/fixforversion/12314956
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-002/
>
> You can use this UNIX script to download the release and verify the
> signatures:
> http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh
>
> Usage:
> sh check_staged_release.sh 002 /tmp/sling-staging
>
> Please vote to approve this release:
>
>  [ ] +1 Approve the release
>  [ ]  0 Don't care
>  [ ] -1 Don't release, because ...
>
> This vote will be open for 72 hours.

+1

-- 
Vidar S. Ramdal  - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00 / +47 21 531941, ext 2070

Re: [VOTE] Release Apache Sling Commons OSGi 2.0.[VOTE] Release Apache Sling Commons OSGi 2.0.6

[Vidar Ramdal]

On Wed, Apr 21, 2010 at 4:05 PM, Justin Edelson  wrote:
> We solved 2 issues in this release:
> https://issues.apache.org/jira/browse/SLING/fixforversion/12314516
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-001/
>
> You can use this UNIX script to download the release and verify the
> signatures:
> http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh
>
> Usage:
> sh check_staged_release.sh 001 /tmp/sling-staging
>
> Please vote to approve this release:
>
>  [ ] +1 Approve the release
>  [ ]  0 Don't care
>  [ ] -1 Don't release, because ...
>
> This vote will be open for 72 hours.

+1


-- 
Vidar S. Ramdal  - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00 / +47 21 531941, ext 2070

Fwd: Trouble matching Felix bundles in launchpad

[Vidar Ramdal]

> On 4/21/10 11:14 AM, Vidar Ramdal wrote:
>> [...]
>> Also, the values of the sling.properties is overwritten on each
>> startup, by values from the launchpad base bundle. Is there an easy
>> way to avoid that, without hacking launchpad base?

On Wed, Apr 21, 2010 at 5:27 PM, Justin Edelson  wrote:
> This shouldn't be the case. What happens is that:
> 1) an empty properties map is created
> 2) the default properties are loaded (from the base bundle)
> 3) anything in ${sling.home}/sling.properties is overlaid on the
> properties map
> 4) if system properties aren't be excluded, they're overlaid on the
> properties map
> 5) the properties map is written to ${sling.home}/sling.properties
>
> then the actual properties map used by Sling is created by resolving any
> variable substitution in the properties map.
>
> (see http://bit.ly/8XmHpT)
>
> In other words, you can manually edit ${sling.home}/sling.properties at
> any time and the updates will be seen the next time Sling starts.

Ah, I was running the 2.0.4-incubator version of launchpad.base. When
updating to the current 2.0.5 snapshot, the sling.properties file is
no longer reverted (but rewritten with the desired properties).

Thanks for your help!

--
Vidar S. Ramdal  - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00 / +47 21 531941, ext 2070

Re: Trouble matching Felix bundles in launchpad

[Vidar Ramdal]

>
> Justin
>
> On 4/21/10 10:15 AM, Vidar Ramdal wrote:
>> I'm trying to set up my own launchpad build, using maven-launchpad-plugin.
>>
>> I'm having trouble getting all Felix components to play nice together.
>> All components fail to start. The log shows:
>>
>> 21.04.2010 15:50:39.094 *INFO* [FelixDispatchQueue]
>> org.apache.felix.metatype BundleEvent STARTED
>> 21.04.2010 15:50:39.118 *INFO* [FelixStartLevel] org.apache.felix.scr
>> Service [Declarative Services Management Agent,29] ServiceEvent
>> REGISTERED
>> 21.04.2010 15:50:39.119 *INFO* [FelixStartLevel] org.apache.felix.scr
>> Service [Declarative Services Configuration Support Listener,30]
>> ServiceEvent REGISTERED
>> 21.04.2010 15:50:39.127 *WARN* [FelixStartLevel]
>> org.apache.felix.configadmin Service
>> [org.apache.felix.cm.ConfigurationAdmin,26] Service
>> org.apache.felix.scr.impl.config.scrconfiguratio...@55d7fc31 is not a
>> ManagedService
>> 21.04.2010 15:50:39.128 *INFO* [FelixStartLevel] org.apache.felix.scr
>> Service [org.apache.felix.scr.ScrService,31] ServiceEvent REGISTERED
>> 21.04.2010 15:50:39.131 *INFO* [FelixStartLevel] org.apache.felix.scr
>> Version = 1.4.0
>> 21.04.2010 15:50:39.156 *ERROR* [FelixStartLevel]
>> org.apache.sling.jcr.webconsole
>> [org.apache.sling.jcr.webconsole.internal.NamespaceConfigurationPrinter]
>> Cannot register Component (java.lang.ClassCastException:
>> org.apache.felix.cm.impl.ConfigurationAdminImpl cannot be cast to
>> org.osgi.service.cm.ConfigurationAdmin) java.lang.ClassCastException:
>> org.apache.felix.cm.impl.ConfigurationAdminImpl cannot be cast to
>> org.osgi.service.cm.ConfigurationAdmin
>>       at 
>> org.apache.felix.scr.impl.config.ConfigurationComponentRegistry.createComponentHolder(ConfigurationComponentRegistry.java:104)
>>       at 
>> org.apache.felix.scr.impl.BundleComponentActivator.loadDescriptor(BundleComponentActivator.java:244)
>>       at 
>> org.apache.felix.scr.impl.BundleComponentActivator.initialize(BundleComponentActivator.java:147)
>>       at 
>> org.apache.felix.scr.impl.BundleComponentActivator.(BundleComponentActivator.java:111)
>>       at 
>> org.apache.felix.scr.impl.Activator.loadComponents(Activator.java:238)
>>       at 
>> org.apache.felix.scr.impl.Activator.loadAllComponents(Activator.java:194)
>>       at org.apache.felix.scr.impl.Activator.start(Activator.java:108)
>>       at 
>> org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:589)
>>       at org.apache.felix.framework.Felix.startBundle(Felix.java:1458)
>>       at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:984)
>>       at 
>> org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:263)
>>       at java.lang.Thread.run(Thread.java:637)
>>
>>
>> The stacktrace is repeated for each component as they try to start.
>>
>> From what I can see, the org.osgi.service.cm package is exported by
>> two bundles: The System bundle, and the org.apache.felix.configadmin
>> bundle.
>> When I disable the org.apache.felix.configadmin the log messages go
>> away, but now all components that try to use ConfigAdmin fails
>> (naturally).
>>
>> Is there a way to resolve this?

On Wed, Apr 21, 2010 at 4:28 PM, Justin Edelson  wrote:
> org.osgi.service.cm should not be exported by the system bundle. These
> should be the only org.osgi.* packages exported by the system bundle:
>
> org.osgi.framework,version=1.5.0
> org.osgi.framework.hooks.service,version=1.0.0
> org.osgi.framework.launch,version=1.0.0
> org.osgi.service.packageadmin,version=1.2.0
> org.osgi.service.startlevel,version=1.1.0
> org.osgi.service.url,version=1.0.0
> org.osgi.util.tracker,version=1.4.0
>
> I'd suggest taking a look at your sling.properties file and see if
> you're specifying that org.osgi.service.cm be exported from the system
> bundle.

In sling.properties, org.osgi.service.cm is listed on the
osgi-compendium-services line, which is again referenced from
org.osgi.framework.system.packages=${osgi-core-packages},
${osgi-compendium-services}, ${jre-${java.specification.version}}
${org.apache.sling.launcher.system.packages}

I guess this means it is exported?

Also, the values of the sling.properties is overwritten on each
startup, by values from the launchpad base bundle. Is there an easy
way to avoid that, without hacking launchpad base?

-- 
Vidar S. Ramdal  - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00 / +47 21 531941, ext 2070

Trouble matching Felix bundles in launchpad

[Vidar Ramdal]

I'm trying to set up my own launchpad build, using maven-launchpad-plugin.

I'm having trouble getting all Felix components to play nice together.
All components fail to start. The log shows:

21.04.2010 15:50:39.094 *INFO* [FelixDispatchQueue]
org.apache.felix.metatype BundleEvent STARTED
21.04.2010 15:50:39.118 *INFO* [FelixStartLevel] org.apache.felix.scr
Service [Declarative Services Management Agent,29] ServiceEvent
REGISTERED
21.04.2010 15:50:39.119 *INFO* [FelixStartLevel] org.apache.felix.scr
Service [Declarative Services Configuration Support Listener,30]
ServiceEvent REGISTERED
21.04.2010 15:50:39.127 *WARN* [FelixStartLevel]
org.apache.felix.configadmin Service
[org.apache.felix.cm.ConfigurationAdmin,26] Service
org.apache.felix.scr.impl.config.scrconfiguratio...@55d7fc31 is not a
ManagedService
21.04.2010 15:50:39.128 *INFO* [FelixStartLevel] org.apache.felix.scr
Service [org.apache.felix.scr.ScrService,31] ServiceEvent REGISTERED
21.04.2010 15:50:39.131 *INFO* [FelixStartLevel] org.apache.felix.scr
Version = 1.4.0
21.04.2010 15:50:39.156 *ERROR* [FelixStartLevel]
org.apache.sling.jcr.webconsole
[org.apache.sling.jcr.webconsole.internal.NamespaceConfigurationPrinter]
Cannot register Component (java.lang.ClassCastException:
org.apache.felix.cm.impl.ConfigurationAdminImpl cannot be cast to
org.osgi.service.cm.ConfigurationAdmin) java.lang.ClassCastException:
org.apache.felix.cm.impl.ConfigurationAdminImpl cannot be cast to
org.osgi.service.cm.ConfigurationAdmin
at 
org.apache.felix.scr.impl.config.ConfigurationComponentRegistry.createComponentHolder(ConfigurationComponentRegistry.java:104)
at 
org.apache.felix.scr.impl.BundleComponentActivator.loadDescriptor(BundleComponentActivator.java:244)
at 
org.apache.felix.scr.impl.BundleComponentActivator.initialize(BundleComponentActivator.java:147)
at 
org.apache.felix.scr.impl.BundleComponentActivator.(BundleComponentActivator.java:111)
at 
org.apache.felix.scr.impl.Activator.loadComponents(Activator.java:238)
at 
org.apache.felix.scr.impl.Activator.loadAllComponents(Activator.java:194)
at org.apache.felix.scr.impl.Activator.start(Activator.java:108)
at 
org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:589)
at org.apache.felix.framework.Felix.startBundle(Felix.java:1458)
at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:984)
at 
org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:263)
at java.lang.Thread.run(Thread.java:637)


The stacktrace is repeated for each component as they try to start.

>From what I can see, the org.osgi.service.cm package is exported by
two bundles: The System bundle, and the org.apache.felix.configadmin
bundle.
When I disable the org.apache.felix.configadmin the log messages go
away, but now all components that try to use ConfigAdmin fails
(naturally).

Is there a way to resolve this?

-- 
Vidar S. Ramdal  - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00 / +47 21 531941, ext 2070

Set of released Sling bundles working together?

[Vidar Ramdal]

The current Sling release is quite old (May 2009), and my project
currently has a number of dependencies to Sling SNAPSHOT bundles (most
of them are old versions), which I want to get rid of.

I have tried two approaches for this:
- Checking out and running the Sling Launchpad. This, of course, gives
me snapshot versions of all bundles. I can then try to replace all
bundles with released versions.
- Download and run the released standalone JAR, then updating bundles
to the newest available released versions

However, both of these approaches lead to a lot of unresolved
dependencies, which I'm not able to resolve.

So, does anyone know a full set of recently released Sling bundles
that are known to work together?

-- 
Vidar S. Ramdal  - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00 / +47 21 531941, ext 2070

ANN: Sling-based Idium Web released

[Vidar Ramdal]

Just thought you would like to know that a new Sling-based product has
been released.

Added some lines to the wiki:
http://cwiki.apache.org/SLING/who-is-using-sling-.html

-- 
Vidar S. Ramdal  - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00 / +47 21 531941, ext 2070

Re: [RT] Using strong patterned prefixes (SPP) for exception class names

[Vidar Ramdal]

On Thu, Apr 1, 2010 at 9:12 AM, Bertrand Delacretaz
 wrote:
> Hi,
>
> I've been thinking about the information conveyed by exceptions, and I
> think we could do much better with naming them.
>
> Using the unchecked SlingException as a base is certainly a good idea,
> but stack traces often get lost, and end users often have a hard time
> reporting exactly what happened when they get an exception.
>
> To fix this, I suggest using a class naming pattern like:
>
> package foo.bar;
>
> class Wiz {
>  static class
>    PackageFooBarClassWizMethodGetSomethingProblemComputeException
>    extends SlingException {
>    ...
>  }
>
>  void getSomething() {
>    if(...something bad happened...) {
>      throw new
> PackageFooBarClassWizMethodGetSomethingProblemComputeException (...);
>   }
> }
>
> Using a strong naming convention like this for exceptions would make
> it much easier to find out where a problem happened, without having to
> hunt for stack traces. Any Sling user can then report precisely where
> a problem happened.
>
> In the above example, the
> PackageFooBarClassWizMethodGetSomethingProblemComputeException name
> makes it very clear that there was a problem in the getSomething
> method of the Wiz class in package foo.bar, and the problem is a
> ComputeException. Bit of a longish name, but we all have cool IDEs,
> right?
>
> Exceptions classes like
> PackageFooBarClassWizMethodGetSomethingProblemComputeException should
> probably be generated, as it's somewhat boring code to type. We can
> think about creating a few annotations, a java code preprocessor or
> bytecode generator, a maven plugin and some javadoc extensions if we
> agree on the basic idea. Maybe we should organize a hackathon soon to
> design this, as it's a big change in the exceptions paradigm. And
> maybe create a new JSR, as we want Sling to be based on standards.
> Again, if we agree on the basics. Thinking about it...maybe JVMs could
> generate those class names based on where the Exception is thrown.
> Hmm
>
> I don't think I've seen this used in any java software yet, so it
> might look unusual but being different is a great way of making Sling
> more visible. I'm going to reserve the spp.org domain ASAP as we might
> need a place to describe this new revolutionary technique. Tell them
> you saw it here first!
>
> WDYT?

This sounded so great to me, and knowing how much Bertrand appreciates
automated tests, I went ahead and implemented tests for all exceptions
we will possibly need.

Take a look (esp you, Bertrand), and tell me what you think:
http://tinyurl.com/2g9mqh

-- 
Vidar S. Ramdal  - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00 / +47 21 531941, ext 2070

Re: Rewrite MapEntries to OSGI EventHandler

[Vidar Ramdal]

>> Vidar Ramdal  wrote
>>> Currently o.a.s.jcr.resource.internal.helper.MapEntries (which
>>> maintain domain mappings) is a javax.jcr.observation.EventListener.
>>> When an event occur somewhere in the /etc/map tree, the MapEntries map
>>> is updated.
>>>
>>> In my project I need to provide domain mappings under /etc/map as
>>> non-JCR resources. MapEntries uses the Resource API to iterate through
>>> the resources under /etc/map, so it is quite easy to use resources
>>> instead of nodes to specify domain mappings.
>>> Except for one thing: MapEntries is only updated on a JCR event, so I
>>> currently need to fire that manually when one of my resources has
>>> changed.
>>>
>>> Does it make sense to rewrite MapEntries to be a OSGi EventHandler instead?

>On Wed, Mar 24, 2010 at 10:32 AM, Carsten Ziegeler  
>wrote:
>> I think it makes sense, especially as we are planning to make the
>> resource resolver usable in non jcr environments.

On Wed, Mar 24, 2010 at 11:10 AM, Felix Meschberger  wrote:
> Agreed completely.

Great => https://issues.apache.org/jira/browse/SLING-1463

-- 
Vidar S. Ramdal  - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00 / +47 21 531941, ext 2070

Rewrite MapEntries to OSGI EventHandler

[Vidar Ramdal]

Currently o.a.s.jcr.resource.internal.helper.MapEntries (which
maintain domain mappings) is a javax.jcr.observation.EventListener.
When an event occur somewhere in the /etc/map tree, the MapEntries map
is updated.

In my project I need to provide domain mappings under /etc/map as
non-JCR resources. MapEntries uses the Resource API to iterate through
the resources under /etc/map, so it is quite easy to use resources
instead of nodes to specify domain mappings.
Except for one thing: MapEntries is only updated on a JCR event, so I
currently need to fire that manually when one of my resources has
changed.

Does it make sense to rewrite MapEntries to be a OSGi EventHandler instead?

-- 
Vidar S. Ramdal  - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00 / +47 21 531941, ext 2070

Re: Creating a Sling Utilities Bundle (was: [jira] Updated: (SLING-1336) Let SlingPostServlet return JSON)

[Vidar Ramdal]

On Wed, Mar 10, 2010 at 7:55 AM, Felix Meschberger  wrote:
> Hi all,
>
> We currently have a multi-faceted issue: We have the Sling API bundle
> containing a number of utility classes (HtmlResponse, ResourceUtil). In
> addition there are two utility classes in the Engine bundle
> (RequestUtil, ResourceUtil) which are of general interest.
>
> The problem with the locations of these classes are (1) mixing
> implementations into an API bundle is problematic, (2) extending
> implementations means increasing the API version, (3) using the Engine
> bundle utilities creates a dependency on the Engine bundle.
>
> I think we should create a new Utilities bundle which will host these
> utility classes.
>
> The classes are simply copied and then further developed in the new
> utilities bundle while the old classes are simply deprecated and removed
> in future versions. This will keep the classes distinct and not create a
> dependency to the new util bundle in the API bundle.
>
> WDYT ?

In general, when a class/package/bundle is named something *Util, I
usually suspect that it is a catch-all for stuff that doesn't
naturally belong anywhere else. So perhaps we should find a better
name, and possibly divide it into multiple units.
In the case of RequestUtil, ideally, those methods would be moved to
SlingHttpServletRequest, but I guess there are reasons why they're not
already there.

That said, I'm all for moving util stuff out of Engine.

I think moving HtmlResponse will be hard, since it is used as
parameter for SlingPostOperations, so there will be huge backward
compatibility trouble. If we are to move it anyway, I'd really like to
rewrite it to an interface "PostResponse", which will be implemented
by a (new) HtmlResponse class and the newly-introduced JsonResponse.

-- 
Vidar S. Ramdal  - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00 / +47 21 531941, ext 2070

Edit permisson for SLINGxSITE

[Vidar Ramdal]

Hi,

I'd like to update the doc for SlingPostServlet [1] to reflect
SLING-1336 [2], but it seems I don't have edit access to that wiki
space.
Can someone grant me that permission, please?

[1] 
http://cwiki.apache.org/confluence/display/SLINGxSITE/Manipulating+Content+-+The+SlingPostServlet+%28servlets.post%29
[2] https://issues.apache.org/jira/browse/SLING-1336

-- 
Vidar S. Ramdal  - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00 / +47 21 531941, ext 2070

Re: AuthenticationPlugin with external users

[Vidar Ramdal]

On Tue, Mar 9, 2010 at 8:30 PM, D. Stuart Freeman
 wrote:
> I've got an AuthenticationHandler and I'd like to allow users to log in
> without doing any further registration.  My understanding is that my
> AuthenticationPlugin will have to create accounts in JCR for users if
> they don't exist already.

That is not necessarily true. If you have a custom LoginModulePlugin
[1], you can lookup user data from anywhere - it doesn't have to be
from JCR. The LoginModulePlugin then instantiates your custom
AuthenticationPlugins on LoginModulePlugin.getAuthentication().

> Will it work (and is it advisable) to do
> something like:
>
>  userManager.createUser(name, RandomStringUtils.random(32), principal);
>
> or am I completely misunderstanding something?

I'd say, if you already have your user data somewhere else (like an
external database or LDAP directory), don't replicate that data in
Jackrabbit's UserManager. In fact, don't use UserManager at all
(except, perhaps, for the pre-defined admin and anonymous users).
Instead, implement a LoginModulePlugin to use your external source.

[1] 
http://sling.apache.org/apidocs/sling5/org/apache/sling/jcr/jackrabbit/server/security/LoginModulePlugin.html


-- 
Vidar S. Ramdal  - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00 / +47 21 531941, ext 2070

Re: [RT] ResourceTypeProvider

[Vidar Ramdal]

On Tue, Mar 9, 2010 at 10:06 AM, Carsten Ziegeler  wrote:
> Bertrand Delacretaz  wrote
>> On Tue, Mar 9, 2010 at 9:34 AM, Carsten Ziegeler  
>> wrote:
>>> Is everyone fine if we add the following interface to the API?
>>>
>>> interface ResourceDecorator {
>>>    Resource decorade(Resource)
>>>    Resource decorade(Resource, HttpServletRequest)
>>> }
>>
>> Why not SlingHttpServletRequest?
> We use HttpServletRequest in the resource resolver as well :)
>
>> +1 anyway if there's a good reason to use HttpServletRequest.
>>
>> (and typo: should be "decorate" of course)

+1 for introducing this interface

("Vidam" would probably vote for "decorade" :)

-- 
Vidar S. Ramdal  - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00 / +47 21 531941, ext 2070

Re: [RT] ResourceTypeProvider

[Vidar Ramdal]

On Mon, Mar 8, 2010 at 4:57 PM, Carsten Ziegeler  wrote:
> Vidar Ramdal  wrote
>> On Mon, Mar 8, 2010 at 3:32 PM, Carsten Ziegeler  
>> wrote:
>>> Justin Edelson  wrote
>>>> Hi all,
>>>> I'm afraid I'm missing something here. With this new interface, who is
>>>> responsible for setting the resource type and super type?
>>> Like before, it's the task of the resource resolver factory. However,
>>> after the resource is created with resource type, super type, metadata
>>> etc. all ResourceDecorators are queried (ordered by service ranking).
>>> They get the current resource and either return it directly (if they
>>> don't want to decorate it) or create a new resource - which usually is
>>> just a decoration - but it could also be a completly different resource
>>> with different behaviour.
>>
>> What information will be made available to ResourceDecorators?
>> I can easily see cases where you'd want a given resource decorated
>> only in certain circumstances, like when a specific request query
>> parameter is present.
>>
> Hmm, ok, good question. So far, we only pass in the Resource - so the
> decorator can access all resource related information - of course this
> would not include a query parameter or something like that.
>
> I'm not sure if we should pass in more parameters like the request etc.
> We could do this however these additional things would be optional as
> the resource resolver may be used out of the scope of a request.

Yeah, that approach makes sense for ResourceResolver, with
ResourceResolver.resolve(String) vs
ResourceResolver.resolve(HttpServletRequest, String). Maybe that would
be good for ResourceDecorator too.

-- 
Vidar S. Ramdal  - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00 / +47 21 531941, ext 2070

Re: [RT] ResourceTypeProvider

[Vidar Ramdal]

On Mon, Mar 8, 2010 at 3:32 PM, Carsten Ziegeler  wrote:
> Justin Edelson  wrote
>> Hi all,
>> I'm afraid I'm missing something here. With this new interface, who is
>> responsible for setting the resource type and super type?
> Like before, it's the task of the resource resolver factory. However,
> after the resource is created with resource type, super type, metadata
> etc. all ResourceDecorators are queried (ordered by service ranking).
> They get the current resource and either return it directly (if they
> don't want to decorate it) or create a new resource - which usually is
> just a decoration - but it could also be a completly different resource
> with different behaviour.

What information will be made available to ResourceDecorators?
I can easily see cases where you'd want a given resource decorated
only in certain circumstances, like when a specific request query
parameter is present.

-- 
Vidar S. Ramdal  - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00 / +47 21 531941, ext 2070

Re: [VOTE] Remove JcrResourceTypeProvider interface

[Vidar Ramdal]

On Mon, Mar 8, 2010 at 3:12 PM, Carsten Ziegeler  wrote:
> Hi,
>
> in order to finish our recent discussions about the
> JcrResourceTypeProvider and alternatives, I call for a vote to remove
> the current JcrResourceTypeProvider interface completly.
>
> As discussed we'll add a new functionality, the ResourceDecorator, which
> has a more general approach and covers more use cases.
>
> If we agree to remove the JcrResourceTypeProvider this would break
> potential implementations - however, there shouldn't be that many and
> converting those implementations to the ResourceDecorator interface
> should be easy.
>
> So please cast your votes.

+1

-- 
Vidar S. Ramdal  - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00 / +47 21 531941, ext 2070

Re: Let SlingPostServlet return JSON (WAS: Re: Client JSon Calls)

[Vidar Ramdal]

>>> On 08.03.2010 09:08, Vidar Ramdal wrote:
>>>> On Thu, Jan 28, 2010 at 3:10 PM, Vidar Ramdal  wrote:
>>>>> Finally, we implement the logic for choosing either sendHtml() or
>>>>> sendJson(), based on:
>>>>> 1. The format of the posted data - if JSON is posted (SLING-1172),
>>>>> return JSON, otherwise return HTML
>>>>> 2. The Accept HTTP header - if set to "application/json" return JSON,
>>>>> otherwise return HTML
>>>>> 3. Possibly also an :accept form field, with the same value as the
>>>>> HTTP header, in case it is proven that setting the HTTP header does
>>>>> not work in some browsers
>>>>
>>>> I have a patch for this ready at
>>>> https://issues.apache.org/jira/secure/ManageAttachments.jspa?id=12446912
>>>>
>>>> Here's how it's implemented:
>>>> 1. A class JSONResponse which extends HtmlResponse (for backward 
>>>> compatibility)
>>>> 2. A class MediaRangeList for parsing the HTTP Accept header
>>>> 3. A method SlingPostServlet.createHtmlResponse for determining which
>>>> format (HTML/JSON) to return to the client
>>>>
>>>> The JSON format is kept as close to the HTML format as possible.
>>>>
>>>> JSON is only returned if the client sends "application/json" in the
>>>> Accept header, with a greater preference than text/html. Also, the
>>>> Accept header can be simulated by a the :http-equiv-accept query
>>>> parameter.
>>>> I dropped the automatic return of JSON on JSON posts (SLING-1172) - I
>>>> think the client should specify application/json in Accept anyway, if
>>>> it wants JSON returned.
>>>>
>>>> WDYT? Is this a sensible way of implementing this?

>> On Mon, Mar 8, 2010 at 9:44 AM, Felix Meschberger  wrote:
>>> It hink this is basically a good idea. Esp. having the overwrite parameter.
>>>
>>> Though for symmetry with GET requests, where the .json extension ask for
>>> a JSON response, we might want to also support this for POST ... Don't
>>> have a very string preference, though.

> On 08.03.2010 11:26, Vidar Ramdal wrote:
>> Yes, I think we have been discussing this before. The problem is, what
>> if you want to post to a JSON file (e.g.
>> http://localhost:8080/content/file.json)?

On Mon, Mar 8, 2010 at 11:47 AM, Felix Meschberger  wrote:
> Hmm, what is the target resource's name ?

In my example the target resource is /content/file.json

> Is it "/content/file" ? Then it is a .json request but you post to
> /content/file.
>
> Is it "/content/file.json" ? Then it is not a .json request because
> there is no request extension.

So, if I want to post a JSON file and have a JSON response, the
request URL would be /content/file.json.json?

>> You probably want a JSON response in those cases too, but I fear this
>> could become inconsistent.
>>
>> Also, strictly speaking, the Accept header will probably say that the
>> client prefers a text/html response (which is what web browsers do as
>> default). So, to strictly comply with RFC 2616 [1], we should return
>> HTML when we're able to, and the client has not specified a preference
>> for something else.
>>
>> [1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.1
>
> But probably you are right. If we want to have JSON requests we are
> probably in more control over the request (app request or XHR request)
> than using a regular post and requiring the Accept header (or the
> overwrite parameter) might be correct).
>
> (in fact sending back JSON as a response to a .json request is already
> bending the standard because we are ignoring the Accept header altogether)

Well, web browsers seems to always send */* as fallback. E.g., Firefox
sends this:
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

So, it prefers text/html, but will accept anything (*/*) if the other
media types are unavailable. So "legally" we could return anything,
but since we "can" produce text/html, I guess we should.

-- 
Vidar S. Ramdal  - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00 / +47 21 531941, ext 2070

Re: Let SlingPostServlet return JSON (WAS: Re: Client JSon Calls)

[Vidar Ramdal]

On Mon, Mar 8, 2010 at 9:44 AM, Felix Meschberger  wrote:
> Hi,
>
> On 08.03.2010 09:08, Vidar Ramdal wrote:
>> On Thu, Jan 28, 2010 at 3:10 PM, Vidar Ramdal  wrote:
>>> Finally, we implement the logic for choosing either sendHtml() or
>>> sendJson(), based on:
>>> 1. The format of the posted data - if JSON is posted (SLING-1172),
>>> return JSON, otherwise return HTML
>>> 2. The Accept HTTP header - if set to "application/json" return JSON,
>>> otherwise return HTML
>>> 3. Possibly also an :accept form field, with the same value as the
>>> HTTP header, in case it is proven that setting the HTTP header does
>>> not work in some browsers
>>
>> I have a patch for this ready at
>> https://issues.apache.org/jira/secure/ManageAttachments.jspa?id=12446912
>>
>> Here's how it's implemented:
>> 1. A class JSONResponse which extends HtmlResponse (for backward 
>> compatibility)
>> 2. A class MediaRangeList for parsing the HTTP Accept header
>> 3. A method SlingPostServlet.createHtmlResponse for determining which
>> format (HTML/JSON) to return to the client
>>
>> The JSON format is kept as close to the HTML format as possible.
>>
>> JSON is only returned if the client sends "application/json" in the
>> Accept header, with a greater preference than text/html. Also, the
>> Accept header can be simulated by a the :http-equiv-accept query
>> parameter.
>> I dropped the automatic return of JSON on JSON posts (SLING-1172) - I
>> think the client should specify application/json in Accept anyway, if
>> it wants JSON returned.
>>
>> WDYT? Is this a sensible way of implementing this?
>
> It hink this is basically a good idea. Esp. having the overwrite parameter.
>
> Though for symmetry with GET requests, where the .json extension ask for
> a JSON response, we might want to also support this for POST ... Don't
> have a very string preference, though.

Yes, I think we have been discussing this before. The problem is, what
if you want to post to a JSON file (e.g.
http://localhost:8080/content/file.json)?
You probably want a JSON response in those cases too, but I fear this
could become inconsistent.

Also, strictly speaking, the Accept header will probably say that the
client prefers a text/html response (which is what web browsers do as
default). So, to strictly comply with RFC 2616 [1], we should return
HTML when we're able to, and the client has not specified a preference
for something else.

[1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.1

-- 
Vidar S. Ramdal  - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00 / +47 21 531941, ext 2070

Re: Let SlingPostServlet return JSON (WAS: Re: Client JSon Calls)

[Vidar Ramdal]

On Thu, Jan 28, 2010 at 3:10 PM, Vidar Ramdal  wrote:
> Finally, we implement the logic for choosing either sendHtml() or
> sendJson(), based on:
> 1. The format of the posted data - if JSON is posted (SLING-1172),
> return JSON, otherwise return HTML
> 2. The Accept HTTP header - if set to "application/json" return JSON,
> otherwise return HTML
> 3. Possibly also an :accept form field, with the same value as the
> HTTP header, in case it is proven that setting the HTTP header does
> not work in some browsers

I have a patch for this ready at
https://issues.apache.org/jira/secure/ManageAttachments.jspa?id=12446912

Here's how it's implemented:
1. A class JSONResponse which extends HtmlResponse (for backward compatibility)
2. A class MediaRangeList for parsing the HTTP Accept header
3. A method SlingPostServlet.createHtmlResponse for determining which
format (HTML/JSON) to return to the client

The JSON format is kept as close to the HTML format as possible.

JSON is only returned if the client sends "application/json" in the
Accept header, with a greater preference than text/html. Also, the
Accept header can be simulated by a the :http-equiv-accept query
parameter.
I dropped the automatic return of JSON on JSON posts (SLING-1172) - I
think the client should specify application/json in Accept anyway, if
it wants JSON returned.

WDYT? Is this a sensible way of implementing this?

-- 
Vidar S. Ramdal  - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00 / +47 21 531941, ext 2070

Re: [RT] ResourceTypeProvider

[Vidar Ramdal]

>> On Fri, Mar 5, 2010 at 11:42 AM, Carsten Ziegeler  
>> wrote:
>>> ...We could make a general approach like (I couldn't make up could names
>>> for the interface and methods...)
>>>
>>> interface ResourceProcessor {
>>>
>>>   Resource process(Resource);
>>> }
>>>
>>> so basically this works like kind of a filter which is able to
>>> substitute a resource with a completly different one - this could be
>>> used to change the resource type, the super resource type, metadata,
>>> different implementations of the adaptTo method etc. Everything is
>>> possible

> On Fri, Mar 5, 2010 at 11:54 AM, Bertrand Delacretaz
>> I like the idea, we could call it ResourceFilter maybe? As you
>> indicate it's filtering the resource after it's loaded.
>>
>> It's a sharp knife though, could probably be abused in several ways -
>> but as all Sling components are replaceable anyway, it doesn't make
>> much of a difference.
>>
>> I'd say go for it, but watch out for which implementations we create ;-)

On Fri, Mar 5, 2010 at 2:10 PM, Julian Sedding  wrote:
> I like the idea and implementing this in a generic fashion seems sensible to 
> me.
>
> Regarding the naming, what about:
>
> interface ResourceDecoratorFilter {
>Resource decorate(Resource);
> }

I really like this idea, I have been thinking about something similar:
A ResourceDecorator which would provide dynamic property values, like
a count of its child resources, or a sum of products in a shopping
basket.

The concept you guys come up with here looks really useful for this purpose.

-- 
Vidar S. Ramdal  - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00 / +47 21 531941, ext 2070

Re: Adding a new @ hint to post servlet

[Vidar Ramdal]

On Tue, Feb 23, 2010 at 3:51 PM, Justin Edelson  wrote:
> I'm having a problem which is primarily a UI issue, but I think would be
> best addressed in the post servlet. Basically, I have a form with
> multiple form fields for the same property and some of those are blank,
> so my post parameters end up like this:
>
> ./stringprope...@typehint=string[]
> ./stringProperty=foo
> ./stringProperty=bar
> ./stringProperty=
>
> This results in stringProperty getting set to ['foo','bar',''], which
> isn't what I want (I want ['foo','bar']).
>
> What I'd like to do is add @ExcludeBlanks as a new hint, so that
>
> ./stringprope...@typehint=string[]
> ./stringprope...@excludeblanks=true
> ./stringProperty=foo
> ./stringProperty=bar
> ./stringProperty=
>
> results in the array of two values.
>
> WDYT?

I'm not sure if the SlingPostServlet should handle this, or if we
should demand the client to be smart enough to not post empty params
if it doesn't want to set a field.
Also, maybe @IgnoreBlanks would be a better name?

In any case, if @ExcludeBlanks/@IgnoreBlanks is implemented, it should
apply to single-value properties as well, for consistency.
So that a post with fields
./stringprope...@typehint=string
./stringprope...@excludeblanks=true
./stringProperty=
... should leave ./stringProperty unchanged.

-- 
Vidar S. Ramdal  - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00 / +47 21 531941, ext 2070

Re: JcrModifiablePropertyMap.save() makes atomic operations difficult

[Vidar Ramdal]

On Mon, Feb 15, 2010 at 1:41 PM, Vidar Ramdal  wrote:

> If we all agree that this is a viable path forward, I'll file a JIRA for it.

As there were no objections so far, I created SLING-1391 to track this.

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

-- 
Vidar S. Ramdal  - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00 / +47 21 531941, ext 2070

Re: Welcome Eric Norman

[Vidar Ramdal]

On Wed, Feb 17, 2010 at 4:20 PM, Felix Meschberger  wrote:
> Please join me in welcoming Eric Norman as a new committer !

Good to have you on board, Eric. Welcome!

-- 
Vidar S. Ramdal  - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00 / +47 21 531941, ext 2070

Re: [VOTE] Release several jcr bundles

[Vidar Ramdal]

On Sat, Feb 13, 2010 at 9:54 PM, Carsten Ziegeler  wrote:
> as discussed in the last days, this vote is for the following releases:
>
> jcr WebDav 2.0.8
> https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&pid=12310710&fixfor=12314433
>
> jcr contentloader 2.0.6
> https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&pid=12310710&fixfor=12314111
>
> jcr usermanager 2.0.4
> https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&pid=12310710&fixfor=12314021
>
> jcr server 2.0.6
> https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&pid=12310710&fixfor=12314067
>
> jcr accessmanager 2.0.4
> https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&pid=12310710&fixfor=12314114
>
> jcr base 2.0.6
> https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&pid=12310710&fixfor=12314521
>
> As I had to do the release on two days, we have two staging repositories:
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-001/
> https://repository.apache.org/content/repositories/orgapachesling-002/
>
> You can use this UNIX script to download the release and verify the
> signatures:
> http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh

+1

-- 
Vidar S. Ramdal  - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00 / +47 21 531941, ext 2070

Re: JcrModifiablePropertyMap.save() makes atomic operations difficult

[Vidar Ramdal]

On Fri, Feb 12, 2010 at 10:32 PM, Felix Meschberger  wrote:
> Sorry to chime in late...
>
> I see the issues of Vidar and these are caused by the
> PersistableValueMap introducing its own transient space ontop of the JCR
> transient space.
>
> When the PersistableValueMap transient space is saved (save() call), the
> data is written to the JCR transient space and then directly to the JCR
> persistent space by calling the JCR save method.
>
> I see the problem. In fact, even if the Sling API would allow for full
> CRUD, particularly creating resources, Vidar's use case cannot be
> implemented using the PersistableValueMap.
>
> How about this:
>
>  * Enable the PersistableValueMap to write through to the JCR
>    transient space on put().
>
>  * Write-through is configurable on a global level (in the
>    JcrResourceResolver providing the PersistableValueMap
>    instances upon adapt()). By default it is switched off
>    (backwards compatiblity).
>
>  * Write-through can also be switched on/off on a per-instance
>    level of the PersistableValueMap object (setWriteThrough(boolean))
>
>  * PersistableValueMap.save() first writes back local changes
>    not already stored using write-through and then calls node.save()
>
>  * PersistableValueMap.reset() drops local changes not already stored
>    using write-through and then calls node.refresh(false)
>
>  * When we finally do full CRUD in the ResourceResolver, we should
>    add save/reset methods, which would call Session.save() or
>    refresh(false), resp. For now the Session methods must be called
>    directly.
>
> WDYT ?

Makes a lot of sense. I suppose the JCR write-through does not affect
performance too much.

I really like the configurable setting on JcrResourceResolver. As
Carsten says, Node.save() is deprecated by JCR 2.0, so we should
probably start avoiding it already.

If we all agree that this is a viable path forward, I'll file a JIRA for it.

-- 
Vidar S. Ramdal  - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00 / +47 21 531941, ext 2070