GWT's servlet implementation has onBefore/onAfterDeserialization which would give me a hook with which to start and stop transactions without doing anything fancy, however those methods don't allow me to properly check for error conditions after the service method got invoked, I just have access to the serialized return value, not directly to any exception that might have been thrown, so deciding whether to roll back or not is not possible that way without rewriting parts the GWT servlet.
I was thinking about using aspectj's compile-time weaving. However, this does not work with Netbeans' compile-on-save feature because the module needs to be recompiled using the aspectj compiler.
How about LTW (load-time-weaving)? Is there any way (or example) to add LTW to the webapp container without using the Spring framework?
I was also thinking about using AOP based on Java dynamic proxies, ie. to put a proxy in front of the servlet. Again, the question arises how to tell the Jetty WebApp container to load the proxy instead of the original servlet.
Or is there any ready-to-use solution out there already?
I think you could overwrite a combination of
public String processCall(RPCRequest rpcRequest) from RemoteServiceServlet and RPC.invokeAndEncodeResponse to do what you want.
Not ideal, as you need to copy/paste a few lines of code, but they really are only a few.
I myself hit the same problems as I needed some customizations, and relevant methods didn't had the access modifier that I needed, so I ended up copy/pasting some portions.
I can't comment on the rest of your question, but I don't expect to find any ready-to-use solutions, as GWT-RPC doesn't seem to have any new fans out there; just people maintaining legacy systems. Therefore, I expect that you either don't find anything or find solutions that are no longer maintained.
Related
I have a project which is basically an Apache Wicket web app, but it also has 3 REST services. I'd like to keep these two different technologies together in one application, as they share quite a lot of classes. Also, I'd like them to share the same JPA instance, as they operate on the same database.
The problem I'm facing is that, as soon as any JAX-RS path is specified, all URLs sent to the application appear to be handled by JAX-RS, even if the REST paths specified don't justify this. Concretely:
#PATH("service")
public class ServiceClassA
#PATH("s1")
public String someMethod...
#PATH("service")
public class ServiceClassB
...
Please note that thereby all defined services have a URI starting "MyAppName/service/...".
The Wicket classes are unaffected by this, as probably the Wicket filter runs before JAX-RS has a chance to grab the URL. But plain resources like css files get in the hands of JAX-RS, resulting in a
No root resource matching request path browser/xxx.css has been found, Relative Path: /browser/xxx.css.
The JAX-RS endpoints contain, in addition to those for the service methods shown above, a general one:
REST Application: http://localhost:8080/MyAppName/ -> org.apache.openejb.server.rest.InternalApplication
As soon as I remove all #PATH annotations, my css is served normally. So I suspect that the endpoint just shown is automatically generated and causes any URI of my app to be handled by the REST framework, even if no path was defined for it. So what I basically need is to tell JAX-RS to ignore
either all URIs not starting with "MyAppName/service",
or all URIs starting with "MyAppName/browser",
or to redirect all URIs it can't handle to the standard Web Server mechanism.
I experimented and googled for possible configuration options quite a lot, but still I didn't find anything suitable for such a simple requirement. I'd appreciate any hints.
BTW, my web.xml is plain vanilla. It contains the wicket filter, mapped to /*, and nothing else, in particular no filtering or servlet for JAX-RS. The server is TomEE-plus 1.6.0.2, and the JAX-RS libraries are the ones shipped with TomEE.
JAX-RS is a servlet so without binding it to a sub context of your app it conflicts with resources. You can provide an Application with #Application("subcontext").
Note: TomEE supports exclusion of some static resources but the configuration is explicit in openejb-jar (https://issues.apache.org/jira/browse/TOMEE-728) so first solution is easier.
I'm doing a Java Backed Webscript to put in Alfresco and call it via REST. This Webscript must do a set of 3 operations (find a path, create a folder and upload a document).
I read about this and found similar examples to do this operations throw the native Alfresco API, with methods like getFileFolderService, getContentService, etc. of Repository or ServiceRegistry classes. All in Java, without javascript.
But I would rather use REST calls instead of Alfresco API inside my Webscript. I think that if already exists Webscripts to do these operacions, is easier call them than use Alfresco API methods to try to do it. And if the API changes in future versions, the REST calls would remain the same. But I'm new here and I don't know if I'm wrong.
In summary: to do these 3 operacions, one after another, in my backed webscript, what is better and why? Use native API methods or use REST calls to existing webscripts?
And if I try to do the second option, is possible to do this? Using HttpClient class and GetMethod/PostMethod for the REST calls inside my Java Webscript may be the best option for Rest calls?. Or this could give me problems? Because I use a Rest call to my backed webscript that do another rest calls to another webscripts.
Thanks a lot!
I think it's bad practice to do it like this. In a lot of Alfresco versions the default services didn't change a bit. Even when they changed they still had deprecated methods.
The rest api changed as well. If you want to make an upgrade proof system I guess it's better to stick with the Webservices (which didn't change since version 2.x) or go with CMIS.
But then it doesn't make sense to have your code within Alfresco, so putting it within an interface is better.
I'd personally just stick with the JavaScript API which didn't change a lot. Yes more functions were enabled within, but the default actions to search & CRUD remained the same.
You could even to a duo: Have your Java Backendscript do whatever fancy stuff and send the result to je JavaScript controller and do the default stuff.
Executing HTTP calls against the process you are already in is a very very bad idea in general. It is slower, much more complex and error-prone, hogs more resources (two threads), and in your case, you will even lose transaction safety. Just imagine the last call fails for some reason. Besides you will most likely have to handle security context propagation yourself. Use the native public API and it will be easy, safe and stable.
I have 2 different gwt applications, both on different machines, but they need to communicate.
Is their a simple way, using the gwt mechanisem to do it and access an existing servlet on another gwt application, or do i need to open another http connection between them some other way?
The most standardized way to do that is to use JMX: it is future prone and a lot of work was already done for you.
http://en.wikipedia.org/wiki/Java_Management_Extensions
Your issue cannot be considered as a GWT problem since GWT is limited to java script, and you need real java methods to communicate together, doing it through GWT is at best unperformant and at worse the source of many problems (since you are not inside a browser, and using a "virtual browser" to execute your javascript might lead to subtile very hard to understand differences)
So I managed to create a GWT-SpringMVC setup. Wasn't easy (not too many resources), but possible. I even autowired and stuff. It even works :)
However, I can't figure out how to make the GwtTestCase run. Obviously it needs the "server" to be up, and because I use Spring, it needs to pass through the dispatching servlet (no?). But I can't figure out how to connect the two. In production or hosted mode, I got the web.xml and the spring-servlet.xml to configure these things. What can I do for tests?
I thought of ignoring the web part and testing the service directly - but this will deny me the option to automatically tests that everything is "transferable".
(if you have an idea on how to do that, I might ditch the GWTTestCase altogether).
An alternative to GWTTestCase could be the gwt-test-utils framework, which provides a simple integration with Spring (see here for details)
Still wresting with GWT and App Engine, and I have come to this problem:
I have an app engine populated with various data, which I would like to present on the client using a GWT RPC.
I have found out the hard way that, because my Model objects are annotated with JDO, i can't just send them back to the client because they aren't serializable. This means I'm going to have to create a layer of intermediate classes to extract data from my model objects, and send it back to the client to use asynchronously.
I am wondering though, it is possible to construct a GWT object in a servlet and send it back to be used? For example, the servlet would be receive my asynchronous request, pull out the data i want from the database, create a GWT VerticalPanel() with appropriate child elements for the data, and send that VerticalPanel back to the client to be injected.
My understanding of the Java / Javascript interaction that is going on here is still foggy, and I'm thinking that sending a Java object that is not compiled to Javascript after the application is deplyed will not work. Can anybody clarify this for me?
No the server can't create GWT UI objects (like vertical panels) to be used in the presentation layer, nor should it, that's why it's called a 'server' and a 'presentation layer' one serves the data and handles all the business logic, the other displays things on a screen and allows a user to interact with them.
You can however send your JPA annotated POJO's to the front end just fine (we do it in all our applications). You simply need to include the source code for the annotations themselves so that GWT knows how to compile them. You also need to make sure your POJOs's are in a package that is referenced by a NameOfXmlFile.gwt.xml file, eg:
<module>
<inherits name='com.google.gwt.user.User'/>
<source path="domain" />
</module>
This file in my case is in a folder above a package called 'domain' where all my JPA annotated POJO's live. Then in your client side you tell it to inherit that .gwt.xml file:
<module>
<inherits name='com.google.gwt.user.User'/>
<!-- Domain layer references -->
<inherits name='your.package.structure.NameOfXmlFile'/>
</module>
There are restrictions on what you can put in those classes (like for example BigDecimal is not supported, etc) but anything that can be compiled by the GWT compiler (and JPA annotations certainly can be) can be sent without needing any kind of transfer objects. This is one of the real strengths of GWT, that you can use the same JPA Pojos in your entire application, without ever needing to create any other similar object.
Edit: I just noticed you said JDO and not JPA. I assume the same applies there as well though if they are just annotations?
I've seen good answers, so I won't repeat them myself..
Anyway my simple but vital suggestion is: the only way to go is through POJO objects.. BUT IMHO to avoid problems, remember that your POJO objects SHOULD be really PLAIN
Anyway, I can suggest you also a little framework I recently did (few hours of work, so don't expect a rocket!).
It is pojo-injector: http://code.google.com/p/pojo-injector
It helps you in translating your data models to POJO and back... It's based on annotations (only on the POJO side!).
I hope it can help.
This is (imho) one of the problems with GWT.
Basically in Java Web applications it's pretty common to have data or domain objects (which would be your JDO objects) and presentation objects, which are sent to the view. Some go much further than this and can have many more layers of abstraction ("go ahead, add one more layer").
I can see the argument for this but it adds a lot of boilerplate as you translate objects between layers.
Anyway, in GWT you need to do this if your domain objects are POJOs (and as with JPA, even though they claim to be POJOs, the annotations make them not so in reality).
GWT will do this for you on objects returned by your RPC interface but there are certain classes you can't use (eg BigDecimal) as there is no Javascript equivalent (so to use BigDecimals you pass Strings around to construct BigDecimals yourself on the serverside when you ened them and convert them back to Strings when you send them to the client).