January 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-2762) Injection of application-provided CDI bean into extension-provided bean fails

by Jozef Hartinger (JIRA)

[ https://issues.jboss.org/browse/WFLY-2762?page=com.atlassian.jira.plugin.... ] Jozef Hartinger commented on WFLY-2762: --------------------------------------- The fix for this issue depends on WFLY-2761. I am therefore waiting for the PR for WFLY-2761 to be merged first so that I can send a PR for this issue afterwards. > Injection of application-provided CDI bean into extension-provided bean fails > ----------------------------------------------------------------------------- > > Key: WFLY-2762 > URL: https://issues.jboss.org/browse/WFLY-2762 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: CDI / Weld > Affects Versions: 8.0.0.CR1 > Reporter: Gunnar Morling > Assignee: Jozef Hartinger > Priority: Blocker > Fix For: 8.0.0.Final > > > When an application provides a CDI bean, injection of this bean into another bean provided by a portable extension (which is attached to this application) fails. > The specific use case is the PE for Hibernate Validator which contains a class {{ValidationInterceptor}} with an injection point of type {{j.v.Validator}}. If the application happens to provide a producer for that type, deployment of the application fails with the following error message: > {quote} > WELD-001408: Unsatisfied dependencies for type Validator with qualifiers @Default > at injection point \[UnbackedAnnotatedField\] @Inject private org.hibernate.validator.internal.cdi.interceptor.ValidationInterceptor.validator > {quote} > A test case can be found [here|https://github.com/gunnarmorling/hibernate-validator/tree/injection-...]. To execute it, pull that branch and run: > {code} > mvn clean install -pl integration -Dit.test=InjectionIssueIT > {code} > The deployment of that Arquillian test fails with the error above. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2762) Injection of application-provided CDI bean into extension-provided bean fails

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-2762?page=com.atlassian.jira.plugin.... ] Jason Greene commented on WFLY-2762: ------------------------------------ Awesome. So whats the next steps on this? > Injection of application-provided CDI bean into extension-provided bean fails > ----------------------------------------------------------------------------- > > Key: WFLY-2762 > URL: https://issues.jboss.org/browse/WFLY-2762 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: CDI / Weld > Affects Versions: 8.0.0.CR1 > Reporter: Gunnar Morling > Assignee: Jozef Hartinger > Priority: Blocker > Fix For: 8.0.0.Final > > > When an application provides a CDI bean, injection of this bean into another bean provided by a portable extension (which is attached to this application) fails. > The specific use case is the PE for Hibernate Validator which contains a class {{ValidationInterceptor}} with an injection point of type {{j.v.Validator}}. If the application happens to provide a producer for that type, deployment of the application fails with the following error message: > {quote} > WELD-001408: Unsatisfied dependencies for type Validator with qualifiers @Default > at injection point \[UnbackedAnnotatedField\] @Inject private org.hibernate.validator.internal.cdi.interceptor.ValidationInterceptor.validator > {quote} > A test case can be found [here|https://github.com/gunnarmorling/hibernate-validator/tree/injection-...]. To execute it, pull that branch and run: > {code} > mvn clean install -pl integration -Dit.test=InjectionIssueIT > {code} > The deployment of that Arquillian test fails with the error above. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2322) Update add-user to REJECT bad passwords

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-2322?page=com.atlassian.jira.plugin.... ] Jason Greene commented on WFLY-2322: ------------------------------------ Do you still plan to do this. Is it still a blocker in your opinion? > Update add-user to REJECT bad passwords > --------------------------------------- > > Key: WFLY-2322 > URL: https://issues.jboss.org/browse/WFLY-2322 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Scripts > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 8.0.0.Final > > > Before we release .Final add-user.sh should be switched back to rejecting bad passwords rather than just warning. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1809) The security subsystem plugins use deprecated Infinispan API

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-1809?page=com.atlassian.jira.plugin.... ] Jason Greene commented on WFLY-1809: ------------------------------------ Paul is this still a blocker? > The security subsystem plugins use deprecated Infinispan API > ------------------------------------------------------------ > > Key: WFLY-1809 > URL: https://issues.jboss.org/browse/WFLY-1809 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Security > Affects Versions: 8.0.0.Alpha3 > Reporter: NadirX > Assignee: Paul Ferraro > Priority: Blocker > Fix For: 8.0.0.Final > > > org.jboss.as.security.plugins.JNDIBasedSecurityManagement uses a deprecated way of configuring an Infinispan cache which must be removed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBMETA-373) [backport JBMETA-371] DefaultPropertyReplacer + PropertyResolver is broken for vault expressions

by Chris Dolphy (JIRA)

[ https://issues.jboss.org/browse/JBMETA-373?page=com.atlassian.jira.plugin... ] Chris Dolphy updated JBMETA-373: -------------------------------- Fix Version/s: (was: 8.0.0.Final) > [backport JBMETA-371] DefaultPropertyReplacer + PropertyResolver is broken for vault expressions > ------------------------------------------------------------------------------------------------ > > Key: JBMETA-373 > URL: https://issues.jboss.org/browse/JBMETA-373 > Project: JBoss Metadata > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: common > Affects Versions: 7.0.4.Final > Reporter: Chris Dolphy > Assignee: Brian Stansberry > > The DefaultPropertyReplacer + PropertyResolver algorithm is broken for vault expressions. It's based on the assumption that the contents of the expression string between "${" and "}" have a fixed format a la the old JBoss AS system properties (e.g. propertyname[: default value]) and then the PropertyResolver tries to resolve "propertyname". > This is incorrect in the case of vault expressions, which do not follow this format. In particular the ":" char appears multiple places in a vault expression and does not serve as a delimiter between "propertyname" and "default value". -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2778) CPU load at 99% with WildFly 8 CR1

by Matthias Richter (JIRA)

[ https://issues.jboss.org/browse/WFLY-2778?page=com.atlassian.jira.plugin.... ] Matthias Richter commented on WFLY-2778: ---------------------------------------- Jason, no problem, meanwhile we switched to an setup with nginx resolving https to http in front of wildfly. We left one machine running in the old setup to support resolving this issue. So if I can help you let me know. > CPU load at 99% with WildFly 8 CR1 > ---------------------------------- > > Key: WFLY-2778 > URL: https://issues.jboss.org/browse/WFLY-2778 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Web (Undertow) > Affects Versions: 8.0.0.CR1 > Environment: $ java -version > java version "1.7.0_45" > Java(TM) SE Runtime Environment (build 1.7.0_45-b18) > Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode) > WildFly 8.0.0.CR1 > XNIO version 3.2.0.Beta4 > Undertow 1.0.0.Beta30 > Reporter: Matthias Richter > Assignee: Stuart Douglas > Priority: Blocker > Attachments: stacktrace-6156.out, stacktrace-6157.out, stacktrace-6158.out, stacktrace-new.out > > > After Undertow included https forwarding features when shipped with Wildfly CR1, we experienced high cpu load on our machines, reproduced on 5 different servers. Up to 3 threads are running wild, sometimes it's just one thread though. On the forum reference there are screenshots from jconsole including stacktraces of the threads. > https://community.jboss.org/message/853569#853569 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2778) CPU load at 99% with WildFly 8 CR1

by Matthias Richter (JIRA)

[ https://issues.jboss.org/browse/WFLY-2778?page=com.atlassian.jira.plugin.... ] Matthias Richter commented on WFLY-2778: ---------------------------------------- piece of cake: {code} wildfly/modules/system/layers/base/org/jboss/xnio/main$ ll total 492 drwxr-xr-x 2 wildfly wildfly 4096 Jan 28 02:36 ./ drwxr-xr-x 5 wildfly wildfly 4096 Jan 28 02:36 ../ -rwxr-xr-x 1 wildfly wildfly 1466 Jan 28 02:36 module.xml* -rwxr-xr-x 1 wildfly wildfly 491417 Jan 28 02:36 xnio-api-3.2.0.Final.jar* {code} > CPU load at 99% with WildFly 8 CR1 > ---------------------------------- > > Key: WFLY-2778 > URL: https://issues.jboss.org/browse/WFLY-2778 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Web (Undertow) > Affects Versions: 8.0.0.CR1 > Environment: $ java -version > java version "1.7.0_45" > Java(TM) SE Runtime Environment (build 1.7.0_45-b18) > Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode) > WildFly 8.0.0.CR1 > XNIO version 3.2.0.Beta4 > Undertow 1.0.0.Beta30 > Reporter: Matthias Richter > Assignee: Stuart Douglas > Priority: Blocker > Attachments: stacktrace-6156.out, stacktrace-6157.out, stacktrace-6158.out, stacktrace-new.out > > > After Undertow included https forwarding features when shipped with Wildfly CR1, we experienced high cpu load on our machines, reproduced on 5 different servers. Up to 3 threads are running wild, sometimes it's just one thread though. On the forum reference there are screenshots from jconsole including stacktraces of the threads. > https://community.jboss.org/message/853569#853569 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBMETA-373) [backport JBMETA-371] DefaultPropertyReplacer + PropertyResolver is broken for vault expressions

by Chris Dolphy (JIRA)

Chris Dolphy created JBMETA-373: ----------------------------------- Summary: [backport JBMETA-371] DefaultPropertyReplacer + PropertyResolver is broken for vault expressions Key: JBMETA-373 URL: https://issues.jboss.org/browse/JBMETA-373 Project: JBoss Metadata Issue Type: Bug Security Level: Public (Everyone can see) Components: common Affects Versions: 7.0.4.Final Reporter: Chris Dolphy Assignee: Brian Stansberry Fix For: 8.0.0.Final The DefaultPropertyReplacer + PropertyResolver algorithm is broken for vault expressions. It's based on the assumption that the contents of the expression string between "${" and "}" have a fixed format a la the old JBoss AS system properties (e.g. propertyname[: default value]) and then the PropertyResolver tries to resolve "propertyname". This is incorrect in the case of vault expressions, which do not follow this format. In particular the ":" char appears multiple places in a vault expression and does not serve as a delimiter between "propertyname" and "default value". -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2778) CPU load at 99% with WildFly 8 CR1

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-2778?page=com.atlassian.jira.plugin.... ] Jason Greene commented on WFLY-2778: ------------------------------------ Thanks for being patient with us. We really would like to see this COMPLETELY resolved before final is released. Unfortunately we have been unable to reproduce whatever incarnation you are seeing. > CPU load at 99% with WildFly 8 CR1 > ---------------------------------- > > Key: WFLY-2778 > URL: https://issues.jboss.org/browse/WFLY-2778 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Web (Undertow) > Affects Versions: 8.0.0.CR1 > Environment: $ java -version > java version "1.7.0_45" > Java(TM) SE Runtime Environment (build 1.7.0_45-b18) > Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode) > WildFly 8.0.0.CR1 > XNIO version 3.2.0.Beta4 > Undertow 1.0.0.Beta30 > Reporter: Matthias Richter > Assignee: Stuart Douglas > Priority: Blocker > Attachments: stacktrace-6156.out, stacktrace-6157.out, stacktrace-6158.out, stacktrace-new.out > > > After Undertow included https forwarding features when shipped with Wildfly CR1, we experienced high cpu load on our machines, reproduced on 5 different servers. Up to 3 threads are running wild, sometimes it's just one thread though. On the forum reference there are screenshots from jconsole including stacktraces of the threads. > https://community.jboss.org/message/853569#853569 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2778) CPU load at 99% with WildFly 8 CR1

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-2778?page=com.atlassian.jira.plugin.... ] Stuart Douglas commented on WFLY-2778: -------------------------------------- Can you confirm the version of XNIO that you are using? (It is in the modules/system/layers/base/org/jboss/xnio/main directory) > CPU load at 99% with WildFly 8 CR1 > ---------------------------------- > > Key: WFLY-2778 > URL: https://issues.jboss.org/browse/WFLY-2778 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Web (Undertow) > Affects Versions: 8.0.0.CR1 > Environment: $ java -version > java version "1.7.0_45" > Java(TM) SE Runtime Environment (build 1.7.0_45-b18) > Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode) > WildFly 8.0.0.CR1 > XNIO version 3.2.0.Beta4 > Undertow 1.0.0.Beta30 > Reporter: Matthias Richter > Assignee: Stuart Douglas > Priority: Blocker > Attachments: stacktrace-6156.out, stacktrace-6157.out, stacktrace-6158.out, stacktrace-new.out > > > After Undertow included https forwarding features when shipped with Wildfly CR1, we experienced high cpu load on our machines, reproduced on 5 different servers. Up to 3 threads are running wild, sometimes it's just one thread though. On the forum reference there are screenshots from jconsole including stacktraces of the threads. > https://community.jboss.org/message/853569#853569 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 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 2014