[JBoss JIRA] (SWSQE-184) Validate that Service-Meshes were succesfully deployed
by Matt Mahoney (JIRA)
Matt Mahoney created SWSQE-184:
----------------------------------
Summary: Validate that Service-Meshes were succesfully deployed
Key: SWSQE-184
URL: https://issues.jboss.org/browse/SWSQE-184
Project: Kiali QE
Issue Type: Sub-task
Reporter: Matt Mahoney
Assignee: Michael Foley
Some automation scripts will fail if test-meshes are not up and running prior to tests being run. Thus this task is to create a script that will validate that all service-mesh pods being successfully started.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (JGRP-2262) "Frozen" coordinator causes the whole cluster to hang
by Sibin Karnavar (JIRA)
[ https://issues.jboss.org/browse/JGRP-2262?page=com.atlassian.jira.plugin.... ]
Sibin Karnavar commented on JGRP-2262:
--------------------------------------
Thanks for creating this JIRA, I was about to create an another one but found this similar issue.
I have faced similar problem. I have my thread dump patsted here. I am using 4.0.10 version. It is not reproducible every time.
1) I was having 3 cluster nodes.
1) I have started all my nodes together (This was due to a deployment of my service in Amazon)
2) After the restart , I have checked my database table. I was not able to see the new ping inserts instead I was able to see the old coordinator entry in the database ( Usually it used to clear the db entry because new coordinator removes it and rewrite new information's back. I have remove_all_data_on_view_change=true )
3) But my cluster was still working with 2 cluster nodes. The third cluster node was in waiting state to start. I am attaching my thread dump. I feel like it is similar issue as mentioned above in this JIRA. its waiting at the ClientGmsImpl.java:93 till i refresh the DB entry by changing the cluster coordinator. As soon as I change my cluster coordinator, JGroup is clearing again the DB and re writing the latest view on the DB. Post this, the hung node is starting from where it stopped.
"localhost-startStop-1" #18 daemon prio=5 os_prio=0 tid=0x00007f9268001000 nid=0x4b39 sleeping[0x00007f92a4512000]
java.lang.Thread.State: TIMED_WAITING (sleeping)
at java.lang.Thread.sleep(Native Method)
at org.jgroups.util.Util.sleep(Util.java:1866)
{color:red} at org.jgroups.protocols.pbcast.ClientGmsImpl.firstOfAllClients(ClientGmsImpl.java:177)
at org.jgroups.protocols.pbcast.ClientGmsImpl.joinInternal(ClientGmsImpl.java:93){color}
at org.jgroups.protocols.pbcast.ClientGmsImpl.join(ClientGmsImpl.java:41)
at org.jgroups.protocols.pbcast.GMS.down(GMS.java:1064)
at org.jgroups.protocols.pbcast.STATE_TRANSFER.down(STATE_TRANSFER.java:206)
at org.jgroups.protocols.FlowControl.down(FlowControl.java:300)
at org.jgroups.protocols.FRAG2.down(FRAG2.java:141)
at org.jgroups.protocols.RSVP.down(RSVP.java:102)
at org.jgroups.stack.ProtocolStack.down(ProtocolStack.java:901)
at org.jgroups.JChannel.down(JChannel.java:668)
at org.jgroups.JChannel._connect(JChannel.java:897)
at org.jgroups.JChannel.connect(JChannel.java:393)
- locked <0x00000007cd00cec8> (a org.jgroups.JChannel)
at org.jgroups.JChannel.connect(JChannel.java:384)
- locked <0x00000007cd00cec8> (a org.jgroups.JChannel)
at com.wellmanage.som.clustermanager.jgroup.AbstractClusterManager.connect(AbstractClusterManager.java:198)
at com.wellmanage.som.clustermanager.jgroup.AbstractClusterManager.start(AbstractClusterManager.java:163)
at com.wellmanage.som.clustermanager.ServiceClusterCoordinator.joinCluster(ServiceClusterCoordinator.java:194)
at com.wellmanage.som.statekeeper.DefaultSOMStateKeeper.start(DefaultSOMStateKeeper.java:250)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeCustomInitMethod(AbstractAutowireCapableBeanFactory.java:1835)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1778)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1706)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:583)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:502)
at org.springframework.beans.factory.support.AbstractBeanFactory.lambda$doGetBean$0(AbstractBeanFactory.java:312)
at org.springframework.beans.factory.support.AbstractBeanFactory$$Lambda$99/1286783232.getObject(Unknown Source)
at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:228)
- locked <0x00000005f80fc130> (a java.util.concurrent.ConcurrentHashMap)
at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:310)
at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:200)
at org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveReference(BeanDefinitionValueResolver.java:367)
at org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveValueIfNecessary(BeanDefinitionValueResolver.java:110)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyPropertyValues(AbstractAutowireCapableBeanFactory.java:1613)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1357)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:582)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:502)
at org.springframework.beans.factory.support.AbstractBeanFactory.lambda$doGetBean$0(AbstractBeanFactory.java:312)
at org.springframework.beans.factory.support.AbstractBeanFactory$$Lambda$99/1286783232.getObject(Unknown Source)
at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:228)
- locked <0x00000005f80fc130> (a java.util.concurrent.ConcurrentHashMap)
at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:310)
at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:200)
at org.springframework.beans.factory.support.ConstructorResolver.instantiateUsingFactoryMethod(ConstructorResolver.java:368)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.instantiateUsingFactoryMethod(AbstractAutowireCapableBeanFactory.java:1250)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:1099)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:545)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:502)
at org.springframework.beans.factory.support.AbstractBeanFactory.lambda$doGetBean$0(AbstractBeanFactory.java:312)
at org.springframework.beans.factory.support.AbstractBeanFactory$$Lambda$99/1286783232.getObject(Unknown Source)
at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:228)
- locked <0x00000005f80fc130> (a java.util.concurrent.ConcurrentHashMap)
at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:310)
at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:205)
at org.springframework.boot.web.servlet.ServletContextInitializerBeans.getOrderedBeansOfType(ServletContextInitializerBeans.java:226)
at org.springframework.boot.web.servlet.ServletContextInitializerBeans.getOrderedBeansOfType(ServletContextInitializerBeans.java:214)
at org.springframework.boot.web.servlet.ServletContextInitializerBeans.addServletContextInitializerBeans(ServletContextInitializerBeans.java:91)
at org.springframework.boot.web.servlet.ServletContextInitializerBeans.<init>(ServletContextInitializerBeans.java:79)
at org.springframework.boot.web.servlet.context.ServletWebServerApplicationContext.getServletContextInitializerBeans(ServletWebServerApplicationContext.java:250)
at org.springframework.boot.web.servlet.context.ServletWebServerApplicationContext.selfInitialize(ServletWebServerApplicationContext.java:237)
at org.springframework.boot.web.servlet.context.ServletWebServerApplicationContext$$Lambda$254/225344427.onStartup(Unknown Source)
at org.springframework.boot.web.embedded.tomcat.TomcatStarter.onStartup(TomcatStarter.java:54)
at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5204)
- locked <0x00000005f80f8200> (a org.springframework.boot.web.embedded.tomcat.TomcatEmbeddedContext)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
- locked <0x00000005f80f8200> (a org.springframework.boot.web.embedded.tomcat.TomcatEmbeddedContext)
at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1419)
at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1409)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Locked ownable synchronizers:
- <0x00000005f80ff838> (a java.util.concurrent.ThreadPoolExecutor$Worker)
Thanks,
Sibin Karnavar
> "Frozen" coordinator causes the whole cluster to hang
> -----------------------------------------------------
>
> Key: JGRP-2262
> URL: https://issues.jboss.org/browse/JGRP-2262
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.7
> Reporter: Pietro Paolini
> Assignee: Bela Ban
> Fix For: 4.0.12
>
> Attachments: jdbc_test.xml, jgroup.zip
>
>
> This is the result of an investigation I carried out for a problem we have experienced within our
> application, the scenario it has been re-created by pausing the JVM using a debugger.
> The discovery mechanism is JDBC_PING.
> If the coordinator's JVM gets fronzen (for whatever reason) before the coordinator sets itself as the cluster coordinator and another node is started after that it will be unable to join the cluster and it will hang indefinitely.
> This seems to be caused by the "continue" statement at
> https://github.com/belaban/JGroups/blob/master/src/org/jgroups/protocols/...
> I have prepared a simple application which can help in replicating the problem.
> To replicate the problem :
> 1) Make sure the JGROUPSPING is empty
> 2) Run the application using an IDE and attaching a debugger to cause the JVM to
> be paused at line Main.java:67, wait for it.
> 3) Run the application in non debug mode or with gradle using "gradle run" and it will
> hang indefinitely
> Depending on the UUID/IP Address being used generated/assigned this may not happen all the time but it happened quite often in my local tests.
>
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (WFLY-10222) Problems in a JAX-RS deployment can cause issues with reading resources from the management model
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-10222?page=com.atlassian.jira.plugin... ]
Brian Stansberry commented on WFLY-10222:
-----------------------------------------
The fix for this JIRA is basically a workaround that prevents a more critical problem -- the inability to read a large resource tree due to a relatively unimportant failure in a small piece -- by introducing a different bug: ignoring a failure, even when it occurs in a narrow context where the failure is *not* relatively unimportant.
I believe the benefit of the workaround fix outweighs the cost of adding the different bug. But it should be understood that the added bug is a bug, and that an overall fix that adds the correct behavior and removes the workaround should not be considered to be a regression, even if some use cases that work with the workaround to now break.
See WFCORE-3754 for further details. The proposal there would basically require some sort of input from the client in order to ignore failures. The expectation is the console would provide that input when appropriate for its requests. Other clients, e.g. the CLI executing a low level operation, would not.
The original report here is about web console usage. So long as the web console usage is not broken in any permanent fix, that should mean there is no regression introduced by the permanent fix.
> Problems in a JAX-RS deployment can cause issues with reading resources from the management model
> -------------------------------------------------------------------------------------------------
>
> Key: WFLY-10222
> URL: https://issues.jboss.org/browse/WFLY-10222
> Project: WildFly
> Issue Type: Bug
> Components: REST
> Affects Versions: 12.0.0.Final
> Reporter: Aquiles Remon
> Assignee: Stuart Douglas
>
> I have installed wildfly 12.0.0 final, or it says the file name I just downloaded from your site. It was working perfectly. After a while, I just installed Keycloak server 3.4.3 and the corresponding adapter for wildfly. From this moment on, every time I access to my local installation of wildfly through the web console I cannot see my deployments anymore, it returned the following error:
> 12:24:44,481 WARN [org.jboss.modules] (External Management Request Threads -- 1) Failed to define class org.apache.hadoop.hdfs.web.resources.UserProvider in Module "deployment.main-project-1.0.ear.web-toxi-0.0.1-SNAPSHOT.war" from Service Module Loader: java.lang.NoClassDefFoundError: Failed to link org/apache/hadoop/hdfs/web/resources/UserProvider (Module "deployment.main-project-1.0.ear.web-toxi-0.0.1-SNAPSHOT.war" from Service Module Loader): com/sun/jersey/spi/inject/InjectableProvider
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:456)
> at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:275)
> at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:78)
> at org.jboss.modules.Module.loadModuleClass(Module.java:717)
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:191)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:412)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:400)
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116)
> at org.jboss.resteasy.spi.ResteasyDeployment.registerProvider(ResteasyDeployment.java:623)
> at org.jboss.resteasy.spi.ResteasyDeployment.registration(ResteasyDeployment.java:404)
> at org.jboss.resteasy.spi.ResteasyDeployment.startInternal(ResteasyDeployment.java:279)
> at org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:86)
> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:119)
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36)
> at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117)
> at org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:78)
> at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103)
> at io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:300)
> at io.undertow.servlet.core.ManagedServlet.getServlet(ManagedServlet.java:190)
> at org.jboss.as.jaxrs.DeploymentRestResourcesDefintion$AbstractRestResReadHandler.lambda$execute$0(DeploymentRestResourcesDefintion.java:188)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:42)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1526)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1526)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1526)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1526)
> at org.jboss.as.jaxrs.DeploymentRestResourcesDefintion$AbstractRestResReadHandler.execute(DeploymentRestResourcesDefintion.java:232)
> at org.jboss.as.controller.operations.global.ReadAttributeHandler.doExecuteInternal(ReadAttributeHandler.java:172)
> at org.jboss.as.controller.operations.global.ReadAttributeHandler.doExecute(ReadAttributeHandler.java:135)
> at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AbstractMultiTargetHandler.execute(GlobalOperationHandlers.java:232)
> at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AvailableResponseWrapper.execute(GlobalOperationHandlers.java:992)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:982)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:726)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:450)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1408)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:423)
> at org.jboss.as.controller.ModelControllerImpl.lambda$execute$1(ModelControllerImpl.java:243)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:263)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:229)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:243)
> at org.jboss.as.domain.http.server.DomainApiHandler.handleRequest(DomainApiHandler.java:212)
> at io.undertow.server.handlers.encoding.EncodingHandler.handleRequest(EncodingHandler.java:72)
> at org.jboss.as.domain.http.server.DomainApiCheckHandler.handleRequest(DomainApiCheckHandler.java:93)
> at org.jboss.as.domain.http.server.security.ElytronIdentityHandler.lambda$handleRequest$0(ElytronIdentityHandler.java:62)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:287)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:244)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:254)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:225)
> at org.jboss.as.domain.http.server.security.ElytronIdentityHandler.handleRequest(ElytronIdentityHandler.java:61)
> at io.undertow.server.handlers.BlockingHandler.handleRequest(BlockingHandler.java:56)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:360)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1349)
> at java.lang.Thread.run(Thread.java:748)
> at org.jboss.threads.JBossThread.run(JBossThread.java:485)
> 12:24:44,484 ERROR [org.jboss.as.controller.management-operation] (External Management Request Threads -- 1) WFLYCTL0013: Operation ("read-attribute") failed - address: ([
> ("deployment" => "main-project-1.0.ear"),
> ("subdeployment" => "web-toxi-0.0.1-SNAPSHOT.war"),
> ("subsystem" => "jaxrs"),
> ("rest-resource" => "org.apache.hadoop.hdfs.server.namenode.web.resources.NamenodeWebHdfsMethods")
> ]): java.lang.NoClassDefFoundError: Failed to link org/apache/hadoop/hdfs/web/resources/UserProvider (Module "deployment.main-project-1.0.ear.web-toxi-0.0.1-SNAPSHOT.war" from Service Module Loader): com/sun/jersey/spi/inject/InjectableProvider
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:456)
> at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:275)
> at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:78)
> at org.jboss.modules.Module.loadModuleClass(Module.java:717)
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:191)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:412)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:400)
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116)
> at org.jboss.resteasy.spi.ResteasyDeployment.registerProvider(ResteasyDeployment.java:623)
> at org.jboss.resteasy.spi.ResteasyDeployment.registration(ResteasyDeployment.java:404)
> at org.jboss.resteasy.spi.ResteasyDeployment.startInternal(ResteasyDeployment.java:279)
> at org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:86)
> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:119)
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36)
> at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117)
> at org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:78)
> at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103)
> at io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:300)
> at io.undertow.servlet.core.ManagedServlet.getServlet(ManagedServlet.java:190)
> at org.jboss.as.jaxrs.DeploymentRestResourcesDefintion$AbstractRestResReadHandler.lambda$execute$0(DeploymentRestResourcesDefintion.java:188)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:42)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1526)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1526)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1526)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1526)
> at org.jboss.as.jaxrs.DeploymentRestResourcesDefintion$AbstractRestResReadHandler.execute(DeploymentRestResourcesDefintion.java:232)
> at org.jboss.as.controller.operations.global.ReadAttributeHandler.doExecuteInternal(ReadAttributeHandler.java:172)
> at org.jboss.as.controller.operations.global.ReadAttributeHandler.doExecute(ReadAttributeHandler.java:135)
> at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AbstractMultiTargetHandler.execute(GlobalOperationHandlers.java:232)
> at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AvailableResponseWrapper.execute(GlobalOperationHandlers.java:992)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:982)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:726)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:450)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1408)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:423)
> at org.jboss.as.controller.ModelControllerImpl.lambda$execute$1(ModelControllerImpl.java:243)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:263)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:229)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:243)
> at org.jboss.as.domain.http.server.DomainApiHandler.handleRequest(DomainApiHandler.java:212)
> at io.undertow.server.handlers.encoding.EncodingHandler.handleRequest(EncodingHandler.java:72)
> at org.jboss.as.domain.http.server.DomainApiCheckHandler.handleRequest(DomainApiCheckHandler.java:93)
> at org.jboss.as.domain.http.server.security.ElytronIdentityHandler.lambda$handleRequest$0(ElytronIdentityHandler.java:62)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:287)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:244)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:254)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:225)
> at org.jboss.as.domain.http.server.security.ElytronIdentityHandler.handleRequest(ElytronIdentityHandler.java:61)
> at io.undertow.server.handlers.BlockingHandler.handleRequest(BlockingHandler.java:56)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:360)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1349)
> at java.lang.Thread.run(Thread.java:748)
> at org.jboss.threads.JBossThread.run(JBossThread.java:485)
> I have read that this is a known issue and can ignore it; this thing is every time I need to modify or redeploy something I have to remove the corresponding tag from standalone.xml and restart wildfly server. Anyway it's working in local environment but a I have to set the production wildfly server by installing Keycloak server and its adapter and I don't know if this is going to break something; considering the wildfly is already installed (same version as mine) and working properly, but without keycloak.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (JASSIST-268) Gettig Java.lang.VerifyError with Latest Javassist, Powermock 1.7 and Java 1.8
by Pedro Cerejo (JIRA)
[ https://issues.jboss.org/browse/JASSIST-268?page=com.atlassian.jira.plugi... ]
Pedro Cerejo edited comment on JASSIST-268 at 4/24/18 10:03 AM:
----------------------------------------------------------------
I'm also encountering the same error. In my case the error appears when i use the appendBefore method, with a for that has a continue, like a simple for:
{code:java}
for(int i = 0; i < beforeMethods.length; i++) {
continue;
}
{code}
for methods *with more than one argument*.
I'm assuming that has something to do with labels but i know nothing about bytecode so don't quote me on that.
was (Author: schimini):
I'm also encountering the same error. In my case the error appears when i use the appendBefore method, with a for that has a continue, like a simple for:
{code:java}
for(int i = 0; i < beforeMethods.length; i++) {
continue;
}
{code}
for methods with more than one argument.
I'm assuming that has something to do with labels but i know nothing about bytecode so don't quote me on that.
> Gettig Java.lang.VerifyError with Latest Javassist, Powermock 1.7 and Java 1.8
> ------------------------------------------------------------------------------
>
> Key: JASSIST-268
> URL: https://issues.jboss.org/browse/JASSIST-268
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.20.0-GA
> Environment: All
> Reporter: Rajesh Eagambaram
> Assignee: Shigeru Chiba
>
> Hi Team,
> We have our current JUnit development completed using Java 1.6 using Powermock1.7 and Javaassist 3.20.0-GA and it is working fine. When we upgrade the JDK to 1.8 we are getting the error "Java.lang.VerifyError: Expecting a stackmap frame at branch target 64".
> Please help to fix the issue
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (JASSIST-268) Gettig Java.lang.VerifyError with Latest Javassist, Powermock 1.7 and Java 1.8
by Pedro Cerejo (JIRA)
[ https://issues.jboss.org/browse/JASSIST-268?page=com.atlassian.jira.plugi... ]
Pedro Cerejo commented on JASSIST-268:
--------------------------------------
I'm also encountering the same error. In my case the error appears when i use the appendBefore method, with a for that has a continue, like a simple for:
{code:java}
for(int i = 0; i < beforeMethods.length; i++) {
continue;
}
{code}
for methods with more than one argument.
I'm assuming that has something to do with labels but i know nothing about bytecode so don't quote me on that.
> Gettig Java.lang.VerifyError with Latest Javassist, Powermock 1.7 and Java 1.8
> ------------------------------------------------------------------------------
>
> Key: JASSIST-268
> URL: https://issues.jboss.org/browse/JASSIST-268
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.20.0-GA
> Environment: All
> Reporter: Rajesh Eagambaram
> Assignee: Shigeru Chiba
>
> Hi Team,
> We have our current JUnit development completed using Java 1.6 using Powermock1.7 and Javaassist 3.20.0-GA and it is working fine. When we upgrade the JDK to 1.8 we are getting the error "Java.lang.VerifyError: Expecting a stackmap frame at branch target 64".
> Please help to fix the issue
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years