January 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-12927) wildfly 8.2 huge memory allocation during and after deployement

by sandev sandev (Jira)

sandev sandev created WFLY-12927: ------------------------------------ Summary: wildfly 8.2 huge memory allocation during and after deployement Key: WFLY-12927 URL: https://issues.redhat.com/browse/WFLY-12927 Project: WildFly Issue Type: Feature Request Reporter: sandev sandev Assignee: Brian Stansberry Attachments: threads.png I am using wildfly 8.2.1 final to deploy java ee 7 maven web application wars about 30 war with dependence between them using rmi remote ejb. I found that the server consumes a lot of memory special on startup of the server to 8 g my java opt are -xms 8g -xmx 8g -metaspacesize 1g .so I use java "visualvm" to understand what is happening. I found that the most consumed memory is for 2 types of threads at deploy: MSC service thread and after deploy finish: DeployementScanner-threads in additional that no user use the server or the deployed application this server was just for test my question is why wildfly starts with about 3g and after some time the memory growth to ~= 8g without any action on the server its idle any help to solve this problem please -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ELYWEB-84) Upgrade Undertow to 2.0.29.Final

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/ELYWEB-84?page=com.atlassian.jira.plugin... ] Darran Lofthouse updated ELYWEB-84: ----------------------------------- Fix Version/s: 1.7.0.CR4 (was: 1.6.1.CR1) > Upgrade Undertow to 2.0.29.Final > -------------------------------- > > Key: ELYWEB-84 > URL: https://issues.redhat.com/browse/ELYWEB-84 > Project: Elytron Web > Issue Type: Component Upgrade > Components: Undertow > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Fix For: 1.7.0.CR4 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ELYWEB-84) Upgrade Undertow to 2.0.29.Final

by Darran Lofthouse (Jira)

Darran Lofthouse created ELYWEB-84: -------------------------------------- Summary: Upgrade Undertow to 2.0.29.Final Key: ELYWEB-84 URL: https://issues.redhat.com/browse/ELYWEB-84 Project: Elytron Web Issue Type: Component Upgrade Components: Undertow Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.6.1.CR1 -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4902) Can not use mod operators (%) in when closures.

by xb l (Jira)

xb l created DROOLS-4902: ---------------------------- Summary: Can not use mod operators (%) in when closures. Key: DROOLS-4902 URL: https://issues.redhat.com/browse/DROOLS-4902 Project: Drools Issue Type: Bug Components: core engine Affects Versions: 7.31.0.Final Reporter: xb l Assignee: Mario Fusco When I study drools , I write a rule use divide operator {code:java} rule "Buzz" salience 2 when $n: Number( this / 5 == 3 ) then System.out.println("Buzz"); end {code} It's OK. But: {code:java} rule "Buzz" salience 2 when $n: Number( this % 5 == 0 ) then System.out.println("Buzz"); end {code} Report parser error: Unable to Analyse Expression this % 5 == 0: -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-1048) Testcases - Kiali Validations sync-up

by Hayk Hovsepyan (Jira)

Hayk Hovsepyan created SWSQE-1048: ------------------------------------- Summary: Testcases - Kiali Validations sync-up Key: SWSQE-1048 URL: https://issues.redhat.com/browse/SWSQE-1048 Project: Kiali QE Issue Type: Sub-task Reporter: Hayk Hovsepyan Sync up all validations from https://kiali.io/documentation/validations/ with Polarion estcases. Make sure all validations have up-to-date testcases in Polarion. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-1047) Kiali Validations sync-up

by Hayk Hovsepyan (Jira)

[ https://issues.redhat.com/browse/SWSQE-1047?page=com.atlassian.jira.plugi... ] Hayk Hovsepyan updated SWSQE-1047: ---------------------------------- Sprint: Kiali Sprint #32 > Kiali Validations sync-up > ------------------------- > > Key: SWSQE-1047 > URL: https://issues.redhat.com/browse/SWSQE-1047 > Project: Kiali QE > Issue Type: QE Task > Reporter: Hayk Hovsepyan > Assignee: Hayk Hovsepyan > Priority: Major > Labels: automation > > Check all actual validations in https://kiali.io/documentation/validations/ > Sync up in Polarion testcases. > UI Automations. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-1047) Kiali Validations sync-up

by Hayk Hovsepyan (Jira)

Hayk Hovsepyan created SWSQE-1047: ------------------------------------- Summary: Kiali Validations sync-up Key: SWSQE-1047 URL: https://issues.redhat.com/browse/SWSQE-1047 Project: Kiali QE Issue Type: QE Task Reporter: Hayk Hovsepyan Assignee: Hayk Hovsepyan Check all actual validations in https://kiali.io/documentation/validations/ Sync up in Polarion testcases. UI Automations. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11566) ConstraintDeclarationException on JAX-RS/EJB Methods with List/Set query parameter

by Matěj Novotný (Jira)

[ https://issues.redhat.com/browse/WFLY-11566?page=com.atlassian.jira.plugi... ] Matěj Novotný commented on WFLY-11566: -------------------------------------- bq. The real VF used by WildFly is initialized here: https://github.com/hibernate/hibernate-validator/blob/master/cdi/src/main... . We can't get a bean from the BeanManager at that point? Thanks [~guillaume.smet], in this case *you can resolve beans* from within {{create()}} method. [~tomekadamski] this might be a way to go then. I suppose HV API would need to declare an interface that would become the bean type which WFLY will provide. And then from within {{ValidatorFactoryBean#create()}} you could use {{BeanManager}} (which is already present there) to resolve beans dynamically - note that this bean may or may not be present in various environments (will be in WFLY, won't be in Quarkus) and if present, you can hopefully use that to config validator factory before building it. > ConstraintDeclarationException on JAX-RS/EJB Methods with List/Set query parameter > ---------------------------------------------------------------------------------- > > Key: WFLY-11566 > URL: https://issues.redhat.com/browse/WFLY-11566 > Project: WildFly > Issue Type: Bug > Components: Bean Validation, EJB, REST > Affects Versions: 14.0.0.Final, 15.0.1.Final > Reporter: Alexander Wagner > Assignee: Tomasz Adamski > Priority: Critical > Labels: downstream_dependency > Attachments: WFLY-11566-3.tar > > > You got an exception if you call methods on JAX-RS endpoints which are also e.g. a stateless EJB and have Set or List as query parameters. > As a workaround we use the "@Context UriInfo info" as parameter an read the parameter manually. As a downside this parameters are missing than in automated api generation with e.g. swagger. Without the @NotEmpty annotation it works fine. Without the generic type parameter ie just List it works fine. Making it a simple CDI bean makes it work fine. > This issue is caused by [commit - WFLY-9628 Allow to switch to Hibernate Validator 6.0 / Bean Validation 2.0|https://github.com/wildfly/wildfly/commit/02f230d91f55f86ee6cadf53832...] > Steps to reproduce: > {code:java} > @Stateless > @Path("/") > public class Resource { > @POST > @Path("put/list") > @Consumes(MediaType.APPLICATION_JSON) > public String putList(@NotEmpty List<String> a) { > return "Hello bars " + a.stream().collect(Collectors.joining(", ")); > } > } > {code} > {noformat} > [mkopecky@dhcp-10-40-5-71 bin]$ curl -d '["a","b","c"]' -H "Content-Type: application/json" -X POST http://localhost:8080/jaxrs-wf/put/list > javax.validation.ConstraintDeclarationException: HV000151: A method overriding another method must not redefine the parameter constraint configuration, but method Resource$$$view1#putList(List) redefines the configuration of Resource#putList(List). > [mkopecky@dhcp-10-40-5-71 bin]$ > {noformat} > {noformat} > javax.validation.ConstraintDeclarationException: HV000151: A method overriding another method must not redefine the parameter constraint configuration, but method Resource$$$view1#putList(List) redefines the configuration of Resource#putList(List). > at org.hibernate.validator.internal.metadata.aggregated.rule.OverridingMethodMustNotAlterParameterConstraints.apply(OverridingMethodMustNotAlterParameterConstraints.java:24) > at org.hibernate.validator.internal.metadata.aggregated.ExecutableMetaData$Builder.assertCorrectnessOfConfiguration(ExecutableMetaData.java:461) > at org.hibernate.validator.internal.metadata.aggregated.ExecutableMetaData$Builder.build(ExecutableMetaData.java:377) > at org.hibernate.validator.internal.metadata.aggregated.BeanMetaDataImpl$BuilderDelegate.build(BeanMetaDataImpl.java:788) > at org.hibernate.validator.internal.metadata.aggregated.BeanMetaDataImpl$BeanMetaDataBuilder.build(BeanMetaDataImpl.java:648) > at org.hibernate.validator.internal.metadata.BeanMetaDataManager.createBeanMetaData(BeanMetaDataManager.java:192) > at org.hibernate.validator.internal.metadata.BeanMetaDataManager.lambda$getBeanMetaData$0(BeanMetaDataManager.java:160) > at java.util.concurrent.ConcurrentMap.computeIfAbsent(ConcurrentMap.java:324) > at org.hibernate.validator.internal.metadata.BeanMetaDataManager.getBeanMetaData(BeanMetaDataManager.java:159) > at org.hibernate.validator.internal.engine.ValidationContext$ValidationContextBuilder.forValidateParameters(ValidationContext.java:619) > at org.hibernate.validator.internal.engine.ValidatorImpl.validateParameters(ValidatorImpl.java:254) > at org.hibernate.validator.internal.engine.ValidatorImpl.validateParameters(ValidatorImpl.java:224) > at org.jboss.resteasy.plugins.validation.GeneralValidatorImpl.validateAllParameters(GeneralValidatorImpl.java:177) > at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:118) > at org.jboss.resteasy.core.ResourceMethodInvoker.internalInvokeOnTarget(ResourceMethodInvoker.java:509) > at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTargetAfterFilter(ResourceMethodInvoker.java:399) > at org.jboss.resteasy.core.ResourceMethodInvoker.lambda$invokeOnTarget$0(ResourceMethodInvoker.java:363) > at org.jboss.resteasy.core.interception.PreMatchContainerRequestContext.filter(PreMatchContainerRequestContext.java:355) > at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:365) > at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:337) > at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:310) > at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:439) > at org.jboss.resteasy.core.SynchronousDispatcher.lambda$invoke$4(SynchronousDispatcher.java:229) > at org.jboss.resteasy.core.SynchronousDispatcher.lambda$preprocess$0(SynchronousDispatcher.java:135) > at org.jboss.resteasy.core.interception.PreMatchContainerRequestContext.filter(PreMatchContainerRequestContext.java:355) > at org.jboss.resteasy.core.SynchronousDispatcher.preprocess(SynchronousDispatcher.java:138) > at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:215) > at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:227) > at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) > at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:791) > at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:74) > at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129) > at io.opentracing.contrib.jaxrs2.server.SpanFinishingFilter.doFilter(SpanFinishingFilter.java:55) > at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61) > at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) > at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84) > at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) > at io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:68) > at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) > at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:132) > at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) > at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) > at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) > at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) > at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) > at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292) > at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81) > at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138) > at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135) > at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) > 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:1502) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502) > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104) > 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:1378) > at java.lang.Thread.run(Thread.java:748) > {noformat} > Links: > * [forum|https://developer.jboss.org/thread/278822] > * WFLY-11566 -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-1038) VS Overview - HTTP Route automate

by Hayk Hovsepyan (Jira)

[ https://issues.redhat.com/browse/SWSQE-1038?page=com.atlassian.jira.plugi... ] Hayk Hovsepyan resolved SWSQE-1038. ----------------------------------- Resolution: Done > VS Overview - HTTP Route automate > --------------------------------- > > Key: SWSQE-1038 > URL: https://issues.redhat.com/browse/SWSQE-1038 > Project: Kiali QE > Issue Type: QE Task > Reporter: Hayk Hovsepyan > Assignee: Hayk Hovsepyan > Priority: Major > Labels: automation > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2429) MsgStats num_bytes_sent should be incremented by the Message::size

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2429?page=com.atlassian.jira.plugin... ] Bela Ban updated JGRP-2429: --------------------------- Fix Version/s: 4.1.9 I don't like this; num_bytes is always the number of bytes sent *in the payload* of a message. If you want the entire marshalled size of a message, I suggest introduce a new field. Method {{size()}} can be quite costly to compute (especially with other message types in 5.0), so -1 from me for using this in the transport. If needed, add this to the {{STATS}} protocol. > MsgStats num_bytes_sent should be incremented by the Message::size > ------------------------------------------------------------------ > > Key: JGRP-2429 > URL: https://issues.redhat.com/browse/JGRP-2429 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.1.8 > Reporter: Diego Lovison > Assignee: Diego Lovison > Priority: Major > Fix For: 4.1.9 > > > MsgStats num_bytes_sent should be incremented by the Message::size > Today it is incremented by the Message:length that is the length of the payload, it doesn't include the headers. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2429) MsgStats num_bytes_sent should be incremented by the Message::size

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2429?page=com.atlassian.jira.plugin... ] Bela Ban closed JGRP-2429. -------------------------- Resolution: Rejected > MsgStats num_bytes_sent should be incremented by the Message::size > ------------------------------------------------------------------ > > Key: JGRP-2429 > URL: https://issues.redhat.com/browse/JGRP-2429 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.1.8 > Reporter: Diego Lovison > Assignee: Diego Lovison > Priority: Major > Fix For: 4.1.9 > > > MsgStats num_bytes_sent should be incremented by the Message::size > Today it is incremented by the Message:length that is the length of the payload, it doesn't include the headers. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4898) Accumulates: min does not work after retracting fact.

by Hiroko Miura (Jira)

[ https://issues.redhat.com/browse/DROOLS-4898?page=com.atlassian.jira.plug... ] Hiroko Miura commented on DROOLS-4898: -------------------------------------- [~mfusco] Thank you for your clarification. I thought that retracting object of same type is enough to re-evaluation of existing facts as property 'longVal' in this reproducer (which is compared in accumulate function) is not changed. > Accumulates: min does not work after retracting fact. > ----------------------------------------------------- > > Key: DROOLS-4898 > URL: https://issues.redhat.com/browse/DROOLS-4898 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 7.26.0.Final, 7.31.0.Final > Reporter: Hiroko Miura > Assignee: Mario Fusco > Priority: Major > Labels: support > > The following rules does not work with specific facts. > {noformat} > rule "rule1_long" > when > accumulate( Fact( $longVal: longVal), $minVal : min($longVal)) > accumulate( Fact( $longVal2: longVal, $longVal2 > $minVal), $minVal2 : min($longVal2)) > $minFact: Fact( longVal == $minVal) > $minFact2: Fact( longVal == $minVal2) > then > System.out.println("Rule ["+kcontext.getRule().getName()+ "] fires!"); > Long $diff = (Long)$minVal2 - (Long)$minVal; > $minFact2.setDiff($diff); > // update($minFact2); > String errmsg = $diff == 0? " !!!!! ERROR !!!!!" : ""; > System.out.println( drools.getRule().getName() + " diff：" + $minFact2.getLongVal() + " - " + $minFact.getLongVal() + " = " + $diff + errmsg); > System.out.println("\tretract <= "+$minFact ); > retract($minFact); > end > {noformat} > There seems to be 2 kind of issues (root cause might be same though). > - 2nd accumulate return same min value with 1st one. > - rule fire count is less than expected. > This does not work with specific set of facts, but works with another set of facts. > If update is called for the fact like above commented out line, this does not happen. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12926) Upgrade Infinispan from 9.4.16.Final to 9.4.18.Final

by Chao Wang (Jira)

[ https://issues.redhat.com/browse/WFLY-12926?page=com.atlassian.jira.plugi... ] Chao Wang updated WFLY-12926: ----------------------------- Description: https://github.com/infinispan/infinispan/compare/9.4.16.Final...9.4.x > Upgrade Infinispan from 9.4.16.Final to 9.4.18.Final > ---------------------------------------------------- > > Key: WFLY-12926 > URL: https://issues.redhat.com/browse/WFLY-12926 > Project: WildFly > Issue Type: Component Upgrade > Components: Build System, Clustering > Affects Versions: 18.0.1.Final > Reporter: Chao Wang > Assignee: Paul Ferraro > Priority: Major > Labels: downstream_dependency > > https://github.com/infinispan/infinispan/compare/9.4.16.Final...9.4.x -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12926) Upgrade Infinispan from 9.4.16.Final to 9.4.18.Final

by Chao Wang (Jira)

[ https://issues.redhat.com/browse/WFLY-12926?page=com.atlassian.jira.plugi... ] Chao Wang updated WFLY-12926: ----------------------------- Component/s: Build System > Upgrade Infinispan from 9.4.16.Final to 9.4.18.Final > ---------------------------------------------------- > > Key: WFLY-12926 > URL: https://issues.redhat.com/browse/WFLY-12926 > Project: WildFly > Issue Type: Component Upgrade > Components: Build System, Clustering > Affects Versions: 18.0.1.Final > Reporter: Chao Wang > Assignee: Paul Ferraro > Priority: Major > Labels: downstream_dependency > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12926) Upgrade Infinispan from 9.4.16.Final to 9.4.18.Final

by Chao Wang (Jira)

[ https://issues.redhat.com/browse/WFLY-12926?page=com.atlassian.jira.plugi... ] Chao Wang updated WFLY-12926: ----------------------------- Labels: downstream_dependency (was: ) > Upgrade Infinispan from 9.4.16.Final to 9.4.18.Final > ---------------------------------------------------- > > Key: WFLY-12926 > URL: https://issues.redhat.com/browse/WFLY-12926 > Project: WildFly > Issue Type: Component Upgrade > Components: Build System, Clustering > Affects Versions: 18.0.1.Final > Reporter: Chao Wang > Assignee: Paul Ferraro > Priority: Major > Labels: downstream_dependency > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12926) Upgrade Infinispan from 9.4.16.Final to 9.4.18.Final

by Chao Wang (Jira)

Chao Wang created WFLY-12926: -------------------------------- Summary: Upgrade Infinispan from 9.4.16.Final to 9.4.18.Final Key: WFLY-12926 URL: https://issues.redhat.com/browse/WFLY-12926 Project: WildFly Issue Type: Component Upgrade Components: Clustering Affects Versions: 18.0.1.Final Reporter: Chao Wang Assignee: Paul Ferraro -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-292) Validate generated OpenAPI document

by Fabio Burzigotti (Jira)

Fabio Burzigotti created WFWIP-292: -------------------------------------- Summary: Validate generated OpenAPI document Key: WFWIP-292 URL: https://issues.redhat.com/browse/WFWIP-292 Project: WildFly WIP Issue Type: Enhancement Components: MP OpenAPI Reporter: Fabio Burzigotti Assignee: Paul Ferraro Currently no validation is provided for generated document and actually the spec is not requesting for vendors to do that [1] but it would definitely be a key improvement for customers and users in general to know that the generated document is checked and appropriate action is taken (e.g.: log WARN messages etc.). Online Swagger Editor [2] was used to verify that non valid content was generated. Also it should be evaluated whether to mention this behavior in community or product docs. [1] https://download.eclipse.org/microprofile/microprofile-open-api-1.1.2/mic... [2] https://editor.swagger.io/ -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-292) Validate generated OpenAPI document

by Fabio Burzigotti (Jira)

[ https://issues.redhat.com/browse/WFWIP-292?page=com.atlassian.jira.plugin... ] Fabio Burzigotti updated WFWIP-292: ----------------------------------- Description: Currently no validation is provided for generated document and actually the spec is not requesting for vendors to do that [1] but it would definitely be a key improvement for customers and users in general to know that the generated document is checked and appropriate action is taken in case content is not valid (e.g.: log WARN messages etc.). Online Swagger Editor [2] was used to verify that non valid content was generated. Also it should be evaluated whether to mention this behavior in community or product docs. [1] https://download.eclipse.org/microprofile/microprofile-open-api-1.1.2/mic... [2] https://editor.swagger.io/ was: Currently no validation is provided for generated document and actually the spec is not requesting for vendors to do that [1] but it would definitely be a key improvement for customers and users in general to know that the generated document is checked and appropriate action is taken (e.g.: log WARN messages etc.). Online Swagger Editor [2] was used to verify that non valid content was generated. Also it should be evaluated whether to mention this behavior in community or product docs. [1] https://download.eclipse.org/microprofile/microprofile-open-api-1.1.2/mic... [2] https://editor.swagger.io/ > Validate generated OpenAPI document > ------------------------------------- > > Key: WFWIP-292 > URL: https://issues.redhat.com/browse/WFWIP-292 > Project: WildFly WIP > Issue Type: Enhancement > Components: MP OpenAPI > Reporter: Fabio Burzigotti > Assignee: Paul Ferraro > Priority: Major > > Currently no validation is provided for generated document and actually the spec is not requesting for vendors to do that [1] but it would definitely be a key improvement for customers and users in general to know that the generated document is checked and appropriate action is taken in case content is not valid (e.g.: log WARN messages etc.). > Online Swagger Editor [2] was used to verify that non valid content was generated. > Also it should be evaluated whether to mention this behavior in community or product docs. > [1] > https://download.eclipse.org/microprofile/microprofile-open-api-1.1.2/mic... > [2] > https://editor.swagger.io/ -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-291) Log messages from io.smallrye.openapi don't have message ID

by Fabio Burzigotti (Jira)

Fabio Burzigotti created WFWIP-291: -------------------------------------- Summary: Log messages from io.smallrye.openapi don't have message ID Key: WFWIP-291 URL: https://issues.redhat.com/browse/WFWIP-291 Project: WildFly WIP Issue Type: Bug Components: MP OpenAPI Reporter: Fabio Burzigotti Assignee: Paul Ferraro Messages logged by io.smallrye.openapi don't have assigned ID: {code} 2020-01-05 16:58:49,225 DEBUG [io.smallrye.openapi.runtime.util.SchemaFactory] (MSC service thread 1-4) Processing a single @Schema annotation. 2020-01-05 16:58:49,225 DEBUG [io.smallrye.openapi.runtime.scanner.OpenApiAnnotationScanner] (MSC service thread 1-4) Processing a single @Response annotation. 2020-01-05 16:58:49,225 DEBUG [io.smallrye.openapi.runtime.scanner.OpenApiAnnotationScanner] (MSC service thread 1-4) Processing jax-rs method: {0} 2020-01-05 16:58:49,225 DEBUG [io.smallrye.openapi.runtime.scanner.OpenApiDataObjectScanner] (MSC service thread 1-4) Starting processing with root: java.lang.String {code} A search in SmallRye implementation seems to show that IDs are not used even when level is WARN: {code} $ find . -name '*.*' -type f -print0 | xargs -0 grep --color -n -e 'LOG.warn' ./implementation/src/main/java/io/smallrye/openapi/runtime/scanner/ParameterProcessor.java:551: LOG.warnf("Matrix parameter references missing path segment: %s", segmentName); ./implementation/src/main/java/io/smallrye/openapi/runtime/scanner/ParameterProcessor.java:1147: LOG.warnf("Value '%s' is not a valid %s default", stringValue, primitive.name().toLowerCase()); {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12835) HealthChecks in subdeployments are not registered

by Ivan Straka (Jira)

[ https://issues.redhat.com/browse/WFLY-12835?page=com.atlassian.jira.plugi... ] Ivan Straka updated WFLY-12835: ------------------------------- Priority: Critical (was: Major) > HealthChecks in subdeployments are not registered > ------------------------------------------------- > > Key: WFLY-12835 > URL: https://issues.redhat.com/browse/WFLY-12835 > Project: WildFly > Issue Type: Feature Request > Components: MP Health > Affects Versions: 18.0.1.Final > Reporter: Ivan Straka > Assignee: Jeff Mesnil > Priority: Critical > > After EAR is deployed HealthChecks are not registered and not exposed under _/health_ endpoint. > EAR contains one WAR and one JAR. Both of them contains HealthChecks. > Test source: https://github.com/istraka/eap-microprofile-test-suite/blob/mp-health/mic... -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12835) HealthChecks in subdeployments are not registered

by Ivan Straka (Jira)

[ https://issues.redhat.com/browse/WFLY-12835?page=com.atlassian.jira.plugi... ] Ivan Straka updated WFLY-12835: ------------------------------- Issue Type: Feature Request (was: Bug) Priority: Major (was: Blocker) > HealthChecks in subdeployments are not registered > ------------------------------------------------- > > Key: WFLY-12835 > URL: https://issues.redhat.com/browse/WFLY-12835 > Project: WildFly > Issue Type: Feature Request > Components: MP Health > Affects Versions: 18.0.1.Final > Reporter: Ivan Straka > Assignee: Jeff Mesnil > Priority: Major > > After EAR is deployed HealthChecks are not registered and not exposed under _/health_ endpoint. > EAR contains one WAR and one JAR. Both of them contains HealthChecks. > Test source: https://github.com/istraka/eap-microprofile-test-suite/blob/mp-health/mic... -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12925) MP FT retry.callsSucceededRetried.total metric has wrong value

by Ivan Straka (Jira)

[ https://issues.redhat.com/browse/WFLY-12925?page=com.atlassian.jira.plugi... ] Ivan Straka updated WFLY-12925: ------------------------------- Steps to Reproduce: build WildFly clone git@github.com:istraka/eap-microprofile-test-suite.git branch mp-ft-metrics-reproducer run the Reproducers#retryCallsSucceededCounter test: {code:bash} mvn clean verify -pl tooling-server-configuration,microprofile-health -Djboss.home=_path_to_wf_ -DfailIfNoTests=false -Dtest=Reproducers#retryCallsSucceededCounter {code} was: build WildFly clone git@github.com:istraka/eap-microprofile-test-suite.git branch mp-ft-metrics-reproducer run the Reproducers#fallbackCounter test: {code:bash} mvn clean verify -pl tooling-server-configuration,microprofile-health -Djboss.home=_path_to_wf_ -DfailIfNoTests=false -Dtest=Reproducers#retryCallsSucceededCounter {code} > MP FT retry.callsSucceededRetried.total metric has wrong value > -------------------------------------------------------------- > > Key: WFLY-12925 > URL: https://issues.redhat.com/browse/WFLY-12925 > Project: WildFly > Issue Type: Bug > Components: MP Fault Tolerance > Affects Versions: 19.0.0.Beta1 > Reporter: Ivan Straka > Assignee: Radoslav Husar > Priority: Blocker > > When method annotated with @Fallback and @Retry fails, MP FT retry.callsSucceededRetried.total metric even though the method fails everytime and falls into a fallback method. > The issue is only in the metric. The method is retried as expected and fallback method is invoked only once as expected. > *Reproducer:* > https://github.com/istraka/eap-microprofile-test-suite/blob/mp-ft-metrics... > *CDI Bean:* > {code:java} > @Fallback(fallbackMethod = "isReadyFallback") > @Retry(maxRetries = MAX_RETRIES) > public boolean isReady() throws IOException { > service.simulateOpeningResources(); > return ready.get(); > } > public boolean isReadyFallback() { > return readyInMainenance.get(); > } > @Counted(name = "simulation-count", absolute = true, displayName = "Simulation Count", description = "Number of simulateOpeningResources invocations", reusable = true) > public void simulateOpeningResources() throws IOException { > if (inMaintanance.get()) { > throw new IOException("In maintanance"); > } > } > {code} > https://github.com/istraka/eap-microprofile-test-suite/blob/mp-ft-metrics... > *Smallrye issue* > https://github.com/smallrye/smallrye-fault-tolerance/issues/159 -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12925) MP FT retry.callsSucceededRetried.total metric has wrong value

by Ivan Straka (Jira)

[ https://issues.redhat.com/browse/WFLY-12925?page=com.atlassian.jira.plugi... ] Ivan Straka updated WFLY-12925: ------------------------------- Steps to Reproduce: build WildFly clone git@github.com:istraka/eap-microprofile-test-suite.git branch mp-ft-metrics-reproducer run the Reproducers#fallbackCounter test: {code:bash} mvn clean verify -pl tooling-server-configuration,microprofile-health -Djboss.home=_path_to_wf_ -DfailIfNoTests=false -Dtest=Reproducers#retryCallsSucceededCounter {code} > MP FT retry.callsSucceededRetried.total metric has wrong value > -------------------------------------------------------------- > > Key: WFLY-12925 > URL: https://issues.redhat.com/browse/WFLY-12925 > Project: WildFly > Issue Type: Bug > Components: MP Fault Tolerance > Affects Versions: 19.0.0.Beta1 > Reporter: Ivan Straka > Assignee: Radoslav Husar > Priority: Blocker > > When method annotated with @Fallback and @Retry fails, MP FT retry.callsSucceededRetried.total metric even though the method fails everytime and falls into a fallback method. > The issue is only in the metric. The method is retried as expected and fallback method is invoked only once as expected. > *Reproducer:* > https://github.com/istraka/eap-microprofile-test-suite/blob/mp-ft-metrics... > *CDI Bean:* > {code:java} > @Fallback(fallbackMethod = "isReadyFallback") > @Retry(maxRetries = MAX_RETRIES) > public boolean isReady() throws IOException { > service.simulateOpeningResources(); > return ready.get(); > } > public boolean isReadyFallback() { > return readyInMainenance.get(); > } > @Counted(name = "simulation-count", absolute = true, displayName = "Simulation Count", description = "Number of simulateOpeningResources invocations", reusable = true) > public void simulateOpeningResources() throws IOException { > if (inMaintanance.get()) { > throw new IOException("In maintanance"); > } > } > {code} > https://github.com/istraka/eap-microprofile-test-suite/blob/mp-ft-metrics... > *Smallrye issue* > https://github.com/smallrye/smallrye-fault-tolerance/issues/159 -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12925) MP FT retry.callsSucceededRetried.total metric has wrong value

by Ivan Straka (Jira)

[ https://issues.redhat.com/browse/WFLY-12925?page=com.atlassian.jira.plugi... ] Ivan Straka updated WFLY-12925: ------------------------------- Priority: Major (was: Blocker) > MP FT retry.callsSucceededRetried.total metric has wrong value > -------------------------------------------------------------- > > Key: WFLY-12925 > URL: https://issues.redhat.com/browse/WFLY-12925 > Project: WildFly > Issue Type: Bug > Components: MP Fault Tolerance > Affects Versions: 19.0.0.Beta1 > Reporter: Ivan Straka > Assignee: Radoslav Husar > Priority: Major > > When method annotated with @Fallback and @Retry fails, MP FT retry.callsSucceededRetried.total metric even though the method fails everytime and falls into a fallback method. > The issue is only in the metric. The method is retried as expected and fallback method is invoked only once as expected. > *Reproducer:* > https://github.com/istraka/eap-microprofile-test-suite/blob/mp-ft-metrics... > *CDI Bean:* > {code:java} > @Fallback(fallbackMethod = "isReadyFallback") > @Retry(maxRetries = MAX_RETRIES) > public boolean isReady() throws IOException { > service.simulateOpeningResources(); > return ready.get(); > } > public boolean isReadyFallback() { > return readyInMainenance.get(); > } > @Counted(name = "simulation-count", absolute = true, displayName = "Simulation Count", description = "Number of simulateOpeningResources invocations", reusable = true) > public void simulateOpeningResources() throws IOException { > if (inMaintanance.get()) { > throw new IOException("In maintanance"); > } > } > {code} > https://github.com/istraka/eap-microprofile-test-suite/blob/mp-ft-metrics... > *Smallrye issue* > https://github.com/smallrye/smallrye-fault-tolerance/issues/159 -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12924) MP FT fallback metric is incremented wrongly

by Ivan Straka (Jira)

[ https://issues.redhat.com/browse/WFLY-12924?page=com.atlassian.jira.plugi... ] Ivan Straka updated WFLY-12924: ------------------------------- Priority: Major (was: Blocker) > MP FT fallback metric is incremented wrongly > -------------------------------------------- > > Key: WFLY-12924 > URL: https://issues.redhat.com/browse/WFLY-12924 > Project: WildFly > Issue Type: Bug > Components: MP Fault Tolerance > Affects Versions: 19.0.0.Beta1 > Reporter: Ivan Straka > Assignee: Radoslav Husar > Priority: Major > > When method annotated with @Fallback and @Retry fails, MP FT fallback counter metric (fallback.calls.total) is incremented by 2. Meaning if the method fails N times (due to @Retry) fallback is invoked and the metric is 2. > The issue is only in the metric. Fallback method is invoked only once as expected. > *Reproducer:* > https://github.com/istraka/eap-microprofile-test-suite/blob/mp-ft-metrics... > *CDI Bean:* > {code:java} > @Fallback(fallbackMethod = "isReadyFallback") > @Retry(maxRetries = MAX_RETRIES) > public boolean isReady() throws IOException { > service.simulateOpeningResources(); > return ready.get(); > } > public boolean isReadyFallback() { > return readyInMainenance.get(); > } > @Counted(name = "simulation-count", absolute = true, displayName = "Simulation Count", description = "Number of simulateOpeningResources invocations", reusable = true) > public void simulateOpeningResources() throws IOException { > if (inMaintanance.get()) { > throw new IOException("In maintanance"); > } > } > {code} > https://github.com/istraka/eap-microprofile-test-suite/blob/mp-ft-metrics... > *Smallrye issue* > https://github.com/smallrye/smallrye-fault-tolerance/issues/158 -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12925) MP FT retry.callsSucceededRetried.total metric has wrong value

by Ivan Straka (Jira)

Ivan Straka created WFLY-12925: ---------------------------------- Summary: MP FT retry.callsSucceededRetried.total metric has wrong value Key: WFLY-12925 URL: https://issues.redhat.com/browse/WFLY-12925 Project: WildFly Issue Type: Bug Components: MP Fault Tolerance Affects Versions: 19.0.0.Beta1 Reporter: Ivan Straka Assignee: Radoslav Husar When method annotated with @Fallback and @Retry fails, MP FT retry.callsSucceededRetried.total metric even though the method fails everytime and falls into a fallback method. The issue is only in the metric. The method is retried as expected and fallback method is invoked only once as expected. *Reproducer:* https://github.com/istraka/eap-microprofile-test-suite/blob/mp-ft-metrics... *CDI Bean:* {code:java} @Fallback(fallbackMethod = "isReadyFallback") @Retry(maxRetries = MAX_RETRIES) public boolean isReady() throws IOException { service.simulateOpeningResources(); return ready.get(); } public boolean isReadyFallback() { return readyInMainenance.get(); } @Counted(name = "simulation-count", absolute = true, displayName = "Simulation Count", description = "Number of simulateOpeningResources invocations", reusable = true) public void simulateOpeningResources() throws IOException { if (inMaintanance.get()) { throw new IOException("In maintanance"); } } {code} https://github.com/istraka/eap-microprofile-test-suite/blob/mp-ft-metrics... *Smallrye issue* https://github.com/smallrye/smallrye-fault-tolerance/issues/159 -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12924) MP FT fallback metric is incremented wrongly

by Ivan Straka (Jira)

[ https://issues.redhat.com/browse/WFLY-12924?page=com.atlassian.jira.plugi... ] Ivan Straka updated WFLY-12924: ------------------------------- Description: When method annotated with @Fallback and @Retry fails, MP FT fallback counter metric (fallback.calls.total) is incremented by 2. Meaning if the method fails N times (due to @Retry) fallback is invoked and the metric is 2. The issue is only in the metric. Fallback method is invoked only once as expected. *Reproducer:* https://github.com/istraka/eap-microprofile-test-suite/blob/mp-ft-metrics... *CDI Bean:* {code:java} @Fallback(fallbackMethod = "isReadyFallback") @Retry(maxRetries = MAX_RETRIES) public boolean isReady() throws IOException { service.simulateOpeningResources(); return ready.get(); } public boolean isReadyFallback() { return readyInMainenance.get(); } @Counted(name = "simulation-count", absolute = true, displayName = "Simulation Count", description = "Number of simulateOpeningResources invocations", reusable = true) public void simulateOpeningResources() throws IOException { if (inMaintanance.get()) { throw new IOException("In maintanance"); } } {code} https://github.com/istraka/eap-microprofile-test-suite/blob/mp-ft-metrics... *Smallrye issue* https://github.com/smallrye/smallrye-fault-tolerance/issues/158 was: When method annotated with @Fallback and @Retry fails, MP FT fallback counter metric (fallback.calls.total) is incremented by 2. Meaning if the method fails N times (due to @Retry) fallback is invoked and the metric is 2. The issue is only in the metric. Fallback method is invoked only once as expected. Reproducer: https://github.com/istraka/eap-microprofile-test-suite/blob/mp-ft-metrics... CDI Bean: {code:java} @Fallback(fallbackMethod = "isReadyFallback") @Retry(maxRetries = MAX_RETRIES) public boolean isReady() throws IOException { service.simulateOpeningResources(); return ready.get(); } public boolean isReadyFallback() { return readyInMainenance.get(); } @Counted(name = "simulation-count", absolute = true, displayName = "Simulation Count", description = "Number of simulateOpeningResources invocations", reusable = true) public void simulateOpeningResources() throws IOException { if (inMaintanance.get()) { throw new IOException("In maintanance"); } } {code} https://github.com/istraka/eap-microprofile-test-suite/blob/mp-ft-metrics... > MP FT fallback metric is incremented wrongly > -------------------------------------------- > > Key: WFLY-12924 > URL: https://issues.redhat.com/browse/WFLY-12924 > Project: WildFly > Issue Type: Bug > Components: MP Fault Tolerance > Affects Versions: 19.0.0.Beta1 > Reporter: Ivan Straka > Assignee: Radoslav Husar > Priority: Blocker > > When method annotated with @Fallback and @Retry fails, MP FT fallback counter metric (fallback.calls.total) is incremented by 2. Meaning if the method fails N times (due to @Retry) fallback is invoked and the metric is 2. > The issue is only in the metric. Fallback method is invoked only once as expected. > *Reproducer:* > https://github.com/istraka/eap-microprofile-test-suite/blob/mp-ft-metrics... > *CDI Bean:* > {code:java} > @Fallback(fallbackMethod = "isReadyFallback") > @Retry(maxRetries = MAX_RETRIES) > public boolean isReady() throws IOException { > service.simulateOpeningResources(); > return ready.get(); > } > public boolean isReadyFallback() { > return readyInMainenance.get(); > } > @Counted(name = "simulation-count", absolute = true, displayName = "Simulation Count", description = "Number of simulateOpeningResources invocations", reusable = true) > public void simulateOpeningResources() throws IOException { > if (inMaintanance.get()) { > throw new IOException("In maintanance"); > } > } > {code} > https://github.com/istraka/eap-microprofile-test-suite/blob/mp-ft-metrics... > *Smallrye issue* > https://github.com/smallrye/smallrye-fault-tolerance/issues/158 -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12924) MP FT fallback metric is incremented wrongly

by Ivan Straka (Jira)

[ https://issues.redhat.com/browse/WFLY-12924?page=com.atlassian.jira.plugi... ] Ivan Straka updated WFLY-12924: ------------------------------- Description: When method annotated with @Fallback and @Retry fails, MP FT fallback counter metric (fallback.calls.total) is incremented by 2. Meaning if the method fails N times (due to @Retry) fallback is invoked and the metric is 2. The issue is only in the metric. Fallback method is invoked only once as expected. Reproducer: https://github.com/istraka/eap-microprofile-test-suite/blob/mp-ft-metrics... CDI Bean: {code:java} @Fallback(fallbackMethod = "isReadyFallback") @Retry(maxRetries = MAX_RETRIES) public boolean isReady() throws IOException { service.simulateOpeningResources(); return ready.get(); } public boolean isReadyFallback() { return readyInMainenance.get(); } @Counted(name = "simulation-count", absolute = true, displayName = "Simulation Count", description = "Number of simulateOpeningResources invocations", reusable = true) public void simulateOpeningResources() throws IOException { if (inMaintanance.get()) { throw new IOException("In maintanance"); } } {code} https://github.com/istraka/eap-microprofile-test-suite/blob/mp-ft-metrics... was: When method annotated with @Fallback and @Retry fails, MP FT fallback counter metric (fallback.calls.total) is incremented by 2. Meaning if the method fails N times (due to @Retry) fallback is invoked and the metric is 2. The issue is only in the metric. Fallback method is invoked only once as expected. Reproducer: https://github.com/istraka/eap-microprofile-test-suite/blob/mp-ft-metrics... CDI Bean: https://github.com/istraka/eap-microprofile-test-suite/blob/mp-ft-metrics... > MP FT fallback metric is incremented wrongly > -------------------------------------------- > > Key: WFLY-12924 > URL: https://issues.redhat.com/browse/WFLY-12924 > Project: WildFly > Issue Type: Bug > Components: MP Fault Tolerance > Affects Versions: 19.0.0.Beta1 > Reporter: Ivan Straka > Assignee: Radoslav Husar > Priority: Blocker > > When method annotated with @Fallback and @Retry fails, MP FT fallback counter metric (fallback.calls.total) is incremented by 2. Meaning if the method fails N times (due to @Retry) fallback is invoked and the metric is 2. > The issue is only in the metric. Fallback method is invoked only once as expected. > Reproducer: > https://github.com/istraka/eap-microprofile-test-suite/blob/mp-ft-metrics... > CDI Bean: > {code:java} > @Fallback(fallbackMethod = "isReadyFallback") > @Retry(maxRetries = MAX_RETRIES) > public boolean isReady() throws IOException { > service.simulateOpeningResources(); > return ready.get(); > } > public boolean isReadyFallback() { > return readyInMainenance.get(); > } > @Counted(name = "simulation-count", absolute = true, displayName = "Simulation Count", description = "Number of simulateOpeningResources invocations", reusable = true) > public void simulateOpeningResources() throws IOException { > if (inMaintanance.get()) { > throw new IOException("In maintanance"); > } > } > {code} > https://github.com/istraka/eap-microprofile-test-suite/blob/mp-ft-metrics... -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12924) MP FT fallback metric is incremented wrongly

by Ivan Straka (Jira)

[ https://issues.redhat.com/browse/WFLY-12924?page=com.atlassian.jira.plugi... ] Ivan Straka updated WFLY-12924: ------------------------------- Description: When method annotated with @Fallback and @Retry fails, MP FT fallback counter metric (fallback.calls.total) is incremented by 2. Meaning if the method fails N times (due to @Retry) fallback is invoked and the metric is 2. The issue is only in the metric. Fallback method is invoked only once as expected. Reproducer: https://github.com/istraka/eap-microprofile-test-suite/blob/mp-ft-metrics... CDI Bean: https://github.com/istraka/eap-microprofile-test-suite/blob/mp-ft-metrics... was: When method annotated with @Fallback and @Retry fails, MP FT fallback counter metric (fallback.calls.total) is incremented by 2. Meaning if the method fails N times (due to @Retry) fallback is invoked and the metric is 2. The issue is only in the metric. Fallback method is invoked only once as expected. > MP FT fallback metric is incremented wrongly > -------------------------------------------- > > Key: WFLY-12924 > URL: https://issues.redhat.com/browse/WFLY-12924 > Project: WildFly > Issue Type: Bug > Components: MP Fault Tolerance > Affects Versions: 19.0.0.Beta1 > Reporter: Ivan Straka > Assignee: Radoslav Husar > Priority: Blocker > > When method annotated with @Fallback and @Retry fails, MP FT fallback counter metric (fallback.calls.total) is incremented by 2. Meaning if the method fails N times (due to @Retry) fallback is invoked and the metric is 2. > The issue is only in the metric. Fallback method is invoked only once as expected. > Reproducer: > https://github.com/istraka/eap-microprofile-test-suite/blob/mp-ft-metrics... > CDI Bean: > https://github.com/istraka/eap-microprofile-test-suite/blob/mp-ft-metrics... -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12924) MP FT fallback metric is incremented wrongly

by Ivan Straka (Jira)

Ivan Straka created WFLY-12924: ---------------------------------- Summary: MP FT fallback metric is incremented wrongly Key: WFLY-12924 URL: https://issues.redhat.com/browse/WFLY-12924 Project: WildFly Issue Type: Bug Components: MP Fault Tolerance Affects Versions: 19.0.0.Beta1 Reporter: Ivan Straka Assignee: Radoslav Husar When method annotated with @Fallback and @Retry fails, MP FT fallback counter metric (fallback.calls.total) is incremented by 2. Meaning if the method fails N times (due to @Retry) fallback is invoked and the metric is 2. The issue is only in the metric. Fallback method is invoked only once as expected. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12924) MP FT fallback metric is incremented wrongly

by Ivan Straka (Jira)

[ https://issues.redhat.com/browse/WFLY-12924?page=com.atlassian.jira.plugi... ] Ivan Straka updated WFLY-12924: ------------------------------- Steps to Reproduce: build WildFly clone git@github.com:istraka/eap-microprofile-test-suite.git branch mp-ft-metrics-reproducer run the test: {code:bash} mvn clean verify -pl tooling-server-configuration,microprofile-health -Djboss.home=_path_to_wf_ -DfailIfNoTests=false -Dtest=Reproducers#fallbackCounter {code} was: build WildFly clone git@github.com:istraka/eap-microprofile-test-suite.git branch mp-ft-metrics-reproducer run the test: mvn clean verify -pl tooling-server-configuration,microprofile-health -Djboss.home=_path_to_wf_ -DfailIfNoTests=false -Dtest=Reproducers#fallbackCounter > MP FT fallback metric is incremented wrongly > -------------------------------------------- > > Key: WFLY-12924 > URL: https://issues.redhat.com/browse/WFLY-12924 > Project: WildFly > Issue Type: Bug > Components: MP Fault Tolerance > Affects Versions: 19.0.0.Beta1 > Reporter: Ivan Straka > Assignee: Radoslav Husar > Priority: Blocker > > When method annotated with @Fallback and @Retry fails, MP FT fallback counter metric (fallback.calls.total) is incremented by 2. Meaning if the method fails N times (due to @Retry) fallback is invoked and the metric is 2. > The issue is only in the metric. Fallback method is invoked only once as expected. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12924) MP FT fallback metric is incremented wrongly

by Ivan Straka (Jira)

[ https://issues.redhat.com/browse/WFLY-12924?page=com.atlassian.jira.plugi... ] Ivan Straka updated WFLY-12924: ------------------------------- Steps to Reproduce: build WildFly clone git@github.com:istraka/eap-microprofile-test-suite.git branch mp-ft-metrics-reproducer run the Reproducers#fallbackCounter test: {code:bash} mvn clean verify -pl tooling-server-configuration,microprofile-health -Djboss.home=_path_to_wf_ -DfailIfNoTests=false -Dtest=Reproducers#fallbackCounter {code} was: build WildFly clone git@github.com:istraka/eap-microprofile-test-suite.git branch mp-ft-metrics-reproducer run the test: {code:bash} mvn clean verify -pl tooling-server-configuration,microprofile-health -Djboss.home=_path_to_wf_ -DfailIfNoTests=false -Dtest=Reproducers#fallbackCounter {code} > MP FT fallback metric is incremented wrongly > -------------------------------------------- > > Key: WFLY-12924 > URL: https://issues.redhat.com/browse/WFLY-12924 > Project: WildFly > Issue Type: Bug > Components: MP Fault Tolerance > Affects Versions: 19.0.0.Beta1 > Reporter: Ivan Straka > Assignee: Radoslav Husar > Priority: Blocker > > When method annotated with @Fallback and @Retry fails, MP FT fallback counter metric (fallback.calls.total) is incremented by 2. Meaning if the method fails N times (due to @Retry) fallback is invoked and the metric is 2. > The issue is only in the metric. Fallback method is invoked only once as expected. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12921) Upgrade to SmallRye Config 2.1.4

by Radoslav Husar (Jira)

[ https://issues.redhat.com/browse/WFLY-12921?page=com.atlassian.jira.plugi... ] Radoslav Husar commented on WFLY-12921: --------------------------------------- Thanks for the upgrade and getting them to release. Hopefully this makes Miroslav happy ;-) > Upgrade to SmallRye Config 2.1.4 > -------------------------------- > > Key: WFLY-12921 > URL: https://issues.redhat.com/browse/WFLY-12921 > Project: WildFly > Issue Type: Component Upgrade > Components: MP Fault Tolerance > Reporter: Kabir Khan > Assignee: Kabir Khan > Priority: Major > Fix For: 19.0.0.Beta1 > > > Needed to resolve some niggles in the integration -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12921) Upgrade to SmallRye Config 2.1.4

by Radoslav Husar (Jira)

[ https://issues.redhat.com/browse/WFLY-12921?page=com.atlassian.jira.plugi... ] Radoslav Husar commented on WFLY-12921: --------------------------------------- Just to note, this is not about integration but it was a SR FT implementation spec violation, i.e. https://github.com/smallrye/smallrye-fault-tolerance/issues/150. > Upgrade to SmallRye Config 2.1.4 > -------------------------------- > > Key: WFLY-12921 > URL: https://issues.redhat.com/browse/WFLY-12921 > Project: WildFly > Issue Type: Component Upgrade > Components: MP Fault Tolerance > Reporter: Kabir Khan > Assignee: Kabir Khan > Priority: Major > Fix For: 19.0.0.Beta1 > > > Needed to resolve some niggles in the integration -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4784) Upgrade Undertow to 2.0.29.Final

by Flavia Rainone (Jira)

Flavia Rainone created WFCORE-4784: -------------------------------------- Summary: Upgrade Undertow to 2.0.29.Final Key: WFCORE-4784 URL: https://issues.redhat.com/browse/WFCORE-4784 Project: WildFly Core Issue Type: Component Upgrade Reporter: Flavia Rainone Assignee: Flavia Rainone Upgrade Undertow to 2.0.29.Final -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12898) Multiversion Testing for wildfly images

by Panagiotis Sotiropoulos (Jira)

[ https://issues.redhat.com/browse/WFLY-12898?page=com.atlassian.jira.plugi... ] Panagiotis Sotiropoulos updated WFLY-12898: ------------------------------------------- Comment: was deleted (was: To be also done : Linking of containers ...) > Multiversion Testing for wildfly images > ---------------------------------------- > > Key: WFLY-12898 > URL: https://issues.redhat.com/browse/WFLY-12898 > Project: WildFly > Issue Type: Task > Components: Test Suite > Reporter: Panagiotis Sotiropoulos > Assignee: Panagiotis Sotiropoulos > Priority: Major > > Multiversion Testing for wildfly images with EAT -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12898) Multiversion Testing for wildfly images

by Panagiotis Sotiropoulos (Jira)

[ https://issues.redhat.com/browse/WFLY-12898?page=com.atlassian.jira.plugi... ] Panagiotis Sotiropoulos commented on WFLY-12898: ------------------------------------------------ To be also done : Linking of containers ... > Multiversion Testing for wildfly images > ---------------------------------------- > > Key: WFLY-12898 > URL: https://issues.redhat.com/browse/WFLY-12898 > Project: WildFly > Issue Type: Task > Components: Test Suite > Reporter: Panagiotis Sotiropoulos > Assignee: Panagiotis Sotiropoulos > Priority: Major > > Multiversion Testing for wildfly images with EAT -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12898) Multiversion Testing for wildfly images

by Panagiotis Sotiropoulos (Jira)

[ https://issues.redhat.com/browse/WFLY-12898?page=com.atlassian.jira.plugi... ] Panagiotis Sotiropoulos commented on WFLY-12898: ------------------------------------------------ To be also done : Linking of containers ... > Multiversion Testing for wildfly images > ---------------------------------------- > > Key: WFLY-12898 > URL: https://issues.redhat.com/browse/WFLY-12898 > Project: WildFly > Issue Type: Task > Components: Test Suite > Reporter: Panagiotis Sotiropoulos > Assignee: Panagiotis Sotiropoulos > Priority: Major > > Multiversion Testing for wildfly images with EAT -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4901) [DMN Designer] Data Types - Drag and Drop - Error when a single structure data type is dragged twice

by Guilherme Gomes (Jira)

Guilherme Gomes created DROOLS-4901: --------------------------------------- Summary: [DMN Designer] Data Types - Drag and Drop - Error when a single structure data type is dragged twice Key: DROOLS-4901 URL: https://issues.redhat.com/browse/DROOLS-4901 Project: Drools Issue Type: Task Components: DMN Editor Reporter: Guilherme Gomes Assignee: Guilherme Gomes Attachments: 2020-01-03 16.48.12.gif Error when a single structure data type is dragged twice. See the steps to reproduce: !2020-01-03 16.48.12.gif|width=300! -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3510) Decision table unable to generate rule for row with pattern without constraint

by Mario Fusco (Jira)

[ https://issues.redhat.com/browse/DROOLS-3510?page=com.atlassian.jira.plug... ] Mario Fusco commented on DROOLS-3510: ------------------------------------- I reproduced the problem with the 'MissingConstraint.xls' decision table that I attached (the original provided one was malformed). This dtable generates the following drl {code} package rule_table; //generated from Decision Table // rule values at B6, header at B1 rule "Test_6" when $factA: FactA(hasSomething == "true") $numberOfFactsB: Number(this > 0, this <= 1) from accumulate(FactB(x == 1) from $factA.listOfFactsB,count(1)) then insert(X); end // rule values at B7, header at B1 rule "Test_7" when $factA: FactA(hasSomething == "true") $numberOfFactsB: Number(this > 1, this <= 2) from accumulate(FactB(x == 1) from $factA.listOfFactsB,count(1)) then insert(X); end // rule values at B8, header at B1 rule "Test_8" when $numberOfFactsB: Number(this > 2, this <= 3) from accumulate(FactB(x == 1) from $factA.listOfFactsB,count(1)) then insert(Y); end {code} I understand that in the 3rd rule it should add pattern FactA() with no constraint while at the moment is totally skipping it. I need to double check if this change could break any backward compatibility. > Decision table unable to generate rule for row with pattern without constraint > ------------------------------------------------------------------------------ > > Key: DROOLS-3510 > URL: https://issues.redhat.com/browse/DROOLS-3510 > Project: Drools > Issue Type: Bug > Components: decision tables > Affects Versions: 7.15.0.Final > Reporter: Andre Piwoni > Assignee: Mario Fusco > Priority: Minor > Attachments: MissingConstraint.xls, failingDecisionTable.xlsx > > > When second condition refers to a field of a variable bound in first condition and there exists row/rule without condition constraint than decision table compiler fails to generate rules. See attachment. > Expected rules to be generated: > {code:java} > rule "Test_1" > when > $factA:FactA(hasSomething == "true") > $numberOfFactsB: Number(this > 0, this <= 1) from accumulate(FactB(x == 1) from $factA.listOfFactsB,count(1)) > then > insert(X); > end > rule "Test_2" > when > $factA:FactA(hasSomething == "true") > $numberOfFactsB: Number(this > 1, this <= 2) from accumulate(FactB(x == 1) from $factA.listOfFactsB,count(1)) > then > insert(X); > end > rule "Test_3" > when > $factA:FactA() > $numberOfFactsB: Number(this > 2, this <= 3) from accumulate(FactB(x == 1) from $factA.listOfFactsB,count(1)) > then > insert(Y); > end > {code} > Also, there does not seem an alternative way to generate following rule using decision table: > {code:java} > rule "Test" > when > $factA:FactA($factsB: listOfFactsB) > $numberOfFactsB: Number(this > 1) from accumulate(FactB(x == 1) from $factsB,count(1)) > then > insert(Y); > end > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3510) Decision table unable to generate rule for row with pattern without constraint

by Mario Fusco (Jira)

[ https://issues.redhat.com/browse/DROOLS-3510?page=com.atlassian.jira.plug... ] Mario Fusco updated DROOLS-3510: -------------------------------- Attachment: MissingConstraint.xls > Decision table unable to generate rule for row with pattern without constraint > ------------------------------------------------------------------------------ > > Key: DROOLS-3510 > URL: https://issues.redhat.com/browse/DROOLS-3510 > Project: Drools > Issue Type: Bug > Components: decision tables > Affects Versions: 7.15.0.Final > Reporter: Andre Piwoni > Assignee: Mario Fusco > Priority: Minor > Attachments: MissingConstraint.xls, failingDecisionTable.xlsx > > > When second condition refers to a field of a variable bound in first condition and there exists row/rule without condition constraint than decision table compiler fails to generate rules. See attachment. > Expected rules to be generated: > {code:java} > rule "Test_1" > when > $factA:FactA(hasSomething == "true") > $numberOfFactsB: Number(this > 0, this <= 1) from accumulate(FactB(x == 1) from $factA.listOfFactsB,count(1)) > then > insert(X); > end > rule "Test_2" > when > $factA:FactA(hasSomething == "true") > $numberOfFactsB: Number(this > 1, this <= 2) from accumulate(FactB(x == 1) from $factA.listOfFactsB,count(1)) > then > insert(X); > end > rule "Test_3" > when > $factA:FactA() > $numberOfFactsB: Number(this > 2, this <= 3) from accumulate(FactB(x == 1) from $factA.listOfFactsB,count(1)) > then > insert(Y); > end > {code} > Also, there does not seem an alternative way to generate following rule using decision table: > {code:java} > rule "Test" > when > $factA:FactA($factsB: listOfFactsB) > $numberOfFactsB: Number(this > 1) from accumulate(FactB(x == 1) from $factsB,count(1)) > then > insert(Y); > end > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3510) Decision table unable to generate rule for row with pattern without constraint

by Mario Fusco (Jira)

[ https://issues.redhat.com/browse/DROOLS-3510?page=com.atlassian.jira.plug... ] Mario Fusco updated DROOLS-3510: -------------------------------- Sprint: 2020 Week 01-03 (from Dec 30) > Decision table unable to generate rule for row with pattern without constraint > ------------------------------------------------------------------------------ > > Key: DROOLS-3510 > URL: https://issues.redhat.com/browse/DROOLS-3510 > Project: Drools > Issue Type: Bug > Components: decision tables > Affects Versions: 7.15.0.Final > Reporter: Andre Piwoni > Assignee: Mario Fusco > Priority: Minor > Attachments: failingDecisionTable.xlsx > > > When second condition refers to a field of a variable bound in first condition and there exists row/rule without condition constraint than decision table compiler fails to generate rules. See attachment. > Expected rules to be generated: > {code:java} > rule "Test_1" > when > $factA:FactA(hasSomething == "true") > $numberOfFactsB: Number(this > 0, this <= 1) from accumulate(FactB(x == 1) from $factA.listOfFactsB,count(1)) > then > insert(X); > end > rule "Test_2" > when > $factA:FactA(hasSomething == "true") > $numberOfFactsB: Number(this > 1, this <= 2) from accumulate(FactB(x == 1) from $factA.listOfFactsB,count(1)) > then > insert(X); > end > rule "Test_3" > when > $factA:FactA() > $numberOfFactsB: Number(this > 2, this <= 3) from accumulate(FactB(x == 1) from $factA.listOfFactsB,count(1)) > then > insert(Y); > end > {code} > Also, there does not seem an alternative way to generate following rule using decision table: > {code:java} > rule "Test" > when > $factA:FactA($factsB: listOfFactsB) > $numberOfFactsB: Number(this > 1) from accumulate(FactB(x == 1) from $factsB,count(1)) > then > insert(Y); > end > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (LOGTOOL-144) Make JBoss logging annotations accessible at runtime

by James Perkins (Jira)

[ https://issues.redhat.com/browse/LOGTOOL-144?page=com.atlassian.jira.plug... ] James Perkins commented on LOGTOOL-144: --------------------------------------- We use the bytecode to generate our pages with all the messages for Wildscribe, https://wildscribe.github.io/WildFly/18.0/log-message-reference.html. I definitely have concerns with the extra metaspace that is likely required. This could be a problem for cloud environments where memory is a concern. > Make JBoss logging annotations accessible at runtime > ---------------------------------------------------- > > Key: LOGTOOL-144 > URL: https://issues.redhat.com/browse/LOGTOOL-144 > Project: Log Tool > Issue Type: Enhancement > Reporter: Francois JACQUES > Priority: Major > > Hi, > We have a use case where we are creating a Java proxy to access meta information of a logger. In this scenario we need to access the `@Message` and `@MessageLogger` annotations at runtime. This is not possible as there retention policy is set to `@Retention(CLASS)`. > Do you see any problem/value into changing the retention policy to runtime for all annotations in JBoss logging ? > Thanks -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3531) template example nullpointexception when execute maven install command in kjar project

by Mario Fusco (Jira)

[ https://issues.redhat.com/browse/DROOLS-3531?page=com.atlassian.jira.plug... ] Mario Fusco resolved DROOLS-3531. --------------------------------- Resolution: Out of Date I tested it with latest release and it works for me. I attached to the ticket a zip file with the maven project with which I tried. > template example nullpointexception when execute maven install command in kjar project > -------------------------------------------------------------------------------------- > > Key: DROOLS-3531 > URL: https://issues.redhat.com/browse/DROOLS-3531 > Project: Drools > Issue Type: Bug > Components: decision tables > Affects Versions: 7.16.0.Final > Reporter: canyu canyu > Assignee: Mario Fusco > Priority: Major > Attachments: template.zip > > > drools-template example changes packaging tag with kjar in pom.xml, adding maven-compiler-plugin. When executes maven install command(-X install), outputs following exception: > [INFO] ------------------------------------------------------------------------ > [INFO] BUILD FAILURE > [INFO] ------------------------------------------------------------------------ > [INFO] Total time: 24.247 s > [INFO] Finished at: 2019-01-18T17:28:50+08:00 > [INFO] ------------------------------------------------------------------------ > [ERROR] Failed to execute goal org.kie:kie-maven-plugin:7.16.0.Final:build (default-build) on project drools-rule-mer: Execution default-build of goal org.kie:kie-maven-plugin:7.16.0.Final:build failed.: NullPointerException -> [Help 1] > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.kie:kie-maven-plugin:7.16.0.Final:build (default-build) on project drools-rule-mer: Execution default-build of goal org.kie:kie-maven-plugin:7.16.0.Final:build failed. > at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:215) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:156) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:148) > at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117) > at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81) > at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:56) > at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128) > at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305) > at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192) > at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105) > at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956) > at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288) > at org.apache.maven.cli.MavenCli.main (MavenCli.java:192) > 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.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:289) > at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:229) > at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:415) > at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:356) > at org.codehaus.classworlds.Launcher.main (Launcher.java:47) > Caused by: org.apache.maven.plugin.PluginExecutionException: Execution default-build of goal org.kie:kie-maven-plugin:7.16.0.Final:build failed. > at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:148) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:210) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:156) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:148) > at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117) > at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81) > at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:56) > at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128) > at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305) > at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192) > at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105) > at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956) > at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288) > at org.apache.maven.cli.MavenCli.main (MavenCli.java:192) > 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.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:289) > at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:229) > at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:415) > at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:356) > at org.codehaus.classworlds.Launcher.main (Launcher.java:47) > Caused by: java.lang.NullPointerException > at org.drools.decisiontable.parser.DefaultRuleSheetListener.flushRule (DefaultRuleSheetListener.java:304) > at org.drools.decisiontable.parser.DefaultRuleSheetListener.finishSheet (DefaultRuleSheetListener.java:284) > at org.drools.decisiontable.parser.xls.ExcelParser.finishSheet (ExcelParser.java:285) > at org.drools.decisiontable.parser.xls.ExcelParser.processSheet (ExcelParser.java:220) > at org.drools.decisiontable.parser.xls.ExcelParser.parseWorkbook (ExcelParser.java:111) > at org.drools.decisiontable.parser.xls.ExcelParser.parseFile (ExcelParser.java:85) > at org.drools.decisiontable.SpreadsheetCompiler.parseResource (SpreadsheetCompiler.java:126) > at org.drools.decisiontable.SpreadsheetCompiler.compile (SpreadsheetCompiler.java:110) > at org.drools.decisiontable.SpreadsheetCompiler.compile (SpreadsheetCompiler.java:83) > at org.drools.decisiontable.DecisionTableProviderImpl.compileResource (DecisionTableProviderImpl.java:78) > at org.drools.decisiontable.DecisionTableProviderImpl.loadFromResource (DecisionTableProviderImpl.java:44) > at org.drools.compiler.compiler.DecisionTableFactory.loadFromResource (DecisionTableFactory.java:36) > at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.decisionTableToPackageDescr (KnowledgeBuilderImpl.java:399) > at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl$ResourceToPkgDescrMapper.lambda$static$4 (CompositeKnowledgeBuilderImpl.java:327) > at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.buildResource (CompositeKnowledgeBuilderImpl.java:199) > at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.buildPackageDescr (CompositeKnowledgeBuilderImpl.java:186) > at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.build (CompositeKnowledgeBuilderImpl.java:108) > at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.build (CompositeKnowledgeBuilderImpl.java:100) > at org.drools.compiler.kie.builder.impl.AbstractKieProject.buildKnowledgePackages (AbstractKieProject.java:251) > at org.drools.compiler.kie.builder.impl.AbstractKieProject.verify (AbstractKieProject.java:74) > at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildKieProject (KieBuilderImpl.java:267) > at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildAll (KieBuilderImpl.java:235) > at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildAll (KieBuilderImpl.java:184) > at org.drools.compiler.kie.builder.impl.KieBuilderImpl.getKieModule (KieBuilderImpl.java:438) > at org.drools.compiler.kie.builder.impl.KieBuilderImpl.getKieModule (KieBuilderImpl.java:428) > at org.kie.maven.plugin.BuildMojo.buildDrl (BuildMojo.java:169) > at org.kie.maven.plugin.BuildMojo.execute (BuildMojo.java:118) > at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:137) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:210) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:156) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:148) > at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117) > at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81) > at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:56) > at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128) > at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305) > at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192) > at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105) > at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956) > at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288) > at org.apache.maven.cli.MavenCli.main (MavenCli.java:192) > 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.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:289) > at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:229) > at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:415) > at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:356) > at org.codehaus.classworlds.Launcher.main (Launcher.java:47) -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3531) template example nullpointexception when execute maven install command in kjar project

by Mario Fusco (Jira)

[ https://issues.redhat.com/browse/DROOLS-3531?page=com.atlassian.jira.plug... ] Mario Fusco updated DROOLS-3531: -------------------------------- Sprint: 2020 Week 01-03 (from Dec 30) > template example nullpointexception when execute maven install command in kjar project > -------------------------------------------------------------------------------------- > > Key: DROOLS-3531 > URL: https://issues.redhat.com/browse/DROOLS-3531 > Project: Drools > Issue Type: Bug > Components: decision tables > Affects Versions: 7.16.0.Final > Reporter: canyu canyu > Assignee: Mario Fusco > Priority: Major > Attachments: template.zip > > > drools-template example changes packaging tag with kjar in pom.xml, adding maven-compiler-plugin. When executes maven install command(-X install), outputs following exception: > [INFO] ------------------------------------------------------------------------ > [INFO] BUILD FAILURE > [INFO] ------------------------------------------------------------------------ > [INFO] Total time: 24.247 s > [INFO] Finished at: 2019-01-18T17:28:50+08:00 > [INFO] ------------------------------------------------------------------------ > [ERROR] Failed to execute goal org.kie:kie-maven-plugin:7.16.0.Final:build (default-build) on project drools-rule-mer: Execution default-build of goal org.kie:kie-maven-plugin:7.16.0.Final:build failed.: NullPointerException -> [Help 1] > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.kie:kie-maven-plugin:7.16.0.Final:build (default-build) on project drools-rule-mer: Execution default-build of goal org.kie:kie-maven-plugin:7.16.0.Final:build failed. > at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:215) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:156) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:148) > at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117) > at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81) > at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:56) > at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128) > at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305) > at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192) > at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105) > at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956) > at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288) > at org.apache.maven.cli.MavenCli.main (MavenCli.java:192) > 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.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:289) > at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:229) > at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:415) > at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:356) > at org.codehaus.classworlds.Launcher.main (Launcher.java:47) > Caused by: org.apache.maven.plugin.PluginExecutionException: Execution default-build of goal org.kie:kie-maven-plugin:7.16.0.Final:build failed. > at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:148) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:210) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:156) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:148) > at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117) > at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81) > at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:56) > at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128) > at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305) > at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192) > at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105) > at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956) > at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288) > at org.apache.maven.cli.MavenCli.main (MavenCli.java:192) > 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.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:289) > at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:229) > at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:415) > at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:356) > at org.codehaus.classworlds.Launcher.main (Launcher.java:47) > Caused by: java.lang.NullPointerException > at org.drools.decisiontable.parser.DefaultRuleSheetListener.flushRule (DefaultRuleSheetListener.java:304) > at org.drools.decisiontable.parser.DefaultRuleSheetListener.finishSheet (DefaultRuleSheetListener.java:284) > at org.drools.decisiontable.parser.xls.ExcelParser.finishSheet (ExcelParser.java:285) > at org.drools.decisiontable.parser.xls.ExcelParser.processSheet (ExcelParser.java:220) > at org.drools.decisiontable.parser.xls.ExcelParser.parseWorkbook (ExcelParser.java:111) > at org.drools.decisiontable.parser.xls.ExcelParser.parseFile (ExcelParser.java:85) > at org.drools.decisiontable.SpreadsheetCompiler.parseResource (SpreadsheetCompiler.java:126) > at org.drools.decisiontable.SpreadsheetCompiler.compile (SpreadsheetCompiler.java:110) > at org.drools.decisiontable.SpreadsheetCompiler.compile (SpreadsheetCompiler.java:83) > at org.drools.decisiontable.DecisionTableProviderImpl.compileResource (DecisionTableProviderImpl.java:78) > at org.drools.decisiontable.DecisionTableProviderImpl.loadFromResource (DecisionTableProviderImpl.java:44) > at org.drools.compiler.compiler.DecisionTableFactory.loadFromResource (DecisionTableFactory.java:36) > at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.decisionTableToPackageDescr (KnowledgeBuilderImpl.java:399) > at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl$ResourceToPkgDescrMapper.lambda$static$4 (CompositeKnowledgeBuilderImpl.java:327) > at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.buildResource (CompositeKnowledgeBuilderImpl.java:199) > at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.buildPackageDescr (CompositeKnowledgeBuilderImpl.java:186) > at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.build (CompositeKnowledgeBuilderImpl.java:108) > at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.build (CompositeKnowledgeBuilderImpl.java:100) > at org.drools.compiler.kie.builder.impl.AbstractKieProject.buildKnowledgePackages (AbstractKieProject.java:251) > at org.drools.compiler.kie.builder.impl.AbstractKieProject.verify (AbstractKieProject.java:74) > at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildKieProject (KieBuilderImpl.java:267) > at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildAll (KieBuilderImpl.java:235) > at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildAll (KieBuilderImpl.java:184) > at org.drools.compiler.kie.builder.impl.KieBuilderImpl.getKieModule (KieBuilderImpl.java:438) > at org.drools.compiler.kie.builder.impl.KieBuilderImpl.getKieModule (KieBuilderImpl.java:428) > at org.kie.maven.plugin.BuildMojo.buildDrl (BuildMojo.java:169) > at org.kie.maven.plugin.BuildMojo.execute (BuildMojo.java:118) > at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:137) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:210) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:156) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:148) > at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117) > at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81) > at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:56) > at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128) > at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305) > at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192) > at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105) > at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956) > at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288) > at org.apache.maven.cli.MavenCli.main (MavenCli.java:192) > 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.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:289) > at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:229) > at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:415) > at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:356) > at org.codehaus.classworlds.Launcher.main (Launcher.java:47) -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3531) template example nullpointexception when execute maven install command in kjar project

by Mario Fusco (Jira)

[ https://issues.redhat.com/browse/DROOLS-3531?page=com.atlassian.jira.plug... ] Mario Fusco updated DROOLS-3531: -------------------------------- Attachment: template.zip > template example nullpointexception when execute maven install command in kjar project > -------------------------------------------------------------------------------------- > > Key: DROOLS-3531 > URL: https://issues.redhat.com/browse/DROOLS-3531 > Project: Drools > Issue Type: Bug > Components: decision tables > Affects Versions: 7.16.0.Final > Reporter: canyu canyu > Assignee: Mario Fusco > Priority: Major > Attachments: template.zip > > > drools-template example changes packaging tag with kjar in pom.xml, adding maven-compiler-plugin. When executes maven install command(-X install), outputs following exception: > [INFO] ------------------------------------------------------------------------ > [INFO] BUILD FAILURE > [INFO] ------------------------------------------------------------------------ > [INFO] Total time: 24.247 s > [INFO] Finished at: 2019-01-18T17:28:50+08:00 > [INFO] ------------------------------------------------------------------------ > [ERROR] Failed to execute goal org.kie:kie-maven-plugin:7.16.0.Final:build (default-build) on project drools-rule-mer: Execution default-build of goal org.kie:kie-maven-plugin:7.16.0.Final:build failed.: NullPointerException -> [Help 1] > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.kie:kie-maven-plugin:7.16.0.Final:build (default-build) on project drools-rule-mer: Execution default-build of goal org.kie:kie-maven-plugin:7.16.0.Final:build failed. > at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:215) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:156) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:148) > at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117) > at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81) > at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:56) > at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128) > at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305) > at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192) > at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105) > at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956) > at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288) > at org.apache.maven.cli.MavenCli.main (MavenCli.java:192) > 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.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:289) > at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:229) > at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:415) > at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:356) > at org.codehaus.classworlds.Launcher.main (Launcher.java:47) > Caused by: org.apache.maven.plugin.PluginExecutionException: Execution default-build of goal org.kie:kie-maven-plugin:7.16.0.Final:build failed. > at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:148) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:210) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:156) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:148) > at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117) > at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81) > at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:56) > at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128) > at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305) > at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192) > at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105) > at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956) > at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288) > at org.apache.maven.cli.MavenCli.main (MavenCli.java:192) > 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.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:289) > at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:229) > at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:415) > at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:356) > at org.codehaus.classworlds.Launcher.main (Launcher.java:47) > Caused by: java.lang.NullPointerException > at org.drools.decisiontable.parser.DefaultRuleSheetListener.flushRule (DefaultRuleSheetListener.java:304) > at org.drools.decisiontable.parser.DefaultRuleSheetListener.finishSheet (DefaultRuleSheetListener.java:284) > at org.drools.decisiontable.parser.xls.ExcelParser.finishSheet (ExcelParser.java:285) > at org.drools.decisiontable.parser.xls.ExcelParser.processSheet (ExcelParser.java:220) > at org.drools.decisiontable.parser.xls.ExcelParser.parseWorkbook (ExcelParser.java:111) > at org.drools.decisiontable.parser.xls.ExcelParser.parseFile (ExcelParser.java:85) > at org.drools.decisiontable.SpreadsheetCompiler.parseResource (SpreadsheetCompiler.java:126) > at org.drools.decisiontable.SpreadsheetCompiler.compile (SpreadsheetCompiler.java:110) > at org.drools.decisiontable.SpreadsheetCompiler.compile (SpreadsheetCompiler.java:83) > at org.drools.decisiontable.DecisionTableProviderImpl.compileResource (DecisionTableProviderImpl.java:78) > at org.drools.decisiontable.DecisionTableProviderImpl.loadFromResource (DecisionTableProviderImpl.java:44) > at org.drools.compiler.compiler.DecisionTableFactory.loadFromResource (DecisionTableFactory.java:36) > at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.decisionTableToPackageDescr (KnowledgeBuilderImpl.java:399) > at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl$ResourceToPkgDescrMapper.lambda$static$4 (CompositeKnowledgeBuilderImpl.java:327) > at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.buildResource (CompositeKnowledgeBuilderImpl.java:199) > at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.buildPackageDescr (CompositeKnowledgeBuilderImpl.java:186) > at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.build (CompositeKnowledgeBuilderImpl.java:108) > at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.build (CompositeKnowledgeBuilderImpl.java:100) > at org.drools.compiler.kie.builder.impl.AbstractKieProject.buildKnowledgePackages (AbstractKieProject.java:251) > at org.drools.compiler.kie.builder.impl.AbstractKieProject.verify (AbstractKieProject.java:74) > at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildKieProject (KieBuilderImpl.java:267) > at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildAll (KieBuilderImpl.java:235) > at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildAll (KieBuilderImpl.java:184) > at org.drools.compiler.kie.builder.impl.KieBuilderImpl.getKieModule (KieBuilderImpl.java:438) > at org.drools.compiler.kie.builder.impl.KieBuilderImpl.getKieModule (KieBuilderImpl.java:428) > at org.kie.maven.plugin.BuildMojo.buildDrl (BuildMojo.java:169) > at org.kie.maven.plugin.BuildMojo.execute (BuildMojo.java:118) > at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:137) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:210) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:156) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:148) > at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117) > at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81) > at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:56) > at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128) > at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305) > at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192) > at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105) > at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956) > at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288) > at org.apache.maven.cli.MavenCli.main (MavenCli.java:192) > 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.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:289) > at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:229) > at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:415) > at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:356) > at org.codehaus.classworlds.Launcher.main (Launcher.java:47) -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (LOGTOOL-144) Make JBoss logging annotations accessible at runtime

by Francois JACQUES (Jira)

[ https://issues.redhat.com/browse/LOGTOOL-144?page=com.atlassian.jira.plug... ] Francois JACQUES commented on LOGTOOL-144: ------------------------------------------ In our specific use case we are looking for the generated message code : prefix-padding-code. Indeed, the information, while still being in the class file, is not read and stored in the JVM memory. Now it's still possible to read this information using a bytecode reader at runtime. But it seems more fragile and overkill for the use case. > Make JBoss logging annotations accessible at runtime > ---------------------------------------------------- > > Key: LOGTOOL-144 > URL: https://issues.redhat.com/browse/LOGTOOL-144 > Project: Log Tool > Issue Type: Enhancement > Reporter: Francois JACQUES > Priority: Major > > Hi, > We have a use case where we are creating a Java proxy to access meta information of a logger. In this scenario we need to access the `@Message` and `@MessageLogger` annotations at runtime. This is not possible as there retention policy is set to `@Retention(CLASS)`. > Do you see any problem/value into changing the retention policy to runtime for all annotations in JBoss logging ? > Thanks -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (LOGTOOL-144) Make JBoss logging annotations accessible at runtime

by James Perkins (Jira)

[ https://issues.redhat.com/browse/LOGTOOL-144?page=com.atlassian.jira.plug... ] James Perkins commented on LOGTOOL-144: --------------------------------------- What is the meta information you're looking for? There is overhead with having the retention policy of runtime as the JVM needs to store that information. While I haven't measured the difference I assume this adds to metaspace since it needs to retain the annotation and all the information associated with it. > Make JBoss logging annotations accessible at runtime > ---------------------------------------------------- > > Key: LOGTOOL-144 > URL: https://issues.redhat.com/browse/LOGTOOL-144 > Project: Log Tool > Issue Type: Enhancement > Reporter: Francois JACQUES > Priority: Major > > Hi, > We have a use case where we are creating a Java proxy to access meta information of a logger. In this scenario we need to access the `@Message` and `@MessageLogger` annotations at runtime. This is not possible as there retention policy is set to `@Retention(CLASS)`. > Do you see any problem/value into changing the retention policy to runtime for all annotations in JBoss logging ? > Thanks -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4386) Wrong matched rules set were fired when one of the condition having empty cell in drools 6.5.0 using Jdk 1.8

by Mario Fusco (Jira)

[ https://issues.redhat.com/browse/DROOLS-4386?page=com.atlassian.jira.plug... ] Mario Fusco resolved DROOLS-4386. --------------------------------- Resolution: Explained The provided decision table gets internally translated in the following drl {code} package rule_table; //generated from Decision Table import com.model.Customer; // rule values at A9, header at A4 rule "Individual = 5y" when $customer:Customer($customer.getType() in (INDIVIDUAL), $customer.getYears() >= (5)) then $customer.setDiscount(15); end // rule values at A10, header at A4 rule "Individual = 3y" when $customer:Customer($customer.getType() in (INDIVIDUAL), $customer.getYears() >= (3)) then $customer.setDiscount(10); end // rule values at A11, header at A4 rule "Individual = 0y" when $customer:Customer($customer.getType() in (INDIVIDUAL)) then $customer.setDiscount(20); end {code} As you can see in the 3rd rule it correctly generates only one constraint since the other is missing. Given this rule set there's no reason why the 3rd rule shouldn't fire as you described and I believe that drools always worked this way. What more likely is changed is that before it fired the rules in a different order, i.e. in drools 5.x it fired the 3rd rule first and then one of the other 2 so you got the correct result "by chance" and never realized this problem. > Wrong matched rules set were fired when one of the condition having empty cell in drools 6.5.0 using Jdk 1.8 > ------------------------------------------------------------------------------------------------------------ > > Key: DROOLS-4386 > URL: https://issues.redhat.com/browse/DROOLS-4386 > Project: Drools > Issue Type: Bug > Components: decision tables > Affects Versions: 6.5.0.Final > Environment: Windows, Java 1.8 and drools 6.5.0.Final > Reporter: Rahul Ramachar > Assignee: Mario Fusco > Priority: Major > Attachments: Discount.xls > > > In JDK 1.7 we were using Drools 5.3.0.Final version and we are migrating to jdk 1.8 so drools 5.3.0.Final was not supported in which we were using Package Builder. > We migrated JDK 1.8 with drools 6.5.0.Final which uses Kie API to implement rules > Below is the decision table I am using: > Customer Rule: > Condition Condition Action > --------------------------------------------------- > Rule NO. Type Years Discount > --------------------------------------------------- > 1 "Individual" 5 15 > 2 "Individual" 3 10 > 3 "Individual" 20 > if I insert customer object as "Type" = Individual and "Years" = 5 > after fireAllRules > It fires two rules i.e Rule no. 1 and 3 and gives the 3rd Rule number as result instead of Rule number 1, inturn gives Discount as 20 instead of 15 which is wrong result. > if I insert customer object as "Type" = Individual and "Years" = 3 > after fireAllRules > It fires two rules i.e Rule no. 2 and 3 and gives the 3rd rule number as result instead of Rule number 2, inturn gives Discount as 20 instead of 10 which is wrong result. > Exact rule match is not happening and providing wrong results. > Could you please give the solution for this it is breaking so many rules in the application. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4386) Wrong matched rules set were fired when one of the condition having empty cell in drools 6.5.0 using Jdk 1.8

by Mario Fusco (Jira)

[ https://issues.redhat.com/browse/DROOLS-4386?page=com.atlassian.jira.plug... ] Mario Fusco updated DROOLS-4386: -------------------------------- Sprint: 2020 Week 01-03 (from Dec 30) > Wrong matched rules set were fired when one of the condition having empty cell in drools 6.5.0 using Jdk 1.8 > ------------------------------------------------------------------------------------------------------------ > > Key: DROOLS-4386 > URL: https://issues.redhat.com/browse/DROOLS-4386 > Project: Drools > Issue Type: Bug > Components: decision tables > Affects Versions: 6.5.0.Final > Environment: Windows, Java 1.8 and drools 6.5.0.Final > Reporter: Rahul Ramachar > Assignee: Mario Fusco > Priority: Major > Attachments: Discount.xls > > > In JDK 1.7 we were using Drools 5.3.0.Final version and we are migrating to jdk 1.8 so drools 5.3.0.Final was not supported in which we were using Package Builder. > We migrated JDK 1.8 with drools 6.5.0.Final which uses Kie API to implement rules > Below is the decision table I am using: > Customer Rule: > Condition Condition Action > --------------------------------------------------- > Rule NO. Type Years Discount > --------------------------------------------------- > 1 "Individual" 5 15 > 2 "Individual" 3 10 > 3 "Individual" 20 > if I insert customer object as "Type" = Individual and "Years" = 5 > after fireAllRules > It fires two rules i.e Rule no. 1 and 3 and gives the 3rd Rule number as result instead of Rule number 1, inturn gives Discount as 20 instead of 15 which is wrong result. > if I insert customer object as "Type" = Individual and "Years" = 3 > after fireAllRules > It fires two rules i.e Rule no. 2 and 3 and gives the 3rd rule number as result instead of Rule number 2, inturn gives Discount as 20 instead of 10 which is wrong result. > Exact rule match is not happening and providing wrong results. > Could you please give the solution for this it is breaking so many rules in the application. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4899) DMN demo extended builtin function for runtime

by Matteo Mortari (Jira)

[ https://issues.redhat.com/browse/DROOLS-4899?page=com.atlassian.jira.plug... ] Matteo Mortari updated DROOLS-4899: ----------------------------------- Summary: DMN demo extended builtin function for runtime (was: DMN extended builtin function for runtime) > DMN demo extended builtin function for runtime > ---------------------------------------------- > > Key: DROOLS-4899 > URL: https://issues.redhat.com/browse/DROOLS-4899 > Project: Drools > Issue Type: Task > Components: dmn engine > Reporter: Matteo Mortari > Assignee: Matteo Mortari > Priority: Major > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4899) DMN extended builtin function for runtime

by Matteo Mortari (Jira)

[ https://issues.redhat.com/browse/DROOLS-4899?page=com.atlassian.jira.plug... ] Matteo Mortari updated DROOLS-4899: ----------------------------------- Issue Type: Task (was: Feature Request) > DMN extended builtin function for runtime > ----------------------------------------- > > Key: DROOLS-4899 > URL: https://issues.redhat.com/browse/DROOLS-4899 > Project: Drools > Issue Type: Task > Components: dmn engine > Reporter: Matteo Mortari > Assignee: Matteo Mortari > Priority: Major > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12923) EjbJaccConfigurator has unused methodIdentifier after WFLY-12794 changes

by Rostislav Svoboda (Jira)

Rostislav Svoboda created WFLY-12923: ---------------------------------------- Summary: EjbJaccConfigurator has unused methodIdentifier after WFLY-12794 changes Key: WFLY-12923 URL: https://issues.redhat.com/browse/WFLY-12923 Project: WildFly Issue Type: Bug Components: EJB Reporter: Rostislav Svoboda Assignee: Rostislav Svoboda EjbJaccConfigurator has unused {{methodIdentifier}} and few unnecessary {{MethodIdentifier.getIdentifierForMethod}} calls after WFLY-12794 changes. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12826) Switch to GAV-based locations for feature-pack dependencies

by Oleksiy Lubyanskyy (Jira)

[ https://issues.redhat.com/browse/WFLY-12826?page=com.atlassian.jira.plugi... ] Oleksiy Lubyanskyy updated WFLY-12826: -------------------------------------- Description: Currently feature-pack dependencies are using FPL format to point to the dependency feature-packs. Galleon 4.2.1.Final and WFGP 4.2.2.Final support generation of the feature-pack dependency locations in GAV format. As a consequence, provisioning in offline mode does not require all the transitive feature-pack configs in the provision goal configuration. > Switch to GAV-based locations for feature-pack dependencies > ----------------------------------------------------------- > > Key: WFLY-12826 > URL: https://issues.redhat.com/browse/WFLY-12826 > Project: WildFly > Issue Type: Component Upgrade > Components: Build System > Reporter: Jean Francois Denise > Assignee: Oleksiy Lubyanskyy > Priority: Major > > Currently feature-pack dependencies are using FPL format to point to the dependency feature-packs. Galleon 4.2.1.Final and WFGP 4.2.2.Final support generation of the feature-pack dependency locations in GAV format. As a consequence, provisioning in offline mode does not require all the transitive feature-pack configs in the provision goal configuration. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12826) Switch to GAV-based locations for feature-pack dependencies

by Oleksiy Lubyanskyy (Jira)

[ https://issues.redhat.com/browse/WFLY-12826?page=com.atlassian.jira.plugi... ] Oleksiy Lubyanskyy updated WFLY-12826: -------------------------------------- Summary: Switch to GAV-based locations for feature-pack dependencies (was: Upgrade galleon to 4.2.1.Final, galleon-plugins to 4.2.2.Final) > Switch to GAV-based locations for feature-pack dependencies > ----------------------------------------------------------- > > Key: WFLY-12826 > URL: https://issues.redhat.com/browse/WFLY-12826 > Project: WildFly > Issue Type: Component Upgrade > Components: Build System > Reporter: Jean Francois Denise > Assignee: Oleksiy Lubyanskyy > Priority: Major > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12922) server scale down keeps data in client's data/ejb-xa-recovery and transactions on client aren't commited

by Ondrej Chaloupka (Jira)

[ https://issues.redhat.com/browse/WFLY-12922?page=com.atlassian.jira.plugi... ] Ondrej Chaloupka updated WFLY-12922: ------------------------------------ Affects Version/s: 18.0.0.Final > server scale down keeps data in client's data/ejb-xa-recovery and transactions on client aren't commited > -------------------------------------------------------------------------------------------------------- > > Key: WFLY-12922 > URL: https://issues.redhat.com/browse/WFLY-12922 > Project: WildFly > Issue Type: Bug > Components: EJB, Transactions > Affects Versions: 18.0.0.Final > Reporter: Martin Simka > Assignee: Ondrej Chaloupka > Priority: Major > Fix For: 19.0.0.Beta1 > > > this follows up on WFWIP-206 > While testing tx recovery in OpenShift I see that scale down of pod that has transaction in-doubt on it isn't successful > Scenario: > *ejb client* (app tx-client, pod tx-client-0): > * EJB business method > ** lookup remote EJB > ** enlist XA resource 1 to transaction > ** enlist XA resource 2 to transaction > ** call remote EJB > *ejb server* (app tx-server, pod tx-server-0): > * EJB business method > ** enlist XA resource 1 to transaction > ** enlist XA resource 2 to transaction > *testTxStatelessServerSecondCommitThrowRmFail* > ejb server XA resource 2 fails with {{XAException(XAException.XAER_RMFAIL)}} > Then the test calls scale down (size from 1 to 0) on tx-server pod. Server scale down completes but sometimes there some records left in {{<JBOSS_HOME>/standalone/data/ejb-xa-recovery}} on tx-client and transactions on client aren't commited. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12922) server scale down keeps data in client's data/ejb-xa-recovery and transactions on client aren't commited

by Ondrej Chaloupka (Jira)

[ https://issues.redhat.com/browse/WFLY-12922?page=com.atlassian.jira.plugi... ] Ondrej Chaloupka resolved WFLY-12922. ------------------------------------- Resolution: Done Caused by WFTC-77, resolved by component upgrade WFLY-12910 > server scale down keeps data in client's data/ejb-xa-recovery and transactions on client aren't commited > -------------------------------------------------------------------------------------------------------- > > Key: WFLY-12922 > URL: https://issues.redhat.com/browse/WFLY-12922 > Project: WildFly > Issue Type: Bug > Components: EJB, Transactions > Affects Versions: 18.0.0.Final > Reporter: Martin Simka > Assignee: Ondrej Chaloupka > Priority: Major > Fix For: 19.0.0.Beta1 > > > this follows up on WFWIP-206 > While testing tx recovery in OpenShift I see that scale down of pod that has transaction in-doubt on it isn't successful > Scenario: > *ejb client* (app tx-client, pod tx-client-0): > * EJB business method > ** lookup remote EJB > ** enlist XA resource 1 to transaction > ** enlist XA resource 2 to transaction > ** call remote EJB > *ejb server* (app tx-server, pod tx-server-0): > * EJB business method > ** enlist XA resource 1 to transaction > ** enlist XA resource 2 to transaction > *testTxStatelessServerSecondCommitThrowRmFail* > ejb server XA resource 2 fails with {{XAException(XAException.XAER_RMFAIL)}} > Then the test calls scale down (size from 1 to 0) on tx-server pod. Server scale down completes but sometimes there some records left in {{<JBOSS_HOME>/standalone/data/ejb-xa-recovery}} on tx-client and transactions on client aren't commited. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12922) server scale down keeps data in client's data/ejb-xa-recovery and transactions on client aren't commited

by Ondrej Chaloupka (Jira)

[ https://issues.redhat.com/browse/WFLY-12922?page=com.atlassian.jira.plugi... ] Ondrej Chaloupka updated WFLY-12922: ------------------------------------ Fix Version/s: 19.0.0.Beta1 > server scale down keeps data in client's data/ejb-xa-recovery and transactions on client aren't commited > -------------------------------------------------------------------------------------------------------- > > Key: WFLY-12922 > URL: https://issues.redhat.com/browse/WFLY-12922 > Project: WildFly > Issue Type: Bug > Components: EJB, Transactions > Affects Versions: 18.0.0.Final > Reporter: Martin Simka > Assignee: Ondrej Chaloupka > Priority: Major > Fix For: 19.0.0.Beta1 > > > this follows up on WFWIP-206 > While testing tx recovery in OpenShift I see that scale down of pod that has transaction in-doubt on it isn't successful > Scenario: > *ejb client* (app tx-client, pod tx-client-0): > * EJB business method > ** lookup remote EJB > ** enlist XA resource 1 to transaction > ** enlist XA resource 2 to transaction > ** call remote EJB > *ejb server* (app tx-server, pod tx-server-0): > * EJB business method > ** enlist XA resource 1 to transaction > ** enlist XA resource 2 to transaction > *testTxStatelessServerSecondCommitThrowRmFail* > ejb server XA resource 2 fails with {{XAException(XAException.XAER_RMFAIL)}} > Then the test calls scale down (size from 1 to 0) on tx-server pod. Server scale down completes but sometimes there some records left in {{<JBOSS_HOME>/standalone/data/ejb-xa-recovery}} on tx-client and transactions on client aren't commited. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12922) server scale down keeps data in client's data/ejb-xa-recovery and transactions on client aren't commited

by Ondrej Chaloupka (Jira)

[ https://issues.redhat.com/browse/WFLY-12922?page=com.atlassian.jira.plugi... ] Ondrej Chaloupka moved WFWIP-218 to WFLY-12922: ----------------------------------------------- Project: WildFly (was: WildFly WIP) Key: WFLY-12922 (was: WFWIP-218) Component/s: EJB Transactions (was: OpenShift) > server scale down keeps data in client's data/ejb-xa-recovery and transactions on client aren't commited > -------------------------------------------------------------------------------------------------------- > > Key: WFLY-12922 > URL: https://issues.redhat.com/browse/WFLY-12922 > Project: WildFly > Issue Type: Bug > Components: EJB, Transactions > Reporter: Martin Simka > Assignee: Ondrej Chaloupka > Priority: Major > > this follows up on WFWIP-206 > While testing tx recovery in OpenShift I see that scale down of pod that has transaction in-doubt on it isn't successful > Scenario: > *ejb client* (app tx-client, pod tx-client-0): > * EJB business method > ** lookup remote EJB > ** enlist XA resource 1 to transaction > ** enlist XA resource 2 to transaction > ** call remote EJB > *ejb server* (app tx-server, pod tx-server-0): > * EJB business method > ** enlist XA resource 1 to transaction > ** enlist XA resource 2 to transaction > *testTxStatelessServerSecondCommitThrowRmFail* > ejb server XA resource 2 fails with {{XAException(XAException.XAER_RMFAIL)}} > Then the test calls scale down (size from 1 to 0) on tx-server pod. Server scale down completes but sometimes there some records left in {{<JBOSS_HOME>/standalone/data/ejb-xa-recovery}} on tx-client and transactions on client aren't commited. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-218) server scale down keeps data in client's data/ejb-xa-recovery and transactions on client aren't commited

by Ondrej Chaloupka (Jira)

[ https://issues.redhat.com/browse/WFWIP-218?page=com.atlassian.jira.plugin... ] Ondrej Chaloupka commented on WFWIP-218: ---------------------------------------- [~brian.stansberry] that's right. I'm moving this to WFLY. It sounds to me as the correct place. > server scale down keeps data in client's data/ejb-xa-recovery and transactions on client aren't commited > -------------------------------------------------------------------------------------------------------- > > Key: WFWIP-218 > URL: https://issues.redhat.com/browse/WFWIP-218 > Project: WildFly WIP > Issue Type: Bug > Components: OpenShift > Reporter: Martin Simka > Assignee: Ondrej Chaloupka > Priority: Major > > this follows up on WFWIP-206 > While testing tx recovery in OpenShift I see that scale down of pod that has transaction in-doubt on it isn't successful > Scenario: > *ejb client* (app tx-client, pod tx-client-0): > * EJB business method > ** lookup remote EJB > ** enlist XA resource 1 to transaction > ** enlist XA resource 2 to transaction > ** call remote EJB > *ejb server* (app tx-server, pod tx-server-0): > * EJB business method > ** enlist XA resource 1 to transaction > ** enlist XA resource 2 to transaction > *testTxStatelessServerSecondCommitThrowRmFail* > ejb server XA resource 2 fails with {{XAException(XAException.XAER_RMFAIL)}} > Then the test calls scale down (size from 1 to 0) on tx-server pod. Server scale down completes but sometimes there some records left in {{<JBOSS_HOME>/standalone/data/ejb-xa-recovery}} on tx-client and transactions on client aren't commited. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4884) When a variable is reassigned in a consequence the property reactivity for the correspondent fact should be ignored

by Mario Fusco (Jira)

[ https://issues.redhat.com/browse/DROOLS-4884?page=com.atlassian.jira.plug... ] Mario Fusco resolved DROOLS-4884. --------------------------------- Resolution: Done Fixed by https://github.com/kiegroup/drools/commit/0ad536175a8ad36628040cbec63431b... > When a variable is reassigned in a consequence the property reactivity for the correspondent fact should be ignored > ------------------------------------------------------------------------------------------------------------------- > > Key: DROOLS-4884 > URL: https://issues.redhat.com/browse/DROOLS-4884 > Project: Drools > Issue Type: Bug > Reporter: Mario Fusco > Assignee: Mario Fusco > Priority: Major > > When a variable is reassigned in a consequence (not a good practice in general) the property reactivity for the correspondent fact should be ignored. In other word the following test should succeed. > {code} > @Test > public void testReassignment() { > final String str1 = > "package com.example\n" + > "\n" + > "declare Counter\n" + > " value1: int\n" + > " value2: int\n" + > "end\n" + > "\n" + > "rule \"Init\" when\n" + > " not Counter()\n" + > "then\n" + > " drools.insert(new Counter(0, 0));\n" + > "end\n" + > "\n" + > "rule \"Loop\"\n" + > "when\n" + > " $c: Counter( value1 == 0 )\n" + > "then\n" + > " $c = new Counter(0, 0);\n" + > " $c.setValue2(1);\n" + > " update($c);\n" + > "end\n\n"; > final KieSession ksession = new KieHelper().addContent( str1, ResourceType.DRL ) > .build() > .newKieSession(); > assertEquals( 5, ksession.fireAllRules(5) ); > } > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2429) MsgStats num_bytes_sent should be incremented by the Message::size

by Diego Lovison (Jira)

[ https://issues.redhat.com/browse/JGRP-2429?page=com.atlassian.jira.plugin... ] Diego Lovison reassigned JGRP-2429: ----------------------------------- Assignee: Diego Lovison (was: Bela Ban) > MsgStats num_bytes_sent should be incremented by the Message::size > ------------------------------------------------------------------ > > Key: JGRP-2429 > URL: https://issues.redhat.com/browse/JGRP-2429 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.1.8 > Reporter: Diego Lovison > Assignee: Diego Lovison > Priority: Major > > MsgStats num_bytes_sent should be incremented by the Message::size > Today it is incremented by the Message:length that is the length of the payload, it doesn't include the headers. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2429) MsgStats num_bytes_sent should be incremented by the Message::size

by Diego Lovison (Jira)

Diego Lovison created JGRP-2429: ----------------------------------- Summary: MsgStats num_bytes_sent should be incremented by the Message::size Key: JGRP-2429 URL: https://issues.redhat.com/browse/JGRP-2429 Project: JGroups Issue Type: Bug Affects Versions: 4.1.8 Reporter: Diego Lovison Assignee: Bela Ban MsgStats num_bytes_sent should be incremented by the Message::size Today it is incremented by the Message:length that is the length of the payload, it doesn't include the headers. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12921) Upgrade to SmallRye Config 2.1.4

by Miroslav Novak (Jira)

[ https://issues.redhat.com/browse/WFLY-12921?page=com.atlassian.jira.plugi... ] Miroslav Novak commented on WFLY-12921: --------------------------------------- [~kabirkhan] I've attached the one directly related to 2.1.4 upgrade. > Upgrade to SmallRye Config 2.1.4 > -------------------------------- > > Key: WFLY-12921 > URL: https://issues.redhat.com/browse/WFLY-12921 > Project: WildFly > Issue Type: Component Upgrade > Components: MP Fault Tolerance > Reporter: Kabir Khan > Assignee: Kabir Khan > Priority: Major > > Needed to resolve some niggles in the integration -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4883) Test Scenario: create kie-docs content for Test Scenario Kie-server support

by Jozef Marko (Jira)

[ https://issues.redhat.com/browse/DROOLS-4883?page=com.atlassian.jira.plug... ] Jozef Marko updated DROOLS-4883: -------------------------------- Tester: Jozef Marko > Test Scenario: create kie-docs content for Test Scenario Kie-server support > --------------------------------------------------------------------------- > > Key: DROOLS-4883 > URL: https://issues.redhat.com/browse/DROOLS-4883 > Project: Drools > Issue Type: Task > Components: Scenario Simulation and Testing > Affects Versions: 7.32.0.Final > Reporter: Daniele Zonca > Assignee: Daniele Zonca > Priority: Major > Labels: drools-tools > > Document how to enable test-scenario capability in Kie-server and how to use it -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4883) Test Scenario: create kie-docs content for Test Scenario Kie-server support

by Jozef Marko (Jira)

[ https://issues.redhat.com/browse/DROOLS-4883?page=com.atlassian.jira.plug... ] Jozef Marko updated DROOLS-4883: -------------------------------- Affects Version/s: 7.32.0.Final > Test Scenario: create kie-docs content for Test Scenario Kie-server support > --------------------------------------------------------------------------- > > Key: DROOLS-4883 > URL: https://issues.redhat.com/browse/DROOLS-4883 > Project: Drools > Issue Type: Task > Components: Scenario Simulation and Testing > Affects Versions: 7.32.0.Final > Reporter: Daniele Zonca > Assignee: Daniele Zonca > Priority: Major > Labels: drools-tools > > Document how to enable test-scenario capability in Kie-server and how to use it -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-1042) Automate https://github.com/kiali/kiali/issues/1344

by Hayk Hovsepyan (Jira)

[ https://issues.redhat.com/browse/SWSQE-1042?page=com.atlassian.jira.plugi... ] Hayk Hovsepyan commented on SWSQE-1042: --------------------------------------- https://github.com/Kiali-QE/kiali-qe-python/pull/230 blocked because Maistra does not include latest istio with this objects yet. > Automate https://github.com/kiali/kiali/issues/1344 > --------------------------------------------------- > > Key: SWSQE-1042 > URL: https://issues.redhat.com/browse/SWSQE-1042 > Project: Kiali QE > Issue Type: QE Task > Reporter: Hayk Hovsepyan > Assignee: Hayk Hovsepyan > Priority: Major > Labels: automation > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-1041) Automate https://github.com/kiali/kiali/issues/1892

by Hayk Hovsepyan (Jira)

[ https://issues.redhat.com/browse/SWSQE-1041?page=com.atlassian.jira.plugi... ] Hayk Hovsepyan resolved SWSQE-1041. ----------------------------------- Resolution: Done > Automate https://github.com/kiali/kiali/issues/1892 > --------------------------------------------------- > > Key: SWSQE-1041 > URL: https://issues.redhat.com/browse/SWSQE-1041 > Project: Kiali QE > Issue Type: QE Task > Reporter: Hayk Hovsepyan > Assignee: Hayk Hovsepyan > Priority: Major > Labels: automation > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2428) Add message size to TP::down trace log

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2428?page=com.atlassian.jira.plugin... ] Bela Ban updated JGRP-2428: --------------------------- Fix Version/s: 4.1.9 > Add message size to TP::down trace log > -------------------------------------- > > Key: JGRP-2428 > URL: https://issues.redhat.com/browse/JGRP-2428 > Project: JGroups > Issue Type: Enhancement > Affects Versions: 4.1.8 > Reporter: Diego Lovison > Assignee: Diego Lovison > Priority: Minor > Fix For: 4.1.9 > > > Add message size to TP::down trace log > {code:java} > log.trace("%s: sending msg to %s, src=%s, size=%d, headers are %s", local_addr, dest, sender, msg.size(), msg.printHeaders()); > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2428) Add message size to TP::down trace log

by Diego Lovison (Jira)

[ https://issues.redhat.com/browse/JGRP-2428?page=com.atlassian.jira.plugin... ] Diego Lovison reassigned JGRP-2428: ----------------------------------- Assignee: Diego Lovison (was: Bela Ban) > Add message size to TP::down trace log > -------------------------------------- > > Key: JGRP-2428 > URL: https://issues.redhat.com/browse/JGRP-2428 > Project: JGroups > Issue Type: Enhancement > Affects Versions: 4.1.8 > Reporter: Diego Lovison > Assignee: Diego Lovison > Priority: Minor > > Add message size to TP::down trace log > {code:java} > log.trace("%s: sending msg to %s, src=%s, size=%d, headers are %s", local_addr, dest, sender, msg.size(), msg.printHeaders()); > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2428) Add message size to TP::down trace log

by Diego Lovison (Jira)

Diego Lovison created JGRP-2428: ----------------------------------- Summary: Add message size to TP::down trace log Key: JGRP-2428 URL: https://issues.redhat.com/browse/JGRP-2428 Project: JGroups Issue Type: Enhancement Affects Versions: 4.1.8 Reporter: Diego Lovison Assignee: Bela Ban Add message size to TP::down trace log {code:java} log.trace("%s: sending msg to %s, src=%s, size=%d, headers are %s", local_addr, dest, sender, msg.size(), msg.printHeaders()); {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4899) DMN extended builtin function for runtime

by Matteo Mortari (Jira)

Matteo Mortari created DROOLS-4899: -------------------------------------- Summary: DMN extended builtin function for runtime Key: DROOLS-4899 URL: https://issues.redhat.com/browse/DROOLS-4899 Project: Drools Issue Type: Feature Request Components: dmn engine Reporter: Matteo Mortari Assignee: Matteo Mortari -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4899) DMN extended builtin function for runtime

by Matteo Mortari (Jira)

[ https://issues.redhat.com/browse/DROOLS-4899?page=com.atlassian.jira.plug... ] Matteo Mortari updated DROOLS-4899: ----------------------------------- Sprint: 2020 Week 01-03 (from Dec 30) > DMN extended builtin function for runtime > ----------------------------------------- > > Key: DROOLS-4899 > URL: https://issues.redhat.com/browse/DROOLS-4899 > Project: Drools > Issue Type: Feature Request > Components: dmn engine > Reporter: Matteo Mortari > Assignee: Matteo Mortari > Priority: Major > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4618) Test Scenario: refactor ExpressionEvaluator implementations

by Jozef Marko (Jira)

[ https://issues.redhat.com/browse/DROOLS-4618?page=com.atlassian.jira.plug... ] Jozef Marko updated DROOLS-4618: -------------------------------- Tester: Jozef Marko (was: Anna Dupliak) > Test Scenario: refactor ExpressionEvaluator implementations > ----------------------------------------------------------- > > Key: DROOLS-4618 > URL: https://issues.redhat.com/browse/DROOLS-4618 > Project: Drools > Issue Type: Task > Components: Scenario Simulation and Testing > Reporter: Daniele Zonca > Assignee: Daniele Zonca > Priority: Minor > Labels: ScenarioSimulation, drools-tools > > Refactor ExpressionEvaluator implementations moving from Object to String for rawExpression (and move as much as possible logic to common class) > See https://github.com/kiegroup/drools/pull/2563#discussion_r331352927 -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12921) Upgrade to SmallRye Config 2.1.4

by Kabir Khan (Jira)

Kabir Khan created WFLY-12921: --------------------------------- Summary: Upgrade to SmallRye Config 2.1.4 Key: WFLY-12921 URL: https://issues.redhat.com/browse/WFLY-12921 Project: WildFly Issue Type: Component Upgrade Components: MP Fault Tolerance Reporter: Kabir Khan Assignee: Kabir Khan Needed to resolve some niggles in the integration -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4782) HttpManagementConstantHeadersTestCase doesn't do assertions on headerList.contains

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/WFCORE-4782?page=com.atlassian.jira.plug... ] Darran Lofthouse updated WFCORE-4782: ------------------------------------- Fix Version/s: 11.0.0.Beta6 > HttpManagementConstantHeadersTestCase doesn't do assertions on headerList.contains > ---------------------------------------------------------------------------------- > > Key: WFCORE-4782 > URL: https://issues.redhat.com/browse/WFCORE-4782 > Project: WildFly Core > Issue Type: Bug > Reporter: Rostislav Svoboda > Assignee: Rostislav Svoboda > Priority: Major > Fix For: 11.0.0.Beta6 > > > HttpManagementConstantHeadersTestCase doesn't do assertions on headerList.contains > It just does {{headerList.contains(new BasicHeader(TEST_HEADER, TEST_VALUE));}} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (LOGTOOL-144) Make JBoss logging annotations accessible at runtime

by Francois JACQUES (Jira)

Francois JACQUES created LOGTOOL-144: ---------------------------------------- Summary: Make JBoss logging annotations accessible at runtime Key: LOGTOOL-144 URL: https://issues.redhat.com/browse/LOGTOOL-144 Project: Log Tool Issue Type: Enhancement Reporter: Francois JACQUES Hi, We have a use case where we are creating a Java proxy to access meta information of a logger. In this scenario we need to access the `@Message` and `@MessageLogger` annotations at runtime. This is not possible as there retention policy is set to `@Retention(CLASS)`. Do you see any problem/value into changing the retention policy to runtime for all annotations in JBoss logging ? Thanks -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12913) Rationalize com.sum.xml.bind module dependencies

by Lin Gao (Jira)

[ https://issues.redhat.com/browse/WFLY-12913?page=com.atlassian.jira.plugi... ] Lin Gao reassigned WFLY-12913: ------------------------------ Assignee: Lin Gao > Rationalize com.sum.xml.bind module dependencies > ------------------------------------------------ > > Key: WFLY-12913 > URL: https://issues.redhat.com/browse/WFLY-12913 > Project: WildFly > Issue Type: Task > Components: JPA / Hibernate, REST, Web Services > Reporter: Brian Stansberry > Assignee: Lin Gao > Priority: Minor > > The com.sun.xml.bind module depends on and exports four other modules, and those modules in turn are private and have no other dependents: > {code} > <module name="com.github.relaxng" export="true" /> > <module name="com.sun.istack" export="true" /> > <module name="com.sun.xml.txw2" export="true" /> > <module name="com.sun.xsom" export="true" /> > {code} > Task is to: > 1) Write to wildfly-dev mail list to check for any projects that layer on WildFly that directly use these modules. > 2) Write to jboss-layered-products (internal Red Hat) mail list to check for any products based on WF/EAP that directly use these modules. > 3) Assuming no positive responses, make the artifacts from the above four modules direct artifacts of the com.sun.xml.bind module, add any needed module dependencies to con.sum.xml.bind, and get rid of those four modules. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12898) Multiversion Testing for wildfly images

by Panagiotis Sotiropoulos (Jira)

[ https://issues.redhat.com/browse/WFLY-12898?page=com.atlassian.jira.plugi... ] Panagiotis Sotiropoulos updated WFLY-12898: ------------------------------------------- Git Pull Request: https://github.com/jboss-set/eap-additional-testsuite/commit/6f4e58ab3b25..., https://github.com/jboss-set/eap-additional-testsuite/commit/cf0667c25577... (was: https://github.com/jboss-set/eap-additional-testsuite/commit/6f4e58ab3b25...) > Multiversion Testing for wildfly images > ---------------------------------------- > > Key: WFLY-12898 > URL: https://issues.redhat.com/browse/WFLY-12898 > Project: WildFly > Issue Type: Task > Components: Test Suite > Reporter: Panagiotis Sotiropoulos > Assignee: Panagiotis Sotiropoulos > Priority: Major > > Multiversion Testing for wildfly images with EAT -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12920) [EAT] : Load two different server distributions

by Panagiotis Sotiropoulos (Jira)

Panagiotis Sotiropoulos created WFLY-12920: ---------------------------------------------- Summary: [EAT] : Load two different server distributions Key: WFLY-12920 URL: https://issues.redhat.com/browse/WFLY-12920 Project: WildFly Issue Type: Task Components: Test Suite Reporter: Panagiotis Sotiropoulos Assignee: Panagiotis Sotiropoulos JBOSS_FOLDER2 env variable should/could be added in case it is needed. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12913) Rationalize com.sum.xml.bind module dependencies

by Lin Gao (Jira)

[ https://issues.redhat.com/browse/WFLY-12913?page=com.atlassian.jira.plugi... ] Lin Gao commented on WFLY-12913: -------------------------------- Refer to: https://github.com/wildfly/wildfly/pull/12856 for the context about this issue. > Rationalize com.sum.xml.bind module dependencies > ------------------------------------------------ > > Key: WFLY-12913 > URL: https://issues.redhat.com/browse/WFLY-12913 > Project: WildFly > Issue Type: Task > Components: JPA / Hibernate, REST, Web Services > Reporter: Brian Stansberry > Priority: Minor > > The com.sun.xml.bind module depends on and exports four other modules, and those modules in turn are private and have no other dependents: > {code} > <module name="com.github.relaxng" export="true" /> > <module name="com.sun.istack" export="true" /> > <module name="com.sun.xml.txw2" export="true" /> > <module name="com.sun.xsom" export="true" /> > {code} > Task is to: > 1) Write to wildfly-dev mail list to check for any projects that layer on WildFly that directly use these modules. > 2) Write to jboss-layered-products (internal Red Hat) mail list to check for any products based on WF/EAP that directly use these modules. > 3) Assuming no positive responses, make the artifacts from the above four modules direct artifacts of the com.sun.xml.bind module, add any needed module dependencies to con.sum.xml.bind, and get rid of those four modules. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2427) UDP: change methods deprecated in Java 14

by Bela Ban (Jira)

Bela Ban created JGRP-2427: ------------------------------ Summary: UDP: change methods deprecated in Java 14 Key: JGRP-2427 URL: https://issues.redhat.com/browse/JGRP-2427 Project: JGroups Issue Type: Task Reporter: Bela Ban Assignee: Bela Ban Fix For: 5.0 Several methods in UDP will get deprecated in Java 14, e.g. {{MulticastSocket.joinGroup()/leaveGroup()/setInterface()}} etc. They can be replaced with their suggested alternatives, even in Java 11 (these methods are already present). -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4879) [DMN Designer] unification of import flash messages

by Jozef Marko (Jira)

[ https://issues.redhat.com/browse/DROOLS-4879?page=com.atlassian.jira.plug... ] Jozef Marko commented on DROOLS-4879: ------------------------------------- [~uxdlc] thank you for finding the proper solution. [~dadossan] ok, I reassigned the jira to you as I guess you will implement it, am I right? > [DMN Designer] unification of import flash messages > --------------------------------------------------- > > Key: DROOLS-4879 > URL: https://issues.redhat.com/browse/DROOLS-4879 > Project: Drools > Issue Type: Bug > Components: DMN Editor > Affects Versions: 7.32.0.Final > Reporter: Jozef Marko > Assignee: Daniel José dos Santos > Priority: Major > Labels: drools-tools > > We should unify the flash messages related to import data types. See the github comment here https://github.com/kiegroup/kie-wb-common/pull/3071#issuecomment-566436373 -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4879) [DMN Designer] unification of import flash messages

by Jozef Marko (Jira)

[ https://issues.redhat.com/browse/DROOLS-4879?page=com.atlassian.jira.plug... ] Jozef Marko reassigned DROOLS-4879: ----------------------------------- Assignee: Daniel José dos Santos (was: Elizabeth Clayton) > [DMN Designer] unification of import flash messages > --------------------------------------------------- > > Key: DROOLS-4879 > URL: https://issues.redhat.com/browse/DROOLS-4879 > Project: Drools > Issue Type: Bug > Components: DMN Editor > Affects Versions: 7.32.0.Final > Reporter: Jozef Marko > Assignee: Daniel José dos Santos > Priority: Major > Labels: drools-tools > > We should unify the flash messages related to import data types. See the github comment here https://github.com/kiegroup/kie-wb-common/pull/3071#issuecomment-566436373 -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4879) [DMN Designer] unification of import flash messages

by Jozef Marko (Jira)

[ https://issues.redhat.com/browse/DROOLS-4879?page=com.atlassian.jira.plug... ] Jozef Marko updated DROOLS-4879: -------------------------------- Summary: [DMN Designer] unification of import flash messages (was: [UX] [DMN Designer] unification of import flash messages) > [DMN Designer] unification of import flash messages > --------------------------------------------------- > > Key: DROOLS-4879 > URL: https://issues.redhat.com/browse/DROOLS-4879 > Project: Drools > Issue Type: Bug > Components: DMN Editor > Affects Versions: 7.32.0.Final > Reporter: Jozef Marko > Assignee: Elizabeth Clayton > Priority: Major > Labels: drools-tools > > We should unify the flash messages related to import data types. See the github comment here https://github.com/kiegroup/kie-wb-common/pull/3071#issuecomment-566436373 -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4879) [UX] [DMN Designer] unification of import flash messages

by Jozef Marko (Jira)

[ https://issues.redhat.com/browse/DROOLS-4879?page=com.atlassian.jira.plug... ] Jozef Marko updated DROOLS-4879: -------------------------------- Component/s: DMN Editor > [UX] [DMN Designer] unification of import flash messages > -------------------------------------------------------- > > Key: DROOLS-4879 > URL: https://issues.redhat.com/browse/DROOLS-4879 > Project: Drools > Issue Type: Bug > Components: DMN Editor > Affects Versions: 7.32.0.Final > Reporter: Jozef Marko > Assignee: Elizabeth Clayton > Priority: Major > Labels: drools-tools > > We should unify the flash messages related to import data types. See the github comment here https://github.com/kiegroup/kie-wb-common/pull/3071#issuecomment-566436373 -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-290) Response Content-Type is 'application/json' even when HTTP request defines 'application/json-patch+json' "Accept" header

by Fabio Burzigotti (Jira)

[ https://issues.redhat.com/browse/WFWIP-290?page=com.atlassian.jira.plugin... ] Fabio Burzigotti updated WFWIP-290: ----------------------------------- Steps to Reproduce: The issue can be reproduced following the steps: * execute Wildfly instance build from feature branch * provide a deployment to register `openapi` endpoint * send HTTP GET request to `openapi` defining the Accept header, e.g.: {code} curl --location --request GET 'http://127.0.0.1:8080/openapi' \ --header 'Accept: application/json-patch+json' {code} * the response "Content-Type" header is set to "application/json". Used feature branch is: https://github.com/pferraro/wildfly/tree/WFLY-12313 was: The issue can be reproduced following the steps: * execute Wildfly instance build from feature branch * provide a deployment to register `openapi` endpoint * send HTTP GET request to `openapi` defining the Accept header, e.g.: `curl --location --request GET 'http://127.0.0.1:8080/openapi' \ --header 'Accept: application/json-patch+json'` * the response "Content-Type" header is set to "application/json". Used feature branch is: https://github.com/pferraro/wildfly/tree/WFLY-12313 > Response Content-Type is 'application/json' even when HTTP request defines 'application/json-patch+json' "Accept" header > ------------------------------------------------------------------------------------------------------------------------ > > Key: WFWIP-290 > URL: https://issues.redhat.com/browse/WFWIP-290 > Project: WildFly WIP > Issue Type: Bug > Components: MP OpenAPI > Reporter: Fabio Burzigotti > Assignee: Paul Ferraro > Priority: Major > > When sending HTTP request header "Accept: application/json-patch+json", "Content-Type: application/json" response is returned. > This behavior seems to be less strict compared to what is defined by the spec, as it states "application/json" is specifically needed in order to get the same value back from server. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-290) Response Content-Type is 'application/json' even when HTTP request defines 'application/json-patch+json' "Accept" header

by Fabio Burzigotti (Jira)

Fabio Burzigotti created WFWIP-290: -------------------------------------- Summary: Response Content-Type is 'application/json' even when HTTP request defines 'application/json-patch+json' "Accept" header Key: WFWIP-290 URL: https://issues.redhat.com/browse/WFWIP-290 Project: WildFly WIP Issue Type: Bug Components: MP OpenAPI Reporter: Fabio Burzigotti Assignee: Paul Ferraro When sending HTTP request header "Accept: application/json-patch+json", "Content-Type: application/json" response is returned. This behavior seems to be less strict compared to what is defined by the spec, as it states "application/json" is specifically needed in order to get the same value back from server. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ELY-243) Ensure reference to repository is removed from pom

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/ELY-243?page=com.atlassian.jira.plugin.s... ] Farah Juma updated ELY-243: --------------------------- Fix Version/s: 1.11.0.CR5 (was: 1.11.0.CR4) > Ensure reference to repository is removed from pom > -------------------------------------------------- > > Key: ELY-243 > URL: https://issues.redhat.com/browse/ELY-243 > Project: WildFly Elytron > Issue Type: Task > Components: Build > Reporter: Darran Lofthouse > Priority: Major > Fix For: 1.11.0.CR5 > > > We need to ensure the reference to the JBoss repo is removed from the pom and artefacts are available from Maven Central. > Also at this point probably good to put the steps in place for Elytron to also be available from Maven Central. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ELY-533) Deprecate all legacy code

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/ELY-533?page=com.atlassian.jira.plugin.s... ] Farah Juma updated ELY-533: --------------------------- Fix Version/s: 1.11.0.CR5 (was: 1.11.0.CR4) > Deprecate all legacy code > ------------------------- > > Key: ELY-533 > URL: https://issues.redhat.com/browse/ELY-533 > Project: WildFly Elytron > Issue Type: Task > Components: API / SPI > Reporter: Darran Lofthouse > Priority: Critical > Fix For: 1.11.0.CR5 > > > In a few places we have legacy behaviour within the project to assist migration from previous JBoss / WildFly releases - this code should be flagged as deprecated to encourage minimal use. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ELY-1440) FlexibleIdentityAssociation should runAs the known SecurityIdentity before associating itself.

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/ELY-1440?page=com.atlassian.jira.plugin.... ] Farah Juma updated ELY-1440: ---------------------------- Fix Version/s: 1.11.0.CR5 (was: 1.11.0.CR4) > FlexibleIdentityAssociation should runAs the known SecurityIdentity before associating itself. > ---------------------------------------------------------------------------------------------- > > Key: ELY-1440 > URL: https://issues.redhat.com/browse/ELY-1440 > Project: WildFly Elytron > Issue Type: Enhancement > Components: API / SPI > Reporter: Darran Lofthouse > Priority: Major > Fix For: 1.11.0.CR5 > > > This API was introduced to cover the case where authentication happens late in a request, generally that is quite a rare event. > Even though the API may be popular it would likely happen once for a session and all future requests for that session the identity would be known in advance. > At the moment by not running as the existing identity we are loosing all automatic identity outflow opportunities as calls pass from the servlet container to the EJB container. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ELY-1735) Clean up the 'wildfly-elytron-auth-server' module as it currently contains both public and private API

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/ELY-1735?page=com.atlassian.jira.plugin.... ] Farah Juma updated ELY-1735: ---------------------------- Fix Version/s: 1.11.0.CR5 (was: 1.11.0.CR4) > Clean up the 'wildfly-elytron-auth-server' module as it currently contains both public and private API > ------------------------------------------------------------------------------------------------------ > > Key: ELY-1735 > URL: https://issues.redhat.com/browse/ELY-1735 > Project: WildFly Elytron > Issue Type: Task > Reporter: Farah Juma > Priority: Major > Fix For: 2.0.0.Alpha7, 1.11.0.CR5 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ELY-1726) Revisit the need for `wildfly-elytron-credential` to depend on `wildfly-elytron-digest`

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/ELY-1726?page=com.atlassian.jira.plugin.... ] Farah Juma updated ELY-1726: ---------------------------- Fix Version/s: 1.11.0.CR5 (was: 1.11.0.CR4) > Revisit the need for `wildfly-elytron-credential` to depend on `wildfly-elytron-digest` > --------------------------------------------------------------------------------------- > > Key: ELY-1726 > URL: https://issues.redhat.com/browse/ELY-1726 > Project: WildFly Elytron > Issue Type: Task > Components: Credentials > Reporter: Darran Lofthouse > Priority: Critical > Fix For: 1.11.0.CR5 > > > This was introduced in the following PR https://github.com/wildfly-security-incubator/wildfly-elytron/pull/54 -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ELY-1682) Fallback to another SASL client mechanism when SASL client initialisation fails

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/ELY-1682?page=com.atlassian.jira.plugin.... ] Farah Juma updated ELY-1682: ---------------------------- Fix Version/s: 1.11.0.CR5 (was: 1.11.0.CR4) > Fallback to another SASL client mechanism when SASL client initialisation fails > ------------------------------------------------------------------------------- > > Key: ELY-1682 > URL: https://issues.redhat.com/browse/ELY-1682 > Project: WildFly Elytron > Issue Type: Bug > Components: SASL > Affects Versions: 1.7.0.CR1 > Reporter: Martin Choma > Priority: Major > Fix For: 1.11.0.CR5 > > Attachments: org.jboss.eapqe.krbldap.eap71.tests.krb.ejb.KerberosEjbGssapiTestCase-output.txt > > > {code:title=HipChat conversation} > Martin Choma: I have got this situation here; Server is authenticated with GSSAPI and PLAIN. Client has only username/password credential - no kerberos credential. > But client tries to create GssapiSaslClient as well (which make problem on IBM). Once I set .setSaslMechanismSelector(SaslMechanismSelector.fromString("PLAIN")) scenario works ok. > I wonder could Authentication Client be smart enough to not try to initialize authentication mechanisms which it has not credentials for? > Darran Lofthouse: Client side GSSAPI we tend not to have configured credentials as the mech obtains from OS level. The mech should fail and allow the next mech to be selected > Martin Choma: Ok, so I will create issue. Seems on client side this mechanism fallback does not work properly. (At least in IBM JDK case). > In this case it is initialization of mechanism which is failing, so maybe fallback does not have chance to get involved. > Darran Lofthouse: Sounds possible, if a mech can not initialise we should likely treat it as a failed mech and move on - maybe something needed in Remoting > though for that one as that is where that loop happens but start with an ELY issue > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ELY-1687) Initial WildFly Elytron Performance Enhancments

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/ELY-1687?page=com.atlassian.jira.plugin.... ] Farah Juma updated ELY-1687: ---------------------------- Fix Version/s: 1.11.0.CR5 (was: 1.11.0.CR4) > Initial WildFly Elytron Performance Enhancments > ----------------------------------------------- > > Key: ELY-1687 > URL: https://issues.redhat.com/browse/ELY-1687 > Project: WildFly Elytron > Issue Type: Task > Affects Versions: 1.7.0.CR2 > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Fix For: 1.11.0.CR5 > > Attachments: BASIC_Auth_Load.jmx, Flight.tgz > > > Rather than this becoming a single long running task to review the performance of WildFly Elytron I think the best strategy is to identity a test strategy, obtain some metrics of that strategy under load, perform profiling to identity a set of issues and look at options to address those issues. > After that we will perform the initial metric test again and close the issue. > A new issue will then be created either to repeat the same test or start with a new test which may be a subtle change of the first test. > The first test is to test HTTP Basic authentication backed by WildFly Elytron. > * Each client will alternatively send a request with no authorization header so triggering a HTTP 401 challenge followed by a request including the header which should successfully authenticate. > Attached is a JMeter test plan configured to use 250 client threads, each submitting requests for 5 minutes. > h2. Initial Issues > h3. WildFlyElytronProvider Locking > Total block time 8.393s via calls to java.security.Provider.getServices(); > Potentially something that could be eliminated if mechanisms were loaded in advance, or at the very least the factories were loaded in advance. > h3. Memory 2.42G of char[] > e.g. > {noformat} > void java.nio.HeapCharBuffer.<init>(int, int) 13037 > CharBuffer java.nio.CharBuffer.allocate(int) 9148 > CharBuffer java.nio.charset.CharsetDecoder.decode(ByteBuffer) 9148 > CharBuffer java.nio.charset.Charset.decode(ByteBuffer) 9148 > void org.wildfly.security.http.impl.BasicAuthenticationMechanism.evaluateRequest(HttpServerRequest) 9148 > {noformat} > Is there any option to re-use these as they can be cleared instead of leaving to GC. > HeapByteBuffer and HeapCharBuffer are also quite prominent. > h3. Memory 1.78G of Callback[] > Using the CallbackHandler API the use of the array is inevitable. > * Could we extend the API to avoid the array? > * Could we re-use the array? Could consider null termination. > {noformat} > boolean org.wildfly.security.http.impl.UsernamePasswordAuthenticationMechanism.authenticate(String, String, char[]) 9222 > void org.wildfly.security.http.impl.BasicAuthenticationMechanism.evaluateRequest(HttpServerRequest) 9222 > {noformat} > h3. Memory 1.41G of HttpAuthenticator$Builder > {noformat} > HttpAuthenticator$Builder org.wildfly.security.http.HttpAuthenticator.builder() 24699 > boolean org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate() 24699 > {noformat} > Could we switch to something that associated these with a ThreadLocal and update the API to allow re-use? > h3. Memory 1.3G of SecurityContextImpl > {noformat} > SecurityContext org.wildfly.elytron.web.undertow.server.SecurityContextImpl$Builder.build() 3247 > SecurityContext org.wildfly.elytron.web.undertow.server.ElytronContextAssociationHandler.createSecurityContext(HttpServerExchange) 1673 > {noformat} > Also instances of HttpAuthenticator > {noformat} > HttpAuthenticator org.wildfly.security.http.HttpAuthenticator$Builder.build() 14624 > {noformat} > And instances of HttpAuthenticator$AuthenticationExchange. > {noformat} > boolean org.wildfly.security.http.HttpAuthenticator.authenticate() 14423 > {noformat} > As with HttpAuthenticator$Builder is there any way to consider re-use? > h3. Memory 1.21G of java.util.ArrayList > {noformat} > boolean org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate() 8911 > {noformat} > Can check the use and see if an alternative is possible. > _If this mechanism was re-written as a recursive call it would eliminate the need for the intermediate ArrayList to hold the responders._ > _This will still be a worthwhile improvement but may need to keep in mind this ArrayList size likely includes the responders which means it includes the mechs and the additional references._ > https://issues.jboss.org/browse/ELY-1689 > h3. Memory ServerAuthenticationContext States > Each ServerAuthenticationContext State is it's own class which needs to be instantiated, a single authentication requests results in multiple states. > Should the state machine be internal to the ServerAuthenticationContext so we have only one class instance? > h3. Memory SecurityIdentity > As an immutable object we can end up with intermediate throw away instances, can we optimise create once? > {noformat} > SecurityIdentity org.wildfly.security.auth.server.SecurityIdentity.withPrivateCredentials(IdentityCredentials) 11454 > ServerAuthenticationContext$AuthorizedAuthenticationState org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.doAuthorization(boolean) 11454 > {noformat} > h3. Method Profiling - org.wildfly.common.iteration.ByteArrayIterator and ByteIterator > These lead to multiple instances of different classes, and the iteration is flagging in the top 10 packages. > Could a static Base64 conversion clean up a lot of this? > h1. Done > h3. Method Profiling - new HttpString > A lot of time spend creating new HttpString (Package is no3 in the top list) > {noformat} > void io.undertow.util.HttpString.<init>(String) 4 > void org.wildfly.elytron.web.undertow.server.ElytronHttpExchange.addResponseHeader(String, String) 4 > {noformat} > Could we re-use the HttpString for common header types? > Re-use of HttpString from cache https://issues.jboss.org/browse/ELYWEB-25 > h3. Memory 885Mb of Undertow FormParserFactory$ParserDefinition[] > {noformat} > FormParserFactory$Builder io.undertow.server.handlers.form.FormParserFactory.builder(boolean) 1091 > FormParserFactory$Builder io.undertow.server.handlers.form.FormParserFactory.builder() 1091 > void org.wildfly.elytron.web.undertow.server.ElytronHttpExchange.<init>(HttpServerExchange, Map, ScopeSessionListener) 1091 > {noformat} > This test did not use forms at all, is this something that can be delayed until we know it is needed? > _It may be possible for the FormParserFactory to be a single static reference, the parser it self is created on a per-request basis as needed._ > https://issues.jboss.org/browse/ELYWEB-27 -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ELY-1700) Intermittently failing AttributeMappingSuiteChild

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/ELY-1700?page=com.atlassian.jira.plugin.... ] Farah Juma updated ELY-1700: ---------------------------- Fix Version/s: 1.11.0.CR5 (was: 1.11.0.CR4) > Intermittently failing AttributeMappingSuiteChild > ------------------------------------------------- > > Key: ELY-1700 > URL: https://issues.redhat.com/browse/ELY-1700 > Project: WildFly Elytron > Issue Type: Bug > Components: Testsuite > Affects Versions: 1.7.0.CR2 > Reporter: Martin Choma > Priority: Minor > Fix For: 1.11.0.CR5 > > > With ration 1:1000 we see ELY01125: Ldap-backed realm failed to obtain context. > {noformat} > org.wildfly.security.auth.server.RealmUnavailableException: ELY01125: Ldap-backed realm failed to obtain context > at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm.obtainContext(LdapSecurityRealm.java:215) > at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm.access$600(LdapSecurityRealm.java:102) > at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.exists(LdapSecurityRealm.java:622) > at org.wildfly.security.auth.server.ServerAuthenticationContext.exists(ServerAuthenticationContext.java:447) > at org.wildfly.security.ldap.AbstractAttributeMappingSuiteChild.assertAttributes(AbstractAttributeMappingSuiteChild.java:85) > at org.wildfly.security.ldap.AbstractAttributeMappingSuiteChild.assertAttributes(AbstractAttributeMappingSuiteChild.java:77) > at org.wildfly.security.ldap.AttributeMappingSuiteChild.testSingleAttributeToSpecifiedName(AttributeMappingSuiteChild.java:33) > at org.wildfly.security.ldap.DirContextFactoryRule$1.evaluate(DirContextFactoryRule.java:218) > Caused by: javax.naming.NamingException: LDAP response read timed out, timeout used:5000ms. > at com.sun.jndi.ldap.Connection.readReply(Connection.java:507) > at com.sun.jndi.ldap.LdapClient.ldapBind(LdapClient.java:365) > at com.sun.jndi.ldap.LdapClient.authenticate(LdapClient.java:214) > at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2791) > at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:319) > at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:192) > at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:210) > at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:153) > at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:83) > at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684) > at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313) > at javax.naming.InitialContext.init(InitialContext.java:244) > at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154) > at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.createDirContext(SimpleDirContextFactoryBuilder.java:436) > at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.obtainDirContext(SimpleDirContextFactoryBuilder.java:355) > at org.wildfly.security.ldap.DirContextFactoryRule.lambda$create$0(DirContextFactoryRule.java:258) > at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm.obtainContext(LdapSecurityRealm.java:203) > ... 7 more > {noformat} > {noformat} > 00:29:39,451 TRACE (main) [org.wildfly.security] <SecurityDomain.java:1036> Building security domain with defaultRealmName default. > 00:29:39,452 TRACE (main) [org.wildfly.security] <SecurityDomain.java:708> Role mapping: principal [anonymous] -> decoded roles [] -> realm mapped roles [] -> domain mapped roles [] > 00:29:39,452 TRACE (main) [org.wildfly.security] <ServerAuthenticationContext.java:1163> Principal assigning: [userWithAttributes], pre-realm rewritten: [userWithAttributes], realm name: [default], post-realm rewritten: [userWithAttributes], realm rewritten: [userWithAttributes] > 00:29:39,453 DEBUG (main) [org.wildfly.security] <LdapSecurityRealm.java:189> Obtaining lock for identity [userWithAttributes]... > 00:29:39,454 DEBUG (main) [org.wildfly.security] <LdapSecurityRealm.java:197> Obtained lock for identity [userWithAttributes]. > 00:29:39,454 DEBUG (main) [org.wildfly.security] <SimpleDirContextFactoryBuilder.java:427> Creating [class javax.naming.directory.InitialDirContext] with environment: > 00:29:39,454 DEBUG (main) [org.wildfly.security] <SimpleDirContextFactoryBuilder.java:428> Property [java.naming.security.credentials] with value [******] > 00:29:39,455 DEBUG (main) [org.wildfly.security] <SimpleDirContextFactoryBuilder.java:428> Property [java.naming.ldap.factory.socket] with value [org.wildfly.security.auth.realm.ldap.ThreadLocalSSLSocketFactory] > 00:29:39,455 DEBUG (main) [org.wildfly.security] <SimpleDirContextFactoryBuilder.java:428> Property [java.naming.security.authentication] with value [simple] > 00:29:39,456 DEBUG (main) [org.wildfly.security] <SimpleDirContextFactoryBuilder.java:428> Property [java.naming.provider.url] with value [ldap://localhost:11390/] > 00:29:39,456 DEBUG (main) [org.wildfly.security] <SimpleDirContextFactoryBuilder.java:428> Property [com.sun.jndi.ldap.read.timeout] with value [60000] > 00:29:39,456 DEBUG (main) [org.wildfly.security] <SimpleDirContextFactoryBuilder.java:428> Property [com.sun.jndi.ldap.connect.timeout] with value [5000] > 00:29:39,456 DEBUG (main) [org.wildfly.security] <SimpleDirContextFactoryBuilder.java:428> Property [java.naming.security.principal] with value [uid=server,dc=elytron,dc=wildfly,dc=org] > 00:29:39,457 DEBUG (main) [org.wildfly.security] <SimpleDirContextFactoryBuilder.java:428> Property [java.naming.referral] with value [ignore] > 00:29:39,457 DEBUG (main) [org.wildfly.security] <SimpleDirContextFactoryBuilder.java:428> Property [java.naming.factory.initial] with value [com.sun.jndi.ldap.LdapCtxFactory] > 00:29:44,528 DEBUG (main) [org.wildfly.security] <SimpleDirContextFactoryBuilder.java:438> Could not create [class javax.naming.ldap.InitialLdapContext]. Failed to connect to LDAP server.: javax.naming.NamingException: LDAP response read timed out, timeout used:5000ms. > at com.sun.jndi.ldap.Connection.readReply(Connection.java:507) > at com.sun.jndi.ldap.LdapClient.ldapBind(LdapClient.java:365) > at com.sun.jndi.ldap.LdapClient.authenticate(LdapClient.java:214) > at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2791) > at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:319) > at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:192) > at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:210) > at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:153) > at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:83) > at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684) > at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313) > at javax.naming.InitialContext.init(InitialContext.java:244) > at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154) > at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.createDirContext(SimpleDirContextFactoryBuilder.java:436) > at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.obtainDirContext(SimpleDirContextFactoryBuilder.java:355) > at org.wildfly.security.ldap.DirContextFactoryRule.lambda$create$0(DirContextFactoryRule.java:258) > at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm.obtainContext(LdapSecurityRealm.java:203) > at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm.access$600(LdapSecurityRealm.java:102) > at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.exists(LdapSecurityRealm.java:622) > at org.wildfly.security.auth.server.ServerAuthenticationContext.exists(ServerAuthenticationContext.java:447) > at org.wildfly.security.ldap.AbstractAttributeMappingSuiteChild.assertAttributes(AbstractAttributeMappingSuiteChild.java:85) > at org.wildfly.security.ldap.AbstractAttributeMappingSuiteChild.assertAttributes(AbstractAttributeMappingSuiteChild.java:77) > at org.wildfly.security.ldap.AttributeMappingSuiteChild.testSingleAttributeToSpecifiedName(AttributeMappingSuiteChild.java:33) > 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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) > at mockit.integration.junit4.internal.JUnit4TestRunnerDecorator.executeTestMethod(JUnit4TestRunnerDecorator.java:162) > at mockit.integration.junit4.internal.JUnit4TestRunnerDecorator.invokeExplosively(JUnit4TestRunnerDecorator.java:71) > at mockit.integration.junit4.internal.MockFrameworkMethod.invokeExplosively(MockFrameworkMethod.java:37) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java) > at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at org.junit.runners.Suite.runChild(Suite.java:128) > at org.junit.runners.Suite.runChild(Suite.java:27) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) > at org.wildfly.security.ldap.DirContextFactoryRule$1.evaluate(DirContextFactoryRule.java:218) > at org.junit.rules.RunRules.evaluate(RunRules.java:20) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161) > at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290) > at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121) > 00:29:44,529 INFO (pool-3-thread-2) [org.apache.directory.server.ldap.handlers.LdapRequestHandler] <LdapRequestHandler.java:131> ignoring the message Abandon Request : > Message Id : 1org.apache.directory.api.ldap.model.message.AbandonRequestImpl@8444b052 received from null session > {noformat} > Maybe just to try prolong SimpleDirContextFactoryBuilder#DEFAULT_CONNECT_TIMEOUT [1] > This issue occurs also with ELY-1699. It is very probable machine was slow. But it would be fine if testsuite could cope with this situation as well. > > [1] https://github.com/wildfly-security/wildfly-elytron/blob/38e1e01972414ad7... -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ELY-1706) Add support for TLS 1.3

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/ELY-1706?page=com.atlassian.jira.plugin.... ] Farah Juma updated ELY-1706: ---------------------------- Fix Version/s: 1.11.0.CR5 (was: 1.11.0.CR4) > Add support for TLS 1.3 > ----------------------- > > Key: ELY-1706 > URL: https://issues.redhat.com/browse/ELY-1706 > Project: WildFly Elytron > Issue Type: Feature Request > Components: SSL > Reporter: Farah Juma > Assignee: Farah Juma > Priority: Major > Labels: eap-7.2.0-deferred > Fix For: 1.11.0.CR5 > > > It presently appears as though TLS 1.3 support could be available from Java 11. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ELY-1723) Separate auth client parsing from the API.

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/ELY-1723?page=com.atlassian.jira.plugin.... ] Farah Juma updated ELY-1723: ---------------------------- Fix Version/s: 1.11.0.CR5 (was: 1.11.0.CR4) > Separate auth client parsing from the API. > ------------------------------------------ > > Key: ELY-1723 > URL: https://issues.redhat.com/browse/ELY-1723 > Project: WildFly Elytron > Issue Type: Task > Components: Authentication Client > Reporter: Darran Lofthouse > Assignee: Ashley Abdel-Sayed > Priority: Blocker > Fix For: 1.11.0.CR5 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ELY-1724) Develop an alternative to 'org.wildfly.security.credential.source.OAuth2CredentialSource'

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/ELY-1724?page=com.atlassian.jira.plugin.... ] Farah Juma updated ELY-1724: ---------------------------- Fix Version/s: 1.11.0.CR5 (was: 1.11.0.CR4) > Develop an alternative to 'org.wildfly.security.credential.source.OAuth2CredentialSource' > ----------------------------------------------------------------------------------------- > > Key: ELY-1724 > URL: https://issues.redhat.com/browse/ELY-1724 > Project: WildFly Elytron > Issue Type: Task > Reporter: Darran Lofthouse > Assignee: Ashley Abdel-Sayed > Priority: Critical > Fix For: 1.11.0.CR5 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ELY-1737) Clean up the 'wildfly-elytron-credential-store' module as it currently contains both public and private API

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/ELY-1737?page=com.atlassian.jira.plugin.... ] Farah Juma updated ELY-1737: ---------------------------- Fix Version/s: 1.11.0.CR5 (was: 1.11.0.CR4) > Clean up the 'wildfly-elytron-credential-store' module as it currently contains both public and private API > ----------------------------------------------------------------------------------------------------------- > > Key: ELY-1737 > URL: https://issues.redhat.com/browse/ELY-1737 > Project: WildFly Elytron > Issue Type: Task > Reporter: Farah Juma > Priority: Major > Fix For: 2.0.0.Alpha7, 1.11.0.CR5 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira January 2020