# ClassCastException: $Proxy



## GartenUmgraben (23. Mai 2005)

Ich bin etwas ratols. Ich will über Servlet und Session Bean  / EntityBean einen Datenbankzugriff realisieren. Nun habe ich eine EJB für je eine Tabelle (Person und Konto) in der DB. Starte ich die Anwendung so kann ich z.B. eine Konto anlegen(geht alles) ...will ich eine weitere anlegen (sprich im Browser zurück und das Formular zum anlegen nochmnal ausgefüllt)  kommt die Exception (sieh unten) gleiches gilt für Person (ensprechende Exception). Soll heissen ich kann für jede EJB jeweils eine Aktion durchführen....danach (bei einem zweiten Versuch) kommt immer die Exception. Ich werd daraus nicht schlau. Eine erneute Asuführung wird erst durch eine neues deployen möglich..aba danach gehts auch wieder je nur einmal  :-//





2005-05-23 11:41:37,337 ERROR [org.jboss.ejb.plugins.LogInterceptor] RuntimeException in method: public abstract void DB_2.ejb.Service.interfaces.KontoService.createKonto(java.lang.Integer,java.lang.String,java.lang.Integer) throws java.rmi.RemoteException:
java.lang.ClassCastException: $Proxy54
	at DB_2.ejb.Service.ServiceLocator.lookup(ServiceLocator.java:46)
	at DB_2.ejb.Service.KontoServiceBean.createKonto(KontoServiceBean.java:96)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:585)
	at org.jboss.invocation.Invocation.performCall(Invocation.java:345)
	at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:214)
	at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:185)
	at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:113)
	at org.jboss.webservice.server.ServiceEndpointInterceptor.invoke(ServiceEndpointInterceptor.java:51)
	at org.jboss.ejb.plugins.CallValidationInterceptor.invoke(CallValidationInterceptor.java:48)
	at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:105)
	at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:313)
	at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:146)
	at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:122)
	at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:192)
	at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:122)
	at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:624)
	at org.jboss.ejb.Container.invoke(Container.java:870)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:585)
	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:144)
	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:249)
	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:642)
	at org.jboss.invocation.local.LocalInvoker$MBeanServerAction.invoke(LocalInvoker.java:155)
	at org.jboss.invocation.local.LocalInvoker.invoke(LocalInvoker.java:104)
	at org.jboss.invocation.InvokerInterceptor.invokeLocal(InvokerInterceptor.java:115)
	at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:101)
	at org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java:46)
	at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:55)
	at org.jboss.proxy.ejb.StatelessSessionInterceptor.invoke(StatelessSessionInterceptor.java:97)
	at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:91)
	at $Proxy63.createKonto(Unknown Source)
	at DB_2.ejb.Client.AdminServlet.doGet(AdminServlet.java:165)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:697)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
	at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:75)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:186)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:214)
	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
	at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:198)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:152)
	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
	at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:66)
	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
	at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:150)
	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
	at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:54)
	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137)
	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:118)
	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
	at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:929)
	at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:160)
	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:799)
	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:705)
	at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:577)
	at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:683)
	at java.lang.Thread.run(Thread.java:595)


----------



## Thomas Darimont (23. Mai 2005)

Hallo!



> at DB_2.ejb.Service.ServiceLocator.lookup(ServiceLocator.java:46)



Stell doch mal das caching in dem ServiceLocator ab...( entferne die HashMap) und mach jedes mal einen erneuten LookUp... da war in meiner  Beispielimplementierung etwas nicht in Ordnung...

Gruß Tom


----------



## GartenUmgraben (23. Mai 2005)

Danke..genau das wars  :-]


----------



## CFranke (5. Juni 2005)

Hallo,

Ich möchte dieses Thema nochmal ausgraben, weil ich ein ähnliches Problem habe.

Ich versuche in einer JSP auf eine Session Bean zuzugreifen. Allerdings nicht über den ServiceLocator sondern über den Context:


```
InitialContext ctx = new InitialContext();
StudentFacadeHome facadeHome = (StudentFacadeHome)
                                              ctx.lookup("facade/StudentFacade");
StudentFacade facade = facadeHome.create();
```

Der JNDI-Name der SessionBean ist über XDoclet-Kommentare festgelegt:


```
* @ejb.bean  
 * 	name="StudentFacade"
 *      display-name="StudentFacade Session Bean"
 *      description="StudentFacade Session Bean"
 *      jndi-name="facade/StudentFacade"
 *      type="Stateless"
 *      view-type="remote"
```

Seltsamerweise hat das eigentlich bis jetzt funktioniert. Das ganze ist auch aus einem Beispiel, das wir von unserer Uni bekommen haben, herausgenommen. 
Jetzt bekomme ich aber folgenden Fehler:


```
13:40:28,984 INFO  [STDOUT] java.lang.ClassCastException: $Proxy113
13:40:28,984 INFO  [STDOUT] 	at org.apache.jsp.createStudentAccount_jsp._jspService(org.apache.jsp.createStudentAccount_jsp:208)
13:40:28,984 INFO  [STDOUT] 	at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97)
13:40:28,984 INFO  [STDOUT] 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
13:40:28,984 INFO  [STDOUT] 	at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:322)
13:40:28,984 INFO  [STDOUT] 	at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314)
13:40:28,984 INFO  [STDOUT] 	at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264)
13:40:28,984 INFO  [STDOUT] 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
13:40:28,984 INFO  [STDOUT] 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
13:40:29,015 INFO  [STDOUT] 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
13:40:29,015 INFO  [STDOUT] 	at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:81)
13:40:29,015 INFO  [STDOUT] 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
13:40:29,015 INFO  [STDOUT] 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
13:40:29,015 INFO  [STDOUT] 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
13:40:29,015 INFO  [STDOUT] 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
13:40:29,015 INFO  [STDOUT] 	at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:39)
13:40:29,015 INFO  [STDOUT] 	at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:153)
13:40:29,015 INFO  [STDOUT] 	at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:59)
13:40:29,015 INFO  [STDOUT] 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
13:40:29,015 INFO  [STDOUT] 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
13:40:29,015 INFO  [STDOUT] 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
13:40:29,015 INFO  [STDOUT] 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
13:40:29,015 INFO  [STDOUT] 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856)
13:40:29,015 INFO  [STDOUT] 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:744)
13:40:29,015 INFO  [STDOUT] 	at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
13:40:29,015 INFO  [STDOUT] 	at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
13:40:29,015 INFO  [STDOUT] 	at java.lang.Thread.run(Thread.java:595)
```

Der Deployment-Deskriptor jboss.xml ist eigentlich auch richtig an der betreffenden Stelle 
(wurde von XDoclet generiert):

```
<session>
         <ejb-name>StudentFacade</ejb-name>
         <jndi-name>facade/StudentFacade</jndi-name>

        <method-attributes>
        </method-attributes>
      </session>
```

Tja,... ich bin ziemlich ratlos. 
Ich habe versucht, es über den ServiceLocator zu machen mit getRemoteHome(...), aber da erhalte ich auch eine ClassCastException. 

Stimmt etwas mit den JNDI-Namen nicht? 

Beste Grüße,
Christian


----------



## CFranke (5. Juni 2005)

Also...
Ich hab jetzt mal versucht, den Programmteil weiter "aufzuschlüsseln", indem ich
die narrow-Methode der PortableRemoteObject Klasse verwende:


```
InitialContext ctx = new InitialContext();
Object ref = ctx.lookup("facade/StudentFacade");
StudentFacadeHome facadeHome = (StudentFacadeHome)
                                      PortableRemoteObject.narrow(ref, StudentFacadeHome.class);
StudentFacade facade = facadeHome.create();
```

... und da stellt sich nach Testausgaben heraus, dass das Problem wieder
erst beim Casting auftritt.
Das heißt also die Objektreferenz wird durch ctx.lookup noch gefunden. Der
JNDI-Name stimmt also.

Eine Lösung ist das aber auch noch nicht...

Beste Grüße,
Christian


----------



## CFranke (6. Juni 2005)

Ich "bumpe" das hier mal nach oben. 

Sorry dafür - ich mache sowas normalerweise nicht.
Allerdings wäre eine Antwort auf meine Frage (oder Tips, Fehlermöglichkeiten etc.) doch momentan recht wichtig für mich. 

Gruß, Christian


----------



## Thomas Darimont (6. Juni 2005)

Hallo!

Vielleicht haßt du das Jar schon mal neu generiert? Vielleicht liegt ja irgendwo noch eine alte Version? (Schau mal im tmp Verzeichnis der Serverkonfiguration). Weiterhin könntest du mal im Debugger den Inhalt von "ref" anschauen. Interessant wäre beispielsweise welches Interface der DynamicProxy implementiert.

Gruß Tom


----------



## CFranke (7. Juni 2005)

Schomal vielen Dank für die Antwort 



			
				Thomas Darimont hat gesagt.:
			
		

> Vielleicht haßt du das Jar schon mal neu generiert? Vielleicht liegt ja irgendwo noch eine alte Version?


Ja, das Jar wurde komplett neu generiert, aber eine alte Version hab ich leider nicht mehr. 
Es wurde aber auch nichts an der JSP oder der Session Bean geändert. 



> Weiterhin könntest du mal im Debugger den Inhalt von "ref" anschauen.


Da wird angezeigt: ref = $Proxy112
Wenn ich ref ausgeben lasse, erhalte ich "facade/StudentFacade"



> Interessant wäre beispielsweise welches Interface der DynamicProxy implementiert.


Da muss ich leider passen. Wie finde ich das raus? 


Übrigens habe ich jetzt die Meldung bekommen, dass es auf einem anderen System (von dem ich leider keine Daten habe) läuft, wenn man das .war und das .jar File deployed, aber nicht, wenn man das .ear File deployed. Vielleicht hilft diese Info ja noch....

Ich habe jetzt auch gehört, dass es evtl. an den ClassLoadern liegt. Was es damit auf sich hat, weiß ich leider noch nicht. Da bin ich noch am Informationen sammeln. 

Beste Grüße,
Christian


----------



## CFranke (8. Juni 2005)

Hallo,

Jetzt muss ich mich mal entschuldigen. Sehr peinlich das Ganze...
Der Fehler entstand höchstwahrscheinlich aus einem JBoss 4.0.2 Bug. Mit der Version 4.0.2RC1 läuft das Ganze nämlich wunderbar. 

Trotzdem vielen Dank für die Hilfe. 

Gruß, Christian


----------

