commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dmitri Plotnikov <dplot...@yahoo.com>
Subject Re: Extending Clazz
Date Wed, 18 Jun 2003 15:10:19 GMT
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 named propery, it will be automatically discovered by
the framework.  See for example
org.apache.commons.clazz.reflect.extended.CustomBean1ExtendedClazz

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?

3. AccessorMethodParsers rather than subclassing them is really not an
option either.  An AccessorMethodParser needs access to the Method to
extract its piece-parts from it.  There is no easy way to predict what
those parts are.  Will it use the type of some argument or some part of
the method name or its visibility or exceptions thrown - who can now?

It is important to understand that you only need to go through all this
trouble of creating ClazzLoaders and custom implementation of Clazz if
you are introducing a new programming model like Extended Java Bean or
something of sorts.  You don't need to do any of that if you just need
to customize an individual clazz: for that you either create a specific
custom implementation of Clazz or use BeanInfo.

- Dmitri



--- victor.volle@gmxpro.net wrote:
> 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 ReflectedClazzLoader
> 5) add the ClazzLoader created in step 4 to an
>     existing ClazzLoader
> 
> I find this quite a lot to do. 
> 
> 1) Wouldn't it be possible to create a new _instance_ 
>     of ReflectedPropertyInspector and configure the 
>    (two) AcessMethodParsers.
> 2) Wouldn't it be possible to simply create a new
>     instance of a BaseAccessMethodParser that has 
>     some methods like
>    
>       - getRequiredPrefix AND setRequiredPrefix (etc.)
> 
>     so that again, I would not need to subclass
> 3) The only reason to create a new subclass of
>     ReflectedClazz seems to be that it has to implement
>     getPropertyInspectors().
>     Why is this method in ReflectedClazz and not in 
>     ClazzLoader? 
>     And again why do I have to subclass wouldn't
>     a BaseReflectedClazz with getter AND setter for
>     PropertyInspectors be sufficient?
> 4) ...
> 
> So it mostly boils down to subclassing vs. "configuring".
> 
> (Besides the remark on the placement of the 
> getPropertyInspectors() method in step 3) which I simply
> do not understand.)
> 
> I do not know, if it's just my preference, but I really dislike
> having so many classes around.
> 
> The simplest solution I could imagine looks something like:
> 
>   AccessorMethodParser readMethod = new BaseAccessMethodParser();
>   readMethod.setRequiredPrefix("add");
>   readMethod.setRequiredParameterCount(1);
>   readMethod.set...
>   // for some methods like getValueType() a subclass might still be
> needed!
>  
>   AccessorMethodParser writeMethod = new BaseAccessMethodParser();
>   ...
> 
>   reflectedPropertyInspector inspector = 
>      new ReflectedPropertyInspector(readMethod, writeMethod);
> 
>   ClazzLoader clazzLoader = ...;
>   clazzLoader.appendPropertyInspector(inspector);
> 
> Could this work with Clazz? 
> 
> Regards
> Victor
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 


__________________________________
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


Mime
View raw message