[JBoss JIRA] (ELY-300) Absence of key-store-credential NPEs
by Kabir Khan (JIRA)
Kabir Khan created ELY-300:
------------------------------
Summary: Absence of key-store-credential NPEs
Key: ELY-300
URL: https://issues.jboss.org/browse/ELY-300
Project: WildFly Elytron
Issue Type: Bug
Reporter: Kabir Khan
Assignee: Darran Lofthouse
Fix For: 1.1.0.Alpha1
Trying to parse
{code}
<authentication-client xmlns="urn:elytron:1.0">
<key-stores>
<key-store name="test" type="PasswordFile">
<file name="keystore/xml-client-keystore-credential-test.keystore"/>
<!--<key-store-credential key-store-name="test" alias="test-alias"/>-->
</key-store>
</key-stores>
</authentication-client>
{code}
I end up with
{code}
java.lang.NullPointerException
at org.wildfly.security.auth.client.ElytronXmlParser$AbstractKeyStoreFactory.create(ElytronXmlParser.java:1082)
at org.wildfly.security.auth.client.ElytronXmlParser$AbstractKeyStoreFactory.create(ElytronXmlParser.java:1067)
at org.wildfly.security.OneTimeSecurityFactory.create(OneTimeSecurityFactory.java:45)
at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseKeyStoreRefType$115(ElytronXmlParser.java:709)
at org.wildfly.security.auth.client.ElytronXmlParser$$Lambda$4/1929600551.create(Unknown Source)
at org.wildfly.security.auth.client.KeyStoreEntrySecurityFactory.create(KeyStoreEntrySecurityFactory.java:47)
at org.wildfly.security.auth.client.KeyStoreEntrySecurityFactory.create(KeyStoreEntrySecurityFactory.java:30)
at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseAuthenticationClientRuleType$106(ElytronXmlParser.java:425)
at org.wildfly.security.auth.client.ElytronXmlParser$$Lambda$5/1053782781.create(Unknown Source)
at org.wildfly.security.OneTimeSecurityFactory.create(OneTimeSecurityFactory.java:45)
at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseAuthenticationClientRuleType$113(ElytronXmlParser.java:474)
at org.wildfly.security.auth.client.ElytronXmlParser$$Lambda$6/2012232625.create(Unknown Source)
at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseAuthenticationClientRulesType$88(ElytronXmlParser.java:242)
at org.wildfly.security.auth.client.ElytronXmlParser$$Lambda$7/627150481.create(Unknown Source)
at org.wildfly.security.OneTimeSecurityFactory.create(OneTimeSecurityFactory.java:45)
at org.wildfly.security.auth.client.XmlClientKeyStoreCredentialTest.testKeystoreCredential(XmlClientKeyStoreCredentialTest.java:110)
{code}
This appears to be because the passwordFactory is only instantiated when parsing the key-store-credential element
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (WFLY-2387) CDI injection in entity listeners failing
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-2387?page=com.atlassian.jira.plugin.... ]
Scott Marlow updated WFLY-2387:
-------------------------------
Fix Version/s: (was: 10.0.0.Final)
> CDI injection in entity listeners failing
> -----------------------------------------
>
> Key: WFLY-2387
> URL: https://issues.jboss.org/browse/WFLY-2387
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, Class Loading, JPA / Hibernate
> Affects Versions: 8.0.0.Beta1
> Reporter: Emond Papegaaij
> Assignee: Scott Marlow
> Attachments: TEST-org.jboss.as.test.integration.ee.injection.support.jpa.EntityListenerInjectionSupportTestCase.xml
>
>
> When trying to use CDI injection in JPA entity listeners, deployment fails with the following exception:
> {code}
> 16:16:37,448 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 15) MSC000001: Failed to start service jboss.persistenceunit."inject-ear.ear#primary": org.jboss.msc.service.StartException in service jboss.persistenceunit."inject-ear.ear#primary": java.lang.IllegalStateException: JBAS016071: Singleton not set for org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl$AggregatedClassLoader@4eeb95dc. This means that you are trying to access a weld deployment with a Thread Context ClassLoader that is not associated with the deployment.
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:169)
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:117)
> at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_25]
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:463) [wildfly-security-manager-1.0.0.Beta3.jar:1.0.0.Beta3]
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:178)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> Caused by: java.lang.IllegalStateException: JBAS016071: Singleton not set for org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl$AggregatedClassLoader@4eeb95dc. This means that you are trying to access a weld deployment with a Thread Context ClassLoader that is not associated with the deployment.
> at org.jboss.as.weld.services.ModuleGroupSingletonProvider$TCCLSingleton.get(ModuleGroupSingletonProvider.java:75)
> at org.jboss.as.weld.services.ModuleGroupSingletonProvider$TCCLSingleton.get(ModuleGroupSingletonProvider.java:128)
> at org.jboss.weld.Container.instance(Container.java:65)
> at org.jboss.weld.manager.BeanManagerImpl.getBeans(BeanManagerImpl.java:563)
> at org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:90)
> at org.jboss.weld.util.Beans.injectBoundFields(Beans.java:358)
> at org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:369)
> at org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:72)
> at org.jboss.weld.injection.producer.ResourceInjector.inject(ResourceInjector.java:60)
> at org.jboss.weld.injection.producer.DefaultInjector$1.proceed(DefaultInjector.java:66)
> at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48)
> at org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:64)
> at org.jboss.weld.injection.producer.BasicInjectionTarget.inject(BasicInjectionTarget.java:90)
> at org.hibernate.jpa.event.internal.jpa.BeanManagerListenerFactory$BeanMetaData.<init>(BeanManagerListenerFactory.java:82)
> at org.hibernate.jpa.event.internal.jpa.BeanManagerListenerFactory$BeanMetaData.<init>(BeanManagerListenerFactory.java:71)
> at org.hibernate.jpa.event.internal.jpa.BeanManagerListenerFactory.buildListener(BeanManagerListenerFactory.java:57)
> at org.hibernate.jpa.event.internal.jpa.LegacyCallbackProcessor.resolveCallbacks(LegacyCallbackProcessor.java:168)
> at org.hibernate.jpa.event.internal.jpa.LegacyCallbackProcessor.processCallbacksForEntity(LegacyCallbackProcessor.java:71)
> at org.hibernate.jpa.event.spi.JpaIntegrator.integrate(JpaIntegrator.java:150)
> at org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:310)
> at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1837)
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:854)
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:847)
> at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:396)
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:846)
> at org.jboss.as.jpa.hibernate4.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:151)
> ... 8 more
> {code}
> I've created a small showcase of the problem: https://github.com/papegaaij/listener-injection
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (WFLY-5432) Wildfly SOAP webservice causes JVM crash
by Davide Marchetti (JIRA)
[ https://issues.jboss.org/browse/WFLY-5432?page=com.atlassian.jira.plugin.... ]
Davide Marchetti updated WFLY-5432:
-----------------------------------
Priority: Blocker (was: Major)
> Wildfly SOAP webservice causes JVM crash
> ----------------------------------------
>
> Key: WFLY-5432
> URL: https://issues.jboss.org/browse/WFLY-5432
> Project: WildFly
> Issue Type: Bug
> Components: Web Services
> Affects Versions: 9.0.1.Final, 10.0.0.CR2
> Environment: Tested on Mac OSX 10.10.2, jdk 1.8.60, wildfly 9.0.1. Final / 10.cr2
> Also tested on Centos 6.5, jdk 1.7.51, wildfly 9.0.1. Final
> Reporter: Davide Marchetti
> Assignee: Alessio Soldano
> Priority: Blocker
> Labels: crash, jvm, soap, webservice
> Attachments: SOAPTest.war
>
>
> The JVM crashes with either a sigsegv or sigbus error when performing a SOAP load test.
> The error printed is:
> # A fatal error has been detected by the Java Runtime Environment:
> #
> # SIGSEGV (0xb) at pc=0x00007f5da922afb8, pid=75645, tid=140039627204352
> #
> # JRE version: OpenJDK Runtime Environment (7.0_51-b02) (build 1.7.0_51-mockbuild_2014_01_15_01_39-b00)
> # Java VM: OpenJDK 64-Bit Server VM (24.45-b08 mixed mode linux-amd64 compressed oops)
> # Problematic frame:
> # J org.apache.cxf.message.ExchangeImpl.get(Ljava/lang/Class;)Ljava/lang/Object;
> #
> # Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
> #
>
> #
> # If you would like to submit a bug report, please include
> # instructions on how to reproduce the bug and visit:
> # 15:56:03,314 INFO [stdout] (default task-17) Submitted order request received with transId: <XXXXX>, opId: <SCO>, ...
> http://icedtea.classpath.org/bugzilla
> #
> The webservice does nothing, just a System.out.print("xxxxx").
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (WFLY-5432) Wildfly SOAP webservice causes JVM crash
by Davide Marchetti (JIRA)
Davide Marchetti created WFLY-5432:
--------------------------------------
Summary: Wildfly SOAP webservice causes JVM crash
Key: WFLY-5432
URL: https://issues.jboss.org/browse/WFLY-5432
Project: WildFly
Issue Type: Bug
Components: Web Services
Affects Versions: 10.0.0.CR2, 9.0.1.Final
Environment: Tested on Mac OSX 10.10.2, jdk 1.8.60, wildfly 9.0.1. Final / 10.cr2
Also tested on Centos 6.5, jdk 1.7.51, wildfly 9.0.1. Final
Reporter: Davide Marchetti
Assignee: Alessio Soldano
Attachments: SOAPTest.war
The JVM crashes with either a sigsegv or sigbus error when performing a SOAP load test.
The error printed is:
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x00007f5da922afb8, pid=75645, tid=140039627204352
#
# JRE version: OpenJDK Runtime Environment (7.0_51-b02) (build 1.7.0_51-mockbuild_2014_01_15_01_39-b00)
# Java VM: OpenJDK 64-Bit Server VM (24.45-b08 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# J org.apache.cxf.message.ExchangeImpl.get(Ljava/lang/Class;)Ljava/lang/Object;
#
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
#
# If you would like to submit a bug report, please include
# instructions on how to reproduce the bug and visit:
# 15:56:03,314 INFO [stdout] (default task-17) Submitted order request received with transId: <XXXXX>, opId: <SCO>, ...
http://icedtea.classpath.org/bugzilla
#
The webservice does nothing, just a System.out.print("xxxxx").
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (WFLY-3612) Implement missing transformers for new bean validation subsystem
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-3612?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated WFLY-3612:
-----------------------------------
Priority: Critical (was: Blocker)
> Implement missing transformers for new bean validation subsystem
> ----------------------------------------------------------------
>
> Key: WFLY-3612
> URL: https://issues.jboss.org/browse/WFLY-3612
> Project: WildFly
> Issue Type: Bug
> Components: Domain Management, EE
> Reporter: Brian Stansberry
> Assignee: Eduardo Martins
> Priority: Critical
>
> The initial work on WFLY-3551 will be merged without needed transformers, because the transformer support we have won't allow the needed transformation. This JIRA is a reminder to add it once the required work in WFCORE-291 is done.
> From my comment on the PR for the WFLY-3551 work:
> There needs to be a discard of this resource if a legacy slave is involved. The presence of the resource means BV is wanted, and by default the legacy slave will have BV, so if this resource exists, the legacy slave is compatible. The resource just needs to be discarded so the legacy slave doesn't fail when it sees resources/ops for this subsystem it can't understand.
> If this subsystem is omitted in a config with ee, the legacy slave will be out of sync with newer ones running the same profile, because the old ones will have BV and the new ones won't. But
> 1) it's a corner case
> 2) it may not matter anyway in terms of behavior of an app
> 3) the transformer logic we have doesn't allow us to do anything about it anyway.
> Re: that last part, when doing this work double check on skipping that, in case the WFLY-3563 work makes it real easy. Unlikely though.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (WFLY-5179) Some tests are unable to init arquillian protocol with security manager
by Ondrej Kotek (JIRA)
[ https://issues.jboss.org/browse/WFLY-5179?page=com.atlassian.jira.plugin.... ]
Ondrej Kotek edited comment on WFLY-5179 at 9/30/15 9:57 AM:
-------------------------------------------------------------
Fixed test cases avoid using ManagementClient when running in non-RunAsClient mode.
EjbLocalRefInjectionTestCase and EnvEntryInjectionTestCase were split -- no permissions needed.
AuthenticationTestCase -and XTS TransactionalTestCase- have new permissions and comments.
was (Author: okotek):
Fixed test cases avoid using ManagementClient when running in non-RunAsClient mode.
EjbLocalRefInjectionTestCase and EnvEntryInjectionTestCase were split -- no permissions needed.
AuthenticationTestCase and XTS TransactionalTestCase have new permissions and comments.
> Some tests are unable to init arquillian protocol with security manager
> -----------------------------------------------------------------------
>
> Key: WFLY-5179
> URL: https://issues.jboss.org/browse/WFLY-5179
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Reporter: Marek Kopecký
> Assignee: Ondrej Kotek
>
> *Description of problem:*
> Some tests are unable to init arquillian protocol with security manager.
> *Affected tests found so far:*
> * org.jboss.as.test.integration.ee.injection.resource.ejblocalref.EjbLocalRefInjectionTestCase#testEjbLink
> * org.jboss.as.test.integration.ee.injection.resource.ejblocalref.EjbLocalRefInjectionTestCase#testLookup
> * org.jboss.as.test.integration.ee.injection.resource.enventry.EnvEntryInjectionTestCase#testEnvEntryInjectionIntoServlet
> * org.jboss.as.test.integration.ejb.security.AuthenticationTestCase
> * org.jboss.as.test.xts.annotation.client.TransactionalTestCase#testNoTransaction
> * org.jboss.as.test.xts.annotation.client.TransactionalTestCase#testActiveTransaction
> *How reproducible:*
> Always.
> *Steps to Reproduce:*
> # ./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -Dnode0=$MYTESTIP_1 -Dnode1=$MYTESTIP_2 -DfailIfNoTests=false -Dsecurity.manager -Dts.basic -Dts.noSmoke -Dtest=EjbLocalRefInjectionTestCase
> *Actual results:*
> {noformat}
> java.lang.RuntimeException: Could not init arquillian protocol
> at org.xnio.Xnio.doGetInstance(Xnio.java:238)
> at org.xnio.Xnio.getInstance(Xnio.java:193)
> at org.jboss.remoting3.Remoting.createEndpoint(Remoting.java:112)
> at org.jboss.as.controller.client.impl.RemotingModelControllerClient.getOrCreateChannel(RemotingModelControllerClient.java:122)
> at org.jboss.as.controller.client.impl.RemotingModelControllerClient$1.getChannel(RemotingModelControllerClient.java:65)
> at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:147)
> at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:122)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:263)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:168)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:147)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:75)
> at org.jboss.as.arquillian.container.ManagementClient.init(ManagementClient.java:140)
> at org.jboss.as.arquillian.container.ManagementClient.getWebUri(ManagementClient.java:177)
> at org.jboss.as.test.integration.ee.injection.resource.ejblocalref.EjbLocalRefInjectionTestCase.performCall(EjbLocalRefInjectionTestCase.java:62)
> at org.jboss.as.test.integration.ee.injection.resource.ejblocalref.EjbLocalRefInjectionTestCase.testEjbLink(EjbLocalRefInjectionTestCase.java:73)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (JGRP-1966) Specify logger name for LogRecord in JDKLogImpl
by George Zalizko (JIRA)
George Zalizko created JGRP-1966:
------------------------------------
Summary: Specify logger name for LogRecord in JDKLogImpl
Key: JGRP-1966
URL: https://issues.jboss.org/browse/JGRP-1966
Project: JGroups
Issue Type: Enhancement
Affects Versions: 3.6.6
Reporter: George Zalizko
Assignee: Bela Ban
Priority: Minor
I use Spring Boot with logback.
For logging I have pattern:
{code}%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} %C{30}:%L - %msg%n{code}
And in console I see:
{code}
16:19:32.062 [OOB-1,yphis-cluster-web,George-THINKPAD-35404] WARN unknown.jul.logger org.jgroups.logging.JDKLogImpl:49 - JGRP000010: packet from 192.168.50.123:45588 has different version (3.2.8) than ours (3.6.6); packet is discarded{code}
This happens because LogRecord created in org.jgroups.logging.JDKLogImpl doesn't have loggerName and when org.slf4j.bridge.SLF4JBridgeHandler make org.slf4j.Logger from java.util.logging.LogRecord he sets logger name as org.slf4j.bridge.SLF4JBridgeHandler#UNKNOWN_LOGGER_NAME that's "unknown.jul.logger"
Actually I don't know is it done specially or not, but I can't find any comments/solutions for that.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (ELY-298) load-from/uri keystore xsd/parser mismatch
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-298?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse updated ELY-298:
---------------------------------
Fix Version/s: 1.1.0.Alpha2
(was: 1.1.0.Alpha1)
> load-from/uri keystore xsd/parser mismatch
> ------------------------------------------
>
> Key: ELY-298
> URL: https://issues.jboss.org/browse/ELY-298
> Project: WildFly Elytron
> Issue Type: Bug
> Reporter: Kabir Khan
> Assignee: Darran Lofthouse
> Fix For: 1.1.0.Alpha2
>
>
> The xsd has
> {code}
> <xsd:complexType name="key-store-type">
> <xsd:sequence minOccurs="1" maxOccurs="1">
> <!-- Access source type -->
> <xsd:choice minOccurs="1" maxOccurs="1">
> <xsd:element name="file" type="name-type" minOccurs="1" maxOccurs="1"/>
> <xsd:element name="load-from" type="uri-type" minOccurs="1" maxOccurs="1"/>
> <xsd:element name="resource" type="name-type" minOccurs="1" maxOccurs="1"/>
> {code}
> The parser seems to look for 'uri' rather than 'load-from'
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months