Niclas Hedhman dijo:
Your reasons are highly valid, no doubt, just like the unstable days of
Cocoon, when matching versions of xerces, xalan and other XML technologies
was a balance act one hardly want to go through again.
I knew about that. But again the balance would a hard task: Xalan and
On Wednesday 20 October 2004 16:23, Antonio Gallardo wrote:
I knew about that. But again the balance would a hard task: Xalan and
Xerces need to move to JAXP 1.3. I already saw the post on the xml-commons
list.
What surprises me about it is that the source of the problem isn't educated
about
Stefano Mazzocchi wrote:
Ralph Goers wrote:
Antonio,
This subject has come up many times. I'll restate what I've always said.
If we must release a snapshot jar then the source that was used to build
it must be available for download from Cocoon's website, or another
documented location (i.e.
I like that a lot as it should guarantee the correct source. Assuming a
project is using SVN of course.
Ralph
Nicola Ken Barozzi said:
In fact AFAIK we had decided that we had to keep the sources only if the
source was not easy to get. We can simply append the SVN version of the
snapshot
Le 20 oct. 04, à 16:43, Ralph Goers a écrit :
I like that a lot as it should guarantee the correct source. Assuming
a
project is using SVN of course
The same is true with CVS, as discussed before [1]
Even if the CVS snapshot cannot be done against a specific CVS tag, a
snapshot using cvs
Niclas Hedhman wrote:
On Wednesday 20 October 2004 16:23, Antonio Gallardo wrote:
I knew about that. But again the balance would a hard task: Xalan and
Xerces need to move to JAXP 1.3. I already saw the post on the xml-commons
list.
What surprises me about it is that the source of the problem
On 18 Oct 2004, at 17:03, Sylvain Wallez wrote:
A lib/endorsed/xalan-2.6.1-dev-20041008T0304.jar
D lib/endorsed/xalan-2.6.0.jar
Why does the 2.1 branch require a timestamped/snapshot version of
Xalan, if everything is so fine and dandy with it?
Damn, I am *NOT*. I missed that. We must not
The serializers in XALAN are just _VERY_ broken... Why don't we switch
the default to work on the serializers block? At least it's a
simple-enough code that we can't fix without too much hassle.
the serializer still has some namespace issues.
but nothing that cannot be fix in a few hours.
--
Pier Fumagalli wrote:
The serializers in XALAN are just _VERY_ broken... Why don't we switch
the default to work on the serializers block? At least it's a
simple-enough code that we can't fix without too much hassle.
I'm sure you meant can instead of can't ;-) but anyway, here's my +1.
Ugo Cei wrote:
Pier Fumagalli wrote:
The serializers in XALAN are just _VERY_ broken... Why don't we switch
the default to work on the serializers block? At least it's a
simple-enough code that we can't fix without too much hassle.
I'm sure you meant can instead of can't ;-) but anyway, here's
Torsten Curdt wrote:
The serializers in XALAN are just _VERY_ broken... Why don't we
switch the default to work on the serializers block? At least it's a
simple-enough code that we can't fix without too much hassle.
the serializer still has some namespace issues. but nothing that
cannot be fix
On 19 Oct 2004, at 17:35, Sylvain Wallez wrote:
Torsten Curdt wrote:
The serializers in XALAN are just _VERY_ broken... Why don't we
switch the default to work on the serializers block? At least it's a
simple-enough code that we can't fix without too much hassle.
the serializer still has some
On 19 Oct 2004, at 11:45, Torsten Curdt wrote:
The serializers in XALAN are just _VERY_ broken... Why don't we
switch the default to work on the serializers block? At least it's a
simple-enough code that we can't fix without too much hassle.
the serializer still has some namespace issues.
but
30142
Pier Fumagalli wrote:
On 19 Oct 2004, at 11:45, Torsten Curdt wrote:
The serializers in XALAN are just _VERY_ broken... Why don't we
switch the default to work on the serializers block? At least it's a
simple-enough code that we can't fix without too much hassle.
the serializer still has
Well, that's a bug related to the Xalan serializers, not to the Cocoon
serializers block, and AFAICS, it was fixed in CVS in July...
Pier
On 19 Oct 2004, at 17:57, Jorg Heymans wrote:
30142
Pier Fumagalli wrote:
On 19 Oct 2004, at 11:45, Torsten Curdt wrote:
The serializers in XALAN are
Pier Fumagalli wrote:
On 19 Oct 2004, at 11:45, Torsten Curdt wrote:
The serializers in XALAN are just _VERY_ broken... Why don't we
switch the default to work on the serializers block? At least it's a
simple-enough code that we can't fix without too much hassle.
the serializer still has some
Vadim Gritsenko dijo:
Hmm, I actually don't know what's best. What do others think?
The best plan IMHO would be:
1. Remove ECM - implementation of Avalon container. Keep re-usable
components
code (XSLT, Source, Store, etc).
2. Drop in the container which replaces it.
3. Write bridge code
Niclas Hedhman dijo:
On Saturday 16 October 2004 04:55, Stefano Mazzocchi wrote:
Because they have been around forever *AND* they don't change their
contracts overnight.
Your talk is not entirely reflected by the actions of the community.
I
just
did a svn up on the 2.1 branch;
A
Hi Ralph:
AFAIK, we can release without problems. But if a xalan version is needed
we can request the xalan project for a release.
I already requested for a release to the commons-lang project. They
promised a release, but I will remeber them about that.
WDYT?
Best Regards,
Antonio Gallardo.
Antonio Gallardo wrote:
snip/
At the end, it a big shame to me that my work is being used against our
community. Seems that I need to be more careful.
Nope. You committed that unreleased version for a valid reason and you
followed that naming rule that allows to find the corresponding sources
Sylvain Wallez dijo:
Antonio Gallardo wrote:
snip/
At the end, it a big shame to me that my work is being used against our
community. Seems that I need to be more careful.
Nope. You committed that unreleased version for a valid reason and you
followed that naming rule that allows to find
Thanks for jogging my memory Sylvain. Yes, the rule was followed. As much
as I'd like the actual source, the name does allow me to get it myself.
BTW - weren't the rules for release numbering, the guarantees about
compatibility as well as how snapshots would be named supposed to be on
the
Ralph Goers dijo:
Antonio,
This subject has come up many times. I'll restate what I've always said.
If we must release a snapshot jar then the source that was used to build
it must be available for download from Cocoon's website, or another
documented location (i.e. cocoondev, ibiblio,
Ralph Goers wrote:
Antonio,
This subject has come up many times. I'll restate what I've always said.
If we must release a snapshot jar then the source that was used to build
it must be available for download from Cocoon's website, or another
documented location (i.e. cocoondev, ibiblio, etc.).
On Wednesday 20 October 2004 05:39, Antonio Gallardo wrote:
At the end, it a big shame to me that my work is being used against our
community. Seems that I need to be more careful.
I am sorry that your work end up being an example;
One should not throw stones while in a glass house.
i.e.
Ugo Cei wrote:
Il giorno 17/ott/04, alle 17:22, Daniel Fagerstrom ha scritto:
data. In Spring you must as well supply wiring information about how
the component is connected to other components thru setters. You need
to describe the life cycle, if there are any initialization and
destruction
Daniel Fagerstrom wrote:
components and property DI for optional components might be a good
approach. However, IMHO, it would not give enough advantages to be worth
any back compatibillity, a prolonged period of instabillity or (at least
for me), the effort.
Thanks Daniel for speaking it out
On Monday 18 October 2004 16:27, Reinhard Poetz wrote:
Thanks Daniel for speaking it out loudly: Who wants to get his hands dirty
with the two implementations
- kernel (inter-block communication, classloader shielding)
- new Cocoon core engine
and which time frames are those people
Niclas Hedhman wrote:
Yes. As a user, that is the essence. What are the 'Dates of
RoadMap Milestones and who are driving those besides Pier,
Sylvain and Ugo?
So, we can get some birds-eye view, and avoid another 2.x
styled delays.
We agreed that the new core (or the blocks
Sylvain Wallez wrote:
Daniel Fagerstrom wrote:
snip/
Add your reasons.
Since Avalon came to life and I came to love it, I've had long fights
with some of my colleagues at work to convince them to use it, in
order to have robust architectures. Their argument was that they
didn't want to use
Niclas Hedhman wrote:
On Saturday 16 October 2004 04:55, Stefano Mazzocchi wrote:
Because they have been around forever *AND* they don't change their
contracts overnight.
Your talk is not entirely reflected by the actions of the community. I just
did a svn up on the 2.1 branch;
A
Stefano Mazzocchi wrote:
Niclas Hedhman wrote:
On Saturday 16 October 2004 04:55, Stefano Mazzocchi wrote:
Because they have been around forever *AND* they don't change their
contracts overnight.
Your talk is not entirely reflected by the actions of the community.
I just did a svn up on the
Carsten Ziegeler dijo:
So, a big +1 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
Il giorno 16/ott/04, alle 20:51, Pier Fumagalli ha scritto:
And that said, I close this whole discussion as I think it's entirely
pointless, I'll let Stefano re-iterate why class loading isolation is
required to achieve blocks polymorphism.
I don't think it is entirely pointless. For one thing,
Sorry, I thought what's being discussed is wether or not to use Spring
as an intra-block container and that Tani as inter-block container is
set. Am I wrong?
Guido
Ralph Goers wrote:
In short, the fact that Cocoon is just a bunch of parts that get
configured is one of Cocoon's major strengths. However, the current
configuration is pretty easy to understand and modify. If the
replacement container makes the configuration more complex and less
Guido Casper wrote:
Sorry, I thought what's being discussed is wether or not to use Spring
as an intra-block container and that Tani as inter-block container is
set. Am I wrong?
Nope, you're totally right. Tani already provides classloader isolation,
and we just need to add a thin DI layer on
Guido Casper wrote:
Ralph Goers wrote:
In short, the fact that Cocoon is just a bunch of parts that get
configured is one of Cocoon's major strengths. However, the current
configuration is pretty easy to understand and modify. If the
replacement container makes the configuration more complex
Pier Fumagalli wrote:
snip/
As I personally need the kernel, I will personally invest some more
time into it, Cocoon or not (frankly, I could care less at this point).
I think that the current kernel code is wrong, as it's based on
implementation of interfaces a-la Avalon, and you showed me a
Daniel Fagerstrom wrote:
Guido Casper wrote:
Ralph Goers wrote:
In short, the fact that Cocoon is just a bunch of parts that get
configured is one of Cocoon's major strengths. However, the current
configuration is pretty easy to understand and modify. If the
replacement container makes the
Daniel,
I didn't quote everything in your post in the interest of space, but I
agree with everything in it. Frankly, I'd be happy if every block had
it's own equivalent to cocoon.xconf that could be loaded along with the
block. If any wiring is needed, it should be between the Cocoon core
Sylvain Wallez wrote:
Daniel Fagerstrom wrote:
snip/
While I agree with your concerns, I think a DI container can
_potentially_ bring a lot in this area. The current problem with
Cocoon's xconf file is that it is really free-form, and the variety of
the components makes writing an XML grammar
Il giorno 17/ott/04, alle 17:22, Daniel Fagerstrom ha scritto:
data. In Spring you must as well supply wiring information about how
the component is connected to other components thru setters. You need
to describe the life cycle, if there are any initialization and
destruction methods of the
Daniel Fagerstrom wrote:
Sylvain Wallez wrote:
snip/
What I would like us to do, is to write some kind of (prioritized)
requirement list on what problems we would like to solve for
intra-block component handling. Then it would be possible to evaluate
different technical solutions with respect
I'm curious about this for a completely different reason. It has been
the stated policy that every attempt will be made to use only formally
released third-party jars in formal releases of Cocoon. Does this mean
that 2.1.6 cannot be released until Xalan 2.6.1 is released? If not,
please
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
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
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.
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
Le 16 oct. 04, à 13:28, Sylvain Wallez a écrit :
Folks, look at what I just found in my junk mail folder. Hopefully,
everyone in Cocoon-land runs the same spam filter...
hmmyour spam filter looks really powerful, but make sure it doesn't
feed the trolls when it thinks it sees one...
(but
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
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
Il giorno 16/ott/04, alle 13:28, Carsten Ziegeler ha scritto:
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).
Pier
Ugo Cei wrote:
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?
He'll instantiate some kind of Avalon container and maybe
bind it to the servlet context, so that any other component
that needs it
I must admit, I have issues with this whole discussion. I understand
that there are problems with the Avalon community and that the current
code base is making implementing real blocks difficult. But I have also
used Spring and have issues with that. To summarize:
1. Figuring out what is
On 16 Oct 2004, at 13:31, Ugo Cei wrote:
Il giorno 16/ott/04, alle 13:28, Carsten Ziegeler ha scritto:
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 :)
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
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
Il giorno 15/ott/04, alle 08:39, Carsten Ziegeler ha scritto:
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
Ugo Cei wrote:
The interfaces that are in Butterfly are a verbatim copy
(apart maybe from some minor changes, some time has passed
and I don't remember all the details) of the Excalibur ones.
Of course, the package names have changed (and the
o.a.butterfly will have to be changed to
On Friday 15 October 2004 15:29, Carsten Ziegeler wrote:
IMHO, generally, compatibility provided through subclassing is 'asking for
long-term trouble'. Take a deep look inside the Netbeans project for a scary
example.
Subclassing of interfaces is slightly better...
public interface Source
Il giorno 15/ott/04, alle 09:43, Niclas Hedhman ha scritto:
However, you are requesting that the Excalibur Source is a subclass of
the
Cocoon Source. I suspect that is a typo, but if not, then you are
introducing
a cross-dependency with the Excalibur project, or breaking namespace
policies
by
On Friday 15 October 2004 16:06, Ugo Cei wrote:
Il giorno 15/ott/04, alle 09:43, Niclas Hedhman ha scritto:
However, you are requesting that the Excalibur Source is a subclass of
the
Cocoon Source. I suspect that is a typo, but if not, then you are
introducing
a cross-dependency with
Carsten Ziegeler wrote:
Ugo Cei wrote:
The interfaces that are in Butterfly are a verbatim copy
(apart maybe from some minor changes, some time has passed
and I don't remember all the details) of the Excalibur ones.
Of course, the package names have changed (and the
o.a.butterfly will have to
Il giorno 15/ott/04, alle 13:01, Vadim Gritsenko ha scritto:
The best plan IMHO would be:
1. Remove ECM - implementation of Avalon container. Keep re-usable
components code (XSLT, Source, Store, etc).
2. Drop in the container which replaces it.
3. Write bridge code between container in (2) and
Ugo Cei [EMAIL PROTECTED] writes:
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
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
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
Ugo Cei wrote:
Il giorno 15/ott/04, alle 13:01, Vadim Gritsenko ha scritto:
The best plan IMHO would be:
1. Remove ECM - implementation of Avalon container. Keep re-usable
components code (XSLT, Source, Store, etc).
2. Drop in the container which replaces it.
3. Write bridge code between
Hunsberger, Peter wrote:
Maybe I'm
just too optimistic in believing there should be container
implementations mature enough for Cocoon to depend on?
What *really* bothers me about this thread is the fact that very few
seem to realize that maturity for dependencies means stability of the
Hunsberger, Peter wrote:
Umm, I don't really see a pattern here. From everything I've seen the
communities involved with Spring and Geronimo have little in common with
the Avalon/Excalibur communities. (Let me qualify that by saying I
haven't looked that closely.) More-over, they both have the
-Original Message-
From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]
Because they have been around forever *AND* they don't change their
contracts overnight.
So who is changing contracts Stefano?
Stefano Mazzocchi [EMAIL PROTECTED] writes:
Hunsberger, Peter wrote:
Umm, I don't really see a pattern here. From everything
I've seen the
communities involved with Spring and Geronimo have little in common
with the Avalon/Excalibur communities. (Let me qualify that
by saying
On Saturday 16 October 2004 04:55, Stefano Mazzocchi wrote:
Because they have been around forever *AND* they don't change their
contracts overnight.
Your talk is not entirely reflected by the actions of the community. I just
did a svn up on the 2.1 branch;
A
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
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
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
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
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
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
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
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
Carsten Ziegeler wrote:
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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/
smime.p7s
Description: S/MIME cryptographic signature
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
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
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
1 - 100 of 108 matches
Mail list logo
