[Spring Integration] - ClassLoader inside deloyed bean cannot find existing class
by ivanyuan
Hi Guru,
With the help from spring integration community, I can successfully deploy spring beans using deployer release 2.5 (jdk5) in JBoss 4.2.2GA and I can also access the deployed beans from another web application.
However I am running into a problem of using ClassLoader inside the deployed spring beans.
>From my web application, I can get bean reference called "billingBean". However when I invoke one method of this bean, which will dynamically create some instances using classloader, I got "java.lang.ClassNotFoundException", and the stacktrace is as below:
| 2009-Nov-23 14:53:17] ERROR - java.lang.ClassNotFoundException: com.iseemedia.provisioningbilling.actionflow.action.AddSubscriptionAction
|
| [2009-Nov-23 14:53:17] ERROR - at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
|
| [2009-Nov-23 14:53:17] ERROR - at java.security.AccessController.doPrivileged(Native Method)
|
| [2009-Nov-23 14:53:17] ERROR - at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
|
| [2009-Nov-23 14:53:17] ERROR - at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
|
| [2009-Nov-23 14:53:17] ERROR - at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268)
|
| [2009-Nov-23 14:53:17] ERROR - at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
|
| [2009-Nov-23 14:53:17] ERROR - at com.iseemedia.provisioningbilling.actionflow.ActionFlow.buildFlow(ActionFlow.java:49)
|
| [2009-Nov-23 14:53:17] ERROR - at com.iseemedia.provisioningbilling.actionflow.ActionFlow.<init>(ActionFlow.java:26)
|
| [2009-Nov-23 14:53:17] ERROR - at com.iseemedia.provisioningbilling.actionflow.ActionFlowFactory.getActionFlow(ActionFlowFactory.java:49)
|
| [2009-Nov-23 14:53:17] ERROR - at com.iseemedia.provisioningbilling.session.SessionManagement.createSession(SessionManagement.java:173)
|
| [2009-Nov-23 14:53:17] ERROR - at com.iseemedia.provisioningbilling.impl.ProvisioningBillingImpl.asyncSubscribe(ProvisioningBillingImpl.java:219)
|
| [2009-Nov-23 14:53:17] ERROR - at com.iseemedia.provisioningbilling.intf.ServiceBillingAdapter.subscribe(ServiceBillingAdapter.java:171)
|
| [2009-Nov-23 14:53:17] ERROR - at com.iseemedia.subscription.common.WebServiceBillingAdapter.subscribeRequest(WebServiceBillingAdapter.java:47)
|
| [2009-Nov-23 14:53:17] ERROR - at com.iseemedia.subscription.webservice.SubscriptionWS.manageSubscription(SubscriptionWS.java:108)
|
| [2009-Nov-23 14:53:17] ERROR - at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
|
| [2009-Nov-23 14:53:17] ERROR - at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
|
| [2009-Nov-23 14:53:17] ERROR - at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
|
| [2009-Nov-23 14:53:17] ERROR - at java.lang.reflect.Method.invoke(Method.java:585)
|
| [2009-Nov-23 14:53:17] ERROR - at org.apache.cxf.service.invoker.AbstractInvoker.performInvocation(AbstractInvoker.java:166)
|
| [2009-Nov-23 14:53:17] ERROR - at org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:82)
|
| [2009-Nov-23 14:53:17] ERROR - at org.apache.cxf.jaxrs.JAXRSInvoker.invoke(JAXRSInvoker.java:122)
|
| [2009-Nov-23 14:53:17] ERROR - at org.apache.cxf.jaxrs.JAXRSInvoker.invoke(JAXRSInvoker.java:70)
|
| [2009-Nov-23 14:53:18] ERROR - at org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:58)
|
| [2009-Nov-23 14:53:18] ERROR - at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:417)
|
| [2009-Nov-23 14:53:18] ERROR - at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
|
| [2009-Nov-23 14:53:18] ERROR - at java.util.concurrent.FutureTask.run(FutureTask.java:123)
|
| [2009-Nov-23 14:53:18] ERROR - at org.apache.cxf.workqueue.SynchronousExecutor.execute(SynchronousExecutor.java:37)
|
| [2009-Nov-23 14:53:18] ERROR - at org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:98)
|
| [2009-Nov-23 14:53:18] ERROR - at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:236)
|
| [2009-Nov-23 14:53:18] ERROR - at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:104)
|
| [2009-Nov-23 14:53:18] ERROR - at org.apache.cxf.transport.servlet.ServletDestination.invoke(ServletDestination.java:99)
|
| [2009-Nov-23 14:53:18] ERROR - at org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:352)
|
| [2009-Nov-23 14:53:18] ERROR - at org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:144)
|
| [2009-Nov-23 14:53:18] ERROR - at org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXFServlet.java:163)
|
| [2009-Nov-23 14:53:18] ERROR - at org.apache.cxf.transport.servlet.AbstractCXFServlet.doGet(AbstractCXFServlet.java:145)
|
| [2009-Nov-23 14:53:18] ERROR - at javax.servlet.http.HttpServlet.service(HttpServlet.java:690)
|
| [2009-Nov-23 14:53:18] ERROR - at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
|
| [2009-Nov-23 14:53:18] ERROR - at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
|
| [2009-Nov-23 14:53:18] ERROR - at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
|
| [2009-Nov-23 14:53:18] ERROR - at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
|
| [2009-Nov-23 14:53:18] ERROR - at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
|
| [2009-Nov-23 14:53:18] ERROR - at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
|
| [2009-Nov-23 14:53:18] ERROR - at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
|
| [2009-Nov-23 14:53:18] ERROR - at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
|
| [2009-Nov-23 14:53:18] ERROR - at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:179)
|
| [2009-Nov-23 14:53:18] ERROR - at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
|
| [2009-Nov-23 14:53:18] ERROR - at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
|
| [2009-Nov-23 14:53:18] ERROR - at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
|
| [2009-Nov-23 14:53:18] ERROR - at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
|
| [2009-Nov-23 14:53:18] ERROR - at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
|
| [2009-Nov-23 14:53:18] ERROR - at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:262)
|
| [2009-Nov-23 14:53:18] ERROR - at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
|
| [2009-Nov-23 14:53:18] ERROR - at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
|
| [2009-Nov-23 14:53:18] ERROR - at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:446)
|
| [2009-Nov-23 14:53:18] ERROR - at java.lang.Thread.run(Thread.java:595)
|
|
The not-found-class, com.iseemedia.provisioningbilling.actionflow.action.AddSubscriptionAction actually is inside the spring archive file. I also tried to copy the spring archive file to default/lib (of course, I renamed it as *.jar), I still got same exception.
Here is the snapshot of my code that will dynamically create some instances. This piece of code worked fine before using the spring deployer.
| HashMap<String, Action> aMap = new HashMap<String, Action>();
| for (String key : flowDef.getActionMap().keySet())
| {
| ActionDef aDef = flowDef.getActionMap().get(key);
|
| Action a = (Action)ClassLoader.getSystemClassLoader().loadClass(aDef.getType()).newInstance();
| aMap.put(key, a);
| }
|
The bold line is the actual cause of the exception. I just wonder which class loader I should use inside a deployed bean?
Thanks in advance,
Ivan Yuan
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4267155#4267155
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4267155
14 years, 10 months
SFSB "different tx context" transaction error on jboss 4.2.X
by Will Milspec
Hi all,
We have an transaction error that has recently appeared consistently: a
stateful session bean (SFSB) has an application error and throws an
exception. The next time the application tries to use the stateful session
bean it gets an error:
tried to enter Stateful bean with different tx context,
contextTx: TransactionImple
< ac, BasicAction: a640128:983:4af49b0f:299 status:
ActionStatus.RUNNING >,
methodTx: TransactionImple
< ac, BasicAction: a640128:983:4af49b0f:348 status:
ActionStatus.RUNNING >
Revewing the ejb literature, I see that if the SFSB throws a SystemException
(eg. EJBException) w, cause the app server will discard the SFSB instance.
Currently the SFSB throws an application exception. This seems like a
straightforward fix.
This code has been in place for a few years, and we've been running jboss
4.2. for a few years. So we're a bit puzzled "why now?"
One change: we have recently upgraded the jdbc drivers (mssql) from to
microsoft's version 1.1 to 2.0. The 1.2-and-later-driver handles
transaction-id's-in-the-jdbc-connection differently than the earlier 1.1
drivers. (The jdbc connection implementation actually keeps a reference to
the current transaction id in the database. After we upgraded the driver, we
saw another problem where bad exception handling kept a stale 'mssql
transaction id' around in the jdbc connection. Properly closing the result
set/stmt/connection upon error solved this jdbc
transaction-id-hanging-around problem).
After reviewing the jboss 4.2.3 code, however, I suspect that the 'jdbc
driver version' change may in not in fact pertain at all to our stateful
session bean problem, i.e. it's a 'red herring',. The
arjuna/user-transaction/statefulsession code does not even touch the jdbc
driver. Unless I missed something
So a few follow-in questions. Can anyone comment/weigh-in/opine/pontificate:
* whether they've seen this issue?
* throwing EJBException's will solve this problem
* comment
* any tips for debugging solving these types of problems?
thanks,
bill
14 years, 10 months
[jBPM Users] - Re: How to use timers?
by kukeltje
First of all, let me point you to http://catb.org/~esr/faqs/smart-questions.html#volume
Personally, when I started reading your post and encounter very basic questions with statements that are plain wrong (see further on, and my previous post) in combination with LOTS of data (will not call it information), I really hesitate to respond, but since I'm in a really good mood
anonymous wrote : The first problem I encounter is a "service 'scheduler' unavailable" error. Searching on the net I found some hints like "start the scheduler" or "change the configuration in src/main/config/jbpm.cfg.xml.
Isn't the internet great
anonymous wrote : But nobody explains WHAT is the scheduler,
Are you serious? You did not ever get the impression that it is used to execute timers? Strange since you have a problem with timers and a message that the scheduler is unavailable and you started searching in this direction. Oh, and it is in the first chapter of the user docs: http://docs.jboss.org/jbpm/v3/userguide/introduction.html#d0e130
anonymous wrote : how to start it, etc..
Besides in the docs: http://docs.jboss.org/jbpm/v3/userguide/deployment.html#webapplication
Very little searching yielded
http://www.jboss.org/index.html?module=bb&op=viewtopic&t=80078&postdays=0...
and many more links
anonymous wrote : However, after some trials and debugging sessions I found that the solution to this problem is another one: you need to create a JbpmContext by yourself:
This is also very basic jBPM stuff and in almost all examples, getting started. So I it sounds strange to me that you only found this out through debugging.
anonymous wrote : However, as I'm working with no database at all, I wouldn't expect that.
You yourself might not be, but does it come as a surprise that jBPM might need one? jBPM is a statemachine, mainly for workflow, so long running processes. Most people would like that state to be persistent to survive a crash or restart. Most systems use a database for this (as does jBPM).
I hope this already helps you as I did not look into your two specific cases.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4267134#4267134
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4267134
14 years, 10 months