Struts Connection Pool Maturity - Ted - you out there?
Is it ready for production yet? I've been using Poolman just fine, but would like to switch to the struts pool if it is at a maturity-level that would make that possible. I know Poolman is solid, but ideally I think everything would be centrally configured. Using the built-in pool would accomplish that. However, if it's at the same maturity-level as when I last checked, I think I'll keep right on using Poolman =) Ted? You out there? =D Thanks tons guys! Eddie
RE: Struts Connection Pool Maturity - Ted - you out there?
snip I've been using Poolman just fine, but would like to switch to the struts pool if it is at a maturity-level that would make that possible. Perhaps I misunderstanding something here? I would like to ask why Struts didn't just incorporate Poolman or Expresso's Connection pooling instead of developing another? i.e. Expresso's has been around since '96 and is certainly stable! It's an Apache Style license so the code is certainly open source compatible with Struts Apache license. This brings up for me a larger question I am not clear on What is Struts view on building on/integrating/contributing with third party open source projects and not reinventing wheels? With the shoe on the other foot we support other open source projects (including several Apache projects) by building on them and thus have an area in Expresso's CVS for third party libraries which is where Struts resides. This benefits the open source movement by making projects stronger and increasing mindshare and strengthening their acceptance as open standards. I'm sure you'll agree the Expresso community has contributed in positive ways to the Struts code and community. I look forward to hearing back. -- Sandra Cann http://www.jcorporate.com Open Standards based Java components Our separation from each other is an optical illusion of consciousness. (Albert Einstein) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Struts Connection Pool Maturity - Ted - you out there?
Interesting This doesn't compute for me. Should we Expresso NOT use Struts or any other Apache project because it is outside of our quality control? No of course not, because we know the collaborative comunity process is such that if we had an issue it would be addressed either by us contributing the fix or the core developers. The point of the matter is there is no mechanism within Apache to use third party open source tools. This is disheartening! By appearances Apache is interested in only code contributed to its Intellectual Property and will not support third party projects. What is more dishearterning to me is this: Considering that in March 2002 Apache was requesting an open and fair licensing scheme from Sun for developing Java standards isn't this hypocritical? Basically Apache is asking Sun to use third party open source projects in Java when Apache itself won't integrate other third party open source projects!!! I would like to propose that Apache should consider its own words and apply them to its own organization and also support third party open source projects that are worthy and are offered under an Apache Style or BSD license. Expresso has more than twice the community listserv size of Struts and has earned its recognition as a solid framework. Respectfully and disappointed -- Sandra Cann COO http://www.jcorporate.com Open Standards based Java components Our separation from each other is an optical illusion of consciousness. (Albert Einstein) -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Wednesday, April 24, 2002 4:49 PM To: Struts Users Mailing List Subject: RE: Struts Connection Pool Maturity - Ted - you out there? In the particular case of the Espresso connection pool, I didn't know about it at the time. In the particular case of Poolman, it has (well, now it is really had) a single developer instead of a community, and an LGPL license to boot. (Talk to RMS about why he says the Apache license is evil -- I'm not interested in getting involved in that discussion.) Feel free to integrate Struts into anything you like -- that is the fundamental value proposition of the Apache License. For the stuff packaged *inside* Struts, I'm personally more comfortable with Apache based code, where I know the other developers and the support culture around it. For outside code, given license compatibility and a willingness of others to support it (to *my* quality standards, since Struts is pretty closely associated with *my* name :-), I'm OK with it, but I'd usually rather just leave it out and let others provide integrated packages. (FWIW, in Struts 1.1 the GenericDataSource class is a wrapper around the commons-dbcp connection pool, which is also going to be used in Tomcat 4.1). Craig On Wed, 24 Apr 2002, Sandra Cann wrote: Date: Wed, 24 Apr 2002 16:04:33 -0400 From: Sandra Cann [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] Subject: RE: Struts Connection Pool Maturity - Ted - you out there? snip I've been using Poolman just fine, but would like to switch to the struts pool if it is at a maturity-level that would make that possible. Perhaps I misunderstanding something here? I would like to ask why Struts didn't just incorporate Poolman or Expresso's Connection pooling instead of developing another? i.e. Expresso's has been around since '96 and is certainly stable! It's an Apache Style license so the code is certainly open source compatible with Struts Apache license. This brings up for me a larger question I am not clear on What is Struts view on building on/integrating/contributing with third party open source projects and not reinventing wheels? With the shoe on the other foot we support other open source projects (including several Apache projects) by building on them and thus have an area in Expresso's CVS for third party libraries which is where Struts resides. This benefits the open source movement by making projects stronger and increasing mindshare and strengthening their acceptance as open standards. I'm sure you'll agree the Expresso community has contributed in positive ways to the Struts code and community. I look forward to hearing back. -- Sandra Cann http://www.jcorporate.com Open Standards based Java components Our separation from each other is an optical illusion of consciousness. (Albert Einstein) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Struts Connection Pool Maturity - Ted - you out there?
snip In the particular case of the Espresso connection pool, I didn't know about it at the time. I wrote Ted about using Expresso Connection pooling on 10/10/01. He responded that we could propose to contribute it to Commons. Sandra -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Struts Connection Pool Maturity - Ted - you out there?
I don't develop struts - I develop WITH struts =) ... so don't go holding apache liable for what I say. I'm just an independent developer that happens to like using Apache tools as often as possible. They typically talk the same language as I do and do things in a manner congruent with how I would have done them. Therefore, especially considering the price (!), I go with them whenever possible. I've looked at other things - I've used Poolman for a while now. What I want, because of the added ease of implementation/maintenance is a Struts connection pool that is production-capable. In Struts release 1.0.2, I was told the connection pool was not up to par and that Poolman was solid and dependable. I _like_ Poolman a lot, but would just as soon have one config file to deal with instead of three. Speaking of which - when is the tiles configuration data going to be incorerated into the struts config file? g I had no intention to start a flame-war with my post, and I appologize if I ruffled any feathers. Please be aware that I am in NO way connect with the struts development effort (other than that fact that I USE struts), and I hardly speak for them. My most humble appologies for starting this, Eddie - Original Message - From: Sandra Cann [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] Sent: Wednesday, April 24, 2002 3:04 PM Subject: RE: Struts Connection Pool Maturity - Ted - you out there? snip I've been using Poolman just fine, but would like to switch to the struts pool if it is at a maturity-level that would make that possible. Perhaps I misunderstanding something here? I would like to ask why Struts didn't just incorporate Poolman or Expresso's Connection pooling instead of developing another? i.e. Expresso's has been around since '96 and is certainly stable! It's an Apache Style license so the code is certainly open source compatible with Struts Apache license. This brings up for me a larger question I am not clear on What is Struts view on building on/integrating/contributing with third party open source projects and not reinventing wheels? With the shoe on the other foot we support other open source projects (including several Apache projects) by building on them and thus have an area in Expresso's CVS for third party libraries which is where Struts resides. This benefits the open source movement by making projects stronger and increasing mindshare and strengthening their acceptance as open standards. I'm sure you'll agree the Expresso community has contributed in positive ways to the Struts code and community. I look forward to hearing back. -- Sandra Cann http://www.jcorporate.com Open Standards based Java components Our separation from each other is an optical illusion of consciousness. (Albert Einstein) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Struts Connection Pool Maturity - Ted - you out there?
Ok, so I can move my data-source back into struts and acquire a reference to it by doing ... hrm ... I'll look it up =) Thanks - sorry for the ... commotion! Eddie - Original Message - From: Craig R. McClanahan [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] Sent: Wednesday, April 24, 2002 3:49 PM Subject: RE: Struts Connection Pool Maturity - Ted - you out there? In the particular case of the Espresso connection pool, I didn't know about it at the time. In the particular case of Poolman, it has (well, now it is really had) a single developer instead of a community, and an LGPL license to boot. (Talk to RMS about why he says the Apache license is evil -- I'm not interested in getting involved in that discussion.) Feel free to integrate Struts into anything you like -- that is the fundamental value proposition of the Apache License. For the stuff packaged *inside* Struts, I'm personally more comfortable with Apache based code, where I know the other developers and the support culture around it. For outside code, given license compatibility and a willingness of others to support it (to *my* quality standards, since Struts is pretty closely associated with *my* name :-), I'm OK with it, but I'd usually rather just leave it out and let others provide integrated packages. (FWIW, in Struts 1.1 the GenericDataSource class is a wrapper around the commons-dbcp connection pool, which is also going to be used in Tomcat 4.1). Craig On Wed, 24 Apr 2002, Sandra Cann wrote: Date: Wed, 24 Apr 2002 16:04:33 -0400 From: Sandra Cann [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] Subject: RE: Struts Connection Pool Maturity - Ted - you out there? snip I've been using Poolman just fine, but would like to switch to the struts pool if it is at a maturity-level that would make that possible. Perhaps I misunderstanding something here? I would like to ask why Struts didn't just incorporate Poolman or Expresso's Connection pooling instead of developing another? i.e. Expresso's has been around since '96 and is certainly stable! It's an Apache Style license so the code is certainly open source compatible with Struts Apache license. This brings up for me a larger question I am not clear on What is Struts view on building on/integrating/contributing with third party open source projects and not reinventing wheels? With the shoe on the other foot we support other open source projects (including several Apache projects) by building on them and thus have an area in Expresso's CVS for third party libraries which is where Struts resides. This benefits the open source movement by making projects stronger and increasing mindshare and strengthening their acceptance as open standards. I'm sure you'll agree the Expresso community has contributed in positive ways to the Struts code and community. I look forward to hearing back. -- Sandra Cann http://www.jcorporate.com Open Standards based Java components Our separation from each other is an optical illusion of consciousness. (Albert Einstein) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Struts Connection Pool Maturity - Ted - you out there?
On Wed, 24 Apr 2002, Sandra Cann wrote: Date: Wed, 24 Apr 2002 17:21:09 -0400 From: Sandra Cann [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] Subject: RE: Struts Connection Pool Maturity - Ted - you out there? Interesting This doesn't compute for me. Should we Expresso NOT use Struts or any other Apache project because it is outside of our quality control? No of course not, because we know the collaborative comunity process is such that if we had an issue it would be addressed either by us contributing the fix or the core developers. The point of the matter is there is no mechanism within Apache to use third party open source tools. Each Apache subproject lets the committers on that subproject make their own decisions on things like that. It's one of the nicer things about the Apache culture -- no pointy-haired-boss types mandating global policies on technical issues :-). Some Apache project teams take a much more liberal view of integrating third party stuff (Cocoon and Turbine come to mind). Others don't. Their choice. This is disheartening! By appearances Apache is interested in only code contributed to its Intellectual Property and will not support third party projects. What is more dishearterning to me is this: Considering that in March 2002 Apache was requesting an open and fair licensing scheme from Sun for developing Java standards isn't this hypocritical? Basically Apache is asking Sun to use third party open source projects in Java when Apache itself won't integrate other third party open source projects!!! That's not at all what happened ... what Apache negotiated for (and won) was the legal right to implement Java specifications -- both for ourselves and for any other open source organization that wants to -- and then prove (by passing the TCKs) that the implementations are spec-compliant. Formerly, this was not legally possible. It doesn't have anything to do with whether Sun (or anyone else) should or should not incorporate Apache code in Sun's products (which it does, by the way -- JAXP is now based on Xerces and Xalan, while Tomcat is used in both the J2EE RI and JWSDP). That is a separate business decision, made by the project teams for those products, on the usual build-or-buy decision approach - the same sort of decision process that you undoubtedly used in deciding to incorporate Struts support into Espresso. I would like to propose that Apache should consider its own words and apply them to its own organization and also support third party open source projects that are worthy and are offered under an Apache Style or BSD license. Apache's representative on the JCP executive committee has spent two years of pain (and a useful amount of Apache Software Foundation money on lawyer's fees) building consensus and arguing for ***your*** right to implement Java specs legally if you want to. We didn't just do it for ourselves. But that has exactly zero to do with where the code shipped with Apache packages itself originated, or whether somebody else includes Apache code or not. Expresso has more than twice the community listserv size of Struts and has earned its recognition as a solid framework. Respectfully and disappointed Why are you disappointed? I responded with a (clearly marked) *personal* opinion -- one of ten or so voices that count (the other committers). If others are willing to support an imported third party module, then that is fine. But I feel a personal moral obligation to Struts users that anything included in the official Struts distribution needs to be supported by the Struts developer community, no matter where the original code came from. As long as that's done, third party code is fine. -- Sandra Cann Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Struts Connection Pool Maturity - Ted - you out there?
Craig Thanks for all of the clarification - I'm relieved that there can be third party open source in Apache projects. :) I stand corrected. If others are willing to support an imported third party module, then that is fine. But I feel a personal moral obligation to Struts users that anything included in the official Struts distribution needs to be supported by the Struts developer community, no matter where the original code came from. As long as that's done, third party code is fine. Heck that's fair enough - we feel the same! i.e. The official Expresso distribution includes Struts and is supported by the Expresso developer community. With the parameters defined for including third party code, I would like to ask if you as a Struts Committer would be willing to give consideration to evaluating Expresso components before developing components that already exist in Expresso? The effectiveness of our joint community collaboration is greater than the sum of their parts. -- Sandra Cann http://www.jcorporate.com Open Standards based Java components Our separation from each other is an optical illusion of consciousness. (Albert Einstein) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Struts Connection Pool Maturity - Ted - you out there?
On Wed, 24 Apr 2002, Sandra Cann wrote: Heck that's fair enough - we feel the same! i.e. The official Expresso distribution includes Struts and is supported by the Expresso developer community. With the parameters defined for including third party code, I would like to ask if you as a Struts Committer would be willing to give consideration to evaluating Expresso components before developing components that already exist in Expresso? Willing to consider? Sure. I tend to be pretty conservative about what I actively add to the base framework (for example, heavy duty enhancements to the tag libraries don't fit my long term vision given a future world that contains JSTL and JavaServer Faces), but well-supported components that are core to the architecture are always worthy of consideration. I just need to note for history's sake that, by the time that the possibility of using the Expresso connection pool was raised, org.apache.struts.util.GenericDataSource had been published in the Struts 1.0 release for almost five months. You've heard me rant about backwards compatibility on at least a couple of occasions :-). The effectiveness of our joint community collaboration is greater than the sum of their parts. Agreed ... and I also want to publicly apologize for mis-typing the name of your framework ... it's really Expresso, not the cup of coffee-flavored drink I should have had before typing that response :-(. -- Sandra Cann http://www.jcorporate.com Open Standards based Java components Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
