Why does Test Connection fail in Wildfly 20 Using SQL Anywhere sajdbc4 driver? - jdbc

I had Wildfly 10 running previously and have just upgraded to Wildfly 20 (under Ubuntu 20). My configuration from Wildfly 10 no longer works when it comes to getting the Sybase SQL Anywhere 17 sajdbc4 driver working. When I "Test Connection" it fails. I am using the same configuration and testing against the exact same (SQL Anywhere High Availability) database server.
"Test Connection" on the following Datasource triggers an "Invalid ODBC handle" error:
<datasource jndi-name="java:jboss/datasources/TestDB" pool-name="TestDB" spy="true" tracking="true" enlistment-trace="true">
<connection-url>jdbc:sqlanywhere:Host=192.168.1.45:19000,192.168.1.45:19001;ServerName=TestDB</connection-url>
<driver>sajdbc4.jar</driver>
<security>
<user-name>...</user-name>
<password>...</password>
</security>
</datasource>
Connection is not valid
Caused by: java.sql.SQLException: Invalid ODBC handle
at deployment.sajdbc4.jar//sap.jdbc4.sqlanywhere.IDriver.makeODBCConnection(Native Method)
at deployment.sajdbc4.jar//sap.jdbc4.sqlanywhere.IDriver.connect(IDriver.java:809)
at org.jboss.ironjacamar.jdbcadapters#1.4.22.Final//org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.createLocalManagedConnection(LocalManagedConnectionFactory.java:321)
... 35 more
How I set this up:
I used the console to Deploy the sajdbc4.jar and that appears to work fine. I see no errors and sajdbc4 shows up as Deployed in the console and it also shows up as a JDBC Driver in the Subsystems. Here is what was created in standalone.xml after using the console:
deployment name="sajdbc4.jar" runtime-name="sajdbc4.jar">
content sha1="b690ff7a8ba1a3c2e8dd5079138b7970d969c2b9"/>
/deployment>
(I had to drop the leading angle brackets to get the previous lines to show - even when marked as Code!)
Next I had to ensure that the java.library.path and classpath included the path to the sajdbc4.jar and its support files so Wildfly can find them. To do so I added the "HACK" to the following in standalone.conf:
if [ "x$JAVA_OPTS" = "x" ]; then
JAVA_OPTS="-Xms64m -Xmx512m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true"
JAVA_OPTS="$JAVA_OPTS -Djboss.modules.system.pkgs=$JBOSS_MODULES_SYSTEM_PKGS -Djava.awt.headless=true"
# ADDED FOLLOWING HACK
JAVA_OPTS="$JAVA_OPTS -Djava.library.path=/opt/wildfly-20.0.1.Final/modules/system/layers/base/com/sybase/main -cp .:/opt/wildfly-20.0.1.Final/modules/system/layers/base/com/sybase/main/sajdbc4.jar"
echo "Java Properties Next:"
java -XshowSettings:properties -version
else
echo "JAVA_OPTS already set in environment; overriding default settings with values: $JAVA_OPTS"
fi
Finally, I added the datasource block shown at the top. After starting Wildfly TestDB shows up as a Datasource in the Datasources Subsystem but when I Test Connection I get the "Invalid ODBC handle" error.
I feel confident that the driver and all its support files are "working" because I have a very simple Java test app that just makes a connection to TestDB, fetches from a table and displays the rows. Note that it uses the exact same java.library.path and classpath as I set in standalone.conf:
cd $HOME/Desktop
export LD_LIBRARY_PATH=/opt/wildfly-20.0.1.Final/modules/system/layers/base/com/sybase/main
export CLASSPATH=.:/opt/wildfly-20.0.1.Final/modules/system/layers/base/com/sybase/main/sajdbc4.jar
java sajdbc4DriverTest.java
Note that server.log shows no errors and in fact shows lines like:
[org.jboss.as.server.deployment] (MSC service thread 1-3) WFLYSRV0027: Starting deployment of "sajdbc4.jar" (runtime-name: "sajdbc4.jar")
...
[org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-4) WFLYJCA0005: Deploying non-JDBC-compliant driver class sap.jdbc4.sqlanywhere.IDriver (version 4.0)
[org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-3) WFLYJCA0018: Started Driver service with driver-name = sajdbc4.jar
[org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-3) WFLYJCA0001: Bound data source [java:jboss/datasources/TestDB]
...
[org.jboss.as.server] (Controller Boot Thread) WFLYSRV0010: Deployed "sajdbc4.jar" (runtime-name : "sajdbc4.jar")
Note that my connection string is for connecting to a SQL Anywhere High Availability system (hence the two URLS). In Wildfly 20 I see that there is now a new "HA URL Separator" field in the console's Datasource definition page. I tried setting that to a comma and that just changed the Test Connection error to "Unable to create connection from URL":
2020-08-25 11:45:08,378 WARN [org.jboss.jca.core.connectionmanager.pool.strategy.OnePool] (External Management Request Threads -- 1) IJ000604: Throwable while attempting to get a new connection: null: javax.resource.ResourceException: IJ031085: Unable to create connection from URL: jdbc:sqlanywhere:Host=192.168.1.45:19000,192.168.1.45:19001;ServerName=TestDB
at org.jboss.ironjacamar.jdbcadapters#1.4.22.Final//org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.getHALocalManagedConnection(LocalManagedConnectionFactory.java:381)
How do I get "Test Connection" to work?
Thank you in advance.

The problem turned out to be related to the fact that I was running Wildfly as a service and apparently my efforts above to set the java.library.path is failing. I know the reason for the error but I do not know how to set the path when running as a service.

Related

No pools configured yet in tomcat for apex

Tomcat is not up for Oracle Apex because it's pointing to a wrong path which does not exist. Is there a way to fix this? below is the error message.
INFO [main] . No pools configured yet
SEVERE [main] oracle.dbtools.common.logging.LegacyLoggingAdaptor.severe Error writing to:
D:\oracle\product\old_ords\defaults.xml, D:\oracle\product\old_ords\defaults.xml (The system cannot find the path specified)

Caused by: java.io.IOException: Invalid keystore format

I have a JBoss 7.4.0 installation running in domain mode on a RHEL 7 platform. The JDK version is java version "15.0.2" 2021-01-19
Java(TM) SE Runtime Environment (build 15.0.2+7-27)
I am using the Jboss documentation How to Configure Server Security, specifically section 2.5: Configuring SSL/TLS for the legacy core management authentication mechanism. I am setting up Two-Way SSL/TLS.
I create a keystore, generate key pairs, export and import certificates. The storetype is JCEKS. (I have also tried using PCKS12 and JKS, same issue)
When I try to start the JBoss server I see the following error:
06:47:41,216 INFO [org.jboss.modules] (main) JBoss Modules version 1.11.0.Final-redhat-00001
06:47:41,498 INFO [org.jboss.threads] (main) JBoss Threads version 2.4.0.Final-redhat-00001
06:47:41,514 INFO [org.jboss.as.process.Host Controller.status] (main) WFLYPC0018: Starting process 'Host Controller'
[Host Controller] 06:47:41,982 INFO [org.jboss.modules] (main) JBoss Modules version 1.11.0.Final-redhat-00001
...
[Host Controller] 06:47:43,848 WARN [org.jboss.as.domain.management.security] (MSC service thread 1-1) WFLYDM0111: Keystore /u01/redhat/jboss/domain_74/domain/configuration/application.keystore not found, it will be auto generated on first use with a self signed certificate for host localhost
[Host Controller] 06:47:43,851 INFO [org.jboss.remoting] (MSC service thread 1-3) JBoss Remoting version 5.0.20.SP1-redhat-00001
[Host Controller] 06:47:43,852 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service org.wildfly.core.management.security.realm.CertificateRealm.key-manager: org.jboss.msc.service.StartException in service org.wildfly.core.management.security.realm.CertificateRealm.key-manager: Failed to start service
[Host Controller] at org.jboss.msc#1.4.12.Final-redhat-00001//org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1731)
...
[Host Controller] Caused by: java.lang.IllegalStateException: org.jboss.msc.service.StartException in anonymous service: WFLYDM0018: Unable to start service
...
[Host Controller] Caused by: java.io.IOException: Invalid keystore format
So my understanding is the issue is with the keystore format, yet if I use another keystore format I get the same issue.
And, when I run the following command I get success:
./keytool -list -keystore $EAP_HOME/vault/h1vault.jceks
Enter keystore password:
Keystore type: JCEKS
Keystore provider: SunJCE
Your keystore contains 3 entries
h1server_alias, Sep 20, 2022, PrivateKeyEntry,
Certificate fingerprint (SHA-256): 58:58:36:82:EE:B5:88:BB:AF:59:F6:17:F2:9B:D3:29:D6:CC:DD:02:04:E5:3B:50:8A:70:AB:5C:85:59:DD:25
h1vault, Sep 20, 2022, SecretKeyEntry,
host2_alias, Sep 20, 2022, trustedCertEntry,
Certificate fingerprint (SHA-256): 62:07:76:CB:B7:B8:9C:89:6D:36:82:8B:5B:8A:E9:7E:8E:6A:23:8E:51:56:03:B9:F9:98:D3:DA:D4:53:B5:57
I would expect this command to fail if the keystore format was incorrect.
I have read all sorts of threads and so on about this but cannot find an answer.
Appreciate if anyone can suggest possible solutions.
Thanks

Not able to deploy keyclock quickstart example war in wildfly

I can't reproduce the tutorial to deploy this application on wildfly.
I downloaded the wildfly and started wildfly-19.1.0.Final/bin/standalone.sh
And when I execute from project directory mvn clean wildfly:deploy I get this error
15:12:55,016 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.module.service."deployment.app-authz-jee-vanilla.war".main: org.jboss.msc.service.StartException in service jboss.module.service."deployment.app-authz-jee-vanilla.war".main: WFLYSRV0179: Failed to load module: deployment.app-authz-jee-vanilla.war
at org.jboss.as.server#11.1.1.Final//org.jboss.as.server.moduleservice.ModuleLoadService.start(ModuleLoadService.java:116)
at org.jboss.msc#1.4.11.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1739)
at org.jboss.msc#1.4.11.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1701)
at org.jboss.msc#1.4.11.Final//org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1559)
at org.jboss.threads#2.3.3.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads#2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
at org.jboss.threads#2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
at org.jboss.threads#2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
at java.base/java.lang.Thread.run(Thread.java:832)
Caused by: org.jboss.modules.ModuleNotFoundException: org.keycloak.keycloak-authz-client
at org.jboss.modules.Module.addPaths(Module.java:1266)
at org.jboss.modules.Module.link(Module.java:1622)
at org.jboss.modules.Module.relinkIfNecessary(Module.java:1650)
at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:299)
at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:283)
at org.jboss.as.server#11.1.1.Final//org.jboss.as.server.moduleservice.ModuleLoadService.start(ModuleLoadService.java:93)
... 8 more
15:12:55,021 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "app-authz-jee-vanilla.war")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.module.service.\"deployment.app-authz-jee-vanilla.war\".main" => "WFLYSRV0179: Failed to load module: deployment.app-authz-jee-vanilla.war
Caused by: org.jboss.modules.ModuleNotFoundException: org.keycloak.keycloak-authz-client"}}
15:12:55,022 ERROR [org.jboss.as.server] (management-handler-thread - 1) WFLYSRV0021: Deploy of deployment "app-authz-jee-vanilla.war" was rolled back with the following failure message:
{"WFLYCTL0080: Failed services" => {"jboss.module.service.\"deployment.app-authz-jee-vanilla.war\".main" => "WFLYSRV0179: Failed to load module: deployment.app-authz-jee-vanilla.war
Caused by: org.jboss.modules.ModuleNotFoundException: org.keycloak.keycloak-authz-client"}}
15:12:55,034 INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) WFLYSRV0028: Stopped deployment app-authz-jee-vanilla.war (runtime-name: app-authz-jee-vanilla.war) in 11ms
I tried running on docker wildfly and other example applications and worked. I don't have any experience in java. What can I do to have this app up and running?
With the command wildfly-19.1.0.Final/bin/standalone.sh, you are running keycloak on Wildfly.
Please use a different Wildfly server to host your servlet application. To communicate with the Keycloak running on the other server, you need "Keycloak OpenID Connect Client Adapter" installed into your Wildfly server which runs the servlet application.
You may use this guide to install the keycloak adapter into the wildly server. After you install this adapter into the new Wildfly, org.keycloak.keycloak-authz-client module will be available on this Wildfly.
However still there is a blocker for the latest java version [above java 11].
In my case, the WildFly not started 100% successfully. In the 'standalone.xml' file's end, there are some ports which maybe not available to you. Check for the logs, disable/move conflicting ports.

Wildfly throws UnsupportedOperationException (Naming context is read-only) on start

We're setting up a new staging server (running Ubuntu), and are encountering errors when starting WildFly. The main one seens to be
java.lang.UnsupportedOperationException: WFLYNAM0043: Naming context is read-only
which then causes many errors about missing dependencies.
We have set up our (liquibase) database on another server, which we can ssh into internally. We've scoured StackOverflow as well, and attempted to add
set "JAVA_OPTS=%JAVA_OPTS% -Dcom.sun.jersey.server.impl.cdi.lookupExtensionInBeanManager=**true**"
to our standalone.conf, standalone.bat, and standalone.conf.bat (for the sake of having tried everything!). We also saw that this should've been fixed in WildFly 7.1.1, we're running 9 ourselves (to emulate the live server).
We tried manually installing the dependencies but there are so many - and honestly we think that's just not the main issue.
We're also running nginx and Redis, we saw in the server.log (see below) that the error happens after "Started Hibernate Redis cache" but the error itself seems to be specific to WildFly.
A chunk of server.log is below:
2019-04-03 10:52:38,252 INFO [com.company.ejb.util.config.ConfigRetriever] (ServerService Thread Pool -- 56) Successfully found and read the config file at /opt/wildfly/config.yml
2019-04-03 10:52:38,300 INFO [com.company.ejb.entity.cache.RedisRegionFactory] (ServerService Thread Pool -- 56) Started Hibernate Redis cache
2019-04-03 10:52:46,896 INFO [org.jboss.weld.Event] (MSC service thread 1-2) WELD-000411: Observer method [BackedAnnotatedMethod] com.sun.jersey.server.impl.cdi.CDIExtension.processAnnotatedType(#Observes ProcessAnnotatedType<Object>) receives events for all annotated types. Consider restricting events using #WithAnnotations or a generic type with bounds.
2019-04-03 10:52:47,041 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.unit."DoThePublish.ear".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."DoThePublish.ear".WeldStartService: Failed to start service
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Caused by: org.jboss.weld.exceptions.DefinitionException: Exception List with 1 exceptions:
Exception 0 :
java.lang.UnsupportedOperationException: WFLYNAM0043: Naming context is read-only
at org.jboss.as.naming.WritableServiceBasedNamingStore.requireOwner(WritableServiceBasedNamingStore.java:161)
at org.jboss.as.naming.WritableServiceBasedNamingStore.createSubcontext(WritableServiceBasedNamingStore.java:151)
at org.jboss.as.naming.NamingContext.createSubcontext(NamingContext.java:417)
at org.jboss.as.naming.InitialContext$DefaultInitialContext.createSubcontext(InitialContext.java:298)
at org.jboss.as.naming.NamingContext.createSubcontext(NamingContext.java:425)
[...]
2019-04-03 10:52:47,078 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "DoThePublish.ear")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"DoThePublish. ear\".WeldStartService" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"DoThePublish.ear\".WeldStartService: Failed to
start service
Caused by: org.jboss.weld.exceptions.DefinitionException: Exception List with 1 exceptions:
Exception 0 :
java.lang.UnsupportedOperationException: WFLYNAM0043: Naming context is read-only
at org.jboss.as.naming.WritableServiceBasedNamingStore.requireOwner(WritableServiceBasedNamingStore.java:161)
at org.jboss.as.naming.WritableServiceBasedNamingStore.createSubcontext(WritableServiceBasedNamingStore.java:151)
at org.jboss.as.naming.NamingContext.createSubcontext(NamingContext.java:417)
at org.jboss.as.naming.InitialContext$DefaultInitialContext.createSubcontext(InitialContext.java:298)
at org.jboss.as.naming.NamingContext.createSubcontext(NamingContext.java:425)
[...]
"}}
2019-04-03 10:52:47,178 INFO [org.jboss.as.server] (ServerService Thread Pool -- 32) WFLYSRV0010: Deployed "DoThePublish.ear" (runtime-name : "DoThePublish.ear")
2019-04-03 10:52:47,186 INFO [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0183: Service status report
WFLYCTL0186: Services which failed to start: service jboss.deployment.unit."DoThePublish.ear".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."DoThePublish.ear".WeldStartService: Failed to start service
2019-04-03 10:52:47,581 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://127.0.0.1:9990/management
2019-04-03 10:52:47,582 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://127.0.0.1:9990
2019-04-03 10:52:47,582 ERROR [org.jboss.as] (Controller Boot Thread) WFLYSRV0026: WildFly Full 9.0.1.Final (WildFly Core 1.0.1.Final) started (with errors) in 42472ms - Started 4599 of 5108 services (362 services failed or missing dependencies, 209 services are lazy, passive or on-demand)
Then following that there's a bunch of missing dependencies (there's looaaaads of these):
WFLYCTL0184: New missing/unsatisfied dependencies:
service jboss.deployment.subunit."DoThePublish.ear"."CoreEjb.jar".component.AbstractEntityMainSB.CREATE (missing) dependents: [service jboss.deployment.subunit."DoThePublish.ear"."CoreEjb.jar".component.AbstractEntityMainSB.START]
service jboss.deployment.subunit."DoThePublish.ear"."CoreEjb.jar".component.AbstractEntityMainSB.START (missing) dependents: [service jboss.deployment.subunit."DoThePublish.ear"."CoreEjb.jar".moduleDeploymentRuntimeInformationStart, service jboss.deployment.subunit."DoThePublish.ear"."CoreEjb.jar".deploymentCompleteService]
service jboss.deployment.subunit."DoThePublish.ear"."CoreEjb.jar".component.AbstractEntityMainSB.VIEW."com.company.ejb.session.AbstractEntityMainSBL".LOCAL (missing) dependents: [service jboss.deployment.subunit."DoThePublish.ear"."CoreEjb.jar".component.AbstractEntityMainSB.START]
We've tried comparing the setup to the existing production (live) server, but there has been a big turnaround in the dev team so no-one knows exactly how they're set up. There are no setup instructions so we're trying things as we go along - perhaps the previous server encountered these same issues but we've no idea.
We are wanting to fix this exception to hopefully be able to start wildfly (and thus our website) without issues (or at least move on to the next error...) Any help is greatly appreciated!
So after a bunch of trying, we figured it out. The line we tried to implement needed to be changed a bit:
JAVA_OPTS="$JAVA_OPTS -Dcom.sun.jersey.server.impl.cdi.lookupExtensionInBeanManager=true"
So we removed the 'set' and removed the asterisks and stuff. In our case it was the .conf file that needed the line, I believe for different types of implementations it might be the .bat or .conf.bat - sorry I can't help further with that.
Hope this helps someone else!
I recently got this same error on startup of JBOSS EAP 7.2 and Wildfly 12. In my case, it's an old Hibernate Java application. The mapping of entities in the hibernate.cfg.xml. My problem was that someone put the name attribute in the <session-factory name="">, and that particular application goes up two contexts! On the startup of the second context, I get the error:
java.lang.UnsupportedOperationException: WFLYNAM0043: Naming context is read-only
Removing the name from the session-factory solved the problem.

Configuration file not found - JBoss7

I wanted to deploy a simple jsp application: I created and copied the myApp.war file to the $JBOSS_HOME/standalone/deployment folder.
Instead of deploying the war file , JBoss created *.war.failed ,
So I thought maybe it's a good idea to restart the jboss to see if it affects the deployment.
In some forums it was suggested to restart the JBoss through : $JBOSS_HOME/bin/jboss-cli.sh
But there was no shutdown or restart command.
While I was trying to restart , I ran the following command :
/usr/local/jboss7/bin/jboss-cli.sh -c ":shutdown(restart=true)"
JBoss stopped working , but it didn't start again.
Now , I want to start it again by :
$JBOSS_HOME/bin/standalone.sh
But it gives me the following exception :
=========================================================================
JBoss Bootstrap Environment
JBOSS_HOME: /usr/local/jboss7
JAVA: /Library/Java/JavaVirtualMachines/jdk1.7.0_71.jdk/Contents/Home/bin/java
JAVA_OPTS: -server -XX:+UseCompressedOops -XX:+TieredCompilation -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 -Djboss.server.default.config=standalone.xml
=========================================================================
17:29:43,399 INFO [org.jboss.modules] JBoss Modules version 1.1.1.GA
17:29:43,536 INFO [org.jboss.msc] JBoss MSC version 1.0.2.GA
17:29:43,567 INFO [org.jboss.as] JBAS015899: JBoss AS 7.1.1.Final "Brontes" starting
17:29:43,876 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.jar:7.1.1.Final]
at org.jboss.as.server.ServerService.boot(ServerService.java:266) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:155) [jboss-as-controller-7.1.1.Final.jar:7.1.1.Final]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_71]
Caused by: com.ctc.wstx.exc.WstxUnexpectedCharException: Unexpected character '*' (code 42) (expected a name start character)
at [row,col {unknown-source}]: [190,160]
at com.ctc.wstx.sr.StreamScanner.throwUnexpectedChar(StreamScanner.java:639)
at com.ctc.wstx.sr.StreamScanner.parseLocalName(StreamScanner.java:1798)
at com.ctc.wstx.sr.BasicStreamReader.handleNsAttrs(BasicStreamReader.java:2975)
at com.ctc.wstx.sr.BasicStreamReader.handleStartElem(BasicStreamReader.java:2926)
at com.ctc.wstx.sr.BasicStreamReader.nextFromTree(BasicStreamReader.java:2802)
at com.ctc.wstx.sr.BasicStreamReader.next(BasicStreamReader.java:1050)
at com.ctc.wstx.sr.BasicStreamReader.nextTag(BasicStreamReader.java:1125)
at org.jboss.staxmapper.XMLExtendedStreamReaderImpl.nextTag(XMLExtendedStreamReaderImpl.java:152) [staxmapper-1.1.0.Final.jar:1.1.0.Final]
at org.jboss.as.server.deployment.scanner.DeploymentScannerParser_1_1.readElement(DeploymentScannerParser_1_1.java:85)
at org.jboss.as.server.deployment.scanner.DeploymentScannerParser_1_1.readElement(DeploymentScannerParser_1_1.java:28)
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:894) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
at org.jboss.as.server.parsing.StandaloneXml.readServerElement_1_1(StandaloneXml.java:330) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:127) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:100) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
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.1.Final.jar:7.1.1.Final]
... 3 more
17:29:43,882 FATAL [org.jboss.as.server] JBAS015957: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
17:29:43,889 INFO [org.jboss.as] JBAS015950: JBoss AS 7.1.1.Final "Brontes" stopped in 4ms
I searched for the cause of the problem , and I found that probably there's a problem with standalone.xml file.
In /usr/local/jboss7/standalone/configuration/standalone_xml_history I have the following files , but not the standalone.xml
2014xxxx-xxxxxxxx
snapshot
standalone.initial.xml
current
standalone.boot.xml
standalone.last.xml
I'd like to know if I have to rename any of these files to standalone.xml ? (actually I tried renaming standalone.boot.xml to standalone.xml but it didn't work either !) or download a new one ? may I remove these xml files after having the new standalone.xml ?
If JBoss-7 is installed in $JBOSSHOME, the default standalone configuration file is $JBOSS_HOME/standalone/configuration/standalone.xml; $JBOSSHOME/standalone/configuration is the default value of the jboss.server.config.dir property; and running $JBOSSHOME/bin/standalone.sh with no options will start JBoss in standalone mode on Linux/Unix systems.
In order to use a different standalone configuration file it can be renamed to standalone.xml, put in jboss.server.config.dir if it is not already there and standalone.sh run with no options; or its file name can be given to standalone.sh as an argument to its -c option after it is put in jboss.server.config.dir, for example:
$JBoss_home/bin/standalone.sh -c standalone-full.xml
RedHat documentation for this is at https://docs.jboss.org/author/display/AS71/Command+line+parameters
I have had the best success with standalone/configuration/standalone-full.xml since it has the full configuration. It is shipped with JBoss-7. If you don't have it you could download a fresh copy of the distro to get it. What I always do is archive a zip of the distro for recovery in case something gets corrupted or lost in the working copy.

Resources