Re: 2.0snapshot Encoder.setMinimumSize broken
Hello,
sorry for being so unspecific. I use a SE component with Jetty, the client
is using the GWT edition. I tested with current versions of FF, Safari and
Chrome. If the issue occurs they all show one or two characters missing at
the end of a json string.
Maybe with this small test case it becomes reproducable:
public class Encoder extends org.restlet.engine.application.Encoder {
public Encoder(final Context context) {
super(context);
setMinimumSize(400);
}
@Override
public void afterHandle(final Request request, final Response response)
{
if (response.isEntityAvailable()) {
final Representation entity = response.getEntity();
try {
System.out.println(entity : +
entity.getText());
} catch (final IOException e) {
}
System.out.println(entity size : + entity.getSize());
}
super.afterHandle(request, response);
}
}
I test with a json rep that has a size of 317. The JsonRepresentation is
created from a String that is built from an LDAP response or is taken out of
a self-implemented cache directly.
On the console I see
entity :
{response:{status:0,startrow:0,totalRows:1,endrow:1,data:[{id:
... }]}}
entity size : 317
The string is a valid json.
In a SF client the web inspector reports:
Accept-Ranges:bytes
Cache-Control:max-age=3600
Content-Length:317
Content-Type:application/json; charset=UTF-8
Date:Tue, 15 Dec 2009 11:47:34 GMT
Expires:Tue, 15 Dec 2009 12:47:34 GMT
Server:Restlet-Framework/2.0snapshot
Vary:Accept-Charset, Accept-Encoding, Accept-Language, Accept
But the content ends with ] the final }} are missing. Hence, I receive
invalid data.
Firebug on FF 355 reports the same.
Changing the test code to setMinimalSize(300) I get the same correct console
output and the web inspector reports:
Accept-Ranges:bytes
Cache-Control:max-age=3600
Content-Encoding:gzip
Content-Type:application/json; charset=UTF-8
Date:Tue, 15 Dec 2009 11:53:01 GMT
Expires:Tue, 15 Dec 2009 12:53:01 GMT
Server:Restlet-Framework/2.0snapshot
Transfer-Encoding:Identity
Vary:Accept-Charset, Accept-Encoding, Accept-Language, Accept
The content is correct. It seems that piping a json rep through the encoder
without encoding may corrupt it.
Best regards,
Guido Schmidt
--
View this message in context:
http://n2.nabble.com/2-0snapshot-Encoder-setMinimumSize-broken-tp4162958p4169542.html
Sent from the Restlet Discuss mailing list archive at Nabble.com.
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2430513
GWT-RESTLET: API to check the current browser instance is already basic authencated.
Hello, I am using RESTLET-GWT client to talk to restlet backend using basic authentication. It's working fine. I am looking for an api in GWT-RESTLET client side to check if the current browser is already authenticated, based on the I would provide a custom-popup to the user to provide the credentials or take it to the logged in page. Is it available? Otherwise, is there some other way to achieve the same ? thanks...sanjib -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2430501
(Servlet context) How to dynamically add Applications to already initialized ServerServlet?
Hi,
I use Restlet in a servlet container, using the ServerServlet.
In the web.xml I have added the org.restlet.component param and set my
specific Component class.
When it comes to the applications for this component, I have to be able to
dynamically add and
remove applications.
But once the ServerServlet has been initialized (when the first request has
reached the servlet), adding
applications to the component's default host has no effect (the applications
can't be reached).
The reason (as far as I see) is in the ServerServlet.createServer() method:
When creating a new Server, the routes of the component's hosts are modified
and an offsetPath is added to the template patterns:
--
for (TemplateRoute route : component.getDefaultHost().getRoutes()) {
log([Restlet] Attaching restlet:
+ route.getNext() + to URI:
+ offsetPath
+ route.getTemplate().getPattern());
route.getTemplate().setPattern(
offsetPath + route.getTemplate().getPattern());
}
--
As a workaround I can add this path myself when subsequently adding new
applications to the component's host(s).
However, I wonder if the possibility to dynamically change the component's
applications might not be a useful feature in general.
Maybe the offsetPath could be stored in the component's host objects and used
when applications are added later.
Cheers,
Carsten
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2430478
web.xml context-params go missing
I have a Spring loaded RESTlet application using the 2.0M6 version. My ServerResources used to be able to obtain the context-params from the web.xml using the Context.getParameters() method, but that's no longer the case. Through my debugger, I can see that the parent of the parent of the getContext() method contains the parameters that I need. This grandparent Context is an instance of ComponentContext, whereas the others are ChildContext instances. How do I get access to those Parameters again? Thank you! Dustin -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2430610
TunnelService - additional tunnel for quirky browser accept headers
I wish to propose another tunnel which is a bit more practical in dealing with browser Accept header quirks. At present, browsers implement the accept header oddly. to quote Jon Blower's recent email to the list: Firefox 3: Accept header is text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8. Hence text/html is used, as expected. Chrome 0.2.149.30: Accept header is text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5. So Chrome prefers application/xml to text/html and hence gets an XML representation by default. Seems odd. IE7: Accept header does not include text/html, image/png or application/xml (!!) but does include */* (yuck) so IE gets the variant that happens to be first in the Resource's list. With the above code this just happens to be text/html. So conneg doesn't really happen here at all. The current way of dealing with this is to use the User Agent (ua) string and then 'fix-up' the accepted media. However, we have unknown browsers, or companies who change the ua string of known browsers, or future versions that change the ua string, different ua strings for different os, etc. This is hard to maintain and leaves us open to serving incorrect representations to our users. - which happens with chrome at the moment. An alternative I suggest would be to ignore the accept header and provide html unless the person sending the request has gone to lengths to send something specific. At lengths could mean where the accept header did not contain any mention of html or xhtml at all. Then they would be shown the representation they requested in the accept headers. This could be wrapped up in a tunnel like setUserAgentTunnel() and be off by default. It would be an 'either or' to have this or the User Agent Tunnel on. Any thoughts or opinions? Jon -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2430633
MIME Accept Type filter
Our Restlet resource server APPLICATION_JSON and APPLICATION_XML. A JQuery client, sets the Accept Type to */*, application/xml. So the Restlet negotiates that APPLICATION_JSON should be returned as expected. However, we want APPLICATION_XML to be served. The problem is that we are unable to remove the */* as the first Accept type in JQuery. JQuery seems to tack on the */* as an Accept Type to every request we send. Is there an elegant way in Restlet to filter the */* values, e.g. ALL or APPLICATION_ALL? We can certainly get the Accept Headers in Restlet and re-arrange the Accept list ourselves to override the Restlet negotiation. We are thinking of filtering, after Restlet negotiation, based on the User-Agent header for this particular JQuery client, so as not to break the Restlet behaviour for other clients (which is what we expect.) -- View this message in context: http://n2.nabble.com/MIME-Accept-Type-filter-tp4173789p4173789.html Sent from the Restlet Discuss mailing list archive at Nabble.com. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2430710
FirstStepsApplication as standalone java app doesnt work
Hey everybody, I tried the firstSteps-tutorial in both ways - in a servlet container and as a standalone Java application. Inside the servlet container everything works fine. The pure java application doesn't work.I downloaded the source at http://www.restlet.org/documentation/2.0/examples/firstSteps/sources.zip and didn't change anything. When running it I can see org.restlet.engine.http.StreamServerHelper start INFO: Starting the internal HTTP server on the terminal. Now when I try to visit http://localhost:8182/hello; all I get is a connection error. Has anyone an idea what the problem could be? Best regards -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2430704
Re: MIME Accept Type filter
Hello, One simple hack I use is to check for ajax requests using to the X-Requested-With header. That way I don't add for example the json representation. Hope it helps, Rémi On Wed, Dec 16, 2009 at 05:21, Andrzej Berico andy.glo...@bericotechnologies.com wrote: Our Restlet resource server APPLICATION_JSON and APPLICATION_XML. A JQuery client, sets the Accept Type to */*, application/xml. So the Restlet negotiates that APPLICATION_JSON should be returned as expected. However, we want APPLICATION_XML to be served. The problem is that we are unable to remove the */* as the first Accept type in JQuery. JQuery seems to tack on the */* as an Accept Type to every request we send. Is there an elegant way in Restlet to filter the */* values, e.g. ALL or APPLICATION_ALL? We can certainly get the Accept Headers in Restlet and re-arrange the Accept list ourselves to override the Restlet negotiation. We are thinking of filtering, after Restlet negotiation, based on the User-Agent header for this particular JQuery client, so as not to break the Restlet behaviour for other clients (which is what we expect.) -- View this message in context: http://n2.nabble.com/MIME-Accept-Type-filter-tp4173789p4173789.html Sent from the Restlet Discuss mailing list archive at Nabble.com. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2430710 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2430731
Re: Object exchange between Android and AppEngine
Hello Marcel, you can have a look here http://wiki.restlet.org/docs_2.0/303-restlet.html. It contains sample code with a GAA application (based on Restlet) and an Android client. Best regards, Thierry Boileau Hi Marcel, I have my business model on AppEngine and now like to use Android as a client to communicate via http. I'd like to keep my beans structure and simply transfer objects between client and server and then call servlets for method calls. a) Do you think this is a good approach? (Or are there nicer designs?) Why do you want to call Servlets? You could implement your logic in Restlets. best regards Stephan -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2427898 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2430733
