You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Niclas Hedhman <ni...@hedhman.org> on 2004/08/10 16:05:54 UTC
[RT] Concerns surrounding CocoonNG
Hi,
I have with great interest read just about everything regarding the Cocoon
sentiment of moving away from Excalibur Component Manager.
What strikes me with the proposals 'on the table';
* Spring
* Pico
* Merlin
* Fortress
* Geronimo/GBean
* Custom (Kernel)
is that AFAIU only Geronimo (not verified but assumed) and Merlin (verified)
is currently equipped to deal with hot & re- deploy of components.
_IMHO_, such feature is far from rudimentary, primarily since it needs to deal
with 'usage references', i.e. decommission components that holds references
to those that are being re-deployed.
Since I belong to the 'Merlin camp', I sure am interested to hear;
1. Is compatibility no longer an issue, and that a Cocoon 3 will emerge from a
clean slate? Or is a 'gradual' evolution from ECM to something new still the
preferred approach?
2. Is the Spring/Pico/Kernel camps considering classloading mentioned above
being a non-issue, and delegating the task to Cocoon itself to deal with it?
3. Is there interest in this community of a 'proof-of-concept', showcasing the
powers of Merlin, such as classloading, Jar management (Maven style), custom
contexts, strong typing, automatic dependency resolution and other features
that Cocoon would benefit from?
FYI, planned features for Merlin in the coming 6-12month period;
* Better JMX integration.
* JMS support.
* JTA support.
* IoC Type 2 and Type 3 dependency resolution.
* JavaBeans/Type2 setter injection of parameter values.
* User-defined life-cycles per component type.
* Improved component-level security.
Cheers
Niclas
--
+------//-------------------+
/ http://www.bali.ac /
/ http://niclas.hedhman.org /
+------//-------------------+
Re: [RT] Concerns surrounding CocoonNG
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Tuesday 10 August 2004 23:29, Pier Fumagalli wrote:
> On 10 Aug 2004, at 15:05, Niclas Hedhman wrote:
> > 2. Is the Spring/Pico/Kernel camps considering classloading mentioned
> > above
> > being a non-issue, and delegating the task to Cocoon itself to deal
> > with it?
>
> Kernel: Class re-Loading already work through the conceptualization and
> implementation of blocks. That was the core issue that I needed to
> solve for my own personal use of the kernel (not considering Cocoon).
Ok, correct me if I am wrong;
ComponentA dependsOn ComponentB.
They are in different classloaders.
The proper handling of this would be to decommission, in Avalon-terms
stop()/dispose() of ComponentA, or container interaction with a
ComponentB-proxy, which drops the reference.
I have tried to locate such behaviour, and concluded that Kernel didn't
support it 'natively' and that some outer system was needed to assist in such
handling.
Cheers
Niclas
--
+------//-------------------+
/ http://www.bali.ac /
/ http://niclas.hedhman.org /
+------//-------------------+
Re: [RT] Concerns surrounding CocoonNG
Posted by Pier Fumagalli <pi...@betaversion.org>.
On 10 Aug 2004, at 15:05, Niclas Hedhman wrote:
> 2. Is the Spring/Pico/Kernel camps considering classloading mentioned
> above
> being a non-issue, and delegating the task to Cocoon itself to deal
> with it?
Kernel: Class re-Loading already work through the conceptualization and
implementation of blocks. That was the core issue that I needed to
solve for my own personal use of the kernel (not considering Cocoon).
Pier
Re: [RT] Concerns surrounding CocoonNG
Posted by Ugo Cei <ug...@apache.org>.
Il giorno 10/ago/04, alle 16:32, Sylvain Wallez ha scritto:
> So my personal answer is no. Other people here may have a different
> opinion though.
Then please disregard the closing sentence in my previous message ;-)
Ugo
--
Ugo Cei - http://beblogging.com/
Re: [RT] Concerns surrounding CocoonNG
Posted by Jörg Schaible <jo...@gmx.de>.
Hi Niclas,
we're drifting OT though, but I could not let your statement uncommented as
it gave a false impression ;-)
Niclas Hedhman wrote:
> On Thursday 12 August 2004 03:24, Jörg Schaible wrote:
>
>> Niclas Hedhman wrote:
>> > The next step ain't that far away, we are just struggling with some
>> > semantics, especially surrounding the possibility of more than a single
>> > constructor, which Pico says is a no-no, but could be a necessity.
>>
>> Pico supports multiple ctors now for quite some time (as it does setter
>> injection - its just not preferred).
>
> Ok. May I ask how Pico resolves which constructor to use, when two or
> more, seemingly incompatible, constructors can be satisfied?
In short: It selects the one with the most arguments it can satisfy. You
have influence on that selection though defining parameters, that can also
have resolvable dependencies though.
>> > Another 'issue' that CDI imposes is how to deal with aggregations and
>> > possibly custom configuration/parameterization objects, which Pico
>> > (unlike Type2) will need.
>>
>> Concerning aggregations Pico handles Java arrays and there is already
>> support for typed aggregations in the queue .. just commented out waiting
>> for JDK 1.5.
>
> I was thinking more of ; I have a component that needs MANY arguments in
> its initialization, of various types, more than is barely feasible to feed
> into the constructor. Pico (when I read it last time, some time ago)
> recommended that configuration types were to be used, i.e. one wraps up
> those values into another object and pass it in the constructor. The class
> of that object, can not really be pico-styled, since that would then have
> the same problem. Then we are back to the Configuration class in Avalon,
> or something similar.
If you have a more bean-style component, you may use the setter injection.
The number of arguments does not really matter. If you use the parameter
definition as mensioned above, you can also do it that way. But, sometimes
it *is* convenient to have a Configuration class, isn't it a valid pattern?
It just depend on the case and your needs.
- Jörg
Re: [RT] Concerns surrounding CocoonNG
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Thursday 12 August 2004 03:24, Jörg Schaible wrote:
> Niclas Hedhman wrote:
> > The next step ain't that far away, we are just struggling with some
> > semantics, especially surrounding the possibility of more than a single
> > constructor, which Pico says is a no-no, but could be a necessity.
>
> Pico supports multiple ctors now for quite some time (as it does setter
> injection - its just not preferred).
Ok. May I ask how Pico resolves which constructor to use, when two or more,
seemingly incompatible, constructors can be satisfied?
> > Another 'issue' that CDI imposes is how to deal with aggregations and
> > possibly custom configuration/parameterization objects, which Pico
> > (unlike Type2) will need.
>
> Concerning aggregations Pico handles Java arrays and there is already
> support for typed aggregations in the queue .. just commented out waiting
> for JDK 1.5.
I was thinking more of ; I have a component that needs MANY arguments in its
initialization, of various types, more than is barely feasible to feed into
the constructor. Pico (when I read it last time, some time ago) recommended
that configuration types were to be used, i.e. one wraps up those values into
another object and pass it in the constructor. The class of that object, can
not really be pico-styled, since that would then have the same problem.
Then we are back to the Configuration class in Avalon, or something similar.
Cheers
Niclas
--
+------//-------------------+
/ http://www.bali.ac /
/ http://niclas.hedhman.org /
+------//-------------------+
Re: [RT] Concerns surrounding CocoonNG
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Wednesday 11 August 2004 14:47, Guido Casper wrote:
> On the surface it may be not that different from a dependency management
> POV but the first is easier to unit test ...
Fair enough (although the response was in respect of dep management), but also
slightly dependent on your test-support in tools, right?
Cheers
Niclas
--
+------//-------------------+
/ http://www.bali.ac /
/ http://niclas.hedhman.org /
+------//-------------------+
Re: [RT] Concerns surrounding CocoonNG
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Thursday 12 August 2004 05:14, Stefano Mazzocchi wrote:
> I am supportive of the innovation that Merlin is proposing technically,
> but I sense strong idea ownership by some of the players and this is,
> historically, a reason to stay away from a technology, no matter how
> powerful and useful.
I understand, and with the ambition that Cocoon parts themselves will at large
not have dependencies on the container, it would suggest that I could fairly
easily 'tweak' Cocoon later, and perhaps provide more than one concurrent
solution.
> So, fix the community issues and then we talk.
Will do!
Cheers
Niclas
--
+------//-------------------+
/ http://www.bali.ac /
/ http://niclas.hedhman.org /
+------//-------------------+
Re: [RT] Concerns surrounding CocoonNG
Posted by Stefano Mazzocchi <st...@apache.org>.
Niclas Hedhman wrote:
> On Wednesday 11 August 2004 14:47, Guido Casper wrote:
>
>
>>On the surface it may be not that different from a dependency management
>>POV but the first is easier to unit test ...
>
>
> And for the record, this whole thread is not an argument for and against
> different IoC styles. That is very academic, and something we at the Merlin
> camp fire, are moving away from.
>
> I am just trying to highlight, that I don't think Spring and Pico are capable
> in their 'native' form to handle the hot-deploy and re-deployment of Cocoon
> blocks. And that is practical concern today for any effort of moving Cocoon
> away from ECM.
>
> We (at Merlin) think that the fastest way forward, possibly with a huge degree
> of compatibility remained, is to base Cocoon on Merlin. But I also
> acknowledge the inert resistence against anything foreign, especially since
> the ECM choice has turned very inhibiting. Otoh, I don't think an in-house
> development at that time (or now) would have been so much more different, and
> the same problems would exist.
Niclas,
there will be no technical argument that will outweight the danger of
depending on grounds that we cannot influence in a collaborative fashion
and my perception is that even if things are moving, the Merlin
community has still to prove itself in that regard.
I am supportive of the innovation that Merlin is proposing technically,
but I sense strong idea ownership by some of the players and this is,
historically, a reason to stay away from a technology, no matter how
powerful and useful.
So, fix the community issues and then we talk.
Not the other way around.
--
Stefano.
Re: [RT] Concerns surrounding CocoonNG
Posted by Stefano Mazzocchi <st...@apache.org>.
Leo Sutic wrote:
> Niclas,
>
> the problem I have with Merlin/Metro is this:
>
> http://marc.theaimsgroup.com/?l=avalon-dev&m=108965397729686&w=2
> Do you have ANY idea just how incredibly hard it has been
> to develop for Merlin? I've been trying to get a whole platform
> out the door here at Sony and was held up for MONTHS
> because of the huge changes between Merlin 3.0 and Merlin
> 3.3.
>
> Perhaps this was just a freak accident, where slight changes turned
> out to have large and unanticipated effects. Nevertheless, it is
> *precisely* the reason why Cocoon is migrating away from Avalon and is
> looking into Pier's kernel. The reason we're interested in it has not
> so much to do with classloading, strong contracts etc., which can be
> implemented if anyone cares enough for them. It's the fact that the
> Kernel is *completely under our control*, so we'll never have the
> system break because of changes to the kernel.
>
> Therefore I'm +1 on Pier's kernel. I'm sure Merlin/Metro has a place
> somewhere, maybe inside the "blocks", maybe somewhere else, but
> considering switching to it at this point in time is simply reckless.
Bingo.
--
Stefano.
Re: [RT] Concerns surrounding CocoonNG
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Leo Sutic wrote:
...
>I'm sure Merlin/Metro has a place
> somewhere, maybe inside the "blocks", maybe somewhere else, but
> considering switching to it at this point in time is simply reckless.
Using a container has two advantages: using code that is already there
and tested, and hooking up with a commmon base so to collaborate with
other services.
For the first point, our needs are not so easy, so we would have the
same problem we had with Avalon: create our new ECM derived from the
simpler core. Furthermore it's not so much tested in the real world and
still evolving.
For the second point, it's not relevant, as Cocoon as a _whole_ should
be embeddable in such a container, like for example in Geronimo as a
GBean, in JBoss, in Merlin, etc.
I agree with Leo, we don't need to buy a motor for our nice car, we need
to make our own and tune it at need.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [RT] Concerns surrounding CocoonNG
Posted by Leo Sutic <le...@gmail.com>.
Niclas,
the problem I have with Merlin/Metro is this:
http://marc.theaimsgroup.com/?l=avalon-dev&m=108965397729686&w=2
Do you have ANY idea just how incredibly hard it has been
to develop for Merlin? I've been trying to get a whole platform
out the door here at Sony and was held up for MONTHS
because of the huge changes between Merlin 3.0 and Merlin
3.3.
Perhaps this was just a freak accident, where slight changes turned
out to have large and unanticipated effects. Nevertheless, it is
*precisely* the reason why Cocoon is migrating away from Avalon and is
looking into Pier's kernel. The reason we're interested in it has not
so much to do with classloading, strong contracts etc., which can be
implemented if anyone cares enough for them. It's the fact that the
Kernel is *completely under our control*, so we'll never have the
system break because of changes to the kernel.
Therefore I'm +1 on Pier's kernel. I'm sure Merlin/Metro has a place
somewhere, maybe inside the "blocks", maybe somewhere else, but
considering switching to it at this point in time is simply reckless.
/LS
Re: [RT] Concerns surrounding CocoonNG
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Wednesday 11 August 2004 14:47, Guido Casper wrote:
> On the surface it may be not that different from a dependency management
> POV but the first is easier to unit test ...
And for the record, this whole thread is not an argument for and against
different IoC styles. That is very academic, and something we at the Merlin
camp fire, are moving away from.
I am just trying to highlight, that I don't think Spring and Pico are capable
in their 'native' form to handle the hot-deploy and re-deployment of Cocoon
blocks. And that is practical concern today for any effort of moving Cocoon
away from ECM.
We (at Merlin) think that the fastest way forward, possibly with a huge degree
of compatibility remained, is to base Cocoon on Merlin. But I also
acknowledge the inert resistence against anything foreign, especially since
the ECM choice has turned very inhibiting. Otoh, I don't think an in-house
development at that time (or now) would have been so much more different, and
the same problems would exist.
Cheers
Niclas
--
+------//-------------------+
/ http://www.bali.ac /
/ http://niclas.hedhman.org /
+------//-------------------+
Re: [RT] Concerns surrounding CocoonNG
Posted by Jörg Schaible <jo...@gmx.de>.
Hi Niclas,
just to correct some things.
Niclas Hedhman wrote:
> The next step ain't that far away, we are just struggling with some
> semantics, especially surrounding the possibility of more than a single
> constructor, which Pico says is a no-no, but could be a necessity.
Pico supports multiple ctors now for quite some time (as it does setter
injection - its just not preferred).
> Another 'issue' that CDI imposes is how to deal with aggregations and
> possibly custom configuration/parameterization objects, which Pico (unlike
> Type2) will need.
Concerning aggregations Pico handles Java arrays and there is already
support for typed aggregations in the queue .. just commented out waiting
for JDK 1.5.
- Jörg
Re: [RT] Concerns surrounding CocoonNG
Posted by Guido Casper <gc...@s-und-n.de>.
Niclas Hedhman wrote:
> Looking at the actual differences;
>
> public AbcComponent( org.hedhman.niclas.SomeDependency some )
> {
> m_SomeDependency = some;
> }
>
> /** @avalon.dependency type="org.hedhman.niclas.SomeDependency"
> * key = "some"
> */
> public void service(ServiceManager man )
> {
> m_SomeDependency = (SomeDependency) man.lookup( "some" );
> }
On the surface it may be not that different from a dependency management
POV but the first is easier to unit test ...
Guido
Re: [RT] Concerns surrounding CocoonNG
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Wednesday 11 August 2004 04:22, Sylvain Wallez wrote:
> Although this is very good from a robustness point of view, I don't feel
> at ease with this as it requires to somehow manage dependencies twice:
> in the model where they have to be formally expressed, and in the code
> where actual lookup occurs. Again, depencency injection (as opposed to
> lookup) avoids this problem.
Looking at the actual differences;
public AbcComponent( org.hedhman.niclas.SomeDependency some )
{
m_SomeDependency = some;
}
/** @avalon.dependency type="org.hedhman.niclas.SomeDependency"
* key = "some"
*/
public void service(ServiceManager man )
{
m_SomeDependency = (SomeDependency) man.lookup( "some" );
}
If there is proper SoII in CDI, the SomeDependency is an interface, and that
leaves room for more than one implementation, in which case both Merlin and
Pico/Nano needs additional meta/code to declare exactly which implementation
to be used.
If there is only one implementation available, Merlin will use that only, as I
believe Pico/Nano will also figure out.
So, the current differences are not as great as some may think. Merlin has
come a long way compared to ECM, but I agree that there are room for further
improvements.
> You said that Merlin is going to support injection, which IMO a very
> good thing.
We have taken a few steps in that direction already. So called "custom
contexts" can already be injected via constructors, as can the traditional
Avalon lifecycle objects, such as Logger, Context, ServiceManager,
Configuration and Parameters.
The next step ain't that far away, we are just struggling with some semantics,
especially surrounding the possibility of more than a single constructor,
which Pico says is a no-no, but could be a necessity.
Another 'issue' that CDI imposes is how to deal with aggregations and possibly
custom configuration/parameterization objects, which Pico (unlike Type2) will
need.
All and all, I am fairly positive about the continuation of the Merlin
convergence with other IoC styles, especially if Merlin becomes the Metro
TLP, in which case there no longer exist any 'religious reasons' to stick
with the Avalon-way only.
Cheers
Niclas
--
+------//-------------------+
/ http://www.bali.ac /
/ http://niclas.hedhman.org /
+------//-------------------+
Re: [RT] Concerns surrounding CocoonNG
Posted by Sylvain Wallez <sy...@apache.org>.
Niclas Hedhman wrote:
>On Tuesday 10 August 2004 22:55, Sylvain Wallez wrote:
>
>
>>Niclas Hedhman wrote:
>>
>>
>>>I know far too little about Spring in general (i.e. never worked with it)
>>>and GBeans in particular (i.e. have not read enough), to be able to
>>>provide a good answer.
>>>
>>>As for Spring, I think the apparent convergence between Merlin and Spring
>>>is based on two different starting points. Merlin starting out as a
>>>Model-driven architecture, with strong typing, a strong IoC as its base,
>>>where as Spring started out with making IoC-style out of JavaBeans.
>>>
>>>
>>Mmh... can you elaborate on the meaning of "model-driven" and "_strong_
>>IOC"?
>>
>>
>
>Strong IoC is in reference to ECM that allows you to look up any component on
>the fly, no matter if such dependency has been declared or not. Merlin otoh,
>will not allow lookup() of non-declared dependencies.
>
>
Ah, ok. So this is about security and proper use of dependencies.
It seems to me that dependency injection, compared to lookup, solves
this problem in the an elegant way by suppressing it, since a component
no more has access to a component locator.
>Model Driven = Merlin builds a model of all the participating components.
>Merlin will satisfy the declared dependencies, implicitly or explicitly,
>within the model, prior to deploying (note, deploying != instantiation, as
>that is determined by the lifestyle) the components. If the dependencies can
>not be fulfilled, deployment will not occur. This approach minimizes the
>runtime problem that can occur, with adhoc resolution of component dependency
>resolution.
>
>
Although this is very good from a robustness point of view, I don't feel
at ease with this as it requires to somehow manage dependencies twice:
in the model where they have to be formally expressed, and in the code
where actual lookup occurs. Again, depencency injection (as opposed to
lookup) avoids this problem.
You said that Merlin is going to support injection, which IMO a very
good thing. My remarks are mainly about the Avalon Framework APIs which
now seem so old-fashioned compared to newer approaches to IOC. Sure,
Avalon kicked ass when it was invented and was very ahead of its time,
but things have evolved since then (dynamic proxies, AOP, etc) and
people have learned from what was brought by Avalon.
>I hope this clarifies my PoV.
>
>
Yep. Thanks a lot!
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [RT] Concerns surrounding CocoonNG
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Tuesday 10 August 2004 22:55, Sylvain Wallez wrote:
> Niclas Hedhman wrote:
> >I know far too little about Spring in general (i.e. never worked with it)
> > and GBeans in particular (i.e. have not read enough), to be able to
> > provide a good answer.
> >
> >As for Spring, I think the apparent convergence between Merlin and Spring
> > is based on two different starting points. Merlin starting out as a
> > Model-driven architecture, with strong typing, a strong IoC as its base,
> > where as Spring started out with making IoC-style out of JavaBeans.
>
> Mmh... can you elaborate on the meaning of "model-driven" and "_strong_
> IOC"?
Strong IoC is in reference to ECM that allows you to look up any component on
the fly, no matter if such dependency has been declared or not. Merlin otoh,
will not allow lookup() of non-declared dependencies.
Model Driven = Merlin builds a model of all the participating components.
Merlin will satisfy the declared dependencies, implicitly or explicitly,
within the model, prior to deploying (note, deploying != instantiation, as
that is determined by the lifestyle) the components. If the dependencies can
not be fulfilled, deployment will not occur. This approach minimizes the
runtime problem that can occur, with adhoc resolution of component dependency
resolution.
I hope this clarifies my PoV.
Cheers
Niclas
--
+------//-------------------+
/ http://www.bali.ac /
/ http://niclas.hedhman.org /
+------//-------------------+
Re: [RT] Concerns surrounding CocoonNG
Posted by Sylvain Wallez <sy...@apache.org>.
Niclas Hedhman wrote:
>I know far too little about Spring in general (i.e. never worked with it) and GBeans in particular (i.e. have not read enough), to be able to provide a good answer.
>
>As for Spring, I think the apparent convergence between Merlin and Spring is based on two different starting points. Merlin starting out as a Model-driven architecture, with strong typing, a strong IoC as its base, where as Spring started out with making IoC-style out of JavaBeans.
>
>
Mmh... can you elaborate on the meaning of "model-driven" and "_strong_
IOC"?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [RT] Concerns surrounding CocoonNG
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Tuesday 10 August 2004 22:32, Sylvain Wallez wrote:
> >FYI, planned features for Merlin in the coming 6-12month period;
> >* Better JMX integration.
> >* JMS support.
> >* JTA support.
> >* IoC Type 2 and Type 3 dependency resolution.
> >* JavaBeans/Type2 setter injection of parameter values.
> >* User-defined life-cycles per component type.
> >* Improved component-level security.
>
> How's that different from GBeans+Spring?
I know far too little about Spring in general (i.e. never worked with it) and
GBeans in particular (i.e. have not read enough), to be able to provide a
good answer.
As for Spring, I think the apparent convergence between Merlin and Spring is
based on two different starting points. Merlin starting out as a Model-driven
architecture, with strong typing, a strong IoC as its base, where as Spring
started out with making IoC-style out of JavaBeans.
Cheers
Niclas
--
+------//-------------------+
/ http://www.bali.ac /
/ http://niclas.hedhman.org /
+------//-------------------+
Re: [RT] Concerns surrounding CocoonNG
Posted by Sylvain Wallez <sy...@apache.org>.
Niclas Hedhman wrote:
>Hi,
>I have with great interest read just about everything regarding the Cocoon
>sentiment of moving away from Excalibur Component Manager.
>
>What strikes me with the proposals 'on the table';
> * Spring
> * Pico
> * Merlin
> * Fortress
> * Geronimo/GBean
> * Custom (Kernel)
>is that AFAIU only Geronimo (not verified but assumed) and Merlin (verified) is currently equipped to deal with hot & re- deploy of components.
>
>_IMHO_, such feature is far from rudimentary, primarily since it needs to deal with 'usage references', i.e. decommission components that holds references to those that are being re-deployed.
>
>Since I belong to the 'Merlin camp', I sure am interested to hear;
>
>1. Is compatibility no longer an issue, and that a Cocoon 3 will emerge from a clean slate? Or is a 'gradual' evolution from ECM to something new still the preferred approach?
>
>
Cocoon 2 was totally incompatible with Cocoon 1, and so could be an
hypothetical Cocoon 3 (as not such plan formally exists today).
Compatibility is of primary importance however for Cocoon 2.1.x series,
and Cocoon 2.2 will remove what is being deprecated in the 2.1.x series.
>2. Is the Spring/Pico/Kernel camps considering classloading mentioned above being a non-issue, and delegating the task to Cocoon itself to deal with it?
>
>
As I explained in an earlier post, there are two levels of containers:
- the single container for blocks, almost invisible from user code, that
has to deal with hot deploy and classloading issues. In this category
come Merlin, GBeans and our own Kernel
- the container within each block, managing application-level
components, and thus visible to users. We use ECM for this today, and is
where API-less containers such as Spring are studied.
>3. Is there interest in this community of a 'proof-of-concept', showcasing the powers of Merlin, such as classloading, Jar management (Maven style), custom contexts, strong typing, automatic dependency resolution and other features that Cocoon would benefit from?
>
>
Merlin certainly contains good code, but too many social issues for a
small community. I don't want these issues to pollute the healthy Cocoon
community.
So my personal answer is no. Other people here may have a different
opinion though.
>FYI, planned features for Merlin in the coming 6-12month period;
>* Better JMX integration.
>* JMS support.
>* JTA support.
>* IoC Type 2 and Type 3 dependency resolution.
>* JavaBeans/Type2 setter injection of parameter values.
>* User-defined life-cycles per component type.
>* Improved component-level security.
>
>
How's that different from GBeans+Spring?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [RT] Concerns surrounding CocoonNG
Posted by Ugo Cei <ug...@apache.org>.
Il giorno 10/ago/04, alle 16:05, Niclas Hedhman ha scritto:
> 1. Is compatibility no longer an issue, and that a Cocoon 3 will
> emerge from a
> clean slate? Or is a 'gradual' evolution from ECM to something new
> still the
> preferred approach?
It depends on who you ask. Personally, I tend to prefer a rewrite over
a refactoring in many situations. I am aware that this is not always
the best course, but it's my personality and I cannot do anything about
it.
However, this has nothing to do with backward compatibility. You can do
a rewrite from scratch and still maintain 100% compatibility with old
interfaces, possibly via an emulation layer.
> 2. Is the Spring/Pico/Kernel camps considering classloading mentioned
> above
> being a non-issue, and delegating the task to Cocoon itself to deal
> with it?
Frankly, I haven't even started considering the issue. I am not
equipped with enough knowledge about class loaders and such to proffer
an informed opinion.
> 3. Is there interest in this community of a 'proof-of-concept',
> showcasing the
> powers of Merlin, such as classloading, Jar management (Maven style),
> custom
> contexts, strong typing, automatic dependency resolution and other
> features
> that Cocoon would benefit from?
Of course, there is, and I don't think I'm mistaken if I try to
interpret the interest of the whole community here.
Ugo
--
Ugo Cei - http://beblogging.com/