August 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-2874) Select a data type, inline, from DMN decision tables.

by Liz Clayton (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2874?page=com.atlassian.jira.plugi... ] Liz Clayton updated DROOLS-2874: -------------------------------- Attachment: Screen Shot 2018-08-24 at 8.38.37 AM.png > Select a data type, inline, from DMN decision tables. > ----------------------------------------------------- > > Key: DROOLS-2874 > URL: https://issues.jboss.org/browse/DROOLS-2874 > Project: Drools > Issue Type: Story > Components: DMN Editor > Reporter: Liz Clayton > Assignee: Liz Clayton > Labels: UX, UXTeam, drools-tools > Attachments: DataType selection ('Properties Panel' and 'in-grid').png, Screen Shot 2018-08-10 at 10.23.36 AM.png, Screen Shot 2018-08-24 at 8.38.37 AM.png, pop-overc.png, select.png > > > *Background* > Persona: Business analyst or Rules practitioner > Use Cases: > * From the DMN canvas view - as a user I want to *select* a data type inline from a decision table. > * > Functional considerations/ pre conditions: > * Actions will be offered or spawned inline within the cells of decision tables. > * Design needs to be consistent with Stunner and PF components. > Verification conditions: > * Scrum team and PO review. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10916) Error in description of priority attribute in filter-ref attributes

by Sande Gilda (JIRA)

[ https://issues.jboss.org/browse/WFLY-10916?page=com.atlassian.jira.plugin... ] Sande Gilda updated WFLY-10916: ------------------------------- Description: The documentation for the `undertow.filter-ref.priority` for the Undertow subsystem [1] suggests a filter with a higher number (e.g. 2) is executed before a filter with a lower number (e.g. 1). It appears to be the opposite. "Defines filter order. It should be set to 1 or more. A higher number instructs the server to be included earlier in the handler chain than others under the same context." This description is taken directly from the WildFly reference model, which is incorrect. See discussions in JBEAP-15189, [1] https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_ap... [2] https://github.com/wildfly/wildfly/blob/master/undertow/src/main/resource... was: The documentation for the `undertow.filter-ref.priority` for the Undertow subsystem [1] suggests a filter with a higher number (e.g. 2) is executed before a filter with a lower number (e.g. 1). It appears to be the opposite. "Defines filter order. It should be set to 1 or more. A higher number instructs the server to be included earlier in the handler chain than others under the same context." This description is taken directly from the WildFly reference model, which is incorrect. [1] https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_ap... > Error in description of priority attribute in filter-ref attributes > ------------------------------------------------------------------- > > Key: WFLY-10916 > URL: https://issues.jboss.org/browse/WFLY-10916 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Reporter: Sande Gilda > Assignee: Stuart Douglas > Priority: Minor > > The documentation for the `undertow.filter-ref.priority` for the Undertow subsystem [1] suggests a filter with a higher number (e.g. 2) is executed before a filter with a lower number (e.g. 1). It appears to be the opposite. > "Defines filter order. It should be set to 1 or more. A higher number instructs the server to be included earlier in the handler chain than others under the same context." > This description is taken directly from the WildFly reference model, which is incorrect. > See discussions in JBEAP-15189, > [1] https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_ap... > [2] https://github.com/wildfly/wildfly/blob/master/undertow/src/main/resource... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10916) Error in description of priority attribute in filter-ref attributes

by Sande Gilda (JIRA)

[ https://issues.jboss.org/browse/WFLY-10916?page=com.atlassian.jira.plugin... ] Sande Gilda updated WFLY-10916: ------------------------------- Description: The documentation for the `undertow.filter-ref.priority` for the Undertow subsystem [1] suggests a filter with a higher number (e.g. 2) is executed before a filter with a lower number (e.g. 1). It appears to be the opposite. "Defines filter order. It should be set to 1 or more. A higher number instructs the server to be included earlier in the handler chain than others under the same context." This description is taken directly from the WildFly reference model, which is incorrect. [1] https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_ap... was: The documentation for the `undertow.filter-ref.priority` in the undertow subsystem [1] suggests a filter with a higher number (e.g. 2) is executed before a filter with a lower number (e.g. 1). It appears to be the opposite. "Defines filter order. It should be set to 1 or more. A higher number instructs the server to be included earlier in the handler chain than others under the same context." [1] https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_ap... > Error in description of priority attribute in filter-ref attributes > ------------------------------------------------------------------- > > Key: WFLY-10916 > URL: https://issues.jboss.org/browse/WFLY-10916 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Reporter: Sande Gilda > Assignee: Stuart Douglas > Priority: Minor > > The documentation for the `undertow.filter-ref.priority` for the Undertow subsystem [1] suggests a filter with a higher number (e.g. 2) is executed before a filter with a lower number (e.g. 1). It appears to be the opposite. > "Defines filter order. It should be set to 1 or more. A higher number instructs the server to be included earlier in the handler chain than others under the same context." > This description is taken directly from the WildFly reference model, which is incorrect. > [1] https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_ap... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10916) Error in description of priority attribute in filter-ref attributes

by Sande Gilda (JIRA)

[ https://issues.jboss.org/browse/WFLY-10916?page=com.atlassian.jira.plugin... ] Sande Gilda updated WFLY-10916: ------------------------------- Description: The documentation for the `undertow.filter-ref.priority` in the undertow subsystem [1] suggests a filter with a higher number (e.g. 2) is executed before a filter with a lower number (e.g. 1). It appears to be the opposite. "Defines filter order. It should be set to 1 or more. A higher number instructs the server to be included earlier in the handler chain than others under the same context." [1] https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_ap... was: The documentation on the filter-ref attribute 'priority' in the undertow subsystem [1] suggests a filter with a higher number (e.g. 2) is executed before a filter with a lower number (e.g. 1). It appears to be the opposite. "Defines filter order. It should be set to 1 or more. A higher number instructs the server to be included earlier in the handler chain than others under the same context." [1] https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_ap... > Error in description of priority attribute in filter-ref attributes > ------------------------------------------------------------------- > > Key: WFLY-10916 > URL: https://issues.jboss.org/browse/WFLY-10916 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Reporter: Sande Gilda > Assignee: Stuart Douglas > Priority: Minor > > The documentation for the `undertow.filter-ref.priority` in the undertow subsystem [1] suggests a filter with a higher number (e.g. 2) is executed before a filter with a lower number (e.g. 1). It appears to be the opposite. > "Defines filter order. It should be set to 1 or more. A higher number instructs the server to be included earlier in the handler chain than others under the same context." > [1] https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_ap... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10916) Error in description of priority attribute in filter-ref attributes

by Sande Gilda (JIRA)

[ https://issues.jboss.org/browse/WFLY-10916?page=com.atlassian.jira.plugin... ] Sande Gilda reassigned WFLY-10916: ---------------------------------- Assignee: Stuart Douglas (was: Christian Huffman) > Error in description of priority attribute in filter-ref attributes > ------------------------------------------------------------------- > > Key: WFLY-10916 > URL: https://issues.jboss.org/browse/WFLY-10916 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Reporter: Sande Gilda > Assignee: Stuart Douglas > Priority: Minor > > The documentation on the filter-ref attribute 'priority' in the undertow subsystem [1] suggests a filter with a higher number (e.g. 2) is executed before a filter with a lower number (e.g. 1). It appears to be the opposite. > "Defines filter order. It should be set to 1 or more. A higher number instructs the server to be included earlier in the handler chain than others under the same context." > [1] https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_ap... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10916) Error in description of priority attribute in filter-ref attributes

by Sande Gilda (JIRA)

[ https://issues.jboss.org/browse/WFLY-10916?page=com.atlassian.jira.plugin... ] Sande Gilda moved JBEAP-15305 to WFLY-10916: -------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-10916 (was: JBEAP-15305) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Web (Undertow) (was: Documentation) > Error in description of priority attribute in filter-ref attributes > ------------------------------------------------------------------- > > Key: WFLY-10916 > URL: https://issues.jboss.org/browse/WFLY-10916 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Reporter: Sande Gilda > Assignee: Christian Huffman > Priority: Minor > > The documentation on the filter-ref attribute 'priority' in the undertow subsystem [1] suggests a filter with a higher number (e.g. 2) is executed before a filter with a lower number (e.g. 1). It appears to be the opposite. > "Defines filter order. It should be set to 1 or more. A higher number instructs the server to be included earlier in the handler chain than others under the same context." > [1] https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_ap... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-119) [Artemis 2.x upgrade] Lost message in replicated HA scenario with MDB

by Clebert Suconic (JIRA)

[ https://issues.jboss.org/browse/WFWIP-119?page=com.atlassian.jira.plugin.... ] Clebert Suconic commented on WFWIP-119: --------------------------------------- https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/eap-7.x-messag..., same hash as the previous one. > [Artemis 2.x upgrade] Lost message in replicated HA scenario with MDB > --------------------------------------------------------------------- > > Key: WFWIP-119 > URL: https://issues.jboss.org/browse/WFWIP-119 > Project: WildFly WIP > Issue Type: Bug > Components: Artemis > Reporter: Erich Duda > Assignee: Martyn Taylor > Priority: Blocker > > *Scenario* > * Start live/backup pair in replicated dedicated topology and start one more server which is in Artemis cluster with live. > * Send messages to queue InQueue. > * Start another server with MDB connected to cluster with live server which resend messages from InQueue to OutQueue. > * Stop backup server and then live server. > * Stop server which was in cluster with live server. > * Start live server and server in cluster. > * Start backup server. > The test fails because one message get lost. It wasn't sent to OutQueue. > Logs from failed test including traces you can find in \[1\]. > \[1\] https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/eap-7.x-messag... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10904) Lower logging level of messages for OpenTracing

by Jan Stourac (JIRA)

[ https://issues.jboss.org/browse/WFLY-10904?page=com.atlassian.jira.plugin... ] Jan Stourac commented on WFLY-10904: ------------------------------------ [~juraci.costa], thank you for the update. I've briefly tried how the logging looks like with current master ({{3c8d65218a7e64126f86708e56c0a21bbf281a97}}). The {{Initialized tracer}} info message is shorter indeed and doesn't pollute the log too much anymore. As I stated before, I still think there is too much information on INFO level. Although, I don't consider this part as a blocker anymore. Just one thing - I noticed that it looks like same information is logged on both INFO and DEBUG level. When I increased logging to debug and deployed jax-rs application, I can see following messages in the server.log: {code} 10:52:11,446 DEBUG [io.undertow.session] (ServerService Thread Pool -- 72) Setting default session timeout to 1800 10:52:11,462 DEBUG [io.undertow.session] (ServerService Thread Pool -- 72) Registered session listener io.undertow.servlet.core.SessionListenerBridge@235e513c 10:52:11,488 DEBUG [io.jaegertracing.thrift.internal.senders.ThriftSenderFactory] (ServerService Thread Pool -- 72) Using the UDP Sender to send spans to the agent. 10:52:11,502 DEBUG [io.jaegertracing.internal.senders.SenderResolver] (ServerService Thread Pool -- 72) Using sender UdpSender() 10:52:11,703 INFO [io.jaegertracing.Configuration] (ServerService Thread Pool -- 72) Initialized tracer=JaegerTracer(version=Java-0.30.6, serviceName=helloworld-rs.war, reporter=RemoteReporter(sender=UdpSender(), closeEnqueueTimeout=1000), sampler=RemoteControlledSampler(maxOperations=2000, manager=HttpSamplingManager(hostPort=localhost:5778), sampler=ProbabilisticSampler(tags={sampler.type=probabilistic, sampler.param=0.001})), tags={hostname=dhcp-10-40-5-80.brq.redhat.com, jaeger.version=Java-0.30.6, ip=10.40.5.80}, zipkinSharedRpcSpan=false, expandExceptionLogs=false) 10:52:11,706 DEBUG [org.wildfly.microprofile.opentracing.smallrye] (ServerService Thread Pool -- 72) WFLYTRAC0004: Registering io.jaegertracing.internal.JaegerTracer as the OpenTracing Tracer 10:52:11,714 DEBUG [org.wildfly.microprofile.opentracing.smallrye] (ServerService Thread Pool -- 72) WFLYTRAC0001: Tracer initialized: JaegerTracer(version=Java-0.30.6, serviceName=helloworld-rs.war, reporter=RemoteReporter(sender=UdpSender(), closeEnqueueTimeout=1000), sampler=RemoteControlledSampler(maxOperations=2000, manager=HttpSamplingManager(hostPort=localhost:5778), sampler=ProbabilisticSampler(tags={sampler.type=probabilistic, sampler.param=0.001})), tags={hostname=dhcp-10-40-5-80.brq.redhat.com, jaeger.version=Java-0.30.6, ip=10.40.5.80}, zipkinSharedRpcSpan=false, expandExceptionLogs=false) 10:52:11,779 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 72) WFLYUT0021: Registered web context: '/helloworld-rs' for server 'default-server' 10:52:11,903 INFO [org.jboss.as.server] (management-handler-thread - 1) WFLYSRV0010: Deployed "helloworld-rs.war" (runtime-name : "helloworld-rs.war") 10:52:11,904 DEBUG [org.jboss.as.server.deployment.scanner] (ServerService Thread Pool -- 72) Updating status after deployment notification for helloworld-rs.war {code} Notice the '{{JaegerTracer(version=Java-0.30.6}}...' part - the same information is logged on both INFO and DEBUG level. I think this is what we don't want. We should either remove the INFO level at all in this case or just provide very brief info like: {code} 10:52:11,703 INFO \[io.jaegertracing.Configuration\] (ServerService Thread Pool -- 72) Initialized tracer for service helloworld-rs.war {code} > Lower logging level of messages for OpenTracing > ----------------------------------------------- > > Key: WFLY-10904 > URL: https://issues.jboss.org/browse/WFLY-10904 > Project: WildFly > Issue Type: Bug > Components: MP OpenTracing > Affects Versions: 14.0.0.Beta2 > Reporter: Jan Stourac > Assignee: Juraci Paixão Kröhling > Priority: Blocker > Fix For: 14.0.0.CR1 > > > Current logging for OpenTracing is quite verbose logging long messages in INFO level, e.g.: > {code} > 17:38:45,359 INFO [io.jaegertracing.internal.senders.SenderResolver] (ServerService Thread Pool -- 28) Using sender UdpSender(udpTransport=ThriftUdpTransport(socket=java.net.DatagramSocket@3e9a2205, receiveBuf=null, receiveOffSet=-1, receiveLength=0)) > 17:38:45,395 INFO [io.jaegertracing.Configuration] (ServerService Thread Pool -- 28) Initialized tracer=JaegerTracer(version=Java-0.30.4, serviceName=deployment.war, reporter=RemoteReporter(queueProcessor=RemoteReporter.QueueProcessor(open=true), sender=UdpSender(udpTransport=ThriftUdpTransport(socket=java.net.DatagramSocket@3e9a2205, receiveBuf=null, receiveOffSet=-1, receiveLength=0)), closeEnqueueTimeout=1000), sampler=RemoteControlledSampler(maxOperations=2000, serviceName=deployment.war, manager=HttpSamplingManager(gson={serializeNulls:false,factories:[Factory[typeHierarchy=com.google.gson.JsonElement,adapter=com.google.gson.internal.bind.TypeAdapters$29@5795d61d], com.google.gson.internal.bind.ObjectTypeAdapter$1@7286f924, com.google.gson.internal.Excluder@10bd7673, Factory[type=java.lang.String,adapter=com.google.gson.internal.bind.TypeAdapters$16@56577ab9], Factory[type=java.lang.Integer+int,adapter=com.google.gson.internal.bind.TypeAdapters$7@2f0b6b50], Factory[type=java.lang.Boolean+boolean,adapter=com.google.gson.internal.bind.TypeAdapters$3@6a01f84c], Factory[type=java.lang.Byte+byte,adapter=com.google.gson.internal.bind.TypeAdapters$5@11f41591], Factory[type=java.lang.Short+short,adapter=com.google.gson.internal.bind.TypeAdapters$6@7c9b37a4], Factory[type=java.lang.Long+long,adapter=com.google.gson.internal.bind.TypeAdapters$11@8be828c], Factory[type=java.lang.Double+double,adapter=com.google.gson.Gson$1@6d18d84f], Factory[type=java.lang.Float+float,adapter=com.google.gson.Gson$2@5c7110e0], Factory[type=java.lang.Number,adapter=com.google.gson.internal.bind.TypeAdapters$14@79f22add], Factory[type=java.util.concurrent.atomic.AtomicInteger,adapter=com.google.gson.TypeAdapter$1@5a47d8d], Factory[type=java.util.concurrent.atomic.AtomicBoolean,adapter=com.google.gson.TypeAdapter$1@2ed507d6], Factory[type=java.util.concurrent.atomic.AtomicLong,adapter=com.google.gson.TypeAdapter$1@7af7f4fc], Factory[type=java.util.concurrent.atomic.AtomicLongArray,adapter=com.google.gson.TypeAdapter$1@123b9dbd], Factory[type=java.util.concurrent.atomic.AtomicIntegerArray,adapter=com.google.gson.TypeAdapter$1@3455c262], Factory[type=java.lang.Character+char,adapter=com.google.gson.internal.bind.TypeAdapters$15@32b89889], Factory[type=java.lang.StringBuilder,adapter=com.google.gson.internal.bind.TypeAdapters$19@772dda36], Factory[type=java.lang.StringBuffer,adapter=com.google.gson.internal.bind.TypeAdapters$20@3935671b], Factory[type=java.math.BigDecimal,adapter=com.google.gson.internal.bind.TypeAdapters$17@23e9f48d], Factory[type=java.math.BigInteger,adapter=com.google.gson.internal.bind.TypeAdapters$18@55634ca9], Factory[type=java.net.URL,adapter=com.google.gson.internal.bind.TypeAdapters$21@4c06d059], Factory[type=java.net.URI,adapter=com.google.gson.internal.bind.TypeAdapters$22@5e997b7d], Factory[type=java.util.UUID,adapter=com.google.gson.internal.bind.TypeAdapters$24@3238a1bf], Factory[type=java.util.Currency,adapter=com.google.gson.TypeAdapter$1@7d71b555], Factory[type=java.util.Locale,adapter=com.google.gson.internal.bind.TypeAdapters$28@70f36ba], Factory[typeHierarchy=java.net.InetAddress,adapter=com.google.gson.internal.bind.TypeAdapters$23@12d8e7b5], Factory[type=java.util.BitSet,adapter=com.google.gson.TypeAdapter$1@659a9908], com.google.gson.internal.bind.DateTypeAdapter$1@153143f3, Factory[type=java.util.Calendar+java.util.GregorianCalendar,adapter=com.google.gson.internal.bind.TypeAdapters$27@6bf50d09], com.google.gson.internal.bind.TimeTypeAdapter$1@3e45ba8d, com.google.gson.internal.bind.SqlDateTypeAdapter$1@f262694, com.google.gson.internal.bind.TypeAdapters$26@1017c258, com.google.gson.internal.bind.ArrayTypeAdapter$1@53c90816, Factory[type=java.lang.Class,adapter=com.google.gson.TypeAdapter$1@40cb5130], com.google.gson.internal.bind.CollectionTypeAdapterFactory@7e67cd3b, com.google.gson.internal.bind.MapTypeAdapterFactory@504cd5ad, com.google.gson.internal.bind.JsonAdapterAnnotationTypeAdapterFactory@4b5efe0a, com.google.gson.internal.bind.TypeAdapters$30@51066480, com.google.gson.internal.bind.ReflectiveTypeAdapterFactory@11c8758e],instanceCreators:{}}, hostPort=localhost:5778), metrics=io.jaegertracing.internal.metrics.Metrics@279f3ba7, sampler=ProbabilisticSampler(positiveSamplingBoundary=9223372036854776, negativeSamplingBoundary=-9223372036854776, samplingRate=0.001, tags={sampler.type=probabilistic, sampler.param=0.001})), ipv4=2130706433, tags={hostname=rhel7-large-74052, jaeger.version=Java-0.30.4, ip=127.0.0.1}, zipkinSharedRpcSpan=false, baggageSetter=io.jaegertracing.internal.baggage.BaggageSetter@1b8d3ff0, expandExceptionLogs=false) > {code} > I think these messages are not useful on INFO level and should be lowered to either DEBUG or TRACE level. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-1501) Release WildFly Elytron 1.1.8.Final

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1501?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse resolved ELY-1501. ----------------------------------- Fix Version/s: 1.1.8.Final (was: 1.7.0.CR1) Resolution: Done > Release WildFly Elytron 1.1.8.Final > ----------------------------------- > > Key: ELY-1501 > URL: https://issues.jboss.org/browse/ELY-1501 > Project: WildFly Elytron > Issue Type: Release > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.1.8.Final > > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10861) MP Health - security enabled, no user yed added, user get info about adding user to access management interface, HTTP code is 200, should be 500

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-10861?page=com.atlassian.jira.plugin... ] Darran Lofthouse commented on WFLY-10861: ----------------------------------------- FYI both examples use WildFly Elytron, PicketBox is not in use at all for the security of the management interfaces. A server restart is not required when referencing the Elytron subsystem configuration directly, the load operation can be invoked on the properties-realm resource: - {noformat} [standalone@localhost:9990 /] ./subsystem=elytron/properties-realm=ApplicationRealm:read-operation-description(name=load) { "outcome" => "success", "result" => { "operation-name" => "load", "description" => "Reload the properties files from the file system.", "request-properties" => {}, "reply-properties" => {}, "read-only" => false, "runtime-only" => true } } {noformat} > MP Health - security enabled, no user yed added, user get info about adding user to access management interface, HTTP code is 200, should be 500 > ------------------------------------------------------------------------------------------------------------------------------------------------ > > Key: WFLY-10861 > URL: https://issues.jboss.org/browse/WFLY-10861 > Project: WildFly > Issue Type: Bug > Components: Management, MP Health > Reporter: Rostislav Svoboda > Assignee: Kabir Khan > Priority: Blocker > Fix For: 14.0.0.CR1 > > > I do {{:write-attribute(name=security-enabled, value=true)}} ++ reload of the server > Note: I didn't add user via {{bin/add-user.sh}} > ---- > Kabir edit: the full command is: > /subsystem=microprofile-health-smallrye:write-attribute(name=security-enabled,value=true) > ---- > When I'm trying to access http://127.0.0.1:9990/health I receive page which is there primarily for web console: > {code} > <h3>Your WildFly Application Server is running.</h3> > <p>However you have <strong>not</strong> yet <strong>added any users</strong> to be able > to access the admin console.</p> > <p>To add a new user execute the <code>add-user.sh</code> script within the bin folder of > your WildFly installation and enter the requested information.</p> > {code} > Can /health endpoint get customized response in case no mgmt user is defined on server side ? > Current response can be little confusing if user is not yet so familiar with WildFly. > -I marked this as minor bug.- ... see comments -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 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 August 2018