Edit standalone.xml while running WildFly 8.2 - wildfly

I have a WildFly running and an application that allow to edit database connection (ds.xml), that connection use security domain. When WildFly stopped it's work!
When WildFly is running, I can write standalone.xml and save it but automatically the standalone.xml reverts to its previous state.
Have a way to a external app to edit the standalone.xml with WildFly running?

WildFly will rewrite the configuration if there are changes to the management model. It's advised not to directly change the XML configuration file. If you need to change a setting it's best to use CLI or the web console.
Some changes don't require a reload, some do. So in some cases you can make changes at runtime and see them immediately.
If you're editing a *-ds.xml file in a deployment, then that deployment will need to be redeployed.

Related

JBOSS Logging per deployment issue

we've an application, running in JBOSS EAP 6.4, generating a lot of logs. So we decided to give the application its own log, rotating each hour.
The application uses SFL4J, which is compatible with JBOSS Logging.
As we can't change parameters on JBOSS config we decided to use the logging per deployment feature and added, following the developers manual, a file logging.properties in the classpath, with the File Handler set up as below
handler.FILE=org.jboss.logmanager.handlers.PeriodicRotatingFileHandler
handler.FILE.level=ALL
handler.FILE.formatter=PATTERN
handler.FILE.properties=append,autoFlush,enabled,suffix,fileName
handler.FILE.constructorProperties=fileName,append
handler.FILE.append=true
handler.FILE.autoFlush=true
handler.FILE.enabled=true
handler.FILE.suffix=.yyyy-MM-dd-HH
handler.FILE.fileName=${jboss.server.log.dir}\\pfl.log
While in DEV station everything works as expected (JBOSS Developer Studio 7.1.1 with JBOSS EAP 6.1), in production and test JBOSS generates correctly the pfl.log file and the hourly backups, BUT the pfl.log is never made empty. So it's growing indefinitely (and so the hourly files). Also we noted that the same behavior happens using dayly rotating logs
handler.FILE.suffix=.yyyy-MM-dd
This is getting us crazy.. How can we solve this ? Where can be the problem ? Did we make any config mistakes ?

Adding wildfly jms subsystem with wildfly cli java api without reloading the server

So we need to provision (add the jms extension/subsystem/configurations to standalone.xml) the JMS subsystem in wildfly when starting the server if it's not already provisioned and that needs to happen automatically. We have an application written in java and we chose to provision the jms subsystem with wildfly's cli java api and that is executed when our application starts deploying. The thing is we need to provision the jms subsystem and use it in the same application.
Problem is, when we add the needed configurations in standalone.xml with wildfly's cli java api, the server requires a reload but we can't reload it because our app is already deploying, it tries to use the defined queues and fails because... Well, the subsystem is not active yet. On next server restart everything is ok but as you can guess in a production environment this is unacceptable. Is there any solution to this? I've tried adding a reload cli command in the end of the batch that creates the jms subsystem and it starts reloading the server but the deployment doesn't stop and exceptions start flying left and right.
Also the whole idea of reloading the server from the app while the app is deploying seems kinda wrong to me.
Thanks in advance.
Solution:
Well the solution in the end was an easy one, we just had to add a reload step in the batch operation that adds the jms subsystem. The problem was that we had a set of async operation that all fired off when the app was deployed so i just had to make sure none of them started until i can check for the messaging subsystem and reload wildfly if necessary. That way I'm not interrupting any async tasks forcefully.
You need to select appropriate profile i.e full or full-ha while starting server only. If you do this there will not be need to add JMS subsystem.
If you want to go with your approach only, add dependency of queue in
application. It will not start deploying until and unless queue is bound to server.
we need to perform reload operation when we add new subsystem, if you dont want to perform reload operation then I will suggest you to start server in 'admin-only' mode. When we start server in 'admin-only' mode then it open only management port(9990/9999). Configure messaging subsystem through CLI command reload server instance. Hope it helps..!!

Wildfly server configuration in eclipse(STS) for hot deployment

I am configuring Wildfly server in eclipse(STS). While configuring, I noticed the following option:
Server is externally managed. Assume server is started.
What does this option do ?
Does it impact capability of hot deployment of jsps etc.
Can someone also point to a location where all these options are described in detail for Wildfly server configuration in eclipse?
"The Server is externally managed. Assume server is started" field is used when the user wants to deploy the server but does not want the IDE to stop or start the server for them. Depending on the requirements, select this check box or leave it unchecked, as is default.
http://tools.jboss.org/documentation/howto/configure_remote_server.html

Logging Level on Glassfish-3 JPA Eclipselink

How do I setup a EAR and a Glassfish Server that it shows FINE level on the development server but the same ear shows INFO level on the productive machines?
In the moment I change config in the persistence.xml every time i deploy onto the productive machines.
But s.t. i forget and the machine starts flooding the log files.
You must put in the
<jvm-options>-Declipselink.logging.level=FINE</jvm-options>
into your config.xml java-config tag on your development machine.
And do NOT put in the logging level property into the persistence.xml.
You can also set the EclipseLink log level using System properties (or you could set the log level in code using a SessionCustomizer).

JBoss 5.1.0 disabled HDScanner, undeploying post restart doesn't work

I have disabled the HDScanner bean (by removing JBOSS_HOME/deploy/hdscanner-jboss-beans.xml) in JBoss 5.1.0 so that I must do all deployments to running instances through Twiddle (applications found in the deployment directory are automatically deployed on startup).
After I have done this I can deploy and undeploy a war by using the following commands:
twiddle.sh -s localhost invoke "jboss.system:service=MainDeployer" deploy "file:/path/to/my.war"
twiddle.sh -s localhost invoke "jboss.system:service=MainDeployer" undeploy "file:/path/to/my.war"
This works fine.
However, if I restart JBoss between the deploy and the undeploy, when I try to undeploy the app using twiddle, the app remains deployed and the JBoss logs display :
2011-04-18 14:30:41,318 WARN [org.jboss.deployment.MainDeployer] (WorkerThread#0[10.21.4.61:43700]) undeploy 'file:/path/to/my.war' : package not deployed
Am I doing something wrong, expecting something that's not possible, or is this a bug in JBoss?
If I am doing something wrong, what is the correct way to undeploy an app that has been deployed using twiddle on an instance of JBoss that has been subsequently restarted?
Edit
Without looking at the source code of JBoss, it seems to me that apps that are deployed on startup are managed in a different place from those deployed through Twiddle. Ie if an app is deployed at startup it is not known of by the mechanism accessed through Twiddle, hence the "package not deployed" error.
So, is there a way to access this other deployment manager through Twiddle such that apps that are present at startup can still be undeployed?
I have done a lot of testing on this, and basically apps that are found at startup are (rightly) considered to be part of the JBoss 'core' and are therefore deployed automatically as part of the startup process. This applies for things such as the jmx-console, and therefore applies for other .wars too. Whether through design or through consequence, these resources that have been automatically deployed during startup cannot be managed by twiddle invokations.