[ANNOUNCE] Apache Commons Digester 3.2 released!
The Apache Commons team is pleased to announce the Apache Commons Digester 3.2 release! The Apache Commons Digester package lets you configure an XML to Java object mapping module which triggers certain actions called ruleswhenever a particular pattern of nested XML elements is recognized. The Apache Commons Digester 3.2 is a maintenance release, offering the most innovative feature ever, allowing objects instantiation via arbitrary constructors and not just using the default empty one. NEW FEATURES = * [DIGESTER-153] Add Constructor support to ObjectCreateRule. BUGS FIXED SINCE PREVIOUS RELEASE === * [DIGESTER-159] */object-param-rule is not managed in the XML rules. * [DIGESTER-155] ClassLoader reference set to DigesterLoader not set in produced Digester instances * [DIGESTER-154] The DigesterBinder is not able to load primitive classes by name IMPROVEMENTS OVER PREVIOUS RELEASE === * [DIGESTER-160] provide an additional artifact with shaded dependencies * [DIGESTER-157] Improve Set(Nested)PropertiesRuleAlias performances in the XML ruleset while binding rules * [DIGESTER-156] Make (Nested|Set)PropertiesBuilder#addAlias() fluent. * [DIGESTER-152] The DigesterLoader doesn't allow binding a default Locator * [DIGESTER-151] The DigesterLoader doesn't allow binding a default ErrorHandler. Have fun!-Simo, on behalf of the Apache Commons PMC http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[POOL2] [Keyed]ObjectPoolFactory mutability and DBCP/JNDI
I'm trying to establish the mutability needs of the [Keyed]ObjectPoolFactory implementations, i.e. Generic[Keyed]ObjectPoolFactory I've looked at DBCP 1.4, which uses POOL 1.x. DBCP 1.4 currently creates an instance of GenericKeyedObjectPoolFactory, which it then uses via the interface KeyedObjectPoolFactory. [This is in the class BasicDataSource.] The additional GKOPF getters, and the protected mutable variables are not actually used by DBCP; it only needs to create the instance of KeyedObjectPoolFactory. There is no indication that DBCP needs to change or even inspect the factory settings once it is created. The factory setters were added in POOL2; if they were not needed for DBCP in POOL 1.X, so are they really needed in POOL 2.x? I already removed them as part of making the classes thread-safe; the question is, are the setters now needed in POOL 2? If so, they can be restored, but synch./volatile will need to be added, as I assume the factories must be thread-safe. Indeed, are the getters even needed? The Pool 1.x code did provide getters, but AFAICT they were not used by DBCP. The calling code knows what it used to create the factory, and the factory is subsequently used as an instance of the interface - which only provides the createPool() method. Is there really a need for other code to find out what the original factory settings were? Can the getters be removed? Do the setters have to be restored? - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Graph] On graph weight type(s)
Hi, trying to put it all together (thanks James, Matthew): * WeightedW is fully generic without restrictions on the type of weight W * different properties of weights are specified with interfaces: e.g. Summable, HasZero, Comparable... * each algorithm requires the weights to implement one or more of the above interfaces based on needs, and only works with related methods abstracting from the actual type of weight. For example sum(W weight) for Summable. this is interesting - at a first read looked like an over engineered layer, but it perfectly model the weight domain... can you provide a patch containing such classes and see them in action in current implemented algos? of course I can, hopefully later this week. And you're right, it sounds over-engineered. But it also gives much more freedom to the end user, so maybe in the future someone could say thanks ;) Now, IFF you like that... what shall we do with Double, Integer, etc? uhm I think we can get rid of them, this is something depending on the domain in which algorithms are applied. Well, ideally the user should be able to use seamlessly all the wrappers for primitive number types: i.e., a graph with edges that implement WeightedDouble should just work the way it is as an input for Dijkstra. But of course Double co are legacy that have nothing to do with our fresh interfaces (Summable co). So there are at least two alternatives: * The user has to wrap primitive types into classes that implement the appropriate interfaces, in order to speak the same language of the algorithm implementations. Some of these classes could of course be provided in the library (e.g. DoubleWeight, IntegerWeight). * The algorithms offer additional signatures for the same method that are legacy-compatible to some extent (e.g. only for Double and Integer), and then take care of the conversion internally. I would go for the second one, because 'ignorance is bliss' for the user :) Comments? Claudio Looking forward to hear from you soon! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Claudio Squarcella PhD student at Roma Tre University E-mail address: squar...@dia.uniroma3.it Phone: +39-06-57333215 Fax: +39-06-57333612 http://www.dia.uniroma3.it/~squarcel - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Graph] On graph weight type(s)
I don't like the idea of pushing the adding, comparing, etc. into the
weights. I like the idea of having operations external to the weights
that take care of that stuff.
On Tue, Dec 13, 2011 at 12:35 PM, Claudio Squarcella
squar...@dia.uniroma3.it wrote:
Hey Simone,
On 12/12/2011 18:35, Simone Tripodi wrote:
Hi James!
yes, actual Dijkstra implementation[1] uses Double number to
accumulating the total path weights...
I think Having an accumulator would be helpful! How do you would
modify the current implementation - even with pseudo-code?
trying to put it all together (thanks James, Matthew):
* WeightedW is fully generic without restrictions on the type of
weight W
* different properties of weights are specified with interfaces: e.g.
Summable, HasZero, Comparable...
* each algorithm requires the weights to implement one or more of the
above interfaces based on needs, and only works with related methods
abstracting from the actual type of weight. For example sum(W
weight) for Summable.
Now, IFF you like that... what shall we do with Double, Integer, etc?
Claudio
TIA, all the best,
-Simo
[1]
https://svn.apache.org/repos/asf/commons/sandbox/graph/trunk/src/main/java/org/apache/commons/graph/shortestpath/Dijkstra.java
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Mon, Dec 12, 2011 at 6:27 PM, James Carman
ja...@carmanconsulting.com wrote:
Why do you need doubles for Dijkstra? Accumulating the total path
weights? Why not introduce an Accumulator interface?
On Dec 12, 2011 9:32 AM, Claudio Squarcellasquar...@dia.uniroma3.it
wrote:
Hi,
On 12/12/2011 05:39, James Carman wrote:
Sorry, I was on my phone before when I sent that. Let me elaborate a
bit more. I would just allow the weights to be of any type. However,
you can create two different types of scenarios where you either use a
Comparable derivative or you use whatever you want, but you have to
supply a custom Comparator.
ok it definitely makes sense, thanks :)
The thing is: in case the weight is actually a number I would really
like
to keep it simple on the user side, i.e. it should be usable with
something
like {{WeightedDouble}}, or {{WeightedInteger}}, etc. On the other
hand, some of the implemented algorithms would need to expose one method
per number type: e.g. Dijkstra (which also sums weights, so it needs
numbers) would need a method for Doubles, one for Integers, etc.
Alternatively one could use the abstract class {{Number}} once for all
--
but that would not make things easier, because there is no way to do
maths
directly with it (see e.g. http://stackoverflow.com/**
questions/2721390/how-to-add-**two-java-lang-numbershttp://stackoverflow.com/questions/2721390/how-to-add-two-java-lang-numbers
).
Summing up:
* {{public interface WeightedW}} with method {{public W getWeight()}}
* weighted things ({{Edge}}, {{Vertex}}, {{Graph}}, etc) need to
implement it, e.g. {{public interface WeightedEdgeE,W extends
EdgeE, WeightedW}}
* each algorithm specifies the type of weight needed. E.g. Prim would
only require edges to have {{Comparable}} weights or a
{{Comparator}}, while Dijkstra needs edges with weights as real
numbers (maybe just {{Double}} for now), etc.
How does that sound?
Ciao,
Claudio
On Sun, Dec 11, 2011 at 8:01 PM, James Carman
ja...@carmanconsulting.com wrote:
I wouldn't restrict the weight to Comparable. What if the user wanted
to
provide their own Comparator?
On Dec 11, 2011 7:07 PM, Claudio
Squarcellasquarcel@dia.**uniroma3.itsquar...@dia.uniroma3.it
wrote:
Hi all,
I explored a bit more the (rather philosophical) dilemma that came
from
a
thread from last week, quoted below
One step further. A weight is not necessarily a double: in some
cases
not
even a number, but rather a comparable of some sort. So I would
suggest to
make use of generics in some way, possibly the smartest. Suggestions
are
welcome :-)
The question is: *what do we mean by weight when dealing with
graphs?*
Real number is a standard answer in graph theory: see, e.g.,
http://www.math.jussieu.fr/~**jabondy/books/gtwa/pdf/**chapter1.pdfhttp://www.math.jussieu.fr/~jabondy/books/gtwa/pdf/chapter1.pdf(pag.
15).
What we have now in the code is a {{getWeight()}} method that returns
a
double. That serves well for all the algorithms currently
implemented,
and
probably for many more to come. However it is also true that:
* some domains of interest and/or algorithms might be more
restrictive
on the type and sign of real number for the weights: integers,
non-negative rationals, etc.
* strictly speaking, the basic operations associated with weights
are
usually just a few. Comparison and sum are enough at least for the
algorithms implemented so far in the project (please correct me if
I
am wrong). Maybe
Re: [ognl] Old issues....
Hello, cool, thanks for the update. If you run out of time for some reason or see any other problems with the import, pls let me/us know. I gladly dedicate the cmd-c/cmd-v operations of the next days to ognl. Cheers Christian 2011/12/14 Łukasz Lenart lukasz.len...@googlemail.com: Hello, I have the dump on my local disk and was planning (again) to re-import it incoming days, just give some time as right now I'm busy with Struts 2 release ;-) Regards -- Łukasz + 48 606 323 122 http://www.lenart.org.pl/ Warszawa JUG conference - Confitura http://confitura.pl/ - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- http://www.grobmeier.de https://www.timeandbill.de - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[POOL2] mutability requirements for Generic[Keyed]ObjectPool in DBCP/JNDI
This is a parallel thread to the one about PoolFactory implementations. I'm trying to establish the mutability needs of the [Keyed]ObjectPool implementations, i.e. Generic[Keyed]ObjectPool I've looked at DBCP 1.4, which uses POOL 1.x. SharedPoolDataSource.registerPool() creates an instance of GenericKeyedObjectPool which it configures via the setters; however the instance is then stored in a KeyedObjectPool, and setters/getters are not used elsewwhere. SImilarly, DriverAdapterCPDS.getPooledConnection creates an instance of GenericKeyedObjectPool which is then only used via the KeyedObjectPool interface. So: as far as I can tell from DBCP, there is no need to provide mutable ObjectPool implementations; so long as the pool can be configured intially, that is sufficient. Are there any other existing use cases that I am missing here? - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [POOL2] thread-safety issues
On 13 December 2011 20:25, Mark Thomas ma...@apache.org wrote: On 13/12/2011 19:12, sebb wrote: I've added some Javadoc to classes to indicate which ones are supposed to be thread-safe and which are not. AFAICT, there remain 2 classes to be dealt with, ie GenericKeyedObjectPool (GKOP) and GenericObjectPool (GOP) GKOP is not currently thread-safe, as there are several mutable variables that aren't always accessed using synch. Adding volatile to these would fix the safe publication issue, but might not fix all thread-safety issues. This depends on how exactly the code uses the variables. If the code relies on the variable not changing between references, then the code is not thread-safe. GOP is not thread-safe either, as the field evictionIterator is not volatile. Adding volatile would ensure safe publication, but the field is accessed multiple times - and may be reset to null. As far as I can tell, the evict() method is not thread-safe because of the way it changes the field. I suspect the code will need to use some synchronisation. Of course the same applies to GKOP. Making all the configuration items final and removing the setters - as discussed previously - will make it much easier to make the classes thread-safe. I think that's the next stage. -1. That makes use with DBCP and JNDI much, much harder. I've looked at the DBCP 1.4 code, and cannot see anywhere that requires the pools to be re-configured after creation. Yes the code will have to be changed to set up the Config class before creating the pool, but that is true anyway. [Pool2 eliminates multiple ctors with multiple params in favour of the settable Config class] Please see other two threads regarding Pool and Factory mutability where I hope the discussion can continue. Lets fix the thread safety issues, being careful to avoid adding syncs unless we absolutely have to. Mark - 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
Re: [Graph] On graph weight type(s)
Hi, On 14/12/2011 12:34, James Carman wrote: I don't like the idea of pushing the adding, comparing, etc. into the weights. I like the idea of having operations external to the weights that take care of that stuff. I would be happy with non-polluted weights, so I am with you. But I am not quite sure how to translate that into a good implementation. Do you have an idea to share? Thanks, Claudio -- Claudio Squarcella PhD student at Roma Tre University E-mail address: squar...@dia.uniroma3.it Phone: +39-06-57333215 Fax: +39-06-57333612 http://www.dia.uniroma3.it/~squarcel - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[dbcp] Support for Java7/JDBC 4.1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Are there any plans to update dbcp to support the new features in Java7/JDBC4.1? - -- James Page Ubuntu Core Developer -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJO6MeQAAoJEL/srsug59jDdC0P/RvEu5B33mH3BxN+9ninOHZN 9Z2//q3N/t4EHUUzfF6ObtJWPUKQITfzksyyGeDAoIWfs3CEtrtG1keK0eWQQ0PD Zrx/9/ZHkqdI88P7cK6cessNGcqaiaCy/cTuL/JmqlNH9tihtoB5yy/aILMknjiN 9UoMtQoxjegOg9d2BqeTeaaOQ4Fi8QKrowq3/7j7lbwX+BU43QDYNUIYcsiRIY3S j8qAItMktVLw8gardZ8Smu1q69LIBUMMs2jqUI9wTWnvctVqIKinL1dGZ3kYvZxV uCmbkLnRRr/g2DfY3U3TtRjl4T9lN+MjOEFhCKuBZktbqwPmqe14phAF/RfgqDN7 38VjhKJ7FDofAWdJX6xjzeKPO1l3OiqQalu1ZZp4eXd349AKjj39pARIrqrX4yuI RrBZDASGoA1B0ht8k+ErXYCx4YB5o2mumfbxV4VtFsaobP3QcbgFzA76i5JRiGpV c0ackpER36P4+W0MKFCNTs37xZgmmr8HvZ/BRG4exjshP93nqq5rFhZ1vBpEZ53f wZLvfaYR4tL2A7iaJSqUzsrhE3jUJ3JTP2lxo0XN01BUhGD1OlFRieCBa6m3VTty 9cQAgneOoPwn+NV7veDfR2NOGpST1qCX8gnQ95KynsQg9SrFRQDCk2rkm5XUxfw/ KbIz1sCS7PX8cRHO2dF5 =VcZ+ -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [POOL2] [Keyed]ObjectPoolFactory mutability and DBCP/JNDI
On 14/12/2011 09:23, sebb wrote: I'm trying to establish the mutability needs of the [Keyed]ObjectPoolFactory implementations, i.e. Generic[Keyed]ObjectPoolFactory I've looked at DBCP 1.4, which uses POOL 1.x. You need to look at DBCP trunk that uses POOL 2. There has been quite a lot of refactoring. DBCP 1.4 currently creates an instance of GenericKeyedObjectPoolFactory, which it then uses via the interface KeyedObjectPoolFactory. [This is in the class BasicDataSource.] The additional GKOPF getters, and the protected mutable variables are not actually used by DBCP; it only needs to create the instance of KeyedObjectPoolFactory. There is no indication that DBCP needs to change or even inspect the factory settings once it is created. The factory setters were added in POOL2; if they were not needed for DBCP in POOL 1.X, so are they really needed in POOL 2.x? I already removed them as part of making the classes thread-safe; the question is, are the setters now needed in POOL 2? If so, they can be restored, but synch./volatile will need to be added, as I assume the factories must be thread-safe. Indeed, are the getters even needed? The Pool 1.x code did provide getters, but AFAICT they were not used by DBCP. The calling code knows what it used to create the factory, and the factory is subsequently used as an instance of the interface - which only provides the createPool() method. Is there really a need for other code to find out what the original factory settings were? Can the getters be removed? Do the setters have to be restored? The factory is little more than a wrapper for the G[K]OPConfig and [K]PoolableObjectFactory. I think there are three options. 1. Drop getters and setters and keep it as a simple, immutable wrapper. 2. Provide getters and setters and make it thread-safe for folks who want multiple pools with almost identical configuration. 3. Drop the Factory entirely. Observations: DBCP2 doesn't need these factories. The factories aren't adding very much value. Conclusions: On reflection, I am leaning towards dropping these factories entirely. Mark - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [POOL2] [Keyed]ObjectPoolFactory mutability and DBCP/JNDI
On 14 December 2011 17:01, Mark Thomas ma...@apache.org wrote: On 14/12/2011 09:23, sebb wrote: I'm trying to establish the mutability needs of the [Keyed]ObjectPoolFactory implementations, i.e. Generic[Keyed]ObjectPoolFactory I've looked at DBCP 1.4, which uses POOL 1.x. You need to look at DBCP trunk that uses POOL 2. There has been quite a lot of refactoring. Yes, but 1.4 shows how factories have been historically used. AFAIK, DBCP2 has yet to be used in the field. DBCP 1.4 currently creates an instance of GenericKeyedObjectPoolFactory, which it then uses via the interface KeyedObjectPoolFactory. [This is in the class BasicDataSource.] The additional GKOPF getters, and the protected mutable variables are not actually used by DBCP; it only needs to create the instance of KeyedObjectPoolFactory. There is no indication that DBCP needs to change or even inspect the factory settings once it is created. The factory setters were added in POOL2; if they were not needed for DBCP in POOL 1.X, so are they really needed in POOL 2.x? I already removed them as part of making the classes thread-safe; the question is, are the setters now needed in POOL 2? If so, they can be restored, but synch./volatile will need to be added, as I assume the factories must be thread-safe. Indeed, are the getters even needed? The Pool 1.x code did provide getters, but AFAICT they were not used by DBCP. The calling code knows what it used to create the factory, and the factory is subsequently used as an instance of the interface - which only provides the createPool() method. Is there really a need for other code to find out what the original factory settings were? Can the getters be removed? Do the setters have to be restored? The factory is little more than a wrapper for the G[K]OPConfig and [K]PoolableObjectFactory. I think there are three options. 1. Drop getters and setters and keep it as a simple, immutable wrapper. 2. Provide getters and setters and make it thread-safe for folks who want multiple pools with almost identical configuration. 3. Drop the Factory entirely. Observations: DBCP2 doesn't need these factories. The factories aren't adding very much value. Indeed. Conclusions: On reflection, I am leaning towards dropping these factories entirely. I did wonder about that as well; in which case the interfaces can presumably be dropped too. My preference order is: 3 or 1, else 2. Mark - 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
Re: [VOTE] Release pool 1.5.7 based on RC3
On 12/13/11 3:34 PM, Jörg Schaible wrote: Phil Steitz wrote: This is a patch release, including a couple of bug fixes. The release artifacts are here: http://people.apache.org/~psteitz/pool-1.5.7-rc3/ Release notes: http://people.apache.org/~psteitz/pool-1.5.7-rc3/RELEASE-NOTES.txt Maven distribution: http://people.apache.org/~psteitz/pool-1.5.7-rc3/maven Site: http://people.apache.org/~psteitz/pool-1.5.7-rc3/docs (Links, including an added link to the released API docs, will be updated post release) Tag: http://svn.apache.org/repos/asf/commons/proper/pool/tags/POOL_1_5_7_RC3 Votes, please. This vote will close in 72 hours, 14-DEC-01:00 GMT. [ ] +1 I support this release [ ] +0 OK, but... [ ] -0 Not happy about this because... [ ] -1 I oppose this release +1 Builds fine from source for my compiler zoo containing versions from 1.4.2 to 7 on Linux/64. However, I really wished that every run would not take minutes to complete... Agreed. We should see if we can find faster ways to manifest the various concurrency bugs that led to the long-running tests. Thanks for testing! Phil - Jörg - 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
{RESULT} [VOTE] Release pool 1.5.7 based on RC3
This vote has passed, with +1 votes from psteitz luc grobmeier joerg +0 votes from sebb ggregory and not other votes. Thanks to all who reviewed the RC. I am traveling with limited access the next couple of days, so I will wait to move publish the release until this weekend. Phil On 12/10/11 5:29 PM, Phil Steitz wrote: This is a patch release, including a couple of bug fixes. The release artifacts are here: http://people.apache.org/~psteitz/pool-1.5.7-rc3/ Release notes: http://people.apache.org/~psteitz/pool-1.5.7-rc3/RELEASE-NOTES.txt Maven distribution: http://people.apache.org/~psteitz/pool-1.5.7-rc3/maven Site: http://people.apache.org/~psteitz/pool-1.5.7-rc3/docs (Links, including an added link to the released API docs, will be updated post release) Tag: http://svn.apache.org/repos/asf/commons/proper/pool/tags/POOL_1_5_7_RC3 Votes, please. This vote will close in 72 hours, 14-DEC-01:00 GMT. [ ] +1 I support this release [ ] +0 OK, but... [ ] -0 Not happy about this because... [ ] -1 I oppose this release Thanks! Phil - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [POOL2] mutability requirements for Generic[Keyed]ObjectPool in DBCP/JNDI
On 12/14/11 5:10 AM, sebb wrote: This is a parallel thread to the one about PoolFactory implementations. I'm trying to establish the mutability needs of the [Keyed]ObjectPool implementations, i.e. Generic[Keyed]ObjectPool I've looked at DBCP 1.4, which uses POOL 1.x. SharedPoolDataSource.registerPool() creates an instance of GenericKeyedObjectPool which it configures via the setters; however the instance is then stored in a KeyedObjectPool, and setters/getters are not used elsewwhere. SImilarly, DriverAdapterCPDS.getPooledConnection creates an instance of GenericKeyedObjectPool which is then only used via the KeyedObjectPool interface. So: as far as I can tell from DBCP, there is no need to provide mutable ObjectPool implementations; so long as the pool can be configured intially, that is sufficient. Are there any other existing use cases that I am missing here? My email access is going to be choppy next couple of days, so I may not respond quickly, but have a look in the not too distant archives for discussion around setFactory. Look at the code that associates a connection pool with a datasource and recent discussion of that code. Phil - 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
Re: [POOL2] [Keyed]ObjectPoolFactory mutability and DBCP/JNDI
On 14/12/2011 17:27, sebb wrote: On 14 December 2011 17:01, Mark Thomas ma...@apache.org wrote: On 14/12/2011 09:23, sebb wrote: I'm trying to establish the mutability needs of the [Keyed]ObjectPoolFactory implementations, i.e. Generic[Keyed]ObjectPoolFactory I've looked at DBCP 1.4, which uses POOL 1.x. You need to look at DBCP trunk that uses POOL 2. There has been quite a lot of refactoring. Yes, but 1.4 shows how factories have been historically used. AFAIK, DBCP2 has yet to be used in the field. DBCP 1.4 currently creates an instance of GenericKeyedObjectPoolFactory, which it then uses via the interface KeyedObjectPoolFactory. [This is in the class BasicDataSource.] The additional GKOPF getters, and the protected mutable variables are not actually used by DBCP; it only needs to create the instance of KeyedObjectPoolFactory. There is no indication that DBCP needs to change or even inspect the factory settings once it is created. The factory setters were added in POOL2; if they were not needed for DBCP in POOL 1.X, so are they really needed in POOL 2.x? I already removed them as part of making the classes thread-safe; the question is, are the setters now needed in POOL 2? If so, they can be restored, but synch./volatile will need to be added, as I assume the factories must be thread-safe. Indeed, are the getters even needed? The Pool 1.x code did provide getters, but AFAICT they were not used by DBCP. The calling code knows what it used to create the factory, and the factory is subsequently used as an instance of the interface - which only provides the createPool() method. Is there really a need for other code to find out what the original factory settings were? Can the getters be removed? Do the setters have to be restored? The factory is little more than a wrapper for the G[K]OPConfig and [K]PoolableObjectFactory. I think there are three options. 1. Drop getters and setters and keep it as a simple, immutable wrapper. 2. Provide getters and setters and make it thread-safe for folks who want multiple pools with almost identical configuration. 3. Drop the Factory entirely. Observations: DBCP2 doesn't need these factories. The factories aren't adding very much value. Indeed. Conclusions: On reflection, I am leaning towards dropping these factories entirely. I did wonder about that as well; in which case the interfaces can presumably be dropped too. My preference order is: 3 or 1, else 2. Assuming there are no objections I'll commit the removal of the factories and the interfaces some time tomorrow. Mark - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [POOL2] mutability requirements for Generic[Keyed]ObjectPool in DBCP/JNDI
On 14/12/2011 12:10, sebb wrote: This is a parallel thread to the one about PoolFactory implementations. I'm trying to establish the mutability needs of the [Keyed]ObjectPool implementations, i.e. Generic[Keyed]ObjectPool I've looked at DBCP 1.4, which uses POOL 1.x. SharedPoolDataSource.registerPool() creates an instance of GenericKeyedObjectPool which it configures via the setters; however the instance is then stored in a KeyedObjectPool, and setters/getters are not used elsewwhere. SImilarly, DriverAdapterCPDS.getPooledConnection creates an instance of GenericKeyedObjectPool which is then only used via the KeyedObjectPool interface. So: as far as I can tell from DBCP, there is no need to provide mutable ObjectPool implementations; so long as the pool can be configured intially, that is sufficient. Are there any other existing use cases that I am missing here? I do see periodic requests to be able to change the (DBCP) pool properties dynamically and it was my intention to support this use case via JMX for POOL2. JNDI assumes resources are essentially beans i.e. have zero argument constructors and getters/setters. If this is not the case then some extra plumbing is required. The further G[K]OP gets from a JavaBean the more plumbing required. Currently the only extra plumbing required is to work-around the zero-argument constructor. Removing the setters would mean more plumbing would be required for someone to create a custom JNDI resource for a pool of objects of type X. DBCP already has the plumbing to handle the removal of the setters but it would require some code changes. It was always my intention to provide the ability to change the pool properties on the fly. I would rather spend a little time fixing the remaining threading issues than drop that requirement. I certainly don't want to try coding DBCP to support dynamic changes when the underlying pool does not. Given that there is a requirement from DBCP users for dynamic changes to the pool, I believe POOL2 needs to support mutable pool implementations. Mark - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [POOL2] mutability requirements for Generic[Keyed]ObjectPool in DBCP/JNDI
On 14 December 2011 18:29, Mark Thomas ma...@apache.org wrote: On 14/12/2011 12:10, sebb wrote: This is a parallel thread to the one about PoolFactory implementations. I'm trying to establish the mutability needs of the [Keyed]ObjectPool implementations, i.e. Generic[Keyed]ObjectPool I've looked at DBCP 1.4, which uses POOL 1.x. SharedPoolDataSource.registerPool() creates an instance of GenericKeyedObjectPool which it configures via the setters; however the instance is then stored in a KeyedObjectPool, and setters/getters are not used elsewwhere. SImilarly, DriverAdapterCPDS.getPooledConnection creates an instance of GenericKeyedObjectPool which is then only used via the KeyedObjectPool interface. So: as far as I can tell from DBCP, there is no need to provide mutable ObjectPool implementations; so long as the pool can be configured intially, that is sufficient. Are there any other existing use cases that I am missing here? I do see periodic requests to be able to change the (DBCP) pool properties dynamically and it was my intention to support this use case via JMX for POOL2. Ah - that is a new requirement. JNDI assumes resources are essentially beans i.e. have zero argument constructors and getters/setters. If this is not the case then some extra plumbing is required. The further G[K]OP gets from a JavaBean the more plumbing required. Currently the only extra plumbing required is to work-around the zero-argument constructor. Removing the setters would mean more plumbing would be required for someone to create a custom JNDI resource for a pool of objects of type X. But AFAIK JNDI does not allow dynamic changes, so can operate on the config classes - which do have the required characteristics, AFAICT. DBCP already has the plumbing to handle the removal of the setters but it would require some code changes. I committed a fix earlier today which changed the one remaining class that used setters on the pool so it now uses setters on the config class. The other pool creation classes already did that. AFAICT, DBCP2 does not need to use setters on the pool at present. It was always my intention to provide the ability to change the pool properties on the fly. I would rather spend a little time fixing the remaining threading issues than drop that requirement. I certainly don't want to try coding DBCP to support dynamic changes when the underlying pool does not. That is a new requirement on DBCP (of which I was previously unaware) - and does of course change things. Given that there is a requirement from DBCP users for dynamic changes to the pool, I believe POOL2 needs to support mutable pool implementations. The more mutable fields there are, the more work to be done to ensure thread-safety, and the more checking/unit tests needed when updating the code. So - are there any settings that it does not make sense to mutate after creation? For example, LIFO? jmxEnabled/jmxNamePrefix? testOnBorrow/testOnReturn/testWhileIdle? blockWhenExhausted? And are there settings which need to be constrained relative to other settings? For example some of the counts probably have inter-dependent ranges. If so, then where is the validation going to be done? Would it make sense to only allow changes via the config class? This would simplify the classes by eliminating all the setters, and should make consistency checking easier. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[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=15866projectId=98 Build statistics: State: Failed Previous State: Ok Started at: Wed 14 Dec 2011 20:51:48 + Finished at: Wed 14 Dec 2011 20:52:07 + Total time: 18s Build Trigger: Schedule Build Number: 124 Exit code: 1 Building machine hostname: vmbuild Operating system : Linux(unknown) Java Home version : java version 1.6.0_26 Java(TM) SE Runtime Environment (build 1.6.0_26-b03) Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02, mixed mode) Builder version : Apache Maven 2.2.1 (r801777; 2009-08-06 19:16:01+) Java version: 1.6.0_26 Java home: /usr/lib/jvm/java-6-sun-1.6.0.26/jre Default locale: en_US, platform encoding: UTF-8 OS name: linux version: 2.6.32-31-server arch: amd64 Family: unix SCM Changes: Changed: no author @ no date Comment: no comment Files changed: src/test/org/apache/commons/pool2/impl/TestGenericKeyedObjectPool.java ( no revision ) src/test/org/apache/commons/pool2/impl/TestGenericObjectPool.java ( no revision ) src/java/org/apache/commons/pool2/impl/GenericKeyedObjectPool.java ( no revision ) src/java/org/apache/commons/pool2/impl/GenericObjectPoolConfig.java ( no revision ) src/java/org/apache/commons/pool2/impl/GenericKeyedObjectPoolConfig.java ( no revision ) src/java/org/apache/commons/pool2/impl/GenericObjectPool.java ( no revision ) Dependencies Changes: No dependencies changed Build Definition: POM filename: pom.xml Goals: clean deploy 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: 0 Failures: 0 Errors: 0 Total time: 0.0 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [POOL2] mutability requirements for Generic[Keyed]ObjectPool in DBCP/JNDI
On Dec 14, 2011, at 14:12, sebb seb...@gmail.com wrote: On 14 December 2011 18:29, Mark Thomas ma...@apache.org wrote: On 14/12/2011 12:10, sebb wrote: This is a parallel thread to the one about PoolFactory implementations. I'm trying to establish the mutability needs of the [Keyed]ObjectPool implementations, i.e. Generic[Keyed]ObjectPool I've looked at DBCP 1.4, which uses POOL 1.x. SharedPoolDataSource.registerPool() creates an instance of GenericKeyedObjectPool which it configures via the setters; however the instance is then stored in a KeyedObjectPool, and setters/getters are not used elsewwhere. SImilarly, DriverAdapterCPDS.getPooledConnection creates an instance of GenericKeyedObjectPool which is then only used via the KeyedObjectPool interface. So: as far as I can tell from DBCP, there is no need to provide mutable ObjectPool implementations; so long as the pool can be configured intially, that is sufficient. Are there any other existing use cases that I am missing here? I do see periodic requests to be able to change the (DBCP) pool properties dynamically and it was my intention to support this use case via JMX for POOL2. Ah - that is a new requirement. JNDI assumes resources are essentially beans i.e. have zero argument constructors and getters/setters. If this is not the case then some extra plumbing is required. The further G[K]OP gets from a JavaBean the more plumbing required. Currently the only extra plumbing required is to work-around the zero-argument constructor. Removing the setters would mean more plumbing would be required for someone to create a custom JNDI resource for a pool of objects of type X. But AFAIK JNDI does not allow dynamic changes, so can operate on the config classes - which do have the required characteristics, AFAICT. DBCP already has the plumbing to handle the removal of the setters but it would require some code changes. I committed a fix earlier today which changed the one remaining class that used setters on the pool so it now uses setters on the config class. The other pool creation classes already did that. AFAICT, DBCP2 does not need to use setters on the pool at present. It was always my intention to provide the ability to change the pool properties on the fly. I would rather spend a little time fixing the remaining threading issues than drop that requirement. I certainly don't want to try coding DBCP to support dynamic changes when the underlying pool does not. That is a new requirement on DBCP (of which I was previously unaware) - and does of course change things. Given that there is a requirement from DBCP users for dynamic changes to the pool, I believe POOL2 needs to support mutable pool implementations. The more mutable fields there are, the more work to be done to ensure thread-safety, and the more checking/unit tests needed when updating the code. So - are there any settings that it does not make sense to mutate after creation? For example, LIFO? jmxEnabled/jmxNamePrefix? testOnBorrow/testOnReturn/testWhileIdle? blockWhenExhausted? And are there settings which need to be constrained relative to other settings? For example some of the counts probably have inter-dependent ranges. If so, then where is the validation going to be done? Would it make sense to only allow changes via the config class? I should then be able to get a config object from a pool, tweak it, and pass it back. Gary This would simplify the classes by eliminating all the setters, and should make consistency checking easier. - 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
Re: [POOL2] mutability requirements for Generic[Keyed]ObjectPool in DBCP/JNDI
sebb seb...@gmail.com wrote: This is a parallel thread to the one about PoolFactory implementations. I'm trying to establish the mutability needs of the [Keyed]ObjectPool implementations, i.e. Generic[Keyed]ObjectPool I've looked at DBCP 1.4, which uses POOL 1.x. SharedPoolDataSource.registerPool() creates an instance of GenericKeyedObjectPool which it configures via the setters; however the instance is then stored in a KeyedObjectPool, and setters/getters are not used elsewwhere. SImilarly, DriverAdapterCPDS.getPooledConnection creates an instance of GenericKeyedObjectPool which is then only used via the KeyedObjectPool interface. So: as far as I can tell from DBCP, there is no need to provide mutable ObjectPool implementations; so long as the pool can be configured intially, that is sufficient. Are there any other existing use cases that I am missing here? - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org Yes, There is a requirement to modify the pool configuration via jmx while the pool is in use. Mark - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release pool 1.5.7 based on RC3
Phil Steitz phil.ste...@gmail.com wrote: Here is my +1 Could use a couple of more so the bug fixes can go out and we can proceed to a patch release for [dbcp] 1.3/1.4. Phil On 12/10/11 5:29 PM, Phil Steitz wrote: This is a patch release, including a couple of bug fixes. The release artifacts are here: http://people.apache.org/~psteitz/pool-1.5.7-rc3/ Release notes: http://people.apache.org/~psteitz/pool-1.5.7-rc3/RELEASE-NOTES.txt Maven distribution: http://people.apache.org/~psteitz/pool-1.5.7-rc3/maven Site: http://people.apache.org/~psteitz/pool-1.5.7-rc3/docs (Links, including an added link to the released API docs, will be updated post release) Tag: http://svn.apache.org/repos/asf/commons/proper/pool/tags/POOL_1_5_7_RC3 Votes, please. This vote will close in 72 hours, 14-DEC-01:00 GMT. [ ] +1 I support this release [ ] +0 OK, but... [ ] -0 Not happy about this because... [ ] -1 I oppose this release Thanks! Phil - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org +1 Mark - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [POOL2] mutability requirements for Generic[Keyed]ObjectPool in DBCP/JNDI
On 14/12/2011 19:12, sebb wrote: On 14 December 2011 18:29, Mark Thomas ma...@apache.org wrote: JNDI assumes resources are essentially beans i.e. have zero argument constructors and getters/setters. If this is not the case then some extra plumbing is required. The further G[K]OP gets from a JavaBean the more plumbing required. Currently the only extra plumbing required is to work-around the zero-argument constructor. Removing the setters would mean more plumbing would be required for someone to create a custom JNDI resource for a pool of objects of type X. But AFAIK JNDI does not allow dynamic changes, so can operate on the config classes - which do have the required characteristics, AFAICT. Which is what I mean by more plumbing. Given that DBCP users want to change pool config on the fly, I imagine users of other pools will to. Given that there is a requirement from DBCP users for dynamic changes to the pool, I believe POOL2 needs to support mutable pool implementations. The more mutable fields there are, the more work to be done to ensure thread-safety, and the more checking/unit tests needed when updating the code. So - are there any settings that it does not make sense to mutate after creation? For example, LIFO? May as well be mutable. jmxEnabled/jmxNamePrefix? That can / should be fixed. testOnBorrow/testOnReturn/testWhileIdle? Mutable. blockWhenExhausted? Mutable. And are there settings which need to be constrained relative to other settings? No. We don't do this currently and I don't see a need to start. There are some combinations that don't make much sense but we don't enforce anything. Would it make sense to only allow changes via the config class? No. The config class can be a short-cut but I don't think it is the only way. Note that changes via a config class won't be atomic unless we make some changes. This would simplify the classes by eliminating all the setters, and should make consistency checking easier. I don't think we need consistency checking. My current thinking is: - make all mutable attributes volatile - methods take local copies of the attributes they require at the start of the method to ensure consistency Mark - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [POOL2] mutability requirements for Generic[Keyed]ObjectPool in DBCP/JNDI
On 14 December 2011 22:22, Mark Thomas ma...@apache.org wrote: On 14/12/2011 19:12, sebb wrote: On 14 December 2011 18:29, Mark Thomas ma...@apache.org wrote: JNDI assumes resources are essentially beans i.e. have zero argument constructors and getters/setters. If this is not the case then some extra plumbing is required. The further G[K]OP gets from a JavaBean the more plumbing required. Currently the only extra plumbing required is to work-around the zero-argument constructor. Removing the setters would mean more plumbing would be required for someone to create a custom JNDI resource for a pool of objects of type X. But AFAIK JNDI does not allow dynamic changes, so can operate on the config classes - which do have the required characteristics, AFAICT. Which is what I mean by more plumbing. Given that DBCP users want to change pool config on the fly, I imagine users of other pools will to. I was just observing that the mutability requirements don't come from JNDI. Whether JNDI updates the config class or a mutable pool makes little or no difference to the code required. Given that there is a requirement from DBCP users for dynamic changes to the pool, I believe POOL2 needs to support mutable pool implementations. The more mutable fields there are, the more work to be done to ensure thread-safety, and the more checking/unit tests needed when updating the code. So - are there any settings that it does not make sense to mutate after creation? For example, LIFO? May as well be mutable. Might create some interesting logic issues if it changes whilst a one thread is using the pool and then another thread uses the new value. jmxEnabled/jmxNamePrefix? That can / should be fixed. Does that mean set at instantiation only, or don't allow any changes once the pool starts to be used? Similarly for any other non-mutable items - the values must be established before they are first used. Could do this by disabling the setter if the pool is active. Or check for actual first use in the getter, but much easier to control if the field is final (i.e. set at construction). testOnBorrow/testOnReturn/testWhileIdle? Mutable. blockWhenExhausted? Mutable. And are there settings which need to be constrained relative to other settings? No. We don't do this currently and I don't see a need to start. There are some combinations that don't make much sense but we don't enforce anything. OK, makes it simpler. Would it make sense to only allow changes via the config class? No. The config class can be a short-cut but I don't think it is the only way. Note that changes via a config class won't be atomic unless we make some changes. This would simplify the classes by eliminating all the setters, and should make consistency checking easier. I don't think we need consistency checking. My current thinking is: - make all mutable attributes volatile Yes. - methods take local copies of the attributes they require at the start of the method to ensure consistency That will ensure consistency within a method. It's not yet clear if there are any independent methods that rely on consistency between them. Also if non-private method A calls non-private method B and they both need the same field, there's a potential window where the value could change unless special precautions are taken. It would be very easy to accidentally break the rule of only fetching each item once within a method invocation. Mark - 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
Re: [dbutils] sign-artifacts hangs during release:prepare
Anyone have any idea on this? Should I be seeing basic auth for my
challenge? Where can I set the password as I was never prompted to
enter it.
At this point, can someone else deploy RC1 while I figure out what is
wrong on my end?
Thanks...
Bill-
On Tue, Dec 13, 2011 at 4:32 PM, William Speirs wspe...@apache.org wrote:
First, thank you all again for the help!
I got past the GPG step, now I'm stuck on password/auth issues now with SVN
:-(
I thought the issue was that my password manager wasn't authed and
that svn was working in a non-interactive mode, so it couldn't get my
password; this was the reason for -r1213934.
Anyway, output below... any/all ideas welcomed!
Bill-
[INFO] Checking in modified POMs...
[INFO] Executing: /bin/sh -c cd
/home/wspeirs/workspace/commons-dbutils svn --non-interactive
commit --file /tmp/maven-scm-481300763.commit --targets
/tmp/maven-scm-3917786176898805146-targets
[INFO] Working directory: /home/wspeirs/workspace/commons-dbutils
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Unable to commit files
Provider message:
The svn command failed.
Command output:
svn: Commit failed (details follow):
svn: MKACTIVITY of
'/repos/asf/!svn/act/3b6f8370-abd6-4d88-adeb-7dc981ecd57f':
authorization failed: Could not authenticate to server: rejected Basic
challenge (https://svn.apache.org)
On Tue, Dec 13, 2011 at 10:28 AM, sebb seb...@gmail.com wrote:
On 13 December 2011 15:19, William Speirs wspe...@apache.org wrote:
I will try adding the additional elements:
gpg.secretKeyring/path/to/secring.gpg/gpg.secretKeyring
!-- must be on the execution path --
gpg.executablegpg2/gpg.executable
Sorry, should have clarified - the above requires gpg2 to be installed
and created.
I installed both gpg1 and gpg2, and created gpg1 and gpg2 as copies of
their respective gpg executables.
e.g. on Windows copy gpg.exe gpgn.exe
Both versions of gpg are on the execution path; running gpg picks the
first one; running gpg1 or gpg2 picks only that version.
This enables quick swapping between them as required.
And also try with gpg2.
I'll try later today and update.
Thanks again for all of the help!
Bill-
On Tue, Dec 13, 2011 at 9:23 AM, Gary Gregory garydgreg...@gmail.com
wrote:
FWIW: My set up is such that I always enter my password on the CLI when
Maven asks for it.
Gary
On Tue, Dec 13, 2011 at 9:20 AM, sebb seb...@gmail.com wrote:
On 13 December 2011 13:53, William Speirs wspe...@apache.org wrote:
On Tue, Dec 13, 2011 at 12:16 AM, Gary Gregory garydgreg...@gmail.com
wrote:
Did you do the whole master pass phrase/obfuscated stuff that the top
of the Using Nexus wiki points to?
I did not do this at first, but I have since tried. I setup my
settings-security.xml file as show on the wiki page, and added the
encrypted passwords to my settings.xml file. Still doesn't work.
Below is my entire settings.xml file (with passwords removed). By
adding the mavenExecutorId element, it will not hang but prompt me
for a password if it's not supplied via gpg.passphrase. However,
even when I type my passphrase in, it still rejects it. Again, if I
use gpg -c somefile.txt and type in that same passphrase, everything
works.
I'm testing this by running: mvn -Prc,apache package gpg:sign
Not sure what the rc profile does compared with the release profile.
What version of GPG are you using?
And I keep getting:
[INFO] [gpg:sign {execution: default-cli}]
gpg: skipped B0EC1E65: bad passphrase
gpg: signing failed: bad passphrase
I'm at a loss at this point...
Bill-
* settings.xml *
?xml version=1.0?
settings xmlns=http://maven.apache.org/SETTINGS/1.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/SETTINGS/1.0.0
http://maven.apache.org/xsd/settings-1.0.0.xsd;
servers
server
idapache.releases/id
usernamewspeirs/username
password{my encrypted Apache password here}/password
filePermissions664/filePermissions
directoryPermissions775/directoryPermissions
/server
server
idapache.website/id
usernamewspeirs/username
password{my encrypted Apache password here}/password
filePermissions664/filePermissions
directoryPermissions775/directoryPermissions
/server
server
idapache.snapshots/id
usernamewspeirs/username
password{my encrypted Apache password here}/password
filePermissions664/filePermissions
directoryPermissions775/directoryPermissions
/server
/servers
profiles
profile
idapache/id
activation
activeByDefaultfalse/activeByDefault
/activation
properties
mavenExecutorIdforked-path/mavenExecutorId
[GUMP@vmgump]: Project commons-proxy-test (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-proxy-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 279 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-proxy-test : Apache Commons Full details are available at: http://vmgump.apache.org/gump/public/apache-commons/commons-proxy-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -WARNING- Overriding Maven settings: [/srv/gump/public/workspace/apache-commons/proxy/gump_mvn_settings.xml] -DEBUG- (Apache Gump generated) Apache Maven Settings in: /srv/gump/public/workspace/apache-commons/proxy/gump_mvn_settings.xml -INFO- Failed with reason build failed -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/proxy/pom.xml -INFO- Project Reports in: /srv/gump/public/workspace/apache-commons/proxy/target/surefire-reports The following work was performed: http://vmgump.apache.org/gump/public/apache-commons/commons-proxy-test/gump_work/build_apache-commons_commons-proxy-test.html Work Name: build_apache-commons_commons-proxy-test (Type: Build) Work ended in a state of : Failed Elapsed: 12 secs Command Line: /opt/maven2/bin/mvn --batch-mode --settings /srv/gump/public/workspace/apache-commons/proxy/gump_mvn_settings.xml test [Working Directory: /srv/gump/public/workspace/apache-commons/proxy] M2_HOME: /opt/maven2 - Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec Running org.apache.commons.proxy.factory.util.TestMethodSignature Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec Running org.apache.commons.proxy.provider.TestConstantProvider Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004 sec Running org.apache.commons.proxy.interceptor.TestFilteredInterceptor Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.035 sec Running org.apache.commons.proxy.interceptor.filter.TestPatternFilter Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec Running org.apache.commons.proxy.interceptor.TestSerializingInterceptor Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.016 sec Running org.apache.commons.proxy.interceptor.TestInterceptorChain Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.008 sec Running org.apache.commons.proxy.invoker.TestNullInvoker Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.015 sec Running org.apache.commons.proxy.provider.remoting.TestBurlapProvider Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.01 sec Running org.apache.commons.proxy.exception.TestDelegateProviderException Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec Running org.apache.commons.proxy.invoker.TestChainInvoker Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.011 sec Running org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory Tests run: 37, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.189 sec Running org.apache.commons.proxy.exception.TestProxyFactoryException Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec Running org.apache.commons.proxy.interceptor.filter.TestReturnTypeFilter Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec Running org.apache.commons.proxy.provider.TestBeanProvider Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.014 sec Results : Tests in error: testInvalidHandlerName(org.apache.commons.proxy.invoker.TestXmlRpcInvoker) Tests run: 179, Failures: 0, Errors: 1, Skipped: 0 [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] There are test failures. Please refer to /srv/gump/public/workspace/apache-commons/proxy/target/surefire-reports for the individual test results. [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 11 seconds [INFO] Finished at: Thu Dec 15 05:31:55 UTC 2011 [INFO] Final Memory: 24M/58M [INFO] - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/apache-commons/commons-proxy-test/rss.xml - Atom:
