You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Ugo Cei <ug...@apache.org> on 2004/10/13 18:59:42 UTC
[RT] Some notes about the "Real Blocks" issue
Folks,
here are some notes I jotted down today while on the train and later on
the plane, on my way back home from the GT, on the issues we discussed
Monday WRT "Real Blocks", Butterfly, Kernel (Tani), Spring, blah blah
blah
Take it as just an outline to fill with your
opinions/suggestions/critiques. As soon as it starts coalescing into
something sensible, we should put it on the Wiki.
My ideas on what should be used _inside_ blocks are rather clear, but I
especially need input on the thing (should we call it Tani, Kernel,
something else?) that is supposed to contain blocks, manage their
dependencies, make it possible for components defined in one block to
refer to components defined in another block, etc. What will it look
like, in practice?
Here we go:
- [ ] GT2004 notes
- [ ] Two levels of containment
- [ ] Intra-block
Defining components and wiring them together inside a
single block can be done with a dependency-injection
type of container. We can do a tentative
implementation using Spring.
- [ ] Inter-block
There should be a container for blocks which should
provide block deployment, classloader isolation and
of course the means by which components defined in
one block can be wired to components defined in
another block.
- [ ] Two kernels?
- [ ] Phase 1 kernel
- [ ] No downloading of blocks from repositories
- [ ] Blocks statically defined, no live deployment
- [ ] No hot swapping
- [ ] No versioning
- [ ] Might be used for development
- [ ] Two kinds of blocks: Avalon (legacy) and Spring as
containers
We need to support Spring (or Picocontainer,
HiveMind or something of our own doing) and
Avalon (for backward compatibilty) ONLY. ONE new
type of container will be supported, otherwise
it's just FS. This container should be
non-invasive, so that we might reuse components
if we, later on, decide to change the container's
implementation.
- [ ] Phase 2 kernel
- [ ] Downloading of blocks from repositories
- [ ] Live deployment without restarting
- [ ] Hot swapping (maybe)
- [ ] Versioning (for sure)
- [ ] Might use something like GBeans from Geronimo
- [ ] Configuration
- [ ] The sitemap
The sitemap will define pipelines and possibly blocks
to be loaded at startup or, alternatively, parameters
for connecting to a naming service that will locate
remote blocks.
Use standards where possible for the naming service,
e.g. LDAP and/or JNDI.
- [ ] The block context specification
The block context specification will define:
1. components hosted inside this block and their
dependencies a-la Spring
2. Interfaces provided by this block to the external
world (public contracts) [?]
- [ ] Everything goes inside blocks
Even core components, like the FileGenerator. Cocoon's
new core is made up only of a sitemap processor and block
deployer.
Q: should a specific environment implementation (e.g.
servlet, cli) be its own block, so that applications that
don't need it won't load the block?
Q: could the flowscript interpreter be its own block?
- [ ] Geronimo/JMX?
This thread:
http://thread.gmane.org/gmane.comp.java.springframework.devel/4910
might provide some suggestions re the
implementation of the kernel.
- [ ] Plan of action
- [ ] 1. Define some use cases
- [ ] 2. Write tests
- [ ] 3. Implement complete use cases in the simplest possible
way
Use a "Tracer Bullets" approach (see The Pragmatic
Programmer, item #10).
- [ ] 4. Refactor mercilessly
--
Ugo Cei - http://beblogging.com/
Re: [RT] Some notes about the "Real Blocks" issue
Posted by Sylvain Wallez <sy...@apache.org>.
Ugo Cei wrote:
> Folks,
>
> here are some notes I jotted down today while on the train and later
> on the plane, on my way back home from the GT, on the issues we
> discussed Monday WRT "Real Blocks", Butterfly, Kernel (Tani), Spring,
> blah blah blah
>
> Take it as just an outline to fill with your
> opinions/suggestions/critiques. As soon as it starts coalescing into
> something sensible, we should put it on the Wiki.
Damn, I also prepared a RT on this subject while in the plane this
evening, in a different style. It would be interesting to split its
content in the different items of our plan. I won't be much available
until next wednesday, so here it is...
The original subject is "[RT] Towards a POJO-based Cocoon"
There was a panel discussion during the GT hackaton to finally decide
what we want the kernel and the Cocoon component model to be.
The starting consensus that drives all the rest is that we no more want
to explicitely depend on a container API. Avalon was the state of the
art 4 years ago, but things have changed a lot since then both
technically with the emergence of dependency injection (DI) and socially
with the problems that led to the death of the Avalon community. This
consensus means that, in order to be future-proof, both blocks and
components inside blocks must be POJOs (plain old java objects) hosted
by a container providing dependency injection. That is the only way that
will allow components to resist a major change in the container used,
should it happen again.
There are two levels in containment in Cocoon, corresponding to
different needs:
- the kernel, which is the root container that hosts blocks: it must
provide classloader shielding of the blocks contents, wiring of blocks
through DI and managing static factories (jaxp/trax/commons logging
etc). Thats basically all. We decided to abandon, at least for now, the
idea of hot deployment of blocks which is a complicated problem when
inter-block wirings have to be updated. In case of change in the
deployment, a global reload will be performed similarily to what is done
today with the "cocoon-reload" request parameter.
- the container for components within a block (aka "intra-block
container"): this is where pipeline components will live, along with
business-logic components. There is no need for classloader shielding
here, but the need for more J2EE-oriented features like transaction
management, datasource pooling etc.
For the intra-block container, a good candidate exists today, which is
quickly becoming a defacto standard because it deserves it: the Spring
framework. It's more than a container, as it provide a great lot of
interesting features (as POJOs) helping to quickly develop robust and
efficient business logic.
For the kernel container, there is no such defacto standard, and adding
classloader-shielding to Spring is overkill as we only need a very small
amount of its features. The kernel must be small, efficient and
rock-solid. Some partial solutions exist today: Pier's Tani which
provides classloader shielding but not dependency injection, and
PicoContainer that provides dependency injection but not classloader
shielding. We have to choose an existing base and augment it to suit our
needs.
Something that has to be taken into account is the existing component
base: over the years, a number of people have invested in proprietary
components based on the Avalon APIs. We cannot tell them to trash their
stuff and rewrite it to use the new Cocoon. So we need some kind of
legacy support for the Avalon framework APIs so that only minimal update
is necessary to existing code or even no update at all. Fortunately,
Spring may allow us to provide this legacy support, through its
BeanFactory mechanism. A BeanFactory in Spring is responsible for
creating a component upon request of the container. How this object is
created is only a concern of the factory. So we could have an
AvalonBeanFactory that would allow to host Avalon components within a
Spring container, going through the lifecycle interfaces when a
component is created and providing a wrapper showing the Spring
container as a ServiceManager.
Something that has to be decided is if we're to make a revolution or a
big evolution. IMO, this should be an evolution. The installed base is
too large to allow use to have something completely different just
because we want to change component handling. The ServiceManager wrapper
on top on Spring may be the way to allow the revolution in the core to
appear like an evolution to the upper-level code, thus allowing a smooth
transition.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [RT] Some notes about the "Real Blocks" issue
Posted by Ugo Cei <ug...@apache.org>.
Il giorno 13/ott/04, alle 18:59, Ugo Cei ha scritto:
> - [ ] Geronimo/JMX?
> This thread:
>
> http://thread.gmane.org/gmane.comp.java.springframework.devel/4910
> might provide some suggestions re the
> implementation of the kernel.
I just came upon this interview with Aslak Hellesoy on The Server Side
<http://www.theserverside.com/talks/videos/AslakHellesoy/dsl/
textFull.html>. It was published a few days ago but I hadn't seen it
yet. I'll paste a brief quote:
"[The Geronimo developers] have been thinking about this since they’ve
been writing the thing, that if you think about Geronimo as the outer
container, if you think of it as a bucket. They have a lot of goodies
in that bucket, like connection pooling, transaction management,
integration with messaging systems and all that. And if you think of
that bucket in a classical J2EE container, in order to benefit from
these things, you have to stick in something that looks like a J2EE
component.
What they are actually doing is, they are sticking a smaller bucket
inside that, that sort of acts as a glue between Pico and Geronimo. So
let us say I am writing this component that needs, for example, a
connection pool. Now what I can do, I can write my class and I could
say in constructor, I could say I want a connection pool. I can drop it
inside Pico, which is inside Geronimo now, and Geronimo will give it
the connection pool, so it is simple."
I find this is very similar to what we're trying to do with the new
kernel. And it works with Spring as well as with Pico.
Now the question is: can a Cocoon block be a GBean? And if it can,
should we either:
1. Borrow some ideas from Geronimo and do our own thing?
2. Borrow some code from Geronimo and adapt it to our needs?
3. Build a "lightweight" version of Geronimo (no J2EE stuff, just
servlets) to use as our kernel?
4. None of the above?
WDYT?
Ugo
--
Ugo Cei - http://beblogging.com/
Some information on Cocoon Block Deployer
Posted by Reinhard Poetz <re...@apache.org>.
Ugo Cei wrote:
> Folks,
...
> - [ ] No downloading of blocks from repositories
...
Because of some discussions at Gent I think there are some people more having a
wrong impression of what the Cocoon Block deployer (CBD) does. Expressed in
simple terms it is a library that extracts the content of a COB file into the
blocks directory of a Cocoon installation. BTW, Commons transaction, which
provides filesystem transactions, works in my first tests really well!
As it is only a library, a client is needed that uses it. I want to provide an
Ant task that can install a bunch of COBs. But in the future having something
like a Eclipse wizard would be nice. For now the library is only used in unit tests.
Beside installing a COB file, the CBD is able to access COB libraries. For the
time being I only support the file system but integrating something like a web
service providing blocks should be very straight forward (only a new locator
implementation within the CBD library is necessary). Anybody volunteering
writing a Cocoon application that provides blocks via web services? (This should
be very easy!!!)
Finally I want to say what the CBD is NOT:
- It's not an implementation of "real blocks". It's only about their installation.
- There is no direct interface between the block machinery in Cocoon and its
deployment. If Cocoon finds a new block installed (extracted) in the block
directory it uses it. So I was able to start with the CBD because it should work
with any block solution we agree on. How the block.xml and wiring.xml finally
look like, isn't important ATM.
--
Reinhard
Re: [RT] Some notes about the "Real Blocks" issue
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Stefano Mazzocchi wrote:
> You can fool yourself with Serviceable instead of Composable and shit
> like that, but the truth is: many many many times
>
> Generator file = new FileGenerator(src,handler,parameters);
>
> would have been enough!!
Well you refer to some overcomponentization in Cocoon, but Generator is not the
place where it is happening. More like XML compiler/decompiler, which might be
simple class instead of component.
And in other places we have undercomponentization as well, example is
[Image|MP3|*]DirectoryGenerator, where you need pluggable file introspection
helpers.
Vadim
Re: [RT] Some notes about the "Real Blocks" issue
Posted by Stefano Mazzocchi <st...@apache.org>.
Ugo Cei wrote:
> Il giorno 14/ott/04, alle 18:09, Vadim Gritsenko ha scritto:
>
>> Other question I have is what we are going to do with the component
>> base we developed and depend on which currently resides in excalibur
>> repository. Should those be copied into Cocoon repository (and
>> springified as needed?)?
>
>
> Things like the SourceResolver, you mean? I have already "springified"
> it and put it (or at least a simplified version of it) here:
> http://svn.apache.org/repos/asf/cocoon/whiteboard/butterfly/src/java/
> org/apache/butterfly/source/
>
> Actually, I don't like the term "springified". I'd rather say
> POJO-ified, since it has just one dependency upon Spring's
> ApplicationContext (which is needed to resolve paths relative to a
> context's base directory). Maybe there's a way to eliminate even that
> one, but I just did the simplest possible implementation.
>
> This is also meant as a response to Stefano's concerns about depending
> on an alien framework. Once again, I am trying to show that, once you
> have swallowed the Dependency-Injection kool-aid, your components have
> very limited dependencies on the framework, or even none at all. So we
> can design generators, transformers, serializers, etc. that can be
> deployed _today_ in any existing DI container, and tomorrow in our own
> container that is designed specifically and optimized for our needs,
> without rewriting a single line of code! If you take a look at the
> sitemap components that are now in Butterfly, you will find exactly
> ZERO dependencies on Spring. And they work, even if in a simplified
> scenario, but you can get a fscking HTML response from the Butterfly
> servlet using a generator-transformer-serializer pipeline NOW.
> Admittedly, it's more of a proof of concept than a usable thing
> (there's no caching, no sitemap processor, etc.) but it shows it can be
> done.
>
> I could have started by doing my own container (after all, it's not
> rocket science, right?) and today I would be nowhere near where I am,
> given the copious free time I have available. Or I could have used the
> best DI container around and got some real work done. What would have
> you done in my place?
All right, do-ocracy wins.
Now, let's make it happen.
--
Stefano.
RE: [RT] Some notes about the "Real Blocks" issue
Posted by Carsten Ziegeler <cz...@apache.org>.
Ugo Cei wrote:
>
> Il giorno 14/ott/04, alle 18:09, Vadim Gritsenko ha scritto:
>
> > Other question I have is what we are going to do with the component
> > base we developed and depend on which currently resides in
> excalibur
> > repository. Should those be copied into Cocoon repository (and
> > springified as needed?)?
>
> Things like the SourceResolver, you mean? I have already
> "springified"
> it and put it (or at least a simplified version of it) here:
> http://svn.apache.org/repos/asf/cocoon/whiteboard/butterfly/src/java/
> org/apache/butterfly/source/
>
Hmm, I'm a little bit concerned about compatibility here. I know it
would be great to be independant from other projects in the core,
but if you look at the sourceresolver in excalibur, the interfaces
that are used there (SourceResolver, Source etc.) do not depend on
Avalon (with the exception of the Component interface which is
there by mistake :( ).
So wouldn't it be better to at least use those interfaces, but
provide just a new implementation? This would be more compatible
than redoing everything. Just a thought.
Carsten
Re: [RT] Some notes about the "Real Blocks" issue
Posted by Ugo Cei <ug...@apache.org>.
Il giorno 14/ott/04, alle 18:09, Vadim Gritsenko ha scritto:
> Other question I have is what we are going to do with the component
> base we developed and depend on which currently resides in excalibur
> repository. Should those be copied into Cocoon repository (and
> springified as needed?)?
Things like the SourceResolver, you mean? I have already "springified"
it and put it (or at least a simplified version of it) here:
http://svn.apache.org/repos/asf/cocoon/whiteboard/butterfly/src/java/
org/apache/butterfly/source/
Actually, I don't like the term "springified". I'd rather say
POJO-ified, since it has just one dependency upon Spring's
ApplicationContext (which is needed to resolve paths relative to a
context's base directory). Maybe there's a way to eliminate even that
one, but I just did the simplest possible implementation.
This is also meant as a response to Stefano's concerns about depending
on an alien framework. Once again, I am trying to show that, once you
have swallowed the Dependency-Injection kool-aid, your components have
very limited dependencies on the framework, or even none at all. So we
can design generators, transformers, serializers, etc. that can be
deployed _today_ in any existing DI container, and tomorrow in our own
container that is designed specifically and optimized for our needs,
without rewriting a single line of code! If you take a look at the
sitemap components that are now in Butterfly, you will find exactly
ZERO dependencies on Spring. And they work, even if in a simplified
scenario, but you can get a fscking HTML response from the Butterfly
servlet using a generator-transformer-serializer pipeline NOW.
Admittedly, it's more of a proof of concept than a usable thing
(there's no caching, no sitemap processor, etc.) but it shows it can be
done.
I could have started by doing my own container (after all, it's not
rocket science, right?) and today I would be nowhere near where I am,
given the copious free time I have available. Or I could have used the
best DI container around and got some real work done. What would have
you done in my place?
Ugo
--
Ugo Cei - http://beblogging.com/
Re: [RT] Some notes about the "Real Blocks" issue
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Stefano Mazzocchi wrote:
>
> Vadim, let me be crystal clear: I DO NOT want to depend on fortress!
>
> I've been trying to get that fucking thing working and it depends on
> things that Berin has on d-haven.org and only *HE* maintains.
>
> We didn't want Merlin because it was a one man show, but Fortress is way
> more of a one man show that Merlin is (at least Merlin compiles in gump,
> <shrug/>)
>
> I have great respect for the people involved, but they are not a
> community, they are a bunch of avalon refugees and that's the only thing
> that unifies them.
Ok. I hear that Spring has good community, so it could be the way then.
Other question I have is what we are going to do with the component base we
developed and depend on which currently resides in excalibur repository. Should
those be copied into Cocoon repository (and springified as needed?)?
Vadim
Re: [RT] Some notes about the "Real Blocks" issue
Posted by Stefano Mazzocchi <st...@apache.org>.
Vadim Gritsenko wrote:
> Stefano Mazzocchi wrote:
>
>> Cocoon undergo phase transition when moving from 1.x to 2.x.
>>
>> Are we doing it again?
>>
>> The question on the table is: we *NEED* better class discovery and
>> classloading isolation. This is a must, just like the need for SAX
>> pipelines drove 2.x away from 1.x in a non-incremental way (phase
>> transition, as I said).
>>
>> Can we implement classloading isolation with incrementally modifying
>> what we already have?
>
>
> From the descriptions sent by Ugo and Sylvain, they both agree that
> "kernel container" is something completely different than "intra-block
> container", which means that it should be implemented on top of existing
> Cocoon codebase as loader and manager of intra-containers regardless of
> particular technology used for implement intra-container (ECM, Spring,
> shell script...)
>
> So me feeling here is that these are two separate threads;
> * Steps to implement "kernel container".
> Pier made the first step already.
> * Directions for improvement "intra container".
> One decision we made recently was (finish) the move to Fortress.
>
> We can back up from that commitment and choose different target, be it
> Nano/Pico/Merlin/etc, but it should be independent of kernel container,
> so we can do that in parallel tracks.
>
> And one more discussion thread is needed, about roadmap for 2.1 branch,
> 2.2 branch, and possibly 2.3. Cocoon 2.2 is a good place to introduce
> fortress, and Cocoon 2.3 can have other intra-container implementations,
> whatever we choose.
Vadim, let me be crystal clear: I DO NOT want to depend on fortress!
I've been trying to get that fucking thing working and it depends on
things that Berin has on d-haven.org and only *HE* maintains.
We didn't want Merlin because it was a one man show, but Fortress is way
more of a one man show that Merlin is (at least Merlin compiles in gump,
<shrug/>)
I have great respect for the people involved, but they are not a
community, they are a bunch of avalon refugees and that's the only thing
that unifies them.
Depending more on avalon/merlin/excalibur will just hurt us more.
--
Stefano.
Re: [RT] Some notes about the "Real Blocks" issue
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Stefano Mazzocchi wrote:
> Cocoon undergo phase transition when moving from 1.x to 2.x.
>
> Are we doing it again?
>
> The question on the table is: we *NEED* better class discovery and
> classloading isolation. This is a must, just like the need for SAX
> pipelines drove 2.x away from 1.x in a non-incremental way (phase
> transition, as I said).
>
> Can we implement classloading isolation with incrementally modifying
> what we already have?
From the descriptions sent by Ugo and Sylvain, they both agree that "kernel
container" is something completely different than "intra-block container", which
means that it should be implemented on top of existing Cocoon codebase as loader
and manager of intra-containers regardless of particular technology used for
implement intra-container (ECM, Spring, shell script...)
So me feeling here is that these are two separate threads;
* Steps to implement "kernel container".
Pier made the first step already.
* Directions for improvement "intra container".
One decision we made recently was (finish) the move to Fortress.
We can back up from that commitment and choose different target, be it
Nano/Pico/Merlin/etc, but it should be independent of kernel container, so we
can do that in parallel tracks.
And one more discussion thread is needed, about roadmap for 2.1 branch, 2.2
branch, and possibly 2.3. Cocoon 2.2 is a good place to introduce fortress, and
Cocoon 2.3 can have other intra-container implementations, whatever we choose.
Vadim
Re: [RT] Some notes about the "Real Blocks" issue
Posted by Stefano Mazzocchi <st...@apache.org>.
Niclas Hedhman wrote:
> On Thursday 14 October 2004 05:23, Vadim Gritsenko wrote:
>
>
>> * Why new type of container is needed;
>> (I suppose: because some things are broken)
>> * What's broken in ECM;
>> * Why it can't be fixed in Fortress;
>> * Why Avalon compatibility can't be achived with new
>> container (so that you need second one in parallel).
>
>
> An interesting thought that I have asked myself.
>
> Looking at the 'container situation' today in Cocoon at the greatest detail,
> and one should soon realize that the "Pojo haven" is a bit misleading.
Agreed. At the same time, avalon's "interface fascism" is a little bit
too much too.
> Let me elaborate;
> Assume for a second that the Avalon Lifecycle contract was called the Cocoon
> Lifecycle contract and had no life outside of the Cocoon world. That contract
> specifies how the components are born, managed and killed within Cocoon.
> Cocoon also has its own Configuration system and component declaration system.
> Furthermore, there is something one could call a Request Cycle contract, the
> sitemap processing interfaces and the various XML chaining interfaces.
>
> IMHO, the situation of component operations are far more complex than "Pojo
> will save the day". And that is probably the main reason why the Fortress
> effort 'stalled' ;
One thing is for sure: cocoon used avalon when it didn't make sense.
> Cocoon is so much more than dependency+conf injection. And
> I think the Spring/Pico camp is probably fooling themselves thinking
> otherwise.
I can't talk about Spring because I don't know much about it, but, with
all due respect, Pico is just a (dangerous!) helper in constructing objects.
> A Cocoon Pojo will not be easier to use outside the Cocoon
> environment than today's set of components are, since there are so many other
> things that needs to happen.
Very true. A cocoon pipeline component, for example, can be or cannot be
an avalon component but you can't use it anywhere else.
At the same time, cognitively speaking, the importance of "it's just a
pojo" is useful: people don't have to think they have to learn yet
another thing to understnad what's going on.
> IMHO, why not simply fork the ECM into Cocoon and mold it to the needs here?
Well, because when we are done there won't be anything left of ECM anyway!
You can fool yourself with Serviceable instead of Composable and shit
like that, but the truth is: many many many times
Generator file = new FileGenerator(src,handler,parameters);
would have been enough!!
> Add CDI and Setter injection into it, if people feel that is needed.
> That would allow for a much smoother path for the majority of users.
The one thing that I like about all this is how people finally
understood how "class discovery" and "class construction" are different
concerns.
> And as Stefano kindly explained to me...
>
> Second principle of thermodynamics;
> Entropy of a system increases when the transformation is not reversible.
>
> i.e. evolutionary steps of ECM are reversible, a leap-of-faith is not.
Yes, I said that, but there is something I didn't mention to you about
thermodynamics: sometimes substances undergo "phase transitions", when
they change state.
Cocoon undergo phase transition when moving from 1.x to 2.x.
Are we doing it again?
The question on the table is: we *NEED* better class discovery and
classloading isolation. This is a must, just like the need for SAX
pipelines drove 2.x away from 1.x in a non-incremental way (phase
transition, as I said).
Can we implement classloading isolation with incrementally modifying
what we already have?
--
Stefano.
Re: [RT] Some notes about the "Real Blocks" issue
Posted by Ralph Goers <Ra...@dslextreme.com>.
Niclas Hedhman wrote:
>IMHO, why not simply fork the ECM into Cocoon and mold it to the needs here?
>
>
Avalon and ECM are not the same thing. I happen to like the way Cocoon
uses Avalon. However, I'm not sure how much value ECM adds.
Ralph
Re: [RT] Some notes about the "Real Blocks" issue
Posted by Ugo Cei <ug...@apache.org>.
Il giorno 14/ott/04, alle 10:25, Ugo Cei ha scritto:
> Er ... no, I haven't had much time to look at it deeply, yet. In any
> case, could you please provide something like an "executive summary"
> of what the BD is, particularly whether it is supposed to work with
> the current blocks system or with something new, and such.
Oops, I just saw that you have already done it. Sorry and thanks.
Ugo
--
Ugo Cei - http://beblogging.com/
Re: [RT] Some notes about the "Real Blocks" issue
Posted by Reinhard Poetz <re...@apache.org>.
Ugo Cei wrote:
> Il giorno 14/ott/04, alle 09:44, Reinhard Poetz ha scritto:
>
>> As you may have seen, I use Easymock at the Cocoon Block Deployer for
>> my tests. IIUC, having a framework like this, also makes it very easy
>> to test frameworks like Avalon because you can mock the service
>> manager with a few lines of code. What I want to say, testability
>> isn't a real difference but I agree with the other mentioned
>> advantages containers providing dependency injection.
>
>
> Er ... no, I haven't had much time to look at it deeply, yet. In any
> case, could you please provide something like an "executive summary" of
> what the BD is, particularly whether it is supposed to work with the
> current blocks system or with something new, and such.
Done a few hours ago ;-)
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=109773890026822&w=2
>
> Re testability, I agree that mock objects can help a lot, but sometimes
> it can even be easier to be able to do without.
The thing is, with easymock you don't need mock object at all because it works
with proxies. And, if you have dependency injection, you also need some mock
objects to fill your setters, don't you? Otherwise, how can you test the object
if it is not instantiated completly.
--
Reinhard
Re: [RT] Some notes about the "Real Blocks" issue
Posted by Ugo Cei <ug...@apache.org>.
Il giorno 14/ott/04, alle 09:44, Reinhard Poetz ha scritto:
> As you may have seen, I use Easymock at the Cocoon Block Deployer for
> my tests. IIUC, having a framework like this, also makes it very easy
> to test frameworks like Avalon because you can mock the service
> manager with a few lines of code. What I want to say, testability
> isn't a real difference but I agree with the other mentioned
> advantages containers providing dependency injection.
Er ... no, I haven't had much time to look at it deeply, yet. In any
case, could you please provide something like an "executive summary" of
what the BD is, particularly whether it is supposed to work with the
current blocks system or with something new, and such.
Re testability, I agree that mock objects can help a lot, but sometimes
it can even be easier to be able to do without.
Ugo
--
Ugo Cei - http://beblogging.com/
Re: [RT] Some notes about the "Real Blocks" issue
Posted by Reinhard Poetz <re...@apache.org>.
Ugo Cei wrote:
> Il giorno 14/ott/04, alle 04:20, Niclas Hedhman ha scritto:
>
>> A Cocoon Pojo will not be easier to use outside the Cocoon
>> environment than today's set of components are, since there are so
>> many other
>> things that needs to happen.
>
>
> Just to clarify: _no_one_ is thinking about using Cocoon components
> outside Cocoon. But if your components have no dependencies on the
> container, you get two things:
>
> 1. You can move them to a different container more easily, assuming the
> new container provides the same set of basic services as the old. This
> is not the case today.
> 2. Testability.
As you may have seen, I use Easymock at the Cocoon Block Deployer for my tests.
IIUC, having a framework like this, also makes it very easy to test frameworks
like Avalon because you can mock the service manager with a few lines of code.
What I want to say, testability isn't a real difference but I agree with the
other mentioned advantages containers providing dependency injection.
--
Reinhard
Re: [RT] Some notes about the "Real Blocks" issue
Posted by Ugo Cei <ug...@apache.org>.
Il giorno 14/ott/04, alle 04:20, Niclas Hedhman ha scritto:
> A Cocoon Pojo will not be easier to use outside the Cocoon
> environment than today's set of components are, since there are so
> many other
> things that needs to happen.
Just to clarify: _no_one_ is thinking about using Cocoon components
outside Cocoon. But if your components have no dependencies on the
container, you get two things:
1. You can move them to a different container more easily, assuming the
new container provides the same set of basic services as the old. This
is not the case today.
2. Testability.
As for your other points, which are certainly worth considering, I'm
not replying to them since I don't want to start a war of religion of
the kind "my container is better than yours". I'll just point out that
at the Hackathon we reached some kind of consensus between people who
are prepared to do some work or that have already done some work (see
the kernel and butterfly attempts). Now it's time to JFDI (Just Fscking
Do it).
Ugo
--
Ugo Cei - http://beblogging.com/
Re: [RT] Some notes about the "Real Blocks" issue
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Friday 15 October 2004 01:39, Luigi Bai wrote:
> Forking the code to Cocoon would be nice: Cocoon committers could then
> fix the bugs even if they are not Avalon/Excalibur/whatever committers.
Well, this is not what the problem has been, since Cocoon committers AFAIU has
been Avalon committers as well. Long time ago Avalon became paralyzed about
its own future, and a lot of "Battle of Egos" occurred, and safe to say
Cocoon was the largest victim of those days.
Avalon is now, in this very moment, facing the consequences...
Cheers
Niclas
--
+------//-------------------+
/ http://www.bali.ac /
/ http://niclas.hedhman.org /
+------//-------------------+
Re: [RT] Some notes about the "Real Blocks" issue
Posted by Luigi Bai <lp...@focalpoint.com>.
A benefit to forking Excalibur into Cocoon would be the availability of
the source code so people can track down bugs. I'm only a "light" Cocoon
user, and I've already been frustrated a number of times tracking down a
problem, only to hit the org.apache.avalon/excalibur "black hole". There
are three or four places to go to find the code, as far as I can tell, and
there seem to be an infinite number of modules to check out...
Forking the code to Cocoon would be nice: Cocoon committers could then
fix the bugs even if they are not Avalon/Excalibur/whatever committers.
Or, (has this been discussed before? Seems familiar) releasing a source
tarball for each jar shipped with Cocoon. Or, at least having a Wiki page
that has links to the CVS repos for various Excalibur/Avalon source trees
(Source, XML, Component, etc.).
On Thu, 14 Oct 2004, Niclas Hedhman wrote:
>
> IMHO, why not simply fork the ECM into Cocoon and mold it to the needs here?
> Add CDI and Setter injection into it, if people feel that is needed.
> That would allow for a much smoother path for the majority of users. And as
> Stefano kindly explained to me...
>
> Second principle of thermodynamics;
> Entropy of a system increases when the transformation is not reversible.
>
> i.e. evolutionary steps of ECM are reversible, a leap-of-faith is not.
>
>
Re: [RT] Some notes about the "Real Blocks" issue
Posted by Sylvain Wallez <sy...@apache.org>.
Niclas Hedhman wrote:
>On Thursday 14 October 2004 18:03, Sylvain Wallez wrote:
>
>
>
>>That is becoming an urban legend in Avalon-land: Cocoon did not expand
>>ECM (except with a few configuration syntax sugar in
>>ExtendedComponentSelector). It used it too much, which is IMO a totally
>>different problem.
>>
>>
>
>:o)
>Urban Legend or not, I agree I have bought it... And the
>
>public final class CocoonComponentManager extends ExcaliburComponentManager
>
>doesn't do much to kill the myth either.
>
>For the record, I was perhaps diong the inference in the wrong direction; The
>sitemap is tightly coupled to the ECM, isn't it?
>
Nope. It used to be, but this is no more the case. The only current
tight coupling is by an explicit instanciation of a component selector
implementation. I lacked a bit of time to totally get rid of it and
simply use Class.newInstance()...
>And sitemap is central to
>Cocoon, hence ripping out ECM and putting in Fortress was less straight
>forward than some was expecting.
>
>
Right. It was at the time where Berin tried to move to Fortress, a time
where the dependency on ECM was strong.
>Anyway, I trust that the aggregated heads of this community can bring a
>solution that we all can enjoy, whether that be a 'baby step evolutionary',
>'phased evolutionary' or 'revolutionary with legacy adapter' approach.
>
>
Thanks :-)
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [RT] Some notes about the "Real Blocks" issue
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Thursday 14 October 2004 18:03, Sylvain Wallez wrote:
> That is becoming an urban legend in Avalon-land: Cocoon did not expand
> ECM (except with a few configuration syntax sugar in
> ExtendedComponentSelector). It used it too much, which is IMO a totally
> different problem.
:o)
Urban Legend or not, I agree I have bought it... And the
public final class CocoonComponentManager extends ExcaliburComponentManager
doesn't do much to kill the myth either.
For the record, I was perhaps diong the inference in the wrong direction; The
sitemap is tightly coupled to the ECM, isn't it? And sitemap is central to
Cocoon, hence ripping out ECM and putting in Fortress was less straight
forward than some was expecting.
Anyway, I trust that the aggregated heads of this community can bring a
solution that we all can enjoy, whether that be a 'baby step evolutionary',
'phased evolutionary' or 'revolutionary with legacy adapter' approach.
Cheers
Niclas
--
+------//-------------------+
/ http://www.bali.ac /
/ http://niclas.hedhman.org /
+------//-------------------+
Re: [RT] Some notes about the "Real Blocks" issue
Posted by Sylvain Wallez <sy...@apache.org>.
Niclas Hedhman wrote:
>On Thursday 14 October 2004 16:47, Sylvain Wallez wrote:
>
>
>>>And that is probably the main reason why the Fortress
>>>effort 'stalled' ; Cocoon is so much more than dependency+conf injection.
>>>
>>>
>>Let me strongly disagree on this point. The Fortress effort stalled
>>because the sitemap engine (aka treeprocessor) was intimately tied to
>>some of the features of the ECM. The design choices of the container had
>>slipped through into the component code. I am the culprit on this point.
>>
>>
>
>I must be dumb, but isn't this what I said? Cocoon has expanded ECM, through
>the sitemap interaction, hence the Cocoon contract encompass much more than
>'traditional life cycle" that Fortress was built to provide.
>
>
That is becoming an urban legend in Avalon-land: Cocoon did not expand
ECM (except with a few configuration syntax sugar in
ExtendedComponentSelector). It used it too much, which is IMO a totally
different problem.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
RE: [RT] Some notes about the 'Real Blocks' issue
Posted by Antonio Gallardo <ag...@agssa.net>.
Carsten Ziegeler dijo:
> So, a big +10000 for not depending on someone else, regardless who they
> are or how brilliant the project seems today.
I thought that was already agreed at the hackthon. But seems things are
not clear so here is my +1 too. ;-)
Best Regards,
Antonio Gallardo
RE: [RT] Some notes about the "Real Blocks" issue
Posted by Carsten Ziegeler <cz...@apache.org>.
Stefano Mazzocchi wrote:
>
> I don't know if Spring will be better, that's why I much
> rather would want to invent our own that to depend on
> somebody elses (writing a dep-inj container is piece of cake, c'mon)
>
*Today* I totally agree with this vision. Until recently (when
the Excalibur project was formed), I belived that there was a
future for the "old Avalon" - that's why I participated in
the excalibur project.
But given the recent events, I came to the conclusion that Nicola Ken,
Stefano et.al. are propably correct about their "Avalon vision" -
unfortunately, but unavoidable as it seems.
So, a big +10000 for not depending on someone else, regardless who they
are or how brilliant the project seems today.
Carsten
Re: [RT] Some notes about the "Real Blocks" issue
Posted by Stefano Mazzocchi <st...@apache.org>.
Niclas Hedhman wrote:
> Being a die-hard Avalon supporter, I am all in favour of progress, but for the
> right reasons. Swapping ECM/Fortress for Spring/Pico doesn't change anything
> fundamentally. Only creates a lot of work for no immediate benefit.
> The real challenge as someone pointed out, is the classloading management to
> support "real blocks". THAT is worth an effort, all IMHO of course.
Niclas,
let me suggest you to consider something that nobody else will
explicitly say but "we are sick of avalon".
It doesn't matter how good it is, fortress, merlin, metro, you name it.
It hurts. It's fragile.
Look at ant, xerces, xalan! Those are things you can count on. You
*know* how painful it is to make excalibur running, how fragmented and
careless the entire avalon community is.
Avalon = pain
ask around: james, the incubated directory project, even fulcrum. Ask
them about avalon and they reply "if I knew then what I know now! :-("
[had this conversation, again, no longer than yesterday!]
Nicola, former PMC chair of avalon wrong "avalon must die!"
What else do you want? it's not a matter of cleaning up ECM, we want
avalon to be considered legacy, we want to move away from it.
I don't know if Spring will be better, that's why I much rather would
want to invent our own that to depend on somebody elses (writing a
dep-inj container is piece of cake, c'mon)
it's not technology, it's psychology.
we have reached one of those "phase transitions" since avalon's
interfaces for component lookup don't support the needs for real blocks.
mix the "sick and tired of avalon"-ness and you get an increase of
entropy and an irreversible state transition.... but this community is
strong, healthy, diverse and yet united on the move (even more so after
the GT) so I see no problems, not for the project nor for the users.
--
Stefano.
Re: [RT] Some notes about the "Real Blocks" issue
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Thursday 14 October 2004 16:47, Sylvain Wallez wrote:
> > Furthermore, there is something one could call a
> > Request Cycle contract, the sitemap processing interfaces and the various
> > XML chaining interfaces.
> >And that is probably the main reason why the Fortress
> >effort 'stalled' ; Cocoon is so much more than dependency+conf injection.
>
> Let me strongly disagree on this point. The Fortress effort stalled
> because the sitemap engine (aka treeprocessor) was intimately tied to
> some of the features of the ECM. The design choices of the container had
> slipped through into the component code. I am the culprit on this point.
I must be dumb, but isn't this what I said? Cocoon has expanded ECM, through
the sitemap interaction, hence the Cocoon contract encompass much more than
'traditional life cycle" that Fortress was built to provide.
But never mind the difference.
Being a die-hard Avalon supporter, I am all in favour of progress, but for the
right reasons. Swapping ECM/Fortress for Spring/Pico doesn't change anything
fundamentally. Only creates a lot of work for no immediate benefit.
The real challenge as someone pointed out, is the classloading management to
support "real blocks". THAT is worth an effort, all IMHO of course.
Cheers
Niclas
--
+------//-------------------+
/ http://www.bali.ac /
/ http://niclas.hedhman.org /
+------//-------------------+
RE: [RT] Some notes about the "Real Blocks" issue
Posted by Carsten Ziegeler <cz...@apache.org>.
Sylvain Wallez wrote:
>
> >And that is probably the main reason why the Fortress effort
> 'stalled'
> >; Cocoon is so much more than dependency+conf injection.
> >
>
> Let me strongly disagree on this point. The Fortress effort
> stalled because the sitemap engine (aka treeprocessor) was
> intimately tied to some of the features of the ECM. The
> design choices of the container had slipped through into the
> component code. I am the culprit on this point.
> There was some refactoring of the treeprocessor lately that
> removes that dependency on ECM internals. It's still tied to
> Avalon framework concepts though, although it could be fairly
> simple to cut that dependency.
>
The former cvs for 2.2 contains a version that runs on Fortress
(without using meta-information). It's not difficult to add
this to our current 2.2 version in SVN, but currently I don't
see a real need for it. For 2.1.x ECM works fine, and with
"Real blocks" we will have a different core anyway.
Carsten
Re: [RT] Some notes about the "Real Blocks" issue
Posted by Sylvain Wallez <sy...@apache.org>.
Niclas Hedhman wrote:
>On Thursday 14 October 2004 05:23, Vadim Gritsenko wrote:
>
>
>
>> * Why new type of container is needed;
>> (I suppose: because some things are broken)
>> * What's broken in ECM;
>> * Why it can't be fixed in Fortress;
>> * Why Avalon compatibility can't be achived with new
>> container (so that you need second one in parallel).
>>
>>
>
>An interesting thought that I have asked myself.
>
>Looking at the 'container situation' today in Cocoon at the greatest detail,
>and one should soon realize that the "Pojo haven" is a bit misleading.
>
>Let me elaborate;
>Assume for a second that the Avalon Lifecycle contract was called the Cocoon
>Lifecycle contract and had no life outside of the Cocoon world. That contract
>specifies how the components are born, managed and killed within Cocoon.
>Cocoon also has its own Configuration system and component declaration system.
>Furthermore, there is something one could call a Request Cycle contract, the
>sitemap processing interfaces and the various XML chaining interfaces.
>
>IMHO, the situation of component operations are far more complex than "Pojo
>will save the day".
>
I agree that a container is much more than
Class.forName().newInstance(). But that's a container developper
concern. The component developper should not have to care about this.
She should just have to write the service logic of the component, all
the management stuff being taken care of externally by the container.
This is a separation of concern that POJO-based containers allow.
>And that is probably the main reason why the Fortress
>effort 'stalled' ; Cocoon is so much more than dependency+conf injection.
>
Let me strongly disagree on this point. The Fortress effort stalled
because the sitemap engine (aka treeprocessor) was intimately tied to
some of the features of the ECM. The design choices of the container had
slipped through into the component code. I am the culprit on this point.
There was some refactoring of the treeprocessor lately that removes that
dependency on ECM internals. It's still tied to Avalon framework
concepts though, although it could be fairly simple to cut that dependency.
>And
>I think the Spring/Pico camp is probably fooling themselves thinking
>otherwise. A Cocoon Pojo will not be easier to use outside the Cocoon
>environment than today's set of components are, since there are so many other
>things that needs to happen.
>
>
Agree. Cocoon core components are meant to be used into Cocoon. But
Cocoon components should not depend on the container that hosts them.
>IMHO, why not simply fork the ECM into Cocoon and mold it to the needs here?
>Add CDI and Setter injection into it, if people feel that is needed.
>
>
Why fork ECM if it's to turn it into a POJO container while there are
mature ones already existing?
>That would allow for a much smoother path for the majority of users. And as
>Stefano kindly explained to me...
>
>Second principle of thermodynamics;
>Entropy of a system increases when the transformation is not reversible.
>
>i.e. evolutionary steps of ECM are reversible, a leap-of-faith is not.
>
>
ECM evolution means still being bound to our current chains. Adding a
level of Avalon framework compatibility to a POJO container means
looking towards the future without ignoring our past.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [RT] Some notes about the "Real Blocks" issue
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Thursday 14 October 2004 05:23, Vadim Gritsenko wrote:
> * Why new type of container is needed;
> (I suppose: because some things are broken)
> * What's broken in ECM;
> * Why it can't be fixed in Fortress;
> * Why Avalon compatibility can't be achived with new
> container (so that you need second one in parallel).
An interesting thought that I have asked myself.
Looking at the 'container situation' today in Cocoon at the greatest detail,
and one should soon realize that the "Pojo haven" is a bit misleading.
Let me elaborate;
Assume for a second that the Avalon Lifecycle contract was called the Cocoon
Lifecycle contract and had no life outside of the Cocoon world. That contract
specifies how the components are born, managed and killed within Cocoon.
Cocoon also has its own Configuration system and component declaration system.
Furthermore, there is something one could call a Request Cycle contract, the
sitemap processing interfaces and the various XML chaining interfaces.
IMHO, the situation of component operations are far more complex than "Pojo
will save the day". And that is probably the main reason why the Fortress
effort 'stalled' ; Cocoon is so much more than dependency+conf injection. And
I think the Spring/Pico camp is probably fooling themselves thinking
otherwise. A Cocoon Pojo will not be easier to use outside the Cocoon
environment than today's set of components are, since there are so many other
things that needs to happen.
IMHO, why not simply fork the ECM into Cocoon and mold it to the needs here?
Add CDI and Setter injection into it, if people feel that is needed.
That would allow for a much smoother path for the majority of users. And as
Stefano kindly explained to me...
Second principle of thermodynamics;
Entropy of a system increases when the transformation is not reversible.
i.e. evolutionary steps of ECM are reversible, a leap-of-faith is not.
Cheers
Niclas
--
+------//-------------------+
/ http://www.bali.ac /
/ http://niclas.hedhman.org /
+------//-------------------+
Re: [RT] Some notes about the "Real Blocks" issue
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Thursday 14 October 2004 18:59, Vadim Gritsenko wrote:
> Personally, I'd favor Avalon support for chosen container. As Ralph noted,
> and he is not alone, people like Avalon, and we should support it for years
> to come.
>
> So why to run two containers - one too much - if Avalon support can be
> implemented in new container of choice.
AFAIU, this is more about "fashionable" than anything else. Avalon has a bad
reputation amongst some people, and Spring is the latest and greatest...
IMHO, other arguments will be constructed to validate the required short-,
mid- and long-term effort to make the switch. I am very interested to take a
close look at this 'over-whelming' :o) evidence that it is worth-while.
Cheers
Niclas
--
+------//-------------------+
/ http://www.bali.ac /
/ http://niclas.hedhman.org /
+------//-------------------+
Re: [RT] Some notes about the "Real Blocks" issue
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Sylvain Wallez wrote:
> Vadim Gritsenko wrote:
>
>> Personally, I'd favor Avalon support for chosen container. As Ralph
>> noted, and he is not alone, people like Avalon, and we should support
>> it for years to come.
>
>
> Well, people will like DI containers once they start using them :-)
One does not exclude the other! I'd love to have ThreadSafe Configurable
Initializable component with DI, both constructors and setters. And if it
supports javadoc style meta info on top of it - even better. It's called smooth
migration path: support good old Avalon Components, and new trendy stuff in
parallel.
>> So why to run two containers - one too much - if Avalon support can be
>> implemented in new container of choice. More memory, management, and
>> confusion overhead. And people also would ask why two containers if
>> old is still there and is used 99% of time (and that's where you
>> answer on my question above - what's so cool about new container -
>> helps).
>
>
> I share your opinion. It would be better to provide an Avalon
> compatibility layer with the new container that having the old ECM still
> inside.
Paint me happy :-)
Vadim
Re: [RT] Some notes about the "Real Blocks" issue
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Thursday 14 October 2004 23:05, Ugo Cei wrote:
> Il giorno 14/ott/04, alle 16:50, Stefano Mazzocchi ha scritto:
> > real block kernel and Rickard Oberg's AOP framework, this would be
> > modern.
>
> Too bad he has not open-sourced it yet, or has he?
Last time I spoke to him, the 'new style' is bascially more about design
patterns than it is 'product' at the moment. The existing framework is
embedded inside a commercial CMS product.
However, I also got the impression that he was seeking an OSS opportunity when
the time and circumstances are right.
So, personally I expect some movement in this area somewhere next year. :o)
Cheers
Niclas
--
+------//-------------------+
/ http://www.bali.ac /
/ http://niclas.hedhman.org /
+------//-------------------+
RE: [RT] Some notes about the "Real Blocks" issue
Posted by Carsten Ziegeler <cz...@apache.org>.
Reinhard Poetz wrote:
>
> Pier Fumagalli wrote:
> > On 14 Oct 2004, at 16:18, Stefano Mazzocchi wrote:
> >
> >>
> >> My point remains: we've been burned too much before already in
> >> depending on frameworks we don't control.
> >>
> >> I still think it would be better to write our own entirely
> from scratch.
> >>
> >> Want to use ideas for Spring? sure, bring them on, but
> depending on
> >> it is asking for trouble.
> >>
> >
> > 100% agreed! :-P
> >
> > Pier
> >
>
> Agree too!
>
I agree that the core should be "free". Now of course we have then
the compatibility problem for core components like the source
resolver, store, xml stuff etc.
The more I think about it the more I like the way Next/Apple does
this for years: they never had any problems with renaming methods
or classes or changing signatures of that improved the framework.
To make things easier for developers they provided two things:
- a very good documentation that listed every change in the API
and the new way of doing things
- an updater tool that simply took the old source code and
updated it to the new API - and this tool worked very well.
So, what about doing it this way as well? Remove all dependencies,
make our own source resolver etc. and provide docs and a tool.
Writing such a tool isn't that difficult. We already wrote such
tools as Eclipse plugins using the Eclipse search/refactor API,
but I guess that could be used in an Ant task as well.
I think this is not the worst way of handling this issue. I guess
that we will use the same methods for those core components but
just different class/package names.
WDYT?
Carsten
Re: [RT] Some notes about the "Real Blocks" issue
Posted by Sylvain Wallez <sy...@apache.org>.
Ugo Cei wrote:
> Il giorno 16/ott/04, alle 13:52, Sylvain Wallez ha scritto:
>> Configuration file format may change, but providing an XSL to migrate
>> it should be a piece of cake should it ever happen.
>
>
> As an aside, Spring's BeanFactory is completely decoupled from the XML
> format. The BeanFactory relies on an abstract BeanDefiniitionReader
> and the XmlBeanDefinitionReader is just one of the possible
> implementations. There are implementations available for reading bean
> definitions from property files or SQL tables and of course one can
> always implement more.
Sure, but we should try to avoid this, i.e. use the container in the
most standard way as far as possible, to avoid users to learn yet
another config file format. However, extending the
XMLBeanDefinitionReader may be a good solution to feed Avalon components
that needs them with a Configuration object.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [RT] Some notes about the "Real Blocks" issue
Posted by Ugo Cei <ug...@apache.org>.
Il giorno 16/ott/04, alle 13:52, Sylvain Wallez ha scritto:
> That's the whole goal of turning Cocoon components into POJOs: have
> our code become totally independent on the container that hosts them.
> Let's use Tani for inter-blocks and Spring for intra-block. I one day
> we're not satified with them, we can just use something else without a
> single code change in components.
+1000!
> Configuration file format may change, but providing an XSL to migrate
> it should be a piece of cake should it ever happen.
As an aside, Spring's BeanFactory is completely decoupled from the XML
format. The BeanFactory relies on an abstract BeanDefiniitionReader and
the XmlBeanDefinitionReader is just one of the possible
implementations. There are implementations available for reading bean
definitions from property files or SQL tables and of course one can
always implement more.
Ugo
--
Ugo Cei - http://beblogging.com/
Re: [RT] Some notes about the "Real Blocks" issue
Posted by Sylvain Wallez <sy...@apache.org>.
Guido Casper wrote:
> Bertrand Delacretaz wrote:
>
>> Le 16 oct. 04, à 11:14, Guido Casper a écrit :
>>
>>> ...for a start it would be the easiest to just drop in
>>> spring-core.jar. But we would have to make sure, that this cannot be
>>> interpreted as an invitation to introduce other dependencies....
>>
>>
>>
>> Dependencies on Spring in the Cocoon core are certainly not a good idea,
>
>
> Why not? Don't you like Spring's way of DI?
DI is exactly why why we *don't need* to depend on Spring APIs except at
the very few places where a container has to be created.
That's the whole goal of turning Cocoon components into POJOs: have our
code become totally independent on the container that hosts them. Let's
use Tani for inter-blocks and Spring for intra-block. I one day we're
not satified with them, we can just use something else without a single
code change in components. Configuration file format may change, but
providing an XSL to migrate it should be a piece of cake should it ever
happen.
Now I agree that pure DI using setters is not always possible and one
may sometimes need to do some lookup on the container. That's where
strong dependencies may come in. But we have a solution with POJC, the
plain old java container (see [1]) that's have been present in the JDK
for years. And we can easily plug a hook into Spring that wraps a
BeanFactory into a BeanContext thus achieving container-neutral
component lookups.
No container dependency at all in our components. What's what we want to
achieve, and we have the tools for it.
Sylvain
[1] http://www.anyware-tech.com/blogs/sylvain/archives/000141.html
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [RT] Some notes about the "Real Blocks" issue
Posted by Guido Casper <gc...@s-und-n.de>.
Bertrand Delacretaz wrote:
> The point that I was trying to make is that I really like the idea of
> considering the "cocoon core" container separately from the "cocoon
> applications" one, as much for marketing reasons as for technical ones.
I too like the idea.
Guido
RE: [RT] Some notes about the "Real Blocks" issue
Posted by Carsten Ziegeler <cz...@apache.org>.
Bertrand Delacretaz wrote:
>
> Le 16 oct. 04, à 12:51, Guido Casper a écrit :
>
> > ...Please don't be dogmatic about this. You have to depend on
> > something! Just make sure you control your dependencies
> (the quality
> > and the quantity of them) and they don't get out of control...
>
> You're right, and anyway I'm not working on these containers
> so I shouldn't make too strong statements.
>
> The point that I was trying to make is that I really like the
> idea of considering the "cocoon core" container separately
> from the "cocoon applications" one, as much for marketing
> reasons as for technical ones.
>
For a long time I was against writing our own container as I
saw it simply as a waist of time/resources. But after just
talking five minutes with Pier at the GT, I changed my
opinion :) (Sometimes Pier can be really convincing).
For a long time we use Avalon as the core container and this
forces users to use this container for their applications as
well. Sure it is possible to use Spring, it might be possible
to use others as well, but it's not that easy and straight
forward.
Now, if we build the core on Spring now we have the same
problem again. What if someone wants to use Avalon (uh!)
for his application?
So this is a more technical reason than all the valid
points about dependencies, communities etc.
So, building an independent and *simple* core and making
it possible to use any container on the application level
is imho a very good way. In addition we could suggest
to use Spring on the application level, but we shouldn't
enforce it.
Carsten
Re: [RT] Some notes about the "Real Blocks" issue
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 16 oct. 04, à 12:51, Guido Casper a écrit :
> ...Please don't be dogmatic about this. You have to depend on
> something! Just make sure you control your dependencies (the quality
> and the quantity of them) and they don't get out of control...
You're right, and anyway I'm not working on these containers so I
shouldn't make too strong statements.
The point that I was trying to make is that I really like the idea of
considering the "cocoon core" container separately from the "cocoon
applications" one, as much for marketing reasons as for technical ones.
-Bertrand
Re: [RT] Some notes about the "Real Blocks" issue
Posted by Guido Casper <gc...@s-und-n.de>.
Guido Casper wrote:
> Don't you like Spring's way of DI?
Sorry Bertrand, ignore that, of course you already told you like it.
May mail wasn't (only) addressed at you :-)
Guido
Re: [RT] Some notes about the "Real Blocks" issue
Posted by Guido Casper <gc...@s-und-n.de>.
Bertrand Delacretaz wrote:
> Le 16 oct. 04, à 11:14, Guido Casper a écrit :
>
>> ...for a start it would be the easiest to just drop in
>> spring-core.jar. But we would have to make sure, that this cannot be
>> interpreted as an invitation to introduce other dependencies....
>
>
> Dependencies on Spring in the Cocoon core are certainly not a good idea,
Why not? Don't you like Spring's way of DI?
Just to be clear, I'm certainly not careless about this issue.
But you have to depend on something (call it container or whatever). A
dependency on Spring wouldn't be the worst of Cocoon's SVN.
The only consensus reached so far (as far as the intra-block container
is concerned IIUC) is the desire to loosen the dependencies on Avalon.
Stefano wants that we build our own container, whatever that might look
like, and I completely understand that attitude.
However it's not mine and my statement that Spring's BeanFactory
(whether that qualifies as a container or not) is trivial to
re-implement does not mean it's effortless. And no matter how strong
this community is, you will have a hard time making sure your
implementation is as stable and as tested as Spring's.
Please don't be dogmatic about this. You have to depend on something!
Just make sure you control your dependencies (the quality and the
quantity of them) and they don't get out of control.
Even your firm belief in the strength of this community may bite you
someday.
Please don't misunderstand this last statement, just to make my point clear.
Guido
Re: [RT] Some notes about the "Real Blocks" issue
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 16 oct. 04, à 11:14, Guido Casper a écrit :
> ...for a start it would be the easiest to just drop in
> spring-core.jar. But we would have to make sure, that this cannot be
> interpreted as an invitation to introduce other dependencies....
Dependencies on Spring in the Cocoon core are certainly not a good
idea, OTOH at the *application level* it can be very useful to take
advantage of Spring's other features, as Ugo nicely shows in his GT
presentation.
I haven't followed all details in this thread, but I'd like to say
that, IMHO (and I think there was consensus on this at the GT), looking
at the container problem at two different levels (Cocoon core and
applications levels) is a big plus.
Minimizing dependencies on external libraries in the core is a good
thing, and letting application developers use a powerful and well
documented components/enterprise patterns/whatever system like Spring,
without having to know too much about Cocoon internals, might help the
acceptance and usability of Cocoon a lot.
Of course this is already possible today, but making it the mainstream
way of doing things would be, again IMHO, a very appropriate message to
our users.
Just my two local money small coins.
-Bertrand
Re: [RT] Some notes about the "Real Blocks" issue
Posted by Ugo Cei <ug...@apache.org>.
Il giorno 16/ott/04, alle 11:14, Guido Casper ha scritto:
> Ugo, can you explain what exactly are the dependencies on Spring? My
> rather limited) understanding is, that we primarily would use Spring's
> BeanFactory. As the BeanFactory is:
> a) designed to not introduce any dependency for your components
> b) rather trivial to re-implement
>
Looking at the current Butterfly code in SVN, there are 70 Java classes
(not counting tests). Of those 70 classes, only two do an "import
org.springframework...".
One is the SourceResolver, which implements ApplicationContextAware in
order to resolve paths relative to the servlet context. The other one
is ButterflyServlet, which fetches a Spring application context from
the servlet context and passes it to the sitemap. Well, actually I am
cheating, since the implementation the sitemap processor is a Groovy
class, and that does lookups on Spring's bean factory, so make that
three classes out of 71.
To sum it up, all the sitemap components can be designed to be use DI
exclusively, without dependencies on the container. Things like the
sitemap processor, which needs to lookup components and assemble them
dinamically, will probably need to have some degree of dependency,
unless you want to define each pipeline via DI. I think this would be
quite awkward, if at all possible. Of course, with a proper design,
even these dependencies can be neatly tucked away in a handful of
classes. The main usage is calling BeanFactory.getBean(String name) and
encapsulating that is an absolute no-brainer.
Hope this answers your question,
Ugo
--
Ugo Cei - http://beblogging.com/
Re: [RT] Some notes about the "Real Blocks" issue
Posted by Guido Casper <gc...@s-und-n.de>.
Ugo, can you explain what exactly are the dependencies on Spring? My
rather limited) understanding is, that we primarily would use Spring's
BeanFactory. As the BeanFactory is:
a) designed to not introduce any dependency for your components
b) rather trivial to re-implement
for a start it would be the easiest to just drop in spring-core.jar. But
we would have to make sure, that this cannot be interpreted as an
invitation to introduce other dependencies.
Guido
Reinhard Poetz wrote:
> Pier Fumagalli wrote:
>
>> On 14 Oct 2004, at 16:18, Stefano Mazzocchi wrote:
>>> My point remains: we've been burned too much before already in
>>> depending on frameworks we don't control.
>>>
>>> I still think it would be better to write our own entirely from scratch.
>>>
>>> Want to use ideas for Spring? sure, bring them on, but depending on
>>> it is asking for trouble.
>>>
>>
>> 100% agreed! :-P
>>
>> Pier
>>
>
> Agree too!
>
Re: [RT] Some notes about the "Real Blocks" issue
Posted by Reinhard Poetz <re...@apache.org>.
Pier Fumagalli wrote:
> On 14 Oct 2004, at 16:18, Stefano Mazzocchi wrote:
>
>> Ugo Cei wrote:
>>
>>> Il giorno 14/ott/04, alle 16:50, Stefano Mazzocchi ha scritto:
>>>
>>>> real block kernel and Rickard Oberg's AOP framework, this would be
>>>> modern.
>>>
>>> Too bad he has not open-sourced it yet, or has he?
>>
>>
>> No, and he will not.
>>
>> But the ideas are available and implementation doesn't scare me.
>>
>> My point remains: we've been burned too much before already in
>> depending on frameworks we don't control.
>>
>> I still think it would be better to write our own entirely from scratch.
>>
>> Want to use ideas for Spring? sure, bring them on, but depending on it
>> is asking for trouble.
>>
>
> 100% agreed! :-P
>
> Pier
>
Agree too!
--
Reinhard
Re: [RT] Some notes about the "Real Blocks" issue
Posted by Pier Fumagalli <pi...@betaversion.org>.
On 14 Oct 2004, at 16:18, Stefano Mazzocchi wrote:
> Ugo Cei wrote:
>
>> Il giorno 14/ott/04, alle 16:50, Stefano Mazzocchi ha scritto:
>>> real block kernel and Rickard Oberg's AOP framework, this would be
>>> modern.
>> Too bad he has not open-sourced it yet, or has he?
>
> No, and he will not.
>
> But the ideas are available and implementation doesn't scare me.
>
> My point remains: we've been burned too much before already in
> depending on frameworks we don't control.
>
> I still think it would be better to write our own entirely from
> scratch.
>
> Want to use ideas for Spring? sure, bring them on, but depending on it
> is asking for trouble.
>
100% agreed! :-P
Pier
Re: [RT] Some notes about the "Real Blocks" issue
Posted by Stefano Mazzocchi <st...@apache.org>.
Ugo Cei wrote:
> Il giorno 14/ott/04, alle 16:50, Stefano Mazzocchi ha scritto:
>
>> real block kernel and Rickard Oberg's AOP framework, this would be
>> modern.
>
> Too bad he has not open-sourced it yet, or has he?
No, and he will not.
But the ideas are available and implementation doesn't scare me.
My point remains: we've been burned too much before already in depending
on frameworks we don't control.
I still think it would be better to write our own entirely from scratch.
Want to use ideas for Spring? sure, bring them on, but depending on it
is asking for trouble.
--
Stefano.
Re: [RT] Some notes about the "Real Blocks" issue
Posted by Ugo Cei <ug...@apache.org>.
Il giorno 14/ott/04, alle 16:50, Stefano Mazzocchi ha scritto:
> real block kernel and Rickard Oberg's AOP framework, this would be
> modern.
Too bad he has not open-sourced it yet, or has he?
--
Ugo Cei - http://beblogging.com/
Re: [RT] Some notes about the "Real Blocks" issue
Posted by Stefano Mazzocchi <st...@apache.org>.
Sylvain Wallez wrote:
> Vadim Gritsenko wrote:
>
> <snip/>
>
>> Personally, I'd favor Avalon support for chosen container. As Ralph
>> noted, and he is not alone, people like Avalon, and we should support
>> it for years to come.
>
> Well, people will like DI containers once they start using them :-)
DI is 1% of the original avalon idea. In fact, the only thing that was
injected were the configurations and the component manager (than people
saw that and not the real power of simple aspect orientation and Fowler
made it big misnaming it).
Technologically speaking, I still believe that the original
block+component avalon model is far superior to a silly DI pattern.
real block kernel and Rickard Oberg's AOP framework, this would be modern.
--
Stefano.
Re: [RT] Some notes about the "Real Blocks" issue
Posted by Sylvain Wallez <sy...@apache.org>.
Vadim Gritsenko wrote:
<snip/>
> Personally, I'd favor Avalon support for chosen container. As Ralph
> noted, and he is not alone, people like Avalon, and we should support
> it for years to come.
Well, people will like DI containers once they start using them :-)
> So why to run two containers - one too much - if Avalon support can be
> implemented in new container of choice. More memory, management, and
> confusion overhead. And people also would ask why two containers if
> old is still there and is used 99% of time (and that's where you
> answer on my question above - what's so cool about new container - helps).
I share your opinion. It would be better to provide an Avalon
compatibility layer with the new container that having the old ECM still
inside.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [RT] Some notes about the "Real Blocks" issue
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Ugo Cei wrote:
> Il giorno 13/ott/04, alle 23:23, Vadim Gritsenko ha scritto:
>
>> * Why new type of container is needed;
>> (I suppose: because some things are broken)
>> * What's broken in ECM;
>
> Quoting Stefano:
>
> "I've been helping Pier write a block-like container for his employer and
> found out that no matter how hard we try, the Avalon interfaces cannot
> allow to implement Cocoon Blocks the way we designed them."
>
> <http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=108004833707209&w=2>
I was asking about intra container (see orig email); quote above is about
kernerl container.
>> * Why it can't be fixed in Fortress;
>
>
> It might be fixed, maybe. My impression, however, is that Avalon with
> Fortress/Merlin/Metro/Magic/Excalibur/Kingarthur/Lancelot/Guinevere/
> Whatever is quickly fading into irrelevance. I was subscribed to the
> Excalibur mailing lists until a couple of days ago. There was almost
> nothing there besides talk about hot to fix the problems with Gump. I
> unsubscribed from Avalon even earlier.
>
> I need a framework which provides today lots of prepackaged modules
> helping with persistence, transactions, messaging, management (in the
> JMX sense). In two words: enterprise services. I don't see anything
> better than Spring it this respect.
>
> [I just realized I promised earlier not to fall into a
> container-religion-war type of argument, and I didn't mantain the
> promise, but since you asked a direct question...]
Ok. Want to give a quick overview of spring features we as enterprise cocooners
should be interested in? (and how it compares with current situation) :)
>> * Why Avalon compatibility can't be achived with new
>> container (so that you need second one in parallel).
>
>
> May be. I just thought it might have been easier that way. No
> compatibility layer to write. if you have legacy components just run
> them in the legacy container, which is not much more than ECM, and we
> already have that. This is however an implementation decision and it is
> IMHO better to start doing it one way or the other and see which one is
> better. I'm all for agile, test-driven development, so what I would do
> is write some tests, implement the simplest thing that might possibly
> work and refactor.
Personally, I'd favor Avalon support for chosen container. As Ralph noted, and
he is not alone, people like Avalon, and we should support it for years to come.
So why to run two containers - one too much - if Avalon support can be
implemented in new container of choice. More memory, management, and confusion
overhead. And people also would ask why two containers if old is still there and
is used 99% of time (and that's where you answer on my question above - what's
so cool about new container - helps).
Vadim
Re: [RT] Some notes about the "Real Blocks" issue
Posted by Ugo Cei <ug...@apache.org>.
Il giorno 13/ott/04, alle 23:23, Vadim Gritsenko ha scritto:
> * Why new type of container is needed;
> (I suppose: because some things are broken)
> * What's broken in ECM;
Quoting Stefano:
"I've been helping Pier write a block-like container for his employer
and
found out that no matter how hard we try, the Avalon interfaces cannot
allow to implement Cocoon Blocks the way we designed them."
<http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=108004833707209&w=2>
> * Why it can't be fixed in Fortress;
It might be fixed, maybe. My impression, however, is that Avalon with
Fortress/Merlin/Metro/Magic/Excalibur/Kingarthur/Lancelot/Guinevere/
Whatever is quickly fading into irrelevance. I was subscribed to the
Excalibur mailing lists until a couple of days ago. There was almost
nothing there besides talk about hot to fix the problems with Gump. I
unsubscribed from Avalon even earlier.
I need a framework which provides today lots of prepackaged modules
helping with persistence, transactions, messaging, management (in the
JMX sense). In two words: enterprise services. I don't see anything
better than Spring it this respect.
[I just realized I promised earlier not to fall into a
container-religion-war type of argument, and I didn't mantain the
promise, but since you asked a direct question...]
> * Why Avalon compatibility can't be achived with new
> container (so that you need second one in parallel).
May be. I just thought it might have been easier that way. No
compatibility layer to write. if you have legacy components just run
them in the legacy container, which is not much more than ECM, and we
already have that. This is however an implementation decision and it is
IMHO better to start doing it one way or the other and see which one is
better. I'm all for agile, test-driven development, so what I would do
is write some tests, implement the simplest thing that might possibly
work and refactor.
--
Ugo Cei - http://beblogging.com/
Re: [RT] Some notes about the "Real Blocks" issue
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Ugo Cei wrote:
> Folks,
>
> here are some notes I jotted down today while on the train and later on
> the plane, on my way back home from the GT, on the issues we discussed
> Monday WRT "Real Blocks", Butterfly, Kernel (Tani), Spring, blah blah blah
Thanks for the summary. Can you extend on this one point:
> - [ ] Two kinds of blocks: Avalon (legacy) and Spring as
> containers
> We need to support Spring (or Picocontainer,
> HiveMind or something of our own doing) and
> Avalon (for backward compatibilty) ONLY. ONE new
> type of container will be supported, otherwise
> it's just FS.
In particular,
* Why new type of container is needed;
(I suppose: because some things are broken)
* What's broken in ECM;
* Why it can't be fixed in Fortress;
* Why Avalon compatibility can't be achived with new
container (so that you need second one in parallel).
Thanks,
Vadim