Re: How do I leverage the struts approach within an EJB environment?
You action classes perform function should do a jndi lookup of a session bean (stateless or not, I prefer stateless), passing a value object holding the relevant data. Do not be tempted to use the form bean, create a value object with no struts stuff in.The session bean should then do any data lookups via entity bean business fnuctions or whatever. Again, any data returned should be within value objects which are then used to populate the form. Why do all this? Basically you are using an industry standard RPC mechanism to a middle tier (ie the EJB remote stuff with JNDI lookup). You are decoupling the GUI from the data manipulation which theoretically gives you OO code reuse (like hell, but someone believes this stuff). You do gain scalability advantages (kind of, but lets not think too hard about that eh). Jonathan Message History From: Paul Idusogie [EMAIL PROTECTED] on 13/02/2002 09:41 CST Please respond to Struts Users Mailing List [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc: Subject: How do I leverage the struts approach within an EJB environment? Could someone kindly provide an explanation on how to leverage the struts approach within an EJB environment? we have the component diagram showing the main struts components relative to the MVC pattern. Where do EJBs fit in? ActionServlet -instantiate--ActionForm | | |send |call | |-Action V | | Jsp |use | | |-ActionMapping-- |use | V TagLib Thanks, Paul Idusogie Technical Architect Consulting Services Stellent Inc. Golden Triangle Drive Eden Prairie, MN 55104 Desk: 952.656.2755 Fax: 952.903.2115 Email: [EMAIL PROTECTED] website: http://www.stellent.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Editing a database record best practice?
OTT, as in amazing dull to code up yet another value object... I've got value objects coming out of my ears :) Jonathan Message History From: Adam Hardy [EMAIL PROTECTED] on 12/02/2002 09:49 PST Please respond to Struts Users Mailing List [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc: Subject: Re: Editing a database record best practice? On Tue, 12 February 2002, Jonathan Gibbons wrote: I guess the really OTT answer is: User/GUI = Form Object, all strings Mid Tier = Value object holding equivalent fields for each form field, but in native data type, but no struts code. DB = EJB, local interfaces. OTT as in the case of an app which you know you're going to deploy on a webfarm? In which case the DB will probably be on a seperate server, the webservers on another, possibly with EJB on board, possibly EJBs on their own server? The technical issue is whether you can realistically pass a form object from a performance point of view from one server to another. Find the best deals on the web at AltaVista Shopping! http://www.shopping.altavista.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: if tag
If there are plans for an if then else tag can they please be dropped. Scriptlets are far cleaner than inventing a tag which exactly mimics java. Jonathan Message History From: Mattos, John [EMAIL PROTECTED] on 12/02/2002 10:59 EST Please respond to Struts Users Mailing List [EMAIL PROTECTED] To: 'Struts Users Mailing List' [EMAIL PROTECTED] cc: Subject: if tag Hi all Are there any plans in the next release of Struts to have a logic:if tag? John -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Editing a database record best practice?
Hi, I've been thinking about this and have just arrived at the point you left behind! OK, the issue is that there is a data layer that holds EVERYTHING. And its all normalised inside databases and is pretty hard to utilise within your business code. So we create a business layer which loads up rows and parts of rows to perform the logical updates and operations required. We use EJB, CMP, OR, JDO whatever. We then have a presentation layer that is user oriented, mixing language varient information, multi-table information, business calculation information, security and so on. Each page/screen only holds the information needed and it holds it in a user friendly form (say Strings for ease, as in Struts). User-MiddleTier/business-database Network bandwidth and the marshalling times are an issue (maybe). Lets say we are using EJB, local interfaces from mid tier to DB, so its as quick as currently possible (ahem). Now the presentation data is held in strut form objects. I recon it is these that should be used as the data transport from mid to gui and back. It means we are only shipping the data we need. But we are putting presentation logic within the mid tier - ie objects that are purely there to populate data for a specific screen. I know this is fast and scalable. BUT, I also know that I have to stick struts.jar into the EJB container (usually they have an obvious common libs place - eg for jdbc drivers). Do we do this? A sacrifice of time against elegance. Hmmm. I guess the really OTT answer is: User/GUI = Form Object, all strings Mid Tier = Value object holding equivalent fields for each form field, but in native data type, but no struts code. DB = EJB, local interfaces. Just answered myself, anyone else got a point of view? Jonathan ps With respect to the original thread, I don't hold any state info in the session because of scaleability, timeout, and state transition issues (back button, multiple browser windows etc). It does mean an update is read for display, and then read for validate/insert. But I recon the DB is there to be used. I do hold user info in the session, but not activity state. Message History From: stf [EMAIL PROTECTED] on 12/02/2002 17:31 CET Please respond to Struts Users Mailing List [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] cc: Subject: Re: Editing a database record best practice? we are using a similar approach with ejb's, that produce value object's instead of database records: We have generic ValueObjects that are filled into the formBean using reflection (You can do something similar with result-sets using the meta-data: as long as you don't mind tying your bean-properties to the database-field names...): along with the data, a timestamp is transported inside the value-object: So only the ValueObject with the last timestamp can make an update on the ejb (with only some exceptions (CLOb/BLOB-fields which get specific update methods) we make global updates, we just set *all* values from the value-object into the ejb. Coming back from the form the process works the other way round: copying the values from the ActionForm into the valueObject and then passing it to the ejb for update... This sounds like a lot of copying: We first had the ejb's producing ValueObjects that extended action-forms with all the fields needed in the form: we ended up with having to package the struts-libs with every EJB caused by this mixing of business-object and view-layer (resulting in a lot of classloading-hassle: Fortunately you sometimes get real errors for bad design-decisions..) - so we ended up with this generic ValueObjectLayer that clearly separates the view from the Business-objects. Instead of using ejb you can try jdo (e.g castor, or intelliBO) - I'm not really sure, wether the need for such a neutralizing layer vanishes with this, but I think they will give you at least some handy tools to write the Data-Access-layer without having to write the sql by yourself. greetings stf - Original Message - From: Ryan Cornia [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, February 12, 2002 2:56 AM Subject: Editing a database record best practice? A common scenario I run into is having a web application where the user needs to edit a database record. The simplest approach I can find is this - 1.) Load the db record into a bean. Copy the bean props. to the form for display. Put the dbbean in the session. 2.) Show the form, when the user presses save, validate the form, make sure, if possible, that the form primary key fields are equal to the dbbean in the session primary fields. 3.) Have the dbbean do an update statement. In order to do this properly, the dbbean needs to have kept the original db values so they can be put in a where clause. This insures that we are changing the record exactly as we
RE: if tag
How can logic:if name=blah value=xxx logic:else /logic:else /logic:if (or whatever) be better. It's just different, but not better, and scriptlets are evil when they go mad and get out of hand, they are not evil of themselves. Jonathan Message History From: Mattos, John [EMAIL PROTECTED] on 12/02/2002 11:52 EST Please respond to Struts Users Mailing List [EMAIL PROTECTED] To: 'Struts Users Mailing List' [EMAIL PROTECTED] cc: Subject: RE: if tag Ya think? Well, if that's true, forget it. I'll just use scriptlets, although I feel like we're mixing too much java that way. John -Original Message- From: Jonathan Gibbons [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 12, 2002 11:38 AM To: Struts Users Mailing List Subject: Re: if tag If there are plans for an if then else tag can they please be dropped. Scriptlets are far cleaner than inventing a tag which exactly mimics java. Jonathan Message History From: Mattos, John [EMAIL PROTECTED] on 12/02/2002 10:59 EST Please respond to Struts Users Mailing List [EMAIL PROTECTED] To: 'Struts Users Mailing List' [EMAIL PROTECTED] cc: Subject: if tag Hi all Are there any plans in the next release of Struts to have a logic:if tag? John -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. -- 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] -- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Design question about ActionForm's validate method
Hi Ted, I was implementing this and noticed a problem in V1.0.1 1. Struts config is as below action path=/str/adminsessionview_srchpost type=com.db.eqpcs.mercstruts.struts.AdminSessionViewSrchAction name=adminsessionviewSrchForm scope=request input=/jsp/adminsessionviewsrch.jsp validate=true forward name=display_row path=/str/adminsessionview_maintget.do/ /action action path=/str/adminsessionview_maintget type=org.apache.struts.actions.ForwardAction parameter=/jsp/adminsessionview.jsp name=adminsessionviewForm scope=request validate=false / 2. The code for AdminSessionViewSrchAction does the following: AdminSessionViewForm form_obj = sess_bean.maintainStrutSearchAdminSessionViewForm(params); request.setAttribute(adminsessionviewForm, form_obj); // Now want to forward to the correct jsp, including the params return (mapping.findForward(display_row)); 3. OK, so we are seeing an action setting up the form for the following page, and that following page is being accessed via an ForwardAction, validate false. Well, it doesn't work. The prepopulated form does not display, all the fields have been reset to nothing. 4. Is this a bug, or is this a problem with my config? If display_row simlpy redirects to the jsp page directly then it works fine. Jonathan Message History From: Ted Husted [EMAIL PROTECTED] on 06/02/2002 18:47 EST Please respond to Struts Users Mailing List [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] cc: Subject: Re: Design question about ActionForm's validate method In 1.0.x, it is often suggested that each link at least be represented by an ActionForward. This centralizes control over the hyperlinks in the Struts Config, which yields a number of benefits. In Struts 1.1, now the Nightly Build, support has been added for multiple Struts configuration files. In order for this feature to work, any request for a presentation page that uses elements from the configuration file (ActionForms, forwards, mappings) must be routed through the controller. This allows the controller to make the appropriate configuration available for a given page. This is becoming a common pattern, since the Velocity support, and I believe the X2 servlet, also need you to do the same thing for the same reason. The controller needs to touch the request to prepare it for the presentation layer. Many other features in advanced applications, including security, logging, and screen definitins, are easier to implement when everything passes through the controller. In a strict MVC implementation, the controller is responsible for interacting with the user. It then follows that all requests from the user should flow through the controller. Some of us had been counting the ActionForwards as flowing through the controller, but as the framework expands, and more services are being plugged in, passing the actual request through the controller becomes more and more desirable, until it's really not worth making the occasional exception any more. -- Ted Husted, Husted dot Com, Fairport NY USA. -- Java Web Development with Struts. -- Tel +1 585 737-3463. -- Web http://www.husted.com/struts/ Alex Paransky wrote: So do you mean, all pages go through the Action? Even those which are not forms and for display purposes only? Could you shed some light as to why this is preferred? Thanks. -AP_ http://www.alexparansky.com -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 05, 2002 2:02 PM To: Struts Users Mailing List Subject: Re: Design question about ActionForm's validate method The best practice now is to use ActionMappings for everything, so that the reqeust passes through the controller. This buys you several important capabilities that become important as applications grow. Not the least of which is the new support for multiple applications in the Nightly Build. The ActionMapping has a validate property that you can use to turn off validation when the mapping is used to initialize a new form. So, typically, you will have an ActionMapping for each circumstance. action path=/item/Add type=org.apache.struts.actions.ForwardAction parameter=/pages/item/Form.jsp name=itemForm scope=request validate=false /action action path=/item/Store type=org.apache.gavel.item.http.Store name=itemForm scope=request validate=true input=/pages/item/Form.jsp
RE: Design question about ActionForm's validate method
Hi, live and learn eh! I revise my recommendation, you still need two URL's, but they can go to defined action paths. However, beware of users browsing directly to the JSP's and code with that in mind. Also to stop yourself going mad, make sure the GET path and POST path are different eg GET /jsp/apageGet POST /jsp/apagePost.do Jonathan ps now rewritting my code gen. Message History From: Robert Scaduto [EMAIL PROTECTED] on 05/02/2002 13:31 EST Please respond to Struts Users Mailing List [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] cc: Subject: RE: Design question about ActionForm's validate method Matt, I also disagree that you should only use actions when submitting a form. I also believe that in most cases you should never forward a request directly to a jsp without first going through the Action framework. Struts provides a utility action that will do this for you. The org.apache.struts.actions.ForwardAction will forward to the jsp file specified in the parameter attribute of the action mapping. Like so.. action path=/passwordAssistance type=org.apache.struts.actions.ForwardAction parameter=/password_assistance.jsp /action If you are using the *.do extension in your servlet mapping you would access the action like this... html:link page=/passwordAssistance.doGo to Password Assistance/html:link It may seem like extra work for no reason but if the requirements of your system change and now you need to forward to an action instead of a jsp it is much easier to replace the ForwardAction to a custom action. It sounds to me like you are on the right track. -Rob -Original Message- From: Matt Read [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 05, 2002 12:59 PM To: Struts Users Mailing List Subject: RE: Design question about ActionForm's validate method I'm fairly new to struts (well, about 24 hours actually) and this message touches on a concept that I've having trouble grasping. Are you saying that your site should never allow the user to navigate to a URL that maps to an Action unless you are submitting a form? This is my example and although it's actually working in practice it doesn't really feel right to me and doesn't conform to above rule. I hope I've included enough detail and would appreciate any clues on good design. 1. User goes to the home page and clicks on a Find a client link. 2. This link points to /find/client.do which is defined as an ActionMapping as follows: action path=/find/client type=mysite.actions.FindClientAction name=clientFindForm scope=request input=/pages/findclient.jsp forward name=newsearch path=/pages/findClient.jsp/ /action 3. The code in FindClientAction ensures that the user is authenticated and then populates some request scoped attributes that enabled /pages/findClient.jsp to function correctly. /pagesfindClient.jsp displays a form to allow the user to enter search criteria. 4. The submit action for the form in /pages/findClient.jsp is /find/getresults which is defined as an ActionMapping as follows: actionpath=/find/clientresults type=mysite.actions.FindClientResultsAction name=clientFindForm scope=request input=/pages/findclient.jsp forward name=success path=/pages/findClientResults.jsp/ /action 5. The code in FindClientResultsAction examines the contents of the clientFindForm and contstructs a SQL statement to retrieve the correct data. 6. /pages/findClientResults.jsp renders the results from the database. Matt. -Original Message- From: Jonathan Gibbons [mailto:[EMAIL PROTECTED]] Sent: 05 February 2002 17:44 To: Struts Users Mailing List Subject: Re: Design question about ActionForm's validate method I made this same 'mistake'. Actions MUST only be called when a form is submitted. Never to generate the JSP. Thats why they are called actions. Or two put it another way, you do need several URL's a) URL to JSP on a GET b) URL to action the POST The easiert way to do it is to have all forwards going directly to the JSP, and all actions in the pages going to .do. At first it seems rubish, but then you hopefully buy into the model view controller idea. i.e NO business logic in the page and it all starts to make perfect sence. But you really do have to buy into it otherwise you are fighting urge to ditch it all and go back to brilliant servlets, nice and easy, total power etc etc. Jonathan Message History From: Sid Stuart [EMAIL PROTECTED] on 05/02/2002 09:24 PST Please respond to Struts Users Mailing List [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] cc: Subject: Design question about ActionForm's
Re: Novell Bordermanager
My guess is that there is proxy caching going on someplace. Setting the HttpServletResponse header fields should do it, not sure if there is a tag, but its easy enough to do in the JSP itself % response.addHeader(Pragma,no-cache); response.addHeader(Cache-Control,no-cache); % Jonathan Message History From: David Bolsover [EMAIL PROTECTED] on 06/02/2002 10:42 Please respond to Struts Users Mailing List [EMAIL PROTECTED] To: Struts User [EMAIL PROTECTED] cc: Subject: Novell Bordermanager Hi all I have a struts application hosted on a W2K server running Apache/Tomcat. The application runs fine for most uses - but I have one user who is accessing application from a system protected by bordermanager. For this user, the pages do not refresh correctly (old pages are returned) despite hitting refresh in the browser. I am not certain but I think this might be a bordermanager issue - has anyone else seen this problem? I have little experience of bordermanager and am not certain this is the problem - Any other ideas on what could be causing difficulty? I have not yet tried setting the appropriate response headers (no-cache etc.) but this does seem difficult - would I have to alter all the action methods?? All advice welcome. David David Bolsover E: [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: bean passing
Hi Stephen, Download my struts example, it includes paged searches implemented in stateless session beans - actually pretend stateless session beans, so you don't need an app server. http://www.faraway.co.uk/tallsoft/lowroad/ click on downloads, agree, examples, example 2 Jonathan Message History From: Steven Banks [EMAIL PROTECTED] on 06/02/2002 08:58 AST Please respond to Struts Users Mailing List [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc: Subject: RE: bean passing Stephen: Your answer is a solution to a problem I have been trying to grasp for awhile. We use a connection pool and I was trying to figure out how to page through large resultsets without having to rerun the entire query and then move through the resultset to the correct position each time. If I understand your solultion correctly, it does what I have been struggling to learn. Would it be possible for you to include some sample code? Thanks in advance Steven Banks Stephen Owens [EMAIL PROTECTED] 02/05/02 02:34PM Mike, This is a deeper question that goes back to your model and the search implementation I think. I tend to keep around only the position within the result set, usually using a 'pager' bean that calculates where I'm at, how many to display, and where to go next/previous. When my action gets the pager values back, it recomputes the search results, and makes them available to the view for display. So the actual search results are not persisted between requests. I have found that persisting large result sets is too inefficient in DB and memory resources. regards, Stephen Owens Corner Software -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 05, 2002 1:27 PM To: [EMAIL PROTECTED] Subject: bean passing I'm new to Struts, but have read most of the doc and examples. One basic thing that I can't quite put a finger on: how do you pass all these beans around that are consumed by the jsp's? For example, say you have a bean containing user's search results. Your display page only shows 10 at a time, and uses next and previous buttons. So, you have to persist the results from page to page. Obviously, you could explicitly add the bean to the session in the action.perform(), then reference the bean with tags using session scope. This is essentially the same way you'd do it even if you weren't using Struts. So, is there a mechanism in Struts that I should be using instead? Either it is simpler than I thought, or I am missing something obvious. Thanks, Mike -- 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] -- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: RE: [Fwd: Re: Hi....]]
Hi, The problem with too many tags is one of maintenance. Each tag you write becomes part of your bespoke project 'language'. With large groups producing many tens or hundreds of tags it can become a nightmare for new staff. Far better to stick to the core tags, and struggle not to add many new ones of your own. Think of it another way, each tag is exactly like you adding to html for your own project. Remember the horror of IE v's Netscape when html diverged - that is exactly what a project is doing by writing their own tags. New project members will hate it. BUT, some ten or so custom tags will make your project a joy and there is no downside. OTOH, if its your project, and you don't have to worry about maintenance (!) then do anything you want. Jonathan Message History From: Olivier Dinocourt [EMAIL PROTECTED] on 05/02/2002 11:07 CET Please respond to Struts Users Mailing List [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] cc: Subject: Re: RE: [Fwd: Re: Hi]] I think he means that you should avoid as much as possible writing code (of any sort : tags, scriptlets, etc...) in your JSPs, and rather put this code in your Action classes / business logic classes - Original Message - From: Jay Sissom [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] Sent: Tuesday, February 05, 2002 12:29 AM Subject: Re: RE: [Fwd: Re: Hi]] I don't agree. If you need to use scriptlets in your JSPs and you use them over and over on many pages, the scriptlet should be a tag. The tag can be reused on many pages, the scriptlet can't. Please explain why This is a bad habit. Only do it if you must. Should we only re-use code if we must? Is re-use of code a bad habit. :) Jay - Original Message - From: Vic Cekvenich [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, January 30, 2002 2:48 PM Subject: [Fwd: RE: [Fwd: Re: Hi]] The thing on tags is do not use to many tags. Try to avoid writing tags. Somehow, the example app on struts has a custom tag and people like to learn how to write tags, and so there are lots of tags in Struts. This is a bad habit. Only do it if you must. Try to do as little code as possible in presentation/view/jsp. So to me, tags and Struts framework are 2 different things, but bellow is a good book anyway. Vic Original Message Subject: RE: [Fwd: Re: Hi] Date: Wed, 30 Jan 2002 18:49:35 +0100 From: Lacerda, Wellington (AFIS) [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] Organization: Basebeans.com To: 'Struts Users Mailing List' [EMAIL PROTECTED] Newsgroups: Struts Another book with a lot of information on Struts is JSP and Tag Libraries for Web Development, available at Amazon and BN. Check the publisher's page at: http://www.newriders.com/books/title.cfm?isbn=0735710953. It is heavily focused on Tag Libraries and Struts is discussed on the light of that. Wellington -Original Message- From: Vic Cekvenich [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 30, 2002 6:39 PM To: [EMAIL PROTECTED] Subject: [Fwd: Re: Hi] Newsgroups: Struts @ news.basebeans.com References: [EMAIL PROTECTED] One Struts book at http://www.basebeans.com/book.jsp Amir N. Nashat wrote: Hi Chetan, There are no books available at this time though 2 are currently being written that I know of. However, they will not be available for a while. The best place to start is to go to the website jakarata.apache.org and search under struts. there is A LOT of good information there. Also, another very good site is www.husted.com. Ted(who runs the site) is very knowledgeable in this field and posts to this mailing list very often. Hope that helps. amir [EMAIL PROTECTED] 10:38:51 PM 01/29/02 I'm just a newbie to Struts and find it very interesting, I just want to ask where is it best to start learning struts from... Is there a book out there that I can buy Thankz Chetan -- 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] -- 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:
Re: Newbie question: Application Flow in Struts
Hi, I can't remember where I read this, but it was in the struts docn or code someplace. You struts config has something like: form-beans form-beanname=adminForm type=com.foo.AdminForm / /form-beans !-- == Action Mapping Definitions == -- action-mappings !-- load jsp page, which does a search action (.do) which forwards back to jsp page to show results-- action path=/jsp/adminaction type=com.foo.AdminAction name=adminForm scope=request input=/jsp/adminsrch.jsp validate=true forward name=success path=/jsp/adminsrch.jsp?action=results/ forward name=displayrow path=/jsp/adminview.jsp/ /action OK, so when you browse to /jsp/adminsrch.jsp Struts knows that the form bean associated with this page will be called adminForm because of the name=adminForm input=/jsp/adminsrch.jsp and the form defn form-beanname=adminForm type=com.foo.AdminForm / So struts creates a form objects and sets it up (reset). You could also create it in the preceding action option, using com.foo.AdminForm next_form = new com.foo.AdminForm(); next_form.setSomething(blah); request.setAttribute(adminForm, next_form); and then forward to /jsp/adminsrch.jsp So the answer is, the controller will instantiate the form if you go to the jsp, OR you can set it up yourself and populate it. Jonathan = For struts code generation with EJB support visit: http://www.faraway.co.uk/tallsoft/lowroad/ Message History From: matt lobur [EMAIL PROTECTED] on 05/02/2002 06:48 PST Please respond to Struts Users Mailing List [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc: Subject: Newbie question: Application Flow in Struts Hello all, I have a few questions, grey areas, when it comes to application flow in STRUTS. I have read many articles but there are still certain areas I am not comfortable with namely the backend. So let me tell what I think I know and then someone can tell me how I went wrong. When you Submit your HTTP request from the browser it gets handled by the Controller Servlet. This servlet knows to instanciate the proper formBean configured in the xml file. The proper action class's perform() method is called with the previous mentioned formBean as a parameter. This is when I get a little confused. In each of your action classes you initiate the logic to update your MODEL. So for example, myAction.perform() will instanciate/use some business objects to update the state information in the system. Since the perform() method returns and ActionForward object to the controller which I assume the controller will use to show a certain page which is based on a formBean. When should I update/instanciate/set that formBean so that the page that uses it will show the correct info? Should that be taken care of by the MODEL, either an EJB or just a regular bean, or in the Action class itself? thanks, matt lobur __ Do You Yahoo!? Send FREE Valentine eCards with Yahoo! Greetings! http://greetings.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Design question about ActionForm's validate method
I made this same 'mistake'. Actions MUST only be called when a form is submitted. Never to generate the JSP. Thats why they are called actions. Or two put it another way, you do need several URL's a) URL to JSP on a GET b) URL to action the POST The easiert way to do it is to have all forwards going directly to the JSP, and all actions in the pages going to .do. At first it seems rubish, but then you hopefully buy into the model view controller idea. i.e NO business logic in the page and it all starts to make perfect sence. But you really do have to buy into it otherwise you are fighting urge to ditch it all and go back to brilliant servlets, nice and easy, total power etc etc. Jonathan Message History From: Sid Stuart [EMAIL PROTECTED] on 05/02/2002 09:24 PST Please respond to Struts Users Mailing List [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] cc: Subject: Design question about ActionForm's validate method Hi, I've stumbled across a subtle problem/design question that I don't see mentioned in the documentation. The ActionForm's validate method can be configured to verify form data from a page and generate error messages which may then be displayed on the page for the user to see. This works fine when the user has accessed the page by specifying a JSP file in the URL. When the user accesses the page by calling the Action directly though, the validate method is called before the user ever sees the page, much less inputs valid data to the form. This leads to an unfortunate display of unwarranted error messages. It would be nice if the documentation would provide a rule such as: If one plans on the user calling the Action directly in the URL then one should not use the automatic validation provided by ActionForm. Further, as having two different procedures to generate a page can lead to subtle errors, one should decide whether a page will be accessed as a JSP or as an Action and design for the one scenario. The simplest (and safest) design rule will be to access all pages through either one mechanism or the other. Comments? Sid Stuart -- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: AW: Formatting Dates, Integers...
Hi, one thing I'm doing today is: a) Add formatting strings to the resource bundles b) Adding util classes which can apply the formatting, either in form object getter/setter or wherever. Step b could be done in one of your own tag libs, but I can't be bothered to do that. This means I can specify the format per locale, rather than use the defaults. The tricky bit is getting at the resource bundle from your own code. You can do this by using the servlet context and session objects with names attributes - ie the same ones used by struts. Take a glance at the MessageTag class for how to. Validation means you should do this in the form validate func as well. Jonathan Message History From: Hudayioglu, Fehmi [EMAIL PROTECTED] on 04/02/2002 09:52 CET Please respond to Struts Users Mailing List [EMAIL PROTECTED] To: 'Struts Users Mailing List' [EMAIL PROTECTED] cc: Subject: AW: Formatting Dates, Integers... thanks ted, we had done exactly what you've said. It works quite fine, and appears to be the most effortless choice we have. But still, in the deepness of my heart, I am not agree with the philosophy of business tier, I think it is a pure localization problem. But I must admit that adopting this sort of formatting would be very hard (I believe it is easy to display formatted strings by using tags, but goddamn I couldn't imagine how to set them back to the properties after user click that goddamned button). thanks, Fehmi. -Ursprüngliche Nachricht- Von: Ted Husted [mailto:[EMAIL PROTECTED]] Gesendet am: Monday, February 04, 2002 3:59 AM An: Struts Users Mailing List Betreff: Re: Formatting Dates, Integers... Pesonally, I recommend doing such things in the ActionForm. You can do them in the page, but that means modifying the page, and placing what is really business logic in the presentation tier. While it seems we are talking about how data looks, formatting it this way or that is really a business requirement. The part about stuffing the formatted string into HTML is the presentation tier. The J2EE blueprints call these helper beans or methods. Generally, I add a second getter to provide the formatted version. This does the same thing a tag would do, but is easier to write. The actual formatting code I would put into a library in the business tier that the ActionForm method would simply call. So you could add these without touching your existing methods, and just have the bean:write call these getters instead. Of course, if we are talking about display data, and you already have beans that render the formatted data, just use those. The ActionForms are only important for inputting data. -- Ted Husted, Husted dot Com, Fairport NY USA. -- Java Web Development with Struts. -- Tel +1 585 737-3463. -- Web http://www.husted.com/struts/ Hudayioglu, Fehmi wrote: Hi fellows, I have searched the mailing list in hope to find a way to display a number in format (e.g:120.200,32). I couldn't find any solution. There were some messages proposing to play on the getter and setter methods. But, this is not a solution we imagine. Because we have some object properties in the Form Bean and their properties can be set by struts directly. So changing getter and setter methods requires tons of effort to modify our data classes and form beans which is of course NOT desirable. I also know that there is a DateTag library of Jakarta, which is yet in beta release. Therefore, my managers (regards to them) don't want to use beta releases. They don't want to modify struts tags neither. However, I believe this is quite straightforward way (hopefully they will be contended soon). So, 1. Do you have any clever solution for this common problem? 2. What necessary steps should I take in order to add a new Format attribute to the form:text and bean:write? 2.1 In case, I added necessary methods, how can I guarantee that struts set this formatted value to the property. According to my tries, it doesn't set them correctly? 2.2 How long does an ordinary developer require to modify struts to do so? thanks and my best regards, fehmi. -- 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] -- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Boost Struts with XSLT and XML - JavaWorld.com
Matt, nicely said. Pretty much what I feel, but could not describe. I guess it comes down to: ITS TOO EARLY. i.e use it for prototypes and dept projects. Don't start designing customer web sites with it until you have sorted out tools, maintenance, evolving xslt/xml specs and so on. Jonathan (who also hates JSP, they are too easy...and thus messy.) Message History From: Matt Raible [EMAIL PROTECTED] on 04/02/2002 09:00 PST Please respond to Struts Users Mailing List [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] cc: Subject: Re: Boost Struts with XSLT and XML - JavaWorld.com I read this article and think that it is good - but there's a couple of things that I think need to happen before this architecture is embraced. 1. There needs to be mechanisms for getting internationalization into your XML or XSL. It seems difficult to use messages from a properties files for messages and form labels. By difficult, I mean harder than it is to use bean:message in JSPs. I could see putting them into the XML document, but then it seems that HTML developer type stuff is getting handed off to the Java developer. 2. XSL Templates and examples are difficult to find. I think this technology and concept would rapidly catch-on if there were XSL stylesheets that you could download that would format all your form-elements and other details. If the struts-example where adapted to use this approach, people would jump all over it I'll bet. 3. XSL is difficult to debug, and if we're truly separating view from everything else - good luck finding a view developer that knows XSL. I know some of these are irrelevant since we HTML developers are often Java coders and XSL experts... but just my 2 cents. Matt --- Ted Husted [EMAIL PROTECTED] wrote: See also the Velocity/Struts toolset. http://husted.com/struts/resources/velstruts.zip and http://cvs.apache.org/viewcvs/jakarta-velocity-tools/ Same basic idea: expose the Struts API as an object that anybody can easily use, without having to know that Struts even exists. All the hooks are there, they just aren't as easy to get to as they might be. I started a ContextHelper object that did this as part of the core framework. We pulled it out temporarily while the new multiapps stuff is going on. But I plan to put it back in so that the default controller does what the X2 Servlet and Velocity Servlets are doing, in a uniform way. It's my personal opinion that, while JSPs are flexible, these other technologies work are ever bit as effictive when used as the V in MVC. -- Ted Husted, Husted dot Com, Fairport NY USA. -- Java Web Development with Struts. -- Tel +1 585 737-3463. -- Web http://www.husted.com/struts/ Knoll, Zach wrote: This is really cool. I've been struggling with this for a while trying to convince myself that everything that comes from SUN must be good and beautiful and that those that were ragging on JSP were just fringe loonies. I thought the whole struts tag library and tag libraries in general would shut up the non-believers by removing spaghetti code from JSP. But from experience I am seeing that people will always go the easiest route and when offered a choice between learning how to handle a new tag library API or just slopping some java code into your JSP, its the rare coder who wont take the sloppy, easier, impossibly harder to debug 2 months later approach. I think I can finally admit now that JSP is just not a clean good technology and although I have a lot to learn I'd like to move away from JSP's altogether. Simultaneous to my JSP=bad voyage of discovery I was also starting to learn Struts and saw and continue to see in Struts stuff that I have been doing on my own for a while now, done in a more polished cleaner fashion that attracts me to it. This article showing how to have the best servlet centric architecture (Struts) while cutting out the dead-weight (JSP) really hits home. I just wish they would've provided more code so people like myself who are new to xml can really get a sense of how to implement this beast. -Original Message- From: Pete Carapetyan [mailto:[EMAIL PROTECTED]] Sent: Saturday, February 02, 2002 12:17 PM To: Struts Users Mailing List Subject: Re: Boost Struts with XSLT and XML - JavaWorld.com This is one of the most well written articles I have ever seen. At first blush, I am having a difficult time deciding wether this technology is totally cool, or it is just such a straightforward presentation that I am twitterpated. Thanks Todd Todd G. Nist wrote: I have not seen this posted so, for those interested in using XSLT and XML with Struts, thought the following article maybe of value. Boost Struts with XSLT and XML An introduction to Model 2X Summary Struts is an
RE: Java Trivia
Java doesn't have pointers! Just mudying the waters, or was it serious? If so sorry. Think of it as chucking water over someone, as opposed to passing them a cup of water. Thats pretty similar. or, um, having someone talk to you, rather than pass you a piece of paper. hmmm. J, Message History From: Galbreath, Mark [EMAIL PROTECTED] on 01/02/2002 08:48 EST Please respond to Struts Users Mailing List [EMAIL PROTECTED] To: 'Mikkel Bruun' [EMAIL PROTECTED]; Struts (E-mail) [EMAIL PROTECTED] cc: Subject: RE: Java Trivia Obviously, the first is passed by value, but the second? We know p will reference the same object it referenced before the method invocation - the memory location it points to is the same. Because p will always point to the same memory location, is it not also passed by value? ;-) -Original Message- From: Mikkel Bruun [mailto:[EMAIL PROTECTED]] Sent: Friday, February 01, 2002 8:44 AM Ehh... primitives vs ojbects??? by value or by ref... whats the point?? -Original Message- From: Galbreath, Mark To: Struts (E-mail); J2ee (E-mail) What's the difference between int i = 3; someMethod( i); and Point p = new Point( 3, 3); someOtherMethod( p); ? Mark -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Java Trivia
Hurray! I was getting worried. And in the UK, its almost time to go home. J. Message History From: Galbreath, Mark [EMAIL PROTECTED] on 01/02/2002 09:59 EST Please respond to Struts Users Mailing List [EMAIL PROTECTED] To: 'Struts Users Mailing List' [EMAIL PROTECTED] cc: Subject: RE: Java Trivia Like I said...it's Friday ;-) -Original Message- From: Jim Bell [mailto:[EMAIL PROTECTED]] Sent: Friday, February 01, 2002 9:14 AM To: Struts Users Mailing List Subject: RE: Java Trivia Perhaps this discussion is better suited for another mailing list, but in an attempt to bring it to closure... Java doesn't expose its pointers for manipulation, but its object references can be considered pointers, if you like. Yes, Java is a pass-by-value language on the surface, but it uses pass-by-reference when passing objects (not primitives) around. Otherwise, it would need to perform expensive deep-cloning of objects before passing objects as parameters. I like to think of Java as doing pass-reference-by-value when objects are involved. Now I notice that the original message was posted to the J2EE mailing list too. Perhaps I should have left it to those folks to address. After all, we already receive a plethora of messages from this list each day. HTH Jim Bell -Original Message- From: Jonathan Gibbons [mailto:[EMAIL PROTECTED]] Sent: Friday, February 01, 2002 9:02 AM To: Struts Users Mailing List Subject: RE: Java Trivia Java doesn't have pointers! Just mudying the waters, or was it serious? If so sorry. Think of it as chucking water over someone, as opposed to passing them a cup of water. Thats pretty similar. or, um, having someone talk to you, rather than pass you a piece of paper. hmmm. J, Message History From: Galbreath, Mark [EMAIL PROTECTED] on 01/02/2002 08:48 EST Please respond to Struts Users Mailing List [EMAIL PROTECTED] To: 'Mikkel Bruun' [EMAIL PROTECTED]; Struts (E-mail) [EMAIL PROTECTED] cc: Subject: RE: Java Trivia Obviously, the first is passed by value, but the second? We know p will reference the same object it referenced before the method invocation - the memory location it points to is the same. Because p will always point to the same memory location, is it not also passed by value? ;-) -Original Message- From: Mikkel Bruun [mailto:[EMAIL PROTECTED]] Sent: Friday, February 01, 2002 8:44 AM Ehh... primitives vs ojbects??? by value or by ref... whats the point?? -Original Message- From: Galbreath, Mark To: Struts (E-mail); J2ee (E-mail) What's the difference between int i = 3; someMethod( i); and Point p = new Point( 3, 3); someOtherMethod( p); ? Mark -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. -- 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] -- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Off Topic] get/set method generation
There are loads of them, for example the LowRoad http://www.faraway.co.uk/tallosft/lowroad/ But its a little heavy if all you want is get and set. Others may suggest XDoclet, I'd suggest you simply write your own. It will take you all of 5 or 10 minutes. Jonathan Message History From: João Paulo G. Batistella [EMAIL PROTECTED] on 31/01/2002 14:56 Z3003 Please respond to Struts Users Mailing List [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] cc: Subject: [Off Topic] get/set method generation Anyboy knows a tool for generating get/set methods from a list of attributes?? An example: I have private String name; private int number; And I would like to generate: public String getName(); public void setName( String name ) ; public int getNumber(); public void setNumber( number ); Thanks -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: RES: handling exceptions
Hi, JDK1.4 is at final release candidate stage. They include nested exceptions (including all remote exceptions) and a logging framework. Use these, and not any other version (eg log4j), you will be future proofing your CV and code. Jonathan === For EJB and Struts code generators see: http://www.faraway.co.uk/tallsoft/lowroad/ Message History From: Chuck Cavaness [EMAIL PROTECTED] on 28/01/2002 08:22 EST Please respond to Struts Users Mailing List [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] cc: Subject: Re: RES: handling exceptions Unfortunately no because I think it contains some really nice features for Struts. This is a commerical product that I'm working on. However, I have received permission to discuss the exception framework in the Struts book that I'm working on for OReilly right now. Search the mailing list archives for the thread OReilly Struts Book. Chuck At 11:02 AM 1/28/2002 -0200, you wrote: Thanks. I want to know if your framework of handling exception will be opensource, like struts. -Mensagem original- De: Chuck Cavaness [mailto:[EMAIL PROTECTED]] Enviada em: segunda-feira, 28 de janeiro de 2002 10:27 Para: Struts Users Mailing List Assunto: Re: handling exceptions We've developed a pretty eloborate exception handling framework on my current project. We're using EJB on the backend, so we must also deal with remote type exceptions. First we catorgize exceptions into those that the user can recover from and those that they can't. Sort of like fatal and non-fatal. You also need to divide exceptions into system and application exceptions. System exceptions are ones like remote exception, or maybe some type of datastore exception. Application exceptions for us are ones like required fields were missing or duplicate values for a unique column. In our world, the same exception framework has to work for ERP systems, so it's not just the web container. Anyway, for those exceptions that the user can recover from like required fields missing, we catch those type of exceptions, create an ActionError with a message from the bundle specifically for that exception, and then forward back to the input page. This gives the user a chance to fix the problem and resubmit. For the more severe exceptions, we also catch those and forward to a system-error type page since there's probably nothing you can do about it anyway. We use an abstract base action that all of our actions extend. We have all of this behavior in the base action and none of the action classes have to worry about catching these exceptions. The abstract base action implements the perform and has an abstract doWork type method. The doWork method is wrapped with the try catch blocks. Each concreate action class implements the doWork and doesn't have to worry about the try catch. I hope that gives you some ideas. chuck p.s. Regarding your other post about using System.out in your action classes; I wouldn't recommend that approach. Use log4j instead. That way, you can shut off the debug logging externally by just editing the log4j.properties file. At 09:50 AM 1/28/2002 -0200, you wrote: Could somebody help me ? I have to many problems with handling exception of the Struts. what do you suggest to handling exception of the deployment applications? -- 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] -- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Only one logged in session at a time for each user
I have used a combination of ip_address and jsessionid which I store in an active_session table. Every action they do I check the table - if the ip address changes (ie someone has nicked the session id) then I ditch the record and make em log in again. If the same user logs in again from same IP address I let them right in, no logon required (within a time period). If the same user logs in from another ip address then I bouce the first one off... It stops users using each others passwords as a rule - it's too annoying. The problem is proxies and gateways which mask off original ip addresses. Can't have everything. Jonathan == For ejb and code generation for your Struts web site, visit: http://www.faraway.co.uk/tallsoft/lowroad/ Message History From: Sean Owen [EMAIL PROTECTED] on 28/01/2002 09:40 EST Please respond to Struts Users Mailing List [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] cc: [EMAIL PROTECTED] Subject: Re: Only one logged in session at a time for each user You should store their current session ID in some kind of persistent store, like you say. Then I would suggest that if they log in a second time, that you invalidate the *old* session and let them continue with new one. I've seen that approach used on a large public web site. Sean On Sunday, January 27, 2002, at 08:01 PM, Antony Stace wrote: Hi I want the users in a Struts application to be only logged in once at any one time. What is the best way to go about this. I was thinking that I can have have some sort of record in (an application wide bean)/(a database record)/(the logon action) that keeps track of who is logged on and when the log on process happens this record is checked, if the user is already logged on then don't let them log on again. The problem I can see with this is that this works fine if the user logs out of the application through a logout action - the logout action can simply clear the record of the user being logged in. But if the users browser crashes, they reboot the machine, they simply restart the browser then this record will not be cleared and thus they will not be able to log in. I cannot think of how I can implement a mechanism to ensure only one log in at a time. The thought of adding some sort of timeout value seems a little nasty, since I hate it when I go to a site and I am told I am alread logged in, please try back in 10 minutes. Any ideas folks on how to handle this? -- Cheers Tony - _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- To unsubscribe, e-mail: mailto:struts-user- [EMAIL PROTECTED] For additional commands, e-mail: mailto:struts-user- [EMAIL PROTECTED] _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Problems with getting the Oracle thin JDBC drivers loaded with Struts 1.0.1under Tomcat 3.3a
Yes it does! Stick it in WEB-INF/libs/classes12.jar. That works just fine. Jonathan === Want to generate heaps of code? Visit: http://www.faraway.co.uk/tallsoft/lowroad/ Message History From: Mark Galbreath [EMAIL PROTECTED] on 28/01/2002 09:46 EST Please respond to Struts Users Mailing List [EMAIL PROTECTED] To: 'Struts Users Mailing List' [EMAIL PROTECTED] cc: Subject: RE: Problems with getting the Oracle thin JDBC drivers loaded with Struts 1.0.1 under Tomcat 3.3a That won't work. It should be %ORACLE_HOME%\jdbc\lib\classes12.zip in the classpath. Mark -Original Message- From: Jack Zakarian [mailto:[EMAIL PROTECTED]] Sent: Sunday, January 27, 2002 8:59 PM To: Struts Users Mailing List Subject: RE: Problems with getting the Oracle thin JDBC drivers loaded with Struts 1.0.1 under Tomcat 3.3a Hi Try renaming it to classes12.jar. Jack -Original Message- From: Thorbjørn Ravn Andersen [mailto:[EMAIL PROTECTED]] Sent: Monday, January 28, 2002 6:57 AM To: [EMAIL PROTECTED] Subject: Problems with getting the Oracle thin JDBC drivers loaded with Struts 1.0.1 under Tomcat 3.3a I am in the process of getting Struts to work under Tomcat3.3a on a Redhat 7.1 and Sun's 1.3.02 JVM (which works) and have access to a DataSource utilizing the thin Oracle JDBC drivers (classes12.zip). This I cannot get to work. I have tried a lot of combinations of the placement of classes12.zip, and I consistently get an error when trying to initiate the datasource of: ... Root cause: java.sql.SQLException: open: java.lang.ClassNotFoundException: oracle.jdbc. driver.OracleDriver at org.apache.struts.util.GenericDataSource.open(GenericDataSource. java:662) ... I have pasted the drivername from another JDBC-JSP-script which worked with this ZIP-file (abeit in Tomcat 4.0.1 with the IBM JVM), and I have tried placing it in $CLASSPATH (which Tomcat apparently ignores) and in tomcat/lib/common and in webapps/ROOT/WEB-INF/lib (I want the whole webserver to default to this application). No luck. Now I'm out of ideas. Somebody must have made this work - what have I missed or misunderstood? Thank you in advance for any hints, -- Thorbjørn Ravn Andersen Scandiatransplant, c/o Christian Mondrup 89 49 53 01 http://biobase.dk/~tra -- 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] -- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: RES: handling exceptions
Well, since Tomcat (for instance) runs the JVM you install then you get the logging and exception stuff as soon as you install 1.4, You do NOT get it within the tomcat code, but you do within your own code. i.e. if their stuff fails then you won't see it. But if your stuff fails, or logs then you get it as soon as you use JDK1.4 (I have yet to use it in anger, I must admit - probably for the reason you just stated :) Jonathan Want to write your code as if you used EJB, but you don't? Visit: http://www.faraway.co.uk/tallsoft/lowroad/ Message History From: Mark Galbreath [EMAIL PROTECTED] on 28/01/2002 09:52 EST Please respond to Struts Users Mailing List [EMAIL PROTECTED] To: 'Struts Users Mailing List' [EMAIL PROTECTED] cc: Subject: RE: RES: handling exceptions That's all very good (and I especially like the inclusion of the RegExp class in 1.4) but when will we have servlet and app containers that can support with 1.4? Mark -Original Message- From: Jonathan Gibbons [mailto:[EMAIL PROTECTED]] Sent: Monday, January 28, 2002 8:30 AM To: Struts Users Mailing List Subject: Re: RES: handling exceptions Hi, JDK1.4 is at final release candidate stage. They include nested exceptions (including all remote exceptions) and a logging framework. Use these, and not any other version (eg log4j), you will be future proofing your CV and code. Jonathan === For EJB and Struts code generators see: http://www.faraway.co.uk/tallsoft/lowroad/ Message History From: Chuck Cavaness [EMAIL PROTECTED] on 28/01/2002 08:22 EST Please respond to Struts Users Mailing List [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] cc: Subject: Re: RES: handling exceptions Unfortunately no because I think it contains some really nice features for Struts. This is a commerical product that I'm working on. However, I have received permission to discuss the exception framework in the Struts book that I'm working on for OReilly right now. Search the mailing list archives for the thread OReilly Struts Book. Chuck At 11:02 AM 1/28/2002 -0200, you wrote: Thanks. I want to know if your framework of handling exception will be opensource, like struts. -Mensagem original- De: Chuck Cavaness [mailto:[EMAIL PROTECTED]] Enviada em: segunda-feira, 28 de janeiro de 2002 10:27 Para: Struts Users Mailing List Assunto: Re: handling exceptions We've developed a pretty eloborate exception handling framework on my current project. We're using EJB on the backend, so we must also deal with remote type exceptions. First we catorgize exceptions into those that the user can recover from and those that they can't. Sort of like fatal and non-fatal. You also need to divide exceptions into system and application exceptions. System exceptions are ones like remote exception, or maybe some type of datastore exception. Application exceptions for us are ones like required fields were missing or duplicate values for a unique column. In our world, the same exception framework has to work for ERP systems, so it's not just the web container. Anyway, for those exceptions that the user can recover from like required fields missing, we catch those type of exceptions, create an ActionError with a message from the bundle specifically for that exception, and then forward back to the input page. This gives the user a chance to fix the problem and resubmit. For the more severe exceptions, we also catch those and forward to a system-error type page since there's probably nothing you can do about it anyway. We use an abstract base action that all of our actions extend. We have all of this behavior in the base action and none of the action classes have to worry about catching these exceptions. The abstract base action implements the perform and has an abstract doWork type method. The doWork method is wrapped with the try catch blocks. Each concreate action class implements the doWork and doesn't have to worry about the try catch. I hope that gives you some ideas. chuck p.s. Regarding your other post about using System.out in your action classes; I wouldn't recommend that approach. Use log4j instead. That way, you can shut off the debug logging externally by just editing the log4j.properties file. At 09:50 AM 1/28/2002 -0200, you wrote: Could somebody help me ? I have to many problems with handling exception of the Struts. what do you suggest to handling exception of the deployment applications? -- 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
RE: RES: handling exceptions
I agree choice is good. And Apache Jakarta is one (if not THE) best of them. JBoss is pretty dang fine too. Hats off. I also know that the recruiting marketplace tends to focus on core libs. Loads of projects steer clear of jakarta stuff BECAUSE it is free and open source. I guess my point of view is that it does come down to choice. You must look at the core API's and offerings and you must be aware of how they are evolving. I will personally tend to either write my own or go with the sun libs. This is a time problem. Open source teams are bright, motivated and produce tons of code that is often not well documented. They exert presure on the industry, and I think it's great they do so. But I will choose the core libs, simply because the next job is more likely to use the core libs. Log4j will rapidly change from the only offering, to yet another proprietary (yes I know, think recruiting person) lib. IMHO. It's not religion, it's choice! :) Jonathan Message History From: Cakalic, James [EMAIL PROTECTED] on 28/01/2002 11:04 EST Please respond to Struts Users Mailing List [EMAIL PROTECTED] To: 'Struts Users Mailing List' [EMAIL PROTECTED] cc: Subject: RE: RES: handling exceptions Hmm. Just because it appears in the JDK doesn't mean that it is a good thing. The original JSR47 has changed substantially from its original specification due, in no small part, to the efforts of the log4j community. Even so, its current incarnation still pales in comparison to log4j. You might take time to read the criticism of log4j authors and supporters at http://jakarta.apache.org/log4j/docs/srtw.html. The Apache Software Foundation -- you know they host the Jakarta project which includes Struts and log4j, right? -- does not support the JSR. As a user of Struts, imagine for a moment that JDK 1.5 included an MVC implementation similar to Struts but with reduced functionality and limited extension capability. Would you switch just because it was included in the JDK? Aside from functional differences, it is not practical or advisable for everyone to adopt JDK 1.4 as soon as it hits release. For one thing, Sun only releases the JDK for Windows and Solaris platforms. What if you are using Linux? Or AIX? Or HP-UX? Or AS/400? Or any of the other plethora of platforms which Sun does _not_ support? You'll have to wait for vendor implementations which could be months after the JDK release. As developers of application-server based software, most of us are also sensitive to the period of time it takes for the server vendors to support a new JDK. This was rather substantial between 1.2 and 1.3. I'm not optimistic about 1.4. I can't comment on the nested exceptions of 1.4 as I haven't really looked at this. But I would venture that my above comments apply there equally. Part of the benefit of a large and active open source community is that there are multiple solutions to every problem. We are able to evaluate the alternatives and choose a package that most closely meets our needs. Ultimately, one of these solutions may bubble to the top. But that solution won't always show up in the next JDK. And even if it does, that doesn't mean that it then becomes the _only_ solution for the entire community. Choice is a good thing. Best regards, Jim Cakalic -Original Message- From: Jonathan Gibbons [mailto:[EMAIL PROTECTED]] Sent: Monday, January 28, 2002 7:30 AM To: Struts Users Mailing List Subject: Re: RES: handling exceptions Hi, JDK1.4 is at final release candidate stage. They include nested exceptions (including all remote exceptions) and a logging framework. Use these, and not any other version (eg log4j), you will be future proofing your CV and code. Jonathan === For EJB and Struts code generators see: http://www.faraway.co.uk/tallsoft/lowroad/ Message History From: Chuck Cavaness [EMAIL PROTECTED] on 28/01/2002 08:22 EST Please respond to Struts Users Mailing List [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] cc: Subject: Re: RES: handling exceptions Unfortunately no because I think it contains some really nice features for Struts. This is a commerical product that I'm working on. However, I have received permission to discuss the exception framework in the Struts book that I'm working on for OReilly right now. Search the mailing list archives for the thread OReilly Struts Book. Chuck At 11:02 AM 1/28/2002 -0200, you wrote: Thanks. I want to know if your framework of handling exception will be opensource, like struts. -Mensagem original- De: Chuck Cavaness [mailto:[EMAIL PROTECTED]] Enviada em: segunda-feira, 28 de janeiro de 2002 10:27 Para: Struts Users Mailing List Assunto: Re: handling exceptions We've
