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
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 =
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
{
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
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,
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
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
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
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
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
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
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,
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
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,
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
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?
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
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,
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!
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( );
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
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
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/
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
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
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
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
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
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
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
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
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
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,
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
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
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
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
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
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
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
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
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
42 matches
Mail list logo
