Re: What is Struts? (was: Re: What is Avalon?)

[James Duncan Davidson]

on 2/11/01 2:47 AM, Jim Driscoll at [EMAIL PROTECTED] wrote:

> Fixing the license part is hard.  Fixing the community part is now
> Duncan's job.  Go, Duncan!

Actually seeing if I can fix it is part of my job. :) Subtle but important.
If I actually *owned* that issue inside of Sun, it would already be done. :)

.duncan

-- 
James Duncan Davidson
http://x180.net/ !try; do();


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: What is Struts? (was: Re: What is Avalon?)

[Peter Donald]

How very amusing.

At 11:06  10/2/01 -0800, Jim Driscoll wrote:
>The internet, where everyone's an expert. 

yes - the biggest people of course are those who wear skippy badges and
loudly claim their excellence. Yes there are lots of experts.

>Stop assuming things without checking facts.

right ... just like you - huh ?

>> 4. Implementing select() is not difficult considering it is part of POSIX
>> and implemented on all platforms that I am aware of (except small ones
>> which use a different platform - J2ME).
>
>This is not entirely true.  If it was trivial, someone would have
>cranked it out over a weekend.  Heck, you've got the source code (in
>SCSL) - why don't YOU do it.

Well - do I look like an idiot? No one in their right mind would ever
contribute code under SCSL if it is the same one from a while back. Why do
you think that all the free JVM/class library projects will not accept code
from people who have looked at code under SCSL? I have heard people
complain about the GPL "taint" - well the SCSL taint is by far a more
sinister variety - it is a taint on IP of product. You effectively give up
the possibility of many of your ideas by signing that obstrocity.

Thankfully I have been hearing murmurings that there is to be a new GNU
jihad against ths SCSL soon ... not sure if it is true but it would follow
as since an incident with another free software java group (jBoss) I have
heard that the "gurus" are now having a closer look at java. We can only
hope it will get Sun to change to a less evil license or even a nice one ;)

>> 6. Without select it is impossible to write scalable server apps that deal
>> with sparsly transmitted upon connections except in hardware that have fine
>> grain locking + many CPUs
>
>Not true.  With clever use of threads, it's been possible to write at
>least one webserver which exceeded the performance of Apache using
>standard benchmarks on SMP machines (both NT and Solaris, Linux threads
>were crap back then, and the implementation wasn't up to it), as well as
>a proxy server which was speed-competitive with Squid.

Yay - a Straw Man arguement. 

Question: What does a webserver have to do with "sparsly transmitted upon
connections"?
Answer: Nothing

Great reasoning you got there.

>All of which sounds pretty competitive to me.  Where are you getting
>*your* data?

I developed a prototype IM server similar to jabber in java. It wasn't
until later that I realized the theoretical limitations. Naturally we were
forced back to native code (namely c).

>> 8. Given the above - Sun obviously believes networking is important, server
>> products are a forte of java and have little cost or risk implementing
>> select().
>
>Demonstrated false 

You are not very good at logic are you. "Demonstrated false" is a false
statement ;)

>My conclusion is that it's more convenient for you to engage in
>conspiracy theory than actually ask the engineers involved, or look at
>the codebase, or think.

My conclusion is that you are too close to the subject material to think
rationally - and I guess that has been adequetely established, no?

>But really, as I said, if you can write even a
>halfway decent threadpool, it's not so necessary to have select.

When you make claims like this - how do you expect us to believe you are an
authority? Whats the saying - "It's better to stay silent and let people
think you are stupid than open your mouth and prove it".

>It'd be far more yeild for high performance servers to have a bug-free
>VM, better performance in multithreaded envirnments, security that
>actually works, DNS lookups that do smart caching 

Add in keywords "service", "xml" and "distributed" and you will graduate
from the MS school of FUD.

Seriously if you think that Sun is whistle clean then feel free to say so.
However your reply was made up of
1. Personal insults
2. You displaying your ignorance
3. A strawman argument
4. FUD

If you want to convince us then try to make your argument cogent or at
least try to back it up with facts for without this you are just a
sophisticated troll. Recomended steps for anybody listening to you

After reading message
1. Take a deep breath
2. Re-read the message
3. think about message
4. reply

It is amazing how many people skip 1-3 ...



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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: What is Struts? (was: Re: What is Avalon?)

[Jon Stevens]

on 2/11/01 2:47 AM, "Jim Driscoll" <[EMAIL PROTECTED]> wrote:

> And contribs didn't fall into a black hole, which is way more important
> than the license.

Yup.

> That probably had way more to do with tying to the Apache brand than the
> OS nature of the licensing terms.  If Sun'd released Tomcat under some
> open source license without tying to Apache, things might have turned
> out quite different.

Hmmm...I don't know about that. Personally speaking, I would have
contributed to Tomcat if it had been held under a BSD'ish license no matter
where it lived...

My criteria are:

#1. Easy access to CVS.
#2. Good mailing lists.
#3. Ability to contribute easily.

Back in Sept 1997, I originally forked JServ over to working-dogs.com
because none of the above was true.

> License != community.  As I'm sure you're in a good position to know :-)

Actually, I disagree. I don't care about how good the GNU community is. I
don't like the license and I don't want to contribute to software under it.

> Fixing the license part is hard.  Fixing the community part is now
> Duncan's job.  Go, Duncan!

Yup.

> Err, select()?  The point of the post was that it was claimed that
> select() should be easy to do - so I asked him to prove it.

Why should he write software for Sun for free? If it is so easy to
implement, then Sun should have the people they pay do it.

Otherwise, release the code under a license and community that is open so
that people who contribute don't feel like they are working for Sun for
free.

:-)

-jon

-- 
If you come from a Perl or PHP background, JSP is a way to take
your pain to new levels. --Anonymous
 && 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: What is Struts? (was: Re: What is Avalon?)

[Jim Driscoll]

Jon Stevens wrote:
> I bet that more people would be willing to contribute to Sun's technologies
> if they were under a better license and were more openly accepted. 

And contribs didn't fall into a black hole, which is way more important
than the license.

> Example:
> look at how many people have contributed to Tomcat.

That probably had way more to do with tying to the Apache brand than the
OS nature of the licensing terms.  If Sun'd released Tomcat under some
open source license without tying to Apache, things might have turned
out quite different.
 
> It just isn't obvious where I sent my patches to Sun source code under SCSL
> because there isn't a community built up around the code. There aren't open
> mailing lists that I can subscribe to. 

License != community.  As I'm sure you're in a good position to know :-)

Fixing the license part is hard.  Fixing the community part is now
Duncan's job.  Go, Duncan!

> There also is no desire to simply
> help Sun write their code for them for free to sell more hardware. What's in
> it for me?

Err, select()?  The point of the post was that it was claimed that
select() should be easy to do - so I asked him to prove it.

Jim

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: What is Struts? (was: Re: What is Avalon?)

[Jon Stevens]

on 2/10/01 11:06 AM, "Jim Driscoll" <[EMAIL PROTECTED]> wrote:

> This is not entirely true.  If it was trivial, someone would have
> cranked it out over a weekend.  Heck, you've got the source code (in
> SCSL) - why don't YOU do it.

I bet that more people would be willing to contribute to Sun's technologies
if they were under a better license and were more openly accepted. Example:
look at how many people have contributed to Tomcat.

It just isn't obvious where I sent my patches to Sun source code under SCSL
because there isn't a community built up around the code. There aren't open
mailing lists that I can subscribe to. There also is no desire to simply
help Sun write their code for them for free to sell more hardware. What's in
it for me?

Oh wait, I could join the JCP and write code for Sun for free.

Not.

:-)

-jon

-- 
If you come from a Perl or PHP background, JSP is a way to take
your pain to new levels. --Anonymous
 && 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Olympics (was: Re: What is Struts? (was: Re: What is Avalon?))

[Jon Stevens]

on 2/10/01 3:51 AM, "Kief Morris" <[EMAIL PROTECTED]> wrote:

>> I am with you on that one, Jon.  I cannot figure out why people would use
>> JSP when they have Servlets.  I think JSP was really just to counter ASP.
> 
> In an engineer's world, the technically superior product would always win,
> while marketing and customer demand would take a back seat to good
> engineering. The success of Microsoft proves this isn't the case.

And the success of Apache is based on what?

Engineers.

Apache HTTPd has placed zero (count that...ZERO) marketing dollars into
building a product, yet it is the most widely used web server on the net by
a landslide.

Apache JServ has won numerous awards and is in several commercial products
(include Oracle's)...again, zero dollars were spent on marketing.

Lets do that with other worthwhile Java technologies as well.

> JSP solves a different kind of problem, which is the need for a tool for
> people with less engineering skills to develop servlets. If JSP didn't
> exist, the Java platform would not be as competitve in the market. It
> may be a dirty hack, but it's a necessary hack.

Again, that isn't true at all. Engineering skills wise, JSP is no better
than Servlets. You still need to know Java in order to write JSP pages.
Look at the examples I recently gave in the article. How many web designers
know how to deal with simple engineer type issues like scope?

> Hopefully people who are drawn to the Java platform by JSP will then learn
> more effective ways to build web applications using servlets, proper
> templating 
> languages, etc. If there was no JSP, those developers would go to Microsoft
> instead. 

A...that is where you are mislead again. It is our job to attempt to get
the word out that there are better solutions than both JSP and M$
technologies. That is where word of mouth and doing articles helps.

> JSP may not be innovative, ground breaking, or technically sublime,
> but the more developers working with Java the better, IMO.

If you have a bunch of bad applications done in JSP, people are going to
think that Java sucks, not that it is good. Why not show developers what a
good tool is right off the bat? Like I said, we have those quality tools
right under our very feet. Lets get everyone using them!

:-)

-jon

-- 
If you come from a Perl or PHP background, JSP is a way to take
your pain to new levels. --Anonymous
 && 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: What is Struts? (was: Re: What is Avalon?)

[Jim Driscoll]

The internet, where everyone's an expert.  And a conspiracy theorist. 
Well, listen up, I was there, and I've been pushing for select() since
1.1, so let me fill you in:

You're full of it. Stop assuming things without checking facts.

There's only been one (1) person working on java.net since James Gosling
wrote the initial version.  First Pavani, then Brown then BR...  I've
lost track some time ago, I don't know the present person's name.  They
usually did double duty in some other area, as well.  Not because Sun
has any grand strategy on starving The Feature You Simply Can't Live
Without, but because java.net is (rightly) considered mostly done, and
other things get priority.

select was pretty much impossible to implement in green threads.  Hell,
blocking IO was a bear under green threads.  Remember green threads? 
Sort of shoots your "it's an afternoon's work" argument in the head,
doesn't it?  Thank God that that's no longer supported, but quite
frankly with the way Linux threads work (or fail to), green threads
could be mighty useful even still.  But then you'd never get your
feature.

More inline:

Peter Donald wrote:
> Let me see - which step did I stuff up.

Everything after step 3.
 
> 1. Sun coined or at least advocates the term "The network is the computer"

Um, ok.

> 2. For a while Java has been billed as great for serverside stuff

It is.

> 3. The longest bug/feature request relating to serverside stuff is lack of
> select()

OK, I'll take that at face value, but I'd be suprised if it was true.

> 4. Implementing select() is not difficult considering it is part of POSIX
> and implemented on all platforms that I am aware of (except small ones
> which use a different platform - J2ME).

This is not entirely true.  If it was trivial, someone would have
cranked it out over a weekend.  Heck, you've got the source code (in
SCSL) - why don't YOU do it.

> 5. select() was implemented by other vendors hence the R&D costs should be
> minimal

Citation, please - I'm not aware of anyone else having implemented a
version of select() which was integrated into a Java VM.

> 6. Without select it is impossible to write scalable server apps that deal
> with sparsly transmitted upon connections except in hardware that have fine
> grain locking + many CPUs

Not true.  With clever use of threads, it's been possible to write at
least one webserver which exceeded the performance of Apache using
standard benchmarks on SMP machines (both NT and Solaris, Linux threads
were crap back then, and the implementation wasn't up to it), as well as
a proxy server which was speed-competitive with Squid.

All of which sounds pretty competitive to me.  Where are you getting
*your* data?

> 7. One of suns greatest revenue streams is selling hardware that has fine
> grain locking and many CPUs

True, but the connection to the rest of the argument is not established.

> 8. Given the above - Sun obviously believes networking is important, server
> products are a forte of java and have little cost or risk implementing
> select().

Demonstrated false - you're assuming little cost here, which has not
been established.

> 9. By virtue of 6 and 7 it would be an unwise buisness decision to
> implement select() as it would reduce demand for their hardware.

Not demonstrated by facts.
 
> Conclusion ?? (it should be obvious).

My conclusion is that it's more convenient for you to engage in
conspiracy theory than actually ask the engineers involved, or look at
the codebase, or think.

> Now which step in reasoning is invalid?

See above.

BTW - I've been out of it for awhile, I'll check and see if Merlin
finally has some of what you're looking for.  (I hear there's a new IO
package in the works).  But really, as I said, if you can write even a
halfway decent threadpool, it's not so necessary to have select.
It'd be far more yeild for high performance servers to have a bug-free
VM, better performance in multithreaded envirnments, security that
actually works, DNS lookups that do smart caching and all the other
things that those engineers actually worked on every time I asked if we
could have select now.

Jim

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Olympics (was: Re: What is Struts? (was: Re: What is Avalon?))

[Kief Morris]

>I am with you on that one, Jon.  I cannot figure out why people would use
>JSP when they have Servlets.  I think JSP was really just to counter ASP.

In an engineer's world, the technically superior product would always win,
while marketing and customer demand would take a back seat to good
engineering. The success of Microsoft proves this isn't the case. 

As Jon says:

>Servlets solve a problem effectively. JSP doesn't.

JSP solves a different kind of problem, which is the need for a tool for
people with less engineering skills to develop servlets. If JSP didn't
exist, the Java platform would not be as competitve in the market. It
may be a dirty hack, but it's a necessary hack. 

Hopefully people who are drawn to the Java platform by JSP will then learn 
more effective ways to build web applications using servlets, proper templating 
languages, etc. If there was no JSP, those developers would go to Microsoft 
instead. 

JSP may not be innovative, ground breaking, or technically sublime,
but the more developers working with Java the better, IMO.

Kief


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Olympics (was: Re: What is Struts? (was: Re: What is Avalon?))

[Micael Padraig Og mac Grene]

I am with you on that one, Jon.  I cannot figure out why people would use
JSP when they have Servlets.  I think JSP was really just to counter ASP.
- Original Message -
From: "Jon Stevens" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, February 10, 2001 1:26 AM
Subject: Re: Olympics (was: Re: What is Struts? (was: Re: What is Avalon?))


> on 2/9/01 10:59 PM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
>
> > Without Sun "pushing" standard technologies, what would Turbine do for a
> > servlet engine base across App Servers?
>
> The same exact thing it has been doing for the last 3+ years now...Sun was
> smart and pushed Servlets.
>
> That doesn't mean that it also got it right with JSP...which in reality is
> not much better than just plain Servlets.
>
> Servlets solve a problem effectively. JSP doesn't.
>
> People need to wake up to that fact.
>
> -jon
>
> --
> If you come from a Perl or PHP background, JSP is a way to take
> your pain to new levels. --Anonymous
> <http://jakarta.apache.org/velocity/> && <http://java.apache.org/turbine/>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Olympics (was: Re: What is Struts? (was: Re: What is Avalon?))

[Jon Stevens]

on 2/9/01 10:59 PM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:

> Without Sun "pushing" standard technologies, what would Turbine do for a
> servlet engine base across App Servers?

The same exact thing it has been doing for the last 3+ years now...Sun was
smart and pushed Servlets.

That doesn't mean that it also got it right with JSP...which in reality is
not much better than just plain Servlets.

Servlets solve a problem effectively. JSP doesn't.

People need to wake up to that fact.

-jon

-- 
If you come from a Perl or PHP background, JSP is a way to take
your pain to new levels. --Anonymous
 && 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Olympics (was: Re: What is Struts? (was: Re: What is Avalon?))

[dion]

on 2/2/01 1:34 AM, "Ceki Gülcü" <[EMAIL PROTECTED]> wrote:

> Sun is doing a great job at convincing people to use their technology. 
This is
> truly a Herculean task and imho constitutes a major achievement for Sun.

Jon Stevens writes:

> Nope. Sun is doing a great job emulating M$. JSP is only better than ASP
> simply because it is Java, not because it is a better design. Is JSP 
better
> than .NET? I don't know yet, but M$ usually doesn't make the same 
mistakes
> with regards to technology decisions twice. Anyone remember that M$ was
> "missing" on the Internet for so long and when Bill woke up, he 
assimilated
> as much Internet related stuff as he could.

Ceki was right, Sun are doing a great job at convincing people to use 
their technology. That may be emulating M$, but it also makes damn good 
business sense. Ceki wasn't saying JSP is better than 
ASP/Turbine/Velocity/WebMacro/? . There's a difference.

Without Sun "pushing" standard technologies, what would Turbine do for a 
servlet engine base across App Servers?

Personally I'm glad Sun are at least sticking to their guns and marketing 
their technology. I too, would like it if they would make it better at the 
same time, and I've provided feedback to the JSR email address for that 
reason.

--
dIon Gillard, Multitask Consulting
Work:  http://www.multitask.com.au
NetRexx: http://www.multitask.com.au/NetRexx.nsf


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: What is Struts? (was: Re: What is Avalon?)

[James Duncan Davidson]

On 2/7/01 2:09 AM, "James Duncan Davidson" <[EMAIL PROTECTED]> wrote:

> Also, I have to note that just because it seems simple to implement doesn¹t
> mean that a simple clean model of exposing it isn't hard to produce.

I should also note that if you've got a good idea on how this should be done
and are tired of waiting around, then work up a JSR and submit it to the
JCP. 

-- 
James Duncan Davidson[EMAIL PROTECTED]
  !try; do()


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: What is Struts? (was: Re: What is Avalon?)

[James Duncan Davidson]

On 2/6/01 5:27 PM, "Peter Donald" <[EMAIL PROTECTED]> wrote:

> It makes good buisness sense to not implement select() and is not the
> result of malice...
> 
> Let me see - which step did I stuff up.
> 
> 1. Sun coined or at least advocates the term "The network is the computer"
> 2. For a while Java has been billed as great for serverside stuff
> 3. The longest bug/feature request relating to serverside stuff is lack of
> select()
> 4. Implementing select() is not difficult considering it is part of POSIX
> and implemented on all platforms that I am aware of (except small ones
> which use a different platform - J2ME).
> 5. select() was implemented by other vendors hence the R&D costs should be
> minimal
> 6. Without select it is impossible to write scalable server apps that deal
> with sparsly transmitted upon connections except in hardware that have fine
> grain locking + many CPUs
> 7. One of suns greatest revenue streams is selling hardware that has fine
> grain locking and many CPUs
> 8. Given the above - Sun obviously believes networking is important, server
> products are a forte of java and have little cost or risk implementing
> select().
> 9. By virtue of 6 and 7 it would be an unwise buisness decision to
> implement select() as it would reduce demand for their hardware.
> 
> Conclusion ?? (it should be obvious).
> 
> Now which step in reasoning is invalid?

Somewhere between 5 and 7.

It's invalid that you'd expect that the engineers that are working through
the bug list have any motivation for selecting bugs to fix based on "high
level business reasons" and that the people that are making the "business
decisions" are looking at the bug list. There's not a chain of command that
goes through each RFE and decides whether or not it makes "business sense"
to fullfill it or not. In fact, only when engineering pushes it up to that
level does it become an issue. Or a major customer/vendor asks for it loudly
enough. Otherwise, the two are separate trains.

Improved I/O has been on the boards for a long time now too, as have been a
lot of other RFEs. These things don't happen quickly in the current system.

Also, I have to note that just because it seems simple to implement doesn¹t
mean that a simple clean model of exposing it isn't hard to produce.

.duncan

-- 
James Duncan Davidson[EMAIL PROTECTED]
  !try; do()


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: What is Struts? (was: Re: What is Avalon?)

[Pier Fumagalli]

Peter Donald <[EMAIL PROTECTED]> wrote:
> 
> Conclusion ?? (it should be obvious).

Conclusion: They pay my salary, and make me happy... If you want a select()
call, it's as easy as 1...2...3... to write it using JNI...

Pier :)


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: What is Struts? (was: Re: What is Avalon?)

[Peter Donald]

At 11:54  6/2/01 -0800, James Duncan Davidson wrote:
>On 2/2/01 12:56 PM, "Peter Donald" <[EMAIL PROTECTED]> wrote:
>
>> Consider the case of select() style functionality - why has not that been
>> added. It's not because it isn't portable, nor is it because it is
technically
>> hard or a design challenge. I put it to you that the sole reason is
because it
>> would mean that low end servers with a small number of CPUs could actually
>> start to compete with the suns network OS hardware which would be a bad
thing
>> for them. Yet not having this functionality has proved considerably
>> challenging to anyone running java as server and in native threads mode. I
>> suspect this will change with Merlin release as more people were allowed to
>> have an opinion.
>
>Oh this is just hilarious. Of course you aren't going to believe me since my
>motives are always so "questionable", but the reason it's not there is
>because the JDK team have been working through their queue of real problems
>in the platform and this hasn't yet burbled to the top of their queue. It's
>not that it's not a real problem, it is, but when you have finite resources
>and need to structure them to get things done, triage results in things
>dropping that are unfortunate.
>
>Now, whether or not the model that is being used is efficient for getting
>work done or an appropriate model is not something that I want to get into a
>discussion on -- but I'm simply pointing out that you are ascribing to
>malice something that isn't the result of malice.

It makes good buisness sense to not implement select() and is not the
result of malice...

Let me see - which step did I stuff up.

1. Sun coined or at least advocates the term "The network is the computer"
2. For a while Java has been billed as great for serverside stuff
3. The longest bug/feature request relating to serverside stuff is lack of
select()
4. Implementing select() is not difficult considering it is part of POSIX
and implemented on all platforms that I am aware of (except small ones
which use a different platform - J2ME).
5. select() was implemented by other vendors hence the R&D costs should be
minimal
6. Without select it is impossible to write scalable server apps that deal
with sparsly transmitted upon connections except in hardware that have fine
grain locking + many CPUs
7. One of suns greatest revenue streams is selling hardware that has fine
grain locking and many CPUs
8. Given the above - Sun obviously believes networking is important, server
products are a forte of java and have little cost or risk implementing
select().
9. By virtue of 6 and 7 it would be an unwise buisness decision to
implement select() as it would reduce demand for their hardware.

Conclusion ?? (it should be obvious).

Now which step in reasoning is invalid? 


Cheers,

Pete

*--*
| "Computers are useless. They can only give you   |
|answers." - Pablo Picasso |
*--*

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: What is Struts? (was: Re: What is Avalon?)

[James Duncan Davidson]

On 2/2/01 12:56 PM, "Peter Donald" <[EMAIL PROTECTED]> wrote:

> Consider the case of select() style functionality - why has not that been
> added. It's not because it isn't portable, nor is it because it is technically
> hard or a design challenge. I put it to you that the sole reason is because it
> would mean that low end servers with a small number of CPUs could actually
> start to compete with the suns network OS hardware which would be a bad thing
> for them. Yet not having this functionality has proved considerably
> challenging to anyone running java as server and in native threads mode. I
> suspect this will change with Merlin release as more people were allowed to
> have an opinion.

Oh this is just hilarious. Of course you aren't going to believe me since my
motives are always so "questionable", but the reason it's not there is
because the JDK team have been working through their queue of real problems
in the platform and this hasn't yet burbled to the top of their queue. It's
not that it's not a real problem, it is, but when you have finite resources
and need to structure them to get things done, triage results in things
dropping that are unfortunate.

Now, whether or not the model that is being used is efficient for getting
work done or an appropriate model is not something that I want to get into a
discussion on -- but I'm simply pointing out that you are ascribing to
malice something that isn't the result of malice.

.duncan

-- 
James Duncan Davidson[EMAIL PROTECTED]
  !try; do()


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: What is Struts? (was: Re: What is Avalon?)

[Federico Barbieri]

Ted Husted wrote:
> 
> > The desire to work together is core to my thesis that there is a
> Jakarta community here.
> 
> There often seems to be an assumption that our resources, or community,
> is limited. There are a great number of Java developers in the world,
> and our numbers grow every day. A project like Struts, with a clear
> internal focus on J2EE compatability can easily attract developers that
> would not otherwise contribute. I happen to be one.
> 
> When considering the merits of a product, it is important to consider
> the human factor of both our users and developers. It's no secret the
> teams working on competiting solutions often "hate each other". Maybe
> that's a good thing. It may not be as efficient, but given the human
> factor, duplicating resources and fostering competition is usually more
> * effective * than "benevolent" cooperation.
> 
> We need more than just science. We need scientists.
> 
> Are we developers looking for projects, or products looking for
> developers?
> 
> Are we building a cathedral, or a bazaar?
> 

just a quick note... a pure bazaar does not scale. period.
 
IMHO if two project share some needs it's probally more a pain than a
gain to enforce code sharing too. But a third new project will probally
benefit and so all following. It's a matter of opening the path in a
forest to make things easier for followers. 

So I'm very +1 for a jakarta util project. Code sharing is the only way
to create standards (good standars) inside apache itself without
following Sun footsteps. 
That's the main goal of Avalon. For example it defines and implements a
lookup service very different from JNDI (ComponentManager). It's not a
Sun standard but IMHO it's much better for some situation. 
Many devs and users on the list are very happy about it and are using
such pattern in their own products creating a new standard. It's hard
not being Sun to enforce a standard but... I mean... we are Apache! Not
an unknown group of loosers! :-)

If you need a volonteer for jakarta-utils I'm definitly in.

Federico Barbieri
<[EMAIL PROTECTED]>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: What is Struts? (was: Re: What is Avalon?)

[Pier Fumagalli]

Jon Stevens <[EMAIL PROTECTED]> wrote:
> 
> FYI, I just *mostly* implemented the J2EE extensions for Turbine's
> Connection pool (the classes now at least implement the interfaces). It took
> me all of about 30 minutes.
> 
> Have fun.

Thank you :) :) :)

Pier

-- 
Pier Fumagalli 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: What is Struts? (was: Re: What is Avalon?)

[Jon Stevens]

on 2/1/01 5:54 PM, "Craig R. McClanahan" <[EMAIL PROTECTED]>
wrote:

> * JDBC Connections - javax.sql.DataSource and
> * JMS Connections - javax.jms.QueueConnectionFactory
> or javax.jms.TopicConnectionFactory
> * JavaMail connections - javax.mail.Session
> * URL connections - java.net.URL
> 
> These requirements allow an application to be portable across application
> servers --
> for example, to use whichever JDBC connection pool implementation is provided
> by
> that container.
> 
> Coding an app to the Turbine connection pool's API is certainly feasible, and
> it
> will run in this kind of environment -- but you will not be using the
> container's
> built in facilities, which allow containers to implement things like
> distributed
> transaction support, integrated authentication checking, and everything else
> that is
> in the J2EE platform requirements.

FYI, I just *mostly* implemented the J2EE extensions for Turbine's
Connection pool (the classes now at least implement the interfaces). It took
me all of about 30 minutes.

Have fun.

-jon

-- 
If you come from a Perl or PHP background, JSP is a way to take
your pain to new levels. --Anonymous
 | 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: What is Struts? (was: Re: What is Avalon?)

[Ted Husted]

On 2/3/2001 at 8:13 AM Peter Donald wrote:
> We can't force projects - especially new ones - to reuse existing
codebases but overtime we should encourage it.

Thanks for saying this better than I did, Peter. +1.

I'd like to be a good Apache scientist some day, but sometimes it's
hard to understand these things secondhand. 

-T.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: What is Struts? (was: Re: What is Avalon?)

[Peter Donald]

At 08:33  2/2/01 -0500, Sam Ruby wrote:
>Now it irritates me that one has to have separate database pools for
>Struts, JetSpeed, and Cocoon.  I don't honestly care how beautiful the
>internal APIs are, or compatible with some corporate strategy the solution
>is, I just want to be able to share database connections.  Is that so bad?

It's painful when the only way interaction between groups occurs is when it
is forced by some group like SUn who introduces a standard extention for it.

>Unfortunately, the last itch requires more than individual effort - it
>requires teamwork.  Making the core functionality pluggable, or wrappering
>it with a J2EE facade or a Avalon facade, or even making sure that Struts
>remains a single jar are mere technical problems.  It is the recognition
>that out there in the chaos that is open source, somebody will want to
>include more than one subproject in their workspace that I desire more
>people to see.

agreed.

>One other thing to ponder.  Sourceforge is a random collection of open
>source projects, each doing their own thing.  Some successful.  Some
>abandoned.  In Jakarta, some of us have worked hard to produce something
>different - a community centered around the building of related software.
>Perhaps we are deluding ourselves.  You tell me.

Unfortunately it has a little to do with the rate at which jakarta aquires
projects and the rate at which new standard extentions are created to fill
the "holes". We can't force projects - especially new ones - to reuse
existing codebases but overtime we should encourage it.

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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: What is Struts? (was: Re: What is Avalon?)

[Peter Donald]

At 07:41  2/2/01 -0500, Ted Husted wrote:
>When considering the merits of a product, it is important to consider
>the human factor of both our users and developers. It's no secret the
>teams working on competiting solutions often "hate each other". Maybe
>that's a good thing. It may not be as efficient, but given the human
>factor, duplicating resources and fostering competition is usually more
>* effective * than "benevolent" cooperation. 

I dislike the implications of this. You advocate reinventing a wheel
because you can - and better - you get to spit in someone else face. These
things - desirable or not - do not belong inside Apache. Yes - competition
is good however not the type you advocate. Look at the cocoon vs turbine
competition. I remember a time when both groups thought the other didn't
know what they were doing. It wasn't till later that some Cocoon2 peeps
crossed over to the other side and saw Turbine was good (ot sure if vice
versa is true). 

>We need more than just science. We need scientists. 

Only if they are good Apache scientists - no need to get us more scientists
who don't want to follow the Apache way. There is plenty of other
organisations that can host them.


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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: What is Struts? (was: Re: What is Avalon?)

[Peter Donald]

At 10:52  2/2/01 +0100, Ceki Gülcü wrote:
>
>Sorry. I inadvertently pressed Ctrl-e which made Eudora forward my
incomplete note. Here is the complete note.
>
>At 19:19 01.02.2001 -0800, you wrote:
>>on 2/1/01 6:45 PM, "Sam Ruby" <[EMAIL PROTECTED]> wrote:
>>
>>> [ Running, ducking, and grinning ;-) ]
>>> 
>>> - Sam Ruby
>>
>>
>>
>>Do not try to resist.
>>We must follow Sun standards.
>>Resistance is futile.
>>J2EE is the only solution.
>>We are Borg. 
>>JSP, XML and EJB is the only way.
>>We will assimilate you.
>>
>>
>
>
>There is a lot of insight in this . Sun is doing a great job at
convincing people to use their technology. This is truly a Herculean task
and imho constitutes a major achievement for Sun.
>
>We should perhaps learn from their JCP model. This is what I *think* they do:
>
>1)  Identify a problem area.
>2)  Find a number of experts willing to contribute. 
>3)  Designate a leader.
>
>The ordering of (2) and (3) can be inverted.
>
>4a) Define requirements. 
>4b) Consolidate those requirements into a document.
>5a) Define a spec based on the requirements. 
>5b) Consolidate the spec into a document. 
>5c) Publicize the spec.
>
>Step 5 is iterative.
>
>6a) Quitely write code that implements the spec. Do not release/publicize
this code to avoid the burden of maintenance.
>6b) When ready, release alpha code to select users.
>6c) When ready, release beta to a larger set of users.
> 
>7)  Take the world by storm when the API+code is ready.
>
>Sun also has an uber-plan consisting of a new release of the JDK. A new
JDK will mass distribute the new APIs so that there will be no point or
very hard to resist any new API. Steps 1 through 6 ensure that the new API
is not botched. (No one will use a manifestly botched API.)
>
>The challenge in this model is to find a competent and respected leader as
well as experts willing to contribute. 

I think you overestimate the good naturedness of Sun. Like any other
buisness they are in it for the money. The purpose of the API is generally
not to be the best/good at what it does - that is an ancilliary concern -
the purpose is to establish a standard so that buisnesses can adopt java
and understand which technologies are going to be supported and thus have
easy training/management of such things.

Many of these specs are reactionary to equivelent MS "standards".
Fortunately it now looks like Sun is starting to also work with rather than
against other standardisation groups (ie see JDO and ODMG spec and other
interaction with the OMG etc).

Sun also does not accept things that would threaten it's vision (ie
lightweight clients powered by super computers). Consider the case of
select() style functionality - why has not that been added. It's not
because it isn't portable, nor is it because it is technically hard or a
design challenge. I put it to you that the sole reason is because it would
mean that low end servers with a small number of CPUs could actually start
to compete with the suns network OS hardware which would be a bad thing for
them. Yet not having this functionality has proved considerably challenging
to anyone running java as server and in native threads mode. I suspect this
will change with Merlin release as more people were allowed to have an
opinion.


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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Olympics (was: Re: What is Struts? (was: Re: What is Avalon?))

[Jon Stevens]

on 2/2/01 1:34 AM, "Ceki Gülcü" <[EMAIL PROTECTED]> wrote:

> Sun is doing a great job at convincing people to use their technology. This is
> truly a Herculean task and imho constitutes a major achievement for Sun.

Nope. Sun is doing a great job emulating M$. JSP is only better than ASP
simply because it is Java, not because it is a better design. Is JSP better
than .NET? I don't know yet, but M$ usually doesn't make the same mistakes
with regards to technology decisions twice. Anyone remember that M$ was
"missing" on the Internet for so long and when Bill woke up, he assimilated
as much Internet related stuff as he could.


Spelling it out:


What I would love to see, more than anything in this world at this point
(besides whirrled peas), is Microsoft to announce that it is going to Open
Source its entire .Net platform on May 28th...exactly two weeks before
JavaOne.

History tells us that JavaOne is the only time of the year that anyone in
Open Source land can get Sun to do something positive for the overall
communities and this usually happens as a result of some weird Sun internal
firestorm pressure to do things quickly right before JavaOne.

We spent about a year trying to convince Sun to Open Source Tomcat. Suddenly
a few weeks before JavaOne the firestorm happened and the next thing I know
is that I'm on stage with Brian, Pier, Stefano and Patricia at her JavaOne
keynote making the big announcement.

Timeline:

 1998: Jakarta/Tomcat
 1999: Apache/XML
 2000: Open Source Java (tm)?

So, what should we hope for this year from Sun? So far, I expect pretty
little since there hasn't been any real new acronyms popping up like gold
(probably due to the current .bomb mess).

However, seeing M$ come up with something really good would be great
pressure for Sun to emulate something else from M$.

2 weeks would just be a nice world speed record for the gold.

-jon


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: What is Struts? (was: Re: What is Avalon?)

[cmanolache]

My 2c:

Instead of talking it would be easier to create another repository, say 
"jakarta-utils" ( or just use jakarta-tool since it's there :-), and start 
organizing the reusable code in avalon, turbine, tomcat, etc.

I don't see any problem with having 2 connection pools - as long as both
are self-contained and easy to pick and use. 

The problem is when in order to get a connection pool you have to take the
whole package, and it depend on other 10 components. 

It's a huge difference between a "CPAN" where you can get the component
you need ( Graph.pm, GDU.pm ) and what I see here - a XXX where you
have to download the whole archive to use one component. 

IMHO the problem is in the way the code is organized - low level
components should be in a common repository ( jakarta-util ), each with
it's own directory and minimal external dependencies. ( plus explicit list
of deps ). If we'll have 5 connection pools, each having specific
advantages - that's great, having to choose is not bad. All commiters 
to individual projects should be automatically commiters to util, 
and we should periodically scan the projects for "general-purpose" code 
and move it to jakarta-util. 

( probably we'll get 5 StringManagers - but  at least they'll be next to
each other )

-- 
Costin


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: What is Struts? (was: Re: What is Avalon?)

[Ted Husted]

>On 2/2/2001 at 8:33 AM Sam Ruby wrote:
In Jakarta, some of us have worked hard to produce something different
- a community centered around the building of related software. Perhaps
we are deluding ourselves.  You tell me.

I would venture that if the goal of each Jakarta product were to be the
defacto (or actual) reference implementation for it's breed, then the
relations will follow.  Besides meritocracy, another important Apache
principle is "correct first". If we pursue that, the rest will follow.

A good role for the Jakarta PMC is to stay in touch with what the
various product teams are planning, and try to suggest a link to
another product when an idea is gestating (repeat, gestating). Another
good role is to point-out to a team where there is signicant component
that could be turned into a product in its own right. 

On the table now is a Jakarta connection pool product. Another
candidate might be the Jetspeed portlet. 

But to be useful to the other products, these components must also be
exposed at the product level, and have their own set of committers,
release plans, and the rest of it. The Ant model is a good one: the
developers of one Jakarta product become the users of another.


-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel 716 425-0252; Fax 716 223-2506.
-- http://www.husted.com/about/struts/



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: What is Struts? (was: Re: What is Avalon?)

[Sam Ruby]

Ted Husted wrote:
>
> > The desire to work together is core to my thesis that
> > there is a Jakarta community here.
>
> There often seems to be an assumption that our resources,
> or community, is limited. There are a great number of
> Java developers in the world, and our numbers grow every
> day. A project like Struts, with a clear internal focus
> on J2EE compatability can easily attract developers that
> would not otherwise contribute. I happen to be one.
>
> Are we building a cathedral, or a bazaar?

Hmm.  I'm not sure how you got that from my statement, but lets go with
that for a moment.

Many have noticed that I personally enjoy the diversity that exists in
scripting languages, template frameworks, and the like.  To me, that's not
the issue.

Open source is about scratching itches.

It irritated me that PHP is somewhat under the Apache umbrella, and so is
Tomcat, but one couldn't make them work together.

It irritated me that Tomcat originally prereqed Sun's parser and many
Apache projects prereqed Xerces, making them difficult to run together.
Some progress has been made, but some projects (like xml-batik and
xml-axis) haven't quite gotten the message.

Now it irritates me that one has to have separate database pools for
Struts, JetSpeed, and Cocoon.  I don't honestly care how beautiful the
internal APIs are, or compatible with some corporate strategy the solution
is, I just want to be able to share database connections.  Is that so bad?

Unfortunately, the last itch requires more than individual effort - it
requires teamwork.  Making the core functionality pluggable, or wrappering
it with a J2EE facade or a Avalon facade, or even making sure that Struts
remains a single jar are mere technical problems.  It is the recognition
that out there in the chaos that is open source, somebody will want to
include more than one subproject in their workspace that I desire more
people to see.

One other thing to ponder.  Sourceforge is a random collection of open
source projects, each doing their own thing.  Some successful.  Some
abandoned.  In Jakarta, some of us have worked hard to produce something
different - a community centered around the building of related software.
Perhaps we are deluding ourselves.  You tell me.

- Sam Ruby


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: What is Struts? (was: Re: What is Avalon?)

[Ted Husted]

Do not try to resist.
We must use Turbine.
JSP is futile.
Turbine is the only solution.
We are Borg. 
Only Turbine knows the  way.
We will assimilate you.



"Choose your enemies wisely ... for you will become them."


> Needless to say, I think that I'm going to start doing my own
comparisons and placing them up for people to comment. 

Choice is good. Let's have more choice. 


> you are arguing that it code re-use is a bad thing and we all know
that isn't true.

Creating better products with less effort is good. 

When code reuse contributes to that goal, then code reuse is a good
thing. 

But code reuse is neither the goal nor a panacea. 

If this is a meritocracy, and decision-making is being push down, then
a subproject is entitled, even obligated, to decide for itself when it
is better to rewrite than reuse. 

Of course, anyone who disagrees can always make a proposal, provide a
working alternative, and let the subproject Committers decide what's
best for the product and its users. At least if this is really a
meritocracy.

It's also important to remember that Java is a components-based
architecture. It would be reasonable for a product to provide a simple,
easy-to-configure solution as part of the release package, and then
also document how to hook into more full-featured solutions, including
a special-purpose Jakarta product, like a datasource pool. Choice is
good. 

-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel 716 425-0252; Fax 716 223-2506.
-- http://www.husted.com/



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: What is Struts? (was: Re: What is Avalon?)

[Ted Husted]

> The desire to work together is core to my thesis that there is a
Jakarta community here.

There often seems to be an assumption that our resources, or community,
is limited. There are a great number of Java developers in the world,
and our numbers grow every day. A project like Struts, with a clear
internal focus on J2EE compatability can easily attract developers that
would not otherwise contribute. I happen to be one. 

When considering the merits of a product, it is important to consider
the human factor of both our users and developers. It's no secret the
teams working on competiting solutions often "hate each other". Maybe
that's a good thing. It may not be as efficient, but given the human
factor, duplicating resources and fostering competition is usually more
* effective * than "benevolent" cooperation. 

We need more than just science. We need scientists. 

Are we developers looking for projects, or products looking for
developers?

Are we building a cathedral, or a bazaar?


-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel 716 425-0252; Fax 716 223-2506.
-- http://www.husted.com/about/struts/



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: What is Avalon?

[Ignacio J. Ortega]

> reaches almost 5'11"... And 4 inches are _something_ :)
> 
> Pier (thinking: Tomcat is higher than anything else, I'm 6'0")

Which tomcat ? i'm about 6'7" :-)


Saludos ,
Ignacio J. Ortega

PS: Sorry for waste of bandwidth :)

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: What is Struts? (was: Re: What is Avalon?)

[Ceki Gülcü]

Sorry. I inadvertently pressed Ctrl-e which made Eudora forward my incomplete note. 
Here is the complete note.

At 19:19 01.02.2001 -0800, you wrote:
>on 2/1/01 6:45 PM, "Sam Ruby" <[EMAIL PROTECTED]> wrote:
>
>> [ Running, ducking, and grinning ;-) ]
>> 
>> - Sam Ruby
>
>
>
>Do not try to resist.
>We must follow Sun standards.
>Resistance is futile.
>J2EE is the only solution.
>We are Borg. 
>JSP, XML and EJB is the only way.
>We will assimilate you.
>
>


There is a lot of insight in this . Sun is doing a great job at convincing 
people to use their technology. This is truly a Herculean task and imho constitutes a 
major achievement for Sun.

We should perhaps learn from their JCP model. This is what I *think* they do:

1)  Identify a problem area.
2)  Find a number of experts willing to contribute. 
3)  Designate a leader.

The ordering of (2) and (3) can be inverted.

4a) Define requirements. 
4b) Consolidate those requirements into a document.
5a) Define a spec based on the requirements. 
5b) Consolidate the spec into a document. 
5c) Publicize the spec.

Step 5 is iterative.

6a) Quitely write code that implements the spec. Do not release/publicize this code to 
avoid the burden of maintenance.
6b) When ready, release alpha code to select users.
6c) When ready, release beta to a larger set of users.
 
7)  Take the world by storm when the API+code is ready.

Sun also has an uber-plan consisting of a new release of the JDK. A new JDK will mass 
distribute the new APIs so that there will be no point or very hard to resist any new 
API. Steps 1 through 6 ensure that the new API is not botched. (No one will use a 
manifestly botched API.)

The challenge in this model is to find a competent and respected leader as well as 
experts willing to contribute. 

et voila, Ceki


Ceki Gülcü   e-mail: [EMAIL PROTECTED] (preferred)
av. de Rumine 5  [EMAIL PROTECTED]
CH-1005 Lausanne  
SwitzerlandTel: ++41 21 351 23 15


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: What is Struts? (was: Re: What is Avalon?)

[Ceki Gülcü]

At 19:19 01.02.2001 -0800, Jon Stevens wrote:
>on 2/1/01 6:45 PM, "Sam Ruby" <[EMAIL PROTECTED]> wrote:
>
>
>
>Do not try to resist.
>We must follow Sun standards.
>Resistance is futile.
>J2EE is the only solution.
>We are Borg. 
>JSP, XML and EJB is the only way.
>We will assimilate you.
>
>

There is a lot of insight in this . Sun is doing a great job at convincing 
people to use their technology. This is truly a Herculean task and imho constitutes a 
major achievement for Sun.

We should perhaps learn from their JCP model. This is what I *think* they do:

1) Identify a problem area.
2) Find a number of experts willing to contribute. 
3) Designate a leader.
4) Define requirements.
5)  
 

The ordering of (2) and (3) can be inverted.






Ceki Gülcü   
av. de Rumine 5Tel: ++41 21 351 23 15   
CH-1005 Lausannee-mail: [EMAIL PROTECTED]  or
Switzerland [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: What is Avalon?

[Peter Donald]

At 10:33  1/2/01 -0500, Sam Ruby wrote:
>Peter Donald wrote:
>>
>> I have another theory ;) Reuse occurs vertically not
>> horizontally. For instance Cocoon reuses a lot of Avalon
>> code and when a bit of code reaches a certain "generality"
>> threshold in C2 it is bubbled back into Avalon (ie
>> DataSource pools just did so recently). I assume the same
>> thing occurs with Turbine-Jetspeed (didn't some of
>> Jetspeeds security/user-management bubble back ???).
>
>Good point.
>
>Now for the $50,000 question: Which is "higher": Avalon or Turbine?

depends what you mean by "higher" ;) Going back to original defineition of
Avalon

---
Avalon is;
1. A repository of general utility code (CLI parsing, cascading exceptions,
StringUtils, etc)
2. A repository of patterns and framework code (ie component lifecycle code
and mamanagement code - think loggign, configuring Startable, Stoppable
Suspendable, Reesumable)
3. A set of general utility code based on (2) that offers "doing" code and
extended patterns. (ie object pooling, thread management, classloader
management, policy management, utility classes that "run" components
lifecycle, Container-Component patterns and implementations,
Kernel-Application-Component patterns and implementation).
4. A micro kernel for running services
5. A set of services that are orientated towards server environments (ie
SocketFactories, ConnectionManagers, Schedulers etc)
---

Both Turbine and Avalon could easily share (1) - possibly put it in Apache
Utility Toolkit that JDD proposed ages ago.

Turbine doesn't have much in the way of (2) but this is the only thing that
is stable in Avalon - it's forte and what cocoon/mrymidon use.

Both Turbine and Avalon have (3) but they do different things in different
projects. So relatively little overlap here.

Turbine doesn't need the abstraction of (4) because of the TDK and because
it is assumed one Turbine app per .war.

Turbines (5) partially overlaps with Avalons (3) and Avalons (5).

I don' think that they could share much of (4), (5) and parts of (3) in
short term bu long term it is a possibility.

>I see both as competing for the title of "bottom".

Well Avalon is more generic and you could build a turbine out of Avalon but
not vice versa. Turbines the bottom for web-apps while Avalons the bottom
for component based apps IMHO. Avalon doesn't even try to do half the
things Turbine does well and vice versa.

>It would be a darn shame for each component in the system to continue to
>have its own pool of JDBC connections at runtime.

agreed.

>Struts is a potential customer.  There is an interesting dynamic that is
>available for somebody to exploit: the reusable framework with the most
>customers tends to attract more customers.

True but I don't think either Avalon or Turbine are customer directed. They
are built to get a job done and/or because they are kewl ;) If users come
then good as it gives more useful refactoring/perspectives, if not we will
still keep on hacking ;)

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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: What is Avalon?

[Pier Fumagalli]

Sam Ruby <[EMAIL PROTECTED]> wrote:
> 
> Now for the $50,000 question: Which is "higher": Avalon or Turbine?

I believe Avalon, because Jon is somewhere around 5'7" tall, while Federico
reaches almost 5'11"... And 4 inches are _something_ :)

Pier (thinking: Tomcat is higher than anything else, I'm 6'0")

-- 
Pier Fumagalli 
I'm selling my Sony Vaio Z505. Check out 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: What is Avalon?

[Sam Ruby]

Peter Donald wrote:
>
> I have another theory ;) Reuse occurs vertically not
> horizontally. For instance Cocoon reuses a lot of Avalon
> code and when a bit of code reaches a certain "generality"
> threshold in C2 it is bubbled back into Avalon (ie
> DataSource pools just did so recently). I assume the same
> thing occurs with Turbine-Jetspeed (didn't some of
> Jetspeeds security/user-management bubble back ???).

Good point.

Now for the $50,000 question: Which is "higher": Avalon or Turbine?

I see both as competing for the title of "bottom".

It would be a darn shame for each component in the system to continue to
have its own pool of JDBC connections at runtime.

Struts is a potential customer.  There is an interesting dynamic that is
available for somebody to exploit: the reusable framework with the most
customers tends to attract more customers.

- Sam Ruby


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: What is Struts? (was: Re: What is Avalon?)

[Jon Stevens]

on 2/1/01 6:45 PM, "Sam Ruby" <[EMAIL PROTECTED]> wrote:

> [ Running, ducking, and grinning ;-) ]
> 
> - Sam Ruby



Do not try to resist.
We must follow Sun standards.
Resistance is futile.
J2EE is the only solution.
We are Borg. 
JSP, XML and EJB is the only way.
We will assimilate you.



:-)

-jon


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: What is Struts? (was: Re: What is Avalon?)

[Sam Ruby]

Jon Stevens wrote:
>
> The fact that you can take Servlets for Tomcat 3.3 and Tomcat 4.0
> and run them the same way is simply because Danny and others got
> smart and introduced a requirement within the specification itself
> that the backwards compatibility exist.

[ Ooooh... you make it too easy ]

So... when is the Turbine team going to get smart?

[ Running, ducking, and grinning ;-) ]

- Sam Ruby


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: What is Struts? (was: Re: What is Avalon?)

[Jon Stevens]

on 2/1/01 5:54 PM, "Craig R. McClanahan" <[EMAIL PROTECTED]>
wrote:

> Yes, Turbine came first.  And it implements what it includes quite well.  No
> question.  But part of being first is deciding what to do when the rest of the
> world tries to catch up, and standardizes APIs for some of the features you
> implement. This is a strategic decision that the Turbine community needs to
> make for itself.

I think that the decision is clear. :-)

> The effort cost to me of involving myself in that community, to help you think
> about if you want to conform to J2EE API patterns (and contributing code if
> you did -- otherwise it wouldn't scratch any of my itches) would far exceed
> the effort cost of implementing a connection pool that does something similar
> to what Turbine provides, but does so in a manner compatible with the standard
> that came along later.

I don't agree that it would far exceed the effort cost.

> In my idealism of last year, I assumed that I would have enough available
> awake hours to do so.  I simply don't have the cycles to engage in yet another
> high volume / high quality email list, or the emotional energy to put up with
> the anti-JSP sentiment that would undoubtedly come my way.

But you have enough time to re-write source code that was already written?
You have enough time to maintain yet another re-write of something that
already exists?

Your argument is silly to me because you are arguing that it code re-use is
a bad thing and we all know that isn't true.

> What I will do for Turbine, however, is work to give you the best possible
> servlet container on which to run it.

That's good to hear.

> Software should evolve.  It should get better.  But, if you want software to
> be used on large scale projects with lifetimes measured in years (not months),
> you need to be serious about backwards compatibility on APIs.

That is exactly why I like a license like the BSD/ASF license. It allows you
to take a snapshot at any point in time and develop on it and never have to
worry about giving anything back.

That said, in the case of webapps, Servlets and Java, they are not  mature
enough technologies to be able to able to count on a stable product with
API's that never change for years...anyone believing that is kidding
themselves.

> I'm not familiar with the details of Sam's specific issues -- what I was
> echoing is agreement with the gist of the points he was making.

His overall points were good, but the examples were incorrect. :-)

>  In fact, my 
> personal experience is that it goes beyond APIs -- how many times have you had
> to go back and change your build scripts to keep up with the rate of change in
> Ant?

You know what? I'm really ok with updating my build scripts. It isn't that
big of a deal to replace  with .

What happened to believing that software evolves? :-)

> Changing the fundamental APIs was not my idea.  But, the suggested approach
> was better -- and if you're going to do it, before an x.0 release is exactly
> the time to make those changes.  Or, would you rather see the fundamental
> interfaces change on every dot release (Tomcat 3.0 -> 3.1 -> 3.2 -> 3.3 comes
> to mind)?

I was giving an example...

> For a counter-example, you might look at how Struts bends over backwards to
> support the APIs of the 0.5 milestone release, even in the face of pretty
> substantial improvements.  The number of developers, and the amount of already
> existing code, impacted by these changes was *substantially* higher than the
> number of people who have written Valves to date -- so it was worth the
> investment in effort.

Yep.

> Had the Valves change actually been made in 4.1 instead of 4.0, you would
> certainly see deprecations and backwards compatibility support.

Even still deprecations don't entirely solve the problem.

> NOTE:  The servlet and JSP APIs are *still* not finalized -- the specs
> implemented by the current code are "Proposed Final Draft".  Any changes that
> happen in the final drafts must, of course, be reflected in Tomcat for it to
> remain true to its mission of faithfully implementing those specs.

NOTE: The Turbine and Avalon and Ant and Struts and and and and API's are
*still* not finalized -- the specs implemented by the current code are
"Standing on the heads of the developers". Any changes that happen in the
final drafts must, of course, be reflected in any applications for it to
remain true to its mission of faithfully implementing those specs.

:-)

-jon


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: What is Struts? (was: Re: What is Avalon?)

[Jon Stevens]

on 2/1/01 5:13 PM, "Sam Ruby" <[EMAIL PROTECTED]> wrote:

> Both the impending Tomcat 3.3 and Tomcat 4.0 look considerably different
> internally than the original Tomcat 3.0.  But the overwhelming majority of
> the servlets that ran on Tomcat 3.0 will run on either.  The reason?  The
> much maligned JCP views the servlet API as a contract.

The Servlet API is a terrible example of backwards compatibility...even with
regards to deprecated methods. Look at how many changes went into 2.0 -> 2.1
and then 2.1->2.2 that broke tons of code.

To this day, we still have at least one place in Turbine that require us to
use reflection in order to get the proper values that we need because
suddenly API methods are returning different values than previously
expected.

The fact that you can take Servlets for Tomcat 3.3 and Tomcat 4.0 and run
them the same way is simply because Danny and others got smart and
introduced a requirement within the specification itself that the backwards
compatibility exist.

Let me also add on to that the point of opening up the Watchdog stuff was in
part mitigated by the fact that myself and others were *screaming* for an
open test suite for all containers to be *required* to conform to.
Unfortunately, even to this day, that requirement has never been implemented
or even brought up again. :-( It is a miracle that there are so many
different servlet containers out there and that they, for the most part, all
run Servlets properly.

-jon


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: What is Avalon?

[Peter Donald]

At 02:12  1/2/01 -0500, Sam Ruby wrote:
>I'm not sure why there isn't more reuse going on within Jakarta, but my
>_theory_ is that the cost associated with versioning issues exceed the
>costs associated with dual maintenance.

I have another theory ;) Reuse occurs vertically not horizontally. For
instance Cocoon reuses a lot of Avalon code and when a bit of code reaches
a certain "generality" threshold in C2 it is bubbled back into Avalon (ie
DataSource pools just did so recently). I assume the same thing occurs with
Turbine-Jetspeed (didn't some of Jetspeeds security/user-management bubble
back ???). 

However there is little to no cross-talk between the Avalon-J2EE-Turbine
camps because each of them is working within their own framework rather
than as an API. ie If you adopt component Foo from framework Bar then you
also get the "baggage" associated with Bar. For instance if you use Turbine
services you got to deal with their propertie files + singleton structure.
If you use the Avalon framework you got to deal with XML style
configurations and separation of every concern to the n'th degree ;) No
idea on struts et al.

To get collaboration we would have to build a lower-level framework or
build API-like code that is wrapped in framework code. API-like code is
generally harder to write and ends up looking like a bunch of beans. Is the
effort to write beans rather than framework components worth it ? I would
say yes but only in time ;)  Have a look at how long it took to get Avalon
rolling and it is only just starting to separate out framework specific
from non-framework specific. 

I guess the best way to enable sharing would be to get a bunch of people
from different projects that have code in common. Turbine/Jetspeed +
Catalina + Avalon + Slide are the ones that jump out at me but I am sure
there are others. We could then migrate framework-nonspecific code into a
central repository and play though polic to keep backwards
compatability/deprecation trends happening ;)

CJAN would of course make this much easier as you could reuse components at
a finer level.
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: What is Struts? (was: Re: What is Avalon?)

[Jon Stevens]

on 2/1/01 5:22 PM, "Craig R. McClanahan" <[EMAIL PROTECTED]>
wrote:

> Coding an app to the Turbine connection pool's API is certainly feasible, and
> it
> will run in this kind of environment -- but you will not be using the
> container's
> built in facilities, which allow containers to implement things like
> distributed
> transaction support, integrated authentication checking, and everything else
> that is
> in the J2EE platform requirements.

The other feasibility would be to simply make Turbine's connection pool
implement that API. Previously someone had suggested doing this on the
Turbine list and I rejected it at the time because the User didn't give a
good reason (actually, they gave no reason at all).

In the case above, you give a good reason and I would be for it. But, it
doesn't matter...cause you never asked and never gave a reason. You just
simply went out and did it on your own without even trying to work
together...oh well...more duplicated code in Jakarta projects and more
confusion for our users...

It is funny, I'm arguing for less confusion for our users and you are
arguing for more confusion! I don't get it. :-(

> Turbine grows features in response to the needs of its users (and, of course,
> the
> willingness of people to contribute effort to it).  So does Struts.
> 
> A large and growing portion of the Struts community are building apps for
> deployment
> in J2EE environments.  Implementing features that are not aligned with the
> corresponding APIs would be a disservice to them.  NOTE:  The issue isn't
> "everything in Struts must be a J2EE API".  Rather, it's "nothing in Struts
> should
> violate J2EE API requirements."

Funny, it doesn't say that on the homepage either.

> Your comments about EJBs ("who needs them"  "useless" etc.) in mailing lists,
> and in
> your Turbine presentation at ApacheCon Europe, were pretty direct complaints
> :-).

My comments about EJB's are clearly:

They are only useful in a small percentage of applications. I say the same
thing about XML as well. I'm tired of people trying to fit every single
technology into every other technology without a scientific reason for *why*
it should be done. 

With regards to that directly, EJB's are also just one single technology
within J2EE. In fact, Turbine tries very hard to follow a core J2EE
technology that I believe strongly in...Servlets.

-jon


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: What is Struts? (was: Re: What is Avalon?)

[Sam Ruby]

Jon Stevens wrote:
>
> Case in point: The changes that Sam quoted with regards to
> Turbine breaking Jetspeed in a single tinderbox build were
> mitigated by the fact that the Jetspeed developers asked
> for those changes to happen in the first place. That is a
> tiny little bit of very important context that Sam
> conveniently left out. :-)

Single?  I won't quibble.  ;-)

Are you saying that this could not have been implemented in a way that
permitted a smooth migration?  Or that the JetSpeed developers specifically
asked that there not be a transition period?

Both the impending Tomcat 3.3 and Tomcat 4.0 look considerably different
internally than the original Tomcat 3.0.  But the overwhelming majority of
the servlets that ran on Tomcat 3.0 will run on either.  The reason?  The
much maligned JCP views the servlet API as a contract.

The desire to work together is core to my thesis that there is a Jakarta
community here.

> With regards to Cocoon, he also left out the fact that we
> DID in fact mark those changed database pool API's as
> deprecated for a few months before removing the deprecated
> code.

The reason I left that out is that I was unaware of it.  My apologies.

- Sam Ruby


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: What is Struts? (was: Re: What is Avalon?)

[Jon Stevens]

on 2/1/01 5:42 PM, "Peter Donald" <[EMAIL PROTECTED]> wrote:

> Actually you follow a lot of the patterns of J2EE aswell - you just do it
> differently. Their services directory via JNDI is equivelent to your
> singleton setup, you use log4j/other for logging while they will use that
> godforsaken sucky logging JSR, you use X they use Y ... ;)

To be more accurate, Turbine provides a way to build ANY logging system into
the backend. That is one of the beauties of Turbine...it is very good at
being the container for any number of technologies.

:-)

> In the long run it would be kewl to allow dual access so that J2EE devs
> could use turbine in a similar manner to most other newer web/enterprise
> apps.

Actually, I have a couple great emails from someone at Nokia that uses
Turbine (see below)...obviously we are doing *something* right. :-) Please
note that both of his issues (in Logging and Services) have already been
resolved.

> Of course a lot of the J2EE design decisions suck and you would have
> to live with them if you went that path ;)

No shit. I'm really tired of this constant pressure to use J2EE when
obviously so many things about it just plain suck...primarily JSP.

I had a great conversation today with Jason Hunter about his upcoming second
edition O'Reilly book on Servlets and how he spent a bunch of time doing
non-biased comparisons between different technologies in order to let people
come up with their own opinions on what they think of the different
implementation approaches instead of the constant pressure to simply use
what Sun's tells them to use. Funny, that sounds like a M$ thing to do.

It is amazing to me how anyone would want to use some of these technologies.
His comparison between Struts and Tea and WebMacro was a real eye opener as
to the fact that even though Struts is JSP done right, it still doesn't even
begin to hide the overall warts in JSP. I can't wait till that book is
published so that people can see these differences in plain as day examples.

Needless to say, I think that I'm going to start doing my own comparisons
and placing them up for people to comment. It is time that people wake up
and realize that the way that Sun dictates for people to do things isn't
necessarily the right way to do things.

-jon

> --
> From: [EMAIL PROTECTED]
> Reply-To: "Turbine" <[EMAIL PROTECTED]>
> Date: Tue, 23 Jan 2001 15:23:09 +0200
> To: [EMAIL PROTECTED]
> Subject: JMX integration issues
> 
> Hi
> 
> We have started an attemt to integrate Turbine to our JMX (Java Management
> eXtensions from Sun) based network agent framework. The framework includes
> its own server and doesn't support servlets directly but a somewaht lighter
> concept that we call request processors. It was a straightforward task to
> convert the Turbine servlet into a processor and get the system running.
> However, two static classes caused some problems.
> 
> 1) It would be useful if the static Log supported customizable instances
> that could redirect log messages to whatever logging system is used in the
> integrating environment.
> 
> 2) TurbineServices implements nicely the ServiceBroker interface and
> provides protected constructors. However, the instance member is private and
> the getInstance method returns a reference to the class instance, not to the
> implemented interface, although the getService method of the interface is
> almost the only one needed outside the class. A possibility to extend and
> customize the TurbineServices instance would make it possible to support
> other service construction methods than Class.forName and additional broker
> mechanisms.
> 
> Other components of Turbine, like assembler factories, seemed to be
> extremely well configurable and customizable. The need to modify some of the
> base classes arise from our JMX based object management and broker system
> that we'd like to use for Turbine based objects also. One benefit of a
> separate broker system is a possibility to use different instances of the
> same Turbine module class depending on the context, e.g. pages maintaining
> state of a group of users and supporting several simultaneous groups.
> 
> Ilkka
> --
> Ilkka Priha
> Nokia Networks 
> http://www.nokia.com/networks
> mail: [EMAIL PROTECTED]

> --
> From: [EMAIL PROTECTED]
> Reply-To: "Turbine" <[EMAIL PROTECTED]>
> Date: Wed, 24 Jan 2001 09:39:04 +0200
> To: [EMAIL PROTECTED]
> Subject: RE: JMX integration issues
> 
> Rafal, Thanks for your comment. I'm waiting for LogService...
> 
> Here is some background information about JMX.
> 
> JMX has evolved from a hardware related need to be able to manage thousands
> of different devices using different protocols in a telecommunications
> network. JMX solves the problem with Java so well that the same framework
> can be used for managing software components as well. The idea is to have a
> centralized object registry server, through which clients can ask for
> service objects they need. The registr

Re: What is Struts? (was: Re: What is Avalon?)

[Craig R. McClanahan]

NOTE:  I accidentally pressed "Send" rather than "Save" while editing this message.
The completed response below includes additional comments.

Jon Stevens wrote:

> on 2/1/01 1:43 PM, "Craig R. McClanahan" <[EMAIL PROTECTED]>
> wrote:
>
> > Jon Stevens wrote:
> >
> >>
> >> Shame on Struts for not using Turbine's Connection pool. That makes me very
> >> upset because this was something that Craig promised would not happen (that
> >> there wouldn't be much major duplication in Struts as in Turbine).
> >
> > The connection pool in Turbine does not implement the javax.sql.DataSource API
> > (from the JDBC 2.0 standard extensions package), which makes it unsuitable for
> > use in a J2EE environment (a very common deployment scenario for Struts based
> > applications).
>
> What *exactly* makes it unsuitable? You ask for a Connection object and you
> get one and it works with all of the known JDBC database drivers out there.
>

In a J2EE app, the usual approach for acquiring resource instances from an
appropriate factory is to look up the factory instance in a container-provided JNDI
context.  The resource factory then returns an instance of the appropriate class.

To ensure portability, the APIs for common resource factories (and therefore the
resources that you can acquire from those factories) are standardized:

* JDBC Connections - javax.sql.DataSource and
* JMS Connections - javax.jms.QueueConnectionFactory
  or javax.jms.TopicConnectionFactory
* JavaMail connections - javax.mail.Session
* URL connections - java.net.URL

These requirements allow an application to be portable across application servers --
for example, to use whichever JDBC connection pool implementation is provided by
that container.

Coding an app to the Turbine connection pool's API is certainly feasible, and it
will run in this kind of environment -- but you will not be using the container's
built in facilities, which allow containers to implement things like distributed
transaction support, integrated authentication checking, and everything else that is
in the J2EE platform requirements.

>
> I also do not see anywhere on the Struts homepage anything stating that all
> components within the Struts framework must implement the J2EE API's.

Turbine grows features in response to the needs of its users (and, of course, the
willingness of people to contribute effort to it).  So does Struts.

A large and growing portion of the Struts community are building apps for deployment
in J2EE environments.  Implementing features that are not aligned with the
corresponding APIs would be a disservice to them.  NOTE:  The issue isn't
"everything in Struts must be a J2EE API".  Rather, it's "nothing in Struts should
violate J2EE API requirements."


>
> > Now, should I go try to lobby the Turbine developers to add this feature
> > (either directly, or by wrapping)?  Probably ... but I'm not going to go fight
> > that battle.  Given the clear antipathy that many Turbine developers have for
> > the J2EE APIs, it is *substantially* less effort to do separately what Struts
> > requires, versus lobby / cajole / argue / become a Turbine committer in order
> > for the shared module to meet *my* needs.
>
> Ok, lets have some fun here...I'm going to play a game where I state what I
> hear you saying and you tell me if I'm right and correct me if I'm wrong.
> :-)
>
> So I hear you saying:
>
> You do not want to work together because you think that Turbine developers
> have antipathy for *ALL* J2EE API's even though we have competing products
> within the same project and that Turbine came long before Struts and Turbine
> has support for JSP (which is the *only* J2EE API that I have ever heard
> anyone in Turbine land complain about).
>

Your comments about EJBs ("who needs them"  "useless" etc.) in mailing lists, and in
your Turbine presentation at ApacheCon Europe, were pretty direct complaints :-).

Yes, Turbine came first.  And it implements what it includes quite well.  No
question.  But part of being first is deciding what to do when the rest of the world
tries to catch up, and standardizes APIs for some of the features you implement.
This is a strategic decision that the Turbine community needs to make for itself.

The effort cost to me of involving myself in that community, to help you think about
if you want to conform to J2EE API patterns (and contributing code if you did --
otherwise it wouldn't scratch any of my itches) would far exceed the effort cost of
implementing a connection pool that does something similar to what Turbine provides,
but does so in a manner compatible with the standard that came along later.

>
> Sigh, I should have held my -1 on the Struts project creation way back when
> because obviously you are not going to hold up to what you stated that you
> would. Specifically (yes, this email was granted permission to be made
> public):
>
> Message-ID: <[EMAIL PROTECTED]>
> Date: Tue, 30 May 2000 12:45:17 -0700
> From: "Craig R. McClanahan"

Re: What is Struts? (was: Re: What is Avalon?)

[Peter Donald]

At 05:33  1/2/01 -0800, Jon Stevens wrote:
>With regards to that directly, EJB's are also just one single technology
>within J2EE. In fact, Turbine tries very hard to follow a core J2EE
>technology that I believe strongly in...Servlets.

Actually you follow a lot of the patterns of J2EE aswell - you just do it
differently. Their services directory via JNDI is equivelent to your
singleton setup, you use log4j/other for logging while they will use that
godforsaken sucky logging JSR, you use X they use Y ... ;)

In the long run it would be kewl to allow dual access so that J2EE devs
could use turbine in a similar manner to most other newer web/enterprise
apps. Of course a lot of the J2EE design decisions suck and you would have
to live with them if you went that path ;)

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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: What is Struts? (was: Re: What is Avalon?)

[Craig R. McClanahan]

Jon Stevens wrote:

> on 2/1/01 1:43 PM, "Craig R. McClanahan" <[EMAIL PROTECTED]>
> wrote:
>
> > Jon Stevens wrote:
> >
> >>
> >> Shame on Struts for not using Turbine's Connection pool. That makes me very
> >> upset because this was something that Craig promised would not happen (that
> >> there wouldn't be much major duplication in Struts as in Turbine).
> >
> > The connection pool in Turbine does not implement the javax.sql.DataSource API
> > (from the JDBC 2.0 standard extensions package), which makes it unsuitable for
> > use in a J2EE environment (a very common deployment scenario for Struts based
> > applications).
>
> What *exactly* makes it unsuitable? You ask for a Connection object and you
> get one and it works with all of the known JDBC database drivers out there.
>

In a J2EE app, the usual approach for acquiring resource instances from an
appropriate factory is to look up the factory instance in a container-provided JNDI
context.  The resource factory then returns an instance of the appropriate class.

To ensure portability, the APIs for common resource factories (and therefore the
resources that you can acquire from those factories) are standardized:

* JDBC Connections - javax.sql.DataSource and
* JMS Connections - javax.jms.QueueConnectionFactory
  or javax.jms.TopicConnectionFactory
* JavaMail connections - javax.mail.Session
* URL connections - java.net.URL

These requirements allow an application to be portable across application servers --
for example, to use whichever JDBC connection pool implementation is provided by
that container.

Coding an app to the Turbine connection pool's API is certainly feasible, and it
will run in this kind of environment -- but you will not be using the container's
built in facilities, which allow containers to implement things like distributed
transaction support, integrated authentication checking, and everything else that is
in the J2EE platform requirements.

>
> I also do not see anywhere on the Struts homepage anything stating that all
> components within the Struts framework must implement the J2EE API's.
>

Turbine grows features in response to the needs of its users (and, of course, the
willingness of people to contribute effort to it).  So does Struts.

A large and growing portion of the Struts community are building apps for deployment
in J2EE environments.  Implementing features that are not aligned with the
corresponding APIs would be a disservice to them.  NOTE:  The issue isn't
"everything in Struts must be a J2EE API".  Rather, it's "nothing in Struts should
violate J2EE API requirements."


>
> > Now, should I go try to lobby the Turbine developers to add this feature
> > (either directly, or by wrapping)?  Probably ... but I'm not going to go fight
> > that battle.  Given the clear antipathy that many Turbine developers have for
> > the J2EE APIs, it is *substantially* less effort to do separately what Struts
> > requires, versus lobby / cajole / argue / become a Turbine committer in order
> > for the shared module to meet *my* needs.
>
> Ok, lets have some fun here...I'm going to play a game where I state what I
> hear you saying and you tell me if I'm right and correct me if I'm wrong.
> :-)
>
> So I hear you saying:
>
> You do not want to work together because you think that Turbine developers
> have antipathy for *ALL* J2EE API's even though we have competing products
> within the same project and that Turbine came long before Struts and Turbine
> has support for JSP (which is the *only* J2EE API that I have ever heard
> anyone in Turbine land complain about).
>

Your comments about EJBs ("who needs them"  "useless" etc.) in mailing lists, and in
your Turbine presentation at ApacheCon Europe, were pretty direct complaints :-).

>
> Sigh, I should have held my -1 on the Struts project creation way back when
> because obviously you are not going to hold up to what you stated that you
> would. Specifically (yes, this email was granted permission to be made
> public):
>
> Message-ID: <[EMAIL PROTECTED]>
> Date: Tue, 30 May 2000 12:45:17 -0700
> From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Subject: Re: [PROPOSAL/VOTE] New Jakarta Subproject - "Struts"
>
> [...]
> "Once the pattern is clear, it will be lots easier to integrate the
> final result into Turbine, rather than doing the integration over and over
> again as the patterns get refined."
> [...]
>
> I read that as saying that at some point, you wanted to work with the
> Turbine project and not duplicate effort over and over and over again.
>
> That is clearly contrary to what you are saying now.
>
> > The issues that Sam raises (lack of attention to backwards compatibility of
> > interfaces, plus arbitrary changes in current development with no
> > consideration of the fact that other people are depending on interface
> > stability) have bitten me every single time I've gotten involved in a "shared
> > utilities" sort of environment.  IMHO there will

What is Struts? (was: Re: What is Avalon?)

[Jon Stevens]

on 2/1/01 1:43 PM, "Craig R. McClanahan" <[EMAIL PROTECTED]>
wrote:

> Jon Stevens wrote:
> 
>> 
>> Shame on Struts for not using Turbine's Connection pool. That makes me very
>> upset because this was something that Craig promised would not happen (that
>> there wouldn't be much major duplication in Struts as in Turbine).
> 
> The connection pool in Turbine does not implement the javax.sql.DataSource API
> (from the JDBC 2.0 standard extensions package), which makes it unsuitable for
> use in a J2EE environment (a very common deployment scenario for Struts based
> applications).

What *exactly* makes it unsuitable? You ask for a Connection object and you
get one and it works with all of the known JDBC database drivers out there.

I also do not see anywhere on the Struts homepage anything stating that all
components within the Struts framework must implement the J2EE API's.

> Now, should I go try to lobby the Turbine developers to add this feature
> (either directly, or by wrapping)?  Probably ... but I'm not going to go fight
> that battle.  Given the clear antipathy that many Turbine developers have for
> the J2EE APIs, it is *substantially* less effort to do separately what Struts
> requires, versus lobby / cajole / argue / become a Turbine committer in order
> for the shared module to meet *my* needs.

Ok, lets have some fun here...I'm going to play a game where I state what I
hear you saying and you tell me if I'm right and correct me if I'm wrong.
:-)

So I hear you saying:

You do not want to work together because you think that Turbine developers
have antipathy for *ALL* J2EE API's even though we have competing products
within the same project and that Turbine came long before Struts and Turbine
has support for JSP (which is the *only* J2EE API that I have ever heard
anyone in Turbine land complain about).


Sigh, I should have held my -1 on the Struts project creation way back when
because obviously you are not going to hold up to what you stated that you
would. Specifically (yes, this email was granted permission to be made
public): 

Message-ID: <[EMAIL PROTECTED]>
Date: Tue, 30 May 2000 12:45:17 -0700
From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Subject: Re: [PROPOSAL/VOTE] New Jakarta Subproject - "Struts"

[...]
"Once the pattern is clear, it will be lots easier to integrate the
final result into Turbine, rather than doing the integration over and over
again as the patterns get refined."
[...]


I read that as saying that at some point, you wanted to work with the
Turbine project and not duplicate effort over and over and over again.

That is clearly contrary to what you are saying now.

> The issues that Sam raises (lack of attention to backwards compatibility of
> interfaces, plus arbitrary changes in current development with no
> consideration of the fact that other people are depending on interface
> stability) have bitten me every single time I've gotten involved in a "shared
> utilities" sort of environment.  IMHO there will not be any quality sharing of
> supposedly "reusable" code until:
> 
> * People start designing code that is designed to be reused -- we all have
> natural biases towards the original use for which we scratched that itch in
> the first place, and tend to create either explicit or implcit dependencies on
> the remainder of the original project.
> 
> * We find developers (for the "shared code" module) that are committed to
> keeping the shared code stable, and to resolving the inevitable disputes (I
> need StringUtils to do something this way; someone else needs it to work that
> way).
> 
> * The shared code base is around long enough to regain the confidence of
> people like me that they can depend on it -- and not have to go back and
> retrofit every time someone else decides to tweak a shared class in a manner
> that is not backwards compatible.
> 
> Craig

My god Craig, you are scaring me. Do you believe that software shouldn't
evolve? :-)

Case in point: The changes that Sam quoted with regards to Turbine breaking
Jetspeed in a single tinderbox build were mitigated by the fact that the
Jetspeed developers asked for those changes to happen in the first place.
That is a tiny little bit of very important context that Sam conveniently
left out. :-)

With regards to Cocoon, he also left out the fact that we DID in fact mark
those changed database pool API's as deprecated for a few months before
removing the deprecated code.

Lets bring up another case of changing API's midstream. How about discussing
the modifications that are going to happen to the Tomcat 4.x Valves in order
to bring them more in line with the Filters API. :-) Somehow I doubt that
you are going to keep those deprecated methods and code around. We could
even go back to the point that Catalina implemented early Servlet API
methods that were not finalized and were later changed. Were those methods
deprecated before being changed? Somehow I doubt it.

:-)

-jon

Re: What is Avalon?

[Ted Husted]

On 2/1/2001 at 2:12 PM Sam Ruby wrote:
>I'm not sure why there isn't more reuse going on within Jakarta, but
my _theory_ is that the cost associated with versioning issues exceed
the costs associated with dual maintenance

Another important issue for "commercial-quality" applications is easy
of installation (along with maintenance). Right now, we can deploy a
Struts application, including the datasource pool, with a single JAR.
>From the the traffic on the list, I can tell you this is an essential
feature to many users. 

Of course, with Ant, it might be possible to do something clever with
assembling builds from across projects. (Again underscoring the need to
have tools like Ant under our wing.) 


-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel 716 425-0252; Fax 716 223-2506.
-- http://www.husted.com/about/struts/



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: What is Avalon?

[Craig R. McClanahan]

Jon Stevens wrote:

>
> Shame on Struts for not using Turbine's Connection pool. That makes me very
> upset because this was something that Craig promised would not happen (that
> there wouldn't be much major duplication in Struts as in Turbine).

The connection pool in Turbine does not implement the
javax.sql.DataSource API
(from the JDBC 2.0 standard extensions package), which makes it
unsuitable for use
in a J2EE environment (a very common deployment scenario for Struts
based
applications).

Now, should I go try to lobby the Turbine developers to add this feature
(either
directly, or by wrapping)?  Probably ... but I'm not going to go fight
that battle.  Given the clear
antipathy that many Turbine developers have for the J2EE APIs, it is
*substantially* less effort to do separately what Struts requires,
versus lobby
/ cajole / argue / become a Turbine committer in order for the shared
module to
meet *my* needs.

The issues that Sam raises (lack of attention to backwards compatibility
of
interfaces, plus arbitrary changes in current development with no
consideration of
the fact that other people are depending on interface stability) have
bitten me
every single time I've gotten involved in a "shared utilities" sort of
environment.  IMHO there will not be any quality sharing of supposedly
"reusable"
code until:

* People start designing code that is designed to be reused -- we
  all have natural biases towards the original use for which we
scratched
  that itch in the first place, and tend to create either explicit or
implcit
  dependencies on the remainder of the original project.

* We find developers (for the "shared code" module) that are committed
  to keeping the shared code stable, and to resolving the inevitable
  disputes (I need StringUtils to do something this way; someone else
  needs it to work that way).

* The shared code base is around long enough to regain the confidence
  of people like me that they can depend on it -- and not have to go
back
  and retrofit every time someone else decides to tweak a shared class
  in a manner that is not backwards compatible.

Craig

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: What is Avalon?

[Jon Stevens]

on 1/31/01 8:53 PM, "David Weinrich" <[EMAIL PROTECTED]> wrote:

> With the recent discussions about tinderbox/CJAN and related stuff, I have
> started wondering about the cases where multiple jakarta projects have areas
> of overlap/duplication. From digging into struts for a very short time I
> notice that it also has a Database Connection Pooling component and some
> string utilities ( I don't know if the string utilities are related in any
> way to Avalon or Turbine ). That makes for three projects that implement the
> same or very similar things.

Shame on Struts for not using Turbine's Connection pool. That makes me very
upset because this was something that Craig promised would not happen (that
there wouldn't be much major duplication in Struts as in Turbine).

Even Cocoon uses Turbine's Connection pool and we put a lot of effort into
making a build target for Turbine that allows you to only build the
turbine-pool.jar.

As for StringUtil's duplication, that isn't that big of a deal to me because
this code is duplicated all the time. It is simple to create and simple to
duplicate and most of it is Java 101 type of code. Not as much of a big
deal.

> The ( possibly naive ) question that comes to my mind is: would it be
> beneficial to take certain aspects of these projects that share the same
> goals or produce libraries with the same or similar functionality and create
> a repository of tools that each do one thing ( or maybe two ) and do them
> very very well. One project that comes to mind is log4j, which recently
> joined jakarta. It focuses on one specific task, logging, and it does it
> extremely well.

That is hard to do because you have communities around the software as well
and there just isn't enough time in the day to track all the changes that
are going on across all communities.

> In my mind this issue is very close to how I see something that will
> hopefully someday become CJAN: a place where people can find the specific
> java libraries/tools that they need. I know that a few times in the recent
> past I have looked for things similar to JDBC pooling and something similar
> to cron for java and found what is available is scattered about on
> individual websites. The ability to present developers with a trusted source
> of high quality and very focused components could only enhance the java
> community as a whole and bring new voices/minds/ideas into the
> jakarta/apache community.

Yep.

-jon


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: What is Avalon?

[Sam Ruby]

Jon Stevens wrote:
>
> Shame on Struts for not using Turbine's Connection pool. That makes
> me very upset because this was something that Craig promised would
> not happen (that there wouldn't be much major duplication in Struts
> as in Turbine).
>
> Even Cocoon uses Turbine's Connection pool and we put a lot of effort
> into making a build target for Turbine that allows you to only build
> the turbine-pool.jar.

Not so fast.

Cocoon1 uses a back level version of Turbine's Connection pool.  An
incompatible interface change was made in Turbine, and they have not kept
up.  See:

http://oss.software.ibm.com/developerworks/opensource/jakarta/proto35/xml-cocoon.html

Cocoon2 does not use Turbine's Connection Pool.  Take a peek at:

http://xml.apache.org/websrc/cvsweb.cgi/~checkout~/xml-cocoon/src/org/apache/cocoon/components/datasource/Attic/JdbcConnectionPool.java?rev=1.1.2.5&content-type=text/plain

I'm not sure why there isn't more reuse going on within Jakarta, but my
_theory_ is that the cost associated with versioning issues exceed the
costs associated with dual maintenance.

Interfaces need to be deprecated for a period of time before they are
removed.  This applies even to the simple movement of a constant from one
class to another.  See:

http://oss.software.ibm.com/developerworks/opensource/jakarta/proto35/jetspeed.html

Consumers of these interfaces need to take deprecation warning seriously.

Without some attention to versioning issues, any CPAN initiative would be
doomed.

- Sam Ruby


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: What is Avalon?

[Jon Stevens]

Peter, I don't know if you know this, but you are also CC'ing the same
address in your replies. You might not want to do that. :-)

Date: Thu, 01 Feb 2001 15:10:51 +1100
To: [EMAIL PROTECTED]
From: Peter Donald <[EMAIL PROTECTED]>
Subject: Re: What is Avalon?
Cc: <[EMAIL PROTECTED]>


on 1/31/01 8:10 PM, "Peter Donald" <[EMAIL PROTECTED]> wrote:

> Similar thou not 100% the same. Turbine more follows the JNDI/J2EE
> application level model. (ie grab the service from a central
> application-wide directory). Avalon is more focused on per component level.
> (ie components are mapped from global area to a local per component area
> which the component accesses). But other than that they are very similar ;)

Correct. Our goal was to provide a singleton manager to the currently
running Turbine application in a particular context. This allowed for an
easy implementation of a Global Cache Service...

>> Database Connection Pooling
>> Schedulers (ie: Java based cron with a RDBM's backend)
> 
> Theres possibly even more overlap than you think ;) We have
> Initializable/Disposable interface which IIRC are similar to Turbines
> interfaces. We also have the next-evolutions of many of original jserv
> interfaces/classes (Configuration etc).

Yep, we have those as well. :-)

> There is also similarities between
> many of the ideas except Avalon is a lil more general (ie we use Context a
> generalisation of RunData etc).

RunData is an object that is over 3 years old now...no really, I'm serious.
:-) I probably would have done it differently today. :-)

> There is other remarkable simularities and if you were to read the Avalon
> archives for last few weeks I have been advocating changes that would
> enable a TurbineKernel and TurbineApplication objects (so you could load
> independent apps into one turbine instance safely).

Hmm...I'm not sure that is really needed, but cool anyway.

> So you could say I
> think in a turbine-esqu way ;)

That makes me happy. :-)

> yer thats where the problem is. The only production level stuff is either
> solely based on the "framework" part or using ancient versions of the kernel.

Part of Sam's complaint. :-)

> yep thats an alternative. It was just that Sam complained about this a
> while back with respect to tinderbox and nesting of projects.
> 
> It could also cause more issues because we could have cornerstone relying
> on version 3.1.1 of avalon, 3.2a of phoenix and actually being 3.2beta
> itself. The only way we could fix this is to store versioned jars in CVS
> (no biggue for me) and put in gratutous documentation stating that you can
> not copy /avalon/dist/lib/avalonapi.jar to /phoenix/lib/avalonapi.jar and
> expect it to work as they are on completely different release schedules.
> This could add a fair bit of confusion during building and attracting more
> developers.

I hear you.

> That would be fine if they were different versions of the one product.
> However they are different products that just happen to be part of the same
> project ;) each having different release schedules. I guess it would be
> similar to some think like
> 
> jakarta-avalon (or perhaps jakarta-framework) == c std library
> jakarta-phoenix == linux kernel
> jakarta-cornerstone == linux kernel modules

Ok, then in this case, I would prefer it to be:

jakarta-avalon
jakarta-avalon-phoenix
jakarta-avalon-cornerstone

-jon


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: What is Avalon?

[Peter Donald]

At 10:18  31/1/01 -0500, Sam Ruby wrote:
>Now, here's a loaded question: which of these is Cocoon2 using?  The reason
>that I ask is that when I was trying to get my tinderbox off the ground, I
>did not like the answer that the APIs were subject to change without
>concern to providing backwards compatibility; and what I really didn't like
>was the suggestion that Cocoon2 not track to the changes.

Cocoon was using jakarta-avalon which should be relatively stable. The
reason cocoon2 didn't track it was because we never had an interim release
as the remaineder (cornerstone and phoenix) was no where near releasable
quality. If we were to split things up it would make it much easier for
Cocoon2 (and myrmiddon if it adopted as Ant2) to track changes.

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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: What is Avalon?

[David Weinrich]

- Original Message -
From: "Jon Stevens" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, January 31, 2001 19:41
Subject: Re: What is Avalon?


...
> We have some overlap in functionality in Turbine, but that is ok. At some
> point, I'm sure we will be working together.
>
> Overlap:
> StringUtils
> Cascading Exceptions
> Services (if what you mean by this is a singleton framework, then that
> is what we are duplicating.)
> Database Connection Pooling
> Schedulers (ie: Java based cron with a RDBM's backend)
>
...

With the recent discussions about tinderbox/CJAN and related stuff, I have
started wondering about the cases where multiple jakarta projects have areas
of overlap/duplication. From digging into struts for a very short time I
notice that it also has a Database Connection Pooling component and some
string utilities ( I don't know if the string utilities are related in any
way to Avalon or Turbine ). That makes for three projects that implement the
same or very similar things.

  The ( possibly naive ) question that comes to my mind is: would it be
beneficial to take certain aspects of these projects that share the same
goals or produce libraries with the same or similar functionality and create
a repository of tools that each do one thing ( or maybe two ) and do them
very very well. One project that comes to mind is log4j, which recently
joined jakarta. It focuses on one specific task, logging, and it does it
extremely well.

  In my mind this issue is very close to how I see something that will
hopefully someday become CJAN: a place where people can find the specific
java libraries/tools that they need. I know that a few times in the recent
past I have looked for things similar to JDBC pooling and something similar
to cron for java and found what is available is scattered about on
individual websites. The ability to present developers with a trusted source
of high quality and very focused components could only enhance the java
community as a whole and bring new voices/minds/ideas into the
jakarta/apache community.

David


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: What is Avalon?

[Jon Stevens]

on 1/31/01 6:12 PM, "Peter Donald" <[EMAIL PROTECTED]> wrote:

> Hi,
> 
> "What is Avalon?" is a question I often hear - quickly followed up with
> "Why should I use it?". To the first question I usually answer
> 
> Avalon is;
> 1. A repository of general utility code (CLI parsing, cascading exceptions,
> StringUtils, etc)
> 2. A repository of patterns and framework code (ie component lifecycle code
> and mamanagement code - think loggign, configuring Startable, Stoppable
> Suspendable, Reesumable)
> 3. A set of general utility code based on (2) that offers "doing" code and
> extended patterns. (ie object pooling, thread management, classloader
> management, policy management, utility classes that "run" components
> lifecycle, Container-Component patterns and implementations,
> Kernel-Application-Component patterns and implementation).
> 4. A micro kernel for running services
> 5. A set of services that are orientated towards server environments (ie
> SocketFactories, ConnectionManagers, Schedulers etc)

We have some overlap in functionality in Turbine, but that is ok. At some
point, I'm sure we will be working together.

Overlap:
StringUtils
Cascading Exceptions
Services (if what you mean by this is a singleton framework, then that
is what we are duplicating.)
Database Connection Pooling
Schedulers (ie: Java based cron with a RDBM's backend)

> After hearing this they look at it and goes - is good but is alpha - call
> me when it's beta ;) It is then I explain that (2) can be considered
> largely stable and fixed, (1) and (3) usually are added to and would be
> considered beta-stable. The only components that are alpha would be part of
> (3), (4) and (5).

Funny thing is that I hear the same types of things about Turbine and also
have a lot of the same responses . However, in Turbine, most of the
code overlap is NOT alpha or even beta quality code, but production level
code that *is* being used in production environments.

> And even within in that there are distinctions. ie The client interface to
> the kernel in (4) is stable but the actuall kernel implementation is not.
> (Consider this the same as difference between servlet and servlet engines).
> 
> So recently we voted and decided that we want to release the different
> components on different schedules. We have three basic components
> 
> avalon (1)->(3) (Thou eventually (1) should move to it's own project ala AUT)
> phoenix (4)
> cornerstone (5)
> 
> That can stand on their own and have varying release schedules and degrees
> of stability. Initially you may look at it and say that cornerstone is not
> separate enough from phoenix to be worthy of a different release schedule
> and there is not enough content in it. I initially tended to agree but
> there is indications that soon (post valentines day) there will be a surge
> in the number of core services offered and there will be enough for it to
> have a separate release schedule.

Sounds good.

> At this point it may seem like it would be a good idea to ask the PMC to
> split the project into multiple sub-projects. However I would tend to
> disagree. The same people are developers for all three sections and it
> would be dividing too many resources. Maybe in the future it may be
> advisable to do this but it is not the future yet ;)

I agree. Keep them in one place.

> So we would like to split the CVS into three separate subprojects/subCVSes
> (jakarta-cornerstone, jakarta-avalon and jakarta-phoenix). This would allow
> us to safely have different release schedules and would give a sense of
> stability to those who just want to use the jakarta-avalon component. It
> would also force us to stabilize faster as we wouldn't be able to as easily
> intermingle changes ;)

I don't think that you have to have different CVS trees to accomplish this
at all. You can simply have your Ant build scripts generate the appropriate
releases.

./cornerstone.xml
./avalon.xml
./phoenix.xml

> So in summary what we would like to do is have three deliverables within
> the same project. Namely;
> 
> jakarta-avalon (Beta->STABLE)
> jakarta-phoenix (Alpha->Beta)
> jakarta-cornerstone (Alpha)

That is fine, but I think you should call them all Avalon and make them
named releases. Otherwise, you are going to have mad (cow  ?)
confusion on our already confused user base.

Avalon (Cornerstone release)
Avalon (Phoenix release)
Avalon (Final release)

This would be similar to how companies like Redhat name their distributions.

-jon


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: What is Avalon?

[Sam Ruby]

Peter Donald wrote:
>
> So we would like to split the CVS into three separate
> subprojects/subCVSes (jakarta-cornerstone, jakarta-avalon
> and jakarta-phoenix). This would allow us to safely have
> different release schedules and would give a sense of
> stability to those who just want to use the jakarta-avalon
> component. It would also force us to stabilize faster as
> we wouldn't be able to as easily intermingle changes ;)

One thing we discussed immediately prior to the PMC (and therefore not in
the minutes) was the possibility of encouraging the use of directories
instead of propagating multiple trees.  So instead of a jakarta-tomcat-40
and a jakarta-tomcat-41, there would be a jakarta-tomcat with a separate
subdirectory for each release.

With such a structure, one still has the ability to only checkout or update
the portions that you are interested in.

This is not much different than what tomcat-40 or even taglibs are doing
with multiple projects under a single top level directory.

> So in summary what we would like to do is have three
> deliverables within the same project. Namely;
>
> jakarta-avalon (Beta->STABLE)
> jakarta-phoenix (Alpha->Beta)
> jakarta-cornerstone (Alpha)

Given the experience we had with Tomcat, I would discourage you from naming
one of the submodules avalon as there will still be the temptation to refer
to the whole as avalon.

Now, here's a loaded question: which of these is Cocoon2 using?  The reason
that I ask is that when I was trying to get my tinderbox off the ground, I
did not like the answer that the APIs were subject to change without
concern to providing backwards compatibility; and what I really didn't like
was the suggestion that Cocoon2 not track to the changes.

- Sam Ruby


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: What is Avalon?

[Sam Ruby]

Peter Donald wrote:
>
> Cocoon was using jakarta-avalon which should be relatively stable.

Cool.  I plan to hold you to it.  ;-)

> It was just that Sam complained about this a while back with
> respect to tinderbox and nesting of projects.

I did complain about it, but my issue is not related to tinderbox.  My
complaint was actually related to the issue that you are trying to address
- putting the servlet engine and the JSP engine in the same repository is a
bit inconvenient for someone who wants only one or the other.

> jakarta-cornerstone (Alpha)

Normally I don't complain much about names, but it would seem a bit weird
to me to name a subproject jakarta-cornerstone when it is the one least
likely to be dependended upon by other jakarta subprojects in the near
term.

- Sam Ruby


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: What is Avalon?

[Peter Donald]

At 07:41  31/1/01 -0800, Jon Stevens wrote:
>We have some overlap in functionality in Turbine, but that is ok. At some
>point, I'm sure we will be working together.
>
>Overlap:
>StringUtils

Actually I think there is credits of a Turbine developer in our StringUtils
(I snagged it as a commit went by ;-])

>Cascading Exceptions
>Services (if what you mean by this is a singleton framework, then that
>is what we are duplicating.)

Similar thou not 100% the same. Turbine more follows the JNDI/J2EE
application level model. (ie grab the service from a central
application-wide directory). Avalon is more focused on per component level.
(ie components are mapped from global area to a local per component area
which the component accesses). But other than that they are very similar ;)

>Database Connection Pooling
>Schedulers (ie: Java based cron with a RDBM's backend)

Theres possibly even more overlap than you think ;) We have
Initializable/Disposable interface which IIRC are similar to Turbines
interfaces. We also have the next-evolutions of many of original jserv
interfaces/classes (Configuration etc). There is also similarities between
many of the ideas except Avalon is a lil more general (ie we use Context a
generalisation of RunData etc). 

There is other remarkable simularities and if you were to read the Avalon
archives for last few weeks I have been advocating changes that would
enable a TurbineKernel and TurbineApplication objects (so you could load
independent apps into one turbine instance safely). So you could say I
think in a turbine-esqu way ;)

>Funny thing is that I hear the same types of things about Turbine and also
>have a lot of the same responses . However, in Turbine, most of the
>code overlap is NOT alpha or even beta quality code, but production level
>code that *is* being used in production environments.

yer thats where the problem is. The only production level stuff is either
solely based on the "framework" part or using ancient versions of the kernel.

>> So we would like to split the CVS into three separate subprojects/subCVSes
>> (jakarta-cornerstone, jakarta-avalon and jakarta-phoenix). This would allow
>> us to safely have different release schedules and would give a sense of
>> stability to those who just want to use the jakarta-avalon component. It
>> would also force us to stabilize faster as we wouldn't be able to as easily
>> intermingle changes ;)
>
>I don't think that you have to have different CVS trees to accomplish this
>at all. You can simply have your Ant build scripts generate the appropriate
>releases.
>
>./cornerstone.xml
>./avalon.xml
>./phoenix.xml

yep thats an alternative. It was just that Sam complained about this a
while back with respect to tinderbox and nesting of projects. 

It could also cause more issues because we could have cornerstone relying
on version 3.1.1 of avalon, 3.2a of phoenix and actually being 3.2beta
itself. The only way we could fix this is to store versioned jars in CVS
(no biggue for me) and put in gratutous documentation stating that you can
not copy /avalon/dist/lib/avalonapi.jar to /phoenix/lib/avalonapi.jar and
expect it to work as they are on completely different release schedules.
This could add a fair bit of confusion during building and attracting more
developers.

>> So in summary what we would like to do is have three deliverables within
>> the same project. Namely;
>> 
>> jakarta-avalon (Beta->STABLE)
>> jakarta-phoenix (Alpha->Beta)
>> jakarta-cornerstone (Alpha)
>
>That is fine, but I think you should call them all Avalon and make them
>named releases. Otherwise, you are going to have mad (cow  ?)
>confusion on our already confused user base.
>
>Avalon (Cornerstone release)
>Avalon (Phoenix release)
>Avalon (Final release)
>
>This would be similar to how companies like Redhat name their distributions.

That would be fine if they were different versions of the one product.
However they are different products that just happen to be part of the same
project ;) each having different release schedules. I guess it would be
similar to some think like

jakarta-avalon (or perhaps jakarta-framework) == c std library
jakarta-phoenix == linux kernel
jakarta-cornerstone == linux kernel modules


Cheers,

Pete

*--*
| "Computers are useless. They can only give you   |
|answers." - Pablo Picasso |
*--*

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]