Re: Re build error
H Jon,
On Fri, Aug 29, 2008 at 1:36 AM, Jon Gorrono <[EMAIL PROTECTED]> wrote:
> ...I changed the visibility of the ContentCreator interface to be public
> and the tests succeed now
>
> The build now fails much later on (as a result of my 'fix'?), in one
> of the executions of LaunchPad's dependency expansion phase:
>
> [INFO] [dependency:unpack-dependencies {execution: inline-framework-bundles}]
> [INFO] Expanding:
> /home/ccjon/.m2/repository/org/apache/felix/org.apache.felix.framework/1.0.4/org.apache.felix.framework-1.0.4.jar
> into /home/ccjon/sling/launchpad/app/target/classes
> org.codehaus.plexus.archiver.ArchiverException: The source must not be
> a directory
Coud you give us the exact change that you made to the ContentCreator
(ideally a patch), and indicate in which version of Sling (svn
revision number) you're seeing the problem?
I'd like to reproduce it and I have a similar macosx environment, but
I've been running many full builds this week without problems.
-Bertrand
Creating paths in the post servlet
Hi all, I currently have the need to create a path by posting to the SlingPostServlet, eg. /some/very/long/path, where only /some exists, and very/long/path has to be created in the repo. Now I miss two features in the current SlingPostServlet: a) specify only one intermediate jcr:primaryType (instead of /some/very/jcr:primaryType=my:type, /some/very/long/jcr:primaryType=my:type, etc.) for all the intermediate nodes that have to be created b) the path is built right from the user input, so I need a nameHint path (eg. user enters "Verü/Lon g/Path", => pathHint = "/some/Verü/Lon g/Path" sent to server, => generated node path is "/some/ver_/lon_g/path"); I could do this on the client-side, but I don't want to reimplement the nameHint -> valid name conversion, it's good to have a central place for it A different solution would be to make several HTTP requests, one for each node in the path, but this would also be more code complexity on the client side and not transactional. WDYT? Overkill or nice-to-have feature? Regards, Alex -- Alexander Klimetschek [EMAIL PROTECTED]
Re: Creating paths in the post servlet
On 8/29/08, Alexander Klimetschek <[EMAIL PROTECTED]> wrote: > Hi all, > > I currently have the need to create a path by posting to the > SlingPostServlet, eg. /some/very/long/path, where only /some exists, > and very/long/path has to be created in the repo. Now I miss two > features in the current SlingPostServlet: > > a) specify only one intermediate jcr:primaryType (instead of > /some/very/jcr:primaryType=my:type, > /some/very/long/jcr:primaryType=my:type, etc.) for all the > intermediate nodes that have to be created are you able to specify the default nodetypes for new nodes in the nodetype of "/some" ? if yes, this should work automatically since the repository selects the correct nodetype. > b) the path is built right from the user input, so I need a nameHint > path (eg. user enters "Verü/Lon g/Path", => pathHint = "/some/Verü/Lon > g/Path" sent to server, => generated node path is > "/some/ver_/lon_g/path"); I could do this on the client-side, but I > don't want to reimplement the nameHint -> valid name conversion, it's > good to have a central place for it but how would you differentiate from the case where a '/' is present in the hint but should not create deep paths? > A different solution would be to make several HTTP requests, one for > each node in the path, but this would also be more code complexity on > the client side and not transactional. > > WDYT? Overkill or nice-to-have feature? i would create the path clientsided... regards, toby
Re: Creating paths in the post servlet
On Fri, Aug 29, 2008 at 9:42 AM, Alexander Klimetschek <[EMAIL PROTECTED]> wrote: > ...b) the path is built right from the user input, so I need a nameHint > path (eg. user enters "Verü/Lon g/Path", => pathHint = "/some/Verü/Lon > g/Path" sent to server, => generated node path is > "/some/ver_/lon_g/path"); I could do this on the client-side, but I > don't want to reimplement the nameHint -> valid name conversion, it's > good to have a central place for it... We could make the path conversion function available in a servlet, you would post the user-entered path to a servlet (at /bin/namehint maybe?), and get back the converted path. -Bertrand
Re: Creating paths in the post servlet
On Fri, Aug 29, 2008 at 10:46 AM, Alexander Klimetschek <[EMAIL PROTECTED]> wrote: > On Fri, Aug 29, 2008 at 10:22 AM, Tobias Bocanegra > <[EMAIL PROTECTED]> wrote: >>> a) specify only one intermediate jcr:primaryType (instead of >>> /some/very/jcr:primaryType=my:type, >>> /some/very/long/jcr:primaryType=my:type, etc.) for all the >>> intermediate nodes that have to be created >> are you able to specify the default nodetypes for new nodes in the >> nodetype of "/some" ? if yes, this should work automatically since the >> repository selects the correct nodetype. > > No, unfortunately not. /some is nt:unstructured. Oh, actually that works, since "/some/very" should exist already (in my use-case). And "very" defines a default node type for its children. Thanks for the tip! Regards, Alex -- Alexander Klimetschek [EMAIL PROTECTED]
Re: Creating paths in the post servlet
On Fri, Aug 29, 2008 at 10:22 AM, Tobias Bocanegra <[EMAIL PROTECTED]> wrote: >> a) specify only one intermediate jcr:primaryType (instead of >> /some/very/jcr:primaryType=my:type, >> /some/very/long/jcr:primaryType=my:type, etc.) for all the >> intermediate nodes that have to be created > are you able to specify the default nodetypes for new nodes in the > nodetype of "/some" ? if yes, this should work automatically since the > repository selects the correct nodetype. No, unfortunately not. /some is nt:unstructured. >> b) the path is built right from the user input, so I need a nameHint >> path (eg. user enters "Verü/Lon g/Path", => pathHint = "/some/Verü/Lon >> g/Path" sent to server, => generated node path is >> "/some/ver_/lon_g/path"); I could do this on the client-side, but I >> don't want to reimplement the nameHint -> valid name conversion, it's >> good to have a central place for it > but how would you differentiate from the case where a '/' is present > in the hint but should not create deep paths? By using a different request parameter name for that hint, eg. :pathHint instead of :nameHint. >> A different solution would be to make several HTTP requests, one for >> each node in the path, but this would also be more code complexity on >> the client side and not transactional. >> >> WDYT? Overkill or nice-to-have feature? > > i would create the path clientsided... Well, my current solution is to built it server-side in my own servlet, because similar functionality is already present there. Client-sided seems to be quicker and maybe simpler, but IMHO this hint -> path conversion belongs to the server, because it is a JCR-specific thing (set of allowed chars). Bertrand's proposal is ok, but it requires you to do 2 requests to the server... Regards, Alex -- Alexander Klimetschek [EMAIL PROTECTED]
[jira] Closed: (SLING-428) [Javascript] allow Server-side inclusion of Javascript files
[ https://issues.apache.org/jira/browse/SLING-428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bertrand Delacretaz closed SLING-428. - Assignee: Bertrand Delacretaz (was: Felix Meschberger) Integration tests for the load() and print() functions added in revisions 690209 and 690210 > [Javascript] allow Server-side inclusion of Javascript files > > > Key: SLING-428 > URL: https://issues.apache.org/jira/browse/SLING-428 > Project: Sling > Issue Type: Improvement > Components: Scripting >Reporter: Lars Trieloff >Assignee: Bertrand Delacretaz > Fix For: 2.0.0 > > Attachments: SLING-428.patch > > > For the sake of modularizing server-side Javascript libraries, it is > advisable to have an inclusion mechanism. Javascript does not have an > standardized way of handling inclusions, so I propose to use the conventions > established by the Rhino Javascript Shell > (http://www.mozilla.org/rhino/shell.html) which is introducing a load() > function in the global scope, loading and evaluating a Javascript file in the > current scope. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-339) Implement job acknowledge
[ https://issues.apache.org/jira/browse/SLING-339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12626957#action_12626957 ] Carsten Ziegeler commented on SLING-339: When implementing an own job processor, it is advisable to use the EventUtil#processJob method. The first implementation will add the acknowledges to this method, so when this method is used, everything is fine. The background clean up thread will be enhanced to check for non acknowledge jobs and mark them as failed. (calling finish with failed value) > Implement job acknowledge > - > > Key: SLING-339 > URL: https://issues.apache.org/jira/browse/SLING-339 > Project: Sling > Issue Type: Improvement > Components: Event >Affects Versions: Extensions Event 2.0.2 >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler >Priority: Blocker > Fix For: Extensions Event 2.0.4 > > Original Estimate: 0h > Remaining Estimate: 0h > > Currently there is no acknowledge that someone is interested in processing a > job. This results in the problem > that jobs might end up locked in the repository for ever if there is noone > interested in processing this kind of > job. > This couldbe solved by requiring that a job processor acknowledges the > receival of a job and thereby indicates that it will process this job. This > could also be used to deny other processors for this job. > If a job is not acknowledged during a specified timeout, the job will be > removed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: sling & FCKeditor
On Wed, Aug 27, 2008 at 10:12 PM, Juerg Meier <[EMAIL PROTECTED]> wrote: > ...This is my 2nd wiring of this posting, first one has been rejected as it > was qualified as spam, so I intentionally put spaces into URIs and the > word "sl ing" After checking with ASF infrastructure, turns out that your messages got marked as spam mainly because of the WHOIS_WHOISGUARD rule (content based, and worth 3.399 points). f c k editor.net is listed with whoisguard, so apparently including that name/URL in a message (multiple times in your case) causes a higher spam score. We'll see if this message makes it through ;-) -Bertrand
[jira] Created: (SLING-635) Stop thread for own job queues when it is unused
Stop thread for own job queues when it is unused Key: SLING-635 URL: https://issues.apache.org/jira/browse/SLING-635 Project: Sling Issue Type: Improvement Components: Event Affects Versions: Extensions Event 2.0.2 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Extensions Event 2.0.4 The background thread should check if a job queue thread has been unused for a longer time and then stop it. This avoids too many idle threads. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Annoyance during update of bundles
Hi all, when I update a bundle containing a servlet (eg. servlet path = /bin/myservlet) and I hit my curl command for testing that servlet (POST to /bin/myservlet + a few specific params) too fast, ie. in the time when the old version of the bundle is gone, but the new version is not yet started, and hence nothing is registered under /bin/myservlet, the request is handled by the SlingPostServlet, which in this case creates a new JCR node under /bin/myservlet. Any ideas how to circumvent this little annoyance during development? Regards, Alex PS: I would like to have a nice "ding" sound once the bundle update completed successfully ;-) -- Alexander Klimetschek [EMAIL PROTECTED]
Re: Re build error
.~/sling]$ svn info
Path: .
URL: http://svn.apache.org/repos/asf/incubator/sling/trunk
Repository Root: http://svn.apache.org/repos/asf
Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68
Revision: 689701
Node Kind: directory
Schedule: normal
Last Changed Author: fmeschbe
Last Changed Rev: 689618
Last Changed Date: 2008-08-27 14:05:21 -0700 (Wed, 27 Aug 2008)
Attached patch taken at the above sandbox rev and url and from the
root of the sling source tree.
On Fri, Aug 29, 2008 at 12:14 AM, Bertrand Delacretaz
<[EMAIL PROTECTED]> wrote:
> H Jon,
>
> On Fri, Aug 29, 2008 at 1:36 AM, Jon Gorrono <[EMAIL PROTECTED]> wrote:
>> ...I changed the visibility of the ContentCreator interface to be public
>> and the tests succeed now
>>
>> The build now fails much later on (as a result of my 'fix'?), in one
>> of the executions of LaunchPad's dependency expansion phase:
>>
>> [INFO] [dependency:unpack-dependencies {execution: inline-framework-bundles}]
>> [INFO] Expanding:
>> /home/ccjon/.m2/repository/org/apache/felix/org.apache.felix.framework/1.0.4/org.apache.felix.framework-1.0.4.jar
>> into /home/ccjon/sling/launchpad/app/target/classes
>> org.codehaus.plexus.archiver.ArchiverException: The source must not be
>> a directory
>
> Coud you give us the exact change that you made to the ContentCreator
> (ideally a patch), and indicate in which version of Sling (svn
> revision number) you're seeing the problem?
>
> I'd like to reproduce it and I have a similar macosx environment, but
> I've been running many full builds this week without problems.
>
> -Bertrand
>
--
Jon Gorrono
email{>+[>+++>>+++>+-]>+++.>.<---.>-.+++..---.-.+.>+.<++.<.+.---.>+.<.>---.>>+.<<<.-.>++.}
http{ats.ucdavis.edu}
Index: jcr/contentloader/src/main/java/org/apache/sling/jcr/contentloader/internal/ContentCreator.java
===
--- jcr/contentloader/src/main/java/org/apache/sling/jcr/contentloader/internal/ContentCreator.java (revision 689701)
+++ jcr/contentloader/src/main/java/org/apache/sling/jcr/contentloader/internal/ContentCreator.java (working copy)
@@ -28,7 +28,7 @@
*
* @since 2.0.4
*/
-interface ContentCreator {
+public interface ContentCreator {
/**
* Create a new node.
Re: Annoyance during update of bundles
Am 29.08.2008 um 16:50 schrieb Alexander Klimetschek: Hi all, when I update a bundle containing a servlet (eg. servlet path = /bin/myservlet) and I hit my curl command for testing that servlet (POST to /bin/myservlet + a few specific params) too fast, ie. in the time when the old version of the bundle is gone, but the new version is not yet started, and hence nothing is registered under /bin/myservlet, the request is handled by the SlingPostServlet, which in this case creates a new JCR node under /bin/myservlet. Any ideas how to circumvent this little annoyance during development? if you don't need it for your development and testing you can just disable the SlingPostServlet service in the Felix console regards alex
Re: Annoyance during update of bundles
how about stalling requests until the update is complete ? regards, toby On 8/29/08, Alexander Klimetschek <[EMAIL PROTECTED]> wrote: > Hi all, > > when I update a bundle containing a servlet (eg. servlet path = > /bin/myservlet) and I hit my curl command for testing that servlet > (POST to /bin/myservlet + a few specific params) too fast, ie. in the > time when the old version of the bundle is gone, but the new version > is not yet started, and hence nothing is registered under > /bin/myservlet, the request is handled by the SlingPostServlet, which > in this case creates a new JCR node under /bin/myservlet. > > Any ideas how to circumvent this little annoyance during development? > > Regards, > Alex > > PS: I would like to have a nice "ding" sound once the bundle update > completed successfully ;-) > > > -- > Alexander Klimetschek > [EMAIL PROTECTED] >
Re: Annoyance during update of bundles
Hi, On Fri, Aug 29, 2008 at 8:33 PM, Tobias Bocanegra <[EMAIL PROTECTED]> wrote: > how about stalling requests until the update is complete ? That would also make startup time when a number of bundles are just being loaded much more predictable. Currently you just need to wait a while until all bundles are in place, otherwise you get various different failures when you try to access your application. BR, Jukka Zitting
Re: sling & FCKeditor
Poor Frederico Caldeira Knabben! On Fri, 2008-08-29 at 14:56 +0200, Bertrand Delacretaz wrote: > On Wed, Aug 27, 2008 at 10:12 PM, Juerg Meier <[EMAIL PROTECTED]> wrote: > > ...This is my 2nd wiring of this posting, first one has been rejected as it > > was qualified as spam, so I intentionally put spaces into URIs and the > > word "sl ing" > > After checking with ASF infrastructure, turns out that your messages > got marked as spam mainly because of the WHOIS_WHOISGUARD rule > (content based, and worth 3.399 points). > > f c k editor.net is listed with whoisguard, so apparently including > that name/URL in a message (multiple times in your case) causes a > higher spam score. > > We'll see if this message makes it through ;-) > > -Bertrand
