I've installed jBPM 4.4 and it looks neat. I've edited a little example process using Signavio, and I'd like to deploy it on the demo server (ant demo.setup.jboss) so that I can see how it works. But I can't figure out how to do that.
I feel like I'm missing something obvious...
Is the .jpdl.xml file all you need for a very basic deployment? Is there a tutorial going through every step of defining a process and deploying it?
Thanks!
you can specify the path where signavio stores the files in the web.xml directory by setting the fileSystemRootDirectory context-param. Then use the jbpm-console to deploy the process from the same directory
Related
we are currently using a powershell script (~800 lines of code) to deploy an asp.net website, setting up the databases and modifying some xml nodes / text files. Can we use the wix toolset to do that? I am not very familiar with it. Or is it possible to copy our installation folder to the target system and executing the powershell file on it, using the wix toolset?
Yes, WIX can handle this.
You can start with this tutorial that includes enabling feature in IIS, installing website and change config files.
Just had a similar question / problem. My problem was that I couldn't get a powershell script working. I wrote a guide over here that migth help you. Feel free to ask if you need further assistance! :)
I'm attempting to deploy to a server via Capistrano and I keep getting the error the task `staging:symlink' does not exist.
I've run cap:deploy setup and cap deploy successfully getting the releases and shared directories created but the above error always shows at the end and I think it's stopping my code from getting moved to the root of the directory where it belongs.
I'm new at using Capistrano and I've Googled the issue but I cannot find anything that helps. I can include my code and everything I just don't know what to show to help... let me know!
Thanks for any help you can provide!
The built-in symlink task for capistrano 2.x is cap deploy:symlink.
staging:symlink is not a valid task, unless you've defined it yourself. If you're not defining this, you are accidentally calling it somewhere in your config files (deploy.rb or one of your staging config files, if you're using multistage).
Additionally, deploy:symlink should be called automatically as part of the deploy task. You don't need to call it manually.
I'm sorry if this question annoys you. I've written an EJB-based application and now I want to deploy it as a single Exe file (not a War file). That means if that Exe file's executed, all related things such as the web server, the database server, ... will be automatically installed to enable my application run smoothly. The JIRA installer's a typical example (http://www.atlassian.com/try).
I've googled a lot but I can't find the right answer. Would you please tell me how I can achieve that?
Glassfish has a embedded Java ee container: http://embedded-glassfish.java.net That will allow you to embedd a Webserver and database into your app (infact a complete Java EE container).
The next step would be to embedd a a java-runtime and bundle it with above as an exe. I havnt tried that. But start with the above step and see if it is enough, then start by reading about this: Embed a JRE in a Windows executable?
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've got a nant build script (.86 beta) and it is telling me this:
BUILD FAILED
Failed to initialize the 'Microsoft
.Net Framework 2.0' target
framework.
The process cannot access the file
'C:\Users\cconway\AppData\Local\Temp\tmp25E3.tmp'
because it is being used by another
process.
This file does not even exist on my machine. Does anyone know the cause of this? Rebooting seems to allow me to run the script once successfully, but every time after that I get this message (though the name of the tmp file changes per reboot).
Thanks!
Are there any third-party tasks which might leave temp files open or keep running in the background, thus leaving file locked?
Maybe try sysinternals process monitor which will allow you to see the process which has the handle on this file.
Also, make sure that you have all the right versions of .Net installed and they are the correct ones (SDK vs Runtime). If you open the config file for nant you can see where it expects the .net version to be go check to make sure it's there and that you can see hte compiler methods (csc, vbc, etc). So it could have something that is trying to find it but it's not there or the pathing is off.
It is beta so there could even be a typo in the config file.
The answer is my anti-virus. I should have tried disabling that first! Once I disabled it, everything worked like a charm.
Hope this helps someone.