Mailing-List: contact abdera-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: abdera-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of jasnell@gmail.com designates
 64.233.166.180 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding;
        b=DXE+SaDmqpz/QjbBjdIWbCoY9WNaMnq0WAn8W/8y6LKron4n2fs6SB/YjbeQU2ngHD4R+Jj725J4Yx0NahhLZzd/32kluJm0wQ+1K15aedPn2uqHuV625d5jabshM0uiA9lX0LPwSAEpIJ8ZBfWooRx2Oi2SAarCh/hhmw8JD7k=
Message-ID: <4804E0C8.1060507@gmail.com>
Date: Tue, 15 Apr 2008 10:07:20 -0700
From: James M Snell <jasnell@gmail.com>
User-Agent: Thunderbird 2.0.0.12 (X11/20080227)
MIME-Version: 1.0
To: abdera-dev@incubator.apache.org
Subject: Re: Concerning ATOM feeds with xhtml content
References: <48037DD9.5070609@konsolenopfer.de> <4803860B.3080903@gmail.com>
 <48039758.1010500@konsolenopfer.de> <48039B56.8070704@gmail.com>
 <4803D9BC.8010807@konsolenopfer.de>
In-Reply-To: <4803D9BC.8010807@konsolenopfer.de>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit

Entirely possible.  If you would, can you please open a jira issue to 
track this and I'll look into it further a bit later this week.

- James

Christoph Bauer wrote:
> Hi,
> 
> ok. i tried it with a jdk 1.5 and it seems to work. I still think there 
> is something fundamental wrong with the 
> <org.apache.abdera.parser.stax.FOMDiv>.getInternalValue() method though.
> 
> Consider this test:
> public static void main(String[] args) throws Exception {
>     
>     ByteArrayOutputStream out = new ByteArrayOutputStream();
>     XMLOutputFactory factory = XMLOutputFactory.newInstance();
>     XMLStreamWriter writer = factory.createXMLStreamWriter(out);
>     writer.writeStartElement("");
>     
>     // simulate <OMNode>.serialize(writer):
>     writer.writeStartElement("a");
>     writer.writeEndElement();
>     writer.flush(); // !
>     
>     writer.writeEndElement();
> 
>     System.out.println("BEFORE:");
>     System.out.println(out.toString());
> 
>     // i think you should:
>     writer.flush();
>     
>     System.out.println("AFTER:");
>     System.out.println(out.toString());
> }
> 
> on my computer it outputs:
> BEFORE:
> <><a />
> AFTER:
> <><a /></>
> 
> Axiom's <OMNode>.serialize() calls flush() after writing.
> 
> The Abdera code does not.
> 
> Using the content of an ByteArrayOutputStream in this way is in my eyes 
> unpredictable without calling flush on the writer.
> 
> The other thing is that calling substring(2) is really silly.
> 
> Why generate an entity that you take away afterwards?
> 
> Especially after i found out that OMNode can be serialized to an 
> OutputStream.
> 
> So the following might work (untested):
>   protected String getInternalValue() {
>     try {
>       ByteArrayOutputStream out = new ByteArrayOutputStream();
> //      XMLStreamWriter writer =
> //        XMLOutputFactory.newInstance().createXMLStreamWriter(out);
> //      writer.writeStartElement("");
>       for (Iterator nodes = this.getChildren(); nodes.hasNext();) {
>         OMNode node = (OMNode) nodes.next();
> //        node.serialize(writer);
>         node.serialize(out);
>       }
> //      writer.writeEndElement();
> //      return out.toString().substring(2);
>       return out.toString();
>     } catch (Exception e) {}
>     return "";
>   }
> 
> g
> 
> Christoph
> 
> James M Snell wrote:
>> The stax implementation has a lot to do with it.  Based on the 
>> classpath, it would appear that you're using the stax impl that ships 
>> with JDK 1.6?  If so, please note that Abdera has not been tested on 
>> 1.6.  I've tried both the IBM and Sun 1.5 JDK's and have not been able 
>> to duplicate your results.
>>
>> - James
>>
>> Christoph Bauer wrote:
>>> Hi,
>>>
>>> thanks for the immediate response.
>>>
>>>
>>> I was testing inside Eclipse Europe with a sun jdk.1.6.0_03 64bit 
>>> Java (linux-64)
>>>
>>> The testing routine contained only the main method.
>>>
>>> following libs in classpath
>>> abdera.0.3.0-incubating/abdera.client.0.3.0-incubating.jar
>>> abdera.0.3.0-incubating/abdera.core.0.3.0-incubating.jar
>>> abdera.0.3.0-incubating/abdera.parser.0.3.0-incubating.jar
>>> abdera.0.3.0-incubating/abdera.protocol.0.3.0-incubating.jar
>>> abdera.0.3.0-incubating/lib/axiom-api-1.2.5.jar
>>> abdera.0.3.0-incubating/lib/axiom-impl-1.2.5.jar
>>> abdera.0.3.0-incubating/lib/commons-codec-1.3.jar
>>> abdera.0.3.0-incubating/lib/commons-httpclient-3.1-rc1.jar
>>> abdera.0.3.0-incubating/lib/commons-logging-1.0.4.jar
>>> abdera.0.3.0-incubating/lib/jaxen-1.1.1.jar
>>> abdera.0.3.0-incubating/lib/abdera-i18n-0.3.0-incubating.jar
>>> abdera.0.3.0-incubating/lib/stax-api-1.0.1.jar
>>>
>>> also tried the retro libs with a 32bit 1.4 jdk (same result)
>>>
>>>
>>> Initially i found the problem with a self-generate feed so i tried 
>>> others and found the same problem.
>>>
>>> Concerning stax: see classpath, but looking at the code i don't see 
>>> how that should matter when abdera generates
>>>
>>> <>
>>> <h3>Header</h3>
>>> <p>some text here</p>
>>> </>
>>>
>>> and then goes ahead and throws the first two characters away.
>>>
>>>
>>>
>>>
>>> James M Snell schrieb:
>>>> I am unable to duplicate the issue.  What stax implementation are 
>>>> you using? What platform?  Does this happen with every entry or just 
>>>> one specific entry?  Are you seeing this problem with more than one 
>>>> feed or several?
>>>>
>>>> - James
>>>>
>>>> Christoph Bauer wrote:
>>>>> Hi Everyone,
>>>>>
>>>>> i haven't found a bug report for this so i thought i ask here
>>>>>
>>>>> please considered the following snippet:
>>>>>
>>>>> public static void main(String[] args) {
>>>>>     Abdera abdera = new Abdera();
>>>>>     AbderaClient client = new AbderaClient(abdera);
>>>>>     ClientResponse resp = 
>>>>> client.get("http://mail-archives.apache.org/mod_mbox/incubator-abdera-dev/?format=atom"); 
>>>>>
>>>>>     if (resp.getType() == ResponseType.SUCCESS) {
>>>>>       Document<Feed> doc = resp.getDocument();
>>>>>      
>>>>> System.out.println(doc.getRoot().getEntries().iterator().next().getContent()); 
>>>>>
>>>>>     } else {
>>>>>     }
>>>>> }
>>>>>
>>>>>
>>>>> Right at the end of the content i get an empty </> xml tag.
>>>>> Something like this:
>>>>>
>>>>> <pre>My content</pre> </>
>>>>>
>>>>>
>>>>>
>>>>> I dived through the code and found the 
>>>>> <org.apache.abdera.parser.stax.FOMDiv>.getInternalValue() Class 
>>>>> which I think is supposed to handle this:
>>>>>
>>>>>   protected String getInternalValue() {
>>>>>     try {
>>>>>       ByteArrayOutputStream out = new ByteArrayOutputStream();
>>>>>       XMLStreamWriter writer =
>>>>>         XMLOutputFactory.newInstance().createXMLStreamWriter(out);
>>>>>       writer.writeStartElement("");
>>>>>       for (Iterator nodes = this.getChildren(); nodes.hasNext();) {
>>>>>         OMNode node = (OMNode) nodes.next();
>>>>>         node.serialize(writer);
>>>>>       }
>>>>>       writer.writeEndElement();
>>>>>       return out.toString().substring(2);
>>>>>     } catch (Exception e) {}
>>>>>     return "";
>>>>>   }
>>>>>
>>>>> If I understand that right abdera is trying to remove the 
>>>>> surrounding "div" tag. Unfortunately the output from this method 
>>>>> cannot be used if you need valid xhtml or at least valid xml 
>>>>> because of the empty element tag.
>>>>>
>>>>> I shudder when i see
>>>>> out.toString().substring(2);
>>>>>
>>>>> For now i decided to stick with abdera, but handle the xhtml myself:
>>>>>
>>>>> Element  c = 
>>>>> doc.getRoot().getEntries().iterator().next().getContentElement().getFirstChild(); 
>>>>>
>>>>> try {
>>>>>   StringWriter out = new StringWriter();
>>>>>   Element e = c.getFirstChild();
>>>>>   while (e != null) {
>>>>>       e.writeTo(out);
>>>>>       e = e.getNextSibling();
>>>>>   }
>>>>>   System.out.println(out.toString());
>>>>> } catch (IOException e1) {
>>>>>     // TODO Auto-generated catch block
>>>>>     e1.printStackTrace();
>>>>> }
>>>>>
>>>>>
>>>>> Would be nice to know whether this is some kind of bug, or whether 
>>>>> i got something wrong.
>>>>>
>>>>> g
>>>>> christoph bauer
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
> 
> 
>