(ejb 3.0) stateful session facade?

Hello,
(1) Would you consider stateful session facade (whose client is a servlet) a bad design?
(2) How to have a stateful session facade referenced in a servlet? I am using Sun Application Server Platform Edition 9.0 and trying to make an injection:
@EJB(name="ejb/KOGSessionFacade")
protected KOGSessionFacade sessionFacade;
but then I get this error in deploy-time: "A stateful session bean can not be injected into a servlet. Please refer to EJB 3.0 Persistence API Specification section #5.2 for further information."
Thanks.

Using a Stateful Session facade from a Servlet is not necessarily a bad design. In some cases, you may want to do some cleanup work on completion of a transaction. Stateful Session beans provide a convenient way (By implementing SessionSynchronization interface) to do this.
In the servlet programming model, Servlets are not designed to be single threaded. So if you inject a StatefulSessionBean (SFSB) references then multiple threads could be possibly be invoking the SFSB concurrently. In this case, the EJBContainer (as required by the specification), will throw a well defined exception.
What you may want to do is to place this SFSB reference into you Servlet session.

Similar Messages

How create EJB 2.1 Stateful Session Bean in a EJB 3.0 Session Bean

Hi All,
We have been developing on EJB 2.1. We are now adding a module on EJB 3.0.
How can we "create" a stateful session bean with create method signature similar to create(String id)?
We have tried
// this is the remote interface
@EJB AddressBean abean;
But not working
Any help will be appreciated.

There is no explicit create() call for EJB 3.0 session beans. It doesn't really matter though
since you can accomplish the same thing by defining your own business method to act
as an initializer for whatever state you'd like. E.g.
@Remote
public interface FooInterface {
public void initialize(String id);
// ... other business methods
@EJB FooInterface fooRef;
fooRef.initialize("foo");
--ken

JDev 1013 BUG? EJB, CMR, DTO and session facade.

I've created two CMP Entity EJB's, CourseEJB and PupilEJB, and defined a M:N relationship between them. A course has many pupils and vice versa. Each bean has only two attributes, id (Long, part of PK) and name (String) for simplicity.
1. Generated DTO's for the two beans won't compile
I get error on:
public void addcourseEJBLocalDTO(courseEJBLocalDTO courseEJBLocalDTO)
coursesDTO.add(courseEJBLocalDTO);
courseEJBLocalDTO.setPupilsDTO(this);
and:
public void addPupilEJBLocalDTO(PupilEJBLocalDTO pupilEJBLocalDTO)
pupilsDTO.add(pupilEJBLocalDTO);
pupilEJBLocalDTO.setCoursesDTO(this);
because JDev has created definitions of the setCoursesDTO function like this:
public void setCoursesDTO(Collection<courseEJBLocalDTO> coursesDTO)
this.coursesDTO = coursesDTO;
and ditto for the setPupilsDTO method, taking a Collection as argument too.
I can fix this code manually, but next step, generating a session Facade with added methods for handling the entity beans isn't exactly any better...
One M:N relation is pretty basic, am I doing something wrong here?
Message was edited by:
jonmarti

Forgot to add, running on 1013

EJB 3.0 Stateful session bean shared between Servlet's

Hello
I have a bit of a noob question regarding Stateful sessions beans.
I am wanting to know if there is a way that I can share an instance of a session bean between multiple HttpServlet instances?
I am sending XML messages from a mobile J2ME application, there will be several http POST's made from the mobile client to the server. I would like these multiple POST's to be passed from the handling servlet instance to the same uniquely identified single stateful session bean instance (i can then @Remove the stateful bean when I have finished my several requests).
I would greatly appreciate any tips anyone could give me.

If not, your only option is to maintain the
association yourself by creating a unique id for
each
conversation and storing that id along with the SFSB
reference in the ServletContext. Then you'll
need to pass the id in along with each invocation to
retrieve the appropriate SFSB reference.Thanks for your reply.
Will I always be presented with the same ServletContext instance? Even if the time between requests might be many minutes? Where can I learn more about how to use the ServletContext?
Thanks!

SAME EJB 3.0 Stateful Session bean for different JSP sessions returned

Forum,
I have a strange problem utilizing stateful session beans. Please note, that I am using jdeveloper for the following:
1) Here is a basic stateful session bean:
@Stateful(name = "DemoClass")
public class DemoClassBean implements DemoClass,
           DemoClassLocal, SessionSynchronization {
      public static int id=0;
      public DemoClassBean() {
      id++;
      public int getId() {
         return id;
      //... other methods
}2) This bean is accessed from a JSP for testing purpose, I am copying only the script used in JSP:
<%
   DemoClass bean = null;
   try {
      bean = (DemoClass) ((new javax.naming.InitialContext()).
                   lookup("DemoClass "));
      System.out.println("ID=" + bean.getId() );
      } catch (javax.naming.NamingException e) {
         // TODO
%>If this page is addressed by different clients, from different browsers, the same bean is returned.
Here is what I see in the logs:
ID=1
ID=1
ID=1
The same problem is being observed when this session bean is accessed from a JSF Backing bean.
What could be wrong? Is this a bug in oc4j / jdeveloper (version 10.1.3.3.0)?
Edited by: smw000000001 on Nov 17, 2008 10:52 AM

Hi,
The code for stateful is perfectly fine and working in a normal way. The way you are trying to implement the stateful session bean in your application is wrong.
think of binding the stateful session bean with HttpSession object.
So that you will get a unique stateful session bean object.

EJB 2.0 STATEFUL SESSION BEANS -- ejbPassivate or ejbActivate is not called

Hi,
am using Oracle Jdevloper 9i. When i use Stateful Session beans the ejbPassivate or ejbActivated methods are not being called. What is the reason?

Hi Arun,
The decision of when to passivate a stateful session bean is up to a particular vendor's implementation. Typically each vendor will have some configuration that controls this decision, but it's certainly common for passivation to not take place for a given workload. Your best bet is to look at the Oracle documentation to see how the container makes its passivation decision.
--ken

EJB 3.0 Stateful - Setting session timeout in configuration

Hello Everyone,
I am working with EJB v3.0 and Glassfish as the app server. In case of Stateful EJB, when we explicitely annotate a method with '@Remove', the bean instance is removed from the container when this method is invoked from the client. However, I just wanted to know if there is any way so that I can override the session timeout value (in configuration or via annotations) such that if no client calls this instance for some configured time, the bean is removed by the container automatically.
Regards,
San

Using a Stateful Session facade from a Servlet is not necessarily a bad design. In some cases, you may want to do some cleanup work on completion of a transaction. Stateful Session beans provide a convenient way (By implementing SessionSynchronization interface) to do this.
In the servlet programming model, Servlets are not designed to be single threaded. So if you inject a StatefulSessionBean (SFSB) references then multiple threads could be possibly be invoking the SFSB concurrently. In this case, the EJBContainer (as required by the specification), will throw a well defined exception.
What you may want to do is to place this SFSB reference into you Servlet session.

EJBs only for session facade?

Hi all,
With EJB 2.1 many were saying that it is good to place POJOs behind a session facade of ejbs for a distributed application.
This will allow a developer to test his business logic outside the container.
But with EJB 3.0, all ejbs are pojos, so can i use ejbs for all my business logic?
Is it advisable?
Will this have any performance problem?
Kindly suggest.

Hi,
Thanks for your reply.
I have a distributed application with numerous web clients as well as a few multithreaded application clients accessing the business logic layer.
Definitely there will be a huge load especially if the number of clients increase.
So there will be a lot of distributed transactions.
I have no doubt whether i should use ejbs or not.
I must because the business logic layer must support remote access.
Considering this scenario, should i use ejbs beyond the session facade layer?
I understand that by using ejbs only in the session facade layer is an adavantage as that will not tie my business logic to a framework.
But considering the scope of the application, kindly provide your suggestions.
Thanks in advance,
James.

Passivation of Connection Object in Stateful Session Bean

Hi all,
I am developing a Stateful session bean that has a Connection object as its instance variable. And this bean starts transaction that spans across multiple method calls and finally either commit or rollback.
BeanClass
UserTransaction utx;
Connection conn;
ejbCreate()
allocateconnection();
ejbRemove()
closeconnection();
ejbActivate()
allocateconnection();
ejbpassivate()
closeconnection();
StartTransaction()
utx = getusertransaction();
utx.begin();
Method1()
do something with database
Method2()
do something with database
CommitTransaction()
utx.commit();
For example, the typical usage of this bean would be:
bean.StartTransaction();
bean.Method1();
bean.Method2();
bean.CommitTransaction();
Here are my two questions:
1. General Question: In order for a Connection object to join a Transaction, Do I have to create the connection after the transaction has started?
2. If the answer to the above question is yes, then: I understand that when this bean get passivated, the UserTransaction instance object would be passivated. And since the connection object can't not be passivated, I have to recreate the connection object in ejbactivate() method, would newly created connection participate in the same Transaction that was being passivated and now activated?

>
Hi all,
I am developing a Stateful session bean that has a
Connection object as its instance variable. And this
bean starts transaction that spans across multiple
method calls and finally either commit or rollback.
BeanClass
UserTransaction utx;
Connection conn;
ejbCreate()
allocateconnection();
ejbRemove()
closeconnection();
ejbActivate()
allocateconnection();
ejbpassivate()
closeconnection();
StartTransaction()
utx = getusertransaction();
utx.begin();
Method1()
do something with database
Method2()
do something with database
CommitTransaction()
utx.commit();
For example, the typical usage of this bean would be:
bean.StartTransaction();
bean.Method1();
bean.Method2();
bean.CommitTransaction();
Here are my two questions:
1. General Question: In order for a Connection object
to join a Transaction, Do I have to create the
connection after the transaction has started?Strictly NO. In fact, the connection is obtained first and then can a transaction begin.
2. If the answer to the above question is yes, then: I
understand that when this bean get passivated, the
UserTransaction instance object would be passivated.
And since the connection object can't not be
passivated, I have to recreate the connection object
in ejbactivate() method, would newly created
connection participate in the same Transaction that
was being passivated and now activated?
The answer to first question being NO, your argument for question 2 does not hold true. According to the EJB specification, a stateful session bean can only be passivated between the transaction and not within a transaction. Your implementation for the stateful EJB is good to work.

Stateful session bean deploying

Hello,
          I try to deploy stateful SessionBean with WL 6.0.
          Content of my 'weblogic-ejb-jar.xml' file is:
          <?xml version="1.0"?>
          <!DOCTYPE weblogic-ejb-jar PUBLIC '-//BEA Systems, Inc.//DTD WebLogic 6.0.0
          EJB//EN' 'http://www.bea.com/servers/wls60/ejb20/dtd/weblogic-ejb-jar.dtd'>
          <weblogic-ejb-jar>
          <weblogic-enterprise-bean>
          <ejb-name>HashtableSessionBean</ejb-name>
          <stateful-session-descriptor>
          <stateful-session-clustering>
          <home-is-clusterable>true</home-is-clusterable>
          <replication-type>InMemory</replication-type>
          </stateful-session-clustering>
          </stateful-session-descriptor>
          <jndi-name>HashtableSessionBean</jndi-name>
          </weblogic-enterprise-bean>
          </weblogic-ejb-jar>
          But I still recive error like bellow:
          ####<2001-03-28 18:15:15 GMT+02:00> <Error> <J2EE> <clikra003> <myserver>
          <Application Manager Thread> <> <> <160002> <Error deploying EJB Component :
          HashtableSessionBean>
          weblogic.ejb20.EJBDeploymentException: Exception in EJB Deployment; nested
          exception is:
          javax.naming.NamingException [Root exception is java.rmi.MarshalException:
          failed to marshal public abstract void
          weblogic.jndi.internal.NamingNode.rebind(java.lang.String,java.lang.Object,j
          ava.util.Hashtable) throws
          javax.naming.NamingException,java.rmi.RemoteException; nested exception is:
           java.rmi.server.ExportException: Failed to invoke contructor for
          RuntimeDescriptor: class weblogic.rmi.internal.BasicRuntimeDescriptor;
          nested exception is:
           java.lang.reflect.InvocationTargetException]
          javax.naming.NamingException. Root exception is java.rmi.MarshalException:
          failed to marshal public abstract void
          weblogic.jndi.internal.NamingNode.rebind(java.lang.String,java.lang.Object,j
          ava.util.Hashtable) throws
          javax.naming.NamingException,java.rmi.RemoteException; nested exception is:
          java.rmi.server.ExportException: Failed to invoke contructor for
          RuntimeDescriptor: class weblogic.rmi.internal.BasicRuntimeDescriptor;
          nested exception is:
          java.lang.reflect.InvocationTargetException
          java.rmi.server.ExportException: Failed to invoke contructor for
          RuntimeDescriptor: class weblogic.rmi.internal.BasicRuntimeDescriptor;
          nested exception is:
          java.lang.reflect.InvocationTargetException
          java.lang.reflect.InvocationTargetException: java.lang.NoClassDefFoundError:
          weblogic/common/managedobject/JavaRemoteManageable
          at java.lang.ClassLoader.defineClass0(Native Method)
          at java.lang.ClassLoader.defineClass(ClassLoader.java:486)
          at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:111)
          at
          weblogic.utils.classloaders.GenericClassLoader.findLocalClass(GenericClassLo
          ader.java:304)
          at
          weblogic.utils.classloaders.GenericClassLoader.findClass(GenericClassLoader.
          java:155)
          at java.lang.ClassLoader.loadClass(ClassLoader.java:297)
          at java.lang.ClassLoader.loadClass(ClassLoader.java:253)
          at weblogic.rmi.utils.Utilities.classForName(Utilities.java:209)
          at weblogic.rmi.internal.BasicDescriptor.<init>(BasicDescriptor.java:88)
          at weblogic.rmi.internal.BasicDescriptor.<init>(BasicDescriptor.java:141)
          at
          weblogic.rmi.internal.BasicRuntimeDescriptor.<init>(BasicRuntimeDescriptor.j
          ava:59)
          at java.lang.reflect.Constructor.newInstance(Native Method)
          at
          weblogic.rmi.internal.DescriptorManager.resolveClass(DescriptorManager.java:
          81)
          at
          weblogic.rmi.internal.DescriptorManager.getDescriptor(DescriptorManager.java
          :39)
          at
          weblogic.rmi.internal.DescriptorManager.getDescriptor(DescriptorManager.java
          :30)
          at
          weblogic.rmi.internal.OIDManager.getRequestDispatcher(OIDManager.java:279)
          at weblogic.rmi.internal.OIDManager.getReplacement(OIDManager.java:268)
          at weblogic.rmi.internal.OIDManager.replaceObject(OIDManager.java:96)
          at
          weblogic.common.internal.WLObjectOutputStreamBase2.replaceObject(WLObjectOut
          putStreamBase2.java:47)
          at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:323)
          at
          weblogic.rmi.internal.CBVOutputStream.writeObjectInternal(CBVOutputStream.ja
          va:220)
          at
          weblogic.rmi.internal.CBVOutputStream.writeObject(CBVOutputStream.java:213)
          at
          weblogic.rmi.internal.CBVOutputStream.writeObject(CBVOutputStream.java:190)
          at weblogic.rmi.internal.ObjectIO.writeObject(ObjectIO.java:19)
          at
          weblogic.rmi.internal.BasicRemoteRef.marshalArgs(BasicRemoteRef.java:121)
          at
          weblogic.rmi.cluster.ReplicaAwareRemoteRef.invoke(ReplicaAwareRemoteRef.java
          :246)
          at
          weblogic.rmi.cluster.ReplicaAwareRemoteRef.invoke(ReplicaAwareRemoteRef.java
          :225)
          at
          weblogic.jndi.internal.ServerNamingNode_WLStub.rebind(ServerNamingNode_WLStu
          b.java:502)
          at weblogic.jndi.internal.WLContextImpl.rebind(WLContextImpl.java:123)
          at weblogic.jndi.internal.WLContextImpl.rebind(WLContextImpl.java:117)
          at
          weblogic.ejb20.deployer.ClientDrivenBeanInfoImpl.deploy(ClientDrivenBeanInfo
          Impl.java:483)
          at weblogic.ejb20.deployer.Deployer.deployDescriptor(Deployer.java:1105)
          at weblogic.ejb20.deployer.Deployer.deploy(Deployer.java:908)
          at weblogic.j2ee.EJBComponent.deploy(EJBComponent.java:31)
          at weblogic.j2ee.Application.addComponent(Application.java:126)
          at weblogic.j2ee.J2EEService.addDeployment(J2EEService.java:115)
          at
          weblogic.management.mbeans.custom.DeploymentTarget.addDeployment(DeploymentT
          arget.java:283)
          at
          weblogic.management.mbeans.custom.DeploymentTarget.addDeployment(DeploymentT
          arget.java:109)
          at java.lang.reflect.Method.invoke(Native Method)
          at
          weblogic.management.internal.DynamicMBeanImpl.invokeLocally(DynamicMBeanImpl
          .java:562)
          at
          weblogic.management.internal.DynamicMBeanImpl.invoke(DynamicMBeanImpl.java:5
          48)
          at
          weblogic.management.internal.ConfigurationMBeanImpl.invoke(ConfigurationMBea
          nImpl.java:285)
          at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1555)
          at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523)
          at
          weblogic.management.internal.ConfigurationMBeanImpl.updateConfigMBeans(Confi
          gurationMBeanImpl.java:409)
          at
          weblogic.management.internal.ConfigurationMBeanImpl.invoke(ConfigurationMBea
          nImpl.java:287)
          at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1555)
          at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523)
          at
          weblogic.management.internal.DynamicMBeanImpl.addDeployment(DynamicMBeanImpl
          .java:866)
          at
          weblogic.management.internal.DynamicMBeanImpl.addDeployment(DynamicMBeanImpl
          .java:853)
          at
          weblogic.management.internal.DynamicMBeanImpl.add(DynamicMBeanImpl.java:838)
          at
          weblogic.management.internal.DynamicMBeanImpl.invokeLocally(DynamicMBeanImpl
          .java:566)
          at
          weblogic.management.internal.DynamicMBeanImpl.invoke(DynamicMBeanImpl.java:5
          48)
          at
          weblogic.management.internal.ConfigurationMBeanImpl.invoke(ConfigurationMBea
          nImpl.java:285)
          at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1555)
          at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523)
          at weblogic.management.internal.MBeanProxy.invoke(MBeanProxy.java:437)
          at weblogic.management.internal.MBeanProxy.invoke(MBeanProxy.java:178)
          at $Proxy8.addTarget(Unknown Source)
          at
          weblogic.management.mbeans.custom.ApplicationManager.autoDeploy(ApplicationM
          anager.java:486)
          at
          weblogic.management.mbeans.custom.ApplicationManager.addApplication(Applicat
          ionManager.java:557)
          at
          weblogic.management.mbeans.custom.ApplicationManager.addApplication(Applicat
          ionManager.java:504)
          at
          weblogic.management.mbeans.custom.ApplicationManager.poll(ApplicationManager
          .java:428)
          at
          weblogic.management.mbeans.custom.ApplicationManager.poll(ApplicationManager
          .java:380)
          at
          weblogic.management.mbeans.custom.ApplicationManager.update(ApplicationManag
          er.java:152)
          at
          weblogic.management.mbeans.custom.ApplicationManager$ApplicationPoller.run(A
          pplicationManager.java:643)
          ####<2001-03-28 18:15:15 GMT+02:00> <Error> <J2EE> <clikra003> <myserver>
          <Application Manager Thread> <> <> <160001> <Error deploying application
          HashtableSessionBean: Could not deploy: 'HashtableSessionBean.jar'
          Possible reasons include:
          1. The bean or an interface class has been modified but
          the deployment descriptor has not been updated
          2. The database mappings in the deployment descriptor do not
          match the database definition
          3. The jar file is not a valid jar file
          4. The jar file does not contain a valid bean>
          Robert


Hello,
          <stateful-session-clustering>
          <replication-type>InMemory</replication-type>
          </stateful-session-clustering>
          Statement above belongs to 'weblogic-ejb-jar.xml' and it is right in my
          opinion.
          I have another one statement describing SessionBean which deploy it as
          stateful bean (it is 'ejb-jar.xml' file):
          <?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>
          <enterprise-beans>
          <session>
          <ejb-name>HashtableSessionBean</ejb-name>
          <home>com.usermgmt.sessionbeans.hashtable.HashtableSessionHome</home>
          <remote>com.usermgmt.sessionbeans.hashtable.HashtableSession</remote>
          <ejb-class>com.usermgmt.sessionbeans.hashtable.HashtableSessionBean</ejb-cla
          ss>
          <session-type>Stateful</session-type>
          <transaction-type>Container</transaction-type>
          </session>
          </enterprise-beans>
          <assembly-descriptor></assembly-descriptor>
          </ejb-jar>
          I think that everything should go right, but SessionBean is not replicated.
          Where is the problem?
          Robert
          Uzytkownik "Prasad Peddada" <[email protected]> napisal w wiadomosci
          news:[email protected]...
          > Its not stateful session descriptor from your xml file instead it is
          > stateful-session-clustering according to the docs.
          >
          > -- Prasad
          >
          > ps: For ejb questions you will get better answers if you post to ejb
          newsgroup.
          >
          >
          > <stateful-session-clustering>
          >
          >
          > ...
          >
          >
          > <replication-type>InMemory</replication-type>
          >
          >
          > </stateful-session-clustering>
          >
          >
          > Robert Zaczynski wrote:
          >
          > > Thanks for help. I resolved this problem but my Stateful SessionBean
          doesn't
          > > replicate.
          > > Have I to use any special statement or settings???
          > >
          > > Robert
          > >
          > > Uzytkownik "Prasad Peddada" <[email protected]> napisal w
          wiadomosci
          > > news:[email protected]...
          > > > Did you modify the weblogic specific deployment descriptor xml file
          after
          > > > running ejbc. If so, you should run ejbc again and then jar it up
          again
          > > and
          > > > trying deploying and your problem should go away.
          > > >
          > > >
          > > > Cheers
          > > >
          > > > -- Prasad
          > > >
          > > > "Robert Zaczyñski" wrote:
          > > >
          > > > > Hello,
          > > > >
          > > > > I try to deploy stateful SessionBean with WL 6.0.
          > > > >
          > > > > Content of my 'weblogic-ejb-jar.xml' file is:
          > > > >
          > > > > <?xml version="1.0"?>
          > > > >
          > > > > <!DOCTYPE weblogic-ejb-jar PUBLIC '-//BEA Systems, Inc.//DTD
          WebLogic
          > > 6.0.0
          > > > > EJB//EN'
          > > 'http://www.bea.com/servers/wls60/ejb20/dtd/weblogic-ejb-jar.dtd'>
          > > > > <weblogic-ejb-jar>
          > > > > <weblogic-enterprise-bean>
          > > > > <ejb-name>HashtableSessionBean</ejb-name>
          > > > >
          > > > > <stateful-session-descriptor>
          > > > > <stateful-session-clustering>
          > > > > <home-is-clusterable>true</home-is-clusterable>
          > > > > <replication-type>InMemory</replication-type>
          > > > > </stateful-session-clustering>
          > > > > </stateful-session-descriptor>
          > > > >
          > > > > <jndi-name>HashtableSessionBean</jndi-name>
          > > > >
          > > > > </weblogic-enterprise-bean>
          > > > > </weblogic-ejb-jar>
          > > > >
          > > > > But I still recive error like bellow:
          > > > >
          > > > > ####<2001-03-28 18:15:15 GMT+02:00> <Error> <J2EE> <clikra003>
          > > <myserver>
          > > > > <Application Manager Thread> <> <> <160002> <Error deploying EJB
          > > Component :
          > > > > HashtableSessionBean>
          > > > > weblogic.ejb20.EJBDeploymentException: Exception in EJB Deployment;
          > > nested
          > > > > exception is:
          > > > > javax.naming.NamingException [Root exception is
          > > java.rmi.MarshalException:
          > > > > failed to marshal public abstract void
          > > > >
          > >
          weblogic.jndi.internal.NamingNode.rebind(java.lang.String,java.lang.Object,j
          > > > > ava.util.Hashtable) throws
          > > > > javax.naming.NamingException,java.rmi.RemoteException; nested
          exception
          > > is:
          > > > > java.rmi.server.ExportException: Failed to invoke contructor for
          > > > > RuntimeDescriptor: class
          weblogic.rmi.internal.BasicRuntimeDescriptor;
          > > > > nested exception is:
          > > > > java.lang.reflect.InvocationTargetException]
          > > > > javax.naming.NamingException. Root exception is
          > > java.rmi.MarshalException:
          > > > > failed to marshal public abstract void
          > > > >
          > >
          weblogic.jndi.internal.NamingNode.rebind(java.lang.String,java.lang.Object,j
          > > > > ava.util.Hashtable) throws
          > > > > javax.naming.NamingException,java.rmi.RemoteException; nested
          exception
          > > is:
          > > > > java.rmi.server.ExportException: Failed to invoke contructor for
          > > > > RuntimeDescriptor: class
          weblogic.rmi.internal.BasicRuntimeDescriptor;
          > > > > nested exception is:
          > > > > java.lang.reflect.InvocationTargetException
          > > > > java.rmi.server.ExportException: Failed to invoke contructor for
          > > > > RuntimeDescriptor: class
          weblogic.rmi.internal.BasicRuntimeDescriptor;
          > > > > nested exception is:
          > > > > java.lang.reflect.InvocationTargetException
          > > > > java.lang.reflect.InvocationTargetException:
          > > java.lang.NoClassDefFoundError:
          > > > > weblogic/common/managedobject/JavaRemoteManageable
          > > > > at java.lang.ClassLoader.defineClass0(Native Method)
          > > > > at java.lang.ClassLoader.defineClass(ClassLoader.java:486)
          > > > > at
          > > java.security.SecureClassLoader.defineClass(SecureClassLoader.java:111)
          > > > > at
          > > > >
          > >
          weblogic.utils.classloaders.GenericClassLoader.findLocalClass(GenericClassLo
          > > > > ader.java:304)
          > > > > at
          > > > >
          > >
          weblogic.utils.classloaders.GenericClassLoader.findClass(GenericClassLoader.
          > > > > java:155)
          > > > > at java.lang.ClassLoader.loadClass(ClassLoader.java:297)
          > > > > at java.lang.ClassLoader.loadClass(ClassLoader.java:253)
          > > > > at weblogic.rmi.utils.Utilities.classForName(Utilities.java:209)
          > > > > at
          > > weblogic.rmi.internal.BasicDescriptor.<init>(BasicDescriptor.java:88)
          > > > > at
          > > weblogic.rmi.internal.BasicDescriptor.<init>(BasicDescriptor.java:141)
          > > > > at
          > > > >
          > >
          weblogic.rmi.internal.BasicRuntimeDescriptor.<init>(BasicRuntimeDescriptor.j
          > > > > ava:59)
          > > > > at java.lang.reflect.Constructor.newInstance(Native Method)
          > > > > at
          > > > >
          > >
          weblogic.rmi.internal.DescriptorManager.resolveClass(DescriptorManager.java:
          > > > > 81)
          > > > > at
          > > > >
          > >
          weblogic.rmi.internal.DescriptorManager.getDescriptor(DescriptorManager.java
          > > > > :39)
          > > > > at
          > > > >
          > >
          weblogic.rmi.internal.DescriptorManager.getDescriptor(DescriptorManager.java
          > > > > :30)
          > > > > at
          > > > >
          > >
          weblogic.rmi.internal.OIDManager.getRequestDispatcher(OIDManager.java:279)
          > > > > at
          weblogic.rmi.internal.OIDManager.getReplacement(OIDManager.java:268)
          > > > > at
          weblogic.rmi.internal.OIDManager.replaceObject(OIDManager.java:96)
          > > > > at
          > > > >
          > >
          weblogic.common.internal.WLObjectOutputStreamBase2.replaceObject(WLObjectOut
          > > > > putStreamBase2.java:47)
          > > > > at
          java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:323)
          > > > > at
          > > > >
          > >
          weblogic.rmi.internal.CBVOutputStream.writeObjectInternal(CBVOutputStream.ja
          > > > > va:220)
          > > > > at
          > > > >
          > >
          weblogic.rmi.internal.CBVOutputStream.writeObject(CBVOutputStream.java:213)
          > > > > at
          > > > >
          > >
          weblogic.rmi.internal.CBVOutputStream.writeObject(CBVOutputStream.java:190)
          > > > > at weblogic.rmi.internal.ObjectIO.writeObject(ObjectIO.java:19)
          > > > > at
          > > > >
          > >
          weblogic.rmi.internal.BasicRemoteRef.marshalArgs(BasicRemoteRef.java:121)
          > > > > at
          > > > >
          > >
          weblogic.rmi.cluster.ReplicaAwareRemoteRef.invoke(ReplicaAwareRemoteRef.java
          > > > > :246)
          > > > > at
          > > > >
          > >
          weblogic.rmi.cluster.ReplicaAwareRemoteRef.invoke(ReplicaAwareRemoteRef.java
          > > > > :225)
          > > > > at
          > > > >
          > >
          weblogic.jndi.internal.ServerNamingNode_WLStub.rebind(ServerNamingNode_WLStu
          > > > > b.java:502)
          > > > > at
          weblogic.jndi.internal.WLContextImpl.rebind(WLContextImpl.java:123)
          > > > > at
          weblogic.jndi.internal.WLContextImpl.rebind(WLContextImpl.java:117)
          > > > > at
          > > > >
          > >
          weblogic.ejb20.deployer.ClientDrivenBeanInfoImpl.deploy(ClientDrivenBeanInfo
          > > > > Impl.java:483)
          > > > > at
          > > weblogic.ejb20.deployer.Deployer.deployDescriptor(Deployer.java:1105)
          > > > > at weblogic.ejb20.deployer.Deployer.deploy(Deployer.java:908)
          > > > > at weblogic.j2ee.EJBComponent.deploy(EJBComponent.java:31)
          > > > > at weblogic.j2ee.Application.addComponent(Application.java:126)
          > > > > at weblogic.j2ee.J2EEService.addDeployment(J2EEService.java:115)
          > > > > at
          > > > >
          > >
          weblogic.management.mbeans.custom.DeploymentTarget.addDeployment(DeploymentT
          > > > > arget.java:283)
          > > > > at
          > > > >
          > >
          weblogic.management.mbeans.custom.DeploymentTarget.addDeployment(DeploymentT
          > > > > arget.java:109)
          > > > > at java.lang.reflect.Method.invoke(Native Method)
          > > > > at
          > > > >
          > >
          weblogic.management.internal.DynamicMBeanImpl.invokeLocally(DynamicMBeanImpl
          > > > > .java:562)
          > > > > at
          > > > >
          > >
          weblogic.management.internal.DynamicMBeanImpl.invoke(DynamicMBeanImpl.java:5
          > > > > 48)
          > > > > at
          > > > >
          > >
          weblogic.management.internal.ConfigurationMBeanImpl.invoke(ConfigurationMBea
          > > > > nImpl.java:285)
          > > > > at
          > > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1555)
          > > > > at
          > > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523)
          > > > > at
          > > > >
          > >
          weblogic.management.internal.ConfigurationMBeanImpl.updateConfigMBeans(Confi
          > > > > gurationMBeanImpl.java:409)
          > > > > at
          > > > >
          > >
          weblogic.management.internal.ConfigurationMBeanImpl.invoke(ConfigurationMBea
          > > > > nImpl.java:287)
          > > > > at
          > > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1555)
          > > > > at
          > > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523)
          > > > > at
          > > > >
          > >
          weblogic.management.internal.DynamicMBeanImpl.addDeployment(DynamicMBeanImpl
          > > > > .java:866)
          > > > > at
          > > > >
          > >
          weblogic.management.internal.DynamicMBeanImpl.addDeployment(DynamicMBeanImpl
          > > > > .java:853)
          > > > > at
          > > > >
          > >
          weblogic.management.internal.DynamicMBeanImpl.add(DynamicMBeanImpl.java:838)
          > > > > at
          > > > >
          > >
          weblogic.management.internal.DynamicMBeanImpl.invokeLocally(DynamicMBeanImpl
          > > > > .java:566)
          > > > > at
          > > > >
          > >
          weblogic.management.internal.DynamicMBeanImpl.invoke(DynamicMBeanImpl.java:5
          > > > > 48)
          > > > > at
          > > > >
          > >
          weblogic.management.internal.ConfigurationMBeanImpl.invoke(ConfigurationMBea
          > > > > nImpl.java:285)
          > > > > at
          > > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1555)
          > > > > at
          com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1
          > > 523)
          > > > > at
          weblogic.management.internal.MBeanProxy.invoke(MBeanProxy.java:437)
          > > > > at
          weblogic.management.internal.MBeanProxy.invoke(MBeanProxy.java:178)
          > > > > at $Proxy8.addTarget(Unknown Source)
          > > > > at
          > > > >
          > >
          weblogic.management.mbeans.custom.ApplicationManager.autoDeploy(ApplicationM
          > > > > anager.java:486)
          > > > > at
          > > > >
          > >
          weblogic.management.mbeans.custom.ApplicationManager.addApplication(Applicat
          > > > > ionManager.java:557)
          > > > > at
          > > > >
          > >
          weblogic.management.mbeans.custom.ApplicationManager.addApplication(Applicat
          > > > > ionManager.java:504)
          > > > > at
          > > > >
          > >
          weblogic.management.mbeans.custom.ApplicationManager.poll(ApplicationManager
          > > > > .java:428)
          > > > > at
          > > > >
          > >
          weblogic.management.mbeans.custom.ApplicationManager.poll(ApplicationManager
          > > > > .java:380)
          > > > > at
          > > > >
          > >
          weblogic.management.mbeans.custom.ApplicationManager.update(ApplicationManag
          > > > > er.java:152)
          > > > > at
          > > > >
          > >
          weblogic.management.mbeans.custom.ApplicationManager$ApplicationPoller.run(A
          > > > > pplicationManager.java:643)
          > > > > ####<2001-03-28 18:15:15 GMT+02:00> <Error> <J2EE> <clikra003>
          > > <myserver>
          > > > > <Application Manager Thread> <> <> <160001> <Error deploying
          application
          > > > > HashtableSessionBean: Could not deploy: 'HashtableSessionBean.jar'
          > > > > Possible reasons include:
          > > > > 1. The bean or an interface class has been modified but
          > > > > the deployment descriptor has not been updated
          > > > > 2. The database mappings in the deployment descriptor do not
          > > > > match the database definition
          > > > > 3. The jar file is not a valid jar file
          > > > > 4. The jar file does not contain a valid bean>
          > > > >
          > > > > Robert
          > > >
          > > > --
          > > > Cheers
          > > >
          > > > - Prasad
          > > >
          > > >
          >
          > --
          > Cheers
          >
          > - Prasad
          >
          >

Stop passivation in stateful session bean

hi
How to stop the passivation in stateful session bean
Regards
Gajendran.G

>
Hi all,
I am developing a Stateful session bean that has a
Connection object as its instance variable. And this
bean starts transaction that spans across multiple
method calls and finally either commit or rollback.
BeanClass
UserTransaction utx;
Connection conn;
ejbCreate()
allocateconnection();
ejbRemove()
closeconnection();
ejbActivate()
allocateconnection();
ejbpassivate()
closeconnection();
StartTransaction()
utx = getusertransaction();
utx.begin();
Method1()
do something with database
Method2()
do something with database
CommitTransaction()
utx.commit();
For example, the typical usage of this bean would be:
bean.StartTransaction();
bean.Method1();
bean.Method2();
bean.CommitTransaction();
Here are my two questions:
1. General Question: In order for a Connection object
to join a Transaction, Do I have to create the
connection after the transaction has started?Strictly NO. In fact, the connection is obtained first and then can a transaction begin.
2. If the answer to the above question is yes, then: I
understand that when this bean get passivated, the
UserTransaction instance object would be passivated.
And since the connection object can't not be
passivated, I have to recreate the connection object
in ejbactivate() method, would newly created
connection participate in the same Transaction that
was being passivated and now activated?
The answer to first question being NO, your argument for question 2 does not hold true. According to the EJB specification, a stateful session bean can only be passivated between the transaction and not within a transaction. Your implementation for the stateful EJB is good to work.

OC4J, Stateful Session EJB, & Session Timeout

In my J2EE applications, I have a user authentication layer whereby when the user is authenticated against our LDAP repository after logging in, a Stateful Session EJB keeps that conversational state with the client at all times until the user logs out whereby the session is invalidated. This way I keep track of the user's authentication at all times throughout the whole session and for every operation performed (JSPs etc) by the user during the session. All this works fine through my implementation of the Session Facade and Business Delegate patterns.
However, if OC4J times out the Session (set to one hour in the <session-config> <session-timeout> parameter of the web.xml), the user cannot re-login and proceed. The user has to close the whole browser and re-start a new browser, then login and proceed.
This is causing us a few problems with the users who are complaining about having to do so. Is there an easy way around this problem?
Regards
Daniel

Can you try in a different browser and see whether you can duplicate this ?
Is this a problem with browser - cache ?
regards
debu

Session ejb 3.0 stateful and same instance

Hello,
I'm using OC4J 10.1.3.3 and EJB 3.0/JSP
In a jsp I do two different lookup for a STATEFUL
session ejb 3.0, and I want two different instances
of the ejb, instead I get the same one...
Please help. Thanks.

Hi,
The code for stateful is perfectly fine and working in a normal way. The way you are trying to implement the stateful session bean in your application is wrong.
think of binding the stateful session bean with HttpSession object.
So that you will get a unique stateful session bean object.

Creating multiple stateful session beans from a java client. (EJB 3.0)

I'm having difficulties with the following:
To access the ShoppingCartBean, I have to put the following annotation in my standalone java client:
@EJB
private static ShoppingCartRemote shoppingCartBean;
The static must be there, thus only one ShoppingCartBean will exist within my java client. But as the ShoppingCartBean is a stateful session bean, I want to be able to get different beans of the same type.
What is the correct way to do this in EJB 3.0?

Great question. Because Home interfaces have been removed for the EJB 3.0 simplified
API, stateful session bean creation happens as a side-effect of injection. However, the
same is true of EJB 3.0 business interface lookups. The easiest way to create additional
stateful session beans is to lookup the same dependency that was declared via your
@EJB annotation.
E.g.,
// Assuming the declaring class is pkg1.ShoppingCartClient.java
InitialContext ic = new InitialContext();
ShoppingCartRemote scr1 = (ShoppingCartRemote)
ic.lookup("java:comp/env/pkg1.ShoppingCartClient/shoppingCartBean");
Note that the name relative to java:comp/env is the default associated with your
@EJB annotation since the name() attribute wasn't used. Alternatively, you
could have used :
@EJB(name="scb") private static ShoppingCartRemote shoppingCartBean;
InitialContext ic = new InitialContext();
ShoppingCartRemote scr1 = (ShoppingCartRemote) ic.lookup("java:comp/env/scb");
Yet another alternative is to declare the @EJB at the class-level. This just defines
the dependency without any injection, which is fine if you want to create a bunch of
them via lookup anyway.
@EJB(name="scb", beanInterface=ShoppingCartRemote.class)
public class .... {

Stateful Session Bean Initialization (EJB 3.0)

Hi all!
In EJB 2.1 the initialization was with create (args) methods. NOw, how is it exploited? Create methods are no more there and there must be a way to send parameters to the stateful session bean when it is newly created...isn't it?
Thank you!

There is no pre-defined equivalent of a create method in EJB 3.0. If you want to initialize a
stateful session bean, just define a business method that the client should use as an initialization
method.

(ejb 3.0) stateful session facade?

Similar Messages

Maybe you are looking for