[
https://issues.jboss.org/browse/FORGE-1074?page=com.atlassian.jira.plugin...
]
Vineet Reynolds commented on FORGE-1074:
----------------------------------------
Care must be taken to ensure that FORGE-1060 considers this scenario, since DTOs could
have a setter, while the JPA entity may not.
REST plugin fails to generate resources for entities lacking a setter
for the @Id field
---------------------------------------------------------------------------------------
Key: FORGE-1074
URL:
https://issues.jboss.org/browse/FORGE-1074
Project: Forge
Issue Type: Bug
Components: Builtin Plugins
Affects Versions: 1.3.3.Final
Reporter: Vineet Reynolds
The following exception is thrown when attempting to create a REST resource for an entity
that only has a getter for the {{@Id}} field:
{noformat}
***ERROR*** Exception encountered: (type "set VERBOSE false" to disable stack
traces)
java.lang.RuntimeException: Could not determine @Id field and setter method for @Entity
[org.jboss.jdf.example.ticketmonster.model.EventCategory]. Aborting.
at org.jboss.forge.spec.javaee.rest.RestPlugin.resolveIdSetterName(RestPlugin.java:305)
at org.jboss.forge.spec.javaee.rest.RestPlugin.endpointFromEntity(RestPlugin.java:157)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.jboss.forge.shell.command.Execution.perform(Execution.java:160)
at org.jboss.forge.shell.command.fshparser.FSHRuntime.run(FSHRuntime.java:109)
at org.jboss.forge.shell.command.fshparser.FSHRuntime.run(FSHRuntime.java:47)
at org.jboss.forge.shell.ShellImpl$ExecutorThread.run(ShellImpl.java:795)
at org.jboss.forge.shell.ShellImpl.execute(ShellImpl.java:818)
at org.jboss.forge.shell.ShellImpl.doShell(ShellImpl.java:608)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.jboss.weld.bean.proxy.AbstractBeanInstance.invoke(AbstractBeanInstance.java:48)
at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:125)
at
org.jboss.forge.shell.ShellImpl$Proxy$_$$_WeldClientProxy.doShell(ShellImpl$Proxy$_$$_WeldClientProxy.java)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.jboss.weld.util.reflection.SecureReflections$13.work(SecureReflections.java:305)
at
org.jboss.weld.util.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:54)
at
org.jboss.weld.util.reflection.SecureReflectionAccess.runAsInvocation(SecureReflectionAccess.java:163)
at org.jboss.weld.util.reflection.SecureReflections.invoke(SecureReflections.java:299)
at
org.jboss.weld.introspector.jlr.WeldMethodImpl.invokeOnInstance(WeldMethodImpl.java:188)
at
org.jboss.weld.introspector.ForwardingWeldMethod.invokeOnInstance(ForwardingWeldMethod.java:59)
at
org.jboss.weld.injection.MethodInjectionPoint.invokeOnInstanceWithSpecialValue(MethodInjectionPoint.java:198)
at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:282)
at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:265)
at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:234)
at org.jboss.weld.manager.BeanManagerImpl.notifyObservers(BeanManagerImpl.java:635)
at org.jboss.weld.manager.BeanManagerImpl.fireEvent(BeanManagerImpl.java:622)
at org.jboss.weld.manager.BeanManagerImpl.fireEvent(BeanManagerImpl.java:616)
at org.jboss.forge.shell.Bootstrap$1.run(Bootstrap.java:186)
at java.lang.Thread.run(Thread.java:722)
{noformat}
This should not be the case. REST resources should be generated for entities that have
only a getter in this instance. There is no need to set the {{@Id}} of the entity.
Currently, the Id setter method is invoked during an update. but then the entity
representation already carries the Id, and the HTTP constraints for PUT ensure that the
body of the PUT request will contain the Id. This is because the HTTP body for PUT should
contain the full resource representation - if the original one contained the Id, then the
PUT request body should contain it.
Besides, the JPA specification does not recommend changing the Id and specifies the
resulting behavior as undefined. Therefore, there should be no pre-requisite for the
{{@Id}} field to have a setter. A straight forward merge of the de-serialized request into
the persistence context would be sufficient.
--
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