I have installed openLiberty 20.0.0 and I want to activate hotdeployment.
For that I added the applicationMonitor tag into the server.xml
<applicationMonitor updateTrigger="polled" pollingRate="500ms"
dropins="dropins" dropinsEnabled="true"/>
But these seems to be the defaults already. So maybe I can leave it.
I also added the autoExpand feature
<applicationManager autoExpand="true" />
Now when I deploy a .war file into the dropins folder the application is automatically recognized by openLiberty and deployed immediately. This is fine so far.
But as I understood, also a hotdeploy of single source files (e.g. .html, .xhtml.) should be recognized and updated in my running application without the need of a full redeployment.
If I change for example a single jsf file within the application folder
./dropins/myapplication.war/my-page.jsf
nothing happens.
What did I miss to let OpenLiberty also recognize this minor file changes?
Simple answer:
remove <applicationManager autoExpand="true" /> and things will work how you expect.
Longer answer:
If you have <applicationManager autoExpand="true" /> in your server.xml configuration then the application will be automatically expanded into a new folder at ${server.config.dir}/apps/expanded/APP_NAME/
So when you run application you will have a file layout like this:
./server.xml
./dropins/myapplication.war
./apps/expanded/myapplication.war/my-page.jsf
./apps/expanded/myapplication.war/WEB-INF/classes/com/foo/SomeAppClass.class
The "active" set of files will be the files under the apps/expanded/ folder which you can then hot-update. This approach is useful if you want to deploy a single .war file and then make tweaks to it after you deploy it, such as in dev mode. However, be cautious about directly making changes to the expanded folder because it can be wiped away if a server is restarted and the app is re-expanded.
Normally users don't need to be aware of the details of app expansion or hot-updates because it's all taken care of if you use Liberty dev mode. If you haven't tired that out already, I'd highly recommend it.
Related
we have an old jar loaded instead of the correct jar. this was a temperory issue and when we restarted the server it picked the correct jar, so I was searching for what might be the cause of this, and I found that there are two places tmp/_WL_user and /AdminServer/tmp they contain copies of application jars. can someone explain the purpose of these two locations and when WebLogic loads the jars from them?
These are temporary application directories. Normally, these files and directories are deleted automatically when no longer needed. However, it is possible to delete them manually to save disk space. Please bear in mind that WLS should be STOPPED prior to deleting these files.
The /tmp/WL_user is actually the cache of your Admin/managed server. In case you accidentally delete the actual jar/war/ear file, your application will still run even if you do a restart of the server. It will only look for the actual location of the jar file only when you remove the /tmp/WL_user directory and restart the servers.
Wroth noting if you have staging enabled, you will also find a directory named 'stage'. This is generally enabled in production where you will find another copy of the jar file. I a not sure of the purpose, but this is again to keep another copy of the jar file to avoid any accidental removal from the original source directory.
Hope this clarifies.
I have an umbraco installation that uses imagegen.ashx.
I would like to deploy it using octopus deploy, this is pretty simpel and is already working.
My problem is that octopus deploys to a new folder (with a version number) each time, which imposes a problem with the media folder, since it can be changed in every folder.
I have made a shared folder at the same level as the versions, and I have made a virtual directory in IIS.
If I access the files directly through a browser - they exist and everything is fine.
But if I use imagegen.ashx it does not work, I have tried setting the imagebasedir property like so:
<Class Name="default" OverridesQueryString="true">
<AllowUpsizing>false</AllowUpsizing>
<MaxHeight>800</MaxHeight>
<MaxWidth>800</MaxWidth>
<ImageBaseDir>D:\Octopus\Applications\customer Test\customer\Shared\ </ImageBaseDir>
</Class>
What am i doing wrong?
ImageBaseDir is unlikely to expect a server mapped path.
The imagegen documentation shows examples that are either relative to the site, or from a fully-qualified url from another site.
Mapping to a path outside of your webroot will likely cause permissions issues for a number of reasons i wont get into here...though i see that you have set up the Media folder as a virtual directory. Good start, however it appears that you're mapping to the d:\ drive instead of the virtual directory you set-up (Presumably this is /Media ?).
You may also look into how the imagegen "Cached" folders are respected by your Octopus set-up. If the imagegen generated images/files get munged, that's a no-good-situation that could leave you with the appearance of missing images:
/(media-virtual-directory)/99999/Cached/index.xml could state that the generated image is # "df1rt0lr.png" -but if that got removed in the deploy process you'll see the missing image behaviour.
Have you used the AltImage property to specify a fallback to a known, always available image? This will help tell if imagegen is throwing errors before outputting your expected result.
I don't believe it's an imagegen issue however, it's a pretty mature product and it's well put together as well being well documented. I would look at using a relative path for ImageBaseDir - or better yet, not using this attribute at all but rather just having your /Media folder being in a constant location as your virtual directory.
Using websphere 8.5. I am trying to use Monitored Directory deployment and use a deployment properties file using this guide
I have enabled the monitored deploy in the global settings. I have also extracted the properties file using wsadmin and verified that it contains the correct configuration (eg. path to a shared library).
I have put the myconfig.properties file in:
C:\websphere\myserver\monitoredDeployableApps\deploymentProperties
I then drag my application test-ear-app.ear (an ear file containing a war file) into:
C:\websphere\myserver\monitoredDeployableApps\servers\my_server
As a result the app is automatically loaded but the myconfig.properties is NOT loaded and hence I need to manually specify the shared library afterwards.
Any ideas why the myconfig.properties is not loaded?
Actually when you deploy using property file you don't drag ear to monitored directory, but just the property file. So in your case you should just drag myconfig.properties to the monitoredDeployableApps/deploymentProperties directory. In your config file you have to define location of your ear by EarFileLocation=/temp/yourApp.ear it will be automatically loaded and installed in proper scope defined by the TargetServer/TargetServer/TargetCluster properties.
See detailed description in page Installing enterprise application files by adding properties files to a monitored directory
As I read, I think the procedure is the opposite of what you were currently doing : drop the Ear first and then start the install process with the props file.
I have a Windows.Forms client that is packaged as MSI by using a Visual Studio Deployment Project.
My app.config has some configuration properties whose values must be replaced by the correct ones depending on the environment I want to deploy the client into.
For instance, my client do connect to a set of COM+ services that are behind a WCF facade, so I have some URLs in the configuration file that vary depending on the environment (development, integration, etc etc).
In such way one can find in the application config line like this:
<add ServiceName="MyService" ServiceEndpoint="$(WS_URL)/MyService.svc" MaxMessageSize="xxxxxx"></add>
Well, the thing is that I need to execute a batch file (.bat) to load some variables and then replace the variables in the app.config, but, I need to do the replacements in the application configuration file that is being packaged in the MSI, and not perform the replacement in the "original" configuration file that is in the client project.
In fact what I would need is just to get the path, of the application configuration file, that VS is about to package, and pass the file-path to my script so that it does the replacements.
NOTE: In the above sample line $(WS_URL) is the variable that must be replaced by its correct value depending on the deployment environment configuration.
I would create 2 copies of your App.Config in source control and associate one with your project for F5 builds / dev debugging and another one that gets consumed by the installer for production use.
Finally I have the solution that fit our needs. My need was mainly to just have one unique configuration file for the Windows.Forms client and being able to replace some property values in it, just before the file is packaged in the MSI.
I thought the binaries that are packaged within the MSI were taken from the project(s) output dir., but they are not, so I couldn't use that location to execute our "variable replacer" script and get the final App.config file ready to be packaged.
We a have a .bat file, one for each kind of environment configuration, in which we centralize the configuration properties applying for Windows.Forms, Web-Applications, COM+ Serviced Components, so I was disgusted with the idea of replicating the configuration file of the client, because my aim is also to reduce the number of configuration files, to reduce the risk of making a mistake, while keeping the process of creating/maintaining build environments easy.
I couldn't find any doc to tell me how could I get the path, of the temporal folder or whatever, where the files are, just before the MSI is being packaged. If I would have access to it, then I would have executed our "variable replacer" script pointing to that directory and problem solved.
My workaround was to place a customized pre-build event, so that the I copy the "template" App.config to the project directory, and once it is there, I run the script to replace the property values.
Now, every time the deployment project is built, we are sure it contains a valid configuration file.
Just FYI, here is how the pre-build event looks like:
XCOPY /Y $(ProjectDir)config\*.* $(ProjectDir)
CALL ..\ScriptsCentral\do_apply_config.bat $(ProjectDir)App.config etc
EXIT 0
NOTE: I had to put the EXIT 0 explicitly because we build all the projects with msbuild and devenv.com and I got the build process stopped in the part where it executes the build event.
(thanks #ChristopherPainter for your time and comments. +1 for your proposal)
I'm working in a solution which includes a windows service host project that uses a single app.config file which contains everything the service needs (logging configuration, WCF configuration, custom configuration, and, connection strings).
The way I actually work is when a user complains about something wrong in the production environnement, I edit the app.config file, modify the connection string so it points to the production database, recompile the service host project, then run the application in my dev environnment to see what's going on.
If I have to test things that would be too risky for the production environment, I edit again the app.config file, modify the app.config file so it points to the test database, recompile the service host project, ... you see where I'm going ...
To avoid the burden of editing the app.config file everytime I have to switch environments, I decided to create a "Production" build configuration and a "Test" build configuration. I added two additionnal config files, one for each environment, which are replicas of the main app.config file except that their connection string points to their respective database. I modified the pre-build event of the project to include code that copies the environment's app.config file depending of the selected build configuration.
I have two concerns about that method :
If I have anything else to modify in the app.config file (WCF, logging, etc.) I have to remember to replicate my modification in the other file. (Big problem for me as I have as much memory as a red fish)
I hate making the project more complex to work with because of the additional build events, additional files in the project directory, etc.
Each build configuration outputs in a different directory. I hate having duplicates of the same code just to overcome that data source issue.
Anybody can suggest a simpler way to work with multiple environments ?
Thanks in advance.