[
https://issues.apache.org/jira/browse/NET-272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12699610#action_12699610
]
Christian Gosch commented on NET-272:
-------------------------------------
Hi Rory,
I checked it out and found: No FTPS on board :-(
(I also checked other packages, since some classes have been moved away
from a more general package to their own one.)
Please show me where it is.
Concerning Java, it seems compliant to Java 1.4: No *.regex.**, but
*.oro.**, and no *.concurrent.** in ListenerList.
FTPS is the only reason for me to move. So that should be present.
Thanks anyway, also for further hints,
--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.
