There's the 3rd-party application bpm.ear that contains the ancient commons-net.jar in its /bpm.war/WEB-INF/lib/.
I need to globally override it with my own version of the jar without patching the files inside the deployment. That is, make this change survive undeployment of the app.
Formerly, when we were using JBoss 4x this was solved by setting the $CLASSPATH env. var before starting the server. Of course, this doesn't work in Wildfly 11.
I want to create a custom module inside ${JBOSS_HOME}/modules (already done) and to create a simple rule to implicitly add this module to all apps deployed on this server.
You can use https://wildscribe.github.io/WildFly/16.0/subsystem/ee/#attr-global-modules to define a list of modules that should be made available to all deployments.
Related
We know that during Tomcat startup, it will deploy the .war files of its web applications. My question is after the deployment I need to run a command to modify a file inside WEB-INF/ of the web application which is generated after deployment, and I need to let Tomcat do this automatically for me, is this possible to achieve ? Something like post_run command after deployment.
I found that CustomEventHookListener can probably do this How to run script on Tomcat startup?, but this involves in making a new Java class, and I'm not allowed to do so. I have to figure out way to modify the existing Tomcat configs like server.xml or tomcat.conf in TOMCAT_HOME/conf to do so.
The main issue about not using a Event Hook Listener is that there's no reliable way to tell if the application is ready or not, as Catalina implements it's own lifecycle for each of their components (as seen in https://tomcat.apache.org/tomcat-8.5-doc/api/org/apache/catalina/Lifecycle.html).
Your best shot is to use tail or some external program infer the component's state, but AFAIK there's no way to implement listeners directly in the configuration files.
I am wondering if there is a way to pass a value for RAILS_ENV directly into the Torquebox server without going through a deployment descriptor; similar to how I can pass properties into Java with the -D option.
I have been wrestling with various deployment issues with Torquebox over the past couple weeks. I think a large part of the problem has to do with packaging the gems into the Knob file, which is the most practical way for managing them on a Window environment. I have tried archive deployment and expanded deployment; with and without external deployment descriptor.
With an external deployment descriptor, I found the packaged Gem dependencies were not properly deployed and I received errors about missing dependencies.
When expanded, I had to fudge around a lot with the dependencies and what got included in the Knob, but eventually I got it to deploy. However, certain files in the expanded Knob were marked as failed (possible duplicate dependencies?), but they did not affect the overall deployment. The problem was when the server restarted, deployment would fail the second time mentioning it could not redeploy one of the previously failed files.
The only one I have found to work consistently for me is archive without external deployment descriptor. However, I still need a way to tell the application in which environment it is running. I have different Torquebox instances for each environment and they only run the one application, so it would be fairly reasonable to configure this at the server level.
Any assistance in this matter would be greatly appreciated. Thank you very much!
The solution I finally came to was to pass in RAILS_ENV as a Java property to the Torquebox server and then to set ENV['RAILS_ENV'] to this value in the Rails boot.rb initializer.
Step 1: Set Java Property
First, you will need to set a Rails Environment java property for your Torquebox server. To keep with standard Java conventions, I called this rails.env.
Dependent on your platform and configuration, this change will need to be made in one of the following scripts:
Using JBoss Windows Service Wrapper: service.bat
Standalone environment: standalone.conf.bat (Windows) or standalone.conf (Unix)
Domain environment:: domain.conf.bat (Windows) or domain.conf (Unix)
Add the following line to the appropriate file above to set this Java property:
set JAVA_OPTS=%JAVA_OPTS% -Drails.env=staging
The -D option is used for setting Java system properties.
Step 2: Set ENV['RAILS_ENV'] based on Java Property
We want to set the RAILS_ENV as early as possible, since it is used by a lot of Rails initialization logic. Our first opportunity to inject application logic into the Rails Initialization Process is boot.rb.
See: http://guides.rubyonrails.org/initialization.html#config-boot-rb
The following line should be added to the top of boot.rb:
# boot.rb (top of the file)
ENV['RAILS_ENV'] = ENV_JAVA['rails.env'] if defined?(ENV_JAVA) && ENV_JAVA['rails.env']
This needs to be the first thing in the file, so Bundler can make intelligent decisions about the environment.
As you can see above, a seldom mentioned feature of JRuby is that it conveniently exposes all Java system properties via the ENV_JAVA global map (mirroring the ENV ruby map), so we can use it to access our Java system property.
We check that ENV_JAVA is defined (i.e. JRuby is being used), since we support multiple deployment environments.
I force the rails.env property to be used when present, as it appears that *RAILS_ENV* already has a default value at this point.
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.
I'm developing an extensible application with MEF. The application will have many types of plugins to collect and process data in different ways.
I'm thinking about building a versioned online repository for the plugins, that will enable the user to download new versions of the plugins when they become available.
It would be nice if MEF could load different versions of the same plugin simultaneously, though from what I understand this isn't possible (correct me if I'm wrong).
So I've resigned myself to the fact I will need to update the plugin and archive the previous version.
What would be the best strategy for doing this?
Example 1
The Application downloads a new version of a loaded running plugin. I can't place the plugin in the plugin directory as there is already DLL with the same name. So I could rename the new plugin with a version suffix. I can't load the same assembly, so I guess I'll have to force a restart. So on restart, it achieves the old plugin and loads the new one.
--- This seems solutions seems a little messy
Example 2
The Application downloads a new version of a loaded running plugin.
The plugin is encased in some type of installer.
The installer closes the host gracefully and archives the existing plugin.
The installer installs new plugin and restarts the host app.
--- this also seems a little messy
I am seeking any correction of my assumptions, or any insight into a successful strategy to my achieve my goal.
The .NET Framework has a fearure called Shadow Copy which allows you to update loaded assebmlies. Basically it copies the assemblies to a temp folder and loads them from there. This way the assemblies located in your application's installation folder will not be locked by the OS and you will be able to replace them. ASP.NET, unit test framweorks and many other applications use shadow copying.
To enable this feature you will need to load your application in a new AppDomain since you cannot enable shadow copying on the main AppDomain. You can create a simple loader that will create an AppDomain and execute your application there. This is very straight forward. For an example of MEF + Shadow Copy have a look at Glenn Block's Way of MEF and in particullar the PartUpdatesInPlace sample.
Now as far as versioning is concerned you will need to be able to have two or more versions of an assembly loaded at the same time in the same application domain. There are two ways to do this:
Strong named assemblies in the GAC.
Assemblies with the version included in their name (like Plugin.v1.dll). Strong naming is optional in this case but a good idea nonetheless. The advantage of this approach is that two or more versions of a plugin can coexist in the same directory.
Have a look at this answer for an example of MEF + Versioning.
You can even use the recomposition feature of MEF and have your plugin container updated after:
A new plugin assembly is added
A plugin assembly is deleted
A plugin assembly is replaced
Have a look at this question for an example.
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.