I found the basic idea here, the exact steps are:
- Install Portable 7zip
- Download Oracle JDK installer for Windows (*.exe)
- Run 7-ZipPortable.exe from your Portable 7zip
- In 7zip find and right-click the jdk installer exe file
- From the context menu use 7-Zip – Open Archive and then Extract
- Now extract the resulting “tools.zip” to a folder that is writable for you
- Open a cmd.exe, cd into the folder and execute this:
for /R %f in (.\*.pack) do @"%cd%\bin\unpack200" -r -v -l "" "%f" "%~pf%~nf.jar"
Kudos to Nick Russler for figuring out this tricky unpack200 command line!
Determine process id
First we determine the process id(s) of the running Tomcat instance(s).
We can grep the running process list for ‘catalina.home’:
pgrep -f 'catalina.home'
This might yield more than one pid.
Or we can search by port (8080 is the default, adjust if necessary). The following commands will likely require root privileges:
lsof -t -i :8080
Alternatively, for example if lsof is not installed:
Or yet another way, using netstat (or its “ss” replacement):
netstat -nlp | grep 8080
ss -nlp | grep 8080
For the process id(s) determined above, we look at process details:
ps -o pid,uid,cmd -p [pidlist] | cat
For each specified pid, this shows the uid (system user) and the full command line of the process.
Typically the command line will contain something like “-Dcatalina.home=[path]” and that path is the catalina.home system property of the Java process.
Alternatively – with Java 7 and later – we can use the JDK command “jcmd” to query the JVM process for its system properties:
sudo -u [uid] jcmd [pid] VM.system_properties \ | grep '^catalina.home' \ | cut -f2 -d'='
Now we can finally determine which Tomcat version is installed under the catalina.home path:
[catalina.home]/bin/catalina.sh version \ | grep '^Server number:'
Note: Please replace
[catalina.home] with the path you determined above.
The final output should be something like this:
Server number: 184.108.40.206
Suggestions for other/better Free/Open Source plugins for current Intellij CE are welcome:
Let’s say you work on a Java application and want to frequently make it available for download so that user’s can easily try the latest version.
Let’s say you work primarily on your laptop or personal computer using a Java IDE and commit code changes, but you don’t want to spend time manually building jars, packaging war or zip files, testing your application or uploading files to a website, etc.
Instead you want to have a fully automated process that compiles your source code, runs automated tests and other quality control mechanisms, builds your application and uploads the result to a public website.
But you don’t want to install any infrastructure for this and not run anything besides Java and your IDE on your own machine(s).
Basically you want to use developer-friendly reliable cloud services but you don’t want to pay a single cent.
All of this is possible, as long your code is Open Source:
- Host your source code on github
- Let travis-ci run vour build process
- Let travis-ci upload the build result to bintray
For details, you can take a look at one of my github projects.
Relevant config files:
Soon I will probably add more detailed instructions to this blog post on how to set up the cloud services.
An old wisdom says that Software can be optimized for latency, throughput or footprint. The same is true for the JVM and its Garbage Collector(s).
Roughly speaking, the classic GC implementations each optimize for one aspect: Serial GC optimizes footprint, Parallel GC optimizes throughput and Concurrent Mark and Sweep (CMS) optimizes for response times and minimal GC induced latency.
But since JDK7u4, we officially have the “Garbage First” (G1) GC. It is still new enough to not even have its own Wikipedia article, but there are good introductory tutorials, articles and tuning guides.
In several ways, G1 is a step up from the conventional GC approaches: It uses non-contiguous heap regions instead of contiguous young and old generations and does most of its reclamation through copying of the live data, thus achieving compaction.
It is based on the principle of collecting the most garbage first and designed with scalability in mind, without compromising throughput.
The benefits of G1 have lead to a proposal and lively debate about Defaulting to G1 Garbage Collector in Java 9.
In conclusion, you can either take the easy path and use the default JVM settings or take some time to learn about modern GC choices and tuning options.
And if you get it all right you might be rewarded with your Java based services performing better than ever before … :)
However, I generally prefer Open Source tools and ideally something that works with other databases as well.
It is a cross-platform tool (Windows, Linux, MacOS, other Unixes) written in Java, uses the Eclipse framework for a lot of great out-of-the-box features and is overall quite polished.
It supports many databases via JDBC. More details and some comparison with similar tools are mentioned on its About page.
Some file types are really just zipped (or maybe gzipped) folders containing xml and/or other plaintext based files.
- *.epub e-books
- OpenDocument files
- Java source jar files
- JEE web application archives (*.war)
- Pentaho report files (*.prpt)
If you happen to have such files in a software project, and don’t want to treat them like opaque binary blobs, you need a tool that helps you to transparently unzip, act on and rezip them. Also you probably want to be able to diff them without resorting to commercial tools like BeyondCompare.
IntelliJ CE (Community Edition) supports archive diffs as part of its regular Comparing Files functionality. All you need to do is make sure the file extension of the file types you want to be treated as archives are accordingly registered in Settings – Editor – File Types.
The screenshot below shows *.war and *.jar registered as Archive file name patterns (by default) and *.prpt (Pentaho report files) as an example of a manually added pattern: