Re: [all] Going TLP?
+1 on the TLP vote In message [EMAIL PROTECTED], =?iso-88 59-1?Q?J=F6rg_Schaible?= writes: I never got why things like ECS, ORO, regexp are not part of commons. = What makes them different to logging or digester? I can understand the = separation for something like POI, but not necessarily for components I = would describe as utitlity libs. Maybe I'm lacking simply historical = reasons though ... For at least ORO, there has been no opposition to moving it into Commons that I can recall. It hasn't happened because folks have taken the initiative only to propose it, not to actually do it. There's also been the issue that being forced to rename the the packages to org.apache.commons.oro, org.apache.commons.regexp, etc. breaks lots of existing code. However, done projects like ORO and regexp are being viewed as unwanted baggage by some folks despite the value they've provided for many years, so I don't know if they'll be allowed to follow commons. They don't belong in Dormant because they have actual releases, but they don't belong in Proper because they are primarily consumed, not developed (albeit they are maintained). The options advocated at Jakarta are always dead or alive for some reason and don't allow for finished. If the Commons community does not oppose allowing for projects to become finished/complete, then some of these can and probably should follow (e.g., the 1.4 branch of Commons Net relies on ORO). But I would suggest any further discussion of this be postponed until after the move of Commons to a TLP. If each issue is handled separately, some progress may actually be made. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Going TLP?
I wrote: +1 on the TLP vote s/vote/idea/ will vote +1 when the actual vote is held. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [commons ftp] help! FTPClient.isConnected() does not work.
In message [EMAIL PROTECTED], Rory Winston writes: I knwo you said that you were going to have a look at adding connect timeout functionality to FTPClient. I had some spare time today, and I decided to see if I could give it a go on the 2.0 branch. However, I Sorry. I plum forgot. Thanks for taking it on. would be grateful if you could give it an eyeball and see if you think it is an acceptable solution. I have made changes to SocketClient and added a simple test case. The changes could be moved into the socket factory with SocketClient.setConnectTimeout being a passthrough to the factory's setConnectTimeout. That way, no extra code has to be added to other places where a factory is used in a SocketClient subclass, such as such as when FTPClient establishes a passive mode data connection. But that's just a first impression that could be off base. With or without that, I think it's safe to change if (connectTimeout == DEFAULT_CONNECT_TIMEOUT) _socket_.connect(new InetSocketAddress(hostname, port)); else _socket_.connect(new InetSocketAddress(hostname, port), connectTimeout); to simply: _socket_.connect(new InetSocketAddress(hostname, port), connectTimeout); because _socket_.connect(new InetSocketAddress(hostname, port)); has the same effect as: _socket_.connect(new InetSocketAddress(hostname, port), 0); daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[net] i need jira issue editing permission (was Re: [jira] Created: (NET-141) FTPClient/DefaultSocketFactory does not regard default timeout)
In message [EMAIL PROTECTED], Christian Hufgard (J IRA) writes: FTPClient/DefaultSocketFactory does not regard default timeout -- Key: NET-141 URL: http://issues.apache.org/jira/browse/NET-141 I added a comment to this issue but couldn't reclassify it. I'm stuck in only the jira-users group. Could someone with admin privileges add me to the appropriate group so I can edit issues? My jira user name is my apache.org email address (dfs at apache dot org). thanks, daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release [net] version 2.0
In message [EMAIL PROTECTED], Rory Winston writes: OK, seeing as we have reached some kind of consensus on how to handle backards-incompatible JDK releases, I'm restarting the vote for a release of Commons::Net 2.0 (the JDK 5.0 branch). +0 I was hoping to see more radical API and implementation changes in Commons Net 2.0. But since I'm currently unable to contribute to such changes, I'm giving a +0 primarily to indicate that I haven't fallen off the planet. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [commons-net ftp] help! can I avoid oro.jar? (MalformedPatternException)
In message [EMAIL PROTECTED], Anil Philip wr ites: I googled and read that the oro.jar is missing. However my application is sensitive to download times and I dont wish to add the oro.jar if possible - I am not using regex here. Is there any way out? The oro jar 77k in size (a good deal smaller than all of the JavaScript support libraries that get loaded in Web pages these days) Usually, if you're sensitive to the size of a jar file, you repackage your application to use only the essential classes. There's nothing preventing you from removing unused classes from the commons-net (based on your commons-user email) and oro jars. However, the oro classes are used by the FTP listing parser. All that said, if you do a checkout of the trunk of the oro svn repository and compile the source with 'ant jar' you will find a number of jars, two of which will be jakarta-oro-core-2.1-dev-1.jar and jakarta-oro-perl5-2.1-dev-1.jar. I do not believe commons-net uses anything outside of that. The first jar is 12k in size and the second is 28k. You can make the second one smaller by removing the org/apache/oro/text/perl classes and the first one smaller by removing the classes with 'Engine' in their names. Based on your commons-net email, you appear to be using only FTP. I'd suggest removing the bsd, nntp, ntp, pop3, smtp, and tftp packages from that jar and creating a new jar including all of your app dependencies to avoid multiple downloads since you're concerned about download times. However, since you mentioned in your commons-user email that you're using Java WebStart, downloads are a one time cost because of the application caching. Also, with the caching mechanism, it's better to use separate jars so that individual jars can be updated without requiring the entire application to be redownloaded. daniel -#-#-#-#-| Sleep and The Traveller |-#-#-#-#-#-#-#- http://www.savarese.org/ In distant lands, I hear the call of my home. # s a v a r e s e Yet my work is not done. My journey's just begun.-software research -- http://www.sleepandthetraveller.com/ # http://www.savarese.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] Commit patch for 38688
In message [EMAIL PROTECTED], Rob Hasselbaum writes: Could a committer please review and commit my patch for bug 38688? I'm preparing a patch for a different bug now that impacts some of the same lines of code and it would be nice to avoid a messy merge later. Done. You can fetch it from the main trunk. Thanks Rob! daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ftp][Fwd: [VFS] FTP Sending LIST while in binary mode]
In message [EMAIL PROTECTED], Mario Ivankovits writes: Ever heard of this? I ran into a problem with a strict FTP server that needs the LIST command to be send while on ascii mode. If it is sent on binary mode, The RFC states the data transfer for LIST is of type ASCII or EBCDIC. It's up to the user to change the mode to ASCII before doing the list because the listing is transferred over the data connection. So, yes, the safe thing for VFS to do is to change the mode before listing a directory. However, I'm not sure I would say the behavior of that FTP server is correct. The RFC does not say the server must not respond or return an error. Although, one could say the behavior is undefined by the RFC, I believe the correct behavior is for the server to send a binary data stream. For most intents and purposes (short of CRLF vs LF issues) it is identical to the ASCII stream, which is in fact what most FTP server implementors have done. But that's neither here nor there. The spec is only unambiguous about the behavior of LIST in ASCII mode :( daniel -#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-| Sleep and The Traveller |-#-#-#-#-#-#-#- s a v a r e s e # In distant lands, I hear the call of my home. software research # Yet my work is not done. My journey's just begun. http://www.savarese.com/ # -- http://www.sleepandthetraveller.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ftp][Fwd: [VFS] FTP Sending LIST while in binary mode]
In message [EMAIL PROTECTED], Mario Ivankovits writes: Sure, I can do this, but shouldnt [net] try to be RFC compliant? Leaving it to the user to be compliant is odd, isnt it? The original intent of commons-net was to provide low-level access to IETF protocols. That meant providing primitive operations only, although some high level functionality made it's way in out of necessity. I'm not going to stand in the way of changing listFiles (although I guess it would now be initiateListParsing) to switch modes as necessary, but the original intent was for higher level tools like VFS to use the low level primitives to provide higher level functions (like recursive retrieves and such). At any rate, I don't have a strong opinion and if most folks think it makes more sense for FTPClient to take care of the detail, then let's do that. What do others think? The trend seems to have been to want commons-net (at least the ftp package) to handle more stuff automatically and hide the details. daniel -#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-| Sleep and The Traveller |-#-#-#-#-#-#-#- s a v a r e s e # In distant lands, I hear the call of my home. software research # Yet my work is not done. My journey's just begun. http://www.savarese.com/ # -- http://www.sleepandthetraveller.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r373207 - /jakarta/commons/proper/net/branches/JDK_1_4_BRANCH/src/java/org/apache/commons/net/ftp/parser/RegexFTPFileEntryParserImpl.java
In message [EMAIL PROTECTED], [EMAIL PROTECTED] g writes: ... URL: http://svn.apache.org/viewcvs?rev=373207view=rev Log: Changed to JD 1.4 regex package ... +import java.util.regex.MatchResult; There is no MatchResult interface in JDK 1.4. It was added in JDK 1.5. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r373242 - /jakarta/commons/proper/net/branches/JDK_1_4_BRANCH/src/java/org/apache/commons/net/ftp/FTP.java
In message [EMAIL PROTECTED], [EMAIL PROTECTED] g writes: Removed dependency on TelnetClient ... -public class FTP extends TelnetClient +public class FTP extends SocketClient From RFC 959: control connection The communication path between the USER-PI and SERVER-PI for the exchange of commands and replies. This connection follows the Telnet Protocol. You can't remove the dependency on TelnetClient without implementing the subset of telnet used by the FTP connection. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r373243 - /jakarta/commons/proper/net/branches/JDK_1_4_BRANCH/src/java/org/apache/commons/net/SocketClient.java
In message [EMAIL PROTECTED], [EMAIL PROTECTED]
g writes:
Added getter/setter for Input/OutputStream
+ public InputStream getInputStream() {
+ return _input_;
+ }
I really don't think these should be public. Otherwise, one might as well
work directly with the Socket class. Callers of SocketClient
implementations shouldn't be able to mess directly with the input and
output streams unless the specific implementation chooses to permit
it (e.g., SMTPClient.sendMessageData). Even in those cases, the streams
are usually wrapped by other i/o classes. To access the streams directly
will bypass the wrappers. I think the methods should be protected,
but since the members are already protected, I don't think there's a
reason to have the methods. At least that's the explanation for why those
methods didn't exist.
As an unrelated side note, the primary motivator for SocketClient was the
lack of support for connection-specific socket factories in JDK 1.1. The
secondary motivator was to put common client operations in one class and
establish a library-wide convention for using clients (e.g., connect,
disconnect) instead of reimplementing them in each class. Now that
there are socket factories in javax.net, there's probably no longer a
need for SocketFactory, but there's probably still a need for SocketClient.
Unfortunately, the NIO stuff doesn't appear to support hooks for
socket factories, so I'm afraid there will have to be some awkwardness
in supporting selectable i/o with SocketChannel and pluggable socket
implementations.
daniel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] JDK 1.4+ Branch?
In message [EMAIL PROTECTED], Rory Winston writes: I think that this might be a good point to consider introducing a version of Commons-Net that uses JDK 1.4+ as a baseline. My reasoning is I've long advocated branching to take advantage of JDK 1.4, but I had a more radical agenda. I believe the underpinnings of Commons Net need to be redesigned without being afraid to break compatibility. My suggestion was for this new Commons Net 2.0 to be in a new package: org.apache.commons.net2. At the time, the incremental evolution path was preferred. * We could remove the (oro) jar dependency; I think that's a side-effect of moving to JDK 1.4, not a reason in and of itself for JDK 1.4. There are no benefits to java.util.regex over oro in the context used by Commons Net. * It could be a good opportunity to clean up the threading code and socket handling, and make use of NIO; I believe that's the main reason to make the move. Of course, JDK-1.3-compatible releases could still continue on HEAD, or we could move the 1.4+ branch to HEAD and the 1.3 code to a maintenance branch. Assuming we're talking about continuing incremental evolution, I believe we should cut a 1.4.2 release with all the current bug fixes included and branch from there. JDK 1.3 would be supported in maintenance releases based off of 1.4.2 (e.g., 1.4.3, 1.4.4, etc.) that would only include bug fixes. New development based on JDK 1.4 would continue on the main trunk. Taking the FTPS code contribution into account, I'd change that to releasing a 1.4.2, then incorporating the FTPS code in a 1.5 release compatible with JDK 1.3, and branching from there as per the original scenario. The only situation in which I'd suggest doing it differently is if someone was really itching to write NIO or other JDK 1.4 stuff in the near term, in which case I think we'd have to let that happen on a separate branch until the FTPS code was incorporated into the trunk. Then after the 1.5 release off of the trunk, we'd merge changes from the JDK 1.4 branch into the main trunk and only do JDK 1.3 releases off of the 1.5 tree. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] JSSE classes in FTPS WAS Re: [net] FTPS submission - legal issues
I'm living in the timewarp of digest mode subscription, so please forgive me for having made obsoleted comments. In message [EMAIL PROTECTED], Rory Winston writes: I think that's a great suggestion. It moves us forward without necessarily sacrificing backwards compatability. ... Steve Cohen wrote: Thank you for this explanation. It is good to actually look at the code instead of making assumptions, which is what I have been doing. ... Therefore, I think the solution for this is for Jakarta Commons Net to take Rory Winston's suggestion and start a new branch of Commons Net for JDK 1.4 only (for this and other reasons) and maintain two branches for awhile, the current HEAD branch for 1.3 compatibility and the new branch for 1.4. The new branch can use the javax.ssl.net classes, the old one can use com.sun.net. +1 Since we're going to branch anyway and in light of Steve's discoveries about JSSE 1.0.3, this seems like the easiest way to handle the situation. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] JSSE classes in FTPS WAS Re: [net] FTPS submission - legal issues
In message [EMAIL PROTECTED], Steve Cohen writes: Daniel, before we vote, I think we need a formal motion to vote on, especially in light of your obsoleted comments in the other thread. My +1 wasn't intended to reflect a vote. It was just shorthand for I concur. While I'm generally in favor of this, I still don't think its ready for a vote because of possibly a different project, which is too vague. +1 :) daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] JDK 1.4+ Branch?
In message [EMAIL PROTECTED], Rory Winston writes: * You're correct that there is no inherent advantage, at least functionality-wise, in removing the ORO dependency. I think the major I didn't mean to suggest that the dependency shouldn't be removed. I was just being nitpicky and saying that it should be removed because we're using JDK 1.4 rather than we should move to JDK 1.4 so we can remove it. * The FTPClient/TelnetClient area: actually, I may have misremembered a comment you made some time back, in which I think you may have expressed a desire to break the dependeny here. I think at least what we should look at is making any incremental changes to the threading code that may be required. I'd have to look back through the archives to see what we talked about before. All I know for sure at the moment is that I am extremely disenchanted with the current TelnetClient implementation. I think my previous comments may have been that the subset of telnet used by FTP didn't require asynchrony and could be implemented in the FTP class to remove the dependency on TelnetClient. However, if TelnetClient is reimplemented with NIO without threads, then there's no need to remove the dependency. The bad thing about the dependency on TelnetClient as currently implemented is that if you want/need to use many FTPClient instances at the same time, you end up with a bunch of extra threads that hog up resources. * I dont know how much has been added since 1.4.1 to merit a 1.4.2 release - maybe we should just go for a 1.5.0 (with FTPS)? There's that TFTP regression, the fix to which at least two people on commons-user are waiting for. I don't know what else users are waiting for, but if the time frame for a 1.5.0 release with FTPS isn't far off, then I also don't see any reason for a 1.4.2. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] JSSE classes in FTPS WAS Re: [net] FTPS submission - legal issues
In message [EMAIL PROTECTED], Rahul Akolkar writes: No, haven't had to deal with such a situation. But doesn't this mean that the code will only work on a subset of the 1.3 JDKs (Sun)? If so, maybe (3) isn't all that bad? In general, I am biased against introducing dependencies on com.sun packages for the very reason stated. The code will work only with the Sun JDK or JVMs incorporating sublicensed parts of the JDK that include those packages. For that matter, it will work only with a particular version of the Sun JVM should the classes not appear in a future release. If JSSE will work and is usable with JDK 1.3 as an add-on jar, I don't see any reason why it should be avoided (i.e., I'm +1 for option 3 and -1 for 2). daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] FTP sends incorrect type for EBCDIC
In message [EMAIL PROTECTED], Niklas Gustavsson writes: Fair enough, but if it is treated as binary, shouldn't the type be I? That's what I get for not doing my homework :) Okay, so I have no idea why it is sending B (other than it being a mistake). I'm not even sure why I thought the spec required ASCII/EBCDIC translation, since it says: For transmission, the data are represented as 8-bit EBCDIC characters. I'll change it to E whenever the source repository is accessible again. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] FTP sends incorrect type for EBCDIC
In message [EMAIL PROTECTED], Niklas Gustavsson writes: When issuing ftp.type(FTP.EBCDIC_FILE_TYPE), FTP will send TYPE B. This is not correct according to RFC 959 where the EBCDIC type is specified as E. I'm pretty sure sending B is intentional since we do not perform automatic translaton between EBCDIC and ASCII. Therefore, EBCDIC is treated as a binary file not subject to the automatic translation required by the FTP spec. It's probably not useful to make a change unless the character translation is implemented. However, I'm speaking purely from memory and not from revisiting the code and RFC. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] Found and fixed a bug in FTPClient class in Commons Net project.
In message [EMAIL PROTECTED], [EMAIL PROTECTED] writes: I downloaded the source code and found the problem. It's in getSystemName method of FTPClient class in Commons Net project. The reason is that for some system, such as HP's NonStop (Tandem) platform, SYST command is not understood, so __systemName will be null thus causing the error above. The proper place to handle this would be in the caller to getSystemName, otherwise you will never be able to know that the system name is unknown. The documentaton for getSystemName() says: * @return The system type name obtained from the server. null if the * information could not be obtained. In other words, it is intended to return null. It is up to the caller to decide what to do with the information. If there's a need for a change, I would suggest making it higher up in the call chain. Steve would know best if there's any need. My guess is that the intent is for API users to catch that ParserInitializationException and select a default parser according their needs instead of having Commons Net make the decision for them. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Stefan Bodewig as commons proper committer
In message [EMAIL PROTECTED], Joe Germuska writes: overdue, probably due to that everyone probably thinks he is a already committer) That's what I thought! Same here. +1 daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: VOTE: Release Commons-Net 1.4.0
In message [EMAIL PROTECTED], Jeffrey D. Brekke writes: I'm having hanging problems running the functional tests under 1.5, but 1.4.2 works ok. Anyone else seeing this running maven test:functional? ListingFunctionalTest hung for me with both because of my firewall. I added a call to enterLocalPassiveMode and it worked with both 1.4.2 and 1.5 for me, although for 1.4.2 I had to use maven -Dmaven.compile.target=1.4 test:functional Rory Winston wrote: I have cut a RC of Commons-Net 1.4.0. If anyone has no objections, I would l ike to cut a release in the next couple of weeks. The main thrust behind this +1 daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] FTP client date parsing: new format
Rory Winston writes: As regards a timeline, I'm also pretty swamped over the next couple of weeks ( starting a new role, etc), so it will be tight for me until then. If I do get a chance in the next couple of weeks I will look at fixing some of the more s traightforward issues in BZ. It would be nice to get a release out before too My schedule opens up after April 25, but I'll try to handle some small issues like the recent POP3Client bug report before then. It would also be nice to close a bunch of the resolved issues. too long - maybe in the next 4-6 weeks, how does that sound as a rough timescale estimate? It sounds about right if everyone's tied up for at least the next two weeks and the bulk of the new code is already in CVS. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] Faulty method name in class FTP
In message [EMAIL PROTECTED], Lindberger Per writes: In org.apache.commons.net.ftp.FTP there is a public method named removeProtocolCommandistener. I think this would be worth changing to Thanks. I applied the fix. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all][VOTE] svn migration
In message [EMAIL PROTECTED], Tim O'Brien write s: This is a vote thread for migrating commons to SVN. If this vote +1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Commons Structure rehashed
In message [EMAIL PROTECTED], Noel J. Bergman w rites: We don't version Commons as a single component, and I don't know that we want to force everyone to always take every single component. Someone wanting to build all of Commons is not the norm. I didn't want to reopen the issue. I was merely making an ancillary comment. However, the flatter layout does not version Commons as a single component. It's all dictated by the procedures one follows. There's no difference between checking out https://svn.apache.org/repos/asf/jakarta/commons/foo/trunk and https://svn.apache.org/repos/asf/jakarta/commons/trunk/foo or between tagging https://svn.apache.org/repos/asf/jakarta/commons/foo/tags/foo-x.x.x and https://svn.apache.org/repos/asf/jakarta/commons/tags/foo-x.x.x The difference is all in one's head. Whether one is uncomfortable with a tag tree filled with lots of tags is a matter of personal preference and one I understand. But conceptually, and in terms of release procedures and script writing, there's no technical difference (everything is still versioned separately). Anyway, please stop commenting on this. I was rambling late at night without having read the thread from its start and I apologize for the distraction given the merely observational nature of my comment. I'm a happy camper with the currently proposed layout. The intent of my email was to offer a suggestion regarding the mention of symbolic links, assuming I understood what was being discussed. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Commons Structure rehashed
In message [EMAIL PROTECTED], Henri Yandell writes: On Sun, 19 Dec 2004 00:00:20 +1300, Simon Kitching [EMAIL PROTECTED] wrote: svn 1.1 (released 2004-09-29) supports symbolic links. Perhaps that would resolve the issue by allowing us to (manually) build an alternative directory containing just symbolic links to the trunk directory of each subproject? Of course whenever a new subproject was created, a symbolic link would need to be manually added - but that is no great problem. Possibly that could even be automated; I'm willing to try to get that working. Cool. I knew such a feature was in the planning but hadn't realised it was out yet. I'm +1 on option A + sym-links or script depending on which feels best. As long as there's a simple way to check out the head of all of commons :) I haven't read the entire thread, but if I understand what's being discussed, checking in symbolic links won't do what you want (assuming we're talking about ln -s symbolic links). Setting the svn:externals property will do what I think you're talking about. For example, you could set svn:externals in a directory to: lang https://svn.apache.org/repos/asf/jakarta/commons/proper/lang/trunk math https://svn.apache.org/repos/asf/jakarta/commons/proper/math/trunk ... That way when you check out the directory, subdirectories lang, math, etc. are created with the contents of the urls checked out. I prefer the idea of using a script instead because it's more flexible for doing things like checking out personalized subsets of commons. Anyway, I may have misunderstood the intent from the get go. I also prefer the flatter layout: jakarta/commons/tags/ /attributes-1.0.1 /attributes-1.0.2 /beanutils-0.9.7 /sandbox/altrmi-x.x.x ... /branches /lang-foo /math-bar /trunk /attributes ... /sandbox /altrmi /amend ... /site ... /validator I can't offer a reason why it's technically better because it just amounts to personal preference. Also, I see how doing having proper/ and sandbox/ parent trees makes certain things easier (like generating commit message subject headers). However, it does make it easier to check out the trunk of commons all at once. I'm sure I missed the original discussion about this, so don't reraise the issue on my account. It doesn't really matter anyway because layouts can be changed after the fact if there's some compelling reason to do so. I only wanted to convey the bit about svn:externals vis a vis symbolic links since it caught my eye. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] Push for 1.3.0 release
Rory Winston writes: I think we should push out a 1.3.0 release pre-xmas. There are many, many enhancements and fixes, and also a new component in HEAD. +1 BTW, thanks for all the work you've done going through and addressing all of those issue reports. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [email] and net
In message [EMAIL PROTECTED], Vic Cekvenich writes: to the people of thinking of releaseing email: I think a lot more work is in net's smtp package such as simple emailer. So, maybe build on that,that is a superset. I didn't notice the original message this was in reply to, but I thought commons email was an API to make it easy to use JavaMail. I don't think the commons net smtp package has much to offer commons email unless I'm missing something. The commons net smtp package is geared toward programmatically executing the client side of the SMTP protocol and does not concern itself with the modeling/assembly/manipulation of email messages. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 31272] - TelnetInputStream zombie thread memory leak, FTPClient TelnetClient
In message [EMAIL PROTECTED], Rory Winston w rites: Actually, just having a quick perusal, I think this may be the culprit ... I've fixed, tested, + committed. Thanks. That's the second straight sloppy patch I've made. I always tell myself I shouldn't touch code after midnight :) I must have somehow compiled it with the unit tests disabled or just not noticed they failed. Shame on me. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] SNTP support?
In message [EMAIL PROTECTED], Rory Winston w rites: Has there been any code contributed re: (S)NTP? I feel I may have a use for this in my day-to-day, and I am just wondering if there has been any movs toward including this. I see there is a TODO on the list that says review (S)NTP code, which implies some code to review. There should be a code submission somewhere in bugzilla, but I can't find it right now. I kept meaning to go over the code, but never got around to it. If you can review it and decide whether/how to incorporate it, that would be great! If really not in bugzilla and I'm not making another late night gaffe, then it may have been submitted to the mailing list and I don't know if the mailing list archives save binary attachments (it may have been a zip file). If you can't find it with a quick search, let me know and I'll dig through my email and see if I can find it and forward it to you. If it went to the mailing list I've still got it somewhere. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 27437] - FTP get and list tasks fail
In message [EMAIL PROTECTED], [EMAIL PROTECTED] .org writes: --- Additional Comments From [EMAIL PROTECTED] 2004-09-23 15:00 --- Sorry, my bad. I didn't realize that Daniel has an AIX parser in there already . I don't think I wrote any of the parsers other than the original default one which has been phased out. I don't think there's an AIX parser. One of the Unix listing parsers should handle it I think. Steve or Jeff would know better than I. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 23488] - OS400 FTP server directory listing is not being parsed properly in FTPFile class.
http://issues.apache.org/bugzilla/show_bug.cgi?id=23488 OS400 FTP server directory listing is not being parsed properly in FTPFile cla ss. --- Additional Comments From [EMAIL PROTECTED] 2004-09-23 13:25 --- Should this bug be marked as FIXED? I can see that we have an OS400 parser in there already (last revision: 1.4 by Daniel). If I touched it, it was to fix a problem with file sizes being returned as ints instead of longs. I think Steve committed the file and Mario may have written it, so I trust Steve knows what the deal is. Ah, I see he's indicated the bug was reported before the parser was added. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] can commons ftp api cause files to be set with wrong owner on server?
In message [EMAIL PROTECTED], =?iso-8859-1?q ?jo=FFe3o=20Paulo=20souza?= writes: I´m using commons.net.ftp package to make the ftp transaction of files from one server to other.I´m connecting for example with an id = bla. So all files stored by the method storeFile from ftpClient class should be own er bla on the server(AIX).Can somebody give me a tip if it is either most li kely a probelm on the ftp or on the server AIX? If the stored files have an owner id different from what you expect, it's most likely the FTP server configuration or the file system configuration. FTPClient just tells the server to store the file and doesn't specify permissions or ownership. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FTPClient related bugs: 30970 and 31122
In message [EMAIL PROTECTED], Joseph Hindsley writes: I had submitted a patch last week for the FTP and FTPClient classes (http://issues.apache.org/bugzilla/show_bug.cgi?id=30970) that doesn't seem to have had any activity. The patch changes FTP to extend SocketClient instead of TelnetClient since the implementation of If it were as simple as using SocketClient, that would have been done from the start. Unfortunately, the FTP control connection requires telnet negotiation. Also unfortunate is that telnet has asynchronous elements that can only be implemented properly with two threads in the absence of selectable channels. Switching to SocketClient will make FTPClient not work with many servers. I think the long term solution should be to branch, leaving the 1.2 series as J2SE 1.2 and 1.3 compatible, and reimplement telnet using selectable I/O in a single thread on the head branch; or start a new 2.0 branch either as a branch or in the sandbox as commons-net2, since everything would have to be overhauled once we start using java.nio. Given how everyone involved has a very limited supply of free time, I'm not sure when such a thing may happen. As it is we're behind on incorporating submitted feature additions such as a network time protocol package :( daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Moving from Bugzilla to JIRA
+1 on moving from Bugzilla to JIRA. I've yet to meet an issue tracking system that didn't cause me issues, but JIRA clearly has more features to support planning, status assessment, and development. The Foundation already has free access to the product and source code and is already using it, so it's a rather moot point for me to object based on concerns I would have otherwise. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [NET] [PATCH] FTPClient to work with FTP servers using a Japanese locale. [UPDATE]
In message [EMAIL PROTECTED], Steve Cohen writes:
A diff -u patch file is best. Please don't send the actual files.
cvs diff -u [files] patchfile.txt
As a reminder, we've previously vetoed changes of this sort (in FTP.java):
public int sendCommand(String command, String args) throws IOException
{
+if ((__commandBuffer == null) || (_controlOutput == null))
+{
+throw new IOException(Not connected.);
+}
I'd suggest that particular part of the patch not be applied. It's
incumbent on the caller to not continue to use the object after an
exception has been thrown. What may make sense to do is move the
assignment of _isConnected_ in SocketClient.disconnect up to the
beginning of the method in case one of the close() calls throws an
exception. Basically, as the docs say, if something bad happens,
you're supposed to call disconnect in the exception handler.
daniel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Commons-net.FTPClient
In message [EMAIL PROTECTED], Ash, Mi chael L writes: Doing the setControlEncoding would be wonderful, I have recompiled the code doing what you suggested and it does work, but I um can't use it because its not an official release :) At the moment CVS HEAD is basically identical to the last released version. I believe the only changes have been bug fixes. I added control encoding setter/getter methods. You can do checkout and use that until the next release. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Commons-net.FTPClient
In message [EMAIL PROTECTED], Steve Cohen writes: Sorry I missed your earlier post. The answer is, unfortunately, that the package does not support the easy conversion to UTF-8. If he needs to change the encoding for the control connection, he can recompile the source with FTP.__DEFAULT_ENCODING redefined. If it is a common requirement to use multi-byte character encodings on the control connection, we can add a setControlEncoding or some such method and/or make the control input and output reader/writers protected. There may be some way for telnet (the FTP control connection) to autonegotiate the character encoding, but there's no reason to believe FTP servers dealing in UTF-8 or other multi-byte encodings implement a negotiation. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] Javadoc question
In message [EMAIL PROTECTED], Jeffrey D. Brekke writes: Probably my fault back when we changed package names. Sorry about that. I don't think it occurred to anyone at the time that there were all of those hardcoded links that needed to be converted. If it's anyone's fault, it's mine since I should have realized it given that I put the links there in the first place. Ah, the legacy of pre-J2SE Java ... daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] Javadoc question
In message [EMAIL PROTECTED], Steve Cohen writes: Have at it, Daniel. You can surely do the job quicker than I can. Alrighty, I'll get to it and report back when I finish. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] Javadoc question
In message [EMAIL PROTECTED], Steve Cohen writes: These broken links are almost all of the following form a href = org.apache.commons.net.package/Class.html Of course, these won't work. Can someone help me answer these questions? How did they ever work? Is this the result of some global search and replace gone awry? What is the right way to express such links in javadoc? Relative paths? is Before there was ever a link tag, JDK 1.1 javadoc generated files of the form packagename.classname.html The only way to reference them was directly. Somewhere in the migration process from NetComponents to Commons Net, the links must have been overlooked, but got the org.apache.commons.net in them from a substitution to fix up the package names. It should be easy enough to do a find src/ -name *.java -print | xargs \ perl -pi -e 's/a\s+href=([^]+)\.html/[EMAIL PROTECTED] $1}/g' \ -e 's/a\s+href=([^]+)\.html(#[^]+)/[EMAIL PROTECTED] $1$2}/g' to fix most of it up. The substitution expressions are off the top of my head and surely need tweaking; they also generate fully qualified class names. If you want, I can fix it up. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net][vote] Steve Cohen to manage release of commons-net-1.2.2
[X] +1 - Steve Cohen should proceed with release of commons-net 1.2.2 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vfs][all][poll]regular expression library or jdk1.4 as minimum requirement
In message [EMAIL PROTECTED], Mario Ivankovits writes: It looks like Perl and Java are very (very) simmilar. So asking ORO to The Java regex syntax is almost a superset of Perl, which is why I don't see the impact of using a Perl engine for JDK 1.3 and java.util.regex for J2SE 1.4 as being major. The expression Rami gave was straight Perl 5.005. jakarta-oro's Perl5Compiler/Perl5Matcher implements zero-width look-ahead assertions from Perl 5.003 but does not implement the zero-width look-behind assertions from 5.005 and future versions (if you don't ask for it ...). This can be added. The other difference is that in Perl \Q and \E are not part of the regex syntax. They are part of Perl string handling, so we didn't implement them in Perl5Compiler (instead quotmeta() is provided), but support them in the Perl5Util convenience class. This can be moved into Perl5Compiler if desired. There has to be a user driver for these small things to happen. In general, most regular expressions you see in the wild can be simplified and don't require unusual constrcuts. For example, why write \\Q**\\E when \\*\\* will do (you would usually want to use \Q and \E for longer sequences or for dynamically generated strings you want to escape; but quotemeta works equally well)? Why use a negative look-behind assertion in ((?!^)|[^/]) when [^/] will suffice (the negative look-behind assertion is redundant because if there's a character present that's not a slash, then it's not the start of the input)? Of course, you can't always simplify your expressions and I think Rami's point is that you shouldn't be bothered with the finer points and stuff should just work. I think the answer is that as long as you stick to Perl5 syntax (which most people using java.util.regex are unknowingly doing), you'll rarely run into differences; but that oro doesn't implement most of the stuff added after Perl 5.003 for lack of demand (there's not that much stuff). daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vfs][all][poll]regular expression library or jdk1.4 as minimum requirement
I wrote: want to escape; but quotemeta works equally well)? Why use a negative look-behind assertion in ((?!^)|[^/]) when [^/] will suffice (the negative look-behind assertion is redundant because if there's a character present that's not a slash, then it's not the start of the input)? Of I forgot to add that that's assuming single line mode. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 29689] - [net] Unix parser does not handle special files.
In message [EMAIL PROTECTED], [EMAIL PROTECTED] .org writes: a listing. Assuming it's implemented, it would also make sense to have FTPFi le return the type as being UNKNOWN_TYPE for these other cases. I haven't kept up with all of the parser changes, but that's why FTPFile.UNKNOWN_TYPE exists. Anything that's not obviously (as determined by the listing format) a regular file, a directory, or a symbolic link (which could point to a directory or to a file) should be treated as unknown, but be included in the listing (and let the client decide what to do with it). At least that was the original intent. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vfs][all][poll]regular expression library or jdk1.4 as minimum requirement
In message [EMAIL PROTECTED], Rami Ojares writes: The problem with having a generic interface for different regex implementation s is that the syntax and semantics of regexes are different. I want to know EXACTLY what my regexes match and what constucts/syntax I can use. Somehow I missed this message. Sorry for the belated response. There are different use cases. What you say is absolutely right for the case where you're coding to a regex API and using those expressions directly in your code. But when you are dynamically fetching expressions, for example from a user interface dialog, it doesn't matter. You can specify what syntax is required for the input. Also, when you're writing generic/reusable code it's of great help. For example, all of the split and substitute methods in the org.apache.oro.text.regex.Util will work independent of the regex syntax used. org.apache.oro.io.RegexFilenameFilter will work with any regex engine. There are plenty of cases where you're writing regular expression code that is not dependent on the specific syntax. For those cases, having generic engines is very useful. The best candidate in my humble opinion for regex language is the one defined in jdk 1.4. What would be needed is a separate package that would implement jdk 1 .4 regex lang and could be used together with older jdk's. That would be a waste of effort in my opinion. Other than glob expressions, there is already a set of syntax common to most pattern matching languages. Since the whole point of the VFS discussion appears to be to support users who aren't using J2SE 1.4, all you have to do is use the syntax subset shared by Perl5 and java.util.regex, which is rather rich and useful. Anyway, that's my take given my understanding of what's being discussed. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vfs][all][poll][RESULT] regular expression library or jdk1.4 as minimum requirement
In message [EMAIL PROTECTED], Mario Ivankovits writes: Whew! Fast work, thank you. If no one involved in VFS has the time to get involved as a committer for jakarta-oro, I need to know more or less by when you would need a 2.1 release of jakarta-oro to be released so you don't have to ask users to rely on the head branch. That way I can budget my time to get it done. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vfs][all][poll][RESULT] regular expression library or jdk1.4 as minimum requirement
In message [EMAIL PROTECTED], Mario Ivankovits writes: jakarta-oro seems a very powerfull solution, but even if is intentaion was only to be an interface - its size has reached 100K - i already hear I didn't mean to give the impression that its intention was to be only an interface, but to stress that it's not just an engine implementation. others yelling ;-) It's possible to split up oro into several smaller jars, one with the core interfaces, one for each engine, one with the utility classes, etc. Offering multiple smaller jars has been on a TODO list and is just a matter of changing the jar generation in build.xml. Not a big deal, but one of those things I always hoped someone with the need/desire would come along and do. I know people are more interested in using regular expression libraries than in maintaining or advancing their development (I'm the same way). Might it be possible to split the discovery/interfaces (use class.forName for its own implementations too) and the implementation to have a small(er) discovery library? Yes, not hardcoding in the Awk, Glob, and Perl5 engine constructors into PatternMatchingEngineFactory occurred to me last night. Since I'm already distracted from work, I can make that change now and make a first pass at repackaging the jars. So as not to break Gump builds, I'll probably continue to generate a jakarta-oro-version.jar instead of a jakarta-oro-all-version.jar in addition to the componentized jars. But don't hesitate to ask for commit privileges (a PMC vote would grant them in short order) and make any changes you see as necessary. I've been trying to get jakarta-oro development to be user-driven, but haven't done a good job. For sure, i know it IS possible ;-), the question is, is this something the ORO project would like to do, or could this be a starting point to refactor ORO and build a commons-RegexpDiscovery, or move the implementations to jakarta-regexp, or I've previously put forward the idea of opening up jakarta-oro (and jakarta-regexp) to any commons committer as a first step to trying to resolve some of the redundancy of effort and decide the future of the regular expression libraries in light of the perception of their impending obsolecence (e.g., should they serve as a temporary bridge until everyone has migrated to J2SE 1.4 and then be shelved?). Anyway, my only concern is not to change the package names of any of the existing classes--or at least provide a smooth migration path that won't immediately break existing code--should a complete move to Jakarta Commons be made. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vfs][all][poll]regular expression library or jdk1.4 as minimum requirement
In message [EMAIL PROTECTED], Noel J. Bergman w rites: Daniel, are you still interested/trying to move ORO into Commons? What is I'm interested in doing whatever it will take to get people using the library or who should be using the library more involved in development. At first I thought that moving into Jakarta Commons might do that, then when Apache Commons started up I thought maybe that was the right place. Now it looks like Jakarta Commons is the right place again, although it would be nice not to have to change the package names. As far as trying, the best I've been able to do is make some noises, but I haven't taken much action under the theory that a couple of other people would lead the charge like happened with Commons Net. happening in the ORO project in terms of developers? Several important contributions were made by some users, but the contributions didn't keep on coming, so I've never called for a vote on granting committership despite their having expressed interested in becoming committers. So despite the contents of the avail file, we're back into a situation where I'm probably the only active committer (and I only make contributions in widely spaced bursts). I think the committer deficit problem would be solved easily if some existing Apache committers who have needs that can be satisfied with jakarta-oro can be convinced to hack the code a little. I've also thought that jakarta-oro and jakarta-regexp ought to interact more and have the same committer base, but I've never started a campaign for that. Asking jakarta-regexp if they're interested in implementing the regexp wrapper engine for oro might get that started. For now though, if I can squeeze enough time out to do the couple of simple things to meet VFS's needs, that may be enough to get more involvement and work things out (whether oro sits where it is or moves partially or completely into jakarta commons). daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vfs][all][poll][RESULT] regular expression library or jdk1.4 as minimum requirement
In message [EMAIL PROTECTED], Mario Ivankovits writes: jakarta-oro seems a very powerfull solution, but even if is intentaion was only to be an interface - its size has reached 100K - i already hear I made the change to PatternMatchingEngineFactory we discussed (use Class.forName() for all of the default engines) and changed build.xml to generate the following jars. I also turned debug info off which reduces the jar file size, since that appears to be something people care about. This is what's generated by the jar target on the head branch: -rw---1 dfs 76246 Jun 15 17:27 jakarta-oro-2.1-dev-1.jar -rw---1 dfs 18124 Jun 15 17:27 jakarta-oro-awk-2.1-dev-1.jar -rw---1 dfs 12296 Jun 15 17:27 jakarta-oro-core-2.1-dev-1.jar -rw---1 dfs 3040 Jun 15 17:27 jakarta-oro-glob-2.1-dev-1.jar -rw---1 dfs 4742 Jun 15 17:27 jakarta-oro-java-2.1-dev-1.jar -rw---1 dfs 27522 Jun 15 17:27 jakarta-oro-perl5-2.1-dev-1.jar -rw---1 dfs 14935 Jun 15 17:27 jakarta-oro-util-2.1-dev-1.jar There can be further subdivisions. For example, Perl5Util and company (as well as Perl5Debug) can be broken out of perl5 or put into the -util package since they aren't part of the Perl5 engine. That can be done if jar size is a concern, but -perl5 seems to be where people would expect to find those classes. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jelly] tag for accessing static fields
In message [EMAIL PROTECTED], Paul Libbrech t writes: I keep believing, however, that such a thing should be done by Jexl or something else... it makes no sense to need this getStatic, at least compared to Java. I agree. After I shot off my email I was going to reply to it and add maybe the right thing to do is enhance Jexl?. When trying to access static constants, the first thing I did was try to use the Jexl expression language, figuring it must support such a thing. After the error messages, finding the Jelly invokeStatic tag, and digging through what documentation I could find, it became clear I couldn't do it with Jexl. I suppose since Jelly supports multiple expression languages, it may be possible to swap in another language to do that sort of thing. I'm new to Jelly and don't know what the preferred approach is to do certain things in a manner consistent with its design. My gut feeling is that the expression language should support features like invokeStatic or my proposed getStatic, but when I see all of the Jelly flow control tags I figure I do not yet understand the intended relationship between Jelly and Jexl or Jelly and another expression language. When does some feature belong in Jelly (or user-implemented Jelly tag), when does it belong in the expression language, when does it belong in a user-implemented JavaBean? As best I can tell, the expression language isn't supposed to do flow control, just evaluate embedded expressions. Based on that Jexl seems like the right place to add static field access. Yet expression manipulation is limited to JavaBean properties (otherwise there would be no need for the invoke tag), which makes it seem like Jexl isn't the right place. If static field access were to be added, why not arbitrary method invocation? Anyway, that's a long-winded way of explaining why I do not yet understand the design guidelines that help dictate what should go where. Yet an alternative way for this was partially done in GridBagConstraintBean: namely it has been tried to have custom converters that would decode such (expected) constants into an integer. The downside to doing that would seem to be that you may have to write a converter for every bean? Or is there a way to do it once for all of them, where by default Jelly would try to match unknown properties against constants? I suppose that's where your mention of BeanUtils comes in. But with a converter, am I correct in assuming you couldn't throw in a constant defined in a different class? Feel free to go ahead but let's start this discussion on the usages of converters in jelly-attributes since it seems BeanUtils folks are eagerly expecting users ;-- I think I'll hold off on doing anything until the discussion runs its course. So far, it seems there's agreement that it's useful to be able to access static class fields, but there's more than one way to do it. Before shoehorning getStatic into jelly core, it may be best to explore the alternatives. Another possibility is to overload invokeStatic so as to avoid adding another tag and have it behave like getStatic if a field attribute is defined and like invokeStatic when a method attribute is defined and throw an exception when both are defined. But that's probably overcomplicating things and not in the spirit of how things are done in Jelly. Otherwise, there would have been no invokeStatic tag and the invoke tag could have been made to behave like invokeStatic if a static=true attribute were present, expecting the on attribute to define a class name in that case. BTW, I'm so glad you mentioned BeanUtils and converters. I have a need right now to take a bunch of beans (remote MBeans actually) and dynamically create Swing components that let you change bean properties and invoke methods. I was fearing (because of the time involved) having to write a bunch of code to convert strings into method parameters. BeanUtils is exactly what I need and it may have taken me a while to figure that out on my own. So count me in as an eagerly expected user. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jelly] tag for accessing static fields
I've been experimenting with Jelly Swing recently after finding Groovy
Swing problematic, trying to see whether it will make GUI prototyping
faster. I may have missed it, but I couldn't find a tag in any of the
tag libraries to access a static class field. There's invokeStatic
for invoking static methods. For the project I'm working on, I
wrote a GetStaticTag that works like this:
v:getStatic var=closeOperation className=javax.swing.JFrame
field=EXIT_ON_CLOSE/
That allowed me to then do:
frame title=Tree Frame var=frame size=400,400
defaultCloseOperation=${closeOperation}
...
/frame
I think it's pretty important to be able to access static fields
and that a getStatic (or some other name) tag would be useful to have
in the core tag library. If I convert my GetStaticTag class code to
the style convention used in the Jelly source and add a Jelly test
for it, is it all right for me to add it to the source tree? I've
appended the simple class at the end of this message. I guess the
question is a two-parter:
1. Does the Jelly core tag library need a getStatic tag to complement
getStatic?
[ ] +1 Yes, it's generally useful.
[ ] -1 No, it's easy for someone who needs it to make their own tag.
2. May I commit code for the tag to the repository assuming I convert
it to the proper style and provide a Jelly test?
[ ] +1 Go right ahead, we can tweak the code after it's committed.
[ ] -1 No, we need to agree on what to call the tag, you should
try more than one class loader in doTag, some other reason ...
daniel
package org.savarese.vserv.jelly;
import org.apache.commons.jelly.*;
public class GetStaticTag extends TagSupport {
private String __var;
private String __field;
private String __className;
public void setVar(String var) {
__var = var;
}
public void setField(String field) {
__field = field;
}
public void setClassName(String className) {
__className = className;
}
public void doTag(XMLOutput output) throws JellyTagException {
String message = null;
if(__var == null)
message = var;
else if(__field == null)
message = field;
else if(__className == null)
message = className;
if(message != null)
throw new MissingAttributeException(message);
try {
Class type = getClass().getClassLoader().loadClass(__className);
Object result = type.getField(__field).get(null);
JellyContext context = getContext();
context.setVariable(__var, result);
} catch(Throwable t) {
throw new JellyTagException(Could not access + __className + . +
__var + . Original exception message: +
t.getMessage(), t);
}
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE][NET] Release commons-net 1.2.1
In message [EMAIL PROTECTED], Steve Cohen writes: This will be a fix release to fix the problem introduced in 1.2.0 that it will not compile using jdk 1.4 and nothing else. Just to be procedurally correct, here's my +1 again (that way you can provide a link to the thread in the vote result). As a side comment, I think it's great that the problem was detected immediately after release (more than once apparently). It means folks actually use the stuff :) daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] minimum jdk version?
In message [EMAIL PROTECTED], Steve Cohen writes: I think a fix release is needed for this. Guys, what should the name of such a version be? 1.2.1 Are there any guidelines about releasing a fix version for such a small but vital thing? Just roll another release. Here's my +1 in advance. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE][NET] Release commons-net 1.2.0
In message [EMAIL PROTECTED], Steve Cohen writes: Where do we stand on this? Hey, you called the vote, you're supposed to know :) I have two +1s from known committers to the project, another +1 from Mario, who I don't believe is a committer on this project but may be one for some other commons projects. I believe there are three committers who haven't voted, one newly minted, and one who I rarely see active on the list. Some votes may have popped up only on the pmc list and some only on commons-dev. By my count there are five +1s: Jeffrey Brekke Steve Cohen Mario Ivankovits Daniel Savarese Davanum Srinivas At least four are PMC members, so the vote passed. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] commons-net.1.2.0-rc1
In message [EMAIL PROTECTED], Jeffrey D. Brekke writes: postgoal and pregoal allow for hooking onto goals. I think we can extend the preparation of the tar dists with postgoal/. Inside the postgoal, copy the NOTICE file into the correct directory. I'll try it soon. Thanks for the education. The only reference I can find to postGoal is a blurb in http://maven.apache.org/reference/user-guide.html#Reports of all places. If postGoal will work after dist:prepare-bin-filesystem and dist:prepare-src-filesystem, then we're set. It sounds like I criticized the plugin prematurely. Had the dist goal not been broken up into subgoals, then there'd have been a problem. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE][NET] Release commons-net 1.2.0
In message [EMAIL PROTECTED], Steve Cohen writes: The candidate release is available at http://cvs.apache.org/~scohen/ ... Please vote on this release. If the vote passes I will produce the release. +1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] commons-net.1.2.0-rc1
In message [EMAIL PROTECTED], Jeffrey D. Brekke writes:
standard stuff won't do. Or better yet, lets just put the two lines
from the NOTICE.txt into the README.txt.
We can't do that because putting it in NOTICE is required by the Apache
License. If I didn't miss anything, we're talking about is getting
NOTICE.txt into the jar and the tarball. I'm no Maven maven, but it looks
like what you have to do is add the following to project.xml:
build
resources
resource
directory${basedir}/directory
targetPathMETA-INF/targetPath
includes
includeNOTICE.txt/include
/includes
/resource
/resources
/build
That will take care of getting NOTICE.txt into the jar file. Although,
for the life of me I can't tell how the jar plugin picks up on the
resource info ... As far as getting the file into the distribution
goes, I think we're going to have to patch the dist plugin to make
it customizable and submit that to the Maven team, or just maintain our
own Commons dist plugin as Jeff suggested. The dist plugin doesn't appear
to be customizable. Of course, the Maven team will eventually add
ant:include name=NOTICE*/ to the dist plugin, but that doesn't solve
the general problem. It seems like a lot of Maven plugins should be
extensible or at least customizable so they don't force a single way of
doing things on the end user. Otherwise, you wind up having to write your
own plugins which is not exactly an efficient way to go about things when
an existing plugin already does most of what you need. Which is to say
that it's better if we add a hook to the dist plugin that allows arbitrary
files to be pulled into a distribution and ask the Maven team to apply the
patch.
daniel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] time to move to the new wiki...? [WAS Re: Commons::Net Wiki]
In message [EMAIL PROTECTED], robert burr ell donkin writes: is it time for jakarta commons to move to the new wiki...? +1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Commons::Net Wiki
In message [EMAIL PROTECTED], Rory Winston writes: well - day job permitting). I am not a committer as of yet - I do realize that you mentioned making me a committer before - what would it take to get myself on the committers list? AIUI, it's a voting process by existing committers? We just need to hold a vote and inform the PMC of the vote results. After you're voted in, you need to FAX or snail mail a CLA http://www.apache.org/licenses/#clas) to the phone/address listed on the CLA. Once that's received, we send a request to infrastructure (cc'ed to the PMC) to create an account for you with commit privileges to Jakarta Commons. Then you'll have commit access and I won't have to apply your patches anymore :) Even though I'm in a responsibility shirking mode, a call for votes will save me more time (e.g., you can apply your message threading patch) than it will cost me :) I just wish I had been following the digest more closely so I could have contributed my vote to Mario Ivankovits (not that he didn't have enough votes already). daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] Rory Winston as a Commons commiter
[ ] +1 Welcome Rory! [ ] 0 No comment. [ ] -1 Not yet, because ... Rory Winston has contributed significant functionality additions to the Commons Net NNTP package in the form of patches over the past year: http://marc.theaimsgroup.com/?l=jakarta-commons-devm=105360087319228w=2 http://marc.theaimsgroup.com/?l=jakarta-commons-devm=107460675201109w=2 http://issues.apache.org/bugzilla/show_bug.cgi?id=26282 He has also shown persistence and patience in seeing his additions incorporated, which have taken months to apply. As a committer, Rory will be able to accelerate the development of Commons Net. Please join me in casting your vote. Here's my +1 daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Commons::Net Wiki
In message [EMAIL PROTECTED], Rory Winston w rites: Whereas the new Wiki is: http://wiki.apache.org/old/CommonsNet/FrequentlyAskedQuestions I'm confused. That page is not editable (it's listed as an immutable page) and does not appear on the list of wikis at http://wiki.apache.org/ The page from nagoya has more up to date information on it. For example, it mentions that your XOVER patch was applied last year. Which is the real wiki? I found http://nagoya.apache.org/wiki/apachewiki.cgi?MigrateFromThisWiki and http://wiki.apache.org/general/UseModMigration which I guess answers the question. Commons hasn't migrated yet. This is where I should offer to send a request to infrastructure and the PMC, but I'm afraid I have to play hot potato and ask Rory to do so (are you a committer yet, if not, you should be). daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-commons/net/src/java/org/apache/commons/net/ftp/parser VMSFTPEntryParser.java
In message [EMAIL PROTECTED], [EMAIL PROTECTED] writes: FTPFile[] results; if ((socket = _openDataConnection_(FTPCommand.LIST, pathname)) == null) -return null; +return new FTPFile[0]; I don't think that's the right behavior. Maybe the old behavior wasn't the best either. The old behavior was: Returns: The list of file information contained in the current working directory. null if the list could not be obtained or if there are no files in the directory. Perhaps the combination of the old and new is best, which would return a zero-length FTPFile array if there are no files in a directory, but would return null if the list could not be obtained. The thing is that if a data connection cannot be established, I don't think you want to be left believing the directory was empty. Alternatively, an IOException could be thrown, but I'm not sure if that's necessary when the control connection is still functioning. Anyway, it's something to think about. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Incorrect documentation of FTP task [net]
In message [EMAIL PROTECTED], Dom inique Devienne writes: Probably not... I simply try to avoid having twice the same functionality on my classpath, and JDK1.4+ fulfills my regexp needs (albeit simple) just fine. I've read a few times that ORO is superior to the JDK's regexp impl, so it's not a question of merit, but simply to avoid duplication (I used java.util.regex with the REX/Shallow Parser expressions, and it worked fine, so that's good enough for me.) What I'm getting at is tht oro is not a regex engine. It is a collection of regex engines and additional text processing features. It provides generic interfaces for pattern matching. Why reinvent generic interfaces, when they are already there? So I implemented the glue last night to make that evident. I could just go all the way and add the java.util.regex wrapper and J2SE 1.4 autodetection, in which case I would hope the point would become moot since you'd have the desired functionality. Although, I'd prefer for other to get involved to at kibitz about the glue (implementing the java.util.regex wrapper is just a matter of setting aside a little time). If oro were a part of commons would this even be an issue? I think a desire for Commons Net to use a regex engine abstraction other than oro may be more of a perceptual issue than an engineering issue. I'm not suggesting Ant change it's wrapper since it's already there. It's just that Steve indicated it wasn't quite general enough for Commons Net and I already know that the code changes to Commons Net will be minimal with oro because it already uses PatternMatcher and PatternCompiler. I understand Jakarta libraries must run on many JDKs, so cannot require JDK 1.4+, but OTOH, it's annoying to have useful OS projects you're interested in pick up so many other dependencies, often for just a few convenient classes, thus using 1% of that dependency, which often has a large overlap with other libraries from the JDK or other libraries one's forced to use (thru indirect dependencies). Too true. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Incorrect documentation of FTP task [net]
In message [EMAIL PROTECTED], Steve Cohen writes: This is all true, Daniel, but I think the initial motivation of Dominique Devienne was to REMOVE the requirement that oro be on ant's runtime classpath I wrote: wrapper and J2SE 1.4 autodetection, in which case I would hope the point would become moot since you'd have the desired functionality. Although, I need to edit my email before sending ... Right, so the point wouldn't be completely moot because the concern is the dependency on external jars. The tradeoff though, in this case, is writing your own wrapper instead of using one provided by another package designed to support this. I believe promoting code reuse within Jakarta is a good thing, so you know what my recommendation is. I wrote: I think a desire for Commons Net to use a regex engine abstraction other than oro may be more of a perceptual issue than an engineering issue. Scratch that. This is really a packaging issue. That is, how to package and distribute ant tasks and their dependencies for ready use. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Incorrect documentation of FTP task [net]
In message [EMAIL PROTECTED], Steve Cohen writes:
You've built an interface to encapsulate the choice in regex implementations
with automatic checking. Sweet! Perhaps we could port it to commons-net -
...
Perhaps this checker mechanism could be ported to commons (a la
commons-logging). Then it could be available to other clients, in
particular, to commons clients. But of course then we'd be requiring yet
...
I think we ought to think seriously about what we are doing here before we
rush into coding anything like this.
*sigh* No one ever brings these things up on the oro or regexp mailing
lists. This is one of those really easy things to do with oro, which
most folks don't realize implements three different regular expression
engines. I know I promised to do the vpp-based conditional compilation
to provide a J2ME/JDK1.1 compatible version of oro, but I just haven't
found the time. This however is easy stuff. I just added two new
interfaces to org.apache.oro.text.regex: PatternMatchingEngine and
PatternCompilerOptions. I implemented these interfaces for the
Perl5, Awk, and Glob engines. I then wrote a PatternMatchingEngineFactory
class to generate engines. You can put the J2SE 1.4 detection code
in there and add an org.apache.oro.text.java package that wraps
java.util.regex. All you have to do is implement PatternMatcher,
PatternCompiler, and Pattern for J2SE 1.4. If someone will step up
to do this, I'm sure the PMC will grant commit access immediately.
I'd actually rather if all of jakarta had commit access to oro for
this very kind of situation. When you don't have commit access, there
is sometimes a tendency to reinvent the wheel.
I've appended a modified version of the grep example that shows how
you might pick an engine based on a set of preferences. At any rate,
I very much thing oro is the place for generic regular expression
engine support since it was designed with that in mind from the
start (although the pattern compilation options could have been
abstracted better at its genesis). I invite anyone and everyone to
do a checkout of the latest jakarta-oro files in CVS and start
improving my 30 minute hack.
daniel
package examples;
import java.io.*;
import java.util.*;
import org.apache.oro.text.*;
import org.apache.oro.text.regex.*;
/**
* This is a no-frills implementation of grep that demos the use of
* PatternMatchingEngineFactory to choose different
* regular expression engines. It performs case insensitive matching
* to demonstrate the use of the PatternCompilerOptions interface.
*
* @version @version@
*/
public final class engineExample {
static int _file = 0;
static final String[] _preferences = {
PatternMatchingEngineFactory.JAVA_KEY,
PatternMatchingEngineFactory.PERL5_KEY,
PatternMatchingEngineFactory.POSIX_KEY,
PatternMatchingEngineFactory.AWK_KEY,
PatternMatchingEngineFactory.GLOB_KEY
};
// args[] is declared final so that Inner Class may reference it.
public static final void main(final String[] args) {
PatternMatchingEngineFactory factory;
PatternMatchingEngine engine = null;
PatternCompiler compiler;
PatternCompilerOptions options;
PatternMatcher matcher;
MatchActionProcessor processor;
int mask;
if(args.length 2) {
System.err.println(Usage: grep pattern filename ...);
System.exit(1);
}
factory = new PatternMatchingEngineFactory();
// Demonstration of choosing engine based on preferences.
for(int i = 0; i _preferences.length; ++i) {
if(factory.containsKey(_preferences[i])) {
engine = factory.get(_preferences[i]);
break;
}
}
if(engine == null)
engine = factory.get(PatternMatchingEngineFactory.DEFAULT_KEY);
compiler = engine.createCompiler();
matcher = engine.createMatcher();
options = engine.getOptions();
mask = options.getMask(PatternCompilerOptions.CASE_INSENSITIVE);
processor = new MatchActionProcessor(compiler, matcher);
try {
if(args.length 2) {
// Print filename before line if more than one file is specified.
// Rely on file to point to current file being processed.
processor.addAction(args[0], mask, new MatchAction() {
public void processMatch(MatchActionInfo info) {
info.output.println(args[_file] + : + info.line);
}
});
} else {
// We rely on the default action of printing matched
// lines to the given OutputStream
processor.addAction(args[0], mask);
}
for(_file = 1; _file args.length; _file++)
processor.processMatches(new FileInputStream(args[_file]), System.out);
} catch(MalformedPatternException e) {
System.err.println(Bad pattern.);
e.printStackTrace();
System.exit(1);
} catch(IOException e) {
System.err.println(Error opening or reading + args[_file]);
e.printStackTrace();
System.exit(1);
}
}
Re: [net] JDK 1.1 question
In message [EMAIL PROTECTED], Steve Cohen writes: Question - primarily for Daniel: Do you think it makes sense to dial back to using jakarta-oro-2.0.1 in commons-net.1.1.1 to preserve JDK 1.1. compatibility? What features/bug fixes would be lost? Unless we either do this or rewrite, we don't have a version that works under 1.1. There's a pile of email I have to go through. Sorry if there are more pending questions that you think I should weigh in on. I think the right thing here is to release a jakarat-oro 2.0.9 release that uses conditional compilation to support multiple JVMs. That's been on the drawing board for a long time (primarily to produce a version for J2ME), but there's been little impetus to move it forward (some users have been hacking the code on their own because the changes are so few to make). Now there is. Since oro doesn't ship with Commons Net (or does it?) and as far as I know Commons Net does not rely on any part of the API that may have been perturbed between 2.0.1 and 2.0.8, a note in the documentation for JDK 1.1 users to use 2.0.1 until 2.0.9 is out should suffice I would think. Was there ever a JDK 1.1 version of the Collections API released the way there was a 1.1 version of Swing? That's another route. Anyway, if oro ships with Commons Net, use 2.0.1 and then we can do a 1.1.2 release that uses 2.0.9. I'd like to see all Jakarta committers have access to all Jakarta code bases. But since that's not currently the case, if we can get some more Commons committers access to oro it may help resolve things like this more quickly. I'll do my best to take care of it this weekend, but it may be another week. The original idea was to use vpp (actually, vpp was written in part to solve our conditional compilation problem), so this may be the time to mavenize oro so vpp is pulled down automatically. Anyway, that's just to say that most of the work will actually involve redoing the build process than inserting the conditional code. Don't forget to vote on the 2.0.9 release thread since you should be on the PMC by then. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net][vote]Steve Cohen to manage release of v1.2.0 of commons.net
In message [EMAIL PROTECTED], Jeffrey D. Brekke writes: I think any committer could be the release manager, +1. I haven't had time to look at the code changes deeply. Based on what I've seen and what was discussed, I'm +0 on the release of 1.2.0, but I do think that a jdk 1.1 compatible version release at the same time, if not before 1.2.0, should be considered. I'm in a real time bind right now and have not read all of the emails related to Commons Net, although I've got them saved up for later examination (I noticed Rory Winston submitted more NNTP enhancements; we should discuss voting him as a committer after we get past the immediate business). If a vote is needed for a release manager, I assumed my vote was implicit based on my earlier comments. Here's an explicit +1 for Steve to manage the release. I haven't had time to look at the most recent changes. I was +1 on a 1.2 release to acommodate Ant's release schedule based on the changes up to Steve's take on resolving the VMS parser situation, even though I believed we'd have to deprecate some of the stuff later. I'd rather err on the side of being user-driven and meeting user needs than insist on perfection. However, additional changes were made that I haven't had time to examine (Steve's refactoring) and I believe will require more time to discuss. So if I have to vote right now I'm: +1 on a 1.2 release if we don't include those latest changes +0 if we do I'm also +1 on the JDK 1.1 compatible 1.1.1 maintenance release. I think we've got three +1's on this one (scohen, jbrekke, dfs), so all that's needed is to start a vote thread with a release plan specifying the release criteria (i.e., remove JDK 1.1 incompatibilities in the 1.1 release) cc'ed to the PMC and giving anyone an opportunity to -1 it. I tried to anticipate and qualify what I could since I'm lagging behind on email and may not be able to respond in a timely manner over the next week. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] Solved VMS duplicates problem and simplified system
In message [EMAIL PROTECTED], steve cohen writes: Oops! CVS doesn't have undelete, does it? :-( Sorry for not knowing/understanding this rule. Do we add it back in (losing history) or is there some way to put that back as well? What is best way to proceed? It looks like you already took care of it. But it should extend FTPFileEntryParserImpl so we don't have duplicate code. I don't know if you're still making changes, so I don't want to mess with anything. But I think these names confused you. At least that's the way it looked to me. The iteration that was needed was over the Vector of raw input in FTPFileList. When I saw you specializing FTPFileIterator, which walks raw input but returns cooked equivalents, I knew you had gone down a wrong No, I just didn't explain myself clearly enough. I was concentrating on teasing out the interfaces. The implementation didn't matter as long as the proper behavior was preserved. That's why I just shuffled code around without actually reimplementing any of it. A subsequent step would be to optimize the specialized iterator so it would incrementally work off of the raw input lines. However, the approach would be through subclassing and making some members of what I called DefaultFTPFileList protected instead of package scoped or private. I still think the changes you made are too application-specific. FTPFileList preParse(FTPFileList) is entirely motivated by the VMS problem and I don't see it holding up to software evolution demands. The need to continue exposing implementation details through methods like getInternalIteratorForFtpFileList (should be getInternalIteratorForFTPFileList to maintain consistent naming) is evidence of an architectural flaw. If we continue to violate data encapsulation, favoring customization through exposure of private data instead of through inheritance, we're going to make the software more difficult to maintain. path. I'm not against abstracting some of these classes. It's probably a good idea and once we have it, further beneficial refactorings will no doubt suggest themselves, but I think that is for 2.0. I disagree. I think the time to fix this is now. Otherwise, we're just adding more methods that we're going to have to deprecate. That said, this affects us more right now than it affects users. It's not like there's a huge amount of user code dependent on the list parsing classes. Most users use what we already provide. Anyway, I know I still haven't expressed myself as clearly as I could (time constraints), but I'd like to fix up my suggested changes to something closer to what I'm ultimately trying to propose in order to make it more clear. Rather than work on what's in CVS, I'll just post the changes for download later this week after I free up some time. Some things are just more clear when looking at examples. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] 1.2 release (Re: [net] checked in parser factory implementation)
In message [EMAIL PROTECTED], steve cohen writes: I also agree that there is a need for postfiltering (to solve the most recent version only problem), although, actually, I think prefiltering out the dupes may be the way to go. Either way, some kind of hook will be necessary, one that's a no-op in the default case. If time gets to be a factor we can leave this as a known issue for later. No one's actually complained about it other than me, from reading the code. I went ahead and made the changes I had put out for discussion (see comments in CVS commit log). It seemed easier to make them and let you improve on them or revert them. There should be no impact on existing code. However, I had to introduce createFTPFileList into the FTPFileEntryParser interface. I don't like the name of this method. It's basically an FTPFileList version of parserFileList. If we keep this change, we should ome up with a more appropriate name. There are some things I didn't understand in FTPFileListIterator (now an abstract class with DefaultFTPFileListIterator containing the implementation code). Is getNext(0) supposed to return all remaining elements and getPrevious(0) all elements between 0 and the current position? Also, FTPFileList.getFiles() (now DefaultFTPFileList.getFiles() with FTPFileList being an abstract class) was returning iterator().getNext(0). I changed this to iterator().getFiles(), which was less confusing to me. But it seems that getFiles() actually does something different than getNext(0), reinitializing the current position. Is there something that needs to be fixed there? I didn't want to change anything there. Please doublecheck VMSFTPEntryParser.DuplicateFilteringIterator to ensure it implements the getNext() and getPrevious() methods as intended. I included little comments saying how I interpreted the 0 argument. I didn't fix up all affected javadocs (too late, too tired). I also didn't split out VMSFTPEntryParser into two classes, but that should be easy for anyone else to do. Basically, all I did was shuffle code around to make user customization easier. The only new code I wrote were a couple of methods in DuplicateFilteringIterator, but it really just grafts part of the old parseFileList which is now split between DuplicateFilteringIterator and createFTPFileList(). daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] 1.2 release (Re: [net] checked in parser factory implementation)
In message [EMAIL PROTECTED], steve cohen writes: I keep coming back to the ant use case and how we'd handle it there. I suppose we could add yet another parameter to the ant ftp task to handle this odd case, but I'd rather not. I'm still not happy with this but I don't have a better suggestion yet. Okay, so am I correct that in ant you can explictly define the parser key? If that's the case then one can implement a factory that recognizes a special parser key (or add it to the default factory), like VMSV that will create a VMS entry parser which handles versioning. That is, assuming the ant task calls listFiles(String, String), which is what I understood to be the reason you gave to keep the method public when Jeffrey suggested it not be public. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] 1.2 release (Re: [net] checked in parser factory implementation)
In message [EMAIL PROTECTED], Jeffrey D. Brekke writes: [Alternatives to VMS Parser/Version issue] Another alternative is to create another parser, creating two VMS parsers, potentially sub-classing one VMS parser to avoid code duplication. A specialized VMS parser that will filter off multiple versions. This solves the contract problems with the parsers and I was about to say Eureka!, that's the right solution. as far as the specific VMS parser case goes, but there's still the problem of how to make it filter off multiple versions when called using readNextEntry and parseFTPEntry. Unless I'm missing something, we still have to support some hook for the postfiltering. Nonetheless, splitting the VMS parsing functionality into two separate classes (one derived from the other) is cleaner than using the versioning property. [FTPClient API coherence] On the point of the FTPClient api, I was under the impression also that we were leaning toward a FTPFileList as the norm, and away from the arrays. Maybe now that we're 1.2 bound, we can just return List and have FTPFileList implement the List interface ( and Iterator interface, opening up the possibility of using commons/collections filter iterator or other collection utilities )? I see Steven and you have made further comments in the thread about this. I'm in favor of whatever provides sufficient flexibility so that API users can customize behavior without requiring us to shoehorn application-specific functionality into the library. I'm not sure about having FTPFileList implement List, or perhaps Collection, but I haven't sorted out my thoughts. There could be considerable advantages. Also, one of the possibilities I threw out was having void listFiles(FTPFileList, ...), where the results are returned in the FTPFileList, which would require at least clear() and possibly add() methods depending on the implementation. I guess we're spiraling out of control here with ideas ( not necessarily a bad thing ). Just not sure how to rein us in ;) Although I don't want to put off decisions, we can always take a baby step to resolve the immediate VMS entry parser issue and take some more time to figure out the rest. That is, unless they are inextricably tied ... We've got several options for allowing ant to grab a VMS entry parser with version filtering. I think we've agreed that splitting out the functionality into a subclass is the way to go. But we still need a way to implement the version filtering transparently without depending on parseFileList. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] checked in parser factory implementation
In message [EMAIL PROTECTED], steve cohen writes: 1) deprecate listFiles() methods that take a FileEntryParser parameter. 2) reimplement listFiles() to do what getFileList(null) now does. 3) reimplement listFiles(String pathname) to do what getFileList(null, pathname) now does. 4) rename getFileList(String parserKey, String pathname) to listFiles(String parserKey, String pathname). Even though autodetection will be the primary use case, it already will not work for every system (see EnterpriseUnix) and there must be some way around it. This is that way. 5) don't use properties to select the parser factory in our library. Instead, add a property and a setter method. Initialize in the library to use the default. Have I missed anything? Yes, that's exactly what I was suggesting. It also occurred to me later that we may want to cache the system name in getSystemName (save it on the first call, return it on subsequent calls, clear it on disconnect), since it will be called more frequently now that you've added autodetection. One problem remains. getFileList() throws a new exception: ParserInitializationException. If we simply rename these methods to listFiles() we will break lots of code. That was my primary reason for giving them a different name. One way around this would be to make ParserInitializationException a RuntimeException. That makes sense, as the error is not recoverable and is always due to a programming error - passing in a key that the system cannot parse, specifying a class that has not been made available. Would you agree? Another choice is to make it extend IOException, but that doesn't seem right. I guess my preference would be to catch the exception in listFiles() and rethrow an IOException that bubbles up the original exception. The problem with that is that standard support for wrapping exceptions is present only in J2SE 1.4. Also, what's the real difference between adding an FTPFileListException (or whatever name) derived from IOException and throwing that instead of just letting a ParserInitializationException derived from RuntimeException pass through. The reason I'm conflicted is that it doesn't seem to me that the caller of listFiles should be bothered to know about the internal implementation of the method, which the throwing of ParserInitializationException requires. If we make ParserInitializationException a RuntimeException we can always go with the catch and throw later. Still, I'm wondering if FTPFileEntryParserFactory should have a boolean isRecognized(String key) method or something similar to avoid the expense of a try/catch block (i.e., you ensure a key is supported before calling createFileEntryParser, and throw an FTPSystemNotSupportedException or something). I'm also wondering a good number of other things (like how to avoid new FooEntryParser() in createFileEntryParser on every call to listFiles), so I'll stop now and say that I support your suggestion to make ParserInitializationException a RuntimeException. It doesn't preclude additional tweaks we may think of before a final release. in Effective Java lays this out clearly enough. If it was called PreconditionViolationException or some such, it would be much clearer. As it is, I've seen too many instance of exceptions being made RuntimeExceptions simply because the programmer thought that propagating it up though the call stack was too difficult. But I don't think that's the case here. This is legitimately a RuntimeException). I agree, but it depends on how you anticipate the method being used. An argument can be made for createFileEntryParser to not throw an exception and instead return null. I wouldn't advocate that here because we're talking about a factory which creates new objects and not a mapper that pairs keys with pre-existing objects. Agree here too, although the idea that FTPFileListParserImpl will no longer implement FTPFileListParser is extremely odd. I suggest we might want rename this class now to FTPFileEntryParserImpl. As it's abstract, I don't think we'd be impacting anyone. That sounds like the right thing to do. So I guess we also deprecate FTPFileListParserImpl? daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] 1.2 release (Re: [net] checked in parser factory implementation)
In message [EMAIL PROTECTED], Daniel F. Savar ese writes: I forgot to add that I think we need a beta release for 1.2 to give us I also forgot to add that there's at least one pending code submission/patch that we need to review and include before a 1.2 release. I believe it was the NTP/SNTP functionality submitted by Jason Matthews. We may need a signed CLA before we can include it should it pass muster. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] 1.2 release (Re: [net] checked in parser factory implementation)
In message [EMAIL PROTECTED], steve cohen writes: There's still one problem with deprecating FTPFileListParser. The one method of this interface (parseFileList()) is used in the VMSFTPEntryParser. There is an implementation here that is distinct from the default one in FTPFileListParserImpl. ... If we still want to deprecate FTPFileListParser, I would recommend, then, that we move parseFileList() into the FTPFileEntryParser interface. However, I wanted to throw this question out there for general comment before I do that. In one of my emails I started writing I'm not entirely convinced we need to deprecate FTPFileListParser ... but I couldn't really support that so I deleted that thought. You nailed the case where it makes a difference. The question remains though, how do we support this when the only way parseFileList is called is in listFiles(FTPFileListParser, ...), which we're deprecating and going to remove? I don't think we want the API user to have to be intimate with the different parsers and figure out when to call listFiles(FTPFileListParser, ...) and when not to. Moving parseFileList into FTPFileEntryParser won't solve the problem unless we make parseFileList the single entry point to creating file lists from FTPClient (since all of the FTPFileEntryParser implementations we have so far implement parseFileList). Looking at the code, I would have to agree that parseFileList should be preserved and move into FTPFileEntryParser. That allows us to rewrite createFileList to call parseFileList instead of FTPFileList.create, which allows the VMSFTPEntryParser to continue doing its thing. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] 1.2 release (Re: [net] checked in parser factory implementation)
I wrote: Looking at the code, I would have to agree that parseFileList should be preserved and move into FTPFileEntryParser. That allows us to rewrite createFileList to call parseFileList instead of FTPFileList.create, which allows the VMSFTPEntryParser to continue doing its thing. Scratch that. I didn't realize how FTPFileList worked and where it was used. There may be a fundamental incompatibility here. In any case, I tested deprecating FTPFileListParser and adding the parseFileList method to FTPFileEntryParser. It doesn't cause any compilation or runtime problems. So that's a viable migration path. The problem that remains is in how to invoke parseFileList() when required (i.e., for VMSFTPEntryParser). The whole point of FTPFileList and FTPFileEntryParser was to perform incremental parsing, but parseFileList requires parsing of the entire input in advance. One way out of this is to add a boolean requiresEntireStream or similar method to FTPFileEntryParser, which FTPFileList can use to decide whether to call parseFileList, but that invites other kluges because FTPEntryParser implementations implement parseFileList by creating an FTPFileList in turn. I don't have a suggestion about this right now. Another question is whether we should encourage the use of FTPFileList over FTPFile[] for iterating over file listings. I thought that's where we were headed with Steve's code. Wouldn't that suggest we should deprecate FTPClient.createFileList and replace it with FTPFileList listFiles? We can get away with that because the createFileList methods have diferent signatures from the existing listFiles methods. But wouldn't we want to replace the existing FTPFile[] listFiles methods with ones that return FTPFileList? Alternatively, FTPFileList could be passed as a reference parameter to a void method (e.g., void listFiles(String pathname, FTPFileList list)), which would require a couple of modifications in FTPFileList, but would have the benefit of allowing the reuse of FTPFileList objects without creating garbage. Or is there no real gain to be had down that road? daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] 1.2 release (Re: [net] checked in parser factory implementation)
In message [EMAIL PROTECTED], steve cohen writes: Except for the issue outlined below (re FTPFileListParser deprecation) my latest commit have implemented everything that Daniel discussed earlier today: Great! I added caching of the system name to avoid issuing SYST to the server for every listing. I also cached the entry parser to avoid creating a new one on every listing. Those changes assume the value of SYST never changes during the lifetime of an FTP session. If anyone knows that to be an invalid assumption, please say let us know so we can back out the optimization. Once we have agreement on what to do about FTPFileListParser, I can make those I jumped the gun and deprecated FTPFileListParser and copied parseFileList to FTPFileEntryParser. It doesn't break anything and it's the direction we seemed to be headed in based on the current state of the discussion. We can always back it out if need be. I also deleted all of the code in DefaultFTPFileListParser and changed the class to extend UnixFTPEntryParser, adding a note indicating the class would be removed in version 2.0. That should take care of the maintenance issue Jeffrey raised while preserving a smooth migration. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] 1.2 release (Re: [net] checked in parser factory implementation)
In message [EMAIL PROTECTED], steve cohen writes: After looking at the code, I have a different idea. Reimplementing createFileList() in terms of parseFileList() would negate the whole reason for inventing createFileList() in the first place - your suggestion wishing Agreed. I'm lagging behind the discussions because of the digest, so I said some stupid things :) VMSFileEntryParser.parseFTPEntry(). A duplicate entry could return null or else a special value (public static final FTPFile DUPLICATE_ENTRY = new FTPFile();). FTPFileIterator would skip all such instances. The only other thing needed would be a new method in FTPFileEntryParser to reinitialize this cache. The default implementation of this in FTPFileEntryParserImpl would be a no-op but the VMS case there would actually be a cache to empty. I also considered that VMSFileEntryParser could manage the removal of duplicates itself, except I saw the need to demarcate the start (and possibly stop) of a listing as a showstopper. It seemed like a special case just for VMSFileEntryParser, in the same way the createIterator idea I suggested seems. I think what we have to discover is the most appropriate general case that encompasses the situation we face with VMSFileEntryParser. If we build special support into FTPFileIterator for handling duplicates, we don't gain any additional flexibility. That's why I favor a way of implementing Jeffrey's iterator filter/adapter idea with as little impact to existing code as possible. It gives additional flexibilty. However, that doesn't mean we don't also need a way to allow entry parsers to maintain state while the parsing of a file listing is in progress. Whether that should be done by adding a new method (indicating the start of a listing; where the cache could be initialized) or an extra parameters to parseFTPEntry (e.g., an integer indicating the number of the entry; 0 indicates the first entry) I don't know. A startListing() or similar method is probably the more flexible approach if we decide that's necessary. I'm of the mind we've run into an architectural weakness and have to rethink how FTPFileList, FTPFileIterator, FTPFileEntryParser, and FTPClient should interact. Right now, we don't have a clear path for extending/customizing FTPFileList and FTPFileIterator behavior as it relates to FTPFileEntryParser instances. Granted, we have only this one case with VMSFileEntryParser to consider, but there may be others lurking around the corner we need to anticipate. I think FTPFileEntryParser is the key to customization. All of our problems would be solved if instead of a static FTPFileList.create method, there were a per-instance FTPFileList createFileList method in FTPFileEntryParser. Although, in that case it would help for FTPFileList to be an interface. Since FTPFileList has a private constructor and API users can only create instances with create(), maybe we can make FTPFileList an abstract class without breaking anything and move the current implementation into a subclass. FTPClient would use the parser createFileList method and VMSFileEntryParser would return an FTPFileList subclass that did the right thing, either by producing a filtering iterator derived from FTPFileIterator or by redefining the way the stream is read. I'm not saying this is the best way to go, but it does offer more flexibility than either of our previous suggestions without breaking anything. At any rate, it's another idea to throw into the pot. Let's brainstorm some more and make a list of pros and cons. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] 1.2 release (Re: [net] checked in parser factory implementation)
In message [EMAIL PROTECTED], steve cohen writes:
Almost right, Daniel. I think it filters out dupes when versioning is turned
on.
I thought that's what you said before, but I saw
if (versioning) {
files = super.parseFileList(listingStream);
} else {
in VMSFTPEntryParser.parseFileList. Is that an error? Should it
be if (!versioning) or do I have the meaning of the versioning
variable mixed up? Just wondering if we found a bug.
Actually, I like your suggestion. The iterator seems the right place to do
it.
As you know by now from my subsequent email, I have yet another suggestion :)
Here's another problem, though, in our system. How do you turn versioning on
in the auto-detect scenario? There's no hook in listFiles() for doing so.
I would say that's where the FTPFileEntryParserFactory comes in. If
someone wants VMSFTPEntryParsers with versioning turned on, they
can implement a factory that returns them. We could add a
setVMSVersioning(boolean) method to DefaultFTPFileEntryParserFactory
and save users the trouble. They'd have to do the following:
FTPClient ftp = new FTPClient();
DefaultFTPFileEntryParserFactory factory =
new DefaultFTPFileEntryParserFactory();
factory.setVMSVersioning(true);
ftp.setParserFactory(factory);
Does that sound acceptable or is there a better way?
daniel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] checked in parser factory implementation
In message [EMAIL PROTECTED], steve cohen writes: Problem is, the current implementations of FTPFileEntryParser, also, for reasons of backward compatibility, implement FTPFileListParser. I don't remember exactly why I did that but there was a reason. But the problem is that deprecating FTPFileListParser will deprecate every parser currently in the package. I don't have a comment on this one yet as I have to look at the code in more detail. I'm in favor of deprecating the old stuff, but figuring out the right way to do it isn't immediately obvious. (Actually, scratch that, now that I've finished writing this email, I have comments at the end). parser and specification of parser either by classname or key (UNIX, VMS, etc.) will go a long way to making this easier to deal with. The key is to now use the new FTPClient.getFileList() methods in place of FTPClient.listFiles(). They can use the autodetect feature and never get near the question of which parser interface to use. Even if specifying by key, all these internals are handled for them. It really should be lots better. If anything needs deprecation at this point, I would say it might be FTPClient.listFiles(). I disagree slightly (it's actually agreement, but with a naming difference) and have some suggested code changes (I can make them if there's agreement). First, the getFileList methods should be named listFiles() as that's what they're replacing. We can deprecate the old listFile methods that take FTPFileListParser arguments and reimplement listFiles() and listFiles(String pathname) in terms of the new stuff using autodection (removing getFileList(String parserKey) since the signatures conflict and the common case will be to use autodetection anyway). Second, we shouldn't create an FTPFileListParserFactory on every call to getFileList. Instead, FTPClient should maintain a reference to an FTPFileEntryParserFactory. This reference should be configurable by the user with a setter method. That allows API users to change the factory implementation. Third, we shouldn't set the default factory based on a property. Once we add the setter method, there is no need for the property. In general, it's better to let applications handle their configuration through properties and leave the library free of dependencies on property values. Which factory to use is an application-level decision (e.g., an ant task can define a property that changes the factory for its purposes), not a library-level decision. Jeffrey Brekke writes: list parsers, and/or implementing the existing list parsers with an implementation that uses the entry parsers. That way we are parsing with one implementation? That should be probably be our first step toward deprecation so the parsers behave consistently. In the 1.2 release we can deprecate the old listFiles methods presuming we agree to keep the method name for the files (the class method names currently mirror as closely as possible the FTP commands they implement). We're stuck by the Commons versioning/release rules regarding when we can remove the old stuff. It has to stay in all of the 1.x releases. Otherwise, I'd say that in 1.2 we announce that in 1.3 FTPFileListParserImpl will no longer implement FTPFileListParser and deprecate the interface in 1.2, removing it in 1.4 along with the old listFiles() methods. We'll just have to wait until 2.0. I just tested it, and if we deprecate FTPFileListParser now, it only affects the javadocs for FTPFileListParser. I think we can live with any compiler warnings saying that you're using a deprecated interface as long as we document this. With a J2SE 1.4 compile, you only get warnings for the listFiles methods, DefaultFTPFileLister (which we also need to deprecate), and FTPFileListParserImpl, but none of the FTPFileListParserImpl subclasses. So I propose deprecation in 1.2 and removal in 2.0. I'd also like to tweak the build files before a 1.2 release because, given our limited free time, it's excessive to trigger unit tests every time you build the javadocs since the unit tests don't test anything in the javadocs. It's just that the unit tests take much so long on my development box (I'm still using sub-1GHz processors), I need a way to bypass them when it's not necessary to run them. It's a tradeoff between productivity and comprehensiveness. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[net] 1.2 release (Re: [net] checked in parser factory implementation)
I forgot to add that I think we need a beta release for 1.2 to give us a chance to back out or fix anything that we discover is suboptimal before we set the stuff in stone in the API. Mostly I'm thinking of method signatures. Anyway, to recap the proposed deprecation list: interfaces: FTPFileListParser classes: DefaultFTPFileListParser methods: FTPClient.listFiles(FTPFileListParser, String) FTPClient.listFiles(FTPFileListParser) Did I miss anything? daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] Let's get rid of org.apache.commons.net.ftp.ftp2
In message [EMAIL PROTECTED], steve cohen writes: On the fresh checkout I did, there was an ftp2 directory but it was empty. Is that another reason to get away from CVS - that it's too hard to get rid of directories? Yep. CVS doesn't treat directories the same as files. I have -P flags next to update and checkout in my .cvsrc which prevents empty directories from being checked out. The only problem with doing that is that sometimes empty directories are meant to be checked out and don't signify an old removed directory. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] Branching
In message [EMAIL PROTECTED], Jeffrey D. Brekke writes: Daniel, I agree with all your ideas, but it seems to me you can branch from any tagged point in the revision history so I'm not sure what the idea is behind deleting/renaming the tags. All I was getting at was what to name the tag. My understanding was that a tag needs to be created as a branch. I should have used a concrete example. I was asking which of: cvs rtag -b -r NET_1_0_0 NET_1_1_0_MAINTENANCE jakarta-commons/net or cvs rtag -b -r NET_1_0_0 NET_FOO jakarta-commons/net cvs rtag -d NET_1_0_0 jakarta-commons/net cvs rtag -b -r NET_FOO NET_1_0_0 jakarta-commons/net cvs rtag -d NET_FOO we wanted to go with (NET_1_1_0_MAINTENANCE is just for example purposes; any other name indicating it's a branch will do). As Noel said, this stuff is easier with Subversion. Given that, as per Steve's message, we can make 1.1 compatibilty changes on HEAD, release and tag, and branch from that point in the future when/if there are bug fixes required? +1. That's easier and avoids the issue altogether. I guess we'd make NET_1_1_1 a branch tag in that case. I've got JDK 1.1.8v1 lying around on my development server if you want me to hunt for and correct any other 1.1 incompatibilities. Otherwise, if Steve's game, he could do it pretty quickly and get on with his work. I won't be back home until tomorrow afternoon and my currently erratic email polling combined with my being subscribed to the mailing list digest means I won't be able to act on anything until tomorrow afternoon. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Next Steps - WAS Re: [net] VMSFTPEntryParser bug?
In message [EMAIL PROTECTED], steve cohen writes: Seems to me the HashMap --- Hashtable change could be made against HEAD. It's only NECESSARY for 1.1 compatibility but it poses no great problem for a 1.2 compatible version; it isn't as if this would impact some functionality deep in the core of the product. So after this is done, a NET_1_1_1 tag could be created and that could be the final of this branch. +1; same as Jeffrey suggested. On the other hand, if there are other 1.1 incompatibilities we may want to fix those too, and then this might get a little problematical. Hey, Jeffrey, do you know if there's an easy way to make Maven do a JDK 1.1 compile? Or would it be easier to just tinker with the generated ant script? +1 to fixing all 1.1 incompatibilities before branching. I skipped ahead in the thread and see Jeffrey already answered how to run compile for 1.1 with Maven. On the subject of the pluggable parser factory, I'm not sure I see the need, but it's easy enough to do it that way, so I will make the change. Am I If there really isn't a need, don't do it. I just thought users may need to be able to customize the method used to determine which parser is returned. I thought it would become an issue when you started writing code that created parsers using the static factory method. correct in assuming that in your plan there would be a default implementation, with other factories being selectable instead on the basis of a property? I figured an automatic detector would accept a parser factory as an argument in either a constructor or detection method. The default constructor or default no-argument method would use a default implementation (whatever you were writing for the static method). That users could provide their own factories for systems we haven't anticipated. Probably they'd just subclass the default implementation, override the factory method, provide their own detection code for the systems they care about that we don't handle, and delegate to the superclass method anything else. Alternatively, there may be situations where they want to implement something from scratch, in which case they would just implement the interface. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Next Steps - WAS Re: [net] VMSFTPEntryParser bug?
In message [EMAIL PROTECTED], steve cohen writes: This code was calling a method in ORO that returned a Collection, also not JDK1.1 compatible. Since the older ORO method that returned a Vector had been deprecated, I looked at what it was doing, which was simply splitting a string on a comma. This was an overkill use of ORO, easily replicated with a StringTokenizer. Oh yeah, it's way better to use StringTokenizer when you're splitting on just a constant string rather than an actual regular expression. However, if there's anything that doesn't work in 1.1 because of ORO, I can get off of my ass and finally do the multi-version compilation support we'd talked about on oro-dev. We wanted to use conditional compilation to simultaneously support J2ME, J2SE 1.2, and J2SE 1.4. J2ME support effectively makes it JDK 1.1 compatible, so we could also throw in a JDK 1.1 target. The changes are minor; the equivalent of a few ifdefs. But it keeps J2ME folks from having to make the changes themselves and will take care of any Commons Net users who complain about Net breaking on JDK 1.1 because of ORO. At any rate, if the ORO dependency is the only thing preventing 1.1 compatibility I can take care of that over the next week. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] Tag NET_1_1_1 created
In message [EMAIL PROTECTED], steve cohen writes: On Thursday 01 January 2004 04:17 pm, Jeffrey D. Brekke wrote: Should we roll out a release of this version? +1. We clearly have lazy consensus, but we need a formal vote cc'ed to the PMC list for all to be kosher. I guess so. It should be billed as the last JDK-1.1-compatible version. Yep, but should we indicate a willingness to backport bug fixes when requested for say the next 6 months? I am more interested in the next version - the one that will have the parser factory. When that is out, I will be able to take it to the ant folks as part of the fix to solve their inability to connect to non-unix ftp servers. Now that you've tagged the code keep on working on the new stuff while you've got the time. Jeffrey or I can handle the release management for 1.1.1 so you can seize your window of opportunity to code. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ready for promotion? Was: [io] release plans?
In message [EMAIL PROTECTED], Hen ri Yandell writes: What do people think about calling a vote for promotion out of the sandbox now? +1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] Branching
In message [EMAIL PROTECTED], Martin Cooper writes: On Fri, 2 Jan 2004, Daniel F. Savarese wrote: All I was getting at was what to name the tag. My understanding was that a tag needs to be created as a branch. I should have used ... to point out that there are two distinct types of tags in CVS. Branches affect future commits, and are harder to change your mind about after the In the context of the discussion, I should have said either that the tag (meaning the tag we were talking about) or that a branch tag (meaning any branch tag) needs to be created as a branch (meaning using -b). Without my saying that, it does sound like I'm saying the wrong thing. Anyway, there's no harm (and probably some help, given my lack of clarity) in your clarifying it and I may still be wrong about the roundabout way of changing a label to a branch being the only way to use an existing CVS non-branch tag as a branch tag. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] Let's get rid of org.apache.commons.net.ftp.ftp2
In message [EMAIL PROTECTED], steve cohen writes: Is there a recommended way to go about this? It was doubtful to me that anyone had ever used these packages, but I now see that I was wrong. Someone went and implemented an AIXFTPEntryParser in the ftp2.parser package (and not on the main stem). So I would be in favor of moving this class onto the main stem and deprecating everything in ftp2. Definitely +1 on this, but it's already been done. You must have an old checkout that you're doing cvs updates on. It's a good thing too since you wouldn't have caught the AIXFTPEntryParser sitting there. We ought to look at the log entries and see if it was subsumed by the functionality in one of the other parsers. In any case, everything in ftp2/ and ftp/parser/ is in the Attic/ in the CVS repository, so when you do a fresh checkout, the directories will be empty. My .cvsrc adds -P to checkout and update (doesn't checkout empty directories), so I didn't know what you were talking about at first. Okay, scratch what I just said. I see, you're talking about what's in the proposal directory. Yeah, definitely get rid of proposal/ftp2. The way to do it is to delete the files and do cvs removes. After looking at the log entry for AIXFTPEntryParser, I see I added it: revision 1.1 date: 2003/01/28 18:53:04; author: dfs; state: Exp; Added AIX listing parser from Brett Smith brett at bml.uk.com. That was in the 1.0 release, before the proposal was moved into the ftp package. The files in src/java/org/apache/commons/net/ftp/parser were added later and first appear in the 1.1 release candidate. So AIXFTPEntryParser didn't get copied from the proposal directory for some reason. I'm not in the best position to do the detective work on this right now, but can look at it tomorrow night if you don't have time to figure out if AIXFTPEntryParser functionality is already provided by another entry parser or if we just missed it when migrating the entry parsers. I suppose the proposal directory is another possibility I hadn't considered for doing work on a java.nio version of the code. In these [net] threads, I think we've pretty much made the case for switching to Subversion sooner rather than later. Subversion is close to a 1.0 release and I believe they've stopped modifying the database schema, so the question will become whether all of Jakarta Commons should move to Subversion at once or piecemeal and when. But that's a subject for a different thread. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AIXFTPEntryParser
In message [EMAIL PROTECTED], steve cohen writes: In looking over the source to AIXFTPEntryParser, I see the following comment, apparently from the author, ([EMAIL PROTECTED]): It sounds like you're already doing the detective work, so I'll leave it to you. I seriously must wonder if this is a distinction between AIX and Unix or whether instead what we are looking at is not a locale-specific variation in how dates are rendered. Might there be unix ftp systems in European locales that show the dates as dd-MM- and AIX systems in the US that use MM-dd-? If that is the case, then the naming of these classes is problematical. It sounds like these variations can all be handled by one class. The locale stuff should be configurable and in the short term, the special case of dd-MM- vis a vis MM-dd- can be handled by a modified regular expression and an if statement or two. If that's the only difference between AIXFTPEntryParser and UnixFTPEntryParser, then it's my fault for having added the code submission instead of incorporating the functionality into UnixFTPEntryParser. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] VMSFTPEntryParser bug?
In message [EMAIL PROTECTED], Steve Cohen writes: But what about my point that what we have now is NOT 1.1 compatible? VMSFTPEntryParser broke that, although it could, if necessary, be reimplemented to use Hashtable instead of HashMap. I misread your email (unfortunately an increasingly common experience given the volume of email I have to skim). I thought you said the unit test wasn't 1.1 compatible. Given that the 1.1 release was supposed to be 1.1 compatible, I'm in favor of replacing the HashMap with a Hashtable in a 1.1.1 release and doing a JDK 1.1 build to spot any other compatibility problems. After that, I say we branch the code. Without selectable I/O, we're forced to use inefficient kluges. The guts of the telnet implementation is an abomination, which I wouldn't be too concerned about except that it underpins the FTPClient command conversation. There was some discussion about mandating 1.3, but that met resistance from some. Let alone 1.4. That was a non-starter, as we've already heard from several users here on the other thread. I don't think it's a non-starter. As long as we give advance warning about how the transition is being handled. Say we branch and commit to making bug fixes on the 1.1 tree for x number of month. Since ant is J2SE 1.2 dependent, we ought not move to 1.3 (what do we really gain from 1.3 anyway?). We can plan a series of 1.2 compatible releases for some pre-announced period of time all the while working on a J2SE 1.4 dependent 2.0 release on an experimental code branch. I know it makes maintenance more difficult, but the code is showing its age and not making an attempt to reimplement using java.nio is selling users short in the long run. I'm willing to take the initiative on the experimental or proposal branch. Are there any users of Commons-Net who need 1.1 compatibility? (Remember NetComponents is still available). Available as a courtesy, but unsupported. We'll find out soon enough if anyone still needs JDK 1.1 compatibility if we migrate to 1.2 and announce no new features for 1.1.x releases and only bug fixes for those who request them. To summarize, I now believe the stepping stones should be J2SE 1.2 and then 1.4. J2SE 1.2 compatibility for releases 1.2.x - 1.9.x on the head branch and J2SE 1.4 for release 2.0 on an experimental branch. JDK 1.1 compatibility for 1.1.x releases on a 1.1 maintenance branch. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Moving up to JVM 1.4+
In message [EMAIL PROTECTED], Geir Magnusson Jr writes: Don't forget that not all platforms have 1.4 or a mature 1.4 that people trust. it too a while for apple to get 1.4 out to OS X - I wouldn't use OS X in production of course, but it's my development platform... Absolutely. J2SE 1.4 java.nio in Sun's JVM was broken even on Solaris until the 1.4.2 release, causing me quite some grief when I tried to demo some code on Solaris that had been developed on Linux. The Win2k implementation was buggy as well until 1.4.1. That's part of why I think java.nio work should start on an experimental branch (another reason is that it allows experimentation with design changes). daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] Branching
In message [EMAIL PROTECTED], Jeffrey D. Brekke writes: After we make a 1.1 compatible release and tag, that will be the branch point for any 1.1 fixes. Next we can make a release with 1.2 support and tag, that will be the branch point for any 1.2 related fixes. All development then proceeds on HEAD. Its just a suggestion. I can live with an experimental branch also, just in other projects I've been involved with, if HEAD isn't the focal point of new development, it get confusing where to put stuff, what is working, etc. I understand and agree with what you're saying and think we had different ideas of the nature of new development. I was thinking that for the foreseeable future, new development would be focused on enhancing the functionality of the current code, such as Steve's parser factory. I'm proposing we engage in a certain amount of redesign and implementation around java.nio, which may break a lot of stuff and in the end may turn out to be a throwaway experiment to figure out how to implement the next generation of the code the right way. I'm leary of the possibility of going down blind alleys on the HEAD branch. However, I was also going to suggest that the redesign/reimplementation/nio work occur in an org.apache.commons.net2 package (has the advantage of allowing both new and old code to coexist, as may be required in some environments, without playing games with classloaders), which may make it a moot point as we can simply omit that package from releases. At any rate, I don't think any of us are going to embark on any J2SE 1.4 work in the next few days, so let's talk it over some more to figure out where we want to go with this and at least create the 1.1 branch so Steve can continue to make his changes of off HEAD. I'm visiting relatives and have likely not given sufficient thought to my suggestions. All I'm sure of is that we've got three cases to consider: 1. maintenance of a 1.1 compatible product with a schedule to suspend support 2. continued development of a 1.2 compatible product where the next immediately usable features will be developed 3. long term development of a 1.4 dependent product that has a yet to be determined design and may take a year or more to materialize into something usable Steve Cohen, Jeffrey Brekke, and Daniel Savarese all appear to agree on how to do 1, so I think it's safe to skip a vote and just make the branch. Sanity check the steps to make sure this is what we want: o rename NET_1_1_0 tag to something else, let's say FOO o tag FOO as NET_1_1_0, this time with the -b flag to make it a branch tag If that seems like not a good thing, another option is to tag the NET_1_1_0 snapshot with NET_1_1_0_MAINTENANCE or some such tag for the 1.1 maintenance branch and leave the existing NET_1_1_0 tag alone. Having done that then we'll continue new development (e.g., Steve's parser factory) on the HEAD branch until we figure out whether J2SE 1.4 development really belongs on an experimental branch, the HEAD branch, in a net2 package, or some variation thereof. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] Branching
I wrote: In message [EMAIL PROTECTED], Jeffrey D. Brekke writes: Its just a suggestion. I can live with an experimental branch also, just in other projects I've been involved with, if HEAD isn't the focal point of new development, it get confusing where to put stuff, what is working, etc. I understand and agree with what you're saying and think we had different ideas of the nature of new development. I was thinking that for the I just realized that my original suggestion didn't make it clear that the experimental branch, should it result in good code, would be remerged into the HEAD branch come time for its first release and the 1.x stuff would branch for maintenance at that point. It may have sounded like I was suggesting that 2.x development continue forever off of a non-HEAD branch. I don't know if that adds anything to the discussion if it was misunderstood. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Next Steps - WAS Re: [net] VMSFTPEntryParser bug?
In message [EMAIL PROTECTED], steve cohen writes: I am not completely CVS-literate and setting up the branches is beyond my current level of experience but probably would be good experience for me. In my response to Jeffrey's email, I asked about whether we wanted to replace the existing NET_1_1_0 tag with a new NET_1_1_0 branch tag or leave the existing tag alone and attach a special branch tag with a different name to the NET_1_1_0 files. After we resolve that, if you want to do it, go ahead. I don't know if you can use the -F and -b options together with cvs tag, which is why I suggested the roundabout way of renaming the tag and creating a new one with the old name using -b. Subversion makes this easier. without requiring it to have far more knowledge of commons-net internals than I think is healthy. So I am developing an FTPFileEntryParserFactory and some convenience methods in FTPClient to enable Ant to be recoded decently. I followed the emails. Sounds great. I forgot to offer a comment. I was going to suggest making FTPFileEntryParserFactory either a class or an interface that has to be instantiated rather than a singleton. I think you were intending to make createFileEntryParser a static method. I suggest the use of an interface and a default factory class for the same reason we had to write SocketFactory and much later, in J2SE 1.4, Sun added its own javax.net.SocketFactory and javax.net.ServerSocketFactory. It allows generic code to be written that accepts pluggable parser factories should a user decide to implement his own factory. I'm thinking about the automatic detection code you alluded to, which could then be configurable/extensible through the insertion of parser factories. I can also make the HashMap--Hashtable change for the 1.1.1 branch. The JDK 1.1 incompatibility was DISCOVERED through failure of the unit test but the offending code is in the class being tested, not the test itself. I have Sure thing. Let's decide how to tag that branch. And it sounds like you have an itch for doing the nio stuff. It's been nagging me for a while, but I'm actually writing networking code these days based on java.nio, so I figure I should kill two birds with one stone and start rolling it into Commons Net as a proposal instead of keeping it in my private library. It's so much easier to dedicate volunteer committer hours when you're working on/using the stuff anyway. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] Branching
I wrote: Sanity check the steps to make sure this is what we want: o rename NET_1_1_0 tag to something else, let's say FOO o tag FOO as NET_1_1_0, this time with the -b flag to make it a branch tag I left out delete the FOO tag ... If that seems like not a good thing, another option is to tag the NET_1_1_0 snapshot with NET_1_1_0_MAINTENANCE or some such tag for the 1.1 maintenance branch and leave the existing NET_1_1_0 tag alone. I forgot to indicate what I favor. Only because I haven't thought of any arguments against it, I favor the first method (change NET_1_1_0 to a 'cvs tag -b' branch tag). The second approach is safer because it doesn't run the risk of screwing up anything and I don't object to it. The only con I can think of to the second approach is that having two tags with NET_1_1_0 in them may be confusing. I don't think I've ever retroactively branched after tagging with CVS (usually, for me at least, branching is premeditated), which is why I don't have a strong preference. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [NET] VMSFTPEntryParser bug?
In message [EMAIL PROTECTED], steve cohen writes : failing but on a different line. I'm not sure what platform Jeff is on when he did the build, but I think I should rewrite this test in a way that doesn't assume any particular order since this seems to be JDK-implementation dependent. The JavaDoc for HashMap specifies no order that should be expected for HashMap.values(), nor for HashMap.keySet() for that matter. We could probably achieve a dependable order by using a TreeMap.keySet() instead. +1 However, this brings up the larger question, of what the target platform for commons-net is. I dimly remember that it being java 1.1. This is why I went through the annoying exercise of creating the FTPFileList and FTPFileIterator classes based on java-1.1-compatible containers like Vector. If we are now using HashMaps, though, we will have violated this contract, if, in fact, such a contract exists. Can someone clarify this question? This is a good question. At first I was going to say it doesn't impact the tests; but if your tests are dependent on a specific JDK, then you never run them on other JDKs. I'm of the mind that we ought to agree on a plan to migrate to J2SE 1.4 features. Still, there's the issue of Ant, which has a dependency on commons net. I know they abandoned JDK 1.1 support in the latest release, but is their new baseline J2SE 1.2 or 1.4? Anyone who needs JDK 1.1 support can live with the 1.1 release and we can support it in a separate branch applying bug fixes if there is sufficient demand. Another alternative is to start an experimental branch intended to become Commons Net 2.0 and continue releasing 1.x releases that meet Ant's compatibility requirements. Commons Net 2.0 could be a fundamental redesign and reimplementation based on the new IO features present in J2SE 1.4. The guts of the code would change, but not all of the protocol logic built around it, so it's not like it would be a complete rewrite. A lot of the kluginess in Commons Net stems from the lack of java.nio at its genesis. At any rate, until we hash some of this out in more detail, my vote is to support whatever Ant requires for compatibility. If it's J2SE 1.2, then HashMaps are okay in the unit tests. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [codec] [proposal] Moving To Apache Commons
In message [EMAIL PROTECTED] .com.au, [EMAIL PROTECTED] writes: I think something folks are missing is that if J-C moves to A-C, then all J-C committers become A-C PMC Members and can change the rules that don't make sense once A-C has incorporated J-C. For example, and it's I'm failing to see what extra oversight this brings us. What percentage of J-C committers are currently on the Jakarta PMC? What percentage of Jakarta PMC members are J-C committers? The percentage would be 100% for both in A-C. In any case, my personal view is not that J-C derives any immediate benefit from a move, but that Jakarta and the ASF as a whole does. Looking from the ouside in it makes sense to me; looking from the inside out the gain isn't apparent. Jakarta Commons is more than about providing common components to Jakarta. It provides them to TLPs as well. Apparently the hypothetical and expository qualifiers in my comment were not sufficiently clear. I never said or attempted to imply that Jakarta Commons was only about providing common components to Jakarta. Why would I think that when the code bases I've contributed to are all used by other TLPs? In any case, your point makes a case for moving out of Jakarta. However, my intent was to express that the arguments based on I don't like how A-C is organized are specious because we get to change the way it is organized. Anyway, the whole matter comes down to differences in perception of the current state of affairs and different predictive models about the outcome of various courses of action. As I've already expressed my opinion (and my vote on the codec move), I have to choose to use the rest of my limited time to attend to pending code-related items I've had to put off for too long, rather than continue to clarify my commentary. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Commons - TLP
In message [EMAIL PROTECTED], Dirk Verbeeck writes: The point I wanted to make was only about how I would try to attract more active developers and not about the usefulness of the mentioned projects. Point taken. I'm totally on the same page as you and agree with all of your suggestions. Even though you weren't trying to say anything about regexp, bcel, and oro, should they want to move out of maintenance mode, they would all benefit from the actions you described. I would have sent this reply to you individually to avoid inadvertently adding to any perceived noise, but I wanted to voice my agreement that JXPath should not move out of J-C out of perception that it would increase participation. Especially when code bases like oro will likely seek to move into a commons environment. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
