.
Hmm, that doesn't seem to be the case for me, since my code is almost an exact
copy the parent class.
--tim
On Sat, Apr 27, 2013 at 6:03 PM, Grant gsingers at apache dot org wrote:
I don't understand what you mean by the handling of the {rr} template.
The approach I suggested
On Sun, Apr 28, 2013 at 11:42 AM, Grant gsingers at apache dot org wrote:
I haven't dug into this code, but I suspect you aren't manipulating
References properly. I advise printing out the intermediate steps of your
Reference computation to see where it goes wrong.
That's just
derivation of Redirector) that has an attach point of
http://foo:port/a and a target template of {rr} whereas before in my static
redirector I was doing http://bar:port/{rr} and everything was good.
Thanks,
Grant
--
http://restlet.tigris.org/ds
I don't understand what you mean by the handling of the {rr} template.
The approach I suggested, overriding getTargetRef, ignores the template
argument entirely.
In my old code, I had:
URI = hardcoded URI to resource
Redirector redir = new Redirector(router.getContext(), URI + {rr},
(in createInboundRoot)
and I want to be able to dynamically set the host/port of the backend service
at request time, as it is possible the service may be down or I want to load
balance it.
I'm on Restlet 2.1.5-RC1.
Thanks,
Grant
--
http
That works beautifully, thank you!
For the record, I used what was in getTargetRef almost as is, except I replaced
the baseRef with a dynamically discovered one (that I get from Zookeeper).
Thanks,
Grant
--
http://restlet.tigris.org/ds
Same here.
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2969813
Anyone else have any thoughts on this?
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2969818
one,
release it and then create it a second time?
Thanks,
Grant
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2964082
I haven't been able to reliably reproduce it yet. Seems to happen more on
slower machines. Sometimes I see underlying log messages that indicate
problems, but nothing consistent. I'm headed up against a release and
switching to HTTPClient fixed the issue (it's been running regularly for a
Netty was dropped in 2.1)
Thanks,
Grant
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2950791
Can you share your definition of Patient?
What errors are you getting that make you need to separate things out?
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2950808
I'm on 2.1-RC3 and seeing some weirdness that I can't explain. I've setup
roles for my various endpoints and hooked them in via the RoleAuthorizer. I've
got an enroler that adds the users roles into the ClientInfo much like the
Security example. However, when I make a request to the system,
I figured this out. The problem was due to the fact that I was getting the
Role instances from another Restlet Resource, so they were just proxy instances
and not actual Role instances. To fix it, I instantiated real Role objects
from the proxies I got back from the other service.
If I swap out Netty with Jetty, all works fine. Attached is a sample
demonstrating this (netty.tar). One possible cause is I am using a newer
version of Netty, but I'm not convinced of that, as I still wonder if the
Netty implementation is not handling chunking correctly.
If you swap
Any thoughts on this?
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2931501
Hello Grant,
I'm not sure I follow. The problem isn't that it doesn't send chunked
encoding. It's that it thinks all JSON messages are chunked due to the
JacksonRepresentation not setting the size value correctly.
Actually, using chunked encoding for representations is not a problem
That makes sense. Which then implies there is some type of bug here, as it
never finishes and returns because the client is being told there is a
chunked result, but it only gets one chunk (b/c the response in this case is
so small).
I'm likely doing something wrong, but it isn't
That makes sense. Which then implies there is some type of bug here, as it
never finishes and returns because the client is being told there is a
chunked result, but it only gets one chunk (b/c the response in this case
is so small).
I'm likely doing something wrong, but it isn't
Hello Grant,
the usage of the chunk encoding is perfectly normal and must be supported
by HTTP servers and clients (except GAE...). I guess this reveals a problem
with the Netty extension, which should correctly parameter the underlying
netty http server in such case.
I'm not sure I follow
.
Thanks,
Grant
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2924705
I'm pretty new to Restlet, but it strikes me that by the time the
JacksonRepresentation is ready to be constructed that we can know the size of
the object.
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2924717
If I put the workaround mentioned in
http://restlet.tigris.org/issues/show_bug.cgi?id=1219 into JacksonConverter in
the toRepresentation method, then things appear to work.
--
My attempted patch at this, which appears to work at first blush, is at
https://github.com/lucidimagination/restlet-framework-java/tree/2.0.11-patch
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2924788
); (see below)
It works (i.e. no error) but when stepping through the code I noticed
the following:
When retrieving the resource the client uses the XstreamConverter.
When storing the resource it uses the DefaultConverter. Is this the
expected behavior?
Regards,
Grant
public class
25 matches
Mail list logo
