users@jersey.java.net

Re: [Jersey] Re: GFv3 with MySQL 5.1.44 (or Derby) with DB generated Identity problems (and NetBeans+Jersey FTW)

From: mkuchtiak <Milan.Kuchtiak_at_Sun.COM>
Date: Mon, 12 Apr 2010 15:08:33 +0200

Hi Gregory,

I am part of Netbeans team who developed "Generate REST from Entity
Beans" Netbeans feature.
There were no big changes after Netbeans 6.5, except of simplifying REST
generation for Jave EE 6 project types.
The idea of this feature was to show user how Entity Beans, JAXB and
REST can be combined together to create a REST "Facade".
It's up to user to modify those classes later.

Another option there is to create a "Session bean from Entity Class"
(Session Bean facade for Entity), then annotate this session bean by
using JAX-RS annotations.

Milan


Paul Sandoz wrote:
> Hi Gregory,
>
> Did you get any answers/help to this?
>
> IMHO the JAX-RS auto-generation from entities needs more work. Note
> that it is not something the Jersey team has developed. I need to
> determine if this is being actively developed further, i am not sure
> it is at the moment.
>
> Paul.
>
> On Apr 5, 2010, at 7:58 AM, Gregory Gerard wrote:
>
>> This is a combination of JPA and transaction semantics that I'm not
>> clear on.
>>
>> If I use a sequence table, my object's PK will be set after calling
>> em.persist(obj). If I use IDENTITY, it's null. Doesn't matter if it's
>> Derby or MySQL (nor should it but I just wanted to rule out the DB).
>>
>> Hmm. I call em.flush() and em.refresh(obj) to get back a usable
>> identity to tell my client.
>>
>> However, when using NetBeans' automatic entity generation thingy with
>> JAX-RS, things don't work of course.
>>
>> When I create an object using curl, the location header returned is
>> incorrect in two ways and I'm not sure why.
>>
>> 1. If I don't tweak the generated code (resolveEntity is where I
>> chose to put the em.flush() and em.refresh() calls), the location
>> header comes back as null making it impossible to have something
>> URN-like for chasing the resource down.
>> 2. The Location header also doesn't include the name of the
>> collection where said entity could be looked up again.
>>
>> Has anyone else noticed this? Is the automatic generation worth
>> pursuing or is it not considered appropriate for production? It seems
>> like decent code and technique -- I can't be the first to have run
>> across this issue but I haven't found any updates to NetBeans that
>> would fix it.
>>
>> I really don't want to add a DAO layer -- it's so repulsive, but I
>> don't see an alternative since every entity needs to be flushed and
>> refreshed to be useful in a web service or page.
>>
>> thanks,
>> greg
>>
>> curl -v -X POST --data-binary @asite.xml -H"Content-Type:
>> application/xml" -H"Accept: application/xml"
>> http://localhost:8080/com.ggerard.gravity/resources/sites
>> * About to connect() to localhost port 8080 (#0)
>> * Trying 127.0.0.1... connected
>> * Connected to localhost (127.0.0.1) port 8080 (#0)
>>> POST /com.ggerard.gravity/resources/sites HTTP/1.1
>>> User-Agent: curl/7.19.6 (i386-apple-darwin10.0.0) libcurl/7.19.6
>>> zlib/1.2.3
>>> Host: localhost:8080
>>> Content-Type: application/xml
>>> Accept: application/xml
>>> Content-Length: 615
>>>
>> < HTTP/1.1 201 Created
>> < X-Powered-By: Servlet/3.0
>> < Server: GlassFish v3
>> < Location: http://localhost:8080/com.ggerard.gravity/resources/1/
>> < Content-Length: 0
>> < Date: Mon, 05 Apr 2010 05:41:07 GMT
>> <
>> * Connection #0 to host localhost left intact
>> * Closing connection #0
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>