Re: [OS-webwork] Performance diff bw ww1 and ww2?
Drew McAuliffe wrote: With ww2, the numbers get a lot worse. List renderings are anywhere from 600 - 1100 ms for the large list, 400 - 600 ms for the small list. Detail pages are rendering in about 70 - 110 ms, though sometimes higher (never lower). Can you post some code snippets that take the time? I know that webwork1 has had a lot longer time to be tuned for performance, but I'm sure we can improve webwork2 in time. Cheers, Scott -- ATLASSIAN - http://www.atlassian.com Expert J2EE Software, Services and Support --- Need a simple, powerful way to track and manage issues? Try JIRA - http://www.atlassian.com/software/jira --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] Performance diff bw ww1 and ww2?
Can you do any profiling to show us the hotspots we should focus on optimizing? -Original Message- From: Drew McAuliffe [mailto:[EMAIL PROTECTED] Sent: Thursday, August 07, 2003 3:57 AM To: [EMAIL PROTECTED] Subject: [OS-webwork] Performance diff bw ww1 and ww2? I've been trying to migrate an application recently from ww1 to ww2 and have had some pretty difficult times. Conversion issues aside, though, I'm extremely concerned with what I see with the performance. ww2 seems to perform about 5 to 10 times worse than my equivalent application in ww1. I'm pretty positive that this isn't a problem with xwork, since my business layer uses xwork as an underlying command structure (and xwork is fantastic; the framework I have set up with it is going to save me a ton of maintenance headaches). The xwork business commands execute extremely quickly. Prior to the upgrade, I had xwork running underneath ww1, with ww1 servlets and actions. Most of the problem appears to be in the render cycle. I'm using velocity as my rendering engine (except for sitemesh decorators and a login.jsp). I'm not using the ww tags or their velocity equivalents because I have a custom page construction framework. Basically, each action sticks a page object onto the stack that contains information about page sections and controls. There are a lot of calls to the old $webwork utility on the ww1 velocity context, especially for bean creation and $webwork.evaluate calls. Under ww1, I get pretty fast response times. For a list page with about 20 items, I get the list in anywhere between 200 and 400 ms. With a constrained list, it's more like 30 - 70 ms (for a list of about 5 items). For a detail page with about 10 fields, I can usually get a render in about 20 - 30 ms. That's only 10 ms longer than the underlying framework is taking to load the data from the database. This is all on a dev machine running a local tomcat server, so I'm pretty happy with this performance. With ww2, the numbers get a lot worse. List renderings are anywhere from 600 - 1100 ms for the large list, 400 - 600 ms for the small list. Detail pages are rendering in about 70 - 110 ms, though sometimes higher (never lower). Also, strangely, my pages have a decorator on the side that shows the current user, using ww:property value=userInfo.firstName/ nbsp;ww:property value=userInfo.lastName/ Every third time the page is loaded, these show up as null, inexplicably. I don't know why this would be happening, though I suppose it has something to do with things getting tied up inside the render cycle. I also get socket errors every fourth or fifth page load, if I keep loading in quick succession. I realize this evidence is anecdotal but I was wondering if anyone else has had similar results with ww2, or if there's something I'm doing completely wrong with the way I'm using velocity in ww2. My previous macros were updated to use the value stack and I can include the old and new versions, if necessary. I do know that it used to work fine before. I'm itching to move to ww2 because it does so many things so much more elegantly (things I used to have to do a lot of custom coding around) and I'm already using xwork anyway. --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet _072303_01/01 ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Performance diff bw ww1 and ww2?
I'll do some optimizing soon, but just off the top of my head those numbers sound very strange. I've done some imprecise testing and I found WW2 about as fast as WW1, especially when using lots of form elements with lots of data. -Pat - Original Message - From: Jason Carreira [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, August 07, 2003 5:37 AM Subject: RE: [OS-webwork] Performance diff bw ww1 and ww2? Can you do any profiling to show us the hotspots we should focus on optimizing? -Original Message- From: Drew McAuliffe [mailto:[EMAIL PROTECTED] Sent: Thursday, August 07, 2003 3:57 AM To: [EMAIL PROTECTED] Subject: [OS-webwork] Performance diff bw ww1 and ww2? I've been trying to migrate an application recently from ww1 to ww2 and have had some pretty difficult times. Conversion issues aside, though, I'm extremely concerned with what I see with the performance. ww2 seems to perform about 5 to 10 times worse than my equivalent application in ww1. I'm pretty positive that this isn't a problem with xwork, since my business layer uses xwork as an underlying command structure (and xwork is fantastic; the framework I have set up with it is going to save me a ton of maintenance headaches). The xwork business commands execute extremely quickly. Prior to the upgrade, I had xwork running underneath ww1, with ww1 servlets and actions. Most of the problem appears to be in the render cycle. I'm using velocity as my rendering engine (except for sitemesh decorators and a login.jsp). I'm not using the ww tags or their velocity equivalents because I have a custom page construction framework. Basically, each action sticks a page object onto the stack that contains information about page sections and controls. There are a lot of calls to the old $webwork utility on the ww1 velocity context, especially for bean creation and $webwork.evaluate calls. Under ww1, I get pretty fast response times. For a list page with about 20 items, I get the list in anywhere between 200 and 400 ms. With a constrained list, it's more like 30 - 70 ms (for a list of about 5 items). For a detail page with about 10 fields, I can usually get a render in about 20 - 30 ms. That's only 10 ms longer than the underlying framework is taking to load the data from the database. This is all on a dev machine running a local tomcat server, so I'm pretty happy with this performance. With ww2, the numbers get a lot worse. List renderings are anywhere from 600 - 1100 ms for the large list, 400 - 600 ms for the small list. Detail pages are rendering in about 70 - 110 ms, though sometimes higher (never lower). Also, strangely, my pages have a decorator on the side that shows the current user, using ww:property value=userInfo.firstName/ nbsp;ww:property value=userInfo.lastName/ Every third time the page is loaded, these show up as null, inexplicably. I don't know why this would be happening, though I suppose it has something to do with things getting tied up inside the render cycle. I also get socket errors every fourth or fifth page load, if I keep loading in quick succession. I realize this evidence is anecdotal but I was wondering if anyone else has had similar results with ww2, or if there's something I'm doing completely wrong with the way I'm using velocity in ww2. My previous macros were updated to use the value stack and I can include the old and new versions, if necessary. I do know that it used to work fine before. I'm itching to move to ww2 because it does so many things so much more elegantly (things I used to have to do a lot of custom coding around) and I'm already using xwork anyway. --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet _072303_01/01 ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go
Re: [OS-webwork] Performance diff bw ww1 and ww2?
This shows again the need for a sophisticated tutorial. Regards Lars I've been trying to migrate an application recently from ww1 to ww2 and have had some pretty difficult times. Conversion issues aside, though, I'm extremely concerned with what I see with the performance. ww2 seems to perform about 5 to 10 times worse than my equivalent application in ww1. I'm pretty positive that this isn't a problem with xwork, since my business layer uses xwork as an underlying command structure (and xwork is fantastic; the framework I have set up with it is going to save me a ton of maintenance headaches). The xwork business commands execute extremely quickly. Prior to the upgrade, I had xwork running underneath ww1, with ww1 servlets and actions. Most of the problem appears to be in the render cycle. I'm using velocity as my rendering engine (except for sitemesh decorators and a login.jsp). I'm not using the ww tags or their velocity equivalents because I have a custom page construction framework. Basically, each action sticks a page object onto the stack that contains information about page sections and controls. There are a lot of calls to the old $webwork utility on the ww1 velocity context, especially for bean creation and $webwork.evaluate calls. Under ww1, I get pretty fast response times. For a list page with about 20 items, I get the list in anywhere between 200 and 400 ms. With a constrained list, it's more like 30 - 70 ms (for a list of about 5 items). For a detail page with about 10 fields, I can usually get a render in about 20 - 30 ms. That's only 10 ms longer than the underlying framework is taking to load the data from the database. This is all on a dev machine running a local tomcat server, so I'm pretty happy with this performance. With ww2, the numbers get a lot worse. List renderings are anywhere from 600 - 1100 ms for the large list, 400 - 600 ms for the small list. Detail pages are rendering in about 70 - 110 ms, though sometimes higher (never lower). Also, strangely, my pages have a decorator on the side that shows the current user, using ww:property value=userInfo.firstName/ nbsp;ww:property value=userInfo.lastName/ Every third time the page is loaded, these show up as null, inexplicably. I don't know why this would be happening, though I suppose it has something to do with things getting tied up inside the render cycle. I also get socket errors every fourth or fifth page load, if I keep loading in quick succession. I realize this evidence is anecdotal but I was wondering if anyone else has had similar results with ww2, or if there's something I'm doing completely wrong with the way I'm using velocity in ww2. My previous macros were updated to use the value stack and I can include the old and new versions, if necessary. I do know that it used to work fine before. I'm itching to move to ww2 because it does so many things so much more elegantly (things I used to have to do a lot of custom coding around) and I'm already using xwork anyway. --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Performance
Were those JSPs precompiled or at least had you visited them once already? On Thursday, January 23, 2003, at 07:15 AM, Rickard Öberg wrote: Patrick Lightbody wrote: I believe that rewriting it to work for Lists would be just fine. The main thing it is doing is essentially _skipping_ all the EL stuff, which I believe is OK since templates are only usually edited once. Another thing that could be an idea is to use Velocity for the templates. I measured the raw overhead of doing an RD.include() on an empty Velocity template and an empty JSP. The overhead was way higher for a JSP, so in any include-intensive situation (e.g. tag templates) Velocity is a better choice. And same as above applies: they're only usually edited once so what it's implemented with isn't that important. Another good thing about using Velocity instead of JSP is that the performance is more consistant since it's not reliant on the JSP engine quality which, in some cases, is not what it should/could be (Tomcat/Jetty for example). /Rickard --- This SF.net email is sponsored by: Scholarships for Techies! Can't afford IT training? All 2003 ictp students receive scholarships. Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. www.ictp.com/training/sourceforge.asp ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Performance
Robert Nicholson wrote: Were those JSPs precompiled or at least had you visited them once already? I accessed the page loads of times using webstress and calculated an average. It's a couple of ms for JSP's, and about a ms for Velocity. That may not seem like much, but it adds up (especially if you, like us, use includes EVERYWHERE). /Rickard -- Rickard Öberg [EMAIL PROTECTED] Senselogic Got blog? I do. http://dreambean.com --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Performance
Oops, I've just noticed that my take on this was wrong. getTemplate() is only called when templateAttr is not set so it allows you to pass in template attribute on the tag no problem. On Thursday, January 23, 2003, at 01:30 PM, Robert Nicholson wrote: I've been looking over the RC2 branch code and it's a shame the JSP tags hardcode the template names. It would have made things easier if you could have at least defaulted the extension to .jsp but use just text instead of text.jsp from getTemplate() methods. Am I right in assuming Tag changes are required to make a one to one velocity/jsp template? You can set the default theme but it's still going to use x.jsp from the Tags getTemplate() methods. Is there some other way you're suppose to implement this? On Thursday, January 23, 2003, at 12:01 PM, Rickard Öberg wrote: Robert Nicholson wrote: Were those JSPs precompiled or at least had you visited them once already? I accessed the page loads of times using webstress and calculated an average. It's a couple of ms for JSP's, and about a ms for Velocity. That may not seem like much, but it adds up (especially if you, like us, use includes EVERYWHERE). /Rickard -- Rickard Öberg [EMAIL PROTECTED] Senselogic Got blog? I do. http://dreambean.com --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Performance
Peter, The Methodology --- Look at the clock by my desk and count how many whole seconds elapse before the page renders. Do not count the initial page compile in the data. Repeat 10 times and average the results. Just an FYI, a more scientific way to do this would be something like the following: long time = System.currentTimeMillis(); // Code here you want to profile time = System.currentTimeMillis() - time; System.err.println(That took + time + milliseconds.); Also, another advantage to this is you could embed it in the JSP page so that would truly measure the speed of the WW UI code and not your EJB layer or the browser rendering time. Cheers, --Bill --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Performance
Just look at Kurts earlier message with his ui:select problems and you'll find examples of this. On Thursday, January 23, 2003, at 07:20 PM, Bill Lynch wrote: Peter, The Methodology --- Look at the clock by my desk and count how many whole seconds elapse before the page renders. Do not count the initial page compile in the data. Repeat 10 times and average the results. Just an FYI, a more scientific way to do this would be something like the following: long time = System.currentTimeMillis(); // Code here you want to profile time = System.currentTimeMillis() - time; System.err.println(That took + time + milliseconds.); Also, another advantage to this is you could embed it in the JSP page so that would truly measure the speed of the WW UI code and not your EJB layer or the browser rendering time. Cheers, --Bill --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Performance (was: Scope for 1.4)
On Thu, 2003-01-23 at 14:24, Patrick Lightbody wrote: Here it is... As I'm in the middle of a performance tuning exercise this is somewhat relevant to me. Any suggestions as to how this should be used ? -- Peter Kelley [EMAIL PROTECTED] Moveit Pty Ltd --- This SF.net email is sponsored by: Scholarships for Techies! Can't afford IT training? All 2003 ictp students receive scholarships. Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. www.ictp.com/training/sourceforge.asp ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Performance
I believe that rewriting it to work for Lists would be just fine. The main thing it is doing is essentially _skipping_ all the EL stuff, which I believe is OK since templates are only usually edited once. -Pat - Original Message - From: Peter Kelley [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, January 22, 2003 10:44 PM Subject: [OS-webwork] Performance OK I've been doing some numbers on performance and I thought I'd share my results with the list. I have formatted the results below but first I have one question: Selectfastmap.jsp requires a map when a lot of our data was in lists. This is not a problem except that getting the map to provide the items in the right order will become a little tricky. Is there anything special performance wise about a map or can selectfastmap.jsp be rewritten easily to allow lists ? Results: Webwork 1.2: 7.3 Seconds Webwork 1.3: 4.7 Seconds Add the following to the page: % java.beans.PropertyEditorManager.registerEditor(String.class, sun.beans.editors.StringEditor.class); % 4.2 seconds Replace ui:select with webwork:iterator: 4.1 seconds (no real difference) Replace ui:select with selectfastmap.jsp (posted on this list earlier) using ui:component tags: 3.2 seconds The Page The page I am testing is a page specifying search parameters for an item search. It has 8 drop down lists, 6 of which have some rasonable data in (days months and years for start and end). There is also a button and a textfield. I started with all of the controls using the UI tags. This page is going to an EJB server and getting data from a database so some of the time shown here is not WW related. The Methodology --- Look at the clock by my desk and count how many whole seconds elapse before the page renders. Do not count the initial page compile in the data. Repeat 10 times and average the results. Environment --- Tomcat 4.1.18 running under JDK 1.4.1_01 talking RMI to JBoss 3.0.3 running under JDK 1.3.1_02 (JDK 1.4.1 was significantly faster than 1.3.1 for WW which was why the split was made). Versant Object database. -- Peter Kelley [EMAIL PROTECTED] Moveit Pty Ltd --- This SF.net email is sponsored by: Scholarships for Techies! Can't afford IT training? All 2003 ictp students receive scholarships. Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. www.ictp.com/training/sourceforge.asp ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.net email is sponsored by: Scholarships for Techies! Can't afford IT training? All 2003 ictp students receive scholarships. Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. www.ictp.com/training/sourceforge.asp ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Performance
On Thu, 2003-01-23 at 17:55, Patrick Lightbody wrote: I believe that rewriting it to work for Lists would be just fine. The main thing it is doing is essentially _skipping_ all the EL stuff, which I believe is OK since templates are only usually edited once. -Pat Should this template be included in CVS at some stage ? -- Peter Kelley [EMAIL PROTECTED] Moveit Pty Ltd --- This SF.net email is sponsored by: Scholarships for Techies! Can't afford IT training? All 2003 ictp students receive scholarships. Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. www.ictp.com/training/sourceforge.asp ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Performance
Patrick Lightbody wrote: I believe that rewriting it to work for Lists would be just fine. The main thing it is doing is essentially _skipping_ all the EL stuff, which I believe is OK since templates are only usually edited once. Another thing that could be an idea is to use Velocity for the templates. I measured the raw overhead of doing an RD.include() on an empty Velocity template and an empty JSP. The overhead was way higher for a JSP, so in any include-intensive situation (e.g. tag templates) Velocity is a better choice. And same as above applies: they're only usually edited once so what it's implemented with isn't that important. Another good thing about using Velocity instead of JSP is that the performance is more consistant since it's not reliant on the JSP engine quality which, in some cases, is not what it should/could be (Tomcat/Jetty for example). /Rickard --- This SF.net email is sponsored by: Scholarships for Techies! Can't afford IT training? All 2003 ictp students receive scholarships. Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. www.ictp.com/training/sourceforge.asp ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Performance
I couldn't be more +1 on this! Using velocity for templates would be awesome. Much better performance. -mike On 23/1/03 6:15 PM, Rickard Öberg ([EMAIL PROTECTED]) penned the words: Patrick Lightbody wrote: I believe that rewriting it to work for Lists would be just fine. The main thing it is doing is essentially _skipping_ all the EL stuff, which I believe is OK since templates are only usually edited once. Another thing that could be an idea is to use Velocity for the templates. I measured the raw overhead of doing an RD.include() on an empty Velocity template and an empty JSP. The overhead was way higher for a JSP, so in any include-intensive situation (e.g. tag templates) Velocity is a better choice. And same as above applies: they're only usually edited once so what it's implemented with isn't that important. Another good thing about using Velocity instead of JSP is that the performance is more consistant since it's not reliant on the JSP engine quality which, in some cases, is not what it should/could be (Tomcat/Jetty for example). /Rickard --- This SF.net email is sponsored by: Scholarships for Techies! Can't afford IT training? All 2003 ictp students receive scholarships. Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. www.ictp.com/training/sourceforge.asp ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.net email is sponsored by: Scholarships for Techies! Can't afford IT training? All 2003 ictp students receive scholarships. Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. www.ictp.com/training/sourceforge.asp ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
