RE: Basic auth and accents in passwords

[Thierry Boileau]

Hello,

thanks for your reports. Such special characters were not taken correctly into 
account. The fix is available in the svn repository.

Best regards,
Thierry Boileau

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

RE: Directory returning 500 instead of 404 for missing files

[Jerome Louvel]

Hi Tal,

Thanks for providing this test class. This wasn't the intended behavior and
this is now fixed in SVN trunk. The change was done in
UniformResource#doCatch() method, which can be overridden as a workaround if
necessary.

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



-Message d'origine-
De : Tal Liron [mailto:tal.li...@threecrickets.com] 
Envoyé : mercredi 17 février 2010 05:17
À : discuss@restlet.tigris.org
Objet : Re: Directory returning 500 instead of 404 for missing files

Ah!

Further digging showed me that what happened was that the behavior of 
catching thrown ResourceExceptions from a ServerResource has changed. 
Now, if the exception has a cause, then the error always becomes 500. 
This was not previously the case... If this is planned behavior, great, 
but just wanted to be sure.

Here is a test case that returns a 500 error:

public class Test
{
 public static class MyResource extends ServerResource
 {
 @Override
 public Representation get() throws ResourceException
 {
 throw new ResourceException( Status.CLIENT_ERROR_NOT_FOUND, 
new IOException( "This turns into a 500 error" ) );
 // The following works as I expected:
 //throw new ResourceException( Status.CLIENT_ERROR_NOT_FOUND );
 }
 }

 public static void main( String arguments[] ) throws Exception
 {
 Component component = new Component();
 try
 {
 component.getServers().add( Protocol.HTTP, 8080 );
 Application application = new Application();
 component.getDefaultHost().attach( application );
 component.getInternalRouter().attach( "/myapp", application 
).setMatchingMode( Template.MODE_STARTS_WITH );
 Router router = new Router( application.getContext() );
 application.setInboundRoot( router );
 router.attach( "/test/", MyResource.class 
).setMatchingMode( Template.MODE_STARTS_WITH );
 component.start();
 ClientResource client = new ClientResource( 
component.getContext(), "riap://component/myapp/test/" );
 // ClientResource client = new ClientResource(
 // "http://localhost:8080/test/"; );
 System.out.println( "GET: " + client.get() );
 }
 catch( ResourceException x )
 {
 System.out.println( x.getStatus() );
 }
 catch( Exception x )
 {
 x.printStackTrace();
 }
 finally
 {
 System.exit( 0 );
 }
 }
}



On 02/16/2010 01:37 AM, Thierry Boileau wrote:
> Hello Tal,
>
> using a ClientResource, I get a ResourceException when the response is 
> not successful, and both the ResourceException and the response's 
> statuses are equals to 404.
> Using a simple Client instance, the status of the response object is 
> set to 404 also. Could you explain a little bit more what happens in 
> your case?
>

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

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

RE: Memory problem using EncodeRepresentation with Gzip

[Jerome Louvel]

Hi Felix,

 

I’ve looked again at this issue and don’t see why it occurs. The close()
method should be invoked by the HTTP server connector already, sometimes
after the write(). 

  

Otherwise, in the ByteUtils class we only close the inputstream when copying
it to an outputstream, but not the outputstream itself (at least in SVN
trunk).

 

Therefore, I suspect a JVM issue and just entered a report:

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

 

Could you try setting a breakpoint on the DeflaterOutputStream#close()
method and see if it is indeed called by the HTTP server connector? BTW,
which connector are you using?

 

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

 

 

 

 

De : Thierry Boileau [mailto:thierry.boil...@noelios.com] 
Envoyé : vendredi 19 février 2010 18:09
À : discuss@restlet.tigris.org
Objet : Re: Memory problem using EncodeRepresentation with Gzip

 

Hello Felix,

do you mind to create an issue about this problem?
We don't see clearly why it could be appropriate to close the stream in the
"write" method.
Another point is that this may be related to concurrency and threads, but in
this case, the fix should be handled in another way.
This could also be related to the implementation of the JVM.

Best regards,
Thierry Boileau




Hi,
we are using Restlet 1.1.8 with spring on a tomcat server. We switched 
to the EncodeRepresentation with Gzip to reduce the traffic on client 
side. This works fine for most systems, but on one system the jvm 
crashes after a few minutes with client requests (ubuntu on an xen host).
The java process grows up to more than 3GB and crashes with a fatal error.
 
The EncodeRepresentation only calls finish() and not close() on the 
GzipOutputStream. The GzipOutputStream calls the end() method on the 
native gzip deflater at the close() method not at the finish().
 
A lot of other Represenations uses the ByteUtils to write the stream and 
there is close() on the steam. I put encoderOutputStream.close(); next 
to the finish at the write method of the EncodeRepresentation and the 
server runs.
 
Is it safe to close the stream?
 
I do not know why the problem only exists on the xen system. The heap 
size is the same, so the gc should work (and close the streams) similar 
to all other tomcats.
 
Thanks,
Felix
 
@Override
public void write(final OutputStream outputStream) throws IOException {
if (canEncode()) {
DeflaterOutputStream encoderOutputStream = null;
 
if (encoding.equals(Encoding.GZIP)) {
encoderOutputStream = new GZIPOutputStream(outputStream);
} else if (encoding.equals(Encoding.DEFLATE)) {
encoderOutputStream = new 
DeflaterOutputStream(outputStream);
} else if (encoding.equals(Encoding.ZIP)) {
final ZipOutputStream stream = new 
ZipOutputStream(outputStream);
if (getWrappedRepresentation().getDownloadName() != null) {
stream.putNextEntry(new 
ZipEntry(getWrappedRepresentation().getDownloadName()));
} else {
stream.putNextEntry(new ZipEntry("entry"));
}
 
encoderOutputStream = stream;
} else if (encoding.equals(Encoding.IDENTITY)) {
// Encoder unecessary for identity encoding
}
 
if (encoderOutputStream != null) {
getWrappedRepresentation().write(encoderOutputStream);
encoderOutputStream.finish();
encoderOutputStream.close();
} else {
getWrappedRepresentation().write(outputStream);
}
} else {
getWrappedRepresentation().write(outputStream);
}

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

Re: HTTPS / SSL not working after updating to trunk

[Bruno Harbulot]

Hi,

Sorry, that's probably due to a patch I submitted a few weeks ago and 
that was put in the trunk a couple of days ago.
The aim was to consolidate the SSL settings to have them in one place, 
but it seems that there was a line missing unfortunately.

Here is a patch:

diff --git 
a/modules/org.restlet/src/org/restlet/engine/security/SslUtils.java 
b/modules/org.restlet/src/org/restlet/engine/security/SslUtils.java
index 6ac6b93..36c7c80 100644
--- a/modules/org.restlet/src/org/restlet/engine/security/SslUtils.java
+++ b/modules/org.restlet/src/org/restlet/engine/security/SslUtils.java
@@ -218,6 +218,7 @@ public class SslUtils {

  if (result == null) {
  result = new DefaultSslContextFactory();
+result.init(helper.getHelpedParameters());
  }

  return result;



I've tried it with the Jetty connector and it fixes the problem. It 
doesn't seem to work so well with the Simple connector, I'm looking into it.

Best wishes,

Bruno.


On 25/03/2010 03:09, David Fogel wrote:
> Hi all-
>
> We recently updated our restlet libraries to the current trunk
> (specifically SVN revision 6394, which I imagine is roughly equivalent
> to the recent 2.0 RC1 release).  We were previously working with a
> build from SVN 5929, from roughly late December.  Now we're dealing
> with the fallout.  For some reason this often seems to involve
> problems that are hard to resolve, or have subtle or hard to reproduce
> causes.  Probably because of the fast pace of improvements in restlet
> development
>
> Our previous problem, which I posted earlier had to do with the
> built-in Client connector waiting/suspended on a latch that never
> returns.  We are temporarily avoiding that by using the HttpClient 4
> extension, which doesn't have this problem for us, but we'd prefer I
> think to use the built-in ones.
>
> The next thing we discovered was broken is HTTPS access for our web
> app.  We now get a "The connection was reset" message in the browser
> (in this case it is firefox), when we try to GET a resource at the
> HTTPS port, and no request is logged by restlet.  This had been
> working fine for use with the december build.
>
> Our configuration for the Component protocols is (roughly) as follows:
>
>  Component c = new Component();
>  c.getServers().add(Protocol.HTTP, 8080);
>  Series  params = c.getServers().add(Protocol.HTTPS,
> 8443).getContext().getParameters();
>  params.add("keystorePath",
> "/an/absolute/path/to/the/keystore/localhost.jks");
>  params.add("keystorePassword", "not actually our password");
>  params.add("keyPassword", "another password");
>
> I'm not sure if it makes a difference, but we're using the
> simpleframework server connectors. I tried simpleversion 4.1.17 (which
> was working before and now doesn't) as well as the slightly newer
> 4.1.19 build.
>
> So, did something break in recent versions?  or were we doing
> something wrong in the first place that just happened to work?
>
> I will also note that the documentation is VERY CONFUSING regarding
> configuring HTTPS/SSL in the userguide.  There is only one example,
> and that example specifically uses the org.restlet.ext.ssl extension
> along with a SSLContextFactory set to be
> "org.restlet.ext.ssl.PkixSslContextFactory".  I think that an example
> which explains the option of using the DefaultSslContextFactory would
> be appropriate, along with some explanation about which situations are
> better handled by the extension.  Given that configuring one's server
> for HTTPS must be an extremely common task, it seems like there should
> be more about this- as it stands there seems to be more docs for
> setting up client cert authentication etc, which is probably less
> common.
>
> Thanks,
>-Dave Fogel
>
> --
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2464621
>

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

RE: RIAP protocol and "local" Representions

[Jerome Louvel]

Hi Valdis,

 

It’s taking a while, but I’m getting to your issue J

 

I have just fixed all the ‘object’ converters to properly handle local 
serialization/deserialization. I’ve tested it successfully using the attached 
class. It should work with your annotated resources now. Please let me know 
when you get a chance to play with the next snapshot/release.

 

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

 

 

 

 

De : Valdis Rigdon [mailto:valdis.rig...@gmail.com] 
Envoyé : dimanche 21 février 2010 16:41
À : discuss@restlet.tigris.org
Objet : Re: RIAP protocol and "local" Representions

 

Is doing something like this possible when using the annotated client-side 
interfaces?

 

I've had to put this work to the side, but I'm planning on getting back to it 
in a few weeks.  If I remember correctly, I ended up registering a RIAP 
ConverterService which detected if the request was made using the RIAP protocol 
and then used a custom Representation to just hold the Object instance.

 

 

Valdis

 

On Feb 21, 2010, at 9:22 AM, Jerome Louvel wrote:





Hi Valdis,

 

It does work out of the box. If you specify that you prefer 
MediaType.APPLICATION_JAVA_OBJECT as a RIAP client, then the converter service 
with return an ObjectRepresentation instance wrapping your local object as 
indicated by Thierry.

 

Then you can directly retrieve the local object *without* any 
serialization/deserialization by doing:

 

MyObject myObj = (MyObject) ((ObjectRepresentation)myEntity).getObject();

 

Hope this helps!

 

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

 

 

 

De : Rob Heittman [mailto:rob.heitt...@solertium.com] 
Envoy馮bsp;: lundi 25 janvier 2010 15:42
 : discuss@restlet.tigris.org
Objet : Re: RIAP protocol and "local" Representions

 

We use a lot of RIAP but very little ConverterService ... that might change if 
it worked more like you expect out of the box.

On Mon, Jan 25, 2010 at 2:17 PM, Valdis Rigdon  wrote:

Is no one else using RIAP in this
way? Or are people using RIAP and letting objects be serialized
locally?

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

Converter.java
Description: Binary data

RE: Redirected resources URIs

[Jerome Louvel]

Hi Fabian,

The "Via" HTTP header is now properly parsed into an 
org.restlet.data.RecipientInfo class accessible with the Message#recipientsInfo 
list property since 2.0 RC1. This should help :)

See the updated mapping page:
http://wiki.restlet.org/docs_2.0/13-restlet/27-restlet/324-restlet/130-restlet.html

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




-Message d'origine-
De : Fabian Mandelbaum [mailto:fmandelb...@gmail.com] 
Envoyé : lundi 22 février 2010 18:33
À : discuss@restlet.tigris.org
Objet : Re: Redirected resources URIs

Hello Thierry,

I've just found again the Mapping HTTP semantics page and was reading it :-)

The idea is to try to get the original host:port requested by the
client, and if the redirection engine is before the Restlet
application, the HTTP Host header for requests hitting the Restlet app
are already redirected.

However, WebDAV needs (or at least all the implementations I've seen
so far do it like this) the URL of the original call, not the
redirected URL, in the  element of some DAV responses. So I
think I'll get the Via header and parse it to get the 1st host:port
pair in the Via 'chain' to get the original host:port requested (that
is, before all redirections/proxies 'in the middle', between the
client and my Restlet server).

Thanks.

On Mon, Feb 22, 2010 at 2:11 PM, Thierry Boileau
 wrote:
> Hello Fabian,
>
> regarding the support of HTTP headers, you can have a look at the user guide
> here: http://wiki.restlet.org/docs_2.0/130-restlet.html. The via header is
> not supported yet.
> Thus, you will to get the "org.restlet.http.headers" reques's attribute...
>
> I see a problem if the rewriting rule is also based on the path.
>
> Best regards,
> Thierry Boileau
>
> Hello there,
>
> one of the elements needed in a WebDAV response for the PROPFIND
> method is the href (full URI) of the resource in question. For
> example:
>
> http://host:port/path/to/the/resource
>
> Now, if my Restlet application is 'behind' an URL redirect engine, for
> example Apache's mod_rewrite, and the client makes the request to:
>
> http://redirected.uri/path/to/the/resource
>
> using something like:
>
> String hrefs = String.format("%s%s", getHostRef().toString(false,
> false), Reference.decode(fragment)); // NOI18N
>
> to compute the text node's value inside  I get:
>
> http://inside.host:port/path/to/the/resource
>
> instead of (the expected by the client which doesn't need to know
> anything about proxies and redirection):
>
> http://redirected.uri/path/to/the/resource
>
> So, I was wondering if getting the HTTP standard "Via" header's first
> value (ex: Via: 1.1 redirected.uri 1.1 internal.first.host 1.1
> inside.host:port) to build the URI's value is the right thing to do to
> get http://redirected.uri/path/to/the/resource, and if restlet has a
> mapped method to get the Via header's value, or I'll have to use the
> getRequest().getAttributes().get("org.restlet.http.headers") method
> and some String manipulation magic to get the 1st value.
>
> I hope to have been clear enough, thanks in advance for your prompt
> and accurate answer.
>
>



-- 
Fabián Mandelbaum
IS Engineer

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

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

RE: Minimum GWT code for ClientResource from a different host

[Jerome Louvel]

Hi Mickey,

You are hit by the Same Origin Policy (SOP) restrictions. 
http://en.wikipedia.org/wiki/Same_origin_policy

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




-Message d'origine-
De : MickeyMiner [mailto:x.restlet@kybernetika.de] 
Envoyé : mardi 23 février 2010 13:00
À : discuss@restlet.tigris.org
Objet : Minimum GWT code for ClientResource from a different host

Hi,

Could anyone please tell a rookie if there is any server side code
absolutely necessary in order to fetch data from a remote host? Later on I
will want to add authentication...

I have set up a working testGwtRestlet-2-0 example and added following lines
to onModuleLoad:


ClientResource r = new
ClientResource("http://www.remotedomein.com/RESTfulTest/resources/customers/
pkey/2176172632");
r.setOnReceived(new Uniform() {
public void handle(Request request, Response response) {
System.out.println("request.getResourceRef(): " +
request.getResourceRef());
System.out.println("response.getStatus(): " +
response.getStatus());
}
});
r.get();

as a debug message a get:

request.getResourceRef():
http://www.remotedomein.com/RESTfulTest/resources/customers/pkey/2176172632
response.getStatus(): Internal Connector Error (1002) -
(NS_ERROR_NOT_AVAILABLE): Component returned failure code: 0x80040111
(NS_ERROR_NOT_AVAILABLE) [nsIXMLHttpRequest.statusText]
 QueryInterface: function QueryInterface() {
[native code]
}
 result: 2147746065
 filename: http://127.0.0.1:
 lineNumber: 36
 columnNumber: 0
 inner: null
 data: null
 initialize: function initialize() {
[native code]
}

Thank you for your help.

mm
-- 
View this message in context:
http://n2.nabble.com/Minimum-GWT-code-for-ClientResource-from-a-different-ho
st-tp4618429p4618429.html
Sent from the Restlet Discuss mailing list archive at Nabble.com.

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

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

Re: Why is the default http server so much faster than Jetty and Grizzly?

[weltermann17]

Reading the documentation as always helps:

Switching the internal type for Jetty to BlockingChannelConnector (type=2)
improves the performance dramatically:

Results: troughput in megabytes per second (MB/sec)

   Internal/Default   Jetty 
  
Grizzly
localhost empty cache > 40  17  
16
localhost from cache   > 120 > 120  
 
> 120

100mbit   empty cache10.8   10.9
  
0.5
100mibt   from cache   10.7   9.8   
  
11

Grizzly does not seem to be configurable in such an easy way, maybe somebody
has an idea?

Guido Schmidt

-- 
View this message in context: 
http://n2.nabble.com/Why-is-the-default-http-server-so-much-faster-than-Jetty-and-Grizzly-tp4777255p4797065.html
Sent from the Restlet Discuss mailing list archive at Nabble.com.

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

RE: Restlet JAX-RS question

[Jerome Louvel]

Hi guys,

Sorry for being late to the discussion. 

The dependency on the Servlet API is an issue indeed, but I think you should
be able to achieve what you want by injecting the Restlet request/response
and then from that retrieving the Servlet request/response.

org.restlet.ext.servlet.internal.ServletCall class has this static method to
help:
getRequest(org.restlet.Request) : HttpServletRequest

In order to make this more obvious, I've just added to SVN trunk a
ServletUtils class to the Servlet extension with two static methods to
easily retrieve the Servlet request/response.

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


-Message d'origine-
De : stephan.ko...@web.de [mailto:stephan.ko...@web.de] 
Envoyé : vendredi 26 février 2010 18:22
À : discuss@restlet.tigris.org
Objet : Re: Restlet JAX-RS question

Hi Fabio, hi Jerome, hi Thierry,

cool Fabio, that you want allow the the Servlet artifacts in JAX-RS. 
Every help is welcome.

I think it is important, that the JAX-RS extension has no dependency to 
the Servlet API, so we need to have another way.
@ Jerome and Theirry: Do you think it useful to create an "extension 
extension", that has all that needs dependencies to the Servlet API? 
Than I have an idea how to implement it. Or do you have another ideas?

Are there other ideas what also could be included, that means could be 
annotated with @Context?

best regards
   Stephan

Fabio Mancinelli schrieb:
> Hi Stephan,
>
> I am writing to you to ask a little advice.
> I was thinking about writing a patch to the JAX-RS extension in order
> to allow the injection of the HttpServletRequest and
> HttpServletRespone objects using the @Context annotation.
>
> Could you point me to the code where injection is done and if I should
> be aware of some architectural details you used for implementing the
> injection mechanism?
>
> Thank you.
>
> Regards,
> Fabio
>

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

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

RE: Random Grizzly NIO Exception

[Jerome Louvel]

Hi Sopasakis,

Looking at the code, this shouldn't happen normally. Could you enter a bug
report with the precise version/environment and stack trace? Then, we'll
need to find a way to reproduce it :)
http://restlet.tigris.org/issues/enter_bug.cgi

If this is blocking you, I suggest using another connector such as Jetty.

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


-Message d'origine-
De : Sopasakis Pantelis [mailto:ch...@mail.ntua.gr] 
Envoyé : vendredi 26 février 2010 19:31
À : discuss@restlet.tigris.org
Objet : Random Grizzly NIO Exception

Dear all,
 I'm using Restlet 2.0 m7 and I have a resource that returns a large URI
list (about 1 thousands URIs or more) upon a GET request. In general
everything seem to work without bugs in my application except for that
resource which every now and then throws an IOException with message
"Unable to write to the non-blocking channel. Unable to select the
channel to write to it. Selection timed out.". It looks like the issue
reported here:
http://www.mail-archive.com/discuss@restlet.tigris.org/msg05941.html 
Is there a way to avoid this exception? 

Note also that the problem is not reproduced for smaller URI lists or
smaller representations in general.

My source code can be found online at the following URLs : 
http://github.com/alphaville/yaqp-turbo/blob/master/src/org/opentox/www/rest
/resources/ModelsResource.java
http://github.com/alphaville/yaqp-turbo/blob/master/src/org/opentox/io/proce
ssors/OutputProcessor.java 
http://github.com/alphaville/yaqp-turbo/blob/master/src/org/opentox/www/rest
/Applecation.java 

The application is deployed and the resource for which the exception is
thrown is found at http://opentox.ntua.gr:3000/model 

I would appreciate any help,

thank you in advance,


Sopasakis Pantelis
Dipl. Chemical Engineer,
MSc. Applied Mathematics
National Technical University of Athens
Automatic Control Laboratory
email: ch...@mail.ntua.gr
tel(office): +30 210 7723236

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

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

RE: M7 and TunnelService fix still not working for IE7/8 (or so it seems)

[Jerome Louvel]

Hi Bruno,

After recent changes, the latest "accept.properties" file in SVN trunk has
this:

#Internet explorer
agentName: msie
acceptOld: 
acceptNew:
text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

I guess with this you won't need to customize it.

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



-Message d'origine-
De : Bruno Harbulot [mailto:bruno.harbu...@manchester.ac.uk] 
Envoyé : mardi 2 mars 2010 15:53
À : discuss@restlet.tigris.org
Objet : Re: M7 and TunnelService fix still not working for IE7/8 (or so it
seems)

Hi,

Just in case it may help, last week, I had to use the following 
configuration for IE8, using the snapshot in the Maven repository
(org.restlet-2.0-20100210.140104-6132.jar).

#Internet explorer
agentName: msie
acceptOld: */*
acceptNew: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

agentName: msie
acceptOld: image/gif, image/jpeg, image/pjpeg, 
application/x-ms-application, application/vnd.ms-xpsdocument, 
application/xaml+xml, application/x-ms-xbap, */*
acceptNew: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

I'm not sure why, but for some requests, IE was sending either */* or 
the longer list.

Best wishes,

Bruno.

Jerome Louvel wrote:
> Hi Fabian,
> 
> It seems that IE6 doesn't use "*/*" but a longer Accept HTTP header so we
need to be careful.
> 
> One option you have is overriding the default "accept.properties" file
from Restlet with your own to do tests. You need to place it in a
"/org/restlet/service/accept.properties" location, available in your
classpath in front of Restlet JAR.
> 
> For example, it might be possible to add several rules for IE to match all
situations?
> 
> Best regards,
> Jerome Louvel
> --
> Restlet ~ Founder and Technical Lead ~ http://www.restlet.org
> Noelios Technologies ~ http://www.noelios.com

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

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

RE: Spring not working with Restlet

[Jerome Louvel]

FYI, thread continued here:
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2454223


-Message d'origine-
De : javaxmlsoapdev [mailto:vika...@yahoo.com] 
Envoyé : mercredi 3 mars 2010 02:30
À : discuss@restlet.tigris.org
Objet : Spring not working with Restlet

I have following Spring config and code. Keep getting 404 error when I hit
the URL


   
  
   
   
  
 
   
  
 
  
   
 
  
   

Where IssueRestResource is as follow

public class IssueRestResource extends Resource {
   private Log log = LogFactory.getLog(this.getClass().getName());
   private TechServiceImpl techServiceImpl;
   
   public IssueRestResource(){
 
   }
   public IssueRestResource(Context context, Request request, Response
response) {
super(context, request, response);
init(context, request, response);
}

@Override
   public void init(Context context, Request request, Response
response){
  if(log.isDebugEnabled())
 log.debug("Inside init");
  super.init(context, request, response);
  getVariants().add(new Variant(MediaType.TEXT_XML));
   }
   
 
/**  
 * Returns a full representation for a given variant.  
 */  
@Override  
public Representation represent(Variant variant) throws
ResourceException {  
   if(log.isDebugEnabled())
  log.debug("Inside represent");
   IssueList issues = techServiceImpl.findAllIssues(1);
   if(log.isDebugEnabled()){
  log.debug("Issues "+issues);
  if(!issues.isEmpty())
……..

In web.xml
  
  org.restlet.application  

webservice.rest.TechRestlet  

   

  
 
  RestletServlet  

 com.noelios.restlet.ext.servlet.ServerServlet  
  
 
 
 
 
  RestletServlet  
  /service/issue  
   

Where TechRestlet code is nothing but returning Router from Spring context.

public class TechRestlet extends Application {
   private Log log = LogFactory.getLog(this.getClass().getName());
   
 
@Override
public Restlet createRoot(){
   if(log.isDebugEnabled()){
  log.debug("Inside createRoot");
   }
   return (SpringRouter)APPLICATION_CONTEXT.getBean("restletRouter");
 

}

when I type in url http://localhost:8080/myapp/service/issue I keep getting
404 error. In the log I can see following

INFO: RestletServlet: [Noelios Restlet Engine] - Attaching application:
webservice.rest.techrest...@68ec7913 to URI: /myapp/service/issue

Mar 1, 2010 12:41:55 PM com.noelios.restlet.LogFilter afterHandle
INFO: 2010-03-01 12:41:55   GET   /myapp/service/issue - 
404330-  8  

My debug statements from IssueTechResource’s init() & represent() methods
never get printed, which make s me believe Resource isn’t getting
initialized properly or something? 
-- 
View this message in context: 
http://n2.nabble.com/Spring-not-working-with-Restlet-tp4664881p4664881.html
Sent from the Restlet Discuss mailing list archive at Nabble.com.

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

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

RE: Spring Restlet not working

[Jerome Louvel]

Hi there,

Were you able to solve this issue? If not, please provide a reproducible
test project and enter a defect report.

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




-Message d'origine-
De : javaxmlsoapdev [mailto:vika...@yahoo.com] 
Envoyé : mercredi 3 mars 2010 04:09
À : discuss@restlet.tigris.org
Objet : Spring Restlet not working

  
 techRestApi  

com.noelios.restlet.ext.spring.SpringServerServlet  

 org.restlet.component  
 restletComponent  

  
  
 techRestApi  
 /techIssueRestResource/*  
 
  
  RestletServlet  

 com.noelios.restlet.ext.servlet.ServerServlet   



And in spring bean xml file
component is declared as follow



  
 

It keeps throwing 
SEVERE: techriskRestApi: [Noelios Restlet Engine] - The ServerServlet
couldn't find the target class. Please check that your classpath includes
restletComponent
java.lang.ClassNotFoundException: restletComponent
at
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.jav
a:1358)

For some reason it's not able to lookup this "restletComponent" bean from
spring context. 

Any idea?

Thanks,
-- 
View this message in context:
http://n2.nabble.com/Spring-Restlet-not-working-tp4665282p4665282.html
Sent from the Restlet Discuss mailing list archive at Nabble.com.

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

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

RE: Restlet Security - Securing URLs

[Jerome Louvel]

Hi Nirav,

 

The JAAS extension integrates with Restlet for the authentication aspects
thanks to the JaasVerifier class. For the authorization aspect, you can use
the static JaasUtils#createSubject(ClientInfo) method to retrieve a JAAS
Subject from your authenticated request. 

 

The org.restlet.security.User and org.restlet.security.Role implement the
java.security.Principal interface in SVN trunk. Before (including 2.0 RC1),
we used RolePrincipal and UserPrincipal classes in the JAAS extension.

 

Regarding JAAS authorization, here is some background info:

http://java.sun.com/j2se/1.5.0/docs/guide/security/jaas/tutorials/GeneralAcn
AndAzn.html

 

You then need to define your JAAS policy file as usual, pointing to the
org.restlet.security.User/Role classes as the principal classes to
grant/deny permissions. You can then use Subject.doAs() mechanism normally.
This is really standard JAAS code at this point.

 

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

 

 

 

 

De : Nirav [mailto:nirav.sha...@gmail.com] 
Envoyé : mercredi 3 mars 2010 15:36
À : Jerome Louvel
Cc : discuss
Objet : Re: Restlet Security - Securing URLs

 

Thanks Jerome! That's a lot of helpful information.

 

Though am currently wondering how do I incorporate JAAS authorization in.
Have figured out the JAAS authentication bit quite well, but a little lost
around the authorization aspect. Is there any analogus to the Subject.doAs
mechanism. Also what would the policy file look like? Is there anywhere I
can read on these questions.


Cheers!
Nirav



On Fri, Feb 26, 2010 at 1:55 PM, Jerome Louvel 
wrote:

Hi Nirav,

Thanks for your feed-back. The new security API is still fresh, so we also
look forward to hearing how it is applied in the field and what are its
limitations. Regarding authorization, there are generally two approaches:

1) Coarse-grained authorization

You configure some Authorizer instances (or subclasses like RoleAuthorizer,
MethodAuthorizer, etc.) and attach them at key points in the call routing
graph (before a Router, for a single route, etc.).

This works nicely if you can assign roles to your authenticated users and if
your authorization rules don't vary too much between resources. Otherwise,
you might end-up with an Authorizer instance in front of each resource
class...

2) Fine-grained authorization

If your authorization rules tend to be very specific to each resource class,
or more complexly specific to resource instances, then it is better to
handle them at the resource level manually. As an help, you can leverage the
ServerResource#isInRole() method.

3) Mix approaches 1) and 2)

This can provide a good balance.

---

Now, back to your use case, I would recommend clearly separating the "user
-> role(s)" mapping rules (stored in LDAP) from the "role -> permission"
rules.

For the latter case, you can code those rules statically in the routing code
using RoleAuthorizer as in approach 1). If those rules are very dynamic and
must be stored in LDAP, I would recommend a fourth approach

4) Middle-grained authorization

The idea would be to define several URI subspaces in your overall
application URI space. Each subspace would have a unique name, like a role
name. Then in LDAP you could assign permissions to roles for each subspace,
not duplicating URI information in LDAP.

Then, in your Restlet application, you could have a SubspaceAuthorizer class
that would retrieve the rules from LDAP based on a given subspace name. An
instance of SubspaceAuthorizer for each identified subspace should be
created and attached to the proper place in the routing graph.

Therefore you wouldn't need to duplicate URI matching code or have to
maintain URI templates in several places.

Hope this helps! BTW, I've copied this explanation in the wiki:
http://wiki.restlet.org/docs_2.0/13-restlet/27-restlet/46-restlet/113-restle
 
t.html


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




-Message d'origine-
De : stephan.ko...@web.de [mailto:stephan.ko...@web.de]
Envoyé : jeudi 18 février 2010 19:52
À : discuss@restlet.tigris.org
Objet : Re: Restlet Security - Securing URLs

Hi Nirav,

you mean, you have one Authenticator and one Authorizator for a lot of
resources?
Why do you not protect every resource or some routers with own instances
of the Authenticator and/or Authorizator?

best regards
  Stephan

Nirav Shah schrieb:
> Hello All !
>
> I have been working on the Security module of our product since about past
two months now and have a nice mechanism integrated into Restlet that lets
us implement our security needs.
>
> We have overwritten the Authenticator and Authorizer to hav our custom
requirement

RE: Basic auth and accents in passwords

[webpost]

Hi,

Thank you for fixing this.
Do you plan to release a new package soon ?

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

Re: Restlet JAX-RS question

[Fabio Mancinelli]

Hi again...

by the way the JAX-RS module has already a dependency on the servlet
API 
(http://restlet.tigris.org/source/browse/*checkout*/restlet/trunk/modules/org.restlet.ext.jaxrs/pom.xml?revision=5522&content-type=text%2Fplain)

-Fabio

On Thu, Mar 25, 2010 at 12:35 PM, Jerome Louvel
 wrote:
> Hi guys,
>
> Sorry for being late to the discussion.
>
> The dependency on the Servlet API is an issue indeed, but I think you should
> be able to achieve what you want by injecting the Restlet request/response
> and then from that retrieving the Servlet request/response.
>
> org.restlet.ext.servlet.internal.ServletCall class has this static method to
> help:
> getRequest(org.restlet.Request) : HttpServletRequest
>
> In order to make this more obvious, I've just added to SVN trunk a
> ServletUtils class to the Servlet extension with two static methods to
> easily retrieve the Servlet request/response.
>
> Best regards,
> Jerome Louvel
> --
> Restlet ~ Founder and Technical Lead ~ http://www.restlet.org
> Noelios Technologies ~ http://www.noelios.com
>
>

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

Re: Restlet JAX-RS question

[Fabio Mancinelli]

On Thu, Mar 25, 2010 at 12:35 PM, Jerome Louvel
 wrote:
> Hi guys,
>
> Sorry for being late to the discussion.
>
> The dependency on the Servlet API is an issue indeed, but I think you should
> be able to achieve what you want by injecting the Restlet request/response
> and then from that retrieving the Servlet request/response.
>
> org.restlet.ext.servlet.internal.ServletCall class has this static method to
> help:
> getRequest(org.restlet.Request) : HttpServletRequest
>
> In order to make this more obvious, I've just added to SVN trunk a
> ServletUtils class to the Servlet extension with two static methods to
> easily retrieve the Servlet request/response.
>
> Best regards,
> Jerome Louvel
> --

Hi,

I don't know if you have seen it, but I contributed a patch...
Actually I inject directly the HttpServletRequest using something that
maybe is similar to what you describe there (hence, the ext.servlet
dependency)

By injecting the Restlet Request we would remove the dependency and we
provide a way for retrieving the HttpServletRequest in the JAX-RS
resources. It is indeed a good idea! And is almost implemented in the
patch I sent (it's just a matter of removing some lines, providing
that the rest is good :))

Thanks for the feedback!

-Fabio

P.S.: Link to the patch : http://restlet.tigris.org/issues/show_bug.cgi?id=722

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

RE: Basic auth and accents in passwords

[Thierry Boileau]

Hi,

well, maybe in one month. However, you can get the current snapshot of the 1.1 
branch (refreshed each day) from this page:

http://www.restlet.org/downloads/1.1/

Best regards,
Thierry Boileau

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

Re: HTTPS / SSL not working after updating to trunk

[Bruno Harbulot]

Hi,

I've put a patch for this in 
http://restlet.tigris.org/issues/show_bug.cgi?id=977

I've tried it locally with the Simple, Jetty and Grizzly connectors (and 
the test cases pass).

This patch also removes the explicit use of DefaultSslContextFactory in 
the test case, to assume we're testing the simple configuration case. 
The keyPassword is also the keystorePassword if absent (rather than "" 
by default, which never works).


Since you're working from the SVN trunk, I suppose you might be able to 
apply the patch as well. Please let us know if it fixes the problem you had.


You're right regarding the documentation, it could be clearer. The basic 
configuration should be like this (that's what you had):

Component component = new Component();
Server server = component.getServers().add(Protocol.HTTPS, 8443);
Series params = server.getContext().getParameters();
params.add("keystorePath", "/.../.../...");
params.add("keystoreType", "PKCS12"); // KeyStore.getDefaultType() by 
default (JKS).
params.add("keystorePassword", "testtest");
params.add("keyPassword", "testtest");


The use of SslContextFactory is for people who want to pass more 
customised SSLContexts.


Best wishes,

Bruno.


Bruno Harbulot wrote:
> Hi,
> 
> Sorry, that's probably due to a patch I submitted a few weeks ago and 
> that was put in the trunk a couple of days ago.
> The aim was to consolidate the SSL settings to have them in one place, 
> but it seems that there was a line missing unfortunately.
> 
> Here is a patch:
> 
> diff --git 
> a/modules/org.restlet/src/org/restlet/engine/security/SslUtils.java 
> b/modules/org.restlet/src/org/restlet/engine/security/SslUtils.java
> index 6ac6b93..36c7c80 100644
> --- a/modules/org.restlet/src/org/restlet/engine/security/SslUtils.java
> +++ b/modules/org.restlet/src/org/restlet/engine/security/SslUtils.java
> @@ -218,6 +218,7 @@ public class SslUtils {
> 
>   if (result == null) {
>   result = new DefaultSslContextFactory();
> +result.init(helper.getHelpedParameters());
>   }
> 
>   return result;
> 
> 
> 
> I've tried it with the Jetty connector and it fixes the problem. It 
> doesn't seem to work so well with the Simple connector, I'm looking into it.
> 
> Best wishes,
> 
> Bruno.
> 
> 
> On 25/03/2010 03:09, David Fogel wrote:
>> Hi all-
>>
>> We recently updated our restlet libraries to the current trunk
>> (specifically SVN revision 6394, which I imagine is roughly equivalent
>> to the recent 2.0 RC1 release).  We were previously working with a
>> build from SVN 5929, from roughly late December.  Now we're dealing
>> with the fallout.  For some reason this often seems to involve
>> problems that are hard to resolve, or have subtle or hard to reproduce
>> causes.  Probably because of the fast pace of improvements in restlet
>> development
>>
>> Our previous problem, which I posted earlier had to do with the
>> built-in Client connector waiting/suspended on a latch that never
>> returns.  We are temporarily avoiding that by using the HttpClient 4
>> extension, which doesn't have this problem for us, but we'd prefer I
>> think to use the built-in ones.
>>
>> The next thing we discovered was broken is HTTPS access for our web
>> app.  We now get a "The connection was reset" message in the browser
>> (in this case it is firefox), when we try to GET a resource at the
>> HTTPS port, and no request is logged by restlet.  This had been
>> working fine for use with the december build.
>>
>> Our configuration for the Component protocols is (roughly) as follows:
>>
>>  Component c = new Component();
>>  c.getServers().add(Protocol.HTTP, 8080);
>>  Series  params = c.getServers().add(Protocol.HTTPS,
>> 8443).getContext().getParameters();
>>  params.add("keystorePath",
>> "/an/absolute/path/to/the/keystore/localhost.jks");
>>  params.add("keystorePassword", "not actually our password");
>>  params.add("keyPassword", "another password");
>>
>> I'm not sure if it makes a difference, but we're using the
>> simpleframework server connectors. I tried simpleversion 4.1.17 (which
>> was working before and now doesn't) as well as the slightly newer
>> 4.1.19 build.
>>
>> So, did something break in recent versions?  or were we doing
>> something wrong in the first place that just happened to work?
>>
>> I will also note that the documentation is VERY CONFUSING regarding
>> configuring HTTPS/SSL in the userguide.  There is only one example,
>> and that example specifically uses the org.restlet.ext.ssl extension
>> along with a SSLContextFactory set to be
>> "org.restlet.ext.ssl.PkixSslContextFactory".  I think that an example
>> which explains the option of using the DefaultSslContextFactory would
>> be appropriate, along with some explanation about which situations are
>> better handled by the extension.  Given that configuring one's server
>> for HTTPS must be an extremely common task, it seems like there should
>> be more about th

RE: HTTPS / SSL not working after updating to trunk

[Jerome Louvel]

Hi all,

Bruno's patch has just been applied to SVN trunk.

Best regards,
Jerome 

-Message d'origine-
De : Bruno Harbulot [mailto:bruno.harbu...@manchester.ac.uk] 
Envoyé : jeudi 25 mars 2010 15:32
À : discuss@restlet.tigris.org
Objet : Re: HTTPS / SSL not working after updating to trunk

Hi,

I've put a patch for this in 
http://restlet.tigris.org/issues/show_bug.cgi?id=977

I've tried it locally with the Simple, Jetty and Grizzly connectors (and 
the test cases pass).

This patch also removes the explicit use of DefaultSslContextFactory in 
the test case, to assume we're testing the simple configuration case. 
The keyPassword is also the keystorePassword if absent (rather than "" 
by default, which never works).


Since you're working from the SVN trunk, I suppose you might be able to 
apply the patch as well. Please let us know if it fixes the problem you had.


You're right regarding the documentation, it could be clearer. The basic 
configuration should be like this (that's what you had):

Component component = new Component();
Server server = component.getServers().add(Protocol.HTTPS, 8443);
Series params = server.getContext().getParameters();
params.add("keystorePath", "/.../.../...");
params.add("keystoreType", "PKCS12"); // KeyStore.getDefaultType() by 
default (JKS).
params.add("keystorePassword", "testtest");
params.add("keyPassword", "testtest");


The use of SslContextFactory is for people who want to pass more 
customised SSLContexts.


Best wishes,

Bruno.


Bruno Harbulot wrote:
> Hi,
> 
> Sorry, that's probably due to a patch I submitted a few weeks ago and 
> that was put in the trunk a couple of days ago.
> The aim was to consolidate the SSL settings to have them in one place, 
> but it seems that there was a line missing unfortunately.
> 
> Here is a patch:
> 
> diff --git 
> a/modules/org.restlet/src/org/restlet/engine/security/SslUtils.java 
> b/modules/org.restlet/src/org/restlet/engine/security/SslUtils.java
> index 6ac6b93..36c7c80 100644
> --- a/modules/org.restlet/src/org/restlet/engine/security/SslUtils.java
> +++ b/modules/org.restlet/src/org/restlet/engine/security/SslUtils.java
> @@ -218,6 +218,7 @@ public class SslUtils {
> 
>   if (result == null) {
>   result = new DefaultSslContextFactory();
> +result.init(helper.getHelpedParameters());
>   }
> 
>   return result;
> 
> 
> 
> I've tried it with the Jetty connector and it fixes the problem. It 
> doesn't seem to work so well with the Simple connector, I'm looking into
it.
> 
> Best wishes,
> 
> Bruno.
> 
> 
> On 25/03/2010 03:09, David Fogel wrote:
>> Hi all-
>>
>> We recently updated our restlet libraries to the current trunk
>> (specifically SVN revision 6394, which I imagine is roughly equivalent
>> to the recent 2.0 RC1 release).  We were previously working with a
>> build from SVN 5929, from roughly late December.  Now we're dealing
>> with the fallout.  For some reason this often seems to involve
>> problems that are hard to resolve, or have subtle or hard to reproduce
>> causes.  Probably because of the fast pace of improvements in restlet
>> development
>>
>> Our previous problem, which I posted earlier had to do with the
>> built-in Client connector waiting/suspended on a latch that never
>> returns.  We are temporarily avoiding that by using the HttpClient 4
>> extension, which doesn't have this problem for us, but we'd prefer I
>> think to use the built-in ones.
>>
>> The next thing we discovered was broken is HTTPS access for our web
>> app.  We now get a "The connection was reset" message in the browser
>> (in this case it is firefox), when we try to GET a resource at the
>> HTTPS port, and no request is logged by restlet.  This had been
>> working fine for use with the december build.
>>
>> Our configuration for the Component protocols is (roughly) as follows:
>>
>>  Component c = new Component();
>>  c.getServers().add(Protocol.HTTP, 8080);
>>  Series  params = c.getServers().add(Protocol.HTTPS,
>> 8443).getContext().getParameters();
>>  params.add("keystorePath",
>> "/an/absolute/path/to/the/keystore/localhost.jks");
>>  params.add("keystorePassword", "not actually our password");
>>  params.add("keyPassword", "another password");
>>
>> I'm not sure if it makes a difference, but we're using the
>> simpleframework server connectors. I tried simpleversion 4.1.17 (which
>> was working before and now doesn't) as well as the slightly newer
>> 4.1.19 build.
>>
>> So, did something break in recent versions?  or were we doing
>> something wrong in the first place that just happened to work?
>>
>> I will also note that the documentation is VERY CONFUSING regarding
>> configuring HTTPS/SSL in the userguide.  There is only one example,
>> and that example specifically uses the org.restlet.ext.ssl extension
>> along with a SSLContextFactory set to be
>> "org.restlet.ext.ssl.PkixSslContextFactory".  I think that an example
>> which expla

Re: HTTPS / SSL not working after updating to trunk

[David Fogel]

Hi Bruno, Jerome-

Thanks for taking a look at this!  I've just updated to the latest in
trunk (SVN revision 6407).

Unfortunately, the fix doesn't seem to be working- in fact now what
I'm seeing is that the connection is never made from the client, but
now my server starts using both CPU cores (up to %170 percent of my
machine) just spinning away, causing the fans to blow.   Nothing shows
up in the logs.

I'll test further, but so far still not working for me.

-Dave Fogel

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

RE: Basic auth and accents in passwords

[webpost]

ok, perfect !

thanks again.

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

Re: HTTPS / SSL not working after updating to trunk

[Bruno Harbulot]

Hi David,

David Fogel wrote:
> Hi Bruno, Jerome-
> 
> Thanks for taking a look at this!  I've just updated to the latest in
> trunk (SVN revision 6407).
> 
> Unfortunately, the fix doesn't seem to be working- in fact now what
> I'm seeing is that the connection is never made from the client, but
> now my server starts using both CPU cores (up to %170 percent of my
> machine) just spinning away, causing the fans to blow.   Nothing shows
> up in the logs.
> 
> I'll test further, but so far still not working for me.

Could you try with another connector, just in case (Jetty or Grizzly)? I 
had noticed a connection problem (once) when writing the patch this 
morning and testing it at the same time with the Simple connector, but I 
haven't had the problem since. (I'll try again on another machine.)


Best wishes,

Bruno.

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

Multiple cookie bug (2.0RC1 and snapshot)

[Rob Heittman]

Hi all,

I haven't explored it in sufficient detail yet to have a patch, but
request.getCookies() is returning only the first cookie sent by the browser,
I think since some of the engine refactoring in early March may have to do
with it?  I think it was OK before then.

A quick step thru seems to indicate that CookieReader gets the first pair,
caches the second pair, but never gets visited again to actually read pairs
2..n

- Rob

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

RE: Re: Suspended thread doing Client.put

[Jerome Louvel]

Hi David,

The connector does work for some requests. Actually, it passes quite a bunch
of unit tests :) 

However, it is possible that the null entity generates a side-effect. We'll
investigate.

BTW, we have just fixed in SVN trunk and issue that would cause requests to
be pipelined all the time. By default, HTTP pipelining is turned off
however. Try again with SVN trunk, the fix might help as well.

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




-Message d'origine-
De : David Fogel [mailto:carrotsa...@gmail.com] 
Envoyé : mercredi 24 mars 2010 20:33
À : discuss@restlet.tigris.org
Objet : Re: Re: Suspended thread doing Client.put

Hi all-

We've updated to the restlet trunk last night, but not successfully-
some or all (hard to tell yet) of our Client requests are hanging with
the thread getting suspended during the latch.await() call in
BaseClientHelper.handle().

(Our project is a web-app that uses openid for federated sign-in, so
on sign-in the user's browser is eventually redirected back to us with
a token, and we make a POST call to the openid provider using a
ClientResource, in order to verify the sign-in etc.  Since our client
POST call never returns, we're not able to sign in to our web app,
which is why we haven't yet concluded whether all the other places
we're using the client connector are also broken or not.)

The only thing we're doing that's even slightly unusual is that we're
calling clientResource.post(null), since we don't need to post an
entity body (all the params are in the URI).  We haven't tried
changing this- figured it was important to send this issue in asap,
but we'll be trying different things this afternoon.

So, is it the case that the built-in Client connector is broken in
RC1?  Or does it work for some requests and not others?

Incidentally, this was a bit of a pain in the butt to track down,
since all we could tell was that somewhere our thread was just
hanging.  debugging restlet apps is not too fun to begin with, due to
the deep stacks filled with filter handle/doHandle calls and in
general all the layers of Helpers and deep inheritance trees of all
the restlet classes etc.  I'm sure much of that is unavoidable, so
this isn't really a complaint, but we'd be interested in hearing how
other people typically debug their restlet apps- maybe there should be
some docs about that too :-)

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

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

Re: Multiple cookie bug (2.0RC1 and snapshot)

[Thierry Boileau]

Hello Rob,

thanks for your report, I've entered an issue for that: 
http://restlet.tigris.org/issues/show_bug.cgi?id=1068

Best regards,
Thierry Boileau

> Hi all,
>
> I haven't explored it in sufficient detail yet to have a patch, but 
> request.getCookies() is returning only the first cookie sent by the 
> browser, I think since some of the engine refactoring in early March 
> may have to do with it?  I think it was OK before then.
>
> A quick step thru seems to indicate that CookieReader gets the first 
> pair, caches the second pair, but never gets visited again to actually 
> read pairs 2..n
>
> - Rob
>
>

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

Re: HTTPS / SSL not working after updating to trunk

[David Fogel]

I'll try Jetty to see if it works, although I'd prefer in the long
term to use Simple.  the only thing is that this is a bit more
burdensome to try for our environment, because we have an OSGi-based
stack, and I have to rebuild any new extension with a new manifest
entry to make it a bundle fragment instead of a bundle (which is how
we deploy restlet extensions, which strategy I've suggested before).

-Dave

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

Re: Re: Suspended thread doing Client.put

[David Fogel]

Hi Jerome-

I did try a number of variations:

// My original code:
ClientResource res = new ClientResource(Method.POST, uri);
Representation entity = res.post(null);

// with an empty Representation:
ClientResource res = new ClientResource(Method.POST, uri);
Representation entity = res.post(new EmptyRepresentation());

// with an empty Form representation:
ClientResource res = new ClientResource(Method.POST, uri);
Representation entity = res.post(new Form().getWebRepresentation();

none of which worked.  I'll try the updates in SVN soon.

-Dave

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

RE: ObjectRepresentation with an Object embedding a negative int value

[Thierry Boileau]

Hello Xavier,

I've just tried with the jse edition and the gwt edition. It just works. Could 
you precise your context?

Best regards,
Thierry  Boileau

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

RE: How serialize Object list or array

[Thierry Boileau]

Hello Matthieu,

I've just fixed the GWT edition, there was a bug avoiding to correctly handle 
arrays.

Could you try tomorrow with the future snapshot 
(http://www.restlet.org/downloads/)?



Best regards,
Thierry Boileau

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

Re: HTTPS / SSL not working after updating to trunk

[David Fogel]

Hi Bruno-

So, I got Jetty working as the connector, and yes, it does seem to
work fine with our previously discussed HTTPS configuration.  So that
can hold us for now, but we do eventually want to use the Simple
connector.

Incidentally, based on recent postings to the simpleframework support
list, it appears that Niall (the author of Simple) plans to release a
bug-fix version in the next few days for some problem having to do
with a potential endless loop writing to a socket.  So I wonder if
this could be part of the issue...

-Dave

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

Re: HTTPS / SSL not working after updating to trunk

[Bruno Harbulot]

To give you a bit more details, just in case you manage to see a bit 
more what's happening on your side, the patch that was put in the trunk 
today (r6407) was clearly due to the fact I had omitted a very important 
line: the one that passes the parameters to the factory:
   if (result == null) {
   result = new DefaultSslContextFactory();
+result.init(helper.getHelpedParameters());
   }


Once that was fixed, the SSLContexts appear to be initialised as 
expected (I've even run this with the debugger within Eclipse).


The other patch that affected the SSLContext was r6391. It was 
essentially moving the code duplicated in the DefaultSslContextFactory 
and in the default connectors into the DefaultSslContextFactory anyway:


@@ -267,37 +269,7 @@ public class HttpsServerHelper extends 
SimpleServerHelper {
  // Initialize the SSL context
  final SslContextFactory sslContextFactory = SslUtils
  .getSslContextFactory(this);
-SSLContext sslContext;
-/*
- * If an SslContextFactory has been set up, its settings take 
priority
- * over the other parameters (which are otherwise used to build and
- * initialize an SSLContext).
- */
-if (sslContextFactory == null) {
-final KeyStore keyStore = 
KeyStore.getInstance(getKeystoreType());
-final FileInputStream fis = getKeystorePath() == null ? null
-: new FileInputStream(getKeystorePath());
-final char[] password = getKeystorePassword() == null ? null
-: getKeystorePassword().toCharArray();
-keyStore.load(fis, password);
-if (fis != null) {
-fis.close();
-}
-
-final KeyManagerFactory keyManagerFactory = KeyManagerFactory
-.getInstance(getCertAlgorithm());
-keyManagerFactory.init(keyStore, 
getKeyPassword().toCharArray());
-
-final TrustManagerFactory trustManagerFactory = 
TrustManagerFactory
-.getInstance(getCertAlgorithm());
-trustManagerFactory.init(keyStore);
-
-sslContext = SSLContext.getInstance(getSslProtocol());
-sslContext.init(keyManagerFactory.getKeyManagers(),
-trustManagerFactory.getTrustManagers(), null);
-} else {
-sslContext = sslContextFactory.createSslContext();
-}
+SSLContext sslContext = sslContextFactory.createSslContext();


Considering that the SslContextFactory seems to behave as expected, I'm 
not quite sure the problem comes from there.



While I wasn't noticing the problem on my Linux box, I'm noticing a 
similar problem on my Mac: the connection just hangs when connecting to 
my test app when using the Simple connector (not with Jetty/Grizzly).


I think the only difference then, from the previous code, is that the 
previous code used to initialise the trustmanager with the same keystore 
as the keymanager.

In fact, this solves the problem, partly. If I use the same settings for 
the trust manager in this test app, it now works on my Mac:

params.add("truststorePath", "...");
params.add("truststorePassword", "testtest");


This shouldn't be required. I've had a brief look at the SimpleFramework 
code itself, but I can't spot anything obvious.


If you could try to set the truststore like your keystore, perhaps it 
would fix your problem in the short term.


Best wishes,

Bruno.


On 25/03/2010 18:44, David Fogel wrote:
> I'll try Jetty to see if it works, although I'd prefer in the long
> term to use Simple.  the only thing is that this is a bit more
> burdensome to try for our environment, because we have an OSGi-based
> stack, and I have to rebuild any new extension with a new manifest
> entry to make it a bundle fragment instead of a bundle (which is how
> we deploy restlet extensions, which strategy I've suggested before).
>
> -Dave
>
> --
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2465073
>

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