[jira] Assigned: (SLING-96) persisted timed events should be removed from the repository after they got successfully executed
[ https://issues.apache.org/jira/browse/SLING-96?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler reassigned SLING-96: - Assignee: Carsten Ziegeler persisted timed events should be removed from the repository after they got successfully executed - Key: SLING-96 URL: https://issues.apache.org/jira/browse/SLING-96 Project: Sling Issue Type: Bug Components: Event Reporter: Philipp Koch Assignee: Carsten Ziegeler Priority: Minor the persisted timed events keep staying in the repository also after being executed/fired successfully. this is from my point of view not correct. the nodes should be deleted so that it would be possible to register a timed event again with the same id. if the current behaviour is thought to keep kind of a history than it would make more sense to keep such a history in a history tree. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-96) persisted timed events should be removed from the repository after they got successfully executed
[ https://issues.apache.org/jira/browse/SLING-96?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12540169 ] Carsten Ziegeler commented on SLING-96: --- Ups, you're right - there is a nice comment in the code: // node is already in repository, this is an error as we don't support updates // of timed events! I guess that your use case is to have timed events that are not scheduled periodically but fired once on a fixed date, right? persisted timed events should be removed from the repository after they got successfully executed - Key: SLING-96 URL: https://issues.apache.org/jira/browse/SLING-96 Project: Sling Issue Type: Bug Components: Event Reporter: Philipp Koch Assignee: Carsten Ziegeler Priority: Minor the persisted timed events keep staying in the repository also after being executed/fired successfully. this is from my point of view not correct. the nodes should be deleted so that it would be possible to register a timed event again with the same id. if the current behaviour is thought to keep kind of a history than it would make more sense to keep such a history in a history tree. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-96) persisted timed events should be removed from the repository after they got successfully executed
[ https://issues.apache.org/jira/browse/SLING-96?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12540171 ] Philipp Koch commented on SLING-96: --- I guess that your use case is to have timed events that are not scheduled periodically but fired once on a fixed date, right? yes. but it might happen that the (fixed) date needs to be updated. so updating the timed event would be nice :-). the workaround would be to delete the event with the given id and recreate the event with the same id - right? persisted timed events should be removed from the repository after they got successfully executed - Key: SLING-96 URL: https://issues.apache.org/jira/browse/SLING-96 Project: Sling Issue Type: Bug Components: Event Reporter: Philipp Koch Assignee: Carsten Ziegeler Priority: Minor the persisted timed events keep staying in the repository also after being executed/fired successfully. this is from my point of view not correct. the nodes should be deleted so that it would be possible to register a timed event again with the same id. if the current behaviour is thought to keep kind of a history than it would make more sense to keep such a history in a history tree. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-96) persisted timed events should be removed from the repository after they got successfully executed
[ https://issues.apache.org/jira/browse/SLING-96?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12540191 ] Carsten Ziegeler commented on SLING-96: --- I've commited a fix for the update problem. persisted timed events should be removed from the repository after they got successfully executed - Key: SLING-96 URL: https://issues.apache.org/jira/browse/SLING-96 Project: Sling Issue Type: Bug Components: Event Reporter: Philipp Koch Assignee: Carsten Ziegeler Priority: Minor the persisted timed events keep staying in the repository also after being executed/fired successfully. this is from my point of view not correct. the nodes should be deleted so that it would be possible to register a timed event again with the same id. if the current behaviour is thought to keep kind of a history than it would make more sense to keep such a history in a history tree. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-96) persisted timed events should be removed from the repository after they got successfully executed
[ https://issues.apache.org/jira/browse/SLING-96?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12540198 ] Philipp Koch commented on SLING-96: --- i created a new timed event. then i updated the timed event. following error got thrown: 05.11.2007 15:30:57 *ERROR* o.a.s.e.i.TimedEventHandler: Exception during writing new job to repository. javax.jcr.InvalidItemStateException: Unable to unlock node. Node has pending changes: /sling/timed-events at com.day.crx.core.NodeImpl.unlock(NodeImpl.java:4097) at org.apache.jackrabbit.util.Locked.runAndUnlock(Locked.java:234) at org.apache.jackrabbit.util.Locked.with(Locked.java:148) at org.apache.jackrabbit.util.Locked.with(Locked.java:104) at org.apache.sling.event.impl.TimedEventHandler.persistEvent(TimedEventHandler.java:172) at org.apache.sling.event.impl.TimedEventHandler.runInBackground(TimedEventHandler.java:127) at org.apache.sling.event.impl.AbstractRepositoryEventHandler$1.run(AbstractRepositoryEventHandler.java:114) 05.11.2007 15:31:19 *ERROR* o.a.s.e.i.TimedEventHandler: Exception during writing new job to repository. javax.jcr.InvalidItemStateException: Unable to lock node. Node has pending changes: /sling/timed-events at com.day.crx.core.NodeImpl.lock(NodeImpl.java:4032) at org.apache.jackrabbit.util.Locked.tryLock(Locked.java:252) at org.apache.jackrabbit.util.Locked.with(Locked.java:146) at org.apache.jackrabbit.util.Locked.with(Locked.java:104) at org.apache.sling.event.impl.TimedEventHandler.persistEvent(TimedEventHandler.java:172) at org.apache.sling.event.impl.TimedEventHandler.runInBackground(TimedEventHandler.java:127) at org.apache.sling.event.impl.AbstractRepositoryEventHandler$1.run(AbstractRepositoryEventHandler.java:114) persisted timed events should be removed from the repository after they got successfully executed - Key: SLING-96 URL: https://issues.apache.org/jira/browse/SLING-96 Project: Sling Issue Type: Bug Components: Event Reporter: Philipp Koch Assignee: Carsten Ziegeler Priority: Minor the persisted timed events keep staying in the repository also after being executed/fired successfully. this is from my point of view not correct. the nodes should be deleted so that it would be possible to register a timed event again with the same id. if the current behaviour is thought to keep kind of a history than it would make more sense to keep such a history in a history tree. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-96) persisted timed events should be removed from the repository after they got successfully executed
[ https://issues.apache.org/jira/browse/SLING-96?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12540210 ] Carsten Ziegeler commented on SLING-96: --- Some synchronization for the removal was missing and the wrong session was used. I fixed this in latest svn. persisted timed events should be removed from the repository after they got successfully executed - Key: SLING-96 URL: https://issues.apache.org/jira/browse/SLING-96 Project: Sling Issue Type: Bug Components: Event Reporter: Philipp Koch Assignee: Carsten Ziegeler Priority: Minor the persisted timed events keep staying in the repository also after being executed/fired successfully. this is from my point of view not correct. the nodes should be deleted so that it would be possible to register a timed event again with the same id. if the current behaviour is thought to keep kind of a history than it would make more sense to keep such a history in a history tree. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Sling API: Script interface
On 11/5/07, Felix Meschberger [EMAIL PROTECTED] wrote: Am Freitag, den 02.11.2007, 09:49 +0100 schrieb Bertrand Delacretaz: On 11/2/07, Felix Meschberger [EMAIL PROTECTED] wrote: ...One simple (stupid ?) solution would be to add a getInputStream() method to the resource... Could we make that a sub-interface? Maybe StreamableResource,... ...I am not sure, whether it is worth it having a separate interface for that. What would be the advantage of NOT adding the getInputStream method to the Resource interface... If it's just one method, ok. But if we need more than one method for StreamableResources, I think that should be a separate interface. -Bertrand
[jira] Updated: (SLING-90) Add support for creating Ruby templates
[ https://issues.apache.org/jira/browse/SLING-90?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ShawnAnderson updated SLING-90: --- Attachment: clean_up_ruby.patch cleaned up script syntax and handled swallowed exception Add support for creating Ruby templates --- Key: SLING-90 URL: https://issues.apache.org/jira/browse/SLING-90 Project: Sling Issue Type: Improvement Components: microsling Reporter: Padraic Hannon Assignee: Felix Meschberger Attachments: clean_up_ruby.patch, ruby_passed_int_tests.patch By adding support for ruby scripted templates microsling could deal with adding dynamic mixins, which is something that java has a hard time with. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Sling API: Script interface
Am Montag, den 05.11.2007, 19:50 +0100 schrieb Bertrand Delacretaz: On 11/5/07, Felix Meschberger [EMAIL PROTECTED] wrote: Am Freitag, den 02.11.2007, 09:49 +0100 schrieb Bertrand Delacretaz: On 11/2/07, Felix Meschberger [EMAIL PROTECTED] wrote: ...One simple (stupid ?) solution would be to add a getInputStream() method to the resource... Could we make that a sub-interface? Maybe StreamableResource,... ...I am not sure, whether it is worth it having a separate interface for that. What would be the advantage of NOT adding the getInputStream method to the Resource interface... If it's just one method, ok. But if we need more than one method for StreamableResources, I think that should be a separate interface. On second thought, I doubt whether a getReader method would be needed, getInputStream would probably suffice it. Regards Felix
Re: Sling API: Script interface
Felix Meschberger wrote: Am Montag, den 05.11.2007, 19:50 +0100 schrieb Bertrand Delacretaz: On 11/5/07, Felix Meschberger [EMAIL PROTECTED] wrote: Am Freitag, den 02.11.2007, 09:49 +0100 schrieb Bertrand Delacretaz: On 11/2/07, Felix Meschberger [EMAIL PROTECTED] wrote: ...One simple (stupid ?) solution would be to add a getInputStream() method to the resource... Could we make that a sub-interface? Maybe StreamableResource,... ...I am not sure, whether it is worth it having a separate interface for that. What would be the advantage of NOT adding the getInputStream method to the Resource interface... If it's just one method, ok. But if we need more than one method for StreamableResources, I think that should be a separate interface. On second thought, I doubt whether a getReader method would be needed, getInputStream would probably suffice it. Yes, getInputStream is enough, but I think we need a getContentType() as well - or add it as a predefined constant to the ResourceMetadata. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
