|
|
| Re: EMF plus IBM's Business Process Server = ClassCastException. Any ideas? [message #424134 is a reply to message #424084] |
Thu, 16 October 2008 22:23   |
 Jason Henriksen
Messages: 231
Registered: July 2009 |
Senior Member |
|
|
Ed Merks wrote:
> Jason,
>
> Comments below.
>
>
> jason henriksen wrote:
>> Hi All,
>>
>> We've got a nice EMF system sending messages around and providing
>> services over SOAP.
> Cool.
>> However, someone's decided we should integrate with BPM.
> Someone important?
Yes. The Boss. :)
>> Unfortunately, BPM is sending everything arounds as SDO's based on EMF
>> 2.1.
> That's just a few years old....
>> To make it worse, these things are accessed over an EJB.
> Not my favorite thing.
>> It seems that the serialized object has a specific version number in
>> it because no matter how we set the classpath we get an EMF 2.1 object.
> How can you tell?
This is my favorite java trick ever:
System.err.println(EPackage.class.getProtectionDomain().getC odeSource().getLocation().toString());
Prints the file on the file system that holds the EPackage class. Works
on any class you like and is unbelievably helpful in sorting out
classloader problems.
>>
>> (I know this because I use a trick that prints the location on the
>> disk where the object's .class lives and it's in the 2.1 jar instead
>> of the 2.4 jar)
> That answers that. But what environment it is this. How can this older
> jar exist. Is it a WAS thing? Are you using the classpath_last thing,
> or whatever it's called?
I think it is a WAS issue. I am using PARENT_LAST to ensure that our
EMF objects are used and not the weird old ones that are stored inside
WAS. However the object I get out of EJB seems to be ignoring my
classes because it gives me an instance of the object out of the 2.1
jars instead of my 2.4 jars.
I don't know if that's because java.util serialization stuff is asking
for a specific version, but I think that might be the case. Because the
EJB sourced object is of the same class type ans the object I'm using,
but they come from different class loaders I can't cast one to the
other. So when I try to use the EJB supplied object it gives a CCE and
we crash.
I'm hoping there's some trick to iterate over the EJB supplied object
and fill in a newly created object. I can't really serialize the object
because we only have 2.4 version Resource classes.
My other path is to simply abandon EJB and move to using SOAP. That
way I get an XML string and I can deserialize it into my own objects.
However, I need to make sure there isn't some easy-ish way of resolving
this in EJB before I switch transport styles.
>>
>> We then try to use that in our code which is all EMF 2.4 objects and
>> we get a ClassCastException.
> Where? I guess you have multiple EMFs....
>>
>> So do you guys have some clever trick for situations like this?
>> Otherwise I'll have to somehow walk the object and manually serialize
>> it so that I can deserialize it into an object from the correct version.
> I'm a bit confused about the runtime environment. Could you elaborate?
>>
>>
>> Jason
>>
>> O.T.P.S.:
>> I for one welcome our new Classloader Overlords.
>> Did I say Overlords? I meant Protectors...
|
|
|
| Re: EMF plus IBM's Business Process Server = ClassCastException. Any ideas? [message #424138 is a reply to message #424134] |
Fri, 17 October 2008 04:46 |
Ed Merks
Messages: 33133
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------030202090909050701080209
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Jason,
Unfortunately I don't understand all the mysteries of WAS class
loaders. :-( I know people generally have gotten things working by
playing the right class loader games.
Maybe 245014 <https://bugs.eclipse.org/bugs/show_bug.cgi?id=245014> will
end up being useful in an EJB context...
jason henriksen wrote:
> Ed Merks wrote:
>> Jason,
>>
>> Comments below.
>>
>>
>> jason henriksen wrote:
>>> Hi All,
>>>
>>> We've got a nice EMF system sending messages around and providing
>>> services over SOAP.
>> Cool.
>>> However, someone's decided we should integrate with BPM.
>> Someone important?
> Yes. The Boss. :)
>
>>> Unfortunately, BPM is sending everything arounds as SDO's based on
>>> EMF 2.1.
>> That's just a few years old....
>>> To make it worse, these things are accessed over an EJB.
>> Not my favorite thing.
>>> It seems that the serialized object has a specific version number in
>>> it because no matter how we set the classpath we get an EMF 2.1 object.
>> How can you tell?
> This is my favorite java trick ever:
>
> System.err.println(EPackage.class.getProtectionDomain().getC odeSource().getLocation().toString());
>
>
> Prints the file on the file system that holds the EPackage class.
> Works on any class you like and is unbelievably helpful in sorting out
> classloader problems.
>
>>>
>>> (I know this because I use a trick that prints the location on the
>>> disk where the object's .class lives and it's in the 2.1 jar instead
>>> of the 2.4 jar)
>> That answers that. But what environment it is this. How can this
>> older jar exist. Is it a WAS thing? Are you using the
>> classpath_last thing, or whatever it's called?
>
> I think it is a WAS issue. I am using PARENT_LAST to ensure that our
> EMF objects are used and not the weird old ones that are stored inside
> WAS. However the object I get out of EJB seems to be ignoring my
> classes because it gives me an instance of the object out of the 2.1
> jars instead of my 2.4 jars.
>
> I don't know if that's because java.util serialization stuff is asking
> for a specific version, but I think that might be the case. Because
> the EJB sourced object is of the same class type ans the object I'm
> using, but they come from different class loaders I can't cast one to
> the other. So when I try to use the EJB supplied object it gives a
> CCE and we crash.
>
> I'm hoping there's some trick to iterate over the EJB supplied object
> and fill in a newly created object. I can't really serialize the
> object because we only have 2.4 version Resource classes.
>
> My other path is to simply abandon EJB and move to using SOAP. That
> way I get an XML string and I can deserialize it into my own objects.
> However, I need to make sure there isn't some easy-ish way of
> resolving this in EJB before I switch transport styles.
>
>
>>>
>>> We then try to use that in our code which is all EMF 2.4 objects and
>>> we get a ClassCastException.
>> Where? I guess you have multiple EMFs....
>>>
>>> So do you guys have some clever trick for situations like this?
>>> Otherwise I'll have to somehow walk the object and manually
>>> serialize it so that I can deserialize it into an object from the
>>> correct version.
>> I'm a bit confused about the runtime environment. Could you elaborate?
>>>
>>>
>>> Jason
>>>
>>> O.T.P.S.:
>>> I for one welcome our new Classloader Overlords.
>>> Did I say Overlords? I meant Protectors...
--------------030202090909050701080209
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Jason,<br>
<br>
Unfortunately I don't understand all the mysteries of WAS class
loaders. :-( I know people generally have gotten things working by
playing the right class loader games.<br>
<br>
Maybe <a name="b245014"
href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=245014">245014</a>
will end up being useful in an EJB context...<br>
<br>
<br>
jason henriksen wrote:
<blockquote cite="mid:gd8esb$qg8$1@build.eclipse.org" type="cite">Ed
Merks wrote:
<br>
<blockquote type="cite">Jason,
<br>
<br>
Comments below.
<br>
<br>
<br>
jason henriksen wrote:
<br>
<blockquote type="cite">Hi All,
<br>
<br>
We've got a nice EMF system sending messages around and providing
services over SOAP.
<br>
</blockquote>
Cool.
<br>
<blockquote type="cite">However, someone's decided we should
integrate with BPM.
<br>
</blockquote>
Someone important?
<br>
</blockquote>
Yes. The Boss. :)
<br>
<br>
<blockquote type="cite">
<blockquote type="cite">Unfortunately, BPM is sending everything
arounds as SDO's based on EMF 2.1.
<br>
</blockquote>
That's just a few years old....
<br>
<blockquote type="cite">To make it worse, these things are accessed
over an EJB.
<br>
</blockquote>
Not my favorite thing.
<br>
<blockquote type="cite">It seems that the serialized object has a
specific version number in it because no matter how we set the
classpath we get an EMF 2.1 object.
<br>
</blockquote>
How can you tell?
<br>
</blockquote>
This is my favorite java trick ever:
<br>
<br>
System.err.println(EPackage.class.getProtectionDomain().getC odeSource().getLocation().toString());
<br>
<br>
Prints the file on the file system that holds the EPackage class.
Works on any class you like and is unbelievably helpful in sorting out
classloader problems.
<br>
<br>
<blockquote type="cite">
<blockquote type="cite"><br>
(I know this because I use a trick that prints the location on the disk
where the object's .class lives and it's in the 2.1 jar instead of the
2.4 jar)
<br>
</blockquote>
That answers that. But what environment it is this. How can this
older jar exist. Is it a WAS thing? Are you using the classpath_last
thing, or whatever it's called?
<br>
</blockquote>
<br>
I think it is a WAS issue. I am using PARENT_LAST to ensure that our
EMF objects are used and not the weird old ones that are stored inside
WAS. However the object I get out of EJB seems to be ignoring my
classes because it gives me an instance of the object out of the 2.1
jars instead of my 2.4 jars.
<br>
<br>
I don't know if that's because java.util serialization stuff is asking
for a specific version, but I think that might be the case. Because
the EJB sourced object is of the same class type ans the object I'm
using, but they come from different class loaders I can't cast one to
the other. So when I try to use the EJB supplied object it gives a CCE
and we crash.
<br>
<br>
I'm hoping there's some trick to iterate over the EJB supplied object
and fill in a newly created object. I can't really serialize the
object because we only have 2.4 version Resource classes.
<br>
<br>
My other path is to simply abandon EJB and move to using SOAP. That
way I get an XML string and I can deserialize it into my own objects.
However, I need to make sure there isn't some easy-ish way of resolving
this in EJB before I switch transport styles.
<br>
<br>
<br>
<blockquote type="cite">
<blockquote type="cite"><br>
We then try to use that in our code which is all EMF 2.4 objects and we
get a ClassCastException.
<br>
</blockquote>
Where? I guess you have multiple EMFs....
<br>
<blockquote type="cite"><br>
So do you guys have some clever trick for situations like this?
Otherwise I'll have to somehow walk the object and manually serialize
it so that I can deserialize it into an object from the correct
version.
<br>
</blockquote>
I'm a bit confused about the runtime environment. Could you elaborate?
<br>
<blockquote type="cite"><br>
<br>
Jason
<br>
<br>
O.T.P.S.:
<br>
I for one welcome our new Classloader Overlords.
<br>
Did I say Overlords? I meant Protectors...
<br>
</blockquote>
</blockquote>
</blockquote>
</body>
</html>
--------------030202090909050701080209--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Powered by
FUDForum. Page generated in 0.02703 seconds
] 
Search
Help
Register
Login
Home
