August 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-5582) Unwanted refiring after deserialization of a rule contaning an accumulate with more than one accumulating function

by Martin Weiler (Jira)

Martin Weiler created DROOLS-5582: ------------------------------------- Summary: Unwanted refiring after deserialization of a rule contaning an accumulate with more than one accumulating function Key: DROOLS-5582 URL: https://issues.redhat.com/browse/DROOLS-5582 Project: Drools Issue Type: Bug Reporter: Martin Weiler Assignee: Mario Fusco As demonstrated by this test [https://github.com/kiegroup/drools/blob/master/drools-compiler/src/test/j...] an accumulate rule doesn't refire after deserialization. However if the accumulate contains more than one accumulating function, e.g. the accumulate in that test is rewritten as {code:java} accumulate ( Person ( getName().startsWith(\"M\"), $age : age ); $sum : sum( $age ), $max : max( $age ) {code} it mistakenly fires once again after deserialization. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13772) Upgrade Netty to 4.1.50.Final

by odidev PS (Jira)

odidev PS created WFLY-13772: -------------------------------- Summary: Upgrade Netty to 4.1.50.Final Key: WFLY-13772 URL: https://issues.redhat.com/browse/WFLY-13772 Project: WildFly Issue Type: Component Upgrade Reporter: odidev PS Assignee: Brian Stansberry Upgrade Netty to its latest version 4.1.50.Final which includes both security fixes and AArch64 performance improvements Refer release notes for detail: [https://netty.io/news/2020/05/13/4-1-50-Final.html] -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-1995) AggregateRealm is failing in authentication with token-realm

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/ELY-1995?page=com.atlassian.jira.plugin.... ] Farah Juma updated ELY-1995: ---------------------------- Fix Version/s: 1.10.8.Final 1.13.0.CR5 > AggregateRealm is failing in authentication with token-realm > ------------------------------------------------------------ > > Key: ELY-1995 > URL: https://issues.redhat.com/browse/ELY-1995 > Project: WildFly Elytron > Issue Type: Bug > Reporter: Farah Juma > Assignee: Farah Juma > Priority: Major > Fix For: 1.10.8.Final, 1.13.0.CR5 > > > Authentication is failing when token-realm is set as an authentication-realm in aggregate-realm and ldap-realm is set as authorization realm. > It is found that {{AggregateSecurityRealm#getRealmIdentity}} is attempting to get the realm identity to be used for authentication using the JWT realm and it attempts to get the realm identity to be used for authorization using the LDAP realm. In both cases, the {{BearerTokenEvidence}} is being used to try to obtain the realm identity. The problem with this is that the {{LdapSecurityRealm}} won't be able to obtain the principal from the {{BearerTokenEvidence}} so the {{authorizationIdentity}} will just be the {{RealmIdentity.NON_EXISTENT}} identity, resulting in the "User does not exist" error. > {panel} > 2020-06-11 08:51:06,767 TRACE [org.wildfly.security] (default task-1) Handling MechanismInformationCallback type='HTTP' name='BEARER_TOKEN' host-name='localhost' protocol='http' > 2020-06-11 08:51:06,769 TRACE [org.wildfly.security] (default task-1) Evidence verification: evidence = org.wildfly.security.evidence.BearerTokenEvidence@2587e47f evidencePrincipal = null > 2020-06-11 08:51:06,782 DEBUG [org.wildfly.security] (default task-1) Token is using algorithm [RS256] > 2020-06-11 08:51:06,789 DEBUG [org.wildfly.security] (default task-1) Token is using algorithm [RS256] > 2020-06-11 08:51:06,792 TRACE [org.wildfly.security] (default task-1) BEARER_TOKEN: org.wildfly.security.http.HttpAuthenticationException: ELY05053: Callback handler failed for unknown reason > at org.wildfly.security.mechanism._private.MechanismUtil.handleCallbacks(MechanismUtil.java:161) > ... 41 more > {panel} > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-1975) Update AcmeClientSpi#obtainCertificate so that it obtains the order URL from the response to newOrder

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/ELY-1975?page=com.atlassian.jira.plugin.... ] Farah Juma updated ELY-1975: ---------------------------- Fix Version/s: 1.10.8.Final > Update AcmeClientSpi#obtainCertificate so that it obtains the order URL from the response to newOrder > ----------------------------------------------------------------------------------------------------- > > Key: ELY-1975 > URL: https://issues.redhat.com/browse/ELY-1975 > Project: WildFly Elytron > Issue Type: Task > Reporter: Farah Juma > Assignee: Farah Juma > Priority: Major > Fix For: 1.13.0.CR1, 1.10.8.Final > > > {{AcmeClientSpi#obtainCertificate}} currently determines the order URL that should be used by taking the {{Location}} header from the response to finalizing the order (the ACME protocol specification has an example response that includes this header). This works when obtaining certificates from Let's Encrypt and Boulder. However, it seems that EJBCA does not include the {{Location}} header in the response to finalizing the order. {{AcmeClientSpi#obtainCertificate}} should instead use the Location header from the response to {{newOrder}}. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-1968) Update error message returned by AcmeClientSpi#getLocation

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/ELY-1968?page=com.atlassian.jira.plugin.... ] Farah Juma updated ELY-1968: ---------------------------- Fix Version/s: 1.10.8.Final > Update error message returned by AcmeClientSpi#getLocation > ---------------------------------------------------------- > > Key: ELY-1968 > URL: https://issues.redhat.com/browse/ELY-1968 > Project: WildFly Elytron > Issue Type: Bug > Components: API / SPI > Reporter: Farah Juma > Assignee: Sonia Zaldana > Priority: Minor > Fix For: 1.12.0.Final, 1.10.8.Final > > > The {{AcmeClientSpi#getLocation}} method returns the value of the "Location" header field if non-null. Otherwise, an exception is thrown. Currently, the error message is specific to accounts, i.e., the error message "No account location URL provided by ACME server" is returned. However, the {{AcmeClientSpi#getLocation}} method is actually called to retrieve the "Location" header field in other cases as well, like when obtaining the URL for orders and authorizations. This should be updated so that the exception that is thrown has an appropriate error message depending on the location URL that could not be retrieved (i.e., the error message should reference the "account location URL", the "order location URL", or the "authorization location URL" as appropriate). -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11808) Unable to do jndi lookup when starting batch job from web console

by Cheng Fang (Jira)

[ https://issues.redhat.com/browse/WFLY-11808?page=com.atlassian.jira.plugi... ] Cheng Fang reassigned WFLY-11808: --------------------------------- Assignee: Cheng Fang (was: Michal Petrov) > Unable to do jndi lookup when starting batch job from web console > ----------------------------------------------------------------- > > Key: WFLY-11808 > URL: https://issues.redhat.com/browse/WFLY-11808 > Project: WildFly > Issue Type: Bug > Components: Batch > Affects Versions: 16.0.0.Final > Reporter: Cheng Fang > Assignee: Cheng Fang > Priority: Major > Attachments: Default Task Thread.png, External Management Request Thread.png, Screen Shot 2019-03-04 at 10.38.47 PM.png > > > when starting a batch job from web console, jndi lookup inside the application's batch artifacts failed with NameNotFoundException. When the same job is started by the application, the lookups all go well. Need to check if the naming context is properly propagated when starting job from the web console. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13770) Create jdbc job repository using deployment descriptors

by Cheng Fang (Jira)

[ https://issues.redhat.com/browse/WFLY-13770?page=com.atlassian.jira.plugi... ] Cheng Fang commented on WFLY-13770: ----------------------------------- Looks like this doc section is out of date. It should use the latest schema namespace ({{urn:jboss:domain:batch-jberet:2.0}}), and use {{data-source}} attribute when defining a jdbc job repository: {code:xml} <jboss xmlns="urn:jboss:1.0"> <batch xmlns="urn:jboss:domain:batch-jberet:2.0"> <job-repository> <jdbc data-source="java:jboss/datasources/ExampleDS"/> </job-repository> </batch> </jboss> {code} > Create jdbc job repository using deployment descriptors > ------------------------------------------------------- > > Key: WFLY-13770 > URL: https://issues.redhat.com/browse/WFLY-13770 > Project: WildFly > Issue Type: Enhancement > Components: Batch > Affects Versions: 20.0.1.Final > Reporter: Jurij Bernhardt > Assignee: Cheng Fang > Priority: Major > > The Example for "new Job Repository" ([https://docs.wildfly.org/20/Admin_Guide.html#deployment-descriptors]) doesn't work properly. > {code:xml} > <jboss xmlns="urn:jboss:1.0"> > <batch xmlns="urn:jboss:batch-jberet:1.0"> > <job-repository> > <jdbc jndi-name="java:jboss/datasources/ExampleDS"/> > </job-repository> > </batch> > </jboss> > {code} > Schema batch-jberet_1_0.xsd alllows only in-memory or named job-repositoryType. > You get the validation exception by using the jdbc example. > It would be useful to improve the batch-jberet integration so that the example given above would work. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13770) Create jdbc job repository using deployment descriptors

by Cheng Fang (Jira)

[ https://issues.redhat.com/browse/WFLY-13770?page=com.atlassian.jira.plugi... ] Cheng Fang updated WFLY-13770: ------------------------------ Description: The Example for "new Job Repository" ([https://docs.wildfly.org/20/Admin_Guide.html#deployment-descriptors]) doesn't work properly. {code:xml} <jboss xmlns="urn:jboss:1.0"> <batch xmlns="urn:jboss:batch-jberet:1.0"> <job-repository> <jdbc jndi-name="java:jboss/datasources/ExampleDS"/> </job-repository> </batch> </jboss> {code} Schema batch-jberet_1_0.xsd alllows only in-memory or named job-repositoryType. You get the validation exception by using the jdbc example. It would be useful to improve the batch-jberet integration so that the example given above would work. was: The Example for "new Job Repository" ([https://docs.wildfly.org/20/Admin_Guide.html#deployment-descriptors]) doesn't work properly. <jboss xmlns="urn:jboss:1.0"> <batch xmlns="urn:jboss:batch-jberet:1.0"> <job-repository> <jdbc jndi-name="java:jboss/datasources/ExampleDS"/> </job-repository> </batch> </jboss> Schema batch-jberet_1_0.xsd alllows only in-memory or named job-repositoryType. You get the validation exception by using the jdbc example. It would be useful to improve the batch-jberet integration so that the example given above would work. > Create jdbc job repository using deployment descriptors > ------------------------------------------------------- > > Key: WFLY-13770 > URL: https://issues.redhat.com/browse/WFLY-13770 > Project: WildFly > Issue Type: Enhancement > Components: Batch > Affects Versions: 20.0.1.Final > Reporter: Jurij Bernhardt > Assignee: Cheng Fang > Priority: Major > > The Example for "new Job Repository" ([https://docs.wildfly.org/20/Admin_Guide.html#deployment-descriptors]) doesn't work properly. > {code:xml} > <jboss xmlns="urn:jboss:1.0"> > <batch xmlns="urn:jboss:batch-jberet:1.0"> > <job-repository> > <jdbc jndi-name="java:jboss/datasources/ExampleDS"/> > </job-repository> > </batch> > </jboss> > {code} > Schema batch-jberet_1_0.xsd alllows only in-memory or named job-repositoryType. > You get the validation exception by using the jdbc example. > It would be useful to improve the batch-jberet integration so that the example given above would work. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-2016) Release WildFly Elytron 1.10.8.Final

by Farah Juma (Jira)

Farah Juma created ELY-2016: ------------------------------- Summary: Release WildFly Elytron 1.10.8.Final Key: ELY-2016 URL: https://issues.redhat.com/browse/ELY-2016 Project: WildFly Elytron Issue Type: Release Reporter: Farah Juma Assignee: Farah Juma Fix For: 1.10.8.Final -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2498) Move dependent projects to 5.0

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2498?page=com.atlassian.jira.plugin... ] Bela Ban resolved JGRP-2498. ---------------------------- Resolution: Done > Move dependent projects to 5.0 > ------------------------------ > > Key: JGRP-2498 > URL: https://issues.redhat.com/browse/JGRP-2498 > Project: JGroups > Issue Type: Task > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Major > Fix For: 5.0.2 > > > Move projects that consume JGroups (e.g. in jgroups-extras) to 5.0. The {{master}} branch would use 5.0, and the newly created (old) branch 4.x. > The projects are under [https://github.com/jgroups-extras|http://example.com] -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira August 2020