Prev: Class Constants - pros and cons
Next: IllegalAccessError - Super/sub-types loaded with different classloaders
From: Zeba on 25 Jul 2010 04:10

Hi,

I have a use case where
- My client has a SampleBO to which he sets various values
- Needs to extend this SampleBO to ExtendedSampleBO object that
provides additional functionality.
- ExtendedSampleBO is a class that is not present in the client
application, but the client can request the framework to downloaded
and load it - USING A SEPARATE CLASSLOADER - from binary files stored
in the database.
( SampleBO is present in the client side and loaded by the normal
application classloader )

My problem is that after I get an ExtendedSampleBO object, if I try to
access the methods of the super-type (SampleBO), I get
IllegalAccessError. How do I solve this problem??!!

Re-stating my requirement - Client needs to set some values in a BO.
The framework has to provides a mechanism for dynamically extending
the functionality of the BO by using binary files deployed to the
database.

Please help!!!
Zeba
From: Alan Gutierrez on 25 Jul 2010 04:53
Zeba wrote:

> My problem is that after I get an ExtendedSampleBO object, if I try to
> access the methods of the super-type (SampleBO), I get
> IllegalAccessError. How do I solve this problem??!!

> Re-stating my requirement - Client needs to set some values in a BO.
> The framework has to provides a mechanism for dynamically extending
> the functionality of the BO by using binary files deployed to the
> database.

Could it be the case that the special database reading `ClassLoader`
that loads `ExtendedSampleBO` is *not* a child of the `ClassLoader` that
loaded `SampleBO`, because if not, then the special database reading
`ClassLoader` is going to create its own `SampleBO` class and that will
be different from the application's `SampleBO` class.

I'm not sure how that would throw an `IllegalAccessError` and not a
`ClassCastException`, but it would be the first thing I'd look at.

--
Alan Gutierrez - alan(a)blogometer.com - http://twitter.com/bigeasy
From: Lew on 25 Jul 2010 10:44
Zeba wrote:
>> My problem is that after I get an ExtendedSampleBO object, if I try to
>> access the methods of the super-type (SampleBO), I get
>> IllegalAccessError. How do I solve this problem??!!

In general, using a different classloader breaks inheritance.

>> Re-stating my requirement - Client needs to set some values in a BO.
>> The framework has to provides a mechanism for dynamically extending
>> the functionality of the BO by using binary files deployed to the
>> database.

Alan Gutierrez wrote:
> Could it be the case that the special database reading `ClassLoader`
> that loads `ExtendedSampleBO` is *not* a child of the `ClassLoader` that
> loaded `SampleBO`, because if not, then the special database reading
> `ClassLoader` is going to create its own `SampleBO` class and that will
> be different from the application's `SampleBO` class.

Huh. I was not aware that using an inheriting classloader would fix the
loaded-class hierarchy compatibility.

--
Lew
From: Alan Gutierrez on 25 Jul 2010 11:10
Lew wrote:
> Zeba wrote:
>>> My problem is that after I get an ExtendedSampleBO object, if I try to
>>> access the methods of the super-type (SampleBO), I get
>>> IllegalAccessError. How do I solve this problem??!!
>
> In general, using a different classloader breaks inheritance.
>
>>> Re-stating my requirement - Client needs to set some values in a BO.
>>> The framework has to provides a mechanism for dynamically extending
>>> the functionality of the BO by using binary files deployed to the
>>> database.
>
> Alan Gutierrez wrote:
>> Could it be the case that the special database reading `ClassLoader`
>> that loads `ExtendedSampleBO` is *not* a child of the `ClassLoader` that
>> loaded `SampleBO`, because if not, then the special database reading
>> `ClassLoader` is going to create its own `SampleBO` class and that will
>> be different from the application's `SampleBO` class.
>
> Huh. I was not aware that using an inheriting classloader would fix the
> loaded-class hierarchy compatibility.

Well, it is my understanding that their is a `ClassLoader` hierarchy.
That the child `ClassLoader` will look to its parent before loading a
class on its own, or in the case of some application container class, it
will look to the parent if it cannot find the class among its own
resources. So, by default it is parent first, then self, but for web
containers it is self first, then parent.

--
Alan Gutierrez - alan(a)blogometer.com - http://twitter.com/bigeasy
From: Lew on 25 Jul 2010 11:27
Lew wrote ...
>> In general, using a different classloader breaks inheritance.

Mike Schilling wrote:
> Which is why all classes must be loaded by the same system classloader
> that loads Object :-)

You seem to have found one of the exceptions that breaks the "in general"
rule, thus illustrating why I said "in general" in the first place.

Perhaps I should have said, "In general, using a different classloader risks
breaking inheritance unless you plan accordingly." I foolishly thought that
was implicit in stating the general risk, but I guess some people need things
spelled out in more excruciating explicit detail than others. ;-)

--
Lew
 |  Next  |  Last
Pages: 1 2
Prev: Class Constants - pros and cons
Next: IllegalAccessError - Super/sub-types loaded with different classloaders