c:url or html:link from http to https?
Is there a simple way (e.g. standard tag with some oddball parameter), which will let me do a standard c:url or html:link, except, rewrite the leading http://; as https://;? I don't want to insert a hack scriptlet every time I want to do this.. Would rather use a tag. But I can't seem to find it Thanks, Bryan
RE: Zero-copy persistence with Struts?
On Fri, 2002-10-25 at 00:55, Hookom, Jacob John wrote: I guess I'm lost as to why CachedRowSet is a zero copy? The source code for the basicPortal's still copies all the data into another, internal collection. Regards, Jacob Here's how my thinking has evolved since I opened this thread a couple of days ago. If you're working in C/C++, zero-copy has a very black-and-white quality to it. However in Java, there's something of a middle position, and that is reference copying. Creating multiple references to an object already created, while certainly more expensive than not, is still not really copying the data. No object's are new'd, and little impact is made upon the garbage collector. That is to say (if I understand the JVM correctly), references going in and out of scope DO impact the garbage collector (in that they may trigger other objects to be gc'd), but they are not themselves gc'd. A lessened impact, but greater than zero. I see three possible scenarios. 1. If we assume that the raw data is in the ResultSet primitive, then the shortest, most optimal route, is to get the ResultSet all the way to the View (JSP pages). It can be wrapped inside another class (a decorator) to make it more bean-like or otherwise more JSP friendly. This minimizes memory use and even reference use. 2. The next best thing is a wrapper object which iterates through the ResultSet, and copies all the rows and columns, by REFERENCE, to a different kind of collection. I suspect that this is what CachedRowSet does. Note that it isn't really copying the data (e.g. no .clone()'s are going on, although someone correct me if I'mw rong), but instead it's copying the references returned by each ResultSet.getObject() call. 3. The worst thing would be a mechanism which literally copies the data, and not just the references to the data, using clone() or something. I can't imagine any of the persistence frameworks actually do this. So the question becomes - does, or does not, reference copying qualify as zero-copy as originally defined? I guess that's a larger issue, don't really want to tie up this Struts list with a debate like that. Actually - the more I look at it - scenarios #1 and #2 are probably equivalent in terms of use of references. Without going into too much detail - a decorator class which delegates the gets and sets to an private object (ResultSet in scenario #1) is probably doing just as much reference cloning as a wrapper which iterates through all rows at startup and copies the references into a private collection (scenario #2). It may be that CachedRowSet is as good as it gets. Bryan
RE: Zero-copy persistence with Struts?
On Fri, 2002-10-25 at 10:33, Craig R. McClanahan wrote: Conceptually, one can imagine a RowSet implementation that did not copy anything unless you tried to *modify* existing data, at which point it would keep dirty copies of the data that was changed. As long as the underlying ResultSet was scrollable, I'd bet you can avoid even the reference copying for the most common scenarios. Of course, any strategy like this still has to deal with the fact that the underlying ResultSet and Statement really do need to be closed (and the connection returned to the pool if you're using one) before the current request completes. Thanks for chiming in, Craig. The modification use-case is frankly not interesting to me, since good design dictates you do all your modification in the Struts Action (or its delegate), and not in the View. What was interesting to me in the first place, is being able to hand the View a large result set to render, without copying each data element (or even duplicating references) before handing it off. As for ensuring that the JDBC primitives get closed -- not very hard, really. My plan is to add them to a Collection after they're opened. Save the Collection into a request-context attribute. Forward to the JSP page. Then, lastly, a Filter picks up the Collection from the request context, and closes all the JDBC primitives. A set of factory functions could make these steps even easier, resulting in less code (and less things to remember to do) in each Struts action. Bryan
Zero-copy persistence with Struts?
I'm banging my brain against the sides of my skull trying to think of a way to do zero-copy JDBC persistence with Struts. What I mean by zero-copy is, basically, pass as much raw data as possible between the Model layer and the View layer. In pragmatic terms, this probably means taking a JDBC ResultSet in the Model layer, decorating it somehow (e.g. wrapping it in a DynaBean, or otherwise), and setting it into the Request attribute context, where the JSP page can iterate through and display it. Why bother? Performance. So here's the catch... if I insert the ResultSet into the request context, then somewhere later I need to close the ResultSet, and probably also the Statement which produced it and possibly even the Connection which was queried in the first place. It wouldn't make sense from a design standpoint to put this plumbing in each JSP page. My thinking is to build a Filter (Servlet 2.3) which, after all Model and View classes are called (e.g. Struts actions and JSP pages), close all the ResultSets, Statements, etc. This seems a little complex but it's the best pattern I can come up with. I was hoping for some (expert) opinions on this approach. The basic flow would be: 1. Struts Action does the following: 1a. grabs a connection from the pool 1b. create a Statement (or PreparedStatement), do the JDBC work, obtain a ResultSet 1c. Decorate the ResultSet as needed (e.g. wrap it inside a ResultSetDynaClass) 1d. Push the original Connection, Statement, and ResultSet onto a request context stack of some kind (with an agreed-upon key name). 2. JSP page does the following: 2a. Iterate through the ResultSet (or it's wrapper) as if it were a standard collection of standard beans. 3. Filter does the following cleanup: 3a. Retrieve the stack of open JDBC primitives from the request context. 3b. Close them all. This seems to achieve a nice level of zero-copyness without bothering the JSP page with messy plumbing details. Comments? Thanks, Bryan
Re: [OT] RE: Persistence Framework Comparison?
On Fri, 2002-10-04 at 15:28, David Graham wrote: This is a layer above all persistence frameworks (JDBC, JDO, EJB, OJB, etc.) that your application programs to. If you decide to change persistence frameworks, most of your code remains unchanged because it doesn't know which one you're using. I just don't think it's feasable to design a single, one-size-fits-all abstraction mechanism for all persistence layers. Many persistence systems have different tricks and different emphases which defy any attempt to neatly abstract them all. For example the Simper framework (which I wrote) is designed to cut through the MVC hierarchy like a butter knife, using the same beans in the Model (which is Simper itself), to the Controller (Struts and your actions), to the View (which is JSP, Velocity, etc). This is a FEATURE not a shortcoming, to reduce data copying across layers and simplify code management. Other differences you may find are in the realm of code generation. People tend to think that you're either writing beans by hand, or you're having a tool auto-generate classes for you. But this is a false assumption: Simper was designed to avoid code generation entirely. It's all dynamic, using DynaBeans and what I call point-and-shoot table configuration. You don't write classes, you don't even auto-generate classes. You just configure them, in a way similar to how Struts 1.1 lets you dynamically configure DynaActionForms. In short, I think trying to make a single layer which sits above all known persistence systems will just stifle creativity in approaches. Bryan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
content management ideas?
I was wondering how people handle frequent content updates with Struts/JSP? At my company, I'm building a site for which much of the static content (including things like the CSS stylesheet) will probably undergo frequent revision. I'd like to open it up for easier access, such as via FrontPage, so that I (the programmer) am not in the middle of such changes. But the site is very dynamic, with almost all page fetches resulting in a database query and dynamic content being built. So the site needs to be JSP-based, and I don't want the aforementioned Frontpagers modifying the raw JSP pages. Opinions appreciated on how this compromise can best be reached, Bryan
Struts -- JSF roadmap
I was wondering if there are others out there who have read the (preliminary) JSF (Java Server Faces) drafts, tutorials, etc., with opinions on how they relate to Struts? With Craig the spec lead on JSF, and Craig also being a primary mover (as well as original inventor) of Struts, I am hoping he will come forward with some real opinions on the matter, such as, where are the areas of overlap between the two? I believe there may be overlap in validation area, as well as in the general controller framework mechanism, though I'm not sure yet. Might there be anything like a long-term roadmap for Struts with some mention of JSF, and best practices for using the two together? Opinions appreciated, Bryan
Re: Struts -- JSF roadmap
Thanks Craig, I'm really looking forward to this... I believe that you're the one and only person who can paint a consistent roadmap including both JSF and Struts. This is independent of how deeply intertwined (if at all) the two frameworks are destined to become. Are the things you described at the JavaOne BOF in March online anywhere? Thanks, Bryan On Fri, 2002-09-06 at 12:45, Craig R. McClanahan wrote: I will have time to expand on this at length over the weekend ... but the things I described in my JavaOne BOF on Struts 1.1 last March look like they're going to come true (which is good news for Struts folks). Craig On 6 Sep 2002, Bryan Field-Elliot wrote: Date: 06 Sep 2002 12:33:37 -0600 From: Bryan Field-Elliot [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: Struts-User [EMAIL PROTECTED] Subject: Struts -- JSF roadmap I was wondering if there are others out there who have read the (preliminary) JSF (Java Server Faces) drafts, tutorials, etc., with opinions on how they relate to Struts? With Craig the spec lead on JSF, and Craig also being a primary mover (as well as original inventor) of Struts, I am hoping he will come forward with some real opinions on the matter, such as, where are the areas of overlap between the two? I believe there may be overlap in validation area, as well as in the general controller framework mechanism, though I'm not sure yet. Might there be anything like a long-term roadmap for Struts with some mention of JSF, and best practices for using the two together? Opinions appreciated, Bryan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Object Relational Bridge is great ? A Basic Problem
On Fri, 2002-07-05 at 15:50, Adolfo Miguelez wrote: The only way that I have seen to do something similar, is the mini-project SIMPER (Struts resources page), which is able to work out dynabeans (actually they are hashmaps in their guts), following a database schema, for it self. For me it has the problem that uses Servlets 2.3 filters and I am working with Servlets 2.2 specs. Adolfo, It's on the to-do list for Simper to reduce the dependency on Servlet 2.3 Filters for transaction demarcation - instead, to use them as an option, rather than a requirement. But before I can make those changes, first, I need to learn how to get by on 3 hours sleep a night with energy and enthusiasm to spare for projects like Simper. ;) Bryan
Re: Soap and Struts
I have successfully deploy Apache Axis (the new beta version) in the same webapp as a Struts application. This takes a little cut-and-pasting from Axis's web.xml file into yours, but it works fine. Bryan On Tue, 2002-04-02 at 02:10, Struts Newsgroup wrote: Subject: Soap and Struts From: Johannes Wolfgang Woger [EMAIL PROTECTED] === Hi, I would like to know: Can SOAP and Struts be brought to work together? Are there example thereof? Wolfgang
RE: JavaServerFaces (JSF) replacement for Struts?
I imagine that it would be a relatively simple task, to write an adaptor of some sort to map the JSF event model onto Struts actions. Bryan On Tue, 2002-04-02 at 12:41, Robert wrote: I went to the JSF session at JavaOne and the most asked question for the JSR group was What about Struts?. Their answer is that JSF will be flexible enough to work with whatever framework you want, including struts. JSF has an event model as well as the widgets, but you don't have to use them (events), so in that scenario, JSF HTML widgets would be a front-end for the Struts controller, effectively replacing/complimenting the Struts taglibs for presentation. Their idea was to have a flexible UI framework that could stand on its own with the event model, or work with whatever controller you wanted. Having said that, JSF is also supposed to have support for other client types, such as PDAs and phones, supplying a different widget set for each. They had a nice demo of using Dreamweaver to build the JSF portion, much like there is a Struts extension out there. - Robert -Original Message- From: Melanie Harris [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 02, 2002 1:37 PM To: [EMAIL PROTECTED] Subject: JavaServerFaces (JSF) replacement for Struts? Hi All, Out on http://www.javaworld.com/javaworld/jw-03-2002/j1-02-grapevine2.html today there is mention of the following: JavaServer Faces Sun Microsystems' Senior Software Engineer Roger Kitain from the JSF team outlined the one project I really hoped would release a specification and RI this week. JSF's functionality, layered on top of the JSP specification, includes change listeners on client-side widgets and a standard tag library (including a tree-view control). I'm working on a project in which such features would come in handy, so if you're listening guys, please release the RI as soon as you can! This sounds to me like JSF might be something that would be similar to Struts with added client-side widgets. I'd like to know what others think of JSF and if you think it might eventually become a preferred framework over struts, etc... ? Thanks in advance for your comments. -mel h - Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: JavaServerFaces (JSF) replacement for Struts?
I, for one, am excited to see JSF (based upon what paltry info I have read about it). I've done several hellishly complicated pages in JSP, doing all kinds of crazy stuff like generating dynamic JavaScript for the client, and invoking Struts actions (with different parameters) depending upon what the user clicked on. It sounds like JSF is made for building those kinds of pages (so I hope). And for it to fit well with Struts is a bonus. Bryan On Tue, 2002-04-02 at 19:11, Sandeep Takhar wrote: I went to the BOF following this session where Craig McLanahan was the main speaker. He basically finished off by saying that we will use whatever we want to from JSF. Just as there are pieces we use from the Servlet JSP specification. He is part of the expert group and is keen on making the jsf framework work for whichever frameworks are out there and specifically struts. He mentioned he had a working model with Struts JSF. I think that maybe there will be some releases of struts that incorporate JSF. Maybe there will be some that take advantage of jsp 1.2 servlet 2.3... I guess this is more a discussion for the dev group. I wouldn't count on JSF being a silver bullet. I think it has a long way to go and Struts will still be around and just end up incorporating the new JSF stuff. Craig said it -- and it is the truth: It is up to us... Sandeep --- Bryan Field-Elliot [EMAIL PROTECTED] wrote: I imagine that it would be a relatively simple task, to write an adaptor of some sort to map the JSF event model onto Struts actions. Bryan On Tue, 2002-04-02 at 12:41, Robert wrote: I went to the JSF session at JavaOne and the most asked question for the JSR group was What about Struts?. Their answer is that JSF will be flexible enough to work with whatever framework you want, including struts. JSF has an event model as well as the widgets, but you don't have to use them (events), so in that scenario, JSF HTML widgets would be a front-end for the Struts controller, effectively replacing/complimenting the Struts taglibs for presentation. Their idea was to have a flexible UI framework that could stand on its own with the event model, or work with whatever controller you wanted. Having said that, JSF is also supposed to have support for other client types, such as PDAs and phones, supplying a different widget set for each. They had a nice demo of using Dreamweaver to build the JSF portion, much like there is a Struts extension out there. - Robert -Original Message- From: Melanie Harris [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 02, 2002 1:37 PM To: [EMAIL PROTECTED] Subject: JavaServerFaces (JSF) replacement for Struts? Hi All, Out on http://www.javaworld.com/javaworld/jw-03-2002/j1-02-grapevine2.html today there is mention of the following: JavaServer Faces Sun Microsystems' Senior Software Engineer Roger Kitain from the JSF team outlined the one project I really hoped would release a specification and RI this week. JSF's functionality, layered on top of the JSP specification, includes change listeners on client-side widgets and a standard tag library (including a tree-view control). I'm working on a project in which such features would come in handy, so if you're listening guys, please release the RI as soon as you can! This sounds to me like JSF might be something that would be similar to Struts with added client-side widgets. I'd like to know what others think of JSF and if you think it might eventually become a preferred framework over struts, etc... ? Thanks in advance for your comments. -mel h - Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] __ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Perhaps TABOO Question, how to convert struts apps to non-struts
Your assumptions are most likely wrong. Whether or not your Servlet container supports hot-redeploy is a general question, and not at all specific to Struts. Therefore, the question of whether to strip out Struts from your application shouldn't even be on the table with repsect to your concerns. I use Tomcat 4.0 as my production server. It supports hot-redeploy by way of the manager reload command, which I can do remotely. As far as I can tell, this only causes a momentary lapse of responsiveness for the one web-app I am redeploying, and the rest of my webapps stay running just fine. No stopping and starting of the entire container is required. With this mechanism, I can change mappings in struts-config.xml, add new Actions, update existing classes, etc., all on-the-fly. The only thing it doesn't do, is reload the web.xml file, which, luckily, changes very infrequently (as opposed to struts-config.xml which changes often). Bryan On Wed, 2002-03-13 at 10:17, [EMAIL PROTECTED] wrote: A co-worker and I were talking about this yesterday and I was curious of the following Seems like in order to develop a struts application, you'll have to pay for a private JVM instance so you can start and stop the tomcat or other JSP engine so that it can re-read the config.xml files Question 1: Any plans for struts to change in the future where you can dynamically add new actions and forwards without having to stop and re-start the web-server? I would guess (although I could be wrong) that this would be pretty easy to do within struts in the future?I assume struts is loading the config files in a DOM.Adding a new servlet within struts to reload the config files and update the DOM does not seem like it would be that difficult... Question 2: Supposing I wrote this app in struts and I could not find a sponser to pay the $50 per month fees to host a web-site...Well, I could reconvert the apps to a non-struts approach and then pay only $10 per month (because I would no longer need to start/stop the web-server and would only need to dump updated JSP's and such) Is there a document/technique/pattern/advice on the best way to convert existing struts applications to non-struts? I know that putting javabeans back into the JSP files would be a royal pain but if it would save $40 per month, it may be the best way to go :-) thanks, Theron -- 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]
Re: Perhaps TABOO Question, how to convert struts apps to non-struts
Tomcat manager app is documented here: http://jakarta.apache.org/tomcat/tomcat-4.0-doc/manager-howto.html Personally, I don't know what are the current state-of-the-art best-practices for web hosting providers. However, I have to assume that they generally allow their customers to restart their web applications, without affecting their other customers' uptimes. Tomcat 4.x lets you start, stop, reload, deploy (from scratch), and undeploy web applications using the manager interface, all without affecting any other running web applications (and yes, they all share a single JVM). On Wed, 2002-03-13 at 11:27, [EMAIL PROTECTED] wrote: I'm curious.I did not know about the manager reload command. Where can I find out more about it? Also, if I went with a web-hosting service that had 1 and only 1 tomcat JVM instance, would the reload command be something the hosting site would allow me to run?Would the reload command affect all of the other folks using the same Tomcat JVM instance? If so, I would assume that the web-hosting service would not allow me to use the reload command and thus would still be stuck with the $50 per month private-jvm instance fee. thanks, Theron Bryan Field-Elliot To: Struts Users Mailing List bryan_lists@ne[EMAIL PROTECTED] tmeme.org cc: Subject: Re: Perhaps TABOO Question, how to convert struts 03/13/02 09:35 apps to non-struts AM Please respond to Struts Users Mailing List Your assumptions are most likely wrong. Whether or not your Servlet container supports hot-redeploy is a general question, and not at all specific to Struts. Therefore, the question of whether to strip out Struts from your application shouldn't even be on the table with repsect to your concerns. I use Tomcat 4.0 as my production server. It supports hot-redeploy by way of the manager reload command, which I can do remotely. As far as I can tell, this only causes a momentary lapse of responsiveness for the one web-app I am redeploying, and the rest of my webapps stay running just fine. No stopping and starting of the entire container is required. With this mechanism, I can change mappings in struts-config.xml, add new Actions, update existing classes, etc., all on-the-fly. The only thing it doesn't do, is reload the web.xml file, which, luckily, changes very infrequently (as opposed to struts-config.xml which changes often). Bryan On Wed, 2002-03-13 at 10:17, [EMAIL PROTECTED] wrote: A co-worker and I were talking about this yesterday and I was curious of the following Seems like in order to develop a struts application, you'll have to pay for a private JVM instance so you can start and stop the tomcat or other JSP engine so that it can re-read the config.xml files Question 1: Any plans for struts to change in the future where you can dynamically add new actions and forwards without having to stop and re-start the web-server? I would guess (although I could be wrong) that this would be pretty easy to do within struts in the future?I assume struts is loading the config files in a DOM.Adding a new servlet within struts to reload the config files and update the DOM does not seem like it would be that difficult... Question 2: Supposing I wrote this app in struts and I could not find a sponser to pay the $50 per month fees to host a web-site...Well, I could reconvert the apps to a non-struts approach and then pay only $10 per month (because I would no longer need to start/stop the web-server and would only need to dump updated JSP's and such) Is there a document/technique/pattern/advice on the best way to convert existing struts applications to non-struts? I know that putting javabeans back into the JSP files would
Re: Perhaps TABOO Question, how to convert struts apps to non-struts
On Wed, 2002-03-13 at 12:02, John M. Corro wrote: I've found that every service provider that I've worked w/ or seen that provides a shared JVM won't allow you to deploy classes. In those situations I've had to write everything in JSP - SUCKS! Of course that's silly, because JSP pages are basically classes anyway... -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Server-side Charting libs?
I was wondering if anyone has any positive experience with open-source charting libraries, with Struts? I need to generate a chart on the server (from a Struts action) and send it back to the client as a Jpeg, PNG, etc. I have messed with (a tiny bit) JFreeChart and Chart2d. Both appear (at first glance) to have issues with headless environments, which my server definitely is (no X server installed). I'm using JDK 1.3. At one point I read that JDK 1.4 has better support for graphics primitives on headless environments, but I don't know if the above two libraries can take advantage of that. A penny for anyone's thoughts? Bryan
RE: Server-side Charting libs?
Thanks, I don't know what Xvfb is, can you give me a pointer to an explanation? Is it something that's part of AWT, or part of jCharts, or something else? Thanks, Bryan On Sun, 2002-03-10 at 15:12, Matt Read wrote: I use jCharts (jcharts.sourceforge.net) which is the best I've found for the actual chart creation but you still have the same problem with the Java 1.3 AWT libraries needing an X server. I just use Xvfb which seems to work fine, let me know if you need any help configuring it. Other than that I've also looked at the Java 1.4, attempted to follow the instructions at http://java.sun.com/products/java-media/2D/forDevelopers/java2dfaq.html#xvfb with no luck and went back to Xvfb. Let me know if you get it working. Matt. -Original Message- From: Bryan Field-Elliot [mailto:[EMAIL PROTECTED]] Sent: 10 March 2002 22:04 To: [EMAIL PROTECTED] Subject: Server-side Charting libs? I was wondering if anyone has any positive experience with open-source charting libraries, with Struts? I need to generate a chart on the server (from a Struts action) and send it back to the client as a Jpeg, PNG, etc. I have messed with (a tiny bit) JFreeChart and Chart2d. Both appear (at first glance) to have issues with headless environments, which my server definitely is (no X server installed). I'm using JDK 1.3. At one point I read that JDK 1.4 has better support for graphics primitives on headless environments, but I don't know if the above two libraries can take advantage of that. A penny for anyone's thoughts? Bryan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: StackOveflowException - poolman
You are running the 2.1-beta of Poolman. While I did not see the specific bug you refer to (StackOverflowException), I did see other bugs, including a random and occasional NullPointerException. Since 2.1-beta has been in beta since October, and since there have been no development since then, and since the primary author has apparantly decided not to continue developing it, I suggest you rollback to the last stable version 2.0.4. Bryan On Fri, 2002-03-08 at 08:01, Satish Jeejula wrote: Hi All, I am running a web application under apache1.3.22\Tomcat3.3 using struts1.0\poolman2.1-b1 on Windows NT server. After running fine for 5-6 hrs, tomcat crashes with StackOverflowException. Then for all the requests that come afterwards, an error is thrown with huge stacktrace (I printed it out, which came out to be 18 pages!! in length) onto the browser. The only way that I can bring tomcat in running mode is to restart it. The stack trace points to com.codestudio.sql.PoolManConnection.setAutoCommit(Unknown Source) method. The stack trace is repetitive after first few lines. This error is also thrown on to tomcat console window. Is this problem with Tomcat or struts or poolman or with my web application?? I have increased the size of heap, changed my code so that it does not print stacktraces etc etc but to no avail. Any help is appreciated. Thanks, Satish -- 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]
Re: [Off Topic] Poolman Setup
I'm no expert (having just picked up poolman a week ago) but, it appears to me that you don't have poolman.xml in the right place. It needs to be in either of the following places: 1. In the WEB-INF/classes directory (this is what I do) 2. Jar'd up, and then put the Jar in the WEB-INF/lib directory (as opposed to what you tried, which is putting the un-jar'd XML file in the lib directory). Bryan On Thu, 2002-03-07 at 15:47, Eddie Bush wrote: I've done everything (I think) that poolman requires in order to function, and yet it does not. After placing only the required jars into my \lib folder, and having no success with Poolman starting, I threw all of them in. It still doesn't work. I wasn't at all sure, from the documentation, where I should poke the poolman.xml file. Initially I had it in my WEB-INF directory. Then, I copied it to the \lib directory. Still no luck. Every time Poolman is started, I get the same exact error - a null pointer exception. This occurs when poolman is calling parseXML from loadConfiguration. The relevant piece of the stacktrace is: java.lang.NullPointerException at com.codestudio.management.PoolManConfiguration.parseXML (PoolManConfiguration.java:121) at com.codestudio.management.PoolManConfiguration.loadConfiguration (PoolManConfiguration.java:75) at com.codestudio.management.PoolManBootstrap.init (PoolManBootstrap.java:61) at com.codestudio.management.PoolManBootstrap.init (PoolManBootstrap.java:54) at com.codestudio.sql.PoolMan.start (PoolMan.java:97) The rest of the stacktrace goes into my servlet - which worked fine before I tried to kick off Poolman in it's init method. I have also tried not calling start, but, instead, just allowing Poolman to do it's 'lazy' initialization - same exact result. I would be most appreciative if someone out there could give me a 'heads up'. I'm running Tomcat 4.0.1 (I can't see why that would matter) and JDK 1.3. Thanks! Eddie
Re: Struts and encryption
Many database have their own extensions for encryption, or one-way hashing, used for things like password storage. That's probably the best choice you could make. Bryan On Thu, 2002-03-07 at 19:36, Andrew H. Peterson wrote: Is there a struts preferred method of handling encryption/decryption? I am authenticating users via a database lookup. I want to store the encrypted password in the database. If struts doesn't have a preferred method of encryption/decryption, can someone point me to a good Java API for encryption/decryption? Thanks. ahp -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: simper-NeXt
Simper's representation of a database row is in the class SimperBean.
SimperBean is a relatively shallow extension of the DynaBean (actually
DynaBean is an interface -- BasicDynaBean is a concrete class which
SimperBean extends) -- see the commons project BeanUtils for the
source to DynaBean.
Table columns, as well as relations, are represented as dynamic
properties using the DynaBean/DynaClass mechanisms. It does NOT produce
get and set methods for each column or relation. Instead, there is a
single get method and a single set method, whose first parameter is
the property name. This isn't a Simper convention, it's a DynaBean
convention.
DynaBeans/DynaClasses are supported by the latest (nightly builds) of
the other beanutils classes, which is why the Struts tags like
bean:write, logic:iterate, etc., all work with SimperBeans (and why
I chose DynaBeans as a basis).
With all that said, I really don't know much about the new Nesting tags
or how they work. If they rely upon the same introspection mechanisms as
logic:iterate, bean:write, etc., then they should work with Simper
just fine. That's just a guess.
Bryan
On Wed, 2002-03-06 at 08:04, John Menke wrote:
Just give it a bash. Run a simper model through the NeXt tags. I lay my
money on it working as-is.
Sounds great. I will do this today. Just trying to understand the
internals a little better.
So as long as the simper beans have bean property conformity (eg:
getMyProperty, setMyProperty) then the beans are ready to go with NeXt
as they are wihout mods. I'd be very surprised if it needed mods,
really. You can use Castor types straight up because the properties are
valid bean properties.
I understand this it looks like Simper will create these methods property
methods
A nested bean is simply one object that is returned by the method of
another.
This is what was unclear to me. I guess when you create relations between
tables in Simper these get Methods to return another bean will be created in
the SimperBean automatically?
-Original Message-
From: Arron Bates [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, March 06, 2002 12:47 AM
To: Struts Users Mailing List
Subject: Re: simper-NeXt
Almost.
NeXt is only working off of Bean properties, and as with all beans, it
doesn't care as to what goes on behind those method definitions. The
constructor is one of those details it cares not about.
So as long as the simper beans have bean property conformity (eg:
getMyProperty, setMyProperty) then the beans are ready to go with NeXt
as they are wihout mods. I'd be very surprised if it needed mods,
really. You can use Castor types straight up because the properties are
valid bean properties.
A nested bean is simply one object that is returned by the method of
another. As each property getter method has get on the front of it,
we're laughin'. At the point of changing a property, you'll need that
set on the front of it, naturally. For example, to get the nesting
level deeper in my Monkey examples, I had a fake nested property that
returned this.
eg:
public MonkeyBean getOtherMonkey() { return this; }
To the internals of BeanUtils (the part of Struts that makes it all
happen), it's treated as an entirely different object. It makes no other
assumptions, rightly so. The system is that explicit.
Just give it a bash. Run a simper model through the NeXt tags. I lay my
money on it working as-is.
Arron.
John Menke wrote:
I'm working through the Simper examples and the NeXt examples and trying to
understand how I can use both together. Here is what I have so far:
In the NeXt you associate nested beans with a parent and children
relationship by inserting a private member variable to the parent bean the
will create a new child bean:
ie.
snip - from MonkeyStruts Tutorial
private BunchBean bunchBean = new BunchBean();
This will give us a new instance of the BunchBean when this MonkeyBean is
created. Just what we want. Now we need to provide the getter method to the
bean under the property name pickedBunch. This will create a getter which
will look something like this example...
Example...
public BunchBean getPickedBunch() {
return this.bunchBean;
/snip
This enables you to make forms like this:
snip - from MonkeyStruts Tutorial
html:form action=/action-tutorial.do
Monkey Name: nested:text property=monkeyName /br
Monkey Age: nested:text property=monkeyAge /br
br
nested:nest property=pickedBunch
Bunch Size: nested:text property=bunchSize /br
Bunch Weight: nested:text property=bunchWeight /br
Re: simper and linking tables (many to many relationships)
m-m is not yet supported in an elegent way by Simper. In the docs I mention 1-1 and 1-m but I don't mention m-m for this reason. As a tempoary workaround to get going, create another field in your portfolio_stock table, called id, and use it as a (pseudo) primary-key (assigning it unique values, etc, upon every insert). I know that m-m tables shouldn't require a primary key field (other than a composite of the foreign keys), but that's just what Simper requires at this point. Also -- perhaps you might join the simper-users mailing list at SF? I'm not sure we want to bog down the Struts users lists with Simper usage discussions. Thanks! Bryan On Wed, 2002-03-06 at 10:56, John Menke wrote: I have the following model: -- Table: stock CREATE TABLE stock ( stock_pkey int4 NOT NULL, symbol varchar(5) NOT NULL, name varchar(50) NOT NULL, price numeric(5, 3), CONSTRAINT stock_symbol_key UNIQUE (symbol), CONSTRAINT stock_pkey PRIMARY KEY (stock_pkey) ); -- Table: portfolio CREATE TABLE portfolio ( portfolio_pkey int4 NOT NULL, name varchar(50), investor_pkey int4, CONSTRAINT portfolio_pkey PRIMARY KEY (portfolio_pkey), CONSTRAINT unnamed FOREIGN KEY (investor_pkey) REFERENCES investor (investor_pkey) ON DELETE NO ACTION ON UPDATE NO ACTION NOT DEFERRABLE INITIALLY IMMEDIATE ); -- Table: portfolio_stock CREATE TABLE portfolio_stock ( stock_pkey int4 NOT NULL, portfolio_pkey int4 NOT NULL, CONSTRAINT portfolio_stock_pkey PRIMARY KEY (stock_pkey, portfolio_pkey), CONSTRAINT unnamed FOREIGN KEY (portfolio_pkey) REFERENCES portfolio (portfolio_pkey) ON DELETE NO ACTION ON UPDATE NO ACTION NOT DEFERRABLE INITIALLY IMMEDIATE, CONSTRAINT unnamed FOREIGN KEY (stock_pkey) REFERENCES stock (stock_pkey) ON DELETE NO ACTION ON UPDATE NO ACTION NOT DEFERRABLE INITIALLY IMMEDIATE ); The portfolio_stock table is a linking table and does not have a primary key. Is it possible to use this type of table in Simper? registerTable requires a primary key and my linking table does not contain a primary key. I guess my question is can you do many to many relationships? If not is there a workaround? -john -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Poolman is gone, I hardly knew ya
According to the website: http://wwwcodestudiocom/ Poolman is no more What a bummer for me as I just learned it and deployed it on a new project less than a week ago! Previously, I was using the pooling mechanism built into Struts, but due to many folks refering to it as not industrial strength, I moved on (to Poolman) So what else are people using? Is there one built into Tomcat now? I read that somewhere, I think in a mailing list message here, but I can't seem to find any docs on it (looking at the Tomcat 40 docs) Is there a mature one in the Jakarta Commons? I see a dbcp but I'm not sure of it's status, if people are using it, etc Opinions appreciated! Bryan
Re: Simper with MySQL
Yes,
There are two functions with Simper where we do mapping of
java.sql.Types to Java classes, and vice versa.
The error you're getting is that the functions mentioned above don't yet
understand java.sql.Type of -1. Do you know offhand what type that is?
It can be added easily to Simper, I can make the change and commit to
sourceforge CVS in a flash.
Bryan
On Tue, 2002-03-05 at 05:11, Matt Raible wrote:
I'm trying to get Simper working with MySQL and I'm getting the following error
when I try to access http://localhost/simper (Tomcat 4.x running on port 80).
exception
javax.servlet.ServletException: Exception while Simper.initEverything tried to
invoke user-supplied initializer: java.lang.IllegalStateException: Invalid
sqlType: -1
at org.netmeme.simper.Simper.initEverything(Simper.java:260)
at org.netmeme.simper.Simper.doFilter(Simper.java:158)
/exception
root_cause
java.lang.IllegalStateException: Invalid sqlType: -1
at org.netmeme.simper.Simper.getClassFromSQLType(Simper.java:401)
at org.netmeme.simper.Simper.registerTable(Simper.java:294)
at org.netmeme.simper.demo.DemoInit.init(DemoInit.java:41)
at org.netmeme.simper.Simper.initEverything(Simper.java:258)
at org.netmeme.simper.Simper.doFilter(Simper.java:158)
/root_cause
SQL Script I used to load MySQL:
sql_script
--
-- SQL commands to generate the simperdemo database
--
CREATE TABLE IF NOT EXISTS authors (
id int NOT NULL,
name text,
email text,
Constraint authors_pkey Primary Key (id)
);
CREATE TABLE IF NOT EXISTS books (
id int NOT NULL,
id_author integer,
title text,
publishdate timestamp,
Constraint books_pkey Primary Key (id)
);
CREATE TABLE IF NOT EXISTS next_id_table (
table_name text,
next_id int
);
--INSERT INTO next_id_table (table_name, next_id) values ('authors', 0);
--INSERT INTO next_id_table (table_name, next_id) values ('books', 0);
--
-- Create a foreign key relationship (books.id_author to authors.id)
-- To my knowledge, MySQL does not support referential integrety...
alter table books add constraint fk_books_authors foreign key (id_author)
references authors (id)
/sql_script
log_messages
[HttpProcessor[80][1]] DEBUG org.netmeme.simper.Simper - doFilter
[HttpProcessor[80][1]] DEBUG org.netmeme.simper.Simper - initEverything
[HttpProcessor[80][1]] DEBUG org.netmeme.simper.Simper -
initClassName=org.netmeme.simper.demo.Demo
Init
[HttpProcessor[80][1]] DEBUG org.netmeme.simper.demo.DemoInit - init
[HttpProcessor[80][1]] DEBUG org.netmeme.simper.Simper - registerDataSource
[HttpProcessor[80][1]] DEBUG org.netmeme.simper.Simper - registerTable(books)
[HttpProcessor[80][1]] DEBUG org.netmeme.simper.Simper - column name: id,
type: class java.lang.Int
eger
[HttpProcessor[80][1]] DEBUG org.netmeme.simper.Simper - column name:
id_author, type: class java.l
ang.Integer
/log_messages
Any ideas?
Matt
__
Do You Yahoo!?
Try FREE Yahoo! Mail - the world's greatest free email!
http://mail.yahoo.com/
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: simper - versionColumn?
It's an unimplemented placeholder for a future version, in which I hope to implement a basic optimistic concurrency pattern. If your tables have an integer column dedicated to versioning, Simper will automatically increment it on every update, after first testing to be sure that the value hasn't changed. When I implement this, you can choose not to use it by passing null as the column name for the version, which makes your code today forward-compatible. The use-case this all supports, is in putting a SimperBean away somewhere (e.g. in a session variable), pulling it out later (e.g. during some future HTTP request), and updating the row, without holding a connection or a transaction the entire time. Bryan On Tue, 2002-03-05 at 20:19, John Menke wrote: The registerTable method takes a String versionColumn as a parameter: public void registerTable(String tableName, String idColumn, String versionColumn, IPKGen primaryKeyGenerator) What is versionColumn used for? In the sample application both of the example tables set it null. I cannot determine it's purpose. -john -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Simper with MySQL
It's LONGVARCHAR (== java.sql.Types value of -1). Two lines of code to
be added to Simper to support this... Will be doing another checking (to
sf) in the short term.
FYI, the null type is 0. And just what the heck does that mean? I've
never heard of a column type of null (as opposed to a column which
allows nulls, which is totally different).
Bryan
On Tue, 2002-03-05 at 20:47, Ted Husted wrote:
It's probably null. I've noticed that different pools handle this
differently. I believe Resin returns zero instead.
Bryan Field-Elliot wrote:
Yes,
There are two functions with Simper where we do mapping of
java.sql.Types to Java classes, and vice versa.
The error you're getting is that the functions mentioned above don't yet
understand java.sql.Type of -1. Do you know offhand what type that is?
It can be added easily to Simper, I can make the change and commit to
sourceforge CVS in a flash.
Bryan
On Tue, 2002-03-05 at 05:11, Matt Raible wrote:
I'm trying to get Simper working with MySQL and I'm getting the following
error
when I try to access http://localhost/simper (Tomcat 4.x running on port 80).
exception
javax.servlet.ServletException: Exception while Simper.initEverything tried
to
invoke user-supplied initializer: java.lang.IllegalStateException: Invalid
sqlType: -1
at org.netmeme.simper.Simper.initEverything(Simper.java:260)
at org.netmeme.simper.Simper.doFilter(Simper.java:158)
/exception
root_cause
java.lang.IllegalStateException: Invalid sqlType: -1
at org.netmeme.simper.Simper.getClassFromSQLType(Simper.java:401)
at org.netmeme.simper.Simper.registerTable(Simper.java:294)
at org.netmeme.simper.demo.DemoInit.init(DemoInit.java:41)
at org.netmeme.simper.Simper.initEverything(Simper.java:258)
at org.netmeme.simper.Simper.doFilter(Simper.java:158)
/root_cause
SQL Script I used to load MySQL:
sql_script
--
-- SQL commands to generate the simperdemo database
--
CREATE TABLE IF NOT EXISTS authors (
id int NOT NULL,
name text,
email text,
Constraint authors_pkey Primary Key (id)
);
CREATE TABLE IF NOT EXISTS books (
id int NOT NULL,
id_author integer,
title text,
publishdate timestamp,
Constraint books_pkey Primary Key (id)
);
CREATE TABLE IF NOT EXISTS next_id_table (
table_name text,
next_id int
);
--INSERT INTO next_id_table (table_name, next_id) values ('authors', 0);
--INSERT INTO next_id_table (table_name, next_id) values ('books', 0);
--
-- Create a foreign key relationship (books.id_author to authors.id)
-- To my knowledge, MySQL does not support referential integrety...
alter table books add constraint fk_books_authors foreign key (id_author)
references authors (id)
/sql_script
log_messages
[HttpProcessor[80][1]] DEBUG org.netmeme.simper.Simper - doFilter
[HttpProcessor[80][1]] DEBUG org.netmeme.simper.Simper - initEverything
[HttpProcessor[80][1]] DEBUG org.netmeme.simper.Simper -
initClassName=org.netmeme.simper.demo.Demo
Init
[HttpProcessor[80][1]] DEBUG org.netmeme.simper.demo.DemoInit - init
[HttpProcessor[80][1]] DEBUG org.netmeme.simper.Simper - registerDataSource
[HttpProcessor[80][1]] DEBUG org.netmeme.simper.Simper -
registerTable(books)
[HttpProcessor[80][1]] DEBUG org.netmeme.simper.Simper - column name: id,
type: class java.lang.Int
eger
[HttpProcessor[80][1]] DEBUG org.netmeme.simper.Simper - column name:
id_author, type: class java.l
ang.Integer
/log_messages
Any ideas?
Matt
__
Do You Yahoo!?
Try FREE Yahoo! Mail - the world's greatest free email!
http://mail.yahoo.com/
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
-- Ted Husted, Husted dot Com, Fairport NY US
-- Developing Java Web Applications with Struts
-- Tel: +1 585 737-3463
- Web: http://husted.com/about/services
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Are there any patters for pager design with EntityBeansproviding access to the database?
The best approach is to use a database-specific extension (since paging is not part of SQL standard syntax). I use PostgreSQL which has very nice and easy paging support (using LIMIT and OFFSET keywords). I've tried to do it once before using Oracle but had some trouble (as I recall the rownum didn't work as intuitively as you would hope or expect). The fallback position is to load the whole resultset into memory and store it as a session variable. This is a bad practice if the resultset can be large (a thousand rows or more for example). Bryan On Tue, 2002-03-05 at 21:12, Alex Paransky wrote: I was wondering how people are implementing paging capability in struts. In other words, if the result set comes back with 2000 rows, how do you display page 4 of 100 with 20 results per page? Is writing custom SQL commands to depend on ROWNUM or something of that sort always required? Are there any easy mechanism to do paging? Would this be a good place to use a Statefull Session Bean and store it in to the session? Thanks. -AP_ http://www.alexparansky.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: validate() and session expiry
On Mon, 2002-03-04 at 19:20, Matt Read wrote: I can see a solution where in validation() methods I check that the session is still valid but this seems clumsy to me Is it good MVC design for the request to be handled by the Model before the Controller gets to see it? Am I incorrectly putting business logic into the validation() method when it should be dealt with further down the chain? Or should I be handling my authentication and session management in a subclass of the ActionServlet? I'd appreciate any insights Matt You're putting too much business logic in the form's validate() method Struts best-practices dictacte that form validation should really be thought of as a two-phase process Phase 1 should check for basic form correctness (eg did they really put a valid number in the text field meant for a number? Is this a valid date? Did they remember select a radio button value?) This phase should be handled by the form bean's validate() method Phase 2 should be put into your Actions themselves, and should be the business logic validation (eg is the user logged in? Is the date they entered a valid date as far as the database of available dates is concerned? Is the name they entered a valid name as far as the database is concerned?) As a side note - the phase 1 validation (calling the validate() method) doesn't have to be done automatically by Struts You can set validate=false in your Action definition (struts-configxml), and call validate() manually from within your action if you choose This is useful when sometimes you want validation, sometimes you don't For example I often have one Action which handles record creation as well as editing Often I want validation in the create use-case, but not in the edit use-case, and so I manually call validate() from the action rather than have Struts do it automatically Bryan
Re: Nesting Extension and persistance strategy
I don't think what you guys are discussing, is too far off from the Simper framework I've developed: http://www.netmeme.org/simper/ It doesn't have anything to do with the current Nesting library, but, it does many of the things you've discussed in this thread, including automatic change detection (and writing/committing of changes at the end of each http request, automatically), as well as support for relations between tables in a manner similar to the nesting library. For example, if you have tables named books and authors, and you have already retrieved a row from the authors table (into the variable theAuthor), you can refer to properties theAuthor.name, theAuthor.address, and you can also refer to relations, such as theAuthor.books, which will (on-the-fly) do a query against the books table for books belonging to the given author, and return a collection. These can be walked through and displayed using standard bean:write, logic:iterate, etc, or they can be updated from within Actions (and written back to disk at the end of the request). Bryan On Mon, 2002-03-04 at 21:16, Arron Bates wrote: Well, yeah. That'd do the trick too. Probably in a fashion that would be manageable, clean, and garner the respect of OO gurus, developers and peers alike. Very apt solution. You can notify the observer from inside your setters rather than query the submit button. Mainly because you will have to do some checking to see if the data did change or if it's just being reset to the same thing. If you show a form, not change anything and submit it. The data may as well be totally different, as the bean properties will be set in each instance anyways. So in your setter you'll have to do comparisons on the incoming data, may as well just notify the observer while you're there. Note: Don't commit or actually make changes as soon as a change is made. Otherwise you'll have an updates firing for every property, for every bean. And that would be bad. :) Just note down the changed beans, and kick off the commit from the observer from within your action. Then you know that all the bean processing is finished, and you can go ahead and mess with your bean states. But to quote Ghostbusters... yes, have some :) Arron. John Menke wrote: Aaron, what do you think of implementing the Observable interface with the DataBeans? This could help with detecting updates. (Inserts and Deletes are easier because you can determine the action via querying the submit button). -john -- 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]
Re: Urgent help - Connection reset by peer error with Struts ..
How would you compare Poolman to the various pooling systems within Jakarta (such as DBCP, or the one built into Tomcat 4 if I'm not mistaken?) I can't keep track of them all Thanks, Bryan On Sun, 2002-03-03 at 07:23, Ted Husted wrote: For a production application, use Poolman www.codestudio.com You can then have your data access objects get the connection using the Poolman findDataSource method, and leave the Struts controller out of it. -- Ted Husted, Husted dot Com, Fairport NY US -- Developing Java Web Applications with Struts -- Tel: +1 585 737-3463 -- Web: http://husted.com/about/services Satish Jeejula wrote: Hi All, I am using struts for my web application under apache\tomcat configuration. Everything seems to working fine and then after some time of no activity the application hangs. When I check the tomcat console for errors, I see lot of the 'Connection reset by peer' errors ... After little bit of research, I found that this problem is caused when my application tries to use a connection which was closed by database. The connection allocated on servlet initialization is kept effectively forever. Unfortunately, the database eventually times out the database socket and application is still using the now-broken connection. Since, I am using connection pooling that comes along with Struts I assumed that this should never happen. Is this bug in Struts Connection Pooling? Is there any way to get around this problem?? If I have to use any other connection pooling mechanism's .. can any of you suggest one? I need help very urgently. Thanks for all your help Satish -- 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]
[Announce] Simper 0.2
Simper is a simple JDBC persistence mechanism for Java web apps It features many of the interesting features of EJB, such as automatic transaction demarcation (by way of Servlet Filters), and automatic change detection of database rows (by way of DynaBeans) Lastly, the notation by which you reference rows, as well as relations between tables, is extremely JSP friendly http://wwwnetmemeorg/simper/ 02 is not a new release (it's been out for about a month), but, a SourceForge project has been set up, with mailing lists, CVS, etc, so that others can discuss and contribute (as I am getting quite busy lately) Bryan
RE: changing from *.do to /do/* screws up everything?
That doesn't seem like it buys you anything... Then what's the point of hiding JSP pages behind WEB-INF, if all of them are available through a simple forwarding action? This is the (small) paradox I find with the whole hiding behind WEB-INF thing. It seems like it should be a good idea, but what do you do about JSP pages you really want to be shown without any pre-processing (by that I mean, processing by an action before rendering the JSP). Bryan On Thu, 2002-02-28 at 09:55, Jeff Krueger wrote: You could setup a action mapping that just does a forward. action path=/signup forward=/WEB-INF/docroot/signup.jsp / Jeff Krueger -Original Message- From: Bryan Field-Elliot [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 27, 2002 1:54 PM To: Struts Users Mailing List; Ted Husted Subject: Re: changing from *.do to /do/* screws up everything? On Wed, 2002-02-27 at 11:56, Ted Husted wrote: It originally came up in response to inquiries about how to enforce MVC. If all the JSPs are under WEB-INF, then the only possible way to get to them is through an action. Users can't just bookmark a JSP and pop into the middle of something. Though, if you self-impose the recommended model of linking only to actions, the value of actually storing the pages under WEB-INF diminishes, since the address of the page is never directly exposed to the user. So Ted, one small gap in my Struts knowledge (in terms of best-practices) is, what's the recommended way to build a pass-through Action which really does just display a JSP page? I have a signup.jsp form, which for the sake of this discussion, is going to be underneath WEB-INF. I really don't need any processing in an action to execute prior to displaying the form -- I just want to link to the (empty) form. Since I can't link directly to it, I need some kind of really shallow Action to get at it. How do you usually build this? Bryan -- 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]
Re: changing from *.do to /do/* screws up everything?
Put this inside the head block of all your JSP pages: html:base/ Here is a URL to the docs for this tag: http://jakarta.apache.org/struts/doc-1.0.2/struts-html.html#base It solves exactly this problem. Bryan On Wed, 2002-02-27 at 10:39, Rob Breeds wrote: Hi I hope this is me being dumb but I have a working Struts application that uses a *.do servlet mapping for ActionServlet Because I found that the servlet spec doesn't allow partial URL mappings for security (eg. I can't specify a url-mapping of '/pub*'), I must now change my app to use /do/* Seems like a fine idea, and Ted says its cool :) So, I changed the servlet mapping to '/do/*' and references to '*.do' in my JSPs. Now my app sort of works but all relative links are now broken - CSS, images, JavaScript files e.g. I have a URL of 'rest of path/do/header' and this is specified in the config file as: action path=/header forward=/WEB-INF/pages/header.jsp/ The page loads OK but the JSP references images like this: img src=images/find_obj.gif This used to work because images was a directory directly under the war directory, but now, the image has a path of img src =/do/images/find_obj.gif which isn't found. Simarly for references to CSS files and JS files. why is the /do/ prefix being added? Please could anyone tell me what I have to do to get my JS, CSS and images to load without changing every reference to them in every JSP to include a /do/? Thanks Rob -- 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]
Re: changing from *.do to /do/* screws up everything?
Then perhaps you can insert your own plain-jane base tag (not a JSP-rendered base tag) to point to the root of your web? Bryan On Wed, 2002-02-27 at 10:58, Rob Breeds wrote: Thanks for suggestion but I can't use html:base because all my JSPs are under WEB-INF\pages Putting html:base/ in will cause images (and any relative urls) to have URLs of img src=WEB-INF/pages/images/find_obj.gif which is even worse (doesn't work at all) and defeats the point of putting pages under WEB-INF! Rob |+- || Bryan | || Field-Elliot | || bryan_lists@ne| || tmeme.org | || | || 27/02/2002 | || 17:49 | || Please respond | || to Struts | || Users Mailing | || List | || | |+- ---| | | | To: Struts Users Mailing List [EMAIL PROTECTED] | | cc: | | Subject: Re: changing from *.do to /do/* screws up everything? | | | | | ---| Put this inside the head block of all your JSP pages: html:base/ Here is a URL to the docs for this tag: http://jakarta.apache.org/struts/doc-1.0.2/struts-html.html#base It solves exactly this problem. Bryan On Wed, 2002-02-27 at 10:39, Rob Breeds wrote: Hi I hope this is me being dumb but I have a working Struts application that uses a *.do servlet mapping for ActionServlet Because I found that the servlet spec doesn't allow partial URL mappings for security (eg. I can't specify a url-mapping of '/pub*'), I must now change my app to use /do/* Seems like a fine idea, and Ted says its cool :) So, I changed the servlet mapping to '/do/*' and references to '*.do' in my JSPs. Now my app sort of works but all relative links are now broken - CSS, images, JavaScript files e.g. I have a URL of 'rest of path/do/header' and this is specified in the config file as: action path=/header forward=/WEB-INF/pages/header.jsp/ The page loads OK but the JSP references images like this: img src=images/find_obj.gif This used to work because images was a directory directly under the war directory, but now, the image has a path of img src =/do/images/find_obj.gif which isn't found. Simarly for references to CSS files and JS files. why is the /do/ prefix being added? Please could anyone tell me what I have to do to get my JS, CSS and images to load without changing every reference to them in every JSP to include a /do/? Thanks Rob -- 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]
Re: changing from *.do to /do/* screws up everything?
On Wed, 2002-02-27 at 11:56, Ted Husted wrote: It originally came up in response to inquiries about how to enforce MVC. If all the JSPs are under WEB-INF, then the only possible way to get to them is through an action. Users can't just bookmark a JSP and pop into the middle of something. Though, if you self-impose the recommended model of linking only to actions, the value of actually storing the pages under WEB-INF diminishes, since the address of the page is never directly exposed to the user. So Ted, one small gap in my Struts knowledge (in terms of best-practices) is, what's the recommended way to build a pass-through Action which really does just display a JSP page? I have a signup.jsp form, which for the sake of this discussion, is going to be underneath WEB-INF. I really don't need any processing in an action to execute prior to displaying the form -- I just want to link to the (empty) form. Since I can't link directly to it, I need some kind of really shallow Action to get at it. How do you usually build this? Bryan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: best practices for logging in
You want to set a session-level boolean value (actually Boolean, not boolean, since you can only store proper objects in the session scope), indicating whether the user has logged in. Here are three ways to build a framework with Struts to check for logged-inness. I've used all three in succession, and my preference nowadays is the last method. 1. At the start of each of your Action's perform() methods, have a common block of code to check for logged-inness, and redirect to a login page as appropriate. Primary disadvantage is that you have to remember to cut and paste this code into all your actions which require a login. 2. Extend Struts' Action class to your own *abstract* class, which adds the (unimplemented method) boolean requiresLogon(). All of your actions should extend this abstract class, and implement their own requiresLogon() method which simply returns true or false. Then, in the base class's perform() method, you can call requiresLogon(), and if true, then test for logged-inness. Lastly, you can call the derived class's real perform method, which actually you'll have to rename to, myPerform or something slightly different. This is a cleaner approach than #1 but still a bit messy. I've used this approach for both requiresLogon(), and requiresDatabase() (in which case I establish and break down a connection, all in one place). My preference is now #3, below. 3. Don't use Struts at all for your login check. Instead, use Servlet Filters (requires a Servlet 2.3 container such as Tomcat 4.0). Implement a filter (they're simple, really!) which checks for logged-inness, and if false, then redirects to some login page. This has a clear advantage in that it separates security checking from the code of your Actions. In addition, it has a clear advantage in that it's declarative at the configuration file (XML) level, rather than embedded in your code. By that I mean, in the web.xml file, you specify which URL's (or which patterns of URL's) the filter applies to, rather than embedding this in your actual Java code. My favorite approach to this kind of thing. Some other notes: 1. If the login check fails, you can do your user a favor by saving the URL they requested into a session variable. Then, in your logon code, upon successful login, you can redirect the user back to the URL they originally requested. A nice convenience. 2. logged-inness is a perfectly legitimate and grammatically correct expression. Bryan On Sun, 2002-02-24 at 08:46, Edward Q. Bridges wrote: what is the general accepted practice for handling logins and securing access with struts? from a review of the archive, it seems that way *not* to do it is to use a isLoggedIn flag that gets passed from page to page. and, that the canonical approach is to utilize Action.perform(...) to determine whether or not the person has logged in. so, how exactly is the Action class determining whether or not the user is logged in? does it set a session-level boolean variable and check that on every invocation of the perform method? has anyone encountered special cases where they've had to come up with some unique way of handling logins? many thanks! --e-- -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: best practices for logging in
Yes, you (and Torgeir Veimo in a prior message) are right, I could use container-managed authorization. I'm just not a big fan of it -- it hasn't bought me much, and since authorization/login check is such a trivial amount of code, I just prefer it all under my wing. Perhaps thats wrong. On Sun, 2002-02-24 at 14:07, Robert Claeson wrote: Bryan Field-Elliot wrote: 3. Don't use Struts at all for your login check. Instead, use Servlet Filters (requires a Servlet 2.3 container such as Tomcat 4.0). You could, of course, also use J2EE's declarative AI features. -- Programmers are tools for converting caffeine into code. --Anonymous -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Dynamic Properties and Database
Take a look at my Simper package, which does basically this: http://www.netmeme.org/simper Still rough around the edges, but within a week or so, I hope to make a polished project out of it (hosted at SourceForge). I've been saying within a week or so for about a month now :( but will really try to get to it soon. In the meantime it's downloadable and usable in it's current form. Please read the README first, it explains what the whole project is about. Bryan On Fri, 2002-02-15 at 04:11, Peter Pilgrim wrote: HI I have had a look Jan Sorenson's Dynamic Properties contribution http://husted.com/struts/resources/DynamicProperties.htm How useful is this code for reading from and writing to arbitary database tables. It sounds like I can map any database column name to an action form property. For example given the SQL table create table COFFEE ( coffee_id integer, coffee_namevarchar(null), coffee_descvarchar(null), . . . ) Mapped to action form accessor and mutator public int getCoffee_Id() ; public void setCoffee_Id( int ) ; . . . It looks a bit nasty especially the underscores but I think it could work. Comments -- Peter Pilgrim ++44 (0)207-545-9923 Swamped under electionic mails -- 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: logic:iterate with Struts template
Consider double-checking that productArrayList is in fact a session-scope object (or request-scope), and not a page-scope object. If it's page-scope, then it won't be visible to included pages. On Mon, 2002-01-28 at 13:43, Brian M. Zhang wrote: Hi, I have a jsp page which contains the following logic:iterate: logic:iterate id=product type=com.myCompany.myPackage.Product name=productArrayList tr tdbean:write name=product property=name filter=true//td tdbean:write name=product property=desc filter=true//td /tr /logic:iterate productArrayList is a session variable holding an ArrayList object for com.myCompany.myPackage.Product classs. This page works just fine when it is by itself. However, when I use it as part of another page using Struts template, the logic:iterate / doesn't work any more. The template setting is ok as everything works just fine when the logic:iterate / part is removed. Any ideas? Thanks. Brian -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Template mechanism tutorial anyone?
I love the simplicity of Templates as well. The bummer with them is, they aren't nestable, as far as I can tell (can anyone tell me differently?). On Tue, 2002-01-15 at 02:09, flare wrote: On 14 Jan 2002 at 23:12, Michael Mehrle wrote: Hi guys/gals: I'm new to the list and to Struts - though I got it all up and running via Tomcat. Again, help with this would be welcome I'm using templates in almost every portal/site, I found Tiles great but often overkill, templates are lightweight and really easy to use, even for a web developer without any coding skill. Look at the nice JavaWorld article (go to http://www.javaworld.com and search for templates) and the struts ML archives for examples, you'll be up and running in a couple of minutes ;) Flare -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Programming Style, Custom Tags - Opinions?
Thanks for the long opinion Ted. I agree with most of what you discussed, which is that the Actions should be delegating to a real business layer of back-end classes and methods, which can be re-applied to a non-Struts front-end. It's your first paragraph which I'd like to continue to discuss (and which was in reference to my original topic of discussion): On Fri, 2001-12-21 at 15:15, Ted Husted wrote: Personally, I would suggest that an Action should always be used to create whatever JavaBean helpers the view needs. The views only responsiblity should be to render the beans. Where these beans come-from or go-to is the controller's business. This puts all the business logic behind Actions, and lets the presentation layer focus on rendering the presentation without knowing anything about the model. In the case of JavaServer Pages, it also makes it much easier to use standard tags, like those that ship with Struts, rather than having to write your own. This will be even more advantageous when JSPTL is finalized. This is where I am having a problem -- if the Action is always responsible for creating whatever JavaBeans the View needs, then doesn't that unnecessarily couple (tightly) the View and the Controller? If, suddenly, the View programmers decide they not only need to render the current user's Name, but also now need to start rendering the last five log entries for a user (on a particular JSP page), then they have to go back to the Action developer and ask for those additional beans to be stuffed into the scope. The approach I was arguing for makes it much more loosely coupled -- the Action just does it's work, and the View just renders whatever it feels it needs to render. Of course, it makes sense for the Action to stuff a bean into a scope to communicate it's own activity results; however, general model rendering info isn't being plugged in by the Action; instead, the View (JSP pages) request them as they see fit. I think this looser coupling makes for a much more manageable (less ripple-effect) design. However, a by-product of it, is the ballooning of custom JSP tags so that the View can get at the model, which I am having a problem with, and for which I was soliticing alternative perspectives. Bryan
Re: Programming Style, Custom Tags - Opinions?
Thanks again Ted, I didn't mean to imply that my View developers were also developing their own Tags. They aren't. Instead, I develop the Model, which includes back-tier business logic to perform actions, and return a bean (or a collection of beans) as a result. High-level business method names like: postMessage deleteMessage getMessageByID getMessagesByTopic getUserByID getUsersByGroup getLogEntriesByUser Then, my Struts actions delegate all of their real work to these back-tier business methods, and in many cases, put the resulting bean (or bean collection) straight into the Request scope and forward on out to a JSP page. In terms of this model-rendering discussion, however -- I also tend to implement JSP custom tags which call out to these same business methods -- usually the getXXX variety, and almost never any other kind (in other words, only those methods which *read* the model). In that way, the View (JSP developers) can render the beans returned by the preceeding Action, and anything else they darn well please, by way of my published JSP Tag library (which is just a mirror of all my model-tier's getXXX methods). Now that I've fully explained my methodology, let me say that I am with you that perhaps this is coupled tightly to the Model (although not at all to the Controller). Where I don't follow you is how there's any other way (e.g. your Layered pattern) to achieve the same results. Perhaps what you're saying between the lines, is that rather than implement custom tags, I should be implementing more smarter JavaBeans which can navigate the model. You're right that this reduces my dependency on JSP tags, and opens the door to other presentation engines like Velocity. I think I'd like to give that a try. Historically, virtually 100% of my JavaBeans have been simple Value Objects, composed of nothing but properties, getters, and setters. So let's assume that, for the benefit of the View, the model-reading methods I was previously wrapping into JSP tags I will now wrap into smarter JavaBeans (to be navigated by way of Struts or JSPTL tags). Moving forward, then, do you think it's a bad idea to give them model-specific JavaBeans, or should I seek to wrap up my model in generic, non-specific collections of properties, which I am guessing is similar to your ContextHelper class (or Craig's new DynaBean, which I am eager to work with)? Thanks for this great discussion, Bryan
Programming Style, Custom Tags - Opinions?
Hi all, I wanted to collect a few opinions on programming style with respect to Struts and JSP. The following have been my guiding principles for the last several Struts projects I've done: 1. When a JSP page needs to ALTER the model (e.g. data will be written), a Struts Action should be used. 2. When a JSP page needs to RENDER the model (e.g. read data, and transform it into HTML), a JSP custom tag should be used to get the data into a local (scriptable) variable/bean. Over time, this strategy produces a roughly 1:1 ratio of Actions to Custom Tags. Sometimes there's even a gray area concerning where to put the logic -- e.g. if the very act of reading data will produce a log entry, technically that's writing to the model -- however, I tend to put primarily read operations into custom tags. One reason why I do this, is so that the Actions don't necessarily have to know every single kind of model data the resulting JSP page may want to draw from. I leave it up to the JSP page to decide. A drawback is that you end up with so much code in both camps -- it would be nice if all the code could, for example, extend the same base classes, or something. I'd appreciate hearing some opinions on whether or not others have found this style workable, and if not, then what works better. Thanks, Bryan
Re: 404 error when placing JSPs beneath WEB-INF
I've tried this with Struts but found it to be unwieldly in the struts-config.xml file. Do you make an action, and a forward, for every single real JSP page? Kind of a pain in the buttocks if you ask me, but I see where you're going with the idea of centralizing access control, exception handling, etc. I wonder if I'm not doing it as elegantly as I could (with respect to the struts-config file). I also wonder if using the new Filtering scheme (which Struts doesn't do anything with), is a more elegant way of inserting that layer in front of every JSP access, rather than a Struts action. Thanks, Bryan On Tue, 2001-12-18 at 10:53, Ted Husted wrote: I do strongly recommend that all references go through actions or forwards, and that a Struts application never link directly to a JSP. This makes where the JSPs are kept less of an issue, since that location is never revealed on the address bar. Heck, there's no reason for anyone to even know that they are JSPs back there to access ;-)
OT: Good secure-ID solution? (Key FOB)
Hi, I apologize for this being off topic, but while this has nothing to do with Struts, still I think this is a list where I might find knowledgable people with good info. I'm looking for a good, cheap secure ID card or ID KeyFob solution, which I can integrate with my Struts application. The device(s) are just cards or keychain devices, with an LCD display. The LCD display shows a 8-digit number, and this number changes to some other pseudo-random value every 60 seconds. It's a password, good for one minute. On the server side, you've got some code running which maps a username to a 60-second password (algorithmically), and authenticates the user thus. RSA has great devices, and they're around $60 each which is fine with me. However, they want you to buy and run their server-side software as well. I'm not into that -- I'd just rather have a simple standardized algorithm and implement my own server-side checking (tied into my own database etc) within my Servlet classes, rather than run some 3rd party software on my server. Does anyone know of such a thing? Thanks, Bryan
Re: Performance, Reflection, and Object Creation vs. Cacheing
Thanks for the insights Ted, Please help me if I'm misinterpreting. But looking at your code, it seems like your populate still takes a plain Bean as it's destination, although it can use a property set (in this case, a ResultSet) as the source. This reduces the proliferation of Value (or other Bean) classes by 50%, but not 100%. In your scenario, which set of beans still need to be developed as plain old beans rather than dynamic sets of properties (e.g. the Entity beans, the Value Objects, or the Struts Form Beans, etc?)? Thanks, Bryan Ted Husted wrote: public static void populate(Object bean, ResultSet resultSet)
Performance, Reflection, and Object Creation vs. Cacheing (was: Barracuda talk)
Ted, I read your rebuttal tonight re: Barracuda, and I have questions about one of your points. Actually this has nothing to do with Barracuda: - Reflection Every recent report I've seen says reflection is no longer a point of concern. Ditto for object creation and garbage collection. The latest advice is that is can be more expensive to cache an object that recreate it. - This is incredibly important stuff! I'm sick to death of making tons of EJB entity beans, and then Value Objects (or data objects) which are very similar, and with Struts, Form Beans which again are very similar. Often I wish I could just use generic property sets (using HashMap, or any other generic collection). But I have resisted on principle, because I thought it would be a poor performer compared to straight Java variables and getters and setters. But here you are saying reflection is no longer a point of concern. What information have you got in this regard? Also, you go on to say 'ditto for objection creation, and that it's more expensive to cache an object than recreate it. Where are you getting this information? It goes against the design considerations of virtually every highly optimized Java system I've seen, including EJB which goes to EXTREME lengths to reuse rather than recreate. You see the same pattern with JSP custom tags (nowadays they are pooled), and you even see the same thing in the Servlet spec design (which is to have one multithreaded instance of the servlet class, rather than one per user which would make more logical sense). So, my apologies if this is off-topic of Struts, but these seem like very important and impactful design issues, relevent (even if peripherally) to good Struts design and development. Thanks, Bryan
Thoughts on Workflow and multiple devices...
Some end-user thoughts on the design of the Workflow system -- For the foreseeable future, I'll be building sites which need to be accessed from multiple devices, with different presentation requirements. This includes the standard desktop browser, but also includes WAP, and likely also includes Palm OS web clipping. To support the same business logic with different presentations, may I stress that the Workflow piece be designed to be as MVC-ish as the rest of Struts. For example -- perhaps you define logical activities, composed of logical steps and logical pre- and post-conditions. But as far as mapping these things to actual screens (JSP pages) -- keep in mind that, depending upon the device, the developer might want to put all steps onto one screen, or split them across multiple screens (or even skip certain steps for certain devices). By keeping a loose coupling between JSP pages and the logical definition of the workflow (and by allowing the flexibility of combining or splitting steps among pages), I'll have better support for this kind of UI problem. Thanks, Bryan
Struts 1.0b1 exception during logic:redirect and HTTPS
We've successfully deployed an application using Struts 1.0b1 and it's working fine. Yesterday however, we introduced an SSL certificate onto the web server, and now, when my application is accessed via HTTPS instead of HTTP, certain exceptions occur on a regular basis. One of them is in logic:redirect. Here are the relevent snippets: Environment: RH Linux 7.1 Sun JDK 1.3 Apache 1.3.14 Tomcat 3.2.1 Relevent JSP code: %-- Make sure a patient is logged in; if not, forward to the logon page --% logic:notPresent name=patient logic:redirect forward=patientLogonPage/ /logic:notPresent Exception details: Name: java.lang.NullPointerException Message: null Stack: java.lang.NullPointerException at org.apache.tomcat.facade.HttpServletResponseFacade.isEncodeable(HttpServletResponseFacade.java:333) at org.apache.tomcat.facade.HttpServletResponseFacade.encodeRedirectURL(HttpServletResponseFacade.java:122) at org.apache.struts.taglib.logic.RedirectTag.doEndTag(RedirectTag.java:274) at jsp.patient._0002fjsp_0002fpatient_0002fcontact_0002dform_0002ejspcontact_0002dform_jsp_4._jspService(_0002fjsp_0002fpatient_0002fcontact_0002dform_0002ejspcontact_0002dform_jsp_4.java:135) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:119) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServlet.java:177) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:318) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:391) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.tomcat.core.ServletWrapper.doService(ServletWrapper.java:404) at org.apache.tomcat.core.Handler.service(Handler.java:286) at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372) at org.apache.tomcat.core.ContextManager.internalService(ContextManager.java:797) at org.apache.tomcat.core.ContextManager.service(ContextManager.java:743) at org.apache.tomcat.service.connector.Ajp13ConnectionHandler.processConnection(Ajp13ConnectionHandler.java:160) at org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:416) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java:498) at java.lang.Thread.run(Thread.java:484) struts-config.xml contains: !-- == Global Forward Definitions == -- global-forwards [...other entries ommitted...] forward name=patientLogonPage path=/jsp/patient/logon.jsp/ /global-forwards I've seen discussions that you cannot forward to a page using a different protocol (HTTP vs HTTPS) than the one the user came into your page with. However in my case, the source page is already being accessed via HTTPS, and the destination page, well, it's referenced via relative URL rather than absolute. Any help would be appreciated. Is this a bug I'm likely to find fixed in beta-2, or am I configuring or doing something wrong somewhere? Thanks, Bryan
Re: Potential Security Flaw in Struts MVC
There is a security risk here as you describe, if (and only if) you are using a generic introspection-based function (like Struts' PropertyUtils.copyBean) to copy the values from the UserForm object to the User object. There are several ways to avoid this -- 1. Don't put an admin flag "setter" method in your User class. 2. In UserAction, don't use the generic bean copy utility -- instead, manually copy the values, excluding the admin flag. 3. As a smarter alternative to #2, don't use a generic bean copy utility -- instead, write an intelligent copy function in the User class, which "knows" that it's copying FROM a UserForm, TO a User, and therefore, skip the copying of the Admin flag. Bryan Jeff Trent wrote: 002501c0d70b$9df009a0$6401a8c0@PROVIDENCE"> I may be wrong about this (only been working w/ Struts for a week now). But I do see a potential security flaw in struts that I would like to hear from others regarding. Consider a simple set of struts classes that represent a user in a system. You would probably have classes that look something like this: User (the model representing the user) UserForm (an enrollment form for a new user) UserAction (Saves the UserForm information to db, etc) The User class would have accessors and modifiers like getFirstName(), setFirstName(), getAdministrativeUserFlag(), setAdministrativeUserFlag(), etc. The basic implementation of the UserForm is to take the UI form data, introspect the beans, and call the correct modifier of the UserForm bean based on the fields contained within the UI submission/form. A developer of course would not expose the "Administrative User Flag" option on the UI for enrollment (that would be found possibly in some other administrative-level module). However, if someone is familiar with the db schema and the naming convention the developer used, that user could subvert the application by writing his own version of the UI which contains an "Administrative User Flag" field (or any other field for that matter) and the basic form processing in Struts will kindly honor the request and set the "Administrative Flag" on the user. Unless, of course, the developer makes special provisions to prevent this behavior. However, its not entirely obvious to the struts user (in my opinion) that this is even a concern. Am I making sense here? - jeff
Re: Potential Security Flaw in Struts MVC
Christian, You kick ass! Apologies to the sensitive but that was a great explanation of a very obscure but important problem. Bryan Christian Cryder wrote: I usually just lurk on this list, but I think I'll pipe in here.
Re: Potential Security Flaw in Struts MVC
Either you are misunderstanding Struts, or I am misunderstanding you.
Struts will populate your UserForm for you, prior to your UserAction being
called. However, it is your responsibility to, within UserAction, copy the
values from UserForm to User.
Bryan
Jeff Trent wrote:
00bd01c0d728$40864960$6401a8c0@PROVIDENCE">
Bryan,
This is good advice. However, I thought
the beans are populated off of the request outside of the control of my
Action class derivation. Therefore, copyProperties() doesn't pertain.
- jeff
- Original Message -
From:
Bryan Field-Elliot
To:
[EMAIL PROTECTED]
Sent: Monday, May 07, 2001 1:14 PM
Subject: Re: Potential Security Flaw inStruts MVC
There is a security risk here as you describe, if (and only if)you are
using a generic introspection-based function (like Struts'PropertyUtils.copyBean)
to copy the values from the UserForm object to theUser object. There
are several ways to avoid this --
1. Don't put anadmin flag "setter" method in your User class.
2. In UserAction, don't usethe generic bean copy utility -- instead,
manually copy the values, excludingthe admin flag.
3. As a smarter alternative to #2, don't use a generic beancopy utility
-- instead, write an intelligent copy function in the User class,which
"knows" that it's copying FROM a UserForm, TO a User, and therefore,skip
the copying of the Admin flag.
Bryan
Jeff Trentwrote:
002501c0d70b$9df009a0$6401a8c0@PROVIDENCE" type="cite">
I may be wrong about this (only been
working w/ Struts for a week now). But I do see a potential security
flaw in struts that I would like to hear from others regarding.
Consider a simple set of struts classes
that represent a user in a system. You would probably have classes that
look something like this:
User (the
model representing the user)
UserForm (an enrollment
form for a new user)
UserAction (Saves
the UserForm information to db, etc)
The User class would have accessors
and modifiers like getFirstName(), setFirstName(), getAdministrativeUserFlag(),
setAdministrativeUserFlag(), etc. The basic implementation of the
UserForm is to take the UI form data, introspect the beans, and call the
correct modifier of the UserForm bean based on the fields contained
within the UI submission/form. A developer of course would not expose
the "Administrative User Flag" option on the UI for enrollment (that
would be found possibly in some other administrative-level module).
However, if someone is familiar with the db schema and the naming convention
the developer used, that user could subvert the application by writing
his own version of the UI which contains an "Administrative User Flag"
field (or any other field for that matter) and the basic form processing
in Struts will kindly honor the request and set the "Administrative
Flag" on the user. Unless, of course, the developer makes special provisions
to prevent this behavior. However, its not entirely obvious to the
struts user (in my opinion) that this is even a concern. Am I making
sense here?
- jeff
Re: Potential Security Flaw in Struts MVC
Yes I think that's a problem; interesting that you would do it that way,
I never saw it from that perspective. But I believe the intent of Struts
(e.g. the examples, etc) is that your ActionForms are really just forms --
conduits for moving field values between HTML forms and Java primitives.
They shouldn't really involve themselves with your model at all. Keep your
model interactions in your Action perform()'s.
Other comments I've seen in this vein are with regards to validation. In
your ActionForms' validate methods, you should validate the data for basic
type-correctness (e.g. did the user really enter a date in the date field?).
But for business-model validation, save it for the Action class (e.g. did
the user enter a date not already booked?). This is sort of a two-phase validation
approach which separates basic validation logic from business model logic.
Bryan
Jeff Trent wrote:
018501c0d739$fa597bd0$6401a8c0@PROVIDENCE">
Ah, this maybe a problem in the way I've
adapted Struts. I reflect all UserForm method calls directly into the contained
User object owned by the UserForm. So for instance, I have
public class UserForm extends ActionsForm
{
protected User user;
...
public String getName()
{
return user.getName();
}
public void setName(String name)
{
user.setName(name);
}
...
}
Now can you begin to see my original concern?
Maybe I need to separate the model from the form a little more than what
I have.
- jeff
- Original Message -
From:
Bryan Field-Elliot
To:
[EMAIL PROTECTED]
Sent: Monday, May 07, 2001 4:38 PM
Subject: Re: Potential Security Flaw inStruts MVC
Either you are misunderstanding Struts, or I ammisunderstanding you.
Struts will populate your UserForm for you, priorto your UserAction being
called. However, it is your responsibility to, withinUserAction, copy
the values from UserForm toUser.
Bryan
Jeff Trent wrote:
00bd01c0d728$40864960$6401a8c0@PROVIDENCE" type="cite">
Bryan,
This is good advice. However, I thought
the beans are populated off of the request outside of the control of
my Action class derivation. Therefore, copyProperties() doesn't
pertain.
- jeff
-Original Message -----
From:
BryanField-Elliot
To:
[EMAIL PROTECTED]
Sent:Monday, May 07, 2001 1:14 PM
Subject:Re: Potential Security Flaw in Struts MVC
There is a security risk here as you describe, if (and onlyif) you
are using a generic introspection-based function (like Struts'PropertyUtils.copyBean)
to copy the values from the UserForm object to theUser object. There
are several ways to avoid this --
1. Don't putan admin flag "setter" method in your User class.
2. In UserAction,don't use the generic bean copy utility -- instead,
manually copy thevalues, excluding the admin flag.
3. As a smarter alternative to #2,don't use a generic bean copy utility
-- instead, write an intelligentcopy function in the User class,
which "knows" that it's copying FROM aUserForm, TO a User, and therefore,
skip the copying of the Adminflag.
Bryan
Jeff Trent wrote:
002501c0d70b$9df009a0$6401a8c0@PROVIDENCE" type="cite">
I may be wrong about this (only
been working w/ Struts for a week now). But I do see a potential
security flaw in struts that I would like to hear from others
regarding.
Consider a simple set of struts
classes that represent a user in a system. You would probably have
classes that look something like this:
User
(the model representing the user)
UserForm (an
enrollment form for a new user)
UserAction
(Saves the UserForm information to db, etc)
The User class would have accessors
and modifiers like getFirstName(), setFirstName(), getAdministrativeUserFlag(),
setAdministrativeUserFlag(), etc. The basic implementation of the
UserForm is to take the UI form data, introspect the beans, and
call the correct modifier of the UserForm bean based on the fields
contained within the UI submission/form. A developer of course
would not expose the "Administrative User Flag" option on the UI
for enrollment (that would be found possibly in some other administrative-level
module). However, if someone is familiar with the db schema and
the naming convention the developer used, that user could s
Re: (struts + EJB) example
and making the whole thing manageable. Perhaps it was my error to start off with that perception. But in the end, the whole Struts framework ended up handling only a relatively small piece of my entire application. The front controller servlet aspect of it is useful but there are certainly other front controller patterns to use (such as the one in the J2EE pattern catalog or their Pet Store app, or the one in the OReilly JSP book).And the form validation framework I am certainly grateful for and probably is the biggest piece I am happy to be using, but again, Struts isn't the only game in town there (see Barracuda for what at first glance appears to be a much more robust form validation framework). Hope this helps, it's good for me to write about the experience as a way of processing and debriefing myself, in addition to helping others. Bryan [EMAIL PROTECTED] wrote: Hi Bryan, Thanks for your reply and pointer! I got several questions for u and all experts of this list, Any reasons behind regarding the recommendation about the tags vs. actions dilemma? == =1. if the Java code will alter your Model, then put it in an Action (or = =equivalent).= =2. if the Java code is only reading your Model to aid in rendering some = =portions of it, the put it in a custom JSP tag. = == Do u mind to give me more information about your application architecture? For the sake of discussion, let's assume I only have two tables (parent and child), what will be the steps for doing fundamental stuff like query, update and create? For example, use case for query of record: 1. jsp captures all required parameters for the query 2. action form creates corresponding query form bean and validation 3. action invokes business delegate and then service locator for getting a jndi reference to corresponding EJB (session or entity) 4. action form (another one) creates corresponding display form bean with attribute of list of records (e.g. array) 5. action (another one) copies EJB to list 6. jsp displays results using iterate tag for the list Thanks again, I appreciate! P.S. I'm very very new for such development environment (struts + EJB), please be patience 8) Chris -Original Message- From: Bryan Field-Elliot [mailto:[EMAIL PROTECTED]] Sent: April 26, 2001 4:39 PM To: [EMAIL PROTECTED] Subject: Re: (struts + EJB) example Chris, I don't have an example for you, but I have written a brief post-mortem analysis of a major project just finished which used EJB and Struts. It can be found here: http://www.mail-archive.com/struts-user%40jakarta.apache.org/msg06088.html It was posted to this group, but no one had anything to say in response, other than someone who referred me to a different framework (Barracuda), which I will be investigating next. Regards, Bryan [EMAIL PROTECTED] wrote: Folks, Anyone know where I can get an example which use struts and ejb? Thanks in advance! P.S. Struts can work out of box with latest version of orion (i.e. 1.4.8) now 8) Chris
Re: (struts + EJB) example
Chris, I don't have an example for you, but I have written a brief post-mortem analysis of a major project just finished which used EJB and Struts. It can be found here: http://www.mail-archive.com/struts-user%40jakarta.apache.org/msg06088.html It was posted to this group, but no one had anything to say in response, other than someone who referred me to a different framework (Barracuda), which I will be investigating next. Regards, Bryan [EMAIL PROTECTED] wrote: Folks, Anyone know where I can get an example which use struts and ejb? Thanks in advance! P.S. Struts can work out of box with latest version of orion (i.e. 1.4.8) now 8) Chris
A quick Struts project post-mortem
I'm just wrapping up a fairly major project which was built on top of Struts (thereby giving me a chance to learn it). I'm a little mixed about the experience, not being entirely sure the value add was there. I definitely feel "helped" by Struts' form validation infrastructure, and I would probably appreciate the message resource bundling more if my application needed to be internationalized (which it didn't). On the flip side, the Action/ActionMapping system, while elegant, only covered about half of my application (since I had to write roughly as many custom JSP tags as I did Struts actions). Lastly (and this last comment is independent of Struts), I've come to the conclusion that a strict adherence to the MVC pattern is by no means a magic pill to perfect application manageability.. that is, plenty of worms still manage to crawl out of the woodwork, and I have a sense that the Java community needs something more than just a good MVC system in order to build an elegent (and robust) web application. The application was also based upon EJB, for even more fun and complexity. On the tags vs. actions dilemma - I took the approach recommended in various other publications etc., which is: 1. if the Java code will alter your Model, then put it in an Action (or equivalent). 2. if the Java code is only reading your Model to aid in rendering some portions of it, the put it in a custom JSP tag. Some quick metrics and "factoids" about my project: 1. 19 Struts actions 2. 18 custom JSP tags (for which I could find little in Struts to add value) 3. 15 ActionForms 4. 13 database tables 5. Since the application uses EJB session beans for all business logic, virtually all of the Struts actions as well as JSP custom tags ended up being very shallow pass-throughs of parameters to the EJB bean, and return values back to the JSP pages. I'm wondering if there are others out there who have finished projects and reached similar conclusions as mine (in particular, about having to implement lots of Tags and not finding much value-add in incorporating Struts classes into them). I am also interested in someone graciously providing a birds-eye view of Struts and Turbine, with relative strengths and weaknesses. I'm sure that, on the whole, Turbine probably has a completely different "central focus" than Struts (apples and oranges), but as someone who is just coming off a Struts project and is a bit daunted by the Turbine "welcome literature" (as I was initially with Struts), I would sure love someone's overview from a Struts-centric perspective. Lastly, I'm not leaving this group, as I am responsible for managing the lifecycle of the application I've described above, even though development is basically "done" (for now!). Thanks, Bryan
Re: Frames, concurrency, and EJB Stateful Session beans - a problem.
Thank you Dan --
As I emailed at around midnight last night, I have everything taken care
of, using Jason Pringle's pattern. It's probably very similar to the Business
Delegate pattern you describe (which I will read today). Basically I implemented
a handler class for the Stateful Session Bean, which contains a duplicate
of all of the bean's remote interface methods. In it's constructor, I create
a private instance of the "real" bean. And in all of the methods, I'm just
passing through the parameters to the "real bean" and returning it's return
values, to the client. In this case, the "client' is always a Struts Action
or a custom JSP tag.
All of these methods are wrapped in a simple "syncronized" statement to the bean instance:
String businessMethod1(int param1, int param2) throws RemoteException {
syncronized(theBean) { return theBean.businessMethod1(param1, param2); }
}
That wasn't so bad, really, and it solved my concurrency problem completely.
For good measure I also implemented the "common business interface" pattern
(or whatever it's properly called), in which I have a single interface defining
my business methods, which is extended (or implemented) by the RemoteInterface,
the Handler, and the actual Bean. This makes for tidier code but wasn't really
germaine to my syncronization problem.
Lastly, you say "if I have any suggestions, you'd love to hear them". Well
here's a big suggestion -- an EJB container should, at the deployer's option,
syncronize concurrent calls to Stateful Session Beans rather than simply
reject outright the second one. As a developer (or deployer), I should be
able to choose whether I want an exception, or blocking, in the case of Stateful
bean concurrency. Either way, I believe EJB's design goals are met, which
is to prevent concurrency. With that as an amendment to the spec (EJB 2.0),
I wouldn't have to write these silly wrappers.
Thanks,
Bryan
Dan Malks wrote:
[EMAIL PROTECTED]">All,Sorry to jump in late on this.Am not monitoring this list real consistently at the moment, but it was broughtto my attention that there were some business tier coupling and EJB issues beingdiscussed, so I thought I'd make a few quick comments.Looking back over the thread, there is a mention of using a handler class asbasically a client-side business abstraction, which I think makes great sense.It reduces the coupling between tiers and provides a nice place for things likeremote lookups, caching, synchronization, exception type translation, etc...About a month ago, we did a beta release of a set of J2EE patterns (availableat: http://developer.java.sun.com/developer/technicalArticles/J2EE/patterns/),which includes just such a pattern.!
..it's called the Business Delegate pattern,and describes these issues among others, so I thought some folks might beinterested to check it out. There is a related Service Locator pattern thatdeals with hiding the impl details of remote lookups.The pattern descriptions have changed quite a bit even from the beta release,based on lots of quality feedback we've received from the community. Updatedversions will be available soon, including lots of source code. If you havesuggestions, we'd love to hear them. Also, there is a discussion list forrelated conversation(http://archives.java.sun.com/archives/j2eepatterns-interest.html). Hope thisproves useful to you.Thanks,Dan"Hines, Bill" wrote:
Brian,Disclaimer: I'm new to EJB and still trying to understand when to usestateful/stateless session beans.Given that, I found your situation interesting. First I'll try to help youif I can. There is an article in the February 2001 WebSphere Advisor by TonyHigham, on page 10, titled "The Reality of EJB". It should be available ontheir web site. He talks about problems like yours and recommends anapproach where you use stateless beans but an alternative state-handlingmechanism such as HttpSession to hold the user's data. Will that sort ofthing work for you? It sounds more light-weight than stashing the wholesession bean and/or accessor JavaBean with synchronized methods into thesession. There are also some good patterns for using session beans in theIBM Redbook "Design and Implement Servlets, JSPs, and EJBs for IBM WebSphereApplication Server", which is available for download o!
n the IBM Redbookssite. You might find some ideas there.Now that I've tried to help, if you could, explain your aversion tostateless and why they won't work for you in this situation, so that I canlearn more.Thanks, your questions and contributions here are very useful to me.Bill HinesSun Certified Java ProgrammerHershey Foods Corp-Original Message-From: Bryan Field-Elliot [mailto:[EMAIL PROTECTED]]Sent: Thursday, April 05, 2001 11:09 AMTo: [EMAIL PROTECTED]Subject: Frames, concurrency, and EJB Stateful Session beans - aproblem.I'm having a design problem with my system, which is not really St
Re: Frames, concurrency, and EJB Stateful Session beans - a problem.
Bill -- I think the important design point to make, is that you want your business logic (including rules of behavior, state machine, etc) to be encapsulated within the EJB tier. This makes for tidier code and a more elegant design, and also makes your code more client-neutral. One of the scenarios you describe is to use stateless session beans, and store user state at the servlet level. While I haven't read the article, and while I will give it the benefit of the doubt that there might be some hidden benefit to that, still I would discount it as a design methodology -- it seems to needlessly spread your business logic across two completely separate subsystems with completely separate programming paradigms (that is, the Servlet level and the EJB level). If the only "problem" that this design is meant to solve is the concurrency issue which started this thread, then I think the solution I ended up on is a better one -- a simple wrapper class around the session bean which adds syncronization to the methods. Hopefully this sheds some light on your follow up question, "why the aversion to stateless". I have users, they log in to the system, and they perform actions against a database, and I need to be sure that they can only perform the actions they are authorized to perform, and only against the data that they are authorized to access. So I have stateful session beans for the users; the only "state", really, is "who is this user?" (obtained from a "logon" method, which is the only method allowed to be executed right after creation). The rest of the methods check who the current user is, and use entity beans to get/set the appropriate data. At the web tier (Struts and JSP), I basically have a library of Struts actions and custom JSP tags which pretty much just duplicate the method names in the session bean, passing parameters to the EJB tier and packaging the return values as javabeans for the JSP to display. So, at the web tier, there really is no "state" at all, except for a reference to the user's EJB session bean. Stateful session beans are the way to go with my application, it keeps the meat of the system all in one tier (EJB), and keeps my web tier very simple (it wouldn't be hard, for example, for me to re-implement my Struts actions in some other framework, since they are just lightweight pass-throughs anyway). Regards, Bryan Hines, Bill wrote: Brian, Disclaimer: I'm new to EJB and still trying to understand when to use stateful/stateless session beans. Given that, I found your situation interesting. First I'll try to help you if I can. There is an article in the February 2001 WebSphere Advisor by Tony Higham, on page 10, titled "The Reality of EJB". It should be available on their web site. He talks about problems like yours and recommends an approach where you use stateless beans but an alternative state-handling mechanism such as HttpSession to hold the user's data. Will that sort of thing work for you? It sounds more light-weight than stashing the whole session bean and/or accessor JavaBean with synchronized methods into the session. There are also some good patterns for using session beans in the IBM Redbook "Design and Implement Servlets, JSPs, and EJBs for IBM WebSphere Application Server", which is available for download on the IBM Redbooks site. You might find some ideas there. Now that I've tried to help, if you could, explain your aversion to stateless and why they won't work for you in this situation, so that I can learn more. Thanks, your questions and contributions here are very useful to me. Bill Hines Sun Certified Java Programmer Hershey Foods Corp
Edit form -- comments
Hmm I didn't catch that nuance... thanks for pointing that out, it does indeed change the picture. In any case, I finally got my own application to work as intended -- using one JSP page, one ActionForm, and one Action -- 1. The JSP page's initial invocation notices that there is no ActionForm bean present, so it forwards to user to the Action (with no parameters). 2. The Action (which is configured with "validate=false") notices that the ActionForm supplied is EMPTY (note that it's not NULL), and fills it with the editable data, then forwards the user back to the JSP page. 3. The JSP page displays the form in HTML format, and changes are submitted back to the Action again. 4. The Action notices that we have a "full form" now, so it MANUALLY calls the ActionForm's "validate()" method. Then, assuming there are no ActionErrors, it saves the data to disk. Would appreciate comments from the group on whether this is a reasonable design use of Struts. Thanks, Bryan P.S. To Biju Isac -- I do not think that Struts is wrong from every angle; in fact I'm wrapping up a three-month project based upon it, and in reflecting on the experience there's a lot to like about Struts. On the other hand, I do think that the documentation needs a lot of beefing up. I will also share my feelings that the tag library, in particular, is confusingly designed. For example, many of the [logic] tags seem to have too many permuations of behavior depending upon the parameters supplied. I'm just not convinced that such deeply intertwined, "overloaded" behavior (for lack of a better description) is the best design. It certainly makes it hard to wade through the docs and grasp (and memorize) how they work. Jean-Noel Ribette wrote: registration.jsp does display the populated form, but when the form is submited, it is to SaveRegistrationAction, not EditRegistrationAction. Jean-Noel
Frames, concurrency, and EJB Stateful Session beans - a problem.
I'm having a design problem with my system, which is not really Struts specific, but since there are a lot of EJB users here, I thought I'd throw it on this list for comments -- My business logic is all implemented in a Stateful EJB Session bean. All Struts users get one instance of the session bean, whose reference is stored in the Servlet's Session scope. All of my Struts actions are simple; they take data from the user (usually in ActionForms), pass them to some method in the EJB Session bean, and store the results in beans for the JSP page to render. However, my design calls for a few places where there is a frameset, and in another place, where two browser windows open up showing two different views. The problem here, is that EJB requires that a Stateful Session bean have only one thread of execution within it (e.g. no concurrency). So, when two different Struts actions (or custom tags) try to invoke a method on the same EJB Session bean reference at the same time, one of them will fail with an exception thrown by the EJB container (in my case, jBoss). Can anyone recommend an easy, general-purpose solution to this problem? (Please don't say, "switch to stateless session beans"). I suppose I need to syncronize access to the EJB bean from the client (and, in this case, the client is Struts), but I'm not sure how to do this quickly and elegantly. Comments would be appreciated, Bryan
Re: Frames, concurrency, and EJB Stateful Session beans - a problem.
Thanks, That proposal would probably work, but it might be a little over-complicated (although I am starting to suspect that every solution is going to be yucky). I think I couldn't do your idea with just a simple bean with a simple syncronized getter method; instead, the wrapper bean would have to have all of the same method signatures as the session bean, and pass through all the calls (doing syncronization first). What I'm leaning towards right now, is finding some kind of "per-user" syncronization, which I can "lock" at the start, and "unlock" at the end, of every one of my Action.perform() methods. I can probably do this with a simple class, with two static methods -- "lock" and "unlock" -- and it will take as a parameter the current user's "session" object (Servlet session, that is), so that the locks are per-user, rather than global. Comments before I dive in the deep end? Thanks, Bryan Abraham Kang wrote: Hi Bryan, Can you put the stateful session bean within a JavaBean with synchronized methods so that all access to the stateful session bean is through the JavaBean? --Abraham -Original Message- From: Bryan Field-Elliot [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 05, 2001 8:09 AM To: [EMAIL PROTECTED] Subject: Frames, concurrency, and EJB Stateful Session beans - a problem. I'm having a design problem with my system, which is not really Struts specific, but since there are a lot of EJB users here, I thought I'd throw it on this list for comments -- My business logic is all implemented in a Stateful EJB Session bean. All Struts users get one instance of the session bean, whose reference is stored in the Servlet's Session scope. All of my Struts actions are simple; they take data from the user (usually in ActionForms), pass them to some method in the EJB Session bean, and store the results in beans for the JSP page to render. However, my design calls for a few places where there is a frameset, and in another place, where two browser windows open up showing two different views. The problem here, is that EJB requires that a Stateful Session bean have only one thread of execution within it (e.g. no concurrency). So, when two different Struts actions (or custom tags) try to invoke a method on the same EJB Session bean reference at the same time, one of them will fail with an exception thrown by the EJB container (in my case, jBoss). Can anyone recommend an easy, general-purpose solution to this problem? (Please don't say, "switch to stateless session beans"). I suppose I need to syncronize access to the EJB bean from the client (and, in this case, the client is Struts), but I'm not sure how to do this quickly and elegantly. Comments would be appreciated, Bryan
Re: Frames, concurrency, and EJB Stateful Session beans - a problem.
Now that I think about it, perhaps a solution to this would be a great general-purpose configuration feature for Struts. On a per-web-application level (e.g. in struts-config.xml), there might be an option such as: syncronize_requests = x where x might be: none - the default -- the current Struts behavior session - syncronize requests on a per user (per-session) basis (but allow concurrent access from different users) application - syncronize all requests, globally This would be to support whacko frameworks like EJB, whereby you can't have concurrent access to Stateful Session Beans. (in that scenario I would use "session" rather than "application" syncronization). Note also (and this is very important) -- that if this were to be a general-purpose Struts mechanism, I would need to be able to tie into it from my custom tag library, as well as my Action classes, since tags might also access an EJB bean. Regards, Bryan
Re: Frames, concurrency, and EJB Stateful Session beans - a probl em.
So in your scenario (as a proposed solution to my problem), I would add syncronization code to xxxHandler.java? That seems elegant; I had never thought of implementing a separate handler class for my EJB's, although it's always been on my "to-do" list to try having Bean and Remote implement a common interface (just haven't gotten around to it yet). From my standpoint (and the problem I'm trying to solve), I'm not sure that adding the "xxxHandler" class with syncronization is going to be any easier for me than a general-purpose "Servlet session syncronization" utility, since I am at ground zero with either approach. They both have appeal. I will stew on this over lunch today and see where that leads me. Thanks for the input, Bryan Jason Pringle wrote: 168B2A5F6A99D4119E28C7C9CA80DE35CE@GIBRALTAR">I usually try to stay far away from doing lock/unlock type things withthreaded access - really testing it can get too hairy, and problems tend tobe hard to trace.The practice we use here for EJBs is thus (it's actually not too hard to do,and hides the fact that you're using EJBs from the front end).Ixxx.java - interface defining business methodsxxxBean.java - implementation code: xxxBean implements SessionBean, IxxHome.java - standard Home interfacexxxRemote.java - remote interface, extends EJBObject, IxxHandler.java - wrapper class, implements IxxxThe JavaBeans (and JSPs in some cases - no, we're not using Struts (yet))use the xxxHandler classes for all access. The xxxHandler actually does tothe lookup, home create, portable narrow, and delegates all calls to theEJB. The code is so straightforward it could! really be generated (ofcourse, we don't do that). Since everything runs off of the Ixxx interface,the compiler will catch if you change signatures in one place and not theother. And your Remote interface is empty, since it just "joins" theEJBObject and Ixxx interfaces.Food for thought, there are many other ways to do this.--jason-----Original Message-From: Bryan Field-Elliot [mailto:[EMAIL PROTECTED]]Sent: Thursday, April 05, 2001 11:33 AMTo: [EMAIL PROTECTED]Cc: [EMAIL PROTECTED]Subject: Re: Frames, concurrency, and EJB Stateful Session beans - aproblem.Thanks,That proposal would probably work, but it might be a little ove! r-complicated (although I am starting to suspect that every solution is going to be yucky). I think I couldn't do your idea with just a simple bean with a simple syncronized getter method; instead, the wrapper bean would have to have all of the same method signatures as the session bean, and pass through all the calls (doing syncronization first).What I'm leaning towards right now, is finding some kind of "per-user" syncronization, which I can "lock" at the start, and "unlock" at the end, of every one of my Action.perform() methods. I can probably do this with a simple class, with two static methods -- "lock" and "unlock" -- and it will take as a parameter the current user's "session" object (Servlet session, that is), so that the locks are per-user, rather than global.Comments before I dive in the deep end?Thanks,BryanAbraham Kang wrote: Hi Bryan, Can you put the stateful session bean within a JavaBean with synchronized methods so that all access to the stateful session bean is through theJavaBean?--Abraham-Original Message-From: Bryan Field-Elliot [mailto:[EMAIL PROTECTED]]Sent: Thursday, April 05, 2001 8:09 AMTo: [EMAIL PROTECTED]Subject: Frames, concurrency, and EJB Stateful Session beans - aproblem.I'm having a design problem with my system, which is not really Strutsspecific, but since there are a lot of EJB users here, I thought I'dthrow it on this list for comments --My business logic is all implemented in a Stateful EJB Session bean. AllStruts users get one instance of the session bean, whose reference isstored in the Servlet's Session scope.! All of my Struts actions are simple; they take data from the user(usually in ActionForms), pass them to some method in the EJB Sessionbean, and store the results in beans for the JSP page to render.However, my design calls for a few places where there is a frameset, andin another place, where two browser windows open up showing twodifferent views. The problem here, is that EJB requires that a StatefulSession bean have only one thread of execution within it (e.g. noconcurrency). So, when two different Struts actions (or custom tags) tryto invoke a method on the same EJB Session bean reference at the sametime, one of them will fail with an exception thrown by the EJBcontainer (in my case, jBoss).Can anyone recommend an easy, general-purpose solution to this problem?(Please don't say, "switch to stateless session beans"). I suppose Ineed to syncronize access to the EJB bean from the client (and, in thiscase! , the client is Struts), but I'm not sure how to do this quickly andelegantly.Comments would be appreciated,Bryan
Re: Frames, concurrency, and EJB Stateful Session beans - a problem.
Good grief -- what a twistly little maze of passages, all alike (or was that, a maze of twisty little passages, all alike?) Thanks for laying out those extra thoughts. I think you're right that the GP approach puts too much of a burden on the client to use it correctly. I still maintain that a REALLY GP approach (that is, built in to Struts, and activatable with a single config option) would be useful, but I haven't the time for that right now. I think I'll go the xxxHandler route. Thanks again, Bryan Jason Pringle wrote: 168B2A5F6A99D4119E28C7C9CA80DE35D0@GIBRALTAR">Yup, that's where I would put the synchronization. At first guess I would think this would be simpler than the general purpose approach, because you've placed all responsibility for synchronization in a distinct spot - the xxxHandler. Any user of the handler doesn't have to even think about the fact that it's synchronized or thread-safe*. In the GP approach, safety depends on both the implementation of the locking system, and the correct usage of the locking system by participants. You'd also want to think about locking specific resources, not just locking the whole servlet - it gets deeper and deeper. There may be issues with locking and forwarding between pages (nested locks?). What about error processing - deadlocks can come into play. Finally, from the performance standpoint, general practice is to limit synchronization to the minimum time needed. In this case that's access to the EJB. If you lock at the servlet level you're unnecessarily restricting throughput.Note that a limitation of this approach is that no ordering is imposed on access serialization. IE - if you have two frames accessing the EJB simultaneously, the actions of one cannot depend on the actions of the other because you can't guarantee which frame is going to attempt access first. If order of execution is important, then you'll need some other type of component broker in the mix.--jason* ok, it's not totally thread-safe unless you make the handler a singleton, which is likely NOT the desired behavior (ie - you want different users to have their own instances). So you do have to guarantee that no two instances of xxxHandler ever reference the same xxxEJB instance. This is inherent in the design as long as you restrict access to EJBs to using the xxxHandler mechanism.-Original Message-----From: Bryan Field-Elliot [mailto:[EMAIL PROTECTED]]Sent: Thursday, April 05, 2001 12:15 PMTo: [EMAIL PROTECTED]Subject: Re: Frames, concurrency, and EJB Stateful Session beans - a probl em.So in your scenario (as a proposed solution to my problem), I would add syncronization code to xxxHandler.java?That seems elegant; I had never thought of implementing a separate handler class for my EJB's, although it's always been on my "to-do" list to try having Bean and Remote implement a common interface (just haven't gotten around to it yet). From my standpoint (and the problem I'm trying to solve), I'm not sure that adding the "xxxHandler" class with syncronization is going to be any easier for me than a general-purpose "Servlet session syncronization" utility, since I am at ground zero with either approach. They both have appeal. I will stew on this over lunch today and see where that leads me.Thanks for the input,BryanJason Pringle wrote:168B2A5F6A99D4119E28C7C9CA80DE35CE@GIBRALTAR" type="cite">I usually try to stay far away from doing lock/unlock type things withthreaded access - really testing it can get too hairy, and problems tend tobe hard to trace.The practice we use here for EJBs is thus (it's actually not too hard to do,and hides the fact that you're using EJBs from the front end).Ixxx.java - interface defining business methodsxxxBean.java - implementation code: xxxBean implements SessionBean, IxxHome.java - standard Home interfacexxxRemote.java - remote interface, extends EJBObject, IxxHandler.java - wrapper class, implements IxxxThe JavaBeans (and JSPs in some cases - no, we're not using Struts (yet))use the xxxHandler classes for all access. The xxxHandler actually does tothe lookup, home create, portable narrow, and delegates all call! s to theEJB. The code is so straightforward it could! really be generated (ofcourse, we don't do that). Since everything runs off of the Ixxx interface,the compiler will catch if you change signatures in one place and not theother. And your Remote interface is empty, since it just "joins" theEJBObject and Ixxx interfaces.Food for thought, there are many other ways to do this.--jason-Original Message-From: Bryan Field-Elliot [mailto:[EMAIL PROTECTED]]Sent: Thursday, April 05, 2001 11:33 AMTo: [EMAIL PROTECTED]Cc: [EMAIL PROTECTED]Subject: Re: Frames, concurrency, and EJB Stateful Session beans - aproblem.Thanks,That ! proposal would probably work, but it might be a little ove!r-complicat
Re: Frames, concurrency, and EJB Stateful Session beans - a problem.
I implemented your solution -- xxxHandler.java for my stateful session bean, and a new interface which the bean, remote interface, and handler all implement (or extend). Also added EJB creation, and method pass-through (with syncronization) to the handler class. Lastly, changed all my Struts code to use the handler and the new interface, instead of the old remote interface. Result - works like a champ! Frameset problem solved. Took about one hour to implement. Thanks again, Bryan Jason Pringle wrote: 168B2A5F6A99D4119E28C7C9CA80DE35D0@GIBRALTAR">Yup, that's where I would put the synchronization. At first guess I would think this would be simpler than the general purpose approach, because you've placed all responsibility for synchronization in a distinct spot - the xxxHandler. Any user of the handler doesn't have to even think about the fact that it's synchronized or thread-safe*. In the GP approach, safety depends on both the implementation of the locking system, and the correct usage of the locking system by participants. You'd also want to think about locking specific resources, not just locking the whole servlet - it gets deeper and deeper. There may be issues with locking and forwarding between pages (nested locks?). What about error processing - deadlocks can come into play. Finally, from the performance standpoint, general practice is to limit synchronization to the minimum time needed. In this case that's access to the EJB. If you lock at the servlet level you're unnecessarily restricting throughput.Note that a limitation of this approach is that no ordering is imposed on access serialization. IE - if you have two frames accessing the EJB simultaneously, the actions of one cannot depend on the actions of the other because you can't guarantee which frame is going to attempt access first. If order of execution is important, then you'll need some other type of component broker in the mix.--jason* ok, it's not totally thread-safe unless you make the handler a singleton, which is likely NOT the desired behavior (ie - you want different users to have their own instances). So you do have to guarantee that no two instances of xxxHandler ever reference the same xxxEJB instance. This is inherent in the design as long as you restrict access to EJBs to using the xxxHandler mechanism.-Original Message-----From: Bryan Field-Elliot [mailto:[EMAIL PROTECTED]]Sent: Thursday, April 05, 2001 12:15 PMTo: [EMAIL PROTECTED]Subject: Re: Frames, concurrency, and EJB Stateful Session beans - a probl em.So in your scenario (as a proposed solution to my problem), I would add syncronization code to xxxHandler.java?That seems elegant; I had never thought of implementing a separate handler class for my EJB's, although it's always been on my "to-do" list to try having Bean and Remote implement a common interface (just haven't gotten around to it yet). From my standpoint (and the problem I'm trying to solve), I'm not sure that adding the "xxxHandler" class with syncronization is going to be any easier for me than a general-purpose "Servlet session syncronization" utility, since I am at ground zero with either approach. They both have appeal. I will stew on this over lunch today and see where that leads me.Thanks for the input,BryanJason Pringle wrote:168B2A5F6A99D4119E28C7C9CA80DE35CE@GIBRALTAR" type="cite">I usually try to stay far away from doing lock/unlock type things withthreaded access - really testing it can get too hairy, and problems tend tobe hard to trace.The practice we use here for EJBs is thus (it's actually not too hard to do,and hides the fact that you're using EJBs from the front end).Ixxx.java - interface defining business methodsxxxBean.java - implementation code: xxxBean implements SessionBean, IxxHome.java - standard Home interfacexxxRemote.java - remote interface, extends EJBObject, IxxHandler.java - wrapper class, implements IxxxThe JavaBeans (and JSPs in some cases - no, we're not using Struts (yet))use the xxxHandler classes for all access. The xxxHandler actually does tothe lookup, home create, portable narrow, and delegates all call! s to theEJB. The code is so straightforward it could! really be generated (ofcourse, we don't do that). Since everything runs off of the Ixxx interface,the compiler will catch if you change signatures in one place and not theother. And your Remote interface is empty, since it just "joins" theEJBObject and Ixxx interfaces.Food for thought, there are many other ways to do this.--jason-Original Message-From: Bryan Field-Elliot [mailto:[EMAIL PROTECTED]]Sent: Thursday, April 05, 2001 11:33 AMTo: [EMAIL PROTECTED]Cc: [EMAIL PROTECTED]Subject: Re: Frames, concurrency, and EJB Stateful Session beans - aproblem.Thanks,That ! proposal would probably work, but it might be a little ove!r-complicated (although I a
Presenting an edit form - example is WAY way bad...
Good grief, I've spent half the evening trying to understand the "proper way" in Struts to present the user with a pre-populated editable form (using ActionForm, a JSP page, and an Action). And, I am not even certain I have it figured out quite yet. My first point, is that the struts-example of editing a form (the RegistrationForm and the EditRegistrationAction classes) is pretty bad, or should I say, hard to follow. This is how I THINK I have the example figured out, and I'd appreciate it if someone could correct me where I'm wrong -- 1. The process is initiated via a hyperlink in mainMenu.jsp, directly to the EditRegistrationAction action, and without any form submission. 2. EditRegistrationAction's ActionMapping (in struts-config.xml) is configured to use the RegistrationForm as it's ActionForm, but with VALIDATE=FALSE. 3. EditRegistrationAction notices that the process() parameter "form" is null, and therefore creates a form, populates it, and saves in the request scope, and then forwards to the JSP page "registration.jsp". 4. registration.jsp displays the populated form, which is eventually re-submitted back to EditRegistrationAction and saved to disk. Is this right? Now, I believe I have spotted a hole in this design -- that is, since the ActionMapping for EditRegistrationAction has "validate=false" in it, then the validate() method for the RegistrationForm is never called. This means that, while validation occured at user signup time, it is not validating their edits. This seems wrong to me. But how to rectify it? I know why you have set validate=false, it's to let the ActionForm through without errors on the first pass (since all it's fields are blank). Should we be manually calling form.validate() from within the action class, in this instance? Confused, tired, and with aching head, Bryan
Re: Communicating with EJB's from Action
I am doing EJB development with Struts also. Good design dictates that basic validity checking should occur nearest the client; probably the ActionForm.validate() method is the best place. In a perfect world, you'd do this way way out on the client via Javascript, but that would open itself up to circumvention by hackers. Basic validity checking includes questions like "is this really a date?", "is this number really between 1 and 100?", "did they select an option from the listbox?", etc. Business model validity checking should absolutely occur at the EJB level, such as "is this user allowed to perform this action?", "is this a valid record number to operate upon", etc. In the Struts world, there is a "middle ground" where one could theoretically do more validity checking, and this is in the Action class's perform() method. However I generally keep all "thinking" out of this method, and simply use it as a conduit between the UI (the ActionForm), and the Model (EJB). Bryan Wong Kok Wai wrote: [EMAIL PROTECTED]">Generally, for a multi-tier architecture, I would dodata checking as close to the user as possible tominimize data transmission. So my first level checkingwould be using Javascript on the browser side.However, not all types of checking can be done inJavascript and so the validate method would be thenext level.--- "Handy, Steve" [EMAIL PROTECTED] wrote: Hal,That's a good question: where should basic valuechecking be done, in thestateless session beans or in the ActionFormvalidate method?Certainly, any checking that depends on anythingoutside the request itselfshould not be in the validate method, e.g. checkingthat depends on thestate of an entity bean. I also believe that anentity bean should protectitself; so, for example, the ejbcreate method shouldvalidate the values itis given for attributes. In general, I wouldn't putany business ruleschecking in the ActionForm validate method.However, I can see where -type- checking might bedone in the validatemethod. For example, when the user gives you astring that is supposed totranslate to a number or a date.What do you think?Steve __Do You Yahoo!?Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/?.refer=text
ActionForm reset(), constructor, and default values
I've posted this general comment three times now, with no response -- I am wondering if anyone is receiving my postings? The issue is, in implementing an ActionForm bean, are we expected to supply default values whenever the constructor is called, or whenever the reset() method is called, or both? The documentation is unclear on exactly which sequences of events need to have default values inserted. Clarification would be appreciated. Thanks, Bryan
How can a Struts Action developer best document the system for a JSP developer?
I am struggling right now with how to properly and efficently document my Struts application for my JSP developer (who is by no means a Java expert). Specifically, I want to document each Action as well as each ActionForm that I code, including things like: 1. the pages I expect the user to have come from 2. the pages to which I might forward, or redirect, the user after completing the action 3. The beans I expect to be in place prior to submitting to my action 4. The beans I will set up with values for the resulting JSP page to work with 5. The errors (html:errors) I may set up And anything else that might be appropriate. I'd like to do so in a way that lets me rely on Javadoc, so that I can keep my documentation inside my code. Javadoc when used correctly will also let me do things like "see also" the Bean documentation (from the Action documentation). I am curious if anyone has developed a "template" action or bean, which makes best use of Javadoc and which I can cut-and-paste at the head of every one of my Action classes, etc? Thanks, Bryan
Still wishing someone would comment on this design issue (ActionForm defaults)
Reposted from earlier as I think this is an important design issue and I never got any comments on it -- I am working wth ActionForms, one of which contains some list boxes and some checkboxes. In building my ActionForm class, I am noticing in the docs (under "Form Construction Tags") warnings like the following: WARNING: In order to correctly recognize unchecked checkboxes, the ActionForm bean associated with this form must include a statement setting the corresponding boolean property to false in the reset() method. WARNING: In order to correctly recognize cases where no selection at all is made, the ActionForm bean associated with this form must include a statement resetting the scalar property to a default value (if multiple is not set), or the array property to zero length (if multiple is set) in the reset() method. So, in my reset() method, I am putting default values for these properties, as recommended. However, I am noticing that in the "first pass" of loading a JSP page (before any Action has occured), my ActionForm bean's reset() method is not being called; only it's constructor is being called. So, the logic I put into the "reset" method, I copied into my default constructor as well. It seems to me that one of the following should happen: 1. The default constructor should call the reset() method. 2. The docs should be updated to indicate that, if you are going to put default values in your ActionForm, you better set them from your default constructor as well as from your reset() method. What I have done for each my my ActionForm beans is create a method called "setDefaults()", and I call it from within the constructor as well as from within the reset() method. It is here that I set default selections for my listboxes, checkboxes, default text for the text fields, etc. Comments? Bryan
struts-config.xml suggestion
Using 1.0 beta -- I have many "global forwards" in my config. All of my "input forms" are represented as global forwards. e.g.: global-forwards forward name="logon" path="/jsp/logon.jsp"/ /global-forwards In my action mappings, those which require ActionForms have an "input" tag: action ... input="/jsp/logon.jsp" /action It would be nice if the "input" attribute of the "action" tag would allow me to refer to a global-forward, instead of an absolute filename. If it did, then if I were to change the filename of my logon JSP page, I would only have to change it in one place. If I am missing something and I can already do this some other way, then please direct me. Thanks, Bryan
PropertyUtils.copyProperties and EJB beans
I am trying to use copyProperties() to copy everything FROM a standard bean, TO an enterprise javabean (entity bean). When I do so, I get the following exception: Name: java.lang.IllegalArgumentExceptionMessage: object is not an instance of declaring class Stack: java.lang.IllegalArgumentException: object is not an instance of declaring class at java.lang.reflect.Method.invoke(Native Method) at org.apache.struts.util.PropertyUtils.getSimpleProperty(PropertyUtils.java:591) at org.apache.struts.util.PropertyUtils.copyProperties(PropertyUtils.java:207) at com.reachmydoctor.ejb.patientSessionBean.createAccount(patientSessionBean.java:109) I suspect this may have something to do with the fact that my destination, being a remote interface, is a funky jBoss proxy class and not a standard bean at all. Nevertheless is there any way I can get this to work? I was really counting on this working... Otherwise I have about 65 properties to copy by hand! Thanks, Bryan
More on my copyProperties/EJB woes
I've been tearing apart my problems using copyProperties in an EJB environment;
The scenario is that I am using PropertyUtils.copyProperties to copy everything FROM a simple bean, TO an EJB entity bean.
Earlier tonight I thought that the hangup was over the destination bean,
perhaps because it was an EJB remote interface. But my digging turns up that
this isn't the case.
The exception is during the getting of the source properties (from my simple
bean), and it never even gets to the setting of the destination property.
I extracted a small piece of code from copyProperties and am executing it directly:
// pv is my simple bean, and "name" is a String property within in, which has a getter and a setter method.
PropertyDescriptor descriptor;
// Following two lines are key:
descriptor = PropertyUtils.getPropertyDescriptor(pv, "name");
//descriptor = new PropertyDescriptor("name", pv.getClass());
Method readMethod = descriptor.getReadMethod();
Object value = readMethod.invoke(pv, new Object[0]);
When I use the first of the two "descriptor = " lines (thereby making use
of Struts), I get the following exception on the invoke() line:
Name: java.lang.IllegalArgumentExceptionMessage: object is not an instance of declaring class Stack: java.lang.IllegalArgumentException: object is not an instance of declaring class at java.lang.reflect.Method.invoke(Native Method)
However, when I use the second of the two "descriptor = " lines (thereby
using standard Java SDK reflection), the invoke() line executes correctly.
Any help would be appreciated.
This is using Struts 1.0 beta-1 (binaries).
Regards,
Bryan
Observations on ActionForms, reset(), html tags
(I am reposting this message from a few days ago, because I realized that my original post was a reply to another message, and that even though I had changed the subject line, perhaps tree-viewing mail clients would show it is part of another conversation, which I didn't really intend. I just wanted a shortcut to entering "[EMAIL PROTECTED]"). I am working wth ActionForms, one of which contains some list boxes and some checkboxes. In building my ActionForm class, I am noticing in the docs (under "Form Construction Tags") warnings like the following: WARNING: In order to correctly recognize unchecked checkboxes, the ActionForm bean associated with this form must include a statement setting the corresponding boolean property to false in the reset() method. WARNING: In order to correctly recognize cases where no selection at all is made, the ActionForm bean associated with this form must include a statement resetting the scalar property to a default value (if multiple is not set), or the array property to zero length (if multiple is set) in the reset() method. So, in my reset() method, I am putting default values for these properties, as recommended. However, I am noticing that in the "first pass" of loading a JSP page (before any Action has occured), my ActionForm bean's reset() method is not being called; only it's constructor is being called. So, the logic I put into the "reset" method, I copied into my default constructor as well. It seems to me that one of the following should happen: 1. The default constructor should call the reset() method. 2. The docs should be updated to indicate that, if you are going to put default values in your ActionForm, you better set them from your default constructor as well as from your reset() method. Comments? Bryan
ActionForm question (repost)
Question reposted (never got any responses) -- please respond, someone :)
Question about creating ActionForm beans --
What kinds of data types are supported? I could not find a reference to
this in the docs. For example, I want to have an input box on my forms,
where the user can enter a number. Or, they can leave it blank. I want
"blank" to show up as null, not zero. Should I implement my ActionForm
bean as follows?
Integer qty;
Integer getQty() { return qty; }
void setQty(Integer) { this.qty = qty; }
I've chosen Integer because it can hold a value, OR it can be null
(which is the behavior I'm looking for).
Will this work, or must I restrict my data types to Strings and do
conversion somewhere else?
Thanks,
Bryan
Question about PropUtils.copyProperties()
Question -- in evaluating names of properties (get/setter methods), does it do a case-INsensitive match, or case-sensitive? Due to the tool I'm using, some classes have method names like: getcc_number() putcc_number() while others will have it as: getCc_number() putCc_number() Will these be considered a "match" by the copyProperties() function? Thanks, Bryan
ActionForm questions
New to Struts here --
Question about creating ActionForm beans --
What kinds of data types are supported? I could not find a reference to
this in the docs. For example, I want to have an input box on my forms,
where the user can enter a number. Or, they can leave it blank. I want
"blank" to show up as null, not zero. Should I implement my ActionForm
bean as follows?
Integer qty;
Integer getQty() { return qty; }
void setQty(Integer) { this.qty = qty; }
I've chosen Integer because it can hold a value, OR it can be null
(which is the behavior I'm looking for).
Will this work, or must I restrict my data types to Strings and do
conversion somewhere else?
Thanks,
Bryan
Modeling Struts apps with TogetherJ?
I'm exercising my new copy of TogetherJ, and at the same time learning Struts for the first time. I was wondering if anyone has had any experience trying to model a Struts application using Together? (e.g. which diagram types did you use, etc.)? Regards, Bryan
