How can I upgrade activeMQ version?
May I save kahdb, conf and lib folder from the old version and replace in the new version?
Thanks.
It depends a bit on which versions are involved.
Generally:
* Install the new version, copy the Kahadb-files
* Copy conf folder
* Copy any custom libs, webapps, plugins etc that you installed manually
* Check all release notes for versions between "old" and "new". It will state any major changes you will need to account for. Examples: ObjectMessage security issues, Java 8 requirement, JDBC table changes, etc.
Regarding the conf, "activemq.xml", you should really go through the configuration and compare to the new version. Sometimes new features, configuration and default settings are introduced that you want to use in your custom config as well. If you are using config OOTB, this is easy, buy may be a bit harder with heavily modified activemq.xml configurations.
Related
We're making a project that is primarily a Windows Service EXE.
We're using WIX (with heat) to create an installer, that creates the relevant files and registers the EXE with Windows Services.
We've got to the point of implementing the installer upgrade logic, which largely JustWorks(TM) by setting the Version attribute of the Product tag in the .wxs file.
One issue that I can't see how to manage is the config files of the tool.
The tool has various config settings that can be modified from within the tool.
We're using ASP.NET, which has built in settings/config management, and the config settings that get changed are declared as "User" settings. When we run the save the config changes, it creates a secondary config file which overrides the default settings in the primary config file.
The primary config file exists at <installRoot>\MyCustomService.exe.config, and the secondary config file is at <complicated\Path>\vX.Y.Z\user.config.
Where X.Y.Z is the AssemblyInfo version number which is held in sync with the WIX Version number.
When we install a new version, the tool starts looking in a new path for the user.config ... and can't find it. So functionally, installing a new version resets all of the user's configuration :( .
What is the appropriate way to get a WIX upgrade installation to maintain the existing config?
ASP.NET config supports upgrading user settings from one version to the next, using the .Upgrade() method. You're better off using that rather than manage this in the installer.
This question has details on how to manage that: How do you keep user.config settings across different assembly versions in .net?
but the core solution is:
if (Settings.Default.UpgradeRequired)
{
Settings.Default.Upgrade();
Settings.Default.UpgradeRequired = false;
Settings.Default.Save();
}
Having created UpdateRequired as a user property existing only to manage this process
I am attempting to stand up a VxWorks Workbench version 4.5.2 project into a CM system but am running into issues. I have just started learning VxWorks Workbench. I have searched a bit on how others have done this and I came across two solutions:
Make the project path relative in a sub-directory in the WindRiver home directory.
Do not version Workbench project files and just version my source code. Every client must re-create the Workbench project on their local machine.
The first solution would be ok but I have not been able to make it work. There seems to be some registry (Windows 10) or some path stored elsewhere for Workbench related workspace locations but the end result is the project is not loaded.
The second solution would be a last resort that I would prefer not to do as there are many steps to re-creating a project on a local machine making it tedious and error prone. Does anyone have experience versioning Workbench 4 projects into CM and can share possible solutions?
This can be complicated, and it very much depends on what project type you are talking about.
For DKMs, RTPs, Static and Shared Library projects, you need to version these project files:
.wrproject
.wrmakefile
.cproject
.project
Other project types will have these, but also some additional files that are required to recreate the project, for instance VIP projects also have a <projectname>.wpj file. A conclusive list is too long for this answer however.
You do not need to version the automatically generated Makefile , nor do you need to version the automatically generated build subfolders.
My advice is to store the projects along side your code. I personally prefer to store my projects outside of my workspace, and they should certainly not be stored anywhere in your Windriver installation folder.
I tend to use a structure like this:
c:\gitrepositorys\CuriousCamel\Source\
dkmProject1
.wrproject
.project
.wrmakefile
.cproject
dkm.c
dkmProject2
dkmProject3
vipProject
etc.
The above are all versioned. In terms of the actual Workbench Workspace, I tend to create it in c:\gitrepositorys\CuriousCamel\Workspace and this is explicitly not versioned - I create it fresh for each clone, and often delete and recreate when I switch branch.
Existing projects can be imported into the workspace using the import wizard (using the General->Existing Projects from Filesystem option). When you create a new project, just make sure you choose the "Create Project in external location" option, and select wherever you have chosen to store projects.
So looking through the newest release of GLM 0.9.7, I dont see a FindGLM.cmake file anywhere, used to easily include GLM in CMAKE. I could always use an old version of it found online but the following commit had me stumped:
https://github.com/g-truc/glm/commit/62a7daddcf082f754000fc5e42d7bcdf93c895f7
Commit message is "Removed obsolete FindGLM". So, did the developer just dump it or are there in fact a new way to find libraries in CMAKE?
Yes, CMake Find modules (FindXyz.cmake files) are deprecated in favour of Package Config files (usually named XyzConfig.cmake). The original philosophy is that Find modules are shipped and maintained by CMake, while Package Config files are shipped and maintained by the package they are intended to find.
CMake's find_package command actually has two modes: Module mode (legacy, using Find modules) and Config mode (preferred, using Package Config files).
For the client consuming the package, little should change (unless more customisation is desired, which is offered by the Config mode of find_package).
Notice that the very commit to which you linked not only drops FindGLM.cmake, but also adds a glmConfig.cmake file.
We moved from Hudson to Jenkins and are using StarTeam for version control.
Now according to this site (https://wiki.jenkins-ci.org/pages/viewpage.action?pageId=47480884) there are no global settings to setup StarTeam config.
So we have to specify the StarTeam configuration manually per project (Jenkins Home/[myProject]/configure 'Source Code Management Section')
Certain properties will always be the same like the HostName and the Port #. Now if we were ever to change the StarTeam server we will have to go to every single project and update it again.
Is there a way that we can specify this in a variable and use it in every project?
We tried to create a global environment var (Jenkins Home/Manage Jenkins/Configure System in the 'Global Properties' section).
And then under the project I am trying to configure I have
But when it is building it has difficulty connection to server ${STARTEAM_SERVER}. Have anyone used this before?
Sadly, the Starteam Jenkins plugin doesn’t understand parameterized values. You have to enter the IP or machine name instead.
Raise issue in Jenkins if you want but I don't think anyone is maintaining the Starteam plugin now.
I do not know if it works, but you can try a properties.file.
Content of the file which constains the script:
echo "STARTTEAM_SERVER=`MyServerNameGoesHere`"> env.properties
Path of the properties file:
env.properties
Source code Management (StartTeam)
echo"$STARTTEAM_SERVER"
Something like this works for the build, maybe here works too.
The answer from ABose was correct at the time, but might be worth another look. As of June 24, Borland closed a vote on their User Voice site. I believe they have finally taken an active role in contributing to the Jenkins plugin. Not sure if it is the same base or if they have written their own plugin. I was in conversation with them on this back in 2012, and it seems they may have gotten this going again. Here's a link: http://borland.uservoice.com/forums/143611-starteam-feature-requests/suggestions/2466059-expanded-build-tool-integrations.
You might try contacting Borland Support to find out more, and bring this feature suggestion to their attention.
We are migrating the project from sitecore 6.2 to sitecore 7.1.
I am trying to install the Active Directory Package "Sitecore Active Directory 1.1 rev. 130705" after upgrade of Lucene Search.
I am getting the error
"Sitecore.Exceptions.ConfigurationException: Could not create instance of type: Sitecore.ContentSearch.LuceneProvider.Analyzers.DefaultPerFieldAnalyzer. No matching constructor was found.".
This is when I try to install the package using Installation wizard in sitecore 7.1
As the Exception Message states its an issue with Sitecore's ContentSearch. It's not relating to version of Lucene or upgrade issues. The source of the issue is an incorrect Lucene or Solr (depending on which on you are using) IndexConfiguration.config file.
Check this first
Before proceeding make sure its not human error. This error will be displayed if you have the index file in the App_Config/Includes/ more than once. Or if two or more Index Configuration files with the same xml element name.
Option 1 - Remove the file
You can either remove the offending IndexConfiguration.config from the /App_Config/Includes/ folder and update the relating Index config files to use the DefaultIndexConfiguration in the configuration XML node;
<configuration ref="contentSearch/indexConfigurations/defaultLuceneIndexConfiguration" />
Option 2 - Fix the file
The other option is to amend the custom IndexConfiguration. Most developers are familiar with creating a custom Index by copying the entire content of the config file so will copy the entire DefaultIndexconfiguration config to create a custom IndexConfiguration causing the Exception. This is not needed.
You only need a small number of the settings from the DefaultIndexconfiguration config as shown in this blog on how to create a custom IndexConfiguration.
I havn't checked out any code, but it sounds like the caller ("Sitecore Active Directory 1.1 rev. 130705") is compiled with an older version of Lucene.Net. Check the references of the AD-package and make sure you're using same version of Lucene.Net, or upgrade your AD-package to use the newer version.
I can't say how much coding is involved when upgrading the Lucene.Net related code (if you have access to it), but updates during the last year or two are mostly casing changes or get-methods transformed into real properties.
I had a similar issue and it had to do with a developer creating a backup file in the app_config\include directory.
They were updating one of the config files and in order to create a backup they just copied the file, which created another .config file (SameName-copy.config)
To fix we just renamed it to SameName-copy.config.bak-ccyymmdd
Hope this helps someone in the future with similar issue.
Note that you cannot upgrade directly from 6.2 to 7.1. You will have to go in steps, going to 6.5, 7 and then 7.1