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
, 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
Dmitry:
2. The reason all those things are implemented as subclasses rather
than configuration-based instances is precisely to avoid the need
for configuration. In any complex environment you are working with
lots of ClassLoaders, which are allocated by some container.
A
Victor,
--- [EMAIL PROTECTED] wrote:
Dmitry:
2. The reason all those things are implemented as subclasses
rather
than configuration-based instances is precisely to avoid the
need
for configuration. In any complex environment you are working
with
lots of ClassLoaders, which
From the (perhaps not quite current?) overview I concluded that
to extend Clazz for Customizing a Family of Reflected Clazzes
I have to create
1) a subclass of Reflected*PropertyInspector
2) some (two) AccessMethodParsers
3) a subclass of (Standard)ReflectedClazz
4) a subclass of
Victor,
1. Are you really trying to add support for a FAMILY of reflected
clazzes? It almost sounds to me that you want to modify accessor
recognition for some specific clazzes. If that's what you are trying to
accomplish. There is a much easier way to do so: you create a custom
Clazz. If it is
