September 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-7151) EJB injection with indirection via web.xml is ignored

by Wolf-Dieter Fink (JIRA)

Wolf-Dieter Fink created WFLY-7151: -------------------------------------- Summary: EJB injection with indirection via web.xml is ignored Key: WFLY-7151 URL: https://issues.jboss.org/browse/WFLY-7151 Project: WildFly Issue Type: Bug Reporter: Wolf-Dieter Fink Assignee: Jason Greene If a web application contains a Servlet and a REST service (as CDI Bean) with an @EJB(lookup="java:comp/env/xxxx") injection for a indirection via web.xml/jboss-web.xml the CDI Bean will ignore it without any message whereas the Servlet inject the EJB proxy as expected. This approach is used to be able to change/adjust the target EJB by changing the DD and not the application code. Reproducer can be found here: git@github.com:wfink/jboss-eap-quickstarts.git BRANCH: 6.4.x_ejb-multi-server_reproducerEJB-injection2 SubProject: ejb-multi-server (used only a part of it to have a web-app and a ejb-app) see ejb-multi-server/README-reproducerEJB-injection -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7150) EJB injection with indirection via web.xml is ignored

by Wolf-Dieter Fink (JIRA)

Wolf-Dieter Fink created WFLY-7150: -------------------------------------- Summary: EJB injection with indirection via web.xml is ignored Key: WFLY-7150 URL: https://issues.jboss.org/browse/WFLY-7150 Project: WildFly Issue Type: Bug Reporter: Wolf-Dieter Fink Assignee: Jason Greene If a web application contains a Servlet and a REST service (as CDI Bean) with an @EJB(lookup="java:comp/env/xxxx") injection for a indirection via web.xml/jboss-web.xml the CDI Bean will ignore it without any message whereas the Servlet inject the EJB proxy as expected. This approach is used to be able to change/adjust the target EJB by changing the DD and not the application code. Reproducer can be found here: git@github.com:wfink/jboss-eap-quickstarts.git BRANCH: 6.4.x_ejb-multi-server_reproducerEJB-injection2 SubProject: ejb-multi-server (used only a part of it to have a web-app and a ejb-app) see ejb-multi-server/README-reproducerEJB-injection -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2640) Unable to add cached-connection-manager after removing it once

by Ingo Weiss (JIRA)

[ https://issues.jboss.org/browse/WFLY-2640?page=com.atlassian.jira.plugin.... ] Ingo Weiss commented on WFLY-2640: ---------------------------------- I discussed this with Stefano and this is by design. The pull request hides the {{:remove()}} and {{:add()}} operations from the CLI's auto-complete and operation names. > Unable to add cached-connection-manager after removing it once > -------------------------------------------------------------- > > Key: WFLY-2640 > URL: https://issues.jboss.org/browse/WFLY-2640 > Project: WildFly > Issue Type: Bug > Components: JCA > Affects Versions: 8.0.0.Beta1 > Reporter: Masafumi Miura > Assignee: Ingo Weiss > > {{<cached-connection-manager>}} is enabled in jca subsystem by default: > {code:xml} > <subsystem xmlns="urn:jboss:domain:jca:1.1"> > ... > <cached-connection-manager /> > </subsystem> > {code} > However, it is unable to re-enable {{<cached-connection-manager>}} once it is disabled. CLI command fails to add it due to duplicate resource. > {code} > [standalone@localhost:9990 /] /subsystem=jca/cached-connection-manager=cached-connection-manager:remove > { > "outcome" => "success", > "response-headers" => { > "operation-requires-reload" => true, > "process-state" => "reload-required" > } > } > [standalone@localhost:9990 /] :reload > { > "outcome" => "success", > "result" => undefined > } > [standalone@localhost:9990 /] /subsystem=jca/cached-connection-manager=cached-connection-manager:add > { > "outcome" => "failed", > "failure-description" => "JBAS014803: Duplicate resource [ > (\"subsystem\" => \"jca\"), > (\"cached-connection-manager\" => \"cached-connection-manager\") > ]", > "rolled-back" => true > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1809) JBoss CLI patch command doesn't honor custom configuration location

by Alexey Loubyansky (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1809?page=com.atlassian.jira.plugi... ] Alexey Loubyansky moved JBEAP-6085 to WFCORE-1809: -------------------------------------------------- Project: WildFly Core (was: JBoss Enterprise Application Platform) Key: WFCORE-1809 (was: JBEAP-6085) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Patching (was: Patching) Affects Version/s: 3.0.0.Alpha8 (was: 7.0.1.GA) (was: 7.0.2.GA) > JBoss CLI patch command doesn't honor custom configuration location > ------------------------------------------------------------------- > > Key: WFCORE-1809 > URL: https://issues.jboss.org/browse/WFCORE-1809 > Project: WildFly Core > Issue Type: Bug > Components: Patching > Affects Versions: 3.0.0.Alpha8 > Reporter: Alexey Loubyansky > > Suppose we are using custom standalone directory(example: standalone_dev) and if we try to rollback applied CP patch, with "--rest-configuration=true" option, it always restore configuration files from default location(JBOSS_HOME/standalone) not from the "standalone_dev" directory. I can see same result when I try to rollback patch through management console and through JBoss CLI in connected mode. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1809) JBoss CLI patch command doesn't honor custom configuration location

by Alexey Loubyansky (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1809?page=com.atlassian.jira.plugi... ] Alexey Loubyansky reassigned WFCORE-1809: ----------------------------------------- Assignee: Alexey Loubyansky > JBoss CLI patch command doesn't honor custom configuration location > ------------------------------------------------------------------- > > Key: WFCORE-1809 > URL: https://issues.jboss.org/browse/WFCORE-1809 > Project: WildFly Core > Issue Type: Bug > Components: Patching > Affects Versions: 3.0.0.Alpha8 > Reporter: Alexey Loubyansky > Assignee: Alexey Loubyansky > > Suppose we are using custom standalone directory(example: standalone_dev) and if we try to rollback applied CP patch, with "--rest-configuration=true" option, it always restore configuration files from default location(JBOSS_HOME/standalone) not from the "standalone_dev" directory. I can see same result when I try to rollback patch through management console and through JBoss CLI in connected mode. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-623) Checking for anonymous principal by name is insufficient

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/ELY-623?page=com.atlassian.jira.plugin.sy... ] David Lloyd commented on ELY-623: --------------------------------- No, I disagree. It is far more useful to accept a string name. To acquire the anonymous identity, it's best to just query the security domain for it. If we want a method which authorizes an anonymous run-as, then we'd probably just get the anonymous identity and authorize it, or else make a convenience method on SecurityDomain to do that. > Checking for anonymous principal by name is insufficient > -------------------------------------------------------- > > Key: ELY-623 > URL: https://issues.jboss.org/browse/ELY-623 > Project: WildFly Elytron > Issue Type: Bug > Reporter: David Lloyd > Assignee: Jan Kalina > > In {{src/main/java/org/wildfly/security/auth/server/SecurityIdentity.java}}: > {noformat} > + if (AnonymousPrincipal.getInstance().getName().equals(name)) { > + if (! context.authorizeAnonymous(false)) { > + throw log.runAsAuthorizationFailed(getPrincipal(), new AnonymousPrincipal(), null); > + } > + } else { > + if (! (context.importIdentity(this) && context.authorize(name, authorize))) { > + throw log.runAsAuthorizationFailed(getPrincipal(), new NamePrincipal(name), null); > + } > } > {noformat} > Only a type check is sufficient to determine if a principal is anonymous. In this fix, the string name "anonymous" takes on a special meaning for the first time, which should not be the case. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7038) License files issues

by Petr Sakař (JIRA)

[ https://issues.jboss.org/browse/WFLY-7038?page=com.atlassian.jira.plugin.... ] Petr Sakař reopened WFLY-7038: ------------------------------ Assignee: Petr Sakař (was: Paul Gier) Another issues found > License files issues > -------------------- > > Key: WFLY-7038 > URL: https://issues.jboss.org/browse/WFLY-7038 > Project: WildFly > Issue Type: Bug > Components: Build System > Affects Versions: 10.1.0.Final > Reporter: Petr Sakař > Assignee: Petr Sakař > Fix For: 11.0.0.Alpha1 > > > Various problems with licenses were found. > - bsd.txt file contains BSD license template > - some licenses are incorrect -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7149) Unable to remove elytron subsystem with defined properties-realm

by Radim Hatlapatka (JIRA)

Radim Hatlapatka created WFLY-7149: -------------------------------------- Summary: Unable to remove elytron subsystem with defined properties-realm Key: WFLY-7149 URL: https://issues.jboss.org/browse/WFLY-7149 Project: WildFly Issue Type: Bug Components: Security Reporter: Radim Hatlapatka Assignee: Darran Lofthouse Priority: Critical When having elytron subsystem with only defined property-realm and calling remove on the subsystem, it fails due unsatisfied dependencies \[1\]. The subsystem is created from scratch with no dependencies outside of the subsystem => it shouldn't fail to remove. \[1\] {noformat} [standalone@localhost:9990 /] /subsystem=elytron:remove { "outcome" => "failed", "failure-description" => "WFLYCTL0171: Removing services has lead to unsatisfied dependencies: Service elytron.security-properties was depended upon by service org.wildfly.security.security-realm.elytron-security Service elytron.core-service was depended upon by service org.wildfly.security.security-realm.elytron-security", "rolled-back" => true } {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7148) Excessive loopback connections on Windows

by Johan Persson (JIRA)

Johan Persson created WFLY-7148: ----------------------------------- Summary: Excessive loopback connections on Windows Key: WFLY-7148 URL: https://issues.jboss.org/browse/WFLY-7148 Project: WildFly Issue Type: Bug Affects Versions: 8.2.0.Final Reporter: Johan Persson Assignee: Jason Greene Using WildFly 8.2.0 on Windows, an excessive amount of loopback connections are established upon application server start. The amount of connections is roughly equal to io-threads*2 <subsystem xmlns="urn:jboss:domain:io:1.1"> <worker name="default" io-threads="1000"/> <buffer-pool name="default"/> </subsystem> (we are seeing ~2000 connections using io-threads=1000). The same configuration doesn't cause this issue on linux (We see 1000 I/O-threads on both windows and linux, but much fewer connections on linux). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-623) Checking for anonymous principal by name is insufficient

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-623?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse commented on ELY-623: -------------------------------------- +1 something like that, we only actually have a single instance of the AnonymousPrinicpal > Checking for anonymous principal by name is insufficient > -------------------------------------------------------- > > Key: ELY-623 > URL: https://issues.jboss.org/browse/ELY-623 > Project: WildFly Elytron > Issue Type: Bug > Reporter: David Lloyd > Assignee: Jan Kalina > > In {{src/main/java/org/wildfly/security/auth/server/SecurityIdentity.java}}: > {noformat} > + if (AnonymousPrincipal.getInstance().getName().equals(name)) { > + if (! context.authorizeAnonymous(false)) { > + throw log.runAsAuthorizationFailed(getPrincipal(), new AnonymousPrincipal(), null); > + } > + } else { > + if (! (context.importIdentity(this) && context.authorize(name, authorize))) { > + throw log.runAsAuthorizationFailed(getPrincipal(), new NamePrincipal(name), null); > + } > } > {noformat} > Only a type check is sufficient to determine if a principal is anonymous. In this fix, the string name "anonymous" takes on a special meaning for the first time, which should not be the case. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 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 2016