Re: Restlet performance
On 2011-01-27 09.05, cristisor wrote: Hello everyone. I have to develop a web service that looks like this: I make a get call, including a string in the url, and I need to receive another string based on the initial string from the query. I might have to make this call even for a thousands times a minute. Do you think that the server will be able to handle so much HTTP communication? Is a RPC approach better? Try it and see what happens. Only way for you to know, given YOUR usecase. But in theory nothing should be stopping you from getting that to work. /Rickard -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2700900
Re: response.release() versus response.exhaust() in 2.0
On 2010-12-31 05.55, Tal Liron wrote:
pool.) It's probably best to employ a try-finally paradigm, where the
try clause contains as little code as possible, and the finally clause
releases the response. See the example below.
var fixture
var resource =
document.external('file:///myfiles/fixture.json','application/json')
try {
fixture = resource.get().text
}
finally {
resource.response.release()
}
So this, combined with Jerome's reply:
1) release() has the effect of closing the underlying TCP
socket, preventing persistent connection reuse. So it can't be
recommended to systematically call it.
basically means that we can't have persistent connection reuse on the
client. Correct or not?
/Rickard
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2695100
Reuse of Responses for long-running requests?
Hi,
I've made a ServerResource which is supposed to return a long-running
response that serves log messages from log4j. It looks something like this:
public class LoggingServerResource
extends ServerResource
{
@Override
protected Representation get() throws ResourceException
{
return new WriterRepresentation( MediaType.TEXT_PLAIN)
{
@Override
public void write( final Writer writer ) throws IOException
{
writer.flush();
final Form params =
getRequest().getResourceRef().getQueryAsForm();
final Logger logger = Logger.getRootLogger();
AppenderSkeleton appender = new LoggingAppender( params,
writer, logger );
appender.setLayout( new PatternLayout([%X{url}] %-5p %c{1}
: %m%n) );
logger.addAppender( appender );
synchronized (appender)
{
try
{
appender.wait();
} catch (InterruptedException e)
{
}
}
}
};
}
private class LoggingAppender extends AppenderSkeleton
{
... impl omitted for brevity ...
}
}
---
Basically it adds an appender to log4j which then writes to the Writer
as long as there's no IOException(=browser stopped connection). This
seemed to work well, but when we went into production it broke
spectacularly as it seems like the Response (or underlying
request/response) was reused for other requests. So in other calls there
would be sporadically included log messages.
The only way I can get this to make sense is that even though the
WriterRepresentation has technically not finished (i.e. write() has not
returned) the underlying streams were reused by other requests. We're
using Glassfish (which uses Tomcat), if that makes any difference.
Has anyone else seen this problem? How is it possible that a Response
being written to can be reused!? Any ideas?
/Rickard
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2694742
Re: response.release() versus response.exhaust() in 2.0
On 2010-12-30 07.34, Jerome Louvel wrote: Hi Marc, I don't know if you still experiment issues with this, but here are a couple of clarifications: 1) release() has the effect of closing the underlying TCP socket, preventing persistent connection reuse. So it can't be recommended to systematically call it. 2) exhaust() does ensure a proper consumption of the entity and enable reuse of the connection. If you don't systematically consume the entity via other means (actually reading it), then calling exhaust() is the way to go. Is there any difference between best practices of how a client vs a server should handle this? Right now we have our clients do response.release() in a finally block. Does your response imply that this messes up persistent connections from the clients point of view? /Rickard -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2694744
Re: ClientInfo.getPreferredMediaType and Internet Explorer
On 2010-12-02 17.07, Jerome Louvel wrote:
Hi Rickard,
This was indeed a bug. It is now fixed in SVN 2.0 branch and trunk.
Thanks for the report.
Goodie, thanks!
Regarding the TunnelService, it can automatically replace the
Accept header sent by broken clients with a more sensible one,
based in the UserAgent header value. See the TunnelService Javadocs
for more details.
Ok, then I understand, thanks.
Could you elaborate a bit more on what is lacking in ServerResource
from your point of view? We have plans to support HATEOS more
automatically in 2.2 so this might help. Any pointer to your
suggested approach (UseCases?).
Basically it comes down to very fundamental issues with what people tend
expose as their REST API (domain model=VERY BAD IDEA!), and the problems
that come from that, and what to do instead. And once you start
realizing that HATEOAS is superimportant, and only really works if you
expose usecases instead, and that it should be as native as possible in
code, that also changes things.
What we have done is to do sort of a custom router mechanism. Let's say
we have the following URL:
/account/changepassword
In my current code this is handled by first having a root resource that
represents / with:
public class RootResource
extends CommandQueryResource
{
@SubResource
public void account()
{
subResource( AccountResource.class );
}
... more subresources ...
}
So a Restlet will instantiate RootResource and call handle() on it,
which through reflect will find account and call that, which
instantiates AccountResource, which looks like this:
public class AccountResource
extends CommandQueryResource
{
public AccountResource( )
{
super( AccountContext.class );
}
... more subresources to /account/ ...
}
/account/ represents a usecase, and now changepassword is one of the
interactions in this usecase. The AccountContext finally contains the
actual code for the usecase (the *Resource is on the REST level, not the
usecase level):
public class AccountContext
{
@Structure
Module module;
public void changepassword( ChangePasswordCommand newPassword )
throws WrongPasswordException
{
UserAuthentication user = RoleMap.role( UserAuthentication.class );
user.changePassword( newPassword.oldPassword().get(), newPassword
.newPassword().get() );
}
}
Where ChangePasswordCommand is a value object that will be
created+filled in with form data (either POST'ed or from request query
parameters). If I do GET on /account/changepassword I get a form with
the required fields (oldPassword, newPassword).
And that's all. Now I don't have to bother with much RESTy stuff in my
usecase code, and yet I get my REST API constructed more or less
automatically.
Additionally, a core requirement in REST is that the client has to find
it's way to this URL by following links. Given the above code my
framework can automatically generate HTML/JSON with links for every path
that ends with /. So from / you would get HTML that includes:
a href=account/ rel=accountAccount/a
and from /account/ you would get HTML that includes:
a href=changepassword rel=changepassword
classes=commandchangepassword/a
With this the client can find the URL without having to know the URL
structure, only rel attributes, which is how it should be. This allow me
to restructure the API without having to change clients interpretation
of paths and whatnot, which is a key point of HATEOAS.
So this is how we write our application code, with Restlet handling all
the RESTy details of parsing requests and generating responses. Which is
perfect!
With this as background, ServerResource is (IMO) simply too low-level,
and exposes things that for most application API's should not be
bothered with. I still use it for other parts of my API, but not the
core application-level part.
For more details see:
http://www.jroller.com/rickard/entry/rest_api_for_infrastructure_domain
http://www.jroller.com/rickard/entry/rest_and_the_missing_link
/Rickard
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2687242
Re: ClientInfo.getPreferredMediaType and Internet Explorer
On 2010-12-02 04.03, Thierry Boileau wrote: the current algorithm implemented in ConnegUtils#getPreferredMetadata was a bit restrictive. It checked the presence of the preference (in this case */*) inside the given list of supported metadatas. Having said that, I'm quite confused. I'm not sure it will fit your need, because it returns a metadata taken from the list of preferences (in your case */*), not from the supported ones, which seems in contradiction with the javadocs... It needs to return a MediaType from the supported list, not the accepted ones (which could be generic, i.e. */*). /Rickard -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2687160
ClientInfo.getPreferredMediaType and Internet Explorer
Hi, If I use Internet Explorer to make requests to a Restlet application, and then use ClientInfo.getPreferredMediaType(supportedMediaTypes), then it will return null as IE sends */* as accepted media type, but this is not handled properly by getPreferredMediaType. Is this a known bug? Or what is the appropriate way to figure out what mediatype to return, and which handles */* on the accepting side, properly? /Rickard -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2686676
Re: ClientInfo.getPreferredMediaType and Internet Explorer
On 2010-12-01 05.23, Fabian Mandelbaum wrote: IE is not very helpful with its accept anything, a.k.a */* default Accept header. Since you are getting */* it's a-priori appropriate to send *anything* as the response, IE clearly states that it's willing to accept anything you throw back at it with the */* idiom. snip We have found writing ServerResources to be a bad way to present our REST API, so that's not an option. We really just want ClientInfo.getPreferredMediaType() to work as expected, i.e. if it has */* in accepted media types, then it should match the first supported media type, which it doesn't do today. Now I have to do a null check on return value, check if accepted types contain */* and then get the first supported media type, manually. You can even return a more specifc Representation object (JsonRepresentation, DomRepresentation, etc.) or even a POJO and rely on Restlet's automagic converter service to make the needed object conversion for you. As above, I don't use any of that stuff. ServerResources and annotations is way too low-level for writing REST API's (especially when you throw in HATEOAS in the mix), in my experience. We have a better way to do it based on UseCases, in a small library on top of Restlet and Qi4j. We just want Restlet to handle the nitty-gritty of receiving/sending requests/responses (which it is great at, btw!). Of course, all this works with proper Accept headers, so you may also need to have your client request with proper Accept values. If your client is an AJAX one, I'm sure most (if not all) JavaScript AJAX frameworks do have a means to specify proper HTTP headers (in this case: Accept: application/json, for example to get a JSON representation) for your requests. This is mainly used when IE is the client, directly to our REST API, e.g. when developers are discovering what our REST API can do or when we are manually testing interactions through a browser. Ouf... my answer was a bit long (sorry), I've tried to cover all aspects. Mmm... but it seems also like you don't agree that the current getPreferredMediaType() is broken? Why is what I'm expecting from it (*/* in accepted mediatypes should match my first supported mediatype) reasonable? /Rickard -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2686861
Re: ClientInfo.getPreferredMediaType and Internet Explorer
On 2010-12-01 05.25, Fabian Mandelbaum wrote:
Oh, one more I forgot:
Setup the tunnel service on your Application class for IE, like this
for example:
public class YourApplication extends Application {
public YourApplication() {
getTunnelService().setUserAgentTunnel(true); // To handle IE requests
properly
}
}
What does it do, and how does it help my problem?
To give you some sense of what I have to do to get around this, whenever
I ask for ClientInfo.getPreferredMediaType() I have to do this:
MediaType responseType = request.getClientInfo().getPreferredMediaType(
possibleMediaTypes );
if (responseType == null
request.getClientInfo().getPreferredMediaType(
Collections.singletonList( MediaType.ALL)) == MediaType.ALL)
{
responseType = possibleMediaTypes.get( 0 );
}
---
Wouldn't it be better if the method did something similar (or better) on
its own? And wouldn't that be in line with expected results from such a
method?
/Rickard
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2686866
Re: Different operations (post) on same resource design
On 2010-11-16 17.45, Tim Peierls wrote: What's wrong with proliferation of resources? Changing a password and exporting to a database sound like two very different things; wouldn't you *want* to expose them as different resources? I agree, that's how I do it. A GET on /contacts/id/changePassword would return a form with the fields to fill in for the command, and a POST executes it. Same thing with exportToSap: a GET would return a form with the possible export options, and a POST performs it (or I would do it using GET actually, since it's a query). This also makes authorization easier, if you want to differentiate who is allowed to perform different operations on the same contact. /Rickard -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2682392
Re: Problems with hanging client calls
On 2010-08-26 22.20, Jerome Louvel wrote: Hi Rickard, Yes, we will definitely fix this issue. Thierry will likely look at it tomorrow. Using other connectors is just a workaround. This internal connector has increasing importance for our users so we are working hard on improving it at each release. FYI, we are working in the Restlet Incubator on an enhanced internal connector fully leveraging non-blocking NIO to reduce thread usage and increase scalability/throughput. Initial benchmarks for simple cases show results close to Jetty (even slightly better). It will be part of version 2.1. See this wiki page for details: NIO connectors http://wiki.restlet.org/developers/172-restlet/354-restlet.html That's excellent news! Thanks for the update on that. regards, Rickard -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2652020
Re: Problems with hanging client calls
On 2010-08-24 21.13, Thierry Boileau wrote: Hello Rickard, to my mind, this should be fixed by using the httpclient connector (or net also). Adding a connector to your application is explained here: http://wiki.restlet.org/docs_2.0/13-restlet/27-restlet/325-restlet/37-restlet.html Thanks, we will look into that. But shouldn't the default one work properly? Are you looking into fixing this as well? regards, Rickard -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2650942
Re: Problems with hanging client calls
On 2010-08-20 13.31, Freya Impens wrote: We had the same issue when upgrading to restlet 2.0.0. Some links about the (I think) same issue: http://restlet.tigris.org/issues/show_bug.cgi?id=1053 andhttp://comments.gmane.org/gmane.comp.java.restlet/12273 It all boils down to calling the exhaust() method on the response representation (in a finally-block), which solves the problem. For some reason calling the release() method is not enough, and this 'exhaust' solves the problem. We asked a similar question on the list some days ago. We tried adding exhaust calls, but still see hangs. Btw, it should be enough to either fully read using BioUtils.copy *or* exhaust(), right? Also, only on response, not request, correct? Are there any docs on how to switch to httpclient? I checked the current docs, and JavaDocs, but couldn't find any instructions on how to actually use it. thanks, Rickard -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2650329
Re: Problems with hanging client calls
On 2010-08-20 14.25, Thierry Boileau wrote: Hello Rickard, did you try with another client connector such as net or httpclient? Do you notice the same behaviour? I have a look at the error handling. I couldn't figure out how to use them. The docs I found were minimal. Got link? thanks, Rickard -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2649251
Re: Problems with hanging client calls
On 2010-08-20 15.31, Thierry Boileau wrote: I wonder if, in your case, the final server (not the proxy) is unable to send a response, because of the closed socket error (on server side). If so, the internal client connector will wait on the read operation. As there is no timeout on this internal client connector for the moment (it is planned to fix it for the 2.0 branch see http://restlet.tigris.org/issues/show_bug.cgi?id=304), it will block. This should not happen with the other client connectors. That seems to be part of it. We found that a socket error lead to a branch of the code that never does unblock, and so the hang was unsurprising. We also just now found that the end server was doing Transfer encoding: chunked, which might cause problems. We'll try to remove that as well (no idea why it is doing so in the first place). BaseClientHelper code (because the catch code doesn't do unblock) Do you refer to the BaseClientHelper#handle(Request, Response) method? Yes. thanks, Rickard -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2649252
Re: Restlet and OSGi: not a good combination
On 2010-06-04 00.40, Jerome Louvel wrote: Hi Rickard, Good point, I've updated the ServletAdapter class as well. The clean-up is done just before leaving the service(HttpServletRequest, HttpServletResponse) method. Ok, good. Is there any particular reason the cleanup is not done properly? My rule of thumb is that whenever there's a setting of a threadlocal you put a try/finally *in the same place* and do the cleanup, so there's no way for references to be left hanging. /Rickard -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2616670
Re: Restlet and OSGi: not a good combination
On 2010-06-02 19.23, Jerome Louvel wrote: Ok, that was easier than expected. This bug has just been fixed in SVN trunk. There is now a Engine#clearThreadLocalVariables() static method use by server connectors and the task service that centralizes the logic. So will this be used after each request? In my case, I have a servlet fronting my Restlet application, and which delegates to a Restlet using a ServletAdapter. If the logic is in the connector, this will not be used and so I have to do this manually, right? Or will you build it into the adapter? /Rickard -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2616214
Restlet and OSGi: not a good combination
Hi, I've been developing an application that uses Restlet, and recently converted it over to OSGi. I soon found that on reloads the OSGi container would leak the classloader for uninstalled bundles. In tracking down all the sources for this leak I found one major contributor to be Restlet, and more specifically, the threadlocals in Context, Response and Application. These threadlocals are set on requests, but are never cleared. So when these threadlocals point to bundle-classes, such as the Application, it leads to leaks. Now that I found it I've managed to get around it by clearing these three threadlocals when the request finishes, and additionally when my activator stops. Is there a reason why these threadlocals are not cleaned up properly? Are there any additional threadlocals other than the above I need to know about? Is noone else running into these issues? It should be similar issues when using Restlet in WAR files of webcontainers, right!? regards, Rickard -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2615446
Re: Restlet Framework 2.0 RC1 released
On 2010-03-15 23.48, Jerome Louvel wrote: Hi all, The first 2.0 release candidate is finally ready. Please help us with bugs reports, patches and wiki contributions, to ship a rock solid 2.0.0 version! http://blog.noelios.com/2010/03/15/restlet-framework-2-0-rc1-released/ Excellent work! Ever since I got into using Restlet, it just feels a whole lot better than servlets. Things just fit. I'm working on a new web framework on top of Restlet, and it allows me to focus on the architectural parts rather than the web details, which is so nice! Keep it up! cheers, Rickard -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2460382
Re: Only HTTP or HTTPS resource URIs are allowed here
On 2010-02-12 17.52, Thierry Boileau wrote: Hello Rickard, this may be due to the way you build the reference variable. Could you tell us a bit more about this? The reference is built by consecutively doing: Reference subReference = reference.clone().addSegment( pathSegment ).addSegment( ); I start with the root of the app, and then as the client traverse down it creates new sub-references by using the above code. So, whenever I look at a particular reference it shows that it is only the last segment. Funny thing is that the same thing works if I do client.get(). It's only client.delete() that crashes with the exception. So somehow how it extracts the URL and sends it to the HttpConnector seems to be different between the two. /Rickard -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2447030
Re: Only HTTP or HTTPS resource URIs are allowed here
On 2010-02-12 17.57, Rickard Öberg wrote: Funny thing is that the same thing works if I do client.get(). It's only client.delete() that crashes with the exception. So somehow how it extracts the URL and sends it to the HttpConnector seems to be different between the two. Scratch that: I actually get the same error with client.get(). /Rickard -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2447039
Re: Only HTTP or HTTPS resource URIs are allowed here
On 2010-02-12 18.46, Thierry Boileau wrote: Hi Rickard, from what I notice, this error can happen only in the context of a GWT application. But, in this case, the clone method is not available. What version of Restlet are you using? What are the packages of the Reference and ClientResource classes? We are using a Restlet-2.0-SNAPSHOT from 2009-10-06, and the packageas are org.restlet.data.Reference and org.restlet.resource.ClientResource. /Rickard -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2447043
Only HTTP or HTTPS resource URIs are allowed here
Hi, When I use the restlet client to delete() a URL that is perfectly valid, I get the following error message: Only HTTP or HTTPS resource URIs are allowed here Here's the URL: http://localhost:8040/streamflow/streamflow/v1/organizations/9720ef9d-ceb3-449d-9036-7a9ca9d301ce-2/users/testuser/ By doing some debugging and trialerror I fixed it by replacing: ClientResource client = new ClientResource(reference); with ClientResource client = new ClientResource( new Reference(reference.toUri()).toString( )); Apparently the first one sent in only a partial piece of the reference to the call, and by explicitly making the reference absolute that worked. But it feels icky. Is this how it's supposed to work? /Rickard ps. I'm working with a snapshot of Restlet 2.0 from October last year, so it might have been fixed after that. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2447003
Persistent connections
Hi, How do I enable persistent connections using Restlet? I've checked the code, and I can't seem to find how to do it. /Rickard -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2412383
Re: Trouble with ServerServlet
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
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
Trouble with ServerServlet
Hi, I'm having some trouble with ServerServlet, and am a bit stuck. What I've done is to subclass ServerServlet and override the createApplication() method to create and return my own subclass of Application. Then, in start() I create and initialize my whole internal application setup. When the Tomcat container starts upp I can see that start() is being called properly. So far so good. But, when I redeploy the application stop() is not always called on the Application (only sometimes!), and so my app is not properly shutdown, which then causes problems when the next version is started. 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? Is there something else I'm missing? Is it a bug in my code or Restlet? Should I implement my own Component instead of Application? thanks, Rickard -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2409718
Re: PROBLEM WITH org.restlet.representation.InputRepresentation IN 1.2-M2
On 2009-10-06 20.15, Thierry Boileau wrote: do you still have the issue regarding the date of the snapshot? It seems to be ok now, thanks! /Rickard -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2404430
ClientInfo.getSubject() is gone
Hi, It seems the ClientInfo.getSubject() method is gone. I was using that to populate the Subject from within my Verifier. What has happened to it, and has it been replaced with something else that I can use? Preferably something returning Subject... /Rickard -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2404446
Re: ClientInfo.getSubject() is gone
On 2009-10-07 18.22, Jerome Louvel wrote: Let me know if you have troubles refactoring your code base on the above changes. Most of it was replaceable, although it was some work to do it. Previously I just had a Verifier and then my resource would get the Subject and do Subject.doAs() before calling application code. Now I had to add an Enroler to translate the User to Principals, and then manually take those Principals in my resources and create a Subject. And since there's no Principal implementation I had to make my own. And previously I also could add more login credentials to the subject in the Verifier, but that is not possible anymore. So, now my code sort of works again, but from my perspective this was a step back, not forward. /Rickard -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2404457
Re: ClientInfo.getSubject() is gone
On 2009-10-07 20.06, Jerome Louvel wrote: Thanks for the feed-back. There are still principal implementations but they were moved to the org.restlet.ext.jaas extension. In your case, is it really necessary to use principals and subject? Couldn't you just leverage Restlet Enroler, User and Role classes, with the ServerResource#isUserInRole() method instead of the Subject.doAs()? Well, the thing is that the Restlet resources are only a frontend to the application layer/domain layer, and in those layers there should be no references to Restlet, or any other UI-layer code. So, Subject worked perfectly, and has the added benefit of being alwas easily available as it is a threadlocal. ServerResource#isUserInRole() doesn't work at all for those purposes. OTOH, I would also like to provide a way to wrap the User and Role instances into a Subject in the JAAS extension. I'm thinking about a ClientSubject class extending Subject and taking a ClientInfo parameter. From this parameter, it would populate the principals set with instances of UserPrincipal and RolePrincipal based on the ClientInfo#user and roles properties. Why not just populate a regular Subject? I don't see the need for making a subclass that behaves exactly the same, apart from how it is constructed. In general, the use of classes and subclassing instead of interfaces for the Restlet API is very annoying. For me I would have much preferred if things like Verifier and Enroler and so on were interfaces. I don't understand why these things which seems like perfect candidates for interfaces are implemented as abstract classes. But, that's another discussion. /Rickard -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2404485
Re: ClientInfo.getSubject() is gone
On 2009-10-07 21.10, Jerome Louvel wrote: I understand your concerns about the Restlet API dependency in other layers. I've just added a JaasUtils class with a createSubject(ClientInfo) static method per your suggestion. It will populate the Subject (which is a final class anyway) with UserPrincipal and RolePrincipal instances as before. Excellent! I've also changed Enroler and Verifier to interfaces as they were abstract only contain a single method and are not expected to evolve in future API versions. We had several discussions in this list previously regarding the choice of favoring classes over interfaces in general. As a result, we even added this task: Reconsider usage of interfaces http://restlet.tigris.org/issues/show_bug.cgi?id=384 Excellent! Nice to hear! BTW, all changes mentioned are in SVN trunk. The JaasUtils class is attached for convenience. Thanks for that! Much appreciated. regards, Rickard -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2404512
Re: PROBLEM WITH org.restlet.representation.InputRepresentation IN 1.2-M2
On 2009-09-30 16.38, Jerome Louvel wrote: Hi Rickard, The public Maven repository is updated twice a month (1st and 15th). You should get it tomorrow: http://www.restlet.org/downloads/maven There seems to be a new snapshot out (090930), but something seems wrong with your Maven publishing, since 2.0-SNAPSHOT still points to 090907! So I suppose I have to hardcode our dependencies to the dated snapshot to get the latest one. Is that really how you want it to work, or is there something wrong? /Rickard -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2402746
Re: 2.0snap GWT getEntity().getText() works again
weltermann17 wrote: I could see that in M5 a check for Editon equals GWT was added and already thought that this would be a temporary fix only as it breaks the contract for InputRepresentation.getStream(). Reading the docs for getStream and isTransient makes it quite clear why a call to getStream().available() to check is something was received breaks the whole stream-handling. If you want I can try to find out where it's called once too often in the current trunk in order to switch back to the indented behaviour on GWT also. Sorry for not fully understanding this issue, but could this also be related to my problems with getRequest().getEntityAsText() returns null on the serverside? I posted about this issue some time ago, and Jerome said it was fixed in Restlet-2.0-SNAPSHOT, which we are now using. But yesterday I saw it again in the logs! We never get this issue on our local dev computers, but get it all the time on our EC2 test instance, so if it is related to available() returning false due to slow connection, that sounds reasonable. Is that a possibility? If not, we are going to try Jetty instead of Tomcat as the container and see if that helps. /Rickard -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2401841
Re: PROBLEM WITH org.restlet.representation.InputRepresentation IN 1.2-M2
On 2009-09-24 22.43, Jerome Louvel wrote: After further investigation, the fix related to annotated methods wasn't enough. There was indeed an issue as you initially reported with the Representation#finalize() method. I was finally able to reproduce it consistently, forcing the GC to run and to fix it by removing the finalize() method. It means that developers won't be able to rely on the GC to ultimately release pending connection which isn't a safe bet anyway. The fix is in SVN trunk and will be part of Restlet 2.0 M5. Ok, this is good news! I have debugged our getRequest().getEntityAsText()=null problem down to this bug. So if I get the latest Restlet-2.0-SNAPSHOT I should be able to get this fix then?? We're going live next week, so having this fixed is imperative! /Rickard -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2401866
Re: PROBLEM WITH org.restlet.representation.InputRepresentation IN 1.2-M2
On 2009-09-24 22.43, Jerome Louvel wrote: Hi Denys, After further investigation, the fix related to annotated methods wasn't enough. There was indeed an issue as you initially reported with the Representation#finalize() method. I was finally able to reproduce it consistently, forcing the GC to run and to fix it by removing the finalize() method. It means that developers won't be able to rely on the GC to ultimately release pending connection which isn't a safe bet anyway. The fix is in SVN trunk and will be part of Restlet 2.0 M5. I just saw that Maven Restlet-2.0-SNAPSHOT is not updated every day, so we are not guaranteed to get this fix ASAP. Is there any way you could force a new snapshot to be created? We are in desperate need of this fix :-( /Rickard -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2401867
Re: getText() still returns null with Tomcat
Jerome Louvel wrote: Hi Rickard, Good luck, the issue has just been fixed in SVN trunk (see recent mails in this list for details)! Regarding the Maven update, it is because the Group IDs have been changed to take into account the support for several editions. This needs to be better documented on the Web site... For example here is a recent POM: http://maven.restlet.org/org/restlet/jee/org.restlet.parent/2.0-SNAPSHOT/org .restlet.parent-2.0-20090907.130057-5350.pom Excellent! I will try the new ones and see if that helps. And yes, it has been confusing trying to figure out what POM's to use. Thanks so much for the pointer, that will help a lot! thanks, Rickard -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2400118
OSGi dependency, where to find?
Jerome Louvel wrote: Hi Rickard, Good luck, the issue has just been fixed in SVN trunk (see recent mails in this list for details)! Regarding the Maven update, it is because the Group IDs have been changed to take into account the support for several editions. This needs to be better documented on the Web site... For example here is a recent POM: http://maven.restlet.org/org/restlet/jee/org.restlet.parent/2.0-SNAPSHOT/org .restlet.parent-2.0-20090907.130057-5350.pom Ok, so I tried it, but it has a strange dependency to org.osgi:osgi_R4_core:jar:4.0, which I have no idea where to find. I've managed to find v1.0, but not 4.0. Which Maven repo can I get it from?? thanks, Rickard -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2400135
getText() still returns null with Tomcat
Hi, We are using Restlet 2.0-SNAPSHOT from the Maven repo (which doesn't seem to have been updated since June btw) along with Tomcat, and we seem to be running into the getText() returns null bug alot. I read the bug threads on Restlet (id: 843) and Tomcat (id: 42996) issue trackers, and from what I could understand the last conclusion was that it was a Restlet problem, and that it was fixed. But, we are still seeing it. In our case we are not using annotations at all (which was indicated as a culprit), just a plain ServerResource that does getEntityAsText(), which returns null every now and then, and especially when there are many users (10) using the server (which still is VERY low load comparatively speaking). Is there another bug involved, and which has to do with Tomcat? Or, is the 2.0-SNAPSHOT not updated with the fixes? Any ideas? /Rickard -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2399121
Re: How to authenticate to many websites seamlessly?
Jerome Louvel wrote: Hi Rickard, Now that 1.2 M2 is out, I can get to your email! I would suggest that you try out Restlet 1.2 M2 if you can. The ClientResource class allows you to set the next Restlet. If can be a Filter chain leading to the Context#clientDispatcher of your Application or leading to a Client instance. Then, you should develop a special Filter that would enrich the request with the correct credentials. You could even use a Router to handle this on a target URI basis! Thanks for the reply! Yes, I figured out on my own that that's what I wanted to do. I built a filter for it. However, your idea with Router might be even better way to do it! thanks, Rickard -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1527368
Re: Restlet 1.2 M2 released [throw previous email away]
Stephan Koops wrote:
Stephan Koops schrieb:
Jonathan Hall schrieb:
Shame you can't have @Get(MediaType.TEXT_HTML). I don't know.
Would it work to change MediaType from class to an enum? That could
work, but I'm not sure
While sending the email I remembered: You can't add new MediaTypes this
way, so we could forget my previous idea.
That depends on how you define the annotation. If it is
@interface Get
{
Enum value();
}
it is fine, since then you can use any enum. Which is better than any
string, since then you get the confusion of Should I use 'xml' 'XML'
'text/xml' or what?. With Enum as baseline you at least have to look at
what someone, somewhere, has defined.
/Rickard
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1527503
How to authenticate to many websites seamlessly?
Hi! I want to use the Restlet client in my app along with a notion of Accounts. This means that the user will set up Accounts with logins to a number of websites, and when the application does HTTP requests to those websites the login info should be used automatically. How do I set up Restlet to do this? One way seems to be to subclass Client and override handle(), and on each call check what host is being called, and then add auth info. Is there a better, cleaner way to do it? If so, how? /Rickard -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1360302
