I have an already running Worklight application. We are planning to move to another production cluster tomorrow but I want to get the old .wlapp that is already deployed on the first cluster.
How can I get it? I could find a directory on the temp file of the WebSphere application server, but it is in an exploded form. When I zipped one of them and converted it to .wlapp, while the deployment was successfull, I had a Direct Update and the application failed to start...
Is it the right path?
When you build your application in Worklight Studio, the build produces .wlapp files and stores them in the yourProject\bin folder, these files do not get deleted from the bin folder unless you've manually deleted them.
appname-envname-version.wlapp
appname-common-version.wlapp
appname-all.wlapp
Where the version value changes depending on the value you've set in yourProject\yourApp\application-descriptor.xml.
A good practice would be to backup your artifacts of different versions as well as project source code (using a source control system...), so you could always restore any version... esp. if you're talking about already being in Production....
After deployment, the .wlapp file is not stored in the filesystem, but in the database.
So as for retrieving previously deployed .wlapp files if you do not have backup (this is very bad, BTW), these are stored in your database in the APP_SYNC_DATA table in the deployable column. You can try to extract and save the APP_SYNC_DATA.deployable data relevant for you as a .wlapp file.
But this really does not guarantee that it will "work" any better than your other attempt. That .wlapp is configured to work with certain server URLs, and if this new cluster is not a replica of the previous cluster, I don't see this working either... But also, without knowing more about the errors you get, who knows to what they are related (but this is NOT for this question).
Related
I'd like to offline profile a YARN application. My application starts 10 containers. One of those starts consuming 100% CPU shortly before it crashes. I don't know which one is going to crash. And sadly, as this application starts multiple containers, they could potentially run on the same cluster hardware nodes. If I use a standard JProfiler config, I have to specify a filename for the savepoint. On my cluster, I can't use a relative path (relative to the working directory) as the folder is removed when the application crashes/finishes, so I need to specify an absolute path on the machine which then is the same for all containers overwriting their snapshots...
Is there a way to solve this issue? I'd like to offline profile all of my containers, let them write to a savepoint and pick the snapshot of the one which crashed.
Today, I found an old jprofiler-config.xml for JProfiler 7 on GitHub indicating that there are several more options available compared to the ones I see in my jprofiler-config.xml (JProfiler 11). Are you aware if there is any XSD describing the schema and what can be configured?
The "Save snapshot" action can add a number to the snapshot name to make it unique. It will check for existing files before writing the snapshot.
Since JProfiler 11, the config file only saves modified attributes and not all possible attributes. You can make changes in the GUI and observe the changes in the config file. There is no XSD for the config file format.
I am attempting to share a file that builds and populates an SQL database through git, but it won't create the DB on my team members' machines because the .mdf and .ldf files are located on my machine. How can I rectify this?
If you want to share a SQL script, you don't have to share the database with it!
What is generally done (best practice) is that you have the script needed to create the database (and eventually populate it with static/test data) in git, and then the user will launch that script to build the database.
git is here to keep track of your source code and the changes made to it, you shouldn't put in it any generated file, and .mdf / .ldf files are typically part of what should not be in your git. For generated files within your folder, there are ways to configure git to ignore them.
The value of git is to record differences between files, if you want to share your software, git is definitely not the good tool. Put those file on a shared folder (NAS), on dropbox, give them through an USB key or whatever.
However, if you really want to do this (bad idea), I guess you can add your files in your repository and either configure SQL Server to find them here or create a symbolic link.
One of my servers is running out of capacity, mostly due to WebLogic's stage folder. I've been looking for information and it seems to be a temporal folder, but unlike older versions, on WL11g this folder is out of the tmp folder. So I'm not sure whether or not I can safely remove it.
Stage directory is where weblogic copies all the applications that it needs to deploy on to the managed servers. Wls does not delete any file from this folder. So in the long run if you have done deployment of many versions of your application then this folder can become rather large.
So yes you can delete the contents of this folder. At the time of restart wls will copy all the necessary files to this folder (this could take some time).
yes, you can delete the stage. All the necessary applications details will be there in this directory, but any how if it is a large environment(many applications are running), just take the back up of the directory or rename it and then you can safely delete the stage.
I am in the process of creating an application to allow the automation of application deployments, (https://github.com/twistedtwig/AutomdatedDeployments#readme).
The idea being that everything is in source control, application files, application configuration as well as IIS configuration. My application allows the solution to auto deploy, (adding a post build setp to the sln / proj file), after a build to the dev machine. It will allow the CI server to auto deploy to its machine for testing as well as the CI Server pushing successful builds to QA / Test / production servers. One of the issues I have with msdeploy is the requirement of IIS to be setup with the website / application before hand, (which my app is trying to get around).
So far I can create, update and remove, app pools, websites and applications via config files automatically. I can sync files and folders fine. The last step was to use the /target:package switch in msbuild to create clean file structures for web deployments. For example I would run a command like:
msbuild.exe myMvcSite.csproj /target:clean /target:package /p:Configuration=Release /p:_PackageTempDir=C:\websites\mySite /p:PackageLocation=C:\dropLocation\mySite.zip
This creates a nice zip file with the internal file path of "C_C\wbesites\mySite" ready (as I understand it) to be sync'd to the production server.
My issue is how I deploy this zip file. I want it to be independent of any IIS information, i.e. I am simply pushing the files / folders to a location, (either on the local machine for developers, or remote for testing etc). The setup of IIS with app pools and sites etc would be taken care of separately. Some of the commands (and their output) I have tried are below:
"C:\Program Files\IIS\Microsoft Web Deploy v2\msdeploy.exe" -verb:sync -source:package="C:\Temp\deploy\installer\test\testPackage.zip" -dest:auto
Info: Adding sitemanifest (sitemanifest).
Error: The application pool that you are trying to use has the 'managedRuntimeVersion' property set to 'v2.0'. This application requires 'v4.0'.
Error count: 1.
and
"C:\Program Files\IIS\Microsoft Web Deploy v2\msdeploy.exe" -verb:sync -source:package="C:\website\installer\testPackage.zip" -dest:contentpath=C:\temp\mytest
Error: Source (sitemanifest) and destination (contentPath) are not compatible for the given operation.
Error count: 1.
The first command I am trying to let it unpack the files with the structure it has. It seems to be upset about app pool stuff though, (which I don't want it to touch).
The second I am trying to get around the "auto" bit but this isn't happy either.
I am struggling to find much information about this process.
The only way I can see how I might achieve this at the moment is to not use msdeploy for it, but to create my own task to integrate the file structure and do the file syncing my self, (not ideal).
I ended up coding around this issue, rather than being able to solve it.
I take the zip package:
unzip in a temp location
find the final path it will be going to (normally from archive.xml)
check to see if I am merging the folders or doing a clean install, (i.e. do I delete the destination folder first).
copy / push files to end location, (normally with msdeploy).
I open sourced my solution to this: https://github.com/twistedtwig/AutomatedDeployments
An MSBuild project copies its output to a directory on a server. Each day, only a few files change and most have an older creation date.
I can FTP this to a remote server with MSBuild tasks. But how can I do this FTP and only copy the few files that have changed?
To do this you'll need something that will manage the sync for you - that is that will keep track of what file is where and update accordingly.
We have used FTPSync to do the file sync bit very tidly for a number of sites.
From MSBuild you can call an external program - so putting the two together will probably work providing your are consistently synching from the same location (otherwise its going to be more interesting!)