[jira] Created: (NET-272) Backport / Downgrade of commons-net-2.0 to Java 1.4

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

[jira] Created: (NET-272) Backport / Downgrade of commons-net-2.0 to Java 1.4

Gilles (Jira)
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


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.

Reply | Threaded
Open this post in threaded view
|

[jira] Commented: (NET-272) Backport / Downgrade of commons-net-2.0 to Java 1.4

Gilles (Jira)

    [ https://issues.apache.org/jira/browse/NET-272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12697803#action_12697803 ]

Rory Winston commented on NET-272:
----------------------------------

Hi Christian

Would the the net-1.5.0 branch do what you need? This is JDK 1.4-compatible.

If you want the MatchResult type functionality, you could use the oro library, which is what the previous version of [net] does.

> 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.

Reply | Threaded
Open this post in threaded view
|

[jira] Commented: (NET-272) Backport / Downgrade of commons-net-2.0 to Java 1.4

Gilles (Jira)
In reply to this post by Gilles (Jira)

    [ 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.

Reply | Threaded
Open this post in threaded view
|

[jira] Commented: (NET-272) Backport / Downgrade of commons-net-2.0 to Java 1.4

Gilles (Jira)
In reply to this post by Gilles (Jira)

    [ https://issues.apache.org/jira/browse/NET-272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12699547#action_12699547 ]

Rory Winston commented on NET-272:
----------------------------------

Hi Christian

Try

http://svn.apache.org/repos/asf/commons/proper/net/trunk


> 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.

Reply | Threaded
Open this post in threaded view
|

[jira] Commented: (NET-272) Backport / Downgrade of commons-net-2.0 to Java 1.4

Gilles (Jira)
In reply to this post by Gilles (Jira)

    [ 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.

Reply | Threaded
Open this post in threaded view
|

[jira] Commented: (NET-272) Backport / Downgrade of commons-net-2.0 to Java 1.4

Gilles (Jira)
In reply to this post by Gilles (Jira)

    [ https://issues.apache.org/jira/browse/NET-272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12701824#action_12701824 ]

Rory Winston commented on NET-272:
----------------------------------

Yes sorry Christian, there is no FTPS support in the 1.5 branch, with no plans at the moment to add it.

> 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.

Reply | Threaded
Open this post in threaded view
|

[jira] Commented: (NET-272) Backport / Downgrade of commons-net-2.0 to Java 1.4

Gilles (Jira)
In reply to this post by Gilles (Jira)

    [ https://issues.apache.org/jira/browse/NET-272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12701828#action_12701828 ]

Christian Gosch commented on NET-272:
-------------------------------------

OK, so we closed the circle ;-)

In need of FTPS the one and only version of commons-net to use is 2.0,
and in need to deploy it on Java 1.4, the one and only way to achieve
this is to back-port it. retroweaver is no option since some classes not
"retroweavable" are present.

Thus I will use it that way and offer the code again here, with the one
TODO mentioned earlier:

- back-replace regex "MatchResult" by the corresponding ORO construct in
the directory contents parser context.

Maybe I am required to do this by myself anyway.

Additionally, the Java 1.4 compatible thread-safe List (i. e.
"Collections.synchronizedList(new ArrayList())") in ListenerList which I
currently use may be replaced by some construct fitting better the
purpose. In 1.5.0, it simply was a Vector.

Finally, I only changed the source code and the obvious attributes in
the maven XML stuff. To build the project using maven, one has to check
carefully if that is sufficient. I did not test that.


If no one else of the team has any interest in incorporating this kind
of code in any branch of commons-net, this thread is complete.

If any one else is interested in this code, I think it should be
possible to zip the whole tree and simply upload it here. If I succeed
in re-introducing MatchResult via ORO, I will mention it here.

Regards,
--cg

commons-net-
no
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.

Reply | Threaded
Open this post in threaded view
|

[jira] Updated: (NET-272) Backport / Downgrade of commons-net-2.0 to Java 1.4

Gilles (Jira)
In reply to this post by Gilles (Jira)

     [ https://issues.apache.org/jira/browse/NET-272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Sebb updated NET-272:
---------------------

    Affects Version/s: 1.4
                           (was: 2.0)

Affects 1.4, not 2.0

> 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: 1.4
>         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.

Reply | Threaded
Open this post in threaded view
|

[jira] Commented: (NET-272) Backport / Downgrade of commons-net-2.0 to Java 1.4

Gilles (Jira)
In reply to this post by Gilles (Jira)

    [ https://issues.apache.org/jira/browse/NET-272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12887305#action_12887305 ]

Christian Gosch commented on NET-272:
-------------------------------------

Affects *2.0* (that is: commons-net-2.0) and *NOT* (commons-net-)1.4.

It seems like I cannot change field values or I did not find how to yet, so pls. reset the "versions affected" value to "2.0".

In you are in doubt, read the small discussion on which version contains TLS support and which does not.

> 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: 1.4
>         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.

Reply | Threaded
Open this post in threaded view
|

[jira] Commented: (NET-272) Backport / Downgrade of commons-net-2.0 to Java 1.4

Gilles (Jira)
In reply to this post by Gilles (Jira)

    [ https://issues.apache.org/jira/browse/NET-272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12887345#action_12887345 ]

Sebb commented on NET-272:
--------------------------

I understand the discussion.

However the issue is about the fact that the 1.x code line does not have FTPS support, i.e. it affects 1.4.

The 2.x code line does have FTPS support, and this issue does not mean that the FTPS support in 2.0 is faulty.

> 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: 1.4
>         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.

Reply | Threaded
Open this post in threaded view
|

[jira] Commented: (NET-272) Backport / Downgrade of commons-net-2.0 to Java 1.4

Gilles (Jira)
In reply to this post by Gilles (Jira)

    [ https://issues.apache.org/jira/browse/NET-272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12887367#action_12887367 ]

Christian Gosch commented on NET-272:
-------------------------------------

OK, I agree.

It is in important distinction whether to make it an 1.4/1.5 issue because FTPS is not present in 1.4/1.5 (but 1.4/1.5 are runtime compatible with Java2 1.4) or to make it an 2.0 issue because 2.0 does not work on Java2 1.4 but contains running FTPS support.

AFAIK 1.4 was never supposed to support FTPS by the way, like 1.5. Thus this issue stays to be an "improvement wish" and no "problem report".

My solution however was a backport of 2.0 to make it compatible with Java2 1.4, and not an addition of FTPS support to 1.4/1.5. The developer team and not me may decide if this also may be seen as an improving work on 1.4/1.5 -- I do not know the other differences between 1.4/1.5 and 2.0 code base. I think there may be more than FTPS support.

> 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: 1.4
>         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.