Thanks again Jesse for looking into this. WINK-149-new-part2.patch has the modification to wink-common/src/main/resources/META-INF/core/wink-providers towards the end of the patch file. But as you suggest, this modification to wink-providers file should definitely be removed.
Regarding committing the provider without updating the wink-providers file, I am concerned about the way users might add it to the list of providers. In WINK-149-new-part2.patch, if you observe the modification I have made to wink-providers file, you will see that this new provider comes before JAXB & Atom providers, thereby giving more preference to JAXB & Atom providers than this new provider. (I realized this by reading the comments at the top of wink-providers file, where it says "# 3. Order of the providers. The later provider was added, the higher priority it has." ). If by mistake, users add it in such a way that this new provider has higher priority than Atom provider, then I see that many of the unit tests fail! hinting the mess up that this new provider has caused. (And I am sorry, I should have mentioned about this before itself.) So I strongly feel that we drop the idea of adding this new provider and request the users to explicitly handle the mapping. Hence I request that only the following patches be committed: * WINK-149-new-part1.patch * WINK-149-new-part3.patch * WINK-149-new-part4.patch Thanks, Shiva Kumar H R On Mon, Apr 19, 2010 at 9:43 PM, Jesse A Ramos <[email protected]> wrote: > Hi Shiva, > > How about we go ahead and commit all your patches, making the provider > optional? I didn't see in any of your patches > wink-common/src/main/resources/META-INF/core/wink-providers being modified > (let me know if I missed it) which would have made the provider a system > provider. If we commit the provider but don't update the wink-providers > file, we avoid introducing the issue you raise by default but still make > the provider available to someone who may want to use it. > > -- Jesse > > > > > > From: > Shiva Kumar H R <[email protected]> > To: > [email protected] > Date: > 04/14/2010 09:55 AM > Subject: > Re: Map RSS to Syndication Object Model > > > > I again need some help here. I have added 4 patches for WINK-149 ( > https://issues.apache.org/jira/browse/WINK-149) : > > 1. WINK-149-new-part1.patch : adds the mapping from RSS to Syndication > Object Model and vice-versa. > 2. WINK-149-new-part2.patch : adds a new JAX-RS provider (which is where I > see a problem as explained below). > 3. WINK-149-new-part3.patch : adds a Junit testcase to test RSS to > SyndFeed > mapping and vice versa. > 4. WINK-149-new-part4.patch : adds a new client example in > \wink-examples\client\ReadRSS-client that demonstrates the RSS mapping > into > Syndication Object Model. > > In WINK-149-new-part2.patch, I have added a new JAX-RS Provider which > takes > an incoming text/xml or application/xml and converts it into SyndFeed. I > am > wondering if we really need this. The problem that I see is: RSS doesn't > have a special content-type header the way ATOM has > (application/atom+xml). > So all RSS docs will be served under the general content-type of > application/xml or text/xml. And sometimes even Atom docs could be served > under this same content type. > > So can't we request our Wink users to explicitly map the RssFeed into > SyndFeed, the way I have done in WINK-149-new-part4.patch which is as > below: > > // perform a GET on the resource. The resource will be > returned > as an Rss object > RssFeed rssFeed = > feedResource.accept(MediaType.APPLICATION_XML).get(RssFeed.class); > > // Map RSS into SyndFeed > SyndFeed syndFeed = new SyndFeed(); > syndFeed = rssFeed.toSynd(syndFeed); > > // Now access RSS using SyndFeed APIs > > The only advantage that I see when the new JAX-RS provider in > WINK-149-new-part2.patch is committed, is that the client code will look > as > below: > // perform a GET on the resource. The resource will be > returned > as an SyndFeed object > SyndFeed syndFeed = > feedResource.accept(MediaType.APPLICATION_XML).get(SyndFeed.class); > // Now access RSS using SyndFeed APIs > > Please suggest which approach we should follow (i.e. whether we must > commit > WINK-149-new-part2.patch or not). > > Thanks, > Shiva Kumar H R > > On Mon, Apr 12, 2010 at 7:22 PM, Shiva Kumar H R <[email protected]> > wrote: > > > I have uploaded new patches onto WINK-149 ( > > https://issues.apache.org/jira/browse/WINK-149) based on the initial > code > > developed by Jesse. > > > > The mapping is documented in > > > > http://cwiki.apache.org/confluence/display/WINK/Mapping+RSS+into+Syndication+Object+Model(the<http://cwiki.apache.org/confluence/display/WINK/Mapping+RSS+into+Syndication+Object+Model%28the> > wiki seems to be down now). > > > > Please commit the new patches. > > > > > > Thanks, > > Shiva Kumar H R > > > > On Tue, Mar 30, 2010 at 5:32 PM, Shiva Kumar H R > <[email protected]>wrote: > > > >> Hi Jesse, > >> I have created the following (temporary) wiki page for capturing this > >> mapping: > >> > >> > > http://cwiki.apache.org/confluence/display/WINK/Mapping+RSS+into+Syndication+Object+Model > > >> > >> And I am sorry, I haven't yet looked into the code. Will do that soon. > >> > >> > >> Thanks, > >> Shiva Kumar H R > >> > >> On Tue, Mar 23, 2010 at 9:10 PM, Jesse A Ramos <[email protected]> > wrote: > >> > >>> I've uploaded a patch with my changes to JIRA WINK-149 ( > >>> https://issues.apache.org/jira/browse/WINK-149). > >>> > >>> I wanted to give folks an opportunity to review this before I > committed > >>> as > >>> I wasn't sure if I did the mappings 100% correctly. In addition to the > >>> question below, there were a few other areas that I wasn't sure about. > >>> > >>> Here is how I mapped things from the syndication Object model to the > RSS > >>> model: > >>> > >>> SyndFeed --> RssFeed/RssChannel (Mapping a SyndFeed to an RssFeed > results > >>> in an RssFeed with version 2.0. The attribute mapping is done in > >>> RssChannel) > >>> ------------------------------------------------------ > >>> SyndFeed.base --> RssChannel.link > >>> SyndFeed.generator --> RssChannel.generator > >>> SyndFeed.icon --> RssChannel.image > >>> SyndFeed.lang --> RssChannel.language > >>> SyndFeed.rights --> RssChannel.copyright > >>> SyndFeed.title --> RssChannel.title > >>> SyndFeed.entries/SyndFeed.links --> RssChannel.items > >>> > >>> SyndEntry --> RssItem > >>> --------------------------------- > >>> SyndEntry.authors (first item) --> RssItem.author > >>> SyndEntry.base --> RssItem.link > >>> SyndEntry.published --> RssItem.pubDate > >>> SyndEntry.title --> RssItem.title > >>> SyndEntry.summary --> RssItem.description > >>> SyndEntry.id --> RssItem.guid > >>> > >>> SyndLink --> RssItem > >>> -------------------------------- > >>> SyndLink.title --> RssItem.title > >>> SyndLink.base --> RssItem.link > >>> > >>> SyndCategory --> RssCategory > >>> ----------------------------------------------- > >>> SyndCategory.term --> RssCategory.domain > >>> SyndCategory.label --> RssCategory.content > >>> > >>> Anything not listed here was not mapped. Any feedback/corrections are > >>> greatly appreciated. > >>> > >>> > >>> > >>> From: > >>> Jesse A Ramos/Austin/i...@ibmus > >>> To: > >>> [email protected] > >>> Date: > >>> 03/22/2010 11:08 AM > >>> Subject: > >>> Re: Map RSS to Syndication Object Model > >>> > >>> > >>> > >>> I went ahead and starting working on this. > >>> > >>> I have a question regarding the mapping of links in a SyndFeed. Would > >>> these map to RssItems? Currently I'm mapping SyndEnty's to RssItems > but > >>> wasn't sure if I should do the same for links. > >>> > >>> Thanks for the clarification. I'll post what I've mapped on the > >>> syndication side to the RSS side as there are other items I'm not 100% > >>> sure about when I'm done just to make sure that it's correct. > >>> > >>> -- Jesse > >>> > >>> > >>> > >>> > >>> From: > >>> Shiva Kumar H R <[email protected]> > >>> To: > >>> [email protected] > >>> Date: > >>> 03/18/2010 08:18 PM > >>> Subject: > >>> Re: Map RSS to Syndication Object Model > >>> > >>> > >>> > >>> Many thanks Jesse. I will look further into this. > >>> > >>> Thanks, > >>> Shiva Kumar H R > >>> > >>> On Thu, Mar 18, 2010 at 8:02 PM, Jesse A Ramos <[email protected]> > >>> wrote: > >>> > >>> > Hi Shiva, > >>> > > >>> > I took a look at this yesterday to see if I could figure out what > >>> needed > >>> > to be done. This is what I found. > >>> > > >>> > In org.apache.wink.common.model.atom the ATOM Object model classes > have > >>> > constructors that accept the Objects from > >>> > org.apache.wink.common.model.synd (ex: the constructor > >>> AtomFeed(SyndFeed)) > >>> > which allow the syndication Objects to be converted to ATOM Objects. > >>> > Similarly, there are adapter classes under > >>> > org.apache.wink.server.internal.entity.html that allow a conversion > to > >>> > html. > >>> > > >>> > Additionally, there are provides (AtomFeedSyndFeedProvider, > >>> > AtomEntrySyndEntryProvider, HtmlSyndFeedProvider, and > >>> > HtmlSyndEntryProvider) which allow syndication Objects to be > serialized > >>> to > >>> > those other formats and which make use of the adapters. > >>> > > >>> > I believe that the JIRA was created to add similar support to the > RSS > >>> > Object model. > >>> > > >>> > -- Jesse > >>> > > >>> > >I need some help in resolving JIRA > >>> > >https://issues.apache.org/jira/browse/WINK-149 "Map RSS to > >>> Syndication > >>> > >Object Model". I had opened this JIRA after a suggestion on dev > list. > >>> > >However I must acknowledge that I never understood the > need/importance > >>> of > >>> > >this. > >>> > > > >>> > >Can someone help me by throwing some light on this? What is > expected > >>> and > >>> > how > >>> > >would that be useful? > >>> > > > >>> > >Thanks, > >>> > >Shiva Kumar H R > >>> > > >>> > > >>> > > >>> > >>> > >>> > >>> > >>> > >> > > > > >
