[jira] Closed: (JELLY-97) MenuBar not shown
Message:
The following issue has been closed.
Resolver: dion gillard
Date: Wed, 7 Jan 2004 7:18 PM
Applied today
-
View the issue:
http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-97
Here is an overview of the issue:
-
Key: JELLY-97
Summary: MenuBar not shown
Type: Bug
Status: Closed
Priority: Minor
Resolution: FIXED
Original Estimate: 5 minutes
Time Spent: Unknown
Remaining: 5 minutes
Project: jelly
Components:
taglib.swt
Assignee: dion gillard
Reporter: Kurt Riede
Created: Thu, 20 Nov 2003 7:19 AM
Updated: Wed, 7 Jan 2004 7:18 PM
Environment: Plattform: Win2000
Java: JDK 1.4.2
Description:
Affects version: CVS from 17.11.2003
Menubar is not attached to parent shell an thus not shown.
Reason:
Wrong signature of method attachWidgets() in class
org.apache.commons.jelly.tags.swt.MenuTag:
What happens:
Instead of the method in the derived class MenuTag, the default method in the
super class WidgetTag is called.
The enclosed patch fixes this problem.
Index: MenuTag.java
===
RCS file:
/home/cvspublic/jakarta-commons/jelly/jelly-tags/swt/src/java/org/apache/commons/jelly/tags/swt/MenuTag.java,v
retrieving revision 1.5
diff -r1.5 MenuTag.java
103c103
< protected void attachWidgets(Widget parent, Widget widget) {
---
> protected void attachWidgets(Object parent, Widget widget) {
-
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/jelly/jelly-tags/swt/src/java/org/apache/commons/jelly/tags/swt MenuTag.java
dion2004/01/07 17:02:05
Modified:jelly/jelly-tags/swt/src/java/org/apache/commons/jelly/tags/swt
MenuTag.java
Log:
Apply Jelly-97. Demo seems to work ok with it
Revision ChangesPath
1.6 +1 -1
jakarta-commons/jelly/jelly-tags/swt/src/java/org/apache/commons/jelly/tags/swt/MenuTag.java
Index: MenuTag.java
===
RCS file:
/home/cvs/jakarta-commons/jelly/jelly-tags/swt/src/java/org/apache/commons/jelly/tags/swt/MenuTag.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- MenuTag.java 9 Oct 2003 21:21:25 - 1.5
+++ MenuTag.java 8 Jan 2004 01:02:05 - 1.6
@@ -100,7 +100,7 @@
* @param parent is the parent widget which is never null
* @param widget is the new child widget to be attached to the parent
*/
-protected void attachWidgets(Widget parent, Widget widget) {
+protected void attachWidgets(Object parent, Widget widget) {
Menu menu = (Menu) widget;
if (parent instanceof Decorations) {
Decorations shell = (Decorations) parent;
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (JELLY-97) MenuBar not shown
Message:
The following issue has been re-assigned.
Assignee: dion gillard (mailto:[EMAIL PROTECTED])
-
View the issue:
http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-97
Here is an overview of the issue:
-
Key: JELLY-97
Summary: MenuBar not shown
Type: Bug
Status: Open
Priority: Minor
Original Estimate: 5 minutes
Time Spent: Unknown
Remaining: 5 minutes
Project: jelly
Components:
taglib.swt
Assignee: dion gillard
Reporter: Kurt Riede
Created: Thu, 20 Nov 2003 7:19 AM
Updated: Wed, 7 Jan 2004 7:13 PM
Environment: Plattform: Win2000
Java: JDK 1.4.2
Description:
Affects version: CVS from 17.11.2003
Menubar is not attached to parent shell an thus not shown.
Reason:
Wrong signature of method attachWidgets() in class
org.apache.commons.jelly.tags.swt.MenuTag:
What happens:
Instead of the method in the derived class MenuTag, the default method in the
super class WidgetTag is called.
The enclosed patch fixes this problem.
Index: MenuTag.java
===
RCS file:
/home/cvspublic/jakarta-commons/jelly/jelly-tags/swt/src/java/org/apache/commons/jelly/tags/swt/MenuTag.java,v
retrieving revision 1.5
diff -r1.5 MenuTag.java
103c103
< protected void attachWidgets(Widget parent, Widget widget) {
---
> protected void attachWidgets(Object parent, Widget widget) {
-
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester] mavenization of documentation build
On Thu, 2004-01-08 at 10:56, robert burrell donkin wrote: > at first glance it seems that pretty much everything is there but i'd > like to double check before it's declared official. i like to ask first > just in case any other people have any strong feelings about not > mavenizing digester. (now would be a good time to speak up if you have, > BTW) I'm happy to use Maven for Digester. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/beanutils/src/java/org/apache/commons/beanutils package.html
rdonkin 2004/01/07 14:01:09
Modified:beanutils/src/java/org/apache/commons/beanutils package.html
Log:
Added entry to FAQ about ordering bean comparator.
Revision ChangesPath
1.18 +24 -0
jakarta-commons/beanutils/src/java/org/apache/commons/beanutils/package.html
Index: package.html
===
RCS file:
/home/cvs/jakarta-commons/beanutils/src/java/org/apache/commons/beanutils/package.html,v
retrieving revision 1.17
retrieving revision 1.18
diff -u -r1.17 -r1.18
--- package.html 17 Sep 2003 20:23:22 - 1.17
+++ package.html 7 Jan 2004 22:01:09 - 1.18
@@ -53,6 +53,7 @@
Frequently Asked Questions
Why Can't BeanUtils Find My Method?
+How Do I Set The BeanComparator Order To Be
Ascending/Descending?
@@ -808,5 +809,28 @@
create your own BeanInfo.
+
+How Do I Set The BeanComparator Order To Be Ascending/Descending?
+
+BeanComparator relies on an internal Comparator to perform the actual
+comparisions. By default,
+org.apache.commons.collections.comparators.ComparableComparator
+is used which imposes a natural order. If you want to change the order,
+then a custom Comparator should be created and passed into the
+appropriate constructor.
+
+
+For example:
+
+
+import org.apache.commons.collections.comparators.ComparableComparator;
+import org.apache.commons.collections.comparators.ReverseComparator;
+import org.apache.commons.beanutils.BeanComparator;
+...
+BeanComparator reversedNaturalOrderBeanComparator
+= new BeanComparator("propertyName", new ReverseComparator(new
ComparableComparator()));
+Collections.sort(myList, reversedNaturalOrderBeanComparator);
+...
+
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester] mavenization of documentation build
On 6 Jan 2004, at 22:45, __matthewHawthorne wrote: robert burrell donkin wrote: there has been talk about an improved, common documentation build for jakarta commons. IIRC the consensus settled on maven. it was suggested that those components already with mavenized builds switch to using these for documentation. i'd be happy to look at updating the digester maven build and porting the existing site to maven. one reason why i'd like to do this is that it should be possible to generate html from the source in the examples (which i think would be really cool :) http://jakarta.apache.org/commons/digester already looks Mavenized. yep. Are you speaking of http://jakarta.apache.org/commons/digester.html? It seems to be a pretty simple conversion. yep. (but never said it'd be difficult ;) at first glance it seems that pretty much everything is there but i'd like to double check before it's declared official. i like to ask first just in case any other people have any strong feelings about not mavenizing digester. (now would be a good time to speak up if you have, BTW) HTML source examples are always helpful, good idea. the examples are pretty cool already but i think folks are more likely to discover them if they're on the website. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [BeanUtils] WrapDynaBean Enhacement Request
On 7 Jan 2004, at 03:27, Craig R. McClanahan wrote: Quoting robert burrell donkin <[EMAIL PROTECTED]>: 3 seems to me to be a symptom of a bigger issue (which has been known for some time). the exception handling in beanutils is painful and confusing to many users. i'd be very reluctant to break backwards compatibility (even for symantics) and i suspect that the proposed patch does. we've talked before about the possibility of factoring out the exception handling and possible it might be better to fix this rather than the symptom. so maybe a little more talk and thought is needed about this one. I'm on general principles opposed to breaking backward compatibility on method names -- but I don't have any problem with efficiency improvements, or usability improvements (i.e. error messages that point you at what the real issue is). I haven't had time to look at your patch yet (slightly busy with JavaServer Faces at the moment ;-), but agree with Robert's general point that an overall review of how BeanUtils is put together as a whole is probably overdue. Indeed, that sort of thing would make sense in the context of a BeanUtils 2.0 type discussion, perhaps having 2.x releases while we continue bugfixes on the 1.x track and keep compatibility there. BeanUtils is a very widely used package, so we have to be even more careful than is typical in j-c about compatibility. But it's also time to do some innovation again, and these sorts of discussions might be a good kickoff for that. +1 i have an idea that there are a number of much requested features that it might be possible to add without breaking backwards compatibility. there will be a price to pay in terms of introducing more strategy plug-ins and greater complexity but i believe that the advantages of being able to drop in more sophisticated functionality would be great. now the main package has been beanified, it might be possible to allow users to tweak existing applications without being forced to upgrade. exception handling is one that's been talked about frequently. many users find the current exception handling strategy confusing. there has been talk about whether it'd be possible to factor out. i'm not sure whether this would be possible or whether it'd solve niall's problems but maybe it's something we might think about. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [BeanUtils] WrapDynaBean Enhacement Request
On 7 Jan 2004, at 05:44, Niall Pemberton wrote: My problem is I built a framework to just generate, process and spit out DynaBeans and then got it to also do POJ beans afterwards when I discovered your "Wrapped" DynaBeans . 1) WrapDynaClass.newInstance() The framework generates DynaBeans (from Excel files). I am storing the DynaClasses and using newInstance() to generate DynaBeans as it needs them. It just made adapting my framework to generate ordinary JavaBeans via "Wrapped" dynabeans v.easy with WrapDynaClass.newInstance() working the same as other DynaClasses. I agree with you, if I hadn't built it initiallly just for DynaBeans I could have done it differently. Also if WrapDyanClass doesn't implement the newInstance() method then it doesn't fulfill its contract as a DynaClass type - shouldn't it do it anyway, even if there are other ways to generate the WrapDynaBean - otherwise it has to be catered for as special case. this seems like a reasonable use case. i'm in favour of adding this method (with some more documentation giving advice about the most typical use case). i'll probably go ahead and add this one unless sometime soonish. 2) WrapDynaBean.getInstance() The framework runs out of the box to generate DynaBeans from Excel spreadsheets using XML configuration. If I can get the original JavaBean out of the Wrapper, I don't have to worry about modifying my existing framework. I think this is a good use case - have a system where you can plug in a Factory to generate whatever flavor of DynaBeans are required, process them and then spit them out to a downstreams system (which has no reference to those POJ Beans) which can then "UnWrap" them and use them as it likes. being able to obtain a reference to the wrapped bean seems reasonable to me. again, this kind of thing is probably not appropriate for the most common use cases but would be useful for some kinds of design. i'll probably go ahead and add it (with some appropriate documentation) sometime soonish. - robert - 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)
On Wednesday 07 January 2004 11:44 am, Daniel F. Savarese wrote: > 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. I think we're all in agreement here. The subclass is cleanest the way to go. (See, Jeffrey, that wasn't so hard). 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. > > >[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 > > Frankly I think we could have this coded by the weekend if not sooner. - 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)
On Wednesday 07 January 2004 11:14 am, Daniel F. Savarese wrote: > 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 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] Exactly so. This will work. - 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)
Daniel F. Savarese wrote: > 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. Correct. On September 14, and corrected on October 8. http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED] he.org&msgNo=33993 http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED] he.org&msgNo=35816 > We may need a signed CLA before we can include it should it pass muster. This is an area I find confusing, as well, but AIUI to date we mostly require a CLA only from a committer. If the codebase is significant (a grey area), one could ask for a software grant, as we have done in some cases. The revised ASF licenses are supposed to help clear up questions related to contributions. But Jason did post it to the mailing list for the specific purpose of having it incorporated, and he applied the ASF License to each file. --- Noel - 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] 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 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]
[cache] Common abstraction layer
Hi, I have implemented what could be the basis for a common abstraction layer for cache implementations as discussed previously : http://www.mail-archive.com/[EMAIL PROTECTED]/msg31432.html http://www.mail-archive.com/[EMAIL PROTECTED]/msg32363.html The structure of this implementation is similar to commons-logging. The CacheFactory class has been adapted from the LogFactory class. Let me know if this looks ok :) Emmanuel Bourg cache.zip Description: Zip archive smime.p7s Description: S/MIME Cryptographic Signature
Re: [net] 1.2 release (Re: [net] checked in parser factory implementation)
> On Wed, 07 Jan 2004 05:44:36 -0600, steve cohen <[EMAIL PROTECTED]> said:
> On Tuesday 06 January 2004 11:04 pm, Jeffrey D. Brekke wrote:
>> Steve/Daniel,
>>
>> I'm responding to snippets from several messages in this one
>> message, sorry if it's confusing...
>>
>> [Iterator idea]
>>
>> When I suggested the filtering iterator I was thinking of something
>> really simple, like an additional class or example of how one could
>> filter off multiple versions when iterating and leaving the VMS
>> parser simple, just parsing the list with versions intact.
> This sounds interesting but I don't really understand how it would
> work. Do you have some example from some other system in mind?
[SNIPPED]
No, but I was just thinking that we'd use Commons/Collections
FilterIterator or some such and provide either the implementation or
an example of how one could do it. A FilterIterator that would
basically just suppress multiple versions.
I haven't done any more than look into javadoc really. If I get time
I'll try it out.
>> [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 keeps the classes following SRP. If someone doesn't
>> like the VMS parser our factory defaults to for auto-detection (
>> we'll have to decide on one of them ), they could write their own
>> factory ( or we could write a property-backed factory for easy
>> customization or something ).
> I was thinking along these lines too. I didn't pursue it because it
> seemed ugly, but is it? I'm not so sure it is. VMS with versioning
> is really a very significant difference from VMS without versioning,
> and yet similar enough that the IS-A relation is a good fit. It's
> certainly easier to do this than to do what Daniel and I were
> talking about, and it's conceptually defensible too. We don't need
> to change the factory for this either - just like the Enhanced Unix,
> this one wouldn't be available to auto-detection, but accessible via
> key or classname and manual coding.
>> [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'm not sure I agree here. FTPFileList (despite its name) is not a
> list of FTPFiles. It is a wrapper around vector of raw FTP entries
> designed to implement Daniel's old suggestion that a quick read of
> the list be separated in time from the creation of more expensive
> FTPFile objects, which would be created as needed when iterating the
> list in a paged fashion, or possibly by a different thread.
> This is not to say that there might not be a good reason to make
> listFiles() methods return Lists instead of arrays, but that's
> different from FTPFileList.
>> I guess we're spiraling out of control here with ideas ( not
>> necessarily a bad thing ). Just not sure how to rein us in ;)
> If we're still at this point by next week, then you should worry.
> :-)
>> > On Tue, 06 Jan 2004 19:47:15 -0600, steve cohen >
>> <[EMAIL PROTECTED]> said:
>> >
>> > On Tuesday 06 January 2004 07:08 pm, Daniel F. Savarese wrote:
>> >> 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.
>> >
>> > You're right. I'm sorry. You read what the code said. I "read"
>> > what I thought the code should be saying. It does seem >
>> counter-intuitive the way it is, but maybe there's a way to >
>> understand it that I don't have, by which it makes sense. I've >
>> explicitly added Stephane Este-Gracias (who wrote this code) to
>> this > thread for his opinion. Stephane, if you see this, please
>> weigh in > on this.
>> >
>> >> >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 :)
>> >
>> > Which I've already responded to so will say no more here.
>> >
>> >> >Here's another problem, though, in our system. How do you turn
>> >>
>> >> versioning > on in the auto-detect scenario? There's no hook in
>> >>
Re: [betwixt] Status of Betwixt
Btw I am going to use commons-sql (at least a choice for now) for my work, which depends on betwixt, so with a bit of luck I can do some betwixt during office hours... Mvgr, Martin On Tue, 2004-01-06 at 23:31, robert burrell donkin wrote: > On 6 Jan 2004, at 02:50, Ryan Hoegg wrote: > > > I am a happy betwixt user and would be happy to take a more active > > role sometime in late January. > > cool. more hands, eyes and brains would be great :) > > > What are your concerns with betwixt as it is now? > > too many to list quickly. it took me a long time to understand a little > about what a start-from-java mapper needs to do. now i think i have an > idea, the current betwixt internal structure isn't strong and simple > enough to support it. > > there are some list of planned features on the todo list in the > documentation. > > the refactoring i've been (slowly) doing is a complete rewrite (again) > of the xml reading code. > > > Perhaps a little road map? > > i'd suggest that we start off as martin says: i'll tidy up my > refactored code and create a branch this weekend. we'll get together > for a chat on IRC sometime next week or weekend. > > i know that some people want (and possibly need) a proper (non-alpha) > release. the code in cvs head is probably good enough for a 0.1 or 0.5 > release but some other committer would need to manage it. this could be > done as soon as convenient. (the more advanced refactored stuff would > be on the branch.) > > > Do we have a wiki? > > probably :) > > but IIRC the apache wiki's (does anyone know more?) are being > restructured so maybe it'd be a good idea to hold off until the dust > settles > > - robert > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- Mvgr, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [collections] Version 3.0 - The final stretch
Neither of these yet exist in released versions of beanutils/configuration, so they can't be deprecated yet. Stephen > from:Henri Yandell <[EMAIL PROTECTED]> > Weren't ExtendedProperties and BeanMap to be removed? > > Or was the decision made to keep them? - 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)
On Tuesday 06 January 2004 11:04 pm, Jeffrey D. Brekke wrote:
> Steve/Daniel,
>
> I'm responding to snippets from several messages in this one message,
> sorry if it's confusing...
>
> [Iterator idea]
>
> When I suggested the filtering iterator I was thinking of something
> really simple, like an additional class or example of how one could
> filter off multiple versions when iterating and leaving the VMS parser
> simple, just parsing the list with versions intact.
This sounds interesting but I don't really understand how it would work. Do
you have some example from some other system in mind?
>
> [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
> keeps the classes following SRP. If someone doesn't like the VMS parser
> our factory defaults to for auto-detection ( we'll have to decide on
> one of them ), they could write their own factory ( or we could write
> a property-backed factory for easy customization or something ).
I was thinking along these lines too. I didn't pursue it because it seemed
ugly, but is it? I'm not so sure it is. VMS with versioning is really a
very significant difference from VMS without versioning, and yet similar
enough that the IS-A relation is a good fit. It's certainly easier to do
this than to do what Daniel and I were talking about, and it's conceptually
defensible too. We don't need to change the factory for this either - just
like the Enhanced Unix, this one wouldn't be available to auto-detection, but
accessible via key or classname and manual coding.
>
> [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'm not sure I agree here. FTPFileList (despite its name) is not a list of
FTPFiles. It is a wrapper around vector of raw FTP entries designed to
implement Daniel's old suggestion that a quick read of the list be separated
in time from the creation of more expensive FTPFile objects, which would be
created as needed when iterating the list in a paged fashion, or possibly by
a different thread.
This is not to say that there might not be a good reason to make listFiles()
methods return Lists instead of arrays, but that's different from
FTPFileList.
>
> I guess we're spiraling out of control here with ideas ( not
> necessarily a bad thing ). Just not sure how to rein us in ;)
If we're still at this point by next week, then you should worry.
:-)
>
> > On Tue, 06 Jan 2004 19:47:15 -0600, steve cohen
> > <[EMAIL PROTECTED]> said:
> >
> > On Tuesday 06 January 2004 07:08 pm, Daniel F. Savarese wrote:
> >> 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.
> >
> > You're right. I'm sorry. You read what the code said. I "read"
> > what I thought the code should be saying. It does seem
> > counter-intuitive the way it is, but maybe there's a way to
> > understand it that I don't have, by which it makes sense. I've
> > explicitly added Stephane Este-Gracias (who wrote this code) to this
> > thread for his opinion. Stephane, if you see this, please weigh in
> > on this.
> >
> >> >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 :)
> >
> > Which I've already responded to so will say no more here.
> >
> >> >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.s
