You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commons-dev@ws.apache.org by Senaka Fernando <se...@apache.org> on 2009/08/10 20:23:12 UTC

What's the purpose of returning OMXMLStreamReaderValidator in OMElementImpl

Hi all,

Why do we return OMXMLStreamReaderValidator inside OMElementImpl when
log4j's DEBUG level is enabled and OMStAXWrapper if not? It also happens to
be that OMXMLStreamReaderValidator is not a OMStAXWrapper which makes some
code that work when log4j's DEBUG level is disabled not to work when log4j's
DEBUG level enabled.

Thanks,
Senaka

Re: What's the purpose of returning OMXMLStreamReaderValidator in OMElementImpl

Posted by Senaka Fernando <se...@apache.org>.
Hi Andreas,

Just read through the API docs. Sounds great.

Thanks,
Senaka.

On Sun, Aug 16, 2009 at 5:15 AM, Andreas Veithen
<an...@gmail.com>wrote:

> Hi Senaka,
>
> I updated the documentation of getXMLStreamReader to make it clear
> what are the assumptions that the caller can make about the returned
> reader and I added a link from OMXMLStreamReaderValidator to that
> documentation. See [1].
>
> Andreas
>
> [1] http://people.apache.org/~veithen/axiom/apidocs/<http://people.apache.org/%7Eveithen/axiom/apidocs/>
>
> On Tue, Aug 11, 2009 at 03:42, Senaka Fernando<se...@wso2.com> wrote:
> > Hi Andreas,
> >
> > Yes, this is what made me more inquisitive about whether it was Axiom or
> > Axis2 that needed some fixing. I was unaware that this was fixed a few
> weeks
> > ago. Many thanks.
> >
> > Also, don't you think that it would be better if we could document what
> this
> > class does, or when we return an object of this type (I prefer this
> option),
> > at API level that such would be created/returned if log4j DEBUG is
> enabled?
> > So, that someone running into a similar issue in the future would perhaps
> > understand what caused this. There could at least be some instances where
> > people use older versions of Axis2 with newer versions of Axiom. WDYT?
> >
> > Thanks,
> > Senaka
> >
> > On Tue, Aug 11, 2009 at 12:15 AM, Andreas Veithen <
> andreas.veithen@gmail.com
> >> wrote:
> >
> >> Senaka,
> >>
> >> The purpose of OMXMLStreamReaderValidator is to validate that the
> >> sequence of events produced by OMStAXWrapper is correct. Note that
> >> code using OMElement#getXMLStreamReader should not make any
> >> assumptions about the implementation class returned by that method.
> >> There is actually no valid reason (at least with the recent XOP/MTOM
> >> fixes in Axiom) to cast the returned reader into an OMStAXWrapper.
> >> AXIS2-4363 gives some more insight into this question.
> >>
> >> Andreas
> >>
> >> On Mon, Aug 10, 2009 at 20:23, Senaka Fernando<se...@apache.org>
> wrote:
> >> > Hi all,
> >> >
> >> > Why do we return OMXMLStreamReaderValidator inside OMElementImpl when
> >> > log4j's DEBUG level is enabled and OMStAXWrapper if not? It also
> happens
> >> to
> >> > be that OMXMLStreamReaderValidator is not a OMStAXWrapper which makes
> >> some
> >> > code that work when log4j's DEBUG level is disabled not to work when
> >> log4j's
> >> > DEBUG level enabled.
> >> >
> >> > Thanks,
> >> > Senaka
> >> >
> >>
> >
>

Re: What's the purpose of returning OMXMLStreamReaderValidator in OMElementImpl

Posted by Andreas Veithen <an...@gmail.com>.
Hi Senaka,

I updated the documentation of getXMLStreamReader to make it clear
what are the assumptions that the caller can make about the returned
reader and I added a link from OMXMLStreamReaderValidator to that
documentation. See [1].

Andreas

[1] http://people.apache.org/~veithen/axiom/apidocs/

On Tue, Aug 11, 2009 at 03:42, Senaka Fernando<se...@wso2.com> wrote:
> Hi Andreas,
>
> Yes, this is what made me more inquisitive about whether it was Axiom or
> Axis2 that needed some fixing. I was unaware that this was fixed a few weeks
> ago. Many thanks.
>
> Also, don't you think that it would be better if we could document what this
> class does, or when we return an object of this type (I prefer this option),
> at API level that such would be created/returned if log4j DEBUG is enabled?
> So, that someone running into a similar issue in the future would perhaps
> understand what caused this. There could at least be some instances where
> people use older versions of Axis2 with newer versions of Axiom. WDYT?
>
> Thanks,
> Senaka
>
> On Tue, Aug 11, 2009 at 12:15 AM, Andreas Veithen <andreas.veithen@gmail.com
>> wrote:
>
>> Senaka,
>>
>> The purpose of OMXMLStreamReaderValidator is to validate that the
>> sequence of events produced by OMStAXWrapper is correct. Note that
>> code using OMElement#getXMLStreamReader should not make any
>> assumptions about the implementation class returned by that method.
>> There is actually no valid reason (at least with the recent XOP/MTOM
>> fixes in Axiom) to cast the returned reader into an OMStAXWrapper.
>> AXIS2-4363 gives some more insight into this question.
>>
>> Andreas
>>
>> On Mon, Aug 10, 2009 at 20:23, Senaka Fernando<se...@apache.org> wrote:
>> > Hi all,
>> >
>> > Why do we return OMXMLStreamReaderValidator inside OMElementImpl when
>> > log4j's DEBUG level is enabled and OMStAXWrapper if not? It also happens
>> to
>> > be that OMXMLStreamReaderValidator is not a OMStAXWrapper which makes
>> some
>> > code that work when log4j's DEBUG level is disabled not to work when
>> log4j's
>> > DEBUG level enabled.
>> >
>> > Thanks,
>> > Senaka
>> >
>>
>

Re: What's the purpose of returning OMXMLStreamReaderValidator in OMElementImpl

Posted by Senaka Fernando <se...@wso2.com>.
Hi Andreas,

Yes, this is what made me more inquisitive about whether it was Axiom or
Axis2 that needed some fixing. I was unaware that this was fixed a few weeks
ago. Many thanks.

Also, don't you think that it would be better if we could document what this
class does, or when we return an object of this type (I prefer this option),
at API level that such would be created/returned if log4j DEBUG is enabled?
So, that someone running into a similar issue in the future would perhaps
understand what caused this. There could at least be some instances where
people use older versions of Axis2 with newer versions of Axiom. WDYT?

Thanks,
Senaka

On Tue, Aug 11, 2009 at 12:15 AM, Andreas Veithen <andreas.veithen@gmail.com
> wrote:

> Senaka,
>
> The purpose of OMXMLStreamReaderValidator is to validate that the
> sequence of events produced by OMStAXWrapper is correct. Note that
> code using OMElement#getXMLStreamReader should not make any
> assumptions about the implementation class returned by that method.
> There is actually no valid reason (at least with the recent XOP/MTOM
> fixes in Axiom) to cast the returned reader into an OMStAXWrapper.
> AXIS2-4363 gives some more insight into this question.
>
> Andreas
>
> On Mon, Aug 10, 2009 at 20:23, Senaka Fernando<se...@apache.org> wrote:
> > Hi all,
> >
> > Why do we return OMXMLStreamReaderValidator inside OMElementImpl when
> > log4j's DEBUG level is enabled and OMStAXWrapper if not? It also happens
> to
> > be that OMXMLStreamReaderValidator is not a OMStAXWrapper which makes
> some
> > code that work when log4j's DEBUG level is disabled not to work when
> log4j's
> > DEBUG level enabled.
> >
> > Thanks,
> > Senaka
> >
>

Re: What's the purpose of returning OMXMLStreamReaderValidator in OMElementImpl

Posted by Andreas Veithen <an...@gmail.com>.
Senaka,

The purpose of OMXMLStreamReaderValidator is to validate that the
sequence of events produced by OMStAXWrapper is correct. Note that
code using OMElement#getXMLStreamReader should not make any
assumptions about the implementation class returned by that method.
There is actually no valid reason (at least with the recent XOP/MTOM
fixes in Axiom) to cast the returned reader into an OMStAXWrapper.
AXIS2-4363 gives some more insight into this question.

Andreas

On Mon, Aug 10, 2009 at 20:23, Senaka Fernando<se...@apache.org> wrote:
> Hi all,
>
> Why do we return OMXMLStreamReaderValidator inside OMElementImpl when
> log4j's DEBUG level is enabled and OMStAXWrapper if not? It also happens to
> be that OMXMLStreamReaderValidator is not a OMStAXWrapper which makes some
> code that work when log4j's DEBUG level is disabled not to work when log4j's
> DEBUG level enabled.
>
> Thanks,
> Senaka
>