[JBoss JIRA] (AS7-3449) IPv6: Unable to start EAP when hostname isn't available in IPv4 address space
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/AS7-3449?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry commented on AS7-3449:
---------------------------------------
Does it work with -Djava.net.preferIPv4Stack=true removed from standalone.conf?
> IPv6: Unable to start EAP when hostname isn't available in IPv4 address space
> -----------------------------------------------------------------------------
>
> Key: AS7-3449
> URL: https://issues.jboss.org/browse/AS7-3449
> Project: Application Server 7
> Issue Type: Bug
> Affects Versions: 7.1.0.CR1b
> Environment: Linux
> Reporter: Pavel Janousek
> Priority: Blocker
>
> I unpacked DR5 build ZIP only, didn't touch configuration and try to run as usual:
> {code}
> cd <bin dir of EAP>
> ./standalone.sh
> {code}
> Got this result:
> {code}
> [root@fedora15-vrt1 bin]# ./standalone.sh
> =========================================================================
> JBoss Bootstrap Environment
> JBOSS_HOME: /home/pjanouse/tmp/jboss-eap-6.0.0.Alpha2
> JAVA: java
> JAVA_OPTS: -server -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> =========================================================================
> 16:55:46,040 INFO [org.jboss.modules] JBoss Modules version 1.0.3.GA
> 16:55:47,253 INFO [org.jboss.msc] JBoss MSC version 1.0.1.GA
> 16:55:47,362 INFO [org.jboss.as] JBoss EAP 6.0.0.Alpha2 (AS 7.1.0.Alpha1-redhat-1) starting
> 16:55:48,163 INFO [org.jboss.as] JBoss EAP 6.0.0.Alpha2 (AS 7.1.0.Alpha1-redhat-1) stopped in 3ms
> 16:55:48,156 ERROR [org.jboss.as.controller.AbstractControllerService] Error booting the container: java.lang.RuntimeException: org.jboss.as.controller.persistence.ConfigurationPersistenceException: Failed to parse configuration
> at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:139) [jboss-as-controller-7.1.0.Alpha1-redhat-1.jar:7.1.0.Alpha1-redhat-1]
> at java.lang.Thread.run(Thread.java:679) [:1.6.0_22]
> Caused by: org.jboss.as.controller.persistence.ConfigurationPersistenceException: Failed to parse configuration
> at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:125) [jboss-as-controller-7.1.0.Alpha1-redhat-1.jar:7.1.0.Alpha1-redhat-1]
> at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:168) [jboss-as-controller-7.1.0.Alpha1-redhat-1.jar:7.1.0.Alpha1-redhat-1]
> at org.jboss.as.server.ServerService.boot(ServerService.java:197) [jboss-as-server-7.1.0.Alpha1-redhat-1.jar:7.1.0.Alpha1-redhat-1]
> at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:133) [jboss-as-controller-7.1.0.Alpha1-redhat-1.jar:7.1.0.Alpha1-redhat-1]
> ... 1 more
> Caused by: java.lang.RuntimeException: Unable to determine a default name based on the local host name
> at org.jboss.as.controller.parsing.CommonXml.getDefaultName(CommonXml.java:188) [jboss-as-controller-7.1.0.Alpha1-redhat-1.jar:7.1.0.Alpha1-redhat-1]
> at org.jboss.as.controller.parsing.StandaloneXml.readServerElement_1_1(StandaloneXml.java:263) [jboss-as-controller-7.1.0.Alpha1-redhat-1.jar:7.1.0.Alpha1-redhat-1]
> at org.jboss.as.controller.parsing.StandaloneXml.readElement(StandaloneXml.java:103) [jboss-as-controller-7.1.0.Alpha1-redhat-1.jar:7.1.0.Alpha1-redhat-1]
> at org.jboss.as.controller.parsing.StandaloneXml.readElement(StandaloneXml.java:82) [jboss-as-controller-7.1.0.Alpha1-redhat-1.jar:7.1.0.Alpha1-redhat-1]
> at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:100) [staxmapper-1.0.0.Final-redhat-1.jar:1.0.0.Final-redhat-1]
> at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:59) [staxmapper-1.0.0.Final-redhat-1.jar:1.0.0.Final-redhat-1]
> at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:117) [jboss-as-controller-7.1.0.Alpha1-redhat-1.jar:7.1.0.Alpha1-redhat-1]
> ... 4 more
> Caused by: java.net.UnknownHostException: fedora15-vrt1: fedora15-vrt1
> at java.net.InetAddress.getLocalHost(InetAddress.java:1426) [:1.6.0_22]
> at org.jboss.as.controller.parsing.CommonXml.getDefaultName(CommonXml.java:186) [jboss-as-controller-7.1.0.Alpha1-redhat-1.jar:7.1.0.Alpha1-redhat-1]
> ... 10 more
> [root@fedora15-vrt1 bin]#
> {code}
> The root of this issue is that *fedora15-vrt1* can't be translated to IPv4 IP address, but only to IPv6 address:
> {code}
> [root@fedora15-vrt1 bin]# ping fedora15-vrt1
> ping: unknown host fedora15-vrt1
> [root@fedora15-vrt1 bin]# ping6 fedora15-vrt1
> PING fedora15-vrt1(vrt1-ip6) 56 data bytes
> 64 bytes from vrt1-ip6: icmp_seq=1 ttl=64 time=0.067 ms
> 64 bytes from vrt1-ip6: icmp_seq=2 ttl=64 time=0.105 ms
> ^C
> --- fedora15-vrt1 ping statistics ---
> 2 packets transmitted, 2 received, 0% packet loss, time 999ms
> rtt min/avg/max/mdev = 0.067/0.086/0.105/0.019 ms
> [root@fedora15-vrt1 bin]#
> {code}
> because I really config /etc/hosts like:
> {code}
> [root@fedora15-vrt1 bin]# cat /etc/hosts
> 127.0.0.1 localhost.localdomain localhost
> ::1 localhost6.localdomain6 localhost6
> 10.0.2.15 both
> ::ffff:10.0.2.15 both
> 1:0:0:1::10 vrt1-ip6 fedora15-vrt1
> 1:0:0:1::11 vrt2-ip6
> [root@fedora15-vrt1 bin]#
> {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
12 years, 8 months
[JBoss JIRA] (AS7-3476) cache-container=foo/:add-alias fails if the list starts out undefined
by Stan Silvert (JIRA)
Stan Silvert created AS7-3476:
---------------------------------
Summary: cache-container=foo/:add-alias fails if the list starts out undefined
Key: AS7-3476
URL: https://issues.jboss.org/browse/AS7-3476
Project: Application Server 7
Issue Type: Bug
Components: Domain Management
Affects Versions: 7.1.0.CR1b
Reporter: Stan Silvert
Assignee: Richard Achmatowicz
Below, see JBAS014749: Operation handler failed: null
/subsystem=infinispan/cache-container=foo/:read-attribute(name=aliases)
{
"outcome" => "success",
"result" => undefined,
"response-headers" => {"process-state" => "reload-required"}
}
/subsystem=infinispan/cache-container=foo/:add-alias(name=foo2)
{
"outcome" => "failed",
"failure-description" => "JBAS014749: Operation handler failed: null",
"rolled-back" => true,
"response-headers" => {"process-state" => "reload-required"}
}
/subsystem=infinispan/cache-container=foo/:write-attribute(name=aliases,value=["foo2"])
{
"outcome" => "success",
"response-headers" => {
"operation-requires-reload" => true,
"process-state" => "reload-required"
}
}
/subsystem=infinispan/cache-container=foo/:add-alias(name=foo3)
{
"outcome" => "success",
"response-headers" => {
"operation-requires-reload" => true,
"process-state" => "reload-required"
}
}
/subsystem=infinispan/cache-container=foo/:read-attribute(name=aliases)
{
"outcome" => "success",
"result" => [
"foo2",
"foo3"
],
"response-headers" => {"process-state" => "reload-required"}
}
--
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
12 years, 8 months
[JBoss JIRA] (JBMDR-75) Merging entity bean metadata yields ClassCastException
by Rune Flobakk (JIRA)
Rune Flobakk created JBMDR-75:
---------------------------------
Summary: Merging entity bean metadata yields ClassCastException
Key: JBMDR-75
URL: https://issues.jboss.org/browse/JBMDR-75
Project: JBoss MetaData Repository
Issue Type: Bug
Components: MetaData
Environment: JBoss AS 7.1.0.CR1b
Reporter: Rune Flobakk
Priority: Critical
I have encountered this issue on JBoss AS 7.1.0.CR1b with an application containing EJB2 entity beans. When deploying the beans I get the following ClassCastException:
{quote}
13:04:55,292 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC00001: Failed to start service jboss.deployment.subunit."myapp.ear"."myapplication-ejb-1.3-SNAPSHOT.jar".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."myapp.ear"."myapplication-ejb-1.3-SNAPSHOT.jar".PARSE: Failed to process phase PARSE of subdeployment "myapplication-ejb-1.3-SNAPSHOT.jar" of deployment "myapp.ear"
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:121) [jboss-as-server-7.1.0.CR1b.jar:7.1.0.CR1b]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1824) [jboss-msc-1.0.1.GA.jar:1.0.1.GA]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1759) [jboss-msc-1.0.1.GA.jar:1.0.1.GA]
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_24]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_24]
at java.lang.Thread.run(Thread.java:662) [:1.6.0_24]
Caused by: java.lang.ClassCastException: org.jboss.metadata.ejb.spec.EntityBeanMetaData cannot be cast to org.jboss.metadata.ejb.jboss.ejb3.JBossGenericBeanMetaData
at org.jboss.metadata.ejb.spec.EntityBeanMetaData.merge(EntityBeanMetaData.java:121)
at org.jboss.metadata.ejb.spec.EntityBeanMetaData.createMerged(EntityBeanMetaData.java:112)
at org.jboss.metadata.ejb.spec.EntityBeanMetaData.createMerged(EntityBeanMetaData.java:32)
at org.jboss.metadata.ejb.spec.EnterpriseBeansMetaData.merge(EnterpriseBeansMetaData.java:81)
at org.jboss.metadata.ejb.spec.EnterpriseBeansMetaData.createMerged(EnterpriseBeansMetaData.java:52)
at org.jboss.metadata.ejb.spec.EjbJarMetaData.merge(EjbJarMetaData.java:175)
at org.jboss.metadata.ejb.spec.EjbJarMetaData.createMerged(EjbJarMetaData.java:668)
at org.jboss.as.ejb3.deployment.processors.EjbJarParsingDeploymentUnitProcessor.deploy(EjbJarParsingDeploymentUnitProcessor.java:124)
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:115) [jboss-as-server-7.1.0.CR1b.jar:7.1.0.CR1b]
... 5 more
{quote}
I have recreated the exception in isolation in a unit test, which can be pulled from my fork of jboss-metadata at github https://github.com/runeflobakk/metadata.
I have identified the bug to be a faulty cast at {{[EntityBeanMetaData.java:121|https://github.com/jboss/metadata/blob/master/ejb/src/main/java/org/jboss/metadata/ejb/spec/EntityBeanMetaData.java#L121]}} (well, obviously). The immediate cause of this is the call to {{EntityBeanMetaData#merge}} at {{[EntityBeanMetaData.java:112|https://github.com/jboss/metadata/blob/master/ejb/src/main/java/org/jboss/metadata/ejb/spec/EntityBeanMetaData.java#L112]}}, passing {{this}} as argument for the {{AbstractEnterpriseBeanMetaData or}} parameter. {{or}} is then being cast to {{JBossGenericBeanMetaData}}, which is an entirely different type than {{EntityBeanMetaData}}. The code simply cannot possibly run.
I _can_ change the cast to EntityBeanMetaData and the code still compiles, but I do not know if this has any other implications, e.g. if the public {{merge}} method is being called by any others which actually _do_ pass an JBossGenericBeanMetaData.
--
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
12 years, 8 months
[JBoss JIRA] (AS7-3457) Server reload results in failed webservices startup
by Brian Stansberry (JIRA)
Brian Stansberry created AS7-3457:
-------------------------------------
Summary: Server reload results in failed webservices startup
Key: AS7-3457
URL: https://issues.jboss.org/browse/AS7-3457
Project: Application Server 7
Issue Type: Bug
Components: Web Services
Reporter: Brian Stansberry
Assignee: Alessio Soldano
Priority: Critical
Fix For: 7.1.0.Final
Executing the :reload operation from the CLI results in:
17:14:50,681 ERROR [org.jboss.as.controller.management-operation] Operation ("add") failed - address: ([
("subsystem" => "webservices"),
("endpoint-config" => "Recording-Endpoint-Config"),
("pre-handler-chain" => "recording-handlers")
]) - failure description: "JBAS015588: Cannot add new handler chain of type pre-handler-chain with id recording-handlers. This id is already used in config Recording-Endpoint-Config for another chain."
--
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
12 years, 8 months
[JBoss JIRA] (AS7-3464) add-user.sh - possibility of setting another Realms should be considered again
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/AS7-3464?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse updated AS7-3464:
----------------------------------
Fix Version/s: Open To Community
Assignee: (was: Anil Saldhana)
If anyone in the community would like to contribute what we actually need here is better detection of the name of the security realm in use by the AS instance.
By default we ship with the realm named ManagementRealm, however as the digest in the properties file is based on the username, realm and password we would recommend the use of different realms on different installations so that disclosing the properties file from one installation does not necessarily affect other instances that have users with the same username and password but a different realm.
The issue is that the name of the realm is defined in the standalone.xml and host.xml so as it stands now these need to be parsed if the server is not running to identify the name of the realm - if the server is running a connection to the server is an option (although a bit messy) to discover the realm.
Alternatively the name of the realm used for the digests could be separated from the config and stored in a file adjacent to the properties file, the first time add-user.sh is run the user would be asked to choose a realm name for their installation - that would be stored in the file and used for all subsequent calls to add-user.sh - this way unique realm names could be encouraged without forcing the core configuration to be modified.
This alternative location to specify the realm may be better considered for AS 7.2 or beyond when we will hopefully expand on the manageability of users and incorporate it there.
> add-user.sh - possibility of setting another Realms should be considered again
> ------------------------------------------------------------------------------
>
> Key: AS7-3464
> URL: https://issues.jboss.org/browse/AS7-3464
> Project: Application Server 7
> Issue Type: Bug
> Components: Security
> Affects Versions: 7.1.0.CR1b
> Reporter: Pavel Janousek
> Priority: Minor
> Fix For: Open To Community
>
>
> I'm aware of add-user.sh isn't general tool for managing an user/groups/roles credential store at all. Is it supposed only as shorthand for quick definition of users access to admin console out of the box. Well..
> According previous paragraph it isn't to much meaningful for me to bring possibility of specify another realm during the invocation of this tool. I think already - Admin console can use another realm than ManagementRealm by change default configuration. I think already too - property file can't contain users definition belong multiple realms. As is stated in comment in the begin of file mgmt-users.properties, this file is for "declaration of users for the realm 'ManagementRealm'".
> I think we should avoid to insert new user with different realm there (it is possible now). add-user.sh doesn't manage any other file and other property file(s) can't be specified during invocation.
> I think this present situation/behavior should confuse hard our end-users - especially users with their own experiences with other JEE servers (Apache Geronimo, Sun/Oracle GlassFish etc.).
> Because we don't provide/support any tool for general CRUD managing of credential store of type like property file(s) - like other JEE app. servers do, we really should use this script/tool only as way to simple very basic user creation in default AS7 environment, because we can't support this tool in any other situation with present behavior and in a such changed environments behavior or final state is hardly understandable (if we create property file (by other way) with the same username, but in different realms, we can't log to admin console never more; if we have users in one realm, switch AS7 instance to use other "admin" realm, we can't add any from existing user to this new realm; we don't know which user belongs to which realm later etc.)
> So conclusion - I think we should remove specification of Realm from input process of add-user.sh script at all and use this script only to define users belongs to ManagementRealm realm and manages only properly mgmt-users.properties files (standalone and domain configuration)
--
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
12 years, 8 months