EJB redirection - lookup or inject defaults ?
Hi,
As a starting point:
I have 2 layers in my app. Both layer contains stateless session beans.
EJBs of Layer1 call EJBs of Layer2.
EJBs of Layer2 can be customized by replacing some of them with custom implementations.
The configuration of these custom EJBs are stored in the database (mainly business interface, jndi name pairs)
EJBs of Layer2: ~20
The usage of EJBs of Layer2 in an EJB of Layer1: ~5
And now the question:
How the redirection logic should be implemented in Layer1?
1. Creating an EJB e.g. "LookupBean". It would be called by EJBs of Layer1: e.g. <T> T getService(Class<T> businessInterface)
It would try to lookup first the custom impl, if it does not exist than it would return with the default impl. But how should the default impl. be obtained?
1.1 the defaults are injected into reference variables
1.2. the defaults are also looked up
1.3. the getService should not contain the redirection logic, the proper impls. are set during the EJB creation in a @PostConstruct annotated method
and then getService method can simple return with the proper reference variable
2. The EJBs of Layer1 should call this "LookupBean". But when?
2.1. every time before a call of an EJB of Layer2.
2.2 right after the EJB is created reference variables is set to the proper impl. in a
@PostConstruct annotated method
3. Maybe the "LookupBean" is totally unnecessary and in a EJB of Layer1 we can do rather for the ~4 EJB ref setting (default or custom)
in the @PostConstruct annotated method. Currently this redirection is not added and if we chose this way the business methods should
not call the additional "LookupBean". On the other hand similar logic should be added for each of the EJBs in the Layer1 (not a big logic by the way:)
(I know that in some JaveEE 5 implementations the usage of the @EJB annotation itself gives a way to the configure which impl to set by an admin,
but in our case storing it a database table is a must and therefore using the @EJB annotation for this purpose is not an option.)
Returning to my question:
I already have a preferred way, but I am very interested in your opinions as well.
I have the following in my mind: if I choose one way against the other, how it influences the clearness/simpliness of the code and
whether there is any difference in the performance between these options.
Please, share your opinions with me.
Hi,
It should work in 11g.
Regards,
Kal
Similar Messages
-
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.
- juliushi,
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 -
EJB 3.0 Dependency Injection in JSF ?
Hi,
I have a question about ejb 3.0 dependency injection in a JSF WebApp:
I Build successfully a Web Module (version 2.5) an EJB Module (version 3.0) and an EAR Module (Version 5.0). The EAR App can be deployed without errors on a Bea WebLogic Server 10.1. All modules are successfully deployed.
Inside the Web Module there is a Servlet which uses dependency injection to access the session EJB form the EJB Module. This works perfect.
Next I try to use the same EJB with dependency injection from the JSF Page via a backing bean. But when I try to access my JSP Page I got a Nullpointer Exception.
It seems that the Dependency Injection in the JSP App did not work?
Can anybody give me a hint what could be wrong?
Thanks
RalphThere is currently no possiblity in Weblogic 10 server web layer to use Dependency Injection on any other component than the ones defined in web.xml s.a.:
- servlets
- listeners
- filters
See here:
http://e-docs.bea.com/wls/docs100/webapp/annotateservlet.html
A simple POJO class part of the web application (such as a Backing Bean in JSF or an Action in Struts for example) is not benefiting from DI.
Doesn't this make Weblogic 10 a NON JEE 5 compliant server?
Why was this restriction imposed?
And how is one supposed to use DI with a simple POJO class? Why this huge inconvenience? -
Hi, problem occurs when I'm clicking a button or a new url on the current site. For instance, when i clicked that "Ask This" button on this web site, It redirects me to the default homepage. I cant go back and I'm losing the previous web site HELP PLEASE!
Try the Firefox SafeMode. <br />
''A troubleshooting mode, which disables most Add-ons.'' <br />
''(If you're not using it, switch to the Default Theme.)''
# You can open the Firefox 4.0 SafeMode by holding the '''Shft''' key when you use the Firefox desktop or Start menu shortcut.
# Or use the Help menu item, click on '''Restart with Add-ons Disabled...''' while Firefox is running. <br />
''To exit the Firefox Safe Mode, just close Firefox and wait a few seconds before using the Firefox shortcut (without the Shft key) to open it again.''
If it is good in the Firefox SafeMode, your problem is probably caused by an extension, and you need to figure out which one. <br />
http://support.mozilla.com/en-US/kb/troubleshooting+extensions+and+themes -
EJB JTA EntityManager not injected (null)
Hello,
I'm writing an enterprise application which uses JSF, EJB and the Java Persistence API (JPA) and I ran into a problem.
I'm trying to implement username and password based authentication with the username and password stored in a database. The problem is that I cannot access the database because my injected EntityManager is always null.
Here are some details: My application is called application, it has two modules: a Web application module (application-web) and an EJB module (application-ejb).
I have a JSP page in which I use JSF tag libraries (login.jsp). I have a backing bean specifically for authentication purposes, called AuthenticationBackingBean. The backing bean is properly declared in faces-config.xml, I can access it without any problems. It has a method, authenticate, which I use to check if the current username and password (stored in the bean from the JSP) validate against the database. authenticate solves this by calling an EJB method with the same name. The EJB is injected with the @EJB annotation. It works, there's no problem calling the authenticate method of the EJB through the remote interface.
The problems begin in my EJB, AuthenticationBean. I inject the EntityManager (em) into the EJB with the @PersistenceContext annotation. I understand that injecting it into EJBs should work, because they're container-managed. The problem is that it is always null, I used java.utils.logging.Logger to log its value in the server log. I also tried to inject EntityManagerFactory with the @PersistenceUnit annotation. It doesn't work either, it's null, just like em. I have read about 10 other posts and could not find any solution.
Some other information: I inject the EntityManager in the EJB outside of any method, I understood that it would pose a problem. The server doesn't say anything, the DB tables are created. I'm using Sun Java System Application Server Platform Edition 9.0 Update 1 Patch 1.
Here are some of the relevant parts of the code:
AuthenticationBackingBean.java
(the backing bean)
package com.aci.application.backing;
import com.aci.application.ejb.AuthenticationRemote;
import javax.ejb.EJB;
public class AuthenticationBackingBean
private Boolean authenticated;
private String password;
private String username;
@EJB
AuthenticationRemote authenticationBean;
public AuthenticationBackingBean()
authenticated = false;
public String authenticate()
if (authenticationBean.authenticate(username, password) == false)
return "failure";
return "success";
public Boolean getAuthenticated()
return authenticated;
public void setAuthenticated(Boolean authenticated)
this.authenticated = authenticated;
public String getPassword()
return password;
public void setPassword(String password)
this.password = password;
public String getUsername()
return username;
public void setUsername(String username)
this.username = username;
AuthenticationBean.java
(the EJB)
package com.aci.application.ejb;
import com.aci.application.entity.UserDBAO;
import java.util.logging.Logger;
import javax.ejb.Stateless;
import javax.persistence.EntityManager;
import javax.persistence.PersistenceContext;
@Stateless
public class AuthenticationBean implements com.aci.application.ejb.AuthenticationRemote
private UserDBAO dbao;
@PersistenceContext
private EntityManager em;
private Logger logger;
public AuthenticationBean()
dbao = new UserDBAO(em);
logger = Logger.getLogger("com.aci.application.ejb.AuthenticationBean");
String record = "";
record += "em: " + em + "\n";
logger.info(record);
public Boolean authenticate(final String username, final String password)
if (dbao.getUserByCredentials(username, password) == null)
return false;
return true;
UserDBAO.java
(I use this class to access the entities (currently only entity).)
package com.aci.application.entity;
import java.util.logging.Logger;
import javax.persistence.EntityManager;
public class UserDBAO
private EntityManager em;
private Logger logger;
public UserDBAO(EntityManager em)
this.em = em;
logger = Logger.getLogger("com.aci.application.entity.UserDBAO");
public User getUserByCredentials(final String username, final String password)
String record = "";
record += "em: " + em + "\n";
logger.info(record);
return null;
return (User)em.createNamedQuery("getUserByCredentials")
.setParameter("username", username)
.setParameter("password", password)
.getSingleResult();
User.java
(the entity)
package com.aci.application.entity;
import java.io.Serializable;
import javax.persistence.Column;
import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.GenerationType;
import javax.persistence.Id;
import javax.persistence.NamedQuery;
import javax.persistence.Table;
@Entity
@NamedQuery
name = "getUserByCredentials",
query =
"SELECT user " +
"FROM User user " +
"WHERE user.username = :username AND user.password = :password"
@Table(name = "Users")
public class User implements Serializable
private Long id;
private String username;
private String password;
@Id
@GeneratedValue(strategy = GenerationType.TABLE)
public Long getId()
return this.id;
public void setId(Long id)
this.id = id;
@Column(name = "username")
public String getUsername()
return username;
public void setUsername(String username)
this.username = username;
@Column(name = "password")
public String getPassword()
return password;
public void setPassword(String password)
this.password = password;
persistence.xml
I've read that if some version number is wrong the container does not bother to inject.
<?xml version="1.0" encoding="UTF-8"?>
<persistence version="1.0" xmlns="http://java.sun.com/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd">
<persistence-unit name="ApplicationPersistenceUnit" transaction-type="JTA">
<provider>oracle.toplink.essentials.ejb.cmp3.EntityManagerFactoryProvider</provider>
<jta-data-source>jdbc/TestDB</jta-data-source>
<properties>
<property name="toplink.ddl-generation" value="create-tables"/>
</properties>
</persistence-unit>
</persistence>I don't know if this will do any good, but I'm posting web.xml and faces-context.xml too.
web.xml
<?xml version="1.0" encoding="UTF-8"?>
<!--
<web-app version="2.5"
xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd">
-->
<web-app xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
version="2.5">
<servlet>
<servlet-name>Faces Servlet</servlet-name>
<servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>Faces Servlet</servlet-name>
<url-pattern>/faces/*</url-pattern>
</servlet-mapping>
<session-config>
<session-timeout>30</session-timeout>
</session-config>
</web-app>
faces-context.xml
<?xml version='1.0' encoding='UTF-8'?>
<faces-config version="1.2" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-facesconfig_1_2.xsd">
<navigation-rule>
<from-view-id>/login.jsp</from-view-id>
<navigation-case>
<from-outcome>failure</from-outcome>
<to-view-id>/failure.jsp</to-view-id>
</navigation-case>
<navigation-case>
<from-outcome>success</from-outcome>
<to-view-id>/success.jsp</to-view-id>
</navigation-case>
</navigation-rule>
<managed-bean>
<managed-bean-name>authentication</managed-bean-name>
<managed-bean-class>com.aci.application.backing.AuthenticationBackingBean</managed-bean-class>
<managed-bean-scope>session</managed-bean-scope>
</managed-bean>
</faces-config>I'm totally new to Java EE, this is my first application (test program), I would really appreciate some detailed information, please.Hi Csabi,
Glad to hear it fixed your issue.
--ken -
Can Apache plug-in redirect lookup of EJB?
Apache plug-in can redirect URLs. I have setup the Apache plug-in to redirect initial context calls to the WLC host and successfully obtained an initial context via this redirection. I received an error when I attempt a lookup of a deployed EJB if the provider URL used in the lookup is that of the Apache plug-in instead of the WLC host. When I invoked the initial context's lookup the following error occurred:
javax.naming.NameNotFoundException: Unable to resolve com.harris.netboss.shared.
service.ServiceRegistrarHome Resolved: '' Unresolved:'com' ; remaining name 'har
ris.netboss.shared.service.ServiceRegistrarHome'
at com.harris.netboss.shared.comm.connector.EJBConnect.connect(EJBConnec
t.java:151)
at test.com.harris.netboss.shared.comm.connector.EJBConnectTester.<init>
(EJBConnectTester.java:24)
at test.com.harris.netboss.shared.comm.connector.EJBConnectTester.main(E
JBConnectTester.java:41)
The Apache plug-in is obviously not redirecting a lookup to the WLC. Has anyone ever used the Apache server to redirect **BOTH** initial context and lookup?
Thank you.Apache plug-in can redirect URLs. I have setup the Apache plug-in to redirect initial context calls to the WLC host and successfully obtained an initial context via this redirection. I received an error when I attempt a lookup of a deployed EJB if the provider URL used in the lookup is that of the Apache plug-in instead of the WLC host. When I invoked the initial context's lookup the following error occurred:
javax.naming.NameNotFoundException: Unable to resolve com.harris.netboss.shared.
service.ServiceRegistrarHome Resolved: '' Unresolved:'com' ; remaining name 'har
ris.netboss.shared.service.ServiceRegistrarHome'
at com.harris.netboss.shared.comm.connector.EJBConnect.connect(EJBConnec
t.java:151)
at test.com.harris.netboss.shared.comm.connector.EJBConnectTester.<init>
(EJBConnectTester.java:24)
at test.com.harris.netboss.shared.comm.connector.EJBConnectTester.main(E
JBConnectTester.java:41)
The Apache plug-in is obviously not redirecting a lookup to the WLC. Has anyone ever used the Apache server to redirect **BOTH** initial context and lookup?
Thank you. -
Remote EJB 3 lookup error in Sun JAS 9.01
Hello,
I have a very simply EJB 3 deployed to a remote SJAS 9.01 (say, in the host "Jupiter") that has only one remote business interface that returns a string. The JNDI name is "mypackage.MyBean".
On a local host (named "Earth", local) there is a simple App Client:
package appCliente;
import javax.ejb.EJB;
public class SlessAppClient {
@EJB (mappedName="corbaname:iiop:jupiter:3700#mypackage.MyBean")
private static mypackage.MyBeanRemote bean;
public static void main(String args[]) {
System.out.println(" *** My Bean : " + bean.hello());
This works fine (i.e. with injection).
What must I do to change this to a "lookup" to use with dinamic (runtime) lookup?
I suppose it should be like this:
package appCliente;
import javax.ejb.EJB;
public class SlessAppClient {
// Do not use injection:
////// @EJB /////(mappedName="corbaname:iiop:jupiter:3700#mypackage.MyBean")
private static mypackage.MyBeanRemote bean;
public static void main(String args[]) {
Properties props = new Properties();
props.setProperty("org.omg.CORBA.ORBInitialHost", "jupiter");
InitialContext ic = new InitialContext(props);
sless = (MyBeanRemote) ic.lookup("mypackage.MyBean");
System.out.println(" *** My Bean : " + bean.hello());
But this doesn't work!!!
(After getting something like this working, let's change to the "no parameters" InitialContext)
Tried the Glassfish EJB FAQs suggestions, but didn't work either.
Please, anybody has any suggestions?
Thanks for any help.Thanks
I added appserv-rt.jar file in classpath and run the code
code is like this
@EJB(name="192.168.0.32/TemperatureBean")
private static TemperatureRemote temperatureBean;
private static TemperatureRemote convert;
URL url;
JFrame frame=new JFrame("Temperature Converter");
JPanel p=new JPanel();
JLabel label1=new JLabel("Enter temperature");
JTextField text=new JTextField();
JLabel label2=new JLabel();
JButton button=new JButton("Convert");
It gives me following exception
javax.naming.NameNotFoundException
at com.sun.enterprise.naming.TransientContext.resolveContext(TransientContext.java:255)
at com.sun.enterprise.naming.TransientContext.lookup(TransientContext.java:178)
at com.sun.enterprise.naming.SerialContextProviderImpl.lookup(SerialContextProviderImpl.java:61)
at com.sun.enterprise.naming.RemoteSerialContextProviderImpl.lookup(RemoteSerialContextProviderImpl.java:116)
at sun.reflect.GeneratedMethodAccessor142.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.corba.ee.impl.presentation.rmi.ReflectiveTie._invoke(ReflectiveTie.java:121)
at com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatchToServant(CorbaServerRequestDispatcherImpl.java:650)
at com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(CorbaServerRequestDispatcherImpl.java:193)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequestRequest(CorbaMessageMediatorImpl.java:1705)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:1565)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleInput(CorbaMessageMediatorImpl.java:947)
at com.sun.corba.ee.impl.protocol.giopmsgheaders.RequestMessage_1_2.callback(RequestMessage_1_2.java:178)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:717)
at com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.dispatch(SocketOrChannelConnectionImpl.java:473)
at com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.doWork(SocketOrChannelConnectionImpl.java:1270)
at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:479)
can you help me? -
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?
DAvi - 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 3.0 Dependency Injection and reentrant Calls on SFSB
Hi there
I have a SFSB (Bean A) that injects another SFSB (Bean B) with the @EJB annotation. Now Bean A does reentrant-calls on Bean B, which is ok, because it just asks for the current state.
This results in a "javax.ejb.EJBTransactionRolledbackException: Illegal attempt to make a reentrant call to a stateful session bean from home: .....; nested exception is: javax.ejb.ConcurrentAccessException: Illegal attempt to make a reentrant call to a stateful session bean: ....."
Now I added a weblogic-ejb-jar.xml with the section:
<stateful-session-descriptor>
<allow-concurrent-calls>true</allow-concurrent-calls>
</stateful-session-descriptor>to enable reentrant calls on my SFSB. Unfortunatly this leads to problems with the DI, it simply doesnt work anymore!!! The message now is " java.lang.IllegalStateException: Cannot find object BeanBInterface with java:comp/env/ejb/BeanBInterface". Obviously the DI didn't work, the local variable isn't filled anmyore.
Is this a bug of WLS 10.0 MP1 or a feature? Should I open a bug report? Any tips a welcome!
StephanThere is currently no possiblity in Weblogic 10 server web layer to use Dependency Injection on any other component than the ones defined in web.xml s.a.:
- servlets
- listeners
- filters
See here:
http://e-docs.bea.com/wls/docs100/webapp/annotateservlet.html
A simple POJO class part of the web application (such as a Backing Bean in JSF or an Action in Struts for example) is not benefiting from DI.
Doesn't this make Weblogic 10 a NON JEE 5 compliant server?
Why was this restriction imposed?
And how is one supposed to use DI with a simple POJO class? Why this huge inconvenience? -
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. -
EJB3.0 App Deplyed wid warnings : Object not found in lookup of JPA-DEFAULT
Hello Friends
I am getting this warning while deploying this EJB 3.0 Application
here I have
1) 4 DCs with session beans
2) One Entity DC
I have checked my jta-data-source its added properly
here is the deployment stack trace
Description:
1. Exception has been returned while the 'asianpaints.com/hssp_app_new' was starting. Warning/Exception :
[ERROR CODE DPL.DS.6193] Error while ; nested exception is:
com.sap.engine.services.deploy.exceptions.ServerDeploymentException: [ERROR CODE DPL.DS.5030] Clusterwide exception: server ID 6358450:com.sap.engine.services.orpersistence.container.deploy.ActionException: [ERROR CODE DPL.DS.5030] Clusterwide exception: com.sap.engine.services.jndi.persistent.exceptions.NameNotFoundException: Object not found in lookup of JPA_DEFAULT.
at com.sap.engine.services.jndi.implserver.ServerContextImpl.lookup(ServerContextImpl.java:584)
at com.sap.engine.services.jndi.implclient.ClientContext.lookup(ClientContext.java:343)
at com.sap.engine.services.jndi.implclient.ClientContext.lookup(ClientContext.java:637)
at javax.naming.InitialContext.lookup(InitialContext.java:351)
at javax.naming.InitialContext.lookup(InitialContext.java:351)
at com.sap.engine.services.orpersistence.container.deploy.impl.ComplexModuleCreator.initDataSources(ComplexModuleCreator.java:344)
at com.sap.engine.services.orpersistence.container.deploy.impl.ComplexModuleCreator.initRuntimeModels(ComplexModuleCreator.java:230)
at com.sap.engine.services.orpersistence.container.deploy.impl.ComplexModuleCreator.createModule(ComplexModuleCreator.java:154)
at com.sap.engine.services.orpersistence.container.deploy.impl.ComplexModuleCreator.execute(ComplexModuleCreator.java:84)
at com.sap.engine.services.orpersistence.container.deploy.impl.ComplexActionAdapter.execute(ComplexActionAdapter.java:34)
at com.sap.engine.services.orpersistence.container.deploy.impl.ApplicationCreator.execute(ApplicationCreator.java:74)
at com.sap.engine.services.orpersistence.container.deploy.impl.PersistenceContainer.prepareStart(PersistenceContainer.java:187)
at com.sap.engine.services.deploy.server.application.StartTransaction.prepareCommon(StartTransaction.java:219)
at com.sap.engine.services.deploy.server.application.StartTransaction.prepare(StartTransaction.java:179)
at com.sap.engine.services.deploy.server.application.ApplicationTransaction.makeAllPhasesOnOneServer(ApplicationTransaction.java:420)
at com.sap.engine.services.deploy.server.application.ApplicationTransaction.makeAllPhases(ApplicationTransaction.java:445)
at com.sap.engine.services.deploy.server.application.ParallelAdapter.super_MakeAllPhases(ParallelAdapter.java:337)
at com.sap.engine.services.deploy.server.application.StartTransaction.makeAllPhasesImpl(StartTransaction.java:550)
at com.sap.engine.services.deploy.server.application.ParallelAdapter.runInTheSameThread(ParallelAdapter.java:251)
at com.sap.engine.services.deploy.server.application.ParallelAdapter.makeAllPhasesAndWait(ParallelAdapter.java:392)
at com.sap.engine.services.deploy.server.DeployServiceImpl.startApplicationAndWait(DeployServiceImpl.java:3389)
at com.sap.engine.services.deploy.server.DeployServiceImpl.startApplicationAndWait(DeployServiceImpl.java:3375)
at com.sap.engine.services.deploy.server.DeployServiceImpl.startApplicationAndWait(DeployServiceImpl.java:3278)
at com.sap.engine.services.deploy.server.DeployServiceImpl.startApplicationAndWait(DeployServiceImpl.java:3251)
at com.sap.engine.services.dc.lcm.impl.J2EELCMProcessor.doStart(J2EELCMProcessor.java:99)
at com.sap.engine.services.dc.lcm.impl.LifeCycleManagerImpl.start(LifeCycleManagerImpl.java:62)
at com.sap.engine.services.dc.cm.deploy.impl.LifeCycleManagerStartVisitor.visit(LifeCycleManagerStartVisitor.java:34)
at com.sap.engine.services.dc.cm.deploy.impl.DeploymentItemImpl.accept(DeploymentItemImpl.java:83)
at com.sap.engine.services.dc.cm.deploy.impl.DefaultDeployPostProcessor.postProcessLCMDeplItem(DefaultDeployPostProcessor.java:80)
at com.sap.engine.services.dc.cm.deploy.impl.DefaultDeployPostProcessor.postProcess(DefaultDeployPostProcessor.java:56)
at com.sap.engine.services.dc.cm.deploy.impl.DeployerImpl.doPostProcessing(DeployerImpl.java:741)
at com.sap.engine.services.dc.cm.deploy.impl.DeployerImpl.performDeploy(DeployerImpl.java:732)
at com.sap.engine.services.dc.cm.deploy.impl.DeployerImpl.doDeploy(DeployerImpl.java:576)
at com.sap.engine.services.dc.cm.deploy.impl.DeployerImpl.deploy(DeployerImpl.java:270)
at com.sap.engine.services.dc.cm.deploy.impl.DeployerImpl.deploy(DeployerImpl.java:192)
at com.sap.engine.services.dc.cm.deploy.impl.DeployerImplp4_Skel.dispatch(DeployerImplp4_Skel.java:875)
at com.sap.engine.services.rmi_p4.DispatchImpl._runInternal(DispatchImpl.java:351)
at com.sap.engine.services.rmi_p4.server.ServerDispatchImpl.run(ServerDispatchImpl.java:70)
at com.sap.engine.services.rmi_p4.P4Message.process(P4Message.java:62)
at com.sap.engine.services.rmi_p4.P4Message.execute(P4Message.java:37)
at com.sap.engine.services.cross.fca.FCAConnectorImpl.executeRequest(FCAConnectorImpl.java:877)
at com.sap.engine.services.rmi_p4.P4Message.process(P4Message.java:53)
at com.sap.engine.services.cross.fca.MessageReader.run(MessageReader.java:58)
at com.sap.engine.core.thread.execution.Executable.run(Executable.java:108)
at com.sap.engine.core.thread.execution.CentralExecutor$SingleThread.run(CentralExecutor.java:304)
at com.sap.engine.services.orpersistence.container.deploy.impl.ComplexModuleCreator.initDataSources(ComplexModuleCreator.java:360)
at com.sap.engine.services.orpersistence.container.deploy.impl.ComplexModuleCreator.initRuntimeModels(ComplexModuleCreator.java:230)
at com.sap.engine.services.orpersistence.container.deploy.impl.ComplexModuleCreator.createModule(ComplexModuleCreator.java:154)
at com.sap.engine.services.orpersistence.container.deploy.impl.ComplexModuleCreator.execute(ComplexModuleCreator.java:84)
at com.sap.engine.services.orpersistence.container.deploy.impl.ComplexActionAdapter.execute(ComplexActionAdapter.java:34)
at com.sap.engine.services.orpersistence.container.deploy.impl.ApplicationCreator.execute(ApplicationCreator.java:74)
at com.sap.engine.services.orpersistence.container.deploy.impl.PersistenceContainer.prepareStart(PersistenceContainer.java:187)
at com.sap.engine.services.deploy.server.application.StartTransaction.prepareCommon(StartTransaction.java:219)
at com.sap.engine.services.deploy.server.application.StartTransaction.prepare(StartTransaction.java:179)
at com.sap.engine.services.deploy.server.application.ApplicationTransaction.makeAllPhasesOnOneServer(ApplicationTransaction.java:420)
at com.sap.engine.services.deploy.server.application.ApplicationTransaction.makeAllPhases(ApplicationTransaction.java:445)
at com.sap.engine.services.deploy.server.application.ParallelAdapter.super_MakeAllPhases(ParallelAdapter.java:337)
at com.sap.engine.services.deploy.server.application.StartTransaction.makeAllPhasesImpl(StartTransaction.java:550)
at com.sap.engine.services.deploy.server.application.ParallelAdapter.runInTheSameThread(ParallelAdapter.java:251)
at com.sap.engine.services.deploy.server.application.ParallelAdapter.makeAllPhasesAndWait(ParallelAdapter.java:392)
at com.sap.engine.services.deploy.server.DeployServiceImpl.startApplicationAndWait(DeployServiceImpl.java:3389)
at com.sap.engine.services.deploy.server.DeployServiceImpl.startApplicationAndWait(DeployServiceImpl.java:3375)
at com.sap.engine.services.deploy.server.DeployServiceImpl.startApplicationAndWait(DeployServiceImpl.java:3278)
at com.sap.engine.services.deploy.server.DeployServiceImpl.startApplicationAndWait(DeployServiceImpl.java:3251)
at com.sap.engine.services.dc.lcm.impl.J2EELCMProcessor.doStart(J2EELCMProcessor.java:99)
at com.sap.engine.services.dc.lcm.impl.LifeCycleManagerImpl.start(LifeCycleManagerImpl.java:62)
at com.sap.engine.services.dc.cm.deploy.impl.LifeCycleManagerStartVisitor.visit(LifeCycleManagerStartVisitor.java:34)
at com.sap.engine.services.dc.cm.deploy.impl.DeploymentItemImpl.accept(DeploymentItemImpl.java:83)
at com.sap.engine.services.dc.cm.deploy.impl.DefaultDeployPostProcessor.postProcessLCMDeplItem(DefaultDeployPostProcessor.java:80)
at com.sap.engine.services.dc.cm.deploy.impl.DefaultDeployPostProcessor.postProcess(DefaultDeployPostProcessor.java:56)
at com.sap.engine.services.dc.cm.deploy.impl.DeployerImpl.doPostProcessing(DeployerImpl.java:741)
at com.sap.engine.services.dc.cm.deploy.impl.DeployerImpl.performDeploy(DeployerImpl.java:732)
at com.sap.engine.services.dc.cm.deploy.impl.DeployerImpl.doDeploy(DeployerImpl.java:576)
at com.sap.engine.services.dc.cm.deploy.impl.DeployerImpl.deploy(DeployerImpl.java:270)
at com.sap.engine.services.dc.cm.deploy.impl.DeployerImpl.deploy(DeployerImpl.java:192)
at com.sap.engine.services.dc.cm.deploy.impl.DeployerImplp4_Skel.dispatch(DeployerImplp4_Skel.java:875)
at com.sap.engine.services.rmi_p4.DispatchImpl._runInternal(DispatchImpl.java:351)
at com.sap.engine.services.rmi_p4.server.ServerDispatchImpl.run(ServerDispatchImpl.java:70)
at com.sap.engine.services.rmi_p4.P4Message.process(P4Message.java:62)
at com.sap.engine.services.rmi_p4.P4Message.execute(P4Message.java:37)
at com.sap.engine.services.cross.fca.FCAConnectorImpl.executeRequest(FCAConnectorImpl.java:877)
at com.sap.engine.services.rmi_p4.P4Message.process(P4Message.java:53)
at com.sap.engine.services.cross.fca.MessageReader.run(MessageReader.java:58)
at com.sap.engine.core.thread.execution.Executable.run(Executable.java:108)
at com.sap.engine.core.thread.execution.CentralExecutor$SingleThread.run(CentralExecutor.java:304)
Result
Status:WarningOK, you have properly declared the data source for your persistence unit in the persistence.xml. But you also have to maintain this data source (alias) on the server, i.e. it has to be created explicitly.
Check this [document|http://help.sap.com/saphelp_nwce711/helpdata/en/46/96ec3c33621e5ce10000000a1553f6/frameset.htm].
HTH!
-- Vladimir
PS: Please take your time to go through the [Rules of Engagement|https://wiki.sdn.sap.com/wiki/display/HOME/RulesofEngagement] and do not crosspost to multiple forums. -
How set timeout in a EJB remote lookup?
Hello,
how can I set the timeout of a remote lookup?
InitialContext ctx = new InitialContext();
EJB2Remote ejb2RemoteWithLookup = (EJB2Remote)ctx.lookup("java:comp/env/ejb/EJB2");
If EJB2 is a bean that reside on a remote server and that server isn't reachable, the lookup fails after about 30-40 seconds. It's possible to set the timeout to 5 seconds?
I use SJSAS 9.
Thank you,
LucaHi Luca,
We don't define a way to control this in the current implementation. There has been
an enhancement request filed for this issue. The overall usability when the server
is not available and a lookup is attempted needs to be improved. You can find additional
information here :
https://glassfish.dev.java.net/issues/show_bug.cgi?id=1026
--ken -
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,
RafaelHi,
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 -
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?
FrankWhat 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
Maybe you are looking for
-
Why am I suddenly unable to see pdf (on iMac) when I click on them ?There is is just a mid grey blank screen .I have sent pdf to my Blackb and I can read it there ,so the file is OK .I recently tried to down load a recent version of Adobe reader from
-
Corrupted time machine backup on external hd connected to Airport extreme?
I have an Airport extreme 11n (not gigabit) and a Lacie external hard disk connected to the usb port. Time machine is set up to make backups wirelessly from my laptop to this external disk. It used to work fine, but no I have the following problem al
-
Saving custom 'Dip to Color Dissolve'... how?
Hello all, I'm stumped here. It seems I can customize several dissolves and video transitions/filters, but can never get to save my 'Dip to Color Dissolve' to white (instead of the default black). Any ideas on how to accomplish this? Thanks in advanc
-
Adding Custom Property in Catalog
Hi all, trying to add a new property in the product and SKU level. I have added the below code in custom catalog.xml. And the below SQL script, i have got by invoking the following like in . In dyn/admin , atg/commerce/catalog/productcatalog , genera
-
Location reminders with siri in the UK
I have been trying to get location reminders to work via Siri. I have set up my home location via my contact information and via the map as the advice on this states but it is not workiing. I tried various things to get it to work but nothing worke