[
https://issues.apache.org/jira/browse/NET-272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12698694#action_12698694
]
Christian Gosch commented on NET-272:
-------------------------------------
Hi Rory,
Following the Changes Report, the FTP over SSL/TLS feature was added
after 1.5.0 resp. is not present in the 1.5.0 feature list. But this is
what I need. (Primarily I need to put some files into one specific
directory on a well-known target server using FTP over TLS, and in a
second step to remove known files from there; problems of type "file to
put is already there" or "file to remove is not there" may be swallowed.
Being able to read the current contents of this directory to check if
there should something be removed or re-added therefore would be fine,
but as far as I can see now, this is not required yet.
Anyway: How do I get anonymous access to this branch, if it turns out
that it can do the job?
--cg
commons-net-
Java5
only
EnterpriseDT
remained:
could
(The
guarantees
elsewhere.
MatchResult in
> Backport / Downgrade of commons-net-2.0 to Java 1.4
> ---------------------------------------------------
>
> Key: NET-272
> URL: https://issues.apache.org/jira/browse/NET-272
> Project: Commons Net
> Issue Type: Improvement
> Affects Versions: 2.0
> Environment: Java 1.4 VM (as opposed to usually required Java5 VM)
> Reporter: Christian Gosch
> Priority: Minor
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> I need FTP over TLS used as Client on an IBM WebSphere 6.0 AppServer which
> only allows for the built-in Sun/IBM JRE 1.4.2, and the one and only useful
> open source Java library for doing so currently seems to be commons-net-2.0
> which requires a Java5 VM. (The alternative EnterpriseDT edtFTPj/PRO may fit
> fine but is way too expensive.)
> Thus I tried to "back-port" the commons-net-2.0 sources to Java 1.4 which was
> feasible up to some 95% in a few hours :-)
> Of course the nice things about type safety and so on (generics, extended
> "for" loop syntax...) disappeared gracefully, the enum in the TFTPServer had
> to be replaced by an equivalent implementation, and all annotations have been
> abandoned, but finally only 1 hard stopper remained: I could not find a
> useful replacement for the use of MatchResult in RegexFTPFileEntryParserImpl
> and VMSVersioningFTPEntryParser, which could guarantee the separation of
> changes in the same way MatchResult does. (The __listeners list in
> ListenerList is solved by Collections.synchronizedList(new ArrayList()),
> which at least guarantees thread safety.)
> I have that code at hand and can donate it to the community, but at least it
> should only get into some branch, and finally: Are you or is someone else
> interested in this code at all?
> If so, there should be some way to publish it, maybe here or elsewhere.
> Remaining tasks are: Finding a useful replacement for Java5 MatchResult in
> Java 1.4, re-integration with the maven build environment (i did the
> modifications somewhat "offline").
> If not, sorry for the disturbance...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
