Nam Nguyen wrote:
> Paul Sandoz wrote:
>> Nam Nguyen wrote:
>>> This is already implemented by Peter. For example:
>>> http://localhost:8085/WebApplication9//resources/customers/?start=0&max=10
>>>
>>
>> Oops, i should keep more up to date. Very good! i just had a close
>> look at the generated code :-)
>>
>> Is there a change log between updates and/or feature set docs that i
>> should be looking at?
> This is one I would love to know how jersey project infrastructure setup
> for it.
I do it by hand, just adding things as i make changes. I would like to
automate it somehow...
> For now, roughly we have to rely on engineering plans:
> http://wiki.netbeans.org/wiki/view/RESTFcsPlan
> http://wiki.netbeans.org/wiki/view/RESTNb6.1Plan
Thanks.
>>
>> For the CustomerDB generated code I like the way you are using an
>> anonymous inner class in the for the customers associated with a
>> discount code.
> On the other hand, I also like Jersey example Bookmark utility class
> TransactionManager and abstract Transactional. It is neat and making
> use of JTA as well as container-manager persistence. With a quick
> comparison, one can see that the plugin generated resource transaction
> code made assumption of local transaction which I think reasonable and
> have better performance. We might need to somehow give user choice of
> either transaction model.
Perhaps the downside to TransactionManager is it encourages use of
anonymous inner classes, which causes some serious head scratching for
some developers.
I think the generated persistence class could also make use of the same
mechanism (efficiently) by the use of anonymous inner classes i.e.
essentially they are an ugly form of closure.
>>
>> It would be nice if Jersey could help in the support of persistence,
>> for example by perhaps providing its own persistence service like the
>> one generated.
> I think this would be cool as it will simplify application code.
Agreed.
>> I think WebBeans could be a lot of help here to inject stuff
> Could you please explain more.
My undestanding is WebBeans will be able support injection of the right
managed persistence stuff and also support transacted invocations of
suitably annotated HTTP methods of a resource, of that resource is
managed by a WebBeans container i.e. it can give many useful things from
EJBs without having to be an EJB, and we don't have to implement such
stuff ourselves.
>> and have transacted HTTP methods.
> Maybe I missed something. Wouldn't this be against the goal of
> REST-style: achieve stateless accesses to resource?
>
I don't think so IIUC, as the transaction is only scoped for the method
call and not over multiple requests/responses. It is a bit like calling
the start transaction before you call the method and the commit
transaction (or rollback on error) after the call.
Paul.
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109