I need some help using remote ejb calls. There is the following setup:
Background:
A JavaEE web application (naming it app1) is hosted on an oldschool WAS8 application server. The application provides at least one (knowen) remote ejb for application to application communication.
An other JavaEE web application (naming it app2) is hosted on a websphere liberty server. (We are currently migrate this application from WAS8 to websphere liberty.) This application (app2) now has to access the remote ejb provided by app1.
Problems:
The old implementation of the remote ejb call did not perfom with websphere liberty. I did a lot of research and was able to migrate the remote ejb call. That looks like this:
try {
// Holds the server address
String server = "server.address:port";
// Building JNDI address:
// E.g. corbaname:iiop:server:port/java:global/app1/ejb-module/BeanImpl!qualified.name.of.RemoteBean
StringBuilder address = new StringBuilder("corbaname:iiop:") // Protocol
.append(server) // Server address
.append("/") // Separator
.append("java:") // EJB context
.append("global/") // Globales Repository
.append("app1/") // Applikation
.append("ejb-module/") // module
.append("BeanImpl!") // Bean
.append("qualified.name.of.RemoteBean"); // Remote Interface
// Performing jndi lookup (shadowed remote ejb call by context (liberty server))
Object o = InitialContext.doLookup(address.toString());
// Casting requested object
service = (qualified.name.of.RemoteBean) PortableRemoteObject.narrow(o,
qualified.name.of.RemoteBean.class);
} catch (NamingException e) {
// Catching naming errors
log.warn("Cannot read app1 URL from JNDI: {}.", e.getMessage());
log.error("Exeption: ", e);
} catch (SystemException e) {
// Catching any other error
log.warn("Cannot connect to app1: {}", e.getMessage());
log.error("Exeption: ", e);
}
This code compiles and is executable w/o any naming exception.
I am still not able to successfully request any remote ejb object. On every request, a org.omg.CORBA.OBJ_ADAPTER exception occures with the following stacktrace (error message: org.omg.CORBA.OBJ_ADAPTER: : vmcid: 0x4942f000 minor code: 0xb81 completed: No):
Exeption: org.omg.CORBA.OBJ_ADAPTER:
at org.apache.yoko.orb.OB.Util.unmarshalSystemException(Util.java:165)
at org.apache.yoko.orb.OB.GIOPConnection.processReply(GIOPConnection.java:543)
at org.apache.yoko.orb.OB.GIOPConnection.processMessage(GIOPConnection.java:365)
at org.apache.yoko.orb.OB.GIOPConnectionThreaded.execReceive(GIOPConnectionThreaded.java:429)
at org.apache.yoko.orb.OB.GIOPConnectionThreaded.access$200(GIOPConnectionThreaded.java:42)
at org.apache.yoko.orb.OB.GIOPConnectionThreaded$Receiver.run(GIOPConnectionThreaded.java:68)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
I have no idea what is happening there. I guess that the requesting VM (Oracle Java 8) is not able to read the object from the response (sent from IBM J9 VM with Java 6)
Infrastructure information:
The WAS8 is running with the IBM J9 VM with java version 1.6.0 on a linux server, hosted in my companies intranet. The WAS8 is version 8.0.0.15 ND.
The websphere liberty is running with the Java HotSpot(TM) 64-Bit Server VM with java version 1.8.0_172-b11 on a windows 10 machine, connected via VPN to the same network zone like the WAS8 application server. Liberty is version 18.0.0.2
Question:
Is the JNDI address correct? The binding of the remote ejb is the following (from server startup log):
[1/11/19 13:26:21:230 CET] 00000008 EJBContainerI I CNTR0167I: The server is binding the qualified.name.of.RemoteBeaninterface of the BeanImplenterprise bean in the ejb-module.jar module of the app1 application. The binding location is: BeanImpl
[1/11/19 13:26:21:246 CET] 00000008 AbstractEJBRu I CNTR0167I: The server is binding the qualified.name.of.RemoteBeaninterface of the BeanImplenterprise bean in the ejb-module.jar module of the app1 application. The binding location is: java:global/app1/ejb-module/BeanImpl!qualified.name.of.RemoteBeaninterface
Is it possible to call a remote ejb from an other jvm with a different vendor an a different version in general?
Is there any documentation about WAS8 concerning it's NameService?
A similar thread in DeveloperWorks discusses the issue of a Liberty client invoking an EJB in tWAS. At the time, there was question on whether Liberty had this functionality. RFE 32815 has since been implemented. And Liberty doc shows examples of EJB lookups (see links given below.)
In any case, based on the stacktrace you posted, it appears the CORBA.OBJ_ADAPTER is being thrown on the tWAS server and the client is processing that exc from within a reply message from the server. Trace from the server may be necessary. I would also run dumpnamespace on your tWAS server in order to see the topology-based ejb object you're trying to look up and try using that rather than the java:global name.
As to your specific questions:
A1. While the "java:global" indirect name may be valid, most lookups I see into tWAS namespace employ topology-based qualified names (e.g. cell//node/...)
A2. In general, yes, interoperability between different CORBA/Naming versions and vendors should exist.
A3. See links listed below.
If none of the following doc helps, it would be best to open a ticket with IBM support so we can more easily exchange logs etc and tap the various Liberty, tWAS Naming/EJB experts.
Doc Links:
Using enterprise JavaBeans with remote interfaces on Liberty
TroubleShooting: JNDI and naming problems
Example: Looking up an EJB home or business interface with JNDI
Namespace logical view
Related
EJB call is successfull, if it is deployed in the local machine. When if it is called by the remote jboss machine, below exception is thrown
Exchange-exception :java.lang.IllegalStateException: EJBCLIENT000025: No EJB receiver available for handling [appName:, moduleName:ejbmavendemo-0.0.1-SNAPSHOT, distinctName:] combination for invocation context org.jboss.ejb.client.EJBClientInvocationContext#43a094bf
at org.jboss.ejb.client.EJBClientContext.requireEJBReceiver(EJBClientContext.java:747)
at org.jboss.ejb.client.ReceiverInterceptor.handleInvocation(ReceiverInterceptor.java:116)
Configuration used in the camel-context.xml is as below
click on this link to view the xml details
Not sure, what is missing. Please advice
It can have several issues :
connection: Connection broken
security : user/pass invalid
EJB missing: connected, but ejb is not there
SSL
The EJBClientContext will keep all available receiver in a Map where the servers name is the key. If there is more than one server with the same name these entries will be lost.
If it is inside of a server instance this instance will be preferred and all other instances with the same server name are hidden.
In this case no EJB will be accessible which is only available on such server.
check the outbound-connection
check the user and password at destination server (NOTE: need to be EAP application user, not management user)
check the secret value at target server
check that there are no extra spaces left after the specifying a property in jboss-ejb-client.properties file.
enable org.jboss.ejb.client and org.jboss.remoting for TRACE logging to see detailed messages for the invocation at client side.
JBoss maintains a persistent connection to the other server, so when the client sees this message it means there is no connection to a server that has the ejb you are trying to call, so a message will be logged when the connection fails to the other server.
I get a java.lang.ClassNotFoundException when trying to create a websphere mq connection factory through wsadmin.
WASX7015E: Exception running command: "AdminTask.createWMQConnectionFactory(...)"; exception information:
com.ibm.websphere.management.exception.ConnectorException
org.apache.soap.SOAPException: [SOAPException: faultCode=SOAP-ENV:Client; msg=com.ibm.ws.messaging.admin.command.AdminCommandException
Server stack trace
JMXTransformException java.lang.ClassNotFoundException: com.ibm.ws.messaging.admin.command.AdminCommandException
at java.lang.Class.forNameImpl(Native Method)
at java.lang.Class.forName(Class.java:185)
at com.ibm.ws.util.WsObjectInputStream.loadClass(WsObjectInputStream.java:228)
at com.ibm.ws.util.WsObjectInputStream.access$000(WsObjectInputStream.java:54)
...
I'm using a websphere application server wsadmin thin client, based on this article http://www.ibm.com/developerworks/websphere/library/techarticles/1207_vansickel/1207_vansickel.html.
I probably have to include one or more jars from websphere for this to succeed. Can somebody tell me which ones?
Currently I have these jars on the classpath:
/usr/share/wsadmin/lib/jython/jython.jar
/usr/share/wsadmin/lib/com.ibm.ws.admin.client_7.0.0.jar
/usr/share/wsadmin/lib/com.ibm.ws.security.crypto.jar
/usr/share/wsadmin/lib/batch.jar
I'm using Websphere 7.0.0.
It's odd, but I found a reference to this CNFE occuring when you reference a queue that doesn't exist or whose case differs from the one in your wsadmin invocation. IOW it's some kind of follow-on failure only.
Maybe triple-check any parameters, especially with respect to case.
http://www-01.ibm.com/support/docview.wss?uid=swg21631640
I'm consuming a web service in a java class standalone and it works fine.
I deployed that class as a part of a web-app in tomcat apache and it works fine.
Then, I deployed it in a glassfish server and I get this error:
WSS1601: Transport binding configured in policy but incoming message was not SSL enabled
I have several weeks stuck here. Seems like some glassfish setting doesn't accepts that my web-app uses a web service that works through HTTP (this is, and has to be the case).
The webservice client was made with the web service client wizard tool of netbeans (it uses wsimport-JAX-WS). More details on the error trace from the server:
com.sun.xml.wss.impl.XWSSecurityRuntimeException: WSS1601: Transport binding configured in policy but incoming message was not SSL enabled
at com.sun.xml.wss.impl.policy.verifier.MessagePolicyVerifier.verifyPolicy(MessagePolicyVerifier.java:125)
Has anybody else faced this issue?
Any help or ideas appreciated.
EDIT: I tried generating the stubs using the axis2 tool and it works great, so i'm sensing some kind of error in jax-ws when used in glassfish.
I guess you are trying to access the service enables with SSL. Try invoking the service with https also you have to install the valid SSL certificate in the client JDK.
The following link explain how to obtain and install a signed certificate :
https://docs.oracle.com/cd/E19798-01/821-1794/aeogl/index.html
Good luck :)
I built a web-service application using Jdeveloper 11.1.1.7 and deployed on weblogic 10.3.6 on physical server let us call it back-end server.
I do not want to give client direct access to back-end server so I make use of Apache 2.2 to be in the middle of client and back-end server. Apache 2.2 is configured on different physical server let us call it middle server.
I defined application's context root (which deployed in back-end server) on middle server in Apache httpd.conf file.
I shared WSDL file location to client ( WSDL URL which referring to the middle server domain name). The external client can access the URL thorug browser where he/she can see the WSDL content
But when the client trying send requests to middle server URL it get rejected with the following error:
[error] [client -clinet public IP goes here-] ap_proxy: trying POST /[application context root goes
here] at backend host '[back-end server local IP]/[port goes here]; got exception 'CONNECTION_REFUSED
[os error=0, line 1602 of URL.cpp]: apr_socket_connect call failed with error=730061, host=[back-end
server local IP], port=[port goes here]'
This error from middle server Apache error log file. No logs from back-end server
What is done so far:
I check the if I can access the middle server as external user using the telnet command. telnet IP port. It is working and the middle server is listening.
I also checked for all ports. between external client and middle server, between middle server and back-end server also using telnet. All ports working.
In this answer : ssl - Apache 2 with Weblogic Plug-in Redirection, original location still requested to backend - Server Fault
they are suggestion to increase the Accept Backlog value from weblogic server tuning . I did that in back-end server but still the issue is not resolved.
Problem resolved
I need to enable (WebLogic Plug-In Enabled) option from weblogic server where the application is deployed
from Domain Structure (Left Panel in admin console) - > Environment - > Servers -> (select the server where you deploy your application on it) - > General tab (from server setting)-> Advance - > (tic the option) WebLogic Plug-In Enabled
Then restarted the server.
By this your are telling the server you will get indirect request through proxy server or load balancer for example
You can do this on many level like cluster or server based on your needs check this site for more information
Understanding the use of “WebLogic Plugin Enabled”
I am trying to invoke a web service that I have just hosted on out linux redhat server but it throws the error {http://xml.apache.org/axis/}stackTrace:Exception occurred while trying to invoke service method + "methodname"
I host the service in apache tomcat webserver
The same service works fine when i host it in the windows xp environment with the same apache web server...
Is there anyone who has experienced a similar problem.
thanks..
in the axis2.xml ...
<parameter name="sendStacktraceDetailsWithFaults">false</parameter>
set the sendStacktraceDetailsWithFaults parameter to true and you should get a copy of the stacktrace in the response (reset to false for production)
I have experienced something similar. Our dev environment was running JBoss and Ubuntu, and prod/test was running Red Hat, Apache in front and JBoss.
Prod/test was running https with certificates, and our problem was that our certificates where out of date. When we fixed that, the webservice calls got through.
Maybe thats your problem?
Another thing you should do to debug is see if the wsdl is deployed and check what the webservice address it is deployed under. Maybe the address is very different in prod?
For instance in JBoss if you go to
http://localhost:8080/jbossws/services you will see all the services that are deployed and what url they have.