Why all of this external reference resolver thing gets into XWork?
Couldn't you just extend DefaultActionProxyFactory, DefaultActionInvocation
and do whatever logic to integrate with the IoC container and/or use an
interceptor?
Even XWorks own IoC container does not need this kind of
I looked through the code a bit last night with a special interest on the
Velocity dependencies. As far as I can see it would be quite easy to
refactor the current UI tags to avoid the hard coded velocity dependency
and provide a plugable template handler. This would allow for a template
- Original Message -
From: Fredrik Lindgren [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, December 12, 2003 9:20 AM
Subject: Re: [OS-webwork] WebWorks without velocity how to
I looked through the code a bit last night with a special interest on the
Velocity dependencies. As far
It is a neater soloution to provide a plugable external resolver system
into xwork.
Xwork's IOC container is currently limited to only one instance of any
component type, similiar to Nano or Pico container's 'metadata free'
configuiration. (i.e. it uses type matching to resolve components)
Freemark looks powerfull, I'd like specially the builtin support
for using jsp taglibs. I will give it a try right now.
Thank
you, Cameron.
Richard HALLIER.
-Message d'origine-De:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]De la part de
Cameron BraidEnvoy: vendredi 12
by [] value do you mean a parameter was passed to the action like
foo.action?bar=
??
Jason Carreira wrote:
So WW1.3 takes [] and sets null on a String property?
-Original Message-
From: Lars Fischer [mailto:[EMAIL PROTECTED]
Sent: Thursday, December 11, 2003 6:38 AM
To: [EMAIL
In WW1.3 and 1.4 a string parameter that is empty will set the string property to the
empty string. Not null.
If your program choose to interpret this as null that is up to you. How can you
otherwise see the difference between a parameter that is not sent in at all and one
that is sent in but
Francois,
:)
As for why it's required, it makes everything more flexible - and it's not
required at all. Just ignore it and it will do you no harm.
Pico is good (for somethings) but personally I much prefer Spring (that's a
large debate for another time - each to their own) :)
- XWorks IoC
It's very nice to hear such answer. I'm not against velocity, I only little
confused about some decisions was made for ww2. I truly believe that ww2
should be able to work even without presentation layer. But to provide full
functionality it has already, it should have an additional
Actually, I agree with Dick here - it _SHOULD_ be an empty String, not null.
The empty string indicates that the form was submitted with an empty value
in the text field - which is exactly what happened.
A null value indicates that the form was not submitted, or else the text
field did not exist
The problem here is that a HTML form ALWAYS submits parameters as empty
strings, you cannot 'not' send a parameter in.
Mathias
-Original Message-
From: Dick Zetterberg [mailto:[EMAIL PROTECTED]
Sent: vrijdag 12 december 2003 10:45
To: [EMAIL PROTECTED]
Subject: Re: [OS-webwork] Empty
seems to be some confusion with this, can someone post what it currently
works like in ww1 and how its supposed to in ww2 (same as ww1, for
backwards compat i assume..)
so say I have foo.action with bar string property
what should bar be when i submit an action like foo.action?bar=
what
_exactly_ - you put it perfectly mate.
So how do you tell the difference between a parameter, and not a parameter?
(ie the text field never existed on the form at all) :)
Cheers,
Mike
On 12/12/03 8:59 PM, BOGAERT Mathias ([EMAIL PROTECTED]) penned the
words:
The problem here is that a HTML
Title: RE: [OS-webwork] Empty string property now instead of null?
A question, why is Long parameters from the FORM set to null, and not String? Cant it be set to Long(0) then?
/Mathias.
-Original Message-
From: Francisco Hernandez [mailto:[EMAIL PROTECTED]]
Sent: den 12 december
Yes you can, you just do not include them in the form. Different forms could for
example be used to submit data to the same action.
Dick
- Original Message -
From: BOGAERT Mathias [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, December 12, 2003 10:59 AM
Subject: RE: [OS-webwork]
Well, that's why we almost always use Strings for critical data - data
conversion (like ints has many problems).
Chief among them IMHO is that if you have a textfield backed by a get/set
int method, and someone submits 'abc' - you're fucked (regardless of whether
it sets null, 0, -1 or any other
- Original Message -
From: Mathias Berg [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, December 12, 2003 11:18 AM
Subject: RE: [OS-webwork] Empty string property now instead of null?
A question, why is Long parameters from the FORM set to null, and not
String? Cant it be set
Sorry, I was talking about the BeanUtil part in WW 1.2 / 1.3.
Something like
BeanUtil.setProperties(ActionContext.getContext().getParameters(),
bean_to_set_properties);
When working with a bean to reflect a row in a Database, it's wrong to
set String values for bean propertties to when the
On Dec 11, 2003, at 1:22 PM, Jason Carreira wrote:
WW1 you can use without velocity, WW2 uses velocity for its UI tag
templates. If you don't plan to use the UI tags, you can remove it.
You can use WW2 and just use JSPs and never have to write any Velocity
templates. However, Velocity is still
- Original Message -
From: Mike Cannon-Brookes [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, December 12, 2003 11:55 AM
Subject: Re: [OS-webwork] WebWorks without velocity how to
It's very nice to hear such answer. I'm not against velocity, I only
little
confused about some
- Original Message -
From: Tracy Snell [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, December 12, 2003 1:49 PM
Subject: Re: [OS-webwork] WebWorks without velocity how to
On Dec 11, 2003, at 1:22 PM, Jason Carreira wrote:
WW1 you can use without velocity, WW2 uses velocity
Regardless what have been said before. Treatment of strings and other form's
variable has to be as it is written HTTP and HTML protocol and ww1, ww2,
struts, maven or whatever have to be implemented in the way as it is in
specification. They have to be transparent. Are you gaing to explain to
Guess what this does?
html
body
form method=post action=http://myhost/app/myAction.action
input name=@[EMAIL PROTECTED](1).dummy value=/
/form
/body
/html
John.
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does
Cool, very cool. What are you going to do with that?
- Original Message -
From: John Patterson [EMAIL PROTECTED]
To: Webwork [EMAIL PROTECTED]
Sent: Friday, December 12, 2003 3:23 PM
Subject: [OS-webwork] Security flaw with WW2
Guess what this does?
html
body
form method=post
Time to brush up on Java security policies.
- Original Message -
From: Carlos Villela [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, December 12, 2003 1:32 PM
Subject: RES: [OS-webwork] Security flaw with WW2
OOUCH!
Ok, possible solutions:
- Disallow POSTs with unknown
Unfortunately, that's like saying if I don't like commons-logging, I
shouldn't be forced to use it. Or if I don't like ognl, I shouldn't be
forced to use it. You can't make every dependency in the library pluggable.
The only reason I could see velocity becoming a barrier to your work with
webwork
Well, we are not all up to date on Java security policies, but since you
seem to be, care to enlighten us?
Thanks,
Mathias
-Original Message-
From: John Patterson [mailto:[EMAIL PROTECTED]
Sent: vrijdag 12 december 2003 14:42
To: [EMAIL PROTECTED]
Subject: Re: [OS-webwork] Security flaw
I disagree. I think the point he's making is 'if I don't want to use
velocity templates, I should not need velocity'. Equivelant statements
are:
'if I don't want to use ognl-expressions, I should not need ognl'
'if I don't want to use jasper reports, I should not need jasper
reports'
'if I
It's not as easy as it sounds.
The JVM allows one security policy, so you'd have to fine tune a policy
file and ensure that it doesn't cause your appserver to become upset.
Some servers have their own policy files that need to be tweaked,
others will need one from scratch.
On Dec 12, 2003, at
Ok I'm fine, I only said my opinion, and it's strong. If evryone is happy
with that and sees no preblem here then I'm not going to complain. Then we
are comming back why did you split ww2 and xwork? Sounds like this was
interesting job, and that is not so intesting, so will we leave it as it is.
Yes you ar right. I do accept yours opinion. I only wanted to state not
evryting have to be that way. As exaple OGNL or any other critical palt that
is critical can to be as a must, here is nothing wrong in that. But velocity
is not a must part.
Again I saw what someone is working on
FYI you can find information on how to do this for WebLogic 8.1 here:
http://edocs.bea.com/wls/docs81/security/server_prot.html#1032262
Mathias
-Original Message-
From: Hani Suleiman [mailto:[EMAIL PROTECTED]
Sent: vrijdag 12 december 2003 14:56
To: [EMAIL PROTECTED]
Subject: Re:
The point is that even though the current state of affairs is that velocity
is required behind the scenes and for the UI tags, it seems to fairly easy
to fix that. In case it is easy to fix it, we should do so, since webwork
should not have more required dependencies than needed.
I don't think
Perhaps I don't understand you, or perhaps I was not clear enough earlier. If you do
not have a field in your form then of course the property will be null. If the field
contained the empty string then the property (if it is a String) will be set to the
empty string. There is nothing strange
Is this an issue with Webwork 1.4 as well?
Blake
- Original Message -
From: BOGAERT Mathias [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, December 12, 2003 9:06 AM
Subject: RE: [OS-webwork] Security flaw with WW2
FYI you can find information on how to do this for WebLogic 8.1
Disallowing POSTs with unknown referrers doesn't work at all. You can forge
the Referer header easily.
Blake
- Original Message -
From: Carlos Villela [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, December 12, 2003 8:32 AM
Subject: RES: [OS-webwork] Security flaw with WW2
Surely the OGNL context that these expressions (params interceptor) are
being executed within can be configured to disallow static invocation.
Cameron
Tobias Järlund wrote:
Well, this seems to go well beyond shutting down the server. I'm
pretty sceptical to the idea of having parameter names
That's not handled by Xwork. You'll want to look at setting up your
persistence tool, like Hibernate.
-Original Message-
From: grendelAI [mailto:[EMAIL PROTECTED]
Sent: Thursday, December 11, 2003 8:24 PM
To: [EMAIL PROTECTED]
Subject: [Webwork-user] Re: Simple Database Example
I think this is the way to go. We'll have to wait for Patrick to come in to hear his
thoughts.
-Original Message-
From: Cameron Braid [mailto:[EMAIL PROTECTED]
Sent: Friday, December 12, 2003 10:35 AM
To: [EMAIL PROTECTED]
Subject: Re: [OS-webwork] Security flaw with WW2
What about the case where you had some previous state in the field from
the session and you want to empty it out? You'd never be able to.
-Original Message-
From: BOGAERT Mathias [mailto:[EMAIL PROTECTED]
Sent: Friday, December 12, 2003 5:21 AM
To: '[EMAIL PROTECTED]'
Subject: RE:
Well, fucked is a little strong... You can (and someone should, just not
me :-) ) create UI templates that will access the type conversion error
map to get the submitted values which could not be converted and
re-display them.
-Original Message-
From: Mike Cannon-Brookes [mailto:[EMAIL
Interceptors are instantiated once per ActionConfig (per Action alias).
I believe there's an InterceptorBuilder class (or something like that) that Mike C-B
refactored out of the original design. Right now this is not pluggable. One of by big
plans for Xwork 1.1 is to refactor ALL object
In addition, I recommend disallowing *any* method invocations (static
or not) from an HTTP request.
Quoting Jason Carreira [EMAIL PROTECTED]:
I think this is the way to go. We'll have to wait for Patrick to come
in to hear his thoughts.
-Original Message-
From: Cameron Braid
So Mike,
You guys developed the external-ref stuff, what do you think of Cameron's changes? It
sounds like he made it more flexible and powerful to me...
-Original Message-
From: Mike Cannon-Brookes [mailto:[EMAIL PROTECTED]
Sent: Friday, December 12, 2003 4:51 AM
To: [EMAIL
The modifications that I have made won't be going into Xwork since the
existing functionalty should be sufficient for most (probably all)
needs.
The existing system allows you to define an external refrence resolver
(per package, with inheritence from the parent package).
You can then add
What uses Velocity outside the templates?
-Original Message-
From: Fredrik Lindgren [mailto:[EMAIL PROTECTED]
Sent: Friday, December 12, 2003 2:20 AM
To: [EMAIL PROTECTED]
Subject: Re: [OS-webwork] WebWorks without velocity how to
I looked through the code a bit last night with
Great idea ;)
So will there be a XworkFactoryFactory ;)
interface XworkFactoryFactory
{
ActionFactory getActionFactory();
InterceptorFactory getInterceptorFactory();
ExternalRefrenceResolverFactory getExternalRefrenceResolverFactory()
etc..
}
Cameron
Jason Carreira wrote:
:-) I don't know if I'd use the word lurking
-Original Message-
From: Tracy Snell [mailto:[EMAIL PROTECTED]
Sent: Friday, December 12, 2003 6:50 AM
To: [EMAIL PROTECTED]
Subject: Re: [OS-webwork] WebWorks without velocity how to
On Dec 11, 2003, at 1:22 PM, Jason Carreira
-Original Message-
From: remigijus [mailto:[EMAIL PROTECTED]
Sorry - I'm totally confused here. XWork is WebWork without the
presentation
layer. What is WebWork without a presentation layer?!?
(Nothing! :))
If you will look at it as an Http layer it will make a
Thanks for the great news Jason. We're looking forward to that!
XWork and Pico together is a real winning combination. Currently, there is
an issue with the Pico integration and I'd like to leverage your expertise
on XWork.
Pico-extras defines a sub-class of DefaultActionInvocation that
I disagree back. It depends on what the thing is that's being used. As it
is, OGNL is pretty core to a lot of functionality in webwork and xwork both.
It's a core dependency. You couldn't remove it without a lot of hassle, and
at that point, why bother using xwork or webwork at all? Find another
Xwork has NO dependencies on velocity! None! Zero! Webwork is a web-centric
presentation layer that offers several presentation methods, including JSP,
velocity, and freemarker. It happens to use velocity behind the scenes. That
has nothing to do with the relationship between webwork and xwork!
Xwork is a generic command pattern implementation with no web
dependencies at all, either Servlet/JSP or Velocity.
-Original Message-
From: remigijus [mailto:[EMAIL PROTECTED]
Sent: Friday, December 12, 2003 8:57 AM
To: [EMAIL PROTECTED]
Subject: Re: [OS-webwork] WebWorks without
I talked to him about this on ICQ actually.
It does make it more flexible and powerful, but also more complex. I'm not
sure that complexity is needed (even Cameron himself says he doesn't need
it), so can we add it when/if someone requests it? :)
As for the resolver resolving one reference at
ServletDispatcher.init initializes the VelocityManager, which in its turn
imports some velocity classes. The ServletDispatcher does not use the
VelocityManager, hence should not depend on it. As a matter of fact the
WebWorkVelocityServlet also initializes the velocityManager. This should
mean
Does anyone have any tips on doing preprocessing when a form fails
validation?
I have a form that some information from the database to set up the user
interface.
Normally I just do this in the execute method. But when the form fails
xwork validation, the execute method is never called. Does
you can do pre-execute-processing using the Preparable interface with
the Preparable Interceptor, just make sure the interceptor runs before
the validation and workflow interceptors if you're using those.
Tao Starbow wrote:
Does anyone have any tips on doing preprocessing when a form fails
57 matches
Mail list logo
