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 is
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 to be used
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 better
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...
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 as we remember that
Alexander Klimetschek wrote
On Wed, Mar 17, 2010 at 16:07, Carsten Ziegeler cziege...@apache.org 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
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
Hi,
On Wed, Mar 17, 2010 at 2:45 AM, Justin Edelson justinedel...@gmail.com 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
Bertrand Delacretaz wrote
Hi,
On Wed, Mar 17, 2010 at 2:45 AM, Justin Edelson justinedel...@gmail.com
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
Hi,
On Wed, Mar 17, 2010 at 9:41 AM, Carsten Ziegeler cziege...@apache.org 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.
Bertrand Delacretaz wrote
Hi,
On Wed, Mar 17, 2010 at 9:41 AM, Carsten Ziegeler cziege...@apache.org
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
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
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 just
On 3/17/10 4:31 AM, Bertrand Delacretaz wrote:
Hi,
On Wed, Mar 17, 2010 at 2:45 AM, Justin Edelson justinedel...@gmail.com
wrote:
Currently, although it's possible to log into different workspaces via
AuthenticationInfo (even if httpauth and formauth don't support this);
script resolution
Hi,
On Wed, Mar 17, 2010 at 1:55 PM, Justin Edelson justinedel...@gmail.com 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
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. The
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
On Wed, Mar 17, 2010 at 2:08 PM, Justin Edelson justinedel...@gmail.com 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
On 3/17/10 9:20 AM, Bertrand Delacretaz wrote:
On Wed, Mar 17, 2010 at 2:08 PM, Justin Edelson
justinedel...@gmail.com 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
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
justinedel...@gmail.com wrote:
... For example, if you think about how Google App Engine allows you to
reference arbitrary versions of your
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
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);
(NB this is
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.getServerName() and
+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
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 seem to recall
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.getServerName() reports; I would
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
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
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 lines
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 don't think
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 have?
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 use
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 and see what
On Wed, Mar 17, 2010 at 16:07, Carsten Ziegeler cziege...@apache.org 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
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 restriction - it seems to me you should resolve
scripts from
35 matches
Mail list logo
