on 2/11/01 7:31 AM, "Jan-Henrik Haukeland" <[EMAIL PROTECTED]> wrote:
> You're not only a pain in the ass Jon, but an inconsistent pain in the
> ass. What's the point in saying goodbye and then keep on posting?
Go back and read my email again.
What I said is that I was not going to take part in
> And Tomcat 3.3 probably wouldn't have a ratified release plan or nearly as
> many volunteers to support it.
+1.
Costin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Sam Ruby wrote:
>
> Jan-Henrik Haukeland wrote:
> >
> > > So long and thanks for all the fish.
> >
> > You're not only a pain in the ass Jon, but an inconsistent pain
> > in the ass. What's the point in saying goodbye and then keep on
> > posting?
>
> I admit that I have a history of being obtus
Jan-Henrik Haukeland wrote:
>
> > So long and thanks for all the fish.
>
> You're not only a pain in the ass Jon, but an inconsistent pain
> in the ass. What's the point in saying goodbye and then keep on
> posting?
I admit that I have a history of being obtuse, but the above sequence of
words st
Jon Stevens <[EMAIL PROTECTED]> writes:
[*]
> Anyway, my point being that I'm really getting tired of being misread,
> misunderstood and being considered the general pain in the ass around here.
> My being here isn't helpful for me and it certainly isn't helpful for the
> community.
[elegy]
>
> > What's wrong with having multiple thread pools or db pools, each
> > having special characteristics and working best in different situations ?
>
> That it requires a special effort to find out which one fits your project
> best. The classical problems of reuse multiply: it's not only fetch a
Peter Donald typed the following on 03:42 PM 2/9/2001 +1100
>At 07:33 8/2/01 -0800, [EMAIL PROTECTED] wrote:
>>Even in CPAN, you can have multiple modules doing similar tasks, each with
>>it's own API. And you have modules depending on other modules.
>
>Then again it is just a component repositor
Hi folks! I hope you don't mind an "outsider" (with little-to-no experience in
OpenSource) contributing to this interesting thread.
[EMAIL PROTECTED] wrote:
> What's wrong with having multiple thread pools or db pools, each
> having special characteristics and working best in different situation
At 07:33 8/2/01 -0800, [EMAIL PROTECTED] wrote:
>> >That's the key - "plug compatible". But we are in java, and writing a
>> >simple adapter should be very easy. Adapters don't add so much complexity.
>>
>> The question is that if we have plug-compatability then what is the point
>> of having mu
On 2/8/01 5:46 PM, "Jon Stevens" <[EMAIL PROTECTED]> wrote:
>
> [...]
> Anyway, my point being that I'm really getting tired of being misread,
> misunderstood and being considered the general pain in the ass around here.
> My being here isn't helpful for me and it certainly isn't helpful for the
> >That's the key - "plug compatible". But we are in java, and writing a
> >simple adapter should be very easy. Adapters don't add so much complexity.
>
> The question is that if we have plug-compatability then what is the point
> of having multiple implementations? (besides keeping massive scala
Jon Stevens wrote:
>
> > Thought experiment: name this subproject dash
>
> Funny. That was the original name of Turbine. Did you
> choose that on purpose?
I guess I was too oblique if even you didn't get my reference. There's
talk about creating a utility project which will contain a number of
c
on 2/8/01 5:28 AM, "Sam Ruby" <[EMAIL PROTECTED]> wrote:
> Thought experiment: name this subproject dash
Funny. That was the original name of Turbine. Did you choose that on
purpose?
> Fast forward six to twelve months. Where do you think you will be? For
> insight on where I think you will b
At 04:48 8/2/01 -0800, [EMAIL PROTECTED] wrote:
>> Costin Manolache wrote:
>> >
>> > What's wrong with having multiple thread pools or db pools, each
>> > having special characteristics and working best in different
>> > situations ?
>>
>> Different, plug compatible, db pools would be great.
>
>
> Costin Manolache wrote:
> >
> > What's wrong with having multiple thread pools or db pools, each
> > having special characteristics and working best in different
> > situations ?
>
> Different, plug compatible, db pools would be great.
That's the key - "plug compatible". But we are in java, an
> Fact: CPAN works. And it is exactly that, "neutral shared utility".
As a long-time perl programmer this has been my biggest complaint about the
Java community that there really is no cohesion outside of the individual
projects. Ask any Perl hack, CPAN is the best thing since sliced bread.
Thes
On 2/8/2001 at 8:28 AM Sam Ruby wrote:
>Thought experiment: name this subproject dash.
>Fast forward six to twelve months.
>Where do you think you will be?
How about someplace like here? - http://husted.com/about/jakarta/dash
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Soft
Costin Manolache wrote:
>
> What's wrong with having multiple thread pools or db pools, each
> having special characteristics and working best in different
> situations ?
Different, plug compatible, db pools would be great.
Having each project early bind to a specific one is not.
If I wanted to
IL PROTECTED]>
> To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
> Subject: RE: What is Jakarta?
> X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N
>
> Thursday, February 08, 2001 10:29 AM GOMEZ Henri wrote:
> > I'm +1 with Arieh Markel abo
> How do you make the tools so that they don't tie
> into applications too closely, or become
> sub-applications - not needed to build any Jakarta project.
> Or can they if they are still add on tools for a Jakarta package.
By not allowing any external dependency, and keeping each module
specia
>
> Unfortunately, there is no such thing as a "neutral shared utility".
Fact: CPAN works. And it is exactly that, "neutral shared utility".
If it is possible to do it for perl ( where everything can be done in many
ways - by design ), it should be possible in Java ( OO, etc ).
> Fast forward
Thursday, February 08, 2001 10:29 AM GOMEZ Henri wrote:
> I'm +1 with Arieh Markel about
>
> . Jakarta Base Network Utilities
> . Jakarta Base JSP Utilities
> . Jakarta XML Utilities
> . Jakarta SMTP Utilities
> . Jakarta Tools
How do you make the tools so that they don't tie
into applications to
Kief Morris wrote:
>
> When one subproject "owns" a utility, that subproject's
> requirements and design philosophy are going to override
> the needs of other projects, no matter how good their
> intentions. Better to have a neutral shared utility,
> which individual subprojects can extend to meet
Ted Husted typed the following on 04:29 PM 2/7/2001 -0500
>1. We have a shared utility subproject that would host an assortment of
>components.
I favor this approach especially if components can be easily pulled out and
used, e.g. different .jar files for the connection pool, etc. Perhaps existi
On 2/8/2001 at 12:53 AM Rodney Waldhoff wrote:
> I'm of no particular opinion whether this is best done as a single
> project or a bunch of little independent projects, although I suspect
> a single project with lots of pieces will be easier to standardize
for
> documentation, structure, etc.
ienate potential developers.
I was going to segue this into a discussion of how a more modular
utility/services/library project or set of projects is warranted, but I see
that Morgan and Ted have already kicked that off in earnest, so I'll follow
up in that thread.
- Rod
-Original Mess
ions.
- Rod
-Original Message-
From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, February 07, 2001 4:27 PM
To: [EMAIL PROTECTED]
Subject: Re: What is Jakarta?
Ted Husted wrote:
>
> I would frame it this way:
>
> 1. We have a shared utility subproject tha
>
> Turbine is a servlet based framework that
> allows experienced Java developers to quickly
> build secure web applications.
That text deserve Turbine. I was looking some time
ago for a generic cache system and a connection pool
to be use outside a webapp, but the title make
me search e
>
> My mistake, although stating that you have a database
> connection pool component does not imply that it is
> applicable outside of Turbine.
>
Hey man, Coccon 1.8 uses Turbine's connection poll. The package name is
turbine-pool.jar. Just extract the jar from the distribution and use it.
And
It may not be easier, but it's certainly more fun. And it often seems easier
to build to suit than to adapt something.
-Original Message-
From: Jon Stevens [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, February 07, 2001 3:24 PM
To: [EMAIL PROTECTED]
Subject: Re: What is Jakarta?
o
Ted Husted wrote:
>
> I would frame it this way:
>
> 1. We have a shared utility subproject that would host an assortment of
> components.
>
> 2. We have a subproject for each component.
>
> 3. Each subproject may host a utility library, which other subprojects
> can use.
>
> (1) or (2) are g
I would frame it this way:
1. We have a shared utility subproject that would host an assortment of
components.
2. We have a subproject for each component.
3. Each subproject may host a utility library, which other subprojects
can use.
(1) or (2) are going to depend on whether anyone has an itc
I think we've pretty much worn out this thread. With
regard to database pools, the options seem to be:
1) Everybody does their own thing.
2) Everybody uses the Turbine pooling.
3) Everybody uses the Struts pooling.
4) We create a new utilities subproject, with database
pooling is a sub-subprojec
Please turn off HTML email (how many times does that need to be repeated???)
on 2/7/01 12:30 PM, "Delagrange, Morgan" <[EMAIL PROTECTED]> wrote:
> Um, you're preaching to the choir. My whole point is that we should all use
> the same database pool, if possible. I think it's unfortunate that St
Title: RE: What is Jakarta?
Um, you're preaching to the choir. My whole point is that we should all use the same database pool, if possible. I think it's unfortunate that Struts and Turbine are not on the same page. My suggested approach is that we create a utilities subpr
on 2/7/01 12:15 PM, "Morgan Delagrange" <[EMAIL PROTECTED]> wrote:
> My mistake, although stating that you have a database
> connection pool component does not imply that it is
> applicable outside of Turbine.
You could ask a very simple question:
"Is Turbine's Connection Pooling code available
--- Jon Stevens <[EMAIL PROTECTED]> wrote:
> on 2/7/01 10:56 AM, "Morgan Delagrange"
> <[EMAIL PROTECTED]> wrote:
>
> > From their home pages, you wouldn't
> > even know that they featured database pooling.
>
> Absolute bullsh*t.
>
> The Turbine homepage *clearly* states:
>
> "The point of Tu
on 2/7/01 10:56 AM, "Morgan Delagrange" <[EMAIL PROTECTED]> wrote:
> From their home pages, you wouldn't
> even know that they featured database pooling.
Absolute bullsh*t.
The Turbine homepage *clearly* states:
"The point of Turbine is to collect that code into one location and make it
easy t
xtremely_
> stable out of the box. The equivalent of libc, or
> rt.jar. With _long_
> release cycles.
>
> Otherwise you couple the release cycles of unrelated
> systems in pathological
> ways.
>
> Or projects clone the code and hide it.
>
>
>
> -Origi
ase cycles.
Otherwise you couple the release cycles of unrelated systems in pathological
ways.
Or projects clone the code and hide it.
-Original Message-
From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, February 07, 2001 8:54 AM
To: [EMAIL PROTECTED]
Subject: Re: What
Ted Husted wrote:
>
> On 2/7/2001 at 12:09 AM Geir Magnusson Jr. wrote:
> > That's exactly what I am trying to say. I know I can't propose.
>
> You or I can't call for a vote of the PMC * on * a proposal, but
> absolutely anyone can submit a proposal for a subproject.
Ok. I read it that one of
There's been some talk on the General List about developing a Jakarta
connection pool product that other products could use as a utility.
Anyone interested in working on this should subscribe to the General
List to help determine the subproject's prospects.
Here's a recap.
On 1/31/01 8:53 PM, "D
On 2/6/2001 at 5:24 PM Jon Stevens wrote:
>However, what is missing (from everything BUT Turbine's
implementation) is a
>"Service" that would allow you to have multiple database connection
pools to
>multiple different backends with different login account settings.
This *is*
>something that Turbi
On 2/7/2001 at 12:09 AM Geir Magnusson Jr. wrote:
> That's exactly what I am trying to say. I know I can't propose.
You or I can't call for a vote of the PMC * on * a proposal, but
absolutely anyone can submit a proposal for a subproject.
As David Weinrich mentioned, a good place to start is an
> On Wednesday, February 07, 2001 5:57 AM Ted Husted wrote:
>
> On 2/6/2001 at 11:03 PM Geir Magnusson Jr. wrote:
> >I have no conclusion other than a misc utility project would be a good
> >thing to have, especially if we can get the major players to work out
> >their differences and actually use
Ted Husted wrote:
>
> On 2/6/2001 at 11:03 PM Geir Magnusson Jr. wrote:
> >I have no conclusion other than a misc utility project would be a good
> >thing to have, especially if we can get the major players to work out
> >their differences and actually use the thing. I volunteer to help in
> >an
On 2/6/2001 at 11:03 PM Geir Magnusson Jr. wrote:
>I have no conclusion other than a misc utility project would be a good
>thing to have, especially if we can get the major players to work out
>their differences and actually use the thing. I volunteer to help in
>any way needed.
The only thing I
On 2/6/2001 at 5:24 PM Jon Stevens wrote:
>As a result, I'm now creating an Essay titled "You make the decision."
that
>will explain in detail the differences on implementing a system based
on top
>of Struts+JSP and Turbine+Velocity.
An honest evaluation could be very helpful to the community. I
Ted Husted wrote:
>
> Jon :
>
> >No, the right direction would be to use the project which implemented
> this
> >code first and has the most complete solution and ask that project to
> >externalize their code in such a way that it could be used in other
> >projects. Oh wait. The Turbine Project
Jon,
>No, the right direction would be to use the project which implemented
this
>code first and has the most complete solution and ask that project to
>externalize their code in such a way that it could be used in other
>projects. Oh wait. The Turbine Project already did all of that work.
No o
on 2/6/01 5:04 PM, "Ted Husted" <[EMAIL PROTECTED]> wrote:
> I still don't quite get why this is such an issue. The efficiency of a
> pool comes from sharing connections that use the same login to the same
> database. It would be likely that Jetspeed, Turbine, and Struts may all
> want to connect
On 2/6/2001 at 6:37 PM Sam Ruby wrote:
> But I *do* care if each subproject hoards its own pool
> of database connections.
I still don't quite get why this is such an issue. The efficiency of a
pool comes from sharing connections that use the same login to the same
database. It would be likely
Ceki Gülcü wrote:
>
> My guess is that when all strictly sub-project related tasks
> are delegated to the committers, the PMC could fulfill its
> role even in the presence of many, say 10 to 20 sub-projects.
> Am I missing anything obvious? Cheers, Ceki
Not that I can tell.
Morgan Delagrange wro
On 2/6/2001 at 11:45 PM Ceki Gülcü wrote:
>My guess is that when all strictly sub-project related tasks are
delegated to the committers, the PMC could fulfill its role even in the
presence of many, say 10 to 20 sub-projects. Am I missing anything
obvious? Cheers, Ceki
Counting what's coming over
At 16:01 06.02.2001 -0500, you wrote:
>On 2/6/2001 at 9:13 PM Ceki Gülcü wrote:
>
>>What would be gained by refining the charter of Jakarta and pruning
>projects?
>
>Roy Fielding has indicated that some action is necessary. His two
>suggestions were to either ask the board to create additional PM
On 2/6/2001 at 9:13 PM Ceki Gülcü wrote:
>What would be gained by refining the charter of Jakarta and pruning
projects?
Roy Fielding has indicated that some action is necessary. His two
suggestions were to either ask the board to create additional PMCs, or
to broaden the scope of the existing PM
On 2/6/2001 at 8:39 PM Charles Benett <[EMAIL PROTECTED]>
wrote:
> I'm inclined to think it would be better to keep all the Apache
projects in Java together
Not entirely possible, since many of the XML projects are also Java
applications.
< http://xml.apache.org >
-- Ted Husted, Husted dot Com
On 2/6/2001 at 11:33 AM Morgan Delagrange wrote:
> Much of Struts deals with servlets, but Struts also provides
frameworks for XML parsing and database pooling, correct?
Only to the extent that they simplify working with the Struts
ActionServlet, which is the core of the framework.
> I'm not
Morgan Delagrange wrote:
>
> Hi Ceki,
>
> I don't think many of is are terribly concerned about
> the constitution of the PMC, as long as each
> subproject
> has at least some representation. However, maybe some
> of us really are concerned about that.
>
> More important to me is what _subpr
Hi Ceki,
I don't think many of is are terribly concerned about
the constitution of the PMC, as long as each
subproject
has at least some representation. However, maybe some
of us really are concerned about that.
More important to me is what _subprojects_ are under
the Jakarta umbrella, not what
I quickly read the "Board of Directors Meeting Minutes" of 16 September 1999. The
minutes indeed link Java Servlet software to Jakarta's charter. but isn't this just a
technicality?
What would be gained by defining a new PMC? Moreover, I thought that java.apache.org
was going to be merged in
--- Ted Husted <[EMAIL PROTECTED]> wrote:
> On 2/6/2001 at 11:26 AM Delagrange, Morgan wrote:
> >Right, but the Jakarta PMC chairman objects to that
> definition.
>
> I'm not sure if Sam Ruby has actually "objected" or
> not. It is evident
> that Roy Fielding has objected to the scope of the
>
on 2/6/01 4:32 AM, "Ted Husted" <[EMAIL PROTECTED]> wrote:
> Since Java-Apache has apparently never actually been charted by the
> ASF, why not ask the board go ahead and charter it like the recent PMCs
> for PHP, Perl, and TCL, e.g.
Lets nip this discussion in the bud. Java Apache (ie: java.apa
On 2/6/2001 at 11:26 AM Delagrange, Morgan wrote:
>Right, but the Jakarta PMC chairman objects to that definition.
I'm not sure if Sam Ruby has actually "objected" or not. It is evident
that Roy Fielding has objected to the scope of the Jakarta Project. As
it stands, the current mission given o
Morgan Delagrange wrote:
>
> In the interest of accuracy, I think your summary of
> the Jakarta project is a little narrow. If you look
> at the charter on the website, it states:
The problem is that the charter on the website does not currently match the
charter as set forward by the Apache boa
Title: RE: What is Jakarta?
Right, but the Jakarta PMC chairman objects to that definition. Sam would rather make the scope fit the project, rather than the project fit the new, much more restrictive scope. Right now, the Jakarta project does not fit its current scope, and I think that&#
On 2/6/2001 at 9:56 AM Delagrange, Morgan wrote:
>Specifically, Jakarta is _not_ limited to servlet-based technologies.
The wording is from the ASF board resolution:
<
http://apache.org/foundation/records/minutes/1999/board_minutes_1999_09_
16.txt >
I believe that this is the "charter" Roy Fie
Title: RE: What is Jakarta?
Hey Ted,
In the interest of accuracy, I think your summary of the Jakarta project is a little narrow. If you look at the charter on the website, it states:
The goal of the Jakarta Project is to provide commercial-quality
server solutions based on the Java
Since Java-Apache has apparently never actually been charted by the
ASF, why not ask the board go ahead and charter it like the recent PMCs
for PHP, Perl, and TCL, e.g.
" ... the Apache Java Committee be and hereby is responsible for the
creation and maintenance of software related to the Java
69 matches
Mail list logo
