[jira] Updated: (SLING-310) SlingMainServlet: null mimeTypeService in HttpContext, but not in main class
[
https://issues.apache.org/jira/browse/SLING-310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bertrand Delacretaz updated SLING-310:
--
Priority: Major (was: Minor)
SlingMainServlet: null mimeTypeService in HttpContext, but not in main class
Key: SLING-310
URL: https://issues.apache.org/jira/browse/SLING-310
Project: Sling
Issue Type: Bug
Reporter: Bertrand Delacretaz
Attachments: SLING-310.log
In revision 633868, with this build/start sequence:
cd launchpad/webapp
cd ../app ; mvn clean install ; cd - ; mvn clean integration-test
-Dintegration.test.wait=true
Some integration tests fail, like for example
PropertyRenderingTest.testTextNoExt
The problem is that mimeTypeService is null here:
HttpContext httpContext = new HttpContext() {
public String getMimeType(String name) {
return mimeTypeService.getMimeType(name);
}
event though the mimeTypeService of the enclosing class is set.
Not sure what's happening, maybe there are several instances of this
HttpContext around.
To simplify, I'll change SlingMainServlet to implement HttpContext
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-310) SlingMainServlet still used as the HttpContext after being deactivated
[
https://issues.apache.org/jira/browse/SLING-310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bertrand Delacretaz updated SLING-310:
--
Summary: SlingMainServlet still used as the HttpContext after being
deactivated (was: SlingMainServlet: null mimeTypeService in HttpContext, but
not in main class)
SlingMainServlet still used as the HttpContext after being deactivated
--
Key: SLING-310
URL: https://issues.apache.org/jira/browse/SLING-310
Project: Sling
Issue Type: Bug
Reporter: Bertrand Delacretaz
Attachments: SLING-310.log
In revision 633868, with this build/start sequence:
cd launchpad/webapp
cd ../app ; mvn clean install ; cd - ; mvn clean integration-test
-Dintegration.test.wait=true
Some integration tests fail, like for example
PropertyRenderingTest.testTextNoExt
The problem is that mimeTypeService is null here:
HttpContext httpContext = new HttpContext() {
public String getMimeType(String name) {
return mimeTypeService.getMimeType(name);
}
event though the mimeTypeService of the enclosing class is set.
Not sure what's happening, maybe there are several instances of this
HttpContext around.
To simplify, I'll change SlingMainServlet to implement HttpContext
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-310) SlingMainServlet: null mimeTypeService in HttpContext, but not in main class
[
https://issues.apache.org/jira/browse/SLING-310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12575630#action_12575630
]
Bertrand Delacretaz commented on SLING-310:
---
The following two requests cause the IllegalStateException after starting as
above:
curl -D - -F title=$(date) http://admin:[EMAIL PROTECTED]:/SLING-310
curl -D - http://admin:[EMAIL PROTECTED]:/SLING-310/title
SlingMainServlet: null mimeTypeService in HttpContext, but not in main class
Key: SLING-310
URL: https://issues.apache.org/jira/browse/SLING-310
Project: Sling
Issue Type: Bug
Reporter: Bertrand Delacretaz
Attachments: SLING-310.log
In revision 633868, with this build/start sequence:
cd launchpad/webapp
cd ../app ; mvn clean install ; cd - ; mvn clean integration-test
-Dintegration.test.wait=true
Some integration tests fail, like for example
PropertyRenderingTest.testTextNoExt
The problem is that mimeTypeService is null here:
HttpContext httpContext = new HttpContext() {
public String getMimeType(String name) {
return mimeTypeService.getMimeType(name);
}
event though the mimeTypeService of the enclosing class is set.
Not sure what's happening, maybe there are several instances of this
HttpContext around.
To simplify, I'll change SlingMainServlet to implement HttpContext
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Support for invoking methods in scripts
hi, this is something i already missed and i think could be useful in apps that use the script support for executing kind of business logic (e.g. workflow, forms validation, rules engine) which of course would expect a return value. regards, philipp On 3/5/08, Carsten Ziegeler [EMAIL PROTECTED] wrote: Hi, the current script support is able to invoke a script and give back a result. If you think of scripting parts of your application it might be useful to group several methods into one script (for instance a javascript script) and execute exactly one method out of this script. WDYT? Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
[jira] Closed: (SLING-228) Create ResourceWrapper and move SyntheticResource to Sling API
[ https://issues.apache.org/jira/browse/SLING-228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed SLING-228. --- Resolution: Fixed This has all been done, so I consider this issue fixed. Create ResourceWrapper and move SyntheticResource to Sling API -- Key: SLING-228 URL: https://issues.apache.org/jira/browse/SLING-228 Project: Sling Issue Type: Improvement Components: Resource Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: 2.0.0 As discussed on the list [1], a new ResourceWrapper class is to be created in the Sling API as well as the SyntheticResource class, currently located in hte jcr/resource modules should be moved to the Sling API. [1] http://www.mail-archive.com/sling-dev@incubator.apache.org/msg02374.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-228) Create ResourceWrapper and move SyntheticResource to Sling API
[ https://issues.apache.org/jira/browse/SLING-228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12575747#action_12575747 ] Felix Meschberger commented on SLING-228: - At long last, I also removed the old SyntheticResource class from the jcr/resolver module in Rev. 634309. Create ResourceWrapper and move SyntheticResource to Sling API -- Key: SLING-228 URL: https://issues.apache.org/jira/browse/SLING-228 Project: Sling Issue Type: Improvement Components: Resource Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: 2.0.0 As discussed on the list [1], a new ResourceWrapper class is to be created in the Sling API as well as the SyntheticResource class, currently located in hte jcr/resource modules should be moved to the Sling API. [1] http://www.mail-archive.com/sling-dev@incubator.apache.org/msg02374.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Rename /classes to /var/jsp/classes?
Hi, Am Donnerstag, den 06.03.2008, 15:33 +0100 schrieb Bertrand Delacretaz: On Thu, Mar 6, 2008 at 3:03 PM, Felix Meschberger [EMAIL PROTECTED] wrote: ... I agree with /var. For jsp, I am not so sure as all jsp classes are compiled into packages below /org/apache/jsp anyway (by Jasper, possibly overwritable).. But if we get another compiler? I'd like us to have a Scala scripting engine at some point, and that's compiled as well. So I thought JSP might use /var/jsp/classes, scala /var/scale/classes, etc. This is probably wrong and makes the class path more complicated as you would have to add entries for both scala and jsp. I also don't think, that this is worth any effort. So I could agree for the move from /classes to /var/classes but not the rest. A package collision is not realistic because - as I said - Jasper compiles all JSPs to inside the org.apache.jsp. And I expect Scala to not tamper with this package. Regards Felix
[jira] Commented: (SLING-311) Record loaded content to not reload inadvertedly.
[ https://issues.apache.org/jira/browse/SLING-311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12575851#action_12575851 ] Felix Meschberger commented on SLING-311: - Actually content is really loaded just before the bundle is started, so content loading is related to bundle start and not to bundle installation, thus you do not need to restart the system, restarting the bundle should suffice it. The goal of this issue is to prevent content reload on bundle start. Record loaded content to not reload inadvertedly. - Key: SLING-311 URL: https://issues.apache.org/jira/browse/SLING-311 Project: Sling Issue Type: Improvement Components: Resource Reporter: Felix Meschberger Fix For: 2.0.0 Currently, the content loader always reloads content indicated as initial content from the bundles if the repository does not contain the respective content. Sometimes it may be desirable to remove the content from the repository and not get the content reloaded on bundle (or system) restart. To prevent such content reload, the content loader should take note of loaded content and not try to reload content, which is marked as loaded, regardless of whether the actual content (still) exists or not. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-311) Record loaded content to not reload inadvertedly.
[ https://issues.apache.org/jira/browse/SLING-311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12575870#action_12575870 ] Felix Meschberger commented on SLING-311: - Considering the content loaded mark is stored in the repository (this is what I intend actually), content will be reloaded when you remove the repository. Record loaded content to not reload inadvertedly. - Key: SLING-311 URL: https://issues.apache.org/jira/browse/SLING-311 Project: Sling Issue Type: Improvement Components: Resource Reporter: Felix Meschberger Fix For: 2.0.0 Currently, the content loader always reloads content indicated as initial content from the bundles if the repository does not contain the respective content. Sometimes it may be desirable to remove the content from the repository and not get the content reloaded on bundle (or system) restart. To prevent such content reload, the content loader should take note of loaded content and not try to reload content, which is marked as loaded, regardless of whether the actual content (still) exists or not. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-310) SlingMainServlet still used as the HttpContext after being deactivated
[
https://issues.apache.org/jira/browse/SLING-310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12575873#action_12575873
]
Felix Meschberger commented on SLING-310:
-
I cannot reproduce this behaviour on my linux box. And looking at the
SlingMainServlet class, I cannot imagine, why the component should be cycled
because the only reason, this would happen is if the HttpService is coming or
going. But then the SlingMainServlet is not activated as long as the
HttpService is not there So this really is a strange situation ...
SlingMainServlet still used as the HttpContext after being deactivated
--
Key: SLING-310
URL: https://issues.apache.org/jira/browse/SLING-310
Project: Sling
Issue Type: Bug
Reporter: Bertrand Delacretaz
Attachments: SLING-310.log
In revision 633868, with this build/start sequence:
cd launchpad/webapp
cd ../app ; mvn clean install ; cd - ; mvn clean integration-test
-Dintegration.test.wait=true
Some integration tests fail, like for example
PropertyRenderingTest.testTextNoExt
The problem is that mimeTypeService is null here:
HttpContext httpContext = new HttpContext() {
public String getMimeType(String name) {
return mimeTypeService.getMimeType(name);
}
event though the mimeTypeService of the enclosing class is set.
Not sure what's happening, maybe there are several instances of this
HttpContext around.
To simplify, I'll change SlingMainServlet to implement HttpContext
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SLING-303) make UjaxHtmlResponse public usable
[ https://issues.apache.org/jira/browse/SLING-303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger reassigned SLING-303: --- Assignee: Felix Meschberger make UjaxHtmlResponse public usable --- Key: SLING-303 URL: https://issues.apache.org/jira/browse/SLING-303 Project: Sling Issue Type: Improvement Components: microsling Reporter: Tobias Bocanegra Assignee: Felix Meschberger Priority: Minor Attachments: ujax_status_provider.r633155.patch the current ujax html response can only by used by the UjaxPostServlet. It would be useful if it can also be used by other classes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-303) make UjaxHtmlResponse public usable
[ https://issues.apache.org/jira/browse/SLING-303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12575874#action_12575874 ] Felix Meschberger commented on SLING-303: - Considering, that we would like to provide a generic means to gather actions (change log) and print the records, I will look into this. make UjaxHtmlResponse public usable --- Key: SLING-303 URL: https://issues.apache.org/jira/browse/SLING-303 Project: Sling Issue Type: Improvement Components: microsling Reporter: Tobias Bocanegra Assignee: Felix Meschberger Priority: Minor Attachments: ujax_status_provider.r633155.patch the current ujax html response can only by used by the UjaxPostServlet. It would be useful if it can also be used by other classes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Rename /classes to /var/jsp/classes?
On Thu, Mar 6, 2008 at 8:35 PM, Felix Meschberger [EMAIL PROTECTED] wrote: ... A package collision is not realistic because - as I said - Jasper compiles all JSPs to inside the org.apache.jsp. And I expect Scala to not tamper with this package Ok, sorry I missed that - if all JSP classes go under the org.apache.jsp package, we're fine. -Bertrand
[jira] Created: (SLING-312) uajx post servlet does not create intermediate nodes for a deep move
uajx post servlet does not create intermediate nodes for a deep move Key: SLING-312 URL: https://issues.apache.org/jira/browse/SLING-312 Project: Sling Issue Type: Improvement Components: microsling Reporter: Tobias Bocanegra when moving a node below a structure of the current one, the intermediate nodes are not created and the move fails. this should be fixed in order to have a consistent behavior as with the properties where the intermediate nodes are created. example: POST /foo/bar ujax:moveSrc=/tmp/file ujax:moveDest=./image/file should create the /foo/bar/image node. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-310) SlingMainServlet still used as the HttpContext after being deactivated
[
https://issues.apache.org/jira/browse/SLING-310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12576061#action_12576061
]
Bertrand Delacretaz commented on SLING-310:
---
Here's the list of tests that fail when this problem occurs:
Failed tests:
testTextNoExt(org.apache.sling.launchpad.webapp.integrationtest.PropertyRenderingTest)
testResourceTypeNoExt(org.apache.sling.launchpad.webapp.integrationtest.PropertyRenderingTest)
testDistinctResource(org.apache.sling.launchpad.webapp.integrationtest.UploadFileTest)
testDistinctResourceWithType(org.apache.sling.launchpad.webapp.integrationtest.UploadFileTest)
testDistinctFile(org.apache.sling.launchpad.webapp.integrationtest.UploadFileTest)
testRtJsp(org.apache.sling.launchpad.webapp.integrationtest.JspScriptingTest)
testUnstructuredJsp(org.apache.sling.launchpad.webapp.integrationtest.JspScriptingTest)
testAptDocument(org.apache.sling.launchpad.webapp.integrationtest.apt.SimpleAptRenderingTest)
testJsonFile(org.apache.sling.launchpad.webapp.integrationtest.StreamServletTest)
SlingMainServlet still used as the HttpContext after being deactivated
--
Key: SLING-310
URL: https://issues.apache.org/jira/browse/SLING-310
Project: Sling
Issue Type: Bug
Reporter: Bertrand Delacretaz
Attachments: SLING-310.log
In revision 633868, with this build/start sequence:
cd launchpad/webapp
cd ../app ; mvn clean install ; cd - ; mvn clean integration-test
-Dintegration.test.wait=true
Some integration tests fail, like for example
PropertyRenderingTest.testTextNoExt
The problem is that mimeTypeService is null here:
HttpContext httpContext = new HttpContext() {
public String getMimeType(String name) {
return mimeTypeService.getMimeType(name);
}
event though the mimeTypeService of the enclosing class is set.
Not sure what's happening, maybe there are several instances of this
HttpContext around.
To simplify, I'll change SlingMainServlet to implement HttpContext
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: failing tests in r633971
Felix Meschberger schrieb: Hi, Unlike Betrand, I cannot reproduce this issue on my linux box, where all tests except one of the ujax move tests succeed. It would be great if one of you MacOSX guys could try to trace this down - esp. if this is linked to the SLING-310 issue... Thanks. I'll try to hunt this bug later today. Carsten Regards Felix Am Mittwoch, den 05.03.2008, 11:06 -0800 schrieb Tobias Bocanegra: hi all, with the current checkout i see failing tests: Failed tests: testTextNoExt(org.apache.sling.launchpad.webapp.integrationtest.PropertyRenderingTest) testResourceTypeNoExt(org.apache.sling.launchpad.webapp.integrationtest.PropertyRenderingTest) testDistinctResource(org.apache.sling.launchpad.webapp.integrationtest.UploadFileTest) testDistinctResourceWithType(org.apache.sling.launchpad.webapp.integrationtest.UploadFileTest) testDistinctFile(org.apache.sling.launchpad.webapp.integrationtest.UploadFileTest) testRtJsp(org.apache.sling.launchpad.webapp.integrationtest.JspScriptingTest) testUnstructuredJsp(org.apache.sling.launchpad.webapp.integrationtest.JspScriptingTest) testAptDocument(org.apache.sling.launchpad.webapp.integrationtest.apt.SimpleAptRenderingTest) testJsonFile(org.apache.sling.launchpad.webapp.integrationtest.StreamServletTest) without having looked at it closely - those are all tests that load a resource from the classpath. maybe something was not adjusted when refactoring the classes. regards, toby -- Carsten Ziegeler [EMAIL PROTECTED]
[jira] Created: (SLING-313) Registered servlet can't be invoked with authentication
Registered servlet can't be invoked with authentication --- Key: SLING-313 URL: https://issues.apache.org/jira/browse/SLING-313 Project: Sling Issue Type: Bug Components: Core Affects Versions: 2.0.0 Reporter: Carsten Ziegeler Fix For: 2.0.0 It seems that if you register a servlet under /bin/myServlet (without storing the servlet into the repository), the /bin node in the repository is checked. If this /bin node is not accessible for the current user, the servlet is not invoked. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
