[validator][site] Download link?

[Ryan Hoegg]

Hi,

There is no download link in the maven generated site for validator.  I 
looked through the Project Info menu also.

I remember seeing dozens of messages fly by about shared site generation 
using maven.. how is that coming?  The About Us, Download, View 
CVS, Information, Community, and Translations sections of the 
menu on the front page for Commons would look good as a link in the 
bottom section next to Project Info imho.

--
Ryan Hoegg
ISIS Networks
http://www.isisnetworks.net/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [lang] Array concat?

[Maarten Coene]

Hi,

is it also possible to add the same methods for the primitive types?

Maarten

Gary Gregory wrote:

I agree with Stephen. It is now so in CVS HEAD.

Gary

 

-Original Message-
From: Stephen Colebourne [mailto:[EMAIL PROTECTED]
Sent: Friday, January 30, 2004 15:16
To: Jakarta Commons Developers List
Subject: Re: [lang] Array concat?
I believe that the collections like names will be best in the long run.

Thus:
   add(Object[], Object)
   add(Object[], int, Object)
   addAll(Object[], Object[])  
Stephen

From: Gary Gregory [EMAIL PROTECTED]
   

I've committed to HEAD three new ArrayUtils methods and unit tests:

  add(Object[], Object)
  add(Object[], int, Object)
  join(Object[], Object[])
Please comment on method names or impl.
 

-
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 26594] New: - [lang] add getLength() method to ArrayUtils

[bugzilla]

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

[lang] add getLength() method to ArrayUtils

   Summary: [lang] add getLength() method to ArrayUtils
   Product: Commons
   Version: unspecified
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Enhancement
  Priority: Other
 Component: Lang
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Hi,

I need a method to determine the length of an array which doesn't throw a NPE if
the array is null (this makes the java.lang.reflect.Array.getLength() method
unsuitable for me because it throws a NPE if array is null). 

Here is a possible implementation for an Object array:

public static int getLength(final Object[] array) {
if (array == null) {
return 0;
} else {
return array.length;
}
}

or, maybe you can use Object which makes this method usable for primitive arrays
as well:

public static int getLength(final Object array) {
if (array == null) {
return 0;
} else {
return java.lang.reflect.Array.getLength(array);
}
}

Can someone please add such a method ?

thanks,
Maarten

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 26598] New: - org.apache.commons.logging.impl.LogFactoryImpl does not provide enough information on an InvocationTargetException in the newInstance() method.

[bugzilla]

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

org.apache.commons.logging.impl.LogFactoryImpl does not provide enough information on 
an InvocationTargetException in the newInstance() method.

   Summary: org.apache.commons.logging.impl.LogFactoryImpl does not
provide enough information on an
InvocationTargetException in the newInstance() method.
   Product: Commons
   Version: unspecified
  Platform: Sun
OS/Version: Solaris
Status: NEW
  Severity: Enhancement
  Priority: Other
 Component: Logging
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]


Using version 1-0-3 I was getting an 
org.apache.commons.logging.LogConfigurationException while attempting to 
retrieve a Log instance from the LogFactory. This LogConfigurationException was 
wrapping an InvocationTargetException from the newInstance() method in 
org.apache.commons.logging.impl.LogFactoryImpl. An InvocationTargetException 
does not provide any information regarding the cause of the exception in its' 
stack trace so I had a difficult time determining the true cause of the error 
(A ClassNotFoundException).

I would suggest adding a special case to the existing catch clause in 
newInstance() to catch an InvocationTargetException and throw a new 
LogConfigurationExeption constructed with the cause (not the 
InvocationTargetException object).

The following would be the new catch clause:

} catch (InvocationTargetException e) {
throw new LogConfigurationException(e.getCause());
} catch (Throwable t) {
throw new LogConfigurationException(t);
}

The modified newInstance() method would look like this:

protected Log newInstance(String name) throws LogConfigurationException {

Log instance = null;
try {
Object params[] = new Object[1];
params[0] = name;
instance = (Log) getLogConstructor().newInstance(params);
if (logMethod != null) {
params[0] = this;
logMethod.invoke(instance, params);
}
return (instance);
} catch (InvocationTargetException e) {
throw new LogConfigurationException(e.getCause());
} catch (Throwable t) {
throw new LogConfigurationException(t);
}

}

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

testing email config

[Steve Cohen]

sorry for the noise

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Contacting the webmaster?

[Shapira, Yoav]

Howdy,
You ARE subscribed, right (to whatever list you're trying to post to)?
Some of the lists that have been permissive, i.e. allowing posts from
non-subscriber with or without moderator approval, have become
restrictive (open to subscribers only) due to abuse from the latest
round of worms.

Yoav Shapira
Millennium ChemInformatics


-Original Message-
From: Steve Cohen [mailto:[EMAIL PROTECTED]
Sent: Sunday, February 01, 2004 8:49 AM
To: [EMAIL PROTECTED]
Subject: Contacting the webmaster?

I've been having problems posting to the list.  A couple of days ago I
looked here:
http://jakarta.apache.org/site/contact.html

and found a link to the webmaster (down at the bottome of the page):
mailto:webmaster.AT.jakarta.DOT.apache.DOT.org

Changing this link in the obvious way, I sent a message to the
webmaster on
Friday, and now it's bounced back as undeliverable.

Please can someone tell me how to contact the administrator of this
site or
would the administrator please step forward if he or she is reading
this?

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




This e-mail, including any attachments, is a confidential business communication, and 
may contain information that is confidential, proprietary and/or privileged.  This 
e-mail is intended only for the individual(s) to whom it is addressed, and may not be 
saved, copied, printed, disclosed or used by anyone else.  If you are not the(an) 
intended recipient, please immediately delete this e-mail from your computer system 
and notify the sender.  Thank you.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 25598] - MultipartStream\IE 5.5 error.

[bugzilla]

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

MultipartStream\IE 5.5 error.





--- Additional Comments From [EMAIL PROTECTED]  2004-02-02 13:55 ---
Martin, 

Yes, you don't really see much from the trace. This is true, but there is a 
problem if you use IE 5.5. Also, some fellow has figured out what you actually 
need to run IE 5.5 on a box without un-installing your current version of IE.
Great, huh! His explanation of how to do so is here:

http://www.insert-title.com/web_design/?page=articles/dev/multi_IE


The version that I was testing with was IE 5.5 SP2. It can be found here (for 
NT, 2000, XP, Server 2003):

http://www.skyzyx.com/downloads/ie55sp2_nt.zip


BTW - I have found this problem running IE55 SP2 on Windows 2000 Server and 
Windows 2000 Worskstation.


and there is also a version for Win 95, 98, Me:

http://www.skyzyx.com/downloads/ie55sp2_nt.zip



Let me know if you need any other information from me.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 25598] - MultipartStream\IE 5.5 error.

[bugzilla]

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

MultipartStream\IE 5.5 error.





--- Additional Comments From [EMAIL PROTECTED]  2004-02-02 14:06 ---
Oh yes, when you run the IE 5.5. executable, if you go to the about box, it 
will still say that it is whatever version you previously installed. However it 
is IE 5.5. 

I do believe he mentions this in his document. He even show screens shots of 
the IE 5.5  version returning a known CSS bug.

See: http://www.insert-title.com/web_design/articles/dev/sidebyside2.jpg

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Straw man release plan

[Piotr Kochaski]

Phil Steitz wrote:

 Thinking about how this will eventually work, it has occurred to me that 
 EmpiricalDistribution could be used to digest / represent bootstrap 
 distributions.  Since we want the interface for EmpiricalDistribution to 
 be complete for 1.0, we need to make sure that bootstrap data can be 
 loaded into EmpiricalDistribution conveniently (if this makes sense), so I 
 have been thinking about adding load() methods to EmpiricalDistribution 
 that take double[] arrays and streams as values, as well as an addValue() 
 method.  Does this make sense?  I would also appreciate any comments / 
 patches on how to improve the EmpiricalDistribution interface or 
 EmpiricalDistributionImpl.  If refactoring or even holding this from the 
 release are in order, I want to make sure that we do it.

As I understand load(double[][]) would compute Empirical Distribution
Function for every bootstraped sample (provided from some other source).
Then, instead of having 

SummaryStatistics sampleStats

we should provide 

SummaryStatistics[] sampleStats

where this array would contain SummaryStatistics calculated
for every sample.  SummaryStatistics getSampleStats() would
be changed as well.

Similarly other methods/objects in EmpiricalDistribution  
would have to be modified (e.g. binStats would have to be 
an array of ArrayLists, etc.).

Do I get your intentions right?

The zeroth row of every matrix could be reserved for original
sample and the rest for bootstrapped results (if they can be
calculated, i.e. samples are given). This can be achieved but
some effort has to be made to make it simple to use for those,
who does not care about bootstrap and want to get results
based only on the original sample. 

The other thing is that such an extension would be very
usefull as long as we play with such bootstrap algorithms,
which use those statistics which are memebers of SummaryStatistics.

Often this is not the case (classic example is Median or Trimmed Mean,
which is not among SummaryStatistics). Sometimes it is also
necessary (or more comfortable) to operate on the raw bootstrap
samples, not EDF calculated from those samples. In this two
cases bootstrap embeded into EmpiricalDistribution would not
be that useful.

Two comments concerning EmpiricalDistribution 
1. Probably it would be nice to have load(double[]) method
2. Instead of
   ArrayList getBinStats();
there could be 
   List getBinStats();

although I can't imagine practical situation, where other List then
ArrayList would be better.

Piotr

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [BeanUtils] Collection 3.0 dependency, release status

[Craig R. McClanahan]

Quoting robert burrell donkin [EMAIL PROTECTED]:

 On 29 Jan 2004, at 20:11, David Graham wrote:
 
  --- Shapira, Yoav [EMAIL PROTECTED] wrote:
 
  Hi,
  I see the BeanUtils 1.7-dev already depends on commons collections
  3.0-dev and builds OK.  Can we update the dependency to collections 
  3.0
  (final)?
 
  What's left to be done for the BeanUtils 1.7 release?
 
  Personally, I'd like to see this enhancement added before the release:
 
  Add BeanFactory for dynamic factories
  http://issues.apache.org/bugzilla/show_bug.cgi?id=18087
 
  There has been some positive feedback on this list about adding it.  I
  could do this myself if the BeanUtils committers still think it's a 
  good
  idea.
 
 i'm still ambivalent.
 
 if craig has no strong feelings against then i suppose that there's an 
 argument that since there are people who think the code's useful it 
 might as well go in. i would be happier to hear craig's opinions on 
 this one before it gets committed.
 

Im actually inclined to remove the BeanUtils dependency on Collections
entirely.  The large number of backwards-incompatible API changes causes some
significant problems for applications that depend on BeanUtils and also on
Collections.  If we change our dependency, that forces all apps using BeanUtils
to update their dependency as well.

Technically, there are two sorts of changes this would entail:

* Replace use of FastHashMap with either an inside-beanutils
  version of it, or some other approach.  FastHashMap came out
  of BeanUtils in the first place, and we could easily adopt it
  back as a package private support class, but there have also
  been some concerns about the thread safety of the locking
  avoidance techniques used inside, so maybe going to synchronized
  HashMaps (and paying the performance price) would be safer.

* The new BeanPropertyValue stuff uses several Collections interfaces,
  and we'd need to evaluate what it means to change that.  This is all
  new code since BeanUtils 1.6, so if we're going to change it, now
  is the time.

 - robert

Craig


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[digester] remove denpendency? (Was: Re: [BeanUtils] Collection 3.0 dependency, release status)

[Craig R. McClanahan]

Quoting Craig R. McClanahan [EMAIL PROTECTED]:

 Quoting robert burrell donkin [EMAIL PROTECTED]:
 
  On 29 Jan 2004, at 20:11, David Graham wrote:
  
   --- Shapira, Yoav [EMAIL PROTECTED] wrote:
  
   Hi,
   I see the BeanUtils 1.7-dev already depends on commons collections
   3.0-dev and builds OK.  Can we update the dependency to collections 
   3.0
   (final)?
  
   What's left to be done for the BeanUtils 1.7 release?
  
   Personally, I'd like to see this enhancement added before the release:
  
   Add BeanFactory for dynamic factories
   http://issues.apache.org/bugzilla/show_bug.cgi?id=18087
  
   There has been some positive feedback on this list about adding it.  I
   could do this myself if the BeanUtils committers still think it's a 
   good
   idea.
  
  i'm still ambivalent.
  
  if craig has no strong feelings against then i suppose that there's an 
  argument that since there are people who think the code's useful it 
  might as well go in. i would be happier to hear craig's opinions on 
  this one before it gets committed.
  
 
 Im actually inclined to remove the BeanUtils dependency on Collections
 entirely.  The large number of backwards-incompatible API changes causes
 some
 significant problems for applications that depend on BeanUtils and also on
 Collections.  If we change our dependency, that forces all apps using
 BeanUtils
 to update their dependency as well.
 
 Technically, there are two sorts of changes this would entail:
 
 * Replace use of FastHashMap with either an inside-beanutils
   version of it, or some other approach.  FastHashMap came out
   of BeanUtils in the first place, and we could easily adopt it
   back as a package private support class, but there have also
   been some concerns about the thread safety of the locking
   avoidance techniques used inside, so maybe going to synchronized
   HashMaps (and paying the performance price) would be safer.
 
 * The new BeanPropertyValue stuff uses several Collections interfaces,
   and we'd need to evaluate what it means to change that.  This is all
   new code since BeanUtils 1.6, so if we're going to change it, now
   is the time.
 
  - robert
 
 Craig
 

For the record, I feel the same way about removing the collecions dependency in
Digester as well.  For that case it's pretty easy ... the only class used is
ArrayStack, and could be easily replaced by an internal utility class.

Craig


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 24369] - Validator.validate() exception handling for ValidatorException

[bugzilla]

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

Validator.validate() exception handling for ValidatorException





--- Additional Comments From [EMAIL PROTECTED]  2004-02-02 19:05 ---
I understand, from David Graham's comments on 2004-01-17 that this bug was 
fixed.  Where might I download this fix?  Thanks!

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 26594] - [lang] add getLength() method to ArrayUtils

[bugzilla]

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

[lang] add getLength() method to ArrayUtils





--- Additional Comments From [EMAIL PROTECTED]  2004-02-02 19:06 ---
Maarten, please submit your getLength(Object) method as a patch *with* a unit
test as this will make the addition of this method much speedier.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[math] Re: Straw man release plan

[Piotr Kochaski]

Hello

Phil Steitz wrote:

 Thinking about how this will eventually work, it has occurred to me that 
 EmpiricalDistribution could be used to digest / represent bootstrap 
 distributions.  Since we want the interface for EmpiricalDistribution to 
 be complete for 1.0, we need to make sure that bootstrap data can be 
 loaded into EmpiricalDistribution conveniently (if this makes sense), so I 
 have been thinking about adding load() methods to EmpiricalDistribution 
 that take double[] arrays and streams as values, as well as an addValue() 
 method.  Does this make sense?  I would also appreciate any comments / 
 patches on how to improve the EmpiricalDistribution interface or 
 EmpiricalDistributionImpl.  If refactoring or even holding this from the 
 release are in order, I want to make sure that we do it.

As I understand load(double[][]) would compute Empirical Distribution
Function for every bootstraped sample (provided from some other source).
Then, instead of having 

SummaryStatistics sampleStats

we should provide 

SummaryStatistics[] sampleStats

where this array would contain SummaryStatistics calculated
for every sample.  SummaryStatistics getSampleStats() would
be changed as well.

Similarly other methods/objects in EmpiricalDistribution  
would have to be modified (e.g. binStats would have to be 
an array of ArrayLists, etc.).

Do I get your intentions right?

The zeroth row of every matrix could be reserved for original
sample and the rest for bootstrapped results (if they can be
calculated, i.e. samples are given). This can be achieved but
some effort has to be made to make it simple to use for those,
who does not care about bootstrap and want to get results
based only on the original sample. 

The other thing is that such an extension would be very
usefull as long as we play with such bootstrap algorithms,
which use those statistics which are memebers of SummaryStatistics.

Often this is not the case (classic example is Median or Trimmed Mean,
which is not among SummaryStatistics). Sometimes it is also
necessary (or more comfortable) to operate on the raw bootstrap
samples, not EDF calculated from those samples. In this two
cases bootstrap embeded into EmpiricalDistribution would not
be that useful.

Two comments concerning EmpiricalDistribution 
1. Probably it would be nice to have load(double[]) method
2. Instead of
   ArrayList getBinStats();
there could be 
   List getBinStats();

although I can't imagine practical situation, where other List then
ArrayList would be better.

Piotr

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Relicensing to the Apache License 2.0 ?

[Henri Yandell]

The policy as far as I know is:

All releases after March 1st must use Apache License 2.0.

No agreement is needed as the only copyright holders to the ASF version of
the source is the ASF. While people retain copyright to their submissions,
they retain the copyright to their copy and not to the ASF copy.

It might be different for say ASF-members who have not signed the CLA, but
I would expect committers who have not signed the CLA to be the same as a
contributor.

IANAL etc. Just passing on what I've seen said, which could be wrong for
all I know.

Hen

On Mon, 2 Feb 2004, Emmanuel Bourg wrote:

 Hi, the Apache License 2.0 has been released last month
 (http://www.apache.org/licenses/LICENSE-2.0) and it seems it will become
 mandatory for all Apache projects this year.

 I wonder what is the procedure for this migration, i guess all copyright
 holders, that's committers and external contributors, have to agree
 explicitely on the relicensing. This should be immediate for the
 committers since they signed the Contributor License Agreement allowing
 the ASF to license the code in any way. But the other contributors will
 have to be contacted to request permission for relicensing, correct?

 Emmanuel Bourg




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

[daemon] jsvc compile errors

[Jeff Barrett]

I recently downloaded the Daemon source from jakarta, the one labeled 1.0-Alpha with 
the intention of using it for jsvc.  I had a compile error in home.c -- easy enough to 
fix, just a missing semi-colon.  It looks like Bill Barker commited a fix for this on 
1/18/2004.  

Anyway it made me wonder: should I even be using this?  Should I be using head?

Thanks for the advice.,
+jeff

The information in this email and subsequent attachments may contain confidential 
information that is intended solely for the attention and use of the named 
addressee(s). This message or any part thereof must not be disclosed, copied, 
distributed, or retained by any person without the authorization from the addressee.

 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [math] Re: Straw man release plan

[Mark R. Diggory]

Piotr Kochaski wrote:
Hello

Phil Steitz wrote:


Thinking about how this will eventually work, it has occurred to me that 
EmpiricalDistribution could be used to digest / represent bootstrap 
distributions.  Since we want the interface for EmpiricalDistribution to 
be complete for 1.0, we need to make sure that bootstrap data can be 
loaded into EmpiricalDistribution conveniently (if this makes sense), so I 
have been thinking about adding load() methods to EmpiricalDistribution 
that take double[] arrays and streams as values, as well as an addValue() 
method.  Does this make sense?  I would also appreciate any comments / 
patches on how to improve the EmpiricalDistribution interface or 
EmpiricalDistributionImpl.  If refactoring or even holding this from the 
release are in order, I want to make sure that we do it.


As I understand load(double[][]) would compute Empirical Distribution
Function for every bootstraped sample (provided from some other source).
Then, instead of having 

SummaryStatistics sampleStats

we should provide 

SummaryStatistics[] sampleStats

where this array would contain SummaryStatistics calculated
for every sample.  SummaryStatistics getSampleStats() would
be changed as well.


I think maybe this should be returning the more generic 
StatisticalSummary interface. If you are returning precalculated 
results, you do not exactly want to expose the underlying implementation 
to modification by the user.

StatisticalSummary[] sampleStats ...

Similarly other methods/objects in EmpiricalDistribution  
would have to be modified (e.g. binStats would have to be 
an array of ArrayLists, etc.).

Do I get your intentions right?

The zeroth row of every matrix could be reserved for original
sample and the rest for bootstrapped results (if they can be
calculated, i.e. samples are given). This can be achieved but
some effort has to be made to make it simple to use for those,
who does not care about bootstrap and want to get results
based only on the original sample. 

The other thing is that such an extension would be very
usefull as long as we play with such bootstrap algorithms,
which use those statistics which are memebers of SummaryStatistics.
Often this is not the case (classic example is Median or Trimmed Mean,
which is not among SummaryStatistics). Sometimes it is also
necessary (or more comfortable) to operate on the raw bootstrap
samples, not EDF calculated from those samples. In this two
cases bootstrap embeded into EmpiricalDistribution would not
be that useful.
If your going to be preserving the original/bootstrap values in a 
double[][], then the Standard DescriptiveStatisticsImpl could be used.

public interface FullStatisticalSummary {
public abstract double getMean();
public abstract double getVariance();
public abstract double getStandardDeviation();
public abstract double getMax();
public abstract double getMin();
public abstract long getN();
public abstract double getSum();
public abstract double getPercentile(double p);
...
}
or more simply,

public interface FullStatisticalSummary extends StatisticalSummary{
public abstract double getPercentile(double p);
...
}
Which would then Be implemented by DescriptiveStatistcs.

If returning an Interface that exposes the statistical analysis of said 
values, then an expanded interface that includes other available 
statistics could easily be added to the API.



Two comments concerning EmpiricalDistribution 
1. Probably it would be nice to have load(double[]) method
2. Instead of
   ArrayList getBinStats();
there could be 
   List getBinStats();

although I can't imagine practical situation, where other List then
ArrayList would be better.
Piotr

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Relicensing to the Apache License 2.0 ?

[Stephen Colebourne]

From: Emmanuel Bourg [EMAIL PROTECTED]
 But the other contributors will 
 have to be contacted to request permission for relicensing, correct?
No, the ASF owns the code, as it was donated at time of submission.

Stephen


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-commons-sandbox/jrcs/doc myers_diff.ps

[juanco]

juanco  2004/02/02 12:26:32

  Added:   jrcs/doc myers_diff.ps
  Log:
  added a copy of Myers' paper about his differencing algorithm
  
  Revision  ChangesPath
  1.1  jakarta-commons-sandbox/jrcs/doc/myers_diff.ps
  
  http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/jrcs/doc/myers_diff.ps?rev=1.1
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 26616] New: - ClassCastException in Enum.equals(Object)

[bugzilla]

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

ClassCastException in Enum.equals(Object)

   Summary: ClassCastException in Enum.equals(Object)
   Product: Commons
   Version: 2.0 Final
  Platform: All
OS/Version: Windows XP
Status: NEW
  Severity: Major
  Priority: Other
 Component: Lang
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Getting a ClassCastException if i
runnig this snippet
 
ColorEnum.RED.equals(test)

Thanks

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 26297] - [lang] BitSetUtils class, toIndexArray and fromIndexArray

[bugzilla]

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

[lang] BitSetUtils class, toIndexArray and fromIndexArray

[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|[collections] BitSetUtils   |[lang] BitSetUtils class,
   |class, toIndexArray and |toIndexArray and
   |fromIndexArray  |fromIndexArray



--- Additional Comments From [EMAIL PROTECTED]  2004-02-02 21:13 ---
changed summary title from [collections] to [lang], attaching new versions of
BitSetUtils and TestBitSetUtils in package org.apache.commons.lang with Apache
license version 2.0 and javadoc improvements.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-commons-sandbox/jrcs/doc .cvsignore

[juanco]

juanco  2004/02/02 13:13:18

  Added:   jrcs/doc .cvsignore
  Log:
  ignore generated directories
  
  Revision  ChangesPath
  1.3   +1 -0  jakarta-commons-sandbox/jrcs/doc/.cvsignore
  
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 26297] - [lang] BitSetUtils class, toIndexArray and fromIndexArray

[bugzilla]

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

[lang] BitSetUtils class, toIndexArray and fromIndexArray





--- Additional Comments From [EMAIL PROTECTED]  2004-02-02 21:14 ---
Created an attachment (id=10192)
updated BitSetUtils.java

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 26297] - [lang] BitSetUtils class, toIndexArray and fromIndexArray

[bugzilla]

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

[lang] BitSetUtils class, toIndexArray and fromIndexArray





--- Additional Comments From [EMAIL PROTECTED]  2004-02-02 21:15 ---
Created an attachment (id=10193)
updated TestBitSetUtils.java

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [BeanUtils] Collection 3.0 dependency, release status

[robert burrell donkin]

+0

i'd definitely support this change (but i'm short of energy at the 
moment).

some more comments inline

On 2 Feb 2004, at 18:27, Craig R. McClanahan wrote:

snip

Im actually inclined to remove the BeanUtils dependency on Collections
entirely.  The large number of backwards-incompatible API changes 
causes some
significant problems for applications that depend on BeanUtils and 
also on
Collections.  If we change our dependency, that forces all apps using 
BeanUtils
to update their dependency as well.

Technically, there are two sorts of changes this would entail:

* Replace use of FastHashMap with either an inside-beanutils
  version of it, or some other approach.  FastHashMap came out
  of BeanUtils in the first place, and we could easily adopt it
  back as a package private support class, but there have also
  been some concerns about the thread safety of the locking
  avoidance techniques used inside, so maybe going to synchronized
  HashMaps (and paying the performance price) would be safer.
sounds reasonable.

with the new bean instances, i'd prefer to factor out the storage into 
separate registry  plugins. i'd be willing to let the user synchronize 
explicitly (if needed) since the most common use case would be create 
and configure a registry then set it. i think that this use case 
shouldn't need to be synchronized. (though it may possible be necessary 
to synchronize some of the calls from the static methods.)

* The new BeanPropertyValue stuff uses several Collections interfaces,
  and we'd need to evaluate what it means to change that.  This is all
  new code since BeanUtils 1.6, so if we're going to change it, now
  is the time.
this means BeanPropertyValueChangeClosure, 
BeanPropertyValueEqualsPredicate and BeanPropertyValueTransformer, 
right?

if so, since these are really implementation i'd be very happy to see 
these moved into an optional package with a separate dependency on 
collections. they are useful but not core to beanutils. in some ways 
they have one foot in beanutils and the other in collections.

- robert

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [digester] remove denpendency? (Was: Re: [BeanUtils] Collection 3.0 dependency, release status)

[robert burrell donkin]

On 2 Feb 2004, at 18:37, Craig R. McClanahan wrote:

snip

For the record, I feel the same way about removing the collecions 
dependency in
Digester as well.  For that case it's pretty easy ... the only class 
used is
ArrayStack, and could be easily replaced by an internal utility class.
sounds good to me

- robert

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 26617] New: - [codec][patch] Quoted-printable codec (partial implementation), RFC1522 QCodec BCodec

[bugzilla]

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

[codec][patch] Quoted-printable codec (partial implementation), RFC1522 QCodec   
BCodec

   Summary: [codec][patch] Quoted-printable codec (partial
implementation), RFC1522 QCodec   BCodec
   Product: Commons
   Version: Nightly Builds
  Platform: All
OS/Version: All
Status: NEW
  Severity: Enhancement
  Priority: Other
 Component: Codec
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


The patch provides partial implementation of quoted-printable codec (rule #1 
rule #2 as described in RFC 1521), Q codec and B codec (as specified in 1522). 

I decided to not implement rule #3, rule #4, rule #5 of the quoted-printable
spec yet, because the complete quoted-printable spec does not lend itself well
into byte[] oriented codec framework. I will happily complete the codec once the
steamable codec framework is ready. The motivation behind providing the codec in
a partial form is that it can already come in handy for those applications that
do not require quoted-printable line formatting (rules #3, #4, #5), for instance
Q codec.

I have also slightly changed URLCodec to make it more consistent with the new
codecs. I tool liberty of deprecating URLCodec#getEncoding method, because this
term encoding is used in RFC1522 to refer to the encoding/decoding algorithm,
whereas charset is used to refer to the character set associated with the
unencoded text. Let me know if you agree/disagree

I am aware that the patch is still far from being complete: javasdocs are
virtually non-existent and the B codec does not have the corresponding test
cases (quoted-printable  Q codec, however, come with a reasonble set of test
cases). If the overall structure and API for the new codecs gets approved, I'll
provide the missing bits and pieces


Oleg

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 26617] - [codec][patch] Quoted-printable codec (partial implementation), RFC1522 QCodec BCodec

[bugzilla]

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

[codec][patch] Quoted-printable codec (partial implementation), RFC1522 QCodec   
BCodec





--- Additional Comments From [EMAIL PROTECTED]  2004-02-02 21:56 ---
Created an attachment (id=10194)
Patch (take 1)

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-commons/betwixt/src/test/org/apache/commons/betwixt/xmlunit TestXmlTestCase.java XmlTestCase.java

[rdonkin]

rdonkin 2004/02/02 14:21:44

  Modified:betwixt/src/java/org/apache/commons/betwixt/io Tag:
REFACTORING-BRANCH_2004-01-13
AbstractBeanWriter.java
   betwixt/src/java/org/apache/commons/betwixt/schema Tag:
REFACTORING-BRANCH_2004-01-13 ComplexType.java
SchemaTranscriber.java
   betwixt/src/test/org/apache/commons/betwixt/schema Tag:
REFACTORING-BRANCH_2004-01-13 SimplestBean.java
TestSchemaGeneration.java
TestSchemaTranscriber.java TestSchemaValidity.java
   betwixt/src/test/org/apache/commons/betwixt/xmlunit Tag:
REFACTORING-BRANCH_2004-01-13 TestXmlTestCase.java
XmlTestCase.java
  Log:
  Added w3c schema generation.
  
  Revision  ChangesPath
  No   revision
  No   revision
  1.22.2.6  +21 -12
jakarta-commons/betwixt/src/java/org/apache/commons/betwixt/io/AbstractBeanWriter.java
  
  Index: AbstractBeanWriter.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/betwixt/src/java/org/apache/commons/betwixt/io/AbstractBeanWriter.java,v
  retrieving revision 1.22.2.5
  retrieving revision 1.22.2.6
  diff -u -r1.22.2.5 -r1.22.2.6
  --- AbstractBeanWriter.java   1 Feb 2004 22:55:47 -   1.22.2.5
  +++ AbstractBeanWriter.java   2 Feb 2004 22:21:44 -   1.22.2.6
  @@ -165,7 +165,7 @@
   log.debug( bean );
   }
   start();
  -write( null, bean );
  +writeBean( null, null, null, bean, makeContext( bean ) );
   end();
   if (log.isDebugEnabled()) {
   log.debug( Finished writing bean graph. );
  @@ -194,7 +194,9 @@
   IOException, 
   SAXException,
   IntrospectionException {
  +start();
   writeBean( , qualifiedName, qualifiedName, bean, makeContext( bean ) );
  +end();
   }
   
   /** 
  @@ -564,7 +566,8 @@
   log.trace( Element  + elementDescriptor +  is empty. );
   }
   
  -Attributes attributes = addNamespaceDeclarations(new ElementAttributes( 
elementDescriptor, context ));
  +Attributes attributes = addNamespaceDeclarations(
  +new ElementAttributes( elementDescriptor, context ), namespaceUri);
   
   startElement( 
   namespaceUri, 
  @@ -582,13 +585,19 @@
   /**
* Adds namespace declarations (if any are needed) to the given attributes.
* @param attributes Attributes, not null
  + * @param elementNamespaceUri the URI for the enclosing element, possibly null
* @return Attributes, not null
*/
  -private Attributes addNamespaceDeclarations(Attributes attributes) {
  +private Attributes addNamespaceDeclarations(Attributes attributes, String 
elementNamespaceUri) {
   Attributes result = attributes;
   AttributesImpl withDeclarations = null; 
  -for (int i=0, size=attributes.getLength(); isize ; i++) {
  -String uri = attributes.getURI(i);
  +for (int i=-1, size=attributes.getLength(); isize ; i++) {
  +String uri = null;
  +if (i == -1) {
  +uri = elementNamespaceUri;
  +} else {
  +uri = attributes.getURI(i);
  +}
   if (uri != null  !.equals(uri)  
!namespacesDeclared.contains(uri)) {
   if (withDeclarations == null) {
   withDeclarations = new AttributesImpl(attributes);
  @@ -643,7 +652,7 @@
   namespaceUri, 
   localName, 
   qualifiedName,
  -addNamespaceDeclarations(attributes));
  +addNamespaceDeclarations(attributes, namespaceUri));
   
   writeElementContent( elementDescriptor, context ) ;
   endElement( namespaceUri, localName, qualifiedName );
  @@ -714,7 +723,7 @@
   idrefAttributeName,
   IDREF,
   idrefAttributeValue);
  -startElement( uri, localName, qualifiedName, 
addNamespaceDeclarations(attributes));
  +startElement( uri, localName, qualifiedName, 
addNamespaceDeclarations(attributes, uri));
   endElement( uri, localName, qualifiedName );
   }
   
  
  
  
  No   revision
  No   revision
  1.1.2.4   +8 -5  
jakarta-commons/betwixt/src/java/org/apache/commons/betwixt/schema/Attic/ComplexType.java
  
  Index: ComplexType.java
  

Re: [BeanUtils] Collection 3.0 dependency, release status

[robert burrell donkin]

On 29 Jan 2004, at 16:53, Shapira, Yoav wrote:

hi Yoav

What's left to be done for the BeanUtils 1.7 release?  I'd like to
help...
i'm really busy at the moment (with betwixt) but one thing i'd really 
like to see before any new release is the addition of an i18nable 
populate method. it's not such a big job and i will get round to it 
(but it might be a while) so it'd be great if someone stepped up to 
take this on. post a reply and i'll supply more details.

- robert

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-commons/betwixt/src/java/org/apache/commons/betwixt/schema Attribute.betwixt

[rdonkin]

rdonkin 2004/02/02 14:24:55

  Added:   betwixt/src/java/org/apache/commons/betwixt/schema Tag:
REFACTORING-BRANCH_2004-01-13 Attribute.betwixt
  Log:
  Added w3c schema generation.
  
  Revision  ChangesPath
  No   revision
  No   revision
  1.1.2.1   +11 -0 
jakarta-commons/betwixt/src/java/org/apache/commons/betwixt/schema/Attic/Attribute.betwixt
  
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-commons/betwixt/src/java/org/apache/commons/betwixt/schema ComplexType.betwixt

[rdonkin]

rdonkin 2004/02/02 14:25:13

  Added:   betwixt/src/java/org/apache/commons/betwixt/schema Tag:
REFACTORING-BRANCH_2004-01-13 ComplexType.betwixt
  Log:
  Added w3c schema generation.
  
  Revision  ChangesPath
  No   revision
  No   revision
  1.1.2.1   +21 -0 
jakarta-commons/betwixt/src/java/org/apache/commons/betwixt/schema/Attic/ComplexType.betwixt
  
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-commons/betwixt/src/java/org/apache/commons/betwixt/schema Element.betwixt

[rdonkin]

rdonkin 2004/02/02 14:25:29

  Added:   betwixt/src/java/org/apache/commons/betwixt/schema Tag:
REFACTORING-BRANCH_2004-01-13 Element.betwixt
  Log:
  Added w3c schema generation.
  
  Revision  ChangesPath
  No   revision
  No   revision
  1.1.2.1   +11 -0 
jakarta-commons/betwixt/src/java/org/apache/commons/betwixt/schema/Attic/Element.betwixt
  
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-commons/betwixt/src/java/org/apache/commons/betwixt/schema Schema.betwixt

[rdonkin]

rdonkin 2004/02/02 14:25:45

  Added:   betwixt/src/java/org/apache/commons/betwixt/schema Tag:
REFACTORING-BRANCH_2004-01-13 Schema.betwixt
  Log:
  Added w3c schema generation.
  
  Revision  ChangesPath
  No   revision
  No   revision
  1.1.2.1   +18 -0 
jakarta-commons/betwixt/src/java/org/apache/commons/betwixt/schema/Attic/Schema.betwixt
  
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-commons/betwixt/src/test/org/apache/commons/betwixt/schema SimplestBean.betwixt

[rdonkin]

rdonkin 2004/02/02 14:26:01

  Added:   betwixt/src/test/org/apache/commons/betwixt/schema Tag:
REFACTORING-BRANCH_2004-01-13 SimplestBean.betwixt
  Log:
  Added w3c schema generation.
  
  Revision  ChangesPath
  No   revision
  No   revision
  1.1.2.1   +13 -0 
jakarta-commons/betwixt/src/test/org/apache/commons/betwixt/schema/Attic/SimplestBean.betwixt
  
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-commons/betwixt/src/test/org/apache/commons/betwixt/schema SimplestElementBean.betwixt

[rdonkin]

rdonkin 2004/02/02 14:26:27

  Added:   betwixt/src/test/org/apache/commons/betwixt/schema Tag:
REFACTORING-BRANCH_2004-01-13
SimplestElementBean.betwixt
  Log:
  Added w3c schema generation.
  
  Revision  ChangesPath
  No   revision
  No   revision
  1.1.2.1   +13 -0 
jakarta-commons/betwixt/src/test/org/apache/commons/betwixt/schema/Attic/SimplestElementBean.betwixt
  
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-commons/betwixt/src/test/org/apache/commons/betwixt/schema SimplestElementBean.java

[rdonkin]

rdonkin 2004/02/02 14:26:43

  Added:   betwixt/src/test/org/apache/commons/betwixt/schema Tag:
REFACTORING-BRANCH_2004-01-13
SimplestElementBean.java
  Log:
  Added w3c schema generation.
  
  Revision  ChangesPath
  No   revision
  No   revision
  1.1.2.1   +77 -0 
jakarta-commons/betwixt/src/test/org/apache/commons/betwixt/schema/Attic/SimplestElementBean.java
  
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 26584] - Support required hidden fields.

[bugzilla]

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

Support required hidden fields.





--- Additional Comments From [EMAIL PROTECTED]  2004-02-02 22:36 ---
Are there any other types of validations for hidden fields
that would be usefull ?

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 26584] - Support required hidden fields.

[bugzilla]

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

Support required hidden fields.





--- Additional Comments From [EMAIL PROTECTED]  2004-02-02 22:50 ---
I would go on the assumption that any validation which can be used for a text field 
should be 
permissible with a hidden field; people always come up with something you didn't think 
of.  

The reason those field type checks are there is not so much because certain fields 
shouldn't be 
validated, as much as there are different methods for dereferencing the value of 
different form field 
types.  

It might be worth just going through and adding it everywhere that 'field.type == 
'text' ' is 
permitted.  I'm not thinking of any substantial risks to it.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 26584] - Support required hidden fields.

[bugzilla]

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

Support required hidden fields.

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2004-02-03 00:01 ---
Fixed - Added checking for all fields but CreditCard.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-commons/validator/conf/share validator_1_1_2.dtd

[rleland]

rleland 2004/02/02 16:38:17

  Added:   validator/conf/share validator_1_1_2.dtd
  Log:
  Add place holder to turn off client or server validation.
  For client side validation it up to the frameworks like
  struts to honor this flag.
  
  Revision  ChangesPath
  1.1  jakarta-commons/validator/conf/share/validator_1_1_2.dtd
  
  Index: validator_1_1_2.dtd
  ===
  !--
  DTD for the Validator Rules Configuration File, Version 1.1.2
  
  To allow for XML validation of your rules configuration
  file, include the following DOCTYPE element at the beginning (after
  the xml declaration):
  
  !DOCTYPE form-validation PUBLIC
   -//Apache Software Foundation//DTD Commons Validator Rules Configuration 
1.1.2//EN
   http://jakarta.apache.org/commons/dtds/validator_1_1_2.dtd;
  
  $Id: validator_1_1_2.dtd,v 1.1 2004/02/03 00:38:16 rleland Exp $
  --
  
  
  
  !--
   The form-validation element is the root of the configuration file
   hierarchy, and contains nested elements for all of the other
   configuration settings.
  --
  !ELEMENT form-validation (global*, formset*)
  
  
  !--
  The elements defined here are all global and must be nested within a
  global element.
  --
  !ELEMENT global (validator*, constant*)
  
  
  !--
   The validator element defines what validator objects can be used with
   the fields referenced by the formset elements.
   elements:
 validator Defines a new validatior
 javascriptThe javascript source code for client side validation.
   attributes:
   nameThe name of this validation
   classname   The java class name that handles server side validation
   method  The java method that handles server side validation
   methodParamsThe java class types passed to the serverside method
   msg a generic message key to use when this validator fails.
   It can be overridden by the 'msg' element for a specific 
field.
   depends The comma-delimited list of validator that are called 
before this validator.
   For this validation to succeed, all the listed validators 
must succeed.
   disable Disable validation on client, server, or both. possible 
values: {|client|server}.
   The default is for validation to occur on both the client 
and server.
   A comma must be used to separate the list e.g. 
client,server if both client
   and server validation is disabled. If this validation is 
listed in the depends
   of another validation the disabled validation will be 
treated as if it passed.
   jsFunctionName  The name of the javascript function which returns all 
fields of a certain type.
   jsFunction  The name of the javascript function which is passed the 
form for validation.
  
  --
  !ELEMENT validator (javascript?)
  !ATTLIST validator name CDATA #REQUIRED
  !ATTLIST validator classname CDATA #REQUIRED
  !ATTLIST validator method CDATA #REQUIRED
  !ATTLIST validator methodParams CDATA #REQUIRED
  !ATTLIST validator msg CDATA #REQUIRED
  !ATTLIST validator depends CDATA #IMPLIED
  !ATTLIST validator disable CDATA #IMPLIED
  !ATTLIST validator jsFunctionName CDATA #IMPLIED
  !ATTLIST validator jsFunction CDATA #IMPLIED
  
  
  
  !--
   The javascript element defines a JavaScript that can be used to perform
   client-side validators.
  --
  !ELEMENT javascript (#PCDATA)
  
  
  !--
   The constant element defines a static value that can be used as
   replacement parameters within field elements. The constant-name and
   constant-value elements define the constant's reference id and replacement
   value.
  --
  !ELEMENT constant (constant-name, constant-value)
  !ELEMENT constant-name  (#PCDATA)
  !ELEMENT constant-value (#PCDATA)
  
  
  !--
The formset element defines a set of forms for a locale. Formsets for
specific locales can override only those fields that change. The
localization is properly scoped, so that a formset can override just the
language, or just the country, or both.
  --
  !ELEMENT formset (constant*, form+)
  !ATTLIST formset language CDATA #IMPLIED
  !ATTLIST formset country CDATA #IMPLIED
  !ATTLIST formset variant CDATA #IMPLIED
  
  
  !--
   The form element defines a set of fields to be validated. The name
   corresponds to the identifier the application assigns to the form. 
  --
  !ELEMENT form (field+)
  !ATTLIST form name CDATA #REQUIRED
  
  
  !--
   The field element defines the properties to be validated. In a
   web application, a field would also correspond to a control on
   a HTML form. To validate the properties, the 

cvs commit: jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript package.html validateMask.js

[rleland]

rleland 2004/02/02 18:15:42

  Modified:validator/src/javascript/org/apache/commons/validator/javascript
package.html validateMask.js
  Log:
  Bug 26585 Validate file extensions for file uploads
  
  Revision  ChangesPath
  1.4   +26 -10
jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript/package.html
  
  Index: package.html
  ===
  RCS file: 
/home/cvs/jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript/package.html,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- package.html  2 Feb 2004 23:58:52 -   1.3
  +++ package.html  3 Feb 2004 02:15:42 -   1.4
  @@ -2,6 +2,11 @@
   html
   head
 titleValidator JavaScript package/title
  +  style type=text/css
  +!--
  +.style1 {color: #A0}
  +--
  +  /style
   /head
   body
   p The validator javascript package provides a series of functions to
  @@ -9,7 +14,7 @@
   br
   h2Package Specification/h2
   br
  -table cellpadding=2 cellspacing=2 border=1
  +table cellpadding=2 cellspacing=2 border=1 bordercolor=#00
style=text-align: left; width: 100%; height: 310px;
title=Input fields and their validations
   
  @@ -120,19 +125,20 @@
 /td
 td style=vertical-align: top;br
 /td
  -  td style=vertical-align: top;br
  +  td style=vertical-align: top;img align=MIDDLE alt=Yes 
src=doc-files/sm-yes.gif
  + style=width: 15px; height: 15px; span class=style11/spanbr
 /td
 td style=vertical-align: top;br
 /td
 td style=vertical-align: top;br
 /td
  -  td style=vertical-align: top;img src=doc-files/sm-yes.gif
  - alt=Yes style=width: 15px; height: 15px;/td
  +  td style=vertical-align: top;img align=MIDDLE
  + alt=Yes src=doc-files/sm-yes.gif style=width: 15px; height: 15px;/td
 td style=vertical-align: top;br
 /td
   /tr
   tr
  -  td style=vertical-align: top;hidden/td
  +  td style=vertical-align: top;hidden span class=style12/span /td
 td style=vertical-align: top;img
style=width: 15px; height: 15px; alt=Yes src=doc-files/sm-yes.gif/td
 td style=vertical-align: top;nbsp;/td
  @@ -339,11 +345,21 @@
   /tr
 /tbody
   /table
  -br
  -ul
  -  lia href=# REFER TO ANY FRAMEMAKER SPECIFICATION HERE #/a
  -  /li
  -/ul
  +pNotes/p
  +table width=1215 border=0
  +  tr
  +th width=17 scope=row1)/th
  +td width=8nbsp;/td
  +td width=1176pSince few browser support the 'accept' attribute for file 
upload input fields, a mask can be used to validate the uploaded file extension./p
  +  p/p/td
  +  /tr
  +  tr
  +th scope=row2)/th
  +tdnbsp;/td
  +td Hidden fields can be used with complicated HTML interface. like cascading 
inter-dependent menus. The menus themselves don't represent real data fields, but are 
used with javascript to set the value of a hidden field. /td
  +  /tr
  +/table
  +pnbsp;/p
   h2Related Documentation/h2
   For overviews, tutorials, examples, guides, and tool documentation,
   please see:
  
  
  
  1.7   +3 -2  
jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript/validateMask.js
  
  Index: validateMask.js
  ===
  RCS file: 
/home/cvs/jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript/validateMask.js,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- validateMask.js   2 Feb 2004 23:58:52 -   1.6
  +++ validateMask.js   3 Feb 2004 02:15:42 -   1.7
  @@ -17,7 +17,8 @@
   
   if ((field.type == 'hidden' ||
   field.type == 'text' ||
  - field.type == 'textarea') 
  + field.type == 'textarea' ||
  +  field.type == 'file') 
(field.value.length  0) 
field.disabled == false) {
   
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 23156] - [VALIDATOR] XML/SGML catalog

[bugzilla]

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

[VALIDATOR] XML/SGML catalog





--- Additional Comments From [EMAIL PROTECTED]  2004-02-03 02:24 ---
Did you ever figure out how to create a catalog ?

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Relicensing to the Apache License 2.0 ?

[Gary Gregory]

Should we replace each source file header lock, stock and two smoking
barrels? If so, does any one have a script for this?

Gary

 -Original Message-
 From: Henri Yandell [mailto:[EMAIL PROTECTED]
 Sent: Monday, February 02, 2004 12:02
 To: Jakarta Commons Developers List
 Subject: Re: Relicensing to the Apache License 2.0 ?
 
 
 The policy as far as I know is:
 
 All releases after March 1st must use Apache License 2.0.
 
 No agreement is needed as the only copyright holders to the ASF version of
 the source is the ASF. While people retain copyright to their submissions,
 they retain the copyright to their copy and not to the ASF copy.
 
 It might be different for say ASF-members who have not signed the CLA, but
 I would expect committers who have not signed the CLA to be the same as a
 contributor.
 
 IANAL etc. Just passing on what I've seen said, which could be wrong for
 all I know.
 
 Hen
 
 On Mon, 2 Feb 2004, Emmanuel Bourg wrote:
 
  Hi, the Apache License 2.0 has been released last month
  (http://www.apache.org/licenses/LICENSE-2.0) and it seems it will become
  mandatory for all Apache projects this year.
 
  I wonder what is the procedure for this migration, i guess all copyright
  holders, that's committers and external contributors, have to agree
  explicitely on the relicensing. This should be immediate for the
  committers since they signed the Contributor License Agreement allowing
  the ASF to license the code in any way. But the other contributors will
  have to be contacted to request permission for relicensing, correct?
 
  Emmanuel Bourg
 
 
 
 
  -
  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: Relicensing to the Apache License 2.0 ?

[Mark R. Diggory]

I replaced our licenses with a simple ant replace task. You may have to 
tweek the matching string a little.

-MArk

Gary Gregory wrote:

Should we replace each source file header lock, stock and two smoking
barrels? If so, does any one have a script for this?
Gary


-Original Message-
From: Henri Yandell [mailto:[EMAIL PROTECTED]
Sent: Monday, February 02, 2004 12:02
To: Jakarta Commons Developers List
Subject: Re: Relicensing to the Apache License 2.0 ?
The policy as far as I know is:

All releases after March 1st must use Apache License 2.0.

No agreement is needed as the only copyright holders to the ASF version of
the source is the ASF. While people retain copyright to their submissions,
they retain the copyright to their copy and not to the ASF copy.
It might be different for say ASF-members who have not signed the CLA, but
I would expect committers who have not signed the CLA to be the same as a
contributor.
IANAL etc. Just passing on what I've seen said, which could be wrong for
all I know.
Hen

On Mon, 2 Feb 2004, Emmanuel Bourg wrote:


Hi, the Apache License 2.0 has been released last month
(http://www.apache.org/licenses/LICENSE-2.0) and it seems it will become
mandatory for all Apache projects this year.
I wonder what is the procedure for this migration, i guess all copyright
holders, that's committers and external contributors, have to agree
explicitely on the relicensing. This should be immediate for the
committers since they signed the Contributor License Agreement allowing
the ASF to license the code in any way. But the other contributors will
have to be contacted to request permission for relicensing, correct?
Emmanuel Bourg



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


--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu
?xml version=1.0 encoding=UTF-8?
project default=replace_license name=license-2.0 basedir=.
  target name=replace_license
  	replace dir=src
  		include name=**/*.java/
  		replacetoken![CDATA[/* 
 * The Apache Software License, Version 1.1
 *
 * Copyright (c) 2003-2004 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 acknowledgement:
 *   This product includes software developed by the
 *Apache Software Foundation (http://www.apache.org/).
 *Alternately, this acknowledgement may appear in the software itself,
 *if and wherever such third-party acknowledgements 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 name 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/.
 */]]/replacetoken
		replacevalue![CDATA[/*
 * 
 * Copyright 

RE: Relicensing to the Apache License 2.0 ?

[Martin Cooper]

On Mon, 2 Feb 2004, Gary Gregory wrote:

 Should we replace each source file header lock, stock and two smoking
 barrels? If so, does any one have a script for this?

The problem with using a script is that the original copyright dates
*must* be retained, so you can't just blat over the old header with a new
one. If you have a script that can do that, great. Otherwise, you're going
to have to make the changes by hand.

--
Martin Cooper



 Gary

  -Original Message-
  From: Henri Yandell [mailto:[EMAIL PROTECTED]
  Sent: Monday, February 02, 2004 12:02
  To: Jakarta Commons Developers List
  Subject: Re: Relicensing to the Apache License 2.0 ?
 
 
  The policy as far as I know is:
 
  All releases after March 1st must use Apache License 2.0.
 
  No agreement is needed as the only copyright holders to the ASF version of
  the source is the ASF. While people retain copyright to their submissions,
  they retain the copyright to their copy and not to the ASF copy.
 
  It might be different for say ASF-members who have not signed the CLA, but
  I would expect committers who have not signed the CLA to be the same as a
  contributor.
 
  IANAL etc. Just passing on what I've seen said, which could be wrong for
  all I know.
 
  Hen
 
  On Mon, 2 Feb 2004, Emmanuel Bourg wrote:
 
   Hi, the Apache License 2.0 has been released last month
   (http://www.apache.org/licenses/LICENSE-2.0) and it seems it will become
   mandatory for all Apache projects this year.
  
   I wonder what is the procedure for this migration, i guess all copyright
   holders, that's committers and external contributors, have to agree
   explicitely on the relicensing. This should be immediate for the
   committers since they signed the Contributor License Agreement allowing
   the ASF to license the code in any way. But the other contributors will
   have to be contacted to request permission for relicensing, correct?
  
   Emmanuel Bourg
  
  
  
  
   -
   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: [math] Re: Getting started questions

[Phil Steitz]

Paul Libbrecht wrote:
Ah, this question is interesting.

I recently removed the dependency on the ../project.xml in Jelly  
because I think checking out a module should produce free-standing  things.
Before being a commons-committer, I always patched the project.xml so  
as to get rid of the project inheritance (which is only for a handful  
of ownership information for the website anyways).
These are good points. I would be +1 for doing this for [math].

snip/

Also, why do you need jakarta-commons/xdocs/
My mistake. All is actually needed is jakarta-commons/incl_nav.xml.

Phil

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [math] Re: Straw man release plan

[Phil Steitz]

Mark R. Diggory wrote:
snip/
where this array would contain SummaryStatistics calculated
for every sample.  SummaryStatistics getSampleStats() would
be changed as well.


I think maybe this should be returning the more generic 
StatisticalSummary interface. If you are returning precalculated 
results, you do not exactly want to expose the underlying implementation 
to modification by the user.
I agree.  That is why StatisticalSummary was created.

Phil







-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[GUMP@lsd]: jelly-tags/commons-jelly-tags-jetty failed

[Morgan Delagrange]

Project: commons-jelly-tags-jetty
State: Failed
URL: http://lsd.student.utwente.nl/gump/jelly-tags/commons-jelly-tags-jetty.html
- G U M P Y


Annotations:
 - Error - Failed with reason build failed


- G U M P Y
Work Name: build_jelly-tags_commons-jelly-tags-jetty (Type: Build)
State: Failed
Elapsed: 0 hours, 0 minutes, 7 seconds
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/data/gump/xml-xerces2/java/build/xercesImpl.jar:/data/gump/xml-xerces2/java/build/xmlParserAPIs.jar
 org.apache.tools.ant.Main -Dbuild.clonevm=true 
-Dgump.merge=/data/gump/gump/work/merge.xml -Dbuild.sysclasspath=only 
-Dfinal.name=commons-jelly-tags-jetty-20040203 jar 
[Working Directory: /data/gump/jelly-tags/jetty]
-
[javac] symbol  : class OutputStreamLogSink 
[javac] location: class org.apache.commons.jelly.tags.jetty.JettyHttpServerTag
[javac] private static OutputStreamLogSink _logSink;
[javac]^
[javac] 
/data/gump/jelly-tags/jetty/src/java/org/apache/commons/jelly/tags/jetty/SecurityHandlerTag.java:71:
 cannot resolve symbol
[javac] symbol  : class Authenticator 
[javac] location: class org.mortbay.http.SecurityConstraint
[javac] import org.mortbay.http.SecurityConstraint.Authenticator;
[javac]^
[javac] 
/data/gump/jelly-tags/jetty/src/java/org/apache/commons/jelly/tags/jetty/SecurityHandlerTag.java:75:
 cannot resolve symbol
[javac] symbol  : class Code 
[javac] location: package util
[javac] import org.mortbay.util.Code;
[javac] ^
[javac] 
/data/gump/jelly-tags/jetty/src/java/org/apache/commons/jelly/tags/jetty/JettyHttpServerTag.java:118:
 cannot resolve symbol
[javac] symbol  : class OutputStreamLogSink 
[javac] location: class org.apache.commons.jelly.tags.jetty.JettyHttpServerTag
[javac] _logSink = new OutputStreamLogSink(DEFAULT_LOG_FILE);
[javac]^
[javac] 
/data/gump/jelly-tags/jetty/src/java/org/apache/commons/jelly/tags/jetty/JettyHttpServerTag.java:120:
 cannot resolve symbol
[javac] symbol  : variable Log 
[javac] location: class org.apache.commons.jelly.tags.jetty.JettyHttpServerTag
[javac] Log.instance().add(_logSink);
[javac] ^
[javac] 
/data/gump/jelly-tags/jetty/src/java/org/apache/commons/jelly/tags/jetty/SecurityHandlerTag.java:236:
 cannot resolve symbol
[javac] symbol  : variable Code 
[javac] location: class org.apache.commons.jelly.tags.jetty.SecurityHandlerTag
[javac] Code.warning(Unknown user-data-constraint:+guarantee);
[javac] ^
[javac] 
/data/gump/jelly-tags/jetty/src/java/org/apache/commons/jelly/tags/jetty/SecurityHandlerTag.java:281:
 cannot resolve symbol
[javac] symbol  : class Authenticator 
[javac] location: class org.apache.commons.jelly.tags.jetty.SecurityHandlerTag
[javac] Authenticator authenticator=null;
[javac] ^
[javac] 
/data/gump/jelly-tags/jetty/src/java/org/apache/commons/jelly/tags/jetty/SecurityHandlerTag.java:293:
 cannot resolve symbol
[javac] symbol  : variable Code 
[javac] location: class org.apache.commons.jelly.tags.jetty.SecurityHandlerTag
[javac] Code.warning(UNKNOWN AUTH METHOD: +m);
[javac] ^
[javac] 
/data/gump/jelly-tags/jetty/src/java/org/apache/commons/jelly/tags/jetty/SecurityHandlerTag.java:306:
 cannot resolve symbol
[javac] symbol  : variable Code 
[javac] location: class org.apache.commons.jelly.tags.jetty.SecurityHandlerTag
[javac] Code.warning(FORM Authentication miss-configured);
[javac] ^
[javac] 13 errors

BUILD FAILED
/data/gump/jelly-tags/jetty/build.xml:31: Compile failed; see the compiler error 
output for details.

Total time: 5 seconds
-

- G U M P Y
RSS: http://lsd.student.utwente.nl/gump/jelly-tags/commons-jelly-tags-jetty.rss | 
Atom: http://lsd.student.utwente.nl/gump/jelly-tags/commons-jelly-tags-jetty.atom

--
Gump http://jakarta.apache.org/gump
[lsd]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[GUMP@lsd]: jelly-tags/commons-jelly-tags-junit failed

[Morgan Delagrange]

Project: commons-jelly-tags-junit
State: Failed
URL: http://lsd.student.utwente.nl/gump/jelly-tags/commons-jelly-tags-junit.html
- G U M P Y


Annotations:
 - Error - Failed with reason build failed


- G U M P Y
Work Name: build_jelly-tags_commons-jelly-tags-junit (Type: Build)
State: Failed
Elapsed: 0 hours, 0 minutes, 14 seconds
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/data/gump/xml-xerces2/java/build/xercesImpl.jar:/data/gump/xml-xerces2/java/build/xmlParserAPIs.jar
 org.apache.tools.ant.Main -Dbuild.clonevm=true 
-Dgump.merge=/data/gump/gump/work/merge.xml -Dbuild.sysclasspath=only 
-Dfinal.name=commons-jelly-tags-junit-20040203 jar 
[Working Directory: /data/gump/jelly-tags/junit]
-
[junit] 
[junit] The exception was: 
file:/data/gump/jelly-tags/junit/target/test-classes/org/apache/commons/jelly/tags/junit/suite.jelly:31:-1:
 lt;test:failgt; 
file:/data/gump/jelly-tags/junit/target/test-classes/org/apache/commons/jelly/tags/junit/suite.jelly:31:-1:
 lt;test:failgt; This should always fail  
[junit]   
[junit] 
[junit] The exception was: 
file:/data/gump/jelly-tags/junit/target/test-classes/org/apache/commons/jelly/tags/junit/suite.jelly:47:-1:
 lt;test:assertEqualsgt; 
file:/data/gump/jelly-tags/junit/target/test-classes/org/apache/commons/jelly/tags/junit/suite.jelly:47:-1:
 lt;test:assertEqualsgt; This should always fail expected:[def] but was:[abc]
[junit] Expected expression: def
[junit] Actual expression: ${foo}   
[junit]   Tests run: 4, Failures: 0, Errors: 1, Time elapsed: 0.293 sec
[junit] Testsuite: org.apache.commons.jelly.tags.junit.TestJUnit
[junit] Tests run: 4, Failures: 0, Errors: 1, Time elapsed: 0.293 sec
[junit] - Standard Error -
[junit] Feb 3, 2004 4:50:18 AM org.apache.commons.jelly.tags.junit.AssertThrowsTag 
getThrowableClass
[junit] WARNING: The class: java.lang.Class is not an Exception class.
[junit] Feb 3, 2004 4:50:18 AM org.apache.commons.jelly.tags.junit.AssertThrowsTag 
getThrowableClass
[junit] WARNING: Could not find exception class: foo.bar.Baz
[junit] -  ---

[junit] Testcase: assertTests took 0.118 sec
[junit] Testcase: failTests took 0.016 sec
[junit] Testcase: assertEqualTests took 0.016 sec
[junit] Testcase: assertThrowsTests took 0.112 sec
[junit] Caused an ERROR
[junit] 
file:/data/gump/jelly-tags/junit/target/test-classes/org/apache/commons/jelly/tags/junit/suite.jelly:103:-1:
 test:assert 
file:/data/gump/jelly-tags/junit/target/test-classes/org/apache/commons/jelly/tags/junit/suite.jelly:103:-1:
 test:assert columnNumber not set. Assertion failed while evaluating test: 
${ex.columnNumber gt 0}
[junit] org.apache.commons.jelly.JellyTagException: 
file:/data/gump/jelly-tags/junit/target/test-classes/org/apache/commons/jelly/tags/junit/suite.jelly:103:-1:
 test:assert 
file:/data/gump/jelly-tags/junit/target/test-classes/org/apache/commons/jelly/tags/junit/suite.jelly:103:-1:
 test:assert columnNumber not set. Assertion failed while evaluating test: 
${ex.columnNumber gt 0}
[junit] at 
org.apache.commons.jelly.impl.TagScript.handleException(TagScript.java:707)
[junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:296)
[junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
[junit] at 
org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:105)
[junit] Caused by: org.apache.commons.jelly.tags.junit.JellyAssertionFailedError: 
file:/data/gump/jelly-tags/junit/target/test-classes/org/apache/commons/jelly/tags/junit/suite.jelly:103:-1:
 test:assert columnNumber not set. Assertion failed while evaluating test: 
${ex.columnNumber gt 0}
[junit] at 
org.apache.commons.jelly.tags.junit.AssertTagSupport.fail(AssertTagSupport.java:85)
[junit] at 
org.apache.commons.jelly.tags.junit.AssertTagSupport.fail(AssertTagSupport.java:96)
[junit] at 
org.apache.commons.jelly.tags.junit.AssertTag.doTag(AssertTag.java:104)
[junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
[junit] ... 11 more
[junit] Root cause
[junit] org.apache.commons.jelly.tags.junit.JellyAssertionFailedError: 
file:/data/gump/jelly-tags/junit/target/test-classes/org/apache/commons/jelly/tags/junit/suite.jelly:103:-1:
 test:assert columnNumber not set. Assertion failed while evaluating test: 
${ex.columnNumber gt 0}
[junit] at 
org.apache.commons.jelly.tags.junit.AssertTagSupport.fail(AssertTagSupport.java:85)
[junit] at 
org.apache.commons.jelly.tags.junit.AssertTagSupport.fail(AssertTagSupport.java:96)
[junit] at 

Re: Memory Leaks when web server hangs

[Adrian Sutton]

On 2/2/04 2:00 PM, Srinivas Vemula [EMAIL PROTECTED] wrote:

 Hi All,
   We are seeing thread leaks when having client open connections to a web
 server that hangs. Has any one seen this happening?? How do we ensure that the
 library correctly closes  socket connections on failures, cleaning up system
 resources, and  threads actually finish in  the timeout period and get freed
 up. Would using MultiThreadedHttpConnectionManager
 file:///D:/silkroad/http-commons/commons-httpclient-2.0-rc3/docs/threading.ht
 ml#MultiThreadedHttpConnectionManager   be of any help??

Hi Srini,
If you're using the same HttpClient instance across multiple threads, you
must use the MultiThreadedHttpConnectionManager or you'll run into strange
problems.  If you're using separate HttpClient instances, you may as well
stick with the single threaded (default) connection manager.

In terms of connections hanging - you probably want to look into the
setConnectionTimeout and setTimeout methods of the HttpClient class.  These
allow you to control how long HttpClient waits when making a connection and
how long it waits for data once the connection is established.  If you have
set either of these to 0 (not sure what the default is, it may be platform
specific) the connection will never timeout which sounds a lot like what
you're seeing.

Mike and Oleg, the stack trace Srini included indicates that HttpClient is
attempting to create a new timeout thread on every connection - does this
always occur or is it just one timeout thread per httpclient instance?  It
would be ideal if we could reduce this to one static thread as starting
threads is never nice for server side apps.  Not sure how feasible that is
though.

 Srini

Regards,

Adrian Sutton.

--
Intencha tomorrow's technology today
Ph: 38478913 0422236329
Suite 8/29 Oatland Crescent
Holland Park West 4121
Australia QLD
www.intencha.com


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Promote HttpClient out of commons?

[Ortwin Glück]

Michael Becke wrote:
In particular I would like to hear from all the regular committers, 
contributors, and users.  How do you think this move would effect 
HttpClient's visibility, community, and organization?
I see HttpClient as a Jakarta level project. As Oleg has already stated, 
its design is really to be overhauled, even if a lot of its 
functionality is working very well. But it has not yet reached the high 
quality that ASF projects are meant to achieve. So I don't see 
HttpClient as a TLP (yet - maybe release 4.0).
Still, I think HttpClient is probably the best (in terms of features, 
standards-compliance) HTTP library available for Java. And this fact has 
attracted a large community so far. Further hiding HttpClient inside 
Commons just doesn't make sense any longer.
The important thing for us developers is a) to be able to maintain 
Bugzilla adequately and b) to be efficient without too much overhead.

Ortwin Glück aka Odi

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Memory Leaks when web server hangs

[Kalnichevski, Oleg]

 Mike and Oleg, the stack trace Srini included indicates that HttpClient is
 attempting to create a new timeout thread on every connection - does this
 always occur or is it just one timeout thread per httpclient instance?  It
 would be ideal if we could reduce this to one static thread as starting
 threads is never nice for server side apps.  Not sure how feasible that is
 though.

Hi Srini,
HttpClient uses an additional controller thread to work around the limitation of older 
( 1.4) JDKs which do not provide a possibility to set connect timeout. If you do not 
really need to control connect timeout (for instance, when communicating with an 
intranet site with good availability) simply set connect timeout to. That will prevent 
HttpClient from spawning an additional thread per request.

Adrian, et al
Another possibility to use reflection to set connect timeout using the Socket methods 
when running in JVM 1.4 or above

Oleg



-Original Message-
From: Adrian Sutton [mailto:[EMAIL PROTECTED]
Sent: Monday, February 02, 2004 09:03
To: Commons HttpClient Project
Subject: Re: Memory Leaks when web server hangs


On 2/2/04 2:00 PM, Srinivas Vemula [EMAIL PROTECTED] wrote:

 Hi All,
   We are seeing thread leaks when having client open connections to a web
 server that hangs. Has any one seen this happening?? How do we ensure that the
 library correctly closes  socket connections on failures, cleaning up system
 resources, and  threads actually finish in  the timeout period and get freed
 up. Would using MultiThreadedHttpConnectionManager
 file:///D:/silkroad/http-commons/commons-httpclient-2.0-rc3/docs/threading.ht
 ml#MultiThreadedHttpConnectionManager   be of any help??

Hi Srini,
If you're using the same HttpClient instance across multiple threads, you
must use the MultiThreadedHttpConnectionManager or you'll run into strange
problems.  If you're using separate HttpClient instances, you may as well
stick with the single threaded (default) connection manager.

In terms of connections hanging - you probably want to look into the
setConnectionTimeout and setTimeout methods of the HttpClient class.  These
allow you to control how long HttpClient waits when making a connection and
how long it waits for data once the connection is established.  If you have
set either of these to 0 (not sure what the default is, it may be platform
specific) the connection will never timeout which sounds a lot like what
you're seeing.

Mike and Oleg, the stack trace Srini included indicates that HttpClient is
attempting to create a new timeout thread on every connection - does this
always occur or is it just one timeout thread per httpclient instance?  It
would be ideal if we could reduce this to one static thread as starting
threads is never nice for server side apps.  Not sure how feasible that is
though.

 Srini

Regards,

Adrian Sutton.

--
Intencha tomorrow's technology today
Ph: 38478913 0422236329
Suite 8/29 Oatland Crescent
Holland Park West 4121
Australia QLD
www.intencha.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]

Re: Memory Leaks when web server hangs

[Srinivas Vemula]

Oleg,
  
   We are using JDK1.4.1 and connection time out is set to 30Ms and 
read time out to 60Ms. We are trying to connect to a IP Camera, and send 
a heart beat command to the camera to check for its availability every 
30 Secs from the time we find it is un available. If the web server is 
down, we feel that HttpClient is not cleaning up failed connections 
properly and thats resulting in Memory Leaks at the server side.

   The code we use is the standard way of using HttpClient and all the 
code is in a method and new HttpClient object is created for every 
request. Are there any ways to make sure the connections are all being 
purged properly? Are there any precautionary measures or flags we can 
set on HttpClient API when communicating with a web server (running on 
firm ware) with relatively less RAM and processing power (IpCamera with 
built in web server)?

Thanks for your time and help.
Srini
Kalnichevski, Oleg wrote:

Mike and Oleg, the stack trace Srini included indicates that HttpClient is
attempting to create a new timeout thread on every connection - does this
always occur or is it just one timeout thread per httpclient instance?  It
would be ideal if we could reduce this to one static thread as starting
threads is never nice for server side apps.  Not sure how feasible that is
though.
   

Hi Srini,
HttpClient uses an additional controller thread to work around the limitation of older 
( 1.4) JDKs which do not provide a possibility to set connect timeout. If you do not 
really need to control connect timeout (for instance, when communicating with an intranet 
site with good availability) simply set connect timeout to. That will prevent HttpClient 
from spawning an additional thread per request.
Adrian, et al
Another possibility to use reflection to set connect timeout using the Socket methods 
when running in JVM 1.4 or above
Oleg



-Original Message-
From: Adrian Sutton [mailto:[EMAIL PROTECTED]
Sent: Monday, February 02, 2004 09:03
To: Commons HttpClient Project
Subject: Re: Memory Leaks when web server hangs
On 2/2/04 2:00 PM, Srinivas Vemula [EMAIL PROTECTED] wrote:

 

Hi All,
 We are seeing thread leaks when having client open connections to a web
server that hangs. Has any one seen this happening?? How do we ensure that the
library correctly closes  socket connections on failures, cleaning up system
resources, and  threads actually finish in  the timeout period and get freed
up. Would using MultiThreadedHttpConnectionManager
file:///D:/silkroad/http-commons/commons-httpclient-2.0-rc3/docs/threading.ht
ml#MultiThreadedHttpConnectionManager   be of any help??
   

Hi Srini,
If you're using the same HttpClient instance across multiple threads, you
must use the MultiThreadedHttpConnectionManager or you'll run into strange
problems.  If you're using separate HttpClient instances, you may as well
stick with the single threaded (default) connection manager.
In terms of connections hanging - you probably want to look into the
setConnectionTimeout and setTimeout methods of the HttpClient class.  These
allow you to control how long HttpClient waits when making a connection and
how long it waits for data once the connection is established.  If you have
set either of these to 0 (not sure what the default is, it may be platform
specific) the connection will never timeout which sounds a lot like what
you're seeing.
Mike and Oleg, the stack trace Srini included indicates that HttpClient is
attempting to create a new timeout thread on every connection - does this
always occur or is it just one timeout thread per httpclient instance?  It
would be ideal if we could reduce this to one static thread as starting
threads is never nice for server side apps.  Not sure how feasible that is
though.
 

Srini
   

Regards,

Adrian Sutton.

--
Intencha tomorrow's technology today
Ph: 38478913 0422236329
Suite 8/29 Oatland Crescent
Holland Park West 4121
Australia QLD
www.intencha.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]
 

--
Srinivas Vemula  +91 40 23547826- Ext 201
Associate Consultant +91 40 23541447 (Fax)
Mensamind+91 98497-42720 (Mobile)
Hyderabad
India
http://www.mensamind.com

DISCLAIMER
The information contained in this e-mail is confidential and intended for the named 
recipient(s) only. If you are not an intended recipient of this email you must not 
copy, distribute or take any further action in reliance on it. You should delete it 
and notify the sender immediately.

Re: Memory Leaks when web server hangs

[Marcus Crafter]

Hi Srinivas, et al,

Hope all is well.

We've also experienced a similar story here in Oz just the other day. 
Essentially connections to the webserver were not being released and were 
consuming sockets on the client (determined via OptimizeIT).

After searching the dev list I found a post by another developer that said
this was the default behaviour for HTTP 1.1 which HttpClient honoured (ie.
keep-alive), if the server didn't indicate what the client should do with
the connection.

When I looked into the headers via a wire trace I saw that indeed the
server (IIS in this case) didn't send a 'Connection: close' header and after 
browsing the HttpClient source saw that the connection was kept alive if 
using HTTP 1.1.

The non-programatic way to fix it was to add a request header to each
client request saying 'Connection: close'.

After doing this, HttpClient closed all connections after they were
released and the open socket problem went away.

Hope this helps.

Cheers,

Marcus

On Mon, Feb 02, 2004 at 04:26:39PM +0530, Srinivas Vemula wrote:
 Oleg,
   
We are using JDK1.4.1 and connection time out is set to 30Ms and 
 read time out to 60Ms. We are trying to connect to a IP Camera, and send 
 a heart beat command to the camera to check for its availability every 
 30 Secs from the time we find it is un available. If the web server is 
 down, we feel that HttpClient is not cleaning up failed connections 
 properly and thats resulting in Memory Leaks at the server side.
 
The code we use is the standard way of using HttpClient and all the 
 code is in a method and new HttpClient object is created for every 
 request. Are there any ways to make sure the connections are all being 
 purged properly? Are there any precautionary measures or flags we can 
 set on HttpClient API when communicating with a web server (running on 
 firm ware) with relatively less RAM and processing power (IpCamera with 
 built in web server)?
 
 Thanks for your time and help.
 Srini
 
 Kalnichevski, Oleg wrote:
 
 Mike and Oleg, the stack trace Srini included indicates that HttpClient is
 attempting to create a new timeout thread on every connection - does this
 always occur or is it just one timeout thread per httpclient instance?  It
 would be ideal if we could reduce this to one static thread as starting
 threads is never nice for server side apps.  Not sure how feasible that is
 though.

 
 
 Hi Srini,
 HttpClient uses an additional controller thread to work around the 
 limitation of older ( 1.4) JDKs which do not provide a possibility to set 
 connect timeout. If you do not really need to control connect timeout (for 
 instance, when communicating with an intranet site with good availability) 
 simply set connect timeout to. That will prevent HttpClient from spawning 
 an additional thread per request.
 
 Adrian, et al
 Another possibility to use reflection to set connect timeout using the 
 Socket methods when running in JVM 1.4 or above
 
 Oleg
 
 
 
 -Original Message-
 From: Adrian Sutton [mailto:[EMAIL PROTECTED]
 Sent: Monday, February 02, 2004 09:03
 To: Commons HttpClient Project
 Subject: Re: Memory Leaks when web server hangs
 
 
 On 2/2/04 2:00 PM, Srinivas Vemula [EMAIL PROTECTED] wrote:
 
  
 
 Hi All,
  We are seeing thread leaks when having client open connections to a 
  web
 server that hangs. Has any one seen this happening?? How do we ensure 
 that the
 library correctly closes  socket connections on failures, cleaning up 
 system
 resources, and  threads actually finish in  the timeout period and get 
 freed
 up. Would using MultiThreadedHttpConnectionManager
 file:///D:/silkroad/http-commons/commons-httpclient-2.0-rc3/docs/threading.ht
 ml#MultiThreadedHttpConnectionManager   be of any help??

 
 
 Hi Srini,
 If you're using the same HttpClient instance across multiple threads, you
 must use the MultiThreadedHttpConnectionManager or you'll run into strange
 problems.  If you're using separate HttpClient instances, you may as well
 stick with the single threaded (default) connection manager.
 
 In terms of connections hanging - you probably want to look into the
 setConnectionTimeout and setTimeout methods of the HttpClient class.  These
 allow you to control how long HttpClient waits when making a connection and
 how long it waits for data once the connection is established.  If you have
 set either of these to 0 (not sure what the default is, it may be platform
 specific) the connection will never timeout which sounds a lot like what
 you're seeing.
 
 Mike and Oleg, the stack trace Srini included indicates that HttpClient is
 attempting to create a new timeout thread on every connection - does this
 always occur or is it just one timeout thread per httpclient instance?  It
 would be ideal if we could reduce this to one static thread as starting
 threads is never nice for server side apps.  Not sure how feasible that is
 though.
 
  
 
 Srini

 
 
 Regards,
 
 Adrian 

Re: Memory Leaks when web server hangs

[Ortwin Glück]

Marcus Crafter wrote:
The non-programatic way to fix it was to add a request header to each
client request saying 'Connection: close'.
You could also have written your own connection manager implementation 
instead of messing with request headers. This would have been more 
portable to later versions.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Memory Leaks when web server hangs

[Marcus Crafter]

Hi Srinivas,

Yes, that's what we did here, afterwards the connections that were
previously held open, were closed.

Sorry if it wasn't clearer in my first email.

Cheers,

Marcus

On Mon, Feb 02, 2004 at 05:31:33PM +0530, Srinivas Vemula wrote:
 Thanks Marcus,
Are u saying  we should add getMethod.addRequestHeader(Connection, 
 close)  for every request made using HttpClient ? Excuse me if I 
 missed your point completely.
 srini
 
 Marcus Crafter wrote:
 
 Hi Srinivas, et al,
 
 Hope all is well.
 
 We've also experienced a similar story here in Oz just the other day. 
 Essentially connections to the webserver were not being released and were 
 consuming sockets on the client (determined via OptimizeIT).
 
 After searching the dev list I found a post by another developer that said
 this was the default behaviour for HTTP 1.1 which HttpClient honoured (ie.
 keep-alive), if the server didn't indicate what the client should do with
 the connection.
 
 When I looked into the headers via a wire trace I saw that indeed the
 server (IIS in this case) didn't send a 'Connection: close' header and 
 after browsing the HttpClient source saw that the connection was kept 
 alive if using HTTP 1.1.
 
 The non-programatic way to fix it was to add a request header to each
 client request saying 'Connection: close'.
 
 After doing this, HttpClient closed all connections after they were
 released and the open socket problem went away.
 
 Hope this helps.
 
 Cheers,
 
 Marcus
 
 On Mon, Feb 02, 2004 at 04:26:39PM +0530, Srinivas Vemula wrote:
  
 
 Oleg,
  
   We are using JDK1.4.1 and connection time out is set to 30Ms and 
 read time out to 60Ms. We are trying to connect to a IP Camera, and send 
 a heart beat command to the camera to check for its availability every 
 30 Secs from the time we find it is un available. If the web server is 
 down, we feel that HttpClient is not cleaning up failed connections 
 properly and thats resulting in Memory Leaks at the server side.
 
   The code we use is the standard way of using HttpClient and all the 
 code is in a method and new HttpClient object is created for every 
 request. Are there any ways to make sure the connections are all being 
 purged properly? Are there any precautionary measures or flags we can 
 set on HttpClient API when communicating with a web server (running on 
 firm ware) with relatively less RAM and processing power (IpCamera with 
 built in web server)?
 
 Thanks for your time and help.
 Srini
 
 Kalnichevski, Oleg wrote:
 

 
 Mike and Oleg, the stack trace Srini included indicates that HttpClient 
 is
 attempting to create a new timeout thread on every connection - does 
 this
 always occur or is it just one timeout thread per httpclient instance?  
 It
 would be ideal if we could reduce this to one static thread as starting
 threads is never nice for server side apps.  Not sure how feasible that 
 is
 though.
  
 

 
 Hi Srini,
 HttpClient uses an additional controller thread to work around the 
 limitation of older ( 1.4) JDKs which do not provide a possibility to 
 set connect timeout. If you do not really need to control connect 
 timeout (for instance, when communicating with an intranet site with 
 good availability) simply set connect timeout to. That will prevent 
 HttpClient from spawning an additional thread per request.
 
 Adrian, et al
 Another possibility to use reflection to set connect timeout using the 
 Socket methods when running in JVM 1.4 or above
 
 Oleg
 
 
 
 -Original Message-
 From: Adrian Sutton [mailto:[EMAIL PROTECTED]
 Sent: Monday, February 02, 2004 09:03
 To: Commons HttpClient Project
 Subject: Re: Memory Leaks when web server hangs
 
 
 On 2/2/04 2:00 PM, Srinivas Vemula [EMAIL PROTECTED] 
 wrote:
 
 
 
  
 
 Hi All,
We are seeing thread leaks when having client open connections to a 
web
 server that hangs. Has any one seen this happening?? How do we ensure 
 that the
 library correctly closes  socket connections on failures, cleaning up 
 system
 resources, and  threads actually finish in  the timeout period and get 
 freed
 up. Would using MultiThreadedHttpConnectionManager
 file:///D:/silkroad/http-commons/commons-httpclient-2.0-rc3/docs/threading.ht
 ml#MultiThreadedHttpConnectionManager   be of any help??
  
 

 
 Hi Srini,
 If you're using the same HttpClient instance across multiple threads, you
 must use the MultiThreadedHttpConnectionManager or you'll run into 
 strange
 problems.  If you're using separate HttpClient instances, you may as well
 stick with the single threaded (default) connection manager.
 
 In terms of connections hanging - you probably want to look into the
 setConnectionTimeout and setTimeout methods of the HttpClient class.  
 These
 allow you to control how long HttpClient waits when making a connection 
 and
 how long it waits for data once the connection is established.  If you 
 have
 set either of these to 0 (not sure what the default is, 

RE: Memory Leaks when web server hangs

[Kalnichevski, Oleg]

Srini,

 If the web server is 
 down, we feel that HttpClient is not cleaning up failed connections 
 properly and thats resulting in Memory Leaks at the server side.

As any other java application HttpClient is not in a position to dispose of any unused 
objects. This is the job of Java's garbage collection. Java application may only 
politely ask GC to clean up but there's no way of reliably forcing garbage collection.

This is how connect timeout is implemented (Odi, please correct me if I miss 
something):
* HttpClient attempts to open a socket
* if connect timeout is set to a positive value, a controller thread is started.
* the controller thread sleeps for the given number of milliseconds
* if the controller thread detects that there's still no connection upon after being 
awoken up, if simply nulls the reference to the socket object awaiting connection, and 
lets GC to eventually dispose of that object
* If GC keeps those objects alive for considerably long period of time, JVM may 
eventually run out of resources

Ways to mend the situation

(1) As Roland said please strongdo reuse/strong the HttpClient instance. 
HttpClient class is fully thread-safe. By no reusing HttpClient you completely defeat 
the connection keep-alive stuff 
(2) Use the trick suggested by Marcus
(3) If you do not want to lose the benefits of connection reuse you have two options:
  * do not use HttpClient#setConnectionTimeout and pray that default JVM connect 
timeout setting is sane
  * fork HttpClient and make HttpConnection use Socket#connect(SocketAddress, int) 
(available as of java 1.4) instead of older Socket#connect(InetAddress, int) + 
controller thread workaround

http://java.sun.com/j2se/1.4.2/docs/api/java/net/Socket.html#connect(java.net.SocketAddress,%20int)

Oleg

-Original Message-
From: Srinivas Vemula [mailto:[EMAIL PROTECTED]
Sent: Monday, February 02, 2004 11:57
To: Commons HttpClient Project
Subject: Re: Memory Leaks when web server hangs


Oleg,
   
We are using JDK1.4.1 and connection time out is set to 30Ms and 
read time out to 60Ms. We are trying to connect to a IP Camera, and send 
a heart beat command to the camera to check for its availability every 
30 Secs from the time we find it is un available. If the web server is 
down, we feel that HttpClient is not cleaning up failed connections 
properly and thats resulting in Memory Leaks at the server side.

The code we use is the standard way of using HttpClient and all the 
code is in a method and new HttpClient object is created for every 
request. Are there any ways to make sure the connections are all being 
purged properly? Are there any precautionary measures or flags we can 
set on HttpClient API when communicating with a web server (running on 
firm ware) with relatively less RAM and processing power (IpCamera with 
built in web server)?

Thanks for your time and help.
Srini

Kalnichevski, Oleg wrote:

Mike and Oleg, the stack trace Srini included indicates that HttpClient is
attempting to create a new timeout thread on every connection - does this
always occur or is it just one timeout thread per httpclient instance?  It
would be ideal if we could reduce this to one static thread as starting
threads is never nice for server side apps.  Not sure how feasible that is
though.



Hi Srini,
HttpClient uses an additional controller thread to work around the limitation of 
older ( 1.4) JDKs which do not provide a possibility to set connect timeout. If you 
do not really need to control connect timeout (for instance, when communicating with 
an intranet site with good availability) simply set connect timeout to. That will 
prevent HttpClient from spawning an additional thread per request.

Adrian, et al
Another possibility to use reflection to set connect timeout using the Socket methods 
when running in JVM 1.4 or above

Oleg



-Original Message-
From: Adrian Sutton [mailto:[EMAIL PROTECTED]
Sent: Monday, February 02, 2004 09:03
To: Commons HttpClient Project
Subject: Re: Memory Leaks when web server hangs


On 2/2/04 2:00 PM, Srinivas Vemula [EMAIL PROTECTED] wrote:

  

Hi All,
  We are seeing thread leaks when having client open connections to a web
server that hangs. Has any one seen this happening?? How do we ensure that the
library correctly closes  socket connections on failures, cleaning up system
resources, and  threads actually finish in  the timeout period and get freed
up. Would using MultiThreadedHttpConnectionManager
file:///D:/silkroad/http-commons/commons-httpclient-2.0-rc3/docs/threading.ht
ml#MultiThreadedHttpConnectionManager   be of any help??



Hi Srini,
If you're using the same HttpClient instance across multiple threads, you
must use the MultiThreadedHttpConnectionManager or you'll run into strange
problems.  If you're using separate HttpClient instances, you may as well
stick with the single threaded (default) connection manager.

In terms of connections hanging - you probably want to 

RE: DO NOT REPLY [Bug 10794] - User interaction for authentication

[Roland Weber]

Hi Oleg,

I trust you on this. Unfortunately, I currently haven't
got the time to look at the patch. From the discussion
I got the feeling that we agree.

cheers,
  Roland





Kalnichevski, Oleg [EMAIL PROTECTED]
02.02.2004 11:36
Please respond to Commons HttpClient Project
 
To: Commons HttpClient Project 
[EMAIL PROTECTED]
cc: 
Subject:RE: DO NOT REPLY [Bug 10794]  - User 
interaction for authentication


Odi, Roland
Do you think you can live with this implementation? Can I commit the 
patch?

Oleg

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Friday, January 30, 2004 22:09
To: [EMAIL PROTECTED]
Subject: DO NOT REPLY [Bug 10794] - User interaction for authentication


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

User interaction for authentication





--- Additional Comments From [EMAIL PROTECTED]  2004-01-30 21:09 
---
Oleg,

Good point.  Code-wise everything looks good to me now.  With a little 
CredentialsProvider 
Javadocs it is good to commit.

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]

Re: Memory Leaks when web server hangs

[Michael Becke]

Hi Srini,

I want to echo Oleg's comments with one addition.

(1) As Roland said please strongdo reuse/strong the HttpClient 
instance. HttpClient class is fully thread-safe. By no reusing 
HttpClient you completely defeat the connection keep-alive stuff
HttpClient is thread safe, depending which connection manager is used.  
By default the SimpleHttpConnectionManager is used by HttpClient.  This 
connection manager is not thread safe, though it can be replaced with 
the MultiThreadedHttpConnectionManager which is.

Mike

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Promote HttpClient out of commons?

[Michael Becke]

Eric,

These are good questions, and I think they summarize well the current 
discussion.

Should HttpClient be promoted to a Jakarta project?
- Yes, that would seem to make sense, given the separate mailing list, 
the list of other commons libraries it depends upon, the separate 
mailing list, and the bugzilla needs, which all point to its slightly 
heavier nature than other commons projects.
At this point I would agree.  It seems very likely that we will move in 
this direction.  Arguments to the contrary are still welcome though.

Should HttpClient be a TLP?
- Don't think so.  Too much extra infrastructure, not much extra 
benefit.
Though moving to a TLP sounds exciting, I agree that it may be too much 
now.  In particular I think that HttpClient is not quite mature enough 
for this status.  Also, I do not think the developer community is quite 
large enough to support this yet either.

Becoming a TLP could be a long term goal.  As others have mentioned 
there are certainly possible HttpClient sub-projects (WebDAV, Gnutella, 
Http Cache).


When can HttpClient 2.0 ship?
- Although I think Oleg is being diligent in wanting to have a 
road-map in place for shipping 2.0, the contrary point is that as 
open-source software, the road-map is dependent on the interests that 
drive the product forward.  As such, it is entirely unpredictable. I 
would like to see/hear Oleg's ideas about where we should be going, 
since his ideas will probably be quite helpful to the rest of us, but 
I'm not sure we need to hold up the 2.0 release for that.  Email or a 
web-site posting would work just as well for that.
Hopefully soon.  A road map would be good, but I think we still need to 
debate if we want to hold up 2.0 before it's done.

- I seem to recall that a bug was actually reported against 2.0rc3, 
which means that we need to have a 2.0rc4, doesn't it?  I think we 
should be absolutely ruthless, that if a bug is not reported within 
the appropriate window, we should name whichever rcX release the 
final.  If need be, we can always come up with a 2.0.1 release that 
patches any future discovered bugs.
I could be wrong here, but I do not think a rc4 is required, unless we 
would like one.  I also prefer a 2.0 sooner, and a 2.0.1 if necessary.

Mike

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Re: Promote HttpClient out of commons?

[Kalnichevski, Oleg]

Otis,
It was a wild guess on my part based on my observations about recent developments in 
Apache Logging and Apache Ant space. I am quite happy to be wrong.

Oleg

-Original Message-
From: otisg [mailto:[EMAIL PROTECTED]
Sent: Monday, February 02, 2004 16:01
To: Sam Berlin
Subject: Re: Re: Promote HttpClient out of commons?


 As for supporting multiple platforms, isn't Ant a TLP and is
only 
 written in Java?  HttpClient is already cross-platform because
it's 
 written in Java -- I don't think there's a requirement that it
be 
 re-implemented in a different language for each platform.

I don't think so, either.
I think Oleg is wrong about this being a requirement.

Otis



Get your own 800 number
Voicemail, fax, email, and a lot more
http://www.ureach.com/reg/tag

-
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: Promote HttpClient out of commons?

[Ortwin Glück]

Kalnichevski, Oleg wrote:
This also affects package naming (org.apache.commons.httpclient vs org.apache.httpclient) which in its turn affects binary compatibility with the previous releases. 
Wow cool. Release now under Commons and rename packages later. This 
gives us the unique opportunity to break the APIs *radically* in future 
releases without ever interfering with previous versions :-)

Odi

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

When does an HttpException occur in httpclient.execute()?

[Brad O'Hearne]

Hey gang,

Just came across something rather odd.  I have an instance of HttpClient and
am invoking the execute() method passing it a PostMethod.  I have two
comments/questions:

1. It looks subtle, but I think the method needs to be rewritten to list its
HttpException prior to the IOException, so the compiler will force handling
of HttpException prior to forcing IOException.  This may be esoteric, but if
you handle the IOException first, the HttpException may go unnoticed, as it
is a subclass of IOException.

2. When is an HttpException thrown?  Looking at the Javadoc, the execute
method returns a response status, yet the HttpException holds the same types
of response statuses.  When does the execute method return with a response
status, versus when an HttpException is thrown to return the response
status?  I pulled my network cable out of my hub while the execute() method
was executing, and received an IOException, not an HttpException.  I also
returned various HTTP failure response statuses like 500 back to client from
my server, and wasn't getting an HttpException, but the execute method was
completing properly, and the status code was returned there.  When does an
HttpException occur?

Thanks for your help in advance,

BradO


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Multiple instances of HttpClient sharing state?

[Brad O'Hearne]

Hey gang,

I have a method that creates an instance of HttpClient and invokes an
execute method (an http post).  I have two separate threads that invoke this
method.  The method is totally thread-safe, i.e. each invocation of the
method will create its own instance of HttpClient.  Will these two separate
HttpClient instances share state (like the underlying connection)?  I am
finding that the second instance of HttpClient possesses the authenticated
cookie of the first instance, without authenticating.

Are instances of HttpClient sharing state, and if so, how do I keep
different instances of HttpClient's state totally independent?

BradO


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

More unwanted HttpClient logging

[Brad O'Hearne]

Got another one of these unwanted log messages spewing to System.out:

Feb 2, 2004 11:32:48 AM org.apache.commons.httpclient.HttpMethodBase
processRequest
INFO: Recoverable exception caught when processing request

Except this time, prior to this executing, I set the log level at WARN.
Anyone know why I am getting INFO messages when the log level is set to
WARN?  Here's the code I am using to set the log level:

System.setProperty(
org.apache.commons.logging.simplelog.log.org.apache.commons.httpclient,
WARN);

I'm trying to eliminate these log messages.  Thanks in advance for your
help!

Sincerely,

BradO


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: More unwanted HttpClient logging

[Sam Berlin]

Use:
 System.setProperty(org.apache.commons.logging.Log,
org.apache.commons.logging.impl.NoOpLog);
Technically it's better to set the property before starting Java (using  
- 
Dorg.apache.commons.logging.Log=org.apache.commons.logging.impl.NoOpLog) 
 when running java, but I believe if the System.setProperty is one of  
the first things done, it should still work.

Thanks,
 Sam
On Monday, February 2, 2004, at 12:08  PM, Brad O'Hearne wrote:

Got another one of these unwanted log messages spewing to System.out:

Feb 2, 2004 11:32:48 AM org.apache.commons.httpclient.HttpMethodBase
processRequest
INFO: Recoverable exception caught when processing request
Except this time, prior to this executing, I set the log level at WARN.
Anyone know why I am getting INFO messages when the log level is set to
WARN?  Here's the code I am using to set the log level:
System.setProperty(
org.apache.commons.logging.simplelog.log.org.apache.commons.httpclient 
,
WARN);

I'm trying to eliminate these log messages.  Thanks in advance for your
help!
Sincerely,

BradO

-
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: More unwanted HttpClient logging

[Brad O'Hearne]

Great, that worked beautifully! Thanks! Now, to turn logging back on, is
there a similar setProperty() value that works counter to
org.apache.commons.logging.impl.NoOpLog?

BradO

 -Original Message-
 From: Sam Berlin [mailto:[EMAIL PROTECTED]
 Sent: Monday, February 02, 2004 12:11 PM
 To: Commons HttpClient Project
 Subject: Re: More unwanted HttpClient logging


 Use:
   System.setProperty(org.apache.commons.logging.Log,
   org.apache.commons.logging.impl.NoOpLog);

 Technically it's better to set the property before starting Java (using
 -
 Dorg.apache.commons.logging.Log=org.apache.commons.logging.impl.NoOpLog)
   when running java, but I believe if the System.setProperty is one of
 the first things done, it should still work.

 Thanks,
   Sam


 On Monday, February 2, 2004, at 12:08  PM, Brad O'Hearne wrote:

  Got another one of these unwanted log messages spewing to System.out:
 
  Feb 2, 2004 11:32:48 AM org.apache.commons.httpclient.HttpMethodBase
  processRequest
  INFO: Recoverable exception caught when processing request
 
  Except this time, prior to this executing, I set the log level at WARN.
  Anyone know why I am getting INFO messages when the log level is set to
  WARN?  Here's the code I am using to set the log level:
 
  System.setProperty(
  org.apache.commons.logging.simplelog.log.org.apache.commons.httpclient
  ,
  WARN);
 
  I'm trying to eliminate these log messages.  Thanks in advance for your
  help!
 
  Sincerely,
 
  BradO
 
 
  -
  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]

Se5rvletExec httpClient compatibility issue?

[Ram Iyer]

Hello:

I am getting the following error when I use httpClient.

org.apache.commons.httpclient.HttpMethodBase readResponse
INFO: Discarding unexpected response: HTTP/1.1 100 Continue
I tried several things suggested by the website for similar problems
elsewhere. However, nothing has worked so far.
e.g:
   PostMethod post = new PostMethod(postingUrl);
   post.setHttp11(false);
   post.setUseExpectHeader(true);
I have also tried to get the new version of httpClient, but no go!

The irony is, everything is fine and dandy with Tomcat 4.1.

Any suggestions? Any help is greatly appreciated.

Ram

---
[This E-mail scanned for viruses by Declude Virus]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

ServletExec httpClient compatibility issue?

[Ram Iyer]

Hello:

I am getting the following error when I use httpClient.

org.apache.commons.httpclient.HttpMethodBase readResponse
INFO: Discarding unexpected response: HTTP/1.1 100 Continue
I tried several things suggested by the website for similar problems 
elsewhere. However, nothing has worked so far.

e.g:
  PostMethod post = new PostMethod(postingUrl);
  post.setHttp11(false);
  post.setUseExpectHeader(true);
I have also tried to get the new version of httpClient, but no go!

The irony is, everything is fine and dandy with Tomcat 4.1.

Any suggestions? Any help is greatly appreciated.

Ram

---
[This E-mail scanned for viruses by Declude Virus]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

httpclient and ejb

Hello,

I am planning to use the HttpClient form EJB and have noticed that
HttpConnection uses threads to implement the connection timeout mechanism. The way the 
threads are used shouldn't create any problems with the EJB programming restrictions 
about threads.
But I would want to hear your opinion as well.
Also can you explain why the HttpClient is considered faster than the Sun
implementation.

Regards,

Milen


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Odd problem

[Brett Knights]

That's what I thought when I first looked at it but it appears to use
the JDK connection classes.
A grinder transcript using HttpUnit (succeeds) and HttpClient (fails)
follows. One thing that's odd is that the HttpClient transaction looks
more like the transcript I get with IE than does the one using
HttpUnit.

HTH

With HttpUnit:
**
***


--- localhost:4078-server.com:443 closed --
--- server.com:443-localhost:4078 closed --
--- localhost:4345-server.com:443 opened --
--- server.com:443-localhost:4345 opened --
-- localhost:4345-server.com:443 --
POST /app/login/nllogin.nl HTTP/1.1
User-Agent: httpunit/1.5
Host: server.com
Content-Type: application/x-www-form-urlencoded
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Cache-Control: no-cache
Pragma: no-cache
Connection: keep-alive
Content-Length: 66


-- localhost:4345-server.com:443 --
password=blahemail=brett%40knightsofthenet.comct=0jsenabled=T
-- server.com:443-localhost:4345 --
HTTP/1.1 302 Moved Temporarily
Date: Mon, 02 Feb 2004 15:08:23 GMT
Server: Oracle9iAS/9.0.2 Oracle HTTP Server
Set-Cookie: NS_VER=9.1; domain=server.com; path=/
Set-Cookie:
JSESSIONID=9b62d46494a44d2588f987b65288ca51.mkbxr2PEmlnva34P-BbQmkLz-A
Tzr6Lzn6rzqwTxpQOUc30KaNDvmQbJrkTOokTBrxyL8Q5xmReHoA5Qmh0LbgTvmQbO-kDv
rA4KahiIqRnvp6iIpAjOp6jynQjM-AbJpgaQch0PbwbCpQPz8QvJpkixn6jAmljGr5XDqQ
LvpAe_; Path=/
Set-Cookie: lastUser=ACCT102534_3_3; Expires=Mon, 09-Feb-2004 15:08:24
GMT; Path=/
Set-Cookie: loginredirect=T; Domain=server.com; Expires=Fri,
02-Apr-2004 15:08:24 GMT; Path=/
Set-Cookie:
stickytags=T1:byMeU53W,T2:byMeU53W,T3:byMeU53W,T4:byMeU53W,T5:byMeU53W
,T6:byMeU53W,T7:byMeU53W,T8:byMeU53W,T9:byMeU53W,T10:byMeU53W,T11:byMe
U53W,T12:byMeU53W,T13:byMeU53W,T14:byMeU53W,T15:byMeU53W,T16:byMeU53W;
Path=/
Cache-Control: private
Location: /app/center/card.nl?sc=-29
P3P: CP=CAO PSAa OUR BUS PUR
Keep-Alive: timeout=15, max=1000
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html; charset=iso-8859-1

0


-- localhost:4345-server.com:443 --
GET /app/external/xml/upload/upload.nl HTTP/1.1
User-Agent: httpunit/1.5

-- localhost:4345-server.com:443 --
Cookie:
JSESSIONID=9b62d46494a44d2588f987b65288ca51.mkbxr2PEmlnva34P-BbQmkLz-A
Tzr6Lzn6rzqwTxpQOUc30KaNDvmQbJrkTOokTBrxyL8Q5xmReHoA5Qmh0LbgTvmQbO-kDv
rA4KahiIqRnvp6iIpAjOp6jynQjM-AbJpgaQch0PbwbCpQPz8QvJpkixn6jAmljGr5XDqQ
LvpAe_;lastUser=ACCT102534_3_3;stickytags=T1:byMeU53W,T2:byMeU53W,T3:b
yMeU53W,T4:byMeU53W,T5:byMeU53W,T6:byMeU53W,T7:byMeU53W,T8:byMeU53W,T9
:byMeU53W,T10:byMeU53W,T11:byMeU53W,T12:byMeU53W,T13:byMeU53W,T14:byMe
U53W,T15:byMeU53W,T16:byMeU53W
Host: server.com
Cache-Control: no-cache

-- localhost:4345-server.com:443 --
Pragma: no-cache
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive


-- server.com:443-localhost:4345 --
HTTP/1.1 200 OK
Date: Mon, 02 Feb 2004 15:08:24 GMT
Server: Oracle9iAS/9.0.2 Oracle HTTP Server
Set-Cookie:
JSESSIONID=9b62d46494a44d2588f987b65288ca51.mkbxr2PEmlnva34P-BbQmkLz-A
Tzr6Lzn6rzqwTxpQOUc30KaNDvmQbJrkTOokTBrxyL8Q5xmReHoA5Qmh0LbgTvmQbO-kDv
rA4KahiIqRnvp6iIpAjOp6jynQjM-AbJpgaQch0PbwbCpQPz8QvJpkixn6jAmljGr5XDqQ
LvpAe_; Path=/
Set-Cookie: NLVisitorId=GEVsNl-JAHPkxcOm; Expires=Sun, 23-Jan-2005
15:08:24 GMT; Path=/
Last-Modified: Mon, 02 Feb 2004 15:08:23 GMT
Expires: 0
P3P: CP=CAO PSAa OUR BUS PUR
Pragma: No-Cache
Cache-Control: No-Cache
Keep-Alive: timeout=15, max=999
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html; charset=iso-8859-1


-- server.com:443-localhost:4345 --
1ffa

-- server.com:443-localhost:4345 --

html
head
meta http-equiv=Content-Type content=text/html;
charset=ISO-8859-1
... receive the expected page

**
***


With HttpClient:
**
***
--- localhost:4345-server.com:443 closed --
--- server.com:443-localhost:4345 closed --
--- localhost:2001-server.com:443 opened --
--- server.com:443-localhost:2001 opened --
-- localhost:2001-server.com:443 --
POST /app/login/nllogin.nl HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;
Q312461)
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Accept: */*
Host: server.com
Content-Length: 66
Content-Type: application/x-www-form-urlencoded


-- localhost:2001-server.com:443 --
email=brett%40knightsofthenet.compassword=blahjsenabled=Tct=0
-- server.com:443-localhost:2001 --
HTTP/1.1 302 Moved Temporarily
Date: Mon, 02 Feb 2004 17:05:41 GMT
Server: Oracle9iAS/9.0.2 Oracle HTTP Server
Set-Cookie: NS_VER=9.1; domain=server.com; path=/
Set-Cookie:
JSESSIONID=0d19260c44084c0b86afcf5b3ddeee62.mkbxr2PEmlnva30T-BbQmkLz-A

Re: Odd problem

[Michael Becke]

Hi Brett,

This is a bit of a guess, but it could be because of the cookie format. 
 Try using the cookie compatibility setting:

CookiePolicy.setDefaultPolicy(CookiePolicy.COMPATIBILITY);

Mike

On Feb 2, 2004, at 3:57 PM, Brett Knights wrote:

That's what I thought when I first looked at it but it appears to use
the JDK connection classes.
A grinder transcript using HttpUnit (succeeds) and HttpClient (fails)
follows. One thing that's odd is that the HttpClient transaction looks
more like the transcript I get with IE than does the one using
HttpUnit.
HTH

With HttpUnit:
**
***
--- localhost:4078-server.com:443 closed --
--- server.com:443-localhost:4078 closed --
--- localhost:4345-server.com:443 opened --
--- server.com:443-localhost:4345 opened --
-- localhost:4345-server.com:443 --
POST /app/login/nllogin.nl HTTP/1.1
User-Agent: httpunit/1.5
Host: server.com
Content-Type: application/x-www-form-urlencoded
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Cache-Control: no-cache
Pragma: no-cache
Connection: keep-alive
Content-Length: 66
-- localhost:4345-server.com:443 --
password=blahemail=brett%40knightsofthenet.comct=0jsenabled=T
-- server.com:443-localhost:4345 --
HTTP/1.1 302 Moved Temporarily
Date: Mon, 02 Feb 2004 15:08:23 GMT
Server: Oracle9iAS/9.0.2 Oracle HTTP Server
Set-Cookie: NS_VER=9.1; domain=server.com; path=/
Set-Cookie:
JSESSIONID=9b62d46494a44d2588f987b65288ca51.mkbxr2PEmlnva34P-BbQmkLz-A
Tzr6Lzn6rzqwTxpQOUc30KaNDvmQbJrkTOokTBrxyL8Q5xmReHoA5Qmh0LbgTvmQbO-kDv
rA4KahiIqRnvp6iIpAjOp6jynQjM-AbJpgaQch0PbwbCpQPz8QvJpkixn6jAmljGr5XDqQ
LvpAe_; Path=/
Set-Cookie: lastUser=ACCT102534_3_3; Expires=Mon, 09-Feb-2004 15:08:24
GMT; Path=/
Set-Cookie: loginredirect=T; Domain=server.com; Expires=Fri,
02-Apr-2004 15:08:24 GMT; Path=/
Set-Cookie:
stickytags=T1:byMeU53W,T2:byMeU53W,T3:byMeU53W,T4:byMeU53W,T5:byMeU53W
,T6:byMeU53W,T7:byMeU53W,T8:byMeU53W,T9:byMeU53W,T10:byMeU53W,T11:byMe
U53W,T12:byMeU53W,T13:byMeU53W,T14:byMeU53W,T15:byMeU53W,T16:byMeU53W;
Path=/
Cache-Control: private
Location: /app/center/card.nl?sc=-29
P3P: CP=CAO PSAa OUR BUS PUR
Keep-Alive: timeout=15, max=1000
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html; charset=iso-8859-1
0

-- localhost:4345-server.com:443 --
GET /app/external/xml/upload/upload.nl HTTP/1.1
User-Agent: httpunit/1.5
-- localhost:4345-server.com:443 --
Cookie:
JSESSIONID=9b62d46494a44d2588f987b65288ca51.mkbxr2PEmlnva34P-BbQmkLz-A
Tzr6Lzn6rzqwTxpQOUc30KaNDvmQbJrkTOokTBrxyL8Q5xmReHoA5Qmh0LbgTvmQbO-kDv
rA4KahiIqRnvp6iIpAjOp6jynQjM-AbJpgaQch0PbwbCpQPz8QvJpkixn6jAmljGr5XDqQ
LvpAe_;lastUser=ACCT102534_3_3;stickytags=T1:byMeU53W,T2:byMeU53W,T3:b
yMeU53W,T4:byMeU53W,T5:byMeU53W,T6:byMeU53W,T7:byMeU53W,T8:byMeU53W,T9
:byMeU53W,T10:byMeU53W,T11:byMeU53W,T12:byMeU53W,T13:byMeU53W,T14:byMe
U53W,T15:byMeU53W,T16:byMeU53W
Host: server.com
Cache-Control: no-cache
-- localhost:4345-server.com:443 --
Pragma: no-cache
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive
-- server.com:443-localhost:4345 --
HTTP/1.1 200 OK
Date: Mon, 02 Feb 2004 15:08:24 GMT
Server: Oracle9iAS/9.0.2 Oracle HTTP Server
Set-Cookie:
JSESSIONID=9b62d46494a44d2588f987b65288ca51.mkbxr2PEmlnva34P-BbQmkLz-A
Tzr6Lzn6rzqwTxpQOUc30KaNDvmQbJrkTOokTBrxyL8Q5xmReHoA5Qmh0LbgTvmQbO-kDv
rA4KahiIqRnvp6iIpAjOp6jynQjM-AbJpgaQch0PbwbCpQPz8QvJpkixn6jAmljGr5XDqQ
LvpAe_; Path=/
Set-Cookie: NLVisitorId=GEVsNl-JAHPkxcOm; Expires=Sun, 23-Jan-2005
15:08:24 GMT; Path=/
Last-Modified: Mon, 02 Feb 2004 15:08:23 GMT
Expires: 0
P3P: CP=CAO PSAa OUR BUS PUR
Pragma: No-Cache
Cache-Control: No-Cache
Keep-Alive: timeout=15, max=999
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html; charset=iso-8859-1
-- server.com:443-localhost:4345 --
1ffa
-- server.com:443-localhost:4345 --

html
head
meta http-equiv=Content-Type content=text/html;
charset=ISO-8859-1
... receive the expected page
**
***
With HttpClient:
**
***
--- localhost:4345-server.com:443 closed --
--- server.com:443-localhost:4345 closed --
--- localhost:2001-server.com:443 opened --
--- server.com:443-localhost:2001 opened --
-- localhost:2001-server.com:443 --
POST /app/login/nllogin.nl HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;
Q312461)
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Accept: */*
Host: server.com
Content-Length: 66
Content-Type: application/x-www-form-urlencoded
-- localhost:2001-server.com:443 --
email=brett%40knightsofthenet.compassword=blahjsenabled=Tct=0
-- server.com:443-localhost:2001 --
HTTP/1.1 302 Moved Temporarily
Date: 

DO NOT REPLY [Bug 26382] - Update license terms

[bugzilla]

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

Update license terms





--- Additional Comments From [EMAIL PROTECTED]  2004-02-03 03:00 ---
I'm wondering if we should change licenses in mid release.  I do not know if 2.0 
causes any 
problems for users, but it seems like a pretty big change for this release.  Perhaps 
we can wait until 
after 2.0 is released.  How does everyone feel about this?

Mike

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 26500] - New socket timeout value wont have effect if connection is reused

[bugzilla]

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

New socket timeout value wont have effect if connection is reused





--- Additional Comments From [EMAIL PROTECTED]  2004-02-03 03:17 ---
Created an attachment (id=10195)
Patch 1

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 26500] - New socket timeout value wont have effect if connection is reused

[bugzilla]

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

New socket timeout value wont have effect if connection is reused





--- Additional Comments From [EMAIL PROTECTED]  2004-02-03 03:18 ---
This should do it I think.  Any comments.

Mike

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]