You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Leo Simons <ma...@leosimons.com> on 2001/08/21 23:01:48 UTC
Relationships between Jakarta projects...
...aren't well-defined at all. Methinks.
Here is how it could be:
/---------------------\
| Client Application | runs within Velocity/Turbine/Tomcat/JVM, uses all
|---------------------|
| Velocity | runs within Tomcat, uses Turbine/Tomcat/toolkits
|---------------------|
| Turbine | runs within Tomcat, uses Tomcat/Avalon/toolkits
|---------------------|
| Tomcat | runs within Avalon Phoenix, uses Avalon
Phoenix/toolkits
|---------------------|
| Avalon Phoenix | runs on top of rest of Avalon, uses toolkits
|---------------------|
| Avalon Framework / |
| Excalibur / |
| Cornerstone / |
| LogKit | uses toolkits
|---------------------|
| Toolkits: |
| Jakarta-utils / |
| Log4J / |
| Jakarta Commons /|
| Jakarta ORO / |
| Jakarta JMX / |
| XML Xalan |
\---------------------/
Avalon is the lowest-level Java project
at Jakarta. It provides things other
server apps need, like pooling, connections,
logging, etc.
Tomcat is a low level server application
that serves as a bridging facilitator
between Java and internet technologies
such as HTTP, WML, XML, etc. It does so
using 2 java standards: servlets (yay!)
and JSP (messy).
Turbine is a framework to make it easier
to bridge enterprise applications and
internet technologies. It runs within
Tomcat as a servlet, where tomcat creates
half of that bridge (the HTTP/XML side).
Velocity is a templating engine that can
run withing Turbine.
The Client application uses all these
different toolkits, frameworks and engines
to create his internet portal, enterprise
application, etc.
---------------------------------------------
Part of this is already true. But there is a
large duplication of code and effort across
the various projects.
There are three server frameworks (Avalon,
Tomcat, Turbine), they have three pooling
systems, two application expansion systems
(catalina and camelot).
They all provide services. Avalon does
deployment, so does tomcat. Turbine, Avalon
and tomcat all do logging using one of the
two toolkits.
Just by looking at class names and pattern
descriptions, this is obvious.
More concrete: doing a search across apache
sources for "Service.java" gives 6 results.
---------------------------------------------
I've stated a lot of the obvious here, left
things (hey, where's cocoon? or james? or
Xalan?) out of the picture. If you forget that,
you'll probably agree. Right?
Now the question is: do we wish to remove
all that duplication of efforts, create a
logical "separation of concerns" between
projects?
Probably: yes.
I was just wondering how we're going to do
that.
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Relationships between Jakarta projects...
Posted by Peter Donald <do...@apache.org>.
On Wed, 22 Aug 2001 16:55, Leo Simons wrote:
> > Most developers are arrogant and stubbon.
>
> <snip>
>
> > Now the above statement can be seen as both a good thing and a
> > bad thing.
>
> Really? In any case,
> "Most developers are _not_ arrogant or stubborn" sounds
> better to me than "Most developers are arrogant or stubborn".
> But that might just be me =)
Well if you replace "arrogant" with "confident" and "stubbon" with
"determined" you may get what I mean ;)
"stubbon" vs "determined" (or "focused" or "persistent") are perceptions
determined by viewer and not something inherent in actions. When this feature
is deemed a good attribute it is termed "determined" but someone who is less
pleased by attribute in specific circumstances would label it as "stubbon".
ack .. now I am sounding like a psych student again ;)
--
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 *
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Relationships between Jakarta projects...
Posted by Peter Donald <do...@apache.org>.
On Wed, 22 Aug 2001 16:55, Leo Simons wrote:
> > Most developers are arrogant and stubbon.
>
> <snip>
>
> > Now the above statement can be seen as both a good thing and a
> > bad thing.
>
> Really? In any case,
> "Most developers are _not_ arrogant or stubborn" sounds
> better to me than "Most developers are arrogant or stubborn".
> But that might just be me =)
Well .. actually I agree. It just doesn't tend to work in opensource
projects. I would love to go through remove all code-ownership, make flat CVS
permissions and generally institute ego-less programming everywhere. Thats
how buisnesses (or at least good ones) work and is relatively effective.
Everyone works to make themselves redundent (thus increasing their value) and
decisions are based on merit etc.
However this does not build a community ;( The reason being that in OSS code
ownership increases pride and sense of belonging. Also OSS participants are
rarely working towards identical goals and rarely willing to defer to others.
Most work on problems they need fixed or on things they find interesting etc.
> The key is in standardising the things that can be standardised at
> no cost to the maximum extend possible. I think the build systems are
> one area where things are improving. I can simply install and configure
> ant with all modules you can think of, download all that's in Jakarta
> CVS, do a search for all build.bat files, double click those, go drink
> some coffee, come back, and have lots of cool software.
>
> It's nice to have universal build systems. Fortunately, it is not a lot
> of work to do it once you convince people we should make them universal.
>
> Something else is the variety of coding conventions.
Some of the variance is needed/wanted. Some build systems have to do odd
things while others are arbitrary decisions (ie intermediate output dir
name). For instance in code conventions my personal aims are
1. maximize safety/typing/compile-time checks
2. maximize information transferal/understanding
3. minimize variance over time
Many other people don't consider some (or all) of those points as important
and they may add something like "shortness of code length". Thus it is
natural that variance exists. However even then there is arbitrary decisions
about implementations of those aims. ie do you mark scope like
_myVar, _myStaticVar, MY_CONST
m_myVar, c_myStaticVar, MY_CONST
fMyVar, gMyStaticVar, MY_CONST/kMyConst
which should be eliminated.
> But a lot more important than those, imho, is the variety of design
> patterns in use for different things. It's clear that somewhere, someone
> figured out that it'd be useful to follow aforementioned
> Kernel-App-Component structure. This insight was not put to use in
> other projects (or even heard of) because it was not communicated
> as well as it should have been.
Well .. I am not so sure about that. There is plenty of research on most of
the concepts. Dare I say it, most of Avalon Framework is not original but
rehashes of ideas dating back a long time. Hell - most of the concepts,
predate computers and are near identical to concepts "discovered" in 1200's
when architects stopped being "artists" and started being "engineers" ;)
I agree - the problem is one of communication. The GoF book "Design Patterns"
was labeled as revolutionary (and it is/was for computer technicians) and is
one way to share the designs. I guess we could do similar ... now thats
actually a good idea. A Repository of pattern ideas .... hmmmm ... I like.
Kinda like the ACE project but OSS rather than academic .... definetly kool
idea.
--
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 *
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: Relationships between Jakarta projects...
Posted by Leo Simons <ma...@leosimons.com>.
> > Part of this is already true. But there is a
> > large duplication of code and effort across
> > the various projects.
>
> yep - in many cases, the evolution of systems also follows a very
> specific
> path.
<snip>
> I find these sorts of trends fairly interesting ...
uhuh.
> > Now the question is: do we wish to remove
> > all that duplication of efforts, create a
> > logical "separation of concerns" between
> > projects?
> >
> > Probably: yes.
> >
> > I was just wondering how we're going to do
> > that.
>
> The problem is not code but people.
if you replace "code" with "X", in the world of
computers, that's always valid. People write the
code, no?
> Most developers are arrogant and stubbon.
<snip>
> Now the above statement can be seen as both a good thing and a
> bad thing.
Really? In any case,
"Most developers are _not_ arrogant or stubborn" sounds
better to me than "Most developers are arrogant or stubborn".
But that might just be me =)
> If
> you look back through the archives it describes some of the things I did
> quite well ;) While I think in most cases, X was a good thing,
> there is also
> some mistakes I made (arrogance blinded me at the time).
X might be good, but in a world of people, not presenting it
with arrogance and stubbornness is just as important. Methinks.
> however there is also a very bad side-effect of that. Sometimes
> some people
> will not bother to evaluate anything based on technical merits
> (ie how good
> is it, how widespread is it, how likely to be supported into future etc).
> They instead base it on semi-religious beliefs, moral arguements
> and other
> trite. Ironically they are also the same people who slam GNU ...
> kettle ...
> black ... pot ... black ...
no comment ;)
> There is also a fairly big anti-standards here. Sometimes this is good
> because we get fab tools out of it (ie Velocity) but othertimes
> it is less
> than good. Even now we have esssentially 3 different build-system
> styles at
> jakarta, some differences are needed while others are just there
> to satisfy
> egos.
The key is in standardising the things that can be standardised at
no cost to the maximum extend possible. I think the build systems are
one area where things are improving. I can simply install and configure
ant with all modules you can think of, download all that's in Jakarta
CVS, do a search for all build.bat files, double click those, go drink
some coffee, come back, and have lots of cool software.
It's nice to have universal build systems. Fortunately, it is not a lot
of work to do it once you convince people we should make them universal.
Something else is the variety of coding conventions.
But a lot more important than those, imho, is the variety of design
patterns in use for different things. It's clear that somewhere, someone
figured out that it'd be useful to follow aforementioned
Kernel-App-Component structure. This insight was not put to use in
other projects (or even heard of) because it was not communicated
as well as it should have been.
> Anyways I would love to see Avalon Framework + parts of Excalibur more
> universal but I guess I have been burned a few times trying to
> get universal
> acceptance of anything .. let alone something as controvertial as a
> framework. Especially considering most developers seem to disdain
> security,
> reusability or any quality control.
I suspect there are many like you who've tried and given up, frustrated
by the failed attempt. Keyword again is communication.
> Changing developers is as
> easy as herding
> cats.
But I suspect there are many developers that actually want the tighter
relationships I'm talking about. Haven't heard anyone state the
contrary...
> Sam Ruby has been the only person inside apache to get this sort of
> cooperation ... not sure how we could do it. I plan to just use
> stuff in my
> own projects. If others use it then great, if they choose not to
> use it then
> thats fine aswell.
And back we are at the ESR vs RMS debate =)
yupyup. I'm gonna do more thinking.
grz,
- Leo, late for work(tm)
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Relationships between Jakarta projects...
Posted by Peter Donald <do...@apache.org>.
On Wed, 22 Aug 2001 07:01, Leo Simons wrote:
> ...aren't well-defined at all. Methinks.
nope.
> ---------------------------------------------
> Part of this is already true. But there is a
> large duplication of code and effort across
> the various projects.
>
> There are three server frameworks (Avalon,
> Tomcat, Turbine), they have three pooling
> systems, two application expansion systems
> (catalina and camelot).
> They all provide services. Avalon does
> deployment, so does tomcat. Turbine, Avalon
> and tomcat all do logging using one of the
> two toolkits.
>
> Just by looking at class names and pattern
> descriptions, this is obvious.
>
> More concrete: doing a search across apache
> sources for "Service.java" gives 6 results.
> ---------------------------------------------
yep - in many cases, the evolution of systems also follows a very specific
path. Initially everything is available via static methods and has flat
architecture and much of config info is flat.
Slowly over time the system will evolve to allow multiple instances per JVM
(ie don't rely on static access so much) and layered approach. TC4 and
Phoenix are 3-layer systems (Kernel-App-component) while turbine is still two
layer system (App-component).
There is also remarkable similarities in evolution of other aspects
(container-component contracts, config formats, lifecycle management,
services architecture etc). This is not restricted to Apache though and
similar evolutions can be seen in OpenEJB and jBoss. You will note that in
almost all cases the "top" layer (ie kernel) is configured by flat properties
while lower layers (if any) are almost always configured via hierarchial
config (like XML).
I find these sorts of trends fairly interesting ...
> Now the question is: do we wish to remove
> all that duplication of efforts, create a
> logical "separation of concerns" between
> projects?
>
> Probably: yes.
>
> I was just wondering how we're going to do
> that.
The problem is not code but people.
Most developers are arrogant and stubbon. If they "discover" X they often
think they are first to know about it and everyone who doesn't use X is
foolish. Some even go as far as to force their vision on others. However it
is very rare that X is anything new and forcing their vision can sometimes be
bad.
Now the above statement can be seen as both a good thing and a bad thing. If
you look back through the archives it describes some of the things I did
quite well ;) While I think in most cases, X was a good thing, there is also
some mistakes I made (arrogance blinded me at the time).
however there is also a very bad side-effect of that. Sometimes some people
will not bother to evaluate anything based on technical merits (ie how good
is it, how widespread is it, how likely to be supported into future etc).
They instead base it on semi-religious beliefs, moral arguements and other
trite. Ironically they are also the same people who slam GNU ... kettle ...
black ... pot ... black ...
There is also a fairly big anti-standards here. Sometimes this is good
because we get fab tools out of it (ie Velocity) but othertimes it is less
than good. Even now we have esssentially 3 different build-system styles at
jakarta, some differences are needed while others are just there to satisfy
egos.
Anyways I would love to see Avalon Framework + parts of Excalibur more
universal but I guess I have been burned a few times trying to get universal
acceptance of anything .. let alone something as controvertial as a
framework. Especially considering most developers seem to disdain security,
reusability or any quality control. Changing developers is as easy as herding
cats.
Sam Ruby has been the only person inside apache to get this sort of
cooperation ... not sure how we could do it. I plan to just use stuff in my
own projects. If others use it then great, if they choose not to use it then
thats fine aswell.
--
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 *
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Relationships between Jakarta projects...
Posted by Peter Donald <do...@apache.org>.
On Wed, 22 Aug 2001 19:56, Paul Hammant wrote:
> >What I also don't see happening (or is there some mailing list I
> >don't know of) is regular communication between programmers on
> >different projects.
>
> This is a *very* good point.
sounds like general@jakarta.apache.org. As a matter of fact thats exactly how
library-dev mailing list and then later commons-dev evolved.
--
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 *
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Relationships between Jakarta projects...
Posted by Paul Hammant <Pa...@yahoo.com>.
>
>
>What I also don't see happening (or is there some mailing list I
>don't know of) is regular communication between programmers on
>different projects.
>
This is a *very* good point.
>In my experience, doing things like this, on a voluntary basis,
>first requires some community feel. If there is no-one who sees
>Jakarta as a community place, there is no-one wo wants to put
>all that extra effort in to make things work together.
>
Maybe we need a mail list for people interested in Jakarta (or Even all
Java @ Apache ) strategy. A get to know you please for _at least_ the
committers.
[ Interest in simple HTTP server for Avalon. ]
Perhaps we should begin shortlisting candidates for porting. Maybe also
we should reach out and suggest porting to "owners" of suitable server
applications.
Here's a list :
* Pico Server (no longer available at Jakarta)
* Tomcat
* Jetty (http://jetty.mortbay.com/) / Artisitic License
* Jo (http://www.tagtraum.com/) / clone of W3C license
* MinML-RPC (http://www.wilson.co.uk/xml/minmlrpc.htm) BSD license
I've not listed any that use license that forbid interoperation with
Apache license.
Regards,
- Paul H
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: Relationships between Jakarta projects...
Posted by Giacomo Pati <gi...@apache.org>.
Quoting Leo Simons <ma...@leosimons.com>:
> > On Wed, 22 Aug 2001 09:02, Paul Hammant wrote:
> > > >And this is probably the hardest part of it.
>
> yup. Which doesn't mean we shouldn't try =)
>
> > > > Since we are all
> > individuls
> > > >here doing things on a voluntary basis and have our very own
> > preferences
> > > >(babies) this we almost never happen. If Apache would run
> "commercial"
> > > >procedure we clearly had less overlay between the projects and
> > some guys
> > > >from the IT architecture department will tell the other guys in the
> > > >development department what they had to use for their apps. And the
> > > >management clearly knows that human resources are the most
> > costly factor
> > > >in the IT departments! This is what Apache doesn't have to pay for
> and
> > > >thus have to allow much more individuality for every one of us.
> > >
> > > True, but other teams could <b>decide</b> that Avalon is good enough
> to
> > > be a foundation at some point. I think it all starts with Tomcat.
> If
> > > we ported a simple HTTP server (resurrect PicoServer) to Avalon,
> then
> > > the Tomcat team might like what they see and make plans themselves.
>
> What I also don't see happening (or is there some mailing list I
> don't know of) is regular communication between programmers on
> different projects.
>
> In my experience, doing things like this, on a voluntary basis,
> first requires some community feel. If there is no-one who sees
> Jakarta as a community place, there is no-one wo wants to put
> all that extra effort in to make things work together.
>
> > It will be a while before TC5 comes around (could be years off).
> > Before we
> > even approach them there are still things that needs to be done
> > to phoenix to
> > make it "worthy". A while back phoenix became "acceptable" for my
> > uses (ie it
> > does everything I need at this stage) and thus development slowed
> > a little.
> > It will eventually get to killer-app status I hope .. just takes time.
>
> Hopefully, this will be before development of Tomcat 5 starts.
> If it's not, well, it would be useful to talk to the tomcat
> developer team about them helping out porting utility code from
> tomcat to Phoenix, or them specifying what they would like
> different in phoenix.
> Just an example, but the point is clear: communication and team
> spirit are a first requirment.
Just a FYI. Grepping the catalina tree in the tomcat-4 repo for 'avalon'
will shows you the file catalina/src/conf/catalina.conf.xml containing:
<avalon>
<block class="org.apache.catalina.startup.CatalinaBlock"
name="catalina" >
<logger name="Servlet container"
destinationURL="../logs/catalina.log"
priority="DEBUG"/>
<configuration>
<path>../../tomcat-4.0</path>
</configuration>
</block>
</avalon>
Remi already thought of starting something sometimes. From the CVS I've got
- Add a wrapper to enable management of Tomcat 4 by Avalon.
- Use the new "dist-opt-avalon" target in the Catalina build file to build the
Avalon block. This is NOT part of the "dist" target because of limitations
in the current Ant (the problem seems to be that this build file is actually
used from the main Tomcat build file; any help to resolve this would be
appreciated).
This target assumes that Avalon is in ../../dist/avalon. There is an
avalon.dist property which can be used to point to another location.
- The Avalon block (catalina.bar) contains a configuration file which has
a path element which must point to the Tomcat 4 distribution. If Avalon is
in the directory mentioned above, then the defaults are fine.
- The wrapper has been successfully tested with Avalon 3.0a3.
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: Relationships between Jakarta projects...
Posted by Leo Simons <ma...@leosimons.com>.
> On Wed, 22 Aug 2001 09:02, Paul Hammant wrote:
> > >And this is probably the hardest part of it.
yup. Which doesn't mean we shouldn't try =)
> > > Since we are all
> individuls
> > >here doing things on a voluntary basis and have our very own
> preferences
> > >(babies) this we almost never happen. If Apache would run "commercial"
> > >procedure we clearly had less overlay between the projects and
> some guys
> > >from the IT architecture department will tell the other guys in the
> > >development department what they had to use for their apps. And the
> > >management clearly knows that human resources are the most
> costly factor
> > >in the IT departments! This is what Apache doesn't have to pay for and
> > >thus have to allow much more individuality for every one of us.
> >
> > True, but other teams could <b>decide</b> that Avalon is good enough to
> > be a foundation at some point. I think it all starts with Tomcat. If
> > we ported a simple HTTP server (resurrect PicoServer) to Avalon, then
> > the Tomcat team might like what they see and make plans themselves.
What I also don't see happening (or is there some mailing list I
don't know of) is regular communication between programmers on
different projects.
In my experience, doing things like this, on a voluntary basis,
first requires some community feel. If there is no-one who sees
Jakarta as a community place, there is no-one wo wants to put
all that extra effort in to make things work together.
> It will be a while before TC5 comes around (could be years off).
> Before we
> even approach them there are still things that needs to be done
> to phoenix to
> make it "worthy". A while back phoenix became "acceptable" for my
> uses (ie it
> does everything I need at this stage) and thus development slowed
> a little.
> It will eventually get to killer-app status I hope .. just takes time.
Hopefully, this will be before development of Tomcat 5 starts.
If it's not, well, it would be useful to talk to the tomcat
developer team about them helping out porting utility code from
tomcat to Phoenix, or them specifying what they would like
different in phoenix.
Just an example, but the point is clear: communication and team
spirit are a first requirment.
> > Voluntary basis is the key.
>
> agreed.
'course =)
grz,
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Relationships between Jakarta projects...
Posted by Peter Donald <do...@apache.org>.
On Wed, 22 Aug 2001 09:02, Paul Hammant wrote:
> >And this is probably the hardest part of it. Since we are all individuls
> >here doing things on a voluntary basis and have our very own preferences
> >(babies) this we almost never happen. If Apache would run "commercial"
> >procedure we clearly had less overlay between the projects and some guys
> >from the IT architecture department will tell the other guys in the
> >development department what they had to use for their apps. And the
> >management clearly knows that human resources are the most costly factor
> >in the IT departments! This is what Apache doesn't have to pay for and
> >thus have to allow much more individuality for every one of us.
>
> True, but other teams could <b>decide</b> that Avalon is good enough to
> be a foundation at some point. I think it all starts with Tomcat. If
> we ported a simple HTTP server (resurrect PicoServer) to Avalon, then
> the Tomcat team might like what they see and make plans themselves.
It will be a while before TC5 comes around (could be years off). Before we
even approach them there are still things that needs to be done to phoenix to
make it "worthy". A while back phoenix became "acceptable" for my uses (ie it
does everything I need at this stage) and thus development slowed a little.
It will eventually get to killer-app status I hope .. just takes time.
> Voluntary basis is the key.
agreed.
> They're all doing other Apache projects,
> we're doing Avalon (plus in many cases proprietory blocks based on
> it)... it's the same for us. A sort of critical mass pattern.
--
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 *
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Relationships between Jakarta projects...
Posted by Peter Donald <do...@apache.org>.
On Wed, 22 Aug 2001 12:05, Oki DZ wrote:
> >I think it all starts with Tomcat. If
> > we ported a simple HTTP server (resurrect PicoServer) to Avalon, then
> > the Tomcat team might like what they see and make plans themselves.
>
> It seems that the World needs a "Kitten" web server. Sure, Tomcat would
> fulfill all your web server feature needs, but I believe that there are
> people who'd like to have something more lighter. Say, in Java
> Programming 101 course, students can implement a db based security module
> for the lightweight web server.
I know quite a few people who want/need a small embedded HTTP server ... that
would be a good idea.
--
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 *
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Relationships between Jakarta projects...
Posted by Oki DZ <ok...@pindad.com>.
On Tue, 21 Aug 2001, Paul Hammant wrote:
> True, but other teams could <b>decide</b> that Avalon is good enough to
> be a foundation at some point.
I thing letting them know that Avalon is ready for prime time would be
needed.
Besides, duplication makes newbies having a hard time (ie: deciding which
one to use). Eg: Excalibur has db pooling, so does Turbine.
>I think it all starts with Tomcat. If
> we ported a simple HTTP server (resurrect PicoServer) to Avalon, then
> the Tomcat team might like what they see and make plans themselves.
It seems that the World needs a "Kitten" web server. Sure, Tomcat would
fulfill all your web server feature needs, but I believe that there are
people who'd like to have something more lighter. Say, in Java
Programming 101 course, students can implement a db based security module
for the lightweight web server.
Oki
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Relationships between Jakarta projects...
Posted by Paul Hammant <Pa...@yahoo.com>.
>
>
>
>And this is probably the hardest part of it. Since we are all individuls
>here doing things on a voluntary basis and have our very own preferences
>(babies) this we almost never happen. If Apache would run "commercial"
>procedure we clearly had less overlay between the projects and some guys
>from the IT architecture department will tell the other guys in the
>development department what they had to use for their apps. And the
>management clearly knows that human resources are the most costly factor
>in the IT departments! This is what Apache doesn't have to pay for and
>thus have to allow much more individuality for every one of us.
>
True, but other teams could <b>decide</b> that Avalon is good enough to
be a foundation at some point. I think it all starts with Tomcat. If
we ported a simple HTTP server (resurrect PicoServer) to Avalon, then
the Tomcat team might like what they see and make plans themselves.
Voluntary basis is the key. They're all doing other Apache projects,
we're doing Avalon (plus in many cases proprietory blocks based on
it)... it's the same for us. A sort of critical mass pattern.
- PH
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Relationships between Jakarta projects...
Posted by giacomo <gi...@apache.org>.
On Tue, 21 Aug 2001, Leo Simons wrote:
> ...aren't well-defined at all. Methinks.
>
> Here is how it could be:
>
> /---------------------\
> | Client Application | runs within Velocity/Turbine/Tomcat/JVM, uses all
> |---------------------|
> | Velocity | runs within Tomcat, uses Turbine/Tomcat/toolkits
> |---------------------|
> | Turbine | runs within Tomcat, uses Tomcat/Avalon/toolkits
> |---------------------|
> | Tomcat | runs within Avalon Phoenix, uses Avalon
> Phoenix/toolkits
> |---------------------|
> | Avalon Phoenix | runs on top of rest of Avalon, uses toolkits
> |---------------------|
> | Avalon Framework / |
> | Excalibur / |
> | Cornerstone / |
> | LogKit | uses toolkits
> |---------------------|
> | Toolkits: |
> | Jakarta-utils / |
> | Log4J / |
> | Jakarta Commons /|
> | Jakarta ORO / |
> | Jakarta JMX / |
> | XML Xalan |
> \---------------------/
>
> Avalon is the lowest-level Java project
> at Jakarta. It provides things other
> server apps need, like pooling, connections,
> logging, etc.
>
> Tomcat is a low level server application
> that serves as a bridging facilitator
> between Java and internet technologies
> such as HTTP, WML, XML, etc. It does so
> using 2 java standards: servlets (yay!)
> and JSP (messy).
>
> Turbine is a framework to make it easier
> to bridge enterprise applications and
> internet technologies. It runs within
> Tomcat as a servlet, where tomcat creates
> half of that bridge (the HTTP/XML side).
>
> Velocity is a templating engine that can
> run withing Turbine.
>
> The Client application uses all these
> different toolkits, frameworks and engines
> to create his internet portal, enterprise
> application, etc.
>
>
> ---------------------------------------------
> Part of this is already true. But there is a
> large duplication of code and effort across
> the various projects.
>
> There are three server frameworks (Avalon,
> Tomcat, Turbine), they have three pooling
> systems, two application expansion systems
> (catalina and camelot).
> They all provide services. Avalon does
> deployment, so does tomcat. Turbine, Avalon
> and tomcat all do logging using one of the
> two toolkits.
>
> Just by looking at class names and pattern
> descriptions, this is obvious.
>
> More concrete: doing a search across apache
> sources for "Service.java" gives 6 results.
> ---------------------------------------------
>
> I've stated a lot of the obvious here, left
> things (hey, where's cocoon? or james? or
> Xalan?) out of the picture. If you forget that,
> you'll probably agree. Right?
>
> Now the question is: do we wish to remove
> all that duplication of efforts, create a
> logical "separation of concerns" between
> projects?
>
> Probably: yes.
>
> I was just wondering how we're going to do
> that.
And this is probably the hardest part of it. Since we are all individuls
here doing things on a voluntary basis and have our very own preferences
(babies) this we almost never happen. If Apache would run "commercial"
procedure we clearly had less overlay between the projects and some guys
from the IT architecture department will tell the other guys in the
development department what they had to use for their apps. And the
management clearly knows that human resources are the most costly factor
in the IT departments! This is what Apache doesn't have to pay for and
thus have to allow much more individuality for every one of us.
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org