Bean on already undeployed

After installing our product on a clean machine when the WLS server runs for the
first time
a call to an entity EJB raises the java.rmi.NoSuchObjectException Bean on already
undeployed.
After WLS reboots the problem seems to disappear.
Regards.
Eran

<Thu Jan 22 18:07:02 GMT+02:00 2004> <Debug><tserver><java.rmi.NoSuchObjectException:
Bean is already undeployed.
     at weblogic.ejb20.manager.BaseEJBManager.preInvoke(BaseEJBManager.java:94)
     at weblogic.ejb20.manager.DBManager.preInvoke(DBManager.java:239)
     at weblogic.ejb20.internal.BaseEJBObject.preInvoke(BaseEJBObject.java:130)
     at weblogic.ejb20.internal.EntityEJBObject.preInvoke(EntityEJBObject.java:90)
     at com.orsus.servers.workflow.tserver.ejb.TaskInfo_dqur1l_EOImpl.setTaskBusy(TaskInfo_dqur1l_EOImpl.java:386)
     at com.orsus.servers.workflow.tserver.message.TaskDispatcherQueueListener.onTaskMessageAcknowladge(TaskDispatcherQueueListener.java:238)
     at com.orsus.servers.workflow.tserver.message.TaskDispatcherQueueListener.onMessage(TaskDispatcherQueueListener.java:76)
     at weblogic.jms.client.JMSSession.onMessage(JMSSession.java:2596)
     at weblogic.jms.client.JMSSession.execute(JMSSession.java:2516)
     at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:197)
     at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:170)

Similar Messages

WLS 7: "Bean is already undeployed" error

Hi all,
Been beating againt WLS 7.0 some more.
Originally, we had our application running in Tomcat and using WLS purely
for EJBs. Now, we've been trying to get the WAR to work within WLS, and made
some layout changes in order to accomodate WLS.
But now, I'm consistently (though I won't say repeatably, as in I can make
it happen) getting these errors, and once that happens, my app is dead.
The WAR and EJBs are part of the same EAR file. I don't any notice in the
WLS log of WLS "undeploying" the IRNGenerator bean, and I'm certainly not
doing it myself, yet I get this error all the time, and it's a bit of a
roadblock.
This doesn't make a lot of sense. I'm not seeing any other exceptions in the
WLS log that would foreshadow this happening.
Any thoughts would be appreciated.
Best Regards,
Will Hartung
([email protected])
Stack snippet below:
1342520 [ExecuteThread: '10' for queue: 'default'] ERROR
msc.asutil.IRNGenerator - getNext: exception: Bean is already undeployed.
java.rmi.NoSuchObjectException: Bean is already undeployed.
at
weblogic.ejb20.manager.BaseEJBManager.preInvoke(BaseEJBManager.java:94)
at weblogic.ejb20.manager.DBManager.preInvoke(DBManager.java:226)
at
weblogic.ejb20.internal.BaseEJBObject.preInvoke(BaseEJBObject.java:126)
at
weblogic.ejb20.internal.EntityEJBObject.preInvoke(EntityEJBObject.java:91)
at
msc.as.IRNEntityEJB_b1jyx4_EOImpl.getIRN(IRNEntityEJB_b1jyx4_EOImpl.java:29)
at msc.asutil.IRNGenerator.getNext(IRNGenerator.java:52)
at msc.asutil.IRNGenerator.getNext(IRNGenerator.java:78)
at msc.as.MetricsSessionEJB.logEvent(MetricsSessionEJB.java:190)

Will,
What method are you using to deploy/undeploy your ear? applications directory?
weblogic.Deployer?
Seth
Will Hartung wrote:
Hi all,
Been beating againt WLS 7.0 some more.
Originally, we had our application running in Tomcat and using WLS purely
for EJBs. Now, we've been trying to get the WAR to work within WLS, and made
some layout changes in order to accomodate WLS.
But now, I'm consistently (though I won't say repeatably, as in I can make
it happen) getting these errors, and once that happens, my app is dead.
The WAR and EJBs are part of the same EAR file. I don't any notice in the
WLS log of WLS "undeploying" the IRNGenerator bean, and I'm certainly not
doing it myself, yet I get this error all the time, and it's a bit of a
roadblock.
This doesn't make a lot of sense. I'm not seeing any other exceptions in the
WLS log that would foreshadow this happening.
Any thoughts would be appreciated.
Best Regards,
Will Hartung
([email protected])
Stack snippet below:
1342520 [ExecuteThread: '10' for queue: 'default'] ERROR
msc.asutil.IRNGenerator - getNext: exception: Bean is already undeployed.
java.rmi.NoSuchObjectException: Bean is already undeployed.
at
weblogic.ejb20.manager.BaseEJBManager.preInvoke(BaseEJBManager.java:94)
at weblogic.ejb20.manager.DBManager.preInvoke(DBManager.java:226)
at
weblogic.ejb20.internal.BaseEJBObject.preInvoke(BaseEJBObject.java:126)
at
weblogic.ejb20.internal.EntityEJBObject.preInvoke(EntityEJBObject.java:91)
at
msc.as.IRNEntityEJB_b1jyx4_EOImpl.getIRN(IRNEntityEJB_b1jyx4_EOImpl.java:29)
at msc.asutil.IRNGenerator.getNext(IRNGenerator.java:52)
at msc.asutil.IRNGenerator.getNext(IRNGenerator.java:78)
at msc.as.MetricsSessionEJB.logEvent(MetricsSessionEJB.java:190)

Include file causes redefinition of bean which already exists!!

hi,
i have a jsp page in which i have 3 directives include.
in every included file i have the same bean used like that:
<jsp:usebean id="myid" class="myclass" scope="session"/>
that causes the following error:
"the tag tried to define a bean which already exists : myid"
(it s in frensh i tried to traduce it)
does someone know how to fix that problem??
thanks in advance!

i have a jsp page in which i have 3 directives include.
in every included file i have the same bean used like that:
<jsp:usebean id="myid" class="myclass" scope="session"/>In one translation unit, the value of the id attribute of "jsp:usebean" must be unique. Duplicate ids found in the same translation unit shall result in a fatal translation error. The jsp page, together with the included files as specified by page directive "include" recursively, is considered inside one translation unit.
Removing that line in your included files will fix the problem. Of course, you need to include that line exactly once in the including page.

Tag attempted to define a bean which already exists

I am having problems with something i thought was solved in version 10.1.3.0.0, but obviously not.
Here is the error message i get:
500 Internal Server Error
OracleJSP: oracle.jsp.parse.JspParseException: /html/portlet/journal_content/view.jsp: Line # 101, </liferay-portlet:renderURL>
Error: Tag attempted to define a bean which already exists: portletURL
I have tried adding init-param forgive_dup_dir_attr to the jsp servlet, but it doesn't help.
Any ideas how to solve this??
BR's

500 Internal Server Error
OracleJSP: oracle.jsp.parse.JspParseException: /html/portlet/journal_content/view.jsp:
Line # 101, </liferay-portlet:renderURL>
Error: Tag attempted to define a bean which already exists: portletURLPlease see my message how to avoid "Tag attempted to define a bean which already exists". Please tell me if it helps.
I am having problems with something i thought was solved in version 10.1.3.0.0, but
obviously notUnfortunately, it is not. It should be resolved in the next major version.

Error: Tag attempted to define a bean which already exists:

I am getting following error
oracle.jsp.parse.JspParseException: Line # 1, Error: Tag
attempted to define a bean which already exists: webBoard
The first few line of my code is given below
<%@ page import = "java.io.*" %>
<%@ page import = "java.util.*" %>
<jsp:useBean id ="webBoard" scope = "session" class
= "com.webBoard.DBBean"/>
Any help will be highly appreciated.
Thanks and Regards
Sai Kumar

I am getting following error
oracle.jsp.parse.JspParseException: Line # 1, Error: Tag
attempted to define a bean which already exists: webBoard
The first few line of my code is given below
<%@ page import = "java.io.*" %>
<%@ page import = "java.util.*" %>
<jsp:useBean id ="webBoard" scope = "session" class
= "com.webBoard.DBBean"/>
Any help will be highly appreciated.
Thanks and Regards
Sai Kumar

Installing Oracle SOA Suite with the WebLogic Server

Hi all,
I am trying to install Oracle SOA Suite with the WebLogic Server. After following the step-by-step instruction in the "Installing Oracle SOA Suite with the WebLogic Server" document, I ran into the following situation: I have a working WebLogic Server with all applications deployed. However the BPELPM application is in Failed state.
When I try to run the application, I get following exception (AdminServer.log):
####<Mar 30, 2009 9:46:43 AM EEST> <Warning> <Deployer> <javadev2> <AdminServer> <[STANDBY] ExecuteThread: '1' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1238395603163> <BEA-149004> <Failures were detected while initiating start task for application 'BPELPM'.>
####<Mar 30, 2009 9:46:43 AM EEST> <Warning> <Deployer> <javadev2> <AdminServer> <[STANDBY] ExecuteThread: '1' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1238395603164> <BEA-149078> <Stack trace for message 149004
weblogic.application.ModuleException: [HTTP:101216]Servlet: "cxloader" failed to preload on startup in Web application: "/orabpel".
javax.servlet.ServletException:
ORABPEL START-UP ERROR!!!!!!!!
OraBPEL run-time system failed to start due to exception:
Bean is already undeployed.
at com.collaxa.cube.admin.CXLoaderServlet.init(CXLoaderServlet.java:87)
at javax.servlet.GenericServlet.init(GenericServlet.java:256)
at weblogic.servlet.internal.StubSecurityHelper$ServletInitAction.run(StubSecurityHelper.java:278)
at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:121)
at weblogic.servlet.internal.StubSecurityHelper.createServlet(StubSecurityHelper.java:64)
at weblogic.servlet.internal.StubLifecycleHelper.createOneInstance(StubLifecycleHelper.java:58)
at weblogic.servlet.internal.StubLifecycleHelper.<init>(StubLifecycleHelper.java:48)
at weblogic.servlet.internal.ServletStubImpl.prepareServlet(ServletStubImpl.java:507)
at weblogic.servlet.internal.WebAppServletContext.preloadServlet(WebAppServletContext.java:1723)
at weblogic.servlet.internal.WebAppServletContext.loadServletsOnStartup(WebAppServletContext.java:1700)
at weblogic.servlet.internal.WebAppServletContext.preloadResources(WebAppServletContext.java:1620)
at weblogic.servlet.internal.WebAppServletContext.start(WebAppServletContext.java:2761)
at weblogic.servlet.internal.WebAppModule.startContexts(WebAppModule.java:889)
at weblogic.servlet.internal.WebAppModule.start(WebAppModule.java:333)
at weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:204)
at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:26)
at weblogic.application.internal.flow.ModuleStateDriver.start(ModuleStateDriver.java:60)
at weblogic.application.internal.flow.ScopedModuleDriver.start(ScopedModuleDriver.java:200)
at weblogic.application.internal.flow.ModuleListenerInvoker.start(ModuleListenerInvoker.java:117)
at weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:204)
at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:26)
at weblogic.application.internal.flow.ModuleStateDriver.start(ModuleStateDriver.java:60)
at weblogic.application.internal.flow.StartModulesFlow.activate(StartModulesFlow.java:26)
at weblogic.application.internal.BaseDeployment$2.next(BaseDeployment.java:635)
at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:26)
at weblogic.application.internal.BaseDeployment.activate(BaseDeployment.java:212)
at weblogic.application.internal.DeploymentStateChecker.activate(DeploymentStateChecker.java:154)
at weblogic.deploy.internal.targetserver.AppContainerInvoker.activate(AppContainerInvoker.java:80)
at weblogic.deploy.internal.targetserver.operations.AbstractOperation.activate(AbstractOperation.java:566)
at weblogic.deploy.internal.targetserver.operations.ActivateOperation.activateDeployment(ActivateOperation.java:136)
at weblogic.deploy.internal.targetserver.operations.ActivateOperation.doCommit(ActivateOperation.java:104)
at weblogic.deploy.internal.targetserver.operations.StartOperation.doCommit(StartOperation.java:139)
at weblogic.deploy.internal.targetserver.operations.AbstractOperation.commit(AbstractOperation.java:320)
at weblogic.deploy.internal.targetserver.DeploymentManager.handleDeploymentCommit(DeploymentManager.java:815)
at weblogic.deploy.internal.targetserver.DeploymentManager.activateDeploymentList(DeploymentManager.java:1222)
at weblogic.deploy.internal.targetserver.DeploymentManager.handleCommit(DeploymentManager.java:433)
at weblogic.deploy.internal.targetserver.DeploymentServiceDispatcher.commit(DeploymentServiceDispatcher.java:161)
at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.doCommitCallback(DeploymentReceiverCallbackDeliverer.java:181)
at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.access$100(DeploymentReceiverCallbackDeliverer.java:12)
at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer$2.run(DeploymentReceiverCallbackDeliverer.java:67)
at weblogic.work.ServerWorkManagerImpl$WorkAdapterImpl.run(ServerWorkManagerImpl.java:518)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:209)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:181)
at weblogic.servlet.internal.WebAppModule.startContexts(WebAppModule.java:891)
at weblogic.servlet.internal.WebAppModule.start(WebAppModule.java:333)
at weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:204)
at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:26)
at weblogic.application.internal.flow.ModuleStateDriver.start(ModuleStateDriver.java:60)
at weblogic.application.internal.flow.ScopedModuleDriver.start(ScopedModuleDriver.java:200)
at weblogic.application.internal.flow.ModuleListenerInvoker.start(ModuleListenerInvoker.java:117)
at weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:204)
at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:26)
at weblogic.application.internal.flow.ModuleStateDriver.start(ModuleStateDriver.java:60)
at weblogic.application.internal.flow.StartModulesFlow.activate(StartModulesFlow.java:26)
at weblogic.application.internal.BaseDeployment$2.next(BaseDeployment.java:635)
at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:26)
at weblogic.application.internal.BaseDeployment.activate(BaseDeployment.java:212)
at weblogic.application.internal.DeploymentStateChecker.activate(DeploymentStateChecker.java:154)
at weblogic.deploy.internal.targetserver.AppContainerInvoker.activate(AppContainerInvoker.java:80)
at weblogic.deploy.internal.targetserver.operations.AbstractOperation.activate(AbstractOperation.java:566)
at weblogic.deploy.internal.targetserver.operations.ActivateOperation.activateDeployment(ActivateOperation.java:136)
at weblogic.deploy.internal.targetserver.operations.ActivateOperation.doCommit(ActivateOperation.java:104)
at weblogic.deploy.internal.targetserver.operations.StartOperation.doCommit(StartOperation.java:139)
at weblogic.deploy.internal.targetserver.operations.AbstractOperation.commit(AbstractOperation.java:320)
at weblogic.deploy.internal.targetserver.DeploymentManager.handleDeploymentCommit(DeploymentManager.java:815)
at weblogic.deploy.internal.targetserver.DeploymentManager.activateDeploymentList(DeploymentManager.java:1222)
at weblogic.deploy.internal.targetserver.DeploymentManager.handleCommit(DeploymentManager.java:433)
at weblogic.deploy.internal.targetserver.DeploymentServiceDispatcher.commit(DeploymentServiceDispatcher.java:161)
at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.doCommitCallback(DeploymentReceiverCallbackDeliverer.java:181)
at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.access$100(DeploymentReceiverCallbackDeliverer.java:12)
at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer$2.run(DeploymentReceiverCallbackDeliverer.java:67)
at weblogic.work.ServerWorkManagerImpl$WorkAdapterImpl.run(ServerWorkManagerImpl.java:518)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:209)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:181)
Any help would be highly appreciated.
Boris

Hi Boris,
Looks like you have not run the post upgrade script for 10.1.3.4.
You need to install SOA 10.1.3.4 Basic Installation. Then start following : http://download.oracle.com/docs/cd/E12524_01/core.1013/e13058/weblogic.htm#BHCIIBFB
You basically, first install 10.1.3.4 basic SOA install, Apply the Opatch 7337034 (HOTPLUG: SOASUITE 10.1.3.4 ON WEBLOGIC 9.2 - CHANGES FOR HOTPLUGGABILITY). Install WLS 9.2 MP3.
Now, Download the Oracle SOA Suite 10.1.3.4 WebLogic Server 9.2 : patch : 7490612.
Then , Modify the following mandatory installation properties in the Weblogic_SOA10134_Base\SOADomain.properties file as per the documentation above.
Cheers
Anirudh Pucha

System classpath deployment ideas?

Our product consists of an API and 4 management web applications. We want to restrict
the API provider classes to one instance per vm. Thanks to the classloading improvements
in wls 8.1, we can package the provider code in APP-INF/lib and share one instance
between all 4 of our web applications.
However, ideally we want the provider code shared as a singleton, available to
all EAR files on the server (which may contain code written to the API). The
only way we can figure out how to accomplish this is to put the provider by hand
in the system classpath for each deployment.
Our customers want a clean deployment solution across multiple managed servers.
Does BEA offer a loader between the system loader and all the ear loaders? Would
any developers have ideas on how we could automate deployment into the system
classpath?

Status of deployment is slightly different from "every class within your EAR
is reachable". Deployment status is "did this deployment action finish", at
which point classloaders are inited and some class resolution has taken
place i.e. can the j2ee container load the EJB that is specified in the
descriptor, but not all classes have been loaded. With java's lazy class
load initialiation classes are loaded at request time.
So now to your real problem. Why do you put these interfaces in the system
classpath? (My guess is you want to share them across multiple archives?).
Currently J2EE doesn't have a way to share a single library between multiple
archives. We are looking at solutions to this for our next release. But
until then, you will have to put these interfaces inot a myEBJInterfaces.jar
and put it in each EAR at EAR/APP-INF/lib.
Cheers
mbg
"Brian" <[email protected]> wrote in message
news:3eca93e0$[email protected]..
>
I'm using wls 8.1. I have an EAR in which several EJB interfaces areloaded from
the system classpath. After redeployment, these EJB's are not available.
java.rmi.NoSuchObjectException: Bean is already undeployed
I would have expected not to be able to affect any change in such EJBs viaredeployment,
but that redeployment would be successful. The console shows thatredeployment
for these EJBs is successful (i.e., status: active). So, do these classeshave
to be off the classpath for redeployment to work properly? Why doesn'tthe console
report their status correctly? Thanks...
..Brian

NoSuchObjectException when redeploying

I get the following exception when redeploying. Is this the expected
behavior?
<Jun 4, 2003 9:49:02 AM PDT> <Error> <Tracking> <402201> <EventService
failure w
hile attempting dispatch of Behavior Tracking event: Event [portalApp @
SessionE
ndEvent @ Wed Jun 04 09:49:02 PDT 2003 ]
{session-id=2eg5cRlzJqkX2l111Ok1ZOvZXZ2
WeupkzqCGT6mtmcgMX03XV2IS!-1740880684!1054744633146}.
java.rmi.NoSuchObjectException: Bean is already undeployed.
at
weblogic.ejb20.manager.BaseEJBManager.preInvoke(BaseEJBManager.java:9
5)
at
weblogic.ejb20.manager.StatelessManager.preInvoke(StatelessManager.ja
va:126)
at
weblogic.ejb20.internal.BaseEJBObject.preInvoke(BaseEJBObject.java:12
7)
at
weblogic.ejb20.internal.StatelessEJBObject.preInvoke(StatelessEJBObje
ct.java:61)
at
com.bea.p13n.events.internal.EventServiceBean_kh7q5h_EOImpl.dispatchE
vent(EventServiceBean_kh7q5h_EOImpl.java:29)
at
com.bea.p13n.tracking.TrackingEventHelper.dispatchEvent(TrackingEvent
Helper.java:96)
at
com.bea.p13n.tracking.listeners.SessionEventListener.sessionDestroyed
(SessionEventListener.java:87)
at
weblogic.servlet.internal.WebAppServletContext.notifySessionDestroyed
(WebAppServletContext.java:2312)
at
weblogic.servlet.internal.session.SessionData.remove(SessionData.java
:728)
at
weblogic.servlet.internal.session.MemorySessionContext.invalidateSess
ion(MemorySessionContext.java:61)
at
weblogic.servlet.internal.session.MemorySessionContext$SessionCleanup
Action.run(MemorySessionContext.java:121)
at
weblogic.security.service.SecurityServiceManager.runAs(SecurityServic
eManager.java:780)
at
weblogic.servlet.internal.session.MemorySessionContext.shutdown(Memor
ySessionContext.java:77)
at
weblogic.servlet.internal.WebAppServletContext.destroyServlets(WebApp
ServletContext.java:4884)
at
weblogic.servlet.internal.WebAppServletContext.shutdown(WebAppServlet
Context.java:4797)
at
weblogic.servlet.internal.ServletContextManager.removeContext(Servlet
ContextManager.java:156)
at
weblogic.servlet.internal.HttpServer.unloadWebApp(HttpServer.java:609
at
weblogic.servlet.internal.WebAppModule.rollback(WebAppModule.java:448
at
weblogic.j2ee.J2EEApplicationContainer.rollbackModule(J2EEApplication
Container.java:1624)
at
weblogic.j2ee.J2EEApplicationContainer.rollback(J2EEApplicationContai
ner.java:949)
at
weblogic.j2ee.J2EEApplicationContainer.rollback(J2EEApplicationContai
ner.java:932)
at
weblogic.j2ee.J2EEApplicationContainer.prepare(J2EEApplicationContain
er.java:584)
at
weblogic.management.deploy.slave.SlaveDeployer.processPrepareTask(Sla
veDeployer.java:1062)
at
weblogic.management.deploy.slave.SlaveDeployer.prepareUpdate(SlaveDep
loyer.java:730)
at
weblogic.drs.internal.SlaveCallbackHandler$1.execute(SlaveCallbackHan
dler.java:24)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:213)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:189)
>

i think your code that you mention has no problem. but in other part
here is some tips for that kind of exception
A NoSuchObjectException is thrown if an attempt is made to invoke a method on an object that no longer exists in the remote virtual machine. If a NoSuchObjectException occurs attempting to invoke a method on a remote object, the call may be retransmitted and still preserve RMI's "at most once" call semantics. A NoSuchObjectException is also thrown by the method java.rmi.server.RemoteObject.toStub and by the unexportObject methods of java.rmi.server.UnicastRemoteObject and java.rmi.activation.Activatable and

GetInstancesByFilter: Exception

Hi All,
I am facing some problem while filtering the instance by connecting to the engine.
I am using ALBPM 5.7 and for filtering using the Fuego API.
The exception I am getting is given below.
Process: SourceInitiateProcess
Task: Initialize
Exception Time: 08312010, 22:07 PDT
Message: Could not execute filter for any process.
Internal exceptions:albpmSvr: Cannot retrieve instances from engine 'albpmSvr'.
Caused by: Process execution engine execution error.
Caused by: Bean is already undeployed.
Exception:fuego.papi.exception.FilterBatchOperationException: Could not execute filter for any process. Internal exceptions: albpmSvr: Cannot retrieve instances from engine 'albpmSvr'. Caused by: Process execution engine execution error. Caused by: Bean is already undeployed. fuego.papi.exception.InstancesNotAvailableInEngineException: Cannot retrieve instances from engine 'albpmSvr'. at fuego.papi.impl.InstanceCache.getInstancesByFilter(InstanceCache.java:294) at fuego.papi.impl.ProcessServiceImpl.getInstancesByFilter(ProcessServiceImpl.java:1087) at fuego.papi.impl.ProcessServiceNESessionImpl.getInstancesByFilter(ProcessServiceNESessionImpl.java:755) at fuegoblock.papi.ProcessService.getInstancesByFilter(ProcessService.java:146) at xobject.Scheduler.DataService.SchedulerProcessService.sourcePollProcess(SchedulerProcessService.java:705) at SVB.SourceInitiateProcess.Default_1_0.Instance.CIL_initialize(Instance.java:812) at SVB.SourceInitiateProcess.Default_1_0.Instance.CIL_initialize(Instance.java:838) at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source) at java.lang.reflect.Method.invoke(Ljava.lang.Object;[Ljava.lang.Object;I)Ljava.lang.Object;(Unknown Source) at fuego.server.execution.EngineExecutionContext.invokeMethodAsCil(EngineExecutionContext.java:915) at fuego.server.execution.EngineExecutionContext.runCil(EngineExecutionContext.java:1076) at fuego.server.execution.TaskExecution.invoke(TaskExecution.java:389) at fuego.server.execution.TaskExecution.executeCIL(TaskExecution.java:490) at fuego.server.execution.TaskExecution.executeTask(TaskExecution.java:677) at fuego.server.execution.TaskExecution.executeTask(TaskExecution.java:638) at fuego.server.execution.TaskExecution.executeTask(TaskExecution.java:152) at fuego.server.execution.activities.XAutomatic.execute(XAutomatic.java:58) at fuego.metadata.Activity.execute(Activity.java:1040) at fuego.server.execution.ToDoItemAutomatic.execute(ToDoItemAutomatic.java:35) at fuego.server.execution.DefaultEngineExecution$AtomicExecutionTA.runTransaction(DefaultEngineExecution.java:291) Caused by: fuego.papi.impl.EngineExecutionException: Process execution engine execution error. at fuego.papi.impl.j2ee.EJBProcessControlHandler.doInvoke(EJBProcessControlHandler.java:153) at fuego.papi.impl.j2ee.EJBProcessControlHandler.doInvoke(EJBProcessControlHandler.java:118) at fuego.papi.impl.j2ee.EJBProcessControlHandler.doInvoke(EJBProcessControlHandler.java:118) at fuego.papi.impl.j2ee.EJBProcessControlHandler.doInvoke(EJBProcessControlHandler.java:118) at fuego.papi.impl.j2ee.EJBProcessControlHandler.doInvoke(EJBProcessControlHandler.java:118) at fuego.papi.impl.j2ee.EJBProcessControlHandler.doInvoke(EJBProcessControlHandler.java:118) at fuego.papi.impl.j2ee.EJBProcessControlHandler.invoke(EJBProcessControlHandler.java:66) at $Proxy47.getInstancesByFilter(Lfuego.papi.Filter;)Lfuego.papi.impl.FilterResult;(Unknown Source) at fuego.papi.impl.InstanceCache.getInstancesByFilter(InstanceCache.java:554) at fuego.papi.impl.InstanceCache.getInstancesByFilter(InstanceCache.java:247) ... 19 more Caused by: java.rmi.NoSuchObjectException: Bean is already undeployed. at weblogic.ejb.container.manager.BaseEJBManager.preInvoke(BaseEJBManager.java:141) at weblogic.ejb.container.manager.StatelessManager.preInvoke(StatelessManager.java:127) at weblogic.ejb.container.internal.BaseEJBObject.preInvoke(BaseEJBObject.java:213) at weblogic.ejb.container.internal.StatelessEJBObject.preInvoke(StatelessEJBObject.java:64) at fuego.ejbengine.EJBProcessControlAdapter_1cf85o_EOImpl.getInstancesByFilter(EJBProcessControlAdapter_1cf85o_EOImpl.java:1983) at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source) at java.lang.reflect.Method.invoke(Ljava.lang.Object;[Ljava.lang.Object;I)Ljava.lang.Object;(Unknown Source) at fuego.papi.impl.AbstractProcessControlHandler.invokeInternal(AbstractProcessControlHandler.java:48) at fuego.papi.impl.j2ee.EJBProcessControlHandler.doInvoke(EJBProcessControlHandler.java:111) at fuego.papi.impl.j2ee.EJBProcessControlHandler.doInvoke(EJBProcessControlHandler.java:118) at fuego.papi.impl.j2ee.EJBProcessControlHandler.doInvoke(EJBProcessControlHandler.java:118) at fuego.papi.impl.j2ee.EJBProcessControlHandler.doInvoke(EJBProcessControlHandler.java:118) at fuego.papi.impl.j2ee.EJBProcessControlHandler.doInvoke(EJBProcessControlHandler.java:118) at fuego.papi.impl.j2ee.EJBProcessControlHandler.doInvoke(EJBProcessControlHandler.java:118) at fuego.papi.impl.j2ee.EJBProcessControlHandler.invoke(EJBProcessControlHandler.java:66) at $Proxy47.getInstancesByFilter(Lfuego.papi.Filter;)Lfuego.papi.impl.FilterResult;(Unknown Source) at fuego.papi.impl.InstanceCache.getInstancesByFilter(InstanceCache.java:554) at fuego.papi.impl.InstanceCache.getInstancesByFilter(InstanceCache.java:247) at fuego.papi.impl.ProcessServiceImpl.getInstancesByFilter(ProcessServiceImpl.java:1087) at fuego.papi.impl.ProcessServiceNESessionImpl.getInstancesByFilter(ProcessServiceNESessionImpl.java:755) at fuegoblock.papi.ProcessService.getInstancesByFilter(ProcessService.java:146) at xobject.Scheduler.DataService.SchedulerProcessService.sourcePollProcess(SchedulerProcessService.java:705)
Bibhu

Hi,
we are getting same type of issue as below...
Caused by: fuego.papi.exception.FilterBatchOperationException: Could not execute filter for any process.
Internal Exceptions:
XBB_PROD6_MRI_ENGINE_6:Cannot retrieve instances from engine 'XBB_PROD6_MRI_ENGINE_6'.
at fuego.papi.impl.InstanceCache.getInstancesByFilter(InstanceCache.java:345)
at fuego.papi.impl.ProcessServiceImpl.getInstancesByFilter(ProcessServiceImpl.java:1469)
at fuego.papi.impl.ProcessServiceSessionImpl.processesGetInstancesByFilter(ProcessServiceSessionImpl.java:2099)
at com.jpmorgan.gcrm.bpm.albpm.utils.PapiWS.isInstanceExist(PapiWS.java:576)
Please help me out... Thanks in advance..

Redeployment - EJBs on Classpath

I'm using wls 8.1. I have an EAR in which several EJB are loaded from the system
classpath. After redeployment, these EJB's are not available.
java.rmi.NoSuchObjectException: Bean is already undeployed
I would have expected not to be able to affect any change in such EJBs via redeployment,
but that redeployment would be successful. The console shows that redeployment
for these EJBs is successful (i.e., status: active). Do these classes have to
be off the classpath for redeployment to work properly? Why doesn't the console
report their status correctly? Thanks...
..Brian

Rob Woollen <[email protected]> wrote:
Brian wrote:
Rob Woollen <[email protected]> wrote:
I believe you are right. Unfortunately the calling application isnot really
a client but the security provider. So, I've put everything our realmcode needs
on the server's classpath. I've also tried taking it off the classpathand putting
it in the providers.jar, but no joy. In that case, a ClassCast exceptionis thrown
on the narrow. So, my problem seems to be that I don't know how tohandle the
situation where my login module makes EJB calls. Is there any wayto refresh
the providers.jar?Does your security provider cache the EJB stub? I believe if you
re-lookup the home in JNDI and get a new stub that it should work fine
without refreshing the providers.jar (assuming the new EJB didn't change
the interface.)
Yes, I am (was) caching the stub. Yes, re-looking up the home cures the problem.
Thanks.
-- Rob
Thanks...
..Brian
-- Rob
I would have expected not to be able to affect any change in such
EJBs
via redeployment,
but that redeployment would be successful. The console shows that
redeployment
for these EJBs is successful (i.e., status: active). Do these classeshave to
be off the classpath for redeployment to work properly? Why doesn'tthe console
report their status correctly? Thanks...
..Brian

Multiple instances of the same bean class in session?

I�m trying to think of a way to have multiple instances of the same bean class in session scope using JSF. For example, let�s say that I have two <h:dataTable>s on the same page. They both use the backing bean called genericBean. Now, the content for genericBean will be different for each <h:dataTable>. In fact, the data source that backs genericBean is not known until runtime. It could be a database, web service, etc.
What I would like is for when JSF needs access genericBean instead of looking for the value with key �genericBean� in the session map it looks for �genericBean_[some runtime ID]�. I could specify this id in EL on a custom component, as a request parameter or whatever.
I think that I need the bean to be in session scope because the tables are complex and I want them to be editable.
I have some ideas about how I can do this but I was wondering if someone has already solved this problem or if there is a standard way to do this using tools like Shale, etc.
Thanks,
Randy

Well, I came up with an interesting solution to this so I thought that I would post it here.
I have a page that looks like this.
<html>
<head>
<title>My Page</title>
</head>
<body>
<f:view>
<f:subview id="component1">
<jsp:include page="component.jsp">
<jsp:param name="id" value="a" />
</jsp:include>
</f:subview>
<hr>
<f:subview id="component2">
<jsp:include page="component.jsp">
<jsp:param name="id" value="b" />
</jsp:include>
</f:subview>
</f:view>
</body>
</html>
And component.jsp looke like this.
<f:verbatim>
<p>
<h1>Component
</f:verbatim>
<h:outputText value=" #{param.id}" />
<f:verbatim>
</h1>
</p>
</f:verbatim>
<h:form>
<h:outputText value="#{component.id}" />
<h:outputText value="#{component.value}" />
<h:commandButton value="increment" action="#{component.increment}" />
<h:commandButton value="decrement" action="#{component.decrement}" />
<f:verbatim>
<input type="hidden" name="id"
value="</f:verbatim><h:outputText value="#{param.id}"/><f:verbatim>" />
</f:verbatim>
</h:form>
The idea is that I want component.jsp to be initialized differently based on the id param. The component managed bean is configured to be in session scope but I want the component instance for id a and id b to be different instances in session scope. Therefore, I added a custom variable resolver to handle this.
public Object resolveVariable(FacesContext context, String name) {
// This id will be different for the different subviews.
HttpServletRequest request = (HttpServletRequest) context.getExternalContext() .getRequest();
String id = request.getParameter("id");
// If there is an id in the request then check if this is a bean that can have multiple
// instances in session scope.
if ((id != null) && (id.length() > 0)) {
ExternalContext ec = context.getExternalContext();
// Build the new name for the key of this bean
String newName = name + "_" + id;
Object value = null;
// See if the bean instance already esists.
if ((null == (value = ec.getRequestMap().get(newName))) &&
(null == (value = ec.getSessionMap().get(newName))) &&
(null == (value = ec.getApplicationMap().get(newName)))) {
     // We could not find the bean instance in scope so create the bean
     // using the standard variable resolver.
value = original.resolveVariable(context, name);
// Now check if the bean implements that page component interface. If it is
// a page component then we want to rename the key to access this bean so
// that the instance is only used when the id is provided in the request.
// For example, if there are two components (a and b) we will have in session scope
// component_a and component_b. The will each point to a unique instance of the
// Component bean class.
if (value instanceof PageComponent) {
// Try to get the value again
if (null != (value = ec.getRequestMap().get(name))) {
     // Initialize the bean using the id
((PageComponent) value).initInstance(id);
ec.getRequestMap().remove(name);
ec.getRequestMap().put(newName, value);
} else if (null != (value = ec.getSessionMap().get(name))) {
((PageComponent) value).initInstance(id);
ec.getSessionMap().remove(name);
ec.getSessionMap().put(newName, value);
} else if (null != (value = ec.getApplicationMap().get(name))) {
((PageComponent) value).initInstance(id);
ec.getApplicationMap().remove(name);
ec.getApplicationMap().put(newName, value);
return value;
return original.resolveVariable(context, name);
}

Question about main difference between Java bean and Java class in JSP

Hi All,
I am new to Java Bean and wonder what is the main difference to use a Bean or an Object in the jsp. I have search on the forum and find some post also asking the question but still answer my doubt. Indeed, what is the real advantage of using bean in jsp.
Let me give an example to illustrate my question:
<code>
<%@ page errorPage="errorpage.jsp" %>
<%@ page import="ShoppingCart" %>

<jsp:useBean id="cart" scope="session" class="ShoppingCart" />
<html>
<head><title>Shopping Cart</title></head>
<body bgcolor="#FFFFFF">
Your cart's ID is: <%=cart.getId()%>.
</body>
<html>
</code>
In the above code, I can also create a object of ShoppingCart by new operator then get the id at the following way.
<code>
<%
ShoppingCart cart = new ShoppingCart();
out.println(cart.getId());
%>
</code>
Now my question is what is the difference between the two method? As in my mind, a normal class can also have it setter and getter methods for its properties. But someone may say that, there is a scope="session", which can be declared in an normal object. It may be a point but it can be easily solved but putting the object in session by "session.setAttribute("cart", cart)".
I have been searching on this issue on the internet for a long time and most of them just say someting like "persistance of state", "bean follow some conventions of naming", "bean must implement ser" and so on. All of above can be solved by other means, for example, a normal class can also follow the convention. I am really get confused with it, and really want to know what is the main point(s) of using the java bean.
Any help will be highly apprecaited. Thanks!!!
Best Regards,
Alex

Hi All,
I am new to Java Bean and wonder what is the main
difference to use a Bean or an Object in the jsp. The first thing to realize is that JavaBeans are just Plain Old Java Objects (POJOs) that follow a specific set of semantics (get/set methods, etc...). So what is the difference between a Bean and an Object? Nothing.
<jsp:useBean id="cart" scope="session" class="ShoppingCart" />
In the above code, I can also create a object of
ShoppingCart by new operator then get the id at the
following way.
ShoppingCart cart = new ShoppingCart();
out.println(cart.getId());
...Sure you could. And if the Cart was in a package (it has to be) you also need to put an import statement in. Oh, and to make sure the object is accessable in the same scope, you have to put it into the PageContext scope. And to totally equal, you first check to see if that object already exists in scope. So to get the equivalant of this:
<jsp:useBean id="cart" class="my.pack.ShoppingCart"/>Then your scriptlet looks like this:
<%@ page import="my.pack.ShoppingCart %>
<%
ShoppingCart cart = pageContext.getAttribute("cart");
if (cart == null) {
    cart = new ShoppingCart();
    pageContext.setAttribute("cart", cart);
%>So it is a lot more work.
As in my mind, a normal class can also
have it setter and getter methods for its properties.True ... See below.
But someone may say that, there is a scope="session",
which can be declared in an normal object.As long as the object is serializeable, yes.
It may be
a point but it can be easily solved but putting the
object in session by "session.setAttribute("cart",
cart)".Possible, but if the object isn't serializable it can be unsafe. As the point I mentioned above, the useBean tag allows you to check if the bean exists already, and use that, or make a new one if it does not yet exist in one line. A lot easier than the code you need to use otherwise.
I have been searching on this issue on the internet
for a long time and most of them just say someting
like "persistance of state", "bean follow some
conventions of naming", "bean must implement ser" and
so on. Right, that would go along the lines of the definition of what a JavaBean is.
All of above can be solved by other means, for
example, a normal class can also follow the
convention. And if it does - then it is a JavaBean! A JavaBean is any Object whose class definition would include all of the following:
1) A public, no-argument constructor
2) Implements Serializeable
3) Properties are revealed through public mutator methods (void return type, start with 'set' have a single Object parameter list) and public accessor methods (Object return type, void parameter list, begin with 'get').
4) Contain any necessary event handling methods. Depending on the purpose of the bean, you may include event handlers for when the properties change.
I am really get confused with it, and
really want to know what is the main point(s) of
using the java bean.JavaBeans are normal objects that follow these conventions. Because they do, then you can access them through simplified means. For example, One way of having an object in session that contains data I want to print our might be:
<%@ page import="my.pack.ShoppingCart %>
<%
ShoppingCart cart = session.getAttribute("cart");
if (cart == null) {
    cart = new ShoppingCart();
    session.setAttribute("cart", cart);
%>Then later where I want to print a total:
<% out.print(cart.getTotal() %>Or, if the cart is a JavaBean I could do this:
<jsp:useBean id="cart" class="my.pack.ShoppingCart" scope="session"/>
Then later on:
<jsp:getProperty name="cart" property="total"/>
Or perhaps I want to set some properties on the object that I get off of the URL's parameter group. I could do this:
<%
ShoppingCart cart = session.getAttribute("cart");
if (cart == null) {
    cart = new ShoppingCart();
    cart.setCreditCard(request.getParameter("creditCard"));
    cart.setFirstName(request.getParameter("firstName"));
    cart.setLastName(request.getParameter("lastName"));
    cart.setBillingAddress1(request.getParameter("billingAddress1"));
    cart.setBillingAddress2(request.getParameter("billingAddress2"));
    cart.setZipCode(request.getParameter("zipCode"));
    cart.setRegion(request.getParameter("region"));
    cart.setCountry(request.getParameter("country"));
    pageContext.setAttribute("cart", cart);
    session.setAttribute("cart", cart);
}Or you could use:
<jsp:useBean id="cart" class="my.pack.ShoppingCart" scope="session">
<jsp:setProperty name="cart" property="*"/>
</jsp:useBean>The second seems easier to me.
It also allows you to use your objects in more varied cases - for example, JSTL (the standard tag libraries) and EL (expression language) only work with JavaBeans (objects that follow the JavaBeans conventions) because they expect objects to have the no-arg constuctor, and properties accessed/changed via getXXX and setXXX methods.
>
Any help will be highly apprecaited. Thanks!!!
Best Regards,
Alex

Execute a bean method on page entry

Hi all,
When I have a page with a backing bean on the request, then I know for sure that that bean will have its constructor called and executed when the page loads. That enables me to do some initialisation in the constructor.
Now I have a page with a bean on session context. However, now the bean is already there (most of the time) so the constructor isn't called.
Is there a (simple) way so that I can call a method of my bean every time my jsp page is loaded?
Thank you,
Steven

Thanks,
I still have a problem though.
I thought of initialising my bean before the apply request phase, but it seems that this phase gets skipped when my page loads for the first time. In fact my beforePhase method only gets executed just before the render response (my method doesn't really contain a lot, I just found out by debugging).
Any ideas how I could resolve this, as in: how can I fire this method everytime my page is accessed?
Thanks
Steven

Managed Bean Best Practices

Hi
Are there any best practices for using Managed Beans?
We plan to use our own custom-built JSF components. Need to understand how to design backing beans for performance/effort optimization.
For example :
1. How to make managed beans thread-safe for concurrent requests, without compromising on efficiency/speed?
2. How to enforce the J2EE security with managed-beans?
3. How to decide the scope of these beans to ensure minimal data-storage in session?
4. How to decide the granularity at which a managed-bean should be used for example :
4.1 One bean-per-component
Advantages :
a) if complex components require special data-holding/processing/event-handling capabilities from bean
(e.g. datagrid model,tree model,menu model)
Problems :
- with multiple components in a page/form
a) it becomes tedious to debug/change/track which bean serves which component
b) if session scope is required, too many beans will be cached in session
c) unnecessarily too many beans will be created on server (= n pages * m components-per-page)
d) unnecessarily increases the length of faces-config.xml
4.2 One bean-per-form
Advantages :
a) in multi-form web pages, to ensure the functional behaviour of each form is separate/modular in its own bean.
b) each managed-bean would map to specific/meaningful functionality/user-interaction in use-case.
Problems :
- if form includes complex components (datagrid/tree/menu) requiring a specialised bean class, then
a) either one of the specialized bean has to be augmented with additional logic to handle data/events for all other components within the form
(Not good, as it mixes-up the responsibilities of component-specific-beans, and the bean may no more be reusable in another form)
b) or without using component-specific beans, only single form bean should handle the data/events for all components in the form?
(Neither good, since if a complex tree-compoent is reused in multiple forms, then the logic to handle data/events for such a component will be repeated in those many form-specific managed beans)
4.3 One bean-per-page
Advantages :
a) seems more modular/meaningful way - since a page would map to some feature within the use-case
b) bean will contain only behaviour which is relevent for the associated page/function within use-case
Problems :
a) in multi-form pages, can single bean handle data/events for multiple forms?
b) if page uses complex component (e.g datagrid, tree) that needs its own bean - how does page-bean exchange data with component-bean?
Thanks,
Arti

Are there any best practices for using Managed
Beans?There are no best practices for using Managed Beans in terms of Sun, or other vendors recommendations. But there are some patterns that can be applied to the managed beans (The managed bean is already a pattern). Also common sense is allways a good practice.
For example, the managed bean should not have business logic code, only presentation logic code, etc.
1. How to make managed beans thread-safe for
concurrent requests, without compromising on
efficiency/speed?The beans can be created by request, so concurrency is not an issue. If they are session scope, also is not an issue because, a user can only have one thread running. Only in application scope you must have carefull.
>
2. How to enforce the J2EE security with
managed-beans?see this:
http://jsf-security.sourceforge.net/
About jsf-security
>
3. How to decide the scope of these beans to ensure
minimal data-storage in session?If you wnat minimal data-storage in session the answer is request or none.
In question 4, you make the question and give the answer ;-)

Jdev EA1 return error in running an already tested war file (imported war )

Hi
Thank you for reading my post.
I have an Odd problem with Jdev EA1
I have a war file , I import it into Jdev (new /project/projects from war file)
I should mention that this war file developed in Rational application developer (Struts based ,database, higly use of other Taglibs)
Now when i try to run my imported application , it does not run at all, it stops with some errors :
for example in compiler log it return error for following line :
     <logic:redirect page="<%=session.getAttribute("LastPage").toString() %>" />
[/Code]
the error is :
     Error(29): Attribute: LastPage").toString() is not a valid attribute name
        Error(29): Attribute: % is not a valid attribute name
        Error(30): Encountered end tag </logic:present> without corresponding start tag.
Also it returns :
     Error(32): Tag attempted to define a bean which already exists: currentModel
        Error(33): Tag attempted to define a bean which already exists: currentName
for the following code :
[CODE]
<logic:equal name="Language" value="en">
     <SCRIPT SRC="language-en.js"></SCRIPT>    /////line 32
     <SCRIPT SRC="ctst.js"></SCRIPT>               ////line 33
</logic:equal>I import it into netbeans and it run correctly on tomcat, i deploy it inot sun Java apps and it works ok.
Even i tried Jboss , geronimo to test my application corectness
Can you tell me what is wrong ?

Hi
I think its serious , Jdev Does not works correctly with a correct war file ,
some one from Jdev team should think about it.

Bean on already undeployed

Similar Messages

Maybe you are looking for