[JBoss JIRA] (DROOLS-4305) getOldObject() of ObjectUpdatedEvent is returning same value as getObject()
by Mario Fusco (Jira)
[ https://issues.jboss.org/browse/DROOLS-4305?page=com.atlassian.jira.plugi... ]
Mario Fusco resolved DROOLS-4305.
---------------------------------
Resolution: Explained
In this case both variables passed to the listener point to the same instance. You're modifying the object in place and we cannot make a copy of it (or better don't want both for perf reason and because we should use serialization and cannot assume that all users' objects are serializable).
> getOldObject() of ObjectUpdatedEvent is returning same value as getObject()
> ---------------------------------------------------------------------------
>
> Key: DROOLS-4305
> URL: https://issues.jboss.org/browse/DROOLS-4305
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.16.0.Final
> Environment: Windows 10 Version 1803 (OS Build 17134.829)
> Eclipse 2018-12 (4.10.0)
> jdk1.8.0_171
> Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T15:39:06-04:00)
> spring-boot-starter-parent 2.1.2.RELEASE
> Reporter: Benoit Proulx
> Assignee: Mario Fusco
> Priority: Optional
>
> We have built a logger file for our rules that implements org.kie.api.event.rule.RuleRuntimeEventListener.
> Whenever the objectUpdated(ObjectUpdatedEvent) method is called, the ObjectUpdatedEvent contains the values of both the old Object and new object (or getOldObject() and getObject() )
> However, it seems that getOldObject() is always returning the same value as getObject().
> Having both values would be very helpful in debugging rules.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (DROOLS-4305) getOldObject() of ObjectUpdatedEvent is returning same value as getObject()
by Mario Fusco (Jira)
[ https://issues.jboss.org/browse/DROOLS-4305?page=com.atlassian.jira.plugi... ]
Mario Fusco updated DROOLS-4305:
--------------------------------
Sprint: 2019 Week 29-31
> getOldObject() of ObjectUpdatedEvent is returning same value as getObject()
> ---------------------------------------------------------------------------
>
> Key: DROOLS-4305
> URL: https://issues.jboss.org/browse/DROOLS-4305
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.16.0.Final
> Environment: Windows 10 Version 1803 (OS Build 17134.829)
> Eclipse 2018-12 (4.10.0)
> jdk1.8.0_171
> Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T15:39:06-04:00)
> spring-boot-starter-parent 2.1.2.RELEASE
> Reporter: Benoit Proulx
> Assignee: Mario Fusco
> Priority: Optional
>
> We have built a logger file for our rules that implements org.kie.api.event.rule.RuleRuntimeEventListener.
> Whenever the objectUpdated(ObjectUpdatedEvent) method is called, the ObjectUpdatedEvent contains the values of both the old Object and new object (or getOldObject() and getObject() )
> However, it seems that getOldObject() is always returning the same value as getObject().
> Having both values would be very helpful in debugging rules.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (DROOLS-2319) Object passed to Decision Table not set in Action columns
by Mario Fusco (Jira)
[ https://issues.jboss.org/browse/DROOLS-2319?page=com.atlassian.jira.plugi... ]
Mario Fusco resolved DROOLS-2319.
---------------------------------
Resolution: Cannot Reproduce
> Object passed to Decision Table not set in Action columns
> ---------------------------------------------------------
>
> Key: DROOLS-2319
> URL: https://issues.jboss.org/browse/DROOLS-2319
> Project: Drools
> Issue Type: Bug
> Components: decision tables
> Affects Versions: 7.6.0.Final
> Reporter: Adil berdai
> Assignee: Mario Fusco
> Priority: Critical
> Attachments: BugDroolsPassedParamDecisonTable.xlsx
>
>
> Hi,
> When I pass an object as parameter to my decison table. this object is set (populated with already assigned values) in conditions but not in action columns. When I call some getters in Action columns already set before , I got a null value in all fields ! It works fine in version 7.4.1.Final : I got all values , but when I switch to the version 7.6.0.Final , it doesn't work !
> I thank you,
> Adil
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (DROOLS-2150) QuartzSchedulerService NullPointerException
by Mario Fusco (Jira)
[ https://issues.jboss.org/browse/DROOLS-2150?page=com.atlassian.jira.plugi... ]
Mario Fusco resolved DROOLS-2150.
---------------------------------
Resolution: Cannot Reproduce
> QuartzSchedulerService NullPointerException
> -------------------------------------------
>
> Key: DROOLS-2150
> URL: https://issues.jboss.org/browse/DROOLS-2150
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.5.0.Final
> Environment: jBPM 6 and Quartz timer
> Reporter: Csaba Házi
> Assignee: Mario Fusco
> Priority: Major
>
> 2017-11-23 10:52:11,064 INFO [org.quartz.core.JobRunShell] (JbpmScheduler_Worker-4) Job jbpm.Timer-ExpireJobContext-6 threw a JobExecutionException: : org.quartz.JobExecutionException: Exception when executing scheduled job [See nested exception: java.lang.NullPointerException]
> at org.jbpm.process.core.timer.impl.QuartzSchedulerService$QuartzJob.execute(QuartzSchedulerService.java:341)
> at org.quartz.core.JobRunShell.run(JobRunShell.java:216)
> at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:549)
> Caused by: java.lang.NullPointerException
> at org.jbpm.process.core.timer.impl.QuartzSchedulerService$InmemoryTimerJobInstanceDelegate.call(QuartzSchedulerService.java:401)
> at org.jbpm.process.core.timer.impl.QuartzSchedulerService$InmemoryTimerJobInstanceDelegate.call(QuartzSchedulerService.java:348)
> at org.jbpm.process.core.timer.impl.QuartzSchedulerService$QuartzJob.execute(QuartzSchedulerService.java:322)
> ... 2 more
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (DROOLS-1771) Serialization is triggering rule multiple times
by Mario Fusco (Jira)
[ https://issues.jboss.org/browse/DROOLS-1771?page=com.atlassian.jira.plugi... ]
Mario Fusco updated DROOLS-1771:
--------------------------------
Sprint: 2019 Week 29-31
> Serialization is triggering rule multiple times
> ------------------------------------------------
>
> Key: DROOLS-1771
> URL: https://issues.jboss.org/browse/DROOLS-1771
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.2.0.Final, 7.3.0.Final
> Reporter: Christopher Brecht
> Assignee: Mario Fusco
> Priority: Major
> Attachments: EventA.java, Person.java, Reproducer.java
>
>
> I attached a reproducer of the problem. If I am executing the rules without serialization everything is working correctly. You can see the output we expect without serialization.
> The EventA at 3:00:30 shouldn’t trigger the rule one at time 3:05:00. Using serialization, event/rule triggering seems to ignore the temporal order of timed events.
> +*WITH SERIALIZATION *+
> STATE OUT Fri Jan 01 03:03:00 CET 2010 com.reproducer.EventA@614aeccc[value=1,timestamp=Fri Jan 01 03:02:00 CET 2010]
> STATE IN Fri Jan 01 03:05:00 CET 2010 com.reproducer.EventA@444548a0[value=0,timestamp=Fri Jan 01 03:00:30 CET 2010]
> STATE IN Fri Jan 01 03:05:00 CET 2010 com.reproducer.EventA@773c0293[value=0,timestamp=Fri Jan 01 03:04:00 CET 2010]
> STATE OUT Fri Jan 01 03:07:00 CET 2010 com.reproducer.EventA@319854f0[value=1,timestamp=Fri Jan 01 03:02:00 CET 2010]
> STATE OUT Fri Jan 01 03:07:00 CET 2010 com.reproducer.EventA@415156bf[value=1,timestamp=Fri Jan 01 03:06:00 CET 2010]
> +*WITHOUT SERIALIZATION *+
> STATE OUT Fri Jan 01 03:03:00 CET 2010 com.reproducer.EventA@659925f4[value=1,timestamp=Fri Jan 01 03:02:00 CET 2010]
> STATE IN Fri Jan 01 03:05:00 CET 2010 com.reproducer.EventA@562c877a[value=0,timestamp=Fri Jan 01 03:04:00 CET 2010]
> STATE OUT Fri Jan 01 03:07:00 CET 2010 com.reproducer.EventA@3b569985[value=1,timestamp=Fri Jan 01 03:06:00 CET 2010]
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (JGRP-2363) DNS Ping cannot lookup SRV record for service port
by Sebastian Laskawiec (Jira)
[ https://issues.jboss.org/browse/JGRP-2363?page=com.atlassian.jira.plugin.... ]
Sebastian Laskawiec commented on JGRP-2363:
-------------------------------------------
Hey Howard,
Here you have a an example that I've been using for testing OpenShift
integration:
https://github.com/slaskawi/jgroups-dns-ping-example#testing-srv-entries
Thanks,
Sebastian
> DNS Ping cannot lookup SRV record for service port
> --------------------------------------------------
>
> Key: JGRP-2363
> URL: https://issues.jboss.org/browse/JGRP-2363
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.20
> Reporter: Howard Gao
> Assignee: Bela Ban
> Priority: Major
> Attachments: App2.java
>
>
> I've got a problem regarding getting service port in DNS_PING DNS lookup.
> It seems in my openshift environment the JNDI DNS lookup cannot query the
> correct SRV record from the openshift DNS server. Ref:
> https://github.com/jboss-openshift/openshift-ping/blob/1.2.1.Final/dns/sr...
> For example, here is the ping service:
> apiVersion: v1
> kind: Service
> metadata:
> annotations:
> description: The JGroups ping port for clustering.
> service.alpha.kubernetes.io/tolerate-unready-endpoints: 'true'
> labels:
> application: application0
> template: amq-broker-73-persistence-clustered
> xpaas: 1.4.16
> name: application0-ping
> spec:
> clusterIP: None
> publishNotReadyAddresses: true
> ports:
> port: 8888
> protocol: TCP
> name: jgroup-port
> targetPort: 8888
> selector:
> deploymentConfig: application0-amq
> After it is deployed I deployed a application pod
> with JGroups DNS_PING protocol loaded. The relevant
> jgroups xml part looks like this:
> <config> ... <openshift.DNS_PING timeout="3000" serviceName="application0-ping" /> ... </config>
> After my application pod is in running state, I checked the log
> and there is a warning message from DNS_PING:
> 2019-07-22 04:16:59,600 INFO [org.openshift.ping.common.Utils] 3 attempt(s) with a 1000ms sleep to execute [GetServicePort] failed. Last failure was [java.lang.NullPointerException: null]
> 2019-07-22 04:16:59,601 WARNING [org.jgroups.protocols.openshift.DNS_PING] No DNS SRV record found for service [application0-ping]
> After some debugging it turns out that the DNS lookup for the record by this name
> "_tcp.application0-ping" returned null.
> However if I logged into the application pod and do nslookup it will give me correct record:
> sh-5.0# nslookup -type=srv _tcp.application0-ping
> Server: 10.74.177.77
> Address: 10.74.177.77#53
> _tcp.application0-ping.default.svc.cluster.local service = 10 100 8888 44c84e52.application0-ping.default.svc.cluster.local.
> And you can get the full name from the record, which is
> _tcp.application0-ping.default.svc.cluster.local
> If I then pass the full qualified name into the application and it can query the SRV
> record successfully.
> I have no idea why my application can't query the record using the short form name (i.e. _tcp.application0-ping). Could it be some configuration issue for the DNS ping?
> My openshift env details are:
> oc v3.11.117
> kubernetes v1.11.0+d4cacc0
> features: Basic-Auth GSSAPI Kerberos SPNEGO
> and the java version used in pod:
> sh-5.0# java -version
> openjdk version "1.8.0_212"
> OpenJDK Runtime Environment (build 1.8.0_212-b04)
> OpenJDK 64-Bit Server VM (build 25.212-b04, mixed mode)
> and the base OS is fedora 30.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (WFLY-11434) Set the iiop bound port of the socket binding
by Martin Stefanko (Jira)
[ https://issues.jboss.org/browse/WFLY-11434?page=com.atlassian.jira.plugin... ]
Martin Stefanko updated WFLY-11434:
-----------------------------------
Labels: downstream_dependency (was: )
> Set the iiop bound port of the socket binding
> ---------------------------------------------
>
> Key: WFLY-11434
> URL: https://issues.jboss.org/browse/WFLY-11434
> Project: WildFly
> Issue Type: Enhancement
> Components: IIOP
> Reporter: Claudio Miranda
> Assignee: Claudio Miranda
> Priority: Minor
> Labels: downstream_dependency
> Fix For: 16.0.0.Beta1, 16.0.0.Final
>
>
> iiop and iiop-ssl socket binding doesn't show the runtime attributes *bound, bound-address, bound-port* as set, making it difficult to map the open ports to the socket bindings when the server is launched with a port offset.
> {code}
> "address" => [
> ("host" => "master"),
> ("server" => "server-three"),
> ("socket-binding-group" => "full-ha-sockets"),
> ("socket-binding" => "iiop")
> ],
> "outcome" => "success",
> "result" => {
> "bound" => false,
> "bound-address" => undefined,
> "bound-port" => undefined,
> "client-mappings" => undefined,
> "fixed-port" => false,
> "interface" => "unsecure",
> "multicast-address" => undefined,
> "multicast-port" => undefined,
> "name" => "iiop",
> "port" => 3528
> }
> },
> {
> "address" => [
> ("host" => "master"),
> ("server" => "server-three"),
> ("socket-binding-group" => "full-ha-sockets"),
> ("socket-binding" => "iiop-ssl")
> ],
> "outcome" => "success",
> "result" => {
> "bound" => false,
> "bound-address" => undefined,
> "bound-port" => undefined,
> "client-mappings" => undefined,
> "fixed-port" => false,
> "interface" => "unsecure",
> "multicast-address" => undefined,
> "multicast-port" => undefined,
> "name" => "iiop-ssl",
> "port" => 3529
> }
> },
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (WFLY-11566) ConstraintDeclarationException on JAX-RS/EJB Methods with List/Set query parameter
by Martin Stefanko (Jira)
[ https://issues.jboss.org/browse/WFLY-11566?page=com.atlassian.jira.plugin... ]
Martin Stefanko updated WFLY-11566:
-----------------------------------
Labels: downstream_dependency (was: )
> ConstraintDeclarationException on JAX-RS/EJB Methods with List/Set query parameter
> ----------------------------------------------------------------------------------
>
> Key: WFLY-11566
> URL: https://issues.jboss.org/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.12.1#712002)
6 years, 10 months
[JBoss JIRA] (WFCORE-4560) HTTP management interface fails to start if backed by a "https" socket-binding
by Jaikiran Pai (Jira)
[ https://issues.jboss.org/browse/WFCORE-4560?page=com.atlassian.jira.plugi... ]
Jaikiran Pai commented on WFCORE-4560:
--------------------------------------
> This JIRA is mainly to track the failure to start and a separate JIRA can/will probably be opened for dealing with the absence of the error message (since I am guessing that it's going to be a more generic issue/change).
A separate JIRA has been opened https://issues.jboss.org/browse/WFCORE-4568 for logging an error message in cases like these.
> HTTP management interface fails to start if backed by a "https" socket-binding
> ------------------------------------------------------------------------------
>
> Key: WFCORE-4560
> URL: https://issues.jboss.org/browse/WFCORE-4560
> Project: WildFly Core
> Issue Type: Bug
> Components: Server
> Affects Versions: 9.0.2.Final, 10.0.0.Beta1
> Reporter: Jaikiran Pai
> Assignee: Jeff Mesnil
> Priority: Major
> Fix For: 10.0.0.Beta2
>
>
> A user has reported that WildFly 17.0.0.Final fails to start when ManagementRealm is backed by a socket-binding which uses HTTPS. More details about this issue are here https://developer.jboss.org/thread/280311.
> There's actually more than one issue in that thread:
> 1. The failure to start
> 2. The absence of any error message indicating what failed.
> This JIRA is mainly to track the failure to start and a separate JIRA can/will probably be opened for dealing with the absence of the error message (since I am guessing that it's going to be a more generic issue/change).
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months