Solution Hacker

Http Proxy Servlet
Both Flex and AJAX have Browser security restriction that can only allow them to access the web server where they originally come from. In order for your Flex and AJAX app to access the web service on the Net, you need to deploy a proxy onto the web server they can access. In PHP, you can use this php proxy (code). In Java, you can use this proxy servlet (code).

Shell Servlet
If you want to issue commands to the web server and tell it to run this command. You can do that with Shell Servlet. With this, you can do Web Administration online, even through WAP phone. 

Reference:

http://www.servletsuite.com/servlets.htm

Web application events
In  servlet 2.3 spec, web application events are introduced that give you greater degree of control over your web application. The two important application events are:

1. Application startup and shutdown
2. Session creation and invalidation

As their names suggest, application startup event occurs when your web application is first loaded and started by the Servlet container and application shutdown event occurs when the web application is shutdown.

Session creation event occurs every time a new session is created on the server and similarly session invalidation event occurs every time a session is invalidated. To make use of these web application events and to do something useful you’ll have to create and make use of special “listener” classes.

Listener
These are simple Java classes which implement one of the two following interfaces:

1. javax.servlet.ServletContextListener
2. javax.servlet.http.HttpSessionListener

If you want your class to listen for application startup and shutdown events then implement ServletContextListener interface. If you want your class to listen for session creation and invalidation events then implement HttpSessionListener interface.

ServletContextListener – This interface contains two methods :
[code]]czoxMTI6XCJwdWJsaWMgdm9pZCBjb250ZXh0SW5pdGlhbGl6ZWQoU2VydmxldENvbnRleHRFdmVudCBzY2UpOw0KcHVibGljIHZvaWR7WyYqJl19IGNvbnRleHREZXN0cm95ZWQoU2VydmxldENvbnRleHRFdmVudCBzY2UpO1wiO3tbJiomXX0=[[/code]

HttpSessionListener – This interface contains two methods also:
[code]]czoxMDA6XCJwdWJsaWMgdm9pZCBzZXNzaW9uQ3JlYXRlZChIdHRwU2Vzc2lvbkV2ZW50IHNlKTsNCnB1YmxpYyB2b2lkIHNlc3Npb257WyYqJl19RGVzdHJveWVkKEh0dHBTZXNzaW9uRXZlbnQgc2UpO1wiO3tbJiomXX0=[[/code]

Example of usage – use HttpSessionListener to count how many active session[code]]czo5MzpcIg0KaW1wb3J0IGphdmF4LnNlcnZsZXQuaHR0cC5IdHRwU2Vzc2lvbkxpc3RlbmVyOw0KaW1wb3J0IGphdmF4LnNlcnZsZXR7WyYqJl19Lmh0dHAuSHR0cFNlc3Npb25FdmVudDtcIjt7WyYqJl19[[/code][code]]czozNzA6XCJwdWJsaWMgY2xhc3MgU2Vzc2lvbkNvdW50ZXIgaW1wbGVtZW50cyBIdHRwU2Vzc2lvbkxpc3RlbmVyIHsNCnByaXZhdGV7WyYqJl19IHN0YXRpYyBpbnQgYWN0aXZlU2Vzc2lvbnMgPSAwOw0KLyogU2Vzc2lvbiBDcmVhdGlvbiBFdmVudCAqLw0Kw4LCoHB1YmxpYyB2b3tbJiomXX1pZCBzZXNzaW9uQ3JlYXRlZChIdHRwU2Vzc2lvbkV2ZW50IHNlKSB7DQrDgsKgIGFjdGl2ZVNlc3Npb25zKys7DQrDgsKgfQ0KLyoge1smKiZdfVNlc3Npb24gSW52YWxpZGF0aW9uIEV2ZW50ICovDQrDgsKgcHVibGljIHZvaWQgc2Vzc2lvbkRlc3Ryb3llZChIdHRwU2Vzc2lvbkV7WyYqJl19dmVudCBzZSkgew0Kw4LCoCBpZihhY3RpdmVTZXNzaW9ucyAmZ3Q7IDApDQrDgsKgIGFjdGl2ZVNlc3Npb25zLS07DQrDgsKgfVwiO3tbJiomXX0=[[/code][code]]czo3ODpcInB1YmxpYyBzdGF0aWMgaW50IGdldEFjdGl2ZVNlc3Npb25zKCkgew0Kw4LCoCByZXR1cm4gYWN0aXZlU2Vzc2lvbnM7DQp7WyYqJl19w4LCoH0NCn1cIjt7WyYqJl19[[/code]Register listener to the web application[code]]czo2NzA6XCINCiZsdDshLS0gV2ViLnhtbCAtLSZndDsNCiZsdDs/eG1sIHZlcnNpb249XCIxLjBcIiBlbmNvZGluZz1cIklTTy04ODU5LTF7WyYqJl19XCI/Jmd0Ow0KJmx0OyFET0NUWVBFIHdlYi1hcHANCsOCwqBQVUJMSUMgXCItLy9TdW4gTWljcm9zeXN0ZW1zLCBJbmMuLy9EVEQgV2Vie1smKiZdfSBBcHBsaWNhdGlvbiAyLjMvL0VOXCINCsOCwqBcIjxhIGhyZWY9XCJodHRwOi8vamF2YS5zdW4uY29tL2oyZWUvZHRkcy93ZWItYXBwXzJ7WyYqJl19LjMuZHRkXCI+aHR0cDovL2phdmEuc3VuLmNvbS9qMmVlL2R0ZHMvd2ViLWFwcF8yLjMuZHRkPC9hPlwiJmd0OyZsdDt3ZWItYXBwJmd0e1smKiZdfTsmbHQ7IS0tIExpc3RlbmVycyAtLSZndDsNCsOCwqAmbHQ7bGlzdGVuZXImZ3Q7DQrDgsKgw4LCoCZsdDtsaXN0ZW5lci1jbGFzcyZ7WyYqJl19Z3Q7DQrDgsKgw4LCoGNvbS5zdGFyZGV2ZWxvcGVyLndlYi5saXN0ZW5lci5TZXNzaW9uQ291bnRlcg0Kw4LCoMOCwqAmbHQ7L2xpc3tbJiomXX10ZW5lci1jbGFzcyZndDsNCsOCwqAmbHQ7L2xpc3RlbmVyJmd0Ow0Kw4LCoCZsdDtsaXN0ZW5lciZndDsNCsOCwqDDgsKgJmx0O2xpe1smKiZdfXN0ZW5lci1jbGFzcyZndDsNCsOCwqDDgsKgY29tLnN0YXJkZXZlbG9wZXIud2ViLmxpc3RlbmVyLkFwcGxpY2F0aW9uV2F0Y2gNCsN7WyYqJl19gsKgw4LCoCZsdDsvbGlzdGVuZXItY2xhc3MmZ3Q7DQrDgsKgJmx0Oy9saXN0ZW5lciZndDsmbHQ7L3dlYi1hcHAmZ3Q7XCI7e1smKiZdfQ==[[/code]

Spring Events
Spring provides a simple mechanism for sending and receiving events between beans. To receive an event, a bean implements ApplicationListener, which has a single method:
[code]]czo1NTpcInB1YmxpYyB2b2lkIG9uQXBwbGljYXRpb25FdmVudChBcHBsaWNhdGlvbkV2ZW50IGV2ZW50KTtcIjt7WyYqJl19[[/code]
To publish events to listeners you call the publishEvent() method the ApplicationContext. This will publish the same event to every listener in the context. Event listeners receive events synchronously. This means the publishEvent()  method blocks until all listeners have finished processing the event. it is possible to supply an alternate event publishing strategy via a ApplicationEventMulticaster implementation. Furthermore, when a listener receives an event it operates inside the transaction context of the publisher, if a transaction context is available.

You can be both listener or publisher. If it is a publisher, it needs to have access to the ApplicationContext. This means that beans will have to made aware of the container that they are running in. You can create your own custom event via extends ApplicationEvent class. In addition to events that are published by other beans, the Spring container itself publishes a handful of events during the course of an application’s lifetime. These application events include:

1. ContextClosedEvent – publish when the application context is closed
2. ContextRefreshEvent – publish when the application context is initialized or refreshed
3. RequestHandledEvent – publish when a request is handled

Put them together
Look at how acegi publish session creation/destroy events to the bean(s) listening on this. It has HttpSessionEventPublisher class that implements HttpSessionListener. So, web container will trigger its sessionCreated and sessoinDestroy methods when session is created an destroyed. Within these methods, the publisher will use ApplicationContext to publish its own HttpSessionCreatedEvent and HttpSessionDestroyedEvent to all the spring bean(s) listening on these. (code)

Reference
http://java.sys-con.com/read/171482_1.htm (Acegi)
http://www.acegisecurity.org/articles.html (Acegi)

How Spring MVC works?
Many people suggest me to use Spring MVC instead of Struts. I decide to take a quick look at that. Before I give you a comparsion chart, I think it is good to outline the core mechanism that Spring MVC uses to achieve the goal. Here it is:

• A dispatcher servlet, which will intercept incoming requests.
• A configuration that instructs the web container to route requests to the dispatcher servlet (ie. a servlet mapping)
• Controllers (the C in MVC) that can perform the business logic and route to particular views (the V) perhaps conveying information models (the M).
• A way for the dispatcher servlet to know which URLs to map to which controllers – called a url mapping (Decouple servlet from controller)
• A way to determine, when a controller has done its job, how to get to the view – called a view resolver  (Decouple controller from view)

Now you know the heart of Spring MVC. It is really similar to how Struts works : ActionServlet -> Action (logic) -> View with Model (struts-mapping.xml holds the information of how to wire them up).

Reference

http://www.devx.com/Java/Article/29208/1954?pf=true

How can you implement the page flow for airline booking system with Struts alone? Before we go deep on the new technology, lets try to tackle it the old way. First, take a look at the page flow below first.

To implement a multi-step page flow in Struts,  we can chain individual actions together through the various views. Action URLs to process different events like “back” or “submit” are hard-coded into each view. Some form of ad-hoc session storage is used to manage flow state. Redirect after post is used to prevent duplicate submissions, etc. Although this is a simple and functional approach, it has a major disadvantage: the overall page flow of the web application is not clear from looking at the action definitions in the struts-config.xml file. That is to say, the flow is not explicitly defined but implicitly hide in your struts-config.xml. Besides, flexibility also suffers since actions and views cannot be easily reused.

This is where Spring Web Flow comes in, allowing you to represent the page flow of a web application in finite state machine. 

In finite state machine, a web flow is composed of a set of states. A state is a point in the flow where something happens; for instance, displaying a view (ie. ViewState) or executing an action (ie. ActionState). Each state has one or more transitions (ie. event) that are used to move to another state. In Spring Web Flow, an ActionState executes an action when entered. That action returns the logical result of its execution, and that result is mapped to a state transition. When an ViewState is entered, it will cause the executing flow to pause, and returns control back to the client with instruction to render the configured view. Later, after some user think-time, the client signals an event describing what action the user took. That resumes the flow, and the event that occurred is mapped to a state transition, which takes the user to the next step in the flow.

The state machine model can be reused anywhere, including environments like Struts, Spring MVC, Tapestry, JSF, and even Portlets. Besides, The page flow in a web application is clearly visible by looking at the corresponding web flow definition (in an XML file or Java class). The page flow now is clearly and explicitly specified in web flow definition (either in XML file or Java class). And it is self-contained and reusable in multiple situations. On top of that, it has a clear, observable lifecycle that is managed for you automatically.

Q & A

Q1) “… since the executing flow is paused when a ViewState is entered, and control is returned to the browser, how is the same flow picked up and resumed on subsequent events?”  The answer is the client tracks the unique id of the executing flow, and provides it as input when the next event is signaled. This is typically done using a hidden form field. This is the concept of continuation.

<input type=”hidden” value=”<c:out value=”${flowExecution.id}”/>”>

Q2) “What about decision state and subflow state?”  Decision state decisions what transition to take with conditional logic embedded. For a flow that is independent from the main flow, you can model it as subflow. When a subflow state is entered, a child flow is spawned. The parent flow is suspended until the child flow ends. This lets you view your application as a set of self-contained modules – flows – that you can easily embed in multiple situations in a consistent manner. By the way, you can pass information to the subflow.

Q3) “What about the end states of the state machine?”  When an end state is entered, the active flow session terminates. Upon termination, all resources associated with the flow are cleaned up for you automatically. So, a new scope “flow” is introduced that spans multiple requests but shorter than a session.

Q4) “When should I use web flow?”  It should be noted that Spring Web Flow is not a one-size-fits-all solution. As you’ve seen, it’s a stateful system that automates the management of page flows that drive business processes. It should not be used when simpler, stateless solutions are more appropriate. For example, it should not be used where sites require free navigations, where the user is free to “click around” anywhere they please. Spring Web Flow is designed to power controlled navigations, where the user is guided through a process with a clear business goal and lifecycle.

Reference

TheServerSide Spring Web Flow Article

Spring Web Flow Architecture

Spring Web Flow – Practical Introduction

Official Spring Web Flow Site