On 3/19/10 10:16 AM, Felix Meschberger wrote:
>> ResourceResolver scriptResolver =
>> request.getResourceResolver().sudo(scriptUser);
>> try {
>> ... resolve ...
>> } finally {
>> scriptResolver.close();
>> }
>>
>> WDYT?
>
> +1 but name it "impersonate" to align it with JCR API.
OK, just so long
Hi Justin,
thanks a lot for your swift response.
> I think the subject of this thread is slightly misleading... it really
> should be "scripts should be resolved from the same workspace as
> resources". Which is essentially the summary of SLING-1446.
ahhh ok, that definitely makes more sense...
Hi,
On 19.03.2010 04:15, Justin Edelson wrote:
> This bit:
>
>> Looking at SlingServletResolver, something like this is needed anyway in
>> order to make SlingServletResolver independent of JCR.
>
> is wrong. Not sure what I was thinking.
>
> But... in figuring out I was wrong, I came up with a
Hi,
On 3/19/10 2:43 AM, Carsten Ziegeler wrote:
> Hi,
>
> Justin Edelson wrote
>> Hi,
>>
>> This is a longish email which I wrote in bursts over a few hours, so I
>> apologize in advance if it's not completely coherent. Basically, I think
>> we should do both... allow for the request's workspace
On 3/19/10 2:59 AM, David Nuescheler wrote:
> I just saw the topic of this thread and thought i would like to weigh in on
> this conversation...
I think the subject of this thread is slightly misleading... it really
should be "scripts should be resolved from the same workspace as
resources". Which
I just saw the topic of this thread and thought i would like to weigh in on
this conversation...
Workspaces are just about one of the most frequently abused feature
of JCR and I have a feeling that this thread may forget what workspaces
are for.
Workspaces are for .clone(), .merge() and .update()
Hi,
Justin Edelson wrote
> Hi,
>
> This is a longish email which I wrote in bursts over a few hours, so I
> apologize in advance if it's not completely coherent. Basically, I think
> we should do both... allow for the request's workspace to be used for
> script resolution AND provide the ability
This bit:
> Looking at SlingServletResolver, something like this is needed anyway in
> order to make SlingServletResolver independent of JCR.
is wrong. Not sure what I was thinking.
But... in figuring out I was wrong, I came up with a better solution:
Instead of:
> ResourceResolverFactory needs
Hi,
This is a longish email which I wrote in bursts over a few hours, so I
apologize in advance if it's not completely coherent. Basically, I think
we should do both... allow for the request's workspace to be used for
script resolution AND provide the ability to mount non-default
workspaces under
Alexander Klimetschek wrote
> On Wed, Mar 17, 2010 at 16:07, Carsten Ziegeler wrote:
>> Carsten Ziegeler wrote
>>> I still have the feeling that mounting other workspaces into the
>>> resource tree is the easier way.
>>> With that we wouldn't need to change content loading, resource events
>>> a
On Wed, Mar 17, 2010 at 16:07, Carsten Ziegeler wrote:
> Carsten Ziegeler wrote
>> I still have the feeling that mounting other workspaces into the
>> resource tree is the easier way.
>> With that we wouldn't need to change content loading, resource events
>> and maybe other things to come?
>>
>>
Carsten Ziegeler wrote
> Carsten Ziegeler wrote
>> I still have the feeling that mounting other workspaces into the
>> resource tree is the easier way.
>> With that we wouldn't need to change content loading, resource events
>> and maybe other things to come?
>>
>> Can we go a step back please an
On 3/17/10 11:03 AM, Carsten Ziegeler wrote:
> I still have the feeling that mounting other workspaces into the
> resource tree is the easier way.
> With that we wouldn't need to change content loading, resource events
> and maybe other things to come?
>
> Can we go a step back please and see what
Carsten Ziegeler wrote
> I still have the feeling that mounting other workspaces into the
> resource tree is the easier way.
> With that we wouldn't need to change content loading, resource events
> and maybe other things to come?
>
> Can we go a step back please and see what use cases we really
I still have the feeling that mounting other workspaces into the
resource tree is the easier way.
With that we wouldn't need to change content loading, resource events
and maybe other things to come?
Can we go a step back please and see what use cases we really have?
Carsten
--
Carsten Ziegeler
On 3/17/10 10:50 AM, Felix Meschberger wrote:
> Hi,
>
> On 17.03.2010 15:46, Justin Edelson wrote:
>> Felix-
>> I know this probably isn't a great answer, but I think we just have to
>> start somewhere. If the answer is that this should happen in a branch,
>> I'm fine with that, but I personally d
Hi,
On 17.03.2010 15:46, Justin Edelson wrote:
> Felix-
> I know this probably isn't a great answer, but I think we just have to
> start somewhere. If the answer is that this should happen in a branch,
> I'm fine with that, but I personally don't think it's necessary - any
> change along these lin
Felix-
I know this probably isn't a great answer, but I think we just have to
start somewhere. If the answer is that this should happen in a branch,
I'm fine with that, but I personally don't think it's necessary - any
change along these lines should be able to be fully backwards compatible.
Two o
On 3/17/10 10:35 AM, Felix Meschberger wrote:
> Strange. This hints at a servlet container issue, because the
> getServerName method is defined to:
Definitely possible. The app server was built pre-J2EE and plenty
quirky. It's since been discontinued. Like I said, possible this was to
workaround an
Hi,
On 17.03.2010 15:27, Justin Edelson wrote:
> On 3/17/10 10:16 AM, Felix Meschberger wrote:
>> Hi,
>>
>> On 17.03.2010 15:09, Justin Edelson wrote:
>>> On 3/17/10 9:49 AM, Felix Meschberger wrote:
>String host = request.getHeader("Host");
(NB this is what request.getServer
On 3/17/10 10:16 AM, Felix Meschberger wrote:
> Hi,
>
> On 17.03.2010 15:09, Justin Edelson wrote:
>> On 3/17/10 9:49 AM, Felix Meschberger wrote:
String host = request.getHeader("Host");
>>>
>>> (NB this is what request.getServerName() reports; I would prefer to use
>>> the API)
>> (I
Hi,
On 17.03.2010 15:09, Justin Edelson wrote:
> On 3/17/10 9:49 AM, Felix Meschberger wrote:
>>>String host = request.getHeader("Host");
>>
>> (NB this is what request.getServerName() reports; I would prefer to use
>> the API)
> (I seem to recall running into trouble with request.getServe
+1
I was in same situation - I can resolve that problem the resource will be
selected as virtual domain, but for me it's little problematic that the scripts
comes from default repository. (For security and versioning reasons sometimes
some domain's repository better if separeted - for example i
On 3/17/10 9:49 AM, Felix Meschberger wrote:
>> public class WorkspacePicker implements AuthenticationInfoPostProcessor {
>>public void postProcess(AuthenticationInfo info, HttpServletRequest
>> request, HttpServletResponse response) {
>>String host = request.getHeader("Host");
>
> (
Hi,
On 17.03.2010 02:45, Justin Edelson wrote:
> Currently, although it's possible to log into different workspaces via
> AuthenticationInfo (even if httpauth and formauth don't support this);
> script resolution only happens against the default workspace. I don't
> see any reason for this restric
Hi,
On 17.03.2010 14:40, Justin Edelson wrote:
> On 3/17/10 9:20 AM, Bertrand Delacretaz wrote:
>> On Wed, Mar 17, 2010 at 2:08 PM, Justin Edelson
> wrote:
>>> ... For example, if you think about how Google App Engine allows you to
>>> reference arbitrary versions of your application with a host
On Wed, Mar 17, 2010 at 14:17, Justin Edelson wrote:
> In general, this works... But script resolution is different because it
> uses a separate session.
>
> So today, you can write a minimal amount of code to switch workspaces
> based on a request header. This isn't in the core. However, even if
On 3/17/10 9:20 AM, Bertrand Delacretaz wrote:
> On Wed, Mar 17, 2010 at 2:08 PM, Justin Edelson
wrote:
>> ... For example, if you think about how Google App Engine allows you to
>> reference arbitrary versions of your application with a host name like
>> version.appname.appspot.com (IIRC), one co
On Wed, Mar 17, 2010 at 2:08 PM, Justin Edelson wrote:
>... For example, if you think about how Google App Engine allows you to
> reference arbitrary versions of your application with a host name like
> version.appname.appspot.com (IIRC), one could imagine using the host
> header to select the wor
On 3/17/10 7:05 AM, Alexander Klimetschek wrote:
> The question for one workspace per account / user / etc. pops up every
> now and then on the jackrabbit mailing lists and the general answer is
> to try to stay away from that as it just complicates things: why
> having to work with multiple worksp
On 3/17/10 4:41 AM, Carsten Ziegeler wrote:
> I'm not sure what the best way is, but Sling is resource tree based. The
> resource resolver (factory) gets configured with resource search paths
> (/apps and /libs is default) for scripts.
> The script resolver uses these paths to search for scripts. T
Hi,
On Wed, Mar 17, 2010 at 1:55 PM, Justin Edelson wrote:
> On 3/17/10 4:31 AM, Bertrand Delacretaz wrote:
>> ...Assuming you use workspaces for multi-homed websites, one could
>> imagine having a "generic scripts" workspace where the script
>> resolution would look after looking in the current
On 3/17/10 4:31 AM, Bertrand Delacretaz wrote:
> Hi,
>
> On Wed, Mar 17, 2010 at 2:45 AM, Justin Edelson
> wrote:
>> Currently, although it's possible to log into different workspaces via
>> AuthenticationInfo (even if httpauth and formauth don't support this);
>> script resolution only happens
Alexander Klimetschek wrote
> The question for one workspace per account / user / etc. pops up every
> now and then on the jackrabbit mailing lists and the general answer is
> to try to stay away from that as it just complicates things: why
> having to work with multiple workspaces when you can ju
The question for one workspace per account / user / etc. pops up every
now and then on the jackrabbit mailing lists and the general answer is
to try to stay away from that as it just complicates things: why
having to work with multiple workspaces when you can just create
separate nodes? Workspaces
Bertrand Delacretaz wrote
> Hi,
>
> On Wed, Mar 17, 2010 at 9:41 AM, Carsten Ziegeler
> wrote:
>> ...In general I am not sure if it should be the authentication which
>> defines what workspace is used. I rather could picture having a resource
>> tree where workspaces are mounted at different lo
Hi,
On Wed, Mar 17, 2010 at 9:41 AM, Carsten Ziegeler wrote:
> ...In general I am not sure if it should be the authentication which
> defines what workspace is used. I rather could picture having a resource
> tree where workspaces are mounted at different locations in the tree.
> The script resol
Bertrand Delacretaz wrote
> Hi,
>
> On Wed, Mar 17, 2010 at 2:45 AM, Justin Edelson
> wrote:
>> Currently, although it's possible to log into different workspaces via
>> AuthenticationInfo (even if httpauth and formauth don't support this);
>> script resolution only happens against the default
Hi,
On Wed, Mar 17, 2010 at 2:45 AM, Justin Edelson wrote:
> Currently, although it's possible to log into different workspaces via
> AuthenticationInfo (even if httpauth and formauth don't support this);
> script resolution only happens against the default workspace. I don't
> see any reason for
39 matches
Mail list logo
