Local Stateful Session Bean State Failover Cluster
Hi,
How are you doing? I have poured through the previous postings and still am unclear
on the following: If we have a stateful session bean that is local is the state
replicated in a cluster if we are using in-memory replication?
What controls when the state is replicated? Transactions?
What happens if the methods are not transacted? Is the state replication at the
method level?
Thank you so much,
-Bart Simpson
Hi Bart,
I'm a bit unclear on it too. It's been asked before, but no definite answer
has been provided.
Peace,
Cameron Purdy
Tangosol, Inc.
http://www.tangosol.com/coherence.jsp
Tangosol Coherence: Clustered Replicated Cache for Weblogic
"Bart Simpson" <[email protected]> wrote in message
news:[email protected]..
>
> Hi,
>
> How are you doing? I have poured through the previous postings and still
am unclear
> on the following: If we have a stateful session bean that is local is the
state
> replicated in a cluster if we are using in-memory replication?
>
> What controls when the state is replicated? Transactions?
>
> What happens if the methods are not transacted? Is the state replication
at the
> method level?
>
> Thank you so much,
> -Bart Simpson
Similar Messages
-
Plz help!! idempotent methods stateful session beans? (failover)
plz help!! idempotent methods stateful session beans? (failover)
Hi there,
Im trying to failover my shopping cart implemented using stateful ejb, the replication
is working but the failover is not (Object not found exception....).
By design is hard to think on an stateful ejb using idempotent methods, but after
checking the documentation in detail im completely confused, so im starting to
wonder if i should use idempotent methods or manual retry in case one server is
down.
Plz take a loo at these explanations about faiolver in the WLS edocs.
"....With clustered objects, automatic failover generally occurs only in cases
where the object is idempotent.....Because of this, replica-aware stubs will not,
by default, attempt to retry a method that fails after the request is sent but
before it returns. This behavior can be overridden by marking a service idempotent..."
BUT
"By default, a stateful session bean's Home stub provides load balancing and failover
for its method invocations to any clustered server where the bean is deployed...."
So is possible to achieve automatic failover (not only load balancing) for stateful
ejb without having to worry about state-changes or manual retry. (i know the retry
is requiered if the server crashed just before finishing a transaction but this
is not what im talking about).
Any help will be highly appreciated
Alan
Ryan,
Yes, im deploying using In-memory replication and clusterable elements, when try
to invoke the method (after one of the nodes is down) i recieve an "java.rmi.NoSuchObjectException:
Bean has been deleted".
I believe all this could be related to some sort of issue with JNDI Lookup in
the cluster, but haavent been able to get a clue to make it work....(almost desesperate
by now)
Alan
"ryan upton" <[email protected]> wrote:
>Alan,
>
>If the state isn't maintained during failover I would suspect a
>configuration error. Have you set the <replication-type> element within
><stateful-session-clustering> tag in the bean's deployment descriptor?
>
>"Alan" <[email protected]> wrote in message
>news:40e17cf7$1@mktnews1...
>>
>> Ryan,
>>
>>
>> Maybe i didnt explain myself, in the scenario im dealing with I KNOW
>the
>method
>> finished succesfully (example, the user succesfully added an item to
>a
>cart).
>>
>>
>> Just after that one of the nodes goes down, and the user decides to
>add a
>new
>> item (new invocation , not a retry of failed one) on the same session.
>>
>> This is the case in which failover should work automatically as you
>say,
>meaning
>> the new method invokation should be able to retrieve the session state
>info from
>> the replica and switch the primary.....Well, this is the part wich
>isnt
>working
>> :( as i understand it should transparently
>>
>> I believe could be a config issue , but have no way to make it work.
>>
>> Regards,
>>
>> Alan
>> "ryan upton" <[email protected]> wrote:
>> >
>> >"Alan" <[email protected]> wrote in message
>news:40e06296@mktnews1...
>> >>
>> >> Ryan,
>> >>
>> >> Thanks for clearing the both conditions a bit more, in this case
>my
>> >issue
>> >has
>> >> to do with the scenario #1 in which subsequent calls (invocations)
>> >go to a
>> >node
>> >> which isnt avaliable(down), do you have any idea of in what conditions
>> >the
>> >"automnatic"
>> >> failover would fail??? (meaning why the stub would try to dispatch
>> >a call
>> >to the
>> >> same previous node)
>> >>
>> >> Thanks for the help again
>> >>
>> >
>> >Subsequent calls won't go to a node that's down. That's the whole
>> >point
>> >;-). Failover is always automatic, what you are getting confused
>on
>> >is
>> >automatic method re-execution upon failover which happens if the method
>> >has
>> >been marked as idempotent. The logic is this: if I failover to an
>EJB
>> >that
>> >I know is still alive, I can't safely call the same method again.
> Why?
>> >Because I don't know how much of the method completed the last time
>before
>> >the previous bean's failure. So if the bean can yield multiple results
>> >from
>> >multiple invocations I had better play it safe and not re-execute
>the
>> >method
>> >on the bean I failed over to (unless it's idempotent because in that
>> >case it
>> >doesn't matter how many times I call it, it always does the same thing).
>> > In
>> >scenario #1 and #2 failover is automatic and all new calls are executed
>> >against the bean the client failed over to, but only idempotent methods
>> >are
>> >re-executed.
>> >
>> >
>>
>
>
-
Problem using application client for local stateful session bean
Hi,
I have deployed a local stateful session bean in Sun J2EE 1.4 application server.
On running the applclient for the stateful session bean application client i get the following error:
Warning: ACC006: No application client descriptor defined for: [null]
cant we use application client for local stateful session beans. becoz the application runs smoothly when i changed the stateful sesion bean to remote.Hi,
No, an ejb that exposes a local view can only be accessed by an ejb or web component packaged within the same application. Parameters and return values for invocations through the ejb local view are passed by reference instead of by value. That can't work for an application client since it's running in a separate JVM.
--ken -
Losing UserTransaction state in Stateful session bean
I have a UserTransaction I wish to begin and commit in different methods of a Stateful session bean. I have 2 methods to test this on the session bean:
public void beginTransaction()
trans = context.getUserTransaction() ;
trans.begin() ;
public void commitTransaction()
trans = context.getUserTransaction() ;
trans.commit() ;
If I call these methods from one Perform method in a Struts action all works fine. If I call the methods in different Struts actions (storing the session bean handle on the HTTPSession in the first for retrieval in the second) the second call fails with the following exception:
java.lang.IllegalStateException: No active Transaction
The state of the transaction on the second call is STATUS_NO_TRANSACTION. I am certain that I have lost no state on the session bean and that using handles gives me the correct bean since I have written some state to test this. Basically something seems to close the transaction between the end of the first Perform method and the beginning of the second (I am of course assuming this is a valid thing to do).
My session bean descriptor has <transaction-type>Bean</transaction-type>, and I am using OC4J.
If anyone can point out what it is I am doing wrong I would be grateful!
James.Sorry, I have re-checked my code and I believe I found the problem.
I was beginning my transaction inside ejbCreate() and trying to commit/rollback in another method. This works in JBoss 3.2 but does not work in either OC4J or WebLogic 7.
If I begin my transaction in a business method and commit/rollback in another method, everything works fine. (It also seems to work fine in 9.0.3 this way).
So I am not sure whether this is a bug in 9iAS/WLS, or a bug in JBoss, or something that is left "vague" in the J2EE spec. Unfortunately, examples on bean-managed transactions are thin on the ground generally (the usual advice being not to use them, which I definitely agree with!).
If you believe that the behaviour I describe is a bug in 9iAS, I can send a simple EJB test case.
Keith -
HttpSession vs. Stateful Session Bean ---- when State Session is large
I hope most of the people come across with this issue where to put the state
for the internet/intranet based applications when they are using
servlet/jsps calling session beans. Weblogic 4.5.1 does support httpsession
in-memory replication for the servlets but the stateful session beans are
not replicated in clustered environment. Plus with stateful bean u get
activation/passivation overhead too. So one tempts to use stateless session
beans and store state in httpsession?
Then what is the upper limit for the session state one can put in
HttpSession with the weblogic? Is there any way to configure it?
One way to overcome the httpsession size limitation is to use database for
storing state and just store some unique Ids for the session info in
httpSession. But then there will be overhead for database connection?(jdbc
connection pool can provide some help here). So what is the recommended way
for doing this provided few thousand concurrent clients with session size
say exceeding 4kb per client?
Thanks
UsmaniThere are no special setting in sun-ejb-jar.xml regarding cache settings. The default settings from server.xml are used:
<jdbc-connection-pool steady-pool-size="8" max-pool-size="32" max-wait-time-in-millis="60000" pool-resize-quantity="2" idle-timeout-in-seconds="300" is-isolation-level-guaranteed="false" is-connection-validation-required="false" connection-validation-method="auto-commit" fail-all-connections="false" datasource-classname="oracle.jdbc.pool.OracleDataSource" name="ebs">
<property value="jdbc:oracle:thin:@myebsdbsserver:1521:ebsdevdb" name="url"/>
<property value="ebs" name="user"/>
<property value="ebs" name="password"/>
</jdbc-connection-pool>
<ejb-container steady-pool-size="32" pool-resize-quantity="16" max-pool-size="64" cache-resize-quantity="32" max-cache-size="512" pool-idle-timeout-in-seconds="600" cache-idle-timeout-in-seconds="600" removal-timeout-in-seconds="5400" victim-selection-policy="nru" commit-option="B" monitoring-enabled="true">
</ejb-container>The Session Bean uses Container Managed Transaction. Is it possible in this case, that the bean isn't 'idle enough' in order to set into passivated? -
Accessing the same stateful session bean from multiple clients in a clustered environment
I am trying to access the same stateful session bean from multiple
clients. I also want this bean to have failover support so we want to
deploy it in a cluster. The following description is how we have tried
to solve this problem, but it does not seem to be working. Any
insight would be greatly appreciated!
I have set up a cluster of three servers. I deployed a stateful
session bean with in memory replication across the cluster. A client
obtains a reference to an instance of one of these beans to handle a
request. Subsequent requests will have to use the same bean and could
come from various clients. So after using the bean the first client
stores the handle to the bean (actually the replica aware stub) to be
used by other clients to be able to obtain the bean. When another
client retrieves the handle gets the replica aware stub and makes a
call to the bean the request seems to unpredictably go to any of the
three servers rather than the primary server hosting that bean. If the
call goes to the primary server everything seems to work fine the
session data is available and it gets backed up on the secondary
server. If it happens to go to the secondary server a bean that has
the correct session data services the request but gives the error
<Failed to update the secondary copy of a stateful session bean from
home:ejb20-statefulSession-TraderHome>. Then any subsequent requests
to the primary server will not reflect changes made on the secondary
and vice versa. If the request happens to go to the third server that
is not hosting an instance of that bean then the client receives an
error that the bean was not available. From my understanding I thought
the replica aware stub would know which server is the primary host for
that bean and send the request there.
Thanks in advance,
Justin
If 'allow-concurrent-call' does exactly what you need, then you don't have a problem,
do you?
Except of course if you switch ejb containers. Oh well.
Mike
"FBenvadi" <[email protected]> wrote:
>I've got the same problem.
>I understand from you that concurrent access to a stateful session bean
>is
>not allowed but there is a
>token is weblogic-ejb-jar.xml that is called 'allow-concurrent-call'
>that
>does exactly what I need.
>What you mean 'you'll get a surprise when you go to production' ?
>I need to understand becouse I can still change the design.
>Thanks Francesco
>[email protected]
>
>"Mike Reiche" <[email protected]> wrote in message
>news:[email protected]...
>>
>> Get the fix immediately from BEA and test it. It would be a shame to
>wait
>until
>> December only to get a fix - that doesn't work.
>>
>> As for stateful session bean use - just remember that concurrent access
>to
>a stateful
>> session bean is not allowed. Things will work fine until you go to
>production
>> and encounter some real load - then you will get a surprise.
>>
>> Mike
>>
>> [email protected] (Justin Meyer) wrote:
>> >I just heard back from WebLogic Tech Support and they have confirmed
>> >that this is a bug. Here is their reply:
>> >
>> >There is some problem in failover of stateful session beans when its
>> >run from a java client.However, it is fixed now.
>> >
>> >The fix will be in SP2 which will be out by december.
>> >
>> >
>> >Mike,
>> >Thanks for your reply. I do infact believe we are correctly using
>a
>> >stateful session bean however it may have been misleading from my
>> >description of the problem. We are not accessing the bean
>> >concurrently from 2 different clients. The second client will only
>> >come into play if the first client fails. In this case we want to
>be
>> >able to reacquire the handle to our stateful session bean and call
>it
>> >from the secondary client.
>> >
>> >
>> >Justin
>> >
>> >"Mike Reiche" <[email protected]> wrote in message
>news:<[email protected]>...
>> >> You should be using an entity bean, not a stateful session bean
>for
>> >this application.
>> >>
>> >> A stateful session bean is intended to be keep state (stateful)
>for
>> >the duration
>> >> of a client's session (session).
>> >>
>> >> It is not meant to be shared by different clients - in fact, if
>you
>> >attempt to
>> >> access the same stateful session bean concurrently - it will throw
>> >an exception.
>> >>
>> >> We did your little trick (storing/retrieving handle) with a stateful
>> >session bean
>> >> on WLS 5.1 - and it did work properly - not as you describe. Our
>sfsb's
>> >were not
>> >> replicated as yours are.
>> >>
>> >> Mike
>> >>
>> >> [email protected] (Justin Meyer) wrote:
>> >> >I am trying to access the same stateful session bean from multiple
>> >> >clients. I also want this bean to have failover support so we want
>> >to
>> >> >deploy it in a cluster. The following description is how we have
>tried
>> >> >to solve this problem, but it does not seem to be working. Any
>> >> >insight would be greatly appreciated!
>> >> >
>> >> >I have set up a cluster of three servers. I deployed a stateful
>> >> >session bean with in memory replication across the cluster. A client
>> >> >obtains a reference to an instance of one of these beans to handle
>> >a
>> >> >request. Subsequent requests will have to use the same bean and
>could
>> >> >come from various clients. So after using the bean the first client
>> >> >stores the handle to the bean (actually the replica aware stub)
>to
>> >be
>> >> >used by other clients to be able to obtain the bean. When another
>> >> >client retrieves the handle gets the replica aware stub and makes
>> >a
>> >> >call to the bean the request seems to unpredictably go to any of
>the
>> >> >three servers rather than the primary server hosting that bean.
>If
>> >the
>> >> >call goes to the primary server everything seems to work fine the
>> >> >session data is available and it gets backed up on the secondary
>> >> >server. If it happens to go to the secondary server a bean that
>has
>> >> >the correct session data services the request but gives the error
>> >> ><Failed to update the secondary copy of a stateful session bean
>from
>> >> >home:ejb20-statefulSession-TraderHome>. Then any subsequent requests
>> >> >to the primary server will not reflect changes made on the secondary
>> >> >and vice versa. If the request happens to go to the third server
>that
>> >> >is not hosting an instance of that bean then the client receives
>an
>> >> >error that the bean was not available. From my understanding I
>thought
>> >> >the replica aware stub would know which server is the primary host
>> >for
>> >> >that bean and send the request there.
>> >> >
>> >> >Thanks in advance,
>> >> >Justin
>>
>
>
-
Deploy Error when using Stateful Session Bean inside Webdynpro
Hi,
I'm trying to create a webdynpro project that uses a stateful session bean
I have created DC's for a EJB Module project, Enterprise Application and Webdynpro component. Created the bean, built it, added it's package to the public part, added the EJB Module to the EAR project. Built the EAR project. Added the EJB Module project and Enterprise Application project as a used DC in the Webdynpro DC.
In the Webdynpro DC I added com.sap.archive-packaging.default.update-descriptors=true in the build.properties file of the cfg directory. (using the navigator view) That resolved an error while building it.
Deployed the Enterprise Application DC without problems.
Tried to deploy the Webdynpro DC but I get the following error:
Jun 16, 2008 9:40:46 AM /userOut/deploy (com.sap.ide.eclipse.sdm.threading.DeployThreadManager) [Thread[Deploy Thread,5,main]] WARNING:
[012]Deployment finished with warning
Settings
SDM host : 10.64.36.74
SDM port : 50018
URL to deploy : file:/C:/DOCUME~1/JESCHA~1/LOCALS~1/Temp/temp59822company.nl~projempactcmp.ear
Result
=> deployed with warning : file:/C:/DOCUME~1/JESCHA~1/LOCALS~1/Temp/temp59822company.nl~projempactcmp.ear
Finished with warnings: development component 'projempactcmp'/'company.nl'/'local'/'20080616094022':Caught exception during application startup from SAP J2EE Engine's deploy service:java.rmi.RemoteException: Error occurred while starting application company.nl/projempactcmp and wait. Reason: Clusterwide execption: server ID 6060950:<--Localization failed: ResourceBundle='com.sap.engine.services.deploy.DeployResourceBundle', ID='com.sap.engine.services.deploy.container.DeploymentException: <--Localization failed: ResourceBundle='com.sap.engine.services.deploy.DeployResourceBundle', ID='Failed implicit start for company.nl/projempejb : Unknown state(5)', Arguments: []--> : Can't find resource for bundle java.util.PropertyResourceBundle, key Failed implicit start for company.nl/projempejb : Unknown state(5)', Arguments: []--> : Can't find resource for bundle java.util.PropertyResourceBundle, key com.sap.engine.services.deploy.container.DeploymentException: <--Localization failed: ResourceBundle='com.sap.engine.services.deploy.DeployResourceBundle', ID='Failed implicit start for company.nl/projempejb : Unknown state(5)', Arguments: []--> : Can't find resource for bundle java.util.PropertyResourceBundle, key Failed implicit start for company.nl/projempejb : Unknown state(5) (message ID: com.sap.sdm.serverext.servertype.inqmy.extern.EngineApplOnlineDeployerImpl.performAction(DeploymentActionTypes).REMEXC)
Deployment exception : Got problems during deployment
Does anyone know what this error means and how to resolve it. I searched the forum but only found errors that look like this relating to XI not to Webdynpro.......
Thansk,
Jeschael
Edited by: J.V. Lebbink on Jun 17, 2008 6:52 AMDefault is 30mts.
This is done as a parameter in orion-ejb-jar.xml. Please look at the EJB Guide at http://otn.oracle.com/docs/products/ias/doc_library/903doc_otn/generic.903/a97677/dtdxml.htm#634197 for details
regards
Debu -
How to intantiate Stateful session bean in EJB 3 ?
In EJB 2.x, to instantiate a Stateful Session bean the process was:
1. Lookup Home object
2. call create(args) method on Home, that in turn would call corresponding ejbCreate(args) on the bean implementation.
Now, in EJB 3, there is no concept of Home interaface, How can I instantiate a stateful session bean with some initialization parameters.
ThanksJust the spec. NetBeans should only be providing the ability to add an ejbCreate method if the bean exposes a Local or Remote 2.x view.
Each lookup or injection of a stateful session bean results in a new bean instance. As long as you call your methods to populate the additional
state right after first acquiring the stateful session bean reference it will work.
--ken -
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
>
>
-
Error in updating secondary stateful session bean
Hi all,
I have set up a cluster of 2 managed servers with WebLogic 6.1. I have a
stateful session bean and several stateless session beans. the stateful
session bean keeps user info and limited cached objects, all are
serializable. it seems working fine, even after killing any one of the
servers, as long as one is alive. a java application client creates a
stateful session bean first, then calls stateless session beans with the
remote interface of the stateful bean as a method parameter. No problem
when stateful session bean is created. However, each stateless bean method
generates the following error message if I turn the debug on (level 64). No
exception stack traces, and all methods execute successfully.
<Error> <EJB> <Failed to update the secondary copy of a stateful session
bean from home:clientsession>
I wonder what causes the error, and why it tries to update the stateful
session bean. in all stateless session beans, only read into the stateful
bean.
Thank you,
Fujin
This has been fixed in WLS 6.1 SP2.
jagdip Talla wrote:
> Hi Fujin,
> please let me know, if u were able to solve the problem..
>
> hi guys,
> appreciate if you could give me some clues
> how to solve this problem ?
>
> i hv 2 WLS instances in a cluster,
> when one server instance is shut down, i keep getting these errors ?
> is it normal ?
> <Feb 19, 2002 2:57:53 PM SGT> <Error> <EJB> <Failed to update the secondary copy of a stateful session bean from home:ejb/xyzrel1_2/xxxxHome>
>
> appreciate if u can let me know, if u could solve it..?
>
> thanks n regads
> jagdip
Rajesh Mirchandani
Developer Relations Engineer
BEA Support
-
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 -
Stateful Session Beans are not passivated / serialized when cache idle time
Technology: Sun Application Server version 7.0.0_01; JDK 1.4.1; developed on Windows 2000; Tested on Sun Solaris.
Initial error on Sun Solaris:
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr: Exception in thread "service-j2ee-25" org.omg.CORBA.OBJ_ADAPTER: vmcid: SUN minor code: 1015 completed: No
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr: at com.sun.corba.ee.internal.POA.GenericPOAServerSC.preinvoke(GenericPOAServerSC.java:389)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr: at com.sun.corba.ee.internal.POA.ServantCachePOAClientSC.initServant(ServantCachePOAClientSC.java:112)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr: at com.sun.corba.ee.internal.POA.ServantCachePOAClientSC.setOrb(ServantCachePOAClientSC.java:95)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr: at com.sun.corba.ee.internal.iiop.CDRInputStream_1_0.createDelegate(CDRInputStream_1_0.java:760)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr: at com.sun.corba.ee.internal.iiop.CDRInputStream_1_0.internalIORToObject(CDRInputStream_1_0.java:750)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr: at com.sun.corba.ee.internal.iiop.CDRInputStream_1_0.read_Object(CDRInputStream_1_0.java:669)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr: at com.sun.corba.ee.internal.iiop.CDRInputStream_1_0.read_abstract_interface(CDRInputStream_1_0.java:890)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr: at com.sun.corba.ee.internal.iiop.CDRInputStream_1_0.read_abstract_interface(CDRInputStream_1_0.java:884)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr: at com.sun.corba.ee.internal.iiop.CDRInputStream.read_abstract_interface(CDRInputStream.java:307)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr: at com.sun.corba.se.internal.io.IIOPInputStream.readObjectDelegate(IIOPInputStream.java:228)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr: at com.sun.corba.se.internal.io.IIOPInputStream.readObjectOverride(IIOPInputStream.java:381)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr: at java.io.ObjectInputStream.readObject(ObjectInputStream.java:318)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr: at com.sun.enterprise.iiop.IIOPHandleDelegate.getStub(IIOPHandleDelegate.java:58)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr: at com.sun.enterprise.iiop.IIOPHandleDelegate.readEJBObject(IIOPHandleDelegate.java:38)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr: at com.sun.ejb.portable.HandleImpl.readObject(HandleImpl.java:91)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr: at com.sun.corba.se.internal.io.IIOPInputStream.readObject(Native Method)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr: at com.sun.corba.se.internal.io.IIOPInputStream.invokeObjectReader(IIOPInputStream.java:1298)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr: at com.sun.corba.se.internal.io.IIOPInputStream.inputObject(IIOPInputStream.java:908)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr: at com.sun.corba.se.internal.io.IIOPInputStream.simpleReadObject(IIOPInputStream.java:261)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr: at com.sun.corba.se.internal.io.ValueHandlerImpl.readValueInternal(ValueHandlerImpl.java:247)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr: at com.sun.corba.se.internal.io.ValueHandlerImpl.readValue(ValueHandlerImpl.java:209)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr: at com.sun.corba.ee.internal.iiop.CDRInputStream_1_0.read_value(CDRInputStream_1_0.java:981)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr: at com.sun.corba.ee.internal.iiop.CDRInputStream.read_value(CDRInputStream.java:287)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr: at com.sun.corba.ee.internal.javax.rmi.CORBA.Util.copyObject(Util.java:598)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr: at javax.rmi.CORBA.Util.copyObject(Util.java:314)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr: at com.telstra.nodeman.ejb._NodeMaint_Stub.getHandle(Unknown Source)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr: at com.telstra.nodeman.arch.NMAViewBeanProxy.checkBeans(NMAViewBeanProxy.java:631)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr: at com.telstra.nodeman.view.html.NMAStandardButton.handleRequest(NMAStandardButton.java:143)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr: at com.telstra.nodeman.arch.NMAViewBeanBase.handleRequest(NMAViewBeanBase.java:1573)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr: at com.iplanet.jato.view.ViewBeanBase.dispatchInvocation(ViewBeanBase.java:824)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr: at com.iplanet.jato.view.ViewBeanBase.invokeRequestHandlerInternal(ViewBeanBase.java:637)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr: at com.iplanet.jato.view.ViewBeanBase.invokeRequestHandler(ViewBeanBase.java:595)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr: at com.iplanet.jato.ApplicationServletBase.dispatchRequest(ApplicationServletBase.java:772)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr: at com.iplanet.jato.ApplicationServletBase.processRequest(ApplicationServletBase.java:446)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr: at com.iplanet.jato.ApplicationServletBase.doPost(ApplicationServletBase.java:324)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr: at com.telstra.nodeman.view.ViewServlet.doPost(ViewServlet.java:243)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr: at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr: at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr: at org.apache.catalina.core.StandardWrapperValve.invokeServletService(StandardWrapperValve.java:720)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr: at org.apache.catalina.core.StandardWrapperValve.access$000(StandardWrapperValve.java:118)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr: at org.apache.catalina.core.StandardWrapperValve$1.run(StandardWrapperValve.java:278)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr: at java.security.AccessController.doPrivileged(Native Method)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr: at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:274)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr: at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:505)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr: at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:212)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr: at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:505)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr: at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:203)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr: at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:505)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr: at com.iplanet.ias.web.connector.nsapi.NSAPIProcessor.process(NSAPIProcessor.java:158)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr: at com.iplanet.ias.web.WebContainer.service(WebContainer.java:598)
The above error caused the server to use all available memory and required a reboot to proceed.
Subsequent testing against the Sun Appliucation Server 7 on Windows 2000 dev environment using the Sun Studio IDE for debugging and trace statements inserted in the code indicate that the Application Server is removing the Stateful Session Beans when they time out without an ejbPassivate event and without serializing the beans to the data-store. cache-idle-timeout-in-seconds set to 180 and removal-timeout-in-seconds set to 1800.
The server.log indicates that the beans are timing out:
[19/Aug/2004:18:15:10] WARNING ( 1664): [NRU-com.telstra.nodeman.ejb.AddressMaintBean]: IdleBeanCleanerTask finished after removing 2 idle beans
Trace statements inserted in ejbPassivate do not appear in the log.
It is my understanding that the above timeout should have caused an ejbPasssivate and serialization of the beans.
The beans have been validated using Sun Java Studio Enterprise 6 with 'EJB validate'.
My reading of the problem is that the beans are not being serialized and the error occurs when the application attempts to reference (getHandle) the bean after timeout.
Any suggestions would be appreciated.Thanks Thorick.
I am using NRU caching. WL 7.0 SP2.
I have not defined idle-timeout-seconds in my weblogic-ejb-jar.xml. As I understand
the default value for this is 600secs. So the ejbs should be removed after this
time. Below is the
weblogic-ejb-jar.xml that I am using.
<!DOCTYPE weblogic-ejb-jar PUBLIC '-//BEA Systems, Inc.//DTD WebLogic 7.0.0 EJB//EN'
'http://www.bea.com/servers/wls700/dtd/weblogic-ejb-jar.dtd'>
<!-- Generated XML! -->
<weblogic-ejb-jar>
<weblogic-enterprise-bean>
<ejb-name>Cart</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>
<transaction-descriptor>
<trans-timeout-seconds>
60
</trans-timeout-seconds>
</transaction-descriptor>
<jndi-name>CartHome</jndi-name>
</weblogic-enterprise-bean>
</weblogic-ejb-jar>
"thorick" <[email protected]> wrote:
>
The idle-timeout-seconds property controls the timeout/removal behavior.
which stateful session cache type are you using ? LRUCache or NRUCache -
Stateful session Bean in Model not working
I made a sample application very very simple, and the weblogic server cant find the @stateful annotation on the class. is it there another possibility? here i post the error i get:
[Running application MyTest1 on Server Instance IntegratedWebLogicServer...]
[09:48:51 PM] ---- Deployment started. ----
[09:48:51 PM] Target platform is (Weblogic 10.3).
[09:48:52 PM] Retrieving existing application information
[09:48:52 PM] Running dependency analysis...
[09:48:52 PM] Deploying 3 profiles...
[09:48:53 PM] Wrote Web Application Module to /home/issanllo/.jdeveloper/system11.1.1.2.36.55.36/o.j2ee/drs/MyTest1/ViewWebApp.war
[09:48:53 PM] Wrote EJB Module to /home/issanllo/.jdeveloper/system11.1.1.2.36.55.36/o.j2ee/drs/MyTest1/ModelEJB.jar
[09:48:53 PM] Wrote Enterprise Application Module to /home/issanllo/.jdeveloper/system11.1.1.2.36.55.36/o.j2ee/drs/MyTest1
[09:48:53 PM] Deploying Application...
<03-jun-2010 21H48' CEST> <Error> <Deployer> <BEA-149265> <Failure occurred in the execution of deployment request with ID '1275594533727' for task '2'. Error is: 'weblogic.application.ModuleException: Exception preparing module: EJBModule(ModelEJB.jar)
[EJB:011023]An error occurred while reading the deployment descriptor. The error was:
No EJBs found in the ejb-jar file {0}. Please ensure the ejb-jar contains EJB declarations via an ejb-jar.xml deployment descriptor or at least one class annotated with the @Stateless, @Stateful or @MessageDriven EJB annotation..'
weblogic.application.ModuleException: Exception preparing module: EJBModule(ModelEJB.jar)
[EJB:011023]An error occurred while reading the deployment descriptor. The error was:
No EJBs found in the ejb-jar file {0}. Please ensure the ejb-jar contains EJB declarations via an ejb-jar.xml deployment descriptor or at least one class annotated with the @Stateless, @Stateful or @MessageDriven EJB annotation..
at weblogic.ejb.container.deployer.EJBModule.prepare(EJBModule.java:454)
at weblogic.application.internal.flow.ModuleListenerInvoker.prepare(ModuleListenerInvoker.java:199)
at weblogic.application.internal.flow.DeploymentCallbackFlow$1.next(DeploymentCallbackFlow.java:391)
at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:83)
at weblogic.application.internal.flow.DeploymentCallbackFlow.prepare(DeploymentCallbackFlow.java:59)
Truncated. see log file for complete stacktrace
Caused By: java.io.IOException: No EJBs found in the ejb-jar file {0}. Please ensure the ejb-jar contains EJB declarations via an ejb-jar.xml deployment descriptor or at least one class annotated with the @Stateless, @Stateful or @MessageDriven EJB annotation.
at weblogic.ejb.container.dd.xml.EjbDescriptorReaderImpl.createReadOnlyDescriptorFromJarFile(EjbDescriptorReaderImpl.java:219)
at weblogic.ejb.spi.EjbDescriptorFactory.createReadOnlyDescriptorFromJarFile(EjbDescriptorFactory.java:93)
at weblogic.ejb.container.deployer.EJBModule.loadEJBDescriptor(EJBModule.java:1210)
at weblogic.ejb.container.deployer.EJBModule.prepare(EJBModule.java:382)
at weblogic.application.internal.flow.ModuleListenerInvoker.prepare(ModuleListenerInvoker.java:199)
Truncated. see log file for complete stacktrace
>
<03-jun-2010 21H48' CEST> <Warning> <Deployer> <BEA-149004> <Failures were detected while initiating deploy task for application 'MyTest1'.>
<03-jun-2010 21H48' CEST> <Warning> <Deployer> <BEA-149078> <Stack trace for message 149004
weblogic.application.ModuleException: Exception preparing module: EJBModule(ModelEJB.jar)
[EJB:011023]An error occurred while reading the deployment descriptor. The error was:
No EJBs found in the ejb-jar file {0}. Please ensure the ejb-jar contains EJB declarations via an ejb-jar.xml deployment descriptor or at least one class annotated with the @Stateless, @Stateful or @MessageDriven EJB annotation..
at weblogic.ejb.container.deployer.EJBModule.prepare(EJBModule.java:454)
at weblogic.application.internal.flow.ModuleListenerInvoker.prepare(ModuleListenerInvoker.java:199)
at weblogic.application.internal.flow.DeploymentCallbackFlow$1.next(DeploymentCallbackFlow.java:391)
at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:83)
at weblogic.application.internal.flow.DeploymentCallbackFlow.prepare(DeploymentCallbackFlow.java:59)
Truncated. see log file for complete stacktrace
Caused By: java.io.IOException: No EJBs found in the ejb-jar file {0}. Please ensure the ejb-jar contains EJB declarations via an ejb-jar.xml deployment descriptor or at least one class annotated with the @Stateless, @Stateful or @MessageDriven EJB annotation.
at weblogic.ejb.container.dd.xml.EjbDescriptorReaderImpl.createReadOnlyDescriptorFromJarFile(EjbDescriptorReaderImpl.java:219)
at weblogic.ejb.spi.EjbDescriptorFactory.createReadOnlyDescriptorFromJarFile(EjbDescriptorFactory.java:93)
at weblogic.ejb.container.deployer.EJBModule.loadEJBDescriptor(EJBModule.java:1210)
at weblogic.ejb.container.deployer.EJBModule.prepare(EJBModule.java:382)
at weblogic.application.internal.flow.ModuleListenerInvoker.prepare(ModuleListenerInvoker.java:199)
Truncated. see log file for complete stacktrace
>
#### Cannot run application MyTest1 due to error deploying to IntegratedWebLogicServer.
[09:48:54 PM] #### Deployment incomplete. ####
[09:48:54 PM] Remote deployment failed (oracle.jdevimpl.deploy.common.Jsr88RemoteDeployer)
[Application MyTest1 stopped and undeployed from Server Instance IntegratedWebLogicServer]
and the very simple class with a Local and Remote interfaces at Model project in jDeveloper 11g (11.1.1.3)
package test.core;
import java.util.ArrayList;
import java.util.List;
import javax.ejb.Local;
import javax.ejb.Remote;
import javax.ejb.Stateful;
@Stateful(name = "ControlSessionBean", mappedName = "MyTest1-Model-ControlSessionBean")
public class ControlSessionBean implements ControlSessionRemote,
ControlSessionLocal
private String username;
private String password;
public ControlSessionBean()
public List simple()
List <String> s = new ArrayList();
s.add(username);
s.add(password);
return s;
any suggestions why it is not working??
sincerely
Israel S Llorensnot working... i tried to make the stateful session bean Control.. and is still not working the error i get now is this one:
<04-jun-2010 16H29' CEST> <Error> <Deployer> <BEA-149265> <Failure occurred in the execution of deployment request with ID '1275661769594' for task '9'. Error is: 'weblogic.application.ModuleException: Could not setup environment'
weblogic.application.ModuleException: Could not setup environment
at weblogic.servlet.internal.WebAppModule.activateContexts(WebAppModule.java:1499)
at weblogic.servlet.internal.WebAppModule.activate(WebAppModule.java:442)
at weblogic.application.internal.flow.ModuleStateDriver$2.next(ModuleStateDriver.java:375)
at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:41)
at weblogic.application.internal.flow.ModuleStateDriver.activate(ModuleStateDriver.java:95)
Truncated. see log file for complete stacktrace
Caused By: weblogic.deployment.EnvironmentException: [J2EE:160200]Error resolving ejb-ref 'gecu.view.LoginBean/controlBean' from module 'GeCU_Web_view_root' of application 'GeCU_Web'. The ejb-ref does not have an ejb-link and the JNDI name of the target bean has not been specified. Attempts to automatically link the ejb-ref to its target bean failed because no EJBs in the application were found to implement the 'gecu.model.ControlSession' interface. Please link or map this ejb-ref to its target EJB and ensure the interfaces declared in the ejb-ref are correct.
at weblogic.deployment.BaseEnvironmentBuilder.autowireEJBRef(BaseEnvironmentBuilder.java:427)
at weblogic.deployment.EnvironmentBuilder.addEJBReferences(EnvironmentBuilder.java:502)
at weblogic.servlet.internal.CompEnv.activate(CompEnv.java:157)
at weblogic.servlet.internal.WebAppServletContext.activate(WebAppServletContext.java:3117)
at weblogic.servlet.internal.WebAppModule.activateContexts(WebAppModule.java:1497)
Truncated. see log file for complete stacktrace
>
<04-jun-2010 16H29' CEST> <Error> <Deployer> <BEA-149202> <Encountered an exception while attempting to commit the 9 task for the application 'GeCU_Web'.>
<04-jun-2010 16H29' CEST> <Warning> <Deployer> <BEA-149004> <Failures were detected while initiating deploy task for application 'GeCU_Web'.>
<04-jun-2010 16H29' CEST> <Warning> <Deployer> <BEA-149078> <Stack trace for message 149004
weblogic.application.ModuleException: Could not setup environment
at weblogic.servlet.internal.WebAppModule.activateContexts(WebAppModule.java:1499)
at weblogic.servlet.internal.WebAppModule.activate(WebAppModule.java:442)
at weblogic.application.internal.flow.ModuleStateDriver$2.next(ModuleStateDriver.java:375)
at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:41)
at weblogic.application.internal.flow.ModuleStateDriver.activate(ModuleStateDriver.java:95)
Truncated. see log file for complete stacktrace
Caused By: weblogic.deployment.EnvironmentException: [J2EE:160200]Error resolving ejb-ref 'gecu.view.LoginBean/controlBean' from module 'GeCU_Web_view_root' of application 'GeCU_Web'. The ejb-ref does not have an ejb-link and the JNDI name of the target bean has not been specified. Attempts to automatically link the ejb-ref to its target bean failed because no EJBs in the application were found to implement the 'gecu.model.ControlSession' interface. Please link or map this ejb-ref to its target EJB and ensure the interfaces declared in the ejb-ref are correct.
at weblogic.deployment.BaseEnvironmentBuilder.autowireEJBRef(BaseEnvironmentBuilder.java:427)
at weblogic.deployment.EnvironmentBuilder.addEJBReferences(EnvironmentBuilder.java:502)
at weblogic.servlet.internal.CompEnv.activate(CompEnv.java:157)
at weblogic.servlet.internal.WebAppServletContext.activate(WebAppServletContext.java:3117)
at weblogic.servlet.internal.WebAppModule.activateContexts(WebAppModule.java:1497)
Truncated. see log file for complete stacktrace
>
[04:29:35 PM] #### Deployment incomplete. ####
[04:29:35 PM] Remote deployment failed -
Handling Transaction in Stateful Session Bean
I wrote a public method like public void doTransaction()
it will call 2 private method, like: methodA and methodB
Both private methods have db accesss statement and will update the db. They got different db connection and will close the connection when method call finished.
How to include them to one transaction? I want to be able to rollback the job of the first method when I catch exception thrown by the second method.
I tried simply define transaction type of the public method to be Container and Required. But it doesn't work, the first method doesn't rollback. Of course I can let the 2 private methods share a same connection and commit after finishing calling them. But how if they are in different DB?Ok... Here it goes...
You can do it in the following manner.
As you said you have got 2 private methods doing d/b updates and these are called from a public method.
Stateful session beans since associated with a client across methods, you can take advantage of it. Write your own user defined transaction.
Begin the transaction scope in your public before calling the 1st private method. Call the 2 methods in a try block. Once you are done with these methods, you can commit and end the transaction. If you get any exception, rollback the transaction in the catch block. Otherwise if u get any exception in the 2nd method, you can rollback the transaction there itself.
Stateful session beans lets u allow to spawn the bean managed transaction across methods. you can begin your transaction in one method and end it in a differnt method or you can end the transaction after calling the methods.
The problem you are dealing with can typically very well handled by writing bean managed transaction.
Hope this helps. If you need anymore clarity on my solution, please let me know.
-amit -
Initialize a stateful session bean from another
Hi,
I am trying to create and initialize a stateful session bean from another stateful session bean. The code is as follows
This method belongs to DefaultSessionBean where it creates the AdminSessionBean based on few checks and returns it to the client.
public AdminSession getAdminSession() throws UnknownException, WarningException {
checkSessionUser("getAdminSession");
if (isAdmin()) {
AdminSession adminSession;
try {
final Context context = IToolsUtil.getInitialContext();
adminSession = (AdminSession)context.lookup("AdminSession");
System.out.println("Successfully created the adminsession bean");
} catch (NamingException ne) {
ne.printStackTrace();
throw new UnknownException (new CatalogHelper("ITOOLS_100019", new Object[]{"Admin", ne.getMessage()}));
System.out.println("adminsession will be returned");
return adminSession;
} else {
throw new WarningException (new CatalogHelper("ITOOLS_000042", sessionUser.getUserhandle()));
}Another method in DefaultSessionBean, creates its local interface and returns it.
public DefaultSessionLocal getDefaultSessionLocal() {
DefaultSessionLocal dsl = (DefaultSessionLocal)context.getBusinessObject(DefaultSessionLocal.class);
System.out.println("local created.");
return dsl;
}Client call initialize method of the AdminSessionBean which is mentioned below:
public void initialize(DefaultSession ds) throws WarningException, UnknownException {
this.ds = ds.getDefaultSessionLocal();
this.rfl = ReadFieldList.getInstance();
this.fm = new FinderMethods();
}The client code where it gets the adminSession and initializes is
public static AdminSession getAdminSession(DefaultSession ds) throws ViewException {
AdminSession as;
try {
as = ds.getAdminSession();
System.out.println("got admin session");
} catch (WarningException we) {
we.printStackTrace();
throw new ViewException(we.getCatalogHelper());
} catch (UnknownException ue) {
ue.printStackTrace();
throw new ViewException(ue.getCatalogHelper());
} catch (OracleRemoteException ore) {
ore.printStackTrace();
throw new ViewException(new CatalogHelper("ITOOLS_050003", ore.getMessage()));
// Initialize Admin Session
try {
System.out.println("before getting it.");
as.initialize(ds);
System.out.println("adminsession is initialized");
} catch (WarningException we) {
as.remove();
as = null;
throw new ViewException(we.getCatalogHelper());
} catch (UnknownException ue) {
as.remove();
as = null;
throw new ViewException(ue.getCatalogHelper());
} catch (OracleRemoteException ore) {
as.remove();
as = null;
throw new ViewException(new CatalogHelper("ITOOLS_050003", ore.getMessage()));
System.out.println("got admin session");
return as;
}Apart from this I am using OC4J 10.1.3.1 tool test my application.
When I am calling initialize method of the AdminSession I am getting the following error.
06/10/24 12:26:08 Entered
06/10/24 12:26:08 got default session
06/10/24 12:26:08 Successfully created the adminsession bean
06/10/24 12:26:08 adminsession will be returned
06/10/24 12:26:08 got admin session
06/10/24 12:26:08 before getting it.
2006-10-24 12:26:08.156 WARNING J2EE RMI-00009 Exception returned by remote server: {0}
06/10/24 12:26:08 com.itools.vs.view.exception.ViewException
06/10/24 12:26:08 at com.itools.vs.view.util.ViewUtil.getAdminSession(ViewUtil.java:71)
06/10/24 12:26:08 at com.itools.vs.view.backing.Admin.CreateUser.submit_action(CreateUser.java:182)
06/10/24 12:26:08 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
06/10/24 12:26:08 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
06/10/24 12:26:08 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
06/10/24 12:26:08 at java.lang.reflect.Method.invoke(Method.java:585)
06/10/24 12:26:08 at com.sun.faces.el.MethodBindingImpl.invoke(MethodBindingImpl.java:146)
06/10/24 12:26:08 at com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:92)
06/10/24 12:26:08 at org.ajax4jsf.framework.ajax.AjaxActionComponent.broadcast(AjaxActionComponent.java:88)
06/10/24 12:26:08 at org.ajax4jsf.framework.ajax.AjaxViewRoot.processEvents(AjaxViewRoot.java:274)
06/10/24 12:26:08 at org.ajax4jsf.framework.ajax.AjaxViewRoot.broadcastEvents(AjaxViewRoot.java:250)
06/10/24 12:26:08 at org.ajax4jsf.framework.ajax.AjaxViewRoot.processApplication(AjaxViewRoot.java:405)
06/10/24 12:26:08 at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:95)
06/10/24 12:26:08 at com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:245)
06/10/24 12:26:08 at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:110)
06/10/24 12:26:08 at javax.faces.webapp.FacesServlet.service(FacesServlet.java:213)
06/10/24 12:26:08 at com.evermind.server.http.ResourceFilterChain.doFilter(ResourceFilterChain.java:64)
06/10/24 12:26:08 at org.ajax4jsf.framework.ajax.xmlfilter.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:67)
06/10/24 12:26:08 at org.ajax4jsf.framework.ajax.xmlfilter.BaseFilter.doFilter(BaseFilter.java:223)
06/10/24 12:26:08 at com.evermind.server.http.ServletRequestDispatcher.invoke(ServletRequestDispatcher.java:621)
06/10/24 12:26:08 at com.evermind.server.http.ServletRequestDispatcher.forwardInternal(ServletRequestDispatcher.java:368)
06/10/24 12:26:08 at com.evermind.server.http.HttpRequestHandler.doProcessRequest(HttpRequestHandler.java:866)
06/10/24 12:26:08 at com.evermind.server.http.HttpRequestHandler.processRequest(HttpRequestHandler.java:448)
06/10/24 12:26:08 at com.evermind.server.http.HttpRequestHandler.serveOneRequest(HttpRequestHandler.java:216)
06/10/24 12:26:08 at com.evermind.server.http.HttpRequestHandler.run(HttpRequestHandler.java:117)
06/10/24 12:26:08 at com.evermind.server.http.HttpRequestHandler.run(HttpRequestHandler.java:110)
06/10/24 12:26:08 at oracle.oc4j.network.ServerSocketReadHandler$SafeRunnable.run(ServerSocketReadHandler.java:260)
06/10/24 12:26:08 at oracle.oc4j.network.ServerSocketAcceptHandler.procClientSocket(ServerSocketAcceptHandler.java:239)
06/10/24 12:26:08 at oracle.oc4j.network.ServerSocketAcceptHandler.access$700(ServerSocketAcceptHandler.java:34)
06/10/24 12:26:08 at oracle.oc4j.network.ServerSocketAcceptHandler$AcceptHandlerHorse.run(ServerSocketAcceptHandler.java:880)
06/10/24 12:26:08 at com.evermind.util.ReleasableResourcePooledExecutor$MyWorker.run(ReleasableResourcePooledExecutor.java:303)
06/10/24 12:26:08 at java.lang.Thread.run(Thread.java:595)
06/10/24 12:26:08 ITOOLS_050003: Failed to get Admin Session.
Exception is "Error marshalling objects, Not Serializable: java.io.NotSerializableException: DefaultSession_RemoteProxy_6nein01; nested exception is:
java.io.NotSerializableException: DefaultSession_RemoteProxy_6nein01".
[b/Your remote client passes a DefaultSession to AdminSession.initialize(..). This DefaultSession has to be a remote type. In your client, how does it get DefaultSession?
Did your client look up DefaultSession, and have it return a (sessionContext.getBusinessObject(DefaultSession.class))? If so, it should work.
Maybe you are looking for
-
ODI Procedures not working after upgrading from 10G to 11G
Hello Gurus, We have run into a scenario where the procedures in ODI are not working after we upgraded it from 10G to 11G (11.1.1.6). However we can make it to run if we create the procedure from scratch. Also we are having issues related to packages
-
Error message : No order corresponds to selection criteria
Hi, I am using T code CN24N for scheduling networks for a project and entering Project as the input. But I am getting the error: No order corresponds to selection criteria networks are there for the selected Project. Can anyone tell me the possibl
-
Should I reinstall Lightroom and if so, how do I not lose my work?
I have Windows 8 and Lightroom 5.7 installed on my desktop. Every since I did the last update, Lightroom has been acting really weird. I often get a "Lightroom Not Responding" message, or it will take for ever to do something like move from library
-
Hi, I have two file name at sender side and wan to generate Idoc (receiver) . File data and format is same. Can I do it ? it would be great, if some one share me any blog where we are using advance option of File adapter( File content conversio
-
iTunes will eventually tell me that the library was created with a newer version of iTunes but I am using the latest version