[JBoss JIRA] Created: (JBAS-8824) Cardinality constraints on children are not enforced after parsing
by Brian Stansberry (JIRA)
Cardinality constraints on children are not enforced after parsing
------------------------------------------------------------------
Key: JBAS-8824
URL: https://issues.jboss.org/browse/JBAS-8824
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Domain Management
Affects Versions: 7.0.0.Alpha1
Reporter: Brian Stansberry
Priority: Critical
Fix For: 7.0.0.Beta1
The parsers enforce cardinality constraints on child elements in the model, but they aren't enforced thereafter. So, for example, a second "profile" or "socket-binding-group" could be added to a standalone server via a management operation.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months
[JBoss JIRA] (AS7-4697) Support general XML Entities in AS boot configuration
by Michael Epley (JIRA)
Michael Epley created AS7-4697:
----------------------------------
Summary: Support general XML Entities in AS boot configuration
Key: AS7-4697
URL: https://issues.jboss.org/browse/AS7-4697
Project: Application Server 7
Issue Type: Feature Request
Components: ConfigAdmin
Affects Versions: 7.1.1.Final
Environment: Fedora 16, plenty of memory, disk, etc; feature is not related to environment
Reporter: Michael Epley
Assignee: Thomas Diesler
The parser for the AS7 boot configuration (tested with standalone.xml) does not permit the use of general XML entities, as it fails [1] on the parsing of the entity declaration [2]. This appears due to the use of a low level parser enforcing certain expectations in the XML file layout.
Use of XML external entities is a method that allows the single boot configuration file to be broken into multiple, independent pieces so that they can be independently contributed (by different developers/teams), controlled (by different developers/teams), configuration managed, or use substituted (for different dev/test/stage/prod) configurations. This is a common business requirement, with larger applications, different developers or sub teams usually contribute or have ownership over different subsystems, or that each contribute some portion of a subsystem.
For example, two developers may each use a different JDBC datasource, and a third deployment engineer may be responsible for controlling the main boot configuration to ensure application integrity. Use of XML entities would allow the deployment engineer to write portions of the boot configuration (eg. standalone.xml) such as:
...
<subsystem xmlns="urn:jboss:domain:datasources:1.0">
<datasources>
&developer1datasource;
&developer2datasource;
</datasources>
</subsystem>
...
where &developer1datasource &developer2datasource might be declared as
<!ENTITY developer1datasource SYSTEM "alicesDatasource.xml" >
<!ENTITY developer2datasource SYSTEM "bobsDatasource.xml" >
and the file alicesDatasource.xml is owned/maintained by developer Alice, and the the file bobsDatasource.xml is owned/maintained by developer Bob.
____________________________________________________________________
[1] For example, on boot, the following is reported:
08:52:51,181 ERROR [org.jboss.as.server] JBAS015956: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: JBAS014676: Failed to parse configuration
at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:141) [jboss-as-controller-7.1.1.Final-redhat-1.jar:7.1.1.Final-redhat-1]
at org.jboss.as.server.ServerService.boot(ServerService.java:268) [jboss-as-server-7.1.1.Final-redhat-1.jar:7.1.1.Final-redhat-1]
at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:155) [jboss-as-controller-7.1.1.Final-redhat-1.jar:7.1.1.Final-redhat-1]
at java.lang.Thread.run(Thread.java:679) [rt.jar:1.6.0_24]
Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[6,4]
Message: found: DTD, expected START_ELEMENT or END_ELEMENT
at com.sun.org.apache.xerces.internal.impl.XMLStreamReaderImpl.nextTag(XMLStreamReaderImpl.java:1246) [rt.jar:1.6.0_24]
at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:67) [staxmapper-1.1.0.Final-redhat-1.jar:1.1.0.Final-redhat-1]
at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:133) [jboss-as-controller-7.1.1.Final-redhat-1.jar:7.1.1.Final-redhat-1]
... 3 more
08:52:51,185 FATAL [org.jboss.as.server] JBAS015957: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
[2] Tested with the following entity declaration in standalone.xml (and various other combinations):
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE server [
<!ENTITY datasources SYSTEM "datasources.xml" >
<!ENTITY cacheDefinitions SYSTEM "caches.xml" >
] >
<server xmlns="urn:jboss:domain:1.3">
<extensions>
...
<subsystem xmlns="urn:jboss:domain:datasources:1.0">
&datasources;
</subsystem>
...
<subsystem xmlns="urn:jboss:domain:infinispan:1.3" default-cache-container="local">
&cacheDefinitions;
</subsystem>
...
</socket-binding-group>
</server>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months
[JBoss JIRA] (AS7-4383) Mode to disable writing deployment outcome files to deployment scanner dir
by Brian Stansberry (JIRA)
Brian Stansberry created AS7-4383:
-------------------------------------
Summary: Mode to disable writing deployment outcome files to deployment scanner dir
Key: AS7-4383
URL: https://issues.jboss.org/browse/AS7-4383
Project: Application Server 7
Issue Type: Feature Request
Components: Domain Management
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Fix For: 7.2.0.Alpha1
Investigate adding a config option that disables writing the .isdeploying, .deployed, .isundeploying, .undeployed files to the deployment scanner dir.
Idea is to make it possible to have multiple scanners on different nodes sharing the deployment directory, without having the markers from one interfere with another.
This may not be practical at all in reality; needs investigation.
Marker files created by the user to control deployment should still be supported.
The .failed and .pending files are a bit of a gray area that need investigation.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months
[JBoss JIRA] (AS7-4428) Arquillian: IllegalStateException: standard-sockets -> http -> bound-port is undefined
by Ondrej Zizka (JIRA)
Ondrej Zizka created AS7-4428:
---------------------------------
Summary: Arquillian: IllegalStateException: standard-sockets -> http -> bound-port is undefined
Key: AS7-4428
URL: https://issues.jboss.org/browse/AS7-4428
Project: Application Server 7
Issue Type: Bug
Components: Test Suite
Reporter: Ondrej Zizka
Assignee: Ondrej Zizka
This happens sometimes in QA lab, probably due to slowness.
See https://hudson.qa.jboss.com/hudson/job/AS7-TS-valid-mvn-all-ipv6/56/testR...
{code}
java.lang.RuntimeException: java.lang.IllegalStateException: standard-sockets -> http -> bound-port is undefined
at org.jboss.as.arquillian.container.ManagementClient.getBinding(ManagementClient.java:222)
at org.jboss.as.arquillian.container.ManagementClient.getWebUri(ManagementClient.java:111)
at org.jboss.as.arquillian.container.ManagementClient.getDeploymentMetaData(ManagementClient.java:117)
at org.jboss.as.arquillian.container.CommonDeployableContainer.deploy(CommonDeployableContainer.java:150)
at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:156)
at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:123)
at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.executeOperation(ContainerDeployController.java:266)
at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deploy(ContainerDeployController.java:122)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createDeploymentContext(ContainerDeploymentContextHandler.java:78)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at org.jboss.arquillian.container.impl.client.container.DeploymentExceptionHandler.verifyExpectedExceptionDuringDeploy(DeploymentExceptionHandler.java:50)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:134)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:114)
at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:90)
at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:79)
at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachDeployment(ContainerDeployController.java:258)
at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachManagedDeployment(ContainerDeployController.java:234)
at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deployManaged(ContainerDeployController.java:78)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:134)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:114)
at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
at org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:101)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:75)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:60)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:134)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:114)
at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeClass(EventTestRunnerAdaptor.java:80)
at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:182)
at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:199)
at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:147)
at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:234)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:133)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:114)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:188)
at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:166)
at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:86)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:101)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74)
Caused by: java.lang.IllegalStateException: standard-sockets -> http -> bound-port is undefined
at org.jboss.as.arquillian.container.ManagementClient.defined(ManagementClient.java:193)
at org.jboss.as.arquillian.container.ManagementClient.getBinding(ManagementClient.java:218)
... 96 more
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months
[JBoss JIRA] Created: (JGRP-1317) STABLE: compress STABLE messages
by Bela Ban (JIRA)
STABLE: compress STABLE messages
--------------------------------
Key: JGRP-1317
URL: https://issues.jboss.org/browse/JGRP-1317
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 2.12.2, 3.1
For large clusters, stable messages are quite large, and should be compressed.
E.g.:
- Don't send the entire view (with all members), but only the ViewId, then the indices of a digest array would point to the rank of a member within the referred-to ViewId
- A digest has 3 longs (low, highest_received and highest_delivered). Do we need all 3 every time ?
- Compress the 3 longs into 1 long and 2 shorts: the latter 2 are offsets from the first seqno
- Use a bit set (consisting of a variable number of ints) to set the 3 variables
- If we have a digest (0), 0, 0: send a special marker
- Canonicalize digests: if everyone has (14) 20, 22, then we could write it once, give it an ID of (say) 1 and then only refer to 1 again if we encounter the same digest. Actually, as a matter of fact, most of the digests would be the same, so this optimization could have a big effect !
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months