January 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-4956) Normarize rule constraints for property reactivity and indexing

by Toshiya Kobayashi (Jira)

[ https://issues.redhat.com/browse/DROOLS-4956?page=com.atlassian.jira.plug... ] Toshiya Kobayashi reassigned DROOLS-4956: ----------------------------------------- Assignee: Toshiya Kobayashi (was: Mario Fusco) > Normarize rule constraints for property reactivity and indexing > --------------------------------------------------------------- > > Key: DROOLS-4956 > URL: https://issues.redhat.com/browse/DROOLS-4956 > Project: Drools > Issue Type: Bug > Components: core engine, executable model > Affects Versions: 7.31.0.Final > Reporter: Toshiya Kobayashi > Assignee: Toshiya Kobayashi > Priority: Major > > Having a constraint like > {code:java} > Person( name == "Toshiya" ) > {code} > is not really the same thing as > {code:java} > Person( "Toshiya" == name ) > {code} > In the second case not only you don't have property reactivity, but also you don't have indexing. This an inconsistent behaviour and hoping to fix it with a "normalization" phase where the second constraint got rewritten like the first before being analyzed by property reactivity and indexing. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4805) WildFly Security Manager does not act for javaagents

by Boris Unckel (Jira)

Boris Unckel created WFCORE-4805: ------------------------------------ Summary: WildFly Security Manager does not act for javaagents Key: WFCORE-4805 URL: https://issues.redhat.com/browse/WFCORE-4805 Project: WildFly Core Issue Type: Bug Components: Security Reporter: Boris Unckel Assignee: Darran Lofthouse The WildFly Core Security Manager cares for modules and deployed artifacts. It offers a JavaEE 7 compliant solution to permissions.xml in META-INF of EARs/WARs. Unfortunately it does not take care of javaagents, specified in https://docs.oracle.com/javase/8/docs/api/java/lang/instrument/package-su... OpenSource: https://inspectit.github.io/inspectit-ocelot/docs/getting-started/quick-s... java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "setContextClassLoader")" in code source "(file:/opt/inspectit/inspectit-ocelot-agent-0.6.jar <no signer certificates>)" of "sun.misc.Launcher$AppClassLoader@18b4aac2") at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:295) at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:192) at java.lang.Thread.setContextClassLoader(Thread.java:1474) at rocks.inspectit.ocelot.bootstrap.AgentManager.startOrReplaceInspectitCore(AgentManager.java:49) at rocks.inspectit.ocelot.agent.AgentMain.startAgent(AgentMain.java:78) at rocks.inspectit.ocelot.agent.AgentMain.lambda$premain$0(AgentMain.java:67) at java.lang.Thread.run(Thread.java:748) The specified JARs need AllPermission Config in the same way as container modules. Other Examples for JavaAgents - closed source: https://docs.appdynamics.com/display/PRO45/Java+Agent https://docs.appdynamics.com/display/PRO45/JBoss+and+Wildfly+Startup+Sett... https://docs.appdynamics.com/display/PRO45/Java+Security+Manager+Configur... -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4802) Upgrade httpcomponents httpclient to 4.5.11 and httpcore to 4.4.13

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFCORE-4802?page=com.atlassian.jira.plug... ] Brian Stansberry updated WFCORE-4802: ------------------------------------- Git Pull Request: https://github.com/wildfly/wildfly-core/pull/4059 (was: https://issues.redhat.com/browse/WFCORE-4802) > Upgrade httpcomponents httpclient to 4.5.11 and httpcore to 4.4.13 > ------------------------------------------------------------------ > > Key: WFCORE-4802 > URL: https://issues.redhat.com/browse/WFCORE-4802 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Management > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Fix For: 11.0.0.Beta8 > > > I have set the component to management as other than use within testsuites these components are used within the git integration for server configuration. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2147) Impossible to use environment variables or system properties in permissions.xml and jboss-permissions.xml

by Boris Unckel (Jira)

[ https://issues.redhat.com/browse/WFCORE-2147?page=com.atlassian.jira.plug... ] Boris Unckel commented on WFCORE-2147: -------------------------------------- Hello [~yersan] thanks a lot for your howto. I have backported it successfully to WildFly Core 4 / WildFly 12, it works. > Impossible to use environment variables or system properties in permissions.xml and jboss-permissions.xml > --------------------------------------------------------------------------------------------------------- > > Key: WFCORE-2147 > URL: https://issues.redhat.com/browse/WFCORE-2147 > Project: WildFly Core > Issue Type: Feature Request > Components: Security > Reporter: Adrian Boangiu > Assignee: Yeray Borges > Priority: Major > Fix For: 11.0.0.Beta7 > > > Without this feature it is impossible to migrate "variable" Java file permissions such as: > {noformat} > permission java.io.FilePermission "${java.io.tmpdir}","read"; > permission java.io.FilePermission "${jboss.home.dir}${/}bin${/}javamelody${/}-","read,write,delete"; > permission java.io.FilePermission "${app.home.dir}${/}log${/}-","read,write,delete"; > {noformat} > that were defined in Java policy file in previous verions of JBoss. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4955) [DMN Designer] Blog post - DMN Elements suggestions for FEEL code completion

by Guilherme Gomes (Jira)

Guilherme Gomes created DROOLS-4955: --------------------------------------- Summary: [DMN Designer] Blog post - DMN Elements suggestions for FEEL code completion Key: DROOLS-4955 URL: https://issues.redhat.com/browse/DROOLS-4955 Project: Drools Issue Type: Task Reporter: Guilherme Gomes Assignee: Guilherme Gomes -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4955) [DMN Designer] Blog post - DMN Elements suggestions for FEEL code completion

by Guilherme Gomes (Jira)

[ https://issues.redhat.com/browse/DROOLS-4955?page=com.atlassian.jira.plug... ] Guilherme Gomes updated DROOLS-4955: ------------------------------------ Description: Create a blog post for https://issues.redhat.com/browse/BAPL-1480 > [DMN Designer] Blog post - DMN Elements suggestions for FEEL code completion > ---------------------------------------------------------------------------- > > Key: DROOLS-4955 > URL: https://issues.redhat.com/browse/DROOLS-4955 > Project: Drools > Issue Type: Task > Reporter: Guilherme Gomes > Assignee: Guilherme Gomes > Priority: Major > > Create a blog post for https://issues.redhat.com/browse/BAPL-1480 -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-1046) Automate Validation links https://github.com/kiali/kiali/issues/2014

by Hayk Hovsepyan (Jira)

[ https://issues.redhat.com/browse/SWSQE-1046?page=com.atlassian.jira.plugi... ] Hayk Hovsepyan commented on SWSQE-1046: --------------------------------------- https://github.com/Kiali-QE/kiali-qe-python/pull/241 > Automate Validation links https://github.com/kiali/kiali/issues/2014 > -------------------------------------------------------------------- > > Key: SWSQE-1046 > URL: https://issues.redhat.com/browse/SWSQE-1046 > Project: Kiali QE > Issue Type: QE Task > Reporter: Hayk Hovsepyan > Assignee: Hayk Hovsepyan > Priority: Major > Labels: automation > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4804) Topology gets loading when the write lock has been acquired on a DC

by Yeray Borges (Jira)

[ https://issues.redhat.com/browse/WFCORE-4804?page=com.atlassian.jira.plug... ] Yeray Borges moved HAL-1643 to WFCORE-4804: ------------------------------------------- Project: WildFly Core (was: HAL) Key: WFCORE-4804 (was: HAL-1643) Workflow: GIT Pull Request workflow (was: GIT Pull Request workflow with automatic PR triggers) Component/s: Management (was: Domain Management) Affects Version/s: 11.0.0.Beta7 (was: 3.2.1.Final) > Topology gets loading when the write lock has been acquired on a DC > ------------------------------------------------------------------- > > Key: WFCORE-4804 > URL: https://issues.redhat.com/browse/WFCORE-4804 > Project: WildFly Core > Issue Type: Enhancement > Components: Management > Affects Versions: 11.0.0.Beta7 > Reporter: Yeray Borges > Assignee: Yeray Borges > Priority: Minor > > Topology information is loaded by using Composite operations. A composite operation could require the write lock on the DC when there is more than one slave in the domain. In this scenario, the DC's write lock is acquired until the overall operation, which is being executed in DC and in all the slaves, finishes. > If there is another operation being executed in the DC that previously has acquired the write lock, e.g servers in the domain are being started or an application is being deployed, the topology won't be able to load. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4803) EJB Client authentication does not work using SASL DIGEST-MD5 and EXTERNAL mechanisms in Legacy security

by Ricardo Martin Camarero (Jira)

[ https://issues.redhat.com/browse/WFCORE-4803?page=com.atlassian.jira.plug... ] Ricardo Martin Camarero moved JBEAP-18530 to WFCORE-4803: --------------------------------------------------------- Project: WildFly Core (was: JBoss Enterprise Application Platform) Key: WFCORE-4803 (was: JBEAP-18530) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Security (was: EJB) (was: Security) Affects Version/s: 11.0.0.Beta7 (was: 7.2.5.GA) QE Test Coverage: (was: +) Fix Version/s: (was: 7.2.8.GA) > EJB Client authentication does not work using SASL DIGEST-MD5 and EXTERNAL mechanisms in Legacy security > -------------------------------------------------------------------------------------------------------- > > Key: WFCORE-4803 > URL: https://issues.redhat.com/browse/WFCORE-4803 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Beta7 > Reporter: Ricardo Martin Camarero > Assignee: Ricardo Martin Camarero > Priority: Major > > The application does not working when use the DIGEST-MD5 mechanism in the legacy security. This this the configuration on standalone.xml: > {code:java} > <subsystem xmlns="urn:jboss:domain:remoting:4.0"> > <http-connector name="http-remoting-connector" connector-ref="https" security-realm="ApplicationRealm"> > <sasl> > <include-mechanisms value="DIGEST-MD5"/> > <qop value="auth"/> > <strength value="medium"/> > <server-auth value="false"/> > <reuse-session value="false"/> > <policy> > <forward-secrecy value="true"/> > <no-active value="false"/> > <no-anonymous value="false"/> > <no-dictionary value="true"/> > <no-plain-text value="false"/> > <pass-credentials value="true"/> > </policy> > </sasl> > </http-connector> > </subsystem> > {code} > Using this configuration I have seen this exception in the application: > {code:java} > 019-12-16 09:08:44,132 TRACE [org.wildfly.security] (default task-1) Handling RealmCallback: selected = [RemotingRealm] > 2019-12-16 09:08:44,132 TRACE [org.wildfly.security] (default task-1) Handling NameCallback: authenticationName = stubejbclient > 2019-12-16 09:08:44,133 TRACE [org.wildfly.security] (default task-1) Principal assigning: [stubejbclient], pre-realm rewritten: [stubejbclient@RemotingRealm], realm name: [DIGEST-MD5], post-realm rewritten: [stubejbclient@RemotingRealm], realm rewritten: [stubejbclient@RemotingRealm] > 2019-12-16 09:08:44,133 TRACE [org.wildfly.security] (default task-1) Handling CredentialCallback: failed to obtain credential > 2019-12-16 09:08:44,133 TRACE [org.wildfly.security] (default task-1) Handling RealmCallback: selected = [RemotingRealm] > 2019-12-16 09:08:44,133 TRACE [org.wildfly.security] (default task-1) Handling NameCallback: authenticationName = stubejbclient > 2019-12-16 09:08:44,133 TRACE [org.wildfly.security] (default task-1) Handling CredentialCallback: failed to obtain credential > 2019-12-16 09:08:44,133 TRACE [org.wildfly.security] (default task-1) Handling RealmCallback: selected = [RemotingRealm] > 2019-12-16 09:08:44,133 TRACE [org.wildfly.security] (default task-1) Handling NameCallback: authenticationName = stubejbclient > 2019-12-16 09:08:44,133 TRACE [org.wildfly.security] (default task-1) Handling PasswordCallback: PasswordCredential may not be supported > 2019-12-16 09:08:44,133 TRACE [org.jboss.remoting.remote.server] (default task-1) Server sending authentication rejected: javax.security.sasl.SaslException: ELY05051: Callback handler does not support credential acquisition [Caused by org.wildfly.security.auth.callback.FastUnsupportedCallbackException: javax.security.auth.callback.PasswordCallback@1cf94092] > at org.wildfly.security.mechanism.digest.PasswordDigestObtainer.getSaltedPasswordFromPasswordCallback(PasswordDigestObtainer.java:295) > at org.wildfly.security.mechanism.digest.PasswordDigestObtainer.handleUserRealmPasswordCallbacks(PasswordDigestObtainer.java:112) > at org.wildfly.security.sasl.digest.AbstractDigestMechanism.handleUserRealmPasswordCallbacks(AbstractDigestMechanism.java:195) > at org.wildfly.security.sasl.digest.DigestSaslServer.validateDigestResponse(DigestSaslServer.java:264) > at org.wildfly.security.sasl.digest.DigestSaslServer.evaluateMessage(DigestSaslServer.java:363) > at org.wildfly.security.sasl.util.AbstractSaslParticipant.evaluateMessage(AbstractSaslParticipant.java:199) > at org.wildfly.security.sasl.digest.DigestSaslServer.evaluateResponse(DigestSaslServer.java:336) > at org.wildfly.security.sasl.util.AuthenticationCompleteCallbackSaslServerFactory$1.evaluateResponse(AuthenticationCompleteCallbackSaslServerFactory.java:58) > at org.wildfly.security.sasl.util.AuthenticationTimeoutSaslServerFactory$DelegatingTimeoutSaslServer.evaluateResponse(AuthenticationTimeoutSaslServerFactory.java:106) > at org.wildfly.security.sasl.util.SecurityIdentitySaslServerFactory$1.evaluateResponse(SecurityIdentitySaslServerFactory.java:59) > at org.xnio.sasl.SaslUtils.evaluateResponse(SaslUtils.java:245) > at org.xnio.sasl.SaslUtils.evaluateResponse(SaslUtils.java:217) > at org.jboss.remoting3.remote.ServerConnectionOpenListener$AuthStepRunnable.run(ServerConnectionOpenListener.java:486) > at org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:991) > at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) > at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985) > at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487) > at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378) > at java.lang.Thread.run(Thread.java:748) > Caused by: org.wildfly.security.auth.callback.FastUnsupportedCallbackException: javax.security.auth.callback.PasswordCallback@1cf94092 > 2019-12-16 09:08:44,133 TRACE [org.wildfly.security] (default task-1) Handling AuthenticationCompleteCallback: fail > 2019-12-16 09:08:44,133 TRACE [org.jboss.remoting.remote.server] (default task-1) No more authentication attempts allowed, closing the connection > {code} > It works to EAP 7.0.x but is not working to EAP 7.2.x. > The same configuration works on JBoss EAP 7.0.z. I'm attaching the EJB client, EJB service and standalone.xm. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12980) Full reload is needed after microprofile-jwt-smallrye subsystem removal

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFLY-12980?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFLY-12980: ----------------------------------------- This should be rejected. Subsystems that require deployment unit processors require a reload. Users should evaluate their configuration in a non-production environment. If there is a high likelihood users would not notice this subsystem in their config and then feel an urgent need to remove it in production, i.e. not as part of a normal maintenance cycle that would bounce their deployments, then we should look into why they would feel that need and either fix whatever that problem is, or if it's inherent in the subsystem, reevaluate having it in the standard configuration. But I'm not aware of any problems like that. Is anyone else? > Full reload is needed after microprofile-jwt-smallrye subsystem removal > ----------------------------------------------------------------------- > > Key: WFLY-12980 > URL: https://issues.redhat.com/browse/WFLY-12980 > Project: WildFly > Issue Type: Bug > Components: MP JWT > Reporter: Jan Kasik > Priority: Major > > When user is removing MP subsystem, full reload is required. This is partly a benefit because it provides a fast fail solution for deployments which requires classes from this subsystem. On the other hand, reload might not be feasible for user under in their current conditions. This is why it has to be reduced as much as possible. > Is there other way to provide fast fail without requiring full reload? -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 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