2017-01-28 9 views
0

Versuch Liferay 7 Bündel auf z, SLES12 mit IBM Java 8. Ich erhalte den folgenden Fehler laufen, wenn startup.sh ausgeführt wird:Liferay 7 mit IBM Java javax.crypto Fehler

27-Jan-2017 17:00:14.652 INFO [localhost-startStop-1] org.apache.catalina.startup.HostConfig.deployDescriptor Deploying configuration descriptor /data/liferay/tomcat-8.0.32/conf/Catalina/localhost/ROOT.xml 
27-Jan-2017 17:00:15.342 INFO [localhost-startStop-1] org.apache.catalina.util.ExtensionValidator.validateManifestResources ExtensionValidator[][file:/data/liferay/tomcat-8.0.32/webapps/ROOT/WEB-INF/classes/META-INF/MANIFEST.MF]: Required extension [javax.crypto] not found. 
27-Jan-2017 17:00:15.343 INFO [localhost-startStop-1] org.apache.catalina.util.ExtensionValidator.validateManifestResources ExtensionValidator[]: Failure to find [1] required extension(s). 
27-Jan-2017 17:00:15.343 SEVERE [localhost-startStop-1] org.apache.catalina.core.StandardContext.startInternal One or more components marked the context as not correctly configured 
27-Jan-2017 17:00:15.344 SEVERE [localhost-startStop-1] org.apache.catalina.core.StandardContext.startInternal Context [] startup failed due to previous errors 
27-Jan-2017 17:00:15.349 WARNING [localhost-startStop-1] org.apache.catalina.deploy.NamingResourcesImpl.cleanUp Failed to retrieve JNDI naming context for container [StandardEngine[Catalina].StandardHost[localhost].StandardContext[]] so no cleanup was performed for that container 
javax.naming.NameNotFoundException: Name [comp/env] is not bound in this Context. Unable to find [comp]. 
    at org.apache.naming.NamingContext.lookup(NamingContext.java:818) 
    at org.apache.naming.NamingContext.lookup(NamingContext.java:166) 
    at org.apache.catalina.deploy.NamingResourcesImpl.cleanUp(NamingResourcesImpl.java:993) 
    at org.apache.catalina.deploy.NamingResourcesImpl.stopInternal(NamingResourcesImpl.java:975) 
    at org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:224) 
    at org.apache.catalina.core.StandardContext.stopInternal(StandardContext.java:5492) 
    at org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:224) 
    at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:159) 
    at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:725) 
    at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:701) 
    at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:717) 
    at org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:585) 
    at org.apache.catalina.startup.HostConfig$DeployDescriptor.run(HostConfig.java:1794) 
    at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:522) 
    at java.util.concurrent.FutureTask.run(FutureTask.java:277) 
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153) 
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) 
    at java.lang.Thread.run(Thread.java:785) 

27-Jan-2017 17:00:15.352 INFO [localhost-startStop-1] org.apache.catalina.startup.HostConfig.deployDescriptor Deployment of configuration descriptor /data/liferay/tomcat-8.0.32/conf/Catalina/localhost/ROOT.xml has finished in 699 ms 
27-Jan-2017 17:00:15.354 INFO [main] org.apache.catalina.startup.Catalina.start Server startup in 752 ms 
27-Jan-2017 17:00:15.356 SEVERE [main] org.apache.catalina.core.StandardServer.await StandardServer.await: create[localhost:8005]: 
java.net.BindException: Address already in use 
    at java.net.PlainSocketImpl.socketBind(Native Method) 
    at java.net.AbstractPlainSocketImpl.bind(AbstractPlainSocketImpl.java:417) 
    at java.net.ServerSocket.bind(ServerSocket.java:444) 
    at java.net.ServerSocket.<init>(ServerSocket.java:258) 
    at org.apache.catalina.core.StandardServer.await(StandardServer.java:420) 
    at org.apache.catalina.startup.Catalina.await(Catalina.java:717) 
    at org.apache.catalina.startup.Catalina.start(Catalina.java:663) 
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) 
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) 
    at java.lang.reflect.Method.invoke(Method.java:508) 
    at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:351) 
    at org.apache.catalina.startup.Bootstrap 

    .main(Bootstrap.java:485) 

Java-Version :

java version "1.8.0" 
Java(TM) SE Runtime Environment (build pxz6480sr3fp21-20161117_02(SR3 FP21)) 
IBM J9 VM (build 2.8, JRE 1.8.0 Linux s390x-64 Compressed References 20161114_325917 (JIT enabled, AOT enabled) 
J9VM - R28_20161114_0146_B325917 
JIT - tr.r14.java.green_20161111_127476 
GC - R28_20161114_0146_B325917_CMPRSS 
J9CL - 20161114_325917) 
JCL - 20161116_01 based on Oracle jdk8u111-b14 

ich kann die

Erforderliche Erweiterung [javax.crypto] nicht

gefunden zu löschen scheinen

Fehler und frage mich, ob jemand weiß, ob:

  1. IBM Java mit Liferay kompatibel ist 7
  2. es eine Möglichkeit ist, die Oracle Java-Sicherheitspaket anstelle von IBMs
zu verwenden

Wenn jemand irgendwelche Informationen darüber hat, wie ich Liferay 7 in der aktuellen Umgebung zum Laufen bringen kann, würde ich es sehr schätzen.

+0

Töte jeden Prozess, der unter 8005 läuft –

Antwort

0

Ans 2. javax.crypto Paket sollte in IBM Java vorhanden sein - in rt.jar. Wenn Sie dies direkt durch ein Oracle-Paket ersetzen, kann dies die Funktionen der Java-Klassenbibliothek von IBM beeinträchtigen, da sie eine geringfügig andere Struktur und Implementierung aufweisen.

+0

Idealerweise sollte IBM Java SE kein Problem haben, irgendetwas auszuführen, das auf Oracle Java SE läuft. Ich frage mich, ob das Startskript eine Abhängigkeit hat, die auf der Oracle Java Klassenstruktur beruht. Ich werde prüfen, ob ich etwas finden kann. – imkabir

+0

Vielen Dank imkabir ... siehe meine Anmerkung oben. – user2305363

0

Vielen Dank für Ihre Eingabe. Wir haben das Problem gelöst, indem wir eine MANIFEST.MF-Datei (im Liferay 7-Bundle-Tomcat-Verzeichnis) entfernt haben, die speziell auf die Java-Crypto von Oracle verweist. Als wir diese Datei entfernten, wurde sie ohne den Fehler gestartet. Seitdem sehen wir eine Meldung in den Protokollen mit der Auswirkung, dass "Oracle-Crypto-Datei nicht gefunden wird, sondern IBM verwendet".

Keine anderen Probleme beim Start vorhanden.