[
https://issues.jboss.org/browse/WFBUILD-14?page=com.atlassian.jira.plugin...
]
Thomas Diesler edited comment on WFBUILD-14 at 8/2/16 7:04 AM:
---------------------------------------------------------------
This condition still seems to be silently ignored both by the feature-pack-build and the
server-provisioning plugin.
On server start I see
{code}
12:43:56,173 INFO [org.jboss.as] (MSC service thread 1-6) WFLYSRV0049: WildFly Core
2.0.10.Final "Kenny" starting
12:43:56,730 ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught
exception during boot:
org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0085: Failed
to parse configuration
at
org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:131)
[wildfly-controller-2.0.10.Final.jar:2.0.10.Final]
at org.jboss.as.server.ServerService.boot(ServerService.java:356)
[wildfly-server-2.0.10.Final.jar:2.0.10.Final]
at
org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:299)
[wildfly-controller-2.0.10.Final.jar:2.0.10.Final]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_92]
Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[2,1]
Message: Unexpected element '{urn:jboss:domain:4.2}server'
at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:108)
[staxmapper-1.2.0.Final.jar:1.2.0.Final]
at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69)
[staxmapper-1.2.0.Final.jar:1.2.0.Final]
at
org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:123)
[wildfly-controller-2.0.10.Final.jar:2.0.10.Final]
... 3 more
12:43:56,734 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot
has failed in an unrecoverable manner; exiting. See previous messages for details.
{code}
What is supposed to happen here?
The server-provisioning plugin could enforce the exact same version of transitively
reachable features packs or use semantic versioning to choose the latest compatible. The
former approach would work every time. The latter would likely work in most cases while
eliminating the need to rebuild dependent feature packs.
If you like, I could take a look at this.
was (Author: thomas.diesler):
This condition still seems to be silently ignored both by the feature-pack-build and the
server-provisioning plugin.
On server start I see
{code}
12:43:56,173 INFO [org.jboss.as] (MSC service thread 1-6) WFLYSRV0049: WildFly Core
2.0.10.Final "Kenny" starting
12:43:56,730 ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught
exception during boot:
org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0085: Failed
to parse configuration
at
org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:131)
[wildfly-controller-2.0.10.Final.jar:2.0.10.Final]
at org.jboss.as.server.ServerService.boot(ServerService.java:356)
[wildfly-server-2.0.10.Final.jar:2.0.10.Final]
at
org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:299)
[wildfly-controller-2.0.10.Final.jar:2.0.10.Final]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_92]
Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[2,1]
Message: Unexpected element '{urn:jboss:domain:4.2}server'
at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:108)
[staxmapper-1.2.0.Final.jar:1.2.0.Final]
at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69)
[staxmapper-1.2.0.Final.jar:1.2.0.Final]
at
org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:123)
[wildfly-controller-2.0.10.Final.jar:2.0.10.Final]
... 3 more
12:43:56,734 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot
has failed in an unrecoverable manner; exiting. See previous messages for details.
{code}
Conflicting feature pack dependency versions should not be allowed
------------------------------------------------------------------
Key: WFBUILD-14
URL:
https://issues.jboss.org/browse/WFBUILD-14
Project: WildFly Build Tools
Issue Type: Bug
Reporter: James Netherton
Assignee: Stuart Douglas
Fix For: 1.1.7.Final
There was a brief discussion about this on the WildFly dev mailing list so I'm
capturing the problem here as well.
Consider the following.
Feature pack 'A' has a dependency on the WildFly 9 feature pack. E.g:
{code:xml}
<dependencies>
<artifact name="org.wildfly:wildfly-feature-pack:9.0.1.Final" />
</dependencies>
{code}
Feature pack 'B' has a dependency on the WildFly 10 feature pack and also on
feature pack 'A'. E.g:
{code:xml}
<dependencies>
<artifact name="org.wildfly:wildfly-feature-pack:10.0.0.CR3" />
<artifact name="org.foo:feature-pack-A" />
</dependencies>
{code}
The result is that you'll have overlapping and possibly problematic non-overlapping
file paths coming from the conflicting WildFly versions
At the moment the plugins allow this scenario, which can lead to all sorts of horrors
when using the server-provisioning plugin to provision an app server.
CrossRef:
https://github.com/wildfly-extras/fuse-patch/issues/101
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)