We Keep Coding

Java ee web application with no servlets, how it's possible?

First of all i'm a newbie in java-ee. I'm working as a java developer and where i work, the company has a web application with java-ee on the frontside and cache(intersystem) at the backend.
Is it possible that the web application may not have any servlet class? I only can find httpservlet imports.
From my understanding, java-ee application always work with servlets with his get/post/init method's. Am i right?
Also,I really don't get the difference between servlets and jsp's.
For the moment, I know that the application is using maven,struts2,jsp,hibernate,taglib...
(Sorry for my english,I try my best)

You are not right, but not totally wrong either. Java-ee application mostly works with servlet but there is also others mechanisms involve like Filter and Listener.
Filters are used to manage request and response before and after servlets are called. For example you could use one to always redirect to a login page if there is no session.
Filter documentation
Listeners are used for listening to events in a web container, like Session creation.
I don't really know Struts2 but with a little of research i found out that it works with a front filter who is interpreting request and dispatch them to your Action class.
Some infos about Struts
A lot of Framework/Apis use a similar system it's actually the design pattern Front Controller, springMVC and Jersey for example both work with an unique front servlet
As for the difference between JSP and servlet, JSPs are just file that are compiled by the web server as servlet.

Java web application event

I am writing a code for a web application using Java and Apache Tomcat. The web application involves an authentication system. My question: is there any way that I can execute a certain code every time my web application receives a request. So instead of adding the code to check if the user is logged in every page, the code gets called automatically when the application receives a request.
Thanks!

You have at least a couple of options
make all your servlets extend the same base class and put the shared code in the service method
use a J2EE filter to intercept the message and put the shared code there
I'd go for the second of these options, providing that it's not too much of a code restructure. Authentication is a cross-cutting concern and is exactly what the Filter framework was designed to handle.

If I understand you correctly you should take a look on HTTP Filter.
You should implement interface javax.servlet.Filter, register you filter in web.xml using <filter> tag and your filter will be called on each call of URL you mapped to this filter.

You could use filter to control the event call.
You also can use tomcat container's background thread follow the event every 5 min.

Form-based authentication is for you.

Architecture of AJAX MVC application

I've written the bare bones of my application using the MVC pattern. I don't currently have any AJAX functionality in my application but I was looking for suggestions on how I would change the architecture of my application to achieve this, to that end I'll try my best to describe my current architecture:
I have a controller servlet "controller.java" which reads the servlet path i.e. request.getServletPath() to determine the action required
I have a number of different Enterprise Java Beans (EJB 3.1) which handle the business logic and which are called by my controller servlet depending on the action requested
I have a number of views which relate to different aspects of my application to which the request is forwarded (by the controller servlet) based on the action requested (i.e. request.getRequestDispatcher(url).forward(request, response);)
I understand that the current architecture could support AJAX functionality (by matching a pattern from my "controller.java" servlet) but I'm getting to the point where I have a huge number of actions supported by my controller and it's getting messy.
Does anybody have any suggestions?
Is there a standard pattern for doing this? I'm trying to stay free of any frameworks just now as I'm a relative beginner! :-)
Thanks

If your controller supports a huge number of actions - it's where you need refactoring. In general your architecture looks correct, if the number of actions is reasonable (up to 10, I would say) per each controller.
One possible way of refactoring is to group controllers into modules.

You can check for ajax requests as follows:
boolean ajax = "XMLHttpRequest".equals(request.getHeader("X-Requested-With"));
and then handle the kind of response accordingly. I.e. returning the view ID which is to be used in a forward or redirect, or returning some JSON which is then to be written to response body, or returning a special View object which contains this kind of information. Given this basic MVC example, it should not be that hard to expand it with ajax support.

Same idea with BalusC.
We have an MVC app that runs by itself. Now to add AJAX functionality we added JQuery and used jqGrid in the presentation layer. It communicates with the backend via AJAX. If we remove the JQuery and jqGrid, we still have a fully running MVC app.
I've put a demo of that at http://krams915.blogspot.com/2010/12/jqgrid-and-spring-3-mvc-integration. Here we integrated Spring MVC 3 and jqGrid/JQuery

Using a Servlet for a non-servlet application

I know 'normal' Java, but am new to the world of servlets, containers etc. Because of that I am not sure which approach is most sensible.
Situation: I have created a Servlet that receives information and stores it in a database. This database gets read by other applications.
Now what I need is an application that receives the exact same information and stores it in the same database. However this new application needs to pull this information from another server (I'll be using httpClient for this) instead of it being pushed to it. Both applications will co-exist.
For this new applications I see the following two options:
Make a stand alone application. For this I can copy paste a lot of the existing back-end code, but I will need to make some modifications (the servlet container offers a context, easy database connection pooling etc.) Further I might need to use some wrapper so this can work like a proper daemon that I can start, but also gracefully stop/restart etc.
Make the new application part of a Servlet. That is: just start a new Thread in the init() of the servlet that will run the new application. This would allow me to reuse all the backend code I already have, without needing to rewrite any of it. I only need to write the code that does the HTTP-GET requests to the other server. With this approach it will also be easier to start and stop the service, because I can use the Servlet container for that.
Some info about the project: the backend code that parses and writes the data to the database has a few threads, but is not very complicated. Writing the code for the original servlet was about one week of work. With the existing code base I feel this new application should probably be 1, 2 days of work max.
The way I see it option 2 is easier. But it feels a bit like I would 'abuse' servlets.
So my question is: Aren't servlets for applications that should handle requests, instead of applications that make request? Are there some huge drawbacks I don't see here? Which option would make most sense?
tl;dr: Can I write an application that doesn't serve requests as a Servlet?

Don't copy and paste code.
Write a re-usable class/module which handles storing the information in the database which can be used by both 1) the servlet and 2) standalone code which retrieves information from a HttpClient.
This way the same piece of code handles the same logic - how to store the information in the database - whether the information in question is being pushed to a servlet or being fetched from a remote URL.

Servlet containers are thread-managed environments. In general, don't start your own threads in a servlet, or bad things can happen... starting and stopping the application context, for example - the appserver doesn't know about the threads you might have started so won't stop them with your app... (More detail in this SO question)
I would try to extract the logic I need from the servlet into classes that don't depend on the Servlet API, and redesign the servlet to make use of these classes. (Refactoring). The servlet API, as you note, is all about receiving requests and sending responses.
I can re-use the logic in my new non-servlet classes anywhere I like, including a non-servlet part of the application that polls out pull that info.

You could use, but you shouldn't, it is a very poor design.
If you have two different ways to access your application (one through servlets and other as standalone), you should create at leats three classes:
One class that does all the work relating database, etc.
One servlet that calls the first class
One stand alone class (or whatever) that calls the first class
In this way, you don't copy/paste, and you can reuse your code (even you can have a third way to call the class that do the heavy work

If you want to reuse code, have this code as part of a "Service" or "Business Logic" layer that will be used both by your servlet and non servlet application.
Package the code as a jar and use it in both applications.

ICEfaces: How to disable send-receive-updates mechanism for some forms

I am quite new to ICEfaces but already have experience with JSF/Facelets and the Java EE in general.
Currently, I am not using to much of ICEfaces except some utility tags like outputStyle and outputDeclaration, but even this is really nice to have.
Even though I plan on using some AJAX functionality later, I have some h:forms (or ice:forms) which I would like to send as normal JSF POST requests, without going via /block/send-receive-updates. The reason is, that I want to use a filter, which acts on the requested URI, which is impossible if everything is sent to /block/send-receive-updates.
Is there some way to do this?
Edit: To clarify what I want to do:
The web site we are developing consists of publicly available pages and some which only registered members can access. The standard FORM-based security mechanism as defined in the servlet standard is pretty inflexible, as it only allows to define a single login page which is shown, when someone wants to access some restricted content. Because we also want to user to be able to log in by using a small login form visible on every page, we developed a filter, which handles authentication and authorization almost like the web container. It redirects to a custom login page if the user is not authenticated/authorized, but also allows to authenticate a user from a backing-bean. To make it work almost transparently it wraps the HttpServletRequest to supply the Principal and the user roles.
When the filter redirects to the custom login page it saves the current request to "replay" it later, when the user has been successfully authenticated. To do this, the filter has to be able to detect, if a POST request came from the login page (and thus if the user is now authenticated/authorized). But if every POST is going via /block/send-receive-updates this doesn't work anymore.
Of course I could exclude the login page from being handled by ICEfaces, but this would mean I couldn't use any ICEfaces/AJAX on the login page.

This might not be the best way of doing this, but it might be a way. I'll assume, for the sake of argument, that your header holds your extra login form. If you were to make your header in either a seperate frame or in the main layout page and imbed your JSF pages into an iframe, this might work. The idea being that since it's being rendered as a seperate page, you can handle it in a seperate way.
Also, there might be a different way of handling your security that would make this more IceFaces-y. Perhaps, when you hit the filter and it determines that you're not logged in, it should create a bean (probably session) which holds the information from the original request (URL, parameters, etc.) and the sends you on to the login page. The login page does its thing, adding your security stuff, then uses the information in that session bean to force a redirect to your new page. You can use the FacesContext to get your HttpContext and do a redirect. You'd probably need to play around with the redirect to add any appropriate parameters. Lastly, you should get rid of the session bean.
Finally, I know that there are a couple of Frameworks (Spring WebFlow, springs to mind) that will save your request state, let you do the login, and redirect you back to where you were going in the first place pretty seamlessly (which, reminds me, I think Seam can do this too. Probably Orchestra and your other frameworks as well.)
Hope this helps!

I've been using IceFaces for nearly a year now and haven't yet come across any way of submitting the form without going via send-receive-updates. But I'm curious, you say "I plan on using some AJAX functionality later". The point of IceFaces is that it pretty much transparently adds AJAX to your JSF app. It's an "all or nothing" kind of thing - any page you have which uses IceFaces will use AJAX.
The only thing I can think of you could do is not use IceFaces for the pages you want to use POST requests on - i.e. you could map IceFaces pages to *.iface, but normal JSF to *.faces.
Alternatively, there may well be some other way of accomplishing what you want to do with filters.