JNDI EJB Lookup fails on Remote Server

Hi,
I am having two different domain (domain1,domain2) respectvely. My ABC.ear j2eee application is deployed on domain2 and its iiop port is 33703.In domain1 i have xyz.war (web application) and it's IIOP port is 3700 .In xyz.war i am having CallEJB.jsp file.In this Jsp file i want to lookup an EJB Service called PaymentEJB(JNDI Name is ejb/PaymentEJB).
The code is below
InitialContext context=new InitialContext();
Object objRef=context.lookup("corbaname:iiop:andaman:33703#ejb/PaymentEJB");
I am getting the following error.
[#|2005-12-14T16:42:03.422+0530|SEVERE|sun-appserver-pe8.1_02|javax.enterprise.resource.corba._DEFAULT_.rpc.transport|_ThreadID=11;|"IOP00410216: (COMM_FAILURE) Unable to create IIOP listener on the specified host/port: all interfaces/3700"
org.omg.CORBA.COMM_FAILURE: vmcid: SUN minor code: 216 completed: No
at com.sun.corba.ee.impl.logging.ORBUtilSystemException.createListenerFailed(ORBUtilSystemException.java:2661)
My doubt is
1.While starting domain1 and domain2 iiop listeners are started on the port 3700 and 33703.in that case why EJB lookup tries to create listener on one more time.
2.I am looking the 33703 port only.but it tries to create port on 3700 why?
3.It was working till JES2005Q1.Is there any patch i need to install? or i need to change anything in my code.
I am frustrated with this error for past one week.I will be happy if some body will give me the peace of mind(thru some solution).

http://docs.sun.com/source/819-0079/dgjndi.html
This might help.

Similar Messages

(261936172) Q general How can I access an EJB hosted on a remote server?

Q<general> How can I access an EJB hosted on a remote server?
A<general> The ability to add EJB control files enables you to access an EJB that
is deployed to the server on which your web service is running. When you select
"add EJB control" you need to supply the home and remote interfaces for the EJB
as well as the JNDI name. This does not provide you with the capability for creating
a control for a remotely hosted EJB. To use a EJB hosted on another server you
will have to provide the appropriate code within your web service itself. You
will have to programmatically gain to access the JNDI for the remote server, lookup
up the home stub and use it to create the remote stub for the EJB. Of course,
to make this work you must have the necessary client interfaces in you classpath
(home and remote interfaces) which can easliy be achieved by adding the EJB client.jar
file to the lib directory in the webservice WEB-INF folder.

just define the different server path in the description xml file
<jndi-name>jnp://serverA(B)/....</jndi-name>

DataSource.Error: SharePoint: Request failed: The remote server returned an error: (500) Internal Server Error.

Seeing this error when retrieving data from a SharePoint list. I have full access to the list. Any help would be appreciated.
DataSource.Error: SharePoint: Request failed: The remote server returned an error: (500) Internal Server Error. (An error occurred while processing this request.)
Details:
https://xyz/_vti_bin/ListData.svc/ListName


I think I figured out how to use Fiddler. Here's the information I captured-
This is a Tunnel. Status: OPEN, Raw Bytes Out: 3,797; In: 7,604
The selected session is a HTTP CONNECT Tunnel. This tunnel enables a client to send raw traffic (e.g. HTTPS-encrypted streams or WebSocket messages) through a HTTP Proxy Server (like Fiddler).
To enable Fiddler's HTTPS-decryption feature and view decrypted traffic, click Tools > Fiddler Options > HTTPS.
Request Count:   1
Bytes Sent:      107  (headers:107; body:0)
Bytes Received: 107  (headers:107; body:0)
Tunnel Sent:     3,797
Tunnel Received: 7,604
ACTUAL PERFORMANCE
ClientConnected: 11:06:11.389
ClientBeginRequest: 11:06:11.395
GotRequestHeaders: 11:06:11.395
ClientDoneRequest: 11:06:11.395
Determine Gateway: 0ms
DNS Lookup:   176ms
TCP/IP Connect: 77ms
HTTPS Handshake: 0ms
ServerConnected: 11:06:11.649
FiddlerBeginRequest: 11:06:11.649
ServerGotRequest: 11:06:11.649
ServerBeginResponse: 00:00:00.000
GotResponseHeaders: 00:00:00.000
ServerDoneResponse: 00:00:00.000
ClientBeginResponse: 11:06:11.649
ClientDoneResponse: 11:06:11.649
Overall Elapsed: 0:00:00.254
-= Fiddler Event Log =-
See http://fiddler2.com/r/?FiddlerLog for details.
10:33:33:8092 Fiddler Running...
10:33:33:8118 Fiddler.Network.AutoProxy> AutoProxy Detection failed.
10:33:33:8118 AutoProxy failed. Disabling for this network.
10:33:33:8118 Windows 8+ AppContainer isolation feature detected.
11:01:21:4125 HTTPSLint> Warning: ClientHello record was 382 bytes long. Some servers have problems with ClientHello's greater than 255 bytes. https://github.com/ssllabs/research/wiki/Long-Handshake-Intolerance
11:01:21:4145 HTTPSLint> Warning: ClientHello record was 382 bytes long. Some servers have problems with ClientHello's greater than 255 bytes. https://github.com/ssllabs/research/wiki/Long-Handshake-Intolerance
11:01:21:4185 HTTPSLint> Warning: ClientHello record was 382 bytes long. Some servers have problems with ClientHello's greater than 255 bytes. https://github.com/ssllabs/research/wiki/Long-Handshake-Intolerance
11:01:21:4258 HTTPSLint> Warning: ClientHello record was 382 bytes long. Some servers have problems with ClientHello's greater than 255 bytes. https://github.com/ssllabs/research/wiki/Long-Handshake-Intolerance
11:01:21:4268 HTTPSLint> Warning: ClientHello record was 382 bytes long. Some servers have problems with ClientHello's greater than 255 bytes. https://github.com/ssllabs/research/wiki/Long-Handshake-Intolerance
11:01:21:4298 HTTPSLint> Warning: ClientHello record was 382 bytes long. Some servers have problems with ClientHello's greater than 255 bytes. https://github.com/ssllabs/research/wiki/Long-Handshake-Intolerance
11:01:21:4398 HTTPSLint> Warning: ClientHello record was 382 bytes long. Some servers have problems with ClientHello's greater than 255 bytes. https://github.com/ssllabs/research/wiki/Long-Handshake-Intolerance
11:01:21:4398 HTTPSLint> Warning: ClientHello record was 382 bytes long. Some servers have problems with ClientHello's greater than 255 bytes. https://github.com/ssllabs/research/wiki/Long-Handshake-Intolerance
11:01:21:4518 HTTPSLint> Warning: ClientHello record was 382 bytes long. Some servers have problems with ClientHello's greater than 255 bytes. https://github.com/ssllabs/research/wiki/Long-Handshake-Intolerance
11:01:21:4518 HTTPSLint> Warning: ClientHello record was 382 bytes long. Some servers have problems with ClientHello's greater than 255 bytes. https://github.com/ssllabs/research/wiki/Long-Handshake-Intolerance
11:01:21:4528 HTTPSLint> Warning: ClientHello record was 382 bytes long. Some servers have problems with ClientHello's greater than 255 bytes. https://github.com/ssllabs/research/wiki/Long-Handshake-Intolerance
11:01:21:4828 HTTPSLint> Warning: ClientHello record was 382 bytes long. Some servers have problems with ClientHello's greater than 255 bytes. https://github.com/ssllabs/research/wiki/Long-Handshake-Intolerance
11:01:21:5789 HTTPSLint> Warning: ClientHello record was 382 bytes long. Some servers have problems with ClientHello's greater than 255 bytes. https://github.com/ssllabs/research/wiki/Long-Handshake-Intolerance
11:01:21:5820 HTTPSLint> Warning: ClientHello record was 382 bytes long. Some servers have problems with ClientHello's greater than 255 bytes. https://github.com/ssllabs/research/wiki/Long-Handshake-Intolerance
11:01:21:5879 HTTPSLint> Warning: ClientHello record was 382 bytes long. Some servers have problems with ClientHello's greater than 255 bytes. https://github.com/ssllabs/research/wiki/Long-Handshake-Intolerance
11:01:21:6179 HTTPSLint> Warning: ClientHello record was 382 bytes long. Some servers have problems with ClientHello's greater than 255 bytes. https://github.com/ssllabs/research/wiki/Long-Handshake-Intolerance
11:01:21:6530 HTTPSLint> Warning: ClientHello record was 382 bytes long. Some servers have problems with ClientHello's greater than 255 bytes. https://github.com/ssllabs/research/wiki/Long-Handshake-Intolerance
11:01:21:6924 HTTPSLint> Warning: ClientHello record was 382 bytes long. Some servers have problems with ClientHello's greater than 255 bytes. https://github.com/ssllabs/research/wiki/Long-Handshake-Intolerance

SharePoint List Error :[DataSource.Error] SharePoint: Request failed: The remote server returned an error: (500) Internal Server Error. (An error occurred while processing this request.)

When I connect to the SharePoint site that contains the lists I need to build my query from , Power Query enumerates the list and displays them in the tool. I can click on the system tables and view the records but any table
in the list I created returns this error.
I can connect fine with InfoPath
[DataSource.Error] SharePoint: Request failed: The remote server returned an error: (500) Internal Server Error. (An error occurred while processing this request.)
thank you for your help
Andrew

Hi Andrew. In order for us diagnose this issue, you'll need to capture some network traces using a tool such as Fiddler and share them by sending a Frown.
To capture a trace using Fiddler, start Fiddler, enable the Tools > Fiddler Options > HTTPS > Decrypt HTTPS traffic option, start the capture, reproduce your issue, then stop and save the capture. You can find more information here.
Once you've done that, please send a Frown through the Power Query ribbon and attach the traces.
Thanks,
Ehren

EJB lookup failing in DCM managed Oracle AS clustering

Hi
My purpose is to test DCM managed Oracle AS clustering:
For that I have two Oracle Application servers installed in two different machines with
Version: 10.1.2.0.2 and Installation Type as J2EE and Web Cache
I created an OracleAS File-based Farm and associated both the instances of AS to the cluster. Then I created One OC4J instance called InstanceOne on the cluster and deployed my Application ear onto the cluster.I also configued web Application and EJB Application State Replication the with OracleAS Cluster (OC4J).
My Application has one Ejb module and a web module. My stateless Session bean is Spring framework implemented and I am trying to load the Spring Context lookup from the Struts Action Class by using WebApplicationContext.
My spring context looks like this
<bean id="jndiTemplate"
class="org.springframework.jndi.JndiTemplate">
<property name="environment">
<props>
<prop key="java.naming.factory.initial">com.evermind.server.rmi.RMIInitialContextFactory</prop>
<prop key="java.naming.provider.url">opmn:ormi://<server host>:InstanceOne/<Application Name></prop>
<prop key="java.naming.security.principal">oc4jadmin</prop>
<prop key="java.naming.security.credentials">admin</prop>
<prop key="oracle.j2ee.naming.cache.timeout">30</prop>
<prop key="Dedicated.Connection">yes</prop>
<prop key="Dedicated.RMIcontext">false</prop>
<prop key="LoadBalanceOnLookup">true</prop>
</props>
</property>
</bean>
<bean id="service"
class="org.springframework.ejb.access.SimpleRemoteStatelessSessionProxyFactoryBean">
<property name="jndiTemplate">
<ref bean="jndiTemplate"/>
</property>
<property name="jndiName">
<value>MyServiceEJB</value>
</property>
<property name="cacheHome">
<value>false</value>
</property>
<property name="refreshHomeOnConnectFailure">
<value>true</value>
</property>
<property name="businessInterface">
<value>com.my.springejb.MyBusinessInterface</value>
</property>
</bean>
When I give only one server lookup like
opmn:ormi://<server host1>:InstanceOne/<Application Name>
then lookup is working, But by giving two servers in cluster, like opmn:ormi://<server host1>:InstanceOne/<Application Name>, opmn:ormi://<server host2>:InstanceOne/<Application Name>
I am getting error like this
06/12/01 19:27:41 java.lang.NumberFormatException: For input string: "InstanceOne"
06/12/01 19:27:41 at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
06/12/01 19:27:41 at java.lang.Integer.parseInt(Integer.java:468)
06/12/01 19:27:41 at java.lang.Integer.parseInt(Integer.java:518)
06/12/01 19:27:41 at com.evermind.server.rmi.RMIInitialContextFactory.getInitialContext(RMIInitialContextFactory.java:237)
06/12/01 19:27:41 at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:662)
06/12/01 19:27:41 at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:243)
06/12/01 19:27:41 at javax.naming.InitialContext.init(InitialContext.java:219)
06/12/01 19:27:41 at javax.naming.InitialContext.<init>(InitialContext.java:195)
06/12/01 19:27:41 at org.springframework.jndi.JndiTemplate.createInitialContext(JndiTemplate.java:105)
06/12/01 19:27:41 at org.springframework.jndi.JndiTemplate.execute(JndiTemplate.java:83)
06/12/01 19:27:41 at org.springframework.ejb.access.SimpleRemoteStatelessSessionProxyFactoryBean.create(SimpleRemoteStatelessSessionProxyFactoryBean.java:19)
My intension of testing is, if I make one server instance (InstanceOne) down then my lookup should divert all ejb calls to the other server in the cluster, which is not happening at all, and I am getting Server SHUT DOWN exception in the server.
Can anybody please let me know, whether the approach is correct and is there any problem with Spring lookup which does not support multiple host lookup or anything I am missing in my steps, as I am following the Oracle Application Server High Availability Guide 10g Release 2 (10.1.2)

you can find an running sample from :
http://javahowto.blogspot.com/2007/12/calling-weblogic-ejb-3-from-jruby-and.html
In weblogic, local ejb don't appear in the jndi tree, but , it can be founded ...
It works into 10.0 and 10.3
Cheers !

EJB control configured with remote server

Hi All,
I have a EJB control created in WL 8.1 workshop that talks to remote EJB deployed
on WL 7.0. I used the JNDI name format as " jndi://user@pwd:localhost:7005/MYEJB".
where the WL7 is running on 7005 port. In the design view, I can see all the exposed
methods of my EJB. That means the EJB control is able to connect to WL 7 on port
7005. However, when I build the webservice and try to invoke a method using test
browser, I get following exception -
java.net.MalformedURLException: For input string:
"localhost:7005"
at java.net.URL.<init>(URL.java:613)
at java.net.URL.<init>(URL.java:476)
at java.net.URL.<init>(URL.java:425)
at com.bea.wlw.runtime.core.control.EJBControlImpl.context_onAcquire(EJBControlImpl.jcs:468)
I dont understand why?
In additon, I have already set the security credential setting between WL 8 and
WL7 domains.

Hi,
Your help required please...
I am trying to do the same as what you are doing. (Integrating 8.1 with 7.0, i.e. invoking EJB running in 7.0 from 8.1).
While creating a EJB Control in Workshop, its listing only the ejbs deployed as modules. But as my EJB is running in 7.0 I have just imported my Remote and Home (in Libraries). But EJB Control doesn't look to recognise it.
Any solution!!!
Thanks in advance
Kirupa

Ejb lookups fail from threads spawned from servlet

Hello,
We have a servlet from which we are spawning a thread. In the thread we are
trying to do a JNDI lookup for the database resource / EJBs. It does not
work as if it is not able to find the context t do the lookup.
I thought that the threads are spawned in the same JVM and context, so why
does the lookup not work.
Please need to figure out a solution to this problem, we need to call some
business logic in the EJBS from the thread and we do not want to do RMI-IIOP
lookups becuase they could be slower.
Appreciate your help in advance.
Regards,
Sakib

Custom threading is not supported. I think a workaround was posted on
this alias (search for custom threading), where you can call the
proprietary API's of the container to recreate the context, but I'm
pretty sure that it's not a supported or recommended solution.
The better (and more scalable) solution is to avoid spawning your own
threads.
David
Sakib Mehasanewala wrote:
Hello,
We have a servlet from which we are spawning a thread. In the thread we are
trying to do a JNDI lookup for the database resource / EJBs. It does not
work as if it is not able to find the context t do the lookup.
I thought that the threads are spawned in the same JVM and context, so why
does the lookup not work.
Please need to figure out a solution to this problem, we need to call some
business logic in the EJBS from the thread and we do not want to do RMI-IIOP
lookups becuase they could be slower.
Appreciate your help in advance.
Regards,
Sakib

Authenication fails on remote server?

I was controlling my newly configured Mini server via ARD, restarted my laptop, and, viola, I can't connect to it any longer due to an authenication error. I can work with the server using it's local keyboard, mouse and monitor, I just can't connect to it via ARD.

have you tried ending the task ARDAgent task on the Mini? You could do this by unchecking and the rechecking Remote Management option in System Preferences Sharing. Alternatively you could issue the command send unix command as root "killall ARDAgent" Or by using task manager on the server.
you could also try deleting the server from ARD and then re-adding it.

Create EJB Control For Remote Server

I'm having trouble creating an EJB control for a EJB residing in a remote server.
First, I've a JAR containing the remote/home interfaces and added it as a Library in the WLW 8.1 application.
When creating a new EJB Control, there's no way to successfully create the control.
At the STEP 2 GUI:
I am able to specify a JNDI-NAME, but the home/bean interface fields are empty. If I click on "Browse application EJBs..." button, nothing is available. If I click on "Browse server EJBs", it only shows EJBs in the current server.
Thanks

Hi
I believe you are on Workshop8.1 Spx.
This is a known issue. The reason the ejb does not show up as an application ejb because we have just the interfaces as a library and not the whole EJB.
Since the EJB's are not deployed on the server it will not show up either.
Unfortunately there is no way to point to a remote domain and get all the ejb's deployed there.
Workaround:
You can deploy the ejb locally, create the ejbcontrol and then undeploy the EJB. You need to manually change the home jndiname to use the remote server url.
Thanks
Vimala

EJB lookup from another EJB server

Hi people,
I have two application servers on two different computers. One
of them contains an EJB, which I need to access from another EJB
server. I know that I can achieve this using RMI, but will then
security and transaction contexts be propagated to the called
EJB?
Sincerely,
Sergei Batiuk.

Here is the solution posted on another forum:
[email protected] Dec 8, 6:03 am show options
Newsgroups: ibm.software.websphere.studio
From: [email protected]
Date: 8 Dec 2004 06:03:04 -0800
Local: Wed, Dec 8 2004 6:03 am
Subject: Re: EJB lookup on from one server to another does not work
Eric,
I dealt with this same problem trying to run 2 local servers (websphere
test servers), using 2 separate WSAD 5.1.2 workspaces. Running on 1
server I have an application that contains an EJB, and running on the
other server is an application that uses an access bean to make a
remote call to my EJB, running on my other server. I too repeately
received the "NameNotFoundException" when trying to lookup my EJB home
reference.
What you have to do to get around this is to modify the server
configuration of the application that contains the EJB that you are
attempting to call remotely. You must open the the server.wsi file for
the server that is running the EJB and go to the "Configuration" tab.
You must check the "Enable administrative console". Once this is
complete, start your server. When it is started, right click on the
server, and select "run administrative console". In the admin console,
select
servers -> application servers -> <your server> -> end points ->
bootstrap address. For "host" you must change "localhost" to either
your ip address or computer name (ive only tried my ip, but your
computer name should work too). When building your properties to get
the initial context, make sure you use
"env.put(Context.PROVIDER_URL, "corbaloc:iiop:<the ip or computer name
listed as the bootstrap host of server running ejb>:<the port listed as
the bootstrap port of server running ejb, which is 2809 in your case>
Restart your server and things should work.

JNDI lookup failed:javax.naming.NameNotFoundException

Hello:
I have a application (not web) that publish messages to a specific topic, i want to receive these messages in a Web Service, but when the web service make the call to a class that is the JMS Client it can't find the Connection factory Name that i create in the aplication.
I want to know what i have to do,
I work with J2EE1.3.1 and JMS1.0.2 for the application that publish the messages
and Jwsdp1.1, tomcat 4 and j2sdk 1.4.0 for the web service.
I create the connection factory with this command:
j2eeadmin -addJmsFactory jms/DurableTopicB topic -props clientID=IdTopicB
Then in the class that the web service invoke i trying to join with this:
try {
jndiContext =new InitialContext();
}catch (NamingException e){
System.err.println("Could not create JNDI API "+
"context:"+e.toString());
return;
*Look up connection factory and topic.If either
*does not exist,exit.
try {
topicConnectionFactory =(TopicConnectionFactory)
jndiContext.lookup(conFacName);
}catch (NamingException e){
System.err.println("JNDI API lookup failed:"+
e.toString());
return;
//System.exit(1);
But i receive a error message in the log of Tomcat:
JNDI API lookup failed:javax.naming.NameNotFoundException: El nombre DurableTopicB no este asociado a este contexto
Thanks

Hello:
I display the full context of the connection factory in the application that publish the message:
Full context is :
Enviroment is : {java.naming.corba.orb=com.sun.enterprise.iiop.POAEJBORB@ec4a87}
And in the web service when i create the initial context the full context is:
Full context is : java:
Enviroment is : {java.naming.factory.initial=org.apache.naming.java.javaURLContextFactory, java.naming.factory.url.pkgs=org.apache.naming}
How can i see the connection factory in the Web Service, because the connection factory was created in other Application?

EJB lookup on Remote Server or different domain fails

Hi,
I am having two different domain (domain1,domain2) respectvely. My ABC.ear j2eee application is deployed on domain2 and its iiop port is 33703.In domain1 i have xyz.war (web application) and it's IIOP port is 3700 .In xyz.war i am having CallEJB.jsp file.In this Jsp file i want to lookup an EJB Service called PaymentEJB(JNDI Name is ejb/PaymentEJB).
The code is below
InitialContext context=new InitialContext();
Object objRef=context.lookup("corbaname:iiop:andaman:33703#ejb/PaymentEJB");
I am getting the following error.
[#|2005-12-14T16:42:03.422+0530|SEVERE|sun-appserver-pe8.1_02|javax.enterprise.resource.corba._DEFAULT_.rpc.transport|_ThreadID=11;|"IOP00410216: (COMM_FAILURE) Unable to create IIOP listener on the specified host/port: all interfaces/3700"
org.omg.CORBA.COMM_FAILURE: vmcid: SUN minor code: 216 completed: No
at com.sun.corba.ee.impl.logging.ORBUtilSystemException.createListenerFailed(ORBUtilSystemException.java:2661)
My doubt is
1.While starting domain1 and domain2 iiop listeners are started on the port 3700 and 33703.in that case why EJB lookup tries to create listener on one more time.
2.I am looking the 33703 port only.but it tries to create port on 3700 why?
3.It was working till JES2005Q1.Is there any patch i need to install? or i need to change anything in my code.
I am frustrated with this error for past one week.I will be happy if some body will give me the peace of mind(thru some solution).

Hi
I found the solution for this issue.
To lookup the EJB applications in web component,we should not set any thing in the Initial Context.i.e the lookup should be
InitialContext initContext=new InitialContext();
Object objref = initContext.lookup("java:comp/env/ejb/"+ejbName_);
This will get you the Home object of the EJB you are looking.
In your web.xml you should have the entry like below.(Just replace the ejbname which you are looking for)
<ejb-ref>
<ejb-ref-name>ejb/GetAssertionEJB</ejb-ref-name>
<ejb-ref-type>Session</ejb-ref-type>
<home>com.ssertion.GetAssertionHome</home>
<remote>com.assertion.GetAssertionRemote</remote>
</ejb-ref>
In your sun-wb.xml,you should have the entry like below(Just replace the ejbname which you are looking for)
<ejb-ref>
<ejb-ref-name>ejb/GetAssertionEJB</ejb-ref-name>
<jndi-name>corbaname:iiop:<hostname>:<iiopport>#ejb/GetAssertionEJB</jndi-name>
</ejb-ref>
Hope this works.

How to use JNDI to lookup remote EJB Home?

Hello,
I am writing a servlet to call a remote EJB on another machine.
I use JNDI to lookup remote EJBHome (not) but fail.
Any advice?
Any trick to configure application-client.xml?
Thanks!

Use com.evermind.server.rmi.RMIInitialContextFactory instead
Here an example
// EmployeeClient.java
package mypackage5;
import javax.ejb.*;
import javax.naming.*;
import javax.rmi.PortableRemoteObject;
import java.io.*;
import java.util.*;
import java.rmi.RemoteException;
import com.evermind.server.ApplicationClientInitialContextFactory;
import com.evermind.server.rmi.RMIInitialContextFactory;
* A simple client for accessing an EJB.
public class EmployeeClient
public static void main(String[] args)
System.out.println("EmployeeClient.main(): client started...");
try
* initialize JNDI context by setting factory, url and credential
* in a hashtable
Hashtable env = new Hashtable();
env.put(Context.INITIAL_CONTEXT_FACTORY, "com.evermind.server.rmi.RMIInitialContextFactory");
//env.put(Context.INITIAL_CONTEXT_FACTORY, "com.evermind.server.ApplicationClientInitialContextFactory");
env.put(Context.PROVIDER_URL, "ormi://koushikm:23791/application4");
env.put(Context.SECURITY_PRINCIPAL, "admin");
env.put(Context.SECURITY_CREDENTIALS, "admin");
* or set these properties in jndi.properties
* or use container defaults if that's where client got launched from
Context context = new InitialContext(env);
* Lookup the EmployeeHome object. The reference is retrieved from the
* application-local context (java:comp/env). The variable is
* specified in the assembly descriptor (META-INF/application-client.xml).
Object homeObject =
context.lookup("HelloEJB");
System.out.println("EmployeeClient.main(): bean found...");
// Narrow the reference to EmployeeHome.
HelloEJBHome home =
(HelloEJBHome) PortableRemoteObject.narrow(homeObject,
HelloEJBHome.class);
System.out.println("EmployeeClient.main(): home narrowed...");
// Create remote object and narrow the reference to Employee.
HelloEJB remote =
(HelloEJB) PortableRemoteObject.narrow(home.create(), HelloEJB.class);
System.out.println("EmployeeClient.main(): remote created...");
String message=remote.helloWorld("SUCCESS");
System.out.println(message);
} catch(NumberFormatException e) {
System.err.println("NumberFormatException: " + e.getMessage());
} catch(RemoteException e) {
System.err.println("RemoteException: " + e.getMessage());
} catch(IOException e) {
System.err.println("IOException: " + e.getMessage());
} catch(NamingException e) {
System.err.println("NamingException: " + e.getMessage());
} catch(CreateException e) {
System.err.println("CreateException: " + e.getMessage());
Hello,
I am writing a servlet to call a remote EJB on another machine.
I use JNDI to lookup remote EJBHome (not) but fail.
Any advice?
Any trick to configure application-client.xml?
Thanks!

Error while using LiveCycle java APIs with Http servlets:"Remote EJBObject lookup failed for ejb/Inv

Hi all,
When i try to run more than one servelt of the Quick Start samples that using Livecycle Java APIs and i get an error of "Remote EJBObject lookup failed for ejb/Invocation provider" from any servelt i run.
I try some Quick samples which is not servelts (java class) and it works fine, which makes me sure that my connection properties is true.
Environment:
The LiveCycle is based on "Websphere v6.1", and i use "Eclipse Platform
Version: 3.4.1".
i install "tomcat 5.5.17" to test the servelts in developing time through Eclipse.(only for test in developing time not for deploy on )
The Jars i added in the classpath:
adobe-forms-client.jar
adobe-livecycle-client.jar
adobe-usermanager-client.jar
adobe-utilities.jar
ejb.jar
j2ee.jar
ecutlis.jar
com.ibm.ws.admin.client_6.1.0.jar
com.ibm.ws.webservices.thinclient_6.1.0.jar
server.jar
utlis.jar
wsexception.jar
My code is :
Properties ConnectionProps = new Properties();
ConnectionProps.setProperty(ServiceClientFactoryProperties.DSC_DEFAULT_EJB_ENDPOINT, "iiop://localhost:2809");
ConnectionProps.setProperty ServiceClientFactoryProperties.DSC_TRANSPORT_PROTOCOL,ServiceClientFactoryProperties.DSC_ EJB_PROTOCOL);
ConnectionProps.setProperty(ServiceClientFactoryProperties.DSC_SERVER_TYPE,ServiceClientFa ctoryProperties.DSC_WEBSPHERE_SERVER_TYPE);
ConnectionProps.setProperty(ServiceClientFactoryProperties.DSC_CREDENTIAL_USERNAME, "Administrator");
ConnectionProps.setProperty(ServiceClientFactoryProperties.DSC_CREDENTIAL_PASSWORD, "password");
ConnectionProps.setProperty("java.naming.factory.initial", "com.ibm.ws.naming.util.WsnInitCtxFactory");
//Create a ServiceClientFactory object
ServiceClientFactory myFactory = ServiceClientFactory.createInstance(ConnectionProps);
//Create a FormsServiceClient object
FormsServiceClient formsClient = new FormsServiceClient(myFactory);
//Get Form data to pass to the processFormSubmission method
Document formData = new Document(req.getInputStream());
//Set run-time options
RenderOptionsSpec processSpec = new RenderOptionsSpec();
processSpec.setLocale("en_US");
//Invoke the processFormSubmission method
FormsResult formOut = formsClient.processFormSubmission(formData,"CONTENT_TYPE=application/pdf&CONTENT_TYPE=app lication/vnd.adobe.xdp+xml&CONTENT_TYPE=text/xml", "",processSpec);
List fileAttachments = formOut.getAttachments();
Iterator iter = fileAttachments.iterator();
int i = 0 ;
while (iter.hasNext()) {
Document file = (Document)iter.next();
file.copyToFile(new File("C:\\Adobe\\tempFile"+i+".jp i++;
short processState = formOut.getAction();
...... (To the end of the sample)
My Error was:
com.adobe.livecycle.formsservice.exception.ProcessFormSubmissionException: ALC-DSC-031-000: com.adobe.idp.dsc.net.DSCNamingException: Remote EJBObject lookup failed for ejb/Invocation provider
at com.adobe.livecycle.formsservice.client.FormsServiceClient.processFormSubmission(FormsSer viceClient.java:416)
at HandleData.doPost(HandleData.java:62)
at HandleData.doGet(HandleData.java:31)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:689)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.j ava:252)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
a

I assume here that your application is deployed on a different physical machine of where LCES is deployed and running.
Do the following test:
- Say that LCES is deployed on machine1 and your application is deployed on machine2. Ping machine1 from machine2 and note the ip address.
- Ping machine1 from machine1 and note the ip address.
The two pings should match.
- Ping machine2 from machine1 and note the ip address.
- Ping machine2 from machine2 and note the ip address.
The two pings should match.
Usually this kind of error would happen if your servers have internal and external ip addresses.

JNDI lookup fails in a thread created by J2EE application on WAS 8.0.0.4 running on Red Hat Enterprise Server 5.8(2.6.18-308.e15).

I am using Jackrabbit Repository (jcr's implementation) as backend in my Web Appl.Whose data persists on Oracle Database. To make connection with Oracle database jackrabbit provide provision of JNDI Lookup to read the data source defined in WAS (using WAS 8.0.0.4 as App Server).
I am able to perform JNDI Lookup everywhere in my application,But in a flow where i am creating a Thread using Java Concurrent Api and insidethread's call() method when I am trying for JNDI Look following exception occurs –
[8/20/13 10:57:35:163 IST] 000000dd System Out O ERROR 20-08 10:57:35,163 (DatabaseFileSystem.java:init:209) failed to initialize file system
javax.jcr.RepositoryException: JNDI name not found: java:comp/env/jdbc/ofsds
at org.apache.jackrabbit.core.util.db.ConnectionFactory.getJndiDataSource(ConnectionFactory.java:295)
at org.apache.jackrabbit.core.util.db.ConnectionFactory.createDataSource(ConnectionFactory.java:233)
at org.apache.jackrabbit.core.util.db.ConnectionFactory.getDataSource(ConnectionFactory.java:166)
at org.apache.jackrabbit.core.fs.db.DbFileSystem.getDataSource(DbFileSystem.java:226)
at org.apache.jackrabbit.core.fs.db.DatabaseFileSystem.init(DatabaseFileSystem.java:190)
at org.apache.jackrabbit.core.config.RepositoryConfigurationParser$6.getFileSystem(RepositoryConfigurationParser.java:1057)
at org.apache.jackrabbit.core.config.RepositoryConfig.getFileSystem(RepositoryConfig.java:911)
at org.apache.jackrabbit.core.RepositoryImpl.<init>(RepositoryImpl.java:285)
at org.apache.jackrabbit.core.RepositoryImpl.create(RepositoryImpl.java:605)
at org.apache.jackrabbit.core.TransientRepository$2.getRepository(TransientRepository.java:232)
at org.apache.jackrabbit.core.TransientRepository.startRepository(TransientRepository.java:280)
at org.apache.jackrabbit.core.TransientRepository.login(TransientRepository.java:376)
at com.mmpnc.icm.server.repository.RepositoryStartupService.newSession(RepositoryStartupService.java:408)
at com.mmpnc.icm.server.repository.RepositoryStartupService.newSession(RepositoryStartupService.java:355)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
at java.lang.reflect.Method.invoke(Method.java:611)
at org.jboss.seam.util.Reflections.invoke(Reflections.java:22)
at org.jboss.seam.intercept.RootInvocationContext.proceed(RootInvocationContext.java:31)
at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:56)
at org.jboss.seam.transaction.RollbackInterceptor.aroundInvoke(RollbackInterceptor.java:28)
at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
at org.jboss.seam.core.MethodContextInterceptor.aroundInvoke(MethodContextInterceptor.java:44)
at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
at org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:107)
at org.jboss.seam.intercept.JavaBeanInterceptor.interceptInvocation(JavaBeanInterceptor.java:166)
at org.jboss.seam.intercept.JavaBeanInterceptor.invoke(JavaBeanInterceptor.java:102)
at com.mmpnc.icm.server.repository.RepositoryStartupService_$$_javassist_1.newSession(RepositoryStartupService_$$_javassist_1.java)
at com.mmpnc.icm.server.repository.ICMHouseKeepingSessionManager.create(ICMHouseKeepingSessionManager.java:37)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
at java.lang.reflect.Method.invoke(Method.java:611)
at org.jboss.seam.util.Reflections.invoke(Reflections.java:22)
at org.jboss.seam.intercept.RootInvocationContext.proceed(RootInvocationContext.java:31)
at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:56)
at org.jboss.seam.transaction.RollbackInterceptor.aroundInvoke(RollbackInterceptor.java:28)
at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
at org.jboss.seam.core.BijectionInterceptor.aroundInvoke(BijectionInterceptor.java:77)
at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
at org.jboss.seam.core.MethodContextInterceptor.aroundInvoke(MethodContextInterceptor.java:44)
at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
at org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:107)
at org.jboss.seam.intercept.JavaBeanInterceptor.interceptInvocation(JavaBeanInterceptor.java:166)
at org.jboss.seam.intercept.JavaBeanInterceptor.invoke(JavaBeanInterceptor.java:102)
at com.mmpnc.icm.server.repository.ICMHouseKeepingSessionManager_$$_javassist_8.create(ICMHouseKeepingSessionManager_$$_javassist_8.java)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
at java.lang.reflect.Method.invoke(Method.java:611)
at org.jboss.seam.util.Reflections.invoke(Reflections.java:22)
at org.jboss.seam.util.Reflections.invokeAndWrap(Reflections.java:138)
at org.jboss.seam.Component.callComponentMethod(Component.java:2171)
at org.jboss.seam.Component.callCreateMethod(Component.java:2094)
at org.jboss.seam.Component.newInstance(Component.java:2054)
at org.jboss.seam.Component.getInstance(Component.java:1948)
at org.jboss.seam.Component.getInstance(Component.java:1910)
at org.jboss.seam.Component.getInstance(Component.java:1904)
at org.jboss.seam.Component.getInstanceInAllNamespaces(Component.java:2271)
at org.jboss.seam.Component.getValueToInject(Component.java:2223)
at org.jboss.seam.Component.injectAttributes(Component.java:1663)
at org.jboss.seam.Component.inject(Component.java:1481)
at org.jboss.seam.core.BijectionInterceptor.aroundInvoke(BijectionInterceptor.java:61)
at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
at org.jboss.seam.core.MethodContextInterceptor.aroundInvoke(MethodContextInterceptor.java:44)
at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
at org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:107)
at org.jboss.seam.intercept.JavaBeanInterceptor.interceptInvocation(JavaBeanInterceptor.java:166)
at org.jboss.seam.intercept.JavaBeanInterceptor.invoke(JavaBeanInterceptor.java:102)
at com.mmpnc.icm.server.repository.ICMHouseKeepingRepository_$$_javassist_7.create(ICMHouseKeepingRepository_$$_javassist_7.java)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
at java.lang.reflect.Method.invoke(Method.java:611)
at org.jboss.seam.util.Reflections.invoke(Reflections.java:22)
at org.jboss.seam.util.Reflections.invokeAndWrap(Reflections.java:138)
at org.jboss.seam.Component.callComponentMethod(Component.java:2171)
at org.jboss.seam.Component.callCreateMethod(Component.java:2094)
at org.jboss.seam.Component.newInstance(Component.java:2054)
at org.jboss.seam.Component.getInstance(Component.java:1948)
at org.jboss.seam.Component.getInstance(Component.java:1910)
at org.jboss.seam.Component.getInstance(Component.java:1904)
at org.jboss.seam.Component.getInstanceInAllNamespaces(Component.java:2271)
at org.jboss.seam.Component.getValueToInject(Component.java:2223)
at org.jboss.seam.Component.injectAttributes(Component.java:1663)
at org.jboss.seam.Component.inject(Component.java:1481)
at org.jboss.seam.core.BijectionInterceptor.aroundInvoke(BijectionInterceptor.java:61)
at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
at org.jboss.seam.core.MethodContextInterceptor.aroundInvoke(MethodContextInterceptor.java:44)
at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
at org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:107)
at org.jboss.seam.intercept.JavaBeanInterceptor.interceptInvocation(JavaBeanInterceptor.java:166)
at org.jboss.seam.intercept.JavaBeanInterceptor.invoke(JavaBeanInterceptor.java:102)
at com.mmpnc.icm.server.repository.ICMHouseKeepingManager_$$_javassist_6.create(ICMHouseKeepingManager_$$_javassist_6.java)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
at java.lang.reflect.Method.invoke(Method.java:611)
at org.jboss.seam.util.Reflections.invoke(Reflections.java:22)
at org.jboss.seam.util.Reflections.invokeAndWrap(Reflections.java:138)
at org.jboss.seam.Component.callComponentMethod(Component.java:2171)
at org.jboss.seam.Component.callCreateMethod(Component.java:2094)
at org.jboss.seam.Component.newInstance(Component.java:2054)
at org.jboss.seam.Component.getInstance(Component.java:1948)
at org.jboss.seam.Component.getInstance(Component.java:1910)
at org.jboss.seam.Component.getInstance(Component.java:1904)
at org.jboss.seam.Component.getInstance(Component.java:1899)
at com.mmpnc.icm.server.concurrent.PerformCloseTask.call(PerformCloseTask.java:136)
at com.mmpnc.icm.server.concurrent.PerformCloseTask.call(PerformCloseTask.java:1)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:314)
at java.util.concurrent.FutureTask.run(FutureTask.java:149)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:897)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:919)
at java.lang.Thread.run(Thread.java:770)
Caused by:
javax.naming.ConfigurationException: A JNDI operation on a "java:" name cannot be completed because the server runtime is not able to associate the operation's thread with any J2EE application component. This condition can occur when the JNDI client using the "java:" name is not executed on the thread of a server application request. Make sure that a J2EE application does not execute JNDI operations on "java:" names within static code blocks or in threads created by that J2EE application. Such code does not necessarily run on the thread of a server application request and therefore is not supported by JNDI operations on "java:" names. [Root exception is javax.naming.NameNotFoundException: Name comp/env/jdbc not found in context "java:".]
at com.ibm.ws.naming.java.javaURLContextImpl.throwExceptionIfDefaultJavaNS(javaURLContextImpl.java:522)
at com.ibm.ws.naming.java.javaURLContextImpl.throwConfigurationExceptionWithDefaultJavaNS(javaURLContextImpl.java:552)
at com.ibm.ws.naming.java.javaURLContextImpl.lookupExt(javaURLContextImpl.java:481)
at com.ibm.ws.naming.java.javaURLContextRoot.lookupExt(javaURLContextRoot.java:485)
at com.ibm.ws.naming.java.javaURLContextRoot.lookup(javaURLContextRoot.java:370)
at org.apache.aries.jndi.DelegateContext.lookup(DelegateContext.java:161)
at javax.naming.InitialContext.lookup(InitialContext.java:436)
at org.apache.jackrabbit.core.util.db.ConnectionFactory.getJndiDataSource(ConnectionFactory.java:280)
... 114 more
Caused by:
javax.naming.NameNotFoundException: Name comp/env/jdbc not found in context "java:".
at com.ibm.ws.naming.ipbase.NameSpace.getParentCtxInternal(NameSpace.java:1969)
at com.ibm.ws.naming.ipbase.NameSpace.retrieveBinding(NameSpace.java:1376)
at com.ibm.ws.naming.ipbase.NameSpace.lookupInternal(NameSpace.java:1219)
at com.ibm.ws.naming.ipbase.NameSpace.lookup(NameSpace.java:1141)
at com.ibm.ws.naming.urlbase.UrlContextImpl.lookupExt(UrlContextImpl.java:1436)
at com.ibm.ws.naming.java.javaURLContextImpl.lookupExt(javaURLContextImpl.java:477)
... 119 more

Okay "damorgan", you seem to have me confused with a newbie. All I'm posting is the info that I got from my Sys Admin on the fix to my problem I encountered when trying to install Oracle 11g (11.2.0.0) on Red Hat Linux Enterprise 5. Since we're mouting onto an NFS, these are the steps he took. I'm not trying to "hide" information or post as little as possible. What other info do you want? I don't know what you are referring to when you mention "Filer, make, model, software version"? Please elaborate. I was just trying to post to others that may have encountered this problem, and I get somewhat attacked by you. I don't assume anyone can read my mind (especially you).

JNDI EJB Lookup fails on Remote Server

Similar Messages

Maybe you are looking for