January 2012 - jboss-jira - Jboss List Archives

[JBoss JIRA] (AS7-3194) Improper handling of load metric add/remove in mod_cluster subsystem

by Brian Stansberry (Created) (JIRA)

Improper handling of load metric add/remove in mod_cluster subsystem -------------------------------------------------------------------- Key: AS7-3194 URL: https://issues.jboss.org/browse/AS7-3194 Project: Application Server 7 Issue Type: Bug Components: Domain Management, Web Affects Versions: 7.1.0.CR1b Reporter: Brian Stansberry Assignee: Jean-Frederic Clere Fix For: 7.1.0.Final The ModClusterAddMetric and ModClusterAddCustomMetric handlers have two problems: 1) They only run if (context.getType() == OperationContext.Type.SERVER) This means a client updating the subsystem config on a domain controller will not be able to have the change reflected in the domain wide model (and it won't be persisted to domain.xml) 2) If they are run on the server, they don't modify the runtime or call context.reloadRequired(). So the runtime services are out of sync with the configuration but the server state doesn't reflect that. -- 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

14 years, 3 months

6
6
0 / 0

[JBoss JIRA] Created: (AS7-779) AS should allow deploying a non-jar deployment descriptor

by Tobias Crawley (JIRA)

AS should allow deploying a non-jar deployment descriptor --------------------------------------------------------- Key: AS7-779 URL: https://issues.jboss.org/browse/AS7-779 Project: Application Server 7 Issue Type: Feature Request Affects Versions: 7.0.0.Beta3 Reporter: Tobias Crawley Assignee: Jason Greene With TorqueBox, we allow deploying a text based deployment descriptor that points to either an archive of the app, or the app directory tree. To support this, AS7 needs to support deploying non-jar resources. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 3 months

3
2
0 / 0

[JBoss JIRA] (AS7-3245) Convert xts subsystem to i18n logging and exceptions messages as per ANDIAMO-2

by Brian Stansberry (Created) (JIRA)

Convert xts subsystem to i18n logging and exceptions messages as per ANDIAMO-2 ------------------------------------------------------------------------------ Key: AS7-3245 URL: https://issues.jboss.org/browse/AS7-3245 Project: Application Server 7 Issue Type: Task Components: Transactions Reporter: Brian Stansberry Assignee: Jason Greene Fix For: 7.1.0.Final The XtsAsLogger and XtsAsMessages classes are currently empty shells. The INFO and above logging and any exception messages in the subsystem needs to be converted to use these classes. See EJB subsystem for an example. -- 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

14 years, 3 months

2
1
0 / 0

[JBoss JIRA] (AS7-3482) Clustering code expects a public default constructor

by Stuart Douglas (JIRA)

Stuart Douglas created AS7-3482: ----------------------------------- Summary: Clustering code expects a public default constructor Key: AS7-3482 URL: https://issues.jboss.org/browse/AS7-3482 Project: Application Server 7 Issue Type: Bug Components: Clustering Affects Versions: 7.1.0.CR1b Reporter: Stuart Douglas Assignee: Paul Ferraro Fix For: 7.1.0.Final org.jboss.as.ejb3.component.stateful.StatefulSessionBeanObjectResolver.SerializableAdapter#readObject does a targetClass.newInstance(), which will fail if there is not a public default constructor. -- 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

14 years, 3 months

2
2
0 / 0

[JBoss JIRA] (AS7-3483) unable to deploy icescrum_R4_3.1

by Philippe FICHET (JIRA)

Philippe FICHET created AS7-3483: ------------------------------------ Summary: unable to deploy icescrum_R4_3.1 Key: AS7-3483 URL: https://issues.jboss.org/browse/AS7-3483 Project: Application Server 7 Issue Type: Bug Components: Server Affects Versions: 7.1.0.CR1b Environment: Ubuntu 11.10 64 bits 12Go DDR3 java version "1.6.0_23" OpenJDK Runtime Environment (IcedTea6 1.11pre) (6b23~pre11-0ubuntu1.11.10.1) OpenJDK 64-Bit Server VM (build 20.0-b11, mixed mode) Reporter: Philippe FICHET Assignee: Jason Greene I use jboss in standalone mode (unzip only, not modified) I deploy icescrum_R4_3.1.war, but can't access by url "http://localhost:8080/icescrum_R4_3.1/" (http code 404) deply command : [standalone@localhost:9999 /] deploy ../../../tools/icescrum_R4_3.1.war Logs : 21:58:16,778 INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) Starting deployment of "icescrum_R4_3.1.war" 21:58:20,767 INFO [org.jboss.web] (MSC service thread 1-8) registering web context: /icescrum_R4_3.1 21:58:20,784 INFO [org.jboss.as.server] (management-handler-threads - 3) JBAS018559: Deployed "icescrum_R4_3.1.war" -- 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

14 years, 3 months

1
0
0 / 0

[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

14 years, 3 months

1
0
0 / 0

[JBoss JIRA] (AS7-3386) Infinispan subsystem need support for eagerly starting cache containers

by Paul Ferraro (JIRA)

Paul Ferraro created AS7-3386: --------------------------------- Summary: Infinispan subsystem need support for eagerly starting cache containers Key: AS7-3386 URL: https://issues.jboss.org/browse/AS7-3386 Project: Application Server 7 Issue Type: Bug Components: Clustering Affects Versions: 7.1.0.CR1b Reporter: Paul Ferraro Assignee: Paul Ferraro Priority: Critical Fix For: 7.1.0.Final Add the following configuration attribute: <cache-container name="..." start="EAGER|LAZY"/> If LAZY, cache container will not start unless it is demanded by some other service. If EAGER, the cache container will start eagerly, bind to jndi, and all cache configurations will be defined. -- 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

14 years, 3 months

3
3
0 / 0

[JBoss JIRA] (AS7-3296) Fix inconsistent handling of property types in remoting subsystem

by Brian Stansberry (JIRA)

Brian Stansberry created AS7-3296: ------------------------------------- Summary: Fix inconsistent handling of property types in remoting subsystem Key: AS7-3296 URL: https://issues.jboss.org/browse/AS7-3296 Project: Application Server 7 Issue Type: Task Components: Domain Management, Remoting Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: 7.1.0.Final The outbound-connection resources are storing properties in a complex attribute instead of in child resources. That's inconsistent with other usage in the subsystem, so it needs to be fixed. -- 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

14 years, 3 months

2
2
0 / 0

[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

14 years, 3 months

2
1
0 / 0

[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

14 years, 3 months

3
6
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 January 2012