I am receiving the following error. What does this mean and how to fix it?
Unable to deploy EJB : xxxEJB from xx.JAR
Error deployin gthe EJB 'xxxEJB, the JNDI name 'xxxEJB' is already in use.
You must set a different JNDI name in weblogic-ejb-jar.xml deployment descriptor or corresponding annotation for this EJB before it can be deployed.
Thanks for the help.
Related
While deploying EAR via HUDSON to Websphere 9.0
WebSphere throws following error
ADMA0205E: A validation error occurred in task Binding enterprise Bean to JNDI names. Java Naming and Directory Interface (JNDI) names for the bean and its local/remote home are both specified for enterprise bean XXXXX in module XXXX. You can provide either JNDI name for the bean or JNDI names for its local/remote home. But you cannot provide both.
can you please let me know if am doing anything wrong.
This normally indicates that the application has a problem in the ibm-ejb-jar-bnd.xml file. Specifically, for the bean XXXXX in module XXXX, there is a binding configuration that specifies both the simple-binding-name attribute and one of the following : local-home-binding-name or remote-home-binding-name attributes, or the <interface> element. simple-binding-name is not compatible with these other attributes/element.
Information about the format of the ibm-ejb-jar-bnd.xml file is available here:
https://www.ibm.com/support/knowledgecenter/en/SSAW57_8.5.5/com.ibm.websphere.nd.doc/ae/cejb_bindingsejbfp.html
I have created two liberty instances on my local machine. I deployed a war module which contains a remote ejb in server X and deployed another war in server Y which has to remote lookup the ejb from server X.
Below is the code to lookup the ejb from a restful webservice.
Properties p = new Properties();
p.setProperty("java.naming.provider.url", "corbaname:iiop:localhost:2809");
InitialContext context = new InitialContext (p);
context.lookup("corbaname:rir:#ejb/global/caching/CachingServiceBean!com%5c.ejb%5c.CachingService");
When I try to call the web service I get below exception
DII operation not supported by local object
P.S.
I have enabled ejbRemote feature on both the servers with different port numbers.
I changed my lookup string to "corbaloc:iiop:localhost:2809/NameService#ejb/global/caching/CachingServiceBean!com%5c.ejb%5c.CachingService" and then I get the below error
Then I changed my lookup string to "corbaname:iiop:localhost:2809/NameService#ejb/global/caching/CachingServiceBean!com%5c.ejb%5c.CachingService" and then I got the below error
After checking apache geronimo-yoko implementation on GitHub, I understood that I have to use corbaloc:iiop:localhost:2809. But still I am getting exceptions caused by
org.omg.CORBA.OBJECT_NOT_EXIST: unable to dispatch - servant or POA not found
I used the following urls with no luck:
corbaloc:iiop:localhost:2809/global/caching/CachingServiceBean!com.ejb.CachingService
corbaloc:iiop:localhost:2809/#ejb/global/caching/CachingServiceBean!com.ejb.CachingService
3.corbaloc:iiop:localhost:2809/caching/CachingServiceBean!com.ejb.CachingService
4.corbaloc:iiop:localhost:2809/ejb/global/caching/CachingServiceBean!com.ejb.CachingService
I think the problem is with the packaging. I packed my ejb in a war module.
I followed the steps described in the PDF mentioned in this page http://www.redbooks.ibm.com/redpieces/abstracts/sg248076.html and everything is working now.
I used corbaname::host:port syntax to lookup the remote ejb instead of corbaloc:iiop:host:port
After packing my ejb in an ear then it started working.
I have EJB packaged jar deployed in a cluster. When I try to create an entity manager with the entitymanager factory I get a namingexception because it can't find my jndi data source (jdbc/oracledb). If I update the datasource to target add the adminserver, I don't get the error it it find the datasource. I am new to EJB and clustering. I am able to see the jndi tree in my cluster from within the Weblogic Admin console and I can programmatically find jdbc/oracledb when I do lookup in my cluster. My entire application is deployed to the cluster, so I don't know why any of it should be within the context of the admin server. I'm wondering if this is a class loading issues. Thanks for any help.
We have installed Worklight server with Websphere Liberty profile.
Installed war file and created derby databases as mentioned in the following url and referenced them in server.xml. I'm getting the below error.
Exception thrown by application class 'com.worklight.core.auth.impl.AuthenticationFilter.verifyServletInitialized:300'
javax.servlet.ServletException: Worklight Console initialization failed.
Logged Exception: com.worklight.server.database.api.WorklightDataSourceException:
FWLSE0194E: Worklight server cannot be started because of failure while getting a connection from data-source bound to resource reference: jdbc/WorklightDS. Make sure the
database is up, the credentials are correct and the driver is available for the server. [project bluemine]
at com.worklight.core.auth.impl.AuthenticationFilter.verifyServletInitialized(AuthenticationFilter.java:300)
at com.worklight.core.auth.impl.AuthenticationFilter.doFilter(AuthenticationFilter.java:111)
at com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(FilterInstanceWrapper.java:194)
at [internal classes]
Issue got resolved. There is a missmatch of versions between DB and the jar file being used. Thanks
When i try to make a remote ejb jndi look up, IBM message Broker throws ClassCastexception for the factory object.
But the same code works fine for a normal local java application and junit.Why this problem occurs when called only from IBM WMB
Context context = new InitialContext(ejbJndiProperties);
Object factoryObj = context.lookup("SampleBeanTAFJ/remote");
return (SampleBeanRemote) factoryObj;
This is often called by loading parts of the interface in a different classloader to the implementation classes.
I would use the env var:
IBM_JAVA_OPTIONS=-Dibm.cl.verbose=*
Then restart the broker, this will dump classloading trace to stdout / console.txt which might give you some clues.
What are the exact classes involved in the error and what jars are they stored in? Deployed to the EG or referenced via a SHARED-CLASSES? The exact details determine which classloaders should be in use here.