date:20080129

OK. Thanks!
But I'm not so got at maven. Am I correct in assuming that the arguments are
set somewhere in the pom.xml in the launchpad directory nearby some lines
saying jett6 .. ??

cheers,
PS

On Jan 29, 2008 9:19 AM, Felix Meschberger [EMAIL PROTECTED] wrote:

 Hi Peter,

 Am Dienstag, den 29.01.2008, 09:12 +0100 schrieb Peter Svensson:
  Sorry Felix. I never got to curl. What I did was to try to mount -t
 davfs
  ...  and I did get 302 reported as an errro by linux mount, which means
 it's
  not compatible with handling that, so that's the reason, probably.

 Good note ! Thanks for the clarification, this will certainly flow into
 the docs.

 
  When I tried it with /dav/default, it worked fine (of course).
 
  Another thing I wonder is where to set memory limits. When I copy my
 project
  into Sling, I always get OutOfMemoryError. Dojo itself is thousands of
  files.

 You set this using java runtime arguments -Xmx. If your OOME is caused
 by PermGen overruns, you might want to try the -XX:MaxPermSize option.
 See [1] for details.

 Regards
 Felix

 [1] http://java.sun.com/javase/technologies/hotspot/vmoptions.jsp

 
  Cheers,
  PS
 
  On Jan 29, 2008 9:02 AM, Felix Meschberger [EMAIL PROTECTED] wrote:
 
   Hi Peter,
  
   Hmm, so you say
  
  curl -D - -X OPTIONS http://admin:[EMAIL PROTECTED]:8080/dav/default
  
   works, but
  
  curl -D - -X OPTIONS http://admin:[EMAIL PROTECTED]:8080/dav
  
   gives you the IllegalStateException in the log ?
  
   This should not be the case as the second URL should be redirected
 (302)
   to the first.
  
   Regards
   Felix
  
   Am Montag, den 28.01.2008, 19:21 +0100 schrieb Peter Svensson:
Ahaaa!  In your previous psot, you misspelled the url :) You said it
 was
different, and only /dav, but now I saw that you write /dev/default
 in
   this
post.
And that worked (releived).
   
Back to work
   
PS
   
On Jan 25, 2008 5:59 PM, Bertrand Delacretaz [EMAIL PROTECTED]
 
   wrote:
   
 Hi Peter,

 On Jan 25, 2008 4:58 AM, Peter Svensson [EMAIL PROTECTED]
 wrote:

  ...2008-01-25 03:30:55.980::WARN:  Committed before 401
 Unauthorized
  2008-01-25 03:30:55.981::WARN:  /dav/
  java.lang.IllegalStateException: Committed...

 Once you get a chance to try again, you could try with curl to
 make
 sure your login problem is unrelated to the WebDAV client.

 After starting launchpad-webapp with mvn package jetty:start,

   curl -D - -X OPTIONS
 http://admin:[EMAIL PROTECTED]:8080/dav/default

 should say

 HTTP/1.1 200 OK
 DAV: 1,2,version-control,version-history,label
 Allow: OPTIONS, GET, HEAD, POST, TRACE, PROPFIND, PROPPATCH,
 MKCOL,
 COPY, PUT, DELETE, MOVE, LOCK, UNLOCK, VERSION-CONTROL
 MS-Author-Via: DAV
 Content-Length: 0
 Server: Jetty(6.1.5)

 The WebDAV service takes a few seconds to startup, about 5 on my
   macbook
 pro.

 -Bertrand

Re: Change in default handler

Hi Peter,

Exactly as David said, I modified this behaviour yesterday. If you
update the sling/servlet-resolver project and redeploy the bundle, the
js file should be delivered as expected again.

Background: With the most recent changes to the Sling API I implemented
automatic server-side execution of directly addressed scripts. This was
implemented by simple checking whether the addressed resource adapts to
a servlet, which is the case .js files. This is now changed to only
execute such directly addressed script of the request extension
(request.getRequestPathInfo().getExtension()) is not null.

Regards
Felix

Am Dienstag, den 29.01.2008, 08:46 +0100 schrieb David Nuescheler:
hi peter,

i think this is an issue that sling tried to execute the js file instead
of just delivering it. this was part of a bigger discussion and should
have been removed by now.

felix may have more details.

regards,
david

On 1/28/08, Peter Svensson [EMAIL PROTECTED] wrote:
Hi, I've finally found some time again to see if I can get Sling and Bunkai
to work together. My plan at the moment is to create my own custom esp
script to handle serialization of resources hierarchies into json, in a way
that can be consumed by Dojo.

I've managed to mount the latest svn revision of Sling and use Launchpad.
I've copied Bunkai into the webDAv mount, and manage to access my html page.
The css gets read correctly, but when I try to laod any js file, I get this;

javax.script.Bindings.put(Ljava/lang/String;Ljava/lang/Object;)Ljava/lang/Object;
(500)

The requested URL /bunkai/dojo-1.0.2/dojo/dojo.js resulted in an error in
Sling Core Default Servlet.
Exception:

java.lang.NoSuchMethodError:
javax.script.Bindings.put(Ljava/lang/String;Ljava/lang/Object;)Ljava/lang/Object;
at
org.apache.sling.scripting.resolver.impl.DefaultSlingScript.verifySlingBindings(DefaultSlingScript.java:305)
at
org.apache.sling.scripting.resolver.impl.DefaultSlingScript.eval(DefaultSlingScript.java:97)
at
org.apache.sling.scripting.resolver.impl.DefaultSlingScript.service(DefaultSlingScript.java:162)
at
org.apache.sling.servlet.resolver.defaults.DefaultServlet.doGet(DefaultServlet.java:81)

And I understand that this means that the current Launchpad does not
know how to provide .js files.
Most probably, it's a simple operation to copy code or classes from
the old microsling project, to get this working, but I'm not sure how
to go about it.

Any directions welcome :)

Cheers,
PS

Re: Change in default handler

Hi Peter,

Am Dienstag, den 29.01.2008, 09:05 +0100 schrieb Peter Svensson:
 Hi Felix and all,
 I did actually read that discussion, I just didn't understand it :)
 Thanks for the info. I'll get on the case tonight, and finally be able to
 write my own json content serializer.
 
 Could some kind soul also point out again where the agreement that one shall
 sign is, I've looked around in my inbox but can't seem to find it.

Are you talking about the CLA ? This is available at [1].

On the other hand we are planning on creating an open wiki [2], so this
is of less importance. Still having a signed CLA on file is a good
thing :-)

Regards
Felix

[1] http://www.apache.org/licenses/icla.txt
[2]
http://www.mail-archive.com/sling-dev@incubator.apache.org/msg02027.html

 Thanks,
 PS
 
 On Jan 29, 2008 9:00 AM, Felix Meschberger [EMAIL PROTECTED] wrote:
 
  Hi Peter,
 
  Exactly as David said, I modified this behaviour yesterday. If you
  update the sling/servlet-resolver project and redeploy the bundle, the
  js file should be delivered as expected again.
 
  Background: With the most recent changes to the Sling API I implemented
  automatic server-side execution of directly addressed scripts. This was
  implemented by simple checking whether the addressed resource adapts to
  a servlet, which is the case .js files. This is now changed to only
  execute such directly addressed script of the request extension
  (request.getRequestPathInfo().getExtension()) is not null.
 
  Regards
  Felix
 
  Am Dienstag, den 29.01.2008, 08:46 +0100 schrieb David Nuescheler:
   hi peter,
  
   i think this is an issue that sling tried to execute the js file instead
   of just delivering it. this was part of a bigger discussion and should
   have been removed by now.
  
   felix may have more details.
  
   regards,
   david
  
   On 1/28/08, Peter Svensson [EMAIL PROTECTED] wrote:
Hi, I've finally found some time again to see if I can get Sling and
  Bunkai
to work together. My plan at the moment is to create my own custom esp
script to handle serialization of resources hierarchies into json, in
  a way
that can be consumed by Dojo.
   
I've managed to mount the latest svn revision of Sling and use
  Launchpad.
I've copied Bunkai into the webDAv mount, and manage to access my html
  page.
The css gets read correctly, but when I try to laod any js file, I get
  this;
   
javax.script.Bindings.put
  (Ljava/lang/String;Ljava/lang/Object;)Ljava/lang/Object;
(500)
   
The requested URL /bunkai/dojo-1.0.2/dojo/dojo.js resulted in an error
  in
Sling Core Default Servlet.
Exception:
   
java.lang.NoSuchMethodError:
javax.script.Bindings.put
  (Ljava/lang/String;Ljava/lang/Object;)Ljava/lang/Object;
at
  org.apache.sling.scripting.resolver.impl.DefaultSlingScript.verifySlingBindings
  (DefaultSlingScript.java:305)
at
  org.apache.sling.scripting.resolver.impl.DefaultSlingScript.eval(
  DefaultSlingScript.java:97)
at
  org.apache.sling.scripting.resolver.impl.DefaultSlingScript.service(
  DefaultSlingScript.java:162)
at
  org.apache.sling.servlet.resolver.defaults.DefaultServlet.doGet(
  DefaultServlet.java:81)
   
And I understand that this means that the current Launchpad does not
know how to provide .js files.
Most probably, it's a simple operation to copy code or classes from
the old microsling project, to get this working, but I'm not sure how
to go about it.
   
Any directions welcome :)
   
Cheers,
PS

Re: Change in default handler

Hi Felix and all,
I did actually read that discussion, I just didn't understand it :)
Thanks for the info. I'll get on the case tonight, and finally be able to
write my own json content serializer.

Could some kind soul also point out again where the agreement that one shall
sign is, I've looked around in my inbox but can't seem to find it.
Thanks,
PS

On Jan 29, 2008 9:00 AM, Felix Meschberger [EMAIL PROTECTED] wrote:

 Hi Peter,

 Exactly as David said, I modified this behaviour yesterday. If you
 update the sling/servlet-resolver project and redeploy the bundle, the
 js file should be delivered as expected again.

 Background: With the most recent changes to the Sling API I implemented
 automatic server-side execution of directly addressed scripts. This was
 implemented by simple checking whether the addressed resource adapts to
 a servlet, which is the case .js files. This is now changed to only
 execute such directly addressed script of the request extension
 (request.getRequestPathInfo().getExtension()) is not null.

 Regards
 Felix

 Am Dienstag, den 29.01.2008, 08:46 +0100 schrieb David Nuescheler:
  hi peter,
 
  i think this is an issue that sling tried to execute the js file instead
  of just delivering it. this was part of a bigger discussion and should
  have been removed by now.
 
  felix may have more details.
 
  regards,
  david
 
  On 1/28/08, Peter Svensson [EMAIL PROTECTED] wrote:
   Hi, I've finally found some time again to see if I can get Sling and
 Bunkai
   to work together. My plan at the moment is to create my own custom esp
   script to handle serialization of resources hierarchies into json, in
 a way
   that can be consumed by Dojo.
  
   I've managed to mount the latest svn revision of Sling and use
 Launchpad.
   I've copied Bunkai into the webDAv mount, and manage to access my html
 page.
   The css gets read correctly, but when I try to laod any js file, I get
 this;
  
   javax.script.Bindings.put
 (Ljava/lang/String;Ljava/lang/Object;)Ljava/lang/Object;
   (500)
  
   The requested URL /bunkai/dojo-1.0.2/dojo/dojo.js resulted in an error
 in
   Sling Core Default Servlet.
   Exception:
  
   java.lang.NoSuchMethodError:
   javax.script.Bindings.put
 (Ljava/lang/String;Ljava/lang/Object;)Ljava/lang/Object;
   at
 org.apache.sling.scripting.resolver.impl.DefaultSlingScript.verifySlingBindings
 (DefaultSlingScript.java:305)
   at
 org.apache.sling.scripting.resolver.impl.DefaultSlingScript.eval(
 DefaultSlingScript.java:97)
   at
 org.apache.sling.scripting.resolver.impl.DefaultSlingScript.service(
 DefaultSlingScript.java:162)
   at
 org.apache.sling.servlet.resolver.defaults.DefaultServlet.doGet(
 DefaultServlet.java:81)
  
   And I understand that this means that the current Launchpad does not
   know how to provide .js files.
   Most probably, it's a simple operation to copy code or classes from
   the old microsling project, to get this working, but I'm not sure how
   to go about it.
  
   Any directions welcome :)
  
   Cheers,
   PS

Re: WebDAV - committed before 401 Unauthorized (was: A quick build question)

Hi Peter,

Hmm, so you say

curl -D - -X OPTIONS http://admin:[EMAIL PROTECTED]:8080/dav/default

works, but

curl -D - -X OPTIONS http://admin:[EMAIL PROTECTED]:8080/dav

gives you the IllegalStateException in the log ?

This should not be the case as the second URL should be redirected (302)
to the first.

Regards
Felix

Am Montag, den 28.01.2008, 19:21 +0100 schrieb Peter Svensson:
 Ahaaa!  In your previous psot, you misspelled the url :) You said it was
 different, and only /dav, but now I saw that you write /dev/default in this
 post.
 And that worked (releived).
 
 Back to work
 
 PS
 
 On Jan 25, 2008 5:59 PM, Bertrand Delacretaz [EMAIL PROTECTED] wrote:
 
  Hi Peter,
 
  On Jan 25, 2008 4:58 AM, Peter Svensson [EMAIL PROTECTED] wrote:
 
   ...2008-01-25 03:30:55.980::WARN:  Committed before 401 Unauthorized
   2008-01-25 03:30:55.981::WARN:  /dav/
   java.lang.IllegalStateException: Committed...
 
  Once you get a chance to try again, you could try with curl to make
  sure your login problem is unrelated to the WebDAV client.
 
  After starting launchpad-webapp with mvn package jetty:start,
 
curl -D - -X OPTIONS http://admin:[EMAIL PROTECTED]:8080/dav/default
 
  should say
 
  HTTP/1.1 200 OK
  DAV: 1,2,version-control,version-history,label
  Allow: OPTIONS, GET, HEAD, POST, TRACE, PROPFIND, PROPPATCH, MKCOL,
  COPY, PUT, DELETE, MOVE, LOCK, UNLOCK, VERSION-CONTROL
  MS-Author-Via: DAV
  Content-Length: 0
  Server: Jetty(6.1.5)
 
  The WebDAV service takes a few seconds to startup, about 5 on my macbook
  pro.
 
  -Bertrand

Re: Change in default handler

Thanks!  Well, I thought it would be a good idea if any scripts I make can
be included in Sling/Launchpad from scratch, if you want.

Cheers,
PS

On Jan 29, 2008 9:14 AM, Felix Meschberger [EMAIL PROTECTED] wrote:

 Hi Peter,

 Am Dienstag, den 29.01.2008, 09:05 +0100 schrieb Peter Svensson:
  Hi Felix and all,
  I did actually read that discussion, I just didn't understand it :)
  Thanks for the info. I'll get on the case tonight, and finally be able
 to
  write my own json content serializer.
 
  Could some kind soul also point out again where the agreement that one
 shall
  sign is, I've looked around in my inbox but can't seem to find it.

 Are you talking about the CLA ? This is available at [1].

 On the other hand we are planning on creating an open wiki [2], so this
 is of less importance. Still having a signed CLA on file is a good
 thing :-)

 Regards
 Felix

 [1] http://www.apache.org/licenses/icla.txt
 [2]
 http://www.mail-archive.com/sling-dev@incubator.apache.org/msg02027.html

  Thanks,
  PS
 
  On Jan 29, 2008 9:00 AM, Felix Meschberger [EMAIL PROTECTED] wrote:
 
   Hi Peter,
  
   Exactly as David said, I modified this behaviour yesterday. If you
   update the sling/servlet-resolver project and redeploy the bundle, the
   js file should be delivered as expected again.
  
   Background: With the most recent changes to the Sling API I
 implemented
   automatic server-side execution of directly addressed scripts. This
 was
   implemented by simple checking whether the addressed resource adapts
 to
   a servlet, which is the case .js files. This is now changed to only
   execute such directly addressed script of the request extension
   (request.getRequestPathInfo().getExtension()) is not null.
  
   Regards
   Felix
  
   Am Dienstag, den 29.01.2008, 08:46 +0100 schrieb David Nuescheler:
hi peter,
   
i think this is an issue that sling tried to execute the js file
 instead
of just delivering it. this was part of a bigger discussion and
 should
have been removed by now.
   
felix may have more details.
   
regards,
david
   
On 1/28/08, Peter Svensson [EMAIL PROTECTED] wrote:
 Hi, I've finally found some time again to see if I can get Sling
 and
   Bunkai
 to work together. My plan at the moment is to create my own custom
 esp
 script to handle serialization of resources hierarchies into json,
 in
   a way
 that can be consumed by Dojo.

 I've managed to mount the latest svn revision of Sling and use
   Launchpad.
 I've copied Bunkai into the webDAv mount, and manage to access my
 html
   page.
 The css gets read correctly, but when I try to laod any js file, I
 get
   this;

 javax.script.Bindings.put
   (Ljava/lang/String;Ljava/lang/Object;)Ljava/lang/Object;
 (500)

 The requested URL /bunkai/dojo-1.0.2/dojo/dojo.js resulted in an
 error
   in
 Sling Core Default Servlet.
 Exception:

 java.lang.NoSuchMethodError:
 javax.script.Bindings.put
   (Ljava/lang/String;Ljava/lang/Object;)Ljava/lang/Object;
 at
  
 org.apache.sling.scripting.resolver.impl.DefaultSlingScript.verifySlingBindings
   (DefaultSlingScript.java:305)
 at
   org.apache.sling.scripting.resolver.impl.DefaultSlingScript.eval(
   DefaultSlingScript.java:97)
 at
   org.apache.sling.scripting.resolver.impl.DefaultSlingScript.service(
   DefaultSlingScript.java:162)
 at
   org.apache.sling.servlet.resolver.defaults.DefaultServlet.doGet(
   DefaultServlet.java:81)

 And I understand that this means that the current Launchpad does
 not
 know how to provide .js files.
 Most probably, it's a simple operation to copy code or classes
 from
 the old microsling project, to get this working, but I'm not sure
 how
 to go about it.

 Any directions welcome :)

 Cheers,
 PS

Re: WebDAV - committed before 401 Unauthorized (was: A quick build question)

Hi Peter,

Am Dienstag, den 29.01.2008, 09:12 +0100 schrieb Peter Svensson:
 Sorry Felix. I never got to curl. What I did was to try to mount -t davfs
 ...  and I did get 302 reported as an errro by linux mount, which means it's
 not compatible with handling that, so that's the reason, probably.

Good note ! Thanks for the clarification, this will certainly flow into
the docs.

 
 When I tried it with /dav/default, it worked fine (of course).
 
 Another thing I wonder is where to set memory limits. When I copy my project
 into Sling, I always get OutOfMemoryError. Dojo itself is thousands of
 files.

You set this using java runtime arguments -Xmx. If your OOME is caused
by PermGen overruns, you might want to try the -XX:MaxPermSize option.
See [1] for details.

Regards
Felix

[1] http://java.sun.com/javase/technologies/hotspot/vmoptions.jsp

 
 Cheers,
 PS
 
 On Jan 29, 2008 9:02 AM, Felix Meschberger [EMAIL PROTECTED] wrote:
 
  Hi Peter,
 
  Hmm, so you say
 
 curl -D - -X OPTIONS http://admin:[EMAIL PROTECTED]:8080/dav/default
 
  works, but
 
 curl -D - -X OPTIONS http://admin:[EMAIL PROTECTED]:8080/dav
 
  gives you the IllegalStateException in the log ?
 
  This should not be the case as the second URL should be redirected (302)
  to the first.
 
  Regards
  Felix
 
  Am Montag, den 28.01.2008, 19:21 +0100 schrieb Peter Svensson:
   Ahaaa!  In your previous psot, you misspelled the url :) You said it was
   different, and only /dav, but now I saw that you write /dev/default in
  this
   post.
   And that worked (releived).
  
   Back to work
  
   PS
  
   On Jan 25, 2008 5:59 PM, Bertrand Delacretaz [EMAIL PROTECTED]
  wrote:
  
Hi Peter,
   
On Jan 25, 2008 4:58 AM, Peter Svensson [EMAIL PROTECTED] wrote:
   
 ...2008-01-25 03:30:55.980::WARN:  Committed before 401 Unauthorized
 2008-01-25 03:30:55.981::WARN:  /dav/
 java.lang.IllegalStateException: Committed...
   
Once you get a chance to try again, you could try with curl to make
sure your login problem is unrelated to the WebDAV client.
   
After starting launchpad-webapp with mvn package jetty:start,
   
  curl -D - -X OPTIONS http://admin:[EMAIL PROTECTED]:8080/dav/default
   
should say
   
HTTP/1.1 200 OK
DAV: 1,2,version-control,version-history,label
Allow: OPTIONS, GET, HEAD, POST, TRACE, PROPFIND, PROPPATCH, MKCOL,
COPY, PUT, DELETE, MOVE, LOCK, UNLOCK, VERSION-CONTROL
MS-Author-Via: DAV
Content-Length: 0
Server: Jetty(6.1.5)
   
The WebDAV service takes a few seconds to startup, about 5 on my
  macbook
pro.
   
-Bertrand

Re: Change in default handler

Hi Peter,

Great ! Looking forward to this.

Regards
Felix

Am Dienstag, den 29.01.2008, 09:16 +0100 schrieb Peter Svensson:
 Thanks!  Well, I thought it would be a good idea if any scripts I make can
 be included in Sling/Launchpad from scratch, if you want.
 
 Cheers,
 PS
 
 On Jan 29, 2008 9:14 AM, Felix Meschberger [EMAIL PROTECTED] wrote:
 
  Hi Peter,
 
  Am Dienstag, den 29.01.2008, 09:05 +0100 schrieb Peter Svensson:
   Hi Felix and all,
   I did actually read that discussion, I just didn't understand it :)
   Thanks for the info. I'll get on the case tonight, and finally be able
  to
   write my own json content serializer.
  
   Could some kind soul also point out again where the agreement that one
  shall
   sign is, I've looked around in my inbox but can't seem to find it.
 
  Are you talking about the CLA ? This is available at [1].
 
  On the other hand we are planning on creating an open wiki [2], so this
  is of less importance. Still having a signed CLA on file is a good
  thing :-)
 
  Regards
  Felix
 
  [1] http://www.apache.org/licenses/icla.txt
  [2]
  http://www.mail-archive.com/sling-dev@incubator.apache.org/msg02027.html
 
   Thanks,
   PS
  
   On Jan 29, 2008 9:00 AM, Felix Meschberger [EMAIL PROTECTED] wrote:
  
Hi Peter,
   
Exactly as David said, I modified this behaviour yesterday. If you
update the sling/servlet-resolver project and redeploy the bundle, the
js file should be delivered as expected again.
   
Background: With the most recent changes to the Sling API I
  implemented
automatic server-side execution of directly addressed scripts. This
  was
implemented by simple checking whether the addressed resource adapts
  to
a servlet, which is the case .js files. This is now changed to only
execute such directly addressed script of the request extension
(request.getRequestPathInfo().getExtension()) is not null.
   
Regards
Felix
   
Am Dienstag, den 29.01.2008, 08:46 +0100 schrieb David Nuescheler:
 hi peter,

 i think this is an issue that sling tried to execute the js file
  instead
 of just delivering it. this was part of a bigger discussion and
  should
 have been removed by now.

 felix may have more details.

 regards,
 david

 On 1/28/08, Peter Svensson [EMAIL PROTECTED] wrote:
  Hi, I've finally found some time again to see if I can get Sling
  and
Bunkai
  to work together. My plan at the moment is to create my own custom
  esp
  script to handle serialization of resources hierarchies into json,
  in
a way
  that can be consumed by Dojo.
 
  I've managed to mount the latest svn revision of Sling and use
Launchpad.
  I've copied Bunkai into the webDAv mount, and manage to access my
  html
page.
  The css gets read correctly, but when I try to laod any js file, I
  get
this;
 
  javax.script.Bindings.put
(Ljava/lang/String;Ljava/lang/Object;)Ljava/lang/Object;
  (500)
 
  The requested URL /bunkai/dojo-1.0.2/dojo/dojo.js resulted in an
  error
in
  Sling Core Default Servlet.
  Exception:
 
  java.lang.NoSuchMethodError:
  javax.script.Bindings.put
(Ljava/lang/String;Ljava/lang/Object;)Ljava/lang/Object;
  at
   
  org.apache.sling.scripting.resolver.impl.DefaultSlingScript.verifySlingBindings
(DefaultSlingScript.java:305)
  at
org.apache.sling.scripting.resolver.impl.DefaultSlingScript.eval(
DefaultSlingScript.java:97)
  at
org.apache.sling.scripting.resolver.impl.DefaultSlingScript.service(
DefaultSlingScript.java:162)
  at
org.apache.sling.servlet.resolver.defaults.DefaultServlet.doGet(
DefaultServlet.java:81)
 
  And I understand that this means that the current Launchpad does
  not
  know how to provide .js files.
  Most probably, it's a simple operation to copy code or classes
  from
  the old microsling project, to get this working, but I'm not sure
  how
  to go about it.
 
  Any directions welcome :)
 
  Cheers,
  PS

Re: WebDAV - committed before 401 Unauthorized (was: A quick build question)

On Jan 29, 2008 9:43 AM, Peter Svensson [EMAIL PROTECTED] wrote:
 ...I'd rather build a stand-alone Launchpad, though, if there's
 maven options for that

We don't have a standalone launchpad yet, but mvn install in
launchpad-webapp builds a war file (under target/) that should run in
any servlet container with JDK 1.5 and servlet API 2.4.

So the best thing for experimenting without having to install too many
things is probably the mvn clean package jetty:run option for now,
and as Felix indicates MAVEN_OPTS can be used to set JVM and other
options.

-Bertrand

Re: WebDAV - committed before 401 Unauthorized (was: A quick build question)

OK. Thanks! I'd rather build a stand-alone Launchpad, though, if there's
maven options for that. Otherwise I'llgo with the enviroment
variable
Cheers,
PS

On Jan 29, 2008 9:36 AM, Felix Meschberger [EMAIL PROTECTED] wrote:

 Hi Peter,

 Am Dienstag, den 29.01.2008, 09:28 +0100 schrieb Peter Svensson:
  OK. Thanks!
  But I'm not so got at maven. Am I correct in assuming that the arguments
 are
  set somewhere in the pom.xml in the launchpad directory nearby some
 lines
  saying jett6 .. ??

 Ah, didn't realize you are using mvn jetty:run on the launchpad-web
 app. Sorry.

 If I remember correctly, jetty runs inline in the Maven Java VM in this
 case. You then may set the MAVEN_OPTS environment variables with an Java
 VM arguments you want to specify. For example, I use

   export MAVEN_OPTS=-Xdebug -Xnoagent
 -Xrunjdwp:transport=dt_socket,address=30313,server=y,suspend=n

 when trying to debug maven builds.

 Hope, this helps.

 Regards
 Felix


 
  cheers,
  PS
 
  On Jan 29, 2008 9:19 AM, Felix Meschberger [EMAIL PROTECTED] wrote:
 
   Hi Peter,
  
   Am Dienstag, den 29.01.2008, 09:12 +0100 schrieb Peter Svensson:
Sorry Felix. I never got to curl. What I did was to try to mount -t
   davfs
...  and I did get 302 reported as an errro by linux mount, which
 means
   it's
not compatible with handling that, so that's the reason, probably.
  
   Good note ! Thanks for the clarification, this will certainly flow
 into
   the docs.
  
   
When I tried it with /dav/default, it worked fine (of course).
   
Another thing I wonder is where to set memory limits. When I copy my
   project
into Sling, I always get OutOfMemoryError. Dojo itself is thousands
 of
files.
  
   You set this using java runtime arguments -Xmx. If your OOME is caused
   by PermGen overruns, you might want to try the -XX:MaxPermSize option.
   See [1] for details.
  
   Regards
   Felix
  
   [1] http://java.sun.com/javase/technologies/hotspot/vmoptions.jsp
  
   
Cheers,
PS
   
On Jan 29, 2008 9:02 AM, Felix Meschberger [EMAIL PROTECTED]
 wrote:
   
 Hi Peter,

 Hmm, so you say

curl -D - -X OPTIONS
 http://admin:[EMAIL PROTECTED]:8080/dav/default

 works, but

curl -D - -X OPTIONS http://admin:[EMAIL PROTECTED]:8080/dav

 gives you the IllegalStateException in the log ?

 This should not be the case as the second URL should be redirected
   (302)
 to the first.

 Regards
 Felix

 Am Montag, den 28.01.2008, 19:21 +0100 schrieb Peter Svensson:
  Ahaaa!  In your previous psot, you misspelled the url :) You
 said it
   was
  different, and only /dav, but now I saw that you write
 /dev/default
   in
 this
  post.
  And that worked (releived).
 
  Back to work
 
  PS
 
  On Jan 25, 2008 5:59 PM, Bertrand Delacretaz 
 [EMAIL PROTECTED]
   
 wrote:
 
   Hi Peter,
  
   On Jan 25, 2008 4:58 AM, Peter Svensson [EMAIL PROTECTED]
   wrote:
  
...2008-01-25 03:30:55.980::WARN:  Committed before 401
   Unauthorized
2008-01-25 03:30:55.981::WARN:  /dav/
java.lang.IllegalStateException: Committed...
  
   Once you get a chance to try again, you could try with curl to
   make
   sure your login problem is unrelated to the WebDAV client.
  
   After starting launchpad-webapp with mvn package
 jetty:start,
  
 curl -D - -X OPTIONS
   http://admin:[EMAIL PROTECTED]:8080/dav/default
  
   should say
  
   HTTP/1.1 200 OK
   DAV: 1,2,version-control,version-history,label
   Allow: OPTIONS, GET, HEAD, POST, TRACE, PROPFIND, PROPPATCH,
   MKCOL,
   COPY, PUT, DELETE, MOVE, LOCK, UNLOCK, VERSION-CONTROL
   MS-Author-Via: DAV
   Content-Length: 0
   Server: Jetty(6.1.5)
  
   The WebDAV service takes a few seconds to startup, about 5 on
 my
 macbook
   pro.
  
   -Bertrand

Re: MissingRepositoryException

2008-01-29 Thread Damian Harden

Hi Bertrand,

I don't know the difference between the launchpad and the launcher.
However, I would be happy to try the launchpad if some documentation
is made available :-)

Kind regards,

Damian

On 29/01/2008, Bertrand Delacretaz [EMAIL PROTECTED] wrote:
 Hi Damian,

 On Jan 29, 2008 10:40 AM, Damian Harden [EMAIL PROTECTED] wrote:

  I just downloaded Sling trunk from SVN (Revision: 616220) and followed
  the First Steps

 If you don't have a specific reason to use the launcher/app or
 launcher/webapp, it might be better to try the launchpad, as this is
 where the action is at the moment. The launcher stuff will eventually
 be merged with the launchpad to have just one starting point.

 Now, there's no documentation on the website about the launchpad, but
 if you'd like to try it today I'd be happy to create such docs - I
 could start right now.

 Would that be ok for you? If so I'll start writing right away so that
 you can get started.

 -Bertrand

Re: MissingRepositoryException

Hi Damian,

On Jan 29, 2008 10:40 AM, Damian Harden [EMAIL PROTECTED] wrote:

 I just downloaded Sling trunk from SVN (Revision: 616220) and followed
 the First Steps

If you don't have a specific reason to use the launcher/app or
launcher/webapp, it might be better to try the launchpad, as this is
where the action is at the moment. The launcher stuff will eventually
be merged with the launchpad to have just one starting point.

Now, there's no documentation on the website about the launchpad, but
if you'd like to try it today I'd be happy to create such docs - I
could start right now.

Would that be ok for you? If so I'll start writing right away so that
you can get started.

-Bertrand

Re: MissingRepositoryException

On Jan 29, 2008 11:03 AM, Damian Harden [EMAIL PROTECTED] wrote:

 I don't know the difference between the launchpad and the launcher.
 ...However, I would be happy to try the launchpad if some documentation
 is made available :-)..

Ok - for now here's what you can do:

  cd top level of the Sling source code tree
  mvn clean install
  cd launchpad/launchpad-webapp
  mvn jetty:run

Now, http://locahost:8080/sling shows the Sling Management Console
page. We don't need it right now, but it shows that Sling is started.

Create a node with an HTTP POST request, for example (or create an
HTML form that posts there):

  curl -Fsling:resourceType=foo/bar -Ftitle=some title
http://admin:[EMAIL PROTECTED]:8080/content/mynode

Now

  http://localhost:8080/content/mynode (login: admin/admin)

Displays a text representation saying Node dumped by
PlainTextRendererServlet with the node's properties.

Try

  http://localhost:8080/content/mynode.html

which displays a default representation of the node, in HTML.

Now connect to the repository with a WebDAV client, at
http://admin:[EMAIL PROTECTED]:8080/dav/default/ and copy this file
under /apps/foo/bar/html.esp, creating those folders as needed:

html
body
h1%= resource.node.title %/h1
/body
/html

Now http://localhost:8080/content/mynode.html displays the title
property of your node as an H1.

That's a first step: rendering JCR nodes with server-side javascript.

I'll put that up on the wiki - stay tuned for more fun.

-Bertrand

[jira] Resolved: (SLING-206) servlet not picked up by resolver unless i restart my bundle


 [ 
https://issues.apache.org/jira/browse/SLING-206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Felix Meschberger resolved SLING-206.
-

   Resolution: Fixed
Fix Version/s: 2.0.0

Fixed in Rev. 616254 by delaying the actual binding of ResourceProviders until 
after the JcrResourceResolverFactoryImpl component is activated and the 
ComponentContext is available.

Please close this issue if this fixes your problem. Thanks.

 servlet not picked up by resolver unless i restart my bundle
 

 Key: SLING-206
 URL: https://issues.apache.org/jira/browse/SLING-206
 Project: Sling
  Issue Type: Bug
  Components: ServletResolver
Reporter: Tobias Bocanegra
Assignee: Felix Meschberger
 Fix For: 2.0.0

 Attachments: config_status.txt


 i have a servlet that is registered with a primary type of a node.
 just after startup, a request to a node with that primary type shows
 the dump of the default servlet. after i restart my bundle that
 contains the servlet (stop/start) the next request is then handled by
 my servlet.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Some more Sling API stuff

2008-01-29 Thread Tobias Bocanegra

+1 good idea

On 1/29/08, Felix Meschberger [EMAIL PROTECTED] wrote:
 Hi all,

 In addition to the changes of last week introducing the Adapter
 framework, I would like to modify the ResourceResolver API as stipulated
 in [2] and described in [1].

 The consequence of this change would be that (1) the PathResolver
 interface of the jcr/resolver project would be dropped, as the
 ResourceResolver interface defines the API and (2) the search path
 handling currently located in the sling/servlet-resolver project is
 moved to be a core functionality of the ResourceResolver and thus be
 usable to other users in need of realtive path resolution.

 WDYT ?

 Regards
 Felix


 [1] http://incubator.apache.org/sling/site/resources.html
 [2] http://issues.apache.org/jira/browse/SLING-198




-- 
- [EMAIL PROTECTED] ---
Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
T +41 61 226 98 98, F +41 61 226 98 97
--- http://www.day.com ---

Discover Sling in 15 minutes

I've started working on this page:

http://cwiki.apache.org/confluence/display/SLING/Discover+Sling+in+15+minutes

To help people get started with the Launchpad.

The page will eventually move to the Sling website, but for now guinea
pigs^H^H^H^H^H^H^H^H beta testers are welcome!

-Bertrand

[jira] Commented: (SLING-149) Create the Sling Launchpad, based on microsling-core code

2008-01-29 Thread Bertrand Delacretaz (JIRA)

[
https://issues.apache.org/jira/browse/SLING-149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12563532#action_12563532
]

Bertrand Delacretaz commented on SLING-149:
---

All integration tests imported from microsling now pass, except the following
ones which are still marked with TODO_FAILS in the launchpad-webapp test code:

1) PostServletCreateTest.testCustomSavePrefixPlusPlus, a ++ save prefix does
not work, haven't checked if the cause is the test or the server-side code.

2) IncludeTest SLING-207 problem

3) testEspHtmlWithContentBasedPath, where scripts are located based on the
content path - not sure if we want to keep that feature.

4) Tests that use script languages other than javascript - we'll have to see
how we handle these, the best would be to test the scripting engines locally in
their own modules

5) All the SyntheticResourceTest, I haven't looked at those yet

6) The ujax client-side library is not included yet, find it under
http://svn.apache.org/repos/asf/incubator/sling/trunk/microsling/microsling-core/src/main/webapp/ujax

Apart from these points, we can now consider that the Launchpad works as
microsling-core did, but based on Sling code.

Create the Sling Launchpad, based on microsling-core code
-

Key: SLING-149
URL: https://issues.apache.org/jira/browse/SLING-149
Project: Sling
Issue Type: Improvement
Components: microsling
Reporter: Bertrand Delacretaz
Assignee: Bertrand Delacretaz

Following up on the [RT] Shall we merge microsling into Sling? [1] and
µsling 2.0 requirements [2] threads on sling-dev, we need to merge
microsling into Sling.
Here the are requirements as discussed in [2] (taking into account Felix's
comment about WebDAV and Michael's comment about switching to other JCR
repositories):
µsling 2.0 is a preconfigured instance of Sling, meant to allow web
developers to test drive Sling by building scripted web and REST applications
backed by a JCR repository.
The µsling 2.0 distribution only requires a Java 5 VM to run, no installation
is needed. Fifteen minutes should be enough to start µsling and understand
the basic concepts, based on self-guiding examples. µsling should ideally be
delivered as a single runnable jar file.
Java programming is not required to build web and REST applications with
µsling 2.0: both server-side and client-side javascript code and presentation
templates can be used to process HTTP requests. Other scripting and
templating languages (JSP and BSF-supported ones) can be plugged in easily.
The µjax application protocol and client-side javascript JCR proxy
library make it easy to write powerful Ajaxish JCR-based applications with
µsling 2.0.
µsling 2.0 is built on the same codebase as Sling, it's only a specific
configuration of Sling.
All µsling 2.0 features are available in Sling applications, as long as they
are enabled in the Sling configuration.
Sling (and µsling, as it runs the same core code) uses OSGi to modularize the
framework, but µsling does not require any OSGI skills, and makes OSGI
largely invisible to beginners.
All Sling features and modules can also be activated in a µsling 2.0
instance, by installing and activating the required OSGi bundles.
µsling 2.0 passes all the integration tests of the existing microsling test
suite (SVN revision 605206), with minor adaptations where needed.
µsling 2.0 includes a WebDAV server module to make it easy to copy scripts
into the JCR repository.
[1] http://markmail.org/message/2s7agnu5kklti6da
[2] http://markmail.org/message/atbjzjjp2wflkotb

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Discover Sling in 15 minutes

2008-01-29 Thread Gert Vanthienen


L.S.,


While following the instructions on the wiki page you mentioned, I ran 
into a problem when executing the 'curl ...' command to add a first node 
of content:


Method POST not supported (405)
The requested URL /content/mynode resulted in an error in Sling Core 
Default Servlet


What have I done wrong here?


Gert

Re: Discover Sling in 15 minutes

2008-01-29 Thread Torgeir Veimo



On 29 Jan 2008, at 23:55, Felix Meschberger wrote:


Hi Torgeir,

Sorry for that, I am currently committing SLING-198 fixes. If you  
update

the jcr/resource project now, it should compile.




A few files still missing?

INFO] Compiling 53 source files to /Users/torgeir/java/src/sling/ 
15minutes/sling/sling/core/target/classes
[INFO]  


[INFO] Compilation failure

/Users/torgeir/java/src/sling/15minutes/sling/sling/core/src/main/java/ 
org/apache/sling/core/impl/SlingHttpServletResponseImpl.java:[35,37]  
cannot find symbol

symbol  : class PathResolver
location: package org.apache.sling.jcr.resource

/Users/torgeir/java/src/sling/15minutes/sling/sling/core/src/main/java/ 
org/apache/sling/core/impl/SlingHttpServletResponseImpl.java:[247,8]  
cannot find symbol

symbol  : class PathResolver
location: class org.apache.sling.core.impl.SlingHttpServletResponseImpl

/Users/torgeir/java/src/sling/15minutes/sling/sling/core/src/main/java/ 
org/apache/sling/core/impl/SlingHttpServletResponseImpl.java:[247,73]  
cannot find symbol

symbol  : class PathResolver
location: class org.apache.sling.core.impl.SlingHttpServletResponseImpl


--
Torgeir Veimo
[EMAIL PROTECTED]

Re: JCR via RMI

On Jan 29, 2008 4:48 PM, Felix Meschberger [EMAIL PROTECTED] wrote:

 ...just replace the jackrabbit-server bundle contained by default
 with the jackrabbit-client bundle and you can access your repository
 over RMI

Looking at the SlingClientRepository class [1], I don't see how one
could set the RMI connection parameters - but if configurable
properties are missing, it shouldn't be hard to add them.

-Bertrand

[1] 
https://svn.apache.org/repos/asf/incubator/sling/trunk/jcr/jackrabbit-client/src/main/java/org/apache/sling/jcr/jackrabbit/client/SlingClientRepository.java

[jira] Closed: (SLING-203) resource loader installs files with last modified date 1.1.1970

2008-01-29 Thread Tobias Bocanegra (JIRA)


 [ 
https://issues.apache.org/jira/browse/SLING-203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tobias Bocanegra closed SLING-203.
--


 resource loader installs files with last modified date 1.1.1970
 ---

 Key: SLING-203
 URL: https://issues.apache.org/jira/browse/SLING-203
 Project: Sling
  Issue Type: Bug
  Components: Resource
Reporter: Tobias Bocanegra
Assignee: Felix Meschberger
 Fix For: 2.0.0


 the resource loader installs files in th repository with a last modified date 
 of 1.1.1970. this leads to problems with browser caches.
 as far as i can see from the code, this is a problem of osgi/felix not 
 providing the correct lastModifiedDate from the respective bundle entry.
 as work around i suggest to catch such dates and use the current date instead,

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: JCR via RMI

Hi Vidar,

Am Dienstag, den 29.01.2008, 16:37 +0100 schrieb Vidar Ramdal:
 We're in the process of developing a web content management system,
 and we have just discovered Sling. It seems like a great platform for
 us to build our application on top of.

Glad to hear that !

 
 From just test-driving Sling, it appears that it hosts its own
 Jackrabbit instance. In our scenario, we would like to keep our
 application and Jackrabbit on separate servers, for easier scaling.
 
 Is it possible to configure Sling to connect to a remote Jackrabbit
 repository over RMI, instead of hosting its own repository?

Sure, just replace the jackrabbit-server bundle contained by default
with the jackrabbit-client bundle and you can access your repository
over RMI.

Hope this helps.

Regards
Felix

JCR via RMI

2008-01-29 Thread Vidar Ramdal

Hi all,

We're in the process of developing a web content management system,
and we have just discovered Sling. It seems like a great platform for
us to build our application on top of.

From just test-driving Sling, it appears that it hosts its own
Jackrabbit instance. In our scenario, we would like to keep our
application and Jackrabbit on separate servers, for easier scaling.

Is it possible to configure Sling to connect to a remote Jackrabbit
repository over RMI, instead of hosting its own repository?

-- 
Vidar S. Ramdal [EMAIL PROTECTED] - http://www.idium.no
Akersgata 16, N-0158 Oslo, Norway

[jira] Closed: (SLING-210) servlets-standard still use old scr resourceTypes name hence do not work

2008-01-29 Thread Tobias Bocanegra (JIRA)


 [ 
https://issues.apache.org/jira/browse/SLING-210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tobias Bocanegra closed SLING-210.
--


thanks

 servlets-standard still use old scr resourceTypes name hence do not work
 

 Key: SLING-210
 URL: https://issues.apache.org/jira/browse/SLING-210
 Project: Sling
  Issue Type: Bug
Reporter: Tobias Bocanegra
Assignee: Felix Meschberger
 Fix For: 2.0.0

 Attachments: missing.scr.patch


 the latest virtual provider change also altered the name of the scr property 
 for declaring resource types.
 the servlets-standard were not changed.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (SLING-211) Improve support for standard nt:file and nt:resource nodes as well as similar nodes

Improve support for standard nt:file and nt:resource nodes as well as similar 
nodes
---

 Key: SLING-211
 URL: https://issues.apache.org/jira/browse/SLING-211
 Project: Sling
  Issue Type: Improvement
  Components: Resource
Reporter: Felix Meschberger
Assignee: Felix Meschberger
 Fix For: 2.0.0


Currently the JcrNodeResource class just supports special handling for nt:file 
nodes with respect to analyzing well known properties such as 
jcr:content/jcr:lastModified etc. and with respect to support 
adaptTo(InputStream.class).

This support should now be extended to nt:resource nodes or nodes which have 
properties analogous to nt:resource nodes, this encompasses the jcr:data, 
jcr:lastModified, jcr:mimeType and jcr:encoding properties. Of course, we may 
not rely on the nt:resource node type as the Jackrabbit Simple WebDAV support 
creates nt:unstructured nodes with the expected properties.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Discover Sling in 15 minutes

On Jan 29, 2008 3:52 PM, Felix Meschberger [EMAIL PROTECTED] wrote:

 ...For me, Sling now builds through the reactor

Same here, revision 616367 builds, launchpad-webapp integration tests pass.

I didn't have a reactor handy, so I used an atom bomb. Worked fine ;-)

-Bertrand

[jira] Resolved: (SLING-210) servlets-standard still use old scr resourceTypes name hence do not work


 [ 
https://issues.apache.org/jira/browse/SLING-210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Felix Meschberger resolved SLING-210.
-

   Resolution: Fixed
Fix Version/s: 2.0.0
 Assignee: Felix Meschberger

Thanks for reporting and providing a patch.

Applied the patch in Rev. 616366.

Please close this, if your issue is solved. Thanks.

 servlets-standard still use old scr resourceTypes name hence do not work
 

 Key: SLING-210
 URL: https://issues.apache.org/jira/browse/SLING-210
 Project: Sling
  Issue Type: Bug
Reporter: Tobias Bocanegra
Assignee: Felix Meschberger
 Fix For: 2.0.0

 Attachments: missing.scr.patch


 the latest virtual provider change also altered the name of the scr property 
 for declaring resource types.
 the servlets-standard were not changed.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (SLING-210) servlets-standard still use old scr resourceTypes name hence do not work

2008-01-29 Thread Tobias Bocanegra (JIRA)

servlets-standard still use old scr resourceTypes name hence do not work


 Key: SLING-210
 URL: https://issues.apache.org/jira/browse/SLING-210
 Project: Sling
  Issue Type: Bug
Reporter: Tobias Bocanegra
 Attachments: missing.scr.patch

the latest virtual provider change also altered the name of the scr property 
for declaring resource types.
the servlets-standard were not changed.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (SLING-202) osgi install action deletes temp file before it gets installed


 [ 
https://issues.apache.org/jira/browse/SLING-202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Felix Meschberger resolved SLING-202.
-

   Resolution: Fixed
Fix Version/s: 2.0.0

I implemented a slightly different solution to go to great extends to really 
remove the temporary file in Rev. 616269:

   * If the temporary file cannot be written at all, remove any left overs
   * Otherwise, if the symbolic name cannot be extracted, remove the file 
before leaving
   * Otherwise have the background thread remove the file after installation or 
update

Please close this issue if this solves your problem. Thanks.

 osgi install action deletes temp file before it gets installed
 --

 Key: SLING-202
 URL: https://issues.apache.org/jira/browse/SLING-202
 Project: Sling
  Issue Type: Bug
  Components: Console
Reporter: Tobias Bocanegra
Assignee: Felix Meschberger
 Fix For: 2.0.0


 sometimes it happens that when uploading a new bundle it just doesn't get 
 installed.
 this problem occurs more often when i'm using for example curl to upload it.
 i think the problem is that the request-thread deletes the file before the 
 install thread gets hold of it.
 when i remove the tmpFile.delete finally block, it works just fine.
 Index: 
 console-web/src/main/java/org/apache/sling/osgi/console/web/internal/core/InstallAction.java
 ===
 --- 
 console-web/src/main/java/org/apache/sling/osgi/console/web/internal/core/InstallAction.java
 (revision 615347)
 +++ 
 console-web/src/main/java/org/apache/sling/osgi/console/web/internal/core/InstallAction.java
 (working copy)
 @@ -99,10 +99,9 @@
  }
  
  // install the bundle now
 -File tmpFile = null;
  try {
  // copy the data to a file for better processing
 -tmpFile = File.createTempFile(install, .tmp);
 +File tmpFile = File.createTempFile(install, .tmp);
  bundleItem.write(tmpFile);
  bundleLocation = inputstream: + bundleItem.getName();
  
 @@ -110,10 +109,6 @@
  } catch (Exception e) {
  getLog().log(LogService.LOG_ERROR,
  Problem accessing uploaded bundle file, e);
 -} finally {
 -if (tmpFile != null) {
 -tmpFile.delete();
 -}
  }
  
  return true;

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Assigned: (SLING-202) osgi install action deletes temp file before it gets installed


 [ 
https://issues.apache.org/jira/browse/SLING-202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Felix Meschberger reassigned SLING-202:
---

Assignee: Felix Meschberger

 osgi install action deletes temp file before it gets installed
 --

 Key: SLING-202
 URL: https://issues.apache.org/jira/browse/SLING-202
 Project: Sling
  Issue Type: Bug
  Components: Console
Reporter: Tobias Bocanegra
Assignee: Felix Meschberger

 sometimes it happens that when uploading a new bundle it just doesn't get 
 installed.
 this problem occurs more often when i'm using for example curl to upload it.
 i think the problem is that the request-thread deletes the file before the 
 install thread gets hold of it.
 when i remove the tmpFile.delete finally block, it works just fine.
 Index: 
 console-web/src/main/java/org/apache/sling/osgi/console/web/internal/core/InstallAction.java
 ===
 --- 
 console-web/src/main/java/org/apache/sling/osgi/console/web/internal/core/InstallAction.java
 (revision 615347)
 +++ 
 console-web/src/main/java/org/apache/sling/osgi/console/web/internal/core/InstallAction.java
 (working copy)
 @@ -99,10 +99,9 @@
  }
  
  // install the bundle now
 -File tmpFile = null;
  try {
  // copy the data to a file for better processing
 -tmpFile = File.createTempFile(install, .tmp);
 +File tmpFile = File.createTempFile(install, .tmp);
  bundleItem.write(tmpFile);
  bundleLocation = inputstream: + bundleItem.getName();
  
 @@ -110,10 +109,6 @@
  } catch (Exception e) {
  getLog().log(LogService.LOG_ERROR,
  Problem accessing uploaded bundle file, e);
 -} finally {
 -if (tmpFile != null) {
 -tmpFile.delete();
 -}
  }
  
  return true;

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Discover Sling in 15 minutes

2008-01-29 Thread Torgeir Veimo



On 29 Jan 2008, at 21:22, Bertrand Delacretaz wrote:


I've started working on this page:

http://cwiki.apache.org/confluence/display/SLING/Discover+Sling+in+15+minutes


When running mvn jetty:run in launchpad/launchpad-webapp I get

[...]
[INFO] [compiler:testCompile]
[INFO] Compiling 29 source files to /Users/torgeir/java/src/sling/ 
15minutes/sling/launchpad/launchpad-webapp/target/test-classes
[INFO]  


[ERROR] BUILD FAILURE
[INFO]  


[INFO] Compilation failure

/Users/torgeir/java/src/sling/15minutes/sling/launchpad/launchpad- 
webapp/src/test/java/org/apache/sling/launchpad/webapp/integrationtest/ 
ujax/PostServletDeleteTest.java:[44,75] cannot find symbol

symbol  : variable DEFAULT_CREATE_SUFFIX
location: class org.apache.sling.ujax.UjaxPostServlet

/Users/torgeir/java/src/sling/15minutes/sling/launchpad/launchpad- 
webapp/src/test/java/org/apache/sling/launchpad/webapp/integrationtest/ 
ujax/PostServletDeleteTest.java:[45,75] cannot find symbol

symbol  : variable DEFAULT_CREATE_SUFFIX
location: class org.apache.sling.ujax.UjaxPostServlet

--
Torgeir Veimo
[EMAIL PROTECTED]

Re: Some more Sling API stuff

2008-01-29 Thread Philipp Koch

that means that the PathResolver.pathToURL(Resource res) will be
replaced by ResourceResolver.map(String path)?
the current pathToUrl method is currently useless because the path to
url resolving only works for a given resource eg. /a/b/c but not for a
path like /a/b/c.gif (also addresses /a/b/c but invokes a script for
gif image generation (as example)) because of the fact the only the
resource can be passed (which does not know anything about its
extension (.gif))...
the suggestion sounds good to me (i hope that this will be the last
change regarding pathToUrl mapping (regarding api)

regards,
philipp

On 1/29/08, Tobias Bocanegra [EMAIL PROTECTED] wrote:
 +1 good idea


  On 1/29/08, Felix Meschberger [EMAIL PROTECTED] wrote:
   Hi all,
  
   In addition to the changes of last week introducing the Adapter
   framework, I would like to modify the ResourceResolver API as stipulated
   in [2] and described in [1].
  
   The consequence of this change would be that (1) the PathResolver
   interface of the jcr/resolver project would be dropped, as the
   ResourceResolver interface defines the API and (2) the search path
   handling currently located in the sling/servlet-resolver project is
   moved to be a core functionality of the ResourceResolver and thus be
   usable to other users in need of realtive path resolution.
  
   WDYT ?
  
   Regards
   Felix
  
  
   [1] http://incubator.apache.org/sling/site/resources.html
   [2] http://issues.apache.org/jira/browse/SLING-198
  
  



 --
  - [EMAIL PROTECTED] ---
  Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
  T +41 61 226 98 98, F +41 61 226 98 97
  --- http://www.day.com ---

[jira] Closed: (SLING-200) Stack overflow if http method is not supported


 [ 
https://issues.apache.org/jira/browse/SLING-200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Felix Meschberger closed SLING-200.
---

Resolution: Fixed
  Assignee: Felix Meschberger

This has been fixed in Rev. 616271 by merging the resource integration into the 
trunk as part of SLING-197.

 Stack overflow if http method is not supported
 --

 Key: SLING-200
 URL: https://issues.apache.org/jira/browse/SLING-200
 Project: Sling
  Issue Type: Bug
  Components: ServletResolver
Reporter: Tobias Bocanegra
Assignee: Felix Meschberger

 eg: posting on a resource that does not support POST, results in a stack 
 overflow:
 25.01.2008 16:23:16 *ERROR* o.a.s.s.r.SlingServletResolver: Cannot handle 
 error
 java.lang.StackOverflowError
 at 
 com.day.j2ee.servletengine.RequestImpl.getAttribute(RequestImpl.java:815)
 at 
 javax.servlet.ServletRequestWrapper.getAttribute(ServletRequestWrapper.java:81)
 at 
 org.eclipse.equinox.http.servlet.internal.HttpServletRequestAdaptor.getAttribute(HttpServletRequestAdaptor.java:115)
 at 
 javax.servlet.ServletRequestWrapper.getAttribute(ServletRequestWrapper.java:81)
 at 
 org.apache.sling.servlet.resolver.SlingServletResolver.handleError(SlingServletResolver.java:154)
 at 
 org.apache.sling.core.impl.SlingHttpServletResponseImpl.sendError(SlingHttpServletResponseImpl.java:204)
 at 
 org.apache.sling.servlet.resolver.SlingServletResolver.handleError(SlingServletResolver.java:184)
 at 
 org.apache.sling.core.impl.SlingHttpServletResponseImpl.sendError(SlingHttpServletResponseImpl.java:204)
 at 
 org.apache.sling.servlet.resolver.SlingServletResolver.handleError(SlingServletResolver.java:184)
 at 
 org.apache.sling.core.impl.SlingHttpServletResponseImpl.sendError(SlingHttpServletResponseImpl.java:204)
 at 
 org.apache.sling.servlet.resolver.SlingServletResolver.handleError(SlingServletResolver.java:184)
 at 
 org.apache.sling.core.impl.SlingHttpServletResponseImpl.sendError(SlingHttpServletResponseImpl.java:204)
 at 
 org.apache.sling.servlet.resolver.SlingServletResolver.handleError(SlingServletResolver.java:184)
 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: MissingRepositoryException

On Jan 29, 2008 1:42 PM, Damian Harden [EMAIL PROTECTED] wrote:
 Fantastic Bertrand - worked a treat! ;-)

Cool - I've expanded on those explanations at

http://cwiki.apache.org/confluence/display/SLING/Discover+Sling+in+15+minutes

-Bertrand

Re: JCR via RMI

Hi,

If you set the configuration property name to the RMI URL, the
SlingClientRepository class fails getting the repository by JNDI and
uses the RMI URL to get the repository in the lower part of the
getRepository() method.

Regards
Felix


Am Dienstag, den 29.01.2008, 16:50 +0100 schrieb Bertrand Delacretaz:
 On Jan 29, 2008 4:48 PM, Felix Meschberger [EMAIL PROTECTED] wrote:
 
  ...just replace the jackrabbit-server bundle contained by default
  with the jackrabbit-client bundle and you can access your repository
  over RMI
 
 Looking at the SlingClientRepository class [1], I don't see how one
 could set the RMI connection parameters - but if configurable
 properties are missing, it shouldn't be hard to add them.
 
 -Bertrand
 
 [1] 
 https://svn.apache.org/repos/asf/incubator/sling/trunk/jcr/jackrabbit-client/src/main/java/org/apache/sling/jcr/jackrabbit/client/SlingClientRepository.java

[jira] Commented: (SLING-211) Improve support for standard nt:file and nt:resource nodes as well as similar nodes