Re: [lang] So, about that 2.0....
I disagree. I added a number of extra methods to StringUtils. I don't think that the 'jar diff' format bit is accurate now. (Although I actually don't find it that friendly. Maybe we should hand write the comments in that section... then again maybe we should just release.) Outstanding issues: - Enum tests - CharSetUtils.translate(*,*,) Stephen - Original Message - From: Henri Yandell [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Wednesday, July 30, 2003 4:34 AM Subject: RE: [lang] So, about that 2.0 Apart from a few bug numbers [mostly javadoc, but I figured I'd list them], not much else to change in the release notes. Thanks Stephen for keeping them up to date with changes. Lots of javadoc improvement done over the last 2 weeks. Impressive. Hen On Tue, 29 Jul 2003, Henri Yandell wrote: Actually I lie, I'm at Defcon this weekend so unless anyone has other thoughts I'll aim to get release-notes Tuesday, and an rc2 up for Thursday evening EST. Major problem with the last one from memory was the inclusion of javadoc in the jar. Will ensure the jar is nicer this time :) Shooting for a release towards the middle of next week if all goes well. Hen On Tue, 29 Jul 2003, Henri Yandell wrote: Guess it depends on timelines etc. We can spend the rest of the week checking on these bits, and I can build an rc2 at the weekend for checking, or I can go ahead and build an rc2 tomorrow night and we can spend the week checking? Apart from Wednesday nights I'm pretty good for time and I've been staying out of the way from the recent changes so I'll have the mental energy to update the release-notes etc. No matter what we decide, I'll start updating the changelog/release-notes tomorrow night. Hen On Mon, 28 Jul 2003, Gary Gregory wrote: If it were all up to me, I would go ahead and commit these changes if they are good-to-go since these really about bullet-proofing the release. Gary -Original Message- From: Phil Steitz [mailto:[EMAIL PROTECTED] Sent: Monday, July 28, 2003 18:18 To: Jakarta Commons Developers List Subject: Re: [lang] So, about that 2.0 --- Stephen Colebourne [EMAIL PROTECTED] wrote: has anybody got anything outstanding? Stephen I have been working on some additional/improved unit tests for StringEscapeUtils and CharSetUtils (I notice that there are no unit tests for CharSetUtils.translate and there is a small javadoc error in the @throws tag), but I have not found any anomolies. I can wait to submit this stuff until after the release if you want to roll it now. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang][io] final classes
From: Arun Thomas [EMAIL PROTECTED] I agree completely that backwards compatibility is important! Your earlier comment: I plan to change that to extend StringUtils once 2.0 is released led me to assume that Ustring does not currently extend StringUtils. If that is the case, I'm terribly confused as to how backward compatibility is an issue at all? These users do not currently dependent on StringUtils functions - in future, as long as they are informed of the existence of StringUtils, could they not begin to use those functions in addition to those in UString? Because I will remove methods from UString that are now replaced by an equivalent method in StringUtils. That said, I jumped in to a thread on [io] regarding following the lang pattern for XxxUtils only to understand the rationalle behind the design decision to not make such classes final. Until starting to use the commons tools, I'd taken it for granted that making Util classes final was a sensible design choice - I was startled to see that a consensus to the contrary had been reached by the commons-lang/io community and wished to understand the reasoning behind it. When the private /public constructors debate came up I was equally startled ;-) Strange what OSS teaches you. Stephen -Original Message- From: Stephen Colebourne [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 29, 2003 4:56 PM To: Jakarta Commons Developers List Subject: [lang][io] final classes Please don't miss the point here! I have 30 developers, and many projects, all happily using the class UString. I don't want them to all have to change their code. (Its called backwards compatability) By subclassing, I add lots of new methods (that are in StringUtils, and not in UString) without breaking any old code. Maybe over time a migration to just StringUtils will occur, I don't want to decide yet. Now, we can sit here and say that its bad design, or that methods should be added that forward the method call, etc.etc. But thats just uneccessary hassle. If you look back in the archives, you'll find a similar discussion about public versus private constructors in [lang]. On that occasion I argued for [lang] to be really tight and have private constructors because that was 'Good Design Practice'. I WAS WRONG. Of all the lessons that OSS has taught me, its not to second guess the user like this. Yes this means that the user can make mistakes and do 'stupid things'/'bad design'. But thats their perogative. We need to give our users as much power as possible. If they abuse that power then fine. (And please note, that anything applying to [lang] applies equally to [io] as far as XxxxUtils goes) Stephen - Original Message - From: Arun Thomas [EMAIL PROTECTED] So this saves one import for every user of Ustring that needs to use a function currently available in StringUtils? Not meaning to be sarcastic at all - it just seems that this is the only savings you get. Even the documentation lookup will probably have to go to the JavaDoc for StringUtils? -AMT -Original Message- From: Stephen Colebourne [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 29, 2003 2:07 PM To: Jakarta Commons Developers List Subject: Re: [lang] DEVELOPERS-GUIDE.html Because I want to create a subclass of StringUtils. Use case: I curently have a string utility class named UString. I plan to change that to extend StringUtils once 2.0 is released. (Because I'll get lots of extra methods for free) But I can only do that if StringUtils is not final. Stephen - Original Message - From: Henri Yandell [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Tuesday, July 29, 2003 7:46 PM Subject: Re: [lang] DEVELOPERS-GUIDE.html Question just came up on [io]. Why do we not make our XxxUtil classes final again? :) Anyone remember or should I trawl through the mail from last year? Hen On Tue, 29 Jul 2003 [EMAIL PROTECTED] wrote: Plus1 Stephen from:Henri Yandell [EMAIL PROTECTED] date:Tue, 29 Jul 2003 14:00:23 to: [EMAIL PROTECTED] subject: Re: [lang] DEVELOPERS-GUIDE.html Just noticed that DEVELOPERS-GUIDE.html doesn't mention whether our XxxUtils class should be final or not. I'm pretty sure we ended up making them not final. Anyone object to this before I add a line to the guide? Hen -- --- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To
RE: [lang] DEVELOPERS-GUIDE.html
This is just to say that polymorphism only applies to instance
methods. You can do the same thing with fields, only it is a bit
different. LOL.
At 04:08 AM 7/30/2003 -0400, you wrote:
It's worth noting that of the 12 people* I have posed this question to only
one got it right.
Making the utility class final does prevent confusion (and viciously hard to
debug errors) for lower standard devlopers - at the cost of preventing some
more aware developers subclassing just to add more static utility methods.
Since this is the sort of thing only some one who knows what they are doing
should be up to they hopefully would know enough to either
a) change the source to add the new methods themselves
b) the above but pass the patches back to Jakarta
question comes down to how prescriptive the commiters feel like being in the
intersts of reducing error reports and users problems on Commons User...
*all with min 3 months java knowledge some considered themselves excellent
java developers
Matt
-Original Message-
From: Gary Gregory [mailto:[EMAIL PROTECTED]
Sent: 29 July 2003 23:01
To: 'Jakarta Commons Developers List'
Subject: RE: [lang] DEVELOPERS-GUIDE.html
Ah, but not really... ;-)
A subclass cannot override methods that are declared static in the
superclass. In other words, a subclass cannot override a
class method. A
subclass can /hide/ a static method in the superclass by
declaring a static
method in the subclass with the same signature as the static
method in the
superclass. Overriding only applies to instance methods, class methods
behave differently (ah, longing for Smalltalk). A class method can be
/shadowed/ by a subclass but not overridden (not to be
confused with method
overloading of course ;-)
Here is a fun experiment with statics that always comes and
bites you in the
you-know-where:
package test;
class SubC extends SuperC {
static String hi() {
return I am Sub;
}
}
class SuperC extends Object {
static String hi() {
return I am Super;
}
}
public class TestSuperStatic {
public static void main(String[] args) {
SuperC a = new SuperC();
SubC b = new SubC();
SuperC c = b;
System.out.println(a.hi() + , + a.getClass());
System.out.println(b.hi() + , + b.getClass());
System.out.println(c.hi() + , + c.getClass());
}
}
Can you guess what gets printed out? :-)
(and no cheating by running the code!)
Gary
-Original Message-
From: Stephen Colebourne [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 29, 2003 14:30
To: Jakarta Commons Developers List
Subject: Re: [lang] DEVELOPERS-GUIDE.html
In this use case, everybody uses UString, so you can
effectively override.
If you code the same method in the 'subclass', and refer to
it using the
subclass class then it will be called.
Stephen
- Original Message -
From: Gary Gregory [EMAIL PROTECTED]
When you do that, do remember that you cannot override
static methods in
the
same way that you can with instance methods.
Gary
-Original Message-
From: Stephen Colebourne [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 29, 2003 14:07
To: Jakarta Commons Developers List
Subject: Re: [lang] DEVELOPERS-GUIDE.html
Because I want to create a subclass of StringUtils.
Use case:
I curently have a string utility class named UString.
I plan to change that to extend StringUtils once 2.0 is released.
(Because I'll get lots of extra methods for free)
But I can only do that if StringUtils is not final.
Stephen
- Original Message -
From: Henri Yandell [EMAIL PROTECTED]
To: Jakarta Commons Developers List
[EMAIL PROTECTED]
Sent: Tuesday, July 29, 2003 7:46 PM
Subject: Re: [lang] DEVELOPERS-GUIDE.html
Question just came up on [io].
Why do we not make our XxxUtil classes final again? :)
Anyone remember
or
should I trawl through the mail from last year?
Hen
On Tue, 29 Jul 2003 [EMAIL PROTECTED] wrote:
Plus1
Stephen
from:Henri Yandell [EMAIL PROTECTED]
date:Tue, 29 Jul 2003 14:00:23
to: [EMAIL PROTECTED]
subject: Re: [lang] DEVELOPERS-GUIDE.html
Just noticed that DEVELOPERS-GUIDE.html doesn't
mention whether our
XxxUtils class should be final or not. I'm pretty
sure we ended up
making
them not final. Anyone object to this before I add a
line to the
guide?
Hen
-
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
-
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
RE: [io][vote] FileUtils: decision on style
David, Keep in mind that the discussion is in the context of static methods, not instance methods. Gary pointed out that there is a significant difference between instance and static methods with respect to subclassing: the former can be overridden - the latter only shadowed. http://www.mail-archive.com/[EMAIL PROTECTED]/msg23155.html People might definitely want to extend the class - I can see a need for that. But that would require a different approach to the utility classes; similar to the approach taken in struts and beanutils (e.g. Singletons with instance methods rather than Class with static methods). However, while we're discussing only classes which package together static methods - does allowing extensibility make sense? -AMT -Original Message- From: David Graham [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 29, 2003 6:48 PM To: Jakarta Commons Developers List Subject: RE: [io][vote] FileUtils: decision on style --- Neil O'Toole [EMAIL PROTECTED] wrote: At first glance I don't really see the `need to override behavior' argument -- if a user doesn't like the way a static method is implemented, can't they just implement their own in a separate class? Absolutely. I don't see any reason why utility methods should be overridden. But other people *will* see a need, guaranteed. It's a rather limited view to think that no one could ever possibly want to extend your classes. This lesson has been learned the hard way in BeanUtils and in Struts so I encourage you to rethink this strategy. David If a method doesn't do what it says it does, it's broken and should be fixed in the next release. If you need the utility method to do something else, then it should have a different name to distinguish the funtional difference. Also, why would you ever need to extend non-instantiable classes? - Neil --- Michael Heuer [EMAIL PROTECTED] wrote: On Tue, 29 Jul 2003, David Graham wrote: --- Arun Thomas [EMAIL PROTECTED] wrote: Hmmm From the last three notes - I think I understand clearly the motivation for requiring the public no-arg constructor, but I still don't understand the reasoning behind the need for avoiding final. The only reason I can see (with possibly poor vision) is to allow access to the methods of the utility class plus additional specific methods with a handle on only one class object or utility instance (of the subclass utility). This seems to me to be very poor design if such a constraint exists. Can anyone see any other value to extending utility classes with entirely static methods? Because static methods can't be overridden you may as well declare them final. However, static methods are truly evil. As soon as you think no one will ever need to override the behavior, some user will come along with a need to do so. This happened in Struts and now we're replacing all the static methods with Singleton classes with instance methods. Is the struts mailing list the best place to go archive-digging on this topic? At first glance I don't really see the `need to override behavior' argument -- if a user doesn't like the way a static method is implemented, can't they just implement their own in a separate class? michael David Cheers, -AMT -Original Message- From: David Graham [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 29, 2003 11:44 AM To: Jakarta Commons Developers List Subject: RE: [io][vote] FileUtils: decision on style --- Arun Thomas [EMAIL PROTECTED] wrote: Can someone expound on this lesson? The Developers Guide mentions neither the rule that final should be avoided, nor the rule that a public constructor is required. I'd love to know the reasoning - is there some reason that actually derives from the constraints of lang, or is it due to constraints on how other systems use lang? I'm particularly confounded by why the use of final would be a problem. Marking a class as final prevents subclassing which is an extraordinarily bad idea in generally available framework classes. This also goes for methods. Classes without default constructors are not JavaBeans and thus cannot be dynamically created and used in certain environments. David Cheers, -AMT -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 29, 2003 5:55 AM To: Jakarta Commons Developers List Subject: Re: [io][vote] FileUtils: decision on style On Tue, 29 Jul 2003 [EMAIL PROTECTED] wrote: Hey thanks for the heads up! being one of the original authors/contributor of this class, I do have some comments (mostly in favour of your
RE: [io][vote] FileUtils: decision on style
On Wed, 30 Jul 2003, Arun Thomas wrote: However, while we're discussing only classes which package together static methods - does allowing extensibility make sense? That's exactly the position beanutils was in (BeanUtils, PropertyUtils, and ConvertUtils were 100% static utility methods). We thought the answer was no. We were wrong. Whether lang or other basic-utility-level packages would also be wrong remains to be seen (would anyone want to customize how capitalization is actually performed without making users change their code? it would not really surprise me). But, in the end, the decision is certainly up to the folks actually providing the code. -AMT Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [io][vote] FileUtils: decision on style
--- Arun Thomas [EMAIL PROTECTED] wrote: David, Keep in mind that the discussion is in the context of static methods, not instance methods. Gary pointed out that there is a significant difference between instance and static methods with respect to subclassing: the former can be overridden - the latter only shadowed. I'm fully aware of the inheritance rules regarding static and final methods. http://www.mail-archive.com/[EMAIL PROTECTED]/msg23155.html People might definitely want to extend the class - I can see a need for that. But that would require a different approach to the utility classes; similar to the approach taken in struts and beanutils (e.g. Singletons with instance methods rather than Class with static methods). However, while we're discussing only classes which package together static methods - does allowing extensibility make sense? There's at least one person in this discussion who needs to extend the utils classes so it doesn't make sense to declare the classes final. How does it benefit anyone by declaring a reusable library class/method final? David -AMT -Original Message- From: David Graham [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 29, 2003 6:48 PM To: Jakarta Commons Developers List Subject: RE: [io][vote] FileUtils: decision on style --- Neil O'Toole [EMAIL PROTECTED] wrote: At first glance I don't really see the `need to override behavior' argument -- if a user doesn't like the way a static method is implemented, can't they just implement their own in a separate class? Absolutely. I don't see any reason why utility methods should be overridden. But other people *will* see a need, guaranteed. It's a rather limited view to think that no one could ever possibly want to extend your classes. This lesson has been learned the hard way in BeanUtils and in Struts so I encourage you to rethink this strategy. David If a method doesn't do what it says it does, it's broken and should be fixed in the next release. If you need the utility method to do something else, then it should have a different name to distinguish the funtional difference. Also, why would you ever need to extend non-instantiable classes? - Neil --- Michael Heuer [EMAIL PROTECTED] wrote: On Tue, 29 Jul 2003, David Graham wrote: --- Arun Thomas [EMAIL PROTECTED] wrote: Hmmm From the last three notes - I think I understand clearly the motivation for requiring the public no-arg constructor, but I still don't understand the reasoning behind the need for avoiding final. The only reason I can see (with possibly poor vision) is to allow access to the methods of the utility class plus additional specific methods with a handle on only one class object or utility instance (of the subclass utility). This seems to me to be very poor design if such a constraint exists. Can anyone see any other value to extending utility classes with entirely static methods? Because static methods can't be overridden you may as well declare them final. However, static methods are truly evil. As soon as you think no one will ever need to override the behavior, some user will come along with a need to do so. This happened in Struts and now we're replacing all the static methods with Singleton classes with instance methods. Is the struts mailing list the best place to go archive-digging on this topic? At first glance I don't really see the `need to override behavior' argument -- if a user doesn't like the way a static method is implemented, can't they just implement their own in a separate class? michael David Cheers, -AMT -Original Message- From: David Graham [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 29, 2003 11:44 AM To: Jakarta Commons Developers List Subject: RE: [io][vote] FileUtils: decision on style --- Arun Thomas [EMAIL PROTECTED] wrote: Can someone expound on this lesson? The Developers Guide mentions neither the rule that final should be avoided, nor the rule that a public constructor is required. I'd love to know the reasoning - is there some reason that actually derives from the constraints of lang, or is it due to constraints on how other systems use lang? I'm particularly confounded by why the use of final would be a problem. Marking a class as final prevents subclassing which is an extraordinarily bad idea in generally available framework classes. This also goes for methods. Classes without default constructors are not JavaBeans and thus cannot be dynamically created and used in certain environments. David Cheers, -AMT
RE: [io][vote] FileUtils: decision on style
There's at least one person in this discussion who needs to extend the utils classes so it doesn't make sense to declare the classes final. How does it benefit anyone by declaring a reusable library class/method final? Preventing people who don't know what they are doing from making mistakes. This IS a benefit - whether or not it outweighs the benefit of allowing users to do what they want is a Jakarta-Commons ideology question... Matt ** The information transmitted herewith is sensitive information intended only for use by the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying or other use of, or taking of any action in reliance upon this information is strictly prohibited. If you have received this communication in error, please contact the sender and delete the material from your computer. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [lang] DEVELOPERS-GUIDE.html
I think I like the final POV.
Some thoughts:
Not final:
While this class is not meant to be subclassed, you can do it and shoot
yourself in the foot. Fine.
One thing I do not like in some libraries is to be in the situation (this
has happened to us in [pool]) where you want to add behavior to a fancy
class and want to override a method but cannot because it is private. The
*Utils case is different, I think, since ALL methods are static, which to me
means that it does not make much sense to subclass the beast.
It is interesting to note that you can set up the Eclipse compiler to warn
you about static method access, that is, when you have code like A.foo()
where foo() is a static method in S and A extends S. You should really be
saying S.foo(). I am sure not everyone buys that.
Final:
This avoid the problems and we could make it clear that if you want to write
a String proxy class that let's you do 'new MyString(s).myOps()' then
subclassing StringUtils is not quite right.
This also lets us say: If you have your own StringUtil-like class, making it
a subclass to get the other methods for free is not a great idea, which
means that you have to buy into don't access static methods from wrong
place line.
This also lets us say: Maybe in the future we will provide a /different/
class, which /is/ a String proxy.
Gary
-Original Message-
From: Hope, Matthew [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 30, 2003 01:08
To: 'Jakarta Commons Developers List'
Subject: RE: [lang] DEVELOPERS-GUIDE.html
It's worth noting that of the 12 people* I have posed this question to only
one got it right.
Making the utility class final does prevent confusion (and viciously hard to
debug errors) for lower standard devlopers - at the cost of preventing some
more aware developers subclassing just to add more static utility methods.
Since this is the sort of thing only some one who knows what they are doing
should be up to they hopefully would know enough to either
a) change the source to add the new methods themselves
b) the above but pass the patches back to Jakarta
question comes down to how prescriptive the commiters feel like being in the
intersts of reducing error reports and users problems on Commons User...
*all with min 3 months java knowledge some considered themselves excellent
java developers
Matt
-Original Message-
From: Gary Gregory [mailto:[EMAIL PROTECTED]
Sent: 29 July 2003 23:01
To: 'Jakarta Commons Developers List'
Subject: RE: [lang] DEVELOPERS-GUIDE.html
Ah, but not really... ;-)
A subclass cannot override methods that are declared static in the
superclass. In other words, a subclass cannot override a
class method. A
subclass can /hide/ a static method in the superclass by
declaring a static
method in the subclass with the same signature as the static
method in the
superclass. Overriding only applies to instance methods, class methods
behave differently (ah, longing for Smalltalk). A class method can be
/shadowed/ by a subclass but not overridden (not to be
confused with method
overloading of course ;-)
Here is a fun experiment with statics that always comes and
bites you in the
you-know-where:
package test;
class SubC extends SuperC {
static String hi() {
return I am Sub;
}
}
class SuperC extends Object {
static String hi() {
return I am Super;
}
}
public class TestSuperStatic {
public static void main(String[] args) {
SuperC a = new SuperC();
SubC b = new SubC();
SuperC c = b;
System.out.println(a.hi() + , + a.getClass());
System.out.println(b.hi() + , + b.getClass());
System.out.println(c.hi() + , + c.getClass());
}
}
Can you guess what gets printed out? :-)
(and no cheating by running the code!)
Gary
-Original Message-
From: Stephen Colebourne [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 29, 2003 14:30
To: Jakarta Commons Developers List
Subject: Re: [lang] DEVELOPERS-GUIDE.html
In this use case, everybody uses UString, so you can
effectively override.
If you code the same method in the 'subclass', and refer to
it using the
subclass class then it will be called.
Stephen
- Original Message -
From: Gary Gregory [EMAIL PROTECTED]
When you do that, do remember that you cannot override
static methods in
the
same way that you can with instance methods.
Gary
-Original Message-
From: Stephen Colebourne [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 29, 2003 14:07
To: Jakarta Commons Developers List
Subject: Re: [lang] DEVELOPERS-GUIDE.html
Because I want to create a subclass of StringUtils.
Use case:
I curently have a string utility class named UString.
I plan to change that to extend StringUtils once 2.0 is released.
(Because I'll get lots of extra methods for free)
RE: [io][vote] FileUtils: decision on style
RE: (e.g. Singletons with instance methods rather than Class with static methods). I would like us to careful if/when we do the Singleton thing. Creating a class coded as a Singleton is creating a global variable and object that lives as long as the VM lives. This, depending on your POV, is good/bad when GC comes into play: the object never goes away. I could have an app that uses some util classes here and there and util singleton object are now around forever. IMHO, you should only use singletons if you have a good reason, by design, not as a convenience (read hack) for subclassing. But wait: If S is a singleton and is subclassed by C, then C has to work a little harder with the innards of S to plug an instance of itself in as the singleton in S. This just gets nasty! Again, I think there has to be a good reason. We have here been moving away from singletons. When some logic needs to do something with one of our util classes, it does it the OO way: create and configure an object and call instance methods. When you're done, toss the object and let GC do its work. Gary -Original Message- From: Arun Thomas [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 30, 2003 09:16 To: Jakarta Commons Developers List; [EMAIL PROTECTED] Subject: RE: [io][vote] FileUtils: decision on style David, Keep in mind that the discussion is in the context of static methods, not instance methods. Gary pointed out that there is a significant difference between instance and static methods with respect to subclassing: the former can be overridden - the latter only shadowed. http://www.mail-archive.com/[EMAIL PROTECTED]/msg23155.html People might definitely want to extend the class - I can see a need for that. But that would require a different approach to the utility classes; similar to the approach taken in struts and beanutils (e.g. Singletons with instance methods rather than Class with static methods). However, while we're discussing only classes which package together static methods - does allowing extensibility make sense? -AMT -Original Message- From: David Graham [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 29, 2003 6:48 PM To: Jakarta Commons Developers List Subject: RE: [io][vote] FileUtils: decision on style --- Neil O'Toole [EMAIL PROTECTED] wrote: At first glance I don't really see the `need to override behavior' argument -- if a user doesn't like the way a static method is implemented, can't they just implement their own in a separate class? Absolutely. I don't see any reason why utility methods should be overridden. But other people *will* see a need, guaranteed. It's a rather limited view to think that no one could ever possibly want to extend your classes. This lesson has been learned the hard way in BeanUtils and in Struts so I encourage you to rethink this strategy. David If a method doesn't do what it says it does, it's broken and should be fixed in the next release. If you need the utility method to do something else, then it should have a different name to distinguish the funtional difference. Also, why would you ever need to extend non-instantiable classes? - Neil --- Michael Heuer [EMAIL PROTECTED] wrote: On Tue, 29 Jul 2003, David Graham wrote: --- Arun Thomas [EMAIL PROTECTED] wrote: Hmmm From the last three notes - I think I understand clearly the motivation for requiring the public no-arg constructor, but I still don't understand the reasoning behind the need for avoiding final. The only reason I can see (with possibly poor vision) is to allow access to the methods of the utility class plus additional specific methods with a handle on only one class object or utility instance (of the subclass utility). This seems to me to be very poor design if such a constraint exists. Can anyone see any other value to extending utility classes with entirely static methods? Because static methods can't be overridden you may as well declare them final. However, static methods are truly evil. As soon as you think no one will ever need to override the behavior, some user will come along with a need to do so. This happened in Struts and now we're replacing all the static methods with Singleton classes with instance methods. Is the struts mailing list the best place to go archive-digging on this topic? At first glance I don't really see the `need to override behavior' argument -- if a user doesn't like the way a static method is implemented, can't they just implement their own in a separate class? michael David Cheers, -AMT -Original Message- From: David Graham [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 29, 2003 11:44 AM To: Jakarta Commons Developers List Subject: RE: [io][vote] FileUtils: decision on style --- Arun Thomas [EMAIL PROTECTED] wrote: Can
RE: [io][vote] FileUtils: decision on style
--- Hope, Matthew [EMAIL PROTECTED] wrote: There's at least one person in this discussion who needs to extend the utils classes so it doesn't make sense to declare the classes final. How does it benefit anyone by declaring a reusable library class/method final? Preventing people who don't know what they are doing from making mistakes. In my experience this is almost impossible. Someone who thinks they can subclass and override a static method needs to read a good Java book. We should design class libraries to be easy to use and *flexible*. If that flexibility hurts the newbie, so be it. David This IS a benefit - whether or not it outweighs the benefit of allowing users to do what they want is a Jakarta-Commons ideology question... Matt ** The information transmitted herewith is sensitive information intended only for use by the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying or other use of, or taking of any action in reliance upon this information is strictly prohibited. If you have received this communication in error, please contact the sender and delete the material from your computer. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [io][vote] FileUtils: decision on style
--- Gary Gregory [EMAIL PROTECTED] wrote: RE: (e.g. Singletons with instance methods rather than Class with static methods). I would like us to careful if/when we do the Singleton thing. Creating a class coded as a Singleton is creating a global variable and object that lives as long as the VM lives. This, depending on your POV, is good/bad when GC comes into play: the object never goes away. I could have an app that uses some util classes here and there and util singleton object are now around forever. Trust me, that 8 bytes won't hurt you :-). IMHO, you should only use singletons if you have a good reason, by design, not as a convenience (read hack) for subclassing. But wait: If S is a singleton and is subclassed by C, then C has to work a little harder with the innards of S to plug an instance of itself in as the singleton in S. This just gets nasty! Again, I think there has to be a good reason. How is it hard to plugin a subclass of a Singleton? We have here been moving away from singletons. When some logic needs to do something with one of our util classes, it does it the OO way: create and configure an object and call instance methods. This implies that Singletons are not good OOP. It's documented in the classic Design Patterns book by the GoF so I think we're safe in viewing Singleton as a good pattern. Furthermore, Singleton allows a clean OO alternative to global static methods because you're passing messages to objects (which is what OOP is all about). David When you're done, toss the object and let GC do its work. Gary -Original Message- From: Arun Thomas [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 30, 2003 09:16 To: Jakarta Commons Developers List; [EMAIL PROTECTED] Subject: RE: [io][vote] FileUtils: decision on style David, Keep in mind that the discussion is in the context of static methods, not instance methods. Gary pointed out that there is a significant difference between instance and static methods with respect to subclassing: the former can be overridden - the latter only shadowed. http://www.mail-archive.com/[EMAIL PROTECTED]/msg23155.html People might definitely want to extend the class - I can see a need for that. But that would require a different approach to the utility classes; similar to the approach taken in struts and beanutils (e.g. Singletons with instance methods rather than Class with static methods). However, while we're discussing only classes which package together static methods - does allowing extensibility make sense? -AMT -Original Message- From: David Graham [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 29, 2003 6:48 PM To: Jakarta Commons Developers List Subject: RE: [io][vote] FileUtils: decision on style --- Neil O'Toole [EMAIL PROTECTED] wrote: At first glance I don't really see the `need to override behavior' argument -- if a user doesn't like the way a static method is implemented, can't they just implement their own in a separate class? Absolutely. I don't see any reason why utility methods should be overridden. But other people *will* see a need, guaranteed. It's a rather limited view to think that no one could ever possibly want to extend your classes. This lesson has been learned the hard way in BeanUtils and in Struts so I encourage you to rethink this strategy. David If a method doesn't do what it says it does, it's broken and should be fixed in the next release. If you need the utility method to do something else, then it should have a different name to distinguish the funtional difference. Also, why would you ever need to extend non-instantiable classes? - Neil --- Michael Heuer [EMAIL PROTECTED] wrote: On Tue, 29 Jul 2003, David Graham wrote: --- Arun Thomas [EMAIL PROTECTED] wrote: Hmmm From the last three notes - I think I understand clearly the motivation for requiring the public no-arg constructor, but I still don't understand the reasoning behind the need for avoiding final. The only reason I can see (with possibly poor vision) is to allow access to the methods of the utility class plus additional specific methods with a handle on only one class object or utility instance (of the subclass utility). This seems to me to be very poor design if such a constraint exists. Can anyone see any other value to extending utility classes with entirely static methods? Because static methods can't be overridden you may as well declare them final. However, static methods are truly evil. As soon as you think no one will ever need to override the behavior, some user will come along with a need to do so. This happened in Struts and now we're replacing all the static methods with Singleton classes with instance methods. Is the struts mailing
RE: [io][vote] FileUtils: decision on style
-Original Message- From: David Graham [mailto:[EMAIL PROTECTED] Sent: 30 July 2003 18:39 To: Jakarta Commons Developers List Subject: RE: [io][vote] FileUtils: decision on style Preventing people who don't know what they are doing from making mistakes. In my experience this is almost impossible. Someone who thinks they can subclass and override a static method needs to read a good Java book. We should design class libraries to be easy to use and *flexible*. If that flexibility hurts the newbie, so be it. a fair point of view - still think you'll reduce the traffic on Commons-Users by doing it though... ** The information transmitted herewith is sensitive information intended only for use by the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying or other use of, or taking of any action in reliance upon this information is strictly prohibited. If you have received this communication in error, please contact the sender and delete the material from your computer. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [io][vote] FileUtils: decision on style
On Wednesday, July 30, 2003, at 06:08 PM, Gary Gregory wrote: snip We have here been moving away from singletons. When some logic needs to do something with one of our util classes, it does it the OO way: create and configure an object and call instance methods. When you're done, toss the object and let GC do its work. IMHO when designing library code, i think that it's important to remember that you are creating reusable component rather than a framework. deciding to put functionality in a singleton or in a booch utility (aka static utility class) forces the user down one design path and limits the ways that the functionality can be used by users and frameworks for very little gain. creating a concrete class with a standard constructor gives the user the maximum flexibility. if the user wants to use a singleton, they are free to create a factory method. a framework is free to create and configure an instance in whatever way it pleases. a user can create a static facade that gives access to the most usual ways they use the libary. i do think that there is a place for booch utilities: where these can provide a simple facade to the basic functionality of the component. these methods should implement basic use cases and should not be configurable. they should simply work. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] Clover coverage report for Lang 2.0
Tetsuya Kitahata wrote: No, I think each subprojects should have own license. Again, it would be interesting to get http://hansel.sourceforge.net/ (recently released 1.0), or http://quilt.sourceforge.net/ working. Unfortunately, the latter had no activity for more than half a year. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] Proposal for a Timeout Affected Priority Queue
0. Please prefix emails by topic, eg.[collections] 1. Has anyone else had a need for a timeout affected priority queue? I haven't had a need for such a class, other may have. 3. How do I submit a draft of the classes - do I attach a zip file or paste into the body of an email? Either a zip attachment, or a link to the zip on another server 4. Who do I send it to? The link/zip should be to this list. Stephen - Original Message - From: Cheung Lo [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, July 30, 2003 9:59 AM Subject: Proposal for a Timeout Affected Priority Queue Proposal for a Timeout Affected Priority Queue Currently available open source queues fall into 2 categories: FIFO/LIFO and priority-sorted. These are fine, so long as the supply of resources to process the queue jobs exceed demand over the time period of interest. When this is true, all the jobs are processed in a timely fashion. In my last project however, the above assumption could not be made. The jobs had an initial priority but during busy periods, the continous insertion of higher priority jobs implied that lower priority jobs did not get done. This pattern occured in another previous project as well. In an insurance office, during periods of low-normal activity, answering customer calls had higher priority over policy administration. However, admin could only be delayed for a limited period. If this period timed out, the priority of policy admin increased so that resources were diverted away from new customer calls. In other circumstances, jobs that time out may be binned instead. I have implemented a generic solution to a self managing Timeout Affected Priority (TAP) Queue. There are 3 core classes: TapQueue, TapObject and TapConsumer. Whenever a consumer pops the next next job, the queue checks for any priority timeouts and, if necessary, re-prioritizes the queue before returning the next job. Internally, the TapQueue uses a modified version of org.apache.commons.collections.BinaryHeap. I would like to propose the adoption of the TapQueue into the collections packages but need feedback on the following issues: 1. Has anyone else had a need for a timeout affected priority queue? 2. If so, what additional requirements did you have that is not already described? 3. How do I submit a draft of the classes - do I attach a zip file or paste into the body of an email? 4. Who do I send it to? Cheung Lo London, UK - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] So, about that 2.0....
--- Stephen Colebourne [EMAIL PROTECTED] wrote: I disagree. I added a number of extra methods to StringUtils. I don't think that the 'jar diff' format bit is accurate now. (Although I actually don't find it that friendly. Maybe we should hand write the comments in that section... then again maybe we should just release.) Outstanding issues: - Enum tests - CharSetUtils.translate(*,*,) I have thought about the second issue some more. Correct me if I am wrong, but I think that the intention of translate(str, repl, with) is: transform str to use the with characters in place of the repl characters, with the understanding that if with contains fewer characters than repl, the last with character will be used for all of the extra repl characters. To me, this makes no sense if either with or repl is or null. In the one case that now throws ArrayOutOfBoundsException (repl positive length, with ) a case could be made that this should mean the same thing as delete(str, repl), but that is not obvious and I see no reason why this behavior should be supported in translate. Therefore, I think that the reasonable alternatives are 1. translate(str, with, repl) is a no-op (i.e. returns str unchanged) whenever with, repl is null or 2. translate(str, with, repl) throws an exception whenever with, repl is null or Personally, I like option 2 and I would rather see IllegalArgumentException thrown in all cases (including null). I would also recommend modifying the other methods in CharSetUtils that now throw NullPointerException to throw IllegalArgumentException instead. An alternative would be NullArgumentException, but that would not literally apply to . Maybe one day we will define EmptyArgumentException for this kind of thing :) For now, seems to me that IllegalArgumentException would be best. Just my HO. Phil Stephen - Original Message - From: Henri Yandell [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Wednesday, July 30, 2003 4:34 AM Subject: RE: [lang] So, about that 2.0 Apart from a few bug numbers [mostly javadoc, but I figured I'd list them], not much else to change in the release notes. Thanks Stephen for keeping them up to date with changes. Lots of javadoc improvement done over the last 2 weeks. Impressive. Hen On Tue, 29 Jul 2003, Henri Yandell wrote: Actually I lie, I'm at Defcon this weekend so unless anyone has other thoughts I'll aim to get release-notes Tuesday, and an rc2 up for Thursday evening EST. Major problem with the last one from memory was the inclusion of javadoc in the jar. Will ensure the jar is nicer this time :) Shooting for a release towards the middle of next week if all goes well. Hen On Tue, 29 Jul 2003, Henri Yandell wrote: Guess it depends on timelines etc. We can spend the rest of the week checking on these bits, and I can build an rc2 at the weekend for checking, or I can go ahead and build an rc2 tomorrow night and we can spend the week checking? Apart from Wednesday nights I'm pretty good for time and I've been staying out of the way from the recent changes so I'll have the mental energy to update the release-notes etc. No matter what we decide, I'll start updating the changelog/release-notes tomorrow night. Hen On Mon, 28 Jul 2003, Gary Gregory wrote: If it were all up to me, I would go ahead and commit these changes if they are good-to-go since these really about bullet-proofing the release. Gary -Original Message- From: Phil Steitz [mailto:[EMAIL PROTECTED] Sent: Monday, July 28, 2003 18:18 To: Jakarta Commons Developers List Subject: Re: [lang] So, about that 2.0 --- Stephen Colebourne [EMAIL PROTECTED] wrote: has anybody got anything outstanding? Stephen I have been working on some additional/improved unit tests for StringEscapeUtils and CharSetUtils (I notice that there are no unit tests for CharSetUtils.translate and there is a small javadoc error in the @throws tag), but I have not found any anomolies. I can wait to submit this stuff until after the release if you want to roll it now. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20813] - FileUpload does not take 'charset' parameter of the 'Content-Type' header into consideration
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20813. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20813 FileUpload does not take 'charset' parameter of the 'Content-Type' header into consideration --- Additional Comments From [EMAIL PROTECTED] 2003-07-30 20:47 --- Created an attachment (id=7593) Patch (take 2) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20813] - FileUpload does not take 'charset' parameter of the 'Content-Type' header into consideration
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20813. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20813 FileUpload does not take 'charset' parameter of the 'Content-Type' header into consideration --- Additional Comments From [EMAIL PROTECTED] 2003-07-30 20:51 --- The parameter parser has been optimized to eliminate unnecessary object instantiation. Parsing should be a bit faster now. Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jelly] patch for a core tag
I was going to submit a patch/enhancement via jira for a core tag and
when I go to the Create new issue, Jelly does not appear in the
project list. So I am attaching the patch file here. It is for the
org.apache.commons.jelly.tags.core.RemoveTag. I changed it so that it
can accept and expression.
Robert McIntosh
Index: RemoveTag.java
===
RCS file:
/home/cvspublic/jakarta-commons/jelly/src/java/org/apache/commons/jelly/tags/core/RemoveTag.java,v
retrieving revision 1.3
diff -u -r1.3 RemoveTag.java
--- RemoveTag.java 24 Jan 2003 22:53:34 - 1.3
+++ RemoveTag.java 30 Jul 2003 20:50:36 -
@@ -64,6 +64,7 @@
import org.apache.commons.jelly.MissingAttributeException;
import org.apache.commons.jelly.TagSupport;
import org.apache.commons.jelly.XMLOutput;
+import org.apache.commons.jelly.expression.Expression;
/**
* A tag which removes the variable of the given name from the current variable scope.
@@ -73,7 +74,7 @@
*/
public class RemoveTag extends TagSupport {
-private String var;
+private Expression var;
public RemoveTag() {
}
@@ -82,7 +83,7 @@
//-
public void doTag(XMLOutput output) throws MissingAttributeException {
if (var != null) {
-context.removeVariable(var);
+context.removeVariable( var.evaluateAsString(context) );
}
else {
throw new MissingAttributeException(var);
@@ -95,7 +96,7 @@
/**
* Sets the name of the variable which will be removed by this tag..
*/
-public void setVar(String var) {
+public void setVar(Expression var) {
this.var = var;
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/httpclient/src/test/org/apache/commons/httpclient TestHttpVersion.java TestNoHost.java
olegk 2003/07/30 14:11:17
Modified:httpclient/src/java/org/apache/commons/httpclient
HttpMethodBase.java HttpRecoverableException.java
httpclient/src/java/org/apache/commons/httpclient/methods
EntityEnclosingMethod.java
ExpectContinueMethod.java
httpclient/src/test/org/apache/commons/httpclient
TestNoHost.java
Added: httpclient/src/java/org/apache/commons/httpclient
HttpVersion.java
httpclient/src/test/org/apache/commons/httpclient
TestHttpVersion.java
Log:
Bug fix #10791 (HTTP Version configuration and tracking)
Contributed by Oleg Kalnichevski
Reviewed by Michael Becke Laura Werner
Revision ChangesPath
1.174 +52 -30
jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/HttpMethodBase.java
Index: HttpMethodBase.java
===
RCS file:
/home/cvs/jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/HttpMethodBase.java,v
retrieving revision 1.173
retrieving revision 1.174
diff -u -r1.173 -r1.174
--- HttpMethodBase.java 25 Jul 2003 18:29:31 - 1.173
+++ HttpMethodBase.java 30 Jul 2003 21:11:17 - 1.174
@@ -196,8 +196,8 @@
/** Whether or not I should automatically process authentication. */
private boolean doAuthentication = true;
-/** Whether or not I should use the HTTP/1.1 protocol. The default is
tttrue/tt. */
-private boolean http11 = true;
+/** Version of the HTTP protocol to be used. */
+private HttpVersion version = HttpVersion.HTTP_1_1;
/** True if we're in strict mode. The default is ttfalse/tt. */
private boolean strictMode = false;
@@ -363,9 +363,15 @@
* Set whether or not I should use the HTTP/1.1 protocol.
*
* @param http11 true to use HTTP/1.1, false to use 1.0
+ *
+ * @deprecated Use @{link #setHttpVersion(HttpVersion)}
*/
public void setHttp11(boolean http11) {
-this.http11 = http11;
+if (http11) {
+this.version = HttpVersion.HTTP_1_1;
+} else {
+this.version = HttpVersion.HTTP_1_0;
+}
}
/**
@@ -397,9 +403,11 @@
* HTTP/1.1 protocol. The default is tttrue/tt.
*
* @return tttrue/tt if I should use the HTTP/1.1 protocol
+ *
+ * @deprecated Use [EMAIL PROTECTED] #getHttpVersion()}
*/
public boolean isHttp11() {
-return http11;
+return this.version.equals(HttpVersion.HTTP_1_1);
}
/**
@@ -894,12 +902,16 @@
}
LOG.debug(Resorting to protocol version default close connection policy);
// missing or invalid connection header, do the default
-if (http11) {
-LOG.debug(Should NOT close connection, using HTTP/1.1.);
+if (this.version.greaterEquals(HttpVersion.HTTP_1_1)) {
+if (LOG.isDebugEnabled()) {
+LOG.debug(Should NOT close connection, using +
this.version.toString());
+}
} else {
-LOG.debug(Should close connection, using HTTP/1.0.);
+if (LOG.isDebugEnabled()) {
+LOG.debug(Should close connection, using +
this.version.toString());
+}
}
-return !http11;
+return this.version.lessEquals(HttpVersion.HTTP_1_0);
}
/**
@@ -1256,7 +1268,7 @@
getResponseTrailerHeaderGroup().clear();
statusLine = null;
used = false;
-http11 = true;
+version = HttpVersion.HTTP_1_1;
responseBody = null;
recoverableExceptionCount = 0;
inExecute = false;
@@ -2049,19 +2061,16 @@
statusLine = new StatusLine(statusString);
//check for a valid HTTP-Version
-String httpVersion = statusLine.getHttpVersion();
-if (httpVersion.equals(HTTP/1.0)) {
-http11 = false;
-} else if (httpVersion.equals(HTTP/1.1)) {
-http11 = true;
-} else if (httpVersion.equals(HTTP)) {
-// some servers do not specify the version correctly, we will just
assume 1.0
-http11 = false;
+String versionStr = statusLine.getHttpVersion();
+if (!this.strictMode versionStr.equals(HTTP)) {
+this.version = HttpVersion.HTTP_1_0;
+if (LOG.isWarnEnabled()) {
+LOG.warn(Ambiguous status line (HTTP protocol version missing): +
+statusLine.toString());
+}
} else {
-throw new ProtocolException(Unrecognized server protocol: '
-
cvs commit: jakarta-commons/lang/src/java/org/apache/commons/lang IntHashMap.java
scolebourne2003/07/30 14:16:13
Modified:lang/src/java/org/apache/commons/lang IntHashMap.java
Log:
Make package scoped
Format as per the [lang] coding standards
Revision ChangesPath
1.3 +50 -77
jakarta-commons/lang/src/java/org/apache/commons/lang/IntHashMap.java
Index: IntHashMap.java
===
RCS file:
/home/cvs/jakarta-commons/lang/src/java/org/apache/commons/lang/IntHashMap.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- IntHashMap.java 14 Jul 2003 22:25:02 - 1.2
+++ IntHashMap.java 30 Jul 2003 21:16:13 - 1.3
@@ -52,8 +52,9 @@
* http://www.apache.org/.
*/
-/**
- * Note: originally released under the GNU LGPL v2.1, but rereleased by the
original author under the ASF license (above).
+/*
+ * Note: originally released under the GNU LGPL v2.1,
+ * but rereleased by the original author under the ASF license (above).
*/
package org.apache.commons.lang;
@@ -66,11 +67,12 @@
*
* @author Justin Couch
* @author Alex Chaffee ([EMAIL PROTECTED])
+ * @author Stephen Colebourne
* @version $Revision$
* @see java.util.HashMap
*/
-public class IntHashMap
-{
+class IntHashMap {
+
/**
* The hash table data.
*/
@@ -100,8 +102,7 @@
* pInnerclass that acts as a datastructure to create a new entry in the
* table./p
*/
-private static class Entry
-{
+private static class Entry {
int hash;
int key;
Object value;
@@ -115,8 +116,7 @@
* @param value The value for this key
* @param next A reference to the next entry in the table
*/
-protected Entry(int hash, int key, Object value, Entry next)
-{
+protected Entry(int hash, int key, Object value, Entry next) {
this.hash = hash;
this.key = key;
this.value = value;
@@ -128,8 +128,7 @@
* pConstructs a new, empty hashtable with a default capacity and load
* factor, which is code20/code and code0.75/code respectively./p
*/
-public IntHashMap()
-{
+public IntHashMap() {
this(20, 0.75f);
}
@@ -141,8 +140,7 @@
* @throws IllegalArgumentException if the initial capacity is less
* than zero.
*/
-public IntHashMap(int initialCapacity)
-{
+public IntHashMap(int initialCapacity) {
this(initialCapacity, 0.75f);
}
@@ -155,16 +153,17 @@
* @throws IllegalArgumentException if the initial capacity is less
* than zero, or if the load factor is nonpositive.
*/
-public IntHashMap(int initialCapacity, float loadFactor)
-{
-if (initialCapacity 0)
-throw new IllegalArgumentException(Illegal Capacity: +
-initialCapacity);
-if (loadFactor = 0)
+public IntHashMap(int initialCapacity, float loadFactor) {
+super();
+if (initialCapacity 0) {
+throw new IllegalArgumentException(Illegal Capacity: +
initialCapacity);
+}
+if (loadFactor = 0) {
throw new IllegalArgumentException(Illegal Load: + loadFactor);
-
-if (initialCapacity == 0)
+}
+if (initialCapacity == 0) {
initialCapacity = 1;
+}
this.loadFactor = loadFactor;
table = new Entry[initialCapacity];
@@ -176,8 +175,7 @@
*
* @return the number of keys in this hashtable.
*/
-public int size()
-{
+public int size() {
return count;
}
@@ -187,8 +185,7 @@
* @return codetrue/code if this hashtable maps no keys to values;
* codefalse/code otherwise.
*/
-public boolean isEmpty()
-{
+public boolean isEmpty() {
return count == 0;
}
@@ -210,20 +207,15 @@
* @see#containsValue(Object)
* @seejava.util.Map
*/
-public boolean contains(Object value)
-{
-if (value == null)
-{
+public boolean contains(Object value) {
+if (value == null) {
throw new NullPointerException();
}
Entry tab[] = table;
-for (int i = tab.length; i-- 0;)
-{
-for (Entry e = tab[i]; e != null; e = e.next)
-{
-if (e.value.equals(value))
-{
+for (int i = tab.length; i-- 0;) {
+for (Entry e = tab[i]; e != null; e = e.next) {
+if (e.value.equals(value)) {
return true;
}
}
@@ -242,8 +234,7 @@
* @see
Re: [lang] So, about that 2.0....
On Wed, 30 Jul 2003, Phil Steitz wrote: Outstanding issues: - Enum tests - CharSetUtils.translate(*,*,) I have thought about the second issue some more. Correct me if I am wrong, but I think that the intention of translate(str, repl, with) is: transform str to use the with characters in place of the repl characters, with the understanding that if with contains fewer characters than repl, the last with character will be used for all of the extra repl characters. Yep. To me, this makes no sense if either with or repl is or null. In the one case that now throws ArrayOutOfBoundsException (repl positive length, with ) a case could be made that this should mean the same thing as delete(str, repl), but that is not obvious and I see no reason why this behavior should be supported in translate. Therefore, I think that the reasonable alternatives are 1. translate(str, with, repl) is a no-op (i.e. returns str unchanged) whenever with, repl is null or 2. translate(str, with, repl) throws an exception whenever with, repl is null or Personally, I like option 2 and I would rather see IllegalArgumentException thrown in all cases (including null). I would also recommend modifying the other methods in CharSetUtils that now throw NullPointerException to throw IllegalArgumentException instead. An alternative would be This seems to always be good grounds for an argument. Sun seem to throw NPEs instead of IAE's for a null. I think IAE makes more sense too, but will happily accept a sun-matching style for conformity. So... if I do: translate(, , ), you're suggesting it should throw an Exception? Or translate(foo, , ) ? I guess I'd expect that translate(x, y, y) would always be a do nothing method, no exceptions etc. Even for null. If however it was: translate(foo, null, somethingelse) or translate(foo, something, null) I would expect NPE [or IAE]. If it was: translate(foo, a, aasqqwqw) then I'd definitely expect an IAE. Tuppence-worth anyway :) Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22002] New: - [math] changed the univariate real solver factory
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22002. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22002 [math] changed the univariate real solver factory Summary: [math] changed the univariate real solver factory Product: Commons Version: unspecified Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Sandbox AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Made the UnivariateRealSolverFactory an abstract factory with one concrete factory: UnivariateRealSolverFactoryImpl. Removed the solve() convience methods from the factory and created a new UnivariateRealSolverUtil class. Added a few javadoc comments. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22002] - [math] changed the univariate real solver factory
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22002. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22002 [math] changed the univariate real solver factory --- Additional Comments From [EMAIL PROTECTED] 2003-07-30 21:54 --- Created an attachment (id=7594) patch file - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/math/src/test/org/apache/commons/math/stat BeanListUnivariateImplTest.java
tobrien 2003/07/30 14:58:11
Modified:math project.xml
math/src/java/org/apache/commons/math
MathConfigurationException.java
math/src/java/org/apache/commons/math/analysis
SplineInterpolator.java UnivariateRealFunction.java
UnivariateRealSolverFactory.java
math/src/java/org/apache/commons/math/linear
RealMatrixImpl.java
math/src/java/org/apache/commons/math/special Beta.java
Gamma.java
math/src/java/org/apache/commons/math/stat/distribution
AbstractContinuousDistribution.java
DistributionFactory.java
math/src/java/org/apache/commons/math/stat/univariate
AbstractStorelessUnivariateStatistic.java
math/src/test/org/apache/commons/math/analysis
RealSolverTest.java
math/src/test/org/apache/commons/math/stat
BeanListUnivariateImplTest.java
Log:
Bugzilla #22002: applied Brent W's patch which dealt with URSFactory and URSFImpl as
well as numerous improvements to javadoc
Revision ChangesPath
1.23 +1 -1 jakarta-commons-sandbox/math/project.xml
Index: project.xml
===
RCS file: /home/cvs/jakarta-commons-sandbox/math/project.xml,v
retrieving revision 1.22
retrieving revision 1.23
diff -u -r1.22 -r1.23
--- project.xml 9 Jul 2003 20:08:00 - 1.22
+++ project.xml 30 Jul 2003 21:58:10 - 1.23
@@ -118,7 +118,7 @@
reportmaven-license-plugin/report
!-- reportmaven-linkcheck-plugin/report --
reportmaven-statcvs-plugin/report
-!-- reportmaven-tasklist-plugin/report --
+ reportmaven-tasklist-plugin/report
/reports
/project
1.5 +5 -3
jakarta-commons-sandbox/math/src/java/org/apache/commons/math/MathConfigurationException.java
Index: MathConfigurationException.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/math/src/java/org/apache/commons/math/MathConfigurationException.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- MathConfigurationException.java 9 Jul 2003 20:02:44 - 1.4
+++ MathConfigurationException.java 30 Jul 2003 21:58:10 - 1.5
@@ -61,13 +61,14 @@
public class MathConfigurationException extends MathException {
/**
- *
+ * Default constructor.
*/
public MathConfigurationException() {
super();
}
/**
+ * Construct an exception with the given message.
* @param message message describing the problem
*/
public MathConfigurationException(String message) {
@@ -75,6 +76,7 @@
}
/**
+ * Construct an exception with the given message and root cause.
* @param message message describing the problem
* @param throwable caught exception causing this problem
*/
@@ -83,10 +85,10 @@
}
/**
+ * Construct an exception with the given root cause.
* @param throwable caught exception causing this problem
*/
public MathConfigurationException(Throwable throwable) {
super(throwable);
}
-
}
1.3 +25 -25
jakarta-commons-sandbox/math/src/java/org/apache/commons/math/analysis/SplineInterpolator.java
Index: SplineInterpolator.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/math/src/java/org/apache/commons/math/analysis/SplineInterpolator.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- SplineInterpolator.java 9 Jul 2003 20:02:43 - 1.2
+++ SplineInterpolator.java 30 Jul 2003 21:58:10 - 1.3
@@ -60,25 +60,31 @@
*
*/
public class SplineInterpolator implements UnivariateRealInterpolator {
-private double[][] c = null ;
+private double[][] c = null;
-/* (non-Javadoc)
- * @see
org.apache.commons.math.UnivariateRealInterpolator#interpolate(double[], double[])
+/**
+ * Computes an interpolating function for the data set.
+ * @param xval the arguments for the interpolation points
+ * @param yval the values for the interpolation points
+ * @return a function which interpolates the data set
+ * @throws MathException if arguments violate assumptions made by the
+ * interpolationg algorithm
*/
public UnivariateRealFunction interpolate(double[] xval, double[] yval) {
if (xval.length != yval.length) {
-throw new IllegalArgumentException(Dataset arrays must
Re: [collections] Proposal for a Timeout Affected Priority Queue
--- Cheung Lo [EMAIL PROTECTED] wrote: Proposal for a Timeout Affected Priority Queue I would like to propose the adoption of the TapQueue into the collections packages but need feedback on the following issues: 1. Has anyone else had a need for a timeout affected priority queue? 2. If so, what additional requirements did you have that is not already described? 3. How do I submit a draft of the classes - do I attach a zip file or paste into the body of an email? 4. Who do I send it to? 1. Yup, i hacked together a duct-tape and espresso solution for a situation like this a few years ago. I remember at the time not being very happy with it, and since I don't have access to that proprietary code, I can thankfully forget i had anything to do with it. I would very much like to see a first-class implementation in [collections]. 2. Your description appears to suggest that the implementation only bumps up the priority when the (single) timeout occurs. What might be preferable is to have multiple timeout points (or some other aging scheme). Here's an example. Let's say you had a priority scheme 0-9 (9 highest), and in comes a policy admin job (as from your example). This might get priority 1 (as opposed to a customer call, which might initially have priority 6). Rather than waiting until the absolute timeout occurs (say after 14 days) and then bumping the policy job priority up to 9, it would be useful if after 2 days the policy job gets bumped up to priority 2, then 2 days later to priority 3, etc. Likewise I'd like my customer calls (which initially start at priority 6) to get bumped up to priority 7 after six hours, then to priority 8, which would be the maximum priority for customer calls. With this scheme policy jobs would gradually rise in priority, rather than waiting until the deadline when the policy job would then become absolute top priority (this does sound like my normal working pattern though!). To implement this there must be some way of associating an object (or class of objects) with a particular (configurable) prioritizing scheme. All sorts of things pop into my head ;) I'd really like to see what you've come up with, and since i will probably have some OSS dev time available fairly shortly, I'd be more than happy to lend you a hand with development if needed. 34. As stephen said, a zip or a link. If the package is large (100K?) then you won't be able to mail it to the list anyway, so you would be better off with a link. - Neil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/math/src/java/org/apache/commons/math/analysis UnivariateRealSolverFactoryImpl.java UnivariateRealSolverUtil.java
tobrien 2003/07/30 15:06:37
Added: math/src/java/org/apache/commons/math/analysis
UnivariateRealSolverFactoryImpl.java
UnivariateRealSolverUtil.java
Log:
Bugzilla #22002 from Brent W's patch - refactoring of UnivariateRealSolver
Revision ChangesPath
1.1
jakarta-commons-sandbox/math/src/java/org/apache/commons/math/analysis/UnivariateRealSolverFactoryImpl.java
Index: UnivariateRealSolverFactoryImpl.java
===
/*
* The Apache Software License, Version 1.1
*
* Copyright (c) 2003 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in
*the documentation and/or other materials provided with the
*distribution.
*
* 3. The end-user documentation included with the redistribution, if
*any, must include the following acknowlegement:
* This product includes software developed by the
*Apache Software Foundation (http://www.apache.org/).
*Alternately, this acknowlegement may appear in the software itself,
*if and wherever such third-party acknowlegements normally appear.
*
* 4. The names The Jakarta Project, Commons, and Apache Software
*Foundation must not be used to endorse or promote products derived
*from this software without prior written permission. For written
*permission, please contact [EMAIL PROTECTED]
*
* 5. Products derived from this software may not be called Apache
*nor may Apache appear in their names without prior written
*permission of the Apache Software Foundation.
*
* THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
* WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
* ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
* USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
* ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
* OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
*
* This software consists of voluntary contributions made by many
* individuals on behalf of the Apache Software Foundation. For more
* information on the Apache Software Foundation, please see
* http://www.apache.org/.
*/
package org.apache.commons.math.analysis;
/**
* A factory to easily get a default solver and some convenience
* functions.
* Because solvers are easily reusable, the factory does not
* store configuration data and creates preconfigured solvers
* (this may be controversial, because the configuration data
* may also be used for the default solver used by the static
* solve() method).
* @version $Revision: 1.1 $ $Date: 2003/07/30 22:06:37 $
*/
public class UnivariateRealSolverFactoryImpl
extends UnivariateRealSolverFactory {
/**
* Default constructor.
*/
UnivariateRealSolverFactoryImpl() {
}
/**
* Create a new [EMAIL PROTECTED] UnivariateRealSolver} for the given function.
The
* actual solver returned is determined by the underlying factory.
*
* This factory returns a [EMAIL PROTECTED] BrentSolver} instance.
*
* @param f the function.
* @return the new solver.
*/
public UnivariateRealSolver newDefaultSolver(UnivariateRealFunction f) {
return newBrentSolver(f);
}
/**
* Create a new [EMAIL PROTECTED] UnivariateRealSolver} for the given function.
The
* solver is an implementation of the bisection method.
* @param f the function.
* @return the new solver.
*/
public UnivariateRealSolver newBisectionSolver(UnivariateRealFunction f) {
return new BisectionSolver(f);
}
/**
* Create a new [EMAIL PROTECTED] UnivariateRealSolver} for the given function.
The
* solver is an implementation of
Re: [lang] So, about that 2.0....
From: Henri Yandell [EMAIL PROTECTED] Therefore, I think that the reasonable alternatives are 1. translate(str, with, repl) is a no-op (i.e. returns str unchanged) whenever with, repl is null or 2. translate(str, with, repl) throws an exception whenever with, repl is null or Personally, I like option 2 and I would rather see IllegalArgumentException thrown in all cases (including null). I would also recommend modifying the other methods in CharSetUtils that now throw NullPointerException to throw IllegalArgumentException instead. An alternative would be This seems to always be good grounds for an argument. Sun seem to throw NPEs instead of IAE's for a null. I think IAE makes more sense too, but will happily accept a sun-matching style for conformity. We should avoid NPE and throw IAE wherever possible. Its the new [lang] way. I propose the clearest is: translate(*str, null, *) = *str translate(*str, , *) = *str translate(*, abc, null) = delete chars 'abc' from string translate(*, abc, ) = delete chars 'abc' from string translate(*, abc, z) = replace chars 'abc' with 'z' translate(*, abc, zyxwv) = replace chars 'a' with 'z', 'b' with 'y', 'c' with 'x', ignore 'wv' -- no errors Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22002] - [math] changed the univariate real solver factory
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22002. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22002 [math] changed the univariate real solver factory [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-07-30 22:14 --- Patch applied and site regenerated to boot. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/lang/src/java/org/apache/commons/lang CharSetUtils.java
scolebourne2003/07/30 15:17:00
Modified:lang/src/java/org/apache/commons/lang CharSetUtils.java
Log:
Update javadoc to better describe method
Revision ChangesPath
1.16 +16 -10
jakarta-commons/lang/src/java/org/apache/commons/lang/CharSetUtils.java
Index: CharSetUtils.java
===
RCS file:
/home/cvs/jakarta-commons/lang/src/java/org/apache/commons/lang/CharSetUtils.java,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -r1.15 -r1.16
--- CharSetUtils.java 30 Jul 2003 00:08:38 - 1.15
+++ CharSetUtils.java 30 Jul 2003 22:17:00 - 1.16
@@ -320,7 +320,8 @@
}
/**
- * pTranslate characters in a String./p
+ * pTranslate characters in a String.
+ * This is a multi character search and replace routine./p
*
* pAn example is:/p
* ul
@@ -331,26 +332,31 @@
* pIf the length of characters to search for is greater than the
* length of characters to replace, then the last character is
* used./p
+ *
+ * pre
+ * CharSetUtils.translate(null, *, *) = null
+ * CharSetUtils.translate(, *, *) =
+ * /pre
*
* @param str String to replace characters in, may be null
- * @param repl String to find that will be replaced, must not be null
- * @param with String to put into the target String, must not be null or empty
()
+ * @param searchChars a set of characters to search for, must not be null
+ * @param replaceChars a set of characters to replace, must not be null or
empty ()
* @return translated String, codenull/code if null string input
* @throws NullPointerException if codewith/code or coderepl/code
* is codenull/code
* @throws ArrayIndexOutOfBoundsException if codewith/code is empty ()
*/
-public static String translate(String str, String repl, String with) {
-if (str == null) {
-return null;
+public static String translate(String str, String searchChars, String
replaceChars) {
+if (str == null || str.length() == 0) {
+return str;
}
StringBuffer buffer = new StringBuffer(str.length());
char[] chrs = str.toCharArray();
-char[] withChrs = with.toCharArray();
+char[] withChrs = replaceChars.toCharArray();
int sz = chrs.length;
-int withMax = with.length() - 1;
+int withMax = replaceChars.length() - 1;
for(int i=0; isz; i++) {
-int idx = repl.indexOf(chrs[i]);
+int idx = searchChars.indexOf(chrs[i]);
if(idx != -1) {
if(idx withMax) {
idx = withMax;
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/lang/src/java/org/apache/commons/lang StringUtils.java
scolebourne2003/07/30 15:17:49
Modified:lang/src/java/org/apache/commons/lang StringUtils.java
Log:
Fixes arising from Clover report
Revision ChangesPath
1.82 +12 -12
jakarta-commons/lang/src/java/org/apache/commons/lang/StringUtils.java
Index: StringUtils.java
===
RCS file:
/home/cvs/jakarta-commons/lang/src/java/org/apache/commons/lang/StringUtils.java,v
retrieving revision 1.81
retrieving revision 1.82
diff -u -r1.81 -r1.82
--- StringUtils.java 26 Jul 2003 15:35:35 - 1.81
+++ StringUtils.java 30 Jul 2003 22:17:49 - 1.82
@@ -2331,10 +2331,10 @@
}
if (str.length() == 1) {
-if (\r.equals(str) || \n.equals(str)) {
+char ch = str.charAt(0);
+if (ch == '\r' || ch == '\n') {
return ;
-}
-else {
+} else {
return str;
}
}
@@ -2615,8 +2615,8 @@
if (repeat = 0) {
return ;
}
-int inputLength;
-if (repeat == 1 || (inputLength = str.length()) == 0) {
+int inputLength = str.length();
+if (repeat == 1 || inputLength == 0) {
return str;
}
if (inputLength == 1 repeat = PAD_LIMIT) {
@@ -2771,13 +2771,13 @@
}
int strLen = str.length();
int pads = size - strLen;
+if (pads = 0) {
+return str; // returns original String when possible
+}
if (padLen == 1 pads = PAD_LIMIT) {
return rightPad(str, size, padStr.charAt(0));
}
-if (pads = 0) {
-return str; // returns original String when possible
-}
if (pads == padLen) {
return str.concat(padStr);
} else if (pads padLen) {
@@ -2884,13 +2884,13 @@
}
int strLen = str.length();
int pads = size - strLen;
+if (pads = 0) {
+return str; // returns original String when possible
+}
if (padLen == 1 pads = PAD_LIMIT) {
return leftPad(str, size, padStr.charAt(0));
}
-if (pads = 0) {
-return str; // returns original String when possible
-}
if (pads == padLen) {
return padStr.concat(str);
} else if (pads padLen) {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/lang/src/test/org/apache/commons/lang SerializationUtilsTest.java BooleanUtilsTest.java CharSetUtilsTest.java StringUtilsEqualsIndexOfTest.java SystemUtilsTest.java StringEscapeUtilsTest.java StringUtilsTest.java RandomStringUtilsTest.java ClassUtilsTest.java StringUtilsSubstringTest.java WordWrapUtilsTest.java ArrayUtilsTest.java ObjectUtilsTest.java
scolebourne2003/07/30 15:21:40
Modified:lang/src/test/org/apache/commons/lang
SerializationUtilsTest.java BooleanUtilsTest.java
CharSetUtilsTest.java
StringUtilsEqualsIndexOfTest.java
SystemUtilsTest.java StringEscapeUtilsTest.java
StringUtilsTest.java RandomStringUtilsTest.java
ClassUtilsTest.java StringUtilsSubstringTest.java
WordWrapUtilsTest.java ArrayUtilsTest.java
ObjectUtilsTest.java
Log:
Additional tests as suggested by Clover report
Revision ChangesPath
1.4 +34 -2
jakarta-commons/lang/src/test/org/apache/commons/lang/SerializationUtilsTest.java
Index: SerializationUtilsTest.java
===
RCS file:
/home/cvs/jakarta-commons/lang/src/test/org/apache/commons/lang/SerializationUtilsTest.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- SerializationUtilsTest.java 19 Jul 2003 20:22:36 - 1.3
+++ SerializationUtilsTest.java 30 Jul 2003 22:21:39 - 1.4
@@ -57,6 +57,8 @@
import java.io.ByteArrayOutputStream;
import java.io.InputStream;
import java.io.ObjectOutputStream;
+import java.lang.reflect.Constructor;
+import java.lang.reflect.Modifier;
import java.util.HashMap;
import junit.framework.Test;
@@ -105,7 +107,37 @@
}
//---
-
+public void testConstructor() {
+assertNotNull(new SerializationUtils());
+Constructor[] cons = SerializationUtils.class.getDeclaredConstructors();
+assertEquals(1, cons.length);
+assertEquals(true, Modifier.isPublic(cons[0].getModifiers()));
+assertEquals(true,
Modifier.isPublic(SerializationUtils.class.getModifiers()));
+assertEquals(false,
Modifier.isFinal(SerializationUtils.class.getModifiers()));
+}
+
+public void testException() {
+SerializationException serEx;
+Exception ex = new Exception();
+
+serEx = new SerializationException();
+assertSame(null, serEx.getMessage());
+assertSame(null, serEx.getCause());
+
+serEx = new SerializationException(Message);
+assertSame(Message, serEx.getMessage());
+assertSame(null, serEx.getCause());
+
+serEx = new SerializationException(ex);
+assertEquals(java.lang.Exception, serEx.getMessage());
+assertSame(ex, serEx.getCause());
+
+serEx = new SerializationException(Message, ex);
+assertSame(Message, serEx.getMessage());
+assertSame(ex, serEx.getCause());
+}
+
+//---
public void testSerializeStream() throws Exception {
ByteArrayOutputStream streamTest = new ByteArrayOutputStream();
SerializationUtils.serialize(iMap, streamTest);
1.5 +47 -2
jakarta-commons/lang/src/test/org/apache/commons/lang/BooleanUtilsTest.java
Index: BooleanUtilsTest.java
===
RCS file:
/home/cvs/jakarta-commons/lang/src/test/org/apache/commons/lang/BooleanUtilsTest.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- BooleanUtilsTest.java 28 Jun 2003 18:16:03 - 1.4
+++ BooleanUtilsTest.java 30 Jul 2003 22:21:39 - 1.5
@@ -53,6 +53,9 @@
*/
package org.apache.commons.lang;
+import java.lang.reflect.Constructor;
+import java.lang.reflect.Modifier;
+
import junit.framework.Test;
import junit.framework.TestCase;
import junit.framework.TestSuite;
@@ -90,6 +93,16 @@
}
//---
+public void testConstructor() {
+assertNotNull(new BooleanUtils());
+Constructor[] cons = BooleanUtils.class.getDeclaredConstructors();
+assertEquals(1, cons.length);
+assertEquals(true, Modifier.isPublic(cons[0].getModifiers()));
+assertEquals(true, Modifier.isPublic(BooleanUtils.class.getModifiers()));
+assertEquals(false, Modifier.isFinal(BooleanUtils.class.getModifiers()));
+}
+
+//---
public void test_negate_Boolean() {
assertSame(null, BooleanUtils.negate(null));
assertSame(Boolean.TRUE, BooleanUtils.negate(Boolean.FALSE));
@@ -151,6 +164,14 @@
public void test_toBoolean_Integer_Integer_Integer() {
Integer six = new Integer(6);
Integer seven = new Integer(7);
+
+
cvs commit: jakarta-commons/codec/src/test/org/apache/commons/codec/binary Base64Test.java HexTest.java
tobrien 2003/07/30 15:34:18
Modified:codec/src/java/org/apache/commons/codec BinaryDecoder.java
BinaryEncoder.java Decoder.java
DecoderException.java Encoder.java
EncoderException.java StringDecoder.java
StringEncoder.java StringEncoderComparator.java
codec/src/java/org/apache/commons/codec/binary Base64.java
Hex.java
codec/src/java/org/apache/commons/codec/language
Metaphone.java RefinedSoundex.java Soundex.java
codec/src/test/org/apache/commons/codec
BinaryEncoderAbstractTest.java
StringEncoderAbstractTest.java
StringEncoderComparatorTest.java
codec/src/test/org/apache/commons/codec/binary
Base64Test.java HexTest.java
Log:
author tag change, removed my email address from author tags
Revision ChangesPath
1.3 +2 -2
jakarta-commons/codec/src/java/org/apache/commons/codec/BinaryDecoder.java
Index: BinaryDecoder.java
===
RCS file:
/home/cvs/jakarta-commons/codec/src/java/org/apache/commons/codec/BinaryDecoder.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- BinaryDecoder.java25 Jul 2003 22:48:11 - 1.2
+++ BinaryDecoder.java30 Jul 2003 22:34:17 - 1.3
@@ -59,7 +59,7 @@
* This interface defines common decoding methods for decoders
* which decode byte arrays.
*
- * @author a href=mailto:[EMAIL PROTECTED]Tim O'Brien/a
+ * @author Tim O'Brien
* @version $Id$
*/
public interface BinaryDecoder extends Decoder {
1.3 +2 -2
jakarta-commons/codec/src/java/org/apache/commons/codec/BinaryEncoder.java
Index: BinaryEncoder.java
===
RCS file:
/home/cvs/jakarta-commons/codec/src/java/org/apache/commons/codec/BinaryEncoder.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- BinaryEncoder.java25 Jul 2003 22:48:11 - 1.2
+++ BinaryEncoder.java30 Jul 2003 22:34:17 - 1.3
@@ -57,7 +57,7 @@
* A binary encoder contains methods common to all
* encoders for binary data.
*
- * @author a href=[EMAIL PROTECTED]Tim O'Brien/a
+ * @author Tim O'Brien
* @version $Id$
*/
public interface BinaryEncoder extends Encoder {
1.3 +2 -2
jakarta-commons/codec/src/java/org/apache/commons/codec/Decoder.java
Index: Decoder.java
===
RCS file:
/home/cvs/jakarta-commons/codec/src/java/org/apache/commons/codec/Decoder.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- Decoder.java 25 Jul 2003 22:48:11 - 1.2
+++ Decoder.java 30 Jul 2003 22:34:17 - 1.3
@@ -59,7 +59,7 @@
* which allows a user to pass a generic Object to any
* Decoder implementation in the codec package.
*
- * @author a href=[EMAIL PROTECTED]Tim O'Brien/a
+ * @author Tim O'Brien
* @version $Id$
*/
public interface Decoder {
1.3 +2 -2
jakarta-commons/codec/src/java/org/apache/commons/codec/DecoderException.java
Index: DecoderException.java
===
RCS file:
/home/cvs/jakarta-commons/codec/src/java/org/apache/commons/codec/DecoderException.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- DecoderException.java 25 Jul 2003 22:48:11 - 1.2
+++ DecoderException.java 30 Jul 2003 22:34:17 - 1.3
@@ -57,7 +57,7 @@
* The DecoderException is thrown when a Decoder has
* encounter a failure condition during a decode.
*
- * @author a href=[EMAIL PROTECTED]Tim O'Brien/a
+ * @author Tim O'Brien
* @version $Id$
*/
public class DecoderException extends Exception {
1.3 +2 -2
jakarta-commons/codec/src/java/org/apache/commons/codec/Encoder.java
Index: Encoder.java
===
RCS file:
/home/cvs/jakarta-commons/codec/src/java/org/apache/commons/codec/Encoder.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- Encoder.java 25 Jul 2003 22:48:11 - 1.2
+++ Encoder.java 30 Jul 2003 22:34:17 - 1.3
@@ -58,7 +58,7 @@
* the highest level of abstraction for Encoders. All
* Encoders implement this common generic interface.
*
- * @author a href=[EMAIL PROTECTED]Tim O'Brien/a
+ * @author Tim O'Brien
* @version $Id$
*/
public interface Encoder {
1.3 +2 -2
DO NOT REPLY [Bug 21605] - [codec] Broken link report
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21605. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21605 [codec] Broken link report [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-07-30 22:43 --- Fixed some of the email broken links, but I don't understand how this tool considers http://www.apache.org/ to be a broken link. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21800] - because The OutputStreamWriter not flush, so short String will encoded error...
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21800. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21800 because The OutputStreamWriter not flush, so short String will encoded error... --- Additional Comments From [EMAIL PROTECTED] 2003-07-30 22:46 --- Huh?! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Jelly] Bug with static
I am not 100% where to post this bug report, but using Jelly I cannot refrence anything that's static or a constant. For example, I want to use DateFormat.parse, but cannot because it's static. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Jelly] Bug with static
Use the invokeState tag. It is part of the core tags. for example: j:invokeStatic var=ps className=java.text.DateFormat method=parse arg /j:invokeStatice Robert Sean W. Ferguson wrote: I am not 100% where to post this bug report, but using Jelly I cannot refrence anything that's static or a constant. For example, I want to use DateFormat.parse, but cannot because it's static. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] So, about that 2.0....
We should avoid NPE and throw IAE wherever possible. Its the new [lang] way. I propose the clearest is: translate(*str, null, *) = *str translate(*str, , *) = *str translate(*, abc, null) = delete chars 'abc' from string translate(*, abc, ) = delete chars 'abc' from string translate(*, abc, z) = replace chars 'abc' with 'z' translate(*, abc, zyxwv) = replace chars 'a' with 'z', 'b' with 'y', 'c' with 'x', ignore 'wv' -- no errors These make sense to me. Also, thanks for changing the parameter names ;-) Some other interesting cases that should be documented are translate(ab, aa, ab) = ab (I think, can't test now) translate(ab, ab, cc) = cc Phil Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/lang/src/test/org/apache/commons/lang/enum DummyEnum.java EnumTest.java EnumUtilsTest.java
scolebourne2003/07/30 16:13:09
Modified:lang/src/java/org/apache/commons/lang/enum Enum.java
ValuedEnum.java
lang/src/test/org/apache/commons/lang/enum EnumTest.java
EnumUtilsTest.java
Added: lang/src/test/org/apache/commons/lang/enum DummyEnum.java
Log:
Extra tests and optimisations suggested by Clover
Revision ChangesPath
1.16 +27 -11
jakarta-commons/lang/src/java/org/apache/commons/lang/enum/Enum.java
Index: Enum.java
===
RCS file:
/home/cvs/jakarta-commons/lang/src/java/org/apache/commons/lang/enum/Enum.java,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -r1.15 -r1.16
--- Enum.java 20 Jul 2003 15:49:58 - 1.15
+++ Enum.java 30 Jul 2003 23:13:09 - 1.16
@@ -63,6 +63,7 @@
import java.util.List;
import java.util.Map;
+import org.apache.commons.lang.ClassUtils;
import org.apache.commons.lang.StringUtils;
/**
@@ -206,9 +207,12 @@
* @version $Id$
*/
public abstract class Enum implements Comparable, Serializable {
+
+/** Serialization id */
+static final long serialVersionUID = -487045951170455942L;
+
// After discussion, the default size for HashMaps is used, as the
// sizing algorithm changes across the JDK versions
-
/**
* An empty codeMap/code, as JDK1.2 didn't have an empty map.
*/
@@ -221,6 +225,14 @@
* The string representation of the Enum.
*/
private final String iName;
+/**
+ * The hashcode representation of the Enum.
+ */
+private transient final int iHashCode;
+/**
+ * The toString representation of the Enum.
+ */
+protected transient String iToString = null;
/**
* pEnable the iterator to retain the source code order./p
@@ -268,6 +280,9 @@
}
entry.map.put(name, this);
entry.list.add(this);
+
+iHashCode = 7 + enumClass.hashCode() + 3 * name.hashCode();
+// cannot create toString here as subclasses may want to include other data
}
/**
@@ -490,7 +505,7 @@
* @return a hashcode based on the name
*/
public final int hashCode() {
-return 7 + iName.hashCode();
+return iHashCode;
}
/**
@@ -507,25 +522,26 @@
* @throws NullPointerException if other is codenull/code
*/
public int compareTo(Object other) {
+if (other == this) {
+return 0;
+}
return iName.compareTo(((Enum) other).iName);
}
/**
* pHuman readable description of this Enum item./p
- *
- * pFor use when debugging./p
*
* @return String in the form codetype[name]/code, for example:
* codeColor[Red]/code. Note that the package name is stripped from
* the type name.
*/
public String toString() {
-String shortName = Enum.getEnumClass(getClass()).getName();
-int pos = shortName.lastIndexOf('.');
-if (pos != -1) {
-shortName = shortName.substring(pos + 1);
+if (iToString == null) {
+Class cls = Enum.getEnumClass(getClass());
+String shortName = ClassUtils.getShortClassName(cls);
+iToString = shortName + [ + getName() + ];
}
-shortName = shortName.replace('$', '.');
-return shortName + [ + getName() + ];
+return iToString;
}
+
}
1.9 +8 -9
jakarta-commons/lang/src/java/org/apache/commons/lang/enum/ValuedEnum.java
Index: ValuedEnum.java
===
RCS file:
/home/cvs/jakarta-commons/lang/src/java/org/apache/commons/lang/enum/ValuedEnum.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- ValuedEnum.java 20 Jul 2003 15:49:58 - 1.8
+++ ValuedEnum.java 30 Jul 2003 23:13:09 - 1.9
@@ -56,6 +56,8 @@
import java.util.Iterator;
import java.util.List;
+import org.apache.commons.lang.ClassUtils;
+
/**
* pAbstract superclass for type-safe enums with integer values suitable
* for use in codeswitch/code statements./p
@@ -205,19 +207,16 @@
/**
* pHuman readable description of this codeEnum/code item./p
*
- * pFor use when debugging./p
- *
* @return String in the form codetype[name=value]/code, for example:
* codeJavaVersion[Java 1.0=100]/code. Note that the package name is
* stripped from the type name.
*/
public String toString() {
-String shortName = Enum.getEnumClass(getClass()).getName();
-int pos = shortName.lastIndexOf('.');
-if (pos
cvs commit: jakarta-commons/lang/src/java/org/apache/commons/lang/enum Enum.java ValuedEnum.java
scolebourne2003/07/30 16:17:23
Modified:lang/src/java/org/apache/commons/lang/enum Enum.java
ValuedEnum.java
Log:
Lang version 1.0.1 serial compatability
Revision ChangesPath
1.17 +2 -2
jakarta-commons/lang/src/java/org/apache/commons/lang/enum/Enum.java
Index: Enum.java
===
RCS file:
/home/cvs/jakarta-commons/lang/src/java/org/apache/commons/lang/enum/Enum.java,v
retrieving revision 1.16
retrieving revision 1.17
diff -u -r1.16 -r1.17
--- Enum.java 30 Jul 2003 23:13:09 - 1.16
+++ Enum.java 30 Jul 2003 23:17:23 - 1.17
@@ -208,7 +208,7 @@
*/
public abstract class Enum implements Comparable, Serializable {
-/** Serialization id */
+/** Lang version 1.0.1 serial compatability */
static final long serialVersionUID = -487045951170455942L;
// After discussion, the default size for HashMaps is used, as the
1.10 +5 -1
jakarta-commons/lang/src/java/org/apache/commons/lang/enum/ValuedEnum.java
Index: ValuedEnum.java
===
RCS file:
/home/cvs/jakarta-commons/lang/src/java/org/apache/commons/lang/enum/ValuedEnum.java,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- ValuedEnum.java 30 Jul 2003 23:13:09 - 1.9
+++ ValuedEnum.java 30 Jul 2003 23:17:23 - 1.10
@@ -136,6 +136,10 @@
* @version $Id$
*/
public abstract class ValuedEnum extends Enum {
+
+/** Lang version 1.0.1 serial compatability */
+static final long serialVersionUID = -7129650521543789085L;
+
/**
* The value contained in enum.
*/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/lang/src/java/org/apache/commons/lang/enum EnumUtils.java
scolebourne2003/07/30 16:21:39
Modified:lang/src/test/org/apache/commons/lang/enum
EnumUtilsTest.java
lang/src/java/org/apache/commons/lang/enum EnumUtils.java
Log:
Bring EnumUtils public constructor testing in line with main package
Revision ChangesPath
1.5 +18 -1
jakarta-commons/lang/src/test/org/apache/commons/lang/enum/EnumUtilsTest.java
Index: EnumUtilsTest.java
===
RCS file:
/home/cvs/jakarta-commons/lang/src/test/org/apache/commons/lang/enum/EnumUtilsTest.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- EnumUtilsTest.java30 Jul 2003 23:13:09 - 1.4
+++ EnumUtilsTest.java30 Jul 2003 23:21:39 - 1.5
@@ -53,6 +53,8 @@
*/
package org.apache.commons.lang.enum;
+import java.lang.reflect.Constructor;
+import java.lang.reflect.Modifier;
import java.util.Iterator;
import java.util.List;
import java.util.Map;
@@ -83,6 +85,17 @@
return suite;
}
+//---
+public void testConstructor() {
+assertNotNull(new EnumUtils());
+Constructor[] cons = EnumUtils.class.getDeclaredConstructors();
+assertEquals(1, cons.length);
+assertEquals(true, Modifier.isPublic(cons[0].getModifiers()));
+assertEquals(true, Modifier.isPublic(EnumUtils.class.getModifiers()));
+assertEquals(false, Modifier.isFinal(EnumUtils.class.getModifiers()));
+}
+
+//---
public void testIterator() {
Iterator it = EnumUtils.iterator(ColorEnum.class);
assertSame(ColorEnum.RED, it.next());
@@ -103,6 +116,7 @@
} catch (IllegalArgumentException ex) {}
}
+//---
public void testList() {
List list = EnumUtils.getEnumList(ColorEnum.class);
Iterator it = list.iterator();
@@ -124,6 +138,7 @@
} catch (IllegalArgumentException ex) {}
}
+//---
public void testMap() {
Map map = EnumUtils.getEnumMap(ColorEnum.class);
assertTrue(map.containsValue(ColorEnum.RED));
@@ -147,6 +162,7 @@
} catch (IllegalArgumentException ex) {}
}
+//---
public void testGet() {
assertSame(ColorEnum.RED, EnumUtils.getEnum(ColorEnum.class, Red));
assertSame(ColorEnum.GREEN, EnumUtils.getEnum(ColorEnum.class, Green));
@@ -166,6 +182,7 @@
} catch (IllegalArgumentException ex) {}
}
+//---
public void testGetValue() {
assertSame(ValuedColorEnum.RED, EnumUtils.getEnum(ValuedColorEnum.class,
1));
assertSame(ValuedColorEnum.GREEN, EnumUtils.getEnum(ValuedColorEnum.class,
2));
1.8 +3 -3
jakarta-commons/lang/src/java/org/apache/commons/lang/enum/EnumUtils.java
Index: EnumUtils.java
===
RCS file:
/home/cvs/jakarta-commons/lang/src/java/org/apache/commons/lang/enum/EnumUtils.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- EnumUtils.java14 Jul 2003 22:25:04 - 1.7
+++ EnumUtils.java30 Jul 2003 23:21:39 - 1.8
@@ -69,9 +69,9 @@
public class EnumUtils {
/**
- * Restricted constructor.
+ * Public constructor. This class should not normally be instantiated.
*/
-private EnumUtils() {
+public EnumUtils() {
}
/**
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] Clover coverage report for Lang 2.0
Another clover run would be useful ;-) We were at 86.6% overall, we should be a bit better now. Hopefully lang and enum will be about 95% Stephen - Original Message - From: Henri Yandell [EMAIL PROTECTED] http://www.thecortex.net/clover/index.html is the clover homepage btw. It used to integrate into Maven, so I assume it still does. I'm not sure what the ? marks in the margin mean. I guess that it can't test them. Hen On Wed, 30 Jul 2003, Henri Yandell wrote: I've been wanting to play with Clover, so took the time out to figure it out a little and run it on Lang. I generated the HTML report [there's a PDF, XML and a GUI as well] which is available at: http://www.flamefew.net/~hen/lang/clover_html/ Clover seems like a pretty good tool to show us which bits aren't tested yet. I had included the reflect sub-package, but it sucks in comparison to the others test-wise so I decided to go just with 2.0. It's just a 30 day evaluation, but open-source projects can get free licences, so if it's of use we can do that. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[io] questions about action items
I have time to do some work, so, in looking at the action items, I have a few questions... 1) Compress - Move the compress sub-package out of IO - READY What does this mean exactly? Where is it being moved to? 2) Extract code from IOUtils to CopyUtils? Should I go ahead and start this? 3) FileUtils: This class is a big mess ATM. We need to clean it up. I believe FileUtils was somehow involved in the huge static/final/inheritance debate. Are there any ideas as to how to approach the cleanup of this class? Should the String methods be deprecated and moved into another class? This requires a good plan. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [io] questions about action items
On Wed, 30 Jul 2003, __matthewHawthorne wrote: I have time to do some work, so, in looking at the action items, I have a few questions... 1) Compress - Move the compress sub-package out of IO - READY What does this mean exactly? Where is it being moved to? Somewhere else :) Reason for it not being moved yet is due to exactly your question. Where do we stick it and what do we name that. I'll leave the other questions for Jeremias. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] So, about that 2.0....
On Wed, 30 Jul 2003, Stephen Colebourne wrote: We should avoid NPE and throw IAE wherever possible. Its the new [lang] way. If it's not in the DEV-GUIDE, I'll stick it in now. I propose the clearest is: translate(*str, null, *) = *str translate(*str, , *) = *str translate(*, abc, null) = delete chars 'abc' from string translate(*, abc, ) = delete chars 'abc' from string translate(*, abc, z) = replace chars 'abc' with 'z' translate(*, abc, zyxwv) = replace chars 'a' with 'z', 'b' with 'y', 'c' with 'x', ignore 'wv' -- no errors +1 Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] Clover coverage report for Lang 2.0
Got a game of football tonight, but will re-run clover when I get back and re-post the url. Hen On Thu, 31 Jul 2003, Stephen Colebourne wrote: Another clover run would be useful ;-) We were at 86.6% overall, we should be a bit better now. Hopefully lang and enum will be about 95% Stephen - Original Message - From: Henri Yandell [EMAIL PROTECTED] http://www.thecortex.net/clover/index.html is the clover homepage btw. It used to integrate into Maven, so I assume it still does. I'm not sure what the ? marks in the margin mean. I guess that it can't test them. Hen On Wed, 30 Jul 2003, Henri Yandell wrote: I've been wanting to play with Clover, so took the time out to figure it out a little and run it on Lang. I generated the HTML report [there's a PDF, XML and a GUI as well] which is available at: http://www.flamefew.net/~hen/lang/clover_html/ Clover seems like a pretty good tool to show us which bits aren't tested yet. I had included the reflect sub-package, but it sucks in comparison to the others test-wise so I decided to go just with 2.0. It's just a 30 day evaluation, but open-source projects can get free licences, so if it's of use we can do that. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/lang DEVELOPERS-GUIDE.html
bayard 2003/07/30 16:54:33 Modified:lang DEVELOPERS-GUIDE.html Log: Added note that XxxUtils classes are not to be final. Revision ChangesPath 1.2 +2 -1 jakarta-commons/lang/DEVELOPERS-GUIDE.html Index: DEVELOPERS-GUIDE.html === RCS file: /home/cvs/jakarta-commons/lang/DEVELOPERS-GUIDE.html,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- DEVELOPERS-GUIDE.html 22 Dec 2002 21:07:35 - 1.1 +++ DEVELOPERS-GUIDE.html 30 Jul 2003 23:54:33 - 1.2 @@ -58,6 +58,7 @@ lihave a name consisting of the interface name plus 'Utils'/li lideal with one class or interface and its variations (subclasses)/li liprovide methods that perform useful utility functions/li +lithe class will not be final/li /ul pA utility class can act as a factory for specific implementations of a class or - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/lang DEVELOPERS-GUIDE.html
bayard 2003/07/30 16:58:36 Modified:lang DEVELOPERS-GUIDE.html Log: Added note that IllegalArgumentException should be thrown when a bad argument of 'null' is passed in and not NullPointerException. Also a note that XxxUtils classes should suppress Exceptions when sensible. Revision ChangesPath 1.3 +8 -1 jakarta-commons/lang/DEVELOPERS-GUIDE.html Index: DEVELOPERS-GUIDE.html === RCS file: /home/cvs/jakarta-commons/lang/DEVELOPERS-GUIDE.html,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- DEVELOPERS-GUIDE.html 30 Jul 2003 23:54:33 - 1.2 +++ DEVELOPERS-GUIDE.html 30 Jul 2003 23:58:36 - 1.3 @@ -59,6 +59,8 @@ lideal with one class or interface and its variations (subclasses)/li liprovide methods that perform useful utility functions/li lithe class will not be final/li +limethods should generally be 'nice' and 'quiet'. That is, they should +suppress Exceptions when sensible. /li /ul pA utility class can act as a factory for specific implementations of a class or @@ -99,6 +101,11 @@ pIf an example is needed enclose it with lt;pregt;lt;/pregt;. It should be supported with an explanation within a normal paragraph./p + +h4Exception throwing/h4 +pWhen throwing an exception to indicate a bad argument, always throw +IllegalArgumentException, even if the argument was null. Do not throw +NullPointerException. /p /body /html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [lang] DEVELOPERS-GUIDE.html
I've added: lithe class will not be final/li limethods should generally be 'nice' and 'quiet'. That is, they should suppress Exceptions when sensible. /li as rules for XxxUtils and also: h4Exception throwing/h4 pWhen throwing an exception to indicate a bad argument, always throw IllegalArgumentException, even if the argument was null. Do not throw NullPointerException. /p Is the 'nice' and 'quiet' one okay? Or should I ignore it because there are times when XxxUtils might want to throw Exceptions. ie) JdbcUtils would throw SQLException from everything and IOUtils should throw IOException from everything. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [lang] So, about that 2.0....
Steven Caswell [EMAIL PROTECTED] a.k.a Mungo Knotwise of Michel Delving One ring to rule them all, one ring to find them... -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 30, 2003 6:50 PM To: Jakarta Commons Developers List Subject: Re: [lang] So, about that 2.0 On Wed, 30 Jul 2003, Stephen Colebourne wrote: We should avoid NPE and throw IAE wherever possible. Its the new [lang] way. If it's not in the DEV-GUIDE, I'll stick it in now. I propose the clearest is: translate(*str, null, *) = *str translate(*str, , *) = *str translate(*, abc, null) = delete chars 'abc' from string translate(*, abc, ) = delete chars 'abc' from string translate(*, abc, z) = replace chars 'abc' with 'z' translate(*, abc, zyxwv) = replace chars 'a' with 'z', 'b' with 'y', 'c' with 'x', ignore 'wv' -- no errors +1 +1 Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] Clover coverage report for Lang 2.0
Actually it's really easy and who needs to warm up :) Re-run of clover done and up at: http://www.flamefew.net/~hen/lang/clover_html/ [though possibly I should have kept the old one] Hasn't changed as much as Stephen hoped :) Hen On Wed, 30 Jul 2003, Henri Yandell wrote: Got a game of football tonight, but will re-run clover when I get back and re-post the url. Hen On Thu, 31 Jul 2003, Stephen Colebourne wrote: Another clover run would be useful ;-) We were at 86.6% overall, we should be a bit better now. Hopefully lang and enum will be about 95% Stephen - Original Message - From: Henri Yandell [EMAIL PROTECTED] http://www.thecortex.net/clover/index.html is the clover homepage btw. It used to integrate into Maven, so I assume it still does. I'm not sure what the ? marks in the margin mean. I guess that it can't test them. Hen On Wed, 30 Jul 2003, Henri Yandell wrote: I've been wanting to play with Clover, so took the time out to figure it out a little and run it on Lang. I generated the HTML report [there's a PDF, XML and a GUI as well] which is available at: http://www.flamefew.net/~hen/lang/clover_html/ Clover seems like a pretty good tool to show us which bits aren't tested yet. I had included the reflect sub-package, but it sucks in comparison to the others test-wise so I decided to go just with 2.0. It's just a 30 day evaluation, but open-source projects can get free licences, so if it's of use we can do that. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [lang] DEVELOPERS-GUIDE.html
--- Henri Yandell [EMAIL PROTECTED] wrote: I've added: lithe class will not be final/li limethods should generally be 'nice' and 'quiet'. That is, they should suppress Exceptions when sensible. /li This sounds fairly dangerous. Methods should always throw appropriate exceptions and never suppress them entirely. as rules for XxxUtils and also: h4Exception throwing/h4 pWhen throwing an exception to indicate a bad argument, always throw IllegalArgumentException, even if the argument was null. Do not throw NullPointerException. /p This could be interpreted to mean that methods should check for null parameters. I hope that's not what it means because that would be a huge pain. Plus it would defeat the entire purpose of the JVM checking null for you! David Is the 'nice' and 'quiet' one okay? Or should I ignore it because there are times when XxxUtils might want to throw Exceptions. ie) JdbcUtils would throw SQLException from everything and IOUtils should throw IOException from everything. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/httpclient/src/java/org/apache/commons/httpclient SimpleHttpConnectionManager.java MultiThreadedHttpConnectionManager.java HttpConnection.java HostConfiguration.java
mbecke 2003/07/30 19:31:09
Modified:httpclient/src/java/org/apache/commons/httpclient Tag:
HTTPCLIENT_2_0_BRANCH
SimpleHttpConnectionManager.java
MultiThreadedHttpConnectionManager.java
HttpConnection.java HostConfiguration.java
Log:
Added support for disabling HttpConnection.isStale() as well as more connection
logging in MultiThreadedHttpConnectionManager.
Submitted by: Michael Becke
Reviewed by: Oleg Kalnichevski
Revision ChangesPath
No revision
No revision
1.12.2.1 +32 -4
jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/SimpleHttpConnectionManager.java
Index: SimpleHttpConnectionManager.java
===
RCS file:
/home/cvs/jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/SimpleHttpConnectionManager.java,v
retrieving revision 1.12
retrieving revision 1.12.2.1
diff -u -r1.12 -r1.12.2.1
--- SimpleHttpConnectionManager.java 12 May 2003 02:42:42 - 1.12
+++ SimpleHttpConnectionManager.java 31 Jul 2003 02:31:09 - 1.12.2.1
@@ -84,6 +84,9 @@
/** The http connection */
private HttpConnection httpConnection;
+/** The value to set when calling setStaleCheckingEnabled() on connections */
+private boolean connectionStaleCheckingEnabled = true;
+
/**
* Constructor for SimpleHttpConnectionManager.
*/
@@ -99,6 +102,29 @@
}
/**
+ * Gets the staleCheckingEnabled value to be set on HttpConnections that are
created.
+ *
+ * @return codetrue/code if stale checking will be enabled on HttpConections
+ *
+ * @see HttpConnection#isStaleCheckingEnabled()
+ */
+public boolean isConnectionStaleCheckingEnabled() {
+return connectionStaleCheckingEnabled;
+}
+
+/**
+ * Sets the staleCheckingEnabled value to be set on HttpConnections that are
created.
+ *
+ * @param connectionStaleCheckingEnabled codetrue/code if stale checking
will be enabled
+ * on HttpConections
+ *
+ * @see HttpConnection#setStaleCheckingEnabled(boolean)
+ */
+public void setConnectionStaleCheckingEnabled(boolean
connectionStaleCheckingEnabled) {
+this.connectionStaleCheckingEnabled = connectionStaleCheckingEnabled;
+}
+
+/**
* @see HttpConnectionManager#getConnection(HostConfiguration, long)
*/
public HttpConnection getConnection(
@@ -106,6 +132,7 @@
if (httpConnection == null) {
httpConnection = new HttpConnection(hostConfiguration);
+httpConnection.setStaleCheckingEnabled(connectionStaleCheckingEnabled);
} else {
// make sure the host and proxy are correct for this connection
@@ -117,6 +144,8 @@
httpConnection.close();
}
+
httpConnection.setStaleCheckingEnabled(connectionStaleCheckingEnabled);
+
httpConnection.setHost(hostConfiguration.getHost());
httpConnection.setVirtualHost(hostConfiguration.getVirtualHost());
httpConnection.setPort(hostConfiguration.getPort());
@@ -131,7 +160,6 @@
}
return httpConnection;
-
}
/**
1.17.2.2 +101 -18
jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/MultiThreadedHttpConnectionManager.java
Index: MultiThreadedHttpConnectionManager.java
===
RCS file:
/home/cvs/jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/MultiThreadedHttpConnectionManager.java,v
retrieving revision 1.17.2.1
retrieving revision 1.17.2.2
diff -u -r1.17.2.1 -r1.17.2.2
--- MultiThreadedHttpConnectionManager.java 23 Jul 2003 01:47:20 -
1.17.2.1
+++ MultiThreadedHttpConnectionManager.java 31 Jul 2003 02:31:09 -
1.17.2.2
@@ -69,6 +69,7 @@
import java.lang.ref.Reference;
import java.lang.ref.ReferenceQueue;
import java.lang.ref.WeakReference;
+import java.net.InetAddress;
import java.net.SocketException;
import java.util.Collections;
import java.util.HashMap;
@@ -109,6 +110,9 @@
/** Maximum number of connections allowed overall */
private int maxTotalConnections = DEFAULT_MAX_TOTAL_CONNECTIONS;
+/** The value to set when calling setStaleCheckingEnabled() on each connection
*/
+private boolean connectionStaleCheckingEnabled = true;
+
/** Connection Pool */
private ConnectionPool connectionPool;
@@ -132,7 +136,29 @@
this.referenceQueue = new ReferenceQueue();
new ReferenceQueueThread().start();
+}
+
cvs commit: jakarta-commons/httpclient/src/java/org/apache/commons/httpclient HttpConnection.java SimpleHttpConnectionManager.java MultiThreadedHttpConnectionManager.java HostConfiguration.java
mbecke 2003/07/30 19:47:30
Modified:httpclient/src/java/org/apache/commons/httpclient
HttpConnection.java
SimpleHttpConnectionManager.java
MultiThreadedHttpConnectionManager.java
HostConfiguration.java
Log:
Added support for disabling HttpConnection.isStale() as well as more connection
logging in MultiThreadedHttpConnectionManager.
Submitted by: Michael Becke
Reviewed by: Oleg Kalnichevski
Revision ChangesPath
1.70 +33 -33
jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/HttpConnection.java
Index: HttpConnection.java
===
RCS file:
/home/cvs/jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/HttpConnection.java,v
retrieving revision 1.69
retrieving revision 1.70
diff -u -r1.69 -r1.70
--- HttpConnection.java 16 Jul 2003 20:48:27 - 1.69
+++ HttpConnection.java 31 Jul 2003 02:47:30 - 1.70
@@ -207,32 +207,6 @@
throw new IllegalArgumentException(protocol is null);
}
-if (LOG.isDebugEnabled()) {
-StringBuffer buffer = new StringBuffer();
-buffer.append(Creating connection for );
-buffer.append(host);
-if (virtualHost != null) {
-buffer.append([);
-buffer.append(virtualHost);
-buffer.append(]);
-}
-if (port 0) {
-buffer.append(:);
-buffer.append(port);
-}
-if (proxyHost != null) {
-buffer.append( via );
-buffer.append(proxyHost);
-if (proxyPort 0) {
-buffer.append(:);
-buffer.append(proxyPort);
-}
-}
-buffer.append( using protocol );
-buffer.append(protocol.toString());
-LOG.debug(buffer.toString());
-}
-
proxyHostName = proxyHost;
proxyPortNumber = proxyPort;
hostName = host;
@@ -419,7 +393,7 @@
* @return tttrue/tt if I am connected
*/
public boolean isOpen() {
-if (used isStale()) {
+if (used isStaleCheckingEnabled() isStale()) {
LOG.debug(Connection is stale, closing...);
close();
}
@@ -427,7 +401,30 @@
}
/**
- * Determines whether a connection is stale, which is to say that either
+ * Tests if stale checking is enabled.
+ *
+ * @return codetrue/code if enabled
+ *
+ * @see #isStale()
+ */
+public boolean isStaleCheckingEnabled() {
+return staleCheckingEnabled;
+}
+
+/**
+ * Sets whether or not isStale() will be called when testing if this connection
is open.
+ *
+ * @param staleCheckingEnabled codetrue/code to enable isStale()
+ *
+ * @see #isStale()
+ * @see #isOpen()
+ */
+public void setStaleCheckingEnabled(boolean staleCheckEnabled) {
+this.staleCheckingEnabled = staleCheckEnabled;
+}
+
+/**
+ * Determines whether this connection is stale, which is to say that either
* it is no longer open, or an attempt to read the connection would fail.
*
* pUnfortunately, due to the limitations of the JREs prior to 1.4, it is
@@ -1317,11 +1314,14 @@
/** TCP_NODELAY socket value */
private boolean soNodelay = true;
-/** Whether or not the _socket is a secure one. Note the difference to _ssl */
+/** Whether or not the socket is a secure one. */
private boolean usingSecureSocket = false;
/** Whether I am tunneling a proxy or not */
private boolean tunnelEstablished = false;
+
+/** Whether or not isStale() is used by isOpen() */
+private boolean staleCheckingEnabled = true;
/** Timeout until connection established (Socket created). 0 means no timeout.
*/
private int connectTimeout = 0;
1.14 +32 -4
jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/SimpleHttpConnectionManager.java
Index: SimpleHttpConnectionManager.java
===
RCS file:
/home/cvs/jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/SimpleHttpConnectionManager.java,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- SimpleHttpConnectionManager.java 16 Jul 2003 20:48:27 - 1.13
+++ SimpleHttpConnectionManager.java 31 Jul 2003 02:47:30 - 1.14
@@ -84,6 +84,9 @@
/** The http connection */
private HttpConnection httpConnection;
+/**
RE: [RELEASE STOPPER] 2.0rc1 is no-go due to a serious performance issue
Mike, The patch looks fine to me. I think it is good to be committed to both the 2.0 branch and the trunk. Oleg -Original Message- From: Michael Becke [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 30, 2003 06:12 To: Commons HttpClient Project Subject: Re: [RELEASE STOPPER] 2.0rc1 is no-go due to a serious performance issue Let's try again GZipped. Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 19868] - Exception handling in HttpClient requires redesign
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19868. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19868 Exception handling in HttpClient requires redesign --- Additional Comments From [EMAIL PROTECTED] 2003-07-30 12:08 --- Laura, Many thanks for your feedback. I patched ExceptionUtils and updated TestNoHost. Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 10791] - HTTP Version configuration and tracking
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10791. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10791 HTTP Version configuration and tracking --- Additional Comments From [EMAIL PROTECTED] 2003-07-30 12:19 --- Created an attachment (id=7581) HTTP version patch (take 3) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: SocketException : SSL Implementation not available
Hi Roland I tried it with no success. renaming/removing IBMJSSE.. nothing seems to fix the issue. The task from the article sounds simple and straight, but still it dosent fix my problem. good sign is that, now I am getting com.sun.net.ssl.internal.ssl.SSLSocketFactoryImpl as the default socket. I created my own trustmanager and keystore with my own certs... yet getting the exception. tyring to resolve it. Will let u know if somehow I get it to work. if something comesup please let me know. Thanks Regards NRR --- Roland Weber [EMAIL PROTECTED] wrote: Hello NR, I have not yet found the time to run a test program. But I have found this posting on developerWorks, which seems to relate to your problems: http://www-106.ibm.com/developerworks/forums/dw_thread.jsp?message=49752cat=10thread=10122forum=178#49752 Abstract: There is an intended restriction concerning alternate SSL implementations in the exportable JDK. This results in problems if the IBM JSSE is loaded before the Sun JSSE during startup of the JDK. You'll have to relocate the IBM JSSE jar in order to make sure it is loaded second, and you can't remove it completely because WAS/WSAD won't work without it. regards, Roland __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RELEASE STOPPER] 2.0rc1 is no-go due to a serious performanceissue
Okay. I will apply it tonight. Mike Kalnichevski, Oleg wrote: Mike, The patch looks fine to me. I think it is good to be committed to both the 2.0 branch and the trunk. Oleg -Original Message- From: Michael Becke [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 30, 2003 06:12 To: Commons HttpClient Project Subject: Re: [RELEASE STOPPER] 2.0rc1 is no-go due to a serious performance issue Let's try again GZipped. Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 10791] - HTTP Version configuration and tracking
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10791. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10791 HTTP Version configuration and tracking --- Additional Comments From [EMAIL PROTECTED] 2003-07-30 19:29 --- If nobody complains loudly I'll commit this patch tonight. Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
