I see the following warning while starting the jetty9 server as service. I have no idea about this.
WARN:oejs.HomeBaseWarning:main: This instance of Jetty is not running from a separate {jetty.base} directory, this is not recommended. See documentation at http://www.eclipse.org/jetty/documentation/current/startup.html
Jetty recommends to run instances of Jetty not from jetty.home distribution folder directly but from jetty.base folder which should be defined separatedly
1. See the chapter Declaring Jetty Base here:
http://www.eclipse.org/jetty/documentation/current/startup-base-and-home.html
The Jetty Distribution's start.jar is the component that manages the
behavior of this separation.
The Jetty start.jar and XML files always assume that both
${jetty.home} and ${jetty.base} are defined when starting Jetty.
You can opt to manually define the ${jetty.home} and ${jetty.base}
directories, such as this:
[jetty-distribution-9.3.7.v20160115]$ pwd
/home/user/jetty-distribution-9.3.7.v20160115
[jetty-distribution-9.3.7.v20160115]$ java -jar start.jar \
jetty.home=/home/user/jetty-distribution-9.3.7.v20160115 \
jetty.base=/home/user/my-base 2013-10-16 09:08:47.802:INFO:oejs.Server:main: jetty-9.3.7.v20160115 2013-10-16
09:08:47.817:INFO:oejdp.ScanningAppProvider:main: Deployment monitor
[file:/home/user/my-base/webapps/] at interval 1 ...
Or you can declare one directory and let the other one be discovered.
The following example uses default discovery of ${jetty.home} by using
the parent directory of wherever start.jar itself is, and a manual
declaration of ${jetty.base}.
[jetty-distribution-9.3.7.v20160115]$ pwd
/home/user/jetty-distribution-9.3.7.v20160115
[jetty-distribution-9.3.7.v20160115]$ java -jar start.jar
jetty.base=/home/user/my-base 2013-10-16
09:08:47.802:INFO:oejs.Server:main: jetty-9.3.7.v20160115 2013-10-16
09:08:47.817:INFO:oejdp.ScanningAppProvider:main: Deployment monitor
[file:/home/user/my-base/webapps/] at interval 1 ...
But Jetty recommends that you always start Jetty by sitting in the
directory that is your ${jetty.base} and starting Jetty by referencing
the start.jar remotely.
2. ... and Creating a new Jetty Base here:
http://www.eclipse.org/jetty/documentation/current/quickstart-running-jetty.html
The demo-base directory described above is an example of the
jetty.base mechanism added in Jetty 9.1. A jetty base allows the
configuration and web applications of a server instance to be stored
separately from the jetty distribution, so that upgrades can be done
with minimal disruption. Jetty's default configuration is based on two
properties: jetty.home
The property that defines the location of the jetty distribution, its libs, default modules and default XML files (typically start.jar,
lib, etc) jetty.base
The property that defines the location of a specific instance of a jetty server, its configuration, logs and web applications (typically
start.ini, start.d, logs and webapps) The jetty.home and jetty.base
properties may be explicitly set on the command line, or they can be
inferred from the environment if used with commands like:
cd $JETTY_BASE
java -jar $JETTY_HOME/start.jar
The following commands: create a new base directory; enables a HTTP
connector and the web application deployer; copies a demo webapp to be
deployed:
JETTY_BASE=/tmp/mybase
mkdir $JETTY_BASE
cd $JETTY_BASE
java -jar $JETTY_HOME/start.jar
WARNING: Nothing to start, exiting ...
Usage: java -jar start.jar [options] [properties] [configs]
java -jar start.jar --help # for more information
> java -jar $JETTY_HOME/start.jar --add-to-startd=http,deploy
INFO: server initialised (transitively) in ${jetty.base}/start.d/server.ini
INFO: http initialised in ${jetty.base}/start.d/http.ini
INFO: security initialised (transitively) in ${jetty.base}/start.d/security.ini
INFO: servlet initialised (transitively) in ${jetty.base}/start.d/servlet.ini
INFO: webapp initialised (transitively) in ${jetty.base}/start.d/webapp.ini
INFO: deploy initialised in ${jetty.base}/start.d/deploy.ini
MKDIR: ${jetty.base}/webapps
INFO: Base directory was modified
> cp $JETTY_HOME/demo-base/webapps/async-rest.war webapps/ROOT.war
> java -jar $JETTY_HOME/start.jar
2015-06-04 11:10:16.286:INFO::main: Logging initialized #274ms
2015-06-04 11:10:16.440:INFO:oejs.Server:main: jetty-9.3.0.v20150601
2015-06-04 11:10:16.460:INFO:oejdp.ScanningAppProvider:main: Deployment monitor [file:///tmp/mybase/webapps/] at interval 1
2015-06-04 11:10:16.581:WARN::main: async-rest webapp is deployed. DO NOT USE IN PRODUCTION!
2015-06-04 11:10:16.589:INFO:oejw.StandardDescriptorProcessor:main: NO JSP Support for /, did not find org.eclipse.jetty.jsp.JettyJspServlet
2015-06-04 11:10:16.628:INFO:oejsh.ContextHandler:main: Started o.e.j.w.WebAppContext#1a407d53{/,[file:///tmp/jetty-0.0.0.0-8080-ROOT.war-_-any-4510228025526425427.dir/webapp/, jar:file:///tmp/jetty-0.0.0.0-8080-ROOT.war-_-any-4510228025526425427.dir/webapp/WEB-INF/lib/example-async-rest-jar-9.3.0.v20150601.jar!/META-INF/resources],AVAILABLE}{/ROOT.war}
2015-06-04 11:10:16.645:INFO:oejs.ServerConnector:main: Started ServerConnector#3abbfa04{HTTP/1.1,[http/1.1]}{0.0.0.0:8080}
2015-06-04 11:10:16.646:INFO:oejs.Server:main: Started #634ms
Related
I am trying to connect JMSToolbox to an app that is driven by JMS queues running on OpenLiberty.
I am using Open liberty version 22. Specifically 22.0.0.11-202210101601
As far as I can tell, the correct documentation to follow is https://github.com/jmstoolbox/jmstoolbox/wiki/2.2-Setup-for-IBM-LibertyProfile
The installed features I have on the Open Liberty server from the documentation are as follows:
restConnector-2.0 (note restConnector-1.0 as specified in the
documentation does not seem to be available)
appSecurity-2.0
wasJmsClient-2.0
wasJmsServer-1.0
Note I was not able to install restConnector-1.0 from the documentation as I could only find restConnector-2.0.
For the extra jars, I was only able to find restConnector.jar
I could not find the other jars specified in the documentation:
com.ibm.ws.ejb.thinclient_x.y.z.jar (from <was_full_home>/runtimes)
com.ibm.ws.orb_x.y.z.jar (from <was_full_home>/runtimes)
com.ibm.ws.sib.client.thin.jms_x.y.z.jar (from
<was_full_home>/runtimes) (tested with x.z.y ==8.5.5.0+, 9.0.0.0)
Where do I get these jars from? I'm not sure what WAS Full Home means. Am I supposed to take them from a copy of WAS? Are these Jars proprietary?
Thanks,
John
"WAS full" refers to "traditional" WebSphere Application Server. You can download it following this page https://www.ibm.com/cloud/blog/websphere-trial-options-and-downloads
WAS full home is shorthand for WAS installation directory, typically /IBM/WebSphere/AppServer.
These jars are included in the /runtimes subdirectory after you installed the product.
So typical approach following above page would be:
download InstallationManager
install InstallationManager
install developers version either v9 (http://www.ibm.com/software/repositorymanager/com.ibm.websphere.ILAN.v90) or v8.5.5 (https://www.ibm.com/software/repositorymanager/com.ibm.websphere.DEVELOPERSILAN.v85)
copy required jars from the installation directory
... but that would take a while...
So alternatively you could (if you have docker), which should be much faster than whole mumbo-jumbo with installation:
pull WAS v8.5 or v9 version from here https://hub.docker.com/r/ibmcom/websphere-traditional
start container: docker run --name was-server -p 9043:9043 -p 9443:9443 -d ibmcom/websphere-traditional
locate required files:
$ cd opt/IBM/WebSphere/AppServer/runtimes/
$ ls -la
total 343540
com.ibm.jaxrs1.1.thinclient_9.0.jar
com.ibm.jaxrs2.0.thinclient_9.0.jar
com.ibm.jaxws.thinclient_9.0.jar
com.ibm.ws.admin.client.forJython21_9.0.jar
com.ibm.ws.admin.client_9.0.jar
com.ibm.ws.ejb.embeddableContainer_9.0.jar
com.ibm.ws.ejb.embeddableContainer_nls_9.0.jar
com.ibm.ws.ejb.portable_9.0.jar
com.ibm.ws.ejb.thinclient_9.0.jar
com.ibm.ws.jpa-2.0.thinclient_9.0.jar
com.ibm.ws.jpa-2.1.thinclient_9.0.jar
com.ibm.ws.messagingClient.jar
com.ibm.ws.orb_9.0.jar
com.ibm.ws.sib.client.thin.jms_9.0.jar
com.ibm.ws.sib.client_ExpeditorDRE_9.0.jar
com.ibm.ws.webservices.thinclient_9.0.jar
com.ibm.xml.thinclient_9.0.jar
endorsed
properties
sibc.jmsra.rar
sibc.nls.zip
copy required files from the container:
docker cp <containerID>:/opt/IBM/WebSphere/AppServer/runtimes/xyz.jar .
I have just installed Apache Tomcat9 on my machine, following mostly these instructions, but I am really stuck with user management here.
My enviroment: Ubuntu 20.04, Java 11 (There is only one alternative in link group java (providing /usr/bin/java): /usr/lib/jvm/java-11-oracle/bin/java).
Few exceptions: I neither have JAVA_HOME, nor the java home directory in my PATH environment variable.
I also have created a symlink at /opt/tomcat/latest/ for pointing to the right folder for all tomcat files.
Now I want to let tomcat run as a service as user 'tomcat'.
This is how my tomcat.service file looks like:
[Unit]
Description=Tomcat 9 servlet container
After=network.target
[Service]
Type=forking
User=tomcat
Group=tomcat
Environment="JAVA_HOME=/usr/lib/jvm/java-11-oracle/bin/java"
# Environment="JAVA_OPTS=-Djava.security.egd=file:///dev/urandom -Djava.awt.headless=true"
Environment="CATALINA_BASE=/opt/tomcat/latest"
Environment="CATALINA_HOME=/opt/tomcat/latest"
Environment="CATALINA_PID=/opt/tomcat/latest/tomcat.pid"
# Environment="CATALINA_OPTS=-Xms512M -Xmx1024M -server -XX:+UseParallelGC"
ExecStart=/opt/tomcat/latest/bin/startup.sh
ExecStop=/opt/tomcat/latest/bin/shutdown.sh
[Install]
WantedBy=multi-user.target
Now, when I comment out the line for the JAVA_HOME environment variable, the startup of the tomcat service fails (journalctl -xe):
Okt 27 17:43:52 my-user startup.sh[7714]: Tomcat started.
Okt 27 17:43:52 my-user shutdown.sh[7737]: PID file found but either no matching process was found or the current user does not have permission to stop the process. Stop aborted.
Okt 27 17:43:52 my-user sudo[7690]: pam_unix(sudo:session): session closed for user root
So there is something running as root, what I don't get.
But when I comment out this line, tomcat runs happily, but on localhost:8080 I am getting this 500:
Message org.apache.jasper.JasperException: java.lang.ClassNotFoundException: org.apache.jsp.index_jsp
or this 404
Message JSP file [/index.jsp] not found
It is similar like here and here.
I also did sudo chown -R tomcat /opt/tomcat/latest/work/Catalina/localhost, but this did not help.
Any help is appreciated.
Now it works and I'm going to list my changes here, but I'm not sure, which one was crucial and which was unnecessary.
JAVA_HOME in tomcat.service changed to: Environment="JAVA_HOME=/usr/lib/jvm/java-11-oracle"
CATALINA_PID in tomcat.service changed to: Environment="CATALINA_PID=/opt/tomcat/latest/temp/tomcat.pid"
give write access to other users to folders work, temp, logs, webapps. Sources here and here.
using this guide: https://www.interserver.net/tips/kb/install-apache-tomcat-on-ubuntu-18-04/
I'm creating a custom Dockerfile with extensions for official keycloak docker image. I want to change web-context and add some custom providers.
Here's my Dockerfile:
FROM jboss/keycloak:7.0.0
COPY startup-config.cli /opt/jboss/tools/cli/startup-config.cli
RUN /opt/jboss/keycloak/bin/jboss-cli.sh --connect --controller=localhost:9990 --file="/opt/jboss/tools/cli/startup-config.cli"
ENV KEYCLOAK_USER=admin
ENV KEYCLOAK_PASSWORD=admin
and startup-config.cli file:
/subsystem=keycloak-server/:write-attribute(name=web-context,value="keycloak/auth")
/subsystem=keycloak-server/:add(name=providers,value="module:module:x.y.z.some-custom-provider")
Bu unfortunately I receive such error:
The controller is not available at localhost:9990: java.net.ConnectException: WFLYPRT0053: Could not connect to remote+http://localhost:9990. The connection failed: WFLYPRT0053: Could not connect to remote+http://localhost:9990. The connection failed: Connection refused
The command '/bin/sh -c /opt/jboss/keycloak/bin/jboss-cli.sh --connect --controller=localhost:9990 --file="/opt/jboss/tools/cli/startup-config.cli"' returned a non-zero code: 1
Is it a matter of invalid localhost? How should I refer to the management API?
Edit: I also tried with ENTRYPOINT instead of RUN, but the same error occurred during container initialization.
You are trying to have Wildfly load your custom config file at build-time here. The trouble is, that the Wildfly server is not running while the Dockerfile is building.
Wildfly actually already has you covered regarding automatically loading custom config, there is built in support for what you want to do. You simply need to put your config file in a "magic location" inside the image.
You need to drop your config file here:
/opt/jboss/startup-scripts/
So that your Dockerfile looks like this:
FROM jboss/keycloak:7.0.0
COPY startup-config.cli /opt/jboss/startup-scripts/startup-config.cli
ENV KEYCLOAK_USER=admin
ENV KEYCLOAK_PASSWORD=admin
Excerpt from the keycloak documentation:
Adding custom script using Dockerfile
A custom script can be added by
creating your own Dockerfile:
FROM keycloak
COPY custom-scripts/ /opt/jboss/startup-scripts/
Now you can simply start the image, and the built features in keycloak (Wildfly feature really) will go look for a config in that spedific directory, and then attempt to load it up.
Edit from comment with final solution:
While the original answer solved the issue with being able to pass configuration to the server at all, an issue remained with the content of the script. The following error was received when starting the container:
=========================================================================
Executing cli script: /opt/jboss/startup-scripts/startup-config.cli
No connection to the controller.
=========================================================================
The issue turned out to be in the startup-config.cli script, where the jboss command embed-server was missing, needed to initiate a connection to the jboss instance. Also missing was the closing stop-embedded-server command. More about configuring jboss in this manner in the docs here: CHAPTER 8. EMBEDDING A SERVER FOR OFFLINE CONFIGURATION
The final script:
embed-server --std-out=echo
/subsystem=keycloak-server/theme=defaults/:write-attribute(name=cacheThemes,value=false)
/subsystem=keycloak-server/theme=defaults/:write-attribute(name=cacheTemplates,value=false)
stop-embedded-server
WildFly management interfaces are not available when building the Docker image. Your only option is to start the CLI in embedded mode as discussed here Running CLI commands in WildFly Dockerfile.
A more advanced approach consists in using the S2I installation scripts to trigger CLI commands.
How to wrap Spring Boot application as a linux daemon and to set it to read from application.properties.
To start the jar with the parameters from the application.properties I am using this command:
java -Dspring.config.location=/application.properties -jar MyJar.jar
Where to set this in wrapper.conf?
I have tried like this but the jar is not starting with the parameters from the application.properties.
wrapper.java.command=java
wrapper.java.command.loglevel=INFO
wrapper.java.mainclass=org.tanukisoftware.wrapper.WrapperJarApp
wrapper.java.classpath.1=../lib/wrapper.jar
wrapper.java.classpath.2=/opt/MyService/lib/MyApp.jar
wrapper.java.library.path.1=../lib
wrapper.logfile=../logs/wrapper.log
wrapper.app.parameter.1=/opt/MyService/lib/MyApp.jar
wrapper.app.parameter.2=-c
wrapper.app.parameter.3=/opt/MyService/lib/conf
Try with this:
wrapper.java.additional.1=-Dspring.config.location=/opt/MyService/lib/conf/application.properties
I'm running Jetty as a service (followed these instructions) on an Ubuntu 14 server. It's been configured to run on port 9000, and it seems to this just fine.
On the same server, I have a solr instance folder (it's located outside of jetty, as part of a website).
What I would like, is to be able to browse to hostname:9000/solr and hostname:9000/solr/admin and then see/manage the data that's in my solr instance folder, but all I ever get from the Jetty service are 404-errors.
The instance itself works perfectly if I start it manually by running 'java -Djetty.port=9000 -jar start.jar' - however, this is not what I want.
What do I need to do?
Edit: Here is the output from service jetty check
root#ubuntu14:/opt/web/mybase/webapps# service jetty check
Checking arguments to Jetty:
START_INI = /opt/web/mybase/start.ini
JETTY_HOME = /opt/jetty/jetty-distribution-9.2.7.v20150116
JETTY_BASE = /opt/web/mybase
JETTY_CONF = /opt/jetty/jetty-distribution-9.2.7.v20150116/etc/jetty.conf
JETTY_PID = /var/run/jetty.pid
JETTY_START = /opt/jetty/jetty-distribution-9.2.7.v20150116/start.jar
JETTY_LOGS = /opt/web/mybase/logs
JETTY_STATE = /opt/web/mybase/jetty.state
CLASSPATH =
JAVA = /usr/bin/java
JAVA_OPTIONS = -Dsolr.solr.home=/var/www/mywebsite/private/my-solr-4.7 -Djetty.logs=/opt/web/mybase/logs -Djetty.home=/opt/jetty/jetty-distribution-9.2.7.v20150116 -Djetty.base=/opt/web/mybase -Djava.io.tmpdir=/opt/jetty/temp
JETTY_ARGS = jetty.state=/opt/web/mybase/jetty.state jetty-logging.xml jetty-started.xml
RUN_CMD = /usr/bin/java -Dsolr.solr.home=/var/www/mywebsite/private/my-solr-4.7 -Djetty.logs=/opt/web/mybase/logs -Djetty.home=/opt/jetty/jetty-distribution-9.2.7.v20150116 -Djetty.base=/opt/web/mybase -Djava.io.tmpdir=/opt/jetty/temp -jar /opt/jetty/jetty-distribution-9.2.7.v20150116/start.jar jetty.state=/opt/web/mybase/jetty.state jetty-logging.xml jetty-started.xml
Jetty running pid=4728
First make sure you have deployed the solr.war file correctly into Jetty as described here. Basically you have 2 options -
Copy the war file into the JETTY_HOME/webapps directory
Add the war file path into $JETTY_HOME/contexts/context.xml file
This will deploy Solr into jetty.
To run Solr, set the Dsolr.solr.home system property to point to your Solr root directory e.g. java -Dsolr.solr.home= -jar start.jar