Re: Board Report
Hi all, Felix Meschberger schrieb: > Hi all, > > We are once again due to report to the Board. I prepared a Wiki page for > this report at [1]. > > Please fill in any items I have been missing (or fix mine ;-) ). > > I will submit the report to the Incubator PMC next Tuesday (11/11). Report [1] is on file [2]. Regards Felix [1] http://cwiki.apache.org/SLING/incubator-status-report-november-2008.html [2] http://wiki.apache.org/incubator/November2008
Re: Replacing JcrResourceResolverFactory by a Sling ResourceResolverFactory
I like the proposal :) I've a few comments. I think we don't need constants for workspace or session for the login stuff. At least the workspace should/could be a configuration of the jcr resource resolver factory. The other thing is that I'm a little bit unsure how login really should work. I think we should not login into all providers upfront. Let's say if a provider is responsible for /a but this path is never accessed by the user, it doesn't matter if the user is able to login into this provider or not. So we need some kind of lazy login I guess (but this might make exception handling or the case if a login fails more complicated) I could also imagine some kind of sso - so this might be a little bit misleading term here. There is a master provider, let's say jcr. This one might be able to add login credentials used by the other providers to login. Perhaps we could add some plugin mechanism here to add credentials based on a successful login into one provider? I haven't thought this through yet, these are just my first unsorted comments :) Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Sling breaks with pax-web 0.5.1
Hi Bertrand,
Thanks for the followup - we've since traced the problem down to being
paxweb 0.5.1 itself and not sling. We've raised a ticket over at OPS4J and
the issue is scheduled for a 0.5.2 release:
http://issues.ops4j.org/jira/browse/PAXWEB-108
Mark
On Wed, Nov 12, 2008 at 12:31 AM, Bertrand Delacretaz <
[EMAIL PROTECTED]> wrote:
> Hi Mark,
>
> Going through my mail backlog I notice that we haven't replied to your
> question, is that still current?
>
> If yes it might be safer to create a JIRA issue so that doesn't fall
> into the cracks - apparently none of us had an answer off the top of
> their head.
>
> -Bertrand
>
> On Sun, Oct 19, 2008 at 11:55 PM, Mark Derricutt <[EMAIL PROTECTED]> wrote:
> > Hi all,
> >
> > We recently updated our sling based application (based around the
> > sling-launchpad osgi deployer) to use pax-web-server 0.5.1 (which uses
> NIO)
> > and have noticed that for some reason none of sling content gets returned
> > anymore, instead we see:
> >
> > ** Node dumped by StreamRendererServlet**
> > Node path:/
> > Resource metadata: {sling.resolutionPath=/}
> >
> > ** Node properties **
> > jcr:primaryType: rep:root
> >
> >
> > being output to the browser. Is this a known issue or something new? Is
> > there anything I can look at to try and diagnose whats going on?
> >
> > Mark
> >
> > --
> > "It is easier to optimize correct code than to correct optimized code."
> --
> > Bill Harlan
> >
>
--
"It is easier to optimize correct code than to correct optimized code." --
Bill Harlan
[jira] Closed: (SLING-727) Allow AuthenticationHandler to assign a workspace to credentials
[ https://issues.apache.org/jira/browse/SLING-727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marc closed SLING-727. -- It works fine, thanks. > Allow AuthenticationHandler to assign a workspace to credentials > > > Key: SLING-727 > URL: https://issues.apache.org/jira/browse/SLING-727 > Project: Sling > Issue Type: Improvement > Components: Engine >Affects Versions: Engine 2.0.2 >Reporter: Marc >Assignee: Felix Meschberger > Fix For: Engine 2.0.4 > > > A custom AuthenticationHandler should be able to add a JCR workspace to the > credentials of a user, see http://markmail.org/message/zvbzejxzinqwttym . > This includes a refactoring of the AuthenticationInfo class into a > Map -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (SLING-698) Repository Ping thread may terminate without any traces in the log files
[ https://issues.apache.org/jira/browse/SLING-698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed SLING-698. --- Resolution: Fixed Logging has been added to the pinger thread. I think this bug can be closed. > Repository Ping thread may terminate without any traces in the log files > > > Key: SLING-698 > URL: https://issues.apache.org/jira/browse/SLING-698 > Project: Sling > Issue Type: Bug > Components: JCR >Affects Versions: JCR Base 2.0.2 >Reporter: Felix Meschberger >Assignee: Felix Meschberger >Priority: Critical > Fix For: JCR Base 2.0.4 > > > The Repository Ping thread ensures the repository is shutdown (or released) > and the service unregistered when the thread terminates. The problem is, that > the thread may either terminate because it is asked to terminate as per > AbstractSlingRepository.stopRepositoryPinger called by the deactivate method > or it terminates because of an uncaught Throwable. Neither case is currently > properly logged. > The AbstractSlingRepository.run() method should log the following situations: > * request to terminate as per AbstractSlingRepository.stopRepositoryPinger > as INFO message > * uncaught throwable as ERROR message > * it is about to be going down as an INFO message -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-727) Allow AuthenticationHandler to assign a workspace to credentials
[ https://issues.apache.org/jira/browse/SLING-727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger resolved SLING-727. - Resolution: Fixed I have implemented this extension in Rev. 713058. For now, I did not yet make the AuthenticationInfo a Map, since this is still under discussion. Please close, if this suits your needs. Thanks. > Allow AuthenticationHandler to assign a workspace to credentials > > > Key: SLING-727 > URL: https://issues.apache.org/jira/browse/SLING-727 > Project: Sling > Issue Type: Improvement > Components: Engine >Affects Versions: Engine 2.0.2 >Reporter: Marc >Assignee: Felix Meschberger > Fix For: Engine 2.0.4 > > > A custom AuthenticationHandler should be able to add a JCR workspace to the > credentials of a user, see http://markmail.org/message/zvbzejxzinqwttym . > This includes a refactoring of the AuthenticationInfo class into a > Map -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SLING-727) Allow AuthenticationHandler to assign a workspace to credentials
[ https://issues.apache.org/jira/browse/SLING-727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger reassigned SLING-727: --- Assignee: Felix Meschberger > Allow AuthenticationHandler to assign a workspace to credentials > > > Key: SLING-727 > URL: https://issues.apache.org/jira/browse/SLING-727 > Project: Sling > Issue Type: Improvement > Components: Engine >Affects Versions: Engine 2.0.2 >Reporter: Marc >Assignee: Felix Meschberger > Fix For: Engine 2.0.4 > > > A custom AuthenticationHandler should be able to add a JCR workspace to the > credentials of a user, see http://markmail.org/message/zvbzejxzinqwttym . > This includes a refactoring of the AuthenticationInfo class into a > Map -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Connecting to and using multiple workspaces
>>> [...] >>> As an alternative -- short term -- approach, you might want to implement >>> a ResourceProvider - say - for the /apps tree, which just uses >>> SlingRepository.loginAdministrative() to login to the default workspace >>> as an administrative user and which would serve the /apps tree from there. >> >> Hmm, hadn't thought of that solution. But when you say implement a >> ResourceProvider for /apps, would it be possible to implement a >> ResourceProvider for the "draft" workspace instead? On Tue, Nov 11, 2008 at 3:49 PM, Felix Meschberger <[EMAIL PROTECTED]> wrote: > Sure, the problem is then how to get the credentials into your > ResourceProvider. > > In addition you are faced with another issue with the current definition > of the ResourceProvider interface: This is currently global and does not > know the concept of users etc. To implement your use case, you might > want to go for a Facade Implementation, where the Facade is registered > and hands over the method call to a real instance, which might be thread > (or request) -bound to support per-user differences. >> In either case, what (in your opinion) would be the easiest approach >> to implement the ResourceProvider? Extending JcrResourceProvider, or >> creating one from scratch, or something completely different? > I would assume that starting from the existing JcrResourceProvider is > probably a good idea because this one already contains most of the core > code required. You just need some integration glue to get it running, > probably. > > Hope this helps Thanks a lot. I think we will hack up something for now, using a fake login to the draft workspace, and wait for ResourceResolverFactory :) -- Vidar S. Ramdal <[EMAIL PROTECTED]> - http://www.idium.no Akersgata 16, N-0158 Oslo, Norway
[jira] Updated: (SLING-727) Allow AuthenticationHandler to assign a workspace to credentials
[ https://issues.apache.org/jira/browse/SLING-727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated SLING-727: Fix Version/s: Engine 2.0.4 Affects Version/s: Engine 2.0.2 > Allow AuthenticationHandler to assign a workspace to credentials > > > Key: SLING-727 > URL: https://issues.apache.org/jira/browse/SLING-727 > Project: Sling > Issue Type: Improvement > Components: Engine >Affects Versions: Engine 2.0.2 >Reporter: Marc >Assignee: Felix Meschberger > Fix For: Engine 2.0.4 > > > A custom AuthenticationHandler should be able to add a JCR workspace to the > credentials of a user, see http://markmail.org/message/zvbzejxzinqwttym . > This includes a refactoring of the AuthenticationInfo class into a > Map -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Connecting to and using multiple workspaces
Hi Vidar, Vidar Ramdal schrieb: >> Vidar Ramdal schrieb: >>> We want to render content in the "draft" workspace with scripts stored >>> in the default workspace. Since only one JCR session is created per >>> HTTP request, we're unable to access both a node in "draft" and the >>> scripts stored under /apps in the default workspace. > > On Tue, Nov 11, 2008 at 2:49 PM, Felix Meschberger <[EMAIL PROTECTED]> wrote: >> Hi Vidar, >> >> Interestingly, your request seems to be supported by my proposal for the >> ResourceResolverFactory [3]. In such a case, you would probably have two >> ResourceProviderFactory services registered: One would support the >> default workspace at "/" and the second one would support the draft >> workspace at "/content". > > Exactly, that would be what I want. (Or even better, the draft > workspace would be mapped to requests with extension/selector = > ".draft", but I guess that's more complicated). > So you can consider this a vote (+1) for your proposal, if I'm allowed > to vote :) Yes, everyone is allowed to vote. Yet there are votes (release votes mostly), where some votes are binding and some are not. In fact I consider it a good thing to get a broad range of votes, not only "binding" ones, because non-binding votes are kind of a signal of interest. > >> [...] >> As an alternative -- short term -- approach, you might want to implement >> a ResourceProvider - say - for the /apps tree, which just uses >> SlingRepository.loginAdministrative() to login to the default workspace >> as an administrative user and which would serve the /apps tree from there. > > Hmm, hadn't thought of that solution. But when you say implement a > ResourceProvider for /apps, would it be possible to implement a > ResourceProvider for the "draft" workspace instead? Sure, the problem is then how to get the credentials into your ResourceProvider. In addition you are faced with another issue with the current definition of the ResourceProvider interface: This is currently global and does not know the concept of users etc. To implement your use case, you might want to go for a Facade Implementation, where the Facade is registered and hands over the method call to a real instance, which might be thread (or request) -bound to support per-user differences. > > In either case, what (in your opinion) would be the easiest approach > to implement the ResourceProvider? Extending JcrResourceProvider, or > creating one from scratch, or something completely different? > > I would assume that starting from the existing JcrResourceProvider is probably a good idea because this one already contains most of the core code required. You just need some integration glue to get it running, probably. Hope this helps Regards Felix
Re: Connecting to and using multiple workspaces
Hi Vidar,
Interestingly, your request seems to be supported by my proposal for the
ResourceResolverFactory [3]. In such a case, you would probably have two
ResourceProviderFactory services registered: One would support the
default workspace at "/" and the second one would support the draft
workspace at "/content".
Whenever a user logs into the system, the ResourceResolverFactory asks
the respective ResourceProviderFactory services for ResourceProvider
instances, which you could provide depending on the requested user and
any other detail provided by the AuthenticationHandler.
As an alternative -- short term -- approach, you might want to implement
a ResourceProvider - say - for the /apps tree, which just uses
SlingRepository.loginAdministrative() to login to the default workspace
as an administrative user and which would serve the /apps tree from there.
WDYT ?
Regards
Felix
Vidar Ramdal schrieb:
> Hello Slingers,
>
> We are developing an application which will feature a staging concept.
> That is, the user should be able to save and preview changes before
> publishing them to the world.
>
> We have read some previous posts with great interest, in particular
> [1]. In that thread, Felix Meschberger suggests [2] using multiple
> workspaces to achieve this. In our case, that would be a "draft"
> workspace in addition to the default workspace.
> (The proposition at [3] also seems interesting in this respect).
>
> As a temporary proof-of-concept, we've hacked
> SlingAuthenticationHandler to look for a "workspace" parameter in the
> URL, to decide which workspace to connect to:
> SlingAuthenticator#218:
> String workspace = req.getParameter("workspace");
> log.debug("authenticate: credentials, trying to get a session");
> Session session = getRepository().login(
> authInfo.getCredentials(), workspace /* was: null */);
>
> This way, we're able to access content in the "draft" workspace by
> http://localhost:/path/to/node?workspace=draft
>
> But having content stored in different workspaces introduces a number
> of difficulties. The first roadblock we've hit, is this:
>
> We want to render content in the "draft" workspace with scripts stored
> in the default workspace. Since only one JCR session is created per
> HTTP request, we're unable to access both a node in "draft" and the
> scripts stored under /apps in the default workspace. (Of course, we
> could duplicate all content under /apps to both workspaces, but that
> seems just ... wrong).
>
> Looking at the different interfaces in Sling, it seems it should be
> possible to implement a custom JcrResourceResolver. The Resolver would
> examine the HttpRequest, and create a connection to the desired
> workspace and fetch the content.
> Given that this is a possible solution, how do we register our
> JcrResourceResolver so that it can respond to certain requests? Or is
> this not a good solution at all?
>
> [1] http://markmail.org/message/4eh45utq72qf4eqo
> [2] http://markmail.org/message/utwgtv7z7rfx6jgl
> [3] http://markmail.org/message/fslkzj3dlkbn4lxo
>
Re: Replacing JcrResourceResolverFactory by a Sling ResourceResolverFactory
On 11 Nov 2008, at 23:09, Bertrand Delacretaz wrote: I tend to agree, and IIUC the various comments in this thread, being able to mount additional resources (files, rss feeds, you name it), at least read-only, at the JCR level, would help a lot. An additional feature would be the possibility to mount various back- ends at the same paths, so that if a resource is not found in one back- end, the other one is tried. This would be more useful for Sling than for JCR though. -- Torgeir Veimo [EMAIL PROTECTED]
Re: multitenancy
Hi Felix > > > Marc Speck schrieb: > > Thanks for the feedback, Bertrand. I'm happy to provide this minor patch. > > However, it seems the new proposal of Felix about > ResourceResolverFactory, > > > http://cwiki.apache.org/SLING/add-resourceresolverfactory-service-interface.html > , > > also allows my use case. So should you find agreement on the proposal > > and > > implement it in the next weeks, I'm fine with waiting for it. > > In fact, your initial message prompted me to finally publicize the > proposal ;-) So, I didn't want to answer to your request too early. yeah, I thought so. > > Since, the proposal is most probably not going to be implemented within > a day or two ;-), your proposal makes absolute sense to me. (In fact I > have implemented some prototype in my workspace to look at it ;-) ). great! > > > My propotype just extends the AuthenticationInfo class by adding another > constructor taking the workspace name and a new getWorkspaceName method. Yep, I did the same. > > Would you mind to create a JIRA for this ? Then I will ASAP commit this > extension. https://issues.apache.org/jira/browse/SLING-727 > > > Thinking of compatibility: It think we can easily turn the > AuthenticationInfo class into a Map suitable for the > proposed ResourceProviderFactory.getResourceProvider method for it to be > used by AuthenticationHandler implementations. So this proposal can > still be supported even with ResourceResolverFactory implemented. That's fine with me. Marc
Re: Connecting to and using multiple workspaces
> Vidar Ramdal schrieb: >> We want to render content in the "draft" workspace with scripts stored >> in the default workspace. Since only one JCR session is created per >> HTTP request, we're unable to access both a node in "draft" and the >> scripts stored under /apps in the default workspace. On Tue, Nov 11, 2008 at 2:49 PM, Felix Meschberger <[EMAIL PROTECTED]> wrote: > Hi Vidar, > > Interestingly, your request seems to be supported by my proposal for the > ResourceResolverFactory [3]. In such a case, you would probably have two > ResourceProviderFactory services registered: One would support the > default workspace at "/" and the second one would support the draft > workspace at "/content". Exactly, that would be what I want. (Or even better, the draft workspace would be mapped to requests with extension/selector = ".draft", but I guess that's more complicated). So you can consider this a vote (+1) for your proposal, if I'm allowed to vote :) > [...] > As an alternative -- short term -- approach, you might want to implement > a ResourceProvider - say - for the /apps tree, which just uses > SlingRepository.loginAdministrative() to login to the default workspace > as an administrative user and which would serve the /apps tree from there. Hmm, hadn't thought of that solution. But when you say implement a ResourceProvider for /apps, would it be possible to implement a ResourceProvider for the "draft" workspace instead? In either case, what (in your opinion) would be the easiest approach to implement the ResourceProvider? Extending JcrResourceProvider, or creating one from scratch, or something completely different? -- Vidar S. Ramdal <[EMAIL PROTECTED]> - http://www.idium.no Akersgata 16, N-0158 Oslo, Norway
[jira] Created: (SLING-727) Allow AuthenticationHandler to assign a workspace to credentials
Allow AuthenticationHandler to assign a workspace to credentials Key: SLING-727 URL: https://issues.apache.org/jira/browse/SLING-727 Project: Sling Issue Type: Improvement Components: Engine Reporter: Marc A custom AuthenticationHandler should be able to add a JCR workspace to the credentials of a user, see http://markmail.org/message/zvbzejxzinqwttym . This includes a refactoring of the AuthenticationInfo class into a Map -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Replacing JcrResourceResolverFactory by a Sling ResourceResolverFactory
On Tue, Nov 11, 2008 at 2:09 PM, Bertrand Delacretaz <[EMAIL PROTECTED]> wrote: > Having to use both the Resource and JCR interfacts in Sling might not > be optimal, but it allows us to do more than if we were to use just > JCR. > > With this in mind, I agree with Felix and Carsten about the proposed > changes, but I think we must be very careful to not bloat the extra > layers of Sling. The proposed changes do improve the current > situation, without adding complexity or new layers, IMHO, so I'm +1 on > them. ACK! Felix's proposal basically just makes the whole resource tree "creation" more flexible and extendable, while the resource api (and it's inherent duplication of the JCR API) would still be the same as it is already now. Which means as long as we have no mounting features in JCR or Jackrabbit, this is a good way to go. We still concentrate on JCR; as an example, the recent threads about using different workspaces depending on the requests show that the new mechanism helps to leverage JCR features, which were previously not possible to use. Regards, Alex -- Alexander Klimetschek [EMAIL PROTECTED]
Re: multitenancy
Hi Mark, Marc Speck schrieb: > Thanks for the feedback, Bertrand. I'm happy to provide this minor patch. > However, it seems the new proposal of Felix about ResourceResolverFactory, > http://cwiki.apache.org/SLING/add-resourceresolverfactory-service-interface.html, > also allows my use case. So should you find agreement on the proposal > and > implement it in the next weeks, I'm fine with waiting for it. In fact, your initial message prompted me to finally publicize the proposal ;-) So, I didn't want to answer to your request too early. Since, the proposal is most probably not going to be implemented within a day or two ;-), your proposal makes absolute sense to me. (In fact I have implemented some prototype in my workspace to look at it ;-) ). My propotype just extends the AuthenticationInfo class by adding another constructor taking the workspace name and a new getWorkspaceName method. Would you mind to create a JIRA for this ? Then I will ASAP commit this extension. Thinking of compatibility: It think we can easily turn the AuthenticationInfo class into a Map suitable for the proposed ResourceProviderFactory.getResourceProvider method for it to be used by AuthenticationHandler implementations. So this proposal can still be supported even with ResourceResolverFactory implemented. Regards Felix > > Marc > > > > > On Tue, Nov 11, 2008 at 12:10 PM, Bertrand Delacretaz < > [EMAIL PROTECTED]> wrote: > >> Hi Marc, >> >> On Fri, Nov 7, 2008 at 3:39 PM, Marc Speck <[EMAIL PROTECTED]> wrote: >> >>> We thought about adding the workspaceName to >>> AuthenticationInfo(String authType, Credentials credentials, String >>> workspaceName) >> Ok, as long as you keep the existing constructor. >> >>> ... And then add it in SlingAuthenticator: >>> >>> ...Session session = getRepository().login( >>> -authInfo.getCredentials(), null); >>> +authInfo.getCredentials(), >>> authInfo.getWorkspaceName());... >> Sounds good to me! >> >> -Bertrand >> >
[jira] Commented: (SLING-726) Prevent ServletResponse.setCharacterEncoding in SlingHttpServletResponseImpl
[ https://issues.apache.org/jira/browse/SLING-726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12646545#action_12646545 ] Felix Meschberger commented on SLING-726: - @Bertrand I agree with you whole heartedly. Yet it took me almost two days, to find the cause for the problem of garbage in the output ! So implementing this workaround to ensure behaviour is spec-compliant (instead of being a buggy extension) is acceptable by me. If have placed comments referring to this bug such that the complete discussion may be tracked. > Prevent ServletResponse.setCharacterEncoding in SlingHttpServletResponseImpl > > > Key: SLING-726 > URL: https://issues.apache.org/jira/browse/SLING-726 > Project: Sling > Issue Type: Bug > Components: Engine >Affects Versions: Engine 2.0.2 >Reporter: Felix Meschberger >Assignee: Felix Meschberger >Priority: Critical > Fix For: Engine 2.0.4 > > > The Servlet API 2.4 specifies that calls to the > ServletResponse.setCharacterEncoding() method should be ignored if the > response has already been committed or if the getWriter() method has already > been called. Likewise the character encoding being specified through > ServletResponse.setContentType() should be ignored if the getWriter() method > has already been called (setContentType should be ignored if the response has > already been committed). > Unfortunately BEA WebLogic 10.3 seems to no ignore this call and instead > chooses to act upon it. It looks like WebLogic internally recodes, what has > already been written, and resets it into the output buffer, but does not seem > to reset the buffer offset before doing this. This causes all kind of garbage > of previous requests (since buffers seem to be reused) to be added to the > output > Sling should workaround this issue by overwriting the setCharacterEncoding > and setContentType methods to prevent the character encoding from being > changed after getWriter() has been called. > The reason, why Sling may run into problems is, that the DefaultSlingScript > used by the scripting/core module to adapt scripts to the Servlet interface > automatically sets the character encoding before calling the actual script. > This may cause responses handled by Sling to become garbled. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Connecting to and using multiple workspaces
Hello Slingers,
We are developing an application which will feature a staging concept.
That is, the user should be able to save and preview changes before
publishing them to the world.
We have read some previous posts with great interest, in particular
[1]. In that thread, Felix Meschberger suggests [2] using multiple
workspaces to achieve this. In our case, that would be a "draft"
workspace in addition to the default workspace.
(The proposition at [3] also seems interesting in this respect).
As a temporary proof-of-concept, we've hacked
SlingAuthenticationHandler to look for a "workspace" parameter in the
URL, to decide which workspace to connect to:
SlingAuthenticator#218:
String workspace = req.getParameter("workspace");
log.debug("authenticate: credentials, trying to get a session");
Session session = getRepository().login(
authInfo.getCredentials(), workspace /* was: null */);
This way, we're able to access content in the "draft" workspace by
http://localhost:/path/to/node?workspace=draft
But having content stored in different workspaces introduces a number
of difficulties. The first roadblock we've hit, is this:
We want to render content in the "draft" workspace with scripts stored
in the default workspace. Since only one JCR session is created per
HTTP request, we're unable to access both a node in "draft" and the
scripts stored under /apps in the default workspace. (Of course, we
could duplicate all content under /apps to both workspaces, but that
seems just ... wrong).
Looking at the different interfaces in Sling, it seems it should be
possible to implement a custom JcrResourceResolver. The Resolver would
examine the HttpRequest, and create a connection to the desired
workspace and fetch the content.
Given that this is a possible solution, how do we register our
JcrResourceResolver so that it can respond to certain requests? Or is
this not a good solution at all?
[1] http://markmail.org/message/4eh45utq72qf4eqo
[2] http://markmail.org/message/utwgtv7z7rfx6jgl
[3] http://markmail.org/message/fslkzj3dlkbn4lxo
--
Vidar S. Ramdal <[EMAIL PROTECTED]> - http://www.idium.no
Akersgata 16, N-0158 Oslo, Norway
Re: Replacing JcrResourceResolverFactory by a Sling ResourceResolverFactory
On Mon, Nov 10, 2008 at 9:27 PM, Jukka Zitting <[EMAIL PROTECTED]> wrote: > ...I find it troubling that Sling is reinventing JCR. This looks like a > symptom that JCR is not optimal for the things Sling wants to do. From > an architectural perspective I'd rather focus on improving JCR than > layering extra levels of abstraction on top of it I tend to agree, and IIUC the various comments in this thread, being able to mount additional resources (files, rss feeds, you name it), at least read-only, at the JCR level, would help a lot. But we don't have this today. Having to use both the Resource and JCR interfacts in Sling might not be optimal, but it allows us to do more than if we were to use just JCR. With this in mind, I agree with Felix and Carsten about the proposed changes, but I think we must be very careful to not bloat the extra layers of Sling. The proposed changes do improve the current situation, without adding complexity or new layers, IMHO, so I'm +1 on them. -Bertrand
[jira] Closed: (SLING-726) Prevent ServletResponse.setCharacterEncoding in SlingHttpServletResponseImpl
[ https://issues.apache.org/jira/browse/SLING-726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed SLING-726. --- Resolution: Fixed Implemented and tested this fix in Rev. 713028. Specially handling the setContentType() method seems not to be required, since WebLogic 10.3 seems to correctly ignore the character set setting in this method call. > Prevent ServletResponse.setCharacterEncoding in SlingHttpServletResponseImpl > > > Key: SLING-726 > URL: https://issues.apache.org/jira/browse/SLING-726 > Project: Sling > Issue Type: Bug > Components: Engine >Affects Versions: Engine 2.0.2 >Reporter: Felix Meschberger >Assignee: Felix Meschberger >Priority: Critical > Fix For: Engine 2.0.4 > > > The Servlet API 2.4 specifies that calls to the > ServletResponse.setCharacterEncoding() method should be ignored if the > response has already been committed or if the getWriter() method has already > been called. Likewise the character encoding being specified through > ServletResponse.setContentType() should be ignored if the getWriter() method > has already been called (setContentType should be ignored if the response has > already been committed). > Unfortunately BEA WebLogic 10.3 seems to no ignore this call and instead > chooses to act upon it. It looks like WebLogic internally recodes, what has > already been written, and resets it into the output buffer, but does not seem > to reset the buffer offset before doing this. This causes all kind of garbage > of previous requests (since buffers seem to be reused) to be added to the > output > Sling should workaround this issue by overwriting the setCharacterEncoding > and setContentType methods to prevent the character encoding from being > changed after getWriter() has been called. > The reason, why Sling may run into problems is, that the DefaultSlingScript > used by the scripting/core module to adapt scripts to the Servlet interface > automatically sets the character encoding before calling the actual script. > This may cause responses handled by Sling to become garbled. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-726) Prevent ServletResponse.setCharacterEncoding in SlingHttpServletResponseImpl
[ https://issues.apache.org/jira/browse/SLING-726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12646541#action_12646541 ] Bertrand Delacretaz commented on SLING-726: --- I hate to have to implement workarounds for broken app servers, but agree that it is useful for Sling to be resilient again such problems. I suggest identifying the corresponding code as a workaround in code comments, as that should normally be none of Sling's business. > Prevent ServletResponse.setCharacterEncoding in SlingHttpServletResponseImpl > > > Key: SLING-726 > URL: https://issues.apache.org/jira/browse/SLING-726 > Project: Sling > Issue Type: Bug > Components: Engine >Affects Versions: Engine 2.0.2 >Reporter: Felix Meschberger >Assignee: Felix Meschberger >Priority: Critical > Fix For: Engine 2.0.4 > > > The Servlet API 2.4 specifies that calls to the > ServletResponse.setCharacterEncoding() method should be ignored if the > response has already been committed or if the getWriter() method has already > been called. Likewise the character encoding being specified through > ServletResponse.setContentType() should be ignored if the getWriter() method > has already been called (setContentType should be ignored if the response has > already been committed). > Unfortunately BEA WebLogic 10.3 seems to no ignore this call and instead > chooses to act upon it. It looks like WebLogic internally recodes, what has > already been written, and resets it into the output buffer, but does not seem > to reset the buffer offset before doing this. This causes all kind of garbage > of previous requests (since buffers seem to be reused) to be added to the > output > Sling should workaround this issue by overwriting the setCharacterEncoding > and setContentType methods to prevent the character encoding from being > changed after getWriter() has been called. > The reason, why Sling may run into problems is, that the DefaultSlingScript > used by the scripting/core module to adapt scripts to the Servlet interface > automatically sets the character encoding before calling the actual script. > This may cause responses handled by Sling to become garbled. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-726) Prevent ServletResponse.setCharacterEncoding in SlingHttpServletResponseImpl
Prevent ServletResponse.setCharacterEncoding in SlingHttpServletResponseImpl Key: SLING-726 URL: https://issues.apache.org/jira/browse/SLING-726 Project: Sling Issue Type: Bug Components: Engine Affects Versions: Engine 2.0.2 Reporter: Felix Meschberger Assignee: Felix Meschberger Priority: Critical Fix For: Engine 2.0.4 The Servlet API 2.4 specifies that calls to the ServletResponse.setCharacterEncoding() method should be ignored if the response has already been committed or if the getWriter() method has already been called. Likewise the character encoding being specified through ServletResponse.setContentType() should be ignored if the getWriter() method has already been called (setContentType should be ignored if the response has already been committed). Unfortunately BEA WebLogic 10.3 seems to no ignore this call and instead chooses to act upon it. It looks like WebLogic internally recodes, what has already been written, and resets it into the output buffer, but does not seem to reset the buffer offset before doing this. This causes all kind of garbage of previous requests (since buffers seem to be reused) to be added to the output Sling should workaround this issue by overwriting the setCharacterEncoding and setContentType methods to prevent the character encoding from being changed after getWriter() has been called. The reason, why Sling may run into problems is, that the DefaultSlingScript used by the scripting/core module to adapt scripts to the Servlet interface automatically sets the character encoding before calling the actual script. This may cause responses handled by Sling to become garbled. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Error Messaging/Validation
On Mon, Oct 20, 2008 at 8:12 AM, Felix Meschberger <[EMAIL PROTECTED]> wrote: > Alexander Klimetschek schrieb: >> Is there a taglib tag for doing this directly in JSPs? If not, >> might be useful and simpler than to remember these lines and the >> correct request dispatcher options. Something like , >> similar to sling:include. > > Yes, this is a TODO. And I think at least one form of > SlingScriptHelper.forward method should also be provided. Note that this is being handled in SLING-703 and the related issues. -Bertrand
Re: Sling breaks with pax-web 0.5.1
Hi Mark,
Going through my mail backlog I notice that we haven't replied to your
question, is that still current?
If yes it might be safer to create a JIRA issue so that doesn't fall
into the cracks - apparently none of us had an answer off the top of
their head.
-Bertrand
On Sun, Oct 19, 2008 at 11:55 PM, Mark Derricutt <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> We recently updated our sling based application (based around the
> sling-launchpad osgi deployer) to use pax-web-server 0.5.1 (which uses NIO)
> and have noticed that for some reason none of sling content gets returned
> anymore, instead we see:
>
> ** Node dumped by StreamRendererServlet**
> Node path:/
> Resource metadata: {sling.resolutionPath=/}
>
> ** Node properties **
> jcr:primaryType: rep:root
>
>
> being output to the browser. Is this a known issue or something new? Is
> there anything I can look at to try and diagnose whats going on?
>
> Mark
>
> --
> "It is easier to optimize correct code than to correct optimized code." --
> Bill Harlan
>
Re: modifying a repository directly with jackrabbit; also, disabling RMI
Hi, On Fri, Nov 7, 2008 at 9:08 PM, Dan Tenenbaum <[EMAIL PROTECTED]> wrote: > I have a java program that opens a TransientRepository using > SLING_HOME/jackrabbit/repository.xml as the config file and > SLING_HOME/jackrabbit/repository as the repository directory... Using the TransientRepository(String config, String home) constructor I assume. > So my questions are: > 1) Where is the repository that my program is writing to? ... If config and home actually point to the repository that Sling uses, that should be the same one. The best way to find out is to check the file timestamps after making changes with one app or the other. > ...Or, if it is > writing to the same repository, why can't I see the nodes that were created. > Could it be using a different workspace? Is there a way to determine what > workspace you are in (and what user you are logged in as) from a sling > script?... By default, Sling uses the repository's default workspace. The JCR Session object can tell you what this is, so currentNode.getSession().getWorkspace().getName() should do. > ...2) Can a java program directly modify the repository that launchpad uses, > while the launchpad app is running?... Not directly, but your program could connect to the same repository via RMI. But can't you do those modifications using the Sling API? We aim to provide full access to the repository via the HTTP/JSON interface of the default Sling servlets, and if there's something missing we might want to add it. > Next question: > ...This suggests that sling is starting up RMI but not using it. Can I disable > that?... Yes, use the Sling console (http://localhost:/system/console/configMgr), select the org.apache.sling.jcr.jackrabbit.server.RmiRegistrationSupport config and change the port number. I don't think there's a simple way to completely disable that ATM. -Bertrand
Re: multitenancy
On Tue, Nov 11, 2008 at 12:24 PM, Marc Speck <[EMAIL PROTECTED]> wrote: > ...it seems the new proposal of Felix about ResourceResolverFactory, > http://cwiki.apache.org/SLING/add-resourceresolverfactory-service-interface.html, > also allows my use case Ah good - didn't find time to read that yet ;-) -Bertrand
Re: multitenancy
Thanks for the feedback, Bertrand. I'm happy to provide this minor patch. However, it seems the new proposal of Felix about ResourceResolverFactory, http://cwiki.apache.org/SLING/add-resourceresolverfactory-service-interface.html, also allows my use case. So should you find agreement on the proposal and implement it in the next weeks, I'm fine with waiting for it. Marc On Tue, Nov 11, 2008 at 12:10 PM, Bertrand Delacretaz < [EMAIL PROTECTED]> wrote: > Hi Marc, > > On Fri, Nov 7, 2008 at 3:39 PM, Marc Speck <[EMAIL PROTECTED]> wrote: > > > We thought about adding the workspaceName to > > AuthenticationInfo(String authType, Credentials credentials, String > > workspaceName) > > Ok, as long as you keep the existing constructor. > > > ... And then add it in SlingAuthenticator: > > > > ...Session session = getRepository().login( > > -authInfo.getCredentials(), null); > > +authInfo.getCredentials(), > > authInfo.getWorkspaceName());... > > Sounds good to me! > > -Bertrand >
Re: multitenancy
Hi Marc, On Fri, Nov 7, 2008 at 3:39 PM, Marc Speck <[EMAIL PROTECTED]> wrote: > We thought about adding the workspaceName to > AuthenticationInfo(String authType, Credentials credentials, String > workspaceName) Ok, as long as you keep the existing constructor. > ... And then add it in SlingAuthenticator: > > ...Session session = getRepository().login( > -authInfo.getCredentials(), null); > +authInfo.getCredentials(), > authInfo.getWorkspaceName());... Sounds good to me! -Bertrand
