I have fixed most of the issues in svn revision #698102. We can still enhance the processor implementation, and produce some more efficient structure to store the unknown elements as you suggested... this should be the next step here.
Thanks On Fri, Sep 19, 2008 at 8:20 AM, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > Luciano Resende wrote: >> >> On Thu, Sep 18, 2008 at 10:35 PM, Jean-Sebastien Delfino >> <[EMAIL PROTECTED]> wrote: >>> >>> I found the following issues in DefaultUnknownElementProcessor. >>> >>> - it's an implementation class, in an API package >>> >> >> We have couple Default implementation on the same level... but anyway, >> what is your suggestion for a better location ? >> > > More than a couple, seven in that package. But these Default* classes are of > a different nature. They are default implementations of some of main core > extensibility SPIs, extension points and registries for example. > > BTW, in my opinion another class DefaultValidatingXMLInputFactory is not an > SPI and should move out of the SPI package as well. > > Here are some suggestions: > > - rename it AnyElementProcessor as this processor is not more a 'default' > processor than any other processors like CompositeProcessor for example, and > it's really used to handle instances of xsd:any elements for which we have > no other processor registered. > > - register it using a META-INF/services entry as all other processors > (instead of hardcoding its creation), with an xsd:any Qname (by xsd I mean > the XML schema's namespace). > > - when you need it look up using xsd:any as a key. > > - in its constructor, look up the DocumentBuilderFactory as we do for most > other factories. > > - move it to modules assembly-xml or contribution-xml. > > Hope this helps. > -- > Jean-Sebastien > -- Luciano Resende Apache Tuscany, Apache PhotArk http://people.apache.org/~lresende http://lresende.blogspot.com/
