EJB 3 jndi lookup from glassfish to glassfish

Hi,
I have a big problem with remote access to EJB3 deployed on a glassfish server . I can get it work from a SE client or a Tomcat server but when I deploy the same code on another glassfish server,
I get a javax.naming.NameNotFoundException.
Here is my lookup code :
     prop.setProperty("java.naming.factory.initial","com.sun.enterprise.naming.SerialInitContextFactory");
                         prop.setProperty("java.naming.factory.url.pkgs","com.sun.enterprise.naming");
                         prop.setProperty("java.naming.factory.state","com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl");
                         prop.setProperty("java.naming.provider.url","iiop://192.168.2.13:3700");
                         prop.setProperty("org.omg.CORBA.ORBInitialPort","3700");
                         prop.setProperty("org.omg.CORBA.ORBInitialHost","192.168.2.13");
                         System.setProperty("org.omg.CORBA.ORBInitialHost", "192.168.2.13");
                         System.setProperty("org.omg.CORBA.ORBInitialPort", "3700");
                         InitialContext ic = new InitialContext(prop);
                         out.println("found :"+ic.lookup("big.com.model.MyEJBRemote"));any help welcome.
thank.

Have you tried this: https://glassfish.dev.java.net/javaee5/ejb/EJB_FAQ.html
Specifically using the no-arg constructor?

Similar Messages

NamingException on EJB jndi lookup

I have two applications - deployed under the "default instance".
When I start up OC4J and deloy app1 and app2, then app1 can do a JNDI lookup on a session bean that resides in App2. It uses the RMIInitialContextFactory.
Provider is "ormi://localhost/app2"
My problem is that if I undeploy and redeploy app2, then app1 suddenly can't do a lookup to any sessionBean found in app2 anymore, even though the jndi name still shows up in the browser, and if I try to look it up from an external application running outside of oc4j (with exactly the same code as I'm using in app1), it also works.
So why is app1 not able to find app2 via jndi after a redeployment?
D

Avi - thank you for your response.
First of all, I run on Suse Linux 10.1. Dunno if that's any help, but hey, more info can't help :)
Let's answer your questions:
1.) OCJ4 Version: 10.1.3.0.0 (build 060119.1546.05277)
2.) JDK Version: 1.5.0_07-b03
As for your suggestions:
1.) app1 = parent of app2.
I'm rather new to Oracle, so maybe I made a mistake during my investigations. Still, I'd like to give a breakdown: I built a framework-type application, and thought about deploying "child modules" (plug-in applications) underneath it, as you proposed.
This worked fine, but there comes a problem whenever you try to use something like Hibernate in any application that's not deployed in the root (ie any app that's deployed as a child of another). The problem came in 2 flavours:
A) If you use a jar in the parent and try to do resource loading from the child, the context of the parent is used the whole time. Since the search-policy of the class-loader is loaded->parent->shared->local, and if Hibernate is already used in the parent, it never gets to the child and thus trying to load a resource in the child is futile since parent can't see child context.
B) Lets say you're not using Hibernate at all in the parent application. When doing resource loading (eg the hibernate.cfg.xml file), Hibernate tries to locate the resource via Thread.currentThread().getContextClassLoader(). OC4J returns the parent-app's thread as the currentThread, NOT that of the child-application that you're actually running the code from, thus it will never be able to pick up resources from within a jar part of the child application. The only way that I managed to get it to work, was to include the Hibernate3.jar as part of the EAR deployment (ie listed it as <library path...> in the orion-application.xml. Putting it in shared-libs or app-libs didn't work...ever. Also, if I happened to use Hibernate in the parent-application, it doesn't matter if I put hibernate3.jar in the EAR of the child - the parent-version gets picked up and used due to the search-policy... NOTE: This is in a JAR - I'm not using WAR's so cannot force local loading as is possible with web-apps...
I then opted to deploy applications seperately under the root, and using RMI to communicate from the framework-application to its "modules", and vice-versa. The master doesn't know the exact type of the remote interface of whatever child-module it needs to call, so it uses reflection to call the "create" on the EJBHome of whatever child-module it needs to invoke as well as the method on the actual remote-interface.
Please note, if I deploy both applications (master and child), and perform JNDI lookups from master to child, it works perfectly. As soon as I do a redeploy (or explicity undeploy, deploy), JNDI fails. External clients, though, works all the time. Also, if I redeploy the child before ever calling it from the parent-application, it also works after I did redeployment. It's as if, when you do a JNDI lookup the first time, it caches something and from there on it breaks if you do a redeploy and perform a consequent app-to-app JNDI lookup...
2.) dedicated.rmicontext=true
I tried this by setting it as a JNDI property before getting the InitialContext - makes no difference, unfortunately.
//========CODE============================
// This is in a SessionBean inside the Master Application. For the time being I've hard-coded the provider-url of the client-application.
// NOTE: This EXACT same code is used in the external java client - there it works perfect every time, whether I redeploy or not.
//========================================
Hashtable<String, String> env = new Hashtable<String, String>();
env.put(Context.INITIAL_CONTEXT_FACTORY, "com.evermind.server.rmi.RMIInitialContextFactory");
env.put(Context.PROVIDER_URL, "ormi://localhost/client-application");
env.put(Context.SECURITY_PRINCIPAL, "oc4jadmin");
env.put(Context.SECURITY_CREDENTIALS, "MyPassword");
env.put("dedicated.rmicontext","true");
InitialContext ctx = null;
try {
     ctx = new InitialContext(env);
     // WHEN I REDEPLOY, CODE CRASHES ON THE NEXT LINE
     Object home = ctx.lookup("ejb/TestWorkerAProxyBean");
     EJBHome obHome = (EJBHome) PortableRemoteObject.narrow(home, EJBHome.class);
     System.out.println("EJBHOME Is [" + obHome + "]");
     final Object invocationTarget = MethodUtils.invokeExactMethod(obHome,"create",new Object[0]);
     System.out.println("invocation target = [" + invocationTarget + "]");
     ClassLoader classLoader = Thread.currentThread().getContextClassLoader();
     IWorkerProxy proxy = (IWorkerProxy)Proxy.newProxyInstance(classLoader, new Class[]{IWorkerProxy.class}, new InvocationHandler() {
          public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
               try {
                    Method remoteEjbMethod = invocationTarget.getClass().getMethod(method.getName(),method.getParameterTypes());
                    return remoteEjbMethod.invoke(invocationTarget, args);
               } catch (Exception e) {
                    ExceptionHandler.handle(e);
               return null;
} catch (NamingException ne) {
     System.out.println("NamingException");
     ne.printStackTrace();
} catch (NoSuchMethodException e) {
     System.out.println("NoSuchMethodException");
     e.printStackTrace();
} catch (Exception e) {
     System.out.println("Other Exception");
     e.printStackTrace();
==========================
===========EXCEPTION (ONLY IF I REDEPLOY - IT WORKS PERFECT IF I RUN IT FIRST TIME)=================
==========================
06/09/25 17:15:51 NamingException
06/09/25 17:15:51 javax.naming.NameNotFoundException: ejb/TestWorkerAProxyBean not found
06/09/25 17:15:51 at com.evermind.server.rmi.RMIClientContext.lookup(RMIClientContext.java:51)
06/09/25 17:15:51 at javax.naming.InitialContext.lookup(InitialContext.java:351)
06/09/25 17:15:51 at com.myapp.master.RequestProcessorBean.processRequest(RequestProcessorBean.java:140)
06/09/25 17:15:51 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
06/09/25 17:15:51 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
06/09/25 17:15:51 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
06/09/25 17:15:51 at java.lang.reflect.Method.invoke(Method.java:585)
06/09/25 17:15:51 at com.evermind.server.ejb.interceptor.joinpoint.EJBJoinPointImpl.invoke(EJBJoinPointImpl.java:35)
06/09/25 17:15:51 at com.evermind.server.ejb.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:69)
06/09/25 17:15:51 at com.evermind.server.ejb.interceptor.system.DMSInterceptor.invoke(DMSInterceptor.java:52)
06/09/25 17:15:51 at com.evermind.server.ejb.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:69)
06/09/25 17:15:51 at com.evermind.server.ejb.interceptor.system.TxSupportsInterceptor.invoke(TxSupportsInterceptor.java:37)
06/09/25 17:15:51 at com.evermind.server.ejb.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:69)
06/09/25 17:15:51 at com.evermind.server.ejb.interceptor.system.DMSInterceptor.invoke(DMSInterceptor.java:52)
06/09/25 17:15:51 at com.evermind.server.ejb.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:69)
06/09/25 17:15:51 at com.evermind.server.ejb.StatelessSessionEJBObject.OC4J_invokeMethod(StatelessSessionEJBObject.java:86)
06/09/25 17:15:51 at RequestProcessorLocal_StatelessSessionBeanWrapper4.processRequest(RequestProcessorLocal_StatelessSessionBeanWrapper4.java:37)
06/09/25 17:15:51 at com.myapp.master.gateway.FrameworkGatewayBean.processObjectRequest(FrameworkGatewayBean.java:172)
06/09/25 17:15:51 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
06/09/25 17:15:51 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
06/09/25 17:15:51 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
06/09/25 17:15:51 at java.lang.reflect.Method.invoke(Method.java:585)
06/09/25 17:15:51 at com.evermind.server.ejb.interceptor.joinpoint.EJBJoinPointImpl.invoke(EJBJoinPointImpl.java:35)
06/09/25 17:15:51 at com.evermind.server.ejb.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:69)
06/09/25 17:15:51 at com.evermind.server.ejb.interceptor.system.DMSInterceptor.invoke(DMSInterceptor.java:52)
06/09/25 17:15:51 at com.evermind.server.ejb.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:69)
06/09/25 17:15:51 at com.evermind.server.ejb.interceptor.system.TxSupportsInterceptor.invoke(TxSupportsInterceptor.java:37)
06/09/25 17:15:51 at com.evermind.server.ejb.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:69)
06/09/25 17:15:51 at com.evermind.server.ejb.interceptor.system.DMSInterceptor.invoke(DMSInterceptor.java:52)
06/09/25 17:15:51 at com.evermind.server.ejb.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:69)
06/09/25 17:15:51 at com.evermind.server.ejb.StatelessSessionEJBObject.OC4J_invokeMethod(StatelessSessionEJBObject.java:86)
06/09/25 17:15:51 at FrameworkGatewayRemote_StatelessSessionBeanWrapper10.processObjectRequest(FrameworkGatewayRemote_StatelessSessionBeanWrapper10.java:94)
06/09/25 17:15:51 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
06/09/25 17:15:51 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
06/09/25 17:15:51 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
06/09/25 17:15:51 at java.lang.reflect.Method.invoke(Method.java:585)
06/09/25 17:15:51 at com.evermind.server.rmi.RmiMethodCall.run(RmiMethodCall.java:53)
06/09/25 17:15:51 at com.evermind.util.ReleasableResourcePooledExecutor$MyWorker.run(ReleasableResourcePooledExecutor.java:303)
06/09/25 17:15:51 at java.lang.Thread.run(Thread.java:595)

EJB JNDI lookup port

Hi,
If my AS Java's port is 50000, then the ejb port is 50004. Is it possible to change the default EJB JNDI lookup port to eg, 55555?
Thanks.
Any help will be highly appreciated.
- julius

hi,
in addition to above context
this may be help full to u
http://help.sap.com/saphelp_nw70ehp1/helpdata/en/a2/f9d7fed2adc340ab462ae159d19509/content.htm
bvr

JNDI lookup from Tomcat to EJB Container

Hello!
i am currently trying to use a combination of Catalina and an external EJB Server (running on another machine).
i am really struggeling with doing the jndi lookup. i have no idea where and how to set the properties in the web server and do the mapping from the ejb-refs to the jndi name? (since tomcat doesnt seem to have a deploymentplan?!)
maybe someone here knows the problem and can help, please?
(i am not sure but this might also be the wrong discussion group for that??)
thanks
wolfgang

Hello Wolfgang,
I solved this problem by setting the proper jndi properties in the startup phase (MyInitServlet) by System.setProperty(...).
This seems ugly, but it works.
Tilo

JNDI lookup from a Java stored proc?

Anybody know if a JNDI lookup, or accessing an EJB from a Java stored procedure is possible? I looked through all the docs and it says it is possible but doesn't specify how. In the java class thats resolved through the stored proc, how are the server generated classes and interfaces made available? Normally setting the classpath for the client app that does the lookup accomplishes this, but what if its called through the stored proc?

check the rdbms platform's "javavm" folder for a "readme.txt" file ...
In section 3.16.9, it discusses how to do this ...

UserTransaction - Scope using JNDI lookup from jspInit() method

Howdy,
I'm using JSP's with JavaBeans accessing a DataSource and some other enviroment variables using JNDI lookups. I've read that JNDI lookups can take a fair amount of time and should be limited whenever possible. My previous configuration had the JNDI lookups inside the constructors of the JavaBeans but I've recently decided to move them to the jspInit() method of the calling JSP. This way the lookup only needs to be performed once and then I pass the values to the JavaBean in a method called setContextVariables. Two of the references to objects that i'm sending are the UserTransaction and DataSource objects. Within the Javabeans I have userTran.begin() and commit() statements. So far it's running great but i'm starting to wonder about the thread safety of this method. My question lies in the actual delagation of the UserTransaction object to the calling client method. It seems that i'm passing the same transaction to every Javabean (or am I?) Is the transaction actually issued when the begin() method is called, or at the time of the JNDI lookup? To test everything out, I opened two sessions and put a breakpoint inside one of the transactions. When I stopped at the breakpoint I ran another thread (also using a transaction retrieved from the same JSP). Then I went back and resumed the first thread and everything seemed to work ok. So... this seems completely fantabulastic so far (definitely noticable response time increases) but I'm still a little skeptical. If anyone is using a process similar to this I would appreciate some feedback. Thanks.

Hi,
The EJB bean will use the client transaction when the following attributes are specified in descriptor.
1) Required
2) Mandatory
3) Supports
In Required case, if the client is associated with Transaction, then the EJB bean will use the same transaction. This is achieved by Transaction context. The EJB bean will use the same transaction context set by client. if the client doesn't have any transaction, then the container will create new transaction context for EJB bean and completes the transaction.
In Mandatory case, the client must be associated with Transaction so that EJB bean will use the same transaction. If the client doesn't associate with transaction, then container will throw TransactionRequiredException for EJB bean.
In Supports case, it works similar to Required case except that if the client doesn't associate with transaction, then there won't be any transaction in EJB bean.
hope this helps.

JWS - EJB JNDI Lookup problem

Hi,
I have a client Java application accessing a session EJB in a remote JBoss J2EE server. I'm using JWS 1.2 to deploy my application but when I do a JNDI lookup to get access the the remote's object home interface I get this error:
"Need to specify class name in environment or system property, or as an applet parameter, or in an application resorce file: java.naming.factory.initial"
All the jar files are signed and the JNPL file contains <all-permissions/>. This is the code that triggers the exception
jndiContext = new InitialContext();
homeRMIReference = jndiContext.lookup(C_SERVICE_NAME);
Any help would be appreciated.
Thanks in advance,
Rafael

Hi,
I've finally found the origin of the problem.
1. JNDI uses a minimum set of properties during initialization phase:
java.naming.factory.initial
java.naming.factory.url.pkgs
java.naming.provider.url
Therefore these properties must be set in the <resource> topic of the JNLP file. The value of these properties is defined in the jndi.properties file that you can find in jbossjmx.ant.jar (within the jboss/client directory)
2. You have to add the JBoss files to your bundle. For doing so I've unjared all the .jar files within the jboss/client directory; afterwards I have jared them in a single file "jboss.jar" and I've signed the file. I've added jboss.jar to the <resource> tag within the JNLP file (Note that I've added all the jboss files just to do quick check but usually you will have to add only those files you need (it doesn't make sense to deploy all JBoss files in each client application)
I hope this helps,
Rafael

ClassCastException on ejb jndi lookup

Hello,
I try to get an standalone remote client to to connect to my stateless session bean:
java.util.Properties props = new java.util.Properties();
props.put("java.naming.provider.url", "181.205.12.19:50004");
props.put("java.naming.factory.initial", "com.sap.engine.services.jndi.InitialContextFactoryImpl" );
props.put("java.naming.security.authentication", "simple");
props.put("java.naming.security.principal", "j2ee_admin");
props.put("java.naming.security.credentials", "*****");
jndiContext = new InitialContext(props);
fetching of jndi context is fine, but once I try to lookup my home interface I get a class cast exception:
home = (ToEdifactConverterHome) PortableRemoteObject.narrow(jndiContext.lookup ("sap.com/EdifactEar/ToEdifactConverterBean"), ToEdifactConverterHome.class);
java.lang.ClassCastException
     at com.sun.corba.se.internal.javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:293)
     at javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:134)
     at test.cceag.transform.TransformTester.setUp(TransformTester.java:74)
     at test.cceag.transform.TransformTester.main(TransformTester.java:48)
The jndi lookup seems to return the bean implementation object, but not the home interface itself.
Thanks for any hints
Matthias

Hi Matthias,
i think the   guide
"How to...EJB: Accessing EJB Applications Using JNDI"
will help you to solve the ejb lookup problem:
https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/0736159e-0301-0010-9ea4-c63d83d0797b
good luck, Katharina

JNDI lookup from Portal Application Module

Dear Experts,
I have a problem with looking up a Deployable Web Service Proxy from within a Portal Application Module.
I use NWDI and created both the Deployable WS Proxy DC and the Portal App DC.
I added the generated Proxy to the Proxy DC's public part and added it as used DC to the Portal Module DC.
When I perform the JNDI lookup, no exception is thrown but the Code is not executed any further...
Here is the source:
Category.APPLICATIONS.infoT( loc, "lookup JNDI...", new Object[] { this });
Object o = ctx.lookup(JNDI_NAME);
Category.APPLICATIONS.infoT( loc, o.getClass().getName(), new Object[] { this });
service = (OrchestrationService)o;
Category.APPLICATIONS.infoT(loc, "success!", new Object[] { this });
The log shows the name of the class (OrchestrationServiceImpl) but not the success! part.
As I said: No exceptions are thrown...
Any help is appreciated!
Matthias

Solved the problem!
It's allways the same:
As soon as you ask the question the answer comes to you by itself...
I needed to add a reference to the using DC. I already did that before but not correctly:
If you want to add a reference to a j2ee application you need to read this document:
[Calling J2EE Applications from Portal Applications|http://help.sap.com/erp2005_ehp_03/helpdata/EN/42/9ddf20bb211d72e10000000a1553f6/frameset.htm]
It says the reference has to look like this:
<property name="SharingReference" value="SAPJ2EE::sap.com/Hello"/>
I hope it helps someone.

Client EJB JNDI lookup broken in OC4J 9.0.2?

I have a client program that connects to an EJB in the application server and invokes methods on it. If it look up the EJB using the actual JNDI binding, it works fine. If I look it up in java:comp/env (and use the ejb-ref in application-client.xml and ejb-ref-mapping in orion-application-client.xml) the client program catches the following exception:
caught : javax.naming.NameNotFoundException: No object bound for java:comp/env/ejb/logging/Logger
javax.naming.NameNotFoundException: No object bound for java:comp/env/ejb/logging/Logger
at com.sun.enterprise.naming.java.javaURLContext.lookup(javaURLContext.java:116)
at javax.naming.InitialContext.lookup(InitialContext.java:347)
at com.mycompany.common.logging.ejb.test.LoggerEJBTest.main(LoggerEJBTest.java:37)
Now, assuming I don't have any typos (and I'd be thrilled if someone pointed it out if that were the case), then it looks like this is a bug in OC4J 9.0.2: the ejb-ref and ejb-ref-mapping elements do not work. For the record, I am using the same ejb-ref and ejb-ref-mapping elements for a servlet's web.xml and orion-web.xml, respectively, without problems.
Here are relevant file excerpts:
LoggerEJBTest.java:
String hostName = "localhost";
String hostPort = "23791";
String userName = "abc";
String password = "def";
String providerURL = "ormi://" + hostName + ":" + hostPort + "/ghi";
Hashtable env = new Hashtable();
env.put(Context.INITIAL_CONTEXT_FACTORY, "com.evermind.server.ApplicationClientInitialContextFactory");
env.put(Context.PROVIDER_URL, providerURL);
env.put(Context.SECURITY_PRINCIPAL, userName);
env.put(Context.SECURITY_CREDENTIALS, password);
System.out.println("create initial context");
Context context = new InitialContext(env);
System.out.println("get home object");
//works when uncommented
//Object homeObject = context.lookup("logging/Logger");
//broken:
Object homeObject = context.lookup("java:comp/env/ejb/logging/Logger");
ejb-jar.xml:
<?xml version="1.0"?>
<!DOCTYPE ejb-jar PUBLIC "-//Sun Microsystems, Inc.//DTD Enterprise JavaBeans 2.0//EN" "http://java.sun.com/dtd/ejb-jar_2_0.dtd">
<ejb-jar>
<description>abc</description>
<display-name>abc</display-name>
<enterprise-beans>
<session>
<description>Logger Bean</description>
<display-name>Logger</display-name>
<ejb-name>Logger</ejb-name>
<home>com.mycompany.common.logging.ejb.LoggerHome</home>
<remote>com.mycompany.common.logging.ejb.Logger</remote>
<ejb-class>com.mycompany.common.logging.ejb.LoggerBean</ejb-class>
<session-type>Stateless</session-type>
<transaction-type>Container</transaction-type>
</session>
</enterprise-beans>
</ejb-jar>
orion-ejb-jar.xml:
<?xml version="1.0"?>
<!DOCTYPE orion-ejb-jar PUBLIC "-//Evermind//DTD Enterprise JavaBeans 2.0 runtime//EN" "http://xmlns.oracle.com/ias/dtds/orion-ejb-jar.dtd">
<orion-ejb-jar>
     <enterprise-beans>
          <session-deployment name="Logger" location="logging/Logger">
     </enterprise-beans>
</orion-ejb-jar>
application-client.xml:
<?xml version="1.0"?>
<!DOCTYPE application-client PUBLIC "-//Sun Microsystems, Inc.//DTD J2EE Application Client 1.3//EN" "http://java.sun.com/dtd/application-client_1_3.dtd">
<application-client>
     <display-name>logging test</display-name>
<ejb-ref>
<ejb-ref-name>ejb/logging/Logger</ejb-ref-name>
<ejb-ref-type>Session</ejb-ref-type>
<home>com.mycompany.common.logging.ejb.LoggerHome</home>
<remote>com.mycompany.common.logging.ejb.Logger</remote>
<ejb-link>Logger</ejb-link>
</ejb-ref>
</application-client>
orion-application-client.xml:
<?xml version="1.0"?>
<!DOCTYPE orion-application-client PUBLIC "-//Evermind//DTD J2EE Application-client runtime 1.2//EN" "http://xmlns.oracle.com/ias/dtds/orion-application-client.dtd">
<orion-application-client>
<ejb-ref-mapping location="logging/Logger" name="ejb/logging/Logger" />
</orion-application-client>

As far as I know, the only way to lookup an EJB (deployed to
OC4J) from a regular java class using the "ApplicationClientInitialContextFactory"
class and the logical JNDI name is to include your regular java
class (i.e. the client) in your application's EAR file (the file
you use to deploy your application to OC4J).OK, but that sounds like a pretty silly constraint. Shouldn't the ApplicationClientInitialContextFactory know how to do the mapping using the application-client.xml and orion-application-client.xml settings? What does the OC4J server provide that makes this magically work?
From the information you have supplied, it appears that you may
not want to include your client (java) class in your EAR file.That is correct. It is an integration test program, not meant to be deployed into the application server.
So now the question is, "Do you want to make your client part
of your J2EE application, and include it in the application
EAR file?"
If you do, then you have made several mistakes which prevent
you from doing that, but I don't want to explain further, since
you may not want to do that, anyway!Not applicable. But on that topic, aside from being able to auto-start a client application within the OC4J JVM, are there any other reasons why I might want to deploy a client in that manner? I mean, honestly, these things are called "clients" and "servers" for a reason.
Now if you have been reading other postings to this forum,
and if you have read the documentation for OC4J, you would
know that it requires J2SDK 1.3.1 only (not 1.4.0).I am well aware of the other postings on that topic. I am, however, counting on Oracle to live up to their promise to certify 1.4 with with the next update to OC4J:
Limits of 10g
That aside, I already consider OC4J 9.0.2 to be a broken product at this point anyway, so hacking it to use Java 1.4 doesn't bother me that much. OC4J 9.0.2 works about as well with Java 1.4 as with Java 1.3, assuming one replaces the tools.jar. The other major incompatibility is that Oracle SOAP breaks if a web service EJB home&remote interface is compiled with Java 1.4:
http://forums.oracle.com/forums/message.jsp?id=936894
Alas, we're using Apache SOAP 2.3 rather than the ass-backwards stuff in OC4J, anyways, so there's no problem.

JNDI lookup from proxied applet is slow

Hi,
I am doing a t3s lookup for an EJB from an applet. The lookup is fairly fast (<
1 sec) if the browser is
setup to not use an HTTP proxy server. However, if the browser is setup to go
via a proxy server, the
t3s lookup takes upwards of 30 seconds.
Running the Weblogic server with -Dweblogic.system.enableReverseDNSLookups=false
makes
no difference.
I am using WLS5.1SP9, and Netscape 4.7 and IE5 browsers.
Any suggestions, please?
Thanks
Ravi

Your File-system Object Store should be in a place
accessible by your client application. Then you can
specify JNDI properties
java.naming.factory.initial
java.naming.provider.url
for the initial context. There are examples in
<install-directory>/examples/jms directory.
The ConnectionFactory object you created should
have broker hostname and port (if not default)
specified.
amy

EJB JNDI Lookup String?

Hi,
just a short question, I try to lookup an EJB from JNDI. I found some JNDI in the documentation of how to use EJB from JSP.
Unfortunately the documentation just says:
try {
InitialContext ic = new InitialContext();
HelloWorldBean h= (HelloWorldBean)ic.lookup("java:comp/env/<HelloWorldBean_Lookup_String>");
out.println(h.sayHello());
catch...
I'm pretty sure "<HelloWorldBean_Lookup_String>" is not the correct lookup string
Which one is it?
Frank

What I did now is to add the following into my web.xml:
<ejb-local-ref>
<ejb-ref-name>ejb/MyBean</ejb-ref-name>
<local>package.MyBean</local>
</ejb-local-ref>
and the lookup through:
InitialContext ic = new InitialContext();
Mybean bean = (MyBean)ic.lookup("java:comp/env/ejb/MyBean");
Thanx for all your help
Frank

ClassCastException - While type casting Home object after EJB JNDI Lookup

Sun One Application Server throws a ClassCastException when I try to type cast Home object to it's respective interface type.
Here is the code ---
==============================================
Object obj = PortableRemoteObject.narrow( context.lookup( jndiName ), homeClass);
System.out.println("Remote Object - obj : "+obj);
if (obj != null) {
   System.out.println("obj.getClass().getName() : "+obj.getClass().getName());
   System.out.println("obj.getClass().getSuperclass() : "+obj.getClass().getSuperclass());
   Class[] interfaces = obj.getClass().getInterfaces();
   if (interfaces != null) {
      for (int count = 0; count < interfaces.length; count++) {
         System.out.println("interfaces[ " + count + " ].getName() : " + interfaces[ count ].getName());
}==============================================
The class name is dislpayed as the Stub class name.
While displaying the interfaces, the Home Interface name is displayed.
But later when I try to type cast it into Home Interface type, it throws a ClassCastException.
Can somebody please check this?

Please post the stack trace. Also, take a look at our EJB FAQ to make sure you're doing the
recommended lookup :
https://glassfish.dev.java.net/javaee5/ejb/EJB_FAQ.html

EJB JNDI access from app1 to app2 in same oc4j (standalone) 9.0.4

I have two applications CatalogosWeb and WSCatalogosWeb both in the same instance of a 9.0.4 standalone OC4J. The first one implements a set of EJB's (both entity and session). In the second i have the EJB classes included int the "classes" directory.
When I try to acces de EJB from the second application I get a ClassCastException.
The source code is approximately:
ic = new InitialContext(env);
where env is>
{java.naming.provider.url=ormi://localhost:23791/CatalogosWeb, java.naming.factory.initial=com.evermind.server.rmi.RMIInitialContextFactory, java.naming.security.principal=admin, java.naming.security.credentials=welcome}
later I try to access the EJB>
Object objref = ic.lookup(jndiHomeName);
Object obj = PortableRemoteObject.narrow(objref, className);
When the PortableRemoteObject tries to "narrow" the class I get the ClassCastException.

user496903 ,
When you need to perform lookups within the same OC4J container, you don't use RMIInitialContextFactory. Instead, you should use the new InitialContext() constructor, that defaults the initial context factory property to (if my memory doesn't fail) ApplicationInitialContextFactory...
Look for more info in the Oracle App Server EJB developer Guide,
hope it helps
RB

JNDI lookup from OC4J to weblogic throws javax.naming.NameNotFoundException

Hi All,
We have the below setup in our production environment.
EJB application is deployed in the Weblogic 10.3.4.0 Server on Sun Solaris. The EJB version is 3.0
OC4J 10.2.0 is running on another Sun Solaris machine.
There are 2 webservice applications WEBSERV1 & TestSoapEJB running on this OC4J container.
We need to do lookup the EJBs deployed on the Weblogic server. For this we used the below logic in the web service's Stateless session bean:
String weblogicURL = "";
Properties props = new Properties();
try
props.load(Thread.currentThread().getContextClassLoader().getResourceAsStream("wl.properties"));
weblogicURL     = props.getProperty("weblogicURL");
catch (FileNotFoundException e)
e.printStackTrace();
catch (IOException e)
e.printStackTrace();
Context ctx = null;
Hashtable ht = new Hashtable();
ht.put(Context.INITIAL_CONTEXT_FACTORY, "weblogic.jndi.WLInitialContextFactory");
ht.put(Context.SECURITY_PRINCIPAL,"weblogic");
ht.put(Context.SECURITY_CREDENTIALS,"weblogic654");
ht.put(Context.PROVIDER_URL, weblogicURL);
ctx = NamingManager.getInitialContext(ht) ;
// tried using //ctx = new InitialContext(ht); same behavior.
TestEJB.AdministratorEJB ejb = (TestEJB.AdministratorEJB) ctx.lookup("TestEJB#TestEJB.AdministratorEJB");
ctx.close();
When we first test first WEBSER1, the lookup is fine.
But when we test the second webservice WEBSER2, the webservice name itself not able to lookup: It gives the below error:
javax.naming.NameNotFoundException: remaining name: env/TestSoapEJB
Below is the stack throws thrown on browser:
500 Internal Server Error
javax.naming.NameNotFoundException: remaining name: env/TestSoapEJB
at weblogic.j2eeclient.SimpleContext.resolve(SimpleContext.java:35)
at weblogic.j2eeclient.SimpleContext.resolve(SimpleContext.java:39)
at weblogic.j2eeclient.SimpleContext.lookup(SimpleContext.java:59)
at weblogic.j2eeclient.SimpleContext.lookup(SimpleContext.java:59)
at weblogic.j2eeclient.SimpleContext.lookup(SimpleContext.java:64)
at weblogic.jndi.factories.java.ReadOnlyContextWrapper.lookup(ReadOnlyContextWrapper.java:45)
at weblogic.jndi.internal.AbstractURLContext.lookup(AbstractURLContext.java:130)
at javax.naming.InitialContext.lookup(InitialContext.java:392)
at oracle.j2ee.ws.SessionBeanRpcWebService.init(SessionBeanRpcWebService.java:65)
at javax.servlet.GenericServlet.init(GenericServlet.java:258)
at com.evermind[Oracle Application Server Containers for J2EE 10g (10.1.2.0.2)].server.http.HttpApplication.loadServlet(HttpApplication.java:2354)
at com.evermind[Oracle Application Server Containers for J2EE 10g (10.1.2.0.2)].server.http.HttpApplication.findServlet(HttpApplication.java:4795)
at com.evermind[Oracle Application Server Containers for J2EE 10g (10.1.2.0.2)].server.http.HttpApplication.getRequestDispatcher(HttpApplication.java:2821)
at com.evermind[Oracle Application Server Containers for J2EE 10g (10.1.2.0.2)].server.http.HttpRequestHandler.processRequest(HttpRequestHandler.java:680)
at com.evermind[Oracle Application Server Containers for J2EE 10g (10.1.2.0.2)].server.http.HttpRequestHandler.run(HttpRequestHandler.java:285)
at com.evermind[Oracle Application Server Containers for J2EE 10g (10.1.2.0.2)].server.http.HttpRequestHandler.run(HttpRequestHandler.java:126)
at com.evermind[Oracle Application Server Containers for J2EE 10g (10.1.2.0.2)].util.ReleasableResourcePooledExecutor$MyWorker.run(ReleasableResourcePooledExecutor.java:186)
at java.lang.Thread.run(Thread.java:662)
It seems that, the OC4J is looking in Weblogic context. But it should be looking in its own context. How to resolve this issue.
The same case happens if i restart the OC4J and first test the TestSoapEJB the lookup is fine . But if i test the WEBSERV1 , it throws the same error as above. In short, if one of the webservices lookup is working fine, the other webservice is not working. At the same time only one webservice's lookup is working.
Kindly help me to resolve this issue.
regards,
Zia
Edited by: PT Expert on Sep 9, 2012 3:16 AM

I work now more that two days on this error!!!
-> I remade my complete jdev project, it did not work!
-> I deleted the jdev/system/j2ee/oc4j/workspace dir
-> I search for some .lock files
-> and many more tries!!! But without success...
Is there a way to reset the Embedded OC4J?

EJB 3 jndi lookup from glassfish to glassfish

Similar Messages

Maybe you are looking for