Nabble - Abdera

Extension example fails to run

2009-11-22T15:42:48Z

Hi,
I am trying to build extension to feed's entry based on subclassing but facing problems in my code I did fallback and tried to run examples. What I got was exactly the same problem as in my custom classes e.g.

Exception in thread "main" java.lang.ClassCastException: org.apache.abdera.parser.stax.FOMExtensibleElement cannot be cast to org.apache.abdera.examples.extension.Foo
at org.apache.abdera.examples.extension.Example.main(Example.java:34)

So far I have maven dependency on 0.4 but I am not sure it's fixed on trunk... anyway inline setup of elements (described here http://old.nabble.com/Adding-an-extension-ts19266916.html#a19266916) works fine so in my case is acceptable.

Let me join to community question, is there any plan to have 0.5 released?

cheers, andy.

From forum: abdera-user

Activity Streams Abdera Extension published

2009-11-16T19:15:46Z

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@...

From forum: abdera-dev

[jira] Updated: (ABDERA-251) Charset issue in FOMDiv.getInternalValue() leads to corrupt return value on non-ASCII platforms

2009-11-11T07:27:39Z

[ 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.

From forum: abdera-dev

[jira] Created: (ABDERA-251) Charset issue in FOMDiv.getInternalValue() leads to corrupt return value on non-ASCII platforms

2009-11-11T07:25:39Z

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.

From forum: abdera-dev

[jira] Created: (ABDERA-250) Abdera fails to load META-INF/services provider configuration files on non-ASCII platforms

2009-11-09T09:23:34Z

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.

From forum: abdera-dev

[jira] Created: (ABDERA-249) Abdera fails to completely read streams using GZIP compression

2009-10-19T13:22:59Z

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.

From forum: abdera-dev

[jira] Updated: (ABDERA-232) build - i18n pom missing commons-codec dependency

2009-10-12T07:57:31Z

[ 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.

From forum: abdera-dev

[jira] Commented: (ABDERA-248) MediaResponseContext#writeTo fails to close input stream after writing

2009-09-11T01:57:57Z

[ 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.

From forum: abdera-dev

[jira] Commented: (ABDERA-248) MediaResponseContext#writeTo fails to close input stream after writing

2009-09-11T01:53:58Z

[ 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.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

From forum: abdera-dev

[jira] Commented: (ABDERA-248) MediaResponseContext#writeTo fails to close input stream after writing

2009-09-11T01:45:57Z

[ 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.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

From forum: abdera-dev

[jira] Created: (ABDERA-248) MediaResponseContext#writeTo fails to close input stream after writing

2009-09-11T01:39:57Z

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.

From forum: abdera-dev

Testing my Abdera Code

2009-09-10T13:42:40Z

Hello,

I need some advise on how to test my web service layer please. If it were a Spring MVC application, for instance, I would have been able to use Controller.handleRequest(mockWebServletRequest) for example. How would I go about doing the same thing but using an Abdera server?

Thank you,
Sammy

From forum: abdera-user

[jira] Created: (ABDERA-247) 位置问题

2009-08-24T19:51:59Z

位置问题
----

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.

From forum: abdera-dev

[jira] Updated: (ABDERA-246) Abdera 1.0 (tag abdera-1.0) does not compile with java jdk 1.6.0_012

2009-08-18T01:45:14Z

[ 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.

From forum: abdera-dev

[jira] Created: (ABDERA-246) Abdera 1.0 (tag abdera-1.0) does not compile with java jdk 1.6.0_012

2009-08-18T01:43:15Z

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.

From forum: abdera-dev

[jira] Closed: (ABDERA-245) Testcases faking TaskTrackerManager might result into NPE

2009-08-12T22:05:14Z

[ 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.

From forum: abdera-dev

[jira] Closed: (ABDERA-244) JobInProgress.initTasks() should not throw KillInterruptedException

2009-08-12T22:01:14Z

[ 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.

From forum: abdera-dev

[jira] Created: (ABDERA-245) Testcases faking TaskTrackerManager might result into NPE

2009-08-12T22:01:14Z

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.

From forum: abdera-dev

[jira] Created: (ABDERA-244) JobInProgress.initTasks() should not throw KillInterruptedException

2009-08-12T21:57:14Z

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.

From forum: abdera-dev

Futures

2009-07-20T09:08:45Z

Hey All,

I wanted to let you know that due to a variety of changes in day job
activities and just regular everyday life stuff, I simply have not had
the time to devote the attention necessary to Abdera. First, on the day
job front, I have recently shifted focus at IBM away from social
networking and syndication technologies and am moving into security
technologies. On the personal front, my wife has recently become a full
time student again meaning most of the extra time I had been devoting to
work on things like Abdera is now being taken up by making sure our
three kids are leaving mom alone so she can study. Unfortunately, it
appears that the other main committers have also had life get in the way
of helping to move things forward so I would like to invite others who
have an interest in this project moving forward to please step up and
volunteer to help keep things moving forward.

- James

From forum: abdera-dev

[jira] Created: (ABDERA-243) Extra characters generated for entities in XHTML

2009-06-16T11:15:07Z

Extra characters generated for entities in XHTML
------------------------------------------------

Key: ABDERA-243
URL: https://issues.apache.org/jira/browse/ABDERA-243
Project: Abdera
Issue Type: Bug
Affects Versions: 0.4.0
Environment: Windows XP
Reporter: Jon Hewitt

Run the following program. Note that the entities (Ȁ ȁ) are translated to the correct characters but an additional character (the euro sign and '?') follows each correct character:

Output:

<p xmlns="http://www.w3.org/2005/Atom">This is simple XHTML È€È? contained within a xhtml:div tag.</p>

import java.io.ByteArrayInputStream;
import java.io.InputStream;

import org.apache.abdera.Abdera;
import org.apache.abdera.model.Document;
import org.apache.abdera.model.Entry;

public class Parser {

public static void main(String args[]) {

try {
String atomText = "<entry xmlns=\"http://www.w3.org/2005/Atom\"> "
+ " <title>Item</title> "
+ " <content type=\"xhtml\" xmlns:xhtml = \"http://www.w3.org/1999/xhtml\" > "
+ " <xhtml:div> "
+ " <p>This is simple XHTML Ȁȁ contained within a xhtml:div tag.</p> "
+ " </xhtml:div> " + " </content> " + "</entry>";

InputStream is = new ByteArrayInputStream(atomText.getBytes("UTF-8"));

Document<Entry> entryDocument = Abdera.getNewParser().parse(is);
Entry entry = entryDocument.getRoot();

System.out.println(entry.getContent());

} catch (Throwable t) {
t.printStackTrace();
}
}
}

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

From forum: abdera-dev

Abdera 1.0 from branch or trunk?

2009-06-08T12:04:03Z

Ok, so here's the thing, we have an Abdera 1.0 branch that was voted on
months ago, and we have a trunk that has a bunch of bug fixes, etc that
are valuable. There are additional changes that I'm planning to make to
reduce the number of areas where the discover code is being used (where
it's not adding any real value currently). I'm wondering if we should
hold off on the 1.0 cut for a couple of weeks, make the additional
changes and bug fixes to the trunk and redo the vote for 1.0 based on
the current trunk. That, I believe, would provide us with a much more
solid release. Whatcha think?

- James

From forum: abdera-dev

[jira] Resolved: (ABDERA-236) Create OSGi Bundles for Abdera using the Maven Felix plugin

2009-06-08T02:36:07Z

[ https://issues.apache.org/jira/browse/ABDERA-236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ugo Cei resolved ABDERA-236.
----------------------------

Resolution: Fixed

Patch applied, thanks

> Create OSGi Bundles for Abdera using the Maven Felix plugin
> -----------------------------------------------------------
>
> Key: ABDERA-236
> URL: https://issues.apache.org/jira/browse/ABDERA-236
> Project: Abdera
> Issue Type: Improvement
> Affects Versions: 1.0
> Reporter: Lars Trieloff
> Attachments: ABDERA-236.patch
>
>
> As per http://mail-archives.apache.org/mod_mbox/abdera-user/200803.mbox/%3c47EA93F9.507@...%3e I am not the only one looking to use Abdera inside an OSGi container. Creating bundles right away would ease the development process for many of Abdera's users.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

From forum: abdera-dev

[jira] Updated: (ABDERA-242) Failing to convert some big capital letters from HTML escape characters to UTF-8

2009-06-05T01:18:07Z

[ https://issues.apache.org/jira/browse/ABDERA-242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Magnus Korvald updated ABDERA-242:
----------------------------------

Description:
We have encountered something that probably is a bug in the "org.apache.abdera.model.Entry" module. When using the function "setSummaryAsXhtml" <URL: http://abdera.apache.org/docs/api/org/apache/abdera/model/Entry.html#setSummaryAsXhtml(java.lang.String) > it replaces the HTML escape characters for the big capital letters ÆØÅ with small capital letters in UTF-8 encoding.

|| HTML escape character || Is converted to || Should be ||
| Æ | æ | Æ |
| Ø | ø | Ø |
| Å | å | Å |
| æ | æ | æ |
| ø | ø | ø |
| å | å | å |

I've included the small capital letters in the table, just so that it might be a little more informative.

was:
We have encountered something that probably is a bug in the "org.apache.abdera.model.Entry" module. When using the function [setSummaryAsXhtml|http://abdera.apache.org/docs/api/org/apache/abdera/model/Entry.html#setSummaryAsXhtml(java.lang.String)] it replaces the HTML escape characters for the big capital letters ÆØÅ with small capital letters in UTF-8 encoding.

|| HTML escape character || Is converted to || Should be ||
| Æ | æ | Æ |
| Ø | ø | Ø |
| Å | å | Å |
| æ | æ | æ |
| ø | ø | ø |
| å | å | å |

I've included the small capital letters in the table, just so that it might be a little more informative.

> Failing to convert some big capital letters from HTML escape characters to UTF-8
> --------------------------------------------------------------------------------
>
> Key: ABDERA-242
> URL: https://issues.apache.org/jira/browse/ABDERA-242
> Project: Abdera
> Issue Type: Bug
> Affects Versions: 0.4.0
> Reporter: Magnus Korvald
> Fix For: 1.0
>
>
> We have encountered something that probably is a bug in the "org.apache.abdera.model.Entry" module. When using the function "setSummaryAsXhtml" <URL: http://abdera.apache.org/docs/api/org/apache/abdera/model/Entry.html#setSummaryAsXhtml(java.lang.String) > it replaces the HTML escape characters for the big capital letters ÆØÅ with small capital letters in UTF-8 encoding.
> || HTML escape character || Is converted to || Should be ||
> | Æ | æ | Æ |
> | Ø | ø | Ø |
> | Å | å | Å |
> | æ | æ | æ |
> | ø | ø | ø |
> | å | å | å |
> I've included the small capital letters in the table, just so that it might be a little more informative.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

From forum: abdera-dev

[jira] Created: (ABDERA-242) Failing to convert some big capital letters from HTML escape characters to UTF-8

2009-06-05T01:14:07Z

Failing to convert some big capital letters from HTML escape characters to UTF-8
--------------------------------------------------------------------------------

Key: ABDERA-242
URL: https://issues.apache.org/jira/browse/ABDERA-242
Project: Abdera
Issue Type: Bug
Affects Versions: 0.4.0
Reporter: Magnus Korvald
Fix For: 1.0

We have encountered something that probably is a bug in the "org.apache.abdera.model.Entry" module. When using the function [setSummaryAsXhtml|http://abdera.apache.org/docs/api/org/apache/abdera/model/Entry.html#setSummaryAsXhtml(java.lang.String)] it replaces the HTML escape characters for the big capital letters ÆØÅ with small capital letters in UTF-8 encoding.

|| HTML escape character || Is converted to || Should be ||
| Æ | æ | Æ |
| Ø | ø | Ø |
| Å | å | Å |
| æ | æ | æ |
| ø | ø | ø |
| å | å | å |

I've included the small capital letters in the table, just so that it might be a little more informative.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

From forum: abdera-dev

[jira] Created: (ABDERA-241) predicate pushdown is not handling exprFieldNodeDesc correctly

2009-06-04T18:57:07Z

predicate pushdown is not handling exprFieldNodeDesc correctly
--------------------------------------------------------------

Key: ABDERA-241
URL: https://issues.apache.org/jira/browse/ABDERA-241
Project: Abdera
Issue Type: Bug
Affects Versions: 0.4.0
Reporter: Prasad Chakka

ClassCastException is being thrown on complex column predicates.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

From forum: abdera-dev

[jira] Closed: (ABDERA-241) predicate pushdown is not handling exprFieldNodeDesc correctly

2009-06-04T18:57:07Z

[ https://issues.apache.org/jira/browse/ABDERA-241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Prasad Chakka closed ABDERA-241.
--------------------------------

Resolution: Invalid

sorry, opened in wrong project.

> predicate pushdown is not handling exprFieldNodeDesc correctly
> --------------------------------------------------------------
>
> Key: ABDERA-241
> URL: https://issues.apache.org/jira/browse/ABDERA-241
> Project: Abdera
> Issue Type: Bug
> Affects Versions: 0.4.0
> Reporter: Prasad Chakka
>
> ClassCastException is being thrown on complex column predicates.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

From forum: abdera-dev

a good webiste :www.electrondiscountshop.com

2009-06-04T07:33:15Z

Dear friend:
how are you doing lately?i would like to introduce a good company who trades
mainly in electornic products. such as motorcycles, laptops, mobile phones,
digial cameras, LCD TV, x box, PS3, GPS, MP3 / 4, etc.
Now the company is under sales promotion,all the products are sold nearly at
its cost.
They provide the best service and original products of
good quality, moreover ,the price is a surprising happiness to you!
It is realy a good chance for shopping.just grasp the opportunity,Now or
never!
http://www.electrondiscountshop.com/

From forum: abdera-user

a good webiste :www.electrondiscountshop.com

2009-06-04T07:33:15Z

From forum: abdera-dev

[jira] Closed: (ABDERA-240) crashing

2009-06-03T02:26:07Z

[ https://issues.apache.org/jira/browse/ABDERA-240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

nishapandith closed ABDERA-240.
-------------------------------

Resolution: Invalid

> crashing
> --------
>
> Key: ABDERA-240
> URL: https://issues.apache.org/jira/browse/ABDERA-240
> Project: Abdera
> Issue Type: Bug
> Affects Versions: 1.0
> Environment: Windows Xp
> Reporter: nishapandith
> Priority: Blocker
> Fix For: 1.0
>
> Original Estimate: 48h
> Remaining Estimate: 48h
>

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

From forum: abdera-dev

[jira] Created: (ABDERA-240) crashing

2009-06-03T02:24:07Z

crashing
--------

Key: ABDERA-240
URL: https://issues.apache.org/jira/browse/ABDERA-240
Project: Abdera
Issue Type: Bug
Affects Versions: 1.0
Environment: Windows Xp
Reporter: nishapandith
Priority: Blocker
Fix For: 1.0

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

From forum: abdera-dev

[jira] Commented: (ABDERA-236) Create OSGi Bundles for Abdera using the Maven Felix plugin

2009-06-03T00:56:07Z

[ https://issues.apache.org/jira/browse/ABDERA-236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12715855#action_12715855 ]

Lars Trieloff commented on ABDERA-236:
--------------------------------------

No, the bundle packaging will create jars with an additional META-INF+OSGi information. So it is just a little more than the usual JAR files that gets created.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

From forum: abdera-dev

[jira] Commented: (ABDERA-236) Create OSGi Bundles for Abdera using the Maven Felix plugin

2009-06-03T00:40:07Z

[ https://issues.apache.org/jira/browse/ABDERA-236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12715851#action_12715851 ]

Ugo Cei commented on ABDERA-236:
--------------------------------

Pardon my complete lack of knowledge about OSGi matters, but would the following:

- <packaging>jar</packaging>
+ <packaging>bundle</packaging>

imply that JARs are not created anymore? I guess not.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

From forum: abdera-dev

[jira] Created: (ABDERA-239) Unable to set writer implementation via abdera.properties

2009-06-02T14:15:07Z

Unable to set writer implementation via abdera.properties
---------------------------------------------------------

Key: ABDERA-239
URL: https://issues.apache.org/jira/browse/ABDERA-239
Project: Abdera
Issue Type: Bug
Affects Versions: 0.4.0
Reporter: Clayton Coleman

We are trying to override the implementation of StreamWriter used by Abdera. The documentation recommends defining an abdera.properties file in the root classloader and adding the following key/value pair:

org.apache.abdera.writer.StreamWriter=org.apache.abdera.parser.stax.StaxStreamWriter

However, even when this is specified, the following snippet from org/apache/abdera/util/ServiceUtil.java appears to be doing the wrong thing:

@SuppressWarnings("unchecked")
private static Object checkAbderaConfiguration(String id, Abdera abdera) {
String s = abdera.getConfiguration().getConfigurationOption(id);
return (s != null) ? locateInstance(getClassLoader(), id, abdera) : null;
}

The value of s for id="org.apache.abdera.writer.StreamWriter" is "org.apache.abdera.parser.stax.StaxStreamWriter", but s is never used inside this method. Should the last line read:

return (s != null) ? locateInstance(getClassLoader(), s, abdera) : null;

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

From forum: abdera-dev

Re: Adding a prefix to the Feed element

2009-06-02T01:46:25Z

Never mind :)

I used the ExtensionElement, I just hadn't it declared properly.

Thanks

rebels_mascot wrote:

Hey,

I'm looking for a way to add a prefix to the Feed element, e.g. <foo:feed>
I initialize the Feed using abdera.getFactory.newFeed() but I can't see how I can add a QName besides creating a new element or extension element.

I'm a fairly new to abdera so any help would be appreciated.

Thanks,
Brian

From forum: abdera-user