Fantastic. The process is mainly formalities of verifying the IP of the code to be donated, see http://incubator.apache.org/ip-clearance/ip-clearance-template.html. If you're happy to sign those legal forms then the actual process would be wait for a few days to see if others have comments on this thread, then hold a formal vote here to accept the code and making the activitystreams people Abdera committers, then we'd submitted the paper work, wait a few more days, then import the code and make you all committers. Does that sounds ok? I expect the main reason anyone here might object would be if it was to just be a code dump with no intention of staying to helping maintain the code in the future - thats not the case is it? You guys would like to help support and maintain it and perhaps even get more involved in Abdera? ...ant On Wed, Nov 18, 2009 at 1:03 PM, Darren Bounds <darren@cliqset.com> wrote: > Absolutely. In fact that was our intention. > > How do we go about it? > > -- > darren bounds > darren@cliqset.com > > On Nov 18, 2009 3:07 AM, "ant elder" <ant.elder@gmail.com> wrote: > > On Tue, Nov 17, 2009 at 3:15 AM, Darren Bounds <darren@cliqset.com> wrote: > > Hey everyone, > > We've... > Looks good. Would you consider donating that code here and joining the > Apache Abdera project? > > ...ant >
Absolutely. In fact that was our intention. How do we go about it? -- darren bounds darren@cliqset.com On Nov 18, 2009 3:07 AM, "ant elder" <ant.elder@gmail.com> wrote: On Tue, Nov 17, 2009 at 3:15 AM, Darren Bounds <darren@cliqset.com> wrote: > Hey everyone, > > We've... Looks good. Would you consider donating that code here and joining the Apache Abdera project? ...ant
Good to hear James. ...ant On Tue, Nov 17, 2009 at 7:19 PM, James M Snell <jasnell@gmail.com> wrote: > Hello All, > > Just a general FYI... A recent job change at IBM pulled me away from all > things Atom to focus on security technologies. I'd been hoping that the > community would pick things up and move forward but unfortunately there just > doesn't seem to be much going on. In order to help get things jump started > again, I plan on re-engaging with Abdera in the weeks following the > thanksgiving holiday. > > - James > >
On Tue, Nov 17, 2009 at 3:15 AM, Darren Bounds <darren@cliqset.com> wrote: > Hey everyone, > > We've published the initial release of our Activity Streams > (http://activitystrea.ms/) Abdera extension to Google Code. This > library is a generic version of the library we use internally here at > Cliqset. We hope it will be useful to others who're interested in > consuming and producing Activity Streams compliant Atom feeds. > > The project can be found here: http://code.google.com/p/abdera-activitystreams > > Please let me know if you have any questions. > > -- > darren bounds > darren@cliqset.com > Looks good. Would you consider donating that code here and joining the Apache Abdera project? ...ant
Hi Darren, thank you, that will definitely be helpful. We plan to incorporate activity streams in our products in future releases and this will make our job a bit easier. regards, Lars On Tue, Nov 17, 2009 at 4:15 AM, Darren Bounds <darren@cliqset.com> wrote: > Hey everyone, > > We've published the initial release of our Activity Streams > (http://activitystrea.ms/) Abdera extension to Google Code. This > library is a generic version of the library we use internally here at > Cliqset. We hope it will be useful to others who're interested in > consuming and producing Activity Streams compliant Atom feeds. > > The project can be found here: http://code.google.com/p/abdera-activitystreams > > Please let me know if you have any questions. > > -- > darren bounds > darren@cliqset.com >
On Nov 13, 2009, at 5:25 AM, Udomsak Donkhampai wrote: > I try to reader Atom and I found error when in Atom has '&' in the > link > > > > Example: <link href="http://news.google.com/news?ned=us&topic=h&output=atom > " rel="self" ></link> The '&' character cannot be used non-escaped in an XML document and an Atom feed is an XML document. Actually, the feed that can be found at that URL has all occurrences of '&' correctly escaped as '&' as it should be. Ugo -- Ugo Cei Sourcesense - making sense of Open Source: http://www.sourcesense.com
Wonderful; thanks James! I recently joined to ask about 1.0, the new stuff in trunk etc. Got a bit spooked by the talk about apache attic.. So great so see you back! As previously mentioned, Abdera has a large user base and deserve a 1.0 status. (I know though that it's really up to the community to pitch in of course. I haven't so much time I'm afraid, but I'd be glad to test, report and provide assistance as much as I can.) Best regards, Niklas On Tue, Nov 17, 2009 at 8:19 PM, James M Snell <jasnell@gmail.com> wrote: > Hello All, > > Just a general FYI... A recent job change at IBM pulled me away from all > things Atom to focus on security technologies. I'd been hoping that the > community would pick things up and move forward but unfortunately there just > doesn't seem to be much going on. In order to help get things jump started > again, I plan on re-engaging with Abdera in the weeks following the > thanksgiving holiday. > > - James > >
On Tue, Nov 17, 2009 at 11:19 AM, James M Snell <jasnell@gmail.com> wrote: > Hello All, > > Just a general FYI... A recent job change at IBM pulled me away from all > things Atom to focus on security technologies. I'd been hoping that the > community would pick things up and move forward but unfortunately there just > doesn't seem to be much going on. In order to help get things jump started > again, I plan on re-engaging with Abdera in the weeks following the > thanksgiving holiday. > > - James > > Very good news, welcome back ! -- Luciano Resende http://people.apache.org/~lresende http://lresende.blogspot.com/
Hello All, Just a general FYI... A recent job change at IBM pulled me away from all things Atom to focus on security technologies. I'd been hoping that the community would pick things up and move forward but unfortunately there just doesn't seem to be much going on. In order to help get things jump started again, I plan on re-engaging with Abdera in the weeks following the thanksgiving holiday. - James
Hey everyone, We've published the initial release of our Activity Streams (http://activitystrea.ms/) Abdera extension to Google Code. This library is a generic version of the library we use internally here at Cliqset. We hope it will be useful to others who're interested in consuming and producing Activity Streams compliant Atom feeds. The project can be found here: http://code.google.com/p/abdera-activitystreams Please let me know if you have any questions. -- darren bounds darren@cliqset.com
On Thu, Nov 12, 2009 at 11:25 PM, Udomsak Donkhampai <UDonkhampai@vizrt.com> wrote: > I try to reader Atom and I found error when in Atom has '&' in the link Atom documents must be well-formed XML, so the '&' must be encoded as '&'. Jim > > > > Example: <link href="http://news.google.com/news?ned=us&topic=h&output=atom" rel="self" ></link> > > This error: com.ctc.wstx.exc.WstxUnexpectedCharException: Unexpected character '=' (code 61); expected a semi-colon after the reference for entity 'topic' > > > > And I read in http://www.ietf.org/rfc/rfc4287.txt > > > > 4.2.7.1. The "href" Attribute > > > > The "href" attribute contains the link's IRI. atom:link elements MUST > > have an href attribute, whose value MUST be a IRI reference > > [RFC3987]. > > > > And IRI (http://www.ietf.org/rfc/rfc3987.txt) > > > IRI = scheme ":" ihier-part [ "?" iquery ] > [ "#" ifragment ] > > > > IRI allow to have '&' after '?' iquery > > > > > > Do you have any idea for this problem? > > > > > > Thank. > > > > Aom > > > > > > >
I try to reader Atom and I found error when in Atom has '&' in the link
Example: <link href="http://news.google.com/news?ned=us&topic=h&output=atom" rel="self"
></link>
This error: com.ctc.wstx.exc.WstxUnexpectedCharException: Unexpected character '=' (code 61);
expected a semi-colon after the reference for entity 'topic'
And I read in http://www.ietf.org/rfc/rfc4287.txt
4.2.7.1. The "href" Attribute
The "href" attribute contains the link's IRI. atom:link elements MUST
have an href attribute, whose value MUST be a IRI reference
[RFC3987].
And IRI (http://www.ietf.org/rfc/rfc3987.txt)
IRI = scheme ":" ihier-part [ "?" iquery ]
[ "#" ifragment ]
IRI allow to have '&' after '?' iquery
Do you have any idea for this problem?
Thank.
Aom
[ https://issues.apache.org/jira/browse/ABDERA-251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robin Fernandes updated ABDERA-251:
-----------------------------------
Description:
In org.apache.abdera.parser.stax.FOMDiv.getInternalValue(), the content of the div is obtained
as a byte array using an XMLStreamWriter.
The content of the byte array is then converted to String using the default platform encoding
(using ByteArrayOutputStream.toString()), which may not be compatible with the encoding used
by the XMLStreamWriter.
A scenario in which this is problematic is if the XMLStreamWriter uses UTF8 (which is the
default behaviour), but FOMDiv.getInternalValue() is invoked on z/OS where the platform encoding
is a flavour of EBCDIC. In this situation, the method returns garbage.
Here's a suggested patch which ensures the XMLStreamWriter writes directly to a StringWriter,
so no 'bytes to String' conversion is required in FOMDiv, and therefore no transcoding issues
arise. The patch also remove seemingly unnecessary calls to XMLStreamWriter.writeStartElement()
and XMLStreamWriter.writeEndElement().
Index: parser/src/main/java/org/apache/abdera/parser/stax/FOMDiv.java
===================================================================
--- parser/src/main/java/org/apache/abdera/parser/stax/FOMDiv.java (revision 834082)
+++ parser/src/main/java/org/apache/abdera/parser/stax/FOMDiv.java (working copy)
@@ -17,7 +17,7 @@
*/
package org.apache.abdera.parser.stax;
-import java.io.ByteArrayOutputStream;
+import java.io.StringWriter;
import java.util.Iterator;
import javax.xml.namespace.QName;
@@ -143,16 +143,14 @@
protected String getInternalValue() {
try {
- ByteArrayOutputStream out = new ByteArrayOutputStream();
+ StringWriter out = new StringWriter();
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);
+ return out.getBuffer().toString();
} catch (Exception e) {}
return "";
}
was:
In org.apache.abdera.parser.stax.FOMDiv.getInternalValue(), the content of the div is obtained
as a byte array using an XMLStreamWriter.
The content of the byte array is then converted to String using the default platform encoding
(using ByteArrayOutputStream.toString()), which may not be compatible with the encoding used
by the XMLStreamWriter.
A scenario in which this is problematic is if the XMLStreamWriter uses UTF8 (which is the
default behaviour), but FOMDiv.getInternalValue() is invoked on z/OS where the platform encoding
is a flavour EBCDIC. In this situation, the method returns garbage.
Here's a suggested patch which ensures the XMLStreamWriter writes directly to a StringWriter,
so no 'bytes to String' conversion is required in FOMDiv, and therefore no transcoding issues
arise. The patch also remove seemingly unnecessary calls to XMLStreamWriter.writeStartElement()
and XMLStreamWriter.writeEndElement().
Index: parser/src/main/java/org/apache/abdera/parser/stax/FOMDiv.java
===================================================================
--- parser/src/main/java/org/apache/abdera/parser/stax/FOMDiv.java (revision 834082)
+++ parser/src/main/java/org/apache/abdera/parser/stax/FOMDiv.java (working copy)
@@ -17,7 +17,7 @@
*/
package org.apache.abdera.parser.stax;
-import java.io.ByteArrayOutputStream;
+import java.io.StringWriter;
import java.util.Iterator;
import javax.xml.namespace.QName;
@@ -143,16 +143,14 @@
protected String getInternalValue() {
try {
- ByteArrayOutputStream out = new ByteArrayOutputStream();
+ StringWriter out = new StringWriter();
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);
+ return out.getBuffer().toString();
} catch (Exception e) {}
return "";
}
> Charset issue in FOMDiv.getInternalValue() leads to corrupt return value on non-ASCII
platforms
> -----------------------------------------------------------------------------------------------
>
> Key: ABDERA-251
> URL: https://issues.apache.org/jira/browse/ABDERA-251
> Project: Abdera
> Issue Type: Bug
> Affects Versions: 0.4.0, 1.0
> Environment: z/OS
> Reporter: Robin Fernandes
>
> In org.apache.abdera.parser.stax.FOMDiv.getInternalValue(), the content of the div is
obtained as a byte array using an XMLStreamWriter.
> The content of the byte array is then converted to String using the default platform
encoding (using ByteArrayOutputStream.toString()), which may not be compatible with the encoding
used by the XMLStreamWriter.
> A scenario in which this is problematic is if the XMLStreamWriter uses UTF8 (which is
the default behaviour), but FOMDiv.getInternalValue() is invoked on z/OS where the platform
encoding is a flavour of EBCDIC. In this situation, the method returns garbage.
> Here's a suggested patch which ensures the XMLStreamWriter writes directly to a StringWriter,
so no 'bytes to String' conversion is required in FOMDiv, and therefore no transcoding issues
arise. The patch also remove seemingly unnecessary calls to XMLStreamWriter.writeStartElement()
and XMLStreamWriter.writeEndElement().
> Index: parser/src/main/java/org/apache/abdera/parser/stax/FOMDiv.java
> ===================================================================
> --- parser/src/main/java/org/apache/abdera/parser/stax/FOMDiv.java (revision 834082)
> +++ parser/src/main/java/org/apache/abdera/parser/stax/FOMDiv.java (working copy)
> @@ -17,7 +17,7 @@
> */
> package org.apache.abdera.parser.stax;
>
> -import java.io.ByteArrayOutputStream;
> +import java.io.StringWriter;
> import java.util.Iterator;
>
> import javax.xml.namespace.QName;
> @@ -143,16 +143,14 @@
>
> protected String getInternalValue() {
> try {
> - ByteArrayOutputStream out = new ByteArrayOutputStream();
> + StringWriter out = new StringWriter();
> 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);
> + return out.getBuffer().toString();
> } catch (Exception e) {}
> return "";
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Charset issue in FOMDiv.getInternalValue() leads to corrupt return value on non-ASCII platforms
-----------------------------------------------------------------------------------------------
Key: ABDERA-251
URL: https://issues.apache.org/jira/browse/ABDERA-251
Project: Abdera
Issue Type: Bug
Affects Versions: 0.4.0, 1.0
Environment: z/OS
Reporter: Robin Fernandes
In org.apache.abdera.parser.stax.FOMDiv.getInternalValue(), the content of the div is obtained
as a byte array using an XMLStreamWriter.
The content of the byte array is then converted to String using the default platform encoding
(using ByteArrayOutputStream.toString()), which may not be compatible with the encoding used
by the XMLStreamWriter.
A scenario in which this is problematic is if the XMLStreamWriter uses UTF8 (which is the
default behaviour), but FOMDiv.getInternalValue() is invoked on z/OS where the platform encoding
is a flavour EBCDIC. In this situation, the method returns garbage.
Here's a suggested patch which ensures the XMLStreamWriter writes directly to a StringWriter,
so no 'bytes to String' conversion is required in FOMDiv, and therefore no transcoding issues
arise. The patch also remove seemingly unnecessary calls to XMLStreamWriter.writeStartElement()
and XMLStreamWriter.writeEndElement().
Index: parser/src/main/java/org/apache/abdera/parser/stax/FOMDiv.java
===================================================================
--- parser/src/main/java/org/apache/abdera/parser/stax/FOMDiv.java (revision 834082)
+++ parser/src/main/java/org/apache/abdera/parser/stax/FOMDiv.java (working copy)
@@ -17,7 +17,7 @@
*/
package org.apache.abdera.parser.stax;
-import java.io.ByteArrayOutputStream;
+import java.io.StringWriter;
import java.util.Iterator;
import javax.xml.namespace.QName;
@@ -143,16 +143,14 @@
protected String getInternalValue() {
try {
- ByteArrayOutputStream out = new ByteArrayOutputStream();
+ StringWriter out = new StringWriter();
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);
+ return out.getBuffer().toString();
} catch (Exception e) {}
return "";
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Abdera fails to load META-INF/services provider configuration files on non-ASCII platforms
------------------------------------------------------------------------------------------
Key: ABDERA-250
URL: https://issues.apache.org/jira/browse/ABDERA-250
Project: Abdera
Issue Type: Bug
Affects Versions: 0.4.0, 1.0
Environment: z/OS, IBM Java 6.0 sr4
Reporter: Robin Fernandes
Sun's jar file specification states that service provider config files (the files under META-INF/services
that determine which implementations of a given interface to use) must be encoded as UTF-8:
http://java.sun.com/javase/6/docs/technotes/guides/jar/jar.html#Provider%20Configuration%20File
Abdera attempts to read these files without explicitly specifying an encoding. In other words,
it assumes the files are in the default platform encoding. Consequently, on non-ASCII platforms,
the files are not read correctly. For example, on z/OS (an EBCDIC platform), the UTF-8 config
files are read as though they were EBCDIC by Abdera, so they are not processed correctly.
Here's a suggested patch:
Index: core/src/main/java/org/apache/abdera/util/ServiceUtil.java
===================================================================
--- core/src/main/java/org/apache/abdera/util/ServiceUtil.java (revision 834079)
+++ core/src/main/java/org/apache/abdera/util/ServiceUtil.java (working copy)
@@ -279,7 +279,7 @@
try {
InputStream is = locateStream(sid);
if (is != null) {
- buf = new BufferedReader(new InputStreamReader(is));
+ buf = new BufferedReader(new InputStreamReader(is, "UTF-8"));
String line = buf.readLine();
if (line != null) {
String s = line.split("#",2)[0].trim();
@@ -326,7 +326,7 @@
URL url = (URL) e.nextElement();
InputStream is = url.openStream();
if (is != null) {
- buf = new BufferedReader(new InputStreamReader(is));
+ buf = new BufferedReader(new InputStreamReader(is, "UTF-8"));
String line;
while ((line = buf.readLine()) != null) {
String s = line.split("#",2)[0].trim();
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
On Fri, Nov 6, 2009 at 5:19 PM, Luciano Resende <luckbr1975@gmail.com> wrote: > > All what I was trying to do was to give my advice on the legal side of > the release being voted. As you said, I'm no binding, and I don't want > to interfere with what the Abdera PMC thing it's the right thing to > do. Please have fun.... > Don't be like that. If we didn't publish these artifacts would you actually help make new ones? By that I mean help fix trunk so it builds again which is what needs to happen before any legal updates could be done as we need to see what the distribution looks like. ...ant
On Fri, Nov 6, 2009 at 8:39 AM, ant elder <antelder@apache.org> wrote: > I think it needs to be clear what state Abdera is in. There have been > no releases since leaving the Incubator a year ago, there have been no > commits for 6 months, committers have said they no longer have time > for the project, most questions or patches on the dev list go ignored. > The trunk code is broken from various changes at the start of the year > including some non trivial refactoring and with the old committers not > around to answer questions its difficult to work out fixes. > > At this stage Abdera could be retired to the Apache Attic, or try to > get some new committers to get some life back in it. It does seem like > there is a community willing to contribute and there is a sizable user > base so it would be a shame to retire it. But right now its very > difficult for anyone to help as trunk is broken and patches aren't > getting applied. > > The 1.0 vote happened way back in January and passed with 4 binding +1 > votes and a non binding -1, and it seems reasonably clear from the > thread and other later emails that the PMC considered the vote a pass > and the artifacts could be published. I've checked the licensing, > there are some inconsistencies but i don't see anything I'd consider a > blocker and I'd don't see any problem with following through on the > result of the vote and finally publishing the artifacts, especially > given the current state of the project. That would give at least a > point to try to go forward with and we could start bringing up trunk > again, applying some patches, getting some new comitters, and then > maybe it would be possible to get the latest code out in another > release. > > ...ant > All what I was trying to do was to give my advice on the legal side of the release being voted. As you said, I'm no binding, and I don't want to interfere with what the Abdera PMC thing it's the right thing to do. Please have fun.... -- Luciano Resende http://people.apache.org/~lresende http://lresende.blogspot.com/
I think it needs to be clear what state Abdera is in. There have been no releases since leaving the Incubator a year ago, there have been no commits for 6 months, committers have said they no longer have time for the project, most questions or patches on the dev list go ignored. The trunk code is broken from various changes at the start of the year including some non trivial refactoring and with the old committers not around to answer questions its difficult to work out fixes. At this stage Abdera could be retired to the Apache Attic, or try to get some new committers to get some life back in it. It does seem like there is a community willing to contribute and there is a sizable user base so it would be a shame to retire it. But right now its very difficult for anyone to help as trunk is broken and patches aren't getting applied. The 1.0 vote happened way back in January and passed with 4 binding +1 votes and a non binding -1, and it seems reasonably clear from the thread and other later emails that the PMC considered the vote a pass and the artifacts could be published. I've checked the licensing, there are some inconsistencies but i don't see anything I'd consider a blocker and I'd don't see any problem with following through on the result of the vote and finally publishing the artifacts, especially given the current state of the project. That would give at least a point to try to go forward with and we could start bringing up trunk again, applying some patches, getting some new comitters, and then maybe it would be possible to get the latest code out in another release. ...ant On Fri, Nov 6, 2009 at 7:45 AM, David Calavera <david.calavera@gmail.com> wrote: > I don't know who was the last committer that modified the trunk code, but > actually it doesn't compile even and I'm not sure if that code is too much > stable. > > Luciano, seems you have much experience than us in legal stuff, any patch to > solve those issues is very appreciated. > > Finally, I just want to remember that voting processes should go on 72 > hours, messages after that can be gracefully ignored. > > Cheers > > > On Fri, Nov 6, 2009 at 3:01 AM, Luciano Resende <luckbr1975@gmail.com>wrote: > >> On Mon, Oct 26, 2009 at 12:37 AM, ant elder <antelder@apache.org> wrote: >> > Thanks for replying. I did find the old vote threads, the license >> > issue was a question on the copyrights in the NOTICE file, I've had a >> > look and I don't think there's any issue - not all copyrights need to >> > be included its only required third-party notices that are necessary, >> > and they seem ok. So it should be fine to publish those artifacts. >> > I'll wait for a while to see if anyone else comments. >> > >> >> I believe there were various enhancements applied to trunk after the >> release was started (see [1]). as this is a 1.0 release, would it be >> better to get these changes and start a new vote ? > > >> I also think that the legal files should be reviewed, there seems to >> be issues as described in [2], but there seems to be other issue as >> well (e.g jaxen-LICENSE.txt is a ASL 2.0 license, and the license.txt >> inside javen-1.1.1.jar is a BSD like one). >> >> [1] http://markmail.org/message/qnk6xo2e5eqtuyia >> [2] http://markmail.org/message/vb2s6gay4dfqxnbt > > >> -- >> Luciano Resende >> http://people.apache.org/~lresende <http://people.apache.org/%7Elresende> >> http://lresende.blogspot.com/ >> >
On Thu, Nov 5, 2009 at 11:45 PM, David Calavera <david.calavera@gmail.com> wrote: > I don't know who was the last committer that modified the trunk code, but > actually it doesn't compile even and I'm not sure if that code is too much > stable. > > Luciano, seems you have much experience than us in legal stuff, any patch to > solve those issues is very appreciated. > > Finally, I just want to remember that voting processes should go on 72 > hours, messages after that can be gracefully ignored. > > Cheers I can try to send a patch over the weekend, as I'm at ApacheCon and still have to present today... -- Luciano Resende http://people.apache.org/~lresende http://lresende.blogspot.com/
I don't know who was the last committer that modified the trunk code, but actually it doesn't compile even and I'm not sure if that code is too much stable. Luciano, seems you have much experience than us in legal stuff, any patch to solve those issues is very appreciated. Finally, I just want to remember that voting processes should go on 72 hours, messages after that can be gracefully ignored. Cheers On Fri, Nov 6, 2009 at 3:01 AM, Luciano Resende <luckbr1975@gmail.com>wrote: > On Mon, Oct 26, 2009 at 12:37 AM, ant elder <antelder@apache.org> wrote: > > Thanks for replying. I did find the old vote threads, the license > > issue was a question on the copyrights in the NOTICE file, I've had a > > look and I don't think there's any issue - not all copyrights need to > > be included its only required third-party notices that are necessary, > > and they seem ok. So it should be fine to publish those artifacts. > > I'll wait for a while to see if anyone else comments. > > > > I believe there were various enhancements applied to trunk after the > release was started (see [1]). as this is a 1.0 release, would it be > better to get these changes and start a new vote ? > I also think that the legal files should be reviewed, there seems to > be issues as described in [2], but there seems to be other issue as > well (e.g jaxen-LICENSE.txt is a ASL 2.0 license, and the license.txt > inside javen-1.1.1.jar is a BSD like one). > > [1] http://markmail.org/message/qnk6xo2e5eqtuyia > [2] http://markmail.org/message/vb2s6gay4dfqxnbt > -- > Luciano Resende > http://people.apache.org/~lresende <http://people.apache.org/%7Elresende> > http://lresende.blogspot.com/ >
On Mon, Oct 26, 2009 at 12:37 AM, ant elder <antelder@apache.org> wrote: > Thanks for replying. I did find the old vote threads, the license > issue was a question on the copyrights in the NOTICE file, I've had a > look and I don't think there's any issue - not all copyrights need to > be included its only required third-party notices that are necessary, > and they seem ok. So it should be fine to publish those artifacts. > I'll wait for a while to see if anyone else comments. > I believe there were various enhancements applied to trunk after the release was started (see [1]). as this is a 1.0 release, would it be better to get these changes and start a new vote ? I also think that the legal files should be reviewed, there seems to be issues as described in [2], but there seems to be other issue as well (e.g jaxen-LICENSE.txt is a ASL 2.0 license, and the license.txt inside javen-1.1.1.jar is a BSD like one). [1] http://markmail.org/message/qnk6xo2e5eqtuyia [2] http://markmail.org/message/vb2s6gay4dfqxnbt -- Luciano Resende http://people.apache.org/~lresende http://lresende.blogspot.com/
Hello,
Is there a workaround for this build error?
Sean
On Sun, Nov 1, 2009 at 8:17 PM, Sean Sullivan <sean@seansullivan.com> wrote:
>
> $ rm -rf ~/.m2/repository/org/apache/abdera
>
> $ svn co http://svn.apache.org/repos/asf/abdera/java/trunk/
>
> $ cd trunk
>
> $ mvn --version
>
> Apache Maven 2.2.1 (r801777; 2009-08-06 12:16:01-0700)
> Java version: 1.6.0_15
> Java home: /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home
> Default locale: en_US, platform encoding: MacRoman
> OS name: "mac os x" version: "10.6.1" arch: "x86_64" Family: "mac"
>
> $ mvn clean install
>
> The build fails with the following errors:
>
> [INFO] [compiler:compile {execution: default-compile}]
> [INFO] Compiling 50 source files to
> /private/tmp/apache/trunk/parser/target/classes
> [INFO]
> ------------------------------------------------------------------------
> [ERROR] BUILD FAILURE
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Compilation failure
>
> /private/tmp/apache/trunk/parser/src/main/java/org/apache/abdera/parser/stax/FOMElement.java:[51,31]
> cannot find symbol
> symbol : class ParseException
> location: package org.apache.abdera.parser
>
> /private/tmp/apache/trunk/parser/src/main/java/org/apache/abdera/parser/stax/FOMElement.java:[52,31]
> cannot find symbol
> symbol : class Parser
> location: package org.apache.abdera.parser
>
> /private/tmp/apache/trunk/parser/src/main/java/org/apache/abdera/parser/stax/FOMElement.java:[53,31]
> cannot find symbol
> symbol : class ParserOptions
> location: package org.apache.abdera.parser
>
> /private/tmp/apache/trunk/parser/src/main/java/org/apache/abdera/parser/stax/FOMElement.java:[581,61]
> cannot find symbol
> symbol : class ParseException
> location: class org.apache.abdera.parser.stax.FOMElement
>
> /private/tmp/apache/trunk/parser/src/main/java/org/apache/abdera/parser/stax/FOMParser.java:[34,31]
> cannot find symbol
> symbol : class ParseException
> location: package org.apache.abdera.parser
>
> /private/tmp/apache/trunk/parser/src/main/java/org/apache/abdera/parser/stax/FOMParser.java:[36,31]
> cannot find symbol
> symbol : class ParserOptions
> location: package org.apache.abdera.parser
>
> /private/tmp/apache/trunk/parser/src/main/java/org/apache/abdera/parser/stax/FOMParser.java:[45,13]
> cannot find symbol
> symbol: class Parser
> implements Parser {
>
> /private/tmp/apache/trunk/parser/src/main/java/org/apache/abdera/parser/stax/FOMParser.java:[55,35]
> cannot find symbol
> symbol : class ParserOptions
> location: class org.apache.abdera.parser.stax.FOMParser
>
> /private/tmp/apache/trunk/parser/src/main/java/org/apache/abdera/parser/stax/FOMBuilder.java:[32,31]
> cannot find symbol
> symbol : class ParseException
> location: package org.apache.abdera.parser
>
> /private/tmp/apache/trunk/parser/src/main/java/org/apache/abdera/parser/stax/FOMBuilder.java:[33,31]
> cannot find symbol
> symbol : class ParserOptions
> location: package org.apache.abdera.parser
>
> /private/tmp/apache/trunk/parser/src/main/java/org/apache/abdera/parser/stax/FOMParser.java:[70,4]
> cannot find symbol
> symbol : class ParserOptions
> location: class org.apache.abdera.parser.stax.FOMParser
>
> /private/tmp/apache/trunk/parser/src/main/java/org/apache/abdera/parser/stax/FOMParser.java:[71,13]
> cannot find symbol
> symbol : class ParseException
> location: class org.apache.abdera.parser.stax.FOMParser
>
> /private/tmp/apache/trunk/parser/src/main/java/org/apache/abdera/parser/stax/FOMParser.java:[90,4]
> cannot find symbol
> symbol : class ParserOptions
> location: class org.apache.abdera.parser.stax.FOMParser
>
> /private/tmp/apache/trunk/parser/src/main/java/org/apache/abdera/parser/stax/FOMParser.java:[91,13]
> cannot find symbol
> symbol : class ParseException
> location: class org.apache.abdera.parser.stax.FOMParser
>
> /private/tmp/apache/trunk/parser/src/main/java/org/apache/abdera/parser/stax/FOMParser.java:[133,4]
> cannot find symbol
> symbol : class ParserOptions
> location: class org.apache.abdera.parser.stax.FOMParser
>
> /private/tmp/apache/trunk/parser/src/main/java/org/apache/abdera/parser/stax/FOMParser.java:[134,13]
> cannot find symbol
> symbol : class ParseException
> location: class org.apache.abdera.parser.stax.FOMParser
>
> /private/tmp/apache/trunk/parser/src/main/java/org/apache/abdera/parser/stax/FOMParser.java:[199,4]
> cannot find symbol
> symbol : class ParserOptions
> location: class org.apache.abdera.parser.stax.FOMParser
>
> /private/tmp/apache/trunk/parser/src/main/java/org/apache/abdera/parser/stax/FOMParser.java:[200,13]
> cannot find symbol
> symbol : class ParseException
> location: class org.apache.abdera.parser.stax.FOMParser
>
> /private/tmp/apache/trunk/parser/src/main/java/org/apache/abdera/parser/stax/FOMParser.java:[216,12]
> cannot find symbol
> symbol : class ParserOptions
> location: class org.apache.abdera.parser.stax.FOMParser
>
> /private/tmp/apache/trunk/parser/src/main/java/org/apache/abdera/parser/stax/FOMFactory.java:[96,9]
> cannot find symbol
> symbol : class Parser
> location: class org.apache.abdera.parser.stax.FOMFactory
>
> /private/tmp/apache/trunk/parser/src/main/java/org/apache/abdera/parser/stax/FOMBuilder.java:[55,16]
> cannot find symbol
> symbol : class ParserOptions
> location: class org.apache.abdera.parser.stax.FOMBuilder
>
> /private/tmp/apache/trunk/parser/src/main/java/org/apache/abdera/parser/stax/FOMBuilder.java:[66,4]
> cannot find symbol
> symbol : class ParserOptions
> location: class org.apache.abdera.parser.stax.FOMBuilder
>
> /private/tmp/apache/trunk/parser/src/main/java/org/apache/abdera/parser/stax/FOMBuilder.java:[86,9]
> cannot find symbol
> symbol : class ParserOptions
> location: class org.apache.abdera.parser.stax.FOMBuilder
>
> /private/tmp/apache/trunk/parser/src/main/java/org/apache/abdera/parser/stax/FOMException.java:[22,34]
> cannot find symbol
> symbol: class ParseException
> public class FOMException extends ParseException {
>
> /private/tmp/apache/trunk/parser/src/main/java/org/apache/abdera/parser/stax/FOMParserFactory.java:[24,31]
> cannot find symbol
> symbol : class NamedParser
> location: package org.apache.abdera.parser
>
> /private/tmp/apache/trunk/parser/src/main/java/org/apache/abdera/parser/stax/FOMParserFactory.java:[26,31]
> cannot find symbol
> symbol : class ParserFactory
> location: package org.apache.abdera.parser
>
> /private/tmp/apache/trunk/parser/src/main/java/org/apache/abdera/parser/stax/FOMParserFactory.java:[31,13]
> cannot find symbol
> symbol: class ParserFactory
> implements ParserFactory {
>
> /private/tmp/apache/trunk/parser/src/main/java/org/apache/abdera/parser/stax/FOMParserFactory.java:[34,27]
> cannot find symbol
> symbol : class NamedParser
> location: class org.apache.abdera.parser.stax.FOMParserFactory
>
> /private/tmp/apache/trunk/parser/src/main/java/org/apache/abdera/parser/stax/FOMParserFactory.java:[50,20]
> cannot find symbol
> symbol : class Parser
> location: class org.apache.abdera.parser.stax.FOMParserFactory
>
> /private/tmp/apache/trunk/parser/src/main/java/org/apache/abdera/parser/stax/FOMParserFactory.java:[54,20]
> cannot find symbol
> symbol : class Parser
> location: class org.apache.abdera.parser.stax.FOMParserFactory
>
> /private/tmp/apache/trunk/parser/src/main/java/org/apache/abdera/parser/stax/FOMParserFactory.java:[63,21]
> cannot find symbol
> symbol : class NamedParser
> location: class org.apache.abdera.parser.stax.FOMParserFactory
>
> /private/tmp/apache/trunk/parser/src/main/java/org/apache/abdera/parser/stax/FOMElement.java:[405,14]
> incompatible types
> found : org.apache.abdera.parser.stax.FOMException
> required: java.lang.Throwable
>
> /private/tmp/apache/trunk/parser/src/main/java/org/apache/abdera/parser/stax/FOMElement.java:[584,4]
> cannot find symbol
> symbol : class Parser
> location: class org.apache.abdera.parser.stax.FOMElement
>
> /private/tmp/apache/trunk/parser/src/main/java/org/apache/abdera/parser/stax/FOMElement.java:[586,4]
> cannot find symbol
> symbol : class ParserOptions
> location: class org.apache.abdera.parser.stax.FOMElement
>
>
>
$ rm -rf ~/.m2/repository/org/apache/abdera
$ svn co http://svn.apache.org/repos/asf/abdera/java/trunk/
$ cd trunk
$ mvn --version
Apache Maven 2.2.1 (r801777; 2009-08-06 12:16:01-0700)
Java version: 1.6.0_15
Java home: /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home
Default locale: en_US, platform encoding: MacRoman
OS name: "mac os x" version: "10.6.1" arch: "x86_64" Family: "mac"
$ mvn clean install
The build fails with the following errors:
[INFO] [compiler:compile {execution: default-compile}]
[INFO] Compiling 50 source files to
/private/tmp/apache/trunk/parser/target/classes
[INFO]
------------------------------------------------------------------------
[ERROR] BUILD FAILURE
[INFO]
------------------------------------------------------------------------
[INFO] Compilation failure
/private/tmp/apache/trunk/parser/src/main/java/org/apache/abdera/parser/stax/FOMElement.java:[51,31]
cannot find symbol
symbol : class ParseException
location: package org.apache.abdera.parser
/private/tmp/apache/trunk/parser/src/main/java/org/apache/abdera/parser/stax/FOMElement.java:[52,31]
cannot find symbol
symbol : class Parser
location: package org.apache.abdera.parser
/private/tmp/apache/trunk/parser/src/main/java/org/apache/abdera/parser/stax/FOMElement.java:[53,31]
cannot find symbol
symbol : class ParserOptions
location: package org.apache.abdera.parser
/private/tmp/apache/trunk/parser/src/main/java/org/apache/abdera/parser/stax/FOMElement.java:[581,61]
cannot find symbol
symbol : class ParseException
location: class org.apache.abdera.parser.stax.FOMElement
/private/tmp/apache/trunk/parser/src/main/java/org/apache/abdera/parser/stax/FOMParser.java:[34,31]
cannot find symbol
symbol : class ParseException
location: package org.apache.abdera.parser
/private/tmp/apache/trunk/parser/src/main/java/org/apache/abdera/parser/stax/FOMParser.java:[36,31]
cannot find symbol
symbol : class ParserOptions
location: package org.apache.abdera.parser
/private/tmp/apache/trunk/parser/src/main/java/org/apache/abdera/parser/stax/FOMParser.java:[45,13]
cannot find symbol
symbol: class Parser
implements Parser {
/private/tmp/apache/trunk/parser/src/main/java/org/apache/abdera/parser/stax/FOMParser.java:[55,35]
cannot find symbol
symbol : class ParserOptions
location: class org.apache.abdera.parser.stax.FOMParser
/private/tmp/apache/trunk/parser/src/main/java/org/apache/abdera/parser/stax/FOMBuilder.java:[32,31]
cannot find symbol
symbol : class ParseException
location: package org.apache.abdera.parser
/private/tmp/apache/trunk/parser/src/main/java/org/apache/abdera/parser/stax/FOMBuilder.java:[33,31]
cannot find symbol
symbol : class ParserOptions
location: package org.apache.abdera.parser
/private/tmp/apache/trunk/parser/src/main/java/org/apache/abdera/parser/stax/FOMParser.java:[70,4]
cannot find symbol
symbol : class ParserOptions
location: class org.apache.abdera.parser.stax.FOMParser
/private/tmp/apache/trunk/parser/src/main/java/org/apache/abdera/parser/stax/FOMParser.java:[71,13]
cannot find symbol
symbol : class ParseException
location: class org.apache.abdera.parser.stax.FOMParser
/private/tmp/apache/trunk/parser/src/main/java/org/apache/abdera/parser/stax/FOMParser.java:[90,4]
cannot find symbol
symbol : class ParserOptions
location: class org.apache.abdera.parser.stax.FOMParser
/private/tmp/apache/trunk/parser/src/main/java/org/apache/abdera/parser/stax/FOMParser.java:[91,13]
cannot find symbol
symbol : class ParseException
location: class org.apache.abdera.parser.stax.FOMParser
/private/tmp/apache/trunk/parser/src/main/java/org/apache/abdera/parser/stax/FOMParser.java:[133,4]
cannot find symbol
symbol : class ParserOptions
location: class org.apache.abdera.parser.stax.FOMParser
/private/tmp/apache/trunk/parser/src/main/java/org/apache/abdera/parser/stax/FOMParser.java:[134,13]
cannot find symbol
symbol : class ParseException
location: class org.apache.abdera.parser.stax.FOMParser
/private/tmp/apache/trunk/parser/src/main/java/org/apache/abdera/parser/stax/FOMParser.java:[199,4]
cannot find symbol
symbol : class ParserOptions
location: class org.apache.abdera.parser.stax.FOMParser
/private/tmp/apache/trunk/parser/src/main/java/org/apache/abdera/parser/stax/FOMParser.java:[200,13]
cannot find symbol
symbol : class ParseException
location: class org.apache.abdera.parser.stax.FOMParser
/private/tmp/apache/trunk/parser/src/main/java/org/apache/abdera/parser/stax/FOMParser.java:[216,12]
cannot find symbol
symbol : class ParserOptions
location: class org.apache.abdera.parser.stax.FOMParser
/private/tmp/apache/trunk/parser/src/main/java/org/apache/abdera/parser/stax/FOMFactory.java:[96,9]
cannot find symbol
symbol : class Parser
location: class org.apache.abdera.parser.stax.FOMFactory
/private/tmp/apache/trunk/parser/src/main/java/org/apache/abdera/parser/stax/FOMBuilder.java:[55,16]
cannot find symbol
symbol : class ParserOptions
location: class org.apache.abdera.parser.stax.FOMBuilder
/private/tmp/apache/trunk/parser/src/main/java/org/apache/abdera/parser/stax/FOMBuilder.java:[66,4]
cannot find symbol
symbol : class ParserOptions
location: class org.apache.abdera.parser.stax.FOMBuilder
/private/tmp/apache/trunk/parser/src/main/java/org/apache/abdera/parser/stax/FOMBuilder.java:[86,9]
cannot find symbol
symbol : class ParserOptions
location: class org.apache.abdera.parser.stax.FOMBuilder
/private/tmp/apache/trunk/parser/src/main/java/org/apache/abdera/parser/stax/FOMException.java:[22,34]
cannot find symbol
symbol: class ParseException
public class FOMException extends ParseException {
/private/tmp/apache/trunk/parser/src/main/java/org/apache/abdera/parser/stax/FOMParserFactory.java:[24,31]
cannot find symbol
symbol : class NamedParser
location: package org.apache.abdera.parser
/private/tmp/apache/trunk/parser/src/main/java/org/apache/abdera/parser/stax/FOMParserFactory.java:[26,31]
cannot find symbol
symbol : class ParserFactory
location: package org.apache.abdera.parser
/private/tmp/apache/trunk/parser/src/main/java/org/apache/abdera/parser/stax/FOMParserFactory.java:[31,13]
cannot find symbol
symbol: class ParserFactory
implements ParserFactory {
/private/tmp/apache/trunk/parser/src/main/java/org/apache/abdera/parser/stax/FOMParserFactory.java:[34,27]
cannot find symbol
symbol : class NamedParser
location: class org.apache.abdera.parser.stax.FOMParserFactory
/private/tmp/apache/trunk/parser/src/main/java/org/apache/abdera/parser/stax/FOMParserFactory.java:[50,20]
cannot find symbol
symbol : class Parser
location: class org.apache.abdera.parser.stax.FOMParserFactory
/private/tmp/apache/trunk/parser/src/main/java/org/apache/abdera/parser/stax/FOMParserFactory.java:[54,20]
cannot find symbol
symbol : class Parser
location: class org.apache.abdera.parser.stax.FOMParserFactory
/private/tmp/apache/trunk/parser/src/main/java/org/apache/abdera/parser/stax/FOMParserFactory.java:[63,21]
cannot find symbol
symbol : class NamedParser
location: class org.apache.abdera.parser.stax.FOMParserFactory
/private/tmp/apache/trunk/parser/src/main/java/org/apache/abdera/parser/stax/FOMElement.java:[405,14]
incompatible types
found : org.apache.abdera.parser.stax.FOMException
required: java.lang.Throwable
/private/tmp/apache/trunk/parser/src/main/java/org/apache/abdera/parser/stax/FOMElement.java:[584,4]
cannot find symbol
symbol : class Parser
location: class org.apache.abdera.parser.stax.FOMElement
/private/tmp/apache/trunk/parser/src/main/java/org/apache/abdera/parser/stax/FOMElement.java:[586,4]
cannot find symbol
symbol : class ParserOptions
location: class org.apache.abdera.parser.stax.FOMElement
Thanks for replying. I did find the old vote threads, the license issue was a question on the copyrights in the NOTICE file, I've had a look and I don't think there's any issue - not all copyrights need to be included its only required third-party notices that are necessary, and they seem ok. So it should be fine to publish those artifacts. I'll wait for a while to see if anyone else comments. ...ant On Sun, Oct 25, 2009 at 11:22 AM, David Calavera <david.calavera@gmail.com> wrote: > The artifacts published in January were petty much stable but there was > license issues, some of them were missing. I can't find the thread were we > discussed that right now. Btw, +1 to publish the same artifacts. > > On Sun, Oct 25, 2009 at 10:53 AM, ant elder <ant.elder@gmail.com> wrote: > >> There was a 1.0 release back in January but it doesn't look like the >> release artifacts were ever published in the distribution area or >> maven repository. I know there has since been a suggestion to do a new >> 1.0 to pick up all the latest trunk fixes but as thats taking some >> time how about just publishing the January artifacts now and having >> all the latest trunk code go out in a new release? WDYT? >> >> ...ant >> >
The artifacts published in January were petty much stable but there was license issues, some of them were missing. I can't find the thread were we discussed that right now. Btw, +1 to publish the same artifacts. On Sun, Oct 25, 2009 at 10:53 AM, ant elder <ant.elder@gmail.com> wrote: > There was a 1.0 release back in January but it doesn't look like the > release artifacts were ever published in the distribution area or > maven repository. I know there has since been a suggestion to do a new > 1.0 to pick up all the latest trunk fixes but as thats taking some > time how about just publishing the January artifacts now and having > all the latest trunk code go out in a new release? WDYT? > > ...ant >
There was a 1.0 release back in January but it doesn't look like the release artifacts were ever published in the distribution area or maven repository. I know there has since been a suggestion to do a new 1.0 to pick up all the latest trunk fixes but as thats taking some time how about just publishing the January artifacts now and having all the latest trunk code go out in a new release? WDYT? ...ant
Abdera fails to completely read streams using GZIP compression
--------------------------------------------------------------
Key: ABDERA-249
URL: https://issues.apache.org/jira/browse/ABDERA-249
Project: Abdera
Issue Type: Bug
Affects Versions: 1.0
Environment: Mac OS X, Java 1.6
Reporter: James Falkner
Test code:
{code:java}
Abdera abdera = new Abdera();
AbderaClient client = new AbderaClient(abdera);
ClientResponse resp = client.get("http://www.facebook.com/activitystreams/feed.php?source_id=499225640");
Document<Feed> doc = resp.getDocument();
doc.complete();
{code}
When reading a stream that is gzip-compressed (such as the sample facebook stream above),
Abdera throws an exception:
{code}
Exception in thread "main" org.apache.abdera.parser.ParseException: java.lang.RuntimeException:
[was class java.io.EOFException] Unexpected end of ZLIB input stream
at org.apache.abdera.parser.stax.FOMBuilder.next(FOMBuilder.java:260)
at org.apache.axiom.om.impl.llom.OMNodeImpl.build(OMNodeImpl.java:318)
at org.apache.axiom.om.impl.llom.OMElementImpl.build(OMElementImpl.java:614)
at org.apache.abdera.parser.stax.FOMElement.complete(FOMElement.java:845)
at org.apache.abdera.parser.stax.FOMFeed.sortEntries(FOMFeed.java:167)
at FacebookStreamReader.main(FacebookStreamReader.java:42)
Caused by: java.lang.RuntimeException: [was class java.io.EOFException] Unexpected end of
ZLIB input stream
at com.ctc.wstx.util.ExceptionUtil.throwRuntimeException(ExceptionUtil.java:18)
at com.ctc.wstx.sr.StreamScanner.throwLazyError(StreamScanner.java:706)
at com.ctc.wstx.sr.BasicStreamReader.safeFinishToken(BasicStreamReader.java:3655)
at com.ctc.wstx.sr.BasicStreamReader.getText(BasicStreamReader.java:809)
at org.apache.axiom.om.impl.builder.StAXBuilder.createOMText(StAXBuilder.java:245)
at org.apache.axiom.om.impl.builder.StAXBuilder.createOMText(StAXBuilder.java:216)
at org.apache.abdera.parser.stax.FOMBuilder.applyTextFilter(FOMBuilder.java:158)
at org.apache.abdera.parser.stax.FOMBuilder.next(FOMBuilder.java:206)
... 5 more
Caused by: java.io.EOFException: Unexpected end of ZLIB input stream
at java.util.zip.InflaterInputStream.fill(InflaterInputStream.java:223)
at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:141)
at java.util.zip.GZIPInputStream.read(GZIPInputStream.java:92)
at java.io.FilterInputStream.read(FilterInputStream.java:116)
at org.apache.abdera.protocol.client.util.AutoReleasingInputStream.read(AutoReleasingInputStream.java:56)
at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:264)
at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:306)
at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:158)
at java.io.InputStreamReader.read(InputStreamReader.java:167)
at com.ctc.wstx.io.MergedReader.read(MergedReader.java:101)
at com.ctc.wstx.io.ReaderSource.readInto(ReaderSource.java:84)
at com.ctc.wstx.io.BranchingReaderSource.readInto(BranchingReaderSource.java:57)
at com.ctc.wstx.sr.StreamScanner.loadMore(StreamScanner.java:967)
at com.ctc.wstx.sr.BasicStreamReader.readTextSecondary(BasicStreamReader.java:4626)
at com.ctc.wstx.sr.BasicStreamReader.readCoalescedText(BasicStreamReader.java:4124)
at com.ctc.wstx.sr.BasicStreamReader.finishToken(BasicStreamReader.java:3699)
at com.ctc.wstx.sr.BasicStreamReader.safeFinishToken(BasicStreamReader.java:3647)
... 10 more
{code}
If I force the stream to be un-compressed, via this code, it works:
{code:java}
Abdera abdera = new Abdera();
AbderaClient client = new AbderaClient(abdera);
RequestOptions options = client.getDefaultRequestOptions();
options.setAcceptEncoding((String)null);
ClientResponse resp = client.get("http://www.facebook.com/activitystreams/feed.php?source_id=499225640",
options);
Document<Feed> doc = resp.getDocument();
doc.complete();
{code}
There is some code in org.apache.abdera.protocol.client.util.AutoReleasingInputStream that
is not properly handling the EOFException. If I modify that code to also catch the EOFException
and behave as though it had gotten back a -1 from the read() method, then it also starts working.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/ABDERA-232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Neale Upstone updated ABDERA-232:
---------------------------------
Remaining Estimate: 0h
Original Estimate: 0h
Is no one maintaining this project any more? I'd have expected this would be a quick and
easy one.
> build - i18n pom missing commons-codec dependency
> -------------------------------------------------
>
> Key: ABDERA-232
> URL: https://issues.apache.org/jira/browse/ABDERA-232
> Project: Abdera
> Issue Type: Bug
> Affects Versions: 1.0
> Reporter: Neale Upstone
> Priority: Trivial
> Original Estimate: 0h
> Remaining Estimate: 0h
>
> I've just checked out the whole abdera project into Eclipse + IAM, and all builds fine
apart from i18n.
> i18n depends on commons-codec 1.3.
> Fix:
> Add the following to dependencies/i18n/pom.xml
> <dependency>
> <groupId>commons-codec</groupId>
> <artifactId>commons-codec</artifactId>
> <version>1.3</version>
> <scope>compile</scope>
> </dependency>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/ABDERA-248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12754055#action_12754055
]
Felix Meschberger commented on ABDERA-248:
------------------------------------------
Oops, this was probably too far above in the peanut gallery and I confused input with output.....
You are right: if the context is creating/getting/acquiring the input, it has to make sure
it is closed.
> MediaResponseContext#writeTo fails to close input stream after writing
> ----------------------------------------------------------------------
>
> Key: ABDERA-248
> URL: https://issues.apache.org/jira/browse/ABDERA-248
> Project: Abdera
> Issue Type: Bug
> Affects Versions: 1.0
> Reporter: Daniel Lichtenberger
>
> MediaResponseContext#writeTo fully consumes the input stream, but does not close it afterwards.
Looking at the source, I also didn't find another place where the input stream was closed,
potentially leaving an open input stream for every media response.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/ABDERA-248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12754053#action_12754053
]
Daniel Lichtenberger commented on ABDERA-248:
---------------------------------------------
Well, the client in my case is the AbderaServlet calling context.writeTo(response.getOutputStream()),
and AbderaServlet doesn't know about any wrapped streams in the ResponseContext.
I'm not familiar with the Abdera source code, so I don't know whether ResponseContext#writeTo
should always close the input stream or the caller (AbderaServlet) should call a close method
on the ResponseContext to allow releasing resources at the end of a request.
> MediaResponseContext#writeTo fails to close input stream after writing
> ----------------------------------------------------------------------
>
> Key: ABDERA-248
> URL: https://issues.apache.org/jira/browse/ABDERA-248
> Project: Abdera
> Issue Type: Bug
> Affects Versions: 1.0
> Reporter: Daniel Lichtenberger
>
> MediaResponseContext#writeTo fully consumes the input stream, but does not close it afterwards.
Looking at the source, I also didn't find another place where the input stream was closed,
potentially leaving an open input stream for every media response.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/ABDERA-248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12754050#action_12754050
]
Felix Meschberger commented on ABDERA-248:
------------------------------------------
>From the peanut gallery not knowing any code: Shouldn't closing the stream be the task
of the caller ?
I assume writeTo reads the stream until being notified to have reached the end of the input,
which need not necessarily be the real end. Consider for example reading a ZIP entry from
a ZipInputStream.
> MediaResponseContext#writeTo fails to close input stream after writing
> ----------------------------------------------------------------------
>
> Key: ABDERA-248
> URL: https://issues.apache.org/jira/browse/ABDERA-248
> Project: Abdera
> Issue Type: Bug
> Affects Versions: 1.0
> Reporter: Daniel Lichtenberger
>
> MediaResponseContext#writeTo fully consumes the input stream, but does not close it afterwards.
Looking at the source, I also didn't find another place where the input stream was closed,
potentially leaving an open input stream for every media response.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
MediaResponseContext#writeTo fails to close input stream after writing
----------------------------------------------------------------------
Key: ABDERA-248
URL: https://issues.apache.org/jira/browse/ABDERA-248
Project: Abdera
Issue Type: Bug
Affects Versions: 1.0
Reporter: Daniel Lichtenberger
MediaResponseContext#writeTo fully consumes the input stream, but does not close it afterwards.
Looking at the source, I also didn't find another place where the input stream was closed,
potentially leaving an open input stream for every media response.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
ä½ç½®é—®é¢˜
----
Key: ABDERA-247
URL: https://issues.apache.org/jira/browse/ABDERA-247
Project: Abdera
Issue Type: Bug
Affects Versions: 1.0
Environment: WIN2K3
Reporter: yezq
Fix For: 0.2.2
ä½ç½®é”™ä¸º
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/ABDERA-246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
GK Ephorus updated ABDERA-246:
------------------------------
Fix Version/s: (was: 1.0)
> Abdera 1.0 (tag abdera-1.0) does not compile with java jdk 1.6.0_012
> --------------------------------------------------------------------
>
> Key: ABDERA-246
> URL: https://issues.apache.org/jira/browse/ABDERA-246
> Project: Abdera
> Issue Type: Bug
> Affects Versions: 1.0
> Environment: Windows XP
> Java jdk 1.6.0_012
> Reporter: GK Ephorus
> Priority: Minor
>
> Steps to reproduce:
> * install jdk 1.6.0_012
> * make sure it's used (java added to PATH etc)
> * mvn install
> Expected result:
> * compile succeeds
> Actual result:
> * compile fails at the i18n tests
> Note:
> how to fix:
> * install jdk 1.6.0_14
> * mvn clean
> * mvn install
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Abdera 1.0 (tag abdera-1.0) does not compile with java jdk 1.6.0_012
--------------------------------------------------------------------
Key: ABDERA-246
URL: https://issues.apache.org/jira/browse/ABDERA-246
Project: Abdera
Issue Type: Bug
Affects Versions: 1.0
Environment: Windows XP
Java jdk 1.6.0_012
Reporter: GK Ephorus
Priority: Minor
Fix For: 1.0
Steps to reproduce:
* install jdk 1.6.0_012
* make sure it's used (java added to PATH etc)
* mvn install
Expected result:
* compile succeeds
Actual result:
* compile fails at the i18n tests
Note:
how to fix:
* install jdk 1.6.0_14
* mvn clean
* mvn install
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/ABDERA-245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amar Kamat closed ABDERA-245.
-----------------------------
Resolution: Fixed
This was meant for MAPREDUCE. Sorry.
> Testcases faking TaskTrackerManager might result into NPE
> ---------------------------------------------------------
>
> Key: ABDERA-245
> URL: https://issues.apache.org/jira/browse/ABDERA-245
> Project: Abdera
> Issue Type: Bug
> Reporter: Amar Kamat
>
> JobInProgress uses JobTracker.getClock() assuming that the JobTracker is initialized
before creating JobInProgress. This might not be true as the testcase might fake TaskTrackerManager.
In such cases the JobInProgress might result into NPE.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Testcases faking TaskTrackerManager might result into NPE
---------------------------------------------------------
Key: ABDERA-245
URL: https://issues.apache.org/jira/browse/ABDERA-245
Project: Abdera
Issue Type: Bug
Reporter: Amar Kamat
JobInProgress uses JobTracker.getClock() assuming that the JobTracker is initialized before
creating JobInProgress. This might not be true as the testcase might fake TaskTrackerManager.
In such cases the JobInProgress might result into NPE.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/ABDERA-244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amar Kamat closed ABDERA-244.
-----------------------------
Resolution: Fixed
This was meant for MAPREDUCE. Sorry.
> JobInProgress.initTasks() should not throw KillInterruptedException
> -------------------------------------------------------------------
>
> Key: ABDERA-244
> URL: https://issues.apache.org/jira/browse/ABDERA-244
> Project: Abdera
> Issue Type: Bug
> Reporter: Amar Kamat
>
> JobInProgress.initTasks() throws KillInterruptedException if its killed in init. This
is a bad programming practice.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
JobInProgress.initTasks() should not throw KillInterruptedException
-------------------------------------------------------------------
Key: ABDERA-244
URL: https://issues.apache.org/jira/browse/ABDERA-244
Project: Abdera
Issue Type: Bug
Reporter: Amar Kamat
JobInProgress.initTasks() throws KillInterruptedException if its killed in init. This is a
bad programming practice.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Hi gang,
For a demo we're building, we're using Abdera. Yay. However, one of
the things is that we're parsing both RSS and Atom feeds. I saw that
this support was folded into extensions/ in ABDERA-202 ; but it looks
like a few loose ends were left.
Here's my attempt to fix it. It Works For Me(tm).
Comments welcomed! -- justin
Add RSS support to complete JAR and add it to the ant build.
* extensions/complete/resources/META-INF/services/org.apache.abdera.factory.ExtensionFactory:
Add RSS extension factory to complete JAR.
* build/build.xml: Teach Ant how to build RSS support.
Index: extensions/complete/resources/META-INF/services/org.apache.abdera.factory.ExtensionFactory
===================================================================
--- extensions/complete/resources/META-INF/services/org.apache.abdera.factory.ExtensionFactory
(revision
802867)
+++ extensions/complete/resources/META-INF/services/org.apache.abdera.factory.ExtensionFactory
(working
copy)
@@ -3,5 +3,6 @@
org.apache.abdera.ext.tombstones.TombstonesExtensionFactory
org.apache.abdera.ext.media.MediaExtensionFactory
org.apache.abdera.ext.opensearch.OpenSearchExtensionFactory
+org.apache.abdera.ext.rss.RssExtensionFactory
org.apache.abdera.ext.sharing.SharingExtensionFactory
-org.apache.abdera.protocol.error.ErrorExtensionFactory
\ No newline at end of file
+org.apache.abdera.protocol.error.ErrorExtensionFactory
Index: build/build.xml
===================================================================
--- build/build.xml (revision 802867)
+++ build/build.xml (working copy)
@@ -360,7 +360,7 @@
<target name="docs" depends="init">
<javadoc
packagenames="org.apache.abdera.*"
- sourcepath="${core.src}:${security.src}:${server.src}:${client.src}:${spring.src}:${i18n.src.java}:${extensions}/gdata/src/main/java:${extensions}/geo/src/main/java:${extensions}/html/src/main/java:${extensions}/json/src/main/java:${extensions}/main/src/main/java:${extensions}/media/src/main/java:${extensions}/oauth/src/main/java:${extensions}/opensearch/src/main/java:${extensions}/serializer/src/main/java:${extensions}/sharing/src/main/java:${extensions}/wsse/src/main/java"
+ sourcepath="${core.src}:${security.src}:${server.src}:${client.src}:${spring.src}:${i18n.src.java}:${extensions}/gdata/src/main/java:${extensions}/geo/src/main/java:${extensions}/html/src/main/java:${extensions}/json/src/main/java:${extensions}/main/src/main/java:${extensions}/media/src/main/java:${extensions}/oauth/src/main/java:${extensions}/opensearch/src/main/java:${extensions}/rss/src/main/java:${extensions}/serializer/src/main/java:${extensions}/sharing/src/main/java:${extensions}/wsse/src/main/java"
destdir="${javadocs}"
windowtitle="Abdera"
classpathref="jar.dependencies" />
@@ -445,6 +445,7 @@
<fileset dir="${extensions.work}/media" includes="**/*"
excludes="META-INF/**/*"/>
<fileset dir="${extensions.work}/oauth" includes="**/*"
excludes="META-INF/**/*"/>
<fileset dir="${extensions.work}/opensearch" includes="**/*"
excludes="META-INF/**/*"/>
+ <fileset dir="${extensions.work}/rss" includes="**/*"
excludes="META-INF/**/*"/>
<fileset dir="${extensions.work}/serializer" includes="**/*"
excludes="META-INF/**/*"/>
<fileset dir="${extensions.work}/sharing" includes="**/*"
excludes="META-INF/**/*"/>
<fileset dir="${extensions.work}/wsse" includes="**/*"
excludes="META-INF/**/*"/>
@@ -728,6 +729,10 @@
</antcall>
<antcall target="compile.extension">
+ <param name="ext" value="rss" />
+ </antcall>
+
+ <antcall target="compile.extension">
<param name="ext" value="sharing" />
</antcall>
@@ -819,6 +824,10 @@
</antcall>
<antcall target="dist.extension">
+ <param name="ext" value="rss" />
+ </antcall>
+
+ <antcall target="dist.extension">
<param name="ext" value="sharing" />
</antcall>
@@ -885,6 +894,10 @@
</antcall>
<antcall target="test.extension">
+ <param name="ext" value="rss" />
+ </antcall>
+
+ <antcall target="test.extension">
<param name="ext" value="sharing" />
</antcall>
@@ -945,6 +958,10 @@
</antcall>
<antcall target="retro.extension">
+ <param name="ext" value="rss" />
+ </antcall>
+
+ <antcall target="retro.extension">
<param name="ext" value="sharing" />
</antcall>