What's the best way to deal with migrating a large application
from Struts to JSF? Is
there any tool
support that can
help?
Answer: This is a complicated task depending on your Struts application.
Because the two frameworks have different goals, there are some challenges. Migrate your response pages first. Keep the Struts
controller and place and forward to JSF pages. Then you can configure Struts
forwards to go through the Faces servlet. Consider
looking at the Struts-Faces framework from Apache. See the framework chapter in
JSF in Action.
How can I 'chain' Actions?
Chaining actions can be done by simply using the
proper mapping in your forward entries in the struts-config.xml file.
Assume you had the following two classes:
/* com/AAction.java */...
public class AAction extends Action
{
public ActionForward
execute(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response) throws
Exception
{
// Do something
return mapping.findForward("success");
}
}
/* com/BAction.java */
...
public class BAction extends Action
{
public ActionForward
execute(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response) throws
Exception
{
// Do something else
return mapping.findForward("success");
}
}
Then you can chain together these two actions with
the Struts configuration as shown in the following excerpt:
...
<action-mappings type="org.apache.struts.action.ActionMapping">
<action path="/A"
type="com.AAction"
validate="false">
<forward name="success" path="/B.do"
/>
</action>
<action path="/B"
type="com.BAction"
scope="session"
validate="false">
<forward name="success" path="/result.jsp" />
</action>
</action-mappings>
...
Here we are assuming you are using a suffix-based (.do) servlet
mapping, which is recommended since module support requires it. When you send
your browser to the web application and name the action A.do
(i.e. http://localhost:8080/app/A.do) it will execute AAction.execute(), which
will then forward to the "success" mapping.
This causes the execution of BAction.execute() since
the entry for "success" in the configuration file uses the .do
suffix.
Of course it is also possible to chain actions programmatically, but the power
and ease of being able to "reroute" your web application's structure
using the XML configuration file is much easier to maintain.
As a rule, chaining Actions is not recommended. If your business classes are
properly factored, you should be able to call whatever methods you need from
any Action, without splicing them together into a cybernetic Rube Goldberg
device.
If you must chain Actions, be aware of the following: calling the second Action
from the first Action has the same effect as calling the second Action from
scratch. If both of your Actions change the properties of a formbean,
the changes made by the first Action will be lost because Struts calls the
reset() method on the formbean when the second Action
is called.
Declarative Exception Handling
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.
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 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 Client.properties
my Client.properties
instanceBd=oraID
userPasswd=xxx/yyyy
maxCount=20
minCount=19
port=1521
driver=oracle.jdbc.driver.OracleDriver
url=jdbc:oracle:thin:@serverName:port:instanceBd
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.setDriverClass(mprop.getDriverClass());
ng.setMaxCount(mprop.getMaxCount());
ng.setMinCount (mprop.getMinCount());
ng.setDescription("jdbc
OracleDriver");
ng.setAutoCommit(true);
try { ng.open(); } 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.
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?
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.
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?
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.
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.
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.
No comments:
Post a Comment