[JBoss JIRA] (JBMESSAGING-1919) Publisher doesn't get JMSException even if database (JMS persistence) is down
by Toshiya Kobayashi (JIRA)
Toshiya Kobayashi created JBMESSAGING-1919:
----------------------------------------------
Summary: Publisher doesn't get JMSException even if database (JMS persistence) is down
Key: JBMESSAGING-1919
URL: https://issues.jboss.org/browse/JBMESSAGING-1919
Project: JBoss Messaging
Issue Type: Bug
Components: Messaging Core
Affects Versions: 1.4.8.SP5
Reporter: Toshiya Kobayashi
In case of Topic (PERSISTENT mode, Durable Subscriber), Publisher doesn't get JMSException even if database (JMS persistence) is down. Attached a reproducer.
How to reproduce:
JBoss 5.1.1
- configure MySQL as JMS persistence manager
- unzip jms-publisher-subscriber.zip
- edit build.properties for your local env
- copy test-destination-service.xml to deploy dir
- (terminal 1) ant subscriber
- (terminal 2) ant publisher
- stop MySQL
-- Subscriber fails. But Publisher keeps running though database is down
JBoss logs an error message in ChannelSupport.
{noformat}
21:37:47,292 ERROR [ChannelSupport] Failed to handle message
org.jboss.util.NestedSQLException: Unable to get managed connection for DefaultDS; - nested throwable: (javax.resource.ResourceException: Unable to get managed connection for DefaultDS)
{noformat}
But doesn't throw a JMSException. On the other hand, it throws a JMSException in case of Queue.
See: ServerConnectionEndpoint
{code:java}
boolean sendMessage(JBossMessage msg, Transaction tx, boolean checkForDuplicates) throws Exception
{
...
else if (dest.isQueue())
{
if (trace) { log.trace(this + " routing " + msg + " to queue"); }
if (!postOffice.route(ref, new JMSCondition(true, dest.getName()), tx))
{
throw new JMSException("Failed to route " + ref + " to " + dest.getName());
}
}
else
{
if (trace) { log.trace(this + " routing " + msg + " to postoffice"); }
postOffice.route(ref, new JMSCondition(false, dest.getName()), tx);
}
if (trace) { log.trace("sent " + msg); }
return true;
}
{code}
This logic is written in revision 1237. But there is no reason to avoid throwing JMS Exception for Topic?
https://source.jboss.org/browse/JBossMessaging/trunk/src/main/org/jboss/j...
{noformat}
------------------------------------------------------------------------
r1237 | timfox | 2006-08-31 03:36:36 +0900 (Thu, 31 Aug 2006) | 4 lines
Initial commit for clustering
{noformat}
--
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, 2 months
[JBoss JIRA] (AS7-3036) Remove OSGi bundles that cannot be supported
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/AS7-3036?page=com.atlassian.jira.plugin.s... ]
Thomas Diesler commented on AS7-3036:
-------------------------------------
The functionality itself is still available (as documented in the [user guide|https://docs.jboss.org/author/display/JBOSGI/Provided+Examples]). It is only that we do not ship the bundles any more that provide the functionality. Instead, we provide a general Repository functionality that can be used to provision the OSGi subsystem with the functionality that is actually needed.
The standalone JBoss OSGi Runtime has been retired - we now focus on OSGi in the context of AS7 only. However, you can of course use our framework embedded or as the target of an external runner like you can with Equinox, Felix, etc.
> Remove OSGi bundles that cannot be supported
> --------------------------------------------
>
> Key: AS7-3036
> URL: https://issues.jboss.org/browse/AS7-3036
> Project: Application Server 7
> Issue Type: Task
> Components: OSGi
> Reporter: Thomas Diesler
> Assignee: Thomas Diesler
> Fix For: 7.1.0.Final
>
>
> Currently we have:
> * Webconsole, provided by Felix (requires HttpService)
> * HttpService, provided by PaxWeb (runs on Jetty)
> * Webapp support, provided by PaxWeb (runs on Jetty)
> * LogService, provided by Felix
> * ConfigAdmin service, provided by Felix
> * JMX services, provided by Aries
> * EventAdmin, provided by Felix
> * DeclarativServices, provided by Felix
> * STOMP endpoints (Stilts), provided by JBoss
> * Blueprint, provided by Aries
> * XML parsing, provided by JBoss
> * JNDI support, provided by JBoss
> * JTA support, provided by JBoss
--
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, 2 months
[JBoss JIRA] (AS7-3036) Remove OSGi bundles that cannot be supported
by Rafael Soares (JIRA)
[ https://issues.jboss.org/browse/AS7-3036?page=com.atlassian.jira.plugin.s... ]
Rafael Soares edited comment on AS7-3036 at 4/9/12 11:32 PM:
-------------------------------------------------------------
Hi Thomas.
The support for these specs will be added in future versions of AS7 or in JBoss OSGi standalone distro?
The reason why they were removed was the EAP distro?
was (Author: rafaelcba):
Hi Thomas.
The support for these specs will be added in future versions of AS7 or in JBoss OSGi standalone distro?
> Remove OSGi bundles that cannot be supported
> --------------------------------------------
>
> Key: AS7-3036
> URL: https://issues.jboss.org/browse/AS7-3036
> Project: Application Server 7
> Issue Type: Task
> Components: OSGi
> Reporter: Thomas Diesler
> Assignee: Thomas Diesler
> Fix For: 7.1.0.Final
>
>
> Currently we have:
> * Webconsole, provided by Felix (requires HttpService)
> * HttpService, provided by PaxWeb (runs on Jetty)
> * Webapp support, provided by PaxWeb (runs on Jetty)
> * LogService, provided by Felix
> * ConfigAdmin service, provided by Felix
> * JMX services, provided by Aries
> * EventAdmin, provided by Felix
> * DeclarativServices, provided by Felix
> * STOMP endpoints (Stilts), provided by JBoss
> * Blueprint, provided by Aries
> * XML parsing, provided by JBoss
> * JNDI support, provided by JBoss
> * JTA support, provided by JBoss
--
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, 2 months
[JBoss JIRA] (AS7-3036) Remove OSGi bundles that cannot be supported
by Rafael Soares (JIRA)
[ https://issues.jboss.org/browse/AS7-3036?page=com.atlassian.jira.plugin.s... ]
Rafael Soares commented on AS7-3036:
------------------------------------
Hi Thomas.
The support for these specs will be added in future versions of AS7 or in JBoss OSGi standalone distro?
> Remove OSGi bundles that cannot be supported
> --------------------------------------------
>
> Key: AS7-3036
> URL: https://issues.jboss.org/browse/AS7-3036
> Project: Application Server 7
> Issue Type: Task
> Components: OSGi
> Reporter: Thomas Diesler
> Assignee: Thomas Diesler
> Fix For: 7.1.0.Final
>
>
> Currently we have:
> * Webconsole, provided by Felix (requires HttpService)
> * HttpService, provided by PaxWeb (runs on Jetty)
> * Webapp support, provided by PaxWeb (runs on Jetty)
> * LogService, provided by Felix
> * ConfigAdmin service, provided by Felix
> * JMX services, provided by Aries
> * EventAdmin, provided by Felix
> * DeclarativServices, provided by Felix
> * STOMP endpoints (Stilts), provided by JBoss
> * Blueprint, provided by Aries
> * XML parsing, provided by JBoss
> * JNDI support, provided by JBoss
> * JTA support, provided by JBoss
--
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, 2 months
[JBoss JIRA] (AS7-4394) ConnectionFactory factory-type is broken
by Jeff Mesnil (JIRA)
Jeff Mesnil created AS7-4394:
--------------------------------
Summary: ConnectionFactory factory-type is broken
Key: AS7-4394
URL: https://issues.jboss.org/browse/AS7-4394
Project: Application Server 7
Issue Type: Bug
Components: JMS
Affects Versions: 7.1.1.Final
Reporter: Jeff Mesnil
Assignee: Andy Taylor
User reported that he could not set the <factory-type> when creating a connection factory:
{noformat}
<connection-factory name="RemoteConnectionFactory">
<factory-type>XA_GENERIC</factory-type>
<connectors>
<connector-ref connector-name="netty"/>
</connectors>
<entries>
<entry name="RemoteConnectionFactory"/>
<entry name="java:jboss/exported/jms/RemoteConnectionFactory"/>
</entries>
<ha>true</ha>
</connection-factory>
{noformat}
I am not sure to understand what is supposed to do this factory-type attribute...
It is not correctly described in the connection-factory description in the CLI:
{noformat}
[standalone@localhost:9999 /] /subsystem=messaging/hornetq-server=default/connection-factory=RemoteConnectionFactory/:read-resource-description
...
"factory-type" => {
"description" => "The type of connection factory. 0 = jms cf, 1 = queue cf, 2 = topic cf, 3 = xa cf, 4 = xa queue cf, 5 = xa topic cf",
"type" => INT,
"nillable" => false,
"allowed" => [
undefined,
undefined,
undefined,
undefined,
undefined,
undefined
],
"access-type" => "read-only",
"storage" => "runtime"
},
...
{noformat}
The allowed values are not properly defined (code in MessagingDescriptions.getConnectionFactory(Locale) is bogus, I'll fix it...)
I don't understand why it is defined as read only but in ConnectionFactoryAdd we try to set the factoryType based on the resolved CONNECTION_FACTORY_TYPE attribute. This attribute is not defined among the connection factory attributes and can not be set when creating a cf with the CLI.
I don't understand why the "factory-type" model node is defined twice (in CommonAttributes and in MessagingDescriptions.getConnectionFactory(Locale)). To me, these 2 attributes are the same.
I'll fix it with the expectation that it is valid for an user to set the type of connection factory (with or w/o XA, queue/topic/generic) when he adds one through configuration or the CLI. Does that sound correct?
--
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, 2 months
[JBoss JIRA] (AS7-4114) datasource min/max pool size details not available via json/cli
by Simeon Pinder (JIRA)
[ https://issues.jboss.org/browse/AS7-4114?page=com.atlassian.jira.plugin.s... ]
Simeon Pinder commented on AS7-4114:
------------------------------------
Note:
So basically this looks like a misunderstanding between how the default values
are defined for some objects in AS7. Instead of setting the default values in
the object model itself as is the case in many places they are attaching a
metadata description object where the default values are defined. This is not
consistently done across all of the nodes or even the subsystems.
In the AS7 administration console the default values are correctly displayed
because they knew to populate the default values from the metadata(if
undefined). I interpreted this as a bug when I requested the same data via cli
and got undefined.
In ER4.1 these values are available so this issue is no longer blocked.
> datasource min/max pool size details not available via json/cli
> ---------------------------------------------------------------
>
> Key: AS7-4114
> URL: https://issues.jboss.org/browse/AS7-4114
> Project: Application Server 7
> Issue Type: Bug
> Components: REST
> Affects Versions: 7.1.0.Final
> Environment: DR13, cli/json interface.
> Reporter: Simeon Pinder
> Assignee: Stefano Maestri
> Labels: rhq
>
> Use cli to browse data with recursive/runtime both true but fields are undefined. The max/min pool sizes are available via localhost:9990/console/App.hmtl.
> /subsystem=datasources/data-source=H2DS/
> max-pool-size => undefined
> min-pool-size => undefined
--
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, 2 months
[JBoss JIRA] (AS7-4435) CLONE - EAR deployment with initialize-in-order doesn't wait for persistence-unit if it's not used in the module
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/AS7-4435?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry moved JBPAPP-8666 to AS7-4435:
-----------------------------------------------
Project: Application Server 7 (was: JBoss Enterprise Application Platform)
Key: AS7-4435 (was: JBPAPP-8666)
Workflow: GIT Pull Request workflow (was: jira)
Affects Version/s: 7.1.1.Final
(was: EAP 6.0.0 ER 4)
Component/s: EE
(was: Microcontainer and Deployers)
Security: (was: Public)
Fix Version/s: 7.1.2.Final-redhat1
(was: TBD EAP 6)
Docs QE Status: (was: NEW)
> CLONE - EAR deployment with initialize-in-order doesn't wait for persistence-unit if it's not used in the module
> ----------------------------------------------------------------------------------------------------------------
>
> Key: AS7-4435
> URL: https://issues.jboss.org/browse/AS7-4435
> Project: Application Server 7
> Issue Type: Bug
> Components: EE
> Affects Versions: 7.1.1.Final
> Environment: EAP 6.0.0.ER4.1, Seam 2.3.0.Beta2-SNAPSHOT (2012-04-06)
> Reporter: Marek Schmidt
> Assignee: Stuart Douglas
> Labels: eap6_need_triage
> Fix For: 7.1.2.Final-redhat1
>
>
> I have an Seam2 EAR application (Blog example from Seam distribution) which almost always fails to deploy with
> {noformat}
> javax.naming.NameNotFoundException: Error looking up blogEntityManagerFactory, service service jboss.naming.context.java.blogEntityManagerFactory is not started
> {noformat}
> The application.xml looks like this:
> {noformat}
> <?xml version="1.0" encoding="UTF-8"?>
> <application xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/application_6.x
> sd" version="6">
> <description>Examples for Seam 2 Framework in Java EE6 environment</description>
> <display-name>blog-ear</display-name>
> <initialize-in-order>true</initialize-in-order>
> <module>
> <ejb>blog-ejb.jar</ejb>
> </module>
> <module>
> <web>
> <web-uri>blog-web.war</web-uri>
> <context-root>/seam-blog</context-root>
> </web>
> </module>
> <module>
> <ejb>jboss-seam.jar</ejb>
> </module>
> <library-directory>lib</library-directory>
> </application>
> {noformat}
> The blog-ejb.jar contains persistence.xml:
> {noformat}
>
> <?xml version="1.0" encoding="UTF-8"?>
> <persistence xmlns="http://java.sun.com/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd"
> version="1.0">
> <persistence-unit name="entityManager">
> <provider>org.hibernate.ejb.HibernatePersistence</provider>
> <jta-data-source>java:jboss/datasources/ExampleDS</jta-data-source>
> <properties>
> <property name="hibernate.hbm2ddl.auto" value="create-drop"/>
> <property name="hibernate.show_sql" value="true"/>
>
> <property name="hibernate.cache.use_second_level_cache" value="true"/>
> <property name="hibernate.cache.use_query_cache" value="true"/>
> <property name="jboss.entity.manager.factory.jndi.name" value="java:/blogEntityManagerFactory"/>
> <property name="hibernate.search.default.directory_provider" value="filesystem"/>
> <property name="hibernate.search.default.indexBase" value="./blogindexes"/>
> </properties>
> </persistence-unit>
> </persistence>
> {noformat}
> The persistence unit is accessed in Seam via JNDI
> (components.xml)
> {noformat}
> <persistence:managed-persistence-context name="entityManager"
> auto-create="true"
> persistence-unit-jndi-name="java:/blogEntityManagerFactory"/>
> {noformat}
> This (usually) fails in the IndexerService, which is started automatically during servlet startup, as the java:/blogEntityManagerFactory is not yet ready.
> Note that in the application.xml the "initialize-in-order" is defined, so the web module should not start before the blog-ejb.jar ( which contains the persistence.xml), is started.
> Source of IndexerService:
> {noformat}
> package actions;
> import javax.ejb.Remove;
> import org.hibernate.search.jpa.FullTextEntityManager;
> import org.jboss.seam.ScopeType;
> import org.jboss.seam.annotations.Create;
> import org.jboss.seam.annotations.Destroy;
> import org.jboss.seam.annotations.In;
> import org.jboss.seam.annotations.Name;
> import org.jboss.seam.annotations.Scope;
> import org.jboss.seam.annotations.Startup;
> /**
> * Index Blog entry at startup
> *
> * @author Emmanuel Bernard
> * @author Sanne Grinovero
> */
> @Name("indexerService")
> @Scope(ScopeType.APPLICATION)
> @Startup
> public class IndexerService
> {
> @In
> private FullTextEntityManager entityManager;
> @Create
> public void index() {
> entityManager.createIndexer().start();
> }
> @Remove
> @Destroy
> public void stop() {}
> }
> {noformat}
> Also note that if I add the following bean to seam-ejb.jar it will correctly wait with the deployment of the web archive:
> {noformat}
> import javax.persistence.PersistenceUnit;
> import javax.persistence.EntityManagerFactory;
> import javax.ejb.Singleton;
> import javax.ejb.Startup;
> @Singleton
> @Startup
> public class Aargh
> {
> @PersistenceUnit
> private EntityManagerFactory emf;
> }
> {noformat}
> I believe this workaround shouldn't be necessary, and the initialize-in-order should also work with persistence units.
> This issue affects all Seam2 EAR applications which use seam-managed entity manager in a @Startup bean, or any other legacy applications accessing persistence units through JNDI.
--
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, 2 months
[JBoss JIRA] (AS7-4070) CLONE - Arquillian should wait until a port is free after AS JVM process ends to prevent "port in use".
by Ondrej Zizka (JIRA)
Ondrej Zizka created AS7-4070:
---------------------------------
Summary: CLONE - Arquillian should wait until a port is free after AS JVM process ends to prevent "port in use".
Key: AS7-4070
URL: https://issues.jboss.org/browse/AS7-4070
Project: Application Server 7
Issue Type: Bug
Components: Test Suite
Affects Versions: 7.1.0.CR1
Reporter: Ondrej Zizka
Assignee: Andrew Rubinger
Priority: Blocker
Fix For: 7.1.2.Final
(05:54:09) dmlloyd: when running with JDWP enabled on the client or server, I occasionally get bind exceptions due to address in use
(05:54:25) dmlloyd: which means that tests are running into each other without waiting for termination of the previous one
(05:54:35) dmlloyd: which may also be causing other issues
(05:56:04) ozizka: dmlloyd: Yes, lbarrerio observed similar problem too,
(05:56:47) ozizka: And that's arq's issue too - there's no way to get around this currently AFAIK. Or is there?
(05:57:05) ozizka: Perhaps "manually" wait in @AfterClass or such
(05:57:07) dmlloyd: yeah, it can wait for the child process to terminate
(05:57:07) ozizka: which is ugly
(05:57:14) dmlloyd: I mean arq should
(05:59:17) ozizka: dmlloyd: Do you have it somewhere on hudson?
(05:59:24) ozizka: dmlloyd: It never happened to me actually
(05:59:49) ozizka: Send me a log if you have one handy
(06:01:35) dmlloyd: ozizka: no, try running with this command though:
{code}
mvn -DallTests install -Djpda -Dsurefire.jpda.args=-Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=n \
-Dmaven.surefire.debug="-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5005"
{code}
(06:13:56) ozizka: dmlloyd: That's on linux?
(06:14:03) dmlloyd: yes
--
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, 2 months
[JBoss JIRA] (AS7-4434) CLONE - It's impossible to add more than 1 custom workmanager to JCA subsystem
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/AS7-4434?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry updated AS7-4434:
----------------------------------
Component/s: Domain Management
> CLONE - It's impossible to add more than 1 custom workmanager to JCA subsystem
> ------------------------------------------------------------------------------
>
> Key: AS7-4434
> URL: https://issues.jboss.org/browse/AS7-4434
> Project: Application Server 7
> Issue Type: Bug
> Components: Domain Management, JCA
> Affects Versions: 7.1.1.Final
> Reporter: Vladimir Rastseluev
> Assignee: Stefano Maestri
> Labels: eap6_need_triage
> Fix For: 7.1.2.Final-redhat1
>
>
> 09:45:35,526 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.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.server.ServerService.boot(ServerService.java:266) [jboss-as-server-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:155) [jboss-as-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_23]
> Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[200,13]
> Message: JBAS014789: Unexpected element '{urn:jboss:domain:jca:1.1}workmanager' encountered
> at org.jboss.as.controller.parsing.ParseUtils.unexpectedElement(ParseUtils.java:85) [jboss-as-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.connector.subsystems.jca.JcaExtension$ConnectorSubsystemParser.readElement(JcaExtension.java:311)
> at org.jboss.as.connector.subsystems.jca.JcaExtension$ConnectorSubsystemParser.readElement(JcaExtension.java:176)
> at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110) [staxmapper-1.1.0.Final.jar:1.1.0.Final]
> at org.jboss.staxmapper.XMLExtendedStreamReaderImpl.handleAny(XMLExtendedStreamReaderImpl.java:69) [staxmapper-1.1.0.Final.jar:1.1.0.Final]
> at org.jboss.as.server.parsing.StandaloneXml.parseServerProfile(StandaloneXml.java:897) [jboss-as-server-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.server.parsing.StandaloneXml.readServerElement_1_1(StandaloneXml.java:332) [jboss-as-server-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:128) [jboss-as-server-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:100) [jboss-as-server-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110) [staxmapper-1.1.0.Final.jar:1.1.0.Final]
> at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69) [staxmapper-1.1.0.Final.jar:1.1.0.Final]
> at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:133) [jboss-as-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> ... 3 more
--
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, 2 months