I also did some reflection on this issue and François summed up
nicely all my thoughts.
I completely agree with him.
-Paolo
>-Original Message-
>From: Francois Beauregard [mailto:[EMAIL PROTECTED]]
>Sent: Wednesday, January 15, 2003 5:35 AM
>To: [EMAIL PROTECTED]
>Subject: [OS-webwork] Co
Part of the message was lost on the way. Here is (hopefully) the complete
one.
I am concerned that the next version of WebWork (or XWork) will be built in
a sandbox mode. I hope the sandbox is just a place to try things and design
stuff. When features and ideas are stable enough they should be bro
Yup, that's the plan. Sandbox is still all about hasing out ideas (although
the codebase is probably more stable than webwork, if only because it's got
good unit test coverage in place).
-Pat
- Original Message -
From: "Francois Beauregard" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent
I am concerned that the next version of WebWork (or XWork) will be built in
a sandbox mode.
I hope the sandbox is just a place to try things and design stuff. When
features and ideas are stable enough they should be brought into the actual
code base in a 'refactor the code' way. WebWork's code has
Kirk,
Ahh - I would suggest that you update CVS, it is much, much faster and most
of these performance improvements have already been made :)
Cheers,
Mike
On 15/1/03 1:10 PM, "Kirk Rasmussen" ([EMAIL PROTECTED]) penned
the words:
> Mike,
> I should qualify that I am running the 1.2.1 build for m
Dick,
The changes you've submitter have been added to CVS. Thanks!
-Pat
- Original Message -
From: "Dick Zetterberg" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, January 14, 2003 3:25 AM
Subject: Re: [OS-webwork] Scope for 1.4
> Mike,
>
> Aren't you worried about the non-t
Kirk Rasmussen wrote:
Has anyone profiled webwork with JProbe or similar tools to look for hot
spots that could be optimized?
Yes, but it was some time ago. I'm probably going to profile it again once
I decide to update the webwork version that Jive is using (currently 1.2.1
+ a lot of cvs cha
Mike,
I should qualify that I am running the 1.2.1 build for my
tests. I have not tried 1.3 RC1 yet.
However, even when I eliminated the tag and used a straight
to product the select list it only reduced the execution
time to 10 secs versus 13 secs. To me this poses a significant problem,
Kirk,
Well - yes and no. JIRA uses OSCache, but not for the UI tags. None of those
are cached at all, and we have literally hundreds ;)
OSCache is only used where certain pages take a long time to generate for
various reasons (most often because of the computations required to
calculate the data
Not really. It gets its speed because the template is single
purpose -- i.e. for creating the select list for countries (254 elements).
The list is not passed in to the template. The list is obtained by
calling another action within the template.
This was just one example of how to optimize
Yup, Kirk's option here is the best way to get immediate performance
improvements. I've made a very generic "selectfastmap.jsp" template for
large lists of Map objects. Works much faster.
-Pat
- Original Message -
From: "Kirk Rasmussen" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tu
Could this be applied as a patch of some sort to the template for the
select ui component?
> -Original Message-
> From: Kirk Rasmussen [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, January 14, 2003 8:34 PM
> To: [EMAIL PROTECTED]
> Subject: RE: [OS-webwork] Scope for 1.4
>
>
> I assume th
I assume that JIRA uses OSCache, right? Jive 3.0 default skin
uses webwork also but they avoid the UI tags completely.
Here is what I did to make my countries list very fast.
It isn't ideal but it works and it was plugin compatible to the
tag.
FYI I got the execution time down from 13 sec
Mike,
We use JIRA and the performance is fine but our product webwork code
performance is awful at the moment. Have you any tips for the
performance challenged ?
On Tue, 2003-01-14 at 16:00, Mike Cannon-Brookes wrote:
> Kirk,
>
> As a guide, we've been shipping code based on 1.3 for a few mont
On Tue, 2003-01-14 at 21:17, Robert Nicholson wrote:
> Why does it have to be a MDB? Can't you just make a listener? What will
> an MDB buy you?
>
In a word: transactions (oh also instance caching for tuning but that
would be more than 1 word :) )
We use a lot of MDBs in our app for these reaso
I see you use PropertyDescriptor to do field
validation. How do I pass parameters to propertyEditorClass so I can re-use a
validator across different fields? Example: Suppose I have an IntegerValidator
which can check a range.
Have you guys thought about adding a field group
validation me
Maybe the way that FreeBSD does their source management would be a good
approach for ww/xwork/open symphony?
They always have HEAD/CURRENT which is the latest and greatest, they then
branch off from there to create the various versions.
For example:
XWORK 2.0 would be HEAD/CURRENT
1.3
1.2
1.1
I
Kirk,
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?
I agree completel
I would suggest using 1.3.. I have been using it from CVS for a large number
of projects and it's worked out great. There are many bug fixes that you
would surely run into with 1.2.
The documentation does need some help, if you read the JDJ (Dec issue) I
have pointed this out. There are ways aroun
Great catch!
Dick Zetterberg wrote:
I have found a line of code in the factory PrefixActionFactoryProxy that I
think is erroneous. It prevents all lookups of action names with prefixes
from being cached.
This means that for EACH action invocation you get something like 3-5 tries
(depending on yo
+1 to that
- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Tuesday, January 14, 2003 6:53 AM
Subject: Re: [OS-webwork] Bug in PrefixActionFactoryProxy? + patch
> Thanks Dick! Dick is on a role here and I would like to
> propose to giv
Great catch Dick! We were actually just running in to a problem with this
very recently. I'll be sure to get this in, as well as your PropertyEditor
fix, right away.
-Pat
- Original Message -
From: "Dick Zetterberg" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, January 14, 20
Thanks Dick! Dick is on a role here and I would like to
propose to give him R/W access so he can apply his
patches since most of us don't seem to have the time.
-Matt
On Tue, 14 Jan 2003, "Dick Zetterberg" wrote:
>
> I have found a line of code in the factory
> PrefixActionFactoryProxy that I
Well, for me it's just easier. I can slap an MDB into our system here in
a matter of minutes with Xdoclet building the deployment descriptors.
I'm not sure if this is something that would go into Webwork or just us
put it into our system.
> -Original Message-
> From: Robert Nicholson [mail
I have found a line of code in the factory PrefixActionFactoryProxy that I
think is erroneous. It prevents all lookups of action names with prefixes
from being cached.
This means that for EACH action invocation you get something like 3-5 tries
(depending on your webwork.properties) to find the cor
Hello everyone,
I don't want to be a killjoy, but can we please aggree on a minimum of
rules on this mailing list.
When quoting somebody else's message
- Remove all parts you do not refer to. This improves the signal to
noise ratio.
- Put you comments "inline", that means directly below
What xwork is isn't clearly defined yet. What there is is some sandbox code for
testing new ideas and playing around. I think the following is correct though...
- xwork is touted as a 'next generation of webwork', so it's not a new version
per se. It certainly will not be backward compatible fro
Clustering, pooling, tx, container managed, all that and more!
Quoting Robert Nicholson <[EMAIL PROTECTED]>:
> Why does it have to be a MDB? Can't you just make a listener? What will
> an MDB buy you?
>
> On Monday, January 13, 2003, at 11:13 PM, Jason Carreira wrote:
>
> > Funny, we were jus
Mike,
Aren't you worried about the non-threadsafe PropertyEditor caching in the
1.3RC1 release?
I certainly was, which is why I made a patch for it that I submitted to the
list (and Jira) last week.
I have not heard much comments about it yet though. Is it ok to add this
patch to CVS?
If no commi
Why does it have to be a MDB? Can't you just make a listener? What will
an MDB buy you?
On Monday, January 13, 2003, at 11:13 PM, Jason Carreira wrote:
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
talk
I don't think we're sure yet.
On Tue, 14 Jan 2003, [iso-8859-1] Joel Cordonnier wrote:
>
> Hi !
>
> Can someone explain me what is XWork really !? Just a new version of WW, with
>additional functonalities, or WW with basic API implementation (Portlet API..).
>
> This question, because i want to
Hi !
Can someone explain me what is XWork really !? Just a new version of WW, with additional functonalities, or WW with basic API implementation (Portlet API..).
This question, because i want to port the Websphere Portal Server / portlet API to WW, if possible. Is it better to switch to XWork ?
Th
32 matches
Mail list logo
