[jira] Closed: (SLING-1022) Make script resolution cacheable
[ https://issues.apache.org/jira/browse/SLING-1022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-1022. --- Resolution: Fixed The resource collector now contains all relevant information and implements equals() and hashCode() Make script resolution cacheable Key: SLING-1022 URL: https://issues.apache.org/jira/browse/SLING-1022 Project: Sling Issue Type: Improvement Components: Servlets Resolver Affects Versions: Servlets Resolver 2.0.6 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Servlets Resolver 2.0.8 The ResourceCollector object needs to be enhanced in order to use it as a key for caching the script resolution. Besides the extension, selectors etc. it should contain the resource type and resource super type. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (SLING-1021) Use admin (configurable user) session for script resolution
[ https://issues.apache.org/jira/browse/SLING-1021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-1021. --- Resolution: Fixed Fix Version/s: Servlets Resolver 2.0.8 The admin session is now used to resolve all scripts. A script user is configurable, if this configuration is set, a session with this user is used instead of the admin session. Use admin (configurable user) session for script resolution --- Key: SLING-1021 URL: https://issues.apache.org/jira/browse/SLING-1021 Project: Sling Issue Type: New Feature Components: Servlets Resolver Affects Versions: Servlets Resolver 2.0.6 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Servlets Resolver 2.0.8 Currently the user session from the current request is used to resolve a script. This has many drawbacks like the scripts need to be readable for all users, caching of the script resolution is not that efficient etc. As discussed in the mailing list, we'll change the script resolution to use a single session. By default the admin session is used, but this will be configurable to use a specific user instead. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: OSGi Compendium
Dominik Süß wrote: Wouldn't it be more straight forward to exclude the Compendium Libraries from the Declarative Services as well and have it as seperate bundle in general? I know this thoughts might lead to a big amount of small bundles and some might not like this, but in this case I think it really would make sense. This actually would require to split up the compendium into the various parts and have an api bundle for each part. Updating the DS then would require to update the api and the impl bundle. Hmm, not sure what the better option is. At least, it seems that pre bundling the compendium libs is wrong. So +1 to remove them from launchpad/base. I like the way how the Apache Felix DS implementation does it. You get one bundle containing everything you need. So updating to a new spec version is pretty simply as the bundle is self contained. How do other implementations do this? Carsten Regards, Dominik On Thu, Jun 25, 2009 at 4:39 PM, Felix Meschberger fmesc...@gmail.comwrote: Hi all, Currently the Sling launcher (in the launchpad/base module) contains the Felix framework, the OSGi Core libraries as well as the OSGi Compendium libraries. While working on the implementation of the new Declarative Services 1.1 features planned for addition in the OSGi Compendium Specification 4.2 I ran into a problem with this setup. Consider a bundle X importing the Declarative Services packages *before* the new implementation is installed. Both the system bundle (as per the launchpad/base module) and the Declarative Services implementation export version 1.0 of the org.osgi.service.component package. This results in all bundles wiring to the system bundle. Everything is fine. Now update the Declarative Services bundle which now exports version 1.1 of the org.osgi.service.component package. The Declarative Services bundle binds to its own export using the latest version available. Bundle X is still wired to the system bundle because there is no rewiring taking place. The consequence is, that the new Declarative Services bundle cannot call any of the activate or deactivate methods of the components in Bundle X because the ComponentContext argument is not compatible. As a fix, I suggest we modify the launchpad/base bundle to *not* provide the Compendium packages any more. Instead we will expect that either the Compendium implementation bundles export the packages (as for example the Apache Felix Declarative Services bundle does) or that the compendium packages are installed as a bundle. WDYT ? Regards Felix -- Carsten Ziegeler cziege...@apache.org
Revisiting the resource super type handling
Hi, while changing the script resolution in the last days a little bit to make it cacheable, I stumbled across the handling of the resource super type. The jcr resource implementation checks if the node has the sling:resourceSuperType property and returns this value if existent. If not, it tries to find a resource under the search paths (usually libs and apps) with the resource type converted to a path. So if a resource has the type a/b, the resources /apps/a/b and /libs/a/b are tested if they exist and contain a resource super type property. Other resource implementations like the bundle resource always returns null. The fs resource implemenations returns a special resource type for the resource super type. I think this behaviour is a little bit inconsistent. I would change it that if a resource does not know it's super type, it should return null. So basically this effects the implementation of the jcr resource. The script resolver already checks if the resource super type is null and then applies the above algoritm from the jcr resource as well. Otherwise each resource implemenation should apply the algorithm to be consistent. But I would prefer the first solution. While the change is incompatible, I think this doesn't have any real effect. WDYT? Carsten -- Carsten Ziegeler cziege...@apache.org
Re: OSGi Compendium
Felix Meschberger schrieb: Carsten Ziegeler schrieb: Dominik Süß wrote: Wouldn't it be more straight forward to exclude the Compendium Libraries from the Declarative Services as well and have it as seperate bundle in general? I know this thoughts might lead to a big amount of small bundles and some might not like this, but in this case I think it really would make sense. This actually would require to split up the compendium into the various parts and have an api bundle for each part. Updating the DS then would require to update the api and the impl bundle. Hmm, not sure what the better option is. At least, it seems that pre bundling the compendium libs is wrong. So +1 to remove them from launchpad/base. I like the way how the Apache Felix DS implementation does it. You get one bundle containing everything you need. So updating to a new spec version is pretty simply as the bundle is self contained. Actually the Apache Felix DS implementation also exports the Configuration Admin packages. This will probably be removed for the next release. How do other implementations do this? AFAICT the Eclipse/Equinox project is using the approach of not including the API in the implementation bundles but to have you install the compendium library bundle. There are basically two approaches to the question of where to locate API with respect to the implementations: One is to include the implemented API with the implementation. The other is to strictly separate API from implementation. My stance is somewhere in-between. Generally I prefer separating the API from the implementation, unless ... For example, in Sling we have the Sling API bundle. This is IMHO a coherent API which is implemented by multiple bundles, e.g. the engine and the jcr/resource bundles. This API is separate. On the other hand we have the exported API of the jcr/resource bundle. While we could separate it out into a separate bundle, the resulting bundle would be so small, that it probably makes no sense. In addition, chances of another implementation of that API are close to zero. For the compendium API, the case is that the Compendium library is a collection of more or less unrelated packages (there is close to no interpackage references on the API level). So having one Compendium bundle tends to lead to issues if we upgrade the implementations independetly of the versioning of the different packages. Yepp, exactly. That's why we either have to split up the compendium into several api bundles (one for DS, one for config admin etc.) or the implementations should bundle it. It is a little bit strange that while OSGi is about modularity the compendium is a single library :) Carsten -- Carsten Ziegeler cziege...@apache.org
[jira] Closed: (SLING-987) Jobs/Events are purged in an uncontrolled way
[ https://issues.apache.org/jira/browse/SLING-987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-987. -- Resolution: Fixed Jobs/Events are purged in an uncontrolled way - Key: SLING-987 URL: https://issues.apache.org/jira/browse/SLING-987 Project: Sling Issue Type: Bug Components: Event Affects Versions: Extensions Event 2.0.4 Reporter: Philipp Koch Assignee: Carsten Ziegeler Priority: Blocker Fix For: Extensions Event 2.0.6 We already had this problem for pretty big event/job queues once (a month ago or so. could not find a jira issue) that the job in the queue got purged because the job acknowledge timed out for that job (by default the job/event is purged after 3 timeouts). the above mentioned fix fixed the issue quite well. it appeared now again when running such big queues on very fast boxes: 9.05.2009 13:00:07.904 *INFO* [pool-4-thread-1] org.apache.sling.event.impl.JobEventHandler No acknowledge received for job org.osgi.service.event.Event [topic=com/day/cq/workflow/job] stored at /var/eventing/jobs/com.day.cq.workflow.job/Job5a50f993-8f36-4eae-81d5-3124ca455bf5. Requeueing job. the funny thing is now that the timeout does not happen after hours but already after 10 mins. there are no (debug) log entries that would point to some event handler problems... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-904) jcrinstall - take three
[ https://issues.apache.org/jira/browse/SLING-904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12723502#action_12723502 ] Carsten Ziegeler commented on SLING-904: Implemented a quick and dirty retry if the bundle can't be started the first time it's tried. jcrinstall - take three --- Key: SLING-904 URL: https://issues.apache.org/jira/browse/SLING-904 Project: Sling Issue Type: Improvement Components: JCR Install Reporter: Bertrand Delacretaz Refactor and reengineer jcrinstall based on the accumulated experiences of the take two, SLING-646. See discussion in http://markmail.org/message/ld6tkz6fdseknntx -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1020) Add some methods from JcrResourceUtil to ResourceUtil
[ https://issues.apache.org/jira/browse/SLING-1020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12723534#action_12723534 ] Carsten Ziegeler commented on SLING-1020: - Added the methods to ResourceUtil together with some base tests in revision 787983 Add some methods from JcrResourceUtil to ResourceUtil - Key: SLING-1020 URL: https://issues.apache.org/jira/browse/SLING-1020 Project: Sling Issue Type: New Feature Components: API, JCR Resource Affects Versions: JCR Resource 2.0.4, API 2.0.4 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: API 2.0.6, JCR Resource 2.0.6 The getResourceSuperType, resourceTypeToPath methods in the JcrResourceUtil are of general interest and not tied to jcr; for example the script resolution makes use of them. We should move them to the API ResourceUtil, let the old methods invoke the new ones and deprecate them -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1020) Add some methods from JcrResourceUtil to ResourceUtil
[ https://issues.apache.org/jira/browse/SLING-1020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12723537#action_12723537 ] Carsten Ziegeler commented on SLING-1020: - Deprecate getResourceSuperType, resourceTypeToPath from JcrResourceUtil and improve resource super handling. in revision: 787987 Add some methods from JcrResourceUtil to ResourceUtil - Key: SLING-1020 URL: https://issues.apache.org/jira/browse/SLING-1020 Project: Sling Issue Type: New Feature Components: API, JCR Resource Affects Versions: JCR Resource 2.0.4, API 2.0.4 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: API 2.0.6, JCR Resource 2.0.6 The getResourceSuperType, resourceTypeToPath methods in the JcrResourceUtil are of general interest and not tied to jcr; for example the script resolution makes use of them. We should move them to the API ResourceUtil, let the old methods invoke the new ones and deprecate them -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (SLING-1020) Add some methods from JcrResourceUtil to ResourceUtil
[ https://issues.apache.org/jira/browse/SLING-1020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-1020. --- Resolution: Fixed Add some methods from JcrResourceUtil to ResourceUtil - Key: SLING-1020 URL: https://issues.apache.org/jira/browse/SLING-1020 Project: Sling Issue Type: New Feature Components: API, Engine, JCR Resource Affects Versions: JCR Resource 2.0.4, Engine 2.0.4, API 2.0.4 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Engine 2.0.6, API 2.0.6, JCR Resource 2.0.6 The getResourceSuperType, resourceTypeToPath methods in the JcrResourceUtil are of general interest and not tied to jcr; for example the script resolution makes use of them. We should move them to the API ResourceUtil, let the old methods invoke the new ones and deprecate them -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-1021) Use admin (configurable user) session for script resolution
Use admin (configurable user) session for script resolution --- Key: SLING-1021 URL: https://issues.apache.org/jira/browse/SLING-1021 Project: Sling Issue Type: New Feature Components: Servlets Resolver Affects Versions: Servlets Resolver 2.0.6 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Currently the user session from the current request is used to resolve a script. This has many drawbacks like the scripts need to be readable for all users, caching of the script resolution is not that efficient etc. As discussed in the mailing list, we'll change the script resolution to use a single session. By default the admin session is used, but this will be configurable to use a specific user 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-1022) Make script resolution cacheable
Make script resolution cacheable Key: SLING-1022 URL: https://issues.apache.org/jira/browse/SLING-1022 Project: Sling Issue Type: Improvement Components: Servlets Resolver Affects Versions: Servlets Resolver 2.0.6 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Servlets Resolver 2.0.8 The ResourceCollector object needs to be enhanced in order to use it as a key for caching the script resolution. Besides the extension, selectors etc. it should contain the resource type and resource super type. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Code Coverage and Metrics
Hi, Sling has been added to the public Sonar instance: http://nemo.sonarsource.org/project/index/org.apache.sling:sling-builder So we get some nice graphics about code coverage, some metrics etc. Atm we have 9% coverage :) Anyone interested in making us look better? Regards Carsten -- Carsten Ziegeler cziege...@apache.org
[jira] Created: (SLING-1018) Remove dependency to DS
Remove dependency to DS --- Key: SLING-1018 URL: https://issues.apache.org/jira/browse/SLING-1018 Project: Sling Issue Type: Improvement Components: JCR Install Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Currently the jcr install requires the declarative services. In order to have minimal dependencies, an activator in combination with service trackers should be used instead. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (SLING-1018) Remove dependency to DS
[ https://issues.apache.org/jira/browse/SLING-1018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-1018. --- Resolution: Fixed Fix Version/s: JCR Install 2.0.4 Removed the dependency to declarative service in revision 787739 Remove dependency to DS --- Key: SLING-1018 URL: https://issues.apache.org/jira/browse/SLING-1018 Project: Sling Issue Type: Improvement Components: JCR Install Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: JCR Install 2.0.4 Currently the jcr install requires the declarative services. In order to have minimal dependencies, an activator in combination with service trackers should be used 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-1019) Correctly handle bind/unbind of repository
Correctly handle bind/unbind of repository -- Key: SLING-1019 URL: https://issues.apache.org/jira/browse/SLING-1019 Project: Sling Issue Type: Bug Components: JCR Install Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler The bind method with a new repository may be called before unbind with the old one is called. In addition, the activate and bind methods should not start installs/uninstalls to avoid potential deadlocks -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-1020) Add some methods from JcrResourceUtil to ResourceUtil
Add some methods from JcrResourceUtil to ResourceUtil - Key: SLING-1020 URL: https://issues.apache.org/jira/browse/SLING-1020 Project: Sling Issue Type: New Feature Components: API, JCR Resource Affects Versions: API 2.0.4, JCR Resource 2.0.4 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: API 2.0.6, JCR Resource 2.0.6 The getResourceSuperType, resourceTypeToPath methods in the JcrResourceUtil are of general interest and not tied to jcr; for example the script resolution makes use of them. We should move them to the API ResourceUtil, let the old methods invoke the new ones and deprecate 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-1017) JCR Resource Resolver 2 generates the same immutable array of JcrResourceTypeProviders on each request.
[ https://issues.apache.org/jira/browse/SLING-1017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-1017. - Resolution: Fixed Fix Version/s: JCR Resource 2.0.6 Assignee: Carsten Ziegeler Thanks for your patch Ian, it's applied in revision: 787268 Can you please cross check and close this bug? Thanks JCR Resource Resolver 2 generates the same immutable array of JcrResourceTypeProviders on each request. --- Key: SLING-1017 URL: https://issues.apache.org/jira/browse/SLING-1017 Project: Sling Issue Type: Bug Components: JCR Resource Affects Versions: JCR Resource 2.0.6 Reporter: Ian Boston Assignee: Carsten Ziegeler Fix For: JCR Resource 2.0.6 Attachments: SLING-1017.path THe JCR Resource Resolver creates 1 array of JcrResourceTypeProviders per request, even if there has been no change to the array. The Array is immutable once created and so it should really be created on change not on request. The creation of this array alos synchronizes all request, which is probably not great for scalability. patch to follow -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-1012) JcrResourceResolverFactoryImpl does not register JcrResourceTypeProviders correctly.
[ https://issues.apache.org/jira/browse/SLING-1012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-1012. - Resolution: Fixed Fix Version/s: JCR Resource 2.0.6 Assignee: Carsten Ziegeler Thanks for your patch Ian, it's applied in revision: 787268 Can you please cross check and close this bug? Thanks JcrResourceResolverFactoryImpl does not register JcrResourceTypeProviders correctly. Key: SLING-1012 URL: https://issues.apache.org/jira/browse/SLING-1012 Project: Sling Issue Type: Bug Components: JCR Resource Affects Versions: JCR Resource 2.0.6 Reporter: Ian Boston Assignee: Carsten Ziegeler Fix For: JCR Resource 2.0.6 Attachments: SLING-1012.patch JcrResourceResolverFactoryImpl only works for 0 or 1 JcrResourceTypeProvider Patch to follow. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[RT] Script Resolution
Hi, I'm currently working on improving the script resolution in terms of performance. While looking at how it works today, I've discovered two problematic points: 1) Currently the scripts are searched by using the session of the current request. Now, I think using the user session to search the script is wrong. The content, the user requests, is already retrieved with the user session and its the content (or the acl's on the content) who define if the user is allowed to access something. The script should always be executable (and I'm speaking of execution not reading, writing etc.) for any user. This also matches the current handling for scripts which are not stored in the repository like the servlets or scripts contained in bundle resources. Therefore I suggest to change the script resolution to use the admin session. Btw, this would also make caching the script resolution easier as the current approach requires the caching of the script resolution to be a per user cache. With the changes from above the cache can be global. 2) Resource events We need to implement https://issues.apache.org/jira/browse/SLING-944 and some extension of this to properly update the cache if scripts are changed, added removed. As scripts can be coming from any data source (jcr, file system, bundle, database etc.) we need a generic mechanism here. For now I think we could start with OSGi events for - Resource added, removed, changed - Resource Provider added, removed WDYT? Carsten -- Carsten Ziegeler cziege...@apache.org
Re: [RT] Script Resolution
Another minor issue are the helper methods of the JcrResourceUtil class (the getResourceSuperType, resourceTypeToPath methods). I think we can make them completly JCR free and move them to the ResourceUtil class in the API. Carsten Carsten Ziegeler wrote: Hi, I'm currently working on improving the script resolution in terms of performance. While looking at how it works today, I've discovered two problematic points: 1) Currently the scripts are searched by using the session of the current request. Now, I think using the user session to search the script is wrong. The content, the user requests, is already retrieved with the user session and its the content (or the acl's on the content) who define if the user is allowed to access something. The script should always be executable (and I'm speaking of execution not reading, writing etc.) for any user. This also matches the current handling for scripts which are not stored in the repository like the servlets or scripts contained in bundle resources. Therefore I suggest to change the script resolution to use the admin session. Btw, this would also make caching the script resolution easier as the current approach requires the caching of the script resolution to be a per user cache. With the changes from above the cache can be global. 2) Resource events We need to implement https://issues.apache.org/jira/browse/SLING-944 and some extension of this to properly update the cache if scripts are changed, added removed. As scripts can be coming from any data source (jcr, file system, bundle, database etc.) we need a generic mechanism here. For now I think we could start with OSGi events for - Resource added, removed, changed - Resource Provider added, removed WDYT? Carsten -- Carsten Ziegeler cziege...@apache.org
[jira] Commented: (SLING-1007) Implement helper classloader
[ https://issues.apache.org/jira/browse/SLING-1007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12721113#action_12721113 ] Carsten Ziegeler commented on SLING-1007: - I'll start with the original issue and when we've finished that we can have a look at the other use case. Implement helper classloader Key: SLING-1007 URL: https://issues.apache.org/jira/browse/SLING-1007 Project: Sling Issue Type: New Feature Components: Commons OSGi Affects Versions: Commons OSGi 2.0.4 Reporter: Felix Meschberger Assignee: Carsten Ziegeler Currently we require the ScriptEngine[Factory] implementation bundles to create bundle header DynamicImport-Package: * to be able to access anything from the scripts since scripts are executed in the class loader of the script engine bundle. The downside of running the scripts in the class loader of the script engine bundle and using this global dynamic import are: * scripts see internal classes of the script engine bundle * scripts engine bundles must provide for classes for the scripts * whenever a wire has been created for a script and the providing bundle is updated or uninstalled, the script engine bundle is also cycled. A better approach might be to provide a ClassLoader implementation which behind the scenes manages access to packages exported by the bundles installed in the system. I would imagine such an implementation along the following lines: * Uses PackageAdmin to find a bundle providing the required class * Copes with bundles being updated or uninstalled Maybe coping with bundles being updated or uninstalled requires a two level approach: a fronend class loader which answers the class and resource accesses by relaying to a backend class loader. The back end classloader does the hardwork of loading classes and resources by querying bundles. Whenever a bundle is updated or uninstalled the backend classloader gets replaced. A similar approach has been chosen for the Repository ClassLoader in the jcr/classloader bundle. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SLING-1007) Implement helper classloader
[ https://issues.apache.org/jira/browse/SLING-1007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler reassigned SLING-1007: --- Assignee: Carsten Ziegeler Implement helper classloader Key: SLING-1007 URL: https://issues.apache.org/jira/browse/SLING-1007 Project: Sling Issue Type: New Feature Components: Commons OSGi Affects Versions: Commons OSGi 2.0.4 Reporter: Felix Meschberger Assignee: Carsten Ziegeler Currently we require the ScriptEngine[Factory] implementation bundles to create bundle header DynamicImport-Package: * to be able to access anything from the scripts since scripts are executed in the class loader of the script engine bundle. The downside of running the scripts in the class loader of the script engine bundle and using this global dynamic import are: * scripts see internal classes of the script engine bundle * scripts engine bundles must provide for classes for the scripts * whenever a wire has been created for a script and the providing bundle is updated or uninstalled, the script engine bundle is also cycled. A better approach might be to provide a ClassLoader implementation which behind the scenes manages access to packages exported by the bundles installed in the system. I would imagine such an implementation along the following lines: * Uses PackageAdmin to find a bundle providing the required class * Copes with bundles being updated or uninstalled Maybe coping with bundles being updated or uninstalled requires a two level approach: a fronend class loader which answers the class and resource accesses by relaying to a backend class loader. The back end classloader does the hardwork of loading classes and resources by querying bundles. Whenever a bundle is updated or uninstalled the backend classloader gets replaced. A similar approach has been chosen for the Repository ClassLoader in the jcr/classloader bundle. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-1011) Remove incubator from versions and remove disclaimer
Remove incubator from versions and remove disclaimer Key: SLING-1011 URL: https://issues.apache.org/jira/browse/SLING-1011 Project: Sling Issue Type: Task Components: General Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (SLING-1011) Remove incubator from versions and remove disclaimer
[ https://issues.apache.org/jira/browse/SLING-1011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-1011. --- Resolution: Fixed I've removed the DISCLAIMER files and disclaimer sections from the readme's. Converted the svn locations Converted the links to the website Removed the -incubator from the module versions Remove incubator from versions and remove disclaimer Key: SLING-1011 URL: https://issues.apache.org/jira/browse/SLING-1011 Project: Sling Issue Type: Task Components: General Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: SLING-490, SystemStatus service discussion
Felix Meschberger wrote: Yes, of course. ConfigAdmin is *not* required for DS. Ah yes, you're right (of course) - I was mistaken as the import for the config admin are not optional in the *pom* of the scr implementation; I didn't see that it actually exports and imports them. :) Carsten -- Carsten Ziegeler cziege...@apache.org
Re: SLING-490, SystemStatus service discussion
Felix Meschberger wrote: Hi, Replying to this message, but my response applies to the complete thread. Let's step back a second and look at what we really need to know to be able to decide the system is ready or not. And who is responsible to provide this knowledge. (1) The most basic criterion for the system to be ready is the available of certain services. (2) There must be away to specify which services are required. Now, this is very simple and easy: As Alex Klimetschek proposes we are using ConfigurationAdmin for this. Each service can be described by a few properties: (a) Service Name (b) Service Filter (c) Number of services The configuration of required services is a multivalued string property of the format [ number ] ( serviceName | serviceFilter ) where numberis an optional positive number of required services serviceName is the name of a service interface serviceFilter is a service filter according to 3.2.6, Filter Syntax The system status service itself : * requires the ConfigAdmin service to be present * registers as a ManagedService to receive the configuration Thats basically all. Very simple, very lean. I still hae my problem with storing the config in the config admin. 1) How does it get there? 2) What happens between the time when a) the main servlet and the config admin are started but the config from 1) isn't there? Regards Carsten -- Carsten Ziegeler cziege...@apache.org
Re: SLING-490, SystemStatus service discussion
Bertrand Delacretaz wrote: Again, I think using sling.properties to define where this info comes from is the most flexible way, going back to yesterday's example from sling.properties: # Values like myServiceA uses the syntax proposed by Felix sling.readyness.check.1 = services:myServiceA, myServiceB # jcr: means look in the repository for additional definitions sling.readyness.check.2 = jcr:/system/sling/status # osgi:ConfigAdmin means use that service to get additional required # services definition. If not present, the ConfigAdmin service is not # required (for super-lean Sling instances) sling.readyness.check.3 = osgi:ConfigAdmin:nameOfTheConfigThatHoldsThisInfo This is easy to implement, flexible, and implementing it is probably faster than spending ages discussing exactly which options we allow ;-) +1 for using sling.properties :) and I think we should just implement the service check for now - just implementing one option which we need seems to be even faster than implementing more options :) Carsten -- Carsten Ziegeler cziege...@apache.org
Re: SLING-490, SystemStatus service discussion
Felix Meschberger wrote: Hi, Well, *if* we want to check the system state, that check should be done continuously during the whole lifetime otherwise it makes no sense, honestly: +1 Carsten -- Carsten Ziegeler cziege...@apache.org
Re: SLING-490, SystemStatus service discussion
Carsten Ziegeler wrote: Bertrand Delacretaz wrote: Again, I think using sling.properties to define where this info comes from is the most flexible way, going back to yesterday's example from sling.properties: # Values like myServiceA uses the syntax proposed by Felix sling.readyness.check.1 = services:myServiceA, myServiceB # jcr: means look in the repository for additional definitions sling.readyness.check.2 = jcr:/system/sling/status # osgi:ConfigAdmin means use that service to get additional required # services definition. If not present, the ConfigAdmin service is not # required (for super-lean Sling instances) sling.readyness.check.3 = osgi:ConfigAdmin:nameOfTheConfigThatHoldsThisInfo This is easy to implement, flexible, and implementing it is probably faster than spending ages discussing exactly which options we allow ;-) +1 for using sling.properties :) and I think we should just implement the service check for now - just implementing one option which we need seems to be even faster than implementing more options :) Rethinking the whole stuff, maybe it's better to not use the sling.properties :) and use a configuration provided by the config admin. With jcr install, file install, and the sling launchpad we have a provisioning system that installs bundles and configurations at the same time. Therefore when the sling engine gets installed, the configuration can already be there. If now the sling main servlet requires the configuration, we're done and have a more portable solution. So I withdraw my +1 for properties :) and give +1 for config admin! But still, checking for services should be sufficient. Carsten -- Carsten Ziegeler cziege...@apache.org
Re: SLING-490, SystemStatus service discussion
Bertrand Delacretaz wrote: Not really at the same time, IMHO the sequence is, in a typical Sling launchpad setup: 1. OSGi framework starts 2. Sling engine bundle starts (few dependencies, so starts early) - HTTP requests are accepted now, or soon 3. SlingRepository becomes available (usally later- more dependencies and heavier) 4. jcrinstall observer requires SlingRepository, so starts even later 5. jcrinstall configs might take 1-2 seconds to be activated, due to some internal polling cycles So, if a request comes in afer step 2, and at step 5. some additional SystemStatus configs would have come in, we have a problem. Yes, sure but if you think of the initial provisioning, where jcr install (or any other install routine) installs the sling bundles and adds the config. From there one everything is fine and before that nothing is available anyway. You only ran into the above if sling is already installed and then jcr install should provide the config. But as long as the config is installed at the same point of time as the status check service we're fine. And that should be easy. What's wrong with that? You say no, we must use ConfigAdmin but what's the justification for this? The above is more flexible and copes with different use cases for the Sling engine, including not having a repository and not having a ConfigAdmin service. ...So I withdraw my +1 for properties :) and give +1 for config admin!.. I'm starting to think this thread is a plot to make me lose the few hair that I have left ;-) Ah, damn, you recognized this too early...now you spoiled all the fun :( We have a bet running how long it will take you to reach that state :) Ok, seriously, sling.properties are problematic as they are only available if sling is run with the launchpad. If you run sling inside equinox, spring server etc. the properties are not available! When I gave my +1 for the properties I didn't thought if this myself. But then during the whole discussion I realized this :) So we should really use a standard way that works in every installation. Carsten -- Carsten Ziegeler cziege...@apache.org
Re: SLING-490, SystemStatus service discussion
Bertrand Delacretaz wrote -Bertrnad Now you know why people sometimes forget about the 'r' :) Ok, just as a heads up, I installed the latest engine in my applications and guess what happens? It doesn't work anymore as I did not install the system status service bundle! We should really make the engine work without any extra bundle as soon as possible. Regards Carsten -- Carsten Ziegeler cziege...@apache.org
Re: SLING-490, SystemStatus service discussion
Bertrand Delacretaz wrote: On Mon, Jun 15, 2009 at 1:00 PM, Alexander Klimetschekaklim...@day.com wrote: On Mon, Jun 15, 2009 at 11:31 AM, Bertrand Delacretazbdelacre...@apache.org wrote: 1. The goal is to return a 503 status until the system is ready to process requests. 2. Defining readyness is hard due to the dynamic nature of OSGi and especially Declarative Services. My idea is to use scripts found under /system/sling/status in the JCR repository to let programmers define what they require for their system to be ready. Why not put a list under /system/sling/status/requiredBundles and requiredServices with the names of the bundles and services that should be running in order to consider the system to be ready? Good idea, and it would allow extensions for use cases that go beyond just testing the presence of a given bundle or service: one could create a service S that checks the required preconditions before coming up (using code, scripts, whatever), and configure S as a requiredService. ...That way it a) only depends on the OSGi Framework API b) could be implemented right inside the engine, introducing none of the chicken and egg problems. c) it also allows you to define more than just scripting engines as dependencies for your system ready state Correct, though my original proposal also allowed for more than scripting engines. The idea was that readyness scripts would check for bundles and services, and maybe run some test code. But your proposal seems to cover all of that. What do others think? I'm not sure :) The stuff Alex suggests is similar to the idea we discussed some time ago when we first thought about this. If we use some kind of configuration for this check, the questions is when is this configuration available? If first the engine starts, the check is performed (with an empty or minimal configuration) you have a system which is running, then at a later point the config kicks in and your system is not ready anymore until the required stuff is running. This might be nitpicking but the system might appear as ready although its not. As a general note, checking if the system is ready might increase the startup time as you're system is only responding if all required services are really available. There might be cases where this is not necessary. Regardless of what we do, I think that the ready check and the configuration for this check must form a single unit. Therefore additional configuration and extra bundles are not a good solution in my opinion. To be fair, I have not good idea either atm. But let's add some other requirements :) The stuff must work without a repository (again my use case for portlets do not have a repository) and it should work without third bundles like config admin etc. Therefore a check like Alex suggest above which solely relies on the OSGI API seems to be good start; the remaining question however is the configuration therefore. Now we could do this by requiring people to repackage the engine bundle and adding a configuration as a resource to the bundle. The default engine has zero checks. This would solve the provisioning of the config but creates new problems when it comes to updates of the bundle etc. Carsten -- Carsten Ziegeler cziege...@apache.org
Re: SLING-490, SystemStatus service discussion
Bertrand Delacretaz wrote: For example: sling.readyness.check = jcr:/system/sling/status to indicate that the readyness check must use JCR nodes under that path to configure itself, like Alex suggests. Absence of that property means no readyness check, and we can later define prefixes other than jcr for alternate mechanisms, if needed. What about merging this with Alex idea? We define properties for required bundles to be available and another one for the services. The sling main servlet (or some helper service) reads the props, and acts accordingly. This keeps everything in one single bundle and does not require any additional stuff. Carsten -- Carsten Ziegeler cziege...@apache.org
Re: SLING-490, SystemStatus service discussion
Bertrand Delacretaz wrote: On Mon, Jun 15, 2009 at 3:18 PM, Carsten Ziegelercziege...@apache.org wrote: Bertrand Delacretaz wrote: sling.readyness.check = jcr:/system/sling/status to indicate that the readyness check must use JCR nodes under that path to configure itself, like Alex suggests. Absence of that property means no readyness check, and we can later define prefixes other than jcr for alternate mechanisms, if needed. What about merging this with Alex idea? We define properties for required bundles to be available and another one for the services. The sling main servlet (or some helper service) reads the props, and acts accordingly. This keeps everything in one single bundle and does not require any additional stuff. There's one additional requirement ;-) It should be easy for developers to augment this configuration when installing additional services, without having to restart Sling. When adding a bundle that provides a Foo service, for example, I can easily add a node under /system/sling/status, but modifying sling.properties is harder, and less visible. We can still probably combine those ideas, maybe something like: sling.readyness.check = jcr:/system/sling/status sling.readyness.check.1 = bundles:mybundleA, mybundleB sling.readyness.check.2 = services:myServiceA, myServiceB in sling.properties. The SystemStatus service should then indicate, in log messages, where it gets the actual list of things to check. Hmm, not sure if I really understand this requirement :) You have a running system which is ready. Then you install *additional* bundles and the system might be in the state not ready after adding additional stuff? Sounds a little bit strange to me. Carsten -- Carsten Ziegeler cziege...@apache.org
Re: SLING-490, SystemStatus service discussion
Bertrand Delacretaz wrote: On Mon, Jun 15, 2009 at 3:37 PM, Carsten Ziegelercziege...@apache.org wrote: ... There's one additional requirement ;-) It should be easy for developers to augment this configuration when installing additional services, without having to restart Sling. When adding a bundle that provides a Foo service, for example, I can easily add a node under /system/sling/status, but modifying sling.properties is harder, and less visible. We can still probably combine those ideas, maybe something like: sling.readyness.check = jcr:/system/sling/status sling.readyness.check.1 = bundles:mybundleA, mybundleB sling.readyness.check.2 = services:myServiceA, myServiceB in sling.properties. The SystemStatus service should then indicate, in log messages, where it gets the actual list of things to check. Hmm, not sure if I really understand this requirement :) You have a running system which is ready. Then you install *additional* bundles and the system might be in the state not ready after adding additional stuff? Sounds a little bit strange to me It's for the next startup - as I have added the Foo service, I want the system to wait for it to be ready on the next startup. Hmm, but that's still strange - without a restart the check is not enforced but with a restart it is? I think if this is the desired behaviour changing the properties is appropriate. On a different thing, OSGi is all about packages and services (bundles are just the way of bundling them - more or less). As services are based on interfaces and therefore packages, it should be enough to just check for the availability of services. Carsten -- Carsten Ziegeler cziege...@apache.org
Re: SLING-490, SystemStatus service discussion
Alexander Klimetschek wrote: On Mon, Jun 15, 2009 at 3:25 PM, Bertrand Delacretazbdelacre...@apache.org wrote: On Mon, Jun 15, 2009 at 3:18 PM, Carsten Ziegelercziege...@apache.org wrote: Bertrand Delacretaz wrote: sling.readyness.check = jcr:/system/sling/status to indicate that the readyness check must use JCR nodes under that path to configure itself, like Alex suggests. Absence of that property means no readyness check, and we can later define prefixes other than jcr for alternate mechanisms, if needed. What about merging this with Alex idea? We define properties for required bundles to be available and another one for the services. The sling main servlet (or some helper service) reads the props, and acts accordingly. This keeps everything in one single bundle and does not require any additional stuff. There's one additional requirement ;-) It should be easy for developers to augment this configuration when installing additional services, without having to restart Sling. When adding a bundle that provides a Foo service, for example, I can easily add a node under /system/sling/status, but modifying sling.properties is harder, and less visible. We can still probably combine those ideas, maybe something like: sling.readyness.check = jcr:/system/sling/status sling.readyness.check.1 = bundles:mybundleA, mybundleB sling.readyness.check.2 = services:myServiceA, myServiceB in sling.properties. The SystemStatus service should then indicate, in log messages, where it gets the actual list of things to check. Why not use OSGi properties, as suggested? They are persisted, so after the next restart they will be applied (these settings only makes sense after restarts, right?), and people can choose whether they will use the OSGi config API, Felix webconsole or config nodes in the JCR to change the settings (in order of availability). Hmm not sure what you exactly mean by OSGi properties? If you mean configurations managed by the config admin, you have the problem that they might either not be delivered at all or might be delivered at the wrong point of time. Carsten -- Carsten Ziegeler cziege...@apache.org
Re: SLING-490, SystemStatus service discussion
Alexander Klimetschek wrote: Could you elaborate? Does this mean the SlingMainServlet (or the SlingStatus service if we separate it) could be activated without the configuration available? I couldn't believe that as it sounds like it would lead to lots of problems when services don't get their configuration... Now, this depends on how this is done. We're using the declarative services in Sling, so when DS is starting the sling main servlet it checks for a configuration to provide it to the service. If it is there, fine. However at this point of time, the ConfigAdmin service might not have been startet yet, or if for example the configuration is installed using jcrinstall, jcr install might kick in later, pass the config to the config admin and then the servlet is restarted with the config. Therefore there might be a time, where the servlet is active without having the config you want it to have. Of course, you can handle this case by taking care of it - which is with DS a little bit difficult or...as soon as DS 1.1 is available (which should be very shortly), you have the possibility to require a service to have a configuration stored in ConfigAdmin. So the sling main servlet would not start without it. However obviously this has another draw back as someone has to take care that the config is there. Therefore, the easiest thing for me seems to be the sling properties. They're guaranteed to be delivered to the sling main servlet as soon as the service can be started. And the props do not change over time. Carsten -- Carsten Ziegeler cziege...@apache.org
Re: SLING-490, SystemStatus service discussion
Bertrand Delacretaz wrote: The ideal case would be for the system to go from ready to not ready when you install an additional bundle, but that's harder to implement so I'd like to keep that for later, if needed. Hmm, no I don't think so - it should not be up to the bundle to define that it is required. it's the app administrator deciding this - so the information if a bundle/package/service is required should not come out of a bundle. About properties vs. nodes...the initial content loading mechanism seems perfectly suited to add the require nodes when a bundle is installed, and remove them when it goes away (IIRC it does that), so that sounds like the simplest thing to do for user bundles. Yeah, but that only would work if your sling installation has a repository :) Carsten -- Carsten Ziegeler cziege...@apache.org
Re: SLING-490, SystemStatus service discussion
Alexander Klimetschek wrote: On Mon, Jun 15, 2009 at 5:10 PM, Carsten Ziegelercziege...@apache.org wrote: Now, this depends on how this is done. We're using the declarative services in Sling, so when DS is starting the sling main servlet it checks for a configuration to provide it to the service. If it is there, fine. However at this point of time, the ConfigAdmin service might not have been startet yet Really? Other services are started albeit the presence of the (non-started) ConfigAdmin? That means services are started and then stopped again once the configadmin is running and they get restarted with their configuration? Yes, I think so - although this is more theory; but it can happen, and I guess it depends how the SCR is implemented; if it requires a config admin, the config admin is of course started first. I think this is the case for the Felix implementation. Does jcr install re-set all the values on startup? I thought it would behave like this: 1) system running, no system-ready config present 2) configure system-ready service via a config node in JCR 3) system-ready service is restarted, config is applied and config is persisted by Apache Felix Yepp. 3) this has no effect on the running system (system-ready is already true, needs a global state variable) 4) restart 5) SlingMainServlet / system-ready service are started with the persisted config (here we have a list of deps to check), system-ready = false 6) waits for the deps to be running 7) finally after some time, system-ready = true Yes, but this means that the whole thing doesn't work without restarting. So on a first start the system pretents to be ready immediately which is imho wrong. And if jcr install is not started for whatever reason, the system remains ready regardless how often you restart it. As soon as we have a dependency between the service checking and the configuration what to check, we might ran into problems. As soon as the configuration is not available the system is ready. So the sling main servlet would not start without it. However obviously this has another draw back as someone has to take care that the config is there. Therefore, the easiest thing for me seems to be the sling properties. They're guaranteed to be delivered to the sling main servlet as soon as the service can be started. And the props do not change over time. Would be working as well, but they are not so easy to find, modify and deploy. Hmm I could argue that using a notepad to edit a properties file is as easy as using some jcr explorer to find/edit nodes in the repository. In the first case you have to know the location of the sling.properties file in the second case you have to know the path in the repository. So there is no difference about the required knowledge. And editing is well a matter of taste although I still think that using notepad is more comfortable than using one of the jcr explorers. But again, storing the system check in the repository doesn't work in the general case. If the repository is not available for whatever reason the system check succeeds and that's plainly something you don't want. Carsten -- Carsten Ziegeler cziege...@apache.org
[jira] Commented: (SLING-490) SlingStatusServlet - find out whether a Sling application is ready after startup
[ https://issues.apache.org/jira/browse/SLING-490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12719310#action_12719310 ] Carsten Ziegeler commented on SLING-490: I'm not very happy about this tight coupling - we require another bundle just to check if the system is ready. So even if all really required bundles are available but for any reason the system status bundle is not available, the system is not running anymore. Sounds a little bit strange to me. In addition I'm using a minimal setup of Sling (without any scripting support - for the portlet environment), so whatever we do these environments should be supported as well. SlingStatusServlet - find out whether a Sling application is ready after startup Key: SLING-490 URL: https://issues.apache.org/jira/browse/SLING-490 Project: Sling Issue Type: Improvement Components: Engine Reporter: Bertrand Delacretaz Priority: Minor Being discussed in http://markmail.org/message/jtdnqneoudxbmb6k -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Make our first release available on central Maven repo? (was: Problems with dependency paths)
Felix Meschberger wrote: Hi, Yes at the time of our first release poddlings had to deploy to the incubator repository at http://people.apache.org/repo/m2-incubating-repository And, yes, I agree we should probably deploy this to central, now. Central being managed through the Nexus repository nowadays, it would probably be easiest to see how to deploy to there. My first try to would be to checkout the Sling 3 tag and deploy it to repository.apache.org setting the altDeploymentRepository property appropriately. Carsten, would that be correct ? Yes, that should do the trick. The tag has externals to the released modules. Good idea! Carsten -- Carsten Ziegeler cziege...@apache.org
[jira] Assigned: (SLING-987) Jobs/Events are purged in an uncontrolled way
[ https://issues.apache.org/jira/browse/SLING-987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler reassigned SLING-987: -- Assignee: Carsten Ziegeler Jobs/Events are purged in an uncontrolled way - Key: SLING-987 URL: https://issues.apache.org/jira/browse/SLING-987 Project: Sling Issue Type: Bug Components: Event Reporter: Philipp Koch Assignee: Carsten Ziegeler Priority: Blocker We already had this problem for pretty big event/job queues once (a month ago or so. could not find a jira issue) that the job in the queue got purged because the job acknowledge timed out for that job (by default the job/event is purged after 3 timeouts). the above mentioned fix fixed the issue quite well. it appeared now again when running such big queues on very fast boxes: 9.05.2009 13:00:07.904 *INFO* [pool-4-thread-1] org.apache.sling.event.impl.JobEventHandler No acknowledge received for job org.osgi.service.event.Event [topic=com/day/cq/workflow/job] stored at /var/eventing/jobs/com.day.cq.workflow.job/Job5a50f993-8f36-4eae-81d5-3124ca455bf5. Requeueing job. the funny thing is now that the timeout does not happen after hours but already after 10 mins. there are no (debug) log entries that would point to some event handler problems... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-987) Jobs/Events are purged in an uncontrolled way
[ https://issues.apache.org/jira/browse/SLING-987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated SLING-987: --- Affects Version/s: Extensions Event 2.0.4 Fix Version/s: Extensions Event 2.0.6 It seems that this problem is caused by massive job events being sent from the event admin - the current thread pool used for the eventing has a maximum queue size of 50; as soon as this limit is reached the request for putting something into the queue is blocked until a place gets available inside the queue. Jobs/Events are purged in an uncontrolled way - Key: SLING-987 URL: https://issues.apache.org/jira/browse/SLING-987 Project: Sling Issue Type: Bug Components: Event Affects Versions: Extensions Event 2.0.4 Reporter: Philipp Koch Assignee: Carsten Ziegeler Priority: Blocker Fix For: Extensions Event 2.0.6 We already had this problem for pretty big event/job queues once (a month ago or so. could not find a jira issue) that the job in the queue got purged because the job acknowledge timed out for that job (by default the job/event is purged after 3 timeouts). the above mentioned fix fixed the issue quite well. it appeared now again when running such big queues on very fast boxes: 9.05.2009 13:00:07.904 *INFO* [pool-4-thread-1] org.apache.sling.event.impl.JobEventHandler No acknowledge received for job org.osgi.service.event.Event [topic=com/day/cq/workflow/job] stored at /var/eventing/jobs/com.day.cq.workflow.job/Job5a50f993-8f36-4eae-81d5-3124ca455bf5. Requeueing job. the funny thing is now that the timeout does not happen after hours but already after 10 mins. there are no (debug) log entries that would point to some event handler problems... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-987) Jobs/Events are purged in an uncontrolled way
[ https://issues.apache.org/jira/browse/SLING-987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12718372#action_12718372 ] Carsten Ziegeler commented on SLING-987: I've set the queue size to unlimited in Revision 783711 Jobs/Events are purged in an uncontrolled way - Key: SLING-987 URL: https://issues.apache.org/jira/browse/SLING-987 Project: Sling Issue Type: Bug Components: Event Affects Versions: Extensions Event 2.0.4 Reporter: Philipp Koch Assignee: Carsten Ziegeler Priority: Blocker Fix For: Extensions Event 2.0.6 We already had this problem for pretty big event/job queues once (a month ago or so. could not find a jira issue) that the job in the queue got purged because the job acknowledge timed out for that job (by default the job/event is purged after 3 timeouts). the above mentioned fix fixed the issue quite well. it appeared now again when running such big queues on very fast boxes: 9.05.2009 13:00:07.904 *INFO* [pool-4-thread-1] org.apache.sling.event.impl.JobEventHandler No acknowledge received for job org.osgi.service.event.Event [topic=com/day/cq/workflow/job] stored at /var/eventing/jobs/com.day.cq.workflow.job/Job5a50f993-8f36-4eae-81d5-3124ca455bf5. Requeueing job. the funny thing is now that the timeout does not happen after hours but already after 10 mins. there are no (debug) log entries that would point to some event handler problems... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-1002) Reduce memory consumption and improve startup behaviour of the job handler
Reduce memory consumption and improve startup behaviour of the job handler -- Key: SLING-1002 URL: https://issues.apache.org/jira/browse/SLING-1002 Project: Sling Issue Type: Improvement Components: Event Affects Versions: Extensions Event 2.0.4 Reporter: Carsten Ziegeler Currently the job handler holds all received jobs in memory until the job has been processed completly. In addition on startup all unprocessed jobs are loaded from the repository. If for example thousands of jobs are unprocessed in the repository and a new instance is started (or restarted) all these events are first load into memory and then put into the queue. It would be better to have a fixed max size for the in memory queue - and check the repository from time to time for unprocessed jobs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-917) Use repository.apache.org for deployments
[ https://issues.apache.org/jira/browse/SLING-917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12718001#action_12718001 ] Carsten Ziegeler commented on SLING-917: Added a profile for rat and the ianal plugin to check legal files in revision 783270 Use repository.apache.org for deployments - Key: SLING-917 URL: https://issues.apache.org/jira/browse/SLING-917 Project: Sling Issue Type: Task Components: General Affects Versions: Parent 5 Reporter: Bertrand Delacretaz Fix For: Parent 6 Attachments: SLING-917.patch See INFRA-1896 for getting access to repository.apache.org . Once that's done, we'll need to configure http://vmbuild.apache.org to push snapshots there. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Caching for ResourceResolver.map()
Jukka Zitting wrote: Hi, I have a case where we're doing lots of reverse mappings with the ResourceResolver.map() method and all the repository accesses caused by that are hurting performance. In general I'm not a big fan of extra caching, but in this case it seems like the only easy way to solve the problem. Would it make sense to embed such caching into JcrResourceResolver2 or should it rather be a separate add-on layer? The former approach would avoid complexities with the HttpServletRequest argument affecting the caching, while the latter would make it easier to only apply the caching in limited cases where it's truly needed (though at the cost of the cache not being global). While caching in the resource resolver might be a good idea anyway, perhaps caching one layer above might give even more benefit. Instead of querying the resource resolver a lot, caching above the resolver would even avoid querying the resolver. Carsten -- Carsten Ziegeler cziege...@apache.org
Re: Moving rewriter to contrib
Bertrand Delacretaz wrote: Hi Carsten, On Tue, Jun 9, 2009 at 2:17 PM, Carsten Ziegelercziege...@apache.org wrote: ...I'm planning to move this from the whiteboard to the contrib section. If noone objects, I'll do this in the next days In principle I'm all for it, but http://svn.apache.org/repos/asf/incubator/sling/whiteboard/rewriter/src/test returns a 404 ;-) :) Can I haz tests? Or maybe a simple smoke-test-the-whole-thing test in launchpad/testing is easier? I guess testing this in launchpad should be easier. Regards Carsten -- Carsten Ziegeler cziege...@apache.org
Re: Continuum or Hudson?
I don't care which one we use - as long as it is working and not spamming the mailing list :) (like the Felix Bamboo does as it sends a mail with each build which is triggered by each commit). And I agree to just use one server :) As people here seem to prefer Hudson, lets use that one. Carsten Bertrand Delacretaz wrote: Hi, We currently have two continuous integration setups for Sling: Continuum: http://vmbuild.apache.org/continuum/projectGroupSummary.action?projectGroupId=53 Hudson: http://hudson.zones.apache.org/hudson/view/Sling/ I don't have much experience with Continuum, but every time I try to do something on vmbuild it's very slow and painful. Seems like that box is overburdened, and the UI is not very easy to use, IMHO. The Hudson setup, OTOH, took me only about an hour of work from scratch, with no previous knowledge of Hudson, and has been running smoothly ever since. Including automatically picking up changes in parent POMs when new modules are created or whem modules are moved, which is very convenient. The overall experience has been much better for me. I don't think we need two CI servers - what do people think of dropping Continuum, and keeping only Hudson? -Bertrand -- Carsten Ziegeler cziege...@apache.org
Moving rewriter to contrib
Hi, I've added a new bundle in our whiteboard: the rewriter. The rewriter bundle allows to rewrite the output from Sling. It is possible to configure a pipeline (based on SAX events) which processes the whole output. This pipeline can be used for various use cases, like checking the links in the content, adding stuff, using xslt to generate different output etc. I'm planning to move this from the whiteboard to the contrib section. If noone objects, I'll do this in the next days. WDYT? Carsten -- Carsten Ziegeler cziege...@apache.org
Re: Moving rewriter to contrib
Torgeir Veimo wrote: 2009/6/9 Carsten Ziegeler cziege...@apache.org: I've added a new bundle in our whiteboard: the rewriter. The rewriter bundle allows to rewrite the output from Sling. It is possible to configure a pipeline (based on SAX events) which processes the whole output. This pipeline can be used for various use cases, like checking the links in the content, adding stuff, using xslt to generate different output etc. I'm planning to move this from the whiteboard to the contrib section. If noone objects, I'll do this in the next days. Could it possibly be used to allow page decoration by configuration? Eg. add a header / footer to all pages at url /a/b/c? Yes, pipelines are configured in the repository. You can configure as many as you want. The configured pipelines are tried to be matched against the current request. One criteria is the content type of the page, another one is the path (maybe we need to extend this for other use cases). So you can configure an own pipeline for all pages at /a/b/c which adds header and footer through a transformer. This should be fairly easy. Regards Carsten -- Carsten Ziegeler cziege...@apache.org
[jira] Updated: (SLING-994) DefaultGetServlet shoud not use sendError when response is already committed
[ https://issues.apache.org/jira/browse/SLING-994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated SLING-994: --- Affects Version/s: (was: Scripting JSP-Taglib 2.0.4) Servlets Get 2.0.4 DefaultGetServlet shoud not use sendError when response is already committed Key: SLING-994 URL: https://issues.apache.org/jira/browse/SLING-994 Project: Sling Issue Type: Bug Components: Servlets Get Affects Versions: Servlets Get 2.0.4 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Servlets Get 2.0.6 If no renderer servlet is found in the DefaultGetServlet, it calls sendError(). If this is an included request, sendError usually fails as the response is already committed. In this case it's hard to detect the underlying problem. Therefore I suggest to check if this is an included request and in this case throw a ServletException I'm not in favour of checking for response isCommitted as this is more unpredictable -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (SLING-994) DefaultGetServlet shoud not use sendError when response is already committed
[ https://issues.apache.org/jira/browse/SLING-994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-994. -- Resolution: Fixed If the request is included, do not use sendError but throw an exception if no renderer is found - changed in Revision 783017 DefaultGetServlet shoud not use sendError when response is already committed Key: SLING-994 URL: https://issues.apache.org/jira/browse/SLING-994 Project: Sling Issue Type: Bug Components: Servlets Get Affects Versions: Servlets Get 2.0.4 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Servlets Get 2.0.6 If no renderer servlet is found in the DefaultGetServlet, it calls sendError(). If this is an included request, sendError usually fails as the response is already committed. In this case it's hard to detect the underlying problem. Therefore I suggest to check if this is an included request and in this case throw a ServletException I'm not in favour of checking for response isCommitted as this is more unpredictable -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Sling configuration
Bertrand Delacretaz wrote:
Hi,
On Tue, Jun 9, 2009 at 1:58 PM, Claude
Vedoviniclaude.vedov...@gmail.com wrote:
Thus given the system poroperty sling.home.prefix is set to
/var/sling. In this case the default sling.home for the /sling/i1 web
app would be /var/sling/_sling_i1.
Would such a prefix suit your needs ?
That would certainly do, but why introduce a new concept?
Let's say that the sling.home property in the sling.property file, the
sling.home init-param in the web.xml and the sling.home system
property override each others (in this order) and they all specify the
root where each deployed sling servlet is going to create its
workspace.
I agree that having a single sling.home property would be simpler, so why not
sling.home = ./sling/{1}
by default, where {1} is replaced by the (suitably escaped)
SlingServlet's context path?
This would make things fully configurable, while allowing multiple
instances of the SlingServlet to each have their own storage folder.
I think this opens a door for misconfigurations. What happens if someone
forgets
about this {1} when configuring the system property and there are
several sling instances?
I think using the prefix as Felix suggested is much easier.
Regards
Carsten
--
Carsten Ziegeler
cziege...@apache.org
Re: Openid integration for Sling 3
Tanmay Barman wrote: Hi all, I was trying to integrate openid in my project that is based on sling 3. I was trying with openid4java api. But I am having the following error java.lang.NoClassDefFoundError: org/apache/commons/httpclient/methods/RequestEntity Hi, the class in question has been added to httpclient in version 3.0, so you need to add commons httpclient 3.1 or similar to your bundles. Regards Carsten at org.apache.sling.samples.jcrdev.servlets.SampleConsumerServlet.authRequest(SampleConsumerServlet.java:93) at org.apache.sling.samples.jcrdev.servlets.SampleConsumerServlet.doPost(SampleConsumerServlet.java:67) at org.apache.sling.samples.jcrdev.servlets.SampleConsumerServlet.doGet(SampleConsumerServlet.java:59) at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) at org.apache.sling.engine.impl.request.RequestData.service(RequestData.java:462) at org.apache.sling.engine.impl.SlingMainServlet.processRequest(SlingMainServlet.java:419) at org.apache.sling.engine.impl.filter.RequestSlingFilterChain.render(RequestSlingFilterChain.java:48) at org.apache.sling.engine.impl.filter.AbstractSlingFilterChain.doFilter(AbstractSlingFilterChain.java:54) at org.apache.sling.engine.impl.debug.RequestProgressTrackerLogFilter.doFilter(RequestProgressTrackerLogFilter.java:59) at org.apache.sling.engine.impl.filter.AbstractSlingFilterChain.doFilter(AbstractSlingFilterChain.java:52) at org.apache.sling.engine.impl.SlingMainServlet.service(SlingMainServlet.java:273) at org.apache.sling.engine.impl.SlingMainServlet.service(SlingMainServlet.java:171) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:362) at org.ops4j.pax.web.service.internal.HttpServiceServletHandler.handle(HttpServiceServletHandler.java:51) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:722) at org.ops4j.pax.web.service.internal.HttpServiceContext.handle(HttpServiceContext.java:87) at org.ops4j.pax.web.service.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:63) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139) at org.mortbay.jetty.Server.handle(Server.java:324) at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:505) at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:828) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:514) at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380) at org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:228) at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:450) I have also included commons-httpclient-2.0.2.jar in my felix environment. If anyone has some idea about that problem please let me know. Regards, Tanmay -- Carsten Ziegeler cziege...@apache.org
Re: Exposing DB Data
Hi Andreas, Andreas Kollegger wrote: Hi, I'd like to expose data stored in an external database as resource nodes in Sling. Access to the database is already wrapped in an OSGi service (MyService.java), and there is a Java model for the data (MyModel.java). From what I can understand from reading the examples, searching the mailing list and looking at documentation, the steps to integrate with Sling could be: 1. MyResourceProvider implements ResourceProvider - bridge to MyService for getting data rows - provider.roots = /my/resources/ - sub-path of root used to select row in table (/my/resources/3245.html retrieves row index 3245 as Resource) - listChildren() of root would list all database rows (probably add query params to limit number of rows returned) - getResource() returns a MyResourceWrapper 2. MyResourceWrapper implements Resource - wraps MyModel - resourceType = my/Model - adaptable to javax.jcr.Node (exposing columns as node properties) it depends on your application (code) but I think making your resource adaptable to ValueMap (jcr resources are adaptable to value map as well) is more generic. It allows you to access different kind of resources (backed by jcr, backed by your db provider) in a unique way. And the ValueMap interface is easier to use than jcr Node :) That would take care of read access to the data. I can then easily add scripts to render the data as appropriate. Sounds good to me :) Write access is a little less clear to me. I'd like to have a servlet which handles json, xml or form POSTs for anything submitted to the path of my ResourceProvider. I think I need to do this: 1. MyResourceTypeProvider implements JcrResourceTypeProvider - provider.roots = /my/resources - any node below the root is returned as resourceType my/Model, otherwise return null 2. MyPostServlet extends SlingAllMethodsServlet - registered to handle nodes of type my/Model - override doPost() to handle data based on content-type - creates new database entries using MyService That would allow the creation of a new database row by posting an appropriate json or xml file to /my/resource/*.html . For the form data, I'd conform to the SlingPostServlet interface to remain compatible with generic node editing. Am I thinking about this correctly, or is their a more appropriate Sling-Way? Hmm not sure :) I guess your idea should work. Now, for updating db data it should already work if your resource is adaptable to PersistableValueMap. For adding/deleting resources something like the above might work. We are thinking of extending the resource provider interface to get better support for these use cases. This is one of the topics for the near future, so maybe we should start thinking about this (again) now :) Regards Carsten -- Carsten Ziegeler cziege...@apache.org
[jira] Created: (SLING-994) DefaultGetServlet shoud not use sendError when response is already committed
DefaultGetServlet shoud not use sendError when response is already committed Key: SLING-994 URL: https://issues.apache.org/jira/browse/SLING-994 Project: Sling Issue Type: Bug Components: Servlets Get Affects Versions: Scripting JSP-Taglib 2.0.4 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Servlets Get 2.0.6 If no renderer servlet is found in the DefaultGetServlet, it calls sendError(). If this is an included request, sendError usually fails as the response is already committed. In this case it's hard to detect the underlying problem. Therefore I suggest to check if this is an included request and in this case throw a ServletException I'm not in favour of checking for response isCommitted as this is more unpredictable -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Clarification for ResourceResolver#map
Hi, how is the ResourceResolver#map method supposed to work or more precisly what input is expected. The javadoc mentions a resource path as input parameter. What is supposed to happen if the path contains a query string or an anchor? Regards Carsten -- Carsten Ziegeler cziege...@apache.org
Re: Clarification for ResourceResolver#map
Felix Meschberger wrote: Hi Carsten Carsten Ziegeler schrieb: how is the ResourceResolver#map method supposed to work or more precisly what input is expected. The javadoc mentions a resource path as input parameter. What is supposed to happen if the path contains a query string or an anchor? The query string is cut off IIRC before applying the mapping and appended again at the end. Great, I didn't find this in the code. Can you give me a pointer please? :) Regards Carsten The anchor is not currently handled, which might be considered a bug to be fixed. Actually the resource path may also contain appended selectors and extensions, which are also cut off at the beginning and reappended at the end. Regards Felix -- Carsten Ziegeler cziege...@apache.org
[jira] Closed: (SLING-984) Registered quartz scheduler should use unique name
[ https://issues.apache.org/jira/browse/SLING-984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-984. -- Resolution: Fixed The scheduler is now registered with a unique run id. In revision 778362 I've also updated to the latest available quartz version Registered quartz scheduler should use unique name -- Key: SLING-984 URL: https://issues.apache.org/jira/browse/SLING-984 Project: Sling Issue Type: Bug Components: Commons Scheduler Affects Versions: Commons Scheduler 2.0.4 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Commons Scheduler 2.0.6 The registered quartz scheduler always uses the default scheduler name - which results in problems if - for whatever reason - the deactivate method (and therefore the unregistering) hasn't been called or if the bundle is running more than once. Quartz does not allow to register the same scheduler name more than once. It seems - although the library is embedded in the bundle - that this name is registered somewhere outside of the bundle scope which therefore causes these problems. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (SLING-979) Make Sling HTTP Servlet Request and Response Adaptable
[ https://issues.apache.org/jira/browse/SLING-979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-979. -- Resolution: Fixed Fix Version/s: API 2.0.6 Thanks, looks great Felix, therefore closing this bug. Make Sling HTTP Servlet Request and Response Adaptable -- Key: SLING-979 URL: https://issues.apache.org/jira/browse/SLING-979 Project: Sling Issue Type: New Feature Components: API Affects Versions: API 2.0.4 Reporter: Carsten Ziegeler Assignee: Felix Meschberger Fix For: API 2.0.6 It would be nice if the SlingHttpServletRequest and SlingHttpServletResponse would extend the Adaptable interface. Adapting the request/response is interesting in several situations. For example, in a portlet environment the req/response could be easily adapted to the Portlet request/response. Or if Sling is used in combination with another web framework the request/response could be easily adapted to the corresponding objects of that particular framework. Another use case is the rewriter (in the whiteboard currently) which makes the response adaptable to a ContentHandler which receives SAX events. This allows direct streaming of XML events from within Sling without the need of creating an output stream and later on reparsing. As the request and response object are implemented using the wrappers, extending the interface does not create problems. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [DISCUSS] Use repository.a.o for deployments
+1 The only problem I can see with this atm is the definition of the assembly plugin which caused us a lot of trouble in the Pluto release. Once the assembly plugin is configured in the parent pom, child poms are not able to override it (this will be fixed in an upcomming release, however today this can be a pain if you have different modules with different assemblies). But that's a minor issue we can sort out. Regards Carsten Felix Meschberger wrote: Hi all, Lets pick up the repository.a.o discussion again now that we have released Sling 5. I have created a patch for our parent pom and attached it to the tracker issue SLING-917 [1]. The important changes: * Use Apache parent pom 6 * Drop most of our apache-release profile (formerly known as release profile) * Drop some plugins in the pluginManagement section * Drop repositories and pluginRepositories sections Using the Nexus repository at repository.a.o has the massive advantage that the release process is drastically simplified: A release is uploaded to a staging repository where it can be reviewed for the vote. When the vote has passed, the staging repository can easily be deployed. There is a catch to this, though: The SVN password and GPG passphrase have to be stored in the Maven 2 settings file for the release process to work correctly. Starting with Maven 2.1 the SVN password file is said to be supported in encrypted form, but the GPG passphrase issue still remains. Weighing the advantages against the disadvantages, I tend to prefer the ease of deployment in this case. Next steps after discussion : * Vote on this issue * Have the repository.a.o team setup Sling for Nexus deployment * Release the Sling parent pom 6 * Update references in projects to the new parent pom * and so on ... WDYT ? Regards Felix [1] https://issues.apache.org/jira/browse/SLING-917 -- Carsten Ziegeler cziege...@apache.org
Re: [VOTE] Release Apache Sling MIME type mapping support Version 2.1.0-incubator
+1 Carsten -- Carsten Ziegeler cziege...@apache.org
[jira] Created: (SLING-979) Make Sling HTTP Servlet Request and Response Adaptable
Make Sling HTTP Servlet Request and Response Adaptable -- Key: SLING-979 URL: https://issues.apache.org/jira/browse/SLING-979 Project: Sling Issue Type: New Feature Components: API Affects Versions: API 2.0.4 Reporter: Carsten Ziegeler It would be nice if the SlingHttpServletRequest and SlingHttpServletResponse would extend the Adaptable interface. Adapting the request/response is interesting in several situations. For example, in a portlet environment the req/response could be easily adapted to the Portlet request/response. Or if Sling is used in combination with another web framework the request/response could be easily adapted to the corresponding objects of that particular framework. Another use case is the rewriter (in the whiteboard currently) which makes the response adaptable to a ContentHandler which receives SAX events. This allows direct streaming of XML events from within Sling without the need of creating an output stream and later on reparsing. As the request and response object are implemented using the wrappers, extending the interface does not create problems. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (SLING-902) add java annotation support for sling scr components/servlets
[
https://issues.apache.org/jira/browse/SLING-902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler closed SLING-902.
--
Resolution: Won't Fix
We'll add the annotations directly in the Felix scr-annotations project (see
FELIX-1056)
add java annotation support for sling scr components/servlets
-
Key: SLING-902
URL: https://issues.apache.org/jira/browse/SLING-902
Project: Sling
Issue Type: New Feature
Components: Servlets Resolver
Reporter: Stefan Seifert
Attachments: 090329_sling_scr_annotations.zip
please note: this proposal depends on a felix-scr-plugin proposal described in
https://issues.apache.org/jira/browse/FELIX-1010
with the described scr plugin enhancement it is possible to define SCR
component definitions via annotations. furthermore it is possible for
felix/SCR based projects to define their own and less verbose annotations for
specific need, together with a provider class mapping them to the SCR tags
needed by the plugin internally.
the attached zip file provides such a implemented for one new annotation
SlingServlet, see example below.
i was not sure into which project and classpath this classes should be
placed, so i attached a ZIP file for discussion and try-out. the best
solution would be to split them up into two projects - one project containing
only the annotation, and the other containing the provider and tag mapping.
the first project has no dependencies and can be referenced by any other
project needing the annotation. the second has to import the felix-scr-plugin
as dependency, this results in a lot of transitive dependency not to be
wished in a normal project.
Example
---
QDox version:
/**
* Sample servlet with sling mappings.
*
* @scr.component immediate=true
* @scr.service interface=javax.servlet.Servlet
* @scr.property name=sling.servlet.methods value=GET
* @scr.property name=sling.servlet.resourceTypes
* value=/apps/test/components/samplecomponent
* @scr.property name=sling.servlet.extensions values.0=html
values.1=json
*/
public class SlingServletQDox implements Servlet {
Annotation version:
/**
* Sample servlet with sling mappings.
*/
@SlingServlet(methods = GET, resourceTypes =
/apps/test/components/samplecomponent, extensions = { html, json })
public class SlingServletAnnotation implements Servlet {
Custom annotation mappings can be integrated by defining a class implementing
org.apache.felix.scrplugin.tags.annotation.AnnotationTagProvider for the
new plugin property annotationTagProviders in the pom.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: AW: update launchpad/bundles/pom.xml to SNAPSHOT versions?
Felix Meschberger wrote: Hi, How about this: I created SLING-972 [1] as a standing task issue for the next collection release. Whenever a bundle is modified, the launchpad/bundles module should be checked whether the reference to the latest snapshot is already contained and under the label of SLING-972 update the reference if required. Hmm, not sure :) Updating the launchpad/bundles pom to a snapshot means that this bundle will be released for the next Sling release. But I guess there are cases where one wants to work for a longer time on a bundle and once this is finished it should be in the release, but not during the development. Therefore I think all automatisms fail here; whenever someone thinks that a new bundle is ready for release/inclusing in the release, update the dependency in the launchpad/bundles. So, +1 for SLING-972 with the exception that there are cases where the reference is not updated immediately when a bundle is changed. Carsten -- Carsten Ziegeler cziege...@apache.org
Re: AW: update launchpad/bundles/pom.xml to SNAPSHOT versions?
Bertrand Delacretaz wrote: On Mon, May 18, 2009 at 10:11 AM, Carsten Ziegeler cziege...@apache.org wrote: ...I think all automatisms fail here; whenever someone thinks that a new bundle is ready for release/inclusing in the release, update the dependency in the launchpad/bundles Why not, but I'd like the launchpad/testing module to always test the trunk - so it might need its own set of dependencies, independent of the launchpad/bundles module. It was like that originally, and that changed when the launchpad/bundles was created. The constraints of the launchpad/app and webapp modules (use stable stuff) are different from those of the launchpad/testing module (test the latest trunk) so we might want to go back and have launchpad/testing use its own set of bundles version numbers. WDYT? Ok, we can do this - so this is kind of doing like gump is doing its stuff. But I see the potential problem that we release our launchpad stuff which is never tested by the integration tests as they test some never stuff where problems might already be fixed/or different. Carsten -- Carsten Ziegeler cziege...@apache.org
Re: AW: update launchpad/bundles/pom.xml to SNAPSHOT versions?
Bertrand Delacretaz wrote: On Mon, May 18, 2009 at 10:57 AM, Carsten Ziegeler cziege...@apache.org wrote: Bertrand Delacretaz wrote: ...so we might want to go back and have launchpad/testing use its own set of bundles version numbers. WDYT? Ok, we can do this - so this is kind of doing like gump is doing its stuff. But I see the potential problem that we release our launchpad stuff which is never tested by the integration tests as they test some never stuff where problems might already be fixed/or different. This can be solved by (manually) running the launchpad/testing tests against an instance of Sling started by the app or webapp modules, like I did for the last release. Yes, sure, but I'm a friend of automated stuff, so they should run at least automated before we do the release. Carsten Some tests might fail if they have been created for trunk stuff that's not being released yet, but even in this case noting the differences will be useful. -Bertrand -- Carsten Ziegeler cziege...@apache.org
Re: [VOTE] Graduate Apache Sling as a top level project
+1 Carsten Felix Meschberger wrote: Hi all, After the second release and an ever growing community, I think we are ready to graduate from the Incubator. At the beginning we entered the Incubator sponsored by the Apache Jackrabbit project with the potential goal of graduating as a subproject to Jackrabbit. Over time, it showed, that Sling will have a life on its own and that the communities of Jackrabbit and Sling are sufficiently different. As a consequence the common opinion of the PPMC is that Sling might best graduate as an Apache Top Level Project. The PPMC has in the meantime held a vote on proposing the first PMC chair and I have updated the graduation-resolution-draft accordingly [1]. So here is the vote: [ ] +1 Graduate as a top level project [ ] 0 Don't care [ ] -1 Don't graduate yet, because The vote is open for the next 72 hours. Every vote is welcome, especially votes from our Mentors. Only votes from PPMC members are considered binding. Thanks and Regards Felix [1] http://cwiki.apache.org/SLING/graduation-resolution-draft.html -- Carsten Ziegeler cziege...@apache.org
Re: [RT] Generic scriptable launcher
While I see the value of a launcher - I don't think that this is the concern of Sling - we are the framework which should run in every OSGi installation; so let's focus on the framework and leverage other efforts like pax+runner, Karaf etc. instead of doing this stuff ourselves. Just my 2c Carsten Felix Meschberger wrote: Hi, Bertrand Delacretaz schrieb: I'm thinking of creating a generic launcher, using a text file definition to load and start jars, allowing a Sling launcher to take over and load and start bundles once a main class is started. This sounds a lot like Tanuki Java Service Wrapper ... Here's a rough idea - I haven't looked at Karaf closely yet, there's probably some overlap, but my idea is to create a generic Java launcher, having nothing to do with OSGi, that in turn launches an OSGi-aware main class. The launcher is a runnable jar, or a war file. It uses a text file named launch.txt to define what to launch, example below. # START launch.txt example properties: sling.home = ./sling org.apache.commons.launcher.protocols.maven.repository.1 = http://repo1.maven.org/maven2 org.apache.commons.launcher.protocols.maven.repository.2 = http://people.apache.org/repo/m2-incubating-repository protocols: # by default only the http and file protocol are provided to # load jar files, more can be added by loading protocol jars # The maven protocol, for example, grabs jar files from # repositories defined by the *.maven.repository properties # found above. jar http://some.repository/launcher-maven-protocol-1.4.2.jar md5=1231231239812cd21231987 bootstrap: # load a number of jars that are required to start the main class jar maven:org.apache.felix:org.osgi.compendium:jar:1.2.0 md5=1231231239812cd212315645 jar maven:org.apache.felix:org.osgi.core:jar:1.2.0 sha1=1231231239812cd21231123213 jar maven:org.apache.felix:org.osgi.foundation:jar:1.2.0 sha1=1231231239812cd2123112313 jar maven:org.apache.sling:org.apache.sling.launchpad.launcher:2.0.2-incubator md5=1231231239812cd2123112313 # now start the main class, from the org.apache.sling.launchpad.launcher jar main-class org.apache.sling.launchpad.launcher.Main -m launcher # The launcher stops processing here, and provides this file to the main class as its # standard input. The above launcher.Main processes the lines that follow the # above main-class statement # Load and start a few bundles, some with specific start levels bundle http://some.obr/some-bundle sha1=1231390890823121312 bundle maven:some.group:some.artifact:1.0 startlevel=2 md5=123213213984329843 # END launch.txt example Creating a launcher that will never change doesn't seem too hard, and then defining a Sling launchpad instance boils down to the launch.txt file. Using a text file to define bundles makes it easy for people to exchange configurations, as the text file fully defines the application assembly, based on the bundles URLs and digests. WDYT? At first I thought: What may this be used for. Maybe just because I failed to understand the problem for which you present a solution. Is this about creating custom Sling configurations ? Now, this is certainly a valid request, to which we currently have two answers: * The launchpad/bundles project defines a package of bundles to be included in the app or webapp binary * A patch to extend the BootstrapInstaller to read more bundles for installation from the filesystem Maybe we need an additional mechanism for setting up an initial set of bundles. Now, there's pax runner [1] which sports so called profiles, which may be exactly what you are envisioning ? While I like our current construct of having very small environment-specific code (web app or standalone app) and the rest being unified, we might also go for favouring the standalone app... Regards Felix [1] http://paxrunner.ops4j.org/space/Pax+Runner -Bertrand -- Carsten Ziegeler cziege...@apache.org
Re: [VOTE RESULT] Release Apache Sling 5
I've uploaded our release yesterday and Sling is now available from the central maven repository and our download page. Carsten -- Carsten Ziegeler cziege...@apache.org
Re: [RT] Generic scriptable launcher
Bertrand Delacretaz wrote: On Thu, May 14, 2009 at 8:47 AM, Carsten Ziegeler cziege...@apache.org wrote: ...While I see the value of a launcher - I don't think that this is the concern of Sling - we are the framework which should run in every OSGi installation; so let's focus on the framework and leverage other efforts like pax+runner, Karaf etc. instead of doing this stuff ourselves Agree, I was actually thinking of creating the launcher as an independent tool outside of Sling, maybe at Apache Commons. Just wanted to see how much people like it here, as that could be useful for our launchpad configurations. I personally would first evaluate if the existing solutions are sufficient or could be easily enhanced instead of creating another project. Carsten -- Carsten Ziegeler cziege...@apache.org
[ANN] New Release of Apache Sling 5
Bringing Back the Fun - Reloaded Apache Sling brings back the fun to Java developers and makes the life of a web developer much easier. It combines current state of the art technologies and methods like OSGi, REST, scripting, and JCR. The main focus of Sling deals with the important task of bringing your content into the web and providing a plattform to manage/update the content in a REST style. Sling is built into OSGi bundles and therefore benefits from all advantages of OSGi. On the development side a scripting layer (using Apache BSF) allows to use any scripting language with Sling (of course you can use plain old Java, too). And on top of this, Sling helps in developing an application in a RESTful way. As the first web framework dedicated to JSR-170 Java Content Repositories, Sling makes it very simple to implement simple applications, while providing an enterprise-level framework for more complex applications. Underneath the covers Apache Jackrabbit is used for the repository implementation. Download the new release, Apache Sling 5, today and give it a try! Apache Sling currently comes in four flavors: - A standalone application (a jar containing everything to get started with Sling) - A web application (just drop this into your favorite web container) - The full source package (interested in reading the source?) - Maven Artifacts (available through the Apache Incubator Repository) For more information, please visit the Apache Sling web site at http://incubator.apache.org/sling. or go directly to the download site at http://incubator.apache.org/sling/site/downloads.cgi The Apache Sling Community -- Carsten Ziegeler cziege...@apache.org
[jira] Commented: (SLING-960) Need webconsole smoke tests
[ https://issues.apache.org/jira/browse/SLING-960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12707987#action_12707987 ] Carsten Ziegeler commented on SLING-960: I don't want to prevent anyone from doing additional tests, but I think this is not the core business of Sling - the web console is just one way of managing an OSGi installation; and more important the web console is developed at another problem, so I can imagine it will be hard to keep track of changes and adjust the tests accordingly. Just my 2 cents, but if someone wants to add tests, welcome! Need webconsole smoke tests Key: SLING-960 URL: https://issues.apache.org/jira/browse/SLING-960 Project: Sling Issue Type: Test Components: Console Reporter: Bertrand Delacretaz Priority: Minor SLING-959 wasn't detected by our test suite, we should add some simple webconsole integration testing to catch such problems in the future. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-960) Need webconsole smoke tests
[ https://issues.apache.org/jira/browse/SLING-960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12708017#action_12708017 ] Carsten Ziegeler commented on SLING-960: Non-automated tests tend to be forgotten during the release process; and I still think this is not a blocker for a Sling release. Contributing the tests to the Felix project might make sense; however in this particular case, the problem arises because of a specific Felix version and a specifc web console version; other combinations work. Need webconsole smoke tests Key: SLING-960 URL: https://issues.apache.org/jira/browse/SLING-960 Project: Sling Issue Type: Test Components: Console Reporter: Bertrand Delacretaz Priority: Minor SLING-959 wasn't detected by our test suite, we should add some simple webconsole integration testing to catch such problems in the future. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-960) Need webconsole smoke tests
[ https://issues.apache.org/jira/browse/SLING-960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12708043#action_12708043 ] Carsten Ziegeler commented on SLING-960: Hmm, yes, but we are currently trying to get a big bang release from Sling out of the doors. Once this is through we can easily and quickly release single modules like the launchpad stuff. Need webconsole smoke tests Key: SLING-960 URL: https://issues.apache.org/jira/browse/SLING-960 Project: Sling Issue Type: Test Components: Console Reporter: Bertrand Delacretaz Priority: Minor SLING-959 wasn't detected by our test suite, we should add some simple webconsole integration testing to catch such problems in the future. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Sling 5 API Docs
Felix Meschberger wrote: Hi all, Now that the Sling release is approaching official status (pending Incubator PMC approval) I also published the aggregate API JavaDoc for this Sling 5 Source Release at [1] (Please allow for a few hours for the site to sync). I also linked to the API docs from the main navigation of the Site. Regards Felix [1] http://incubator.apache.org/sling/apidocs/sling5/index.html Can we later on have a tarball with the docs for download? Carsten -- Carsten Ziegeler cziege...@apache.org
Re: Releases in the future
Roy T. Fielding wrote: On May 11, 2009, at 12:03 PM, Felix Meschberger wrote: Carsten and I have been reasoning about the releases in the future, mainly the ones for end-users who just want to grab a binary and fire it off. Basically, we will start releasing single bundles using the regular ASF release process. This should enable us to release much quicker than with big release we have done until now. For the consumer releases we are talking about 4 projects mainly: * launchpad/base - contains the launcher code, Felix framework and the OSGi core and compendium libraries. * launchpad/bundles - a very simple project to just pack together existing bundles * launchpad/app, launchpad/webapp - projects to create final app and web app from the base and bundles projects So to release a consumer product we update the launchpad/bundles project with all the bundles we want to include and prepare the releases of the launchpad/bundles, launchpad/app and launchpad/webapp projects. I know this is kind of weird in the Apache World, but in essence these releases are not mainly targeted at developers and manual builders but at consumers, who just want to grab-and-run it. WDYT ? Apache only releases source code packages. Those other things you build are not releases -- they are binaries that individuals build and upload. Yes, that's right - now, we think that even for those things voting etc. is a good thing. While legaly everything might be correct, but I don't think that users are really able (or willing) to distinguish between a release (source) and a downloadable binary. So it makes sense that those binaries are checked and handled properly as well. Carsten -- Carsten Ziegeler cziege...@apache.org
[VOTE RESULT] Release Apache Sling 5
The vote to release Apache Sling 5 finished successfully with six +1 votes from: - Felix Meschberger (*) - Jukka Zitting (*) - Juan José Vázquez Delgado (*) - Vidar Ramdal (*) - Carsten Ziegeler (*) - Bertrand Delacretaz (*) The people marked with * are members of the PPMC No other votes were cast. Thanks for taking the time to check the release! Regards Carsten -- Carsten Ziegeler cziege...@apache.org
Re: [Vote] Release Apache Sling 5
+1 Carsten -- Carsten Ziegeler cziege...@apache.org
Re: Building trunk
Ian Boston wrote: :), Ignore me, I need to pull the appropriate tag and build locally while waiting for the release. Actually this was a good hint as I forgot to commit the updated poms yesterday evening :) Everything should point now to the next parent pom snapshot and allow a build without locally building something before again. Thanks Carsten Ian On 7 May 2009, at 12:07, Ian Boston wrote: Hi, I am trying to build trunk after the recent release and version increment. Before doing this I zapped ~/.m2/repository/org/apache/sling as a precaution, but I am seeing quite a variety of missing artifacts versions eg 2.0.4-incubator 5-incubator etc I suspect, if no one is seeing the same problems they might have the old artifacts in their local maven repo. Should these all be 6-incubator-SNAPSHOT and 2.0.5-incubator-SNAPSHOT everywhere or should there be a mixture ? I have a half a patch done but thought I should check. Ian -- Carsten Ziegeler cziege...@apache.org
Re: Building trunk
Obviously I was wrong of course, trunk is not buildable - this will be the case until we can make the release available in a public repository (and this will take at least another 4 days - but with the weekend inbetween this might be a little bit longer). Carsten -- Carsten Ziegeler cziege...@apache.org
Re: [IMP] End of Code freeze
Ok, I'm done with the maven stuff, so this ends the code freeze. Thanks Carsten -- Carsten Ziegeler cziege...@apache.org
[Vote] Release Apache Sling 4
Hello everyone, finally we have new release to vote on! You'll find the releases at: http://people.apache.org/~cziegeler/releases/sling I've created the same type of artifacts as for the last release. The main release is a release of the source tree with the version 4-incubator. For convenience we have two additional binary releases here: the launchpad app and webapp. The source release: sling-4-incubator-source-release.tar.gz ccfe4dc8245ee217c94e520b5c65da53 sling-4-incubator-source-release.zip 688c42f67e17bf23aca8405a2c5fcca8 The launchpad app: org.apache.sling.launchpad.app-4-incubator-bin.tar.gz a542e802f05c2fe5ab88202443f36b4a org.apache.sling.launchpad.app-4-incubator-bin.zip d03de1964b3795ea6f3ea237af157cc3 The launchpad webapp: org.apache.sling.launchpad.webapp-4-incubator.war 213cdc63159721b43485bb6728dd9450 In addition I've built the corresponding maven artifacts of all modules which can be found here: http://people.apache.org/~cziegeler/releases/sling/maven The KEYS file to check my signature is at http://people.apache.org/~cziegeler/releases/KEYS This is basically just one big release, so please cast your votes, the vote will be open for 72 hours. Thanks Carsten -- Carsten Ziegeler cziege...@apache.org
Re: [Vote] Release Apache Sling 4
Hi, we (Felix and I) have just found an issue with the source release. We hit (for the n-th time) a maven problem, wenn a reactor build is using different parent poms with different plugin versions. Our source release contains mostly new modules (referencing parent pom version 5) but also three modules we didn't releasee (parent pom version 3). This creates a conflict as only one of them is used to define plugin versions and may cause compilation/build problems. Therefore you should remove the following bundles from the reactor pom: - scripting api - jcr api - adapter I think we can live with this known issue and don't need to cut a new release. Only if we find more severe problems we should recut. Regards Carsten -- Carsten Ziegeler cziege...@apache.org
[jira] Commented: (SLING-957) JCR EventListeners are not easy to create or write
[ https://issues.apache.org/jira/browse/SLING-957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12706451#action_12706451 ] Carsten Ziegeler commented on SLING-957: I haven't locked at the patch yet, but nevertheless I'm in favour of a more generic/Sling like solution, taking the resource tree into account. Something along the lines of https://issues.apache.org/jira/browse/SLING-944 JCR EventListeners are not easy to create or write -- Key: SLING-957 URL: https://issues.apache.org/jira/browse/SLING-957 Project: Sling Issue Type: New Feature Components: JCR Reporter: Ian Boston Attachments: RegisterableEventManager.patch JCE EventListeners have some drawbacks in the current sling environment. Its relatively expensive to register them as each provider needs its own jcr session. Its not possible to register synchronous event listeners as this is part of the jackrabbit-server bundle. The patch to follow adds an EventManager to jackrabbit-server that ServiceTrack(s) a provider interface, registering InjectableEventListners as normal jcr event listeners or sync event listeners. This patch assumes that you trust all the code in the JVM and are happy giving bundles access to the JCR System Session. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (SLING-957) JCR EventListeners are not easy to create or write
Ian Boston wrote: Agreed, the reason for sharing this is we have some use cases that need to look at the node state prior to save. In the past (pre OSGi) we added these to the the jcr server component. Since this is now owned by Sling, we cant do that any more without patching the jackrabbit-server bundle. Obviously there needs to be a hook somewhere for this use case to be covered. The more generic event use case *is* better handled by the OSGi event service, especially where delivery is not expected to be on the same thread or even on the same cluster node. I could make this patch only for SynchronousEventsListeners. WDYT? Not sure :) You mention that you want to look at the node state prior to save, so maybe the SlingPostProcessor (post bundle) can help you? You can register these processors and they are invoked on a POST to Sling before the save is called. It allows you to make additional changes, revert them etc. Carsten -- Carsten Ziegeler cziege...@apache.org
[Vote] Release Apache Sling 5
Hello everyone, I redid the release, which is not version 5 and we can vote again :) You'll find the releases at: http://people.apache.org/~cziegeler/releases/sling I've created the same type of artifacts as for the last release. The main release is a release of the source tree with the version 4-incubator. For convenience we have two additional binary releases here: the launchpad app and webapp. The source release: sling-5-incubator-source-release.tar.gz 2d3f26b986b12e4c3863c8352508cc6c sling-5-incubator-source-release.zip e60241ee568f76872684348690b069d5 The launchpad app: org.apache.sling.launchpad.app-5-incubator-bin.tar.gz bce9be4df9de0bb8e3f856dc83034fdb org.apache.sling.launchpad.app-5-incubator-bin.zip c96face22c569d5795ea549f729e2294 The launchpad webapp: org.apache.sling.launchpad.webapp-5-incubator.war e5e7acb1d7140f10e8247a4076ca094c In addition I've built the corresponding maven artifacts of all modules which can be found here: http://people.apache.org/~cziegeler/releases/sling/maven The KEYS file to check my signature is at http://people.apache.org/~cziegeler/releases/KEYS This is basically just one big release, so please cast your votes, the vote will be open for 72 hours. Thanks Carsten -- Carsten Ziegeler cziege...@apache.org
Preparing the release
Hi, I just went through the list of all modules for the release (bundles, launchpad and maven plugins). From this list it seems that we haven't changed these modules (apart from cosmetic changes of the bundle name - but no functional changes): - bundles/extensions/adapter - bundles/jcr/api - bundles/jcr/jackrabbit-api - bundles/scripting/api - maven/maven-jcrocm-plugin So I think we shouldn't release those and just use the old released versions for the big downloadable release. Finally, we have the extensions/i18n bundle which we didn't release last time and which we are still not using/referencing. So we can either: a) release it as is b) don't release it c) don't release it and move to extensions From the list above I would prefer c). Carsten -- Carsten Ziegeler cziege...@apache.org
Re: svn commit: r771617 - in /incubator/sling/trunk/bundles/jcr: jackrabbit-accessmanager/pom.xml jackrabbit-usermanager/pom.xml
Felix Meschberger wrote: Hi, Shouldn't this rather be org.apache.jackrabbit:jackrabbit-api ? Hmm, yes - I'll check all references. Thanks Carsten -- Carsten Ziegeler cziege...@apache.org
Re: Event Listeners
Ian Boston wrote: Are there any facilities in sling for registering jcr event listeners ? Both the external javax.jcr.observation.EventListener and the SynchronousEventListener type. No we don't have extra support in Sling atm. One of the problems here is that the jcr listeners are tied to a session. But we're working on a resource based eventing which leverages the OSGi eventing: https://issues.apache.org/jira/browse/SLING-944 Carsten -- Carsten Ziegeler cziege...@apache.org
[IMP] Code freeze
Ok, I'l start with the release process - I fear that this will take a little bit longer this time (until tomorrow I guess). Please refrain from committing stuff in the meantime. During the release process the build will be broken as the it will reference artifacts which are not available in a public repo - but on my machine :) So stay tuned. Carsten -- Carsten Ziegeler cziege...@apache.org
Re: [IMP] Code freeze
Bertrand Delacretaz wrote: On Tue, May 5, 2009 at 4:48 PM, Carsten Ziegeler cziege...@apache.org wrote: Ok, I'l start with the release process - I fear that this will take a little bit longer this time (until tomorrow I guess). Please refrain from committing stuff in the meantime It is ok to commit under contrib/extensions, right? Yes, but your build will fail as I changed the dependency to the parent pom; so you have to set this back to the snapshot manually. Carsten -- Carsten Ziegeler cziege...@apache.org
Re: Event Listeners
Tobias Bocanegra wrote: sorry to bring this up again - but i'm a bit concerned that every JCR api functionality is duplicated in sling. i think it should not be to goal to replace the JCR api in sling, but to leverage it. the main focus of sling should be to build a framework on JCR and not try to make JCR replaceable. the JCR api might be a bit clumsy to use, but at least it is well documented and standardized. One of the aims of Sling is to make building apps on top of JCR easier. And the described functionality makes observation in many use cases easier. So it's not a duplication. It's a simplified interface. Carsten -- Carsten Ziegeler cziege...@apache.org
Re: [IMP] Code freeze
Jukka Zitting wrote: Hi, On Tue, May 5, 2009 at 4:48 PM, Carsten Ziegeler cziege...@apache.org wrote: Ok, I'l start with the release process - I fear that this will take a little bit longer this time (until tomorrow I guess). Please refrain from committing stuff in the meantime. During the release process the build will be broken as the it will reference artifacts which are not available in a public repo - but on my machine :) Branch? We're not branching for a release; we only branch if really necessary. Carsten -- Carsten Ziegeler cziege...@apache.org
Re: Event Listeners
Bertrand Delacretaz wrote: On Tue, May 5, 2009 at 5:04 PM, Carsten Ziegeler cziege...@apache.org wrote: Tobias Bocanegra wrote: sorry to bring this up again - but i'm a bit concerned that every JCR api functionality is duplicated in sling One of the aims of Sling is to make building apps on top of JCR easier. And the described functionality makes observation in many use cases easier. So it's not a duplication. It's a simplified interface. Is there a description of this new observation stuff somewhere? So far it's just a rough idea which is available as a patch: https://issues.apache.org/jira/browse/SLING-944 Carsten -- Carsten Ziegeler cziege...@apache.org
Re: [IMP] Code freeze
Jukka Zitting wrote: Hi, On Tue, May 5, 2009 at 5:09 PM, Carsten Ziegeler cziege...@apache.org wrote: Jukka Zitting wrote: Branch? We're not branching for a release; we only branch if really necessary. Why? Doing the release preparation in a branch would allow others to continue using trunk for normal development. Hmm, the release process changes at least the poms, so these need to be merged back. I don't actively develop Sling, so my opinion carries little weight on this matter. I'm just curious about why you think branching is a bad idea. I'm not sure if it is a bad idea :) But it is a little overhead which comes with the cost that people shouldn't commit for some hours. I think avoiding the overhead weights more in this case. Carsten -- Carsten Ziegeler cziege...@apache.org
Re: Hudson build is still unstable: sling-contrib-1.5 » Apache Sling Launchpad Contrib Testing #13
Is it possible to configure Hudson to only send mails if the status changed? Carsten Apache Hudson Server schrieb: See http://hudson.zones.apache.org/hudson/job/sling-contrib-1.5/org.apache.sling$org.apache.sling.launchpad.contrib-testing/13/ -- Carsten Ziegeler cziege...@apache.org
Re: JCR2 upgrade plans ?
Felix Meschberger schrieb: Hi, Jukka Zitting schrieb: Hi, On Thu, Apr 30, 2009 at 6:59 PM, Ian Boston i...@tfd.co.uk wrote: With JR trunk having branched 1.x off and now heading for 2.0. What plans, if any does Sling have for moving to 2.0 and 283 support? With my Jackrabbit release manager hat on I'd recommend that Sling wait until Jackrabbit 2.0 is officially out before upgrading to JCR 2.0. I was starting to think on another track: Is it really correct to have the OSGi bindings for Jackrabbit in the Sling project ? Wouldn't it be more logical that Jackrabbit would provide the jackrabbit binding bundles (jcr/jackrabbit-core and jcr/jackrabbit-client and probably also jcr/base itself) ? In fact, many Jackrabbit libraries already come as bundles (jackrabbit-api, jackrabbit-jcr-commons, jackrabbit-jcr-rmi), why not the rest also ? I tend to think, that we might keep the bundles around here at Sling for the Jackrabbit 1.x line because we extended Jackrabbit to allow for pluggable extensions. But for Jackrabbit 2.0 it might be different. I think that Sling should be able to run on JCR 1.0 for a long time; we shouldn't tie us to a new version; however, of course we might have some optional functionality requiring JCR 2.0. Carsten -- Carsten Ziegeler cziege...@apache.org
