[g...@vmgump]: Project commons-email (in module apache-commons) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at gene...@gump.apache.org. Project commons-email has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 2 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-email : Commons Email Package Full details are available at: http://vmgump.apache.org/gump/public/apache-commons/commons-email/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole jar output [commons-email-*[0-9T].jar] identifier set to project name -DEBUG- (Apache Gump generated) Apache Maven Settings in: /srv/gump/public/workspace/apache-commons/email/gump_mvn_settings.xml -INFO- Failed with reason build failed -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/email/pom.xml -DEBUG- Extracted fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/apache-commons/commons-email/gump_work/build_apache-commons_commons-email.html Work Name: build_apache-commons_commons-email (Type: Build) Work ended in a state of : Failed Elapsed: 38 secs Command Line: /opt/maven2/bin/mvn --batch-mode -Dmaven.jar.mail=/srv/gump/packages/javamail-1.4/mail.jar --settings /srv/gump/public/workspace/apache-commons/email/gump_mvn_settings.xml package [Working Directory: /srv/gump/public/workspace/apache-commons/email] M2_HOME: /opt/maven2 - log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info. Tests run: 13, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 1.69 sec <<< FAILURE! Running org.apache.commons.mail.EmailLiveTest Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.473 sec Running org.apache.commons.mail.SendWithAttachmentsTest Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.117 sec Running org.apache.commons.mail.DataSourceResolverTest Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.012 sec Running org.apache.commons.mail.util.MimeMessageParserTest Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.158 sec Running org.apache.commons.mail.EmailTest Tests run: 40, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.359 sec Running org.apache.commons.mail.EmailAttachmentTest Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.526 sec Running org.apache.commons.mail.ImageHtmlEmailTest Tests run: 19, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.716 sec <<< FAILURE! Running org.apache.commons.mail.DefaultAuthenticatorTest Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004 sec Running org.apache.commons.mail.util.URLFactoryTest Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.005 sec Running org.apache.commons.mail.SimpleEmailTest Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.016 sec Running org.apache.commons.mail.MultiPartEmailTest Tests run: 10, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.085 sec Running org.apache.commons.mail.InvalidInternetAddressTest Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.011 sec Running org.apache.commons.mail.InvalidAddressTest Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.008 sec Results : Failed tests: testEmbedFileWithCID(org.apache.commons.mail.HtmlEmailTest) testEmbedFileWithCID(org.apache.commons.mail.ImageHtmlEmailTest) Tests run: 110, Failures: 2, Errors: 0, Skipped: 0 [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] There are test failures. Please refer to /srv/gump/public/workspace/apache-commons/email/target/surefire-reports for the individual test results. [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 37 seconds [INFO] Finished at: Tue Dec 21 07:14:22 UTC 2010 [INFO] Final Memory: 51M/122M [INFO] - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/apache-commons/commons-email/rss.xml - Atom: http://vmgump.apache.org/gump/public/apache-commons/commons-email/atom.xml == Gump Tracking Only === Produced by Apache Gump(TM) version 2.3. Gump Run 3421122010, vmgump.apache.org:vmgump:34211
Re: [pool] Refactoring Config classes (Was: [pool] Pool config vs. factory hierarchies.)
Thanks for the feedbacks Gary, I'm committing the latest modifications right now, every kind of feedback/suggestion is appreciated, every contribution is more than welcome. Many thanks in advance, have a nice day, Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Tue, Dec 21, 2010 at 12:30 AM, Gary Gregory wrote: > Please go ahead as you see fit. > > I am in the middle of moving now and can only process emails. > > I am also not sure about the merit of the refactoring anymore. I recall a > message casting doubt on this refactoring adventure :) > > Gary > > On Dec 20, 2010, at 13:56, "Simone Tripodi" wrote: > >> Hi Gary, >> IMHO the optimizations you're proposing are very important and since I >> like cooperating with you, I thought was better making aware about >> what I'd intend to do :P >> If you agree I could start committing the latest modifications, so you >> can apply your refactoring later. WDYT? >> Have a nice day, all the best, >> Simo >> >> http://people.apache.org/~simonetripodi/ >> http://www.99soft.org/ >> >> >> >> On Mon, Dec 20, 2010 at 10:41 PM, Gary Gregory >> wrote: >>> Don't worry about my stuff. I am in the middle of a move. >>> >>> Gary >>> >>> On Dec 20, 2010, at 12:20, "Simone Tripodi" >>> wrote: >>> Hi all guys, I spent the afternoon refactoring the config classes according to informations collected on[1], have a ready commit. Do you want to read the patch before I commit or I I can commit so everybody can review and contribute to the modifications? This could block the Gary's work on optimization, please let me know! Thanks in advance, Simo [1] http://wiki.apache.org/commons/PoolRoadMap http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Sun, Dec 5, 2010 at 2:27 PM, Simone Tripodi wrote: > Hi Gary/all :) > I collected informations on the wiki on the RoadMap page[1], based on > what we discussed in this thread. > If you agree on what is written, we can start back coding. > Have a nice weekend, > Simo > > [1] http://wiki.apache.org/commons/PoolRoadMap > > http://people.apache.org/~simonetripodi/ > http://www.99soft.org/ > > > > On Wed, Dec 1, 2010 at 3:21 PM, Gary Gregory > wrote: >>> -Original Message- >>> From: Simone Tripodi [mailto:simone.trip...@gmail.com] >>> Sent: Wednesday, December 01, 2010 08:51 >>> To: Commons Developers List >>> Subject: Re: [pool] Pool config vs. factory hierarchies. >>> >>> Hi Gary, >>> yes, more people involved on defining these details is better, I >>> agree. I'm thinking about creating a wiki page to resume all the >>> requirements, what do you think? >> >> Good idea! >> >> Gary >> >>> Simo >>> >>> http://people.apache.org/~simonetripodi/ >>> http://www.99soft.org/ >>> >>> >>> >>> On Wed, Dec 1, 2010 at 2:39 PM, Gary Gregory >>> wrote: On Dec 1, 2010, at 2:01, "Simone Tripodi" wrote: > Hi Gary :) > thanks for the feedback, IMHO once the Configuration for > Generic(Keyed)ObjectPool(Factory) will be fixed, we could start > thinking about a new release of the new pool. This evening/tonight (in > my local time) I'll start re-arranging stuff, of course suggestions > will be more than appreciated. > > About duplication: I agree with you, but after re-reading all the > mails we wrote about it, I recently become convinced that > Configuration for GKOB/GOB have different semantic even if some > configuration property have same name/type, what's your opinion about > it? Many thanks in advance! > Yes, semantics are different iirc and I'd confusing is that some props have >>> the same name but mean different things for each pool type. I am not sure if it worth changing these method names (new method and >>> deprecated old method) or just writing better javadocs. I would go with >>> an >>> experts opinion there. Gary > Have a nice day, > Simo > > http://people.apache.org/~simonetripodi/ > http://www.99soft.org/ > > > > On Tue, Nov 30, 2010 at 11:02 PM, Gary Gregory > wrote: >> Yes, I thought we were on a roll there! Lots of good discussions and >>> then... quiet. That's OK though. We all get busy. Time to come back and >>> reflect. >> >> I am still looking for these goals: >> - Generics released ASAP. I would be OK for a earlier release just >> to get >>> this out. >> - Better names for properties and methods >> - Refactor to remove duplication >> >> Gary >> >>> -Original Mess
Re: [VOTE] Release Commons VFS 2.0
I have modified the release packaging so that the binary release includes release notes generated by the maven-changes-plugin announcement generator. I've excluded doap_vfs.rdf from the src zip, although it isn't clear to me why this is necessary, especially if there is some Maven plugin designed to process it. I have not included release notes in the src zip since my understanding is the src zip should contain the directories pretty much as they exist in SVN. Instead I have added a README.txt that tells a user how to generate the announcement file. I've also updated the site main page to document the compatibility break. Is there anything else that should be done before attempting a final release? Ralph On Dec 6, 2010, at 7:49 AM, sebb wrote: > On 6 December 2010 02:04, Ralph Goers wrote: >> This is a vote to release Apache Commons VFS 2.0. >> >> Since the last candidate the package name was changed from vfs to vfs2. Many >> of the Jira issues were reviewed and those that required a possibly >> incompatible API change were addressed. Most instances of StringBuffer were >> replaced with StringBuilder. Some synchronization issues were addressed. >> Many javadoc and some checkstyle issues were addressed. The filesystem >> documentation was improved to list file system capabilities. >> >> [ ] +1 release it >> [ ] +0 go ahead I don't care >> [X] -1 no, do not release it because... >> >> Ralph >> >> tag: >> https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs2-project-2.0/ >> (revision 1042381). >> >> site: http://people.apache.org/~rgoers/commons-vfs/index.html > > Does not mention that the new release uses a new package name and > requires source updates to use. > Ditto the Maven changes. > > changes.xml has not been updated with a description of the release. > Also, the date will need to be changed at some point. > > I still think we should have tried to maintain binary compatibility - > which I think would have been possible. > However, assuming that the compatibility break is what the majority > wants, this needs to be made very obvious, and there should be upgrade > notes describing how to perform the change. > > IMO there should be some RELEASE_NOTES in the source and binary archives. > > The source archive should probably exclude the DOAP. > >> >> The following artifacts have been staged to the Apache Nexus Staging >> repository org.apache.commons-051 (u:rgoers, a:75.82.178.177) >> https://repository.apache.org/content/repositories/orgapachecommons-051/ >> >> commons-vfs2-examples-2.0-sources.jar >> commons-vfs2-examples-2.0.jar.asc >> commons-vfs2-examples-2.0.pom >> commons-vfs2-examples-2.0-javadoc.jar.asc >> commons-vfs2-examples-2.0.jar >> commons-vfs2-examples-2.0-javadoc.jar >> commons-vfs2-examples-2.0.pom.asc >> commons-vfs2-examples-2.0-sources.jar.asc >> commons-vfs2-project-2.0-site.xml >> commons-vfs2-project-2.0.pom.asc >> commons-vfs2-project-2.0.pom >> commons-vfs2-project-2.0-site.xml.asc >> commons-vfs2-2.0-sources.jar.asc >> commons-vfs2-2.0-tests.jar.asc >> commons-vfs2-2.0-javadoc.jar >> commons-vfs2-2.0.jar.asc >> commons-vfs2-2.0-test-sources.jar.asc >> commons-vfs2-2.0-javadoc.jar.asc >> commons-vfs2-2.0-test-sources.jar >> commons-vfs2-2.0.pom.asc >> commons-vfs2-2.0.jar >> commons-vfs2-2.0.pom >> commons-vfs2-2.0-sources.jar >> commons-vfs2-2.0-tests.jar >> commons-vfs2-sandbox-2.0.pom.asc >> commons-vfs2-sandbox-2.0-javadoc.jar >> commons-vfs2-sandbox-2.0-tests.jar >> commons-vfs2-sandbox-2.0.jar.asc >> commons-vfs2-sandbox-2.0-sources.jar >> commons-vfs2-sandbox-2.0-sources.jar.asc >> commons-vfs2-sandbox-2.0-tests.jar.asc >> commons-vfs2-sandbox-2.0.pom >> commons-vfs2-sandbox-2.0.jar >> commons-vfs2-sandbox-2.0-test-sources.jar.asc >> commons-vfs2-sandbox-2.0-test-sources.jar >> commons-vfs2-sandbox-2.0-javadoc.jar.asc >> commons-vfs2-distribution-2.0-bin.tar.gz.asc >> commons-vfs2-distribution-2.0-src.tar.gz >> commons-vfs2-distribution-2.0-src.zip >> commons-vfs2-distribution-2.0-src.zip.asc >> commons-vfs2-distribution-2.0.pom.asc >> commons-vfs2-distribution-2.0.pom >> commons-vfs2-distribution-2.0-bin.zip >> commons-vfs2-distribution-2.0-src.tar.gz.asc >> commons-vfs2-distribution-2.0-bin.tar.gz >> commons-vfs2-distribution-2.0-bin.zip.asc > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[g...@vmgump]: Project commons-collections4 (in module apache-commons) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at gene...@gump.apache.org. Project commons-collections4 has an issue affecting its community integration. This issue affects 2 projects, and has been outstanding for 14 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-collections4 : Collections - commons-collections4-testframework : Apache Commons Full details are available at: http://vmgump.apache.org/gump/public/apache-commons/commons-collections4/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- (Apache Gump generated) Apache Maven Settings in: /srv/gump/public/workspace/apache-commons/collections/gump_mvn_settings.xml -INFO- Failed with reason build failed -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/collections/pom.xml -DEBUG- Extracted fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/apache-commons/commons-collections4/gump_work/build_apache-commons_commons-collections4.html Work Name: build_apache-commons_commons-collections4 (Type: Build) Work ended in a state of : Failed Elapsed: 24 secs Command Line: /opt/maven2/bin/mvn --batch-mode --settings /srv/gump/public/workspace/apache-commons/collections/gump_mvn_settings.xml package [Working Directory: /srv/gump/public/workspace/apache-commons/collections] M2_HOME: /opt/maven2 - required: org.apache.commons.collections.Closure[] found: org.apache.commons.collections.Closure[] [INFO] 8 errors [INFO] - [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure /srv/gump/public/workspace/apache-commons/collections/src/java/org/apache/commons/collections/functors/SwitchTransformer.java:[68,38] invalid inferred types for T; actual arguments do not conforms to inferred formal arguments required: org.apache.commons.collections.Predicate[] found: org.apache.commons.collections.Predicate[] /srv/gump/public/workspace/apache-commons/collections/src/java/org/apache/commons/collections/functors/SwitchTransformer.java:[69,40] invalid inferred types for I; actual arguments do not conforms to inferred formal arguments required: org.apache.commons.collections.Transformer[] found: org.apache.commons.collections.Transformer[] /srv/gump/public/workspace/apache-commons/collections/src/java/org/apache/commons/collections/functors/OnePredicate.java:[66,38] invalid inferred types for T; actual arguments do not conforms to inferred formal arguments required: org.apache.commons.collections.Predicate[] found: org.apache.commons.collections.Predicate[] /srv/gump/public/workspace/apache-commons/collections/src/java/org/apache/commons/collections/functors/SwitchClosure.java:[66,38] invalid inferred types for T; actual arguments do not conforms to inferred formal arguments required: org.apache.commons.collections.Predicate[] found: org.apache.commons.collections.Predicate[] /srv/gump/public/workspace/apache-commons/collections/src/java/org/apache/commons/collections/functors/SwitchClosure.java:[67,36] invalid inferred types for E; actual arguments do not conforms to inferred formal arguments required: org.apache.commons.collections.Closure[] found: org.apache.commons.collections.Closure[] /srv/gump/public/workspace/apache-commons/collections/src/java/org/apache/commons/collections/functors/ChainedTransformer.java:[56,40] invalid inferred types for I; actual arguments do not conforms to inferred formal arguments required: org.apache.commons.collections.Transformer[] found: org.apache.commons.collections.Transformer[] /srv/gump/public/workspace/apache-commons/collections/src/java/org/apache/commons/collections/functors/NonePredicate.java:[61,38] invalid inferred types for T; actual arguments do not conforms to inferred formal arguments required: org.apache.commons.collections.Predicate[] found: org.apache.commons.collections.Predicate[] /srv/gump/public/workspace/apache-commons/collections/src/java/org/apache/commons/collections/functors/ChainedClosure.java:[53,36] invalid inferred types for E; actual arguments do not conforms to inferred formal arguments required: org.apache.commons.collections.Closure[] found: org.apache.commons.collections.Closure[] [INFO] [INFO] For more information, run Maven with the -e switch [INFO] -
Re: [pool] Refactoring Config classes (Was: [pool] Pool config vs. factory hierarchies.)
Please go ahead as you see fit. I am in the middle of moving now and can only process emails. I am also not sure about the merit of the refactoring anymore. I recall a message casting doubt on this refactoring adventure :) Gary On Dec 20, 2010, at 13:56, "Simone Tripodi" wrote: > Hi Gary, > IMHO the optimizations you're proposing are very important and since I > like cooperating with you, I thought was better making aware about > what I'd intend to do :P > If you agree I could start committing the latest modifications, so you > can apply your refactoring later. WDYT? > Have a nice day, all the best, > Simo > > http://people.apache.org/~simonetripodi/ > http://www.99soft.org/ > > > > On Mon, Dec 20, 2010 at 10:41 PM, Gary Gregory > wrote: >> Don't worry about my stuff. I am in the middle of a move. >> >> Gary >> >> On Dec 20, 2010, at 12:20, "Simone Tripodi" wrote: >> >>> Hi all guys, >>> I spent the afternoon refactoring the config classes according to >>> informations collected on[1], have a ready commit. >>> Do you want to read the patch before I commit or I I can commit so >>> everybody can review and contribute to the modifications? >>> This could block the Gary's work on optimization, please let me know! >>> Thanks in advance, >>> Simo >>> >>> [1] http://wiki.apache.org/commons/PoolRoadMap >>> >>> http://people.apache.org/~simonetripodi/ >>> http://www.99soft.org/ >>> >>> >>> >>> On Sun, Dec 5, 2010 at 2:27 PM, Simone Tripodi >>> wrote: Hi Gary/all :) I collected informations on the wiki on the RoadMap page[1], based on what we discussed in this thread. If you agree on what is written, we can start back coding. Have a nice weekend, Simo [1] http://wiki.apache.org/commons/PoolRoadMap http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Wed, Dec 1, 2010 at 3:21 PM, Gary Gregory wrote: >> -Original Message- >> From: Simone Tripodi [mailto:simone.trip...@gmail.com] >> Sent: Wednesday, December 01, 2010 08:51 >> To: Commons Developers List >> Subject: Re: [pool] Pool config vs. factory hierarchies. >> >> Hi Gary, >> yes, more people involved on defining these details is better, I >> agree. I'm thinking about creating a wiki page to resume all the >> requirements, what do you think? > > Good idea! > > Gary > >> Simo >> >> http://people.apache.org/~simonetripodi/ >> http://www.99soft.org/ >> >> >> >> On Wed, Dec 1, 2010 at 2:39 PM, Gary Gregory >> wrote: >>> On Dec 1, 2010, at 2:01, "Simone Tripodi" >>> wrote: >>> Hi Gary :) thanks for the feedback, IMHO once the Configuration for Generic(Keyed)ObjectPool(Factory) will be fixed, we could start thinking about a new release of the new pool. This evening/tonight (in my local time) I'll start re-arranging stuff, of course suggestions will be more than appreciated. About duplication: I agree with you, but after re-reading all the mails we wrote about it, I recently become convinced that Configuration for GKOB/GOB have different semantic even if some configuration property have same name/type, what's your opinion about it? Many thanks in advance! >>> Yes, semantics are different iirc and I'd confusing is that some props >>> have >> the same name but mean different things for each pool type. >>> >>> I am not sure if it worth changing these method names (new method and >> deprecated old method) or just writing better javadocs. I would go with >> an >> experts opinion there. >>> >>> Gary Have a nice day, Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Tue, Nov 30, 2010 at 11:02 PM, Gary Gregory wrote: > Yes, I thought we were on a roll there! Lots of good discussions and >> then... quiet. That's OK though. We all get busy. Time to come back and >> reflect. > > I am still looking for these goals: > - Generics released ASAP. I would be OK for a earlier release just to > get >> this out. > - Better names for properties and methods > - Refactor to remove duplication > > Gary > >> -Original Message- >> From: Simone Tripodi [mailto:simone.trip...@gmail.com] >> Sent: Tuesday, November 30, 2010 09:33 >> To: Commons Developers List >> Subject: Re: [pool] Pool config vs. factory hierarchies. >> >> Hi all guys, >> sorry for resurrecting a zombie message, but I've been busy at work >> and haven't had the chance to contribute at all. >> I could re-start committing code acco
Re: svn commit: r1051300 - /commons/proper/pool/trunk/src/test/org/apache/commons/pool2/impl/TestStackObjectPool.java
Cool!!! thanks for taking care!
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Mon, Dec 20, 2010 at 11:05 PM, wrote:
> Author: sebb
> Date: Mon Dec 20 22:05:42 2010
> New Revision: 1051300
>
> URL: http://svn.apache.org/viewvc?rev=1051300&view=rev
> Log:
> Add some IAE tests for null ctor parameters
>
> Modified:
>
> commons/proper/pool/trunk/src/test/org/apache/commons/pool2/impl/TestStackObjectPool.java
>
> Modified:
> commons/proper/pool/trunk/src/test/org/apache/commons/pool2/impl/TestStackObjectPool.java
> URL:
> http://svn.apache.org/viewvc/commons/proper/pool/trunk/src/test/org/apache/commons/pool2/impl/TestStackObjectPool.java?rev=1051300&r1=1051299&r2=1051300&view=diff
> ==
> ---
> commons/proper/pool/trunk/src/test/org/apache/commons/pool2/impl/TestStackObjectPool.java
> (original)
> +++
> commons/proper/pool/trunk/src/test/org/apache/commons/pool2/impl/TestStackObjectPool.java
> Mon Dec 20 22:05:42 2010
> @@ -174,6 +174,23 @@ public class TestStackObjectPool extends
> }
> }
>
> + �...@test(expected=IllegalArgumentException.class)
> + public void testNullFactory1(){
> + new StackObjectPool(null);
> + }
> +
> + �...@test(expected=IllegalArgumentException.class)
> + public void testNullFactory2(){
> + new StackObjectPool(null, null);
> + }
> +
> + �...@test(expected=IllegalArgumentException.class)
> + public void testNullFactory3(){
> + PoolableObjectFactory factory = new SelectiveFactory();
> + new StackObjectPool(factory, null);
> + }
> +
> + /**
> /**
> * Verify that out of range constructor arguments are ignored.
> */
>
>
>
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [pool] Refactoring Config classes (Was: [pool] Pool config vs. factory hierarchies.)
Hi Gary, IMHO the optimizations you're proposing are very important and since I like cooperating with you, I thought was better making aware about what I'd intend to do :P If you agree I could start committing the latest modifications, so you can apply your refactoring later. WDYT? Have a nice day, all the best, Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Mon, Dec 20, 2010 at 10:41 PM, Gary Gregory wrote: > Don't worry about my stuff. I am in the middle of a move. > > Gary > > On Dec 20, 2010, at 12:20, "Simone Tripodi" wrote: > >> Hi all guys, >> I spent the afternoon refactoring the config classes according to >> informations collected on[1], have a ready commit. >> Do you want to read the patch before I commit or I I can commit so >> everybody can review and contribute to the modifications? >> This could block the Gary's work on optimization, please let me know! >> Thanks in advance, >> Simo >> >> [1] http://wiki.apache.org/commons/PoolRoadMap >> >> http://people.apache.org/~simonetripodi/ >> http://www.99soft.org/ >> >> >> >> On Sun, Dec 5, 2010 at 2:27 PM, Simone Tripodi >> wrote: >>> Hi Gary/all :) >>> I collected informations on the wiki on the RoadMap page[1], based on >>> what we discussed in this thread. >>> If you agree on what is written, we can start back coding. >>> Have a nice weekend, >>> Simo >>> >>> [1] http://wiki.apache.org/commons/PoolRoadMap >>> >>> http://people.apache.org/~simonetripodi/ >>> http://www.99soft.org/ >>> >>> >>> >>> On Wed, Dec 1, 2010 at 3:21 PM, Gary Gregory >>> wrote: > -Original Message- > From: Simone Tripodi [mailto:simone.trip...@gmail.com] > Sent: Wednesday, December 01, 2010 08:51 > To: Commons Developers List > Subject: Re: [pool] Pool config vs. factory hierarchies. > > Hi Gary, > yes, more people involved on defining these details is better, I > agree. I'm thinking about creating a wiki page to resume all the > requirements, what do you think? Good idea! Gary > Simo > > http://people.apache.org/~simonetripodi/ > http://www.99soft.org/ > > > > On Wed, Dec 1, 2010 at 2:39 PM, Gary Gregory > wrote: >> On Dec 1, 2010, at 2:01, "Simone Tripodi" >> wrote: >> >>> Hi Gary :) >>> thanks for the feedback, IMHO once the Configuration for >>> Generic(Keyed)ObjectPool(Factory) will be fixed, we could start >>> thinking about a new release of the new pool. This evening/tonight (in >>> my local time) I'll start re-arranging stuff, of course suggestions >>> will be more than appreciated. >>> >>> About duplication: I agree with you, but after re-reading all the >>> mails we wrote about it, I recently become convinced that >>> Configuration for GKOB/GOB have different semantic even if some >>> configuration property have same name/type, what's your opinion about >>> it? Many thanks in advance! >>> >> Yes, semantics are different iirc and I'd confusing is that some props >> have > the same name but mean different things for each pool type. >> >> I am not sure if it worth changing these method names (new method and > deprecated old method) or just writing better javadocs. I would go with an > experts opinion there. >> >> Gary >>> Have a nice day, >>> Simo >>> >>> http://people.apache.org/~simonetripodi/ >>> http://www.99soft.org/ >>> >>> >>> >>> On Tue, Nov 30, 2010 at 11:02 PM, Gary Gregory >>> wrote: Yes, I thought we were on a roll there! Lots of good discussions and > then... quiet. That's OK though. We all get busy. Time to come back and > reflect. I am still looking for these goals: - Generics released ASAP. I would be OK for a earlier release just to get > this out. - Better names for properties and methods - Refactor to remove duplication Gary > -Original Message- > From: Simone Tripodi [mailto:simone.trip...@gmail.com] > Sent: Tuesday, November 30, 2010 09:33 > To: Commons Developers List > Subject: Re: [pool] Pool config vs. factory hierarchies. > > Hi all guys, > sorry for resurrecting a zombie message, but I've been busy at work > and haven't had the chance to contribute at all. > I could re-start committing code according to the requirements > described by Phil, If it works for you, so other tasks like > JMX/autoconfigure can be unlocked, please let me know. > Have a nice day, > Simo > > http://people.apache.org/~simonetripodi/ > http://www.99soft.org/ > > > > On Wed, Nov 3, 2010 at 11:01 PM, Phil Steitz > wrote: >> >> >> >> >> On Nov 3, 2010, at 5:03 PM, Steve
Re: [pool] Refactoring Config classes (Was: [pool] Pool config vs. factory hierarchies.)
Don't worry about my stuff. I am in the middle of a move.
Gary
On Dec 20, 2010, at 12:20, "Simone Tripodi" wrote:
> Hi all guys,
> I spent the afternoon refactoring the config classes according to
> informations collected on[1], have a ready commit.
> Do you want to read the patch before I commit or I I can commit so
> everybody can review and contribute to the modifications?
> This could block the Gary's work on optimization, please let me know!
> Thanks in advance,
> Simo
>
> [1] http://wiki.apache.org/commons/PoolRoadMap
>
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>
>
>
> On Sun, Dec 5, 2010 at 2:27 PM, Simone Tripodi
> wrote:
>> Hi Gary/all :)
>> I collected informations on the wiki on the RoadMap page[1], based on
>> what we discussed in this thread.
>> If you agree on what is written, we can start back coding.
>> Have a nice weekend,
>> Simo
>>
>> [1] http://wiki.apache.org/commons/PoolRoadMap
>>
>> http://people.apache.org/~simonetripodi/
>> http://www.99soft.org/
>>
>>
>>
>> On Wed, Dec 1, 2010 at 3:21 PM, Gary Gregory
>> wrote:
-Original Message-
From: Simone Tripodi [mailto:simone.trip...@gmail.com]
Sent: Wednesday, December 01, 2010 08:51
To: Commons Developers List
Subject: Re: [pool] Pool config vs. factory hierarchies.
Hi Gary,
yes, more people involved on defining these details is better, I
agree. I'm thinking about creating a wiki page to resume all the
requirements, what do you think?
>>>
>>> Good idea!
>>>
>>> Gary
>>>
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Wed, Dec 1, 2010 at 2:39 PM, Gary Gregory
wrote:
> On Dec 1, 2010, at 2:01, "Simone Tripodi"
> wrote:
>
>> Hi Gary :)
>> thanks for the feedback, IMHO once the Configuration for
>> Generic(Keyed)ObjectPool(Factory) will be fixed, we could start
>> thinking about a new release of the new pool. This evening/tonight (in
>> my local time) I'll start re-arranging stuff, of course suggestions
>> will be more than appreciated.
>>
>> About duplication: I agree with you, but after re-reading all the
>> mails we wrote about it, I recently become convinced that
>> Configuration for GKOB/GOB have different semantic even if some
>> configuration property have same name/type, what's your opinion about
>> it? Many thanks in advance!
>>
> Yes, semantics are different iirc and I'd confusing is that some props
> have
the same name but mean different things for each pool type.
>
> I am not sure if it worth changing these method names (new method and
deprecated old method) or just writing better javadocs. I would go with an
experts opinion there.
>
> Gary
>> Have a nice day,
>> Simo
>>
>> http://people.apache.org/~simonetripodi/
>> http://www.99soft.org/
>>
>>
>>
>> On Tue, Nov 30, 2010 at 11:02 PM, Gary Gregory
>> wrote:
>>> Yes, I thought we were on a roll there! Lots of good discussions and
then... quiet. That's OK though. We all get busy. Time to come back and
reflect.
>>>
>>> I am still looking for these goals:
>>> - Generics released ASAP. I would be OK for a earlier release just to
>>> get
this out.
>>> - Better names for properties and methods
>>> - Refactor to remove duplication
>>>
>>> Gary
>>>
-Original Message-
From: Simone Tripodi [mailto:simone.trip...@gmail.com]
Sent: Tuesday, November 30, 2010 09:33
To: Commons Developers List
Subject: Re: [pool] Pool config vs. factory hierarchies.
Hi all guys,
sorry for resurrecting a zombie message, but I've been busy at work
and haven't had the chance to contribute at all.
I could re-start committing code according to the requirements
described by Phil, If it works for you, so other tasks like
JMX/autoconfigure can be unlocked, please let me know.
Have a nice day,
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Wed, Nov 3, 2010 at 11:01 PM, Phil Steitz
wrote:
>
>
>
>
> On Nov 3, 2010, at 5:03 PM, Steven Siebert wrote:
>
>>>
>>>
>>> You restore the pool fields that used to hold the configuration
setting
>>> properties and leave the getters and setters (for the mutable ones)
>>> in
>>> place.
>>>
>>> Phil
>>>
>>>
>> so something like this?
>>
>> public class GOP extends {
>>
>> /**
>>* ref to immutable config reference, immutable config values are
either
>> referred
[continuum] BUILD FAILURE: Apache Commons - Commons Pool - Default Maven 2 Build Definition (Java 1.5)
Online report : http://vmbuild.apache.org/continuum/buildResult.action?buildId=2206&projectId=98 Build statistics: State: Failed Previous State: Ok Started at: Mon 20 Dec 2010 20:29:53 + Finished at: Mon 20 Dec 2010 20:48:08 + Total time: 18m 14s Build Trigger: Schedule Build Number: 52 Exit code: 1 Building machine hostname: vmbuild Operating system : Linux(unknown) Java Home version : java version "1.6.0_20" Java(TM) SE Runtime Environment (build 1.6.0_20-b02) Java HotSpot(TM) 64-Bit Server VM (build 16.3-b01, mixed mode) Builder version : Apache Maven 2.2.1 (r801777; 2009-08-06 19:16:01+) Java version: 1.6.0_20 Java home: /usr/lib/jvm/java-6-sun-1.6.0.20/jre Default locale: en_US, platform encoding: ANSI_X3.4-1968 OS name: "linux" version: "2.6.32-24-server" arch: "amd64" Family: "unix" SCM Changes: Changed: simonetripodi @ Mon 20 Dec 2010 20:16:23 + Comment: fixed IAE in broken tests Files changed: /commons/proper/pool/trunk/src/test/org/apache/commons/pool2/impl/TestStackObjectPool.java ( 1051273 ) Dependencies Changes: No dependencies changed Build Definition: POM filename: pom.xml Goals: clean install Arguments: --batch-mode -Pjava-1.5 Build Fresh: false Always Build: false Default Build Definition: true Schedule: COMMONS_SCHEDULE Profile Name: Maven 2.2.1 Description: Default Maven 2 Build Definition (Java 1.5) Test Summary: Tests: 227 Failures: 1 Errors: 0 Success Rate: 99 Total time: 1056.327 Test Failures: TestGenericObjectPool testBorrowObjectFairness : java.lang.AssertionError java.lang.AssertionError: Thread 18 failed: java.lang.Throwable: Expected: 8 found: 9 at org.junit.Assert.fail(Assert.java:91) at org.apache.commons.pool2.impl.TestGenericObjectPool.testBorrowObjectFairness(TestGenericObjectPool.java:1504) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:592) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31) at org.junit.runners.BlockJUnit4ClassRunner.runNotIgnored(BlockJUnit4ClassRunner.java:79) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:71) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:49) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184) at org.junit.runners.ParentRunner.run(ParentRunner.java:236) at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:59) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:115) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:102) at org.apache.maven.surefire.Surefire.run(Surefire.java:180) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Me
[continuum] BUILD FAILURE: Apache Commons - Commons Collections - Default Maven 2 Build Definition (Java 1.5)
Online report : http://vmbuild.apache.org/continuum/buildResult.action?buildId=2204&projectId=71 Build statistics: State: Failed Previous State: Ok Started at: Mon 20 Dec 2010 20:20:29 + Finished at: Mon 20 Dec 2010 20:24:40 + Total time: 4m 11s Build Trigger: Schedule Build Number: 23 Exit code: 1 Building machine hostname: vmbuild Operating system : Linux(unknown) Java Home version : java version "1.6.0_20" Java(TM) SE Runtime Environment (build 1.6.0_20-b02) Java HotSpot(TM) 64-Bit Server VM (build 16.3-b01, mixed mode) Builder version : Apache Maven 2.2.1 (r801777; 2009-08-06 19:16:01+) Java version: 1.6.0_20 Java home: /usr/lib/jvm/java-6-sun-1.6.0.20/jre Default locale: en_US, platform encoding: ANSI_X3.4-1968 OS name: "linux" version: "2.6.32-24-server" arch: "amd64" Family: "unix" SCM Changes: Changed: sebb @ Mon 20 Dec 2010 19:24:29 + Comment: COLLECTIONS-363 TransformedMap is Serializable but its superclass doesn't define an accessible void constructor Files changed: /commons/proper/collections/trunk/src/java/org/apache/commons/collections/splitmap/AbstractIterableGetMapDecorator.java ( 1051248 ) /commons/proper/collections/trunk/src/test/org/apache/commons/collections/splitmap/TestTransformedMap.java ( 1051248 ) Dependencies Changes: No dependencies changed Build Definition: POM filename: pom.xml Goals: clean install Arguments: --batch-mode -Pjava-1.5 Build Fresh: false Always Build: false Default Build Definition: true Schedule: COMMONS_SCHEDULE Profile Name: Maven 2.2.1 Description: Default Maven 2 Build Definition (Java 1.5) Test Summary: Tests: 11010 Failures: 0 Errors: 2 Success Rate: 99 Total time: 55.271 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[pool] Refactoring Config classes (Was: [pool] Pool config vs. factory hierarchies.)
Hi all guys,
I spent the afternoon refactoring the config classes according to
informations collected on[1], have a ready commit.
Do you want to read the patch before I commit or I I can commit so
everybody can review and contribute to the modifications?
This could block the Gary's work on optimization, please let me know!
Thanks in advance,
Simo
[1] http://wiki.apache.org/commons/PoolRoadMap
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Sun, Dec 5, 2010 at 2:27 PM, Simone Tripodi wrote:
> Hi Gary/all :)
> I collected informations on the wiki on the RoadMap page[1], based on
> what we discussed in this thread.
> If you agree on what is written, we can start back coding.
> Have a nice weekend,
> Simo
>
> [1] http://wiki.apache.org/commons/PoolRoadMap
>
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>
>
>
> On Wed, Dec 1, 2010 at 3:21 PM, Gary Gregory
> wrote:
>>> -Original Message-
>>> From: Simone Tripodi [mailto:simone.trip...@gmail.com]
>>> Sent: Wednesday, December 01, 2010 08:51
>>> To: Commons Developers List
>>> Subject: Re: [pool] Pool config vs. factory hierarchies.
>>>
>>> Hi Gary,
>>> yes, more people involved on defining these details is better, I
>>> agree. I'm thinking about creating a wiki page to resume all the
>>> requirements, what do you think?
>>
>> Good idea!
>>
>> Gary
>>
>>> Simo
>>>
>>> http://people.apache.org/~simonetripodi/
>>> http://www.99soft.org/
>>>
>>>
>>>
>>> On Wed, Dec 1, 2010 at 2:39 PM, Gary Gregory
>>> wrote:
>>> > On Dec 1, 2010, at 2:01, "Simone Tripodi"
>>> > wrote:
>>> >
>>> >> Hi Gary :)
>>> >> thanks for the feedback, IMHO once the Configuration for
>>> >> Generic(Keyed)ObjectPool(Factory) will be fixed, we could start
>>> >> thinking about a new release of the new pool. This evening/tonight (in
>>> >> my local time) I'll start re-arranging stuff, of course suggestions
>>> >> will be more than appreciated.
>>> >>
>>> >> About duplication: I agree with you, but after re-reading all the
>>> >> mails we wrote about it, I recently become convinced that
>>> >> Configuration for GKOB/GOB have different semantic even if some
>>> >> configuration property have same name/type, what's your opinion about
>>> >> it? Many thanks in advance!
>>> >>
>>> > Yes, semantics are different iirc and I'd confusing is that some props
>>> > have
>>> the same name but mean different things for each pool type.
>>> >
>>> > I am not sure if it worth changing these method names (new method and
>>> deprecated old method) or just writing better javadocs. I would go with an
>>> experts opinion there.
>>> >
>>> > Gary
>>> >> Have a nice day,
>>> >> Simo
>>> >>
>>> >> http://people.apache.org/~simonetripodi/
>>> >> http://www.99soft.org/
>>> >>
>>> >>
>>> >>
>>> >> On Tue, Nov 30, 2010 at 11:02 PM, Gary Gregory
>>> >> wrote:
>>> >>> Yes, I thought we were on a roll there! Lots of good discussions and
>>> then... quiet. That's OK though. We all get busy. Time to come back and
>>> reflect.
>>> >>>
>>> >>> I am still looking for these goals:
>>> >>> - Generics released ASAP. I would be OK for a earlier release just to
>>> >>> get
>>> this out.
>>> >>> - Better names for properties and methods
>>> >>> - Refactor to remove duplication
>>> >>>
>>> >>> Gary
>>> >>>
>>> -Original Message-
>>> From: Simone Tripodi [mailto:simone.trip...@gmail.com]
>>> Sent: Tuesday, November 30, 2010 09:33
>>> To: Commons Developers List
>>> Subject: Re: [pool] Pool config vs. factory hierarchies.
>>>
>>> Hi all guys,
>>> sorry for resurrecting a zombie message, but I've been busy at work
>>> and haven't had the chance to contribute at all.
>>> I could re-start committing code according to the requirements
>>> described by Phil, If it works for you, so other tasks like
>>> JMX/autoconfigure can be unlocked, please let me know.
>>> Have a nice day,
>>> Simo
>>>
>>> http://people.apache.org/~simonetripodi/
>>> http://www.99soft.org/
>>>
>>>
>>>
>>> On Wed, Nov 3, 2010 at 11:01 PM, Phil Steitz
>>> wrote:
>>> >
>>> >
>>> >
>>> >
>>> > On Nov 3, 2010, at 5:03 PM, Steven Siebert wrote:
>>> >
>>> >>>
>>> >>>
>>> >>> You restore the pool fields that used to hold the configuration
>>> setting
>>> >>> properties and leave the getters and setters (for the mutable ones)
>>> >>> in
>>> >>> place.
>>> >>>
>>> >>> Phil
>>> >>>
>>> >>>
>>> >> so something like this?
>>> >>
>>> >> public class GOP extends {
>>> >>
>>> >> /**
>>> >> * ref to immutable config reference, immutable config values are
>>> either
>>> >> referred directly here
>>> >> * or are copied to a final instance field
>>> >> */
>>> >> private GOPConfig config
>>> >
>>> > No. There is no config member. It is used only to encapsulate the
>>> parameters of the ctors.
Re: svn commit: r1051146 - in /commons/proper/daemon/trunk/src/native/windows/src: service.c utils.c
On 20 December 2010 15:35, wrote:
> Author: mturk
> Date: Mon Dec 20 15:35:15 2010
> New Revision: 1051146
>
> URL: http://svn.apache.org/viewvc?rev=1051146&view=rev
> Log:
> Combine core dependencies with --DependsOn cmdline
>
> Modified:
> commons/proper/daemon/trunk/src/native/windows/src/service.c
> commons/proper/daemon/trunk/src/native/windows/src/utils.c
The change to utils.c seems to be an unrelated bug fix?
> Modified: commons/proper/daemon/trunk/src/native/windows/src/service.c
> URL:
> http://svn.apache.org/viewvc/commons/proper/daemon/trunk/src/native/windows/src/service.c?rev=1051146&r1=1051145&r2=1051146&view=diff
> ==
> --- commons/proper/daemon/trunk/src/native/windows/src/service.c (original)
> +++ commons/proper/daemon/trunk/src/native/windows/src/service.c Mon Dec 20
> 15:35:15 2010
> @@ -517,6 +517,11 @@ apxServiceInstall(APXHANDLE hService, LP
> lpService->stServiceEntry.lpConfig = NULL;
> AplZeroMemory(&lpService->stServiceEntry, sizeof(APXSERVENTRY));
>
> + if (lpDependencies)
> + lpDependencies = apxMultiSzCombine(NULL, lpDependencies,
> + L"Tcpip\0Afd\0", NULL);
> + else
> + lpDependencies = L"Tcpip\0Afd\0";
> lpService->hService = CreateServiceW(lpService->hManager,
> szServiceName,
> szDisplayName,
> @@ -527,7 +532,7 @@ apxServiceInstall(APXHANDLE hService, LP
> szImagePath,
> NULL,
> NULL,
> - lpDependencies ? lpDependencies :
> L"Tcpip\0Afd\0",
> + lpDependencies,
> NULL,
> NULL);
>
>
> Modified: commons/proper/daemon/trunk/src/native/windows/src/utils.c
> URL:
> http://svn.apache.org/viewvc/commons/proper/daemon/trunk/src/native/windows/src/utils.c?rev=1051146&r1=1051145&r2=1051146&view=diff
> ==
> --- commons/proper/daemon/trunk/src/native/windows/src/utils.c (original)
> +++ commons/proper/daemon/trunk/src/native/windows/src/utils.c Mon Dec 20
> 15:35:15 2010
> @@ -256,7 +256,7 @@ LPWSTR apxMultiSzCombine(APXHANDLE hPool
> if (lb) {
> AplMoveMemory(&rv[la], lpStrB, lb * sizeof(WCHAR));
> }
> - if (*lpdwLength)
> + if (lpdwLength)
Is this a different bug fix?
> *lpdwLength = (la + lb + 1) * sizeof(WCHAR);
> return rv;
> }
>
>
>
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1051138 - in /commons/proper/daemon/trunk: RELEASE-NOTES.txt src/native/windows/src/service.c
On 20 December 2010 15:08, wrote:
> Author: mturk
> Date: Mon Dec 20 15:08:21 2010
> New Revision: 1051138
>
> URL: http://svn.apache.org/viewvc?rev=1051138&view=rev
> Log:
> DAEMON-190: Make sure we have default system dependent services
>
> Modified:
> commons/proper/daemon/trunk/RELEASE-NOTES.txt
> commons/proper/daemon/trunk/src/native/windows/src/service.c
>
> Modified: commons/proper/daemon/trunk/RELEASE-NOTES.txt
> URL:
> http://svn.apache.org/viewvc/commons/proper/daemon/trunk/RELEASE-NOTES.txt?rev=1051138&r1=1051137&r2=1051138&view=diff
> ==
> --- commons/proper/daemon/trunk/RELEASE-NOTES.txt (original)
> +++ commons/proper/daemon/trunk/RELEASE-NOTES.txt Mon Dec 20 15:08:21 2010
> @@ -70,7 +70,7 @@ NEW FEATURES:
>
> BUG FIXES:
>
> -1.0.5: DAEMON-188
> +1.0.5: DAEMON-188, DAEMON-190
>
> 1.0.4: DAEMON-95, DAEMON-171, DAEMON-100, DAEMON-164, DAEMON-165, DAEMON-175,
> DAEMON-177, DAEMON-150, DAEMON-163, DAEMON-182, DAEMON-181
>
> Modified: commons/proper/daemon/trunk/src/native/windows/src/service.c
> URL:
> http://svn.apache.org/viewvc/commons/proper/daemon/trunk/src/native/windows/src/service.c?rev=1051138&r1=1051137&r2=1051138&view=diff
> ==
> --- commons/proper/daemon/trunk/src/native/windows/src/service.c (original)
> +++ commons/proper/daemon/trunk/src/native/windows/src/service.c Mon Dec 20
> 15:08:21 2010
> @@ -249,7 +249,7 @@ __apxStopDependentServices(LPAPXSERVICE
> DWORD dwBytesNeeded;
> DWORD dwCount;
>
> - LPENUM_SERVICE_STATUS lpDependencies = NULL;
> + LPENUM_SERVICE_STATUSW lpDependencies = NULL;
> ENUM_SERVICE_STATUS ess;
> SC_HANDLE hDepService;
> SERVICE_STATUS_PROCESS ssp;
> @@ -260,11 +260,11 @@ __apxStopDependentServices(LPAPXSERVICE
>
> /* Pass a zero-length buffer to get the required buffer size.
> */
> - if (EnumDependentServices(lpService->hService,
> - SERVICE_ACTIVE,
> - lpDependencies, 0,
> - &dwBytesNeeded,
> - &dwCount)) {
> + if (EnumDependentServicesW(lpService->hService,
> + SERVICE_ACTIVE,
> + lpDependencies, 0,
> + &dwBytesNeeded,
> + &dwCount)) {
> /* If the Enum call succeeds, then there are no dependent
> * services, so do nothing.
> */
> @@ -284,24 +284,26 @@ __apxStopDependentServices(LPAPXSERVICE
>
> __try {
> /* Enumerate the dependencies. */
> - if (!EnumDependentServices(lpService->hService,
> - SERVICE_ACTIVE,
> - lpDependencies,
> - dwBytesNeeded,
> - &dwBytesNeeded,
> - &dwCount))
> + if (!EnumDependentServicesW(lpService->hService,
> + SERVICE_ACTIVE,
> + lpDependencies,
> + dwBytesNeeded,
> + &dwBytesNeeded,
> + &dwCount))
> return FALSE;
>
> for (i = 0; i < dwCount; i++) {
> ess = *(lpDependencies + i);
> /* Open the service. */
> - hDepService = OpenService(lpService->hManager,
> - ess.lpServiceName,
> - SERVICE_STOP |
> SERVICE_QUERY_STATUS);
> + hDepService = OpenServiceW(lpService->hManager,
> + ess.lpServiceName,
> + SERVICE_STOP |
> SERVICE_QUERY_STATUS);
>
> if (!hDepService)
> - return FALSE;
> -
> + continue;
> + if (lstrcmpiW(ess.lpServiceName, L"Tcpip") == 0 ||
> + lstrcmpiW(ess.lpServiceName, L"Afd") == 0)
> + continue;
Not sure I understand how Tcpip or Afd can ever appear here - surely
the "ess" field is set to the list of services that depend on the
Daemon service?
> __try {
> /* Send a stop code. */
> if (!ControlService(hDepService,
> @@ -525,7 +527,7 @@ apxServiceInstall(APXHANDLE hService, LP
> szImagePath,
> NULL,
> NULL,
> - lpDependencies,
> + lpDependencies ? lpDependencies :
> L"Tcpip\0Afd\0",
>
Re: [collections] Proposed patch to [#COLLECTIONS-363]
Oh yeah, I did. I'm currently working on it. Thanks for noticing. 2010/12/20 Ted Dunning > Did you see the comment on that JIRA that asked for a test case? > > On Sun, Dec 19, 2010 at 11:07 PM, Igor Saprykin > wrote: > > > Hello. > > > > One week ago I proposed a patch to the issue #363 ( > > https://issues.apache.org/jira/browse/COLLECTIONS-363 ). > > > > I didn't see any relevant activity though. It is my first patch to apache > > projects and i'm trying to understand how everybody works here. I also > > understand that apache developers may be busy or the issue may be not > > important enough. But I'd really like to have some feedback about > > correctness of my patch (solution to the issue seemed really > > straightforward > > to me). > > > > Happy holidays, > > Igor Saprykin > > >
Re: [collections] Proposed patch to [#COLLECTIONS-363]
Did you see the comment on that JIRA that asked for a test case? On Sun, Dec 19, 2010 at 11:07 PM, Igor Saprykin wrote: > Hello. > > One week ago I proposed a patch to the issue #363 ( > https://issues.apache.org/jira/browse/COLLECTIONS-363 ). > > I didn't see any relevant activity though. It is my first patch to apache > projects and i'm trying to understand how everybody works here. I also > understand that apache developers may be busy or the issue may be not > important enough. But I'd really like to have some feedback about > correctness of my patch (solution to the issue seemed really > straightforward > to me). > > Happy holidays, > Igor Saprykin >
[collections] Proposed patch to [#COLLECTIONS-363]
Hello. One week ago I proposed a patch to the issue #363 ( https://issues.apache.org/jira/browse/COLLECTIONS-363 ). I didn't see any relevant activity though. It is my first patch to apache projects and i'm trying to understand how everybody works here. I also understand that apache developers may be busy or the issue may be not important enough. But I'd really like to have some feedback about correctness of my patch (solution to the issue seemed really straightforward to me). Happy holidays, Igor Saprykin
[collections] Proposed patch to [#COLLECTIONS-363]
Hello. One week ago I proposed a patch to the issue #363 ( https://issues.apache.org/jira/browse/COLLECTIONS-363 ). I didn't see any relevant activity though. It is my first patch to apache projects and i'm trying to understand how everybody works here. I also understand that apache developers may be busy or the issue may be not important enough. But I'd really like to have some feedback about correctness of my patch (solution to the issue seemed really straightforward to me). Happy holidays, Igor Saprykin
