Can't we just stop crossposting?
Who wants to follow the discussion gets on the Avalon list.
[EMAIL PROTECTED]
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
--
> From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]]
>
> Now, you (and Berin) were suggesting that the CM be extended
> to provide a single point of contruction control not only for
> Avalon components, but also for those legacy objects that
> might request non-simple contruction control (suc
> From: Vadim Gritsenko [mailto:[EMAIL PROTECTED]]
>
> Shouldn't some standard (default, etc) Manager will be available?
And what, pray tell, would it look like? The COmponentManger as it is
defined is a lookup mechanism. Nothing more. The ComponentSelector
pattern was designed to allow mult
CTED]]
> Sent: Thursday, June 06, 2002 3:18 PM
> To: [EMAIL PROTECTED]
> Cc: 'Avalon Developers List'
> Subject: Re: [Design] ContainerManager is under fire--let's find the
> best resolution
>
>
> Gosh, I forgot how strident can become talking about high
Stefano Mazzocchi wrote:
>You are telling me that instead of doing
>
> ConnectionPool pool = new ConnectionPool(...);
>
>you like to do
>
> ConnectionPool pool = (ConnectionPool) factory.create("connection
>pool");
>
>
Yuck.
Better:
ConnectionPool pool = (ConnectionPool) factory.create(
Co
Paulo Gaspar wrote:
>
> About Object instead of Component...
...
> I am using a CM similar in concept to the one Berin is proposing for many
> months already (I think it will be one year in October) and getting rid of
> Component and the other marker interfaces was one of my best decisions.
>
People,
the idea I had of Avalon kept with my hopes: it is a meme, an infective
programming notion that sticks in your head and that can't be further
removed.
Luckily, it also moved from a meme to code than to a community effort: I
can't say I'm entirely happy with what happens over at Avalon-la
> From: Berin Loritsch [mailto:[EMAIL PROTECTED]]
>
> > From: Leo Sutic [mailto:[EMAIL PROTECTED]]
> >
> > > From: Berin Loritsch [mailto:[EMAIL PROTECTED]]
> > >
> > > > Or, I always will get XManager? Then, lifecycle
> > management will
> > > > be moved to XManager, right?
> > >
>
About Object instead of Component...
> -Original Message-
> From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]]
> Sent: Friday, June 07, 2002 12:18 AM
>
> Gosh, I forgot how strident can become talking about high level
> abstractions... remind me of the good old days when we were discussi
> From: Berin Loritsch [mailto:[EMAIL PROTECTED]]
>
> > From: Leo Sutic [mailto:[EMAIL PROTECTED]]
> >
> > > From: Berin Loritsch [mailto:[EMAIL PROTECTED]]
> > >
> > > > Or, I always will get XManager? Then, lifecycle
> > > > management will
> > > > be moved to XManager, right?
> > >
> >
> From: Leo Sutic [mailto:[EMAIL PROTECTED]]
>
> > From: Berin Loritsch [mailto:[EMAIL PROTECTED]]
> >
> > > Or, I always will get XManager? Then, lifecycle
> management will
> > > be moved to XManager, right?
> >
> > You will always get the XManager. So yes, lifecycle does
> >
> From: Berin Loritsch [mailto:[EMAIL PROTECTED]]
>
> > Or, I always will get XManager? Then, lifecycle
> > management will be moved to XManager, right?
>
> You will always get the XManager. So yes, lifecycle does
> move to XManager. However, the XXManager can act as
>
> From: Berin Loritsch [mailto:[EMAIL PROTECTED]]
> > > The GeneratorManager would handle the release() method, or it
would
> > > declare its semantics for use.
> > >
> > > Component use should not be a function of component lookup.
> >
> > Ok. What then will be contract between component man
> From: Vadim Gritsenko [mailto:[EMAIL PROTECTED]]
> > Furthermore, a GeneratorManager can declare its own
> semantics. If you
> > want the release() method there, then there are no issues
> conflicting
> > with overall CM design.
>
> Ok, it means that for Generator I should create
> Gener
> From: Berin Loritsch [mailto:[EMAIL PROTECTED]]
>
> > From: Vadim Gritsenko [mailto:[EMAIL PROTECTED]]
> >
> >
> > And work itself will be done in XMLSource/XMLPipeline/XMLSink. I got
> > that part. Hope performance will not be sacrificed by this move (you
> > will be new()ing this objects all
> From: Vadim Gritsenko [mailto:[EMAIL PROTECTED]]
>
>
> And work itself will be done in XMLSource/XMLPipeline/XMLSink. I got
> that part. Hope performance will not be sacrificed by this move (you
> will be new()ing this objects all the time)
Modern JVMs have better GC policies, and is quicker
> From: Berin Loritsch [mailto:[EMAIL PROTECTED]]
>
> > From: Vadim Gritsenko [mailto:[EMAIL PROTECTED]]
> >
> > > From: Berin Loritsch [mailto:[EMAIL PROTECTED]]
> >
> >
> >
> > ASSUMPTION:
> >
> > Poolable component is a component with high instantiation
> > cost and state thus it can not be
> From: Vadim Gritsenko [mailto:[EMAIL PROTECTED]]
>
> JDBC connection must be aware of pooling (special handling in the
> close() method), which does not look good - current Avalon
> model where poolable component must not care about how it is
> being pooled is *much* better.
The connection
> From: Berin Loritsch [mailto:[EMAIL PROTECTED]]
>
> > From: Vadim Gritsenko [mailto:[EMAIL PROTECTED]]
> >
> > In J2EE, it is common to have session EJBs working with JDBC
> > connection. You obtain connection whenever you need it and
> > return to the pool when you are done.
>
> Semantic clar
> From: Vadim Gritsenko [mailto:[EMAIL PROTECTED]]
>
> In J2EE, it is common to have session EJBs working with JDBC
> connection. You obtain connection whenever you need it and
> return to the pool when you are done.
Semantic clarification:
You get the DataSource, and call getConnection().
> From: Vadim Gritsenko [mailto:[EMAIL PROTECTED]]
>
> > From: Berin Loritsch [mailto:[EMAIL PROTECTED]]
>
>
>
> ASSUMPTION:
>
> Poolable component is a component with high instantiation
> cost and state thus it can not be used in several threads
> simultaneously.
>
Don't forget Per-Th
Hi,
I'm not entirely familiar with the internals of Cocoon, so please bear
with me. However, my main point is two-fold:
-there is a difference in practice between recycling reusable components
and "real" garbage collection
-are we sure that removing the responsibility for management of reusable
Stefano Mazzocchi wrote:
>
>
> So, it makes perfect sense to merge the two aspects into a single CM.
+1
>
>
> You know what? I'm starting to think that the java GC is a gigantic
> mistake. Why? simple, it's useless.
>
I totally agree here - before I started Java programming I used many
other
Gosh, I forgot how strident can become talking about high level
abstractions... remind me of the good old days when we were discussing
what later became known as Avalon and Pier and I got such a huge fight
for a simple method.
ihihih, discussing such high-level abstractions can get really nasty
e
>
> Yes, if they share same ... how you call it? ... scope: both are
> ThreadSafe or Poolable (by nature). Here, one (Transformer) will be
> ThreadSafe (or even not a component (it's too lightweight for it)), and
> other (XMLSource) - Poolable.
>
> Thus, you can not keep an instance of XMLSourc
> From: Andy Lewis [mailto:[EMAIL PROTECTED]]
>
>
>
> >
> > If you to change Transformer interface to return only
> > XMLSource/ContentHandler, all the logic and state Transformer has
moves
> > into this XMLSource.
> >
> > Thus, XMLSource becomes heavy and Transformer light. Obviously,
> > Tran
> From: Berin Loritsch [mailto:[EMAIL PROTECTED]]
>
> > From: Leo Sutic [mailto:[EMAIL PROTECTED]]
> >
> > > From: Berin Loritsch [mailto:[EMAIL PROTECTED]]
> > >
> > > Hmm. What we have here is a bad design. Should the
> > > container make up for your poor design? Can you really get
> > > awa
> From: Leo Sutic [mailto:[EMAIL PROTECTED]]
>
> > From: Berin Loritsch [mailto:[EMAIL PROTECTED]]
> >
> > Hmm. What we have here is a bad design. Should the
> > container make up for your poor design? Can you really get
> > away with only three instances in a pool with a web
> > environment?
>
> If you to change Transformer interface to return only
> XMLSource/ContentHandler, all the logic and state Transformer has moves
> into this XMLSource.
>
> Thus, XMLSource becomes heavy and Transformer light. Obviously,
> Transformer becomes ThreadSafe (which is good) and XMLSource must be
>
> From: Berin Loritsch [mailto:[EMAIL PROTECTED]]
ASSUMPTION:
Poolable component is a component with high instantiation cost and
state thus it can not be used in several threads simultaneously.
> However, the interfaces for the Cocoon pipeline components are broken.
> A Generator should r
> From: Leo Sutic [mailto:[EMAIL PROTECTED]]
>
> > From: Berin Loritsch [mailto:[EMAIL PROTECTED]]
> >
> > > From: Leo Sutic [mailto:[EMAIL PROTECTED]]
> > >
> > > > From: Berin Loritsch [mailto:[EMAIL PROTECTED]]
> > > >
> > > > > From: Leo Sutic [mailto:[EMAIL PROTECTED]]
> > > > >
> >
> >
> From: Berin Loritsch [mailto:[EMAIL PROTECTED]]
>
> > From: Leo Sutic [mailto:[EMAIL PROTECTED]]
> >
> > > From: Berin Loritsch [mailto:[EMAIL PROTECTED]]
> > >
> > > > From: Leo Sutic [mailto:[EMAIL PROTECTED]]
> > > >
>
> Hmm. What we have here is a bad design. Should the
> container m
I've always maintained that the key difference between an object and a
component is granularity. Both can be reusable, but a component generally
represents a (reusable) encapsulation of a conceptually larger "chunk" of
logic/data than a typical object.
>> From: Leo Sutic [mailto:[EMAIL PROTECTED
> "Leo" == Leo Sutic <[EMAIL PROTECTED]> writes:
Leo> The difference is this - with explicit release I can:
Leo>public void someMethod () { component = manager.lookup
Leo> (ExpensiveButPooledComponent.ROLE); ... manager.release
Leo> (component); Added this
> From: Leo Sutic [mailto:[EMAIL PROTECTED]]
>
> > From: Berin Loritsch [mailto:[EMAIL PROTECTED]]
> >
> > > From: Leo Sutic [mailto:[EMAIL PROTECTED]]
> > >
> > > Suppose you have a pool-max of 3:
> > >
> > >public void handleRequest () {
> > > someMethod ();
> > > someMethod
> From: Berin Loritsch [mailto:[EMAIL PROTECTED]]
>
> > From: Leo Sutic [mailto:[EMAIL PROTECTED]]
> >
> > Suppose you have a pool-max of 3:
> >
> >public void handleRequest () {
> > someMethod ();
> > someMethod ();
> > someMethod ();
> > someMethod ();
> >
> From: Leo Sutic [mailto:[EMAIL PROTECTED]]
>
> > From: Berin Loritsch [mailto:[EMAIL PROTECTED]]
>
> > > Assume you have a CM that automatically reclaims all components
> > > after each request. That is, for Cocoon, when the request
> comes in,
> > > the CM starts keeping track of what com
I really like the philosophy behind what Berin is proposing here. You do
need to understand the lifecycle you are working in for component usage,
but how is that new
>
>
>> From: Berin Loritsch [mailto:[EMAIL PROTECTED]]
>>
>> > From: Leo Sutic [mailto:[EMAIL PROTECTED]]
>> >
>> > Berin,
>> >
> From: Berin Loritsch [mailto:[EMAIL PROTECTED]]
>
> > From: Leo Sutic [mailto:[EMAIL PROTECTED]]
> >
> > Berin,
> >
> > I am 75% for your new CM interface. The problem is point 4.
>
> Am I not a prophet?
:)
> > Assume you have a CM that automatically reclaims all
> > components after ea
> From: Leo Sutic [mailto:[EMAIL PROTECTED]]
>
> Berin,
>
> I am 75% for your new CM interface. The problem is point 4.
Am I not a prophet?
> Assume you have a CM that automatically reclaims all
> components after each request. That is, for Cocoon, when the
> request comes in, the CM start
40 matches
Mail list logo
