Re: Backing out...(was: Re: What is Jakarta?)

2001-02-11 Thread Jan-Henrik Haukeland

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]
 
 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? 

-- 
Jan-Henrik Haukeland

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




Re: Backing out...(was: Re: What is Jakarta?)

2001-02-11 Thread Sam Ruby

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 strikes me as particularly ironic.  For those who care,
http://www.sf.co.yu/science/hitchh4.htm .

Meanwhile, I will readily agree that Jon is at times - OK, quite frequenty;
oh, all right, pretty much all of the time - is a pain in the ass.  But it
is also important to realize that without him being exactly the way he is,
this little community that we all are a part of quite possibly wouldn't be
here.

And Tomcat 3.3 probably wouldn't have a ratified release plan or nearly as
many volunteers to support it.  Nor would we be aware of the extent of the
overlap between the various subprojects.

Whether everyone here realizes it or not, we get a lot of benefit from Jon
being here.  It just is a shame that more people don't take the effort to
return the favor sometimes.

- Sam Ruby


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




Re: Backing out...(was: Re: What is Jakarta?)

2001-02-11 Thread cmanolache

 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]




Re: Backing out...(was: Re: What is Jakarta?)

2001-02-11 Thread Jon Stevens

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 PMC level decisions.

-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]




Re: What is Jakarta?

2001-02-08 Thread Rodney Waldhoff

A little backstory on the connection pooling mechanism I submitted to Struts 
a while back:

A couple of months ago, at the company I work for we ran into problems with 
the connection pooling implementation within the commercial product we were 
using.  Specifically, (a) the pool itself was buggy and (b) the pool 
implementation made it difficult for us to pool PreparedStatements and the 
parse rate of unpooled PreparedStatements within the database was becoming a 
bottleneck to application performance.  For this reason I put together a 
Connection/PreparedStatement pooling implementation that met our needs.

Completely independently, I noticed the Struts project on 
jakarta.apache.org, started to poke around a bit, and subscribed to 
struts-dev and struts-user.  I noticed that Struts had a basic connection 
pooling implementation.  I also noticed several requests on struts-dev and 
struts-user looking to expand the functionality on the Struts connection 
pool.  Many of the features (in fact all of the features) that were being 
asked for were/are features of the Connection/PreparedStatement pool I put 
together.  So, I repackaged my code as org.apache.struts.*, and submitted it 
to the list.

This is the way open source development is supposed to work, no?  I had an 
itch, I scratched it.  I noticed others had the same itch, so I offered it 
up.

Now, unbeknownst to me, the Turbine project over at java.apache.org also has 
a connection pooling library with similar functionality.  Maybe it's my 
fault for not knowing this.  Maybe it's the struts-dev folk’s fault (sorry 
guys) for failing to mention that there is a connection pooling library in 
Turbine over at java.apache.org.  Maybe it's Apache's fault for not 
providing a clear picture of what is available and where.  Maybe it doesn't 
matter anyway because I think my pool is better designed, easier to 
maintain, or more feature rich than the existing one, in which case I think 
it's up to the community to decide which implementation they'd like to use. 
(And before we go off on a a holy war here, I'm not saying that I do think 
that.  I'm specifically not saying that one impl is better or worse than the 
other. Not having looked at the Turbine stuff in detail, I'm in no position 
to state that.  I'm just saying that that is a valid position to take.  It 
could be wrong (in the eyes of the community) but it's not unreasonable.)

Jon's response to this, when brought up in a slightly different context, was 
a bit off-putting:

  Meanwhile, I do think there would be a lot of interest in a Jakarta
  connection pool. In fact, someone has offered to donate one to Struts.
http://marc.theaimsgroup.com/?l=struts-devm=97967619230491 

Totally friggen lame.

*All* of that code (and more) is already implemented in Turbine and can be
used outside of the core "Turbine" system very easily.

If all of that functionality is available in Turbine, that makes it 
*redundant*, not lame.  Moreover, having poked around a bit in the Turbine 
stuff (and granted, I didn't poke that hard or that long, so maybe I missed 
it), it seems to me that not "all of that code is already implemented in 
Turbine".  Specifically, (a) I don't see that Turbine is doing any pooling 
of PreparedStatements, which if you recall was the major itch I was trying 
to scratch, (b) Turbine's Connection pool seems to require specific 
references to TurbineDB--so that legacy code has to be retrofitted to work 
with Turbine's pool, (c) Turbine's pool doesn't seem to support a 
javax.sql.DataSource interface.  Could Turbine's pool be modify to support 
these things? Of course, but I wasn't aware of Turbine's pool when I first 
submitted mine.  Moreover, Jon's response doesn't make me feel like my 
contribution is very welcome there.

Frankly, there seems to be some underlying Turbine vs. Struts politics here 
that I don't want to get involved in.  If you'd like to debate the merits of 
one pooling implementation versus another, or to work to see the full suite 
of functionality implemented in a single pooling library, or perhaps to 
debate whether or not more than one pool implementation is warranted, then 
let's do so.  But I don't think a knee-jerk response like that does much 
more than alienate 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 Message-
From: Steve Downey [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, February 07, 2001 4:23 PM
To: '[EMAIL PROTECTED]'
Subject: RE: What is Jakarta?


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 PR

RE: What is Jakarta?

2001-02-08 Thread Theo Keyzer

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 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.

Theo




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




RE: What is Jakarta?

2001-02-08 Thread Sam Ruby

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 run JetSpeed and Coocoon today on the same web server, I
would have to statically apportion my database connections between the two.
Add Struts into the mix and I must further subdivide.

Overall, I'm not overly concerned if we have multiple XML mappers.
Arguably it would be better if we didn't, but on the other hand a little
duplication sometimes removes the requirement for a lot of coordination.
In other words, if this is an itch that somebody wants to scratch, I would
encourage them to do so, but if not, I wouldn't want to mandate it from
above.

- Sam Ruby


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




RE: What is Jakarta?

2001-02-06 Thread Morgan Delagrange


--- 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
 Jakarta Project. As
 it stands, the current mission given on the Web site
 is technically
 incorrect. If we want a broader scope, it's obvious
 that the ASF will
 require a board resolution to put things right. 

From Sam's comments, it seems pretty clear that he'd
rather expand the scope than start pruning
subprojects.

 If you make the definition of Jakarta this
 restrictive
 
 Jakarta's charter is * already * that restricted.
 The contract between
 the ASF and the Jakarta PMC reads that Jakarta is
 "charged with the
 creation and maintenance of open-source Java
 Servlet-related software
 for distribution at no charge to the public." 

Agreed, many Jakarta projects are currently out of
scope according to the current charter.

 As you pointed out,  the Jakarta PMC has exceed its
 original charter.
 The ASF board chairman has raised an exception, and
 presented two
 alternatives: (1) A broader charter or (2) More
 PMCs. 
 
 Some people seem to like the idea of a broader
 charter. Other people
 have said they don't. I'm just suggesting that as a
 followup to Roy's
 suggestion (2) that we consider whether chartering
 Java-Apache for the
 out-of-scope projects makes any sense. 

Thanks to Jon for clarifying the deprecation of the
java.apache.org domain.  The current Jakarta site
states:

  The older Java Apache Project will have its 
  projects merged into the Jakarta Project 
  in the near future (no set date). For more 
  information please see the announcement on that
  website. 

If this is still the case, fine.  If not, we need a
new plan of action, since clearly java.apache.org
needs to go away.

 Really, if you limit the scope of the Jakarta
 project to Servlet-based
 technologies, the list of in-scope projects is very
 short:
 
 But, is that a bad thing?

It's too specific.  See next comment.

 projects like Slide and Struts, which only deal
 with servlets in part
 
 I can't vouch for Slide, but Struts is definately
 Java Servlet-related
 software.

I didn't say there weren't servlet-related components
in Struts, I'm saying there's a lot more in Struts
than servlet stuff; hence you can easily argue that
Struts is not entirely in-scope.  Much of Struts deals
with servlets, but Struts also provides frameworks for
XML parsing and database pooling, correct?  Since
these are not specifically servlet-related, they would
have to be removed from the project.

I'm not arguing for Jakarta becoming the one giant
Java project, I'm just saying that a Servlet-oriented
charter is too inflexible.  I'd rather see a charter
that focuses on Java servers and related tools (and I
think Ant in particular may not fit, but that's
another argument).

- Morgan


=
Morgan Delagrange
Britannica.com

__
Do You Yahoo!?
Yahoo! Auctions - Buy the things you want at great prices.
http://auctions.yahoo.com/

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




RE: What is Jakarta?

2001-02-06 Thread Ceki Gülcü

At 16:01 06.02.2001 -0500, you wrote:
On 2/6/2001 at 9:13 PM Ceki Glc 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 PMC.

 What decisions does the PMC take? 

Part of the problem is that the ASF PMC's are a recent invention, so no
one is entirely sure how they should work

We are working on that as part of the update to the guidelines at 
http://jakarta.apache.org/site/proposal.html#management .

Thanks for the link. Here is an excerpt from that document:

 Responsibilities of the PMC include:

 - the active discussion of Project issues, strategic direction, and forward progress, 
 
 - the consideration and approval of new subprojects, 
 
 - retiring inactive subprojects and Committers as necessary, 
 
 - arbitrating otherwise intractable disputes regarding subproject voting and vetos, 
 
 - the security and reliability of the Project's Web site, mailing
 lists, code repositories, and related services,

 - legal issues involving the Project and its subprojects, and 
 maintaining Project and subproject scope as chartered by the ASF corporation 


As I understand it, the main responsibility of the PMC is to decide whether to include 
a sub-project under the Jakarta label and possibly act as an arbitrator in case of 
conflicts within a sub-project. There is also the task of managing the Jakarta 
web-site + mailing lists but that is probably less strategic a task (read: a chore). :)

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



Ceki Glc   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 Jakarta?

2001-02-06 Thread Jon Stevens

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 to the same DBMS, but they would not usually want to
 connect to the same database using the same login.

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 Turbine provides. Eventually, someone will come along to the
Struts project who needs this functionality and it will get re-implemented
yet again.

 Meanwhile, I do think there would be a lot of interest in a Jakarta
 connection pool. In fact, someone has offered to donate one to Struts.
 
  http://marc.theaimsgroup.com/?l=struts-devm=97967619230491 

Totally friggen lame.

*All* of that code (and more) is already implemented in Turbine and can be
used outside of the core "Turbine" system very easily.

 Perhaps the thing to do would be to circulate a Request for Proposal to
 the subprojects that might use database connections, and see what we
 get back. 

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.

It really disappoints me that Craig and the Struts project have completely
ignored the fact that they said he wouldn't compete with Turbine and would
instead work with us instead of re-implementing everything...instead, now we
have a war of duplication between Turbine and Struts.

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. It will be up to our user base to choose
the one they prefer and the amount of lower level duplication will continue
to grow until someone wakes up and realizes that this code can be
generalized into another project...

But, I'm not going to start working on that other project until I can get
agreement and proof that Struts community will contribute to the project
because so far, they have refused to contribute to Turbine which is the
project they are duplicating...

Sigh.

-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]