On Sat, Oct 25, 2008 at 1:19 AM, Dhaval Chauhan <[EMAIL PROTECTED]> wrote: > I have submitted the patch for the following two JIRAs: > > TUSCANY-2629: Enhancements to the AnyElementProcessor > [https://issues.apache.org/jira/browse/TUSCANY-2629] and > TUSCANY-2624: Missing namespace declarations at the element level > [https://issues.apache.org/jira/browse/TUSCANY-2624] > > I have attached the patch with the TUSCANY-2629 JIRA. Because the submitted > patch is combined for the above two JIRAs as they are interrelated. > I can separate them if required. > > A] Following is a summary of the working of the developed modules: > > 1. The existing processor for handling the Unknown Elements > [AnyElementProcessor] records the events inside the Unknown block of the > composite file > and returns the custom implementation of the XMLStreamReader called > 'XMLEventsStreamReader' which can be further used to regenerate/write the > model. > > 2. It was required by the processor to access the NamespaceContext for any > element at any level but the default implementation of the XMLStreamReader > was unable to provide it (TUSCANY-2624). > I have introduced another custom implementation of the XMLStreamReader > called 'TuscanyXMLStreamReader' which explicitly maintains the stack of the > namespace contexts at each element level. > Additionally, There is a custom implementation of the NamespaceContext > interface called 'TuscanyNamespaceContext' that provides NamespaceContext > related methods. > > B] There are couple of things I am trying to decide : > 1. Default location of these modules: Currently, I have added the above > mentioned modules inside the 'contribution-xml' package. > So, can someone guide me for their default location?
Processors should be ok in contribution-xml, but I think pure xml utilities such as these and couple others available in the databinding framework and embedded in some processors should ideally be in it's own module. > > 2. Initialization of the TuscanyXMLStreamReader : Currently, the > TuscanyXMLStreamReader is initialized explicitly from the testcase for the > AnyElementProcessor [AnyElementReadWriteTestCase] > I am using a singleton called 'TuscanyXMLInputFactory' that returns the > instance of the TuscanyXMLStreamReader whenever required. > So, the other issue is how to incorporate the usage of the > TuscanyXMLStreamReader inside the runtime? > I got confused here. When a regular application is processing a contribution and parse a composite, is this new reader being used ? Or is it being used only when the test case is executed ? If your question is whether we should use it only when processing the composite versus using it throughout the runtime, I'm not sure I have a concrete answer, but I'd probably concentrate on verifying that the tooling scenario described in the original JIRA is covered, and minimize the risks of exposing this trough the whole runtime. What others think here ? > Looks like the summary went longer but I couldn't find a better way to > explain the patch. Hope it clears the scenario. > So, are you waiting to finalize these questions before applying the patch ? I guess we could apply the patch if everything builds ok, and update the code if the discussions reach any concensus in a different direction. Thoughts ? > Thanks, > Dhaval > > > > > > ________________________________ > Want to read Hotmail messages in Outlook? The Wordsmiths show you how. Learn > Now -- Luciano Resende Apache Tuscany, Apache PhotArk http://people.apache.org/~lresende http://lresende.blogspot.com/
