[jira] Closed: (SLING-933) Upgrade to latest SCR release
[ https://issues.apache.org/jira/browse/SLING-933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed SLING-933. --- Resolution: Fixed Upgraded in Rev. 771575 Upgrade to latest SCR release - Key: SLING-933 URL: https://issues.apache.org/jira/browse/SLING-933 Project: Sling Issue Type: Sub-task Components: Launchpad Reporter: Felix Meschberger Fix For: Launchpad Bundles 4 Upgrade 1.0.7-SNAPSHOT with next SCR release once available from the Apache Felix project. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Sling board report draft (due May 13th)
Hi, See http://wiki.apache.org/incubator/May2009. Here's my suggested draft: Sling is a scriptable OSGI-based web framework that uses a Java Content Repository, such as Apache Jackrabbit, to store and manage content. Sling entered incubation on September 5th, 2007, and is actively preparing for graduation. There are no issues which require Incubator PMC or board attention at the moment. Community Lots of interest around Sling at ApacheCon in March, including fruitful discussions with people from the Sakai community who are starting to use Sling for a new version of their software, and starting to actively participate on our mailing lists. Meeting people from the Apache Felix and ServiceMix projects has helped build more community bridges around OSGi. Vidar Ramdal was elected as a committer and PPMC member. Juan José Vázquez Delgado, Sling committer since the start of incubation, became more active, contributed a pipelining module based on Cocoon 3, and is working on improved OSGi testing frameworks. Mike Mueller was granted write access to our wiki as a documentation committer, iCLA on file. In general, steadily increasing community activity with more contributions, discussions and patches. Mailing list stats (http://people.apache.org/~coar/mlists.html) also show a steady increase in subscribers, now at 130 subscribers and average of 17 posts/day on the sling dev list (there's no user list at the moment). Software Preparing the new release, awaiting imminent release of some dependencies to cut it. Continuous integration builds have been activated on hudson.zones.apache.org. Issues before graduation Sustained activity from at least two non-Day committers, along with the new release and increased community interest and engagement, seems to indicate that Sling should graduate soon. Licensing and other issues None -Bertrand
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: Preparing the release
Hi, Carsten Ziegeler schrieb: 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 Hmm, this should definitely be moved to contrib (if not removed altogether) because the Jackrabbit API library is an OSGi bundle nowadays and in fact we already include the original Jackrabbit API as a bundle and don't use this one any more. - 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. +1 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). +1 (assuming contrib/extensions and to be release in the near future) Regards Felix
Re: Preparing the release
On Tue, May 5, 2009 at 10:35 AM, Felix Meschberger fmesc...@gmail.com wrote: snip cause=good stuff/ I agree with Felix. -Bertrand
Re: svn commit: r771617 - in /incubator/sling/trunk/bundles/jcr: jackrabbit-accessmanager/pom.xml jackrabbit-usermanager/pom.xml
Hi, Shouldn't this rather be org.apache.jackrabbit:jackrabbit-api ? Regards Felix cziege...@apache.org schrieb: Author: cziegeler Date: Tue May 5 08:26:58 2009 New Revision: 771617 URL: http://svn.apache.org/viewvc?rev=771617view=rev Log: Use released version of jackrabbit api Modified: incubator/sling/trunk/bundles/jcr/jackrabbit-accessmanager/pom.xml incubator/sling/trunk/bundles/jcr/jackrabbit-usermanager/pom.xml Modified: incubator/sling/trunk/bundles/jcr/jackrabbit-accessmanager/pom.xml URL: http://svn.apache.org/viewvc/incubator/sling/trunk/bundles/jcr/jackrabbit-accessmanager/pom.xml?rev=771617r1=771616r2=771617view=diff == --- incubator/sling/trunk/bundles/jcr/jackrabbit-accessmanager/pom.xml (original) +++ incubator/sling/trunk/bundles/jcr/jackrabbit-accessmanager/pom.xml Tue May 5 08:26:58 2009 @@ -95,7 +95,7 @@ dependency groupIdorg.apache.sling/groupId artifactIdorg.apache.sling.jcr.jackrabbit.api/artifactId - version2.0.3-incubator-SNAPSHOT/version + version2.0.2-incubator/version /dependency dependency groupIdorg.apache.sling/groupId Modified: incubator/sling/trunk/bundles/jcr/jackrabbit-usermanager/pom.xml URL: http://svn.apache.org/viewvc/incubator/sling/trunk/bundles/jcr/jackrabbit-usermanager/pom.xml?rev=771617r1=771616r2=771617view=diff == --- incubator/sling/trunk/bundles/jcr/jackrabbit-usermanager/pom.xml (original) +++ incubator/sling/trunk/bundles/jcr/jackrabbit-usermanager/pom.xml Tue May 5 08:26:58 2009 @@ -104,7 +104,7 @@ dependency groupIdorg.apache.sling/groupId artifactIdorg.apache.sling.jcr.jackrabbit.api/artifactId - version2.0.3-incubator-SNAPSHOT/version + version2.0.2-incubator/version /dependency dependency groupIdorg.apache.sling/groupId
[jira] Created: (SLING-954) Add suppport for TCP/IP based control connection for Sling standalone app
Add suppport for TCP/IP based control connection for Sling standalone app - Key: SLING-954 URL: https://issues.apache.org/jira/browse/SLING-954 Project: Sling Issue Type: New Feature Components: Launchpad Launcher Affects Versions: Launchpad Base 2.0.4 Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: Launchpad Base 2.0.4 Currently the Sling standalone application can only be stopped by stopping the system bundle or by killing the Sling process. To better control Sling control connection support based on TCP/IP would be nice. This way the same sling standalone application may be used to start sling, to check a running sling instance and to stop a running sling instance. The following command line arguments are added: start - Sling opens a TCP/IP server socket for the control conneciton status - Checks whether a Sling instance is listening on a TCP/IP socket stop - Stops a Sling instance listening on a TCP/IP socket none of the above - starts Sling without listening on a TCP/IP socket The socket to listen on (start option) or to send the command to (status, stop) is configured with the -j command line option. This option takes an argument of the following form: host:port -- host name or ip address and port number of the socket port -- port number on localhost (InetAddress.getLocalHost()) of the socket none or -j not specified -- defaults to port 63000 on localhost Note, that setting any host name or IP address, which is reachable from remote systems may be considered as security issue, since the connection is not secured by password or such. For this reason the default interface to listen on is local host and the server socket is only created if explicitly asked for with the start parameter. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (SLING-953) Preprocess the Commandline in the outer Main class
[ https://issues.apache.org/jira/browse/SLING-953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed SLING-953. --- Resolution: Fixed Implemented new command line parsing in Rev. 771608 and added a small fix to allow for single dash parameter arguments (as in -f -) in Rev. 771647. Preprocess the Commandline in the outer Main class Key: SLING-953 URL: https://issues.apache.org/jira/browse/SLING-953 Project: Sling Issue Type: Improvement Components: Launchpad Launcher Affects Versions: Launchpad Base 2.0.4 Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: Launchpad Base 2.0.4 Currently the command line is pre-parsed in the real Main class -- o.a.s.launchpad.app.Main -- to extract the sling.home folder setting and parsed fully in the MainDelegate class to which it is handed calling the Launcher.setCommandLine(String[]) method. It would make more sense to parse the command line completely in the Main class and pass a map of command line args into the MainDelagate. This allows for more elaborate command line argument handling in the Main class (like start, stop, status support for system service support). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-954) Add suppport for TCP/IP based control connection for Sling standalone app
[ https://issues.apache.org/jira/browse/SLING-954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger resolved SLING-954. - Resolution: Fixed Implemented control connection support as described in Rev. 771647 Add suppport for TCP/IP based control connection for Sling standalone app - Key: SLING-954 URL: https://issues.apache.org/jira/browse/SLING-954 Project: Sling Issue Type: New Feature Components: Launchpad Launcher Affects Versions: Launchpad Base 2.0.4 Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: Launchpad Base 2.0.4 Currently the Sling standalone application can only be stopped by stopping the system bundle or by killing the Sling process. To better control Sling control connection support based on TCP/IP would be nice. This way the same sling standalone application may be used to start sling, to check a running sling instance and to stop a running sling instance. The following command line arguments are added: start - Sling opens a TCP/IP server socket for the control conneciton status - Checks whether a Sling instance is listening on a TCP/IP socket stop - Stops a Sling instance listening on a TCP/IP socket none of the above - starts Sling without listening on a TCP/IP socket The socket to listen on (start option) or to send the command to (status, stop) is configured with the -j command line option. This option takes an argument of the following form: host:port -- host name or ip address and port number of the socket port -- port number on localhost (InetAddress.getLocalHost()) of the socket none or -j not specified -- defaults to port 63000 on localhost Note, that setting any host name or IP address, which is reachable from remote systems may be considered as security issue, since the connection is not secured by password or such. For this reason the default interface to listen on is local host and the server socket is only created if explicitly asked for with the start parameter. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (SLING-954) Add suppport for TCP/IP based control connection for Sling standalone app
[ https://issues.apache.org/jira/browse/SLING-954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed SLING-954. --- Updated the launchpad documentation at http://cwiki.apache.org/SLING/the-sling-launchpad.html Add suppport for TCP/IP based control connection for Sling standalone app - Key: SLING-954 URL: https://issues.apache.org/jira/browse/SLING-954 Project: Sling Issue Type: New Feature Components: Launchpad Launcher Affects Versions: Launchpad Base 2.0.4 Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: Launchpad Base 2.0.4 Currently the Sling standalone application can only be stopped by stopping the system bundle or by killing the Sling process. To better control Sling control connection support based on TCP/IP would be nice. This way the same sling standalone application may be used to start sling, to check a running sling instance and to stop a running sling instance. The following command line arguments are added: start - Sling opens a TCP/IP server socket for the control conneciton status - Checks whether a Sling instance is listening on a TCP/IP socket stop - Stops a Sling instance listening on a TCP/IP socket none of the above - starts Sling without listening on a TCP/IP socket The socket to listen on (start option) or to send the command to (status, stop) is configured with the -j command line option. This option takes an argument of the following form: host:port -- host name or ip address and port number of the socket port -- port number on localhost (InetAddress.getLocalHost()) of the socket none or -j not specified -- defaults to port 63000 on localhost Note, that setting any host name or IP address, which is reachable from remote systems may be considered as security issue, since the connection is not secured by password or such. For this reason the default interface to listen on is local host and the server socket is only created if explicitly asked for with the start parameter. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
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
[jira] Created: (SLING-955) Multi-value sling:vanityPath properties not properly handled
Multi-value sling:vanityPath properties not properly handled Key: SLING-955 URL: https://issues.apache.org/jira/browse/SLING-955 Project: Sling Issue Type: Bug Components: JCR Resource Affects Versions: JCR Resource 2.0.4 Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: JCR Resource 2.0.4 Due to a limitation in the JCR Query specification and implementation, the MapEntries.loadVanityPaths method does not currently resolve sling:vanityPath properties correctly if the properties happen to be multi-value properties. The workaround for this issue is to not use ResourceResolver.queryResources method to get the query result rows but to use the ResourceResolver.findResources method and to manually access the properties through the resources returned. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (SLING-955) Multi-value sling:vanityPath properties not properly handled
[ https://issues.apache.org/jira/browse/SLING-955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed SLING-955. --- Resolution: Fixed Fixed in Rev. 771666 by using the ResourceResolver.findResources method to first find matching resources and the ValueMap adapter to then access the vanity path setup. Multi-value sling:vanityPath properties not properly handled Key: SLING-955 URL: https://issues.apache.org/jira/browse/SLING-955 Project: Sling Issue Type: Bug Components: JCR Resource Affects Versions: JCR Resource 2.0.4 Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: JCR Resource 2.0.4 Due to a limitation in the JCR Query specification and implementation, the MapEntries.loadVanityPaths method does not currently resolve sling:vanityPath properties correctly if the properties happen to be multi-value properties. The workaround for this issue is to not use ResourceResolver.queryResources method to get the query result rows but to use the ResourceResolver.findResources method and to manually access the properties through the resources returned. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Event Listeners
Are there any facilities in sling for registering jcr event listeners ? Both the external javax.jcr.observation.EventListener and the SynchronousEventListener type. Ian
Sling app -j option does not work (was: [jira] Closed: (SLING-954)...)
On Tue, May 5, 2009 at 12:08 PM, Felix Meschberger (JIRA) j...@apache.org wrote: ...Felix Meschberger closed SLING-954 I just tried this in launchpad/app, and java -jar target/org.apache.sling.launchpad.app-4-incubator-SNAPSHOT.jar -j says Unrecognized option j=j, although the -j option is provided in the usage message that follows. -Bertrand
[jira] Reopened: (SLING-954) Add suppport for TCP/IP based control connection for Sling standalone app
[ https://issues.apache.org/jira/browse/SLING-954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger reopened SLING-954: - -j option prevents MainDelegate from operating. The Main class should probably remove that option from the internal map. Reported by Bertrand Delacretaz in http://markmail.org/message/btsfd3an5o5wcf3u Add suppport for TCP/IP based control connection for Sling standalone app - Key: SLING-954 URL: https://issues.apache.org/jira/browse/SLING-954 Project: Sling Issue Type: New Feature Components: Launchpad Launcher Affects Versions: Launchpad Base 2.0.4 Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: Launchpad Base 2.0.4 Currently the Sling standalone application can only be stopped by stopping the system bundle or by killing the Sling process. To better control Sling control connection support based on TCP/IP would be nice. This way the same sling standalone application may be used to start sling, to check a running sling instance and to stop a running sling instance. The following command line arguments are added: start - Sling opens a TCP/IP server socket for the control conneciton status - Checks whether a Sling instance is listening on a TCP/IP socket stop - Stops a Sling instance listening on a TCP/IP socket none of the above - starts Sling without listening on a TCP/IP socket The socket to listen on (start option) or to send the command to (status, stop) is configured with the -j command line option. This option takes an argument of the following form: host:port -- host name or ip address and port number of the socket port -- port number on localhost (InetAddress.getLocalHost()) of the socket none or -j not specified -- defaults to port 63000 on localhost Note, that setting any host name or IP address, which is reachable from remote systems may be considered as security issue, since the connection is not secured by password or such. For this reason the default interface to listen on is local host and the server socket is only created if explicitly asked for with the start parameter. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Sling app -j option does not work (was: [jira] Closed: (SLING-954)...)
Hi Bertrand, Bertrand Delacretaz schrieb: On Tue, May 5, 2009 at 12:08 PM, Felix Meschberger (JIRA) j...@apache.org wrote: ...Felix Meschberger closed SLING-954 I just tried this in launchpad/app, and java -jar target/org.apache.sling.launchpad.app-4-incubator-SNAPSHOT.jar -j says Unrecognized option j=j, although the -j option is provided in the usage message that follows. Thanks for reporting, will fix this. But actually, the -j option by itself does nothing and has no effect unless the start, stop or status option is also used. Regards Felix -Bertrand
[jira] Resolved: (SLING-954) Add suppport for TCP/IP based control connection for Sling standalone app
[ https://issues.apache.org/jira/browse/SLING-954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger resolved SLING-954. - Resolution: Fixed Implemented fix in Rev. 771696: * -h option support moved to Main class to not clutter usage output with log messages * streamlined logging in MainDelegate class * Remove all Main specific options (start, stop, status, -j, -h) before calling MainDelagate Add suppport for TCP/IP based control connection for Sling standalone app - Key: SLING-954 URL: https://issues.apache.org/jira/browse/SLING-954 Project: Sling Issue Type: New Feature Components: Launchpad Launcher Affects Versions: Launchpad Base 2.0.4 Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: Launchpad Base 2.0.4 Currently the Sling standalone application can only be stopped by stopping the system bundle or by killing the Sling process. To better control Sling control connection support based on TCP/IP would be nice. This way the same sling standalone application may be used to start sling, to check a running sling instance and to stop a running sling instance. The following command line arguments are added: start - Sling opens a TCP/IP server socket for the control conneciton status - Checks whether a Sling instance is listening on a TCP/IP socket stop - Stops a Sling instance listening on a TCP/IP socket none of the above - starts Sling without listening on a TCP/IP socket The socket to listen on (start option) or to send the command to (status, stop) is configured with the -j command line option. This option takes an argument of the following form: host:port -- host name or ip address and port number of the socket port -- port number on localhost (InetAddress.getLocalHost()) of the socket none or -j not specified -- defaults to port 63000 on localhost Note, that setting any host name or IP address, which is reachable from remote systems may be considered as security issue, since the connection is not secured by password or such. For this reason the default interface to listen on is local host and the server socket is only created if explicitly asked for with the start parameter. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
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
Re: Event Listeners
On 5 May 2009, at 14:26, Carsten Ziegeler wrote: 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 I am after is a listener that only fires on the cluster node that created it. I need this because I want to ensure that all nodes, however they are created have certain properties (like the id of the creator) if appropriate. The only way I have found to do this is a SynchronousEventListener, however this is internal to Jackrabbit and so its not possible to activate a bundle containing this. The SLING-944 patch starts to get close, but its bound to EventListener so one copy of the event will fire on all nodes in a cluster, depending on how the OSGi Event admin service is wired this might mean that you will see duplicates of the event in a cluster. so your use case may be the same. (btw, I agree, the session binding is not ideal for general purpose events that have no connection to jcr) Ian Carsten -- Carsten Ziegeler cziege...@apache.org
Re: Event Listeners
On Tue, May 5, 2009 at 3:55 PM, Ian Boston i...@tfd.co.uk wrote:
I am after is a listener that only fires on the cluster node that created
it. I need this because I want to ensure that all nodes, however they are
created have certain properties (like the id of the creator) if appropriate.
Jackrabbit has support for this. There is the JackrabbitEvent
interface [1] which extends javax.jcr.Event and adds a method
isExternal, that signals whether an event was created on the local
cluster node (false) or comes from another cluster node (true).
Casting inside a normal EventListener does the trick:
if (event instanceof JackrabbitEvent !((JackrabbitEvent)
event).isExternal()) {
// local event
}
[1]
http://jackrabbit.apache.org/api/1.5/org/apache/jackrabbit/api/observation/JackrabbitEvent.html
Regards,
Alex
--
Alexander Klimetschek
alexander.klimetsc...@day.com
[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
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? BR, Jukka Zitting
Re: [IMP] Code freeze
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? -Bertrand
Re: Event Listeners
On Tue, May 5, 2009 at 3:26 PM, Carsten Ziegeler cziege...@apache.org wrote: 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 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. regards, toby
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: Event Listeners
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? -Bertrand
Re: [IMP] Code freeze
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. 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. BR, Jukka Zitting
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: Event Listeners
On 5 May 2009, at 15:36, Alexander Klimetschek wrote:
On Tue, May 5, 2009 at 3:55 PM, Ian Boston i...@tfd.co.uk wrote:
I am after is a listener that only fires on the cluster node that
created
it. I need this because I want to ensure that all nodes, however
they are
created have certain properties (like the id of the creator) if
appropriate.
Jackrabbit has support for this. There is the JackrabbitEvent
interface [1] which extends javax.jcr.Event and adds a method
isExternal, that signals whether an event was created on the local
cluster node (false) or comes from another cluster node (true).
Casting inside a normal EventListener does the trick:
if (event instanceof JackrabbitEvent !((JackrabbitEvent)
event).isExternal()) {
// local event
}
Ahh, Ok hadn't seen that.
Looks like it just changed to 1.5 in Sling.
Do you know if there are plans to expose SynchronousEventListener in
the same way, that would remove any need to do anything in the
jackrabbit-server bundle. ?
Thanks
Ian
[1]
http://jackrabbit.apache.org/api/1.5/org/apache/jackrabbit/api/observation/JackrabbitEvent.html
Regards,
Alex
--
Alexander Klimetschek
alexander.klimetsc...@day.com
