You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by vi...@gmxpro.net on 2003/06/20 12:18:19 UTC
[Clazz] subclassing vs. configuration (Was: Extending Clazz)
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 ClazzLoader is automatically allocated by Clazz for each
> > > ClassLoader as needed.
> > > Where would we put the hook for configuration?
Victor:
> > But the fifth step, adding the new ClazzLoader, _is_ a configuration
> > anyway.
Dmitry:
> It's done at the factory level: you register your custom ClazzLoader
> class (not instance) with a ClazzLoaderFactory. The factory will
> instantiate it as needed.
Sorry, I do not understand it. You do not want configuration because
you are not sure where to put the "configuration hook". But where
(in my client code) do I register the ClazzLoader class. Here
I have the "configuration hook".
Or is the problem based on registering a ClazzLoader class
and not an instance?
I have further looked into the code and the problem seems to be
based on creating a ClazzLoader (zz) instance for each
ClassLoader (ss). Is this necessary? Why not have another
getClazzForName(String) method that takes a ClassLoader?
getClazzForName(String, ClassLoader)
Wouldn't that be much simpler?
Victor
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [Clazz] subclassing vs. configuration (Was: Extending Clazz)
Posted by Dmitri Plotnikov <dm...@apache.org>.
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: <vi...@gmxpro.net>
To: <co...@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
Re: [Clazz] subclassing vs. configuration (Was: Extending Clazz)
Posted by vi...@gmxpro.net.
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
Re: [Clazz] subclassing vs. configuration (Was: Extending Clazz)
Posted by Dmitri Plotnikov <dp...@yahoo.com>.
Victor,
--- victor.volle@gmxpro.net 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 are allocated by some container.
> > > > A ClazzLoader is automatically allocated by Clazz for each
> > > > ClassLoader as needed.
> > > > Where would we put the hook for configuration?
>
> Victor:
> > > But the fifth step, adding the new ClazzLoader, _is_ a
> configuration
> > > anyway.
>
> Dmitry:
> > It's done at the factory level: you register your custom
> ClazzLoader
> > class (not instance) with a ClazzLoaderFactory. The factory will
> > instantiate it as needed.
>
> Sorry, I do not understand it. You do not want configuration because
> you are not sure where to put the "configuration hook". But where
> (in my client code) do I register the ClazzLoader class. Here
> I have the "configuration hook".
Right, but there is a big difference between registering a class with a
factory and actually instantiating a ClazzLoader and configuring it.
When you register the class with the factory, it just sits there
dormant, with no overhead at all, until it is actually needed, which is
when it is instantiated.
> Or is the problem based on registering a ClazzLoader class
> and not an instance?
I don't see it as a problem - I see it as a solution.
> I have further looked into the code and the problem seems to be
> based on creating a ClazzLoader (zz) instance for each
> ClassLoader (ss). Is this necessary? Why not have another
> getClazzForName(String) method that takes a ClassLoader?
>
> getClazzForName(String, ClassLoader)
>
> Wouldn't that be much simpler?
The reason you allocate a ClazzLoader(zz) for each ClassLoader (ss) is
that you want to cache clazzes, rather than re-doing introspection
every time somebody needs a clazz.
>
> Victor
- Dmitri
__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org