IllegalAccessError - Super/sub-types loaded with different classloaders
in [Java Help]
|
Prev: IllegalAccessError - Super/sub-types loaded with different classloaders
Next: Process ID in Windows the best way
From: Alan Gutierrez on 25 Jul 2010 11:58 Zeba wrote: > On Jul 25, 2:56 pm, Zeba <coolz...(a)gmail.com> wrote: >> On Jul 25, 1:53 pm, Alan Gutierrez <a...(a)blogometer.com> 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??!! >>>> 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. No need to quote signatures. >> Ohh :( That's the problem then. Actually the application has a large >> number of Rule-set's (binary files), each of which is loaded from db >> by its own classloader. However, all of these Rule-sets have a common >> Master ( also loaded from db by a separate classloader ). So instead >> of loading the Master binary files from the db for each of the Child- >> set's, I just save a reference to the master class-loader and use that >> within the Rule-set's class-loaders to load the files ( to save memory >> by avoiding same classes being loaded multiple times over multiple >> classloaders - there will be a large number of Rule-set's). >> >> Is there any other solution than making the Master classloader a child >> of the Rule-set classloader?? > > Missed one point - ExtendedSampleBO is in the Master-set. SampleBO is > a class loaded by the parent of Rule-set's classloader. You can first assert that `ClassLoader` hierarchy is the problem by using `Class.getSuperclass` and `Class.equals` and if the `SampleBO` you use to declare your reference is different from the `SampleBO` acting as the super class of `ExampleSampleBO` then you do have the problem described, and if that is not the case, then you have another problem. There is no good alternative. You could define the methods in you BO to return classes from the system `ClassLaoder` like the `java.util` classes and call them via reflection, but you're well into the wilderness, surrounded by the sun-bleached bones of the others that went before you. I'd say, get your `ClassLoader` hierarchy correct, or replace byte code in the database with an interpreted language like Groovy or jRuby. If it were me, I'd express my logic in Java and deploy the generated byte code in JARs. I'm a traditionalist in this way. -- Alan Gutierrez - alan(a)blogometer.com - http://twitter.com/bigeasy
From: Lew on 25 Jul 2010 12:07 Zeba wrote: > Ohh :( That's the problem then. Actually the application has a large > number of Rule-set's [sic] (binary files), each of which is loaded from db > by its own classloader. However, all of these Rule-sets have a common Why use separate classloaders? > Master ( also loaded from db by a separate classloader ). So instead > of loading the Master binary files from the db for each of the Child- > set's, I just save a reference to the master class-loader and use that > within the Rule-set's [sic] class-loaders to load the files ( to save memory > by avoiding same classes being loaded multiple times over multiple > classloaders - there will be a large number of Rule-set's [sic]). Another way to save that memory is not to use separate classloaders. What other consequences would that cause? > Is there any other solution than making the Master classloader a child > of the Rule-set classloader?? Don't use separate classloaders? -- Lew
From: Alan Gutierrez on 25 Jul 2010 14:57
Alan Gutierrez wrote: > Zeba wrote: >> On Jul 25, 2:56 pm, Zeba <coolz...(a)gmail.com> wrote: >>> On Jul 25, 1:53 pm, Alan Gutierrez <a...(a)blogometer.com> 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??!! >>>>> 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. > > No need to quote signatures. > >>> Ohh :( That's the problem then. Actually the application has a large >>> number of Rule-set's (binary files), each of which is loaded from db >>> by its own classloader. However, all of these Rule-sets have a common >>> Master ( also loaded from db by a separate classloader ). So instead >>> of loading the Master binary files from the db for each of the Child- >>> set's, I just save a reference to the master class-loader and use that >>> within the Rule-set's class-loaders to load the files ( to save memory >>> by avoiding same classes being loaded multiple times over multiple >>> classloaders - there will be a large number of Rule-set's). >>> >>> Is there any other solution than making the Master classloader a child >>> of the Rule-set classloader?? >> >> Missed one point - ExtendedSampleBO is in the Master-set. SampleBO is >> a class loaded by the parent of Rule-set's classloader. > > You can first assert that `ClassLoader` hierarchy is the problem by > using `Class.getSuperclass` and `Class.equals` and if the `SampleBO` you > use to declare your reference is different from the `SampleBO` acting as > the super class of `ExampleSampleBO` then you do have the problem > described, and if that is not the case, then you have another problem. > > There is no good alternative. You could define the methods in you BO to > return classes from the system `ClassLaoder` like the `java.util` > classes and call them via reflection, but you're well into the > wilderness, surrounded by the sun-bleached bones of the others that went > before you. > > I'd say, get your `ClassLoader` hierarchy correct, or replace byte code > in the database with an interpreted language like Groovy or jRuby. If it > were me, I'd express my logic in Java and deploy the generated byte code > in JARs. I'm a traditionalist in this way. Hmm... It occurs to me that I'm imagining that you've put byte code in the database, which upon re-reading the description of your system, doesn't jibe. If you need to transfer objects between processes, use a form of serialization? -- Alan Gutierrez - alan(a)blogometer.com - http://twitter.com/bigeasy |