• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • paul wheaton
  • Jeanne Boyarsky
  • Ron McLeod
Sheriffs:
  • Paul Clapham
  • Liutauras Vilda
  • Devaka Cooray
Saloon Keepers:
  • Tim Holloway
  • Roland Mueller
Bartenders:

Peculiar ClassCastException with Plain Old Java Objects

 
Greenhorn
Posts: 16
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello
I am attempting to return a plain old java object across the wire and am running into problems. The POJO is returned by a Session Bean method.

Employer is just a simple class

I added implements java.io.Serializable to see if it made any difference. It didn't
Anyway, when I call the method from a client, like so

which gives me:

If I don't try to return the object everything runs fine, so I think the rest of the code is OK
Does anyone have any idea what's going on? Is there some other obscure interface I need to implement?
thanks
 
Ranch Hand
Posts: 4982
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Srinivas,
Serializable means the Object can be sent through the Internet. Usually, we need to implement the 2 methods: writeObject() and readObject(), which defines how the object is imported and exported.
As in the Employer class, String and Collection are serializable, and thus, you dont need to define how they can be sent via the network. But if it contains some non-serializable objects, OR you dont want to send some attributes via the network, you need to define how the objects be sent. If you do not want to send it, you can provide the transient keyword to fulfill this.
For your case, since Client never directly access any EJB, it only access the EJBObject (provided by the container) and the EJBObject invokes the method from EJB you need, thus, your code seems do not work.
Did you create any component interface and home interface so that the container can invoke the bean for you? In WSAD, you can generate all sets of related interfaces by adding a new EJB via the deployment discriptor.
Nick.
 
srinivas nedunuri
Greenhorn
Posts: 16
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Nick
As you point out, the Employer class is inherently serializable, since it contains nothing other than String and Collection (ArrayList).


For your case, since Client never directly access any EJB, it only access the EJBObject (provided by the container) and the EJBObject invokes the method from EJB you need, thus, your code seems do not work.


I'm not sure what you mean here. I already have a Session bean which is where the method sits(the first piece of code). Its remote interface extends EJBObject as required. Are you saying that Employer should be made an Entity bean? That is certainly one possibility. But suppose I want to avoid Entity beans? There has to be some way of passing around plain java objects.
 
Author
Posts: 16
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
ClassCastExceptions are usually the result of class loader issues. In what different jar/war files do you define Employer class?
Generally, you will only want to define POJO classes in a dependent jar file (or in some limited cases, an ejb-jar file). Including it in multiple places, e.g., both the war file and ejb-jar file will lead to this type of problem -- two classloaders in the same JVM each with a version of the class.
 
Ranch Hand
Posts: 321
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,
I agree as pointed out by Craig that the .jars of the dependent java projects should be included in your .ear as (utility jars) and your web-project and other ejb-project should not have the same in their classpath. This would ensure that your application(.ear) file when deployed should have 1 class-loader.
Rishi
SCJP,SCWCD,IBM/OOAD
 
Liar, liar, pants on fire! refreshing plug:
Smokeless wood heat with a rocket mass heater
https://woodheat.net
reply
    Bookmark Topic Watch Topic
  • New Topic