Skip to main content

Wildfly EJB Remote Client Exceptions.......

Below are exceptions and the solutions I applied while developing a remote client enterprise application.

To start with, enable debug for your application server to see the detail and good luck troubleshooting.

Exceptions :
Starting with  java.lang.ClassNotFoundException: org.hibernate.collection.internal.Persistent.........

Solution :
I fixed the exception be adding hibernate Entity Manager Dependencies.

Exception:
Error javax.naming.NoInitialContextException: Need to specify class name in environment or system property, or as an applet parameter, or in an application resource file:  java.naming.factory.initial

Solution:
Add JBOSS-CLIENT Dependencies to your project


Exception:
IllegalStateException: EJBCLIENT000025: No EJB receiver available for handling

Solution:
Confirm that your EJB module have been deployed.


Exception:
org.jboss.naming.remote.client.initialcontextfactory wildfly
   
javax.naming.NamingException: WFLYNAM0027: Failed instantiate InitialContextFactory org.jboss.naming.remote.client.InitialContextFactory from classloader

javax.naming.namenotfoundexception while trying to lookup ejb
Caused by: org.jboss.modules.ModuleNotFoundException:  xxxxx:main

Solution:
Pay close attention to your JNDI context lookup URL.

Follow the link below, it might point you in the right direction

 https://docs.jboss.org/author/display/WFLY8/JNDI+Reference?_sscc=t



Exception:
Caused by: java.lang.NoClassDefFoundError:

Solutions:
After adding manifest to the calling jar/war, goto the dependencies manifest and add the meta-inf for access to the meta-inf.

for example, your manifest file of TemplateClient.jar should look like

Manifest-Version: 1.0
Dependencies: lib/TemplateEJB-1.0-SNAPSHOT.jar export meta-inf

suppose TemplateEJB-xxx is being called from TemplateClient.jar

Read https://docs.jboss.org/author/display/WFLY10/Class+Loading+in+WildFly.



In conclusion, for remote client, on wildfly, your project pom should look like

      <dependency>
            <groupId>org.wildfly</groupId>
            <artifactId>wildfly-ejb-client-bom</artifactId>
            <version>10.0.0.Final</version>
            <type>pom</type>
        </dependency>

        <dependency>
            <groupId>org.jboss.remoting</groupId>
            <artifactId>jboss-remoting</artifactId>
            <version>4.0.21.Final</version>
            <scope>runtime</scope>
        </dependency>
       
        <dependency>
            <groupId>org.jboss</groupId>
            <artifactId>jboss-remote-naming</artifactId>
            <version>2.0.4.Final</version>
            <scope>runtime</scope>
        </dependency>



Comments

Post a Comment

Popular posts from this blog

Fix HTTP error code 513 on Wildfly

The Mysterious Case of TIME_WAIT and IDLE Connections Have you ever encountered a network issue where your server is consistently showing a high number of connections in the TIME_WAIT and IDLE states? This phenomenon can be frustrating, especially when it indicates that the connections are not being closed properly by the server or client. In our investigation, we found that the culprit behind this issue was an HTTP error code 513 being sent to clients from servers. This error code indicates that the server is overloaded and cannot handle more requests. Furthermore, the client was logging a socket close event, which meant it was terminating the connection prematurely. To replicate this issue, we used JMeter and found that the max concurrent connection limit was reached, resulting in an HTTP error code 513. The allowed queue was also full, contributing to the problem. So, what are the consequences of this issue? Performance degradation and resource wastage on both servers and clients ca...
Post a Comment
Read more

Catch persistence java.sql.sqlintegrityconstraintviolationexception

Handling SQL Integrity Constraint Violation Exceptions This tutorial will guide you through handling `SQLIntegrityConstraintViolationException` when persisting objects that violate database constraints. Step 1: Catch the EJB Exception Catch a `javax.ejb.EJBException` which wraps the underlying exception. try {     // persistence transactions } catch (Exception e) {     if (e instanceof javax.ejb.EJBException) {         logger.debug("Exception instance of javax.ejb.EjbException");     } } Step 2: Get the Underlying Exception Get the underlying exception from the `EJBException` using `e.getCause()`. try {     // persistence transactions } catch (Exception e) {     if (e instanceof javax.ejb.EJBException) {         logger.debug("Exception instance of javax.ejb.EjbException");         Throwable cause = e.getCause();         if (cause != null) {     ...
Post a Comment
Read more