Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #29460 > unrolled thread

dealing with ClassLoaders...

Back to article view | Back to comp.lang.java.programmer

Contents

  dealing with ClassLoaders... Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-07-31 19:40 +0000
    Re: dealing with ClassLoaders... Martin Gregorie <martin@address-in-sig.invalid> - 2014-07-31 20:44 +0000
      Re: dealing with ClassLoaders... Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-08-01 14:22 +0000
        Re: dealing with ClassLoaders... Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-08-01 21:10 +0000
          Re: dealing with ClassLoaders... Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-08-01 17:32 -0400
            Re: dealing with ClassLoaders... Joerg Meier <joergmmeier@arcor.de> - 2014-08-02 01:21 +0200
            Re: dealing with ClassLoaders... Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-08-02 00:00 +0000
          Re: dealing with ClassLoaders... Martin Gregorie <martin@address-in-sig.invalid> - 2014-08-01 21:45 +0000
            Re: dealing with ClassLoaders... Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-08-01 23:14 +0000
              Re: dealing with ClassLoaders... Martin Gregorie <martin@address-in-sig.invalid> - 2014-08-02 00:35 +0000
                Re: dealing with ClassLoaders... Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-08-05 15:38 +0000
    Re: dealing with ClassLoaders... Silvio <silvio@internet.com> - 2014-08-01 13:31 +0200
      Re: dealing with ClassLoaders... Silvio <silvio@internet.com> - 2014-08-01 13:37 +0200
        Re: dealing with ClassLoaders... Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-08-01 16:06 +0000
    Re: dealing with ClassLoaders... "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2014-08-01 13:19 +0100
      Re: dealing with ClassLoaders... Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-08-01 15:51 +0000
    Re: dealing with ClassLoaders... Josip Almasi <joe@vrspace.org> - 2014-08-01 15:55 +0200
      Re: dealing with ClassLoaders... Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-08-04 15:12 +0000
        Re: dealing with ClassLoaders... Mike Amling <mamling@chaff.us> - 2014-08-04 19:53 -0500
          Re: dealing with ClassLoaders... Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-08-05 15:16 +0000
        Re: dealing with ClassLoaders... Josip Almasi <joe@vrspace.org> - 2014-08-08 11:53 +0200
          Re: dealing with ClassLoaders... Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-08-08 18:46 +0000
            Re: dealing with ClassLoaders... Josip Almasi <joe@vrspace.org> - 2014-08-10 13:22 +0200
              Re: dealing with ClassLoaders... Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-08-12 17:16 +0000

Page 2 of 2 — ← Prev page 1 [2]

#29583

On 08/04/2014 05:12 PM, Andreas Leitgeb wrote:
> Josip Almasi <joe@vrspace.org> wrote:
>> On 07/31/2014 09:40 PM, Andreas Leitgeb wrote:
>>> The classloader tutorials I skimmed so far seem to imply, that
>>> a custom classloader is only appropriate to enable classloading
>>> from sources that the system classloader cannot handle itself.
>> Nah, it's also appropriate for context isolation.
>
> But it seems like it doesn't really make it easy to use it
> that way.

Noone said it's easy;)


>>> Is there a clean way to keep classes of a given package confined
>>> to some custom classloader, in order to control the classes' and
>>> their statics' scope/lifetime?
>> Yep, just don't break delegation model.
>> Model says something like, a classloader should ask parent classloader
>> if it has already loaded the class.
>> So, make sure you respect that rule.
>
> The twist in my case comes from the fact, that the parent *could*
> theoretically have loaded one of my special classes, but that would
> just indicate a programming error (aka Bug), so I'd rather have the
> compiler or at least the VM report a strange ClassCastException
> than silently use one of my classes loaded by wrong classloader.

Don't worry, it won't be silent:>
Mess up anything, and you get strange ClassCastExceptions.

>> Also, make sure your loaders don't load the same packages.
> This I don't understand.
> While my "special classes" happen to be in a specific package,
> I don't see, why packages as such would be relevant. I'd expect
> that even within the same package I should (in principle) be
> allowed to have some classes loaded through parent and others
> through custom classloader.

Well your classes 'happen' to be in specific packages, but I think you 
should use that to your advantage, to avoid confussion and classloader bugs.
It gets ugly when equals() starts throwing up.
Better have clearly divided responsibilities.

> I'd welcome hints for how to improve the "classname -> byte[]" step.

I used something like

JarEntry entry = (JarEntry) jarFile.getEntry( name+".class" );
InputStream stream = jarFile.getInputStream(entry);
int size = (int) entry.getSize();
byte[] code = new byte[size];

I also stated with URL but gave it up, because of unknown length.
If I really wanted to load classes remotelly, I'd download jars first 
then load classes from local copies.

Regards...

[toc] | [prev] | [next] | [standalone]

#29588

Josip Almasi <joe@vrspace.org> wrote:
> On 08/04/2014 05:12 PM, Andreas Leitgeb wrote:
>> But it seems like it doesn't really make it easy to use it
>> that way.
> Noone said it's easy;)

;)

> Don't worry, it won't be silent:>
> Mess up anything, and you get strange ClassCastExceptions.

Well, if due to a bug all references to a certain class
came from System classloader, then there would not be
any ClassCastExceptions, but no isolation, either.

Anyway, I got the classloader working well enough for my needs
and I posted the final snippet somewhere in this thread. I used
URLs, because that's what getSystemResource() gives me. They
need not be remote (and in my case aren't remote).

>>> Also, make sure your loaders don't load the same packages.

I think I got confused about this advice, in that I thought
it was meant to point out a technical requirement, when it
really was just a hint (and a good one, btw).

> I used something like
> JarEntry entry = (JarEntry) jarFile.getEntry( name+".class" );
> InputStream stream = jarFile.getInputStream(entry);
> int size = (int) entry.getSize();
> byte[] code = new byte[size];
> I also stated with URL but gave it up, because of unknown length.

I didn't really want to hardcode any particular way to access the 
class-files.  They may be in Jar file after deploy, but e.g. in
eclipse they're just plain files.
Even at the cost of having to grow the ByteArrayOutputStream.

Thanks for caring

PS: Right after I got a "safe-point" with a working custom classloader,
I started un-static'izing the relevant classes. I see myself at 80% 
done, but the remaining 80% will still be rather tough... ;-)

[toc] | [prev] | [next] | [standalone]

#29617

On 08/08/2014 08:46 PM, Andreas Leitgeb wrote:
>> Don't worry, it won't be silent:>
>> Mess up anything, and you get strange ClassCastExceptions.
>
> Well, if due to a bug all references to a certain class
> came from System classloader, then there would not be
> any ClassCastExceptions, but no isolation, either.

Right, but that the case with clearly divided resposibilites.
Not-so-clear situations are different story.

Say, I had plugin system, each plugin was embedding a stand-alone app, 
like web, mail, chat servers...
So, each had it's own class loader, for isolation.
However, the system needed some internal data from plugins...
like, to match username on web server with username on mail server:>
Then, I wanted a plugin to communicate with other plugins.
Like, to ask my chatbot to send someone a mail.
( 
http://www.vrspace.org/vrspace-old/VRSpace_presentation/Presentation_pictures/p2_8.jpg 
)
And so on.

Then, what if two of your apps use same lib, and that lib has static 
collections, and stores some of it's own data into these collections?
Note that it may not matter which loader loaded the lib, but instead, 
which loader loaded the thread that generated object stored to lib's 
internals!
( new -> Class.currentThread().getClassLoader().loadClass(...) or so)

It can go wrong in many ways.

Of course, solutions exist for all wrongs, but identifying what went 
wrong is quite time consuming, because there's so many.

Regards...

[toc] | [prev] | [next] | [standalone]

#29643

Josip Almasi <joe@vrspace.org> wrote:
> On 08/08/2014 08:46 PM, Andreas Leitgeb wrote:
>>> Don't worry, it won't be silent:>
>>> Mess up anything, and you get strange ClassCastExceptions.
>> Well, if due to a bug all references to a certain class
>> came from System classloader, then there would not be
>> any ClassCastExceptions, but no isolation, either.
> Right, but that the case with clearly divided resposibilites.
> Not-so-clear situations are different story.
> Say, I had plugin system, each plugin was embedding a stand-alone app, 
> like web, mail, chat servers...
> So, each had it's own class loader, for isolation.
> However, the system needed some internal data from plugins...
> like, to match username on web server with username on mail server:>
> Then, I wanted a plugin to communicate with other plugins.
> Like, to ask my chatbot to send someone a mail.
> ( 
> http://www.vrspace.org/vrspace-old/VRSpace_presentation/Presentation_pictures/p2_8.jpg 
> )
> And so on.
> ...

:-)

Thanks, you've just made me appreciate the simplicity of my task :-)

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.java.programmer

csiph-web