Payara 5.2020.4 didn't start - java

I've jdk1.8.0_171 installed on my windows 10, 64bit OS , yesterday I've downloaded Payara Micro Community 5.2020.4 and added the server on Netbeans 8.2 , but when I try to start the sever NetBeans Payara server log shows following error
Error: Could not find or load main class [9|]--add-opens=java.logging.java.util.logging=ALL-UNNAMED
Need clues to resolve this error
Thanks in advance

This is due to a change in Payara Server configuration that's not compatible with how the older version of the Netbeans Payara (GlassFish) plugin launches Payara Server. The plugin uses a hacky mechanism that reads the domain configuration and launches the Java process of Payara Server directly instead of using the asadmin launcher.
You can easily fix this by editing the domain.xml file in glassfish/domains/domain1/config/domain.xml. Just remove all jvm-option elements where you find [ and ] brackets. These define the Java version for which the JVM option is applicable. Usually this is for running on JDK 9+, so it's safe to remove those options if you run on Java 8.
So, remove this option and all similar options:
<jvm-option>[9|]--add-opens=java.logging.java.util.logging=ALL-UNNAMED</jvm-option>
Upgrading Netbeans to the latest version 12.1 also fixes this problem as Netbeans has been updated to understand this change in the configuration.

I have got a similar problem with jdk1.8.0_311 , payara-5.2021.10 on netbeans 8.2 . payara start successfully in a terminal with command :
glassfish/bin/asadmin start-domain
, but when I start the server inside netbeans, i have some errors :
Unrecognized VM option 'UseOpenJSSE'
Unrecognized VM option 'HotswapAgent=core'
Unrecognized option: -Xlog:redefine+class*=info
The solution by OndroMih works fine.
I have removed this lines in domain.xml. "glassfish/domains/domain1/config/domain.xml"
<jvm-options>[Azul-1.8.0u222|1.8.0u260]-XX:+UseOpenJSSE</jvm-options>
<jvm-options>[Dynamic Code Evolution-11.0.10|]-XX:HotswapAgent=core</jvm-options>
<jvm-options>[Dynamic Code Evolution-11.0.10|]-Xlog:redefine+class*=info</jvm-options>
now its ok

Solution to Payara 5.184 / Netbeans 8.2 / Java 8 Not launching Payara:
in file:
\payara5\glassfish\domains\domain1\config\domain.xml
Search for the unrecognized option UseOpenJSSE and comment that tag.
Repeat for each occurrence.
Repeat as well for subsequent errors might appear.
Good Luck!

Related

Glassfish 5 not working with Intellij 2017 2.4

I am new to Intellij ide and i'm having issues running Glassfish 5 or any previous version on Intellij 2017 2.4.
After selecting New Project > Java Enterprise > Web Application i had to specify the application server, to which i selected the folder of glassfish 5, jdk is set to 1.8 and java ee to 7. So far so good, no errors and the project gets created. Then i have a greyed "play" icon next to GlassFish 5.0.0 in the upper right of the corner that says that i have to configure it, i click Edit Configurations and the Run/Debug Configurations opens up
Everything seems fine and when i click the "play" green button to start the server and run the project i have projectName:war exploded under Deployment and
[2017-09-26 08:47:57,836] Artifact testfornew:war exploded: Waiting for server connection to start artifact deployment...
Detected server admin port: 4848
Detected server http port: 8080
Exception in thread "main" java.lang.NullPointerException
at com.sun.enterprise.module.common_impl.AbstractModulesRegistryImpl.initializeServiceLocator(AbstractModulesRegistryImpl.java:152)
at com.sun.enterprise.module.common_impl.AbstractModulesRegistryImpl.newServiceLocator(AbstractModulesRegistryImpl.java:144)
at com.sun.enterprise.module.common_impl.AbstractModulesRegistryImpl.createServiceLocator(AbstractModulesRegistryImpl.java:218)
at com.sun.enterprise.module.common_impl.AbstractModulesRegistryImpl.createServiceLocator(AbstractModulesRegistryImpl.java:224)
at com.sun.enterprise.module.single.StaticModulesRegistry.createServiceLocator(StaticModulesRegistry.java:88)
at com.sun.enterprise.admin.cli.CLIContainer.getServiceLocator(CLIContainer.java:217)
at com.sun.enterprise.admin.cli.CLIContainer.getLocalCommand(CLIContainer.java:255)
at com.sun.enterprise.admin.cli.CLICommand.getCommand(CLICommand.java:231)
at com.sun.enterprise.admin.cli.AdminMain.executeCommand(AdminMain.java:371)
at com.sun.enterprise.admin.cli.AdminMain.doMain(AdminMain.java:306)
at org.glassfish.admin.cli.AsadminMain.main(AsadminMain.java:57)
Under output. Coming from Netbeans setting glassfish up was pretty straightforward, i've checked a couple of solutions online including this but they don't seem to work for me.
I was having the same problem and I found that it is caused by an issue with the JDK software. So the NullPointerException thrown at AsadminMain.java:57 can be solved by checking your system variables (PATH, JAVA_HOME). Be sure that they reference to an acceptable JDK supported by your GlassFish version. GlassFish 5.0 is certified to work with java sdk 8u144 as mentioned HERE: https://javaee.github.io/glassfish/doc/5.0/release-notes.pdf.
Be aware, the path may also contain a reference to an old SDK directory.
If you need more help, please post the results of calling echo %PATH% on your cmd.
In my case JDK 1.8.0_152 must be installed, path and java_home variables have to be configured AND JDK 9.X must be uninstalled. Without uninstall, the error persist.
Uninstall Java 9, stay with the version 8 update 162 and the jdk8. When you unistall the Java 9 your system variables (PATH, JAVA_HOME=C:\ProgramData\Oracle\Java\javapath) will update the 3 jar (java, javaw, javaws) in this path to Java version 8.
war exploded: Waiting for server connection to start artifact deployment...
Detected server admin port: 4848
Detected server http port: 8080
....
Assuming that you are certain that JDK has set well in your environment variables and you are using jdk 8 or lower-Well I read somewhere that java9 has issues with such configurations, maybe the issue has been solve but for my case I chose to avoid for now.
Download and extract GlassFish of your version. For my case I'm
using GlassFish 5.181.O on Intellij 2018.1 ultimate version
Start Intellij, and before opening any project, or rather close all projects that are open.
Click on configure, then settings. A new window will appear as shown below. I have marked the steps you need to follow in the image. I will also add some explanation here.
Under Application Servers, click on the + shown as step 2 on the image, here you need to specify you glassfish server, the folder where you extracted to.
Next, click on + shown in step 3 on the image to add the server modules.
Assuming all is a success upto this point, select all choices of as shown in step 4 on the image, apply changes and Ok.
I will explain about creating a new project because I'm not sure how you would handle an existing project but I guess you can use concepts here to figure out what you need to tweak.Create your new java ee or whatever application you are working on,
As shown on figure 2, assuming you are creating a Java EE app, Click on Java Enterprise, then check/tick Web Application and JSF
Under libraries, use library from Glassfish ... Installation didn't help much because I got null pointer exceptions., so I used Download as shown in figure 2. Click next and finish.
Automatically you will see GlassFish added to the project, run it from the IDE.
Edit
If you had done all of the above and still get some error like Null Pointer Exceptions. Do what #Jailson Evora says: Clear your systems from java 9 and install java 8 and make sure when you issue java -version on command line, the output is java 8
I had to uninstall both jdk9 and jdk10 and set my java_home back to jdk8_181

Tomcat 7.0.73 doesn't work with java 9

Unable to start tomcat based app with java 9 because of default "java.endorsed.dirs" option in catalina.sh.
-Djava.endorsed.dirs=/usr/local/share/tomcat/endorsed is not supported. Endorsed standards and standalone APIs in modular form will be supported via the concept of upgradeable modules.
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
Is there a work around for this?
You'll have to hack the script bin/catalina.sh to get this to work.
There are a bunch of lines like this in bin/catalina.sh:
exec "$_RUNJDB" "$LOGGING_CONFIG" $LOGGING_MANAGER $JAVA_OPTS $CATALINA_OPTS \
-Djava.endorsed.dirs="$JAVA_ENDORSED_DIRS" -classpath "$CLASSPATH" \
...
Just remove the second of those lines (the one with -Djava.endorsed.dirs) in each case and you should be back in business.
I'm looking at improving those scripts so that -Djava.endorsed.dirs is not provided to the JVM when the value is empty (which should be the case if you are using Java 9).
UPDATE 2017-11-06
Looks like r1810284 should fix the endorsed.dirs problem. Expect this fix to be included in Tomcat 7.0.83 (or whatever the next 7.0.x version passes voting).
UPDATE 2018-03-07
The first official release of Apache tomcat 7.0.x that includes this fix is Apache Tomcat 7.0.84, voted stable on 2018-01-24.
The above issue was fixed with the later releases of Eclipse but Unfortunately, it appeared again with the release of Java 10. Here is my research :
Initially, I installed Java 10 and Eclipse Oxygen 3 which gave me the same error you mentioned in your question. But, at the moment I installed Java 9 and pointed my Apache tomcat runtime server to it, the error was gone.
In my case, what I did to answer the problem of Tomcat not running was to set Tomcat (version 7) with a lower Java version (e.g. Java 8).
Then, in startup.sh, shutdown.sh and catalina.sh I added the following:
export JAVA_HOME=`/usr/libexec/java_home -v 1.8`;
This symptom can come about if you have a Tomcat Runtime using a JRE earlier than Java 9 and create and run a server with that runtime. Then edit the Tomcat Runtime to use Java 9 and try to start the server. What happens is that a "-Djava.endorsed.dirs" argument gets added to the launch configuration when the server was run with the earlier JRE. When running the server after the switch to Java 9, the "-Djava.endorsed.dirs" argument is seen as a user added VM argument and kept, resulting in the error.
The simplest way to fix is to recreate the server. You can also right click on the server in the servers view and select Open. In the window that opens, click the "Open launch configuration" link at the bottom of the General section. In the dialog that opens, switch to the Arguments tab and in the "VM arguments" section, edit out the "-Djava.endorsed.dirs" argument and click OK. You should be able to start the server now.
To fix this bug, you need to install/update the Eclipse Web Tools Platform (WTP) to version 3.9.4 or later.
Select Help > Install new Software...
Select or add following URL: http://download.eclipse.org/webtools/repository/oxygen
Check Web Tools Platform (WTP) 3.9.4
Select "Next" and follow instructions
Reconfigure the tomcat in eclipse.
In Run configurations -> Arguments -> VM arguments
try removing
-Djava.endorsed.dirs="C:\Program Files\Apache Software Foundation\Tomcat 8.5\endorsed"
You have to remove -
"-Djava.endorsed.dirs="/home/ttlaptop/Downloads/apache-tomcat-7.0.105/endorsed"
from run configurations, and then tomcat will start
I can't be sure but ..
Step 1 -- >
it worked for me, I just remove servers from eclipse
Step 2 -->
restarted and add server again (tomcat 7)
Tomcat v7.0 Server at localhost

Problems with glassfish 4 Debug in IDEA 12.1

I'm trying to debug glassfish 4 application in IntelliJ IDEA12.1 and am getting the following:
D:\tools\glassfish4\glassfish\bin\asadmin.bat start-domain --debug domain1
[2013-06-28 03:58:34,480] Artifact exchange-web:war: Server is not connected. Deploy is not available.
Detected server admin port: 4848
Detected server http port: 8080
Attempting to start domain1.... Please look at the server log for more details.....
But nothing started. And there is no error in log.
So what should I do to resolve this?
Had also trouble with that after upgrading to GF 4.1. Problem was, that IntelliJ itself was running under 1.6 VM. GF 4.1 comes with 1.7 compiled classes. Switching IntelliJ JDK to 1.7 solved that deployment trouble.
It is a tricky one. When you add an artifact in the deployment tab, you see a warning message in the bottom (If you not, just resize the window enough):
Debug settings are invalid or not suitable for local debugging
Then just click to the button fix.
There is similar error (Server is not connected. Deploy is not available.) with IDEA 13.1.* and Glassfish 4.1. Upgrading intellij JDK to 1.7 or 1.8 solved this problem.
Go Intellij.App/Contents modify Info.plist upgrade JVMVersion 1.6* to 1.7*
As banterCZ explained. If the button fix does not react, It can also be a permission problem. You can also start IntelliJ as Administrator, and click to the button fix If it does not work.
FIX for Mac:
1) Open Terminal (make sure IDEA is closed)
2) type: vi "/Applications/IntelliJ IDEA 13.app/Contents/Info.plist"
3) Find Line with JWMVersion
4) on your keyboard click key "i" and change the value from 1.6* to 1.8*
5) Press ESC
6) Press Command + key ":"
7) input "wq"
8) Start IDEA
Actually the situation was same here for IntelliJ 15.0.2 and Glassfish 4.1.1. But it was not a problem of JDK incompatibility here, because I used JDK 1.8. Instead, it was the invalid details of server configuration. This kind of situation can occur with an invalid password, VM and other details.
I had this problem with the Payara server and the fix button did not worked.
The solution was to add the same server using the GlassFish plugin and click on the fix button. This also fixed the Payara server configuration.
I had the same problem with glassfish 6.0.0 and intellij idea with java jdk 14. Solved it by installing the jdk 1.8 and changing the settings of the project.

Java Exception when Trying to Run Grails

All - I just downloaded the latest grails (2.1.0) and JDK (1.7.0_07) on my Win7 64bit machine and configured my machine as follows:
1.) Added environment variables for Java and Grails
2.) Update PATH as appropriate
3.) Verified that everything installed correctly by executing java -version and grails -version
The java -version command works, and shows the following:
java version "1.7.0_07"
Java(TM) SE Runtime Environment (build 1.7.0_07-b10)
Java HotSpot(TM) 64-Bit Server VM (build 23.3-b01, mixed mode)
but the grails -version command yields the following error:
Exception: java.lang.RuntimeException thrown from the UncaughtExceptionHandler in thread “main”
I tried debugging by completely uninstalling all Java, then reinstalling, but the same error occurs. I verified that I installed the 64 bit version of Java.
More information about the error can be found at this website (Mike [the owner] directed me to Stackoverflow for more help).
Any idea is to why this occurred? What can I do to get Grails working? Thanks in advance for your help.
-Tom
Edit 1 from Vector's comment:
All variables are set properly and shown here:
GRAILS_HOME = C:\grails\grails-2.1.0
JAVA_HOME = C:\Program Files\Java\jdk1.7.0_07
Path = [lots of other stuff];%JAVA_HOME%\bin;%GRAILS_HOME%\bin;
Edit 2 Fixed java version number at top of problem statement (version is 1.7.0_07) per #crudolf
Answer: Thou shalt ensurest that thine box is set to Administrator . . . and the people rejoiced.
Apparently, Grails wants to write to C:\Users\Administrator.grails and C:\Users\Administrator.groovy. Even though I had admin rights on my machine (since I successfully installed Java), I apparently needed to click through into the Administrator folder in order for the preferences to be written that I wanted to use JDK.
All is well. Thanks everyone for your help.
I ran into this error after attempting to upgrade from Grails 2.1.0 to Grails 2.2.1 on Windows 7.
I simply had to delete the C:\User\%USERNAME%\.grails and C:\User\%USERNAME%\.groovy folders created by and leftover from Grails 2.1.0.
It appeared that Grails was loading some leftover cached JARs or configuration files of .grails and .groovy instead of %GRAILS_HOME%.
It took hours, but I learned my lesson - delete ".grails" and ".groovy" before running a new version of Grails!
I ran into this problem with Grails 2.4.0 and 2.2.4 on Windows 8.1 Pro. I noticed that the problem did not occur if I ran the grails command in an administrator cmd-shell. I then checked my Appdata\Local\Temp. It turned out that the security setting for the temp folder needed to be changed. After I gave Everyone the full access to Appdata\Local\Temp folder, the problem was solved. But you may need to check the security setting often because some Windows Apps reset the security setting.
I was having the same problem. I was having a working grails-2.2.4 with java-1.7.25 on a Windows 7 x86. But it suddenly stopped working today. I tried removing ~/.groovy and ~/.grails, but still got java.lang.RuntimeException thrown from the UncaughtExceptionHandler.
Finally, the problem was solved by removing ~/.m2 as well.
BTW, "set DEBUG=1" before starting "grails" in a Command Prompt will show the environment and parameters to launch Java.exe.
I was having a similar problem but in Ubuntu 12.04. I solved it by removing $GROOVY_HOME environment variable. If you also have $GROOVY_HOME variable try removing it.
Try deleting the file .grails_history file located in your %Home% directory.
This worked for me on Windows 8.1

Tomcat 6.0.18 service will not start on a windows server

I installed Tomcat 6.0.18 on a windows server 2003 box and it will not start as a service.
I'm running it with jdk 1.6.0_07.
It runs when I start it with tomcat6.exe.
I got a vague error in the System Event Log on Windows.
The Apache Tomcat 6 service terminated with service-specific error 0 (0x0).
I'll bite it :-)
Tomcat Service on windows is dependent on the MS C Runtime library msvcr71.dll. As long as it is in the path, the service will start just fine.
Just to prevent your other windows to be forced to use this version of the runtime library, you might want to copy the DLL to just the tomcat bin path instead of windows\system32.
From gobaco.wordpress.com
Tomcat 6 couldn’t find a file called msvcr71.dll.
I just copied it over from
c:\windows\microsoft.net\framework\v1.1.4322
to
c:\windows\system32
and was able to start tomcat.
I thought this was very strange, so I wanted to post it on SO in case anyone else runs into this problem. If someone wants to post the same answer I'll accept it.
i follow the above guide but still the same, error 0,
my process monitor log at http://www.sendspace.com/file/t0tahr
I solved the same problem enabling the default java virtual machine in the configuration app.
Assuming you have installed tomcat using:
service install tomcat-6.0.35
execute:
tomcat6w //ES/tomcat-6.0.35
a window pops up, select the java tab and click on "Use default" checkbox.
The service install script (I immagine) selected C:\Program Files(x86)\Java\jre\bin\client\jvm.dll instead.
Environment:
Windows Server standard SP2 64-bin
Java 1.6.0_23-b05 (Java hotspot 64-bit server vm 19.0-b09 mixed mode)
Apache tomcat 6.35 (you guessed this didn't you?)
I copied the msvcr71.dll from the java home directory to the bin directory of the apache-tomcat install, and the service started after that.
Even though it's an older post, I thought I'd share the knowledge about the very same issue I had, but the workaround was different.
The Apache Tomcat 7 service terminated with service-specific error 0 (0x0).
As there was no more information regarding the problem I went back to the Tomcat Control Panel and had a look at the Java path, which was pointed to an earlier installation of Java Virtual Machine:
C:\Program Files\Java\jre6\bin\client\jvm.dll, which no longer existed, so I had to change the JRE version to jre7.
Having done that, the service started up and all running now.
Hope it'll help some of you out there.

Categories

Resources