I like to use command line to install Tomcat as a Windows service. There should be the service.bat file for this purpose. But it is missing from Tomcat 7.0.37 and 7.0.39.
We can not use Windows installer for embedded, so this is not an option.
Thanks for help.
Are you sure you have downloaded the right package?
From the download page for the latest Tomcat 7 version (7.0.39 at the moment of writing this) choose depending on your needs:
32-bit Windows zip
64-bit Windows zip
Both packages have service.bat in the bin directory.
Also on the download page read the README file for packaging information. It explains what every distribution contains.
UPDATE
From the README file for packaging information (emphasis mine):
apache-tomcat-[version].zip or .tar.gz
Base distribution. These distributions do not include the Windows service wrapper nor the compiled APR/native library for Windows.
apache-tomcat-[version]-windows-x86.zip
32-bit Windows specific distribution that includes the Windows service wrapper and the compiled APR/native library for use with
32-bit JVMs on both 32 and 64 bit Windows platforms.
apache-tomcat-[version]-windows-x64.zip
64-bit Windows specific distribution that includes the Windows service wrapper and the compiled APR/native library for use with
64-bit JVMs on x64 Windows platforms.
You may also find it useful reading the RUNNING.txt file, which is available in every distribution. It contains important details about installing/configuring/running Apache Tomcat and also Windows and *nix specific instructions.
Tomcat is a Java application. So it is cross-platform. But if you want/need to utilize Windows specific features, like Windows services in your case, then you should download the Windows specific distribution.
Other thoughts
I myself on my Windows machine use "Base distribution" (i.e. not Windows specific, but an ordinary ZIP file available on the download page under Binary Distributions => Core) without any problem whatsoever, because I prefer not to bother with installations (i.e. running the installer), but just to simply unpack the distribution to the desired directory and manually configure it using the related config files. It's so much easier and convenient both to install (just unpack) and delete the installation (just delete without running any uninstaller), and it's more portable. Plus this way you can install multiple versions of Tomcat on the same machine (in case you need this for some development/testing reasons).
Here is a very useful step-by-step tutorial with some nice illustrations and explanations:
How to Install Apache Tomcat 7/8 (on Windows, Mac, Ubuntu) and Get
Started with Java Servlet
Programming
In the official web site, under core. Don't download the version tagged zip. Download the version tagged 32-bit Windows zip or 64-bit Windows zip. You will find Service.bat under Bin
Related
I'm trying to revive some old software: it was developed on Windows XP, and I'm trying to get it working on Windows 10.
However, this software is dependent on api-ms-win-core-wow64-l1-1-1.dll, which isn't co-operating: Dependencies states that api-ms-win-core-wow64-l1-1-1.dll is missing imports, while Visual Studio's dumpbin states that it has no dependencies.
I'm aware that Microsoft has migrated its functionality and that nobody should link to the implementations directly, but is there any way to get api-ms-win-core-wow64-l1-1-1.dll functionality for this old software on Windows 10? Alternatively, is there an accessible way to rewrite old .dlls to link to Microsoft's Win32 APIs?
(For those who need the file: I got api-ms-win-core-wow64-l1-1-1.dll by running $ locate api-ms-win-core-wow64-l1-1-1.dll on a linux machine with wine installed on it.)
I'm not sure whether this directly addresses your issue. I'm supporting a Java app which uses JNI with some native Windows libraries. I used Dependencies to check what was missing and it turned out to be api-ms-win-core-wow64-l1-1-1.dll (through WS2_32.dll).
The solution for me was to install the latest VC redistributable from MS.
Getting libraries from Wine is probably not a solution, in case you seek to use them outside the linux environment. (They are wrappers and obviously not using native Windows assemblies)
You can get some success by using extracting them from the ReactOS live CD. However, you should be aware that many of these are umbrella libraries, as explained here:
An umbrella library is a single static-link library that exports a subset of Win32 APIs. For example, an umbrella library named OneCore.lib provides the exports for the subset of Win32 APIs that are common to all Windows 10 devices.
https://learn.microsoft.com/en-us/windows/win32/apiindex/windows-umbrella-libraries
https://learn.microsoft.com/en-us/windows/win32/apiindex/windows-apisets
https://learn.microsoft.com/en-us/uwp/win32-and-com/win32-apis
I noticed that deployed on windows Qt applications are always including the dlls they needed.
Why did they made it that way?
Why can't they do it like on linux? - You install needed Qt version to system, and then every application that need it - can use it, e.g. only one instance of libraries(excluding different versions like qt4/qt5).
Wouldn't it be better to make it like Java/.Net, e.g. you install Java/.Net then you run/develop applications using only one instance of libraries(dlls).
I find it kinda "unconservating": I have 7 applications that use Qt5, and all of them have Qt5Core.dll, Qt5GUI.dll, etc. and every of them takes some space. Feels like I have 7 packs of Qt5 libraries... x_x
While on linux these same applications use only "one" Qt library.
I noticed that deployed on windows Qt applications are always including the dlls they needed.
This is called "local deployment".
Why did they made it that way?
I can think of a few reasons.
To avoid DLL Hell.
It is sanctioned by Microsoft. They wrote, "You can use this deployment method to enable installation by users who don't have administrator rights, or for applications that can be run from a network share." (see https://learn.microsoft.com/en-us/cpp/windows/choosing-a-deployment-method?view=vs-2019)
You install needed Qt version to system, and then every application that need it - can use it, e.g. only one instance of libraries(excluding different versions like qt4/qt5)
Qt is a C++ library. C++ DLLs can differ by more than just a major version number. The DLLs could be built with MinGW, or they could be built with MSVC; They could be 32-bit, or they could be 64-bit. The different variants are incompatible with each other.
Example: if you force a PC to have one global copy of Qt 5.14.1 MSVC 32-bit and put that in your PATH, then:
Other Qt apps on that PC that are built with MinGW cannot run.
Other Qt apps on that PC that are 64-bit cannot run.
Apps that must use Qt 5.13 might be broken. (For example, if a critical bug exists in Qt 5.14)
Why can't they do it like on linux? .... on linux these same applications use only "one" Qt library.
I listed a few disadvantages of this approach above. In addition, the version of Qt in Linux distros are usually a few versions behind so applications in the distro repository cannot make use the latest features, bugfixes, or improvements.
That's part of the reason why systems like AppImage and Snapcraft were invented. Sometimes, Linux users also want an app to contain a copy of its libraries, instead of having a single global copy of the libraries.
I use a 64-bit OS to develop a JavaFX application and use Maven to build my application with javafx-maven-plugin to generate an installation package. The resulting package contains only a 64-bit application. So, is there a way to create a multiarch installator or create a pair of x86 / x64 installators in one pass?
UPD
Could you provide an example of a targeted build-system based on maven? Is it needed to use differents OS or just differents JRE on OS x64? In last case how to build the pair of installers per one run? How to automatically add a suffix to application name to noting the architecture? Is it needed to use e.g. Jenkins, or it can be done with maven alone? Is there a some "classic" configuration of the targeted build-system? And more, is there some drawbacks to use 32-bit application on 64-bit OS? From my tests follows that 32-bit app (for my case) is slower on 32-bit OS than on 64-bit OS. But 32-bit and 64-bit application on 64-bit OS work equally.
this is indended, because the underlying installers contain that information. There is no future where this can be provided, this was a JDK-bug once, but closed as "wont fix". As the javafx-maven-plugin uses the official javapackager-tooling, all benefits/drawbacks of that tooling is valid here too. This is even in the official documentation: https://docs.oracle.com/javase/8/docs/technotes/guides/deploy/self-contained-packaging.html#A1307236
You need a build-system per targeted architecture.
EDIT: regarding your updated question: you can only create windows-launchers/installers on windows-systems, you can only create linux-launchers/installers on linux-systems, and the same form mac. This means in order to get launchers/installers from the one project, you have to run the build on every platform, and two times each. One time you have to call it with 32bit JDK being installed, and the other time with 64bit JDK installed (might work on Windows to only have JAVA_HOME being set, as maven picks this up), it does not need any tool like Jenkins, but if you have it, just use it.
About the performance I can't say anything, this is out of scope and is bound to the JRE itself.
Disclaimer: I'm the maintainer of that maven-plugin.
I would like to try scidb as a replacement for hdf5. I would like to test it on my Debian laptop (no clusters) to give it a try.
Is this possible? Might be that Debian (as opposed to Ubuntu) is not supported?
I had no luck with the installation instructions. The deployment script tells that my OS is not supported. The scidb userguide says about some pre-built packages (for Ubuntu, at least). But there is no hint on how to obtain them.
SciDB is limited to RedHat / CentOS, and to Ubuntu as of the 14.9 release. Folk who want to run it on other distros generally compile from code.
Information about how to obtain the sources (as well as current documentation and community discussion) can be found on the forums here ... http://www.scidb.org/forum/. You'll need to register as a forum user.
Specifically, have a look at http://www.scidb.org/forum/viewtopic.php?f=16&t=364. There's a list of releases and links to code bundles there.
I installed SciDB several times using several ways (building from sources and installing from packages, installing the cluster version and the dev version).
Installation from packages
First, if you choose to install from packages (the easiest and fastest way), SciDB is very very sensitive about your Linux version. For example, for the last version of SciDB (14.8), if you choose to install on a Ubuntu, it has to be a Ubuntu 12.04 (and not a 14.04, a common mistake) 64 bits (meaning you have to install the AMD64 version even if you have an Intel processor). It won't work if you have a different version.
If you have an Ubuntu 12.04 AMD64, Paradigm4 provides a deployment script and a documentation with very simple steps:
https://github.com/Paradigm4/deployment
Installation from sources
It's not so difficult but it can be painful and time consuming. I did it because we had to compile a custom plugin for SciDB. You have two types of installation: dev install (in SciDB user directory) and cluster install (in /opt/ directory).
You have to be registered on their forum to have the link to the source code. They provide a specific documentation to build from source.
Good luck.
Several months ago I have dealt with porting SciDB 14.12 to an unsupported Linux - Fedora 19. If your OS is not supported, it will neither be supported if you try to install from the sources. You have to start from the sources, but then you have to adapt the deployment and installation scripts. The sources can be downloaded from SciDB forum.
Namely, add a new platform to deployment/common/os_detect.sh. Then, there are multiple platform specific deployment scripts, such as deployment/common/prepare_toolchain.sh, deployment/common/prepare_coordinator.sh and deployment/common/prepare_chroot.sh. You need to make sure those prepare the environment as they would on the supported OS'. I used Red Hat 6 and CentOS 6 as a reference, as those are both more similar to Fedora. Since your OS is Debian, you can first try falling back to Ubuntu deployment (in os_detect.sh).
Another problem you may encounter are the 3rd party tools, specially Boost. In my case, I had to build it manually from sources.
Sometimes when porting and debugging it is not convenient to run the scripts with deploy.sh, but it's better to run the deployment scripts directly on the target machine (e.g. coordinator).
Probably the best way to install and to start with SciDB is to download a standard image. With this image you only have to import the virtual machine with a software to virtualize. Moreover there are some characteristics of this virtual machine that are great to develop your first applications.
The main advantage, is that you have an API to SciDB queries and another to R. Then you can explore all options and to test SciDB.
This is the version that I downloaded few months ago: http://www.paradigm4.com/forum/viewtopic.php?f=14&t=1329&sid=606f614e401900cfa750375ba56de656
Nevertheless, there is a problem, the community is too poor. There are little people developing with SciDB.
I have a development PC with Windows 7 (APACHE / MYSQL / PHP) and I want to install "Skipfish" (http://code.google.com/p/skipfish/) in order to check my web app for security/vulnerability issues. I read the instructions but I can't understand it.
I cite the source page
The tool is believed to support Linux, FreeBSD, MacOS X, and Windows (Cygwin) environments
Since it isn't a "real" windows application you don't have any file windows can execute (such as a .exe or .msi file). You need to use the http://www.cygwin.com/ tool and then more or less use it as an Linux application.
Read up on the instructions on skipfish and Cygwin, and then return with any more specific questions you may have.
I think it is too late, but... Complied version is here: https://didasec.wordpress.com/2012/12/17/skipfish-2-10b-for-windows/
Since the original source is not available so it is shared in GDrive. Use it.
Skipfish for Windows