March 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-4259) Upgrade WildFly Elytron to 1.9.x

by Darran Lofthouse (Jira)

[ https://issues.jboss.org/browse/WFCORE-4259?page=com.atlassian.jira.plugi... ] Darran Lofthouse updated WFCORE-4259: ------------------------------------- Summary: Upgrade WildFly Elytron to 1.9.x (was: Upgrade WildFly Elytron to 1.8.x) > Upgrade WildFly Elytron to 1.9.x > -------------------------------- > > Key: WFCORE-4259 > URL: https://issues.jboss.org/browse/WFCORE-4259 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Fix For: 9.0.0.Beta1 > > -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4301) Upgrade remotingjmx to 3.1.0

by Darran Lofthouse (Jira)

[ https://issues.jboss.org/browse/WFCORE-4301?page=com.atlassian.jira.plugi... ] Darran Lofthouse resolved WFCORE-4301. -------------------------------------- Resolution: Rejected Recent fixes have been included in 3.0.1.Final > Upgrade remotingjmx to 3.1.0 > ---------------------------- > > Key: WFCORE-4301 > URL: https://issues.jboss.org/browse/WFCORE-4301 > Project: WildFly Core > Issue Type: Bug > Reporter: Flavia Rainone > Assignee: Darran Lofthouse > Priority: Major > > Upgrade remoting jmx at wildfly core to next version -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3313) Websocket Auth - Container is not aware of the Principal

by Darran Lofthouse (Jira)

[ https://issues.jboss.org/browse/WFLY-3313?page=com.atlassian.jira.plugin.... ] Darran Lofthouse reassigned WFLY-3313: -------------------------------------- Assignee: (was: Darran Lofthouse) > Websocket Auth - Container is not aware of the Principal > -------------------------------------------------------- > > Key: WFLY-3313 > URL: https://issues.jboss.org/browse/WFLY-3313 > Project: WildFly > Issue Type: Bug > Components: EJB, Security, Web (Undertow), Web Sockets > Affects Versions: 8.1.0.CR1, 10.0.0.Final, 15.0.0.Final > Reporter: Markus D > Priority: Major > Attachments: websocket-different-principals-ejb-vs-socket.png, websocket-endpoint-security.war > > > The Websocket is protected by the web.xml. The session object of the callback object correctly returns the principal. > When an EJB is called the callerPrincipal is always anonymous. > @Resource > private SessionContext ctx; > Principal callerPrincipal = ctx.getCallerPrincipal(); > Running thread here: > https://community.jboss.org/thread/240617 > Shouldn't the principal be propagated to the EJB container when a websocket callback method triggered? -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9702) SSO Integration for Programmatic Authentication

by Darran Lofthouse (Jira)

[ https://issues.jboss.org/browse/WFLY-9702?page=com.atlassian.jira.plugin.... ] Darran Lofthouse reassigned WFLY-9702: -------------------------------------- Assignee: (was: Darran Lofthouse) > SSO Integration for Programmatic Authentication > ----------------------------------------------- > > Key: WFLY-9702 > URL: https://issues.jboss.org/browse/WFLY-9702 > Project: WildFly > Issue Type: Feature Request > Components: Clustering, Security, Web (Undertow) > Reporter: Darran Lofthouse > Priority: Critical > > At the moment the SSO integration only fully covers authentication mechanisms as they can be wrapped, we need to revisit for programmatic authentication. > In this scenario we don't have either a wrapped mechanism or a CallbackHandler. > Couple of options: > * Can we get away with pushing in some form of IdentityCache factory the mechs can obtain from the request? This may miss the additional notifications the SSO impl depends on. > * Can we also better support listening for the notifications without the need for wrappers? This could cover both mechs and programmatic authentication? > * Instead do we make the programmatic authenticator pluggable, i.e. push in an SSO aware impl, it can choose how to handle it's own caching and also doesn't need the notifications as it is in control of that stage of the process. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4357) Support new MSC Service API for deployment dependency

by Jeff Mesnil (Jira)

[ https://issues.jboss.org/browse/WFCORE-4357?page=com.atlassian.jira.plugi... ] Jeff Mesnil commented on WFCORE-4357: ------------------------------------- [~ropalka][~jstourac] I've renamed the issue and move it to WFCORE as the change would have to be done in the codebase. > Support new MSC Service API for deployment dependency > ----------------------------------------------------- > > Key: WFCORE-4357 > URL: https://issues.jboss.org/browse/WFCORE-4357 > Project: WildFly Core > Issue Type: Bug > Components: Management > Reporter: Jan Stourac > Assignee: Jeff Mesnil > Priority: Major > > When org.jboss.as.server.deployment.DeploymentPhaseContextImpl#addDeploymentDependency is used, it is expecting the service to be old-API org.jboss.msc.service.Service and use its getValue() method. > This needs to be fixed so that using new MSC Service API works too. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3715) Zipkiemodule nullpointerexception

by Łukasz Szmolke (Jira)

[ https://issues.jboss.org/browse/DROOLS-3715?page=com.atlassian.jira.plugi... ] Łukasz Szmolke commented on DROOLS-3715: ---------------------------------------- Sory, i can't share project code. But it's common multi maven module issue. Each nested maven project with multiple kmodule.xml should not working. > Zipkiemodule nullpointerexception > --------------------------------- > > Key: DROOLS-3715 > URL: https://issues.jboss.org/browse/DROOLS-3715 > Project: Drools > Issue Type: Bug > Affects Versions: 7.16.0.Final, 7.17.0.Final > Reporter: Łukasz Szmolke > Assignee: Tibor Zimányi > Priority: Major > > o During ZipKieModule loading in “org.drools.compiler.kie.builder.impl.ZipKieModule:142” nullpointerexception is thrown: > > urlPath = urlPath.substring( urlPath.lastIndexOf( '!' ) + 1 ); > ArrayList<ZipEntry> entries = new ArrayList<>(); > // read jar file from uber-jar > InputStream in = this.getClass().getResourceAsStream(urlPath); // nullpointerexception > > For example full UrlPath on windows to internal .jar is: > C:\Users\xbbnv0c\IdeaProjects\ais-data-exchange\data-exchange-app\target\data-exchange-app-1.0.1-SNAPSHOT.jar!\BOOT-INF\lib\data-exchange-brms-1.0.1-SNAPSHOT.jar > So the result of this first line will be: > \BOOT-INF\lib\data-exchange-brms-1.0.1-SNAPSHOT.jar > It will be perfect, but during accessing internal resource file separator should be “/” not “\”. So InputStream in = null. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4357) Support new MSC Service API for deployment dependency

by Jeff Mesnil (Jira)

[ https://issues.jboss.org/browse/WFCORE-4357?page=com.atlassian.jira.plugi... ] Jeff Mesnil moved WFLY-11810 to WFCORE-4357: -------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-4357 (was: WFLY-11810) Component/s: Management (was: MSC) Affects Version/s: (was: 16.0.0.Final) > Support new MSC Service API for deployment dependency > ----------------------------------------------------- > > Key: WFCORE-4357 > URL: https://issues.jboss.org/browse/WFCORE-4357 > Project: WildFly Core > Issue Type: Bug > Components: Management > Reporter: Jan Stourac > Assignee: Jeff Mesnil > Priority: Major > > When org.jboss.as.server.deployment.DeploymentPhaseContextImpl#addDeploymentDependency is used, it is expecting the service to be old-API org.jboss.msc.service.Service and use its getValue() method. > This needs to be fixed so that using new MSC Service API works too. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11810) Support new MSC Service API for deployment dependency

by Jeff Mesnil (Jira)

[ https://issues.jboss.org/browse/WFLY-11810?page=com.atlassian.jira.plugin... ] Jeff Mesnil updated WFLY-11810: ------------------------------- Description: When org.jboss.as.server.deployment.DeploymentPhaseContextImpl#addDeploymentDependency is used, it is expecting the service to be old-API org.jboss.msc.service.Service and use its getValue() method. This needs to be fixed so that using new MSC Service API works too. was: I have no necessary insight regarding to the code but based on the discussion in WFLY-11603 ([comment|https://issues.jboss.org/browse/WFLY-11603?focusedCommentId=13687...]) it is not possible to use 'org.jboss.msc.Service' API to properly install service and deprecated 'org.jboss.msc.service.Service' API has to be used instead. It is necessary to fix the behavior of the new API so when we switch to it, we don't introduce the issue described and fixed in WFLY-11603 again. As it was an intermittent NPE, there is a risk that during the simple switch from deprecated API the introduced issue is not caught right-away but after some time... > Support new MSC Service API for deployment dependency > ----------------------------------------------------- > > Key: WFLY-11810 > URL: https://issues.jboss.org/browse/WFLY-11810 > Project: WildFly > Issue Type: Bug > Components: MSC > Reporter: Jan Stourac > Assignee: Jeff Mesnil > Priority: Major > > When org.jboss.as.server.deployment.DeploymentPhaseContextImpl#addDeploymentDependency is used, it is expecting the service to be old-API org.jboss.msc.service.Service and use its getValue() method. > This needs to be fixed so that using new MSC Service API works too. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11810) Support new MSC Service API for deployment dependency

by Jeff Mesnil (Jira)

[ https://issues.jboss.org/browse/WFLY-11810?page=com.atlassian.jira.plugin... ] Jeff Mesnil updated WFLY-11810: ------------------------------- Summary: Support new MSC Service API for deployment dependency (was: Fix 'org.jboss.msc.Service' API to enable proper service installation) > Support new MSC Service API for deployment dependency > ----------------------------------------------------- > > Key: WFLY-11810 > URL: https://issues.jboss.org/browse/WFLY-11810 > Project: WildFly > Issue Type: Bug > Components: MSC > Affects Versions: 16.0.0.Final > Reporter: Jan Stourac > Assignee: Jeff Mesnil > Priority: Major > > I have no necessary insight regarding to the code but based on the discussion in WFLY-11603 ([comment|https://issues.jboss.org/browse/WFLY-11603?focusedCommentId=13687...]) it is not possible to use 'org.jboss.msc.Service' API to properly install service and deprecated 'org.jboss.msc.service.Service' API has to be used instead. > It is necessary to fix the behavior of the new API so when we switch to it, we don't introduce the issue described and fixed in WFLY-11603 again. As it was an intermittent NPE, there is a risk that during the simple switch from deprecated API the introduced issue is not caught right-away but after some time... -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11810) Fix 'org.jboss.msc.Service' API to enable proper service installation

by Richard Opalka (Jira)

[ https://issues.jboss.org/browse/WFLY-11810?page=com.atlassian.jira.plugin... ] Richard Opalka commented on WFLY-11810: --------------------------------------- This is not MSC API problem [~jstourac]. org.jboss.msc.service.Service.getValue() method is deprecated: https://github.com/wildfly/wildfly/pull/12012/files#diff-6de66bee9c455ef4... If you need to use this method you either: a) didn't migrate your MSC services properly b) or there are still some internal WildFly APIs that are still using legacy MSC API and thus your code cannot be migrated to new MSC APIs yet Migration of WildFly code base to use new MSC API is a long process and it will take some time to get there. > Fix 'org.jboss.msc.Service' API to enable proper service installation > --------------------------------------------------------------------- > > Key: WFLY-11810 > URL: https://issues.jboss.org/browse/WFLY-11810 > Project: WildFly > Issue Type: Bug > Components: MSC > Affects Versions: 16.0.0.Final > Reporter: Jan Stourac > Assignee: Jeff Mesnil > Priority: Major > > I have no necessary insight regarding to the code but based on the discussion in WFLY-11603 ([comment|https://issues.jboss.org/browse/WFLY-11603?focusedCommentId=13687...]) it is not possible to use 'org.jboss.msc.Service' API to properly install service and deprecated 'org.jboss.msc.service.Service' API has to be used instead. > It is necessary to fix the behavior of the new API so when we switch to it, we don't introduce the issue described and fixed in WFLY-11603 again. As it was an intermittent NPE, there is a risk that during the simple switch from deprecated API the introduced issue is not caught right-away but after some time... -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 10 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira March 2019