We are trying to deploy java restful webservies, which we have implemented using jersey, in unlimitedgb.com webhost. Which provides java7 and tomcat7.
When we had a chat with the technical support team of unlimitedgb, they replied saying "Sorry we are not providing support for JERSEY in java private JVM".
In our local system which consists of java7 and tomcat7, it works fine.
As per my knowledge as jersey provides api's for restful webservice development, so there must not be any dependency on the server or server's architecture or may be some other internals. So jersey must work with java 1.6 and above.
But when I got reply from the technical support team that they don't support jersey I was really confused and started thinking if there is really any dependency of jersey on server or server architecture.
I feel the support team is not having any technical details about jersey.
I have not purchased the web host yet.
Please help me with the technical details so that I can go ahead in purchasing the web host.
I am not sure how much this would help but I used Jelastic and was able to deploy the war and host Jersey APIs without any support.
So, I am pretty confident with your own private VPS hosting, you should be able to get it working.
When support says, 'we don't support that', what they mean is, we won't answer your questions about that topic.
Jersey should be completely fine in that environment, however, you should write a suite of tests, so that when you change JVM you'll be notified of strange failures due to differences in the JVM. Testing jersey
If you want a completely Java EE-container-free rest environment, check out RestExpress
Related
Is it possible to setup the IBM HTTP server as the front end for a non IBM Websphere application server (Glassfish, Apache Tomcat or other Java application servers) and is it supported by IBM? I tried to look for similar articles online but to no luck. I also tried asking IBM support but they haven't gone back to me as of this posting. Feedback will be very much appreciated.
It is possible, but not supported. To summarize the license options across different releases: you have either totally unsupported or bundled with an IBM product (like WAS) and supported when used in a way direct and necessary to support that product.
It's generally inadvisable, too. Because you IBM cares very little about the alternate modules used for this kind of thing and you can't service them yourself as a user. Contrast with just using Apache or nginx.
IBM HTTP is an enhanced variant of Apache HTTP Server. I have used it in the past as a reverse proxy in front of Tomcat Server (as well as other non application servers for example Websphere Message Broker) in the past. I am not really sure if the entitlement allows support from IBM to permit this , you will have to specifically check if the entitlements allow support on non WAS instances.
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.
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.
I am currently developing an application for some researchers in my university.It's a small java program that you can use by command line. The next step is to package that program and deploy it to an application server. Some clients program will submit requests to the server who will call the tool that I wrote. Lately, we will add more tools to the server and he has to dispatch the requests to the right tool.
Which application server fits my needs ? I have looked for Tomcat, Jetty and Glassfish but it seems that they are only used for web application.
Is it possible to use those servers in some context different from web context? Which package archive should i use (jar, war) ?
Any advice?
Some clients program will submit requests to the server who will call the tool that I wrote.
The big question is what server-side technology and what communication protocol can you use between the clients and the server. You basically have two major options: HTTP and web services (in that case, consider using either JAX-WS or JAX-RS) or RMI-IIOP and EJBs (in that case, you'll have to use a Java EE compliant server like GlassFish).
I have looked for Tomcat, Jetty and Glassfish but it seems that they are only used for web application.
Not really. As I said, they can also be used for web services oriented applications. And GlassFish can be used for EJBs applications.
Which package archive should i use (jar, war)
The packaging will depend on the type of application you'll write, it's not something that you choose upfront, it's just a consequence. EJBs are packaged in an EJB JAR and typically deployed inside an EAR; Servlet based web services are deployed inside a WAR.
You really need to think about what technology to use first (with the current level of detail, I can't provide more guidance).
Do you even need an application server? There's nothing stopping you from adding the necessary network bindings and deploying it on its own.
Of the servers you mention, you've got 2 different categories: servlet containers and full-stack Java EE servers
Tomcat and Jetty are servlet containers. That doesn't mean that you can only do web stuff with them and you could manually add the required libraries to get a full Java EE server.
Glassfish is a full-stack Java EE server and can be compared with JBoss (both are open source) or the commercial rivals Weblogic and Websphere.
Sometimes this question is simple as the environment you are working in mandates a particular flavour of app server. You should check this first.
If you're not forced to use an app server, I'd ask why you think you need to use an app server?
I don't see why you would want to use tomcat, glassfish or jetty for a command line program.
If it's command-line based, and you want it to run server-side, you could write a little program that allows users to, for instance, telnet to your server, which in turn starts the CLI-application in question, and relays input / output to the client.
You may also want to look into Java Webstart, which makes deployment of new versions a breeze.
Actually we can't answer with so few elements.
- What are you planning to do
- With what technologies
- Where are you planning to host your application (have you got budget?)
- In which language are written the clients (even the future ones)?
- Could clients be on mobile phones (add some technlogy constraints...)
....
It would also be great to know what kind of request the clients will do, and what kind of response the server will provide...
Actually with what you tell us, all those application servers can do what you want...
I have looked for Tomcat, Jetty and
Glassfish but it seems that they are
only used for web application
You could even make a webapplication (servlet) and on the clientside use a httpclient to call that servlet... there are so many options :)
vive Paris!
The company I work for sells a J2EE application that runs on Tomcat, WebSphere, or WebLogic. We have a customer that is trying to decide between Tomcat and WebSphere. They're leaning towards WebSphere because they're concerned that Tomcat has more security holes.
After searching around on the web, I've been unable to find any sites or studies that compare the robustness of the major J2EE application servers from a security standpoint.
Can any of you point me to information comparing app server security holes?
It's interesting that your client is "concerned that Tomcat has more security holes." I wonder if they could list what those holes are? If they can't, it's hearsay and FUD.
I would say that all web servers/servlet engines suffer from the same issues. It's the applications that are deployed on them that represent the real security holes. Cross-site scripting, SQL injection, lack of input validation, exposure of sensitive data due to poor layering and practices - these are all application issues that will be problems regardless of which app server you choose.
My personal opinion is that WebLogic is the best Java EE app server on the market. I don't have first-hand experience with WebSphere, but people that I respect who have tell me that it's a horror show. I've only used Tomcat for local development. It's never failed me, but that's hardly production experience. I have no idea how it scales.
I'd think carefully about Spring's dm Server, based on Tomcat, Spring, and OSGi. I have a feeling that it represents a future direction that all its competitors will be taking.
I'd say use tomcat over WebSphere if at all possible.
I think 99% of security is how you set it all up.
Are you also evaluating the security implications of Apache HTTP Server, IBM HTTP Server, and IIS?
Security involves so much more than just what application server you choose to run your webapp on.
Tomcat security report
Websphere security report (You have to dig into each update to see what was fixed)
In my experience, WebSphere isn't adding anything that isn't spec (and thus somewhat supported on Tomcat). The problem comes when trying to do some more complex security tricks (admin authentication using SecureID or something) you need to dig much deeper. WebSphere tries to put more of that in the UI Console.
That being said, your company should look at testing on Glassfish. It uses Tomcat as it's servlet container, but adds a much better UI for management.
According to this article, WebSphere community addition is no different than Tomcat 5.5 in terms of the servlet engine. In my opinion, this decision should be based on overall features needed rather than perceived "security holes".
Several different surveys have confirmed that Tomcat is running at over 60% of organizations worldwide, including the largest banks. As others have said, Tomcat security is not the issue. What "Plain Vanilla" Tomcat lacks is the console and UI which many enterprises require for access controls, diagnostics, monitoring, alerts and provisioning. Check out Tcat server from MuleSoft. It's 100% Tomcat (no fork), but has the enterprise capabilities for running Tomcat.
I can't say whether one is better than the other as I have never used Tomcat, and you really haven't defined what your security requirements are. Security can be a rather large beast and involve varying levels. So you will need well defined requirements to even determine what Security features are required.
We use Websphere integrated with several other IBM products to provide secure access to our application, which has been working well for us so far. You can look up Webseal and the Tivoli line of products for added security to WebSphere.