[jira] Commented: (POOL-86) GenericKeyedObjectPool retaining too many idle objects
[
http://issues.apache.org/jira/browse/POOL-86?page=comments#action_12445490 ]
Sandy McArthur commented on POOL-86:
> Firstly, borrowObject() is returning the LRU object rather than the MRU
> object. That minimizes rather than maximizes object reuse and tends to
> refresh all the idle objects, preventing them from becoming evictable.
I think you have minimize and maximize backwards and reusing idle objects is
why you'd want to use a pool. There are a couple of reasons for GKOP preferring
the LRU idle object:
1. The reason to use a pool is that you have reusable objects that are
expensive to create or dispose of. Using a FIFO ordering (LRU) means you use
all the pooled objects over time instead of just a handful. Idle object will be
kept fresh and ready to reuse or they will fail validateObject and be
discarded. LIFO ordering (MRU) will tend to reuse the same objects and others
will rarely be used under peak load, unless you have an idle object evictor to
check their reusability ...
2. Using an idle object evictor can cause deadlocks. If the
PoolableObjectFactory uses synchronization and the pool is accessed in a
synchronized context it can lead to locks being acquired in the opposite order
which creates a deadlock possible race condition and thread-safty cannot be
guaranteed. Basically, avoid idle object eviction if you can.
3. A FIFO pool is implicitly optimized to be prepared to handle the next load
spike. And that is the point of the pool. Optimizing the pool for low load
levels reduces the important advantage of using a pool, being prepared for lots
of work.
I can think of situations where the above doesn't apply but "Generic" pools are
named "Generic" because they aren't optimized for any specific situation.
> Secondly, evict() itself has a couple of problems, both of which only show up
> when many keys are in play:
> Here's a patch fixing both problems:
If you could work the patch to only address the evict issue and attach it as a
file instead of a copy/paste in it's own issue I'd appreciate it.
> GenericKeyedObjectPool retaining too many idle objects
> --
>
> Key: POOL-86
> URL: http://issues.apache.org/jira/browse/POOL-86
> Project: Commons Pool
> Issue Type: Bug
>Affects Versions: 1.3
>Reporter: Mike Martin
>
> There are two somewhat related problems in GenericKeyedObjectPool that cause
> many more idle objects to be retained than should be, for much longer than
> they
> should be.
> Firstly, borrowObject() is returning the LRU object rather than the MRU
> object.
> That minimizes rather than maximizes object reuse and tends to refresh all the
> idle objects, preventing them from becoming evictable.
> The idle LinkedList is being maintained with:
> borrowObject: list.removeFirst()
> returnObject: list.addLast()
> These should either both be ...First() or both ...Last() so the list maintains
> a newer-to-older, or vice-versa, ordering. The code in evict() works from the
> end of the list which indicates newer-to-older might have been originally
> intended.
> Secondly, evict() itself has a couple of problems, both of which only show up
> when many keys are in play:
> 1. Once it processes a key it doesn't advance to the next key.
> 2. _evictLastIndex is not working as documented ("Position in the _pool where
> the _evictor last stopped"). Instead it's the position where the last
> scan
> started, and becomes the position at which it attempts to start scanning
> *in the next pool*. That just causes objects eligible for eviction to
> sometimes be skipped entirely.
> Here's a patch fixing both problems:
> GenericKeyedObjectPool.java
> 990c990
> < pool.addLast(new ObjectTimestampPair(obj));
> ---
> > pool.addFirst(new ObjectTimestampPair(obj));
> 1094,1102c1094,1095
> < }
> <
> < // if we don't have a keyed object pool iterator
> < if (objIter == null) {
> < final LinkedList list = (LinkedList)_poolMap.get(key);
> < if (_evictLastIndex < 0 || _evictLastIndex >
> list.size()) {
> < _evictLastIndex = list.size();
> < }
> < objIter = list.listIterator(_evictLastIndex);
> ---
> > LinkedList list = (LinkedList)_poolMap.get(key);
> > objIter = list.listIterator(list.size());
> 1154,1155c1147
> < _evictLastIndex = -1;
> < objIter = null;
> ---
> > key = null;
> 1547,1551d1538
> <
> < /**
> < * Position in the _pool where the _evictor last stopped.
> < */
> < private int _evictLastIndex = -1;
> I have a local unit test for this but it depends on some other code I can't
> donate.
[jira] Updated: (LANG-285) Wish : method unaccent
[ http://issues.apache.org/jira/browse/LANG-285?page=all ] Guillaume Coté updated LANG-285: Attachment: MapBuilder.java MapBuilder.java is little program that I use to gererate a map of caracters. This isn't intend to be included in the repository, but it might be of interest for the curious. > Wish : method unaccent > -- > > Key: LANG-285 > URL: http://issues.apache.org/jira/browse/LANG-285 > Project: Commons Lang > Issue Type: New Feature >Reporter: Guillaume Coté >Priority: Minor > Attachments: MapBuilder.java, unaccent.patch, UnnacentMap.java > > > I would like to add a method that replace accented caracter by unaccented > one. For example, with the input String "L'été où j'ai dû aller à l'île > d'Anticosti commenca tôt", the method would return "L'ete ou j'ai du aller à > l'ile d'Anticosti commenca tot". > I suggest to call that method unaccent and to add it in StringUtils. > If we cannot covert all case, the first version could only covert iso-8859-1. > If you are willing to go forward with that idea, I am willing to contribute a > patch. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (LANG-285) Wish : method unaccent
[ http://issues.apache.org/jira/browse/LANG-285?page=all ] Guillaume Coté updated LANG-285: Attachment: unaccent.patch A patch that add a method unaccent in StringUtil and the corresponding test cases. P.S. My svn is outputing in french, even if my computer is in english. There is a little bit of french in the patch. If that a issue, let me know and I'll try to switch my svn in english. > Wish : method unaccent > -- > > Key: LANG-285 > URL: http://issues.apache.org/jira/browse/LANG-285 > Project: Commons Lang > Issue Type: New Feature >Reporter: Guillaume Coté >Priority: Minor > Attachments: unaccent.patch, UnnacentMap.java > > > I would like to add a method that replace accented caracter by unaccented > one. For example, with the input String "L'été où j'ai dû aller à l'île > d'Anticosti commenca tôt", the method would return "L'ete ou j'ai du aller à > l'ile d'Anticosti commenca tot". > I suggest to call that method unaccent and to add it in StringUtils. > If we cannot covert all case, the first version could only covert iso-8859-1. > If you are willing to go forward with that idea, I am willing to contribute a > patch. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] Generics & the collection subpackage
I shall be opening a ticket for the Closure one in the next while (when I get a chance). Note that Procedure and Function don't actually say anything - they're very broad programming principals. Also note that a Factory may not actually create/generate something (it may already be in the warehouse) - it's also a well known convention. Cheers Stephen I would propose Closure -> Processor - Rename functor interfaces and update method signatures in collections to match those in [functor], specifically Closure --> Procedure, Transformer --> Function or Functor, Factory --> Generator - Add TertiaryXxx, QuaternaryXxx, and NaryXxx (using varargs, e.g. E xxx(E... e)) interfaces michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
the best way to get involved?
Hi Everybody! I am new to the commons as a developer, but I have been using the libraries for a while now, and I would like to give something back. My question is this - what areas are most in need of maintenance or improvement? I have gone through the bug database, and it seems as if much of what is there is either already fixed or very outdated. Any suggestions? Requests? Thanks much in advance, Alex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Major versions require package name change
That should be "an appropriate solution *for everybody*" Rory Winston wrote: +1 I agree this is an issue which package maintainers will need to consider when making major releases. I dont believe that mandating package name changes is an appropriate solution. Niall Pemberton wrote: On 10/29/06, Stephen Colebourne <[EMAIL PROTECTED]> wrote: PROPOSAL: The major version number of a component, where it is greater than 1, shall be included in the package name. EXAMPLE: org.apache.commons.pool - version 1.x line org.apache.commons.pool2 - version 2.x line RATIONALE: Java has no mechanism for handling different versions of the same library where those versions clash. This leads to a situation known as 'jar hell'. Consider application A dependent on frameworks M and N, both of which depend on a commons component X. A | - | | M N | | - | X Now consider what happens if framework M upgrades to a later version of X, but N does not. The standard approach is to drop in X2 and hope that N still runs. A | - | | M N | | - | X2 However N may not run with X2 if the changes from X to X2 are major and incompatible (which should be signalled via a major version change). Given this situation, the application now has no simple options. They can: a) give up and not upgrade framework M b) petition framework N to upgrade c) dive into the open source and upgrade N themselves d) use two classloaders e) use fancy bytecode weaving tricks to merge the versions f) use jar embedding tools to alter N I would argue that the majority of developers would choose option (a) and give up. This is because while options b-f are possible, they are not what the average *user* wants to spend their time doing. Of course, all of this presents a very simple example. Most open source stacks are much deeper than this and thus the potential for jar hell is much higher. The proposed solution is to rename the package of each commons component at each major version change. This binds all the callers of the commons component to a different package namespace, and thus no clashes, or jar hell will ensue - except by human error. Why now? Because this is the time that the majority of components are starting to consider new incompatible versions, often related to JDK1.5. DOWNSIDES: - The client application has to change their package names when upgrading to a later major version of the commons component. - The client may get two versions of the same class in their IDE autocomplete (most IDEs allow this to be filtered). This proposal is about making upgrades *predicatable* at the expense of a small amount of pain. I know that most of us don't really like it, but I contend that there is no alternative other than to inflict pain on users of commons over the next few years, and perhaps risk commons becoming irrelevant by being unusable. I also strongly believe we need a cross-commons approach on this. Its perfectly possible for a component to have a major upgrade without breaking backwards compatibility and I don't think we should mandate this. Even when there is a break in backwards compatbility, then using a deprecate / remove cycle should also be open as an option. There may be a number of factors which influence the approach to take - how widely used/depended on the component is, how major or minor the in-compatibility is and how long / many versions the feature has been deprecated before being removed/changed. This should be decided by the component developers on a component by component basis and not mandated as a policy. There are clearly good reasons / circumstances to take the approach you suggest, but it is a user unfriendly approach. As a user I like to try out new versions by dropping in a new jar - before taking the decision to upgrade. This approach rules that out and it wouldn't surprise me if users started to see commons as irrelevant because of "upgrade hell" if we take this route too often. Niall Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Major versions require package name change
+1 I agree this is an issue which package maintainers will need to consider when making major releases. I dont believe that mandating package name changes is an appropriate solution. Niall Pemberton wrote: On 10/29/06, Stephen Colebourne <[EMAIL PROTECTED]> wrote: PROPOSAL: The major version number of a component, where it is greater than 1, shall be included in the package name. EXAMPLE: org.apache.commons.pool - version 1.x line org.apache.commons.pool2 - version 2.x line RATIONALE: Java has no mechanism for handling different versions of the same library where those versions clash. This leads to a situation known as 'jar hell'. Consider application A dependent on frameworks M and N, both of which depend on a commons component X. A | - | | M N | | - | X Now consider what happens if framework M upgrades to a later version of X, but N does not. The standard approach is to drop in X2 and hope that N still runs. A | - | | M N | | - | X2 However N may not run with X2 if the changes from X to X2 are major and incompatible (which should be signalled via a major version change). Given this situation, the application now has no simple options. They can: a) give up and not upgrade framework M b) petition framework N to upgrade c) dive into the open source and upgrade N themselves d) use two classloaders e) use fancy bytecode weaving tricks to merge the versions f) use jar embedding tools to alter N I would argue that the majority of developers would choose option (a) and give up. This is because while options b-f are possible, they are not what the average *user* wants to spend their time doing. Of course, all of this presents a very simple example. Most open source stacks are much deeper than this and thus the potential for jar hell is much higher. The proposed solution is to rename the package of each commons component at each major version change. This binds all the callers of the commons component to a different package namespace, and thus no clashes, or jar hell will ensue - except by human error. Why now? Because this is the time that the majority of components are starting to consider new incompatible versions, often related to JDK1.5. DOWNSIDES: - The client application has to change their package names when upgrading to a later major version of the commons component. - The client may get two versions of the same class in their IDE autocomplete (most IDEs allow this to be filtered). This proposal is about making upgrades *predicatable* at the expense of a small amount of pain. I know that most of us don't really like it, but I contend that there is no alternative other than to inflict pain on users of commons over the next few years, and perhaps risk commons becoming irrelevant by being unusable. I also strongly believe we need a cross-commons approach on this. Its perfectly possible for a component to have a major upgrade without breaking backwards compatibility and I don't think we should mandate this. Even when there is a break in backwards compatbility, then using a deprecate / remove cycle should also be open as an option. There may be a number of factors which influence the approach to take - how widely used/depended on the component is, how major or minor the in-compatibility is and how long / many versions the feature has been deprecated before being removed/changed. This should be decided by the component developers on a component by component basis and not mandated as a policy. There are clearly good reasons / circumstances to take the approach you suggest, but it is a user unfriendly approach. As a user I like to try out new versions by dropping in a new jar - before taking the decision to upgrade. This approach rules that out and it wouldn't surprise me if users started to see commons as irrelevant because of "upgrade hell" if we take this route too often. Niall Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Major versions require package name change
On 10/29/06, Stephen Colebourne <[EMAIL PROTECTED]> wrote: PROPOSAL: The major version number of a component, where it is greater than 1, shall be included in the package name. EXAMPLE: org.apache.commons.pool - version 1.x line org.apache.commons.pool2 - version 2.x line RATIONALE: Java has no mechanism for handling different versions of the same library where those versions clash. This leads to a situation known as 'jar hell'. Consider application A dependent on frameworks M and N, both of which depend on a commons component X. A | - | | M N | | - | X Now consider what happens if framework M upgrades to a later version of X, but N does not. The standard approach is to drop in X2 and hope that N still runs. A | - | | M N | | - | X2 However N may not run with X2 if the changes from X to X2 are major and incompatible (which should be signalled via a major version change). Given this situation, the application now has no simple options. They can: a) give up and not upgrade framework M b) petition framework N to upgrade c) dive into the open source and upgrade N themselves d) use two classloaders e) use fancy bytecode weaving tricks to merge the versions f) use jar embedding tools to alter N I would argue that the majority of developers would choose option (a) and give up. This is because while options b-f are possible, they are not what the average *user* wants to spend their time doing. Of course, all of this presents a very simple example. Most open source stacks are much deeper than this and thus the potential for jar hell is much higher. The proposed solution is to rename the package of each commons component at each major version change. This binds all the callers of the commons component to a different package namespace, and thus no clashes, or jar hell will ensue - except by human error. Why now? Because this is the time that the majority of components are starting to consider new incompatible versions, often related to JDK1.5. DOWNSIDES: - The client application has to change their package names when upgrading to a later major version of the commons component. - The client may get two versions of the same class in their IDE autocomplete (most IDEs allow this to be filtered). This proposal is about making upgrades *predicatable* at the expense of a small amount of pain. I know that most of us don't really like it, but I contend that there is no alternative other than to inflict pain on users of commons over the next few years, and perhaps risk commons becoming irrelevant by being unusable. I also strongly believe we need a cross-commons approach on this. Its perfectly possible for a component to have a major upgrade without breaking backwards compatibility and I don't think we should mandate this. Even when there is a break in backwards compatbility, then using a deprecate / remove cycle should also be open as an option. There may be a number of factors which influence the approach to take - how widely used/depended on the component is, how major or minor the in-compatibility is and how long / many versions the feature has been deprecated before being removed/changed. This should be decided by the component developers on a component by component basis and not mandated as a policy. There are clearly good reasons / circumstances to take the approach you suggest, but it is a user unfriendly approach. As a user I like to try out new versions by dropping in a new jar - before taking the decision to upgrade. This approach rules that out and it wouldn't surprise me if users started to see commons as irrelevant because of "upgrade hell" if we take this route too often. Niall Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (COLLECTIONS-230) CollectionUtils.size(null) should return 0
CollectionUtils.size(null) should return 0
--
Key: COLLECTIONS-230
URL: http://issues.apache.org/jira/browse/COLLECTIONS-230
Project: Commons Collections
Issue Type: Wish
Affects Versions: 3.2
Reporter: Stepan Koltsov
Hello,
CollectionUtils.size(null) currently throws
IllegalArgumentException("Unsupported object type: null"). I think
CollectionUtils.size(null) should return 0.
Why?
The aim of library is to minimize the amount of code that uses this library. In
my experience, in the most cases null collections can be threated as as
zero-length. Current behavior causes the need of many trivial null-checks.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pool] intend to propose for a pool 2.0 release soon
On 10/29/06, Stephen Colebourne <[EMAIL PROTECTED]> wrote: This may be another case where we should consider placing the major version number in the package name. I don't think so. There are no binary compatibility changes. Only slight behavioral changes within what has always been allowed for a pool implementations. Basically the changes are to be less exception happy or try harder before giving up with an exception. For pool 3 I want remove the throws declarations that are no longer needed by pool 2 changes and this will cause source incompatibilities but not binary incompatibilities. Sandy McArthur wrote: > As I mentioned on commons-user I plan to prep a pool 2.0 release > candidate in the next week. I'll compile a complete list of changes > but here are the important changes I can recall right now. > > 1. Requires Java 1.4 > 2. Adds the org.apache.commons.pool.composite pool implementation that > I started writing almost a year ago. > 3. Changes the behavior of getNumActive and getNumIdle so they return > a negative value to indicate unsupported operation instead of thrown > an UnsupportedOperationException. > 4. The returnObject, invalidateObject, and close methods no longer > throw Exceptions. The rational being code calling these methods would > rather have any internal exceptions swallowed instead of being > propagated and having to deal with them. > 5. borrowObject swallows exceptions that originate from activating an > idle object but throw an exception that originates from the factory's > makeObject method. > > Expanded details at: http://wiki.apache.org/jakarta-commons/PoolRoadMap > > I plan to look at issues POOL-85 and POOL-86 and change the > pacakge.html for the composite package because it has a lot of > information intended for pool developers and not programmers using > pool. > > https://issues.apache.org/jira/browse/POOL-85 > https://issues.apache.org/jira/browse/POOL-86 > http://svn.apache.org/viewvc/jakarta/commons/proper/pool/trunk/src/java/org/apache/commons/pool/composite/package.html?revision=465936 > > > Any thoughts or objections? > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Sandy McArthur "He who dares not offend cannot be honest." - Thomas Paine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TLS for FTP
Niklas Gustavsson wrote: Rory Winston wrote: Susanne It may be possible that there is a bug in the FTPSClient impl - can you post a transcript of the FTP commands and responses sent over the wire? I've now tested this with FtpServer and I think I got a clue as to what is going on. But, I would like to confirm my suspicions with you :-) I'm CCing the FtpServer list on the discussion. When using the PROT P command in active mode, the FTP server will try to connect using SSL to the client. In this case the server acts as the SSL client. However, this seems to fail and we get a cleartext data connection. My feeling is that this is because the commons-net SSLContext does not set a keystore it can't act as a SSL server. However, I haven't tested patching FTPSClient yet so I'm not sure. If I run in passive mode (where the FTPSClient will act as a SSL client and FtpServer as a SSL server also for the data connection) everything seems to work as expected. You can find my simple test case here: http://svn.apache.org/repos/asf/incubator/ftpserver/ssl-tests/trunk/src/test/org/apache/ftpserver/ssl/DataConnectionTest.java Note that this tests differs from what Susanne described as I get a into problems on a single STOR. This might be because I have some basic misconfiguration, is so feel free to point me the right way :-) With some additional testing I was able to get everything to work. Not sure if it's the optimal solution but anyways, here's how I did it. The FTPSClient needs the have a SSL enabled ServerSocketFactory set, e.g.: client.setServerSocketFactory(SSLServerSocketFactory.getDefault()); Since we're now using the standard SSL socket implementation, it will look the the regular system properties for the key and trust stores. So I created a keystore for the client, containing a key pair for the client and I then imported the certificate for the server (exported from the server keystore). I then set the system properties and everything now seems to works as expected. The test case referred to above as been updated with these fixes. I should also say that I got this working within my Eclipse environment, not yet in the Maven build. Still not sure why but I'm looking into it. /niklas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (DBCP-198) PoolingDataSource.PoolGuardConnectionWrapper equals() implementation incorrect
[
http://issues.apache.org/jira/browse/DBCP-198?page=comments#action_12445464 ]
Phil Steitz commented on DBCP-198:
--
Additional tests and fix to handle the case where accessToUnderlyingConnection
is false committed in r469008.
> PoolingDataSource.PoolGuardConnectionWrapper equals() implementation incorrect
> --
>
> Key: DBCP-198
> URL: http://issues.apache.org/jira/browse/DBCP-198
> Project: Commons Dbcp
> Issue Type: Bug
>Affects Versions: 1.2.1
>Reporter: Kevin Ruland
> Fix For: 1.2.2
>
>
> The Object.equals( Object ) implementation in
> PoolingDataSource.PoolGuardConnectionWrapper is broken because it does not
> attempt to test if the outermost objects are equal. It should be replaced
> with something like:
> public boolean equals(Object obj) {
> if ( obj == this ) return true;
> if ( obj instanceof PoolGuardConnectionWrapper ) {
> return delegate.equals( ((PoolGuardConnectionWrapper) obj).delegate );
> return false;
> }
> The current implementation prevents putting PoolGuardConenctionWrapper
> objects in Collections and using the standard contains( Object ) or remove(
> Object ) methods.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r469008 - in /jakarta/commons/proper/dbcp/trunk/src: java/org/apache/commons/dbcp/ test/org/apache/commons/dbcp/
Author: psteitz
Date: Sun Oct 29 13:48:02 2006
New Revision: 469008
URL: http://svn.apache.org/viewvc?view=rev&rev=469008
Log:
Added tests and fixed errors remaining in DelegatingConnection,
PoolGuardConnectionWrapper equals implementations.
JIRA: DBCP-198
Modified:
jakarta/commons/proper/dbcp/trunk/src/java/org/apache/commons/dbcp/DelegatingConnection.java
jakarta/commons/proper/dbcp/trunk/src/java/org/apache/commons/dbcp/PoolingDataSource.java
jakarta/commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/TestDelegatingConnection.java
jakarta/commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/TestPoolingDataSource.java
Modified:
jakarta/commons/proper/dbcp/trunk/src/java/org/apache/commons/dbcp/DelegatingConnection.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/dbcp/trunk/src/java/org/apache/commons/dbcp/DelegatingConnection.java?view=diff&rev=469008&r1=469007&r2=469008
==
---
jakarta/commons/proper/dbcp/trunk/src/java/org/apache/commons/dbcp/DelegatingConnection.java
(original)
+++
jakarta/commons/proper/dbcp/trunk/src/java/org/apache/commons/dbcp/DelegatingConnection.java
Sun Oct 29 13:48:02 2006
@@ -120,15 +120,30 @@
public Connection getDelegate() {
return _conn;
}
+
+public boolean innermostDelegateEquals(Connection c) {
+Connection innerCon = getInnermostDelegate();
+if (innerCon == null) {
+return c == null;
+} else {
+return innerCon.equals(c);
+}
+}
public boolean equals(Object obj) {
+if (obj == null) {
+return false;
+}
+if (obj == this) {
+return true;
+}
Connection delegate = getInnermostDelegate();
if (delegate == null) {
return false;
}
-if (obj instanceof DelegatingConnection) {
+if (obj instanceof DelegatingConnection) {
DelegatingConnection c = (DelegatingConnection) obj;
-return delegate.equals(c.getInnermostDelegate());
+return c.innermostDelegateEquals(delegate);
}
else {
return delegate.equals(obj);
Modified:
jakarta/commons/proper/dbcp/trunk/src/java/org/apache/commons/dbcp/PoolingDataSource.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/dbcp/trunk/src/java/org/apache/commons/dbcp/PoolingDataSource.java?view=diff&rev=469008&r1=469007&r2=469008
==
---
jakarta/commons/proper/dbcp/trunk/src/java/org/apache/commons/dbcp/PoolingDataSource.java
(original)
+++
jakarta/commons/proper/dbcp/trunk/src/java/org/apache/commons/dbcp/PoolingDataSource.java
Sun Oct 29 13:48:02 2006
@@ -209,25 +209,15 @@
return delegate.createStatement(resultSetType,
resultSetConcurrency);
}
-
-public boolean equals(Object obj) {
-if (obj == null) {
-return false;
-}
-if (obj == this) {
-return true;
-}
-if (delegate == null) {
-return false;
-}
-if (obj instanceof PoolGuardConnectionWrapper) {
-PoolGuardConnectionWrapper w = (PoolGuardConnectionWrapper)
obj;
-return delegate.equals(w.delegate);
+public boolean innermostDelegateEquals(Connection c) {
+Connection innerCon = super.getInnermostDelegate();
+if (innerCon == null) {
+return c == null;
} else {
-return delegate.equals(obj);
+return innerCon.equals(c);
}
}
-
+
public boolean getAutoCommit() throws SQLException {
checkOpen();
return delegate.getAutoCommit();
@@ -263,6 +253,27 @@
return 0;
}
return delegate.hashCode();
+}
+
+public boolean equals(Object obj) {
+if (obj == null) {
+return false;
+}
+if (obj == this) {
+return true;
+}
+// Use superclass accessor to skip access test
+Connection delegate = super.getInnermostDelegate();
+if (delegate == null) {
+return false;
+}
+if (obj instanceof DelegatingConnection) {
+DelegatingConnection c = (DelegatingConnection) obj;
+return c.innermostDelegateEquals(delegate);
+}
+else {
+return delegate.equals(obj);
+}
}
public boolean isReadOnly() throws SQLException {
Modified:
jakarta/commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/TestDelegatingConnection.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/dbcp
Re: TLS for FTP
Rory Winston wrote: Susanne It may be possible that there is a bug in the FTPSClient impl - can you post a transcript of the FTP commands and responses sent over the wire? I've now tested this with FtpServer and I think I got a clue as to what is going on. But, I would like to confirm my suspicions with you :-) I'm CCing the FtpServer list on the discussion. When using the PROT P command in active mode, the FTP server will try to connect using SSL to the client. In this case the server acts as the SSL client. However, this seems to fail and we get a cleartext data connection. My feeling is that this is because the commons-net SSLContext does not set a keystore it can't act as a SSL server. However, I haven't tested patching FTPSClient yet so I'm not sure. If I run in passive mode (where the FTPSClient will act as a SSL client and FtpServer as a SSL server also for the data connection) everything seems to work as expected. You can find my simple test case here: http://svn.apache.org/repos/asf/incubator/ftpserver/ssl-tests/trunk/src/test/org/apache/ftpserver/ssl/DataConnectionTest.java Note that this tests differs from what Susanne described as I get a into problems on a single STOR. This might be because I have some basic misconfiguration, is so feel free to point me the right way :-) /niklas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r468993 - in /jakarta/commons/proper/betwixt/trunk/xdocs: cvs-usage.xml issue-tracking.xml
Author: rdonkin Date: Sun Oct 29 12:58:43 2006 New Revision: 468993 URL: http://svn.apache.org/viewvc?view=rev&rev=468993 Log: Added a couple of improved reports. Derived from Commons Collections versions. Added: jakarta/commons/proper/betwixt/trunk/xdocs/cvs-usage.xml jakarta/commons/proper/betwixt/trunk/xdocs/issue-tracking.xml Added: jakarta/commons/proper/betwixt/trunk/xdocs/cvs-usage.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/betwixt/trunk/xdocs/cvs-usage.xml?view=auto&rev=468993 == --- jakarta/commons/proper/betwixt/trunk/xdocs/cvs-usage.xml (added) +++ jakarta/commons/proper/betwixt/trunk/xdocs/cvs-usage.xml Sun Oct 29 12:58:43 2006 @@ -0,0 +1,45 @@ + + + + + Source repository + Commons Documentation Team + + + + + + Jakarta Commons Betwixt is hosted on the Apache + http://subversion.tigris.org/";>subversion repository. + + + The project URL is: + http://svn.apache.org/repos/asf/jakarta/commons/proper/betwixt/trunk + + + The best way to view the repository is via the + http://svn.apache.org/viewcvs.cgi/jakarta/commons/proper/betwixt/trunk/";>subversion viewer. + + + The alternative is to use the + http://svn.apache.org/repos/asf/jakarta/commons/proper/betwixt/trunk/";>native subversion display. + + + + + Added: jakarta/commons/proper/betwixt/trunk/xdocs/issue-tracking.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/betwixt/trunk/xdocs/issue-tracking.xml?view=auto&rev=468993 == --- jakarta/commons/proper/betwixt/trunk/xdocs/issue-tracking.xml (added) +++ jakarta/commons/proper/betwixt/trunk/xdocs/issue-tracking.xml Sun Oct 29 12:58:43 2006 @@ -0,0 +1,67 @@ + + + + + Issue tracking + Commons Documentation Team + + + + + + Commons Betwixt uses http://issues.apache.org/jira/browse/BETWIXT";>ASF JIRA for tracking issues. + + + To use JIRA you may need to http://issues.apache.org/jira/secure/Signup!default.jspa";>create an account + (if you have previously created/updated Commons issues using Bugzilla an account will have been automatically + created and you can use the http://issues.apache.org/jira/secure/ForgotPassword!default.jspa";>Forgot Password + page to get a new password). + + + If you would like to report a bug, or raise an enhancement request with + Commons Betwixt please do the following: + + http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&pid=12310461&sorter/field=issuekey&sorter/order=DESC&status=1&status=4";>Search existing open bugs. + If you find your issue listed then please add a comment with your details. + http://mail-archives.apache.org/mod_mbox/jakarta-commons-dev/";>Search the mailing list archive. + You may find your issue or idea has already been discussed. + Decide if your issue is a bug or an enhancement. + Submit either a http://issues.apache.org/jira/secure/CreateIssueDetails!init.jspa?pid=12310461&issuetype=1&priority=4&assignee=-1";>bug report + or http://issues.apache.org/jira/secure/CreateIssueDetails!init.jspa?pid=12310461&issuetype=4&priority=4&assignee=-1";>enhancement request. + + + + Please also remember these points: + + the more information you provide, the better we can help you + test cases are vital, particularly for any proposed enhancements + the developers of Commons Betwixt are all unpaid volunteers + + + + You may also find these links useful: + + http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&pid=12310461&sorter/field=issuekey&sorter/order=DESC&status=1&status=4";>All Open Betwixt bugs + http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&pid=12310461&sorter/field=issuekey&sorter/order=DESC&status=5&status=6";>All Resolved Betwixt bugs + http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&pid=12310461&sorter/field=issuekey&sorter/order=DESC";>All Betwixt bugs + + + + + + - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (LANG-291) Null-safe comparison methods for finding most recent / least recent dates.
[ http://issues.apache.org/jira/browse/LANG-291?page=all ] David J. M. Karlsen updated LANG-291: - Attachment: DateUtils-patch-rev468924.txt Patch includes the two implementations and tests > Null-safe comparison methods for finding most recent / least recent dates. > -- > > Key: LANG-291 > URL: http://issues.apache.org/jira/browse/LANG-291 > Project: Commons Lang > Issue Type: Improvement > Environment: N/A >Reporter: David J. M. Karlsen > Attachments: DateUtils-patch-rev468924.txt > > > /** > * > * Null-safe date comparison. > * Returnes the most recent date if date1 and date2 is non-null. > * If one of the dates are null, the non-null will be returned. > * If both are null, null will be returned. > * > * @param date1 > * @param date2 > * @return > */ > public static Date mostRecent( Date date1, Date date2 ) > /** > * > * Null-safe date comparison. > * Returnes the least recent (oldest) date if date1 and date2 is > non-null. > * If one of the dates are null, the non-null will be returned. > * If both are null, null will be returned. > * > * @param date1 > * @param date2 > * @return > */ > public static Date leastRecent( Date date1, Date date2 ) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (LANG-291) Null-safe comparison methods for finding most recent / least recent dates.
Null-safe comparison methods for finding most recent / least recent dates. -- Key: LANG-291 URL: http://issues.apache.org/jira/browse/LANG-291 Project: Commons Lang Issue Type: Improvement Environment: N/A Reporter: David J. M. Karlsen /** * * Null-safe date comparison. * Returnes the most recent date if date1 and date2 is non-null. * If one of the dates are null, the non-null will be returned. * If both are null, null will be returned. * * @param date1 * @param date2 * @return */ public static Date mostRecent( Date date1, Date date2 ) /** * * Null-safe date comparison. * Returnes the least recent (oldest) date if date1 and date2 is non-null. * If one of the dates are null, the non-null will be returned. * If both are null, null will be returned. * * @param date1 * @param date2 * @return */ public static Date leastRecent( Date date1, Date date2 ) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (BEANUTILS-252) getNestedProperty doesn't work with maps properly
getNestedProperty doesn't work with maps properly
-
Key: BEANUTILS-252
URL: http://issues.apache.org/jira/browse/BEANUTILS-252
Project: Commons BeanUtils
Issue Type: Bug
Affects Versions: 1.7.0 Release
Environment: Any
Reporter: Masker71
Hello,
Here is an example of PropertyUtils.getProperty use:
HashMap myMap = new HashMap();
myMap.put("key","value");
Request:
System.out.println(PropertyUtils.getProperty(myMap, "(key)"));
Result:
null
Workaround:
HashMap myMap = new HashMap();
myMap.put("(key)","value");
Request:
System.out.println(PropertyUtils.getProperty(myMap, "(key)"));
Result:
value
The reason of this behaviour is that in the implementation of
PropertyUtilsBean.getNestedProperty function.
Currently it doesn't extract 'key' from brackets. variable name is equal to
"(key)" when this method is invoked
and it is used to extract value from the map:
indexOfINDEXED_DELIM = name.indexOf(PropertyUtils.INDEXED_DELIM);
indexOfMAPPED_DELIM = name.indexOf(PropertyUtils.MAPPED_DELIM);
if (bean instanceof Map) {
bean = ((Map) bean).get(name);
} else if (indexOfMAPPED_DELIM >= 0) {
bean = getMappedProperty(bean, name);
} else if (indexOfINDEXED_DELIM >= 0) {
bean = getIndexedProperty(bean, name);
} else {
bean = getSimpleProperty(bean, name);
}
For the bean methods which returs maps key extraction is performed, why it
isn't done for the Map? Cannot I use any string as a key in the map, why should
I use keys enveloped in brackets? I think what is mentioned to do is that:
indexOfINDEXED_DELIM = name.indexOf(PropertyUtils.INDEXED_DELIM);
indexOfMAPPED_DELIM = name.indexOf(PropertyUtils.MAPPED_DELIM);
indexOfMAPPED_DELIM2 = name.indexOf(PropertyUtils.MAPPED_DELIM2);
if (bean instanceof Map) {
if (indexOfMAPPED_DELIM >= 0 && indexOfMAPPED_DELIM2>=0)
name = name.substring(indexOfMAPPED_DELIM+1,
indexOfMAPPED_DELIM2);
bean = ((Map) bean).get(name);
}
Hope description was clear enough and you will approve it as a bug.
Thank you
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] Cloneable replacement/CloneBuilder
We already have SerializationUtils.clone() to help with cloning.
I can't see how a CloneBuilder would help. Each clone is a very class
specific function, and typically needs to be written directly within the
class itself.
There just might be a role for a public clone interface, although it
really needs to be in the JDK to be of any use.
Stephen
Gregor Zeitlinger wrote:
1)
Since Cloneable is broken in Java, I think it would be a good idea to
introduce a better solution. The simplest solution would be
public interface Copyable extends Cloneable {
public Object clone();
}
This would get rid of the problem that the clone method is not part of
the Cloneable interface.
I doesn't solve the problem that it would be nice to require that the
cloned object is exactly the same type:
public this clone();
but this isn't possible in Java.
2)
I would welcome a utility class that assists in implementing clone:
CloneBuilder
I don't really know the best way to do this, but it is important to
keep inheritance in mind.
public interface Copyable extends Cloneable {
public Object clone();
public Object clone(Object result);
}
public class A implements Copyable {
..
}
public class B extends A {
int value;
public Object clone() {
return clone(new B());
}
public Object clone(Object result) {
super.clone(result);
B other = (B) result;
other.value = value;
}
}
The CloneBuilder would preferably make this simpler.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r468948 - in /jakarta/commons/proper/betwixt/trunk/xdocs: index.xml tasks.xml
Author: rdonkin Date: Sun Oct 29 09:44:36 2006 New Revision: 468948 URL: http://svn.apache.org/viewvc?view=rev&rev=468948 Log: Preparations for 0.8 release Modified: jakarta/commons/proper/betwixt/trunk/xdocs/index.xml jakarta/commons/proper/betwixt/trunk/xdocs/tasks.xml Modified: jakarta/commons/proper/betwixt/trunk/xdocs/index.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/betwixt/trunk/xdocs/index.xml?view=diff&rev=468948&r1=468947&r2=468948 == --- jakarta/commons/proper/betwixt/trunk/xdocs/index.xml (original) +++ jakarta/commons/proper/betwixt/trunk/xdocs/index.xml Sun Oct 29 09:44:36 2006 @@ -43,6 +43,21 @@ + + +Note: 0.8 is in preparation. + + +Betwixt 0.8 is a feature release. +Improvements have been made to supression strategies. +Enhancements have been made to mapping formats. +Mixed collections are now handled more completely. +For full details see the tasks documentation. + + +Note these deprecations (since 0.7). + + Betwixt 0.7 is a feature release. Modified: jakarta/commons/proper/betwixt/trunk/xdocs/tasks.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/betwixt/trunk/xdocs/tasks.xml?view=diff&rev=468948&r1=468947&r2=468948 == --- jakarta/commons/proper/betwixt/trunk/xdocs/tasks.xml (original) +++ jakarta/commons/proper/betwixt/trunk/xdocs/tasks.xml Sun Oct 29 09:44:36 2006 @@ -198,7 +198,7 @@ - + Added strategies for suppression of attributes and elements at introspection time. @@ -428,7 +428,7 @@ - + IdStoringStrategy @@ -559,6 +559,10 @@ + + + + @@ -569,6 +573,10 @@ + + + + @@ -666,6 +674,10 @@ + + + + - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r468942 - in /jakarta/commons/proper/betwixt/trunk/src/java/org/apache/commons/betwixt: ElementDescriptor.java IntrospectionConfiguration.java XMLUtils.java
Author: rdonkin
Date: Sun Oct 29 09:05:59 2006
New Revision: 468942
URL: http://svn.apache.org/viewvc?view=rev&rev=468942
Log:
Fixed javadoc warnings
Modified:
jakarta/commons/proper/betwixt/trunk/src/java/org/apache/commons/betwixt/ElementDescriptor.java
jakarta/commons/proper/betwixt/trunk/src/java/org/apache/commons/betwixt/IntrospectionConfiguration.java
jakarta/commons/proper/betwixt/trunk/src/java/org/apache/commons/betwixt/XMLUtils.java
Modified:
jakarta/commons/proper/betwixt/trunk/src/java/org/apache/commons/betwixt/ElementDescriptor.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/betwixt/trunk/src/java/org/apache/commons/betwixt/ElementDescriptor.java?view=diff&rev=468942&r1=468941&r2=468942
==
---
jakarta/commons/proper/betwixt/trunk/src/java/org/apache/commons/betwixt/ElementDescriptor.java
(original)
+++
jakarta/commons/proper/betwixt/trunk/src/java/org/apache/commons/betwixt/ElementDescriptor.java
Sun Oct 29 09:05:59 2006
@@ -234,9 +234,7 @@
/**
* Removes an attribute descriptor from this element descriptor.
- * @param descriptor the AttributeDescriptor that will be
removed.
- *
- * @param descriptor
+ * @param descriptor the AttributeDescriptor to be removed,
not null
*/
public void removeAttributeDescriptor(AttributeDescriptor descriptor) {
getAttributeList().remove(descriptor);
@@ -267,7 +265,8 @@
* Returns an attribute descriptor with a given name or null.
*
* @param name to search for; will be checked against the attributes'
qualified name.
- * @return
+ * @return AttributeDescriptor with the given name,
+ * or null if no descriptor has that name
*/
public AttributeDescriptor getAttributeDescriptor(final String name) {
for (int i = 0, size = attributeDescriptors.length; i < size; i++) {
Modified:
jakarta/commons/proper/betwixt/trunk/src/java/org/apache/commons/betwixt/IntrospectionConfiguration.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/betwixt/trunk/src/java/org/apache/commons/betwixt/IntrospectionConfiguration.java?view=diff&rev=468942&r1=468941&r2=468942
==
---
jakarta/commons/proper/betwixt/trunk/src/java/org/apache/commons/betwixt/IntrospectionConfiguration.java
(original)
+++
jakarta/commons/proper/betwixt/trunk/src/java/org/apache/commons/betwixt/IntrospectionConfiguration.java
Sun Oct 29 09:05:59 2006
@@ -460,7 +460,7 @@
* This is used to suppress attributes, e.g. for versioning.
*
* @since 0.8
- * @param the strategy
+ * @param attributeSuppressionStrategy the strategy
*/
public void setAttributeSuppressionStrategy(
AttributeSuppressionStrategy attributeSuppressionStrategy) {
Modified:
jakarta/commons/proper/betwixt/trunk/src/java/org/apache/commons/betwixt/XMLUtils.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/betwixt/trunk/src/java/org/apache/commons/betwixt/XMLUtils.java?view=diff&rev=468942&r1=468941&r2=468942
==
---
jakarta/commons/proper/betwixt/trunk/src/java/org/apache/commons/betwixt/XMLUtils.java
(original)
+++
jakarta/commons/proper/betwixt/trunk/src/java/org/apache/commons/betwixt/XMLUtils.java
Sun Oct 29 09:05:59 2006
@@ -355,8 +355,7 @@
* @param bufferedContent the body content within a buffer
* whose character data should
* be escaped in a way appropriate for use within a CDATA
- * section of xml.
- * @return escaped character data, not null
+ * section of xml
*/
public static final void escapeCDATAContent(StringBuffer bufferedContent) {
for (int i=2, size = bufferedContent.length(); i
svn commit: r468932 - /jakarta/commons/proper/betwixt/trunk/src/test/org/apache/commons/betwixt/examples/rss/rss-0.91.dtd
Author: rdonkin Date: Sun Oct 29 08:30:16 2006 New Revision: 468932 URL: http://svn.apache.org/viewvc?view=rev&rev=468932 Log: Not sure about the licensing for file. Removed: jakarta/commons/proper/betwixt/trunk/src/test/org/apache/commons/betwixt/examples/rss/rss-0.91.dtd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[collections] WeakArrayList
I recently had a severe memory leak because more listeners were added to a listener list than removed. I solved the problem by adding only WeakReferences and compacting the list in a separate thread. CursorableLinkedList has a similar solution for cursors - except that the cursors are not cleaned up in a separate thread (which is better, now that I'm thinking about it). So what I suggest is a list where the entries are stored in weak references and auto-cleaned like the cursors in CursorableLinkedList. No more removeListener - which is silly anyways. -- Gregor Zeitlinger [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [io] FileSystemUtils.getDrives?
What about File.listRoots() ? It returns / on Linux, even if /var (for example) is a different mount point (see http://java.sun.com/j2se/1.4.2/docs/api/java/io/File.html#listRoots()) Other than that, it would probably work. But there are other methods beyond freeSpace that make sense for a drive/mount point. 1) isReady 2) isRemovable etc. Therefore, Drive should be it's own class. -- Gregor Zeitlinger [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r468919 - in /jakarta/commons/proper/betwixt/trunk: ./ src/test/org/apache/commons/betwixt/ src/test/org/apache/commons/betwixt/dotbetwixt/ src/test/org/apache/commons/betwixt/io/read/ src
Author: rdonkin Date: Sun Oct 29 07:13:20 2006 New Revision: 468919 URL: http://svn.apache.org/viewvc?view=rev&rev=468919 Log: Added missing licenses. Modified: jakarta/commons/proper/betwixt/trunk/doap_betwixt.rdf jakarta/commons/proper/betwixt/trunk/src/test/org/apache/commons/betwixt/PoemBean.betwixt jakarta/commons/proper/betwixt/trunk/src/test/org/apache/commons/betwixt/dotbetwixt/Father.betwixt jakarta/commons/proper/betwixt/trunk/src/test/org/apache/commons/betwixt/dotbetwixt/IgnoreAddersBean.betwixt jakarta/commons/proper/betwixt/trunk/src/test/org/apache/commons/betwixt/dotbetwixt/IgnoreAddersLibraryBean.betwixt jakarta/commons/proper/betwixt/trunk/src/test/org/apache/commons/betwixt/dotbetwixt/IgnoreBean.betwixt jakarta/commons/proper/betwixt/trunk/src/test/org/apache/commons/betwixt/dotbetwixt/IgnorePropertiesLibraryBean.betwixt jakarta/commons/proper/betwixt/trunk/src/test/org/apache/commons/betwixt/dotbetwixt/LibraryBean.betwixt jakarta/commons/proper/betwixt/trunk/src/test/org/apache/commons/betwixt/dotbetwixt/MapBean.betwixt jakarta/commons/proper/betwixt/trunk/src/test/org/apache/commons/betwixt/dotbetwixt/MixedCollectionBean.betwixt jakarta/commons/proper/betwixt/trunk/src/test/org/apache/commons/betwixt/dotbetwixt/PersonWithNamespace.betwixt jakarta/commons/proper/betwixt/trunk/src/test/org/apache/commons/betwixt/io/read/Elements.betwixt jakarta/commons/proper/betwixt/trunk/src/test/org/apache/commons/betwixt/mapping.xml jakarta/commons/proper/betwixt/trunk/src/test/org/apache/commons/betwixt/recursion/HybridBean.java jakarta/commons/proper/betwixt/trunk/src/test/org/apache/commons/betwixt/schema/SimpleBean.betwixt jakarta/commons/proper/betwixt/trunk/src/test/org/apache/commons/betwixt/schema/SimplestBean.betwixt jakarta/commons/proper/betwixt/trunk/src/test/org/apache/commons/betwixt/schema/SimplestElementBean.betwixt jakarta/commons/proper/betwixt/trunk/src/test/org/apache/commons/betwixt/schema/simplest-bean-attribute.xsd jakarta/commons/proper/betwixt/trunk/src/test/org/apache/commons/betwixt/schema/simplest-bean-element.xsd jakarta/commons/proper/betwixt/trunk/src/test/org/apache/commons/betwixt/xmlunit/invalid-personnel-schema.xml jakarta/commons/proper/betwixt/trunk/src/test/org/apache/commons/betwixt/xmlunit/invalid.xml jakarta/commons/proper/betwixt/trunk/src/test/org/apache/commons/betwixt/xmlunit/personnel.xsd jakarta/commons/proper/betwixt/trunk/src/test/org/apache/commons/betwixt/xmlunit/test.xsd jakarta/commons/proper/betwixt/trunk/src/test/org/apache/commons/betwixt/xmlunit/valid-personnel-schema.xml jakarta/commons/proper/betwixt/trunk/src/test/org/apache/commons/betwixt/xmlunit/valid.xml jakarta/commons/proper/betwixt/trunk/src/test/org/apache/commons/digester/rss/Channel.betwixt (contents, props changed) jakarta/commons/proper/betwixt/trunk/src/test/org/apache/commons/digester/rss/Image.betwixt (contents, props changed) jakarta/commons/proper/betwixt/trunk/xdocs/design.xml Modified: jakarta/commons/proper/betwixt/trunk/doap_betwixt.rdf URL: http://svn.apache.org/viewvc/jakarta/commons/proper/betwixt/trunk/doap_betwixt.rdf?view=diff&rev=468919&r1=468918&r2=468919 == --- jakarta/commons/proper/betwixt/trunk/doap_betwixt.rdf (original) +++ jakarta/commons/proper/betwixt/trunk/doap_betwixt.rdf Sun Oct 29 07:13:20 2006 @@ -1,4 +1,20 @@ + http://usefulinc.com/ns/doap#"; xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"; xmlns:asfext="http://projects.apache.org/ns/asfext#"; xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"; xmlns:doap="http://usefulinc.com/ns/doap#"; xml:lang="en"> http://jakarta.apache.org/commons/betwixt/";> Apache Jakarta Commons Betwixt Modified: jakarta/commons/proper/betwixt/trunk/src/test/org/apache/commons/betwixt/PoemBean.betwixt URL: http://svn.apache.org/viewvc/jakarta/commons/proper/betwixt/trunk/src/test/org/apache/commons/betwixt/PoemBean.betwixt?view=diff&rev=468919&r1=468918&r2=468919 == --- jakarta/commons/proper/betwixt/trunk/src/test/org/apache/commons/betwixt/PoemBean.betwixt (original) +++ jakarta/commons/proper/betwixt/trunk/src/test/org/apache/commons/betwixt/PoemBean.betwixt Sun Oct 29 07:13:20 2006 @@ -1,4 +1,20 @@ + Modified: jakarta/commons/proper/betwixt/trunk/src/test/org/apache/commons/betwixt/dotbetwixt/Father.betwixt URL: http://svn.apache.org/viewvc/jakarta/commons/proper/betwixt/trunk/src/test/org/apache/commons/betwixt/dotbetwixt/Father.betwixt?view=diff&rev=468919&r1=468918&r2=468919 == --- jakarta/commons/proper/betwixt/trunk/src/test/org/apache/commons/betwixt/dotbetwixt/Father.betwixt (ori
Re: [io] FileSystemUtils.getDrives?
On 10/29/06, Gregor Zeitlinger <[EMAIL PROTECTED]> wrote:
I recently had the problem to find the partition with the most free
space available.
FileSystemUtils.freeSpace was not working in that case, because I
wanted to check all available drives/mount points.
I solved this problem by using df on Linux and WMI (windows management
instrumentation) on Windows.
It would have been easier in the following form:
for(Drive d : FileSystemUtils.getDrives()) {
if (d.freeSpace() > maxSpace) {
result = d;
maxSpace = d.freeSpace();
}
}
Would you be interested in something like that?
What about File.listRoots() ?
for(Drive d : File.listRoots()) {
if (d.freeSpace() > maxSpace) {
result = d;
maxSpace = d.freeSpace();
}
}
Niall
Gregor Zeitlinger
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[lang] Cloneable replacement/CloneBuilder
1)
Since Cloneable is broken in Java, I think it would be a good idea to
introduce a better solution. The simplest solution would be
public interface Copyable extends Cloneable {
public Object clone();
}
This would get rid of the problem that the clone method is not part of
the Cloneable interface.
I doesn't solve the problem that it would be nice to require that the
cloned object is exactly the same type:
public this clone();
but this isn't possible in Java.
2)
I would welcome a utility class that assists in implementing clone:
CloneBuilder
I don't really know the best way to do this, but it is important to
keep inheritance in mind.
public interface Copyable extends Cloneable {
public Object clone();
public Object clone(Object result);
}
public class A implements Copyable {
..
}
public class B extends A {
int value;
public Object clone() {
return clone(new B());
}
public Object clone(Object result) {
super.clone(result);
B other = (B) result;
other.value = value;
}
}
The CloneBuilder would preferably make this simpler.
--
Gregor Zeitlinger
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[io] FileSystemUtils.getDrives?
I recently had the problem to find the partition with the most free
space available.
FileSystemUtils.freeSpace was not working in that case, because I
wanted to check all available drives/mount points.
I solved this problem by using df on Linux and WMI (windows management
instrumentation) on Windows.
It would have been easier in the following form:
for(Drive d : FileSystemUtils.getDrives()) {
if (d.freeSpace() > maxSpace) {
result = d;
maxSpace = d.freeSpace();
}
}
Would you be interested in something like that?
--
Gregor Zeitlinger
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] good maven2 pom.xml to copy?
Simon Kitching wrote: Hi, I'd like to enable building of digester with maven2. Any suggestions as to which commons project's pom.xml I should base it on? I know some work has been going on for maven2 support recently.. Thanks, Simon You could try the maven-one-plugin [1] (for Maven 2) which has a goal for converting a Maven 1 project.xml file into a Maven 2 pom.xml file. The version of the plugin that has this new feature has not been released yet, but you can try a SNAPSHOT of it if you follow these [2] instructions. It does a reasonable job of converting the pom, but it can't handle everything. [1] http://people.apache.org/~dennisl/maven-one-plugin/ [2] http://maven.apache.org/guides/development/guide-testing-development-plugins.html -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[PROPOSAL] Major versions require package name change
PROPOSAL: The major version number of a component, where it is greater than 1, shall be included in the package name. EXAMPLE: org.apache.commons.pool - version 1.x line org.apache.commons.pool2 - version 2.x line RATIONALE: Java has no mechanism for handling different versions of the same library where those versions clash. This leads to a situation known as 'jar hell'. Consider application A dependent on frameworks M and N, both of which depend on a commons component X. A | - | | M N | | - | X Now consider what happens if framework M upgrades to a later version of X, but N does not. The standard approach is to drop in X2 and hope that N still runs. A | - | | M N | | - | X2 However N may not run with X2 if the changes from X to X2 are major and incompatible (which should be signalled via a major version change). Given this situation, the application now has no simple options. They can: a) give up and not upgrade framework M b) petition framework N to upgrade c) dive into the open source and upgrade N themselves d) use two classloaders e) use fancy bytecode weaving tricks to merge the versions f) use jar embedding tools to alter N I would argue that the majority of developers would choose option (a) and give up. This is because while options b-f are possible, they are not what the average *user* wants to spend their time doing. Of course, all of this presents a very simple example. Most open source stacks are much deeper than this and thus the potential for jar hell is much higher. The proposed solution is to rename the package of each commons component at each major version change. This binds all the callers of the commons component to a different package namespace, and thus no clashes, or jar hell will ensue - except by human error. Why now? Because this is the time that the majority of components are starting to consider new incompatible versions, often related to JDK1.5. DOWNSIDES: - The client application has to change their package names when upgrading to a later major version of the commons component. - The client may get two versions of the same class in their IDE autocomplete (most IDEs allow this to be filtered). This proposal is about making upgrades *predicatable* at the expense of a small amount of pain. I know that most of us don't really like it, but I contend that there is no alternative other than to inflict pain on users of commons over the next few years, and perhaps risk commons becoming irrelevant by being unusable. I also strongly believe we need a cross-commons approach on this. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r468880 - /jakarta/commons/proper/httpclient/tags/HTTPCLIENT_3_1_BETA1/
Author: olegk Date: Sun Oct 29 03:33:11 2006 New Revision: 468880 URL: http://svn.apache.org/viewvc?view=rev&rev=468880 Log: HttpClient release 3.1-beta1 Added: jakarta/commons/proper/httpclient/tags/HTTPCLIENT_3_1_BETA1/ - copied from r468879, jakarta/commons/proper/httpclient/trunk/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pool] intend to propose for a pool 2.0 release soon
This may be another case where we should consider placing the major version number in the package name. Stephen Sandy McArthur wrote: As I mentioned on commons-user I plan to prep a pool 2.0 release candidate in the next week. I'll compile a complete list of changes but here are the important changes I can recall right now. 1. Requires Java 1.4 2. Adds the org.apache.commons.pool.composite pool implementation that I started writing almost a year ago. 3. Changes the behavior of getNumActive and getNumIdle so they return a negative value to indicate unsupported operation instead of thrown an UnsupportedOperationException. 4. The returnObject, invalidateObject, and close methods no longer throw Exceptions. The rational being code calling these methods would rather have any internal exceptions swallowed instead of being propagated and having to deal with them. 5. borrowObject swallows exceptions that originate from activating an idle object but throw an exception that originates from the factory's makeObject method. Expanded details at: http://wiki.apache.org/jakarta-commons/PoolRoadMap I plan to look at issues POOL-85 and POOL-86 and change the pacakge.html for the composite package because it has a lot of information intended for pool developers and not programmers using pool. https://issues.apache.org/jira/browse/POOL-85 https://issues.apache.org/jira/browse/POOL-86 http://svn.apache.org/viewvc/jakarta/commons/proper/pool/trunk/src/java/org/apache/commons/pool/composite/package.html?revision=465936 Any thoughts or objections? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r468849 - /jakarta/commons/proper/digester/trunk/src/java/org/apache/commons/digester/StackAction.java
Author: skitching
Date: Sun Oct 29 01:59:17 2006
New Revision: 468849
URL: http://svn.apache.org/viewvc?view=rev&rev=468849
Log:
Change @since from 1.7.1 to 1.8
Modified:
jakarta/commons/proper/digester/trunk/src/java/org/apache/commons/digester/StackAction.java
Modified:
jakarta/commons/proper/digester/trunk/src/java/org/apache/commons/digester/StackAction.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/digester/trunk/src/java/org/apache/commons/digester/StackAction.java?view=diff&rev=468849&r1=468848&r2=468849
==
---
jakarta/commons/proper/digester/trunk/src/java/org/apache/commons/digester/StackAction.java
(original)
+++
jakarta/commons/proper/digester/trunk/src/java/org/apache/commons/digester/StackAction.java
Sun Oct 29 01:59:17 2006
@@ -40,7 +40,7 @@
*
* See also Digester.setStackAction.
*
- * @since 1.7.1
+ * @since 1.8
*/
public interface StackAction {
/**
@@ -74,4 +74,4 @@
* o is returned but this method could return an alternate object.
*/
public Object onPop(Digester d, String stackName, Object o);
-}
\ No newline at end of file
+}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r468847 - /jakarta/commons/proper/digester/trunk/src/java/org/apache/commons/digester/Digester.java
Author: skitching
Date: Sun Oct 29 01:56:44 2006
New Revision: 468847
URL: http://svn.apache.org/viewvc?view=rev&rev=468847
Log:
Change @since from 1.7.1 to 1.8 as that's what the next release will now be
labelled.
Modified:
jakarta/commons/proper/digester/trunk/src/java/org/apache/commons/digester/Digester.java
Modified:
jakarta/commons/proper/digester/trunk/src/java/org/apache/commons/digester/Digester.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/digester/trunk/src/java/org/apache/commons/digester/Digester.java?view=diff&rev=468847&r1=468846&r2=468847
==
---
jakarta/commons/proper/digester/trunk/src/java/org/apache/commons/digester/Digester.java
(original)
+++
jakarta/commons/proper/digester/trunk/src/java/org/apache/commons/digester/Digester.java
Sun Oct 29 01:56:44 2006
@@ -1023,7 +1023,7 @@
* Define a callback object which is invoked whever an object is pushed
onto
* a digester object stack, or popped off one.
*
- * @since 1.7.1
+ * @since 1.8
*/
public void setStackAction(StackAction stackAction) {
this.stackAction = stackAction;
@@ -1032,7 +1032,7 @@
/**
* See setStackAction.
*
- * @since 1.7.1
+ * @since 1.8
*/
public StackAction getStackAction() {
return stackAction;
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[general] good maven2 pom.xml to copy?
Hi, I'd like to enable building of digester with maven2. Any suggestions as to which commons project's pom.xml I should base it on? I know some work has been going on for maven2 support recently.. Thanks, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r468851 - /jakarta/commons/proper/digester/trunk/RELEASE-NOTES.txt
Author: skitching Date: Sun Oct 29 01:04:32 2006 New Revision: 468851 URL: http://svn.apache.org/viewvc?view=rev&rev=468851 Log: Update version number from 1.7.1 to 1.8; that will be the next release version. Modified: jakarta/commons/proper/digester/trunk/RELEASE-NOTES.txt Modified: jakarta/commons/proper/digester/trunk/RELEASE-NOTES.txt URL: http://svn.apache.org/viewvc/jakarta/commons/proper/digester/trunk/RELEASE-NOTES.txt?view=diff&rev=468851&r1=468850&r2=468851 == --- jakarta/commons/proper/digester/trunk/RELEASE-NOTES.txt (original) +++ jakarta/commons/proper/digester/trunk/RELEASE-NOTES.txt Sun Oct 29 01:04:32 2006 @@ -2,11 +2,11 @@ Commons Digester Package -Version 1.7.1-dev +Version 1.8-dev Release Notes -*** Release notes current as of 2005-09-10 +*** Release notes current as of 2006-10-29 INTRODUCTION @@ -24,12 +24,12 @@ Dependencies = -Release 1.7.1 has the same dependencies as release 1.7. +Release 1.8 has the same dependencies as release 1.7. Compatible Dependency Sets: - Digester 1.7 + Logging 1.0.x + BeanUtils 1.x + Collections 2.x - Digester 1.7 + Logging 1.0.x + BeanUtils 1.x + Collections 3.x - Digester 1.7 + Logging 1.0.x + BeanUtils 1.7 + Digester 1.8 + Logging 1.0.x + BeanUtils 1.x + Collections 2.x + Digester 1.8 + Logging 1.0.x + BeanUtils 1.x + Collections 3.x + Digester 1.8 + Logging 1.0.x + BeanUtils 1.7 NEW FEATURES = @@ -55,6 +55,14 @@ code to monitor all objects pushed onto and popped off digester stacks. In particular, this makes it easier to store source file/line info for all objects created during parsing. + +Namespace Access + + +Method "getCurrentNamespaces" has been added to the Digester class. This allows user +code to get a snapshot of all the prefix->url mappings applicable at a point in time. +This is particularly useful for elements that contain xpath expressions that should +be evaluated later using the same namespaces defined for the element. BUGS FROM PREVIOUS RELEASE == - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
