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.
Related
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.
I've written a REST server in Delphi XE (using the wizard) and I want to change the URLs a bit so that instead of having
http://192.168.1.84:8080/datasnap/rest/TServerMethods1/GetListings
I get something that looks more like http://192.168.1.84:8080/GetListings
Is there a nice easy of doing this?
The naming convention is (Delphi XE3):
http://my.site.com/datasnap/rest/URIClassName/URIMethodName[/inputParameter]
You can easily change the "datasnap" and "rest" part of the URL in the TDSHTTPWebDispatcher component properties. You can change the Class Name and Method Name of the URL by simply changing the name of your class and method. However, you still have to have 4 components to the URL, so for example it could be:
http://my.site.com/api/v1/People/Listing
See here:
http://docwiki.embarcadero.com/RADStudio/XE3/en/REST#Customizing_the_URL_for_REST_requests
You could put IIS or Apache in between to accomplish this, and indeed rewrite the URL to point to your service the way you like.
That provides some more advantages anyway (security and scalability mostly). For example, you can create a fail-safe setup with double servers, or you can create multiple machines with your service, and have your web server do the load balancing for example.
You'll get extra logging capabilities, and if you easily want to serve other web content it's easy to have a full fledged web server anyway.
URL rewriting is usually done in the web server configuration, in Apache using entries in the .htaccess file
I want to host restful webservice from CQ5. Basically the intention is to expose all the users present in CQ5 to external systems based on some parameters like modified date, user state etc.
I went through https://chanchal.wordpress.com/2015/01/11/using-jax-rs-and-jersey-to-write-restful-services-in-osgi-apache-felix-adobe-cq5aem/ as I could find only this post online, but as I am a beginner I couldn't implement it. Need guidance in implementing such RESTful webservice in CQ5
CQ5 is based on Apache Sling which is inherently RESTful, so you don't usually need additional libraries. In your case (and unless the users info is already available as Sling resources, I don't remember if that's the case) implementing a Sling ResourceProvider is enough to provide a browseable RESTful representation of those resources. See the Sling docs for more info, they point to a simple PlanetResourceProvider as a minimal example.
Couldn't get the REST webservices working with AEM/CQ5. Even after installing the packages for JAXB for CQ5. It seems like sling overrides the resolving before it goes to the JAXB annotation handler. Due to lack to time had to implement an alternative approach where CQ5 will be timely writing the json data to an shared location as json file and the third party applications will fetch the files from there.
This will however impact the performace as schedulers are to be written and also it's not a recommended approach but still it will work in my scenario.
Thanks all for helping me.
I developed a web application (works properly) which registers a user to the system and allows user to upload a file to system via https. The client side code is totally developed by using GWT 2.4 and the back end is several servlets. Except the upload code, all the client-server communications are done via using ServiceAsync interface as it is the common practice in GWT. The upload code is based on a form which is communicating with the upload servlet directly.
This project is developed as a course work and my Professor is keen on knowing the underlying architecture of google web toolkit specificly focused on the client-server communication. His question was,
"How the client code knows the server's url so that all the communication is done?"
His question is legitimate for the ServiceAsync interface. I am calling a function on the server side which seems interesting to him and he wants to know the underlying process behind it.
For uploading, I just defined uploadForm.setAction(GWT.getModuleBaseURL()+"upload"); where upload is the name of the upload servlet in web.xml.
I told him that the compiler generates Javascript code which contains all the web application code (whole system developed dynamically) and the url to the servlet is placed in that script file however the answer did not satisfy him. Please let me know the inner facts of the client-server communication with GWT.
Please give me some answers that can help my Professor to understand GWT's asynchronous client-to-server RPC communication.
The underlying technology is shown here as a diagram. Google says "GWT provides an RPC mechanism based on Java Servlets to provide access to server side resources. This mechanism includes generation of efficient client and server side code to serialize objects across the network using deferred binding."
The client knows the URL to query because you would have annotated your service interface with a #RemoteServiceRelativePath tag. This associates the service with a default path relative to the module base URL. That URL is where Javascript sends your request.
There's a lot more to learn about GWT's RPC if you care to, and you can start picking it apart here and here.
There are multiple ways in GWt how to bind RPC service to the specific url.
First is an annotation #RemoteServiceRelativePath which is placed on synchronous interface. Using deferred binding rule GWT will discover this URL and will set it to the service instance automatically.
Second is casting instance of GWT-RPC async service to the ServiceDefTarget and setting an url manually.
But this answer alone will not satisfy your professor, because most likely he will want to know some other details, so I recommend you to learn how exactly GWT-RPC works.
Regarding the basic question of how the client knows the url of the server, it sounds as though the professor may be asking about the full url of the site (the domain name), and not just the sub-directories for the services as they are defined in #RemoteServiceRelativePath and the web.xml.
For this more fundamental aspect of the question, I think the "Same Origin Policy" (SOP) that browsers have for javascript security could be an important part of the answer. This is explained in one of the GWT FAQs. The first thing that the browser is doing on the client side (after the HTTPS connection is established, which I think could be another important part of the answer) is reading the host html file, where the bootstrap nocache.js file is referenced. Once this file is loaded, the SOP is going to guarantee that all of the subsequent JS application files are coming from the same server as the bootstrap and the host html files. Once the application files are loaded, then everything is happening within that context, with specific internal url paths being defined for RPCs as already mentioned.
I have been trying to figure out how to use JAX-RS for quite some time. I started from the very basic concepts and then to gradually understand the annotation styled programming, the meaning of #Path, #Get, #Post, etc.
To my understanding, as to what has been mentioned in a lot of places, JAX-RS is a framework that focuses on applying Java annotations to plain Java objects (Page 27, Bill Burke, RESTful Java).
I have then got confused beyond this point. If JAX-RS in itself is a framework that defines APIs dealing with annotations in order to implement RESTful web service, what's the meaning of "implementation of JAX-RS" such as "Jersey" and "JBoos Resteasy". Another layer on top of JAX-RS? Why do we need them?
Could someone provide me some insights about it? Many thanks!!!
JAX-RS is a standard defined in Java Specification Request 311 (JSR-311) and Jersey / RESTEasy are implementations of it.
Being implementations mean that the spec says "if you put #GET("/foo") on a method (bar()), you may access data X" - now in an app server, someone needs to go in and actually read your deployed code, parse the byte code with the #GET annotation and then if the user actually browses to e.g. http://localhost/foo get this web request to reach bar() and translate the return value of bar() into a http answer (e.g in XML or JSON representation).
So the spec with the name "JAX-RS" only provides the syntax and semantics of e.g. #GET, but the work of parsing requests, calling the right methods, marshalling the result values etc. need to be done by a package that implements the Spec.
Work on the version 2.0 of the standard has started as JRS-339.
See also http://en.wikipedia.org/wiki/Jax-rs
JAX-RS is a specification for RESTful Web Services with Java. There is a reference implementation that is included in Java EE but since it is a specification, other frameworks can be written to implement the spec, and that includes Jersey, Resteasy, and others.