That wouldn't help for the 'include' style, but it would for the 'find them all in the classpath.'
On Thu, Mar 13, 2008 at 6:55 PM, Dan Diephouse <[EMAIL PROTECTED]> wrote: > Have you tried creating multiple ApplicationContexts? i.e. create the > first application context which is not validated with all the CXF files. > Then create another with all the user files which has the first context > as the parent. > > Dan > > Benson Margulies wrote: > > One more note for now: it's harder than I had hoped to be selective > about > > validation, due to the modularity of Spring. I haven't given up yet. > > > > On Thu, Mar 13, 2008 at 7:09 AM, Benson Margulies <[EMAIL PROTECTED] > > > > wrote: > > > > > >> The validation in question is of spring configuration files. It occurs, > >> first and foremost, as part of Bus initialization on both server and > client. > >> It's the user's cxf.xml plus all the included files, and/or the > invisible > >> process of loading a series of Spring XML files to set up the default > bus. > >> The identifier spring.validation.mode was apparently invented by us, at > >> least as far as a quick google would indicate. > >> > >> From my point of view, it takes CXF a surprisingly long time to start > up, > >> and so moving all validation from on by default to off by default > appeals to > >> me. Documentation would seem to be an important aspect. > >> > >> However, if no one disagrees with your preference to leave validation > in > >> general on by default but turn it off for our internal files, then I'll > very > >> cheerfully do that. > >> > >> > >> > >> > >> On Thu, Mar 13, 2008 at 5:48 AM, Glen Mazza <[EMAIL PROTECTED]> > >> wrote: > >> > >> > >>> 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. > >>>> > >>> > > > > > > > -- > Dan Diephouse > MuleSource > http://mulesource.com | http://netzooid.com > >
