George Franciscus

Thank you for the kind words.

I checked with Manning. You can get the book via this channel. Sorry for the confusion. That's why they let somebody else do the marketing.

Wiley Dreamtech in New Delhi has the rights your book. Our contact
tells me it should be 4-6 weeks for the book to hit the market.
Regards,
Lee

There seems to be a lot of questions about file upload/download.

Have a look at Struts Recipes, recipe 2.9

Chapter 2 is available at http://www.manning-source.com/books/franciscus/franciscus_chp2.pdf

Check out Struts Recipes, chapter 2, recipe 2.9, Upload a File, p 89 (p 51 in the pdf). This recipe explains how to do it and "gotcha"s.

http://www.manning-source.com/books/franciscus/franciscus_chp2.pdf

~~George

We have a recipe in Struts Recipes that explains this exact thing (8.5 Hibernate and Struts). Its rather straight forward. Most of the complexity is using Hibernate. The Struts portion is easy.

The basic steps are ....
1. receive your submit in the usual way. You can create an ActionForm or a DynaForm. There is nothing stoping you from getting it out of the request, but the ActionForm is the usual way.

2. Configure Hibernate and map it to your table. The Hibernate site has excellent documentation on how to do this.

3. It is recommended that you cache the Hibernate session object. You can do this with a Struts plugin.

4. Use the Hibernate session object to retreive your data. Don't forget to close the session in the finally clause.

5. Place your data in a request attribute so you can pick it up in your view (JSP, Velocity, etc.).

Note: You can place all of your Hibernate logic in a DAO for higher maintainability.

Thank you.

You can browse to pick up the file anywhere on your drive.

Struts Recipes is available anywhere Amazon ships. Also, manning has a world-wide distribution network that includes Inida. Let me know if you have a problem getting it.

http://www.manning.com/about/distributors.html

You've got plenty of options to choose from. IMO security is a business requirement, and therefore should be dealt with in the business layer. Another way to look at is ... If I were to switch to a command-line UI, would I loose functionality. Most times the answer to this question is to do security in the business layer. However, not every project needs to be a multi-layer architecture. If its a small project then you can consider doing it in the web layer.

Here are some options

In the web layer �
a) You can secure a Struts action mapping using the role attribute. You can either use your container's role definitions (in web.xml), or point it to your own
b) You can protect areas on a page by using the role attribute on a tile definition
c) You can protect a field using the role attribute on a present tag
d) The RequestProcessor

The choices on (a), (b),(c) are matter of granularity. Each of these are addressed in Struts Recipes (Manning)

In the business layer �
i) EJB: If you are using EJB, then you can secure using J2EE security on the bean or method level. You can use a SSB (with local interfaces if the architecture is collocated) to provide security. WebSphere allows you to use LDAP or whatever you want
ii) Spring Framework: Spring use Aspect Orientated Programming (AOP) to provide security
iii) AOP: If you don't want to use Spring, then you can use AOP on its own.
iv) Java Dynamic Proxies: Java supports the something like AOP, but uses reflection to intercept a call to a method. You would then combine this with a call to your security service
v) roll your own

All of my large projects have been done with (i) EJB, but I'm starting to become serious about (ii) Spring.
[ February 01, 2005: Message edited by: George Franciscus ]

I like this tutorial on developerworks. It explains it all.

Java security, Part 1: Crypto basics

A class may have many instances. You can use "this" to obtain a reference to the current instance.

Here's an example ...

public Class MyClass {

String name;

public setName(String name) {
this.name = name; <----
}

}

At the arrow the the current instance variable "name" of this class is being assigned the method argument called "name"

We have a recipe in Struts Recipes that shows you how to do the whole thing step-by-step. Please have a look at recipe 2.9 in the sample download chapter.

http://www.manning-source.com/books/franciscus/franciscus_chp2.pdf

1. download and install tomcat http://jakarta.apache.org/tomcat/
2. download the struts binaries (or source) http://struts.apache.org/download.cgi
3. place struts-blank.war in webapps of your tomcat install
4. start tomcat and look at the struts-blank directory

There you will see where everything goes.

We would like to thank JavaRanch for inviting us. There is certainly a lot of thought provoking discussion and interesting ideas on the JavaRanch forums. We'll be back from time to time. In the meantime, we continue to welcome your thoughts at Struts Recipes Author OnLine http://www.manning-sandbox.com/forum.jspa?forumID=157

Thanks again everyone,
~~George

The client may not be a browser. Your application is receiving HTTP requests from anything that can send a request, not just a browser.

However, you can have your cake and eat it too. The validation (bundled with Struts) allows you to generate JavaScript validation and then execute it again server side.

Here's a link to the validation chapter from "Struts In Action"
http://www.manning-source.com/books/husted/husted_ch12.pdf

The explaination lies in understanding the difference between the comparison of an object reference and an object value. This little program explains it in code. Java will set name1 and name2 to the same object reference. Therefore, the first "if" statement evaluates to true, because the "==" is testing that the *references* are the same. However, name3 creates a brand new object with its own object reference. Therefore, the second "if" statement fails because the *references* are different. The third "if" statement evaluates to true because that statement is checking the contents of the String variables, not the references.

The output is as follows...

same
NOT same
equals

Here's the program ...

public class TestString { public static void main(String[] args) { new TestString().m(); } public void m() { String name1 = "prasad"; String name2 = "prasad"; String name3 = new String("prasad"); if (name1 == name2) { System.out.println("same"); } else { System.out.println("NOT same"); } if (name1 == name3) { System.out.println("same"); } else { System.out.println("NOT same"); } if ((name1.equals(name2)) && (name1.equals(name3))) { System.out.println("equals"); } else { System.out.println("not equals"); } } }

[added code tags - Ilja]
[ January 29, 2005: Message edited by: Ilja Preuss ]

As rule I try to avoid action chaining wherever possible. Chaining tends to �smell� like a responsibility leak. The business layer is responsible for providing atomic business transactions. Since an action chain will not demarcate a transaction (unless you introduce JTA in your actions), it starts a path down a very slippery slope. If two actions in the chain need to act as a transactional unit, then action chaining will not support a cohesive transaction. If the two actions in the chain do not need transactional control, then you wont have the problem *today*.

However, the application will be best understood during the development cycle. During the maintenance cycle someone could inadvertently create a non-atomic transaction. The greater the size of the application and breadth of the chain web, the greater the risk. The consequence of a non-atomic transaction could be great to the business community and not generally discovered until it reaches production. Good design and programming involves trying to make it bullet-proof into the future. A lofty goal, I know, but whatever you can do is better than nothing at all.

Some people use chaining to re-use a �display� action from multiple create/update/delete actions. IMO the chain web starts to get bigger, more complicated and starts to diminish the benefit of re-use.

If two actions are chained, then that generally means that there is a business relationship between the two actions � and that�s the job of the business layer. I think its better to couple that in the business layer rather than the web layer. A good way to test this relationship is to ask yourself � �If I were to swap out the web interface for a command-line interface, would things still hold up�. Often the answer to this question leads to decision to not chain the actions.

Having said that, I have seen action chaining used where the designer was trying to achieve a conditional dispatching effect. There may be some merit to that, but its not all that frequent.

Yes, we do. We have two.

Recipe 5.4 Use declarative exception handling uses a use case to illustrate how to implement declarative exception handling. The key to implementing it well is to make sure you have a well thought out exception strategy. Its important to spend a little time to come up with an inheritance hierarchy that suits your architecture. In this recipe we illustrate a sample strategy and show how it dove tails into declarative exception handling.

It is a best practice to always create a global exception tag to catch anything that might slip through. Its a graceful way to handle the unexpected. The best practice reads as follows ...

Best Practice: Always create a global exception tag to catch java.lang.Exception

Under Struts 1.1, an Action's execute method allows an unintentional return of an exception descending from java.lang.Exception. Unless these exceptions are caught by the ExceptionHandler, the user will receive a "Server Error 500". A graceful way to handle this unexpected condition is to create a global exception tag to handle java.lang.Exception.

We also have another recipe that shows you how to deal with an aggregation of exceptions (5.5 Aggregate exceptions). Often you will want to discover as many issues up front and aggregate then into a single exception. In this recipe we show you how to roll your own ExceptionHandler to deal with an aggregation of exceptions.