Re: [OS-webwork] Reflection
boxed wrote: The problem is not right or wrong, the problem is the pro's and con's of the various approaches, and AFAICT the explicit approach has some limitations, whereas the non-explicit approach has no limitations. I can think of an example right now when the explicit solution is much more flexible than the ThreadLocal solution: Action1 creates two sets of data and starts off two threads, executes Action2 and Action3 with these two maps as parameters, then joins on the threads and continues on with its own execution. Did I miss something here? Would this be easier to implement with ThreadLocal (with JNDI?)? If the threading is done by XWork it would be equally simple. /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: A plea - WAS Re: [OS-webwork] Reflection
On Mon, Jan 13, 2003 at 08:30:17AM +0100, Rickard Öberg wrote: Mike Cannon-Brookes wrote: Some points that people seem to be forgetting: - Xwork is in the SANDBOX and is eXperimental (if you like the X for that) - Nothing in Xwork can't be changed, these are ideas, prototypes - Xwork will be better for 'web work' than WebWork is! - Xwork will be better for 'non web work' than WebWork is, _WITHOUT_ impacting people who don't care for 'non web work' That WebWork turned out to be a generic command pattern was more of an accident then by design. Because of this genericity WebWork is not optimally designed for doing web work. Some of the plumbing needs to be done by actions themselves, instead of having it be done by the framework. I want to make WebWork/XWork *better* suited for the web, because that is what *I* *need*. I want to get more for less. I don't give a damn about making it work well in Swing. If it does, then whaddyaknow, cool. If it doesn't, shit happens. If there's ever a point where I need to decide between keeping genericity, or making it work better for the web, the latter is a given. My recent emails have explained some of what I want to do in this area (introducing packages and components for example). Some of those are VERY web-centric, and that *IS THE POINT*. I think we should keep swing clients out of the discussion at the moment. Although I do not have very much experience with swing clients, the design patterns differ from the request-response pattern of web or rpc clients. So I see no problem in pushing the development slightly away from the web to a more generic request-response pattern. -billy. -- Meisterbohne Söflinger Straße 100 Tel: +49-731-399 499-0 eLösungen 89077 Ulm Fax: +49-731-399 499-9 msg01183/pgp0.pgp Description: PGP signature
Re: [OS-webwork] Slow performance using ww:iterator tag (version 1.2.1)?
Hi Kirk, I do not use the ui: tags myself (I stick with property and iterator etc), so I cannot say for sure, but I believe the bad performance is due to the use of PropertyEditors when printing the select list. I had similar performance problems with the 1.2.1 version. The 1.3RC1 version does not have this performance problem because there one introduced a cache of the PropertyEditors. Unfortunately that is not allowed since it is not thread-safe at all (as have been discussed on the list). Last week I posted a patch to the list (and Jira), that would fix this for 1.3, but I still have not heard of any committer adding it to CVS. Anyway, back to your problem. What you can try is to patch the BeanUtil class. Change the method: String toStringValue(Object obj) to just do a: if (obj == null) return ; else return obj.toString(); However, then you cannot rely on any PropertyEditor to be used for displaying your data. I do not know how important that is for you. Or you could change it to: if (obj == null) return; else if (obj instanceof String) return (String) obj; else ( do the method as it is today...). When I first had these performance problems I noticed that when the PropertyEditorManager should return an editor for a String it took even longer that normal! It seemed as if this was because the StringEditor was not registered in the HashMap in the PropertyEditorManager, so it was not found on the first lookup, but later when the manager checks for different classnames etc. So if you do not want to do the changes to Webwork code I described above, you can try to add a String editor to the PropertyEditorManager like: PropertyEditorManager.registerEditor(String.class, sun.beans.editors.StringEditor.class); That might improve your performance a bit. Hope this helps! Good luck! Best regards, Dick Zetterberg [EMAIL PROTECTED] Original Message - From: Kirk Rasmussen [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, January 12, 2003 2:38 AM Subject: [OS-webwork] Slow performance using ww:iterator tag (version 1.2.1)? Happy new year everyone! I have a simple question about the webwork:iterator tag and performance using WW 1.2.1. I have this list of countries that contains 245 entries. When I execute the following fragment, it takes about 15 seconds to execute the iterator loop by itself. Any of you WW gurus have some pointers on making it faster? I can't simply cache the select list because the form is for an address book so the selected value is user specific. %@ taglib uri=webwork prefix=ww % %@ taglib uri=webwork prefix=ui % % long start, end = -1; % table width=100% tr !-- start cell with webwork components -- ww:action name='CountriesList' id=countrieslist/ % start = System.currentTimeMillis(); % ui:select label='Country' name='country' list=@countrieslist/countries listKey='countryCode' listValue='description'/ % end = System.currentTimeMillis(); % !-- end cell with webwork components -- /tr /table p Execution Time=%= ((double)end - start) / 1000.0 % sec /p Thanks, Kirk Rasmussen Lucasfilm Ltd. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld 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: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
[OS-webwork] Interceptor abuse
Are interceptors really that different from filters? If they are very different, then I'm missing something and you can ignore the rest of this email... However, if they aren't that different, then I believe that they are few cases where a interceptor would be required instead of a filter. Filters should also be encouraged as they have a far better chance of working if you moved outside of a web environment. From hearing examples bandied about here, some people seem to think of interceptors for stuff like security and login, which IMHO is an abuse of them. Thoughts? Hani --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Interceptor abuse
Hani, Do you mean servlet filters? In which case - surely they don't work at all outside a web environment? And the other problem is that servlet filters are not applied directly to a specific action / group of actions, they are URL pattern based? (which is a royal pain in the ass to define!) Mike On 13/1/03 10:45 PM, Hani Suleiman ([EMAIL PROTECTED]) penned the words: Are interceptors really that different from filters? If they are very different, then I'm missing something and you can ignore the rest of this email... However, if they aren't that different, then I believe that they are few cases where a interceptor would be required instead of a filter. Filters should also be encouraged as they have a far better chance of working if you moved outside of a web environment. From hearing examples bandied about here, some people seem to think of interceptors for stuff like security and login, which IMHO is an abuse of them. Thoughts? Hani --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Interceptor abuse
On Mon, 13 Jan 2003, Mike Cannon-Brookes wrote: Hani, Do you mean servlet filters? In which case - surely they don't work at all outside a web environment? As Rickard has pointed out, So? There's little intent - except by a few over-outspoken users - to get XWork out of the web arena. And the other problem is that servlet filters are not applied directly to a specific action / group of actions, they are URL pattern based? (which is a royal pain in the ass to define!) Good point here, though. Mike On 13/1/03 10:45 PM, Hani Suleiman ([EMAIL PROTECTED]) penned the words: Are interceptors really that different from filters? If they are very different, then I'm missing something and you can ignore the rest of this email... However, if they aren't that different, then I believe that they are few cases where a interceptor would be required instead of a filter. Filters should also be encouraged as they have a far better chance of working if you moved outside of a web environment. From hearing examples bandied about here, some people seem to think of interceptors for stuff like security and login, which IMHO is an abuse of them. Thoughts? Hani --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork - Joseph B. Ottinger [EMAIL PROTECTED] http://enigmastation.comIT Consultant --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Interceptor abuse
Yes, I do mean servlet filters. I really don't mean to be rehashing old arguments, but the 'outside of a web environment' argument seems like a bit of a red herring to me. Lets take a few examples where the use of interceptors is mentioned... - Hibernate sessions: A filter could start and close the session. It has nothign to do with webwork, and tieing them together seems like strong coupling for no good reason (that I can see). Same for TX, really. You want to use it in your swing client? Great, just open and close your session before calling the action. In fact, since it's a persistent client, you'd open the session once, then close it when user closes the app, rather than constant open/close on every action. - Authentication: Again, a filter works wonderfully (as it does currently). Regarding out of web usage, method of auth is more often than not likely to be fairly different. Resource requests are also different, so really, you won't be able to 'drop in' your code without adding some awareness/abstraction in it that lets it handle the appclient case gracefully. With 'non-web' in general, people seem to forget that if your actions talk to a db and suchlike, then you now find yourself having to add a db connection pooling mechanism (since xwork is request/response, very much unlike how things are done normally in swing/appclient frontends). There are also a whole host of other paradigm shifts when moving to appclients, and the focus on it in xwork seems to be (perhaps wrongly) to ignore those, and focus on the final 1% of the task, which is to remove serlvet/explicit web stuff. I agree with the pain in the ass to define. So are we saying that the main advantage of interceptors is that they provide a richer urlpattern? Quoting Mike Cannon-Brookes [EMAIL PROTECTED]: Hani, Do you mean servlet filters? In which case - surely they don't work at all outside a web environment? And the other problem is that servlet filters are not applied directly to a specific action / group of actions, they are URL pattern based? (which is a royal pain in the ass to define!) Mike On 13/1/03 10:45 PM, Hani Suleiman ([EMAIL PROTECTED]) penned the words: Are interceptors really that different from filters? If they are very different, then I'm missing something and you can ignore the rest of this email... However, if they aren't that different, then I believe that they are few cases where a interceptor would be required instead of a filter. Filters should also be encouraged as they have a far better chance of working if you moved outside of a web environment. From hearing examples bandied about here, some people seem to think of interceptors for stuff like security and login, which IMHO is an abuse of them. Thoughts? Hani --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Interceptor abuse
Quoting Mike Cannon-Brookes [EMAIL PROTECTED]: Yes, I do mean servlet filters. How the hell do they work outside the web environment mate? :) They don't! I want the ability to run some code before / after defined actions. That would be awesomely useful, for the reasons you mentioned and more. Should you deny me this ability if it does not affect your code? No, of course not, I'm all for it. I'm just wary of the potential 'abuse' of interceptors. I guess it's a matter of how much rope do you give people to hang themselves with. I prefer to use Xwork (and we already use WW this way) as a generic command pattern framework. Where? Wherever command pattern makes sense. Go revise your GoF with JoeO - do not pass Go, do not collect $200 ;) I understand the command pattern, thanks. What about backend actions? Business logic? Asynchronous messaging like JMS and email? None of these even have a frontend (Swing, HTML or other) but they all work well for the command pattern style of development. Yep, good point. I don't think we're saying radically different things. I just wanted to bring up the point that writing interceptors is not entirely unrelated to writing vendor specific appserver code. It's handy dandy, but nicer if one could stick to the spec (but sometimes, the spec just isn't good enough, so one uses specific features). --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Interceptor abuse
--- Mike Cannon-Brookes [EMAIL PROTECTED] wrote: Noone is trying to get Xwork out of the web arena. They're trying to make sure it works, well, in both. -mike Herein lies comments of a new user so please read as such... Who owns/started webwork? Should they not have a say in the general direction that this project is headed? Is it just me or does the fact that it's called WEBWORK, imply a coupling to the web? Maybe it was named such because it WASN'T intended to be the king of frameworks that works for every kind of application under the sun. Maybe we all fell in love with it for it's web useage and should leave as is (with improvements of course). If the changes are so great that you require a name change, maybe you should consider a separate project? I don't see why you would abandon the WebWork name and lose all name recognition within the development community, etc. I may be biased because I don't do Swing. Sure genericity is uber-cool but in the end, there's no way you can convince me that the codebase would be as simple/readable/manageable as if it were web-specific. Our documentation is poor already (causing newcomers to read code instead of docs for understanding), let's not confuse it anymore by making it too generic. -Wayland Chan __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] Reflection
Can you explain? I'd like to know. -Original Message- From: Heng Sin Low [mailto:[EMAIL PROTECTED]] Sent: Sunday, January 12, 2003 8:48 PM To: [EMAIL PROTECTED] Subject: RE: [OS-webwork] Reflection The multiple thread thing is simple/trivial to solve using AOP. I'm not sure this would cause any performance issue though. --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] Reflection
-Original Message- From: Rickard Öberg [mailto:[EMAIL PROTECTED]] Why is it difficult? Whenever there's a thread disconnect you just get the state, and then re-set it when you want to restart the execution. What exactly is the difficulty? I'm not as familiar with the non-common usages of ThreadLocals as you are. I understand how they can be gotten and set, but how do you get them from another thread to set into this thread, when a new thread is kicked off (or a new thread, like the event handler in Swing, is suddenly being used)? --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] XWork Interceptors
You could simply add a Frequently Asked Question for this.
As I said, I don't think GD is needed anymore. Here's an example
interceptor I wrote:
public class ParameterInterceptor
implements ActionInterceptor
{
// ActionInterceptor implementation --
public String execute(ActionInvocation invocation)
throws Exception
{
// Set parameters
TypeConverter typeConverter =
Configuration.getInstance().getAction(invocation.getName()).ge
tTypeConverter();
OgnlUtil.setProperties(ActionContext.getContext().getParameters(),
invocation.getAction(), typeConverter);
return invocation.next();
}
}
I'm not so sure about this case. In this case, you need to map the
interceptor to your classes, rather than it being the default. Yes, we
can work on packages and interceptor defaults, but the fact remains that
if you leave one line out of your xwork.xml, all of a sudden request
params don't get set on your actions which equals lots of confused
emails to the list.
---
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
--
Michael Blake Day
Artistry Studios
mobile: 770.480.1547
---
This SF.NET email is sponsored by: FREE SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] XWork: core concepts
Rickard, This has been brought up before, I think, but I'm not sure it was answered well enough. What about people that want to use XML, Velocity, Jasper Reports, or some other view technology? You are using JSP to include the actions, but how would you do that with XML, for example? Blake Day On Fri, 2003-01-10 at 20:59, Rickard Öberg wrote: All, Since quite a few of you disagreed with my resignation as XWork architect, I've given some thought to how it would be possible to merge my requirements with those that you have. It might be possible to do it, and if so I would reconsider re-starting my work on XWork. I'd like to begin with defining the core concepts that XWork would have, and also briefly list my requirements, and see what your thoughts on them are. Good to have you back The core concepts that I think must be included are the following: * Actions. These are the application implementations (generic or specific) that together define the behaviour of the application. No news here. * Interceptors. These are cross-cutting concerns that apply to several actions, and which may modify the behaviour of it, produce some side-effect to the execution of the Action, or modify the input or output of the Action. * Components. This is a new concept for WebWork. Instead of just having a bunch of non-related Action's, one would bundle some of them together into a Component. An Action may be part of several Components though. The main feature of a Component is to function as a state machine which determine what Action to execute during a page rendering. * Packages. Also a new concept. There are usually two approaches to configuration: coarse-grained or fine-grained. In the coarse-grained style a setting applies to EVERYTHING in the app. In the fine-grained style each part needs to be individually configured. The first focus on ease-of-use and the latter on flexibility. Packages allow for something in between. An Action, Interceptor or Component can be defined in a Package and can easily refer to one another within that package. By having hierarchical packages can easily refer to definitions in other Packages. For example, we would most likely define a number of Actions, Interceptors and possible Components that are in a default Package, which user Packages would then depend on. However, user Packages could then override any such definition made higher up. This gives the ease-of-use of a coarse-grained configuration together with the total control and flexibility of a fine-grained configuration, while still providing reasonably clear semantics. Are views a core concept ? The other thing we might want to address is whether or not XWork will be somewhat seperated at the core from the web. These are the core concepts that I can think of. Now, for my own portlet-ish needs (which I hope will be more common for others too in the future) the following applies: * Actions and Components, and their resulting views, are ALWAYS called through a servlet include. This means that the URL in a browser NEVER reveals that XWork is used. For example, an admin app would consist of an admin.jsp which includes the Actions/Components needed for that app. Not only does that make it easy to extend the admin app later on with more portlets, it also makes it possible (for those who are so inclined) to use J2EE declarative security very easily. Plus bookmarks are human-friendly. This means that the dispatcher would explicitly disallow Action invocation that are NOT a result of an include. This too adds some extra security, since only actions that YOU decide should be called are actually callable. Plus, your actions can decide much better in what order they are called, depending on your app requirements. The actual include would still be using the .action extension though. Sure but I'm not sure how this relates to calling views outside a servlet environment ? * For many simple portlets an include of a .action is fine. For complex portlets that require a state machine this is not ok. Instead, what one usually wants is to include a component that then delegates to some action depending on the *state* of some automata. This is similar to how the CardPane works in WebWork. Essentially, XWork would include this kind of state machine as a built-in concept instead of as an add-on like CardPane, since this is such an important and common case. It needs to be as simple and flexible as is possible. When a component renders its view it also creates URL's that define what the possible next states are. This means that the URL's in the generated HTML are shortlived (i.e. after one of the URL's have been clicked they are all invalid), which also means that it will be impossible to have a double form submit. After the first submit the URL will be invalid, so clicking again will not lead to a re-execution of the action.
Re: [OS-webwork] XWork: core concepts
Correct me if I'm wrong, but didn't you all rename WebWork to XWork because WebWork was a misnomer? If the framework remains web-centric, why not just call it WebWork 1.4? Blake Day On Saturday, January 11, 2003, at 03:29 AM, Rickard Öberg wrote: This is a very difficult question. Separating it from the javax.servlet API should be possible, but overall I have the feeling that trying to make a *too* generic solution might be crippling. A little poll: *) How many have actions that are used with more than one kind of dispatcher? *) How many are using WebWork in Swing apps? *) How many are using WebWork for RPC style stuff? (the ClientServletDispatcher and friends) I don't use any of those and am quite unlikely to eve ruse them. Reason: I use app clients. webwork/xwork to me is ALL about being web only, and its role is to handle view related stuff and marshall things for the backend. EJBs do all the actual 'meat'. Appclients for me provide a far greater degree of separation, as if I went with the webwork framework for my swing clients, due to the possibility of wildly different UI's, I suspect I'd end up having to add a whole bunch of special chains/collections of actions for the appclients to use. I strongly suspect that swing/non web usage makes up 1% or less of all the users. Lets not make this unpleasant for the silent majority just to win a marketing line or two or some coolness points by saying 'we have nothing to do with the web!'. xwork should be targeted at the web, and should make the life of web developers a lot more pleasant and fun. It should NOT enforce that though and should work well outside of it, but web people should definitely be the main target audience. --- 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 -- Michael Blake Day Artistry Studios mobile: 770.480.1547 --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] XWork: core concepts
My point precisely. I think, given the current culture of XWork, we're looking at WW 2.0 (major revision change) instead of XWork... and the webwork name becomes appropriate. On Mon, 13 Jan 2003, Michael Blake Day wrote: Correct me if I'm wrong, but didn't you all rename WebWork to XWork because WebWork was a misnomer? If the framework remains web-centric, why not just call it WebWork 1.4? --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
[OS-webwork] Scope for 1.4
So, after we finally push 1.3 out the door, we're going to need an idea of what should be in 1.4. My suggestion would be refactor the GenericDispatcher and ActionFactory to put the Interceptor code in, and have a relatively quick release after 1.3 with that stuff added (and any bug fixes). Thoughts? Jason -- Jason Carreira Technical Architect, Notiva Corp. phone: 585.240.2793 fax: 585.272.8118 email: [EMAIL PROTECTED] --- Notiva - optimizing trade relationships (tm) --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: A plea - WAS Re: [OS-webwork] Reflection
After reading this for a while I cannot recall who asked for swing clients in the first place. I don't think they were ever a requirement. In terms of non web stuff I would like to see something that could talk to JMS in an asynchronous manner but I'm not going to lose sleep if it's outside the scope. We have developed a somewhat webwork like Message EJB implementation which will do fine for the forseeable future. On Mon, 2003-01-13 at 20:20, Philipp Meier wrote: I think we should keep swing clients out of the discussion at the moment. Although I do not have very much experience with swing clients, the design patterns differ from the request-response pattern of web or rpc clients. So I see no problem in pushing the development slightly away from the web to a more generic request-response pattern. -billy. -- Peter Kelley [EMAIL PROTECTED] Moveit Pty Ltd --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: A plea - WAS Re: [OS-webwork] Reflection
Funny, we were just talking about this here today. We've got a simple command pattern implementation for running batch jobs now, and I was talking about how, if we moved to Webwork, we could make a MessageDrivenDispatcher (an MDB) that would run jobs asynchronously... -Original Message- From: Peter Kelley [mailto:[EMAIL PROTECTED]] Sent: Monday, January 13, 2003 5:28 PM To: [EMAIL PROTECTED] Subject: Re: A plea - WAS Re: [OS-webwork] Reflection After reading this for a while I cannot recall who asked for swing clients in the first place. I don't think they were ever a requirement. In terms of non web stuff I would like to see something that could talk to JMS in an asynchronous manner but I'm not going to lose sleep if it's outside the scope. We have developed a somewhat webwork like Message EJB implementation which will do fine for the forseeable future. On Mon, 2003-01-13 at 20:20, Philipp Meier wrote: I think we should keep swing clients out of the discussion at the moment. Although I do not have very much experience with swing clients, the design patterns differ from the request-response pattern of web or rpc clients. So I see no problem in pushing the development slightly away from the web to a more generic request-response pattern. -billy. -- Peter Kelley [EMAIL PROTECTED] Moveit Pty Ltd --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi- bin/redirect.pl?thaw0026en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] WEBWORK under jboss-3.0.5RC1_tomcat-4.1.18
If I recall correctly, this is caused by having saxon.jar before xerces.jar on the classpath. AElfred, a non-validating parser, is being found and used before Xerces, the validating parser that you actually want to be using. Should just be a matter of changing some start up scripts or the like. If that doesn't work, you could also remove META-INF/services/javax.xml.parsers.SAXParserFactory from saxon.jar. Check around on google, this isn't a WebWork specific problem. --Erik --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] WEBWORK under jboss-3.0.5RC1_tomcat-4.1.18
Check your XML parser settings, it looks like the one you are using is non-validating. I find that xerces does all that we need but there are other validating parsers out there. On Tue, 2003-01-14 at 09:16, Jose Alvarez wrote: Can You help me please? I am trying to deploy the webwork.war file of the WebWork 1.3rc1 package under jboss 3.05. but I'am getting the following error message: 15:35:08,860 INFO [MainDeployer] Starting deployment of package: file:/C:/jag/J boss/jboss-3.0.5RC1_tomcat-4.1.18/server/default/deploy/webwork.war 15:35:11,063 INFO [EmbeddedCatalinaService41] deploy, ctxPath=/webwork, warUrl= file:/C:/jag/Jboss/jboss-3.0.5RC1_tomcat-4.1.18/server/default/tmp/deploy/server /default/deploy/webwork.war/21.webwork.war 15:35:11,454 INFO [Engine] WebappLoader[/webwork]: Deploying class repositories to work directory C:\jag\Jboss\jboss-3.0.5RC1_tomcat-4.1.18\tomcat-4.1.x\work\M ainEngine\localhost\webwork 15:35:11,514 INFO [Engine] WebappLoader[/webwork]: Deploy JAR /WEB-INF/lib/bsf. jar to C:\jag\Jboss\jboss-3.0.5RC1_tomcat-4.1.18\tomcat-4.1.x\work\MainEngine\lo calhost\webwork\WEB-INF\lib\bsf.jar 15:35:11,614 INFO [Engine] WebappLoader[/webwork]: Deploy JAR /WEB-INF/lib/comm ons-beanutils.jar to C:\jag\Jboss\jboss-3.0.5RC1_tomcat-4.1.18\tomcat-4.1.x\work \MainEngine\localhost\webwork\WEB-INF\lib\commons-beanutils.jar 15:35:11,674 INFO [Engine] WebappLoader[/webwork]: Deploy JAR /WEB-INF/lib/comm ons-collections.jar to C:\jag\Jboss\jboss-3.0.5RC1_tomcat-4.1.18\tomcat-4.1.x\wo rk\MainEngine\localhost\webwork\WEB-INF\lib\commons-collections.jar 15:35:11,754 INFO [Engine] WebappLoader[/webwork]: Deploy JAR /WEB-INF/lib/comm ons-digester.jar to C:\jag\Jboss\jboss-3.0.5RC1_tomcat-4.1.18\tomcat-4.1.x\work\ MainEngine\localhost\webwork\WEB-INF\lib\commons-digester.jar 15:35:11,834 INFO [Engine] WebappLoader[/webwork]: Deploy JAR /WEB-INF/lib/cos- multipart.jar to C:\jag\Jboss\jboss-3.0.5RC1_tomcat-4.1.18\tomcat-4.1.x\work\Mai nEngine\localhost\webwork\WEB-INF\lib\cos-multipart.jar 15:35:11,904 INFO [Engine] WebappLoader[/webwork]: Deploy JAR /WEB-INF/lib/db4o .jar to C:\jag\Jboss\jboss-3.0.5RC1_tomcat-4.1.18\tomcat-4.1.x\work\MainEngine\l ocalhost\webwork\WEB-INF\lib\db4o.jar 15:35:11,984 INFO [Engine] WebappLoader[/webwork]: Deploy JAR /WEB-INF/lib/itex t-0.81.jar to C:\jag\Jboss\jboss-3.0.5RC1_tomcat-4.1.18\tomcat-4.1.x\work\MainEn gine\localhost\webwork\WEB-INF\lib\itext-0.81.jar 15:35:12,145 INFO [Engine] WebappLoader[/webwork]: Deploy JAR /WEB-INF/lib/jasp erreports.jar to C:\jag\Jboss\jboss-3.0.5RC1_tomcat-4.1.18\tomcat-4.1.x\work\Mai nEngine\localhost\webwork\WEB-INF\lib\jasperreports.jar 15:35:12,285 INFO [Engine] WebappLoader[/webwork]: Deploy JAR /WEB-INF/lib/jdom .jar to C:\jag\Jboss\jboss-3.0.5RC1_tomcat-4.1.18\tomcat-4.1.x\work\MainEngine\l ocalhost\webwork\WEB-INF\lib\jdom.jar 15:35:12,415 INFO [Engine] WebappLoader[/webwork]: Deploy JAR /WEB-INF/lib/js.j ar to C:\jag\Jboss\jboss-3.0.5RC1_tomcat-4.1.18\tomcat-4.1.x\work\MainEngine\loc alhost\webwork\WEB-INF\lib\js.jar 15:35:12,585 INFO [Engine] WebappLoader[/webwork]: Deploy JAR /WEB-INF/lib/pell -multipart.jar to C:\jag\Jboss\jboss-3.0.5RC1_tomcat-4.1.18\tomcat-4.1.x\work\Ma inEngine\localhost\webwork\WEB-INF\lib\pell-multipart.jar 15:35:12,705 INFO [Engine] WebappLoader[/webwork]: Deploy JAR /WEB-INF/lib/saxo n.jar to C:\jag\Jboss\jboss-3.0.5RC1_tomcat-4.1.18\tomcat-4.1.x\work\MainEngine\ localhost\webwork\WEB-INF\lib\saxon.jar 15:35:12,906 INFO [Engine] WebappLoader[/webwork]: Deploy JAR /WEB-INF/lib/velo city-dep-1.2.jar to C:\jag\Jboss\jboss-3.0.5RC1_tomcat-4.1.18\tomcat-4.1.x\work\ MainEngine\localhost\webwork\WEB-INF\lib\velocity-dep-1.2.jar 15:35:13,106 INFO [Engine] WebappLoader[/webwork]: Deploy JAR /WEB-INF/lib/webw ork-examples.jar to C:\jag\Jboss\jboss-3.0.5RC1_tomcat-4.1.18\tomcat-4.1.x\work\ MainEngine\localhost\webwork\WEB-INF\lib\webwork-examples.jar 15:35:13,186 INFO [Engine] WebappLoader[/webwork]: Deploy JAR /WEB-INF/lib/webw ork.jar to C:\jag\Jboss\jboss-3.0.5RC1_tomcat-4.1.18\tomcat-4.1.x\work\MainEngin e\localhost\webwork\WEB-INF\lib\webwork.jar 15:35:14,808 ERROR [Digester] Digester.getParser: javax.xml.parsers.ParserConfigurationException: AElfred parser is non-validating at com.icl.saxon.aelfred.SAXParserFactoryImpl.newSAXParser(SAXParserFact oryImpl.java:34) at org.apache.commons.digester.Digester.getParser(Digester.java:676) at org.apache.commons.digester.Digester.getXMLReader(Digester.java:892) at org.apache.commons.digester.Digester.parse(Digester.java:1514) at org.apache.catalina.startup.ContextConfig.tldScanStream(ContextConfig .java:977) at org.apache.catalina.startup.ContextConfig.tldScanJar(ContextConfig.ja va:921) at
RE: [OS-webwork] Slow performance using ww:iterator tag (version 1.2.1)?
Thanks Dick! After adding the following to my test JSP: java.beans.PropertyEditorManager.registerEditor(String.class, sun.beans.editors.StringEditor.class); I got a significant boost in performance but its still a little slow. 1) ui:select tag Execution Time=4.253 sec 2) ui:iterator with ui:property tag Execution Time=0.449 sec 3) JSP scriptlet using WW API Execution Time=0.0020 sec At this point I'm thinking of just implementing it as an include as a JSP scriplet using the WW API for the country list. Any other ideas (other than caching)? If I've exposed a bottleneck in the WW UI tags then I'd like to help to fix it. Thanks, Kirk Rasmussen Lucasfilm Ltd. -Original Message- From: Dick Zetterberg [mailto:[EMAIL PROTECTED]] Sent: Monday, January 13, 2003 1:59 AM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] Slow performance using ww:iterator tag (version 1.2.1)? Hi Kirk, I do not use the ui: tags myself (I stick with property and iterator etc), so I cannot say for sure, but I believe the bad performance is due to the use of PropertyEditors when printing the select list. I had similar performance problems with the 1.2.1 version. The 1.3RC1 version does not have this performance problem because there one introduced a cache of the PropertyEditors. Unfortunately that is not allowed since it is not thread-safe at all (as have been discussed on the list). Last week I posted a patch to the list (and Jira), that would fix this for 1.3, but I still have not heard of any committer adding it to CVS. Anyway, back to your problem. What you can try is to patch the BeanUtil class. Change the method: String toStringValue(Object obj) to just do a: if (obj == null) return ; else return obj.toString(); However, then you cannot rely on any PropertyEditor to be used for displaying your data. I do not know how important that is for you. Or you could change it to: if (obj == null) return; else if (obj instanceof String) return (String) obj; else ( do the method as it is today...). When I first had these performance problems I noticed that when the PropertyEditorManager should return an editor for a String it took even longer that normal! It seemed as if this was because the StringEditor was not registered in the HashMap in the PropertyEditorManager, so it was not found on the first lookup, but later when the manager checks for different classnames etc. So if you do not want to do the changes to Webwork code I described above, you can try to add a String editor to the PropertyEditorManager like: PropertyEditorManager.registerEditor(String.class, sun.beans.editors.StringEditor.class); That might improve your performance a bit. Hope this helps! Good luck! Best regards, Dick Zetterberg [EMAIL PROTECTED] Original Message - From: Kirk Rasmussen [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, January 12, 2003 2:38 AM Subject: [OS-webwork] Slow performance using ww:iterator tag (version 1.2.1)? Happy new year everyone! I have a simple question about the webwork:iterator tag and performance using WW 1.2.1. I have this list of countries that contains 245 entries. When I execute the following fragment, it takes about 15 seconds to execute the iterator loop by itself. Any of you WW gurus have some pointers on making it faster? I can't simply cache the select list because the form is for an address book so the selected value is user specific. %@ taglib uri=webwork prefix=ww % %@ taglib uri=webwork prefix=ui % % long start, end = -1; % table width=100% tr !-- start cell with webwork components -- ww:action name='CountriesList' id=countrieslist/ % start = System.currentTimeMillis(); % ui:select label='Country' name='country' list=@countrieslist/countries listKey='countryCode' listValue='description'/ % end = System.currentTimeMillis(); % !-- end cell with webwork components -- /tr /table p Execution Time=%= ((double)end - start) / 1000.0 % sec /p Thanks, Kirk Rasmussen Lucasfilm Ltd. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld 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: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED]
RE: [OS-webwork] Slow performance using ww:iterator tag (version 1.2.1)?
I agree. Just for comparison check out these numbers. Something is fundamentally
wrong
with how WW is implemented or how I am abusing it :)
case 1) ui:select tag
Execution Time=12.482 sec
case 2) ww:iterator tag only
Execution Time=10.709 sec
case 3) JSP scriplet using WW API
Execution Time=0.0020 sec
Here is the code:
%@ taglib uri=webwork prefix=ww %
%@ taglib uri=webwork prefix=ui %
%@ page session=false %
%
long start, end = -1;
%
table width=100%
tr
!-- start cell with webwork components --
ww:action name='CountriesList' id=countrieslist/
% start = System.currentTimeMillis(); %
ui:select label='Country' name='country' list=@countrieslist/countries
listKey='countryCode' listValue='description'/
% end = System.currentTimeMillis(); %
!-- end cell with webwork components --
/tr
/table
p
Execution Time=%= ((double)end - start) / 1000.0 % sec
/p
table width=100%
tr
!-- start cell with webwork components --
% start = System.currentTimeMillis(); %
Country: select name=country
ww:iterator value=@countrieslist/countries
option value=ww:property value=countryCode/
ww:property value=description/
/option
/ww:iterator
/select
% end = System.currentTimeMillis(); %
!-- end cell with webwork components --
/tr
/table
p
Execution Time=%= ((double)end - start) / 1000.0 % sec
/p
table width=100%
tr
!-- start cell with webwork components --
% start = System.currentTimeMillis(); %
%
webwork.util.ValueStack vs = webwork.util.ValueStack.getStack( pageContext );
java.util.Collection countries =
(java.util.Collection)vs.findValue(@countrieslist/countries);
out.println(PRE);
for(java.util.Iterator iter = countries.iterator(); iter.hasNext(); )
{
iter.next();
}
out.println(/PRE);
%
% end = System.currentTimeMillis(); %
!-- end cell with webwork components --
/tr
/table
p
Execution Time=%= ((double)end - start) / 1000.0 % sec
/p
-Original Message-
From: Hani Suleiman [mailto:[EMAIL PROTECTED]]
Sent: Sunday, January 12, 2003 3:04 PM
To: [EMAIL PROTECTED]
Subject: Re: [OS-webwork] Slow performance using ww:iterator tag
(version 1.2.1)?
Only after the first try. I don't think slapping on oscache is the
solution, as it just hides the performance problem (of course, adding
oscache is always a good idea, but making that first hit faster would
also be a good idea)
On Sunday, January 12, 2003, at 06:00 PM, Mike Cannon-Brookes wrote:
Simple : OSCache with a session scoped cache entry. This
will drop the
run
time down to about 1ms.
Cheers,
Mike
On 12/1/03 9:36 PM, Robert Nicholson
([EMAIL PROTECTED]) penned the
words:
That is flabbergasting. Couldn't you cache the list when
the user logs
in?
Why don't you take a look at the template and see if you
can nail down
what's causing the delays assuming you haven't done that already of
course. If it's user specific what does countries method look like?
On Sunday, January 12, 2003, at 01:38 AM, Kirk Rasmussen wrote:
Happy new year everyone! I have a simple question about the
webwork:iterator tag and performance using WW 1.2.1.
I have this list of countries that contains 245 entries. When I
execute the following fragment, it takes about 15 seconds
to execute
the iterator loop by itself. Any of you WW gurus have
some pointers
on making it faster? I can't simply cache the select
list because
the
form is for an address book so the selected value is user
specific.
%@ taglib uri=webwork prefix=ww %
%@ taglib uri=webwork prefix=ui %
%
long start, end = -1;
%
table width=100%
tr
!-- start cell with webwork components --
ww:action name='CountriesList' id=countrieslist/
% start = System.currentTimeMillis(); %
ui:select label='Country' name='country'
list=@countrieslist/countries listKey='countryCode'
listValue='description'/
% end = System.currentTimeMillis(); %
!-- end cell with webwork components --
/tr
/table
p
Execution Time=%= ((double)end - start) / 1000.0 % sec
/p
Thanks,
Kirk Rasmussen
Lucasfilm Ltd.
---
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] Scope for 1.4
Kirk, As a guide, we've been shipping code based on 1.3 for a few months now. And yes, we use millions of UI tags ;) I agree with you in general though - talk of 1.4 is silly when 1.3 isn't out yet! Cheers, Mike ATLASSIAN - http://www.atlassian.com Expert J2EE Software, Services and Support On 14/1/03 7:34 AM, Kirk Rasmussen ([EMAIL PROTECTED]) penned the words: Hello everyone! I'm very pleased to make the transition towards using the WW framework for our development group and I would like to contribute back to the project. I choose to use WW over Struts as our standard MVC framework about a month ago after reading about it in various blogs and mailing lists. I downloaded the 1.2.1 version and started developing with it because it was the only release available at the time. After using WW for about 3 weeks and as an outside observer on this list for some time now it seems to me that there needs to be separate teams focused on the 1.2, 1.3, XWork, and now 1.4 branches?? There are a number of issues that still need to be resolved with the 1.2 release IMHO. I've spoken with a number of people with more WW experience than I and the common theme I've heard is don't use the UI tags. Why is that? Now that I've used them I know why...performance. As a new user it is disconcerting that the WW docs and examples are geared towards using the UI tags but in real world usage now I've been told not to use them by a number of people. I have gotten a lot of helpful advice on how to solve the performance problem (e.g. OSCache, patching BeanUtil class, etc.) but if WW is to grow as a community like Struts has, I think the current branch needs to be polished before moving on to the next big thing (1.3, XWork or 1.4?) I realize that the UI tags aren't necessary and that they are only a small part of the rest of the WW architecture. In our environment, the engineers are out numbered by the content folks by an 5 to 1 ratio. It is important that the pages be as simple as possible. Our pages that are released to production tend to get duplicated (copy paste from examples) and maintenance of the pages becomes a nightmare. I think new users will tend to download the most stable version of a product instead of the latest cutting edge version especially when documentation is lacking. What do you guys think? Is 1.2 a lost cause at this point? Is it better to focus on the 1.3 release only? Regards, Kirk Rasmussen Lucasfilm Ltd. -Original Message- From: Jason Carreira [mailto:[EMAIL PROTECTED]] Sent: Monday, January 13, 2003 11:17 AM To: [EMAIL PROTECTED] Subject: [OS-webwork] Scope for 1.4 So, after we finally push 1.3 out the door, we're going to need an idea of what should be in 1.4. My suggestion would be refactor the GenericDispatcher and ActionFactory to put the Interceptor code in, and have a relatively quick release after 1.3 with that stuff added (and any bug fixes). Thoughts? Jason -- Jason Carreira Technical Architect, Notiva Corp. phone:585.240.2793 fax:585.272.8118 email:[EMAIL PROTECTED] --- Notiva - optimizing trade relationships (tm) --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Slow performance using ww:iterator tag (version1.2.1)?
Kirk, There's a few things you can try to improve the speed: - Use the 1.3 codebase. While it isn't final, it does have some significant improvements like Rickard's FastByteArrayOutputStream for the include tag. That alone is worth it imho. - There is some areas of improvement that can be made to the codebase that I've found with a profiler. I can't remember all of them off the top of my head, but as an example the search order for action classes in the PrefixActionFactoryProxy class isn't optimal. If you look at the code it will first search for the action in ww's action.standard package then in other packages defined in webwork.properties. This is less then optimal since most action calls (at least in our applications) are not for actions in ww's action package but rather packages we define. This leads to a lot of unneccessary ClassNotFoundExceptions being thrown. A simple solution is to just reverse the search order and search from the end of the prefix list to the front. - Run the code inside of a profiler such as JProfiler, etc while at the same time hitting the page multiple times (use jmeter or the like). That will easily showcase the hotspots in the code. If you want to provide me with the action that goes alone with your sample jsp page I'll be happy to profile it here and see if I can find any obvious issues, etc. Regards, Bruce Ritchie Kirk Rasmussen wrote: Thanks Dick! After adding the following to my test JSP: java.beans.PropertyEditorManager.registerEditor(String.class, sun.beans.editors.StringEditor.class); I got a significant boost in performance but its still a little slow. 1) ui:select tag Execution Time=4.253 sec 2) ui:iterator with ui:property tag Execution Time=0.449 sec 3) JSP scriptlet using WW API Execution Time=0.0020 sec At this point I'm thinking of just implementing it as an include as a JSP scriplet using the WW API for the country list. Any other ideas (other than caching)? If I've exposed a bottleneck in the WW UI tags then I'd like to help to fix it. Thanks, Kirk Rasmussen Lucasfilm Ltd. -Original Message- From: Dick Zetterberg [mailto:[EMAIL PROTECTED]] Sent: Monday, January 13, 2003 1:59 AM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] Slow performance using ww:iterator tag (version 1.2.1)? Hi Kirk, I do not use the ui: tags myself (I stick with property and iterator etc), so I cannot say for sure, but I believe the bad performance is due to the use of PropertyEditors when printing the select list. I had similar performance problems with the 1.2.1 version. The 1.3RC1 version does not have this performance problem because there one introduced a cache of the PropertyEditors. Unfortunately that is not allowed since it is not thread-safe at all (as have been discussed on the list). Last week I posted a patch to the list (and Jira), that would fix this for 1.3, but I still have not heard of any committer adding it to CVS. Anyway, back to your problem. What you can try is to patch the BeanUtil class. Change the method: String toStringValue(Object obj) to just do a: if (obj == null) return ; else return obj.toString(); However, then you cannot rely on any PropertyEditor to be used for displaying your data. I do not know how important that is for you. Or you could change it to: if (obj == null) return; else if (obj instanceof String) return (String) obj; else ( do the method as it is today...). When I first had these performance problems I noticed that when the PropertyEditorManager should return an editor for a String it took even longer that normal! It seemed as if this was because the StringEditor was not registered in the HashMap in the PropertyEditorManager, so it was not found on the first lookup, but later when the manager checks for different classnames etc. So if you do not want to do the changes to Webwork code I described above, you can try to add a String editor to the PropertyEditorManager like: PropertyEditorManager.registerEditor(String.class, sun.beans.editors.StringEditor.class); That might improve your performance a bit. Hope this helps! Good luck! Best regards, Dick Zetterberg [EMAIL PROTECTED] Original Message - From: Kirk Rasmussen [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, January 12, 2003 2:38 AM Subject: [OS-webwork] Slow performance using ww:iterator tag (version 1.2.1)? Happy new year everyone! I have a simple question about the webwork:iterator tag and performance using WW 1.2.1. I have this list of countries that contains 245 entries. When I execute the following fragment, it takes about 15 seconds to execute the iterator loop by itself. Any of you WW gurus have some pointers on making it faster? I can't simply cache the select list because the form is for an address book so the selected value is user specific. %@ taglib uri=webwork prefix=ww % %@ taglib uri=webwork prefix=ui % % long start, end = -1; % table width=100% tr !-- start
