RE: Re: Re: Re: Problems when registering a simple Restlet resource under OSGi

[Vlatko Davidovski]

Hi Rob!

Good news! I think I discovered what the problem could be. Seems some Manifest 
entries are wrong in the org.restlet jar.

I used the pax-wrap tool (edits and optimizes the Manifest for OSGi) to wrap 
the Restlet jar as a bundle, and after that all problems disappeared.

Resources can be easily registered now.

Will do some more test/development these days and will let u know if I discover 
something new.

Regards,
Vlatko

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2410002

Re: Router in servelet not routing to correct resource

[Matt Stromske]

!DOCTYPE html PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN
html
head
  meta content=text/html;charset=ISO-8859-1 http-equiv=Content-Type
/head
body bgcolor=#ff text=#00
Thanks.nbsp; That did it.nbsp; I think I'm losing it because I thought I tried
that and it didn't work.nbsp; br
Thanks again,br
Mattbr
br
Matt Kennedy wrote:
blockquote cite=mid:682073e5-25b8-47b9-970e-182d4990e...@gmail.com
 type=cite
  pre wrap=I'm not 100% sure based on that description, but try setting 
your  
second router line to:

router.attach(/test1)


On Oct 21, 2009, at 1:19 PM, Matt Stromske wrote:

  /pre
  blockquote type=cite
pre wrap=Hello,

I can't figure out why my router isn't routing to the correct  
resource.  It always seems to route to the default route.  I have 2  
routes:
   router.attachDefault(DefaultResource.class);
router.attach(/gpsh/test1,TestResource.class);

My servlet container mapping:
lt;url-patterngt;/gpsh/*lt;/url-patterngt;


When I attempt to go to /gpsh/test1, I end up going to the default  
route.

Any idea how I can get the routing corrected?

Thanks,
Matt

--
a class=moz-txt-link-freetext 
href=http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2409873;http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447amp;dsMessageId=2409873/a
/pre
  /blockquote
  pre wrap=!
--
a class=moz-txt-link-freetext 
href=http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2409935;http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447amp;dsMessageId=2409935/a
  /pre
/blockquote
br
pre class=moz-signature cols=72-- 

Matt Stromske
Software Engineer
Singlewire Software, LLC
a class=moz-txt-link-abbreviated 
href=http://www.singlewire.com;www.singlewire.com/a
--
608.298.1020
a class=moz-txt-link-abbreviated 
href=mailto:matt.strom...@singlewire.com;matt.strom...@singlewire.com/a
/pre
/body
/html

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2409949

Re: Trouble with ServerServlet

[Rickard Öberg]

On 2009-10-21 18.24, Rickard Öberg wrote:
 I can see that ServerServlet.destroy() *is* called when webapp is
 redeployed, but it doesn't call stop() on my application. When looking
 in the ServerServlet code it's a bit weird, because the init() code
 calls getApplication().start(), but destroy() calls
 getComponent().stop()! I'm guessing my problem is somewhere with that.
 Why aren't these methods starting/stopping the same thing?

I've temporarily fixed this by overriding destroy() as well, and do 
application.stop() on my own. This works, but I'd prefer if the base 
ServerServlet does it for me.

/Rickard

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2410088

Re: Trouble with ServerServlet

[Rémi Dewitte]

Rickard,

I have the feeling that overriding ServerServlet is not the way to go. AFAIR
you should be able to use it out ofthebox configuring the application in
web.xml. I don't know if stop() is called either but I think so.

Rémi

On Thu, Oct 22, 2009 at 08:56, Rickard Öberg rickardob...@gmail.com wrote:

 On 2009-10-21 18.24, Rickard Öberg wrote:
  I can see that ServerServlet.destroy() *is* called when webapp is
  redeployed, but it doesn't call stop() on my application. When looking
  in the ServerServlet code it's a bit weird, because the init() code
  calls getApplication().start(), but destroy() calls
  getComponent().stop()! I'm guessing my problem is somewhere with that.
  Why aren't these methods starting/stopping the same thing?

 I've temporarily fixed this by overriding destroy() as well, and do
 application.stop() on my own. This works, but I'd prefer if the base
 ServerServlet does it for me.

 /Rickard

 --

 http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2410088


--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2410096

Re: Trouble with ServerServlet

[Rickard Öberg]

On 2009-10-22 15.32, Rémi Dewitte wrote:
 Rickard,

 I have the feeling that overriding ServerServlet is not the way to go.
 AFAIR you should be able to use it out ofthebox configuring the
 application in web.xml. I don't know if stop() is called either but I
 think so.

Overriding ServerServlet.destroy is definitely not right, but that's the 
only way I can get it to work. Preferably I should only have to override 
createApplication. But if I do that, then application.stop() is not 
always called, as I get cases where the Component is considered stopped, 
and so application.stop() is not called.

I could very easily reproduce this by simply deploying, and then 
redeploy again immediatly, without any servlet calls having been made. 
The application is instantiated and started, but not stopped on 
destroy(), as the Component is stopped. It seems there's a logic error 
somewhere in the code.

/Rickard

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2410097

Re: HTTP_BASIC authentication doesn't work in GAE

[Patrizio Munzi]

Hello,

Ok I understand, however that was the only way I managed to make it
work in M4.
And It worked without any intercalated "/".

Is that strange?

BR
    Patrizio

Thierry Boileau wrote:

  Hello Patrizio,

I notice that the guarder router add another level in the hierarchy of 
the URIs, because it attaches the authenticator to the segment "/".
Router guardedRouter = new Router(getContext());
guardedRouter.attach("/", authenticator);

The consequence is that you need to intercalate a "/" in your URI 
hierarchy : http://example.com//myresource.

So either the guarder router attaches the authenticator using the 
"attachDefault" method, either you simply return the authenticator.

best regards,
Thierry Boileau

  
  
Hi Jerome,

thanks for the snippet.
My error was returning the guarded router instead of the 
authenticator. That way worked in M4 outside GAE/J.

Anyway I just verified that everything works fine.

Do you know when M5 will be released??

Thanks again.

Jerome Louvel wrote:


  Hi Patrizio,

Â

Thierry just did a test with the latest snapshot and HTTP BASIC 
authentication does work. Here is attached a quick code snippet that 
he wrote based on your code sample.

Â

Best regards,
Jerome Louvel
--
Restlet ~ Founder and Lead developer ~ http://www.restlet.org 
http://www.restlet.org/
Noelios Technologies ~ Co-founder ~ http://www.noelios.com 
http://www.noelios.com/

Â

Â

Â

Â

*De :* Patrizio Munzi [mailto:patrizio.mu...@eris4.com]
*Envoyé :* mardi 20 octobre 2009 09:27
*À :* discuss@restlet.tigris.org
*Objet :* Re: HTTP_BASIC authentication doesn't work in GAE

Â

Hi Jerome,

did you miss my last mail..??
I'm having trouble attaching the authenticator with the new snapshot.

Regards

Patrizio Munzi wrote:

Hi Jerome,

I'm trying to test latest snapshot but I'm not able anymore to attach 
an authenticator to my router.
Using the same snippet as before:
---
public Restlet createRoot() {

// Create a router Restlet that defines routes.
Router router = new Router(getContext());

// Defines a route for the resource "list of items"
router.attach("/addcall", CallResource.class);
router.attach("/addsms", SMSResource.class);

ChallengeAuthenticator authenticator = new 
ChallengeAuthenticator(getContext(), ChallengeScheme.HTTP_BASIC, 
"com.eris4.warp4.callfriends.server.restlet");
MapVerifier verifier = new MapVerifier();
verifier.getLocalSecrets().put("callFriends", 
"callFriends".toCharArray());
authenticator.setVerifier(verifier);
authenticator.setNext(router);

Router guardedRouter = new Router(getContext());
guardedRouter.attach("/", authenticator);

return guardedRouter;
}
-

I get a Resource not found from the client.
Has something changed on guarding mechanism..??

Please let me know so that I can go further.

BR

Jerome Louvel wrote:

Hi Patrizio,
 
We recently moved all JAAS dependencies from Restlet Core to a JAAS 
extension. This should solve your issue. Could you test with a recent 
2.0 snapshot and let us know?
 
Best regards,
Jerome Louvel
--
Restlet ~ Founder and Lead developer ~ http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com
 
 
Patrizio Munzi a écrit :
  

Ok, thank you.

 

Thierry Boileau wrote:

    

Hello Patrizio,

 

I've entered a new issue for this problem : 

http://restlet.tigris.org/issues/show_bug.cgi?id=893.

Thanks for your report.

 

Best regards,

Thierry Boileau

 

  

      

Hi everybody,

 

I think I've found a problem of Restlet Authentication mechanism with GAE.

 

I have got this simple guard:

--

    public Restlet createRoot() { 

        // Create a router Restlet that defines routes. 

        Router router = new Router(getContext()); 

 

        // Defines a route for the resource "list of items" 

        router.attach("/addcall", CallResource.class); 

        router.attach("/addsms", SMSResource.class); 

 

        ChallengeAuthenticator authenticator = new 

ChallengeAuthenticator(getContext(), ChallengeScheme.HTTP_BASIC, 

"com.eris4.warp4.callfriends.server.restlet");

        MapVerifier verifier = new MapVerifier();

        verifier.getSecrets().put("callFriends", 

"callFriends".toCharArray());

        authenticator.setVerifier(verifier);

        authenticator.setNext(router);

       

        Router guardedRouter = new Router(getContext());

        guardedRouter.attach("/", authenticator);

   

Re: HTTP_BASIC authentication doesn't work in GAE

[Thierry Boileau]

Hi,

  Is that strange?
to my mind, yes. But I've just tested, and it effectively works...

best regards,
Thierry Boileau

 Hello,

 Ok I understand, however that was the only way I managed to make it 
 work in M4.
 And It worked without any intercalated /.

 Is that strange?

 BR
 Â Â Â Patrizio

 Thierry Boileau wrote:
 Hello Patrizio,

 I notice that the guarder router add another level in the hierarchy of 
 the URIs, because it attaches the authenticator to the segment /.
 Router guardedRouter = new Router(getContext());
 guardedRouter.attach(/, authenticator);

 The consequence is that you need to intercalate a / in your URI 
 hierarchy : http://example.com//myresource.

 So either the guarder router attaches the authenticator using the 
 attachDefault method, either you simply return the authenticator.

 best regards,
 Thierry Boileau

   
 Hi Jerome,

 thanks for the snippet.
 My error was returning the guarded router instead of the 
 authenticator. That way worked in M4 outside GAE/J.

 Anyway I just verified that everything works fine.

 Do you know when M5 will be released??

 Thanks again.

 Jerome Louvel wrote:
 
 Hi Patrizio,

 Â

 Thierry just did a test with the latest snapshot and HTTP BASIC 
 authentication does work. Here is attached a quick code snippet that 
 he wrote based on your code sample.

 Â

 Best regards,
 Jerome Louvel
 --
 Restlet ~ Founder and Lead developer ~ http://www.restlet.org 
 http://www.restlet.org/
 Noelios Technologies ~ Co-founder ~ http://www.noelios.com 
 http://www.noelios.com/

 Â

 Â

 Â

 Â

 *De :* Patrizio Munzi [mailto:patrizio.mu...@eris4.com]
 *Envoyé :* mardi 20 octobre 2009 09:27
 *À :* discuss@restlet.tigris.org
 *Objet :* Re: HTTP_BASIC authentication doesn't work in GAE

 Â

 Hi Jerome,

 did you miss my last mail..??
 I'm having trouble attaching the authenticator with the new snapshot.

 Regards

 Patrizio Munzi wrote:

 Hi Jerome,

 I'm trying to test latest snapshot but I'm not able anymore to attach 
 an authenticator to my router.
 Using the same snippet as before:
 ---
 public Restlet createRoot() {

 // Create a router Restlet that defines routes.
 Router router = new Router(getContext());

 // Defines a route for the resource list of items
 router.attach(/addcall, CallResource.class);
 router.attach(/addsms, SMSResource.class);

 ChallengeAuthenticator authenticator = new 
 ChallengeAuthenticator(getContext(), ChallengeScheme.HTTP_BASIC, 
 com.eris4.warp4.callfriends.server.restlet);
 MapVerifier verifier = new MapVerifier();
 verifier.getLocalSecrets().put(callFriends, 
 callFriends.toCharArray());
 authenticator.setVerifier(verifier);
 authenticator.setNext(router);

 Router guardedRouter = new Router(getContext());
 guardedRouter.attach(/, authenticator);

 return guardedRouter;
 }
 -

 I get a Resource not found from the client.
 Has something changed on guarding mechanism..??

 Please let me know so that I can go further.

 BR

 Jerome Louvel wrote:

 Hi Patrizio,
 Â 
 We recently moved all JAAS dependencies from Restlet Core to a JAAS 
 extension. This should solve your issue. Could you test with a recent 
 2.0 snapshot and let us know?
 Â 
 Best regards,
 Jerome Louvel
 --
 Restlet ~ Founder and Lead developer ~ http://www.restlet.org
 Noelios Technologies ~ Co-founder ~ http://www.noelios.com
 Â 
 Â 
 Patrizio Munzi a écrit :
 Â  

 Ok, thank you.

 Â 

 Thierry Boileau wrote:

 Â Â Â  

 Hello Patrizio,

 Â 

 I've entered a new issue for this problem : 

 http://restlet.tigris.org/issues/show_bug.cgi?id=893.

 Thanks for your report.

 Â 

 Best regards,

 Thierry Boileau

 Â 

 Â  

 Â Â Â Â Â Â 

 Hi everybody,

 Â 

 I think I've found a problem of Restlet Authentication 
 mechanism with GAE.

 Â 

 I have got this simple guard:

 --

 Â Â Â  public Restlet createRoot() { 

 Â Â Â Â Â Â Â Â // Create a router Restlet that 
 defines routes. 

 Â Â Â Â Â Â Â Â Router router = new 
 Router(getContext()); 

 Â 

 Â Â Â Â Â Â Â  // Defines a route for the resource 
 list of items 

 Â Â Â Â Â Â Â Â router.attach(/addcall, 
 CallResource.class); 

 Â Â Â Â Â Â Â Â router.attach(/addsms, 
 SMSResource.class); 

 Â 

 Â Â Â Â Â Â Â  ChallengeAuthenticator authenticator = 
 new 

 ChallengeAuthenticator(getContext(), 
 ChallengeScheme.HTTP_BASIC, 

 com.eris4.warp4.callfriends.server.restlet);

 Â Â Â Â Â Â Â  MapVerifier verifier = new MapVerifier();

 Â Â Â Â Â Â Â  verifier.getSecrets().put(callFriends, 

 

Problem with Reloading

[Sopasakis Pantelis]

Dear List,
  Hi for the first time, cause I'm a new member. I've developed a web
service based on Restlet 1.1.5 which runs as a standalone application
using Grizzly. I deciided to migrate to Restlet version 2.0. m3 and
after some refactoring and changes in my code, I managed to make the
whole thing work just fine! 

In the server class, I attach both an application and some static html
files including a javadoc directory. This is the server class:


***

package org.opentox.server;
 
import java.util.logging.Level;
import java.util.logging.Logger;
import org.opentox.Applications.OpenToxApplication;
import org.opentox.Resources.AbstractResource;
import org.restlet.Application;
import org.restlet.Component;
import org.restlet.data.LocalReference;
import org.restlet.data.Protocol;
import org.restlet.resource.Directory;
import org.restlet.routing.VirtualHost;
 
/**
*
* @author chung
*/
public class Server {
 
public static void main(String[] args){
// Create a component
   Component component = new Component();
 
   component.getServers().add(Protocol.HTTP, 3000);
 
   component.getClients().add(Protocol.FILE);
 
 
   LocalReference javadoc =
LocalReference.createFileReference(
  AbstractResource.javadocDir);
 
   LocalReference home =
   LocalReference.createFileReference(
  AbstractResource.HTMLDir);
 
 
   Directory javadocDirectory = new
Directory(component.getContext().createChildContext(), javadoc);
   Directory homeDirectory = new
Directory(component.getContext().createChildContext(), home);
 
 
   Application application = new OpenToxApplication();
 
   VirtualHost host = new VirtualHost();
 
   host.attach(/OpenToxServices,application);
   host.attach(,homeDirectory);
   host.attach(/OpenToxServices/javadoc, javadocDirectory);
 
 
 
   component.setDefaultHost(host);
try {
component.start();
} catch (Exception ex) {
Logger.getLogger(Server.class.getName()).log(Level.SEVERE,
null, ex);
}
 
}
 
}


The problem is that when I reload any of the resources that corresponds
to a static HTML file (e.g. the javadoc), I get a status code 405
(Method Not allowed). If I reload the page again, I get the HTML but
without the CSS. I reload it again to get the correct HTML
representation but without the Images contained in it. Another reload
gives once again a status 405, then HTML without css and finally the
correct HTML. This happens each time I press F5 on mozilla BUT NOT if I
request the resource again, i.e. if I retype the URL. Note that this
happens only with the static html files. Other resources that are based
on java classes (MyResource extends ServerResource) don't have such
problems!

Having no idea how to solve that, I just separated the static files from
the service. I set up an apache server on another port (80) to deploy
the static html files and the services run on 3000. However I think
other people are experiencing the same problem, because I had the same
problem on 2 different machines.

I would appreciate any suggestions or ideas on that.

You can find the source code of the application at
http://github.com/sopasakis/yaqp 

Thank you in advance,
Sopasakis Pantelis

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2410202

Re: Problem with Reloading

[Rob Heittman]

Did you try it to see if you get the same behavior using a connector other
than Grizzly?  (e.g. Jetty or the included HTTP connector)  On refresh, most
Mozilla based browsers will try a conditional GET first to see if the
resource has changed, then if the server indicates that it has changed, will
repeat with the full GET.  The weird behavior you describe is also found
when running under Tomcat 5 if you don't send a large enough entity from
Restlet ... where that first conditional GET will fail and cause the same
symptoms in the browser.  So I'm wondering if it's connector-specific here,
too.

On Thu, Oct 22, 2009 at 8:38 AM, Sopasakis Pantelis ch...@mail.ntua.grwrote:

 Dear List,
  Hi for the first time, cause I'm a new member. I've developed a web
 service based on Restlet 1.1.5 which runs as a standalone application
 using Grizzly. I deciided to migrate to Restlet version 2.0. m3 and
 after some refactoring and changes in my code, I managed to make the
 whole thing work just fine!

 In the server class, I attach both an application and some static html
 files including a javadoc directory. This is the server class:


 ***

 package org.opentox.server;

 import java.util.logging.Level;
 import java.util.logging.Logger;
 import org.opentox.Applications.OpenToxApplication;
 import org.opentox.Resources.AbstractResource;
 import org.restlet.Application;
 import org.restlet.Component;
 import org.restlet.data.LocalReference;
 import org.restlet.data.Protocol;
 import org.restlet.resource.Directory;
 import org.restlet.routing.VirtualHost;

 /**
 *
 * @author chung
 */
 public class Server {

public static void main(String[] args){
// Create a component
   Component component = new Component();

   component.getServers().add(Protocol.HTTP, 3000);

   component.getClients().add(Protocol.FILE);


   LocalReference javadoc =
LocalReference.createFileReference(
  AbstractResource.javadocDir);

   LocalReference home =
   LocalReference.createFileReference(
  AbstractResource.HTMLDir);


   Directory javadocDirectory = new
 Directory(component.getContext().createChildContext(), javadoc);
   Directory homeDirectory = new
 Directory(component.getContext().createChildContext(), home);


   Application application = new OpenToxApplication();

   VirtualHost host = new VirtualHost();

   host.attach(/OpenToxServices,application);
   host.attach(,homeDirectory);
   host.attach(/OpenToxServices/javadoc, javadocDirectory);



   component.setDefaultHost(host);
try {
component.start();
} catch (Exception ex) {
Logger.getLogger(Server.class.getName()).log(Level.SEVERE,
 null, ex);
}

}

 }
 

 The problem is that when I reload any of the resources that corresponds
 to a static HTML file (e.g. the javadoc), I get a status code 405
 (Method Not allowed). If I reload the page again, I get the HTML but
 without the CSS. I reload it again to get the correct HTML
 representation but without the Images contained in it. Another reload
 gives once again a status 405, then HTML without css and finally the
 correct HTML. This happens each time I press F5 on mozilla BUT NOT if I
 request the resource again, i.e. if I retype the URL. Note that this
 happens only with the static html files. Other resources that are based
 on java classes (MyResource extends ServerResource) don't have such
 problems!

 Having no idea how to solve that, I just separated the static files from
 the service. I set up an apache server on another port (80) to deploy
 the static html files and the services run on 3000. However I think
 other people are experiencing the same problem, because I had the same
 problem on 2 different machines.

 I would appreciate any suggestions or ideas on that.

 You can find the source code of the application at
 http://github.com/sopasakis/yaqp

 Thank you in advance,
 Sopasakis Pantelis

 --

 http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2410202


--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2410217