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.
Related
I'm about to backup my (Linux) home directory, and in the process of culling some of the larger files/subdirectories whose contents I dont need (e.g. .cache, .ccache etc.) - I noticed I have a pretty sizable .gradle subdirectory.
I very rarely use the gradle build tool, but I must have used it for something a couple of years back. My question: Is there important information/settings in a user's .gradle folder, or is it basically just cached dependencies / gradle's own auto-downloaded data?
From the docs:
https://docs.gradle.org/current/userguide/directory_layout.html#dir:gradle_user_home
The Gradle user home directory ($USER_HOME/.gradle by default) is used to store global configuration properties and initialization scripts as well as caches and log files.
Generally, locally it does not matter. However, more advanced use cases (CI/CD) allow you to share or even relocate certain caches: https://docs.gradle.org/current/userguide/build_cache.html
The only notable item of importance is a global gradle.properties file you may have created. If you did, it would be located at $GRADLE_USER_HOME/gradle.properties where GRADLE_USER_HOME by default is $USER_HOME/.gradle. If there any credentials in there you do not have saved else where, considering backing those up.
Otherwise, it is safe to delete. Granted you do not mind having to redownload dependencies etc. again.
While trying to clear up some disk space, I noticed that many Gigabytes of data lie around in the 'sonatype-work/nexus/tmp' folder. The biggest directory is called 'nexus-maven-repository-index.gz*.dir' and I am hesitating to remove it. Is that just a temporary and unused copy of the repository index which I can safely delete?
The documentation of the Nexus Directories does not provide sufficient information about the 'tmp' folder. It only says that it is the "Folder used for temporary storage".
It should be safe to delete this content. Please note that treatment of the tmp folder recently changed in the 2.8.1 release.
Also going forward you should use the Empty Trash scheduled task. See http://blog.sonatype.com/2009/09/nexus-scheduled-tasks/
I am reading this file "readme_5202_P8CPE_IF001.htm" (Content Platform Engine 5.2.0.2 Interim Fix 1), and I encountered this procedure:
Copy the new Engine-xx.ear file into the following directory. This directory is a staging location. Do not delete or overwrite the currently deployed Engine-xx.ear file.
Windows
installation_location\ContentEngine\lib
UNIX
installation_location/ContentEngine/lib
What I don't understand is, how am I supposed to copy the Engine-xx.ear file to the specified directory without deleting or overwriting the existing Engine-xx.ear file there? Please bear with me if my understanding in English is not good.
Thank you very much!
That's a note (poorly explained, though) not to overwrite the original file (Engine-xx.ear), but to rename it, as e.g. Engine-xx-orig.ear, and store it aside (to have it if something goes bad with your upgrade) before copying/building the version from a fix pack to that same location.
Which is called a staging environment.
Because it's used to build a WAR/EAR for deployment.
Judging from the rest of the document, I belive that they are trying to tell you that you should follow their instructions carefully, and not try to be clever and overwrite the deployed application (at some other location).
I would give it a shot and overwrite whatever is in installation_location\ContentEngine\lib, the staging location. Make a backup of the files you overwrite in case it doesn't work out.
Everytime I deploy my ClickOnce application it creates a bunch of directories with a single dll inside it.
It doesn't even use them and I'm not sure how to disable their creation.
Actual Directory http://imageshack.us/a/img818/6347/folderstructure.png
Each time I open it them it's just ONE dll in there.
Actual Directory http://imageshack.us/a/img15/6027/directoryb.png
This is the actual working directory. I can delete the other folders manually, but I'm not sure what I need to do to make sure the clickonce deployment doesn't create the other directories.
Actual Directory http://imageshack.us/a/img11/573/actualdirectory.png
Any idea on how to disable the Clickonce installer to not create the other directories?
Thanks,
Raff
I was able to clean the list out by going through each project and modifying the assembly information so that it was not com enabled and all the fields filled. out.
Hopefully this will help anyone else that might find a similar issue.
I code on 2 different computers with different username. Xcode makes a .pbxuser file for each one, making necesary replicate the config from each one.
This is error prone, and the files are not diff-friendly so everything must be carefully checked. Any way to avoid this?
The info in the .pbxuser file is not particularly important - it's just personal settings like window locations, breakpoints, etc. All the important stuff is in project.pbxproj and this is the only file you need to sync/back up/check into source control/etc. You can ignore or even delete the other files in the .xcodeproj directory - they will get re-created with default settings.
the .pbxuser file does contain custom executables in there. So if you use a custom executable as a unit test runner, (or some other executable) you might have to share that file
When I have Xcode projects I might have to work on on multiple computers, I just have my project live on Dropbox. Then it's in the same folder on any computer I might use to work on it, and the changes get synced every time files are modified. That way I'm literally working on the exact same project on each computer.