OTECTED]>
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,
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.l
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 Cla
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.
> >
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 na
>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 ReflectedClazz
