Hi Brad
Hi Sergey,
the media type issue is a bit strange but I've worked around it with a
simple subclass of the CXF ATOM provider which only produces atom+xml.
Cool, I think it narrows a problem a bit.
Regarding the html thing, its actually not associated with the feed.
What we require is something that can produce a html rendering of our
data object. The idea is that a given service can produce xml, json or
html from the same RESTful URL. The HTML view is for clients coming
off the feed which we indicate with a query param. Maybe I can add an
application specific provider to handle this. that should be all our
requirements covered then.....just in time for the weekend!
Perhaps the application-specific provider will do, but I'm thinking perhaps it
would be worth
adding a stock provider which will handle response objects of type (jaxp)Source
and then applying a stylesheet
to it (configured through Spring for ex), again using a JAXP api. With XSLT, it's a good idea to have presentational aspects
seperated in a different input source document, so then a stylesheet can take two input documents in (one is the presentation one
which has special tags/hints to the stylesheet indicating where the various bits of the actual content should go) and another one
(the content one) returned from an application code...
Cheers, Sergey
Thanks,
Brad.
On Fri, Jun 20, 2008 at 12:56 PM, Sergey Beryozkin
<[EMAIL PROTECTED]> wrote:
Hi Brad
I'm not sure why application/json ends up being the media type passed to the
provider. I'll have a look these weekends...There's likely to be some flaw
in the way media types are matched on the outbound chain, it might've been
already fixed in my private snapshot. Perhaps setting an explictit Accept :
application/atom+xml might help
About xhtml. Aport from updating the actual Atpm provider to handle
application/xhtml+xml, another possibility is to deal with the
application/atom+xml only but in your code, where you create the feed, you
can add a feed/content element with the type "xhtml" and the Atom-aware
browser will display it even if the content type of the response will be
application/atom+xml
Cheers, Sergey
Sergey,
the accept header is */*. I'm setting the media type on the response
with builder.type("application/atom+xml");. Is it intended for the
media type set in a Response to reach the provider or does it get a
different one based on the request headers?
Will try the abdera tip and see if that helps..
Thanks,
Brad.
On Thu, Jun 19, 2008 at 5:08 PM, Sergey Beryozkin
<[EMAIL PROTECTED]> wrote:
Hi,
Try creating entry first and then adding it to the feed. It might be
worth
trying to do it in a simple mainline code and then try to
use Abdera to (de)serialize the feed you just created...
About the other problem you're seeing...
What is the Accept header's value ? Does it contain application/json by
any
chance ?
Cheers, Sergey
Ok I just tried submitting the same URL straight from TCPMon (cURL
didn't like the & in the query string for some reason). The request
was only performed once and this time it didn't hide the root cause:
INFO: Interceptor has thrown exception, unwinding now
org.apache.abdera.parser.stax.FOMException:
Looks like I've not populated my Feed object correctly.
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
