RE: [VOTE] Promote Email to Commons Proper
Corey, yes you are right, main motivation is getting [email] out of sandbox :-) your #1 should be the easiest way. Btw. do you know if the JAMES-folks have a facility like dumbster? Regards, Matthias -Original Message- From: Corey Scott [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 16, 2004 8:14 AM To: Jakarta Commons Developers List Subject: Re: [VOTE] Promote Email to Commons Proper So back to the original problem. Dumbster is currently used by the tests. The way I see it this leaves us with a few options: 1) Remove it (and wait for the ok or change of license 2) Replace it (I havent seen an alternative, but I am willing to look) 3) Do it ourselves. To be honest, my main motivation is just to get Email promoted and moving. That said, after using dumbster for a while I have found it to be a good idea, although I find the implementation to be quite limited. As it also seems to be a one man show, the likelihood of it progressing to far, is low. For this reason, I would like to test the water a suggest, what does everything think about doing a similar component and putting it the sandbox? For my mind, this would help us immensely, we could shape the component so that is was more agreeable to what we are trying to test and ensure that a user was able to retrieve a decent amount of info from the 'sent' mails, as this is a lacking at the moment. I am willing to work on this, but I will need someone to help me champion it and CVS committer. -Corey - 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]
DO NOT REPLY [Bug 32260] - [email] byte array attachments
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32260. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=32260 [EMAIL PROTECTED] changed: What|Removed |Added AssignedTo|commons-|[EMAIL PROTECTED] |[EMAIL PROTECTED] | Status|NEW |ASSIGNED --- Additional Comments From [EMAIL PROTECTED] 2004-11-16 09:38 --- Created an attachment (id=13475) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=13475action=view) adds an attachment method that takes and byte[] as input Scott, This is just a quick kludge, is this the sort of thing you are talking about? Do you think you would be able to contrib a test case for this? I have to admit, I dont use this particular functionality and an experienced eye would be greatly helpful. -Corey -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] Promote Email to Commons Proper
ah, now I read the rest, well doing such a component is a nice thing. since unit-tests for [email] are a plus. well I don't know how to promote such a component to sandbox, perhaps eric knows more? I guess must post some code, that you will push to Jakarta Commons Sandbox. After that, there will be a vote for adding it to Sandbox? Just my personal thoughts. Since I haven't started an own project in ASF/Jakarta. With MyFaces (JSF-Implementation) it was different, we had code in SF.net. Asked the incubator-folks. After that we droped LGPL and used Apache2.0 Then the way was ready to start in ASF. Incubator-folks voted us to be on board. -Matthias -Original Message- From: Corey Scott [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 16, 2004 8:14 AM To: Jakarta Commons Developers List Subject: Re: [VOTE] Promote Email to Commons Proper So back to the original problem. Dumbster is currently used by the tests. The way I see it this leaves us with a few options: 1) Remove it (and wait for the ok or change of license 2) Replace it (I havent seen an alternative, but I am willing to look) 3) Do it ourselves. To be honest, my main motivation is just to get Email promoted and moving. That said, after using dumbster for a while I have found it to be a good idea, although I find the implementation to be quite limited. As it also seems to be a one man show, the likelihood of it progressing to far, is low. For this reason, I would like to test the water a suggest, what does everything think about doing a similar component and putting it the sandbox? For my mind, this would help us immensely, we could shape the component so that is was more agreeable to what we are trying to test and ensure that a user was able to retrieve a decent amount of info from the 'sent' mails, as this is a lacking at the moment. I am willing to work on this, but I will need someone to help me champion it and CVS committer. -Corey - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Promote Email to Commons Proper
I have taken a quick look at Jame, maybe someone might correct me, but I cant see anything similar to this. I will be the first to admit that I am not a domain expert in this particular area, but I am definately interested and can see the use for a compact 'fake' mail server, with decent error and content checking support. I think this is why we got so excited over dumbster in the first place :-) If people are interested, then we can give it shot and see where it leads us too. -Corey - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Promote Email to Commons Proper
Matthias Wessendorf wrote: your #1 should be the easiest way. Btw. do you know if the JAMES-folks have a facility like dumbster? Sorry, what is dumbster? -- Serge Knystautas Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Promote Email to Commons Proper
Serge, [Extract from the website http://quintanasoft.com/dumbster/] The Dumbster is a very simple fake SMTP server designed for unit and system testing applications that send email messages. It responds to all standard SMTP commands but does not deliver messages to the user. The messages are stored within the Dumbster for later extraction and verification. The Dumbster slots itself very easily into your testing strategy. As long as your application talks to an email server using SMTP then the Dumbster can be used to test the application with no code changes. [End extract] We have been using it to allow us to test send mails and do some rudimentary verification of the sent mails in our jUnit tests. Regards, Corey On Tue, 16 Nov 2004 03:53:48 -0500, Serge Knystautas [EMAIL PROTECTED] wrote: Matthias Wessendorf wrote: your #1 should be the easiest way. Btw. do you know if the JAMES-folks have a facility like dumbster? Sorry, what is dumbster? -- Serge Knystautas Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Promote Email to Commons Proper
Sounds like he's gonna change it anyway.. I mailed him the thread with henri's explaination and they've had a dialogue sicnce then. He said I don't have a problem changing the license. I will take a closer look at the text tomorrow and drop in the appropriate license from the choice you gave me before the end of this week. So assuming dumbsters license is on the mend. I guess its you folks back to voting.. On Tue, 16 Nov 2004 16:59:09 +0800, Corey Scott [EMAIL PROTECTED] wrote: Serge, [Extract from the website http://quintanasoft.com/dumbster/] The Dumbster is a very simple fake SMTP server designed for unit and system testing applications that send email messages. It responds to all standard SMTP commands but does not deliver messages to the user. The messages are stored within the Dumbster for later extraction and verification. The Dumbster slots itself very easily into your testing strategy. As long as your application talks to an email server using SMTP then the Dumbster can be used to test the application with no code changes. [End extract] We have been using it to allow us to test send mails and do some rudimentary verification of the sent mails in our jUnit tests. Regards, Corey On Tue, 16 Nov 2004 03:53:48 -0500, Serge Knystautas [EMAIL PROTECTED] wrote: Matthias Wessendorf wrote: your #1 should be the easiest way. Btw. do you know if the JAMES-folks have a facility like dumbster? Sorry, what is dumbster? -- Serge Knystautas Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] Promote Email to Commons Proper
Serge, http://quintanasoft.com/dumbster/ faking SMTP ;-) Regards, Matthias -Original Message- From: Serge Knystautas [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 16, 2004 9:54 AM To: Jakarta Commons Developers List Subject: Re: [VOTE] Promote Email to Commons Proper Matthias Wessendorf wrote: your #1 should be the easiest way. Btw. do you know if the JAMES-folks have a facility like dumbster? Sorry, what is dumbster? -- Serge Knystautas Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] Promote Email to Commons Proper
yeah Mark, nice deal! I also just surfed to sf.net and figured out email-address of jasionkitchen ;-) so back to vote! ;-) -Matthias - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Promote Email to Commons Proper
I had a peek on SF, and it looks like the developer has changed the license now: http://cvs.sourceforge.net/viewcvs.py/dumbster/dumbster/license.txt?rev=1.2view=auto Cheers, Rory Matthias Wessendorf wrote: yeah Mark, nice deal! I also just surfed to sf.net and figured out email-address of jasionkitchen ;-) so back to vote! ;-) -Matthias - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] Promote Email to Commons Proper
Rory, well the project pages tell you GPL... http://sourceforge.net/projects/dumbster/ cheers! -Original Message- From: Rory Winston [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 16, 2004 2:02 PM To: Jakarta Commons Developers List Subject: Re: [VOTE] Promote Email to Commons Proper I had a peek on SF, and it looks like the developer has changed the license now: http://cvs.sourceforge.net/viewcvs.py/dumbster/dumbster/license.txt?rev= 1.2view=auto Cheers, Rory Matthias Wessendorf wrote: yeah Mark, nice deal! I also just surfed to sf.net and figured out email-address of jasionkitchen ;-) so back to vote! ;-) -Matthias - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
FW: Bugzilla buggy?
Hi, I get the same thing, forwarding to [EMAIL PROTECTED] as instructed in the error report. Yoav Shapira http://www.yoavshapira.com -Original Message- From: Shinobu Kawai [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 16, 2004 6:30 AM To: [EMAIL PROTECTED] Subject: Bugzilla buggy? Hi, Is bugzilla broken? Or is it just me? I tried to see a bug, and got a big red error message. :( http://issues.apache.org/bugzilla/show_bug.cgi?id=32247 Best regards, -- Shinobu Kawai -- Shinobu Kawai [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] Promote Email to Commons Proper
Hi, Give him a couple of days to update his license and web page before we start the vote again ;) But it's sure nice to have clout when you ask people to change their license ;) Yoav Shapira http://www.yoavshapira.com -Original Message- From: Matthias Wessendorf [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 16, 2004 4:08 AM To: 'Jakarta Commons Developers List'; 'Mark Lowe' Subject: RE: [VOTE] Promote Email to Commons Proper yeah Mark, nice deal! I also just surfed to sf.net and figured out email-address of jasionkitchen ;-) so back to vote! ;-) -Matthias - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Promote Transaction to Commons Proper
+1 Stefan Oliver Zeigermann wrote: Folks, as described in previous posts and inspired by the fine proposal for email promotion I would like to see the transaction component http://jakarta.apache.org/commons/sandbox/transaction/ promoted to commons proper. The initial committers would be Stefan Lützkendorf, James Mason, Daniel Florey and me. AFAIK none of us is a committer in commons proper so the promotion would include making as committers there. We all are Jakarta Slide committers and this is where the component came from. We factored out code for a transactional file system, transactional maps (implementing Map interface) with different ACID strategies, general purpose locks and a few more helper classes. Junit tests exist for all parts and succeed: http://jakarta.apache.org/commons/sandbox/transaction/junit-report.html Javadoc is pretty complete http://jakarta.apache.org/commons/sandbox/transaction/apidocs/index.html and general documentation and even a short tutorial for locks exist: http://jakarta.apache.org/commons/sandbox/transaction/locks/tutorial.html The transaction component is stable enough to be released as a 1.0 soon after promotion and would initially be maintained by the committers of the Slide community. Once promoted growth is anticipated as even in the sandbox it attracted some attention. As I am not a commons committer, I have no binding vote, but my non-binding vote of course is +1. Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Stefan Lützkendorf -- [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FW: Bugzilla buggy?
Yikes. A quick Google says that this error is: No space left on device Who's the relevant admin? Rory Shapira, Yoav wrote: Hi, I get the same thing, forwarding to [EMAIL PROTECTED] as instructed in the error report. Yoav Shapira http://www.yoavshapira.com -Original Message- From: Shinobu Kawai [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 16, 2004 6:30 AM To: [EMAIL PROTECTED] Subject: Bugzilla buggy? Hi, Is bugzilla broken? Or is it just me? I tried to see a bug, and got a big red error message. :( http://issues.apache.org/bugzilla/show_bug.cgi?id=32247 Best regards, -- Shinobu Kawai -- Shinobu Kawai [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: FW: Bugzilla buggy?
Hi, It's [EMAIL PROTECTED] and [EMAIL PROTECTED] Yoav Shapira http://www.yoavshapira.com -Original Message- From: Rory Winston [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 16, 2004 9:05 AM To: Jakarta Commons Developers List Subject: Re: FW: Bugzilla buggy? Yikes. A quick Google says that this error is: No space left on device Who's the relevant admin? Rory Shapira, Yoav wrote: Hi, I get the same thing, forwarding to [EMAIL PROTECTED] as instructed in the error report. Yoav Shapira http://www.yoavshapira.com -Original Message- From: Shinobu Kawai [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 16, 2004 6:30 AM To: [EMAIL PROTECTED] Subject: Bugzilla buggy? Hi, Is bugzilla broken? Or is it just me? I tried to see a bug, and got a big red error message. :( http://issues.apache.org/bugzilla/show_bug.cgi?id=32247 Best regards, -- Shinobu Kawai -- Shinobu Kawai [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - 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] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Promote Transaction to Commons Proper
also non-binding, right? On Tue, 16 Nov 2004 14:49:10 +0100, Stefan Lützkendorf [EMAIL PROTECTED] wrote: +1 Stefan Oliver Zeigermann wrote: Folks, as described in previous posts and inspired by the fine proposal for email promotion I would like to see the transaction component http://jakarta.apache.org/commons/sandbox/transaction/ promoted to commons proper. The initial committers would be Stefan Lützkendorf, James Mason, Daniel Florey and me. AFAIK none of us is a committer in commons proper so the promotion would include making as committers there. We all are Jakarta Slide committers and this is where the component came from. We factored out code for a transactional file system, transactional maps (implementing Map interface) with different ACID strategies, general purpose locks and a few more helper classes. Junit tests exist for all parts and succeed: http://jakarta.apache.org/commons/sandbox/transaction/junit-report.html Javadoc is pretty complete http://jakarta.apache.org/commons/sandbox/transaction/apidocs/index.html and general documentation and even a short tutorial for locks exist: http://jakarta.apache.org/commons/sandbox/transaction/locks/tutorial.html The transaction component is stable enough to be released as a 1.0 soon after promotion and would initially be maintained by the committers of the Slide community. Once promoted growth is anticipated as even in the sandbox it attracted some attention. As I am not a commons committer, I have no binding vote, but my non-binding vote of course is +1. Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Stefan Lützkendorf -- [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Promote Email to Commons Proper
It'd be pretty easy to have James use the Null mailet as the first (and only step) in its processing logic. This would cause James to spool the incoming messages to disk, and then always discard them. That would be a much heavier weight solution though. We use something slightly like this, at least informally. There's a tool called Postal (http://www.coker.com.au/postal/) that does SMTP and POP benchmarking, and that has an SMTP sink. -- Serge Knystautas Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] Corey Scott wrote: Serge, [Extract from the website http://quintanasoft.com/dumbster/] The Dumbster is a very simple fake SMTP server designed for unit and system testing applications that send email messages. It responds to all standard SMTP commands but does not deliver messages to the user. The messages are stored within the Dumbster for later extraction and verification. The Dumbster slots itself very easily into your testing strategy. As long as your application talks to an email server using SMTP then the Dumbster can be used to test the application with no code changes. [End extract] We have been using it to allow us to test send mails and do some rudimentary verification of the sent mails in our jUnit tests. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: logging: WeakHashtable
Attached is a patch to LogFactory that attempts to play classloader tricks to prevent the hard reference problem. This is not meant to be applied; the patch is just a shorthand way to communicate ideas I'm playing with. This seemed to work in the sense that the tests I added to LogFactoryTest pass. But, o.a.c.l.LoadTest fails with a ClassCastException. Other tests in that package pass. Haven't had time to try and analyze what's going on with the LoadTest. Gotta run to work. - brian __ Do you Yahoo!? The all-new My Yahoo! - Get yours free! http://my.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Promote Transaction to Commons Proper
+1 On Tue, 16 Nov 2004 14:49:10 +0100, Stefan Lützkendorf [EMAIL PROTECTED] wrote: +1 Stefan Oliver Zeigermann wrote: Folks, as described in previous posts and inspired by the fine proposal for email promotion I would like to see the transaction component http://jakarta.apache.org/commons/sandbox/transaction/ promoted to commons proper. The initial committers would be Stefan Lützkendorf, James Mason, Daniel Florey and me. AFAIK none of us is a committer in commons proper so the promotion would include making as committers there. We all are Jakarta Slide committers and this is where the component came from. We factored out code for a transactional file system, transactional maps (implementing Map interface) with different ACID strategies, general purpose locks and a few more helper classes. Junit tests exist for all parts and succeed: http://jakarta.apache.org/commons/sandbox/transaction/junit-report.html Javadoc is pretty complete http://jakarta.apache.org/commons/sandbox/transaction/apidocs/index.html and general documentation and even a short tutorial for locks exist: http://jakarta.apache.org/commons/sandbox/transaction/locks/tutorial.html The transaction component is stable enough to be released as a 1.0 soon after promotion and would initially be maintained by the committers of the Slide community. Once promoted growth is anticipated as even in the sandbox it attracted some attention. As I am not a commons committer, I have no binding vote, but my non-binding vote of course is +1. Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Stefan Lützkendorf -- [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas - http://webservices.apache.org/~dims/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Jakarta Commons Wiki] Updated: Jelly
Date: 2004-11-16T13:00:02 Editor: TorstenCurdt [EMAIL PROTECTED] Wiki: Jakarta Commons Wiki Page: Jelly URL: http://wiki.apache.org/jakarta-commons/Jelly no comment Change Log: -- @@ -11,6 +11,8 @@ Jelly is also based on an XML pipeline architecture, like Cocoon, so that it is ideal for processing XML, scripting web services, generating dynamic web content or being part of a content generation system such as Cocoon. = External Resources = + * [http://www.software-support.biz/sus/sus_buch/psecom,id,63,nodeid,8,_language,de.html Jakarta Commons] by Torsten Curdt, Stefan Edlich, Henrik Hörning, Reidar Hörning, Software Support Verlag, in German + ||Do you have a good example, add it here!|| = FAQ = - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Promote Transaction to Commons Proper
i like what i see but at the moment i'm +0... i'm a little uncertain whether the scope of the component has been given the thought it deserves. the description describes what's in transaction rather than the proposed scope for the component. in some ways, at the moment transaction feels like four good components rather than one. (this might seem a little pedantic but component scopes have proved useful in the past) with a good scope added to the proposal, i'd be willing to alter my vote to +1. - robert On 15 Nov 2004, at 17:43, Oliver Zeigermann wrote: Folks, as described in previous posts and inspired by the fine proposal for email promotion I would like to see the transaction component http://jakarta.apache.org/commons/sandbox/transaction/ promoted to commons proper. The initial committers would be Stefan Lützkendorf, James Mason, Daniel Florey and me. AFAIK none of us is a committer in commons proper so the promotion would include making as committers there. We all are Jakarta Slide committers and this is where the component came from. We factored out code for a transactional file system, transactional maps (implementing Map interface) with different ACID strategies, general purpose locks and a few more helper classes. Junit tests exist for all parts and succeed: http://jakarta.apache.org/commons/sandbox/transaction/junit-report.html Javadoc is pretty complete http://jakarta.apache.org/commons/sandbox/transaction/apidocs/ index.html and general documentation and even a short tutorial for locks exist: http://jakarta.apache.org/commons/sandbox/transaction/locks/ tutorial.html The transaction component is stable enough to be released as a 1.0 soon after promotion and would initially be maintained by the committers of the Slide community. Once promoted growth is anticipated as even in the sandbox it attracted some attention. As I am not a commons committer, I have no binding vote, but my non-binding vote of course is +1. Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Promote Transaction to Commons Proper
I think your request is very reasonable. However, this really is an integrated component. Both the file system and the maps rely on the locks. Compare this to e.g. http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.html where you have a similar structure for more general concurrent Java programming. You have locks that are used by the channels and the collections and some more general purpuse helpers. You would not split this to more than one package, would you? Now, the transaction component aims at the same thing as the concurrent package, but is specific to transactions. You are very right and this really should be made explicite, thus I will add this as a scope to the index page of the transaction component ASAP. May a presume that this changes your vote to +1? Oliver On Tue, 16 Nov 2004 21:13:11 +, robert burrell donkin [EMAIL PROTECTED] wrote: i like what i see but at the moment i'm +0... i'm a little uncertain whether the scope of the component has been given the thought it deserves. the description describes what's in transaction rather than the proposed scope for the component. in some ways, at the moment transaction feels like four good components rather than one. (this might seem a little pedantic but component scopes have proved useful in the past) with a good scope added to the proposal, i'd be willing to alter my vote to +1. - robert On 15 Nov 2004, at 17:43, Oliver Zeigermann wrote: Folks, as described in previous posts and inspired by the fine proposal for email promotion I would like to see the transaction component http://jakarta.apache.org/commons/sandbox/transaction/ promoted to commons proper. The initial committers would be Stefan Lützkendorf, James Mason, Daniel Florey and me. AFAIK none of us is a committer in commons proper so the promotion would include making as committers there. We all are Jakarta Slide committers and this is where the component came from. We factored out code for a transactional file system, transactional maps (implementing Map interface) with different ACID strategies, general purpose locks and a few more helper classes. Junit tests exist for all parts and succeed: http://jakarta.apache.org/commons/sandbox/transaction/junit-report.html Javadoc is pretty complete http://jakarta.apache.org/commons/sandbox/transaction/apidocs/ index.html and general documentation and even a short tutorial for locks exist: http://jakarta.apache.org/commons/sandbox/transaction/locks/ tutorial.html The transaction component is stable enough to be released as a 1.0 soon after promotion and would initially be maintained by the committers of the Slide community. Once promoted growth is anticipated as even in the sandbox it attracted some attention. As I am not a commons committer, I have no binding vote, but my non-binding vote of course is +1. Oliver - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: logging: WeakHashtable
On 16 Nov 2004, at 06:12, Brian Stansberry wrote: (in general agreement) snip So, it seems like a hard reference in the map to a LogFactory is mostly a problem for webapps that include commons-logging in WEB-INF when it is already available on the server classpath. Bad practice in general to do this, but people do the darnedest things. I know Tomcat and the embedded Tomcat in JBoss both guard against this problem by calling LogFactory.release() when they undeploy webapps. Don't know about other webservers. i suspect that this will be the case whenever commons-logging is either deployed in WEB-INF or only within an ear (not at the system level). i believe that in the case of a jar deployed in an ear only, the context classloader will be the one used to load the class (since the parent won't have a copy available). in this case, the value would have to (sooner or later) be held by a weak reference. it would probably be possible to help in this case by counting, holding strong references then clearing them once the get count becomes too high. (the typical use case this would address would be multiple hot deployments which should result in enough gets.) having said that, this particular problem now looks more like a minority issue... (BTW, the problem with JBoss that led to Bug 31286 is related to EJB deployments. commons-logging is on the JBoss server classpath (specifically in the UnifiedClassLoaderRepository) due to its use in embedded Tomcat, so the classloader situation should be analogous to #2 above. JBoss doesn't call LogFactory.release() when undeploying EJBs, because if embedded Tomcat is not deployed they can't be sure LogFactory will be available). i agree that this case can be clearly addressed by holding a hard reference to the factory. maybe the best approach would be to address what seems to be the biggest use case and hold the LogFactory reference with a hard reference. i'd to happy to see WeakHashTable changed to use this strategy. the code to address the other use case is probably do-able but it's going to be a bit ugly. could create a similar class (with counts) and a similar (though subsidiary) mechanism which tries to load this other class in the case when WeakHashTable isn't present. however, bytecode manipulation might be more attractive in this case... - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Promote Transaction to Commons Proper
On 16 Nov 2004, at 22:03, Oliver Zeigermann wrote: I think your request is very reasonable. However, this really is an integrated component. Both the file system and the maps rely on the locks. Compare this to e.g. http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/ intro.html where you have a similar structure for more general concurrent Java programming. You have locks that are used by the channels and the collections and some more general purpuse helpers. You would not split this to more than one package, would you? we've found in the commons that tight, focussed components have done best :) thinking about scope before promotion and writing it down saves arguments later. (it's also part of the charter.) Now, the transaction component aims at the same thing as the concurrent package, but is specific to transactions. that makes sense. so (for example) like doug lea's original, transaction (probably) aims to be lightweight with minimal dependencies, and provides well tested, rigourous solutions for the most common use transactional use cases. (i have no doubt that you'll probably come up with something a lot better...) that way, in years to come when oddballs propose some heavyweight solution with big dependencies for an obscure problem, you'll be able to points them straight to your scope, saving weeks of argument :) You are very right and this really should be made explicite, thus I will add this as a scope to the index page of the transaction component ASAP. May a presume that this changes your vote to +1? come up with a good scope, discuss (as necessary) with the transaction community then commit and i'll cast a new vote :) (you'll thank me in the long run for insisting that you don't rush ;) - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/transaction/xdocs index.xml
ozeigermann2004/11/16 14:44:44 Modified:transaction/xdocs index.xml Log: Added scope proposal Revision ChangesPath 1.6 +28 -17jakarta-commons-sandbox/transaction/xdocs/index.xml Index: index.xml === RCS file: /home/cvs/jakarta-commons-sandbox/transaction/xdocs/index.xml,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- index.xml 15 Nov 2004 22:25:15 - 1.5 +++ index.xml 16 Nov 2004 22:44:44 - 1.6 @@ -10,41 +10,52 @@ body section name=The Transaction Component -p -Provides a set of utility classes for transactional data structures, -locks, and a transactional file system. Because it relies on the Map -interface it requires at least JDK1.2. -/p - -p -ba href=maps/index.htmlmemory/a package:/b -Contains a wrapper to make Maps implementing interface +pCommons Transaction aims at providing lightweight, standardized, +well tested and +efficient implementations of utility classes commonly used in +transactional Java programming. Initially there are implementations for +multi level locks, +transactional collections and transactional file access. There may +be additional implementations when the common need for them becomes +obvious. However, the complete component shall remain compatible to +JDK1.2 and should have minimal dependencies./p +pThe optimal - but maybe impudent - long term goal would be to create the transactional counterpart +of a +href=http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.html;Doug +Lea's fabulous concurrent package/a which recently made it to Java 5.0./p + + +pThese are the initial parts in detail: +ul +liba href=maps/index.htmlmemory/a package:/b +Contains a wrapper to make any map implementing interface codejava.util.Map/code transactional. Depending on the type of the map that is wrapped this can either work as a transactional cache or some sort of volatile memory store. -/p +/li -p +li ba href=locks/index.htmllocking/a package:/b Interfaces and implementations for locks that can have more than one owner at different compatible levels. -/p +/li -p +li ba href=file/index.htmlfile/a package:/b -Implementation of a transaction file system. Using a pessimistic +Implementation of transaction file access. Using a pessimistic locking schema this implementation features emserializable/em transactions. -/p +/li -p +li bemutil/em package:/b Contains a collection of utility classes used by the transaction package itself. Of more general interest could be a rendezvous barrier and a file utility class. +/li +/ul /p - /section section name=Releases - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Promote Transaction to Commons Proper
OK, I added the scope proposal to http://jakarta.apache.org/commons/sandbox/transaction/ I have to admit it is somehow inspired by the scope of the concurrent package and also by Roberts sketch ;) Any objections from the other transaction guys? Thanks for pointing in that direction Robert, I appreciate it! Oliver On Tue, 16 Nov 2004 22:30:19 +, robert burrell donkin [EMAIL PROTECTED] wrote: On 16 Nov 2004, at 22:03, Oliver Zeigermann wrote: I think your request is very reasonable. However, this really is an integrated component. Both the file system and the maps rely on the locks. Compare this to e.g. http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/ intro.html where you have a similar structure for more general concurrent Java programming. You have locks that are used by the channels and the collections and some more general purpuse helpers. You would not split this to more than one package, would you? we've found in the commons that tight, focussed components have done best :) thinking about scope before promotion and writing it down saves arguments later. (it's also part of the charter.) Now, the transaction component aims at the same thing as the concurrent package, but is specific to transactions. that makes sense. so (for example) like doug lea's original, transaction (probably) aims to be lightweight with minimal dependencies, and provides well tested, rigourous solutions for the most common use transactional use cases. (i have no doubt that you'll probably come up with something a lot better...) that way, in years to come when oddballs propose some heavyweight solution with big dependencies for an obscure problem, you'll be able to points them straight to your scope, saving weeks of argument :) You are very right and this really should be made explicite, thus I will add this as a scope to the index page of the transaction component ASAP. May a presume that this changes your vote to +1? come up with a good scope, discuss (as necessary) with the transaction community then commit and i'll cast a new vote :) (you'll thank me in the long run for insisting that you don't rush ;) - robert - 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]
cvs commit: jakarta-commons/configuration/src/test/org/apache/commons/configuration TestBaseConfigurationXMLReader.java
ebourg 2004/11/16 16:12:05 Modified:configuration/src/test/org/apache/commons/configuration TestBaseConfigurationXMLReader.java Log: minor style fix Revision ChangesPath 1.4 +3 -3 jakarta-commons/configuration/src/test/org/apache/commons/configuration/TestBaseConfigurationXMLReader.java Index: TestBaseConfigurationXMLReader.java === RCS file: /home/cvs/jakarta-commons/configuration/src/test/org/apache/commons/configuration/TestBaseConfigurationXMLReader.java,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- TestBaseConfigurationXMLReader.java 27 Feb 2004 17:41:34 - 1.3 +++ TestBaseConfigurationXMLReader.java 17 Nov 2004 00:12:05 - 1.4 @@ -1,5 +1,3 @@ -package org.apache.commons.configuration; - /* * Copyright 2001-2004 The Apache Software Foundation. * @@ -15,6 +13,8 @@ * See the License for the specific language governing permissions and * limitations under the License. */ + +package org.apache.commons.configuration; import java.io.IOException; import java.util.Arrays; - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/configuration/src/java/org/apache/commons/configuration ConfigurationUtils.java
ebourg 2004/11/16 16:14:03
Modified:configuration/src/java/org/apache/commons/configuration
ConfigurationUtils.java
Log:
getBasePath now returns null if the specified URL is null
Revision ChangesPath
1.11 +6 -1
jakarta-commons/configuration/src/java/org/apache/commons/configuration/ConfigurationUtils.java
Index: ConfigurationUtils.java
===
RCS file:
/home/cvs/jakarta-commons/configuration/src/java/org/apache/commons/configuration/ConfigurationUtils.java,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- ConfigurationUtils.java 19 Oct 2004 13:41:44 - 1.10
+++ ConfigurationUtils.java 17 Nov 2004 00:14:03 - 1.11
@@ -372,6 +372,11 @@
*/
static String getBasePath(URL url)
{
+if (url == null)
+{
+return null;
+}
+
String s = url.toString();
if (s.endsWith(/) || StringUtils.isEmpty(url.getPath()))
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/configuration/src/java/org/apache/commons/configuration AbstractFileConfiguration.java
ebourg 2004/11/16 16:18:00
Modified:configuration/src/java/org/apache/commons/configuration
AbstractFileConfiguration.java
Log:
The constructor AbstractFileConfiguration(String) now relies on setFileName()
instead of duplicating the logic.
This provides an alternate fix to Bug 32236 with a modification to
ConfigurationUtils.getBasePath.
Revision ChangesPath
1.9 +4 -10
jakarta-commons/configuration/src/java/org/apache/commons/configuration/AbstractFileConfiguration.java
Index: AbstractFileConfiguration.java
===
RCS file:
/home/cvs/jakarta-commons/configuration/src/java/org/apache/commons/configuration/AbstractFileConfiguration.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- AbstractFileConfiguration.java14 Nov 2004 18:29:02 - 1.8
+++ AbstractFileConfiguration.java17 Nov 2004 00:18:00 - 1.9
@@ -76,14 +76,7 @@
this();
// store the file name
-this.fileName = fileName;
-
-// locate the file
-url = ConfigurationUtils.locate(fileName);
-if(url == null)
-{
-throw new ConfigurationException(fileName + could not be
found!);
-}
+setFileName(fileName);
// update the base path
setBasePath(ConfigurationUtils.getBasePath(url));
@@ -496,7 +489,7 @@
}
/**
- * The URL where the configuration is stored.
+ * Set the URL where the configuration is stored.
*
* @param url
*/
@@ -508,6 +501,7 @@
basePath = ConfigurationUtils.getBasePath(url);
if (basePath != null basePath.startsWith(file:))
{
+// remove the file: prefix from file URLs
basePath = basePath.substring(5);
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31797] - [configuration] Optional configurations
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31797. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31797 [EMAIL PROTECTED] changed: What|Removed |Added Priority||P1 --- Additional Comments From [EMAIL PROTECTED] 2004-11-17 01:39 --- This looks good, thank you Oliver. I don't know if the name of the attribute is a good choice, we could have used optional=true instead of required=false, I have no personnal preference. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/httpclient/xdocs news.xml
mbecke 2004/11/16 17:43:20 Modified:httpclient/xdocs news.xml Log: added mailing list news Revision ChangesPath 1.32 +19 -4 jakarta-commons/httpclient/xdocs/news.xml Index: news.xml === RCS file: /home/cvs/jakarta-commons/httpclient/xdocs/news.xml,v retrieving revision 1.31 retrieving revision 1.32 diff -u -r1.31 -r1.32 --- news.xml 11 Oct 2004 22:32:46 - 1.31 +++ news.xml 17 Nov 2004 01:43:20 - 1.32 @@ -10,6 +10,21 @@ /properties body +section name=23 October 2004 - New HttpClient mailing lists +p +Starting today HttpClient has two new mailing lists for +a href=mailto:[EMAIL PROTECTED];developer/a and +a href=mailto:[EMAIL PROTECTED]user/a +discussion. People previously subscribed to icommons-httpclient-dev/i have +been automatically moved to the new developer mailing list. People +subscribed to icommons-user/i who are interested in HttpClient will have +to join the HttpClient user mailing list manually. +/p +p +Please see the HttpClient a href=mail-lists.htmlmailing list page/a for +(un)subscription and archive details. +/p +/section section name=11 October 2004 - HttpClient issue tracking in Bugzilla p HttpClient project has taken a very important step toward becoming @@ -44,9 +59,9 @@ section name=11 October 2004 - HttpClient 2.0.2 released p We are pleased to announce the latest stable release of HttpClient, -version 2.0.2. This release adds buffering for all reads. In particular this -change greatly improves the performance of reading responses with little or no content. -Please see the a href=http://www.apache.org/dist/jakarta/commons/httpclient/RELEASE-NOTES-2.0.txt; +version 2.0.2. This release greatly improves the performance of executing +methods where the response contains little or no content. Please see the +a href=http://www.apache.org/dist/jakarta/commons/httpclient/RELEASE-NOTES-2.0.txt; release notes/a for more detail. /p p - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/httpclient release_notes.txt
mbecke 2004/11/16 18:19:14 Modified:httpclient release_notes.txt Log: added the latest changes Revision ChangesPath 1.41 +11 -2 jakarta-commons/httpclient/release_notes.txt Index: release_notes.txt === RCS file: /home/cvs/jakarta-commons/httpclient/release_notes.txt,v retrieving revision 1.40 retrieving revision 1.41 diff -u -r1.40 -r1.41 --- release_notes.txt 2 Nov 2004 19:46:19 - 1.40 +++ release_notes.txt 17 Nov 2004 02:19:13 - 1.41 @@ -1,5 +1,14 @@ +Release 3.0 Beta 1 +--- Changes since Alpha 2: + * 31929 - Added support for formatting dates. Deprecated DateParser in + favor of DateUtil. + Contributed by Michael Becke mbecke at apache.org + + * - - HostConfiguration.isHostSet() and Hostconfiguration.isProxySet() have been + deprecated. + * 31981 - Fixed the bug causing an infinite loop in HttpMethodDirector when using SSL + proxy + host auth + keep alive off Contributed by Oleg Kalnichevski olegk at apache.org @@ -11,8 +20,8 @@ * 31471 - HostConfiguration refactored Contributed by Oleg Kalnichevski olegk at apache.org - * ContentLengthInputStream no longer supports mark() reset() methods. - Old broken implementation removed. + * - - ContentLengthInputStream no longer supports mark() reset() methods. Old + broken implementation removed. Contributed by Eric Johnson eric at tibco.com Release 3.0 Alpha 2 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31797] - [configuration] Optional configurations
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31797. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31797 --- Additional Comments From [EMAIL PROTECTED] 2004-11-17 07:50 --- The attribute name optional was indeed my first choice, but then I adapted it to the proposal in the bug description. Well, this is easy enough to change: just modify a string constant and negate a condition. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/chain/src/java/org/apache/commons/chain/impl CatalogBase.java
mrdon 2004/11/16 23:59:19 Modified:chain/src/java/org/apache/commons/chain/impl CatalogBase.java Log: Made CatalogBase thread-safe by synchronizing the map of commands PR: 32015 Revision ChangesPath 1.11 +5 -2 jakarta-commons/chain/src/java/org/apache/commons/chain/impl/CatalogBase.java Index: CatalogBase.java === RCS file: /home/cvs/jakarta-commons/chain/src/java/org/apache/commons/chain/impl/CatalogBase.java,v retrieving revision 1.10 retrieving revision 1.11 diff -u -r1.10 -r1.11 --- CatalogBase.java 25 Feb 2004 00:01:06 - 1.10 +++ CatalogBase.java 17 Nov 2004 07:59:18 - 1.11 @@ -17,6 +17,7 @@ import java.util.HashMap; +import java.util.Collections; import java.util.Iterator; import java.util.Map; import org.apache.commons.chain.Catalog; @@ -28,6 +29,8 @@ * pSimple in-memory implementation of [EMAIL PROTECTED] Catalog}. This class can * also be used as the basis for more advanced implementations./p * + * pThis implementation is thread-safe./p + * * @author Craig R. McClanahan * @author Matthew J. Sgarlata * @version $Revision$ $Date$ @@ -42,7 +45,7 @@ /** * pThe map of named [EMAIL PROTECTED] Command}s, keyed by name. */ -protected Map commands = new HashMap(); +protected Map commands = Collections.synchronizedMap(new HashMap()); // - Public Methods - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 32015] - [chain] Make CatalogBase.getCommand() thread safe
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32015. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=32015 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-11-17 08:59 --- Fixed, thanks. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
