cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benson Margulies" <bimargul...@gmail.com>
Subject Re: [PLEASE [DISCUSS]] Spring validation
Date Thu, 13 Mar 2008 18:43:01 GMT
OK.

Methinks that a reasonable task list is:

1) fix the property name.
2) Do anything that is not gigantic on the endpoint creation side.
3) tackle the problem of selective validation prevention. it will require
copying out the guts of a Spring class into BusApplicationContext.

A big, conspicuous 'tuning' page seems indicated even if it doesn't have
much content to start with, I agree.

On Thu, Mar 13, 2008 at 10:33 AM, Daniel Kulp <dkulp@apache.org> wrote:

> On Thursday 13 March 2008, Johnson, Eric wrote:
> > From a usability standpoint, Glen is correct. It is better to have
> > user's file validated by default so that they fail fast and have a
> > good warning message about the cause. It would also be a good
> > usability tact to have the property that controls validation have a
> > cxf prefix to make it clear that it is a cxf thing.
>
> Agreed.
>
> If you CAN turn it off for the META-INF/cxf/cxf-extension* stuff, that
> would be great, but I do think it needs to default to on for the user
> config files.  Before we had the validation working, it drove me nuts
> when something didn't work and it was because I misspelled an attribute
> name or something.   Without the validation, those mistakes are
> sometimes very hard to track down.
>
> That said, we probably need a "tuning faq" page on the wiki that
> describes some of the things that affect performance.   How to turn off
> validation would be one thing.   Other things like avoiding jaxws
> handlers is another (the opposite direction).
>
>
> Dan
>
>
>
> >
> >
> >
> > -----Original Message-----
> > From: Glen Mazza [mailto:glen.mazza@verizon.net]
> > Sent: Thu 3/13/2008 5:48 AM
> > To: cxf-dev@incubator.apache.org
> > Subject: Re: [PLEASE [DISCUSS]] Spring validation
> >
> > I don't know the full story here--is this validation occurring for web
> > services or SOAP clients--which one is your main concern?  Also, is
> > this validation occurring for *every* web service request (client
> > side) or *each* web service processing (service side)--or just once?
> > Also, which config files are you speaking of--just the main cxf.xml
> > one used for the bus?
> >
> > I suspect we do not need to be validating our own static configuration
> > files (if any), but validating their config files would appear to make
> > sense--this is something they can turn off if it performance is a
> > problem for them.  For newbies, I think is is better to have
> > validation over performance, even if it is not immediately obvious to
> > the newbie how to optimize performance.
> >
> > Also, is this "spring.validation.mode" property a Spring default name
> > (i.e., those working with Spring usually know about it)?  Then perhaps
> > it would be best to keep using that property name.  Just as the
> > benefits of working with Maven is that all projects run alike, a
> > similar argument can be made for configuring Spring-based
> > applications.
> >
> > Regards,
> > Glen
> >
> > Am Donnerstag, den 13.03.2008, 03:54 -0400 schrieb Benson Margulies:
> > > This message is an outgrowth of my performance investigations.
> > >
> > > We are (still?) validating spring XML files by default, at high
> > > cost.
> > >
> > > We control validation with a system property with a name that
> > > doesn't say 'cxf' in it anywhere.
> > >
> > > I could submit the following change:
> > >
> > > 1) Add the name org.apache.cxf.spring.validation.mode as a
> > > (compatible) replacement for spring.validation.mode.
> > >
> > > 2) Treat the default as 'none'.
> > >
> > > Or, I could make the BusApplicationContext force validation off when
> > > reading any file with a pathname beginning with META-INF:/cxf (e.g.,
> > > one of ours), so that users still get validation by default.
> > >
> > > Please send along thoughts.
>
>
>
> --
> J. Daniel Kulp
> Principal Engineer, IONA
> dkulp@apache.org
> http://www.dankulp.com/blog
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message