September 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-12484) Make org.picketlink.trust.jbossws.handler.SMALHandler supports SAAJ1.4

by Jim Ma (Jira)

Jim Ma created WFLY-12484: ----------------------------- Summary: Make org.picketlink.trust.jbossws.handler.SMALHandler supports SAAJ1.4 Key: WFLY-12484 URL: https://issues.jboss.org/browse/WFLY-12484 Project: WildFly Issue Type: Task Components: Web Services Affects Versions: 17.0.1.Final Reporter: Jim Ma Assignee: Jim Ma Fix For: 18.0.0.Final To support SAAJ 1.4, Picketlink SMALHandler needs get DOM Element with CXF's DOMUtils to append/remove element from soap message. This handler now fails -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-189) Operatoris not aware of Secret/ConfigMap updates (WildFlyServerSpec#envFrom) - this could lead to inconsistencies

by Petr Kremensky (Jira)

Petr Kremensky created WFWIP-189: ------------------------------------ Summary: Operatoris not aware of Secret/ConfigMap updates (WildFlyServerSpec#envFrom) - this could lead to inconsistencies Key: WFWIP-189 URL: https://issues.jboss.org/browse/WFWIP-189 Project: WildFly WIP Issue Type: Bug Components: OpenShift Reporter: Petr Kremensky Assignee: Brian Stansberry User is able to share environment variables in a ConfigMap or Secret and pass it to Operator via [WildFlyServerSpec#envFrom|https://github.com/wildfly/wildfly-operator/blo...] field. Problem is, that Operator is not aware of changes in Secret/ConfigMap (only reference change is recognized - add or remove ConfigMap/Secret reference). This could lead to inconsistency of environment between pods in a single project (moreover this could lead also to inconsistency between projects in case that ConfigMap/Secret is shared by them). The reaction on ConfigMap/Secret content should be doable, see https://blog.questionable.services/article/kubernetes-deployments-configm... *reproduce* * create a config map with ("foo1", "bar1") entry * create an operator (size = 1) with a reference to the config map * update the config map - add ("foo2", "bar2") entry * resize the operator *actual* {code} $ oc get pods NAME READY STATUS RESTARTS AGE eap-cd-0 1/1 Running 0 112s eap-cd-1 1/1 Running 0 94s wildfly-operator-55b544c4bb-wts8l 1/1 Running 0 2m1s $ oc rsh pod/eap-cd-0 sh-4.4$ env | grep foo foo1=bar1 $ oc rsh pod/eap-cd-1 sh-4.4$ env | grep foo foo1=bar1 foo2=bar2 {code} *expected* {code} $ oc get pods NAME READY STATUS RESTARTS AGE eap-cd-0 1/1 Running 0 112s eap-cd-1 1/1 Running 0 94s wildfly-operator-55b544c4bb-wts8l 1/1 Running 0 2m1s $ oc rsh pod/eap-cd-0 sh-4.4$ env | grep foo foo1=bar1 foo2=bar2 $ oc rsh pod/eap-cd-1 sh-4.4$ env | grep foo foo1=bar1 foo2=bar2 {code} *Environment:* *operator version:* [467407a|https://github.com/wildfly/wildfly-operator/commit/467407a6c21102...] *openshift version:* {noformat} OpenShift version: 4.1.11 Kubernetes Master Version: v1.13.4+df9cebc {noformat} Out of curiosity, is there is way to rollout the pods manually as {{oc rollout}} was designed for DeploymentConfigs and cannot be used here? -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12433) Upgrade jboss-jaxrs-api_2.1_spec to 2.0.0.Final

by Alessio Soldano (Jira)

[ https://issues.jboss.org/browse/WFLY-12433?page=com.atlassian.jira.plugin... ] Alessio Soldano commented on WFLY-12433: ---------------------------------------- CR2 tag: https://github.com/jboss/jboss-jakarta-jaxrs-api_spec/commits/jboss-jaxrs... > Upgrade jboss-jaxrs-api_2.1_spec to 2.0.0.Final > ----------------------------------------------- > > Key: WFLY-12433 > URL: https://issues.jboss.org/browse/WFLY-12433 > Project: WildFly > Issue Type: Sub-task > Components: REST > Reporter: Alessio Soldano > Assignee: Alessio Soldano > Priority: Major > Fix For: 18.0.0.Final > > > JBoss Jakarta JAX-RS API fork: > https://github.com/jboss/jboss-jakarta-jaxrs-api_spec/ -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12462) Incompatible conflicting binding Exception and EJB naming

by Alexey Usharovski (Jira)

[ https://issues.jboss.org/browse/WFLY-12462?page=com.atlassian.jira.plugin... ] Alexey Usharovski commented on WFLY-12462: ------------------------------------------ [~jaikiran] I use IntelliJ IDEA Ultimate and use maven Wildfly plugin for deployment. The plugin version are in the sample application. Also I run the Wildfly with *--server-config=standalone-full.xml*. And before application deployment I run two Wildfly CLI scripts from here https://github.com/usharik/simplewebapp/tree/lesson-6-ejb/simple-webapp to create MySQL driver module and datasource. I can try to make a video of how it looks like on my side or provide the full configs I have in my Wildfly instance. > Incompatible conflicting binding Exception and EJB naming > --------------------------------------------------------- > > Key: WFLY-12462 > URL: https://issues.jboss.org/browse/WFLY-12462 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld, EJB > Affects Versions: 17.0.1.Final > Environment: MacOS High Sierra > Reporter: Alexey Usharovski > Assignee: Cheng Fang > Priority: Minor > Attachments: server.log.zip, simplewebapp-lesson-6-ejb.zip, war-content.txt.zip > > > Wired exception for very simple EJB with @Remote annotated interface in time of deploy to WildFly 17.0.1.Final > {code:java} > @Stateless > public class UserServiceImpl implements UserServiceRemote { > @Override > public List<UserRepr> getAllUsers() { > return null; > } > } > @Remote > public interface UserServiceRemote { > List<UserRepr> getAllUsers(); > } > {code} > The exception is > {code} > Caused by: java.lang.IllegalArgumentException: WFLYEE0047: Incompatible conflicting binding at java:jboss/exported/simple-webapp/UserServiceImpl!ru.geekbrains.jsf.UserServiceRemote > source: org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor$2@6aba1c4b"}, > "WFLYCTL0412: Required services that are not installed:" => [ "jboss.deployment.unit.\"simple-webapp.war\".beanmanager", "jboss.deployment.unit.\"simple-webapp.war\".WeldStartService" ], > "WFLYCTL0180: Services with missing/unavailable dependencies" => [ "jboss.deployment.unit.\"simple-webapp.war\".batch.artifact.factory is missing [jboss.deployment.unit.\"simple-webapp.war\".beanmanager]", > "jboss.deployment.unit.\"simple-webapp.war\".weld.weldClassIntrospector is missing [jboss.deployment.unit.\"simple-webapp.war\".beanmanager, jboss.deployment.unit.\"simple-webapp.war\".WeldStartService]" ] } > {code} > Notice that problem could be resolved by undeploy and Wildfly server restart. May be something wrong with JNDI content? > I've tried to look through the web console but found nothing interesting. > Full application code on GitHub https://github.com/usharik/simplewebapp/tree/lesson-6-ejb -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12483) Move to jakarta.activation

by Alessio Soldano (Jira)

Alessio Soldano created WFLY-12483: -------------------------------------- Summary: Move to jakarta.activation Key: WFLY-12483 URL: https://issues.jboss.org/browse/WFLY-12483 Project: WildFly Issue Type: Component Upgrade Reporter: Alessio Soldano Assignee: Brian Stansberry We should consider moving from javax.activation to jakarta.activation http://central.maven.org/maven2/jakarta/activation/jakarta.activation-api... -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3309) Code cleanup

by Gabriele Cardosi (Jira)

[ https://issues.jboss.org/browse/DROOLS-3309?page=com.atlassian.jira.plugi... ] Gabriele Cardosi closed DROOLS-3309. ------------------------------------ Resolution: Won't Do > Code cleanup > ------------ > > Key: DROOLS-3309 > URL: https://issues.jboss.org/browse/DROOLS-3309 > Project: Drools > Issue Type: Enhancement > Components: Scenario Simulation and Testing > Reporter: Gabriele Cardosi > Assignee: Gabriele Cardosi > Priority: Minor > > Clean up code > # 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 > # remove injection of ScenarioSimulationDocksHandler from ScenarioSimulationEditorPresenter -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4298) Drools-wb-webapp: prefer locally built artifacts over remote ones

by Gabriele Cardosi (Jira)

[ https://issues.jboss.org/browse/DROOLS-4298?page=com.atlassian.jira.plugi... ] Gabriele Cardosi closed DROOLS-4298. ------------------------------------ Resolution: Won't Do > Drools-wb-webapp: prefer locally built artifacts over remote ones > ----------------------------------------------------------------- > > Key: DROOLS-4298 > URL: https://issues.jboss.org/browse/DROOLS-4298 > Project: Drools > Issue Type: Enhancement > Components: Scenario Simulation and Testing > Reporter: Gabriele Cardosi > Assignee: Gabriele Cardosi > Priority: Major > > Currently drools-wb-webapp tries to download remotes updated snapshots. Setup maven configure to search before for locally built/installed ones -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11604) Non-anonymous principal is not propagated from EJB context to CDI bean

by Diana Vilkolakova (Jira)

[ https://issues.jboss.org/browse/WFLY-11604?page=com.atlassian.jira.plugin... ] Diana Vilkolakova commented on WFLY-11604: ------------------------------------------ {quote}In scenario #1 however the call does not pass to another EJB, instead it passes directly to an injected CDI bean. As this bean is directly injected it is running using the SecurityContext of the CallerWithIdentity bean so it is correct that this is returning 'anonymous' instead of 'non-anonymous'.{quote} [~dlofthouse] [~fjuma] This holds true for legacy, but when Elytron is enabled the scenario #1 is returning non-anonymous principal. The difference is in [this method|https://github.com/wildfly/wildfly/blob/master/weld/subsystem/src/...]. For elytron `elytronDomain.getCurrentSecurityIdentity().getPrincipal();` returns non-anonymous but legacy returns anonymous. > Non-anonymous principal is not propagated from EJB context to CDI bean > ---------------------------------------------------------------------- > > Key: WFLY-11604 > URL: https://issues.jboss.org/browse/WFLY-11604 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld, Security > Affects Versions: 14.0.1.Final, 15.0.1.Final > Reporter: Nikoleta Ziakova > Priority: Critical > > This is a follow-up on WFLY-11587 which only dealt with being able to inject the principal. > However, during testing I have tried a scenario when the caller principal was not anonymous (run-as-principal setting in jboss-ejb3.xml). See the test case in this [commit|https://github.com/nziakova/wildfly/commit/9ae586ad0159e6399f65103...]. > The principal is not propagated from the EJB context. The result is that injected principal in the CDI bean is always anonymous, although {{ctx.getCallerPrincipal()}} in the EJB returns correct principal. -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-255) Boot time only system properties should not modify the runtime only the model

by Pandurang Memane (Jira)

[ https://issues.jboss.org/browse/WFCORE-255?page=com.atlassian.jira.plugin... ] Pandurang Memane updated WFCORE-255: ------------------------------------ Description: The three properties {{jboss.server.base.dir}}, {{jboss.server.config.dir}} and {{jboss.server.log.dir}} are allowed to be overridden for servers. For a domain server, these values need to be allowed to be set as a {{boot-time=true}} system property. These properties should also be allowed to be set as a system-property resource or overridden via {{JAVA_OPTS}} or the {{launch-command}}. The {{add}}, {{write-attribute}} and {{remove}} operations should not modify the runtime, but should modify the model. It's debatable whether the server should be put in a {{restart-required}} state. Currently similar resources do _not_ set the server state to {{restart-required}}. For now we should stick with the same state. {code} [domain@localhost:9999 /] /host=master/system-property=jboss.server.log.dir:add(boot-time=true,value="/var/log") { "outcome" => "failed", "result" => undefined, "failure-description" => "JBAS010839: Operation failed or was rolled back on all servers.", "rolled-back" => true, "server-groups" => {"main-server-group" => {"host" => {"master" => { "server-one" => {"response" => { "outcome" => "failed", "failure-description" => "JBAS015845: System property jboss.server.log.dir cannot be set via the xml configuration file or from a management client; it's value must be known at initial process start so it can only set from the commmand line", "rolled-back" => true }}, "server-two" => {"response" => { "outcome" => "failed", "failure-description" => "JBAS015845: System property jboss.server.log.dir cannot be set via the xml configuration file or from a management client; it's value must be known at initial process start so it can only set from the commmand line", "rolled-back" => true }} }}}} } {code} These properties should also be allowed to be set in the {{/host=\*/server-config=\*/jvm=\*/}} resource on the {{jvm-options}} and likely {{launch-command}} attributes. was: The three properties {{jboss.server.base.dir}}, {{jboss.server.config.dir}} and {{jboss.server.log.dir}} are allowed to be overridden for servers. They cannot be set as a system-property resource, but can be overridden via {{JAVA_OPTS}} or the command line. For a domain server these values need to be allowed to be set as a {{boot-time=true}} system property. The {{add}}, {{write-attribute}} and {{remove}} operations should not modify the runtime, but should modify the model. It's debatable whether the server should be put in a {{restart-required}} state. Currently similar resources do _not_ set the server state to {{restart-required}}. For now we should stick with the same state. {code} [domain@localhost:9999 /] /host=master/system-property=jboss.server.log.dir:add(boot-time=true,value="/var/log") { "outcome" => "failed", "result" => undefined, "failure-description" => "JBAS010839: Operation failed or was rolled back on all servers.", "rolled-back" => true, "server-groups" => {"main-server-group" => {"host" => {"master" => { "server-one" => {"response" => { "outcome" => "failed", "failure-description" => "JBAS015845: System property jboss.server.log.dir cannot be set via the xml configuration file or from a management client; it's value must be known at initial process start so it can only set from the commmand line", "rolled-back" => true }}, "server-two" => {"response" => { "outcome" => "failed", "failure-description" => "JBAS015845: System property jboss.server.log.dir cannot be set via the xml configuration file or from a management client; it's value must be known at initial process start so it can only set from the commmand line", "rolled-back" => true }} }}}} } {code} These properties should also be allowed to be set in the {{/host=\*/server-config=\*/jvm=\*/}} resource on the {{jvm-options}} and likely {{launch-command}} attributes. > Boot time only system properties should not modify the runtime only the model > ----------------------------------------------------------------------------- > > Key: WFCORE-255 > URL: https://issues.jboss.org/browse/WFCORE-255 > Project: WildFly Core > Issue Type: Bug > Components: Management > Reporter: James Perkins > Assignee: James Perkins > Priority: Major > Labels: domain-mode > > The three properties {{jboss.server.base.dir}}, {{jboss.server.config.dir}} and {{jboss.server.log.dir}} are allowed to be overridden for servers. For a domain server, these values need to be allowed to be set as a {{boot-time=true}} system property. > These properties should also be allowed to be set as a system-property resource or overridden via {{JAVA_OPTS}} or the {{launch-command}}. > The {{add}}, {{write-attribute}} and {{remove}} operations should not modify the runtime, but should modify the model. It's debatable whether the server should be put in a {{restart-required}} state. Currently similar resources do _not_ set the server state to {{restart-required}}. For now we should stick with the same state. > {code} > [domain@localhost:9999 /] /host=master/system-property=jboss.server.log.dir:add(boot-time=true,value="/var/log") > { > "outcome" => "failed", > "result" => undefined, > "failure-description" => "JBAS010839: Operation failed or was rolled back on all servers.", > "rolled-back" => true, > "server-groups" => {"main-server-group" => {"host" => {"master" => { > "server-one" => {"response" => { > "outcome" => "failed", > "failure-description" => "JBAS015845: System property jboss.server.log.dir cannot be set via the xml configuration file or from a management client; it's value must be known at initial process start so it can only set from the commmand line", > > "rolled-back" => true > }}, > "server-two" => {"response" => { > "outcome" => "failed", > "failure-description" => "JBAS015845: System property jboss.server.log.dir cannot be set via the xml configuration file or from a management client; it's value must be known at initial process start so it can only set from the commmand line", > "rolled-back" => true > }} > }}}} > } > {code} > These properties should also be allowed to be set in the {{/host=\*/server-config=\*/jvm=\*/}} resource on the {{jvm-options}} and likely {{launch-command}} attributes. -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12482) Layers test not disabling inheritance in transitive dependencies

by Jean Francois Denise (Jira)

[ https://issues.jboss.org/browse/WFLY-12482?page=com.atlassian.jira.plugin... ] Jean Francois Denise reassigned WFLY-12482: ------------------------------------------- Assignee: Jean Francois Denise > Layers test not disabling inheritance in transitive dependencies > ---------------------------------------------------------------- > > Key: WFLY-12482 > URL: https://issues.jboss.org/browse/WFLY-12482 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Reporter: Jean Francois Denise > Assignee: Jean Francois Denise > Priority: Major > > By resolving the transitive dependencies locally, we enable inheritance of packages and configs. -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 8 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 September 2019