You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Max Pfingsthorn <m....@hippo.nl> on 2006/01/02 12:35:27 UTC
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
Posted by Bertrand Delacretaz <bd...@apache.org>.
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
Re: [RT] Simplifying component handling
Posted by Sylvain Wallez <sy...@apache.org>.
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 Wallez Anyware Technologies
http://bluxte.net http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: [RT] Simplifying component handling
Posted by Bertrand Delacretaz <bd...@apache.org>.
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
Re: [RT] Simplifying component handling
Posted by Ralph Goers <Ra...@dslextreme.com>.
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
Posted by Giacomo Pati <gi...@apache.org>.
-----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 <cz...@apache.org>
> 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
Posted by Carsten Ziegeler <cz...@apache.org>.
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, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: [RT] Simplifying component handling
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
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
Posted by Carsten Ziegeler <cz...@apache.org>.
Sylvain Wallez wrote:
>
> Carsten, what's wrong with the Spring bridge?
>
See my reply from today.
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
Posted by Sylvain Wallez <sy...@apache.org>.
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 Wallez Anyware Technologies
http://bluxte.net http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: [RT] Simplifying component handling
Posted by Carsten Ziegeler <cz...@apache.org>.
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, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: [RT] Simplifying component handling
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
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
Posted by Sylvain Wallez <sy...@apache.org>.
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 Wallez Anyware Technologies
http://bluxte.net http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: [RT] Simplifying component handling
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
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 opinions: Users should be able to use any container.
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.
/Daniel
Re: [RT] Simplifying component handling
Posted by Vadim Gritsenko <va...@reverycodes.com>.
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
Posted by Sylvain Wallez <sy...@apache.org>.
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 Wallez Anyware Technologies
http://bluxte.net http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: [RT] Simplifying component handling
Posted by Carsten Ziegeler <cz...@apache.org>.
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: The Apple-Intel analogy
Posted by Reinhard Poetz <re...@apache.org>.
Torsten Curdt wrote:
>> IMO Cocoon should go the same way. The recent thread
>> about a complete rewrite of Cocoon *really* scares me
>> and a lot of people I've talked to as it will break
>> compatibility for sure.
>
> Fear has always been the main blocker for new technologies.
Well, I haven't talked about what my (many's) fear is: We have been talking
about blocks for ages. After years we will get them. We are good in talking
about design and architecture but the usual Cocoon committer can only dedicate a
fraction of his time to enhance and improve Cocoon.
Considering this situation I have the fear that we will have a good concept (and
maybe some prototyp) in the end, that will block all future improvments as
everybody is waiting for the much, much better next revolutionary step.
Compared to this I like Daniel's vision much more because he outlines a way how
we get major improvments evolutionary. After splitting up Cocoon in many small
parts (blocks) and refactoring them to POJOs, we can reimplement the core which
should become much simpler if the core has been stripped down to its minimum.
This also makes it much easier for us to keep our *current* userbase as they can
follow us making small steps. This also has a positive impact on the quality
because we never have the chicken-egg-situation that we are waiting for users
that should use the new, shiny (alpha) version of Cocoon and they are waiting
that the new Cocoon gets officially realeased. As Mr. Javaflow you should know
this situation ;-).
I do not fear new technologies - I'm maybe the only one who is using Cocoon from
trunk in a serious project - but I do fear making the same mistake that we did
with 2.1 --> 2.2 again.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: The Apple-Intel analogy
Posted by Torsten Curdt <tc...@apache.org>.
> I think the Apple move to Intel processors is a good
> example.
Same here!
> Apple is changing its fundaments but the
> building above, the operating systems, remains the
> same and all your applications won't stop to work.
That's not true ...you have to port applications to
the new platform. But Apple has prepared developers
very well on how to do the migration. Of course we
would have to that too.
> The
> average user won't even notice that the processor has
> changed.
Let's hope they will ;)
> IMO Cocoon should go the same way. The recent thread
> about a complete rewrite of Cocoon *really* scares me
> and a lot of people I've talked to as it will break
> compatibility for sure.
Fear has always been the main blocker for new technologies.
I thought it was already clear that what (I think) most
people want is not necessarily to really rewrite from
scratch but the freedom to reevaluate and change every-
thing if they think it's a good change ...without the
"no, we cannot do that to our existing customers"
There is no doubt we need migration strategies ...but
there is also no doubt we are currently locked into
some not even so clear and old contracts.
THIS is what people (or at least I) want to change.
<snip/>
> I also consider it as dangerous as it might
> lead to fractions within the community and we start
> again to split our limited time that we can dedicate
> to the devleopment of Cocoon into two projects for
> years (again).
I am sure it will also create fraction if we don't
move on with some innovations that are just too much
for the current codebase.
cheers
--
Torsten
Re: The Apple-Intel analogy
Posted by Sylvain Wallez <sy...@apache.org>.
Reinhard Poetz wrote:
> I think the Apple move to Intel processors is a good
> example. Apple is changing its fundaments but the
> building above, the operating systems, remains the
> same and all your applications won't stop to work. The
> average user won't even notice that the processor has
> changed.
>
For this migration, that's true, but...
> IMO Cocoon should go the same way. The recent thread
> about a complete rewrite of Cocoon *really* scares me
> and a lot of people I've talked to as it will break
> compatibility for sure.
>
...remember a few years ago the migration from MacOS 9 to MacOS X:
everything changed, and that was a complete rewrite. There is the
MacClassic compatibility layer, that allows MacOS 9 applications to run
on MacOS X. With some limitations though, since MacOS 9 applications had
to be based on CarbonLib to have a chance to run on MacOS X.
At first, many users where angry because the new OS was breaking some of
their applications and because it was changing their habits. But now, a
few years later, no one would consider using again that old Mac OS 9. I
bought some Macs in 1987, 1995 and my PowerBook in 2003. I *never* used
MacClassic on my PowerBook.
My old Macs still work, and the 10 year old one is still used every
week-end. Just as we still have projects here running on Cocoon 1 and
are maintaining them. And contrarily to hardware, software doesn't have
the problem of failing parts for which you can't find a replacement.
> If I take Marc's proposal as some kind of common understanding within the community on where we want to go, I still fail to see why the revolution is necessary. I also consider it as dangerous as it might lead to fractions within the community and we start again to split our limited time that we can dedicate to the devleopment of Cocoon into two projects for years (again).
>
The architecture of the current Cocoon is too intimately tied to Avalon,
and doesn't really help to handle the new needs of XML processing and
webapp development. Cocoon must evolve or it will die.
Now we have to find our CarbonLib to prepare the migration to the next
major revision. Currently, I see it as being the sitemap language which
can be implemented on a different pipeline API, and the flowscript for
which a compatible object model can be built. Although some level of
compatibility can be provided, there will be some incompatibilities. But
new projects won't care.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://bluxte.net http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
The Apple-Intel analogy
Posted by Reinhard Poetz <re...@yahoo.de>.
--- Sylvain Wallez <sy...@apache.org> schrieb:
> Giacomo Pati wrote:
> > 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.
I think the Apple move to Intel processors is a good
example. Apple is changing its fundaments but the
building above, the operating systems, remains the
same and all your applications won't stop to work. The
average user won't even notice that the processor has
changed.
IMO Cocoon should go the same way. The recent thread
about a complete rewrite of Cocoon *really* scares me
and a lot of people I've talked to as it will break
compatibility for sure.
If I take Marc's proposal as some kind of common
understanding within the community on where we want to
go, I still fail to see why the revolution is
necessary. I also consider it as dangerous as it might
lead to fractions within the community and we start
again to split our limited time that we can dedicate
to the devleopment of Cocoon into two projects for
years (again).
--
Reinhard
___________________________________________________________
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: [RT] Simplifying component handling
Posted by Carsten Ziegeler <cz...@apache.org>.
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, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: [RT] Simplifying component handling
Posted by Sylvain Wallez <sy...@apache.org>.
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 Wallez Anyware Technologies
http://bluxte.net http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: [RT] Simplifying component handling
Posted by Giacomo Pati <gi...@apache.org>.
-----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
Posted by Sylvain Wallez <sy...@apache.org>.
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 Wallez Anyware Technologies
http://bluxte.net http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: [RT] Simplifying component handling
Posted by Carsten Ziegeler <cz...@apache.org>.
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
Posted by Giacomo Pati <gi...@apache.org>.
-----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 <cz...@apache.org>
> 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
Posted by Carsten Ziegeler <cz...@apache.org>.
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
Posted by Sylvain Wallez <sy...@apache.org>.
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 Wallez Anyware Technologies
http://bluxte.net http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: [RT] Simplifying component handling
Posted by Ezkovich Glen <gl...@hard-bop.com>.
On Jan 3, 2006, at 9:06 AM, Peter Hunsberger wrote:
> On 1/3/06, Giacomo Pati <gi...@apache.org> 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
Posted by Peter Hunsberger <pe...@gmail.com>.
On 1/3/06, Giacomo Pati <gi...@apache.org> 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
Posted by Giacomo Pati <gi...@apache.org>.
-----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 <sy...@apache.org>
> 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
Posted by Sylvain Wallez <sy...@apache.org>.
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 Wallez Anyware Technologies
http://bluxte.net http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: [RT] Simplifying component handling
Posted by Gianugo Rabellino <gi...@apache.org>.
On 1/3/06, Upayavira <uv...@odoko.co.uk> wrote:
> Reinhard Poetz wrote:
> > --- Carsten Ziegeler <cz...@apache.org> 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
Posted by Upayavira <uv...@odoko.co.uk>.
Reinhard Poetz wrote:
> --- Carsten Ziegeler <cz...@apache.org> schrieb:
>
>
>>Gianugo Rabellino wrote:
>>
>>>On 1/2/06, Ralph Goers
>>
>><Ra...@dslextreme.com> 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
Posted by Reinhard Poetz <re...@yahoo.de>.
--- Carsten Ziegeler <cz...@apache.org> schrieb:
> Gianugo Rabellino wrote:
> > On 1/2/06, Ralph Goers
> <Ra...@dslextreme.com> 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
Posted by Carsten Ziegeler <cz...@apache.org>.
Gianugo Rabellino wrote:
> On 1/2/06, Ralph Goers <Ra...@dslextreme.com> 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, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: [RT] Simplifying component handling
Posted by Gianugo Rabellino <gi...@apache.org>.
On 1/2/06, Ralph Goers <Ra...@dslextreme.com> 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
Posted by Ralph Goers <Ra...@dslextreme.com>.
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
Posted by Carsten Ziegeler <cz...@apache.org>.
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, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/