(BUG) restlet-ext-jaxrs depends on a snapshot jax-rs (javax.ws.rs:jsr311-api:jar:1.0-SNAPSHOT).
Restlet-ext-JAXRS depends on a snapshot jax-rs (javax.ws.rs:jsr311-api:jar:1.0-SNAPSHOT). My project is not buildable under this configuration. Using Maven 2.0.9. 1) javax.ws.rs:jsr311-api:jar:1.0-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=javax.ws.rs -DartifactId=jsr311-api -Dversion=1.0-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=javax.ws.rs -DartifactId=jsr311-api -Dversion=1.0-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) * 2) org.restlet:org.restlet.ext.jaxrs:jar:1.1.1 3) javax.ws.rs:jsr311-api:jar:1.0-SNAPSHOT I've reported this as bug in http://restlet.tigris.org/issues/show_bug.cgi?id=647 -- Best regards, Hendy Irawan "Help save my best friend Melissa from teeth infection, please!" -> www.rainbowpurple.com
Re: XmlHttpRequest doesn't like no-entity responses
Hmm. Thought my logging was pretty verbose ... better double check. On Fri, Nov 7, 2008 at 3:50 PM, Stephan Koops <[EMAIL PROTECTED]> wrote: > If I remember right, there is a message in the log, if there is no entity. > > best regards > Stephan >
Re: XmlHttpRequest doesn't like no-entity responses
Hi Rob, (b) we could warn on the server side that sending a 200 with no entity may have deleterious consequences. If I remember right, there is a message in the log, if there is no entity. best regards Stephan
XmlHttpRequest doesn't like no-entity responses
I've attached a test case that illustrates an unpleasant behavior
between XmlHttpRequest and Restlet success responses with no entities.
(We use Jetty connector here as usual.) The server behavior differs
between Restlet 1.0 and 1.1 in how the no-entity responses are sent.
In Firefox 3 and Internet Explorer (possibly others) XmlHttpRequest
gets indigestion and emits a cryptic "no element found" error when
doing a GET or POST to this kind of resource. This error is difficult
to catch, as it seems to happen outside caller code, after the initial
asynchronous call returns and before the callback fires. Depending on
the browser environment, the result is somewhere between noisy and
catastrophic -- an embedded IE inside a SWT browser component on
Windows will lock up permanently trying to report the error.
There's a simple server-side workaround: DON'T send no-entity success responses.
But, seems like Restlet could do something about this ... either (a)
maybe we're not quite right with how we're handling no-entity success,
or (b) we could warn on the server side that sending a 200 with no
entity may have deleterious consequences.
Ideas or recommendations, anybody?
-- Forwarded message --
From: Adam Schwartz <[EMAIL PROTECTED]>
Date: Fri, Nov 7, 2008 at 1:42 PM
Subject: no element found test case
To: Rob Heittman <[EMAIL PROTECTED]>
Just need the SimpleRestlet attached at "/postTest" and the
sampleLoginPage.html will hit it on a submit. The first, then every
other time the Restlet gets a request, it will send back a Success and
voila, the error.
import org.restlet.Context;
import org.restlet.Restlet;
import org.restlet.data.Request;
import org.restlet.data.Response;
import org.restlet.data.Status;
public class SimpleRestlet extends Restlet {
public SimpleRestlet(Context context) {
super(context);
}
public void handle(Request request, Response response) {
if( count % 2 == 0 )
response.setStatus(Status.SUCCESS_OK);
else
response.setStatus(Status.CLIENT_ERROR_BAD_REQUEST);
count++;
}
}
Title: Affiliate Login
Please enter your username and password.
Username:
Password:
Re: JsonRepresentation(JSONArray jsonArray) Not working
Hello Adrian,
this bug has been fixed. You can check out the svn repsitory or wait for
the incoming snapshot (tomorrow).
best regards,
Thierry Boileau
Hello, we are testing the following code in a Java class"
JSONArray jsonFeedEntry = new JSONArray();
jsonFeedEntry.put("Red");
jsonFeedEntry.put("Blue");
System.out.println("VALUES:"+jsonFeedEntry.toString());
result = new JsonRepresentation(jsonFeedEntry);
It seems to print out the proper information but nothing is being returned in
the result for some reason. If we change the same code and add the following,
it works fine with the JSONObject:
JSONObject jsonobj = new JSONObject();
jsonobj.put("id","ID..");
jsonobj.put("name", "NAME...");
result = new JsonRepresentation(jsonobj);
Any reason or documentation on how to get it working properly with the
JSONArray class? Thanks.
Adrian
Re: Router: 'not matched' versus 'not found'
On Fri, 2008-11-07 at 10:06 +0100, Stephan Koops wrote:
> Hi Bruno,
>
> I planned a possibility of JAX-RS for this, but I had no time to
> implement it.
> I will put it higher in my priority list.
>
Cool.
I have just tried if I can do everything I need by some customization
(via subclassing). It works and it is a clean solution.
The only change I need in JaxRsRestlet is the ability to provide a
custom ExceptionHandler. I can then override the methods like
rootResourceNotFound() and set a flag in a response attribute.
I've attached a patch for this small change. I've added a method which
can be overridden using subclassing, just to avoid adding a public
method, but I'm fine with either approach. Do you think this is an
acceptable change?
--
Bruno Dumon http://outerthought.org/
Outerthoughthttp://www.daisycms.org/
[EMAIL PROTECTED] http://www.kauriproject.org/
Index: modules/org.restlet.ext.jaxrs_1.0/src/org/restlet/ext/jaxrs/JaxRsRestlet.java
===
--- modules/org.restlet.ext.jaxrs_1.0/src/org/restlet/ext/jaxrs/JaxRsRestlet.java (revision 3945)
+++ modules/org.restlet.ext.jaxrs_1.0/src/org/restlet/ext/jaxrs/JaxRsRestlet.java (working copy)
@@ -198,7 +198,7 @@
super(context);
final ExtensionBackwardMapping extensionBackwardMapping = new ExtensionBackwardMapping(
metadataService);
-this.excHandler = new ExceptionHandler(getLogger());
+this.excHandler = getExceptionHandler();
this.providers = new JaxRsProviders(this.objectFactory, this.tlContext,
extensionBackwardMapping, getLogger());
this.resourceClasses = new ResourceClasses(this.tlContext,
@@ -210,6 +210,13 @@
this.setRoleChecker(RoleChecker.REJECT_WITH_ERROR);
}
+/**
+ * Allows to provide a custom ExceptionHandler.
+ */
+protected ExceptionHandler getExceptionHandler() {
+return new ExceptionHandler(getLogger());
+}
+
private void loadDefaultProviders() {
this.addSingleton(new BufferedReaderProvider(), true);
this.addSingleton(new ByteArrayProvider(), true);
RE: Patch for 1.1.1 NPE under Apache service wrapper on Windows
Hi Rob,
Thanks for the patch. I applied to SVN trunk and branch 1.1.
In some cases, only doing a Class.forName() will work because it will use
the caller object's classloader (internal code to JRE). That's why we also
have an Engine#loadClass() method for loading classes.
Best regards,
Jérôme Louvel
--
Restlet ~ Founder and Lead developer ~ http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com
-Message d'origine-
De : Rob Heittman [mailto:[EMAIL PROTECTED]
Envoyé : jeudi 6 novembre 2008 23:28
À : discuss@restlet.tigris.org
Objet : Patch for 1.1.1 NPE under Apache service wrapper on Windows
This particular environment has funny classloader behavior. So only
the System classloader resolves.
Accordingly, Engine NPEs due to a bad assumption here:
ClassLoader cl = getClassLoader(); // this may return
null since it doesn't try System classloader
URL configURL = cl.getResource(providerResource); // boom
My patch was to fix getClassLoader(), but while an effective fix, I'm
not sure that's what should be done:
Index: modules/org.restlet/src/org/restlet/util/Engine.java
===
--- modules/org.restlet/src/org/restlet/util/Engine.java(revision
3945)
+++ modules/org.restlet/src/org/restlet/util/Engine.java(working
copy)
@@ -107,6 +107,10 @@
result = Class.class.getClassLoader();
}
+if (result == null) {
+result = ClassLoader.getSystemClassLoader();
+}
+
return result;
}
Re: Router: 'not matched' versus 'not found'
Hi Bruno, I planned a possibility of JAX-RS for this, but I had no time to implement it. I will put it higher in my priority list. best regards Stephan Bruno Dumon schrieb: Hi, I have a situation where it would be very useful if a router (a normal Restlet Router or the routing part of JAX-RS) could tell in its response whether there was a matching route. An example to clarify: I would like all requests to be handled by JAX-RS, and if there's no resource class to handle the request, move on to another router to handle the request. (it's not possible to decide on beforehand to what router to go, nor is the caller aware of what resources are available within each router) This is currently not possible, since what JAX-RS (or the normal Restlet router) does when there's no matching resource class or matching route is setting the response to 404. This is ok, but it doesn't allow to make the distinction between "no matching route" or "a route matched, but the addressed resource was not found". Any suggestions? Would this be something that could be considered for inclusion in Restlet? The solution I'm thinking of is that restlets which perform routing (= Router, JaxRsRestlet, possibly others) could set a special response attribute to indicate there was no matching route.
