ws-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andreas Veithen (Commented) (JIRA)" <>
Subject [jira] [Commented] (AXIOM-333) getFirstChildWithName should not read the next element.
Date Mon, 10 Oct 2011 19:12:30 GMT


Andreas Veithen commented on AXIOM-333:

OMChildrenIterator is part of axiom-api because it is code shared by different Axiom implementations
[1]. That means that it should not be considered part of the public API, but rather part of
the support classes for Axiom implementations. We maintain compatibility of the public API
between minor releases, but there may be changes required in the Axiom implementations, i.e
the SPI may slightly change.

Unfortunately, since axiom-api contains both the public API and classes shared by different
implementations, the distinction between these two got a bit blurred over time. This is something
that will be fixed in Axiom 1.3.

Anyway, since Abdera is an Axiom implementation that extends the default Axiom LLOM implementation
(axiom-impl) it is strongly coupled to Axiom's internals and upgrading the Abdera build to
a new Axiom version will always require some changes.

In my opinion, the real problem is that this issue also occurs at runtime. Actually, Abdera
should not have a dependency on axiom-impl at runtime, but instead include a (relocated) copy
of these classes (using the maven-shade-plugin). This is also the reason why currently Abdera
and Axiom don't play nicely together in an OSGi environment [2].

To summarize, the structural solution to the problem that Abdera in general breaks after upgrading
Axiom is to:
* ensure that there is a clear separation between the public Axiom API and implementation
classes, and move implementation classes out of axiom-api (so that axiom-api can be upgraded
* eliminate the runtime dependency on axiom-impl in Abdera (so that upgrading axiom-impl will
never be a problem).

Obviously, that is a long term solution. In the meantime, I can try to come up with a patch
that updates Abdera to Axiom 1.2.13-SNAPSHOT.

> getFirstChildWithName should not read the next element.
> -------------------------------------------------------
>                 Key: AXIOM-333
>                 URL:
>             Project: Axiom
>          Issue Type: Improvement
>          Components: DOOM, LLOM
>            Reporter: Jose Antonio
>            Assignee: Andreas Veithen
>            Priority: Minor
>             Fix For: 1.2.11
> When calling getFirstChildWithName operation over an element, it reads not only the first
element, but the next also. I think that could be improved since the operation name semantics
specifies that the caller is only interested in the first element and not the rest of them,
so a iterator (the reason to read the next element) is useless here. Suppose the following
> <root-element>
>   <chlid-element att="value">
>      <sub-child-element>
>           -- very big content --
>      </sub-child-element>
>   </child-element>
> </root-element>
> I want to read the sub-child-element only in some cases depending on the 'value' attribute.
If I call to getFirstElement I get the behaviour I want, since only the header is readed and
I can skip and discard the message if it doesn't match. I get the behaviour that I would expect
from a StaX parser and a getFirst* method, so I can discard the message quickly. Instead,
getFirstElementWithName seems to call internally to getElementsWithName and returns the first
occurence, which forces the parser to read the next element and (in this case) the complete
big message.
> I think that the efficiency of that method could be improved since, for a StaX model,
one expects that the parser only reads the minimal information needed to serve the request.
Instead of calling to getElementsWithName, it would be better an implementation based on getFirstElement
and then going through getNextOMSibling.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message