On Thu June 4 2009 8:46:08 pm Benson Margulies wrote: > I'm feeling a bit 'phased'. I already did my first effort here in > AbstractInDatabindingInterceptor, and it seems that this is too late. > Just where do I have to be to be after reading the body element?
Hmm.... The ReadHeadersInterceptor might need to be spit into two interceptors. If you see the bottom of it's handleMessage, you see it advances to the first token inside the soap:body. If the first token was whitespace, you probably would be OK. However, that's not normal. I think you would need to set your schema right in there someplace. Thus, that loop might need to be put into a separate interceptor so that you could inject a new interceptor between the ReadHeadersInterceptor and that new interceptor. Dan > > On Tue, Jun 2, 2009 at 12:41 PM, Daniel Kulp <[email protected]> wrote: > > On Mon June 1 2009 9:44:25 pm Benson Margulies wrote: > >> The way Tatu has woodstox validation set up, it would be desirable to > >> activate it just before reading the first part-element. The code I've > >> got so far wants to see the part, and thus get dispatched into the > >> data binding, and then turn on validation. By which time, it's (for > >> now) too late. > >> > >> It occurs to me that perhaps there's enough information to do this the > >> other way. An endpoint can only have one data binding going, I think, > >> so some sort of interceptor magic could call the DB and allow it to > >> set validation on the stream before reading the part elements? > > > > Yea. That makes complete sense. An interceptor that runs after the > > reading of the soap:body element that would set this up would definitely > > be the preferred route for doc/lit endpoints. For RPC/Lit, I think the > > current setup is correct (as you don't validate the element name, just > > the type), but those are rare (and don't work with JAXB validation > > either). > > > > In the AegisDataBinding init method, you should be able to add an > > interceptor to the Service object. I believe that would work. > > > > -- > > Daniel Kulp > > [email protected] > > http://www.dankulp.com/blog -- Daniel Kulp [email protected] http://www.dankulp.com/blog
