Take a look at the struts-example. I know its been part of it since at least Struts 1.0
...specifically, look at SaveRegistrationAction.java Good Luck!!! James Mitchell Software Engineer\Struts Evangelist Struts-Atlanta, the "Open Minded Developer Network" http://www.open-tools.org/struts-atlanta > -----Original Message----- > From: Nilan Shakya [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, July 10, 2002 12:01 PM > To: 'Struts Users Mailing List' > Cc: '[EMAIL PROTECTED]' > Subject: RE: Problem with form submission > > > Thank you James. > > I am still not sure where to put saveToken(request) and > isTokenValid(request, true) is not taking. It is not accepting as valid > method. > > I am hoping that you will give me some clue for that. > > Thank you, > Nilan > > -----Original Message----- > From: James Mitchell [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, July 10, 2002 12:58 AM > To: Struts Users Mailing List > Subject: RE: Problem with form submission, > > I saved the below msg because this is a very common question: > > > -----Original Message----- > > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] > > Sent: Friday, June 28, 2002 3:10 PM > > To: Struts Users Mailing List > > Cc: Ivan D. Sager > > Subject: Re: mapping > > > > <snip/> > > > > > To deal with resubmits, the most important issue is to avoid > updating the > > database twice when the user accidentally resubmits the same > form. Struts > > has a feature called "transaction control tokens" that help you avoid > > this, which is very simply used as follows: > > > > * In the Action that sets up your input form (i.e. before you forward > > to it), execute the following > > > > saveToken(request) > > > > to save a special value in the user's session that will be used in > > the next step. > > > > * In the Action that receives the form and updates the database, add > > the following logic before you do the update: > > > > if (isTokenValid(request, true)) { > > ... this is a resubmit, so go display an error ... > > } > > > > The "true" parameter causes the token to be removed from the session > > so that it doesn't interfere with subsequent form submits. > > > > This way, the submit will work the first time, but fail on any > accidental > > or on-purpose resubmit, and you avoid adding the information to the > > database twice. It also prevents the user from navigating > directly to the > > "myDB.do" URL without going through your normal setup actions -- because > > the transaction token would not have been placed in the session, so the > > isTokenValid() test would fail. > > > > Craig > > > > > > > > James Mitchell > Software Engineer\Struts Evangelist > Struts-Atlanta, the "Open Minded Developer Network" > http://www.open-tools.org/struts-atlanta > > > > > > -----Original Message----- > > From: Nilan Shakya [mailto:[EMAIL PROTECTED]] > > Sent: Tuesday, July 09, 2002 6:59 PM > > To: 'Struts Users Mailing List' > > Subject: Problem with form submission > > > > > > Hi All! > > > > I am having a problem while submitting a form. My form submission > > sometimes > > takes delay because it has to do lots of validation before updating the > > information in database. While the form is on the process of > submission of > > data if I click the same submit button once again it is > > submitting the data > > once again. This means that, now my output listing of items > from db shows > > repeated data set submitted (same data set submitted twice). I want to > > prevent the form be submitted once it is on the process of submission of > > data (disable the submission of form if it is already on the > way to submit > > something). > > > > Does anyone have any idea to solve my problem? > > > > Your help will be greatly appreciated. > > > > Nilan > > > > > > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > > Sent: Tuesday, July 09, 2002 11:39 AM > > To: Struts Users Mailing List > > Subject: Re: Off-Topic: JMS Design Question... > > > > > > > > To begin with, I'd recommend using a web service instead of just > > JMS. It's > > more reusable, has the ability for a variety of clients to access it and > > comes with fewer networking headaches. Plus they are especially good for > > sending XML. Given the fact that you are simply sending messages and > > getting responses, this may be better. > > > > But I've also built JMS apps as well. JMS is extremely cool and > > has a whole > > bunch of functionality that might be useful. In fact, this is > > how Weblogic > > implements message-oriented web services (see - "Message-Style > > Web Services > > and JMS" at > > http://edocs.bea.com/wls/docs61/webServices/develop.html#1031913 ). > > > > Using JMS within your container with SOAP as the transport protocol as > > outlined in the weblogic links above would be a great solution. It gives > > you persistence within your container and theirs, while exposing > > the app as > > a web service. > > > > I believe this simplifies your solution: > > > > - Your web app either: > > 1. - Puts the transaction into a JMS queue (topic or > > point-to-point) on your machine > > - Another process on your machine gets the message and then > > makes a message-based web service call to their app server > > - Their app server (which is exposed as a web > > service) gets the > > message, processes it and places the result on an outoging queue > > - Your web sevice call then retrieves the results. > > or, 2. - Your web app simply acts as a client to their web > > service and sends the message/retrieves the results by itself. > > - In this case you may be able to use the simpler, RPC-style > > web service. > > - In this case you also lose the ability to easily > persist the > > transaction for sending later it their service is unavailable. > > > > > > Let's assume you choose option #1 above - to answer your questions: > > > > 1) If Client's App Server is down, then our MDB should keep resending > > till the message is sent successfully. How can I do this in JMS? > > > > - roll-back your read of your internal JMS queue. The message will be > > there when you retry at some later time. The normal transaction > management > > stuff in your app server should handle all this. > > > > > > 2) If our JMS Server is down (shouldn't happen, but let's say it does) > > what should the Web App do? Would "Durable Subscriptions" help in this > > case? > > > > - Log the information you captured in a database and/or via an e-mail > > message to someone who cares and intervene manually (uless you want to > > write some fail-safe backup delivery - but then how do you > provide back-up > > in case the back-up fails?). "Durable Subscriptions" would allow > > you to not > > lose any messages already on the queue, but wouldn't help you add new > > transactions if they came along while JMS was down. > > > > Since this is off-topid. feel free to respond to me directly if > > you want to > > follow up. > > > > Kevin > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hello, > > > > This is kind of off-topic, so I apologize in advance. We do have some > > J2EE gurus on this mailing list so I decided to ask it here. (Is there > > any other *active* mailing list where I can post JMS related questions?) > > > > Anyway, I need some help to develop a JMS based solution. Here's what we > > are trying to accomplish; > > > > We need to send XML messages (as well as other types of messages) back & > > forth between two Application Servers. In other words, a Web Application > > created by us will send a message to the application server of our > > client and vice versa. > > > > This is what I was thinking of doing; > > > > 1) When it's time to send a message on our side, we will write it to a > > Topic in our App Server. > > 2) A MDB on our side will retrieve the message and send it to the Topic > > of our client. > > > > The same logic will apply for incoming messages; > > 1) Client will write a message to our Topic. > > 2) A MDB on our side will then pick up this message and process it. > > > > If this sounds okay, then I am wondering how I can handle Exception > > conditions. For example; > > > > 1) If Client's App Server is down, then our MDB should keep resending > > till the message is sent successfully. How can I do this in JMS? > > 2) If our JMS Server is down (shouldn't happen, but let's say it does) > > what should the Web App do? Would "Durable Subscriptions" help in this > > case? > > > > I would greatly appreciate any input in this matter. Thanks (a lot) for > > your time. > > > > - Ajay > > > > > > > > -- > > To unsubscribe, e-mail: > > <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: > > <mailto:[EMAIL PROTECTED]> > > > > -- > > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
