I have downloaded jBPM 7.37.0.Final server (single zip) distribution from https://www.jbpm.org/learn/gettingStarted.html. Installed in Ubuntu machine.
I have made one change in standalone.xml file in section just to point postgres database intead of H2.
I am using business-central for JBPM deployments.
http://localhost:8080/business-central/kie-wb.jsp
I simply added case project then i added a case definition.
But Process designer not showing case management option. See below image.Without Case management Option
I have already set below parameters for case,
i)runtime strategy to Per Case
ii)configure marshallers for case file and documents
ii)created WorkDefinition.wid files in the project and its packages to ensure case related nodes (e.g. Milestone) are available in palette.
But still it is not showing case management option.Please help here.
I got the solution.
In the case definition properties set Ad-hoc process property to true, save case, close and reopen.
Related
We are in process of upgrading Sitecore 6.6 to 7.2. Part of upgrade is to migrate all the media items from 6.6 to 7.2.
I tried creating a package but the package size is too large and times out on package installation.
I found link below using Powershell Console where it shows copy-item command:
http://blog.najmanowicz.com/2011/11/18/sample-scripts-for-sitecore-powershell-console
I attached the 6.6 to 7.2 version where I can access the 6.6 DB. However copy-item doesn't seem to support different databases.
Could someone please help how I can use SiteCore Powershell or similar to migrate media items from 6.6 to 7.2?
I had a similar issue with a (very large) media library with a similar migration. Packages seems to bomb out around the 2GB mark, instead serialize the items:
Delete everything from /Data/Serialization
Open the media library. Makes sure you have the Developer tab
showing (right click somewhere on the toolbar and enable it
otherwise)
Select your root media item then Serialize Tree
Wait...
Copy the serialized files from /Data/Serialization to your new
server
From the toolbar select Update or Revert Tree depending on your requirements
Profit.
You can find more info in the Sitecore Serialization Guide and this post by Brian Pedersen
You should be able to do this in Powershell too (from my understanding). You need to:
Add the database to your connectionString.config
Add that database to your web.config to <sitecore><databases><database>. You can copy the existing master node and rename the id attribute to match your conneciton name
Your legacy database should now be connected to Sitecore interface, you can check it is present in the database selector list from the right of the desktop
The powershell command now needs a "from" and "to" location. Assume your database is called "legacy_master", the following should work:
copy-item "master:\media library\*" "legacy_master:\media library\"
I've found Hedgehog TDS (and sometimes Razl) quite useful for doing this.
Create a new TDS project (don't version control it), and download all the items you need to your local machine. You can for example connect the "Debug" build to your source 6.6 instance, and a "Release" build to your target 7.2 instance. Then you can just synchronize the items to your target machine. It's sometimes good to synchronize one or a few branches at a time if you have long latency connections.
The good thing about this is that you're in total control of your content and can see what fields are updated etc. During an update process, it's sometimes useful to compare other parts of the db as well, just to ensure you don't miss any changes you've made to the platform.
Since I mentioned Razl as well: I've found Razl quite good if you have a whole branch that you know should be transferred from one db to another (such as the case you describe). TDS is a bit slower, but more universal - and you may have a TDS license already so it may not be worth an additional Razl license.
I've just added item transfer from one DB to another so you can Copy-item between databases starting with Sitecore PowerShell Extensions 3.0. Thanks for the great idea!
Just to add another option you can perform tasks like this using Revolver.
WARNING: Try this in a test environment first
if we assume that:
the context item is the media library item
the current database is master
the target database is called master72
then something like this should work:
cp -r -n master72/sitecore/
I am trying to use eclipse kepler for Java EE 7.I already installed JBoss Tools and added JBoss Wildfly successfully as a server. However my changes are not automatically deployed. Is there anyway the app can be deployed automatically just as when using glassfish?
Using Eclipse, click twice on your WildFly Server to edit the following properties:
Publishing: choose "Automatically publish after a build event". I like to change the publishing interval to 1 second too.
Application Reload Behavior: check the "Customize application reload ..." checkbox and edit the regex pattern to \.jar$|\.class$
That's it. Good luck!
Both #varantes and #Sean are essentially correct, but these answers are not full.
Unfortunately the only way in a Java server environment to have full, zero-downtime hot deployment is to use paid JRebel or free spring-loaded tool.
But for small project there are some ways to speed up work by partial hot-deployment. Essentially:
When enabled option Automatically publish when resource change
then changes inside *.html, *.xhtml files are immediately
reflected as soon as you refresh the browser.
To make hot deployment work for *.jsp files too, then you should
inside ${wildfly-home}/standalone/configuration/standalone.xml
make following change:
<jsp-config/>
replace with:
<jsp-config development="true"/>
restart the server and enjoy hot deployment of web files.
But when modifying *.java source files, then only partial hot deployment is possible. As #varantes stated in his answer, enabling Application Reload Behavior with regex pattern set to \.jar$|\.class$ is an option, but has serious downside: whole module is restarted, thus:
It takes some time (depending on how big is a module).
Whole application state is lost.
So personally, I discourage this solution. JVM supports (in debug mode) code-swapping for methods' bodies. So as long as you are modifying only bodies of existing methods, you are at home (zero downtime, changes are reflected immediately). But you have to disable automatic publishing inside server settings otherwise the application's state will still be destroyed by that republish.
But if you are heavily crafting Java code (adding classes, annotations, constructors) then unfortunately I can only recommend set publishing into Never publish automatically (or shutdown server) and when you finish your work in Java files, then restart by hand your module (or turn-on server). Up to you.
It works for small Java projects, but for bigger ones, JRebel is invaluable (or just spring-loaded), because all approaches described above are not sufficient. Also because of such problems, solutions like Rails/ Django /Play! Framework gained so huge popularity.
I am assuming you are using the latest version of Wildfly (8.0 Beta 1 as of writing).
In the standalone.xml config file, look for <jsp-config/>. Add the attribute development="true" and it should hot-deploy. The resulting config will look like this:
<jsp-config development="true"/>
Add attributes (development, check-interval, modification-test-interval, recompile-on-fail) in configuration file in xPath = //servlet-container/jsp-config/
<servlet-container name="default" default-buffer-cache="default" stack-trace-on-error="local-only">
<jsp-config development="true" check-interval="1" modification-test-interval="1" recompile-on-fail="true"/>
</servlet-container>
(It works in WildFly-8.0.0.Final)
Start server in debug mode and It will track chances inside methods. Other changes It will ask to restart the server.
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 been trying to figure this out and so far haven't found a simple solution. Is it really that hard to deploy a database project (and a web site) using TFS 2010 as part of the build process?
I've found one example that involved lots of complicated checks and editing the workflow (which is a giant workflow btw).
I've even purchased the book "professional application lifecycle management with VS 2010", but apparently professionals don't deploy their applications since it isn't even mentioned in the book.
I know I'm retarded when it comes to TFS, but it seems like there should be any easy way to do this. Is there?
I can't speak for the database portion, but I just went through this on the web portion, the magic part is not very well documented component, namely the MSBuild Parameters.
In your build definition:
Process on the Left
Required > Items to Build > Configurations to Build
Edit, add a new one, for this example
Configuration: Dev (I cover how to create a configuration below)
Platform: Any CPU
Advanced > MSBuild Process
Use the following arguments (at least for me, your publish method may vary).
MsBuild Params:
/p:MSDeployServiceURL="http://myserver"
/p:MSDeployPublishMethod=RemoteAgent
/p:DeployOnBuild=True
/p:DeployTarget=MsDeployPublish
/p:CreatePackageOnPublish=True
/p:username=aduser
/p:password=adpassword
Requirements:
You need to install the MS Deploy Remote Agent Service on the destination web server, MSDeploy needs to be on the Build/Deployer server as well, but this should be the case by default.
The account you use in the params above needs admin access, at least to IIS...I'm not sure what the minimum permission requirements are.
You configure which WebSite/Virtual Directory the site goes to in the Web project you're deploying. Personally I have a build configuration for each environment, this makes the builds very easy to handle and organize. For example we have Release, Debug and Dev (there are more but for this example that's it). Only the Web project has a Dev configuration.
To do this, right click the solution, Configuration Manager..., On the web project click the configuration drop down, click New.... Give it a name, "Dev" for this example, copy settings from debug or release, whatever matches closest to what your deployment server environment should be. Make sure "Create new solution configurations" is checked, it is by default. After creating this, change the configuration dropdown on the solution to the new Dev one, and Any CPU...make sure your projects are all correct, I had some flipping to x86 and x64 randomly, not sure of the exact cause of that).
In your web project, right click, properties. On the left, click Package/Publish Web (you'll also want to mess with the other Package/Publish SQL tab, but I can't speak to that). In the options on the right click Create deployment package as a zip file. The default location is fine, the next textbox I didn't find documented anywhere. The format is this: WebSite/Virtual Directory, so if you have a site called "BuildSite" in IIS with no virtual directory (app == site root), you would have BuildSite only in this box. If it was in a virtual directory, you might have Default Web Site/BuildVirtualDirectory.
After you set all that, make sure to check-in the solution and web project so the build server has the configuration changes you made, then kick off a build :)
If you have more questions, I recommend you watch this video by Vishal Joshi, specifically around 22 and 59 minutes in, he covers the database portion as well...but I have no actual experience trying it since we're on top of a non MSSQL database.
I'm trying to customize the location of the user.config file. Currently it's stored with a hash and version number
%AppData%\[CompanyName]\[ExeName]_Url_[some_hash]\[Version]\
I want to it be agnostic to the version of the application
%AppData%\[CompanyName]\[ProductName]\
Can this be done and how? What are the implications? Will the user lose their settings from the previous version after upgrading?
I wanted to add this quoted text as a reference for when i have this problem in the future. Supposedly you can instruct the ApplicationSettings infrastructure to copy settings from a previous version by calling Upgrade:
Properties.Settings.Value.Upgrade();
From Client Settings FAQ blog post: (archive)
Q: Why is there a version number in the user.config path? If I deploy a new version of my application, won't the user lose all the settings saved by the previous version?
A: There are couple of reasons why the
user.config path is version sensitive.
(1) To support side-by-side deployment
of different versions of an
application (you can do this with
Clickonce, for example). It is
possible for different version of the
application to have different settings
saved out.
(2) When you upgrade an
application, the settings class may
have been altered and may not be
compatible with what's saved out,
which can lead to problems.
However, we have made it easy to
upgrade settings from a previous
version of the application to the
latest. Simply call
ApplicationSettingsBase.Upgrade() and
it will retrieve settings from the
previous version that match the
current version of the class and store
them out in the current version's
user.config file. You also have the
option of overriding this behavior
either in your settings class or in
your provider implementation.
Q: Okay, but how do I know when to
call Upgrade?
A: Good question. In Clickonce, when
you install a new version of your
application, ApplicationSettingsBase
will detect it and automatically
upgrade settings for you at the point
settings are loaded. In non-Clickonce
cases, there is no automatic upgrade -
you have to call Upgrade yourself.
Here is one idea for determining when
to call Upgrade:
Have a boolean setting called
CallUpgrade and give it a default
value of true. When your app starts
up, you can do something like:
if (Properties.Settings.Value.CallUpgrade)
{
Properties.Settings.Value.Upgrade();
Properties.Settings.Value.CallUpgrade = false;
}
This will ensure that Upgrade() is
called only the first time the
application runs after a new version
is deployed.
i don't believe for a second that it could actually work - there's no way Microsoft would provide this ability, but the method is there just the same.
To answer the first question, you technically can put the file wherever you want, however you will have to code it yourself, as the default place the file goes to is the first of your two examples. (link to how to do it yourself)
As for the second question, it depends on how you deploy the application. If you deploy via a .msi, then there are two hashes in the properties of the setup project (that the msi is built from), the 'upgrade code' and the 'product code'. These determine how the msi can be installed, and if it upgrades, overwrites, or installs beside any other version of the same application.
For instance, if you have two versions of your software and they have different 'upgrade' codes, then to windows they are completely different pieces of software regardless of what the name is. However if the 'upgrade' code is the same, but the 'product' code is different then when you try to install the 2nd msi it will ask you if you want to upgrade, at which time it is supposed to copy the values from the old config to a new config. If both values are the same, and the version number didn't change then the new config will be in the same location as the old config, and it won't have to do anything. MSDN Documentation
ClickOnce is a little bit different, because its based more off of the ClickOnce version # and URL path, however I have found that as long as you continue to 'Publish' to the same location the new version of the application will continue to use the existing config. (link to how ClickOnce handles updates)
I also know there is a way to manually merge configs during the install of the msi using custom install scripts, but I don't remember the exact steps to do it... (see this link for how to do it with a web.config)
The user.config file is stored at
C:\Documents and Settings>\<username>\[Local Settings\]Application Data\<companyname>\<appdomainname>_<eid>_<hash>\<version>
<C:\Documents and Settings> is the user data directory, either non-roaming (Local Settings above) or roaming.
<username> is the user name.
<companyname> is the CompanyNameAttribute value, if available. Otherwise, ignore this element.
<appdomainname> is the AppDomain.CurrentDomain.FriendlyName. This usually defaults to the .exe name.
<eid> is the URL, StrongName, or Path, based on the evidence available to hash.
<hash> is a SHA1 hash of evidence gathered from the CurrentDomain, in the following order of preference:
1. StrongName
2. URL:
If neither of these is available, use the .exe path.
<version> is the AssemblyInfo's AssemblyVersionAttribute setting.
Full description is here http://msdn.microsoft.com/en-us/library/ms379611.aspx
(I'd add this as a comment to #Amr's answer, but I don't have enough rep to do that yet.)
The info in the MSDN article is very clear and appears to still apply. However it fails to mention that the SHA1 hash is written out base 32 encoded, rather than the more typical base 16.
I believe the algorithm being used is implemented in ToBase32StringSuitableForDirName, which can be found here in the Microsoft Reference Source.