Re: [vfs] parsing uri
Hello!
Anyway there is nothing to it so mario can
probably make the fix right away. But the list of
special characters needs still to be addressed.
I think at least {'#', ' '}
I tried to find a way without decode/encode the url again.
This turns out to work - could you please check it out.
btw. you catched a vespiary - usign the '%' as valid filename character
turns out to be a problem through all archive like filesystem providers
(tar, zip, ..). Also the FileObject.getName().getURI() didnt correctly
encode the path i.e. one cant use its result to resolve a file again.
I have to investigate this in more detail.
If I could I would assign you 12 points (the maximium) for catching this
problem ;-)
---
Mario
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33893] New: - [digester] xmlrules does not support NodeCreateRule
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33893. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33893 Summary: [digester] xmlrules does not support NodeCreateRule Product: Commons Version: 1.6 Final Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P3 Component: Digester AssignedTo: commons-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] xmlrules does not support NodeCreateRule -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33895] New: - [digester] xmlrules does not support setNamespaceURI
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33895. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33895 Summary: [digester] xmlrules does not support setNamespaceURI Product: Commons Version: 1.6 Final Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P3 Component: Digester AssignedTo: commons-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] It is not possible to set the namespace-uri associated with a Rule instance created via xmlrules. This means that it is not possible to process a document with namespaces using xmlrules. [well, it might be possible to set namespaceAware to false, then include the prefix in the pattern, but that's a nasty hack]. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[GUMP@brutus]: Project commons-jelly-tags-xml (in module commons-jelly) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-jelly-tags-xml has an issue affecting its community integration. This issue affects 12 projects, and has been outstanding for 16 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-define : Commons Jelly - commons-jelly-tags-html : Commons Jelly - commons-jelly-tags-http : Commons Jelly - commons-jelly-tags-jaxme : Commons Jelly - commons-jelly-tags-jetty : Commons Jelly - commons-jelly-tags-jface : Commons Jelly - commons-jelly-tags-jsl : Commons Jelly - commons-jelly-tags-swing : Commons Jelly - commons-jelly-tags-xml : Commons Jelly - commons-jelly-tags-xmlunit : Commons Jelly - maven : Project Management Tools - maven-bootstrap : Project Management Tools Full details are available at: http://brutus.apache.org/gump/public/commons-jelly/commons-jelly-tags-xml/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-jelly-tags-xml-08032005.jar] identifier set to project name -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/test-reports -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://brutus.apache.org/gump/public/commons-jelly/commons-jelly-tags-xml/gump_work/build_commons-jelly_commons-jelly-tags-xml.html Work Name: build_commons-jelly_commons-jelly-tags-xml (Type: Build) Work ended in a state of : Failed Elapsed: 13 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml] CLASSPATH: /opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-08032005.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-08032005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-08032005.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-08032005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-08032005.jar - [mkdir] Created dir: /home/gump/workspaces2/public/workspace/commons-jelly/jelly-tags/xml/target/classes java:compile: [echo] Compiling to /home/gump/workspaces2/public/workspace/commons-jelly/jelly-tags/xml/target/classes [echo] == NOTE: Targetting JVM 1.4, classes will not run on earlier JVMs == [javac] Compiling 16 source files to /home/gump/workspaces2/public/workspace/commons-jelly/jelly-tags/xml/target/classes java:jar-resources: test:prepare-filesystem: [mkdir] Created dir: /home/gump/workspaces2/public/workspace/commons-jelly/jelly-tags/xml/target/test-classes [mkdir] Created dir: /home/gump/workspaces2/public/workspace/commons-jelly/jelly-tags/xml/target/test-reports test:test-resources: Copying 36 files to
Re: [vfs] parsing uri
btw. you catched a vespiary - usign the '%' as valid filename character
turns out to be a problem through all archive like filesystem providers
(tar, zip, ..). Also the FileObject.getName().getURI() didnt correctly
encode the path i.e. one cant use its result to resolve a file again.
I have to investigate this in more detail.
Already one year ago when I was fiddling with classloaders I found
out how URL encoding (eg. in URLClassLoader) is completely flawed
in Java. There are bug reports about this in java.sun.com but the official
answer to this seems to be that the way URL encoding is done now
is too central to be changed since big software has been written that
assume that URLs are encoded wrongly.
Therefore encode the file path to URL in vfs. It's not hard and
it is the only way.
This theme brings up an interesting topic about the set of characters that
are allowed to appear in file name. As we know the set of prohibited
characters
on different operating systems is - well different.
Since vfs is cross-platform file-system it should define it's own set of
prohibited characters. Maybe union of prohibited characters on win/unix/mac.
But that is impossible since it will find files on unix that do have
characters
that are prohibited - say on windows.
Maybe FileSystemProvider when instantiated has to be able to tell which
characters are allowed. Of course vfs can be completely neutral about
the issue
and let the os / network protocol tell that something is wrong when
illegal filename
was used. Nevertheless it would be excellent to document these kinds of
issues
as part of the vfs project. Then it would be easier also to say for sure
which
characters need to be encoded for URL.
Also I think decodeURI and encodeURI should be symmetrical.
Maybe we don't need to know anything about filenames.
We only need to know about URI.
What is the set of characters that need to be encoded in URI.
Well let's see RFC 2396
/reserved = ; | / | ? | : | @ | | = | + | $ | ,/
These are reserved characters because they have a special meaning in URI
They work as delimiters between different components. and the schema
finally decides if they are delimiters or not (I think)
They should be escaped but note:
/2.4.2. When to Escape and Unescape
A URI is always in an escaped form, since escaping or unescaping a
completed URI might change its semantics. Normally, the only time
escape encodings can safely be made is when the URI is being created
from its component parts; each component may have its own set of
characters that are reserved, so only the mechanism responsible for
generating or interpreting that component can determine whether or
not escaping a character will change its semantics. Likewise, a URI
must be separated into its components before the escaped characters
within those components can be safely decoded./
So when I have a path like /foo/%bar I should encode % but not /
Looking at the reserved character set in case of file: schema I
think none of them should be escaped.
/2.4.3. Excluded US-ASCII Characters
/
/control = US-ASCII coded characters 00-1F and 7F hexadecimal/
/space = US-ASCII coded character 20 hexadecimal
delims = | | # | % |
The angle-bracket and and double-quote () characters are
excluded because they are often used as the delimiters around URI in
text documents and protocol fields. The character # is excluded
because it is used to delimit a URI from a fragment identifier in URI
references (Section 4). The percent character % is excluded because
it is used for the encoding of escaped characters./
I think these should always be encoded in URI
There exists also unwise characters
/Other characters are excluded because gateways and other transport
agents are known to sometimes modify such characters, or they are
used as delimiters.
unwise = { | } | | | \ | ^ | [ | ] | `
/
But I don't think these should be encoded.
So all in all for file URI schema I think the characters to encode are:
*control = US-ASCII coded characters 00-1F and 7F hexadecimal*
*space = US-ASCII coded character 20 hexadecimal*
*delims = | | # | % | *
On my Linux I can create directory
/#%/
I just need write mkdir \\#%\
Also it has happened to me that a program has created
a file name that contains newlines and some other non-printable
characters.
Copying this folder to some other os would result (probably)
in exception.
//
If I could I would assign you 12 points (the maximium) for catching this
problem ;-)
Why can't you ?-)
- rami
Re: [vfs] parsing uri
Hello Rami! Thanks for collection all this informations, this is very usefull and I will try my best to implement it in VFS. Therefore encode the file path to URL in vfs. It's not hard and it is the only way. Currently VFS tries to decode as soon as possible - and yes, I think thats wrong. I think (no decision has made now) I will change this to decode only if its needet e.g. if the real physical access will be made - and then only if the underlaying library requires it e.g. ftp or http might work with the encoded uris even better. Sounds like a long night today :-) Why can't you ?-) Rami 12 points. --- Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 32643] - [fileupload] FileUploadException, Stream ended unexpectedly
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32643. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=32643 --- Additional Comments From [EMAIL PROTECTED] 2005-03-08 12:46 --- I got a similar problem (Processing of multipart/form-data request failed. Read timed out) in the same method, but somehow I am not sure this error (or any of the other errors in this bug report) is a problem of FileUpload. To track down the error, it would help very much to have a stacktrace of the original Exception which was caught in parseRequest. One possibility for this would be to write it to a log file, but FileUpload does not seem to use any logger. Another possibility would be to use a NestableException out of the commons.lang library (or use the code from there, if one does not want to depend on the commons.lang library) -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vfs] parsing uri
Rami 12 points. I'm honored. - Rami - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vfs] parsing uri
Rami Ojares wrote: file.toURI().toString() is not the way to go. The reason is simple. It does not work. What does it does not work mean? That is, what is an example failure case? Cheers, --binkley - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] distribution packaging
Brian, From a cursory look at your document, I have to *speculate* that the changes you describe do not solve the core flaws in JCL but merely hide them by falling back on java.util.logging. However, I am only *speculating* as I have not had a chance to study your document with the care that it deserves. After careful study of JCL, I am convinced that JCL is broken beyond hope. While its interfaces can be salvaged, its implementation must be thrown away entirely. While this opinion is not popular around here, it is based on verifiable facts, not wishful thinking that does not survive critical scrutiny. I was very surprised to discover that several voting participants in JCL are more concerned about covering their political asses rather than verifiable facts. Until this day, JCL developers have not acknowledged the fatal flaws in their software. The talk always has been about corner cases even if the problems faced by users are frequent and manifestly major. The JCL wiki still qualifies my past analysis as FUD [1]. Many of us are drawn to open source for the love of writing good software. As any engineering discipline, software development has its roots in scientific methodology, where one hopes that verifiable facts prime over petty political considerations. It seems to me that when someone comes with verifiable facts, the right attitude is to acknowledge the facts rather than try to ignore or ridicule them. We all make mistakes. However, in technical branches, we have the luxury of experimentation. When facts debunk our beliefs, we can either rise to the occasion and rectify those false beliefs or ignore the facts and plow on to until the facts catch up with us. In late 1999, National Magazine published an article about a newly discovered Archaeoraptor fossil, calling it a true missing link demonstrating the relation between birds and dinosaurs, supposedly bringing to conclusion a debate raging since the 1860s. When XU XING, a Chineese palaeontologist, declared that the missing-link fossil acquired by National Geographic was a fake, the illustrious magazine rechecked their facts and admitted their mistake. They had invested considerably in the article and had already checked their facts. However, when XU XING's message arrived, they did not summarily dismiss it or ridicule his findings. They rechecked their facts. For the details of this fascinating story, please refer to [2]. Recently the ASF celebrated its 10th anniversary. IMHO, if the foundation is ever to celebrate its 100th anniversary, we better develop a better tradition for dealing with critical input. [1] http://wiki.apache.org/jakarta-commons/Commons_20Logging_20FUD [2] http://www.bbc.co.uk/science/horizon/2001/dinofooltrans.shtml On 2005-03-08 7:35:11, Brian Stansberry wrote: I was a little surprised myself, which is why I wanted to follow Ceki's good example and publish test cases that could easily be verified (or debunked) by others. -- Ceki Gülcü The complete log4j manual: http://www.qos.ch/log4j/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang]/[servlet] Doing some tickling
Sorry to jump in mid-conversation, but I have recently written a
DateRange class of my own.
I think it would be much simpler to make the class only operate on Date
objects, both in the constructor:
DateRange(Date d1, Date d2)
and in the methods to check if dates fall within the range:
contains(Date)
intersects(Date)
I find this easier than dealing with numerous ints for startHour,
startMinutes, endHour, endMinutes.
But again, I'm not 100% sure of the requirements.
If what I've described sounds good, perhaps I could upload it into
Bugzilla. Let me know.
Frank W. Zammetti wrote:
On Mon, March 7, 2005 2:21 am, Henri Yandell said:
Largely trying to avoid throwing it straight in as after many moons of
failing, I'm making a push to get 2.1 out :)
I can certainly appreciate that :)
On the larger ideas (DateRange class), I'd imagine an API of:
// DateRange might not extend the math.Range, but would mimic the API
DateRange range = new DateRange(date1, date2, Calendar.HOUR);
if(range.contains(new Date())) { .. }
Unsure. Maybe it'd be simpler with TimeRange being another range that
provides the kind of feature you want, ie) only based on the time of
day. That way the rather dodgy Calendar.HOUR bit can be thrown out.
To me, the part about mimicing the API makes some sense (so long as there
is an overload version that accepts a Calendar so that my use case is
handled too!). The part about extending math.Range (which I realize you
say you aren't sure about) I wouldn't like. It doesn't feel like it
really applies properly, a bit of a square peg in a round hole if you
will. I think the API is the part that really matters though.
I'm not entirely clear on why there are three parameters when constucting
the DateRange though... Seems like a range by definition should only
require two items, no? :)
Given the criteria above, at least an API of:
DateUtils.inRange(Date time, int startHours, int startMinutes, int
endHours, int endMinutes)
It's the 2,358 number I dislike :)
I can live with that :)
We tend to make the target the first parameter btw, but that's no
biggy. I also switched it to be a Date.
Also not a problem for me. However, I would think it would be better to
create another overloaded version to accept a Date rather than replacing
it. I still think there are cases where the base int-only version will
come in handy, and I'd hate to see if removed. I think all overloaded
versions callind on the int-only version is the most flexible model
anyway... I can't imagine an overloaded version I'd rally against :)
Another approach would be if we added a Time class to represent a time
value independent of the day. I'm not sure if Stephen did this in
JODA, but I suspect that it would be a simple enough addition. Maybe
we could extend java.util.Date so that it could still be used easily
in DateFormat/JDBC etc. Some issues with that, but might be usable
enough with them.
Not a bad thought, but I would make an argument that as an application
developer, I'm not sure I'd be thrilled with having to use something other
than JDK standard classes (even though, to me anyway, its a bit bizarre in
the first place to have to use a Date or Calendar when I'm just dealing
with times). I suppose as long as it was easy to get a Time instance
based off of any of these, i.e., Time t = new Time(calendar); Time t = new
Time(date); ... and so on... then I'd be happy with that. I could see
using that myself.
The String variants have the p/pm hardcoded, which will be a bit
limiting. It'd make things slower, but I presume you could use a
SimpleDateFormat here.
That's a good thought, I didn't think of doing it that way. Certainly, if
I could let the standard JDK classes handle the conversion, then cool.
Plus, it should be able to handle just about any format one throws at it,
so that's certainly worth doing. In any case, I can't imagine it would
effect performance any more than the current implementation probably does
:)
Frank
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang]/[servlet] Doing some tickling
My feeling is that this would lead to confusion... The code I proposed is
specifically for checking TIME ranges, but looking at your suggestion, I
can't tell if it would work in determing if an hour fell within a given
range. It might, but I can't tell from what you've posted here. It also,
in my particular use case, has to work when the range start time is on a
Monday and the range end time is on a Tuesday.
I think the object to ints that you and also Henri I think talked about is
valid, but note that you only supply a single int for range start and end,
you don't specify hours and minutes separately. It is this way because
that's exactly what you get if you do Calendar.get(Calendar.HOUR_OF_DAY;.
Henri already talked about adding a version to accept a Date, which I
think makes sense, as long as its an overloaded version, I certainly have
no objection.
Now, all that being said, I for one say post your class if something like
it doesn't already exist. Being able to determine if a date falls within
a given range is also a valuable function for sure. :)
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
On Tue, March 8, 2005 10:15 am, matthew.hawthorne said:
Sorry to jump in mid-conversation, but I have recently written a
DateRange class of my own.
I think it would be much simpler to make the class only operate on Date
objects, both in the constructor:
DateRange(Date d1, Date d2)
and in the methods to check if dates fall within the range:
contains(Date)
intersects(Date)
I find this easier than dealing with numerous ints for startHour,
startMinutes, endHour, endMinutes.
But again, I'm not 100% sure of the requirements.
If what I've described sounds good, perhaps I could upload it into
Bugzilla. Let me know.
Frank W. Zammetti wrote:
On Mon, March 7, 2005 2:21 am, Henri Yandell said:
Largely trying to avoid throwing it straight in as after many moons of
failing, I'm making a push to get 2.1 out :)
I can certainly appreciate that :)
On the larger ideas (DateRange class), I'd imagine an API of:
// DateRange might not extend the math.Range, but would mimic the API
DateRange range = new DateRange(date1, date2, Calendar.HOUR);
if(range.contains(new Date())) { .. }
Unsure. Maybe it'd be simpler with TimeRange being another range that
provides the kind of feature you want, ie) only based on the time of
day. That way the rather dodgy Calendar.HOUR bit can be thrown out.
To me, the part about mimicing the API makes some sense (so long as
there
is an overload version that accepts a Calendar so that my use case is
handled too!). The part about extending math.Range (which I realize you
say you aren't sure about) I wouldn't like. It doesn't feel like it
really applies properly, a bit of a square peg in a round hole if you
will. I think the API is the part that really matters though.
I'm not entirely clear on why there are three parameters when
constucting
the DateRange though... Seems like a range by definition should only
require two items, no? :)
Given the criteria above, at least an API of:
DateUtils.inRange(Date time, int startHours, int startMinutes, int
endHours, int endMinutes)
It's the 2,358 number I dislike :)
I can live with that :)
We tend to make the target the first parameter btw, but that's no
biggy. I also switched it to be a Date.
Also not a problem for me. However, I would think it would be better to
create another overloaded version to accept a Date rather than replacing
it. I still think there are cases where the base int-only version will
come in handy, and I'd hate to see if removed. I think all overloaded
versions callind on the int-only version is the most flexible model
anyway... I can't imagine an overloaded version I'd rally against :)
Another approach would be if we added a Time class to represent a time
value independent of the day. I'm not sure if Stephen did this in
JODA, but I suspect that it would be a simple enough addition. Maybe
we could extend java.util.Date so that it could still be used easily
in DateFormat/JDBC etc. Some issues with that, but might be usable
enough with them.
Not a bad thought, but I would make an argument that as an application
developer, I'm not sure I'd be thrilled with having to use something
other
than JDK standard classes (even though, to me anyway, its a bit bizarre
in
the first place to have to use a Date or Calendar when I'm just dealing
with times). I suppose as long as it was easy to get a Time instance
based off of any of these, i.e., Time t = new Time(calendar); Time t =
new
Time(date); ... and so on... then I'd be happy with that. I could see
using that myself.
The String variants have the p/pm hardcoded, which will be a bit
limiting. It'd make things slower, but I presume you could use a
SimpleDateFormat here.
That's a good thought, I didn't think of doing it that way. Certainly,
if
I could let the
RE: [VOTE] Release commons email 1.0
Okay...
I have fixed the NOTICE.txt in the jar at the top level not being in the
META-INF. However, I can't seem to get the NOTICE.txt in the top level
of either the src or binary distributions. The postGoal in commons
build here doesn't seem to run. No xdocs, no jars, no NOTICE.txt...:
postGoal name=dist:prepare-src-filesystem
j:set var=maven.dist.src.assembly.dir
value=${pom.getPluginContext('maven-dist-plugin').getVariable('maven.di
st.src.assembly.dir')} /
!-- Copy Files --
ant:copy todir=${maven.dist.src.assembly.dir}
ant:fileset dir=.
ant:include name=NOTICE.txt/
/ant:fileset
/ant:copy
!-- Copy Jars --
ant:copy todir=${maven.dist.src.assembly.dir}
ant:fileset dir=${maven.build.dir}
ant:include name=*.jar/
/ant:fileset
/ant:copy
!-- Copy XDocs --
ant:copy todir=${maven.dist.src.assembly.dir}/xdocs
ant:fileset dir=xdocs /
/ant:copy
/postGoal
To what extent is the NOTICE.txt a mandatory requriement? TO me, it
looks just like the LICENSE.txt...
And, in the interests of finally getting a release out, especially since
we have the required +1 votes, can I just add the file by hand? Icky, I
know, but...
Eric
-Original Message-
From: Phil Steitz [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 02, 2005 3:49 PM
To: Jakarta Commons Developers List
Subject: Re: [VOTE] Release commons email 1.0
+1 modulo the following nits:
* Binary distro includes NOTICE.txt in the jar (top level, should
probably be with LICENSE.txt in META-INF) but not in the top level
directory of the distribution.
* Source distro does not include NOTICE.txt
* Ant build.xml in source distro fails with MalformedURLException in get
deps. When I regenerated the build.xml using maven ant, the regenerated
build.xml worked. Could be build.xml is out of date?
* Make sure to update the repo link on the web site to point to svn.
Phil
robert burrell donkin wrote:
On Tue, 2005-03-01 at 06:58, Eric Pugh wrote:
[X] +1 Lets release commons-email, it's been too long!
[ ] 0 Commons-what? Not ready for release
[ ] -1 Don't release. I can't get dumbster (replace with your
reason) to work.
BTW i've checked the sums and signatures
- robert
-
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: [vfs] parsing uri
What does it does not work mean? That is, what is an example failure
case?
Good question.
Because it does work :)
All I can say to my defense is that my library management is a mess!
Therefore I decided to make the simplest possible class for testing
how file.toURI().toString()
It encodes all excluded characters (space, %, #, ...)
From reserved character it encodes (on my linux) only ? (question mark)
Then from unwise characters ({}|\\^[]`) it encodes all.
But maybe it is not necessary to know how it encodes because the
inverse operation can be done too.
new File(new URI(
(new File($%[EMAIL PROTECTED]|\\^[]`$)).toURI().toString()
)).getPath()
Returns $%[EMAIL PROTECTED]|\\^[]`$
Which is correct.
Once again all this confusion was produced because I have my
library management in state of flux and I have had bad experiences
with this issue in the past.
Also I remembered the bug about this encoding issue but this
really seems to work.
My java -version returns
1.4.2_06-b03
This might not work on 1.3 but I am not sure.
Like I said before, the URI encoding is schema specific,
so it should be done separately for different providers.
And it seems that for local files URI and File classes
could work as the codec.
Thanks binkley!
- rami
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vfs] parsing uri
Slight correction new File(new URI( (new File($%[EMAIL PROTECTED]|\\^[]`$)).toURI().toString() )).getPath() Returns $%[EMAIL PROTECTED]|\\^[]`$ Return value is $%[EMAIL PROTECTED]|\^[]`$ (Only one backslash) - rami - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vfs] parsing uri
Rami Ojares wrote: new File(new URI( (new File($%[EMAIL PROTECTED]|\\^[]`$)).toURI().toString() )).getPath() Returns $%[EMAIL PROTECTED]|\\^[]`$ Which is correct. Yikes! I want to hire you to do all my software testing. That is diabolical. Cheers, --binkley - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33912] New: - Evictor thread in GenericObjectPool has potential for deadlock
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=33912.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=33912
Summary: Evictor thread in GenericObjectPool has potential for
deadlock
Product: Commons
Version: unspecified
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: Dbcp
AssignedTo: commons-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]
The GenericObjectPool Evictor thread can potentially cause a deadlock between
its connection factory and java.sql.DriverManager. The deadlock occurs when the
Evictor thread is trying to make enough connections to bring the pool's idle
connections up to what's specified in minIdle, at the same time a connection is
being requested through DriverManager.getConnection(). See the attached stack
trace dump:
Found one Java-level deadlock:
=
Thread-0:
waiting to lock monitor 0x0809a994 (object 0x698c2b48, a java.lang.Class),
which is held by main
main:
waiting to lock monitor 0x0809aad4 (object 0x65df7030, a
org.apache.commons.dbcp.PoolableConnectionFactory),
which is held by Thread-0
Java stack information for the threads listed above:
===
Thread-0:
at java.sql.DriverManager.getConnection(DriverManager.java:158)
- waiting to lock 0x698c2b48 (a java.lang.Class)
at
org.apache.commons.dbcp.DriverManagerConnectionFactory.createConnection(DriverManagerConnectionFactory.java:48)
at
org.apache.commons.dbcp.PoolableConnectionFactory.makeObject(PoolableConnectionFactory.java:290)
- locked 0x65df7030 (a
org.apache.commons.dbcp.PoolableConnectionFactory)
at
org.apache.commons.pool.impl.GenericObjectPool.addObject(GenericObjectPool.java:996)
at
org.apache.commons.pool.impl.GenericObjectPool.ensureMinIdle(GenericObjectPool.java:978)
at
org.apache.commons.pool.impl.GenericObjectPool.access$000(GenericObjectPool.java:124)
at
org.apache.commons.pool.impl.GenericObjectPool$Evictor.run(GenericObjectPool.java:1090)
at java.lang.Thread.run(Thread.java:595)
main:
at
org.apache.commons.dbcp.PoolableConnectionFactory.makeObject(PoolableConnectionFactory.java:290)
- waiting to lock 0x65df7030 (a
org.apache.commons.dbcp.PoolableConnectionFactory)
at
org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:771)
at org.apache.commons.dbcp.PoolingDriver.connect(PoolingDriver.java:175)
at java.sql.DriverManager.getConnection(DriverManager.java:525)
- locked 0x698c2b48 (a java.lang.Class)
at java.sql.DriverManager.getConnection(DriverManager.java:193)
- locked 0x698c2b48 (a java.lang.Class)
at Deadlock.main(Deadlock.java:83)
Found 1 deadlock.
The deadlock occurs when GenericObjectPool.addObject() calls synchronized method
PoolableConnectionFactory.makeObject(), meanwhile static synchronized
DriverManager.getConnection() is called. makeObject() waits for the lock on
DriverManager to be released, whereas DriverManager waits for the lock on the
PoolableConnectionFactory instance to be released.
The Java program below, based on ManualPoolingDriverExample.java provided with
DBCP, duplicates the deadlock for me within several seconds of being run:
import java.sql.*;
import org.apache.commons.pool.*;
import org.apache.commons.pool.impl.*;
import org.apache.commons.dbcp.*;
/**
* Duplicate DBCP pool deadlocking.
*
* Compile with:
* /usr/java/jdk1.5.0/bin/javac
* -classpath
commons-collections.jar:commons-dbcp-1.2.1.jar:commons-pool-1.2.jar
* Deadlock.java
*
* Run with:
* /usr/java/jdk1.5.0/bin/java
* -classpath
commons-collections.jar:commons-dbcp-1.2.1.jar:commons-pool-1.2.jar:ojdbc14.jar:xerces.jar:.
* Deadlock
*
* Locks still occur when compiled and run with J2SDK 1.4.1_03.
*/
public class Deadlock {
private static final int ACTIVE = 10;
private static void init() {
System.out.println(Loading drivers);
try {
Class.forName(oracle.jdbc.driver.OracleDriver);
Class.forName(org.apache.commons.dbcp.PoolingDriver);
} catch (ClassNotFoundException e) {
e.printStackTrace();
}
System.out.println(Setting up pool);
try {
GenericObjectPool.Config config = new
GenericObjectPool.Config();
config.maxActive = ACTIVE;
config.minIdle = 2; // Idle limits are low to allow more
possibility
Re: [httpclient]contrib
On Mon, 2005-03-07 at 19:07 -0400, Derek Lohnes wrote: I was looking for a jar containing the contrib classes for SSL. Can some tell me what the intention is for this stuff will it be packaged as part of the distribution? Hi Derek, We may eventually consider moving the AuthSSLProtocolSocketFactory http://svn.apache.org/viewcvs.cgi/jakarta/commons/proper/httpclient/trunk/src/contrib/org/apache/commons/httpclient/contrib/ssl/AuthSSLProtocolSocketFactory.java?view=markup to HttpClient proper. As to the rest of SSL socket factories in the SSL contrib package, they usually implement a security short-cut or based upon an assumption which may be too application specific and therefore are considered unsafe for general use without a thorough review and modification. If you want to use it do you need to check it out of CVS and build it yourself? This is precisely what we encourage people to do: get the source code, review it carefully, make system specific adjustments. Oleg Thanks Derek - 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]
[pipeline] To-do list
Hi, Abhilash,
Thanks! I'm sorry that it's taken me so long to get back to you on this
. I believe that Craig had generated the build.xml file from the maven
project file (since he uses ant for the nightlies) and had just
committed whatever was generated for him.
As far as a to-do list goes, I'm currently working on trying to
implement a set of graceful failure modes for pipeline stages. I've
toyed around with a few different ideas on how to go about doing this,
but I'd be grateful for any input you might have. A few failure cases
that I need to solve are listed below:
1) Failure of a downstream dependency: If the preprocess() method of a
given stage fails, cause one or more upstream stages to terminate execution.
2) Failure of an upstream stage where a downstream stage is blocked
waiting on an event that the upstream stage might generate. It's
currently possible to deadlock the pipeline if this happens, so I need
to come up with some set of configurable conditions under which it's
allowable to interrupt the blocked stage.
3) Stateful suspend and resume. This is a big task that needs a lot of
thought - how to serialize the pipeline state so that it's possible to
resume processing after a failure. Obviously whatever decisions are made
here will make a difference in how stages are implemented, so we may
simply want to specify a Resumable interface that the stages can
optionally implement and leave it up to the implementer to handle
suspension and resumption. At very least, we should probably provide
utility methods for serializing and deserializing a stage's queue.
Another concept that I've started playing around with is a router
stage that can route data onto different pipeline branches using a
chain-of-responsibility for the decision-making process.
Kris
Abhilash Koneri wrote:
Kris,
Thanks for the info. I downloaded the source and compiled it. I have a
fair idea now on the source and would be interested in contributing.
Do you have a to-do list for further development?
The build.xml was not generic enough. It had reference to specific
directories that did not enable anyone to build out-of-the-box (ex.
/home/craigmcc/). I have cleaned it up a bit. Also, I added a
maven-get task to obtain a dependent library -
get dest=${libdir}/commons-collections-3.1.jar usetimestamp=true
ignoreerrors=true
src=http://www.ibiblio.org/maven/commons-collections/jars/commons-collections-3.1.jar;
Attached is the version I now use. Hope it helps.
Abhilash
On Fri, 04 Feb 2005 09:34:29 -0700, Kris Nuttycombe
[EMAIL PROTECTED] wrote:
Hi, Abhilash,
I'm the main developer of the pipeline, so I can help you out. The
javadocs have been broken for some time and I haven't been able to get
anyone with permission to update the website to fix the link, so I've
attached a tarball of the docs to this email.
The source code is available from both CVS and Subversion (there are no
releases as yet.) You can get access starting here:
http://jakarta.apache.org/site/cvsindex.html
Hope this helps! Any comments or contributions are greatly appreciated!
Kris
Abhilash Koneri wrote:
Hi,
I came accross the pipeline component on the webpage at jakarta -
http://jakarta.apache.org/commons/sandbox/pipeline/ . However, I was
not able to find the downloads or the java doc pages. I am very
interesting in this compnent. I am a java developer and would like to
help if possible. Could you point me to some documentation / source
code for this component?
Thanks much.
Abhilash Koneri
(http://www.angelfire.com/or/abhilash/site/index.html)
--
=
Kris Nuttycombe
Associate Scientist
Geospatial Data Services Group
CIRES, National Geophysical Data Center/NOAA
(303) 497-6337
[EMAIL PROTECTED]
=
?xml version=1.0 encoding=UTF-8?
!--build.xml generated by maven from project.xml version 0.0.1
on date October 2 2004, time 1145--
project default=jar name=commons-pipeline basedir=.
property name=defaulttargetdir value=target
/property
property name=libdir value=${defaulttargetdir}/lib
/property
property name=classesdir value=${defaulttargetdir}/classes
/property
property name=testclassesdir value=${defaulttargetdir}/test-classes
/property
property name=distdir value=dist
/property
property name=javadocdir value=dist/docs/api
/property
property name=final.name value=commons-pipeline-0.0.1
/property
target name=init description=o Initializes some properties
mkdir dir=${libdir}
/mkdir
condition property=noget
equals arg2=only arg1=${build.sysclasspath}
/equals
/condition
/target
target name=compile description=o Compile the code depends=get-deps
mkdir dir=${classesdir}
/mkdir
javac destdir=${classesdir} deprecation=true debug=true optimize=false
excludes=**/package.html
src
pathelement
Re: [lang]/[servlet] Doing some tickling
Frank W. Zammetti wrote:
My feeling is that this would lead to confusion... The code I proposed is
specifically for checking TIME ranges, but looking at your suggestion, I
can't tell if it would work in determing if an hour fell within a given
range. It might, but I can't tell from what you've posted here. It also,
in my particular use case, has to work when the range start time is on a
Monday and the range end time is on a Tuesday.
I'm fairly sure that it would.
My 'contains' method looks something like this:
public boolean contains(Date d) {
return this.startDate.before(d) this.endDate.after(d);
}
with 'startDate' and 'endDate' being the 2 dates that are passed into
the DateRange(Date, Date) constructor.
I think the object to ints that you and also Henri I think talked about is
valid, but note that you only supply a single int for range start and end,
you don't specify hours and minutes separately. It is this way because
that's exactly what you get if you do Calendar.get(Calendar.HOUR_OF_DAY;.
Henri already talked about adding a version to accept a Date, which I
think makes sense, as long as its an overloaded version, I certainly have
no objection.
I can't claim that I completely follow you here -- but I think I get the
fundamental point.
I can appreciate your desire to only provide hours and minutes, if that
is all that you care about. Part of the problem is that Java only deals
with dates in the full context: year, month, day, hour, seconds, etc.
So, stripping some of that information away may make the calculations a
bit trickier.
I like the idea of the 'TimeRange' object that was mentioned earlier.
I think that may make the simple hour second calculations easier to
deal with.
However, I think this would suffice only if the comparison takes place
within a single day. Once the calculation spreads across multiple days,
I think it would be better assisted with Date objects, to give it the
additional context.
If the difference in 2 Dates is required, then it may also be nice to
create a simple class that can convert milliseconds (from
Date.getTime()) into more useful units, like seconds, hours, days, etc.
I understand that this is simple math, but it can also be repetitive,
so it may be worth thinking about.
Again, this depends on the requirements. I may be going off on some
weird tangents here.
Now, all that being said, I for one say post your class if something like
it doesn't already exist. Being able to determine if a date falls within
a given range is also a valuable function for sure. :)
OK, sounds good. I'll try to clean it up and post it to Bugzilla when I
get a chance.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] 1.0.5: WeakHashtable
On Tue, 2005-03-08 at 06:41, Simon Kitching wrote:
Hi,
Here are a few comments on logging-1.0.5-alpha1. More to come..
great
many thanks
===
Should the WeakHashtable class be rolled into commons-logging.jar?
It seems easier for users than remembering to deploy the extra jar, and
should be feasable by having something like this in
Hashtable foo;
String version = System.getProperty(java.vm.specification.version);
if (versionLessThan(version, 1.3)) {
foo = new Hashtable();
} else {
// use reflection to create instance
foo = createWeakHashtable();
}
Or is the reason for having it separate because there is a performance
hit when using it? If that is so, then file guide.xml should document
that rather than saying always deploy it when using java 1.3 or later.
there may be some performance hit but this should only really happen the
first time that a Log is obtained for a new classloader. i doubt that
there will be significant real world performance degradation by using
this jar. be nice to have some figures, though.
there were two main reasons why it was issued as an optional jar:
1. JCL has always tried hard to be compatible with early JVMs
2. backwards compatibility is very important
the memory problem is only likely to manifest when frequently hot
deploying in certain containers. i'm a little reluctant to use system
property version numbers (since they haven't always been very reliable)
and prefer to give users the explicit choice as to whether they risk
using the new code or not.
however, maybe it would be a reasonable tradeoff in this case and i
would be willing to be convinced. (i tend to be very conservation when
maintaining components with large installation bases).
opinions anyone?
===
The current javadoc for the WeakHashtable class doesn't include a
description of the general problem it's trying to solve (though this is
well described in the guide.xml).
I found it rather difficult to understand the description of the
remaining issue that this class still doesn't handle.
i'm quite fond of the precision of the existing description. however, i
take your point.
So attached is a proposed patch to the javadoc for the WeakHashtable
class.
i think i'll probably try to pull something together containing the best
of both. i suppose that the user guide will also need updating...
BTW, is there a maven command that will actually generate the javadoc
for the optional classes?
it should be possible to get the reactor to work but i've never really
had any success using the maven reactor. (probably need to sit down for
half a day or so and really get to grips with it.) if you anyone can
find the cycles, then i'd be happy to see the maven build improved :)
FYI simon: the usually commons process for karma for additional
components for existing committers is just to ask
- robert
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang]/[servlet] Doing some tickling
On Tue, March 8, 2005 3:45 pm, matthew.hawthorne said:
I'm fairly sure that it would.
My 'contains' method looks something like this:
public boolean contains(Date d) {
return this.startDate.before(d) this.endDate.after(d);
As long as before() and after() are inclusive, then logically at least I
agree, that should work.
I can't claim that I completely follow you here -- but I think I get the
fundamental point.
That's OK, I don't follow *myself* half the time :)
I can appreciate your desire to only provide hours and minutes, if that
is all that you care about. Part of the problem is that Java only deals
with dates in the full context: year, month, day, hour, seconds, etc.
So, stripping some of that information away may make the calculations a
bit trickier.
To me it makes it *easier*... The original use case that caused me to
write the function was that I have a webapp that sense text messages to
another system throughout the day. Problem is, that remote system isn't
available from 10am to 6pm. So, I needed at any point in time to be able
to check if the current time fell within that range.
As is the standard in this app, the current time is gotten with:
GregorianCalendar now = new GregorianCalendar();
Now, maybe there is a good argument to be made that doing that isn't the
best idea in the first place, but its what is throughout the codebase, so
it is what it is :) Anyway... having a Calendar object, just calling:
now.get(Calendar.HOUR_OF_DAY);
...gets me an int that is a 24-hour time, so 0-2359. Doing the range
check is just a number comparison at that point, hence the reason I took
that approach.
I'm not arguing that it's the best approach or anything, just giving the
rationale for the way I wrote the code :)
I like the idea of the 'TimeRange' object that was mentioned earlier.
I think that may make the simple hour second calculations easier to
deal with.
I agree too, as I think I did when it was mentioned. My only point about
it was that I'd like to be able to pass it a Calendar or even an int to
construct it, so that I just wrap what I now have in a TimeRange and off I
go. I'm a believer in providing as many overloaded versions of
utility-type functions and class constructors as possible so that as a
developer I have an easy time getting from one type to another.
However, I think this would suffice only if the comparison takes place
within a single day. Once the calculation spreads across multiple days,
I think it would be better assisted with Date objects, to give it the
additional context.
That's a fair point, however, you may not always know when a comparison is
going to span days, as is the case for me... even though I know the range
spans midnight because its in my webapp config file, the range could
change down the road and not span midnight. Certainly I don't want to
change code to accomodate the range change, and I shouldn't have to.
Whatever function I use to do the check should be smart enough to work
either way. If the snippet you posted here in fact does do that, then I'm
OK with it, again, as long as I can construct a Date off a Calendar so I
don't have to change a lot of existing code. :)
If the difference in 2 Dates is required, then it may also be nice to
create a simple class that can convert milliseconds (from
Date.getTime()) into more useful units, like seconds, hours, days, etc.
I understand that this is simple math, but it can also be repetitive,
so it may be worth thinking about.
Nice suggestion... so nice in fact that I'd have a hard time believing
it's not out there already :)
Again, this depends on the requirements. I may be going off on some
weird tangents here.
Tangents? With me?!? No way! ;) (I'm known, I think, for wild tangents!)
Now, all that being said, I for one say post your class if something
like
it doesn't already exist. Being able to determine if a date falls
within
a given range is also a valuable function for sure. :)
OK, sounds good. I'll try to clean it up and post it to Bugzilla when I
get a chance.
Excellent! :)
Frank
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] distribution packaging
On Tue, 2005-03-08 at 07:35, Brian Stansberry wrote: --- robert burrell donkin [EMAIL PROTECTED] wrote: snip i'd definitely be willing to review patches if someone wants to volunteer to alter the build, create some good test cases and write up some documentation. I'd be happy to take that on if a consensus is reached that repackaging is the way to go. i think that repackaging might be the way to go for the future of the 1.0.x series of JCL releases. i also think that anything that can improve this series is definitely worth doing. it has the great advantage of being fully compatible. opinions anyone? Might take me a bit of time though, as I'm fairly swamped. understood :) - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release commons email 1.0
From: Eric Pugh [EMAIL PROTECTED] To what extent is the NOTICE.txt a mandatory requriement? TO me, it looks just like the LICENSE.txt... The NOTICE.txt is the thing that specifies the Apache name. It is essential, and all releases must contain it in every jar, plus the top level of the src and bin zips. And, in the interests of finally getting a release out, especially since we have the required +1 votes, can I just add the file by hand? Icky, I know, but... As this is a 1.0, personally I'd prefer to see a clean (re)vote and release. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] distribution packaging
On Tue, 2005-03-08 at 14:39, Ceki Gülcü wrote: Brian, From a cursory look at your document, I have to *speculate* that the changes you describe do not solve the core flaws in JCL but merely hide them by falling back on java.util.logging. However, I am only *speculating* as I have not had a chance to study your document with the care that it deserves. IMHO speculation often proves damaging brian's document gives a honest assessment of the impact of the changes. that's very valuable in itself. After careful study of JCL, I am convinced that JCL is broken beyond hope. While its interfaces can be salvaged, its implementation must be thrown away entirely. While this opinion is not popular around here, it is based on verifiable facts, not wishful thinking that does not survive critical scrutiny. LOL! it's a little ironic that both richard and i have held that opinion for a long while now. however, ceki's and brian's investigations are now starting to persuade me that there is actually some hope for much improved discovery from the 1.0.x series of releases. there are a number of subtle issues (well, they seem subtle to me) about salvaging the interfaces. it's more difficult that it should be. not being able to fix them easily is what i have always regarded as the JCL fatal flaw. i think that there are ways to maintain backwards compatibility which should also allow the interfaces to be salvaged for reuse by different implementations. i was working on code along these lines but i only have so much energy and most of it (over the last few weeks) has been taken up replying to ceki's posts and analysing ceki's examples (or so it seems to me). I was very surprised to discover that several voting participants in JCL are more concerned about covering their political asses rather than verifiable facts. Until this day, JCL developers have not acknowledged the fatal flaws in their software. The talk always has been about corner cases even if the problems faced by users are frequent and manifestly major. The JCL wiki still qualifies my past analysis as FUD [1]. oh come on ceki! if you didn't choose to use such intemperate language, you would not precipitate such a strong reaction. it seems to me that your comments are aimed at one particular individual who hasn't been able to find much jakarta commons time in recent months. a flamewar requires two to prosper. if i'm wrong about this, then it would be more effective to name the targets of your displeasure. to some, having to place a jar in a particular classloader to ensure that JCL autodiscovery works is a fatal flaw. others will say this limitation is a corner case. personally, i'm not convinced that arguing symantics really gets anyone anywhere. it certainly doesn't get software coded... - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33912] - [dbcp] Evictor thread in GenericObjectPool has potential for deadlock
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33912. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33912 [EMAIL PROTECTED] changed: What|Removed |Added OS/Version|Linux |All Platform|PC |All Summary|Evictor thread in |[dbcp] Evictor thread in |GenericObjectPool has |GenericObjectPool has |potential for deadlock |potential for deadlock -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r156579 - in jakarta/commons/proper/feedparser/trunk/src/java/org/apache/commons/feedparser: AtomFeedParser.java BaseParser.java RSSFeedParser.java
Author: burton
Date: Tue Mar 8 15:05:22 2005
New Revision: 156579
URL: http://svn.apache.org/viewcvs?view=revrev=156579
Log:
Fixed bug with doLocale passing in a null element...
Modified:
jakarta/commons/proper/feedparser/trunk/src/java/org/apache/commons/feedparser/AtomFeedParser.java
jakarta/commons/proper/feedparser/trunk/src/java/org/apache/commons/feedparser/BaseParser.java
jakarta/commons/proper/feedparser/trunk/src/java/org/apache/commons/feedparser/RSSFeedParser.java
Modified:
jakarta/commons/proper/feedparser/trunk/src/java/org/apache/commons/feedparser/AtomFeedParser.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/feedparser/trunk/src/java/org/apache/commons/feedparser/AtomFeedParser.java?view=diffr1=156578r2=156579
==
---
jakarta/commons/proper/feedparser/trunk/src/java/org/apache/commons/feedparser/AtomFeedParser.java
(original)
+++
jakarta/commons/proper/feedparser/trunk/src/java/org/apache/commons/feedparser/AtomFeedParser.java
Tue Mar 8 15:05:22 2005
@@ -306,6 +306,10 @@
*/
private static String getXMLOfContent( List content ) {
+//NOTE: Fri Mar 04 2005 03:59 PM ([EMAIL PROTECTED]): in my profiling I
+//found that this is a BIG memory allocater. FIXME: We SHOULD be able
+//to do the same thing we do for xhtml:body RIGHT?
+
StringBuffer buff = new StringBuffer( 1 );
XMLOutputter outputter = new XMLOutputter( , true );
Modified:
jakarta/commons/proper/feedparser/trunk/src/java/org/apache/commons/feedparser/BaseParser.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/feedparser/trunk/src/java/org/apache/commons/feedparser/BaseParser.java?view=diffr1=156578r2=156579
==
---
jakarta/commons/proper/feedparser/trunk/src/java/org/apache/commons/feedparser/BaseParser.java
(original)
+++
jakarta/commons/proper/feedparser/trunk/src/java/org/apache/commons/feedparser/BaseParser.java
Tue Mar 8 15:05:22 2005
@@ -45,7 +45,10 @@
protected static void doLocale( FeedParserState state,
FeedParserListener listener,
Element element ) throws Exception {
-
+
+if ( element == null )
+return;
+
if ( state.metaFeedParserlistener == null )
return;
@@ -66,6 +69,9 @@
FeedParserListener listener,
Element element )
throws Exception {
+
+if ( element == null )
+return;
if ( state.metaFeedParserlistener == null )
return;
Modified:
jakarta/commons/proper/feedparser/trunk/src/java/org/apache/commons/feedparser/RSSFeedParser.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/feedparser/trunk/src/java/org/apache/commons/feedparser/RSSFeedParser.java?view=diffr1=156578r2=156579
==
---
jakarta/commons/proper/feedparser/trunk/src/java/org/apache/commons/feedparser/RSSFeedParser.java
(original)
+++
jakarta/commons/proper/feedparser/trunk/src/java/org/apache/commons/feedparser/RSSFeedParser.java
Tue Mar 8 15:05:22 2005
@@ -63,6 +63,7 @@
XPath xpath = new XPath( /descendant::*[local-name() = 'channel'] );
Element channel = (Element)xpath.selectSingleNode( doc );
state.current = channel;
+
doLocale( state, listener, channel );
doChannel( listener, state );
doLocaleEnd( state, listener, channel );
@@ -213,6 +214,9 @@
if ( encoded != null ) {
+//FIXME: move to the onContent API defined within the
+//AtomFeedParser and deprecated this body handling.
+
mcpl.onContentEncoded( new FeedParserState( encoded ),
encoded.getText() );
@@ -230,6 +234,9 @@
.getChild( item, NS.CONTENT )
.getChild( value, NS.RDF );
+//FIXME: move to the onContent API defined within the
+//AtomFeedParser and deprecated this body handling.
+
mcpl.onContentItem( new FeedParserState( value ),
null,
null,
@@ -251,6 +258,9 @@
Element body = state.current.getChild( body, NS.XHTML );
+//FIXME: move to the onContent API defined within the
AtomFeedParser
+//and deprecated this body handling.
+
if ( body != null ) {
xfp.onXHTMLBody( new FeedParserState( body ),
body );
svn commit: r156585 - in jakarta/commons/sandbox/benchmark/trunk: project.xml src/java/org/apache/commons/benchmark/xmlrpc/BenchmarkHandler.java xdocs/index.xml
Author: burton
Date: Tue Mar 8 15:25:39 2005
New Revision: 156585
URL: http://svn.apache.org/viewcvs?view=revrev=156585
Log:
0.0.4... xmlrpc refactor
Modified:
jakarta/commons/sandbox/benchmark/trunk/project.xml
jakarta/commons/sandbox/benchmark/trunk/src/java/org/apache/commons/benchmark/xmlrpc/BenchmarkHandler.java
jakarta/commons/sandbox/benchmark/trunk/xdocs/index.xml
Modified: jakarta/commons/sandbox/benchmark/trunk/project.xml
URL:
http://svn.apache.org/viewcvs/jakarta/commons/sandbox/benchmark/trunk/project.xml?view=diffr1=156584r2=156585
==
--- jakarta/commons/sandbox/benchmark/trunk/project.xml (original)
+++ jakarta/commons/sandbox/benchmark/trunk/project.xml Tue Mar 8 15:25:39 2005
@@ -15,7 +15,7 @@
descriptionJakarta Benchmark/description
-currentVersion0.0.3/currentVersion
+currentVersion0.0.4/currentVersion
packageorg.apache.commons.benchmark/package
Modified:
jakarta/commons/sandbox/benchmark/trunk/src/java/org/apache/commons/benchmark/xmlrpc/BenchmarkHandler.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/sandbox/benchmark/trunk/src/java/org/apache/commons/benchmark/xmlrpc/BenchmarkHandler.java?view=diffr1=156584r2=156585
==
---
jakarta/commons/sandbox/benchmark/trunk/src/java/org/apache/commons/benchmark/xmlrpc/BenchmarkHandler.java
(original)
+++
jakarta/commons/sandbox/benchmark/trunk/src/java/org/apache/commons/benchmark/xmlrpc/BenchmarkHandler.java
Tue Mar 8 15:25:39 2005
@@ -29,16 +29,29 @@
* @version $Id: BenchmarkHandler.java,v 1.5 2005/03/04 00:31:08 burton Exp $
*/
public class BenchmarkHandler {
+
+//FIXME: I think this needs to be refactored due to the getTracker1() code.
+//I should be able to specify time here.
-public Double getLastStarted( String name, int interval ) {
+public Double getLastStarted( String name ) {
return new Double( Benchmark.getBenchmark( name )
.getTracker1().getLast().getStarted() );
}
-public Double getLastCompleted( String name, int interval ) {
+public Double getLastCompleted( String name ) {
return new Double( Benchmark.getBenchmark( name )
.getTracker1().getLast().getCompleted() );
+}
+
+public Double getLastDuration( String name ) {
+return new Double( Benchmark.getBenchmark( name )
+ .getTracker1().getLast().getDuration() );
+}
+
+public Double getLastMeanDuration( String name ) {
+return new Double( Benchmark.getBenchmark( name )
+ .getTracker1().getLast().getMeanDuration() );
}
}
Modified: jakarta/commons/sandbox/benchmark/trunk/xdocs/index.xml
URL:
http://svn.apache.org/viewcvs/jakarta/commons/sandbox/benchmark/trunk/xdocs/index.xml?view=diffr1=156584r2=156585
==
--- jakarta/commons/sandbox/benchmark/trunk/xdocs/index.xml (original)
+++ jakarta/commons/sandbox/benchmark/trunk/xdocs/index.xml Tue Mar 8 15:25:39
2005
@@ -24,7 +24,43 @@
developers can write frontends to monitor application
performance.
/p
-
+
+p
+Of course one approach is to use a Java profiler (and many
+exist) but profilers suffer a number of fatal problems:
+/p
+
+dl
+
+dtSlow/dt
+
+dd
+Most java profilers are slow due to profiling of ALL method
+calls or allocation points. This is a fatal flaw of their
+design not their implementation. Since they don't know
what
+they're looking for they essentially have to look for
+everything..
+
+/dd
+
+dtRequire a LOT of memory/dt
+
+dtCrash/dt
+
+dtNot always enabled/dt
+
+dd
+Benchmarks are designed to run in qalways on/q mode
+where collection of performance data has a negligible
impact
+on the VM. Most profilers on the other hand are not
+designed to do this and often cause significant resource
+restraints.
+/dd
+
+dtProprietary/dt
+
+/ol
+
p
Infrasture code such as rrdtool, ganglia, and jrobin, provide
the foundation to view the data and commons benchmarks provides
@@ -177,6 +213,72 @@
gmetric script. Slight configuration is required in order to
specify the multicast channel, port, cluster name, ec.
/p
+
+/section
+
+
svn commit: r156586 - in jakarta/commons/sandbox/benchmark/trunk: project.xml src/java/org/apache/commons/benchmark/Benchmark.java src/test/org/apache/commons/benchmark/Test1.java
Author: burton
Date: Tue Mar 8 16:09:49 2005
New Revision: 156586
URL: http://svn.apache.org/viewcvs?view=revrev=156586
Log:
refactored test to use clear instad of reset... tests for xmlrpc daemon support
Modified:
jakarta/commons/sandbox/benchmark/trunk/project.xml
jakarta/commons/sandbox/benchmark/trunk/src/java/org/apache/commons/benchmark/Benchmark.java
jakarta/commons/sandbox/benchmark/trunk/src/test/org/apache/commons/benchmark/Test1.java
Modified: jakarta/commons/sandbox/benchmark/trunk/project.xml
URL:
http://svn.apache.org/viewcvs/jakarta/commons/sandbox/benchmark/trunk/project.xml?view=diffr1=156585r2=156586
==
--- jakarta/commons/sandbox/benchmark/trunk/project.xml (original)
+++ jakarta/commons/sandbox/benchmark/trunk/project.xml Tue Mar 8 16:09:49 2005
@@ -61,6 +61,11 @@
version1.7.0/version
/dependency
+dependency
+idxmlrpc/id
+version1.2-b1/version
+/dependency
+
dependencyidjrobin/idversion1.4.0/version/dependency
!-- these two are required by maven --
Modified:
jakarta/commons/sandbox/benchmark/trunk/src/java/org/apache/commons/benchmark/Benchmark.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/sandbox/benchmark/trunk/src/java/org/apache/commons/benchmark/Benchmark.java?view=diffr1=156585r2=156586
==
---
jakarta/commons/sandbox/benchmark/trunk/src/java/org/apache/commons/benchmark/Benchmark.java
(original)
+++
jakarta/commons/sandbox/benchmark/trunk/src/java/org/apache/commons/benchmark/Benchmark.java
Tue Mar 8 16:09:49 2005
@@ -124,7 +124,7 @@
this.name = name;
-reset();
+clear();
}
@@ -133,7 +133,7 @@
*
* @author a href=mailto:[EMAIL PROTECTED]Kevin A. Burton/a
*/
-void reset() {
+void clear() {
tracker1 = new BenchmarkTracker( INTERVAL_1, this );
tracker5 = new BenchmarkTracker( INTERVAL_5, this );
@@ -146,7 +146,7 @@
/**
* Get the tracker for this benchmark which includes all metadata related
to
* this benchmark including total completed/started and current values.
- *
+ *
*/
public BenchmarkTracker getTracker() {
return getTracker1();
Modified:
jakarta/commons/sandbox/benchmark/trunk/src/test/org/apache/commons/benchmark/Test1.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/sandbox/benchmark/trunk/src/test/org/apache/commons/benchmark/Test1.java?view=diffr1=156585r2=156586
==
---
jakarta/commons/sandbox/benchmark/trunk/src/test/org/apache/commons/benchmark/Test1.java
(original)
+++
jakarta/commons/sandbox/benchmark/trunk/src/test/org/apache/commons/benchmark/Test1.java
Tue Mar 8 16:09:49 2005
@@ -16,6 +16,11 @@
package org.apache.commons.benchmark;
+import org.apache.commons.benchmark.*;
+import org.apache.commons.benchmark.xmlrpc.*;
+
+import org.apache.xmlrpc.*;
+
import junit.framework.*;
import java.util.*;
@@ -30,6 +35,50 @@
//FIXME: test with using really short intervals but with diff values.
+public void testXmlrpc() throws Exception {
+
+WebServer webserver = new WebServer ( 2048 );
+
+webserver.addHandler( benchmark,
+ new BenchmarkHandler() );
+
+// deny all clients
+webserver.setParanoid ( true );
+// allow local access
+webserver.acceptClient ( 10.*.*.* );
+webserver.acceptClient ( 127.*.*.* );
+
+webserver.start();
+
+Thread.sleep( 100 );
+
+//create a faux benchmark
+
+Benchmark b = Benchmark.getBenchmark( foo );
+b.start();
+b.complete();
+
+assertEquals( 1, b.getTracker1().now.completed );
+
+b.getTracker1().reset( System.currentTimeMillis() );
+
+//FIXME: this isn't working.
+assertEquals( 0, b.getTracker1().now.completed );
+assertEquals( 1, b.getTracker1().last.completed );
+
+String router = http://localhost:2048/RPC2;;
+
+XmlRpcClient xmlrpc = new XmlRpcClient ( router );
+
+Vector params = new Vector ();
+params.add( foo );
+
+Object result = xmlrpc.execute ( benchmark.getLastCompleted, params
);
+
+assertEquals( new Double( 1 ), result );
+
+}
+
public void testDuration() throws Exception {
Benchmark.DISABLE_LOCAL = false;
@@ -59,7 +108,7 @@
assertTrue( 100 meanDuration );
assertTrue( 200 meanDuration );
-benchmark.reset();
+benchmark.clear();
}
@@ -91,7 +140,7 @@
assertEquals( 0, benchmark.getTracker1().now.getCompleted() );
assertEquals( 0, benchmark.getTracker1().now.getDuration() );
-benchmark.reset();
+
svn commit: r156588 - in jakarta/commons/sandbox/servlet/trunk: build.properties.sample build.xml src/java/org/apache/commons/servlet/RequestUtils.java src/java/org/apache/commons/servlet/SessionUtils.java
Author: bayard
Date: Tue Mar 8 16:51:49 2005
New Revision: 156588
URL: http://svn.apache.org/viewcvs?view=revrev=156588
Log:
fixed the build (somewhat, still need to edit buld.properties.sample), added
the new ideas from Frank Zammetti (Bugzilla: #33676) and fixed the existing
code so it actually compiles.
Added:
jakarta/commons/sandbox/servlet/trunk/src/java/org/apache/commons/servlet/SessionUtils.java
Modified:
jakarta/commons/sandbox/servlet/trunk/build.properties.sample
jakarta/commons/sandbox/servlet/trunk/build.xml
jakarta/commons/sandbox/servlet/trunk/src/java/org/apache/commons/servlet/RequestUtils.java
Modified: jakarta/commons/sandbox/servlet/trunk/build.properties.sample
URL:
http://svn.apache.org/viewcvs/jakarta/commons/sandbox/servlet/trunk/build.properties.sample?view=diffr1=156587r2=156588
==
--- jakarta/commons/sandbox/servlet/trunk/build.properties.sample (original)
+++ jakarta/commons/sandbox/servlet/trunk/build.properties.sample Tue Mar 8
16:51:49 2005
@@ -4,3 +4,5 @@
# The pathname of the junit.jar JAR file
junit.jar = ${junit.home}/junit.jar
+
+servlet.jar=${user.home}/.maven/repository/servletapi/jars/servletapi-2.2.jar
Modified: jakarta/commons/sandbox/servlet/trunk/build.xml
URL:
http://svn.apache.org/viewcvs/jakarta/commons/sandbox/servlet/trunk/build.xml?view=diffr1=156587r2=156588
==
--- jakarta/commons/sandbox/servlet/trunk/build.xml (original)
+++ jakarta/commons/sandbox/servlet/trunk/build.xml Tue Mar 8 16:51:49 2005
@@ -76,6 +76,7 @@
!-- Construct compile classpath --
path id=compile.classpath
pathelement location=${build.home}/classes/
+pathelement location=${servlet.jar}/
/path
Modified:
jakarta/commons/sandbox/servlet/trunk/src/java/org/apache/commons/servlet/RequestUtils.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/sandbox/servlet/trunk/src/java/org/apache/commons/servlet/RequestUtils.java?view=diffr1=156587r2=156588
==
---
jakarta/commons/sandbox/servlet/trunk/src/java/org/apache/commons/servlet/RequestUtils.java
(original)
+++
jakarta/commons/sandbox/servlet/trunk/src/java/org/apache/commons/servlet/RequestUtils.java
Tue Mar 8 16:51:49 2005
@@ -18,13 +18,16 @@
import javax.servlet.http.HttpServletRequest;
-import org.apache.commons.lang.Strings;
+
+import java.util.Enumeration;
+import java.util.HashMap;
/**
* This class provides utilities for getting information from
* javax.servlet.http.HttpServletRequest.
*
* @author a href=mailto:[EMAIL PROTECTED]Lance Lavandowska/a
+ * @author a href=mailto:[EMAIL PROTECTED]Frank W. Zammetti/a
* @version $Id$
*/
public class RequestUtils
@@ -53,7 +56,7 @@
if (headerValue == null)
{
// dash w/ title case
-header = Strings.replace(header, _, -);
+header = header.replaceAll(_, -);
headerValue = request.getHeader(header);
if (headerValue == null)
{
@@ -68,7 +71,7 @@
if (headerValue == null)
{
// underscore w/ all lower
-header = Strings.replace(header, -, _);
+header = header.replaceAll(-, _);
headerValue = request.getHeader(header);
}
}
@@ -107,4 +110,77 @@
}
return header;
}
+
+
+ /**
+ * This method is a convenience method that calls the other three and
+ * returns a HashMap containing all request attributes, parameters and
headers
+ *
+ * @param request A valid HTTPServletRequest object
+ */
+ public static HashMap getAllRequestInfo(HttpServletRequest request) {
+
+HashMap hm = new HashMap();
+hm.put(Request Attributes, getRequestAttributes(request));
+hm.put(Request Parameters, getRequestParameters(request));
+hm.put(Request Headers, getRequestHeaders(request));
+return hm;
+
+ }
+
+
+ /**
+ * This method will return a HashMap that can be displayed which contains
+ * all request attributes.
+ *
+ * @param request A valid HTTPServletRequest object
+ */
+ public static HashMap getRequestAttributes(HttpServletRequest request) {
+
+HashMap hm = new HashMap();
+for (Enumeration en = request.getAttributeNames(); en.hasMoreElements();) {
+ String next = (String)en.nextElement();
+ hm.put(next, request.getAttribute(next));
+}
+return hm;
+
+ }
+
+
+ /**
+ * This method will return a HashMap that can be displayed which contains
+ * all request parameters.
+ *
+ * @param request A valid HTTPServletRequest object
+ */
+ public static HashMap getRequestParameters(HttpServletRequest
DO NOT REPLY [Bug 33676] - [servlet] SessionUtils and new methods for RequestUtils
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33676. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33676 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-03-09 01:51 --- Applied, with various fixes so it compiles etc, plus fixes to [servlet] itself which currently doesn't compile. And a fixed build system. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r156615 - in jakarta/commons/proper/chain/trunk/src: java/org/apache/commons/chain/web/ChainResources.java test/org/apache/commons/chain/web/ChainResourcesTestCase.java
Author: martinc
Date: Tue Mar 8 20:38:51 2005
New Revision: 156615
URL: http://svn.apache.org/viewcvs?view=revrev=156615
Log:
Factor out the comma-delimited parsing into a separate method, fix the
whitespace-skipping bugs in it, and add unit tests to verify that.
Added:
jakarta/commons/proper/chain/trunk/src/test/org/apache/commons/chain/web/ChainResourcesTestCase.java
Modified:
jakarta/commons/proper/chain/trunk/src/java/org/apache/commons/chain/web/ChainResources.java
Modified:
jakarta/commons/proper/chain/trunk/src/java/org/apache/commons/chain/web/ChainResources.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/chain/trunk/src/java/org/apache/commons/chain/web/ChainResources.java?view=diffr1=156614r2=156615
==
---
jakarta/commons/proper/chain/trunk/src/java/org/apache/commons/chain/web/ChainResources.java
(original)
+++
jakarta/commons/proper/chain/trunk/src/java/org/apache/commons/chain/web/ChainResources.java
Tue Mar 8 20:38:51 2005
@@ -17,6 +17,8 @@
import java.net.URL;
+import java.util.ArrayList;
+import java.util.List;
import javax.servlet.ServletContext;
import org.apache.commons.chain.Catalog;
import org.apache.commons.chain.config.ConfigParser;
@@ -65,20 +67,11 @@
if (loader == null) {
loader = ChainResources.class.getClassLoader();
}
+String[] paths = getResourcePaths(resources);
String path = null;
try {
-while (true) {
-int comma = resources.indexOf(,);
-if (comma 0) {
-path = resources.trim();
-resources = ;
-} else {
-path = resources.substring(0, comma);
-resources = resources.substring(comma + 1);
-}
-if (path.length() 1) {
-break;
-}
+for (int i = 0; i paths.length; i++) {
+path = paths[i];
URL url = loader.getResource(path);
if (url == null) {
throw new IllegalStateException
@@ -119,20 +112,11 @@
if (loader == null) {
loader = ChainResources.class.getClassLoader();
}
+String[] paths = getResourcePaths(resources);
String path = null;
try {
-while (true) {
-int comma = resources.indexOf(,);
-if (comma 0) {
-path = resources.trim();
-resources = ;
-} else {
-path = resources.substring(0, comma);
-resources = resources.substring(comma + 1);
-}
-if (path.length() 1) {
-break;
-}
+for (int i = 0; i paths.length; i++) {
+path = paths[i];
URL url = loader.getResource(path);
if (url == null) {
throw new IllegalStateException
@@ -166,20 +150,11 @@
if (resources == null) {
return;
}
+String[] paths = getResourcePaths(resources);
String path = null;
try {
-while (true) {
-int comma = resources.indexOf(,);
-if (comma 0) {
-path = resources.trim();
-resources = ;
-} else {
-path = resources.substring(0, comma);
-resources = resources.substring(comma + 1);
-}
-if (path.length() 1) {
-break;
-}
+for (int i = 0; i paths.length; i++) {
+path = paths[i];
URL url = context.getResource(path);
if (url == null) {
throw new IllegalStateException
@@ -217,20 +192,11 @@
if (resources == null) {
return;
}
+String[] paths = getResourcePaths(resources);
String path = null;
try {
-while (true) {
-int comma = resources.indexOf(,);
-if (comma 0) {
-path = resources.trim();
-resources = ;
-} else {
-path = resources.substring(0, comma);
-resources = resources.substring(comma + 1);
-}
-if (path.length() 1) {
-break;
-}
+for (int i = 0; i paths.length; i++) {
+path = paths[i];
URL url = context.getResource(path);
if (url == null) {
throw new IllegalStateException
@@ -248,6 +214,39 @@
}
}
+
+
+/**
+ * p Parse the resource string into an array of paths. Empty entries will
+ * be skipped. (That is,
Re: [vfs] parsing uri
Hello! Sounds like a long night today :-) Hard work - it might take some time until I can commit the new naming stuff. The whole procedure of parsing a uri needs to be refactored, currently I fight agains the Layered stuff e.g. tar:tar:file:/dir/first.tar!/second.tar!/entry And I already implemented some incompatibilites between the old and the new VFS naming: Current: file = getManager().resolveFile(%2e); resolves to the current Directory New: resolves to a file or directory NAMED . Current: file = getManager().resolveFile(dir%2fchild); resolves to a file child in directory dir New: resolves to a file or directory named dir/child Current: file = getManager().resolveFile(dir%5cchild); resolves to a file child in directory dir New: resolves to a file or directory named dir\child I leave it up to the filesystem if such a file or directory could be created. The above examples are those from the unit-test, so the old behaviour was wanted. But I think the new one is the right one. I think it is very unlikely that those constructs can be found in the wild life, but if one used VFS that way it IS broken. Any comments? --- Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] distribution packaging
--- Ceki Gülcü [EMAIL PROTECTED] wrote: Brian, From a cursory look at your document, I have to *speculate* that the changes you describe do not solve the core flaws in JCL but merely hide them by falling back on java.util.logging. However, I am only *speculating* as I have not had a chance to study your document with the care that it deserves. This is definitely the case with JCL 1.0.5RC1; the exceptions you noted were (largely) no longer thrown, but JCL fell back on java.util.logging. With the packaging changes, the logging was done using the expected implementation. I didn't just want to rely on my noticing the formatting differences in the log output between the different loggers, so the test cases also log the classname of the Log wrapper. After careful study of JCL, I am convinced that JCL is broken beyond hope. While its interfaces can be salvaged, its implementation must be thrown away entirely. While this opinion is not popular around here, it is based on verifiable facts, not wishful thinking that does not survive critical scrutiny. Perhaps coming down to a solution involving distributing multiple different jars, teaching users how to correctly deploy them, and then still having some use cases where JCL's discovery mechanism doesn't work qualifies as broken beyond hope. I'm actually still somewhat on the fence on this one. I think there are two issues here: 1) Does changing packaging actually solve some of the identified problems? This issue can and should be resolved empirically. 2) Is a proposed change so ugly/difficult to understand/limited in effectiveness that it's better to not bother and instead focus energy on a more radical solution? This is really a value judgement that IMHO can best be resolved through discussion within the community. My goal to this point has been to help clarify the empirical issues so that any discussion of the value judgements could proceed from a shared base of understanding. Regarding the issues of politics you raise, I don't really have the historical background to comment other than to say that referring to your Think Again article as a rant was uncalled for (and actually detracts from the content of the wiki page). (OK, someone out there, flame away :-) ). snip In late 1999, National Magazine published an article about a newly discovered Archaeoraptor fossil, calling it a true missing link demonstrating the relation between birds and dinosaurs, supposedly bringing to conclusion a debate raging since the 1860s. When XU XING, a Chineese palaeontologist, declared that the missing-link fossil acquired by National Geographic was a fake, the illustrious magazine rechecked their facts and admitted their mistake. They had invested considerably in the article and had already checked their facts. However, when XU XING's message arrived, they did not summarily dismiss it or ridicule his findings. They rechecked their facts. For the details of this fascinating story, please refer to [2]. Thanks for this link. I'd never heard this story. I'm also a bit of a Sinologist, so the background on the fossil trade in Liaoning is personally interesting. Brian Recently the ASF celebrated its 10th anniversary. IMHO, if the foundation is ever to celebrate its 100th anniversary, we better develop a better tradition for dealing with critical input. [1] http://wiki.apache.org/jakarta-commons/Commons_20Logging_20FUD [2] http://www.bbc.co.uk/science/horizon/2001/dinofooltrans.shtml On 2005-03-08 7:35:11, Brian Stansberry wrote: I was a little surprised myself, which is why I wanted to follow Ceki's good example and publish test cases that could easily be verified (or debunked) by others. -- Ceki Gülcü The complete log4j manual: http://www.qos.ch/log4j/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Celebrate Yahoo!'s 10th Birthday! Yahoo! Netrospective: 100 Moments of the Web http://birthday.yahoo.com/netrospective/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
