IBM Mobilefirst 8 error with the configure-tomcat-mysql.xml config file - ibm-mobilefirst

I get the following error when I run the configure-tomcat-mysql.xml. This script is provided in the installation folder and I have made the necessary changes.
BUILD FAILED
/home/madmin/software/ibm/configure-tomcat-mysql.xml:143: The element <applicationserver> inside <installmobilefirstadmin>, Tomcat version cannot be defined.
server details:
1.8.0_181
Linux Ubuntu 16.04
ant 1.9.6
tomcat 8
mysql:5.7.23
MFP V8
Thanks for your help
==UPDATE ---
I install tomcat 7 and had the same issue
Using CATALINA_BASE: /usr/share/tomcat7
Using CATALINA_HOME: /usr/share/tomcat7
Using CATALINA_TMPDIR: /usr/share/tomcat7/temp
Using JRE_HOME: /usr
Using CLASSPATH: /usr/share/tomcat7/bin/bootstrap.jar:/usr/share/tomcat7/bin/tomcat-juli.jar
Server version: Apache Tomcat/7.0.68 (Ubuntu)
Server built: Jun 27 2016 18:13:17 UTC
Server number: 7.0.68.0
OS Name: Linux
OS Version: 4.15.0-1015-gcp
Architecture: amd64
JVM Version: 1.8.0_181-8u181-b13-0ubuntu0.16.04.1-b13
[installmobilefirstadmin] [13/08/2018 16:01:16:631 UTC] Mon Aug 13 16:01:16 UTC 2018 WARN: Establishing SSL connec
tion without server's identity verification is not recommended. According to MySQL 5.5.45+, 5.6.26+ and 5.7.6+ req
uirements SSL connection must be established by default if explicit option isn't set. For compliance with existing
applications not using SSL the verifyServerCertificate property is set to 'false'. You need either to explicitly
disable SSL by setting useSSL=false, or set useSSL=true and provide truststore for server certificate verification
.
BUILD FAILED
/home/madmin/configure-tomcat-mysql.xml:143: The element <applicationserver> inside <installmobilefirstadmin>, Tom
cat version cannot be defined.
== Update 2 ===
I redo the entire install by downloading again the V8 zip file and the install manager but I get the same result
Can you let me know how to debug or resolve this issue

Related

Plain vanilla Apache Ignite cluster fails setting state back to ACTIVE

I've got a plain vanilla install of ignite 2.14, with the binaries downloaded from https://ignite.apache.org/download.cgi (exact link https://dlcdn.apache.org/ignite/2.14.0/apache-ignite-2.14.0-bin.zip). I'm on Windows 10, IGNITE_HOME is not set in the PATH (this is optional), and Ignite's using this java runtime:
OpenJDK Runtime Environment 1.8.0_201-2-redhat-b09 Oracle Corporation
OpenJDK 64-Bit Server VM 25.201-b09
I start an ignite node using the default configuration provided in the downloaded zip apache-ignite-2.14.0-bin.zip :
ignite.bat ..\config\default-config.xml
This starts fine. Following the instructions at https://ignite.apache.org/docs/latest/tools/control-script I can check the state and see I've got a single node cluster in state ACTIVE (the default-config.xml must not have native persistence enabled, so the cluster goes to ACTIVE state automatically).
I can then set the state to INACTIVE like so:
control.bat --set-state INACTIVE
This works fine. However if I set the state to active again like so:
control.bat --set-state ACTIVE
I get the error pasted below and the cluster stays in the INACTIVE state. I first came across this error when using Ignite in embedded server mode, but I can still reproduce it with a fresh out-of-the-box ignite install (not using embedded). I'm surprised that a plain vanilla install just calling a couple of basic commands falls over like this. Any idea what's happening?
This is the error:
C:\temp\apache-ignite-2.14.0-bin\bin>control.bat --set-state ACTIVE
Nov 17, 2022 4:27:17 PM
org.apache.ignite.internal.client.impl.connection.GridClientNioTcpConnection
INFO: Client TCP connection established: /127.0.0.1:11211 Nov
17, 2022 4:27:17 PM
org.apache.ignite.internal.client.impl.connection.GridClientNioTcpConnection
close INFO: Client TCP connection closed: /127.0.0.1:11211 Nov 17,
2022 4:27:17 PM org.apache.ignite.internal.client.util.GridClientUtils
shutdownNow WARNING: Runnable tasks outlived thread pool executor
service [owner=GridClientConnectionManager,
tasks=[java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask#6d7b4f4c]]
Control utility [ver. 2.14.0#20220929-sha1:951e8deb] 2022 Copyright(C)
Apache Software Foundation User: info Time: 2022-11-17T16:27:16.344
null suppressed:
Command [SET-STATE] finished with code: 4 Error stack trace: class
org.apache.ignite.internal.client.GridClientException: null
suppressed:
at org.apache.ignite.internal.client.impl.connection.GridClientNioTcpConnection.handleClientResponse(GridClientNioTcpConnection.java:632)
at org.apache.ignite.internal.client.impl.connection.GridClientNioTcpConnection.handleResponse(GridClientNioTcpConnection.java:563)
at org.apache.ignite.internal.client.impl.connection.GridClientConnectionManagerAdapter$NioListener.onMessage(GridClientConnectionManagerAdapter.java:691)
at org.apache.ignite.internal.util.nio.GridNioFilterChain$TailFilter.onMessageReceived(GridNioFilterChain.java:279)
at org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:109)
at org.apache.ignite.internal.util.nio.GridNioCodecFilter.onMessageReceived(GridNioCodecFilter.java:116)
at org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:109)
at org.apache.ignite.internal.util.nio.GridNioServer$HeadFilter.onMessageReceived(GridNioServer.java:3734)
at org.apache.ignite.internal.util.nio.GridNioFilterChain.onMessageReceived(GridNioFilterChain.java:175)
at org.apache.ignite.internal.util.nio.GridNioServer$ByteBufferNioClientWorker.processRead(GridNioServer.java:1211)
at org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.processSelectedKeysOptimized(GridNioServer.java:2508)
at org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.bodyInternal(GridNioServer.java:2273)
at org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.body(GridNioServer.java:1910)
at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
at java.lang.Thread.run(Thread.java:748)
Control utility has completed execution at: 2022-11-17T16:27:17.642
Execution time: 1298 ms Press any key to continue . . .
It's a known issue, which is, unfortunately, not fixed yet.
As a workaround, you can execute the command with the autoconfirmation flag --yes, as shown below:
control.bat --set-state ACTIVE --yes

Problems with CATALINA_PID and ARTIFACTORY_PID while upgrading Artifactory to the latest version

While upgrading my Artifactory server (free OSS version) from the version 5.2.0 to the latest 5.4.5, I was hit by an ARTIFACTORY_PID problem.
After migrating from 5.3.2 to 5.4.0, the Artifactory server did not want to start anymore complaining about
PID file /var/opt/jfrog/run/artifactory.pid not readable (yet?) after start.
I found the only way around it is to remove the line export CATALINA_PID=$ARTIFACTORY_PID from the setenv.sh of the tomcat.
Note that upgrade from 5.2.0 to 5.3.2 went smoothly.
However, after upgrading from 5.4.0 to the latest 5.4.5 this trick does not work anymore. Now I get an error:
Job for artifactory.service failed because a configured resource limit was exceeded. See "systemctl status artifactory.service" and "journalctl -xe" for details.
And when executing service artifactory status, I get:
● artifactory.service - Setup Systemd script for Artifactory in Tomcat Servlet Engine
Loaded: loaded (/usr/lib/systemd/system/artifactory.service; enabled; vendor preset: disabled)
Active: activating (auto-restart) (Result: resources) since Tue 2017-07-25 09:40:10 CEST; 4s ago
Process: 31912 ExecStart=/opt/jfrog/artifactory/bin/artifactoryManage.sh start (code=exited, status=0/SUCCESS)
Jul 25 09:40:10 linux systemd[1]: Failed to start Setup Systemd script for Artifactory in Tomcat Servlet Engine.
Jul 25 09:40:10 linux systemd[1]: Unit artifactory.service entered failed state.
Jul 25 09:40:10 linux systemd[1]: artifactory.service failed.
In fact Artifactory is now running showing version 5.4.5, but I am not happy about all those errors above.
Plus I am a bit failing to understand the purpose of CATALINA_PID and/or ARTIFACTORY_PID. Why the tomcat was failing on the startup because of this file? What was wrong with the permissions? I think I did no extra actions before.
The only difference that before it was installed from an official downloaded rpm. But now using an official remote yum repo.
If I try to create an empty /var/opt/jfrog/run/artifactory.pid file, while Artifactory is running, it gets deleted. Who is deleting this file and why? Is it a standard tomcat behavior?
OS: CentOS 7, up to date.
In my case (in a slow virtual machine) the error message from the command artifactoryManage.sh start was:
ERROR: Artifactory Tomcat server did not start in 60 seconds. Please check the logs
The log file told that the only problem was slowness (/var/opt/jfrog/artifactory/logs/artifactory.log):
### Artifactory successfully started (64.802 seconds) ###
The problem was solved by adding a longer timeout to the service definition at /etc/systemd/system/artifactory.service:
[Service]
Environment=START_TMO=120
After editing the service definition, as you know, systemctl daemon-reload was needed.
Run this script:
/opt/jfrog/artifactory/bin/artifactoryManage.sh start
It will show the exact error to you.
In my case it was java version not updated. So I updated to java 1.8.

command start-domain failed glassfish 4.1

I successfully installed glassfish 4.1 on my centos server via ssh but I am unable to start the server.
when I type ./asadmin start-domain I got this error below.
Waiting for domain1 to start ......Error starting domain domain1.
The server exited prematurely with exit code 137.
Before it died, it produced the following output:
Launching GlassFish on Felix platform
Registered com.sun.enterprise.glassfish.bootstrap.osgi.EmbeddedOSGiGlassFishRuntime#33903879 in service registry.
Nov 24, 2014 10:42:08 PM com.sun.enterprise.glassfish.bootstrap.osgi.BundleProvisioner createBundleProvisioner
INFO: Create bundle provisioner class = class com.sun.enterprise.glassfish.bootstrap.osgi.BundleProvisioner.
Nov 24, 2014 10:42:08 PM com.sun.enterprise.glassfish.bootstrap.osgi.BundleProvisioner$DefaultCustomizer getLocations
WARNING: Skipping entry because it is not an absolute URI.
Nov 24, 2014 10:42:08 PM com.sun.enterprise.glassfish.bootstrap.osgi.BundleProvisioner$DefaultCustomizer getLocations
WARNING: Skipping entry because it is not an absolute URI.
Command start-domain failed.
Can anyone help with this one?
Thanks.
It seems that Glassfish cannot start because an address is trying to bind is already in use.
Shutting down server due to startup exception
java.net.BindException: Address already in use: bind
Try to edit the domain.xml.
/glassfish/domains/domain1/config/domain.xml
The most common problem would be that the http-listener ports are reused by another application. Find the following lines:
name="http-listener-1" port="8080" name="http-listener-1" port="9090"
And replace them with something like:
name="http-listener-2" port="8181" name="http-listener-2" port="9191"
You can also read more about the domain.xml

IBM Worklight 6.2. Analytics installation on Linux 64 bits. Issue with lib libsigar-amd64-linux.so

I' trying to install analytics in a WAS 8.5 standalone server in a Linux redhat 6 64 bits.
uname -a
Linux localhost.localdomain 2.6.32-71.el6.x86_64 #1 SMP Wed Sep 1 01:33:01 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux
After installing the .war in the server and configuring the classloader with parent last, when I try to access to the console I get this exception in the log although the console is displayed.
[8/6/14 12:31:16:501 EDT] 00000051 SystemOut O 0 [WebContainer : 1] DEBUG Sigar - libsigar-amd64-linux.so (Not found in java.library.path)
org.hyperic.sigar.SigarException: libsigar-amd64-linux.so (Not found in java.library.path)
at org.hyperic.sigar.Sigar.loadLibrary(Sigar.java:172)
at org.hyperic.sigar.Sigar.<clinit>(Sigar.java:100)
at java.lang.J9VMInternals.initializeImpl(Native Method)
at java.lang.J9VMInternals.initialize(J9VMInternals.java:236)
at org.elasticsearch.monitor.sigar.SigarService.<init>(SigarService.java:40)
at org.elasticsearch.monitor.MonitorModule.configure(MonitorModule.java:81)
at org.elasticsearch.common.inject.AbstractModule.configure(AbstractModule.java:60)
at org.elasticsearch.common.inject.spi.Elements$RecordingBinder.install(Elements.java:204)
I have not found any documentation about this in the Knowledge center or even in google.
We have tried with yum but we haven't found the lib.
Any hint?
This is a defect. The workaround is to open the analytics WAR file and delete the following directory:
WEB-INF/lib/sigar
The analytics console isn't using sigar, so there shouldn't be any issues when deleting this folder.

error starting tomee server from eclipse servers tab

My OS is win 7 ultimate 32 bit
After installing JDK 7u9, eclipse Juno (4.2) SR1 for Java EE
and finally adding into it the new server
Apache TomEE 1.5.0 October 2nd, 2012 apache-tomee-1.5.0-webprofile.zip
(using eclipse wizard to add new servers and choosing tomcat 7 profile and then the directory where it's installed)
i'm getting the following console error
...
...
...
nov 13, 2012 8:07:53 PM org.apache.tomee.catalina.OpenEJBContextConfig processAnnotationsFile
SEVERE: OpenEJBContextConfig.processAnnotationsFile: failed.
java.util.regex.PatternSyntaxException: Illegal/unsupported escape sequence near index 32
C:\workspace\.metadata\.plugins\org.eclipse.wst.server.core\tmp0\wtpwebapps\testtomee01\WEB-INF\classes
^
at java.util.regex.Pattern.error(Unknown Source)
...
...
...
the server, eventually seems to start but then you get the 404 error on every page under http://localhost:8080/
tomEE installation directory is C:\apache-tomee-webprofile-1.5.0
eclipse installation directory is C:\eclipse
and java jre under C:\Program Files\Java\jre7
It looks like the current Windows release is broken. You'll have to download a fixed version as suggested in the bug report found here: https://issues.apache.org/jira/browse/TOMEE-436
The 1.5.1 snapshots are available for download here: 1.5.1-SNAPSHOT
Yes, should have been fixed and included in the next release (1.5.1).
FYI, it should be available next week.
Jean-Louis