In GWT application I have RPC interface. Some methods works fine (i.e. RemoeServiceServlet configured fine), but when I try to invoke another method, it always fails with onFailure() method. Ajax call also don't occur (I can see it using FireBug, also on server side method invocation don't occur), but another methods of this service performs Ajax calls as well.
When I try to log error using e.getMessage() I get "undefined" message. Also I tried to wrap RPC calling code using try-catch - no error message.
Can this issue be related with GWT-RPC Serialization?
EDIT: Opera Dragonfly showed error on following method inside generated JavaScript (compiled with PRETTY mode):
function $check(this$static, typeSignature){
if (isNull($get_3(this$static.methodMapNative, typeSignature))) {
Unhandled Object: undefined
throw new SerializationException_1(typeSignature);
}
}
with error message
Unhandled Object: undefined
I would guess that you have a Serialization issue, remember that Java Serialization is not the same as GWT Serialization.
There is often no meaningful error message on Serialization errors when using RPC.
must have 0-ary constructor
final fields are inherently transient (ie. do NOT use final fields in classes intended to be serialized)
collections (ex List and Set) must be annotated with #gwt.typeArgs. #gwt.typeArgs is a JavaDoc annotation, thus it must be wrapped in a JavaDoc comment
ex.: /** #gwt.typeArgs */
For more details see:
GWT Serialization
Another thing to try:
When running GWT from the eclipse-plugin, a folder in the eclipse project is created (I belive its called gwt-unitCache). Sometimes my own GWT projects get ill and output strange exceptions, I can solve this by deleting the folder and run the project again.
Related
We are Upgrading to Jetty 9 from Jetty 6, but in our previous code we are throwing org.eclipse.jetty.http.HttpException, but I see that this Class is removed in 9.x. Is there any equivalent of this class or should I define a new class with the same content to use it in my code?
Jetty 7.6 was the first version to not have HttpException.
It was removed as part of commit d81f9c1e
The purpose of HttpException was limited to reporting really bad HTTP parsing issues with bad requests (all of which would result in a 400 Bad Request). That implementation was changed to use HttpParser.badMessage() instead, as that will properly set the connection state, and then allow implementations of HttpHandler.badMessage() to log or produce whatever response is desired, afterwords resulting in a forced connection close.
Without this change, it was not possible to log 400 Bad Request in the access log, and customize the error 400 response message.
There is no equivalent exception for HttpException present in Jetty 7.6+.
It was an internal class anyway, not meant for you to be using.
What are you attempting to accomplish by using that?
New to scala futures I try to call a web service like
wsClient.url(baseUrl + url).withHeaders("Content-Type" -> "application/json").post(dataForR).flatMap(parseOutlierResponse)
using ply-ws library
I validate & map the response as follows https://gist.github.com/geoHeil/943a18d43279762ad4cdfe9aa2e40770
The main thing is:
Await.result(callAMethodCallingTheFirstSnippet, 5.minutes)
Strangely this works just fine in the repl. However if run via sbt run I get a NullPointer Exception. I already verified the JSON response manually. It validates like a breeze. Even the mapping works great. However, there must be a problem with the futures I am using. But I am not sure what is wrong. It seems like the flatMap method is called before there already is a result.
Interestingly if I do not await the result there is no null-pointer exception, but the parsed result is displayed correctly (however, the program does not exit). But there, where I really use this code, I somehow need to await the successful completion to further deal with it.
Below you will find an illustration of the problem
I do not see any major concern with your code! I made a small test with the following code bit and it seems to be working perfectly, both in the REPL and when using sbt run:
WS.clientUrl(s"http://$hostName/api/put").withHeaders(jsonHeaders: _*).post(body).map { r =>
if (r.status >= 400)
logger.warn(s"Invalid http response status: ${r.status} \n ${r.body}")
else
logger.debug(s"Successfully persisted data. Http response ${r.status}")
}
After more and more debugging I found that some implicits were in the wrong scope and the order of dependent case-classes was wrong. After moving them into the correct scope (the method performing the request) the null-pointer exception is fixed.
I could only find the "real" error after changing from flatmap to map which I find very strange. However, now both methods work fine.
I had to copy some existing beans and their remote interfaces within an existing working application. Now whenever I call one of the methods, I get the following exception:
java.lang.IllegalStateException: EJBCLIENT000032: Cannot retry a request which hasn't previously been completed
at org.jboss.ejb.client.EJBClientInvocationContext.retryRequest(EJBClientInvocationContext.java:203)
at org.jboss.ejb.client.EJBInvocationHandler.sendRequestWithPossibleRetries(EJBInvocationHandler.java:256)
at org.jboss.ejb.client.EJBInvocationHandler.sendRequestWithPossibleRetries(EJBInvocationHandler.java:265)
at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:198)
at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:181)
at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:144)
at com.sun.proxy.$Proxy27.createRawSTRProfiles(Unknown Source)
at org.acme.project.CreateSomethingRunnable.run(CreateSomethingRunnable.java:76)
at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:121)
The same bean works for other method calls. There is no other exception on neither client nor server side, a breakpoint inside the server method in question is never called. I have no idea how to debug, and Google is oblivous to this error message. We are using WildFly 8.1.0.Final.
Can anybody help shed light on this issue? Thanks.
The root exception for us was a ClassNotFoundError because an entirely unrelated JAR inside the EAR had the wrong version number.
Double-check everything. We dismantled the value that was sent (setting all fields to null). When that worked, we set the fields to objects again one by one, checking the classes in question for Serializable (because sometimes a missing Serializable causes similar exceptions).
In short, ensure that all classes going over the wire implement the Serializable interface.
In regard to potential runtime failures, like database queries, it seems that one must use some form of Either[String, Option[T]] in order to accurately capture the following outcomes:
Some (record(s) found)
None (no record(s) found)
SQL Exception
Option simply does not have enough options.
I guess I need to dive into scalaz, but for now it's straight Either, unless I'm missing something in the above.
Have boxed myself into a corner with my DAO implementation, only employing Either for write operations, but am now seeing that some Either writes depend on Option reads (e.g. checking if email exists on new user signup), which is a majorly bad gamble to make.
Before I go all-in on Either, does anyone have alternate solutions for how to handle the runtime trifecta of success/fail/exception?
Try Box from the fantastic lift framework. It provides exactly what you want.
See this wiki (and the links at the top) for details. Fortunately lift project is well modulized, the only dependency to use Box is net.lift-web % lift-common
Use Option[T] for the cases records found and no records found and throw an exception in the case of SQLException.
Just wrap the exception inside your own exception type, like PersistenceException so that you don't have a leaky abstraction.
We do it like this because we can't and don't want to recover from unexpected database exceptions. The exception gets caught on the top level and our web service returns a 500 Internal server error in such case.
In cases where we want to recover we use Validation from scalaz, which is much like Lift's Box.
Here's my revised approach
Preserve Either returning query write operations (useful for transactional blocks where we want to rollback on for comprehension Left outcome).
For Option returning query reads, however, rather than swallowing the exception with None (and logging it), I have created a 500 error screen, letting the exception bubble up.
Why not just work with Either result type by default when working with runtime failures like query Exceptions? Option[T] reads are a bit more convenient to work with vs Either[Why-Fail, Option[T]], which you have to fold/map through to get at T. Leaving Either to write operations simplifies things (all the more so given that's how the application is currently setup, no refactoring required ;-))
The only other change required is for AJAX requests. Rather than displaying the entire 500 error page response in the AJAX status div container, we check for the status type and display 500 error message accordingly.
if(data.status == 500)
$('#status > div').html("an error occurred, please try again")
Could probably do an isAjax check server-side prior to sending the response; in which case I can send back only status + message rather than the error page itself.
I am not able to understand the places where an error handling or where an exception handling should be used. I assume this, if it is an existing framework class there are delegate methods which will facilitate the programmer to send an error object reference and handle the error after that. Exception handling is for cases where an operation of a programmer using some framework classes throws an error and i cannot get an fix on the error object's reference.
Is this assumption valid ? or how should i understand them ?
You should use exceptions for errors that would never appear if the programmer would have checked the parameters to the method that throws the exception. E.g. divide by 0 or the well known "out of bounds"-exception you get from NSArrays.
NSErrors are for errors that the programmer could do nothing about. E.g. parsing a plist file. It would be a waste of resources if the program would check if the file is a valid plist before it tries to read its content. For the validity check the program must parse the whole file. And parsing a file to report that it is valid so you can parse it again would be a total waste. So the method returns a NSError (or just nil, which tells you that something went wrong) if the file can't be parsed.
The parsing for validity is the "programmer should have checked the parameters" part. It's not applicable for this type of errors, so you don't throw a exception.
In theory you could replace the out of bounds exception with a return nil. But this would lead to very bad programming.
Apple says:
Important: In many environments, use of exceptions is fairly commonplace. For example, you might throw an exception to signal that a routine could not execute normally—such as when a file is missing or data could not be parsed correctly. Exceptions are resource-intensive in Objective-C. You should not use exceptions for general flow-control, or simply to signify errors. Instead you should use the return value of a method or function to indicate that an error has occurred, and provide information about the problem in an error object.
I think you are absolutely right with your assumption for Errors and for it framework provide a set of methods (UIWebView error handling ), But your assumption for Exception partially right because the exception only occurred if we do something wrong which is not allowed by the framework and can be fixed. (for example accessing a member from an array beyond its limit).
and will result in application crash.