[JBoss JIRA] (WFLY-950) RESTEasy: Empty cfg. param javax.ws.rs.Application produces exception
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-950?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration commented on WFLY-950:
----------------------------------------------
Weinan Li <weli(a)redhat.com> changed the Status of [bug 899666|https://bugzilla.redhat.com/show_bug.cgi?id=899666] from ASSIGNED to MODIFIED
> RESTEasy: Empty cfg. param javax.ws.rs.Application produces exception
> ---------------------------------------------------------------------
>
> Key: WFLY-950
> URL: https://issues.jboss.org/browse/WFLY-950
> Project: WildFly
> Issue Type: Bug
> Components: REST
> Reporter: Pavel Janousek
> Assignee: Weinan Li
>
> RESTEasy can be configured through several configuration options in WAR application deployment file WEB-INF/web.xml. The major one (also portable defined by JAX-RS standard) is _javax.ws.rs.Application_. When I set this parameter to empty content present behavior is raising exception "java.lang.StringIndexOutOfBoundsException: String index out of range: 0", it is not so good.
> I think, this is hard miss-configuration error and deployment description as this one should be rejected and a such application should not be deployed at all with appropriate error message, but not only by messed exception.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 9 months
[JBoss JIRA] (JASSIST-234) Support for Javaflow bytecode pattern
by Shigeru Chiba (JIRA)
[ https://issues.jboss.org/browse/JASSIST-234?page=com.atlassian.jira.plugi... ]
Shigeru Chiba resolved JASSIST-234.
-----------------------------------
Fix Version/s: 3.19.0-GA
Resolution: Done
The patch has been merged.
> Support for Javaflow bytecode pattern
> -------------------------------------
>
> Key: JASSIST-234
> URL: https://issues.jboss.org/browse/JASSIST-234
> Project: Javassist
> Issue Type: Patch
> Affects Versions: 3.18.2-GA
> Reporter: Shigeru Chiba
> Assignee: Shigeru Chiba
> Fix For: 3.19.0-GA
>
>
> The Apache Javaflow project instruments class files to provide its Continuation capability. One of the bytecode patterns it generates to handle Category 2 parameters is:
> NEW
> DUP
> DUP2_X2
> POP2
> Unfortunately, when Javassist sees this pattern when moving instructions, it recognizes the NEW DUP and removes it in order to do the move. However, this leaves the DUP2_X2 POP2 abandoned which leads to stack corruption and javassist throwing an exception due to a negative stack height.
> Given this involves Category 2 operands, there is not much short of a complete rearchitecting that can be done in Javaflow to accommodate the existing Javassist patterns for NEW. Therefore, I ask the the above bytecode pattern be added to the javassist.expr.NewExpr.canReplace() method. I will submit a patch with the proposed change.
> Originally reported by Baron Roberts at:
> https://github.com/jboss-javassist/javassist/pull/21
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 9 months
[JBoss JIRA] (JASSIST-234) Support for Javaflow bytecode pattern
by Shigeru Chiba (JIRA)
[ https://issues.jboss.org/browse/JASSIST-234?page=com.atlassian.jira.plugi... ]
Shigeru Chiba closed JASSIST-234.
---------------------------------
> Support for Javaflow bytecode pattern
> -------------------------------------
>
> Key: JASSIST-234
> URL: https://issues.jboss.org/browse/JASSIST-234
> Project: Javassist
> Issue Type: Patch
> Affects Versions: 3.18.2-GA
> Reporter: Shigeru Chiba
> Assignee: Shigeru Chiba
> Fix For: 3.19.0-GA
>
>
> The Apache Javaflow project instruments class files to provide its Continuation capability. One of the bytecode patterns it generates to handle Category 2 parameters is:
> NEW
> DUP
> DUP2_X2
> POP2
> Unfortunately, when Javassist sees this pattern when moving instructions, it recognizes the NEW DUP and removes it in order to do the move. However, this leaves the DUP2_X2 POP2 abandoned which leads to stack corruption and javassist throwing an exception due to a negative stack height.
> Given this involves Category 2 operands, there is not much short of a complete rearchitecting that can be done in Javaflow to accommodate the existing Javassist patterns for NEW. Therefore, I ask the the above bytecode pattern be added to the javassist.expr.NewExpr.canReplace() method. I will submit a patch with the proposed change.
> Originally reported by Baron Roberts at:
> https://github.com/jboss-javassist/javassist/pull/21
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 9 months
[JBoss JIRA] (JASSIST-234) Support for Javaflow bytecode pattern
by Shigeru Chiba (JIRA)
Shigeru Chiba created JASSIST-234:
-------------------------------------
Summary: Support for Javaflow bytecode pattern
Key: JASSIST-234
URL: https://issues.jboss.org/browse/JASSIST-234
Project: Javassist
Issue Type: Patch
Affects Versions: 3.18.2-GA
Reporter: Shigeru Chiba
Assignee: Shigeru Chiba
The Apache Javaflow project instruments class files to provide its Continuation capability. One of the bytecode patterns it generates to handle Category 2 parameters is:
NEW
DUP
DUP2_X2
POP2
Unfortunately, when Javassist sees this pattern when moving instructions, it recognizes the NEW DUP and removes it in order to do the move. However, this leaves the DUP2_X2 POP2 abandoned which leads to stack corruption and javassist throwing an exception due to a negative stack height.
Given this involves Category 2 operands, there is not much short of a complete rearchitecting that can be done in Javaflow to accommodate the existing Javassist patterns for NEW. Therefore, I ask the the above bytecode pattern be added to the javassist.expr.NewExpr.canReplace() method. I will submit a patch with the proposed change.
Originally reported by Baron Roberts at:
https://github.com/jboss-javassist/javassist/pull/21
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 9 months
[JBoss JIRA] (HIBERNATE-146) Remove after get with optimistic lock fails
by Arcadiy Ivanov (JIRA)
[ https://issues.jboss.org/browse/HIBERNATE-146?page=com.atlassian.jira.plu... ]
Arcadiy Ivanov commented on HIBERNATE-146:
------------------------------------------
Pull requests https://github.com/hibernate/hibernate-orm/pull/815 and https://github.com/hibernate/hibernate-orm/pull/816 filed for 4.3.x and 5.x branches respectively.
> Remove after get with optimistic lock fails
> -------------------------------------------
>
> Key: HIBERNATE-146
> URL: https://issues.jboss.org/browse/HIBERNATE-146
> Project: Hibernate Integration
> Issue Type: Bug
> Reporter: Arcadiy Ivanov
> Assignee: Steve Ebersole
> Attachments: hibernate-146.tar.gz, hibernate-146.tar.gz
>
>
> Whenever an entity is retrieved with an optimistic lock and then later is removed within the same transaction, an OptimisticLockException is thrown incorrectly.
> This is caused by the lock being incorrectly tracked altogether in case of an explicit optimistic lock. The unlocked/default lock behavior tracks entity versions correctly deleting entity even with optimistic check.
> EclipseLink, being a reference implementation, behaves correctly in this case.
> =====
> Running the attached test case the following behaviors can be observed:
> Insert + Commit, Get unlocked + Delete + Commit = OK
> {noformat}
> Hibernate:
> /* insert com.csc.hibernate146.Person
> */ insert
> into
> Person
> (name, version)
> values
> (?, ?)
> Hibernate:
> /* named HQL query Person.getPerson */ select
> person0_.id as id1_0_,
> person0_.name as name2_0_,
> person0_.version as version3_0_
> from
> Person person0_
> where
> person0_.name=?
> Deleting without lock: Person [id=1, name=John Doe, version=0]
> Hibernate:
> /* delete com.csc.hibernate146.Person */ delete
> from
> Person
> where
> id=?
> and version=?
> {noformat}
> Insert + Commit, Get + LockModeType.OPTIMISTIC + Delete + Commit = OptimisticLockException
> {noformat}
> Hibernate:
> /* insert com.csc.hibernate146.Person
> */ insert
> into
> Person
> (name, version)
> values
> (?, ?)
> Hibernate:
> /* named HQL query Person.getPerson */ select
> person0_.id as id1_0_,
> person0_.name as name2_0_,
> person0_.version as version3_0_
> from
> Person person0_
> where
> person0_.name=?
> Deleting under optimistic lock: Person [id=2, name=Jane Doe, version=0]
> Hibernate:
> /* delete com.csc.hibernate146.Person */ delete
> from
> Person
> where
> id=?
> and version=?
> Hibernate:
> /* get version com.csc.hibernate146.Person */ select
> version
> from
> Person
> where
> id =?
> WARN [com.arjuna.ats.arjuna] ARJUNA012125: TwoPhaseCoordinator.beforeCompletion - failed for SynchronizationImple< 0:ffffc0a87b34:-72291bdb:5424d3a3:22, org.hibernate.engine.transaction.synchronization.internal.RegisteredSynchronization@7c440164 >: org.hibernate.OptimisticLockException: Newer version [null] of entity [[com.csc.hibernate146.Person#2]] found in database
> at org.hibernate.action.internal.EntityVerifyVersionProcess.doBeforeTransactionCompletion(EntityVerifyVersionProcess.java:60) [hibernate-core-4.3.5.Final.jar:4.3.5.Final]
> at org.hibernate.engine.spi.ActionQueue$BeforeTransactionCompletionProcessQueue.beforeTransactionCompletion(ActionQueue.java:715) [hibernate-core-4.3.5.Final.jar:4.3.5.Final]
> at org.hibernate.engine.spi.ActionQueue.beforeTransactionCompletion(ActionQueue.java:389) [hibernate-core-4.3.5.Final.jar:4.3.5.Final]
> at org.hibernate.internal.SessionImpl.beforeTransactionCompletion(SessionImpl.java:516) [hibernate-core-4.3.5.Final.jar:4.3.5.Final]
> at org.hibernate.engine.transaction.synchronization.internal.SynchronizationCallbackCoordinatorNonTrackingImpl.beforeCompletion(SynchronizationCallbackCoordinatorNonTrackingImpl.java:119) [hibernate-core-4.3.5.Final.jar:4.3.5.Final]
> at org.hibernate.engine.transaction.synchronization.internal.RegisteredSynchronization.beforeCompletion(RegisteredSynchronization.java:50) [hibernate-core-4.3.5.Final.jar:4.3.5.Final]
> at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:76)
> at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:358)
> at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:91)
> at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1166)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126)
> at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:75)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:93) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:277) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:340) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) [:1.2.1.Final]
> at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) [:1.2.1.Final]
> at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) [:1.2.1.Final]
> at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:95) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) [:1.2.1.Final]
> at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) [:1.2.1.Final]
> at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) [:1.2.1.Final]
> at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) [:1.2.1.Final]
> at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) [:1.2.1.Final]
> at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64) [jboss-invocation-1.2.1.Final.jar:1.2.1.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) [:1.2.1.Final]
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:326) [:1.2.1.Final]
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:448) [wildfly-security-manager-1.0.0.Final.jar:1.0.0.Final]
> at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61) [jboss-invocation-1.2.1.Final.jar:1.2.1.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) [:1.2.1.Final]
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:326) [:1.2.1.Final]
> at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80) [jboss-invocation-1.2.1.Final.jar:1.2.1.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) [:1.2.1.Final]
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) [jboss-invocation-1.2.1.Final.jar:1.2.1.Final]
> at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:185)
> at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:182)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) [:1.2.1.Final]
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) [jboss-invocation-1.2.1.Final.jar:1.2.1.Final]
> at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73)
> at com.csc.hibernate146.PersonManagementBean$$$view1.getByNameAndDeletePersonLocked(Unknown Source) [ee86ef2e-58da-4691-b087-2c3678ec3ddf.jar:]
> at com.csc.hibernate146.test.Hibernate146Test.createAndDeletePersonLocked(Hibernate146Test.java:59) [ee86ef2e-58da-4691-b087-2c3678ec3ddf.jar:]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_67]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_67]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_67]
> at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_67]
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47) [arquillian-junit.jar:]
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) [arquillian-junit.jar:]
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44) [arquillian-junit.jar:]
> at org.jboss.arquillian.junit.Arquillian$6$1.invoke(Arquillian.java:301) [arquillian-junit.jar:]
> at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60) [arquillian-core.jar:]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_67]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_67]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_67]
> at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_67]
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) [arquillian-core.jar:]
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) [arquillian-core.jar:]
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) [arquillian-core.jar:]
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) [arquillian-core.jar:]
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) [arquillian-core.jar:]
> at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) [arquillian-core.jar:]
> at org.jboss.arquillian.container.test.impl.execution.ContainerTestExecuter.execute(ContainerTestExecuter.java:38) [arquillian-core.jar:]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_67]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_67]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_67]
> at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_67]
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) [arquillian-core.jar:]
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) [arquillian-core.jar:]
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) [arquillian-core.jar:]
> at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:102) [arquillian-core.jar:]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_67]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_67]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_67]
> at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_67]
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) [arquillian-core.jar:]
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) [arquillian-core.jar:]
> at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:84) [arquillian-core.jar:]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_67]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_67]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_67]
> at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_67]
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) [arquillian-core.jar:]
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) [arquillian-core.jar:]
> at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:65) [arquillian-core.jar:]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_67]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_67]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_67]
> at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_67]
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) [arquillian-core.jar:]
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) [arquillian-core.jar:]
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) [arquillian-core.jar:]
> at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:111) [arquillian-core.jar:]
> at org.jboss.arquillian.junit.Arquillian$6.evaluate(Arquillian.java:294) [arquillian-junit.jar:]
> at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:267) [arquillian-junit.jar:]
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) [arquillian-junit.jar:]
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) [arquillian-junit.jar:]
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) [arquillian-junit.jar:]
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) [arquillian-junit.jar:]
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) [arquillian-junit.jar:]
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) [arquillian-junit.jar:]
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) [arquillian-junit.jar:]
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) [arquillian-junit.jar:]
> at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:193) [arquillian-junit.jar:]
> at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:345) [arquillian-junit.jar:]
> at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:49) [arquillian-junit.jar:]
> at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:207) [arquillian-junit.jar:]
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309) [arquillian-junit.jar:]
> at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:155) [arquillian-junit.jar:]
> at org.junit.runner.JUnitCore.run(JUnitCore.java:160) [arquillian-junit.jar:]
> at org.junit.runner.JUnitCore.run(JUnitCore.java:138) [arquillian-junit.jar:]
> at org.jboss.arquillian.junit.container.JUnitTestRunner.execute(JUnitTestRunner.java:66) [arquillian-junit.jar:]
> at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner.executeTest(ServletTestRunner.java:160) [arquillian-protocol.jar:]
> at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner.execute(ServletTestRunner.java:126) [arquillian-protocol.jar:]
> at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner.doGet(ServletTestRunner.java:90) [arquillian-protocol.jar:]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_67]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_67]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_67]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 9 months
[JBoss JIRA] (DROOLS-614) Traits should map non-accessor methods
by Davide Sottara (JIRA)
Davide Sottara created DROOLS-614:
-------------------------------------
Summary: Traits should map non-accessor methods
Key: DROOLS-614
URL: https://issues.jboss.org/browse/DROOLS-614
Project: Drools
Issue Type: Enhancement
Affects Versions: 6.1.0.Final, 5.6.0.Final
Reporter: Davide Sottara
Assignee: Mark Proctor
When using non-declared @Traits and @Traitables, it is possible for interfaces to define non-accessor methods. If a core method is compatible with an interface method, it should be mapped rather than throw an AbstractMethodException as it does in 5.x and 6.0 and 6.1
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 9 months
[JBoss JIRA] (WFLY-2456) Using add-user.bat for initial admin user results in "JBAS015234: No mgmt-groups.properties files found"
by Ramesh Kumar Junnuru (JIRA)
[ https://issues.jboss.org/browse/WFLY-2456?page=com.atlassian.jira.plugin.... ]
Ramesh Kumar Junnuru commented on WFLY-2456:
--------------------------------------------
I am also not able to add user even i ran that as administrator
D:\jboss-as-7.1.0.Final\bin>add-user.bat
The filename, directory name, or volume label syntax is incorrect.
Press any key to continue . . .
D:\jboss-as-7.1.0.Final\bin>set J
JAVA_HOME=D:\Java\jdk1.7.0_25\bin;D:\Java\jdk1.7.0_25\lib;.;
JBOSS_HOME=D:\jboss-as-7.1.0.Final
D:\jboss-as-7.1.0.Final\bin>
Please let me know how i need to fix the issue.
> Using add-user.bat for initial admin user results in "JBAS015234: No mgmt-groups.properties files found"
> --------------------------------------------------------------------------------------------------------
>
> Key: WFLY-2456
> URL: https://issues.jboss.org/browse/WFLY-2456
> Project: WildFly
> Issue Type: Bug
> Components: Scripts
> Affects Versions: 8.0.0.Beta1
> Environment: Windows 7, 32-bit, jdk1.7.0_45
> Reporter: John Lusk
> Assignee: Darran Lofthouse
> Fix For: 9.0.0.Beta1
>
>
> Just getting started w/Wildfly after a long absence from Java. Fresh download, trying to hit admin console, got instructed to use add-user to add an admin user.
> c:\usr\local\wildfly-8.0.0.Beta1\bin>.\add-user.bat
> What type of user do you wish to add?
> a) Management User (mgmt-users.properties)
> b) Application User (application-users.properties)
> (a): a
> * Error *
> JBAS015234: No mgmt-groups.properties files found.
> Press any key to continue . . .
> c:\usr\local\wildfly-8.0.0.Beta1\bin>echo %JBOSS_HOME%
> C:\usr\local\wildfly-8.0.0.Beta1
> c:\usr\local\wildfly-8.0.0.Beta1\bin>echo %JAVA_HOME%
> C:\java\jdk1.7.0_45
> c:\usr\local\wildfly-8.0.0.Beta1\bin>echo %M2_HOME%
> C:\usr\local\Maven\3.1.1
> c:\usr\local\wildfly-8.0.0.Beta1\bin>mvn -version
> Apache Maven 3.1.1 (0728685237757ffbf44136acec0402957f723d9a; 2013-09-17 11:22:2
> 2-0400)
> Maven home: C:\usr\local\Maven\3.1.1
> Java version: 1.7.0_45, vendor: Oracle Corporation
> Java home: C:\java\jdk1.7.0_45\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "x86", family: "windows"
> c:\usr\local\wildfly-8.0.0.Beta1\bin>
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 9 months
[JBoss JIRA] (WFLY-3905) POJO JAX-WS endpoints should not be processed if packaged in EJB-jar
by Kyle Lape (JIRA)
[ https://issues.jboss.org/browse/WFLY-3905?page=com.atlassian.jira.plugin.... ]
Kyle Lape reassigned WFLY-3905:
-------------------------------
Assignee: Kyle Lape (was: Alessio Soldano)
> POJO JAX-WS endpoints should not be processed if packaged in EJB-jar
> --------------------------------------------------------------------
>
> Key: WFLY-3905
> URL: https://issues.jboss.org/browse/WFLY-3905
> Project: WildFly
> Issue Type: Bug
> Components: Web Services
> Affects Versions: 9.0.0.Alpha1
> Reporter: Kyle Lape
> Assignee: Kyle Lape
>
> If a POJO is defined like this in an EJB-jar:
> {code:java}
> package com.redhat.gss.ws;
> @javax.jws.WebService
> public class HelloService {
> public String sayHello() {
> return "Hello World!";
> }
> }
> {code}
> Deployment structure:
> {noformat}
> klape@localhost ws-java.jar$ tree
> .
> ├── com
> │ └── redhat
> │ └── gss
> │ └── ws
> │ └── HelloService.java
> └── META-INF
> └── MANIFEST.MF
> 5 directories, 2 files
> klape@localhost ws-java.jar$
> {noformat}
> Upon deployment, you get this in the log:
> {noformat}
> 16:52:51,372 INFO [org.jboss.ws.cxf.metadata] (MSC service thread 1-7) JBWS024061: Adding service endpoint metadata: id=com.redhat.gss.ws.HelloService
> address=http://localhost:8080/ws-java/HelloService
> implementor=com.redhat.gss.ws.HelloService
> serviceName={http://ws.gss.redhat.com/}HelloServiceService
> portName={http://ws.gss.redhat.com/}HelloServicePort
> annotationWsdlLocation=null
> wsdlLocationOverride=null
> mtomEnabled=false
> 16:52:51,571 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (MSC service thread 1-7) Creating Service {http://ws.gss.redhat.com/}HelloServiceService from class com.redhat.gss.ws.HelloService
> 16:52:51,879 INFO [org.apache.cxf.endpoint.ServerImpl] (MSC service thread 1-7) Setting the server's publish address to be http://localhost:8080/ws-java/HelloService
> 16:52:51,925 INFO [org.jboss.ws.cxf.deployment] (MSC service thread 1-7) JBWS024074: WSDL published to: file:/home/remote/klape/work/archives/wildfly-8.1.0.Final/standalone/data/wsdl/ws-java.jar/HelloServiceService.wsdl
> {noformat}
> Yet when you try to get the WSDL at {{http://localhost:8080/ws-java/HelloService?wsdl}} (pulled from the metadata in the log), you get a 404 error.
> JBossWS should not be trying to deploy the POJO endpoint from within an EJB-jar.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 9 months