I am using Keycloak4.8.3 with JBoss EAP 7.2.2. Therefore I installed the adapter keycloak-wildfly-adapter-dist-4.8.3 on JBoss
As to the documentation I executed the command line
$ ./bin/jboss-cli.sh --file=bin/adapter-elytron-install-offline.cli
But it only modifies the standalone.xml. This is ok for my local environment.
My customer is running in domain mode and therefore the changes have to exist in domain.xml. Is there a way to automate modifying the domain.xml? I want to avoid copying the changes manually.
First you might have to know which profile your JBoss is running with.
Then edit adapter-elytron-install-offline.cli, for every occurrence of /subsystem, prepend with /profile=<your-profile-name>
The use jboss-cli.bat along with the newly edited cli file to modify the domain mode configuration as you previously did.
Related
How can I check this in the deployment.xml in Websphere. So when I deploy my application this is already checked.
The name of the XML attribute is "backgroundApplication" (it's not in there by default, as it defaults to "false"); however, deployment.xml is generated by WebSphere at deployment time, so you can't specify this setting prior to deployment.
If you script your application install through wsadmin, you could update your script to add a call to update the setting after the call to install the app. That will get the setting modified right away as part of your deployment process.
I was wondering if anyone could help me out. I recently installed Liferay 6.1.2 on our JBoss 7.2.0. No problems with setting up the environment. Documentation was really helpful. But now I'm not making any progress with deploying themes and portlets.
Control Panel > Server > Plugin Installations is not providing any upload functions. Only lists of portlets, themes ans templates respectivly and a hint that Liferay marketplace will take over some day.
Letting the JBoss take care of the deployments doesn't work either. This would be my favored solution, but portlet deployments failed because some liferay classes are missing. Tried to deploy a theme afterwards, which didn't result in errors, but this theme was not available for pages in Liferay. Is letting the JBoss take care of the deployments an option anyway? After all portlets cannot run outside of a portal-environment.
My last try so far was using an auto deploy directory. But since our JBoss is running in domain mode instead of standalone, it seems this is not an option. JBoss log states that the deployment-scanner subsystem can only be installed in standalone mode, not in domain mode.
Has anyone extirienced similar problems and can provide a solution or some helpful tips? Or maybe there is an other solution that I haven't tought of so far. Anyway, I looking forward to hearing from you ;-) Thanks in advance.
Regards
Sebastian
Liferay's "Hot Deploy" process ensures that plugins use the correct versions of Liferay libraries, matching the currently installed portal. If your server does not support hot-deployment, there's another, recommended way to inject these settings and libraries. Look at these properties:
#
# Set this to true to enable auto deploy of layout templates, portlets, and
# themes.
#
auto.deploy.enabled=true
#
# Set the directory to scan for layout templates, portlets, and themes to
# auto deploy.
#
auto.deploy.deploy.dir=${liferay.home}/deploy
#
# Set the directory where auto deployed WARs are copied to. The application
# server or servlet container must know to listen on that directory.
# Different containers have different hot deploy paths. For example, Tomcat
# listens on "${catalina.base}/webapps" whereas JBoss listens on
# "${jboss.home.dir}/deploy". Set a blank directory to automatically use the
# application server specific directory.
#
auto.deploy.dest.dir=
auto.deploy.default.dest.dir=../webapps
auto.deploy.geronimo.dest.dir=${org.apache.geronimo.home.dir}/deploy
auto.deploy.glassfish.dest.dir=${com.sun.aas.instanceRoot}/autodeploy
auto.deploy.jboss.dest.dir=${jboss.home.dir}/standalone/deployments
auto.deploy.jetty.dest.dir=${jetty.home}/webapps
auto.deploy.jonas.dest.dir=${jonas.base}/deploy
auto.deploy.resin.dest.dir=${resin.home}/webapps
auto.deploy.tomcat.dest.dir=${catalina.base}/webapps
auto.deploy.weblogic.dest.dir=${env.DOMAIN_HOME}/autodeploy
auto.deploy.websphere.dest.dir=${env.USER_INSTALL_ROOT}/wsadmin-deploy
You can override these in portal-ext.properties. Configure your JBoss to listen to any directory, here ${liferay.home}/deploy, and configure its dest dir to somewhere else: auto.deploy.jboss.dest.dir=${liferay.home}/for-installation-on-jboss. Then package the resulting content of the dest.dir as *.war or *.ear file and deploy this as usual on your JBoss server. This one will contain all settings and libraries required.
Make sure that ${liferay.home}/for-installation-on-jboss exists before you try to "deploy" to it.
Can I make jboss load system properties from a file without writing any explicit code for it?
Yes you can.
In JbossAS versions prior to 7.x there is PropertiesService. It's dead simple to use. I am using it with JBoss 5.1.0.GA, and it works like a charm.
Unfortunatelly PropertiesService mbean is absent in JBossAS 7.x, but there are other ways as described in official admin guide.
Here is another solution. Post author claims it's possible to list your properties files in command line while starting server instance:
./standalone.sh --properties=1.properties --properties=2.properties
and their contents should be added to System Properties.
Documentation says if you have a context file here:
$CATALINA_HOME/conf/Catalina/localhost/myapp.xml
it will NOT be replaced by a context file here:
mywebapp.war/META-INF/context.xml
It is written here: http://tomcat.apache.org/tomcat-6.0-doc/config/context.html
Only if a context file does not exist for the application in the $CATALINA_BASE/conf/[enginename]/[hostname]/, in an individual file at /META-INF/context.xml inside the application files.
But everytime I re-deploy the war it replaces this myapp.xml with the /META-INF/context.xml!
Why does it do it and how can I avoid it?
Thanx
Undeploy part of redeploy deletes app and the associated context.xml.
If you use maven tomcat plugin you can avoid deleting context.xml if you deploy your app with command like this:
mvn tomcat:deploy-only -Dmaven.tomcat.update=true
More info here: https://tomcat.apache.org/maven-plugin-2.0-beta-1/tomcat7-maven-plugin/deploy-only-mojo.html
You can use deploy-only with parameter mode to deploy the context.xml too.
The short answer:
Just make the TOMCATHOME/conf/Catalina/localhost dir read-only, and keep reading for more details:
For quick deployment mode (Eclipse dynamic web project, direct Tomcat
connection, etc.) on a local/non-shared Tomcat server you can just define your JDBC datasource (or any
other 'web resource') using the META-INF/context.xml file inside the
WAR file. Easy and fast in your local environment, but not suitable for staging, QA, or
production.
For build deployment mode (usually for staging, QA, or prod), JDBC
datasources and other 'web resources' details are defined by the
QA/production team, not the development team anymore. Therefore, they
must be specified in the Tomcat server, not inside the WAR file
anymore. In this case, specify them in the file
TOMCATHOME/conf/Catalina/localhost/CONTEXT.xml (change Catalina
by the engine, and localhost by the host, and CONTEXT by your context accordingly). However,
Tomcat will delete this file on each deployment. To prevent this
deletion, just make this dir read-only; in Linux you can type:
chmod a-w TOMCATHOME/conf/Catalina/localhost
Voila! Your welcome.
The long answer
For historical reasons Tomcat allows you to define web resources (JDBC datasources, and others) in four
different places (read four different files) in a very specific order of precedence, if you happen to define the same resource multiple times. The ones named in the
short answer above are the more suitable nowadays for each purpose, though you could still
use the others (nah... you probably don't want to). I'm not going to
discuss the other ones here unless someone asks for it.
On tomcat7, also woth autoDeploy=false the file will be deleted on undeploy. This is documented and not a bug (althought it avoids good automated deployments with server-side fixed configuration).
I found a workaround which solved the problem for me:
create a META-INF/context.xml file in your webapp that contains
on the Server create a second context "/config-context" in server.xml and put all your server-side configuration parameters there
on the application use context.getContext("/config-context").getInitParameter(...) to access the configuration there.
This allows a per-host configuration that is independent of the deployed war.
It should also be possible to add per-context configurations by adding contexts like "/config-context-MYPATH". In your app you can use the context path oth the app to calculate the context path of the config app.
According to the documentation (http://tomcat.apache.org/tomcat-8.0-doc/config/automatic-deployment.html#Deleted_files) upon redeploy tomcat detects the deletion (undeploy) of your application. So it will start a cleanup process deleting the directory and xml also. This is independent of auto deployment - so it will happen upon redeployment through manager and modification of war also. There are 3 exceptions:
global resources are never deleted
external resources are never deleted
if the WAR or DIR has been modified then the XML file is only deleted
if copyXML is true and deployXML is true
I don't know why, but copyXML="false" deployXML="false" won't help.
Secondly: Making the directory read only just makes tomcat throwing an exception and won't start.
You can try merging your $CATALINA_BASE/conf/Catalina/localhost/myapp-1.xml, $CATALINA_BASE/conf/Catalina/localhost/myapp-2.xml, etc files into $CATALINA_BASE/conf/context.xml (that works only if you make sure your application won't deploy its own context configuration, like myapp-1.xml)
If someone could tell what is that "external resources" that would generally solve the problem.
The general issue as described by the title is covered by Re-deploy from war without deleting context which is still an open issue at this time.
There is an acknowledged distinction between re-deploy which does not delete the context, and deploy after un-deploy where the un-deploy deletes the context. The documentation was out of date, and the manager GUI still does not support re-deploy.
Redeployment means two parts: undeployment and deployment.
Undeployment removes the conf/Catalina/yourhost/yourapp.xml because the
<Host name="localhost" appBase="webapps" unpackWARs="true"
autoDeploy="true"> <!-- means autoUndeploy too!!! -->
</Host>
Change the autoDeploy="false" and Tomcat has no order anymore to remove the conf/Catalina/yourhost/yourapp.xml.
There is an feature that allowes us to make those steps (undeploy/deploy) as one single step (redeploy) that do not remove the context.xml. This feature is available via the manager-text-interface, but the option is not available using the manager-html-interface. You might have to wait until the bug in tomcat is fixed. You can use the method described in this answer as an workaround.
I need a windows shell script which will redeploy my .ear file. I wrote one:
net stop "JBAS50SVC"
copy /y O:\TEMP\app.ear C:\jboss-4.2.3.GA\server\default\deploy\app.ear
net start "JBAS50SVC"
But the problem is that when I try to stop the JBoss service it does not fully unload itself (my suggestion), so when I start it there's no app deployed in JBoss.
You mentioned that JBoss becomes very slow when you use autoDeploy and keep the server running for a month or more. That's likely to be because your permanent generation memory is filling up over time. See this related question.
I think you'd be best served by using the autoDeploy feature as other suggest, and restarting the entire server periodically to clear out PermGen. There's several ways to track PermGen utilization; I add the following to JAVA_OPTS in run.conf:
-XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC -XX:+PrintTenuringDistribution -Xloggc:$LOGDIR/gc.log
Typically to redeploy an application that is self-contained in an ear in jboss just requires replacing the ear. If there is more to the application (such as classes that have to go in the jboss lib directory) then it may require a restart.
In terms of how to restart it, it depends what you are using to start jboss as a service. Some service starters do not actually control the jvm after they start it, so restarting the service just starts a second instance. You can shutdown jboss with the shutdown script in the JBOSS_HOME/bin directory (shutdown.bat) and then deploy and restart the service. Be sure to pause when you do this, as the shutdown command will issue the shutdown request, the server may still be running.
You can just COPY/RENAME the EAR file to deploy directory. JBoss will automatically take care of re-deployment for you.
As mentioned earlier jboss automatically deploys everything you copy into the deploy directory by default.
If not, check if you are working on a vhost that doesnt autodeploy ear files.
<Host name="vhost2" autoDeploy="false" .... />
other than that, I feel like this is a totally different error due to the fact that jboss takes care of deployment for you. Please check the log files for startup errors of your application.
You might want to check the JBoss community wiki on this, there are undoubtedly easier and more reliable methods than a batch file.
Stopping the server should not undeploy the application - that wouldn't make much sense.