You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Dhaval Chauhan <dh...@hotmail.com> on 2008/10/25 10:19:30 UTC
Summary of the submitted patch for TUSCANY-2629 (handling unknown
contents) and TUSCANY-2624 (missing namespace declarations)
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? 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?
Looks like the summary went longer but I couldn't find a better way to explain the patch. Hope it clears the scenario.
Thanks,
Dhaval
_________________________________________________________________
Want to read Hotmail messages in Outlook? The Wordsmiths show you how.
http://windowslive.com/connect/post/wedowindowslive.spaces.live.com-Blog-cns!20EE04FBC541789!167.entry?ocid=TXT_TAGLM_WL_hotmail_092008
RE: Summary of the submitted patch for TUSCANY-2629 (handling
unknown contents) and TUSCANY-2624 (missing namespace declarations)
Posted by Dhaval Chauhan <dh...@hotmail.com>.
I have submitted a new patch with few changes to the TUSCANY-2629 JIRA (https://issues.apache.org/jira/browse/TUSCANY-2629)
It solves two issues: TUSCANY-2629 and it's dependent JIRA - TUSCANY-2624 (https://issues.apache.org/jira/browse/TUSCANY-2624)
Please disregard all the previous patches.
Thanks,
Dhaval
> Date: Sun, 26 Oct 2008 10:15:05 -0700
> From: luckbr1975@gmail.com
> To: dev@tuscany.apache.org
> Subject: Re: Summary of the submitted patch for TUSCANY-2629 (handling unknown contents) and TUSCANY-2624 (missing namespace declarations)
>
> On Sat, Oct 25, 2008 at 1:19 AM, Dhaval Chauhan
> <dh...@hotmail.com> 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/
_________________________________________________________________
You live life beyond your PC. So now Windows goes beyond your PC.
http://clk.atdmt.com/MRT/go/115298556/direct/01/
Re: Summary of the submitted patch for TUSCANY-2629 (handling unknown contents) and TUSCANY-2624 (missing namespace declarations)
Posted by Luciano Resende <lu...@gmail.com>.
On Sat, Oct 25, 2008 at 1:19 AM, Dhaval Chauhan
<dh...@hotmail.com> 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/