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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Clazz] subclassing vs. configuration (Was: Extending Clazz)
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: [EMAIL PROTECTED] To: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Clazz] subclassing vs. configuration (Was: Extending Clazz)
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 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Extending Clazz
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Extending Clazz
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 --- [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
