[jira] Resolved: (SLING-1631) Classloading problems when taglibs are used.
[ https://issues.apache.org/jira/browse/SLING-1631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-1631. - Resolution: Fixed Fixed in revision 982966 The taglib now uses the same logic for detecting taglib changes as the classloader uses for bundles Simplified and fixed the timestamp checking for taglibs. Classloading problems when taglibs are used. Key: SLING-1631 URL: https://issues.apache.org/jira/browse/SLING-1631 Project: Sling Issue Type: Bug Components: Scripting Affects Versions: Scripting JSP 2.0.8 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Scripting JSP 2.0.10 When taglibs are used together with jsp scripting there are several problems: 1. The taglib cache does not detect changes to taglibs (contained in bundles) like the general classloading mechanism through the dynamic classloader - this can result in inconsistencies and classloading problems. 2. The last modified check for taglibs does not work as expected. As soon as tags are used, they are considered as changed which results in recompilation of the jsp and of the tag where the second invalidates the classloader of the jsp. This classloader is later on used and then a classloading exception is thrown -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1445) store the AuthenticationInfo object in a request attribute
[ https://issues.apache.org/jira/browse/SLING-1445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12896054#action_12896054 ] Carsten Ziegeler commented on SLING-1445: - Maybe we could add something like a copy() method to the resource resolver: ResourceResolver newRR = oldRR.copy(); store the AuthenticationInfo object in a request attribute -- Key: SLING-1445 URL: https://issues.apache.org/jira/browse/SLING-1445 Project: Sling Issue Type: Improvement Components: Commons Reporter: Justin Edelson Assignee: Justin Edelson Fix For: Commons Auth 1.0.0 called org.apache.sling.commons.auth.spi.AuthenticationInfo -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-1636) Provide a mechanism to detect if a dynamic classloader is still valid
Provide a mechanism to detect if a dynamic classloader is still valid - Key: SLING-1636 URL: https://issues.apache.org/jira/browse/SLING-1636 Project: Sling Issue Type: New Feature Components: Commons Affects Versions: Commons ClassLoader 1.1.4 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Commons ClassLoader 1.2.0 In some situations it is useful to know if a used classloader is still live/valid. Especially with dynamic class loaders it happens that a classloader gets invalidated but is still in use. In such cases the client of such a classloader should be able to detect this and reload classes. One use case is scripting in Sling: we have the JCR based classloader and for example compiled scripts. A JCR classloader gets invalid as soon as something changes with the classes it has loaded in the repository. In this case the jsp script engine should reload the compiled classes -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-1636) Provide a mechanism to detect if a dynamic classloader is still valid
[ https://issues.apache.org/jira/browse/SLING-1636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-1636. - Resolution: Fixed Added a new interface DynamicClassLoader in revision 983910 which can be implemented by dynamic class loaders. This allows clients to check the used classloaders. Provide a mechanism to detect if a dynamic classloader is still valid - Key: SLING-1636 URL: https://issues.apache.org/jira/browse/SLING-1636 Project: Sling Issue Type: New Feature Components: Commons Affects Versions: Commons ClassLoader 1.1.4 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Commons ClassLoader 1.2.0 In some situations it is useful to know if a used classloader is still live/valid. Especially with dynamic class loaders it happens that a classloader gets invalidated but is still in use. In such cases the client of such a classloader should be able to detect this and reload classes. One use case is scripting in Sling: we have the JCR based classloader and for example compiled scripts. A JCR classloader gets invalid as soon as something changes with the classes it has loaded in the repository. In this case the jsp script engine should reload the compiled classes -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-1637) Support DynamicClassLoader interface
Support DynamicClassLoader interface Key: SLING-1637 URL: https://issues.apache.org/jira/browse/SLING-1637 Project: Sling Issue Type: New Feature Components: JCR Affects Versions: JCR Classloader 3.1.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: JCR Classloader 3.1.2 The jcr class loader should support the new DynamicClassLoader interface from commons classloader to allow clients to detect if the used classloader is invalid -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-1637) Support DynamicClassLoader interface
[ https://issues.apache.org/jira/browse/SLING-1637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-1637. - Resolution: Fixed Added support for the interface in revision 983917 Support DynamicClassLoader interface Key: SLING-1637 URL: https://issues.apache.org/jira/browse/SLING-1637 Project: Sling Issue Type: New Feature Components: JCR Affects Versions: JCR Classloader 3.1.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: JCR Classloader 3.1.2 The jcr class loader should support the new DynamicClassLoader interface from commons classloader to allow clients to detect if the used classloader is invalid -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-1638) Reload jsp if used classloader is invalid
Reload jsp if used classloader is invalid - Key: SLING-1638 URL: https://issues.apache.org/jira/browse/SLING-1638 Project: Sling Issue Type: Improvement Components: Scripting Affects Versions: Scripting JSP 2.0.8 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Scripting JSP 2.0.10 The jsp scripting should use the new dynamic class loader interface to check if the used class loaders for a jsp are still valid. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-1638) Reload jsp if used classloader is invalid
[ https://issues.apache.org/jira/browse/SLING-1638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-1638. - Resolution: Fixed Using new class loader feature with revision 983940 Reload jsp if used classloader is invalid - Key: SLING-1638 URL: https://issues.apache.org/jira/browse/SLING-1638 Project: Sling Issue Type: Improvement Components: Scripting Affects Versions: Scripting JSP 2.0.8 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Scripting JSP 2.0.10 The jsp scripting should use the new dynamic class loader interface to check if the used class loaders for a jsp are still valid. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-1607) org.apache.sling.osgi.installer stops only with errors
[ https://issues.apache.org/jira/browse/SLING-1607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-1607. - Assignee: Carsten Ziegeler Fix Version/s: OSGi Installer 3.0.0 Resolution: Fixed Fixed this while cleaning up the code with revision 983998 org.apache.sling.osgi.installer stops only with errors -- Key: SLING-1607 URL: https://issues.apache.org/jira/browse/SLING-1607 Project: Sling Issue Type: Bug Components: Installer Affects Versions: JCR Install 2.0.4 Environment: CQ 5.3 released using JCR install3.0.0.R889608 Reporter: Thierry Yge Assignee: Carsten Ziegeler Fix For: OSGi Installer 3.0.0 Attachments: logs(2).zip On shutdown the following error occurs on the deactivation of the jcr install 16.07.2010 09:17:57.039 *ERROR* [FelixDispatchQueue] org.apache.sling.osgi.installer FrameworkEvent ERROR (org.osgi.framework.BundleException: Activator stop error in bundle org.apache.sling.osgi.installer [265].) org.osgi.framework.BundleException: Activator stop error in bundle org.apache.sling.osgi.installer [265]. at org.apache.felix.framework.Felix.stopBundle(Felix.java:2128) at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1095) at org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:264) at java.lang.Thread.run(Thread.java:619) Caused by: java.lang.NullPointerException at java.util.TreeMap.put(TreeMap.java:541) at java.util.TreeSet.add(TreeSet.java:238) at org.apache.sling.osgi.installer.impl.OsgiInstallerImpl.deactivate(OsgiInstallerImpl.java:67) at org.apache.sling.osgi.installer.impl.Activator.stop(Activator.java:111) at org.apache.felix.framework.util.SecureAction.stopActivator(SecureAction.java:662) at org.apache.felix.framework.Felix.stopBundle(Felix.java:2071) ... 3 more Is it harmless ? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1560) Improve and clean up code
[ https://issues.apache.org/jira/browse/SLING-1560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12896926#action_12896926 ] Carsten Ziegeler commented on SLING-1560: - Changes in revision 983998: Removed the input stream support for dictionaries from the osgi installer - reading configurations is up to the providers like jcr install. By removing this we can reduce the complexity of the installer. Moved logging to a Logger class to avoid passing around the installer context just for logging Moved statistics methods to own interface as this is just used for testing and should not be part of the public api Cleaned up installable resource factory Changed type of installable resource from enum to String in order to provide pluggable installers in the future Improve and clean up code - Key: SLING-1560 URL: https://issues.apache.org/jira/browse/SLING-1560 Project: Sling Issue Type: Improvement Components: Installer Affects Versions: OSGi Installer 3.0.0, JCR Installer 3.0.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: OSGi Installer 3.0.0, JCR Installer 3.0.0 In order to fix some outstanding bugs and to add new features, a code review and clean up seems to be a good idea :) This bug will keep track of all changes to the code that don't add new features -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1335) Timing issues in OSGi installer integration tests
[ https://issues.apache.org/jira/browse/SLING-1335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12896928#action_12896928 ] Carsten Ziegeler commented on SLING-1335: - I fixed one IT test case - the only one with timing problems, at least on my machine, is the config admin test Timing issues in OSGi installer integration tests - Key: SLING-1335 URL: https://issues.apache.org/jira/browse/SLING-1335 Project: Sling Issue Type: Bug Components: Installer Reporter: Bertrand Delacretaz Priority: Minor Seems like some tests in the installer/osgi/it have timing issues which make them fail semi-randomly. More often on Hudson that on my macbook, for example. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1560) Improve and clean up code
[ https://issues.apache.org/jira/browse/SLING-1560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12897076#action_12897076 ] Carsten Ziegeler commented on SLING-1560: - Changes in revision 984254: Move all config admin related stuff into config admin package - the config support must be optional (VIP) Reduce usage of installer context (VIP) Improve and clean up code - Key: SLING-1560 URL: https://issues.apache.org/jira/browse/SLING-1560 Project: Sling Issue Type: Improvement Components: Installer Affects Versions: OSGi Installer 3.0.0, JCR Installer 3.0.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: OSGi Installer 3.0.0, JCR Installer 3.0.0 In order to fix some outstanding bugs and to add new features, a code review and clean up seems to be a good idea :) This bug will keep track of all changes to the code that don't add new features -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1560) Improve and clean up code
[ https://issues.apache.org/jira/browse/SLING-1560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12897155#action_12897155 ] Carsten Ziegeler commented on SLING-1560: - Changes in revision: 984304 Further reduce the usage of the installer context Improve and clean up code - Key: SLING-1560 URL: https://issues.apache.org/jira/browse/SLING-1560 Project: Sling Issue Type: Improvement Components: Installer Affects Versions: OSGi Installer 3.0.0, JCR Installer 3.0.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: OSGi Installer 3.0.0, JCR Installer 3.0.0 In order to fix some outstanding bugs and to add new features, a code review and clean up seems to be a good idea :) This bug will keep track of all changes to the code that don't add new features -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-1414) JSP Expression Language (eg: ${resource.path}) to call the getPath() method of a Resource object returned by ResourceResolver.findResources() result in error.
[
https://issues.apache.org/jira/browse/SLING-1414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler updated SLING-1414:
Affects Version/s: JCR Resource 2.0.6
JSP Expression Language (eg: ${resource.path}) to call the getPath() method
of a Resource object returned by ResourceResolver.findResources() result in
error.
Key: SLING-1414
URL: https://issues.apache.org/jira/browse/SLING-1414
Project: Sling
Issue Type: Bug
Components: JCR
Affects Versions: JCR Resource 2.0.6
Environment: CQ5.2.1/CQ5.3
Reporter: zhangchunlong
Priority: Minor
Often in the JSPs, we call the ResourceResolver.findResources(query, xpath)
method to return an IteratorResource object, which we iterate through using
JSTL and EL syntax. When we attempt to access the getPath() method of each
Resource, the following exception is thrown:
java.lang.IllegalAccessException: Class javax.el.BeanELResolver can not
access a member of class
org.apache.sling.jcr.resource.internal.helper.jcr.JcrItemResource with
modifiers public.
This works with CQ5.2.1 with no problem before. The issue happens on CQ5.3 GA
release.
Example codes to re-produce the error in CQ5.3.
IteratorResource found = resourceResolver.findResources(//element(*,
nt:unstructured),xpath);
while(found.hasNext()){
try{
Resource foundResource = found.next();
pageContext.setAttribute(foundResource, foundResource);
%${foundResource.path}%
}
catch(Exception e){
%%=e.getMessage()%%
}
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1560) Improve and clean up code
[ https://issues.apache.org/jira/browse/SLING-1560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12897266#action_12897266 ] Carsten Ziegeler commented on SLING-1560: - Changes in revision 984405 Do counter handling internally and tasks should not throw an exception Improve and clean up code - Key: SLING-1560 URL: https://issues.apache.org/jira/browse/SLING-1560 Project: Sling Issue Type: Improvement Components: Installer Affects Versions: OSGi Installer 3.0.0, JCR Installer 3.0.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: OSGi Installer 3.0.0, JCR Installer 3.0.0 In order to fix some outstanding bugs and to add new features, a code review and clean up seems to be a good idea :) This bug will keep track of all changes to the code that don't add new features -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1560) Improve and clean up code
[ https://issues.apache.org/jira/browse/SLING-1560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12897318#action_12897318 ] Carsten Ziegeler commented on SLING-1560: - Changes in revision: 984451 The installable resource factory detects now only known types - this allows for pluggable formats. Improve and clean up code - Key: SLING-1560 URL: https://issues.apache.org/jira/browse/SLING-1560 Project: Sling Issue Type: Improvement Components: Installer Affects Versions: OSGi Installer 3.0.0, JCR Installer 3.0.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: OSGi Installer 3.0.0, JCR Installer 3.0.0 In order to fix some outstanding bugs and to add new features, a code review and clean up seems to be a good idea :) This bug will keep track of all changes to the code that don't add new features -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1560) Improve and clean up code
[ https://issues.apache.org/jira/browse/SLING-1560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12897361#action_12897361 ] Carsten Ziegeler commented on SLING-1560: - Changs in revision 984500 Removed the installable resources factory again and converted the installable resource to a class; this makes it easier for clients of the osgi installer. Improve and clean up code - Key: SLING-1560 URL: https://issues.apache.org/jira/browse/SLING-1560 Project: Sling Issue Type: Improvement Components: Installer Affects Versions: OSGi Installer 3.0.0, JCR Installer 3.0.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: OSGi Installer 3.0.0, JCR Installer 3.0.0 In order to fix some outstanding bugs and to add new features, a code review and clean up seems to be a good idea :) This bug will keep track of all changes to the code that don't add new features -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-1644) Use configuration reader from Apache Felix ConfigAdmin
Use configuration reader from Apache Felix ConfigAdmin -- Key: SLING-1644 URL: https://issues.apache.org/jira/browse/SLING-1644 Project: Sling Issue Type: Improvement Components: Installer Affects Versions: OSGi Installer 3.0.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: OSGi Installer 3.0.0 The Apache Felix ConfigAdmin provides an easily integrateable reader for configuration files - we should directly use this in the installer to support configurations based on an input stream. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-1643) Add start level support
Add start level support --- Key: SLING-1643 URL: https://issues.apache.org/jira/browse/SLING-1643 Project: Sling Issue Type: Improvement Components: Installer Affects Versions: OSGi Installer 3.0.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: OSGi Installer 3.0.0 An installable resource for a bundle might also contain a dictionary with additional information like a start level. If such a valid start level is provided the bundle should be installed in that level -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1560) Improve and clean up code
[ https://issues.apache.org/jira/browse/SLING-1560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12897599#action_12897599 ] Carsten Ziegeler commented on SLING-1560: - Changes in revision 984660 Remove unused Sling API reference from tests in jcr install Improve and clean up code - Key: SLING-1560 URL: https://issues.apache.org/jira/browse/SLING-1560 Project: Sling Issue Type: Improvement Components: Installer Affects Versions: OSGi Installer 3.0.0, JCR Installer 3.0.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: OSGi Installer 3.0.0, JCR Installer 3.0.0 In order to fix some outstanding bugs and to add new features, a code review and clean up seems to be a good idea :) This bug will keep track of all changes to the code that don't add new features -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-1643) Add start level support
[ https://issues.apache.org/jira/browse/SLING-1643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-1643. - Resolution: Fixed Added start level support through the dictionary in revision 984661 Add start level support --- Key: SLING-1643 URL: https://issues.apache.org/jira/browse/SLING-1643 Project: Sling Issue Type: Improvement Components: Installer Affects Versions: OSGi Installer 3.0.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: OSGi Installer 3.0.0 An installable resource for a bundle might also contain a dictionary with additional information like a start level. If such a valid start level is provided the bundle should be installed in that level -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-1644) Use configuration reader from Apache Felix ConfigAdmin
[ https://issues.apache.org/jira/browse/SLING-1644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-1644. - Resolution: Fixed Added support for the two dictionary file formats with various extensions in revision 984676 Use configuration reader from Apache Felix ConfigAdmin -- Key: SLING-1644 URL: https://issues.apache.org/jira/browse/SLING-1644 Project: Sling Issue Type: Improvement Components: Installer Affects Versions: OSGi Installer 3.0.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: OSGi Installer 3.0.0 The Apache Felix ConfigAdmin provides an easily integrateable reader for configuration files - we should directly use this in the installer to support configurations based on an input stream. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1560) Improve and clean up code
[ https://issues.apache.org/jira/browse/SLING-1560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12897668#action_12897668 ] Carsten Ziegeler commented on SLING-1560: - Changes in revision 984709 Further reduce the installer context - this will make it easier to make it public for pluggable tasks Removed most of the stuff from the installer itself - we can now merge the installer and the thread Improve and clean up code - Key: SLING-1560 URL: https://issues.apache.org/jira/browse/SLING-1560 Project: Sling Issue Type: Improvement Components: Installer Affects Versions: OSGi Installer 3.0.0, JCR Installer 3.0.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: OSGi Installer 3.0.0, JCR Installer 3.0.0 In order to fix some outstanding bugs and to add new features, a code review and clean up seems to be a good idea :) This bug will keep track of all changes to the code that don't add new features -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-983) Add sling.properties file to configuration status page
[ https://issues.apache.org/jira/browse/SLING-983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-983. Fix Version/s: Extensions Settings 0.1.0 (was: Engine 2.1.0) Resolution: Fixed Moved to the new settings module and removed from engine Add sling.properties file to configuration status page -- Key: SLING-983 URL: https://issues.apache.org/jira/browse/SLING-983 Project: Sling Issue Type: Improvement Components: Engine Affects Versions: Launchpad Base 2.1.0 Reporter: Felix Meschberger Assignee: Carsten Ziegeler Fix For: Extensions Settings 0.1.0, Launchpad Base 2.2.0 It would be good, if the sling.properties file could be provided through a Felix Web Console ConfigurationPrinter to include it into the Configuration Status output to ease support. Maybe this would be part of the Sling Engine bundle, which is the core engine of Sling. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-1651) Integrate RunMode module into new Settings Module
[ https://issues.apache.org/jira/browse/SLING-1651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-1651. - Resolution: Fixed Added run mode stuff to the settings service and added web configuration printer and shell command Integrate RunMode module into new Settings Module - Key: SLING-1651 URL: https://issues.apache.org/jira/browse/SLING-1651 Project: Sling Issue Type: Task Components: Engine Affects Versions: Extensions Settings 0.1.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Extensions Settings 0.1.0 To keep all settings related stuff in a single central place, we should merge the current run mode module into the settings module -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1560) Improve and clean up code
[ https://issues.apache.org/jira/browse/SLING-1560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12898197#action_12898197 ] Carsten Ziegeler commented on SLING-1560: - Merge installer impl and thread, make registered resources comparable Improve and clean up code - Key: SLING-1560 URL: https://issues.apache.org/jira/browse/SLING-1560 Project: Sling Issue Type: Improvement Components: Installer Affects Versions: OSGi Installer 3.0.0, JCR Installer 3.0.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: OSGi Installer 3.0.0, JCR Installer 3.0.0 In order to fix some outstanding bugs and to add new features, a code review and clean up seems to be a good idea :) This bug will keep track of all changes to the code that don't add new features -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-1513) allow host-specific rendering for virtual hosts. Multitenancy Support
[ https://issues.apache.org/jira/browse/SLING-1513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated SLING-1513: Component/s: API allow host-specific rendering for virtual hosts. Multitenancy Support --- Key: SLING-1513 URL: https://issues.apache.org/jira/browse/SLING-1513 Project: Sling Issue Type: New Feature Components: API Reporter: Markus Blaurock Currently we have the need to run multiple websites on the same sling-instance. That is, serving the same or similar content in different ways (layouts), defined by the hostname. Reason behind this is we would like to have a single pool of sling-app-servers and each one should be possible to serve all websites. Otherwise we would need to have one pool for each (small) site, which is not feasible. e.g. Content a/b/c should be accessible with http://www.one/a/b/c.html and http://www.two/a/b/c.html and looking differently. https://cwiki.apache.org/SLING/multitenancy-support.html would solve the problem easily. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-1648) Node move with :replace fails
[ https://issues.apache.org/jira/browse/SLING-1648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated SLING-1648: Affects Version/s: Servlets Post 2.0.4 Component/s: Servlets Node move with :replace fails - Key: SLING-1648 URL: https://issues.apache.org/jira/browse/SLING-1648 Project: Sling Issue Type: Bug Components: Servlets Affects Versions: Servlets Post 2.0.4 Reporter: daniel parry Following docs at http://sling.apache.org/site/manipulating-content-the-slingpostservlet-servletspost.html In trunk, Revision: 984520, steps to reproduce error: curl -uadmin:admin -Ftitle=test -Ftext=test http://localhost:8080/test1 curl -uadmin:admin -Ftitle=test -Ftext=test http://localhost:8080/test2 curl -uadmin:admin -F:operation=move -F:dest=/test2 http://localhost:8080/test1 (Not allowed to move without :replace as expected) curl -uadmin:admin -F:operation=move -F:replace=true -F:dest=/test2 http://localhost:8080/test1 (This should work with :replace specified) However, error encountered: html head titleError while processing /test1/title /head body h1Error while processing /test1/h1 table tbody tr tdStatus/td tddiv id=Status500/div/td /tr tr tdMessage/td tddiv id=Messagejavax.jcr.PathNotFoundException: /test2/div/td /tr tr tdLocation/td tda href=/test1 id=Location/test1/a/td /tr tr tdParent Location/td tda href=/ id=ParentLocation//a/td /tr tr tdPath/td tddiv id=Path/test1/div/td /tr tr tdReferer/td tda href= id=Referer/a/td /tr tr tdChangeLog/td tddiv id=ChangeLogpre/pre/div/td /tr /tbody /table pa href=Go Back/a/p pa href=/test1Modified Resource/a/p pa href=/Parent of Modified Resource/a/p /body /html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-1488) Move EventHelper from JCRInstall to Commons Testing
[ https://issues.apache.org/jira/browse/SLING-1488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-1488. - Resolution: Fixed Removed class from jcr install in revision 985245 Move EventHelper from JCRInstall to Commons Testing --- Key: SLING-1488 URL: https://issues.apache.org/jira/browse/SLING-1488 Project: Sling Issue Type: Improvement Components: Commons, Installer Reporter: Justin Edelson Assignee: Justin Edelson Priority: Minor Fix For: JCR Installer 3.0.0, Commons Testing 2.0.6 Original Estimate: 0h Remaining Estimate: 0h There's an EventHelper class in JCRInstall's test directory which is of general use. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-1295) JcrInstall should only observe configured folders
[ https://issues.apache.org/jira/browse/SLING-1295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-1295. - Resolution: Invalid This issue is invalid JcrInstall should only observe configured folders - Key: SLING-1295 URL: https://issues.apache.org/jira/browse/SLING-1295 Project: Sling Issue Type: Improvement Components: Installer Reporter: Carsten Ziegeler Currently jcr install listens for all modifications in the repository - however only changes to the configured locations are of interest, therefore jcr install should register more specific listeners for the various configured paths. This can be done by registering event listener proxy that all forward the events to a single listener -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-1419) Remove dependency to JCR
[ https://issues.apache.org/jira/browse/SLING-1419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-1419. - Resolution: Duplicate This is now a duplicate of SLING-1654 Remove dependency to JCR Key: SLING-1419 URL: https://issues.apache.org/jira/browse/SLING-1419 Project: Sling Issue Type: Improvement Components: Commons Affects Versions: Commons Auth 1.0.0 Reporter: Carsten Ziegeler Fix For: Commons Auth 1.0.0 The commons auth module as independent functionality wrt to JCR therefore we should make it work without JCR With SLING-1262 implemented, we can use the ResourceResolverFactory to login instead of going through the SlingRepository. In addition we should: - drop the setter and getter methods for credentials in the AuthenticationInfo - we keep the constant though - drop the setter and getter method for the workspace in the AuthenticationInfo - we keep the constant We make the import to the jcr packages optional as these are required for compatibility support of the old engine packages. If someone wants to use this support he'll need the jcr api anyway. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (SLING-1419) Remove dependency to JCR
[ https://issues.apache.org/jira/browse/SLING-1419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler reopened SLING-1419: - Duplicate is not quiet correct, therefore reopening Remove dependency to JCR Key: SLING-1419 URL: https://issues.apache.org/jira/browse/SLING-1419 Project: Sling Issue Type: Improvement Components: Commons Affects Versions: Commons Auth 1.0.0 Reporter: Carsten Ziegeler Fix For: Commons Auth 1.0.0 The commons auth module as independent functionality wrt to JCR therefore we should make it work without JCR With SLING-1262 implemented, we can use the ResourceResolverFactory to login instead of going through the SlingRepository. In addition we should: - drop the setter and getter methods for credentials in the AuthenticationInfo - we keep the constant though - drop the setter and getter method for the workspace in the AuthenticationInfo - we keep the constant We make the import to the jcr packages optional as these are required for compatibility support of the old engine packages. If someone wants to use this support he'll need the jcr api anyway. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-1657) Installer integration tests should not rely on internal counters/state
Installer integration tests should not rely on internal counters/state -- Key: SLING-1657 URL: https://issues.apache.org/jira/browse/SLING-1657 Project: Sling Issue Type: Improvement Components: Installer Affects Versions: OSGi Installer 3.0.0 Reporter: Carsten Ziegeler Fix For: OSGi Installer 3.0.0 Currently the installer integration tests rely on internal knowledge like the state of counters etc to detect of the tests are correct. Once the implementation changes, all these tests are bound to fail The tests should not rely on any internals and just check the actions and their result instead. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SLING-1661) compute the digest when a dictionary is read from the input stream
[ https://issues.apache.org/jira/browse/SLING-1661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler reassigned SLING-1661: --- Assignee: Carsten Ziegeler compute the digest when a dictionary is read from the input stream -- Key: SLING-1661 URL: https://issues.apache.org/jira/browse/SLING-1661 Project: Sling Issue Type: Improvement Components: Installer Reporter: Justin Edelson Assignee: Carsten Ziegeler Fix For: OSGi Installer 3.0.0 Attachments: SLING-1661.patch currently, if this call is made: new InstallableResource(id, is, null, null, InstallableResource.TYPE_CONFIG, null) an error will be thrown because the digest is null. But this isn't necessary because we can generate the digest from the parsed dictionary -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-1661) compute the digest when a dictionary is read from the input stream
[ https://issues.apache.org/jira/browse/SLING-1661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-1661. - Resolution: Fixed Applied a slightly modified patch by rearranging the instruction order in the constructor in revision 986237 compute the digest when a dictionary is read from the input stream -- Key: SLING-1661 URL: https://issues.apache.org/jira/browse/SLING-1661 Project: Sling Issue Type: Improvement Components: Installer Reporter: Justin Edelson Assignee: Carsten Ziegeler Fix For: OSGi Installer 3.0.0 Attachments: SLING-1661.patch currently, if this call is made: new InstallableResource(id, is, null, null, InstallableResource.TYPE_CONFIG, null) an error will be thrown because the digest is null. But this isn't necessary because we can generate the digest from the parsed dictionary -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-1657) Installer integration tests should not rely on internal counters/state
[ https://issues.apache.org/jira/browse/SLING-1657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-1657. - Resolution: Fixed Changed the tests to not rely on internals anymore in revision 986576 Installer integration tests should not rely on internal counters/state -- Key: SLING-1657 URL: https://issues.apache.org/jira/browse/SLING-1657 Project: Sling Issue Type: Improvement Components: Installer Affects Versions: OSGi Installer 3.0.0 Reporter: Carsten Ziegeler Fix For: OSGi Installer 3.0.0 Currently the installer integration tests rely on internal knowledge like the state of counters etc to detect of the tests are correct. Once the implementation changes, all these tests are bound to fail The tests should not rely on any internals and just check the actions and their result instead. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-1666) Check and update tests
Check and update tests -- Key: SLING-1666 URL: https://issues.apache.org/jira/browse/SLING-1666 Project: Sling Issue Type: Task Components: Installer Affects Versions: OSGi Installer 3.0.0 Reporter: Carsten Ziegeler Fix For: OSGi Installer 3.0.0 We should update/enhance/check the current tests if they check everything, especially with the changes to the it tests we might have lost some testing -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1560) Improve and clean up code
[ https://issues.apache.org/jira/browse/SLING-1560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12899762#action_12899762 ] Carsten Ziegeler commented on SLING-1560: - Removed the statistics interface and the counters in revision 986583 Improve and clean up code - Key: SLING-1560 URL: https://issues.apache.org/jira/browse/SLING-1560 Project: Sling Issue Type: Improvement Components: Installer Affects Versions: OSGi Installer 3.0.0, JCR Installer 3.0.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: OSGi Installer 3.0.0, JCR Installer 3.0.0 In order to fix some outstanding bugs and to add new features, a code review and clean up seems to be a good idea :) This bug will keep track of all changes to the code that don't add new features -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1560) Improve and clean up code
[ https://issues.apache.org/jira/browse/SLING-1560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12899825#action_12899825 ] Carsten Ziegeler commented on SLING-1560: - Simplified the osgi installer task interface and the task generation in revision 986645 Improve and clean up code - Key: SLING-1560 URL: https://issues.apache.org/jira/browse/SLING-1560 Project: Sling Issue Type: Improvement Components: Installer Affects Versions: OSGi Installer 3.0.0, JCR Installer 3.0.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: OSGi Installer 3.0.0, JCR Installer 3.0.0 In order to fix some outstanding bugs and to add new features, a code review and clean up seems to be a good idea :) This bug will keep track of all changes to the code that don't add new features -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1680) FsResourceProvider takes VERY long to register/unregister AND finally throws an OutOfMemoryError
[ https://issues.apache.org/jira/browse/SLING-1680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12901411#action_12901411 ] Carsten Ziegeler commented on SLING-1680: - I haven't tested this yet on win xp - now the monitoring creates an entry status object for each file and directory in the configured tree. It traverses the whole directory tree - so if your c:/tmp dir is large, this may not be optimal. For the startup time we can definitly delay the scanning or do this in the background - but I don't have a good idea for the memory problem; except turning of the notification of file changes :( FsResourceProvider takes VERY long to register/unregister AND finally throws an OutOfMemoryError Key: SLING-1680 URL: https://issues.apache.org/jira/browse/SLING-1680 Project: Sling Issue Type: Bug Components: JCR Environment: WinXP, latest-greatest Sling (from trunk) Reporter: Clemens Wyss Given the Sling Web Console When I configure an instance of the filesystem resource provider in terms of provider root and filesystem location, e.g.: Provider root: /tmp Filesystem Root: c:/tmp it takes very long to handle the request an finally ends in an OutOfMemoryError: 23.08.2010 15:56:08.446 *ERROR* [FelixStartLevel] org.apache.sling.fsresource [org.apache.sling.fsprovider.internal.FsResourceProvider] The activate method has thrown an exception (java.lang.OutOfMemoryError: Java heap space) java.lang.OutOfMemoryError: Java heap space at java.util.Arrays.copyOf(Arrays.java:2882) at java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:100) at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:572) at java.lang.StringBuilder.append(StringBuilder.java:203) at org.apache.sling.fsprovider.internal.FileMonitor$DirStatus.init(FileMonitor.java:253) at org.apache.sling.fsprovider.internal.FileMonitor.createStatus(FileMonitor.java:219) at org.apache.sling.fsprovider.internal.FileMonitor.access$000(FileMonitor.java:36) at org.apache.sling.fsprovider.internal.FileMonitor$DirStatus.init(FileMonitor.java:255) at org.apache.sling.fsprovider.internal.FileMonitor.createStatus(FileMonitor.java:219) at org.apache.sling.fsprovider.internal.FileMonitor.access$000(FileMonitor.java:36) at org.apache.sling.fsprovider.internal.FileMonitor$DirStatus.init(FileMonitor.java:255) at org.apache.sling.fsprovider.internal.FileMonitor.createStatus(FileMonitor.java:219) at org.apache.sling.fsprovider.internal.FileMonitor.access$000(FileMonitor.java:36) at org.apache.sling.fsprovider.internal.FileMonitor$DirStatus.init(FileMonitor.java:255) at org.apache.sling.fsprovider.internal.FileMonitor.createStatus(FileMonitor.java:219) at org.apache.sling.fsprovider.internal.FileMonitor.access$000(FileMonitor.java:36) at org.apache.sling.fsprovider.internal.FileMonitor$DirStatus.init(FileMonitor.java:255) at org.apache.sling.fsprovider.internal.FileMonitor.createStatus(FileMonitor.java:219) at org.apache.sling.fsprovider.internal.FileMonitor.access$000(FileMonitor.java:36) at org.apache.sling.fsprovider.internal.FileMonitor$DirStatus.init(FileMonitor.java:255) at org.apache.sling.fsprovider.internal.FileMonitor.createStatus(FileMonitor.java:219) at org.apache.sling.fsprovider.internal.FileMonitor.access$000(FileMonitor.java:36) at org.apache.sling.fsprovider.internal.FileMonitor$DirStatus.init(FileMonitor.java:255) at org.apache.sling.fsprovider.internal.FileMonitor.createStatus(FileMonitor.java:219) at org.apache.sling.fsprovider.internal.FileMonitor.access$000(FileMonitor.java:36) at org.apache.sling.fsprovider.internal.FileMonitor$DirStatus.init(FileMonitor.java:255) at org.apache.sling.fsprovider.internal.FileMonitor.createStatus(FileMonitor.java:219) at org.apache.sling.fsprovider.internal.FileMonitor.access$000(FileMonitor.java:36) at org.apache.sling.fsprovider.internal.FileMonitor$DirStatus.init(FileMonitor.java:255) at org.apache.sling.fsprovider.internal.FileMonitor.createStatus(FileMonitor.java:219) at org.apache.sling.fsprovider.internal.FileMonitor.access$000(FileMonitor.java:36) at org.apache.sling.fsprovider.internal.FileMonitor$DirStatus.init(FileMonitor.java:255) 23.08.2010 15:56:08.446 *ERROR* [FelixStartLevel] org.apache.sling.fsresource [org.apache.sling.fsprovider.internal.FsResourceProvider] Failed creating the component instance; see log for reason 23.08.2010
[jira] Commented: (SLING-1680) FsResourceProvider takes VERY long to register/unregister AND finally throws an OutOfMemoryError
[ https://issues.apache.org/jira/browse/SLING-1680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12901420#action_12901420 ] Carsten Ziegeler commented on SLING-1680: - Hmm, yes, this is realy large :) Now, to be honest, I don't know if we should consider this a real world use case; I usually use the fs provider just for development, everything else (well nearly everything else) is in the repository later on. But I don't see a reason why we shoudln't support large file directories FsResourceProvider takes VERY long to register/unregister AND finally throws an OutOfMemoryError Key: SLING-1680 URL: https://issues.apache.org/jira/browse/SLING-1680 Project: Sling Issue Type: Bug Components: JCR Environment: WinXP, latest-greatest Sling (from trunk) Reporter: Clemens Wyss Given the Sling Web Console When I configure an instance of the filesystem resource provider in terms of provider root and filesystem location, e.g.: Provider root: /tmp Filesystem Root: c:/tmp it takes very long to handle the request an finally ends in an OutOfMemoryError: 23.08.2010 15:56:08.446 *ERROR* [FelixStartLevel] org.apache.sling.fsresource [org.apache.sling.fsprovider.internal.FsResourceProvider] The activate method has thrown an exception (java.lang.OutOfMemoryError: Java heap space) java.lang.OutOfMemoryError: Java heap space at java.util.Arrays.copyOf(Arrays.java:2882) at java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:100) at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:572) at java.lang.StringBuilder.append(StringBuilder.java:203) at org.apache.sling.fsprovider.internal.FileMonitor$DirStatus.init(FileMonitor.java:253) at org.apache.sling.fsprovider.internal.FileMonitor.createStatus(FileMonitor.java:219) at org.apache.sling.fsprovider.internal.FileMonitor.access$000(FileMonitor.java:36) at org.apache.sling.fsprovider.internal.FileMonitor$DirStatus.init(FileMonitor.java:255) at org.apache.sling.fsprovider.internal.FileMonitor.createStatus(FileMonitor.java:219) at org.apache.sling.fsprovider.internal.FileMonitor.access$000(FileMonitor.java:36) at org.apache.sling.fsprovider.internal.FileMonitor$DirStatus.init(FileMonitor.java:255) at org.apache.sling.fsprovider.internal.FileMonitor.createStatus(FileMonitor.java:219) at org.apache.sling.fsprovider.internal.FileMonitor.access$000(FileMonitor.java:36) at org.apache.sling.fsprovider.internal.FileMonitor$DirStatus.init(FileMonitor.java:255) at org.apache.sling.fsprovider.internal.FileMonitor.createStatus(FileMonitor.java:219) at org.apache.sling.fsprovider.internal.FileMonitor.access$000(FileMonitor.java:36) at org.apache.sling.fsprovider.internal.FileMonitor$DirStatus.init(FileMonitor.java:255) at org.apache.sling.fsprovider.internal.FileMonitor.createStatus(FileMonitor.java:219) at org.apache.sling.fsprovider.internal.FileMonitor.access$000(FileMonitor.java:36) at org.apache.sling.fsprovider.internal.FileMonitor$DirStatus.init(FileMonitor.java:255) at org.apache.sling.fsprovider.internal.FileMonitor.createStatus(FileMonitor.java:219) at org.apache.sling.fsprovider.internal.FileMonitor.access$000(FileMonitor.java:36) at org.apache.sling.fsprovider.internal.FileMonitor$DirStatus.init(FileMonitor.java:255) at org.apache.sling.fsprovider.internal.FileMonitor.createStatus(FileMonitor.java:219) at org.apache.sling.fsprovider.internal.FileMonitor.access$000(FileMonitor.java:36) at org.apache.sling.fsprovider.internal.FileMonitor$DirStatus.init(FileMonitor.java:255) at org.apache.sling.fsprovider.internal.FileMonitor.createStatus(FileMonitor.java:219) at org.apache.sling.fsprovider.internal.FileMonitor.access$000(FileMonitor.java:36) at org.apache.sling.fsprovider.internal.FileMonitor$DirStatus.init(FileMonitor.java:255) at org.apache.sling.fsprovider.internal.FileMonitor.createStatus(FileMonitor.java:219) at org.apache.sling.fsprovider.internal.FileMonitor.access$000(FileMonitor.java:36) at org.apache.sling.fsprovider.internal.FileMonitor$DirStatus.init(FileMonitor.java:255) 23.08.2010 15:56:08.446 *ERROR* [FelixStartLevel] org.apache.sling.fsresource [org.apache.sling.fsprovider.internal.FsResourceProvider] Failed creating the component instance; see log for reason 23.08.2010 15:56:08.446 *ERROR* [FelixDispatchQueue] org.apache.sling.fsresource FrameworkEvent ERROR
[jira] Resolved: (SLING-1560) Improve and clean up code
[ https://issues.apache.org/jira/browse/SLING-1560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-1560. - Resolution: Fixed The InstallableResource is now a simple data object - all the logic like format detection etc is done inside the implementation This should give us room to make the installer pluggable without changing the api later on Done in revision 988214 I'm closing this bug for now as we've done a lot of changes Improve and clean up code - Key: SLING-1560 URL: https://issues.apache.org/jira/browse/SLING-1560 Project: Sling Issue Type: Improvement Components: Installer Affects Versions: OSGi Installer 3.0.0, JCR Installer 3.0.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: OSGi Installer 3.0.0, JCR Installer 3.0.0 In order to fix some outstanding bugs and to add new features, a code review and clean up seems to be a good idea :) This bug will keep track of all changes to the code that don't add new features -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-1685) Method to force remove a job
Method to force remove a job Key: SLING-1685 URL: https://issues.apache.org/jira/browse/SLING-1685 Project: Sling Issue Type: New Feature Components: Extensions Affects Versions: Extensions Event 2.3.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Extensions Event 2.4.0 Currently it is only possible to try to remove an event - this might fail if the job is in processing; while this is fine, this usually creates a problem for the client as it really wants to stop the job. It is easy to implement the retry in the job handling than in the client code. Therefore we should add a forceRemoveJob method which waits until the job is removed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-1687) JobStatusProvider should lazy load events when returning
JobStatusProvider should lazy load events when returning Key: SLING-1687 URL: https://issues.apache.org/jira/browse/SLING-1687 Project: Sling Issue Type: New Feature Components: Extensions Affects Versions: Extensions Event 2.3.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Extensions Event 2.4.0 The current implementation of the job status provider does a query, then loads all jobs and returns a list. If you just want to know how many jobs are available or just want to return the first X jobs, the implementation is too expansive. One solution would be to return a kind of range iterator instead of a list and load jobs on demand. There are two potential problems: - if the jcr query does not return a count, we can't return a count either without going through the hole result set - it might be that a job can't be loaded because of missing classes; in this cases the job count from the query result is higher than the count of the jobs that get processed. I think we can neglect this -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-1689) Change the OSGi installer interface
Change the OSGi installer interface --- Key: SLING-1689 URL: https://issues.apache.org/jira/browse/SLING-1689 Project: Sling Issue Type: Improvement Components: Installer Affects Versions: OSGi Installer 3.0.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: OSGi Installer 3.0.0 As discussed in the mailing list: the current OSGi installer has three methods: - registerResources : which is used to register all resources from the installer client like jcr install; this is usually invoked on startup - addResource : adds a resource during runtime - removeResource : removes a resource during runtime The api is simple, fine and sufficient. However there is a small glitch here. If a client detects several changes at once, like a set of bundles is removed or updated, it has to call addResource or removeResource for each change separately. The OSGi installer could run a install cycle inbetween those method calls. Causing a part of this process to be done in the first cycle and the other part in the second cycle - now as OSGi has a dynamic nature this isn't a problem after two cycles everything is installed as expected. But still I have the feeling that it would be nicer, if the client could submit several changes add once, so maybe instead of having a addResource and removeResource method, just a updateResources([] addedResources, [] removedResources). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-1690) Reduce startup time of jcr install
Reduce startup time of jcr install -- Key: SLING-1690 URL: https://issues.apache.org/jira/browse/SLING-1690 Project: Sling Issue Type: Improvement Components: Installer Affects Versions: JCR Installer 3.0.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: JCR Installer 3.0.0 The jcr installer scans the repository during the activate method; this slows down the general startup time of the whole system. The scanning should be done delayed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-1489) Upgrade JCR Install to JCR 2
[ https://issues.apache.org/jira/browse/SLING-1489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-1489. - Resolution: Won't Fix As discussed in the mailing list, we don't upgrade to JCR 2 and rely on JCR 1 Upgrade JCR Install to JCR 2 Key: SLING-1489 URL: https://issues.apache.org/jira/browse/SLING-1489 Project: Sling Issue Type: Improvement Components: Installer Reporter: Justin Edelson Assignee: Justin Edelson Fix For: JCR Installer 3.0.0 JCR 2 added a NODE_MOVED event. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SLING-1663) OSGi Install should recognize system bundle updates
[ https://issues.apache.org/jira/browse/SLING-1663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler reassigned SLING-1663: --- Assignee: Carsten Ziegeler OSGi Install should recognize system bundle updates --- Key: SLING-1663 URL: https://issues.apache.org/jira/browse/SLING-1663 Project: Sling Issue Type: Bug Components: Installer Reporter: Felix Meschberger Assignee: Carsten Ziegeler Fix For: OSGi Installer 3.0.0 The Launchpad Base module generates a bundle with the symbolic name system.bundle which is an official alias for the symbolic name of the system bundle whose real symbolic name is framework specific. The Web Console supports updates with the system.bundle symbolic name and updates the system bundle accordingly. The OSGi Installer should also recognize this situation and act accordingly: * The system bundle does not need to be stopped/started for the update, a framework restart is done automatically * A package refresh is not required * System bundle update acts immediately preventing OSGi Install from properly cleaning up after the install Thus updating the system bundle should probably be done in a special way: * at the of a processing cycle of OSGi Install * preventing any more processing before calling bundle update * probably updating the system bundle in a separate thread to not prevent proper shutdown of OSGi Install -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1690) Reduce startup time of jcr install
[ https://issues.apache.org/jira/browse/SLING-1690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12901855#action_12901855 ] Carsten Ziegeler commented on SLING-1690: - Changed the startup: most of the stuff is now done in the background thread (revision 988516) Reduce startup time of jcr install -- Key: SLING-1690 URL: https://issues.apache.org/jira/browse/SLING-1690 Project: Sling Issue Type: Improvement Components: Installer Affects Versions: JCR Installer 3.0.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: JCR Installer 3.0.0 The jcr installer scans the repository during the activate method; this slows down the general startup time of the whole system. The scanning should be done delayed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1663) OSGi Install should recognize system bundle updates
[ https://issues.apache.org/jira/browse/SLING-1663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12901854#action_12901854 ] Carsten Ziegeler commented on SLING-1663: - Added a first implementation in revision 988515 - not tested yet OSGi Install should recognize system bundle updates --- Key: SLING-1663 URL: https://issues.apache.org/jira/browse/SLING-1663 Project: Sling Issue Type: Bug Components: Installer Reporter: Felix Meschberger Assignee: Carsten Ziegeler Fix For: OSGi Installer 3.0.0 The Launchpad Base module generates a bundle with the symbolic name system.bundle which is an official alias for the symbolic name of the system bundle whose real symbolic name is framework specific. The Web Console supports updates with the system.bundle symbolic name and updates the system bundle accordingly. The OSGi Installer should also recognize this situation and act accordingly: * The system bundle does not need to be stopped/started for the update, a framework restart is done automatically * A package refresh is not required * System bundle update acts immediately preventing OSGi Install from properly cleaning up after the install Thus updating the system bundle should probably be done in a special way: * at the of a processing cycle of OSGi Install * preventing any more processing before calling bundle update * probably updating the system bundle in a separate thread to not prevent proper shutdown of OSGi Install -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-1335) Timing issues in OSGi installer integration tests
[ https://issues.apache.org/jira/browse/SLING-1335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-1335. - Resolution: Fixed I finally fixed the other failing test; everything should run now Timing issues in OSGi installer integration tests - Key: SLING-1335 URL: https://issues.apache.org/jira/browse/SLING-1335 Project: Sling Issue Type: Bug Components: Installer Reporter: Bertrand Delacretaz Priority: Minor Seems like some tests in the installer/osgi/it have timing issues which make them fail semi-randomly. More often on Hudson that on my macbook, for example. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-755) jcrinstall console plugin
[ https://issues.apache.org/jira/browse/SLING-755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated SLING-755: --- Fix Version/s: (was: JCR Install 2.0.4) Unscheduling this from JCR 2.0.4 as we are working on JCR 3.0.0 now jcrinstall console plugin - Key: SLING-755 URL: https://issues.apache.org/jira/browse/SLING-755 Project: Sling Issue Type: Improvement Components: Installer Reporter: Bertrand Delacretaz Priority: Minor (changed title as discussion moved to creating a console plugin) Making a servlet out of the jcrinstall RepositoryObserver class introduces dependencies on the sling api and servlet bundles, which are not desired for jcrinstall - its dependencies should be kept to a minimum. I'll move the servlet to its own bundle - it is currently only needed for integration testing, but might be useful for other monitoring purposes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-1690) Reduce startup time of jcr install
[ https://issues.apache.org/jira/browse/SLING-1690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-1690. - Resolution: Fixed Works Reduce startup time of jcr install -- Key: SLING-1690 URL: https://issues.apache.org/jira/browse/SLING-1690 Project: Sling Issue Type: Improvement Components: Installer Affects Versions: JCR Installer 3.0.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: JCR Installer 3.0.0 The jcr installer scans the repository during the activate method; this slows down the general startup time of the whole system. The scanning should be done delayed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-1691) Improve startup behaviour
Improve startup behaviour - Key: SLING-1691 URL: https://issues.apache.org/jira/browse/SLING-1691 Project: Sling Issue Type: Improvement Components: Scripting Affects Versions: Scripting JSP-Atom-Taglib 1.0.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Scripting JSP-Atom-Taglib 1.0.0 The current implementation costs some startup performance as a service tracker is registered which loads all Abdera stuff as soon as the servlet context is available. We could delay this to it's first usage -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-1691) Improve startup behaviour
[ https://issues.apache.org/jira/browse/SLING-1691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-1691. - Resolution: Fixed Abdera is now started on first usage and not put into the servlet context anymore. Changed in revision 988540 Improve startup behaviour - Key: SLING-1691 URL: https://issues.apache.org/jira/browse/SLING-1691 Project: Sling Issue Type: Improvement Components: Scripting Affects Versions: Scripting JSP-Atom-Taglib 1.0.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Scripting JSP-Atom-Taglib 1.0.0 The current implementation costs some startup performance as a service tracker is registered which loads all Abdera stuff as soon as the servlet context is available. We could delay this to it's first usage -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1560) Improve and clean up code
[ https://issues.apache.org/jira/browse/SLING-1560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12901921#action_12901921 ] Carsten Ziegeler commented on SLING-1560: - I've done another minor update: move most of the activation stuff into the run method and removed a local instance variable for clarification in revision 988593 Improve and clean up code - Key: SLING-1560 URL: https://issues.apache.org/jira/browse/SLING-1560 Project: Sling Issue Type: Improvement Components: Installer Affects Versions: OSGi Installer 3.0.0, JCR Installer 3.0.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: OSGi Installer 3.0.0, JCR Installer 3.0.0 In order to fix some outstanding bugs and to add new features, a code review and clean up seems to be a good idea :) This bug will keep track of all changes to the code that don't add new features -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-1694) Instantiate adapter factories lazy
Instantiate adapter factories lazy -- Key: SLING-1694 URL: https://issues.apache.org/jira/browse/SLING-1694 Project: Sling Issue Type: Improvement Components: Extensions Affects Versions: Adapter 2.0.4 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Adapter 2.0.6 The adapter factories can be instantiated lazy to reduce service instantiation on startup and improve overall startup performance -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-1694) Instantiate adapter factories lazy
[ https://issues.apache.org/jira/browse/SLING-1694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-1694. - Resolution: Fixed Changed in revision 989023 Instantiate adapter factories lazy -- Key: SLING-1694 URL: https://issues.apache.org/jira/browse/SLING-1694 Project: Sling Issue Type: Improvement Components: Extensions Affects Versions: Adapter 2.0.4 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Adapter 2.0.6 The adapter factories can be instantiated lazy to reduce service instantiation on startup and improve overall startup performance -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-1699) New default configuration is created on each startup
New default configuration is created on each startup Key: SLING-1699 URL: https://issues.apache.org/jira/browse/SLING-1699 Project: Sling Issue Type: Bug Components: Commons Affects Versions: Commons Threads 3.0.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Commons Threads 3.0.2 On each startup a new default configuration is added -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-1699) New default configuration is created on each startup
[ https://issues.apache.org/jira/browse/SLING-1699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-1699. - Resolution: Fixed Factory configurations are now not created by the manager anymore - if a pool should be administrated through the config admin, a factory config should be created there. Added a web console printer to print out the current pools Fixed some problems in the metatype descriptor Revision 990068 New default configuration is created on each startup Key: SLING-1699 URL: https://issues.apache.org/jira/browse/SLING-1699 Project: Sling Issue Type: Bug Components: Commons Affects Versions: Commons Threads 3.0.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Commons Threads 3.0.2 On each startup a new default configuration is added -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (SLING-1637) Support DynamicClassLoader interface
[ https://issues.apache.org/jira/browse/SLING-1637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-1637. --- Support DynamicClassLoader interface Key: SLING-1637 URL: https://issues.apache.org/jira/browse/SLING-1637 Project: Sling Issue Type: New Feature Components: JCR Affects Versions: JCR Classloader 3.1.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: JCR Classloader 3.1.2 The jcr class loader should support the new DynamicClassLoader interface from commons classloader to allow clients to detect if the used classloader is invalid -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (SLING-1434) Inherit from SecureClassLoader (and not URLClassLoader)
[ https://issues.apache.org/jira/browse/SLING-1434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-1434. --- Inherit from SecureClassLoader (and not URLClassLoader) --- Key: SLING-1434 URL: https://issues.apache.org/jira/browse/SLING-1434 Project: Sling Issue Type: Improvement Components: JCR Affects Versions: JCR Classloader 3.1.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: JCR Classloader 3.1.2 The current classloaders inherit from url classloader - this is not required and we can reduce the code a little bit my directly inheriting from the SecureClassloader -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (SLING-1480) Don't use Workspace#move, use Session#move
[ https://issues.apache.org/jira/browse/SLING-1480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-1480. --- Don't use Workspace#move, use Session#move -- Key: SLING-1480 URL: https://issues.apache.org/jira/browse/SLING-1480 Project: Sling Issue Type: Improvement Components: JCR Affects Versions: JCR Classloader 3.1.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Priority: Minor Fix For: JCR Classloader 3.1.2 The class loader write should use Session#move instead of Workspace#move - this seems to reduce potential concurrency problems -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-1685) Method to force remove a job
[ https://issues.apache.org/jira/browse/SLING-1685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-1685. - Resolution: Fixed Implemented in revision 991105 - the force remove method simply polls until the job is removed. Added a test case. Method to force remove a job Key: SLING-1685 URL: https://issues.apache.org/jira/browse/SLING-1685 Project: Sling Issue Type: New Feature Components: Extensions Affects Versions: Extensions Event 2.3.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Extensions Event 2.4.0 Currently it is only possible to try to remove an event - this might fail if the job is in processing; while this is fine, this usually creates a problem for the client as it really wants to stop the job. It is easy to implement the retry in the job handling than in the client code. Therefore we should add a forceRemoveJob method which waits until the job is removed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-1687) JobStatusProvider should lazy load events when returning
[ https://issues.apache.org/jira/browse/SLING-1687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-1687. - Resolution: Fixed Added a new methods which in revision which return a JobsIterator - if the query returns a size this will be available through the iterator. Skipping jobs is possible as well. Even if a required classloader is not available, the job will be returned - just without the props that can't be loaded! If only the size of the iterator is queried or the iterator is only used partially, the close method must be called to free the session. JobStatusProvider should lazy load events when returning Key: SLING-1687 URL: https://issues.apache.org/jira/browse/SLING-1687 Project: Sling Issue Type: New Feature Components: Extensions Affects Versions: Extensions Event 2.3.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Extensions Event 2.4.0 The current implementation of the job status provider does a query, then loads all jobs and returns a list. If you just want to know how many jobs are available or just want to return the first X jobs, the implementation is too expansive. One solution would be to return a kind of range iterator instead of a list and load jobs on demand. There are two potential problems: - if the jcr query does not return a count, we can't return a count either without going through the hole result set - it might be that a job can't be loaded because of missing classes; in this cases the job count from the query result is higher than the count of the jobs that get processed. I think we can neglect this -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SLING-1710) JobEventHandler: jobs in a waiting state won't be waked up anymore if job.getProperty(EventUtil.PROPERTY_JOB_QUEUE_NAME) != null
[
https://issues.apache.org/jira/browse/SLING-1710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler reassigned SLING-1710:
---
Assignee: Carsten Ziegeler
JobEventHandler: jobs in a waiting state won't be waked up anymore if
job.getProperty(EventUtil.PROPERTY_JOB_QUEUE_NAME) != null
Key: SLING-1710
URL: https://issues.apache.org/jira/browse/SLING-1710
Project: Sling
Issue Type: Bug
Components: Extensions
Affects Versions: Extensions Event 2.3.0
Reporter: Philipp Koch
Assignee: Carsten Ziegeler
Priority: Critical
it may happen that a job (before execution) is put in a waiting state because
the maximum parallel job count was reached.
unfortunately, that waiting job won't be notified anymore in case the job is
bound to a defined job queue:
1377 if ( job.getProperty(EventUtil.PROPERTY_JOB_QUEUE_NAME) == null ) {
1378 this.parallelJobCount--;
1379 this.backgroundLock.notify();
1380 }
couldn't one simply remove the
job.getProperty(EventUtil.PROPERTY_JOB_QUEUE_NAME) == null check or is
there a reason why this check got added?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-1710) JobEventHandler: jobs in a waiting state won't be waked up anymore if job.getProperty(EventUtil.PROPERTY_JOB_QUEUE_NAME) != null
[
https://issues.apache.org/jira/browse/SLING-1710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler resolved SLING-1710.
-
Fix Version/s: Extensions Event 2.4.0
Resolution: Fixed
Fixed in revision 991169
If a job for a job queue was put into the main queue instead we have to remove
the queue name property for correct processing
JobEventHandler: jobs in a waiting state won't be waked up anymore if
job.getProperty(EventUtil.PROPERTY_JOB_QUEUE_NAME) != null
Key: SLING-1710
URL: https://issues.apache.org/jira/browse/SLING-1710
Project: Sling
Issue Type: Bug
Components: Extensions
Affects Versions: Extensions Event 2.3.0
Reporter: Philipp Koch
Assignee: Carsten Ziegeler
Priority: Critical
Fix For: Extensions Event 2.4.0
it may happen that a job (before execution) is put in a waiting state because
the maximum parallel job count was reached.
unfortunately, that waiting job won't be notified anymore in case the job is
bound to a defined job queue:
1377 if ( job.getProperty(EventUtil.PROPERTY_JOB_QUEUE_NAME) == null ) {
1378 this.parallelJobCount--;
1379 this.backgroundLock.notify();
1380 }
couldn't one simply remove the
job.getProperty(EventUtil.PROPERTY_JOB_QUEUE_NAME) == null check or is
there a reason why this check got added?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-1536) Job Queue might be stopped during job processing
[ https://issues.apache.org/jira/browse/SLING-1536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-1536. - Resolution: Fixed Added an extra check in revision 991215 Job Queue might be stopped during job processing Key: SLING-1536 URL: https://issues.apache.org/jira/browse/SLING-1536 Project: Sling Issue Type: Bug Components: Extensions Affects Versions: Extensions Event 2.3.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Extensions Event 2.4.0 If a long running job is started from a job queue, the job queue might be shutdown in the meantime (if no other jobs are arriving for this queue). This leads to an NPE when finishedJob is called. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-1475) Create a web console plugin
[ https://issues.apache.org/jira/browse/SLING-1475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated SLING-1475: Fix Version/s: Extensions Event 2.4.2 (was: Extensions Event 2.4.0) Create a web console plugin --- Key: SLING-1475 URL: https://issues.apache.org/jira/browse/SLING-1475 Project: Sling Issue Type: Improvement Components: Extensions Affects Versions: Extensions Event 2.3.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Extensions Event 2.4.2 It would be nice to have a web console plugin for the configuration status which displays all available information, like available job queues, number of jobs in processing etc. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-1432) Unable to Forward to Images via a Filter
[ https://issues.apache.org/jira/browse/SLING-1432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-1432. - Resolution: Not A Problem Your filter is a component filter and therefore comes too late in the game. A component filter is called whenever a component = script is invoked for rendering. This happens after the resource is resolved. Unfortunately making this filter a sling request filter (filter.scope=request), doesn't solve your problem either as event sling request filters are called after the resource is resolved. It works in the POST case as a POST is intended to create new resources. Depending on the OSGi http service implementation you might be able to register a real servlet filter for the whole sling web application. This filter would run before Sling and solve your problem. Another solution I see (which I would rather consider a workaround) would be to post/get to a path like /resources/XYZ while you store content in the repository at /data/X/Y/Z. In this case you can register your own servlet through the http service at /resources and simple forward from there to /data/ which is handled by Sling. Unable to Forward to Images via a Filter Key: SLING-1432 URL: https://issues.apache.org/jira/browse/SLING-1432 Project: Sling Issue Type: Bug Components: Extensions, Servlets Reporter: Jason Rose Attachments: uuid_filter_problem.log, UuidFilter.java In my current application, I store nodes with the name of the node being a uuid generated by a sproutcore client. Because this doesn't directly lend itself to a deep node hierarchy, I have a filter in place that buckets these uuids into two more levels based on the first four characters in the uuid. I'd like this process to be transparent to the front end, so I use the filter. The filter itself is very simple. It checks the request.getPathInfo() for any uuids, buckets them according to a built-in strategy, then uses the request dispatcher to forward to the new path. i.e: posting to /test/foo/abba---- ends up creating a node at /test/foo/ab/ba/abba----. Accessing '/test/foo/abba----.xml' filters it to '/test/foo/ab/ba/abba----.xml' and it works correctly. This sort of approach seems to solve all the performance problems in jackrabbit and works in the general case, like when there isn't an obvious way to naturally get a deep hierarchy. Something breaks, though, when I try to bucket images. The node is posted correctly, but when I try to get it via the filter in the url, I get a 404. If I put an image with the same name under the unbucketed path using something like DAV, requesting an unbucketed resource that gets resolved by my filter will return the image I uploaded manually. i.e: posting to /test/foo/abba----/img.jpg ends up creating a node at /test/foo/ab/ba/abba----/img.jpg. Accessing '/test/foo/abba----/img.jpg' leads to a 404. Accessing '/test/foo/ab/ba/abba----/img.jpg' returns the correct resource. Putting a new image also called img.jpg under /test/foo/abba---- with a dav, then hitting the first path in the browser will the image stored at the bucketed path. It seems to me that the prep work done by sling before executing the filters leads to a dirty state that disallows me from forwarding to a new path in my filter. Is there a way to clean up the request's state? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1213) Filters to support servlet-API-level scope configuration
[ https://issues.apache.org/jira/browse/SLING-1213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12904948#action_12904948 ] Carsten Ziegeler commented on SLING-1213: - Can you point to the changes regarding the filter handling? The patch is rather long :) Just noticed a typo in ServletFilterManager: the enum for request is just Reques Filters to support servlet-API-level scope configuration Key: SLING-1213 URL: https://issues.apache.org/jira/browse/SLING-1213 Project: Sling Issue Type: Improvement Components: Engine Reporter: Mike Pfaff Currently the filter.scope supports either - component (comparable to dispatcherINCLUDE,FORWARD,ERROR/dispatcher of the servlet API) or - request (comparable to dispatcherREQUEST/dispatcher of the servlet API) In certain cases one wants to have finer control over the filter scopes, e.g. have a filter that would do dispatcherREQUEST,FORWARD/dispatcher, so that the filter is applied first for the request and then again when you do a requestDispatcher.forward(). Therefore i suggest that the filter.scope should be enhanced as follows: - Make filter.scope a multi-value property - Add filter scopes: include, forward and error - The existing filter scope component(quasi an alias for include,forward,error) should for backward-compatibility not change. - Add filter chains for the new filter scopes (don't know if this is needed internally?) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-1711) Move SlingAdaptable from adapter bundle to api
Move SlingAdaptable from adapter bundle to api -- Key: SLING-1711 URL: https://issues.apache.org/jira/browse/SLING-1711 Project: Sling Issue Type: New Feature Components: API, Extensions Affects Versions: Adapter 2.0.6, API 2.1.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: API 2.1.2, Adapter 2.0.8 The SlingAdaptable - which is the default implementation for Adaptable - is current in the adapter bundle. The implementation contains some caching. As the API should not depend on other Sling bundles, AbstractResource can't extend this implementation. In addition if one wants to use the SlingAdaptable together with the Sling API it needs several bundles. We can clean this up, by : - adding SlingAdaptable to the API - deprecate SlingAdaptable in the adapter bundle and let it extend the API version - make AbstractResource extend the new SlingAdaptable - move the AdapterManager code from AbstractResource to the new SlingAdaptable -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-1720) Classloader cache is not synced
Classloader cache is not synced --- Key: SLING-1720 URL: https://issues.apache.org/jira/browse/SLING-1720 Project: Sling Issue Type: Bug Affects Versions: JCR Classloader 3.1.2 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: JCR Classloader 3.1.4 The classloader cache is not synced which can cause java.util.ConcurrentModificationExceptions: at java.util.HashMap$HashIterator.nextEntry(HashMap.java:793) at java.util.HashMap$ValueIterator.next(HashMap.java:822) at org.apache.sling.jcr.classloader.internal.DynamicRepositoryClassLoader.cleanCache(DynamicRepositoryClassLoader.java:394) at org.apache.sling.jcr.classloader.internal.DynamicRepositoryClassLoader.onEvent(DynamicRepositoryClassLoader.java:681) at org.apache.sling.jcr.classloader.internal.DynamicRepositoryClassLoader$ProxyEventListener.onEvent(DynamicRepositoryClassLoader.java:797) at org.apache.jackrabbit.core.observation.EventConsumer.consumeEvents(EventConsumer.java:246) at org.apache.jackrabbit.core.observation.ObservationDispatcher.run(ObservationDispatcher.java:161) at java.lang.Thread.run(Thread.java:619) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-1720) Classloader cache is not synced
[ https://issues.apache.org/jira/browse/SLING-1720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-1720. - Resolution: Fixed Syncing both maps in the classloader now. Changed in revision 991844 Classloader cache is not synced --- Key: SLING-1720 URL: https://issues.apache.org/jira/browse/SLING-1720 Project: Sling Issue Type: Bug Affects Versions: JCR Classloader 3.1.2 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: JCR Classloader 3.1.4 The classloader cache is not synced which can cause java.util.ConcurrentModificationExceptions: at java.util.HashMap$HashIterator.nextEntry(HashMap.java:793) at java.util.HashMap$ValueIterator.next(HashMap.java:822) at org.apache.sling.jcr.classloader.internal.DynamicRepositoryClassLoader.cleanCache(DynamicRepositoryClassLoader.java:394) at org.apache.sling.jcr.classloader.internal.DynamicRepositoryClassLoader.onEvent(DynamicRepositoryClassLoader.java:681) at org.apache.sling.jcr.classloader.internal.DynamicRepositoryClassLoader$ProxyEventListener.onEvent(DynamicRepositoryClassLoader.java:797) at org.apache.jackrabbit.core.observation.EventConsumer.consumeEvents(EventConsumer.java:246) at org.apache.jackrabbit.core.observation.ObservationDispatcher.run(ObservationDispatcher.java:161) at java.lang.Thread.run(Thread.java:619) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-1724) Improve script execution performance
Improve script execution performance Key: SLING-1724 URL: https://issues.apache.org/jira/browse/SLING-1724 Project: Sling Issue Type: Improvement Components: Scripting Affects Versions: Scripting Core 2.0.10 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Scripting Core 2.0.12 The creation of the SimpleScriptContext is relatively costly (in the DefaultSlingScript) - it takes more than 20% of the inclusion time. It seems to be that setting up the reader and writer in the SimpleScriptContext causes this. If we completly implement the script context, the include time is way faster. This also fixes some inconsistency with some methods in the script context; with the full implementation we have a fully working context wrt to the sling scope as well -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-1724) Improve script execution performance
[ https://issues.apache.org/jira/browse/SLING-1724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-1724. - Resolution: Fixed Fixed in revision 991933 Improve script execution performance Key: SLING-1724 URL: https://issues.apache.org/jira/browse/SLING-1724 Project: Sling Issue Type: Improvement Components: Scripting Affects Versions: Scripting Core 2.0.10 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Scripting Core 2.0.12 The creation of the SimpleScriptContext is relatively costly (in the DefaultSlingScript) - it takes more than 20% of the inclusion time. It seems to be that setting up the reader and writer in the SimpleScriptContext causes this. If we completly implement the script context, the include time is way faster. This also fixes some inconsistency with some methods in the script context; with the full implementation we have a fully working context wrt to the sling scope as well -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1728) ServiceCache is prone to deadlocks
[ https://issues.apache.org/jira/browse/SLING-1728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12906333#action_12906333 ] Carsten Ziegeler commented on SLING-1728: - Yes I think version 2 is the better option ServiceCache is prone to deadlocks -- Key: SLING-1728 URL: https://issues.apache.org/jira/browse/SLING-1728 Project: Sling Issue Type: Bug Components: Scripting Affects Versions: Scripting Core 2.0.12 Reporter: Felix Meschberger Assignee: Felix Meschberger Priority: Critical Fix For: Scripting Core 2.0.12 Attachments: SLING-1728-v1.patch, SLING-1728-v2.patch The ServiceCache introduce with SLING-1478 is prone to deadlocks with the Framework. The serviceChanged method is called from the framework and tries to synchronize on the cache. The getService method on the other hand synchronizes on the cache and while holding the lock calls into the framework. The fix is to not hold a lock while calling into the framework. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (SLING-1426) Spurious wakeups are not handled correctly
[ https://issues.apache.org/jira/browse/SLING-1426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-1426. --- Spurious wakeups are not handled correctly -- Key: SLING-1426 URL: https://issues.apache.org/jira/browse/SLING-1426 Project: Sling Issue Type: Bug Components: Extensions Affects Versions: Extensions Event 2.3.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Extensions Event 2.4.0 According to the javadocs, a object.wait() should always be done in a loop in order to catch spurious wakeups. The JobEventHandler implementation does not wait in a loop which might result in dead locks. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (SLING-1687) JobStatusProvider should lazy load events when returning
[ https://issues.apache.org/jira/browse/SLING-1687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-1687. --- JobStatusProvider should lazy load events when returning Key: SLING-1687 URL: https://issues.apache.org/jira/browse/SLING-1687 Project: Sling Issue Type: New Feature Components: Extensions Affects Versions: Extensions Event 2.3.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Extensions Event 2.4.0 The current implementation of the job status provider does a query, then loads all jobs and returns a list. If you just want to know how many jobs are available or just want to return the first X jobs, the implementation is too expansive. One solution would be to return a kind of range iterator instead of a list and load jobs on demand. There are two potential problems: - if the jcr query does not return a count, we can't return a count either without going through the hole result set - it might be that a job can't be loaded because of missing classes; in this cases the job count from the query result is higher than the count of the jobs that get processed. I think we can neglect this -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (SLING-1537) Illegal job topics are not handled correctly
[ https://issues.apache.org/jira/browse/SLING-1537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-1537. --- Illegal job topics are not handled correctly Key: SLING-1537 URL: https://issues.apache.org/jira/browse/SLING-1537 Project: Sling Issue Type: Bug Components: Extensions Affects Versions: Extensions Event 2.3.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Extensions Event 2.4.0 If a job event contains an illegal jop topic an illegal state exception is thrown inside the processing of the event - this exception is not really directly catched. This could cause inconsistencies in the event handling. A better solution would be to check the job topic when the job is received and immediately discard it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (SLING-1685) Method to force remove a job
[ https://issues.apache.org/jira/browse/SLING-1685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-1685. --- Method to force remove a job Key: SLING-1685 URL: https://issues.apache.org/jira/browse/SLING-1685 Project: Sling Issue Type: New Feature Components: Extensions Affects Versions: Extensions Event 2.3.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Extensions Event 2.4.0 Currently it is only possible to try to remove an event - this might fail if the job is in processing; while this is fine, this usually creates a problem for the client as it really wants to stop the job. It is easy to implement the retry in the job handling than in the client code. Therefore we should add a forceRemoveJob method which waits until the job is removed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (SLING-1518) Fix JMock 2.5.1 compatibility issue
[ https://issues.apache.org/jira/browse/SLING-1518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-1518. --- Fix JMock 2.5.1 compatibility issue --- Key: SLING-1518 URL: https://issues.apache.org/jira/browse/SLING-1518 Project: Sling Issue Type: Improvement Components: API, Extensions, Launchpad, Servlets Reporter: Justin Edelson Assignee: Justin Edelson Priority: Minor Fix For: Servlets Post 2.0.6, Launchpad Base 2.2.2, Extensions Event 2.4.0, Extensions Adapter 2.0.2, API 2.1.0 described here: http://markmail.org/message/uhwlfqabt4bn47sp -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-1594) Support CommonJS Modules i.e. the require function
[ https://issues.apache.org/jira/browse/SLING-1594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated SLING-1594: Fix Version/s: Scripting JavaScript 2.0.8 Support CommonJS Modules i.e. the require function -- Key: SLING-1594 URL: https://issues.apache.org/jira/browse/SLING-1594 Project: Sling Issue Type: Improvement Components: Scripting Reporter: Lars Trieloff Assignee: Carsten Ziegeler Priority: Minor Fix For: Scripting JavaScript 2.0.8 Attachments: SLING-1594.patch SLING-320 already allows calling functions in external scripts, so implementing the full-blown modules spec to allow interoperability with other CommonJS modules should be possible. http://wiki.commonjs.org/wiki/Modules/1.1.1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (SLING-1315) java.lang.ClassNotFoundException during jsp compilation
[ https://issues.apache.org/jira/browse/SLING-1315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-1315. --- java.lang.ClassNotFoundException during jsp compilation --- Key: SLING-1315 URL: https://issues.apache.org/jira/browse/SLING-1315 Project: Sling Issue Type: Bug Components: Scripting Environment: Day CQ5.2.1 fresh installation Reporter: zhangchunlong Attachments: errors.log This problems occurs only in this situations: * first time compilation of all the JSPs being used by a CQ Template * it happens only for requests to JSPs that generate CSS fragments. perhaps this is a timing issue because they are compiled at the same time when requested simulatneously by the browser. To reproduce this issue, please following the steps to reproduce in the DayCare ticket [1] . 1. for page [2], you could delete the contents under jcr:content to avoid unnecessary errors. The template codes generate the errors. 2. there is a easier way to reproduce the error which is connect to WebDAV and delete the compiled class file at /var/classes/org/ and refresh the page again. 3. it is not happen every time, but most of time, when it happens, there is a .classtmp file generated for the corresponding JSP under /var/classes/org/ [1] http://daycare.day.com/home/volkswagen/volkswagen_de/vwcms_design/16481.html [2] http://localhost:4502/de_sample/brand/de/e5_content.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SLING-1736) Potential Deadlock while registering/unregistering ResourceProvider
[ https://issues.apache.org/jira/browse/SLING-1736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler reassigned SLING-1736: --- Assignee: Carsten Ziegeler (was: Felix Meschberger) Potential Deadlock while registering/unregistering ResourceProvider --- Key: SLING-1736 URL: https://issues.apache.org/jira/browse/SLING-1736 Project: Sling Issue Type: Bug Components: JCR Affects Versions: JCR Resource 2.0.8 Reporter: Felix Meschberger Assignee: Carsten Ziegeler Priority: Blocker Fix For: JCR Resource 2.0.8 Upon registration and unregistration of new resource providers EventAdmin events are posted to inform interested parties of added and removed resource providers. Unfortunately these events are posted inside a synchronized(this) block, which may lead to deadlock situations. The solution (and right thing to do) is to post the events with the EventAdmin service outside of a synchronized block. I consider this a critical issue which blocks the next release of this module. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-1736) Potential Deadlock while registering/unregistering ResourceProvider
[ https://issues.apache.org/jira/browse/SLING-1736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-1736. - Resolution: Fixed I changed the sync blocks in revision 995023 - only add and remove operations are now inside the sync, everything else is outside Potential Deadlock while registering/unregistering ResourceProvider --- Key: SLING-1736 URL: https://issues.apache.org/jira/browse/SLING-1736 Project: Sling Issue Type: Bug Components: JCR Affects Versions: JCR Resource 2.0.8 Reporter: Felix Meschberger Assignee: Carsten Ziegeler Priority: Blocker Fix For: JCR Resource 2.0.8 Upon registration and unregistration of new resource providers EventAdmin events are posted to inform interested parties of added and removed resource providers. Unfortunately these events are posted inside a synchronized(this) block, which may lead to deadlock situations. The solution (and right thing to do) is to post the events with the EventAdmin service outside of a synchronized block. I consider this a critical issue which blocks the next release of this module. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-1737) Add state management for resources
Add state management for resources -- Key: SLING-1737 URL: https://issues.apache.org/jira/browse/SLING-1737 Project: Sling Issue Type: Improvement Components: Installer Affects Versions: OSGi Installer 3.0.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: OSGi Installer 3.0.0 Currently there is no state management, so it is hard to tell if a resource has been installed, should be installed, uninstalled etc. In some situations this leads to endless loops where something is tried over and over again - although nothing needs to be done anymore or can't be done. If we add proper state management to the resources, the installer knows what needs to be done and can act accordingly -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-1738) Add kind of audit log
Add kind of audit log - Key: SLING-1738 URL: https://issues.apache.org/jira/browse/SLING-1738 Project: Sling Issue Type: Improvement Affects Versions: OSGi Installer 3.0.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: OSGi Installer 3.0.0 It would be nice to log all actions (installs, updates, uninstalls) to a special log category to see what is going on in the system. With this we should revisit all log statements and unify them -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-1594) Support CommonJS Modules i.e. the require function
[ https://issues.apache.org/jira/browse/SLING-1594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-1594. - Resolution: Fixed Thanks for your patch, Lars - I've applied it in revision 995334. It works for me on the first request, there is no need to reload Support CommonJS Modules i.e. the require function -- Key: SLING-1594 URL: https://issues.apache.org/jira/browse/SLING-1594 Project: Sling Issue Type: Improvement Components: Scripting Reporter: Lars Trieloff Assignee: Carsten Ziegeler Priority: Minor Fix For: Scripting JavaScript 2.0.8 Attachments: SLING-1594.patch SLING-320 already allows calling functions in external scripts, so implementing the full-blown modules spec to allow interoperability with other CommonJS modules should be possible. http://wiki.commonjs.org/wiki/Modules/1.1.1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-1663) OSGi Install should recognize system bundle updates
[ https://issues.apache.org/jira/browse/SLING-1663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-1663. - Resolution: Fixed Setting this to resolved - if errors occur we can open a new bug or reopen OSGi Install should recognize system bundle updates --- Key: SLING-1663 URL: https://issues.apache.org/jira/browse/SLING-1663 Project: Sling Issue Type: Bug Components: Installer Reporter: Felix Meschberger Assignee: Carsten Ziegeler Fix For: OSGi Installer 3.0.0 The Launchpad Base module generates a bundle with the symbolic name system.bundle which is an official alias for the symbolic name of the system bundle whose real symbolic name is framework specific. The Web Console supports updates with the system.bundle symbolic name and updates the system bundle accordingly. The OSGi Installer should also recognize this situation and act accordingly: * The system bundle does not need to be stopped/started for the update, a framework restart is done automatically * A package refresh is not required * System bundle update acts immediately preventing OSGi Install from properly cleaning up after the install Thus updating the system bundle should probably be done in a special way: * at the of a processing cycle of OSGi Install * preventing any more processing before calling bundle update * probably updating the system bundle in a separate thread to not prevent proper shutdown of OSGi Install -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-1746) Use slf4j instead of log service
[ https://issues.apache.org/jira/browse/SLING-1746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-1746. - Resolution: Fixed Switched with revision 995732 Use slf4j instead of log service Key: SLING-1746 URL: https://issues.apache.org/jira/browse/SLING-1746 Project: Sling Issue Type: Task Affects Versions: OSGi Installer 3.0.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Priority: Minor Fix For: OSGi Installer 3.0.0 The installer uses currently the LogService to avoid dependencies - however nearly every log service implementation comes with various logging api's - so from a dependency pov it's no difference. The slf4j api (or any other logging api) provides more usuability, therefore we should switch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-1754) Jobs nodes should be unlocked after they have been changed
Jobs nodes should be unlocked after they have been changed -- Key: SLING-1754 URL: https://issues.apache.org/jira/browse/SLING-1754 Project: Sling Issue Type: Improvement Components: Extensions Affects Versions: Extensions Event 2.4.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Extensions Event 2.4.2 In a clustered environment, it can currently happen that another cluster node picks up a job during the unlock operation in finishJob and tries to process it. There is a delay between the unlock and a remove/finish operation. Therefore the node should either be directly removed/updated before the unlock -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1737) Add state management for resources
[ https://issues.apache.org/jira/browse/SLING-1737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12908437#action_12908437 ] Carsten Ziegeler commented on SLING-1737: - Updated the configuration state handling and bundle state handling in revisoin 996285 Add state management for resources -- Key: SLING-1737 URL: https://issues.apache.org/jira/browse/SLING-1737 Project: Sling Issue Type: Improvement Components: Installer Affects Versions: OSGi Installer 3.0.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: OSGi Installer 3.0.0 Currently there is no state management, so it is hard to tell if a resource has been installed, should be installed, uninstalled etc. In some situations this leads to endless loops where something is tried over and over again - although nothing needs to be done anymore or can't be done. If we add proper state management to the resources, the installer knows what needs to be done and can act accordingly -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1737) Add state management for resources
[ https://issues.apache.org/jira/browse/SLING-1737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12908471#action_12908471 ] Carsten Ziegeler commented on SLING-1737: - Started further refactoring of internal data objects in revision 996317 The EntityResourceList object will get whole state logic for a single entity, this keeps state handling in a single central place (WIP) Add state management for resources -- Key: SLING-1737 URL: https://issues.apache.org/jira/browse/SLING-1737 Project: Sling Issue Type: Improvement Components: Installer Affects Versions: OSGi Installer 3.0.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: OSGi Installer 3.0.0 Currently there is no state management, so it is hard to tell if a resource has been installed, should be installed, uninstalled etc. In some situations this leads to endless loops where something is tried over and over again - although nothing needs to be done anymore or can't be done. If we add proper state management to the resources, the installer knows what needs to be done and can act accordingly -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1737) Add state management for resources
[ https://issues.apache.org/jira/browse/SLING-1737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12908734#action_12908734 ] Carsten Ziegeler commented on SLING-1737: - No, with all the latest changes this one is passing fine on my machine - but very rarely the testBundleStatePreserved test (org.apache.sling.osgi.installer.it.BundleStatePreservedTest) fails now for me Add state management for resources -- Key: SLING-1737 URL: https://issues.apache.org/jira/browse/SLING-1737 Project: Sling Issue Type: Improvement Components: Installer Affects Versions: OSGi Installer 3.0.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: OSGi Installer 3.0.0 Currently there is no state management, so it is hard to tell if a resource has been installed, should be installed, uninstalled etc. In some situations this leads to endless loops where something is tried over and over again - although nothing needs to be done anymore or can't be done. If we add proper state management to the resources, the installer knows what needs to be done and can act accordingly -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-1761) JcrPropertyResource sets incorrect content length for strings containing non-ascii character
[ https://issues.apache.org/jira/browse/SLING-1761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated SLING-1761: Fix Version/s: JCR Resource 2.0.8 Sounds to me like an easy fix, we might want to include into the 2.0.8 release JcrPropertyResource sets incorrect content length for strings containing non-ascii character Key: SLING-1761 URL: https://issues.apache.org/jira/browse/SLING-1761 Project: Sling Issue Type: Bug Components: JCR Affects Versions: JCR Resource 2.0.6 Reporter: Julian Sedding Fix For: JCR Resource 2.0.8 Attachments: SLING-1761-tests.patch, SLING-1761.patch JcrPropertyResource sets the content length of the property in its metadata. To do so, it uses javax.jcr.Property#getLength() to determine the content length. The documentation for javax.jcr.Property#getLength() states [...] Returns the length in bytes if the value is a PropertyType.BINARY, otherwise it returns the number of characters needed to display the value in its string form. [...]. The documentation in ResourceMetadata is not explicit, but from its usage in StreamRendererServlet I conclude that ResourceMetadata.getContentLength() is intended for use in the Content-Length HTTP header. If my assumptions are correct, the content length indicates the number of bytes in the string, while javax.jcr.Property#getLength() returns the number of characters. The effect of this can be observed by the following steps: * create a string property /utf8string with value Bär * access this property using a browser (e.g. http://localhost:/utf8string), so that the property gets rendered by the StreamRendererServlet = the string is rendered incorrectly (due to a missing Content-Type header) = the string is cut off (due to the incorrectly set Content-Length header) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1737) Add state management for resources
[ https://issues.apache.org/jira/browse/SLING-1737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12908811#action_12908811 ] Carsten Ziegeler commented on SLING-1737: - Finished the state handling implementation with revision 996562. The tasks are now computed by the state of the resources to be installed/uninstalled and the current state of the system. This avoids reinstallation of resources or accidental uninstall etc. Add state management for resources -- Key: SLING-1737 URL: https://issues.apache.org/jira/browse/SLING-1737 Project: Sling Issue Type: Improvement Components: Installer Affects Versions: OSGi Installer 3.0.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: OSGi Installer 3.0.0 Currently there is no state management, so it is hard to tell if a resource has been installed, should be installed, uninstalled etc. In some situations this leads to endless loops where something is tried over and over again - although nothing needs to be done anymore or can't be done. If we add proper state management to the resources, the installer knows what needs to be done and can act accordingly -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-1773) Possible to store newly install bundle digests into bundle-digests.properties immediately after the bundle is installed successfully
[ https://issues.apache.org/jira/browse/SLING-1773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-1773. - Assignee: Carsten Ziegeler Fix Version/s: OSGi Installer 3.0.0 Resolution: Fixed With SLING-1737 we now have a better state management which ensures that once a bundle is installed it is immediately marked as installed. The extra saving of digests has been completly removed. Possible to store newly install bundle digests into bundle-digests.properties immediately after the bundle is installed successfully Key: SLING-1773 URL: https://issues.apache.org/jira/browse/SLING-1773 Project: Sling Issue Type: Improvement Components: Installer Affects Versions: JCR Installer 3.0.0 Environment: CQ5.3 Reporter: zhangchunlong Assignee: Carsten Ziegeler Priority: Minor Fix For: OSGi Installer 3.0.0 Bundle slinginstall:org.apache.sling.osgi.installer-3.0.0-R900409.jar in CQ5.3 only try to store the bundle digests into bundle-digests.properties when the server is shutting down. In case some bundles are installed and the server is not shutdown properly. eg. crash, being killed, next time when CQ5.3 starts, will try to re-install those bundles and leave the bundle status as installed. It might be good to store such information immediately after any bundle is being installed successfully if possible. To reproduce the issue: 1. create some test bundle 2. start the CQ5.3 instance, install the test bundle into some /install folder. 3. kill the CQ5.3 instance. 4. start the CQ5.3 instance again. 5. from the crx-quickstart/logs/error.log, could see the test bundle is being installed again. 6. from Felix console, the test bundle status is installed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1768) Download links are broken
[ https://issues.apache.org/jira/browse/SLING-1768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12909132#action_12909132 ] Carsten Ziegeler commented on SLING-1768: - The correct download page is : http://sling.apache.org/site/downloads.cgi but nevertheless you're right that the links are broken there as well Download links are broken - Key: SLING-1768 URL: https://issues.apache.org/jira/browse/SLING-1768 Project: Sling Issue Type: Bug Components: Site Reporter: Andreas Kuckartz Priority: Blocker Most or all of the binary download links on this page are broken: http://sling.apache.org/site/downloads.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-1737) Add state management for resources
[ https://issues.apache.org/jira/browse/SLING-1737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12909141#action_12909141 ] Carsten Ziegeler commented on SLING-1737: - I retried the tests running on Java 5 and Java 6 - and they run each time :( It seems the -Dpax.exam.log.level=DEBUG test option does not work like I expected; at least I can't find the relevant log statements in the logs you provided :( So maybe could you please rerun the tests and change directly the property value in the pom.xml? Please also make sure that you did a mvn install on the installer/osgi/installer project before you run the tests. @Justin - Are the tests for you failing with both Maven versions or just with 3.0-beta-3? - I'm just speculating here, but as I'm also using OS X with Maven 2.2.1, there must be some difference between our environments. Add state management for resources -- Key: SLING-1737 URL: https://issues.apache.org/jira/browse/SLING-1737 Project: Sling Issue Type: Improvement Components: Installer Affects Versions: OSGi Installer 3.0.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: OSGi Installer 3.0.0 Attachments: ConfigInstallTest-debug.log.gz, debug.zip, RemovedResourceDetectionTest-debug.log.gz Currently there is no state management, so it is hard to tell if a resource has been installed, should be installed, uninstalled etc. In some situations this leads to endless loops where something is tried over and over again - although nothing needs to be done anymore or can't be done. If we add proper state management to the resources, the installer knows what needs to be done and can act accordingly -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
