You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Paul Hammant <Pa...@yahoo.com> on 2002/03/30 16:17:57 UTC
Website docs
Folks,
Some obersvations :
Page http://jakarta.apache.org/avalon/
----------------------------------------
1) Sub-Projects "logkit" before "Framework". Framework is our major art,
it should be first.
2) "Logkit" I think some front page addition to the effect of :
LogKit is the preferred logger for Avalon sub projects and components.
It is not a static logger like that other popular one that Apache hosts,
because we prefer one that is true to our IoC pattern. It is
interface/impl separated and can redirect its logging to that
aforementioned static logger or to various other implementations local
and remote.
3) "Excalibur" I think the addition of - These components can be used in
client or server side Java applications that in all other senses are not
dependant on Avalon. For server side Java, they can be used in the
Servlet context or fully blown server applications.
4) "Phoenix" - Pheonix is a Application Server for other Servers. ....
composed of blocks...
5) "Cornerstone" ... can be used to build your own server for phoenix
(i.e. drop starting point).
6) "Testlet" - can we purge this ?
7) "Applications". New section.
Page http://jakarta.apache.org/avalon/framework/index.html
-------------------------------------------------------------
1) "Target Audience"
Is now : This documentation is aimed towards developers who are
interested in the design principles of Avalon, or wish to develop code
that will be incorporated into Avalon
Should be : This documentation is aimed towards developers who are
interested in the design principles of Avalon, or wish to develop code
that will be incorporated into Avalon, or reuse Avalon concepts in their
own application.
2) "Theoretical Aspects of Component Development"
I'd like to add a new pattern that we already informally treat
reverently. It is "Interface/Impl seperation". People understand it but
do not really apply it, of it is mucked up. Catalina, for example, is
supposed to be interface/impl separated but is (or was last time I was
active in their mail list) not. The other thing that wven we are
historically a bit guilty of is the separation in terms of jars. We
desire this because we want to hide implementation. Following of from
Peter's K/CAPI/HC trinity of classloaders, where Hosted comps (HC) only
see the Client API (CAPI), the Kernel (K) may have chosen to hide the
impl of the CAPI in a different clas loader, not just by dyanmic proxy.
The K/CAPI/HC trinity will be repeated many times over in the most
complex cases (Phoenix hosting JAMES, FtpServer, Jesktop, EOB). It would
be good if we could really start promoting this. At least I am getting
sick of explaining it to the people I meet on the net when they have
something that is almost a good candidate for an example for EOB. One
case wherewe have it wrong is I think cornerstone.jar, it contains
interface and impl and will probably be left as is for historical reasons.
I think I have created enough trouble for one day.... ;-)
Regards,
- Paul H
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Website docs
Posted by Paul Hammant <Pa...@yahoo.com>.
Pete,
> By the way, I am quite happy with 'Interface/Impl seperation' as the
> MEME formerly known as the 'Interface' pattern. I trust you are
> equally happy with 'InformingAPI' and that we won't meet in the middle
> for this.
Sorry that sounds rude. I hit send before appending the smiley.
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Website docs
Posted by Pete Carapetyan <pe...@datafundamentals.com>.
> Citing JDBC, Jxxx, then I agree with you that they are more APIs. Maybe
> we can meet in the middle by saying that ones duty as a Java developer
> is to split into interface, abstractions, and implementations.
>
> In AltRMI we hope that interface is exacltly that and includes final
> serialiazable classes (pattern book referes to these as ImmutableBeans,
> other as 'Value Objects'). The difference between the anstract and
> final classes is moot as far as AltRMI (and the bean container that uses
> it - Enterprise Object Broker) is concerned. Neither the abstract or
> final (impl) classes arrive on the client side. The client only deals
> with the interface and the ImmutableBeans.
>
> EJB is very similar. Client only deals with Home and Remote interfaces
> and knows little of how the bean developer put the app together or what
> patterns they used.
>
> >>You have not talked about an equally important test of your seperation.
> >> Zip the interface into one jar, the impl into another and a test into a
> >>third. Mount the three in different classloaders with only the
> >>interfaces visible to both the other two. I.e. it is no good separating
> >>if you distribute both in one Jar.
> >>
> >
> >Indeed. Have not looked how you handle it with the three different logging
> >components, any one of which can be used, but it is the same problem? Assume, the
> >same solution?
> >
> Three different logging comps? LogKit, Log4J & Commons-Logger? We
> only really use the former.
>
Sorry, but I was citing this as an example. In a world full of me too's, it was our hope
to use Avalon to allow people to bring in and use their favorite components. "You are our
only hope, OB1".
> >It seems unlikely though, that any of this would really be possible without a
> >configurator tool that would let you build your components together as a group
> >designed to work with each other. Not just like Maven, but in a addition, with pick
> >boxes like pick this logging component, this persistence component, this view
> >component, etc.
> >
> Picker. Hmm sounds like our years old ComponentManager.
>
Thanks, I shall study that next. Does it address the problem you mentioned earlier, which
you mention above in the paragraph ending with
*I.e. it is no good separating
>>if you distribute both in one Jar.*
It is more the build issue that I am trying to wrestle with, in my head.
> >There is a bunch of us who are refugees from another very successful framework, but
> >one which we considered to be eventually doomed because of it's tightly coupled, and
> >commercially sponsored roots. We have, apparently, broken off to start afresh. We
> >will be attempting to use Avalon as our starting point. Quite a terrific framework,
> >this Avalon! No telling how fast this will move, though, as the old framework is
> >working well enough for us that we don't have to slam together a bad product together
> >just for the sake of getting something out the door. It is starting very slowly, so
> >far, which is fine.
> >
> No name? Another commerical effort? Using or competing with Avalon?
> Since we're name dropping, are your refugees from one other listed
> frameworks on JSR111 ?
>
No name yet, but only because we are still forming. It would also be discourteous to the
other guys to announce before they offer their consent.
Another commercial effort?
NOT ! We are all open-sourcers, otherwise we would be still with the bad nasty from whence
we came.
Using or competing with Avalon?
Using. We are just trying to build what we need to use. We have already done it before, it
just wasn't pluggable, so we dramatically reduced our gene pool. If our goals were not
somewhat orthogonal to Avalon, I am sure we would be joining outright, rather than
supplementing. But we will have an Apache style license, so probably anything we do would
be something that could be incorporated by Avalon, that would be up to Avalon, and not to
us. Most of us seem to be dedicated non-political types, something which is hard to do
within Apache, if history is any guide. Just look at the Forrest/Maven thing. To heck with
that! One Interface (as in contract), and let the market decide which component it wants
to use to get the job done.
> By the way, I am quite happy with 'Interface/Impl seperation' as the
> MEME formerly known as the 'Interface' pattern. I trust you are equally
> happy with 'InformingAPI' and that we won't meet in the middle for this.
Not so fast, home boy. My only problem with Interface/Impl as a term is that it uses the
ambiguous Interface, and thus potentially muddying the waters. But InformingAPI is just a
proxy term for the concept. I would much rather have a term that was universally
recognized than to start yet another, ugh. Is Interface/Impl universally recognized, as
in, a standardized term that can be pointed to as IoC and SeparationOfConcerns is? If so,
that's the road I would propose to take. Less is better, when it comes to confusing terms.
But if it isn't clear, then let's make it clear, whatever the term ends up being. Your
identification of the problem itself is right on the money, my 2c.
JSR 111?
Not.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Website docs
Posted by Paul Hammant <Pa...@yahoo.com>.
Pete,
><snip discussing the difference between the InformingAPI and the component that
>implements it>
>
>>>What this does for us is make sure that the first guy to implement a component
>>>works to a common API, such as JAAS, JCA, or JBLAH, instead of just doing his
>>>own thing. That way the next guy works to the JBLAH interface when he writes his
>>>plubbable component, not to the interface set by the JBlahComponent, which has
>>>every right to be funky, without the InformingAPI pattern. Keeps the idea of
>>>pluggability possible in practice, rather than just as an abstract idea that
>>>falls apart when the second implementation doesn't work to the same interfaces
>>>that the first guy uses.
>>>
>>>Does that make sense? ...or did I go off into different waters?
>>>
>>More or less the same thing. The first person to code the the thing
>>deliberately creates interfaces thus making an API. Wiley's Patterns
>>for Java book refers to it as 'Interface' and cites Grand98 as the
>>origin. It is a dodgy thing to include in a pattern book as Java has it
>>as a core concept. Having said that people think iyt is mostly for
>>things they use and not things they make. It is worth pushing..
>>
>
>Interface is one of those polymorphic terms in the english language that means so
>many things. Here, it is used in the more literal contract sense, but not perfectly
>literal, because JAAS, JCA, JDBC, and JXXX are not written as interfaces they are
>API's. Semantics then can be more than a little bit confusing, because from a
>component standpoint, you want to look at them as an interface which the component
>would implement as a black box.
>
I agree that 'Interface' is overloaded in English let alone computing.
Citing JDBC, Jxxx, then I agree with you that they are more APIs. Maybe
we can meet in the middle by saying that ones duty as a Java developer
is to split into interface, abstractions, and implementations.
In AltRMI we hope that interface is exacltly that and includes final
serialiazable classes (pattern book referes to these as ImmutableBeans,
other as 'Value Objects'). The difference between the anstract and
final classes is moot as far as AltRMI (and the bean container that uses
it - Enterprise Object Broker) is concerned. Neither the abstract or
final (impl) classes arrive on the client side. The client only deals
with the interface and the ImmutableBeans.
EJB is very similar. Client only deals with Home and Remote interfaces
and knows little of how the bean developer put the app together or what
patterns they used.
>>You have not talked about an equally important test of your seperation.
>> Zip the interface into one jar, the impl into another and a test into a
>>third. Mount the three in different classloaders with only the
>>interfaces visible to both the other two. I.e. it is no good separating
>>if you distribute both in one Jar.
>>
>
>Indeed. Have not looked how you handle it with the three different logging
>components, any one of which can be used, but it is the same problem? Assume, the
>same solution?
>
Three different logging comps? LogKit, Log4J & Commons-Logger? We
only really use the former.
>It seems unlikely though, that any of this would really be possible without a
>configurator tool that would let you build your components together as a group
>designed to work with each other. Not just like Maven, but in a addition, with pick
>boxes like pick this logging component, this persistence component, this view
>component, etc.
>
Picker. Hmm sounds like our years old ComponentManager.
>There are many more problems than this though, because not all InformingAPI's are so
>clean. Lots of API's are an amalgamation of all kinds of functionality. No way you
>can bring them in as a single purpose component, but instead as a collection of
>components. Struts is a perfect example. It brings together many different
>functionalities. You would have one InformingAPI, but many different component
>interfaces, including Validation, action mapping, and on and on. But a different
>InformingAPI that accomplishes many of the same goals is JavaServerFaces (JSR127)
>which takes these forms, and more. So if you wanted plugability to use one or the
>other, JSF provides 7 distinct areas, Struts 5 distinct areas, and the mapping
>between them is not so clean. Hurts my head to think about this.
>
>>Lastly, when you say "our own little Avalon framework" what do you mean ?
>>
>
>There is a bunch of us who are refugees from another very successful framework, but
>one which we considered to be eventually doomed because of it's tightly coupled, and
>commercially sponsored roots. We have, apparently, broken off to start afresh. We
>will be attempting to use Avalon as our starting point. Quite a terrific framework,
>this Avalon! No telling how fast this will move, though, as the old framework is
>working well enough for us that we don't have to slam together a bad product together
>just for the sake of getting something out the door. It is starting very slowly, so
>far, which is fine.
>
No name? Another commerical effort? Using or competing with Avalon?
Since we're name dropping, are your refugees from one other listed
frameworks on JSR111 ?
By the way, I am quite happy with 'Interface/Impl seperation' as the
MEME formerly known as the 'Interface' pattern. I trust you are equally
happy with 'InformingAPI' and that we won't meet in the middle for this.
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Website docs
Posted by Pete Carapetyan <pe...@datafundamentals.com>.
<snip discussing the difference between the InformingAPI and the component that
implements it>
> >What this does for us is make sure that the first guy to implement a component
> >works to a common API, such as JAAS, JCA, or JBLAH, instead of just doing his
> >own thing. That way the next guy works to the JBLAH interface when he writes his
> >plubbable component, not to the interface set by the JBlahComponent, which has
> >every right to be funky, without the InformingAPI pattern. Keeps the idea of
> >pluggability possible in practice, rather than just as an abstract idea that
> >falls apart when the second implementation doesn't work to the same interfaces
> >that the first guy uses.
> >
> >Does that make sense? ...or did I go off into different waters?
> >
> More or less the same thing. The first person to code the the thing
> deliberately creates interfaces thus making an API. Wiley's Patterns
> for Java book refers to it as 'Interface' and cites Grand98 as the
> origin. It is a dodgy thing to include in a pattern book as Java has it
> as a core concept. Having said that people think iyt is mostly for
> things they use and not things they make. It is worth pushing..
>
Interface is one of those polymorphic terms in the english language that means so
many things. Here, it is used in the more literal contract sense, but not perfectly
literal, because JAAS, JCA, JDBC, and JXXX are not written as interfaces they are
API's. Semantics then can be more than a little bit confusing, because from a
component standpoint, you want to look at them as an interface which the component
would implement as a black box.
> You have not talked about an equally important test of your seperation.
> Zip the interface into one jar, the impl into another and a test into a
> third. Mount the three in different classloaders with only the
> interfaces visible to both the other two. I.e. it is no good separating
> if you distribute both in one Jar.
Indeed. Have not looked how you handle it with the three different logging
components, any one of which can be used, but it is the same problem? Assume, the
same solution?
It seems unlikely though, that any of this would really be possible without a
configurator tool that would let you build your components together as a group
designed to work with each other. Not just like Maven, but in a addition, with pick
boxes like pick this logging component, this persistence component, this view
component, etc.
There are many more problems than this though, because not all InformingAPI's are so
clean. Lots of API's are an amalgamation of all kinds of functionality. No way you
can bring them in as a single purpose component, but instead as a collection of
components. Struts is a perfect example. It brings together many different
functionalities. You would have one InformingAPI, but many different component
interfaces, including Validation, action mapping, and on and on. But a different
InformingAPI that accomplishes many of the same goals is JavaServerFaces (JSR127)
which takes these forms, and more. So if you wanted plugability to use one or the
other, JSF provides 7 distinct areas, Struts 5 distinct areas, and the mapping
between them is not so clean. Hurts my head to think about this.
> Lastly, when you say "our own little Avalon framework" what do you mean ?
There is a bunch of us who are refugees from another very successful framework, but
one which we considered to be eventually doomed because of it's tightly coupled, and
commercially sponsored roots. We have, apparently, broken off to start afresh. We
will be attempting to use Avalon as our starting point. Quite a terrific framework,
this Avalon! No telling how fast this will move, though, as the old framework is
working well enough for us that we don't have to slam together a bad product together
just for the sake of getting something out the door. It is starting very slowly, so
far, which is fine.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Website docs
Posted by Paul Hammant <Pa...@yahoo.com>.
Pete,
>>2) "Theoretical Aspects of Component Development"
>>
>>I'd like to add a new pattern that we already informally treat
>>reverently. It is "Interface/Impl seperation". People understand it but
>>do not really apply it, of it is mucked up. Catalina, for example, is
>>supposed to be interface/impl separated but is (or was last time I was
>>active in their mail list) not. The other thing that wven we are
>>historically a bit guilty of is the separation in terms of jars. We
>>desire this because we want to hide implementation. Following of from
>>Peter's K/CAPI/HC trinity of classloaders, where Hosted comps (HC) only
>>see the Client API (CAPI), the Kernel (K) may have chosen to hide the
>>impl of the CAPI in a different clas loader, not just by dyanmic proxy.
>>The K/CAPI/HC trinity will be repeated many times over in the most
>>complex cases (Phoenix hosting JAMES, FtpServer, Jesktop, EOB). It would
>>be good if we could really start promoting this. At least I am getting
>>sick of explaining it to the people I meet on the net when they have
>>something that is almost a good candidate for an example for EOB. One
>>case wherewe have it wrong is I think cornerstone.jar, it contains
>>interface and impl and will probably be left as is for historical reasons.
>>
>
>We are already trying to address this in our own little Avalon framework, and I
>would like to repeat it below to make sure that I understand properly, and to
>make sure that I am understanding what you are saying.
>
>Basically, we decided to call it, at least for the moment, the InformingAPI
>pattern.
>
>What that says is that XxxComponent may be BlahComponent or FooComponent, but
>that regardless of where it came from, what it is intended to do is implement
>the JXXX Api. The agreement then, is to use an InformingAPI to define the
>interface, and then BlahComponent, FooComponent and BarComponent may then
>implement this interface in their own black box kind of way.
>
>What this does for us is make sure that the first guy to implement a component
>works to a common API, such as JAAS, JCA, or JBLAH, instead of just doing his
>own thing. That way the next guy works to the JBLAH interface when he writes his
>plubbable component, not to the interface set by the JBlahComponent, which has
>every right to be funky, without the InformingAPI pattern. Keeps the idea of
>pluggability possible in practice, rather than just as an abstract idea that
>falls apart when the second implementation doesn't work to the same interfaces
>that the first guy uses.
>
>Does that make sense? ...or did I go off into different waters?
>
More or less the same thing. The first person to code the the thing
deliberately creates interfaces thus making an API. Wiley's Patterns
for Java book refers to it as 'Interface' and cites Grand98 as the
origin. It is a dodgy thing to include in a pattern book as Java has it
as a core concept. Having said that people think iyt is mostly for
things they use and not things they make. It is worth pushing..
You have not talked about an equally important test of your seperation.
Zip the interface into one jar, the impl into another and a test into a
third. Mount the three in different classloaders with only the
interfaces visible to both the other two. I.e. it is no good separating
if you distribute both in one Jar.
Lastly, when you say "our own little Avalon framework" what do you mean ?
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Website docs
Posted by Pete Carapetyan <pe...@datafundamentals.com>.
> <snip>
> 2) "Theoretical Aspects of Component Development"
>
> I'd like to add a new pattern that we already informally treat
> reverently. It is "Interface/Impl seperation". People understand it but
> do not really apply it, of it is mucked up. Catalina, for example, is
> supposed to be interface/impl separated but is (or was last time I was
> active in their mail list) not. The other thing that wven we are
> historically a bit guilty of is the separation in terms of jars. We
> desire this because we want to hide implementation. Following of from
> Peter's K/CAPI/HC trinity of classloaders, where Hosted comps (HC) only
> see the Client API (CAPI), the Kernel (K) may have chosen to hide the
> impl of the CAPI in a different clas loader, not just by dyanmic proxy.
> The K/CAPI/HC trinity will be repeated many times over in the most
> complex cases (Phoenix hosting JAMES, FtpServer, Jesktop, EOB). It would
> be good if we could really start promoting this. At least I am getting
> sick of explaining it to the people I meet on the net when they have
> something that is almost a good candidate for an example for EOB. One
> case wherewe have it wrong is I think cornerstone.jar, it contains
> interface and impl and will probably be left as is for historical reasons.
We are already trying to address this in our own little Avalon framework, and I
would like to repeat it below to make sure that I understand properly, and to
make sure that I am understanding what you are saying.
Basically, we decided to call it, at least for the moment, the InformingAPI
pattern.
What that says is that XxxComponent may be BlahComponent or FooComponent, but
that regardless of where it came from, what it is intended to do is implement
the JXXX Api. The agreement then, is to use an InformingAPI to define the
interface, and then BlahComponent, FooComponent and BarComponent may then
implement this interface in their own black box kind of way.
What this does for us is make sure that the first guy to implement a component
works to a common API, such as JAAS, JCA, or JBLAH, instead of just doing his
own thing. That way the next guy works to the JBLAH interface when he writes his
plubbable component, not to the interface set by the JBlahComponent, which has
every right to be funky, without the InformingAPI pattern. Keeps the idea of
pluggability possible in practice, rather than just as an abstract idea that
falls apart when the second implementation doesn't work to the same interfaces
that the first guy uses.
Does that make sense? ...or did I go off into different waters?
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Website docs
Posted by Paul Hammant <Pa...@yahoo.com>.
Peter,
I have submitted a document. As usual I have ignored good advise on
what to leave out... ;-)
- Paul
>Hi,
>
>Looks nicer.
>
>On Sun, 31 Mar 2002 02:17, Paul Hammant wrote:
>
>>Page http://jakarta.apache.org/avalon/framework/index.html
>>-------------------------------------------------------------
>>
>>1) "Target Audience"
>>
>>Is now : This documentation is aimed towards developers who are
>>interested in the design principles of Avalon, or wish to develop code
>>that will be incorporated into Avalon
>>
>>Should be : This documentation is aimed towards developers who are
>>interested in the design principles of Avalon, or wish to develop code
>>that will be incorporated into Avalon, or reuse Avalon concepts in their
>>own application.
>>
>
>Okay - also delete the second paragraph in introduction as it is no longer
>relevent.
>
>>2) "Theoretical Aspects of Component Development"
>>
>>I'd like to add a new pattern that we already informally treat
>>reverently. It is "Interface/Impl seperation". People understand it but
>>do not really apply it, of it is mucked up. Catalina, for example, is
>>supposed to be interface/impl separated but is (or was last time I was
>>active in their mail list) not. The other thing that wven we are
>>historically a bit guilty of is the separation in terms of jars. We
>>desire this because we want to hide implementation. Following of from
>>Peter's K/CAPI/HC trinity of classloaders, where Hosted comps (HC) only
>>see the Client API (CAPI), the Kernel (K) may have chosen to hide the
>>impl of the CAPI in a different clas loader, not just by dyanmic proxy.
>>The K/CAPI/HC trinity will be repeated many times over in the most
>>complex cases (Phoenix hosting JAMES, FtpServer, Jesktop, EOB). It would
>>be good if we could really start promoting this. At least I am getting
>>sick of explaining it to the people I meet on the net when they have
>>something that is almost a good candidate for an example for EOB. One
>>case wherewe have it wrong is I think cornerstone.jar, it contains
>>interface and impl and will probably be left as is for historical reasons.
>>
>
>I think we should just start discussing about separation of implementation
>and the interface/contract. Dont worry about describing classloader/jar
>issues just yet.
>
>The main reason I do it is because;
>
>1. it forces you to decouple different modules/components/objects
>2. if specified correctly allows you to easily change the implementation of
>the interface/contract in the future.
>3. makes it possible for a user to read documentation about interface without
>having the implementation details clutter up their perception
>
>if you are building objects with the aim of reuse then [2] is important but
>most people don't build for reuse (and most XP advocates say you should just
>plan to use not reuse) and thus [1] and [2] are more important. If you feel
>like documenting that and expanding this then feel free to.
>
>Tackling the separation of ClassLoaders/jars is a related but different
>issue. It could be documented but I think it may be best to tackle this
>second and put it in a a different document. This is mainly because many
>applications do not require that level of separation.
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Website docs
Posted by Paul Hammant <Pa...@yahoo.com>.
Peter,
All points noted. Will implement.
-PH
>Hi,
>
>Looks nicer.
>
>On Sun, 31 Mar 2002 02:17, Paul Hammant wrote:
>
>>Page http://jakarta.apache.org/avalon/framework/index.html
>>-------------------------------------------------------------
>>
>>1) "Target Audience"
>>
>>Is now : This documentation is aimed towards developers who are
>>interested in the design principles of Avalon, or wish to develop code
>>that will be incorporated into Avalon
>>
>>Should be : This documentation is aimed towards developers who are
>>interested in the design principles of Avalon, or wish to develop code
>>that will be incorporated into Avalon, or reuse Avalon concepts in their
>>own application.
>>
>
>Okay - also delete the second paragraph in introduction as it is no longer
>relevent.
>
>>2) "Theoretical Aspects of Component Development"
>>
>>I'd like to add a new pattern that we already informally treat
>>reverently. It is "Interface/Impl seperation". People understand it but
>>do not really apply it, of it is mucked up. Catalina, for example, is
>>supposed to be interface/impl separated but is (or was last time I was
>>active in their mail list) not. The other thing that wven we are
>>historically a bit guilty of is the separation in terms of jars. We
>>desire this because we want to hide implementation. Following of from
>>Peter's K/CAPI/HC trinity of classloaders, where Hosted comps (HC) only
>>see the Client API (CAPI), the Kernel (K) may have chosen to hide the
>>impl of the CAPI in a different clas loader, not just by dyanmic proxy.
>>The K/CAPI/HC trinity will be repeated many times over in the most
>>complex cases (Phoenix hosting JAMES, FtpServer, Jesktop, EOB). It would
>>be good if we could really start promoting this. At least I am getting
>>sick of explaining it to the people I meet on the net when they have
>>something that is almost a good candidate for an example for EOB. One
>>case wherewe have it wrong is I think cornerstone.jar, it contains
>>interface and impl and will probably be left as is for historical reasons.
>>
>
>I think we should just start discussing about separation of implementation
>and the interface/contract. Dont worry about describing classloader/jar
>issues just yet.
>
>The main reason I do it is because;
>
>1. it forces you to decouple different modules/components/objects
>2. if specified correctly allows you to easily change the implementation of
>the interface/contract in the future.
>3. makes it possible for a user to read documentation about interface without
>having the implementation details clutter up their perception
>
>if you are building objects with the aim of reuse then [2] is important but
>most people don't build for reuse (and most XP advocates say you should just
>plan to use not reuse) and thus [1] and [2] are more important. If you feel
>like documenting that and expanding this then feel free to.
>
>Tackling the separation of ClassLoaders/jars is a related but different
>issue. It could be documented but I think it may be best to tackle this
>second and put it in a a different document. This is mainly because many
>applications do not require that level of separation.
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Website docs
Posted by Peter Donald <pe...@apache.org>.
Hi,
Looks nicer.
On Sun, 31 Mar 2002 02:17, Paul Hammant wrote:
> Page http://jakarta.apache.org/avalon/framework/index.html
> -------------------------------------------------------------
>
> 1) "Target Audience"
>
> Is now : This documentation is aimed towards developers who are
> interested in the design principles of Avalon, or wish to develop code
> that will be incorporated into Avalon
>
> Should be : This documentation is aimed towards developers who are
> interested in the design principles of Avalon, or wish to develop code
> that will be incorporated into Avalon, or reuse Avalon concepts in their
> own application.
Okay - also delete the second paragraph in introduction as it is no longer
relevent.
> 2) "Theoretical Aspects of Component Development"
>
> I'd like to add a new pattern that we already informally treat
> reverently. It is "Interface/Impl seperation". People understand it but
> do not really apply it, of it is mucked up. Catalina, for example, is
> supposed to be interface/impl separated but is (or was last time I was
> active in their mail list) not. The other thing that wven we are
> historically a bit guilty of is the separation in terms of jars. We
> desire this because we want to hide implementation. Following of from
> Peter's K/CAPI/HC trinity of classloaders, where Hosted comps (HC) only
> see the Client API (CAPI), the Kernel (K) may have chosen to hide the
> impl of the CAPI in a different clas loader, not just by dyanmic proxy.
> The K/CAPI/HC trinity will be repeated many times over in the most
> complex cases (Phoenix hosting JAMES, FtpServer, Jesktop, EOB). It would
> be good if we could really start promoting this. At least I am getting
> sick of explaining it to the people I meet on the net when they have
> something that is almost a good candidate for an example for EOB. One
> case wherewe have it wrong is I think cornerstone.jar, it contains
> interface and impl and will probably be left as is for historical reasons.
I think we should just start discussing about separation of implementation
and the interface/contract. Dont worry about describing classloader/jar
issues just yet.
The main reason I do it is because;
1. it forces you to decouple different modules/components/objects
2. if specified correctly allows you to easily change the implementation of
the interface/contract in the future.
3. makes it possible for a user to read documentation about interface without
having the implementation details clutter up their perception
if you are building objects with the aim of reuse then [2] is important but
most people don't build for reuse (and most XP advocates say you should just
plan to use not reuse) and thus [1] and [2] are more important. If you feel
like documenting that and expanding this then feel free to.
Tackling the separation of ClassLoaders/jars is a related but different
issue. It could be documented but I think it may be best to tackle this
second and put it in a a different document. This is mainly because many
applications do not require that level of separation.
--
Cheers,
Pete
"Well you can put lipstick on a hog and call it 'Monique', but it's
still a pig." -- Texas Gov. Ann Richards
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>