Well the problem was solved, apparently this is an issue of jboss-client-proxy who caches response objects.
The solution, share all the EJB-client-proxies between all applications putting the jars in tomcat share folders. Thanks Tonio wrote: > > Thanks Brice, > > Really I didn't know about this classloader problem, hope it is > because I'm enough tidy to put only the needed jars :-) (probably it was > just good luck only). > > I'm sure there is only one place from where the class is loaded > (users.jar in the war file, and nowhere else), but of course the problem > is, that if after waiting 60 seconds (new tests reveals 45 seconds too) > it works, the problem must come from elsewhere. > > I revised all my code to be sure classloader problem didn't happen, your > e-mail was a good excuse for that. > > Thanks again, > and Happy New Year anywhere in the world you are > tonio > > > On Fri, 2006-12-29 at 11:28 -0600, Ruth, Brice D wrote: >> This smells of a classloader problem. I'm no expert in this area, but if >> you have the same class loaded by two classloaders, you'll get a >> ClassCastException when an object of that class is passed between the >> objects instantiated from two different classloaders. >> >> For example, if in one classloader, you have an object that does a new >> MyClass() and then you pass that object to a method on an object from a >> different classloader, which takes (MyClass obj) as a parameter, when >> that method is invoked, you'll get a ClassCastException, even if the >> class is loaded from the same JARs, the same .class file, or whatever. >> >> I'm not sure where the timing you've indicated would play into this >> scenario, but this smells like a classloader issue of some sort. >> >> I know in JBoss you can use a unified classloader, and you can get the >> embedded Tomcat that JBoss uses to also use the JBoss classloader - not >> sure if that would help in this situation (probably not, since you have >> different VMs). >> >> Hope this helps in some small way. >> >> Cheers, >> Brice >> >> -----Original Message----- >> From: Tonio [mailto:[EMAIL PROTECTED] >> Sent: Friday, December 29, 2006 11:03 AM >> To: [email protected] >> Subject: [xfire-user] Tomcat/Jboss problem >> >> >> >> Hi, >> >> A very strange problem accesing JBoss from Tomcat running in differente >> JVM. >> >> Jboss 4.0.5 >> tomcat 5.5.17 >> jvm 1.5.08 >> xfire 1.2.3 >> >> I'll describe my instalation: >> >> Jboss -> Stateless-Session userAuthorization >> -> Stateless-Session calculator >> >> tomcat (in differente JVM) front end to jboss Stateless-Session >> >> tomcat has in it's share class-loader all jboss-client jars (except >> jws), and then >> all xfire jars (in that order) >> >> When a user needs to run a service this needs to be done: >> >> Obtain a ticket from web-service userAuthorization >> The web-service obtains a ticket calling EJB >> userAuthorization >> >> Use this ticket to call calculator's methods (example >> add(ticket, >> num, num)) >> The web-service validates ticket against EJB >> userAuthorization >> call the corresponding calculator >> method >> >> The problem: >> The consumer obtain the ticket without problem >> When he tries to call the calculator method, the ticket >> validation >> gives a strange ClassCastException in Jboss generated Proxy. >> >> if I wait 60 seconds between the 2 calls all works fine (????) >> if I wait less than 60 seconds, the same problem appears. >> >> What I tested: >> I make a client calling directly jboss from java, all works ok >> I make a standard servlet deployed in my tomcat that receives >> an URL and does the two calls, it worked ok >> I make a WS-Client the problem appears >> I tried with soapui the problem appears >> >> >> Any ideas where or what to look for will be greatly apreciatted. >> Thanks in advance >> tonio > > > --------------------------------------------------------------------- > To unsubscribe from this list please visit: > > http://xircles.codehaus.org/manage_email > > > -- View this message in context: http://www.nabble.com/Tomcat-Jboss-problem-tf2895466.html#a8148761 Sent from the XFire - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email
