You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@abdera.apache.org by Adam Constabaris <ad...@clownsinmycoffee.net> on 2007/02/27 17:40:00 UTC
Controlling serialization w/extensions
I'm currently trying to track down the cause of some bad output from my
Provider's getFeed() method (building against trunk). I'm not sure
whether it's a bug yet. I've written an ExtensionFactory because my
entries contain some Dublin Core elements, but the namespace handling on
output isn't working correctly -- in some environments. When I run my
provider in a servlet container, only the first atom:entry element in
the output contains declarations for the DC namespace; subsequent
atom:entry elements lack the declarations. Tests mimicking the servlet
environment as closely as possible don't exhibit the same problem.
This symptom suggests that there's a bug in the serializer somewhere
("I've already output a declaration for those, so I don't need to do it
again"), but the successful unit tests don't fit with that diagnosis.
I've tried this against Axiom 1.2.1 and 1.2.2, since they addressed some
namespace issues there. I haven't seen anything (yet) that tells me
whether the container (Glassfish) is a factor here. Both environments
use the same JDK (1.6.0) and a default Abdera instance.
The hack I've adopted, for the time being, is to add extension elements
using all the namespaces that will appear in the entries to the feed
element; since I don't need those elements to appear, what I'd like to
do is just add the namespace declarations (and save a few bits on the
wire while I'm at it). So there's a concrete RFE, at least.
Stripping down to (what I believe are) the bare essentials, this is the
code:
MyProvider extends AbstractProvider {
...
public ResponseContext getFeed(RequestContext req) {
Factory factory =
req.getServiceContext().getAbdera().getNewFactory();
factory.registerExtension( new DCExtensionFactory() ); // Dublin
Core elements
Feed feed = factory.newFeed();
MyEntryFactory ef = new MyEntryFactory(factory);
feed.setTitle("My Feed With Extensions");
...
for( MyObject object : myObjects ) {
feed.addEntry( ef.getEntry(object) );
}
return new BaseResponseContext(feed);
}
public class MyEntryFactory {
public MyEntryFactory(Factory factory) {
this.factory = factory;
}
public Entry getEntry(MyObject object) {
Entry entry = factory.newEntry(); // I've also tried passing in
the parent feed here and using factory.newEntry(feed)
entry.setTitle(myObject.getName());
...
// DCTextElement -> ElementWrapper
DCTextElement publisher =
entry.addExtension(DCExtensionFactory.PUBLISHER);
publisher.setText(myObject.getOwner().getName());
...
return entry;
}
cheers,
AC
Re: Controlling serialization w/extensions
Posted by Adam Constabaris <ad...@clownsinmycoffee.net>.
Adam Constabaris wrote:
<snip>
> The hack I've adopted, for the time being, is to add extension
> elements using all the namespaces that will appear in the entries to
> the feed element; since I don't need those elements to appear, what
> I'd like to do is just add the namespace declarations (and save a few
> bits on the wire while I'm at it). So there's a concrete RFE, at least.
And only after posting does he discover Element.declareNS(). Cue Emily
Littella.
AC
> Stripping down to (what I believe are) the bare essentials, this is
> the code:
>
> MyProvider extends AbstractProvider {
> ...
> public ResponseContext getFeed(RequestContext req) {
> Factory factory =
> req.getServiceContext().getAbdera().getNewFactory();
> factory.registerExtension( new DCExtensionFactory() ); //
> Dublin Core elements
> Feed feed = factory.newFeed();
> MyEntryFactory ef = new MyEntryFactory(factory);
> feed.setTitle("My Feed With Extensions");
> ...
> for( MyObject object : myObjects ) {
> feed.addEntry( ef.getEntry(object) );
> }
> return new BaseResponseContext(feed);
> }
>
> public class MyEntryFactory {
> public MyEntryFactory(Factory factory) {
> this.factory = factory;
> }
>
> public Entry getEntry(MyObject object) {
> Entry entry = factory.newEntry(); // I've also tried passing in
> the parent feed here and using factory.newEntry(feed)
> entry.setTitle(myObject.getName());
> ...
>
> // DCTextElement -> ElementWrapper
> DCTextElement publisher =
> entry.addExtension(DCExtensionFactory.PUBLISHER);
> publisher.setText(myObject.getOwner().getName());
> ...
> return entry;
> }
>
> cheers,
>
> AC
>
Re: Controlling serialization w/extensions
Posted by Adam Constabaris <ad...@clownsinmycoffee.net>.
James M Snell wrote:
> Without a concrete test case, it would be difficult for me to say with
> certainty that it is the stax impl. However, there is a huge amount of
> inconsistency between stax implementations right now due largely to
> massive holes in the Stax specification. It would not surprise me in the
> least if this was a Stax impl bug.
>
I 've posted a minimal program that illustrates the problem (nothing to
do with Abdera classes) on the AXIOM issue:
https://issues.apache.org/jira/browse/WSCOMMONS-175
AC
> - James
>
> Adam Constabaris wrote:
>
>> James M Snell wrote:
>>
>> <snip>
>>
>>>> This symptom suggests that there's a bug in the serializer somewhere
>>>> ("I've already output a declaration for those, so I don't need to do it
>>>> again"), but the successful unit tests don't fit with that diagnosis.
>>>>
>>>>
>>> Which Stax parser are you using, btw?
>>>
>>>
>> Don't know why I didn't think of looking there; server was using StAX
>> from JDK 1.6.0 and the unit tests were using Woodstox. I since verified
>> trying both parsers w/AXIOM offline, and the StAX implementation appears
>> to be the key difference.
>>
>> I've filed this with AXIOM
>> (https://issues.apache.org/jira/browse/WSCOMMONS-175) (it may or may not
>> be "their fault" -- I don't have time to dig into the StAX
>> implementations -- but they may want to implement a fix). Either way, I
>> suppose the issue is relevant for anybody deploying Abdera w/1.6.0 --
>> watch your StAX implementation, or make sure to add all your
>> declarations to the root element.
>>
>> cheers,
>>
>> AC
>>
>>
>>
Re: Controlling serialization w/extensions
Posted by James M Snell <ja...@gmail.com>.
Without a concrete test case, it would be difficult for me to say with
certainty that it is the stax impl. However, there is a huge amount of
inconsistency between stax implementations right now due largely to
massive holes in the Stax specification. It would not surprise me in the
least if this was a Stax impl bug.
- James
Adam Constabaris wrote:
> James M Snell wrote:
>
> <snip>
>>> This symptom suggests that there's a bug in the serializer somewhere
>>> ("I've already output a declaration for those, so I don't need to do it
>>> again"), but the successful unit tests don't fit with that diagnosis.
>>>
>>
>> Which Stax parser are you using, btw?
>>
> Don't know why I didn't think of looking there; server was using StAX
> from JDK 1.6.0 and the unit tests were using Woodstox. I since verified
> trying both parsers w/AXIOM offline, and the StAX implementation appears
> to be the key difference.
>
> I've filed this with AXIOM
> (https://issues.apache.org/jira/browse/WSCOMMONS-175) (it may or may not
> be "their fault" -- I don't have time to dig into the StAX
> implementations -- but they may want to implement a fix). Either way, I
> suppose the issue is relevant for anybody deploying Abdera w/1.6.0 --
> watch your StAX implementation, or make sure to add all your
> declarations to the root element.
>
> cheers,
>
> AC
>
>
Re: Controlling serialization w/extensions
Posted by Adam Constabaris <ad...@clownsinmycoffee.net>.
James M Snell wrote:
<snip>
>> This symptom suggests that there's a bug in the serializer somewhere
>> ("I've already output a declaration for those, so I don't need to do it
>> again"), but the successful unit tests don't fit with that diagnosis.
>>
>
> Which Stax parser are you using, btw?
>
Don't know why I didn't think of looking there; server was using StAX
from JDK 1.6.0 and the unit tests were using Woodstox. I since verified
trying both parsers w/AXIOM offline, and the StAX implementation appears
to be the key difference.
I've filed this with AXIOM
(https://issues.apache.org/jira/browse/WSCOMMONS-175) (it may or may not
be "their fault" -- I don't have time to dig into the StAX
implementations -- but they may want to implement a fix). Either way, I
suppose the issue is relevant for anybody deploying Abdera w/1.6.0 --
watch your StAX implementation, or make sure to add all your
declarations to the root element.
cheers,
AC
Re: Controlling serialization w/extensions
Posted by James M Snell <ja...@gmail.com>.
Adam Constabaris wrote:
> I'm currently trying to track down the cause of some bad output from my
> Provider's getFeed() method (building against trunk). I'm not sure
> whether it's a bug yet. I've written an ExtensionFactory because my
> entries contain some Dublin Core elements, but the namespace handling on
> output isn't working correctly -- in some environments. When I run my
> provider in a servlet container, only the first atom:entry element in
> the output contains declarations for the DC namespace; subsequent
> atom:entry elements lack the declarations. Tests mimicking the servlet
> environment as closely as possible don't exhibit the same problem.
>
Hmm... I'm not able to actually duplicate this at all. Is there any
chance you could put together a complete test case (code) that recreates
the problem every time and put it into Jira?
> This symptom suggests that there's a bug in the serializer somewhere
> ("I've already output a declaration for those, so I don't need to do it
> again"), but the successful unit tests don't fit with that diagnosis.
Which Stax parser are you using, btw?
- James