[JBoss JIRA] (JGRP-2218) New payload interface
by Pedro Ruivo (Jira)
[ https://issues.redhat.com/browse/JGRP-2218?page=com.atlassian.jira.plugin... ]
Pedro Ruivo commented on JGRP-2218:
-----------------------------------
[~belaban] if I recall correctly, or it was to avoid allocating a new array or to avoid a map lookup for the ISPN command to marshall.
If it was the first one, with the {{ByteMessage}}, I would have to marshall the command and create a new array to populate the {{ByteMessage}}
If it was the second, it would save a map lookup and 2 bytes:
{{ByteMessage}} size: msg_type + headers + address + ispn_command_id (*2 since we wrap the Command into a RpcCommand) + command_payload
{{BackUpMessage}} size: msg_type + headers + address + payload
> New payload interface
> ---------------------
>
> Key: JGRP-2218
> URL: https://issues.redhat.com/browse/JGRP-2218
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 5.0
>
> Attachments: jgrp-2218.jfr, master.jfr
>
>
> h3. Goal
> Change payload in {{Message}} from byte[] arrays to a {{Payload}} interface which can have multiple implementations.
> h3. Reason
> Currently, having to pass a byte[] array to a message leads to unnecessary copying:
> * When an application has a ref to an NIO (direct) {{ByteBuffer}}, the bytes in the byte buffer have to be copied into a byte[] array and then set in the message
> * When the application sends around byte[] arrays, but also wants to add some additional metadata, e.g. type (1000-byte requests/responses), it needs to create a new byte[] array of (say) 1001 bytes and copy the data (1000 bytes) plus the request type (1 byte) into the new copy. Example: {{MPerf}} and {{UPerf}}
> * When an object has to be sent (e.g. in Infinispan), the object has to be marshalled into a byte[] array (first allocation) and then added to the message. With the suggested {{ObjectPayload}} (below), marshalling of the object would occur late, and it would be marshalled directly into the output stream of the bundler, eliminating the byte[] array allocation made by the application.
> h3. Design
> Instead of copying, the application creates an instance of {{Payload}} and sets the payload in {{Message}}. The {{Payload}} is then passed all the way down into the transport where it is marshalled and sent. There can be a number of payload implementations, e.g.
> * {{ByteArrayPayload}}: wraps a byte[] array with an offset and length
> * {{NioDirectPayload}}: wraps an NIO direct {{ByteBuffer}}
> * {{NioHeapPayload}}: wraps an NIO heap-based {{ByteBuffer}}
> * {{CompositePayload}}: wraps multiple Buffers. E.g. type (1 byte) and data (1000 bytes) as described above
> * {{IntPayload}}: a single integer
> * {{ObjectPayload}}: has an Object and a ClassLoader (for reading), plus a Marshaller which know how to marshal the object, this allows for objects to be passed in payloads and they're only marshalled at the end (transport).
> * {{PartialPayload}}: a ref to a {{Payload}}, with an offset and length
> * {{InputStreamPayload}}: has a ref to an input stream and copies data from input- to output stream when marshalling
> The {{Payload}} interface has methods:
> * {{size()}}
> * {{writeTo(DataOutput)}}
> * {{readFrom(DataInput)}}
> * {{getInput()}}: this provides a {{DataInput}} stream for reading from the underlying payload
> and possibly also
> * {{acquire()}} and
> * {{release()}} (for ref-counting)
> * {{copy()}}
> Each payload impl has an ID and it should be possible to register new impls. A {{PayloadFactory}} maintains a mapping between IDs and impl classes.
> When marshalling a {{Payload}}, the ID is written first, followed by the payload's {{writeTo()}} method. When reading payloads, the {{PayloadFactory}} is used to create instances from IDs.
> h4. Fragmentation
> When fragmenting a buffer, the fragments are instances of {{PartialPayload}} which maintains an offset and length over an underlying payload. When marshalling a {{PartialPayload}}, only the part between offset and offset+length is written to the output stream.
> For fragmentation, method {{size()}} is crucial to determine whether a payload needs to be fragmented, or not. If, for example, a payload (e.g. an {{ObjectPayload}}) cannot determine the correct size, it may return {{-1}}. This leads to the {{ObjectPayload}} getting marshalled right away and getting wrapped into a {{ByteArrayPayload}}. So if {{size()}} cannot be determined, we have exactly the same behavior as what's currently done.
> h4. Reference counting
> If we implement ref-counting, then payloads can be reused as soon as the ref-count is 0. For example, when sending a message, the payload's ref-count could be incremented by the app calling {{acquire()}}. (Assuming the message is a unicast message), {{UNICAST3}} would increment the count to 2. This is needed because {{UNICAST3}} might have to retransmit the message if it was lost on the network, and meanwhile the payload cannot be reused (changed). The app calls {{release()}} when the {{JChannel.send()}} call returns, but the payload cannot be reused until {{UNICAST3}} calls {{release()}} as well. This will happen when an {{ACK}} for the given message has been received.
> h4. Payload factory
> When a request is received, the buffer is created from the bytes received on the network, based on the ID. This should be done by asking a {{PayloadFactory}} component for a new buffer. A naive implementation might create a new buffer every time, but a more sophisticated one might use a pool of payloads.
> The {{PayloadFactory}} instance could be replaced by one's own implementation; this allows for an application to control the lifecycle of payloads: thus the creation of buffers by the application and of payloads received over the network can be controlled by the same payload management impl.
> h4. Symmetry
> When sending a {{CompositePayload}} of a 500 byte {{ByteArrayPayload}} and a 1000 byte {{NioDirectPayload}}, would we want to also get the same {{CompositePayload}} consisting of 2 payloads on the receiver side, or would we want to combine the 2 payloads into one and make the 2 payloads refer to the same combined byte[] array (or NIO buffer)? Should this be made configurable?
> h4. ObjectPayload
> If ObjectPayload cannot determine the size of the serialized data, it should return {{-1}}. This means that {{Message.setPayload(ObjectPayload)}} would right away serialize {{ObjectPayload}} into {{ByteArrayPayload}}.
> This means we do have the {{byte[]}} array creation (same as now), but for object payloads which do implement {{size()}} correctly, we could still do late serialization.
> h5. ObjectPayload and fragmentation
> {{FRAG3}} could decorate {{ObjectPayload}} with a fragmentation payload, which generates fragments on serialization and sends them down the stack.
> h4. Misc
> * Since this issue includes API changes, the version will be 5.0
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (WFLY-11566) ConstraintDeclarationException on JAX-RS/EJB Methods with List/Set query parameter
by Tomasz Adamski (Jira)
[ https://issues.redhat.com/browse/WFLY-11566?page=com.atlassian.jira.plugi... ]
Tomasz Adamski commented on WFLY-11566:
---------------------------------------
I have implemented EJB proxy bean normalizer and registered it in Weld:
https://github.com/tadamski/wildfly/tree/WFLY-11566
[~manovotn] could you please take a look whether the implementation is ok from Weld point of view.
[~guillaume.smet] Would you be able to use the provided normalizer?
> 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, 6 months
[JBoss JIRA] (JGRP-2426) JChannel: remove stats
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2426?page=com.atlassian.jira.plugin... ]
Bela Ban resolved JGRP-2426.
----------------------------
Resolution: Done
> JChannel: remove stats
> ----------------------
>
> Key: JGRP-2426
> URL: https://issues.redhat.com/browse/JGRP-2426
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Optional
> Fix For: 5.0
>
>
> Remove stats such as {{sent_msgs, received_msgs, sent_bytes, received_bytes}} from JChannel. It may be costly to maintain those stats (e.g. {{Message.getLength()}} in 5.0), and they're already maintained by the transport (or {{STATS}}).
> For ForkChannels, these stats would be gone, too, and would not be maintained for each fork channel separately...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (JGRP-2218) New payload interface
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2218?page=com.atlassian.jira.plugin... ]
Bela Ban commented on JGRP-2218:
--------------------------------
[~pruivo] Sorry for the delay (+1 year!) :-)
Why did you write a custom message? Was the {{BytesMessage}} not good enough? {{BackUpMessage} doesn't carry a lot of data, so IMO {{BytesMessage}} could have been used.
Or was the idea to see how easy it was to implement a custom message?
> New payload interface
> ---------------------
>
> Key: JGRP-2218
> URL: https://issues.redhat.com/browse/JGRP-2218
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 5.0
>
> Attachments: jgrp-2218.jfr, master.jfr
>
>
> h3. Goal
> Change payload in {{Message}} from byte[] arrays to a {{Payload}} interface which can have multiple implementations.
> h3. Reason
> Currently, having to pass a byte[] array to a message leads to unnecessary copying:
> * When an application has a ref to an NIO (direct) {{ByteBuffer}}, the bytes in the byte buffer have to be copied into a byte[] array and then set in the message
> * When the application sends around byte[] arrays, but also wants to add some additional metadata, e.g. type (1000-byte requests/responses), it needs to create a new byte[] array of (say) 1001 bytes and copy the data (1000 bytes) plus the request type (1 byte) into the new copy. Example: {{MPerf}} and {{UPerf}}
> * When an object has to be sent (e.g. in Infinispan), the object has to be marshalled into a byte[] array (first allocation) and then added to the message. With the suggested {{ObjectPayload}} (below), marshalling of the object would occur late, and it would be marshalled directly into the output stream of the bundler, eliminating the byte[] array allocation made by the application.
> h3. Design
> Instead of copying, the application creates an instance of {{Payload}} and sets the payload in {{Message}}. The {{Payload}} is then passed all the way down into the transport where it is marshalled and sent. There can be a number of payload implementations, e.g.
> * {{ByteArrayPayload}}: wraps a byte[] array with an offset and length
> * {{NioDirectPayload}}: wraps an NIO direct {{ByteBuffer}}
> * {{NioHeapPayload}}: wraps an NIO heap-based {{ByteBuffer}}
> * {{CompositePayload}}: wraps multiple Buffers. E.g. type (1 byte) and data (1000 bytes) as described above
> * {{IntPayload}}: a single integer
> * {{ObjectPayload}}: has an Object and a ClassLoader (for reading), plus a Marshaller which know how to marshal the object, this allows for objects to be passed in payloads and they're only marshalled at the end (transport).
> * {{PartialPayload}}: a ref to a {{Payload}}, with an offset and length
> * {{InputStreamPayload}}: has a ref to an input stream and copies data from input- to output stream when marshalling
> The {{Payload}} interface has methods:
> * {{size()}}
> * {{writeTo(DataOutput)}}
> * {{readFrom(DataInput)}}
> * {{getInput()}}: this provides a {{DataInput}} stream for reading from the underlying payload
> and possibly also
> * {{acquire()}} and
> * {{release()}} (for ref-counting)
> * {{copy()}}
> Each payload impl has an ID and it should be possible to register new impls. A {{PayloadFactory}} maintains a mapping between IDs and impl classes.
> When marshalling a {{Payload}}, the ID is written first, followed by the payload's {{writeTo()}} method. When reading payloads, the {{PayloadFactory}} is used to create instances from IDs.
> h4. Fragmentation
> When fragmenting a buffer, the fragments are instances of {{PartialPayload}} which maintains an offset and length over an underlying payload. When marshalling a {{PartialPayload}}, only the part between offset and offset+length is written to the output stream.
> For fragmentation, method {{size()}} is crucial to determine whether a payload needs to be fragmented, or not. If, for example, a payload (e.g. an {{ObjectPayload}}) cannot determine the correct size, it may return {{-1}}. This leads to the {{ObjectPayload}} getting marshalled right away and getting wrapped into a {{ByteArrayPayload}}. So if {{size()}} cannot be determined, we have exactly the same behavior as what's currently done.
> h4. Reference counting
> If we implement ref-counting, then payloads can be reused as soon as the ref-count is 0. For example, when sending a message, the payload's ref-count could be incremented by the app calling {{acquire()}}. (Assuming the message is a unicast message), {{UNICAST3}} would increment the count to 2. This is needed because {{UNICAST3}} might have to retransmit the message if it was lost on the network, and meanwhile the payload cannot be reused (changed). The app calls {{release()}} when the {{JChannel.send()}} call returns, but the payload cannot be reused until {{UNICAST3}} calls {{release()}} as well. This will happen when an {{ACK}} for the given message has been received.
> h4. Payload factory
> When a request is received, the buffer is created from the bytes received on the network, based on the ID. This should be done by asking a {{PayloadFactory}} component for a new buffer. A naive implementation might create a new buffer every time, but a more sophisticated one might use a pool of payloads.
> The {{PayloadFactory}} instance could be replaced by one's own implementation; this allows for an application to control the lifecycle of payloads: thus the creation of buffers by the application and of payloads received over the network can be controlled by the same payload management impl.
> h4. Symmetry
> When sending a {{CompositePayload}} of a 500 byte {{ByteArrayPayload}} and a 1000 byte {{NioDirectPayload}}, would we want to also get the same {{CompositePayload}} consisting of 2 payloads on the receiver side, or would we want to combine the 2 payloads into one and make the 2 payloads refer to the same combined byte[] array (or NIO buffer)? Should this be made configurable?
> h4. ObjectPayload
> If ObjectPayload cannot determine the size of the serialized data, it should return {{-1}}. This means that {{Message.setPayload(ObjectPayload)}} would right away serialize {{ObjectPayload}} into {{ByteArrayPayload}}.
> This means we do have the {{byte[]}} array creation (same as now), but for object payloads which do implement {{size()}} correctly, we could still do late serialization.
> h5. ObjectPayload and fragmentation
> {{FRAG3}} could decorate {{ObjectPayload}} with a fragmentation payload, which generates fragments on serialization and sends them down the stack.
> h4. Misc
> * Since this issue includes API changes, the version will be 5.0
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (WFWIP-297) Base64 encoded JWKS from a file fails to resolve
by Darran Lofthouse (Jira)
[ https://issues.redhat.com/browse/WFWIP-297?page=com.atlassian.jira.plugin... ]
Darran Lofthouse commented on WFWIP-297:
----------------------------------------
The error is a little confusing, the specification requires the implementation to attempt to load as a pem before it gets to Base64 decoding so the message logged is just for information.
> Base64 encoded JWKS from a file fails to resolve
> ------------------------------------------------
>
> Key: WFWIP-297
> URL: https://issues.redhat.com/browse/WFWIP-297
> Project: WildFly WIP
> Issue Type: Bug
> Components: MP JWT
> Reporter: Jan Kasik
> Assignee: Darran Lofthouse
> Priority: Blocker
>
> JWKS supplied through {{mp.jwt.verify.publickey.location}} fails to resolve when encoded to Base64 string. Seems like the SmallRye is trying to parse the file content as a PEM key. See excerpt from log.
> This breaks specification compatibility because according to MP-JWT 1.1 which specifies in section 9.2.3:
> {quote}
> The JWKS may be supplied in plain JSON or Base64 URL encoded JSON format.
> {quote}
> {code}
> 12:04:02,323 DEBUG [io.smallrye.jwt.config.JWTAuthContextInfoProvider] (default task-1) init, mpJwtPublicKey=NONE, mpJwtIssuer=issuer, mpJwtLocation=META-INF/keys.jwks
> ...
> 12:04:02,326 DEBUG [io.smallrye.jwt.auth.principal.KeyLocationResolver] (default task-1) Trying to create a key from the encoded PEM key...
> 12:04:02,326 DEBUG [io.smallrye.jwt.auth.principal.KeyLocationResolver] (default task-1) Failed to create a key from the encoded PEM key: java.security.spec.InvalidKeySpecException: java.security.InvalidKeyException: invalid key format
> at sun.security.rsa.RSAKeyFactory.engineGeneratePublic(RSAKeyFactory.java:205)
> ...
> Caused by: org.jose4j.jwt.consumer.InvalidJwtException: JWT processing failed. Additional details: [[17] Unable to process JOSE object (cause: org.jose4j.lang.UnresolvableKeyException: Failed to resolve a key from: META-INF/keys.jwks): JsonWebSignature{"kid":"blue-key","typ":"JWT","alg":"RS256"}->eyJraWQiOiJibHVlLWtleSIsInR5cCI6IkpXVCIsImFsZyI6IlJTMjU2In0=.eyJqdGkiOiJmMjc2YjVhYS0zMGZiLTQ4MWEtYjk0MS0xNDJhNjBmMGZiNjMiLCJzdWIiOiJGQUtFX1VTRVIiLCJncm91cHMiOlsiZ3JvdXAyIiwiZ3JvdXAxIl0sImF1ZCI6Im1pY3JvcHJvZmlsZS1qd3QtdGVzdHN1aXRlIiwiaXNzIjoiaXNzdWVyIiwiaWF0IjoxNTc4NjU0MjQxLCJleHAiOjE1Nzg2NTc4NDEsInVwbiI6IkZBS0VfVVNFUiIsInByZWZlcnJlZF91c2VybmFtZSI6IkZBS0VfVVNFUiJ9.AEe5kEr0s2p4CDbqwHPRwLziktwABX0OmM2aCEgdUF71eXlCu72ZhwNYDac3NyXMNhWp7k_xxX0I20EIbwBQsiJFmQZgqXZuK44Kc3jnMWDHT8kdPU03G3rIZBA2aiYsVy2gZ67gG_VnFx453fqHOxBIXtDsy1mzdrHwHLgY5iOklAodlv0Oe-H2Qik8oEj_k2R0a9b9E9pu7RHkono1d8TIuufwuJOIv7QSSo9w5vC74mYvd_RhZKvLACLx4ry9KVWamtDp_hMpclAqeUCjvcL-2VMI1VaDE3ZE7XonNMbCjwjxLzTtRLwVZAoYiD3eXSYkFTLGUT4BtfE8P5B3Uvb6pjf50e_EgYePAwvY-PFBFPB54BWcO433B3Pk411XYHUZweQfMHumateCwPJXZXcCoWjGj8ujHH3Leje_9gswzxDxd0JI2zjJEwasTBMixC65Jz9W5lKwQVVTHULP49KIbRXFkU52gTizMZNaABSGI48naMHr0Xu42yDKSrwkJTO3zNW1kSVi-3BMU6fmUxK8BF3xy2VgDgg_Rpmx_eQCBrGE36J-swHZbAPmiMKYT96D3rZHcMHa1oj784Em_h1p3sfr27ZCd0vpO7rOmHWzk1SWnb5GkySuuedwBQL-K5VT3mytqwFOg_UXZMkxSEGbn37WRzMa2KxfXKgRA-A=]
> at org.jose4j.jwt.consumer.JwtConsumer.processContext(JwtConsumer.java:271)
> at org.jose4j.jwt.consumer.JwtConsumer.process(JwtConsumer.java:433)
> at io.smallrye.jwt.auth.principal.DefaultJWTTokenParser.parse(DefaultJWTTokenParser.java:88)
> ... 40 more
> Caused by: org.jose4j.lang.UnresolvableKeyException: Failed to resolve a key from: META-INF/keys.jwks
> at io.smallrye.jwt.auth.principal.KeyLocationResolver.resolveKey(KeyLocationResolver.java:101)
> at org.jose4j.jwt.consumer.JwtConsumer.processContext(JwtConsumer.java:213)
> ... 42 more
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (DROOLS-4925) forall pattern with date constraint fail to match
by Mario Fusco (Jira)
[ https://issues.redhat.com/browse/DROOLS-4925?page=com.atlassian.jira.plug... ]
Mario Fusco updated DROOLS-4925:
--------------------------------
Sprint: 2020 Week 01-03 (from Dec 30)
> forall pattern with date constraint fail to match
> -------------------------------------------------
>
> Key: DROOLS-4925
> URL: https://issues.redhat.com/browse/DROOLS-4925
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.29.0.Final, 7.30.0.Final, 7.31.0.Final
> Reporter: Matteo Casalino
> Assignee: Mario Fusco
> Priority: Major
> Attachments: forall-date-constraint.tgz, network.png
>
>
> As of Drools 7.29.0.Final, {{forall}} patterns containing equality constraints on dates won't match as expected.
> For instance, given the following drl
> {noformat}
> declare Fact
> d : java.util.Date
> end
>
> rule "forall with date"
> when
> forall(Fact(d == "01-Jan-2020"))
> then
> end
> {noformat}
> and the following working memory:
> {noformat}
> Fact( d=Wed Jan 01 00:00:00 CET 2020 )
> Fact( d=Wed Jan 01 00:00:00 CET 2020 )
> Fact( d=Wed Jan 01 00:00:00 CET 2020 )
> {noformat}
> Drools <= 7.28.0.Final will fire 1 rule, whereas Drools >= 7.29.0.Final will fire 0 rules.
> This is probably due to the fact that the rewriting implemented in [DROOLS-4632] fails to negate the constraint on the date, as visible in the attached picture of the network.
> I am wondering whether there would be an equivalent problem with any constraint on dates (e.g., >=, <=, ...)?
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (WFWIP-294) JWT is rejected if signature matching public key is not first in JWK set
by Jan Kasik (Jira)
[ https://issues.redhat.com/browse/WFWIP-294?page=com.atlassian.jira.plugin... ]
Jan Kasik updated WFWIP-294:
----------------------------
Description:
When public key on remote server is configured to be JWK set, the JWT which has correctly configured key ID to aim on matching public key from the set is rejected if matching public key is not on first position in the set array.
This behavior is reproducible in the case the JWKS is set via {{mp.jwt.verify.publickey}} property.
Attached is "flawed" key set with "blue-key" placed on first position in array when JOSE header has {{kid}} set to "orange-key" and JWT itself is signed by private key which is from "orange" key pair.
This breaks MP-JWT specification compatibility because the MP-JWT 1.1 states:
In section 9.2.3:
{quote}
If the incoming JWT uses the kid header field and there is a key in the supplied JWK set with the same kid, only that key is considered for verification of the JWT’s digital signature.
{quote}
In section 4.1:
{quote}
kid - This JOSE header parameter is a hint indicating which key was used to secure the JWT. RFC7515, Section-4.1.4
{quote}
And the RFC7515, Section-4.1.4 states:
{quote}
When used with a JWK, the "kid" value is used to match a JWK "kid" parameter value.
{quote}
was:
When public key on remote server is configured to be JWK set, the JWT which has correctly configured key ID to aim on matching public key from the set is rejected if matching public key is not on first position in the set array.
This behavior is reproducible in the case the JWKS is set via {{mp.jwt.verify.publickey}} property.
Attached is "flawed" key set with "blue-key" placed on first position in array when JOSE header has {{kid}} set to "orange-key" and JWT itself is signed by private key which is from "orange" key pair.
This breaks MP-JWT specification compatibility because the MP-JWT 1.1 states:
In section 9.2.3:
{quote}
If the incoming JWT uses the kid header field and there is a key in the supplied JWK set with the same kid, only that key is considered for verification of the JWT’s digital signature.
{quote}
> JWT is rejected if signature matching public key is not first in JWK set
> ------------------------------------------------------------------------
>
> Key: WFWIP-294
> URL: https://issues.redhat.com/browse/WFWIP-294
> Project: WildFly WIP
> Issue Type: Bug
> Components: MP JWT
> Reporter: Jan Kasik
> Assignee: Darran Lofthouse
> Priority: Blocker
> Attachments: jwks.json, jwt.base64
>
>
> When public key on remote server is configured to be JWK set, the JWT which has correctly configured key ID to aim on matching public key from the set is rejected if matching public key is not on first position in the set array.
> This behavior is reproducible in the case the JWKS is set via {{mp.jwt.verify.publickey}} property.
> Attached is "flawed" key set with "blue-key" placed on first position in array when JOSE header has {{kid}} set to "orange-key" and JWT itself is signed by private key which is from "orange" key pair.
> This breaks MP-JWT specification compatibility because the MP-JWT 1.1 states:
> In section 9.2.3:
> {quote}
> If the incoming JWT uses the kid header field and there is a key in the supplied JWK set with the same kid, only that key is considered for verification of the JWT’s digital signature.
> {quote}
> In section 4.1:
> {quote}
> kid - This JOSE header parameter is a hint indicating which key was used to secure the JWT. RFC7515, Section-4.1.4
> {quote}
> And the RFC7515, Section-4.1.4 states:
> {quote}
> When used with a JWK, the "kid" value is used to match a JWK "kid" parameter value.
> {quote}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (DROOLS-4925) forall pattern with date constraint fail to match
by Matteo Casalino (Jira)
Matteo Casalino created DROOLS-4925:
---------------------------------------
Summary: forall pattern with date constraint fail to match
Key: DROOLS-4925
URL: https://issues.redhat.com/browse/DROOLS-4925
Project: Drools
Issue Type: Bug
Components: core engine
Affects Versions: 7.31.0.Final, 7.30.0.Final, 7.29.0.Final
Reporter: Matteo Casalino
Assignee: Mario Fusco
Attachments: forall-date-constraint.tgz, network.png
As of Drools 7.29.0.Final, {{forall}} patterns containing equality constraints on dates won't match as expected.
For instance, given the following drl
{noformat}
declare Fact
d : java.util.Date
end
rule "forall with date"
when
forall(Fact(d == "01-Jan-2020"))
then
end
{noformat}
and the following working memory:
{noformat}
Fact( d=Wed Jan 01 00:00:00 CET 2020 )
Fact( d=Wed Jan 01 00:00:00 CET 2020 )
Fact( d=Wed Jan 01 00:00:00 CET 2020 )
{noformat}
Drools <= 7.28.0.Final will fire 1 rule, whereas Drools >= 7.29.0.Final will fire 0 rules.
This is probably due to the fact that the rewriting implemented in [DROOLS-4632] fails to negate the constraint on the date, as visible in the attached picture of the network.
I am wondering whether there would be an equivalent problem with any constraint on dates (e.g., >=, <=, ...)?
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (WFWIP-294) JWT is rejected if signature matching public key is not first in JWK set
by Jan Kasik (Jira)
[ https://issues.redhat.com/browse/WFWIP-294?page=com.atlassian.jira.plugin... ]
Jan Kasik updated WFWIP-294:
----------------------------
Description:
When public key on remote server is configured to be JWK set, the JWT which has correctly configured key ID to aim on matching public key from the set is rejected if matching public key is not on first position in the set array.
This behavior is reproducible in the case the JWKS is set via {{mp.jwt.verify.publickey}} property.
Attached is "flawed" key set with "blue-key" placed on first position in array when JOSE header has {{kid}} set to "orange-key" and JWT itself is signed by private key which is from "orange" key pair.
This breaks MP-JWT specification compatibility because the MP-JWT 1.1 states:
In section 9.2.3:
{quote}
If the incoming JWT uses the kid header field and there is a key in the supplied JWK set with the same kid, only that key is considered for verification of the JWT’s digital signature.
{quote}
was:
When public key on remote server is configured to be JWK set, the JWT which has correctly configured key ID to aim on matching public key from the set is rejected if matching public key is not on first position in the set array.
This behavior is reproducible in the case the JWKS is set via {{mp.jwt.verify.publickey}} property.
Attached is "flawed" key set with "blue-key" placed on first position in array when JOSE header has {{kid}} set to "orange-key" and JWT itself is signed by private key which is from "orange" key pair.
> JWT is rejected if signature matching public key is not first in JWK set
> ------------------------------------------------------------------------
>
> Key: WFWIP-294
> URL: https://issues.redhat.com/browse/WFWIP-294
> Project: WildFly WIP
> Issue Type: Bug
> Components: MP JWT
> Reporter: Jan Kasik
> Assignee: Darran Lofthouse
> Priority: Blocker
> Attachments: jwks.json, jwt.base64
>
>
> When public key on remote server is configured to be JWK set, the JWT which has correctly configured key ID to aim on matching public key from the set is rejected if matching public key is not on first position in the set array.
> This behavior is reproducible in the case the JWKS is set via {{mp.jwt.verify.publickey}} property.
> Attached is "flawed" key set with "blue-key" placed on first position in array when JOSE header has {{kid}} set to "orange-key" and JWT itself is signed by private key which is from "orange" key pair.
> This breaks MP-JWT specification compatibility because the MP-JWT 1.1 states:
> In section 9.2.3:
> {quote}
> If the incoming JWT uses the kid header field and there is a key in the supplied JWK set with the same kid, only that key is considered for verification of the JWT’s digital signature.
> {quote}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (WFWIP-297) Base64 encoded JWKS from a file fails to resolve
by Jan Kasik (Jira)
[ https://issues.redhat.com/browse/WFWIP-297?page=com.atlassian.jira.plugin... ]
Jan Kasik updated WFWIP-297:
----------------------------
Description:
JWKS supplied through {{mp.jwt.verify.publickey.location}} fails to resolve when encoded to Base64 string. Seems like the SmallRye is trying to parse the file content as a PEM key. See excerpt from log.
This breaks specification compatibility because according to MP-JWT 1.1 which specifies in section 9.2.3:
{quote}
The JWKS may be supplied in plain JSON or Base64 URL encoded JSON format.
{quote}
{code}
12:04:02,323 DEBUG [io.smallrye.jwt.config.JWTAuthContextInfoProvider] (default task-1) init, mpJwtPublicKey=NONE, mpJwtIssuer=issuer, mpJwtLocation=META-INF/keys.jwks
...
12:04:02,326 DEBUG [io.smallrye.jwt.auth.principal.KeyLocationResolver] (default task-1) Trying to create a key from the encoded PEM key...
12:04:02,326 DEBUG [io.smallrye.jwt.auth.principal.KeyLocationResolver] (default task-1) Failed to create a key from the encoded PEM key: java.security.spec.InvalidKeySpecException: java.security.InvalidKeyException: invalid key format
at sun.security.rsa.RSAKeyFactory.engineGeneratePublic(RSAKeyFactory.java:205)
...
Caused by: org.jose4j.jwt.consumer.InvalidJwtException: JWT processing failed. Additional details: [[17] Unable to process JOSE object (cause: org.jose4j.lang.UnresolvableKeyException: Failed to resolve a key from: META-INF/keys.jwks): JsonWebSignature{"kid":"blue-key","typ":"JWT","alg":"RS256"}->eyJraWQiOiJibHVlLWtleSIsInR5cCI6IkpXVCIsImFsZyI6IlJTMjU2In0=.eyJqdGkiOiJmMjc2YjVhYS0zMGZiLTQ4MWEtYjk0MS0xNDJhNjBmMGZiNjMiLCJzdWIiOiJGQUtFX1VTRVIiLCJncm91cHMiOlsiZ3JvdXAyIiwiZ3JvdXAxIl0sImF1ZCI6Im1pY3JvcHJvZmlsZS1qd3QtdGVzdHN1aXRlIiwiaXNzIjoiaXNzdWVyIiwiaWF0IjoxNTc4NjU0MjQxLCJleHAiOjE1Nzg2NTc4NDEsInVwbiI6IkZBS0VfVVNFUiIsInByZWZlcnJlZF91c2VybmFtZSI6IkZBS0VfVVNFUiJ9.AEe5kEr0s2p4CDbqwHPRwLziktwABX0OmM2aCEgdUF71eXlCu72ZhwNYDac3NyXMNhWp7k_xxX0I20EIbwBQsiJFmQZgqXZuK44Kc3jnMWDHT8kdPU03G3rIZBA2aiYsVy2gZ67gG_VnFx453fqHOxBIXtDsy1mzdrHwHLgY5iOklAodlv0Oe-H2Qik8oEj_k2R0a9b9E9pu7RHkono1d8TIuufwuJOIv7QSSo9w5vC74mYvd_RhZKvLACLx4ry9KVWamtDp_hMpclAqeUCjvcL-2VMI1VaDE3ZE7XonNMbCjwjxLzTtRLwVZAoYiD3eXSYkFTLGUT4BtfE8P5B3Uvb6pjf50e_EgYePAwvY-PFBFPB54BWcO433B3Pk411XYHUZweQfMHumateCwPJXZXcCoWjGj8ujHH3Leje_9gswzxDxd0JI2zjJEwasTBMixC65Jz9W5lKwQVVTHULP49KIbRXFkU52gTizMZNaABSGI48naMHr0Xu42yDKSrwkJTO3zNW1kSVi-3BMU6fmUxK8BF3xy2VgDgg_Rpmx_eQCBrGE36J-swHZbAPmiMKYT96D3rZHcMHa1oj784Em_h1p3sfr27ZCd0vpO7rOmHWzk1SWnb5GkySuuedwBQL-K5VT3mytqwFOg_UXZMkxSEGbn37WRzMa2KxfXKgRA-A=]
at org.jose4j.jwt.consumer.JwtConsumer.processContext(JwtConsumer.java:271)
at org.jose4j.jwt.consumer.JwtConsumer.process(JwtConsumer.java:433)
at io.smallrye.jwt.auth.principal.DefaultJWTTokenParser.parse(DefaultJWTTokenParser.java:88)
... 40 more
Caused by: org.jose4j.lang.UnresolvableKeyException: Failed to resolve a key from: META-INF/keys.jwks
at io.smallrye.jwt.auth.principal.KeyLocationResolver.resolveKey(KeyLocationResolver.java:101)
at org.jose4j.jwt.consumer.JwtConsumer.processContext(JwtConsumer.java:213)
... 42 more
{code}
was:
JWKS supplied through {{mp.jwt.verify.publickey.location}} fails to resolve when encoded to Base64 string. Seems like the SmallRye is trying to parse the file content as a PEM key. See excerpt from log.
{code}
12:04:02,323 DEBUG [io.smallrye.jwt.config.JWTAuthContextInfoProvider] (default task-1) init, mpJwtPublicKey=NONE, mpJwtIssuer=issuer, mpJwtLocation=META-INF/keys.jwks
...
12:04:02,326 DEBUG [io.smallrye.jwt.auth.principal.KeyLocationResolver] (default task-1) Trying to create a key from the encoded PEM key...
12:04:02,326 DEBUG [io.smallrye.jwt.auth.principal.KeyLocationResolver] (default task-1) Failed to create a key from the encoded PEM key: java.security.spec.InvalidKeySpecException: java.security.InvalidKeyException: invalid key format
at sun.security.rsa.RSAKeyFactory.engineGeneratePublic(RSAKeyFactory.java:205)
...
Caused by: org.jose4j.jwt.consumer.InvalidJwtException: JWT processing failed. Additional details: [[17] Unable to process JOSE object (cause: org.jose4j.lang.UnresolvableKeyException: Failed to resolve a key from: META-INF/keys.jwks): JsonWebSignature{"kid":"blue-key","typ":"JWT","alg":"RS256"}->eyJraWQiOiJibHVlLWtleSIsInR5cCI6IkpXVCIsImFsZyI6IlJTMjU2In0=.eyJqdGkiOiJmMjc2YjVhYS0zMGZiLTQ4MWEtYjk0MS0xNDJhNjBmMGZiNjMiLCJzdWIiOiJGQUtFX1VTRVIiLCJncm91cHMiOlsiZ3JvdXAyIiwiZ3JvdXAxIl0sImF1ZCI6Im1pY3JvcHJvZmlsZS1qd3QtdGVzdHN1aXRlIiwiaXNzIjoiaXNzdWVyIiwiaWF0IjoxNTc4NjU0MjQxLCJleHAiOjE1Nzg2NTc4NDEsInVwbiI6IkZBS0VfVVNFUiIsInByZWZlcnJlZF91c2VybmFtZSI6IkZBS0VfVVNFUiJ9.AEe5kEr0s2p4CDbqwHPRwLziktwABX0OmM2aCEgdUF71eXlCu72ZhwNYDac3NyXMNhWp7k_xxX0I20EIbwBQsiJFmQZgqXZuK44Kc3jnMWDHT8kdPU03G3rIZBA2aiYsVy2gZ67gG_VnFx453fqHOxBIXtDsy1mzdrHwHLgY5iOklAodlv0Oe-H2Qik8oEj_k2R0a9b9E9pu7RHkono1d8TIuufwuJOIv7QSSo9w5vC74mYvd_RhZKvLACLx4ry9KVWamtDp_hMpclAqeUCjvcL-2VMI1VaDE3ZE7XonNMbCjwjxLzTtRLwVZAoYiD3eXSYkFTLGUT4BtfE8P5B3Uvb6pjf50e_EgYePAwvY-PFBFPB54BWcO433B3Pk411XYHUZweQfMHumateCwPJXZXcCoWjGj8ujHH3Leje_9gswzxDxd0JI2zjJEwasTBMixC65Jz9W5lKwQVVTHULP49KIbRXFkU52gTizMZNaABSGI48naMHr0Xu42yDKSrwkJTO3zNW1kSVi-3BMU6fmUxK8BF3xy2VgDgg_Rpmx_eQCBrGE36J-swHZbAPmiMKYT96D3rZHcMHa1oj784Em_h1p3sfr27ZCd0vpO7rOmHWzk1SWnb5GkySuuedwBQL-K5VT3mytqwFOg_UXZMkxSEGbn37WRzMa2KxfXKgRA-A=]
at org.jose4j.jwt.consumer.JwtConsumer.processContext(JwtConsumer.java:271)
at org.jose4j.jwt.consumer.JwtConsumer.process(JwtConsumer.java:433)
at io.smallrye.jwt.auth.principal.DefaultJWTTokenParser.parse(DefaultJWTTokenParser.java:88)
... 40 more
Caused by: org.jose4j.lang.UnresolvableKeyException: Failed to resolve a key from: META-INF/keys.jwks
at io.smallrye.jwt.auth.principal.KeyLocationResolver.resolveKey(KeyLocationResolver.java:101)
at org.jose4j.jwt.consumer.JwtConsumer.processContext(JwtConsumer.java:213)
... 42 more
{code}
> Base64 encoded JWKS from a file fails to resolve
> ------------------------------------------------
>
> Key: WFWIP-297
> URL: https://issues.redhat.com/browse/WFWIP-297
> Project: WildFly WIP
> Issue Type: Bug
> Components: MP JWT
> Reporter: Jan Kasik
> Assignee: Darran Lofthouse
> Priority: Blocker
>
> JWKS supplied through {{mp.jwt.verify.publickey.location}} fails to resolve when encoded to Base64 string. Seems like the SmallRye is trying to parse the file content as a PEM key. See excerpt from log.
> This breaks specification compatibility because according to MP-JWT 1.1 which specifies in section 9.2.3:
> {quote}
> The JWKS may be supplied in plain JSON or Base64 URL encoded JSON format.
> {quote}
> {code}
> 12:04:02,323 DEBUG [io.smallrye.jwt.config.JWTAuthContextInfoProvider] (default task-1) init, mpJwtPublicKey=NONE, mpJwtIssuer=issuer, mpJwtLocation=META-INF/keys.jwks
> ...
> 12:04:02,326 DEBUG [io.smallrye.jwt.auth.principal.KeyLocationResolver] (default task-1) Trying to create a key from the encoded PEM key...
> 12:04:02,326 DEBUG [io.smallrye.jwt.auth.principal.KeyLocationResolver] (default task-1) Failed to create a key from the encoded PEM key: java.security.spec.InvalidKeySpecException: java.security.InvalidKeyException: invalid key format
> at sun.security.rsa.RSAKeyFactory.engineGeneratePublic(RSAKeyFactory.java:205)
> ...
> Caused by: org.jose4j.jwt.consumer.InvalidJwtException: JWT processing failed. Additional details: [[17] Unable to process JOSE object (cause: org.jose4j.lang.UnresolvableKeyException: Failed to resolve a key from: META-INF/keys.jwks): JsonWebSignature{"kid":"blue-key","typ":"JWT","alg":"RS256"}->eyJraWQiOiJibHVlLWtleSIsInR5cCI6IkpXVCIsImFsZyI6IlJTMjU2In0=.eyJqdGkiOiJmMjc2YjVhYS0zMGZiLTQ4MWEtYjk0MS0xNDJhNjBmMGZiNjMiLCJzdWIiOiJGQUtFX1VTRVIiLCJncm91cHMiOlsiZ3JvdXAyIiwiZ3JvdXAxIl0sImF1ZCI6Im1pY3JvcHJvZmlsZS1qd3QtdGVzdHN1aXRlIiwiaXNzIjoiaXNzdWVyIiwiaWF0IjoxNTc4NjU0MjQxLCJleHAiOjE1Nzg2NTc4NDEsInVwbiI6IkZBS0VfVVNFUiIsInByZWZlcnJlZF91c2VybmFtZSI6IkZBS0VfVVNFUiJ9.AEe5kEr0s2p4CDbqwHPRwLziktwABX0OmM2aCEgdUF71eXlCu72ZhwNYDac3NyXMNhWp7k_xxX0I20EIbwBQsiJFmQZgqXZuK44Kc3jnMWDHT8kdPU03G3rIZBA2aiYsVy2gZ67gG_VnFx453fqHOxBIXtDsy1mzdrHwHLgY5iOklAodlv0Oe-H2Qik8oEj_k2R0a9b9E9pu7RHkono1d8TIuufwuJOIv7QSSo9w5vC74mYvd_RhZKvLACLx4ry9KVWamtDp_hMpclAqeUCjvcL-2VMI1VaDE3ZE7XonNMbCjwjxLzTtRLwVZAoYiD3eXSYkFTLGUT4BtfE8P5B3Uvb6pjf50e_EgYePAwvY-PFBFPB54BWcO433B3Pk411XYHUZweQfMHumateCwPJXZXcCoWjGj8ujHH3Leje_9gswzxDxd0JI2zjJEwasTBMixC65Jz9W5lKwQVVTHULP49KIbRXFkU52gTizMZNaABSGI48naMHr0Xu42yDKSrwkJTO3zNW1kSVi-3BMU6fmUxK8BF3xy2VgDgg_Rpmx_eQCBrGE36J-swHZbAPmiMKYT96D3rZHcMHa1oj784Em_h1p3sfr27ZCd0vpO7rOmHWzk1SWnb5GkySuuedwBQL-K5VT3mytqwFOg_UXZMkxSEGbn37WRzMa2KxfXKgRA-A=]
> at org.jose4j.jwt.consumer.JwtConsumer.processContext(JwtConsumer.java:271)
> at org.jose4j.jwt.consumer.JwtConsumer.process(JwtConsumer.java:433)
> at io.smallrye.jwt.auth.principal.DefaultJWTTokenParser.parse(DefaultJWTTokenParser.java:88)
> ... 40 more
> Caused by: org.jose4j.lang.UnresolvableKeyException: Failed to resolve a key from: META-INF/keys.jwks
> at io.smallrye.jwt.auth.principal.KeyLocationResolver.resolveKey(KeyLocationResolver.java:101)
> at org.jose4j.jwt.consumer.JwtConsumer.processContext(JwtConsumer.java:213)
> ... 42 more
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (WFLY-12955) Upgrade galleon to 4.2.3
by Jean Francois Denise (Jira)
Jean Francois Denise created WFLY-12955:
-------------------------------------------
Summary: Upgrade galleon to 4.2.3
Key: WFLY-12955
URL: https://issues.redhat.com/browse/WFLY-12955
Project: WildFly
Issue Type: Component Upgrade
Components: Build System
Reporter: Jean Francois Denise
Assignee: Jean Francois Denise
This upgrade allows to get rid-off universe and producer dependencies needed when generating offliner file.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (DROOLS-4911) Allow bound variables to be a function of 3 and 4 other variables
by Lukáš Petrovický (Jira)
[ https://issues.redhat.com/browse/DROOLS-4911?page=com.atlassian.jira.plug... ]
Lukáš Petrovický updated DROOLS-4911:
-------------------------------------
Description: For a use case in OptaPlanner's Constraint Streams (see PLANNER-1764), I need to be able to call variable binding functions with 3 and 4 arguments inside accumulate CEs. At the moment, Drools exec model only supports cases of up to 2 arguments. I need to bring the number up to 4. (was: For a use case in OptaPlanner's Constraint Streams (see PLANNER-1764), I need to be able to call variable binding functions with 3 and 4 arguments inside accumulate CEs. At the moment, Drools exec model only supports cases of up to 2 arguments. I need to bring the number up to 4.
I do not plan to introduce this functionality into DRL, as my use case leverages exec model directly.
)
> Allow bound variables to be a function of 3 and 4 other variables
> -----------------------------------------------------------------
>
> Key: DROOLS-4911
> URL: https://issues.redhat.com/browse/DROOLS-4911
> Project: Drools
> Issue Type: Enhancement
> Components: executable model
> Affects Versions: 7.31.0.Final
> Reporter: Lukáš Petrovický
> Assignee: Lukáš Petrovický
> Priority: Major
> Fix For: 7.32.0.Final
>
>
> For a use case in OptaPlanner's Constraint Streams (see PLANNER-1764), I need to be able to call variable binding functions with 3 and 4 arguments inside accumulate CEs. At the moment, Drools exec model only supports cases of up to 2 arguments. I need to bring the number up to 4.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (DROOLS-4911) Allow bound variables to be a function of 3 and 4 other variables
by Lukáš Petrovický (Jira)
[ https://issues.redhat.com/browse/DROOLS-4911?page=com.atlassian.jira.plug... ]
Lukáš Petrovický updated DROOLS-4911:
-------------------------------------
Description:
For a use case in OptaPlanner's Constraint Streams (see PLANNER-1764), I need to be able to call variable binding functions with 3 and 4 arguments inside accumulate CEs. At the moment, Drools exec model only supports cases of up to 2 arguments. I need to bring the number up to 4.
I do not plan to introduce this functionality into DRL, as my use case leverages exec model directly.
was:
For a use case in OptaPlanner's Constraint Streams (see PLANNER-1764), I need to be able to call variable binding functions with 3 or 4 arguments. This will allow me to handle cases like this:
{noformat}
$p1: Person()
$p2: Person()
$p3: Person($allMoney: $p1.money + $p2.money + $p3.money)
{noformat}
At the moment, Drools exec model only supports cases of up to 2 arguments. I need to bring the number up to 4.
I do not plan to introduce this functionality into DRL, as my use case leverages exec model directly.
> Allow bound variables to be a function of 3 and 4 other variables
> -----------------------------------------------------------------
>
> Key: DROOLS-4911
> URL: https://issues.redhat.com/browse/DROOLS-4911
> Project: Drools
> Issue Type: Enhancement
> Components: executable model
> Affects Versions: 7.31.0.Final
> Reporter: Lukáš Petrovický
> Assignee: Lukáš Petrovický
> Priority: Major
> Fix For: 7.32.0.Final
>
>
> For a use case in OptaPlanner's Constraint Streams (see PLANNER-1764), I need to be able to call variable binding functions with 3 and 4 arguments inside accumulate CEs. At the moment, Drools exec model only supports cases of up to 2 arguments. I need to bring the number up to 4.
> I do not plan to introduce this functionality into DRL, as my use case leverages exec model directly.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (WFLY-12949) Upgrade WildFly-Http-Client from 1.0.18.final to 1.0.19.Final
by Richard Opalka (Jira)
[ https://issues.redhat.com/browse/WFLY-12949?page=com.atlassian.jira.plugi... ]
Richard Opalka updated WFLY-12949:
----------------------------------
Description:
This component upgrade incorporates:
New features:
* [WEJBHTTP-34] EJB over HTTP discovery support
Bug fixes:
* [WEJBHTTP-31] Notify waiters when WildflyClientInputStream read listener reads 0 regardless of whether pooled.getBuffer().hasRemaining() returns true or false
* [WEJBHTTP-32] Remove duplicate notifyAll invocation from WildflyClientInputStream read listener
> Upgrade WildFly-Http-Client from 1.0.18.final to 1.0.19.Final
> -------------------------------------------------------------
>
> Key: WFLY-12949
> URL: https://issues.redhat.com/browse/WFLY-12949
> Project: WildFly
> Issue Type: Component Upgrade
> Components: EJB
> Reporter: Richard Opalka
> Assignee: Richard Opalka
> Priority: Major
> Fix For: 19.0.0.Beta1
>
>
> This component upgrade incorporates:
>
> New features:
> * [WEJBHTTP-34] EJB over HTTP discovery support
>
> Bug fixes:
> * [WEJBHTTP-31] Notify waiters when WildflyClientInputStream read listener reads 0 regardless of whether pooled.getBuffer().hasRemaining() returns true or false
> * [WEJBHTTP-32] Remove duplicate notifyAll invocation from WildflyClientInputStream read listener
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (WFWIP-297) Base64 encoded JWKS from a file fails to resolve
by Jan Kasik (Jira)
[ https://issues.redhat.com/browse/WFWIP-297?page=com.atlassian.jira.plugin... ]
Jan Kasik updated WFWIP-297:
----------------------------
Summary: Base64 encoded JWKS from a file fails to resolve (was: Base64 encoded JWKS from a fail fails to resolve)
> Base64 encoded JWKS from a file fails to resolve
> ------------------------------------------------
>
> Key: WFWIP-297
> URL: https://issues.redhat.com/browse/WFWIP-297
> Project: WildFly WIP
> Issue Type: Bug
> Components: MP JWT
> Reporter: Jan Kasik
> Assignee: Darran Lofthouse
> Priority: Blocker
>
> JWKS supplied through {{mp.jwt.verify.publickey.location}} fails to resolve when encoded to Base64 string. Seems like the SmallRye is trying to parse the file content as a PEM key. See excerpt from log.
> {code}
> 12:04:02,323 DEBUG [io.smallrye.jwt.config.JWTAuthContextInfoProvider] (default task-1) init, mpJwtPublicKey=NONE, mpJwtIssuer=issuer, mpJwtLocation=META-INF/keys.jwks
> ...
> 12:04:02,326 DEBUG [io.smallrye.jwt.auth.principal.KeyLocationResolver] (default task-1) Trying to create a key from the encoded PEM key...
> 12:04:02,326 DEBUG [io.smallrye.jwt.auth.principal.KeyLocationResolver] (default task-1) Failed to create a key from the encoded PEM key: java.security.spec.InvalidKeySpecException: java.security.InvalidKeyException: invalid key format
> at sun.security.rsa.RSAKeyFactory.engineGeneratePublic(RSAKeyFactory.java:205)
> ...
> Caused by: org.jose4j.jwt.consumer.InvalidJwtException: JWT processing failed. Additional details: [[17] Unable to process JOSE object (cause: org.jose4j.lang.UnresolvableKeyException: Failed to resolve a key from: META-INF/keys.jwks): JsonWebSignature{"kid":"blue-key","typ":"JWT","alg":"RS256"}->eyJraWQiOiJibHVlLWtleSIsInR5cCI6IkpXVCIsImFsZyI6IlJTMjU2In0=.eyJqdGkiOiJmMjc2YjVhYS0zMGZiLTQ4MWEtYjk0MS0xNDJhNjBmMGZiNjMiLCJzdWIiOiJGQUtFX1VTRVIiLCJncm91cHMiOlsiZ3JvdXAyIiwiZ3JvdXAxIl0sImF1ZCI6Im1pY3JvcHJvZmlsZS1qd3QtdGVzdHN1aXRlIiwiaXNzIjoiaXNzdWVyIiwiaWF0IjoxNTc4NjU0MjQxLCJleHAiOjE1Nzg2NTc4NDEsInVwbiI6IkZBS0VfVVNFUiIsInByZWZlcnJlZF91c2VybmFtZSI6IkZBS0VfVVNFUiJ9.AEe5kEr0s2p4CDbqwHPRwLziktwABX0OmM2aCEgdUF71eXlCu72ZhwNYDac3NyXMNhWp7k_xxX0I20EIbwBQsiJFmQZgqXZuK44Kc3jnMWDHT8kdPU03G3rIZBA2aiYsVy2gZ67gG_VnFx453fqHOxBIXtDsy1mzdrHwHLgY5iOklAodlv0Oe-H2Qik8oEj_k2R0a9b9E9pu7RHkono1d8TIuufwuJOIv7QSSo9w5vC74mYvd_RhZKvLACLx4ry9KVWamtDp_hMpclAqeUCjvcL-2VMI1VaDE3ZE7XonNMbCjwjxLzTtRLwVZAoYiD3eXSYkFTLGUT4BtfE8P5B3Uvb6pjf50e_EgYePAwvY-PFBFPB54BWcO433B3Pk411XYHUZweQfMHumateCwPJXZXcCoWjGj8ujHH3Leje_9gswzxDxd0JI2zjJEwasTBMixC65Jz9W5lKwQVVTHULP49KIbRXFkU52gTizMZNaABSGI48naMHr0Xu42yDKSrwkJTO3zNW1kSVi-3BMU6fmUxK8BF3xy2VgDgg_Rpmx_eQCBrGE36J-swHZbAPmiMKYT96D3rZHcMHa1oj784Em_h1p3sfr27ZCd0vpO7rOmHWzk1SWnb5GkySuuedwBQL-K5VT3mytqwFOg_UXZMkxSEGbn37WRzMa2KxfXKgRA-A=]
> at org.jose4j.jwt.consumer.JwtConsumer.processContext(JwtConsumer.java:271)
> at org.jose4j.jwt.consumer.JwtConsumer.process(JwtConsumer.java:433)
> at io.smallrye.jwt.auth.principal.DefaultJWTTokenParser.parse(DefaultJWTTokenParser.java:88)
> ... 40 more
> Caused by: org.jose4j.lang.UnresolvableKeyException: Failed to resolve a key from: META-INF/keys.jwks
> at io.smallrye.jwt.auth.principal.KeyLocationResolver.resolveKey(KeyLocationResolver.java:101)
> at org.jose4j.jwt.consumer.JwtConsumer.processContext(JwtConsumer.java:213)
> ... 42 more
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (WFWIP-297) Base64 encoded JWKS from a fail fails to resolve
by Jan Kasik (Jira)
Jan Kasik created WFWIP-297:
-------------------------------
Summary: Base64 encoded JWKS from a fail fails to resolve
Key: WFWIP-297
URL: https://issues.redhat.com/browse/WFWIP-297
Project: WildFly WIP
Issue Type: Bug
Components: MP JWT
Reporter: Jan Kasik
Assignee: Darran Lofthouse
JWKS supplied through {{mp.jwt.verify.publickey.location}} fails to resolve when encoded to Base64 string. Seems like the SmallRye is trying to parse the file content as a PEM key. See excerpt from log.
{{code}}
12:04:02,326 DEBUG [io.smallrye.jwt.auth.principal.KeyLocationResolver] (default task-1) Trying to create a key from the encoded PEM key...
12:04:02,326 DEBUG [io.smallrye.jwt.auth.principal.KeyLocationResolver] (default task-1) Failed to create a key from the encoded PEM key: java.security.spec.InvalidKeySpecException: java.security.InvalidKeyException: invalid key format
at sun.security.rsa.RSAKeyFactory.engineGeneratePublic(RSAKeyFactory.java:205)
...
Caused by: org.jose4j.jwt.consumer.InvalidJwtException: JWT processing failed. Additional details: [[17] Unable to process JOSE object (cause: org.jose4j.lang.UnresolvableKeyException: Failed to resolve a key from: META-INF/keys.jwks): JsonWebSignature{"kid":"blue-key","typ":"JWT","alg":"RS256"}->eyJraWQiOiJibHVlLWtleSIsInR5cCI6IkpXVCIsImFsZyI6IlJTMjU2In0=.eyJqdGkiOiJmMjc2YjVhYS0zMGZiLTQ4MWEtYjk0MS0xNDJhNjBmMGZiNjMiLCJzdWIiOiJGQUtFX1VTRVIiLCJncm91cHMiOlsiZ3JvdXAyIiwiZ3JvdXAxIl0sImF1ZCI6Im1pY3JvcHJvZmlsZS1qd3QtdGVzdHN1aXRlIiwiaXNzIjoiaXNzdWVyIiwiaWF0IjoxNTc4NjU0MjQxLCJleHAiOjE1Nzg2NTc4NDEsInVwbiI6IkZBS0VfVVNFUiIsInByZWZlcnJlZF91c2VybmFtZSI6IkZBS0VfVVNFUiJ9.AEe5kEr0s2p4CDbqwHPRwLziktwABX0OmM2aCEgdUF71eXlCu72ZhwNYDac3NyXMNhWp7k_xxX0I20EIbwBQsiJFmQZgqXZuK44Kc3jnMWDHT8kdPU03G3rIZBA2aiYsVy2gZ67gG_VnFx453fqHOxBIXtDsy1mzdrHwHLgY5iOklAodlv0Oe-H2Qik8oEj_k2R0a9b9E9pu7RHkono1d8TIuufwuJOIv7QSSo9w5vC74mYvd_RhZKvLACLx4ry9KVWamtDp_hMpclAqeUCjvcL-2VMI1VaDE3ZE7XonNMbCjwjxLzTtRLwVZAoYiD3eXSYkFTLGUT4BtfE8P5B3Uvb6pjf50e_EgYePAwvY-PFBFPB54BWcO433B3Pk411XYHUZweQfMHumateCwPJXZXcCoWjGj8ujHH3Leje_9gswzxDxd0JI2zjJEwasTBMixC65Jz9W5lKwQVVTHULP49KIbRXFkU52gTizMZNaABSGI48naMHr0Xu42yDKSrwkJTO3zNW1kSVi-3BMU6fmUxK8BF3xy2VgDgg_Rpmx_eQCBrGE36J-swHZbAPmiMKYT96D3rZHcMHa1oj784Em_h1p3sfr27ZCd0vpO7rOmHWzk1SWnb5GkySuuedwBQL-K5VT3mytqwFOg_UXZMkxSEGbn37WRzMa2KxfXKgRA-A=]
at org.jose4j.jwt.consumer.JwtConsumer.processContext(JwtConsumer.java:271)
at org.jose4j.jwt.consumer.JwtConsumer.process(JwtConsumer.java:433)
at io.smallrye.jwt.auth.principal.DefaultJWTTokenParser.parse(DefaultJWTTokenParser.java:88)
... 40 more
Caused by: org.jose4j.lang.UnresolvableKeyException: Failed to resolve a key from: META-INF/keys.jwks
at io.smallrye.jwt.auth.principal.KeyLocationResolver.resolveKey(KeyLocationResolver.java:101)
at org.jose4j.jwt.consumer.JwtConsumer.processContext(JwtConsumer.java:213)
... 42 more
{{code}}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (WFWIP-297) Base64 encoded JWKS from a fail fails to resolve
by Jan Kasik (Jira)
[ https://issues.redhat.com/browse/WFWIP-297?page=com.atlassian.jira.plugin... ]
Jan Kasik updated WFWIP-297:
----------------------------
Description:
JWKS supplied through {{mp.jwt.verify.publickey.location}} fails to resolve when encoded to Base64 string. Seems like the SmallRye is trying to parse the file content as a PEM key. See excerpt from log.
{code}
12:04:02,326 DEBUG [io.smallrye.jwt.auth.principal.KeyLocationResolver] (default task-1) Trying to create a key from the encoded PEM key...
12:04:02,326 DEBUG [io.smallrye.jwt.auth.principal.KeyLocationResolver] (default task-1) Failed to create a key from the encoded PEM key: java.security.spec.InvalidKeySpecException: java.security.InvalidKeyException: invalid key format
at sun.security.rsa.RSAKeyFactory.engineGeneratePublic(RSAKeyFactory.java:205)
...
Caused by: org.jose4j.jwt.consumer.InvalidJwtException: JWT processing failed. Additional details: [[17] Unable to process JOSE object (cause: org.jose4j.lang.UnresolvableKeyException: Failed to resolve a key from: META-INF/keys.jwks): JsonWebSignature{"kid":"blue-key","typ":"JWT","alg":"RS256"}->eyJraWQiOiJibHVlLWtleSIsInR5cCI6IkpXVCIsImFsZyI6IlJTMjU2In0=.eyJqdGkiOiJmMjc2YjVhYS0zMGZiLTQ4MWEtYjk0MS0xNDJhNjBmMGZiNjMiLCJzdWIiOiJGQUtFX1VTRVIiLCJncm91cHMiOlsiZ3JvdXAyIiwiZ3JvdXAxIl0sImF1ZCI6Im1pY3JvcHJvZmlsZS1qd3QtdGVzdHN1aXRlIiwiaXNzIjoiaXNzdWVyIiwiaWF0IjoxNTc4NjU0MjQxLCJleHAiOjE1Nzg2NTc4NDEsInVwbiI6IkZBS0VfVVNFUiIsInByZWZlcnJlZF91c2VybmFtZSI6IkZBS0VfVVNFUiJ9.AEe5kEr0s2p4CDbqwHPRwLziktwABX0OmM2aCEgdUF71eXlCu72ZhwNYDac3NyXMNhWp7k_xxX0I20EIbwBQsiJFmQZgqXZuK44Kc3jnMWDHT8kdPU03G3rIZBA2aiYsVy2gZ67gG_VnFx453fqHOxBIXtDsy1mzdrHwHLgY5iOklAodlv0Oe-H2Qik8oEj_k2R0a9b9E9pu7RHkono1d8TIuufwuJOIv7QSSo9w5vC74mYvd_RhZKvLACLx4ry9KVWamtDp_hMpclAqeUCjvcL-2VMI1VaDE3ZE7XonNMbCjwjxLzTtRLwVZAoYiD3eXSYkFTLGUT4BtfE8P5B3Uvb6pjf50e_EgYePAwvY-PFBFPB54BWcO433B3Pk411XYHUZweQfMHumateCwPJXZXcCoWjGj8ujHH3Leje_9gswzxDxd0JI2zjJEwasTBMixC65Jz9W5lKwQVVTHULP49KIbRXFkU52gTizMZNaABSGI48naMHr0Xu42yDKSrwkJTO3zNW1kSVi-3BMU6fmUxK8BF3xy2VgDgg_Rpmx_eQCBrGE36J-swHZbAPmiMKYT96D3rZHcMHa1oj784Em_h1p3sfr27ZCd0vpO7rOmHWzk1SWnb5GkySuuedwBQL-K5VT3mytqwFOg_UXZMkxSEGbn37WRzMa2KxfXKgRA-A=]
at org.jose4j.jwt.consumer.JwtConsumer.processContext(JwtConsumer.java:271)
at org.jose4j.jwt.consumer.JwtConsumer.process(JwtConsumer.java:433)
at io.smallrye.jwt.auth.principal.DefaultJWTTokenParser.parse(DefaultJWTTokenParser.java:88)
... 40 more
Caused by: org.jose4j.lang.UnresolvableKeyException: Failed to resolve a key from: META-INF/keys.jwks
at io.smallrye.jwt.auth.principal.KeyLocationResolver.resolveKey(KeyLocationResolver.java:101)
at org.jose4j.jwt.consumer.JwtConsumer.processContext(JwtConsumer.java:213)
... 42 more
{code}
was:
JWKS supplied through {{mp.jwt.verify.publickey.location}} fails to resolve when encoded to Base64 string. Seems like the SmallRye is trying to parse the file content as a PEM key. See excerpt from log.
{{code}}
12:04:02,326 DEBUG [io.smallrye.jwt.auth.principal.KeyLocationResolver] (default task-1) Trying to create a key from the encoded PEM key...
12:04:02,326 DEBUG [io.smallrye.jwt.auth.principal.KeyLocationResolver] (default task-1) Failed to create a key from the encoded PEM key: java.security.spec.InvalidKeySpecException: java.security.InvalidKeyException: invalid key format
at sun.security.rsa.RSAKeyFactory.engineGeneratePublic(RSAKeyFactory.java:205)
...
Caused by: org.jose4j.jwt.consumer.InvalidJwtException: JWT processing failed. Additional details: [[17] Unable to process JOSE object (cause: org.jose4j.lang.UnresolvableKeyException: Failed to resolve a key from: META-INF/keys.jwks): JsonWebSignature{"kid":"blue-key","typ":"JWT","alg":"RS256"}->eyJraWQiOiJibHVlLWtleSIsInR5cCI6IkpXVCIsImFsZyI6IlJTMjU2In0=.eyJqdGkiOiJmMjc2YjVhYS0zMGZiLTQ4MWEtYjk0MS0xNDJhNjBmMGZiNjMiLCJzdWIiOiJGQUtFX1VTRVIiLCJncm91cHMiOlsiZ3JvdXAyIiwiZ3JvdXAxIl0sImF1ZCI6Im1pY3JvcHJvZmlsZS1qd3QtdGVzdHN1aXRlIiwiaXNzIjoiaXNzdWVyIiwiaWF0IjoxNTc4NjU0MjQxLCJleHAiOjE1Nzg2NTc4NDEsInVwbiI6IkZBS0VfVVNFUiIsInByZWZlcnJlZF91c2VybmFtZSI6IkZBS0VfVVNFUiJ9.AEe5kEr0s2p4CDbqwHPRwLziktwABX0OmM2aCEgdUF71eXlCu72ZhwNYDac3NyXMNhWp7k_xxX0I20EIbwBQsiJFmQZgqXZuK44Kc3jnMWDHT8kdPU03G3rIZBA2aiYsVy2gZ67gG_VnFx453fqHOxBIXtDsy1mzdrHwHLgY5iOklAodlv0Oe-H2Qik8oEj_k2R0a9b9E9pu7RHkono1d8TIuufwuJOIv7QSSo9w5vC74mYvd_RhZKvLACLx4ry9KVWamtDp_hMpclAqeUCjvcL-2VMI1VaDE3ZE7XonNMbCjwjxLzTtRLwVZAoYiD3eXSYkFTLGUT4BtfE8P5B3Uvb6pjf50e_EgYePAwvY-PFBFPB54BWcO433B3Pk411XYHUZweQfMHumateCwPJXZXcCoWjGj8ujHH3Leje_9gswzxDxd0JI2zjJEwasTBMixC65Jz9W5lKwQVVTHULP49KIbRXFkU52gTizMZNaABSGI48naMHr0Xu42yDKSrwkJTO3zNW1kSVi-3BMU6fmUxK8BF3xy2VgDgg_Rpmx_eQCBrGE36J-swHZbAPmiMKYT96D3rZHcMHa1oj784Em_h1p3sfr27ZCd0vpO7rOmHWzk1SWnb5GkySuuedwBQL-K5VT3mytqwFOg_UXZMkxSEGbn37WRzMa2KxfXKgRA-A=]
at org.jose4j.jwt.consumer.JwtConsumer.processContext(JwtConsumer.java:271)
at org.jose4j.jwt.consumer.JwtConsumer.process(JwtConsumer.java:433)
at io.smallrye.jwt.auth.principal.DefaultJWTTokenParser.parse(DefaultJWTTokenParser.java:88)
... 40 more
Caused by: org.jose4j.lang.UnresolvableKeyException: Failed to resolve a key from: META-INF/keys.jwks
at io.smallrye.jwt.auth.principal.KeyLocationResolver.resolveKey(KeyLocationResolver.java:101)
at org.jose4j.jwt.consumer.JwtConsumer.processContext(JwtConsumer.java:213)
... 42 more
{{code}}
> Base64 encoded JWKS from a fail fails to resolve
> ------------------------------------------------
>
> Key: WFWIP-297
> URL: https://issues.redhat.com/browse/WFWIP-297
> Project: WildFly WIP
> Issue Type: Bug
> Components: MP JWT
> Reporter: Jan Kasik
> Assignee: Darran Lofthouse
> Priority: Blocker
>
> JWKS supplied through {{mp.jwt.verify.publickey.location}} fails to resolve when encoded to Base64 string. Seems like the SmallRye is trying to parse the file content as a PEM key. See excerpt from log.
> {code}
> 12:04:02,326 DEBUG [io.smallrye.jwt.auth.principal.KeyLocationResolver] (default task-1) Trying to create a key from the encoded PEM key...
> 12:04:02,326 DEBUG [io.smallrye.jwt.auth.principal.KeyLocationResolver] (default task-1) Failed to create a key from the encoded PEM key: java.security.spec.InvalidKeySpecException: java.security.InvalidKeyException: invalid key format
> at sun.security.rsa.RSAKeyFactory.engineGeneratePublic(RSAKeyFactory.java:205)
> ...
> Caused by: org.jose4j.jwt.consumer.InvalidJwtException: JWT processing failed. Additional details: [[17] Unable to process JOSE object (cause: org.jose4j.lang.UnresolvableKeyException: Failed to resolve a key from: META-INF/keys.jwks): JsonWebSignature{"kid":"blue-key","typ":"JWT","alg":"RS256"}->eyJraWQiOiJibHVlLWtleSIsInR5cCI6IkpXVCIsImFsZyI6IlJTMjU2In0=.eyJqdGkiOiJmMjc2YjVhYS0zMGZiLTQ4MWEtYjk0MS0xNDJhNjBmMGZiNjMiLCJzdWIiOiJGQUtFX1VTRVIiLCJncm91cHMiOlsiZ3JvdXAyIiwiZ3JvdXAxIl0sImF1ZCI6Im1pY3JvcHJvZmlsZS1qd3QtdGVzdHN1aXRlIiwiaXNzIjoiaXNzdWVyIiwiaWF0IjoxNTc4NjU0MjQxLCJleHAiOjE1Nzg2NTc4NDEsInVwbiI6IkZBS0VfVVNFUiIsInByZWZlcnJlZF91c2VybmFtZSI6IkZBS0VfVVNFUiJ9.AEe5kEr0s2p4CDbqwHPRwLziktwABX0OmM2aCEgdUF71eXlCu72ZhwNYDac3NyXMNhWp7k_xxX0I20EIbwBQsiJFmQZgqXZuK44Kc3jnMWDHT8kdPU03G3rIZBA2aiYsVy2gZ67gG_VnFx453fqHOxBIXtDsy1mzdrHwHLgY5iOklAodlv0Oe-H2Qik8oEj_k2R0a9b9E9pu7RHkono1d8TIuufwuJOIv7QSSo9w5vC74mYvd_RhZKvLACLx4ry9KVWamtDp_hMpclAqeUCjvcL-2VMI1VaDE3ZE7XonNMbCjwjxLzTtRLwVZAoYiD3eXSYkFTLGUT4BtfE8P5B3Uvb6pjf50e_EgYePAwvY-PFBFPB54BWcO433B3Pk411XYHUZweQfMHumateCwPJXZXcCoWjGj8ujHH3Leje_9gswzxDxd0JI2zjJEwasTBMixC65Jz9W5lKwQVVTHULP49KIbRXFkU52gTizMZNaABSGI48naMHr0Xu42yDKSrwkJTO3zNW1kSVi-3BMU6fmUxK8BF3xy2VgDgg_Rpmx_eQCBrGE36J-swHZbAPmiMKYT96D3rZHcMHa1oj784Em_h1p3sfr27ZCd0vpO7rOmHWzk1SWnb5GkySuuedwBQL-K5VT3mytqwFOg_UXZMkxSEGbn37WRzMa2KxfXKgRA-A=]
> at org.jose4j.jwt.consumer.JwtConsumer.processContext(JwtConsumer.java:271)
> at org.jose4j.jwt.consumer.JwtConsumer.process(JwtConsumer.java:433)
> at io.smallrye.jwt.auth.principal.DefaultJWTTokenParser.parse(DefaultJWTTokenParser.java:88)
> ... 40 more
> Caused by: org.jose4j.lang.UnresolvableKeyException: Failed to resolve a key from: META-INF/keys.jwks
> at io.smallrye.jwt.auth.principal.KeyLocationResolver.resolveKey(KeyLocationResolver.java:101)
> at org.jose4j.jwt.consumer.JwtConsumer.processContext(JwtConsumer.java:213)
> ... 42 more
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (WFWIP-297) Base64 encoded JWKS from a fail fails to resolve
by Jan Kasik (Jira)
[ https://issues.redhat.com/browse/WFWIP-297?page=com.atlassian.jira.plugin... ]
Jan Kasik updated WFWIP-297:
----------------------------
Description:
JWKS supplied through {{mp.jwt.verify.publickey.location}} fails to resolve when encoded to Base64 string. Seems like the SmallRye is trying to parse the file content as a PEM key. See excerpt from log.
{code}
12:04:02,323 DEBUG [io.smallrye.jwt.config.JWTAuthContextInfoProvider] (default task-1) init, mpJwtPublicKey=NONE, mpJwtIssuer=issuer, mpJwtLocation=META-INF/keys.jwks
...
12:04:02,326 DEBUG [io.smallrye.jwt.auth.principal.KeyLocationResolver] (default task-1) Trying to create a key from the encoded PEM key...
12:04:02,326 DEBUG [io.smallrye.jwt.auth.principal.KeyLocationResolver] (default task-1) Failed to create a key from the encoded PEM key: java.security.spec.InvalidKeySpecException: java.security.InvalidKeyException: invalid key format
at sun.security.rsa.RSAKeyFactory.engineGeneratePublic(RSAKeyFactory.java:205)
...
Caused by: org.jose4j.jwt.consumer.InvalidJwtException: JWT processing failed. Additional details: [[17] Unable to process JOSE object (cause: org.jose4j.lang.UnresolvableKeyException: Failed to resolve a key from: META-INF/keys.jwks): JsonWebSignature{"kid":"blue-key","typ":"JWT","alg":"RS256"}->eyJraWQiOiJibHVlLWtleSIsInR5cCI6IkpXVCIsImFsZyI6IlJTMjU2In0=.eyJqdGkiOiJmMjc2YjVhYS0zMGZiLTQ4MWEtYjk0MS0xNDJhNjBmMGZiNjMiLCJzdWIiOiJGQUtFX1VTRVIiLCJncm91cHMiOlsiZ3JvdXAyIiwiZ3JvdXAxIl0sImF1ZCI6Im1pY3JvcHJvZmlsZS1qd3QtdGVzdHN1aXRlIiwiaXNzIjoiaXNzdWVyIiwiaWF0IjoxNTc4NjU0MjQxLCJleHAiOjE1Nzg2NTc4NDEsInVwbiI6IkZBS0VfVVNFUiIsInByZWZlcnJlZF91c2VybmFtZSI6IkZBS0VfVVNFUiJ9.AEe5kEr0s2p4CDbqwHPRwLziktwABX0OmM2aCEgdUF71eXlCu72ZhwNYDac3NyXMNhWp7k_xxX0I20EIbwBQsiJFmQZgqXZuK44Kc3jnMWDHT8kdPU03G3rIZBA2aiYsVy2gZ67gG_VnFx453fqHOxBIXtDsy1mzdrHwHLgY5iOklAodlv0Oe-H2Qik8oEj_k2R0a9b9E9pu7RHkono1d8TIuufwuJOIv7QSSo9w5vC74mYvd_RhZKvLACLx4ry9KVWamtDp_hMpclAqeUCjvcL-2VMI1VaDE3ZE7XonNMbCjwjxLzTtRLwVZAoYiD3eXSYkFTLGUT4BtfE8P5B3Uvb6pjf50e_EgYePAwvY-PFBFPB54BWcO433B3Pk411XYHUZweQfMHumateCwPJXZXcCoWjGj8ujHH3Leje_9gswzxDxd0JI2zjJEwasTBMixC65Jz9W5lKwQVVTHULP49KIbRXFkU52gTizMZNaABSGI48naMHr0Xu42yDKSrwkJTO3zNW1kSVi-3BMU6fmUxK8BF3xy2VgDgg_Rpmx_eQCBrGE36J-swHZbAPmiMKYT96D3rZHcMHa1oj784Em_h1p3sfr27ZCd0vpO7rOmHWzk1SWnb5GkySuuedwBQL-K5VT3mytqwFOg_UXZMkxSEGbn37WRzMa2KxfXKgRA-A=]
at org.jose4j.jwt.consumer.JwtConsumer.processContext(JwtConsumer.java:271)
at org.jose4j.jwt.consumer.JwtConsumer.process(JwtConsumer.java:433)
at io.smallrye.jwt.auth.principal.DefaultJWTTokenParser.parse(DefaultJWTTokenParser.java:88)
... 40 more
Caused by: org.jose4j.lang.UnresolvableKeyException: Failed to resolve a key from: META-INF/keys.jwks
at io.smallrye.jwt.auth.principal.KeyLocationResolver.resolveKey(KeyLocationResolver.java:101)
at org.jose4j.jwt.consumer.JwtConsumer.processContext(JwtConsumer.java:213)
... 42 more
{code}
was:
JWKS supplied through {{mp.jwt.verify.publickey.location}} fails to resolve when encoded to Base64 string. Seems like the SmallRye is trying to parse the file content as a PEM key. See excerpt from log.
{code}
12:04:02,326 DEBUG [io.smallrye.jwt.auth.principal.KeyLocationResolver] (default task-1) Trying to create a key from the encoded PEM key...
12:04:02,326 DEBUG [io.smallrye.jwt.auth.principal.KeyLocationResolver] (default task-1) Failed to create a key from the encoded PEM key: java.security.spec.InvalidKeySpecException: java.security.InvalidKeyException: invalid key format
at sun.security.rsa.RSAKeyFactory.engineGeneratePublic(RSAKeyFactory.java:205)
...
Caused by: org.jose4j.jwt.consumer.InvalidJwtException: JWT processing failed. Additional details: [[17] Unable to process JOSE object (cause: org.jose4j.lang.UnresolvableKeyException: Failed to resolve a key from: META-INF/keys.jwks): JsonWebSignature{"kid":"blue-key","typ":"JWT","alg":"RS256"}->eyJraWQiOiJibHVlLWtleSIsInR5cCI6IkpXVCIsImFsZyI6IlJTMjU2In0=.eyJqdGkiOiJmMjc2YjVhYS0zMGZiLTQ4MWEtYjk0MS0xNDJhNjBmMGZiNjMiLCJzdWIiOiJGQUtFX1VTRVIiLCJncm91cHMiOlsiZ3JvdXAyIiwiZ3JvdXAxIl0sImF1ZCI6Im1pY3JvcHJvZmlsZS1qd3QtdGVzdHN1aXRlIiwiaXNzIjoiaXNzdWVyIiwiaWF0IjoxNTc4NjU0MjQxLCJleHAiOjE1Nzg2NTc4NDEsInVwbiI6IkZBS0VfVVNFUiIsInByZWZlcnJlZF91c2VybmFtZSI6IkZBS0VfVVNFUiJ9.AEe5kEr0s2p4CDbqwHPRwLziktwABX0OmM2aCEgdUF71eXlCu72ZhwNYDac3NyXMNhWp7k_xxX0I20EIbwBQsiJFmQZgqXZuK44Kc3jnMWDHT8kdPU03G3rIZBA2aiYsVy2gZ67gG_VnFx453fqHOxBIXtDsy1mzdrHwHLgY5iOklAodlv0Oe-H2Qik8oEj_k2R0a9b9E9pu7RHkono1d8TIuufwuJOIv7QSSo9w5vC74mYvd_RhZKvLACLx4ry9KVWamtDp_hMpclAqeUCjvcL-2VMI1VaDE3ZE7XonNMbCjwjxLzTtRLwVZAoYiD3eXSYkFTLGUT4BtfE8P5B3Uvb6pjf50e_EgYePAwvY-PFBFPB54BWcO433B3Pk411XYHUZweQfMHumateCwPJXZXcCoWjGj8ujHH3Leje_9gswzxDxd0JI2zjJEwasTBMixC65Jz9W5lKwQVVTHULP49KIbRXFkU52gTizMZNaABSGI48naMHr0Xu42yDKSrwkJTO3zNW1kSVi-3BMU6fmUxK8BF3xy2VgDgg_Rpmx_eQCBrGE36J-swHZbAPmiMKYT96D3rZHcMHa1oj784Em_h1p3sfr27ZCd0vpO7rOmHWzk1SWnb5GkySuuedwBQL-K5VT3mytqwFOg_UXZMkxSEGbn37WRzMa2KxfXKgRA-A=]
at org.jose4j.jwt.consumer.JwtConsumer.processContext(JwtConsumer.java:271)
at org.jose4j.jwt.consumer.JwtConsumer.process(JwtConsumer.java:433)
at io.smallrye.jwt.auth.principal.DefaultJWTTokenParser.parse(DefaultJWTTokenParser.java:88)
... 40 more
Caused by: org.jose4j.lang.UnresolvableKeyException: Failed to resolve a key from: META-INF/keys.jwks
at io.smallrye.jwt.auth.principal.KeyLocationResolver.resolveKey(KeyLocationResolver.java:101)
at org.jose4j.jwt.consumer.JwtConsumer.processContext(JwtConsumer.java:213)
... 42 more
{code}
> Base64 encoded JWKS from a fail fails to resolve
> ------------------------------------------------
>
> Key: WFWIP-297
> URL: https://issues.redhat.com/browse/WFWIP-297
> Project: WildFly WIP
> Issue Type: Bug
> Components: MP JWT
> Reporter: Jan Kasik
> Assignee: Darran Lofthouse
> Priority: Blocker
>
> JWKS supplied through {{mp.jwt.verify.publickey.location}} fails to resolve when encoded to Base64 string. Seems like the SmallRye is trying to parse the file content as a PEM key. See excerpt from log.
> {code}
> 12:04:02,323 DEBUG [io.smallrye.jwt.config.JWTAuthContextInfoProvider] (default task-1) init, mpJwtPublicKey=NONE, mpJwtIssuer=issuer, mpJwtLocation=META-INF/keys.jwks
> ...
> 12:04:02,326 DEBUG [io.smallrye.jwt.auth.principal.KeyLocationResolver] (default task-1) Trying to create a key from the encoded PEM key...
> 12:04:02,326 DEBUG [io.smallrye.jwt.auth.principal.KeyLocationResolver] (default task-1) Failed to create a key from the encoded PEM key: java.security.spec.InvalidKeySpecException: java.security.InvalidKeyException: invalid key format
> at sun.security.rsa.RSAKeyFactory.engineGeneratePublic(RSAKeyFactory.java:205)
> ...
> Caused by: org.jose4j.jwt.consumer.InvalidJwtException: JWT processing failed. Additional details: [[17] Unable to process JOSE object (cause: org.jose4j.lang.UnresolvableKeyException: Failed to resolve a key from: META-INF/keys.jwks): JsonWebSignature{"kid":"blue-key","typ":"JWT","alg":"RS256"}->eyJraWQiOiJibHVlLWtleSIsInR5cCI6IkpXVCIsImFsZyI6IlJTMjU2In0=.eyJqdGkiOiJmMjc2YjVhYS0zMGZiLTQ4MWEtYjk0MS0xNDJhNjBmMGZiNjMiLCJzdWIiOiJGQUtFX1VTRVIiLCJncm91cHMiOlsiZ3JvdXAyIiwiZ3JvdXAxIl0sImF1ZCI6Im1pY3JvcHJvZmlsZS1qd3QtdGVzdHN1aXRlIiwiaXNzIjoiaXNzdWVyIiwiaWF0IjoxNTc4NjU0MjQxLCJleHAiOjE1Nzg2NTc4NDEsInVwbiI6IkZBS0VfVVNFUiIsInByZWZlcnJlZF91c2VybmFtZSI6IkZBS0VfVVNFUiJ9.AEe5kEr0s2p4CDbqwHPRwLziktwABX0OmM2aCEgdUF71eXlCu72ZhwNYDac3NyXMNhWp7k_xxX0I20EIbwBQsiJFmQZgqXZuK44Kc3jnMWDHT8kdPU03G3rIZBA2aiYsVy2gZ67gG_VnFx453fqHOxBIXtDsy1mzdrHwHLgY5iOklAodlv0Oe-H2Qik8oEj_k2R0a9b9E9pu7RHkono1d8TIuufwuJOIv7QSSo9w5vC74mYvd_RhZKvLACLx4ry9KVWamtDp_hMpclAqeUCjvcL-2VMI1VaDE3ZE7XonNMbCjwjxLzTtRLwVZAoYiD3eXSYkFTLGUT4BtfE8P5B3Uvb6pjf50e_EgYePAwvY-PFBFPB54BWcO433B3Pk411XYHUZweQfMHumateCwPJXZXcCoWjGj8ujHH3Leje_9gswzxDxd0JI2zjJEwasTBMixC65Jz9W5lKwQVVTHULP49KIbRXFkU52gTizMZNaABSGI48naMHr0Xu42yDKSrwkJTO3zNW1kSVi-3BMU6fmUxK8BF3xy2VgDgg_Rpmx_eQCBrGE36J-swHZbAPmiMKYT96D3rZHcMHa1oj784Em_h1p3sfr27ZCd0vpO7rOmHWzk1SWnb5GkySuuedwBQL-K5VT3mytqwFOg_UXZMkxSEGbn37WRzMa2KxfXKgRA-A=]
> at org.jose4j.jwt.consumer.JwtConsumer.processContext(JwtConsumer.java:271)
> at org.jose4j.jwt.consumer.JwtConsumer.process(JwtConsumer.java:433)
> at io.smallrye.jwt.auth.principal.DefaultJWTTokenParser.parse(DefaultJWTTokenParser.java:88)
> ... 40 more
> Caused by: org.jose4j.lang.UnresolvableKeyException: Failed to resolve a key from: META-INF/keys.jwks
> at io.smallrye.jwt.auth.principal.KeyLocationResolver.resolveKey(KeyLocationResolver.java:101)
> at org.jose4j.jwt.consumer.JwtConsumer.processContext(JwtConsumer.java:213)
> ... 42 more
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (DROOLS-4923) Added handling an end key for selecting bottom right cell in scenario
by Jozef Marko (Jira)
[ https://issues.redhat.com/browse/DROOLS-4923?page=com.atlassian.jira.plug... ]
Jozef Marko updated DROOLS-4923:
--------------------------------
Description:
This is small improvement basically for testing.
This enchantments adds ability to user to navigate to the right bottom cell of the grid by using *Shift+END* key.
It is described in ScenarioGridPanelProducer.class.
was:
This is small improvement basically for testing.
This enchantments adds ability to user to navigate to the right bottom cell of the grid by using END key.
It described in ScenarioGridPanelProducer.class.
> Added handling an end key for selecting bottom right cell in scenario
> ---------------------------------------------------------------------
>
> Key: DROOLS-4923
> URL: https://issues.redhat.com/browse/DROOLS-4923
> Project: Drools
> Issue Type: Enhancement
> Components: Test Scenarios Editor
> Affects Versions: 7.31.0.Final
> Reporter: Anna Dupliak
> Assignee: Anna Dupliak
> Priority: Trivial
> Labels: BusinessCentral
>
> This is small improvement basically for testing.
> This enchantments adds ability to user to navigate to the right bottom cell of the grid by using *Shift+END* key.
> It is described in ScenarioGridPanelProducer.class.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (DROOLS-4923) Added handling an end key for selecting bottom right cell in scenario
by Jozef Marko (Jira)
[ https://issues.redhat.com/browse/DROOLS-4923?page=com.atlassian.jira.plug... ]
Jozef Marko updated DROOLS-4923:
--------------------------------
Summary: Added handling an end key for selecting bottom right cell in scenario (was: dded handling an end key for selecting bottom right cell in scenario)
> Added handling an end key for selecting bottom right cell in scenario
> ---------------------------------------------------------------------
>
> Key: DROOLS-4923
> URL: https://issues.redhat.com/browse/DROOLS-4923
> Project: Drools
> Issue Type: Enhancement
> Components: Test Scenarios Editor
> Affects Versions: 7.31.0.Final
> Reporter: Anna Dupliak
> Assignee: Anna Dupliak
> Priority: Trivial
> Labels: BusinessCentral
>
> This is small improvement basically for testing.
> This enchantments adds ability to user to navigate to the right bottom cell of the grid by using END key.
> It described in ScenarioGridPanelProducer.class.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (WFLY-12952) MP Health returns UP when checks are expected but not installed yet.
by Jeff Mesnil (Jira)
[ https://issues.redhat.com/browse/WFLY-12952?page=com.atlassian.jira.plugi... ]
Jeff Mesnil commented on WFLY-12952:
------------------------------------
[~istraka] The culprit of this issue is the notion of "expected" health check procedures.
WildFly allows deployment of Jakarta EE application without any a priori knowledge. The application server does not when when an application will be deployed or if that application contains health check procedures.
That's why the default for the readiness endpoint is to return UP. It means that the app server does not expect any health check procedures from the deployments.
We also want to handle the case where the user knows that that there will be health check procedures in the deployment.
In that case, WildFly needs a hint about that and the user must specify the env var MP_HEALTH_EMPTY_READINESS_CHECKS_STATUS=DOWN, so that WildFly knows that it must return DOWN until there are application readiness probes to take into account to determine the overall readiness of the app server + application.
My understanding is that we respect the spec. We need a hint (or configuration) from the user but this is not against the spec.
> MP Health returns UP when checks are expected but not installed yet.
> --------------------------------------------------------------------
>
> Key: WFLY-12952
> URL: https://issues.redhat.com/browse/WFLY-12952
> Project: WildFly
> Issue Type: Bug
> Components: MP Health
> Affects Versions: 18.0.0.Final
> Reporter: Ivan Straka
> Assignee: Jeff Mesnil
> Priority: Blocker
>
> MicroProfile Health 2.0 specification [link|https://github.com/eclipse/microprofile-health/blob/2.0/spec/src/mai...] says:
> * A producer MUST support custom, application level health check procedures
> * A producer SHOULD support reasonable out-of-the-box procedures
> * A producer with no health check procedures expected or installed MUST return positive overall status (i.e. HTTP 200)
> * A producer with health check procedures expected but not yet installed MUST return negative overall status (i.e. HTTP 503)
> When I deploy and application with a readiness probe before WildFly is started, from my and namely OpenShift POV the health check procedure is expected from the very beginning.
> _Let me note that on OpenShift starting the served should mean starting the service._
> Hence I expect negative overall status till the probe is ready and is able to provide response.
> However WildFly with default setting responses with status UP:
> {code:bash}
> while true; do echo $(date +"%T.%3N") ; curl localhost:9990/health/ready; echo ""; done
> 17:17:56.438 curl: (7) Failed to connect to localhost port 9990: Connection refused
> 17:17:56.452 curl: (7) Failed to connect to localhost port 9990: Connection refused
> 17:17:56.466 {"status":"UP","checks":[]}
> ...
> 17:18:01.121 {"status":"UP","checks":[]}
> 17:18:01.133 {"status":"DOWN","checks":[{"name":"delayed-readiness","status":"DOWN"}]}
> {code}
> This violates (4) bullet in the specification.
> WildFly provides option to set global Status when probes are not defined ([documentation|https://doc-stage.usersys.redhat.com/documentation/en-us/re...])
> Which would mean the scenario would behave according to the specification. Yet the default state violates it.
> If the default value were _DOWN_ we would run into an issue if WildFly without deployment were used (for example as backup for AMQ). The status would be just DOWN:
> {noformat}
> 17:22:41.719
> {"status":"DOWN","checks":[]}
> {noformat}
> And that would violate (3) in the specification.
> TCK tests do not cover the scenario well.
> Is there a way to return _DOWN_ until WildFly scan a deployment and if no health check is found (thus not expected) then start to return _UP_ ? The scan should happen during MP Health initialization.
> If there is no deployment, the _UP_ it is.
> Setting the priority to blocker since WildFly 19 shall be EAP 7.3.0.CD19 which is supposed to run on OpenShift. With this behavior health check is not very useful because:
> * OpenShift starts the service wait some time and start asking for health status
> * WildFly responses _UP_ yet application helathcheck is not installed yet
> * With health status _UP_ OpenShift consider a pod ready
> * In this point application is installed, health status is _DOWN_ (a DB is down) however OpenShift flow is somewhere else
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (DROOLS-4923) dded handling an end key for selecting bottom right cell in scenario
by Anna Dupliak (Jira)
Anna Dupliak created DROOLS-4923:
------------------------------------
Summary: dded handling an end key for selecting bottom right cell in scenario
Key: DROOLS-4923
URL: https://issues.redhat.com/browse/DROOLS-4923
Project: Drools
Issue Type: Enhancement
Components: Test Scenarios Editor
Affects Versions: 7.31.0.Final
Reporter: Anna Dupliak
Assignee: Anna Dupliak
This is small improvement basically for testing.
This enchantments adds ability to user to navigate to the right bottom cell of the grid by using END key.
It described in ScenarioGridPanelProducer.class.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (WFLY-12952) MP Health returns UP when checks are expected but not installed yet.
by Ivan Straka (Jira)
[ https://issues.redhat.com/browse/WFLY-12952?page=com.atlassian.jira.plugi... ]
Ivan Straka updated WFLY-12952:
-------------------------------
Description:
MicroProfile Health 2.0 specification [link|https://github.com/eclipse/microprofile-health/blob/master/spec/src/...] says:
* A producer MUST support custom, application level health check procedures
* A producer SHOULD support reasonable out-of-the-box procedures
* A producer with no health check procedures expected or installed MUST return positive overall status (i.e. HTTP 200)
* A producer with health check procedures expected but not yet installed MUST return negative overall status (i.e. HTTP 503)
When I deploy and application with a readiness probe before WildFly is started, from my and namely OpenShift POV the health check procedure is expected from the very beginning.
_Let me note that on OpenShift starting the served should mean starting the service._
Hence I expect negative overall status till the probe is ready and is able to provide response.
However WildFly with default setting responses with status UP:
{code:bash}
while true; do echo $(date +"%T.%3N") ; curl localhost:9990/health/ready; echo ""; done
17:17:56.438 curl: (7) Failed to connect to localhost port 9990: Connection refused
17:17:56.452 curl: (7) Failed to connect to localhost port 9990: Connection refused
17:17:56.466 {"status":"UP","checks":[]}
...
17:18:01.121 {"status":"UP","checks":[]}
17:18:01.133 {"status":"DOWN","checks":[{"name":"delayed-readiness","status":"DOWN"}]}
{code}
This violates (4) bullet in the specification.
WildFly provides option to set global Status when probes are not defined ([documentation|https://doc-stage.usersys.redhat.com/documentation/en-us/re...])
Which would mean the scenario would behave according to the specification. Yet the default state violates it.
If the default value were _DOWN_ we would run into an issue if WildFly without deployment were used (for example as backup for AMQ). The status would be just DOWN:
{noformat}
17:22:41.719
{"status":"DOWN","checks":[]}
{noformat}
And that would violate (3) in the specification.
TCK tests do not cover the scenario well.
Is there a way to return _DOWN_ until WildFly scan a deployment and if no health check is found (thus not expected) then start to return _UP_ ? The scan should happen during MP Health initialization.
If there is no deployment, the _UP_ it is.
Setting the priority to blocker since WildFly 19 shall be EAP 7.3.0.CD19 which is supposed to run on OpenShift. With this behavior health check is not very useful because:
* OpenShift starts the service wait some time and start asking for health status
* WildFly responses _UP_ yet application helathcheck is not installed yet
* With health status _UP_ OpenShift consider a pod ready
* In this point application is installed, health status is _DOWN_ (a DB is down) however OpenShift flow is somewhere else
was:
MicroProfile Health specification [link|https://github.com/eclipse/microprofile-health/blob/master/spec/src/...] says:
* A producer MUST support custom, application level health check procedures
* A producer SHOULD support reasonable out-of-the-box procedures
* A producer with no health check procedures expected or installed MUST return positive overall status (i.e. HTTP 200)
* A producer with health check procedures expected but not yet installed MUST return negative overall status (i.e. HTTP 503)
When I deploy and application with a readiness probe before WildFly is started, from my and namely OpenShift POV the health check procedure is expected from the very beginning.
_Let me note that on OpenShift starting the served should mean starting the service._
Hence I expect negative overall status till the probe is ready and is able to provide response.
However WildFly with default setting responses with status UP:
{code:bash}
while true; do echo $(date +"%T.%3N") ; curl localhost:9990/health/ready; echo ""; done
17:17:56.438 curl: (7) Failed to connect to localhost port 9990: Connection refused
17:17:56.452 curl: (7) Failed to connect to localhost port 9990: Connection refused
17:17:56.466 {"status":"UP","checks":[]}
...
17:18:01.121 {"status":"UP","checks":[]}
17:18:01.133 {"status":"DOWN","checks":[{"name":"delayed-readiness","status":"DOWN"}]}
{code}
This violates (4) bullet in the specification.
WildFly provides option to set global Status when probes are not defined ([documentation|https://doc-stage.usersys.redhat.com/documentation/en-us/re...])
Which would mean the scenario would behave according to the specification. Yet the default state violates it.
If the default value were _DOWN_ we would run into an issue if WildFly without deployment were used (for example as backup for AMQ). The status would be just DOWN:
{noformat}
17:22:41.719
{"status":"DOWN","checks":[]}
{noformat}
And that would violate (3) in the specification.
TCK tests do not cover the scenario well.
Is there a way to return _DOWN_ until WildFly scan a deployment and if no health check is found (thus not expected) then start to return _UP_ ? The scan should happen during MP Health initialization.
If there is no deployment, the _UP_ it is.
Setting the priority to blocker since WildFly 19 shall be EAP 7.3.0.CD19 which is supposed to run on OpenShift. With this behavior health check is not very useful because:
* OpenShift starts the service wait some time and start asking for health status
* WildFly responses _UP_ yet application helathcheck is not installed yet
* With health status _UP_ OpenShift consider a pod ready
* In this point application is installed, health status is _DOWN_ (a DB is down) however OpenShift flow is somewhere else
> MP Health returns UP when checks are expected but not installed yet.
> --------------------------------------------------------------------
>
> Key: WFLY-12952
> URL: https://issues.redhat.com/browse/WFLY-12952
> Project: WildFly
> Issue Type: Bug
> Components: MP Health
> Affects Versions: 18.0.0.Final
> Reporter: Ivan Straka
> Assignee: Jeff Mesnil
> Priority: Blocker
>
> MicroProfile Health 2.0 specification [link|https://github.com/eclipse/microprofile-health/blob/master/spec/src/...] says:
> * A producer MUST support custom, application level health check procedures
> * A producer SHOULD support reasonable out-of-the-box procedures
> * A producer with no health check procedures expected or installed MUST return positive overall status (i.e. HTTP 200)
> * A producer with health check procedures expected but not yet installed MUST return negative overall status (i.e. HTTP 503)
> When I deploy and application with a readiness probe before WildFly is started, from my and namely OpenShift POV the health check procedure is expected from the very beginning.
> _Let me note that on OpenShift starting the served should mean starting the service._
> Hence I expect negative overall status till the probe is ready and is able to provide response.
> However WildFly with default setting responses with status UP:
> {code:bash}
> while true; do echo $(date +"%T.%3N") ; curl localhost:9990/health/ready; echo ""; done
> 17:17:56.438 curl: (7) Failed to connect to localhost port 9990: Connection refused
> 17:17:56.452 curl: (7) Failed to connect to localhost port 9990: Connection refused
> 17:17:56.466 {"status":"UP","checks":[]}
> ...
> 17:18:01.121 {"status":"UP","checks":[]}
> 17:18:01.133 {"status":"DOWN","checks":[{"name":"delayed-readiness","status":"DOWN"}]}
> {code}
> This violates (4) bullet in the specification.
> WildFly provides option to set global Status when probes are not defined ([documentation|https://doc-stage.usersys.redhat.com/documentation/en-us/re...])
> Which would mean the scenario would behave according to the specification. Yet the default state violates it.
> If the default value were _DOWN_ we would run into an issue if WildFly without deployment were used (for example as backup for AMQ). The status would be just DOWN:
> {noformat}
> 17:22:41.719
> {"status":"DOWN","checks":[]}
> {noformat}
> And that would violate (3) in the specification.
> TCK tests do not cover the scenario well.
> Is there a way to return _DOWN_ until WildFly scan a deployment and if no health check is found (thus not expected) then start to return _UP_ ? The scan should happen during MP Health initialization.
> If there is no deployment, the _UP_ it is.
> Setting the priority to blocker since WildFly 19 shall be EAP 7.3.0.CD19 which is supposed to run on OpenShift. With this behavior health check is not very useful because:
> * OpenShift starts the service wait some time and start asking for health status
> * WildFly responses _UP_ yet application helathcheck is not installed yet
> * With health status _UP_ OpenShift consider a pod ready
> * In this point application is installed, health status is _DOWN_ (a DB is down) however OpenShift flow is somewhere else
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (WFLY-12952) MP Health returns UP when checks are expected but not installed yet.
by Ivan Straka (Jira)
[ https://issues.redhat.com/browse/WFLY-12952?page=com.atlassian.jira.plugi... ]
Ivan Straka updated WFLY-12952:
-------------------------------
Description:
MicroProfile Health 2.0 specification [link|https://github.com/eclipse/microprofile-health/blob/2.0/spec/src/mai...] says:
* A producer MUST support custom, application level health check procedures
* A producer SHOULD support reasonable out-of-the-box procedures
* A producer with no health check procedures expected or installed MUST return positive overall status (i.e. HTTP 200)
* A producer with health check procedures expected but not yet installed MUST return negative overall status (i.e. HTTP 503)
When I deploy and application with a readiness probe before WildFly is started, from my and namely OpenShift POV the health check procedure is expected from the very beginning.
_Let me note that on OpenShift starting the served should mean starting the service._
Hence I expect negative overall status till the probe is ready and is able to provide response.
However WildFly with default setting responses with status UP:
{code:bash}
while true; do echo $(date +"%T.%3N") ; curl localhost:9990/health/ready; echo ""; done
17:17:56.438 curl: (7) Failed to connect to localhost port 9990: Connection refused
17:17:56.452 curl: (7) Failed to connect to localhost port 9990: Connection refused
17:17:56.466 {"status":"UP","checks":[]}
...
17:18:01.121 {"status":"UP","checks":[]}
17:18:01.133 {"status":"DOWN","checks":[{"name":"delayed-readiness","status":"DOWN"}]}
{code}
This violates (4) bullet in the specification.
WildFly provides option to set global Status when probes are not defined ([documentation|https://doc-stage.usersys.redhat.com/documentation/en-us/re...])
Which would mean the scenario would behave according to the specification. Yet the default state violates it.
If the default value were _DOWN_ we would run into an issue if WildFly without deployment were used (for example as backup for AMQ). The status would be just DOWN:
{noformat}
17:22:41.719
{"status":"DOWN","checks":[]}
{noformat}
And that would violate (3) in the specification.
TCK tests do not cover the scenario well.
Is there a way to return _DOWN_ until WildFly scan a deployment and if no health check is found (thus not expected) then start to return _UP_ ? The scan should happen during MP Health initialization.
If there is no deployment, the _UP_ it is.
Setting the priority to blocker since WildFly 19 shall be EAP 7.3.0.CD19 which is supposed to run on OpenShift. With this behavior health check is not very useful because:
* OpenShift starts the service wait some time and start asking for health status
* WildFly responses _UP_ yet application helathcheck is not installed yet
* With health status _UP_ OpenShift consider a pod ready
* In this point application is installed, health status is _DOWN_ (a DB is down) however OpenShift flow is somewhere else
was:
MicroProfile Health 2.0 specification [link|https://github.com/eclipse/microprofile-health/blob/master/spec/src/...] says:
* A producer MUST support custom, application level health check procedures
* A producer SHOULD support reasonable out-of-the-box procedures
* A producer with no health check procedures expected or installed MUST return positive overall status (i.e. HTTP 200)
* A producer with health check procedures expected but not yet installed MUST return negative overall status (i.e. HTTP 503)
When I deploy and application with a readiness probe before WildFly is started, from my and namely OpenShift POV the health check procedure is expected from the very beginning.
_Let me note that on OpenShift starting the served should mean starting the service._
Hence I expect negative overall status till the probe is ready and is able to provide response.
However WildFly with default setting responses with status UP:
{code:bash}
while true; do echo $(date +"%T.%3N") ; curl localhost:9990/health/ready; echo ""; done
17:17:56.438 curl: (7) Failed to connect to localhost port 9990: Connection refused
17:17:56.452 curl: (7) Failed to connect to localhost port 9990: Connection refused
17:17:56.466 {"status":"UP","checks":[]}
...
17:18:01.121 {"status":"UP","checks":[]}
17:18:01.133 {"status":"DOWN","checks":[{"name":"delayed-readiness","status":"DOWN"}]}
{code}
This violates (4) bullet in the specification.
WildFly provides option to set global Status when probes are not defined ([documentation|https://doc-stage.usersys.redhat.com/documentation/en-us/re...])
Which would mean the scenario would behave according to the specification. Yet the default state violates it.
If the default value were _DOWN_ we would run into an issue if WildFly without deployment were used (for example as backup for AMQ). The status would be just DOWN:
{noformat}
17:22:41.719
{"status":"DOWN","checks":[]}
{noformat}
And that would violate (3) in the specification.
TCK tests do not cover the scenario well.
Is there a way to return _DOWN_ until WildFly scan a deployment and if no health check is found (thus not expected) then start to return _UP_ ? The scan should happen during MP Health initialization.
If there is no deployment, the _UP_ it is.
Setting the priority to blocker since WildFly 19 shall be EAP 7.3.0.CD19 which is supposed to run on OpenShift. With this behavior health check is not very useful because:
* OpenShift starts the service wait some time and start asking for health status
* WildFly responses _UP_ yet application helathcheck is not installed yet
* With health status _UP_ OpenShift consider a pod ready
* In this point application is installed, health status is _DOWN_ (a DB is down) however OpenShift flow is somewhere else
> MP Health returns UP when checks are expected but not installed yet.
> --------------------------------------------------------------------
>
> Key: WFLY-12952
> URL: https://issues.redhat.com/browse/WFLY-12952
> Project: WildFly
> Issue Type: Bug
> Components: MP Health
> Affects Versions: 18.0.0.Final
> Reporter: Ivan Straka
> Assignee: Jeff Mesnil
> Priority: Blocker
>
> MicroProfile Health 2.0 specification [link|https://github.com/eclipse/microprofile-health/blob/2.0/spec/src/mai...] says:
> * A producer MUST support custom, application level health check procedures
> * A producer SHOULD support reasonable out-of-the-box procedures
> * A producer with no health check procedures expected or installed MUST return positive overall status (i.e. HTTP 200)
> * A producer with health check procedures expected but not yet installed MUST return negative overall status (i.e. HTTP 503)
> When I deploy and application with a readiness probe before WildFly is started, from my and namely OpenShift POV the health check procedure is expected from the very beginning.
> _Let me note that on OpenShift starting the served should mean starting the service._
> Hence I expect negative overall status till the probe is ready and is able to provide response.
> However WildFly with default setting responses with status UP:
> {code:bash}
> while true; do echo $(date +"%T.%3N") ; curl localhost:9990/health/ready; echo ""; done
> 17:17:56.438 curl: (7) Failed to connect to localhost port 9990: Connection refused
> 17:17:56.452 curl: (7) Failed to connect to localhost port 9990: Connection refused
> 17:17:56.466 {"status":"UP","checks":[]}
> ...
> 17:18:01.121 {"status":"UP","checks":[]}
> 17:18:01.133 {"status":"DOWN","checks":[{"name":"delayed-readiness","status":"DOWN"}]}
> {code}
> This violates (4) bullet in the specification.
> WildFly provides option to set global Status when probes are not defined ([documentation|https://doc-stage.usersys.redhat.com/documentation/en-us/re...])
> Which would mean the scenario would behave according to the specification. Yet the default state violates it.
> If the default value were _DOWN_ we would run into an issue if WildFly without deployment were used (for example as backup for AMQ). The status would be just DOWN:
> {noformat}
> 17:22:41.719
> {"status":"DOWN","checks":[]}
> {noformat}
> And that would violate (3) in the specification.
> TCK tests do not cover the scenario well.
> Is there a way to return _DOWN_ until WildFly scan a deployment and if no health check is found (thus not expected) then start to return _UP_ ? The scan should happen during MP Health initialization.
> If there is no deployment, the _UP_ it is.
> Setting the priority to blocker since WildFly 19 shall be EAP 7.3.0.CD19 which is supposed to run on OpenShift. With this behavior health check is not very useful because:
> * OpenShift starts the service wait some time and start asking for health status
> * WildFly responses _UP_ yet application helathcheck is not installed yet
> * With health status _UP_ OpenShift consider a pod ready
> * In this point application is installed, health status is _DOWN_ (a DB is down) however OpenShift flow is somewhere else
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (WFWIP-294) JWT is rejected if signature matching public key is not first in JWK set
by Jan Kasik (Jira)
[ https://issues.redhat.com/browse/WFWIP-294?page=com.atlassian.jira.plugin... ]
Jan Kasik commented on WFWIP-294:
---------------------------------
I will sum up our discussion here: After fiddling with [~dlofthouse]'s quickstart project we found out that the issue is reproducible for {{mp.jwt.verify.publickey}}. With {{mp.jwt.verify.publickey.location}} it is not.
> JWT is rejected if signature matching public key is not first in JWK set
> ------------------------------------------------------------------------
>
> Key: WFWIP-294
> URL: https://issues.redhat.com/browse/WFWIP-294
> Project: WildFly WIP
> Issue Type: Bug
> Components: MP JWT
> Reporter: Jan Kasik
> Assignee: Darran Lofthouse
> Priority: Blocker
> Attachments: jwks.json, jwt.base64
>
>
> When public key on remote server is configured to be JWK set, the JWT which has correctly configured key ID to aim on matching public key from the set is rejected if matching public key is not on first position in the set array.
> This behavior is reproducible in the case the JWKS is set via {{mp.jwt.verify.publickey}} property.
> Attached is "flawed" key set with "blue-key" placed on first position in array when JOSE header has {{kid}} set to "orange-key" and JWT itself is signed by private key which is from "orange" key pair.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (DROOLS-4922) LinkageError: attempted duplicate class definition for materialized Lambda during incremental compilation
by Toshiya Kobayashi (Jira)
[ https://issues.redhat.com/browse/DROOLS-4922?page=com.atlassian.jira.plug... ]
Toshiya Kobayashi reassigned DROOLS-4922:
-----------------------------------------
Assignee: Toshiya Kobayashi (was: Luca Molteni)
> LinkageError: attempted duplicate class definition for materialized Lambda during incremental compilation
> ---------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-4922
> URL: https://issues.redhat.com/browse/DROOLS-4922
> Project: Drools
> Issue Type: Bug
> Components: executable model
> Reporter: Toshiya Kobayashi
> Assignee: Toshiya Kobayashi
> Priority: Major
>
> In case of incremental compilation, say, a rule is changed:
> - A lambda consequence (or a lambda predicate) has the same expression
> - But an "import" statement is added to the rule
> It will results in
> {noformat}
> [ERROR] testIdenticalConsequenceButImportChange[PATTERN_DSL](org.drools.modelcompiler.IncrementalCompilationTest) Time elapsed: 3.135 s <<< ERROR!
> java.lang.LinkageError: loader org.drools.dynamic.DynamicProjectClassLoader$DefaultInternalTypesClassLoader @2b0dc227 (instance of org.drools.dynamic.DynamicProjectClassLoader$DefaultInternalTypesClassLoader, child of 'app' jdk.internal.loader.ClassLoaders$AppClassLoader) attempted duplicate class definition for org.drools.test.LambdaConsequence6F5B5EC739B778AE0EE14FA22BAFE144.
> at java.base/java.lang.ClassLoader.defineClass1(Native Method)
> at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1016)
> at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:877)
> at org.drools.dynamic.DynamicProjectClassLoader$DefaultInternalTypesClassLoader.defineClass(DynamicProjectClassLoader.java:97)
> at org.drools.reflective.classloader.ProjectClassLoader.defineType(ProjectClassLoader.java:183)
> at org.drools.reflective.classloader.ProjectClassLoader.defineClass(ProjectClassLoader.java:195)
> at org.drools.compiler.kie.builder.impl.KieContainerImpl.reinitModifiedClasses(KieContainerImpl.java:323)
> at org.drools.compiler.kie.builder.impl.KieContainerImpl.update(KieContainerImpl.java:243)
> at org.drools.compiler.kie.builder.impl.KieContainerImpl.update(KieContainerImpl.java:236)
> at org.drools.compiler.kie.builder.impl.KieContainerImpl.updateToVersion(KieContainerImpl.java:194)
> at org.drools.modelcompiler.IncrementalCompilationTest.testIdenticalConsequenceButImportChange(IncrementalCompilationTest.java:257)
> ...
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (DROOLS-4922) LinkageError: attempted duplicate class definition for materialized Lambda during incremental compilation
by Toshiya Kobayashi (Jira)
[ https://issues.redhat.com/browse/DROOLS-4922?page=com.atlassian.jira.plug... ]
Toshiya Kobayashi updated DROOLS-4922:
--------------------------------------
Sprint: 2020 Week 01-03 (from Dec 30)
> LinkageError: attempted duplicate class definition for materialized Lambda during incremental compilation
> ---------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-4922
> URL: https://issues.redhat.com/browse/DROOLS-4922
> Project: Drools
> Issue Type: Bug
> Components: executable model
> Reporter: Toshiya Kobayashi
> Assignee: Toshiya Kobayashi
> Priority: Major
>
> In case of incremental compilation, say, a rule is changed:
> - A lambda consequence (or a lambda predicate) has the same expression
> - But an "import" statement is added to the rule
> It will results in
> {noformat}
> [ERROR] testIdenticalConsequenceButImportChange[PATTERN_DSL](org.drools.modelcompiler.IncrementalCompilationTest) Time elapsed: 3.135 s <<< ERROR!
> java.lang.LinkageError: loader org.drools.dynamic.DynamicProjectClassLoader$DefaultInternalTypesClassLoader @2b0dc227 (instance of org.drools.dynamic.DynamicProjectClassLoader$DefaultInternalTypesClassLoader, child of 'app' jdk.internal.loader.ClassLoaders$AppClassLoader) attempted duplicate class definition for org.drools.test.LambdaConsequence6F5B5EC739B778AE0EE14FA22BAFE144.
> at java.base/java.lang.ClassLoader.defineClass1(Native Method)
> at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1016)
> at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:877)
> at org.drools.dynamic.DynamicProjectClassLoader$DefaultInternalTypesClassLoader.defineClass(DynamicProjectClassLoader.java:97)
> at org.drools.reflective.classloader.ProjectClassLoader.defineType(ProjectClassLoader.java:183)
> at org.drools.reflective.classloader.ProjectClassLoader.defineClass(ProjectClassLoader.java:195)
> at org.drools.compiler.kie.builder.impl.KieContainerImpl.reinitModifiedClasses(KieContainerImpl.java:323)
> at org.drools.compiler.kie.builder.impl.KieContainerImpl.update(KieContainerImpl.java:243)
> at org.drools.compiler.kie.builder.impl.KieContainerImpl.update(KieContainerImpl.java:236)
> at org.drools.compiler.kie.builder.impl.KieContainerImpl.updateToVersion(KieContainerImpl.java:194)
> at org.drools.modelcompiler.IncrementalCompilationTest.testIdenticalConsequenceButImportChange(IncrementalCompilationTest.java:257)
> ...
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (DROOLS-4922) LinkageError: attempted duplicate class definition for materialized Lambda during incremental compilation
by Toshiya Kobayashi (Jira)
Toshiya Kobayashi created DROOLS-4922:
-----------------------------------------
Summary: LinkageError: attempted duplicate class definition for materialized Lambda during incremental compilation
Key: DROOLS-4922
URL: https://issues.redhat.com/browse/DROOLS-4922
Project: Drools
Issue Type: Bug
Components: executable model
Reporter: Toshiya Kobayashi
Assignee: Luca Molteni
In case of incremental compilation, say, a rule is changed:
- A lambda consequence (or a lambda predicate) has the same expression
- But an "import" statement is added to the rule
It will results in
{noformat}
[ERROR] testIdenticalConsequenceButImportChange[PATTERN_DSL](org.drools.modelcompiler.IncrementalCompilationTest) Time elapsed: 3.135 s <<< ERROR!
java.lang.LinkageError: loader org.drools.dynamic.DynamicProjectClassLoader$DefaultInternalTypesClassLoader @2b0dc227 (instance of org.drools.dynamic.DynamicProjectClassLoader$DefaultInternalTypesClassLoader, child of 'app' jdk.internal.loader.ClassLoaders$AppClassLoader) attempted duplicate class definition for org.drools.test.LambdaConsequence6F5B5EC739B778AE0EE14FA22BAFE144.
at java.base/java.lang.ClassLoader.defineClass1(Native Method)
at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1016)
at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:877)
at org.drools.dynamic.DynamicProjectClassLoader$DefaultInternalTypesClassLoader.defineClass(DynamicProjectClassLoader.java:97)
at org.drools.reflective.classloader.ProjectClassLoader.defineType(ProjectClassLoader.java:183)
at org.drools.reflective.classloader.ProjectClassLoader.defineClass(ProjectClassLoader.java:195)
at org.drools.compiler.kie.builder.impl.KieContainerImpl.reinitModifiedClasses(KieContainerImpl.java:323)
at org.drools.compiler.kie.builder.impl.KieContainerImpl.update(KieContainerImpl.java:243)
at org.drools.compiler.kie.builder.impl.KieContainerImpl.update(KieContainerImpl.java:236)
at org.drools.compiler.kie.builder.impl.KieContainerImpl.updateToVersion(KieContainerImpl.java:194)
at org.drools.modelcompiler.IncrementalCompilationTest.testIdenticalConsequenceButImportChange(IncrementalCompilationTest.java:257)
...
{noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (WFWIP-294) JWT is rejected if signature matching public key is not first in JWK set
by Jan Kasik (Jira)
[ https://issues.redhat.com/browse/WFWIP-294?page=com.atlassian.jira.plugin... ]
Jan Kasik updated WFWIP-294:
----------------------------
Description:
When public key on remote server is configured to be JWK set, the JWT which has correctly configured key ID to aim on matching public key from the set is rejected if matching public key is not on first position in the set array.
This behavior is reproducible in the case the JWKS is set via {{mp.jwt.verify.publickey}} property.
Attached is "flawed" key set with "blue-key" placed on first position in array when JOSE header has {{kid}} set to "orange-key" and JWT itself is signed by private key which is from "orange" key pair.
was:
When public key on remote server is configured to be JWK set, the JWT which has correctly configured key ID to aim on matching public key from the set is rejected if matching public key is not on first position in the set array.
Attached is "flawed" key set with "blue-key" placed on first position in array when JOSE header has {{kid}} set to "orange-key" and JWT itself is signed by private key which is from "orange" key pair.
> JWT is rejected if signature matching public key is not first in JWK set
> ------------------------------------------------------------------------
>
> Key: WFWIP-294
> URL: https://issues.redhat.com/browse/WFWIP-294
> Project: WildFly WIP
> Issue Type: Bug
> Components: MP JWT
> Reporter: Jan Kasik
> Assignee: Darran Lofthouse
> Priority: Blocker
> Attachments: jwks.json, jwt.base64
>
>
> When public key on remote server is configured to be JWK set, the JWT which has correctly configured key ID to aim on matching public key from the set is rejected if matching public key is not on first position in the set array.
> This behavior is reproducible in the case the JWKS is set via {{mp.jwt.verify.publickey}} property.
> Attached is "flawed" key set with "blue-key" placed on first position in array when JOSE header has {{kid}} set to "orange-key" and JWT itself is signed by private key which is from "orange" key pair.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (DROOLS-4698) Adding "expression" type handling for Collection type propereties
by Jozef Marko (Jira)
[ https://issues.redhat.com/browse/DROOLS-4698?page=com.atlassian.jira.plug... ]
Jozef Marko commented on DROOLS-4698:
-------------------------------------
[~yamer] understood. I reported DROOLS-4920 and DROOLS-4921 as requested.
> Adding "expression" type handling for Collection type propereties
> -----------------------------------------------------------------
>
> Key: DROOLS-4698
> URL: https://issues.redhat.com/browse/DROOLS-4698
> Project: Drools
> Issue Type: Feature Request
> Components: Scenario Simulation and Testing
> Reporter: Yeser Amer
> Assignee: Yeser Amer
> Priority: Major
> Labels: UX, UXTeam, drools-tools
> Attachments: Screenshot from 2020-01-08 14-14-05.png, Screenshot from 2020-01-08 14-20-30.png, Screenshot from 2020-01-08 14-36-33.png, Screenshot from 2020-01-08 14-36-52.png, test urgent.scesim, urgent.dmn
>
>
> Support is about both drools/java collections and dmn collections.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (DROOLS-4921) Scrollbars in collection editor popup do not work
by Jozef Marko (Jira)
[ https://issues.redhat.com/browse/DROOLS-4921?page=com.atlassian.jira.plug... ]
Jozef Marko updated DROOLS-4921:
--------------------------------
Steps to Reproduce:
# Run business-central
# Open any project
# Prepare java data object with a collection field, e.g. Person with List of children
# Create new rule base Test Scenario
# Bind any column as instance: Person, property: children
# Double click any data cell corresponding to your column
# The collection editor will be shown
# Try to scroll with mouse wheel
> Scrollbars in collection editor popup do not work
> -------------------------------------------------
>
> Key: DROOLS-4921
> URL: https://issues.redhat.com/browse/DROOLS-4921
> Project: Drools
> Issue Type: Bug
> Components: Scenario Simulation and Testing
> Affects Versions: 7.31.0.Final
> Reporter: Jozef Marko
> Assignee: Yeser Amer
> Priority: Major
> Labels: drools-tools
> Attachments: Screenshot from 2020-01-08 14-20-30.png
>
>
> Scrollbars in the popup do not work rolling wheel on mouse. User can just click on it and drag manually.
> !Screenshot from 2020-01-08 14-20-30.png|thumbnail!
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (DROOLS-4921) Scrollbars in collection editor popup do not work
by Jozef Marko (Jira)
[ https://issues.redhat.com/browse/DROOLS-4921?page=com.atlassian.jira.plug... ]
Jozef Marko updated DROOLS-4921:
--------------------------------
Description:
Scrollbars in the popup do not work rolling wheel on mouse. User can just click on it and drag manually.
!Screenshot from 2020-01-08 14-20-30.png|thumbnail!
was:Support is about both drools/java collections and dmn collections.
> Scrollbars in collection editor popup do not work
> -------------------------------------------------
>
> Key: DROOLS-4921
> URL: https://issues.redhat.com/browse/DROOLS-4921
> Project: Drools
> Issue Type: Bug
> Components: Scenario Simulation and Testing
> Affects Versions: 7.31.0.Final
> Reporter: Jozef Marko
> Assignee: Yeser Amer
> Priority: Major
> Labels: drools-tools
> Attachments: Screenshot from 2020-01-08 14-20-30.png
>
>
> Scrollbars in the popup do not work rolling wheel on mouse. User can just click on it and drag manually.
> !Screenshot from 2020-01-08 14-20-30.png|thumbnail!
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (DROOLS-4920) Scenario simulation for DMN with collections throws en error
by Jozef Marko (Jira)
[ https://issues.redhat.com/browse/DROOLS-4920?page=com.atlassian.jira.plug... ]
Jozef Marko updated DROOLS-4920:
--------------------------------
Steps to Reproduce:
# Run business-central
# Open a project
# Import the attached DMN into the project (project -> Import asset)
# Try to create a tests scenario for the given DMN (add -> new -> test scenario)
> Scenario simulation for DMN with collections throws en error
> ------------------------------------------------------------
>
> Key: DROOLS-4920
> URL: https://issues.redhat.com/browse/DROOLS-4920
> Project: Drools
> Issue Type: Bug
> Components: Scenario Simulation and Testing
> Affects Versions: 7.31.0.Final
> Reporter: Jozef Marko
> Assignee: Yeser Amer
> Priority: Major
> Labels: drools-tools
> Attachments: Screenshot from 2020-01-08 14-14-05.png, urgent.dmn
>
>
> If a user tries to create a test scenario for [^urgent.dmn] he will get a [1] even when he is creating test scenario for the first time.
> [1]
> !Screenshot from 2020-01-08 14-14-05.png|thumbnail!
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (DROOLS-4921) Scrollbars in collection editor popup do not work
by Jozef Marko (Jira)
Jozef Marko created DROOLS-4921:
-----------------------------------
Summary: Scrollbars in collection editor popup do not work
Key: DROOLS-4921
URL: https://issues.redhat.com/browse/DROOLS-4921
Project: Drools
Issue Type: Feature Request
Components: Scenario Simulation and Testing
Reporter: Jozef Marko
Assignee: Yeser Amer
Attachments: Screenshot from 2020-01-08 14-20-30.png, Screenshot from 2020-01-08 14-36-33.png, Screenshot from 2020-01-08 14-36-52.png, test urgent.scesim, urgent.dmn
Support is about both drools/java collections and dmn collections.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (DROOLS-4921) Scrollbars in collection editor popup do not work
by Jozef Marko (Jira)
[ https://issues.redhat.com/browse/DROOLS-4921?page=com.atlassian.jira.plug... ]
Jozef Marko updated DROOLS-4921:
--------------------------------
Attachment: (was: Screenshot from 2020-01-08 14-14-05.png)
> Scrollbars in collection editor popup do not work
> -------------------------------------------------
>
> Key: DROOLS-4921
> URL: https://issues.redhat.com/browse/DROOLS-4921
> Project: Drools
> Issue Type: Bug
> Components: Scenario Simulation and Testing
> Affects Versions: 7.31.0.Final
> Reporter: Jozef Marko
> Assignee: Yeser Amer
> Priority: Major
> Labels: UX, UXTeam, drools-tools
> Attachments: Screenshot from 2020-01-08 14-20-30.png, Screenshot from 2020-01-08 14-36-33.png, Screenshot from 2020-01-08 14-36-52.png, test urgent.scesim, urgent.dmn
>
>
> Support is about both drools/java collections and dmn collections.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (DROOLS-4920) Scenario simulation for DMN with collections throws en error
by Jozef Marko (Jira)
[ https://issues.redhat.com/browse/DROOLS-4920?page=com.atlassian.jira.plug... ]
Jozef Marko updated DROOLS-4920:
--------------------------------
Description:
If a user tries to create a test scenario for [^urgent.dmn] he will get a [1] even when he is creating test scenario for the first time.
[1]
!Screenshot from 2020-01-08 14-14-05.png|thumbnail!
was:Support is about both drools/java collections and dmn collections.
> Scenario simulation for DMN with collections throws en error
> ------------------------------------------------------------
>
> Key: DROOLS-4920
> URL: https://issues.redhat.com/browse/DROOLS-4920
> Project: Drools
> Issue Type: Bug
> Components: Scenario Simulation and Testing
> Affects Versions: 7.31.0.Final
> Reporter: Jozef Marko
> Assignee: Yeser Amer
> Priority: Major
> Labels: drools-tools
> Attachments: Screenshot from 2020-01-08 14-14-05.png, urgent.dmn
>
>
> If a user tries to create a test scenario for [^urgent.dmn] he will get a [1] even when he is creating test scenario for the first time.
> [1]
> !Screenshot from 2020-01-08 14-14-05.png|thumbnail!
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (DROOLS-4920) Scenario simulation for DMN with collections throws en error
by Jozef Marko (Jira)
[ https://issues.redhat.com/browse/DROOLS-4920?page=com.atlassian.jira.plug... ]
Jozef Marko updated DROOLS-4920:
--------------------------------
Attachment: (was: Screenshot from 2020-01-08 14-20-30.png)
> Scenario simulation for DMN with collections throws en error
> ------------------------------------------------------------
>
> Key: DROOLS-4920
> URL: https://issues.redhat.com/browse/DROOLS-4920
> Project: Drools
> Issue Type: Bug
> Components: Scenario Simulation and Testing
> Affects Versions: 7.31.0.Final
> Reporter: Jozef Marko
> Assignee: Yeser Amer
> Priority: Major
> Labels: drools-tools
> Attachments: Screenshot from 2020-01-08 14-14-05.png, urgent.dmn
>
>
> If a user tries to create a test scenario for [^urgent.dmn] he will get a [1] even when he is creating test scenario for the first time.
> [1]
> !Screenshot from 2020-01-08 14-14-05.png|thumbnail!
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (DROOLS-4920) Scenario simulation for DMN with collections throws en error
by Jozef Marko (Jira)
[ https://issues.redhat.com/browse/DROOLS-4920?page=com.atlassian.jira.plug... ]
Jozef Marko updated DROOLS-4920:
--------------------------------
Attachment: (was: Screenshot from 2020-01-08 14-36-33.png)
> Scenario simulation for DMN with collections throws en error
> ------------------------------------------------------------
>
> Key: DROOLS-4920
> URL: https://issues.redhat.com/browse/DROOLS-4920
> Project: Drools
> Issue Type: Bug
> Components: Scenario Simulation and Testing
> Affects Versions: 7.31.0.Final
> Reporter: Jozef Marko
> Assignee: Yeser Amer
> Priority: Major
> Labels: drools-tools
> Attachments: Screenshot from 2020-01-08 14-14-05.png, urgent.dmn
>
>
> If a user tries to create a test scenario for [^urgent.dmn] he will get a [1] even when he is creating test scenario for the first time.
> [1]
> !Screenshot from 2020-01-08 14-14-05.png|thumbnail!
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (DROOLS-4920) Scenario simulation for DMN with collections throws en error
by Jozef Marko (Jira)
[ https://issues.redhat.com/browse/DROOLS-4920?page=com.atlassian.jira.plug... ]
Jozef Marko updated DROOLS-4920:
--------------------------------
Attachment: (was: Screenshot from 2020-01-08 14-36-52.png)
> Scenario simulation for DMN with collections throws en error
> ------------------------------------------------------------
>
> Key: DROOLS-4920
> URL: https://issues.redhat.com/browse/DROOLS-4920
> Project: Drools
> Issue Type: Bug
> Components: Scenario Simulation and Testing
> Affects Versions: 7.31.0.Final
> Reporter: Jozef Marko
> Assignee: Yeser Amer
> Priority: Major
> Labels: drools-tools
> Attachments: Screenshot from 2020-01-08 14-14-05.png, urgent.dmn
>
>
> If a user tries to create a test scenario for [^urgent.dmn] he will get a [1] even when he is creating test scenario for the first time.
> [1]
> !Screenshot from 2020-01-08 14-14-05.png|thumbnail!
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (DROOLS-4920) Scenario simulation for DMN with collections throws en error
by Jozef Marko (Jira)
Jozef Marko created DROOLS-4920:
-----------------------------------
Summary: Scenario simulation for DMN with collections throws en error
Key: DROOLS-4920
URL: https://issues.redhat.com/browse/DROOLS-4920
Project: Drools
Issue Type: Feature Request
Components: Scenario Simulation and Testing
Reporter: Jozef Marko
Assignee: Yeser Amer
Attachments: Screenshot from 2020-01-08 14-14-05.png, Screenshot from 2020-01-08 14-20-30.png, Screenshot from 2020-01-08 14-36-33.png, Screenshot from 2020-01-08 14-36-52.png, test urgent.scesim, urgent.dmn
Support is about both drools/java collections and dmn collections.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (WFCORE-2147) Impossible to use environment variables or system properties in permissions.xml and jboss-permissions.xml
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFCORE-2147?page=com.atlassian.jira.plug... ]
Brian Stansberry edited comment on WFCORE-2147 at 1/9/20 6:18 PM:
------------------------------------------------------------------
I resolved this as the WF Core part of this has been merged, but for the overall high-level feature to be done the related issue in full WildFly still need completion (i.e. WF Core upgraded with this and the related PR merged.)
^^^ is for the benefit of anyone reading this who is interested. The folks doing the feature know this already. :)
was (Author: brian.stansberry):
I resolved this as the WF Core part of this has been merged, but for the overall high-level feature to be done the related issue in full WildFly still need completion (i.e. WF Core upgraded with this and the related PR merged.)
> Impossible to use environment variables or system properties in permissions.xml and jboss-permissions.xml
> ---------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-2147
> URL: https://issues.redhat.com/browse/WFCORE-2147
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Security
> Reporter: Adrian Boangiu
> Assignee: Yeray Borges
> Priority: Major
> Fix For: 11.0.0.Beta7
>
>
> Without this feature it is impossible to migrate "variable" Java file permissions such as:
> {noformat}
> permission java.io.FilePermission "${java.io.tmpdir}","read";
> permission java.io.FilePermission "${jboss.home.dir}${/}bin${/}javamelody${/}-","read,write,delete";
> permission java.io.FilePermission "${app.home.dir}${/}log${/}-","read,write,delete";
> {noformat}
> that were defined in Java policy file in previous verions of JBoss.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (DROOLS-4919) Long running query at kie-server startup
by Danny Rucker (Jira)
Danny Rucker created DROOLS-4919:
------------------------------------
Summary: Long running query at kie-server startup
Key: DROOLS-4919
URL: https://issues.redhat.com/browse/DROOLS-4919
Project: Drools
Issue Type: Bug
Components: kie server
Affects Versions: 7.28.0.Final
Reporter: Danny Rucker
Assignee: Maciej Swiderski
The following query is executed at start up of kie-server
```
select vil.processInstanceId, vil.processId, vil.id, vil.variableId, vil.value from VariableInstanceLog vil where vil.id in (select MAX(v.id) from VariableInstanceLog v group by v.variableId, v.processInstanceId)
```
This is causing some issues with getting kie-server to start up.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (WFLY-12954) Web sessions passivated on shutdown even if the cache store purges on startup
by Paul Ferraro (Jira)
[ https://issues.redhat.com/browse/WFLY-12954?page=com.atlassian.jira.plugi... ]
Paul Ferraro moved JBEAP-18446 to WFLY-12954:
---------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-12954 (was: JBEAP-18446)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Clustering
(was: Clustering)
Affects Version/s: 18.0.1.Final
(was: 7.2.5.GA)
> Web sessions passivated on shutdown even if the cache store purges on startup
> -----------------------------------------------------------------------------
>
> Key: WFLY-12954
> URL: https://issues.redhat.com/browse/WFLY-12954
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 18.0.1.Final
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Priority: Major
>
> With the default HA configuration, when a <distributable/> web application is stopped its sessions are persisted to disk. No max-active-sessions configuration used.
> This is a performance issue. It does not affect functionality, because the store is purged on startup.
> It affects all EAP 7 versions tested. It does not occur in EAP 6.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (WFLY-12953) Delete any existing licenses.html before transforming to create a new one
by Brian Stansberry (Jira)
Brian Stansberry created WFLY-12953:
---------------------------------------
Summary: Delete any existing licenses.html before transforming to create a new one
Key: WFLY-12953
URL: https://issues.redhat.com/browse/WFLY-12953
Project: WildFly
Issue Type: Enhancement
Components: Build System
Reporter: Brian Stansberry
Assignee: Brian Stansberry
If the transform task in the tasks.xml from the docs.licenses.merge galleon package from more than one f-p gets executed it will fail because the first task to run will create a licenses.html and 'transform' will fail if the target file already exists. So as a safety measure have the tasks delete any such file before doing the transform.
AIUI a fix for GAL-305 will remove the need for this by preventing more than one docs.licenses.merge package being provisioned, but having this in there will do no harm and makes things a bit more robust.
Also, remove the crufty 'alternative-tasks.xml' files from these docs.licenses.merge packages.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (JBMETA-418) Validation error with "jboss-web_14_0.xsd"
by Wolfgang Knauf (Jira)
[ https://issues.redhat.com/browse/JBMETA-418?page=com.atlassian.jira.plugi... ]
Wolfgang Knauf updated JBMETA-418:
----------------------------------
Description:
I build a "jboss-web.xml" file referencing jboss-web_14_0.xsd (bundled with WildFly 18), using Eclipse IDE:
{noformat}
<?xml version="1.0" encoding="UTF-8"?>
<jboss-web xmlns="http://www.jboss.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.jboss.com/xml/ns/javaee http://www.jboss.org/schema/jbossas/jboss-web_14_0.xsd"
version="14.0">
<context-root>MyWebProject</context-root>
</jboss-web>
{noformat}
Eclipse shows validation errors deep in jboss_web_14_0.xsd.
Unfortunately, I can not copy from nested validation errors.
So I will attach a screenshot and type one of the error lines:
{noformat}
sch-props-correct.2: A schema cannot contain two global components with the same name; this schema contains two occurences of 'http://xmlns.jcp.org/xml/ns/javaee,descriptionGroup'
{noformat}
The reason seems to be that "jboss-web_14_0.xsd" imports two files:
* "web-app_4_0.xsd" which imports "web-common_4_0.xsd" which imports "javaee_7.xsd".
* "jboss-common_8_0.xsd" which imports "javaee_8.xsd"
This is quite confusing, as the JavaEE8 standard has a lot of XSD files which import "javaee_7.xsd": [JavaEE schemas|https://www.oracle.com/webfolder/technetwork/jsc/xml/ns/javaee/in...]
It should work if "jboss-web_14_0.xsd" imports "jboss-common_7_1.xsd" and thus "javaee_7.xsd". I don't see any relevant differences beetween "jboss-common_7_1.xsd" and "jboss-common_8_0.xsd", so this should be possible.
was:
I build a "jboss-web.xml" file referencing jboss-web_14_0.xsd (bundled with WildFly 18), using Eclipse IDE:
{noformat}
<?xml version="1.0" encoding="UTF-8"?>
<jboss-web xmlns="http://www.jboss.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.jboss.com/xml/ns/javaee http://www.jboss.org/schema/jbossas/jboss-web_14_0.xsd"
version="14.0">
<context-root>MyWebProject</context-root>
</jboss-web>
{noformat}
Eclipse shows validation errors deep in jboss_web_14_0.xsd.
Unfortunately, I can not copy from nested validation errors.
So I will attach a screenshot and type one of the error lines:
sch-props-correct.2: A schema cannot contain two global components with the same name; this schema contains two occurences of 'http://xmlns.jcp.org/xml/ns/javaee,descriptionGroup'
The reason seems to be that "jboss-web_14_0.xsd" imports two files:
* "web-app_4_0.xsd" which imports "web-common_4_0.xsd" which imports "javaee_7.xsd".
* "jboss-common_8_0.xsd" which imports "javaee_8.xsd"
This is quite confusing, as the JavaEE8 standard has a lot of XSD files which import "javaee_7.xsd": [JavaEE schemas|https://www.oracle.com/webfolder/technetwork/jsc/xml/ns/javaee/in...]
It should work if "jboss-web_14_0.xsd" imports "jboss-common_7_1.xsd" and thus "javaee_7.xsd". I don't see any relevant differences beetween "jboss-common_7_1.xsd" and "jboss-common_8_0.xsd", so this should be possible.
> Validation error with "jboss-web_14_0.xsd"
> ------------------------------------------
>
> Key: JBMETA-418
> URL: https://issues.redhat.com/browse/JBMETA-418
> Project: JBoss Metadata
> Issue Type: Bug
> Components: web
> Affects Versions: 12.0.0.Final
> Reporter: Wolfgang Knauf
> Assignee: Jean-Frederic Clere
> Priority: Major
> Attachments: validationerror.png
>
>
> I build a "jboss-web.xml" file referencing jboss-web_14_0.xsd (bundled with WildFly 18), using Eclipse IDE:
> {noformat}
> <?xml version="1.0" encoding="UTF-8"?>
> <jboss-web xmlns="http://www.jboss.com/xml/ns/javaee"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="http://www.jboss.com/xml/ns/javaee http://www.jboss.org/schema/jbossas/jboss-web_14_0.xsd"
> version="14.0">
> <context-root>MyWebProject</context-root>
> </jboss-web>
> {noformat}
> Eclipse shows validation errors deep in jboss_web_14_0.xsd.
> Unfortunately, I can not copy from nested validation errors.
> So I will attach a screenshot and type one of the error lines:
> {noformat}
> sch-props-correct.2: A schema cannot contain two global components with the same name; this schema contains two occurences of 'http://xmlns.jcp.org/xml/ns/javaee,descriptionGroup'
> {noformat}
> The reason seems to be that "jboss-web_14_0.xsd" imports two files:
> * "web-app_4_0.xsd" which imports "web-common_4_0.xsd" which imports "javaee_7.xsd".
> * "jboss-common_8_0.xsd" which imports "javaee_8.xsd"
> This is quite confusing, as the JavaEE8 standard has a lot of XSD files which import "javaee_7.xsd": [JavaEE schemas|https://www.oracle.com/webfolder/technetwork/jsc/xml/ns/javaee/in...]
> It should work if "jboss-web_14_0.xsd" imports "jboss-common_7_1.xsd" and thus "javaee_7.xsd". I don't see any relevant differences beetween "jboss-common_7_1.xsd" and "jboss-common_8_0.xsd", so this should be possible.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (JBMETA-418) Validation error with "jboss-web_14_0.xsd"
by Wolfgang Knauf (Jira)
[ https://issues.redhat.com/browse/JBMETA-418?page=com.atlassian.jira.plugi... ]
Wolfgang Knauf updated JBMETA-418:
----------------------------------
Description:
I build a "jboss-web.xml" file referencing jboss-web_14_0.xsd (bundled with WildFly 18), using Eclipse IDE:
{noformat}
<?xml version="1.0" encoding="UTF-8"?>
<jboss-web xmlns="http://www.jboss.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.jboss.com/xml/ns/javaee http://www.jboss.org/schema/jbossas/jboss-web_14_0.xsd"
version="14.0">
<context-root>MyWebProject</context-root>
</jboss-web>
{noformat}
Eclipse shows validation errors deep in jboss_web_14_0.xsd.
Unfortunately, I can not copy from nested validation errors.
So I will attach a screenshot and type one of the error lines:
sch-props-correct.2: A schema cannot contain two global components with the same name; this schema contains two occurences of 'http://xmlns.jcp.org/xml/ns/javaee,descriptionGroup'
The reason seems to be that "jboss-web_14_0.xsd" imports two files:
* "web-app_4_0.xsd" which imports "web-common_4_0.xsd" which imports "javaee_7.xsd".
* "jboss-common_8_0.xsd" which imports "javaee_8.xsd"
This is quite confusing, as the JavaEE8 standard has a lot of XSD files which import "javaee_7.xsd": [JavaEE schemas|https://www.oracle.com/webfolder/technetwork/jsc/xml/ns/javaee/in...]
It should work if "jboss-web_14_0.xsd" imports "jboss-common_7_1.xsd" and thus "javaee_7.xsd". I don't see any relevant differences beetween "jboss-common_7_1.xsd" and "jboss-common_8_0.xsd", so this should be possible.
was:
I build a "jboss-web.xml" file referencing jboss-web_14_0.xsd (bundled with WildFly 18), using Eclipse IDE:
{noformat}
{{<?xml version="1.0" encoding="UTF-8"?>
<jboss-web xmlns="http://www.jboss.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.jboss.com/xml/ns/javaee http://www.jboss.org/schema/jbossas/jboss-web_14_0.xsd"
version="14.0">
<context-root>MyWebProject</context-root>
</jboss-web>}}
{noformat}
Eclipse shows validation errors deep in jboss_web_14_0.xsd.
Unfortunately, I can not copy from nested validation errors.
So I will attach a screenshot and type one of the error lines:
sch-props-correct.2: A schema cannot contain two global components with the same name; this schema contains two occurences of 'http://xmlns.jcp.org/xml/ns/javaee,descriptionGroup'
The reason seems to be that "jboss-web_14_0.xsd" imports two files:
* "web-app_4_0.xsd" which imports "web-common_4_0.xsd" which imports "javaee_7.xsd".
* "jboss-common_8_0.xsd" which imports "javaee_8.xsd"
This is quite confusing, as the JavaEE8 standard has a lot of XSD files which import "javaee_7.xsd": [JavaEE schemas|https://www.oracle.com/webfolder/technetwork/jsc/xml/ns/javaee/in...]
It should work if "jboss-web_14_0.xsd" imports "jboss-common_7_1.xsd" and thus "javaee_7.xsd". I don't see any relevant differences beetween "jboss-common_7_1.xsd" and "jboss-common_8_0.xsd", so this should be possible.
> Validation error with "jboss-web_14_0.xsd"
> ------------------------------------------
>
> Key: JBMETA-418
> URL: https://issues.redhat.com/browse/JBMETA-418
> Project: JBoss Metadata
> Issue Type: Bug
> Components: web
> Affects Versions: 12.0.0.Final
> Reporter: Wolfgang Knauf
> Assignee: Jean-Frederic Clere
> Priority: Major
> Attachments: validationerror.png
>
>
> I build a "jboss-web.xml" file referencing jboss-web_14_0.xsd (bundled with WildFly 18), using Eclipse IDE:
> {noformat}
> <?xml version="1.0" encoding="UTF-8"?>
> <jboss-web xmlns="http://www.jboss.com/xml/ns/javaee"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="http://www.jboss.com/xml/ns/javaee http://www.jboss.org/schema/jbossas/jboss-web_14_0.xsd"
> version="14.0">
> <context-root>MyWebProject</context-root>
> </jboss-web>
> {noformat}
> Eclipse shows validation errors deep in jboss_web_14_0.xsd.
> Unfortunately, I can not copy from nested validation errors.
> So I will attach a screenshot and type one of the error lines:
> sch-props-correct.2: A schema cannot contain two global components with the same name; this schema contains two occurences of 'http://xmlns.jcp.org/xml/ns/javaee,descriptionGroup'
> The reason seems to be that "jboss-web_14_0.xsd" imports two files:
> * "web-app_4_0.xsd" which imports "web-common_4_0.xsd" which imports "javaee_7.xsd".
> * "jboss-common_8_0.xsd" which imports "javaee_8.xsd"
> This is quite confusing, as the JavaEE8 standard has a lot of XSD files which import "javaee_7.xsd": [JavaEE schemas|https://www.oracle.com/webfolder/technetwork/jsc/xml/ns/javaee/in...]
> It should work if "jboss-web_14_0.xsd" imports "jboss-common_7_1.xsd" and thus "javaee_7.xsd". I don't see any relevant differences beetween "jboss-common_7_1.xsd" and "jboss-common_8_0.xsd", so this should be possible.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (JBJCA-1347) NullPointerException in SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:441
by Piotr Krokowski (Jira)
[ https://issues.redhat.com/browse/JBJCA-1347?page=com.atlassian.jira.plugi... ]
Piotr Krokowski commented on JBJCA-1347:
----------------------------------------
Hello. I'm getting a bit desperate, because I can't find this info anywhere, so adding this comment here is my last hope.
Main question is: *In which version was that fix included?*
Background:
We started to get into this issue massively after datacenter changes (so the root cause is unrelated - probably connections are closed too eagerly on the DB side).
Some notable fragments from exceptions (issue happens while INVALIDATING a connection):
{{Caused by: java.lang.NullPointerException at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.getConnection(SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:461)}}
Depending on desired behavior (which us unknown to me), it either seems to be an issue in:
SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:461 and line 441.
or it could be the fact, that pool.getInternalStatistics() should not be nullified by another thread, while another thread is trying to do the same.
It's hard to tell not knowing the concept.
Please help...
> NullPointerException in SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:441
> ------------------------------------------------------------------------------------
>
> Key: JBJCA-1347
> URL: https://issues.redhat.com/browse/JBJCA-1347
> Project: IronJacamar
> Issue Type: Bug
> Affects Versions: WildFly/IronJacamar 1.3.2.Final
> Environment: CentOS 6
> Wildfly 10.0.0.Final (Iron Jacamar 1.3.2.Final)
> PostgreSQL Server 9.5.5
> PostgreSQL JDBC driver 9.4.1208 and tried with 42.0.0
> Oracle Java version "1.8.0_112"
> Java(TM) SE Runtime Environment (build 1.8.0_112-b15)
> Java HotSpot(TM) 64-Bit Server VM (build 25.112-b15, mixed mode)
> Reporter: Brett Delle Grazie
> Assignee: Flavia Rainone
> Priority: Major
>
> Using a PostgreSQL XA datasource with statistics enabled we get a NullPointerException if the connection fails temporarily.
> With JDBC driver 9.4.1208 Wildfly never reconnects to the PostgreSQL server with the next request and Wildfly must be restarted. With JDBC driver 42.0.0 it does reconnect on next request.
> If statistics are disabled, the NPE does not occur and both drivers reconnect on the next request as expected.
> Specific location of NPE:
> https://github.com/ironjacamar/ironjacamar/blob/ironjacamar-1.3.2.Final/c...
> Note there is similar code on line 461 of the same class (in the exception handler)
> Example configuration follows
> With a PostgreSQL datasource configured in Wildfly as:
> {code:xml}
> <xa-datasource jndi-name="java:/DS.people" pool-name="DS.people" enabled="true" spy="true" statistics-enabled="true" use-java-context="true" use-ccm="true">
> <driver>postgresql</driver>
> <xa-datasource-property name="ServerName">localhost</xa-datasource-property>
> <xa-datasource-property name="PortNumber">5432</xa-datasource-property>
> <xa-datasource-property name="DatabaseName">peopleviewstore</xa-datasource-property>
> <xa-datasource-property name="ApplicationName">people</xa-datasource-property>
> <xa-datasource-property name="assumeMinServerVersion">9.5</xa-datasource-property>
> <xa-datasource-property name="connectTimeout">10</xa-datasource-property>
> <xa-datasource-property name="currentSchema">public</xa-datasource-property>
> <xa-datasource-property name="hostRecheckSeconds">10</xa-datasource-property>
> <xa-datasource-property name="loginTimeout">10</xa-datasource-property>
> <xa-datasource-property name="logUnclosedConnections">true</xa-datasource-property>
> <xa-datasource-property name="socketTimeout">30</xa-datasource-property>
> <xa-datasource-property name="targetServerType">master</xa-datasource-property>
> <xa-datasource-property name="tcpKeepAlive">true</xa-datasource-property>
> <xa-pool>
> <min-pool-size>0</min-pool-size>
> <initial-pool-size>0</initial-pool-size>
> <max-pool-size>10</max-pool-size>
> <allow-multiple-users>false</allow-multiple-users>
> </xa-pool>
> <timeout>
> <xa-resource-timeout>0</xa-resource-timeout>
> </timeout>
> <transaction-isolation>TRANSACTION_READ_COMMITTED</transaction-isolation>
> <statement>
> <track-statements>true</track-statements>
> </statement>
> <security>
> <user-name></user-name>
> <password></password>
> </security>
> <validation>
> <validate-on-match>true</validate-on-match>
> <use-fast-fail>true</use-fast-fail>
> <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLExceptionSorter"/>
> <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLValidConnectionChecker"/>
> </validation>
> </xa-datasource>
> {code}
> And corresponding driver configuration:
> {code:xml}
> <driver name="postgresql" module="org.postgresql">
> <xa-datasource-class>org.postgresql.xa.PGXADataSource</xa-datasource-class>
> </driver>
> {code}
> we have deployed the JDBC driver as a module, module.xml looks like:
> {code:xml}
> <?xml version="1.0" ?>
> <module xmlns="urn:jboss:module:1.3" name="org.postgresql" slot="main">
> <resources>
> <resource-root path="postgresql-42.0.0.jar"/>
> </resources>
> <dependencies>
> <module name="javax.api"/>
> <module name="javax.transaction.api"/>
> </dependencies>
> </module>
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (JBJCA-1347) NullPointerException in SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:441
by Piotr Krokowski (Jira)
[ https://issues.redhat.com/browse/JBJCA-1347?page=com.atlassian.jira.plugi... ]
Piotr Krokowski commented on JBJCA-1347:
----------------------------------------
And sorry for double comment :'(
> NullPointerException in SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:441
> ------------------------------------------------------------------------------------
>
> Key: JBJCA-1347
> URL: https://issues.redhat.com/browse/JBJCA-1347
> Project: IronJacamar
> Issue Type: Bug
> Affects Versions: WildFly/IronJacamar 1.3.2.Final
> Environment: CentOS 6
> Wildfly 10.0.0.Final (Iron Jacamar 1.3.2.Final)
> PostgreSQL Server 9.5.5
> PostgreSQL JDBC driver 9.4.1208 and tried with 42.0.0
> Oracle Java version "1.8.0_112"
> Java(TM) SE Runtime Environment (build 1.8.0_112-b15)
> Java HotSpot(TM) 64-Bit Server VM (build 25.112-b15, mixed mode)
> Reporter: Brett Delle Grazie
> Assignee: Flavia Rainone
> Priority: Major
>
> Using a PostgreSQL XA datasource with statistics enabled we get a NullPointerException if the connection fails temporarily.
> With JDBC driver 9.4.1208 Wildfly never reconnects to the PostgreSQL server with the next request and Wildfly must be restarted. With JDBC driver 42.0.0 it does reconnect on next request.
> If statistics are disabled, the NPE does not occur and both drivers reconnect on the next request as expected.
> Specific location of NPE:
> https://github.com/ironjacamar/ironjacamar/blob/ironjacamar-1.3.2.Final/c...
> Note there is similar code on line 461 of the same class (in the exception handler)
> Example configuration follows
> With a PostgreSQL datasource configured in Wildfly as:
> {code:xml}
> <xa-datasource jndi-name="java:/DS.people" pool-name="DS.people" enabled="true" spy="true" statistics-enabled="true" use-java-context="true" use-ccm="true">
> <driver>postgresql</driver>
> <xa-datasource-property name="ServerName">localhost</xa-datasource-property>
> <xa-datasource-property name="PortNumber">5432</xa-datasource-property>
> <xa-datasource-property name="DatabaseName">peopleviewstore</xa-datasource-property>
> <xa-datasource-property name="ApplicationName">people</xa-datasource-property>
> <xa-datasource-property name="assumeMinServerVersion">9.5</xa-datasource-property>
> <xa-datasource-property name="connectTimeout">10</xa-datasource-property>
> <xa-datasource-property name="currentSchema">public</xa-datasource-property>
> <xa-datasource-property name="hostRecheckSeconds">10</xa-datasource-property>
> <xa-datasource-property name="loginTimeout">10</xa-datasource-property>
> <xa-datasource-property name="logUnclosedConnections">true</xa-datasource-property>
> <xa-datasource-property name="socketTimeout">30</xa-datasource-property>
> <xa-datasource-property name="targetServerType">master</xa-datasource-property>
> <xa-datasource-property name="tcpKeepAlive">true</xa-datasource-property>
> <xa-pool>
> <min-pool-size>0</min-pool-size>
> <initial-pool-size>0</initial-pool-size>
> <max-pool-size>10</max-pool-size>
> <allow-multiple-users>false</allow-multiple-users>
> </xa-pool>
> <timeout>
> <xa-resource-timeout>0</xa-resource-timeout>
> </timeout>
> <transaction-isolation>TRANSACTION_READ_COMMITTED</transaction-isolation>
> <statement>
> <track-statements>true</track-statements>
> </statement>
> <security>
> <user-name></user-name>
> <password></password>
> </security>
> <validation>
> <validate-on-match>true</validate-on-match>
> <use-fast-fail>true</use-fast-fail>
> <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLExceptionSorter"/>
> <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLValidConnectionChecker"/>
> </validation>
> </xa-datasource>
> {code}
> And corresponding driver configuration:
> {code:xml}
> <driver name="postgresql" module="org.postgresql">
> <xa-datasource-class>org.postgresql.xa.PGXADataSource</xa-datasource-class>
> </driver>
> {code}
> we have deployed the JDBC driver as a module, module.xml looks like:
> {code:xml}
> <?xml version="1.0" ?>
> <module xmlns="urn:jboss:module:1.3" name="org.postgresql" slot="main">
> <resources>
> <resource-root path="postgresql-42.0.0.jar"/>
> </resources>
> <dependencies>
> <module name="javax.api"/>
> <module name="javax.transaction.api"/>
> </dependencies>
> </module>
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (JBJCA-1347) NullPointerException in SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:441
by Piotr Krokowski (Jira)
[ https://issues.redhat.com/browse/JBJCA-1347?page=com.atlassian.jira.plugi... ]
Piotr Krokowski commented on JBJCA-1347:
----------------------------------------
Hello. I'm getting a bit desperate, because I can't find this info anywhere, so adding this comment here is my last hope.
Main question is: *In which version was that fix included?*
Background:
We started to get into this issue massively after datacenter changes (so the root cause is unrelated - probably connections are closed too eagerly on the DB side).
Some notable fragments from exceptions (issue happens while INVALIDATING a connection):
{{Caused by: java.lang.NullPointerException at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.getConnection(SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:461)}}
Depending on desired behavior (which us unknown to me), it either seems to be an issue in:
SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:461 and line 441.
or it could be the fact, that pool.getInternalStatistics() should not be nullified by another thread, while another thread is trying to do the same.
It's hard to tell not knowing the concept.
Please help...
> NullPointerException in SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:441
> ------------------------------------------------------------------------------------
>
> Key: JBJCA-1347
> URL: https://issues.redhat.com/browse/JBJCA-1347
> Project: IronJacamar
> Issue Type: Bug
> Affects Versions: WildFly/IronJacamar 1.3.2.Final
> Environment: CentOS 6
> Wildfly 10.0.0.Final (Iron Jacamar 1.3.2.Final)
> PostgreSQL Server 9.5.5
> PostgreSQL JDBC driver 9.4.1208 and tried with 42.0.0
> Oracle Java version "1.8.0_112"
> Java(TM) SE Runtime Environment (build 1.8.0_112-b15)
> Java HotSpot(TM) 64-Bit Server VM (build 25.112-b15, mixed mode)
> Reporter: Brett Delle Grazie
> Assignee: Flavia Rainone
> Priority: Major
>
> Using a PostgreSQL XA datasource with statistics enabled we get a NullPointerException if the connection fails temporarily.
> With JDBC driver 9.4.1208 Wildfly never reconnects to the PostgreSQL server with the next request and Wildfly must be restarted. With JDBC driver 42.0.0 it does reconnect on next request.
> If statistics are disabled, the NPE does not occur and both drivers reconnect on the next request as expected.
> Specific location of NPE:
> https://github.com/ironjacamar/ironjacamar/blob/ironjacamar-1.3.2.Final/c...
> Note there is similar code on line 461 of the same class (in the exception handler)
> Example configuration follows
> With a PostgreSQL datasource configured in Wildfly as:
> {code:xml}
> <xa-datasource jndi-name="java:/DS.people" pool-name="DS.people" enabled="true" spy="true" statistics-enabled="true" use-java-context="true" use-ccm="true">
> <driver>postgresql</driver>
> <xa-datasource-property name="ServerName">localhost</xa-datasource-property>
> <xa-datasource-property name="PortNumber">5432</xa-datasource-property>
> <xa-datasource-property name="DatabaseName">peopleviewstore</xa-datasource-property>
> <xa-datasource-property name="ApplicationName">people</xa-datasource-property>
> <xa-datasource-property name="assumeMinServerVersion">9.5</xa-datasource-property>
> <xa-datasource-property name="connectTimeout">10</xa-datasource-property>
> <xa-datasource-property name="currentSchema">public</xa-datasource-property>
> <xa-datasource-property name="hostRecheckSeconds">10</xa-datasource-property>
> <xa-datasource-property name="loginTimeout">10</xa-datasource-property>
> <xa-datasource-property name="logUnclosedConnections">true</xa-datasource-property>
> <xa-datasource-property name="socketTimeout">30</xa-datasource-property>
> <xa-datasource-property name="targetServerType">master</xa-datasource-property>
> <xa-datasource-property name="tcpKeepAlive">true</xa-datasource-property>
> <xa-pool>
> <min-pool-size>0</min-pool-size>
> <initial-pool-size>0</initial-pool-size>
> <max-pool-size>10</max-pool-size>
> <allow-multiple-users>false</allow-multiple-users>
> </xa-pool>
> <timeout>
> <xa-resource-timeout>0</xa-resource-timeout>
> </timeout>
> <transaction-isolation>TRANSACTION_READ_COMMITTED</transaction-isolation>
> <statement>
> <track-statements>true</track-statements>
> </statement>
> <security>
> <user-name></user-name>
> <password></password>
> </security>
> <validation>
> <validate-on-match>true</validate-on-match>
> <use-fast-fail>true</use-fast-fail>
> <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLExceptionSorter"/>
> <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLValidConnectionChecker"/>
> </validation>
> </xa-datasource>
> {code}
> And corresponding driver configuration:
> {code:xml}
> <driver name="postgresql" module="org.postgresql">
> <xa-datasource-class>org.postgresql.xa.PGXADataSource</xa-datasource-class>
> </driver>
> {code}
> we have deployed the JDBC driver as a module, module.xml looks like:
> {code:xml}
> <?xml version="1.0" ?>
> <module xmlns="urn:jboss:module:1.3" name="org.postgresql" slot="main">
> <resources>
> <resource-root path="postgresql-42.0.0.jar"/>
> </resources>
> <dependencies>
> <module name="javax.api"/>
> <module name="javax.transaction.api"/>
> </dependencies>
> </module>
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (WFLY-12941) Microprofile count metrics does not increase in wildfly17
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFLY-12941?page=com.atlassian.jira.plugi... ]
Brian Stansberry reassigned WFLY-12941:
---------------------------------------
Component/s: MP Metrics
Assignee: Jeff Mesnil (was: Brian Stansberry)
Thanks [~alireza.alallah] -- so I've set the component on this and assigned over the [~jmesnil] the component lead for MP Metrics.
My comment about 'statistics-enabled' isn't relevant to this one. :)
> Microprofile count metrics does not increase in wildfly17
> ----------------------------------------------------------
>
> Key: WFLY-12941
> URL: https://issues.redhat.com/browse/WFLY-12941
> Project: WildFly
> Issue Type: Bug
> Components: MP Metrics
> Reporter: alireza alallah
> Assignee: Jeff Mesnil
> Priority: Major
>
> for example
> @Path("/")
> public class RESTEndpoints {
>
> @GET
> @Path("/hello")
> @Counted(name"total_count",absolute = true)
> public String hello(@DefaultValue("my friend!") @QueryParam("name") String name) {
> return "Hello "+name;
>
> }
>
> }
> Now in http://localhost:9990/metrics *total_count* metric does not increase after invoke endpoint.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (WFLY-12952) MP Health returns UP when checks are expected but not installed yet.
by Ivan Straka (Jira)
[ https://issues.redhat.com/browse/WFLY-12952?page=com.atlassian.jira.plugi... ]
Ivan Straka updated WFLY-12952:
-------------------------------
Description:
MicroProfile Health specification [link|https://github.com/eclipse/microprofile-health/blob/master/spec/src/...] says:
* A producer MUST support custom, application level health check procedures
* A producer SHOULD support reasonable out-of-the-box procedures
* A producer with no health check procedures expected or installed MUST return positive overall status (i.e. HTTP 200)
* A producer with health check procedures expected but not yet installed MUST return negative overall status (i.e. HTTP 503)
When I deploy and application with a readiness probe before WildFly is started, from my and namely OpenShift POV the health check procedure is expected from the very beginning.
_Let me note that on OpenShift starting the served should mean starting the service._
Hence I expect negative overall status till the probe is ready and is able to provide response.
However WildFly with default setting responses with status UP:
{code:bash}
while true; do echo $(date +"%T.%3N") ; curl localhost:9990/health/ready; echo ""; done
17:17:56.438 curl: (7) Failed to connect to localhost port 9990: Connection refused
17:17:56.452 curl: (7) Failed to connect to localhost port 9990: Connection refused
17:17:56.466 {"status":"UP","checks":[]}
...
17:18:01.121 {"status":"UP","checks":[]}
17:18:01.133 {"status":"DOWN","checks":[{"name":"delayed-readiness","status":"DOWN"}]}
{code}
This violates (4) bullet in the specification.
WildFly provides option to set global Status when probes are not defined ([documentation|https://doc-stage.usersys.redhat.com/documentation/en-us/re...])
Which would mean the scenario would behave according to the specification. Yet the default state violates it.
If the default value were _DOWN_ we would run into an issue if WildFly without deployment were used (for example as backup for AMQ). The status would be just DOWN:
{noformat}
17:22:41.719
{"status":"DOWN","checks":[]}
{noformat}
And that would violate (3) in the specification.
TCK tests do not cover the scenario well.
Is there a way to return _DOWN_ until WildFly scan a deployment and if no health check is found (thus not expected) then start to return _UP_ ? The scan should happen during MP Health initialization.
If there is no deployment, the _UP_ it is.
Setting the priority to blocker since WildFly 19 shall be EAP 7.3.0.CD19 which is supposed to run on OpenShift. With this behavior health check is not very useful because:
* OpenShift starts the service wait some time and start asking for health status
* WildFly responses _UP_ yet application helathcheck is not installed yet
* With health status _UP_ OpenShift consider a pod ready
* In this point application is installed, health status is _DOWN_ (a DB is down) however OpenShift flow is somewhere else
was:
MicroProfile Health specification [link|https://github.com/eclipse/microprofile-health/blob/master/spec/src/...] says:
* A producer MUST support custom, application level health check procedures
* A producer SHOULD support reasonable out-of-the-box procedures
* A producer with no health check procedures expected or installed MUST return positive overall status (i.e. HTTP 200)
* A producer with health check procedures expected but not yet installed MUST return negative overall status (i.e. HTTP 503)
When I deploy and application with a readiness probe before WildFly is started, from my and namely OpenShift POV the health check procedure is expected from the very beginning.
_Let me note that on OpenShift starting the served should mean starting the service._
Hence I expect negative overall status till the probe is ready and is able to provide response.
However WildFly with default setting responses with status UP:
{code:bash}
while true; do echo $(date +"%T.%3N") ; curl localhost:9990/health/ready; echo ""; done
17:17:56.438 curl: (7) Failed to connect to localhost port 9990: Connection refused
17:17:56.452 curl: (7) Failed to connect to localhost port 9990: Connection refused
17:17:56.466 {"status":"UP","checks":[]}
...
17:18:01.121 {"status":"UP","checks":[]}
17:18:01.133 {"status":"DOWN","checks":[{"name":"delayed-readiness","status":"DOWN"}]}
{code}
This violates (4) bullet in the specification.
WildFly provides option to set global Status when probes are not defined ([documentation|https://doc-stage.usersys.redhat.com/documentation/en-us/re...])
Which would mean the scenario would behave according to the specification. Yet the default state violates it.
If the default value were _DOWN_ we would run into an issue if WildFly without deployment were used (for example as backup for AMQ). The status would be just DOWN:
{noformat}
17:22:41.719
{"status":"DOWN","checks":[]}
{noformat}
And that would violate (3) in the specification.
TCK tests do not cover the scenario well.
Is there a way to return _DOWN_ until WildFly scan a deployment and if no health check is found (thus not expected) then start to return _UP_ ? The scan should happen during MP Health initialization.
If there is no deployment, the _UP_ it is.
Setting the priority to blocker since WildFly 19 shall be EAP 7.3.0.CD19 which is supposed to run on OpenShift. With this behavior health check is not very useful because:
* OpenShift starts the service wait some time and start asking for health status
* WildFly responses _UP_ yet application helathcheck is not installed yet
* With health status _UP_ OpenShift consider a pod ready
* In this point application is ready, health status is _DOWN_ (a DB is down) however OpenShift flow is somewhere else
> MP Health returns UP when checks are expected but not installed yet.
> --------------------------------------------------------------------
>
> Key: WFLY-12952
> URL: https://issues.redhat.com/browse/WFLY-12952
> Project: WildFly
> Issue Type: Bug
> Components: MP Health
> Affects Versions: 18.0.0.Final
> Reporter: Ivan Straka
> Assignee: Jeff Mesnil
> Priority: Blocker
>
> MicroProfile Health specification [link|https://github.com/eclipse/microprofile-health/blob/master/spec/src/...] says:
> * A producer MUST support custom, application level health check procedures
> * A producer SHOULD support reasonable out-of-the-box procedures
> * A producer with no health check procedures expected or installed MUST return positive overall status (i.e. HTTP 200)
> * A producer with health check procedures expected but not yet installed MUST return negative overall status (i.e. HTTP 503)
> When I deploy and application with a readiness probe before WildFly is started, from my and namely OpenShift POV the health check procedure is expected from the very beginning.
> _Let me note that on OpenShift starting the served should mean starting the service._
> Hence I expect negative overall status till the probe is ready and is able to provide response.
> However WildFly with default setting responses with status UP:
> {code:bash}
> while true; do echo $(date +"%T.%3N") ; curl localhost:9990/health/ready; echo ""; done
> 17:17:56.438 curl: (7) Failed to connect to localhost port 9990: Connection refused
> 17:17:56.452 curl: (7) Failed to connect to localhost port 9990: Connection refused
> 17:17:56.466 {"status":"UP","checks":[]}
> ...
> 17:18:01.121 {"status":"UP","checks":[]}
> 17:18:01.133 {"status":"DOWN","checks":[{"name":"delayed-readiness","status":"DOWN"}]}
> {code}
> This violates (4) bullet in the specification.
> WildFly provides option to set global Status when probes are not defined ([documentation|https://doc-stage.usersys.redhat.com/documentation/en-us/re...])
> Which would mean the scenario would behave according to the specification. Yet the default state violates it.
> If the default value were _DOWN_ we would run into an issue if WildFly without deployment were used (for example as backup for AMQ). The status would be just DOWN:
> {noformat}
> 17:22:41.719
> {"status":"DOWN","checks":[]}
> {noformat}
> And that would violate (3) in the specification.
> TCK tests do not cover the scenario well.
> Is there a way to return _DOWN_ until WildFly scan a deployment and if no health check is found (thus not expected) then start to return _UP_ ? The scan should happen during MP Health initialization.
> If there is no deployment, the _UP_ it is.
> Setting the priority to blocker since WildFly 19 shall be EAP 7.3.0.CD19 which is supposed to run on OpenShift. With this behavior health check is not very useful because:
> * OpenShift starts the service wait some time and start asking for health status
> * WildFly responses _UP_ yet application helathcheck is not installed yet
> * With health status _UP_ OpenShift consider a pod ready
> * In this point application is installed, health status is _DOWN_ (a DB is down) however OpenShift flow is somewhere else
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (WFLY-12952) MP Health returns UP when checks are expected but not installed yet.
by Ivan Straka (Jira)
[ https://issues.redhat.com/browse/WFLY-12952?page=com.atlassian.jira.plugi... ]
Ivan Straka updated WFLY-12952:
-------------------------------
Description:
MicroProfile Health specification [link|https://github.com/eclipse/microprofile-health/blob/master/spec/src/...] says:
* A producer MUST support custom, application level health check procedures
* A producer SHOULD support reasonable out-of-the-box procedures
* A producer with no health check procedures expected or installed MUST return positive overall status (i.e. HTTP 200)
* A producer with health check procedures expected but not yet installed MUST return negative overall status (i.e. HTTP 503)
When I deploy and application with a readiness probe before WildFly is started, from my and namely OpenShift POV the health check procedure is expected from the very beginning.
_Let me note that on OpenShift starting the served should mean starting the service._
Hence I expect negative overall status till the probe is ready and is able to provide response.
However WildFly with default setting responses with status UP:
{code:bash}
while true; do echo $(date +"%T.%3N") ; curl localhost:9990/health/ready; echo ""; done
17:17:56.438 curl: (7) Failed to connect to localhost port 9990: Connection refused
17:17:56.452 curl: (7) Failed to connect to localhost port 9990: Connection refused
17:17:56.466 {"status":"UP","checks":[]}
...
17:18:01.121 {"status":"UP","checks":[]}
17:18:01.133 {"status":"DOWN","checks":[{"name":"delayed-readiness","status":"DOWN"}]}
{code}
This violates (4) bullet in the specification.
WildFly provides option to set global Status when probes are not defined ([documentation|https://doc-stage.usersys.redhat.com/documentation/en-us/re...])
Which would mean the scenario would behave according to the specification. Yet the default state violates it.
If the default value were _DOWN_ we would run into an issue if WildFly without deployment were used (for example as backup for AMQ). The status would be just DOWN:
{noformat}
17:22:41.719
{"status":"DOWN","checks":[]}
{noformat}
And that would violate (3) in the specification.
TCK tests do not cover the scenario well.
Is there a way to return _DOWN_ until WildFly scan a deployment and if no health check is found (thus not expected) then start to return _UP_ ? The scan should happen during MP Health initialization.
If there is no deployment, the _UP_ it is.
Setting the priority to blocker since WildFly 19 shall be EAP 7.3.0.CD19 which is supposed to run on OpenShift. With this behavior health check is not very useful because:
* OpenShift starts the service wait some time and start asking for health status
* WildFly responses _UP_ yet application helathcheck is not installed yet
* With health status _UP_ OpenShift consider a pod ready
* In this point application is ready, health status is _DOWN_ (a DB is down) however OpenShift flow is somewhere else
was:
MicroProfile Health specification [link|https://github.com/eclipse/microprofile-health/blob/master/spec/src/...] says:
* A producer MUST support custom, application level health check procedures
* A producer SHOULD support reasonable out-of-the-box procedures
* A producer with no health check procedures expected or installed MUST return positive overall status (i.e. HTTP 200)
* A producer with health check procedures expected but not yet installed MUST return negative overall status (i.e. HTTP 503)
When I deploy and application with a readiness probe before WildFly is started, from my and namely OpenShift POV the health check procedure is expected from the very beginning.
_Let me note that on OpenShift starting the served should mean starting the service._
Hence I expect negative overall status till the probe is ready and is able to provide response.
However WildFly with default setting responses with status UP:
{code:bash}
while true; do echo $(date +"%T.%3N") ; curl localhost:9990/health/ready; echo ""; done
17:17:56.438 curl: (7) Failed to connect to localhost port 9990: Connection refused
17:17:56.452 curl: (7) Failed to connect to localhost port 9990: Connection refused
17:17:56.466 {"status":"UP","checks":[]}
...
17:18:01.121 {"status":"UP","checks":[]}
17:18:01.133 {"status":"DOWN","checks":[{"name":"delayed-readiness","status":"DOWN"}]}
{code}
This violates (4) bullet in the specification.
WildFly provides option to set global Status when probes are not defined ([documentation|https://doc-stage.usersys.redhat.com/documentation/en-us/re...])
Which would mean the scenario would behave according to the specification. Yet the default state violates it.
If the default value were _DOWN_ we would run into an issue if WildFly without deployment were used (for example as backup for AMQ). The status would be just DOWN:
{noformat}
17:22:41.719
{"status":"DOWN","checks":[]}
{noformat}
And that would violate (3) in the specification.
TCK tests do not cover the scenario well.
Is there a way to return _DOWN_ until WildFly scan a deployment and if no health check is found (thus not expected) then start to return _UP_ ? The scan should happen during MP Health initialization.
If there is no deployment, the _UP_ it is.
Setting the priority to blocker since WildFly 19 shall be EAP 7.3.0.CD19 which is supposed to run on OpenShift. With this behavior health check is not very useful because:
* OpenShift starts the service wait some time and start asking for health status
* WildFly responses _UP_ yet application helathcheck is not installed yet
* With health status _UP_ OpenShift consider a pod ready
* In this point application is ready, health status is _DOWN_ (a DB is down) however OpenShift flow is somewhere else
> MP Health returns UP when checks are expected but not installed yet.
> --------------------------------------------------------------------
>
> Key: WFLY-12952
> URL: https://issues.redhat.com/browse/WFLY-12952
> Project: WildFly
> Issue Type: Bug
> Components: MP Health
> Affects Versions: 18.0.0.Final
> Reporter: Ivan Straka
> Assignee: Jeff Mesnil
> Priority: Blocker
>
> MicroProfile Health specification [link|https://github.com/eclipse/microprofile-health/blob/master/spec/src/...] says:
> * A producer MUST support custom, application level health check procedures
> * A producer SHOULD support reasonable out-of-the-box procedures
> * A producer with no health check procedures expected or installed MUST return positive overall status (i.e. HTTP 200)
> * A producer with health check procedures expected but not yet installed MUST return negative overall status (i.e. HTTP 503)
> When I deploy and application with a readiness probe before WildFly is started, from my and namely OpenShift POV the health check procedure is expected from the very beginning.
> _Let me note that on OpenShift starting the served should mean starting the service._
> Hence I expect negative overall status till the probe is ready and is able to provide response.
> However WildFly with default setting responses with status UP:
> {code:bash}
> while true; do echo $(date +"%T.%3N") ; curl localhost:9990/health/ready; echo ""; done
> 17:17:56.438 curl: (7) Failed to connect to localhost port 9990: Connection refused
> 17:17:56.452 curl: (7) Failed to connect to localhost port 9990: Connection refused
> 17:17:56.466 {"status":"UP","checks":[]}
> ...
> 17:18:01.121 {"status":"UP","checks":[]}
> 17:18:01.133 {"status":"DOWN","checks":[{"name":"delayed-readiness","status":"DOWN"}]}
> {code}
> This violates (4) bullet in the specification.
> WildFly provides option to set global Status when probes are not defined ([documentation|https://doc-stage.usersys.redhat.com/documentation/en-us/re...])
> Which would mean the scenario would behave according to the specification. Yet the default state violates it.
> If the default value were _DOWN_ we would run into an issue if WildFly without deployment were used (for example as backup for AMQ). The status would be just DOWN:
> {noformat}
> 17:22:41.719
> {"status":"DOWN","checks":[]}
> {noformat}
> And that would violate (3) in the specification.
> TCK tests do not cover the scenario well.
> Is there a way to return _DOWN_ until WildFly scan a deployment and if no health check is found (thus not expected) then start to return _UP_ ? The scan should happen during MP Health initialization.
> If there is no deployment, the _UP_ it is.
> Setting the priority to blocker since WildFly 19 shall be EAP 7.3.0.CD19 which is supposed to run on OpenShift. With this behavior health check is not very useful because:
> * OpenShift starts the service wait some time and start asking for health status
> * WildFly responses _UP_ yet application helathcheck is not installed yet
> * With health status _UP_ OpenShift consider a pod ready
> * In this point application is ready, health status is _DOWN_ (a DB is down) however OpenShift flow is somewhere else
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (WFLY-12952) MP Health returns UP when checks are expected but not installed yet.
by Ivan Straka (Jira)
[ https://issues.redhat.com/browse/WFLY-12952?page=com.atlassian.jira.plugi... ]
Ivan Straka updated WFLY-12952:
-------------------------------
Description:
MicroProfile Health specification [link|https://github.com/eclipse/microprofile-health/blob/master/spec/src/...] says:
* A producer MUST support custom, application level health check procedures
* A producer SHOULD support reasonable out-of-the-box procedures
* A producer with no health check procedures expected or installed MUST return positive overall status (i.e. HTTP 200)
* A producer with health check procedures expected but not yet installed MUST return negative overall status (i.e. HTTP 503)
When I deploy and application with a readiness probe before WildFly is started, from my and namely OpenShift POV the health check procedure is expected from the very beginning.
_Let me note that on OpenShift starting the served should mean starting the service._
Hence I expect negative overall status till the probe is ready and is able to provide response.
However WildFly with default setting responses with status UP:
{code:bash}
while true; do echo $(date +"%T.%3N") ; curl localhost:9990/health/ready; echo ""; done
17:17:56.438 curl: (7) Failed to connect to localhost port 9990: Connection refused
17:17:56.452 curl: (7) Failed to connect to localhost port 9990: Connection refused
17:17:56.466 {"status":"UP","checks":[]}
...
17:18:01.121 {"status":"UP","checks":[]}
17:18:01.133 {"status":"DOWN","checks":[{"name":"delayed-readiness","status":"DOWN"}]}
{code}
This violates (4) bullet in the specification.
WildFly provides option to set global Status when probes are not defined ([documentation|https://doc-stage.usersys.redhat.com/documentation/en-us/re...])
Which would mean the scenario would behave according to the specification. Yet the default state violates it.
If the default value were _DOWN_ we would run into an issue if WildFly without deployment were used (for example as backup for AMQ). The status would be just DOWN:
{noformat}
17:22:41.719
{"status":"DOWN","checks":[]}
{noformat}
And that would violate (3) in the specification.
TCK tests do not cover the scenario well.
Is there a way to return _DOWN_ until WildFly scan a deployment and if no health check is found (thus not expected) then start to return _UP_ ? The scan should happen during MP Health initialization.
If there is no deployment, the _UP_ it is.
Setting the priority to blocker since WildFly 19 shall be EAP 7.3.0.CD19 which is supposed to run on OpenShift. With this behavior health check is not very useful because:
* OpenShift starts the service wait some time and start asking for health status
* WildFly responses _UP_ yet application helathcheck is not installed yet
* With health status _UP_ OpenShift shall proceeds
* In this point application is ready, health status is _DOWN_ (a DB is down) however OpenShift flow is somewhere else
was:
MicroProfile Health specification [link|https://github.com/eclipse/microprofile-health/blob/master/spec/src/...] says:
* A producer MUST support custom, application level health check procedures
* A producer SHOULD support reasonable out-of-the-box procedures
* A producer with no health check procedures expected or installed MUST return positive overall status (i.e. HTTP 200)
* A producer with health check procedures expected but not yet installed MUST return negative overall status (i.e. HTTP 503)
When I deploy and application with a readiness probe before WildFly is started, from my and namely OpenShift POV the health check procedure is expected from the very beginning.
_Let me note that on OpenShift starting the served should mean starting the service._
Hence I expect negative overall status till the probe is ready and is able to provide response.
However WildFly with default setting responses with status UP:
{code:bash}
while true; do echo $(date +"%T.%3N") ; curl localhost:9990/health/ready; echo ""; done
17:17:56.438 curl: (7) Failed to connect to localhost port 9990: Connection refused
17:17:56.452 curl: (7) Failed to connect to localhost port 9990: Connection refused
17:17:56.466 {"status":"UP","checks":[]}
...
17:18:01.121 {"status":"UP","checks":[]}
17:18:01.133 {"status":"DOWN","checks":[{"name":"delayed-readiness","status":"DOWN"}]}
{code}
This violates (4) bullet in the specification.
WildFly provides option to set global Status when probes are not defined ([documentation|https://doc-stage.usersys.redhat.com/documentation/en-us/re...])
Which would mean the scenario would behave according to the specification. Yet the default state violates it.
If the default value were _DOWN_ we would run into an issue if WildFly without deployment were used (for example as backup for AMQ). The status would be just DOWN:
{noformat}
17:22:41.719
{"status":"DOWN","checks":[]}
{noformat}
And that would violate (3) in the specification.
TCK tests do not cover the scenario well.
Is there a way to return _DOWN_ until WildFly scan a deployment and if no health check is found (thus not expected) then start to return _UP_ ? The scan should happen during MP Health initialization.
If there is no deployment, the _UP_ it is.
> MP Health returns UP when checks are expected but not installed yet.
> --------------------------------------------------------------------
>
> Key: WFLY-12952
> URL: https://issues.redhat.com/browse/WFLY-12952
> Project: WildFly
> Issue Type: Bug
> Components: MP Health
> Affects Versions: 18.0.0.Final
> Reporter: Ivan Straka
> Assignee: Jeff Mesnil
> Priority: Blocker
>
> MicroProfile Health specification [link|https://github.com/eclipse/microprofile-health/blob/master/spec/src/...] says:
> * A producer MUST support custom, application level health check procedures
> * A producer SHOULD support reasonable out-of-the-box procedures
> * A producer with no health check procedures expected or installed MUST return positive overall status (i.e. HTTP 200)
> * A producer with health check procedures expected but not yet installed MUST return negative overall status (i.e. HTTP 503)
> When I deploy and application with a readiness probe before WildFly is started, from my and namely OpenShift POV the health check procedure is expected from the very beginning.
> _Let me note that on OpenShift starting the served should mean starting the service._
> Hence I expect negative overall status till the probe is ready and is able to provide response.
> However WildFly with default setting responses with status UP:
> {code:bash}
> while true; do echo $(date +"%T.%3N") ; curl localhost:9990/health/ready; echo ""; done
> 17:17:56.438 curl: (7) Failed to connect to localhost port 9990: Connection refused
> 17:17:56.452 curl: (7) Failed to connect to localhost port 9990: Connection refused
> 17:17:56.466 {"status":"UP","checks":[]}
> ...
> 17:18:01.121 {"status":"UP","checks":[]}
> 17:18:01.133 {"status":"DOWN","checks":[{"name":"delayed-readiness","status":"DOWN"}]}
> {code}
> This violates (4) bullet in the specification.
> WildFly provides option to set global Status when probes are not defined ([documentation|https://doc-stage.usersys.redhat.com/documentation/en-us/re...])
> Which would mean the scenario would behave according to the specification. Yet the default state violates it.
> If the default value were _DOWN_ we would run into an issue if WildFly without deployment were used (for example as backup for AMQ). The status would be just DOWN:
> {noformat}
> 17:22:41.719
> {"status":"DOWN","checks":[]}
> {noformat}
> And that would violate (3) in the specification.
> TCK tests do not cover the scenario well.
> Is there a way to return _DOWN_ until WildFly scan a deployment and if no health check is found (thus not expected) then start to return _UP_ ? The scan should happen during MP Health initialization.
> If there is no deployment, the _UP_ it is.
> Setting the priority to blocker since WildFly 19 shall be EAP 7.3.0.CD19 which is supposed to run on OpenShift. With this behavior health check is not very useful because:
> * OpenShift starts the service wait some time and start asking for health status
> * WildFly responses _UP_ yet application helathcheck is not installed yet
> * With health status _UP_ OpenShift shall proceeds
> * In this point application is ready, health status is _DOWN_ (a DB is down) however OpenShift flow is somewhere else
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (WFLY-12952) MP Health returns UP when checks are expected but not installed yet.
by Ivan Straka (Jira)
[ https://issues.redhat.com/browse/WFLY-12952?page=com.atlassian.jira.plugi... ]
Ivan Straka updated WFLY-12952:
-------------------------------
Description:
MicroProfile Health specification [link|https://github.com/eclipse/microprofile-health/blob/master/spec/src/...] says:
* A producer MUST support custom, application level health check procedures
* A producer SHOULD support reasonable out-of-the-box procedures
* A producer with no health check procedures expected or installed MUST return positive overall status (i.e. HTTP 200)
* A producer with health check procedures expected but not yet installed MUST return negative overall status (i.e. HTTP 503)
When I deploy and application with a readiness probe before WildFly is started, from my and namely OpenShift POV the health check procedure is expected from the very beginning.
_Let me note that on OpenShift starting the served should mean starting the service._
Hence I expect negative overall status till the probe is ready and is able to provide response.
However WildFly with default setting responses with status UP:
{code:bash}
while true; do echo $(date +"%T.%3N") ; curl localhost:9990/health/ready; echo ""; done
17:17:56.438 curl: (7) Failed to connect to localhost port 9990: Connection refused
17:17:56.452 curl: (7) Failed to connect to localhost port 9990: Connection refused
17:17:56.466 {"status":"UP","checks":[]}
...
17:18:01.121 {"status":"UP","checks":[]}
17:18:01.133 {"status":"DOWN","checks":[{"name":"delayed-readiness","status":"DOWN"}]}
{code}
This violates (4) bullet in the specification.
WildFly provides option to set global Status when probes are not defined ([documentation|https://doc-stage.usersys.redhat.com/documentation/en-us/re...])
Which would mean the scenario would behave according to the specification. Yet the default state violates it.
If the default value were _DOWN_ we would run into an issue if WildFly without deployment were used (for example as backup for AMQ). The status would be just DOWN:
{noformat}
17:22:41.719
{"status":"DOWN","checks":[]}
{noformat}
And that would violate (3) in the specification.
TCK tests do not cover the scenario well.
Is there a way to return _DOWN_ until WildFly scan a deployment and if no health check is found (thus not expected) then start to return _UP_ ? The scan should happen during MP Health initialization.
If there is no deployment, the _UP_ it is.
Setting the priority to blocker since WildFly 19 shall be EAP 7.3.0.CD19 which is supposed to run on OpenShift. With this behavior health check is not very useful because:
* OpenShift starts the service wait some time and start asking for health status
* WildFly responses _UP_ yet application helathcheck is not installed yet
* With health status _UP_ OpenShift consider a pod ready
* In this point application is ready, health status is _DOWN_ (a DB is down) however OpenShift flow is somewhere else
was:
MicroProfile Health specification [link|https://github.com/eclipse/microprofile-health/blob/master/spec/src/...] says:
* A producer MUST support custom, application level health check procedures
* A producer SHOULD support reasonable out-of-the-box procedures
* A producer with no health check procedures expected or installed MUST return positive overall status (i.e. HTTP 200)
* A producer with health check procedures expected but not yet installed MUST return negative overall status (i.e. HTTP 503)
When I deploy and application with a readiness probe before WildFly is started, from my and namely OpenShift POV the health check procedure is expected from the very beginning.
_Let me note that on OpenShift starting the served should mean starting the service._
Hence I expect negative overall status till the probe is ready and is able to provide response.
However WildFly with default setting responses with status UP:
{code:bash}
while true; do echo $(date +"%T.%3N") ; curl localhost:9990/health/ready; echo ""; done
17:17:56.438 curl: (7) Failed to connect to localhost port 9990: Connection refused
17:17:56.452 curl: (7) Failed to connect to localhost port 9990: Connection refused
17:17:56.466 {"status":"UP","checks":[]}
...
17:18:01.121 {"status":"UP","checks":[]}
17:18:01.133 {"status":"DOWN","checks":[{"name":"delayed-readiness","status":"DOWN"}]}
{code}
This violates (4) bullet in the specification.
WildFly provides option to set global Status when probes are not defined ([documentation|https://doc-stage.usersys.redhat.com/documentation/en-us/re...])
Which would mean the scenario would behave according to the specification. Yet the default state violates it.
If the default value were _DOWN_ we would run into an issue if WildFly without deployment were used (for example as backup for AMQ). The status would be just DOWN:
{noformat}
17:22:41.719
{"status":"DOWN","checks":[]}
{noformat}
And that would violate (3) in the specification.
TCK tests do not cover the scenario well.
Is there a way to return _DOWN_ until WildFly scan a deployment and if no health check is found (thus not expected) then start to return _UP_ ? The scan should happen during MP Health initialization.
If there is no deployment, the _UP_ it is.
Setting the priority to blocker since WildFly 19 shall be EAP 7.3.0.CD19 which is supposed to run on OpenShift. With this behavior health check is not very useful because:
* OpenShift starts the service wait some time and start asking for health status
* WildFly responses _UP_ yet application helathcheck is not installed yet
* With health status _UP_ OpenShift shall proceeds
* In this point application is ready, health status is _DOWN_ (a DB is down) however OpenShift flow is somewhere else
> MP Health returns UP when checks are expected but not installed yet.
> --------------------------------------------------------------------
>
> Key: WFLY-12952
> URL: https://issues.redhat.com/browse/WFLY-12952
> Project: WildFly
> Issue Type: Bug
> Components: MP Health
> Affects Versions: 18.0.0.Final
> Reporter: Ivan Straka
> Assignee: Jeff Mesnil
> Priority: Blocker
>
> MicroProfile Health specification [link|https://github.com/eclipse/microprofile-health/blob/master/spec/src/...] says:
> * A producer MUST support custom, application level health check procedures
> * A producer SHOULD support reasonable out-of-the-box procedures
> * A producer with no health check procedures expected or installed MUST return positive overall status (i.e. HTTP 200)
> * A producer with health check procedures expected but not yet installed MUST return negative overall status (i.e. HTTP 503)
> When I deploy and application with a readiness probe before WildFly is started, from my and namely OpenShift POV the health check procedure is expected from the very beginning.
> _Let me note that on OpenShift starting the served should mean starting the service._
> Hence I expect negative overall status till the probe is ready and is able to provide response.
> However WildFly with default setting responses with status UP:
> {code:bash}
> while true; do echo $(date +"%T.%3N") ; curl localhost:9990/health/ready; echo ""; done
> 17:17:56.438 curl: (7) Failed to connect to localhost port 9990: Connection refused
> 17:17:56.452 curl: (7) Failed to connect to localhost port 9990: Connection refused
> 17:17:56.466 {"status":"UP","checks":[]}
> ...
> 17:18:01.121 {"status":"UP","checks":[]}
> 17:18:01.133 {"status":"DOWN","checks":[{"name":"delayed-readiness","status":"DOWN"}]}
> {code}
> This violates (4) bullet in the specification.
> WildFly provides option to set global Status when probes are not defined ([documentation|https://doc-stage.usersys.redhat.com/documentation/en-us/re...])
> Which would mean the scenario would behave according to the specification. Yet the default state violates it.
> If the default value were _DOWN_ we would run into an issue if WildFly without deployment were used (for example as backup for AMQ). The status would be just DOWN:
> {noformat}
> 17:22:41.719
> {"status":"DOWN","checks":[]}
> {noformat}
> And that would violate (3) in the specification.
> TCK tests do not cover the scenario well.
> Is there a way to return _DOWN_ until WildFly scan a deployment and if no health check is found (thus not expected) then start to return _UP_ ? The scan should happen during MP Health initialization.
> If there is no deployment, the _UP_ it is.
> Setting the priority to blocker since WildFly 19 shall be EAP 7.3.0.CD19 which is supposed to run on OpenShift. With this behavior health check is not very useful because:
> * OpenShift starts the service wait some time and start asking for health status
> * WildFly responses _UP_ yet application helathcheck is not installed yet
> * With health status _UP_ OpenShift consider a pod ready
> * In this point application is ready, health status is _DOWN_ (a DB is down) however OpenShift flow is somewhere else
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (WFLY-12952) MP Health returns UP when checks are expected but not installed yet.
by Ivan Straka (Jira)
[ https://issues.redhat.com/browse/WFLY-12952?page=com.atlassian.jira.plugi... ]
Ivan Straka updated WFLY-12952:
-------------------------------
Description:
MicroProfile Health specification [link|https://github.com/eclipse/microprofile-health/blob/master/spec/src/...] says:
* A producer MUST support custom, application level health check procedures
* A producer SHOULD support reasonable out-of-the-box procedures
* A producer with no health check procedures expected or installed MUST return positive overall status (i.e. HTTP 200)
* A producer with health check procedures expected but not yet installed MUST return negative overall status (i.e. HTTP 503)
When I deploy and application with a readiness probe before WildFly is started, from my and namely OpenShift POV the health check procedure is expected from the very beginning.
_Let me note that on OpenShift starting the served should mean starting the service._
Hence I expect negative overall status till the probe is ready and is able to provide response.
However WildFly with default setting responses with status UP:
{code:bash}
while true; do echo $(date +"%T.%3N") ; curl localhost:9990/health/ready; echo ""; done
17:17:56.438 curl: (7) Failed to connect to localhost port 9990: Connection refused
17:17:56.452 curl: (7) Failed to connect to localhost port 9990: Connection refused
17:17:56.466 {"status":"UP","checks":[]}
...
17:18:01.121 {"status":"UP","checks":[]}
17:18:01.133 {"status":"DOWN","checks":[{"name":"delayed-readiness","status":"DOWN"}]}
{code}
This violates (4) bullet in the specification.
WildFly provides option to set global Status when probes are not defined ([documentation|https://doc-stage.usersys.redhat.com/documentation/en-us/re...])
Which would mean the scenario would behave according to the specification. Yet the default state violates it.
If the default value were _DOWN_ we would run into an issue if WildFly without deployment were used (for example as backup for AMQ). The status would be just DOWN:
{noformat}
17:22:41.719
{"status":"DOWN","checks":[]}
{noformat}
And that would violate (3) in the specification.
TCK tests do not cover the scenario well.
Is there a way to return _DOWN_ until WildFly scan a deployment and if no health check is found (thus not expected) then start to return _UP_ ? The scan should happen during MP Health initialization.
If there is no deployment, the _UP_ it is.
was:
MicroProfile Health specification [link|https://github.com/eclipse/microprofile-health/blob/master/spec/src/... says:
* A producer MUST support custom, application level health check procedures
* A producer SHOULD support reasonable out-of-the-box procedures
* A producer with no health check procedures expected or installed MUST return positive overall status (i.e. HTTP 200)
* A producer with health check procedures expected but not yet installed MUST return negative overall status (i.e. HTTP 503)
When I deploy and application with a readiness probe before WildFly is started, from my and namely OpenShift POV the health check procedure is expected from the very beginning.
_Let me note that on OpenShift starting the served should mean starting the service._
Hence I expect negative overall status till the probe is ready and is able to provide response.
However WildFly with default setting responses with status UP:
{code:bash}
while true; do echo $(date +"%T.%3N") ; curl localhost:9990/health/ready; echo ""; done
17:17:56.438 curl: (7) Failed to connect to localhost port 9990: Connection refused
17:17:56.452 curl: (7) Failed to connect to localhost port 9990: Connection refused
17:17:56.466 {"status":"UP","checks":[]}
...
17:18:01.121 {"status":"UP","checks":[]}
17:18:01.133 {"status":"DOWN","checks":[{"name":"delayed-readiness","status":"DOWN"}]}
{code}
This violates (4) bullet in the specification.
WildFly provides option to set global Status when probes are not defined ([documentation|https://doc-stage.usersys.redhat.com/documentation/en-us/re...])
Which would mean the scenario would behave according to the specification. Yet the default state violates it.
If the default value were _DOWN_ we would run into an issue if WildFly without deployment were used (for example as backup for AMQ). The status would be just DOWN:
{noformat}
17:22:41.719
{"status":"DOWN","checks":[]}
{noformat}
And that would violate (3) in the specification.
TCK tests do not cover the scenario well.
Is there a way to return _DOWN_ until WildFly scan a deployment and if no health check is found (thus not expected) then start to return _UP_ ? The scan should happen during MP Health initialization.
If there is no deployment, the _UP_ it is.
> MP Health returns UP when checks are expected but not installed yet.
> --------------------------------------------------------------------
>
> Key: WFLY-12952
> URL: https://issues.redhat.com/browse/WFLY-12952
> Project: WildFly
> Issue Type: Bug
> Components: MP Health
> Affects Versions: 18.0.0.Final
> Reporter: Ivan Straka
> Assignee: Jeff Mesnil
> Priority: Blocker
>
> MicroProfile Health specification [link|https://github.com/eclipse/microprofile-health/blob/master/spec/src/...] says:
> * A producer MUST support custom, application level health check procedures
> * A producer SHOULD support reasonable out-of-the-box procedures
> * A producer with no health check procedures expected or installed MUST return positive overall status (i.e. HTTP 200)
> * A producer with health check procedures expected but not yet installed MUST return negative overall status (i.e. HTTP 503)
> When I deploy and application with a readiness probe before WildFly is started, from my and namely OpenShift POV the health check procedure is expected from the very beginning.
> _Let me note that on OpenShift starting the served should mean starting the service._
> Hence I expect negative overall status till the probe is ready and is able to provide response.
> However WildFly with default setting responses with status UP:
> {code:bash}
> while true; do echo $(date +"%T.%3N") ; curl localhost:9990/health/ready; echo ""; done
> 17:17:56.438 curl: (7) Failed to connect to localhost port 9990: Connection refused
> 17:17:56.452 curl: (7) Failed to connect to localhost port 9990: Connection refused
> 17:17:56.466 {"status":"UP","checks":[]}
> ...
> 17:18:01.121 {"status":"UP","checks":[]}
> 17:18:01.133 {"status":"DOWN","checks":[{"name":"delayed-readiness","status":"DOWN"}]}
> {code}
> This violates (4) bullet in the specification.
> WildFly provides option to set global Status when probes are not defined ([documentation|https://doc-stage.usersys.redhat.com/documentation/en-us/re...])
> Which would mean the scenario would behave according to the specification. Yet the default state violates it.
> If the default value were _DOWN_ we would run into an issue if WildFly without deployment were used (for example as backup for AMQ). The status would be just DOWN:
> {noformat}
> 17:22:41.719
> {"status":"DOWN","checks":[]}
> {noformat}
> And that would violate (3) in the specification.
> TCK tests do not cover the scenario well.
> Is there a way to return _DOWN_ until WildFly scan a deployment and if no health check is found (thus not expected) then start to return _UP_ ? The scan should happen during MP Health initialization.
> If there is no deployment, the _UP_ it is.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (WFLY-12952) MP Health returns UP when checks are expected but not installed yet.
by Ivan Straka (Jira)
Ivan Straka created WFLY-12952:
----------------------------------
Summary: MP Health returns UP when checks are expected but not installed yet.
Key: WFLY-12952
URL: https://issues.redhat.com/browse/WFLY-12952
Project: WildFly
Issue Type: Bug
Components: MP Health
Affects Versions: 18.0.0.Final
Reporter: Ivan Straka
Assignee: Jeff Mesnil
MicroProfile Health specification [link|https://github.com/eclipse/microprofile-health/blob/master/spec/src/... says:
* A producer MUST support custom, application level health check procedures
* A producer SHOULD support reasonable out-of-the-box procedures
* A producer with no health check procedures expected or installed MUST return positive overall status (i.e. HTTP 200)
* A producer with health check procedures expected but not yet installed MUST return negative overall status (i.e. HTTP 503)
When I deploy and application with a readiness probe before WildFly is started, from my and namely OpenShift POV the health check procedure is expected from the very beginning.
_Let me note that on OpenShift starting the served should mean starting the service._
Hence I expect negative overall status till the probe is ready and is able to provide response.
However WildFly with default setting responses with status UP:
{code:bash}
while true; do echo $(date +"%T.%3N") ; curl localhost:9990/health/ready; echo ""; done
17:17:56.438 curl: (7) Failed to connect to localhost port 9990: Connection refused
17:17:56.452 curl: (7) Failed to connect to localhost port 9990: Connection refused
17:17:56.466 {"status":"UP","checks":[]}
...
17:18:01.121 {"status":"UP","checks":[]}
17:18:01.133 {"status":"DOWN","checks":[{"name":"delayed-readiness","status":"DOWN"}]}
{code}
This violates (4) bullet in the specification.
WildFly provides option to set global Status when probes are not defined ([documentation|https://doc-stage.usersys.redhat.com/documentation/en-us/re...])
Which would mean the scenario would behave according to the specification. Yet the default state violates it.
If the default value were _DOWN_ we would run into an issue if WildFly without deployment were used (for example as backup for AMQ). The status would be just DOWN:
{noformat}
17:22:41.719
{"status":"DOWN","checks":[]}
{noformat}
And that would violate (3) in the specification.
TCK tests do not cover the scenario well.
Is there a way to return _DOWN_ until WildFly scan a deployment and if no health check is found (thus not expected) then start to return _UP_ ? The scan should happen during MP Health initialization.
If there is no deployment, the _UP_ it is.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (DROOLS-4698) Adding "expression" type handling for Collection type propereties
by Yeser Amer (Jira)
[ https://issues.redhat.com/browse/DROOLS-4698?page=com.atlassian.jira.plug... ]
Yeser Amer commented on DROOLS-4698:
------------------------------------
Comment 1: Issue present in master and not related to this PR. Can you please open a new ticket?
Comment 2: (not tested in master) in my opinion same of comment 1
Comment 3: 1. Inside the expression I see "Free Rooms", which is not a valid expression
3. you need to compare the FEEL list with the value definied in GIVEN in this way --->" ? = [{Capacity : 1, Price : 1500}, {Capacity : 1, Price : 1200}] "
"?" represents the actualValue.
Comment 4: I changed part of the code during code review, then it seems no more present. BUT if you try to open a duplicated ExpressionCollection cell, an exception is thrown. I need to fix that. I'll notify you when is fixed.
Thank you!
> Adding "expression" type handling for Collection type propereties
> -----------------------------------------------------------------
>
> Key: DROOLS-4698
> URL: https://issues.redhat.com/browse/DROOLS-4698
> Project: Drools
> Issue Type: Feature Request
> Components: Scenario Simulation and Testing
> Reporter: Yeser Amer
> Assignee: Yeser Amer
> Priority: Major
> Labels: UX, UXTeam, drools-tools
> Attachments: Screenshot from 2020-01-08 14-14-05.png, Screenshot from 2020-01-08 14-20-30.png, Screenshot from 2020-01-08 14-36-33.png, Screenshot from 2020-01-08 14-36-52.png, test urgent.scesim, urgent.dmn
>
>
> Support is about both drools/java collections and dmn collections.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (DROOLS-4698) Adding "expression" type handling for Collection type propereties
by Yeser Amer (Jira)
[ https://issues.redhat.com/browse/DROOLS-4698?page=com.atlassian.jira.plug... ]
Yeser Amer edited comment on DROOLS-4698 at 1/9/20 11:26 AM:
-------------------------------------------------------------
[~jomarko]
Comment 1: Issue present in master and not related to this PR. Can you please open a new ticket?
Comment 2: (not tested in master) in my opinion same of comment 1
Comment 3: 1. Inside the expression I see "Free Rooms", which is not a valid expression
3. you need to compare the FEEL list with the value definied in GIVEN in this way --->" ? = [{Capacity : 1, Price : 1500}, {Capacity : 1, Price : 1200}] "
"?" represents the actualValue.
Comment 4: I changed part of the code during code review, then it seems no more present. BUT if you try to open a duplicated ExpressionCollection cell, an exception is thrown. I need to fix that. I'll notify you when is fixed.
Thank you!
was (Author: yamer):
Comment 1: Issue present in master and not related to this PR. Can you please open a new ticket?
Comment 2: (not tested in master) in my opinion same of comment 1
Comment 3: 1. Inside the expression I see "Free Rooms", which is not a valid expression
3. you need to compare the FEEL list with the value definied in GIVEN in this way --->" ? = [{Capacity : 1, Price : 1500}, {Capacity : 1, Price : 1200}] "
"?" represents the actualValue.
Comment 4: I changed part of the code during code review, then it seems no more present. BUT if you try to open a duplicated ExpressionCollection cell, an exception is thrown. I need to fix that. I'll notify you when is fixed.
Thank you!
> Adding "expression" type handling for Collection type propereties
> -----------------------------------------------------------------
>
> Key: DROOLS-4698
> URL: https://issues.redhat.com/browse/DROOLS-4698
> Project: Drools
> Issue Type: Feature Request
> Components: Scenario Simulation and Testing
> Reporter: Yeser Amer
> Assignee: Yeser Amer
> Priority: Major
> Labels: UX, UXTeam, drools-tools
> Attachments: Screenshot from 2020-01-08 14-14-05.png, Screenshot from 2020-01-08 14-20-30.png, Screenshot from 2020-01-08 14-36-33.png, Screenshot from 2020-01-08 14-36-52.png, test urgent.scesim, urgent.dmn
>
>
> Support is about both drools/java collections and dmn collections.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (WFWIP-288) JWT signed by 1024 bit long key is rejected
by Darran Lofthouse (Jira)
[ https://issues.redhat.com/browse/WFWIP-288?page=com.atlassian.jira.plugin... ]
Darran Lofthouse commented on WFWIP-288:
----------------------------------------
I have created https://issues.redhat.com/browse/WFLY-12951 to track that we need to follow this up.
> JWT signed by 1024 bit long key is rejected
> -------------------------------------------
>
> Key: WFWIP-288
> URL: https://issues.redhat.com/browse/WFWIP-288
> Project: WildFly WIP
> Issue Type: Bug
> Components: MP JWT
> Reporter: Jan Kasik
> Assignee: Darran Lofthouse
> Priority: Major
>
> According to MP-JWT 1.1 specification, 1024 and 2048 bit key sizes must be supported. Though when there is JWT signed by 1024 bit long key presented to the server, it is rejected and client receives "Unauthorized" (code 401) message.
> See chapter 9.2. Supported Public Key Formats:
> {quote}
> Support for RSA Public Keys of 1024 or 2048 bits in length is required. Other key sizes are allowed, but should be considered vendor-specific.
> {quote}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (WFLY-12951) JWT signed by 1024 bit long key is rejected
by Darran Lofthouse (Jira)
[ https://issues.redhat.com/browse/WFLY-12951?page=com.atlassian.jira.plugi... ]
Darran Lofthouse commented on WFLY-12951:
-----------------------------------------
As discussed within WFWIP-288 there is an ambiguity in the spec where MP JWT requires a specific signature algorithm and subsequently specifies using a key size too small for that algorithm. This WFLY issue is to track so we can follow up on the next iteration of spec development.
> JWT signed by 1024 bit long key is rejected
> -------------------------------------------
>
> Key: WFLY-12951
> URL: https://issues.redhat.com/browse/WFLY-12951
> Project: WildFly
> Issue Type: Bug
> Components: MP JWT
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Major
>
> According to MP-JWT 1.1 specification, 1024 and 2048 bit key sizes must be supported. Though when there is JWT signed by 1024 bit long key presented to the server, it is rejected and client receives "Unauthorized" (code 401) message.
> See chapter 9.2. Supported Public Key Formats:
> {quote}
> Support for RSA Public Keys of 1024 or 2048 bits in length is required. Other key sizes are allowed, but should be considered vendor-specific.
> {quote}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months