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


Groups > comp.lang.java.programmer > #29485

Re: dealing with ClassLoaders...

Path csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!us.feeder.erje.net!news2.arglkargh.de!news.mixmin.net!weretis.net!feeder1.news.weretis.net!newsfeed.CARNet.hr!garrison.bnet.hr!gregory.BNet.hr!not-for-mail
From Josip Almasi <joe@vrspace.org>
Newsgroups comp.lang.java.programmer
Subject Re: dealing with ClassLoaders...
Date Fri, 01 Aug 2014 15:55:56 +0200
Organization B.net Hrvatska d.o.o.
Lines 47
Message-ID <lrg69c$6r3$1@gregory.bnet.hr> (permalink)
References <slrnltl6t2.fp3.avl@login.logic.tuwien.ac.at>
NNTP-Posting-Host 109.60.126.109
Mime-Version 1.0
Content-Type text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding 7bit
X-Trace gregory.bnet.hr 1406901356 7011 109.60.126.109 (1 Aug 2014 13:55:56 GMT)
X-Complaints-To abuse@globalnet.hr
NNTP-Posting-Date Fri, 1 Aug 2014 13:55:56 +0000 (UTC)
User-Agent Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
In-Reply-To <slrnltl6t2.fp3.avl@login.logic.tuwien.ac.at>
Xref csiph.com comp.lang.java.programmer:29485

Show key headers only | View raw


On 07/31/2014 09:40 PM, Andreas Leitgeb wrote:
> All the classes of my app are principially loadable by the system's
> default ClassLoader (i.e. they are in the java.class.path).  Some
> Main class (mypackage.Main) of my app will even be loaded, and this
> class will then create a new Thread with a custom ClassLoader that
> is supposed to load all the other used classes of my app's packages
> (while still delegating loading of newly used system classes to its
> parent).
>
> 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.

> 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.
Also, make sure your loaders don't load the same packages.
Other than this, it's just
if (loaderPackage.equals(classPackage)) loadClass(cls);

BTW if you want to unload/reload classes, you need to remove reference 
to classloader that loaded them.

> The outset is, that some of these classes contain static data.
> (They had been designed as standalone application classes.)
> Now, to improve invocation time, one VM is supposed to run all
> the program instances. This is effectively a followup to a
> previous c.l.j.p thread of mine, where I asked about a certain
> kind of "application servers".
>
> If this is a no-go, then I'll have to redesign those classes to
> get rid of static data, but that will be some effort and require
> passing around context references or use ThreadLocal stuff, so
> my hope is for classloaders to provide me with an easier way out.

Yep, get rid of statics.
In the context of above, I'd say your custom classloader is logical 
source for singleton.

Regards...

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

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

csiph-web