You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by steve cohen <sc...@javactivity.org> on 2004/01/10 17:20:42 UTC
[net] Solved VMS duplicates problem and simplified system
I have made a rather large checkin to fully solve the VMS problem. (Actually,
there is one more detail, but it is minor, see below).
These changes were as follows:
1. Subclass VMSFTPEntryParser with VMSVersioningFTPEntryParser.
This subclass handles the duplicate removal at what I believe is the right
time: After the initial list is read in, but within the process of
FTPFileList creation, that is before FTPFileList.create() returns. No client
of the list sees the removed dupes.
2. In order to implement one, a removeDuplicates() method was added to
FTPFileEntryParser. This is a no-op in the normal case but implemented in
VMSVersioningFTPEntryParser.
3. You'll note I said FTPFileList.create() in #1. I reverted to this and
removed FTPFileEntryParser.createFTPFileList() that Daniel had added. He was
uncomfortable with the name of this method, and it was no longer necessary
with the above changes. I also removed DefaultFTPFileList and
DefaultFTPFileIterator. Since these are large changes and potentially step
on Daniel's toes, I created a tag NET_1_2_0_TEMP so we can revert if anyone
strenuously objects.
4. I renamed FTPFileListParserImpl to FTPFileEntryParserImpl to reduce the
confusion level since FTPFileListParser is now deprecated and going away in
2.0. For the time being, though, for backward compatibility it still
implements FTPFileListParser.
This has been a painful exercise, so I want to give my thinking.
Probably FTPFileList and FTPFileListIterator are misnamed. FTPFileList
IS-NOT-A List of FTPFiles. It HAS a Vector of raw input lines from the
listing. FTPFileListIterator IS-NOT-A simple iterator over FTPFileList. It
DOES iterate over this Vector and DOES return FTPFile objects, so it is more
than a simple iterator, it is an iterator on steroids.
Remember that there are two scenarios supported here:
a) read the whole list at once as in FTPClient.listFiles() and
b) read the list in but defer creation of more expensive FTPFile objects until
needed. This scenario was broken in the VMS case.
The nice thing about this fix is that both scenarios are supported, and
complications are much reduced.
The one thing left to do is decide which VMS scenario, versioning or
non-versioning is the default, i.e. the one to be supported by autodetection.
I asked for someone to chime in on this last week and no one has. I still
don't know.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [net] Solved VMS duplicates problem and simplified system
Posted by steve cohen <sc...@javactivity.org>.
Fixed.
On Monday 12 January 2004 09:30 am, steve cohen wrote:
> Sorry. My fault. Daniel reminded me I could not get rid of this class and
> I forgot to see that it compiled. Fix coming soon.
>
> On Monday 12 January 2004 07:31 am, Jeffrey D. Brekke wrote:
> > I'm still trying to keep up with the code changes and discussion, but
> > currently I'm getting a compile failure:
> >
> > ----
> >
> > java:compile:
> > [echo] Compiling to
> > /usr/local/jbrekke/sandbox/other/commons-net/target/classes [javac]
> > Compiling 70 source files to
> > /usr/local/jbrekke/sandbox/other/commons-net/target/classes
> > /usr/local/jbrekke/sandbox/other/commons-net/src/java/org/apache/commons/
> >ne t/ftp/FTPFileListParserImpl.java:152: cannot resolve symbol symbol :
> > class DefaultFTPFileList
> > location: class org.apache.commons.net.ftp.FTPFileListParserImpl
> > DefaultFTPFileList list = new DefaultFTPFileList(this);
> > ^
> > /usr/local/jbrekke/sandbox/other/commons-net/src/java/org/apache/commons/
> >ne t/ftp/FTPFileListParserImpl.java:152: cannot resolve symbol symbol :
> > class DefaultFTPFileList
> > location: class org.apache.commons.net.ftp.FTPFileListParserImpl
> > DefaultFTPFileList list = new DefaultFTPFileList(this);
> > ^
> > 2 errors
> >
> > BUILD FAILED
> > File...... file:/home/jbrekke/.maven/plugins/maven-java-plugin-1.3/
> > Element... ant:javac
> > Line...... 34
> > Column.... 48
> > Compile failed; see the compiler error output for details.
> > Total time: 13 seconds
> > Finished at: Mon Jan 12 07:47:30 CST 2004
> >
> > ----
> >
> > Are all your changes committed?
> >
> > >>>>> On Sat, 10 Jan 2004 10:20:42 -0600, steve cohen
> > >>>>> <sc...@javactivity.org> said:
> > >
> > > I have made a rather large checkin to fully solve the VMS problem.
> > > (Actually, there is one more detail, but it is minor, see below).
> > >
> > > These changes were as follows:
> > >
> > > 1. Subclass VMSFTPEntryParser with VMSVersioningFTPEntryParser.
> > > This subclass handles the duplicate removal at what I believe is the
> > > right time: After the initial list is read in, but within the
> > > process of FTPFileList creation, that is before FTPFileList.create()
> > > returns. No client of the list sees the removed dupes.
> > >
> > > 2. In order to implement one, a removeDuplicates() method was added
> > > to FTPFileEntryParser. This is a no-op in the normal case but
> > > implemented in VMSVersioningFTPEntryParser.
> > >
> > > 3. You'll note I said FTPFileList.create() in #1. I reverted to
> > > this and removed FTPFileEntryParser.createFTPFileList() that Daniel
> > > had added. He was uncomfortable with the name of this method, and
> > > it was no longer necessary with the above changes. I also removed
> > > DefaultFTPFileList and DefaultFTPFileIterator. Since these are
> > > large changes and potentially step on Daniel's toes, I created a tag
> > > NET_1_2_0_TEMP so we can revert if anyone strenuously objects.
> > >
> > > 4. I renamed FTPFileListParserImpl to FTPFileEntryParserImpl to
> > > reduce the confusion level since FTPFileListParser is now deprecated
> > > and going away in 2.0. For the time being, though, for backward
> > > compatibility it still implements FTPFileListParser.
> > >
> > > This has been a painful exercise, so I want to give my thinking.
> > > Probably FTPFileList and FTPFileListIterator are misnamed.
> > > FTPFileList IS-NOT-A List of FTPFiles. It HAS a Vector of raw input
> > > lines from the listing. FTPFileListIterator IS-NOT-A simple
> > > iterator over FTPFileList. It DOES iterate over this Vector and
> > > DOES return FTPFile objects, so it is more than a simple iterator,
> > > it is an iterator on steroids.
> > >
> > > Remember that there are two scenarios supported here: a) read the
> > > whole list at once as in FTPClient.listFiles() and b) read the list
> > > in but defer creation of more expensive FTPFile objects until
> > > needed. This scenario was broken in the VMS case.
> > >
> > >
> > > The nice thing about this fix is that both scenarios are supported,
> > > and complications are much reduced.
> > >
> > > The one thing left to do is decide which VMS scenario, versioning or
> > > non-versioning is the default, i.e. the one to be supported by
> > > autodetection. I asked for someone to chime in on this last week
> > > and no one has. I still don't know.
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [net] Solved VMS duplicates problem and simplified system
Posted by steve cohen <sc...@javactivity.org>.
Sorry. My fault. Daniel reminded me I could not get rid of this class and I
forgot to see that it compiled. Fix coming soon.
On Monday 12 January 2004 07:31 am, Jeffrey D. Brekke wrote:
> I'm still trying to keep up with the code changes and discussion, but
> currently I'm getting a compile failure:
>
> ----
>
> java:compile:
> [echo] Compiling to
> /usr/local/jbrekke/sandbox/other/commons-net/target/classes [javac]
> Compiling 70 source files to
> /usr/local/jbrekke/sandbox/other/commons-net/target/classes
> /usr/local/jbrekke/sandbox/other/commons-net/src/java/org/apache/commons/ne
>t/ftp/FTPFileListParserImpl.java:152: cannot resolve symbol symbol : class
> DefaultFTPFileList
> location: class org.apache.commons.net.ftp.FTPFileListParserImpl
> DefaultFTPFileList list = new DefaultFTPFileList(this);
> ^
> /usr/local/jbrekke/sandbox/other/commons-net/src/java/org/apache/commons/ne
>t/ftp/FTPFileListParserImpl.java:152: cannot resolve symbol symbol : class
> DefaultFTPFileList
> location: class org.apache.commons.net.ftp.FTPFileListParserImpl
> DefaultFTPFileList list = new DefaultFTPFileList(this);
> ^
> 2 errors
>
> BUILD FAILED
> File...... file:/home/jbrekke/.maven/plugins/maven-java-plugin-1.3/
> Element... ant:javac
> Line...... 34
> Column.... 48
> Compile failed; see the compiler error output for details.
> Total time: 13 seconds
> Finished at: Mon Jan 12 07:47:30 CST 2004
>
> ----
>
> Are all your changes committed?
>
> >>>>> On Sat, 10 Jan 2004 10:20:42 -0600, steve cohen
> >>>>> <sc...@javactivity.org> said:
> >
> > I have made a rather large checkin to fully solve the VMS problem.
> > (Actually, there is one more detail, but it is minor, see below).
> >
> > These changes were as follows:
> >
> > 1. Subclass VMSFTPEntryParser with VMSVersioningFTPEntryParser.
> > This subclass handles the duplicate removal at what I believe is the
> > right time: After the initial list is read in, but within the
> > process of FTPFileList creation, that is before FTPFileList.create()
> > returns. No client of the list sees the removed dupes.
> >
> > 2. In order to implement one, a removeDuplicates() method was added
> > to FTPFileEntryParser. This is a no-op in the normal case but
> > implemented in VMSVersioningFTPEntryParser.
> >
> > 3. You'll note I said FTPFileList.create() in #1. I reverted to
> > this and removed FTPFileEntryParser.createFTPFileList() that Daniel
> > had added. He was uncomfortable with the name of this method, and
> > it was no longer necessary with the above changes. I also removed
> > DefaultFTPFileList and DefaultFTPFileIterator. Since these are
> > large changes and potentially step on Daniel's toes, I created a tag
> > NET_1_2_0_TEMP so we can revert if anyone strenuously objects.
> >
> > 4. I renamed FTPFileListParserImpl to FTPFileEntryParserImpl to
> > reduce the confusion level since FTPFileListParser is now deprecated
> > and going away in 2.0. For the time being, though, for backward
> > compatibility it still implements FTPFileListParser.
> >
> > This has been a painful exercise, so I want to give my thinking.
> > Probably FTPFileList and FTPFileListIterator are misnamed.
> > FTPFileList IS-NOT-A List of FTPFiles. It HAS a Vector of raw input
> > lines from the listing. FTPFileListIterator IS-NOT-A simple
> > iterator over FTPFileList. It DOES iterate over this Vector and
> > DOES return FTPFile objects, so it is more than a simple iterator,
> > it is an iterator on steroids.
> >
> > Remember that there are two scenarios supported here: a) read the
> > whole list at once as in FTPClient.listFiles() and b) read the list
> > in but defer creation of more expensive FTPFile objects until
> > needed. This scenario was broken in the VMS case.
> >
> >
> > The nice thing about this fix is that both scenarios are supported,
> > and complications are much reduced.
> >
> > The one thing left to do is decide which VMS scenario, versioning or
> > non-versioning is the default, i.e. the one to be supported by
> > autodetection. I asked for someone to chime in on this last week
> > and no one has. I still don't know.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [net] Solved VMS duplicates problem and simplified system
Posted by steve cohen <sc...@javactivity.org>.
On Monday 12 January 2004 07:31 am, Jeffrey D. Brekke wrote:
> I'm still trying to keep up with the code changes and discussion, but
> currently I'm getting a compile failure:
>
> ----
>
> java:compile:
> [echo] Compiling to
> /usr/local/jbrekke/sandbox/other/commons-net/target/classes [javac]
> Compiling 70 source files to
> /usr/local/jbrekke/sandbox/other/commons-net/target/classes
> /usr/local/jbrekke/sandbox/other/commons-net/src/java/org/apache/commons/ne
>t/ftp/FTPFileListParserImpl.java:152: cannot resolve symbol symbol : class
> DefaultFTPFileList
> location: class org.apache.commons.net.ftp.FTPFileListParserImpl
> DefaultFTPFileList list = new DefaultFTPFileList(this);
> ^
> /usr/local/jbrekke/sandbox/other/commons-net/src/java/org/apache/commons/ne
>t/ftp/FTPFileListParserImpl.java:152: cannot resolve symbol symbol : class
> DefaultFTPFileList
> location: class org.apache.commons.net.ftp.FTPFileListParserImpl
> DefaultFTPFileList list = new DefaultFTPFileList(this);
> ^
> 2 errors
>
> BUILD FAILED
> File...... file:/home/jbrekke/.maven/plugins/maven-java-plugin-1.3/
> Element... ant:javac
> Line...... 34
> Column.... 48
> Compile failed; see the compiler error output for details.
> Total time: 13 seconds
> Finished at: Mon Jan 12 07:47:30 CST 2004
>
> ----
>
> Are all your changes committed?
>
> >>>>> On Sat, 10 Jan 2004 10:20:42 -0600, steve cohen
> >>>>> <sc...@javactivity.org> said:
> >
> > I have made a rather large checkin to fully solve the VMS problem.
> > (Actually, there is one more detail, but it is minor, see below).
> >
> > These changes were as follows:
> >
> > 1. Subclass VMSFTPEntryParser with VMSVersioningFTPEntryParser.
> > This subclass handles the duplicate removal at what I believe is the
> > right time: After the initial list is read in, but within the
> > process of FTPFileList creation, that is before FTPFileList.create()
> > returns. No client of the list sees the removed dupes.
> >
> > 2. In order to implement one, a removeDuplicates() method was added
> > to FTPFileEntryParser. This is a no-op in the normal case but
> > implemented in VMSVersioningFTPEntryParser.
> >
> > 3. You'll note I said FTPFileList.create() in #1. I reverted to
> > this and removed FTPFileEntryParser.createFTPFileList() that Daniel
> > had added. He was uncomfortable with the name of this method, and
> > it was no longer necessary with the above changes. I also removed
> > DefaultFTPFileList and DefaultFTPFileIterator. Since these are
> > large changes and potentially step on Daniel's toes, I created a tag
> > NET_1_2_0_TEMP so we can revert if anyone strenuously objects.
> >
> > 4. I renamed FTPFileListParserImpl to FTPFileEntryParserImpl to
> > reduce the confusion level since FTPFileListParser is now deprecated
> > and going away in 2.0. For the time being, though, for backward
> > compatibility it still implements FTPFileListParser.
> >
> > This has been a painful exercise, so I want to give my thinking.
> > Probably FTPFileList and FTPFileListIterator are misnamed.
> > FTPFileList IS-NOT-A List of FTPFiles. It HAS a Vector of raw input
> > lines from the listing. FTPFileListIterator IS-NOT-A simple
> > iterator over FTPFileList. It DOES iterate over this Vector and
> > DOES return FTPFile objects, so it is more than a simple iterator,
> > it is an iterator on steroids.
> >
> > Remember that there are two scenarios supported here: a) read the
> > whole list at once as in FTPClient.listFiles() and b) read the list
> > in but defer creation of more expensive FTPFile objects until
> > needed. This scenario was broken in the VMS case.
> >
> >
> > The nice thing about this fix is that both scenarios are supported,
> > and complications are much reduced.
> >
> > The one thing left to do is decide which VMS scenario, versioning or
> > non-versioning is the default, i.e. the one to be supported by
> > autodetection. I asked for someone to chime in on this last week
> > and no one has. I still don't know.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [net] Solved VMS duplicates problem and simplified system
Posted by "Jeffrey D. Brekke" <jb...@wi.rr.com>.
I'm still trying to keep up with the code changes and discussion, but
currently I'm getting a compile failure:
----
java:compile:
[echo] Compiling to /usr/local/jbrekke/sandbox/other/commons-net/target/classes
[javac] Compiling 70 source files to /usr/local/jbrekke/sandbox/other/commons-net/target/classes
/usr/local/jbrekke/sandbox/other/commons-net/src/java/org/apache/commons/net/ftp/FTPFileListParserImpl.java:152: cannot resolve symbol
symbol : class DefaultFTPFileList
location: class org.apache.commons.net.ftp.FTPFileListParserImpl
DefaultFTPFileList list = new DefaultFTPFileList(this);
^
/usr/local/jbrekke/sandbox/other/commons-net/src/java/org/apache/commons/net/ftp/FTPFileListParserImpl.java:152: cannot resolve symbol
symbol : class DefaultFTPFileList
location: class org.apache.commons.net.ftp.FTPFileListParserImpl
DefaultFTPFileList list = new DefaultFTPFileList(this);
^
2 errors
BUILD FAILED
File...... file:/home/jbrekke/.maven/plugins/maven-java-plugin-1.3/
Element... ant:javac
Line...... 34
Column.... 48
Compile failed; see the compiler error output for details.
Total time: 13 seconds
Finished at: Mon Jan 12 07:47:30 CST 2004
----
Are all your changes committed?
>>>>> On Sat, 10 Jan 2004 10:20:42 -0600, steve cohen <sc...@javactivity.org> said:
> I have made a rather large checkin to fully solve the VMS problem.
> (Actually, there is one more detail, but it is minor, see below).
> These changes were as follows:
> 1. Subclass VMSFTPEntryParser with VMSVersioningFTPEntryParser.
> This subclass handles the duplicate removal at what I believe is the
> right time: After the initial list is read in, but within the
> process of FTPFileList creation, that is before FTPFileList.create()
> returns. No client of the list sees the removed dupes.
> 2. In order to implement one, a removeDuplicates() method was added
> to FTPFileEntryParser. This is a no-op in the normal case but
> implemented in VMSVersioningFTPEntryParser.
> 3. You'll note I said FTPFileList.create() in #1. I reverted to
> this and removed FTPFileEntryParser.createFTPFileList() that Daniel
> had added. He was uncomfortable with the name of this method, and
> it was no longer necessary with the above changes. I also removed
> DefaultFTPFileList and DefaultFTPFileIterator. Since these are
> large changes and potentially step on Daniel's toes, I created a tag
> NET_1_2_0_TEMP so we can revert if anyone strenuously objects.
> 4. I renamed FTPFileListParserImpl to FTPFileEntryParserImpl to
> reduce the confusion level since FTPFileListParser is now deprecated
> and going away in 2.0. For the time being, though, for backward
> compatibility it still implements FTPFileListParser.
> This has been a painful exercise, so I want to give my thinking.
> Probably FTPFileList and FTPFileListIterator are misnamed.
> FTPFileList IS-NOT-A List of FTPFiles. It HAS a Vector of raw input
> lines from the listing. FTPFileListIterator IS-NOT-A simple
> iterator over FTPFileList. It DOES iterate over this Vector and
> DOES return FTPFile objects, so it is more than a simple iterator,
> it is an iterator on steroids.
> Remember that there are two scenarios supported here: a) read the
> whole list at once as in FTPClient.listFiles() and b) read the list
> in but defer creation of more expensive FTPFile objects until
> needed. This scenario was broken in the VMS case.
> The nice thing about this fix is that both scenarios are supported,
> and complications are much reduced.
> The one thing left to do is decide which VMS scenario, versioning or
> non-versioning is the default, i.e. the one to be supported by
> autodetection. I asked for someone to chime in on this last week
> and no one has. I still don't know.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
--
=====================================================================
Jeffrey D. Brekke jbrekke@wi.rr.com
Wisconsin, USA brekke@apache.org
ekkerbj@yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org