[JBoss JIRA] (AS7-3217) Eliminate arquillian/container-managed-domain module
by Brian Stansberry (Created) (JIRA)
Eliminate arquillian/container-managed-domain module
----------------------------------------------------
Key: AS7-3217
URL: https://issues.jboss.org/browse/AS7-3217
Project: Application Server 7
Issue Type: Task
Components: Domain Management, Test Suite
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Priority: Minor
Fix For: 7.1.0.Final
Get rid of the current arquillian/container-managed-domain module in the AS7 source tree and move the couple classes there to the testsuite/domain module. That's the only place they are used, and their current location implies they are a proper arquillian container implementation, which isn't the case. They're just some utilities that I hoped someday to turn into a proper container implementation.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 3 months
[JBoss JIRA] (AS7-3072) SecurityException deploying login quickstart on a server with signed jars
by Marek Schmidt (Created) (JIRA)
SecurityException deploying login quickstart on a server with signed jars
-------------------------------------------------------------------------
Key: AS7-3072
URL: https://issues.jboss.org/browse/AS7-3072
Project: Application Server 7
Issue Type: Bug
Components: CDI / Weld
Affects Versions: 7.1.0.Beta1b
Reporter: Marek Schmidt
Assignee: Stuart Douglas
Priority: Blocker
Fix For: 7.1.0.Final
Attempting to deploy the "login" quickstart on AS7 with signed modules fails with the following exception:
{noformat}
17:35:11,860 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC00001: Failed to start service jboss.deployment.unit."jboss-as-login.war".WeldService: org.jboss.msc.service.StartException in service jboss.deployment.unit."jboss-as-login.war".WeldService: org.jboss.weld.exceptions.WeldException: by java.lang.SecurityException: class "org.jboss.as.quickstarts.login.UserManager$-2022604038$Proxy$_$$_Weld$Proxy$"'s signer information does not match signer information of other classes in the same package
at org.jboss.as.weld.services.WeldService.start(WeldService.java:96)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1824) [jboss-msc-1.0.1.GA.jar:]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1759) [jboss-msc-1.0.1.GA.jar:]
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_24]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_24]
at java.lang.Thread.run(Thread.java:662) [:1.6.0_24]
Caused by: org.jboss.weld.exceptions.WeldException: by java.lang.SecurityException: class "org.jboss.as.quickstarts.login.UserManager$-2022604038$Proxy$_$$_Weld$Proxy$"'s signer information does not match signer information of other classes in the same package
at org.jboss.weld.bean.proxy.ProxyFactory.getProxyClass(ProxyFactory.java:273)
at org.jboss.weld.bean.SessionBean.initProxyClass(SessionBean.java:231)
at org.jboss.weld.bean.SessionBean.initialize(SessionBean.java:164)
at org.jboss.weld.bean.AbstractProducerBean.initialize(AbstractProducerBean.java:174)
at org.jboss.weld.bean.ProducerMethod.initialize(ProducerMethod.java:115)
at org.jboss.weld.bootstrap.AbstractBeanDeployer.deploy(AbstractBeanDeployer.java:115)
at org.jboss.weld.bootstrap.BeanDeployment.deployBeans(BeanDeployment.java:204)
at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:344)
at org.jboss.as.weld.WeldContainer.start(WeldContainer.java:81)
at org.jboss.as.weld.services.WeldService.start(WeldService.java:89)
... 5 more
Caused by: javassist.CannotCompileException: by java.lang.SecurityException: class "org.jboss.as.quickstarts.login.UserManager$-2022604038$Proxy$_$$_Weld$Proxy$"'s signer information does not match signer information of other classes in the same package
at org.jboss.weld.util.bytecode.ClassFileUtils.toClass(ClassFileUtils.java:99)
at org.jboss.weld.bean.proxy.ProxyFactory.createProxyClass(ProxyFactory.java:374)
at org.jboss.weld.bean.proxy.ProxyFactory.getProxyClass(ProxyFactory.java:271)
... 14 more
Caused by: java.lang.SecurityException: class "org.jboss.as.quickstarts.login.UserManager$-2022604038$Proxy$_$$_Weld$Proxy$"'s signer information does not match signer information of other classes in the same package
at java.lang.ClassLoader.checkCerts(ClassLoader.java:807) [:1.6.0_24]
at java.lang.ClassLoader.preDefineClass(ClassLoader.java:488) [:1.6.0_24]
at java.lang.ClassLoader.defineClassCond(ClassLoader.java:626) [:1.6.0_24]
at java.lang.ClassLoader.defineClass(ClassLoader.java:616) [:1.6.0_24]
at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source) [:1.6.0_24]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_24]
at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_24]
at org.jboss.weld.util.bytecode.ClassFileUtils.toClass2(ClassFileUtils.java:118)
at org.jboss.weld.util.bytecode.ClassFileUtils.toClass(ClassFileUtils.java:95)
... 16 more
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 3 months
[JBoss JIRA] (JBJCA-724) Support system property to disable validation of JDBC JCA recovery connection
by Justin Bertram (Created) (JIRA)
Support system property to disable validation of JDBC JCA recovery connection
-----------------------------------------------------------------------------
Key: JBJCA-724
URL: https://issues.jboss.org/browse/JBJCA-724
Project: IronJacamar
Issue Type: Feature Request
Components: JDBC
Reporter: Justin Bertram
Assignee: Jesper Pedersen
Whenever the JBossTS transaction recovery manager asks for an XAResource from a JDBC XA datasource we call java.sql.Connection.isValid(int) to ensure the connection is valid. However, in DB2 a call to java.sql.Connection.isValid(int) causes the connection made from the DB2 JDBC driver to the back-end DB2 RDBMS to become "active" which prevents an administrative shutdown of the DB2 RDBMS instance. To deal with this quirk in the DB2 implementation of java.sql.Connection.isValid(int) and since we cannot change the configuration schema at this point we should support a new system property named "recover-connection-validation" which can be used to turn the validation off, e.g.:
-Drecover-connection-validation=false
Using "false" for "recover-connection-validation" will force the recovery connection used for an XA JDBC datasource to be re-created every time the JBossTS transaction recovery manager asks for it.
In the future we can change the configuration schema to support this functionality directly.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 3 months
[JBoss JIRA] Created: (AS7-1911) Adding deployment scanner failed if directory does not exist
by Heiko Braun (JIRA)
Adding deployment scanner failed if directory does not exist
------------------------------------------------------------
Key: AS7-1911
URL: https://issues.jboss.org/browse/AS7-1911
Project: Application Server 7
Issue Type: Bug
Components: Domain Management
Reporter: Heiko Braun
Assignee: Brian Stansberry
Fix For: 7.1.0.Beta1
17:34:20,015 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC00001: Failed to start service jboss.server.deployment.scanner.asdasdasd: org.jboss.msc.service.StartException in service jboss.server.deployment.scanner.asdasdasd: java.lang.IllegalArgumentException: /Users/hbraun/dev/prj/jboss-as/build/target/jboss-as-7.1.0.Alpha2-SNAPSHOT/standalone/deployments2 does not exist
at org.jboss.as.server.deployment.scanner.DeploymentScannerService.start(DeploymentScannerService.java:161)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1824) [jboss-msc-1.0.1.GA.jar:1.0.1.GA]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1759) [jboss-msc-1.0.1.GA.jar:1.0.1.GA]
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_26]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_26]
at java.lang.Thread.run(Thread.java:680) [:1.6.0_26]
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 3 months
[JBoss JIRA] (AS7-3143) JMS Messages with CMP and transactional=true are not commited to the queue
by Markus Doering (Created) (JIRA)
JMS Messages with CMP and transactional=true are not commited to the queue
--------------------------------------------------------------------------
Key: AS7-3143
URL: https://issues.jboss.org/browse/AS7-3143
Project: Application Server 7
Issue Type: Bug
Components: JMS
Affects Versions: 7.1.0.CR1b, 7.1.0.CR1, 7.0.1.Final
Environment: Windows 7, Java 1.6 update 24
Reporter: Markus Doering
Assignee: Clebert Suconic
Attachments: TestEAR.ear.zip
When sending a message to a JMS queue using container managed transactions and setting transactional=true (connection.createSession(true, Session.AUTO_ACKNOWLEDGE)), the message is never added to the queue.
Using transactional=false is not an option because the message is added to the queue immediately and not after transaction commit.
This can be reproduced with the attached EAR (exploded deployment, so just unpack the .zip in the deployments directory) and the standalone-full.xml (JBoss 7.1.0.CR1
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 3 months
[JBoss JIRA] (JBJCA-725) NPE in TxConnectorManagerImpl
by Stuart Douglas (Created) (JIRA)
NPE in TxConnectorManagerImpl
-----------------------------
Key: JBJCA-725
URL: https://issues.jboss.org/browse/JBJCA-725
Project: IronJacamar
Issue Type: Bug
Affects Versions: 1.1.0.Alpha4
Reporter: Stuart Douglas
Assignee: Jesper Pedersen
Sometimes this gets called when the lock is null:
{code}
10:22:00,312 WARN [org.jboss.tm.usertx.UserTransactionRegistry] (Thread-0 (group:HornetQ-client-global-threads-1925761454)) Error notifying listener org.jboss.jca.core.tx.jbossts.UserTransactionListenerImpl@1fe30f8 of userTransactionStarted: java.lang.NullPointerException
at org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.transactionStarted(TxConnectionManagerImpl.java:395)
at org.jboss.jca.core.connectionmanager.ccm.CachedConnectionManagerImpl.userTransactionStarted(CachedConnectionManagerImpl.java:207)
at org.jboss.jca.core.tx.jbossts.UserTransactionListenerImpl.userTransactionStarted(UserTransactionListenerImpl.java:52)
at org.jboss.tm.usertx.UserTransactionRegistry.userTransactionStarted(UserTransactionRegistry.java:119)
at org.jboss.tm.usertx.client.ServerVMClientUserTransaction.begin(ServerVMClientUserTransaction.java:141)
at com.sun.ts.tests.jms.ee.mdb.xa.MsgBeanxa.runTest5(MsgBeanxa.java:218) [mdb_msg_ejb.jar:]
at com.sun.ts.tests.jms.ee.mdb.xa.MsgBeanxa.runTests(MsgBeanxa.java:113) [mdb_msg_ejb.jar:]
at com.sun.ts.tests.jms.ee.mdb.xa.MsgBeanxa.onMessage(MsgBeanxa.java:78) [mdb_msg_ejb.jar:]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_29]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_29]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_29]
at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_29]
at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72) [jboss-as-ee-7.1.0.Final-SNAPSHOT.jar:7.1.0.Final-SNAPSHOT]
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:36) [jboss-as-ee-7.1.0.Final-SNAPSHOT.jar:7.1.0.Final-SNAPSHOT]
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
at org.jboss.as.ejb3.tx.EjbBMTInterceptor.handleInvocation(EjbBMTInterceptor.java:105) [jboss-as-ejb3-7.1.0.Final-SNAPSHOT.jar:7.1.0.Final-SNAPSHOT]
at org.jboss.as.ejb3.tx.BMTInterceptor.processInvocation(BMTInterceptor.java:56) [jboss-as-ejb3-7.1.0.Final-SNAPSHOT.jar:7.1.0.Final-SNAPSHOT]
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53) [jboss-as-ee-7.1.0.Final-SNAPSHOT.jar:7.1.0.Final-SNAPSHOT]
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51) [jboss-as-ejb3-7.1.0.Final-SNAPSHOT.jar:7.1.0.Final-SNAPSHOT]
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [jboss-as-ejb3-7.1.0.Final-SNAPSHOT.jar:7.1.0.Final-SNAPSHOT]
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) [jboss-as-ee-7.1.0.Final-SNAPSHOT.jar:7.1.0.Final-SNAPSHOT]
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:43) [jboss-as-ejb3-7.1.0.Final-SNAPSHOT.jar:7.1.0.Final-SNAPSHOT]
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
at org.jboss.as.ejb3.component.messagedriven.MessageDrivenComponentDescription$4$1.processInvocation(MessageDrivenComponentDescription.java:176) [jboss-as-ejb3-7.1.0.Final-SNAPSHOT.jar:7.1.0.Final-SNAPSHOT]
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
at org.jboss.as.ee.component.TCCLInterceptor.processInvocation(TCCLInterceptor.java:45) [jboss-as-ee-7.1.0.Final-SNAPSHOT.jar:7.1.0.Final-SNAPSHOT]
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:57) [jboss-as-ejb3-7.1.0.Final-SNAPSHOT.jar:7.1.0.Final-SNAPSHOT]
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:165) [jboss-as-ee-7.1.0.Final-SNAPSHOT.jar:7.1.0.Final-SNAPSHOT]
at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:173) [jboss-as-ee-7.1.0.Final-SNAPSHOT.jar:7.1.0.Final-SNAPSHOT]
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:72) [jboss-as-ee-7.1.0.Final-SNAPSHOT.jar:7.1.0.Final-SNAPSHOT]
at javax.jms.MessageListener$$$view2.onMessage(Unknown Source) [jboss-jms-api_1.1_spec-1.0.0.Final.jar:1.0.0.Final]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_29]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_29]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_29]
at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_29]
at org.jboss.as.ejb3.inflow.MessageEndpointInvocationHandler.doInvoke(MessageEndpointInvocationHandler.java:140) [jboss-as-ejb3-7.1.0.Final-SNAPSHOT.jar:7.1.0.Final-SNAPSHOT]
at org.jboss.as.ejb3.inflow.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:73) [jboss-as-ejb3-7.1.0.Final-SNAPSHOT.jar:7.1.0.Final-SNAPSHOT]
at $Proxy13.onMessage(Unknown Source) at org.hornetq.ra.inflow.HornetQMessageHandler.onMessage(HornetQMessageHandler.java:278)
at org.hornetq.core.client.impl.ClientConsumerImpl.callOnMessage(ClientConsumerImpl.java:866)
at org.hornetq.core.client.impl.ClientConsumerImpl.access$100(ClientConsumerImpl.java:44)
at org.hornetq.core.client.impl.ClientConsumerImpl$Runner.run(ClientConsumerImpl.java:983)
at org.hornetq.utils.OrderedExecutorFactory$OrderedExecutor$1.run(OrderedExecutorFactory.java:100)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_29]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_29]
at java.lang.Thread.run(Thread.java:680) [:1.6.0_29]
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 3 months
[JBoss JIRA] (AS7-3214) RESTEasy: Resource with resource method with more than one parameter that is not annotated isn't rejected, nor warning generated
by Pavel Janousek (Updated) (JIRA)
[ https://issues.jboss.org/browse/AS7-3214?page=com.atlassian.jira.plugin.s... ]
Pavel Janousek updated AS7-3214:
--------------------------------
Priority: Blocker (was: Major)
Description:
Section 3.3.2.1. of JAX-RS 1.1. specs says:
<cite>
3.3.2.1 Entity Parameters
The value of a non-annotated parameter, called the entity parameter, is mapped from the request entity body. Conversion between an entity body and a Java type is the responsibility of an entity provider, see section 4.2.
Resource methods MUST NOT have more than one parameter that is not annotated with one of the above-listed annotations.
</cite>
Although a resource contains "endpoint" with method(s) goes against this specs, request is processed normally, without any error(s) occurred or reported.
was:
Section 3.3.2.1. of JAX-RS 1.1. specs says:
<cite>
3.3.2.1 Entity Parameters
The value of a non-annotated parameter, called the entity parameter, is mapped from the request entity body. Conversion between an entity body and a Java type is the responsibility of an entity provider, see section 4.2.
Resource methods MUST NOT have more than one parameter that is not annotated with one of the above-listed annotations.
</cite>
If Reource contains methos that isn't conformed with second paragraph,actual behavior is only saying "404 - not found" when someone do access to a such "endpoint". I think we should provide better handling of this situation - I prefer rejecting of a such resource during deploying the JAX-RS application, but at least some warning could be generated at this situation.
> RESTEasy: Resource with resource method with more than one parameter that is not annotated isn't rejected, nor warning generated
> --------------------------------------------------------------------------------------------------------------------------------
>
> Key: AS7-3214
> URL: https://issues.jboss.org/browse/AS7-3214
> Project: Application Server 7
> Issue Type: Bug
> Components: REST
> Affects Versions: 7.1.0.CR1b
> Reporter: Pavel Janousek
> Assignee: Weinan Li
> Priority: Blocker
>
> Section 3.3.2.1. of JAX-RS 1.1. specs says:
> <cite>
> 3.3.2.1 Entity Parameters
> The value of a non-annotated parameter, called the entity parameter, is mapped from the request entity body. Conversion between an entity body and a Java type is the responsibility of an entity provider, see section 4.2.
> Resource methods MUST NOT have more than one parameter that is not annotated with one of the above-listed annotations.
> </cite>
> Although a resource contains "endpoint" with method(s) goes against this specs, request is processed normally, without any error(s) occurred or reported.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 3 months