Re: [RT] The Real Component Simplification
On Thursday 05 January 2006 23:37, Berin Loritsch wrote: > I don't recall if we tested extending where the > URLStreamHandlers are located using the "|java.protocol.handler.pkgs" > system property. The general problem with the java.protocol.handler.pkgs is revolving around an obscure bug (which Sun will not fix) which gives the side effect that those protocol handlers MUST sit in system classloader (or higher), and that is somewhat troublesome for products like Cocoon. IMHO, a big pity, since one could have done so much funky stuff with URL handlers otherwise. The interesting thing around this is that the internal code that handles this probably been refactored so that an additional method call is introduced on the call stack. Reason, it looks at the callstack a couple of levels away and tries to determine the "callee" and use its classloader. But it is always seeing java.net.URL which classloader is null, so it calls ClassLoader.getSystemClassLoader(). I have been arguing over this since JDK1.2 came out, but "Won't fix." is the categorical reply from Sun. Cheers Niclas
Re: [RT] The Real Component Simplification
Carsten Ziegeler wrote: Daniel Fagerstrom wrote: "Decomponentization" could start right away. Do you have any concrete examples of components that shouldn't be components? The XMLSerializer/XMLDeserializer combo is one of the best examples, I think. These shouldn't be components. If noone objects I'll do the changes for 2.2 - we already discussed this years ago :) I never wrote avalon components for my cocoon needs. :-) Hence, any step to a simpler architecture deserves a big +1! Best Regards, Antonio Gallardo. Carsten
Re: [RT] The Real Component Simplification
Vadim Gritsenko wrote: URL interpretation ? SourceResolver and company It proved to be very valuable extension point I'm not negating that, however the way it is currently implemented makes it difficult to use at times. Again there are different ways of skinning this particular cat that would be more efficient. I do recall why we didn't try to use Java's own URL "component" framework. It really wasn't due to complexity of getting the URLStreamHandlers to communicate with Cocoon. It was due to the fact that some web containers like BEA WebLogic and IBM WebSphere preset the static instance of URLStreamHandlerFactory, making it impossible for us to override it. I don't recall if we tested extending where the URLStreamHandlers are located using the "|java.protocol.handler.pkgs" system property. The advantage of using Java's extension mechanism here is that we would be able to use our cocoon:// URLs inside of FOP and any other library that relies on URLs. If we don't rely on components for the core of Cocoon, then we have more flexibility on improving this point. | It is very simplistic view of the world to declare that only P/G/T deserve to be components. I'd even go as far as claim that P/G/T are implemented by cocoon users the *least* often compared to other interfaces. Well, as da Vinci said, "Simplicity is the ultimate sophistication". The key point of the decomponentization process is to reduce the number of extension points to the absolute practical minimum. By being brave about what we leave out, it forces us to think differently about other aspects of the system. I'm thinking way forward here. Just don't throw out baby in the heat of fight for simplification :) Right. Although just because something is an extension point does not mean it has to necessarily be a component.
Re: [RT] The Real Component Simplification
Berin Loritsch wrote: Vadim Gritsenko wrote: Berin Loritsch wrote: Pipeline (sure we have two implementations, but that doesn't mean it has to be a component) Five implementations. And I imagine after interface cleanup and for pipeline API, pipeline should stay component. Not necessarily. Just because there are multiple implementations doesn't necessarily mean it is a component--or should be a component. There are some useful things we can do with a Pipeline such as using the Decorator pattern as opposed to inheritance to add features. Or we could use other OO tricks that just aren't possible or too difficult in a component environment. May be URL interpretation ? SourceResolver and company It proved to be very valuable extension point Just about anything that is not a Processor, Generator, Transformer, Serializer, or Reader. You forgot Matchers, Selectors, and Actions. Every but small projects have bunch of those. No, I left them out on purpose. Those are elements of the Sitemap--which is an implementation of the Processor. Stores. Swapped very frequently, several implementations, and Cocoon's default is not the fastest gun in the west. Ok. That works. Input/output modules. Tons of them. :/ I think that there are some better ways of dealing with this... But it is an extension point that is useful. Unified object model and expression language could replace many of those. It is very simplistic view of the world to declare that only P/G/T deserve to be components. I'd even go as far as claim that P/G/T are implemented by cocoon users the *least* often compared to other interfaces. Well, as da Vinci said, "Simplicity is the ultimate sophistication". The key point of the decomponentization process is to reduce the number of extension points to the absolute practical minimum. By being brave about what we leave out, it forces us to think differently about other aspects of the system. I'm thinking way forward here. Just don't throw out baby in the heat of fight for simplification :) Vadim
Re: [RT] The Real Component Simplification
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 5 Jan 2006, Carsten Ziegeler wrote: Date: Thu, 05 Jan 2006 09:47:01 +0100 From: Carsten Ziegeler <[EMAIL PROTECTED]> Reply-To: dev@cocoon.apache.org To: dev@cocoon.apache.org Subject: Re: [RT] The Real Component Simplification Daniel Fagerstrom wrote: "Decomponentization" could start right away. Do you have any concrete examples of components that shouldn't be components? The XMLSerializer/XMLDeserializer combo is one of the best examples, I think. These shouldn't be components. If noone objects I'll do the changes for 2.2 - we already discussed this years ago :) +1 - -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDvTNaLNdJvZjjVZARArhBAKDyvZP0PJFPGOoumN3qNszdd+kWtACg4KHO deM/MQyF4esf76tP+m9wT14= =Os2u -END PGP SIGNATURE-
Re: [RT] The Real Component Simplification
Vadim Gritsenko wrote: Berin Loritsch wrote: Daniel Fagerstrom wrote: "Decomponentization" could start right away. Do you have any concrete examples of components that shouldn't be components? Pipeline (sure we have two implementations, but that doesn't mean it has to be a component) Five implementations. And I imagine after interface cleanup and for pipeline API, pipeline should stay component. Not necessarily. Just because there are multiple implementations doesn't necessarily mean it is a component--or should be a component. There are some useful things we can do with a Pipeline such as using the Decorator pattern as opposed to inheritance to add features. Or we could use other OO tricks that just aren't possible or too difficult in a component environment. URL interpretation ? SourceResolver and company Just about anything that is not a Processor, Generator, Transformer, Serializer, or Reader. You forgot Matchers, Selectors, and Actions. Every but small projects have bunch of those. No, I left them out on purpose. Those are elements of the Sitemap--which is an implementation of the Processor. Stores. Swapped very frequently, several implementations, and Cocoon's default is not the fastest gun in the west. Ok. That works. Input/output modules. Tons of them. :/ I think that there are some better ways of dealing with this... But it is an extension point that is useful. It is very simplistic view of the world to declare that only P/G/T deserve to be components. I'd even go as far as claim that P/G/T are implemented by cocoon users the *least* often compared to other interfaces. Well, as da Vinci said, "Simplicity is the ultimate sophistication". The key point of the decomponentization process is to reduce the number of extension points to the absolute practical minimum. By being brave about what we leave out, it forces us to think differently about other aspects of the system. I'm thinking way forward here.
Re: [RT] The Real Component Simplification
Daniel Fagerstrom wrote: Carsten Ziegeler wrote: Daniel Fagerstrom wrote: "Decomponentization" could start right away. Do you have any concrete examples of components that shouldn't be components? The XMLSerializer/XMLDeserializer combo is one of the best examples, I think. These shouldn't be components. If noone objects I'll do the changes for 2.2 - we already discussed this years ago :) Carsten +1 +1 Vadim
Re: [RT] The Real Component Simplification
Berin Loritsch wrote: Daniel Fagerstrom wrote: "Decomponentization" could start right away. Do you have any concrete examples of components that shouldn't be components? Pipeline (sure we have two implementations, but that doesn't mean it has to be a component) Five implementations. And I imagine after interface cleanup and for pipeline API, pipeline should stay component. URL interpretation ? Just about anything that is not a Processor, Generator, Transformer, Serializer, or Reader. You forgot Matchers, Selectors, and Actions. Every but small projects have bunch of those. Stores. Swapped very frequently, several implementations, and Cocoon's default is not the fastest gun in the west. Input/output modules. Tons of them. It is very simplistic view of the world to declare that only P/G/T deserve to be components. I'd even go as far as claim that P/G/T are implemented by cocoon users the *least* often compared to other interfaces. Vadim As to Processors, I see the following implementations: 1. current sitemap--complete with its matchers, selectors, actions, and tree processor 2. rails-like router The others are planned extension points that several people have written solutions for.
Re: [RT] The Real Component Simplification
Carsten Ziegeler wrote: Daniel Fagerstrom wrote: "Decomponentization" could start right away. Do you have any concrete examples of components that shouldn't be components? The XMLSerializer/XMLDeserializer combo is one of the best examples, I think. These shouldn't be components. Definitely! If noone objects I'll do the changes for 2.2 - we already discussed this years ago :) +1 Sylvain -- Sylvain WallezAnyware Technologies http://bluxte.net http://www.anyware-tech.com Apache Software Foundation Member Research & Technology Director
Re: [RT] The Real Component Simplification
Carsten Ziegeler wrote: Daniel Fagerstrom wrote: "Decomponentization" could start right away. Do you have any concrete examples of components that shouldn't be components? The XMLSerializer/XMLDeserializer combo is one of the best examples, I think. These shouldn't be components. If noone objects I'll do the changes for 2.2 - we already discussed this years ago :) Carsten +1 /Daniel
Re: [RT] The Real Component Simplification
Daniel Fagerstrom wrote: > > "Decomponentization" could start right away. Do you have any concrete > examples of components that shouldn't be components? > The XMLSerializer/XMLDeserializer combo is one of the best examples, I think. These shouldn't be components. If noone objects I'll do the changes for 2.2 - we already discussed this years ago :) Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [RT] The Real Component Simplification
Daniel Fagerstrom wrote: Berin Loritsch skrev: ... Much like Photoshop with filter plugins. The block idea would be more analagous to complex macros for Photoshop. They may provide new plugins to use in the package, but they allow you to do predefined things. I don't know enough about Photoshop to be able to follow your analogy. Are you talking about extension points and plugins as in Eclipse or are you talking about some other level of granularity? Pretty much. ... The real component simplification is to get rid of the components that will never be swapped out. It's unnecessary for them to be components anyway. That makes the task of providing an Avalon bridge for existing components much easier. And it achieves the goal that the internals are not a scary mess any more. "Decomponentization" could start right away. Do you have any concrete examples of components that shouldn't be components? Pipeline (sure we have two implementations, but that doesn't mean it has to be a component) URL interpretation Just about anything that is not a Processor, Generator, Transformer, Serializer, or Reader. As to Processors, I see the following implementations: 1. current sitemap--complete with its matchers, selectors, actions, and tree processor 2. rails-like router The others are planned extension points that several people have written solutions for.
Re: [RT] The Real Component Simplification
Berin Loritsch skrev: ... Much like Photoshop with filter plugins. The block idea would be more analagous to complex macros for Photoshop. They may provide new plugins to use in the package, but they allow you to do predefined things. I don't know enough about Photoshop to be able to follow your analogy. Are you talking about extension points and plugins as in Eclipse or are you talking about some other level of granularity? ... The real component simplification is to get rid of the components that will never be swapped out. It's unnecessary for them to be components anyway. That makes the task of providing an Avalon bridge for existing components much easier. And it achieves the goal that the internals are not a scary mess any more. "Decomponentization" could start right away. Do you have any concrete examples of components that shouldn't be components? /Daniel
[RT] The Real Component Simplification
Much has been talked about in regards to the component infrastructure. That's a good thing, but after years of component based design, and getting back to the roots of just plain old object oriented design, I have to question why everything needs to be a component. Using good OOD, we can create a solid and robust core--devoid of any configuration settings--and only provide extension points. I.e. plugins. Here's my reasoning, component based design (CBD) is a restricted form of OOD with some initialization magic thrown in. The key weakness in a CBD system is that everything is a moving part. While the flexibility is a strength, the resultant instability is a weakness. It is much easier to design for error tracking using plain old OOD than it is in a system where you don't manage the objects you are using. There are several OO tricks we can't use, or are not using. At the same time, we have some aspects of our system that need to be extended with user provided functionality. Much like Photoshop with filter plugins. The block idea would be more analagous to complex macros for Photoshop. They may provide new plugins to use in the package, but they allow you to do predefined things. There are three areas where we can use the plugin behavior: pipeline components (generator, serializer, transformer, reader), processor (sitemap, rails like router, blocks), and inter-block communication. Everything else should be part of the core. For example, the core does not need to worry about how to stylize the content of your blocks. That is a function of inter-block communication. The core only needs to worry about how to work the different things together. The core does not need to worry about database connections, only how Cocoon extensions relate to the environment. These should be very simple contracts. No moving parts, no configuration for configuration's sake. No need for reams of XML config files. Java 1.4 provided some nice alternatives to dealing with configurations. One notable example would be the Java Preferences API. I have a nice utility that abstracts away the Preferences API vs. a Properties file, and gives you a POJO interface for it. That will also make it easier to create standalone configuration apps using the rock solid JGoodies APIs. Oh, not to mention that my utility also allows you to obfuscate configuration entries like database username and password. The point is, that there are other approaches to configuration. Those approaches are better than XML config files for two reasons: processing the configurations is less complicated, and they are easily managed. The real component simplification is to get rid of the components that will never be swapped out. It's unnecessary for them to be components anyway. That makes the task of providing an Avalon bridge for existing components much easier. And it achieves the goal that the internals are not a scary mess any more.
