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
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'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.
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
I'm trying to run Jetty on CentOS and am having problems as I am getting unexpected results when I try to set the full path for JETTY_LOGS. The system tries to take that path and append it to the path I specified in the JETTY_HOME variable.
JETTY_HOME=/usr/local/jetty/jetty-9.1.4
JETTY_USER=jetty
JETTY_PORT=8085
JETTY_HOST=0.0.0.0
JETTY_LOGS=/usr/local/jetty/jetty-9.1.4/logs
Any ideas as to what I'm doing wrong?
The error I get is:
Starting Jetty: java.io.IOException: Cannot write start.log to directory
/usr/local/jetty/jetty-9.1.4/usr/local/jetty/jetty-9.1.4/logs [directory doesn't exist or is read-only]
java.io.IOException: Cannot write start.log to directory /usr/local/jetty/jetty-9.1.4/usr/local/jetty/jetty-9.1.4/logs [directory doesn't exist or is read-only]
at org.eclipse.jetty.start.StartLog.initLogFile(StartLog.java:127)
at org.eclipse.jetty.start.StartLog.initialize(StartLog.java:113)
at org.eclipse.jetty.start.Main.processCommandLine(Main.java:520)
at org.eclipse.jetty.start.Main.main(Main.java:102)
It seems that JETTY_LOG directory is relative to JETTY_HOME.
Could you try to set:
JETTY_LOGS=/logs
or alternatively
JETTY_HOME=/usr/local/jetty/jetty-9.1.4/
JETTY_LOGS=logs
You're not doing anything wrong, this is new behavior in jetty 9.1.4:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=432192
Workaround is to set the JETTY_LOGS env var relative to your jetty base dir (like the logs dir that comes in the standard jetty tarball):
JETTY_LOGS=logs
Which will resolve to /usr/local/jetty/jetty-9.1.4/logs in your case (the jetty base dir defaults to the jetty home dir).
If you want the logs written somewhere outside of your jetty base dir, the best way is to use the above JETTY_LOGS=logs env setting, and just symlink the dir elsewhere; like this to create and link to the common /var/log/jetty dir:
# mv /usr/local/jetty/jetty-9.1.4/logs /var/log/jetty
# ln -s /var/log/jetty /usr/local/jetty/jetty-9.1.4/logs
Whatever you do, also make sure that the user as which you run jetty has write access to the logs dir; if you use the jetty user in the jetty group, make it the owner of your logs dir:
# chown -R jetty:jetty /var/log/jetty
I want to basically upgrade my tomcat version(on RHEL).
Always worked in an environment where my war file would be dumped into */webapps, on restart of tomcat, the war file would expand and the rest is history.
Now, the system I'm working on, has completely different folder structure.
Something like this:
[root#bliss ~]# ls /usr/local/blah/blu-app/WEB-INF/
accounts faces-reports.xml logging.properties web-app_2_3.dtd
bin faces-syscfg.xml logging.properties-production web-app_2_4.xsd
buildnum.txt framework2007 perl web.xml
classes host.xsd settings work
deploy-root java.policy tags
events.xsd lib tld
[root#bliss ~]#
I can see some tomcat related jars here:
/usr/local/blah/blu-app/WEB-INF/lib/tomcat-http.jar
/usr/local/blah/blu-app/WEB-INF/lib/tomcat-util.jar
/usr/local/blah/blu-app/WEB-INF/lib/tomcat-coyote.jar
UPDATE
So I did find out that the tomcat is embedded 'cuz I found the following code starting it:
tomcat = new Embedded();
tomcat.setCatalinaHome(targetPath);
Host host = tomcat.createHost("localhost", targetPath);
Context rootCtx = tomcat.createContext("", targetPath);
((StandardContext)rootCtx).setWorkDir("WEB-INF/work");
ServletContext servletContext = rootCtx.getServletContext();
servletContext.setAttribute("version", version);
ApplRealm realm = new ApplRealm(servletContext);
tomcat.setRealm(realm);
rootCtx.setPrivileged(true);
Engine engine = tomcat.createEngine();
engine.setName("tomcat");
engine.setDefaultHost("localhost");
host.addChild(rootCtx);
engine.addChild(host);
tomcat.addEngine(engine);
LOG.debug("starting tomcat");
tomcat.start();
LOG.debug("tomcat started");
// clear out any old sessions: see bug 17882
Session[] sessions = rootCtx.getManager().findSessions();
for (int i = 0; i < sessions.length; i++)
{
sessions[i].expire();
}
ServerSocket socket = null;
socket = new ServerSocket(CmcUtils.getControlPort(), 2, InetAddress.getByName("127.0.0.1"));
socket.accept();
LOG.info("Received shutdown command. Exiting !");
tomcat.stop();
The question then is, how do I upgrade this tomcat to say Tomcat6?
Replace with the latest jars in WEB-INF/lib? Which all jars?
It depends. It could be an embedded tomcat but it could also be a heavily customised tomcat configuration.
Check the startup script to determine which class is being invoked. If its the usual catalina its not embedded its just that they changed the config to point to another folder instead of webapps.
If it is indeed embedded then to upgrade u would need to replace the tomcat jars with new ones.
In tomcat we can create virtual hosts,i.e, making tomcat recognize application's which are deployed in external folders.
A lot more information can be found here.
http://tomcat.apache.org/tomcat-5.5-doc/config/host.html
In your given scenario, try to lookup in server.xml, which is usually found in conf folder of tomcat home.