[EJB 3.0] - Stateful bean via RMI
by hipa
I can't get access to stateful bean, but can to stateless one. Why?
| package org.test.ejb;
|
| public interface StatelessRemote
| {
| public void test();
| }
|
| package org.test.ejb;
|
| public interface StatefulRemote
| {
| public void test();
| public void destroy();
| }
|
| package org.test.ejb;
|
| import javax.ejb.Stateless;
| import javax.ejb.Remote;
|
| import org.test.ejb.StatelessRemote;
|
| @Stateless
| @Remote(StatelessRemote.class)
| public class StatelessBean
| implements StatelessRemote
| {
| public void test()
| {
| System.out.println("test stateless");
| }
| }
|
| package org.test.ejb;
|
| import javax.ejb.Stateful;
| import javax.ejb.Remote;
| import javax.ejb.Remove;
|
| import org.test.ejb.StatefulRemote;
|
| @Stateful
| @Remote(StatefulRemote.class)
| public class StatefulBean
| implements StatefulRemote
| {
| public void test()
| {
| System.out.println("test stateful");
| }
|
| @Remove
| public void destroy()
| {
| System.out.println("Destroy");
| }
| }
|
Client code
| ...
| InitialContext context = new InitialContext(jndiProps);
| NamingEnumeration en = context.list("java:/ejb_test");
| while (en.hasMore())
| {
| System.out.println(en.next());
| }
|
| Object stateless = context.lookup("StatelessBean/remote");
| System.out.println("Bean received " + stateless);
|
| Object stateful = context.lookup("StatefulBean/remote"); // 109
| System.out.println("Bean received " + stateful);
| ...
|
Console:
| EjbSynchronizations: org.jnp.interfaces.NamingContext
| TimerServiceDispatcher: org.jnp.interfaces.NamingContext
| StatefulBean: org.jnp.interfaces.NamingContext
| StatelessBean: org.jnp.interfaces.NamingContext
| Bean received = jboss.j2ee:ear=ejb_test.ear,jar=ejb_test.jar,name=StatelessBean,service=EJB3
|
| javax.naming.NameNotFoundException: ejb_test not bound
| at org.jnp.server.NamingServer.getBinding(NamingServer.java:529)
| at org.jnp.server.NamingServer.getBinding(NamingServer.java:537)
| at org.jnp.server.NamingServer.getObject(NamingServer.java:543)
| at org.jnp.server.NamingServer.lookup(NamingServer.java:267)
| at org.jnp.server.NamingServer.lookup(NamingServer.java:270)
| at sun.reflect.GeneratedMethodAccessor91.invoke(Unknown Source)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| at java.lang.reflect.Method.invoke(Method.java:597)
| at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:305)
| at sun.rmi.transport.Transport$1.run(Transport.java:159)
| at java.security.AccessController.doPrivileged(Native Method)
| at sun.rmi.transport.Transport.serviceCall(Transport.java:155)
| at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:535)
| at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:790)
| at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:649)
| at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885)
| at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
| at java.lang.Thread.run(Thread.java:619)
| at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:255)
| at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:233)
| at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:142)
| at org.jnp.server.NamingServer_Stub.lookup(Unknown Source)
| at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:667)
| at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:627)
| at org.jboss.ejb3.JndiProxyFactory.getObjectInstance(JndiProxyFactory.java:52)
| at javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:304)
| at org.jnp.interfaces.NamingContext.getObjectInstance(NamingContext.java:1273)
| at org.jnp.interfaces.NamingContext.getObjectInstanceWrapFailure(NamingContext.java:1290)
| at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:763)
| at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:627)
| at javax.naming.InitialContext.lookup(InitialContext.java:392)
| at org.test.remote.Test.callEjb(Test.java:109)
| at org.test.remote.Test$3.run(Test.java:220)
| at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
| at java.awt.EventQueue.dispatchEvent(EventQueue.java:597)
| at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:273)
| at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:183)
| at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:173)
| at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:168)
| at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:160)
| at java.awt.EventDispatchThread.run(EventDispatchThread.java:121)
|
|
JMX console:
|
| | +- StatefulBean (class: org.jnp.interfaces.NamingContext)
| | | +- remote (class: java.lang.Object)
| | | +- remoteStatefulProxyFactory (proxy: $Proxy103 implements interface org.jboss.ejb3.ProxyFactory)
| | +- StatelessBean (class: org.jnp.interfaces.NamingContext)
| | | +- remote (proxy: $Proxy295 implements interface org.test.ejb.StatelessRemote,interface org.jboss.ejb3.JBossProxy)
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4108810#4108810
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4108810
18 years, 5 months
[JBossCache] - Re: ClusteredCacheLoader + LOCAL CacheMode
by lovelyliatroim
Ok seeking some clarity on why you would use a ClusteredCacheLoader in my case.
I have seen the thread http://www.jboss.org/index.html?module=bb&op=viewtopic&t=118598
but in terms of my needs ;).
Ok running my cache in invalidation mode is a no go for me, i dont want data evicted if i update a data item on one cache node. So i cant run in invalidation mode.
replication mode without buddy replication. Doesnt make sense to use it here because all the data is replicated across all the nodes.
replication with buddy replication: This is where i am not so clear, im not so clear on how buddy replication works, i have set it up but dont know the reasoning behind why it does what it does. Ok i would have thought that you would share data with your buddy and the data would be in the same tree, not in a seperate branch i.e under /_BUDDY_BACKUP_ 0 branch. Maybe im missing some configuration setting to merge the 2 buddies data into the same tree??
If i dont have buddy replication then all the replication goes into the same tree, thats how i would have thought buddy replication would work except that you are just sharing with you and your buddy has and not with the whole cluster.
Can someone just clear up why 2 different trees and not the same as in replication without buddy replication??
p.s i using jmx console to see whats in my cache
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4108808#4108808
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4108808
18 years, 5 months