I would like to fix PR #25972 and tidy up a few other things. Any
objections to my adding myself to STATUS and committing, or shall I
submit patches?
Phil
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands,
Hi,
as I am about to write a first version of a JaxMe schema reader taking beans
as input I am sure that I would rewrite lots of code from Betwixt. In
particular I am sure, that I would rewrite code that inspects the beans
and assigns guidelines like this element wants its properties as
I hadn't realized there were any open bugs on the bugzilla.
Go for it, just commit your work. :-)
-Mark
Phil Steitz wrote:
I would like to fix PR #25972 and tidy up a few other things. Any
objections to my adding myself to STATUS and committing, or shall I
submit patches?
Phil
--
Mark
--- Phil Steitz [EMAIL PROTECTED] wrote:
I would like to fix PR #25972 and tidy up a few other things. Any
objections to my adding myself to STATUS and committing, or shall I
submit patches?
Phil
I don't understand why the bug report is filed against Math, but I'm fine with
you going
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=25991.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Al Chou wrote:
--- Phil Steitz [EMAIL PROTECTED] wrote:
I would like to fix PR #25972 and tidy up a few other things. Any
objections to my adding myself to STATUS and committing, or shall I
submit patches?
Phil
I don't understand why the bug report is filed against Math, but I'm fine with
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=25995.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
+1 to subclassing and agreement ;)
On Wed, 07 Jan 2004 13:38:27 -0600, steve cohen [EMAIL PROTECTED] said:
[SNIPPED]
On Wednesday 07 January 2004 11:44 am, Daniel F. Savarese wrote:
In message [EMAIL PROTECTED], Jeffrey D. Brekke writes:
[Alternatives to VMS Parser/Version issue]
Another
Berin Loritsch wrote:
I would like to see about getting the Avalon Event package migrated to
commons, which really has little to do with Avalon itself. In
contrast to the current Jakarat Commons Event package, the Avalon
Event package is developed with the Staged Event Driven Architecture
__matthewHawthorne wrote:
Berin Loritsch wrote:
I would like to see about getting the Avalon Event package migrated to
commons, which really has little to do with Avalon itself. In
contrast to the current Jakarat Commons Event package, the Avalon
Event package is developed with the
ggregory2004/01/08 11:22:22
Modified:codec/src/java/org/apache/commons/codec/language
DoubleMetaphone.java
Log:
Qualify inst var access with this.
Revision ChangesPath
1.18 +13 -13
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=25995.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
dfs 2004/01/08 13:28:26
Modified:net/xdocs changes.xml
Log:
Added entries for recent changes (scohen removal of JDK 1.1
incompatibilities for v1.1.1, scohen's addition of
FTPFileEntryParserFactory and entry parser autodetection, scohen/dfs
deprecation of FTPFileListParser,
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=25995.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
scolebourne2004/01/08 14:18:16
Modified:collections/src/java/org/apache/commons/collections
IteratorUtils.java BinaryHeap.java
Log:
Fix javadoc
Revision ChangesPath
1.20 +3 -4
scolebourne2004/01/08 14:26:08
Modified:collections/src/java/org/apache/commons/collections/functors
PrototypeFactory.java
collections/src/java/org/apache/commons/collections
CollectionUtils.java PriorityQueue.java
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=25936.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
scolebourne2004/01/08 14:37:31
Modified:collections/src/java/org/apache/commons/collections/comparators
NullComparator.java
collections/src/java/org/apache/commons/collections/iterators
UnmodifiableMapIterator.java
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=25937.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
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=24537.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
rdonkin 2004/01/08 14:38:11
Modified:beanutils/src/java/org/apache/commons/beanutils
WrapDynaBean.java
beanutils/src/test/org/apache/commons/beanutils
WrapDynaBeanTestCase.java
Log:
Added ability to get wrapped instance
There was talk of adding static 'newInstance() methods to the decorator
classes to provide the default ArrayList/HashMap combinations. Never got
done though.
Stephen
- Original Message -
From: Michael Heuer [EMAIL PROTECTED]
Would it be possible to add a class that extends
rdonkin 2004/01/08 14:59:07
Modified:beanutils/src/java/org/apache/commons/beanutils
WrapDynaClass.java
beanutils/src/test/org/apache/commons/beanutils
AlphaBean.java WrapDynaBeanTestCase.java
Log:
Added newInstance
Mark R. Diggory wrote:
Sorry, that may have be a bit naive. More specifically, I know that
open/closeReplay file reloads the values file inputstream. I suspect
that these are only used in one other location in the ValueServer. Maybe
they should be private or consolidated into the getNExtReplay
husted 2004/01/08 19:29:41
Modified:chain/src/java/org/apache/commons/chain/web/faces
FacesSetLocaleCommand.java
FacesGetLocaleCommand.java
Log:
Update for current jsf-1.0-beta release.
Revision ChangesPath
1.6 +4 -4
husted 2004/01/08 19:32:07
Modified:chainproject.xml
Log:
Update portlet and jsf dependencies; migrate deprecated id element to groupId and
artifactId
Revision ChangesPath
1.2 +38 -18jakarta-commons-sandbox/chain/project.xml
Index: project.xml
husted 2004/01/08 19:32:53
Modified:chainproject.xml
Log:
Tidy formatting
Revision ChangesPath
1.3 +6 -10 jakarta-commons-sandbox/chain/project.xml
Index: project.xml
===
RCS file:
brekke 2004/01/08 20:19:44
Modified:net/src/test/org/apache/commons/net/ftp/parser
DefaultFTPFileEntryParserFactoryTest.java
Log:
remove unused import
Revision ChangesPath
1.2 +0 -1
brekke 2004/01/08 20:20:16
Modified:net/xdocs changes.xml tasks.xml
Log:
Fixed typo in changes doc and added outstanding to-do' to tasks.xml.
Revision ChangesPath
1.19 +0 -1 jakarta-commons/net/xdocs/changes.xml
Index: changes.xml
On Thu, 08 Jan 2004 17:38:50 -0500, Daniel F. Savarese [EMAIL PROTECTED]
said:
[SNIPPED]
In other news, we need to write a status file to keep track of what
we need to get done before a 1.2 release. I'll get to it over the
next week if no one beats me to it. So far we've got the VMS parser
tobrien 2004/01/08 21:05:10
jakarta-commons/cli/src/media - New directory
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
tobrien 2004/01/08 21:06:01
Modified:cli project.properties project.xml
cli/xdocs navigation.xml
Added: cli/src/media logo.xcf
cli/xdocs/images logo.png
Log:
Regenerated CLI site, added logo, and updated NAV. Site hadn't been updated since
Phil Steitz wrote:
Mark R. Diggory wrote:
Sorry, that may have be a bit naive. More specifically, I know that
open/closeReplay file reloads the values file inputstream. I suspect
that these are only used in one other location in the ValueServer.
Maybe they should be private or consolidated
Hello,
Streamable codecs make a lot of sense for some codecs (but perhaps not for
the language codecs). Thanks for bringing the topic up. I took a very quick
look at the code you refer to and it seems to be a separate framework from
what we have in [codec] today (I could be wrong of course),
dfs 2004/01/08 22:19:23
Modified:net/src/java/org/apache/commons/net/telnet
TelnetInputStream.java
Log:
Jeff Barrett [EMAIL PROTECTED] reports that:
I'm using commons-net to ftp a bunch of files around every night as a batch process.
It probably
Committers,
what about publishing a roadmap (replacing the status page) on the
HttpClient project website? It seems of a general intrest to know what
the projects status is and what are the next steps. I don't mean to
publish actual dates but general ideas of where we are going. We can use
Srinivas,
Making predictions about release dates for open-source projects is a nasty business.
The final 2.0 release was initially anticipated in June-July 2003. It did not quite
work out for us. Even though 2.0 is _almost_ finished (we have not been seeing any
major bugs since September 2003 I
Hi All,
I completely understand. Only reason I was curious was cos the
web-site mentions all the big stuff planned for 2.1. Thank you all for
your efforts.
srini
Kalnichevski, Oleg wrote:
Srinivas,
Making predictions about release dates for open-source projects is a nasty business.
The
Kalnichevski, Oleg wrote:
Makes sense. Anyways, some sort of coherent statement with regards to the post-2.0 development directions is pretty much a must for the 2.0 Final. I think I could handle this task while you, guys, concentrate on reviewing the pending patches, even though I am a
Thinking about it as a 3.0 release, though, I think we should make an
effort to change the 3.0 API so that we're more confident of our ability
to make critical incremental changes.
I hate revisiting the same discussions that raged on this forum 6 months ago, but this
is exactly the point.
Kalnichevski, Oleg wrote:
I hate revisiting the same discussions that raged on this forum 6 months ago, but this is exactly the point. If we decide to go 3.0, then we should stop playing 'bend 2.0 API around' kind of games and should get down to some serious work (which would inevitably delay
What's wrong with that?
Version inflation is as evil and misleading, IMHO
Anyways, why do not we have all HttpClient regualrs vote on this issue and get it over
with?
Oleg
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For
Kalnichevski, Oleg wrote:
Version inflation is as evil and misleading, IMHO
Sure. Especially in Java, where Jar-Versioning is a somewhat unsolved
problem (okay you CAN solve it with classloaders but it's a PITA).
Still, you were taling about years :-)
Anyways, why do not we have all HttpClient
Eric,
I find it hard to disagree with you, being a fan of incremental, iterative development
myself. I just regret all the energy and time that went into 2.0 API compatibility
workarounds so far. If we go with 3.0 then I would like to see a few more 2.0 API
breakages that had been turned down
Ortwin Glück wrote:
Why not just release the current one as 3.0 and make a 4.0 after that?
What's wrong with that? We all want a release SOON and not within
months. If we make more API changes for 4.0 who cares.
Sorry, I was talking about CVS HEAD here. Forget the SOON.
Rather than removing classes right away, I'd like to see them deprecated
for at least one major release. That leaves clients with the crumbs
that they can follow to migrate their code, rather than discovering that
their code is completely broken and must be rewritten. So I would say
I agree. A coherent roadmap, or something of the like, would be quite
useful. Don't be too hard on yourself, I've always found your writing
to be quite good.
Mike
Kalnichevski, Oleg wrote:
Makes sense. Anyways, some sort of coherent statement with regards to
the post-2.0 development
Hi all,
Under some exceptional circumstances, reading from a SocketInputStream
can cause an ArrayIndexOutOfBoundsException. We have seen this occur
in many other places (non HttpClient related), and since including
HttpClient a few bugs have been reported with it as well. The exact
I agree that working around JVM bugs is annoying, but in most cases
there's really not much else you can do. However, it's not acceptable
to allow a runtime exception to kill code that should otherwise work.
The bug so far has only been reported with Windows (but that could be
because
Seems like a good time to introduce the separate request/response
design. We could create HttpRequest and HttpResponse interfaces. That
way we could have HttpMethodBase, et al implement both. To solve the
interface problem we could just explicitly comment
HttpRequest/HttpResponse saying
50 matches
Mail list logo
