Re: [all] Craig Mcc turned spammer? :-)
Was this sent to me directly, or did it go to the list? You can find out by looking at the headers, was it handled by an apache.org machine at any point? But it is also highly likely that the spammers mined this list and got your address *and* Craigs, and used Craig as the sender because he is a regular poster. d. *** The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient (or responsible for delivery of the message to the intended recipient) please notify us immediately on 0141 306 2050 and delete the message from your computer. You may not copy or forward it or use or disclose its contents to any other person. As Internet communications are capable of data corruption Student Loans Company Limited does not accept any responsibility for changes made to this message after it was sent. For this reason it may be inappropriate to rely on advice or opinions contained in an e-mail without obtaining written confirmation of it. Neither Student Loans Company Limited or the sender accepts any liability or responsibility for viruses as it is your responsibility to scan attachments (if any). Opinions and views expressed in this e-mail are those of the sender and may not reflect the opinions and views of The Student Loans Company Limited. This footnote also confirms that this email message has been swept for the presence of computer viruses. ** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [plea] get back to work -- was Re: [codec] [proposal] Moving To Apache Commons
I know exactly how you feel. The basic problem is that Jakarta, and Jakarta-Commons, are now incapable of taking any decisions on contentious issues. They are too large - too large for the discussion, too many mails, too many personalities and and inability to hold a vote. I think that is a bit harsh, it would be easy to take decisions with a VOTE, I don't know where you get inability from, it's getting broad based concensus that is harder, but also more desirable. IMHO, the only hope is for individual products to choose to move to TLP (lucene, slide and struts I'm hoping for). In effect, I'm hoping (praying) that other products will then see the light and want to escape. I also think this is unfair, there is no question of any sub-project having to escape from anything. Jakarta has, and still does, and will continue to, provide a supportive environment for the development of Open Source Java server software. Individual communities within Jakarta may decide to apply for promotion, or not, to serve their own best interests. Whatever their choice, and even if they want simply to continue without making a decision, they will be fully supported in that action by the Jakarta PMC. And then I suspect the final battle will commence - J-C vs Tomcat for the Jakarta name. Thats a lot of melodramatic nonsense, why on earth would there be a battle about it? You seem to think that the sub projects should behave like spoilt children competing for their parents attention. I think we are all mature enough to realise that there are many degrees of compromise between one extreme and the other. During this time, there will be little coding, much fustration and community damage. Why would people not code? Nothing will occur to affect the infrastructure and day-to-day decision making of any sub-project or commons component, promotion to tlp, movement to the incubator, or movement to apache commons is not Excommunication the project infrastructure is not destroyed and left for the commiters to re-assemble. The PMC's, the infrastructure folks, members and the board are all there to support transition and engourage success in each and every project of Apache, large or small. From www.apache.org We consider ourselves not simply a group of projects sharing a server, but rather a community of developers and users I'll say again - the Board could avoid this damage by choosing to ACT rather than REACT. It is extremely unlikely that the board will become involved in this unless either the PMC request it or it directly affects the board's business. The right people to decide the future of Jakarta commons are the Jakarta commons commiters. d. *** The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient (or responsible for delivery of the message to the intended recipient) please notify us immediately on 0141 306 2050 and delete the message from your computer. You may not copy or forward it or use or disclose its contents to any other person. As Internet communications are capable of data corruption Student Loans Company Limited does not accept any responsibility for changes made to this message after it was sent. For this reason it may be inappropriate to rely on advice or opinions contained in an e-mail without obtaining written confirmation of it. Neither Student Loans Company Limited or the sender accepts any liability or responsibility for viruses as it is your responsibility to scan attachments (if any). Opinions and views expressed in this e-mail are those of the sender and may not reflect the opinions and views of The Student Loans Company Limited. This footnote also confirms that this email message has been swept for the presence of computer viruses. ** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OT: Re: [ANN] hivemind has been temporarily taken offline
Vic, I read the discussions in which you made allegations about Geronimo. Now please read this: 1/ It is the decision of the Jakarta PMC that as doubt about the ownership has been expressed and not resolved it is prudent for the PMC to take this step until it is resolved. 2/ No one is suggesting, at this stage, that there is any possibility that Hivemind won't return as soon as the PMC are satisfied that the right to distribute the code under the ASFL has been satisfactorily established. The origin of the code is not in doubt. 3/ Geronimo is not under the jurisdiction of this PMC. The Geronimo situation was explained to you at the time . There is certainly no conspiracy against Hivemind. Period. I sincerely hope that the full facts regarding the doubt expressed over Hivemind can be examined and the issue resolved quickly, in the meantime the PMC has a duty to take this issue seriously. Not to do so, however desirable it might be, would be negligent. d. Interesting that HiveMind was a problem, yet jBoss to Geromino is not a potential legal problem for Apache Users. What was the diference, that they put the code in sf.net first, refactored packages and claimed it was not jBoss IP? All Howard did was level with ASF, and Geronimo (insert appropriate word) claimed orignial IP. Even enforcement would be great. I hope HiveMind shows up on sf.net in the mean time, *** The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient (or responsible for delivery of the message to the intended recipient) please notify us immediately on 0141 306 2050 and delete the message from your computer. You may not copy or forward it or use or disclose its contents to any other person. As Internet communications are capable of data corruption Student Loans Company Limited does not accept any responsibility for changes made to this message after it was sent. For this reason it may be inappropriate to rely on advice or opinions contained in an e-mail without obtaining written confirmation of it. Neither Student Loans Company Limited or the sender accepts any liability or responsibility for viruses as it is your responsibility to scan attachments (if any). Opinions and views expressed in this e-mail are those of the sender and may not reflect the opinions and views of The Student Loans Company Limited. This footnote also confirms that this email message has been swept for the presence of computer viruses. ** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN][hivemind] hivemind has been temporarily taken offline
Harish, There isn't very much traffic on the PMC list at all, most business, and all votes, is transacted on the general list. If anyone has any item which they wish to draw to the specific attention of the PMC it is always a good idea to post to PMC@ because you will then know that your message has been read. Further discussions could be carried out on the general list or in private, whichever was more appropriate. By which I don't mean that the PMC would reach its decisions in secret but that issues of individual privacy may make it more acceptable to keep the discussion out of the spotlight. d. *** The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient (or responsible for delivery of the message to the intended recipient) please notify us immediately on 0141 306 2050 and delete the message from your computer. You may not copy or forward it or use or disclose its contents to any other person. As Internet communications are capable of data corruption Student Loans Company Limited does not accept any responsibility for changes made to this message after it was sent. For this reason it may be inappropriate to rely on advice or opinions contained in an e-mail without obtaining written confirmation of it. Neither Student Loans Company Limited or the sender accepts any liability or responsibility for viruses as it is your responsibility to scan attachments (if any). Opinions and views expressed in this e-mail are those of the sender and may not reflect the opinions and views of The Student Loans Company Limited. This footnote also confirms that this email message has been swept for the presence of computer viruses. ** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [hivemind] what exactly is the issue here?
Noel wrote: (about Howard Hivemind) Some of his messages seem to imply that he feels that if he did [put the full facts before the PMC or the Board], there would be drastic action. Speaking for myself I'd say there is *less* likely to be drastic action if the PMC are fully congnisant of the facts than if there is a spectre of legal mess looming over us, assuming that Howard is correct in his assertions. It's also worth reiterating that (IMO at least) the PMC is exists to support people in situations like this, and to try to resolve these kind of issues to the satisfaction of everyone involved. d. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] *** The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient (or responsible for delivery of the message to the intended recipient) please notify us immediately on 0141 306 2050 and delete the message from your computer. You may not copy or forward it or use or disclose its contents to any other person. As Internet communications are capable of data corruption Student Loans Company Limited does not accept any responsibility for changes made to this message after it was sent. For this reason it may be inappropriate to rely on advice or opinions contained in an e-mail without obtaining written confirmation of it. Neither Student Loans Company Limited or the sender accepts any liability or responsibility for viruses as it is your responsibility to scan attachments (if any). Opinions and views expressed in this e-mail are those of the sender and may not reflect the opinions and views of The Student Loans Company Limited. This footnote also confirms that this email message has been swept for the presence of computer viruses. ** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Math] common-math and bloated 3rd party libraries
FWIW the math proposal actually says: Emphasis on small, easily integrated components rather than large libraries with complex dependencies ;-) As far as Todds comments go: While I tend to be in the go with 1.4 ... I'm firmly in the stick with 1.3 camp. Until there is either progress which is *really* blocked by lack of access to 1.4+ and or the demand for 1.3 compatibility is insignificant I don't think it is wise for any Jakarta sub-project, or part of commons, to ignore the fact that the Jakarta mission to produce server software, and many many people are stuck with 1.3 until they can justify significant investment involved in upgrading to newer container version. Don't forget that the cost of change isn't all in the software there's a big old load of testing to do as well. I also want to gripe mildly about the server-side mission, since it feels myopic to me. The lines between client and server blur more every day. With JNLP it is easy and beneficial to shove increasing functionality to the client side, which means downloading jars to the desktop. But the lines are blurred and blurring @jakarta as well, there's plenty of software here which is as applicable in clients as it is in servers, but to extend the scope of the project to anything java at all would be silly, theres already enough going on as it is. If you want to develop desktop software @apache, make a proposal to the incubator. d. *** The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient (or responsible for delivery of the message to the intended recipient) please notify us immediately on 0141 306 2050 and delete the message from your computer. You may not copy or forward it or use or disclose its contents to any other person. As Internet communications are capable of data corruption Student Loans Company Limited does not accept any responsibility for changes made to this message after it was sent. For this reason it may be inappropriate to rely on advice or opinions contained in an e-mail without obtaining written confirmation of it. Neither Student Loans Company Limited or the sender accepts any liability or responsibility for viruses as it is your responsibility to scan attachments (if any). Opinions and views expressed in this e-mail are those of the sender and may not reflect the opinions and views of The Student Loans Company Limited. This footnote also confirms that this email message has been swept for the presence of computer viruses. ** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Scripting in Java ?
Mark wrote: I think its important to point out that BSF is really a Generic Framework for plugging in other scripting engines Snip... So with this in mind you can actually plug jython, rhino, etc into it and use it as a generic api for your java development. I've used BSF with both Rhino and Jython, it really is what you want. FWIW both Rhino (java script engine from Mozilla.org) and Jython (www.jython.org) are excellent products, and much respect is due to their creators/maintainers. Which engine you end up using is then up to your own prefrences, Java script is a handy option where you want to allow web developers to modify the behaviour of web apps, python is much more readable by non-geeks if you want to work with business people. d. *** The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient (or responsible for delivery of the message to the intended recipient) please notify us immediately on 0141 306 2050 and delete the message from your computer. You may not copy or forward it or use or disclose its contents to any other person. As Internet communications are capable of data corruption Student Loans Company Limited does not accept any responsibility for changes made to this message after it was sent. For this reason it may be inappropriate to rely on advice or opinions contained in an e-mail without obtaining written confirmation of it. Neither Student Loans Company Limited or the sender accepts any liability or responsibility for viruses as it is your responsibility to scan attachments (if any). Opinions and views expressed in this e-mail are those of the sender and may not reflect the opinions and views of The Student Loans Company Limited. This footnote also confirms that this email message has been swept for the presence of computer viruses. ** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 23990] - EmailValidator - valid email address fails
So it again boils down to a *BUG*. But not the same bug.. *** The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient (or responsible for delivery of the message to the intended recipient) please notify us immediately on 0141 306 2050 and delete the message from your computer. You may not copy or forward it or use or disclose its contents to any other person. As Internet communications are capable of data corruption Student Loans Company Limited does not accept any responsibility for changes made to this message after it was sent. For this reason it may be inappropriate to rely on advice or opinions contained in an e-mail without obtaining written confirmation of it. Neither Student Loans Company Limited or the sender accepts any liability or responsibility for viruses as it is your responsibility to scan attachments (if any). Opinions and views expressed in this e-mail are those of the sender and may not reflect the opinions and views of The Student Loans Company Limited. This footnote also confirms that this email message has been swept for the presence of computer viruses. ** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Attributes] Inherit and Develop
I personally don't have any problem with widening that rule to any Apache committer, which would therefore include Leo automatically (he has commit access on Avalon, which used to be a Jakarta sub-project but is now top level). Does any other Commons-Dev committer or Jakarta PMC member have any problem with that? Not me. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[DBCP] Event/Listener proposal (was .. RE: [DBCP] AbandonedTrace - Connection Recovery)
Well I never, There's been a lot of talk generated by my innocent proposal of using the Observer pattern, or in more java-esque terms events and listeners to arrive at a compromise in the Connection Recovery War. I'd like to clarify some points raised. In the first place to address the criticism of any compromise being levelled by Juozas, this was intended not to appeal to one camp or the other, but to be a neutral proposal which would accomodate both modes of use. There is nothing in the addition of an event model that should offend either camp, and properly impelemented users who don't choose to listen for events should not notice any impact on performance. Secondly, to address Craig's opinion that we shoudl abandon connection recovery altogether, I proposed that the existing recovery code be refactored to be usable as a listener in the event model because there *are* some users, and some vocal supporters and I would like to think that this community is not so arrogant that we would remove support for them without phaseing it out gradually. The listener implementing connection recovery could be immediately deprecated with text to explain why we don't like it, and scheduled for removal at the next release, giving people time to make other arrangements (probably just fork it :) . Third there are *way* more uses for this than for supporting the forceable recovery of connections, for instance this could be used to log and trace pool activity allowing people to attach tools which will help them to improve their code. It really is much more than just a way in which users can avoid the responsibility of handling connections correctly. Finally it allows the DBCP project to have a finite scope. By providing an API for the attachment of additional functionality we would allow DBCP to encapsulate JDBC Connection pooling, the implementation would not be the concern of users nor necessarily of the majority of implementors of listeners. DBCP could move towards maturity and low maintenance without restricting the creation of new behaviours and tools. d. - 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]
Event/Listener proposal (was .. RE: [DBCP] AbandonedTrace - Connection Recovery)
Well I never, There's been a lot of talk generated by my innocent proposal of using the Observer pattern, or in more java-esque terms events and listeners to arrive at a compromise in the Connection Recovery War. I'd like to clarify some points raised. In the first place to address the criticism of any compromise being levelled by Juozas, this was intended not to appeal to one camp or the other, but to be a neutral proposal which would accomodate both modes of use. There is nothing in the addition of an event model that should offend either camp, and properly impelemented users who don't choose to listen for events should not notice any impact on performance. Secondly, to address Craig's opinion that we shoudl abandon connection recovery altogether, I proposed that the existing recovery code be refactored to be usable as a listener in the event model because there *are* some users, and some vocal supporters and I would like to think that this community is not so arrogant that we would remove support for them without phaseing it out gradually. The listener implementing connection recovery could be immediately deprecated with text to explain why we don't like it, and scheduled for removal at the next release, giving people time to make other arrangements (probably just fork it :) . Third there are *way* more uses for this than for supporting the forceable recovery of connections, for instance this could be used to log and trace pool activity allowing people to attach tools which will help them to improve their code. It really is much more than just a way in which users can avoid the responsibility of handling connections correctly. Finally it allows the DBCP project to have a finite scope. By providing an API for the attachment of additional functionality we would allow DBCP to encapsulate JDBC Connection pooling, the implementation would not be the concern of users nor necessarily of the majority of implementors of listeners. DBCP could move towards maturity and low maintenance without restricting the creation of new behaviours and tools. d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [DBCP] AbandonedTrace - Connection Recovery
Serge, 1. Remove existing abandoned recovery attempt code. 2. Log when connections are abandoned and do not add them back into the pool. 3. Optionally log stack trace of where abandoned connection was first grabbed. 4. Provide some kind of extensible connection object that could allow someone to add their own (possibly included but optional) way to recover abandoned connections. I agree with your proposal, although I don't think I have a vote here. wrt point 4 I would suggest you consider allowing users to attach a listener/listeners to the pool and propogate the following events: ConnectionBorrowed - allow users to add a handler to test and possibly replace connections as they leave the pool ConnectionReturned - allow users to add a handler to test and discard (reallyClose()) connections returning to the pool ConnectionUnallocatedIdleTimeReached - allow users to add a handler to test and reallyClose() or replace connections idle in the pool beyond a confiigured idle timeout. ConnectionAllocatedIdleTimeReached - allow users to add a handler to reclaim connections allocated but idle beyond a configured idle timeout. d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [DBCP] AbandonedTrace - Connection Recovery
Serge et al, Further to my suggestion about using the Observer pattern for event notification w.r.t. point 4 (below) I forgot to mention that it also has the benefit of offering a compromise in the pro/anti recovery debate. Existing contentious code designed to reclaim or test connections need not be retired as it could still be made available re-factored into a listener, and attached at runtime by the user. Users can use, extend or ignore DBCP's own listeners at their discretion shifting the decision from the developers to the users where, judging by the debate, it probably belongs. It also follows that DBCP need not then impose a single Jakarta-approved strategy, but could easily be shipped with a number of implementations of different strategies, chosen between and attached at runtime by the user or by DBCP itself in response to configuration settings. 4. Provide some kind of extensible connection object that could allow someone to add their own (possibly included but optional) way to recover abandoned connections. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [DBCP] AbandonedTrace - Connection Recovery
Juozas, I do not think it is good idea to maintain any kind of public API for abandoned connections, It is garbage, If application or server is not broken, it doe's not need workarounds. It is easy for you to say this, but the fact remains that a number of people are quite vocal in their support for it, it is wrong for us to ignore the needs of _all_ users, particularly if we are talking about removing functionality which already exists and is in use. Therefore there we have four options: 1/ We vote and the winning proposal is implemented leaving everyone else dissatisfied 2/ We retain the status quo 3/ Someone makes a change without the general consent of the group 4/ We reach a compromise. 1 is the Apache way. 2 is ignoring the issue. 3 is unacceptable and would cause trouble. 4 is surely the most reasonable course of action to take. Now I know you favour dropping support, others don't. What would you say if we retained it? What would they say if we dropped it? Alternatively Serge's proposal is a proposal for compromise, I was attempting to provide some support for the proposal by detailing one possible way in which a compromise can be accomodated, allowing both sets of users to have DBCP behave in the way they favour without breaking it for the others. If you believe my suggestions are garbage I suggest you help the process by suggesting an alternative compromise as it looks likely that only a compromise will be generally acceptable. d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [DBCP] AbandonedTrace - Connection Recovery
Juozas, I think I will leave commons and I will spend more my time on SF with forked code, if this kind of vote can win at apache. My input is not a very big, but I will lose any energy to work for crap . I think it is sad that you would rather leave than suggest any alternative. It highlights my point though, why should we expect those in favour of its retention to remain involved if we drop this when you won't remain involved if it is not dropped? Surely we should at least _try_ to accomodate both points of view? Or are also against even helping to find a compromise that would satify your requirements? I can see no technical reason why this should not be done, perhaps you can? If so why don't you help us by explaining why a compromise can never be acceptable to you. d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: DBCP status?
Serge, I *need* the pooler to close connections that have been borrowed from the pool and forgotten to be closed. Can you give a) reasons why not to close them because of an optional parameter and b) suggested workaround? Why? I can think of a couple of reasons you might give, but I'm seriously not convinced that it is a legitimate thing for the pool to do. Can you sell it to us? I think there's a relunctance (including mine) to create a dependency on commons-logging (or another logger), so I was thinking about a PoolListener service. FWIW I authored a JDBC connection pool and file URL cache library for work, my experience is this.. we started off with logging, it is vital to know exactly what the pools and caches think is going on while your library is under development. However once we started putting stable product into other software we quickly discovered that logging is unnecessary, if anything is going on you use a debugger, if it is going well you don't want the kind of logs these things produce. We eventually added a listener API and found it to be much more satisfactory. +1 to that idea. There would be classes of events for: a) creating a connection b) grabbing a connection c) closing a connection d) a connection getting too old I think that if in case d) your listener can intervene in the connection lifecycle then it is unnecessary to have DBCP frceably close connections. d.
RE: DBCP status?
I think we've had this discussion before. But I'll weigh in with my 2c again because I still feel strongly about it.. Craig says: I do not believe there is any fundamentally sound algorithm that a connection pool can use to detect when a connection has truly been abandoned and is thereby suitable for recovery. And, grabbing back connections that are actually in use is *much* worse than leaking them, because you immediately break an application that is currenty executing, in ways that are very unpredictable, hard to reproduce, and basically impossible to recover from. I agree. IMO It is fundamentally better to let leaks result in the problems associated with leaks (run out of connections) than to replace a set of known, quantifiable and understood symptoms with Mystery and Confusion. d.
RE: Re[2]: DBCP status?
I have been stricken with the beauty of approach you have proposed, indeed its nice to emulate a server timeout :-)) I can see how this would appeal, allowing DBCP to impose its own timeout, however IMO it would still not allow DBCP be able to reclaim the connection, Rather it would have instead to mimic the servers response to a timeout, which might only become apparent when the connection is used, and not have any affect if the routine holding the connection is accessing properties and methods of the connection which are handled offline. In this event it would therefore appear to be almost impossible to achieve any real advantage for the pool, in that it would still not be able to legitimately reclaim the connection or close it, unless that can be done without breaking existing ResultSet's, StoredProcedures and so on. For example connecting to MySQL using JDBC it is possible to attempt to use a connection which no longer exists, and only on the execution of an SQL query does the driver return an error. This is because the instance of Connection is not closed, it is simply no longer capable of contacting the RDBMS. Even when that error is issued it is *still* the responsibility of the user to call close(), JDBC doesn't reclaim the object and garbage collect it for you. Therefore I contend that it would be inconsistent for DBCP to behave otherwise, and it would also be of little use for preventing leaks as leaked connections will most likely never be used again, and so never be seen to timeout. I'm afraid something nasty may happen if while the user is executing a lengthy query another thread close()-s the connection. This is one of my primary reasons for siding against intervention by the pool, it is not within the remit of a pool to dictate how the resources should be used. In use, IMO, any pool or cache should intervene between programme and resource in a manner which is completely transparent. It should never be the case that a pool or cache can cause the failure of the resource where the resource is being used legitimately according to its specification, JDBC makes no restriction on the length of time connections can be held for and therfore neither should any JDBC connection pool. If this causes problems for the user it is because they are either using the pool inapropriately or their code is broken. In neither situation has the case been well argued that the pool should attempt to correct this in preference to the developers of the software. d.
RE: Re[2]: Nightly builds?
Me too, but maybe I'm lameristic :) In fact I use windows port of SSH (by Gorden Chaffee, ssh-1.2.14-win32bin.zip) with windows port of cvs. CVS and ssh work fine but I fail to do scp. But I have been failing this for a long time already. Maybe the reason is that with scp I did not find a way to specify my cvs.apache.org username (atagunov), while my login name here at Win2K is different. Try using putty on windows, it has implementations of scp sftp ssh and agent, has a good ssh terminal GUI or you can use a commandline version. http://www.chiark.greenend.org.uk/~sgtatham/putty/
RE: Re[4]: Nightly builds?
But, with that program I have another kind of difficulty: by itself it generates keys of some format not recognized by ssh server running on cvs.apache.org. The keys of this format look like Top tip .. I find it often avoids pain if you generate your keys on the server you're connecting to rather on your own desktop. Particularly if the former is *nix and the latter isn't. d.
RE: [DBCP] Please let us start to improve the connection pool
Craig wrote: But I think we might be using the term recycle differently. By recycle, do you mean if a connection has been setting in the pool for a long time and is not allocated to an application, so we can close it now? No, thats pool administration. IMO its an implementation detail that should be of no concern of the user, its existence should only be exposed indirectly through settings such as test while idle. Although in practice it helps if you know whats going on. Or, by recycle, do you mean if a connection has been allocated to an application but not returned for a long time, the pool is allowed to grab it back again -- but you want to notify the application first. The grab it back behavior is already configurable (and not enabled by default) -- and it's this functionality that I object to having at all. If there was no grab it back we wouldn't have to worry about notifying anyone that it was about to happen :-). This was what actually I meant by recycling, from the POV that the whole pooling pattern is about re-cycling objects dispensed with by one Object but of use to another (as in trash re-cycling) to reduce the overhead of creating identical new objects. Its my opinion that it is beyond the remit of the pool to re-use objects which have not been positively freed by the Object which was last assigned them. My reasons are that it builds in the potential for unpredictable failures, and only benefits broken code. So I think we agree... If we're talking about the second use of recycled above, IMHO, I think adding support for recovering abandoned connections at all was a mistake. Doing anything to make it work better (knowing all the while that it cannot be made perfect) simply perpetuates the mistake. I'd much rather see this whole area of functionality deprecated, rather than continuing to mislead people into believing that its OK to depend on something that cannot ever work reliably 100% of the time. I'd agree with that too. What has now occured to me is that this philosophy also delegates the responsibility to the connection consumer for ensuring that refrences, direct or indirect, to the connection are never used once the connection has been passed back to the pool. Otherwise this is another area where confusing behaviour could result from subtle bad code. The notion expressed by someone else of creating new wrappers for each request delegating to truly pooled connections, with the wrappers discarded when the connection is returned to the pool would prevent refrences to wrappers being used to access the real pooled resources. On the other hand this safety might negate too much of the performance boost pooling provides. d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [DBCP] Please let us start to improve the connection pool
Craig, IMHO, any application that depends on the connection pool for recovering abandoned connections (whether or not it recycles them) is broken. Far better is to focus your energy on avoiding all the cases where you grab a connection from the pool but fail to return it for some reason. One simple way to do this is to encapsulate your JDBC-using code in a try/catch/finally block, something like this: I haven't used DBCP for anthing yet, though we're proposing to use it for James in place of our homespun pool. However from what I understand of this discussion there are two things going on here; Thing one, I agree with you, code failing to return connections to the pool should lead to failure, and the sooner this can be done the better for identifying such broken code. Thing two, DBCP will apparently make a value judgement about an assigned connection, and is capable of recycling it with no notification to the code which has checked it out. In my opinion thing two is wrong or incomplete as it creates a situation where potential failure is built in, difficult to reproduce and difficult identify the cause of. In the case of JDBC connection pooling may be reasonable to want to keep a connection even when it is idle, because connections can aquire state which is expensive to reproduce. Is it not, then, unresonable to allow the pool to silently and forcably recycle apparently idle but valuable connections? My solution would either be to make it possible to turn off the forcable recycling of connections, or to make the pool capable of notifying code that its connection has been recycled. Is that reasonable? d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [NET] Here's an Ant bug that we should look into fixing
As far as my less ambitious goal of parsing dates correctly on different locale systems is concerned, I posted a request on the Ant list for any sample FTP sites implemented in different languages and so far have not received any replies. Are you sure that dates are transferred in local language? SMTP specifies English for dates, perhaps ftp does too? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
