[jira] Created: (SLING-427) [Javascript] Make ScriptableItemMap behave like an Array
[Javascript] Make ScriptableItemMap behave like an Array Key: SLING-427 URL: https://issues.apache.org/jira/browse/SLING-427 Project: Sling Issue Type: Improvement Components: Scripting Reporter: Lars Trieloff Priority: Minor The ScriptableItemMap which wraps an Iterator for Javascript scripts is nice, but it exposes itself as an object, not as an array, which makes it hard to loop easily over the contents of the map. It would be nice if the Map could expose an Array-like behavior by exposing a length field and allowing indexed access to its contents (which is already in place) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-427) [Javascript] Make ScriptableItemMap behave like an Array
[ https://issues.apache.org/jira/browse/SLING-427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Trieloff updated SLING-427: Attachment: SLING-427.patch This patch adds a length property to the map, making it behave like an array. If one of your elements in the map has the key length and you try named access, you are out of luck, but this is an acceptable limitation from my point of view. [Javascript] Make ScriptableItemMap behave like an Array Key: SLING-427 URL: https://issues.apache.org/jira/browse/SLING-427 Project: Sling Issue Type: Improvement Components: Scripting Reporter: Lars Trieloff Priority: Minor Attachments: SLING-427.patch The ScriptableItemMap which wraps an Iterator for Javascript scripts is nice, but it exposes itself as an object, not as an array, which makes it hard to loop easily over the contents of the map. It would be nice if the Map could expose an Array-like behavior by exposing a length field and allowing indexed access to its contents (which is already in place) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-428) [Javascript] allow Server-side inclusion of Javascript files
[ https://issues.apache.org/jira/browse/SLING-428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Trieloff updated SLING-428: Attachment: SLING-428.patch This patch implements the load() and print() methods in the global scope. load() will use the ResourceResolver to resolve a script and evaluate it, print() will log an info statement using the default logger. This patch has been tested with the Dojo Javascript library, proving that even massive libraries are supported. [Javascript] allow Server-side inclusion of Javascript files Key: SLING-428 URL: https://issues.apache.org/jira/browse/SLING-428 Project: Sling Issue Type: Improvement Components: Scripting Reporter: Lars Trieloff Attachments: SLING-428.patch For the sake of modularizing server-side Javascript libraries, it is advisable to have an inclusion mechanism. Javascript does not have an standardized way of handling inclusions, so I propose to use the conventions established by the Rhino Javascript Shell (http://www.mozilla.org/rhino/shell.html) which is introducing a load() function in the global scope, loading and evaluating a Javascript file in the current scope. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-429) Tune Dojo to allow server-side execution
Tune Dojo to allow server-side execution Key: SLING-429 URL: https://issues.apache.org/jira/browse/SLING-429 Project: Sling Issue Type: Improvement Components: Extensions Reporter: Lars Trieloff Following SLING-428, if you want to use Dojo on the server side, two modifications are neccessary: 1) you need the source build of Dojo, because the default release has been customized for in-browser environments, disabling auto-detection of the environment 2) the Rhino host environment in Stock Dojo expects to load scripts either as a File or as an URL, this needs to be changed to use Resources or URLs as input sources -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-429) Tune Dojo to allow server-side execution
[ https://issues.apache.org/jira/browse/SLING-429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Trieloff updated SLING-429: Attachment: SLING-429.patch This patch includes a customized hostenv_rhino.js file (I am just copying it, instead of using Ant's patch task, which requires the patch executabel to be on the path) and modifies the pom.xml to use the source package of Dojo and copy the customized hostenv_rhino.js over the stock Dojo files. I am also upgrading the version number of the bundle to reflect the recent upgrade to Dojo 1.1.0 Tune Dojo to allow server-side execution Key: SLING-429 URL: https://issues.apache.org/jira/browse/SLING-429 Project: Sling Issue Type: Improvement Components: Extensions Reporter: Lars Trieloff Attachments: SLING-429.patch Following SLING-428, if you want to use Dojo on the server side, two modifications are neccessary: 1) you need the source build of Dojo, because the default release has been customized for in-browser environments, disabling auto-detection of the environment 2) the Rhino host environment in Stock Dojo expects to load scripts either as a File or as an URL, this needs to be changed to use Resources or URLs as input sources -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-398) [Patch] Separate bundle details page in sling web console
[ https://issues.apache.org/jira/browse/SLING-398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated SLING-398: --- Remaining Estimate: 0h Original Estimate: 0h Could you please submit an updated patch against the latest svn? [Patch] Separate bundle details page in sling web console - Key: SLING-398 URL: https://issues.apache.org/jira/browse/SLING-398 Project: Sling Issue Type: New Feature Components: Console Reporter: Alexander Klimetschek Attachments: bundle-details-html-page.patch, bundle-details-html-page.patch, bundle-details-html-page.patch Original Estimate: 0h Remaining Estimate: 0h This patch adds a separate HTML page showing bundle details to the Sling web console. It displays the same details as those displayed by the ajax-based popup. Use case: I found myself configuring a bundle with Export-Package etc. and continuously installing it to Sling to see if all package dependencies could be resolved. It is quite tedious to reload the bundle list page, scroll down to the bundle in question and click on the link to get the ajax-based details popup. A simpler (and more restful) way is to have a separate URL and HTML page for a single bundle's details. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Servlet Registration
Hi all, Servlets registered as OSGi services are taken up by the Sling Servlet Resolver to use them for request processing. To this avail a number of service registration properties have been defined which are considered for that registration. One such property is the sling.servlet.methods property which takes a list of request method names for which the servlet is registered. It is currently allowed to omit this property, which causes the servlet to be registered with no specific method. This allows the servlet to be used as a fallback if no other servlet applies. An example of this mechanism is the SlingWebDavServlet. This mechanism - no property meaning all methods - has its drawbacks and is counter-intuitive for the developers used to sensitive defaults. In particular just leaving out a property intending to say just everything is probable not good, either. So I propose to change the sling.servlet.methods property handling as follows: * If the property is empty or missing, the property is assumed to be set to [ GET, HEAD ] * If the property is set to the single value *, the servlet is not registered for a specific method. * Otherwise the servlet is registered for the configured methods names. WDYT ? Regards Felix
Re: Servlet Registration
On Wed, May 7, 2008 at 10:38 AM, Felix Meschberger [EMAIL PROTECTED] wrote: ...I propose to change the sling.servlet.methods property handling as follows: * If the property is empty or missing, the property is assumed to be set to [ GET, HEAD ] * If the property is set to the single value *, the servlet is not registered for a specific method. * Otherwise the servlet is registered for the configured methods names... I agree with those changes. -Bertrand
Re: Servlet Registration
Felix Meschberger wrote: So I propose to change the sling.servlet.methods property handling as follows: * If the property is empty or missing, the property is assumed to be set to [ GET, HEAD ] * If the property is set to the single value *, the servlet is not registered for a specific method. * Otherwise the servlet is registered for the configured methods names. +1 Just to be clear, there are two ways of registering a servlet: a) by path b) by resource types Configuring things like methods, selectors or extensions are only used for registering a servlet for a resource type. And the two options are mutual exclusive. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Moving the Sling Management Console to Apache Felix
On Apr 11, 2008, at 9:54 , Bertrand Delacretaz wrote: On Fri, Apr 11, 2008 at 9:47 AM, Felix Meschberger [EMAIL PROTECTED] wrote: ... Point is, if we can show to the IPMC that both communities are interested in this move - shown by a vote in both places - this should not be a problem to the IPMC Ok, let's have those votes then. I'm also on the IPMC, so I'll support our case there if needed. Any update on this yet? Greetings, Marcel
[jira] Created: (SLING-430) Change behaviour of Servlet Resource Registration for missing sling.servlet.methods property
Change behaviour of Servlet Resource Registration for missing sling.servlet.methods property Key: SLING-430 URL: https://issues.apache.org/jira/browse/SLING-430 Project: Sling Issue Type: Improvement Components: ServletResolver Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: 2.0.0 As discussed in [1]: The behaviour of handling the sling.servlet.methods property should be modified as follows: * If the property is missing or empty, assume a value of [ GET, HEAD ] * If the property is set to a single * entry, assume support for no specific request method and register as a fallback for any methods not handled by other (more specific) servlets * Any other value of the property is used as the (list of) request method name(s) to register the servlet for This is different from the behaviour today, where an empty property is assumed to be non-specific support for all methods. [1] http://markmail.org/message/axkirfnce52va2op -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Servlet Registration
Hi all, Ok, I implemented this in Rev. 654077 (and have also adapted the SlingWebDavServlet). Regards Felix Am Mittwoch, den 07.05.2008, 10:58 +0200 schrieb Carsten Ziegeler: Felix Meschberger wrote: So I propose to change the sling.servlet.methods property handling as follows: * If the property is empty or missing, the property is assumed to be set to [ GET, HEAD ] * If the property is set to the single value *, the servlet is not registered for a specific method. * Otherwise the servlet is registered for the configured methods names. +1 Just to be clear, there are two ways of registering a servlet: a) by path b) by resource types Configuring things like methods, selectors or extensions are only used for registering a servlet for a resource type. And the two options are mutual exclusive. Carsten
Re: IncludeTest fails
Hi Bertrand, Bertrand Delacretaz schrieb: Hi Andreas (nice to see you here BTW ;-) I put big hopes in JCR, and maybe I can use Sling to get started (again) and learn some good practises. Actually it seems to resemble a part of the vision I had for a future Lenya: A framework which makes it easy to build content management applications on top of a powerful repository. Lenya has taken a different path (more product than framework), and has focused on a rather specific usage scenario. On Thu, Apr 24, 2008 at 4:26 PM, Andreas Hartmann [EMAIL PROTECTED] wrote: ... FYI: the IncludeTest fails on my machine after a fresh check-out (stack trace attached below). I wasn't sure if this belongs to an existing issue report (e.g. SLING-207), so I'm posting it here SLING-207 has been fixed for a long time, so I don't think it is related. All tests pass for me in revision 652071 if I do mvn clean install from the top of the Sling code tree, and I also have MacOSX and java version 1.5.0_13. In which SVN revision do you see the problem? The problem occurs in revision 650128; I'll do an update now and try again. Thanks a lot for your reply! -- Andreas -- Andreas Hartmann, CTO BeCompany GmbH http://www.becompany.ch Tel.: +41 (0) 43 818 57 01
[jira] Created: (SLING-431) Unexplained NPE in AbstractSlingRepository.pingAndCheck
Unexplained NPE in AbstractSlingRepository.pingAndCheck
---
Key: SLING-431
URL: https://issues.apache.org/jira/browse/SLING-431
Project: Sling
Issue Type: Bug
Reporter: Bertrand Delacretaz
Priority: Minor
I've found this trace in the log of my custom launchpad-based Sling webapp:
Exception in thread Repository Pinger java.lang.NullPointerException
at
org.apache.sling.jcr.base.AbstractSlingRepository.pingAndCheck(AbstractSlingRepository.java:481)
at
org.apache.sling.jcr.base.AbstractSlingRepository.run(AbstractSlingRepository.java:898)
at java.lang.Thread.run(Thread.java:613)
This happened at startup, but only once with many successful startups with the
same code and configuration.
The corresponding code line is the log.log call in
} catch(RepositoryException re) {
log.log(LogService.LOG_INFO, pingAndCheck; loginAdministrative
failed, re);
}
So the only explanation is that log is null, which is impossible looking at
the source code: the thread that calls pingAndCheck is created in activate(),
which must be called by the OSGi framework after initializing the log member
variable:
/** @scr.reference bind=bindLog unbind=unbindLog */
private LogService log;
There is something weird about the log class, in the error log:
07.05.2008 13:20:39.574 *ERROR* [SCR Component Actor]
org.apache.sling.jcr.jackrabbit.client
[org.apache.sling.jcr.jackrabbit.client.SlingClientRepository] Cannot load
class used as parameter org.osgi.service.log.Lo
gService (java.lang.ClassNotFoundException: org.osgi.service.log.LogService)
java.lang.ClassNotFoundException: org.osgi.service.log.LogService
at org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1504)
That happens before the above NPE.
I won't investigate further for now, but this looks like a weird timing-related
bug.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-431) Unexplained NPE in AbstractSlingRepository.pingAndCheck
[
https://issues.apache.org/jira/browse/SLING-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12594895#action_12594895
]
Bertrand Delacretaz commented on SLING-431:
---
Note that things worked fine after stopping and restarting the repository
client bundle.
Unexplained NPE in AbstractSlingRepository.pingAndCheck
---
Key: SLING-431
URL: https://issues.apache.org/jira/browse/SLING-431
Project: Sling
Issue Type: Bug
Reporter: Bertrand Delacretaz
Priority: Minor
I've found this trace in the log of my custom launchpad-based Sling webapp:
Exception in thread Repository Pinger java.lang.NullPointerException
at
org.apache.sling.jcr.base.AbstractSlingRepository.pingAndCheck(AbstractSlingRepository.java:481)
at
org.apache.sling.jcr.base.AbstractSlingRepository.run(AbstractSlingRepository.java:898)
at java.lang.Thread.run(Thread.java:613)
This happened at startup, but only once with many successful startups with
the same code and configuration.
The corresponding code line is the log.log call in
} catch(RepositoryException re) {
log.log(LogService.LOG_INFO, pingAndCheck;
loginAdministrative failed, re);
}
So the only explanation is that log is null, which is impossible looking at
the source code: the thread that calls pingAndCheck is created in activate(),
which must be called by the OSGi framework after initializing the log member
variable:
/** @scr.reference bind=bindLog unbind=unbindLog */
private LogService log;
There is something weird about the log class, in the error log:
07.05.2008 13:20:39.574 *ERROR* [SCR Component Actor]
org.apache.sling.jcr.jackrabbit.client
[org.apache.sling.jcr.jackrabbit.client.SlingClientRepository] Cannot load
class used as parameter org.osgi.service.log.Lo
gService (java.lang.ClassNotFoundException: org.osgi.service.log.LogService)
java.lang.ClassNotFoundException: org.osgi.service.log.LogService
at org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1504)
That happens before the above NPE.
I won't investigate further for now, but this looks like a weird
timing-related bug.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-432) Metatype descriptor for SlingAuthenticator inconsistent with actual default value
Metatype descriptor for SlingAuthenticator inconsistent with actual default value - Key: SLING-432 URL: https://issues.apache.org/jira/browse/SLING-432 Project: Sling Issue Type: Bug Components: Core Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: 2.0.0 The Metatype descriptor defines the default value for the auth.anonymous parameter to be false, which the actual default value in the SlingAuthenticator class is defined as true. This is inconsistent and causes confusion when comparing the displayed default configuration in the Sling Console Configuration screen to the actual behaviour. The fix is to use the recently added valueRef attribute for the @scr.property tag to refer to the constant describing the actual default value. The same fix should be applied to the other configuration properties in the SlingAuthenticator class. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (SLING-432) Metatype descriptor for SlingAuthenticator inconsistent with actual default value
[ https://issues.apache.org/jira/browse/SLING-432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed SLING-432. --- Resolution: Fixed Fixed in Rev. 654086 together with update to the message catalogue used to build the configuration GUI. Metatype descriptor for SlingAuthenticator inconsistent with actual default value - Key: SLING-432 URL: https://issues.apache.org/jira/browse/SLING-432 Project: Sling Issue Type: Bug Components: Core Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: 2.0.0 The Metatype descriptor defines the default value for the auth.anonymous parameter to be false, which the actual default value in the SlingAuthenticator class is defined as true. This is inconsistent and causes confusion when comparing the displayed default configuration in the Sling Console Configuration screen to the actual behaviour. The fix is to use the recently added valueRef attribute for the @scr.property tag to refer to the constant describing the actual default value. The same fix should be applied to the other configuration properties in the SlingAuthenticator class. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-431) Unexplained NPE in AbstractSlingRepository.pingAndCheck
[
https://issues.apache.org/jira/browse/SLING-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12594904#action_12594904
]
Carsten Ziegeler commented on SLING-431:
I experienced the same strange log entry about the ClassNotFoundException. The
reason was that my repository client bundle did not have an import for
org.osgi.service.log. This *should* be generated by the maven plugin, but for
some strange reasons it did not. Even more strange: the app did run without any
problems.
So have a look if this import is in the client bundle; if not it should be
added.
Unexplained NPE in AbstractSlingRepository.pingAndCheck
---
Key: SLING-431
URL: https://issues.apache.org/jira/browse/SLING-431
Project: Sling
Issue Type: Bug
Reporter: Bertrand Delacretaz
Priority: Minor
I've found this trace in the log of my custom launchpad-based Sling webapp:
Exception in thread Repository Pinger java.lang.NullPointerException
at
org.apache.sling.jcr.base.AbstractSlingRepository.pingAndCheck(AbstractSlingRepository.java:481)
at
org.apache.sling.jcr.base.AbstractSlingRepository.run(AbstractSlingRepository.java:898)
at java.lang.Thread.run(Thread.java:613)
This happened at startup, but only once with many successful startups with
the same code and configuration.
The corresponding code line is the log.log call in
} catch(RepositoryException re) {
log.log(LogService.LOG_INFO, pingAndCheck;
loginAdministrative failed, re);
}
So the only explanation is that log is null, which is impossible looking at
the source code: the thread that calls pingAndCheck is created in activate(),
which must be called by the OSGi framework after initializing the log member
variable:
/** @scr.reference bind=bindLog unbind=unbindLog */
private LogService log;
There is something weird about the log class, in the error log:
07.05.2008 13:20:39.574 *ERROR* [SCR Component Actor]
org.apache.sling.jcr.jackrabbit.client
[org.apache.sling.jcr.jackrabbit.client.SlingClientRepository] Cannot load
class used as parameter org.osgi.service.log.Lo
gService (java.lang.ClassNotFoundException: org.osgi.service.log.LogService)
java.lang.ClassNotFoundException: org.osgi.service.log.LogService
at org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1504)
That happens before the above NPE.
I won't investigate further for now, but this looks like a weird
timing-related bug.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SLING-426) Sling client library tests: Allow Anonymous Access configuration on Authentication Filter does not take effect.
[ https://issues.apache.org/jira/browse/SLING-426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger reassigned SLING-426: --- Assignee: Felix Meschberger Sling client library tests: Allow Anonymous Access configuration on Authentication Filter does not take effect. --- Key: SLING-426 URL: https://issues.apache.org/jira/browse/SLING-426 Project: Sling Issue Type: Bug Components: Testing Environment: Windows Reporter: Paul Noden Assignee: Felix Meschberger Priority: Minor In the latest version I found that checking the Allow Anonymous Access configuration on Authentication Filter does not take effect. Changing the anonymous user/password for the Embedded JCR Repository to admin:admin was the only way I got the Sling client library tests -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (SLING-426) Sling client library tests: Allow Anonymous Access configuration on Authentication Filter does not take effect.
[ https://issues.apache.org/jira/browse/SLING-426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed SLING-426. --- Resolution: Duplicate Fix Version/s: 2.0.0 Closing this as a duplicate of SLING-432. Sling client library tests: Allow Anonymous Access configuration on Authentication Filter does not take effect. --- Key: SLING-426 URL: https://issues.apache.org/jira/browse/SLING-426 Project: Sling Issue Type: Bug Components: Testing Environment: Windows Reporter: Paul Noden Assignee: Felix Meschberger Priority: Minor Fix For: 2.0.0 In the latest version I found that checking the Allow Anonymous Access configuration on Authentication Filter does not take effect. Changing the anonymous user/password for the Embedded JCR Repository to admin:admin was the only way I got the Sling client library tests -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-431) Unexplained NPE in AbstractSlingRepository.pingAndCheck
[
https://issues.apache.org/jira/browse/SLING-431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bertrand Delacretaz resolved SLING-431.
---
Resolution: Cannot Reproduce
Thanks for the pointer, I have added the org.osgi.service.log Import-Package to
the jcr.jackrabbit.client bundle and that got rid of the ClassNotFoundException.
Closing this as cannot reproduce for now, I'll reopen it if I see the problem
again.
Unexplained NPE in AbstractSlingRepository.pingAndCheck
---
Key: SLING-431
URL: https://issues.apache.org/jira/browse/SLING-431
Project: Sling
Issue Type: Bug
Reporter: Bertrand Delacretaz
Priority: Minor
I've found this trace in the log of my custom launchpad-based Sling webapp:
Exception in thread Repository Pinger java.lang.NullPointerException
at
org.apache.sling.jcr.base.AbstractSlingRepository.pingAndCheck(AbstractSlingRepository.java:481)
at
org.apache.sling.jcr.base.AbstractSlingRepository.run(AbstractSlingRepository.java:898)
at java.lang.Thread.run(Thread.java:613)
This happened at startup, but only once with many successful startups with
the same code and configuration.
The corresponding code line is the log.log call in
} catch(RepositoryException re) {
log.log(LogService.LOG_INFO, pingAndCheck;
loginAdministrative failed, re);
}
So the only explanation is that log is null, which is impossible looking at
the source code: the thread that calls pingAndCheck is created in activate(),
which must be called by the OSGi framework after initializing the log member
variable:
/** @scr.reference bind=bindLog unbind=unbindLog */
private LogService log;
There is something weird about the log class, in the error log:
07.05.2008 13:20:39.574 *ERROR* [SCR Component Actor]
org.apache.sling.jcr.jackrabbit.client
[org.apache.sling.jcr.jackrabbit.client.SlingClientRepository] Cannot load
class used as parameter org.osgi.service.log.Lo
gService (java.lang.ClassNotFoundException: org.osgi.service.log.LogService)
java.lang.ClassNotFoundException: org.osgi.service.log.LogService
at org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1504)
That happens before the above NPE.
I won't investigate further for now, but this looks like a weird
timing-related bug.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[Solved] Re: IncludeTest fails
Andreas Hartmann schrieb: FYI: the IncludeTest fails on my machine after a fresh check-out (stack trace attached below). I wasn't sure if this belongs to an existing issue report (e.g. SLING-207), so I'm posting it here. The problem doesn't occur anymore in revision 654077. -- Andreas Environment: Mac OS X, Java 1.5.0_13 -- Andreas --- Test set: org.apache.sling.launchpad.webapp.integrationtest.IncludeTest --- Tests run: 5, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 46.93 sec FAILURE! testInfiniteLoopDetection(org.apache.sling.launchpad.webapp.integrationtest.IncludeTest) Time elapsed: 33.688 sec FAILURE! junit.framework.AssertionFailedError: Response contains infinite loop error message at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.assertTrue(Assert.java:20) at org.apache.sling.launchpad.webapp.integrationtest.IncludeTest.testInfiniteLoopDetection(IncludeTest.java:129) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at junit.framework.TestCase.runTest(TestCase.java:168) at junit.framework.TestCase.runBare(TestCase.java:134) at junit.framework.TestResult$1.protect(TestResult.java:110) at junit.framework.TestResult.runProtected(TestResult.java:128) at junit.framework.TestResult.run(TestResult.java:113) at junit.framework.TestCase.run(TestCase.java:124) at junit.framework.TestSuite.runTest(TestSuite.java:232) at junit.framework.TestSuite.run(TestSuite.java:227) at org.junit.internal.runners.OldTestClassRunner.run(OldTestClassRunner.java:76) at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127) at org.apache.maven.surefire.Surefire.run(Surefire.java:177) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:338) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:997) -- Andreas Hartmann, CTO BeCompany GmbH http://www.becompany.ch Tel.: +41 (0) 43 818 57 01
Re: [Solved] Re: IncludeTest fails
On Wed, May 7, 2008 at 3:46 PM, Andreas Hartmann [EMAIL PROTECTED] wrote: ...The problem doesn't occur anymore in revision 654077... Cool, thanks for reporting! -Bertrand
Re: IncludeTest fails
On Wed, May 7, 2008 at 2:23 PM, Andreas Hartmann [EMAIL PROTECTED] wrote: ...Actually it seems to resemble a part of the vision I had for a future Lenya: A framework which makes it easy to build content management applications on top of a powerful repository Which is exactly the focus of Sling, so hope you like it! And if not, suggestions/patches are of course welcome. -Bertrand
[jira] Updated: (SLING-425) SlingLogFileWriter fails three test cases
[ https://issues.apache.org/jira/browse/SLING-425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Noden updated SLING-425: - Attachment: SlingLogFileWriterTest.java Attached SlingLogFileWriterTest.java. The tests which fail on windows are indicated with // TODO: TEST FAILURE: SlingLogFileWriter fails three test cases - Key: SLING-425 URL: https://issues.apache.org/jira/browse/SLING-425 Project: Sling Issue Type: Bug Components: Testing Environment: Windows Reporter: Paul Noden Priority: Minor Attachments: SlingLogFileWriterTest.java The test for SlingLogFileWriter failed in the three test cases in SlingLogFileWriterTest where assertTrue(test.exists() test.length() 0) is made. I took the liberty of commenting out from this line to the end of each test case and found that all the other tests in the build process on windows still reported successful - with the exception of the tests run once sling has started up, all of which fail with Sling services not available.- I'm hoping this is a consequence of these logging issues. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Resolved: (SLING-431) Unexplained NPE in AbstractSlingRepository.pingAndCheck
Hi,
Am Mittwoch, den 07.05.2008, 06:46 -0700 schrieb Bertrand Delacretaz
(JIRA):
Thanks for the pointer, I have added the org.osgi.service.log Import-Package
to the jcr.jackrabbit.client bundle and that got rid of the
ClassNotFoundException.
Could this be something we should talk to Peter Kriens and Stuart
about ?
Regards
Felix
Closing this as cannot reproduce for now, I'll reopen it if I see the
problem again.
Unexplained NPE in AbstractSlingRepository.pingAndCheck
---
Key: SLING-431
URL: https://issues.apache.org/jira/browse/SLING-431
Project: Sling
Issue Type: Bug
Reporter: Bertrand Delacretaz
Priority: Minor
I've found this trace in the log of my custom launchpad-based Sling webapp:
Exception in thread Repository Pinger java.lang.NullPointerException
at
org.apache.sling.jcr.base.AbstractSlingRepository.pingAndCheck(AbstractSlingRepository.java:481)
at
org.apache.sling.jcr.base.AbstractSlingRepository.run(AbstractSlingRepository.java:898)
at java.lang.Thread.run(Thread.java:613)
This happened at startup, but only once with many successful startups with
the same code and configuration.
The corresponding code line is the log.log call in
} catch(RepositoryException re) {
log.log(LogService.LOG_INFO, pingAndCheck;
loginAdministrative failed, re);
}
So the only explanation is that log is null, which is impossible looking
at the source code: the thread that calls pingAndCheck is created in
activate(), which must be called by the OSGi framework after initializing
the log member variable:
/** @scr.reference bind=bindLog unbind=unbindLog */
private LogService log;
There is something weird about the log class, in the error log:
07.05.2008 13:20:39.574 *ERROR* [SCR Component Actor]
org.apache.sling.jcr.jackrabbit.client
[org.apache.sling.jcr.jackrabbit.client.SlingClientRepository] Cannot load
class used as parameter org.osgi.service.log.Lo
gService (java.lang.ClassNotFoundException:
org.osgi.service.log.LogService) java.lang.ClassNotFoundException:
org.osgi.service.log.LogService
at org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1504)
That happens before the above NPE.
I won't investigate further for now, but this looks like a weird
timing-related bug.
[jira] Created: (SLING-433) DefaultSlingScript should only set currentNode property if not null
DefaultSlingScript should only set currentNode property if not null --- Key: SLING-433 URL: https://issues.apache.org/jira/browse/SLING-433 Project: Sling Issue Type: Bug Components: Scripting Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: 2.0.0 The DefaultSlingScript.verifySlingBindings sets the currentNode property to the resource adapted to a Node. This may be null in case the resource is not node-based. In such situations the currentNode property should not be set. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (SLING-433) DefaultSlingScript should only set currentNode property if not null
[ https://issues.apache.org/jira/browse/SLING-433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed SLING-433. --- Resolution: Fixed Fixed in Rev. 654204 DefaultSlingScript should only set currentNode property if not null --- Key: SLING-433 URL: https://issues.apache.org/jira/browse/SLING-433 Project: Sling Issue Type: Bug Components: Scripting Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: 2.0.0 The DefaultSlingScript.verifySlingBindings sets the currentNode property to the resource adapted to a Node. This may be null in case the resource is not node-based. In such situations the currentNode property should not be set. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-434) DefaultGetServlet should check for a NonExistingResource before dispatching to renderers
DefaultGetServlet should check for a NonExistingResource before dispatching to renderers Key: SLING-434 URL: https://issues.apache.org/jira/browse/SLING-434 Project: Sling Issue Type: Improvement Components: Default Servlets Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: 2.0.0 The DefaultGetServlet dispatches the requests to the actual renderes based on the request extension. It does not currently check whether the resource underlying the request actually exists. Rather - by coincidence - this check is executed by the StreamRendererServlet. By Coincidence because a request for a non existing resource has no request extension which causes the StreamRendererServlet being selected for rendering. Better is for the DefaultGetServlet to check for the NonExistingResource and fail early before dispatching. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (SLING-434) DefaultGetServlet should check for a NonExistingResource before dispatching to renderers
[ https://issues.apache.org/jira/browse/SLING-434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed SLING-434. --- Resolution: Fixed Fixed in Rev. 654210 by moving the NonExistingResource check from the StreamRendererServlet to the DefaultGetServlet. DefaultGetServlet should check for a NonExistingResource before dispatching to renderers Key: SLING-434 URL: https://issues.apache.org/jira/browse/SLING-434 Project: Sling Issue Type: Improvement Components: Default Servlets Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: 2.0.0 The DefaultGetServlet dispatches the requests to the actual renderes based on the request extension. It does not currently check whether the resource underlying the request actually exists. Rather - by coincidence - this check is executed by the StreamRendererServlet. By Coincidence because a request for a non existing resource has no request extension which causes the StreamRendererServlet being selected for rendering. Better is for the DefaultGetServlet to check for the NonExistingResource and fail early before dispatching. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[VOTE] Moving the Sling Management Console to Apache Felix
Hi all, After an initial round of discussion and letting it almost be forgotten, we should finally start to get this moving again. As noted in [1] the incubating Apache Sling project has a module - a single bundle - which provides a Web Based Management Console. The base bundle allows mainly for OSGi management such as bundle lifecycle management, configuration, etc. But the console is in fact extensible and more functionality may easily be plugged into it. Members of the Felix and Sling community met at ApacheCon in Amsterdam and and came to the conclusion, that the Apache Felix project would be the natural location for such a management console. Mainly because people looking for OSGi stuff would turn to Felix and not primarily to Sling. There is no release yet of the Sling Management Console and there are a number of open issues [2], which should be fixed/implemented before a first release of the console. Nevertheless the console is already usable in its current state and therefore, I think we may just move it as is and finish it in Apache Felix. So here is the vote. As always, it will be open for 72 hours and only votes of Sling PPMC members are binding (though anybody is cordially invited to vote): [+1] Yes, move the Management Console to Apache Felix [0] Don't care [-1] No, keep it in Sling Regards Felix PS: A paralell vote has been started on the Felix Dev list [3] to ask whether Felix would be willing to take over the console. [1] http://markmail.org/message/tizwcfggwcrnngei [2] http://issues.apache.org/jira/browse/SLING/component/12312091 [3] http://markmail.org/message/ex6wjqowp7psomv4
Re: [VOTE] Moving the Sling Management Console to Apache Felix
+1 On 5/7/08 1:04 PM, Felix Meschberger [EMAIL PROTECTED] wrote: Hi all, After an initial round of discussion and letting it almost be forgotten, we should finally start to get this moving again. As noted in [1] the incubating Apache Sling project has a module - a single bundle - which provides a Web Based Management Console. The base bundle allows mainly for OSGi management such as bundle lifecycle management, configuration, etc. But the console is in fact extensible and more functionality may easily be plugged into it. Members of the Felix and Sling community met at ApacheCon in Amsterdam and and came to the conclusion, that the Apache Felix project would be the natural location for such a management console. Mainly because people looking for OSGi stuff would turn to Felix and not primarily to Sling. There is no release yet of the Sling Management Console and there are a number of open issues [2], which should be fixed/implemented before a first release of the console. Nevertheless the console is already usable in its current state and therefore, I think we may just move it as is and finish it in Apache Felix. So here is the vote. As always, it will be open for 72 hours and only votes of Sling PPMC members are binding (though anybody is cordially invited to vote): [+1] Yes, move the Management Console to Apache Felix [0] Don't care [-1] No, keep it in Sling Regards Felix PS: A paralell vote has been started on the Felix Dev list [3] to ask whether Felix would be willing to take over the console. [1] http://markmail.org/message/tizwcfggwcrnngei [2] http://issues.apache.org/jira/browse/SLING/component/12312091 [3] http://markmail.org/message/ex6wjqowp7psomv4
