Set - 4

Question 6 :

Declarative Exception Handling ?

Answer :

If you have developed web applications long enough, you will realize a recurring pattern emerges: when the backend (e.g. the EJB tier) throws you an exception, you nearly always need to display an error page corresponding to the type of that exception. Sooner or later, you will come up with a mechanism to use a lookup table (e.g. an HashMap) to lookup an error page from the exception class.
Struts 1.1 now provides a similar but more powerful mechanism to declare exception handling. In Struts 1.1, you can declare in the struts-config.xml the associations between an exception class and an exception handler. Using the default exception handler included in Struts, you can also specify the path of the error pages. With this information, Struts will automatically forward to the specified pages when an uncaught exception is thrown from an Action.
Like other facilities in Struts, the exception handlers are pluggable. You can write and define your own handler classes if needed.

Question 7 :

Struts GenericDataSource Just a general question - I'm building an application that will run stand-alone, not in an application server. I need to manage some database connections. Is the struts GenericDataSource a good candidate to do this for me? I basicly just need a connection pool from where I can get connections and then return them to optimize performance.
If this struts class is not a good candidate, can someone recommend a similar pool-manager that is lean and mean and easy to use?

Answer :

Answer 1
The Struts 1.0 GenericDataSource is not a good candidate for a production server. In Struts 1.1, the Commons DBCP is used istead, which is a good candidate for a production server. (You can also use the DBCP in Struts 1.0 by specifying the type and including the Commons JARs.)
Another popular choice is Poolman. It's not under active development, but I believe you can still download it from SourceForge. Poolman is also very easy to use outside of Struts.
Many containers also offer support for connection pools. The one that ships with Resin is quite good. The later versions of Tomcat bundle the Commons DBCP.
Regardless of what pool you use, a good practice is to hide it behind some type of adaptor class of your own (often a singleton), to make it easy to change later. So your classes call your adaptor, and your adaptor calls whichever pool you are using.
A neat and often-overlooked aspect of the Struts DataSource manager is that it supports loading multiple connection pools and giving each a name. So you might have one pool for internal use and another for public use. This way, the public connections can't swap your administrative access to the application. Each pool could also have its own login, and therefore different rights to the underlying database.

Answer 2
int i=1;
with Struts 1.0 and jdbc i'am use GenericDataSource not in struts-xml, but in


then, on my code i have init (struts 1.0 or struts 1.1):

GenericDataSource ng = new GenericDataSource ();
ng.setUser (mprop.getUserBd());
ng.setPassword (mprop.getPasswdBd());
ng.setUrl (mprop.getUrl());
ng.setMinCount (mprop.getMinCount());
ng.setDescription("jdbc OracleDriver");
try {; } catch (java.sql.SQLException e) {

in business logic (or pool) :
Connect cn = ng.getConnection();
it's work.
with struts 1.1 , struts-legacy.jar is necessy for this codes.
it's work.

Question 8 :

Dynamic pages using struts
Is it possible to create the elements of a page(jsp) dynamically based on the results of a data base query, when using struts framework?

Answer :

If you are talking about rendering a report, then sure. The Action iteracts with the business layer/data access objects to acquire the data, and then passes it to the presentation page bundled up as a JavaBean or a collection of JavaBeans. The JSP tags (and other systems) all use reflection, so you can use whatever JavaBean you like.
If you are talking about creating a dynamic data-entry form, then "not so much".
Struts 1.1 supports map-backed ActionForms, but the page still needs to know what input fields are going to be needed. For a truly dynamic input form, I guess the key would be some type of tag that took a map and then generated a column of input fields. (Wouldn't work for everyone, since a lot of forms must be designed just so.) For extra credit, the entry names could (optionally) be resource keys that were used to find the label text.
Text fields would be easy. Others would need some type of JavaBean with properties to tell the tag what to output. A bit of work, but obviously doable.
Of course, you'd probably want to validate the form before passing it back to the database. I imagine it's possible to use the validator in a non-declarative way, but I don't know anyone whose doing that. If you can do a db query to get the information about the form, I imagine you could also do a query to get the information about validations for the form. It would probably be easier to write your own engine than adopt the validator. (It's not really that complicated to do.)
People often ask about "dynamic input forms", but most of us just can't get our head around the use case. It's hard to understand what you do with the dynamic data when it comes back. Most application don't allow you to input or update an arbitrary (e.g. dynamic) set of fields.

Question 9 :

Both JSF and Struts will continue to exist for a while. The Struts community is aware of JSF and is positioning itself to have strong support for JSF. See What about JSTL and JavaServer faces?

Answer :

From a tools perspective, if you look at the support for JSF versus Struts in WebSphere Studio, the Struts tools are focused around the controller aspects. The Web Diagram editor helps build your Struts configuration and the wizards/editors build Struts artifacts. The JSF tools are geared towards building pages, and in essence, hide the JSF framework from you. Expect WebSphere Studio to support both frameworks for a while. As JSF matures, expect to see some of the controller aspects in JSF to become toolable.

Question 10 :

Can you compare the advantages and disadvantages of JSF vs. Struts. Both now, and from what you may know of futures, how and if JSF will evolve into a superior technology vs. Struts? Include how WSAD plays into the comparison if it will help differentiate the two?

Answer :

This is a very popular question these days. In general, JSF is still fairly new and will take time to fully mature. However, I see JSF being able to accomplish everything Struts can, plus more. Struts evolved out of necessity. It was created by developers who were tired of coding the same logic again and again. JSF emerged both from necessity and competition.
Struts has several benefits:
* Struts is a mature and proven framework. It has been around for a few years and deployed successfully on many projects. The WebSphere Application Server admin console is a Struts application.
* Struts uses the Front Controller and Command patterns and can handle sophisticated controller logic.
* In addition to the core controller function, it has many add-on benefits such as layouts with Tiles, declarative exception handling, and internationalization.

There are disadvantages:
* Struts is very JSP-centric and takes other frameworks to adapt to other view technologies.
* Although Struts has a rich tag library, it is still geared towards helping the controller aspect of development and does not give a sense that you are dealing with components on a page. Therefore, it is not as toolable from a view perspective.
* Struts requires knowledge of Javaâ„¢. Its goal was to aid Java developers, but not to hide Java. It does not hide details of the Java language to Web developers that well.
* ActionForms are linked programmatically to the Struts framework. Therefore, to decouple the model, you need to write transfer code or use utilities to move data from Action Forms to the Model on input.

JSF is an evolution of a few frameworks, including Struts. The creator of Struts, Craig McClanahan, is one of the JSF specification leads. Therefore, it is not by accident to see some overlap between Struts and JSF. However, one of JSF's major goals is to help J2EE Web applications to be easily developed using RAD tools. As such, it introduces a rich component model. JSF has several advantages:
* JSF is a specification from Sun® and will be included in future versions of the J2EE specification. All major vendors are pledging strong support for JSF.
* JSF uses the Page Controller Pattern and therefore aids in Page rich applications. Components can respond to event from components on a page.
* JSF has a well-defined request lifecycle allowing for plugability at different levels.
* One powerful example of plugability is building your own render toolkit. The ability to separate the rendering portion from the controller portion of the framework allows for wonderful opportunities of extensibility. Component providers can write their own toolkits to render different markup languages, such as XML or WML. In addition, the render toolkit is not tied to JSP.
* Because JSF has a rich component model, it favors a RAD style of development. I can now build my Web pages using drag and drop technology. In addition, JSF gives me a way to link visual components to back model components without breaking the layering.
JSF has disadvantages:
* JSF is still quite new and evolving. It will take some time to see successful deployments and wide usage. In addition, as vendors write components, they may not do everything you want them to.
* JSF by hand is not easier than Struts. Its goal was more oriented to RAD. Those who prefer to do things by hand (for example, the vi type guy who does not like IDEs) may find Struts easier to develop.
* Struts navigation may be a bit more flexible and adhere to more complex controller logic.