In the 'Project Overview' section I think you should introduce the
basic idea that a
designer needs to extend a 'resource helper' class. This isn't
explicitly made clear until
the API section, but a number of code-snippets mention super
and getPrimaryKey(info)
In the 'Testing' section you should mention the use of the built-in
Javase 6 HTTPServer, which
allows simplified end-to-end testing without having to deal with
AppServer deployment issues.
---
Mike Norman | Principal Software Designer
Phone: +6132884638 | | Fax: +6132382818 |
Oracle Oracle Server Technologies,
EclipseLink Product
ORACLE Canada | 45 O'Connor Street, Suite 400, Ottawa, Ontario | K1P 1A4
Oracle is committed to developing practices and products that
help protect the environment
On 07/10/2010 10:31 AM, Blaise Doughan wrote:
Hello All,
The design doc has been updated:
Reminder the review is scheduled for tomorrow (Friday) at 1pm EDT.
-Blaise
Blaise Doughan wrote:
Hello All,
The design review has been re-scheduled for this Friday at 1pm EDT.
-Blaise
Blaise Doughan wrote:
Hello All,
The design review has been scheduled for this Friday at 3pm EDT.
Please contact me if you require dial in information.
-Blaise
Blaise Doughan wrote:
Hi Tom,
Thanks for the feed back. I'll address your questions below inlined in
blue.
Tom Ware wrote:
Hi
Blaise,
Some comments/questions:
--------
- I am kind of surprised how different the URLs for simple PKs and
composite PKs are.
i.e. if a composite PK looks like this:
"http://www.example.com/customer-app/rest/customers;id=1;country=CA"
Why isn't a simple PK more like this:
"http://www.example.com/customer-app/rest/customers;id=1"
The ideal URL for a RESTful resource is
like
the
one below with the ID as part of the path:
http://www.example.com/customer-app/rest/customers/1
This type of pattern can be seen all over the web:
It is for the composite key case that we
need
to
deviate from the standard representation:
-----------
- For queries, how do you distinguish if the URL refers to a query or a
find?
i.e. How do you know http://www.example.com/customer-app/rest/customers/findCustomerByName
isn't referring to an entity called "findCustomerByName"?
Is it the fact that I have some reserved words, "singleResult" and
"resultList" that come later in the URL?
The RESTful JPA service will be limited
to
one
root entity. This entity will be the input and output of all
operations. The supported named queries will be limited to named
queries that return one or many instances of that entity (or subtypes).
For the following URL:
http://www.example.com/customer-app/rest/customers/findCustomerByName/resultList
- "findCustomersByName" is the name
of
the
named query, passing in another path fragment will cause another named
query to be created
- resultList & singleResult are
reserved
path names to indicate the result type
-----------
How is the initial metadata obtained? How is the session built?
The user implemented subclass is
responsible
for
implementing a method called entityManager() to return the
entityManager. I expect that users will implement their RESTful
service as a session bean and will gain access to the EntityMangager
through the use of @PersistenceContext.
-----------
How do you figure out the parameter types for named queries?
Are there core features that need implementation for this to work?
-----------
-Tom
The parameter types for named queries can
be
obtained from the name query itself. No features are required, only a
fix to the following bug:
Blaise Doughan wrote:
Hello All,
I am developing a new EclipseLink feature that will expose a JPA
EnitityManager as a RESTful (JAX-RS) service. The relevant collateral
can be found below. I will send out design review details soon.
*Enhancement Request:*
* http://bugs.eclipse.org/326663
*Design Document:*
* http://wiki.eclipse.org/EclipseLink/DesignDocs/326663
-Blaise
------------------------------------------------------------------------
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
-Blaise
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
|
