[JBoss JIRA] (FORGE-1277) Allow relationships to be conditionally emitted in REST resource representations
by Vineet Reynolds (JIRA)
[ https://issues.jboss.org/browse/FORGE-1277?page=com.atlassian.jira.plugin... ]
Vineet Reynolds commented on FORGE-1277:
----------------------------------------
In my opinion, this is a good addition to have. We should however handle the scenario (or the equivalent ):
If a client issues a GET with a filter parameter (like filterAllWithBooks), then the resource representation should not be used in a subsequent PUT request to update the entity. The resource representation used in such a PUT request would lack certain relationships, and thus such requests would result in incorrect updates.
I believe this could be done via documentation - clients should not be using filtered representations to represent updates in entities. Also we do not support HTTP PATCH (yet), so we should accept resource representations in whole and not in bits. It may also be necessary to ensure that the relationships are eagerly fetched by default (debatable on whether we should require clients to take the additional step of using the filter parameter to request the complete entity representation).
> Allow relationships to be conditionally emitted in REST resource representations
> --------------------------------------------------------------------------------
>
> Key: FORGE-1277
> URL: https://issues.jboss.org/browse/FORGE-1277
> Project: Forge
> Issue Type: Feature Request
> Components: Builtin Plugins
> Reporter: Vineet Reynolds
>
> From : http://lists.jboss.org/pipermail/forge-dev/2013-October/003484.html
> When you have too many @OneToMany or @ManyToMany relationships, you end up
> with several queries that JOIN FETCH several/different relationships. So
> what I usually do when things are complex is :
> findAll
> findAllWithRelations (meaning all relations are FETCH)
> or more specific (when things are really really complex)
> findAllWithBooks
> findAllWithAuthors
> findAllWithBooksAndAuthors
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months
[JBoss JIRA] (FORGEPLUGINS-143) The scaffolding should create JavaScript-based models
by Vineet Reynolds (JIRA)
Vineet Reynolds created FORGEPLUGINS-143:
--------------------------------------------
Summary: The scaffolding should create JavaScript-based models
Key: FORGEPLUGINS-143
URL: https://issues.jboss.org/browse/FORGEPLUGINS-143
Project: Forge Plugins
Issue Type: Enhancement
Components: AngularJS Scaffold
Reporter: Vineet Reynolds
Assignee: Vineet Reynolds
Currently the AngularJS scaffold uses ngResource objects as the model in the application. We should instead create separate JavaScript models for the AngularJS application, so that additional properties and functions can be added in a clean manner.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months
[JBoss JIRA] (FORGE-1275) @PUT method shouldn't have a @Path
by Antonio Goncalves (JIRA)
Antonio Goncalves created FORGE-1275:
----------------------------------------
Summary: @PUT method shouldn't have a @Path
Key: FORGE-1275
URL: https://issues.jboss.org/browse/FORGE-1275
Project: Forge
Issue Type: Bug
Components: Scaffold
Affects Versions: 1.4.2.Final
Reporter: Antonio Goncalves
Hi,
In the REST scaffolding, the generate {{update}} method looks like this :
{code}
@PUT
@Path("/{id:[0-9][0-9]*}")
@Consumes("application/xml")
public Response update(Book entity) {
em.merge(entity);
return Response.noContent().build();
}
{code}
The method has a {{@Path}} annotation with an id and therefore cannot be invoked (without the id that is not used in the method). So it should simply be :
{code}
@PUT
@Consumes("application/xml")
public Response update(Book entity) {
em.merge(entity);
return Response.noContent().build();
}
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months
[JBoss JIRA] (FORGE-1270) Forge 2.0.0.Aplha13 doesn't start on Windows
by Lincoln Baxter III (JIRA)
[ https://issues.jboss.org/browse/FORGE-1270?page=com.atlassian.jira.plugin... ]
Lincoln Baxter III commented on FORGE-1270:
-------------------------------------------
Okay. We've just released Alpha14. Do you think you could give that a try? Also, the Eclipse plugin should now build and run.
> Forge 2.0.0.Aplha13 doesn't start on Windows
> --------------------------------------------
>
> Key: FORGE-1270
> URL: https://issues.jboss.org/browse/FORGE-1270
> Project: Forge
> Issue Type: Bug
> Affects Versions: 2.0.0.Alpha13
> Environment: Win 7-64b, JDK 1.7.0_45, forge 2.0.0.Alpha13
> Reporter: Fred Bricon
> Priority: Blocker
>
> * Start forge
> * Forge banner is shown
> * Prompt never shows up
> See threaddump :
> {noformat}
> 2013-10-20 10:37:12
> Full thread dump Java HotSpot(TM) 64-Bit Server VM (24.45-b08 mixed mode):
> "Reference Reaper" daemon prio=6 tid=0x000000000c994000 nid=0x259c in Object.wait() [0x000000000d9af000]
> java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <0x00000007d6c50bc8> (a java.lang.ref.ReferenceQueue$Lock)
> at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:135)
> - locked <0x00000007d6c50bc8> (a java.lang.ref.ReferenceQueue$Lock)
> at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:151)
> at org.jboss.modules.ref.References$ReaperThread.run(References.java:68)
> "Service Thread" daemon prio=6 tid=0x000000000a9c8000 nid=0x1b68 runnable [0x0000000000000000]
> java.lang.Thread.State: RUNNABLE
> "C2 CompilerThread1" daemon prio=10 tid=0x000000000a9c6000 nid=0x2380 waiting on condition [0x0000000000000000]
> java.lang.Thread.State: RUNNABLE
> "C2 CompilerThread0" daemon prio=10 tid=0x000000000a9c1000 nid=0x1bdc waiting on condition [0x0000000000000000]
> java.lang.Thread.State: RUNNABLE
> "Attach Listener" daemon prio=10 tid=0x000000000a9bf000 nid=0x209c waiting on condition [0x0000000000000000]
> java.lang.Thread.State: RUNNABLE
> "Signal Dispatcher" daemon prio=10 tid=0x000000000a9b8000 nid=0x22e0 runnable [0x0000000000000000]
> java.lang.Thread.State: RUNNABLE
> "Finalizer" daemon prio=8 tid=0x000000000a969800 nid=0x1b58 in Object.wait() [0x000000000bc8f000]
> java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <0x00000007d6605568> (a java.lang.ref.ReferenceQueue$Lock)
> at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:135)
> - locked <0x00000007d6605568> (a java.lang.ref.ReferenceQueue$Lock)
> at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:151)
> at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:189)
> "Reference Handler" daemon prio=10 tid=0x000000000a95e000 nid=0x1b80 in Object.wait() [0x000000000be2f000]
> java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <0x00000007d66050f0> (a java.lang.ref.Reference$Lock)
> at java.lang.Object.wait(Object.java:503)
> at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:133)
> - locked <0x00000007d66050f0> (a java.lang.ref.Reference$Lock)
> "main" prio=6 tid=0x00000000023af000 nid=0x1124 waiting on condition [0x00000000027df000]
> java.lang.Thread.State: TIMED_WAITING (sleeping)
> at java.lang.Thread.sleep(Native Method)
> at org.jboss.forge.furnace.impl.FurnaceImpl.start(FurnaceImpl.java:177)
> at org.jboss.forge.furnace.impl.FurnaceImpl.start(FurnaceImpl.java:122)
> at org.jboss.forge.bootstrap.Bootstrap.start(Bootstrap.java:170)
> at org.jboss.forge.bootstrap.Bootstrap.main(Bootstrap.java:88)
> "VM Thread" prio=10 tid=0x000000000a958800 nid=0x24a0 runnable
> "GC task thread#0 (ParallelGC)" prio=6 tid=0x000000000229e800 nid=0x1d70 runnable
> "GC task thread#1 (ParallelGC)" prio=6 tid=0x00000000022a0800 nid=0x7e8 runnable
> "GC task thread#2 (ParallelGC)" prio=6 tid=0x00000000022a2000 nid=0x1694 runnable
> "GC task thread#3 (ParallelGC)" prio=6 tid=0x00000000022a3800 nid=0xe70 runnable
> "VM Periodic Task Thread" prio=10 tid=0x000000000a9de000 nid=0x1e7c waiting on condition
> JNI global references: 134
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months
[JBoss JIRA] (FORGE-1273) REST NOT_FOUND should be NO_CONTENT
by George Gastaldi (JIRA)
[ https://issues.jboss.org/browse/FORGE-1273?page=com.atlassian.jira.plugin... ]
George Gastaldi updated FORGE-1273:
-----------------------------------
Component/s: Java EE APIs
> REST NOT_FOUND should be NO_CONTENT
> -----------------------------------
>
> Key: FORGE-1273
> URL: https://issues.jboss.org/browse/FORGE-1273
> Project: Forge
> Issue Type: Enhancement
> Components: Java EE APIs, Scaffold
> Affects Versions: 1.4.2.Final
> Reporter: Antonio Goncalves
> Fix For: 2.x Future
>
> Attachments: rest.tiff, rest2.tiff
>
>
> Hi,
> In the REST endpoint generated code we have the following methods that return a Status.NOT_FOUND status in case the entity is not found :
> {code}
> @DELETE
> @Path("/{id:[0-9][0-9]*}")
> public Response deleteById(@PathParam("id") Long id)
> {
> Book entity = em.find(Book.class, id);
> if (entity == null)
> {
> return Response.status(Status.NOT_FOUND).build();
> }
> em.remove(entity);
> return Response.noContent().build();
> }
> @GET
> @Path("/{id:[0-9][0-9]*}")
> @Produces("application/xml")
> public Response findById(@PathParam("id") Long id)
> {
> TypedQuery<Book> findByIdQuery = em.createQuery("SELECT DISTINCT b FROM Book b WHERE b.id = :entityId ORDER BY b.id", Book.class);
> findByIdQuery.setParameter("entityId", id);
> Book entity;
> try
> {
> entity = findByIdQuery.getSingleResult();
> }
> catch (NoResultException nre)
> {
> entity = null;
> }
> if (entity == null)
> {
> return Response.status(Status.NOT_FOUND).build();
> }
> return Response.ok(entity).build();
> }
> {code}
> In both cases it should be a Status.NO_CONTENT. The resource exists (otherwise it would have been impossible to invoke it) it just happens that it returns an empty body (with a no content status)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months