[jira] Created: (SLING-1687) JobStatusProvider should lazy load events when returning
JobStatusProvider should lazy load events when returning Key: SLING-1687 URL: https://issues.apache.org/jira/browse/SLING-1687 Project: Sling Issue Type: New Feature Components: Extensions Affects Versions: Extensions Event 2.3.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Extensions Event 2.4.0 The current implementation of the job status provider does a query, then loads all jobs and returns a list. If you just want to know how many jobs are available or just want to return the first X jobs, the implementation is too expansive. One solution would be to return a kind of range iterator instead of a list and load jobs on demand. There are two potential problems: - if the jcr query does not return a count, we can't return a count either without going through the hole result set - it might be that a job can't be loaded because of missing classes; in this cases the job count from the query result is higher than the count of the jobs that get processed. I think we can neglect this -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [DISCUSS] Correct listing of resource children (follow up to SLING-1672)
Hi, Here is what I would see to be intended. For case (1) the ResourceResolver must mix the results of calling listChildren(/for/bar) on all resource providers providing resource at or below said path. In this case the BundleResourceProvider and the JcrResourceProvider. For case (2) the ResourceResolver must create these intermediary SyntheticResource instances to be able to traverse down to the mount point of provided resources. Case (2) seems to work, though: when you deploy my whiteboard WebDAV bundle, you will for example see the subtree below /libs, e.g. /libs/sling/redirect. This subtree is entirely synthetic and created on the fly. In the case of the ServletResourceProvider part of the work is done in the ServletResourceProvider (see ServletResourceIterator.seek() method). The ResourceResolver calls the ResourceProvider.listChildren method on each resource provider registered with a path which is a substring of the parent path or which includes the parent path. Maybe this kind of code should be moved to the ResourceResolver creating these synthetic intermediaries for locations below which a ResourceProvider is attached. Now, the BundleResourceProvider is not operating like this. For example there is the Sling POST Servlet bundle registering the /system/sling.js script. This script is never returned by the BundleResourceProvider's listChildren implementation. So what we probably should do is the following: * The ResourceResolver.listChildren method calls the ResourceProvider.listChildren method of all resource providers registered at or _above_ the location whose children are to be listted * Next the for each ResourceProvider registered _below_ the location whose childre are to be listed a SyntheticResource is created (unless an actual resource exists) for the next segment towards the registered ResourceProvider. Example: Consider three resource providers registered at /, /libs, and /libs/sling/servlet/default. Now we want to list the children of /libs/sling. - First the listChildren method of the / and /libs providers are called with the parent path /libs/sling - Next for the /libs/sling/servlet/default provider a synthetic resource is created for /libs/sling/servlet unless this resource has already been returned by one of the other providers. WDYT ? Regards Felix Regards Felix On 23.08.2010 10:17, Mike Müller wrote: Hi When getting a resource the case seems to be clear: The first resource provider which returns a resource *wins*. And the resource providers are called in order starting with the provider which is registered for the longest part of the requested path. With ResourceResolver#listChildren it's a bit trickier. Assume the following: structure in the JCR: /foo /foo/bar /foo/bar/test and in another resource provider: /foo/bar /foo/bar/myresource case 1) ResourceResolver#listChildren( /foo/bar ) should now list the following test myresource case 2) Assume another provider: /some/path/resource /some/path/resource2 What should ResourceResolver#listChildren( / ) list? From my understanding it should list: foo some where may be a SyntheticResource. case 1) and case 2) are not returning the expected result, at least not if you use a bundle resource provider. I haven't looked into the details so I can't say if it's a problem of the bundle resource provider or a more general problem with the resource resolver implementation. Maybe security could be a problem. But a resource provider at least can access the user id via ResourceResolver#getUserID, and list children only if access is allowed. I don't know if this behavour of a resource provider is intended. WDYT? best regards mike
Re: [VOTE] Release Apache Sling Auth Core 1.0.0, Auth Form 1.0.0, Auth OpenID 1.0.0, Auth Selector 1.0.0
+1 Ian On 23 Aug 2010, at 19:48, Felix Meschberger wrote: Hi, Here are the 1.0.0 releases of the Apache Sling Auth Core, Auth Form, Auth OpenID, and Auth Selector bundles. We have solved 36 issues for Auth Core: https://issues.apache.org/jira/browse/SLING/fixforversion/12314514 We have solved 10 issues for Auth Form: https://issues.apache.org/jira/browse/SLING/fixforversion/12314785 We have solved 5 issues for Auth OpenID: https://issues.apache.org/jira/browse/SLING/fixforversion/12314515 We have solved one issue for the Auth Selector: https://issues.apache.org/jira/browse/SLING/fixforversion/12315263 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-135/ You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 135 /tmp/sling-staging Please vote to approve this release: [ ] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... This vote will be open for 72 hours. Regards Felix
[jira] Created: (SLING-1688) List built-in HTTP Basic Authentication Handler on the WebConsole's Authenticator page
List built-in HTTP Basic Authentication Handler on the WebConsole's Authenticator page -- Key: SLING-1688 URL: https://issues.apache.org/jira/browse/SLING-1688 Project: Sling Issue Type: Improvement Components: Authentication Affects Versions: Auth Core 1.0.0 Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: Auth Core 1.0.2 Currently the built-in HTTP Basic Authentication Handler is not listed as an authenticator on the Web Console Authenticator page. Unless the HTTP Basic Authentication Handler is disabled, the handler should actually be listed along with an indication of whether it is fully enabled or just providing preemptively sent credentials. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
RE: [DISCUSS] Correct listing of resource children (follow up to SLING-1672)
Hi That's exactly what I was thinking of: Not the Resource Provider implementations should be responsible for the synthetic resources but the ResourceResolver implementation. So a big +1 from my side. best regards mike Hi, Here is what I would see to be intended. For case (1) the ResourceResolver must mix the results of calling listChildren(/for/bar) on all resource providers providing resource at or below said path. In this case the BundleResourceProvider and the JcrResourceProvider. For case (2) the ResourceResolver must create these intermediary SyntheticResource instances to be able to traverse down to the mount point of provided resources. Case (2) seems to work, though: when you deploy my whiteboard WebDAV bundle, you will for example see the subtree below /libs, e.g. /libs/sling/redirect. This subtree is entirely synthetic and created on the fly. In the case of the ServletResourceProvider part of the work is done in the ServletResourceProvider (see ServletResourceIterator.seek() method). The ResourceResolver calls the ResourceProvider.listChildren method on each resource provider registered with a path which is a substring of the parent path or which includes the parent path. Maybe this kind of code should be moved to the ResourceResolver creating these synthetic intermediaries for locations below which a ResourceProvider is attached. Now, the BundleResourceProvider is not operating like this. For example there is the Sling POST Servlet bundle registering the /system/sling.js script. This script is never returned by the BundleResourceProvider's listChildren implementation. So what we probably should do is the following: * The ResourceResolver.listChildren method calls the ResourceProvider.listChildren method of all resource providers registered at or _above_ the location whose children are to be listted * Next the for each ResourceProvider registered _below_ the location whose childre are to be listed a SyntheticResource is created (unless an actual resource exists) for the next segment towards the registered ResourceProvider. Example: Consider three resource providers registered at /, /libs, and /libs/sling/servlet/default. Now we want to list the children of /libs/sling. - First the listChildren method of the / and /libs providers are called with the parent path /libs/sling - Next for the /libs/sling/servlet/default provider a synthetic resource is created for /libs/sling/servlet unless this resource has already been returned by one of the other providers. WDYT ? Regards Felix Regards Felix On 23.08.2010 10:17, Mike Müller wrote: Hi When getting a resource the case seems to be clear: The first resource provider which returns a resource *wins*. And the resource providers are called in order starting with the provider which is registered for the longest part of the requested path. With ResourceResolver#listChildren it's a bit trickier. Assume the following: structure in the JCR: /foo /foo/bar /foo/bar/test and in another resource provider: /foo/bar /foo/bar/myresource case 1) ResourceResolver#listChildren( /foo/bar ) should now list the following test myresource case 2) Assume another provider: /some/path/resource /some/path/resource2 What should ResourceResolver#listChildren( / ) list? From my understanding it should list: foo some where may be a SyntheticResource. case 1) and case 2) are not returning the expected result, at least not if you use a bundle resource provider. I haven't looked into the details so I can't say if it's a problem of the bundle resource provider or a more general problem with the resource resolver implementation. Maybe security could be a problem. But a resource provider at least can access the user id via ResourceResolver#getUserID, and list children only if access is allowed. I don't know if this behavour of a resource provider is intended. WDYT? best regards mike
[jira] Resolved: (SLING-1688) List built-in HTTP Basic Authentication Handler on the WebConsole's Authenticator page
[ https://issues.apache.org/jira/browse/SLING-1688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger resolved SLING-1688. -- Resolution: Fixed Added support to list built-in HTTP Basic handler in the Authenticator list in Rev. 988415 List built-in HTTP Basic Authentication Handler on the WebConsole's Authenticator page -- Key: SLING-1688 URL: https://issues.apache.org/jira/browse/SLING-1688 Project: Sling Issue Type: Improvement Components: Authentication Affects Versions: Auth Core 1.0.0 Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: Auth Core 1.0.2 Currently the built-in HTTP Basic Authentication Handler is not listed as an authenticator on the Web Console Authenticator page. Unless the HTTP Basic Authentication Handler is disabled, the handler should actually be listed along with an indication of whether it is fully enabled or just providing preemptively sent credentials. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [DISCUSS] Correct listing of resource children (follow up to SLING-1672)
Hi Felix The proposal looks good, +1. I've some additional thoughts: If resources are provided by several ResourceProviders, does it matter which one provides the resource? E.g. the sling:resourceType might vary. So I believe that the order in which ResourceProviders are asked to provide a certain resource needs to be guaranteed. If this assumption holds true, couldn't the synthetic resources be provided by a SyntheticResourceProvider, which would be internal to the ResourceResolver. This SyntheticResourceProvider should be registered as the last one in the list of ResourceProviders. The synthetic resources could then be pre-created upon registration of servlets or ResourceProviders. Reusing the ResourceProvider concept to handle this special case should make it less special and thus would IMHO allow keep the code simple. WDYT? Regards Julian On Tue, Aug 24, 2010 at 9:11 AM, Felix Meschberger fmesc...@gmail.com wrote: Hi, Here is what I would see to be intended. For case (1) the ResourceResolver must mix the results of calling listChildren(/for/bar) on all resource providers providing resource at or below said path. In this case the BundleResourceProvider and the JcrResourceProvider. For case (2) the ResourceResolver must create these intermediary SyntheticResource instances to be able to traverse down to the mount point of provided resources. Case (2) seems to work, though: when you deploy my whiteboard WebDAV bundle, you will for example see the subtree below /libs, e.g. /libs/sling/redirect. This subtree is entirely synthetic and created on the fly. In the case of the ServletResourceProvider part of the work is done in the ServletResourceProvider (see ServletResourceIterator.seek() method). The ResourceResolver calls the ResourceProvider.listChildren method on each resource provider registered with a path which is a substring of the parent path or which includes the parent path. Maybe this kind of code should be moved to the ResourceResolver creating these synthetic intermediaries for locations below which a ResourceProvider is attached. Now, the BundleResourceProvider is not operating like this. For example there is the Sling POST Servlet bundle registering the /system/sling.js script. This script is never returned by the BundleResourceProvider's listChildren implementation. So what we probably should do is the following: * The ResourceResolver.listChildren method calls the ResourceProvider.listChildren method of all resource providers registered at or _above_ the location whose children are to be listted * Next the for each ResourceProvider registered _below_ the location whose childre are to be listed a SyntheticResource is created (unless an actual resource exists) for the next segment towards the registered ResourceProvider. Example: Consider three resource providers registered at /, /libs, and /libs/sling/servlet/default. Now we want to list the children of /libs/sling. - First the listChildren method of the / and /libs providers are called with the parent path /libs/sling - Next for the /libs/sling/servlet/default provider a synthetic resource is created for /libs/sling/servlet unless this resource has already been returned by one of the other providers. WDYT ? Regards Felix Regards Felix On 23.08.2010 10:17, Mike Müller wrote: Hi When getting a resource the case seems to be clear: The first resource provider which returns a resource *wins*. And the resource providers are called in order starting with the provider which is registered for the longest part of the requested path. With ResourceResolver#listChildren it's a bit trickier. Assume the following: structure in the JCR: /foo /foo/bar /foo/bar/test and in another resource provider: /foo/bar /foo/bar/myresource case 1) ResourceResolver#listChildren( /foo/bar ) should now list the following test myresource case 2) Assume another provider: /some/path/resource /some/path/resource2 What should ResourceResolver#listChildren( / ) list? From my understanding it should list: foo some where may be a SyntheticResource. case 1) and case 2) are not returning the expected result, at least not if you use a bundle resource provider. I haven't looked into the details so I can't say if it's a problem of the bundle resource provider or a more general problem with the resource resolver implementation. Maybe security could be a problem. But a resource provider at least can access the user id via ResourceResolver#getUserID, and list children only if access is allowed. I don't know if this behavour of a resource provider is intended. WDYT? best regards mike
[VOTE] Release Apache Sling Auth Core 1.0.2
Hi, Here is the Apache Sling Auth Core 1.0.2 release. There appeared two issues after the call for votes for the Auth Core 1.0.0 bundle. These have been fixed: https://issues.apache.org/jira/browse/SLING/fixforversion/12315268 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-137/ You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 137 /tmp/sling-staging Please vote to approve this release: [ ] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... This vote will be open for 72 hours. Regards Felix
Re: [VOTE] Release Apache Sling Auth Core 1.0.2
+1 Regards Felix On 24.08.2010 09:58, Felix Meschberger wrote: Hi, Here is the Apache Sling Auth Core 1.0.2 release. There appeared two issues after the call for votes for the Auth Core 1.0.0 bundle. These have been fixed: https://issues.apache.org/jira/browse/SLING/fixforversion/12315268 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-137/ You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 137 /tmp/sling-staging Please vote to approve this release: [ ] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... This vote will be open for 72 hours. Regards Felix
[jira] Commented: (SLING-1672) resource.resourceResolver.listChildren only enlists jcr nodes but not all child resources
[ https://issues.apache.org/jira/browse/SLING-1672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12901761#action_12901761 ] Felix Meschberger commented on SLING-1672: -- Please also see the discussion at http://markmail.org/message/2nfguno63hq2fvgt. The ultimate point is probably: * The ResourceResolver.listChildren method calls the ResourceProvider.listChildren method of all resource providers registered at or _above_ the location whose children are to be listted * Next the for each ResourceProvider registered _below_ the location whose childre are to be listed a SyntheticResource is created (unless an actual resource exists) for the next segment towards the registered ResourceProvider. Example: Consider three resource providers registered at /, /libs, and /libs/sling/servlet/default. Now we want to list the children of /libs/sling. - First the listChildren method of the / and /libs providers are called with the parent path /libs/sling - Next for the /libs/sling/servlet/default provider a synthetic resource is created for /libs/sling/servlet unless this resource has already been returned by one of the other providers. resource.resourceResolver.listChildren only enlists jcr nodes but not all child resources - Key: SLING-1672 URL: https://issues.apache.org/jira/browse/SLING-1672 Project: Sling Issue Type: Bug Components: JCR Affects Versions: JCR Resource 2.0.6 Environment: sling from trunk (as of August 20th 2010) Reporter: Clemens Wyss Assignee: Justin Edelson in my esp-script I have the follwoing line: var childResources = request.resourceResolver.listChildren(resource ); In my pom.xml I have the follwoing declaration: Sling-Bundle-Resources /res/sling/explorer;overwrite:=true;uninstall=true;path:=/libs/sling/explorer /Sling-Bundle-Resources i.e. I map /res/sling/explorer to /libs/sling/explorer. And I can directly access the files beneath /res/sling/explorer, e.g. http://localhost:8080/res/sling/explorer/css/explorer.css. I.e. resolving seems to work But when I enlist (which end up in BundleResourceProvider#listChildren()) on the root (/) I don't see 'res' -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: OSGi Installer API
Hi, On Mon, Aug 23, 2010 at 8:26 PM, Carsten Ziegeler cziege...@apache.org wrote: the current OSGi installer has three methods: ...I have the feeling that it would be nicer, if the client could submit several changes add once, so maybe instead of having a addResource and removeResource method, just a updateResources([] addedResources, [] removedResources). Agreed, makes sense. -Bertrand
[jira] Created: (SLING-1689) Change the OSGi installer interface
Change the OSGi installer interface --- Key: SLING-1689 URL: https://issues.apache.org/jira/browse/SLING-1689 Project: Sling Issue Type: Improvement Components: Installer Affects Versions: OSGi Installer 3.0.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: OSGi Installer 3.0.0 As discussed in the mailing list: the current OSGi installer has three methods: - registerResources : which is used to register all resources from the installer client like jcr install; this is usually invoked on startup - addResource : adds a resource during runtime - removeResource : removes a resource during runtime The api is simple, fine and sufficient. However there is a small glitch here. If a client detects several changes at once, like a set of bundles is removed or updated, it has to call addResource or removeResource for each change separately. The OSGi installer could run a install cycle inbetween those method calls. Causing a part of this process to be done in the first cycle and the other part in the second cycle - now as OSGi has a dynamic nature this isn't a problem after two cycles everything is installed as expected. But still I have the feeling that it would be nicer, if the client could submit several changes add once, so maybe instead of having a addResource and removeResource method, just a updateResources([] addedResources, [] removedResources). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] Release Apache Sling Auth Core 1.0.2
+1, release checks out ok. Ian On 24 Aug 2010, at 08:58, Felix Meschberger wrote: +1 Regards Felix On 24.08.2010 09:58, Felix Meschberger wrote: Hi, Here is the Apache Sling Auth Core 1.0.2 release. There appeared two issues after the call for votes for the Auth Core 1.0.0 bundle. These have been fixed: https://issues.apache.org/jira/browse/SLING/fixforversion/12315268 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-137/ You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 137 /tmp/sling-staging Please vote to approve this release: [ ] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... This vote will be open for 72 hours. Regards Felix
[jira] Created: (SLING-1690) Reduce startup time of jcr install
Reduce startup time of jcr install -- Key: SLING-1690 URL: https://issues.apache.org/jira/browse/SLING-1690 Project: Sling Issue Type: Improvement Components: Installer Affects Versions: JCR Installer 3.0.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: JCR Installer 3.0.0 The jcr installer scans the repository during the activate method; this slows down the general startup time of the whole system. The scanning should be done delayed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-1489) Upgrade JCR Install to JCR 2
[ https://issues.apache.org/jira/browse/SLING-1489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-1489. - Resolution: Won't Fix As discussed in the mailing list, we don't upgrade to JCR 2 and rely on JCR 1 Upgrade JCR Install to JCR 2 Key: SLING-1489 URL: https://issues.apache.org/jira/browse/SLING-1489 Project: Sling Issue Type: Improvement Components: Installer Reporter: Justin Edelson Assignee: Justin Edelson Fix For: JCR Installer 3.0.0 JCR 2 added a NODE_MOVED event. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] Release Apache Sling Auth Core 1.0.2
+1 Carsten Felix Meschberger wrote Hi, Here is the Apache Sling Auth Core 1.0.2 release. There appeared two issues after the call for votes for the Auth Core 1.0.0 bundle. These have been fixed: https://issues.apache.org/jira/browse/SLING/fixforversion/12315268 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-137/ You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 137 /tmp/sling-staging Please vote to approve this release: [ ] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... This vote will be open for 72 hours. Regards Felix -- Carsten Ziegeler cziege...@apache.org
[jira] Assigned: (SLING-1663) OSGi Install should recognize system bundle updates
[ https://issues.apache.org/jira/browse/SLING-1663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler reassigned SLING-1663: --- Assignee: Carsten Ziegeler OSGi Install should recognize system bundle updates --- Key: SLING-1663 URL: https://issues.apache.org/jira/browse/SLING-1663 Project: Sling Issue Type: Bug Components: Installer Reporter: Felix Meschberger Assignee: Carsten Ziegeler Fix For: OSGi Installer 3.0.0 The Launchpad Base module generates a bundle with the symbolic name system.bundle which is an official alias for the symbolic name of the system bundle whose real symbolic name is framework specific. The Web Console supports updates with the system.bundle symbolic name and updates the system bundle accordingly. The OSGi Installer should also recognize this situation and act accordingly: * The system bundle does not need to be stopped/started for the update, a framework restart is done automatically * A package refresh is not required * System bundle update acts immediately preventing OSGi Install from properly cleaning up after the install Thus updating the system bundle should probably be done in a special way: * at the of a processing cycle of OSGi Install * preventing any more processing before calling bundle update * probably updating the system bundle in a separate thread to not prevent proper shutdown of OSGi Install -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1690) Reduce startup time of jcr install
[ https://issues.apache.org/jira/browse/SLING-1690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12901855#action_12901855 ] Carsten Ziegeler commented on SLING-1690: - Changed the startup: most of the stuff is now done in the background thread (revision 988516) Reduce startup time of jcr install -- Key: SLING-1690 URL: https://issues.apache.org/jira/browse/SLING-1690 Project: Sling Issue Type: Improvement Components: Installer Affects Versions: JCR Installer 3.0.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: JCR Installer 3.0.0 The jcr installer scans the repository during the activate method; this slows down the general startup time of the whole system. The scanning should be done delayed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1663) OSGi Install should recognize system bundle updates
[ https://issues.apache.org/jira/browse/SLING-1663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12901854#action_12901854 ] Carsten Ziegeler commented on SLING-1663: - Added a first implementation in revision 988515 - not tested yet OSGi Install should recognize system bundle updates --- Key: SLING-1663 URL: https://issues.apache.org/jira/browse/SLING-1663 Project: Sling Issue Type: Bug Components: Installer Reporter: Felix Meschberger Assignee: Carsten Ziegeler Fix For: OSGi Installer 3.0.0 The Launchpad Base module generates a bundle with the symbolic name system.bundle which is an official alias for the symbolic name of the system bundle whose real symbolic name is framework specific. The Web Console supports updates with the system.bundle symbolic name and updates the system bundle accordingly. The OSGi Installer should also recognize this situation and act accordingly: * The system bundle does not need to be stopped/started for the update, a framework restart is done automatically * A package refresh is not required * System bundle update acts immediately preventing OSGi Install from properly cleaning up after the install Thus updating the system bundle should probably be done in a special way: * at the of a processing cycle of OSGi Install * preventing any more processing before calling bundle update * probably updating the system bundle in a separate thread to not prevent proper shutdown of OSGi Install -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-1335) Timing issues in OSGi installer integration tests
[ https://issues.apache.org/jira/browse/SLING-1335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-1335. - Resolution: Fixed I finally fixed the other failing test; everything should run now Timing issues in OSGi installer integration tests - Key: SLING-1335 URL: https://issues.apache.org/jira/browse/SLING-1335 Project: Sling Issue Type: Bug Components: Installer Reporter: Bertrand Delacretaz Priority: Minor Seems like some tests in the installer/osgi/it have timing issues which make them fail semi-randomly. More often on Hudson that on my macbook, for example. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-755) jcrinstall console plugin
[ https://issues.apache.org/jira/browse/SLING-755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated SLING-755: --- Fix Version/s: (was: JCR Install 2.0.4) Unscheduling this from JCR 2.0.4 as we are working on JCR 3.0.0 now jcrinstall console plugin - Key: SLING-755 URL: https://issues.apache.org/jira/browse/SLING-755 Project: Sling Issue Type: Improvement Components: Installer Reporter: Bertrand Delacretaz Priority: Minor (changed title as discussion moved to creating a console plugin) Making a servlet out of the jcrinstall RepositoryObserver class introduces dependencies on the sling api and servlet bundles, which are not desired for jcrinstall - its dependencies should be kept to a minimum. I'll move the servlet to its own bundle - it is currently only needed for integration testing, but might be useful for other monitoring purposes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-1690) Reduce startup time of jcr install
[ https://issues.apache.org/jira/browse/SLING-1690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-1690. - Resolution: Fixed Works Reduce startup time of jcr install -- Key: SLING-1690 URL: https://issues.apache.org/jira/browse/SLING-1690 Project: Sling Issue Type: Improvement Components: Installer Affects Versions: JCR Installer 3.0.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: JCR Installer 3.0.0 The jcr installer scans the repository during the activate method; this slows down the general startup time of the whole system. The scanning should be done delayed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-1691) Improve startup behaviour
Improve startup behaviour - Key: SLING-1691 URL: https://issues.apache.org/jira/browse/SLING-1691 Project: Sling Issue Type: Improvement Components: Scripting Affects Versions: Scripting JSP-Atom-Taglib 1.0.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Scripting JSP-Atom-Taglib 1.0.0 The current implementation costs some startup performance as a service tracker is registered which loads all Abdera stuff as soon as the servlet context is available. We could delay this to it's first usage -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-1691) Improve startup behaviour
[ https://issues.apache.org/jira/browse/SLING-1691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-1691. - Resolution: Fixed Abdera is now started on first usage and not put into the servlet context anymore. Changed in revision 988540 Improve startup behaviour - Key: SLING-1691 URL: https://issues.apache.org/jira/browse/SLING-1691 Project: Sling Issue Type: Improvement Components: Scripting Affects Versions: Scripting JSP-Atom-Taglib 1.0.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Scripting JSP-Atom-Taglib 1.0.0 The current implementation costs some startup performance as a service tracker is registered which loads all Abdera stuff as soon as the servlet context is available. We could delay this to it's first usage -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1560) Improve and clean up code
[ https://issues.apache.org/jira/browse/SLING-1560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12901921#action_12901921 ] Carsten Ziegeler commented on SLING-1560: - I've done another minor update: move most of the activation stuff into the run method and removed a local instance variable for clarification in revision 988593 Improve and clean up code - Key: SLING-1560 URL: https://issues.apache.org/jira/browse/SLING-1560 Project: Sling Issue Type: Improvement Components: Installer Affects Versions: OSGi Installer 3.0.0, JCR Installer 3.0.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: OSGi Installer 3.0.0, JCR Installer 3.0.0 In order to fix some outstanding bugs and to add new features, a code review and clean up seems to be a good idea :) This bug will keep track of all changes to the code that don't add new features -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
RE: [DISCUSS] Correct listing of resource children (follow up to SLING-1672)
Hi That seems to be a good way to implement it. IIRC the resource providers are called in order starting with the provider which is registered for the longest part of the requested path. If that is correct the SyntheticResourceProvider (which I rather would name something like PathNodeProvider) should be registered for /, where also the JcrResourceProvider is registered. The question is now, how the resource provider which are registered for the same path could be further ordered (the service id doesn't seem to be a good idea). Any idea? best regards mike The proposal looks good, +1. I've some additional thoughts: If resources are provided by several ResourceProviders, does it matter which one provides the resource? E.g. the sling:resourceType might vary. So I believe that the order in which ResourceProviders are asked to provide a certain resource needs to be guaranteed. If this assumption holds true, couldn't the synthetic resources be provided by a SyntheticResourceProvider, which would be internal to the ResourceResolver. This SyntheticResourceProvider should be registered as the last one in the list of ResourceProviders. The synthetic resources could then be pre-created upon registration of servlets or ResourceProviders. Reusing the ResourceProvider concept to handle this special case should make it less special and thus would IMHO allow keep the code simple. WDYT? Regards Julian On Tue, Aug 24, 2010 at 9:11 AM, Felix Meschberger fmesc...@gmail.com wrote: Hi, Here is what I would see to be intended. For case (1) the ResourceResolver must mix the results of calling listChildren(/for/bar) on all resource providers providing resource at or below said path. In this case the BundleResourceProvider and the JcrResourceProvider. For case (2) the ResourceResolver must create these intermediary SyntheticResource instances to be able to traverse down to the mount point of provided resources. Case (2) seems to work, though: when you deploy my whiteboard WebDAV bundle, you will for example see the subtree below /libs, e.g. /libs/sling/redirect. This subtree is entirely synthetic and created on the fly. In the case of the ServletResourceProvider part of the work is done in the ServletResourceProvider (see ServletResourceIterator.seek() method). The ResourceResolver calls the ResourceProvider.listChildren method on each resource provider registered with a path which is a substring of the parent path or which includes the parent path. Maybe this kind of code should be moved to the ResourceResolver creating these synthetic intermediaries for locations below which a ResourceProvider is attached. Now, the BundleResourceProvider is not operating like this. For example there is the Sling POST Servlet bundle registering the /system/sling.js script. This script is never returned by the BundleResourceProvider's listChildren implementation. So what we probably should do is the following: * The ResourceResolver.listChildren method calls the ResourceProvider.listChildren method of all resource providers registered at or _above_ the location whose children are to be listted * Next the for each ResourceProvider registered _below_ the location whose childre are to be listed a SyntheticResource is created (unless an actual resource exists) for the next segment towards the registered ResourceProvider. Example: Consider three resource providers registered at /, /libs, and /libs/sling/servlet/default. Now we want to list the children of /libs/sling. - First the listChildren method of the / and /libs providers are called with the parent path /libs/sling - Next for the /libs/sling/servlet/default provider a synthetic resource is created for /libs/sling/servlet unless this resource has already been returned by one of the other providers. WDYT ? Regards Felix Regards Felix On 23.08.2010 10:17, Mike Müller wrote: Hi When getting a resource the case seems to be clear: The first resource provider which returns a resource *wins*. And the resource providers are called in order starting with the provider which is registered for the longest part of the requested path. With ResourceResolver#listChildren it's a bit trickier. Assume the following: structure in the JCR: /foo /foo/bar /foo/bar/test and in another resource provider: /foo/bar /foo/bar/myresource case 1) ResourceResolver#listChildren( /foo/bar ) should now list the following test myresource case 2) Assume another provider: /some/path/resource /some/path/resource2 What should ResourceResolver#listChildren( / ) list? From my understanding it should list: foo some where may be a SyntheticResource. case 1) and case 2) are not returning the expected result, at least not if you use a bundle resource
Re: [DISCUSS] Correct listing of resource children (follow up to SLING-1672)
Mike Müller wrote Hi That seems to be a good way to implement it. IIRC the resource providers are called in order starting with the provider which is registered for the longest part of the requested path. If that is correct the SyntheticResourceProvider (which I rather would name something like PathNodeProvider) should be registered for /, where also the JcrResourceProvider is registered. The question is now, how the resource provider which are registered for the same path could be further ordered (the service id doesn't seem to be a good idea). Any idea? We could use service.ranking property - the standard way of defining an order in such cases. Carsten -- Carsten Ziegeler cziege...@apache.org
Re: [VOTE] Release Apache Sling Auth Core 1.0.2
+1 Thanks. 2010/8/24 Felix Meschberger fmesc...@gmail.com Hi, Here is the Apache Sling Auth Core 1.0.2 release. There appeared two issues after the call for votes for the Auth Core 1.0.0 bundle. These have been fixed: https://issues.apache.org/jira/browse/SLING/fixforversion/12315268 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-137/ You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 137 /tmp/sling-staging Please vote to approve this release: [ ] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... This vote will be open for 72 hours. Regards Felix -- *Regards,* *Victor Taranenko*
[jira] Created: (SLING-1692) When started from Maven Launchpad Plugin, framework cannot be restarted
When started from Maven Launchpad Plugin, framework cannot be restarted --- Key: SLING-1692 URL: https://issues.apache.org/jira/browse/SLING-1692 Project: Sling Issue Type: Bug Components: Maven Plugins Reporter: Justin Edelson Fix For: Maven Launchpad Plugin 2.0.8 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-1692) When started from Maven Launchpad Plugin, framework cannot be restarted
[ https://issues.apache.org/jira/browse/SLING-1692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Edelson updated SLING-1692: -- Assignee: Justin Edelson When started from Maven Launchpad Plugin, framework cannot be restarted --- Key: SLING-1692 URL: https://issues.apache.org/jira/browse/SLING-1692 Project: Sling Issue Type: Bug Components: Maven Plugins Reporter: Justin Edelson Assignee: Justin Edelson Fix For: Maven Launchpad Plugin 2.0.8 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-1692) When started from Maven Launchpad Plugin, framework cannot be restarted
[ https://issues.apache.org/jira/browse/SLING-1692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Edelson resolved SLING-1692. --- Resolution: Fixed When started from Maven Launchpad Plugin, framework cannot be restarted --- Key: SLING-1692 URL: https://issues.apache.org/jira/browse/SLING-1692 Project: Sling Issue Type: Bug Components: Maven Plugins Reporter: Justin Edelson Assignee: Justin Edelson Fix For: Maven Launchpad Plugin 2.0.8 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1692) When started from Maven Launchpad Plugin, framework cannot be restarted
[ https://issues.apache.org/jira/browse/SLING-1692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12901952#action_12901952 ] Justin Edelson commented on SLING-1692: --- done in r988610 When started from Maven Launchpad Plugin, framework cannot be restarted --- Key: SLING-1692 URL: https://issues.apache.org/jira/browse/SLING-1692 Project: Sling Issue Type: Bug Components: Maven Plugins Reporter: Justin Edelson Assignee: Justin Edelson Fix For: Maven Launchpad Plugin 2.0.8 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-1693) Maven Launchpad Plugin's ResourceProvider should return .xml files from the classpath
Maven Launchpad Plugin's ResourceProvider should return .xml files from the classpath - Key: SLING-1693 URL: https://issues.apache.org/jira/browse/SLING-1693 Project: Sling Issue Type: Bug Components: Maven Plugins Reporter: Justin Edelson Assignee: Justin Edelson Fix For: Maven Launchpad Plugin 2.0.8 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-1693) Maven Launchpad Plugin's ResourceProvider should return .xml files from the classpath
[ https://issues.apache.org/jira/browse/SLING-1693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Edelson resolved SLING-1693. --- Resolution: Fixed done in r988612 Maven Launchpad Plugin's ResourceProvider should return .xml files from the classpath - Key: SLING-1693 URL: https://issues.apache.org/jira/browse/SLING-1693 Project: Sling Issue Type: Improvement Components: Maven Plugins Reporter: Justin Edelson Assignee: Justin Edelson Fix For: Maven Launchpad Plugin 2.0.8 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-1693) Maven Launchpad Plugin's ResourceProvider should return .xml files from the classpath
[ https://issues.apache.org/jira/browse/SLING-1693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Edelson updated SLING-1693: -- Issue Type: Improvement (was: Bug) Maven Launchpad Plugin's ResourceProvider should return .xml files from the classpath - Key: SLING-1693 URL: https://issues.apache.org/jira/browse/SLING-1693 Project: Sling Issue Type: Improvement Components: Maven Plugins Reporter: Justin Edelson Assignee: Justin Edelson Fix For: Maven Launchpad Plugin 2.0.8 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (SLING-1693) Maven Launchpad Plugin's ResourceProvider should return .xml files from the classpath
[ https://issues.apache.org/jira/browse/SLING-1693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Edelson reopened SLING-1693: --- need to rethink this strategy entirely... Maven Launchpad Plugin's ResourceProvider should return .xml files from the classpath - Key: SLING-1693 URL: https://issues.apache.org/jira/browse/SLING-1693 Project: Sling Issue Type: Improvement Components: Maven Plugins Reporter: Justin Edelson Assignee: Justin Edelson Fix For: Maven Launchpad Plugin 2.0.8 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-1693) Maven Launchpad Plugin's ResourceProvider should use a search path
[ https://issues.apache.org/jira/browse/SLING-1693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Edelson updated SLING-1693: -- Summary: Maven Launchpad Plugin's ResourceProvider should use a search path (was: Maven Launchpad Plugin's ResourceProvider should return .xml files from the classpath) for resources, regardless of file type, should be... 1) a local directory 2) the classpath 3) treat the path as a URL Maven Launchpad Plugin's ResourceProvider should use a search path -- Key: SLING-1693 URL: https://issues.apache.org/jira/browse/SLING-1693 Project: Sling Issue Type: Improvement Components: Maven Plugins Reporter: Justin Edelson Assignee: Justin Edelson Fix For: Maven Launchpad Plugin 2.0.8 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-1664) support reading the jackrabbit configuration file from the launchpad archive
[ https://issues.apache.org/jira/browse/SLING-1664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Edelson updated SLING-1664: -- Assignee: Justin Edelson support reading the jackrabbit configuration file from the launchpad archive Key: SLING-1664 URL: https://issues.apache.org/jira/browse/SLING-1664 Project: Sling Issue Type: Improvement Components: JCR Reporter: Justin Edelson Assignee: Justin Edelson downstream users of Sling should be able to put a repository.xml in either the launchpad JAR or WAR and get it to work without any additional configuration. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-1693) Maven Launchpad Plugin's ResourceProvider should use a search path
[ https://issues.apache.org/jira/browse/SLING-1693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Edelson resolved SLING-1693. --- Resolution: Fixed reimplemented in r988642 Maven Launchpad Plugin's ResourceProvider should use a search path -- Key: SLING-1693 URL: https://issues.apache.org/jira/browse/SLING-1693 Project: Sling Issue Type: Improvement Components: Maven Plugins Reporter: Justin Edelson Assignee: Justin Edelson Fix For: Maven Launchpad Plugin 2.0.8 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-1664) support reading the jackrabbit configuration file from the launchpad archive
[ https://issues.apache.org/jira/browse/SLING-1664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Edelson updated SLING-1664: -- Fix Version/s: JCR Jackrabbit Server 2.0.8 support reading the jackrabbit configuration file from the launchpad archive Key: SLING-1664 URL: https://issues.apache.org/jira/browse/SLING-1664 Project: Sling Issue Type: Improvement Components: JCR Reporter: Justin Edelson Assignee: Justin Edelson Fix For: JCR Jackrabbit Server 2.0.8 downstream users of Sling should be able to put a repository.xml in either the launchpad JAR or WAR and get it to work without any additional configuration. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1664) support reading the jackrabbit configuration file from the launchpad archive
[ https://issues.apache.org/jira/browse/SLING-1664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12901998#action_12901998 ] Justin Edelson commented on SLING-1664: --- done in r988640 if there's no configuration for the embedded repository and there is a repository.xml file at the root of the ResourceProvider, then that configuration file is copied into sling.home and used as the repository configuration. for JAR archives, this is the root of the archive for WAR archives, this is the root of the archive, WEB-IF, or the webapp classpath when using the Maven Launchpad Plugin, it is src/test/resources support reading the jackrabbit configuration file from the launchpad archive Key: SLING-1664 URL: https://issues.apache.org/jira/browse/SLING-1664 Project: Sling Issue Type: Improvement Components: JCR Reporter: Justin Edelson Assignee: Justin Edelson Fix For: JCR Jackrabbit Server 2.0.8 downstream users of Sling should be able to put a repository.xml in either the launchpad JAR or WAR and get it to work without any additional configuration. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-1681) Merge Installer into Reactor
[ https://issues.apache.org/jira/browse/SLING-1681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Edelson resolved SLING-1681. --- Assignee: Justin Edelson Resolution: Fixed Merge Installer into Reactor Key: SLING-1681 URL: https://issues.apache.org/jira/browse/SLING-1681 Project: Sling Issue Type: Improvement Components: General Reporter: Justin Edelson Assignee: Justin Edelson installer builds and test successfully, so we should merge it into the main reactor -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1681) Merge Installer into Reactor
[ https://issues.apache.org/jira/browse/SLING-1681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12902000#action_12902000 ] Justin Edelson commented on SLING-1681: --- done in r988646 Merge Installer into Reactor Key: SLING-1681 URL: https://issues.apache.org/jira/browse/SLING-1681 Project: Sling Issue Type: Improvement Components: General Reporter: Justin Edelson Assignee: Justin Edelson installer builds and test successfully, so we should merge it into the main reactor -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Documentation on BundleResourceProvider and ResourceDecorator
Hi I added some documentation on BundleResourceProvider [1] and ResourceDecorator [2]. Please feel free to correct me if something is wrong or unclear. [1] http://sling.apache.org/site/bundle-resources-extensionsbundleresource.html [2] https://cwiki.apache.org/confluence/display/SLINGxSITE/Wrap+or+Decorate+Resources best regards mike
Build failed in Hudson: sling-contrib-1.5 » Apache Sling Dojo JavaScript Library #568
See
https://hudson.apache.org/hudson/job/sling-contrib-1.5/org.apache.sling$org.apache.sling.extensions.dojo/568/
--
[INFO]
[INFO] Building Apache Sling Dojo JavaScript Library
[INFO]task-segment: [clean, install]
[INFO]
[INFO] [clean:clean {execution: default-clean}]
[INFO] Deleting file set:
https://hudson.apache.org/hudson/job/sling-contrib-1.5/org.apache.sling$org.apache.sling.extensions.dojo/ws/target
(included: [**], excluded: [])
[INFO] [enforcer:enforce {execution: enforce-java}]
[INFO] [remote-resources:process {execution: default}]
[INFO] [resources:resources {execution: default-resources}]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 4 resources
[INFO] Copying 3 resources
[INFO] [antrun:run {execution: default}]
[INFO] Executing tasks
[taskdef] Could not load definitions from resource
net/sf/antcontrib/antcontrib.properties. It could not be found.
[HUDSON] Archiving
https://hudson.apache.org/hudson/job/sling-contrib-1.5/org.apache.sling$org.apache.sling.extensions.dojo/ws/pom.xml
to
/home/hudson/hudson/jobs/sling-contrib-1.5/modules/org.apache.sling$org.apache.sling.extensions.dojo/builds/2010-08-24_20-12-46/archive/org.apache.sling/org.apache.sling.extensions.dojo/1.1.0.002-SNAPSHOT/pom.xml
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] An Ant BuildException has occured: Problem: failed to create task or
type if
Cause: The name is undefined.
Action: Check the spelling.
Action: Check that any custom tasks/types have been declared.
Action: Check that any presetdef/macrodef declarations have taken place.
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 1 minute 3 seconds
[INFO] Finished at: Tue Aug 24 20:13:57 UTC 2010
[INFO] Final Memory: 40M/63M
[INFO]
Build failed in Hudson: sling-trunk-1.5 #846
See https://hudson.apache.org/hudson/job/sling-trunk-1.5/846/changes Changes: [justin] SLING-1681 - adding installer to reactor [justin] using SNAPSHOT version of launchpad plugin to see repository.xml context support [justin] SLING-1693 - implemeting a search path for resources [justin] adding sample repository.xml files just to demonstrate SLING-1664 [justin] SLING-1664 - try reading the repository.xml file from the Launchpad context [justin] changing classname and adding missing license header [justin] SLING-1693 - adding xml as a resource provider provided extension [justin] SLING-1692 - replacing dummy code for updated() method. [cziegeler] SLING-1560 : Improve and clean up code [cziegeler] SLING-1560 : Improve and clean up code [cziegeler] Taglib runs with Abdera 1.0 [cziegeler] Add serial version [cziegeler] SLING-1691 : Improve startup behaviour [cziegeler] SLING-1690 : Reduce startup time of jcr install [cziegeler] SLING-1663 : OSGi Install should recognize system bundle updates [cziegeler] SLING-1689 : Change the OSGi installer interface [fmeschbe] [maven-release-plugin] prepare for next development iteration [fmeschbe] [maven-release-plugin] prepare release org.apache.sling.auth.core-1.0.2 [fmeschbe] Fix JIRA version ID for the 1.0.2 release [fmeschbe] SLING-1688 Add built-in HTTP Basic authentication handler to Web Console Authenticator page if not disabled [cziegeler] Some pom formatting, set export version and make dependencies provided [cziegeler] Some pom formatting, set export version and make dependencies provided [enorman] svn:ignore eclipse project files [enorman] SLING-1677 Let AccessManager POST servlets return JSON [enorman] SLING-1676 Let UserManager POST servlets return JSON [justin] SLING-1686 - adding post processing for fallback basic auth handler -- [...truncated 14331 lines...] 21:36:04.406 DEBUG [JcrInstaller.20] WatchedFolder.java:154 Digest didn't change, ignoring InstallableResource, priority=100, id=/libs/foo/bar/install/cfgA 21:36:04.407 INFO [JcrInstaller.20] JcrInstaller.java:434 Registering resource with OSGi installer: [InstallableResource, priority=100, id=/libs/foo/bar/install/bundle1.jar, InstallableResource, priority=100, id=/libs/foo/bar/install/cfg3.cfg] 21:36:04.407 INFO [JcrInstaller.20] JcrInstaller.java:435 Removing resource from OSGi installer: [] 21:36:04.407 DEBUG [JcrInstaller.20] WatchedFolder.java:130 Scanning /libs/foo/wii/install 21:36:04.408 DEBUG [JcrInstaller.20] FileNodeConverter.java:63 Node /libs/foo/wii/install/cfgB has no jcr:content/jcr:data or jcr:content/jcr:lastModified properties, ignored 21:36:04.408 DEBUG [JcrInstaller.20] ConfigNodeConverter.java:72 Loading config from Node /libs/foo/wii/install/cfgB 21:36:04.408 DEBUG [JcrInstaller.20] ConfigNodeConverter.java:75 Loading /libs/foo/wii/install/cfgB properties 21:36:04.409 DEBUG [JcrInstaller.20] ConfigNodeConverter.java:61 Converted node /libs/foo/wii/install/cfgB to InstallableResource, priority=100, id=/libs/foo/wii/install/cfgB 21:36:04.409 DEBUG [JcrInstaller.20] WatchedFolder.java:154 Digest didn't change, ignoring InstallableResource, priority=100, id=/libs/foo/wii/install/cfgB 21:36:04.409 DEBUG [JcrInstaller.20] FileNodeConverter.java:63 Node /libs/foo/wii/install/cfgC has no jcr:content/jcr:data or jcr:content/jcr:lastModified properties, ignored 21:36:04.409 DEBUG [JcrInstaller.20] ConfigNodeConverter.java:72 Loading config from Node /libs/foo/wii/install/cfgC 21:36:04.409 DEBUG [JcrInstaller.20] ConfigNodeConverter.java:75 Loading /libs/foo/wii/install/cfgC properties 21:36:04.410 DEBUG [JcrInstaller.20] ConfigNodeConverter.java:61 Converted node /libs/foo/wii/install/cfgC to InstallableResource, priority=100, id=/libs/foo/wii/install/cfgC 21:36:04.410 DEBUG [JcrInstaller.20] WatchedFolder.java:154 Digest didn't change, ignoring InstallableResource, priority=100, id=/libs/foo/wii/install/cfgC 21:36:04.410 INFO [JcrInstaller.20] JcrInstaller.java:434 Registering resource with OSGi installer: [InstallableResource, priority=100, id=/libs/foo/wii/install/bundle2.jar, InstallableResource, priority=100, id=/libs/foo/wii/install/cfg1.properties, InstallableResource, priority=100, id=/libs/foo/wii/install/cfg2.properties] 21:36:04.410 INFO [JcrInstaller.20] JcrInstaller.java:435 Removing resource from OSGi installer: [] 21:36:04.410 DEBUG [JcrInstaller.20] WatchedFolder.java:130 Scanning /apps/install 21:36:04.410 INFO [JcrInstaller.20] JcrInstaller.java:434 Registering resource with OSGi installer: [] 21:36:04.410 INFO [JcrInstaller.20] JcrInstaller.java:435 Removing resource from OSGi installer: [] 21:36:04.411 DEBUG [JcrInstaller.20] JcrInstaller.java:364 Updating folder list. 21:36:04.411 INFO [JcrInstaller.20] TransientRepository.java:384 Session opened 21:36:04.412 DEBUG [JcrInstaller.20] JcrInstaller.java:312 Bundles root node /libs found, looking for
Hudson build is back to stable : sling-installer-1.5 » Apache Sling OSGi Installer Integration Tests #99
See https://hudson.apache.org/hudson/job/sling-installer-1.5/org.apache.sling$org.apache.sling.osgi.installer.it/99/changes
Hudson build is back to stable : sling-installer-1.5 #99
See https://hudson.apache.org/hudson/job/sling-installer-1.5/99/changes
Hudson build is still unstable: sling-trun k-1.6 » Apache Sling Launchpad Testing #538
See https://hudson.apache.org/hudson/job/sling-trunk-1.6/org.apache.sling$org.apache.sling.launchpad.testing/changes
Hudson build is still unstable: sling-trunk-1.6 #538
See https://hudson.apache.org/hudson/job/sling-trunk-1.6/changes
[RESULT] [VOTE] Release Apache Sling Web Console Branding 1.0.0 and Apache Sling Web Console Security Provider 1.0.0
Hi, Time to tally the vote. We received the following votes: +1 Felix Meschberger*, Ian Boston*, Victor Taranenko, Carsten Ziegeler*, Justin Edelson 0 - -1 - No other votes have been cast. Thus this vote succeeds with 5 +1 votes (3 of which binding). Thanks for your votes. I will now proceed with publishing the artifacts. Regards Felix On 21.08.2010 22:56, Felix Meschberger wrote: Hi, Here are the Apache Sling Web Console Branding 1.0.0 and Apache Sling Web Console Security Provider 1.0.0 releases. For the Web Console Branding we fixed 3 issues: https://issues.apache.org/jira/browse/SLING/fixforversion/12314456 For the Web Console Security Provider one issue was fixed: https://issues.apache.org/jira/browse/SLING/fixforversion/12315265 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-131/ You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 131 /tmp/sling-staging Please vote to approve this release: [ ] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... This vote will be open for 72 hours. Regards Felix
