resteasy-developers — The main list for RESTEasy developers to discuss project development

Re: [Resteasy-developers] Possible build issues

[Bill B. <bb...@re...>]

So it looks like master got corrupted with 2.3.5 pom references.  Ok, I 
can fix that.

On 10/19/2012 12:25 PM, Weinan Li wrote:
> Hi Daniel,
>
> Thanks for catching these bugs! Could you please help to create pull
> request for this commit so that Bill could merge into trunk? Thanks!
>
> --
> Weinan Li
> JBoss, Red Hat
>
> On Friday, October 19, 2012 at 6:04 PM, Daniel Bevenius wrote:
>
>> Hi All,
>>
>> After update my fork today and saw a few build errors (you might have
>> to clear out 'org/jboss/resteasy' in your local maven repository to
>> get these which might be that these have done unnoticed),
>>
>> I've pushed the changes that I had to make to this branch:
>> https://github.com/danbev/Resteasy/commit/4bda688193efebe265c2712736e8695da7c36ed2
>>
>> If anyone could confirm that this happens to them too that would be
>> great, and if this is something local to my environment I'm sorry for
>> the noise.
>>
>> Thanks,
>>
>> /Daniel
>>
>> ------------------------------------------------------------------------------
>> Everyone hates slow websites. So do we.
>> Make your web apps faster with AppDynamics
>> Download AppDynamics Lite for free today:
>> http://p.sf.net/sfu/appdyn_sfd2d_oct
>> _______________________________________________
>> Resteasy-developers mailing list
>> Res...@li...
>> <mailto:Res...@li...>
>> https://lists.sourceforge.net/lists/listinfo/resteasy-developers
>
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct
>
>
>
> _______________________________________________
> Resteasy-developers mailing list
> Res...@li...
> https://lists.sourceforge.net/lists/listinfo/resteasy-developers
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

Re: [Resteasy-developers] Possible build issues

[Weinan L. <we...@re...>]

Hi Daniel, 

Thanks for catching these bugs! Could you please help to create pull request for this commit so that Bill could merge into trunk? Thanks! 

-- 
Weinan Li
JBoss, Red Hat


On Friday, October 19, 2012 at 6:04 PM, Daniel Bevenius wrote:

> Hi All,
> 
> After update my fork today and saw a few build errors (you might have
> to clear out 'org/jboss/resteasy' in your local maven repository to
> get these which might be that these have done unnoticed),
> 
> I've pushed the changes that I had to make to this branch:
> https://github.com/danbev/Resteasy/commit/4bda688193efebe265c2712736e8695da7c36ed2
> 
> If anyone could confirm that this happens to them too that would be
> great, and if this is something local to my environment I'm sorry for
> the noise.
> 
> Thanks,
> 
> /Daniel
> 
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct
> _______________________________________________
> Resteasy-developers mailing list
> Res...@li... (mailto:Res...@li...)
> https://lists.sourceforge.net/lists/listinfo/resteasy-developers
> 
> 

[Resteasy-developers] Possible build issues

[Daniel B. <dan...@gm...>]

Hi All,

After update my fork today and saw a few build errors (you might have
to clear out 'org/jboss/resteasy' in your local maven repository to
get these which might be that these have done unnoticed),

I've pushed the changes that I had to make to this branch:
https://github.com/danbev/Resteasy/commit/4bda688193efebe265c2712736e8695da7c36ed2

If anyone could confirm that this happens to them too that would be
great, and if this is something local to my environment I'm sorry for
the noise.

Thanks,

/Daniel

Re: [Resteasy-developers] Another JAXB problem related to Atom on AS .0.2/7.1.1

[Jervis L. <jl...@re...>]

On 2012/10/19 0:49, Weinan Li wrote:
> Hi Jervis,
>
> I've updated 'try-resteasy' and added two new classes:
>
> GuvnorAtomProcessor
> GuvnorDecorators
>
> Please also check EntryResource.createAssetFromAtom6().
>
> I've added @GuvnorDecorators to the method above.
>
> Could you please start up the server and try to run ClientTest? I 
> believe this patch has solved your problem. If there are any issues 
> please let me know.
>
>
Hi Weinan, the patch works like a charm. Thanks for all the helps!

Cheers,
Jervis
>
> -- 
> Weinan Li
> JBoss, Red Hat
>

Re: [Resteasy-developers] Another JAXB problem related to Atom on AS .0.2/7.1.1

[Weinan L. <we...@re...>]

Hi Jervis,  

I've updated 'try-resteasy' and added two new classes:

GuvnorAtomProcessor
GuvnorDecorators

Please also check EntryResource.createAssetFromAtom6().

I've added @GuvnorDecorators to the method above.

Could you please start up the server and try to run ClientTest? I believe this patch has solved your problem. If there are any issues please let me know.



--  
Weinan Li
JBoss, Red Hat


On Wednesday, October 17, 2012 at 11:24 PM, Weinan Li wrote:

> The patch I provided to Jervis has fixed his issues in Guvnor. But during the process I've found some missing things in our AtomProvider:  
>  
> public class Link extends CommonAttributes {
> …
>    protected MediaType type;
>  
> }
>  
> In our Link class it contains MediaType, but MediaType hasn't been JAXB annotated, so it will cause marshal/unmarshal problems. I'll add this missing part, and sum up with the patch I provided to Jervis to create a monolith fix for this.
>  
>  
> --  
> Weinan Li
> JBoss, Red Hat
>  
>  
> On Wednesday, October 17, 2012 at 3:09 AM, Weinan Li wrote:
>  
> > Hi Jervis,
> >  
> > I believe I've fixed bug. Could you please help to verify it?  Here's the method:
> >  
> > Please update your try-resteasy:
> >  
> > git pull origin test-guvnor-jaxb
> >  
> > and then try  
> >  
> > http://127.0.0.1:8080/try-resteasy/resteasy/entry3
> > http://127.0.0.1:8080/try-resteasy/resteasy/entry4
> >  
> > Currently getAnyOtherJAXBObject(AtomAssetMetadata.class); works fine on my computer.
> >  
> > If it works for you also, you can replace Guvnor's Entry.getAnyOtherJAXBObject() with the contents I've attached in getAnyOtherJAXBObject.java. And I'll create a pull request with this patch to RESTEasy trunk.
> >  
> >  
> > --  
> > Weinan Li
> > JBoss, Red Hat
> >  
> >  
> > On Tuesday, October 16, 2012 at 12:56 AM, Weinan Li wrote:
> >  
> > > Hi Jervis,  
> > >  
> > > I've created a test case here: https://github.com/liweinan/try-resteasy/tree/test-guvnor-jaxb
> > >  
> > > Could you please checkout 'try-resteasy' and use branch 'test-guvnor-jaxb' to give it a try?
> > >  
> > > You can run the example like this:
> > >  
> > > git clone git://github.com/liweinan/try-resteasy.git (http://github.com/liweinan/try-resteasy.git)
> > > git checkout -b test-guvnor-jaxb origin/test-guvnor-jaxb  
> > > mvn jetty:run
> > >  
> > > Then you can access these two urls:
> > >  
> > > http://127.0.0.1:8080/try-resteasy/resteasy/entry
> > > http://127.0.0.1:8080/try-resteasy/resteasy/entry2
> > >  
> > > The first one is the XML generated by JAXB
> > > The second one is the XML you gave to me
> > >  
> > > Both can be marshalled by RESTEasy correctly. I've only fix one class in Guvnor's code:
> > >  
> > >  
> > > In "public class Link extends CommonAttributes", I've comment out the @XmlAttribute of MediaType:
> > >  
> > > // @XmlAttribute  
> > >  public MediaType getType() { return type; }
> > >  
> > > Seems the annotation is not used correctly.
> > >  
> > > Please tell me your test result.  
> > >  
> > >  
> > >  
> > > --  
> > > Weinan Li
> > > JBoss, Red Hat
> > >  
> > >  
> > > On Monday, October 15, 2012 at 4:50 PM, Jervis Liu wrote:
> > >  
> > > > On 2012/10/13 18:14, Weinan Li wrote:
> > > > > Hi Jervis,  
> > > > >  
> > > > > Sorry for the late reply. I've checked the trunk code in RESTEasy and it seems getJAXBObject could handle custom element properly:  
> > > > >  
> > > > > CustomerAtom cust = entry.getContent().getJAXBObject(CustomerAtom.class); Assert.assertEquals(cust.getName(), "bill");    
> > > > > Could you please check the example code "org.jboss.resteasy.test.providers.atom.ResourceTest" in 'providers/resteasy-atom'? I believe from RESTEasy 2.3.5 Final it could fulfil your requirement properly.
> > > > >  
> > > > No, I am afraid it does not work. Please note, what we are asking for is not to use extension element on Atom Entry's content element. but on Entry itself or Feed and any other elements that are valid to have extension element per spec : http://tools.ietf.org/html/rfc4287#section-6.4. eg., like sth this:
> > > >  
> > > >             AtomAssetMetadata assetMetadata = entry.getAnyOtherJAXBObject(AtomAssetMetadata.class);
> > > >  
> > > > I checked the Atom provider code on RESTEasy master branch. It does not work either.  
> > > >  
> > > >  
> > > > Thanks,
> > > > Jervis
> > > > >  
> > > > > --   
> > > > > Weinan Li
> > > > > JBoss, Red Hat
> > > > >  
> > > > >  
> > > > > On Tuesday, October 9, 2012 at 2:47 AM, Weinan Li wrote:
> > > > >  
> > > > > >  
> > > > > >  
> > > > > > --   
> > > > > > Weinan Li
> > > > > > JBoss, Red Hat
> > > > > >  
> > > > > >  
> > > > > > On Monday, October 8, 2012 at 10:14 PM, Jervis Liu wrote:
> > > > > >  
> > > > > > > On 2012/9/29 14:06, Weinan Li wrote:
> > > > > > > >  
> > > > > > > >  
> > > > > > > > --   
> > > > > > > > Weinan Li
> > > > > > > > JBoss, Red Hat
> > > > > > > >  
> > > > > > > >  
> > > > > > > > On Saturday, September 29, 2012 at 12:59 PM, Jervis Liu wrote:
> > > > > > > >  
> > > > > > > > > On 2012/9/27 20:29, Weinan Li wrote:
> > > > > > > > > > Hi Jervis,  
> > > > > > > > > >  
> > > > > > > > > > Seems Guvnor is using its own Atom encapsulation:  
> > > > > > > > > >  
> > > > > > > > > > import org.drools.guvnor.server.jaxrs.jaxb.AtomAssetMetadata;  
> > > > > > > > > > import org.drools.guvnor.server.jaxrs.providers.atom.Entry;
> > > > > > > > > >  
> > > > > > > > > >  
> > > > > > > > > >  
> > > > > > > > > >  
> > > > > > > > > >  
> > > > > > > > >  
> > > > > > > > > The Atom provider code was copied from RESTEasy.  
> > > > > > > > >  
> > > > > > > > >  
> > > > > > > > >  
> > > > > > > >  
> > > > > > > > AtomAssetMetadata is not copied from RESTEasy and implemented by Guvnor itself.
> > > > > > > >   
> > > > > > > > > This is because the RESTEasy version shipped with AS 7 does not have the Atom Provider.
> > > > > > > > >  
> > > > > > > > >  
> > > > > > > > >  
> > > > > > > >  
> > > > > > > >  
> > > > > > > >  
> > > > > > >  
> > > > > > > Hi, sorry for the confusion. The reason why we maintained our own copy of RESTEasy Atom provider is because the code that handles Atom extension is not available until 2.3.4.Final. The feature we are looking for is the capability to create and read Atom Extension element (http://tools.ietf.org/html/rfc4287#section-6.4). For example, below is how we add a custom extension to Atom using Abdera:
> > > > > > >  
> > > > > > > Abdera abdera = new Abdera();  
> > > > > > > Entry entry = abdera.newEntry();
> > > > > > > entry.setTitle("testCreatePackageFromAtom1");
> > > > > > > entry.setSummary("desc for testCreatePackageFromAtom");
> > > > > > > ExtensibleElement extension = entry.addExtension(new QName("",  
> > > > > > > "metadata"));
> > > > > > > ExtensibleElement childExtension = extension.addExtension(new  
> > > > > > > QName("", "categories"));
> > > > > > > childExtension.addSimpleExtension(new QName("", "value")),  
> > > > > > > "AssetPackageResourceTestCategory");
> > > > > > >  
> > > > > > > Basically we are looking for a similar way to add and read ATOM extension element using RESTEasy. Unfortunately methods likes getAnyOther, getAnyOtherJaxbObject etc were added into RESTEasy after 2.3.4.Final.  
> > > > > > >  
> > > > > > > The problem I reported in this email thread is regarding the code that handles extension element does not work properly (I am referring to our own copy of Atom provider code, which was copied from RESTEasy 2.3.4). To be more precisely, the problem is getAnyOtherJAXBObject returns null. I also verified the object returned by getAnyOther, yes, it is not null, but it is a ElementNSImpl object. I dont think you should expect RESTEasy users to retrieve a raw xml object using getAnyOther then marshall the raw xml to object using JAXB by themselves. This does not sound like a correct way to read Atom extension.  
> > > > > > >  
> > > > > > > I hope we can have explicit methods to read and create extension element on Entry, Feed and any other elements that are valid to have extension element per spec : http://tools.ietf.org/html/rfc4287#section-6.4. Eg, sth like Entry.addExentionElement(Object o) and Entry.getExtensionElemnt(), this API will be easier to understand than getAnyOther or getAnyOtherJaxbObject.  
> > > > > >  
> > > > > >  
> > > >  
> > >  
> > > ------------------------------------------------------------------------------
> > > Don't let slow site performance ruin your business. Deploy New Relic APM
> > > Deploy New Relic app performance management and know exactly
> > > what is happening inside your Ruby, Python, PHP, Java, and .NET app
> > > Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> > > http://p.sf.net/sfu/newrelic-dev2dev
> > >  
> > > _______________________________________________
> > > Resteasy-developers mailing list
> > > Res...@li... (mailto:Res...@li...)
> > > https://lists.sourceforge.net/lists/listinfo/resteasy-developers
> > >  
> > >  
> > >  
> >  
> >  
> > ------------------------------------------------------------------------------
> > Don't let slow site performance ruin your business. Deploy New Relic APM
> > Deploy New Relic app performance management and know exactly
> > what is happening inside your Ruby, Python, PHP, Java, and .NET app
> > Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> > http://p.sf.net/sfu/newrelic-dev2dev
> >  
> > _______________________________________________
> > Resteasy-developers mailing list
> > Res...@li... (mailto:Res...@li...)
> > https://lists.sourceforge.net/lists/listinfo/resteasy-developers
> >  
> >  
> >  
> >  
> > Attachments:  
> > - getAnyOtherJAXBObject.java
> >  
> >  
>  
>  
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct
>  
> _______________________________________________
> Resteasy-developers mailing list
> Res...@li... (mailto:Res...@li...)
> https://lists.sourceforge.net/lists/listinfo/resteasy-developers
>  
>  

Re: [Resteasy-developers] Another JAXB problem related to Atom on AS .0.2/7.1.1

[Weinan L. <we...@re...>]

The patch I provided to Jervis has fixed his issues in Guvnor. But during the process I've found some missing things in our AtomProvider:  

public class Link extends CommonAttributes {
…
   protected MediaType type;

}

In our Link class it contains MediaType, but MediaType hasn't been JAXB annotated, so it will cause marshal/unmarshal problems. I'll add this missing part, and sum up with the patch I provided to Jervis to create a monolith fix for this.


--  
Weinan Li
JBoss, Red Hat


On Wednesday, October 17, 2012 at 3:09 AM, Weinan Li wrote:

> Hi Jervis,
>  
> I believe I've fixed bug. Could you please help to verify it?  Here's the method:
>  
> Please update your try-resteasy:
>  
> git pull origin test-guvnor-jaxb
>  
> and then try  
>  
> http://127.0.0.1:8080/try-resteasy/resteasy/entry3
> http://127.0.0.1:8080/try-resteasy/resteasy/entry4
>  
> Currently getAnyOtherJAXBObject(AtomAssetMetadata.class); works fine on my computer.
>  
> If it works for you also, you can replace Guvnor's Entry.getAnyOtherJAXBObject() with the contents I've attached in getAnyOtherJAXBObject.java. And I'll create a pull request with this patch to RESTEasy trunk.
>  
>  
> --  
> Weinan Li
> JBoss, Red Hat
>  
>  
> On Tuesday, October 16, 2012 at 12:56 AM, Weinan Li wrote:
>  
> > Hi Jervis,  
> >  
> > I've created a test case here: https://github.com/liweinan/try-resteasy/tree/test-guvnor-jaxb
> >  
> > Could you please checkout 'try-resteasy' and use branch 'test-guvnor-jaxb' to give it a try?
> >  
> > You can run the example like this:
> >  
> > git clone git://github.com/liweinan/try-resteasy.git (http://github.com/liweinan/try-resteasy.git)
> > git checkout -b test-guvnor-jaxb origin/test-guvnor-jaxb  
> > mvn jetty:run
> >  
> > Then you can access these two urls:
> >  
> > http://127.0.0.1:8080/try-resteasy/resteasy/entry
> > http://127.0.0.1:8080/try-resteasy/resteasy/entry2
> >  
> > The first one is the XML generated by JAXB
> > The second one is the XML you gave to me
> >  
> > Both can be marshalled by RESTEasy correctly. I've only fix one class in Guvnor's code:
> >  
> >  
> > In "public class Link extends CommonAttributes", I've comment out the @XmlAttribute of MediaType:
> >  
> > // @XmlAttribute  
> >  public MediaType getType() { return type; }
> >  
> > Seems the annotation is not used correctly.
> >  
> > Please tell me your test result.  
> >  
> >  
> >  
> > --  
> > Weinan Li
> > JBoss, Red Hat
> >  
> >  
> > On Monday, October 15, 2012 at 4:50 PM, Jervis Liu wrote:
> >  
> > > On 2012/10/13 18:14, Weinan Li wrote:
> > > > Hi Jervis,  
> > > >  
> > > > Sorry for the late reply. I've checked the trunk code in RESTEasy and it seems getJAXBObject could handle custom element properly:  
> > > >  
> > > > CustomerAtom cust = entry.getContent().getJAXBObject(CustomerAtom.class); Assert.assertEquals(cust.getName(), "bill");    
> > > > Could you please check the example code "org.jboss.resteasy.test.providers.atom.ResourceTest" in 'providers/resteasy-atom'? I believe from RESTEasy 2.3.5 Final it could fulfil your requirement properly.
> > > >  
> > > No, I am afraid it does not work. Please note, what we are asking for is not to use extension element on Atom Entry's content element. but on Entry itself or Feed and any other elements that are valid to have extension element per spec : http://tools.ietf.org/html/rfc4287#section-6.4. eg., like sth this:
> > >  
> > >             AtomAssetMetadata assetMetadata = entry.getAnyOtherJAXBObject(AtomAssetMetadata.class);
> > >  
> > > I checked the Atom provider code on RESTEasy master branch. It does not work either.  
> > >  
> > >  
> > > Thanks,
> > > Jervis
> > > >  
> > > > --   
> > > > Weinan Li
> > > > JBoss, Red Hat
> > > >  
> > > >  
> > > > On Tuesday, October 9, 2012 at 2:47 AM, Weinan Li wrote:
> > > >  
> > > > >  
> > > > >  
> > > > > --   
> > > > > Weinan Li
> > > > > JBoss, Red Hat
> > > > >  
> > > > >  
> > > > > On Monday, October 8, 2012 at 10:14 PM, Jervis Liu wrote:
> > > > >  
> > > > > > On 2012/9/29 14:06, Weinan Li wrote:
> > > > > > >  
> > > > > > >  
> > > > > > > --   
> > > > > > > Weinan Li
> > > > > > > JBoss, Red Hat
> > > > > > >  
> > > > > > >  
> > > > > > > On Saturday, September 29, 2012 at 12:59 PM, Jervis Liu wrote:
> > > > > > >  
> > > > > > > > On 2012/9/27 20:29, Weinan Li wrote:
> > > > > > > > > Hi Jervis,  
> > > > > > > > >  
> > > > > > > > > Seems Guvnor is using its own Atom encapsulation:  
> > > > > > > > >  
> > > > > > > > > import org.drools.guvnor.server.jaxrs.jaxb.AtomAssetMetadata;  
> > > > > > > > > import org.drools.guvnor.server.jaxrs.providers.atom.Entry;
> > > > > > > > >  
> > > > > > > > >  
> > > > > > > > >  
> > > > > > > > >  
> > > > > > > > >  
> > > > > > > >  
> > > > > > > > The Atom provider code was copied from RESTEasy.  
> > > > > > > >  
> > > > > > > >  
> > > > > > > >  
> > > > > > >  
> > > > > > > AtomAssetMetadata is not copied from RESTEasy and implemented by Guvnor itself.
> > > > > > >   
> > > > > > > > This is because the RESTEasy version shipped with AS 7 does not have the Atom Provider.
> > > > > > > >  
> > > > > > > >  
> > > > > > > >  
> > > > > > >  
> > > > > > >  
> > > > > > >  
> > > > > >  
> > > > > > Hi, sorry for the confusion. The reason why we maintained our own copy of RESTEasy Atom provider is because the code that handles Atom extension is not available until 2.3.4.Final. The feature we are looking for is the capability to create and read Atom Extension element (http://tools.ietf.org/html/rfc4287#section-6.4). For example, below is how we add a custom extension to Atom using Abdera:
> > > > > >  
> > > > > > Abdera abdera = new Abdera();  
> > > > > > Entry entry = abdera.newEntry();
> > > > > > entry.setTitle("testCreatePackageFromAtom1");
> > > > > > entry.setSummary("desc for testCreatePackageFromAtom");
> > > > > > ExtensibleElement extension = entry.addExtension(new QName("",  
> > > > > > "metadata"));
> > > > > > ExtensibleElement childExtension = extension.addExtension(new  
> > > > > > QName("", "categories"));
> > > > > > childExtension.addSimpleExtension(new QName("", "value")),  
> > > > > > "AssetPackageResourceTestCategory");
> > > > > >  
> > > > > > Basically we are looking for a similar way to add and read ATOM extension element using RESTEasy. Unfortunately methods likes getAnyOther, getAnyOtherJaxbObject etc were added into RESTEasy after 2.3.4.Final.  
> > > > > >  
> > > > > > The problem I reported in this email thread is regarding the code that handles extension element does not work properly (I am referring to our own copy of Atom provider code, which was copied from RESTEasy 2.3.4). To be more precisely, the problem is getAnyOtherJAXBObject returns null. I also verified the object returned by getAnyOther, yes, it is not null, but it is a ElementNSImpl object. I dont think you should expect RESTEasy users to retrieve a raw xml object using getAnyOther then marshall the raw xml to object using JAXB by themselves. This does not sound like a correct way to read Atom extension.  
> > > > > >  
> > > > > > I hope we can have explicit methods to read and create extension element on Entry, Feed and any other elements that are valid to have extension element per spec : http://tools.ietf.org/html/rfc4287#section-6.4. Eg, sth like Entry.addExentionElement(Object o) and Entry.getExtensionElemnt(), this API will be easier to understand than getAnyOther or getAnyOtherJaxbObject.  
> > > > >  
> > > > >  
> > >  
> >  
> > ------------------------------------------------------------------------------
> > Don't let slow site performance ruin your business. Deploy New Relic APM
> > Deploy New Relic app performance management and know exactly
> > what is happening inside your Ruby, Python, PHP, Java, and .NET app
> > Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> > http://p.sf.net/sfu/newrelic-dev2dev
> >  
> > _______________________________________________
> > Resteasy-developers mailing list
> > Res...@li... (mailto:Res...@li...)
> > https://lists.sourceforge.net/lists/listinfo/resteasy-developers
> >  
> >  
> >  
>  
>  
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
>  
> _______________________________________________
> Resteasy-developers mailing list
> Res...@li... (mailto:Res...@li...)
> https://lists.sourceforge.net/lists/listinfo/resteasy-developers
>  
>  
>  
>  
> Attachments:  
> - getAnyOtherJAXBObject.java
>  

Re: [Resteasy-developers] RESTEASY-342: Enable JSONP support with Jackson JSON processor

[Bill B. <bb...@re...>]

You could probably do this Holger in a MessageBodyWriterInterceptor. 
Just write the JSONP function to the stream then hand off to the 
MessageBodyWriter (proceed()) then write the finishing touches to the 
output stream after proceed() finishes.  THen your interceptor would be 
independent of the json processor.

On 10/16/2012 6:55 AM, Heiko W.Rupp wrote:
> Hi,
>
> in RHQ I've implemented this as a Sevlet-Filter. See e.g.
>
> http://git.fedorahosted.org/cgit/rhq/rhq.git/tree/modules/enterprise/gui/rest-war/src/main/java/org/rhq/enterprise/rest/JsonPFilter.java
>
> While I don't think this is perfect, it could be a way to solve this independently of the json parser used
> as MessageBodyWriter
>
>
>
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
>
>
>
> _______________________________________________
> Resteasy-developers mailing list
> Res...@li...
> https://lists.sourceforge.net/lists/listinfo/resteasy-developers
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

Re: [Resteasy-developers] RESTEASY-342: Enable JSONP support with Jackson JSON processor

[Heiko W.R. <hr...@re...>]

Hi,

in RHQ I've implemented this as a Sevlet-Filter. See e.g. 

http://git.fedorahosted.org/cgit/rhq/rhq.git/tree/modules/enterprise/gui/rest-war/src/main/java/org/rhq/enterprise/rest/JsonPFilter.java

While I don't think this is perfect, it could be a way to solve this independently of the json parser used
as MessageBodyWriter

-- 
Reg. Adresse: Red Hat GmbH, Technopark II, Haus C, 
Werner-von-Siemens-Ring 14, D-85630 Grasbrunn
Handelsregister: Amtsgericht München HRB 153243
Geschaeftsführer:  Mark Hegarty, Charlie Peters, Michael Cunningham, Charles Cachera

Re: [Resteasy-developers] A couple of AS7 questions

[Weinan L. <we...@re...>]

-- 
Weinan Li
JBoss, Red Hat


On Tuesday, October 16, 2012 at 9:53 AM, Ron Sigal wrote:

> Hi Bill,
> 
> 1. What is our policy regarding keeping in sync with AS 7?

Stuart is taking care of sync issues for AS7 and I'm taking charge of the work in EAP6.
> I see branch 
> master on https://github.com/jbossas, with version 
> 7.2.0.Alpha1-SNAPSHOT, which specifies Resteasy version 2.3.3.Final.
> 
> 


The latest version in AS7 is 2.3.4.Final. 
> 
> Are we going to upgrade that to 2.3.5.Final? 
> 
> 


Yes, and after AS7 upgraded to 2.3.5.Final, I'll start the work on EAP6 :-)
 
> In particular, I'm asking 
> because of RESTEASY-758 "Upgrade Jackson from 1.8.5 to 1.9.9". If AS 
> 7.2 stays at Resteasy 2.3.3.Final, then I guess it doesn't matter which 
> version of Jackson we use. On the other hand, 7.2.0.Alpha1-SNAPSHOT 
> specifies Jackson version 1.9.2. On the other, other hand, I guess that 
> could change too. Do you have any insights into this situation? Or 
> should I ask Shelly McGowan or Martha Benitez or someone like that?
> 
> 


Fernando, could you please help to clarify this?
> 
> 2. With the changes from RESTEASY-722 "Fix HC4 buffering", 
> resteasy-jaxrs now depends on Apache
> 
> <dependency>
> <groupId>commons-io</groupId>
> <artifactId>commons-io</artifactId>
> </dependency>
> 
> I've added that to the pom, but, playing with AS 7 for RESTEASY-760 
> "@FormParam does not work with PUT method when a Query param is 
> present", I had to add commons-io to the dependencies list in 
> modules/org/jboss/resteasy/resteasy-jaxrs/main/modules.xml.
> 
> a. I haven't played much with AS 7. I just want to check that there 
> aren't any gotchas here.
> 
> b. I assume this addition has to be done through an "Application Server 
> 7" JIRA issue, right?
> 
> Thanks,
> Ron
> 
> -- 
> My company's smarter than your company (unless you work for Red Hat).
> 
> 
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
> _______________________________________________
> Resteasy-developers mailing list
> Res...@li... (mailto:Res...@li...)
> https://lists.sourceforge.net/lists/listinfo/resteasy-developers
> 
> 

Re: [Resteasy-developers] jbossweb question

[Ron S. <rs...@re...>]

Ok, I've put in the fix.

On 10/15/2012 03:29 PM, Bill Burke wrote:
> Err...PUT has meaning.  PUT + form parameters should be supported.
>
> On 10/15/2012 1:43 PM, Ron Sigal wrote:
>> My mistake.  I was using PUT when I thought I was using POST.  For POST,
>> jbossweb returns both the query and the form parameters.
>>
>> So, I guess the answer is:  USE POST.  FORGET PUT.  Is that reasonable?
>>
>> Or, I can include my fix that makes it work with PUT.  Bill, wdyt?
>>
>> Sorry for the confusion, Remy.  :(
>>
>> On 10/15/2012 01:25 PM, Ron Sigal wrote:
>>> On 10/15/2012 12:12 PM, Rémy Maucherat wrote:
>>>> On 10/15/2012 03:40 PM, Bill Burke wrote:
>>>>> Please move these types of discussions to the dev list.
>>>> Ok, but I am not subscribed to it.
>>> WHAT?!?!  I thought everyone was on the Resteasy dev list.  I'm pretty
>>> sure Francois Holland is on the list.  Also, Voltaire.  But not Marie Le
>>> Pen.  She's on the jersey dev list.  ;)
>>>
>>>>> But, for form processing, there's a few things you have to worry about.
>>>>>
>>>>> 1) Did a Servlet filter eat the input stream?  You'll need to use
>>>>> getParameterMap() then.
>>>>> 2) Is it a POST or PUT? If PUT, does getParameterMap() eat the form
>>>>> input stream or not?
>>>>> 3) If its Tomcat, a PUT, and the filter ate the input stream, you're
>>>>> up shit creek.
>>>> The spec is quite clear that it deals with URL encoded POSTs, so I
>>>> understand the real problems started when other containers thought it
>>>> would be nice to ignore specs and do what users asked for. So the
>>>> option to also process PUT should be added to AS then ?
>>> I'm not sure why the user wants to use PUT.  But I get the same problem
>>> with POST.  Here's my test, on the client side:
>>>
>>>        @Test
>>>        public void testFormParamWithQueryParamPost() throws Exception
>>>        {
>>>           ClientRequest request = new
>>> ClientRequest("http://localhost:8080/RESTEASY-760/post/query?query=xyz");
>>>           request.formParameter("formParam", "abc");
>>>           request.header("Content-Type", "application/x-www-form-urlencoded");
>>>           ClientResponse<String>   response = request.put(String.class);
>>>           assertTrue(response != null);
>>>           System.out.println("response: " + response.getEntity());
>>>           assertEquals("abc", response.getEntity());
>>>        }
>>>
>>> When Resteasy calls
>>> javax.servlet.http.HttpServletRequest..getParameterMap(), it gets
>>> query=xyz but not formParam=abc.   Maybe I'm doing something wrong?
>>>
>>>> Rémy
>>>>

-- 
My company's smarter than your company (unless you work for Red Hat).

[Resteasy-developers] A couple of AS7 questions

[Ron S. <rs...@re...>]

Hi Bill,

1. What is our policy regarding keeping in sync with AS 7?  I see branch 
master on https://github.com/jbossas, with version 
7.2.0.Alpha1-SNAPSHOT, which specifies Resteasy version 2.3.3.Final.  
Are we going to upgrade that to 2.3.5.Final?  In particular, I'm asking 
because of RESTEASY-758 "Upgrade Jackson from 1.8.5 to 1.9.9".  If AS 
7.2 stays at Resteasy 2.3.3.Final, then I guess it doesn't matter which 
version of Jackson we use.  On the other hand, 7.2.0.Alpha1-SNAPSHOT 
specifies Jackson version 1.9.2.  On the other, other hand, I guess that 
could change too.  Do you have any insights into this situation?  Or 
should I ask Shelly McGowan or Martha Benitez or someone like that?

2. With the changes from RESTEASY-722 "Fix HC4 buffering", 
resteasy-jaxrs now depends on Apache

<dependency>
<groupId>commons-io</groupId>
<artifactId>commons-io</artifactId>
</dependency>

I've added that to the pom, but, playing with AS 7 for RESTEASY-760 
"@FormParam does not work with PUT method when a Query param is 
present", I had to add commons-io to the dependencies list in 
modules/org/jboss/resteasy/resteasy-jaxrs/main/modules.xml.

a. I haven't played much with AS 7.  I just want to check that there 
aren't any gotchas here.

b. I assume this addition has to be done through an "Application Server 
7" JIRA issue, right?

Thanks,
Ron

-- 
My company's smarter than your company (unless you work for Red Hat).

Re: [Resteasy-developers] jbossweb question

[Bill B. <bb...@re...>]

Err...PUT has meaning.  PUT + form parameters should be supported.

On 10/15/2012 1:43 PM, Ron Sigal wrote:
> My mistake.  I was using PUT when I thought I was using POST.  For POST,
> jbossweb returns both the query and the form parameters.
>
> So, I guess the answer is:  USE POST.  FORGET PUT.  Is that reasonable?
>
> Or, I can include my fix that makes it work with PUT.  Bill, wdyt?
>
> Sorry for the confusion, Remy.  :(
>
> On 10/15/2012 01:25 PM, Ron Sigal wrote:
>>
>> On 10/15/2012 12:12 PM, Rémy Maucherat wrote:
>>> On 10/15/2012 03:40 PM, Bill Burke wrote:
>>>> Please move these types of discussions to the dev list.
>>> Ok, but I am not subscribed to it.
>> WHAT?!?!  I thought everyone was on the Resteasy dev list.  I'm pretty
>> sure Francois Holland is on the list.  Also, Voltaire.  But not Marie Le
>> Pen.  She's on the jersey dev list.  ;)
>>
>>>> But, for form processing, there's a few things you have to worry about.
>>>>
>>>> 1) Did a Servlet filter eat the input stream?  You'll need to use
>>>> getParameterMap() then.
>>>> 2) Is it a POST or PUT? If PUT, does getParameterMap() eat the form
>>>> input stream or not?
>>>> 3) If its Tomcat, a PUT, and the filter ate the input stream, you're
>>>> up shit creek.
>>> The spec is quite clear that it deals with URL encoded POSTs, so I
>>> understand the real problems started when other containers thought it
>>> would be nice to ignore specs and do what users asked for. So the
>>> option to also process PUT should be added to AS then ?
>> I'm not sure why the user wants to use PUT.  But I get the same problem
>> with POST.  Here's my test, on the client side:
>>
>>       @Test
>>       public void testFormParamWithQueryParamPost() throws Exception
>>       {
>>          ClientRequest request = new
>> ClientRequest("http://localhost:8080/RESTEASY-760/post/query?query=xyz");
>>          request.formParameter("formParam", "abc");
>>          request.header("Content-Type", "application/x-www-form-urlencoded");
>>          ClientResponse<String>  response = request.put(String.class);
>>          assertTrue(response != null);
>>          System.out.println("response: " + response.getEntity());
>>          assertEquals("abc", response.getEntity());
>>       }
>>
>> When Resteasy calls
>> javax.servlet.http.HttpServletRequest..getParameterMap(), it gets
>> query=xyz but not formParam=abc.   Maybe I'm doing something wrong?
>>
>>> Rémy
>>>
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

Re: [Resteasy-developers] jbossweb question

[Ron S. <rs...@re...>]

Ok, I see

> SRV.4.1.1
> When Parameters Are Available
> The following are the conditions that must be met before post form 
> data will
> be populated to the parameter set:
> 1. The request is an HTTP or HTTPS request.
> 2. The HTTP method is POST
> 3. The content type is application/x-www-form-urlencoded
> 4. The servlet has made an initial call of any of the getParameter 
> family of meth-
> ods on the request object.
> If the conditions are not met and the post form data is not included 
> in the
> parameter set, the post data must still be available to the servlet 
> via the request
> object’s input stream. If the conditions are met, post form data will 
> no longer be
> available for reading directly from the request object’s input stream.

in the Servlet spec. That seems to settle it.

Thanks, Remy.

On 10/15/2012 01:43 PM, Ron Sigal wrote:
> My mistake.  I was using PUT when I thought I was using POST.  For POST,
> jbossweb returns both the query and the form parameters.
>
> So, I guess the answer is:  USE POST.  FORGET PUT.  Is that reasonable?
>
> Or, I can include my fix that makes it work with PUT.  Bill, wdyt?
>
> Sorry for the confusion, Remy.  :(
>
> On 10/15/2012 01:25 PM, Ron Sigal wrote:
>> On 10/15/2012 12:12 PM, Rémy Maucherat wrote:
>>> On 10/15/2012 03:40 PM, Bill Burke wrote:
>>>> Please move these types of discussions to the dev list.
>>> Ok, but I am not subscribed to it.
>> WHAT?!?!  I thought everyone was on the Resteasy dev list.  I'm pretty
>> sure Francois Holland is on the list.  Also, Voltaire.  But not Marie Le
>> Pen.  She's on the jersey dev list.  ;)
>>
>>>> But, for form processing, there's a few things you have to worry about.
>>>>
>>>> 1) Did a Servlet filter eat the input stream?  You'll need to use
>>>> getParameterMap() then.
>>>> 2) Is it a POST or PUT? If PUT, does getParameterMap() eat the form
>>>> input stream or not?
>>>> 3) If its Tomcat, a PUT, and the filter ate the input stream, you're
>>>> up shit creek.
>>> The spec is quite clear that it deals with URL encoded POSTs, so I
>>> understand the real problems started when other containers thought it
>>> would be nice to ignore specs and do what users asked for. So the
>>> option to also process PUT should be added to AS then ?
>> I'm not sure why the user wants to use PUT.  But I get the same problem
>> with POST.  Here's my test, on the client side:
>>
>>       @Test
>>       public void testFormParamWithQueryParamPost() throws Exception
>>       {
>>          ClientRequest request = new
>> ClientRequest("http://localhost:8080/RESTEASY-760/post/query?query=xyz");
>>          request.formParameter("formParam", "abc");
>>          request.header("Content-Type", "application/x-www-form-urlencoded");
>>          ClientResponse<String>   response = request.put(String.class);
>>          assertTrue(response != null);
>>          System.out.println("response: " + response.getEntity());
>>          assertEquals("abc", response.getEntity());
>>       }
>>
>> When Resteasy calls
>> javax.servlet.http.HttpServletRequest..getParameterMap(), it gets
>> query=xyz but not formParam=abc.   Maybe I'm doing something wrong?
>>
>>> Rémy
>>>

-- 
My company's smarter than your company (unless you work for Red Hat).

Re: [Resteasy-developers] jbossweb question

[Ron S. <rs...@re...>]

My mistake.  I was using PUT when I thought I was using POST.  For POST, 
jbossweb returns both the query and the form parameters.

So, I guess the answer is:  USE POST.  FORGET PUT.  Is that reasonable?

Or, I can include my fix that makes it work with PUT.  Bill, wdyt?

Sorry for the confusion, Remy.  :(

On 10/15/2012 01:25 PM, Ron Sigal wrote:
>
> On 10/15/2012 12:12 PM, Rémy Maucherat wrote:
>> On 10/15/2012 03:40 PM, Bill Burke wrote:
>>> Please move these types of discussions to the dev list.
>> Ok, but I am not subscribed to it.
> WHAT?!?!  I thought everyone was on the Resteasy dev list.  I'm pretty
> sure Francois Holland is on the list.  Also, Voltaire.  But not Marie Le
> Pen.  She's on the jersey dev list.  ;)
>
>>> But, for form processing, there's a few things you have to worry about.
>>>
>>> 1) Did a Servlet filter eat the input stream?  You'll need to use
>>> getParameterMap() then.
>>> 2) Is it a POST or PUT? If PUT, does getParameterMap() eat the form
>>> input stream or not?
>>> 3) If its Tomcat, a PUT, and the filter ate the input stream, you're
>>> up shit creek.
>> The spec is quite clear that it deals with URL encoded POSTs, so I
>> understand the real problems started when other containers thought it
>> would be nice to ignore specs and do what users asked for. So the
>> option to also process PUT should be added to AS then ?
> I'm not sure why the user wants to use PUT.  But I get the same problem
> with POST.  Here's my test, on the client side:
>
>      @Test
>      public void testFormParamWithQueryParamPost() throws Exception
>      {
>         ClientRequest request = new
> ClientRequest("http://localhost:8080/RESTEASY-760/post/query?query=xyz");
>         request.formParameter("formParam", "abc");
>         request.header("Content-Type", "application/x-www-form-urlencoded");
>         ClientResponse<String>  response = request.put(String.class);
>         assertTrue(response != null);
>         System.out.println("response: " + response.getEntity());
>         assertEquals("abc", response.getEntity());
>      }
>
> When Resteasy calls
> javax.servlet.http.HttpServletRequest..getParameterMap(), it gets
> query=xyz but not formParam=abc.   Maybe I'm doing something wrong?
>
>> Rémy
>>

-- 
My company's smarter than your company (unless you work for Red Hat).

Re: [Resteasy-developers] jbossweb question

[Ron S. <rs...@re...>]

On 10/15/2012 01:21 PM, Rémy Maucherat wrote:
> On 10/15/2012 07:10 PM, Ron Sigal wrote:
>>
>>
>> On 10/15/2012 09:36 AM, Rémy Maucherat wrote:
>>>
>>> The web container only processes URL encoded POSTs, not any other 
>>> method (as per the spec).
>>
>> I get the same result, i.e., missing form parameters in 
>> getParameterMap(), with POST.
> It is normal that the query parameters are always parsed.
>
> The body parameters will then be parsed if it is a POST with the form 
> encoding content type and the body is not too large (2MB max). A 
> chunked body used to not be supported as well, but it is now supported.

Do I have to do something to trigger the parsing of the body parameters?

>
> Rémy
>

-- 
My company's smarter than your company (unless you work for Red Hat).

Re: [Resteasy-developers] jbossweb question

[Ron S. <rs...@re...>]

On 10/15/2012 12:12 PM, Rémy Maucherat wrote:
> On 10/15/2012 03:40 PM, Bill Burke wrote:
>> Please move these types of discussions to the dev list.
> Ok, but I am not subscribed to it.

WHAT?!?!  I thought everyone was on the Resteasy dev list.  I'm pretty 
sure Francois Holland is on the list.  Also, Voltaire.  But not Marie Le 
Pen.  She's on the jersey dev list.  ;)

>>
>> But, for form processing, there's a few things you have to worry about.
>>
>> 1) Did a Servlet filter eat the input stream?  You'll need to use 
>> getParameterMap() then.
>> 2) Is it a POST or PUT? If PUT, does getParameterMap() eat the form 
>> input stream or not?
>> 3) If its Tomcat, a PUT, and the filter ate the input stream, you're 
>> up shit creek.
> The spec is quite clear that it deals with URL encoded POSTs, so I 
> understand the real problems started when other containers thought it 
> would be nice to ignore specs and do what users asked for. So the 
> option to also process PUT should be added to AS then ?

I'm not sure why the user wants to use PUT.  But I get the same problem 
with POST.  Here's my test, on the client side:

    @Test
    public void testFormParamWithQueryParamPost() throws Exception
    {
       ClientRequest request = new 
ClientRequest("http://localhost:8080/RESTEASY-760/post/query?query=xyz");
       request.formParameter("formParam", "abc");
       request.header("Content-Type", "application/x-www-form-urlencoded");
       ClientResponse<String> response = request.put(String.class);
       assertTrue(response != null);
       System.out.println("response: " + response.getEntity());
       assertEquals("abc", response.getEntity());
    }

When Resteasy calls 
javax.servlet.http.HttpServletRequest..getParameterMap(), it gets 
query=xyz but not formParam=abc.   Maybe I'm doing something wrong?

>
> Rémy
>

-- 
My company's smarter than your company (unless you work for Red Hat).

Re: [Resteasy-developers] jbossweb question

[Ron S. <rs...@re...>]

On 10/15/2012 09:36 AM, Rémy Maucherat wrote:
> On 10/14/2012 07:27 AM, Ron Sigal wrote:
>> Hi Remy,
>>
>> I'm working on RESTEASY-760 "@FormParam does not work with PUT method 
>> when a Query param is present", in which the reporter claims (and 
>> I've verified the behavior), that if he sends a request with both 
>> query parameters and form parameters, Resteasy doesn't pass the form 
>> parameters into his JAX-RS resource.  It seems that in jbossweb, 
>> org.apache.catalina.connector.RequestFacade.getParameterMap() returns 
>> only query parameters, despite the javadoc on 
>> javax.servlet.ServletRequest.getParameterMap(), which says
>>
>>     /**
>>      * Returns a java.util.Map of the parameters of this request.
>>      *
>>      * <p>Request parameters are extra information sent with the 
>> request.
>>      * For HTTP servlets, parameters are contained in the query 
>> string or
>>      * posted form data.
>>      *
>>      * @return an immutable java.util.Map containing parameter names as
>>      * keys and parameter values as map values. The keys in the 
>> parameter
>>      * map are of type String. The values in the parameter map are of 
>> type
>>      * String array.
>>      */
>>
>> 1. Is this behavior a bug in jbossweb?  I don't see any jbossweb 
>> parameters that override the behavior.  Granted, the javadoc is a 
>> little ambiguous, where it says, "parameters are contained in the 
>> query string <em>OR</em> posted form data.
>>
>> 2. Resteasy already has a workaround for Tomcat:
>>
>>       // Tomcat does not set getParameters() if it is a PUT request
>>       // so pull it out manually
>>       if (request.getMethod().equals("PUT") && 
>> (request.getParameterMap() == null || 
>> request.getParameterMap().isEmpty()))
>>       {
>>          return getPutFormParameters();
>>       }
>>
>> where getPutFormParameters() pulls form parameters directly from the 
>> input stream.  I'm thinking of adding this:
>>
>>       Map<String, String[]> parameterMap = request.getParameterMap();
>>       MultivaluedMap<String, String> queryMap = 
>> uri.getQueryParameters();
>>       if (mapEquals(parameterMap, queryMap))
>>       {
>>          return getPutFormParameters();
>>       }
>>
>> In other words, it's a test that request.getParameterMap() contains 
>> only query parameters.
>>
>> My next question is, is this safe?  Is it possible that the input 
>> stream has already been read?
>>
> The web container only processes URL encoded POSTs, not any other 
> method (as per the spec).

I get the same result, i.e., missing form parameters in 
getParameterMap(), with POST.

>
> Although it is a convenient API, it is possible that the integrated 
> processing is very resource intensive compared to what is actually 
> needed, with questionable scalability, since it parses everything down 
> to individual strings, and puts everything in a hash map.
>
> Rémy
>

-- 
My company's smarter than your company (unless you work for Red Hat).

Re: [Resteasy-developers] jbossweb question

[Ron S. <rs...@re...>]

On 10/15/2012 09:40 AM, Bill Burke wrote:
> Please move these types of discussions to the dev list.

It's on the cc list.  I cc'd you and Weinan, which I guess is redundant.

>
> But, for form processing, there's a few things you have to worry about.
>
> 1) Did a Servlet filter eat the input stream?  You'll need to use 
> getParameterMap() then.

I'm not using a filter in my own tests.  But if the container doesn't 
put form parameters in the parameter map, that won't work.  I guess we 
can put a warning in the Resteasy User Guide.

> 2) Is it a POST or PUT? If PUT, does getParameterMap() eat the form 
> input stream or not?

I get the same results with POST and PUT.   For jbossweb, my change 
works for both, so jbossweb, at least, isn't eating the input stream.

> 3) If its Tomcat, a PUT, and the filter ate the input stream, you're 
> up shit creek.

In that case, again, I guess all we can do is put a warning in the 
Resteasy User Guide.

>
> On 10/15/2012 9:36 AM, Rémy Maucherat wrote:
>> On 10/14/2012 07:27 AM, Ron Sigal wrote:
>>> Hi Remy,
>>>
>>> I'm working on RESTEASY-760 "@FormParam does not work with PUT method
>>> when a Query param is present", in which the reporter claims (and I've
>>> verified the behavior), that if he sends a request with both query
>>> parameters and form parameters, Resteasy doesn't pass the form
>>> parameters into his JAX-RS resource.  It seems that in jbossweb,
>>> org.apache.catalina.connector.RequestFacade.getParameterMap() returns
>>> only query parameters, despite the javadoc on
>>> javax.servlet.ServletRequest.getParameterMap(), which says
>>>
>>>     /**
>>>      * Returns a java.util.Map of the parameters of this request.
>>>      *
>>>      * <p>Request parameters are extra information sent with the 
>>> request.
>>>      * For HTTP servlets, parameters are contained in the query 
>>> string or
>>>      * posted form data.
>>>      *
>>>      * @return an immutable java.util.Map containing parameter names as
>>>      * keys and parameter values as map values. The keys in the 
>>> parameter
>>>      * map are of type String. The values in the parameter map are of
>>> type
>>>      * String array.
>>>      */
>>>
>>> 1. Is this behavior a bug in jbossweb?  I don't see any jbossweb
>>> parameters that override the behavior.  Granted, the javadoc is a
>>> little ambiguous, where it says, "parameters are contained in the
>>> query string <em>OR</em> posted form data.
>>>
>>> 2. Resteasy already has a workaround for Tomcat:
>>>
>>>       // Tomcat does not set getParameters() if it is a PUT request
>>>       // so pull it out manually
>>>       if (request.getMethod().equals("PUT") &&
>>> (request.getParameterMap() == null ||
>>> request.getParameterMap().isEmpty()))
>>>       {
>>>          return getPutFormParameters();
>>>       }
>>>
>>> where getPutFormParameters() pulls form parameters directly from the
>>> input stream.  I'm thinking of adding this:
>>>
>>>       Map<String, String[]> parameterMap = request.getParameterMap();
>>>       MultivaluedMap<String, String> queryMap = 
>>> uri.getQueryParameters();
>>>       if (mapEquals(parameterMap, queryMap))
>>>       {
>>>          return getPutFormParameters();
>>>       }
>>>
>>> In other words, it's a test that request.getParameterMap() contains
>>> only query parameters.
>>>
>>> My next question is, is this safe?  Is it possible that the input
>>> stream has already been read?
>>>
>> The web container only processes URL encoded POSTs, not any other method
>> (as per the spec).
>>
>> Although it is a convenient API, it is possible that the integrated
>> processing is very resource intensive compared to what is actually
>> needed, with questionable scalability, since it parses everything down
>> to individual strings, and puts everything in a hash map.
>>
>> Rémy
>>
>

-- 
My company's smarter than your company (unless you work for Red Hat).

Re: [Resteasy-developers] Another JAXB problem related to Atom on AS .0.2/7.1.1

[Weinan L. <we...@re...>]

Hi Jervis, 

I've created a test case here: https://github.com/liweinan/try-resteasy/tree/test-guvnor-jaxb

Could you please checkout 'try-resteasy' and use branch 'test-guvnor-jaxb' to give it a try?

You can run the example like this:

git clone git://github.com/liweinan/try-resteasy.git
git checkout -b test-guvnor-jaxb origin/test-guvnor-jaxb 
mvn jetty:run

Then you can access these two urls:

http://127.0.0.1:8080/try-resteasy/resteasy/entry
http://127.0.0.1:8080/try-resteasy/resteasy/entry2

The first one is the XML generated by JAXB
The second one is the XML you gave to me

Both can be marshalled by RESTEasy correctly. I've only fix one class in Guvnor's code:


In "public class Link extends CommonAttributes", I've comment out the @XmlAttribute of MediaType:

// @XmlAttribute 
 public MediaType getType() { return type; }

Seems the annotation is not used correctly.

Please tell me your test result. 



-- 
Weinan Li
JBoss, Red Hat


On Monday, October 15, 2012 at 4:50 PM, Jervis Liu wrote:

> On 2012/10/13 18:14, Weinan Li wrote:
> > Hi Jervis, 
> > 
> > Sorry for the late reply. I've checked the trunk code in RESTEasy and it seems getJAXBObject could handle custom element properly: 
> > 
> > CustomerAtom cust = entry.getContent().getJAXBObject(CustomerAtom.class); Assert.assertEquals(cust.getName(), "bill");   
> > Could you please check the example code "org.jboss.resteasy.test.providers.atom.ResourceTest" in 'providers/resteasy-atom'? I believe from RESTEasy 2.3.5 Final it could fulfil your requirement properly.
> > 
> No, I am afraid it does not work. Please note, what we are asking for is not to use extension element on Atom Entry's content element. but on Entry itself or Feed and any other elements that are valid to have extension element per spec : http://tools.ietf.org/html/rfc4287#section-6.4. eg., like sth this:
> 
>             AtomAssetMetadata assetMetadata = entry.getAnyOtherJAXBObject(AtomAssetMetadata.class);
> 
> I checked the Atom provider code on RESTEasy master branch. It does not work either. 
> 
> 
> Thanks,
> Jervis
> > 
> > --  
> > Weinan Li
> > JBoss, Red Hat
> > 
> > 
> > On Tuesday, October 9, 2012 at 2:47 AM, Weinan Li wrote:
> > 
> > > 
> > > 
> > > --  
> > > Weinan Li
> > > JBoss, Red Hat
> > > 
> > > 
> > > On Monday, October 8, 2012 at 10:14 PM, Jervis Liu wrote:
> > > 
> > > > On 2012/9/29 14:06, Weinan Li wrote:
> > > > > 
> > > > > 
> > > > > --  
> > > > > Weinan Li
> > > > > JBoss, Red Hat
> > > > > 
> > > > > 
> > > > > On Saturday, September 29, 2012 at 12:59 PM, Jervis Liu wrote:
> > > > > 
> > > > > > On 2012/9/27 20:29, Weinan Li wrote:
> > > > > > > Hi Jervis, 
> > > > > > > 
> > > > > > > Seems Guvnor is using its own Atom encapsulation: 
> > > > > > > 
> > > > > > > import org.drools.guvnor.server.jaxrs.jaxb.AtomAssetMetadata; 
> > > > > > > import org.drools.guvnor.server.jaxrs.providers.atom.Entry;
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > 
> > > > > > The Atom provider code was copied from RESTEasy. 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > 
> > > > > AtomAssetMetadata is not copied from RESTEasy and implemented by Guvnor itself.
> > > > >  
> > > > > > This is because the RESTEasy version shipped with AS 7 does not have the Atom Provider.
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > 
> > > > Hi, sorry for the confusion. The reason why we maintained our own copy of RESTEasy Atom provider is because the code that handles Atom extension is not available until 2.3.4.Final. The feature we are looking for is the capability to create and read Atom Extension element (http://tools.ietf.org/html/rfc4287#section-6.4). For example, below is how we add a custom extension to Atom using Abdera:
> > > > 
> > > > Abdera abdera = new Abdera(); 
> > > > Entry entry = abdera.newEntry();
> > > > entry.setTitle("testCreatePackageFromAtom1");
> > > > entry.setSummary("desc for testCreatePackageFromAtom");
> > > > ExtensibleElement extension = entry.addExtension(new QName("", 
> > > > "metadata"));
> > > > ExtensibleElement childExtension = extension.addExtension(new 
> > > > QName("", "categories"));
> > > > childExtension.addSimpleExtension(new QName("", "value")), 
> > > > "AssetPackageResourceTestCategory");
> > > > 
> > > > Basically we are looking for a similar way to add and read ATOM extension element using RESTEasy. Unfortunately methods likes getAnyOther, getAnyOtherJaxbObject etc were added into RESTEasy after 2.3.4.Final. 
> > > > 
> > > > The problem I reported in this email thread is regarding the code that handles extension element does not work properly (I am referring to our own copy of Atom provider code, which was copied from RESTEasy 2.3.4). To be more precisely, the problem is getAnyOtherJAXBObject returns null. I also verified the object returned by getAnyOther, yes, it is not null, but it is a ElementNSImpl object. I dont think you should expect RESTEasy users to retrieve a raw xml object using getAnyOther then marshall the raw xml to object using JAXB by themselves. This does not sound like a correct way to read Atom extension. 
> > > > 
> > > > I hope we can have explicit methods to read and create extension element on Entry, Feed and any other elements that are valid to have extension element per spec : http://tools.ietf.org/html/rfc4287#section-6.4. Eg, sth like Entry.addExentionElement(Object o) and Entry.getExtensionElemnt(), this API will be easier to understand than getAnyOther or getAnyOtherJaxbObject. 
> > > 
> > > 
> 

Re: [Resteasy-developers] jbossweb question

[Ron S. <rs...@re...>]

I've replicated the problem with my own tests.

On 10/15/2012 09:19 AM, Bill Burke wrote:
> Are you sure our stuff doesn't work?  Maybe the user is consuming the 
> input stream somewhere.
>
> On 10/14/2012 1:27 AM, Ron Sigal wrote:
>> Hi Remy,
>>
>> I'm working on RESTEASY-760 "@FormParam does not work with PUT method
>> when a Query param is present", in which the reporter claims (and I've
>> verified the behavior), that if he sends a request with both query
>> parameters and form parameters, Resteasy doesn't pass the form
>> parameters into his JAX-RS resource.  It seems that in jbossweb,
>> org.apache.catalina.connector.RequestFacade.getParameterMap() returns
>> only query parameters, despite the javadoc on
>> javax.servlet.ServletRequest.getParameterMap(), which says
>>
>>      /**
>>       * Returns a java.util.Map of the parameters of this request.
>>       *
>>       * <p>Request parameters are extra information sent with the 
>> request.
>>       * For HTTP servlets, parameters are contained in the query 
>> string or
>>       * posted form data.
>>       *
>>       * @return an immutable java.util.Map containing parameter names as
>>       * keys and parameter values as map values. The keys in the 
>> parameter
>>       * map are of type String. The values in the parameter map are 
>> of type
>>       * String array.
>>       */
>>
>> 1. Is this behavior a bug in jbossweb?  I don't see any jbossweb
>> parameters that override the behavior.  Granted, the javadoc is a little
>> ambiguous, where it says, "parameters are contained in the query string
>> <em>OR</em> posted form data.
>>
>> 2. Resteasy already has a workaround for Tomcat:
>>
>>        // Tomcat does not set getParameters() if it is a PUT request
>>        // so pull it out manually
>>        if (request.getMethod().equals("PUT") &&
>> (request.getParameterMap() == null || 
>> request.getParameterMap().isEmpty()))
>>        {
>>           return getPutFormParameters();
>>        }
>>
>> where getPutFormParameters() pulls form parameters directly from the
>> input stream.  I'm thinking of adding this:
>>
>>        Map<String, String[]> parameterMap = request.getParameterMap();
>>        MultivaluedMap<String, String> queryMap = 
>> uri.getQueryParameters();
>>        if (mapEquals(parameterMap, queryMap))
>>        {
>>           return getPutFormParameters();
>>        }
>>
>> In other words, it's a test that request.getParameterMap() contains only
>> query parameters.
>>
>> My next question is, is this safe?  Is it possible that the input stream
>> has already been read?
>>
>> Thanks,
>> Ron
>>
>>
>

-- 
My company's smarter than your company (unless you work for Red Hat).

Re: [Resteasy-developers] jbossweb question

[Bill B. <bb...@re...>]

Please move these types of discussions to the dev list.

But, for form processing, there's a few things you have to worry about.

1) Did a Servlet filter eat the input stream?  You'll need to use 
getParameterMap() then.
2) Is it a POST or PUT? If PUT, does getParameterMap() eat the form 
input stream or not?
3) If its Tomcat, a PUT, and the filter ate the input stream, you're up 
shit creek.

On 10/15/2012 9:36 AM, Rémy Maucherat wrote:
> On 10/14/2012 07:27 AM, Ron Sigal wrote:
>> Hi Remy,
>>
>> I'm working on RESTEASY-760 "@FormParam does not work with PUT method
>> when a Query param is present", in which the reporter claims (and I've
>> verified the behavior), that if he sends a request with both query
>> parameters and form parameters, Resteasy doesn't pass the form
>> parameters into his JAX-RS resource.  It seems that in jbossweb,
>> org.apache.catalina.connector.RequestFacade.getParameterMap() returns
>> only query parameters, despite the javadoc on
>> javax.servlet.ServletRequest.getParameterMap(), which says
>>
>>     /**
>>      * Returns a java.util.Map of the parameters of this request.
>>      *
>>      * <p>Request parameters are extra information sent with the request.
>>      * For HTTP servlets, parameters are contained in the query string or
>>      * posted form data.
>>      *
>>      * @return an immutable java.util.Map containing parameter names as
>>      * keys and parameter values as map values. The keys in the parameter
>>      * map are of type String. The values in the parameter map are of
>> type
>>      * String array.
>>      */
>>
>> 1. Is this behavior a bug in jbossweb?  I don't see any jbossweb
>> parameters that override the behavior.  Granted, the javadoc is a
>> little ambiguous, where it says, "parameters are contained in the
>> query string <em>OR</em> posted form data.
>>
>> 2. Resteasy already has a workaround for Tomcat:
>>
>>       // Tomcat does not set getParameters() if it is a PUT request
>>       // so pull it out manually
>>       if (request.getMethod().equals("PUT") &&
>> (request.getParameterMap() == null ||
>> request.getParameterMap().isEmpty()))
>>       {
>>          return getPutFormParameters();
>>       }
>>
>> where getPutFormParameters() pulls form parameters directly from the
>> input stream.  I'm thinking of adding this:
>>
>>       Map<String, String[]> parameterMap = request.getParameterMap();
>>       MultivaluedMap<String, String> queryMap = uri.getQueryParameters();
>>       if (mapEquals(parameterMap, queryMap))
>>       {
>>          return getPutFormParameters();
>>       }
>>
>> In other words, it's a test that request.getParameterMap() contains
>> only query parameters.
>>
>> My next question is, is this safe?  Is it possible that the input
>> stream has already been read?
>>
> The web container only processes URL encoded POSTs, not any other method
> (as per the spec).
>
> Although it is a convenient API, it is possible that the integrated
> processing is very resource intensive compared to what is actually
> needed, with questionable scalability, since it parses everything down
> to individual strings, and puts everything in a hash map.
>
> Rémy
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

Re: [Resteasy-developers] jbossweb question

[Bill B. <bb...@re...>]

Are you sure our stuff doesn't work?  Maybe the user is consuming the 
input stream somewhere.

On 10/14/2012 1:27 AM, Ron Sigal wrote:
> Hi Remy,
>
> I'm working on RESTEASY-760 "@FormParam does not work with PUT method
> when a Query param is present", in which the reporter claims (and I've
> verified the behavior), that if he sends a request with both query
> parameters and form parameters, Resteasy doesn't pass the form
> parameters into his JAX-RS resource.  It seems that in jbossweb,
> org.apache.catalina.connector.RequestFacade.getParameterMap() returns
> only query parameters, despite the javadoc on
> javax.servlet.ServletRequest.getParameterMap(), which says
>
>      /**
>       * Returns a java.util.Map of the parameters of this request.
>       *
>       * <p>Request parameters are extra information sent with the request.
>       * For HTTP servlets, parameters are contained in the query string or
>       * posted form data.
>       *
>       * @return an immutable java.util.Map containing parameter names as
>       * keys and parameter values as map values. The keys in the parameter
>       * map are of type String. The values in the parameter map are of type
>       * String array.
>       */
>
> 1. Is this behavior a bug in jbossweb?  I don't see any jbossweb
> parameters that override the behavior.  Granted, the javadoc is a little
> ambiguous, where it says, "parameters are contained in the query string
> <em>OR</em> posted form data.
>
> 2. Resteasy already has a workaround for Tomcat:
>
>        // Tomcat does not set getParameters() if it is a PUT request
>        // so pull it out manually
>        if (request.getMethod().equals("PUT") &&
> (request.getParameterMap() == null || request.getParameterMap().isEmpty()))
>        {
>           return getPutFormParameters();
>        }
>
> where getPutFormParameters() pulls form parameters directly from the
> input stream.  I'm thinking of adding this:
>
>        Map<String, String[]> parameterMap = request.getParameterMap();
>        MultivaluedMap<String, String> queryMap = uri.getQueryParameters();
>        if (mapEquals(parameterMap, queryMap))
>        {
>           return getPutFormParameters();
>        }
>
> In other words, it's a test that request.getParameterMap() contains only
> query parameters.
>
> My next question is, is this safe?  Is it possible that the input stream
> has already been read?
>
> Thanks,
> Ron
>
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

Re: [Resteasy-developers] Another JAXB problem related to Atom on AS .0.2/7.1.1

[Jervis L. <jl...@re...>]

On 2012/10/13 18:14, Weinan Li wrote:
> Hi Jervis,
>
> Sorry for the late reply. I've checked the trunk code in RESTEasy and 
> it seems getJAXBObject could handle custom element properly:
>
> CustomerAtom cust = 
> entry.getContent().getJAXBObject(CustomerAtom.class); 
> Assert.assertEquals(cust.getName(), "bill");
> Could you please check the example 
> code "org.jboss.resteasy.test.providers.atom.ResourceTest" in 
> 'providers/resteasy-atom'? I believe from RESTEasy 2.3.5 Final it 
> could fulfil your requirement properly.
>
No, I am afraid it does not work. Please note, what we are asking for is 
not to use extension element on Atom Entry's content element. but on 
Entry itself or Feed and any other elements that are valid to have 
extension element per spec : 
http://tools.ietf.org/html/rfc4287#section-6.4. eg., like sth this:

             AtomAssetMetadata assetMetadata = 
entry.getAnyOtherJAXBObject(AtomAssetMetadata.class);

I checked the Atom provider code on RESTEasy master branch. It does not 
work either.


Thanks,
Jervis
>
> -- 
> Weinan Li
> JBoss, Red Hat
>
> On Tuesday, October 9, 2012 at 2:47 AM, Weinan Li wrote:
>
>>
>>
>> -- 
>> Weinan Li
>> JBoss, Red Hat
>>
>> On Monday, October 8, 2012 at 10:14 PM, Jervis Liu wrote:
>>
>>> On 2012/9/29 14:06, Weinan Li wrote:
>>>>
>>>>
>>>> -- 
>>>> Weinan Li
>>>> JBoss, Red Hat
>>>>
>>>> On Saturday, September 29, 2012 at 12:59 PM, Jervis Liu wrote:
>>>>
>>>>> On 2012/9/27 20:29, Weinan Li wrote:
>>>>>> Hi Jervis,
>>>>>>
>>>>>> Seems Guvnor is using its own Atom encapsulation:
>>>>>>
>>>>>> importorg.drools.guvnor.server.jaxrs.jaxb.AtomAssetMetadata;
>>>>>> importorg.drools.guvnor.server.jaxrs.providers.atom.Entry;
>>>>> The Atom provider code was copied from RESTEasy.
>>>> AtomAssetMetadata is not copied from RESTEasy and implemented by 
>>>> Guvnor itself.
>>>>> This is because the RESTEasy version shipped with AS 7 does not 
>>>>> have the Atom Provider.
>>> Hi, sorry for the confusion. The reason why we maintained our own 
>>> copy of RESTEasy Atom provider is because the code that handles Atom 
>>> extension is not available until 2.3.4.Final. The feature we are 
>>> looking for is the capability to create and read Atom Extension 
>>> element (http://tools.ietf.org/html/rfc4287#section-6.4). For 
>>> example, below is how we add a custom extension to Atom using Abdera:
>>>
>>> Abdera abdera = new Abdera();
>>> Entry entry = abdera.newEntry();
>>> entry.setTitle("testCreatePackageFromAtom1");
>>> entry.setSummary("desc for testCreatePackageFromAtom");
>>> ExtensibleElement extension = entry.addExtension(new QName("",
>>> "metadata"));
>>> ExtensibleElement childExtension = extension.addExtension(new
>>> QName("", "categories"));
>>> childExtension.addSimpleExtension(new QName("", "value")),
>>> "AssetPackageResourceTestCategory");
>>>
>>> Basically we are looking for a similar way to add and read ATOM 
>>> extension element using RESTEasy. Unfortunately methods likes 
>>> getAnyOther, getAnyOtherJaxbObject etc were added into RESTEasy 
>>> after 2.3.4.Final.
>>>
>>> The problem I reported in this email thread is regarding the code 
>>> that handles extension element does not work properly (I am 
>>> referring to our own copy of Atom provider code, which was copied 
>>> from RESTEasy 2.3.4). To be more precisely, the problem is 
>>> getAnyOtherJAXBObject returns null. I also verified the object 
>>> returned by getAnyOther, yes, it is not null, but it is a 
>>> ElementNSImpl object. I dont think you should expect RESTEasy users 
>>> to retrieve a raw xml object using getAnyOther then marshall the raw 
>>> xml to object using JAXB by themselves. This does not sound like a 
>>> correct way to read Atom extension.
>>>
>>> I hope we can have explicit methods to read and create extension 
>>> element on Entry, Feed and any other elements that are valid to have 
>>> extension element per spec : 
>>> http://tools.ietf.org/html/rfc4287#section-6.4. Eg, sth like 
>>> Entry.addExentionElement(Object o) and Entry.getExtensionElemnt(), 
>>> this API will be easier to understand than getAnyOther or 
>>> getAnyOtherJaxbObject.
>>
>>

[Resteasy-developers] jbossweb question

[Ron S. <rs...@re...>]

Hi Remy,

I'm working on RESTEASY-760 "@FormParam does not work with PUT method 
when a Query param is present", in which the reporter claims (and I've 
verified the behavior), that if he sends a request with both query 
parameters and form parameters, Resteasy doesn't pass the form 
parameters into his JAX-RS resource.  It seems that in jbossweb, 
org.apache.catalina.connector.RequestFacade.getParameterMap() returns 
only query parameters, despite the javadoc on 
javax.servlet.ServletRequest.getParameterMap(), which says

     /**
      * Returns a java.util.Map of the parameters of this request.
      *
      * <p>Request parameters are extra information sent with the request.
      * For HTTP servlets, parameters are contained in the query string or
      * posted form data.
      *
      * @return an immutable java.util.Map containing parameter names as
      * keys and parameter values as map values. The keys in the parameter
      * map are of type String. The values in the parameter map are of type
      * String array.
      */

1. Is this behavior a bug in jbossweb?  I don't see any jbossweb 
parameters that override the behavior.  Granted, the javadoc is a little 
ambiguous, where it says, "parameters are contained in the query string 
<em>OR</em> posted form data.

2. Resteasy already has a workaround for Tomcat:

       // Tomcat does not set getParameters() if it is a PUT request
       // so pull it out manually
       if (request.getMethod().equals("PUT") && 
(request.getParameterMap() == null || request.getParameterMap().isEmpty()))
       {
          return getPutFormParameters();
       }

where getPutFormParameters() pulls form parameters directly from the 
input stream.  I'm thinking of adding this:

       Map<String, String[]> parameterMap = request.getParameterMap();
       MultivaluedMap<String, String> queryMap = uri.getQueryParameters();
       if (mapEquals(parameterMap, queryMap))
       {
          return getPutFormParameters();
       }

In other words, it's a test that request.getParameterMap() contains only 
query parameters.

My next question is, is this safe?  Is it possible that the input stream 
has already been read?

Thanks,
Ron


-- 
My company's smarter than your company (unless you work for Red Hat).

Re: [Resteasy-developers] Another JAXB problem related to Atom on AS .0.2/7.1.1

[Weinan L. <we...@re...>]

Hi Jervis,  

Sorry for the late reply. I've checked the trunk code in RESTEasy and it seems getJAXBObject could handle custom element properly:

CustomerAtom cust = entry.getContent().getJAXBObject(CustomerAtom.class); Assert.assertEquals(cust.getName(), "bill");  
Could you please check the example code "org.jboss.resteasy.test.providers.atom.ResourceTest" in 'providers/resteasy-atom'? I believe from RESTEasy 2.3.5 Final it could fulfil your requirement properly.


--  
Weinan Li
JBoss, Red Hat


On Tuesday, October 9, 2012 at 2:47 AM, Weinan Li wrote:

>  
>  
> --  
> Weinan Li
> JBoss, Red Hat
>  
>  
> On Monday, October 8, 2012 at 10:14 PM, Jervis Liu wrote:
>  
> > On 2012/9/29 14:06, Weinan Li wrote:
> > >  
> > >  
> > > --   
> > > Weinan Li
> > > JBoss, Red Hat
> > >  
> > >  
> > > On Saturday, September 29, 2012 at 12:59 PM, Jervis Liu wrote:
> > >  
> > > > On 2012/9/27 20:29, Weinan Li wrote:
> > > > > Hi Jervis,  
> > > > >  
> > > > > Seems Guvnor is using its own Atom encapsulation:  
> > > > >  
> > > > > import org.drools.guvnor.server.jaxrs.jaxb.AtomAssetMetadata;  
> > > > > import org.drools.guvnor.server.jaxrs.providers.atom.Entry;
> > > > >  
> > > > >  
> > > > >  
> > > > >  
> > > >  
> > > > The Atom provider code was copied from RESTEasy.  
> > > >  
> > > >  
> > >  
> > > AtomAssetMetadata is not copied from RESTEasy and implemented by Guvnor itself.
> > >   
> > > > This is because the RESTEasy version shipped with AS 7 does not have the Atom Provider.
> > > >  
> > > >  
> > >  
> > >  
> >  
> > Hi, sorry for the confusion. The reason why we maintained our own copy of RESTEasy Atom provider is because the code that handles Atom extension is not available until 2.3.4.Final. The feature we are looking for is the capability to create and read Atom Extension element (http://tools.ietf.org/html/rfc4287#section-6.4). For example, below is how we add a custom extension to Atom using Abdera:
> >  
> > Abdera abdera = new Abdera();  
> > Entry entry = abdera.newEntry();
> > entry.setTitle("testCreatePackageFromAtom1");
> > entry.setSummary("desc for testCreatePackageFromAtom");
> > ExtensibleElement extension = entry.addExtension(new QName("",  
> > "metadata"));
> > ExtensibleElement childExtension = extension.addExtension(new  
> > QName("", "categories"));
> > childExtension.addSimpleExtension(new QName("", "value")),  
> > "AssetPackageResourceTestCategory");
> >  
> > Basically we are looking for a similar way to add and read ATOM extension element using RESTEasy. Unfortunately methods likes getAnyOther, getAnyOtherJaxbObject etc were added into RESTEasy after 2.3.4.Final.  
> >  
> > The problem I reported in this email thread is regarding the code that handles extension element does not work properly (I am referring to our own copy of Atom provider code, which was copied from RESTEasy 2.3.4). To be more precisely, the problem is getAnyOtherJAXBObject returns null. I also verified the object returned by getAnyOther, yes, it is not null, but it is a ElementNSImpl object. I dont think you should expect RESTEasy users to retrieve a raw xml object using getAnyOther then marshall the raw xml to object using JAXB by themselves. This does not sound like a correct way to read Atom extension.  
> >  
> > I hope we can have explicit methods to read and create extension element on Entry, Feed and any other elements that are valid to have extension element per spec : http://tools.ietf.org/html/rfc4287#section-6.4. Eg, sth like Entry.addExentionElement(Object o) and Entry.getExtensionElemnt(), this API will be easier to understand than getAnyOther or getAnyOtherJaxbObject.  
>  
> Hi Jervis, thank you for the feedback, could you please help to create a JIRA feature request for this and assign it to me? Thanks!
> >  
> >  
> > Thanks,
> > Jervis  
> > > I've checked: jboss-as-7.1.0.Final/modules/org/jboss/resteasy
> > >  
> > > ls  
> > > resteasy-atom-provider      resteasy-jettison-provider
> > > resteasy-cdi                resteasy-jsapi
> > > resteasy-jackson-provider   resteasy-multipart-provider
> > > resteasy-jaxb-provider      resteasy-yaml-provider
> > > resteasy-jaxrs
> > >  
> > >  
> > > It has resteasy-atom-provider.
> > > > Please help to check if the Atom provider in RESTEasy 2.3.4.or master branch has the same problem. As long the Atom provider on RESTEasy master branch works, we will try to keep our copy synced with RESTEasy master branch. Thanks.
> > >  
> > > The problem is that you copied AtomFeedProvider and AtomEntryProvider from RESTEasy but doesn't modify it to accommodate your own AtomAssetMetadata:  
> > >  
> > >       for (Entry entry : feed.getEntries())  
> > >       {
> > >          if (entry.getContent() != null && entry.getContent().getJAXBObject() != null)
> > >          {
> > >             set.add(entry.getContent().getJAXBObject().getClass());
> > >          }
> > >       }
> > >  
> > >  
> > > …  
> > >  
> > >       if (entry.getAnyOtherJAXBObject() != null) {  
> > >           set.add(entry.getAnyOtherJAXBObject().getClass());
> > >       }
> > >       if (entry.getContent() != null && entry.getContent().getJAXBObject() != null)
> > >       {
> > >          set.add(entry.getContent().getJAXBObject().getClass());
> > >       }
> > >  
> > >  
> > > The above code won't extract the metadata correctly, as we have analysed these days. So you need to hack the provider classes(instead of merely copy it from RESTEasy) for it to support AtomAssetMetadata. Hope this information useful to you :-)  
> > >  
> > >  
> > >  
> >  
> > ------------------------------------------------------------------------------
> > Don't let slow site performance ruin your business. Deploy New Relic APM
> > Deploy New Relic app performance management and know exactly
> > what is happening inside your Ruby, Python, PHP, Java, and .NET app
> > Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> > http://p.sf.net/sfu/newrelic-dev2dev
> >  
> > _______________________________________________
> > Resteasy-developers mailing list
> > Res...@li... (mailto:Res...@li...)
> > https://lists.sourceforge.net/lists/listinfo/resteasy-developers
> >  
> >  
> >  
>  
>  
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
>  
> _______________________________________________
> Resteasy-developers mailing list
> Res...@li... (mailto:Res...@li...)
> https://lists.sourceforge.net/lists/listinfo/resteasy-developers
>  
>