>> Friday, June 17, 2011
Why is it called Struts?
It's a reference to struts in the architectural sense, a reminder of the nearly invisible pieces that hold up buildings, houses, and bridges.
Do I have to credit Struts on my own website?
You need to credit Struts if you redistribute your own framework based on Struts for other people to use. (See the Apache License for details.) But you do not need to credit Struts just because your web application utilizes the framework. It's the same situation as using the Apache HTTPD server or Tomcat. Not required if its just running your web site.
Where can I get a copy of Struts?
The best place to download Struts is at struts.apache.org. The nightly builds are very stable, and recommended as the best place to start today.
How do I install Struts?
To develop applications with Struts, you can usually just add the Struts JAR file to your Java development environment. You can then start using the Struts classes as part of your own application. A blank Struts application (in the webapps directory, open struts-blank.war) is provided, which you can just copy to get a quick-start on your own brainchild.
Since the full source code for Struts is available, we also provide complete instructions for compiling your own Struts JAR from scratch. (This is actually easier than it looks!)
Your Struts application can usually be deployed using a standard WAR file. In most cases, you simply deposit the WAR file on your application server, and it is installed automatically. If not, step-by-step installation instructions for various servlet containers are available.
When do I need "struts.jar" on my classpath?
When you are compiling an application that uses the Struts classes, you must have the "struts.jar" on the classpath your compiler sees -- it does not have to be on your CLASSPATH environment variable.
Why is that an important distinction? Because if you are using a servlet container on your development machine to test your application, the "struts.jar" must not be on your CLASSPATH environment variable when running the container. (This is because each Web application must also have their own copy of the Struts classes, and the container will become confused if it is on the environment path as well.)
There are several general approaches to this issue:
* Use ANT for building your projects -- it can easily assemble classpaths for the compiler. (This is how Struts itself is built, along with Tomcat and most other Java-based projects).
* Use an IDE where you can configure the "class path" used for compilation independent of the CLASSPATH environment variable.
* Use a shell script that temporarily adds struts.jar to the classpath just for compilation, for example javac -classpath /path/to/struts.jar:$CLASSPATH $@
Does Struts include its own unit tests?
Struts currently has two testing environments, to reflect the fact that some things can be tested statically, and some really need to be done in the environment of a running servlet container.
For static unit tests, we use the JUnit framework. The sources for these tests are in the "src/test" hierarchy in the source repository, and are executed via the "test.junit" target in the top-level build.xml file. Such tests are focused on the low-level functionality of individual methods, are particularly suitable for the static methods in the org.apache.struts.util utility classes. In the test hierarchy, there are also some "mock object" classes (in the org.apache.struts.mock package) so that you can package up things that look like servlet API and Struts API objects to pass in as arguments to such tests.
Another valuable tool is Struts TestCase which provides a useful harness for Action classes that can be used with JUnit or Cactus.
If the framework doesn't do what I want, can I request that a feature be added?
First, it's important to remember that Struts is an all-volunteer project. We don't charge anyone anything to use Struts. Committers and other developers work on Struts because they need to use it with their own applications. If others can use it too, that's "icing on the cake". If you submit a patch for a feature that a Committer finds useful, then that Committer may choose to volunteer his or her time to apply the patch. If you just submit an idea without a patch, it is much less likely to be added (since first someone else has to volunteer their time to write the patch).
We are grateful for any patches, and we welcome new ideas, but the best way to see that something gets added to the framework is to do as much of the work as you can, rather than rely on the "kindness of strangers". Worst case, you can apply the patch to your copy of Struts and still use the feature in your own application. (Which is what open source is ~really~ all about.)
What's the difference between Struts and Turbine? What's the difference between Struts and Espresso?
If you are starting from scratch, packages like Turbine and Espresso can be very helpful since they try to provide all of the basic services that your team is likely to need. Such services include things like data persistence and logging.
If you are not starting from scratch, and need to hook up your web application to an existing infrastructure, then "plain vanilla" Struts can be a better choice. The core Struts framework does not presuppose that you are using a given set of data persistence, presentation, or logging tools. Anything goes =:0)
Compared to other offerings, Struts endeavors to be a minimalist framework. We try leverage existing technologies whenever we can and provide only the missing pieces you need to combine disparate technologies into a coherent application. This is great when you want to select your own tools to use with Struts. But, if you prefer a more integrated infrastructure, then packages like Turbine or Espresso (which uses Struts) are perfectly good ways to go.
See also
* < http://www.mail-archive.com/struts-user@jakarta.apache.org/msg03206.html >
* < http://www.mail-archive.com/general@jakarta.apache.org/msg00495.html >
* < http://jakarta.apache.org/velocity/ymtd/ymtd.html >
It's a reference to struts in the architectural sense, a reminder of the nearly invisible pieces that hold up buildings, houses, and bridges.
Do I have to credit Struts on my own website?
You need to credit Struts if you redistribute your own framework based on Struts for other people to use. (See the Apache License for details.) But you do not need to credit Struts just because your web application utilizes the framework. It's the same situation as using the Apache HTTPD server or Tomcat. Not required if its just running your web site.
Where can I get a copy of Struts?
The best place to download Struts is at struts.apache.org. The nightly builds are very stable, and recommended as the best place to start today.
How do I install Struts?
To develop applications with Struts, you can usually just add the Struts JAR file to your Java development environment. You can then start using the Struts classes as part of your own application. A blank Struts application (in the webapps directory, open struts-blank.war) is provided, which you can just copy to get a quick-start on your own brainchild.
Since the full source code for Struts is available, we also provide complete instructions for compiling your own Struts JAR from scratch. (This is actually easier than it looks!)
Your Struts application can usually be deployed using a standard WAR file. In most cases, you simply deposit the WAR file on your application server, and it is installed automatically. If not, step-by-step installation instructions for various servlet containers are available.
When do I need "struts.jar" on my classpath?
When you are compiling an application that uses the Struts classes, you must have the "struts.jar" on the classpath your compiler sees -- it does not have to be on your CLASSPATH environment variable.
Why is that an important distinction? Because if you are using a servlet container on your development machine to test your application, the "struts.jar" must not be on your CLASSPATH environment variable when running the container. (This is because each Web application must also have their own copy of the Struts classes, and the container will become confused if it is on the environment path as well.)
There are several general approaches to this issue:
* Use ANT for building your projects -- it can easily assemble classpaths for the compiler. (This is how Struts itself is built, along with Tomcat and most other Java-based projects).
* Use an IDE where you can configure the "class path" used for compilation independent of the CLASSPATH environment variable.
* Use a shell script that temporarily adds struts.jar to the classpath just for compilation, for example javac -classpath /path/to/struts.jar:$CLASSPATH $@
Does Struts include its own unit tests?
Struts currently has two testing environments, to reflect the fact that some things can be tested statically, and some really need to be done in the environment of a running servlet container.
For static unit tests, we use the JUnit framework. The sources for these tests are in the "src/test" hierarchy in the source repository, and are executed via the "test.junit" target in the top-level build.xml file. Such tests are focused on the low-level functionality of individual methods, are particularly suitable for the static methods in the org.apache.struts.util utility classes. In the test hierarchy, there are also some "mock object" classes (in the org.apache.struts.mock package) so that you can package up things that look like servlet API and Struts API objects to pass in as arguments to such tests.
Another valuable tool is Struts TestCase which provides a useful harness for Action classes that can be used with JUnit or Cactus.
If the framework doesn't do what I want, can I request that a feature be added?
First, it's important to remember that Struts is an all-volunteer project. We don't charge anyone anything to use Struts. Committers and other developers work on Struts because they need to use it with their own applications. If others can use it too, that's "icing on the cake". If you submit a patch for a feature that a Committer finds useful, then that Committer may choose to volunteer his or her time to apply the patch. If you just submit an idea without a patch, it is much less likely to be added (since first someone else has to volunteer their time to write the patch).
We are grateful for any patches, and we welcome new ideas, but the best way to see that something gets added to the framework is to do as much of the work as you can, rather than rely on the "kindness of strangers". Worst case, you can apply the patch to your copy of Struts and still use the feature in your own application. (Which is what open source is ~really~ all about.)
What's the difference between Struts and Turbine? What's the difference between Struts and Espresso?
If you are starting from scratch, packages like Turbine and Espresso can be very helpful since they try to provide all of the basic services that your team is likely to need. Such services include things like data persistence and logging.
If you are not starting from scratch, and need to hook up your web application to an existing infrastructure, then "plain vanilla" Struts can be a better choice. The core Struts framework does not presuppose that you are using a given set of data persistence, presentation, or logging tools. Anything goes =:0)
Compared to other offerings, Struts endeavors to be a minimalist framework. We try leverage existing technologies whenever we can and provide only the missing pieces you need to combine disparate technologies into a coherent application. This is great when you want to select your own tools to use with Struts. But, if you prefer a more integrated infrastructure, then packages like Turbine or Espresso (which uses Struts) are perfectly good ways to go.
See also
* < http://www.mail-archive.com/struts-user@jakarta.apache.org/msg03206.html >
* < http://www.mail-archive.com/general@jakarta.apache.org/msg00495.html >
* < http://jakarta.apache.org/velocity/ymtd/ymtd.html >
0 comments:
Post a Comment