[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)
11 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)
11 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)
11 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)
11 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)
11 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)
11 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 updated WFLY-3905:
----------------------------
Description:
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.
was:
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}
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.
> 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: Alessio Soldano
>
> 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)
11 years, 9 months
[JBoss JIRA] (WFLY-3905) POJO JAX-WS endpoints should not be processed if packaged in EJB-jar
by Kyle Lape (JIRA)
Kyle Lape created WFLY-3905:
-------------------------------
Summary: 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: Alessio Soldano
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}
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)
11 years, 9 months
[JBoss JIRA] (WFLY-3842) Netty direct buffer detection broken due to missing module dependencies
by Seth Miller (JIRA)
[ https://issues.jboss.org/browse/WFLY-3842?page=com.atlassian.jira.plugin.... ]
Seth Miller commented on WFLY-3842:
-----------------------------------
The fix for the underlying HornetQ issue has been merged into HornetQ 2.4.4 Final see:
https://github.com/hornetq/hornetq/commit/5d307d86d8c96bca912c5675ec9fc63...
Once Wildfly updates to this version, it is probably safe to retest/apply the pull request.
> Netty direct buffer detection broken due to missing module dependencies
> -----------------------------------------------------------------------
>
> Key: WFLY-3842
> URL: https://issues.jboss.org/browse/WFLY-3842
> Project: WildFly
> Issue Type: Bug
> Components: Server
> Affects Versions: 8.1.0.Final, 9.0.0.Alpha1
> Reporter: Seth Miller
> Assignee: Jason Greene
>
> When deploying Wildfly 8.x, you'll see this in the server.log:
> {code}
> INFO [io.netty.util.internal.PlatformDependent] Your platform does not provide complete low-level API for accessing direct buffers reliably. Unless explicitly requested, heap buffer will always be preferred to av
> oid potential system unstability.
> {code}
> Following this into netty, here:
> https://github.com/netty/netty/blob/master/common/src/main/java/io/netty/...
> Down to here:
> https://github.com/netty/netty/blob/netty-4.0.15.Final/common/src/main/ja...
> We need access to sun.misc to see if direct buffers are available.
> Adding sun.misc to the netty module removes the log message, but if we TRACE on io.netty, there is one additional message:
> {code}
> 2014-09-09 13:58:35,512 FINE [io.netty.util.internal.PlatformDependent] -Dio.netty.noJavassist: false
> 2014-09-09 13:58:35,513 FINE [io.netty.util.internal.PlatformDependent] Javassist: unavailable
> 2014-09-09 13:58:35,513 FINE [io.netty.util.internal.PlatformDependent] You don't have Javassist in your class path or you don't have enough permission to load dynamically generated classes. Please check the configuration for better performance.
> {code}
> We can provide netty with a depends on Javassist to remove the FINE message about performance.
> Workaround: alter the module io/netty/main/module.xml to include the following {code}
> <module xmlns="urn:jboss:module:1.3" name="io.netty">
> <resources>
> <resource-root path="netty-all-4.0.15.Final.jar"/>
> </resources>
> <dependencies>
> <module name="sun.jdk"/>
> <module name="org.javassist"/>
> </dependencies>
> </module>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 9 months
[JBoss JIRA] (JBEE-156) Missing privileged action in org.jboss.com.sun.corba.se.impl.util.Utility
by David Lloyd (JIRA)
David Lloyd created JBEE-156:
--------------------------------
Summary: Missing privileged action in org.jboss.com.sun.corba.se.impl.util.Utility
Key: JBEE-156
URL: https://issues.jboss.org/browse/JBEE-156
Project: JBoss JavaEE Spec APIs
Issue Type: Bug
Components: jboss-rmi-api
Reporter: David Lloyd
Assignee: Shelly McGowan
org.jboss.com.sun.corba.se.impl.util.Utility#loadStub(org.omg.CORBA.Object, java.lang.Class<?>)
This method has the following method:
{code}
/*
* Load an RMI-IIOP Stub. This is used in PortableRemoteObject.narrow.
*/
public static Object loadStub(org.omg.CORBA.Object narrowFrom, Class<?> narrowTo)
{
Object result = null;
try
{
// Get the codebase from the delegate to use when loading the new stub, if possible...
String codebase = null;
try
{
// We can't assume that narrowFrom is a CORBA_2_3 stub, yet it may have a 2_3 Delegate that provides a
// codebase. Swallow the ClassCastException otherwise.
Delegate delegate = StubAdapter.getDelegate(narrowFrom);
codebase = ((org.omg.CORBA_2_3.portable.Delegate) delegate).get_codebase(narrowFrom);
}
catch (ClassCastException e)
{
throw wrapper.classCastExceptionInLoadStub(e);
}
PresentationManager.StubFactoryFactory sff = org.jboss.com.sun.corba.se.spi.orb.ORB.getStubFactoryFactory();
PresentationManager.StubFactory sf = sff.createStubFactory(narrowTo.getName(), false, codebase, narrowTo,
narrowTo.getClassLoader());
result = sf.makeStub();
StubAdapter.setDelegate(result, StubAdapter.getDelegate(narrowFrom));
}
catch (Exception err)
{
throw wrapper.exceptionInLoadStub(err);
}
return result;
}
{code}
The {{narrowTo.getClassLoader()}} should be made privileged.
Problem found in jboss-rmi-api_1.0_spec-1.0.4.Final; no version seems to exist for this release.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 9 months