November 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-1128) Improve the subsystem test schema test coverage

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1128?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1128: ------------------------------------- Fix Version/s: 2.0.3.Final (was: 2.0.2.Final) > Improve the subsystem test schema test coverage > ----------------------------------------------- > > Key: WFCORE-1128 > URL: https://issues.jboss.org/browse/WFCORE-1128 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 2.0.1.Final > Reporter: Kabir Khan > Assignee: Kabir Khan > Fix For: 2.0.3.Final > > > Currently the way to enable the AbstractSubsystemBaseTest testSchema() and testSchemaOfSubsystemTemplates() tests is to override getSubsystemXsdPath() and getSubsystemTemplatePaths(). > Rather than making it explicit to turn on, it should be explicit to turn off. > Also the current way of doing this uses Assume.assumeTrue() to check if a test has provided a schema file, which provides a lot of ignored test noise in the test output. If the xsd should not be tested, methods should instead override testSchema() or testSchemaOfSubsystemTemplates() and provide an empty implementation with a comment saying why it is not important. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1036) Upgrade to JBoss Remoting 4.0.15.Final

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1036?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1036: ------------------------------------- Fix Version/s: 2.0.3.Final (was: 2.0.2.Final) > Upgrade to JBoss Remoting 4.0.15.Final > -------------------------------------- > > Key: WFCORE-1036 > URL: https://issues.jboss.org/browse/WFCORE-1036 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Remoting > Reporter: Darran Lofthouse > Assignee: David Lloyd > Fix For: 2.0.3.Final > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-889) Kerberos authentication for Management CLI should fallback when server principal is set incorrectly

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-889?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-889: ------------------------------------ Fix Version/s: 2.0.3.Final (was: 2.0.2.Final) > Kerberos authentication for Management CLI should fallback when server principal is set incorrectly > --------------------------------------------------------------------------------------------------- > > Key: WFCORE-889 > URL: https://issues.jboss.org/browse/WFCORE-889 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Fix For: 2.0.3.Final, 3.0.0.Alpha1 > > > In case when kerberos authentication is configured in security realm but principal attribute in keytab element is set incorrectly (e.g. remote/wrong_localhost(a)JBOSS.ORG, remote/localhost(a)WRONG_JBOSS.ORG or wrong_remote/localhost(a)JBOSS.ORG instead of remote/localhost(a)JBOSS.ORG) then authentication does not fallback into another authentication mechanism for user with valid kerberos ticket. In case when user does not have kerberos ticket then fallback is taken into account correctly. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1142) Remoting Subsystem RemoteOutboundConnectionService is caching ConnectionURI causing issues when DNS changes

by Brian Stansberry (JIRA)

Brian Stansberry created WFCORE-1142: ---------------------------------------- Summary: Remoting Subsystem RemoteOutboundConnectionService is caching ConnectionURI causing issues when DNS changes Key: WFCORE-1142 URL: https://issues.jboss.org/browse/WFCORE-1142 Project: WildFly Core Issue Type: Bug Components: Remoting Reporter: Brad Maxwell Assignee: David Lloyd Description of problem: EJB CLient was configured with DNS FQDN to configure access to a remote EJB. If run a simple test adding an entry in /etc/hosts file pointing that FQDN to localhost for tests everything works. However, after finish the tests and remove the entry, the client still connects to localhost instead of resolve the new IP address. Even adding networkaddress.cache.ttl=30 inside security settings didn't work too. How reproducible: Everytime you use DNS names to connect to a remote EJB. Steps to Reproduce: 1. Configure a simple client that connects to a remote EJB using dns name 2. add an entry in /etc/hosts mapping the dns name to localhost 3. run the client code 4. remove the entry in /etc/hosts 5. run the client code again Actual results: EJB remote is still reached from localhost Expected results: After changing DNS record EJB will be reached in this new address -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1142) Remoting Subsystem RemoteOutboundConnectionService is caching ConnectionURI causing issues when DNS changes

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1142?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1142: ------------------------------------- Git Pull Request: (was: https://github.com/wildfly/wildfly-core/pull/1229) > Remoting Subsystem RemoteOutboundConnectionService is caching ConnectionURI causing issues when DNS changes > ----------------------------------------------------------------------------------------------------------- > > Key: WFCORE-1142 > URL: https://issues.jboss.org/browse/WFCORE-1142 > Project: WildFly Core > Issue Type: Bug > Components: Remoting > Reporter: Brad Maxwell > Assignee: David Lloyd > > Description of problem: > EJB CLient was configured with DNS FQDN to configure access to a remote EJB. If run a simple test adding an entry in /etc/hosts file pointing that FQDN to localhost for tests everything works. However, after finish the tests and remove the entry, the client still connects to localhost instead of resolve the new IP address. Even adding networkaddress.cache.ttl=30 inside security settings didn't work too. > How reproducible: > Everytime you use DNS names to connect to a remote EJB. > Steps to Reproduce: > 1. Configure a simple client that connects to a remote EJB using dns name > 2. add an entry in /etc/hosts mapping the dns name to localhost > 3. run the client code > 4. remove the entry in /etc/hosts > 5. run the client code again > Actual results: > EJB remote is still reached from localhost > Expected results: > After changing DNS record EJB will be reached in this new address -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1133) JDK 1.8 on Mac causes javax.script.ScriptEngineFactory: Provider apple.applescript.AppleScriptEngineFactory not found

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1133?page=com.atlassian.jira.plugi... ] Brian Stansberry reassigned WFCORE-1133: ---------------------------------------- Fix Version/s: 2.0.2.Final Assignee: Jay SenSharma (was: Stuart Douglas) Resolution: Done > JDK 1.8 on Mac causes javax.script.ScriptEngineFactory: Provider apple.applescript.AppleScriptEngineFactory not found > --------------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-1133 > URL: https://issues.jboss.org/browse/WFCORE-1133 > Project: WildFly Core > Issue Type: Bug > Affects Versions: 2.0.1.Final > Environment: Macbook > JDK 1.8 > Reporter: Jay SenSharma > Assignee: Jay SenSharma > Fix For: 2.0.2.Final > > Attachments: WildFlyServerSideJavaScript.war > > > - When we try deploying any simple ServerSide java script based application on WildFly 10 we see the following Error while deploying the application: > {code:java} > 22:50:49,050 ERROR [stderr] (ServerService Thread Pool -- 62) ScriptEngineManager providers.next(): javax.script.ScriptEngineFactory: Provider apple.applescript.AppleScriptEngineFactory not found > {code} > try deploying the attached application on WildFly 10 and notice the console output. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-127) Module naming does does not support slots

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-127?page=com.atlassian.jira.plugin... ] James Perkins reassigned LOGMGR-127: ------------------------------------ Fix Version/s: 1.5.6.Final 2.0.4.Final 2.1.0.Beta1 Assignee: James Livingston Resolution: Done > Module naming does does not support slots > ----------------------------------------- > > Key: LOGMGR-127 > URL: https://issues.jboss.org/browse/LOGMGR-127 > Project: JBoss Log Manager > Issue Type: Bug > Reporter: James Livingston > Assignee: James Livingston > Fix For: 1.5.6.Final, 2.0.4.Final, 2.1.0.Beta1 > > > AbstractPropertyConfiguration$ModuleFinder uses ModuleIdentifier.create() rather than fromString(), which means it does not support specifying the slot via "module:slot" and can only use the main slot. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (HIBERNATE-93) Missing referencedColumnName attribute in @JoinColumn annotation should log error

by Steve Ebersole (JIRA)

[ https://issues.jboss.org/browse/HIBERNATE-93?page=com.atlassian.jira.plug... ] Steve Ebersole commented on HIBERNATE-93: ----------------------------------------- Wrong Jira :) > Missing referencedColumnName attribute in @JoinColumn annotation should log error > --------------------------------------------------------------------------------- > > Key: HIBERNATE-93 > URL: https://issues.jboss.org/browse/HIBERNATE-93 > Project: Hibernate Integration > Issue Type: Feature Request > Environment: Hibernate 3.2.4 SP1 > Reporter: James Kelly > Assignee: Steve Ebersole > > This is specifically when a @JoinColumn is part of a @JoinColumns annotation. The spec wording is: > "When the JoinColumns annotation is used, both the name and the referencedColumnName elements must be specified in each such JoinColumn annotation." > Hibernate accepts JoinColumn annotations with the missing referencedColumnName even though this causes unpredictable behavior. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1056) InstanceAlreadyExistsException in logs while starting embed-server after failure

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1056?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1056: ------------------------------------- Git Pull Request: https://github.com/wildfly/wildfly-core/pull/1256, https://github.com/wildfly/wildfly-core/pull/1254 (was: https://github.com/wildfly/wildfly-core/pull/1254) > InstanceAlreadyExistsException in logs while starting embed-server after failure > -------------------------------------------------------------------------------- > > Key: WFCORE-1056 > URL: https://issues.jboss.org/browse/WFCORE-1056 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Affects Versions: 2.0.0.CR6 > Reporter: Petr Kremensky > Assignee: Ken Wills > Fix For: 2.0.2.Final > > > IAEE can be seen in the logs of embed server on the second startup if the first one fails. > \\ > \\ > Starting the embed server with --emty-config using default configuration fails as expected. > {noformat} > [disconnected /] embed-server --std-out=echo --empty-config > 10:12:35,251 INFO [org.jboss.modules] (AeshProcess: 1) JBoss Modules version 1.4.4.Final > 10:12:35,323 INFO [org.jboss.msc] (AeshProcess: 1) JBoss MSC version 1.2.6.Final > 10:12:35,384 INFO [org.jboss.as] (MSC service thread 1-6) WFLYSRV0049: WildFly Core 2.0.0.CR7-SNAPSHOT (WildFly Core 2.0.0.CR7-SNAPSHOT) starting > 10:12:35,454 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service jboss.as.server-controller: org.jboss.msc.service.StartException in service jboss.as.server-controller: Failed to start service > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.lang.IllegalStateException: WFLYCTL0389: Could not create an empty configuration at file /home/pkremens/devel/wildfly-core/dist/target/wildfly-core-2.0.0.CR7-SNAPSHOT/standalone/configuration/standalone.xml as there is an existing non-empty configuration there > at org.jboss.as.controller.persistence.ConfigurationFile.getBootFile(ConfigurationFile.java:242) > at org.jboss.as.controller.persistence.BackupXmlConfigurationPersister.<init>(BackupXmlConfigurationPersister.java:70) > at org.jboss.as.server.Bootstrap$Configuration$1.createConfigurationPersister(Bootstrap.java:192) > at org.jboss.as.server.ServerService.start(ServerService.java:249) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > ... 3 more > Cannot start embedded server: WFLYEMB0022: Cannot invoke 'start' on standalone server: WFLYSRV0141: Cannot start server: Operation failed: Failed to start service: WFLYCTL0389: Could not create an empty configuration at file /home/pkremens/devel/wildfly-core/dist/target/wildfly-core-2.0.0.CR7-SNAPSHOT/standalone/configuration/standalone.xml as there is an existing non-empty configuration there > {noformat} > InstanceAlreadyExistsException can be seen in the logs during the boot of the embed server now. > {noformat} > [disconnected /] embed-server --std-out=echo > 10:12:40,211 INFO [org.jboss.modules] (AeshProcess: 2) JBoss Modules version 1.4.4.Final > 10:12:40,217 ERROR [org.jboss.msc] (AeshProcess: 2) MSC000010: Failed to register MBean with MBeanServer: javax.management.InstanceAlreadyExistsException: jboss.msc:type=container,name=jboss-as > at com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:437) > at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerWithRepository(DefaultMBeanServerInterceptor.java:1898) > at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:966) > at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:900) > at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:324) > at com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:522) > at org.jboss.msc.service.ServiceContainerImpl.<init>(ServiceContainerImpl.java:372) > at org.jboss.msc.service.ServiceContainer$Factory.create(ServiceContainer.java:258) > at org.jboss.as.server.BootstrapImpl$ShutdownHook.register(BootstrapImpl.java:208) > at org.jboss.as.server.BootstrapImpl$ShutdownHook.access$100(BootstrapImpl.java:198) > at org.jboss.as.server.BootstrapImpl.<init>(BootstrapImpl.java:62) > at org.jboss.as.server.Bootstrap$Factory.newInstance(Bootstrap.java:256) > at org.wildfly.core.embedded.EmbeddedStandaloneServerFactory$StandaloneServerImpl.start(EmbeddedStandaloneServerFactory.java:275) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.wildfly.core.embedded.EmbeddedServerReference.invokeOnServer(EmbeddedServerReference.java:85) > at org.wildfly.core.embedded.EmbeddedServerReference.start(EmbeddedServerReference.java:56) > at org.jboss.as.cli.embedded.EmbedServerHandler.doHandle(EmbedServerHandler.java:205) > at org.jboss.as.cli.handlers.CommandHandlerWithHelp.handle(CommandHandlerWithHelp.java:88) > at org.jboss.as.cli.impl.CommandContextImpl.handle(CommandContextImpl.java:773) > at org.jboss.as.cli.impl.CommandContextImpl.handleSafe(CommandContextImpl.java:796) > at org.jboss.as.cli.impl.CommandContextImpl$2.execute(CommandContextImpl.java:410) > at org.jboss.aesh.console.AeshProcess.run(AeshProcess.java:53) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > 10:12:40,227 INFO [org.jboss.as] (MSC service thread 2-8) WFLYSRV0049: WildFly Core 2.0.0.CR7-SNAPSHOT (WildFly Core 2.0.0.CR7-SNAPSHOT) starting > 10:12:40,678 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Core 2.0.0.CR7-SNAPSHOT (WildFly Core 2.0.0.CR7-SNAPSHOT) started in 465ms - Started 35 of 42 services (13 services are lazy, passive or on-demand) > [standalone@embedded /] > {noformat} > Embed server functionality doesn't seem to be affected by the exception - is operable. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ELY-373) General peer verification callback

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/ELY-373?page=com.atlassian.jira.plugin.sy... ] David Lloyd updated ELY-373: ---------------------------- Fix Version/s: 1.1.0.Beta2 (was: 1.1.0.Beta3) > General peer verification callback > ---------------------------------- > > Key: ELY-373 > URL: https://issues.jboss.org/browse/ELY-373 > Project: WildFly Elytron > Issue Type: Task > Components: Callbacks > Reporter: David Lloyd > Assignee: David Lloyd > Fix For: 1.1.0.Beta2 > > > We need to generalize peer verification. Right now the peer verification callback ({{org.wildfly.security.auth.callback.VerifyPeerTrustedCallback}}) is specific to X.509 certificate chains, but other mechanisms might use different peer credentials for the verification. > An ideal API might use an optional Principal and an optional Credential. For Entity, a {{org.wildfly.security.credential.X509CertificateChainPublicCredential}} might be used for the Credential, and the Principal would be extracted from that. For key-based authentication, the principal could be the NamePrincipal of the host name and the credential would be a PublicKeyCredential. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 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 November 2015