[JBoss JIRA] (FORGE-1075) REST plugin should detect if an existing JAX-RS resource is mapped to the same @Path
by Vineet Reynolds (JIRA)
[ https://issues.jboss.org/browse/FORGE-1075?page=com.atlassian.jira.plugin... ]
Vineet Reynolds updated FORGE-1075:
-----------------------------------
Summary: REST plugin should detect if an existing JAX-RS resource is mapped to the same @Path (was: REST plugin shoudl detect if an existing JAX-RS resource is mapped to the same @Path in the project)
> REST plugin should detect if an existing JAX-RS resource is mapped to the same @Path
> ------------------------------------------------------------------------------------
>
> Key: FORGE-1075
> URL: https://issues.jboss.org/browse/FORGE-1075
> Project: Forge
> Issue Type: Feature Request
> Components: Builtin Plugins
> Affects Versions: 1.3.3.Final
> Reporter: Vineet Reynolds
>
> When an existing resource in a project already maps to a Path, it may conflict with the JAX-RS resource newly created by the REST plugin.
> The REST plugin should therefore create the JAX-RS resource only when it is certain (to a degree) that there are no conflicting paths.
> This would have to be done for several cases including:
> * JAX-RS resources
> * JAX-RS sub-resources
> * JAX-RS resources and sub-resources across projects (may have to wait until binary inspection can be done)
--
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
10 years, 11 months
[JBoss JIRA] (FORGE-1075) REST plugin shoudl detect if an existing JAX-RS resource is mapped to the same @Path in the project
by Vineet Reynolds (JIRA)
Vineet Reynolds created FORGE-1075:
--------------------------------------
Summary: REST plugin shoudl detect if an existing JAX-RS resource is mapped to the same @Path in the project
Key: FORGE-1075
URL: https://issues.jboss.org/browse/FORGE-1075
Project: Forge
Issue Type: Feature Request
Components: Builtin Plugins
Affects Versions: 1.3.3.Final
Reporter: Vineet Reynolds
When an existing resource in a project already maps to a Path, it may conflict with the JAX-RS resource newly created by the REST plugin.
The REST plugin should therefore create the JAX-RS resource only when it is certain (to a degree) that there are no conflicting paths.
This would have to be done for several cases including:
* JAX-RS resources
* JAX-RS sub-resources
* JAX-RS resources and sub-resources across projects (may have to wait until binary inspection can be done)
--
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
10 years, 11 months
[JBoss JIRA] (FORGE-1074) REST plugin fails to generate resources for entities lacking a setter for the @Id field
by Vineet Reynolds (JIRA)
[ https://issues.jboss.org/browse/FORGE-1074?page=com.atlassian.jira.plugin... ]
Vineet Reynolds closed FORGE-1074.
----------------------------------
Assignee: Vineet Reynolds
Fix Version/s: 1.3.4.Final
Resolution: Done
Pushed upstream: https://github.com/forge/core/commit/48431eb99938e312457a8934cb60cf3b3415...
> 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
> Assignee: Vineet Reynolds
> Fix For: 1.3.4.Final
>
>
> 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
10 years, 11 months
[JBoss JIRA] (FORGEPLUGINS-120) Invalid AngularJS controllers are generated
by Vineet Reynolds (JIRA)
[ https://issues.jboss.org/browse/FORGEPLUGINS-120?page=com.atlassian.jira.... ]
Vineet Reynolds edited comment on FORGEPLUGINS-120 at 8/2/13 7:54 AM:
----------------------------------------------------------------------
This is due to the type of the class lacking a primary key annotated with {{@Id}}. In this case, the entities generated from the Sakila-H2 model includes the {{FilmActor}} entity that contains an {{@EmbeddedId}} instead of a plain {{@Id}}.
was (Author: vineet.reynolds):
This is due to the type of the class lacking a primary key annotated with {{@Id}}. In this case, the entities generated from the Sakila-H2 model includes the {FilmActor} entity that contains an {{@EmbeddedId}} instead of a plain {{@Id}}.
> Invalid AngularJS controllers are generated
> -------------------------------------------
>
> Key: FORGEPLUGINS-120
> URL: https://issues.jboss.org/browse/FORGEPLUGINS-120
> Project: Forge Plugins
> Issue Type: Bug
> Components: AngularJS Scaffold
> Environment: AngularJS scaffold plugin v1.0.1.Final
> Reporter: Vineet Reynolds
> Assignee: Vineet Reynolds
>
> The following code is generated in the AngularJS controllers via the Scaffolding plugin:
> {noformat}
> if($scope.actor.filmActors){
> $.each($scope.actor.filmActors, function(idx, element) {
> if(item. == element.) {
> $scope.filmActorsSelection.push(wrappedObject);
> }
> });
> }
> {noformat}
> Note the invalid comparison expression.
--
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
10 years, 11 months
[JBoss JIRA] (FORGEPLUGINS-123) AngularJS scaffolding should scaffold @Embedded properties correctly
by Vineet Reynolds (JIRA)
Vineet Reynolds created FORGEPLUGINS-123:
--------------------------------------------
Summary: AngularJS scaffolding should scaffold @Embedded properties correctly
Key: FORGEPLUGINS-123
URL: https://issues.jboss.org/browse/FORGEPLUGINS-123
Project: Forge Plugins
Issue Type: Bug
Components: AngularJS Scaffold
Reporter: Vineet Reynolds
Assignee: Vineet Reynolds
Currently {{@Embedded}} properties are treated as a single property and not expanded in the create and edit views; this results in the input text boxes displaying something like [object Object] for an existing embedded property of an entity.
Also, the search results display the JSON representation of the object instead of one or several properties of the object. This needs correction.
--
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
10 years, 11 months
[JBoss JIRA] (FORGE-1054) Forge OpenShift plugin hangs when creating a JBoss app in Windows
by Lincoln Baxter III (JIRA)
[ https://issues.jboss.org/browse/FORGE-1054?page=com.atlassian.jira.plugin... ]
Lincoln Baxter III reassigned FORGE-1054:
-----------------------------------------
Assignee: William DeCoste
Hey Bill,
I hope I'm not bugging you. It looks like something might have changed and broken the Openshift plugin again. Could you spare a few minutes to check this out?
Thanks!
> Forge OpenShift plugin hangs when creating a JBoss app in Windows
> -----------------------------------------------------------------
>
> Key: FORGE-1054
> URL: https://issues.jboss.org/browse/FORGE-1054
> Project: Forge
> Issue Type: Bug
> Affects Versions: 1.3.3.Final
> Environment: Window7
> Git-1.8.3-preview2013.6.1 jdk-7u25-windows-x64
> Reporter: nan wei
> Assignee: William DeCoste
>
> Description of problem:
> When creating a jboss app, app creation process hang there.
> Version:
> forge-distribution-1.3.3.Final.zip
> Window7
> Git-1.8.3-preview2013.6.1 jdk-7u25-windows-x64
> How reproducible:
> always
> Steps to Reproduce:
> 1. Ensure that you have already installed a Java 6+ JDK.
> 1.1 install jdk-7u25-windows-x64
> 1.2 set JAVA_HOME.
> 2. Download Forge 1.3.2.Final and Un-zip Forge into a folder on your hard-disk, this folder will be your FORGE_HOME.
> 2.1 Add '$FORGE_HOME/bin' to your windows path.
> 2.2 installing Git(Git-1.8.3-preview2013.6.1)
> 3. Open a command prompt and run 'forge.bat'.
> 4. Install OpenShift plugin for forge.
> 5. create a jboss app.
> Actual results:
> [forge-openshift-demo] forge-openshift-demo $ rhc setup
> ***INFO*** Loaded OpenShift configuration from C:\Users\nanwei/.openshift/expres
> s.conf
> ? Enter the application name [forgeopenshiftd] [forgeopenshiftd] wsy
> ***INFO*** Using RHLOGIN:nwei for https://10.4.59.171
> ? Enter your Red Hat Openshift password: ******
> ***INFO*** Found OpenShift User: nwei
> Choose a JBoss Cartridge:
>
> 1 - [Cartridge [name=jbosseap-6.0]]*
> 2 - [Cartridge [name=jbossews-2.0]]
> 3 - [Cartridge [name=jbossews-1.0]]
>
> ? Choose an option by typing the number of the selection [*-default] [0] 1
> ***INFO*** Using JBoss Cartridge: jbosseap-6.0
> Initialized empty Git repository in C:/Users/nanwei/Downloads/forge/bin/forge-op
> enshift-demo/.git/
> ***INFO*** Waiting for OpenShift to propagate DNS
> ***INFO*** Trying to contact http://forge-nweidomain.osetestv2.com/ (attempt 1 of
> 500)
> Updating openshift
> Expected results:
> The process will hang there for ever.
> Additional info:
--
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
10 years, 11 months
[JBoss JIRA] (FORGE-1074) REST plugin fails to generate resources for entities lacking a setter for the @Id field
by Vineet Reynolds (JIRA)
[ 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
10 years, 11 months
[JBoss JIRA] (FORGE-1074) REST plugin fails to generate resources for entities lacking a setter for the @Id field
by Vineet Reynolds (JIRA)
Vineet Reynolds created FORGE-1074:
--------------------------------------
Summary: 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
10 years, 11 months