[jira] Commented: (SLING-1445) store the AuthenticationInfo object in a request attribute

[Justin Edelson (JIRA)]

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

Justin Edelson commented on SLING-1445:
---

IIRC, my use case was to log into a different workspace using the same 
credentials. copy() obviously won't help for this. Apologies for not 
documenting the rationale.

I can probably get by with a combination of loginAdministrative and impersonate 
if you want to roll this back.

(Bertrand - as an aside, I briefly looked at the class linked to above and 
didn't see the ResourceResolver being closed. Maybe I just missed it, but I 
figured it was worth mentioning.)

> store the AuthenticationInfo object in a request attribute
> --
>
> Key: SLING-1445
> URL: https://issues.apache.org/jira/browse/SLING-1445
> Project: Sling
>  Issue Type: Improvement
>  Components: Commons
>Reporter: Justin Edelson
>Assignee: Justin Edelson
> Fix For: Commons Auth 1.0.0
>
>
> called org.apache.sling.commons.auth.spi.AuthenticationInfo

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

[jira] Commented: (SLING-1627) import operation does not respect :replace=true for properties

[Eric Norman (JIRA)]

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

Eric Norman commented on SLING-1627:


The wiki pages for the jcr.contentloader and servlets.post bundles are now 
updated with the new options.

> import operation does not respect :replace=true for properties
> --
>
> Key: SLING-1627
> URL: https://issues.apache.org/jira/browse/SLING-1627
> Project: Sling
>  Issue Type: Bug
>  Components: JCR
>Reporter: Zach A. Thomas
>Assignee: Eric Norman
> Fix For: Servlets Post 2.0.6, Launchpad Testing 6, JCR 
> ContentLoader 2.0.8
>
> Attachments: SLING-1627.patch, SLING-1627v2.patch
>
>
> If I want to import some JSON and then update it with a subsequent POST 
> (using the :replace=true flag), the nodes are updated, but not the properties.
> curl -u admin:admin -F":operation=import" -F":contentType=json" 
> -F':content={"columns": {"one":"value"}, "layout": "dev"}' 
> http://localhost:8080/dashboard
> If I do a subsequent POST with the :replace parameter:
> curl -u admin:admin -F":operation=import" -F":contentType=json" 
> -F':content={"columns": {"one":"love"}, "layout": "dev"}' -F":replace=true" 
> http://localhost:8080/dashboard
> The columns object is updated, but the layout property is not. I tracked this 
> down to Sling's DefaultContentCreator, whose createProperty method expressly 
> won't overwrite a property if it already exists.

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

[jira] Resolved: (SLING-1627) import operation does not respect :replace=true for properties

[Eric Norman (JIRA)]

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

Eric Norman resolved SLING-1627.


Fix Version/s: Servlets Post 2.0.6
   Launchpad Testing 6
   JCR ContentLoader 2.0.8
   Resolution: Fixed

Thanks for the updated patch.  I cleaned things up a bit and committed the 
changes in r983135.

I changed the names of the request param and directive from what was in the 
patch, updated some javadocs and added an additional integration test.

Please verify the changes work for you.

> import operation does not respect :replace=true for properties
> --
>
> Key: SLING-1627
> URL: https://issues.apache.org/jira/browse/SLING-1627
> Project: Sling
>  Issue Type: Bug
>  Components: JCR
>Reporter: Zach A. Thomas
>Assignee: Eric Norman
> Fix For: Servlets Post 2.0.6, Launchpad Testing 6, JCR 
> ContentLoader 2.0.8
>
> Attachments: SLING-1627.patch, SLING-1627v2.patch
>
>
> If I want to import some JSON and then update it with a subsequent POST 
> (using the :replace=true flag), the nodes are updated, but not the properties.
> curl -u admin:admin -F":operation=import" -F":contentType=json" 
> -F':content={"columns": {"one":"value"}, "layout": "dev"}' 
> http://localhost:8080/dashboard
> If I do a subsequent POST with the :replace parameter:
> curl -u admin:admin -F":operation=import" -F":contentType=json" 
> -F':content={"columns": {"one":"love"}, "layout": "dev"}' -F":replace=true" 
> http://localhost:8080/dashboard
> The columns object is updated, but the layout property is not. I tracked this 
> down to Sling's DefaultContentCreator, whose createProperty method expressly 
> won't overwrite a property if it already exists.

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

Re: Maven Launchpad Plugin : Support for other files than bundles

[Justin Edelson]

On Aug 6, 2010, at 11:41 AM, Carsten Ziegeler  wrote:

> Hi,
> 
> does our maven launchpad plugin support including other artifacts than
> bundles by just listing them in the XML file?
> 

Assuming you're talking about src/main/bundles/list.xml, no, this just handles 
bundles (i.e. Maven artifacts).

> In addition I would like to add configuration files - usually these
> files are not available as dependencies. I see two options:
> - either include them as resources and the launchpad plugin could just
> copy the src/main/resources directory

In general, this is the right way IMHO, but... 

> - having a separate project for this stuff - and then just reference the
> dependency from the builder project. As this is a resource dependency
> the jar/zip gets extracted when included

What configs do you envision including in launchpad? I assumed that this 
functionally would only be used downstream, i.e. By something like Sakai or IKS.

If there are going to be 'standard' configs, then I think we probably should 
have a separate project, a la launchpad.base so that they can be easily 
consumed downstream, but let's cross that bridge when we get to it.

Justin  
> 
> 
> WDYT?
> 
> Regards
> Carsten
> -- 
> Carsten Ziegeler
> cziege...@apache.org

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

[Justin Edelson]

+1

On Fri, Aug 6, 2010 at 2: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.
>
> Regards
> Carsten
>
> Jean Christophe Kautzmann  wrote
>> Hi,
>>
>> How about adding a hint to the docs stating that other bundles might be
>> needed and that a list of dependencies can be found in the manifest.mf file
>> of the scheduler bundle?
>> I'd volunteer to adapt the docs (that I happen to draft with Carsten)
>> accordingly but I'd need access rights for that :)
>>
>> Cheers JC
>>
>> On Thu, Aug 5, 2010 at 1:14 PM, Mike Müller  wrote:
>>
>>> Hi
>>>
>>> Such depencies are reflected in the manifest.mf file of each
>>> bundle. I don't think it's a good idea, to put them manually
>>> into the documentation, as long as they can change over time.
>>>
>>> best regards
>>> mike
>>>
 -Original Message-
 From: Federico Paparoni [mailto:federico.papar...@gmail.com]
 Sent: Thursday, August 05, 2010 10:04 AM
 To: us...@sling.apache.org
 Subject: Re: Scheduler service problem


 2010/8/5 Carsten Ziegeler 

> Hi,
>
> the scheduler needs two other bundles:
>
> org.apache.commons.collections (which should be installed)
> org.apache.sling.commons.threads 3.0.0
>
> Regards
> Carsten
>
>
 Now everything works, thanks.
 Anyway I think these informations should be available on the
 documentation (
 http://sling.apache.org/site/scheduler-service-commons-schedul
>>> er.html
>>> ).
>>>
>>> --
>>> Federico
>>>
>>
>
>
> --
> Carsten Ziegeler
> cziege...@apache.org
>

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

[Eric Norman]

+1

On Thu, Aug 5, 2010 at 11:08 PM, 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.
>
> Regards
> Carsten
>
> Jean Christophe Kautzmann  wrote
> > Hi,
> >
> > How about adding a hint to the docs stating that other bundles might be
> > needed and that a list of dependencies can be found in the manifest.mf
> file
> > of the scheduler bundle?
> > I'd volunteer to adapt the docs (that I happen to draft with Carsten)
> > accordingly but I'd need access rights for that :)
> >
> > Cheers JC
> >
> > On Thu, Aug 5, 2010 at 1:14 PM, Mike Müller  wrote:
> >
> >> Hi
> >>
> >> Such depencies are reflected in the manifest.mf file of each
> >> bundle. I don't think it's a good idea, to put them manually
> >> into the documentation, as long as they can change over time.
> >>
> >> best regards
> >> mike
> >>
> >>> -Original Message-
> >>> From: Federico Paparoni [mailto:federico.papar...@gmail.com]
> >>> Sent: Thursday, August 05, 2010 10:04 AM
> >>> To: us...@sling.apache.org
> >>> Subject: Re: Scheduler service problem
> >>>
> >>>
> >>> 2010/8/5 Carsten Ziegeler 
> >>>
>  Hi,
> 
>  the scheduler needs two other bundles:
> 
>  org.apache.commons.collections (which should be installed)
>  org.apache.sling.commons.threads 3.0.0
> 
>  Regards
>  Carsten
> 
> 
> >>> Now everything works, thanks.
> >>> Anyway I think these informations should be available on the
> >>> documentation (
> >>> http://sling.apache.org/site/scheduler-service-commons-schedul
> >> er.html<
> http://sling.apache.org/site/scheduler-service-commons-schedul%0Aer.html>
> >> ).
> >>
> >> --
> >> Federico
> >>
> >
>
>
> --
> Carsten Ziegeler
> cziege...@apache.org
>

Re: [RT] Using FileInstall

[Justin Edelson]

Apologies in advance for reordering the bits from Carsten's email, but
I think my response will make more sense this way.

On Wed, Aug 4, 2010 at 9:53 AM, Carsten Ziegeler  wrote:
>
> Currently the launchpad copies the initial set of bundles to a file
> directory and creates a structure based on the start levels there.
> Bundles are then picked up from there and installed.
>
Personally, I'd like to revisit this design. It seems unnecessary to
copy the bundles to the file system vs. reading them directly from the
InputStream. AFAICT, this was originally done to allow for additional
bundles (i.e. ones not in the launchpad archive) to be placed in the
startup directory, but that's exactly where FileInstall *should* be
used.

What I would like to see is that the ResourceProvider interface (the
launchpad one, not the Sling API one) is treated like a virtual file
system and that resources from this VFS are used directly by:
1) the bits in launchpad which install/start bundles
2) some ConfigAdmin bridge thingy
3) the jackrabbit.server bundle (in order to load the JR config from
inside the archive)

Yes... disk is cheap, but it seems wasteful that in a typical Sling
install you end up with three copies of each bundle - one inside the
archive, one in the startup directory, and one in the Felix cache.

> while trying to implement handling of initial configurations for the
> ConfigAdmin within our launchpad, I noticed that this is more difficult
> than I thought. The final problem is a class loading issue as the
> launchpad does not contain the compendium class (for config admin).
> For the same reason, the current support of deployment packages is
> broken in launchpad.

The other obvious solution is to embed ConfigAdmin in Launchpad. I'm
sure there are reasons not to do this, but I suspect that these are
somewhat academic in nature given how stable the
Felix ConfigAdmin implementation appears to be.

> While trying to workarund these problems I came back to an idea I had a
> long time ago: instead of doing all these installs (bundle, configs,
> depl. pcks etc.) in our own code, why not use existing stuff?
> The FileInstall bundle from Apache Felix covers most of our use cases -
> there are some minor pieces missing. But we can add the required
> features there and avoid duplicate code by just using File Install.
I'm not sure these missing pieces are so minor... last I looked, File
Install doesn't support start levels. Although I'm not sure Sling
*needs* start levels, they are useful from an administrative
perspective.

It seems to me that what's really needed is a refactoring of
ConfigAdmin and FileInstall (and JCR Install for that matter) to
provide a unified, standalone config parsing library. I believe I saw
some discussion on felix-dev about having FileInstall use the config
parsing bits from the ConfigAdmin bundle. This is better than having
code duplication, but a standalone library still seems better to me.

All that said, I'm on vacation and haven't been able to fully process
this. But I did want to raise my concerns now before this got too far.

Justin

> Note, that File Install is mainly used to get initial configuration into
> the system - so it's more bootstrapping - for everything else jcr
> install can be used. Or File Install is nice for all those scenarios
> where no repository is used :)
>
> WDYT?
>
> Carsten
> --
> Carsten Ziegeler
> cziege...@apache.org
>

[jira] Updated: (SLING-1627) import operation does not respect :replace=true for properties

[Zach A. Thomas (JIRA)]

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

Zach A. Thomas updated SLING-1627:
--

Attachment: SLING-1627v2.patch

Thanks, Eric. I have attached another patch that addresses the issue with a new 
request parameter: :replaceProps

It necessitates changes to two bundles, rather than just one: jcr/contentloader 
and servlets/post



> import operation does not respect :replace=true for properties
> --
>
> Key: SLING-1627
> URL: https://issues.apache.org/jira/browse/SLING-1627
> Project: Sling
>  Issue Type: Bug
>  Components: JCR
>Reporter: Zach A. Thomas
>Assignee: Eric Norman
> Attachments: SLING-1627.patch, SLING-1627v2.patch
>
>
> If I want to import some JSON and then update it with a subsequent POST 
> (using the :replace=true flag), the nodes are updated, but not the properties.
> curl -u admin:admin -F":operation=import" -F":contentType=json" 
> -F':content={"columns": {"one":"value"}, "layout": "dev"}' 
> http://localhost:8080/dashboard
> If I do a subsequent POST with the :replace parameter:
> curl -u admin:admin -F":operation=import" -F":contentType=json" 
> -F':content={"columns": {"one":"love"}, "layout": "dev"}' -F":replace=true" 
> http://localhost:8080/dashboard
> The columns object is updated, but the layout property is not. I tracked this 
> down to Sling's DefaultContentCreator, whose createProperty method expressly 
> won't overwrite a property if it already exists.

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

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

[Justin Edelson]

+1

On Fri, Aug 6, 2010 at 2: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.
>
> Regards
> Carsten
>
> Alison Heimoz  wrote
>> Hi Carsten
>>
>> +1 for Jean Christophe.
>>
>> And can I add my own name to the request for access rights to documentation?
>>
>> I've already entered a few Jiras on documentation after reviewing/testing
>> some of the getting started/introduction pages.
>> It would make it quicker if I could update directly as well.
>>
>> Cheers Alison
>>
>>
>> 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.
>>>
>>> Regards
>>> Carsten
>>>
>>> Jean Christophe Kautzmann  wrote
 Hi,

 How about adding a hint to the docs stating that other bundles might be
 needed and that a list of dependencies can be found in the manifest.mf
>>> file
 of the scheduler bundle?
 I'd volunteer to adapt the docs (that I happen to draft with Carsten)
 accordingly but I'd need access rights for that :)

 Cheers JC

 On Thu, Aug 5, 2010 at 1:14 PM, Mike Müller  wrote:

> Hi
>
> Such depencies are reflected in the manifest.mf file of each
> bundle. I don't think it's a good idea, to put them manually
> into the documentation, as long as they can change over time.
>
> best regards
> mike
>
>> -Original Message-
>> From: Federico Paparoni [mailto:federico.papar...@gmail.com]
>> Sent: Thursday, August 05, 2010 10:04 AM
>> To: us...@sling.apache.org
>> Subject: Re: Scheduler service problem
>>
>>
>> 2010/8/5 Carsten Ziegeler 
>>
>>> Hi,
>>>
>>> the scheduler needs two other bundles:
>>>
>>> org.apache.commons.collections (which should be installed)
>>> org.apache.sling.commons.threads 3.0.0
>>>
>>> Regards
>>> Carsten
>>>
>>>
>> Now everything works, thanks.
>> Anyway I think these informations should be available on the
>> documentation (
>> http://sling.apache.org/site/scheduler-service-commons-schedul
> er.html<
>>> http://sling.apache.org/site/scheduler-service-commons-schedul%0Aer.html>
> ).
>
> --
> Federico
>

>>>
>>>
>>> --
>>> Carsten Ziegeler
>>> cziege...@apache.org
>>>
>>
>
>
> --
> Carsten Ziegeler
> cziege...@apache.org
>

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

[Eric Norman]

+1

Regards,
Eric

On Aug 5, 2010 11:21 PM, "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.

Regards
Carsten

Alison Heimoz  wrote
> Hi Carsten
>
> +1 for Jean Christophe.
>
> And can I add my own name to the request for access rights to
documentation?
>
> I've already entered a few Jiras on documentation after reviewing/testing
> some of the getting started/introduction pages.
> It would make it quicker if I could update directly as well.
>
> Cheers Alison
>
>
> 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.
>>
>> Regards
>> Carsten
>>
>> Jean Christophe Kautzmann  wrote
>>> Hi,
>>>
>>> How about adding a hint to the docs stating that other bundles might be
>>> needed and that a list of dependencies can be found in the manifest.mf
>> file
>>> of the scheduler bundle?
>>> I'd volunteer to adapt the docs (that I happen to draft with Carsten)
>>> accordingly but I'd need access rights for that :)
>>>
>>> Cheers JC
>>>
>>> On Thu, Aug 5, 2010 at 1:14 PM, Mike Müller  wrote:
>>>
 Hi

 Such depencies are reflected in the manifest.mf file of each
 bundle. I don't think it's a good idea, to put them manually
 into the documentation, as long as they can change over time.

 best regards
 mike

> -Original Message-
> From: Federico Paparoni [mailto:federico.papar...@gmail.com]
> Sent: Thursday, August 05, 2010 10:04 AM
> To: us...@sling.apache.org
> Subject: Re: Scheduler service problem
>
>
> 2010/8/5 Carsten Ziegeler 
>
>> Hi,
>>
>> the scheduler needs two other bundles:
>>
>> org.apache.commons.collections (which should be installed)
>> org.apache.sling.commons.threads 3.0.0
>>
>> Regards
>> Carsten
>>
>>
> Now everything works, thanks.
> Anyway I think these informations should be available on the
> documentation (
> http://sling.apache.org/site/scheduler-service-commons-schedul
 er.html<
>> http://sling.apache.org/site/scheduler-service-commons-schedul%0Aer.html>
 ).

 --
 Federico

>>>
>>
>>
>> --
>> Carsten Ziegeler
>> cziege...@apache.org
>>
>


--
Carsten Ziegeler
cziege...@apache.org

Re: [RT] SlingHttpServletRequest.externalize() methods

[Alexander Klimetschek]

On Fri, Aug 6, 2010 at 14:25, Felix Meschberger  wrote:
> Excellent point: Have a look at Sling's
> HttpServletResponse.encodeURL(String) method [1].
>
> And yes, this is a method which has been there for a long time, but
> developers don't seem to be used to use it ;-)

I know it, but it doesn't fit at all: encodeURL() doesn't generate
absolute URLs, its main purpose is to add the session ID, which we
don't want in Sling.

My idea was to have a reliable single method for generating absolute
URLs, and for the sake of consistency and simplicity for the client,
have a similar one (or decide via a flag) for generating relative URLs
(what ResourceResolver.map(request, path) is doing).

Regards,
Alex

-- 
Alexander Klimetschek
alexander.klimetsc...@day.com

Re: [RT] SlingHttpServletRequest.externalize() methods

[Alexander Klimetschek]

On Fri, Aug 6, 2010 at 12:07, Carsten Ziegeler  wrote:
> Alexander Klimetschek  wrote
>
>> Another reason for the prominent place is that it teaches people to do
>> the right thing more easily. I have seen many cases that create links
>> without considering context path or sling's mapping.
>>
> Hmm, but if a developer is not able to call map on the resource resolver
> why should he now call a method on the request (or response) ?
> Maybe the map method is not very prominently placed, but I would rather
> do an example showing people how to do it, instead of adding all kind of
> stuff to the request interface.
> Again, maybe this stuff is very useful for everyone and it makes sense
> to add it to a more prominent place. But atm I doubt this.

Maybe you are right.

Actually I now think that the ResourceResolver would be a better
location, to be able to generate absolute URLs (ie. including host and
context path) outside of the request scope. That would require some
additional configuration in the resolver or under /etc/map. Currently
I am doing that in a custom service.

Regards,
Alex

-- 
Alexander Klimetschek
alexander.klimetsc...@day.com

Re: davidgsoc2010 r58, code review

[Federico Paparoni]

Hi Bertrand,

2010/8/6 Bertrand Delacretaz 

> Hi Federico,
>
> Here are the raw comments from my review, I'll discuss the next
> steps/priorities in a separate message.
>
> Test scenario, action items marked with ->
>
> Start sling launchpad/builder -standalone jar after deleting sling work
> folder
>
> Build and install davidgsoc2010 libraries and core bundles in this order
>
> Core bundle doesn't start, needs additional bundles:
> org.apache.sling.commons.scheduler
> org.apache.sling.commons.threads
>
> core bundle now starts.
>
> -> suggest a README.txt at the top of the davidgsoc2010 code tree that
> describes the installation.
>

Yes, it will be also described in the documentation.


>
> Open http://localhost:8080/content/david.home.html
>
> -> should be david.html, as already mentioned.
>

Fixed with last revision (65)


>
> Sometimes saving an entry doesn't work, server says
>
>  Error while processing /content/david/2010/08/07/about_sling
>  javax.jcr.AccessDeniedException: Access denied
>
> even though I could save another entry seconds before.
>
> Deleting entries didn't work either, didn't investigate.
>
> -> need better client-side error messages to troubleshoot such things
>

I don't understand why. There is the check to see if you are logged and I
never received this error.
Can you tell me the exact steps you performed? Which browser are you using?


>
> Search functions seem to work ok, tested with minimal content only.
>
> On /content/david.list.html the name of the entry should be a link to
> READ, and remove that link. Reading is the standard operation.
>
> -> change links
>

Fixed with last revision (65)


>
> The libraries bundle should be split in two: ckeditor and swfobject
> for tags display. Or more than two if it contains other independent
> components - the idea is to have one bundle per independent component.
> The convention is to use /libs, not /libraries for those types of
> things.
>
> -> split bundle
>

I can split the libraries into two or more bundles, but I think it isn't
useful.
It can be useful if there is a mechanism to change these components with
others (other layout, other JS framework etc. etc.). But to do that I had to
focus more on the project that on Sling.
Anyway if you think it's a "must-have" feature (also for a future
development) I can separate them.


>
> The core bundle source code structure is nice and clean now, that's
> very cool: it contains just the applications layer of the mini-CMS.
>
> -Bertrand
>



-- 
Federico

Re: [RT] Using FileInstall

[Carsten Ziegeler]

Ok, I think the whole thing could work like this:

- resources/corebundles : contains the bundles which are installed by
the Sling base - this is usually just the log bundle and the file
install bundle.
- resources/bundles/{startLevel}/* : contains the bundles in the various
start levels - this is currently handled by Sling but will be by
FileInstall.
- resources/install : contains all other installables like deployment
packages and configurations

Like before all these are copied on startup over to the sling/startup
directory and file install is configured to watch the bundles and
install directory.

WDYT?

Regards
Carsten
-- 
Carsten Ziegeler
cziege...@apache.org

Maven Launchpad Plugin : Support for other files than bundles

[Carsten Ziegeler]

Hi,

does our maven launchpad plugin support including other artifacts than
bundles by just listing them in the XML file?

In addition I would like to add configuration files - usually these
files are not available as dependencies. I see two options:
- either include them as resources and the launchpad plugin could just
copy the src/main/resources directory
- having a separate project for this stuff - and then just reference the
dependency from the builder project. As this is a resource dependency
the jar/zip gets extracted when included


WDYT?

Regards
Carsten
-- 
Carsten Ziegeler
cziege...@apache.org

[jira] Commented: (SLING-1445) store the AuthenticationInfo object in a request attribute

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz commented on SLING-1445:


> Maybe we could add something like a copy() method to the resource resolver: 

Would work for me, currently I'm getting the AuthenticationInfo from a request 
attribute in [1], as it's needed to create a new ResourceResolver with the same 
credentials as the current one.

[1] 
http://svn.apache.org/repos/asf/sling/trunk/contrib/extensions/bgservlets/src/main/java/org/apache/sling/bgservlets/impl/BackgroundRequestExecutionJob.java

> store the AuthenticationInfo object in a request attribute
> --
>
> Key: SLING-1445
> URL: https://issues.apache.org/jira/browse/SLING-1445
> Project: Sling
>  Issue Type: Improvement
>  Components: Commons
>Reporter: Justin Edelson
>Assignee: Justin Edelson
> Fix For: Commons Auth 1.0.0
>
>
> called org.apache.sling.commons.auth.spi.AuthenticationInfo

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

Re: closing out remaining API 2.1.0 issues

[Carsten Ziegeler]

Felix Meschberger  wrote
> 
> Agreed for the constants: How about moving them to the API ?
> 
> Why is using the AuthenticationInfo constructor more elegant than using
> the Map constructor and setting a property. And where would such a thing
> be used ?
> 
Yes, I think the constants USER, PASSWORD should be enough to be moved.
We could just add them to the ResourceResolverFactory.

We should move the CREDENTIALS constant to the JcrResourceConstants
class as these constant is only relevant for a jcr backed resource
resolver. We can then remove the credentials class check as well.

We should also move the commons auth module out of commons as this
module now depends on Sling API and therefore does not meet the criteria
for commons :)

Regards
Carsten
-- 
Carsten Ziegeler
cziege...@apache.org

Re: closing out remaining API 2.1.0 issues

[Felix Meschberger]

Hi,

On 29.07.2010 08:45, Carsten Ziegeler wrote:
> Felix Meschberger  wrote
>> Hi,
>>
>> It took me some time to complete, but here we are...
>>
>> I have finished SLING-1193 (Resource API extension) and SLING-1575
>> (moving Authenticator interface to Sling API).
>>
> Great, thanks for the work Felix!
> 
>> I think this finishes all open tasks for Sling 2.1.0. Looking back at
>> what we did, this looks like the biggest extension to API since 2.0 ;-)
>>
>> Before cutting a release, lets wait few days for people to review the API.
>>
> Ok, here we go :)
> 
> I think the AuthenticationInfo is something which might move to the
> Sling API - when using the ResourceResolverFactory to get a resolver, it
> would be a little bit nicer to be able to use the AuthenticationInfo
> class instead of a plain map (for using the constructors and the constants).

Agreed for the constants: How about moving them to the API ?

Why is using the AuthenticationInfo constructor more elegant than using
the Map constructor and setting a property. And where would such a thing
be used ?

> 
> I can't remember our old discussions in detail, but I thought we move
> the api part (including the spi) from the auth module to the Sling api
> module and just leave the implementation in the auth module.
> So basically the problematic part is the auth module which contains api
> and impl.
> The urge to change this is not that high as it only affects people using
> the Sling API without the Auth module, but still it would be nice :)

My point was, that the SPI part of the Commons Auth API is more tied to
how the Commons Auth bundle implements the org.apache.sling.api.auth
API. As such it is of no interest to most Sling Application developers.

Regards
Felix

> 
> Regards
> Carsten

[jira] Commented: (SLING-1445) store the AuthenticationInfo object in a request attribute

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-1445:
-

Maybe we could add something like a copy() method to the resource resolver:

ResourceResolver newRR = oldRR.copy();



> store the AuthenticationInfo object in a request attribute
> --
>
> Key: SLING-1445
> URL: https://issues.apache.org/jira/browse/SLING-1445
> Project: Sling
>  Issue Type: Improvement
>  Components: Commons
>Reporter: Justin Edelson
>Assignee: Justin Edelson
> Fix For: Commons Auth 1.0.0
>
>
> called org.apache.sling.commons.auth.spi.AuthenticationInfo

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

Re: closing out remaining API 2.1.0 issues

[Felix Meschberger]

Hi,

On 29.07.2010 10:39, Bertrand Delacretaz wrote:
> On Thu, Jul 29, 2010 at 8:45 AM, Carsten Ziegeler  
> wrote:
>> ...I think the AuthenticationInfo is something which might move to the
>> Sling API - when using the ResourceResolverFactory to get a resolver, it
>> would be a little bit nicer to be able to use the AuthenticationInfo
>> class instead of a plain map (for using the constructors and the 
>> constants)...
> 
> +1 to that, I'm also using that interface in [1] and having to depend
> on org.apache.sling.commons.auth just for this feels wrong.

But having the AuthenticationInfo as a request attribute feels even
wronger. Which is why I reopened SLING-1445.

> [1] 
> http://svn.apache.org/repos/asf/sling/trunk/contrib/extensions/bgservlets/src/main/java/org/apache/sling/bgservlets/impl/BackgroundRequestExecutionJob.java

You could also use something like ResourceResolver.clone(), right ?

Regards
Felix

[jira] Reopened: (SLING-1445) store the AuthenticationInfo object in a request attribute

[Felix Meschberger (JIRA)]

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

Felix Meschberger reopened SLING-1445:
--


Thinking about this, I come to the conclusion that this is a bad idea, because 
it makes the password readily available for requests to read 

What is the use case for having the AuthenticationInfo object as a request 
attribute ?

> store the AuthenticationInfo object in a request attribute
> --
>
> Key: SLING-1445
> URL: https://issues.apache.org/jira/browse/SLING-1445
> Project: Sling
>  Issue Type: Improvement
>  Components: Commons
>Reporter: Justin Edelson
>Assignee: Justin Edelson
> Fix For: Commons Auth 1.0.0
>
>
> called org.apache.sling.commons.auth.spi.AuthenticationInfo

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

Re: Exception when bundling commons auth

[Felix Meschberger]

Hi,

On 29.07.2010 11:52, Ian Boston wrote:
> 
> Hi 
> I am seeing the following when executing the maven bundle plugin in commons 
> auth.
> The MANIFEST.MF looks Ok.
> I think its caused by
>  
>   
> 
> org.apache.sling.api.auth;version="[$(version;==;$(@)),$(version;=+;$(@)))",

This is not really greek, rather it is APL ;-) Or, not really ;-)

No, it is a notation to configure the correct import version range for
an API implementor. In this case it generates the range [1.0,1.1).

> *
> 
> 
> which is greek to me, without reading the BND docs.
> 
> Any ideas,
> does it matter
> Ian
> Caused by: java.lang.IllegalArgumentException: Invalid syntax for version: 
> $...@}
>   at aQute.libg.version.Version.(Version.java:45)
>   at aQute.lib.osgi.Macro._version(Macro.java:627)

I do not exactly know, why this is thrown (it is thrown multiple times
during a full Sling build). But the end result is correct and everything
works fine.

So we can just ignore this.

Regards
Felix

Re: [RT] Using FileInstall

[Carsten Ziegeler]

Bertrand Delacretaz  wrote
> On Wed, Aug 4, 2010 at 3:53 PM, Carsten Ziegeler  wrote:
>> ...Now, I would like to extend this and just copy all files over, bundles
>> will get into the same location, all other files go into a single
>> "install" directory.
>> The only bundle which we will really install by launchpad is the File
>> Install bundle - which will be configured to listen for the directory
>> where everything got copied over
> 
> Sounds good. Too bad we're still duplicating a big part of the
> FileInstall logic in our osgi.installer module, it would be cool to
> merge both things at some point.
> 
Yepp, it is on my todo list :)

Regards
Carsten
-- 
Carsten Ziegeler
cziege...@apache.org

[jira] Resolved: (SLING-1631) Classloading problems when taglibs are used.

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler resolved SLING-1631.
-

Resolution: Fixed

Fixed in revision 982966
The taglib now uses the same logic for detecting taglib changes as the 
classloader uses for bundles
Simplified and fixed the timestamp checking for taglibs.

> Classloading problems when taglibs are used.
> 
>
> Key: SLING-1631
> URL: https://issues.apache.org/jira/browse/SLING-1631
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Affects Versions: Scripting JSP 2.0.8
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Scripting JSP 2.0.10
>
>
> When taglibs are used together with jsp scripting there are several problems:
> 1. The taglib cache does not detect changes to taglibs (contained in bundles) 
> like the general classloading mechanism through the dynamic classloader - 
> this can result in inconsistencies and classloading problems.
> 2. The last modified check for taglibs does not work as expected. As soon as 
> tags are used, they are considered as changed which results in recompilation 
> of the jsp and of the tag where the second invalidates the classloader of the 
> jsp. This classloader is later on used and then a classloading exception is 
> thrown

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

Re: [RT] Using FileInstall

[Bertrand Delacretaz]

On Wed, Aug 4, 2010 at 3:53 PM, Carsten Ziegeler  wrote:
> ...Now, I would like to extend this and just copy all files over, bundles
> will get into the same location, all other files go into a single
> "install" directory.
> The only bundle which we will really install by launchpad is the File
> Install bundle - which will be configured to listen for the directory
> where everything got copied over

Sounds good. Too bad we're still duplicating a big part of the
FileInstall logic in our osgi.installer module, it would be cool to
merge both things at some point.

-Bertrand

[jira] Resolved: (SLING-1219) Map test in JCR Resource Resolver web console plugin is not reflecting all cases

[Felix Meschberger (JIRA)]

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

Felix Meschberger resolved SLING-1219.
--

Resolution: Fixed

Thanks for providing the patch.
I have applied it in Rev. 982946.

> Map test in JCR Resource Resolver web console plugin is not reflecting all 
> cases
> 
>
> Key: SLING-1219
> URL: https://issues.apache.org/jira/browse/SLING-1219
> Project: Sling
>  Issue Type: Improvement
>  Components: JCR
>Affects Versions: JCR Resource 2.0.6
>Reporter: Alexander Klimetschek
>Assignee: Felix Meschberger
>Priority: Minor
> Fix For: JCR Resource 2.0.8
>
> Attachments: SLING-1219-second.patch, SLING-1219.patch
>
>
> The "Map" test in the web console plugin of the JCR resource resolver is 
> actually doing a
>  ResourceResolver.map(request, path)
> with the request being something like "http://null";, without even noting 
> that. This is misleading as one would at least expect that the current server 
> is used (ie. how the web console is accessed), eg. http://localhost in most 
> cases. This difference will give different results in many cases, eg. if an 
> internal redirect based on localhost.80 is configured.
> Also, there is a second map() only accepting a path which behaves different 
> in that it will always add the domain prefix if configured.
> For proper testing there should be a way to do all of them.

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

davidgsoc2010, suggested next steps

[Bertrand Delacretaz]

Hi Federico,

Here's what I suggest for the next steps for your GSoC project.

The GSoC timeline suggest stopping work on code this Monday August
9th, I think that's a good idea.

I don't see a need for more features, rather just fix the client-side
error reporting (see review message that I sent a few minutes ago),
and make sure CRUD functions work, I had problems with creating and
deleting entries in my test.

For next week I suggest that you work on the following things, in
order of priority:

1) Add technical docs, I suggest having them in your CMS as initial
content linked from the CMS home page.
What I'd like to see is a description of how the various use cases are
implemented, example for the "New Entry" use case:

==
User opens /david.new.esp, resource type of that node is "david".

Sling selects the /apps/david/new.esp script to process that request
(link to Sling servlet/script selection docs)

The new.esp script displays content entry form, embeds the ckeditor.

User fills and submits the form.

The SlingPostServlet (link to that) processes the form fields and
creates the corresponding content.
==

I think describing the use cases in such concise form would be useful
to Sling newbies, which are the target audience for this cms example.

The nice thing with having these docs in your content is that
"new.esp" for example can be a link to to that script, so people can
see it live immediately. /content/david can link to the json
representation of that node, etc.

As for the use cases to document I suggest:

Create new entry
List existing entries
Edit existing entry
Delete existing entry
Generate the tags content structure
Display tags using the Flash-based animation
List entries by tags
Search for entries
Create PDF renditions

2) Cleanup and comment the ESP and Java code
Make sure each source file includes a short comment that describes its purpose.
Point to Sling docs where appropriate in comments, using sling.apache.org URLs.
Remove any dead code.

If you can do these two things next week I think that would nicely
wrap up your project, and make it useful to Sling newbies.

I'll be traveling part of next week and the week after, so make sure
you submit the complete code as a patch to SLING-1438 before August
12th, even if not all docs are done by then. Tick the "Grant license
to ASF for inclusion in ASF works" if you agree with that, so that we
can eventually add the example to the Sling codebase.

As I already said, I'll do my final mentor evaluation of your GSoC
work in a week from now, August 12th or 13th, so make sure everything
looks good by then!

Thanks for your work,
-Bertrand

Re: [RT] Using FileInstall

[Felix Meschberger]

Hi,

+1 to using fileinstall

One point: I would extend the "fixed" bundles to be installed by the
commons.log bundle, which brings LogService and Logging APIs. This
should IMHO really be the very first bundle to be installed.

Regards
Felix

On 04.08.2010 15:53, Carsten Ziegeler wrote:
> Hi,
> 
> while trying to implement handling of initial configurations for the
> ConfigAdmin within our launchpad, I noticed that this is more difficult
> than I thought. The final problem is a class loading issue as the
> launchpad does not contain the compendium class (for config admin).
> For the same reason, the current support of deployment packages is
> broken in launchpad.
> 
> While trying to workaround these problems I came back to an idea I had a
> long time ago: instead of doing all these installs (bundle, configs,
> depl. pcks etc.) in our own code, why not use existing stuff?
> The FileInstall bundle from Apache Felix covers most of our use cases -
> there are some minor pieces missing. But we can add the required
> features there and avoid duplicate code by just using File Install.
> 
> Currently the launchpad copies the initial set of bundles to a file
> directory and creates a structure based on the start levels there.
> Bundles are then picked up from there and installed.
> 
> Now, I would like to extend this and just copy all files over, bundles
> will get into the same location, all other files go into a single
> "install" directory.
> The only bundle which we will really install by launchpad is the File
> Install bundle - which will be configured to listen for the directory
> where everything got copied over.
> 
> File Install picks up the bundles with the start levels, the configs and
> whatnot and just installs the stuff for us. As the directory is watched
> by File Install, changes are reflected as well.
> 
> So basically we have the same functionality with less code :)
> 
> I think getting all of this done for Sling 6 is too much. Therefore I
> would like to use File Install for everything else but bundles as a
> start: copying over those files to the install directory and start file
> install configured with that directory.
> 
> Note, that File Install is mainly used to get initial configuration into
> the system - so it's more bootstrapping - for everything else jcr
> install can be used. Or File Install is nice for all those scenarios
> where no repository is used :)
> 
> WDYT?
> 
> Carsten

Re: Creating ResourceProvider for Apache Camel?

[Felix Meschberger]

Hi,

On 05.08.2010 02:05, Jason Rose wrote:
> In my current project we use Camel (via ServiceMix) to handle all of our
> integration with our other applications.  The application I'm personally
> working on uses Sling/JCR to store most of its content, but a large amount
> of other stuff it uses is held in data stores in these other applications.
> 
> Currently, I'm creating servlets for every external application operation I
> want to expose, then manually invoking Camel to fetch/push data across the
> ESB.  Lately, I've been thinking of creating a ResourceProvider to expose
> all my camel endpoints as Resources, which would mesh a lot more cleanly
> with Sling.
> 
> Looking at the Sling source, I can see the ResourceResolver for JCR;
> ResourceProviderFactories for Servlets; and ResourceProviders for each of
> the filesystem, servlets, bundles, users, and the JCR.  My question is, what
> parts do I need to implement myself to have integration with ServiceMix as
> transparent as the other types of resources?

What you would implement is the ResourceProvider interface which returns
your own implementations of the Resource interface.

For examples you might want to look at the Bundle Resource Provider [1]
and the Filesystem Resource Provider [2].

Hope this helps.

Regards
Felix

[1]
http://svn.apache.org/repos/asf/sling/trunk/bundles/extensions/bundleresource
[2]
http://svn.apache.org/repos/asf/sling/trunk/bundles/extensions/fsresource

davidgsoc2010 r58, code review

[Bertrand Delacretaz]

Hi Federico,

Here are the raw comments from my review, I'll discuss the next
steps/priorities in a separate message.

Test scenario, action items marked with ->

Start sling launchpad/builder -standalone jar after deleting sling work folder

Build and install davidgsoc2010 libraries and core bundles in this order

Core bundle doesn't start, needs additional bundles:
org.apache.sling.commons.scheduler
org.apache.sling.commons.threads

core bundle now starts.

-> suggest a README.txt at the top of the davidgsoc2010 code tree that
describes the installation.

Open http://localhost:8080/content/david.home.html

-> should be david.html, as already mentioned.

Sometimes saving an entry doesn't work, server says

  Error while processing /content/david/2010/08/07/about_sling
  javax.jcr.AccessDeniedException: Access denied

even though I could save another entry seconds before.

Deleting entries didn't work either, didn't investigate.

-> need better client-side error messages to troubleshoot such things

Search functions seem to work ok, tested with minimal content only.

On /content/david.list.html the name of the entry should be a link to
READ, and remove that link. Reading is the standard operation.

-> change links

The libraries bundle should be split in two: ckeditor and swfobject
for tags display. Or more than two if it contains other independent
components - the idea is to have one bundle per independent component.
The convention is to use /libs, not /libraries for those types of
things.

-> split bundle

The core bundle source code structure is nice and clean now, that's
very cool: it contains just the applications layer of the mini-CMS.

-Bertrand

Re: [RT] SlingHttpServletRequest.externalize() methods

[Felix Meschberger]

Hi,

On 06.08.2010 12:07, Carsten Ziegeler wrote:
> Alexander Klimetschek  wrote
> 
>> Another reason for the prominent place is that it teaches people to do
>> the right thing more easily. I have seen many cases that create links
>> without considering context path or sling's mapping.
>>
> Hmm, but if a developer is not able to call map on the resource resolver
> why should he now call a method on the request (or response) ?

Excellent point: Have a look at Sling's
HttpServletResponse.encodeURL(String) method [1].

And yes, this is a method which has been there for a long time, but
developers don't seem to be used to use it ;-)

So -1 to adding such a method.

Regards
Felix

[1]
http://svn.apache.org/repos/asf/sling/trunk/bundles/engine/src/main/java/org/apache/sling/engine/impl/SlingHttpServletResponseImpl.java

> Maybe the map method is not very prominently placed, but I would rather
> do an example showing people how to do it, instead of adding all kind of
> stuff to the request interface.
> Again, maybe this stuff is very useful for everyone and it makes sense
> to add it to a more prominent place. But atm I doubt this.
> 
> Carsten

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

[Alison Heimoz]

No probs - have got it ready to scan and send on Monday.
Cheers Alison

On Fri, Aug 6, 2010 at 2:07 PM, Felix Meschberger wrote:

> Hi,
>
> On 06.08.2010 09:06, Bertrand Delacretaz wrote:
> > On Fri, Aug 6, 2010 at 8:21 AM, Carsten Ziegeler 
> wrote:
> >> ...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
>
> >
> > +1, but Alison will IMO need to file an iCLA [1] before being granted
> > write access.
>
> Yes, that's required.
>
> Regards
> Felix
>
> >
> > -Bertrand
> >
> > [1] http://www.apache.org/licenses/icla.txt
> >
> >>
> >> Regards
> >> Carsten
> >>
> >> Alison Heimoz  wrote
> >>> Hi Carsten
> >>>
> >>> +1 for Jean Christophe.
> >>>
> >>> And can I add my own name to the request for access rights to
> documentation?
> >>>
> >>> I've already entered a few Jiras on documentation after
> reviewing/testing
> >>> some of the getting started/introduction pages.
> >>> It would make it quicker if I could update directly as well.
> >>>
> >>> Cheers Alison
> >>>
> >>>
> >>> 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.
> 
>  Regards
>  Carsten
> 
>  Jean Christophe Kautzmann  wrote
> > Hi,
> >
> > How about adding a hint to the docs stating that other bundles might
> be
> > needed and that a list of dependencies can be found in the
> manifest.mf
>  file
> > of the scheduler bundle?
> > I'd volunteer to adapt the docs (that I happen to draft with Carsten)
> > accordingly but I'd need access rights for that :)
> >
> > Cheers JC
> >
> > On Thu, Aug 5, 2010 at 1:14 PM, Mike Müller 
> wrote:
> >
> >> Hi
> >>
> >> Such depencies are reflected in the manifest.mf file of each
> >> bundle. I don't think it's a good idea, to put them manually
> >> into the documentation, as long as they can change over time.
> >>
> >> best regards
> >> mike
> >>
> >>> -Original Message-
> >>> From: Federico Paparoni [mailto:federico.papar...@gmail.com]
> >>> Sent: Thursday, August 05, 2010 10:04 AM
> >>> To: us...@sling.apache.org
> >>> Subject: Re: Scheduler service problem
> >>>
> >>>
> >>> 2010/8/5 Carsten Ziegeler 
> >>>
>  Hi,
> 
>  the scheduler needs two other bundles:
> 
>  org.apache.commons.collections (which should be installed)
>  org.apache.sling.commons.threads 3.0.0
> 
>  Regards
>  Carsten
> 
> 
> >>> Now everything works, thanks.
> >>> Anyway I think these informations should be available on the
> >>> documentation (
> >>> http://sling.apache.org/site/scheduler-service-commons-schedul
> >> er.html<
> 
> http://sling.apache.org/site/scheduler-service-commons-schedul%0Aer.html>
> >> ).
> >>
> >> --
> >> Federico
> >>
> >
> 
> 
>  --
>  Carsten Ziegeler
>  cziege...@apache.org
> 
> >>>
> >>
> >>
> >> --
> >> Carsten Ziegeler
> >> cziege...@apache.org
> >>
> >
>
>

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

[Felix Meschberger]

Hi,

On 06.08.2010 09:06, Bertrand Delacretaz wrote:
> On Fri, Aug 6, 2010 at 8:08 AM, Carsten Ziegeler  wrote:
>> 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

> 
> +1, but Jean-Christophe will IMO need to file an iCLA [1] before being
> granted write access.

Yes, that's required.

Regards
Felix

> 
> -Bertrand
> 
> [1] http://www.apache.org/licenses/icla.txt
> 
> 
>> Jean Christophe Kautzmann  wrote
>>> Hi,
>>>
>>> How about adding a hint to the docs stating that other bundles might be
>>> needed and that a list of dependencies can be found in the manifest.mf file
>>> of the scheduler bundle?
>>> I'd volunteer to adapt the docs (that I happen to draft with Carsten)
>>> accordingly but I'd need access rights for that :)
>>>
>>> Cheers JC
>>>
>>> On Thu, Aug 5, 2010 at 1:14 PM, Mike Müller  wrote:
>>>
 Hi

 Such depencies are reflected in the manifest.mf file of each
 bundle. I don't think it's a good idea, to put them manually
 into the documentation, as long as they can change over time.

 best regards
 mike

> -Original Message-
> From: Federico Paparoni [mailto:federico.papar...@gmail.com]
> Sent: Thursday, August 05, 2010 10:04 AM
> To: us...@sling.apache.org
> Subject: Re: Scheduler service problem
>
>
> 2010/8/5 Carsten Ziegeler 
>
>> Hi,
>>
>> the scheduler needs two other bundles:
>>
>> org.apache.commons.collections (which should be installed)
>> org.apache.sling.commons.threads 3.0.0
>>
>> Regards
>> Carsten
>>
>>
> Now everything works, thanks.
> Anyway I think these informations should be available on the
> documentation (
> http://sling.apache.org/site/scheduler-service-commons-schedul
 er.html
 ).

 --
 Federico

>>>
>>
>>
>> --
>> Carsten Ziegeler
>> cziege...@apache.org
>>
> 

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

[Felix Meschberger]

Hi,

On 06.08.2010 09:06, Bertrand Delacretaz wrote:
> On Fri, Aug 6, 2010 at 8:21 AM, Carsten Ziegeler  wrote:
>> ...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

> 
> +1, but Alison will IMO need to file an iCLA [1] before being granted
> write access.

Yes, that's required.

Regards
Felix

> 
> -Bertrand
> 
> [1] http://www.apache.org/licenses/icla.txt
> 
>>
>> Regards
>> Carsten
>>
>> Alison Heimoz  wrote
>>> Hi Carsten
>>>
>>> +1 for Jean Christophe.
>>>
>>> And can I add my own name to the request for access rights to documentation?
>>>
>>> I've already entered a few Jiras on documentation after reviewing/testing
>>> some of the getting started/introduction pages.
>>> It would make it quicker if I could update directly as well.
>>>
>>> Cheers Alison
>>>
>>>
>>> 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.

 Regards
 Carsten

 Jean Christophe Kautzmann  wrote
> Hi,
>
> How about adding a hint to the docs stating that other bundles might be
> needed and that a list of dependencies can be found in the manifest.mf
 file
> of the scheduler bundle?
> I'd volunteer to adapt the docs (that I happen to draft with Carsten)
> accordingly but I'd need access rights for that :)
>
> Cheers JC
>
> On Thu, Aug 5, 2010 at 1:14 PM, Mike Müller  wrote:
>
>> Hi
>>
>> Such depencies are reflected in the manifest.mf file of each
>> bundle. I don't think it's a good idea, to put them manually
>> into the documentation, as long as they can change over time.
>>
>> best regards
>> mike
>>
>>> -Original Message-
>>> From: Federico Paparoni [mailto:federico.papar...@gmail.com]
>>> Sent: Thursday, August 05, 2010 10:04 AM
>>> To: us...@sling.apache.org
>>> Subject: Re: Scheduler service problem
>>>
>>>
>>> 2010/8/5 Carsten Ziegeler 
>>>
 Hi,

 the scheduler needs two other bundles:

 org.apache.commons.collections (which should be installed)
 org.apache.sling.commons.threads 3.0.0

 Regards
 Carsten


>>> Now everything works, thanks.
>>> Anyway I think these informations should be available on the
>>> documentation (
>>> http://sling.apache.org/site/scheduler-service-commons-schedul
>> er.html<
 http://sling.apache.org/site/scheduler-service-commons-schedul%0Aer.html>
>> ).
>>
>> --
>> Federico
>>
>


 --
 Carsten Ziegeler
 cziege...@apache.org

>>>
>>
>>
>> --
>> Carsten Ziegeler
>> cziege...@apache.org
>>
> 

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!

[jira] Created: (SLING-1631) Classloading problems when taglibs are used.

[Carsten Ziegeler (JIRA)]

Classloading problems when taglibs are used.


 Key: SLING-1631
 URL: https://issues.apache.org/jira/browse/SLING-1631
 Project: Sling
  Issue Type: Bug
  Components: Scripting
Affects Versions: Scripting JSP 2.0.8
Reporter: Carsten Ziegeler
Assignee: Carsten Ziegeler
 Fix For: Scripting JSP 2.0.10


When taglibs are used together with jsp scripting there are several problems:
1. The taglib cache does not detect changes to taglibs (contained in bundles) 
like the general classloading mechanism through the dynamic classloader - this 
can result in inconsistencies and classloading problems.
2. The last modified check for taglibs does not work as expected. As soon as 
tags are used, they are considered as changed which results in recompilation of 
the jsp and of the tag where the second invalidates the classloader of the jsp. 
This classloader is later on used and then a classloading exception is thrown

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

Re: [RT] SlingHttpServletRequest.externalize() methods

[Carsten Ziegeler]

Alexander Klimetschek  wrote

> Another reason for the prominent place is that it teaches people to do
> the right thing more easily. I have seen many cases that create links
> without considering context path or sling's mapping.
> 
Hmm, but if a developer is not able to call map on the resource resolver
why should he now call a method on the request (or response) ?
Maybe the map method is not very prominently placed, but I would rather
do an example showing people how to do it, instead of adding all kind of
stuff to the request interface.
Again, maybe this stuff is very useful for everyone and it makes sense
to add it to a more prominent place. But atm I doubt this.

Carsten
-- 
Carsten Ziegeler
cziege...@apache.org

Re: [RT] SlingHttpServletRequest.externalize() methods

[Alexander Klimetschek]

On Fri, Aug 6, 2010 at 10:24, Carsten Ziegeler  wrote:
> Alexander Klimetschek  wrote
>> On Fri, Aug 6, 2010 at 08:10, Carsten Ziegeler  wrote:
>>> What about a helper class (static methods) or a jsp taglib?
>>
>> I was preferring them on the request, as you then don't need to pass
>> the request and things get shorter. A jsp taglib can also only be used
>> inside a jsp.
>>
> Sure but you were talking about jsps in your proposal :)

And servlets.

> Anyway, there are always a lot of useful functions one needs here or
> there - adding all of them to the request interface just because it is a
> little bit less to type does not sound like the best argument to me.
> That's why I would put them in a helper class first - if they are used
> by each and everyone in every script, then this might be a candidate to
> add it to a more prominent place.

Another reason for the prominent place is that it teaches people to do
the right thing more easily. I have seen many cases that create links
without considering context path or sling's mapping.

Regards,
Alex

-- 
Alexander Klimetschek
alexander.klimetsc...@day.com

Re: [RT] SlingHttpServletRequest.externalize() methods

[Bertrand Delacretaz]

On Fri, Aug 6, 2010 at 10:24 AM, Carsten Ziegeler  wrote:
> ...there are always a lot of useful functions one needs here or
> there - adding all of them to the request interface just because it is a
> little bit less to type does not sound like the best argument to me.
> That's why I would put them in a helper class first - if they are used
> by each and everyone in every script, then this might be a candidate to
> add it to a more prominent place...

+1

-Bertrand

Re: [RT] SlingHttpServletRequest.externalize() methods

[Carsten Ziegeler]

Alexander Klimetschek  wrote
> On Fri, Aug 6, 2010 at 08:10, Carsten Ziegeler  wrote:
>> What about a helper class (static methods) or a jsp taglib?
> 
> I was preferring them on the request, as you then don't need to pass
> the request and things get shorter. A jsp taglib can also only be used
> inside a jsp.
> 
Sure but you were talking about jsps in your proposal :)
Anyway, there are always a lot of useful functions one needs here or
there - adding all of them to the request interface just because it is a
little bit less to type does not sound like the best argument to me.
That's why I would put them in a helper class first - if they are used
by each and everyone in every script, then this might be a candidate to
add it to a more prominent place.

Carsten
-- 
Carsten Ziegeler
cziege...@apache.org

Re: [RT] SlingHttpServletRequest.externalize() methods

[Alexander Klimetschek]

On Fri, Aug 6, 2010 at 08:10, Carsten Ziegeler  wrote:
> What about a helper class (static methods) or a jsp taglib?

I was preferring them on the request, as you then don't need to pass
the request and things get shorter. A jsp taglib can also only be used
inside a jsp.

Regards,
Alex

-- 
Alexander Klimetschek
alexander.klimetsc...@day.com

Fwd: Apache Retreat in Hursley, UK - 17-19th September

[Bertrand Delacretaz]

-- Forwarded message --
From: Nick Burch 
Date: Thu, Aug 5, 2010 at 7:39 PM
Subject: Please Forward - Apache Retreat in Hursley, UK - 17-19th September
To: p...@apache.org


Hi All

Below are details of an upcoming Apache Retreat in the UK.

Firstly, could you please forward the email below (without this PMC
information part!) to your dev@ list, to both invite your committers
to the whole event, and invite active contributors to the Saturday
BarCamp.

Secondly, if there are any members of your community who are not
currently committers, but are close to being, please invite them to
attend the whole weekend (which is by default committers only). This
will hopefully be a great chance for nearly-committers to learn more
about the Apache Way, which should lead to them being full committers
sooner!

Thanks
Nick
(On behalf of the retreat organising committee)

===
From: Nick Burch 
To: retre...@apache.org
Reply-To: retre...@apache.org
Subject: Apache Retreat in Hursley, UK - 17-19th September

Hi All

Just a reminder that our next Apache Retreat will be in Hursley in the
UK, from the 17th - 19th September. That's a little over a month away
now!

If you're an Apache Committer, we'd like to invite you to come for the
whole weekend. We've booked Tipis to stay in(!), catering on-site,
we've conference facilities sorted for running a BarCamp both days,
we'll be doing lightning talks, socialising, hacking etc.

If you're a user of Apache software, we'd love for you to come along
in the day on the Saturday. We're running a BarCamp in the day, and
it'll be great chance to learn more about new Apache projects, how the
Apache Way leads us to develop software, as well as to talk about your
current projects.

More details on the event, and a link to the signup site are available
from the ApacheCon wiki:
       http://wiki.apache.org/apachecon/
(Signup is available now for the whole retreat, and he barcamp signup
will open on Monday)

Also, if funding would be an issue to stop you attending, then the
Travel Assistance Committee are accepting applications for assistance
to attend until Wednesday 11th. More details, and a link to the
applications site are available from:
       http://www.apache.org/travel/

Nick
(On behalf of the retreat organising committee)

Re: Allow modify during "import" operation

[Bertrand Delacretaz]

On Thu, Aug 5, 2010 at 7:36 PM, Simon Gaeremynck  wrote:
> This issue has been reported as [1] SLING-1627 and a patch was provided.
> Is it possible to merge this in as this is blocking a Sakai release.
>...
> [1] https://issues.apache.org/jira/browse/SLING-1627

Looking at that patch, Zach reused the existing
ImportOptions.isOverwrite() flag, instead of defining a new
isPropertyOverwrite() one as some of us suggested.

I think that introduces an incompatible change, whereas defining a new
option means that old code would continue to work unchanged.

-Bertrand

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

[Bertrand Delacretaz]

On Fri, Aug 6, 2010 at 8:08 AM, Carsten Ziegeler  wrote:
> 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, but Jean-Christophe will IMO need to file an iCLA [1] before being
granted write access.

-Bertrand

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


> Jean Christophe Kautzmann  wrote
>> Hi,
>>
>> How about adding a hint to the docs stating that other bundles might be
>> needed and that a list of dependencies can be found in the manifest.mf file
>> of the scheduler bundle?
>> I'd volunteer to adapt the docs (that I happen to draft with Carsten)
>> accordingly but I'd need access rights for that :)
>>
>> Cheers JC
>>
>> On Thu, Aug 5, 2010 at 1:14 PM, Mike Müller  wrote:
>>
>>> Hi
>>>
>>> Such depencies are reflected in the manifest.mf file of each
>>> bundle. I don't think it's a good idea, to put them manually
>>> into the documentation, as long as they can change over time.
>>>
>>> best regards
>>> mike
>>>
 -Original Message-
 From: Federico Paparoni [mailto:federico.papar...@gmail.com]
 Sent: Thursday, August 05, 2010 10:04 AM
 To: us...@sling.apache.org
 Subject: Re: Scheduler service problem


 2010/8/5 Carsten Ziegeler 

> Hi,
>
> the scheduler needs two other bundles:
>
> org.apache.commons.collections (which should be installed)
> org.apache.sling.commons.threads 3.0.0
>
> Regards
> Carsten
>
>
 Now everything works, thanks.
 Anyway I think these informations should be available on the
 documentation (
 http://sling.apache.org/site/scheduler-service-commons-schedul
>>> er.html
>>> ).
>>>
>>> --
>>> Federico
>>>
>>
>
>
> --
> Carsten Ziegeler
> cziege...@apache.org
>

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

[Bertrand Delacretaz]

On Fri, Aug 6, 2010 at 8:21 AM, Carsten Ziegeler  wrote:
> ...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, but Alison will IMO need to file an iCLA [1] before being granted
write access.

-Bertrand

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

>
> Regards
> Carsten
>
> Alison Heimoz  wrote
>> Hi Carsten
>>
>> +1 for Jean Christophe.
>>
>> And can I add my own name to the request for access rights to documentation?
>>
>> I've already entered a few Jiras on documentation after reviewing/testing
>> some of the getting started/introduction pages.
>> It would make it quicker if I could update directly as well.
>>
>> Cheers Alison
>>
>>
>> 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.
>>>
>>> Regards
>>> Carsten
>>>
>>> Jean Christophe Kautzmann  wrote
 Hi,

 How about adding a hint to the docs stating that other bundles might be
 needed and that a list of dependencies can be found in the manifest.mf
>>> file
 of the scheduler bundle?
 I'd volunteer to adapt the docs (that I happen to draft with Carsten)
 accordingly but I'd need access rights for that :)

 Cheers JC

 On Thu, Aug 5, 2010 at 1:14 PM, Mike Müller  wrote:

> Hi
>
> Such depencies are reflected in the manifest.mf file of each
> bundle. I don't think it's a good idea, to put them manually
> into the documentation, as long as they can change over time.
>
> best regards
> mike
>
>> -Original Message-
>> From: Federico Paparoni [mailto:federico.papar...@gmail.com]
>> Sent: Thursday, August 05, 2010 10:04 AM
>> To: us...@sling.apache.org
>> Subject: Re: Scheduler service problem
>>
>>
>> 2010/8/5 Carsten Ziegeler 
>>
>>> Hi,
>>>
>>> the scheduler needs two other bundles:
>>>
>>> org.apache.commons.collections (which should be installed)
>>> org.apache.sling.commons.threads 3.0.0
>>>
>>> Regards
>>> Carsten
>>>
>>>
>> Now everything works, thanks.
>> Anyway I think these informations should be available on the
>> documentation (
>> http://sling.apache.org/site/scheduler-service-commons-schedul
> er.html<
>>> http://sling.apache.org/site/scheduler-service-commons-schedul%0Aer.html>
> ).
>
> --
> Federico
>

>>>
>>>
>>> --
>>> Carsten Ziegeler
>>> cziege...@apache.org
>>>
>>
>
>
> --
> Carsten Ziegeler
> cziege...@apache.org
>