We Keep Coding

Ping implementation approach for web application

I've a java based web application running on Tomcat and it uses spring framework. I need to expose a ping URL to check whether the application is up and running. I've considered the following implementation approaches and all of them seems to work well when I tried them. However, I could not make up my mind whether one approach is better than another. Does it matter which path I take? Could someone advise which approach is better and why?
Create a web page and modify web.xml to redirect the url to the jsp page.
Create a REST service using Spring-WS
Create a servlet and return response

Use anything you want :-) But notice, that both Spring-WS and JSP are a little heavier (really not a meaningful reason here) than servlets. If you already have REST API to your aplication, use Spring-WS, if you render pages through JSP, use JSP. Or if you use none of these, write a plain servlet.

Since you are using Spring, assuming you use Spring MVC, you can just add another controller mapped to a certain URL which would be responsible for returning a status.
Solution 1 might not work depending on your requirement since a jsp page might work even if the rest of the app does not since it is not part of spring config.

Send notifications from Java servlet to HTML pages

I have a Java servlet from which I need to send few notifications to the HTML page before I send the final response (which is a PDF file).
Basically I need to keep the user updating on steps I am performing while generating the PDF for them.
I guess, one way could be set various attributes using HttpSession and have them printed using JS. But I don't know how to do that dynamically without loading the page again.
Any idea on how can this be done? I am kind of new to JSP and servlets.

There are two ways:
AJAX polling - you send ajax requests periodically, and the server responds. The page does not get refreshed. Check jQuery for an easy way to make ajax calls
Comet - that's an umbrella term for what you are trying to do. Usually it means keeping an open channel with the server. There are many ways to implement comet (including the option above), but in Java, on the server side, there are two things to check:
Servlet 3.0 asynchronous support
Atmoshphere - chooses the best underlying mechanism provided by the container, which includes the async support above

You should probably look forward to use some implementation of COMET (with js library of choice).

If your html code is allowed to use html5 features, you could also use websockets

Java HTTP Proxy

I am working on a project where we'd like to pull content from one of our legacy applications, BUT, we'd like to avoid showing the "waiting for www.somehostname.com/someproduct/..." to the user.
We can easily add another domain that points to the same server, but we still have the problem of the someproduct context root in the url. Simply changing the context root is not an option since there are hundreds of hard coded bits in the legacy app that refer to the existing context root.
What I'd like to do is be able to send a request to a different context root (Say /foo/bar.do), and have it actually go to /someproduct/bar.do, (but without a redirect, so the browser still shows /foo/bar.do).
I've found a few URL rewriting options that do something similar, but so far they seem to all be restricted to catching/forwarding requests only to/from the same context root.
Is there any project out there that handles this type of thing? We are using weblogic 10.3 (on legacy app it is weblogic 8). Ideally we could host this as part of the new app, but if we had to, we could also add something to the old app.
Or, is there some completely different solution that would work better that we haven't though of?
Update: I should mention that we already originally suggested using apace with mod_rewrite or something similar, but management/hosting are giving the thumbs down to this solution. :/
Update 2 More information:
The places where the user is able to see the old url / context root have to do with pages/workflows that are loaded from the old app into an iframe in the new app.
So there is really nothing special about the communication between the two apps that client could see, it's plain old HTTPS handled by the browser.

I think you should be able to do this using a fairly simple custom servlet.
At a high level, you'd:
Map the servlet to a mapping like /foo/*
In the servlet's implementation, simply take the request's pathInfo, and use that to make a request to the legacy site (using HttpUrlConnection or the Apache Commons equivalent).
Pipe the response to the client (some processing may be necessary to handle the headers).

Why not front weblogic with Apache.
This is a very standard setup and will bring lots of other advantages also. URL rewriting in apache is extremely well supported and the documentation is excellent.
Don't be put off by the setup it's fairly simple and you can run apache on the same box if necessary.

Using Restlet would allow you to do this. The Redirector object can be used. See here and here for example.

If you instead serve out a JSP page you can use the tag to do the request server side.
Then the user will not even know that the resource was external.
http://java.sun.com/products/jsp/syntax/1.2/syntaxref1214.html

a bit more context for the API the client is working against would help here to give a solution that could work. Are you trying to provide a complete new API totally different from the legacy Java EE app? What artifact is serving the API (Servlet, EJB, REST service)?
If you have the API provided by a different enterprise application then I suppose you simply use a Pojo class to work as a gateway to the legacy app wich of cause can then be reachable via another context root than the new service app. This solution would assume you know all legacy API methods and can map them to the calls for the new API.
For a generic solution where you don't have to worry about what methods are called. I am curious if the proxy approach could really work. Would the user credentials also be served correctly to the legacy system by URL re-writing? Would you have to switch to a different user for the legacy calls instead of using the origin caller? Is that possible with URL re-writing. Not sure if that could work in a secure context.
Maybe you can provide a bit more information here.

AJAX Using a REST API Without Server Side Framework

I am building a REST based API (Read only) for accessing services of my application. I plan on writing a web application that will leverage these APIs to provide basic information on the status of the application. I plan to use AJAX (using jQuery) to show the information.
Originally I planned on using Grails, Spring MVC, RoR or one of the web frameworks to handle the back end of my application. The REST APIs I will be providing though are already built on a stanalone REST framework so I would only be leveraging the web framework for the core application and not the business logic. In the future, I might need the server side framework to handle other tasks but for now most of the work is done in the REST APIs.
My question is, should I bother with using a web application framework on the server side? I should be able to make all the API calls I need from AJAX directly from the browser. I cannot think of much I would need to do on the server side. Would it make sense to have the application be standard HTML + AJAX + REST?

Its hard to say without actually knowing more about your current setup. This is what your situation sounds like:
You already have an app ready to go with all of the business logic contained. Sounds like its written in Java?
You already have the services written and exposed through a REST api using some other standalone framework. Meaning that if you wanted to, you could access the data right now with the browser without any extra work.
You have not yet built the web application, but when you do, it will get all of its content from the REST api using XHR and jquery. I say that, because otherwise, I would think that you would already be using some kind of framework to generate the other content.
If I am correct in my assumptions, then I would say that you have no need for an additional framework layer. Grails, RoR, SpringMVC my use ajax, and aid in exposing REST services, but the bulk of what they provide is an easy way to make an application that must generate html on the server, deal with form submissions, and handle sessions in a request/response cycle. It doesn't really sound like you'll be doing any of that, and it will likely make your app more complicated.
If you did at some point need the things that rails etc. provides, I would say that you may not need to use rails to expose the rest apis you have now. You could use rails just for what you need, and continue to use what you have for the REST api.

Well, the AJAX calls need to pull data from a server somewhere. If the goal is to avoid a complicated setup on the server side, CherryPy can keep the server side code VERY small.
I've written a simple exapmle below. The first class would be where you put the logic for your ReST API. The code below the class is all you need to get the server up and running.
Install Python 2.6, save the code below to restExample.py. Then in your command line run the python file by doing "python restExample.py". Point your browser to http://localhost:8080/blog/999 and see some JSON come back.
import cherrypy
import json
# Create the controller
class Blog_Controller(object):
def get(self, entryID):
cherrypy.response.headers['Content-Type'] = 'application/json'
return json.dumps({'title':'Entry Title from DB', 'entry_text': 'Text From DB'})
def update(self, entryID, titleFromPOSTFormInput, textFromPOSTFormInput):
# Update DB with passed in arguments. entryID comes from URL,
# other two entries come from POST
cherrypy.response.headers['Content-Type'] = 'application/json'
return json.dumps({'success':True})
# Setup URL routes
d = cherrypy.dispatch.RoutesDispatcher()
d.connect(name='blog_entry', route='blog/:entryID', action='get',
controller=Blog_Controller(),
conditions={'method': ['GET']})
d.connect(name='blog_entry', route='blog/update/:entryID', action='update',
controller=Blog_Controller(),
conditions={'method': ['POST']})
config = { '/' : { 'request.dispatch': d } }
cherrypy.tree.mount(root=None, config=config)
# Start the webserver
engine = cherrypy.engine
try:
engine.start()
except:
sys.exit(1)
else:
engine.block()

It sounds like this might be a good use case for GWT with Restlet.

Forgive me for tooting my own horn, but if you are doing AJAX REST stuff with jQuery, you should probably check out my JSON-REST plugin:
http://plugins.jquery.com/project/rest
If you are getting XML back, then this won't be as useful, but you may still be able to adapt some of the code to your needs.

Creating a REST webserver with security

I am very new to creating webservers - and I have had several goes at trying to understand them and write a quick webserver, but it's never quite 'clicked'. At the moment I am under the impression that REST would be most suitable for my purposes (I will explain later).
Can anyone either show me a basic code example in Java (using Tomcat Apache) or a tutorial resource to show how a webserver:
Can be used for security - i.e. pass in some kind of value to identify the client - from their the webserver will either deny or grant access to the client dependant on some criteria - maybe a lookup list.
Once the client is successfully accepted they will be allowed to pass in some more values to the webserver that will be used to write a row in a database table.
Many thanks.
PS - I would have thought there might have been soemthing that comes with Eclipse Ganymede? If someone can confirm?

The best way to write restful resources in Java is via the JAX-RS standard. So I'd recommend you download Jersey which is the JAX-RS reference implementation and check out its examples; its got lots of them. Take an example for a spin then try hacking it to do what you like.
BTW JAX-RS can be run inside any Servlet engine - you just build a WAR and deploy it (there are examples in the Jersery samples) - though Jersey also comes with a small lightweight web server you can use too which is a little easier to use - again there are examples in the distro of this.

I would also suggest that you look at Restlet