[jira] [Commented] (CONFIGURATION-604) combining properties which use 3+ part names discards entries as of Commons 1.6+
[
https://issues.apache.org/jira/browse/CONFIGURATION-604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14613397#comment-14613397
]
N Campbell commented on CONFIGURATION-604:
--
Simple source
import java.util.Iterator;
import org.apache.commons.configuration.CombinedConfiguration;
import org.apache.commons.configuration.ConfigurationException;
import org.apache.commons.configuration.PropertiesConfiguration;
import org.apache.commons.configuration.tree.NodeCombiner;
import org.apache.commons.configuration.tree.OverrideCombiner;
public class CommonsIssue {
public static String propFile1 = "c:\\temp\\A.properties";
public static String propFile2 = "c:\\temp\\B.properties";
public static void main( String[] args ) throws ConfigurationException {
testCombindedConfig();
}
public static void testCombindedConfig() throws ConfigurationException {
NodeCombiner combiner = new OverrideCombiner();
CombinedConfiguration combinedConfig = new
CombinedConfiguration(combiner);
PropertiesConfiguration conf1 = new PropertiesConfiguration();
conf1.setDelimiterParsingDisabled(true);
conf1.setThrowExceptionOnMissing(true);
conf1.load(propFile1);
combinedConfig.addConfiguration(conf1);
PropertiesConfiguration conf2 = new PropertiesConfiguration();
conf2.setDelimiterParsingDisabled(true);
conf2.setThrowExceptionOnMissing(true);
conf2.load(propFile2);
combinedConfig.addConfiguration(conf2);
@SuppressWarnings("unchecked")
Iterator keys = combinedConfig.getKeys();
while (keys.hasNext()) {
String key = keys.next();
System.out.println(key + "=" +
combinedConfig.getString(key));
}
}
}
A.properties
x.y.simpleCase=false
x.y.between=false
x.y.isDistinctFrom=false
x.y=true
B.properties
x.y=true
x.y.between=true
x.y.comparison=true
x.y.in=true
x.y.isDistinctFrom=true
x.y.simpleCase=true
> combining properties which use 3+ part names discards entries as of Commons
> 1.6+
>
>
> Key: CONFIGURATION-604
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-604
> Project: Commons Configuration
> Issue Type: Bug
>Affects Versions: 1.6
>Reporter: N Campbell
>
> When two property files are combined using commons config 1.5, the aggregate
> configuration returns an expected result of 6 entries. If Commons
> configuration 1.6 or higher is used, the resulting set drops to which is not
> expected.
> The property names include 2, 3 or 4 part names X.Y, X.Y.Z etc and it appears
> that as of 1.6 if the names are arranged in 2 part, then 3 part etc that the
> combiner returns the expected result.
> There does not appear to be any release notes etc that would suggest that
> this isn't a defect versus an intended implementation change.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CONFIGURATION-604) combining properties which use 3+ part names discards entries as of Commons 1.6+
N Campbell created CONFIGURATION-604: Summary: combining properties which use 3+ part names discards entries as of Commons 1.6+ Key: CONFIGURATION-604 URL: https://issues.apache.org/jira/browse/CONFIGURATION-604 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.6 Reporter: N Campbell When two property files are combined using commons config 1.5, the aggregate configuration returns an expected result of 6 entries. If Commons configuration 1.6 or higher is used, the resulting set drops to which is not expected. The property names include 2, 3 or 4 part names X.Y, X.Y.Z etc and it appears that as of 1.6 if the names are arranged in 2 part, then 3 part etc that the combiner returns the expected result. There does not appear to be any release notes etc that would suggest that this isn't a defect versus an intended implementation change. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (NET-446) Inconsistent short date handling
[ https://issues.apache.org/jira/browse/NET-446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved NET-446. -- Resolution: Won't Fix No progress > Inconsistent short date handling > > > Key: NET-446 > URL: https://issues.apache.org/jira/browse/NET-446 > Project: Commons Net > Issue Type: Improvement > Components: FTP >Affects Versions: 3.1 >Reporter: Sebb >Priority: Minor > > Most FTP servers seem to use short dates when the file date is within +/- 6 > months of the server clock. > Some may use a different strategy, for example +0 / -12 months. > The code currently (3.2 SNAPSHOT - r1295237) assumes short dates are always > in the past, unless "lenient future date" is selected, in which case a day's > grace is allowed, i.e. +1 day / -364 days. > However, when dealing with Feb 29th, the code does not handle the case where > the server clock is in the following year. > Since most FTP servers use +/- 6 months for short dates, this is not > generally a problem. > Equally, the code does not deal with future dates more than a day in advance, > since that is usally all that is needed for handling different time zones. > (Is it likely that an FTP server has genuine future-dated files?) > See https://issues.apache.org/jira/browse/NET-188#comment-12579253 for a > suggested API to specify short-date ranges. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (NET-508) Add support for FTP proxies
[
https://issues.apache.org/jira/browse/NET-508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb resolved NET-508.
--
Resolution: Won't Fix
> Add support for FTP proxies
> ---
>
> Key: NET-508
> URL: https://issues.apache.org/jira/browse/NET-508
> Project: Commons Net
> Issue Type: Improvement
> Components: FTP
>Affects Versions: 3.2
>Reporter: Arno Unkrig
>
> The COMMONS-NET FTP client supports 'FTP over HTTP', but not the other
> popular FTP proxy schemes. The article
> http://www.codeproject.com/Articles/9547/How-Proxy-Server-serves-FTP-clients
> describes some of them, but not very precisely an obviously a bit incorrect.
> I added proxy support for the ANT FTP task in
>
> https://svn.code.sf.net/p/loggifier/code/trunk/ant_issue_54883/src/org/apache/tools/ant/taskdefs/optional/net2/FTP2.java
> (search for string "proxyServer"), but I believe that the feature should be
> implemented in COMMONS-NET, not in the application, maybe like this:
> {code}
> connectToProxyAndLogin(server, port, userid, password, proxyServer,
> proxyPort, proxyUserid, proxyPassword)
> {code}
> The proxy server that I (must) use is
> {noformat}
> 220 McAfee Web Gateway 7.2.0 build 13935
> {noformat}
> , and from experiments it supports the following authentication schemes:
> {noformat}
> (1) USER pu PASS pp OPEN ftp.acme.com[:port] USER u PASS
> p
> (2) USER pu PASS pp USER u...@ftp.acme.com[:port]
> PASS p
> (3) USER pu PASS pp SITE ftp.acme.com[:port] USER u PASS
> p
> {noformat}
> I don't know which FTP proxy servers support which of these flavors, but (2)
> appears to be the most natural and robust to me.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (NET-550) Default FTPClient bufferSize results in very slow retrieve transfers
[
https://issues.apache.org/jira/browse/NET-550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb resolved NET-550.
--
Resolution: Fixed
Unless there is strong evidence that the default of 1k is inadequate, there
seems to be nothing left to do here.
> Default FTPClient bufferSize results in very slow retrieve transfers
>
>
> Key: NET-550
> URL: https://issues.apache.org/jira/browse/NET-550
> Project: Commons Net
> Issue Type: Bug
>Affects Versions: 3.3
>Reporter: Geoffrey Hardy
> Fix For: 3.4
>
> Attachments: net-buffercopy-ext.patch, net-buffercopy.patch
>
>
> While experimenting with FTPClient, I discovered that if I don't call
> setBufferSize(), the default value is zero. This results in retrieveFile()
> calling the version of InputStream.read() with no parameters, reading one
> byte at a time. For comparison, the downloading a CD ISO image of about
> ~648MB took 18m10s with the default settings. In contrast, calling
> setBufferSize(8192) took only 7.9s, an improvement of ~137x.
> Here is some sample code:
> {code:java}
> FTPClient ftp = new FTPClient();
> // ftp.setBufferSize(8192);
> ftp.setControlKeepAliveTimeout(300);
> ftp.setCopyStreamListener(new CopyStreamListener() {
> @Override
> public void bytesTransferred(long totalBytesTransferred, int
> bytesTransferred, long streamSize) {
> System.out.println("totalBytesTransferred: " + totalBytesTransferred
> + ", bytesTransferred: " + bytesTransferred + ", streamSize: " +
> streamSize);
> }
> @Override public void bytesTransferred(CopyStreamEvent event) {}
> });
> ftp.connect(host);
> ftp.login(user, pass);
> ftp.retrieveFile(file, outputStream);
> {code}
> The log message from the stream listener printed lots messages
> "bytesTransferred: 1" and totalBytesTransferred incremented by 1 each time.
> This corresponds to the part of the code which reads one byte at a time with
> {{int inputStream.read()}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (NET-567) commons-net-3.0.1.jar not listing file from solaris FTP server
[ https://issues.apache.org/jira/browse/NET-567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved NET-567. -- Resolution: Cannot Reproduce Without further details (or a login to the server) there's not a lot we can do. Re-open if you can provide more details. > commons-net-3.0.1.jar not listing file from solaris FTP server > -- > > Key: NET-567 > URL: https://issues.apache.org/jira/browse/NET-567 > Project: Commons Net > Issue Type: Bug > Components: FTP >Affects Versions: 3.0.1 > Environment: Linux server > Solaris(Japanese lang) FTP server >Reporter: Kaif Akbar > Labels: features > Original Estimate: 24h > Remaining Estimate: 24h > > When using commons-net-3.0.1.jar file on Linux server to list the files from > Solaris10(Japanese Language) server then it is not listing files whereas when > using commons-net-2.0.jar to list the files then it is listing. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NET-558) getModificationTime() returns complete received line including response code
[ https://issues.apache.org/jira/browse/NET-558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14613292#comment-14613292 ] Sebb commented on NET-558: -- You can try the current code by using a build from the ASF SNAPSHOT repository. Such builds have not been reviewed so are used at your risk. > getModificationTime() returns complete received line including > response code > -- > > Key: NET-558 > URL: https://issues.apache.org/jira/browse/NET-558 > Project: Commons Net > Issue Type: Bug > Components: FTP >Affects Versions: 3.3 > Environment: The ftp server supports MDTM. >Reporter: Ralph Becker >Priority: Minor > Labels: commons-net, ftp > Fix For: 3.4 > > > When retrieving the last modification time of a file on the server via the > method getModificationTime(String filename) it returns something like > "213 2014112706" where only the part after the space is the relevant data. > I digged deeper and i found that the first part before the space is the > positive > response code which is not removed before getModificationTime returns. > I consider this a minor bug as i think there is a simple work around > (split by space, use second part only) but i do not believe that > the result of the method is what a user expects regarding the documentation > of that method. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NET-577) Fails to parse FEAT response from Microsoft FTP Service
[
https://issues.apache.org/jira/browse/NET-577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14613264#comment-14613264
]
Sebb commented on NET-577:
--
It would of course be possible to allow for multiple leading spaces.
However this is definitely a violation of the RFC, so it seems wrong to do so.
What do other FTP clients do?
> Fails to parse FEAT response from Microsoft FTP Service
> ---
>
> Key: NET-577
> URL: https://issues.apache.org/jira/browse/NET-577
> Project: Commons Net
> Issue Type: Bug
> Components: FTP
>Affects Versions: 3.3
>Reporter: Jochen Kemnade
>
> This is probably rather a bug in the server implementation, but anyway.
> The response from a Microsoft FTP Service I'm trying to work with looks like
> that:
> {noformat}
> 211-FEAT
> SIZE
> MDTM
> 211 END
> {noformat}
> So, after parsing the response, the entries in the features map are {{
> SIZE}} and {{ MDTM}}.
> While it doesn't adhere to the RFC (there's supposed to be a single leading
> space for each feature), it should be possible to work around that kind of
> broken response.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] commons-lang pull request: Changes in Capitalize methods in WordUt...
Github user joehni commented on the pull request: https://github.com/apache/commons-lang/pull/102#issuecomment-118259555 It does! Binary compatibility means, that you can take the new jar file and replace it in an existing project without recompile the sources. This is what Apache Common promises for its components. Therefore is is *not* possible to remove those methods, because existing classes will call the methods with the single argument and will break badly if it is missing. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
