[jira] Created: (COLLECTIONS-363) TransformedMap is Serializable but its superclass doesn't define an accessible void constructor
TransformedMap is Serializable but its superclass doesn't define an accessible
void constructor
---
Key: COLLECTIONS-363
URL: https://issues.apache.org/jira/browse/COLLECTIONS-363
Project: Commons Collections
Issue Type: Bug
Components: Map
Affects Versions: 3.2
Reporter: Sebb
TransformedMap is Serializable but its superclass doesn't define an accessible
void constructor.
For example, the following test fails:
{code}
public void testSerialisation() throws Exception {
TransformedMap map =
TransformedMap.decorate(
new HashMap(), NOPTransformer.
getInstance(), NOPTransformer. getInstance());
ByteArrayOutputStream bytes = new ByteArrayOutputStream();
ObjectOutputStream out = new ObjectOutputStream(bytes);
out.writeObject(map); // fails with java.io.InvalidClassException:
org.apache.commons.collections.splitmap.TransformedMap; no valid constructor
out.close();
}
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COLLECTIONS-327) Serialisable classes without serialVersionUID
[ https://issues.apache.org/jira/browse/COLLECTIONS-327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12921612#action_12921612 ] Sebb commented on COLLECTIONS-327: -- Oops! Ignore the comment re TreeBidiMap. Not sure where I got that from. However, the following additional classes don't declare a serialVersionUID: CompositeCollection CompositeSet EmptyMapMutator EmptySetMutator > Serialisable classes without serialVersionUID > - > > Key: COLLECTIONS-327 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-327 > Project: Commons Collections > Issue Type: Improvement >Affects Versions: 3.2 >Reporter: Sebb >Assignee: Brent Worden > Fix For: 4.0 > > Attachments: collections.pat > > > The following classes are serializable, but don't declare a serialVersionUID: > ExtendedProperties > TreeBidiMap -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (DAEMON-178) jsvc process does not take the umask of the running user. It is always 077
jsvc process does not take the umask of the running user. It is always 077 -- Key: DAEMON-178 URL: https://issues.apache.org/jira/browse/DAEMON-178 Project: Commons Daemon Issue Type: Bug Components: Jsvc Affects Versions: 1.0.3 Environment: Ubuntu Hardy 8.0.4, jdk1.6.2 Reporter: J Miller 1) create a simple implementation of the Daemon interface that writes "hello world" log files 2) compile jsvc as described in the documentation 3) verify that your linux user has umask != 077, by typing "umask" 4) start jsvc with all the required CP args as described in the documentation 5) look the log file permissions Expected: The permissions are not 700. Actual: They are 700. 6) Modify commons-daemon/src/native/unix/native/jsvc-unix.c, replacing 077 with 022 7) recompile jsvc 8) repeat 4-5 Expected: The permissions are 755. Actual: The permissions are 755. Conclusion: The jsvc process uses a hard-coded value, instead of adopting the running user's umask, as expected. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (CONFIGURATION-424) HierachicalINIConfiguration has problems with configurations only containing a global section
HierachicalINIConfiguration has problems with configurations only containing a
global section
-
Key: CONFIGURATION-424
URL: https://issues.apache.org/jira/browse/CONFIGURATION-424
Project: Commons Configuration
Issue Type: Bug
Components: Format
Reporter: André Weihe
Priority: Critical
HierachicalINIConfiguration#getSections() does not correctly deal with
configurations containing only a globalSection() leading for example to a
configuration containing only a global section to be saved as a zero length
file.
The current code only acknowledges a global section when at least one other
named section is present, if none is present it just returns an empty set.
Since HierachicalINIConfiguration#save() saves only the contents of the set
returned by getSections() this leads to an ini file being loaded and saved
again to be saved as a zero length file resulting in the loss of all data in
the file (thus the critical priority).
Workaround:
Create at least one named section
Proposed fix (sourcecode):
Set sections = new ListOrderedSet();
for (Iterator it = getRootNode().getChildren().iterator(); it.hasNext();)
{
ConfigurationNode node = (ConfigurationNode) it.next();
if (isSectionNode(node))
{
sections.add(node.getName());
}
else
{
sections.add(null);
}
}
return sections;
Beware:
I have NOT tested this (at all).
It's just the way I would write this method instead of the way it was written
before. But since I don't know the big picture maybe there was a (good) reason
to write the current version the way it is now so my seemingly easy fix could
not work correctly.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (COLLECTIONS-8) Comparator Predicate
[ https://issues.apache.org/jira/browse/COLLECTIONS-8?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brent Worden resolved COLLECTIONS-8. Resolution: Fixed Fix Version/s: (was: 4.x) 4.0 SVN 1023105. Patch applied with minor changes: added generics and enumeration. > Comparator Predicate > > > Key: COLLECTIONS-8 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-8 > Project: Commons Collections > Issue Type: New Feature > Components: Functor >Affects Versions: 3.1 > Environment: Operating System: other > Platform: Other >Reporter: Rune Peter Bjørnstad >Assignee: Brent Worden >Priority: Minor > Fix For: 4.0 > > Attachments: ComparatorPredicate.diff, ComparatorPredicate.java > > > A predicate that makes use of a Comparator object for evaluation is, in my > opinion, missing in the functors package. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (EMAIL-100) The default connection timeout should be set to a reasonable default value
[
https://issues.apache.org/jira/browse/EMAIL-100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Siegfried Goeschl resolved EMAIL-100.
-
Resolution: Fixed
> The default connection timeout should be set to a reasonable default value
> --
>
> Key: EMAIL-100
> URL: https://issues.apache.org/jira/browse/EMAIL-100
> Project: Commons Email
> Issue Type: Improvement
>Affects Versions: 1.3
>Reporter: David Parks
>Assignee: Siegfried Goeschl
> Fix For: 1.3
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Commons email is a simplifying wrapper around another API. It is also
> expected to be used in server environments.
> By default there are no connection timeouts set, this can (and does) cause
> threads to hang indefinitely. Since the goal of commons email is to simplify
> configuration, there should be a reasonable default value set. The default
> config should not risk a hanging a server.
> This situation was easily produced using the gmail SMTP gateway. When > ~10
> open connections exists the SMTP server starts resetting connections. Once in
> a while this will cause a thread to hang in IO wait indefinitely. The
> solution was to set the timeouts, but it is very easy to overlook the need to
> set this timeout, and natural to expect the wrapper class to handle such
> details.
> The snippets of code below belong in 1.3 Snapshot [as of 8/21/2010]
> org.apache.commons.mail.Email, they set a default of 1 minute timeout for
> connection and IO and update the javadocs.
> Line 109:
>
> /**
> * Socket connection timeout value in milliseconds. Default is 1 minute.
> * @since 1.2
> */
> public static final String MAIL_SMTP_CONNECTIONTIMEOUT =
> "mail.smtp.connectiontimeout";
> /**
> * Socket I/O timeout value in milliseconds. Default is 1 minute.
> * @since 1.2
> */
> public static final String MAIL_SMTP_TIMEOUT = "mail.smtp.timeout";
> Line 240:
>
> /** socket I/O timeout value in milliseconds */
> protected int socketTimeout = 6;
> /** socket connection timeout value in milliseconds */
> protected int socketConnectionTimeout = 6;
> Line 1504:
>
> /**
> * Get the socket connection timeout value in milliseconds.
>* Default is 1 minute.
> *
> * @return the timeout in milliseconds.
> * @since 1.2
> */
> public int getSocketConnectionTimeout()
> {
> return this.socketConnectionTimeout;
> }
> /**
> * Set the socket connection timeout value in milliseconds.
> * Default is 1 minute.
> *
> * @param socketConnectionTimeout the connection timeout
> * @since 1.2
> */
> public void setSocketConnectionTimeout(int socketConnectionTimeout)
> {
> this.socketConnectionTimeout = socketConnectionTimeout;
> }
> /**
> * Get the socket I/O timeout value in milliseconds.
> * Default is 1 minute.
> *
> * @return the socket I/O timeout
> * @since 1.2
> */
> public int getSocketTimeout()
> {
> return this.socketTimeout;
> }
> /**
> * Set the socket I/O timeout value in milliseconds.
> * Default is 1 minute.
> *
> * @param socketTimeout the socket I/O timeout
> * @since 1.2
> */
> public void setSocketTimeout(int socketTimeout)
> {
> this.socketTimeout = socketTimeout;
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COLLECTIONS-344) Delete MapUtils.getXxx
[ https://issues.apache.org/jira/browse/COLLECTIONS-344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12921516#action_12921516 ] Brent Worden commented on COLLECTIONS-344: -- Those methods do a lot of type conversion that are not possible using just generics. Multiple methods are still needed to govern those conversions. Should the methods remain? > Delete MapUtils.getXxx > -- > > Key: COLLECTIONS-344 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-344 > Project: Commons Collections > Issue Type: Task > Components: Map >Reporter: Henri Yandell > Fix For: 4.0 > > > Seems pointless in a generics based world to have getDouble, getMap and their > ilk. Delete em all. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (COLLECTIONS-348) Javadoc: incorrect behavior explained for XXXUtils.transformedXXX
[ https://issues.apache.org/jira/browse/COLLECTIONS-348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brent Worden resolved COLLECTIONS-348. -- Resolution: Fixed all changes have been made. > Javadoc: incorrect behavior explained for XXXUtils.transformedXXX > - > > Key: COLLECTIONS-348 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-348 > Project: Commons Collections > Issue Type: Bug > Components: Bag, Collection, List, Map, Set >Affects Versions: 3.2, 4.0-beta-1 >Reporter: Paul Benedict > Fix For: 4.0 > > > As a sequel to COLLECTIONS-288, any utility method that "transformed" needs > to document that the incoming collection is not immediately transformed -- > future additions are. > Candidate methods: > * BagUtils.transformedBag > * BagUtils.transformedSortedBag > * CollectionUtils.transform > * CollectionUtils.transformedCollection > * ListUtils.transformedList *done* > * MapUtils.transformedMap > * MapUtils.transformedSortedMap > * SetUtils.transformedSet > * SetUtils.transformedSortedSet -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (COLLECTIONS-327) Serialisable classes without serialVersionUID
[ https://issues.apache.org/jira/browse/COLLECTIONS-327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12921510#action_12921510 ] Brent Worden edited comment on COLLECTIONS-327 at 10/15/10 3:31 PM: TreeBidiMap is not serializable. Should it be? was (Author: brentworden): TreeBidiMap is not serializable. Shoud it be? > Serialisable classes without serialVersionUID > - > > Key: COLLECTIONS-327 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-327 > Project: Commons Collections > Issue Type: Improvement >Affects Versions: 3.2 >Reporter: Sebb > Fix For: 4.0 > > Attachments: collections.pat > > > The following classes are serializable, but don't declare a serialVersionUID: > ExtendedProperties > TreeBidiMap -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COLLECTIONS-327) Serialisable classes without serialVersionUID
[ https://issues.apache.org/jira/browse/COLLECTIONS-327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12921510#action_12921510 ] Brent Worden commented on COLLECTIONS-327: -- TreeBidiMap is not serializable. Shoud it be? > Serialisable classes without serialVersionUID > - > > Key: COLLECTIONS-327 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-327 > Project: Commons Collections > Issue Type: Improvement >Affects Versions: 3.2 >Reporter: Sebb > Fix For: 4.0 > > Attachments: collections.pat > > > The following classes are serializable, but don't declare a serialVersionUID: > ExtendedProperties > TreeBidiMap -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (EMAIL-76) Some setters of class Email does not return "this".
[ https://issues.apache.org/jira/browse/EMAIL-76?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Siegfried Goeschl resolved EMAIL-76. Resolution: Fixed > Some setters of class Email does not return "this". > --- > > Key: EMAIL-76 > URL: https://issues.apache.org/jira/browse/EMAIL-76 > Project: Commons Email > Issue Type: Bug >Reporter: Yu Kobayashi >Assignee: Siegfried Goeschl >Priority: Minor > Fix For: 1.3 > > Attachments: EmailSetter.patch, MultiPartEmailSetter.patch > > > Some setters of class Email return "this", and some doesn't. > For the consistency, all the setters should return "this". -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (EMAIL-99) The 1.2 javadocs on the website are out of date
[ https://issues.apache.org/jira/browse/EMAIL-99?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Siegfried Goeschl resolved EMAIL-99. Resolution: Fixed Uploaded the 1.2 aipdocs but it will some time to propagate to the end user. > The 1.2 javadocs on the website are out of date > --- > > Key: EMAIL-99 > URL: https://issues.apache.org/jira/browse/EMAIL-99 > Project: Commons Email > Issue Type: Task >Affects Versions: 1.2 > Environment: The apache commons email website >Reporter: David Parks >Assignee: Siegfried Goeschl >Priority: Trivial > Original Estimate: 2h > Remaining Estimate: 2h > > The javadocs for version 1.2 are out of date. In particular it's been noticed > that the following two functions are not included in the javadoc from the > apache commons email website, but they exist as public methods in the 1.2 > download release & downloaded javadocs. > Email.setSocketConnectionTimeout(int); > Email.setSocketTimeout(int); > The website just needs to be updated by someone with access. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (NET-332) Commons net ftp cannot handle unknown type parser and should allow override of parser through vm argument
[ https://issues.apache.org/jira/browse/NET-332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated NET-332: - Issue Type: New Feature (was: Bug) > Commons net ftp cannot handle unknown type parser and should allow override > of parser through vm argument > - > > Key: NET-332 > URL: https://issues.apache.org/jira/browse/NET-332 > Project: Commons Net > Issue Type: New Feature > Components: FTP >Affects Versions: 2.0 > Environment: All >Reporter: David R > > When parser is of unknown type, commons ftp throws an exception and does not > enable you to use the ftp even though every other ftp client is able to do > handle this. My suggestion is to allow the default factory to be overriden > through a VM parameter so that i can use a different parser even in ant. For > non ant, the solution is easy as i outline here: > http://groovyjavathoughts.blogspot.com/2009/06/ftpclient-advantage-of-open-source-code.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (NET-334) org.apache.commons.net.io.FromNetASCIIInputStream can throw a NullPointerException
[
https://issues.apache.org/jira/browse/NET-334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb resolved NET-334.
--
Resolution: Fixed
Fix Version/s: 2.2
Could possibly drop the method entirely instead. Meanwhile fix the NPE.
> org.apache.commons.net.io.FromNetASCIIInputStream can throw a
> NullPointerException
> --
>
> Key: NET-334
> URL: https://issues.apache.org/jira/browse/NET-334
> Project: Commons Net
> Issue Type: Bug
>Affects Versions: 2.0
> Environment: OS: Linux -- Redhat enterprise
> JVM 1.6 64bit
>Reporter: Kenneth Ritch
> Fix For: 2.2
>
>
> org.apache.commons.net.io.FromNetASCIIInputStream.available() can throw a
> NullPointerException if the
> InputStream is null. This has been experienced on a loaded system.
> StackTrace:
> Exception in thread "Telnet Reader" java.lang.NullPointerException
> at
> org.apache.commons.net.io.FromNetASCIIInputStream.available(FromNetASCIIInputStream.java:202)
>
> at
> org.apache.commons.net.io.FromNetASCIIInputStream.read(FromNetASCIIInputStream.java:164)
>
> at java.io.BufferedInputStream.fill(Unknown Source)
> at java.io.BufferedInputStream.read(Unknown Source)
> at
> org.apache.commons.net.telnet.TelnetInputStream.__read(TelnetInputStream.java:122)
>
> at
> org.apache.commons.net.telnet.TelnetInputStream.read(TelnetInputStream.java:375)
>
> at
> org.apache.commons.net.telnet.TelnetInputStream.read(TelnetInputStream.java:492)
>
> at java.io.BufferedInputStream.fill(Unknown Source)
> at java.io.BufferedInputStream.read1(Unknown Source)
> at java.io.BufferedInputStream.read(Unknown Source)
> at java.io.FilterInputStream.read(Unknown Source)
> Cause:
> The base PushbackInputStream checks the input stream is not closed before
> invoking avilable()
> 274 public int available() throws IOException {
> 275 ensureOpen();
> 276 return (buf.length - pos) + super.available();
> 277 }
> Which throws appropriate IOException if input stream is null:
> 72private void ensureOpen() throws IOException {
> 73if (in == null)
> 74throw new IOException("Stream closed");
> 75}
> commons.net.io.FromNetASCIIInputStream does not. This can lead to a
> NullPointerException being thrown if the input stream is null.
> 191// PushbackInputStream in JDK 1.1.3 returns the wrong thing
> 192/***
> 193 * Returns the number of bytes that can be read without blocking
> EXCEPT
> 194 * when newline conversions have to be made somewhere within the
> 195 * available block of bytes. In other words, you really should not
> 196 * rely on the value returned by this method if you are trying to
> avoid
> 197 * blocking.
> 198 ***/
> 199@Override
> 200public int available() throws IOException
> 201{
> 202return (buf.length - pos) + in.available();
> 203}
> FromNetASCIIInputStream.available() should be changed to mimic the base class
> behaviour.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (NET-335) TelnetOutputStream incorrectly doubles-up IAC when sending IAC+EOR in BINARY transmission mode
[
https://issues.apache.org/jira/browse/NET-335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12921309#action_12921309
]
Sebb commented on NET-335:
--
The problem with option 1 is that this breaks compatibility for existing users,
who expect IAC characters to be doubled.
Indeed if your data includes IAC not followed by EOR, it would not be sent
correctly.
Note that a work-round is to use the protected _output_ field from
SocketClient, which is not subject to any filtering.
> TelnetOutputStream incorrectly doubles-up IAC when sending IAC+EOR in BINARY
> transmission mode
> --
>
> Key: NET-335
> URL: https://issues.apache.org/jira/browse/NET-335
> Project: Commons Net
> Issue Type: Bug
> Components: Telnet
>Affects Versions: 1.4, 2.0
> Environment: Windows XP SP3, Java 1.6.0_21
>Reporter: Chris Jones
>
> This is related to NET-180 which I reported a couple of years back, and is
> reported fixed in 2.1. I've since re-visited the code, and found another issue
> background
>
> I have a TN5250 client (see rfc1205) which extends TelnetClient. Basically,
> the client negotiates BINARY transmission and operates in block-mode. The
> client sends IAC+EOR to notify the host that the data is complete, but the
> TelnetOutputStream doubles-up the IAC automatically as if it was a data byte,
> which iis not the case, resulting in IAC+IAC+EOR.
> Two possible solutions come to mind:
> 1. Do not double-up IAC when in BINARY transmission in TelnetOutputStream
> (i.e. leave it to the client)
> 2. Add a method to TelnetClient like -- sendCommand(byte b) {} which
> would act similar to sendAYT, only allowing the client to specify the value.
> On balance, I like the second option, as it would give more future
> possibilities.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (NET-273) FEAT response parsing
[ https://issues.apache.org/jira/browse/NET-273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated NET-273: - Affects Version/s: (was: 2.1) 2.0 > FEAT response parsing > - > > Key: NET-273 > URL: https://issues.apache.org/jira/browse/NET-273 > Project: Commons Net > Issue Type: Improvement > Components: FTP >Affects Versions: 2.0 >Reporter: Shikhar Bhushan >Priority: Minor > > Would be nice if response to FEAT could be parsed, and a simple method > provided like client.isSupported(FTPCommand.MDTM) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (NET-340) FTPClient.getModificationTime(String path) throws an ArrayOutOfBoundsException
[ https://issues.apache.org/jira/browse/NET-340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved NET-340. -- Resolution: Duplicate Fix Version/s: 2.2 > FTPClient.getModificationTime(String path) throws an ArrayOutOfBoundsException > -- > > Key: NET-340 > URL: https://issues.apache.org/jira/browse/NET-340 > Project: Commons Net > Issue Type: Bug > Components: FTP >Affects Versions: 2.0 > Environment: all >Reporter: alan atkinson > Fix For: 2.2 > > > FTPClient eventually ends up calling sendCommand(int command, String args) > with MOD_TIME (=33) and the path to the file. > FTPCommands._commands is missing the "MDMT" string in the array, causing the > out of bounds exception. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (NET-339) Incorrect parsing of timestamp on Windows CE
[ https://issues.apache.org/jira/browse/NET-339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved NET-339. -- Resolution: Fixed Fix Version/s: 2.2 > Incorrect parsing of timestamp on Windows CE > > > Key: NET-339 > URL: https://issues.apache.org/jira/browse/NET-339 > Project: Commons Net > Issue Type: Bug > Components: FTP >Affects Versions: 2.0 > Environment: Windows >Reporter: Bram >Priority: Minor > Fix For: 2.2 > > Attachments: NET-339_v2.patch > > > Somewhere in the past the timestamp format returned by windows/the windows > ftp server changed. > In the past the timestamp had a format like: '09-21-10 06:00PM'. > The 'current' format however is: '09-21-10 18:00'. > In version 1.4 this resulted in no files being displayed because parsing the > timestamp fails; > In version 2 this results in the files being displayed but without the > timestamp. > (This is the result of change 645299) > The attached patch updates the code so that it detects both the old and the > new format of the timestamp. > A bug that also mentions this, or at least the comments, > https://issues.apache.org/jira/browse/NET-50 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (NET-339) Incorrect parsing of timestamp on Windows CE
[ https://issues.apache.org/jira/browse/NET-339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated NET-339: - Summary: Incorrect parsing of timestamp on Windows CE (was: Incorrect parsing of timestamp on windows) > Incorrect parsing of timestamp on Windows CE > > > Key: NET-339 > URL: https://issues.apache.org/jira/browse/NET-339 > Project: Commons Net > Issue Type: Bug > Components: FTP >Affects Versions: 2.0 > Environment: Windows >Reporter: Bram >Priority: Minor > Attachments: NET-339_v2.patch > > > Somewhere in the past the timestamp format returned by windows/the windows > ftp server changed. > In the past the timestamp had a format like: '09-21-10 06:00PM'. > The 'current' format however is: '09-21-10 18:00'. > In version 1.4 this resulted in no files being displayed because parsing the > timestamp fails; > In version 2 this results in the files being displayed but without the > timestamp. > (This is the result of change 645299) > The attached patch updates the code so that it detects both the old and the > new format of the timestamp. > A bug that also mentions this, or at least the comments, > https://issues.apache.org/jira/browse/NET-50 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (NET-316) listFiles() returns empty for "Windows NT" systems
[ https://issues.apache.org/jira/browse/NET-316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated NET-316: - Affects Version/s: (was: 2.1) > listFiles() returns empty for "Windows NT" systems > -- > > Key: NET-316 > URL: https://issues.apache.org/jira/browse/NET-316 > Project: Commons Net > Issue Type: Bug >Affects Versions: 1.4, 2.0 >Reporter: Andy Brook > > Try as I might, I can't provoke a directory listing from a system reporting > as "Windows NT". The root of the server has no files, just directories, but > the problem is the directories are not being included in *.listFiles()* > Is Windows NT unsupported? Any workarounds I can use to extract directory > listings? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (NET-337) Support for Extended Passive Mode
[
https://issues.apache.org/jira/browse/NET-337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb updated NET-337:
-
Affects Version/s: (was: 2.1)
2.0
> Support for Extended Passive Mode
> --
>
> Key: NET-337
> URL: https://issues.apache.org/jira/browse/NET-337
> Project: Commons Net
> Issue Type: New Feature
> Components: FTP
>Affects Versions: 2.0
> Environment: all
>Reporter: Carlos Silva A.
>
> Extended Passive Mode (ESPV) is not supported yet in the current library.
> Adding support for it will enable this library to use it to connect ot
> servers behind routers that are incorrectly configured to use PASV.
> I dont know if I should try to place a patch as I am on doubt on what the
> right approach should be:
> a) Create a new EXTENDED_PASSIVE_LOCAL_DATA_CONNECTION_MODE connection mode
> This would probably fulfill the actual requirement, but would also
> require multiple changes across to support the EPSV command and its result as
> well.
> b) create a public property "ignorePassiveHost" that can be used in
> FTPClient# __parsePassiveModeReply() as follows
> if(__ignorePassiveHost){
> __passiveHost = getRemoteAddress().getHostAddress();
> }else{
> __passiveHost = parts[0] + '.' + parts[1] + '.' + parts[2] +
> '.' + parts[3];
> }
>
> c) externalize (as a protected method) the call to create socket in
> FTPClient#_openDataConnection_ to a protected method "createSocket)
> This would allow user code to override the default connection
> behavior to accomplish a similar functionality.
> d) make __parsePassiveModeReply a protected method and also add a protected
> method for setting the value on __passiveHost
> This would allow user code to override the default behavior to
> accomplish a similar functionality.
> Thanks for any comments / work on this.
> I can submit a patch on any of these options if you need me to.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (NET-294) UnixFTPEntryParser fails to parse some entries
[
https://issues.apache.org/jira/browse/NET-294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb updated NET-294:
-
Fix Version/s: (was: 2.1)
2.2
> UnixFTPEntryParser fails to parse some entries
> --
>
> Key: NET-294
> URL: https://issues.apache.org/jira/browse/NET-294
> Project: Commons Net
> Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Gilles Duboscq
> Fix For: 1.5, 2.2
>
> Attachments: UnixFTPEntryParser.java.patch
>
>
> The regex does match the entry but the resulting groups are wrong for
> exemple, with
> {code}
> -rwxrwx--- 1 ftp ftp-admin 816026400 Oct 5 2008 bloplab 7 cd1.img
> {code}
> the unix group name group will match "ftp-admin 816026400 Oct" file size
> group will match "5" first date group will match "2008 bloplab" then the year
> group will match "7" and the file name group will match "cd1.img"
> in this listing :
> {code}
> -rwxrwx--- 1 ftp ftp-admin 771 Oct 5 2008 bloplab 7 cd1.ccd
> -rwxrwx--- 1 ftp ftp-admin 76 Oct 5 2008 bloplab 7 cd1.cue
> -rwxrwx--- 1 ftp ftp-admin 816026400 Oct 5 2008 bloplab 7 cd1.img
> -rwxrwx--- 1 ftp ftp-admin 33307200 Oct 5 2008 bloplab 7 cd1.sub
> -rwxrwx--- 1 ftp ftp-admin 772 Oct 5 2008 bloplab 7 cd2.ccd
> -rwxrwx--- 1 ftp ftp-admin 76 Oct 5 2008 bloplab 7 cd2.cue
> -rwxrwx--- 1 ftp ftp-admin 413902608 Oct 5 2008 bloplab 7 cd2.img
> -rwxrwx--- 1 ftp ftp-admin 16893984 Oct 5 2008 bloplab 7 cd2.sub
> {code}
> the 4 entries in which groupname and file size are only separated by one
> space wont be parsed properly, the others work
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (NET-341) FTPClient.remoteAppend(String filename) uses STOR instead of APPE
[ https://issues.apache.org/jira/browse/NET-341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved NET-341. -- Resolution: Fixed Fix Version/s: 2.2 Fix will be in 2.2 > FTPClient.remoteAppend(String filename) uses STOR instead of APPE > - > > Key: NET-341 > URL: https://issues.apache.org/jira/browse/NET-341 > Project: Commons Net > Issue Type: Bug > Components: FTP >Affects Versions: 2.0 >Reporter: Sebb > Fix For: 2.2 > > > From user-list report: > http://mail-archives.apache.org/mod_mbox/commons-user/201010.mbox/%3c618a4792-6400-4ee8-8452-1391067c6...@neccn-cas02.nec.com.cn%3e > The FTPClient.remoteAppend(String filename) method uses STOR instead of APPE -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (NET-341) FTPClient.remoteAppend(String filename) uses STOR instead of APPE
FTPClient.remoteAppend(String filename) uses STOR instead of APPE - Key: NET-341 URL: https://issues.apache.org/jira/browse/NET-341 Project: Commons Net Issue Type: Bug Components: FTP Affects Versions: 2.0 Reporter: Sebb >From user-list report: http://mail-archives.apache.org/mod_mbox/commons-user/201010.mbox/%3c618a4792-6400-4ee8-8452-1391067c6...@neccn-cas02.nec.com.cn%3e The FTPClient.remoteAppend(String filename) method uses STOR instead of APPE -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DIGESTER-131) [PATCH] commons-digester / Allow recursive match in ExtendedBaseRules.java (see patch)
[ https://issues.apache.org/jira/browse/DIGESTER-131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12921280#action_12921280 ] Simone Tripodi commented on DIGESTER-131: - Hi Volker, apologizes but I wasn't able to manage that issue before :( Looking forward to publish 2.2 ASAP including the submitted patch, It would be nicer if you can provide in the patch also a TestCase that shows the benefit of the submitted code. Sorry but I'm not familiar with XML config, can you post here in the comments a sample that shows which is now allowed that was not admitted before? Many thanks in advance and apologizes once again, Simo > [PATCH] commons-digester / Allow recursive match in ExtendedBaseRules.java > (see patch) > -- > > Key: DIGESTER-131 > URL: https://issues.apache.org/jira/browse/DIGESTER-131 > Project: Commons Digester > Issue Type: Improvement > Environment: all >Reporter: Volker Karlmeier > Fix For: 1.8.2, 2.2 > > Attachments: ExtendedBaseRules.patch > > Original Estimate: 0.17h > Remaining Estimate: 0.17h > > Recursive tags in XML-rules-file only work on root node. Nested nodes like > the one below to not work. > With the attached patch, it is possible to specify rules like > <...> > <...> > > classname="de.wsy.f4ja.alertbatches.configuration.alerting.alertingconfig.Properties" > /> > > > > > > > classname="de.wsy.f4ja.alertbatches.configuration.alerting.alertingconfig.Property" > /> > > > > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
