class java.lang.RuntimeException in glassfish when i try to create new JDBC Resources - glassfish

class java.lang.RuntimeException in glassfish when i try to create new JDBC Resources.
This is the exception. Following is the snapshot:

I've been having same issues with the latest Glassfish 4.1. I couldn't find any solution on how to resolve RuntimeException when using web interface to add new resources. From what I understand it is a major bug that hasn't been resolved yet (GLASSFISH-21437). Meanwhile, I manually add JDBC Connection Pool and JDBC Resource entries by modifying domain.xml file located in the domain's config folder:
glassfish4/glassfish/domains/domain1/config/domain.xml
Just make sure that you make a backup copy just in case you make a mistake. You will need to restart Glassfish.
You can also use asadmin CLI commands to add resources. I have not done this myself but instructions on how to do that can be found in Glassfish administration guide (chapter 5).
I hope this helps.

I had the same issue. I found the only solution to replace glassfish 4.1.1 with version 4.1.0. This fixed my problem.

I have found that BUG is fixed (https://java.net/jira/browse/GLASSFISH-21314). I created JDBC resurce without exception

Update to 4.1.2 .
I had the same issue with Glassfish 4.1.1 , until now I set up all with asadmin commands , but the bug has been fixed with version 4.1.2 , no more exception thrown while creating new JDBC ressources .

I have to download another version of glassfish, in my case "GlassFish 5.0 - Web Profile" https://javaee.github.io/glassfish/download , after in netbeans i removed the old GlassFish setting up the new version and everything was fine.

Related

couldnt create db schema "ACT_RU_IDENTITYLINK" in flowable engine

I have Spring Boot (2.3.4) app runs on Tomcat (9). When i try to build the project, flowable(6.6.0) engine gives this error. Schema is already created but it tries to create again. My problem is, i cannot deploy war code to the server because of it.
I upgraded flowable-engine version 6.6.0 to 6.7.0, and its solved.

How to Fix No MBean found for Worklight project?

I have a problem when deploying my Worklight project on the server . It shows the following Error Message :
FWLSE3041E: No MBean found for Worklight project 'MyProject'. Possibly the Worklight runtime web application for Worklight project 'MyProject' is not running. If it is running, use JConsole to inspect the available MBeans.
and when I tried to preview my application it showed this message :
SRVE0777E: Exception thrown by application class 'com.worklight.core.auth.impl.AuthenticationFilter.verifyServletInitialized:420'
I had the same issue using Worklight 6.2 CLI, but recreating the project did not work.
One issue that I had was that worklight did not build a .war-file properly, so I copied the .war-file from a backup.
Edit: This happens regularly in our project now, and we have no idea why. We fix it by invoking any procedure, which makes it work until you restart the server. Worklight must be building something when invoking a procedure that it does not do when building.
I Solved The problem by creating a new Worklight Project and copied all my files , it works just fine :) I used Worklight 6.1 instead of 6.2
I solved this by fixing a recently created security test in
server/conf/authenticationConfig.xml
The problem was I mispelled the Realm name I previously defined.
I solved this problem by deleting the application from the worklight server and rebuild it.
Delete WorklightServerConfig folder in workspace and rebuild your application.
I was able to fix this in MobileFirst 7.0 (Fka Worklight) by opening the Servers view, Window -> Show View -> Servers. Then expanding the MobileFirst Development Server and right click on the project in question, chose delete.
Once you do that go back to the applications' directory in the "apps" directory and right click -> Run As -> Run On MobileFirst Development Server
This should rebuild and deploy the project on the server.
I solved the problem by using ibm jdk not open jdk. My solution is to make sure the env parameters are correct
export JAVA_HOME = $your_ibm_jdk
export PATH + $your_ibm_jdk/bin:$PATH
run java -version to make sure the setting work

This class does not support SAAJ 1.3

In trying to call a webservice from a portlet from Glassfish to a webservice hosted remotely on weblogic we are getting this error:
Caused by: java.lang.UnsupportedOperationException: This class does not support SAAJ 1.3
at weblogic.webservice.core.soap.SOAPHeaderImpl.addHeaderElement(SOAPHeaderImpl.java:178)
I added the webservicesclient.jar from WebLogic to the portlet WAR file.
How is the best way to handle this problem?
EDIT: Adding webservicesclient.jar was the wrong thing to do. I removed the jar file and that fixed the problem. The underlying problem was also fixed with a restart.
Answered my own question. See edit in the question:
EDIT: Adding webservicesclient.jar was the wrong thing to do. I removed the jar file and that fixed the problem. The underlying problem was also fixed with a restart.

How to Upgrade glassfish?

I want to upgrade Glassfish without internet connection. But I have already downloaded the latest version.
I have done the following steps,
For eg. galssfish-3.0 is the older version and glassfish-3.1 is the newer version.
Step: 1
I just copied the glassfish-3.0/glassfish/domains/domain1 and pasted in glassfish-3.1/glassfish/domains
Step: 2
In glassfish-3.1/bin ./asadmin i just give the command asadmin> start-domain --upgrade
then i checked the version asadmin> version the ouput was
Version = GlassFish Server Open Source Edition 3.1.1 (build 12)
Command version executed successfully.
Is this correct or I need to follow some other ways to achieve this? If wrong Please guide me the right way.
Can anyone help me?
Thanks in advance,
Gnik
Regarding the Oracle GlassFish Server 3.1 Upgrade Guide you did it right.
There are some hints in this guide for the migration of deployed applications:
Application archives (EAR files) and component archives (JAR, WAR, and
RAR files) that are deployed in the source server do not require any
modification to run on Oracle GlassFish Server 3.1. Components that
may have incompatibilities are deployed on GlassFish Server 3.1 with
the compatibility property set to v2 and will run without change on
GlassFish Server 3.1. You may, however, want to consider modifying the
applications to conform to Java EE 6 requirements.
...
Applications and components that are deployed in the source server are
deployed on the target server during the upgrade. Applications that do
not deploy successfully on the target server must be deployed manually
on the target server by the user.
If a domain contains information about a deployed application and the
installed application components do not agree with the configuration
information, the configuration is migrated unchanged, without any
attempt to reconfigure the incorrect configurations.
You should read through the guide carefully and check your deployed applications for any errors / exceptions during server startup or manual redeployment.
Some time ago I made an update as described in the update guide from 3.0 to 3.1.1 and cannot remember any bigger problems.

HSQLDB is working on Windows but throws exceptions on Linux

This is really annoying: my java web-application deployed on Windows Tomcat runs perfectly. When application is deployed to Linux HSQLDB starts throwing exeptions about bad SQL grammar and syntax of elementary SQL statements. Like "DROP TABLE Test IF EXISTS" "IF EXISTS" is an error or "double" type is not supported. I tested with hsql 2.1.0 and hsql 1.8.1 - same errors.
My brain is in real stackoverflow. Am I struggling with a known issue?
P.S.
After further investigation it shows that my web-application of Linux suddenly switches to DBCP of Tomcat instead of using DBCP in the WEB-INF/lib
HSQLDB does not run differently in Linux. It is possible that an earlier version Jar is in Tomcat's classpath in Linux. In this situation, classes from the early jar may be picked up.
It is possible to add a test to your app to detect the existence of early version Jars.
For example DatabaseMetaData#getDriverVersion() will report the version of the jar.
I appologize for the question. The cause of the problem had nothing to do with HSQL database. The datasource was created using Spring and I was using th same name for teh datasource bean in two different places.