Re: PUT requires an entity
Hi Jim, On May 8, 2008, at 11:22 PM, Jim Alateras wrote: I've noticed that if i do a PUT to a resource with an empty entity I get a BAD_REQUEST status code. Is it part of the HTTP spec that the PUT must contain a non-null entity. We had a discussion of this a few months back. The conclusion was that the spec might be a little vague, but most implementations consider this an error. Here's the thread: http://restlet.tigris.org/servlets/ReadMsg?listName=discuss&msgNo=3902 Rhett
PUT requires an entity
I've noticed that if i do a PUT to a resource with an empty entity I get a BAD_REQUEST status code. Is it part of the HTTP spec that the PUT must contain a non-null entity. cheers
Duplicate variants coming from DirectoryResource
Hi all, I'm noticing odd behaviour under the latest snapshot in com.noelios.restlet.local.DirectoryResource#getVariants. The getVariants method seems to get called 2-3 times for a single request, and each time it appends the same variants to the variants list. This means that I end up with three variants recorded for the resource (thats three .html variants). This doesn't seem right. org.restlet.resource.Resource#getVariants checks that the org.restlet.resource.Resource#variants field is not null as part of its lazy creation, but nothing checks weather the field is empty or not, so it keeps rediscovering and appending. Should I record this as a bug in bugzilla? -- "It is easier to optimize correct code than to correct optimized code." -- Bill Harlan
Re: Content negotiation in DirectoryResource
I've recorded this at http://restlet.tigris.org/issues/show_bug.cgi?id=491 On Fri, May 9, 2008 at 3:47 PM, Mark Derricutt <[EMAIL PROTECTED]> wrote: > I believe I've found where the negotiate content should be used. Looking > at Directory.java: > -- "It is easier to optimize correct code than to correct optimized code." -- Bill Harlan
Re: Content negotiation in DirectoryResource
I believe I've found where the negotiate content should be used. Looking at
Directory.java:
public Handler findTarget(Request request, Response response) {
try {
return Engine.getInstance().createDirectoryResource(this,
request,
response);
} catch (IOException ioe) {
getLogger().log(Level.WARNING,
"Unable to find the directory's resource", ioe);
return null;
}
}
This is creating and return a DirectoryResource instance. Deeper down
inside Resource.java (line 431) isNegotiateContent() is used, but is
defaulting to true as the Directory instance is never passing down the
setting.
Changing Directory.java's findTarget() method to setNegotiateContent() on
the newly created DirectoryResource before returning it looks to be the
logical fix (I've not yet tried this thou).
Mark
On Wed, May 7, 2008 at 4:09 AM, Jeroen Goubert <[EMAIL PROTECTED]> wrote:
> Hello,
>
> the Directory class has a method "setNegotiateContent(boolean
> negotiateContent)" which can be used to indicate that content negotiation
> should not happen (by default best content is automatically negotiated).
> It seems however that this setter has no impact since the
> "isNegotiateContent()" is nowhere used in the codebase: the
> DirectoryResource implementation always tries to do content negotation.
>
> I think DirectoryResource should look at the negotiateContent-indication or
> am I missing something ?
>
> Best regards,
> Jeroen
>
>
> DISCLAIMER
> http://www.schaubroeck.be/maildisclaimer.htm
>
--
"It is easier to optimize correct code than to correct optimized code." --
Bill Harlan
Re: CLAP across OSGi classloaders/bundles?
Just updated to the latest snapshot and I'm bit further along, it actually requests index.html as expected. Changing my ClientHelper to return a MediaType: InputRepresentation ir = new InputRepresentation(url.openStream(), MediaType.ALL); solves an NPE further down the chain, however now I'm seeing com.noelios.restlet.Engine#getScore being called 3 times, and my output is: [EMAIL PROTECTED]:~/IdeaProjects/securemx/smx3$ curl http://localhost:8182/admin/index.html osgi://smx3.testresource/admin/index.html osgi://smx3.testresource/admin/index.html osgi://smx3.testresource/admin/index.html [EMAIL PROTECTED]:~/IdeaProjects/securemx/smx3$ I would have assumed I would seen the contents of the InputStream that InputRepresentation read, rather than just the internal URL being outputed (3 times no less). Am I missing something simple here? On Fri, May 9, 2008 at 2:37 PM, Mark Derricutt <[EMAIL PROTECTED]> wrote: > So after some experimentation I've created a ClientHelper and registered > that into restlet, only I'm stuck >
Re: CLAP across OSGi classloaders/bundles?
So after some experimentation I've created a ClientHelper and registered
that into restlet, only I'm stuck on the new content negotiation. I have a
Directory mounted to my new osgi://bundle/resource URI scheme, but when I
request /admin/index.html this translates to
osgi://bundle/resource/admin/index which I have no means to resolve.
When I mount my Directory, I'm calling setNegotiate(false) in the hopes that
this would prevent this, but that doesn't seem to help. Any ideas?
For what its worth, my current ClientHelper looks like this (very raw, just
trying to get the data out at the moment). It's quite possible I'm going
about this entirely wrong as I'm still rather new to restlet, esp. the
internals:
public class BundleResourceClientHelper extends ClientHelper {
public static final Protocol OSGI = new Protocol("osgi", "OSGI",
"OSGI Bundle Resource", Protocol.UNKNOWN_PORT);
public BundleResourceClientHelper(Client client) {
super(client);
getProtocols().add(Protocol.valueOf("OSGI"));
}
public void handle(Request request, Response response) {
Matcher matcher =
Pattern.compile("(osgi://)([^/]*)").matcher(request.getResourceRef().getHostIdentifier());
if (matcher.matches()) {
Bundle[] bundles = RestActivator.bundleContext.getBundles();
for (Bundle bundle : bundles) {
if (matcher.group(2).equals(bundle.getSymbolicName())) {
URL url =
bundle.getResource(request.getResourceRef().getPath());
if (url != null) {
try {
InputRepresentation ir = new
InputRepresentation(url.openStream(), null);
response.setEntity(ir);
} catch (IOException e) {
e.printStackTrace(); //To change body of catch
statement use File | Settings | File Templates.
}
}
}
}
}
}
}
On Thu, May 8, 2008 at 5:23 PM, Mark Derricutt <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> I was wondering if anyones managed to get CLAP resources working under an
> OSGi environment?
>
--
"It is easier to optimize correct code than to correct optimized code." --
Bill Harlan
XmlBeans to DomRepresentation
I am trying to convert an XmlBean XmlObject to a DomRepresentation and can't seem to make it work. The following is the snippet of code. (the owner document is not null) Node document = xmlObject.getDomNode(); DomRepresentation representation = new DomRepresentation(MediaType.TEXT_XML, document.getFirstChild().getOwnerDocument()); If I monitor the server side (HTTP response) I see the Xml I am looking for, but on the client side I am getting the following message (and no xml): INFO: The length of the message body is unknown. The entity must be handled carefully, and may be consumed entirely in order to surely release the connection. Thanks, Mike
Re: XmlBeans/Restlet
Thierry, Thank you for your response. It works correctly when you modify the code as you suggested. Thanks again, Mike
