Paul Sandoz wrote:
> 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.
>
Any idea when the things we discussed here may become reality? Also,
perhaps support for some form of memory caching can be part of this?
Thanks
Peter