I'm trying to develop a small server which would include one restful webservice.
I'd like to use JAX-RS for the webservice part, but every example I'm seeing is using a tomcat server, and I can't use any 'application' server (meaning I can create a server in my code, but can't run it from the outside).
Well anyway I was wondering if anyone had any sample to show, and any advice on which light library I could use to run such a simple server into my code (can't use any gpl /lgpl etc licence, so no jersey for example).
Thank you.
It's possible to embed Tomcat in your application, see here for an example: http://java.dzone.com/articles/embedded-tomcat-minimal
Another popular choice for an embedded servlet container is Jetty, they have a tutorial here.
Edit
The examples provided with Jersey can also be helpful, here's one for running using the Grizzly HTTP library: https://github.com/jersey/jersey/blob/master/examples/helloworld/src/main/java/org/glassfish/jersey/examples/helloworld/App.java
You can even use the HTTP server that's bundled with the JDK (probably not the way to go for a real application): https://github.com/jersey/jersey/blob/master/examples/helloworld-pure-jax-rs/src/main/java/org/glassfish/jersey/examples/helloworld/jaxrs/App.java
Have you checked out http://www.sparkjava.com/?
It's very light-weight and concise.
Building a server into code is nothing. See "Embedding Jetty", for one. There are plenty of other options with varying degrees of difficulty and capabilities, like the Simple Framework, Tomcat, Grizzly, Netty, and Vert.x, to name a few. Then, if you're not stuck with Java, the language, there's Ratpack for a lightweight REST server. Otherwise, running something like Jersey in an embedded server is quite simple. I do it every day in tests.
Related
I'm using a set of APIs developed internally by my company to communicate with some common central services in the organization. The APIs can be configured dynamically by runtime configuration to use several transport protocols as needed by the system.
The collection of internal APIs are coupled to the IBM WebService thinclient.jar to configure and call all the necessary web services. I got the standalone prototype working smoothly, but need to integrate the functionality into several other services that are being developed in Grails.
This is where things fell apart. In the code that I've written, we just call a factory method and use that to get a client session and then proceed with our business logic. Simple. Using the debugger and digging into the API getClient() call, I can see that this gets a generic transport configuration and then binds it to a SOAP transport configuration. From here, the path differs whether it is the pure standalone Java service or the service running in the Grails app.
In the pure Java standalone, this then is bound to a
com.ibm.ws.webservice.engine.client.Service where the
initService() method is called and things work as expected.
In the Grails app, with the same Java code included, the same place
in the code calls to
com.springsource.loaded.ri.ReflectiveIntercepter and then after a
lot of back and forth in the spring-loaded API, it finally throws a
java.lang.reflect.InvocationTargetException.
Does any one have any tips or ideas on how to get the reflection in Grails to behave the same as in the straight Java?
I've tried a lot of variations to get to this point and I'm nearing the end of my rope. Ideally, it would be easiest to manage the Grails service that manages our business logic and the Java code that talks to these internal systems together, so I would prefer to get everything (Grails and my Java service code) working together. I briefly tried building a standalone JAR of my service code and all it's dependencies, but had chained dependency conflicts when trying to use that in Grails. My final option will be to stand my Java service up separately from the business logic in the Grails service and just make the calls from the Grails service to the Java service. This is less than ideal.
It's easy when you stumble into the answer... ;-)
The Grails service runs as expected if I set the run configuration in IDEA to use -noreloading option.
grails -noreloading run-app
This stops Grails/IDEA from leaving in the hooks to reload classes on the fly.
Are there any thoughts on whether this is a bug in Grails or the SpringSource Loader classes?
I am looking to use Jersey without the need of installing an application server such as Tomcat or Glassfish. Ideally I would like to create a lightweight program that listens on a port and allows connections. I believe you can do this with Grizzly + Jersey but I am not sure how easy this is, because from my understanding Grizzly is used to write new http servers from scratch?
Restlet looked good in this regard because it included an internal http server but the documentation provided is extremely meager.
You can use a light-weight servlet container like jetty. you can bundle and ship this with your application. Also building and shipping jetty with your application is very easy.
I've deployed an app recently that uses embedded Jetty in Spring to launch Jersey, so this is 100% possible. Jersey, in fact, has a SpringServlet for easy delegating to a Spring context based REST implementation. If you have additional questions down this route, let me know. It wasn't the most straight forward, but I can talk you through some of it with the appropriate links.
We have a java server application which runs certain batch jobs. It's core function is not as a web application and there's no reason for it to be that. But we would like to add an option to check what the app is doing from a web page. And we thought this could be nicely done with the Google Web Toolkit.
In any previous experiences we have with GWT we have deployed it on Tomcat. But in this case it seems like overkill. The web part is more of a side function to what the application is actually doing.
I'm thinking of a solution where the web server is integrated into the jar file - perhaps Jetty? So that the full java application can be deployed to a single jar file together with the web/GWT part.
There may be performance aspects to this but the web side of things will have very few users. Are there any other reasons not to do it this way?
And, can you give some advice on how to configure Eclipse / Ant / Jetty / GWT for this?
we had the similar experience at our previous project. There was an eclipse-rcp application, with embedded Jetty server (it was started programmatically when application was starting). GWT application was deployed into the Jetty as usually. Also there was a OSGI-service as a controller to provide communication between GWT-server and other parts of application. GWT server was usual RCP server, which is described in the most of examples. It had a reference to the controller. Moreover, it was an event listener, to support bot-side communication.
The main problem for us I think, was synchronization problem. Since there were a lot of messages between eclipse-rcp application an GWT-part (every let say 100 ms the message was received) and GWT had an asynchronous way of communication between client part and its server part, then some mechanism had to be created to synchronize those messages. Otherwise there were no performance problems (except IE 6. which had to be supported:S :D).
Hope this will somehow help.
Upd: As far as I remember, the controller was registered as OSGI service only to be able to communicate with other services of Eclipse-RCP part. In order to communicate with GWT controller was implementing special interface, which was known to the GWT-server (Controller was registered as an implementer through instantiation and the server was regsitered in the controller as IMessageListener). This interface was lying in separate project, which could was also built into the .war file. This project also contained number of event to support backward communication from controller to GWT-server through IMessageListener interface.
It's kind of confusing probably, sorry. May be I should draw a diagram..
We had our own custom web server(written in java) built in 2005. We are thinking of moving to apache web server. Does anyone know any pointers about this process?
What is your code base in? If it's also in java then you will need a middle layer to actually run your applications, like tomcat.
Why do you want to move to apache. For a java code base you will be adding a layer of complexity. However, if you current server is broken or not scalable then by all means switch.
Here is an article on setting up tomcat and apache.
http://www.jajakarta.org/tomcat/tomcat3.2-4.0/tomcat-3.2.3/doc/tomcat-apache-howto.html
Can someone point me a good step-by-step tutorial to consuming an already running web service in java?
PS: I tried creating the classes with wsconsume, but it cries with
[ERROR] rpc/encoded wsdls are not supported in JAXWS 2.0. (my web service is rpc/encoded)
If I can consume web services entirely by hand (using no wizards), and understand how is it working, then I'll be happy.
Thanks!
Update: I have found out that rpc web services are not consumed using jbossws, but jboss-jaxrpc, which implements the JAX-RPC specification. I've found a guide for JAX-RPC here, but I'm still looking for other guides that could help.
Apache CXF is the easiest way to get webservices running. Specifically look at the Simple Frontend. The simple front end uses reflection to convert the method/data types to a webservice. It doesn't get much easier than that.
CXF is pretty stable, but does not include all the WS specifications (WS-Eventing for example).
How about the JBossWS website? The details on the client side wsconsume tool are probally what you will look at first.
If you have the WSDL and XSD files, you can use the Axis web-services library to create Java classes that will interact with the services they describe. From the stand-point of this library, you are creating a client application.
You can also consume web services with Spring WS.