You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Berin Loritsch <bl...@apache.org> on 2002/06/18 15:56:36 UTC
We have come full circle, Let's move forward
So far, we have had a lot of conversations which have spun our wheels
on how we can refine Avalon even more. So far, everyone is largely
happy with what we have. This is a good thing. Therefore, we should
place any last notes we have in the A5 proposal directory just to
table the discussion.
The next course of action is how do we improve what we have. We
already have a number of deprecations, so I want to keep that to a
minimum. Before we deprecate the release methods, we should put in
the javadocs that designing a component so that it is *required* to
be released is considered bad practice. The important thing is that
we need to document how it can be done satisfactorily.
Secondly, we need to revise our naming policy so that the use of the
*Selector is no longer needed. I.e. make it the norm that we state
our dependencies as ROLE + "/constraint". NOTE: I know Stephen
disagrees with using the interface name at all, but many people find
it a useful way of reducing the time it takes for a new developer to
maintain existing components. Until the meta-model is fixed with the
javadoc extensions it should be the preferred way of doing things.
There is less confusion over exactly which connection-manager interface
the component wants to use--until the meta-model is done.
Our focus should be now on refining the meta-model, and refining the
container/component contracts. The developer needs to see *in the
implementation* the interface that the component depends on, and the
creational policy for the component.
Lastly, I would like to bring two more points to the table:
* We should consider an additional lifecycle for a persistence layer.
It is the container's responsibility to save the information, but
for many types of components it would be useful to save configuration
changes made during runtime or saving datasets. I will come up with
a proposal in a separate thread.
* reference implementation for a session object. This is how stateful
session beans (EJB spec) and servlets manage state in an otherwise
stateless environment. It is also how they can manage to be used by
multiple threads or contexts of execution simultaneously. We should
put together a reference implentation of this in excalibur and then
vote whether it should be incorporated as part of Framework (at least
the defining interfaces).
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: We have come full circle, Let's move forward
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Marcus Crafter [mailto:crafterm@fztig938.bank.dresdner.net]
>
> On Tue, Jun 18, 2002 at 11:20:46AM -0400, Berin Loritsch wrote:
> > > From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
> > > This would solve 90% of the problems I had with Avalon.
> > > I had to create my container implementation because of this,
> > > and it was
> > > a real PITA.
> > >
> > > BTW, I regard it as a requirement to be able to do this
> > > without having
> > > to create my complete version of the
> > > container-componentmanager-whateverwecallit.
> >
> > Understood. The main challenge is what extensions do we
> > support. I.E. Marcus had four phases of component use
> > when Avalon only ever talks about 3 (init, active,
> > destruction).
>
> The phases came from my experiences with Cocoon, and trying to
> encapsulate a general solution that included its needs with our
own.
>
> IMO the following phases exist:
>
> 1. instantiation (bring the component to life)
> 2. access (get a reference to the component)
> 3. use the component (call business logic methods)
> 4. release (release the component back to the CM)
> 5. destruction (decomission the component).
>
> I separate 1 and 2 because a lookup() doesn't always mean the
> creation of a new component. I know client code doesn't
generally
> differentiate between this, but some of our users already have
and
> have defined lifecycle stages of this type.
>
> (Cocoon is the example I've been using here with it's
> RequestLifecycleComponent interface).
>
> I'd find it useful to be able to tailor a component at lookup()
time,
> especially in such a request based environment, but perhaps this
needs
> to be discussed further.
>
> 4. is, as discussed previously terminally ill :-)
Marcus,
If I may...
If you have 'tailor' step (number 2), you should (or: it would be wise
to) 'un-tailor' component some time after step 3..., unless it is
automagically done by some omnipotent force.
Vadim
> 5. is clear.
>
> Cheers,
>
> Marcus
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: We have come full circle, Let's move forward
Posted by Marcus Crafter <cr...@fztig938.bank.dresdner.net>.
On Tue, Jun 18, 2002 at 11:20:46AM -0400, Berin Loritsch wrote:
> > From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
> > This would solve 90% of the problems I had with Avalon.
> > I had to create my container implementation because of this,
> > and it was
> > a real PITA.
> >
> > BTW, I regard it as a requirement to be able to do this
> > without having
> > to create my complete version of the
> > container-componentmanager-whateverwecallit.
>
> Understood. The main challenge is what extensions do we
> support. I.E. Marcus had four phases of component use
> when Avalon only ever talks about 3 (init, active,
> destruction).
The phases came from my experiences with Cocoon, and trying to
encapsulate a general solution that included its needs with our own.
IMO the following phases exist:
1. instantiation (bring the component to life)
2. access (get a reference to the component)
3. use the component (call business logic methods)
4. release (release the component back to the CM)
5. destruction (decomission the component).
I separate 1 and 2 because a lookup() doesn't always mean the
creation of a new component. I know client code doesn't generally
differentiate between this, but some of our users already have and
have defined lifecycle stages of this type.
(Cocoon is the example I've been using here with it's
RequestLifecycleComponent interface).
I'd find it useful to be able to tailor a component at lookup() time,
especially in such a request based environment, but perhaps this needs
to be discussed further.
4. is, as discussed previously terminally ill :-)
5. is clear.
Cheers,
Marcus
--
.....
,,$$$$$$$$$, Marcus Crafter
;$' '$$$$: Computer Systems Engineer
$: $$$$: ManageSoft GmbH
$ o_)$$$: 82-84 Mainzer Landstrasse
;$, _/\ &&:' 60327 Frankfurt Germany
' /( &&&
\_&&&&'
&&&&.
&&&&&&&:
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: We have come full circle, Let's move forward
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Berin Loritsch wrote:
>>From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
>>This would solve 90% of the problems I had with Avalon.
>>I had to create my container implementation because of this,
>>and it was
>>a real PITA.
>
>>BTW, I regard it as a requirement to be able to do this
>>without having
>>to create my complete version of the
>>container-componentmanager-whateverwecallit.
>
> Understood. The main challenge is what extensions do we
> support. I.E. Marcus had four phases of component use
> when Avalon only ever talks about 3 (init, active,
> destruction).
>
>
>>>which raises another question: should we have optional interfaces
>>>(ones a container doesn't really have to recognize) in framework or
>>>not?
>>
>>User speak: are they part of Avalon or not? ;-)
>>
>>As Paul and I have recently seen on the James list, there is big
>>confusion between Framework, Excalibur and Phoenix.
>>
>>One of the reasons is that many features of "Avalon" are not in
>>Framework but in Excalibur, Phoenix etc...
>
>
> +1
>
>
>>IMNSHO, we should structure ourselves like this:
>>
>> API
>> |
>> | ------ Utility classes
>> / \
>> / | \
>> Reference implementations
>> | | | | | | |
>> Applications tha work in the above
>>
>>
>>
>>IE:
>>
>> Framework
>> |
>> | ------ Excalibur
>> / \
>> / | \
>>Phoenix, Fortress, Merlin, Jesktop (yes, Jesktop)
>> | | | | | | |
>> Cornerstone, Phoenix Apps, Jesktop Apps
>>
>>
>>This would clear up some confusion for the users.
>>
>>Since we are talking about containers, I wanna commit my container
>>somewhere (since everyone has one, can't I? ;-)
>
>
> Don't you want to make what's there better, instead of splitting
> attention even further?
:-))
>>Where shall I put it, in an Excalibur scratchpad?
>
> that would be the location, but excalibur is pretty crowded already.
> why not join forces w/ Fortress or Merlin?
It is my intention.
I just wanted to put it in there so to be able to converge more quickly...
Hmmm... I still have to think about how to do it...
... I guess I'll have a deeper look at Fortress and Merlin instead first :-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: We have come full circle, Let's move forward
Posted by Berin Loritsch <bl...@apache.org>.
> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
> This would solve 90% of the problems I had with Avalon.
> I had to create my container implementation because of this,
> and it was
> a real PITA.
>
> BTW, I regard it as a requirement to be able to do this
> without having
> to create my complete version of the
> container-componentmanager-whateverwecallit.
Understood. The main challenge is what extensions do we
support. I.E. Marcus had four phases of component use
when Avalon only ever talks about 3 (init, active,
destruction).
>
> >>* reference implementation for a session object. This is
> how stateful
> >> session beans (EJB spec) and servlets manage state in an otherwise
> >> stateless environment. It is also how they can manage to
> be used by
> >> multiple threads or contexts of execution simultaneously.
> We should
> >> put together a reference implentation of this in
> excalibur and then
> >> vote whether it should be incorporated as part of Framework (at
> >>least
> >> the defining interfaces).
> >
> >
> > which raises another question: should we have optional interfaces
> > (ones a container doesn't really have to recognize) in framework or
> > not?
>
> User speak: are they part of Avalon or not? ;-)
>
> As Paul and I have recently seen on the James list, there is big
> confusion between Framework, Excalibur and Phoenix.
>
> One of the reasons is that many features of "Avalon" are not in
> Framework but in Excalibur, Phoenix etc...
+1
>
> IMNSHO, we should structure ourselves like this:
>
> API
> |
> | ------ Utility classes
> / \
> / | \
> Reference implementations
> | | | | | | |
> Applications tha work in the above
>
>
>
> IE:
>
> Framework
> |
> | ------ Excalibur
> / \
> / | \
> Phoenix, Fortress, Merlin, Jesktop (yes, Jesktop)
> | | | | | | |
> Cornerstone, Phoenix Apps, Jesktop Apps
>
>
> This would clear up some confusion for the users.
>
> Since we are talking about containers, I wanna commit my container
> somewhere (since everyone has one, can't I? ;-)
Don't you want to make what's there better, instead of splitting
attention
even further?
>
> Where shall I put it, in an Excalibur scratchpad?
that would be the location, but excalibur is pretty crowded already.
why not join forces w/ Fortress or Merlin?
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: We have come full circle, Let's move forward
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Leo Simons wrote:
> I think we're not full circle just yet. Don't try and shelf the
> discussion; there may still be some valuable knowledge to be
> gained/transferred.
I agree.
I also think that I will put my attention on Centipede and Avalon 4.5.
Ant is basically using parts of the Ant2 proposals in current dot
releases, and this incremental update feels really good.
I would saw, let's talk about 5, and vote, when we feel sure, about
putting specific features in 4.x.
...
>>Lastly, I would like to bring two more points to the table:
>>* We should consider an additional lifecycle for a persistence layer.
>
>
> I think if we want something like this it would be good to take a look
> at the "custom marker proposal" (bad name) Marcus is working on, and try
> and integrate.
Definately.
This would solve 90% of the problems I had with Avalon.
I had to create my container implementation because of this, and it was
a real PITA.
BTW, I regard it as a requirement to be able to do this without having
to create my complete version of the
container-componentmanager-whateverwecallit.
>>* reference implementation for a session object. This is how stateful
>> session beans (EJB spec) and servlets manage state in an otherwise
>> stateless environment. It is also how they can manage to be used by
>> multiple threads or contexts of execution simultaneously. We should
>> put together a reference implentation of this in excalibur and then
>> vote whether it should be incorporated as part of Framework (at least
>> the defining interfaces).
>
>
> which raises another question: should we have optional interfaces (ones
> a container doesn't really have to recognize) in framework or not?
User speak: are they part of Avalon or not? ;-)
As Paul and I have recently seen on the James list, there is big
confusion between Framework, Excalibur and Phoenix.
One of the reasons is that many features of "Avalon" are not in
Framework but in Excalibur, Phoenix etc...
IMNSHO, we should structure ourselves like this:
API
|
| ------ Utility classes
/ \
/ | \
Reference implementations
| | | | | | |
Applications tha work in the above
IE:
Framework
|
| ------ Excalibur
/ \
/ | \
Phoenix, Fortress, Merlin, Jesktop (yes, Jesktop)
| | | | | | |
Cornerstone, Phoenix Apps, Jesktop Apps
This would clear up some confusion for the users.
Since we are talking about containers, I wanna commit my container
somewhere (since everyone has one, can't I? ;-)
Where shall I put it, in an Excalibur scratchpad?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: We have come full circle, Let's move forward
Posted by Berin Loritsch <bl...@apache.org>.
> From: Leo Simons [mailto:leosimons@apache.org]
>
> There are several other areas that deserve focus as well,
> like documentation and examples.
Yes, and those are things that need to be done now--with
A4.
> > Lastly, I would like to bring two more points to the table:
> > * We should consider an additional lifecycle for a
> persistence layer.
>
> I think if we want something like this it would be good to
> take a look at the "custom marker proposal" (bad name) Marcus
> is working on, and try and integrate.
Yes, but a standard is also worthwhile.
> > * reference implementation for a session object. This is
> how stateful
> > session beans (EJB spec) and servlets manage state in an otherwise
> > stateless environment. It is also how they can manage to
> be used by
> > multiple threads or contexts of execution simultaneously.
> We should
> > put together a reference implentation of this in
> excalibur and then
> > vote whether it should be incorporated as part of
> Framework (at least
> > the defining interfaces).
>
> which raises another question: should we have optional
> interfaces (ones a container doesn't really have to
> recognize) in framework or not?
Framework defined the minimum contracts between a component
and the container. The Session object proposal is the key
usability feature (that doesn't have to wait for A5) that
will enable stateful threadsafe components with a minimum
amount of intrusion on the part of the component developer
and the client of the component. It is something that we
need to take care of before we deprecate the release()
method because what we are talking about here will obviate
the need for a release() mechanism. Until that we have
sessions in some form, we do need to be able to release
components (pooled implementations).
Currently it is *possible* to provide pooled implementations
of components without a release() method, but the workarounds
necessary to make it happen render it not a solution.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: We have come full circle, Let's move forward
Posted by Leo Simons <le...@apache.org>.
I think we're not full circle just yet. Don't try and shelf the
discussion; there may still be some valuable knowledge to be
gained/transferred.
Some things you propose are still proposals, where you simply assume
that they are the only option. I feel the normal voting process is the
best way to handle each of these.
specific response:
> Our focus should be now on refining the meta-model, and refining the
> container/component contracts. The developer needs to see *in the
> implementation* the interface that the component depends on, and the
> creational policy for the component.
There are several other areas that deserve focus as well, like
documentation and examples.
> Lastly, I would like to bring two more points to the table:
> * We should consider an additional lifecycle for a persistence layer.
I think if we want something like this it would be good to take a look
at the "custom marker proposal" (bad name) Marcus is working on, and try
and integrate.
> * reference implementation for a session object. This is how stateful
> session beans (EJB spec) and servlets manage state in an otherwise
> stateless environment. It is also how they can manage to be used by
> multiple threads or contexts of execution simultaneously. We should
> put together a reference implentation of this in excalibur and then
> vote whether it should be incorporated as part of Framework (at least
> the defining interfaces).
which raises another question: should we have optional interfaces (ones
a container doesn't really have to recognize) in framework or not?
- Leo Simons
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: We have come full circle, Let's move forward
Posted by Peter Royal <pr...@apache.org>.
On Tuesday 18 June 2002 10:27 am, Berin Loritsch wrote:
> > For release() for example, you will basically say
> > "Deprecated without replacement. Non-ThreadSafe components
> > are considered bad practice." and *that* will cause a storm.
>
> You mis-understood.
>
> I am not proposing to deprecate it *at this time*, but to encourage
> the developer to think of alternative ways of developing their
> component so that it is not needed.
I'm +1 on Stephen McConnell's idea of moving towards Serviceable and
deprecating release() there. The migration path is then:
ComponentManager w/release() ->
ServiceManager(Locator) w/ deprecated release() ->
Servicemanager w/no release()
-pete
--
peter royal -> proyal@apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: We have come full circle, Let's move forward
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Berin Loritsch [mailto:bloritsch@apache.org]
>
> You mis-understood.
>
> I am not proposing to deprecate it *at this time*, but to
> encourage the developer to think of alternative ways of
> developing their component so that it is not needed.
Yes, but until we do have a replacement - and I do not
think we really reached concensus on it - making anything
public outside of the A5 proposal is just stirring up a lot
of FUD.
We have agreed that it would be nice without a release().
We never really agreed on the replacement. There are some
things that can be formalized so that you may be able to
design components with a need for release() without it
being bad practice. Without investigating those, I do
not think we can make any recommendation at all.
Take the Session for example: It is one way of doing threadsafe
components. But I want to see that it works, that it is
easy to work with, and that it is easily graspable
by newbies before I consider it ready to go and before I see
it as reason enough to deprecate release(). (At the moment
I consider it a tentacled horror.)
I do not want to scare the life out of those committed to
A4 by even hinting that A5 will have less features than A4.
So shove everything into A5 proposal, and wait with any
announcements regarding what developers should think of
until we have a solid understanding of what A5 will be
like. *Then* start the gradual transition.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: We have come full circle, Let's move forward
Posted by Berin Loritsch <bl...@apache.org>.
> From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com]
>
> +1 for stuffing everything into the proposal directory.
>
> -1 for everything else.
>
> Letting a not-yet-finished proposal affect the current
> version is not good.
>
> For release() for example, you will basically say
> "Deprecated without replacement. Non-ThreadSafe components
> are considered bad practice." and *that* will cause a storm.
You mis-understood.
I am not proposing to deprecate it *at this time*, but to encourage
the developer to think of alternative ways of developing their
component so that it is not needed.
> When A5 is really good-to-go we can start deprecating. At the
> moment it seems like we're just trying to shake off our
> remaining users.
No, we are just saying that we need to consider extending what
we have to add the missing pieces. The meta-info part is the
key missing piece.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: We have come full circle, Let's move forward
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
+1 for stuffing everything into the proposal directory.
-1 for everything else.
Letting a not-yet-finished proposal affect the current version
is not good.
For release() for example, you will basically say
"Deprecated without replacement. Non-ThreadSafe components
are considered bad practice." and *that* will cause a storm.
When A5 is really good-to-go we can start deprecating. At the
moment it seems like we're just trying to shake off our remaining
users.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>