You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Federico Barbieri <sc...@betaversion.org> on 2001/02/26 14:23:41 UTC
[proposal] Primitive and composite patterns
I'm happy to see the avalon package looks much cleaner now so that you
can notice something... there are packages that we could call
"primitive"... avalon.component, avalon.context, configuration,
processor, lifecycle and others are totally decoupled one from the
other, they define a single, very specific contract and they are "self
contained".
Others packages uses this primitive to create more elaborate and high
level contracts (container etc.).
It's a general rule it's better to have primitive than composite
packages... because they don't have dependencies and they enforce SOC. I
may like the avalon.pool interfaces but I don't want to inherit all
component contracts. This make perfect sense.
So my first question is: container is right now a composite since uses
component. Is it right? Can we have a container package unaware of
components? If so it's critical not to mix contracts and clean it.
The same can be asked about datasource and a couple of other classes...
Second: I'm +0.001 to restore lifecycle into avalon.* ... just
aesthetic. :-)
Fede
Re: [proposal] Primitive and composite patterns
Posted by Peter Donald <do...@apache.org>.
At 01:11 27/2/01 -0800, Federico Barbieri wrote:
>BTW at this point a summary:
>
>packages:
>component
>configuration
>container
>context
>lifecycle
>pool
>processor
>thread
>util
I would remove container/util/thread/pool from primitive and possibly add
logger.
>camelot builds from the container and component packages an higher level
>pattern for component oriented containers.
I still don't think they are separated correctly at the moment but I don't
know what the best separation is yet.
>I like what I see... :-) do you?
Mostly ;)
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
Re: [proposal] Primitive and composite patterns
Posted by Federico Barbieri <sc...@betaversion.org>.
BTW at this point a summary:
packages:
component
configuration
container
context
lifecycle
pool
processor
thread
util
are PRIMITIVE
that means they are decoupled, you can use one each package separately.
Ex: I want to write some kind of application, I'll need conf and I like
avalon.Configuration, my application is going to be a container and I
like the avalon.container but even if I'll need to make child
communicate one with the other I don't like the ComponentManager and all
the avalon.component package, I'll use JNDI. Now I can do it, import
only what I want and forget all the rest.
Primitive are easier to understand and document becouse they are
self-contained.
camelot builds from the container and component packages an higher level
pattern for component oriented containers.
datasource uses component, configuration and loggable.
I like what I see... :-) do you?
Fede
Re: [proposal] Primitive and composite patterns
Posted by Peter Donald <do...@apache.org>.
At 03:15 27/2/01 -0800, Federico Barbieri wrote:
>"almost universaly"... I totally agree all abstract classes in camelot
>should implements Component so they are ready to use in all component
>aware enviroments. But contaier interfaces shouldn't.
Perhaps - but most things I use work with and manipulate the interfaces
rather than implementations and thus would have to do a cast and hope when
re-entering it into a CM which is bad ;)
>BTW what's the difference between Info and MetaInfo? I thought were the
>same and I removed Info but before you get pissed off :-)... I'm ready
>to restore it if there is a good explanation.
Info is information about the component. MetaInfo is static position
independent data (ie BeanInfo/MBean etc). LocatorInfo is information on how
to access component (ie URL/position/whatever).
MetaInfo never used to exhist but I got a few requests for it when
discussing it with a few people who thought it "odd" that LocatorInfo
extended Info that was meant to represent static position independent data.
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
Re: [proposal] Primitive and composite patterns
Posted by Federico Barbieri <sc...@betaversion.org>.
Peter Donald wrote:
>
> At 02:46 27/2/01 -0800, Federico Barbieri wrote:
> >Peter Donald wrote:
> >>
> >> At 12:59 27/2/01 -0800, Federico Barbieri wrote:
> >> >I meant tomcat is a Component viewed from the kernel since implements
> >> >Block. But its a container of servlets. Now servlet are not Component
> >> >but still Tomcat should be a Container... that's way Container shouldn't
> >> >be Component container.
> >>
> >> okay - I don't thikn it is any more. Entry's contain Objects rather than
> >> Components and thus can follow any design pattern from
> >> EJB/servlet/mailet/Portlet/other.
> >>
> >
> >ok then why the Container must be a Component?
>
> Mainly ease as Containers are almost universally placed in CMs it is easier
> to make them extend Component than have to futz with them later.
>
"almost universaly"... I totally agree all abstract classes in camelot
should implements Component so they are ready to use in all component
aware enviroments. But contaier interfaces shouldn't.
BTW what's the difference between Info and MetaInfo? I thought were the
same and I removed Info but before you get pissed off :-)... I'm ready
to restore it if there is a good explanation.
Fede
Re: [proposal] Primitive and composite patterns
Posted by Peter Donald <do...@apache.org>.
At 02:46 27/2/01 -0800, Federico Barbieri wrote:
>Peter Donald wrote:
>>
>> At 12:59 27/2/01 -0800, Federico Barbieri wrote:
>> >I meant tomcat is a Component viewed from the kernel since implements
>> >Block. But its a container of servlets. Now servlet are not Component
>> >but still Tomcat should be a Container... that's way Container shouldn't
>> >be Component container.
>>
>> okay - I don't thikn it is any more. Entry's contain Objects rather than
>> Components and thus can follow any design pattern from
>> EJB/servlet/mailet/Portlet/other.
>>
>
>ok then why the Container must be a Component?
Mainly ease as Containers are almost universally placed in CMs it is easier
to make them extend Component than have to futz with them later.
>I can have a servlet that
>"contains" others parts like Cocoon, Turbine etc. Why should they be
>Component or at least be forced to use Components somewhere if they
>don't want to?
Ease of use. If you want to place something in the CM it must implement
Component. Most Avalon based things use CM ... hence ;)
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
Re: [proposal] Primitive and composite patterns
Posted by Federico Barbieri <sc...@betaversion.org>.
Peter Donald wrote:
>
> At 12:59 27/2/01 -0800, Federico Barbieri wrote:
> >I meant tomcat is a Component viewed from the kernel since implements
> >Block. But its a container of servlets. Now servlet are not Component
> >but still Tomcat should be a Container... that's way Container shouldn't
> >be Component container.
>
> okay - I don't thikn it is any more. Entry's contain Objects rather than
> Components and thus can follow any design pattern from
> EJB/servlet/mailet/Portlet/other.
>
ok then why the Container must be a Component? I can have a servlet that
"contains" others parts like Cocoon, Turbine etc. Why should they be
Component or at least be forced to use Components somewhere if they
don't want to?
> >> It does in the long run - but now is not the time to do it I don't think.
> >> We haven't road tested camelot enough for it to be viable in alternate
> >> contexts. Once we see it tested out in a few other places then it may be
> >> something we could consider. We could break it down into
> >> install/deploy/container/info/registry sections. Of course this will be
> >> more further defined after use ;)
> >
> >have a look and tell me... I think that separation make things clearer.
>
> Perhaps - I don't see it though because most of them are used together. I
> would separate out "AvalonState" but no others ;)
most of them are used together in Phoenix. It's not intrinsec in the
container design the use or the need for components. I just don't think
interfaces should enforce a relation for no reason. Classes and abstract
classes should. Interfaces shouldn't.
>
> BTW could you use specific imports instead of glob imports. Especially in
> the proposal. The reason is that it makes it easy to refactor - you can
> search and replace the appropriate strings but with import globbing you
> actually have to think ;)
>
My fault! I war trying to get it compilable fast... :-)
Fede
Re: [proposal] Primitive and composite patterns
Posted by Peter Donald <do...@apache.org>.
At 12:59 27/2/01 -0800, Federico Barbieri wrote:
>I meant tomcat is a Component viewed from the kernel since implements
>Block. But its a container of servlets. Now servlet are not Component
>but still Tomcat should be a Container... that's way Container shouldn't
>be Component container.
okay - I don't thikn it is any more. Entry's contain Objects rather than
Components and thus can follow any design pattern from
EJB/servlet/mailet/Portlet/other.
>> It does in the long run - but now is not the time to do it I don't think.
>> We haven't road tested camelot enough for it to be viable in alternate
>> contexts. Once we see it tested out in a few other places then it may be
>> something we could consider. We could break it down into
>> install/deploy/container/info/registry sections. Of course this will be
>> more further defined after use ;)
>
>have a look and tell me... I think that separation make things clearer.
Perhaps - I don't see it though because most of them are used together. I
would separate out "AvalonState" but no others ;)
BTW could you use specific imports instead of glob imports. Especially in
the proposal. The reason is that it makes it easy to refactor - you can
search and replace the appropriate strings but with import globbing you
actually have to think ;)
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
Re: [proposal] Primitive and composite patterns
Posted by Federico Barbieri <sc...@betaversion.org>.
Peter Donald wrote:
>
> At 10:01 26/2/01 -0800, Federico Barbieri wrote:
> >Peter Donald wrote:
> >>
> >> At 05:23 26/2/01 -0800, Federico Barbieri wrote:
> >> >It's a general rule it's better to have primitive than composite
> >> >packages... because they don't have dependencies and they enforce SOC. I
> >> >may like the avalon.pool interfaces but I don't want to inherit all
> >> >component contracts. This make perfect sense.
> >>
> >> The problem is that if you want to place anything in a CM then it needs to
> >> implement Component - which is why some people I talked to said either
> >> *everything* should implement component or *nothing* should implement
> >> component and the CM should deal with objects. Thats the main reason why
> >> Pool etal extend Component.
> >
> >not sure... being a Recyclabe doesn't imply being a component too... so
> >I can have a pool being a Component and working with the CM but I can
> >have a pool NOT implementing component as stand alone.
>
> you can but it is for all purposes practically unusable. Under Avalon
> almost all components are shared via a ComponentManager. If we have to
> extend components trivially to implement Component then it is a PITA to use
> a CM.
>
quite true... classes should implement all needed patterns as they wish,
interfaces shouldn't overlap when it's not needed. take a look at
container/camelot. container is component free, camelot uses both
patterns for abstract classes and provide a solid ground for component
and container aware app (phoenix etc.)
> >The reason I want to clear this is simple... container is a desing
> >pattern that is exteremly useful in many situation, including phoenix
> >and its blocks, a servlet container and its servlet etc. If we can't
> >decouple container from component then a SE can't benefit of the
> >patterns since servlet ARE NOT components. This whould be a pity...
>
> I am not 100% clear what you are saying here but if it what I think you are
> saying then I have a different opinion.
>
> Whether something is a component or a container is completely a matter of
> perspective. From one perspective a object may be a component while from
> another it is a container.
>
> Take phoenix - It has a kernel (container) that hosts Applications
> (component). These applications (now looks like a Container) are in turn
> made of up of content-objects/Blocks (component). This Block (now a
> container) can host other things like mailets/servlets/ejbs/other
> (component again) etc.
I meant tomcat is a Component viewed from the kernel since implements
Block. But its a container of servlets. Now servlet are not Component
but still Tomcat should be a Container... that's way Container shouldn't
be Component container.
>
> >Then does it make sense to have a clean container package component
> >unaware and a higher camelot package component aware? The container can
> >be small but it's reusable by all container, camelot is for component
> >oriented containers (phoenix etc.).
>
> It does in the long run - but now is not the time to do it I don't think.
> We haven't road tested camelot enough for it to be viable in alternate
> contexts. Once we see it tested out in a few other places then it may be
> something we could consider. We could break it down into
> install/deploy/container/info/registry sections. Of course this will be
> more further defined after use ;)
have a look and tell me... I think that separation make things clearer.
Fede
Re: [proposal] Primitive and composite patterns
Posted by Peter Donald <do...@apache.org>.
At 10:01 26/2/01 -0800, Federico Barbieri wrote:
>Peter Donald wrote:
>>
>> At 05:23 26/2/01 -0800, Federico Barbieri wrote:
>> >It's a general rule it's better to have primitive than composite
>> >packages... because they don't have dependencies and they enforce SOC. I
>> >may like the avalon.pool interfaces but I don't want to inherit all
>> >component contracts. This make perfect sense.
>>
>> The problem is that if you want to place anything in a CM then it needs to
>> implement Component - which is why some people I talked to said either
>> *everything* should implement component or *nothing* should implement
>> component and the CM should deal with objects. Thats the main reason why
>> Pool etal extend Component.
>
>not sure... being a Recyclabe doesn't imply being a component too... so
>I can have a pool being a Component and working with the CM but I can
>have a pool NOT implementing component as stand alone.
you can but it is for all purposes practically unusable. Under Avalon
almost all components are shared via a ComponentManager. If we have to
extend components trivially to implement Component then it is a PITA to use
a CM.
>The reason I want to clear this is simple... container is a desing
>pattern that is exteremly useful in many situation, including phoenix
>and its blocks, a servlet container and its servlet etc. If we can't
>decouple container from component then a SE can't benefit of the
>patterns since servlet ARE NOT components. This whould be a pity...
I am not 100% clear what you are saying here but if it what I think you are
saying then I have a different opinion.
Whether something is a component or a container is completely a matter of
perspective. From one perspective a object may be a component while from
another it is a container.
Take phoenix - It has a kernel (container) that hosts Applications
(component). These applications (now looks like a Container) are in turn
made of up of content-objects/Blocks (component). This Block (now a
container) can host other things like mailets/servlets/ejbs/other
(component again) etc.
>Then does it make sense to have a clean container package component
>unaware and a higher camelot package component aware? The container can
>be small but it's reusable by all container, camelot is for component
>oriented containers (phoenix etc.).
It does in the long run - but now is not the time to do it I don't think.
We haven't road tested camelot enough for it to be viable in alternate
contexts. Once we see it tested out in a few other places then it may be
something we could consider. We could break it down into
install/deploy/container/info/registry sections. Of course this will be
more further defined after use ;)
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
Re: [proposal] Primitive and composite patterns
Posted by Federico Barbieri <sc...@betaversion.org>.
Peter Donald wrote:
>
> At 05:23 26/2/01 -0800, Federico Barbieri wrote:
> >It's a general rule it's better to have primitive than composite
> >packages... because they don't have dependencies and they enforce SOC. I
> >may like the avalon.pool interfaces but I don't want to inherit all
> >component contracts. This make perfect sense.
>
> The problem is that if you want to place anything in a CM then it needs to
> implement Component - which is why some people I talked to said either
> *everything* should implement component or *nothing* should implement
> component and the CM should deal with objects. Thats the main reason why
> Pool etal extend Component.
not sure... being a Recyclabe doesn't imply being a component too... so
I can have a pool being a Component and working with the CM but I can
have a pool NOT implementing component as stand alone.
The reason I want to clear this is simple... container is a desing
pattern that is exteremly useful in many situation, including phoenix
and its blocks, a servlet container and its servlet etc. If we can't
decouple container from component then a SE can't benefit of the
patterns since servlet ARE NOT components. This whould be a pity...
>
> >So my first question is: container is right now a composite since uses
> >component. Is it right? Can we have a container package unaware of
> >components? If so it's critical not to mix contracts and clean it.
>
> See above. Remember that container (which I still thinkg should be camelot)
> is not just a container package but has other things like deployment (and
> will have installing when I differentiate between install/deploy). If we
> want to call it conatiner it should be further differentaited but I think
> it will lead to confusion (hence the abstract name that has no semantic
> connotations).
>
Then does it make sense to have a clean container package component
unaware and a higher camelot package component aware? The container can
be small but it's reusable by all container, camelot is for component
oriented containers (phoenix etc.).
> Cheers,
>
> Pete
>
Fede
Re: [proposal] Primitive and composite patterns
Posted by Peter Donald <do...@apache.org>.
At 05:23 26/2/01 -0800, Federico Barbieri wrote:
>It's a general rule it's better to have primitive than composite
>packages... because they don't have dependencies and they enforce SOC. I
>may like the avalon.pool interfaces but I don't want to inherit all
>component contracts. This make perfect sense.
The problem is that if you want to place anything in a CM then it needs to
implement Component - which is why some people I talked to said either
*everything* should implement component or *nothing* should implement
component and the CM should deal with objects. Thats the main reason why
Pool etal extend Component.
>So my first question is: container is right now a composite since uses
>component. Is it right? Can we have a container package unaware of
>components? If so it's critical not to mix contracts and clean it.
See above. Remember that container (which I still thinkg should be camelot)
is not just a container package but has other things like deployment (and
will have installing when I differentiate between install/deploy). If we
want to call it conatiner it should be further differentaited but I think
it will lead to confusion (hence the abstract name that has no semantic
connotations).
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*