Re: [RT] Simplifying component handling
Giacomo Pati wrote: On Tue, 3 Jan 2006, Sylvain Wallez wrote: Right. And the simplest and most consistent step to go forward is IMO to just use what's already there, providing a nice bridge to a rock-solid container used by thousands of people. If you mean Spring as the rock-solid container used by thousands of people than tell me why are you using a Mac while ten-thousands of people use a IBM ThinkPad ;-) A very interesting comparison: Apple is currently moving to Intel CPUs!! Why so? Because PowerPC is a dead end for their market, as IBM makes no effort to produce good laptop CPUs. So Apple changes the engine, without changing what's unique to them. This is exactly the same for Cocoon: Avalon is dead, and we all agree on this. So what's the point of adding dependency injection features to Avalon? It's like adding Intel instructions to a PowerPC to prepare migration. That's nonsense: you end up with a clumsy solution that smells like a DI container but is not, and provides a mix of injection, lifecycle interfaces and service lookup. Furthermore, it doesn't really encourage people to move away from Avalon as its features are still available to all components. That's what I'm against this change to ECM: just as Apple has setup a bridge (Rosetta) to allow PowerPC and Intel code to run on the same hardware, let's have this bridge in Cocoon too. Want to use legacy components? Use ECM. Want to use dependency injection? Use Spring. Or Pico. Or Hivemind. The bridge can host whatever container manager you want, even if we should promote only one. From a user point of view, I'll be happy to see soon PowerBooks as powerful as ThinkPads. But there's actually much more to this switch: it won't take long before wine is ported to the Mac, so that we can use some applications that, like it or not, only exist on Windows. Yes: the comfort of the Mac, with is deviant compared to the vast majority of PCs out there, but the ability to suck Windoze applications when it makes sense. This is the same with Spring: this is not only a DI container, but a lot of additional services to build applications. And also a lot of people that know it. The Cocoon project, in its current state, really doesn't need yet another specific extension to its obsolete container architecture, that less than an handful of people will understand and be able to maintain. We need to move away from Avalon, so let's do it in a way that can bring in more people and use an engine that's known outside of cocoon-dev. I can understand Carsten as we've talked about it recently and we share some common reservation about Spring (as Carsten has already expressed). Maybe Carsten regrets having written that Spring bridge or the motivation to write it was a business or marketing need not a conceptual evolution. I asked Carsten why he doesn't want to use the bridge that _he_ wrote, and would love to have his answer. Carsten? So, after your veto to the change Cartsten has proposed the only way for him is to write another bridge that suits his needs. This is what I was calling ECM+++. Admittedly I do not know how this bridging to Spring is done at all and I cannot say whether or not a migration from one CM to another will be possible to smooth this migration so that one day we can deprecate the usage of Avalon components. Have a look at the spring-app block. Sylvain -- Sylvain WallezAnyware Technologies http://bluxte.net http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: [RT] Simplifying component handling
Vadim Gritsenko wrote: Carsten Ziegeler wrote: So I'm coming back to my idea, is anyone against adding constructor injection to ECM++ or at least make it pluggable so I can add it for my own projects? The change adds only a feature while maintaining 100% compatibility. Why not setter injection? Because I don't need it :) As you have seen in this thread there are many arguments about a confusing mechanism or hack or whatever. My opinion is that while constructor injection is a clean approach, setter injection might really be more confusion. But as I already said, if someone wants to add setter injection as well, I'm not against it. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [RT] Simplifying component handling
Sylvain Wallez wrote: I asked Carsten why he doesn't want to use the bridge that _he_ wrote, and would love to have his answer. Carsten? Now all this comparing of the things Apple did with our situation is missing imho a big difference: Apple decided that their next OS (MacOS X) should have this and that feature and *then* they thought about a possible bridge for old stuff. So first they had a plan on what to build next (without taking old stuff into consideration). Even more important the bridge is a connection from the new stuff to the old one. Currently we are discussing the opposite! We say, we have this nice bridge that allows the user to use anything (Spring, Pico, Hivemind) she likes and this bridge is a connection from our old stuff (we want to get rid off btw) to new stuff. So, we don't have a clear plan on what the new version should be and just leave it to the user. This would be like if Apple had said, oh, we still use MacOS 9 and provide bridges for windows, linux and AmigaOS. See the difference? And this is why I don't want to use the bridge in general. It's the wrong way. The bridge is nice if you want to use Spring etc. with Cocoon and want a tighter integration. But with the bridges the core will never change, it will still be ECM++. And the current bridge has some other problems, it does not provide access to everything required and I think it might have a performance problem if used the wrong way. Now, actually, I wanted to have constructor injection and more simplifications to make working with the portal block easier. As the portal block in theory has no real connections to cocoon - it's a set of components triggered by a generator - I think I'll use a different approach there, like embedding Spring directly into the generator and building the whole portal on top of Spring without using anything of Avalon. Other portal relevant projects are using Spring anyways, so it might make sense to go into that direction as well. But I fear this approach will not work for other blocks. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [RT] Simplifying component handling
Carsten Ziegeler wrote: Vadim Gritsenko wrote: Carsten Ziegeler wrote: So I'm coming back to my idea, is anyone against adding constructor injection to ECM++ or at least make it pluggable so I can add it for my own projects? The change adds only a feature while maintaining 100% compatibility. Why not setter injection? Because I don't need it :) As you have seen in this thread there are many arguments about a confusing mechanism or hack or whatever. My opinion is that while constructor injection is a clean approach, setter injection might really be more confusion. But as I already said, if someone wants to add setter injection as well, I'm not against it. Guys, remember the real-blocks container story? Two reasons led to the choice of OSGi: there are existing implementations, and it stopped the endless discussions about what the container API should be. We have exactly the same here. why not this or that and I don't need it but you can implement it lead nowhere. NIH syndrome at work. Cocoon's goal is not about containers, but about components. Cocoon was one of the first component-oriented frameworks, but times have changed! Carsten, what's wrong with the Spring bridge? Sylvain -- Sylvain WallezAnyware Technologies http://bluxte.net http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: [RT] Simplifying component handling
Wow, a long and fun thread ;) Seem like most want to migrate away from the Avalon interfaces for component handling and that some (I'm included), in the long term, want to move away even from ECM++. IMO, with all communities that specializes on containers, building containers should be outside the scope of Cocoon. Of course we have to maintain ECM++ for back compability, but hopefully as an optional block. So the only remaining questions are where we want to go and how to get there ;) How --- Concerning how to get there, using the Spring (or other) bridges. as Sylvain proposes, for user component handling does part of the job, we should IMO encourage users to use a bridge rather than ECM++ for new development. Still the bridge in its current form, AFAICS, doesn't help migrating the Cocoon core and the blocks to a more modern container. One (yet unimplemented) feature with the block architecture is that one can choose block manager at the block level and still exporting components to other blocks. By using this and spliting the Cocoon core into smaller blocks, migration to a modern container becomes easier as we can migrate one block at the time. Component management at the block level also removes the need to use sub sitemaps with local component managers for modularization. This means that we can depricate component containers at the sitemap level and thus in the long run simplify the architecture and loosen the coupling between conatiners and the sitemap engine. We can also migrate to DI gradually within the blocks (and core) by extending ECM++ with some DI mechanism as Carsten wants, but I agree with those who fear mixed models. If we go that way, we should have a clear idea where we want to go. What While we, IMO, shouldn't lock users to a specific container, we need a common ground for development of the core and the most important blocks. I have to little knowledge about Spring, Pico etc to have any opinion yet. But for injection strategy I would prefer setter injection. Citing Berin: Setter Injection --- Familiar JavaBean style interface, natural to many Java developers, and easy to use introspection based tools. Encorages failsafe design so that almost all components are optional. In short, the absense of other components cause the bean to work with diminished capacity. An example is the DataSource object from the SQL package. In fact, that component would work out of the box in this type of environment. Constructor Injection - Very robust design, less familiar to many Java developers, but natural enough. Encourages tight encapsulation and failfast design so that almost all components are required. In short, the absense of other components can cause the component to crash. Examples include just about any unmodifiable POJO object. Here it is the failsafe design aspect that I find most important. One of the long term goals with the blocks system is to allow for hot deployable and updateable blocks. While hot deployabillity no doubt is complicated and even might be to complicted for some kinds of blocks, it is a very large advantage not least for getting development interactive. Also OSGi helps a lot in this area. Now, in a dynamic environment, the failfast design of constructor injection isn't atractive at all anymore, as the assumption that all components are constructed once and for all at startup isn't valid anymore. Also, the new (and very prommissing) declarative services from OSGi R4, supports setter injection but not constructor injection. Declarative services is a standardised component container for OSGi which is designed with dynamic component creation, update and destruction, in mind. IBM have recently donated the reference implementation to Eclipse. As others have noted, we will need to support the use of a sevice manager even in the future, dynamic builders like the sitemap engine cannot just be injected with all the components they need. I agree with Carsten that we should migrate towards using thread safe components and factories everywhere. This is needed in the OSGi environment as the OSGi service architecture assumes singletons and factories. This is a separate concern that we can start to work on immediatly. As long as we use Avalon interfaces, respecting the contracts is however IMO more important than saving a few keystrokes, so we shouldn't change defaults. We also need to rethink configuration for components in blocks. We need two levels, one deploy time configuration level, that is on the user level and probably is property based, and one wiring level that is statically declared within the block and takes care of implementation details. OSGi already have a mechanism for this where the declarative services configuration is used for the wiring level and the configuration service for the deploy time configuration. --- o0o --- Summarizing my
Re: [RT] Simplifying component handling
Sylvain Wallez wrote: ... Guys, remember the real-blocks container story? Two reasons led to the choice of OSGi: there are existing implementations, and it stopped the endless discussions about what the container API should be. We have exactly the same here. why not this or that and I don't need it but you can implement it lead nowhere. NIH syndrome at work. Cocoon's goal is not about containers, but about components. Cocoon was one of the first component-oriented frameworks, but times have changed! +1000 what's wrong with the Spring bridge? Nothing, but it currently doesn't help migrating the core and the blocks to a modern container. For that we need to make the bridge available at the block level, and connect it to inter block component management. /Daniel
Re: [RT] Simplifying component handling
Sylvain Wallez wrote: Carsten, what's wrong with the Spring bridge? See my reply from today. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [RT] Simplifying component handling
Sylvain Wallez wrote: Guys, remember the real-blocks container story? Two reasons led to the choice of OSGi: there are existing implementations, and it stopped the endless discussions about what the container API should be. We have exactly the same here. why not this or that and I don't need it but you can implement it lead nowhere. NIH syndrome at work. Cocoon's goal is not about containers, but about components. Cocoon was one of the first component-oriented frameworks, but times have changed! Yes, so why not throwing ECM++ away and use an existing container? We can provide an Avalon compatibility bridge for nearly any existing container. I don't want to build an own container in Cocoon, but currently using an existing one for the core has been veto'd several times, so we have to stick with ECM++. But making this more useful is also veto'd. Hmm. And as we can't come up with a good solution (being it using an existing container or improving our own), we simply tell the users to use whatever they think is right - as we don't know it. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [RT] Simplifying component handling
Le 4 janv. 06, à 12:36, Carsten Ziegeler a écrit : ...Yes, so why not throwing ECM++ away and use an existing container? We can provide an Avalon compatibility bridge for nearly any existing container... I was thinking about this after reading the replies this morning, sounds like an ideal solution to move forward: allow existing components to run in the Avalon way, yet gradually move to more modern stuff. -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: [RT] Simplifying component handling
Carsten Ziegeler wrote: Sylvain Wallez wrote: Guys, remember the real-blocks container story? Two reasons led to the choice of OSGi: there are existing implementations, and it stopped the endless discussions about what the container API should be. We have exactly the same here. why not this or that and I don't need it but you can implement it lead nowhere. NIH syndrome at work. Cocoon's goal is not about containers, but about components. Cocoon was one of the first component-oriented frameworks, but times have changed! Yes, so why not throwing ECM++ away and use an existing container? We can provide an Avalon compatibility bridge for nearly any existing container. Incidentally, I had just started to write a implementation of the Avalon lifecycle as a Spring BeanFactory when you committed the Spring bridge. The current bridge allows Spring to run in an Avalon container, whereas what I had started was the other way around, i.e. an Avalon container within Spring. Need to dig in my HD although I'm not sure I still have it... I don't want to build an own container in Cocoon, but currently using an existing one for the core has been veto'd several times, so we have to stick with ECM++. What has been vetoed is turning ECM++ to a DI container, which is not Cocoon's goals and allow confusing mixed models to develop components (opposed to writing components _either_ the Avalon way _or_ the POJO way). But making this more useful is also veto'd. Hmm. And as we can't come up with a good solution (being it using an existing container or improving our own), we simply tell the users to use whatever they think is right - as we don't know it. Uh? I don't follow you here. Sylvain -- Sylvain WallezAnyware Technologies http://bluxte.net http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: [RT] Simplifying component handling
Daniel Fagerstrom wrote: snip/ Summarizing my opinions: Users should be able to use any container. ... but we should have one usable out of the box for users that don't want or don't know how to make a choice. Blocks and a more fine grained modularization of the core gives the possiblity to migrate to a new container in steps. We need a common strategy for core and important blocks. Setter injection is more natural for a dynamic environment. We should start migrating towards threadsafes and factories. Two levels of component configuration are needed. Building component containers is outside the scope of Cocoon. +1000. Sylvain -- Sylvain WallezAnyware Technologies http://bluxte.net http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: [RT] Simplifying component handling
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 4 Jan 2006, Carsten Ziegeler wrote: Date: Wed, 04 Jan 2006 12:36:19 +0100 From: Carsten Ziegeler [EMAIL PROTECTED] Reply-To: dev@cocoon.apache.org To: dev@cocoon.apache.org Subject: Re: [RT] Simplifying component handling Sylvain Wallez wrote: Guys, remember the real-blocks container story? Two reasons led to the choice of OSGi: there are existing implementations, and it stopped the endless discussions about what the container API should be. We have exactly the same here. why not this or that and I don't need it but you can implement it lead nowhere. NIH syndrome at work. Cocoon's goal is not about containers, but about components. Cocoon was one of the first component-oriented frameworks, but times have changed! Yes, so why not throwing ECM++ away and use an existing container? We can provide an Avalon compatibility bridge for nearly any existing container. ATM I do see this as a valuable way to go. - - Declare our legacy Avalon components being the bridged ones - - Start using an existing container - - Migrate the legacy stuff over I don't want to build an own container in Cocoon, but currently using an existing one for the core has been veto'd several times, so we have to stick with ECM++. But making this more useful is also veto'd. Hmm. And as we can't come up with a good solution (being it using an existing container or improving our own), we simply tell the users to use whatever they think is right - as we don't know it. That's a deadlock. - -- 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) iD8DBQFDu81uLNdJvZjjVZARAtZRAJ0fENxt8LZVH4HV6Vz2OBAxPqACZQCg0xLo aOPmX3dXq2pWKm8FTaic5ko= =DweB -END PGP SIGNATURE-
Re: [RT] Simplifying component handling
My only fear with this whole discussion is that we are once again going to lose focus on finishing 2.2. Ralph
Re: [RT] Simplifying component handling
Sylvain Wallez skrev: Daniel Fagerstrom wrote: snip/ Summarizing my opinions: Users should be able to use any container. ... but we should have one usable out of the box for users that don't want or don't know how to make a choice. Absolutely. In the long run I think that the OSGi declarative services together with the configuration admin service (and the metatype service for strong typing of the configurations) is the way to go. But the declarative services is still unproven technology and we have some work left to do before we have an OSGi based block system, so it might not be a realistic choice yet. In the mean time I would prefer something that is as leight weight and non intrusive as possible. /Daniel
Re: [RT] Simplifying component handling
On 1/3/06, Upayavira [EMAIL PROTECTED] wrote: Reinhard Poetz wrote: --- Carsten Ziegeler [EMAIL PROTECTED] schrieb: Gianugo Rabellino wrote: Yeah, and I really don't understand this - I (and others) propose small but simple steps to a) improve using Cocoon and b) provide a smooth migration path. So I'm coming back to my idea, is anyone against adding constructor injection to ECM++ or at least make it pluggable so I can add it for my own projects? The change adds only a feature while maintaining 100% compatibility. Without having time to understand in depth what you guys are talking about, I'd say that we should not block any features that don't introduce any backwards incompatibilities. If people disagree here, I would be very intersted in their reasons ... So +1 for your enhancements Carsten! Even more - Gianugo makes some valid points about the future. However, at this point, we cannot prove that his opinion is correct. So in my view, we should be taking multiple paths until one shows up to be the clear winner. It's not so easy. First let me state that I don't have any particular blocker if all we're talking about is adding constructor injection to ECM++: whatever goes in the direction of a lighter and less-Avalon-dependant Cocoon gets my applause. I do have issues, though, when mixing models. something we're very good at. Keeping both interface injection and constructor-injection (well, why not setter injection as well at this point, shouldn't be too hard and, hey, gives one more choice) and telling users to take their pick isn't going to work: adding features blindly not because of architectural/design issues but because it's tiresome to add 5 lines of code and - at the same time - not considering how users might be confused by the fact that we're still using Avalon but we're subverting its very principles is just not going to work. Careful also about taking multiple paths (and again, this isn't quite the case of this constructor-injection stuff which gets my +0 as in it's not my favourite solution but I'm fine with it): removing cruft later on is hard, and the situation we are in how should prove it: once you've baked a cake, there is no way to get your flour, butter and eggs back to bake another one. Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: [RT] Simplifying component handling
Carsten Ziegeler wrote: So I'm coming back to my idea, is anyone against adding constructor injection to ECM++ or at least make it pluggable so I can add it for my own projects? The change adds only a feature while maintaining 100% compatibility. I have strong reservations about components using a mixed model (i.e. dependency injection + Avalon interfaces), as these components will look as semi-POJOs that bring some potential confusion about their lifecycle: - is the component ready after the constructor has been called? - what is the call order between setter-based injection and Avalon lifecycle interfaces? - what is the lifestyle of a POJO: thread safe, single threaded? So although I'm all for a simplification of components and moving away from Avalon, I'm strongly against using mixed models. Now, do we need to make changes to ECM++ at all? Cocoon 2.2 allows the integration of other containers such as Spring (Carsten, _you_ wrote that!), so we just have to *use* what is already there, using a solid existing container rather than a half-baked solution. Sylvain -- Sylvain WallezAnyware Technologies http://bluxte.net http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: [RT] Simplifying component handling
Addressing both, Sylvain's and Gianugo's response (at least partially): Gianugo Rabellino wrote: It's not so easy. First let me state that I don't have any particular blocker if all we're talking about is adding constructor injection to ECM++: whatever goes in the direction of a lighter and less-Avalon-dependant Cocoon gets my applause. I do have issues, though, when mixing models. something we're very good at. Keeping both interface injection and constructor-injection (well, why not setter injection as well at this point, shouldn't be too hard and, hey, gives one more choice) and telling users to take their pick isn't going to work: adding features blindly not because of architectural/design issues but because it's tiresome to add 5 lines of code and - at the same time - not considering how users might be confused by the fact that we're still using Avalon but we're subverting its very principles is just not going to work. Sylvain Wallez wrote: I have strong reservations about components using a mixed model (i.e. dependency injection + Avalon interfaces), as these components will look as semi-POJOs that bring some potential confusion about their lifecycle: - is the component ready after the constructor has been called? - what is the call order between setter-based injection and Avalon lifecycle interfaces? - what is the lifestyle of a POJO: thread safe, single threaded? So although I'm all for a simplification of components and moving away from Avalon, I'm strongly against using mixed models. Now, do we need to make changes to ECM++ at all? Cocoon 2.2 allows the integration of other containers such as Spring (Carsten, _you_ wrote that!), so we just have to *use* what is already there, using a solid existing container rather than a half-baked solution. Hmm, so why is ECM++ different from ECM (includes, JMX etc.)? With the same argument we could just use ECM with the container integrations and that's it. Now, I'm only talking about constructor injection, so if you're using it you have a well defined life-cycle of that component as the constructor is called before everything else. Mixing constructor injection with other Avalon interfaces might cause confusion, yes. It's up to the component writer to decide this and we can come up with nice documentation telling everyone how to develop components. I would suggest to either use constructor injectior or the Avalon interfaces but not both at the same time. However, there is one exception: the lifestyle. As we can't agree on making everything thread safe, I think the easiest way is to support ThreadSafe, Poolable etc. with constructor injection as well - with the default still being single threaded. With constructor injection we have a simple container which is able to serve POJOs while remaining compatible. And we are one step further in a smooth migration path. Setter injection is a different thing - I personally don't want to add it as things imho get too complicated then (but if someone wants to do it, well, why not). And finally, Spring is cool and has nice features, but imho it has no clean separation between a component writer and a component user when it comes to configuration. In fact (as a teaser :) ), I'm thinking about writing a new core for Cocoon based on Spring which supports annotations and the avalon style configuration based on roles and xconf files. It's not that hard to do, but the question right now is if it's worth it. This could simply replace ECM++. But as we don't want to build on sand again, I think this is out of question anyway Now, seriously, comming back to Gianugo's concern adding features blindly not because of architectural/design issues but because it's tiresome to add 5 lines of code...: As I said, these changes make it imho easier to work with Cocoon and provide a required migration path. Imho, the best way would be to think about a new architecture/design for a future Cocoon, build that and provide then migration paths. But the last months have shown that we have currently no common understanding of a future Cocoon - everyone has her own vision and plans. And as long as we are in this situation, we can imho only try to do simple steps forward and see where we will arrive. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [RT] Simplifying component handling
Carsten Ziegeler wrote: Hmm, so why is ECM++ different from ECM (includes, JMX etc.)? With the same argument we could just use ECM with the container integrations and that's it. Oh yes, sure! And why not going back to the Director interface of the good old Cocoon 1.0 times? Seriously, ECM++ allowed us to add new features that we badly needed such as xconf includes, and Spring bridge among others. Now, I'm only talking about constructor injection, so if you're using it you have a well defined life-cycle of that component as the constructor is called before everything else. Mixing constructor injection with other Avalon interfaces might cause confusion, yes. It's up to the component writer to decide this and we can come up with nice documentation telling everyone how to develop components. Muhuhuhahahahaha! Nice documentation C'mon... I would suggest to either use constructor injectior or the Avalon interfaces but not both at the same time. Great, I suggest the same by using the Spring bridge. However, there is one exception: the lifestyle. As we can't agree on making everything thread safe, I think the easiest way is to support ThreadSafe, Poolable etc. with constructor injection as well - with the default still being single threaded. With constructor injection we have a simple container which is able to serve POJOs while remaining compatible. And we are one step further in a smooth migration path. Just use Spring: this is compatible, and allows to move away from Avalon faster. Setter injection is a different thing - I personally don't want to add it as things imho get too complicated then (but if someone wants to do it, well, why not). And finally, Spring is cool and has nice features, but imho it has no clean separation between a component writer and a component user when it comes to configuration. In fact (as a teaser :) ), I'm thinking about writing a new core for Cocoon based on Spring which supports annotations and the avalon style configuration based on roles and xconf files. It's not that hard to do, but the question right now is if it's worth it. This could simply replace ECM++. But as we don't want to build on sand again, I think this is out of question anyway Hmm... Is it April 1st already? Now, seriously, comming back to Gianugo's concern adding features blindly not because of architectural/design issues but because it's tiresome to add 5 lines of code...: As I said, these changes make it imho easier to work with Cocoon and provide a required migration path. I disagree: the migration path is to allow writing components *without caring about Avalon*. Any mixed model is a complexification as it requires to know both models and the interaction betwen them in mixed model components. And a nice documentation is not the solution. Imho, the best way would be to think about a new architecture/design for a future Cocoon, build that and provide then migration paths. But the last months have shown that we have currently no common understanding of a future Cocoon - everyone has her own vision and plans. And as long as we are in this situation, we can imho only try to do simple steps forward and see where we will arrive. Right. And the simplest and most consistent step to go forward is IMO to just use what's already there, providing a nice bridge to a rock-solid container used by thousands of people. Sylvain -- Sylvain WallezAnyware Technologies http://bluxte.net http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: [RT] Simplifying component handling
Sorry, but I don't comment on this. Just one (final) question: are you -1 on the changes? Carsten Sylvain Wallez wrote: Carsten Ziegeler wrote: Hmm, so why is ECM++ different from ECM (includes, JMX etc.)? With the same argument we could just use ECM with the container integrations and that's it. Oh yes, sure! And why not going back to the Director interface of the good old Cocoon 1.0 times? Seriously, ECM++ allowed us to add new features that we badly needed such as xconf includes, and Spring bridge among others. Now, I'm only talking about constructor injection, so if you're using it you have a well defined life-cycle of that component as the constructor is called before everything else. Mixing constructor injection with other Avalon interfaces might cause confusion, yes. It's up to the component writer to decide this and we can come up with nice documentation telling everyone how to develop components. Muhuhuhahahahaha! Nice documentation C'mon... I would suggest to either use constructor injectior or the Avalon interfaces but not both at the same time. Great, I suggest the same by using the Spring bridge. However, there is one exception: the lifestyle. As we can't agree on making everything thread safe, I think the easiest way is to support ThreadSafe, Poolable etc. with constructor injection as well - with the default still being single threaded. With constructor injection we have a simple container which is able to serve POJOs while remaining compatible. And we are one step further in a smooth migration path. Just use Spring: this is compatible, and allows to move away from Avalon faster. Setter injection is a different thing - I personally don't want to add it as things imho get too complicated then (but if someone wants to do it, well, why not). And finally, Spring is cool and has nice features, but imho it has no clean separation between a component writer and a component user when it comes to configuration. In fact (as a teaser :) ), I'm thinking about writing a new core for Cocoon based on Spring which supports annotations and the avalon style configuration based on roles and xconf files. It's not that hard to do, but the question right now is if it's worth it. This could simply replace ECM++. But as we don't want to build on sand again, I think this is out of question anyway Hmm... Is it April 1st already? Now, seriously, comming back to Gianugo's concern adding features blindly not because of architectural/design issues but because it's tiresome to add 5 lines of code...: As I said, these changes make it imho easier to work with Cocoon and provide a required migration path. I disagree: the migration path is to allow writing components *without caring about Avalon*. Any mixed model is a complexification as it requires to know both models and the interaction betwen them in mixed model components. And a nice documentation is not the solution. Imho, the best way would be to think about a new architecture/design for a future Cocoon, build that and provide then migration paths. But the last months have shown that we have currently no common understanding of a future Cocoon - everyone has her own vision and plans. And as long as we are in this situation, we can imho only try to do simple steps forward and see where we will arrive. Right. And the simplest and most consistent step to go forward is IMO to just use what's already there, providing a nice bridge to a rock-solid container used by thousands of people. Sylvain -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [RT] Simplifying component handling
Carsten Ziegeler wrote: Sorry, but I don't comment on this. Just one (final) question: are you -1 on the changes? Yes, -1 because: - the mixed model will bring confusion, - having yet another Cocoon-specific way of handling components just makes the learning curve steeper, - the number of saved code lines doesn't justify it (how many manager.lookup() with all the keystrokes in these mails?), - we already have a Spring bridge that allows us to have *real* POJOs and much more. Honestly, I fail to understand why you don't want to use that Spring bridge that you wrote. Sylvain -- Sylvain WallezAnyware Technologies http://bluxte.net http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: [RT] Simplifying component handling
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 3 Jan 2006, Sylvain Wallez wrote: Date: Tue, 03 Jan 2006 10:13:33 +0100 From: Sylvain Wallez [EMAIL PROTECTED] Reply-To: dev@cocoon.apache.org To: dev@cocoon.apache.org Subject: Re: [RT] Simplifying component handling Carsten Ziegeler wrote: So I'm coming back to my idea, is anyone against adding constructor injection to ECM++ or at least make it pluggable so I can add it for my own projects? The change adds only a feature while maintaining 100% compatibility. I have strong reservations about components using a mixed model (i.e. dependency injection + Avalon interfaces), as these components will look as semi-POJOs that bring some potential confusion about their lifecycle: - is the component ready after the constructor has been called? - what is the call order between setter-based injection and Avalon lifecycle interfaces? - what is the lifestyle of a POJO: thread safe, single threaded? So although I'm all for a simplification of components and moving away from Avalon, I'm strongly against using mixed models. Now, do we need to make changes to ECM++ at all? Cocoon 2.2 allows the integration of other containers such as Spring (Carsten, _you_ wrote that!), so we just have to *use* what is already there, using a solid existing container rather than a half-baked solution. I'm with Sylvain's and Gianugo's oppinion. I also see users getting confused with multiple choices of how to write a component. I'd say in this area we need a revolution instead of an evolution. Maybe we need a ECM+++ to still keep our fingers on the container. - -- 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) iD8DBQFDulHrLNdJvZjjVZARAjuFAKDI9RUXPxdJxxxPmLypZ5OYGW994gCgh1TE zwGKN5VX/acJGPD8c5/pjOg= =oKmG -END PGP SIGNATURE-
Re: [RT] Simplifying component handling
Giacomo Pati wrote: I'm with Sylvain's and Gianugo's oppinion. I also see users getting confused with multiple choices of how to write a component. I personally don't see a problem *if* we tell them how to do it right. Perhaps I'm wrong, don't know. I'd say in this area we need a revolution instead of an evolution. Ok, I agree that we need a revolution - I guess most of us do - but honestly, where is this revolution? When will it take place? And even more important, we don't have a common understanding of this revolution and how it might look like. So it's really hard (if not impossible) right now to do something that helps getting at this point :( Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [RT] Simplifying component handling
Giacomo Pati wrote: I'm with Sylvain's and Gianugo's opinion. I also see users getting confused with multiple choices of how to write a component. I'd say in this area we need a revolution instead of an evolution. Moving to POJOs doesn't need a revolution. We already have the bridge. Maybe it needs a bit of polishing, but it is here, waiting to be used. Maybe we need a ECM+++ to still keep our fingers on the container. Yes, we need ECM++ to have an hybrid containement model that can host Avalon components and POJO components in a POJO container. Sylvain -- Sylvain WallezAnyware Technologies http://bluxte.net http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: [RT] Simplifying component handling
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 3 Jan 2006, Carsten Ziegeler wrote: Date: Tue, 03 Jan 2006 11:49:32 +0100 From: Carsten Ziegeler [EMAIL PROTECTED] Reply-To: dev@cocoon.apache.org To: dev@cocoon.apache.org Subject: Re: [RT] Simplifying component handling Giacomo Pati wrote: I'm with Sylvain's and Gianugo's oppinion. I also see users getting confused with multiple choices of how to write a component. I personally don't see a problem *if* we tell them how to do it right. Perhaps I'm wrong, don't know. :-) and which one is the right one? I'd say in this area we need a revolution instead of an evolution. Ok, I agree that we need a revolution - I guess most of us do - but honestly, where is this revolution? When will it take place? And even more important, we don't have a common understanding of this revolution and how it might look like. So it's really hard (if not impossible) right now to do something that helps getting at this point :( Of course we do not have a common understanding. We have old farts like me comfortable with the Avalon way :-) that say I know it well and it has worked for years, so why should I change, younger ones familiar with Spring but not so with Avalon. We have a friendly community with no dictators but probably in this case one would be handy to say we go the XYZ way ;-) - -- 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) iD8DBQFDulh7LNdJvZjjVZARAgGmAKCX6nDfMhgK8PvhbB+A1gFhtZc3kQCeMWHS cFOL3zIgxPa8tsEvBCT9VNg= =Wh1q -END PGP SIGNATURE-
Re: [RT] Simplifying component handling
On 1/3/06, Giacomo Pati [EMAIL PROTECTED] wrote: I'm with Sylvain's and Gianugo's oppinion. I also see users getting confused with multiple choices of how to write a component. I'd say in this area we need a revolution instead of an evolution. I really don't get this objection; if I see a class that allows constructor injection OR can be initialized via some other sequence I'm going to think gee, that's nice, I can do everything in one shot instead of having to call the service manager (or whatever) . All that's required to make sure that's clear is about 2 lines of Javadoc on the constructor and if that's missing and someone does try to initialize the class both ways you can probably make sure it either blows up or handles things gracefully. We use constructor injection in some of our code. It's clean, it's simple, it's easy to write. Sometimes we support multiple methods of initializing the code. It's pretty darn clear what's going on to any user of the code. As a Cocoon user I really think that any objection to this proposal based on it might be confusing to users is bogus... -- Peter Hunsberger
Re: [RT] Simplifying component handling
On Jan 3, 2006, at 9:06 AM, Peter Hunsberger wrote: On 1/3/06, Giacomo Pati [EMAIL PROTECTED] wrote: I'm with Sylvain's and Gianugo's oppinion. I also see users getting confused with multiple choices of how to write a component. I'd say in this area we need a revolution instead of an evolution. I really don't get this objection; if I see a class that allows constructor injection OR can be initialized via some other sequence I'm going to think gee, that's nice, I can do everything in one shot instead of having to call the service manager (or whatever) . All that's required to make sure that's clear is about 2 lines of Javadoc on the constructor and if that's missing and someone does try to initialize the class both ways you can probably make sure it either blows up or handles things gracefully. We use constructor injection in some of our code. It's clean, it's simple, it's easy to write. Sometimes we support multiple methods of initializing the code. It's pretty darn clear what's going on to any user of the code. As a Cocoon user I really think that any objection to this proposal based on it might be confusing to users is bogus... I agree. This is a minor simplification directed towards developers. If they can't figure out when and when not to use this then they need to learn. The fact that this buys you very little is a different concern. Sometimes we spend a bit more then we should for little luxuries, but we're willing to eat bread and water as a result. Just make sure Carsten is the one who suffers for this luxury ;) Glen Ezkovich HardBop Consulting glen at hard-bop.com A Proverb for Paranoids: If they can get you asking the wrong questions, they don't have to worry about answers. - Thomas Pynchon Gravity's Rainbow
Re: [RT] Simplifying component handling
Carsten Ziegeler wrote: So I'm coming back to my idea, is anyone against adding constructor injection to ECM++ or at least make it pluggable so I can add it for my own projects? The change adds only a feature while maintaining 100% compatibility. Why not setter injection? Vadim
Re: [RT] Simplifying component handling
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 3 Jan 2006, Sylvain Wallez wrote: Right. And the simplest and most consistent step to go forward is IMO to just use what's already there, providing a nice bridge to a rock-solid container used by thousands of people. If you mean Spring as the rock-solid container used by thousands of people than tell me why are you using a Mac while ten-thousands of people use a IBM ThinkPad ;-) I can understand Carsten as we've talked about it recently and we share some common reservation about Spring (as Carsten has already expressed). Maybe Carsten regrets having written that Spring bridge or the motivation to write it was a business or marketing need not a conceptual evolution. So, after your veto to the change Cartsten has proposed the only way for him is to write another bridge that suits his needs. This is what I was calling ECM+++. Admittedly I do not know how this bridging to Spring is done at all and I cannot say whether or not a migration from one CM to another will be possible to smooth this migration so that one day we can deprecate the usage of Avalon components. - -- 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) iD8DBQFDuvdpLNdJvZjjVZARArRgAKCOA/TAwNJBR5nRqUVGVQjo4Nq42wCfWr0p 0UHIy7RCqUIw98YvNBll+ro= =8z7n -END PGP SIGNATURE-
RE: [RT] Simplifying component handling
... What's the contract for the auto-wiring? Just assuming ClassA and ClassB have public static fields called ROLE? Sounds somewhat strange. No, the contract would be to search for a component which is registered using the ClassA as the role name. Actually ClassA and ClassB are two interfaces. Hmm, so what do you do about the hints? Often enough, I see o.a.c.something.SomeInterface/hint (like o.a.c.caching.Cache/EventAware) in cocoon. This wouldn't work with your assumptions of always using FQCNs as service names. max
Re: [RT] Simplifying component handling
Max Pfingsthorn wrote: ... What's the contract for the auto-wiring? Just assuming ClassA and ClassB have public static fields called ROLE? Sounds somewhat strange. No, the contract would be to search for a component which is registered using the ClassA as the role name. Actually ClassA and ClassB are two interfaces. Hmm, so what do you do about the hints? Often enough, I see o.a.c.something.SomeInterface/hint (like o.a.c.caching.Cache/EventAware) in cocoon. This wouldn't work with your assumptions of always using FQCNs as service names. Right. Most times these are dynamic parts, for example pipeline processing, in this case, you can still use Serviceable. But as we can't get any consensus on any changes, I think we should drop the topic and wait until we have moved away from Avalon completly. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [RT] Simplifying component handling
That seems to be a catch-22. How do you move away from Avalon without making these kind of changes? Carsten Ziegeler wrote: But as we can't get any consensus on any changes, I think we should drop the topic and wait until we have moved away from Avalon completly. Carsten
Re: [RT] Simplifying component handling
On 1/2/06, Ralph Goers [EMAIL PROTECTED] wrote: That seems to be a catch-22. How do you move away from Avalon without making these kind of changes? Honestly, I don't see how anything in the 2.x series could move away from Avalon. Too much refactoring needed, too many issues on the table. Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: [RT] Simplifying component handling
This thread got me thinking about alternatives to dependency injection. The only credible alternative I can think of for Cocoon is a Service Locator. One of the things I liked about Avalon was its combination of dependency injection and service locator. This combination made sense for a general purpose framework. The drawback is that there is a great deal of complexity due to its use of interface injection. (probably the real reason Carsten started this thread) To simplify this all one need do is remove the interface injection. Once the injection is removed each component is responsible for constructing its self. The drawback of using a service locator is the dependency on the locator itself. Cocoon is a coherent framework that provides its own locator so this is a minimal stumbling block. There are two ways we could proceed using a service locator. One would be to add a static method to a SeviceManager implementation public static ServiceManager getServiceManager() The other would be to use constructor injection public MyComponent(ServiceManager m) No reflection, no tricks, no jumping through hoops and a simple contract. This also provides a way to move away from Avalon while providing the benefits of life-cycle management by allowing a component to request its parameters, disposer, etc. by creating other locators. I don't believe it would be to difficult to keep backwards compatibility using this technique and all future components will be greatly simplified. WDYT? Glen Ezkovich HardBop Consulting glen at hard-bop.com A Proverb for Paranoids: If they can get you asking the wrong questions, they don't have to worry about answers. - Thomas Pynchon Gravity's Rainbow
Re: [RT] Simplifying component handling
On Dec 30, 2005, at 4:05 PM, Berin Loritsch wrote: Seriously, I agree that writing less code is good, but not at the price of too black magic implying weaker contracts. Agreed. To achieve the goal of less code would require major overhauls of the entire system. Yes. I think Cocoon could be greatly simplified knowing what we know now. This would be a worthwhile endeavor but not one that should be undertaken at the cost of slowing advancement. Remember Netscape. Glen Ezkovich HardBop Consulting glen at hard-bop.com A Proverb for Paranoids: If they can get you asking the wrong questions, they don't have to worry about answers. - Thomas Pynchon Gravity's Rainbow
Re: [RT] Simplifying component handling
Gianugo Rabellino wrote: On 1/2/06, Ralph Goers [EMAIL PROTECTED] wrote: That seems to be a catch-22. How do you move away from Avalon without making these kind of changes? Good question - I think noone is able to answer that one. Honestly, I don't see how anything in the 2.x series could move away from Avalon. Too much refactoring needed, too many issues on the table. Yeah, and I really don't understand this - I (and others) propose small but simple steps to a) improve using Cocoon and b) provide a smooth migration path. But even if these proposals do not include heavy refactoring and do not come with problems, people are blocking it and always point to the we need a rewrite. Then if people are suggestion, let's rewrite, the same people (and others) complain that that is currently not an option. So in the end we are doomed. So I'm coming back to my idea, is anyone against adding constructor injection to ECM++ or at least make it pluggable so I can add it for my own projects? The change adds only a feature while maintaining 100% compatibility. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [RT] Simplifying component handling
Le 3 janv. 06, à 08:11, Carsten Ziegeler a écrit : ...So I'm coming back to my idea, is anyone against adding constructor injection to ECM++ or at least make it pluggable so I can add it for my own projects? The change adds only a feature while maintaining 100% compatibility... I'm +1 on this change, as you say it maintains compatibility, and it can simplify component writing. -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: [RT] Simplifying component handling
--- Carsten Ziegeler [EMAIL PROTECTED] schrieb: Gianugo Rabellino wrote: On 1/2/06, Ralph Goers [EMAIL PROTECTED] wrote: That seems to be a catch-22. How do you move away from Avalon without making these kind of changes? Good question - I think noone is able to answer that one. Honestly, I don't see how anything in the 2.x series could move away from Avalon. Too much refactoring needed, too many issues on the table. Yeah, and I really don't understand this - I (and others) propose small but simple steps to a) improve using Cocoon and b) provide a smooth migration path. But even if these proposals do not include heavy refactoring and do not come with problems, people are blocking it and always point to the we need a rewrite. Then if people are suggestion, let's rewrite, the same people (and others) complain that that is currently not an option. So in the end we are doomed. So I'm coming back to my idea, is anyone against adding constructor injection to ECM++ or at least make it pluggable so I can add it for my own projects? The change adds only a feature while maintaining 100% compatibility. Without having time to understand in depth what you guys are talking about, I'd say that we should not block any features that don't introduce any backwards incompatibilities. If people disagree here, I would be very intersted in their reasons ... So +1 for your enhancements Carsten! -- Reinhard ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: [RT] Simplifying component handling
Reinhard Poetz wrote: --- Carsten Ziegeler [EMAIL PROTECTED] schrieb: Gianugo Rabellino wrote: On 1/2/06, Ralph Goers [EMAIL PROTECTED] wrote: That seems to be a catch-22. How do you move away from Avalon without making these kind of changes? Good question - I think noone is able to answer that one. Honestly, I don't see how anything in the 2.x series could move away from Avalon. Too much refactoring needed, too many issues on the table. Yeah, and I really don't understand this - I (and others) propose small but simple steps to a) improve using Cocoon and b) provide a smooth migration path. But even if these proposals do not include heavy refactoring and do not come with problems, people are blocking it and always point to the we need a rewrite. Then if people are suggestion, let's rewrite, the same people (and others) complain that that is currently not an option. So in the end we are doomed. So I'm coming back to my idea, is anyone against adding constructor injection to ECM++ or at least make it pluggable so I can add it for my own projects? The change adds only a feature while maintaining 100% compatibility. Without having time to understand in depth what you guys are talking about, I'd say that we should not block any features that don't introduce any backwards incompatibilities. If people disagree here, I would be very intersted in their reasons ... So +1 for your enhancements Carsten! Even more - Gianugo makes some valid points about the future. However, at this point, we cannot prove that his opinion is correct. So in my view, we should be taking multiple paths until one shows up to be the clear winner. So, I'd say, Carsten, get on with improving 2.2 to address the issues people have mentioned, and others, get on with prototyping a new implementation of Cocoon. If/when that new implementation comes along, we can see if it can be redone as a refactoring rather than a rewrite. Until then, let's move on on all fronts. We stand a better chance of winning that way. Regards, Upayavira, who's been away for a few days and hasn't read the full thread
Re: [RT] Simplifying component handling
On 30.12.2005 19:09, Carsten Ziegeler wrote:
class MyComponent implements SOMETHING, ThreadSafe, Disposable,
Serviceable {
protected ClassA compA;
protected ClassB compB;
protected ServiceManager m;
public void service(ServiceManager m) {
this.m = m;
compA = (ClassA)m.lookup(ClassA.ROLE);
compB = (ClassB)m.lookup(ClassB.ROLE);
}
public void dispose() {
if ( m != null ) {
m.release(compA);
m.release(compB);
}
}
Way too much code me thinks. So what about:
class MyComponent implements SOMETHING, ThreadSafe {
protected final ClassA compA;
protected final ClassB compB;
public MyComponent(ClassA a, ClassB b) {
compA = a;
compB = b;
}
}
We could simply add constructor injection: if the implementation does
not provide a default constructor, the available constructor is called
using reflection and the components are injected on construction of the
object - no need to configure something in any xml configuration file.
Implementing this is easy - I did this already years ago for Fortress.
What's the contract for the auto-wiring? Just assuming ClassA and ClassB
have public static fields called ROLE? Sounds somewhat strange.
Jörg
Re: [RT] Simplifying component handling
Joerg Heinicke wrote:
On 30.12.2005 19:09, Carsten Ziegeler wrote:
class MyComponent implements SOMETHING, ThreadSafe, Disposable,
Serviceable {
protected ClassA compA;
protected ClassB compB;
protected ServiceManager m;
public void service(ServiceManager m) {
this.m = m;
compA = (ClassA)m.lookup(ClassA.ROLE);
compB = (ClassB)m.lookup(ClassB.ROLE);
}
public void dispose() {
if ( m != null ) {
m.release(compA);
m.release(compB);
}
}
Way too much code me thinks. So what about:
class MyComponent implements SOMETHING, ThreadSafe {
protected final ClassA compA;
protected final ClassB compB;
public MyComponent(ClassA a, ClassB b) {
compA = a;
compB = b;
}
}
We could simply add constructor injection: if the implementation does
not provide a default constructor, the available constructor is called
using reflection and the components are injected on construction of the
object - no need to configure something in any xml configuration file.
Implementing this is easy - I did this already years ago for Fortress.
What's the contract for the auto-wiring? Just assuming ClassA and ClassB
have public static fields called ROLE? Sounds somewhat strange.
No, the contract would be to search for a component which is registered
using the ClassA as the role name. Actually ClassA and ClassB are two
interfaces.
Carsten
--
Carsten Ziegeler - Open Source Group, SN AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: [RT] Simplifying component handling
Niclas Hedhman wrote:
On Saturday 31 December 2005 02:09, Carsten Ziegeler wrote:
My final idea is to use even more magic (but it might be too much magic?):
class MyComponent implements SOMETHING {
protected final ClassA component_A;
protected final ClassB component_B;
}
Yipee, yet another thread on a new container architecture. Can't wait to see
the hours of debate leading up to no change...
Exactly.
Honestly guys, I'm starting to think that Cocoon won't manage to do the
separation from Avalon, purely due to the number of ways to do it exceeds the
number of strong-willed people in the community, and disagreements of what is
the best move.
Too true :( And this all is not just about the separation from Avalon.
Sigh
Time for me to close the shop, and start with something more exciting.
Sounds like a good plan! If you found something, let me know!
Carsten
--
Carsten Ziegeler - Open Source Group, SN AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: [RT] Simplifying component handling
On 30.12.2005 19:09, Carsten Ziegeler wrote:
Way too much code me thinks. So what about:
class MyComponent implements SOMETHING, ThreadSafe {
protected final ClassA compA;
protected final ClassB compB;
public MyComponent(ClassA a, ClassB b) {
compA = a;
compB = b;
}
}
I've tried this (with Jakarta Commons Attributes) and the end result
can be summarized as it is barely worth it in terms of added
complexity and behind-the-scenes magic. Technically it is a huge
success. But the price you pay is that it makes the code that much
more non-standard.
This is also for a closed code base that has a fixed team of a few
developers. For open source, having additional magic would probably be
even more expensive in terms of complexity, initial threshold for
developers, and embeddability.
(Regarding the lower embeddability: This is my main problem with
Commons Logging. It has magic all right - just not the right magic!)
For Cocoon, I'd recommend against it. So what if the code is a little
bit bigger, if it means that it can actually be understood without
knowing a hundred additional, Cocoon-specific contracts up front.
/LS
[RT] Simplifying component handling
Aren't you tired of implementing a service/dispose combo for each of
your components over and over again? Now, actually, I am. Big time.
If you look at several of our components, they do something like this:
class MyComponent implements SOMETHING, ThreadSafe, Disposable,
Serviceable {
protected ClassA compA;
protected ClassB compB;
protected ServiceManager m;
public void service(ServiceManager m) {
this.m = m;
compA = (ClassA)m.lookup(ClassA.ROLE);
compB = (ClassB)m.lookup(ClassB.ROLE);
}
public void dispose() {
if ( m != null ) {
m.release(compA);
m.release(compB);
}
}
Way too much code me thinks. So what about:
class MyComponent implements SOMETHING, ThreadSafe {
protected final ClassA compA;
protected final ClassB compB;
public MyComponent(ClassA a, ClassB b) {
compA = a;
compB = b;
}
}
We could simply add constructor injection: if the implementation does
not provide a default constructor, the available constructor is called
using reflection and the components are injected on construction of the
object - no need to configure something in any xml configuration file.
Implementing this is easy - I did this already years ago for Fortress.
But I think it can even get easier:
1. Let's just assume that every component is ThreadSafe - unless
otherwise stated - no need to declare the interface anymore. I think
apart from the interpreter most components are threadsafe or poolable
anyway.
2. Let's remove support for pooled components - yes, seriously. Fiddling
with the pool sizes is really annoying. We have a working factory
approach for sitemap components, so why not simply use it overall? And
rewriting the remaining pooled components shouldn't be that hard. (I now
that we are proxying pooled components to simplify the lookup, but you
still have to configure pool sizes).
My final idea is to use even more magic (but it might be too much magic?):
class MyComponent implements SOMETHING {
protected final ClassA component_A;
protected final ClassB component_B;
}
When the component is instantiated all instance variables prefixed with
component_ are setup using some injection mechanism - or perhaps using
annotations?
Now, in the end I really want to write less code :)
Ah and yes I'm talking about 2.2, seriously - I'll come up with a list
of things I think we should remove in 2.2 in the next days :)
Carsten
--
Carsten Ziegeler - Open Source Group, SN AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: [RT] Simplifying component handling
Carsten Ziegeler wrote:
Aren't you tired of implementing a service/dispose combo for each of
your components over and over again? Now, actually, I am. Big time.
If you look at several of our components, they do something like this:
class MyComponent implements SOMETHING, ThreadSafe, Disposable,
Serviceable {
protected ClassA compA;
protected ClassB compB;
protected ServiceManager m;
public void service(ServiceManager m) {
this.m = m;
compA = (ClassA)m.lookup(ClassA.ROLE);
compB = (ClassB)m.lookup(ClassB.ROLE);
}
public void dispose() {
if ( m != null ) {
m.release(compA);
m.release(compB);
}
}
The test m != null is useless, as dispose should never be called
twice. Removes 2 lines :-)
Way too much code me thinks. So what about:
class MyComponent implements SOMETHING, ThreadSafe {
protected final ClassA compA;
protected final ClassB compB;
public MyComponent(ClassA a, ClassB b) {
compA = a;
compB = b;
}
}
We could simply add constructor injection: if the implementation does
not provide a default constructor, the available constructor is called
using reflection and the components are injected on construction of the
object - no need to configure something in any xml configuration file.
Implementing this is easy - I did this already years ago for Fortress.
But I think it can even get easier:
1. Let's just assume that every component is ThreadSafe - unless
otherwise stated - no need to declare the interface anymore. I think
apart from the interpreter most components are threadsafe or poolable
anyway.
This is a huge change compared to the current behaviour, where no
interface means not threadsafe and not reusable. IMO, this change can
only happen if we completely move away from Avalon.
2. Let's remove support for pooled components - yes, seriously. Fiddling
with the pool sizes is really annoying. We have a working factory
approach for sitemap components, so why not simply use it overall? And
rewriting the remaining pooled components shouldn't be that hard. (I now
that we are proxying pooled components to simplify the lookup, but you
still have to configure pool sizes).
+1 for generalizing the factory pattern. Cocoon spends way too much time
in checking Avalon's lifecycle interfaces and parsing configuration objects.
My final idea is to use even more magic (but it might be too much magic?):
class MyComponent implements SOMETHING {
protected final ClassA component_A;
protected final ClassB component_B;
}
When the component is instantiated all instance variables prefixed with
component_ are setup using some injection mechanism - or perhaps using
annotations?
Hmm...
- how do you unit test Cocoon without the container? By subclassing to
access the protected fields?
- we can't strongly enforce the contract of subclasses by making some
fields private.
- the naming convention weakens the strong typing of Java. What if you
write conponent_A? Chasing the NPE won't be easy...
Now, in the end I really want to write less code :)
Use Ruby :-P
Seriously, I agree that writing less code is good, but not at the price
of too black magic implying weaker contracts.
Sylvain
--
Sylvain WallezAnyware Technologies
http://bluxte.net http://www.anyware-tech.com
Apache Software Foundation Member Research Technology Director
Re: [RT] Simplifying component handling
On 12/30/05, Carsten Ziegeler [EMAIL PROTECTED] wrote:
Aren't you tired of implementing a service/dispose combo for each of
your components over and over again? Now, actually, I am. Big time.
Way too much code me thinks. So what about:
class MyComponent implements SOMETHING, ThreadSafe {
protected final ClassA compA;
protected final ClassB compB;
public MyComponent(ClassA a, ClassB b) {
compA = a;
compB = b;
}
}
I'm definitely not a fan of constructor injection, exp. when we
consider how (way too) often we resorted to inheritance in Cocoon
components. Now, while interface injection is clearly out of fashion,
sticking with Avalon/Excalibur also means that it would be difficult
to get around the container (e.g., how do you release components with
your approach? I assume Excalibur still kinda needs that).
But I think it can even get easier:
1. Let's just assume that every component is ThreadSafe - unless
otherwise stated - no need to declare the interface anymore. I think
apart from the interpreter most components are threadsafe or poolable
anyway.
Again, until Avalon is around I don't see how a marker interface can
really bug you...
2. Let's remove support for pooled components - yes, seriously. Fiddling
with the pool sizes is really annoying. We have a working factory
approach for sitemap components, so why not simply use it overall? And
rewriting the remaining pooled components shouldn't be that hard. (I now
that we are proxying pooled components to simplify the lookup, but you
still have to configure pool sizes).
I'm also still not completely sold on factories. Indeed, they work and
they're a brilliant solution, but am I the only one smelling hack and
workaround?
My final idea is to use even more magic (but it might be too much magic?):
class MyComponent implements SOMETHING {
protected final ClassA component_A;
protected final ClassB component_B;
}
When the component is instantiated all instance variables prefixed with
component_ are setup using some injection mechanism - or perhaps using
annotations?
Yes, that's definitely too much magic. ;-) I'd rather favor an
annotation/attribute based approach rather than reflection hacks...
Ciao,
--
Gianugo Rabellino
Pro-netics s.r.l. - http://www.pro-netics.com
Orixo, the XML business alliance: http://www.orixo.com
(blogging at http://www.rabellino.it/blog/)
Re: [RT] Simplifying component handling
+ 1 with comments below
Carsten Ziegeler wrote:
Aren't you tired of implementing a service/dispose combo for each of
your components over and over again? Now, actually, I am. Big time.
If you look at several of our components, they do something like this:
class MyComponent implements SOMETHING, ThreadSafe, Disposable,
Serviceable {
protected ClassA compA;
protected ClassB compB;
protected ServiceManager m;
public void service(ServiceManager m) {
this.m = m;
compA = (ClassA)m.lookup(ClassA.ROLE);
compB = (ClassB)m.lookup(ClassB.ROLE);
}
public void dispose() {
if ( m != null ) {
m.release(compA);
m.release(compB);
}
}
Way too much code me thinks. So what about:
class MyComponent implements SOMETHING, ThreadSafe {
protected final ClassA compA;
protected final ClassB compB;
public MyComponent(ClassA a, ClassB b) {
compA = a;
compB = b;
}
}
We could simply add constructor injection: if the implementation does
not provide a default constructor, the available constructor is called
using reflection and the components are injected on construction of the
object - no need to configure something in any xml configuration file.
Implementing this is easy - I did this already years ago for Fortress.
But I think it can even get easier:
1. Let's just assume that every component is ThreadSafe - unless
otherwise stated - no need to declare the interface anymore. I think
apart from the interpreter most components are threadsafe or poolable
anyway.
2. Let's remove support for pooled components - yes, seriously. Fiddling
with the pool sizes is really annoying. We have a working factory
approach for sitemap components, so why not simply use it overall? And
rewriting the remaining pooled components shouldn't be that hard. (I now
that we are proxying pooled components to simplify the lookup, but you
still have to configure pool sizes).
As my current experience is showing misconfigured pooling can be
disastrous. However, when it is correct it is pretty fast. Before
removing support for pooling lets actually prove that the factory
approach performs approximately the same as the correctly configured
pooled approach. Last time I checked there was exactly one factory
component - the file generator. Can you do a quick test to show how
that performs against the pooled version?
My final idea is to use even more magic (but it might be too much magic?):
class MyComponent implements SOMETHING {
protected final ClassA component_A;
protected final ClassB component_B;
}
When the component is instantiated all instance variables prefixed with
component_ are setup using some injection mechanism - or perhaps using
annotations?
Now, in the end I really want to write less code :)
Ah and yes I'm talking about 2.2, seriously - I'll come up with a list
of things I think we should remove in 2.2 in the next days :)
Carsten
Re: [RT] Simplifying component handling
Sylvain Wallez wrote:
public void dispose() {
if ( m != null ) {
m.release(compA);
m.release(compB);
}
}
The test m != null is useless, as dispose should never be called
twice. Removes 2 lines :-)
No, it is not useless - if some exception happens during the init phase
of a component, the service method() might never be called, there m is
null. Without the null-test in dispose, you get an NPE :(
Seriously, I agree that writing less code is good, but not at the price
of too black magic implying weaker contracts.
Agreed - ok, so a first step would be to implement the constructor
injection then - this is imho a compatible/transparent addition
simplyfing a lot.
Second step would be to use factories where currently pooled components
are used.
Carsten
--
Carsten Ziegeler - Open Source Group, SN AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: [RT] Simplifying component handling
Sylvain Wallez wrote: This is a huge change compared to the current behaviour, where no interface means not threadsafe and not reusable. IMO, this change can only happen if we completely move away from Avalon. Isn't that the direction we are headed anyway?
Re: [RT] Simplifying component handling
Gianugo Rabellino wrote: I'm also still not completely sold on factories. Indeed, they work and they're a brilliant solution, but am I the only one smelling hack and workaround? I didn't like this when I first saw it either. My thought was to have the Generator, etc. be thread safe and have it create an object that was passed around to all of its methods which would then be released when the pipeline lost track of it. However, I realized that in the end that that is more or less what the current implementation does, but just with different names attached to the objects. The major difference is that the setup and generate methods are in the dynamically created object instead of in the factory class. But does that really matter?
Re: [RT] Simplifying component handling
Gianugo Rabellino wrote: I'm definitely not a fan of constructor injection, exp. when we consider how (way too) often we resorted to inheritance in Cocoon components. Now, while interface injection is clearly out of fashion, sticking with Avalon/Excalibur also means that it would be difficult to get around the container (e.g., how do you release components with your approach? I assume Excalibur still kinda needs that). Yes, Excalibur still needs it - but it's easy. Bascially, you emulate the service() method on construction of the object and then you emulate the dispose method when destroying the object. Everything our ecm++ needs to know is there. As I said, I've done this in Fortress and we can use that code in ecm++ as well. And we could implement setter injection with some kind of auto wiring as well. It's not really that harder. But using setters again requires to code more than using a constructor. But I think it can even get easier: 1. Let's just assume that every component is ThreadSafe - unless otherwise stated - no need to declare the interface anymore. I think apart from the interpreter most components are threadsafe or poolable anyway. Again, until Avalon is around I don't see how a marker interface can really bug you... It's not the marker interfaces itself - it's just the amount of code I have to write. For example, the initializable interface is great - in other component frameworks you have to configure the init methode somehow which is imho too much work and makes configuration your application too complicated. 2. Let's remove support for pooled components - yes, seriously. Fiddling with the pool sizes is really annoying. We have a working factory approach for sitemap components, so why not simply use it overall? And rewriting the remaining pooled components shouldn't be that hard. (I now that we are proxying pooled components to simplify the lookup, but you still have to configure pool sizes). I'm also still not completely sold on factories. Indeed, they work and they're a brilliant solution, but am I the only one smelling hack and workaround? Hmm, don't know :) I don't see a hack/workaround in using factories instead of using pooled components? If we would use other component containers we had to do this anyway. And yes, we have to/want to move away from Avalon - using constructor injection, removing pooling etc. makes this easier in smaller steps. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [RT] Simplifying component handling
Ralph Goers wrote: Sylvain Wallez wrote: This is a huge change compared to the current behaviour, where no interface means not threadsafe and not reusable. IMO, this change can only happen if we completely move away from Avalon. Isn't that the direction we are headed anyway? Yes, of course. What I say if that while Avalon is there in the system with its marker interfaces, we should use them. Sylvain -- Sylvain WallezAnyware Technologies http://bluxte.net http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: [RT] Simplifying component handling
Carsten Ziegeler wrote: Gianugo Rabellino wrote: I'm definitely not a fan of constructor injection, exp. when we consider how (way too) often we resorted to inheritance in Cocoon components. Now, while interface injection is clearly out of fashion, sticking with Avalon/Excalibur also means that it would be difficult to get around the container (e.g., how do you release components with your approach? I assume Excalibur still kinda needs that). Yes, Excalibur still needs it - but it's easy. Bascially, you emulate the service() method on construction of the object and then you emulate the dispose method when destroying the object. Everything our ecm++ needs to know is there. As I said, I've done this in Fortress and we can use that code in ecm++ as well. And we could implement setter injection with some kind of auto wiring as well. It's not really that harder. But using setters again requires to code more than using a constructor. I'm with Gianugo on this one - I'd better have setter injection instead of constructor injection. In *addition* to setter injection, ecm++ could also recognize annotations (if running under jdk 1.5). Vadim
Re: [RT] Simplifying component handling
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 30 Dec 2005, Vadim Gritsenko wrote: Date: Fri, 30 Dec 2005 14:21:07 -0500 From: Vadim Gritsenko [EMAIL PROTECTED] Reply-To: dev@cocoon.apache.org To: dev@cocoon.apache.org Subject: Re: [RT] Simplifying component handling Carsten Ziegeler wrote: Gianugo Rabellino wrote: I'm definitely not a fan of constructor injection, exp. when we consider how (way too) often we resorted to inheritance in Cocoon components. Now, while interface injection is clearly out of fashion, sticking with Avalon/Excalibur also means that it would be difficult to get around the container (e.g., how do you release components with your approach? I assume Excalibur still kinda needs that). Yes, Excalibur still needs it - but it's easy. Bascially, you emulate the service() method on construction of the object and then you emulate the dispose method when destroying the object. Everything our ecm++ needs to know is there. As I said, I've done this in Fortress and we can use that code in ecm++ as well. And we could implement setter injection with some kind of auto wiring as well. It's not really that harder. But using setters again requires to code more than using a constructor. I'm with Gianugo on this one - I'd better have setter injection instead of constructor injection. Actually the problem I see with setter injection is that you normally will open up the setter method (make it public) to your configurator/instatiator and thus to everybody else. Now, don't tell my 'you can write some IF satements to prevent that. The reason for a change as Carsten stated was 'I want to write less code'. The constructor injection IMO allows you to make your member variable holding the injected objects final as well as checking whether the component is correctly constructed (especially if it needs a Configuration object) in the constructor itself. So for me constructor injection (and only constructor injection, no mixes allowed) is much more robust over setter injection and needs less code. For these issues I'm more in favor of constructor injection (if we have the vision to go the pure way) than setter injection. In *addition* to setter injection, ecm++ could also recognize annotations (if running under jdk 1.5). I do not exclude annotations be it 1.5 annotations or other xdoclet style. - -- 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) iD8DBQFDtY5GLNdJvZjjVZARApaaAKDESVZxrBJY6sGXt1k3LuLg9uVJvQCfTU2Z oHN4+3eF+r9QCxPI8iyEFNs= =ZH65 -END PGP SIGNATURE-
Re: [RT] Simplifying component handling
Giacomo Pati wrote: On Fri, 30 Dec 2005, Vadim Gritsenko wrote: Carsten Ziegeler wrote: Gianugo Rabellino wrote: I'm definitely not a fan of constructor injection, exp. when we consider how (way too) often we resorted to inheritance in Cocoon components. Now, while interface injection is clearly out of fashion, sticking with Avalon/Excalibur also means that it would be difficult to get around the container (e.g., how do you release components with your approach? I assume Excalibur still kinda needs that). Yes, Excalibur still needs it - but it's easy. Bascially, you emulate the service() method on construction of the object and then you emulate the dispose method when destroying the object. Everything our ecm++ needs to know is there. As I said, I've done this in Fortress and we can use that code in ecm++ as well. And we could implement setter injection with some kind of auto wiring as well. It's not really that harder. But using setters again requires to code more than using a constructor. I'm with Gianugo on this one - I'd better have setter injection instead of constructor injection. Actually the problem I see with setter injection is that you normally will open up the setter method (make it public) to your configurator/instatiator and thus to everybody else. service() method is already public, so I don't see any departure from existing practice. Now, don't tell my 'you can write some IF satements to prevent that. The reason for a change as Carsten stated was 'I want to write less code'. The constructor injection IMO allows you to make your member variable holding the injected objects final as well as checking whether the component is correctly constructed If goal is to write *less* code then this code won't have any checks at all :) Regardless whether it is constructor or setter injection, checks can be written same way anyway, so I don't see this as an argument. As for final, that's actually and IMHO a downside: currently you can null out all component references (and you can do that automatically with setter injection! whoo-hooo! yeay!) and be *sure* that even if there are any leaks in system, they are minimized. You can also be sure that you will get clear NPE if somebody holding using disposed component, instead of getting undetermined behavior. So I'm -1 on final references for all of the above reasons. (especially if it needs a Configuration object) in the constructor itself. So for me constructor injection (and only constructor injection, no mixes allowed) is much more robust over setter injection and needs less code. For these issues I'm more in favor of constructor injection (if we have the vision to go the pure way) than setter injection. In *addition* to setter injection, ecm++ could also recognize annotations (if running under jdk 1.5). I do not exclude annotations be it 1.5 annotations or other xdoclet style. Yep. Xdoclet, though, means pre-processing step - annotations are nicer in this context. Vadim
Re: [RT] Simplifying component handling
On 12/30/05, Giacomo Pati [EMAIL PROTECTED] wrote: On Fri, 30 Dec 2005, Vadim Gritsenko wrote: Carsten Ziegeler wrote: Gianugo Rabellino wrote: I'm definitely not a fan of constructor injection, exp. when we consider how (way too) often we resorted to inheritance in Cocoon components. Now, while interface injection is clearly out of fashion, sticking with Avalon/Excalibur also means that it would be difficult to get around the container (e.g., how do you release components with your approach? I assume Excalibur still kinda needs that). Yes, Excalibur still needs it - but it's easy. Bascially, you emulate the service() method on construction of the object and then you emulate the dispose method when destroying the object. Everything our ecm++ needs to know is there. As I said, I've done this in Fortress and we can use that code in ecm++ as well. And we could implement setter injection with some kind of auto wiring as well. It's not really that harder. But using setters again requires to code more than using a constructor. I'm with Gianugo on this one - I'd better have setter injection instead of constructor injection. Actually the problem I see with setter injection is that you normally will open up the setter method (make it public) to your configurator/instatiator and thus to everybody else. I guess we could waste a near to infinite number of electrons debating the various IoC types and their downsides, so I won't delve any further on this (apart from +1ing Vadim's reply to your concerns, exp. the part about final members). My point is actually a tad different: like it or not, we are still working with Avalon which is interface-injection based: bastardizing the model with some clever hacks won't get us anywhere and will just confuse people. Now, if we were to completely change the approach, this discussion might have much more sense, but arguing about it while sticking with Avalon is moot, IMHO. Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: [RT] Simplifying component handling
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 30 Dec 2005, Vadim Gritsenko wrote: Date: Fri, 30 Dec 2005 15:06:34 -0500 From: Vadim Gritsenko [EMAIL PROTECTED] Reply-To: dev@cocoon.apache.org To: dev@cocoon.apache.org Subject: Re: [RT] Simplifying component handling Giacomo Pati wrote: Actually the problem I see with setter injection is that you normally will open up the setter method (make it public) to your configurator/instatiator and thus to everybody else. service() method is already public, so I don't see any departure from existing practice. With 'the pure way' I mean getting rid of *ALL* Avalon artifacts methodologies. This includes the Serviceable/service() stuff. Now, don't tell my 'you can write some IF satements to prevent that. The reason for a change as Carsten stated was 'I want to write less code'. The constructor injection IMO allows you to make your member variable holding the injected objects final as well as checking whether the component is correctly constructed If goal is to write *less* code then this code won't have any checks at all :) I a pure setter based system you cannot determine when a component has been fully initialized unless you have the initialize() method/Lifecycle Carsten was mentioning (to signal the end of 'configuration' to the component). With pure constructor injection you'll have that again right in the constructor to check completness. Regardless whether it is constructor or setter injection, checks can be written same way anyway, so I don't see this as an argument. Yes, the checks have to be made anyway, but see above. As for final, that's actually and IMHO a downside: currently you can null out all component references (and you can do that automatically with setter injection! whoo-hooo! yeay!) and be *sure* that even if there are any leaks in system, they are minimized. You can also be sure that you will get clear NPE if somebody holding using disposed component, instead of getting undetermined behavior. So I'm -1 on final references for all of the above reasons. I don't see the reason to zap out the Logger, Configuration, Context. I have to admit that I don't see component injections (as Carsten suggested) as we do have too much dynamic in cocoon for many of our components as they do not know which one they will depend upon before consulting a Configuration or maybe the Context. My vision ATM would be some kind of ServiceManager injection instead of multiple Components. Of course this leads to looking up the needed services from that ServiceManager but I don't see a way around it ATM. (especially if it needs a Configuration object) in the constructor itself. So for me constructor injection (and only constructor injection, no mixes allowed) is much more robust over setter injection and needs less code. For these issues I'm more in favor of constructor injection (if we have the vision to go the pure way) than setter injection. In *addition* to setter injection, ecm++ could also recognize annotations (if running under jdk 1.5). I do not exclude annotations be it 1.5 annotations or other xdoclet style. Yep. Xdoclet, though, means pre-processing step - annotations are nicer in this context. I'm almost sure that Cocoon 2.2 will stay 1.4 compatible for another year at least. So an approach with Xdoclet or qdox (see Maven2's Mojo's) will be the only way to go ATM. Anyway, unless we decide to get rid of the Avalon interfaces/Lifecycle _completely_ this discussion is useless as Gianugo stated in his reply. - -- 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) iD8DBQFDtaDILNdJvZjjVZARAjbpAJ0SGm7NlmJ+QhrRMU5RxC6YrglZcACgl6M9 jho9rnXTUscLlDAVfiCFVV0= =nUyY -END PGP SIGNATURE-
Re: [RT] Simplifying component handling
Giacomo Pati wrote: I'm almost sure that Cocoon 2.2 will stay 1.4 compatible for another year at least. So an approach with Xdoclet or qdox (see Maven2's Mojo's) will be the only way to go ATM. Have a look at http://retrotranslator.sourceforge.net/ Real JDK 1.5 annotations (and more) with JDK 1.4! Anyway, unless we decide to get rid of the Avalon interfaces/Lifecycle _completely_ this discussion is useless as Gianugo stated in his reply. Agree. Sylvain -- Sylvain WallezAnyware Technologies http://bluxte.net http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: [RT] Simplifying component handling
Sylvain Wallez wrote:
But I think it can even get easier:
1. Let's just assume that every component is ThreadSafe - unless
otherwise stated - no need to declare the interface anymore. I think
apart from the interpreter most components are threadsafe or poolable
anyway.
This is a huge change compared to the current behaviour, where no
interface means not threadsafe and not reusable. IMO, this change can
only happen if we completely move away from Avalon.
This is not the safe assumption, and can cause unexpected side-effects
in user's code. This is not a 2.x change.
2. Let's remove support for pooled components - yes, seriously. Fiddling
with the pool sizes is really annoying. We have a working factory
approach for sitemap components, so why not simply use it overall? And
rewriting the remaining pooled components shouldn't be that hard. (I now
that we are proxying pooled components to simplify the lookup, but you
still have to configure pool sizes).
+1 for generalizing the factory pattern. Cocoon spends way too much
time in checking Avalon's lifecycle interfaces and parsing
configuration objects.
Well, a better pool like the MPool package at D-Haven will help. MPool
is the managed pool that will shrink pool sizes at a slower rate,
removing the need to think about pool sizes in general (i.e. no
deferring back to factory method).
The big thing about Avalon based components is the startup time due to
the configuration element parsing, etc.
Now, I will say that getting rid of component pooling will require a
major overhaul of the Cocoon internals.
My final idea is to use even more magic (but it might be too much
magic?):
class MyComponent implements SOMETHING {
protected final ClassA component_A;
protected final ClassB component_B;
}
When the component is instantiated all instance variables prefixed with
component_ are setup using some injection mechanism - or perhaps using
annotations?
Hmm...
- how do you unit test Cocoon without the container? By subclassing to
access the protected fields?
- we can't strongly enforce the contract of subclasses by making some
fields private.
- the naming convention weakens the strong typing of Java. What if you
write conponent_A? Chasing the NPE won't be easy...
Danger Will Robinson!
In addition to the reasons listed by Sylvain, you are deviating far into
left field from what the average Java developer is used to.
Now, in the end I really want to write less code :)
Use Ruby :-P
Seriously, I agree that writing less code is good, but not at the
price of too black magic implying weaker contracts.
Agreed. To achieve the goal of less code would require major overhauls
of the entire system.
Re: [RT] Simplifying component handling
On Dec 30, 2005, at 12:09 PM, Carsten Ziegeler wrote:
Aren't you tired of implementing a service/dispose combo for each of
your components over and over again? Now, actually, I am. Big time.
If you look at several of our components, they do something like this:
class MyComponent implements SOMETHING, ThreadSafe, Disposable,
Serviceable {
protected ClassA compA;
protected ClassB compB;
protected ServiceManager m;
public void service(ServiceManager m) {
this.m = m;
compA = (ClassA)m.lookup(ClassA.ROLE);
compB = (ClassB)m.lookup(ClassB.ROLE);
}
public void dispose() {
if ( m != null ) {
m.release(compA);
m.release(compB);
}
}
Way too much code me thinks. So what about:
Come on! how many components do you write a day that 10 lines and 184
characters is too much? Sure less code and fewer interfaces are good
things in general and I don't mind switching to constructor injection
but give me a better reason than you want to write less code.
class MyComponent implements SOMETHING, ThreadSafe {
protected final ClassA compA;
protected final ClassB compB;
public MyComponent(ClassA a, ClassB b) {
compA = a;
compB = b;
}
}
We could simply add constructor injection: if the implementation does
not provide a default constructor, the available constructor is called
using reflection and the components are injected on construction of
the
object - no need to configure something in any xml configuration file.
Implementing this is easy - I did this already years ago for Fortress.
But I think it can even get easier:
1. Let's just assume that every component is ThreadSafe - unless
otherwise stated - no need to declare the interface anymore. I think
apart from the interpreter most components are threadsafe or poolable
anyway.
I don't like assumptions like this. I see deadlocks in your future.
2. Let's remove support for pooled components - yes, seriously.
Fiddling
with the pool sizes is really annoying. We have a working factory
approach for sitemap components, so why not simply use it overall? And
rewriting the remaining pooled components shouldn't be that hard.
(I now
that we are proxying pooled components to simplify the lookup, but you
still have to configure pool sizes).
I make extensive use of the factory pattern and in some instances my
factories use pools. Just because you use factories does not mean you
can eliminate pooling. Now if you'd like to implement self monitoring
pooling that tunes itself I think we'll all be happy.
My final idea is to use even more magic (but it might be too much
magic?):
class MyComponent implements SOMETHING {
protected final ClassA component_A;
protected final ClassB component_B;
}
When the component is instantiated all instance variables prefixed
with
component_ are setup using some injection mechanism - or perhaps
using
annotations?
Now, in the end I really want to write less code :)
sounds lazy to me, but then again I don't want to write any code I
just want to think of something and have it work. :-)
Glen Ezkovich
HardBop Consulting
glen at hard-bop.com
A Proverb for Paranoids:
If they can get you asking the wrong questions, they don't have to
worry about answers.
- Thomas Pynchon Gravity's Rainbow
Re: [RT] Simplifying component handling
On 30.12.2005, at 20:21, Vadim Gritsenko wrote: Carsten Ziegeler wrote: Gianugo Rabellino wrote: I'm definitely not a fan of constructor injection, exp. when we consider how (way too) often we resorted to inheritance in Cocoon components. Now, while interface injection is clearly out of fashion, sticking with Avalon/Excalibur also means that it would be difficult to get around the container (e.g., how do you release components with your approach? I assume Excalibur still kinda needs that). Yes, Excalibur still needs it - but it's easy. Bascially, you emulate the service() method on construction of the object and then you emulate the dispose method when destroying the object. Everything our ecm++ needs to know is there. As I said, I've done this in Fortress and we can use that code in ecm++ as well. And we could implement setter injection with some kind of auto wiring as well. It's not really that harder. But using setters again requires to code more than using a constructor. I'm with Gianugo on this one - I'd better have setter injection instead of constructor injection. Maybe this is becoming a bit OT but could you guys give some reasons why? I personally prefer contructor injection over setter injection because of the clear contract. As soon as the object is instantiated it can be used. With setter injection you have to have some weird behind the scenes object life-cycle. cheers -- Torsten PGP.sig Description: This is a digitally signed message part
Re: [RT] Simplifying component handling
Torsten Curdt wrote: On 30.12.2005, at 20:21, Vadim Gritsenko wrote: Carsten Ziegeler wrote: Gianugo Rabellino wrote: I'm definitely not a fan of constructor injection, exp. when we consider how (way too) often we resorted to inheritance in Cocoon components. Now, while interface injection is clearly out of fashion, sticking with Avalon/Excalibur also means that it would be difficult to get around the container (e.g., how do you release components with your approach? I assume Excalibur still kinda needs that). Yes, Excalibur still needs it - but it's easy. Bascially, you emulate the service() method on construction of the object and then you emulate the dispose method when destroying the object. Everything our ecm++ needs to know is there. As I said, I've done this in Fortress and we can use that code in ecm++ as well. And we could implement setter injection with some kind of auto wiring as well. It's not really that harder. But using setters again requires to code more than using a constructor. I'm with Gianugo on this one - I'd better have setter injection instead of constructor injection. Maybe this is becoming a bit OT but could you guys give some reasons why? I personally prefer contructor injection over setter injection because of the clear contract. As soon as the object is instantiated it can be used. With setter injection you have to have some weird behind the scenes object life-cycle. Well, personal preferences aside, there are pros and cons in any situation. First, any component that is able to be accessed is fully instantiated. Nothing more needs to be done. Setter injection vs. Constructor injection doesn't change a thing here. Both styles of code encorage different coding conventions. Setter Injection --- Familiar JavaBean style interface, natural to many Java developers, and easy to use introspection based tools. Encorages failsafe design so that almost all components are optional. In short, the absense of other components cause the bean to work with diminished capacity. An example is the DataSource object from the SQL package. In fact, that component would work out of the box in this type of environment. Constructor Injection - Very robust design, less familiar to many Java developers, but natural enough. Encourages tight encapsulation and failfast design so that almost all components are required. In short, the absense of other components can cause the component to crash. Examples include just about any unmodifiable POJO object. Spring is the XML laden container of choice for Setter Injection while Pico is the code it yourself container of choice for Constructor Injection. My personal preference would be for Pico primarily because it is not nearly so XML heavy. Also note that Pico can work with setter injection as well as constructor injection. My Java5 Dojo container works with Setter injection out of the box, and can easily be extended for constructor injection. Through the Multi-Dojo wrapper, it could have components designed for either style of development work seamlessly with each other. Even if you don't use it, you might take a look at the code. It's pretty straight-forward and a simple design.
Re: [RT] Simplifying component handling
On Saturday 31 December 2005 11:47, Berin Loritsch wrote: Also note that Pico can work with setter injection as well as constructor injection So does Spring. Cheers Niclas
Re: [RT] Simplifying component handling
On Saturday 31 December 2005 02:09, Carsten Ziegeler wrote:
My final idea is to use even more magic (but it might be too much magic?):
class MyComponent implements SOMETHING {
protected final ClassA component_A;
protected final ClassB component_B;
}
Yipee, yet another thread on a new container architecture. Can't wait to see
the hours of debate leading up to no change...
Honestly guys, I'm starting to think that Cocoon won't manage to do the
separation from Avalon, purely due to the number of ways to do it exceeds the
number of strong-willed people in the community, and disagreements of what is
the best move.
Time for me to close the shop, and start with something more exciting.
Bye and Good Luck.
Niclas Hedhman
