[jira] [Commented] (LANG-1055) StrSubstitutor.replaceSystemProperties does not work constistently
[
https://issues.apache.org/jira/browse/LANG-1055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14286057#comment-14286057
]
Jonathan Baker commented on LANG-1055:
--
Not sure if this is correct, or if it addresses Phil's concerns, but the
following is an implementation that 1) does not use a singleton, and 2) allows
each instance to have their own snap-shop of the system properties:
https://github.com/apache/commons-lang/pull/43
Thanks in advance for your time.
StrSubstitutor.replaceSystemProperties does not work constistently
--
Key: LANG-1055
URL: https://issues.apache.org/jira/browse/LANG-1055
Project: Commons Lang
Issue Type: Bug
Components: lang.text.*
Affects Versions: 3.3.2
Environment: Windows 7, Java 7
Reporter: Phil Dicke
StrSubsitutor caches a references to SystemProperties statically on first
class references. This does not work properly with System.setProperties().
For example the following code:
{code}
package test.utilities;
import java.util.Properties;
import org.apache.commons.lang.text.StrSubstitutor;
public class TestStrSubstitutor {
public static void main(String[] args) {
System.out.println(StrSubstitutor.replaceSystemProperties(os.name=${os.name}));
Properties testProps = new Properties();
testProps.put(test_key, test_value);
testProps.putAll(System.getProperties());
System.setProperties(testProps);
System.out.println(StrSubstitutor.replace(test_key=${test_key},
System.getProperties()));
System.out.println(StrSubstitutor.replaceSystemProperties(test_key=${test_key}));
}
}
{code}
produces the following output:
{code}
os.name=Windows 7
test_key=test_value
test_key=${test_key}
{code}
The code linked here shows the static caching of the System Properties
reference:
http://commons.apache.org/proper/commons-lang/apidocs/src-html/org/apache/commons/lang3/text/StrLookup.html
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (LANG-1082) Add option to disable the objectsTriviallyEqual test in DiffBuilder.
[ https://issues.apache.org/jira/browse/LANG-1082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedikt Ritter updated LANG-1082: -- Fix Version/s: Patch Needed Patches welcome! :) Add option to disable the objectsTriviallyEqual test in DiffBuilder. -- Key: LANG-1082 URL: https://issues.apache.org/jira/browse/LANG-1082 Project: Commons Lang Issue Type: Improvement Components: lang.builder.* Affects Versions: 3.3.2 Reporter: Jonathan Baker Priority: Trivial Fix For: Patch Needed Original Estimate: 0.25h Remaining Estimate: 0.25h For example, a bean (e.g. a JPA record) has equals() overridden with a implementation that tests its id property. If two beans have the same ID, they correspond to the same record in the database. However, without tricking the objectsTriviallyEqual check in the DiffBuilder constructor, there is no way to build a DiffResult using before and after instances with changes to other properties (name, modification time, etc). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (LANG-1055) StrSubstitutor.replaceSystemProperties does not work constistently
[
https://issues.apache.org/jira/browse/LANG-1055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14286055#comment-14286055
]
ASF GitHub Bot commented on LANG-1055:
--
GitHub user j--baker opened a pull request:
https://github.com/apache/commons-lang/pull/43
LANG-1055: StrLookup.systemPropertiesLookup() not singleton.
- Assuming StrLookup.systemPropertiesLookup() should not be a singleton.
- Assuming each lookup should have its own snap-shot of the system
properties.
Please review the proposed changes.
Thank you!
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/j--baker/commons-lang LANG-1055
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/commons-lang/pull/43.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #43
commit f4d574872bdd488032b296faece7921737518c3a
Author: j--baker j--ba...@users.noreply.github.com
Date: 2015-01-21T18:45:11Z
LANG-1055: Change StrLookup.systemPropertiesLookup() to return a new
instance with its own copy of the current system properties.
StrSubstitutor.replaceSystemProperties does not work constistently
--
Key: LANG-1055
URL: https://issues.apache.org/jira/browse/LANG-1055
Project: Commons Lang
Issue Type: Bug
Components: lang.text.*
Affects Versions: 3.3.2
Environment: Windows 7, Java 7
Reporter: Phil Dicke
StrSubsitutor caches a references to SystemProperties statically on first
class references. This does not work properly with System.setProperties().
For example the following code:
{code}
package test.utilities;
import java.util.Properties;
import org.apache.commons.lang.text.StrSubstitutor;
public class TestStrSubstitutor {
public static void main(String[] args) {
System.out.println(StrSubstitutor.replaceSystemProperties(os.name=${os.name}));
Properties testProps = new Properties();
testProps.put(test_key, test_value);
testProps.putAll(System.getProperties());
System.setProperties(testProps);
System.out.println(StrSubstitutor.replace(test_key=${test_key},
System.getProperties()));
System.out.println(StrSubstitutor.replaceSystemProperties(test_key=${test_key}));
}
}
{code}
produces the following output:
{code}
os.name=Windows 7
test_key=test_value
test_key=${test_key}
{code}
The code linked here shows the static caching of the System Properties
reference:
http://commons.apache.org/proper/commons-lang/apidocs/src-html/org/apache/commons/lang3/text/StrLookup.html
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (COLLECTIONS-548) Performance issue in CompositeCollection::retainAll
[
https://issues.apache.org/jira/browse/COLLECTIONS-548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oswaldo Olivo updated COLLECTIONS-548:
--
Description:
There seems to be a performance problem with the function retainAll of
CompositeCollection. This is analogous to
https://issues.apache.org/jira/browse/COLLECTIONS-534 .
The following is the code of the function:
{code}
/**
* Retains all the elements in the specified collection in this composite
collection,
* removing all others.
* p
* This implementation calls coderetainAll()/code on each collection.
*
* @param coll the collection to remove
* @return true if the collection was modified
* @throws UnsupportedOperationException if retainAll is unsupported
*/
public boolean retainAll(final Collection? coll) {
boolean changed = false;
for (final CollectionE item : all) {
changed |= item.retainAll(coll);
}
return changed;
}
{code}
The performance problem occurs when the underlying collections in the current
collection have a slow retainAll method. Whenever we're relying on
Collection::retainAll, slow cases tend to occur when the parameter collection
has a slow contains method.
The following test harness shows the performance degradation between
using a list and using a set as a parameter, across different collection sizes.
{code}
public static void compositeCollectionRetainAllTest(boolean original) {
int N=50;
ArrayListInteger firstArrayList=new ArrayListInteger();
ArrayListInteger secondArrayList=new ArrayListInteger();
for(int i=0;iN;++i) {
firstArrayList.add(new Integer(i));
secondArrayList.add(new Integer(N-1-i));
}
CompositeCollection col = new CompositeCollection(firstArrayList);
col.retainAll(original ? secondArrayList : (new
HashSetInteger(secondArrayList)));
}
{code}
In the following table Original corresponds to the time taken by
the existing implementation of CompositeCollection::retainAll, Repaired to
the time taken by the function invoked with the parameter converted into a set,
and Speed-up to the speed-up obtained after the repair.
N Original(s) Repaired(s) Speed-up(X)
10 1.04 1.041.00
100 1.04 1.050.99
10001.061.061.00
1 1.121.101.01
10 9.341.158.12
50 300 1.29 232.55
If it's unacceptable to convert the parameter into a set before calling
retainsAll, a solution would be to include a warning to the user in the
documentation that the parameter should have a fast contains method when
possible.
was:
There seems to be a performance problem with the function retainAll of
CompositeCollection.
The following is the code of the function:
{code}
/**
* Retains all the elements in the specified collection in this composite
collection,
* removing all others.
* p
* This implementation calls coderetainAll()/code on each collection.
*
* @param coll the collection to remove
* @return true if the collection was modified
* @throws UnsupportedOperationException if retainAll is unsupported
*/
public boolean retainAll(final Collection? coll) {
boolean changed = false;
for (final CollectionE item : all) {
changed |= item.retainAll(coll);
}
return changed;
}
{code}
The performance problem occurs when the underlying collections in the current
collection have a slow retainAll method. Whenever we're relying on
Collection::retainAll, slow cases tend to occur when the parameter collection
has a slow contains method.
The following test harness shows the performance degradation between
using a list and using a set as a parameter, across different collection sizes.
{code}
public static void compositeCollectionRetainAllTest(boolean original) {
int N=50;
ArrayListInteger firstArrayList=new ArrayListInteger();
ArrayListInteger secondArrayList=new ArrayListInteger();
for(int i=0;iN;++i) {
firstArrayList.add(new Integer(i));
secondArrayList.add(new Integer(N-1-i));
}
CompositeCollection col = new CompositeCollection(firstArrayList);
col.retainAll(original ? secondArrayList : (new
HashSetInteger(secondArrayList)));
}
{code}
In the following table Original corresponds to the time taken by
the existing implementation of CompositeCollection::retainAll, Repaired to
the time taken by the function invoked with the parameter converted into a set,
[jira] [Commented] (CONFIGURATION-595) need optional include without exception
[
https://issues.apache.org/jira/browse/CONFIGURATION-595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14286225#comment-14286225
]
Oliver Heger commented on CONFIGURATION-595:
It is correct that {{PropertiesConfiguration}} does not support optional
includes.
However, you can achieve something similar - and more flexible and powerful -
with {{CombinedConfigurationBuilder}} (or {{DefaultConfigurationBuilder}} if
you are still using version 1.10). This class allows constructing a combined
configuration from an arbitrary number of configuration sources. Optional
sources are supported as well. This is described in the user's guide at
http://commons.apache.org/proper/commons-configuration/userguide/howto_combinedbuilder.html#Optional_configuration_sources
Please have a look and tell us whether this fits your needs. I am a bit
reluctant of extending the include mechanism of {{PropertiesConfiguration}}
because it is a specific feature of this class and not supported by other
configuration implementations - especially if combined configuration sources
offer a super set of the functionality available.
need optional include without exception
---
Key: CONFIGURATION-595
URL: https://issues.apache.org/jira/browse/CONFIGURATION-595
Project: Commons Configuration
Issue Type: Improvement
Components: Expression engine
Affects Versions: 2.x, 1.10
Reporter: ryenus
I'm trying to include a server local properties file during initialization of
a distributed application.
The file to be included might not exist on some of the servers, and this
should be fine in terms of our application logic.
But this is not possible with commons configuration, inside
org.apache.commons.configuration.PropertiesConfiguration.loadIncludeFile(String),
when an included file doesn't exist, namely the resolved url would be null,
it always throws a ConfigurationException.
See:
https://github.com/apache/commons-configuration/blob/trunk/src/main/java/org/apache/commons/configuration2/PropertiesConfiguration.java#L1414
This might be good to ensure configuration integrity, but looking around, for
bash, ~/.bashrc is optional, for maven, ~/.m2/settings.xml is optional, I
wish there could be a way to do the same in commons configurations.
One way is to skip the exception, and print a warning to stderr (or some
better logging options).
Alternatively, an `optionalInclude` key can be introduced to serve this
purpose.
Thanks!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (COLLECTIONS-548) Performance issue in CompositeCollection::retainAll
Oswaldo Olivo created COLLECTIONS-548:
-
Summary: Performance issue in CompositeCollection::retainAll
Key: COLLECTIONS-548
URL: https://issues.apache.org/jira/browse/COLLECTIONS-548
Project: Commons Collections
Issue Type: Bug
Components: Collection
Affects Versions: 4.1
Environment: Ubuntu 14.04
Reporter: Oswaldo Olivo
Priority: Minor
There seems to be a performance problem with the function retainAll of
CompositeCollection.
The following is the code of the function:
{code}
/**
* Retains all the elements in the specified collection in this composite
collection,
* removing all others.
* p
* This implementation calls coderetainAll()/code on each collection.
*
* @param coll the collection to remove
* @return true if the collection was modified
* @throws UnsupportedOperationException if retainAll is unsupported
*/
public boolean retainAll(final Collection? coll) {
boolean changed = false;
for (final CollectionE item : all) {
changed |= item.retainAll(coll);
}
return changed;
}
{code}
The performance problem occurs when the underlying collections in the current
collection have a slow retainAll method. Whenever we're relying on
Collection::retainAll, slow cases tend to occur when the parameter collection
has a slow contains method.
The following test harness shows the performance degradation between
using a list and using a set as a parameter, across different collection sizes.
{code}
public static void compositeCollectionRetainAllTest(boolean original) {
int N=50;
ArrayListInteger firstArrayList=new ArrayListInteger();
ArrayListInteger secondArrayList=new ArrayListInteger();
for(int i=0;iN;++i) {
firstArrayList.add(new Integer(i));
secondArrayList.add(new Integer(N-1-i));
}
CompositeCollection col = new CompositeCollection(firstArrayList);
col.retainAll(original ? secondArrayList : (new
HashSetInteger(secondArrayList)));
}
{code}
In the following table Original corresponds to the time taken by
the existing implementation of CompositeCollection::retainAll, Repaired to
the time taken by the function invoked with the parameter converted into a set,
and Speed-up to the speed-up obtained after the repair.
N Original(s) Repaired(s) Speed-up(X)
10 1.04 1.041.00
100 1.04 1.050.99
10001.061.061.00
1 1.121.101.01
10 9.341.158.12
50 300 1.29 232.55
If it's unacceptable to convert the parameter into a set before calling
retainsAll, a solution would be to include a warning to the user in the
documentation that the parameter should have a fast contains method when
possible.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (COLLECTIONS-547) Performance issue in SetUtils::isEqualSet
Oswaldo Olivo created COLLECTIONS-547:
-
Summary: Performance issue in SetUtils::isEqualSet
Key: COLLECTIONS-547
URL: https://issues.apache.org/jira/browse/COLLECTIONS-547
Project: Commons Collections
Issue Type: Bug
Components: Set
Affects Versions: 4.1
Environment: Ubuntu 14.04
Reporter: Oswaldo Olivo
Priority: Minor
There seems to be a performance problem with the function isEqualSet of
SetUtils when the first parameter is of a collection type that has a slow
containsAll/contains method.
The following is the code of the function:
{code}
/**
* Tests two sets for equality as per the codeequals()/code contract
* in {@link java.util.Set#equals(java.lang.Object)}.
* p
* This method is useful for implementing codeSet/code when you cannot
* extend AbstractSet. The method takes Collection instances to enable other
* collection types to use the Set implementation algorithm.
* p
* The relevant text (slightly paraphrased as this is a static method) is:
* blockquote
* pTwo sets are considered equal if they have
* the same size, and every member of the first set is contained in
* the second. This ensures that the ttequals/tt method works
* properly across different implementations of the ttSet/tt
* interface./p
*
* p
* This implementation first checks if the two sets are the same object:
* if so it returns tttrue/tt. Then, it checks if the two sets are
* identical in size; if not, it returns false. If so, it returns
* tta.containsAll((Collection) b)/tt./p
* /blockquote
*
* @see java.util.Set
* @param set1 the first set, may be null
* @param set2 the second set, may be null
* @return whether the sets are equal by value comparison
*/
public static boolean isEqualSet(final Collection? set1, final
Collection? set2) {
if (set1 == set2) {
return true;
}
if (set1 == null || set2 == null || set1.size() != set2.size()) {
return false;
}
return set1.containsAll(set2);
}
{code}
The problem is that in the last return statement, the function relies on the
containsAll method of the class of the set1, which can be any type of
collection.
The following test harness shows the performance degradation between
using a list and using a set as a first parameter, across different collection
sizes.
{code}
public static void setUtilsisEqualSetTest(boolean original) {
int N=50;
ArrayListInteger firstArrayList=new ArrayListInteger();
ArrayListInteger secondArrayList=new ArrayListInteger();
for(int i=0;iN;++i) {
firstArrayList.add(new Integer(i));
secondArrayList.add(new Integer((N-1)-i));
}
SetUtils.isEqualSet(original?firstArrayList:(new
HashSetInteger(firstArrayList)),secondArrayList);
{code}
In the following table Original corresponds to the time taken by
the existing implementation of SetUtils::isEqualSet, Repaired to the time
taken by the function invoked with the first parameter converted into a
set, and Speed-up to the speed-up obtained after the repair.
NOriginal(s) Repaired(s) Speed-up(X)
10 1.01 1.02 0.99
100 1.02 1.02 1
1000 1.04 1.04 1
1 1.15 1.09 1.05
10 9.33 1.11 8.40
50 300 1.26 238.09
One way to deal with this would be to call the CollectionUtils::containsAll
method instead of Collection::containsAll, since it has a linear time
implementation instead of quadratic, and can handle the types of isEqualSet.
Another solution would be to include a warning to the user in the documentation
that the first parameter should have a fast containment method when possible.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (COLLECTIONS-548) Performance issue in CompositeCollection::retainAll
[
https://issues.apache.org/jira/browse/COLLECTIONS-548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14286597#comment-14286597
]
Oswaldo Olivo commented on COLLECTIONS-548:
---
Here's another potential fix by using a more efficient retainAll method in the
spirit of CollectionUtils::containsAll
{code}
// Eliminates from coll1 all elements that are not in coll2.
// It runs in O(m+n) size, requiring additional O(m) space.
public static boolean efficientRetainAll(final Collection? coll1,final
Collection? coll2) {
// If coll2 is empty there are no elements to retain.
if(coll2.isEmpty()) {
return coll1.removeAll(coll1);
}
// Simple case when we're supposed to retain all elements
// in the first collection.
if(coll1==coll2)
return false;
// it1 iterates over coll1 and it2 iterares over coll2,
// and seen contains all the elements before it2, allowing
// us to never revisit previous elements.
// The algorithm iterates through it1, checks to see if we've
// already seen the current element of it1 via a Hashset
// efficient check, or traverses elements of it2 until we find
// it or it2 ends. At each iteration over it2 we add the
// elements to seen to avoid revisiting items.
Iterator? it1 = coll1.iterator();
Iterator? it2 = coll2.iterator();
HashSetObject seen = new HashSetObject();
boolean changed=false;
// Traverse all the elements in coll1.
while(it1.hasNext()) {
final Object o=it1.next();
// If we've seen this element in coll2, keep it.
if(seen.contains(o))
continue;
// Otherwise, check for its containment in coll2, while
// adding the elements to seen.
boolean contained=false;
while(it2.hasNext()) {
final Object o2=it2.next();
seen.add(o2);
// Found the element in coll2.
if(o2.equals(o)) {
contained=true;
break;
}
}
// If the element was not found in coll2, remove it from it1.
if(!contained) {
changed=true;
it1.remove();
}
}
return changed;
}
{code}
--
And the harness:
---
{code}
public static void compositeCollectionRetainAllTest(boolean original) {
int N=50;
ArrayListInteger firstArrayList=new ArrayListInteger();
ArrayListInteger secondArrayList=new ArrayListInteger();
for(int i=0;iN;++i) {
firstArrayList.add(new Integer(i));
secondArrayList.add(new Integer(N-1-i));
}
CompositeCollection col = new CompositeCollection(firstArrayList);
if(original)
col.retainAll(secondArrayList);
else
efficientRetainAll(col,secondArrayList);
}
{code}
--
The results are:
N Original(s) Repaired(s) Speed-up(X)
10 1.04 1.050.99
100 1.04 1.050.99
1000 1.06 1.061.00
11.12 1.101.01
10 9.34 1.158.12
50300 1.34 223.88
Performance issue in CompositeCollection::retainAll
---
Key: COLLECTIONS-548
URL: https://issues.apache.org/jira/browse/COLLECTIONS-548
Project: Commons Collections
Issue Type: Bug
Components: Collection
Affects Versions: 4.1
Environment: Ubuntu 14.04
Reporter: Oswaldo Olivo
Priority: Minor
Labels: performance
There seems to be a performance problem with the function retainAll of
CompositeCollection. This is analogous to
https://issues.apache.org/jira/browse/COLLECTIONS-534 .
The following is the code of the function:
{code}
/**
* Retains all the elements in the specified collection in this composite
collection,
* removing all others.
* p
* This implementation calls coderetainAll()/code on each collection.
*
* @param coll the collection to remove
* @return true if the collection was modified
* @throws UnsupportedOperationException if retainAll is unsupported
*/
public boolean retainAll(final Collection? coll) {
boolean changed = false;
for (final CollectionE item : all) {
[jira] [Created] (COLLECTIONS-549) Linear time implementation of retainAll for CollectionUtils
Oswaldo Olivo created COLLECTIONS-549:
-
Summary: Linear time implementation of retainAll for
CollectionUtils
Key: COLLECTIONS-549
URL: https://issues.apache.org/jira/browse/COLLECTIONS-549
Project: Commons Collections
Issue Type: Improvement
Components: Collection
Affects Versions: 4.1
Environment: Ubuntu 14.04
Reporter: Oswaldo Olivo
CollectionUtils provides a linear time implementation of containsAll using
additional linear space.
There is a linear time implementation of retainAll as follows:
{code}
// Eliminates from coll1 all elements that are not in coll2.
// It runs in O(m+n) size, requiring additional O(m) space.
public static boolean efficientRetainAll(final Collection? coll1,final
Collection? coll2) {
// If coll2 is empty there are no elements to retain.
if(coll2.isEmpty()) {
return coll1.removeAll(coll1);
}
// Simple case when we're supposed to retain all elements
// in the first collection.
if(coll1==coll2)
return false;
// it1 iterates over coll1 and it2 iterares over coll2,
// and seen contains all the elements before it2, allowing
// us to never revisit previous elements.
// The algorithm iterates through it1, checks to see if we've
// already seen the current element of it1 via a Hashset
// efficient check, or traverses elements of it2 until we find
// it or it2 ends. At each iteration over it2 we add the
// elements to seen to avoid revisiting items.
Iterator? it1 = coll1.iterator();
Iterator? it2 = coll2.iterator();
HashSetObject seen = new HashSetObject();
boolean changed=false;
// Traverse all the elements in coll1.
while(it1.hasNext()) {
final Object o=it1.next();
// If we've seen this element in coll2, keep it.
if(seen.contains(o))
continue;
// Otherwise, check for its containment in coll2, while
// adding the elements to seen.
boolean contained=false;
while(it2.hasNext()) {
final Object o2=it2.next();
seen.add(o2);
// Found the element in coll2.
if(o2.equals(o)) {
contained=true;
break;
}
}
// If the element was not found in coll2, remove it from it1.
if(!contained) {
changed=true;
it1.remove();
}
}
return changed;
}
{code}
Besides providing this in CollectionUtils for the user, this function could be
beneficial within other functions, where the existing retainAll exhibits a
significant slowdown for large collections:
1) https://issues.apache.org/jira/browse/COLLECTIONS-534
2) https://issues.apache.org/jira/browse/COLLECTIONS-548
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LANG-1082) Add option to disable the objectsTriviallyEqual test in DiffBuilder.
[
https://issues.apache.org/jira/browse/LANG-1082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14286579#comment-14286579
]
Jonathan Baker commented on LANG-1082:
--
I'd be happy to throw some code out there, but I want to make sure I'm
preserving the original spirit.
My gut tells me DiffBuilder should remain immutable.
Would adding a second constructor be the best fit?
public DiffBuilder( boolean testTriviallyEqual ) { ... }
public DiffBuilder() { this( true ); }
Thoughts?
Add option to disable the objectsTriviallyEqual test in DiffBuilder.
--
Key: LANG-1082
URL: https://issues.apache.org/jira/browse/LANG-1082
Project: Commons Lang
Issue Type: Improvement
Components: lang.builder.*
Affects Versions: 3.3.2
Reporter: Jonathan Baker
Priority: Trivial
Fix For: Patch Needed
Original Estimate: 0.25h
Remaining Estimate: 0.25h
For example, a bean (e.g. a JPA record) has equals() overridden with a
implementation that tests its id property. If two beans have the same ID,
they correspond to the same record in the database. However, without
tricking the objectsTriviallyEqual check in the DiffBuilder constructor,
there is no way to build a DiffResult using before and after instances
with changes to other properties (name, modification time, etc).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (JCS-141) RemoteCacheServerFactory ignores configuration
[ https://issues.apache.org/jira/browse/JCS-141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] validruk updated JCS-141: - Description: RemoteCacheServerFactory ignores configuration from property file, when calls constructor RemoteCacheServer.RemoteCacheServer(IRemoteCacheServerAttributes). There is missing sett property rcsa.setConfigFileName( propFile ), default value is: rcsa.configFileName = Remote cache server then ignores all properties about cache attributes from property file (eg. remote.cacheXY.ccf). was: RemoteCacheServerFactory ignores configuration from property file, when calls constructor org.apache.commons.jcs.auxiliary.remote.server.RemoteCacheServer.RemoteCacheServer(IRemoteCacheServerAttributes). There is missing setted property rcsa.setConfigFileName( propFile ), default value is: rcsa.configFileName = Remote cache server then ignores all properties about cache attributes from property file (eg. remote.cacheXY.ccf). RemoteCacheServerFactory ignores configuration --- Key: JCS-141 URL: https://issues.apache.org/jira/browse/JCS-141 Project: Commons JCS Issue Type: Bug Components: RMI Remote Cache Reporter: validruk Labels: bug, configuration, ignore, remote Original Estimate: 1h Remaining Estimate: 1h RemoteCacheServerFactory ignores configuration from property file, when calls constructor RemoteCacheServer.RemoteCacheServer(IRemoteCacheServerAttributes). There is missing sett property rcsa.setConfigFileName( propFile ), default value is: rcsa.configFileName = Remote cache server then ignores all properties about cache attributes from property file (eg. remote.cacheXY.ccf). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (LANG-1055) StrSubstitutor.replaceSystemProperties does not work constistently
[
https://issues.apache.org/jira/browse/LANG-1055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedikt Ritter updated LANG-1055:
--
Fix Version/s: Review Patch
Setting this to review patch. I'll try to have a look soon.
StrSubstitutor.replaceSystemProperties does not work constistently
--
Key: LANG-1055
URL: https://issues.apache.org/jira/browse/LANG-1055
Project: Commons Lang
Issue Type: Bug
Components: lang.text.*
Affects Versions: 3.3.2
Environment: Windows 7, Java 7
Reporter: Phil Dicke
Fix For: Review Patch
StrSubsitutor caches a references to SystemProperties statically on first
class references. This does not work properly with System.setProperties().
For example the following code:
{code}
package test.utilities;
import java.util.Properties;
import org.apache.commons.lang.text.StrSubstitutor;
public class TestStrSubstitutor {
public static void main(String[] args) {
System.out.println(StrSubstitutor.replaceSystemProperties(os.name=${os.name}));
Properties testProps = new Properties();
testProps.put(test_key, test_value);
testProps.putAll(System.getProperties());
System.setProperties(testProps);
System.out.println(StrSubstitutor.replace(test_key=${test_key},
System.getProperties()));
System.out.println(StrSubstitutor.replaceSystemProperties(test_key=${test_key}));
}
}
{code}
produces the following output:
{code}
os.name=Windows 7
test_key=test_value
test_key=${test_key}
{code}
The code linked here shows the static caching of the System Properties
reference:
http://commons.apache.org/proper/commons-lang/apidocs/src-html/org/apache/commons/lang3/text/StrLookup.html
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LANG-1082) Add option to disable the objectsTriviallyEqual test in DiffBuilder.
[ https://issues.apache.org/jira/browse/LANG-1082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14287066#comment-14287066 ] Benedikt Ritter commented on LANG-1082: --- A second constructor sounds like a good solution. Note however, that the DiffBuilder itself is not immutable, since it holds a reference to the mutable collection of diffs. Add option to disable the objectsTriviallyEqual test in DiffBuilder. -- Key: LANG-1082 URL: https://issues.apache.org/jira/browse/LANG-1082 Project: Commons Lang Issue Type: Improvement Components: lang.builder.* Affects Versions: 3.3.2 Reporter: Jonathan Baker Priority: Trivial Fix For: Patch Needed Original Estimate: 0.25h Remaining Estimate: 0.25h For example, a bean (e.g. a JPA record) has equals() overridden with a implementation that tests its id property. If two beans have the same ID, they correspond to the same record in the database. However, without tricking the objectsTriviallyEqual check in the DiffBuilder constructor, there is no way to build a DiffResult using before and after instances with changes to other properties (name, modification time, etc). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CONFIGURATION-595) need optional include without exception
ryenus created CONFIGURATION-595: Summary: need optional include without exception Key: CONFIGURATION-595 URL: https://issues.apache.org/jira/browse/CONFIGURATION-595 Project: Commons Configuration Issue Type: Improvement Components: Expression engine Affects Versions: 2.x, 1.10 Reporter: ryenus I'm trying to include a server local properties file during initialization of a distributed application. The file to be included might not exist on some of the servers, and this should be fine in terms of our application logic. But this is not possible with commons configuration, inside org.apache.commons.configuration.PropertiesConfiguration.loadIncludeFile(String), when an included file doesn't exist, namely the resolved url would be null, it always throws a ConfigurationException. See: https://github.com/apache/commons-configuration/blob/trunk/src/main/java/org/apache/commons/configuration2/PropertiesConfiguration.java#L1414 This might be good to ensure configuration integrity, but looking around, for bash, ~/.bashrc is optional, for maven, ~/.m2/settings.xml is optional, I wish there could be a way to do the same in commons configurations. One way is to skip the exception, and print a warning to stderr (or some better logging options). Alternatively, an `optionalInclude` key can be introduced to serve this purpose. Thanks! -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (JCS-141) RemoteCacheServerFactory ignores configuration
validruk created JCS-141: Summary: RemoteCacheServerFactory ignores configuration Key: JCS-141 URL: https://issues.apache.org/jira/browse/JCS-141 Project: Commons JCS Issue Type: Bug Components: RMI Remote Cache Reporter: validruk RemoteCacheServerFactory ignores configuration from property file, when calls constructor org.apache.commons.jcs.auxiliary.remote.server.RemoteCacheServer.RemoteCacheServer(IRemoteCacheServerAttributes). There is missing setted property rcsa.setConfigFileName( propFile ), default value is: rcsa.configFileName = Remote cache server then ignores all properties about cache attributes from property file (eg. remote.cacheXY.ccf). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (COLLECTIONS-546) Implement expiring queue like already exist PassiveExpiringMap
Guram Savinov created COLLECTIONS-546: - Summary: Implement expiring queue like already exist PassiveExpiringMap Key: COLLECTIONS-546 URL: https://issues.apache.org/jira/browse/COLLECTIONS-546 Project: Commons Collections Issue Type: New Feature Components: Collection Affects Versions: 4.x Reporter: Guram Savinov It's very useful collection wrapper for map with expiration - PassiveExpiringMap. Can you implement queue with expiration like already exist PassiveExpiringMap? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
