[JBoss JIRA] (WFLY-12188) Option READ_TIMEOUT is ignored
by Flavia Rainone (Jira)
[ https://issues.jboss.org/browse/WFLY-12188?page=com.atlassian.jira.plugin... ]
Flavia Rainone commented on WFLY-12188:
---------------------------------------
I plan to look at this Jira at this week.
> Option READ_TIMEOUT is ignored
> ------------------------------
>
> Key: WFLY-12188
> URL: https://issues.jboss.org/browse/WFLY-12188
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Remoting
> Affects Versions: 17.0.0.Final
> Reporter: Joerg Baesner
> Assignee: Flavia Rainone
> Priority: Blocker
> Labels: blocker-WF18
>
> What's the difference of the {{READ_TIMEOUT}} in _ejb3_ subsystem vs. _remoting_ subsystem? See:
> {code}
> <remote connector-ref="http-remoting-connector" thread-pool-name="default">
> <channel-creation-options>
> <option name="READ_TIMEOUT" value="${prop.remoting-connector.read.timeout:20}" type="xnio"/>
> <option name="MAX_OUTBOUND_MESSAGES" value="1234" type="remoting"/>
> </channel-creation-options>
> </remote>
> {code}
> {code}
> <subsystem xmlns="urn:jboss:domain:remoting:4.0">
> <endpoint/>
> <http-connector name="http-remoting-connector" connector-ref="default" security-realm="ApplicationRealm">
> <!-- server-side configuration -->
> <properties>
> <property name="org.jboss.remoting3.RemotingOptions.HEARTBEAT_INTERVAL" value="5000"/>
> <property name="KEEP_ALIVE" value="true"/>
> <property name="READ_TIMEOUT" value="10000"/>
> <property name="WRITE_TIMEOUT" value="10000"/>
> </properties>
> </http-connector>
> {code}
> None of those options work.
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
6 years, 8 months
[JBoss JIRA] (WFLY-11218) IIOP call does not work with transaction started on client side when run on IBM JDK
by Tomasz Adamski (Jira)
[ https://issues.jboss.org/browse/WFLY-11218?page=com.atlassian.jira.plugin... ]
Tomasz Adamski resolved WFLY-11218.
-----------------------------------
Resolution: Explained
> IIOP call does not work with transaction started on client side when run on IBM JDK
> -----------------------------------------------------------------------------------
>
> Key: WFLY-11218
> URL: https://issues.jboss.org/browse/WFLY-11218
> Project: WildFly
> Issue Type: Bug
> Components: IIOP
> Affects Versions: 14.0.0.Final, 15.0.0.Beta1
> Environment: IBM JDK 8
> Reporter: Ivan Straka
> Assignee: Tomasz Adamski
> Priority: Blocker
> Labels: blocker-WF18
>
> Issue is valid only for IBM JDK 8...scenario works on oracle jdk 8 and 11 and openjdk 8.
> Scenario (using CORBA):
> # start transaction
> # lookup
> # IIOP call
> # EJB perform a basic operation and return (no failure is expected)
> IIOP call fails with following exception:
> {code:java}
> java.lang.NullPointerException: null
> at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.sentFullMessage(CorbaMessageMediatorImpl.java:429)
> at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.sendCancelRequestIfFinalFragmentNotSent(CorbaMessageMediatorImpl.java:394)
> at com.sun.corba.se.impl.protocol.CorbaClientRequestDispatcherImpl.endRequest(CorbaClientRequestDispatcherImpl.java:895)
> at com.sun.corba.se.impl.protocol.CorbaClientDelegateImpl.releaseReply(CorbaClientDelegateImpl.java:167)
> at com.sun.corba.se.impl.protocol.CorbaClientDelegateImpl.is_a(CorbaClientDelegateImpl.java:253)
> at org.omg.CORBA.portable.ObjectImpl._is_a(ObjectImpl.java:139)
> at org.omg.CosNaming.NamingContextHelper.narrow(NamingContextHelper.java:91)
> at com.sun.jndi.cosnaming.CNCtx.setOrbAndRootContext(CNCtx.java:408)
> at com.sun.jndi.cosnaming.CNCtx.initOrbAndRootContext(CNCtx.java:274)
> at com.sun.jndi.cosnaming.CNCtx.<init>(CNCtx.java:132)
> at com.sun.jndi.cosnaming.CNCtxFactory.getInitialContext(CNCtxFactory.java:61)
> at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:695)
> at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:324)
> at javax.naming.InitialContext.init(InitialContext.java:255)
> at javax.naming.InitialContext.<init>(InitialContext.java:227)
> at org.jboss.as.test.jbossts.client.utils.TxUtil.lookupIIOP(TxUtil.java:93)
> at org.jboss.as.test.jbossts.client.utils.TxUtil.lookupIIOP(TxUtil.java:103)
> at org.jboss.as.test.jbossts.crashrec.test.JMSCrashRecoveryTestCase.lookupCrashBeanOverIIOP(JMSCrashRecoveryTestCase.java:164)
> at org.jboss.as.test.jbossts.crashrec.test.JMSCrashRecoveryTestCase.callCrashTest(JMSCrashRecoveryTestCase.java:126)
> {code}
> When transaction is not started on client side, IIOP call works smoothly.
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
6 years, 8 months
[JBoss JIRA] (WFWIP-188) [Galleon] Exisiting EAP templates are not able to use chained builds
by Michal Jurc (Jira)
[ https://issues.jboss.org/browse/WFWIP-188?page=com.atlassian.jira.plugin.... ]
Michal Jurc commented on WFWIP-188:
-----------------------------------
[~jdenise], [~brian.stansberry]: Do you mean to ask whether including chained builds in _some_ templates is an acceptable solution?
Well, it is kinda hard to tell for me right now. I would hugely prefer including chained builds in all templates. Our docs largely mention {{basic-s2i}}, {{tx-recovery-s2i}} and so on, basically the templates that contain {{JGROUPS_CLUSTER_PASSWORD}}. The quickstarts refer to these templates as well.
Also, before making an educated guess, I will need to dig in to what it would mean for disk space usage to have the two images present. I am not sure right now if the two mentioned images are produced and kept after the build is done and whether both of them are required for the application to function. If sum of their sizes would be larger than non-trimmed and both of the images would be required for correct function of the deployment, that would be kind of bad.
> [Galleon] Exisiting EAP templates are not able to use chained builds
> --------------------------------------------------------------------
>
> Key: WFWIP-188
> URL: https://issues.jboss.org/browse/WFWIP-188
> Project: WildFly WIP
> Issue Type: Bug
> Components: OpenShift
> Reporter: Michal Jurc
> Assignee: Jean Francois Denise
> Priority: Critical
>
> It's not possible to trigger a chained build with existing EAP templates. This kind of hinders the usability since the existing templates already cover a lot of useful test cases.
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
6 years, 8 months
[JBoss JIRA] (WFLY-12304) Upgrade Apache Artemis from 2.9.0 to 2.10.0
by Clebert Suconic (Jira)
[ https://issues.jboss.org/browse/WFLY-12304?page=com.atlassian.jira.plugin... ]
Clebert Suconic edited comment on WFLY-12304 at 9/9/19 8:59 AM:
----------------------------------------------------------------
The REPLICATION_START_FINISH_SYNC packet never arriving is a symptom of the issue I explained.
Look at this commit on artemis: https://github.com/apache/activemq-artemis/commit/85b93f0883bc06a2dfe2de9...
Since this commit, we are using NonFileClosingDefaultFileRegion to send the body of the file. it's sending it with zero copy.
On the same commit, look at the change on NettyConnectionm, method getFileObject.
NonFileClosingDefaultFileRegion is being ignored by the netty-xnio-transport handler, what will make the whole thing to freeze, not receive any data on the other side of the replication, and the replication-finish to never arrive.
I tried implementing a proper handler for the FileRegion, but it did not work.
The handler has code for FileRegion but for some reason that code is never happening... and I don't know the component well enough to fix it.
> Upgrade Apache Artemis from 2.9.0 to 2.10.0
> -------------------------------------------
>
> Key: WFLY-12304
> URL: https://issues.jboss.org/browse/WFLY-12304
> Project: WildFly
> Issue Type: Component Upgrade
> Components: JMS
> Reporter: Martin Stefanko
> Assignee: Emmanuel Hugonnet
> Priority: Blocker
> Labels: blocker-WF18, downstream_dependency
>
> Upgrade Apache Artemis from 2.9.0.Final to 2.10.0.Final.
> Due to HA issue with Apache Artemis 2.10.0 this may not be the final version upgrade
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
6 years, 8 months
[JBoss JIRA] (WFLY-12462) Incompatible conflicting binding Exception and EJB naming
by Alexey Usharovski (Jira)
[ https://issues.jboss.org/browse/WFLY-12462?page=com.atlassian.jira.plugin... ]
Alexey Usharovski commented on WFLY-12462:
------------------------------------------
[~cfang] Looks like I also can't reproduce that now. Very likely it was kind of misconfiguration after several deployments of application. Going to try to reproduce again ASAP.
> Incompatible conflicting binding Exception and EJB naming
> ---------------------------------------------------------
>
> Key: WFLY-12462
> URL: https://issues.jboss.org/browse/WFLY-12462
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, EJB
> Affects Versions: 17.0.1.Final
> Environment: MacOS High Sierra
> Reporter: Alexey Usharovski
> Assignee: Cheng Fang
> Priority: Minor
> Attachments: server.log.zip, simplewebapp-lesson-6-ejb.zip, war-content.txt.zip
>
>
> Wired exception for very simple EJB with @Remote annotated interface in time of deploy to WildFly 17.0.1.Final
> {code:java}
> @Stateless
> public class UserServiceImpl implements UserServiceRemote {
> @Override
> public List<UserRepr> getAllUsers() {
> return null;
> }
> }
> @Remote
> public interface UserServiceRemote {
> List<UserRepr> getAllUsers();
> }
> {code}
> The exception is
> {code}
> Caused by: java.lang.IllegalArgumentException: WFLYEE0047: Incompatible conflicting binding at java:jboss/exported/simple-webapp/UserServiceImpl!ru.geekbrains.jsf.UserServiceRemote
> source: org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor$2@6aba1c4b"},
> "WFLYCTL0412: Required services that are not installed:" => [ "jboss.deployment.unit.\"simple-webapp.war\".beanmanager", "jboss.deployment.unit.\"simple-webapp.war\".WeldStartService" ],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => [ "jboss.deployment.unit.\"simple-webapp.war\".batch.artifact.factory is missing [jboss.deployment.unit.\"simple-webapp.war\".beanmanager]",
> "jboss.deployment.unit.\"simple-webapp.war\".weld.weldClassIntrospector is missing [jboss.deployment.unit.\"simple-webapp.war\".beanmanager, jboss.deployment.unit.\"simple-webapp.war\".WeldStartService]" ] }
> {code}
> Notice that problem could be resolved by undeploy and Wildfly server restart. May be something wrong with JNDI content?
> I've tried to look through the web console but found nothing interesting.
> Full application code on GitHub https://github.com/usharik/simplewebapp/tree/lesson-6-ejb
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
6 years, 8 months
[JBoss JIRA] (WFWIP-175) Operator doesn't react on env removal
by Petr Kremensky (Jira)
[ https://issues.jboss.org/browse/WFWIP-175?page=com.atlassian.jira.plugin.... ]
Petr Kremensky commented on WFWIP-175:
--------------------------------------
The test passes, I run the rest of the tests we have to check for the regressions and let you know.
> Operator doesn't react on env removal
> -------------------------------------
>
> Key: WFWIP-175
> URL: https://issues.jboss.org/browse/WFWIP-175
> Project: WildFly WIP
> Issue Type: Bug
> Components: OpenShift
> Reporter: Petr Kremensky
> Assignee: Jeff Mesnil
> Priority: Blocker
>
> Removing env from WildFlyServerSpec is not reflected by Operator.
> *Actual:*
> * removing env doesn't trigger update action
> * removed envs are never actually removed prom the projects
> *Expected:*
> * removing env does trigger update action
> * removed envs are removed prom the projects
> *Steps to reproduce:*
> {code}
> cat eap-operator.yaml
> ...
> spec:
> applicationImage: <image>
> env:
> - name: TEST_START
> value: INITIAL
> size: 1
> ...
> {code}
> Deploy and see the envs
> {code}
> oc apply -f eap-operator.yaml
> oc set env pod/eap-operator-0 --list | grep TEST
> TEST_START=INITIAL
> {code}
> change the value of variable to TEST_START=UPDATE
> {code}
> oc edit wildflyserver eap-operator
> env:
> - name: TEST_START
> value: UPDATE
> # wait till the eap pod is terminated, a new one is started instead
> oc set env pod/eap-operator-0 --list | grep TEST
> TEST_START=UPDATE
> {code}
> change the name of variable to TEST_UPDATE=UPDATE - {color:red}a new one is created!{color}
> {code}
> oc edit wildflyserver eap-operator
> env:
> - name: TEST_UPDATE
> value: UPDATE
> # wait till the eap pod is terminated, a new one is started instead
> oc set env pod/eap-operator-0 --list | grep TEST
> TEST_START=UPDATE
> TEST_UPDATE=UPDATE
> {code}
> remove the entire env section from spec - {color:red}delete envs are not removed!{color}
> {code}
> oc edit wildflyserver eap-operator
> # no pods update is triggered, operator didn't react on envs removal
> oc set env pod/eap-operator-0 --list | grep TEST
> TEST_START=UPDATE
> TEST_UPDATE=UPDATE
> {code}
> add a new env - {color:red}pod still contains deleted envs!{color}
> {code}
> oc edit wildflyserver eap-operator
> env:
> - name: TEST_ADD
> value: ADD
> # wait till the eap pod is terminated, a new one is started instead
> oc set env pod/eap-operator-0 --list | grep TEST
> TEST_START=UPDATE
> TEST_UPDATE=UPDATE
> TEST_ADD=ADD
> {code}
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
6 years, 8 months
[JBoss JIRA] (DROOLS-4486) Duplicate default namespace declaration exception after importing DMN file
by Jozef Marko (Jira)
[ https://issues.jboss.org/browse/DROOLS-4486?page=com.atlassian.jira.plugi... ]
Jozef Marko updated DROOLS-4486:
--------------------------------
Labels: drools-tools support (was: support)
> Duplicate default namespace declaration exception after importing DMN file
> --------------------------------------------------------------------------
>
> Key: DROOLS-4486
> URL: https://issues.jboss.org/browse/DROOLS-4486
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Reporter: Martin Weiler
> Assignee: Guilherme Gomes
> Priority: Major
> Labels: drools-tools, support
>
> Building a project in business-central which contains a DMN file from the drools test codebase fails with the following exception:
> {noformat}
> 07:48:29,886 ERROR [org.kie.dmn.backend.marshalling.v1x.XStreamMarshaller] (EJB default - 3) Error unmarshalling DMN model from reader.: com.thoughtworks.xstream.io.StreamException:
> at org.kie.dmn.backend.marshalling.CustomStaxReader.pullNextEvent(CustomStaxReader.java:118)
> at com.thoughtworks.xstream.io.xml.AbstractPullReader.readRealEvent(AbstractPullReader.java:148)
> at com.thoughtworks.xstream.io.xml.AbstractPullReader.readEvent(AbstractPullReader.java:141)
> at com.thoughtworks.xstream.io.xml.AbstractPullReader.move(AbstractPullReader.java:118)
> at com.thoughtworks.xstream.io.xml.AbstractPullReader.moveDown(AbstractPullReader.java:103)
> at org.kie.dmn.backend.marshalling.CustomStaxReader.moveDown(CustomStaxReader.java:97)
> at org.kie.dmn.backend.marshalling.CustomStaxReader.<init>(CustomStaxReader.java:31)
> at org.kie.dmn.backend.marshalling.v1x.XStreamMarshaller.inferDMNVersion(XStreamMarshaller.java:86)
> at org.kie.dmn.backend.marshalling.v1x.XStreamMarshaller.unmarshal(XStreamMarshaller.java:62)
> at org.kie.dmn.backend.marshalling.v1x.XStreamMarshaller.unmarshal(XStreamMarshaller.java:106)
> at org.kie.dmn.core.assembler.DMNAssemblerService.addResources(DMNAssemblerService.java:93)
> at org.kie.internal.services.KieAssemblersImpl.addResources(KieAssemblersImpl.java:60)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.addPackageForExternalType(KnowledgeBuilderImpl.java:813)
> at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.buildOthers(CompositeKnowledgeBuilderImpl.java:161)
> at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.build(CompositeKnowledgeBuilderImpl.java:113)
> at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.build(CompositeKnowledgeBuilderImpl.java:100)
> at org.drools.compiler.kie.builder.impl.KieBuilderSetImpl.buildChanges(KieBuilderSetImpl.java:152)
> at org.drools.compiler.kie.builder.impl.KieBuilderSetImpl.build(KieBuilderSetImpl.java:94)
> at org.kie.workbench.common.services.backend.builder.core.Builder.buildIncrementally(Builder.java:533)
> at org.kie.workbench.common.services.backend.builder.core.Builder.addResource(Builder.java:354)
> at org.kie.workbench.common.services.backend.builder.core.Builder.addResource(Builder.java:320)
> at org.kie.workbench.common.services.backend.builder.core.Builder.updateResource(Builder.java:414)
> at org.kie.workbench.common.services.backend.builder.core.BuildHelper.updatePackageResource(BuildHelper.java:167)
> at org.kie.workbench.common.services.backend.builder.core.BuildHelper$Proxy$_$$_WeldClientProxy.updatePackageResource(Unknown Source)
> at org.kie.workbench.common.services.backend.builder.ala.LocalBuildExecConfigExecutor.apply(LocalBuildExecConfigExecutor.java:70)
> at org.kie.workbench.common.services.backend.builder.ala.LocalBuildExecConfigExecutor.apply(LocalBuildExecConfigExecutor.java:32)
> at org.kie.workbench.common.services.backend.builder.ala.LocalBuildExecConfigExecutor$Proxy$_$$_WeldClientProxy.apply(Unknown Source)
> at org.guvnor.ala.pipeline.execution.PipelineExecutor.lambda$continuePipeline$0(PipelineExecutor.java:109)
> at org.guvnor.ala.pipeline.StageUtil$1.execute(StageUtil.java:38)
> at org.guvnor.ala.pipeline.StageUtil$1.execute(StageUtil.java:33)
> at org.guvnor.ala.pipeline.execution.PipelineExecutor.continuePipeline(PipelineExecutor.java:94)
> at org.guvnor.ala.pipeline.execution.PipelineExecutor.execute(PipelineExecutor.java:76)
> at org.kie.workbench.common.services.backend.builder.ala.BuildPipelineInvoker.invokeLocalBuildPipeLine(BuildPipelineInvoker.java:88)
> at org.kie.workbench.common.services.backend.builder.ala.BuildPipelineInvoker$Proxy$_$$_WeldClientProxy.invokeLocalBuildPipeLine(Unknown Source)
> at org.kie.workbench.common.services.backend.builder.service.BuildServiceHelper.invokeLocalBuildPipeLine(BuildServiceHelper.java:163)
> at org.kie.workbench.common.services.backend.builder.service.BuildServiceHelper.localBuild(BuildServiceHelper.java:98)
> at org.kie.workbench.common.services.backend.builder.service.BuildServiceHelper$Proxy$_$$_WeldClientProxy.localBuild(Unknown Source)
> at org.kie.workbench.common.services.backend.builder.service.BuildServiceImpl.buildIncrementally(BuildServiceImpl.java:136)
> at org.kie.workbench.common.services.backend.builder.service.BuildServiceImpl.updatePackageResource(BuildServiceImpl.java:126)
> at org.kie.workbench.common.services.backend.builder.service.BuildServiceImpl$Proxy$_$$_WeldClientProxy.updatePackageResource(Unknown Source)
> at org.guvnor.common.services.builder.ResourceChangeIncrementalBuilder$4.execute(ResourceChangeIncrementalBuilder.java:262)
> at org.guvnor.common.services.builder.IncrementalBuilderExecutorManager.execute(IncrementalBuilderExecutorManager.java:90)
> 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.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509)
> at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:90)
> at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:101)
> at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:40)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53)
> at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.singleton.SingletonComponentInstanceAssociationInterceptor.processInvocation(SingletonComponentInstanceAssociationInterceptor.java:53)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInNoTx(CMTTxInterceptor.java:216)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.notSupported(CMTTxInterceptor.java:345)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:142)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509)
> at org.jboss.weld.module.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:81)
> at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:89)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509)
> at org.jboss.as.ejb3.component.singleton.ContainerManagedConcurrencyInterceptor.processInvocation(ContainerManagedConcurrencyInterceptor.java:106)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:60)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:438)
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:619)
> at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:57)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53)
> at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198)
> at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.LogDiagnosticContextRecoveryInterceptor.processInvocation(LogDiagnosticContextRecoveryInterceptor.java:82)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.AsyncFutureInterceptorFactory$2$2.runInvocation(AsyncFutureInterceptorFactory.java:152)
> at org.jboss.as.ejb3.component.interceptors.AsyncInvocationTask.run(AsyncInvocationTask.java:81)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> at org.jboss.threads.JBossThread.run(JBossThread.java:485)
> Caused by: com.ctc.wstx.exc.WstxParsingException: Duplicate default namespace declaration.
> at [row,col {unknown-source}]: [2,72]
> at com.ctc.wstx.sr.StreamScanner.constructWfcException(StreamScanner.java:621)
> at com.ctc.wstx.sr.StreamScanner.throwParseError(StreamScanner.java:491)
> at com.ctc.wstx.sr.StreamScanner.throwParseError(StreamScanner.java:475)
> at com.ctc.wstx.sr.BasicStreamReader.handleNsAttrs(BasicStreamReader.java:3140)
> at com.ctc.wstx.sr.BasicStreamReader.handleStartElem(BasicStreamReader.java:3043)
> at com.ctc.wstx.sr.BasicStreamReader.handleRootElem(BasicStreamReader.java:2179)
> at com.ctc.wstx.sr.BasicStreamReader.nextFromProlog(BasicStreamReader.java:2159)
> at com.ctc.wstx.sr.BasicStreamReader.next(BasicStreamReader.java:1181)
> at org.kie.dmn.backend.marshalling.CustomStaxReader.pullNextEvent(CustomStaxReader.java:102)
> ... 108 more
> {noformat}
> Upon re-opening the DMN file it fails to render the file in the DMN editor, and the following changes to the original xml file can be observed:
> a) new default xmlns attribute in definitions element has been added to the dmn file:
> {{xmlns="http://www.trisotech.com/definitions/_4e0f0b70-d31c-471c-bd52-5ca709ed362b"}}
> b) "tns:" has been changed to "tns."
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
6 years, 8 months
[JBoss JIRA] (WFWIP-175) Operator doesn't react on env removal
by Petr Kremensky (Jira)
[ https://issues.jboss.org/browse/WFWIP-175?page=com.atlassian.jira.plugin.... ]
Petr Kremensky commented on WFWIP-175:
--------------------------------------
Sure, I'll take a look and let you know.
> Operator doesn't react on env removal
> -------------------------------------
>
> Key: WFWIP-175
> URL: https://issues.jboss.org/browse/WFWIP-175
> Project: WildFly WIP
> Issue Type: Bug
> Components: OpenShift
> Reporter: Petr Kremensky
> Assignee: Jeff Mesnil
> Priority: Blocker
>
> Removing env from WildFlyServerSpec is not reflected by Operator.
> *Actual:*
> * removing env doesn't trigger update action
> * removed envs are never actually removed prom the projects
> *Expected:*
> * removing env does trigger update action
> * removed envs are removed prom the projects
> *Steps to reproduce:*
> {code}
> cat eap-operator.yaml
> ...
> spec:
> applicationImage: <image>
> env:
> - name: TEST_START
> value: INITIAL
> size: 1
> ...
> {code}
> Deploy and see the envs
> {code}
> oc apply -f eap-operator.yaml
> oc set env pod/eap-operator-0 --list | grep TEST
> TEST_START=INITIAL
> {code}
> change the value of variable to TEST_START=UPDATE
> {code}
> oc edit wildflyserver eap-operator
> env:
> - name: TEST_START
> value: UPDATE
> # wait till the eap pod is terminated, a new one is started instead
> oc set env pod/eap-operator-0 --list | grep TEST
> TEST_START=UPDATE
> {code}
> change the name of variable to TEST_UPDATE=UPDATE - {color:red}a new one is created!{color}
> {code}
> oc edit wildflyserver eap-operator
> env:
> - name: TEST_UPDATE
> value: UPDATE
> # wait till the eap pod is terminated, a new one is started instead
> oc set env pod/eap-operator-0 --list | grep TEST
> TEST_START=UPDATE
> TEST_UPDATE=UPDATE
> {code}
> remove the entire env section from spec - {color:red}delete envs are not removed!{color}
> {code}
> oc edit wildflyserver eap-operator
> # no pods update is triggered, operator didn't react on envs removal
> oc set env pod/eap-operator-0 --list | grep TEST
> TEST_START=UPDATE
> TEST_UPDATE=UPDATE
> {code}
> add a new env - {color:red}pod still contains deleted envs!{color}
> {code}
> oc edit wildflyserver eap-operator
> env:
> - name: TEST_ADD
> value: ADD
> # wait till the eap pod is terminated, a new one is started instead
> oc set env pod/eap-operator-0 --list | grep TEST
> TEST_START=UPDATE
> TEST_UPDATE=UPDATE
> TEST_ADD=ADD
> {code}
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
6 years, 8 months