May 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-1444) Fix schema as native-interface shouldn't be mandatory for host-management-interfaces

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1444?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1444: ------------------------------------- Fix Version/s: 2.2.0.CR1 > Fix schema as native-interface shouldn't be mandatory for host-management-interfaces > ------------------------------------------------------------------------------------ > > Key: WFCORE-1444 > URL: https://issues.jboss.org/browse/WFCORE-1444 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 2.1.0.Final > Reporter: ehsavoie Hugonnet > Assignee: ehsavoie Hugonnet > Priority: Minor > Fix For: 2.2.0.CR1, 3.0.0.Alpha1 > > > Since host-management-interfaces could use http-remoting or native remote protocols the native-interface shouldn't be mandatory. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1448) AttributeParser for ObjectListAttributeDefinitions doesn't differentiate between empty and absent object lists

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1448?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1448: ------------------------------------- Fix Version/s: 2.2.0.CR1 > AttributeParser for ObjectListAttributeDefinitions doesn't differentiate between empty and absent object lists > -------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-1448 > URL: https://issues.jboss.org/browse/WFCORE-1448 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 2.1.0.Final > Reporter: Tomaz Cerar > Assignee: Tomaz Cerar > Fix For: 2.2.0.CR1, 3.0.0.Alpha1 > > > Attributes of type ObjectList are left undefined when their enclosing element is empty, which makes it impossible to differentiate an empty object list from an unspecified one. > The ability to distinguish the two scenarios is important in the security manager subsystem. Consider this configuration: > {code:xml} > <subsystem xmlns="urn:jboss:domain:security-manager:1.0"> > <deployment-permissions> > <mininum-set> > .... > </minimum-set> > </deployment-permissions> > </subsystem> > {code} > The maximum-set is absent and this case we want to use a default set with AllPermission. Now consider another configuration: > {code:xml} > <subsystem xmlns="urn:jboss:domain:security-manager:1.0"> > <deployment-permissions> > <mininum-set/> > <maximum-set/> > </deployment-permissions> > </subsystem> > {code} > In this case, maximum-set has been specified but it is empty, which means the admin/user deliberately wants to use an emtpy set, possibly to enforce that no deployments with special permissions requirements get deployed. > The problem is that both scenarios result in an undefined attribute for the maximum-set, which means that the default AllPermission set ends up being used in both cases. The parser doesn't initialize the attribute with an empty list when the enclosing element is present but is empty. So in the end, both approaches result in an undefined attribute. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1454) Undertow 1.3.20.Final

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1454?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1454: ------------------------------------- Fix Version/s: 2.2.0.CR1 > Undertow 1.3.20.Final > --------------------- > > Key: WFCORE-1454 > URL: https://issues.jboss.org/browse/WFCORE-1454 > Project: WildFly Core > Issue Type: Component Upgrade > Reporter: Stuart Douglas > Assignee: Stuart Douglas > Fix For: 2.2.0.CR1, 3.0.0.Alpha1 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-915) Allow concurrent registration of slave host controllers

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-915?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-915: ------------------------------------ Fix Version/s: 2.2.0.CR1 > Allow concurrent registration of slave host controllers > ------------------------------------------------------- > > Key: WFCORE-915 > URL: https://issues.jboss.org/browse/WFCORE-915 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Ken Wills > Labels: 2.2 > Fix For: 2.2.0.CR1, 3.0.0.Alpha1 > > > Registration of slave host controllers must be done with the exclusive ModelController lock held, in order to ensure that the registering HC sees a consistent config throughout the entire process. The drawback to this is registrations must therefore be done in series, which is inefficient in a large domain. > We need to evaluate how this can be done in parallel, without losing the correctness semantics. For example, have the first registration request acquire the lock, but then don't release the lock as long as any other registrations are in progress. > The current lock acquisition mechanism based on an OperationStepHandler acquiring the lock[1] can't do this, or at least not without having the request that acquires the lock have to wait for final completion until all other concurrent requests complete. (Doing that will likely cause problems due to that "unlucky" first slave not getting the expected final response. Plus it just smells bad.) > A possibility is to remove the currrent lock acquisition in the OSH[1] and instead change the internal HostControllerRegistrationHandler.OperationExecutor API to expose a use-case specific method for the initial registration call.[2] The actual HostControllerRegistrationHandler.OperationExecutor impl is DomainModelControllerService, which is the service that installs the ModelControllerImpl and potentially has closer access to its non-public API (i.e. the locking methods.) So DomainModelControllerService can perhaps therefore coordinate the locking, holding the lock until all active registrations complete. > [1] https://github.com/wildfly/wildfly-core/blob/master/host-controller/src/m... > [2] I want to change that API anyway. See TODO at https://github.com/wildfly/wildfly-core/blob/master/host-controller/src/m... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1449) truststore-type incorrect case in management schema

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1449?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1449: ------------------------------------- Fix Version/s: 2.2.0.CR1 > truststore-type incorrect case in management schema > --------------------------------------------------- > > Key: WFCORE-1449 > URL: https://issues.jboss.org/browse/WFCORE-1449 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management, Security > Affects Versions: 2.1.0.Final > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 2.2.0.CR1, 3.0.0.Alpha1 > > > truststore-Type attribute of element server-sslType should be named truststore-type in XSD. Wildfly configuration parser works with truststore-type, but for example eclipse xml validator complains when truststore-type is used in configuration file. > On the other side when truststore-Type (comply to XSD) is used, wildfly configuration parser starts to complain: > {code} > [Host Controller] 14:49:21,822 ERROR [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0033: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0085: Failed to parse configuration > [Host Controller] at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:131) > [Host Controller] at org.jboss.as.host.controller.HostControllerConfigurationPersister.load(HostControllerConfigurationPersister.java:188) > [Host Controller] at org.jboss.as.host.controller.DomainModelControllerService.boot(DomainModelControllerService.java:585) > [Host Controller] at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:299) > [Host Controller] at java.lang.Thread.run(Thread.java:745) > [Host Controller] Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[110,13] > [Host Controller] Message: WFLYCTL0197: Unexpected attribute 'truststore-Type' encountered > [Host Controller] at org.jboss.as.controller.parsing.ParseUtils.unexpectedAttribute(ParseUtils.java:117) > [Host Controller] at org.jboss.as.host.controller.parsing.HostXml_4.parseServerSsl(HostXml_4.java:1271) > [Host Controller] at org.jboss.as.host.controller.parsing.HostXml_4.parseServerContent(HostXml_4.java:1131) > [Host Controller] at org.jboss.as.host.controller.parsing.HostXml_4.parseServer(HostXml_4.java:1088) > [Host Controller] at org.jboss.as.host.controller.parsing.HostXml_4.parseServers(HostXml_4.java:1071) > [Host Controller] at org.jboss.as.host.controller.parsing.HostXml_4.readHostElement(HostXml_4.java:388) > [Host Controller] at org.jboss.as.host.controller.parsing.HostXml_4.readElement(HostXml_4.java:170) > [Host Controller] at org.jboss.as.host.controller.parsing.HostXml.readElement(HostXml.java:79) > [Host Controller] at org.jboss.as.host.controller.parsing.HostXml.readElement(HostXml.java:50) > [Host Controller] at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110) > [Host Controller] at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69) > [Host Controller] at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:123) > [Host Controller] ... 4 more > [Host Controller] > [Host Controller] 14:49:21,823 FATAL [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0034: Host Controller boot has failed in an unrecoverable manner; exiting. See previous messages for details -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1425) Embedded HC started with host-slave.xml uses incorrect hostname

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1425?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1425: ------------------------------------- Fix Version/s: 2.2.0.CR1 > Embedded HC started with host-slave.xml uses incorrect hostname > --------------------------------------------------------------- > > Key: WFCORE-1425 > URL: https://issues.jboss.org/browse/WFCORE-1425 > Project: WildFly Core > Issue Type: Bug > Reporter: Ken Wills > Assignee: Ken Wills > Fix For: 2.2.0.CR1, 3.0.0.Alpha1 > > > EmbeddedHostControllerFactory:282, authCode is being used as the hostname. This is reset if the name is present in the xml config, but since the default -slave.xml has no name, the hostname is displayed as the contents of authCode. > We should probably extract the hostname code from HostControllerEnvironment:300 into its own method, and use that. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1375) Fix build to make it work with JDK9 new versioning

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1375?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1375: ------------------------------------- Fix Version/s: 3.0.0.Alpha1 2.2.0.CR1 > Fix build to make it work with JDK9 new versioning > -------------------------------------------------- > > Key: WFCORE-1375 > URL: https://issues.jboss.org/browse/WFCORE-1375 > Project: WildFly Core > Issue Type: Sub-task > Reporter: Tomaz Cerar > Assignee: Tomaz Cerar > Fix For: 2.2.0.CR1, 3.0.0.Alpha1 > > > Java 9 uses new versioning http://openjdk.java.net/jeps/223 > that breaks some maven plugins. > Fixes are done already in upstream. > best action is to upgrade to jboss-parent that uses new versions of plugins. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1379) service.bat points user to wrong directory

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1379?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1379: ------------------------------------- Fix Version/s: 2.2.0.CR1 > service.bat points user to wrong directory > ------------------------------------------ > > Key: WFCORE-1379 > URL: https://issues.jboss.org/browse/WFCORE-1379 > Project: WildFly Core > Issue Type: Bug > Components: Scripts > Affects Versions: 2.0.10.Final > Reporter: Nicklas Karlsson > Assignee: Tomaz Cerar > Priority: Trivial > Fix For: 2.2.0.CR1, 3.0.0.Alpha1 > > > Running service.bat from the docs/contrib/scripts/service dir tells user to run the script under bin/service*s* but the binary paths to the services expects bin/service, resulting in service install failure with file not found -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1177) Service can't be installed if the path contains a closed bracket

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1177?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1177: ------------------------------------- Fix Version/s: 2.2.0.CR1 > Service can't be installed if the path contains a closed bracket > ---------------------------------------------------------------- > > Key: WFCORE-1177 > URL: https://issues.jboss.org/browse/WFCORE-1177 > Project: WildFly Core > Issue Type: Bug > Components: Scripts > Environment: all Windows versions > Reporter: Paul Wildberg > Assignee: Tomaz Cerar > Priority: Critical > Labels: jboss > Fix For: 2.2.0.CR1, 3.0.0.Alpha1 > > > Problem: > If you start "service.bat install" in e.g. in C:\Program Files (x86)\wildfly-9.0.1.Final\bin\service you will get: > Using the X86-64bit version of prunsrv > "\wildfly-9.0.1.Final\domain\log" can not be used syntatically at this point (don't know if it is correct, I translated it from german. Original it is "kann syntaktisch an dieser Stelle nicht verarbeitet werden.") > Cause: > This is because of the ) in "Program Files (x86)" and this is a problem because in the service.bat in line 175 and 179 (set LOGPATH=%JBOSS_HOME%\domain\log and LOGPATH=%JBOSS_HOME%\standalone\log- in version 9.0.1 and 9.0.2 - in Version 10 it may be in another line) path is not set in double quotation marks. > All other paths are set in double quotation marks. > Solution: > Set the variable and path in double quotation marks: > set "LOGPATH=%JBOSS_HOME%\...\log" -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1399) Failure when resolving an expression with the default value containing a '$' at the end

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1399?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1399: ------------------------------------- Fix Version/s: 2.2.0.CR1 > Failure when resolving an expression with the default value containing a '$' at the end > --------------------------------------------------------------------------------------- > > Key: WFCORE-1399 > URL: https://issues.jboss.org/browse/WFCORE-1399 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 2.1.0.CR1 > Reporter: Valentin Maechler > Assignee: ehsavoie Hugonnet > Fix For: 2.2.0.CR1, 3.0.0.Alpha1 > > Attachments: ExpressionResolver.java, ExpressionResolverUnitTestCase.java > > > Can not add a JNDI / naming entry which contains a "$" sign at the end of its default value. > e.g. {code} > value="${my.sample.property1:entry5-default-value-with-special-char-at-the-end-$}" > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

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