January 2020 - jboss-jira - Jboss List Archives

[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 moved WFWIP-296 to WFLY-12951: ----------------------------------------------- Project: WildFly (was: WildFly WIP) Key: WFLY-12951 (was: WFWIP-296) Component/s: MP JWT (was: MP JWT) > 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

1
0
0 / 0

[JBoss JIRA] (WFWIP-296) JWT signed by 1024 bit long key is rejected

by Darran Lofthouse (Jira)

Darran Lofthouse created WFWIP-296: -------------------------------------- Summary: JWT signed by 1024 bit long key is rejected Key: WFWIP-296 URL: https://issues.redhat.com/browse/WFWIP-296 Project: WildFly WIP Issue Type: Bug Components: MP JWT Reporter: Darran Lofthouse Assignee: Darran Lofthouse 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

1
0
0 / 0

[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 updated WFWIP-288: ----------------------------------- Priority: Major (was: Blocker) > 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

1
0
0 / 0

[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 resolved JGRP-2218. ---------------------------- Resolution: Done > 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

1
0
0 / 0

[JBoss JIRA] (DROOLS-4918) Update Springboot and Springframework to 2.2.2 and 5.2.2 as kieparent

by Massimiliano Dessi (Jira)

Massimiliano Dessi created DROOLS-4918: ------------------------------------------ Summary: Update Springboot and Springframework to 2.2.2 and 5.2.2 as kieparent Key: DROOLS-4918 URL: https://issues.redhat.com/browse/DROOLS-4918 Project: Drools Issue Type: Task Reporter: Massimiliano Dessi Assignee: Massimiliano Dessi The springboot module of hacep refuse to start with the error 2020-01-09 15:30:27.085 ERROR 10 --- [ main] o.s.boot.SpringApplication : Application run failed org.springframework.core.annotation.AnnotationConfigurationException: Attribute 'proxyBeanMethods' in annotation [org.springframework.boot.autoconfigure.SpringBootApplication] is declared as an @AliasFor nonexistent attribute 'proxyBeanMethods' in annotation [org.springframework.context.annotation.Configuration].; nested exception is java.lang.NoSuchMethodException: org.springframework.context.annotation.Configuration.proxyBeanMethods() at org.springframework.core.annotation.AnnotationUtils$AliasDescriptor.<init>(AnnotationUtils.java:2180) currently it use 2.1.1 and spring 5.1.3 the proxyBeanMethods was introduced in springboot 2.2 -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[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 edited comment on JGRP-2218 at 1/9/20 10:51 AM: --------------------------------------------------------- If we created different message *types* rather than payloads, we could have the *same* memory footprint for byte[] array based messages as what we have now! E.g. {code:java} public abstract class Message { protected Address dest_addr, src_addr; protected volatile Header[] headers; protected volatile short flags; protected volatile byte transient_flags; } {code} {code:java} public class ByteArrayMessage extends Message { protected int offset, length; protected byte[] payload; } {code} There could be other types of messages, e.g. {{ObjectMessage}} (equivalent to {{ObjectPayload}}), {{CompositeMessage}} and so on, but the {{ByteArrayMessage}} as sketched out above would have *exactly the same memory footprint (40 bytes)* as the current {{Message}} on {{master}}! Perhaps people could create their own {{message}} subclasses (or implementations if {{Message}} were an interface!) and register them with a factory. The message concept is similar to what JMS provides. was (Author: belaban): If we created different message types rather than payloads, we could have the *same* memory footprint for byte[] array based messages as what we have now! E.g. {code:java} public abstract class Message { protected Address dest_addr, src_addr; protected volatile Header[] headers; protected volatile short flags; protected volatile byte transient_flags; } {code} {code:java} public class ByteArrayMessage extends Message { protected int offset, length; protected byte[] payload; } {code} There could be other types of messages, e.g. {{ObjectMessage}} (equivalent to {{ObjectPayload}}), {{CompositeMessage}} and so on, but the {{ByteArrayMessage}} as sketched out above would have *exactly the same memory footprint (40 bytes)* as the current {{Message}} on {{master}}! Perhaps people could create their own {{message}} subclasses (or implementations if {{Message}} were an interface!) and register them with a factory. The message concept is similar to what JMS provides. > 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

1
0
0 / 0

[JBoss JIRA] (WFWIP-294) JWT is rejected if signature matching public key is not first in JWK set

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/WFWIP-294?page=com.atlassian.jira.plugin... ] Darran Lofthouse commented on WFWIP-294: ---------------------------------------- I have just tried updating my quickstart project and I can not reproduce, here is the branch I am testing: - https://github.com/darranl/microprofile-jwt/tree/jwks The following command builds the project and deploys to WildFly: - mvn install wildfly:deploy The following command generates a token: - mvn exec:java -Dexec.mainClass=org.wildfly.quickstarts.mpjwt.TokenUtil -Dexec.classpathScope=test -Dexec.args="testUser 2017-09-15 Echoer Subscriber" Then the final command is used for the call but with the full token added: - curl -H "Authorization: Bearer eyJ...59g" http://localhost:8080/microprofile-jwt/rest/secured/hello > 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. > 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

1
0
0 / 0

[JBoss JIRA] (WFWIP-288) JWT signed by 1024 bit long key is rejected

by Jan Kasik (Jira)

[ https://issues.redhat.com/browse/WFWIP-288?page=com.atlassian.jira.plugin... ] Jan Kasik commented on WFWIP-288: --------------------------------- [~dlofthouse] Thank you, as you said in this case it seems like an issue in the specification. I suggest to lower the priority and clone this to WFLY/WFCORE issue to make a tracking issue on our side. We should also document this inconsistency in specification later in the product so I will create JBEAP documentation issue linking this clone. WDYT? > 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: Blocker > > 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

1
0
0 / 0

[JBoss JIRA] (JGRP-2400) FRAG4: cache marshalled output with FragmentedMessage

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2400?page=com.atlassian.jira.plugin... ] Bela Ban updated JGRP-2400: --------------------------- Fix Version/s: 5.1 (was: 5.0) > FRAG4: cache marshalled output with FragmentedMessage > ----------------------------------------------------- > > Key: JGRP-2400 > URL: https://issues.redhat.com/browse/JGRP-2400 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Major > Fix For: 5.1 > > > FRAG4 marshals a long message (that has *no array*) into smaller fragments, e.g. when frag_size==200, a 500 byte message is marshalled into 3 FragmentedMessages of sizes 200, 200 and 100. > The first FragmentedMessage marshals the entire original message, but only writes the first 200 bytes to the output stream. > The second FragmentedMessage also marshals the entire original message, and writes the second 200 bytes. > The third message writes only the last 100 bytes. > This means that the original message is marshalled 3 times. > It might be faster to create an object that wraps the original message *and* a byte array, which represents the marshalled object. When marshalled for the first time, the byte array is created. The second and third time, no marshalling is performed, but instead, the FragmentedMessages access the byte array directly (at the given offsets/lengths). -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-294) JWT is rejected if signature matching public key is not first in JWK set

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/WFWIP-294?page=com.atlassian.jira.plugin... ] Darran Lofthouse commented on WFWIP-294: ---------------------------------------- Checking the MP JWT spec I believe there may be some more aspects to this to double check: - * If the JWT token contains the "kid" claim and that claim matches the kid of a JWT then only that key should be used to check the signature. >From that I believe we may be able to imply if the token contains no "kid" then all keys should be used to find one which verifies the signature. This may also mean that if the token contains a "kid" that doesn't match any JWK then all keys should be used to find one which verifies the signature. > 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. > 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

1
0
0 / 0

[JBoss JIRA] (WFLY-12950) [EAT] Multiversion Asynchronous EJB test

by Panagiotis Sotiropoulos (Jira)

Panagiotis Sotiropoulos created WFLY-12950: ---------------------------------------------- Summary: [EAT] Multiversion Asynchronous EJB test Key: WFLY-12950 URL: https://issues.redhat.com/browse/WFLY-12950 Project: WildFly Issue Type: Task Components: Test Suite Reporter: Panagiotis Sotiropoulos Assignee: Panagiotis Sotiropoulos Multiversion Test for issue "Calling Asynchronous EJB will use the propagated caller transaction which is not according to the specification" -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-295) Credential store alias is generated from lower and upper case letter

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/WFWIP-295?page=com.atlassian.jira.plugin... ] Farah Juma commented on WFWIP-295: ---------------------------------- [~tterem] I've updated my PR to include the fix for this issue, i.e., only lower case characters and digits are now used when randomly generating an alias: af4cbf0#diff-955e48598ef9f41cbfef3231e19871dbR128 > Credential store alias is generated from lower and upper case letter > -------------------------------------------------------------------- > > Key: WFWIP-295 > URL: https://issues.redhat.com/browse/WFWIP-295 > Project: WildFly WIP > Issue Type: Bug > Components: CLI, Security > Reporter: Tomas Terem > Assignee: Farah Juma > Priority: Blocker > Labels: cli, credential-reference, credential-store, management > > Credential store alias is generated from both lower and upper case letters which is unnecessary because aliases are case insensitive by default. > When alias is generated, user is informed about the alias name and it consists of both lower and upper case characters, however, then when requested list of aliases from the credential store, it displays aliases in lower case. This could be confusing for users. > Consider to use only lower case letters to be used for generating aliases. > It should be only matter of changing https://github.com/wildfly/wildfly-core/pull/3925/files#diff-955e48598ef9... -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-295) Credential store alias is generated from lower and upper case letter

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/WFWIP-295?page=com.atlassian.jira.plugin... ] Farah Juma edited comment on WFWIP-295 at 1/9/20 9:49 AM: ---------------------------------------------------------- [~tterem] I've updated my PR to include the fix for this issue, i.e., only lower case characters and digits are now used when randomly generating an alias: https://github.com/wildfly/wildfly-core/pull/3925/commits/af4cbf0cec367c5... was (Author: fjuma): [~tterem] I've updated my PR to include the fix for this issue, i.e., only lower case characters and digits are now used when randomly generating an alias: af4cbf0#diff-955e48598ef9f41cbfef3231e19871dbR128 > Credential store alias is generated from lower and upper case letter > -------------------------------------------------------------------- > > Key: WFWIP-295 > URL: https://issues.redhat.com/browse/WFWIP-295 > Project: WildFly WIP > Issue Type: Bug > Components: CLI, Security > Reporter: Tomas Terem > Assignee: Farah Juma > Priority: Blocker > Labels: cli, credential-reference, credential-store, management > > Credential store alias is generated from both lower and upper case letters which is unnecessary because aliases are case insensitive by default. > When alias is generated, user is informed about the alias name and it consists of both lower and upper case characters, however, then when requested list of aliases from the credential store, it displays aliases in lower case. This could be confusing for users. > Consider to use only lower case letters to be used for generating aliases. > It should be only matter of changing https://github.com/wildfly/wildfly-core/pull/3925/files#diff-955e48598ef9... -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4917) Multistatement support for MVEL Expressions

by Yeser Amer (Jira)

Yeser Amer created DROOLS-4917: ---------------------------------- Summary: Multistatement support for MVEL Expressions Key: DROOLS-4917 URL: https://issues.redhat.com/browse/DROOLS-4917 Project: Drools Issue Type: Bug Components: Scenario Simulation and Testing Reporter: Yeser Amer Assignee: Yeser Amer -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-295) Credential reference alias is generated from lower and upper case letter

by Tomas Terem (Jira)

Tomas Terem created WFWIP-295: --------------------------------- Summary: Credential reference alias is generated from lower and upper case letter Key: WFWIP-295 URL: https://issues.redhat.com/browse/WFWIP-295 Project: WildFly WIP Issue Type: Bug Components: CLI, Security Reporter: Tomas Terem Assignee: Farah Juma Credential store alias is generated from both lower and upper case letters which is unnecessary because aliases are case insensitive by default. When alias is generated, user is informed about the alias name and it consists of both lower and upper case characters, however, then when requested list of aliases from the credential store, it displays aliases in lower case. This could be confusing for users. Consider to use only lower case letters to be used for generating aliases. It should be only matter of changing https://github.com/wildfly/wildfly-core/pull/3925/files#diff-955e48598ef9... -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-295) Credential store alias is generated from lower and upper case letter

by Tomas Terem (Jira)

[ https://issues.redhat.com/browse/WFWIP-295?page=com.atlassian.jira.plugin... ] Tomas Terem updated WFWIP-295: ------------------------------ Summary: Credential store alias is generated from lower and upper case letter (was: Credential reference alias is generated from lower and upper case letter) > Credential store alias is generated from lower and upper case letter > -------------------------------------------------------------------- > > Key: WFWIP-295 > URL: https://issues.redhat.com/browse/WFWIP-295 > Project: WildFly WIP > Issue Type: Bug > Components: CLI, Security > Reporter: Tomas Terem > Assignee: Farah Juma > Priority: Blocker > Labels: cli, credential-reference, credential-store, management > > Credential store alias is generated from both lower and upper case letters which is unnecessary because aliases are case insensitive by default. > When alias is generated, user is informed about the alias name and it consists of both lower and upper case characters, however, then when requested list of aliases from the credential store, it displays aliases in lower case. This could be confusing for users. > Consider to use only lower case letters to be used for generating aliases. > It should be only matter of changing https://github.com/wildfly/wildfly-core/pull/3925/files#diff-955e48598ef9... -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-1039) Fix publish_jenkins_console.py

by Filip Brychta (Jira)

[ https://issues.redhat.com/browse/SWSQE-1039?page=com.atlassian.jira.plugi... ] Filip Brychta resolved SWSQE-1039. ---------------------------------- Resolution: Done > Fix publish_jenkins_console.py > ------------------------------ > > Key: SWSQE-1039 > URL: https://issues.redhat.com/browse/SWSQE-1039 > Project: Kiali QE > Issue Type: QE Task > Reporter: Filip Brychta > Assignee: Filip Brychta > Priority: Major > Labels: infrastructure > > Job Filter pattern: "[\w-]+ #\d+" > Output Filter pattern: "" > Jenkins Version: 2.190.2 > OrderedDict([('python-ui-test-pr', set([472])), ('upstream-pipeline', set([544])), ('build-kiali', set([871])), ('install-maistra', set([1377])), ('clean-environment', set([3240, 3241, 3242, 3239])), ('istio-kiali-mesh-checker', set([1864, 1865, 1866])), ('install-bookinfo', set([1619, 1620])), ('install-kiali-test-mesh-operator', set([881])), ('run-kiali-ui-tests-parallel', set([454])), ('run-kiali-ui-tests', set([7630, 7631, 7632, 7633, 7634, 7635, 7636, 7637, 7638, 7639, 7640, 7641, 7642, 7643, 7644, 7645, 7646]))]) > {'run-kiali-ui-tests-parallel': 'UNSTABLE', 'python-ui-test-pr': 'UNSTABLE', 'build-kiali': 'SUCCESS', 'istio-kiali-mesh-checker': 'SUCCESS', 'upstream-pipeline': 'UNSTABLE', 'clean-environment': 'SUCCESS', 'run-kiali-ui-tests': 'UNSTABLE', 'install-bookinfo': 'SUCCESS', 'install-maistra': 'SUCCESS', 'install-kiali-test-mesh-operator': 'SUCCESS'} > Traceback (most recent call last): > File "publish_jenkins_console.py", line 150, in <module> > _url = _upload_console_log(_name, _ids_list) > File "publish_jenkins_console.py", line 126, in _upload_console_log > _url = _response.json()['url'] > File "/usr/lib/python2.7/site-packages/requests/models.py", line 897, in json > return complexjson.loads(self.text, **kwargs) > File "/usr/lib64/python2.7/json/__init__.py", line 338, in loads > return _default_decoder.decode(s) > File "/usr/lib64/python2.7/json/decoder.py", line 366, in decode > obj, end = self.raw_decode(s, idx=_w(s, 0).end()) > File "/usr/lib64/python2.7/json/decoder.py", line 384, in raw_decode > raise ValueError("No JSON object could be decoded") > ValueError: No JSON object could be decoded > cat: /home/jenkins/agent/workspace/python-ui-test-pr/build_comment_log.md: No such file or directory -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12949) Upgrade WildFly-Http-Client from 1.0.18.final to 1.0.19.Final

by Richard Opalka (Jira)

Richard Opalka created WFLY-12949: ------------------------------------- Summary: 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 Fix For: 19.0.0.Beta1 -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3879) Create Kogito version of Test Scenarios designer

by Gabriele Cardosi (Jira)

[ https://issues.redhat.com/browse/DROOLS-3879?page=com.atlassian.jira.plug... ] Gabriele Cardosi updated DROOLS-3879: ------------------------------------- Description: Scope of this PR is to create a *Kogito/client-side only* versions of scesim editor. >From an architectural point of view, the actual implementation has been moved (in the past) inside a common module: `drools-wb-scenario-simulation-editor-client`. Access to it has been "hided" behind a wrapper interface with three actual implementations: * `drools-wb-scenario-simulation-editor-businesscentral-client` for BusinessCentral environment * `drools-wb-scenario-simulation-editor-kogito-testing` to provide a development/debugging setup for the *Kogito/client-side only* environment * `drools-wb-scenario-simulation-editor-kogito-runtime` that should be the one deployed in actual client-side only containers (e.g. VSCode). As agreed upon in the last summer (https://issues.redhat.com/browse/AF-2041), the kogito editors should depend upon a common library, `org.kie.workbench:kie-wb-common-kogito-webapp-base` to put all the code/maven configuration shared by the different editors in one single place. Currently, only the two kogito-related scesim modules fulfill that requirement; all other editors, starting from DMN, should be adapted to this approach. Kogito-testing module is a standalone showcase that provides some minimum interaction to: * load DMN files * create DMN-related scesim assets, selecting one of the imported DMN. Currently - RULE/data object model scesim is disabled. Kogito-runtime module is the version that should run purely client side. It does not provide any graphical widget to load/create/save asset. Some minimal tests may be done in the following way: # full compilation (i.e. included GWT compilation) of the runtime module # open the `drools-wb/drools-wb-screens/drools-wb-scenario-simulation-editor/drools-wb-scenario-simulation-editor-kogito-runtime/target/drools-wb-scenario-simulation-editor-kogito-runtime/index.html` file inside Chrome # inside the Chrome dev console, issue the command `window.gwtEditorBeans.get("ScenarioSimulationEditorKogitoRuntimeScreen").get().setContent("")`; this will show the "New Scesim" popup, where user may choose to create a DMN or RULE scesim; of course, inside Chrome it is not possible to have a reference to other resources, so only "Rule" will work; at the same time, no Data model is available inside Chrome, so the right panel will be empty and the only expected result is an empty grid. Some tricks: to avoid CORS and other policy-related issues: # set chrome://flags/#allow-insecure-localhost for invalid certificates error # start chrome from cli with the command `chrome --allow-file-access-from-files` to allow loading from file. /----/ The "run scenario" functionality won't be implemented by this PR. All the functionalities related to file system/resource access will be simulated in the testing modules (but only for the DMN models), and for the runtime module will depend on the API/environment provided by VSCode was: Scope of this PR is to create a *Kogito/client-side only* versions of scesim editor. >From an architectural point of view, the actual implementation has been moved (in the past) inside a common module: `drools-wb-scenario-simulation-editor-client`. Access to it has been "hided" behind a wrapper interface with three actual implementations: * `drools-wb-scenario-simulation-editor-businesscentral-client` for BusinessCentral environment * `drools-wb-scenario-simulation-editor-kogito-testing` to provide a development/debugging setup for the *Kogito/client-side only* environment * `drools-wb-scenario-simulation-editor-kogito-runtime` that should be the one deployed in actual client-side only containers (e.g. VSCode). As agreed upon in the last summer (https://issues.redhat.com/browse/AF-2041), the kogito editors should depend upon a common library, `org.kie.workbench:kie-wb-common-kogito-webapp-base` to put all the code/maven configuration shared by the different editors in one single place. Currently, only the two kogito-related scesim modules fulfill that requirement; all other editors, starting from DMN, should be adapted to this approach. Kogito-testing module is a standalone showcase that provides some minimum interaction to: * load DMN files * create DMN-related scesim assets, selecting one of the imported DMN. Currently - RULE/data object model scesim is disabled. Kogito-runtime module is the version that should run purely client side. It does not provide any graphical widget to load/create/save asset. Some minimal tests may be done in the following way: # full compilation (i.e. included GWT compilation) of the runtime module # open the `drools-wb/drools-wb-screens/drools-wb-scenario-simulation-editor/drools-wb-scenario-simulation-editor-kogito-runtime/target/drools-wb-scenario-simulation-editor-kogito-runtime/index.html` file inside Chrome # inside the Chrome dev console, issue the command `window.gwtEditorBeans.get("ScenarioSimulationEditorKogitoRuntimeScreen").get().setContent("")`; this will create a new - empty - scesim file. Some tricks: to avoid CORS and other policy-related issues: # set chrome://flags/#allow-insecure-localhost for invalid certificates error # start chrome from cli with the command `chrome --allow-file-access-from-files` to allow loading from file. /----/ The "run scenario" functionality won't be implemented by this PR. All the functionalities related to file system/resource access will be simulated in the testing modules (but only for the DMN models), and for the runtime module will depend on the API/environment provided by VSCode > Create Kogito version of Test Scenarios designer > ------------------------------------------------ > > Key: DROOLS-3879 > URL: https://issues.redhat.com/browse/DROOLS-3879 > Project: Drools > Issue Type: Feature Request > Components: Scenario Simulation and Testing > Reporter: Gabriele Cardosi > Assignee: Yeser Amer > Priority: Major > Labels: drools-tools > > Scope of this PR is to create a *Kogito/client-side only* versions of scesim editor. > From an architectural point of view, the actual implementation has been moved (in the past) inside a common module: `drools-wb-scenario-simulation-editor-client`. > Access to it has been "hided" behind a wrapper interface with three actual implementations: > * `drools-wb-scenario-simulation-editor-businesscentral-client` for BusinessCentral environment > * `drools-wb-scenario-simulation-editor-kogito-testing` to provide a development/debugging setup for the *Kogito/client-side only* environment > * `drools-wb-scenario-simulation-editor-kogito-runtime` that should be the one deployed in actual client-side only containers (e.g. VSCode). > As agreed upon in the last summer (https://issues.redhat.com/browse/AF-2041), the kogito editors should depend upon a common library, `org.kie.workbench:kie-wb-common-kogito-webapp-base` to put all the code/maven configuration shared by the different editors in one single place. > Currently, only the two kogito-related scesim modules fulfill that requirement; all other editors, starting from DMN, should be adapted to this approach. > Kogito-testing module is a standalone showcase that provides some minimum interaction to: > * load DMN files > * create DMN-related scesim assets, selecting one of the imported DMN. > Currently - RULE/data object model scesim is disabled. > Kogito-runtime module is the version that should run purely client side. It does not provide any graphical widget to load/create/save asset. > Some minimal tests may be done in the following way: > # full compilation (i.e. included GWT compilation) of the runtime module > # open the `drools-wb/drools-wb-screens/drools-wb-scenario-simulation-editor/drools-wb-scenario-simulation-editor-kogito-runtime/target/drools-wb-scenario-simulation-editor-kogito-runtime/index.html` file inside Chrome > # inside the Chrome dev console, issue the command `window.gwtEditorBeans.get("ScenarioSimulationEditorKogitoRuntimeScreen").get().setContent("")`; this will show the "New Scesim" popup, where user may choose to create a DMN or RULE scesim; of course, inside Chrome it is not possible to have a reference to other resources, so only "Rule" will work; at the same time, no Data model is available inside Chrome, so the right panel will be empty and the only expected result is an empty grid. > Some tricks: to avoid CORS and other policy-related issues: > # set chrome://flags/#allow-insecure-localhost for invalid certificates error > # start chrome from cli with the command `chrome --allow-file-access-from-files` to allow loading from file. > /----/ > The "run scenario" functionality won't be implemented by this PR. > All the functionalities related to file system/resource access will be simulated in the testing modules (but only for the DMN models), and for the runtime module will depend on the API/environment provided by VSCode -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

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

by Hayk Hovsepyan (Jira)

[ https://issues.redhat.com/browse/SWSQE-1048?page=com.atlassian.jira.plugi... ] Hayk Hovsepyan commented on SWSQE-1048: --------------------------------------- With ServiceMeshpolicy, it will be available once Maistra gets Istio 1.4. > Testcases - Kiali Validations sync-up > ------------------------------------- > > Key: SWSQE-1048 > URL: https://issues.redhat.com/browse/SWSQE-1048 > Project: Kiali QE > Issue Type: Sub-task > Reporter: Hayk Hovsepyan > Assignee: Sunil Kondkar > Priority: Major > > Sync up all validations from https://kiali.io/documentation/validations/ with Polarion estcases. > Make sure all validations have up-to-date testcases in Polarion. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

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

by Sunil Kondkar (Jira)

[ https://issues.redhat.com/browse/SWSQE-1048?page=com.atlassian.jira.plugi... ] Sunil Kondkar commented on SWSQE-1048: -------------------------------------- In below example, the gateway name should be changed to something else like unknown-gateway. The example has below: gateways: - bookinfo-gateway https://kiali.io/documentation/validations/#_virtualservice_is_pointing_t... > Testcases - Kiali Validations sync-up > ------------------------------------- > > Key: SWSQE-1048 > URL: https://issues.redhat.com/browse/SWSQE-1048 > Project: Kiali QE > Issue Type: Sub-task > Reporter: Hayk Hovsepyan > Assignee: Sunil Kondkar > Priority: Major > > Sync up all validations from https://kiali.io/documentation/validations/ with Polarion estcases. > Make sure all validations have up-to-date testcases in Polarion. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4907) DMN FunctionDefinition parameter not trimmed by editor

by Michael Anstis (Jira)

[ https://issues.redhat.com/browse/DROOLS-4907?page=com.atlassian.jira.plug... ] Michael Anstis updated DROOLS-4907: ----------------------------------- Description: Parameter are not trimmed by the editor !image-2020-01-07-17-19-25-638.png|thumbnail! h3. Acceptance criteria - Add a parameter and before dismissing the dialog add spaces to it's start/end. Press tab. -- The view should update to show the trimmed name. -- Undoing the add parameter should remove the parameter. -- Redoing should add it back. - Add a parameter and dismiss dialog - Edit parameters and add spaces to the start/end of the parameters name. Press tab. -- The view should update to show the trimmed name. -- Undoing the add parameter should remove the parameter. -- Redoing should add it back. - Edit parameters and change the parameters name. Press tab. -- The view should update to show the new name. -- Undoing the name change should restore the original name. -- Redoing should restore the changed name. - Add a parameter. Dismiss the dialog. -- Undo should remove parameter. Redoing should add it back with the same name. was: Parameter are not trimmed by the editor !image-2020-01-07-17-19-25-638.png|thumbnail! h3. Acceptance criteria - Add a parameter and before dismissing the dialog add spaces to it's start/end. Press tab. -- The view should update to show the trimmed name. -- Undoing the add parameter should remove the parameter. -- Redoing should add it back. - Add a parameter and dismiss dialog - Edit parameters and add spaces to the start/end of the parameters name. Press tab. -- The view should update to show the trimmed name. -- Undoing the add parameter should remove the parameter. -- Redoing should add it back. - Add a parameter. Dismiss the dialog. -- Undo should remove parameter. Redoing should add it back with the same name. > DMN FunctionDefinition parameter not trimmed by editor > ------------------------------------------------------ > > Key: DROOLS-4907 > URL: https://issues.redhat.com/browse/DROOLS-4907 > Project: Drools > Issue Type: Enhancement > Components: DMN Editor > Reporter: Matteo Mortari > Assignee: Michael Anstis > Priority: Major > Labels: drools-tools > Attachments: image-2020-01-07-17-19-25-638.png > > > Parameter are not trimmed by the editor > !image-2020-01-07-17-19-25-638.png|thumbnail! > h3. Acceptance criteria > - Add a parameter and before dismissing the dialog add spaces to it's start/end. Press tab. > -- The view should update to show the trimmed name. > -- Undoing the add parameter should remove the parameter. > -- Redoing should add it back. > - Add a parameter and dismiss dialog > - Edit parameters and add spaces to the start/end of the parameters name. Press tab. > -- The view should update to show the trimmed name. > -- Undoing the add parameter should remove the parameter. > -- Redoing should add it back. > - Edit parameters and change the parameters name. Press tab. > -- The view should update to show the new name. > -- Undoing the name change should restore the original name. > -- Redoing should restore the changed name. > - Add a parameter. Dismiss the dialog. > -- Undo should remove parameter. Redoing should add it back with the same name. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4912) DMN Data type editor - inline add action button.

by Jozef Marko (Jira)

[ https://issues.redhat.com/browse/DROOLS-4912?page=com.atlassian.jira.plug... ] Jozef Marko updated DROOLS-4912: -------------------------------- Description: Change the behavior and tooltip for the inline add icon-button (+). Currently it converts the type to Structure before adding a row below. Instead, we want it to add another row without converting the type. Acceptance criteria: * Tooltip: "Add row below (Ctrl + B)" Behavior - Clicking the (+) inline add button: * from a type defined as Structure, will add a field row below. * from a Field row (within a Structure), will add another field row below. * from a Simple type, such as "Person(string)", will add another row of the same type below. was: Change the behavior and tooltip for the inline add icon-button (+). Currently it converts the type to Structure before adding a row below. Instead, we want it to add another row without converting the type. Acceptance criteria: *Tooltip: "Add row below (Ctrl + B)" Behavior - Clicking the (+) inline add button: * from a type defined as Structure, will add a field row below. * from a Field row (within a Structure), will add another field row below. * from a Simple type, such as "Person(string)", will add another row of the same type below. > DMN Data type editor - inline add action button. > ------------------------------------------------- > > Key: DROOLS-4912 > URL: https://issues.redhat.com/browse/DROOLS-4912 > Project: Drools > Issue Type: Bug > Components: DMN Editor > Affects Versions: 7.31.0.Final > Reporter: Elizabeth Clayton > Assignee: Guilherme Gomes > Priority: Minor > Labels: UX, drools-tools > Attachments: Screen Shot 2020-01-08 at 7.06.20 PM.png > > > Change the behavior and tooltip for the inline add icon-button (+). Currently it converts the type to Structure before adding a row below. Instead, we want it to add another row without converting the type. > Acceptance criteria: > * Tooltip: "Add row below (Ctrl + B)" > Behavior - Clicking the (+) inline add button: > * from a type defined as Structure, will add a field row below. > * from a Field row (within a Structure), will add another field row below. > * from a Simple type, such as "Person(string)", will add another row of the same type below. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2432) Use maven release plugin

by Bela Ban (Jira)

Bela Ban created JGRP-2432: ------------------------------ Summary: Use maven release plugin Key: JGRP-2432 URL: https://issues.redhat.com/browse/JGRP-2432 Project: JGroups Issue Type: Enhancement Reporter: Bela Ban Assignee: Bela Ban Fix For: 5.1 For releases, switch to the mvn-release plugin. This should simplify releasing a new version and entails * Updating the POM and ivy.xml (?) * Updating the version in all the sample config files -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4912) DMN Data type editor - inline add action button.

by Jozef Marko (Jira)

[ https://issues.redhat.com/browse/DROOLS-4912?page=com.atlassian.jira.plug... ] Jozef Marko updated DROOLS-4912: -------------------------------- Affects Version/s: 7.31.0.Final > DMN Data type editor - inline add action button. > ------------------------------------------------- > > Key: DROOLS-4912 > URL: https://issues.redhat.com/browse/DROOLS-4912 > Project: Drools > Issue Type: Bug > Components: DMN Editor > Affects Versions: 7.31.0.Final > Reporter: Elizabeth Clayton > Assignee: Guilherme Gomes > Priority: Minor > Labels: UX, drools-tools > Attachments: Screen Shot 2020-01-08 at 7.06.20 PM.png > > > Change the behavior and tooltip for the inline add icon-button (+). Currently it converts the type to Structure before adding a row below. Instead, we want it to add another row without converting the type. > Acceptance criteria: > *Tooltip: "Add row below (Ctrl + B)" > Behavior - Clicking the (+) inline add button: > * from a type defined as Structure, will add a field row below. > * from a Field row (within a Structure), will add another field row below. > * from a Simple type, such as "Person(string)", will add another row of the same type below. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

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

by Bela Ban (Jira)

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

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2285) ObjectMessage: handle objects with incorrect size

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2285?page=com.atlassian.jira.plugin... ] Bela Ban updated JGRP-2285: --------------------------- Fix Version/s: 5.1 (was: 5.0) > ObjectMessage: handle objects with incorrect size > ------------------------------------------------- > > Key: JGRP-2285 > URL: https://issues.redhat.com/browse/JGRP-2285 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Major > Fix For: 5.1 > > > An ObjectMessage accepts objects of type SizeStreamable. When such an object has an incorrect serializableSize() method, the following can happen: > * Say the serialized size is 1000, but serializedSize() returns 1200 > * When the ObjectMessage is serialized, a length of 1200 is written, but then only 1000 bytes are serialized onto the output stream > * On the receiving side, length=1200 is read and a byte array of 1200 is created > * DataInput.readFully() reads 1000 bytes, but then reaches the eof of the stream, trying to read an additional 200 bytes > * An exception is thrown and the reading of the message fails > If we caught the exception, things would work, however this would mask other errors in the object serialization/deserialization code. > If the serilization code was able to mark the position of the output stream, then we could write the *actual number of bytes written* (especially if it differs from serializedSize()); however, DataOutput doesn't give us this option! > Investigate whether simply catching (and ignoring) the EOFException would work. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2289) FRAG4: handle ObjectMessage whose size() method is incorrect

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2289?page=com.atlassian.jira.plugin... ] Bela Ban updated JGRP-2289: --------------------------- Fix Version/s: 5.1 (was: 5.0) > FRAG4: handle ObjectMessage whose size() method is incorrect > ------------------------------------------------------------ > > Key: JGRP-2289 > URL: https://issues.redhat.com/browse/JGRP-2289 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Major > Fix For: 5.1 > > > When an ObjectMessage has a {{SizeStreamable}} object whose size() returns more bytes than are actually written, {{FRAG4}} will block on reading of the last fragment. Example: size() returns 27 bytes (LENGTH), but we only write 20 bytes, then {{readFully()}} (used to read the fragments) will throw an exception (EOF, IIRC). > To fix this, {{FragmentedMessage.writeTo()}} could do the following: > * Check if DataOutput is of type ByteArrayDataOutputStream. This is almost always the case as this is used on the bundler base class. If not -> use the current code path > * Remember the current position > * Write LENGTH bytes (27 in the example above) > * Call obj.writeTo(out) > * If the current position is *not* equal to the remembered position + LENGTH: > ** Position the output stream back to the remembered position and write the correct length ACTUAL bytes (20) as an int > Obviously, this only works for DataOutput implementations that support position(), but with most bundlers using ByteArrayDataOutputStream, this should be the case most of the time. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2230) Multiple discovery protocols without MULTI_PING

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2230?page=com.atlassian.jira.plugin... ] Bela Ban updated JGRP-2230: --------------------------- Fix Version/s: 5.1 (was: 5.0) > Multiple discovery protocols without MULTI_PING > ----------------------------------------------- > > Key: JGRP-2230 > URL: https://issues.redhat.com/browse/JGRP-2230 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Major > Fix For: 5.1 > > > Currently, {{MULTI_PING}} is needed to forward discovery requests to multiple discovery protocols. If we change the API in 5.0, and pass a {{Responses}} object down to the discovery protocols, and each discovery protocol forwards discovery requests down (and responses up), and they all add responses to the same {{Responses}} object, then we would not need {{MULTI_PING}} any longer. > However, this is an API change, so can be done only in 5.0. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4907) DMN FunctionDefinition parameter not trimmed by editor

by Michael Anstis (Jira)

[ https://issues.redhat.com/browse/DROOLS-4907?page=com.atlassian.jira.plug... ] Michael Anstis updated DROOLS-4907: ----------------------------------- Description: Parameter are not trimmed by the editor !image-2020-01-07-17-19-25-638.png|thumbnail! h3. Acceptance criteria - Add a parameter and before dismissing the dialog add spaces to it's start/end. Press tab. -- The view should update to show the trimmed name. -- Undoing the add parameter should remove the parameter. -- Redoing should add it back. - Add a parameter and dismiss dialog - Edit parameters and add spaces to the start/end of the parameters name. Press tab. -- The view should update to show the trimmed name. -- Undoing the add parameter should remove the parameter. -- Redoing should add it back. - Add a parameter. Dismiss the dialog. -- Undo should remove parameter. Redoing should add it back with the same name. was: Parameter are not trimmed by the editor !image-2020-01-07-17-19-25-638.png|thumbnail! > DMN FunctionDefinition parameter not trimmed by editor > ------------------------------------------------------ > > Key: DROOLS-4907 > URL: https://issues.redhat.com/browse/DROOLS-4907 > Project: Drools > Issue Type: Enhancement > Components: DMN Editor > Reporter: Matteo Mortari > Assignee: Michael Anstis > Priority: Major > Labels: drools-tools > Attachments: image-2020-01-07-17-19-25-638.png > > > Parameter are not trimmed by the editor > !image-2020-01-07-17-19-25-638.png|thumbnail! > h3. Acceptance criteria > - Add a parameter and before dismissing the dialog add spaces to it's start/end. Press tab. > -- The view should update to show the trimmed name. > -- Undoing the add parameter should remove the parameter. > -- Redoing should add it back. > - Add a parameter and dismiss dialog > - Edit parameters and add spaces to the start/end of the parameters name. Press tab. > -- The view should update to show the trimmed name. > -- Undoing the add parameter should remove the parameter. > -- Redoing should add it back. > - Add a parameter. Dismiss the dialog. > -- Undo should remove parameter. Redoing should add it back with the same name. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2417) Ref-counting for messages

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2417?page=com.atlassian.jira.plugin... ] Bela Ban updated JGRP-2417: --------------------------- Fix Version/s: 5.1 (was: 5.0) > Ref-counting for messages > ------------------------- > > Key: JGRP-2417 > URL: https://issues.redhat.com/browse/JGRP-2417 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Major > Fix For: 5.1 > > > When users do their own memory management, the message passed to {{Channel.send()}} might have a reference to a memory area that's allocated from a pool, and that needs to be returned when done. > However, the return of a {{Channel.send()}} call does not necessarily mean that the memory area can be reused. If, for example, NAKACK2 or UNICAST3 have the message in their retransmission tables (to potentially retransmit it), then the memory cannot be reused until that message has been purged from the retransmission table. > Add a reference-counting mechanism to {{Message}} (implemented in {{BaseMessage}}) that allows NAKACK2 or UNICAST3 to increment a ref-count. When a message is purged from the retransmission table, decrement its ref-count. When the ref-count is 0, a callback could be called. The callback could for example return the associated memory chunk back to the memory pool. > This could possibly be a trait, with a no-op implementation as default. This could be overwritten, ie. > {code:java} > Message release() { > if(refcount <= 0) > // give associated memory area back to pool > } > {code} > See if this needs to be integrated with {{MessageFactory}} as well. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4132) Pure Client Side Scenario Simulation Editor

by Gabriele Cardosi (Jira)

[ https://issues.redhat.com/browse/DROOLS-4132?page=com.atlassian.jira.plug... ] Gabriele Cardosi reassigned DROOLS-4132: ---------------------------------------- Assignee: Yeser Amer (was: Gabriele Cardosi) > Pure Client Side Scenario Simulation Editor > ------------------------------------------- > > Key: DROOLS-4132 > URL: https://issues.redhat.com/browse/DROOLS-4132 > Project: Drools > Issue Type: Epic > Reporter: Eder Ignatowicz > Assignee: Yeser Amer > Priority: Major > > The goal of this phase: Be able to have a pure client-side editor for Scenario Simulation. > The end result of this epic will be a client-side distribution of Scenario Simulation working on VSCode and able to run and show the result of the test execution. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

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

by Sunil Kondkar (Jira)

[ https://issues.redhat.com/browse/SWSQE-1048?page=com.atlassian.jira.plugi... ] Sunil Kondkar commented on SWSQE-1048: -------------------------------------- Not able to create Meshpolicy in the example below: https://kiali.io/documentation/validations/#_meshpolicy_enabling_mtls_fou... I can create ServiceMeshpolicy by changing apiVersion and kind to below values: apiVersion: "authentication.maistra.io/v1" kind: "ServiceMeshPolicy" > Testcases - Kiali Validations sync-up > ------------------------------------- > > Key: SWSQE-1048 > URL: https://issues.redhat.com/browse/SWSQE-1048 > Project: Kiali QE > Issue Type: Sub-task > Reporter: Hayk Hovsepyan > Assignee: Sunil Kondkar > Priority: Major > > Sync up all validations from https://kiali.io/documentation/validations/ with Polarion estcases. > Make sure all validations have up-to-date testcases in Polarion. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4136) R&D how to run scenario simulation tests inside VSCode

by Gabriele Cardosi (Jira)

[ https://issues.redhat.com/browse/DROOLS-4136?page=com.atlassian.jira.plug... ] Gabriele Cardosi reassigned DROOLS-4136: ---------------------------------------- Assignee: Yeser Amer (was: Gabriele Cardosi) > R&D how to run scenario simulation tests inside VSCode > ------------------------------------------------------ > > Key: DROOLS-4136 > URL: https://issues.redhat.com/browse/DROOLS-4136 > Project: Drools > Issue Type: Task > Reporter: Eder Ignatowicz > Assignee: Yeser Amer > Priority: Major > > The main goal of this JIRA is to research what are the best approaches in order to run scenario simulation tests inside VSCode client-side only distribution. > Eder's first ideas: > [1] Run kie-server inside a docker image and run scenario tests via REST API > [2] Show the result of test execution inside scenario simulation editor > <add your idea here> > On future: [1] + investigate if it's possible to show tests execution results inside another junit vscode extension -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4134) Create a scenario simulation distribution

by Gabriele Cardosi (Jira)

[ https://issues.redhat.com/browse/DROOLS-4134?page=com.atlassian.jira.plug... ] Gabriele Cardosi closed DROOLS-4134. ------------------------------------ Release Notes Text: Covered by https://issues.redhat.com/browse/DROOLS-3879 Resolution: Duplicate Issue > Create a scenario simulation distribution > ----------------------------------------- > > Key: DROOLS-4134 > URL: https://issues.redhat.com/browse/DROOLS-4134 > Project: Drools > Issue Type: Task > Reporter: Eder Ignatowicz > Assignee: Gabriele Cardosi > Priority: Major > > Create a scenario simulation client-side editor based on our base showcase. This editor will only be able to do a simple POC inside VSCode. For now, we will have a mocked marshaller and we will not run/execute any test scenario. Moreover, also the base data used to create the scenario simulation (DMOs/DMNs) will be hardcoded > The end result of this JIRA is a scenario simulation editor visible inside VSCode with mocked data. > This war should be manually included inside the current VSCode extension. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4135) Scenario Simulation Marshaller

by Gabriele Cardosi (Jira)

[ https://issues.redhat.com/browse/DROOLS-4135?page=com.atlassian.jira.plug... ] Gabriele Cardosi closed DROOLS-4135. ------------------------------------ Release Notes Text: Covered by https://issues.redhat.com/browse/DROOLS-4249 Resolution: Duplicate Issue > Scenario Simulation Marshaller > ------------------------------ > > Key: DROOLS-4135 > URL: https://issues.redhat.com/browse/DROOLS-4135 > Project: Drools > Issue Type: Task > Reporter: Eder Ignatowicz > Assignee: Gabriele Cardosi > Priority: Major > > <TODO after Marshaller BAPL> -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4133) Extract and Refactor Scenario Simulation Modules

by Gabriele Cardosi (Jira)

[ https://issues.redhat.com/browse/DROOLS-4133?page=com.atlassian.jira.plug... ] Gabriele Cardosi closed DROOLS-4133. ------------------------------------ Release Notes Text: Covered by https://issues.redhat.com/browse/DROOLS-3879 Resolution: Duplicate Issue > Extract and Refactor Scenario Simulation Modules > ------------------------------------------------ > > Key: DROOLS-4133 > URL: https://issues.redhat.com/browse/DROOLS-4133 > Project: Drools > Issue Type: Task > Reporter: Eder Ignatowicz > Assignee: Gabriele Cardosi > Priority: Major > > In order to be ready to be used on business central and kogito, scenario simulation codebase should be split into three modules: > Client Core (environment-agnostic implementations and interfaces) > Business central module (depends on Client Core) > Kogito module (depends on Client Core) > Business central scenario simulation distribution will be made by bc + core and kogito distribution by kogito + core -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4145) R&D how to import/export CSV inside VSCode

by Gabriele Cardosi (Jira)

[ https://issues.redhat.com/browse/DROOLS-4145?page=com.atlassian.jira.plug... ] Gabriele Cardosi closed DROOLS-4145. ------------------------------------ Release Notes Text: Import/Exprto of CSV inside SCESIM should be managed by scesim itself, not delegated to the container Resolution: Won't Do > R&D how to import/export CSV inside VSCode > ------------------------------------------ > > Key: DROOLS-4145 > URL: https://issues.redhat.com/browse/DROOLS-4145 > Project: Drools > Issue Type: Enhancement > Reporter: Gabriele Cardosi > Assignee: Gabriele Cardosi > Priority: Major > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3439) Prevent selection of specific cells in Scenario Simulation

by Gabriele Cardosi (Jira)

[ https://issues.redhat.com/browse/DROOLS-3439?page=com.atlassian.jira.plug... ] Gabriele Cardosi reassigned DROOLS-3439: ---------------------------------------- Assignee: Yeser Amer (was: Gabriele Cardosi) > Prevent selection of specific cells in Scenario Simulation > ---------------------------------------------------------- > > Key: DROOLS-3439 > URL: https://issues.redhat.com/browse/DROOLS-3439 > Project: Drools > Issue Type: Enhancement > Components: Scenario Simulation and Testing > Affects Versions: 7.16.0.Final > Reporter: Jozef Marko > Assignee: Yeser Amer > Priority: Optional > Labels: drools-tools > Attachments: table.png > > > It would improve the user experience if some of the cells could not be selected at all; specifically cells #, Scenario description, GIVEN, EXPECT, and row numbers, as it should not be possible to change them anyway. > This follows up keyboard shortcuts implemented as part of DROOLS-2932. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4726) Bound facts from model are available on Background

by Gabriele Cardosi (Jira)

[ https://issues.redhat.com/browse/DROOLS-4726?page=com.atlassian.jira.plug... ] Gabriele Cardosi reassigned DROOLS-4726: ---------------------------------------- Assignee: Yeser Amer (was: Gabriele Cardosi) > Bound facts from model are available on Background > -------------------------------------------------- > > Key: DROOLS-4726 > URL: https://issues.redhat.com/browse/DROOLS-4726 > Project: Drools > Issue Type: Bug > Components: Scenario Simulation and Testing > Affects Versions: 7.30.0.Final > Reporter: Jozef Marko > Assignee: Yeser Amer > Priority: Major > Labels: ScenarioSimulation, drools-tools > Attachments: bound-facts-on-background.webm > > > See the attached video. The bound facts from main model tab are available in the Background tab. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3447) Remove "DMN Asset" dependency from TitledAttachmentFileWidget

by Gabriele Cardosi (Jira)

[ https://issues.redhat.com/browse/DROOLS-3447?page=com.atlassian.jira.plug... ] Gabriele Cardosi reassigned DROOLS-3447: ---------------------------------------- Assignee: Yeser Amer (was: Gabriele Cardosi) > Remove "DMN Asset" dependency from TitledAttachmentFileWidget > ------------------------------------------------------------- > > Key: DROOLS-3447 > URL: https://issues.redhat.com/browse/DROOLS-3447 > Project: Drools > Issue Type: Bug > Components: Scenario Simulation and Testing > Reporter: Gabriele Cardosi > Assignee: Yeser Amer > Priority: Minor > Labels: drools-tools > > Currently, TitledAttachmentFileWidget use ProjectAssetsQuery to retrieve the "dmn" files. > Implicitly, this means that *if* (for whatever reason) dmn editor is disabled, the dmn file are not retrieved. Wording differently, this creates an implicit dependency between scenariosimulation and dmn editor. > Fix it so that TitledAttachmentFileWidget could find dmn files regardless of dmn editor. > Look at left dock that shows all the files of the project. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4720) Use Objects.equals in AbstractScesimData

by Gabriele Cardosi (Jira)

[ https://issues.redhat.com/browse/DROOLS-4720?page=com.atlassian.jira.plug... ] Gabriele Cardosi reassigned DROOLS-4720: ---------------------------------------- Assignee: Yeser Amer (was: Gabriele Cardosi) > Use Objects.equals in AbstractScesimData > ---------------------------------------- > > Key: DROOLS-4720 > URL: https://issues.redhat.com/browse/DROOLS-4720 > Project: Drools > Issue Type: Task > Components: Scenario Simulation and Testing > Affects Versions: 7.30.0.Final > Reporter: Jozef Marko > Assignee: Yeser Amer > Priority: Major > Labels: ScenarioSimulation, drools-tools > > We should use _Objects.equals()_ instead of simple _equals_ in the [AbstractScesimData|https://github.com/kiegroup/drools/blob/b1bc7ebb290604...] class. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4727) Unclear message when user tries to bind a fact on the Background tab

by Gabriele Cardosi (Jira)

[ https://issues.redhat.com/browse/DROOLS-4727?page=com.atlassian.jira.plug... ] Gabriele Cardosi reassigned DROOLS-4727: ---------------------------------------- Assignee: Yeser Amer (was: Gabriele Cardosi) > Unclear message when user tries to bind a fact on the Background tab > -------------------------------------------------------------------- > > Key: DROOLS-4727 > URL: https://issues.redhat.com/browse/DROOLS-4727 > Project: Drools > Issue Type: Bug > Components: Scenario Simulation and Testing > Affects Versions: 7.30.0.Final > Reporter: Jozef Marko > Assignee: Yeser Amer > Priority: Major > Labels: ScenarioSimulation, drools-tools > Attachments: bind.webm > > > See the attached video. There is confusing message when user bind a fact on Background tab and tries to continue work with the editor. The current message is like _Can not read GJg undefined property_. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2417) Ref-counting for messages

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2417?page=com.atlassian.jira.plugin... ] Bela Ban updated JGRP-2417: --------------------------- Description: When users do their own memory management, the message passed to {{Channel.send()}} might have a reference to a memory area that's allocated from a pool, and that needs to be returned when done. However, the return of a {{Channel.send()}} call does not necessarily mean that the memory area can be reused. If, for example, NAKACK2 or UNICAST3 have the message in their retransmission tables (to potentially retransmit it), then the memory cannot be reused until that message has been purged from the retransmission table. Add a reference-counting mechanism to {{Message}} (implemented in {{BaseMessage}}) that allows NAKACK2 or UNICAST3 to increment a ref-count. When a message is purged from the retransmission table, decrement its ref-count. When the ref-count is 0, a callback could be called. The callback could for example return the associated memory chunk back to the memory pool. This could possibly be a trait, with a no-op implementation as default. This could be overwritten, ie. {code:java} Message release() { if(refcount <= 0) // give associated memory area back to pool } {code} See if this needs to be integrated with {{MessageFactory}} as well. was: When users do their own memory management, the message passed to {{Channel.send()}} might have a reference to a memory area that's allocated from a pool, and that needs to be returned when done. However, {{Channel.send()}} does not necessarily mean that the memory area can be reused. If, for example, NAKACK2 or UNICAST3 have the message in their retransmission tables (to potentially retransmit it), then the memory cannot be reused until that message has been purged from the retransmission table. Add a reference-counting mechanism to {{Message}} (implemented in {{BaseMessage}}) that allows NAKACK2 or UNICAST3 to increment a ref-count. When a message is purged from the retransmission table, decrement its ref-count. When the ref-count is 0, a callback could be called. The callback could for example return the associated memory chunk back to the memory pool. This could possibly be a trait, with a no-op implementation as default. This could be overwritten, ie. {code:java} Message release() { if(refcount <= 0) // give associated memory area back to pool } {code} See if this needs to be integrated with {{MessageFactory}} as well. > Ref-counting for messages > ------------------------- > > Key: JGRP-2417 > URL: https://issues.redhat.com/browse/JGRP-2417 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Major > Fix For: 5.0 > > > When users do their own memory management, the message passed to {{Channel.send()}} might have a reference to a memory area that's allocated from a pool, and that needs to be returned when done. > However, the return of a {{Channel.send()}} call does not necessarily mean that the memory area can be reused. If, for example, NAKACK2 or UNICAST3 have the message in their retransmission tables (to potentially retransmit it), then the memory cannot be reused until that message has been purged from the retransmission table. > Add a reference-counting mechanism to {{Message}} (implemented in {{BaseMessage}}) that allows NAKACK2 or UNICAST3 to increment a ref-count. When a message is purged from the retransmission table, decrement its ref-count. When the ref-count is 0, a callback could be called. The callback could for example return the associated memory chunk back to the memory pool. > This could possibly be a trait, with a no-op implementation as default. This could be overwritten, ie. > {code:java} > Message release() { > if(refcount <= 0) > // give associated memory area back to pool > } > {code} > See if this needs to be integrated with {{MessageFactory}} as well. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4671) Scenario Grids keyboard control

by Gabriele Cardosi (Jira)

[ https://issues.redhat.com/browse/DROOLS-4671?page=com.atlassian.jira.plug... ] Gabriele Cardosi reassigned DROOLS-4671: ---------------------------------------- Assignee: Yeser Amer (was: Gabriele Cardosi) > Scenario Grids keyboard control > ------------------------------- > > Key: DROOLS-4671 > URL: https://issues.redhat.com/browse/DROOLS-4671 > Project: Drools > Issue Type: Bug > Components: Scenario Simulation and Testing > Affects Versions: 7.29.0.Final > Reporter: Jozef Marko > Assignee: Yeser Amer > Priority: Major > Labels: drools-tools > > Scenario keyboard control needs to work immediately after opening Model or Background tab, see the [comment|https://github.com/kiegroup/drools-wb/pull/1239#discussion_r33638...]. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3315) Implement placeholder mechanism for the header of the grid

by Gabriele Cardosi (Jira)

[ https://issues.redhat.com/browse/DROOLS-3315?page=com.atlassian.jira.plug... ] Gabriele Cardosi reassigned DROOLS-3315: ---------------------------------------- Assignee: Yeser Amer (was: Gabriele Cardosi) > Implement placeholder mechanism for the header of the grid > ---------------------------------------------------------- > > Key: DROOLS-3315 > URL: https://issues.redhat.com/browse/DROOLS-3315 > Project: Drools > Issue Type: Enhancement > Components: Scenario Simulation and Testing > Reporter: Daniele Zonca > Assignee: Yeser Amer > Priority: Minor > Labels: ScenarioSimulation, drools-tools > > Implement directly in core-grids an extension of placeholder mechanism to cover also the header -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4838) Create common producer for tests

by Gabriele Cardosi (Jira)

[ https://issues.redhat.com/browse/DROOLS-4838?page=com.atlassian.jira.plug... ] Gabriele Cardosi reassigned DROOLS-4838: ---------------------------------------- Assignee: Yeser Amer (was: Gabriele Cardosi) > Create common producer for tests > -------------------------------- > > Key: DROOLS-4838 > URL: https://issues.redhat.com/browse/DROOLS-4838 > Project: Drools > Issue Type: Task > Components: Scenario Simulation and Testing > Reporter: Gabriele Cardosi > Assignee: Yeser Amer > Priority: Minor > Labels: drools-tools > > Inside the tests there is a whole bunch of mocked objects that are used in multiple places (especially the ones related to grid/cell/rendering stuff). > Scope of this ticket shuold be to put all of them inside a static producer; this would also reduce the needs for abstract/inheritance chains, simplifying the test environment -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4576) Data object selector Search widget not enabled in saved tests

by Gabriele Cardosi (Jira)

[ https://issues.redhat.com/browse/DROOLS-4576?page=com.atlassian.jira.plug... ] Gabriele Cardosi reassigned DROOLS-4576: ---------------------------------------- Assignee: Yeser Amer (was: Gabriele Cardosi) > Data object selector Search widget not enabled in saved tests > ------------------------------------------------------------- > > Key: DROOLS-4576 > URL: https://issues.redhat.com/browse/DROOLS-4576 > Project: Drools > Issue Type: Bug > Components: Scenario Simulation and Testing > Reporter: Elizabeth Clayton > Assignee: Yeser Amer > Priority: Major > Labels: drools-tools > Attachments: 2019-09-27 13.36.19.gif > > > The Search widget doesn't work (isn't accessible/enabled) in a test template that has been setup/saved, it does work in a new test though. Example attached. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4721) Use Objects.equals in ScesimModelDescriptor

by Gabriele Cardosi (Jira)

[ https://issues.redhat.com/browse/DROOLS-4721?page=com.atlassian.jira.plug... ] Gabriele Cardosi reassigned DROOLS-4721: ---------------------------------------- Assignee: Yeser Amer (was: Gabriele Cardosi) > Use Objects.equals in ScesimModelDescriptor > ------------------------------------------- > > Key: DROOLS-4721 > URL: https://issues.redhat.com/browse/DROOLS-4721 > Project: Drools > Issue Type: Task > Components: Scenario Simulation and Testing > Affects Versions: 7.30.0.Final > Reporter: Jozef Marko > Assignee: Yeser Amer > Priority: Major > Labels: ScenarioSimulation, drools-tools > > We should use _Objects.equals()_ instead of simple _equals_ in the [ScesimModelDescriptor|https://github.com/kiegroup/drools/blob/b1bc7ebb290...] class. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4769) Add an empty row on grid when importing "empty" csv

by Gabriele Cardosi (Jira)

[ https://issues.redhat.com/browse/DROOLS-4769?page=com.atlassian.jira.plug... ] Gabriele Cardosi reassigned DROOLS-4769: ---------------------------------------- Assignee: Yeser Amer (was: Gabriele Cardosi) > Add an empty row on grid when importing "empty" csv > --------------------------------------------------- > > Key: DROOLS-4769 > URL: https://issues.redhat.com/browse/DROOLS-4769 > Project: Drools > Issue Type: Enhancement > Components: Scenario Simulation and Testing > Affects Versions: 7.30.0.Final > Reporter: Anna Dupliak > Assignee: Yeser Amer > Priority: Minor > Labels: drools-tools > Attachments: DmnAssert.scesim, DmnAssert.scesim.csv, Driver Suspension Rules.dmn, image.png > > > If user import csv file in DMN scenario, which contains only header, then the Background contains no rows see [^image.png] > Steps to reproduce : > # Import [^Driver Suspension Rules.dmn] > # Import [^DmnAssert.scesim] > # In scesim file import [^DmnAssert.scesim.csv] > Expected: Grid with the cells state the same as after initialization > Actual: user has no rows to add a value > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4153) Move common code to scenarioeditorpresenter

by Gabriele Cardosi (Jira)

[ https://issues.redhat.com/browse/DROOLS-4153?page=com.atlassian.jira.plug... ] Gabriele Cardosi closed DROOLS-4153. ------------------------------------ Resolution: Done > Move common code to scenarioeditorpresenter > ------------------------------------------- > > Key: DROOLS-4153 > URL: https://issues.redhat.com/browse/DROOLS-4153 > Project: Drools > Issue Type: Enhancement > Components: Scenario Simulation and Testing > Reporter: Gabriele Cardosi > Assignee: Gabriele Cardosi > Priority: Major > Labels: drools-tools > > Move common code/logic from BusinessCentral/Kogit wrappers to SCenarioEditorPresenter -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3397) Move undoable logic to AbstractCommand

by Gabriele Cardosi (Jira)

[ https://issues.redhat.com/browse/DROOLS-3397?page=com.atlassian.jira.plug... ] Gabriele Cardosi reassigned DROOLS-3397: ---------------------------------------- Assignee: Yeser Amer (was: Gabriele Cardosi) > Move undoable logic to AbstractCommand > -------------------------------------- > > Key: DROOLS-3397 > URL: https://issues.redhat.com/browse/DROOLS-3397 > Project: Drools > Issue Type: Enhancement > Components: Scenario Simulation and Testing > Reporter: Gabriele Cardosi > Assignee: Yeser Amer > Priority: Minor > Labels: drools-tools > > Move undoable logic from AbstractScenarioSimulationCommand to AbstractCommand. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3312) Minor cleanup

by Gabriele Cardosi (Jira)

[ https://issues.redhat.com/browse/DROOLS-3312?page=com.atlassian.jira.plug... ] Gabriele Cardosi reassigned DROOLS-3312: ---------------------------------------- Assignee: Yeser Amer (was: Gabriele Cardosi) > Minor cleanup > ------------- > > Key: DROOLS-3312 > URL: https://issues.redhat.com/browse/DROOLS-3312 > Project: Drools > Issue Type: Sub-task > Components: Scenario Simulation and Testing > Reporter: Gabriele Cardosi > Assignee: Yeser Amer > Priority: Minor > Labels: drools-tools > > # replace GIVEN/EXPECT Strings with Enum > # move classes to proper packages > # rename classes with "old" meanings (for ex, BaseExpressionGridTheme is the name of the class originally copied from DMN) > # BaseExpressionGridTheme.getHeaderBackground remove get(0) used to set background color -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4035) Remove kie-soup-project-datamodel-api dependency from drools-scenario-simulation-api

by Gabriele Cardosi (Jira)

[ https://issues.redhat.com/browse/DROOLS-4035?page=com.atlassian.jira.plug... ] Gabriele Cardosi reassigned DROOLS-4035: ---------------------------------------- Assignee: Yeser Amer (was: Gabriele Cardosi) > Remove kie-soup-project-datamodel-api dependency from drools-scenario-simulation-api > ------------------------------------------------------------------------------------ > > Key: DROOLS-4035 > URL: https://issues.redhat.com/browse/DROOLS-4035 > Project: Drools > Issue Type: Enhancement > Components: Scenario Simulation and Testing > Reporter: Gabriele Cardosi > Assignee: Yeser Amer > Priority: Major > Labels: drools-tools > > drools-scenario-simulation-api is inherited by all scenario-simulation modules, included the submarine one(s), so it must not contain anything related/specific for the "business central" environment. - DO NOT MERGE -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4722) Refactor DOMUtil.createNodeAtPosition

by Gabriele Cardosi (Jira)

[ https://issues.redhat.com/browse/DROOLS-4722?page=com.atlassian.jira.plug... ] Gabriele Cardosi reassigned DROOLS-4722: ---------------------------------------- Assignee: Yeser Amer (was: Gabriele Cardosi) > Refactor DOMUtil.createNodeAtPosition > ------------------------------------- > > Key: DROOLS-4722 > URL: https://issues.redhat.com/browse/DROOLS-4722 > Project: Drools > Issue Type: Task > Components: Scenario Simulation and Testing > Affects Versions: 7.30.0.Final > Reporter: Jozef Marko > Assignee: Yeser Amer > Priority: Major > Labels: ScenarioSimulation, drools-tools > > According a discussion [here|https://github.com/kiegroup/drools/pull/2630#discussion_r341188931] we should refactor the method _DOMParserUtil.createNodeAtPosition_ to simplify its usage by dropping its last parameter. This parameter is null in most cases. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3879) Create Kogito version of Test Scenarios designer

by Gabriele Cardosi (Jira)

[ https://issues.redhat.com/browse/DROOLS-3879?page=com.atlassian.jira.plug... ] Gabriele Cardosi reassigned DROOLS-3879: ---------------------------------------- Assignee: Yeser Amer (was: Gabriele Cardosi) > Create Kogito version of Test Scenarios designer > ------------------------------------------------ > > Key: DROOLS-3879 > URL: https://issues.redhat.com/browse/DROOLS-3879 > Project: Drools > Issue Type: Feature Request > Components: Scenario Simulation and Testing > Reporter: Gabriele Cardosi > Assignee: Yeser Amer > Priority: Major > Labels: drools-tools > > Scope of this PR is to create a *Kogito/client-side only* versions of scesim editor. > From an architectural point of view, the actual implementation has been moved (in the past) inside a common module: `drools-wb-scenario-simulation-editor-client`. > Access to it has been "hided" behind a wrapper interface with three actual implementations: > * `drools-wb-scenario-simulation-editor-businesscentral-client` for BusinessCentral environment > * `drools-wb-scenario-simulation-editor-kogito-testing` to provide a development/debugging setup for the *Kogito/client-side only* environment > * `drools-wb-scenario-simulation-editor-kogito-runtime` that should be the one deployed in actual client-side only containers (e.g. VSCode). > As agreed upon in the last summer (https://issues.redhat.com/browse/AF-2041), the kogito editors should depend upon a common library, `org.kie.workbench:kie-wb-common-kogito-webapp-base` to put all the code/maven configuration shared by the different editors in one single place. > Currently, only the two kogito-related scesim modules fulfill that requirement; all other editors, starting from DMN, should be adapted to this approach. > Kogito-testing module is a standalone showcase that provides some minimum interaction to: > * load DMN files > * create DMN-related scesim assets, selecting one of the imported DMN. > Currently - RULE/data object model scesim is disabled. > Kogito-runtime module is the version that should run purely client side. It does not provide any graphical widget to load/create/save asset. > Some minimal tests may be done in the following way: > # full compilation (i.e. included GWT compilation) of the runtime module > # open the `drools-wb/drools-wb-screens/drools-wb-scenario-simulation-editor/drools-wb-scenario-simulation-editor-kogito-runtime/target/drools-wb-scenario-simulation-editor-kogito-runtime/index.html` file inside Chrome > # inside the Chrome dev console, issue the command `window.gwtEditorBeans.get("ScenarioSimulationEditorKogitoRuntimeScreen").get().setContent("")`; this will create a new - empty - scesim file. > Some tricks: to avoid CORS and other policy-related issues: > # set chrome://flags/#allow-insecure-localhost for invalid certificates error > # start chrome from cli with the command `chrome --allow-file-access-from-files` to allow loading from file. > /----/ > The "run scenario" functionality won't be implemented by this PR. > All the functionalities related to file system/resource access will be simulated in the testing modules (but only for the DMN models), and for the runtime module will depend on the API/environment provided by VSCode -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4880) JAXB serialize DomainClassMetadata classes

by Luca Molteni (Jira)

[ https://issues.redhat.com/browse/DROOLS-4880?page=com.atlassian.jira.plug... ] Luca Molteni updated DROOLS-4880: --------------------------------- Tester: Jiri Petrlik (was: Daniel Rosa) > JAXB serialize DomainClassMetadata classes > ------------------------------------------ > > Key: DROOLS-4880 > URL: https://issues.redhat.com/browse/DROOLS-4880 > Project: Drools > Issue Type: Bug > Components: executable model > Reporter: Luca Molteni > Assignee: Luca Molteni > Priority: Major > Labels: good-first-issue > > See > https://github.com/kiegroup/droolsjbpm-integration/pull/1864/commits/2331... > The Price class was moved from a static inner class because it was causing a JAXB problem in OptaPlannerIntegrationTest that crashed while trying to serialize DomainClassMetadata (due to the creation of the synthetic class CloudBalancingGenerator$1 > Customers are still relying on static inner class so we should have this test running in the original form > run the test with > mvn -nsu -Dcontainer=wildfly -Dintegration-tests=true -Dfull=true -Dcontainer.profile=wildfly -Pwildfly clean install -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4916) Investigate modify parsing bug in executable model

by Luca Molteni (Jira)

Luca Molteni created DROOLS-4916: ------------------------------------ Summary: Investigate modify parsing bug in executable model Key: DROOLS-4916 URL: https://issues.redhat.com/browse/DROOLS-4916 Project: Drools Issue Type: Bug Components: executable model Reporter: Luca Molteni Assignee: Luca Molteni declare Application categories : Set = new HashSet() Then I had a modify statement scattered about: modify ($a) { $a.getCategories().add("hello"); } The ExecutableModel did not seem to like any of those. I changed it to: $a.getCategories().add("hello"); update($a); -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2420) Look at submariner for xsite traffic

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2420?page=com.atlassian.jira.plugin... ] Bela Ban closed JGRP-2420. -------------------------- Resolution: Won't Do > Look at submariner for xsite traffic > ------------------------------------ > > Key: JGRP-2420 > URL: https://issues.redhat.com/browse/JGRP-2420 > Project: JGroups > Issue Type: Task > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Optional > Fix For: 4.2.0 > > > See whether submariner can help with xsite (especially if we can avoid the LB issues). > [1] submariner.io -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2420) Look at submariner for xsite traffic

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2420?page=com.atlassian.jira.plugin... ] Bela Ban commented on JGRP-2420: -------------------------------- For now, the solution posted at \[1\] is sufficient. Kubernetes network-connectors such as weave-net, submariner and skupper provide a (virtual) flat address space. Once this is set up, we could use DNS (for example) to discover the nodes in all sites and then run additional logic to discover the site masters. This is currently not needed, but we may come back and try this out at a later time... \[1\] http://belaban.blogspot.com/2019/12/spanning-jgroups-kubernetes-based.html > Look at submariner for xsite traffic > ------------------------------------ > > Key: JGRP-2420 > URL: https://issues.redhat.com/browse/JGRP-2420 > Project: JGroups > Issue Type: Task > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Optional > Fix For: 4.2.0 > > > See whether submariner can help with xsite (especially if we can avoid the LB issues). > [1] submariner.io -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4915) Upgrade Hibernate validator

by Massimiliano Dessi (Jira)

[ https://issues.redhat.com/browse/DROOLS-4915?page=com.atlassian.jira.plug... ] Massimiliano Dessi updated DROOLS-4915: --------------------------------------- Summary: Upgrade Hibernate validator (was: Upgrade Hibernate validator to fix CVE-2019-10219) > Upgrade Hibernate validator > --------------------------- > > Key: DROOLS-4915 > URL: https://issues.redhat.com/browse/DROOLS-4915 > Project: Drools > Issue Type: Task > Reporter: Massimiliano Dessi > Assignee: Massimiliano Dessi > Priority: Major > Labels: HADrools > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4915) Upgrade Hibernate validator to fix CVE-2019-10219

by Massimiliano Dessi (Jira)

[ https://issues.redhat.com/browse/DROOLS-4915?page=com.atlassian.jira.plug... ] Massimiliano Dessi commented on DROOLS-4915: -------------------------------------------- Upgrade Hibernate validator to fix CVE-2019-10219 > Upgrade Hibernate validator to fix CVE-2019-10219 > ------------------------------------------------- > > Key: DROOLS-4915 > URL: https://issues.redhat.com/browse/DROOLS-4915 > Project: Drools > Issue Type: Task > Reporter: Massimiliano Dessi > Assignee: Massimiliano Dessi > Priority: Major > Labels: HADrools > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-293) Current implementation of MP-JWT doesn't require claims which should be required

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/WFWIP-293?page=com.atlassian.jira.plugin... ] Darran Lofthouse commented on WFWIP-293: ---------------------------------------- [~jkasik] I think this one needs to be rejected, after investigating this one and attempting to implement a fix there is clearly come ambiguity within the specification that needs to be clarified. Most importantly this behaviour is within SmallRye JWT which is already being used within both Thorntail and Quarkus. After attempting to make the complete set of required claims (Except "upn" which has a defined fallback strategy) firstly the SmallRye JWT testsuite fails due to missing claims (if that was the only failure obviously the correct step would be to fix those tests) - I then execute the MicroProfile JWT TCK with the change and the majority of the tests subsequently fail so even the TCK is not sending in the "required" set of claims. At this stage I don't think it is a good strategy to make this complete set required, JWT token authentication is very much about interoperability so releasing a strict implementation I believe will cause more problems than it solves. The following issue actually already exists against the specification: - https://github.com/eclipse/microprofile-jwt-auth/issues/128 Also the following issue is questioning the "required" status of the groups claim: - https://github.com/eclipse/microprofile-jwt-auth/issues/129 So instead of an immediate code change I am going to see if we can kick start some discussions to evolve the JWT specification and hopefully in the not too distant future have a spec with clarifications applied. > Current implementation of MP-JWT doesn't require claims which should be required > -------------------------------------------------------------------------------- > > Key: WFWIP-293 > URL: https://issues.redhat.com/browse/WFWIP-293 > Project: WildFly WIP > Issue Type: Bug > Components: MP JWT > Reporter: Jan Kasik > Assignee: Darran Lofthouse > Priority: Critical > > Chapter 4.1 of MP-JWT 1.1 recommends minimal set of JWT claims which should be required. > Current implementation doesn't check for following claims and returns 200/OK if they are missing: > * {{upn}} > * {{jti}} > * {{groups}} > * {{iat}} > * {{sub}} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4915) Upgrade Hibernate validator to fix CVE-2019-10219

by Massimiliano Dessi (Jira)

Massimiliano Dessi created DROOLS-4915: ------------------------------------------ Summary: Upgrade Hibernate validator to fix CVE-2019-10219 Key: DROOLS-4915 URL: https://issues.redhat.com/browse/DROOLS-4915 Project: Drools Issue Type: Task Reporter: Massimiliano Dessi Assignee: Massimiliano Dessi -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12948) When shutting down, JDBC_PING tries to use a closed connection

by Sebastian Laskawiec (Jira)

[ https://issues.redhat.com/browse/WFLY-12948?page=com.atlassian.jira.plugi... ] Sebastian Laskawiec commented on WFLY-12948: -------------------------------------------- [~rhusar] [~pferraro] FYI > When shutting down, JDBC_PING tries to use a closed connection > -------------------------------------------------------------- > > Key: WFLY-12948 > URL: https://issues.redhat.com/browse/WFLY-12948 > Project: WildFly > Issue Type: Bug > Components: Clustering > Reporter: Sebastian Laskawiec > Assignee: Paul Ferraro > Priority: Minor > > One of the Keycloak demos use {{JDBC_PING}} as discovery protocol (see [here|https://github.com/keycloak/keycloak-containers/blob/master/docker-c...]). One of our users noticed (and I confirmed it) that when shutting Keycloak down, {{JDBC_PING}} tries to use a closed Connection Factory: > {code} > keycloak_2 | 09:14:34,807 ERROR [org.jgroups.protocols.JDBC_PING] (ServerService Thread Pool -- 23) JGRP000115: Could not open connection to database: java.sql.SQLException: javax.resource.ResourceException: IJ000470: You are trying to use a connection factory that has been shut down: java:jboss/datasources/KeycloakDS > keycloak_2 | at org.jboss.ironjacamar.jdbcadapters@1.4.17.Final//org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:159) > keycloak_2 | at org.jboss.as.connector@18.0.1.Final//org.jboss.as.connector.subsystems.datasources.WildFlyDataSource.getConnection(WildFlyDataSource.java:64) > keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.protocols.JDBC_PING.getConnection(JDBC_PING.java:310) > keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.protocols.JDBC_PING.clearTable(JDBC_PING.java:361) > keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.protocols.JDBC_PING.removeAll(JDBC_PING.java:190) > keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.protocols.JDBC_PING.stop(JDBC_PING.java:119) > keycloak_2 | at java.base/java.util.ArrayList.forEach(ArrayList.java:1540) > keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.stack.ProtocolStack.stopStack(ProtocolStack.java:906) > keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.JChannel.stopStack(JChannel.java:1076) > keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.JChannel._close(JChannel.java:1063) > keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.JChannel.close(JChannel.java:454) > keycloak_2 | at org.jboss.as.clustering.jgroups@18.0.1.Final//org.jboss.as.clustering.jgroups.subsystem.ChannelServiceConfigurator.accept(ChannelServiceConfigurator.java:132) > keycloak_2 | at org.jboss.as.clustering.jgroups@18.0.1.Final//org.jboss.as.clustering.jgroups.subsystem.ChannelServiceConfigurator.accept(ChannelServiceConfigurator.java:58) > keycloak_2 | at org.wildfly.clustering.service@18.0.1.Final//org.wildfly.clustering.service.FunctionalService.stop(FunctionalService.java:77) > keycloak_2 | at org.wildfly.clustering.service@18.0.1.Final//org.wildfly.clustering.service.AsyncServiceConfigurator$AsyncService.lambda$stop$1(AsyncServiceConfigurator.java:142) > keycloak_2 | at org.jboss.threads@2.3.3.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) > keycloak_2 | at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982) > keycloak_2 | at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486) > keycloak_2 | at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377) > keycloak_2 | at java.base/java.lang.Thread.run(Thread.java:834) > keycloak_2 | at org.jboss.threads@2.3.3.Final//org.jboss.threads.JBossThread.run(JBossThread.java:485) > keycloak_2 | Caused by: javax.resource.ResourceException: IJ000470: You are trying to use a connection factory that has been shut down: java:jboss/datasources/KeycloakDS > keycloak_2 | at org.jboss.ironjacamar.impl@1.4.17.Final//org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:777) > keycloak_2 | at org.jboss.ironjacamar.jdbcadapters@1.4.17.Final//org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:151) > keycloak_2 | ... 20 more > keycloak_2 | 09:14:34,807 ERROR [org.jgroups.JChannel] (ServerService Thread Pool -- 23) JGRP000020: failed destroying the protocol stack: java.lang.NullPointerException > keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.protocols.JDBC_PING.clearTable(JDBC_PING.java:362) > keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.protocols.JDBC_PING.removeAll(JDBC_PING.java:190) > keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.protocols.JDBC_PING.stop(JDBC_PING.java:119) > keycloak_2 | at java.base/java.util.ArrayList.forEach(ArrayList.java:1540) > keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.stack.ProtocolStack.stopStack(ProtocolStack.java:906) > keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.JChannel.stopStack(JChannel.java:1076) > keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.JChannel._close(JChannel.java:1063) > keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.JChannel.close(JChannel.java:454) > keycloak_2 | at org.jboss.as.clustering.jgroups@18.0.1.Final//org.jboss.as.clustering.jgroups.subsystem.ChannelServiceConfigurator.accept(ChannelServiceConfigurator.java:132) > keycloak_2 | at org.jboss.as.clustering.jgroups@18.0.1.Final//org.jboss.as.clustering.jgroups.subsystem.ChannelServiceConfigurator.accept(ChannelServiceConfigurator.java:58) > keycloak_2 | at org.wildfly.clustering.service@18.0.1.Final//org.wildfly.clustering.service.FunctionalService.stop(FunctionalService.java:77) > keycloak_2 | at org.wildfly.clustering.service@18.0.1.Final//org.wildfly.clustering.service.AsyncServiceConfigurator$AsyncService.lambda$stop$1(AsyncServiceConfigurator.java:142) > keycloak_2 | at org.jboss.threads@2.3.3.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) > keycloak_2 | at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982) > keycloak_2 | at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486) > keycloak_2 | at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377) > keycloak_2 | at java.base/java.lang.Thread.run(Thread.java:834) > keycloak_2 | at org.jboss.threads@2.3.3.Final//org.jboss.threads.JBossThread.run(JBossThread.java:485) > keycloak_2 | 09:14:34,819 INFO [org.jboss.as] (MSC service thread 1-5) WFLYSRV0050: Keycloak 8.0.1 (WildFly Core 10.0.3.Final) stopped in 160ms > keycloak_2 | *** JBossAS process (510) received TERM signal *** > {code} > More information: > * Generated {{standalone-ha.xml}} used by the example: https://gist.github.com/slaskawi/7cb8eefdfa3e27f7c0f0e62e26bb0216 > * Full logs from Docker Compose: https://gist.github.com/slaskawi/239a2a1ea83d7bc98c8d0d884480c77e -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12948) When shutting down, JDBC_PING tries to use a closed connection

by Sebastian Laskawiec (Jira)

[ https://issues.redhat.com/browse/WFLY-12948?page=com.atlassian.jira.plugi... ] Sebastian Laskawiec updated WFLY-12948: --------------------------------------- Description: One of the Keycloak demos use {{JDBC_PING}} as discovery protocol (see [here|https://github.com/keycloak/keycloak-containers/blob/master/docker-c...]). One of our users noticed (and I confirmed it) that when shutting Keycloak down, {{JDBC_PING}} tries to use a closed Connection Factory: {code} keycloak_2 | 09:14:34,807 ERROR [org.jgroups.protocols.JDBC_PING] (ServerService Thread Pool -- 23) JGRP000115: Could not open connection to database: java.sql.SQLException: javax.resource.ResourceException: IJ000470: You are trying to use a connection factory that has been shut down: java:jboss/datasources/KeycloakDS keycloak_2 | at org.jboss.ironjacamar.jdbcadapters@1.4.17.Final//org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:159) keycloak_2 | at org.jboss.as.connector@18.0.1.Final//org.jboss.as.connector.subsystems.datasources.WildFlyDataSource.getConnection(WildFlyDataSource.java:64) keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.protocols.JDBC_PING.getConnection(JDBC_PING.java:310) keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.protocols.JDBC_PING.clearTable(JDBC_PING.java:361) keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.protocols.JDBC_PING.removeAll(JDBC_PING.java:190) keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.protocols.JDBC_PING.stop(JDBC_PING.java:119) keycloak_2 | at java.base/java.util.ArrayList.forEach(ArrayList.java:1540) keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.stack.ProtocolStack.stopStack(ProtocolStack.java:906) keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.JChannel.stopStack(JChannel.java:1076) keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.JChannel._close(JChannel.java:1063) keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.JChannel.close(JChannel.java:454) keycloak_2 | at org.jboss.as.clustering.jgroups@18.0.1.Final//org.jboss.as.clustering.jgroups.subsystem.ChannelServiceConfigurator.accept(ChannelServiceConfigurator.java:132) keycloak_2 | at org.jboss.as.clustering.jgroups@18.0.1.Final//org.jboss.as.clustering.jgroups.subsystem.ChannelServiceConfigurator.accept(ChannelServiceConfigurator.java:58) keycloak_2 | at org.wildfly.clustering.service@18.0.1.Final//org.wildfly.clustering.service.FunctionalService.stop(FunctionalService.java:77) keycloak_2 | at org.wildfly.clustering.service@18.0.1.Final//org.wildfly.clustering.service.AsyncServiceConfigurator$AsyncService.lambda$stop$1(AsyncServiceConfigurator.java:142) keycloak_2 | at org.jboss.threads@2.3.3.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) keycloak_2 | at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982) keycloak_2 | at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486) keycloak_2 | at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377) keycloak_2 | at java.base/java.lang.Thread.run(Thread.java:834) keycloak_2 | at org.jboss.threads@2.3.3.Final//org.jboss.threads.JBossThread.run(JBossThread.java:485) keycloak_2 | Caused by: javax.resource.ResourceException: IJ000470: You are trying to use a connection factory that has been shut down: java:jboss/datasources/KeycloakDS keycloak_2 | at org.jboss.ironjacamar.impl@1.4.17.Final//org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:777) keycloak_2 | at org.jboss.ironjacamar.jdbcadapters@1.4.17.Final//org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:151) keycloak_2 | ... 20 more keycloak_2 | 09:14:34,807 ERROR [org.jgroups.JChannel] (ServerService Thread Pool -- 23) JGRP000020: failed destroying the protocol stack: java.lang.NullPointerException keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.protocols.JDBC_PING.clearTable(JDBC_PING.java:362) keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.protocols.JDBC_PING.removeAll(JDBC_PING.java:190) keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.protocols.JDBC_PING.stop(JDBC_PING.java:119) keycloak_2 | at java.base/java.util.ArrayList.forEach(ArrayList.java:1540) keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.stack.ProtocolStack.stopStack(ProtocolStack.java:906) keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.JChannel.stopStack(JChannel.java:1076) keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.JChannel._close(JChannel.java:1063) keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.JChannel.close(JChannel.java:454) keycloak_2 | at org.jboss.as.clustering.jgroups@18.0.1.Final//org.jboss.as.clustering.jgroups.subsystem.ChannelServiceConfigurator.accept(ChannelServiceConfigurator.java:132) keycloak_2 | at org.jboss.as.clustering.jgroups@18.0.1.Final//org.jboss.as.clustering.jgroups.subsystem.ChannelServiceConfigurator.accept(ChannelServiceConfigurator.java:58) keycloak_2 | at org.wildfly.clustering.service@18.0.1.Final//org.wildfly.clustering.service.FunctionalService.stop(FunctionalService.java:77) keycloak_2 | at org.wildfly.clustering.service@18.0.1.Final//org.wildfly.clustering.service.AsyncServiceConfigurator$AsyncService.lambda$stop$1(AsyncServiceConfigurator.java:142) keycloak_2 | at org.jboss.threads@2.3.3.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) keycloak_2 | at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982) keycloak_2 | at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486) keycloak_2 | at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377) keycloak_2 | at java.base/java.lang.Thread.run(Thread.java:834) keycloak_2 | at org.jboss.threads@2.3.3.Final//org.jboss.threads.JBossThread.run(JBossThread.java:485) keycloak_2 | 09:14:34,819 INFO [org.jboss.as] (MSC service thread 1-5) WFLYSRV0050: Keycloak 8.0.1 (WildFly Core 10.0.3.Final) stopped in 160ms keycloak_2 | *** JBossAS process (510) received TERM signal *** {code} More information: * Generated {{standalone-ha.xml}} used by the example: https://gist.github.com/slaskawi/7cb8eefdfa3e27f7c0f0e62e26bb0216 * Full logs from Docker Compose: https://gist.github.com/slaskawi/239a2a1ea83d7bc98c8d0d884480c77e was: One of the Keycloak demos use {{JDBC_PING}} as discovery protocol (see [here|https://github.com/keycloak/keycloak-containers/blob/master/docker-c...]). One of our users noticed (and I confirmed it) that when shutting Keycloak down, {{JDBC_PING}} tries to use a closed Connection Factory: {code} keycloak_2 | 09:14:34,807 ERROR [org.jgroups.protocols.JDBC_PING] (ServerService Thread Pool -- 23) JGRP000115: Could not open connection to database: java.sql.SQLException: javax.resource.ResourceException: IJ000470: You are trying to use a connection factory that has been shut down: java:jboss/datasources/KeycloakDS keycloak_2 | at org.jboss.ironjacamar.jdbcadapters@1.4.17.Final//org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:159) keycloak_2 | at org.jboss.as.connector@18.0.1.Final//org.jboss.as.connector.subsystems.datasources.WildFlyDataSource.getConnection(WildFlyDataSource.java:64) keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.protocols.JDBC_PING.getConnection(JDBC_PING.java:310) keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.protocols.JDBC_PING.clearTable(JDBC_PING.java:361) keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.protocols.JDBC_PING.removeAll(JDBC_PING.java:190) keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.protocols.JDBC_PING.stop(JDBC_PING.java:119) keycloak_2 | at java.base/java.util.ArrayList.forEach(ArrayList.java:1540) keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.stack.ProtocolStack.stopStack(ProtocolStack.java:906) keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.JChannel.stopStack(JChannel.java:1076) keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.JChannel._close(JChannel.java:1063) keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.JChannel.close(JChannel.java:454) keycloak_2 | at org.jboss.as.clustering.jgroups@18.0.1.Final//org.jboss.as.clustering.jgroups.subsystem.ChannelServiceConfigurator.accept(ChannelServiceConfigurator.java:132) keycloak_2 | at org.jboss.as.clustering.jgroups@18.0.1.Final//org.jboss.as.clustering.jgroups.subsystem.ChannelServiceConfigurator.accept(ChannelServiceConfigurator.java:58) keycloak_2 | at org.wildfly.clustering.service@18.0.1.Final//org.wildfly.clustering.service.FunctionalService.stop(FunctionalService.java:77) keycloak_2 | at org.wildfly.clustering.service@18.0.1.Final//org.wildfly.clustering.service.AsyncServiceConfigurator$AsyncService.lambda$stop$1(AsyncServiceConfigurator.java:142) keycloak_2 | at org.jboss.threads@2.3.3.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) keycloak_2 | at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982) keycloak_2 | at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486) keycloak_2 | at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377) keycloak_2 | at java.base/java.lang.Thread.run(Thread.java:834) keycloak_2 | at org.jboss.threads@2.3.3.Final//org.jboss.threads.JBossThread.run(JBossThread.java:485) keycloak_2 | Caused by: javax.resource.ResourceException: IJ000470: You are trying to use a connection factory that has been shut down: java:jboss/datasources/KeycloakDS keycloak_2 | at org.jboss.ironjacamar.impl@1.4.17.Final//org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:777) keycloak_2 | at org.jboss.ironjacamar.jdbcadapters@1.4.17.Final//org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:151) keycloak_2 | ... 20 more keycloak_2 | 09:14:34,807 ERROR [org.jgroups.JChannel] (ServerService Thread Pool -- 23) JGRP000020: failed destroying the protocol stack: java.lang.NullPointerException keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.protocols.JDBC_PING.clearTable(JDBC_PING.java:362) keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.protocols.JDBC_PING.removeAll(JDBC_PING.java:190) keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.protocols.JDBC_PING.stop(JDBC_PING.java:119) keycloak_2 | at java.base/java.util.ArrayList.forEach(ArrayList.java:1540) keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.stack.ProtocolStack.stopStack(ProtocolStack.java:906) keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.JChannel.stopStack(JChannel.java:1076) keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.JChannel._close(JChannel.java:1063) keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.JChannel.close(JChannel.java:454) keycloak_2 | at org.jboss.as.clustering.jgroups@18.0.1.Final//org.jboss.as.clustering.jgroups.subsystem.ChannelServiceConfigurator.accept(ChannelServiceConfigurator.java:132) keycloak_2 | at org.jboss.as.clustering.jgroups@18.0.1.Final//org.jboss.as.clustering.jgroups.subsystem.ChannelServiceConfigurator.accept(ChannelServiceConfigurator.java:58) keycloak_2 | at org.wildfly.clustering.service@18.0.1.Final//org.wildfly.clustering.service.FunctionalService.stop(FunctionalService.java:77) keycloak_2 | at org.wildfly.clustering.service@18.0.1.Final//org.wildfly.clustering.service.AsyncServiceConfigurator$AsyncService.lambda$stop$1(AsyncServiceConfigurator.java:142) keycloak_2 | at org.jboss.threads@2.3.3.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) keycloak_2 | at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982) keycloak_2 | at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486) keycloak_2 | at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377) keycloak_2 | at java.base/java.lang.Thread.run(Thread.java:834) keycloak_2 | at org.jboss.threads@2.3.3.Final//org.jboss.threads.JBossThread.run(JBossThread.java:485) keycloak_2 | 09:14:34,819 INFO [org.jboss.as] (MSC service thread 1-5) WFLYSRV0050: Keycloak 8.0.1 (WildFly Core 10.0.3.Final) stopped in 160ms keycloak_2 | *** JBossAS process (510) received TERM signal *** {code} > When shutting down, JDBC_PING tries to use a closed connection > -------------------------------------------------------------- > > Key: WFLY-12948 > URL: https://issues.redhat.com/browse/WFLY-12948 > Project: WildFly > Issue Type: Bug > Components: Clustering > Reporter: Sebastian Laskawiec > Assignee: Paul Ferraro > Priority: Minor > > One of the Keycloak demos use {{JDBC_PING}} as discovery protocol (see [here|https://github.com/keycloak/keycloak-containers/blob/master/docker-c...]). One of our users noticed (and I confirmed it) that when shutting Keycloak down, {{JDBC_PING}} tries to use a closed Connection Factory: > {code} > keycloak_2 | 09:14:34,807 ERROR [org.jgroups.protocols.JDBC_PING] (ServerService Thread Pool -- 23) JGRP000115: Could not open connection to database: java.sql.SQLException: javax.resource.ResourceException: IJ000470: You are trying to use a connection factory that has been shut down: java:jboss/datasources/KeycloakDS > keycloak_2 | at org.jboss.ironjacamar.jdbcadapters@1.4.17.Final//org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:159) > keycloak_2 | at org.jboss.as.connector@18.0.1.Final//org.jboss.as.connector.subsystems.datasources.WildFlyDataSource.getConnection(WildFlyDataSource.java:64) > keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.protocols.JDBC_PING.getConnection(JDBC_PING.java:310) > keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.protocols.JDBC_PING.clearTable(JDBC_PING.java:361) > keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.protocols.JDBC_PING.removeAll(JDBC_PING.java:190) > keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.protocols.JDBC_PING.stop(JDBC_PING.java:119) > keycloak_2 | at java.base/java.util.ArrayList.forEach(ArrayList.java:1540) > keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.stack.ProtocolStack.stopStack(ProtocolStack.java:906) > keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.JChannel.stopStack(JChannel.java:1076) > keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.JChannel._close(JChannel.java:1063) > keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.JChannel.close(JChannel.java:454) > keycloak_2 | at org.jboss.as.clustering.jgroups@18.0.1.Final//org.jboss.as.clustering.jgroups.subsystem.ChannelServiceConfigurator.accept(ChannelServiceConfigurator.java:132) > keycloak_2 | at org.jboss.as.clustering.jgroups@18.0.1.Final//org.jboss.as.clustering.jgroups.subsystem.ChannelServiceConfigurator.accept(ChannelServiceConfigurator.java:58) > keycloak_2 | at org.wildfly.clustering.service@18.0.1.Final//org.wildfly.clustering.service.FunctionalService.stop(FunctionalService.java:77) > keycloak_2 | at org.wildfly.clustering.service@18.0.1.Final//org.wildfly.clustering.service.AsyncServiceConfigurator$AsyncService.lambda$stop$1(AsyncServiceConfigurator.java:142) > keycloak_2 | at org.jboss.threads@2.3.3.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) > keycloak_2 | at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982) > keycloak_2 | at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486) > keycloak_2 | at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377) > keycloak_2 | at java.base/java.lang.Thread.run(Thread.java:834) > keycloak_2 | at org.jboss.threads@2.3.3.Final//org.jboss.threads.JBossThread.run(JBossThread.java:485) > keycloak_2 | Caused by: javax.resource.ResourceException: IJ000470: You are trying to use a connection factory that has been shut down: java:jboss/datasources/KeycloakDS > keycloak_2 | at org.jboss.ironjacamar.impl@1.4.17.Final//org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:777) > keycloak_2 | at org.jboss.ironjacamar.jdbcadapters@1.4.17.Final//org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:151) > keycloak_2 | ... 20 more > keycloak_2 | 09:14:34,807 ERROR [org.jgroups.JChannel] (ServerService Thread Pool -- 23) JGRP000020: failed destroying the protocol stack: java.lang.NullPointerException > keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.protocols.JDBC_PING.clearTable(JDBC_PING.java:362) > keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.protocols.JDBC_PING.removeAll(JDBC_PING.java:190) > keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.protocols.JDBC_PING.stop(JDBC_PING.java:119) > keycloak_2 | at java.base/java.util.ArrayList.forEach(ArrayList.java:1540) > keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.stack.ProtocolStack.stopStack(ProtocolStack.java:906) > keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.JChannel.stopStack(JChannel.java:1076) > keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.JChannel._close(JChannel.java:1063) > keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.JChannel.close(JChannel.java:454) > keycloak_2 | at org.jboss.as.clustering.jgroups@18.0.1.Final//org.jboss.as.clustering.jgroups.subsystem.ChannelServiceConfigurator.accept(ChannelServiceConfigurator.java:132) > keycloak_2 | at org.jboss.as.clustering.jgroups@18.0.1.Final//org.jboss.as.clustering.jgroups.subsystem.ChannelServiceConfigurator.accept(ChannelServiceConfigurator.java:58) > keycloak_2 | at org.wildfly.clustering.service@18.0.1.Final//org.wildfly.clustering.service.FunctionalService.stop(FunctionalService.java:77) > keycloak_2 | at org.wildfly.clustering.service@18.0.1.Final//org.wildfly.clustering.service.AsyncServiceConfigurator$AsyncService.lambda$stop$1(AsyncServiceConfigurator.java:142) > keycloak_2 | at org.jboss.threads@2.3.3.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) > keycloak_2 | at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982) > keycloak_2 | at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486) > keycloak_2 | at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377) > keycloak_2 | at java.base/java.lang.Thread.run(Thread.java:834) > keycloak_2 | at org.jboss.threads@2.3.3.Final//org.jboss.threads.JBossThread.run(JBossThread.java:485) > keycloak_2 | 09:14:34,819 INFO [org.jboss.as] (MSC service thread 1-5) WFLYSRV0050: Keycloak 8.0.1 (WildFly Core 10.0.3.Final) stopped in 160ms > keycloak_2 | *** JBossAS process (510) received TERM signal *** > {code} > More information: > * Generated {{standalone-ha.xml}} used by the example: https://gist.github.com/slaskawi/7cb8eefdfa3e27f7c0f0e62e26bb0216 > * Full logs from Docker Compose: https://gist.github.com/slaskawi/239a2a1ea83d7bc98c8d0d884480c77e -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

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

by Fabio Burzigotti (Jira)

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

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12948) When shutting down, JDBC_PING tries to use a closed connection

by Sebastian Laskawiec (Jira)

Sebastian Laskawiec created WFLY-12948: ------------------------------------------ Summary: When shutting down, JDBC_PING tries to use a closed connection Key: WFLY-12948 URL: https://issues.redhat.com/browse/WFLY-12948 Project: WildFly Issue Type: Bug Components: Clustering Reporter: Sebastian Laskawiec Assignee: Paul Ferraro One of the Keycloak demos use {{JDBC_PING}} as discovery protocol (see [here|https://github.com/keycloak/keycloak-containers/blob/master/docker-c...]). One of our users noticed (and I confirmed it) that when shutting Keycloak down, {{JDBC_PING}} tries to use a closed Connection Factory: {code} keycloak_2 | 09:14:34,807 ERROR [org.jgroups.protocols.JDBC_PING] (ServerService Thread Pool -- 23) JGRP000115: Could not open connection to database: java.sql.SQLException: javax.resource.ResourceException: IJ000470: You are trying to use a connection factory that has been shut down: java:jboss/datasources/KeycloakDS keycloak_2 | at org.jboss.ironjacamar.jdbcadapters@1.4.17.Final//org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:159) keycloak_2 | at org.jboss.as.connector@18.0.1.Final//org.jboss.as.connector.subsystems.datasources.WildFlyDataSource.getConnection(WildFlyDataSource.java:64) keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.protocols.JDBC_PING.getConnection(JDBC_PING.java:310) keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.protocols.JDBC_PING.clearTable(JDBC_PING.java:361) keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.protocols.JDBC_PING.removeAll(JDBC_PING.java:190) keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.protocols.JDBC_PING.stop(JDBC_PING.java:119) keycloak_2 | at java.base/java.util.ArrayList.forEach(ArrayList.java:1540) keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.stack.ProtocolStack.stopStack(ProtocolStack.java:906) keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.JChannel.stopStack(JChannel.java:1076) keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.JChannel._close(JChannel.java:1063) keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.JChannel.close(JChannel.java:454) keycloak_2 | at org.jboss.as.clustering.jgroups@18.0.1.Final//org.jboss.as.clustering.jgroups.subsystem.ChannelServiceConfigurator.accept(ChannelServiceConfigurator.java:132) keycloak_2 | at org.jboss.as.clustering.jgroups@18.0.1.Final//org.jboss.as.clustering.jgroups.subsystem.ChannelServiceConfigurator.accept(ChannelServiceConfigurator.java:58) keycloak_2 | at org.wildfly.clustering.service@18.0.1.Final//org.wildfly.clustering.service.FunctionalService.stop(FunctionalService.java:77) keycloak_2 | at org.wildfly.clustering.service@18.0.1.Final//org.wildfly.clustering.service.AsyncServiceConfigurator$AsyncService.lambda$stop$1(AsyncServiceConfigurator.java:142) keycloak_2 | at org.jboss.threads@2.3.3.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) keycloak_2 | at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982) keycloak_2 | at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486) keycloak_2 | at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377) keycloak_2 | at java.base/java.lang.Thread.run(Thread.java:834) keycloak_2 | at org.jboss.threads@2.3.3.Final//org.jboss.threads.JBossThread.run(JBossThread.java:485) keycloak_2 | Caused by: javax.resource.ResourceException: IJ000470: You are trying to use a connection factory that has been shut down: java:jboss/datasources/KeycloakDS keycloak_2 | at org.jboss.ironjacamar.impl@1.4.17.Final//org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:777) keycloak_2 | at org.jboss.ironjacamar.jdbcadapters@1.4.17.Final//org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:151) keycloak_2 | ... 20 more keycloak_2 | 09:14:34,807 ERROR [org.jgroups.JChannel] (ServerService Thread Pool -- 23) JGRP000020: failed destroying the protocol stack: java.lang.NullPointerException keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.protocols.JDBC_PING.clearTable(JDBC_PING.java:362) keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.protocols.JDBC_PING.removeAll(JDBC_PING.java:190) keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.protocols.JDBC_PING.stop(JDBC_PING.java:119) keycloak_2 | at java.base/java.util.ArrayList.forEach(ArrayList.java:1540) keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.stack.ProtocolStack.stopStack(ProtocolStack.java:906) keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.JChannel.stopStack(JChannel.java:1076) keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.JChannel._close(JChannel.java:1063) keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.JChannel.close(JChannel.java:454) keycloak_2 | at org.jboss.as.clustering.jgroups@18.0.1.Final//org.jboss.as.clustering.jgroups.subsystem.ChannelServiceConfigurator.accept(ChannelServiceConfigurator.java:132) keycloak_2 | at org.jboss.as.clustering.jgroups@18.0.1.Final//org.jboss.as.clustering.jgroups.subsystem.ChannelServiceConfigurator.accept(ChannelServiceConfigurator.java:58) keycloak_2 | at org.wildfly.clustering.service@18.0.1.Final//org.wildfly.clustering.service.FunctionalService.stop(FunctionalService.java:77) keycloak_2 | at org.wildfly.clustering.service@18.0.1.Final//org.wildfly.clustering.service.AsyncServiceConfigurator$AsyncService.lambda$stop$1(AsyncServiceConfigurator.java:142) keycloak_2 | at org.jboss.threads@2.3.3.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) keycloak_2 | at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982) keycloak_2 | at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486) keycloak_2 | at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377) keycloak_2 | at java.base/java.lang.Thread.run(Thread.java:834) keycloak_2 | at org.jboss.threads@2.3.3.Final//org.jboss.threads.JBossThread.run(JBossThread.java:485) keycloak_2 | 09:14:34,819 INFO [org.jboss.as] (MSC service thread 1-5) WFLYSRV0050: Keycloak 8.0.1 (WildFly Core 10.0.3.Final) stopped in 160ms keycloak_2 | *** JBossAS process (510) received TERM signal *** {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

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

by Fabio Burzigotti (Jira)

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

6 years, 6 months

1
0
0 / 0

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

by Fabio Burzigotti (Jira)

[ https://issues.redhat.com/browse/WFWIP-290?page=com.atlassian.jira.plugin... ] Fabio Burzigotti edited comment on WFWIP-290 at 1/9/20 4:19 AM: ---------------------------------------------------------------- Thanks [~pferraro]. Tests are confirming for this to be fixed with following feature branch version: * https://github.com/pferraro/wildfly/tree/WFLY-12313 * commit: 7c53fecadc5df6b8e5f0c2795bc8b9daf58055bd Closing the issue. was (Author: fburzigo): Thanks [~pferraro]. Tests are confirming for this to be fixed with following feature branch version: * commit: 7c53fecadc5df6b8e5f0c2795bc8b9daf58055bd Closing the issue. > Response Content-Type is 'application/json' even when HTTP request defines 'application/json-patch+json' "Accept" header > ------------------------------------------------------------------------------------------------------------------------ > > Key: WFWIP-290 > URL: https://issues.redhat.com/browse/WFWIP-290 > Project: WildFly WIP > Issue Type: Bug > Components: MP OpenAPI > Reporter: Fabio Burzigotti > Assignee: Paul Ferraro > Priority: Major > > When sending HTTP request header "Accept: application/json-patch+json", "Content-Type: application/json" response is returned. > This behavior seems to be less strict compared to what is defined by the spec, as it states "application/json" is specifically needed in order to get the same value back from server. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

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

by Fabio Burzigotti (Jira)

[ https://issues.redhat.com/browse/WFWIP-290?page=com.atlassian.jira.plugin... ] Fabio Burzigotti commented on WFWIP-290: ---------------------------------------- Thanks [~pferraro]. Tests are confirming for this to be fixed with following feature branch version: * commit: 7c53fecadc5df6b8e5f0c2795bc8b9daf58055bd Closing the issue. > Response Content-Type is 'application/json' even when HTTP request defines 'application/json-patch+json' "Accept" header > ------------------------------------------------------------------------------------------------------------------------ > > Key: WFWIP-290 > URL: https://issues.redhat.com/browse/WFWIP-290 > Project: WildFly WIP > Issue Type: Bug > Components: MP OpenAPI > Reporter: Fabio Burzigotti > Assignee: Paul Ferraro > Priority: Major > > When sending HTTP request header "Accept: application/json-patch+json", "Content-Type: application/json" response is returned. > This behavior seems to be less strict compared to what is defined by the spec, as it states "application/json" is specifically needed in order to get the same value back from server. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4881) Reactivate CustomExtensionTests with the executable model in droolsjsbpm-integration

by Luca Molteni (Jira)

[ https://issues.redhat.com/browse/DROOLS-4881?page=com.atlassian.jira.plug... ] Luca Molteni updated DROOLS-4881: --------------------------------- Labels: good-first-issue (was: ) > Reactivate CustomExtensionTests with the executable model in droolsjsbpm-integration > ------------------------------------------------------------------------------------ > > Key: DROOLS-4881 > URL: https://issues.redhat.com/browse/DROOLS-4881 > Project: Drools > Issue Type: Bug > Components: executable model > Reporter: Luca Molteni > Assignee: Luca Molteni > Priority: Major > Labels: good-first-issue > > See https://github.com/kiegroup/droolsjbpm-integration/pull/1864/commits/4e0b... -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4880) JAXB serialize DomainClassMetadata classes

by Luca Molteni (Jira)

[ https://issues.redhat.com/browse/DROOLS-4880?page=com.atlassian.jira.plug... ] Luca Molteni updated DROOLS-4880: --------------------------------- Labels: good-first-issue (was: ) > JAXB serialize DomainClassMetadata classes > ------------------------------------------ > > Key: DROOLS-4880 > URL: https://issues.redhat.com/browse/DROOLS-4880 > Project: Drools > Issue Type: Bug > Components: executable model > Reporter: Luca Molteni > Assignee: Luca Molteni > Priority: Major > Labels: good-first-issue > > See > https://github.com/kiegroup/droolsjbpm-integration/pull/1864/commits/2331... > The Price class was moved from a static inner class because it was causing a JAXB problem in OptaPlannerIntegrationTest that crashed while trying to serialize DomainClassMetadata (due to the creation of the synthetic class CloudBalancingGenerator$1 > Customers are still relying on static inner class so we should have this test running in the original form > run the test with > mvn -nsu -Dcontainer=wildfly -Dintegration-tests=true -Dfull=true -Dcontainer.profile=wildfly -Pwildfly clean install -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4885) Renabble DMNPMMLRegressionIntegrationTest

by Luca Molteni (Jira)

[ https://issues.redhat.com/browse/DROOLS-4885?page=com.atlassian.jira.plug... ] Luca Molteni updated DROOLS-4885: --------------------------------- Labels: good-first-issue (was: ) > Renabble DMNPMMLRegressionIntegrationTest > ----------------------------------------- > > Key: DROOLS-4885 > URL: https://issues.redhat.com/browse/DROOLS-4885 > Project: Drools > Issue Type: Bug > Components: executable model > Reporter: Luca Molteni > Assignee: Luca Molteni > Priority: Major > Labels: good-first-issue > > See https://github.com/kiegroup/droolsjbpm-integration/pull/1864/commits/873d... > This test doesn't work with the executable model -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4914) Reactivate DMNPMMLScorecardIntegrationTest with the executable model in droolsjsbpm-integration

by Luca Molteni (Jira)

[ https://issues.redhat.com/browse/DROOLS-4914?page=com.atlassian.jira.plug... ] Luca Molteni updated DROOLS-4914: --------------------------------- Labels: good-first-issue (was: ) > Reactivate DMNPMMLScorecardIntegrationTest with the executable model in droolsjsbpm-integration > ----------------------------------------------------------------------------------------------- > > Key: DROOLS-4914 > URL: https://issues.redhat.com/browse/DROOLS-4914 > Project: Drools > Issue Type: Enhancement > Components: executable model > Reporter: Luca Molteni > Assignee: Luca Molteni > Priority: Major > Labels: good-first-issue > > It was disabled with > generateModel=NO > droolsjbpm-integration/kie-server-parent/kie-server-tests/kie-server-integ-tests-dmn/src/test/filtered-resources/kjars-sources/dmn-pmml-scorecard/pom.xml > but it should work on the exec model also -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4891) Further Optimize Lambdas in Executable Model

by Luca Molteni (Jira)

[ https://issues.redhat.com/browse/DROOLS-4891?page=com.atlassian.jira.plug... ] Luca Molteni updated DROOLS-4891: --------------------------------- Labels: good-first-issue (was: ) > Further Optimize Lambdas in Executable Model > -------------------------------------------- > > Key: DROOLS-4891 > URL: https://issues.redhat.com/browse/DROOLS-4891 > Project: Drools > Issue Type: Enhancement > Reporter: Luca Molteni > Assignee: Luca Molteni > Priority: Major > Labels: good-first-issue > > Lambda shouldn't be externalized depending on the variable name but on the actual lambda. > So > person.name == a > person.name == b > Is effectively the same lambda and should externalized once. > Hint: we could rename the parameters to p1, p2, p3, promote the types to fully qualified names and get this result. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4914) Reactivate DMNPMMLScorecardIntegrationTest with the executable model in droolsjsbpm-integration

by Luca Molteni (Jira)

Luca Molteni created DROOLS-4914: ------------------------------------ Summary: Reactivate DMNPMMLScorecardIntegrationTest with the executable model in droolsjsbpm-integration Key: DROOLS-4914 URL: https://issues.redhat.com/browse/DROOLS-4914 Project: Drools Issue Type: Enhancement Components: executable model Reporter: Luca Molteni Assignee: Luca Molteni It was disabled with generateModel=NO droolsjbpm-integration/kie-server-parent/kie-server-tests/kie-server-integ-tests-dmn/src/test/filtered-resources/kjars-sources/dmn-pmml-scorecard/pom.xml but it should work on the exec model also -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[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. 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. > 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. > 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

1
0
0 / 0

[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 reassigned WFWIP-294: ------------------------------- Assignee: Darran Lofthouse (was: Kabir Khan) > 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. > Attached is "flawed" key set with "blue-key" placed on first position in array. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[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: ---------------------------- Component/s: MP JWT > 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: Kabir Khan > 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. > Attached is "flawed" key set with "blue-key" placed on first position in array. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-294) JWT is rejected if signature matching public key is not first in JWK set

by Jan Kasik (Jira)

Jan Kasik created WFWIP-294: ------------------------------- Summary: 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 Reporter: Jan Kasik Assignee: Kabir Khan 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. Attached is "flawed" key set with "blue-key" placed on first position in array. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12947) EL should coerce String to Integer in equals operation

by Ricardo Martin Camarero (Jira)

[ https://issues.redhat.com/browse/WFLY-12947?page=com.atlassian.jira.plugi... ] Ricardo Martin Camarero moved JBEAP-18439 to WFLY-12947: -------------------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-12947 (was: JBEAP-18439) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: EE (was: EE) Affects Version/s: 18.0.1.Final (was: 7.2.5.GA) QE Test Coverage: (was: +) > EL should coerce String to Integer in equals operation > ------------------------------------------------------ > > Key: WFLY-12947 > URL: https://issues.redhat.com/browse/WFLY-12947 > Project: WildFly > Issue Type: Bug > Components: EE > Affects Versions: 18.0.1.Final > Reporter: Ricardo Martin Camarero > Assignee: Ricardo Martin Camarero > Priority: Major > > EAP 7's EL equals operations work differently from EAP 6 one. > For example: put the following JSP in your web application (e.g. example.war) > {code:java|title=test.jsp} > <% request.setAttribute("testAttr", "01"); %> > ${testAttr == 1} > ${param['foo'] == 1} > ${1 == param['foo']} > ${1 == (0+param['foo'])} > {code} > Then, access the above JSP with curl command: > {code} > $ curl http://localhost:8080/example/test.jsp?foo=01 > {code} > - Expected result (EAP 6's behavior): > {code} > true > true > true > true > {code} > - Actual result (EAP 7's behavior): > {code} > false > false > false > true > {code} > In the section 1.9.2 of [EL 3.0 Specification|https://download.oracle.com/otndocs/jcp/el-3_0-fr-eval-spec...], the ==,!= operators have the following step: > {code} > ■If A==B, apply operator > ■ If A is null or B is null return false for == or eq, true for != or ne. > ■ If A or B is BigDecimal, coerce both A and B to BigDecimal and then: > ■ If operator is == or eq, return A.equals(B) > ■ If operator is != or ne, return !A.equals(B) > ■ If A or B is Float or Double coerce both A and B to Double, apply operator > ■ If A or B is BigInteger, coerce both A and B to BigInteger and then: > ■ If operator is == or eq, return A.equals(B) > ■ If operator is != or ne, return !A.equals(B) > ■ If A or B is Byte, Short, Character, Integer, or Long coerce both A and B to Long, apply operator > ■ If A or B is Boolean coerce both A and B to Boolean, apply operator > ■ If A or B is an enum, coerce both A and B to enum, apply operator > ■ If A or B is String coerce both A and B to String, compare lexically > ■ Otherwise if an error occurs while calling A.equals(B), error > ■ Otherwise, apply operator to result of A.equals(B) > {code} > Note that the step "If A or B is Byte, Short, Character, Integer, or Long coerce both A and B to Long, apply operator" should happen earlier than the step coercion to String. So, it appears that EAP 7's behavior violates the spec. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4909) Infinite recursion in drools after version change from v7.20 to v7.21

by Mario Fusco (Jira)

[ https://issues.redhat.com/browse/DROOLS-4909?page=com.atlassian.jira.plug... ] Mario Fusco commented on DROOLS-4909: ------------------------------------- Before 7.20 when the property reactivity analysis couldn't figure out which was the property interested by a given constraint it simply skipped it. This resulted in missing firings, so when this happens now it takes the safest possible choice and just disable the reactivity for the whole pattern. That said I admit that yours is an edge case and Drools should behave in exactly the same way for '$card == card' and 'card == $card'. I'll try to fix this in one of the next minor releases. > Infinite recursion in drools after version change from v7.20 to v7.21 > --------------------------------------------------------------------- > > Key: DROOLS-4909 > URL: https://issues.redhat.com/browse/DROOLS-4909 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 7.21.0.Final, 7.22.0.Final, 7.23.0.Final, 7.25.0.Final, 7.31.0.Final > Environment: Both Mac and Windows > Reporter: Crosson David > Assignee: Mario Fusco > Priority: Major > Attachments: Screen Shot 2019-07-10 at 3.53.10 PM.png, Screen Shot 2019-07-10 at 5.56.32 PM.png, Screen Shot 2019-07-10 at 5.59.28 PM.png, error.png, pojo.png, static.png, static_error.png, toto.drl > > > https://issues.redhat.com/browse/DROOLS-4288 > The problem is not fully solved, I got a forever loop on my KB since 7.21.0.Final, I tried with 7.25.0.Final but without success, and the issue is still here with 7.31.0.Final. Will go back to release 7.20.0.Final > (the only fix I can apply is to add no-loop clause to my rules although it shouldn't be necessary). > I can't share the affected KB, and unfortunately I was unable to reproduce the issue loop on a smaller example > The affected rule looks like : > {{rule "reset metric to max score when no more issues are present" > //no-loop // TODO - no-loop TO BE REMOVED AS IT SHOULDN'T BE NECESSARY > when > Something($id:identity, $origin:origin) > not Issue($id == identity, $origin == origin, category!="metrics") > $scoring: Scoring(name == "performance", $id == identity, $origin == origin) > then > modify($scoring) > { setValue(100.0); } > end}} > ---- > from https://issues.redhat.com/browse/DROOLS-4288 : > When there is a version change in drools-compiler from `7.20.0.Final` to `7.21.0.Final` some rules are looping recursively. > *Code in github:* > [The working version|https://github.com/padippist/DroolsIssueReporting/tree/issue_v_7.20] > [The recursively looping version|https://github.com/padippist/DroolsIssueReporting/tree/issue_v_7.21] > [The change between working and looping version|https://github.com/padippist/DroolsIssueReporting/compare/issue_v...] > *More details* > When I fire a rule whose `then` part modifies a fact that is already checked in the `when` part: > {code:java} > rule "rule 1.1" > when > $sampleDomain: SampleDomain(instanceVariable2 == "Value of instance variable") > then > System.out.println("Rule 1.1 fired"); > modify($sampleDomain){ > setInstanceVariable1(3) > } > end > {code} > it doesn't loop recursively. > But when I call another rule which call a static function from another class: > {code:java} > rule "rule 1.2" > when > $sampleDomain: SampleDomain(CoreUtils.anotherFunction()) > then > System.out.println("Rule 1.2 fired"); > modify($sampleDomain){ > setInstanceVariable1(3) > } > end > {code} > it loops recursively. > The class with static function is > {code:java} > import com.drool_issue.domain.SampleDomain; > public class CoreUtils { > > public static boolean anotherFunction() { > System.out.println("anotherFunction() inside CoreUtils"); > return true; > } > > public static boolean anotherFunction(SampleDomain sampleDomain) { > System.out.println("anotherFunction(SampleDomain sampleDomain) inside CoreUtils"); > return true; > } > } > {code} > My domain file is: > {code:java} > public class SampleDomain { > private int instanceVariable1; > private String instanceVariable2; > private int instanceVariable3; > > > public int getInstanceVariable1() { > return instanceVariable1; > } > public void setInstanceVariable1(int instanceVariable1) { > this.instanceVariable1 = instanceVariable1; > } > public String getInstanceVariable2() { > return instanceVariable2; > } > public void setInstanceVariable2(String instanceVariable2) { > this.instanceVariable2 = instanceVariable2; > } > public int getInstanceVariable3() { > return instanceVariable3; > } > public void setInstanceVariable3(int instanceVariable3) { > this.instanceVariable3 = instanceVariable3; > } > > > } > {code} > This is only caused after version change from `7.20.0.Final` to `7.21.0.Final`. Any guess on what the problem might be? > When I further looked into the problem I saw this too. > When we add two functions into the `SampleDomain` class ie > {code:java} > public boolean anotherFunction() { > return true; > } > > public boolean anotherFunction(SampleDomain sampleDomain) { > return true; > } > {code} > and use this in the rule like: > {code:java} > rule "rule 1.4" > when > $sampleDomain: SampleDomain(anotherFunction()) > then > System.out.println("Rule 1.4 fired"); > modify($sampleDomain){ > setInstanceVariable1(3) > } > end > {code} > and > {code:java} > rule "rule 1.5" > when > $sampleDomain: SampleDomain(anotherFunction($sampleDomain)) > then > System.out.println("Rule 1.5 fired"); > modify($sampleDomain){ > setInstanceVariable3(4) > } > end > {code} > these also loops recursively. > *Code in github:* > [The recursive looping when using non static methods|https://github.com/padippist/DroolsIssueReporting/tree/issue_v_7....] > [The change between working and above version|https://github.com/padippist/DroolsIssueReporting/compare/issue_v...] > Also when any of the static method is made non static then method from the domain class is called even though the static method is specified in the rule. > *Code portions to be noted here are:* > [Rule where static method is called.|https://github.com/padippist/DroolsIssueReporting/blob/bde2804b25...] > [Another rule which also call the static method.|https://github.com/padippist/DroolsIssueReporting/blob/bde2804b25...] > [The static access modifier removed from the functions which where previously static.|https://github.com/padippist/DroolsIssueReporting/compare/issue_v...] > *Code in github:* > [Weird behaviour when removing static modifier for the functions.|https://github.com/padippist/DroolsIssueReporting/tree/issue_v...] > [The change between working and above version|https://github.com/padippist/DroolsIssueReporting/compare/issue_v...] > *All this are caused in versions after `7.20.0.Final`, ie `7.21.0.Final`, `7.22.0.Final` and `7.23.0.Final`* -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12941) Microprofile count metrics does not increase in wildfly17

by alireza alallah (Jira)

[ https://issues.redhat.com/browse/WFLY-12941?page=com.atlassian.jira.plugi... ] alireza alallah updated WFLY-12941: ----------------------------------- Description: 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. was:Count metrics in wildfly17 does not increase > Microprofile count metrics does not increase in wildfly17 > ---------------------------------------------------------- > > Key: WFLY-12941 > URL: https://issues.redhat.com/browse/WFLY-12941 > Project: WildFly > Issue Type: Bug > Reporter: alireza alallah > Assignee: Brian Stansberry > 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

1
0
0 / 0

[JBoss JIRA] (WFLY-12941) Microprofile count metrics does not increase in wildfly17

by alireza alallah (Jira)

[ https://issues.redhat.com/browse/WFLY-12941?page=com.atlassian.jira.plugi... ] alireza alallah updated WFLY-12941: ----------------------------------- Summary: Microprofile count metrics does not increase in wildfly17 (was: ,Count metrics in wildfly17 does not increase) > Microprofile count metrics does not increase in wildfly17 > ---------------------------------------------------------- > > Key: WFLY-12941 > URL: https://issues.redhat.com/browse/WFLY-12941 > Project: WildFly > Issue Type: Bug > Reporter: alireza alallah > Assignee: Brian Stansberry > Priority: Major > > Count metrics in wildfly17 does not increase -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12941) , Count metrics in wildfly17 does not increase

by alireza alallah (Jira)

[ https://issues.redhat.com/browse/WFLY-12941?page=com.atlassian.jira.plugi... ] alireza alallah commented on WFLY-12941: ---------------------------------------- oh sorry, you are right, :) I am taking about eclipse microprofile specifications impl in wildfly17 , @Counted() does not increase during invoke Endpoint and this application metrics always zero in wildfly 17, also we have another jee server such as thorntail for that @counted works but for wildfly does not work. > ,Count metrics in wildfly17 does not increase > --------------------------------------------- > > Key: WFLY-12941 > URL: https://issues.redhat.com/browse/WFLY-12941 > Project: WildFly > Issue Type: Bug > Reporter: alireza alallah > Assignee: Brian Stansberry > Priority: Major > > Count metrics in wildfly17 does not increase -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12910) Upgrade wildfly-transaction-client to 1.1.9.Final

by Ilia Vassilev (Jira)

[ https://issues.redhat.com/browse/WFLY-12910?page=com.atlassian.jira.plugi... ] Ilia Vassilev updated WFLY-12910: --------------------------------- Labels: downstream_dependency (was: ) > Upgrade wildfly-transaction-client to 1.1.9.Final > ------------------------------------------------- > > Key: WFLY-12910 > URL: https://issues.redhat.com/browse/WFLY-12910 > Project: WildFly > Issue Type: Component Upgrade > Components: EJB, Transactions > Affects Versions: 18.0.1.Final > Reporter: Tomasz Adamski > Assignee: Tomasz Adamski > Priority: Major > Labels: downstream_dependency > Fix For: 19.0.0.Beta1 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12946) (7.3.z) Upgrade wildfly-transaction-client to 1.1.9.Final

by Ilia Vassilev (Jira)

[ https://issues.redhat.com/browse/WFLY-12946?page=com.atlassian.jira.plugi... ] Ilia Vassilev reassigned WFLY-12946: ------------------------------------ Assignee: Ilia Vassilev (was: Tomasz Adamski) > (7.3.z) Upgrade wildfly-transaction-client to 1.1.9.Final > --------------------------------------------------------- > > Key: WFLY-12946 > URL: https://issues.redhat.com/browse/WFLY-12946 > Project: WildFly > Issue Type: Component Upgrade > Components: EJB, Transactions > Reporter: Ilia Vassilev > Assignee: Ilia Vassilev > Priority: Major > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12946) (7.3.z) Upgrade wildfly-transaction-client to 1.1.9.Final

by Ilia Vassilev (Jira)

Ilia Vassilev created WFLY-12946: ------------------------------------ Summary: (7.3.z) Upgrade wildfly-transaction-client to 1.1.9.Final Key: WFLY-12946 URL: https://issues.redhat.com/browse/WFLY-12946 Project: WildFly Issue Type: Component Upgrade Components: EJB, Transactions Affects Versions: 18.0.1.Final Reporter: Ilia Vassilev Assignee: Tomasz Adamski Fix For: 19.0.0.Beta1 -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4912) DMN Data type editor - inline add action button.

by Elizabeth Clayton (Jira)

[ https://issues.redhat.com/browse/DROOLS-4912?page=com.atlassian.jira.plug... ] Elizabeth Clayton updated DROOLS-4912: -------------------------------------- Description: Change the behavior and tooltip for the inline add icon-button (+). Currently it converts the type to Structure before adding a row below. Instead, we want it to add another row without converting the type. Acceptance criteria: *Tooltip: "Add row below (Ctrl + B)" Behavior - Clicking the (+) inline add button: * from a type defined as Structure, will add a field row below. * from a Field row (within a Structure), will add another field row below. * from a Simple type, such as "Person(string)", will add another row of the same type below. was: Change the behavior and tooltip for the inline add icon-button (+). Currently it converts the type to Structure before adding a row below. Instead, we want it to add another row without converting the type. Acceptance criteria: *Tooltip: "Add row below (Ctrl + B)" Behavior - Clicking the (+) inline add button: * from a type defined as Structure, will add a field row below. * from a Field row (within a Structure), will add a field row below. * from a Simple type, such as "Person(string)", will add another row of the same type below. > DMN Data type editor - inline add action button. > ------------------------------------------------- > > Key: DROOLS-4912 > URL: https://issues.redhat.com/browse/DROOLS-4912 > Project: Drools > Issue Type: Bug > Components: DMN Editor > Reporter: Elizabeth Clayton > Assignee: Guilherme Gomes > Priority: Minor > Labels: UX, drools-tools > Attachments: Screen Shot 2020-01-08 at 7.06.20 PM.png > > > Change the behavior and tooltip for the inline add icon-button (+). Currently it converts the type to Structure before adding a row below. Instead, we want it to add another row without converting the type. > Acceptance criteria: > *Tooltip: "Add row below (Ctrl + B)" > Behavior - Clicking the (+) inline add button: > * from a type defined as Structure, will add a field row below. > * from a Field row (within a Structure), will add another field row below. > * from a Simple type, such as "Person(string)", will add another row of the same type below. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4912) DMN Data type editor - inline add action button.

by Elizabeth Clayton (Jira)

[ https://issues.redhat.com/browse/DROOLS-4912?page=com.atlassian.jira.plug... ] Elizabeth Clayton updated DROOLS-4912: -------------------------------------- Priority: Minor (was: Major) > DMN Data type editor - inline add action button. > ------------------------------------------------- > > Key: DROOLS-4912 > URL: https://issues.redhat.com/browse/DROOLS-4912 > Project: Drools > Issue Type: Bug > Components: DMN Editor > Reporter: Elizabeth Clayton > Assignee: Guilherme Gomes > Priority: Minor > Labels: UX, drools-tools > Attachments: Screen Shot 2020-01-08 at 7.06.20 PM.png > > > Change the behavior and tooltip for the inline add icon-button (+). Currently it converts the type to Structure before adding a row below. Instead, we want it to add another row without converting the type. > Acceptance criteria: > *Tooltip: "Add row below (Ctrl + B)" > Behavior - Clicking the (+) inline add button: > * from a type defined as Structure, will add a field row below. > * from a Field row (within a Structure), will add a field row below. > * from a Simple type, such as "Person(string)", will add another row of the same type below. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4912) DMN Data type editor - inline add action button.

by Elizabeth Clayton (Jira)

[ https://issues.redhat.com/browse/DROOLS-4912?page=com.atlassian.jira.plug... ] Elizabeth Clayton updated DROOLS-4912: -------------------------------------- Attachment: Screen Shot 2020-01-08 at 7.06.20 PM.png > DMN Data type editor - inline add action button. > ------------------------------------------------- > > Key: DROOLS-4912 > URL: https://issues.redhat.com/browse/DROOLS-4912 > Project: Drools > Issue Type: Bug > Components: DMN Editor > Reporter: Elizabeth Clayton > Assignee: Guilherme Gomes > Priority: Major > Labels: UX, drools-tools > Attachments: Screen Shot 2020-01-08 at 7.06.20 PM.png > > > Change the behavior and tooltip for the inline add icon-button (+). Currently it converts the type to Structure before adding a row below. Instead, we want it to add another row without converting the type. > Acceptance criteria: > *Tooltip: "Add row below (Ctrl + B)" > Behavior - Clicking the (+) inline add button: > * from a type defined as Structure, will add a field row below. > * from a Field row (within a Structure), will add a field row below. > * from a Simple type, such as "Person(string)", will add another row of the same type below. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4913) DMN Data type editor - inline add action button.

by Elizabeth Clayton (Jira)

Elizabeth Clayton created DROOLS-4913: ----------------------------------------- Summary: DMN Data type editor - inline add action button. Key: DROOLS-4913 URL: https://issues.redhat.com/browse/DROOLS-4913 Project: Drools Issue Type: Bug Components: DMN Editor Reporter: Elizabeth Clayton Assignee: Guilherme Gomes Change the behavior and tooltip for the inline add icon-button (+). Currently it converts the type to Structure before adding a row below. Instead, we want it to add another row without converting the type. Acceptance criteria: *Tooltip: "Add row below (Ctrl + B)" Behavior - Clicking the (+) inline add button: * from a type defined as Structure, will add a field row below. * from a Field row (within a Structure), will add a field row below. * from a Simple type, such as "Person(string)", will add another row of the same type below. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4912) DMN Data type editor - inline add action button.

by Elizabeth Clayton (Jira)

Elizabeth Clayton created DROOLS-4912: ----------------------------------------- Summary: DMN Data type editor - inline add action button. Key: DROOLS-4912 URL: https://issues.redhat.com/browse/DROOLS-4912 Project: Drools Issue Type: Bug Components: DMN Editor Reporter: Elizabeth Clayton Assignee: Guilherme Gomes Change the behavior and tooltip for the inline add icon-button (+). Currently it converts the type to Structure before adding a row below. Instead, we want it to add another row without converting the type. Acceptance criteria: *Tooltip: "Add row below (Ctrl + B)" Behavior - Clicking the (+) inline add button: * from a type defined as Structure, will add a field row below. * from a Field row (within a Structure), will add a field row below. * from a Simple type, such as "Person(string)", will add another row of the same type below. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12934) Remove link to google plus on https://wildfly.org/

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFLY-12934?page=com.atlassian.jira.plugi... ] Brian Stansberry resolved WFLY-12934. ------------------------------------- Resolution: Done Fixed; thanks for the report [~jpa_ge]! > Remove link to google plus on https://wildfly.org/ > -------------------------------------------------- > > Key: WFLY-12934 > URL: https://issues.redhat.com/browse/WFLY-12934 > Project: WildFly > Issue Type: Bug > Reporter: Jpa Ge > Assignee: Brian Stansberry > Priority: Minor > Fix For: No Release > > > On the website, https://wildfly.org/, in the "Follow us" menu, there an sub menu for google plus. > But google plus was turned off in december 2018. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12934) Remove link to google plus on https://wildfly.org/

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFLY-12934?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFLY-12934: ------------------------------------ Fix Version/s: No Release > Remove link to google plus on https://wildfly.org/ > -------------------------------------------------- > > Key: WFLY-12934 > URL: https://issues.redhat.com/browse/WFLY-12934 > Project: WildFly > Issue Type: Bug > Reporter: Jpa Ge > Assignee: Brian Stansberry > Priority: Minor > Fix For: No Release > > > On the website, https://wildfly.org/, in the "Follow us" menu, there an sub menu for google plus. > But google plus was turned off in december 2018. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

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

by Matteo Mortari (Jira)

[ https://issues.redhat.com/browse/DROOLS-4899?page=com.atlassian.jira.plug... ] Matteo Mortari updated DROOLS-4899: ----------------------------------- Description: Demonstrate how the developer/user can create a custom FEEL function to access to the DMNRuntime. This in a target application can serve several use cases: * *Introspection*. For instance return information about the environment, like number of models etc. * *Access to Kie API*. For instance to call out to a Stateless Kie Session execution in the same application. (The DMN user is knowledgeable by the spec external invocation shall be side-effect free was: Demonstrate how the developer/user can create a custom FEEL function to access to the DMNRuntime. This in a target application can serve several use cases: * *Introspection*. For instance return information about the environment, like number of models etc. * *Access to Kie API*. For instance to call out to a Stateless Kie Session execution in the same application. (The DMN user is knowledgeable by the spec external invocation shall be side-effect free) > DMN demo extended builtin function for runtime > ---------------------------------------------- > > Key: DROOLS-4899 > URL: https://issues.redhat.com/browse/DROOLS-4899 > Project: Drools > Issue Type: Task > Components: dmn engine > Reporter: Matteo Mortari > Assignee: Matteo Mortari > Priority: Major > > Demonstrate how the developer/user can create a custom FEEL function to access to the DMNRuntime. > This in a target application can serve several use cases: > * *Introspection*. For instance return information about the environment, like number of models etc. > * *Access to Kie API*. For instance to call out to a Stateless Kie Session execution in the same application. (The DMN user is knowledgeable by the spec external invocation shall be side-effect free -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

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

by Matteo Mortari (Jira)

[ https://issues.redhat.com/browse/DROOLS-4899?page=com.atlassian.jira.plug... ] Matteo Mortari commented on DROOLS-4899: ---------------------------------------- [~jpetrlik] done. > DMN demo extended builtin function for runtime > ---------------------------------------------- > > Key: DROOLS-4899 > URL: https://issues.redhat.com/browse/DROOLS-4899 > Project: Drools > Issue Type: Task > Components: dmn engine > Reporter: Matteo Mortari > Assignee: Matteo Mortari > Priority: Major > > Demonstrate how the developer/user can create a custom FEEL function to access to the DMNRuntime. > This in a target application can serve several use cases: > * *Introspection*. For instance return information about the environment, like number of models etc. > * *Access to Kie API*. For instance to call out to a Stateless Kie Session execution in the same application. (The DMN user is knowledgeable by the spec external invocation shall be side-effect free) -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

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

by Matteo Mortari (Jira)

[ https://issues.redhat.com/browse/DROOLS-4899?page=com.atlassian.jira.plug... ] Matteo Mortari updated DROOLS-4899: ----------------------------------- Description: Demonstrate how the developer/user can create a custom FEEL function to access to the DMNRuntime. This in a target application can serve several use cases: * *Introspection*. For instance return information about the environment, like number of models etc. * *Access to Kie API*. For instance to call out to a Stateless Kie Session execution in the same application. (The DMN user is knowledgeable by the spec external invocation shall be side-effect free) > DMN demo extended builtin function for runtime > ---------------------------------------------- > > Key: DROOLS-4899 > URL: https://issues.redhat.com/browse/DROOLS-4899 > Project: Drools > Issue Type: Task > Components: dmn engine > Reporter: Matteo Mortari > Assignee: Matteo Mortari > Priority: Major > > Demonstrate how the developer/user can create a custom FEEL function to access to the DMNRuntime. > This in a target application can serve several use cases: > * *Introspection*. For instance return information about the environment, like number of models etc. > * *Access to Kie API*. For instance to call out to a Stateless Kie Session execution in the same application. (The DMN user is knowledgeable by the spec external invocation shall be side-effect free) -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ELYWEB-87) Release Elytron Web 1.7.0.Final

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/ELYWEB-87?page=com.atlassian.jira.plugin... ] Farah Juma resolved ELYWEB-87. ------------------------------ Resolution: Done > Release Elytron Web 1.7.0.Final > ------------------------------- > > Key: ELYWEB-87 > URL: https://issues.redhat.com/browse/ELYWEB-87 > Project: Elytron Web > Issue Type: Release > Reporter: Farah Juma > Assignee: Farah Juma > Priority: Major > Fix For: 1.7.0.Final > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira January 2020