Getting handshake_failure when pulling dependencies from Maven on EC2 Instance - java

This is only happens to 3rd party Maven repository for ElasticSearch on EC2 instance. It's working fine locally.
https://maven.elasticsearch.org/releases
Is it a configuration issue?
[ERROR] Failed to execute goal on project system-s: Could not resolve
dependencies for project com.7leaf:system-s:jar:0.0.1: Failed to collect
dependencies at org.elasticsearch.plugin:shield:jar:2.4.1: Failed to read
artifact descriptor for org.elasticsearch.plugin:shield:jar:2.4.1: Could not
transfer artifact org.elasticsearch.plugin:shield:pom:2.4.1 from/to es-repo
(https://maven.elasticsearch.org/releases): Received fatal alert:
handshake_failure -> [Help 1]
This is the Maven and Java version on the server.
Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T16:41:47+00:00)
Maven home: /usr/share/apache-maven
Java version: 1.8.0_101, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.101-3.b13.24.amzn1.x86_64/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "4.4.23-31.51.amzn1.x86_64", arch: "amd64", family: "unix"

After trying out a few things, I found out that the issue is SSL and for this case, I'm able to switch to use non-SSL endpoint instead to solve the issue.
Switch to use
http://maven.elasticsearch.org/releases
instead of
https://maven.elasticsearch.org/releases

Related

AxisFault: Unsupported type http://www.myexternalservice.com/externalsoftware Custom_Type

I have an external SOAP service (page .asmx).
From .asmx, I save his WSDL (go to http://www.myexternalservice.com/myservice.asmx?WSDL and then save the wsdl file in a folder of my pc: myservice.wsdl).
With Axis 1.8.2, Java JDK 1.8.0_341 and wsdl2tojava.bat I create the .java file (Hanlder and Stub). From prompt:
C:\axis2-1.8.2\bin>wsdl2java.bat -uri C:\wsdl\myservice.wsdl
(no errors from prompt).
I create a Java-Maven project, I insert these maven references:
groupId: org.apache.axis2, artifactId: axis2, version: 1.8.2
groupId: org.apache.axis2, artifactId: axis2-adb, version: 1.8.2
groupId: org.apache.axis2, artifactId: axis2-kernel, version: 1.8.2
groupId: org.apache.axis2, artifactId: axis2-transport-local, version: 1.8.2
groupId: org.apache.axis2, artifactId: axis2-transport-http, version: 1.8.2
When I try to invoke a soap-action, I have this error: AxisFault - Unsupported type http://www.myexternalservice.com/externalsoftware MY_Custom_Type
The page .asmx and WSDL is correct beacuse it isn't a my service (it's an external service, I known that there aren't errors from application-server of external service) and from an application in C# I can invoke that soap-action without problems.
I think it's a problem about Axis? How can I solve my problem?
That soap call returns an XML object and I get same information from it.
But I can't get these information from soap call.

jhipster giving autoloader error while generating an application

I am working macOS Big Sur 11.2.3, with java version "14.0.1" 2020-04-14, node v16.1.0, git version 2.24.3 (Apple Git-128), and maven
Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
Maven home: /usr/local/Cellar/maven/3.6.3_1/libexec
Java version: 14.0.1, vendor: N/A, runtime: /usr/local/Cellar/openjdk/14.0.1/libexec/openjdk.jdk/Contents/Home
Default locale: en_IN, platform encoding: UTF-8
OS name: "mac os x", version: "10.16", arch: "x86_64", family: "mac"
I have installed Jhipster with below command and is successfully installed.
sudo npm install -g generator-jhipster
But now when I type the command jhipster to generate the application in a new project folder, I am getting below error. I have no clue what went wrong and how to resolve this. can any one help me on this please.
Error: editions-autoloader-invalid-engines: The edition had no engines to compare against the environment
at new Errlop (/usr/local/lib/node_modules/generator-jhipster/node_modules/errlop/edition-es5/index.js:61:18)
at Object.errtion (/usr/local/lib/node_modules/generator-jhipster/node_modules/editions/edition-es5/util.js:23:14)
at isCompatibleEngines (/usr/local/lib/node_modules/generator-jhipster/node_modules/editions/edition-es5/index.js:183:19)
at isCompatibleEdition (/usr/local/lib/node_modules/generator-jhipster/node_modules/editions/edition-es5/index.js:250:10)
at determineEdition (/usr/local/lib/node_modules/generator-jhipster/node_modules/editions/edition-es5/index.js:287:4)
at determineEdition (/usr/local/lib/node_modules/generator-jhipster/node_modules/editions/edition-es5/index.js:312:12)
at solicitEdition (/usr/local/lib/node_modules/generator-jhipster/node_modules/editions/edition-es5/index.js:350:16)
at Object.requirePackage (/usr/local/lib/node_modules/generator-jhipster/node_modules/editions/edition-es5/index.js:364:9)
at Object.<anonymous> (/usr/local/lib/node_modules/generator-jhipster/node_modules/istextorbinary/index.cjs:4:38)
at Module._compile (node:internal/modules/cjs/loader:1109:14) {
klass: [Function: Errlop] {
create: [Function (anonymous)],
isErrlop: [Function (anonymous)],
ensure: [Function (anonymous)]
},
parent: undefined,
ancestors: [],
orphanStack: 'Error: editions-autoloader-invalid-engines: The edition had no engines to compare against the environment\n' +
' at new Errlop (/usr/local/lib/node_modules/generator-jhipster/node_modules/errlop/edition-es5/index.js:61:18)\n' +
' at Object.errtion (/usr/local/lib/node_modules/generator-jhipster/node_modules/editions/edition-es5/util.js:23:14)\n' +
' at isCompatibleEngines (/usr/local/lib/node_modules/generator-jhipster/node_modules/editions/edition-es5/index.js:183:19)\n' +
' at isCompatibleEdition (/usr/local/lib/node_modules/generator-jhipster/node_modules/editions/edition-es5/index.js:250:10)\n' +
' at determineEdition (/usr/local/lib/node_modules/generator-jhipster/node_modules/editions/edition-es5/index.js:287:4)\n' +
' at determineEdition (/usr/local/lib/node_modules/generator-jhipster/node_modules/editions/edition-es5/index.js:312:12)\n' +
' at solicitEdition (/usr/local/lib/node_modules/generator-jhipster/node_modules/editions/edition-es5/index.js:350:16)\n' +
' at Object.requirePackage (/usr/local/lib/node_modules/generator-jhipster/node_modules/editions/edition-es5/index.js:364:9)\n' +
' at Object.<anonymous> (/usr/local/lib/node_modules/generator-jhipster/node_modules/istextorbinary/index.cjs:4:38)\n' +
' at Module._compile (node:internal/modules/cjs/loader:1109:14)',
code: 'editions-autoloader-invalid-engines'
}
Always use an LTS 64-bit version of Node as stated in the JHipster doc

Deployment via tomcat7-maven-plugin keeps adding "/deploy?path" to the target path

I'm trying to deploy a new version of my app to the path /app-test using the ## notation.
I've set the warFileName in pom.xml to be app-test##2021-01-21-pkix-fix and then called
mvn clean tomcat7:deploy
which generates and builds a .war successfully:
...
[INFO] Generating war /xyz/target/app-test##2021-01-21-pkix-fix.war
[INFO] Building war: /xyz/target/app-test##2021-01-21-pkix-fix.war
As it proceeds to upload the resources, it tries to do so multiple times while adding /deploy?path for the 2nd time. The third attempt makes even less sense:
[INFO] Deploying war to http://mydomain.eu/app-test##2021-01-21-pkix-fix
Uploading: http://mydomain.eu/manager/text/deploy?path=%2Fapp-test%23%232021-01-21-pkix-fix
Uploaded: http://mydomain.eu/manager/text/deploy?path=%2Fapp-test%23%232021-01-21-pkix-fix
Uploading: https://mydomain.eu/manager/text/deploy?path=%2Fapp-test%23%232021-01-21-pkix-fix/deploy?path=%2Fapp-test%23%232021-01-21-pkix-fix
Uploaded: https://mydomain.eu/manager/text/deploy?path=%2Fapp-test%23%232021-01-21-pkix-fix/deploy?path=%2Fapp-test%23%232021-01-21-pkix-fix
Uploading: https://mydomain.eu/manager/text/deploy?path=%2Fapp-test%23%232021-01-21-pkix-fix/deploy?path=%2Fapp-test%23%232021-01-21-pkix-fix
Uploaded: https://mydomain.eu/manager/text/deploy?path=%2Fapp-test%23%232021-01-21-pkix-fix/deploy?path=%2Fapp-test%23%232021-01-21-pkix-fix
The deployment then fails:
FAIL - Failed to deploy application at context path /app-test##2021-01-21-pkix-fix/deploy?path=/app-test##2021-01-21-pkix-fix
because paths must not contain the = char which is confirmed by the catalina-daemon.out error log:
...
javax.management.MalformedObjectNameException: Invalid character '=' in value part of property
at javax.management.ObjectName.construct(ObjectName.java:618)
at javax.management.ObjectName.<init>(ObjectName.java:1382)
...
Here's my condensed pom.xml.
I suspect this has to do with my relatively recent mvn upgrade through homebrew. Here's my current version:
Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
Maven home: /usr/local/Cellar/maven/3.6.3_1/libexec
Java version: 1.8.0_112, vendor: Oracle Corporation, runtime: /Library/Java/JavaVirtualMachines/jdk1.8.0_112.jdk/Contents/Home/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "10.16", arch: "x86_64", family: "mac"
Why does tomcat keep adding /deploy?path to my deployments?
As I'm investigating further, it's likely it's related to the tomcat7-maven-plugin but the docs haven't really clarified anything.
When all else fails, there's always the option to deploy the .war manually.
Package the program first:
mvn clean package [-P profile_name]
and then locate the .war in /target:

Random failure on Hudson for Maven builds

Since migrating to Maven, a lot of Java project builds on Hudson randomly fail with the following error message:
[ERROR] Process did not initiate connection and is still alive; killing it
[ERROR] Failure: hudson.AbortException: Process failed to connect; exit code: 143
ERROR: Process failed to connect; exit code: 143
The build queue is not full. The next build usually works just fine. Any clues on what is happening?
I'm using Hudson version 3.2.1 with Hudson Maven3 Plug-in version 3.0.4
Full log (edited for simplicity/security):
Started by user anonymous
Building on master
Updating {svn path} revision: {date} depth:infinity ignoreExternals: false
At revision {number}
no change for {svn path} since the previous build
[INFO] Using bundled Maven 3 installation
[INFO] Checking Maven 3 installation environment
[workspace] $ {maven home}/mvn --help
[INFO] Checking Maven 3 installation version
[INFO] Detected Maven 3 installation version: 3.1.1
[workspace] $ {maven home}/mvn clean package -V -B -Dmaven.ext.class.path={classpath} -Dhudson.eventspy.port=54304 -f pom.xml
[DEBUG] Waiting for connection on port: 54304
Apache Maven 3.1.1 (0728685237757ffbf44136acec0402957f723d9a; 2013-09-17 12:22:22-0300)
Maven home: {maven home}
Java version: 1.6.0_22, vendor: Sun Microsystems Inc.
Java home: {java home}
Default locale: en_US, platform encoding: ISO-8859-1
OS name: "linux", version: "2.6.18-407.el5", arch: "amd64", family: "unix"
[ERROR] Process did not initiate connection and is still alive; killing it
[ERROR] Failure: hudson.AbortException: Process failed to connect; exit code: 143
ERROR: Process failed to connect; exit code: 143
Sending e-mails to: {e-mail}
[DEBUG] Skipping watched dependency update for build: project-trunk #6 due to result: FAILURE
Finished: FAILURE
Since having random failures defeats the whole purpose of having a continuous integration tool, the answer is moving on to Jenkins for better Maven support.

Emacs Java Malabar Mode

I was using JDEE for my java projects in Emacs. JDEE does not work well for maven. Recently I came across Malabar Mode which has better support for Maven based Java projects in Emacs.
I managed to install malbar-mode using melpa in M-x list-packages. But when I'm getting error message on mvn package for my simple app https://github.com/vijayendra/JavaSrc/tree/master/my-app
Projects.get('/home/egnyte/src/my-app/pom.xml', []).run(['package'], [], [:])
[INFO] Scanning for projects...
[INFO] ------------------------------------------------------------------------
[INFO] Building my-app Maven Webapp 1.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 0.081s
[INFO] Finished at: Sat Dec 06 23:55:22 PST 2014
[INFO] Final Memory: 20M/48M
[INFO] ------------------------------------------------------------------------
[ERROR] Execution error
org.apache.maven.plugin.PluginResolutionException: Plugin org.apache.maven.plugins:maven-resources-plugin:2.5 or one of its dependencies could not be resolved: Failed to read artifact descriptor for or\
g.apache.maven.plugins:maven-resources-plugin:jar:2.5
at org.apache.maven.plugin.internal.DefaultPluginDependenciesResolver.resolve(DefaultPluginDependenciesResolver.java:129)
at org.apache.maven.plugin.internal.DefaultMavenPluginManager.getPluginDescriptor(DefaultMavenPluginManager.java:142)
at org.apache.maven.plugin.internal.DefaultMavenPluginManager.getMojoDescriptor(DefaultMavenPluginManager.java:261)
at org.apache.maven.plugin.DefaultBuildPluginManager.getMojoDescriptor(DefaultBuildPluginManager.java:185)
My emacs version is as follows:
emacs -version
GNU Emacs 24.3.1
Copyright (C) 2013 Free Software Foundation, Inc.
GNU Emacs comes with ABSOLUTELY NO WARRANTY.
You may redistribute copies of Emacs
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING.
My .emacs file is as follows:
(require 'package) ;; You might already have this line
(add-to-list 'package-archives
'("melpa-stable" . "http://stable.melpa.org/packages/") t)
;; unstable packages
;; (add-to-list 'package-archives
;; '("melpa" . "http://melpa.org/packages/") t)
(when (< emacs-major-version 24)
;; For important compatibility libraries like cl-lib
(add-to-list 'package-archives '("gnu" . "http://elpa.gnu.org/packages/")))
(package-initialize) ;; You might already have this line
(require 'cedet)
(require 'semantic)
(load "semantic/loaddefs.el")
(semantic-mode 1)
(setq malabar-groovy-lib-dir "~/.m2/repository/com/software-ninja/malabar/1.5.10")
(require 'malabar-mode)
(add-to-list 'auto-mode-alist '("\\.java\\'" . malabar-mode))
My maven version is as follows:
mvn -version
Apache Maven 3.2.3 (33f8c3e1027c3ddde99d3cdebad2656a31e8fdf4; 2014-08-11T13:58:10-07:00)
Maven home: /home/egnyte/lib/apache-maven-3.2.3
Java version: 1.7.0_65, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-7-openjdk-amd64/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "3.8.0-29-generic", arch: "amd64", family: "unix"
How can I get malabar mode to work?
There are two answers.
First, malabar-mode is stuck at maven 3.0.4 so try that version. Also do not set the lib dir. It should be set automatically.
Second, in order to get around the maven version I am rewriting malabar-mode from scratch. Follow the instructions at https://github.com/m0smith/malabar-mode/blob/develop/doc/2.0/INSTALL.md. This version should work for all versions of maven after 3.0.4. It is a work in progress and not all the features are there yet.
If you have problems or suggestions create an issue in the GitHub repo as now is a good time to get your wishes known
EDIT: 2.0 of malabar has been released to MELPA. To install now:
```
(load-file "~/projects/cedet/cedet-devel-load.el")
(add-hook 'after-init-hook (lambda ()
(message "activate-malabar-mode")
(activate-malabar-mode)))
(add-hook 'malabar-java-mode-hook 'flycheck-mode)
(add-hook 'malabar-groovy-mode-hook 'flycheck-mode)
```

Categories

Resources