Re: rejuvenating the webdav block
On 12/20/05, Max Pfingsthorn <[EMAIL PROTECTED]> wrote: > > > On another note: I need the eventcaching block for webdav, but > > > that one only needs jms in one class, and databases in the > > > samples. So, I'll work on the dependency issue there instead of > > > in the webdav block directly. ... > The eventcache is needed for more advanced caching. The components need to > know about it to be able to construct the right Validity objects for > Source.getValidity(). We found out that eventcaching is really key for good > performance of the website, so I would consider it a good kind of dependency. > Of course, the eventcaching block depending (indirectly) on the database > block is a bit silly. Yes, these dependencies were always somewhat painful - as we discussed before [1]. It's only the samples that cause the dependency on the database block IIRC. There was some work being done on samples dependencies I think - or were samples being separated into samples blocks perhaps? That would cure this. I see you've implemented some of this in webdav - did you manage to avoid a dependency on the database block somehow? Geoff [1] http://marc.theaimsgroup.com/?t=11325928653&r=1&w=2
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
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
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
[jira] Closed: (COCOON-1385) [PATCH] Portlet ActionResponse.setWindowState() not working
[ http://issues.apache.org/jira/browse/COCOON-1385?page=all ] Carsten Ziegeler closed COCOON-1385: Resolution: Won't Fix I'll close this issue as the patch is against an old version and the patch addresses more things than this issue is about. Please recheck with the latest Cocoon version and eventually reopen this bug. > [PATCH] Portlet ActionResponse.setWindowState() not working > --- > > Key: COCOON-1385 > URL: http://issues.apache.org/jira/browse/COCOON-1385 > Project: Cocoon > Type: Bug > Components: Blocks: Portal > Versions: 2.1.6 > Environment: Operating System: All > Platform: Other > Reporter: Michal Durdina > Assignee: Cocoon Developers Team > Attachments: release_2_1_6.patch_11.diff > > ActionResponse.setWindowState() is not working. > Other issues solved by this patch: > - set of window state in action request must preserve current window state > till render request i.e. > a = ActionRequest.getWindowState(); > ActionResponse.setWindowState(b); > c = ActionRequest.getWindowState(); > this must be valid: c.equals(a) > byt currently it is not true > - window state set via ActionResponse.setWindowState() takes precendence > over > createActionURL().setWindowState() > - some full screen issues fixed -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (COCOON-1375) Bugfixes & enhancement to the Applicationproxy in the portal block
[ http://issues.apache.org/jira/browse/COCOON-1375?page=all ] Carsten Ziegeler closed COCOON-1375: Resolution: Won't Fix As there has been no feedback at all, I'll close this > Bugfixes & enhancement to the Applicationproxy in the portal block > -- > > Key: COCOON-1375 > URL: http://issues.apache.org/jira/browse/COCOON-1375 > Project: Cocoon > Type: Bug > Components: Blocks: Portal > Versions: 2.1.5 > Environment: Operating System: Windows 2000 > Platform: PC > Reporter: Gernot Koller > Assignee: Carsten Ziegeler > Attachments: patch-textual-description.txt, patch.txt > > We have made some modifications and bugfixes to the code which originally > came > from us, which we like to submit to the community. > We have made a unified diff and also a textual description of the changes. > But as it seems bugzilla cannot handle that much data in this description > field, so I am not sure how I can attacht the patch to this bug report... > So I'll try to commit this anyway, let's see if there is a way of attaching > once the report is committed... > thanks, > Gernot -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
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
-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
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: [2.2] Problems with JMX Support and Tomcat
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 2 Jan 2006, Carsten Ziegeler wrote: Date: Mon, 02 Jan 2006 16:46:38 +0100 From: Carsten Ziegeler <[EMAIL PROTECTED]> Reply-To: dev@cocoon.apache.org To: dev@cocoon.apache.org Subject: Re: [2.2] Problems with JMX Support and Tomcat Giacomo Pati wrote: On Mon, 2 Jan 2006, Carsten Ziegeler wrote: Date: Mon, 02 Jan 2006 11:00:32 +0100 From: Carsten Ziegeler <[EMAIL PROTECTED]> Reply-To: dev@cocoon.apache.org To: Cocoon-Dev Subject: [2.2] Problems with JMX Support and Tomcat I'm trying to get the latest 2.2 running in a standard tomcat 5.5.12 With the default webapp, the following class can't be found: org.mortbay.log.LogFactory So it seems that the jetty-jmx-5.1.8.jar does not contain all required classes. Copying also jetty-5.1.8.jar into WEB-INF/lib of course solves this problem. Hmm.. maybe we either need our own JMX ModelMBean base class, witching to commons modeler, or copy from jetty whats needed (as once Sylvain suggested)? "witching"? - LOL I can come up with a list of required classes for jetty's jmx support tomorrow. Perhaps it's only the LogFactory. If only some classes are missing, we can repackage them, but as soon as this gets more complex we can either ask the jetty guys to provide different packages or switch to something different. What about Spring? I don't know much about it but I think Spring has some jmx support as well. I don't know much about JMX support in spring either. I've checked what is needed from the jetty-jmx jar to make it usable for us. In the end I've managed to compile with just 2 classes from the jetty-jmx library (the ModelMBeanImpl and TypeUtil class) replacing jetty's LogFactory with the one from commons-logging. I don't know whether it's legal to just copy thoses two classes into our source tree (jetty is licensed under ASL 2.0). - -- 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) iD8DBQFDulcnLNdJvZjjVZARAhJKAJ9GWiNiLwSI92OPmGM7Hy4ruUDPOACfam79 dwisbBHVbaK+q5YmN0ONy3Y= =/szA -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, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
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
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: [vote] Jean-Baptiste Quenot as new Cocoon committer (was Re: Problem with CachingPointProcessingPipeline)
Andrew Savory wrote: Everyone: Jean-Baptiste is becoming more and more active on the dev list, and has been diligently filing bugs and patches for the last few months. The first post about his activity is from July, 2004 [1]. He seems to have a good grasp of the guts of Cocoon. I think it's time for him to become a committer. +1 /Daniel
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, S&N 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
[jira] Commented: (COCOON-1709) Speedup portal loading
[ http://issues.apache.org/jira/browse/COCOON-1709?page=comments#action_12361593 ] Jean-Baptiste Quenot commented on COCOON-1709: -- Ralph, I don't know why I don't get notified of your comments, not even on cocoon-dev. I made some tests, with or without cache (I added a boolean flag), and with or without Ralph's change on the Castor mapping, and the results are quite surprising: it seems that no caching is needed anymore with his change, but what I don't understand is that only the first profiles loading takes longer. The facts in milliseconds: loadProfile-without-cache-and-older-cocoon: 1551, 1014, 1403 loadProfile-without-cache-and-newer-cocoon: 505, 183, 174 loadProfile-with-cache-and-newer-cocoon: 601, 142, 113 I would expect that without cache, the newer Castor mapping would always take about 505ms. > Speedup portal loading > -- > > Key: COCOON-1709 > URL: http://issues.apache.org/jira/browse/COCOON-1709 > Project: Cocoon > Type: Improvement > Components: Blocks: Portal > Versions: 2.1.9-dev (current SVN) > Reporter: Jean-Baptiste Quenot > Attachments: 20051212-portal-MapProfileLS, 20051222-MapProfileLS.java, > 20051222-MapProfileLS.java, UserRoleSourceFactory.java, portal-config > > Portal loads user profiles (when using eg AuthenticationProfileManager) with > Castor every time the user logs in and this is very slow. This patch allows > to cache the result for further invocations. However the coplet instance > profiles are handled in a special way, after being obtained by mapping the > CopletInstanceDataManager they are cloned to ensure that every user gets its > own copy of the coplets. Thus this bug depends on > http://issues.apache.org/jira/browse/COCOON-1708 Allow > CopletInstanceDataManager to be cloneable. > An improvement would be to store cached objects in Cocoon Store, the provided > patch currently uses a simple HashMap to store profiles. Note that the key > of the object is the URI returned by the source. This is important because > different values of uri in resolver.resolveURI(uri) could return the same > source, ie source.getURI() could be the same, so only different objects are > stored in the Map. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
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, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
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
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: mvn compile for core block fails in 2.2 snapshot
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 1 Jan 2006, Rice Yeh wrote: Date: Sun, 1 Jan 2006 14:58:12 +0800 From: Rice Yeh <[EMAIL PROTECTED]> Reply-To: dev@cocoon.apache.org To: dev@cocoon.apache.org Subject: mvn compile for core block fails in 2.2 snapshot Hi, I checked out the 2.2 source code and use 'mvn compile' to compile the source code and got the following error: [INFO] Compilation failure C:\apache\cocoon.home\svn\trunk\core\..\src\java\org\apache\cocoon\components\fl ow\ContinuationsManagerImplMBean.java:[20,28] package org.mortbay.util.jmxdoes not exist C:\apache\cocoon.home\svn\trunk\core\..\src\java\org\apache\cocoon\components\fl ow\ContinuationsManagerImplMBean.java:[25,24] package javax.management does not exist C:\apache\cocoon.home\svn\trunk\core\..\src\java\org\apache\cocoon\components\fl ow\ContinuationsManagerImplMBean.java:[26,24] package javax.management does not exist C:\apache\cocoon.home\svn\trunk\core\..\src\java\org\apache\cocoon\components\fl ow\ContinuationsManagerImplMBean.java:[35,8] cannot resolve symbol symbol : class ModelMBeanImpl location: class org.apache.cocoon.components.flow.ContinuationsManagerImplMBean It seems the dependency set is not well maintained. Yes, my fault. I'll fix them. - -- 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) iD8DBQFDujRnLNdJvZjjVZARAoCmAKCayfW/3XafSKroTaMXiAD1r6tBzwCfd1GA BmE4DLzCPNodi+W3Zk3FYO8= =T/Ui -END PGP SIGNATURE-
