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

[Resteasy-developers] Updating to 0.9

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

FYI, I'm updating jaxrs-api to 0.9.  One of the significant changes is 
that @ProduceMime is now @Produces and @ConsumeMime is Consumes.
-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

[Resteasy-developers] ContextResolver for JAXBContext lookup

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

After talking on the mail list a few weeks ago about ContextResolver (I 
didn't know WTF it was for), I found that it exists solely to provide 
pluggable JAXB contexts in the RI.  I figure, since its there, we might 
as well use it instead of JAXBCache.
-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

Re: [Resteasy-developers] How to configure JAXB now?

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

Any idea when you're going to be done?  I want to do a release soon.

Ryan McDonough wrote:
> Bill,
>  
> I do have more plans for this and had started work on a few annotations 
> to allow you to do the following:
> 
>     * pass multiple package names to the JAXBContext
>     * provide a schema to validate against
> 
> Are there any other configuration options you can think of that would be 
> required? There's one minor undocumented fetaure that the marshaller 
> has: if you pass an X-Xml-Formatted header to true, the marshaller will 
> format the output.
>  
> And yes, I do have plans to update the JSON providers as well ;)
>  
> Ryan-
>  
> 
> 
>  
> On Thu, Jul 31, 2008 at 12:42 PM, Bill Burke <bb...@re... 
> <mailto:bb...@re...>> wrote:
> 
>     I don't see a way to configure JAXB at all anymore with Ryan's changes.
>      Do we need it more configurable on a per Class/JAXBContext basis?
> 
>     Thanks
> 
>     --
>     Bill Burke
>     JBoss, a division of Red Hat
>     http://bill.burkecentral.com <http://bill.burkecentral.com/>
> 
>     -------------------------------------------------------------------------
>     This SF.Net email is sponsored by the Moblin Your Move Developer's
>     challenge
>     Build the coolest Linux based applications with Moblin SDK & win
>     great prizes
>     Grand prize is a trip for two to an Open Source event anywhere in
>     the world
>     http://moblin-contest.org/redirect.php?banner_id=100&url=/
>     <http://moblin-contest.org/redirect.php?banner_id=100&url=/>
>     _______________________________________________
>     Resteasy-developers mailing list
>     Res...@li...
>     <mailto:Res...@li...>
>     https://lists.sourceforge.net/lists/listinfo/resteasy-developers
> 
> 
> 
> 
> -- 
> Ryan J. McDonough
> http://www.damnhandy.com

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

Re: [Resteasy-developers] How to configure JAXB now?

[Ryan M. <ry...@da...>]

Bill,

I do have more plans for this and had started work on a few annotations to
allow you to do the following:

   - pass multiple package names to the JAXBContext
   - provide a schema to validate against

Are there any other configuration options you can think of that would be
required? There's one minor undocumented fetaure that the marshaller has: if
you pass an X-Xml-Formatted header to true, the marshaller will format the
output.

And yes, I do have plans to update the JSON providers as well ;)

Ryan-




On Thu, Jul 31, 2008 at 12:42 PM, Bill Burke <bb...@re...> wrote:

> I don't see a way to configure JAXB at all anymore with Ryan's changes.
>  Do we need it more configurable on a per Class/JAXBContext basis?
>
> Thanks
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Resteasy-developers mailing list
> Res...@li...
> https://lists.sourceforge.net/lists/listinfo/resteasy-developers
>



-- 
Ryan J. McDonough
http://www.damnhandy.com

[Resteasy-developers] Should JSON/Jettison be rolled into new JAXB providers?

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

I think it makes sense.
-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

[Resteasy-developers] How to configure JAXB now?

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

I don't see a way to configure JAXB at all anymore with Ryan's changes. 
  Do we need it more configurable on a per Class/JAXBContext basis?

Thanks

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

Re: [Resteasy-developers] Changes to JAXBProviders

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

We could implement the DELETE/PUT tunneling that was talked about before.

Ryan J. McDonough wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Swing will be first since that is further along. Flex introduces some 
> new annoying issues in that the Flash player only supports GET and POST. 
> in order to utilize other HTTP methods, all requests must be proxied 
> through the either LiveCycle DS or BlazeDS. Niether of which is really a 
> problem, but kind of a pain none the less. I'll be committing the code 
> early next week.
> 
> Ryan-
> 
> 
> On Jul 30, 2008, at 7:45 AM, Bill Burke wrote:
> 
>> This is really awesome Ryan!  Looking forward to seeing the flex app.
>>
>> Ryan J. McDonough wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>> I have committed the updated JAXB Providers and posted updated 
>>> documentation here:
>>> http://wiki.jboss.org/auth/wiki/BuiltInJAXBXMLProvider
>>> I have also added some more unit tests to cover the different cases, 
>>> but it could still use some more test coverage. With this all 
>>> working, I'll also want to update the JSON provider so that it too 
>>> can take advantage of these changes as well. Additionally, I also 
>>> created a provider to handle FastinfoSets:
>>> http://en.wikipedia.org/wiki/Fast_Infoset
>>> Finally, I also committed a bunch of code for my example app which 
>>> uses an EJB, Seam, and has some custom exception mappers. It also 
>>> shows how you can handle cyclic references with JAXB and re-associate 
>>> children with their parent objects on unmarshall. I have a Swing and 
>>> Flex  GUI I'm wrapping up that'll pull it all together. Once that is 
>>> complete, I'll update the documentation.
>>> Ryan-
>>> On Jul 21, 2008, at 9:02 PM, Ryan J. McDonough wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>>
>>>> Absolutely! There are some very subtle differences for all of these 
>>>> variations and i'll put those up on the wiki as part of the commit.
>>>>
>>>> Ryan-
>>>>
>>>>
>>>> On Jul 21, 2008, at 8:38 AM, Bill Burke wrote:
>>>>
>>>>> Can you map out how people will configure and use these new JAXB 
>>>>> providers?  That is the hardest part of all of this since we have 
>>>>> to DI mechanism.
>>>>>
>>>>> Ryan J. McDonough wrote:
>>>>>> I just opened:
>>>>>> https://jira.jboss.org/jira/browse/RESTEASY-82
>>>>>> Currently, our JAXBProvider does not handle classed which are 
>>>>>> generated from an existing XML Schema by XJC. To resolve this, I 
>>>>>> have refactored the JAXBProvider into a number of more specialized 
>>>>>> providers:
>>>>>> *JAXBContextCache*:
>>>>>> A shared class for all JAXB providers to cache the various 
>>>>>> JAXBContexts in use
>>>>>> *JAXBXmlRootEntityProvider* :
>>>>>> basically the same as our current JAXBProvider
>>>>>> JAXBXmlTypeProvider:
>>>>>> Generated classes won't have the @XmlRootEntity annotation on them 
>>>>>> and therefore will be ignored. *JAXBElementProvider*:
>>>>>> A JAXB provider for JAXBElement classes.
>>>>>> With the number of classes here, I'm considering creating a jaxb 
>>>>>> subpackage under:
>>>>>> org.jboss.resteasy.plugins.providers
>>>>>> Thoughts?
>>>>>> I have already got most of this done and will be committing 
>>>>>> changes by next Monday. Please let me know if you see any issues 
>>>>>> with these changes. On a related note; we may also want to 
>>>>>> consider similar changes for the JSON providers as well as this 
>>>>>> issue will affect this provider also. Ryan-
>>>>>> ------------------------------------------------------------------------ 
>>>>>>
>>>>>> ------------------------------------------------------------------------- 
>>>>>>
>>>>>> This SF.Net email is sponsored by the Moblin Your Move Developer's 
>>>>>> challenge
>>>>>> Build the coolest Linux based applications with Moblin SDK & win 
>>>>>> great prizes
>>>>>> Grand prize is a trip for two to an Open Source event anywhere in 
>>>>>> the world
>>>>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>>>>> ------------------------------------------------------------------------ 
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>>
>>>> -----BEGIN PGP SIGNATURE-----
>>>> Version: GnuPG v1.4.7 (Darwin)
>>>>
>>>> iD8DBQFIhTHCK/xjmUY6JwURAqKeAJ9puaboJQHYWXXDcdGiDIjfhLFhKgCglCTO
>>>> w4kaOyjRu6QVvQF9H9pf1jQ=
>>>> =/uFk
>>>> -----END PGP SIGNATURE-----
>>> -----BEGIN PGP SIGNATURE-----
>>> Version: GnuPG v1.4.7 (Darwin)
>>> iD8DBQFIj+EiK/xjmUY6JwURAhL+AJ40MToEA065BLIBCzo2LBirrGrlTwCdGMw5
>>> DEzlIDmFV6+tA142VUGL864=
>>> =XbVv
>>> -----END PGP SIGNATURE-----
>>
>> -- 
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.7 (Darwin)
> 
> iD8DBQFIkF2SK/xjmUY6JwURAsRvAJ90qPSLhBDlEmqdLgMOE1QfJmwqGwCgqNYJ
> L6dOSakHwLHu+7o3+P+8avQ=
> =IB4u
> -----END PGP SIGNATURE-----

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

Re: [Resteasy-developers] ResourceFactory

[Ryan J. M. <ry...@da...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Now that I have my example code committed, you can see what I was  
trying to do. Right now, the annotation code is commented out, but  
have a look at the Contact entity in the ejb project. Ideally, what I  
want to be able to do is have the ContactServiceBean return an a  
Contact instance (which it does) and form there, the JAX-RS  
annotations are read off of the entity. This way, I can easily  
navigate to:

http://localhost:8080/addressbook/contacts/1/emailAddresses/3

And from there, I could view the EmailAddress entity with ID 3. Right  
now, this doesn't work as expected and a 404 is returned.

Ryan-



On Jul 16, 2008, at 4:52 PM, Bill Burke wrote:

>
>
> Ryan J. McDonough wrote:
>> On Jul 15, 2008, at 9:22 AM, Bill Burke wrote:
>>> I don't see why you need a change to Resteasy to do this when the  
>>> JAX-RS spec allows you to return any arbitrary object from a  
>>> subresource locator.  For example:
>>>
>>> @Path("/")
>>> public class CustomerDatabase {
>>>
>>>  @Path("customers/{id}")
>>>  public Object getCustomer() {
>>>
>>>      Customer cust = jpa.find(...);
>>>      return cust;
>>>  }
>>> }
>>>
>>> public class Customer {
>>>
>>>  @GET
>>>  public String get() {...}
>>>
>>>  @Path("/address")
>>>  public String getAddress() {...}
>>> }
>>>
>>> So
>>>
>>> GET /customers/1
>>> GET /customer/1/address
>>>
>>> Would eventually route to Customer.
>> I've tried that, and it does not work. You can certainly get the  
>> Contact entity, but any @Path annotations on the entity are not  
>> processed. We don't have any unit tests which cover this sort of  
>> behavior, so it maybe that we don't support this yet? (Or support  
>> this with EJB's?) I was also taking a look at the Jersey "Bookmark"  
>> example app, and they have created separate resource classes for  
>> child entities. Ideally, I don't want to do this. You've got  
>> similar patterns being repeated and we've got a lot of meta data on  
>> the entity that we can use.
>
> You'll have to show me an example because I'm not sure exactly what  
> you are doing here.
>
> -- 
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)

iD8DBQFIkGHyK/xjmUY6JwURAraYAJ9xNjpukovLJo9d8t9SyTbAn3Lx4wCgiRug
9Ad2Xa+ovRaIRWiw2tCNHCE=
=FE55
-----END PGP SIGNATURE-----

Re: [Resteasy-developers] RES: Mapping Parameters to Object

[Ryan J. M. <ry...@da...>]

On second thought, not requiring the @FormParam annotation on bean  
properties will make it difficult for the writer to know which  
properties should be serialized in the response. I that case, you'd  
have to ensure all properties are annotated, or none. Or, we could  
introduce another annotation, something like @FormTransient, which  
will instruct the provider to ignore the property from both the  
request and response. Thoughts?

On a related topic: I started thinking about ways to improve the  
mutlipart experience and I was thinking we could do something like  
what I've done in the FormUrlEncodedObjectProvider. We could have a  
MultipartObjectProvider which works off a class that is annotated with  
an @MultipartValues annotation. Each property is annotated with a  
@MimePart annotation which contains the following properties:

index: the index of the part.
mediaType: the media type of the part
name: and optional name for the part
fileName: the file optional file name for the part

This would be an natural extension of FormUrlEncodedObjectProvider and  
will allow you to work with more complex data types other than ones  
that are simply based on String values. Thoughts/Opinions?

Ryan-


On Jul 29, 2008, at 11:39 PM, Ryan J. McDonough wrote:

> Hey Rafael,
>
> I just committed a FormUrlEncodedObjectProvider which does mostly  
> what you want. To get it to work, you must annotate the value object  
> with the @FormValues annotation, and each field that needs to be  
> annotated with a @FormParam annotation. There's a unit test in src/ 
> test that shows how it all fits together. Going forward, here's what  
> I'd like/need to do:
>
> * support @Encoded
> * Don't require @FormParam if the field name matches the parameter  
> name
> * improve error handling
>
> Let me know if this is where your thinking was at?
>
> Ryan-
>
>
> On Jul 29, 2008, at 10:43 AM, Rafael Pereira Nunes wrote:
>
>> Probably we will have the same limitations of standard action.
>> If you have a reference to other object/composition I can´t see how  
>> to do this kind of injection.
>> Like if the address in Person object was another Object instead a  
>> String.
>>
>> class Person{
>>   String name;
>>   int age;
>>   Address address;
>> }
>>
>> How do you think in how to do that in a neat way?
>>
>> Feature Request opened:
>> https://jira.jboss.org/jira/browse/RESTEASY-85
>>
>> I´m finishing some integration examples of RestEasy with another  
>> platforms(Adobe Flex, Python, Ruby, HttpClient...) and I could help  
>> with this feature if you want.
>>
>> --Rafael
>> -----Mensagem original-----
>> De: Ryan J. McDonough [mailto:ry...@da...]
>> Enviada em: terça-feira, 29 de julho de 2008 10:01
>> Para: Rafael Pereira Nunes
>> Cc: res...@li...
>> Assunto: Re: [Resteasy-developers] Mapping Parameters to Object
>>
>> HA HA! I have to chuckle a bit because this is some that Bill was
>> trying to get into the JAX-RS spec but it got shot down. I think this
>> is something that'll end up being a RESTEasy-specific feature, and I
>> know it's something Bill was very interested in doing. In fact, I can
>> think of a pretty neat way to do it too. If you can, please open a
>> feature request for it so we don't for get ;) I'm finishing up some
>> JAXB stuff now.
>>
>> Ryan-
>>
>> On Jul 28, 2008, at 10:34 AM, Rafael Pereira Nunes wrote:
>>
>>> I was thinking about something that I cannot found in any REST
>>> framework(Restlet, Jersey, CXF...).
>>> I would like to see something like the standard action of
>>> JSP(<jsp:setProperty property="*">) when I found request parameters
>>> that
>>> matches with my object attributes I inject them.
>>>
>>> Something like:
>>>
>>> @POST
>>> public void someMethod(Person person){...}
>>>
>>> And in the client:
>>>
>>> POST Body
>>> name=John
>>> age=25
>>> gender=M
>>> addres=blablabla
>>>
>>> And I inject them with:
>>> person.setName("John")
>>> person.setAge(25)
>>> person.setGender('M')
>>> person.setAddress("blablabla")
>>>
>>> And can see some problems with that, but not impossible to do.
>>>
>>> Is this possible? Or is it just a nonsense dream?
>>>
>>>
>>> Rafael
>>>
>>>
>>>
>>>
>>> -------------------------------------------------------------------------
>>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>>> challenge
>>> Build the coolest Linux based applications with Moblin SDK & win
>>> great prizes
>>> Grand prize is a trip for two to an Open Source event anywhere in
>>> the world
>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>> _______________________________________________
>>> Resteasy-developers mailing list
>>> Res...@li...
>>> https://lists.sourceforge.net/lists/listinfo/resteasy-developers
>>
>>
>>
>>
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's  
>> challenge
>> Build the coolest Linux based applications with Moblin SDK & win  
>> great prizes
>> Grand prize is a trip for two to an Open Source event anywhere in  
>> the world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> Resteasy-developers mailing list
>> Res...@li...
>> https://lists.sourceforge.net/lists/listinfo/resteasy-developers
>

Re: [Resteasy-developers] Changes to JAXBProviders

[Ryan J. M. <ry...@da...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Swing will be first since that is further along. Flex introduces some  
new annoying issues in that the Flash player only supports GET and  
POST. in order to utilize other HTTP methods, all requests must be  
proxied through the either LiveCycle DS or BlazeDS. Niether of which  
is really a problem, but kind of a pain none the less. I'll be  
committing the code early next week.

Ryan-


On Jul 30, 2008, at 7:45 AM, Bill Burke wrote:

> This is really awesome Ryan!  Looking forward to seeing the flex app.
>
> Ryan J. McDonough wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>> I have committed the updated JAXB Providers and posted updated  
>> documentation here:
>> http://wiki.jboss.org/auth/wiki/BuiltInJAXBXMLProvider
>> I have also added some more unit tests to cover the different  
>> cases, but it could still use some more test coverage. With this  
>> all working, I'll also want to update the JSON provider so that it  
>> too can take advantage of these changes as well. Additionally, I  
>> also created a provider to handle FastinfoSets:
>> http://en.wikipedia.org/wiki/Fast_Infoset
>> Finally, I also committed a bunch of code for my example app which  
>> uses an EJB, Seam, and has some custom exception mappers. It also  
>> shows how you can handle cyclic references with JAXB and re- 
>> associate children with their parent objects on unmarshall. I have  
>> a Swing and Flex  GUI I'm wrapping up that'll pull it all together.  
>> Once that is complete, I'll update the documentation.
>> Ryan-
>> On Jul 21, 2008, at 9:02 PM, Ryan J. McDonough wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> Absolutely! There are some very subtle differences for all of  
>>> these variations and i'll put those up on the wiki as part of the  
>>> commit.
>>>
>>> Ryan-
>>>
>>>
>>> On Jul 21, 2008, at 8:38 AM, Bill Burke wrote:
>>>
>>>> Can you map out how people will configure and use these new JAXB  
>>>> providers?  That is the hardest part of all of this since we have  
>>>> to DI mechanism.
>>>>
>>>> Ryan J. McDonough wrote:
>>>>> I just opened:
>>>>> https://jira.jboss.org/jira/browse/RESTEASY-82
>>>>> Currently, our JAXBProvider does not handle classed which are  
>>>>> generated from an existing XML Schema by XJC. To resolve this, I  
>>>>> have refactored the JAXBProvider into a number of more  
>>>>> specialized providers:
>>>>> *JAXBContextCache*:
>>>>> A shared class for all JAXB providers to cache the various  
>>>>> JAXBContexts in use
>>>>> *JAXBXmlRootEntityProvider* :
>>>>> basically the same as our current JAXBProvider
>>>>> JAXBXmlTypeProvider:
>>>>> Generated classes won't have the @XmlRootEntity annotation on  
>>>>> them and therefore will be ignored. *JAXBElementProvider*:
>>>>> A JAXB provider for JAXBElement classes.
>>>>> With the number of classes here, I'm considering creating a jaxb  
>>>>> subpackage under:
>>>>> org.jboss.resteasy.plugins.providers
>>>>> Thoughts?
>>>>> I have already got most of this done and will be committing  
>>>>> changes by next Monday. Please let me know if you see any issues  
>>>>> with these changes. On a related note; we may also want to  
>>>>> consider similar changes for the JSON providers as well as this  
>>>>> issue will affect this provider also. Ryan-
>>>>> ------------------------------------------------------------------------
>>>>> -------------------------------------------------------------------------
>>>>> This SF.Net email is sponsored by the Moblin Your Move  
>>>>> Developer's challenge
>>>>> Build the coolest Linux based applications with Moblin SDK & win  
>>>>> great prizes
>>>>> Grand prize is a trip for two to an Open Source event anywhere  
>>>>> in the world
>>>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>>>> ------------------------------------------------------------------------
>>>>> _______________________________________________
>>>>> 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
>>>
>>> -----BEGIN PGP SIGNATURE-----
>>> Version: GnuPG v1.4.7 (Darwin)
>>>
>>> iD8DBQFIhTHCK/xjmUY6JwURAqKeAJ9puaboJQHYWXXDcdGiDIjfhLFhKgCglCTO
>>> w4kaOyjRu6QVvQF9H9pf1jQ=
>>> =/uFk
>>> -----END PGP SIGNATURE-----
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.7 (Darwin)
>> iD8DBQFIj+EiK/xjmUY6JwURAhL+AJ40MToEA065BLIBCzo2LBirrGrlTwCdGMw5
>> DEzlIDmFV6+tA142VUGL864=
>> =XbVv
>> -----END PGP SIGNATURE-----
>
> -- 
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)

iD8DBQFIkF2SK/xjmUY6JwURAsRvAJ90qPSLhBDlEmqdLgMOE1QfJmwqGwCgqNYJ
L6dOSakHwLHu+7o3+P+8avQ=
=IB4u
-----END PGP SIGNATURE-----

Re: [Resteasy-developers] Changes to JAXBProviders

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

This is really awesome Ryan!  Looking forward to seeing the flex app.

Ryan J. McDonough wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> I have committed the updated JAXB Providers and posted updated 
> documentation here:
> 
> http://wiki.jboss.org/auth/wiki/BuiltInJAXBXMLProvider
> 
> I have also added some more unit tests to cover the different cases, but 
> it could still use some more test coverage. With this all working, I'll 
> also want to update the JSON provider so that it too can take advantage 
> of these changes as well. Additionally, I also created a provider to 
> handle FastinfoSets:
> 
> http://en.wikipedia.org/wiki/Fast_Infoset
> 
> Finally, I also committed a bunch of code for my example app which uses 
> an EJB, Seam, and has some custom exception mappers. It also shows how 
> you can handle cyclic references with JAXB and re-associate children 
> with their parent objects on unmarshall. I have a Swing and Flex  GUI 
> I'm wrapping up that'll pull it all together. Once that is complete, 
> I'll update the documentation.
> 
> Ryan-
> 
> On Jul 21, 2008, at 9:02 PM, Ryan J. McDonough wrote:
> 
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Absolutely! There are some very subtle differences for all of these 
>> variations and i'll put those up on the wiki as part of the commit.
>>
>> Ryan-
>>
>>
>> On Jul 21, 2008, at 8:38 AM, Bill Burke wrote:
>>
>>> Can you map out how people will configure and use these new JAXB 
>>> providers?  That is the hardest part of all of this since we have to 
>>> DI mechanism.
>>>
>>> Ryan J. McDonough wrote:
>>>> I just opened:
>>>> https://jira.jboss.org/jira/browse/RESTEASY-82
>>>> Currently, our JAXBProvider does not handle classed which are 
>>>> generated from an existing XML Schema by XJC. To resolve this, I 
>>>> have refactored the JAXBProvider into a number of more specialized 
>>>> providers:
>>>> *JAXBContextCache*:
>>>> A shared class for all JAXB providers to cache the various 
>>>> JAXBContexts in use
>>>> *JAXBXmlRootEntityProvider* :
>>>> basically the same as our current JAXBProvider
>>>> JAXBXmlTypeProvider:
>>>> Generated classes won't have the @XmlRootEntity annotation on them 
>>>> and therefore will be ignored. *JAXBElementProvider*:
>>>> A JAXB provider for JAXBElement classes.
>>>> With the number of classes here, I'm considering creating a jaxb 
>>>> subpackage under:
>>>> org.jboss.resteasy.plugins.providers
>>>> Thoughts?
>>>> I have already got most of this done and will be committing changes 
>>>> by next Monday. Please let me know if you see any issues with these 
>>>> changes. On a related note; we may also want to consider similar 
>>>> changes for the JSON providers as well as this issue will affect 
>>>> this provider also. Ryan-
>>>> ------------------------------------------------------------------------ 
>>>>
>>>> ------------------------------------------------------------------------- 
>>>>
>>>> This SF.Net email is sponsored by the Moblin Your Move Developer's 
>>>> challenge
>>>> Build the coolest Linux based applications with Moblin SDK & win 
>>>> great prizes
>>>> Grand prize is a trip for two to an Open Source event anywhere in 
>>>> the world
>>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>>> ------------------------------------------------------------------------ 
>>>>
>>>> _______________________________________________
>>>> 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
>>
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.7 (Darwin)
>>
>> iD8DBQFIhTHCK/xjmUY6JwURAqKeAJ9puaboJQHYWXXDcdGiDIjfhLFhKgCglCTO
>> w4kaOyjRu6QVvQF9H9pf1jQ=
>> =/uFk
>> -----END PGP SIGNATURE-----
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.7 (Darwin)
> 
> iD8DBQFIj+EiK/xjmUY6JwURAhL+AJ40MToEA065BLIBCzo2LBirrGrlTwCdGMw5
> DEzlIDmFV6+tA142VUGL864=
> =XbVv
> -----END PGP SIGNATURE-----

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

Re: [Resteasy-developers] @EJB: workaround available?

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

Ya, I've thought about this a lot and I don't want to create a new 
component model when we already have:

* EJB
* Seam
* Spring
* Web Beans

Ryan J. McDonough wrote:
> Jürgen,
> 
> I don't think we have this implemented yet, but with RESTEasy, you can 
> make the EJB itself a resource. Bill has an example of it in the 
> integration tests folder and I'll be committing and example app that 
> uses this on Wednesday.
> 
> Ryan-
> 
> On Jul 27, 2008, at 4:21 AM, Jürgen Zimmermann wrote:
> 
>> When using Jersey I could use a provider class to make @EJB available
>> (see below). Is there a similar workaround to use RESTeasy with JBoss
>> 4.2.3?
>>
>> import java.lang.reflect.Type;
>> import javax.ejb.EJB;
>> import javax.naming.Context;
>> import javax.naming.InitialContext;
>> import javax.naming.NamingException;
>> import javax.ws.rs.ext.Provider;
>> import com.sun.jersey.api.core.HttpContext;
>> import com.sun.jersey.spi.inject.Injectable;
>> import com.sun.jersey.spi.inject.InjectableProvider;
>> import com.sun.jersey.spi.service.ComponentContext;
>> import com.sun.jersey.spi.service.ComponentProvider.Scope;
>>
>> @Provider
>> public class EJBProvider implements InjectableProvider<EJB, Type> {
>> private static String JNDI_PREFIX = "hska/";
>> private static String JNDI_SUFFIX = "Bean/local";
>>
>> public Scope getScope() {
>> return Scope.Singleton;
>> }
>>
>> public Injectable<Object> getInjectable(ComponentContext
>> componentCtx, EJB ejb, Type type) {
>> if (!(type instanceof Class))
>> return null;
>>
>> final Class<?> clazz = (Class<?>) type;
>> try {
>> final Context ctx = new InitialContext();
>> final String jndiName = JNDI_PREFIX +
>> clazz.getSimpleName() + JNDI_SUFFIX;
>> final Object obj = ctx.lookup(jndiName);
>>
>> return new Injectable<Object>() {
>> public Object getValue(HttpContext c) {
>> return obj;
>> }
>> };
>> }
>> catch (NamingException e) {
>> e.printStackTrace();
>> return null;
>> }
>> }
>> }
>>
>>
>>
>>
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's 
>> challenge
>> Build the coolest Linux based applications with Moblin SDK & win great 
>> prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the 
>> world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/ 
>> <http://moblin-contest.org/redirect.php?banner_id=100&url=/>
>> _______________________________________________
>> Resteasy-developers mailing list
>> Res...@li... 
>> <mailto:Res...@li...>
>> https://lists.sourceforge.net/lists/listinfo/resteasy-developers
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> 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] RES: Mapping Parameters to Object

[Ryan J. M. <ry...@da...>]

Hey Rafael,

I just committed a FormUrlEncodedObjectProvider which does mostly what  
you want. To get it to work, you must annotate the value object with  
the @FormValues annotation, and each field that needs to be annotated  
with a @FormParam annotation. There's a unit test in src/test that  
shows how it all fits together. Going forward, here's what I'd like/ 
need to do:

* support @Encoded
* Don't require @FormParam if the field name matches the parameter name
* improve error handling

Let me know if this is where your thinking was at?

Ryan-


On Jul 29, 2008, at 10:43 AM, Rafael Pereira Nunes wrote:

> Probably we will have the same limitations of standard action.
> If you have a reference to other object/composition I can´t see how  
> to do this kind of injection.
> Like if the address in Person object was another Object instead a  
> String.
>
> class Person{
>   String name;
>   int age;
>   Address address;
> }
>
> How do you think in how to do that in a neat way?
>
> Feature Request opened:
> https://jira.jboss.org/jira/browse/RESTEASY-85
>
> I´m finishing some integration examples of RestEasy with another  
> platforms(Adobe Flex, Python, Ruby, HttpClient...) and I could help  
> with this feature if you want.
>
> --Rafael
> -----Mensagem original-----
> De: Ryan J. McDonough [mailto:ry...@da...]
> Enviada em: terça-feira, 29 de julho de 2008 10:01
> Para: Rafael Pereira Nunes
> Cc: res...@li...
> Assunto: Re: [Resteasy-developers] Mapping Parameters to Object
>
> HA HA! I have to chuckle a bit because this is some that Bill was
> trying to get into the JAX-RS spec but it got shot down. I think this
> is something that'll end up being a RESTEasy-specific feature, and I
> know it's something Bill was very interested in doing. In fact, I can
> think of a pretty neat way to do it too. If you can, please open a
> feature request for it so we don't for get ;) I'm finishing up some
> JAXB stuff now.
>
> Ryan-
>
> On Jul 28, 2008, at 10:34 AM, Rafael Pereira Nunes wrote:
>
>> I was thinking about something that I cannot found in any REST
>> framework(Restlet, Jersey, CXF...).
>> I would like to see something like the standard action of
>> JSP(<jsp:setProperty property="*">) when I found request parameters
>> that
>> matches with my object attributes I inject them.
>>
>> Something like:
>>
>> @POST
>> public void someMethod(Person person){...}
>>
>> And in the client:
>>
>> POST Body
>> name=John
>> age=25
>> gender=M
>> addres=blablabla
>>
>> And I inject them with:
>> person.setName("John")
>> person.setAge(25)
>> person.setGender('M')
>> person.setAddress("blablabla")
>>
>> And can see some problems with that, but not impossible to do.
>>
>> Is this possible? Or is it just a nonsense dream?
>>
>>
>> Rafael
>>
>>
>>
>>
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>> challenge
>> Build the coolest Linux based applications with Moblin SDK & win
>> great prizes
>> Grand prize is a trip for two to an Open Source event anywhere in
>> the world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> Resteasy-developers mailing list
>> Res...@li...
>> https://lists.sourceforge.net/lists/listinfo/resteasy-developers
>
>
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's  
> challenge
> Build the coolest Linux based applications with Moblin SDK & win  
> great prizes
> Grand prize is a trip for two to an Open Source event anywhere in  
> the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Resteasy-developers mailing list
> Res...@li...
> https://lists.sourceforge.net/lists/listinfo/resteasy-developers

Re: [Resteasy-developers] Changes to JAXBProviders

[Ryan J. M. <ry...@da...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I have committed the updated JAXB Providers and posted updated  
documentation here:

http://wiki.jboss.org/auth/wiki/BuiltInJAXBXMLProvider

I have also added some more unit tests to cover the different cases,  
but it could still use some more test coverage. With this all working,  
I'll also want to update the JSON provider so that it too can take  
advantage of these changes as well. Additionally, I also created a  
provider to handle FastinfoSets:

http://en.wikipedia.org/wiki/Fast_Infoset

Finally, I also committed a bunch of code for my example app which  
uses an EJB, Seam, and has some custom exception mappers. It also  
shows how you can handle cyclic references with JAXB and re-associate  
children with their parent objects on unmarshall. I have a Swing and  
Flex  GUI I'm wrapping up that'll pull it all together. Once that is  
complete, I'll update the documentation.

Ryan-

On Jul 21, 2008, at 9:02 PM, Ryan J. McDonough wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Absolutely! There are some very subtle differences for all of these  
> variations and i'll put those up on the wiki as part of the commit.
>
> Ryan-
>
>
> On Jul 21, 2008, at 8:38 AM, Bill Burke wrote:
>
>> Can you map out how people will configure and use these new JAXB  
>> providers?  That is the hardest part of all of this since we have  
>> to DI mechanism.
>>
>> Ryan J. McDonough wrote:
>>> I just opened:
>>> https://jira.jboss.org/jira/browse/RESTEASY-82
>>> Currently, our JAXBProvider does not handle classed which are  
>>> generated from an existing XML Schema by XJC. To resolve this, I  
>>> have refactored the JAXBProvider into a number of more specialized  
>>> providers:
>>> *JAXBContextCache*:
>>> A shared class for all JAXB providers to cache the various  
>>> JAXBContexts in use
>>> *JAXBXmlRootEntityProvider* :
>>> basically the same as our current JAXBProvider
>>> JAXBXmlTypeProvider:
>>> Generated classes won't have the @XmlRootEntity annotation on them  
>>> and therefore will be ignored. *JAXBElementProvider*:
>>> A JAXB provider for JAXBElement classes.
>>> With the number of classes here, I'm considering creating a jaxb  
>>> subpackage under:
>>> org.jboss.resteasy.plugins.providers
>>> Thoughts?
>>> I have already got most of this done and will be committing  
>>> changes by next Monday. Please let me know if you see any issues  
>>> with these changes. On a related note; we may also want to  
>>> consider similar changes for the JSON providers as well as this  
>>> issue will affect this provider also. Ryan-
>>> ------------------------------------------------------------------------
>>> -------------------------------------------------------------------------
>>> This SF.Net email is sponsored by the Moblin Your Move Developer's  
>>> challenge
>>> Build the coolest Linux based applications with Moblin SDK & win  
>>> great prizes
>>> Grand prize is a trip for two to an Open Source event anywhere in  
>>> the world
>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>> ------------------------------------------------------------------------
>>> _______________________________________________
>>> 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
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.7 (Darwin)
>
> iD8DBQFIhTHCK/xjmUY6JwURAqKeAJ9puaboJQHYWXXDcdGiDIjfhLFhKgCglCTO
> w4kaOyjRu6QVvQF9H9pf1jQ=
> =/uFk
> -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)

iD8DBQFIj+EiK/xjmUY6JwURAhL+AJ40MToEA065BLIBCzo2LBirrGrlTwCdGMw5
DEzlIDmFV6+tA142VUGL864=
=XbVv
-----END PGP SIGNATURE-----

[Resteasy-developers] RES: Mapping Parameters to Object

[Rafael P. N. <raf...@me...>]

Probably we will have the same limitations of standard action. 
If you have a reference to other object/composition I can´t see how to do this kind of injection.
Like if the address in Person object was another Object instead a String.

class Person{
   String name;
   int age;
   Address address;
}

How do you think in how to do that in a neat way?

Feature Request opened:
https://jira.jboss.org/jira/browse/RESTEASY-85

I´m finishing some integration examples of RestEasy with another platforms(Adobe Flex, Python, Ruby, HttpClient...) and I could help with this feature if you want.

--Rafael
-----Mensagem original-----
De: Ryan J. McDonough [mailto:ry...@da...] 
Enviada em: terça-feira, 29 de julho de 2008 10:01
Para: Rafael Pereira Nunes
Cc: res...@li...
Assunto: Re: [Resteasy-developers] Mapping Parameters to Object

HA HA! I have to chuckle a bit because this is some that Bill was  
trying to get into the JAX-RS spec but it got shot down. I think this  
is something that'll end up being a RESTEasy-specific feature, and I  
know it's something Bill was very interested in doing. In fact, I can  
think of a pretty neat way to do it too. If you can, please open a  
feature request for it so we don't for get ;) I'm finishing up some  
JAXB stuff now.

Ryan-

On Jul 28, 2008, at 10:34 AM, Rafael Pereira Nunes wrote:

> I was thinking about something that I cannot found in any REST
> framework(Restlet, Jersey, CXF...).
> I would like to see something like the standard action of
> JSP(<jsp:setProperty property="*">) when I found request parameters  
> that
> matches with my object attributes I inject them.
>
> Something like:
>
> @POST
> public void someMethod(Person person){...}
>
> And in the client:
>
> POST Body
> name=John
> age=25
> gender=M
> addres=blablabla
>
> And I inject them with:
> person.setName("John")
> person.setAge(25)
> person.setGender('M')
> person.setAddress("blablabla")
>
> And can see some problems with that, but not impossible to do.
>
> Is this possible? Or is it just a nonsense dream?
>
>
> Rafael
>
>
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's  
> challenge
> Build the coolest Linux based applications with Moblin SDK & win  
> great prizes
> Grand prize is a trip for two to an Open Source event anywhere in  
> the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Resteasy-developers mailing list
> Res...@li...
> https://lists.sourceforge.net/lists/listinfo/resteasy-developers

Re: [Resteasy-developers] Mapping Parameters to Object

[Ryan J. M. <ry...@da...>]

HA HA! I have to chuckle a bit because this is some that Bill was  
trying to get into the JAX-RS spec but it got shot down. I think this  
is something that'll end up being a RESTEasy-specific feature, and I  
know it's something Bill was very interested in doing. In fact, I can  
think of a pretty neat way to do it too. If you can, please open a  
feature request for it so we don't for get ;) I'm finishing up some  
JAXB stuff now.

Ryan-

On Jul 28, 2008, at 10:34 AM, Rafael Pereira Nunes wrote:

> I was thinking about something that I cannot found in any REST
> framework(Restlet, Jersey, CXF...).
> I would like to see something like the standard action of
> JSP(<jsp:setProperty property="*">) when I found request parameters  
> that
> matches with my object attributes I inject them.
>
> Something like:
>
> @POST
> public void someMethod(Person person){...}
>
> And in the client:
>
> POST Body
> name=John
> age=25
> gender=M
> addres=blablabla
>
> And I inject them with:
> person.setName("John")
> person.setAge(25)
> person.setGender('M')
> person.setAddress("blablabla")
>
> And can see some problems with that, but not impossible to do.
>
> Is this possible? Or is it just a nonsense dream?
>
>
> Rafael
>
>
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's  
> challenge
> Build the coolest Linux based applications with Moblin SDK & win  
> great prizes
> Grand prize is a trip for two to an Open Source event anywhere in  
> the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Resteasy-developers mailing list
> Res...@li...
> https://lists.sourceforge.net/lists/listinfo/resteasy-developers

Re: [Resteasy-developers] @EJB: workaround available?

[Ryan J. M. <ry...@da...>]

Jürgen,

I don't think we have this implemented yet, but with RESTEasy, you can  
make the EJB itself a resource. Bill has an example of it in the  
integration tests folder and I'll be committing and example app that  
uses this on Wednesday.

Ryan-

On Jul 27, 2008, at 4:21 AM, Jürgen Zimmermann wrote:

> When using Jersey I could use a provider class to make @EJB available
> (see below). Is there a similar workaround to use RESTeasy with JBoss
> 4.2.3?
>
> import java.lang.reflect.Type;
> import javax.ejb.EJB;
> import javax.naming.Context;
> import javax.naming.InitialContext;
> import javax.naming.NamingException;
> import javax.ws.rs.ext.Provider;
> import com.sun.jersey.api.core.HttpContext;
> import com.sun.jersey.spi.inject.Injectable;
> import com.sun.jersey.spi.inject.InjectableProvider;
> import com.sun.jersey.spi.service.ComponentContext;
> import com.sun.jersey.spi.service.ComponentProvider.Scope;
>
> @Provider
> public class EJBProvider implements InjectableProvider<EJB, Type> {
> 	private static String JNDI_PREFIX = "hska/";
> 	private static String JNDI_SUFFIX = "Bean/local";
>
> 	public Scope getScope() {
> 		return Scope.Singleton;
> 	}
>
> 	public Injectable<Object> getInjectable(ComponentContext
> componentCtx, EJB ejb, Type type) {
> 		if (!(type instanceof Class))
> 			return null;
>
> 		final Class<?> clazz = (Class<?>) type;
> 		try {
> 			final Context ctx = new InitialContext();
> 			final String jndiName = JNDI_PREFIX +
> clazz.getSimpleName() + JNDI_SUFFIX;
> 			final Object obj = ctx.lookup(jndiName);
>
> 			return new Injectable<Object>() {
> 				public Object getValue(HttpContext c) {
> 					return obj;
> 				}
> 			};
> 		}
> 		catch (NamingException e) {
> 			e.printStackTrace();
> 			return null;
> 		}
> 	}
> }
>
>
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's  
> challenge
> Build the coolest Linux based applications with Moblin SDK & win  
> great prizes
> Grand prize is a trip for two to an Open Source event anywhere in  
> the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Resteasy-developers mailing list
> Res...@li...
> https://lists.sourceforge.net/lists/listinfo/resteasy-developers

[Resteasy-developers] Mapping Parameters to Object

[Rafael P. N. <raf...@me...>]

I was thinking about something that I cannot found in any REST
framework(Restlet, Jersey, CXF...).
I would like to see something like the standard action of
JSP(<jsp:setProperty property="*">) when I found request parameters that
matches with my object attributes I inject them.

Something like:

@POST
public void someMethod(Person person){...}

And in the client:

POST Body
name=John
age=25
gender=M
addres=blablabla

And I inject them with:
person.setName("John")
person.setAge(25)
person.setGender('M')
person.setAddress("blablabla")

And can see some problems with that, but not impossible to do.

Is this possible? Or is it just a nonsense dream?


Rafael

[Resteasy-developers] @EJB: workaround available?

[Jürgen Z. <Jue...@HS...>]

When using Jersey I could use a provider class to make @EJB available
(see below). Is there a similar workaround to use RESTeasy with JBoss
4.2.3?

import java.lang.reflect.Type;
import javax.ejb.EJB;
import javax.naming.Context;
import javax.naming.InitialContext;
import javax.naming.NamingException;
import javax.ws.rs.ext.Provider;
import com.sun.jersey.api.core.HttpContext;
import com.sun.jersey.spi.inject.Injectable;
import com.sun.jersey.spi.inject.InjectableProvider;
import com.sun.jersey.spi.service.ComponentContext;
import com.sun.jersey.spi.service.ComponentProvider.Scope;

@Provider
public class EJBProvider implements InjectableProvider<EJB, Type> {
	private static String JNDI_PREFIX = "hska/";
	private static String JNDI_SUFFIX = "Bean/local";

	public Scope getScope() {
		return Scope.Singleton;
	}

	public Injectable<Object> getInjectable(ComponentContext
componentCtx, EJB ejb, Type type) {
		if (!(type instanceof Class))
			return null;

		final Class<?> clazz = (Class<?>) type;
		try {
			final Context ctx = new InitialContext();
			final String jndiName = JNDI_PREFIX +
clazz.getSimpleName() + JNDI_SUFFIX;
			final Object obj = ctx.lookup(jndiName);

			return new Injectable<Object>() {
				public Object getValue(HttpContext c) {
					return obj;
				}
			};
		}
		catch (NamingException e) {
			e.printStackTrace();
			return null;
		}
	}
}

[Resteasy-developers] jaxrs-api version should be the same

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

The jaxrs-api.jar should have the same version number as resteasy jars. 
  Why?  The spec is a moving target.  we may decide to implement a 
feature *before* it becomes official.  Or, I may we may only want to 
partially implement a newer version of the specification.

When the specification is final, we may remove the jaxrs-api jar 
entirely and use Sun's, but until then its versioning stays the say as 
all other resteasy jars.

Bill

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

[Resteasy-developers] i am Rallier

[rallier a. <ark...@ya...>]

i am Rallier 
   
  Permit me to inform you of my desire of going into business relationship with you,i got your mail from www.chatbelgie.be I am Ms Rallier Arkidy 19yrs the only child of Late Mr. & Mrs. Uzoh Arkidy.. My father was a very wealthy cocoa merchant in Abidjan , the economic capital of Ivory coast, my
 father was poisoned to death by his business associates on one of their outings on a business trip . 
   
  My mother died when I was a baby and since then my father took me so special. Before the death of my father on Feb. 2007 in a private hospital here he secretly called me on his bed side and told me that he has the sum of four million two hundred thausand dollar.($4.2Million) USD left in fixed /
 suspense account in one of the prime bank here in Abidjan, that he used my name as his only Daugher for the next of Kin in depositing of the fund. He also explained to me that it was because of this wealth that he was poisoned by his business ssociates.
   
  (1) To provide a bank account  which this money  will be transferred into . 
   
  (2) To serve as a guardian of this fund since I am only 19years. 
   
  (3) To make arrangement for me to come over to your country to further my education and to secure a resident permit in your country. 
   
  Moreover, Dear, I am willing to offer you 15% of the total sum as compensation for your effort/ input after the successful transfer of this fund into your nominated account 
   
  i am waiting to hear  from you,
   
  Rallier
 
 

 
---------------------------------
Stop! Global Warming ~ Yahoo! JAPAN Earth Project

Re: [Resteasy-developers] Changes to JAXBProviders

[Ryan J. M. <ry...@da...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Absolutely! There are some very subtle differences for all of these  
variations and i'll put those up on the wiki as part of the commit.

Ryan-


On Jul 21, 2008, at 8:38 AM, Bill Burke wrote:

> Can you map out how people will configure and use these new JAXB  
> providers?  That is the hardest part of all of this since we have to  
> DI mechanism.
>
> Ryan J. McDonough wrote:
>> I just opened:
>> https://jira.jboss.org/jira/browse/RESTEASY-82
>> Currently, our JAXBProvider does not handle classed which are  
>> generated from an existing XML Schema by XJC. To resolve this, I  
>> have refactored the JAXBProvider into a number of more specialized  
>> providers:
>> *JAXBContextCache*:
>> A shared class for all JAXB providers to cache the various  
>> JAXBContexts in use
>> *JAXBXmlRootEntityProvider* :
>> basically the same as our current JAXBProvider
>> JAXBXmlTypeProvider:
>> Generated classes won't have the @XmlRootEntity annotation on them  
>> and therefore will be ignored. *JAXBElementProvider*:
>> A JAXB provider for JAXBElement classes.
>> With the number of classes here, I'm considering creating a jaxb  
>> subpackage under:
>> org.jboss.resteasy.plugins.providers
>> Thoughts?
>> I have already got most of this done and will be committing changes  
>> by next Monday. Please let me know if you see any issues with these  
>> changes. On a related note; we may also want to consider similar  
>> changes for the JSON providers as well as this issue will affect  
>> this provider also. Ryan-
>> ------------------------------------------------------------------------
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's  
>> challenge
>> Build the coolest Linux based applications with Moblin SDK & win  
>> great prizes
>> Grand prize is a trip for two to an Open Source event anywhere in  
>> the world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> ------------------------------------------------------------------------
>> _______________________________________________
>> 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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)

iD8DBQFIhTHCK/xjmUY6JwURAqKeAJ9puaboJQHYWXXDcdGiDIjfhLFhKgCglCTO
w4kaOyjRu6QVvQF9H9pf1jQ=
=/uFk
-----END PGP SIGNATURE-----

Re: [Resteasy-developers] Changes to JAXBProviders

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

Can you map out how people will configure and use these new JAXB 
providers?  That is the hardest part of all of this since we have to DI 
mechanism.

Ryan J. McDonough wrote:
> I just opened:
> 
> https://jira.jboss.org/jira/browse/RESTEASY-82
> 
> Currently, our JAXBProvider does not handle classed which are generated 
> from an existing XML Schema by XJC. To resolve this, I have refactored 
> the JAXBProvider into a number of more specialized providers:
> 
> *JAXBContextCache*:
> A shared class for all JAXB providers to cache the various JAXBContexts 
> in use
> 
> *JAXBXmlRootEntityProvider* :
> basically the same as our current JAXBProvider
> 
> JAXBXmlTypeProvider:
> Generated classes won't have the @XmlRootEntity annotation on them and 
> therefore will be ignored. 
> 
> *JAXBElementProvider*:
> A JAXB provider for JAXBElement classes.
> 
> With the number of classes here, I'm considering creating a jaxb 
> subpackage under:
> 
> org.jboss.resteasy.plugins.providers
> 
> Thoughts?
> 
> I have already got most of this done and will be committing changes by 
> next Monday. Please let me know if you see any issues with these 
> changes. On a related note; we may also want to consider similar changes 
> for the JSON providers as well as this issue will affect this provider 
> also. 
> 
> Ryan-
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> 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

[Resteasy-developers] Changes to JAXBProviders

[Ryan J. M. <ry...@da...>]

I just opened:

https://jira.jboss.org/jira/browse/RESTEASY-82

Currently, our JAXBProvider does not handle classed which are  
generated from an existing XML Schema by XJC. To resolve this, I have  
refactored the JAXBProvider into a number of more specialized providers:

JAXBContextCache:
A shared class for all JAXB providers to cache the various  
JAXBContexts in use

JAXBXmlRootEntityProvider :
basically the same as our current JAXBProvider

JAXBXmlTypeProvider:
Generated classes won't have the @XmlRootEntity annotation on them and  
therefore will be ignored.

JAXBElementProvider:
A JAXB provider for JAXBElement classes.

With the number of classes here, I'm considering creating a jaxb  
subpackage under:

org.jboss.resteasy.plugins.providers

Thoughts?

I have already got most of this done and will be committing changes by  
next Monday. Please let me know if you see any issues with these  
changes. On a related note; we may also want to consider similar  
changes for the JSON providers as well as this issue will affect this  
provider also.

Ryan-

Re: [Resteasy-developers] [JBoss JIRA] Commented: (RESTEASY-81) @Context member variables in subresources are not injected (null)

[Martin A. <sp...@ma...>]

On 18 Jul 2008, at 17:34, Bill Burke wrote:

> Make it so, should be easy.
>

Uhm? I already did (and yes it was easy), and reverted it back since I  
didn't think we could go against the spec. You think I can?

M


> Martin Algesten wrote:
>> But thinking about this, it makes me question this part of the spec.
>> "An implementation is only required to set the annotated field and   
>> bean property values of instances created by the implementation   
>> runtime. Objects returned by sub-resource locators (see section  
>> 3.4.1)  are expected to be initialized by their creator and field  
>> and bean  properties are not modified by the implementation  
>> runtime."
>> Why does the spec use an injection style way of initialisation in  
>> the  first place? I guess because it's kinda new, cool, and less to  
>> write.
>> public class OldStyleResource implements UriInfoAware {
>>  private UriInfo uriInfo;
>>  // Called by framework to give us uriInfo.
>>  public void setUriInfo( UriInfo uriInfo ) {
>>    this.uriInfo = uriInfo;
>>  }
>>  public SubResource getSubResrouce() {...}
>> }
>> vs
>> public class ModernStyleResource {
>>  @Context
>>  private UriInfo uriInfo;
>> }
>> But why doesn't the same logic apply to subresoures? The fact that   
>> they've been instantiated by something else that in theory could  
>> pass  all the wanted references through doesn't seem to be  
>> adequate, what if  there's a whole heap of stuff to pass through?  
>> Doesn't the same  neatness logic apply?... I'm not saying that we  
>> should traverse the  whole object graph of the subresource and  
>> inject everywhere, just the  top level. if we're trying to do nice  
>> new ways of initialising why not  do it across the board?
>> M
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's  
>> challenge
>> Build the coolest Linux based applications with Moblin SDK & win  
>> great prizes
>> Grand prize is a trip for two to an Open Source event anywhere in  
>> the world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> 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
>