commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dmitri Plotnikov <dmi...@apache.org>
Subject Re: [Clazz] subclassing vs. configuration (Was: Extending Clazz)
Date Sat, 21 Jun 2003 22:46:59 GMT
Victor,

Thank you for your interest in Clazz.  We sure could use your help with
perfecting it.

One of the purposes of ClazzLoader is indeed to be a configurable version
Introspector.  The complexity of the relationship between ClazzLoader and
ClassLoader is caused by the complexity of class loader frameworks in modern
application servers and IDEs.  Most conteporary systems allocate and
garbage-collect multiple ClassLoaders, some of which may load different
versions of the same class.  That's why there is a multitude of ClazzLoaders
involved in the introspection process.

In any case, I think it is a good idea to refrain from using Clazz in any
production system at this point.  It is an unreleased sandbox component and
could be abandoned without notice at any point in time.

Thanks,

- Dmitri

----- Original Message ----- 
From: <victor.volle@gmxpro.net>
To: <commons-dev@jakarta.apache.org>
Sent: Saturday, June 21, 2003 12:56 PM
Subject: Re: [Clazz] subclassing vs. configuration (Was: Extending Clazz)


> Dmitri,
>
> ok, I think I understand how it works internally.
> But I honestly must say I do not understand the reasons
> for all this ClassLoader stuff, or at least I do not know
> the requirements which lead to a mechanism, that is
> much to complicated for what I need.
>
> What Clazz did was to mimic java.langClass
> (forName(), defineClass(), ClassLoader)
> and I just need a better and simply
> configurable java.beans.Introspector. I yesterday
> tried to convert it to such a simpler architecture, but
> it would take more than a whole day I think, so I
> refrained and will stay with my own reflection hack.
>
> This surely does not mean that Clazz has a bad
> architecture (in the contrary) it just does fulfill
> requirements I do not have.
>
> Thanks for the very interesting and (for me at least)
> fruitful discussion.
>
> Regards
> Victor
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message