Giacomo Pati wrote:
On Tue, 3 Jan 2006, Sylvain Wallez wrote:
Right. And the simplest and most consistent step to go forward is IMO
to just use what's already there, providing a nice bridge to a
rock-solid container used by thousands of people.
If you mean Spring as the rock-solid container
--- Sylvain Wallez [EMAIL PROTECTED] schrieb:
Giacomo Pati wrote:
If you mean Spring as the rock-solid container
used by thousands of
people than tell me why are you using a Mac while
ten-thousands of
people use a IBM ThinkPad ;-)
A very interesting comparison: Apple is currently
I think the Apple move to Intel processors is a good
example.
Same here!
Apple is changing its fundaments but the
building above, the operating systems, remains the
same and all your applications won't stop to work.
That's not true ...you have to port applications to
the new platform. But
Reinhard Poetz wrote:
I think the Apple move to Intel processors is a good
example. Apple is changing its fundaments but the
building above, the operating systems, remains the
same and all your applications won't stop to work. The
average user won't even notice that the processor has
changed.
Vadim Gritsenko wrote:
Carsten Ziegeler wrote:
So I'm coming back to my idea, is anyone against adding constructor
injection to ECM++ or at least make it pluggable so I can add it for my
own projects? The change adds only a feature while maintaining 100%
compatibility.
Why not setter
Sylvain Wallez wrote:
I asked Carsten why he doesn't want to use the bridge that _he_ wrote,
and would love to have his answer. Carsten?
Now all this comparing of the things Apple did with our situation is
missing imho a big difference: Apple decided that their next OS (MacOS
X) should have
Carsten Ziegeler wrote:
Vadim Gritsenko wrote:
Carsten Ziegeler wrote:
So I'm coming back to my idea, is anyone against adding constructor
injection to ECM++ or at least make it pluggable so I can add it for my
own projects? The change adds only a feature while maintaining 100%
Wow, a long and fun thread ;)
Seem like most want to migrate away from the Avalon interfaces for
component handling and that some (I'm included), in the long term, want
to move away even from ECM++. IMO, with all communities that specializes
on containers, building containers should be outside
Sylvain Wallez wrote:
...
Guys, remember the real-blocks container story? Two reasons led to the
choice of OSGi: there are existing implementations, and it stopped the
endless discussions about what the container API should be.
We have exactly the same here. why not this or that and I don't
Sylvain Wallez wrote:
Carsten, what's wrong with the Spring bridge?
See my reply from today.
Carsten
--
Carsten Ziegeler - Open Source Group, SN AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Hi,
On 22 Dec 2005, at 13:42, Andrew Savory wrote:
Please cast your votes!
Congratulations Jean-Baptiste, you are elected with 19 +1s
Welcome aboard!
Andrew.
--
Andrew Savory, Managing Director, Luminas Limited
Tel: +44 (0)870 741 6658 Fax: +44 (0)700 598 1135
Web:
Sylvain Wallez wrote:
Guys, remember the real-blocks container story? Two reasons led to the
choice of OSGi: there are existing implementations, and it stopped the
endless discussions about what the container API should be.
We have exactly the same here. why not this or that and I don't
Geoff Howard [mailto:[EMAIL PROTECTED] wrote:
On 12/20/05, Max Pfingsthorn [EMAIL PROTECTED] wrote:
On another note: I need the eventcaching block for webdav, but
that one only needs jms in one class, and databases in the
samples. So, I'll work on the dependency issue there
Le 4 janv. 06, à 12:36, Carsten Ziegeler a écrit :
...Yes, so why not throwing ECM++ away and use an existing container?
We
can provide an Avalon compatibility bridge for nearly any existing
container...
I was thinking about this after reading the replies this morning,
sounds like an ideal
On 1/4/06, Max Pfingsthorn [EMAIL PROTECTED] wrote:
Geoff Howard [mailto:[EMAIL PROTECTED] wrote:
On 12/20/05, Max Pfingsthorn [EMAIL PROTECTED] wrote:
On another note: I need the eventcaching block for webdav, but
that one only needs jms in one class, and databases in the
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
Guys, remember the real-blocks container story? Two reasons led to the
choice of OSGi: there are existing implementations, and it stopped the
endless discussions about what the container API should be.
We have exactly the same here. why not
Daniel Fagerstrom wrote:
snip/
Summarizing my opinions: Users should be able to use any container.
... but we should have one usable out of the box for users that don't
want or don't know how to make a choice.
Blocks and a more fine grained modularization of the core gives the
possiblity
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 4 Jan 2006, Carsten Ziegeler wrote:
Date: Wed, 04 Jan 2006 12:36:19 +0100
From: Carsten Ziegeler [EMAIL PROTECTED]
Reply-To: dev@cocoon.apache.org
To: dev@cocoon.apache.org
Subject: Re: [RT] Simplifying component handling
Sylvain Wallez
Hi
there,
XTech 2006 (former
XMLEurope)will be heldin Amsterdam 16-19 May. They havethe
option to request a (free?) room for "related events"- hackton and the
likes. Any interest? I could arrange something..
http://www.xtech-conference.org/
Arjé Cahn
Hippo
Oosteinde 11 1017WT
Torsten Curdt wrote:
IMO Cocoon should go the same way. The recent thread
about a complete rewrite of Cocoon *really* scares me
and a lot of people I've talked to as it will break
compatibility for sure.
Fear has always been the main blocker for new technologies.
Well, I haven't talked
My only fear with this whole discussion is that we are once again going
to lose focus on finishing 2.2.
Ralph
Much has been talked about in regards to the component infrastructure.
That's a good thing, but after years of component based design, and
getting back to the roots of just plain old object oriented design, I
have to question why everything needs to be a component. Using good
OOD, we can
Arje Cahn wrote:
Hi there,
XTech 2006 (former XMLEurope) will be held in Amsterdam 16-19 May. They
have the option to request a (free?) room for related events - hackton
and the likes. Any interest? I could arrange something..
FYI, I'm on the technical review board of that conference.
--
Sylvain Wallez skrev:
Daniel Fagerstrom wrote:
snip/
Summarizing my opinions: Users should be able to use any container.
... but we should have one usable out of the box for users that don't
want or don't know how to make a choice.
Absolutely. In the long run I think that the OSGi
Berin Loritsch skrev:
...
Much like Photoshop with filter plugins. The
block idea would be more analagous to complex macros for Photoshop.
They may provide new plugins to use in the package, but they allow you
to do predefined things.
I don't know enough about Photoshop to be able to
Daniel Fagerstrom wrote:
Berin Loritsch skrev:
...
Much like Photoshop with filter plugins. The block idea would be
more analagous to complex macros for Photoshop. They may provide new
plugins to use in the package, but they allow you to do predefined
things.
I don't know enough about
FYI, I'm on the technical review board of that conference.
Will you attend too?
Arje Cahn wrote:
FYI, I'm on the technical review board of that conference.
Will you attend too?
Don't know, probably not, but I'll have to be in Sweden the week after
that to given a keynote speech, so I might be able to stop by ;-)
--
Stefano.
I got another stack trace from our product today. I have 25 threads that
look like the one below. No thread appears to have the lock. I then
looked at getProfile() which is the only method getting the writeLock.
However, I don't see a releaseLocks() being done in that method. Am I
missing
I figured out that the releaseLocks happens elsewhere.
I noticed that several of the threads are waiting for the write lock.
There does appear to be one thread, that based on where it is, should
have the read lock, however the stack trace doesn't show it. That
thread is in the class loader
30 matches
Mail list logo
