Re: [GUMP@brutus]: Project commons-jelly-tags-ant (in module jelly-tags) failed
What's happened to Gump? You think the Gump environment has changed? Hmm, the JDK was upgraded (within major release, not above) a short while ago. Other than that, nothing ought have changed, AFAIK. Could this be a problem? This was running ok previously. So is this NullPointer bogus? [junit] Testcase: copy took 0.131 sec [junit] Caused an ERROR [junit] file:/usr/local/gump/public/workspace/jelly-tags/ant/target/test-classes/org/apache/commons/jelly/ant/suite.jelly:114:80: util:loadText charsetName [junit] org.apache.commons.jelly.JellyTagException: file:/usr/local/gump/public/workspace/jelly-tags/ant/target/test-classes/org/apache/commons/jelly/ant/suite.jelly:114:80: util:loadText charsetName [junit] at org.apache.commons.jelly.impl.TagScript.handleException(TagScript.java:677) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:261) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:89) [junit] at org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59) [junit] Caused by: java.lang.NullPointerException: charsetName [junit] at java.io.InputStreamReader.init(InputStreamReader.java:82) [junit] at org.apache.commons.jelly.tags.util.LoadTextTag.doTag(LoadTextTag.java:87) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:252) [junit] ... 12 more [junit] Root cause [junit] java.lang.NullPointerException: charsetName [junit] at java.io.InputStreamReader.init(InputStreamReader.java:82) [junit] at org.apache.commons.jelly.tags.util.LoadTextTag.doTag(LoadTextTag.java:87) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:252) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:89) [junit] at org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59) BUILD FAILED /usr/local/gump/public/workspace/jelly-tags/ant/build.xml:97: Test org.apache.commons.jelly.ant.TestJelly failed regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ATTN Open-source projects using HttpClient
On Mon, 2004-09-20 at 22:50, Oleg Kalnichevski wrote: As far as I know the following projects rely on HttpClient 2.0 as a required or optional dependency * Apache Jakarta Slide (http://jakarta.apache.org/slide/) * Apache Jakarta Cactus (http://jakarta.apache.org/cactus/) * Apache Axis (http://ws.apache.org/axis/) * Apache XML-RPC (http://ws.apache.org/xmlrpc/) * Spring Framework (http://www.springframework.org/) * HtmlUntit (http://htmlunit.sourceforge.net/) * XINS (http://xins.sourceforge.net/) Just stumbled over this mail. Does the Dependees list here help give you other possibles? http://brutus.apache.org/gump/public/jakarta-commons/commons-httpclient/details.html regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Sorry for the [GUMP@gump]
A test Gump went rogue. I'll silence it, until it speaks the truth. regards, Adam -- Experience the Unwired Enterprise: http://www.sybase.com/unwiredenterprise Try Sybase: http://www.try.sybase.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Starting work on UGLI
I am CCing [EMAIL PROTECTED], avalon-dev and commons-dev to elicit input for this endeavor. I'm no expert in this area, simply an external user (with no insights into history/politics/whatever). That said, I'm not shy to provide my input... I've loved logging (log4j, simple), I've hated logging (for becoming a pain). I've never had good experiences with commons-logging in my environments (not saying I could do better, I recognize the challenge is non-trivial), but I accept it is currently a *necessary evil* given Javasoft adding to the mix w/ JDK logging. Logging users just ought not suffer the pain. If UGLI is a way to bring /commons-logging/ into the fold of logging services provided as a globally available service, I could be +1 for that .. That said, a few things: 1) I don't know the two communities, but one thing I like about C-L being in 'user space' is it is clearly a user advocate w/o the temptations to extend the API. We see (from the recent Gump failures) how many folks depend upon C-L already, but maybe putting it into a logging services community would open it up to more folks, including container writers. 2) I know C-L has a hard life, it is trying to sit on top of so much, but I find it's need/attempt to call/configure logging packages a problem. I don't know if I am expressing some form of IOC thought here, but when working on Depot, even C-L falls down. We (as a library) wanted to plug in to Ant, and we didn't want to force the C-L to Ant bridge. Basically, we wrote our own (yet another) logging that was simply a listener pattern, and plugged in an Ant logger listener, or a commons logging listener, as appropriate. Works nicely, but I don't want to write that code. I'd like UGLI as a logging abstraction that all containers can agree upon (Ant as a container, an application as a container) and have the environment provide it. 3) Forgive me, but ... would UGLI (with nose holding) be able to sit under JDK logging? Surely folks ought be able to just use that. Ugly or not, the JDK solution is going to be there inside any recent Java VM. Is that not sufficiently simple? Right now, logging is simple, but real-world logging has become way too complex, in too many environments. Something needs to give. regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vfs][all]maven generated build file and conditional compilation
gump.xml is the descriptor generated by maven gump IIRC. Since Gump's support for Maven as a build tool is rather new, there probably is no automated way to generate a Gump descriptor from project.xml yet. We've asked the Maven folks not to change the 'gump' goal *yet* (to produce maven instead of ant) just incase we make changes. That said, running 'maven gump' ought give a gump.xml that is then easily tweaked (change ant to maven, and target to goal -- or delete.) Take a look at the Gump descriptor of commons-id[1] to see how it would look with Maven instead of Ant. I assume you'd just have to select the correct goal and a transition was easy. Enough folks have asked. Note, this isn't fixed in stone: http://gump.apache.org/metadata/maven.html BTW, there is no reason to keep the descriptor outside of Gump's CVS module since all Apache committers have access to Gump. The reason it is outside of Gump's module now IIRC is that it is generated and not hand-maintained and thus should be kept in sync with project.xml - which is easier if both are at the same place. And if you move it in, we'll help you w/ maintenance if maven ever changes. regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[collections] Re: [GUMP@brutus]: jakarta-commons/commons-collections failed
I looked into this wondering if somehow Gump had something 'stale' lying around that caused it, but I see it is writing to an in-memory buffer reading from same, so no (at least not there). Could there be some stray class lying around that could be out sync? I find that hard to imagine, but will look if it is likely. Also, since this is writing a class (behind a List interface) to bytes and then reading (hopefully) same class back, I'm somewhat at a loss to see how the problem can even occur. Any pointers? [junit] Testcase: testEmptyListCompatibility(org.apache.commons.collections.list.TestTransform edList) : Caused an ERROR [junit] org.apache.commons.collections.list.TransformedList; local class incompatible: stream classdesc serialVersionUID = 107719303513141, local class serialVersionUID = 368464020144282561 [...] [junit] Testcase: testFullListCompatibility(org.apache.commons.collections.list.TestTransforme dList) : Caused an ERROR [junit] org.apache.commons.collections.list.TransformedList; local class incompatible: stream classdesc serialVersionUID = 107719303513141, local class serialVersionUID = 368464020144282561 regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [codec] base64Codec.decode and DecoderException
So, if I am following this ... we need a codec-1.1 module/project (in Gump)
against the CODEC_1_1 tag of codec that gives us frozen 1.1 code. Ok, that
ought be doable.
If nobody sees a problem with this approach, I'll give it a shot.
regards,
Adam
- Original Message -
From: Ryan Hoegg [EMAIL PROTECTED]
To: Jakarta Commons Developers List [EMAIL PROTECTED]
Sent: Thursday, June 03, 2004 8:41 PM
Subject: Re: [codec] base64Codec.decode and DecoderException
Hi,
I'd guess not. In Codec 1.1 the (checked) DecoderException was thrown.
XML-RPC 2.0 alpha (HEAD) depends on version 1.1 of codec with no known
issues.
I'd be surprised if we updated to 1.2 this summer. Our stable branch
(1.2) has no current or planned dependency on codec because we had our
own Base64 implementation. I probably already mentioned that we only
need Base64, so we might end up deciding against having a codec
dependency. Not long ago the Maven team encountered the same situation
and they decided to copy the Base64 source rather than to depend on
codec. I'd prefer not to follow suit for a lot of the same reasons we
decided to create a shared Base64 implementation in the first place
(early 2002 in the sandbox). For various reasons xmlrpc doesn't move
very quickly, especially by jakarta standards. So for the time being,
we'll probably stick with codec 1.1.
Cheers,
--
Ryan Hoegg
ISIS Networks
http://www.isisnetworks.net/
Gary Gregory wrote:
Has this been resolved within build_ws-xmlrpc_ws-xmlrpc?
I do not see the compile error mentioned in the message below in the
page:
http://brutus.apache.org:8080/gump/ws-xmlrpc/ws-xmlrpc/gump_work/build_w
s-
xmlrpc_ws-xmlrpc.html
Thank you,
Gary
-Original Message-
From: Adam R. B. Jack [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 25, 2004 09:44
To: Jakarta Commons Developers List
Subject: [codec] base64Codec.decode and DecoderException
Folks,
An interested compatibility issue has surfaced from this:
http://brutus.apache.org:8080/gump/ws-xmlrpc/ws-xmlrpc/gump_work/build_w
s-
xmlrpc_ws-xmlrpc.html
/usr/local/gump/public/workspace/ws-
xmlrpc/src/java/org/apache/xmlrpc/Defaul
tTypeFactory.java:133: exception
org.apache.commons.codec.DecoderException
is never thrown in body of corresponding try statement
[javac] catch (DecoderException e) {
[javac] ^
This is the code:
public Object createBase64(String cdata)
{
try {
return base64Codec.decode(cdata.getBytes());
}
catch (DecoderException e) {
//TODO: consider throwing an exception here?
return new byte[0];
}
}
Now since exceptions are not part of the signature of methods, there
is
probably no runtime issue here. If the exception is not going to be
thrown
that is the same as it not actually being thrown, I guess. Still,
there is
a
compile time problem and if one removes the catch they can't compile
against
older codec (assuming that was declared to throw it).
Can somebody provide the background information on this exception,
from
this
method, and when (releases) it might've been available and removed? If
this
exception is never to be thrown again (and better, if it isn't thrown
in
currently released code) then maybe we can just ask the ws-xmlrpc
folks to
update.
BTW: I don't think there is a way to turn off this compiler error, is
there?
Would that be appropriate, even if possible?
regards,
Adam
--
Experience the Unwired Enterprise:
http://www.sybase.com/unwiredenterprise
Try Sybase: http://www.try.sybase.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[codec] base64Codec.decode and DecoderException
Folks,
An interested compatibility issue has surfaced from this:
http://brutus.apache.org:8080/gump/ws-xmlrpc/ws-xmlrpc/gump_work/build_ws-xmlrpc_ws-xmlrpc.html
/usr/local/gump/public/workspace/ws-xmlrpc/src/java/org/apache/xmlrpc/Defaul
tTypeFactory.java:133: exception org.apache.commons.codec.DecoderException
is never thrown in body of corresponding try statement
[javac] catch (DecoderException e) {
[javac] ^
This is the code:
public Object createBase64(String cdata)
{
try {
return base64Codec.decode(cdata.getBytes());
}
catch (DecoderException e) {
//TODO: consider throwing an exception here?
return new byte[0];
}
}
Now since exceptions are not part of the signature of methods, there is
probably no runtime issue here. If the exception is not going to be thrown
that is the same as it not actually being thrown, I guess. Still, there is a
compile time problem and if one removes the catch they can't compile against
older codec (assuming that was declared to throw it).
Can somebody provide the background information on this exception, from this
method, and when (releases) it might've been available and removed? If this
exception is never to be thrown again (and better, if it isn't thrown in
currently released code) then maybe we can just ask the ws-xmlrpc folks to
update.
BTW: I don't think there is a way to turn off this compiler error, is there?
Would that be appropriate, even if possible?
regards,
Adam
--
Experience the Unwired Enterprise:
http://www.sybase.com/unwiredenterprise
Try Sybase: http://www.try.sybase.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging][PROPOSAL] a solution to incompatibility between log4j versions
With some changes to log4j HEAD and the following patch to commons-logging, it is now possible to compile commons-logging with 1.3alpha and run it with both 1.3 *and* 1.2.8. Is it too late to ask if things in log4j could be put back to where they were a week ago, while we work together for a clean longer term plan together? Even if C-L can manage this, there are other direct users (both inside Apache and *end users*) that will have to handle the situation. I know this has been 'on the way out' for long time, but it seems that the transition isn't as smooth as was hoped. Could a plan be put in place, guaranteed compatible changes put in place, and the clock start ticking on the 'overlap window'? regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging][PROPOSAL] a solution to incompatibility between log4j versions
On the log4j we are making a very serious effort to keep everyone happy. And that is greatly appreciated. :) I really wish you weren't having to go through this, I can hardly imagine how frustrating it must be to maintain an old interface for two years, attempting a clean deprecation, only run into such a gotcha. I do feel for you, and think users appreciate anything you can do to help. Tell us specifically what fails and we will do our best to fix it. Rolling back everything is not specific enough. Then can I say, whatever changed in the public API? ;-) Seriously though, I'd mentioned them previous in thread. That said, this thread has morphed, moved over 4 list, etc, so here again: Best I can tell from here: http://lsd.student.utwente.nl/gump/project_todos.html These two are the Priority deprecation: http://lsd.student.utwente.nl/gump/jakarta-commons/commons-logging/index.html http://lsd.student.utwente.nl/gump/jakarta-velocity/jakarta-velocity/index.html You already reverted this one, thanks (it was RootCategory, I think): http://lsd.student.utwente.nl/gump/avalon-excalibur/excalibur-logger/index.html Again, these are only the ones I can tell from within Apacge/Gump. External users who've not moved from Priority, are probably the same. Moreover, we have provided very clear set of instructions that safely address the c-l compilation problems. I think log4j is the wrong tree to bark at. I noticed that http://gump.covalent.net/log/bootstrap-ant.htmlbootstrap-ant no longer builds. Is it a related problem? Hmm, good question. Seems possible, but odd that it works here: http://lsd.student.utwente.nl/gump/ant/bootstrap-ant/index.html http://lsd.student.utwente.nl/gump/ant/bootstrap-ant/gump_work/buildscript_ant_bootstrap-ant.html (although here it assumes no log4j). The check does look for : available property=log4j.present classname=org.apache.log4j.Category classpathref=classpath/ Did that change? I'll ask a Gumpmeister (who has access to that box) to take a closer look, and get back to you. regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging][PROPOSAL] a solution to incompatibility between log4j versions
What about the option of having commons-logging 1.0.3 and earlier work with log4j 1.2.8 and earlier, and commons-logging 1.0.4 and later do whatever it feels like (since that's now possible with Ceki's recent changes)? I'm not gung ho about bending over backwards in order to not remove an API that's been deprecated for two years: that's the purpose of deprecation, to give people a warning that the deprecated item will be gone. Sure, but the opportunity of a smooth transition has been lost. Deprecation w/ an overlapping strategy (allowing both to operate) so folks can make the transition semi-transparently not impose Jar-Hell on users/users environments, now that is a beautiful thing. BTW: This isn't just C-L. BTW: I also wish folks had updated long ago, we'd have had a much smaller transition, be having discovered this sooner. regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging][PROPOSAL] a solution to incompatibility between log4j versions
BTW: I also wish folks had updated long ago, we'd have had a much smaller transition, be having discovered this sooner. I worded this poorly, and failed to get my point across. I meant ... I wish projects had stopped using deprecated stuff a year ago, heck ... or two. Progress has to be allowed to happens, so API change will happen ... and I agree it is a long time to carry around deprecate baggage. That said, it is an interesting challenge -- aligning the projects is like aligning the stars -- and good inter-project communications (tough in OSS) are critical to this. I don't know if the Java language allowed the class/methods to be marked as deprecated, 'cos I'm sure compiler warning would have moved things along. I don't know if the technique of sub-classing (Priority as an alias for Level, or vice-verse) is seen (in hindsight) as a good technique for API change, or not. This stuff just fascinates me (in the main 'cos I have to run lots of Java code, and suffer badly when it doesn't work). FWIIW: I don't know (wish I did) if there was a time in those two years, a period of log4j releases, where there were more 'actively used releases' that supported Priority than both Priority and Level. I wonder when would have been the right time (the best time, least user pain) for C-L to have moved, and if there was an opportunity missed there... BTW: Gump has no ego, all hail folks caring about Jar Hell! :-) regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging][PROPOSAL] a solution to incompatibility between log4j versions
You guys stopped me in my tracks for a mo, and I am (in my time) trying to get towards Gump w/ specific versions, but for here and now ... If it ain't broke, don't fix it. I can understand that for larger projects, but not for infrastructure/wrappers like C-L. C-L, by it's nature, is sitting in an environment fed to it by others, is impacted by the decisions of others (above and below). I'm not knocking C-L, please, this is for discussion only... GUMP acts as an early warning sign, but if a project doesn't care to update dependency X because there is no reason to change, but does care about tracking important dependencies, that needs to be accomodated. Understood. Recall, we can do that with Gump today (if not as cheaply as packaged releases) and we even do for log4j -- we have log4j-12 as well as log4j (HEAD). What occured though was that (as you gave in an example) AXIS got it's log4j from another place than C-L and failed to run. This is trying to alligh projects, and requires inter-project communication. For the sake of argument, let us say that a project doesn't care about tracking Log4J, but does care about DBCP and Avalon. It could have an indirect dependency on Log4J via two paths (hypothetically, for illustration, via Avalon and Commons Logging). Yup, this is jar hell. :-) I don't have an answer, but it is why I work on this (in what spare time I find, which it little): http://incubator.apache.org/depot/version/ http://incubator.apache.org/depot/version/jar-hell.html http://incubator.apache.org/depot/version/overview.html I'm going at a snails pace [and need to get to fix that site], and kinda expecting Sun to fix it before I get anywhere useful, but hey, no harm in trying... This is the mixed issue with GUMP. It acts as an early warning sign, but it also pushes projects to accept leading edge changes in order for GUMP builds to work, which may push them into using unstable code. Yeah, there are risk to staying up to the minute, and risks to falling too far behind (and not being able to catch up). Of the two, I'd rather lean towards the former (because of Jar-Hell, and becase [as I was told on this list] one get's better OSS support with new releases). That said, I think there is a balance, and Gump needs to allow/support it. No answers. Just observations. Same here. regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging][PROPOSAL] a solution to incompatibility between log4j versions
i've added some optional unit tests that give me confidence that a version of commons-logging compiled against log4j CVS HEAD will run against 1.2.7. it'd be a good idea to find a way for gump to run this test (but i'm not too sure at the moment how to do this). i'll probably add another where the log4j 1.3 jar is explicitly specified tomorrow. We have both 'CVS HEAD' and 'v1_2-branch' available to Gump. Is that close enough to 1.2.7? If so, the trick would be to run commons-logging unit tests separately from the compile, and run two of them with a dependency on logging-log4j and logging-log4j-12. regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging][PROPOSAL] a solution to incompatibility between log4j versions
If so, the trick would be to run commons-logging unit tests separately
from
the compile, and run two of them with a dependency on logging-log4j and
logging-log4j-12.
something along those lines would probably work.
Basically depend upon C-L to get what you just built, and then set an
environment to suit, then call ant with a 'test' target. You might wish to
change C-L from a 'dist' (compile/test/jar) to a simple compile/jar.
project name=commons-logging-test-SUITABLE-NAME
descriptionLogging Tests/description
url href=http://jakarta.apache.org/commons//
ant basedir=logging target=test/
depend project=ant inherit=runtime/
depend project=commons-logging/
depend project=xml-xerces/
depend project=logging-log4j-12/
or
depend project=logging-log4j/
or
depend project=avalon-logkit/
or
... missing (to test Simple)
nag to=[EMAIL PROTECTED]
from=robert burrell donkin
lt;[EMAIL PROTECTED]gt;/
/project
Note: I made the three mandatory dependencies, not optional. Better to fail
explicitly than fallback to simple.
This is in Gump CVS at ./project/jakarta-commons.xml. If you get too
much/too fancy, you might wish to pull it out into your own module
descriptor [like http-client chose], but I wouldn't yet.
a second gump target which tested just the log4j1.2.x compatibility
would probably do the trick. a third which allows us to test the avalon
framework logger would be cool as well.
and a forth to fallback to Simple? Your call.
BTW: C-L doesn't set runtime dependences within Gump, which is good for
this, bad for other things. AXIS failed when I set C-L to use log4j-12, but
sucked in it's own log4j ('cos C-L didn't provide). In the future we might
wish to address this, with the default C-L project setting things runtime,
but one step at a time.
i haven't found time to fix digester, beanutils and struts gump runs
yet but i hope to do so tomorrow. i you could give me some quick
pointers to the best way to do the additional targets, i'll add them to
my list of stuff to do...
Thanks for doing that.
regards
Adam
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging][PROPOSAL] a solution to incompatibility between log4j versions
Version numbers Together with deprecations this makes it easy (well sort of) to see which piece of software that is a drop-in replacement and which will require changes to your own code. In my book upgrading from 1.0.1 to 1.0.2 should be a walk in the park, but upgrading from 1.0 to 2.0 propably means I have to work late. If log4j decides to drop the Category class (which is their decision to make) I feel that would make it log4j 2.0 rather than 1.3. If commons-logging were to drop support for log4j 1.1 I think that would have to be commons-logging 1.1 rather than 1.0.4. Good points, and interface class removal, after deprecation, is covered in that document. Isn't there a document about this somewhere at Apache? Good point. It moved, but I found this via Google: http://jakarta.apache.org/commons/releases/versioning.html Not sure if folks outside of Jakarta Commons are held to this standard. :( regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging][PROPOSAL] a solution to incompatibility between log4j versions
i'm very open to suggestions about the best way to structure the build scripts. You able to benefit from Ant 1.6 (or are they earlier?) selectors? Ant's own build file uses them (along with available and such to do some pretty slick conditional compilation. regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [GUMP@brutus]: jakarta-commons/commons-latka failed
Please ignore this, this is due to commons-logging not working against log4j CVS HEAD, this is NOT a latka problem. regards Adam - Original Message - From: Ted Husted [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, May 17, 2004 7:01 PM Subject: [EMAIL PROTECTED]: jakarta-commons/commons-latka failed To whom it may engage... This is an automated request, but not an unsolicited one. For help understanding the request please visit http://gump.apache.org/nagged.html, and/or contact [EMAIL PROTECTED] Project commons-latka has an issue affecting its community integration. The current state is 'Failed', for reason 'Build Failed' Full details are available at: http://brutus.apache.org:8080/gump/jakarta-commons/commons-latka/index.html That said, some snippets follow: Gump provided these annotations: - Info - Sole jar [commons-latka.jar] identifier set to project name - Info - Dependency on jaxen exists, no need to add for property jaxen.jar. - Info - Made directory [/usr/local/gump/public/workspace/jakarta-commons/latka/target/classes] - Info - Made directory [/usr/local/gump/public/workspace/jakarta-commons/latka/target/test-classes] - Info - Enable debug output, due to a sequence of 17 previous errors. - Info - Failed with reason build failed Gump performed this work: http://brutus.apache.org:8080/gump/jakarta-commons/commons-latka/gump_work/build_jakarta-commons_commons-latka.html Work Name: build_jakarta-commons_commons-latka (Type: Build) State: Failed Elapsed: 0 hours, 0 minutes, 4 seconds Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/works pace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/ xml-xerces2/java/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xal an/java/build/xalan-unbundled.jar:/usr/local/gump/public/workspace/xml-commo ns/java/external/build/xml-apis.jar org.apache.tools.ant.Main -debug -Dgump.merge=/usr/local/gump/public/gump/wo rk/merge.xml -Dbuild.sysclasspath=only -Djaxen.jar=/usr/local/gump/public/wo rkspace/jaxen/target/jaxen-20040517.jar dist [Working Directory: /usr/local/gump/public/workspace/jakarta-commons/latka] CLASSPATH : /usr/local/j2sdk1.4.2_04/lib/tools.jar:/usr/local/gump/public/workspace/jaka rta-commons/latka/target/classes:/usr/local/gump/public/workspace/jakarta-co mmons/latka/target/test-classes:/usr/local/gump/public/workspace/ant/dist/li b/ant-stylebook.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.ja r:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gum p/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspac e/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/a nt-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-xalan2.jar :/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gum p/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/jak arta-commons/httpclient/dist/commons-httpclient.jar:/usr/local/gump/public/w orkspace/jakarta-commons/logging/dist/commons-logging.jar:/usr/local/gump/pu blic/workspace/jakarta-commons/logging/dist/commons-logging-api.ja r:/usr/local/gump/public/workspace/jakarta-commons/codec/dist/commons-codec- 20040517.jar:/usr/local/gump/public/workspace/logging-log4j/log4j-20040517.j ar:/usr/local/gump/public/workspace/logging-log4j/log4j-lf5-20040517.jar:/us r/local/gump/public/workspace/logging-log4j/log4j-chainsaw-20040517.jar:/usr /local/gump/public/workspace/jakarta-regexp/build/jakarta-regexp-20040517.ja r:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant-launcher.jar:/usr/l ocal/gump/public/workspace/ant/bootstrap/lib/ant.jar:/usr/local/gump/public/ workspace/jakarta-servletapi-4/lib/servlet.jar:/usr/local/gump/public/worksp ace/jdom/build/jdom.jar:/usr/local/gump/public/workspace/dist/junit/junit.ja r:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/pub lic/workspace/xml-fop/build/fop.jar:/usr/local/gump/public/workspace/avalon/ framework/target/avalon-framework-20040517.jar:/usr/local/gump/public/worksp ace/avalon/framework/api/target/avalon-framework-api-20040517.jar:/usr/local / gump/public/workspace/avalon/framework/impl/target/avalon-framework-impl-200 40517.jar:/usr/local/gump/public/workspace/jakarta-commons/io/dist/jakarta-c ommons-io-20040517.jar:/usr/local/gump/public/workspace/jakarta-commons/jell y/target/commons-jelly-20040517.jar:/usr/local/gump/public/workspace/jakarta -commons/beanutils/dist/commons-beanutils.jar:/usr/local/gump/public/workspa ce/jakarta-commons/collections/build/commons-collections-20040517.jar:/usr/l ocal/gump/public/workspace/jelly-tags/junit/target/commons-jelly-tags-junit- 20040517.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/comm ons-jexl-20040517.jar:/usr/local/gump/packages/dom4j-1.4/dom4j-full.jar:/usr /local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-20040517
Re: [GUMP@brutus]: jakarta-commons/commons-logging failed
I know logger know this better than I, but in case quick answer help w/ timezones... i am more than a little confused about this whole issue. i've taken a look in cvs and priority still seems to be in existence (and undeprecated). when i looked at the gump record for sunday, common-logging seems to have passed. can someone please either explain where the log4j changes are and when the failure occurred? The issues isn't wether Priority exists, so much as the called method. It now take Level only, the Priority version of the method has been removed. [BTW: This has (I am told) been deprecated for 2 years, so this really is somewhat overdue.) BTW: Whilst waiting for C-L to address this problem I let Gump build C-L on log4j 1.2, temporarily. That is no longer the case, you'll see failures in future Gump outputs (w/o a change). (as for the suggested patch) i'd be very unhappy about committing a patch which broke backwards compatibility with the most common versions of log4j (especially this close to a release). in fact, i'd probably think about vetoing any such change. there are a number of important upcoming releases who would be directly effected by these changes as well as a very large number of users of these releases who would be forced to upgrade. I beleive that it won't break compatibility any log4j within the last 2 years, because the alternate method has been there. If true, is that acceptable enough? Change has to be allow to occur, and this seems as smooth a transition as possible. regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [GUMP@brutus]: jakarta-commons/commons-logging failed
I'm no expert on when to [or not to] cross post, but this looks like a good topic for discussion in these two places at once. regards Adam - Original Message - From: Mario Ivankovits [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Monday, May 17, 2004 2:33 PM Subject: Re: [EMAIL PROTECTED]: jakarta-commons/commons-logging failed robert burrell donkin wrote: i am more than a little confused about this whole issue. i've taken a look in cvs and priority still seems to be in existence (and undeprecated). when i looked at the gump record for sunday, common-logging seems to have passed. can someone please either explain where the log4j changes are and when the failure occurred? (as for the suggested patch) i'd be very unhappy about committing a patch which broke backwards compatibility with the most common versions of log4j (especially this close to a release). in fact, i'd probably think about vetoing any such change. there are a number of important upcoming releases who would be directly effected by these changes as well as a very large number of users of these releases who would be forced to upgrade. Ceki Gülcü wrote: Fortunately, the required changes are easy and are backward compatible. Commons-logging code needs to be changed as follows. The change was in the Category class, formerly the log methods accepted a priority but this has change to a level now. But it looks like the change isnt really backward compatible, i have tried this now and got the following exception (patched commons-logging and log4j-1.2.8): java.lang.NoSuchMethodError: org.apache.log4j.Logger.log(Ljava/lang/String;Lorg/apache/log4j/Level;Ljava/ lang/Object;Ljava/lang/Throwable;)V at org.apache.commons.logging.impl.Log4JLogger.fatal(Log4JLogger.java:161) at org.apache.commons.vfs.test.RunTest.main(RunTest.java:31) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39 ) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl .java:25) at java.lang.reflect.Method.invoke(Method.java:324) at com.intellij.rt.execution.application.AppMain.main(Unknown Source) Maybe we relly need a new Log4J implementation depending on its version this is bad, isnt it? - 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: [GUMP@brutus]: jakarta-commons/commons-logging failed
please take into account that most old hands on jakarta commons use filtering extensively to ensure they have some time to do coding (rather than just reading mailing lists). cross posts may well be filed into low priority directories. unless the rules of the commons-dev mailing list are observed and prefixes are added to subjects, posts have a large chance of being ignored. i'd like to change the title of this thread very soon so that the other folks interested in commons-logging improved their chances of response. Yup, I need to look into whether Gump can respect this list's prefixing. I agree, us humans ought. ;-) regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] new snapshot to ibiblio
There is a convergence between the Gump Integration and this unstable repository which I hope is occurring, eventually, we hope that Gump will be used to produce a nightly build repository for projects, and that most projects will start taking advantage of this Continuous Integration for their development. I have been watching (lurking?) the Gump folks diligently working on this and I think its coming along. It is, but it'd happen a lot faster if you'd cease and decist lurking and start discussing. ;-) [I've had to stop myself sending you P2P mail asking for help more than once. Not having you involved has meant I've not focused on this. :-(] The Gump/Maven integration is raising good group/artefact issues, and the repository aspect is right next. Please come champion this cause it'll get a lot more focus. If you like, I can write up a proposal to the gump list to give you some context of the help I'd like, but mainly I just want your thoguhts/insights.] regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VFS]: Integration - too early?
* Is VFS still in a state of flux? Well - quite some time not much happened in VFS - i picked it up now and try to implement what ever comes in my head. Awesome! As a long time user of VFS (first Ruper, now Depot), this is great news. VFS is nicely done, and it'd be a real a shame to be without it. BTW: Depot is the only dependency on Gump that claims usage of VFS (and it'd be nice to see more): http://lsd.student.utwente.nl/gump/commons-vfs/commons-vfs/details.html#Project+Dependees http://lsd.student.utwente.nl/gump/depot/depot-update-ant-sample-vfs/index.html * Does VFS have a feature to dynamically detect which file systems are 'available'? Yes Could you make it not log at a WARNING level if it doesn't find something? Depot has Ant tasks that create the file systems (each run), and the ant build log is horribly poluted with insignificant things (about semi-obscure protocols). [I got so frustrated with this not being changed (I reported a year or more ago) I tried writting this myself, avoiding the StabdardFileSystem. Technically the API wouldn't allow me to safely do it I had to limp back, tail between legs. Would you want me to enter a change request for this? Also, last time Depot ran (using VFS) on Gump it crashed when VFS tried to set a null into HttpClient as a username (not behaviour the user can control, it seems). I posted here about it, and either need to know how to set a user (couldn't see it) or some fix/workaround. [I found it odd that VFS unit tests pass]. Would you want a Bugzilla report on this? [BTW: When Gump next runs Depot over VFS the output ought be here (below) and ought show the stack trace.] http://lsd.student.utwente.nl/gump/depot/depot-update-ant-sample-vfs/index.html Finally, thanks for stepping up to VFS, I look forward to your progress with baited breath. :-) regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] new snapshot to ibiblio
At this point I'm not sure what is correct. I only know that the efforts up to this point are to enable gump to use maven to accomplish a nightly build of a mavenized project, in which case you have an opportunity to control some of the dependencies when your project is integrated via the same mechanisms Maven is providing to you on the command line. Gump currently invokes Maven providing it with jar overrides from Gump produced jars (it also sets it 'offiline', to ensure control). So, for me, the question becomes -- what jars does Gump use (see below). Also, I'm not sure why you would want to fix your dependency to a specific snapshot release date when you the latest snapshot may be available to you via Gump/Maven. If you needed to rely on a specific version of a dependency, it would in my opinion, be a major release of that jar and not a dated snapshot. We've been discussing cases where we try to pick 'the very latest that works', in cases where CVS HEAD doesn't work. (Trying to get 600 or so projects all to work correctly at one point (allowing for real world API shifts, aka progess/clean-up) is like star alignment ... not seen in many folks lifetimes. ;-) As such, I could (personally) see a dated snapshot available to be used. What I am saying is that you either base your development on the bleeding edge (SNAPSHOT) or a stable release (x.x), not on a possibly outdated and unstable dated or nightly build. This is what we are trying to break away from by getting the nightlies off of ibiblio and into a separate Repository. I differ slightly from Stefan here, although I think we agree in principle. I think that Gump ought maintain an ASF-format repository (probably closed only to Gump, or those who know it is Gumped) so that it can go and gather 'the very latest that works'. I could see that we could try to automate this, and/or we could cooperate with humans (via metadata) to give a hint. regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] new snapshot to ibiblio
My impression was, GUMP always use the cvs-head to build the dependencies - and fixing the dependency to a given release is not the intention of GUMP. From experience, I can tell you that I welcome the new ability to fix certain dependencies. For example, the Avalon Project has made API changes that break compatibility with existing code. James ships with an earlier version of Avalon because of the incompatibility. Eventually, James will make the necessary changes, but that will happen on James' schedule, not Avalon's. But James also ships with Jakarta Commons DBCP, and will be using other Jakarta Commons packages. If James were forced to track the HEAD of all components, even when some of them are known to be incompatible, there would be no point in using GUMP, since failure can be assumed. However, with the new ability, James could fix the Avalon dependencies to the particular version(s) used, and still track HEAD for other dependencies. Actually, we need to correct/clarify something for the record. Gump has some of this already. It can use a CVS tag (or SVN branch) of some module to allow this. We used it yesterday because we are waiting for Commons Logging to become compatible with log4j CVS HEAD (to be known as 1.3). For CVS HEAD: http://lsd.student.utwente.nl/gump/logging-log4j/index.html http://lsd.student.utwente.nl/gump/logging-log4j/index.html#Definition And for log4j 1.2: http://lsd.student.utwente.nl/gump/logging-log4j-12/index.html http://lsd.student.utwente.nl/gump/logging-log4j-12/index.html#Definition See: module name=logging-log4j-12 tag=v1_2-branch We set C-L's dependency to logging-log4j-12 from logging-log4j. Adding the ability to get a dated/frozen build of a project [from a repository/store] allows further granularity (e.g. we coped with 1.3 up until X and would like to keep 'closer to' 1.3 than 1.2). Clearly the combinatorials are theoretically enormous, but (like tags) in practice they can be made to work. regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] new snapshot to ibiblio
Gump has some of this already. It can use a CVS tag (or SVN branch) of some module to allow this. Which would work really well if Avalon had tagged their stuff prior to complaints about why tagging is sort of vital, but all that we have are the current jars. Not even the Avalon folks who later tried were able to reproduce the contents. Not that you need to support that problem. :-) Now I didn't follow that exactly (except to commiserate ;-) but there are also two other possibities that I'm not sure if they help you, or not. We could add a 'packaged project' a fixed set of jars we don't (including can't) build, for project XYZ-version see: http://brutus.apache.org/gump/public/packages.html Alternatively, you could add/reference the jars in your CVS, and add you own XYZ-version, kinda like james-server.xml does for dnsjava right now. And I would love to have James (both branch_2_1_fcs and MAIN) building with GUMP. If this means adding two modules, james-server and james-server-2_1_fcs, then go for it. If you need help, let us know. As you know (if you read the thread on [EMAIL PROTECTED] about freezing phoenix) we can't (todate) ensure that no unfrozen components somewhere within both dependency trees won't throw a spanner into the works. We can consider that if/when it occurs though. regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] new snapshot to ibiblio
Actually we don't differ at all. Once we have support for last good builds or something similar in Gump, they can certainly live in a ASF-format repository. And if pushing the created jars into repository structure helps with anything we do, then go for it. Actually, it does it today although somehow I dorked it up with directory synchronization for Forrest pages. The jars are written to a repository (not guaranteed ASF-format yet, and with no .MD5s yet) but then the run 'tidies' that up (deleting it). I'll fix that, and made the repository available for review. My Gump doesn't use any repository means right now. Ah, ok, understood. Thanks. regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [GUMP@brutus]: jakarta-commons/commons-logging failed
From: Mario Ivankovits [EMAIL PROTECTED] wrote: Just for the records - i already posted a patch, maybe a logging-committer might pick it up http://issues.apache.org/bugzilla/show_bug.cgi?id=28933 Excellent, thank you. I really hope one of the commons logging folks will get to it today, and we can have a fuller Gump tonight. There is some good activity on projects infrequently Gumped, and I'd like to see that momentum continue. regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] new snapshot to ibiblio
- Original Message - From: Noel J. Bergman [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Thursday, May 13, 2004 4:44 PM Subject: RE: [collections] new snapshot to ibiblio I understand the desire to not having projects use snapshots, but the reality is you just sometimes need to build against head. The geronimo team tries to limit snapshots to projects that do instep releases with geronimo but that is still about 30 modules spread across 4 projects. Why use snapshots? If you want to track *current* status, you really want to turn that over to GUMP, which will pull source for every project you depend upon, and build Geronimo and all dependents from source. GUMP is the ASF's Continous Integration project, and will be adding (AIUI) testing, as well as the ability to freeze a given dependent to a released JAR. Testing (via ant running junit tests) has been they for a long time. Build/Testing (via Maven) is pretty close, and we have a geronimo project in place (although it is still a work in progress): http://lsd.student.utwente.nl/gump/incubator-geronimo/incubator-geronimo/index.html Let us know what you need/want, and we'll see if we can help you: [EMAIL PROTECTED] regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [GUMP@lsd]: jakarta-commons/commons-collections failed
Made a change to get more log info from ant script. Will probably fail again tonight :-( All I can see from here is the one failure unit test: http://lsd.student.utwente.nl/gump/jakarta-commons/commons-collections/gump_work/build_jakarta-commons_commons-collections.html If you turn on junit reports in the build, and tell Gump where to find them, it'll list them for you to view remotely. Something like: junitreport nested=collections/build/junit/results/ (or wherever they'd be) Added to: http://cvs.apache.org/viewcvs.cgi/gump/project/jakarta-commons.xml?view=markup In here: project name=commons-collections packageorg.apache.commons.collections/package descriptionCollections/description url href=http://jakarta.apache.org/commons/collections.html/ ant basedir=collections target=dist property name=component.version value=@@DATE@@/ /ant depend project=ant inherit=runtime/ depend project=xml-xerces/ depend project=junit/ work nested=collections/build/classes/ work nested=collections/build/tests/ home nested=collections/build/ jar name=commons-collections-@@DATE@@.jar/ javadoc nested=collections/build/docs/apidocs/ nag to=[EMAIL PROTECTED] from=Ted Husted lt;[EMAIL PROTECTED]gt;/ /project All apache folk have CVS commit permissions on Gump. BTW: Other Gump run do occur at other times (not just once nightly), so you might get a preview by looking at one of the others: http://lsd.student.utwente.nl/gump/servers.html regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [site] Gump Builds
Sorry folks, I almost missed this (given it was weekend and the traffic on this list). If you want to discuss this further, mind joining folk on the [EMAIL PROTECTED] list? [I don't know if cross posting is considered poor form or not in a case like this, and is a solution.] If not, I'll try to watch for subjects with 'Gump' in them on this list. regards, Adam - Original Message - From: Phil Steitz [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Saturday, April 10, 2004 9:59 AM Subject: Re: [site] Gump Builds Mark R. Diggory wrote: Lets push this to another thread because its such a great topic in and of itself. So I think we have several needs here: 1.) nightly builds of jars that can be available to developers 2.) Integration testing across all the commons 3.) Automated Site updating/generation. All great ideas. We have 1) now via the commons nightly build process and 2) is largely in place via the jakarta-commons gump module (though it uses ant and does not include all projects). Item 3) would be a *big* advantage and would eliminate the need for ssh access to update the site. It might also solve another open problem that we have in terms of site recoverability. A while back there was discussion of a staging / build server where we could build a pre-image of the production web site (so the current site would be always be recoverable without having to rebuild everything). If the clean environment that Adam refers to below could be that server (or could push to that server on success) and we could use rsynch (as I think Noel had suggested) to automate the push to production, this might be an effective way to keep the commons web site both up to date and recoverable. Can gump help us do this? Is there any way, using gump and maven cleverness, that we can separate the site generation from the integration build? If we could do that, we could leave jakarta-commons alone (just add ant-based descriptors for the missing projects) and create jakarta-commons-site just to do the site build. Phil Adam R. B. Jack wrote: Mark, Have you thought about enlisting the help of Gump for the manual effort here? We are trying to allow Gump to be able to use Maven (instead of Ant) for projects that prefer builds this way. We are making progress (with the mechanics) but [don't know if you've read the list/archive] the main sticking point seems to be group/artefact ids (something you know plenty about.) Can you outline what you finally resolved to concerning what the artifact/group ids should be for gump builds which use maven? If you are interested, Gump ought be able to make this task a bit easier on you, and automatically (nightly or more) do fresh runs (in clean environments) for you. Just a thought. regards Adam I'm just mostly unsure where to begin with getting with the Gump. I suspect we would register each project with gump and let them get built separately? -Mark - 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] test server
I have a vested interest in wanting VFS to be well tested (for Depot Ruper) so I'm game to see this... regards Adam - Original Message - From: Noel J. Bergman [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, March 19, 2004 10:14 AM Subject: RE: [VFS] test server Just as a thought, is this something that could run under User-Mode Linux on the new GUMP server when it is installed? Is this something that you would want to add to automated tests under GUMP? See: http://user-mode-linux.sourceforge.net/ http://usermodelinux.org/ http://www.honeynet.org/papers/uml/ http://www.linuxgazette.com/issue90/weber.html The latter two are tutorials that I thought would give you some ideas of how User-Mode Linux could be used to address your needs, including network in a box and the ability to reset the test system to a known state for each test. The GUMP folks have also talked a bit in passing about User-Mode Linux, so this seems an opportune time to point you folks at each other. --- Noel - 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]
[configuration turbine] Gump issues...
Hi, This started failing a while back: http://lsd.student.utwente.nl/gump/jakarta-turbine-stratum/gump_work/build_jakarta-turbine-stratum_jakarta-turbine-stratum.html#Output [javac] /data3/gump/jakarta-turbine-stratum/src/java/org/apache/stratum/component/Co mponentLoader.java:217: cannot resolve symbol [javac] symbol : constructor PropertiesConfiguration (java.lang.String,org.apache.commons.configuration.Configuration) [javac] location: class org.apache.commons.configuration.PropertiesConfiguration [javac] .configure(new PropertiesConfiguration(configFile, [javac]^ [javac] 1 error Any there doesn't appear to be a configure availalbe. Was this removed? http://cvs.apache.org/viewcvs.cgi/jakarta-commons/configuration/src/java/org/apache/commons/configuration/PropertiesConfiguration.java Could configuration folks work with the turbine folk to find a solution? Thanks in advance. regards, Adam -- Experience the Unwired Enterprise: http://www.sybase.com/unwiredenterprise Try Sybase: http://www.try.sybase.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ws-xmlrpc|codec] ws-xmlrpc fails on Gump when compiling against codec ...
ws-xmlrpc recently started failing to be Gumped against codec, see:
http://lsd.student.utwente.nl/gump/ws-xmlrpc/ws-xmlrpc.html
inside the build:
http://lsd.student.utwente.nl/gump/ws-xmlrpc/gump_work/build_ws-xmlrpc_ws-xmlrpc.html
stating:
[javac]
/data3/gump/ws-xmlrpc/src/java/org/apache/xmlrpc/DefaultTypeFactory.java:133
: exception org.apache.commons.codec.DecoderException is never thrown in
body of corresponding try statement
[javac] catch (DecoderException e) {
[javac] ^
This confused me, because looking in CVS the createBase64() method in:
http://cvs.apache.org/viewcvs.cgi/ws-xmlrpc/src/java/org/apache/xmlrpc/DefaultTypeFactory.java
has
try {
return base64Codec.decode(cdata.getBytes());
}
catch (DecoderException e) {
//TODO: consider throwing an exception here?
return new byte[0];
}
But the decode() method in this class does state it could throw:
org.apache.commons.codec.DecoderException
see:
http://cvs.apache.org/viewcvs.cgi/jakarta-commons/codec/src/java/org/apache/commons/codec/binary/Base64.java
Does anybody see anything I'm missing?
regards
Adam
--
Experience the Unwired Enterprise:
http://www.sybase.com/unwiredenterprise
Try Sybase: http://www.try.sybase.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] End Gump builds for sandbox projects
This is a proposal to begin to end the abuse of the sandbox. (The sandbox was intended as a temporary 'play area' for new ideas, not a long term project home) This is a fascinating approach, and not unlike something that drove me towards Gump in the first place. I was a heavy user of a common (sandbox) project that after a lot of (user) investment on my part went badly stagnant. I felt pretty mift, and wished I had some metrics (or similar) to help me make my choices of dependencies in the first place. I turned to Gump to attempt to determine which projects were healthy (stagnant isn't a bad thing for a feature rich, stable product, with a stable stack below it) and which weren't. I feel it is only 'open' to give an assessment of a project's status, and what better way that the 'googlesque' (I'm sure it is a word waiting to enter the dictionary ;-) approach of letting community usage/satisfaction do the talking. Increase the rating of a project by using it, depending on it. Decrease it by walking away (as I did) breaking dependency. Here Gump attempts to 'rate' a project by 'FOG Factor' (eventually something mystical, a combination of all, but right now a ratio of successes verse failures, including those of the dependency stack) : http://lsd.student.utwente.nl/gump/gump_stats/project_fogfactor.html This is by 'count of dependees' (how many projects depend on the project): http://lsd.student.utwente.nl/gump/gump_stats/module_dependees.html This is by last updated (on the module) - yup, sadly bogus for commons, I know. :( http://lsd.student.utwente.nl/gump/gump_stats/module_updated.html Gump is far from done, we'll work with folks to create new views/new stats, but it is amasing valuable (albethem statistical) insights into projects on a daily basis. As such - please do NOT remove these things from Gump, please help us use Gump to publically determine the wheat from the chaff, whilst you apply PMC or peer means to clean house of projects that have failed to achieve mass. Gump might be in a position (especially with help of users like you seeking solutions) to help you determine what course of action to take for each component... regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] LICENSE vs LICENSE.txt (was: [GUMP@lsd]: jakarta-commons-sandbox/commons-jjar failed)
It doesn't matter to Gump which you chose, the main thing is that if the Gump descriptor for a project references a license filename, and that filename is missing, it'll complain. That has caught us on few LICENSE - LICENSE.txt changes recently. regards Adam - Original Message - From: Henri Yandell [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Sunday, February 29, 2004 12:55 PM Subject: Re: [all] LICENSE vs LICENSE.txt (was: [EMAIL PROTECTED]: jakarta-commons-sandbox/commons-jjar failed) My fault, I thought it was the other way around for Commons. Hen On Sun, 29 Feb 2004, Michael Davey wrote: Gump 'bot (pretending to be Ted Husted) wrote: [snip] Project commons-jjar has an issue affecting it's community integration. The current state is 'Failed', for reason 'Build Failed' [snip] BUILD FAILED /data3/gump/jakarta-commons-sandbox/jjar/build.xml:173: Warning: Could not find file /data3/gump/jakarta-commons-sandbox/jjar/LICENSE to copy. I thought that the idea was that the prefered name is without an extension: quote href=http://apache.org/dev/apply-license.html; *Can the LICENSE and NOTICE files be called LICENSE.txt and NOTICE.txt?* This is permitted. However the preference is that the files be called LICENSE and NOTICE. /quote -- Michael - 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]
commons-jelly-tags-interaction on Gump...
Ought this say interaction not http? property name=final.name value=commons-jelly-tags-http-20031128/ http://lsd.student.utwente.nl/gump/jelly-tags/commons-jelly-tags-interaction.html http://lsd.student.utwente.nl/gump/jelly-tags/work/list_commons-jelly-tags-interaction_dir1_target.html project name=commons-jelly-tags-interaction work nested=interaction/target/classes/ work nested=interaction/target/test-classes/ depend project=commons-jelly inherit=all/ descriptionThis is a Jelly interface to the user./description mkdir dir=interaction/src/test// packageorg.apache.commons.jelly.tags.interaction/package jar name=interaction/target/commons-jelly-tags-interaction-20031128.jar/ ant basedir=interaction target=jar property name=final.name value=commons-jelly-tags-http-20031128/ /ant nag to=[EMAIL PROTECTED] from=Morgan Delagrange lt;[EMAIL PROTECTED]gt;/ /project regards Adam -- Experience Sybase Technology... http://www.try.sybase.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Commons-collections on Gump
Fixed in CVS, although I have to admit that I wasn't aware that gump was building javadocs. Yup, it is overkill. Somebody set the Gump descriptor to have an ant target of 'dist'. ant basedir=collections target=dist/ Could you suggest a target that only does compilation, and perhaps unit tests? regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Commons-collections on Gump
Hi, Could I trouble you guys to look this and tell me if this is a commons-collections problem, or a Gump problem, or some combination? This is from Python Gump: http://gump.dotnot.org/jakarta-commons/commons-collections.html http://gump.dotnot.org/jakarta-commons/work/build_jakarta-commons_commons-collections.html This from traditional Gump: http://gump.covalent.com/log/commons-collections.html [delete] Deleting directory /var/tmp/buildtemp_200311242110 doc-javadoc-testframework: [mkdir] Created dir: /var/tmp/buildtemp_200311242110 BUILD FAILED /data/gump/jakarta-commons/collections/build.xml:251: /var/tmp/buildtemp_200311242110/java not found. Total time: 3 minutes 45 seconds P.S. Impressive set of dependees: http://gump.dotnot.org/jakarta-commons/commons-collections.html#Project+Dependees regards Adam -- Experience Sybase Technology... http://www.try.sybase.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: commons-logging classloading (continued)
Forgive me for jumping in with a comment, I have the interest if not the
experience (at least not of the rest of this thread.) I'm wondering ... is
the issue loading the local webapp's version of commons logging, or getting
to it's configuration? Assuming a robust/stable interface/implementation of
CL, I have to assume the latter. Having a copy of CL bundled with the webapp
ought be just a fallback.
So, does that change the problem from class loading to resource loading? Is
it possible to get to the webapp's resource, [whereas getting to the webapps
classes might lead to a Link error.] I don't know the details of resource
loading, but I wonder if it is less of a rats nest than class loading. I
wonder if one could as for local-commonslogging.properties and if not found
go for commonslogging.properties [shipped with CL or whatever.] Unlike
classloading, I assume one can have multiple resources in memory more
easily.
That said, I don't know if one can teach the log load to detect that a
webapp was just loaded (if the Log class is already in memory). I assume
this is doable though.
Just a random thought...
regards
Adam
- Original Message -
From: Richard Sitze [EMAIL PROTECTED]
To: Jakarta Commons Developers List [EMAIL PROTECTED]
Sent: Tuesday, November 18, 2003 12:51 PM
Subject: RE: commons-logging classloading (continued)
So, I'm coming into this a bit late and all, and I know a few others have
been looking at this over the past few weeks... hope this does more than
just add fuel to the fire.
commons-discovery was created to address the classloader usage patterns
being discussed : how to discover an implemention for a given interface.
Commons-discovery was explicitly designed to be a general replacement for
LogFactory - I'd like to see LogFactory eliminated entirely from
commons-logging.
On the surface, you may not find that commons-discovery does anything more
than LogFactory. Underneath, it's a set of tools that let you setup your
own patterns.
That said:
LogFactory was designed to work in a J2EE environment by dropping it into
the Server level. It also functions quite well embedded into the
application.
As is being discovered, it doesn't work so well if you want some hybrid of
that. It's a known problem, and I'm sorry to say I simply don't see ANY
straight forward fix available - particularly by working with the
ClassLoaders. The following was proposed:
if (!Log.class.isAssignableFrom(logClass)) {
// Plan B. Bend over backwards to continue
Class logInterface =
LoadClass(org.apache.commons.logging.Log);
if (logInterface == null) {
throw new LogConfigurationException
(Log interface can not be found);
}
if (!logInterface.isAssignableFrom(logClass))
throw new LogConfigurationException
(Class + logClassName + does not implement Log);
}
The situation:
- logClass bundled into a webapp.
- commons-logging bundled into a webapp, with local configuration
settings.
- commons-logging bundled into the webserver, with global configuration
settings.
Clearly logClass, which implemented the local copy of Log, failed to
load because it doesn't implement the (expected) global copy of Log.
Calling LoadClass(org.apache.commons.logging.Log) will only return the
global copy - classloaders (by design) always defer to parent
classloaders. In this case, the web-app classloader gives the server
classloader first crack at loading Log. You simply don't have anyway to
see the local copy that's the fundamental problem.
***
Richard A. Sitze
IBM WebSphere WebServices Development
It's a kind of growing pain with the success of Commons.
Some servers have some commons jars while others not. In the
application you always include jars you needed. At the end of
day, situation like that seems inevitable, not just logging,
not mention the version problem.
Is it possible some standard be set or a classloader component
in Commons?
- sean
--- Ojares Rami EINT [EMAIL PROTECTED] wrote:
Well put Norbert.
I think that since classloading and threads are such complex
issues there should be a way to not use the pattern
of loading the implementation from thread's context classloader.
(Hint to Craig :)
- rami
-Original Message-
From: Norbert Klose [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 30, 2003 12:21 PM
To: [EMAIL PROTECTED]
Subject: commons-logging classloading (continued)
Hello,
i currently use Tomcat 4.1.27 bundled with commons-logging
1.0.3. My own webapp i'm working on also uses commons-logging,
so i include a copy of the jar file into the WEB-INF/lib
directory to be protable to other servlet containers that does
not include the commons-logging package. I found some
discussions in the mail archive that is about
Re: HttpClient Revolutions
You asked for opinions, here's mine... There is no point maintaining broken stuff, it just leads to more real world misery. Backwards compatible or not. I'd rather if it break at compile/dynamic link time, not runtime (with broken stuff). I want a ubiquitous HttpClient I can rely upon, and it needs to be stable, so it needs to be maintainable, hence clean. Your time is better spent making this clean than fighting mistakes. Short term pain, long term gain -- that's my view! [I've recently started two re-works, clean-ups -- and I've gotta say ... Yum! Nothing feels better...] regards, Adam P.S. Why can't HttpClient jump to a 3.0? Who cares about time and numbers? In a month [or whatever] folks will look back on working system and not know the difference. Is HttpClient really so ubiquitous it couldn't make a jump? - Original Message - From: Oleg Kalnichevski [EMAIL PROTECTED] To: Jakarata Commons HttpClient mailing list [EMAIL PROTECTED] Sent: Thursday, November 06, 2003 3:40 PM Subject: HttpClient Revolutions Folks, This is one of those days when my frustration with the existing HttpClient architecture reaches the point when I can hardly fight off the idea of stating a fork at SourceForge in order to finally get the very basic things right. I am really getting tired of patching the deficient architecture and bending it in all sorts of creative ways. I was trying to provide a fix for the bug that I introduced with one of my recent patches (authentication headers created by HttpMethodDirector end up removed in HttpMethodBase). The nasty thing is that since headers can be added to the HTTP method in several places, it is not quite clear at what point auto-generated headers are safe to be removed. If the auto-generated are cleaned up in the authentication/redirect loop, then they are not cleaned up in case of automatic recovery from a transport exception. As a result cookie headers can be duplicated. If the auto-generated headers are cleaned inside the retry loop, authentication headers are not re-generated in case of the method retry. So, once again the real trouble is the ugly design of the HttpMethod interface/HttpMethodBase class. The decision to recreate request headers every time the method is being executed was ill-conceived, not to mention that this is not quite efficient. I strongly believe that the process of request assembly and request execution should be decoupled. I suggest the generateRequstHeaders(HttpState, HttpConnection) method be added to the HttpMethod interface. The only problem that concerns me is that this may be too much of a change for 2.1 release, and I once again will end up accused of all sorts of things ranging from not caring about backward compatibility to deliberately breaking other people's stuff. Actually applications that only use public HttpClient APIs will not be affected, but classes implementing HttpMethod interface will be broken. Let me know what's your feeling about this I'm off to bed Oleg - 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]
[HttpClient] Freezes w/ MultiThreadedHttpConnectionManager
My single threaded user of VFS (an HttpClient user, that uses MultiThreadedHttpConnectionManager) hangs [I suspect indefinitely] on minor activity. I've turned on HttpClient debug and I see this, the last line being the last thing I get... 2003/10/09 09:34:26:482 MDT [DEBUG] wire - - Content-Type: text/html[\r][\n] 2003/10/09 09:34:26:482 MDT [DEBUG] HttpMethodBase - -Resorting to protocol version default close co nnection policy 2003/10/09 09:34:26:492 MDT [DEBUG] HttpMethodBase - -Should NOT close connection, using HTTP/1.1 2003/10/09 09:34:26:502 MDT [DEBUG] HttpMethodDirector - -Execute loop try 1 2003/10/09 09:34:26:512 MDT [DEBUG] MultiThreadedHttpConnectionManager - -HttpConnectionManager.getC onnection: config = HostConfiguration[host=www.ibiblio.org, protocol=http:80, port=80], timeout = 0 2003/10/09 09:34:26:522 MDT [DEBUG] MultiThreadedHttpConnectionManager - -Unable to get a connection , waiting..., hostConfig=HostConfiguration[host=www.ibiblio.org, protocol=http:80, port=80] I can send the full run logs if folks need/want. This is pretty reproducible. When I hack VFS not to use the MultiThreadedHttpConnectionManager I don't get the problem. I'll go find the bug tracking system (not sure why it isn't jumping out at me from the WWW site, but then -- nor are mailing lists, hence this -- maybe I need more coffee, or less sun glare before I look) . I'll enter a but report. FWIIW: I think I've noticed this for about a week, I only just found time to dig in. regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-commons/httpclient/src/java/org/apache/commons/httpclient MultiThreadedHttpConnectionManager.java
Thanks, this works for me. I appreciate the patch.
regards
Adam
- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, September 25, 2003 8:44 PM
Subject: cvs commit:
jakarta-commons/httpclient/src/java/org/apache/commons/httpclient
MultiThreadedHttpConnectionManager.java
mbecke 2003/09/25 19:44:18
Modified:httpclient/src/java/org/apache/commons/httpclient
MultiThreadedHttpConnectionManager.java
Log:
Fixes connection release problem.
PR: 22800
Submitted by: Michael Becke
Revision ChangesPath
1.25 +4 -4
jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/MultiThrea
dedHttpConnectionManager.java
Index: MultiThreadedHttpConnectionManager.java
===
RCS file:
/home/cvs/jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/
MultiThreadedHttpConnectionManager.java,v
retrieving revision 1.24
retrieving revision 1.25
diff -u -r1.24 -r1.25
--- MultiThreadedHttpConnectionManager.java 1 Sep 2003 18:06:55 -
1.24
+++ MultiThreadedHttpConnectionManager.java 26 Sep 2003 02:44:18 -
1.25
@@ -996,7 +996,7 @@
}
public void releaseConnection() {
-if (hasConnection()) {
+if (!isLocked() hasConnection()) {
HttpConnection wrappedConnection =
this.wrappedConnection;
this.wrappedConnection = null;
wrappedConnection.releaseConnection();
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[Daemon|JRCS] Gump Visibility ... Re: [vote] Move JRCS out of Jakarta
Folks wrote: [JRCS] The obvious problem is that the project is becomming invisible, and in so few people are working on it. It IS invisible, hence no one (ok, few people) knows it is here. [Daemon] I believe that now is the right time to reform the API since it seems like no one(*) is using it right now. I believe that another way to raise the visibility is to participate in the nightly Gump builds: http://cvs.apache.org/builds/gump/latest/ Gump is under a going re-write (http://nagoya.apache.org/wiki/apachewiki.cgi?GumpPython) and is looking to grow in what roles it performs. Yes, it helps with continuous integration, but there is more it can do. Gump wants to assist projects working together, assist with making and keeping friends. Gump is a social experiment, Gump likes friends liking friends. ;-) Seriously though, Gump can and should help with promoting reuse. Gump recognizes and documents project inter-dependencies, the community tells it it combines that information, and as such it can tell you who it knows is using your product. The new Gump documents this, even displays modules in order of the number of projects using a project, and such. Gump can and should promote good projects based upon their own good actions. This is a work in progress (needs icons added) and probably some redesign, but shows the concept. http://gump.chalko.com/py/index.html Some (rough) statistics: http://gump.chalko.com/py/gump_stats/index.html See dependees -- that is folks using this project: http://gump.chalko.com/py/krysalis-version/krysalis-version-core.html BTW: These mails prompted me to add (see tomorrow) site url to description here: http://gump.chalko.com/py/krysalis-version/index.html I'd like to see Gump map/document as much OSS (particularly younger/less-established Jakarta software) as it can. I'd like to see increased re-use/use through active/automated communication, and I know the Gump community are willing to work with teams, to help them tap into the melting pot. regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VFS|HttpClient] Re: [VFS] Crashes in getContent()
Stefan wrote:
Please note that there already is a commons-httpclient-2.0-branch
project in Gump's workspace. It would be trivial for projects to
depend on that branch instead of CVS HEAD and in fact jakarta-slide
and xml-rpc already do so.
Thanks, I'd not seen that.
However, most of my statement (and now question) is about friend-of-gump
behaviour, and having that project is good, but not friendly 'cos it
forces work onto sub-projects. Do you not agree that the project should
manage itself, should create the new (temporarily unstable) codebase as the
sub-named project, and should either alias (via project
name=commons-httpclient .. depend
name=commons-httpclient-old-stable-branch inherit=all) or rename
projects in order to manage it for folk? It seems better for the active
project to manage this once (with sub-projects having named projects should
they chose) than for sub-projects to attempt to keep track.
If not, it gets into me as a user having to manage VFS ('cos they are too
busy off elsewhere to do such things) and that seems (1) rude [I oughtn't]
(2) messy we'd loose valuable gump runs due to folks trying to keep in
synch.
regards,
Adam
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VFS|HttpClient] Re: [VFS] Crashes in getContent()
Mike wrote: I must disagree with you here. I responded to your bug report about 5 hours after you posted it. I was unable to reproduce this problem given the details you have provided. If you have some more detail about how to reproduce this problem, or perhaps a wire log, I would be happy to continue helping. http://issues.apache.org/bugzilla/show_bug.cgi?id=22800 Hmm, sorry Mike, I don't beleive I received notification of that. I certainly wasn't aware of the response. Sorry I didn't go look. The crash that I get (still w/ latest CVS HEAD) is that in HttpMethodDirector.procesRedirectResponse the connection returns null fir pretty much everything, including Protocol. As such it crashes in: connection.getProtocol().getScheme() on line 460. I will take your sample and attempt to reproduce it here. Unfortunately (for debugging this) I am using Commons VFS, which in turn uses HttpClient, so maybe it is some usage/re-usage/configuration sequence that causes this. I will see what I can do to reproduce. regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VFS|HttpClient] Re: [VFS] Crashes in getContent()
I will take your sample and attempt to reproduce it here. Unfortunately (for debugging this) I am using Commons VFS, which in turn uses HttpClient, so maybe it is some usage/re-usage/configuration sequence that causes this. I will see what I can do to reproduce. I found the settings that VFS was using, and tried to emulate. It seems to need the MultiThreadedHttpConnectionManager plus HEAD to crash. HttpClient client = new HttpClient(new MultiThreadedHttpConnectionManager()); HeadMethod head = new HeadMethod(url); client.executeMethod(head); I updated the bug database (I believe) so this is posted there. BTW: I don't mind bugs, in any complex software there will be bugs, but I feel it is only polite to have (1) test projects on gump -- that run your unit tests [so I can 'depend upon them'] (2) transition projects on gump when you are doing a big re-work, so you control when folks get exposed to the new work. Folks like VFS just don't tinker w/ their code that often, and so if this had been (or is) something inside their usage it could fester for a while. Since you chose to move them to CVS HEAD (for Gump) and since they don't run their unit tests (either) then my projects fail in Gump. Just a request... regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VFS|HttpClient] Re: [VFS] Crashes in getContent()
I updated the bug database (I believe) so this is posted there. FWIIW: I do not believe I am receiving e-mails from the bug tracker. Are other folks? Did you get my update? regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VFS|HttpClient] Re: [VFS] Crashes in getContent()
Oleg wrote: Adam, with all due respect let me point out that we have stable HTTPCLIENT_2_0_BRANCH branch that should be used by those who need API and/or code stability. If GUMP cannot be configured to use any other CVS branch but HEAD, this is a totally different kind of a problem, and it should be brought up to GUMP folks, not to us. Gump can be configured, but it is community configured, and your project has selected this configuration. I am (very recently) a gump folk, although still learning -- and these opionions are most definately, my own -- however I think we are discussing Gump ettiquette. I think your project unwittingly did something a bit unfriendly, and I'd like to cultivate a gump how-to or how-to-be-a-friend-of-gump that helps you/other projects from doing the same in the future. I care because I feel Gump supports inter-community respect, and project collaboration, and I want projects to depend upon each other more, not less. Gump's philosophy is to use CVS HEAD, and does so by default. You could've set your project to use the stable tag, but without it you involved all your dependees in any major changes. Now debatably this is a good thing, it helps you find the problems, but as your list of dependees gets long (and I hope it does :-) and if things fail, then this stops a whole sub-tree of Gump from Gumping ... and hence is detrimental to the community. As such, a separate transition project (one for stable, one for CVS HEAD) allows you and sub-projects to decide when to test the new stuff and you (via aliasing) can decide when to flip the switch. As for having unit tests run in the gump project, there are three schools of thought. First says don't do them, Gump is for compiling -- unit tests cost Gump CPU, but I disagree -- and I hope most folks do. Second is -- add them to your main project. Third says -- create a separate xxx-test project for your unit tests. The logic behind the third (which I am becoming a fan of) is that dependees can then chose to depend upon xxx or also upon xxx-test. Typically unit tests are very strict, so depending upon xxx-test might cause wasted gumping (a compile error might not be found due to some obscure unit test failing), so folks would normally not depend upon xxx-test (their yyy-test would find it) unless they felt xxx was unstable, and then they could. I think these are nuance of using Gump that escapes most Gump project configurer [I am just getting them], and I think it needs to be address via some sort of FriendOfGump guidelines documentation on Gump. I am copying the Gump list for their input, and if a conscensus is there I'll try to write up the documentaton. regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VFS|HttpClient] Re: [VFS] Crashes in getContent()
Oleg wrote: We will be more than happy to play by the rules, as long as they are clearly articulated and agreed upon, not just imposed upon us. I completely agree, and like I said -- these aren't even mandatory rules more here is how to play nicely w/ other Gumpers. I also agree it is upon the Gump folk to agree and document/communicate these things. I think this has been in the heads of those in the know for too long... There is one thing I really have an issue with: why do we have to have separate CVS modules per version under development, where a more natural way for me (very GUMP illiterate person) is to have a CVS branch per version being developed. It may happen that we will end up having yet another development stream in addition to version 2.0 and 2.1 development. Would that require yet another CVS module to remain GUMP friendly? Yikes, did I communicate this? No, not at all! I think we have a terminology miscommunication... Upon investigating how I see that one has to have multiple gump module descriptors for separate tags/branches in one CVS module, but that is doable. I beleive you can alias (via depends) to set the commons-httpclient to any one of your two (or three) tags. I will find some time to check this all out, and write it up/document it on the gump site. That said, the Jakarta POI recently did this with two module descriptors, but the same effect (although no aliasing): http://cvs.apache.org/viewcvs.cgi/jakarta-gump/project/jakarta-poi.xml?rev=1.29content-type=text/vnd.viewcvs-markup se module tag=.. http://cvs.apache.org/viewcvs.cgi/jakarta-gump/project/jakarta-poi3.xml?rev=1.4content-type=text/vnd.viewcvs-markup There are (at least) two ways to get a tag/branch for a module (I am still investigating on project). For reference see: http://jakarta.apache.org/gump/module.html w/ the tag on module and the cvs information. IF you look here I think you'll see a number of such examples: http://cvs.apache.org/viewcvs.cgi/jakarta-gump/project/#dirlist As I said, I care about this sort of stuff so am happy to try to help and/or document. regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VFS|HttpClient] Re: [VFS] Crashes in getContent()
Folks, what was the outcome of this discussion? From my perspective, it fizzled and died here. I logged a bug report on HttpClient (on one crash I received) but I don't believe any action has occurred. The Krysalis stack of projects still fail nightly on Gump with VFS/HttpClient. Please see: http://cvs.apache.org/builds/gump/latest/krysalis-version.html http://cvs.apache.org/builds/gump/latest/krysalis-centipede-site.html That said, these here look like VFS crashes, however I believe they are due to an earlier HttpClient crash. The stack I logged went into HttpClient and crashed there, something to do with processing a simple redirect. BTW: The lack of progress on this has finally pushed me to begin a re-write of Krysalis Ruper to make VFS HttpClient optional. The re-write is a good thing for itself, but the inability to rely upon this foundation is disappointing. regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VFS|HttpClient] Re: [VFS] Crashes in getContent()
Mike wrote: Yes, it looks like you are using HttpClient from HEAD. 2.0 code has been moved into a branch and we've started 2.1 in HEAD. All unit tests are passing but HEAD contains essentially alpha code. If you are looking for something stable I suggest 2.0. Mostly likely there is a bug in HEAD. Please submit a bug in Bugzilla when you get a chance. I can understand the reasoning to use HEAD for latest stuff, and I appreciate it being alpha code the benefits of starting some brave/risky new work for a new release. What I am wondering however is the choice of impact on gump until you are more stable . I don't have access to a VFS committer, and I am sure there are a bunch of httpclient dependencies that haven't had chance to chose their basis, you've made the choice for them by having the main common-httpclient be 2.1. Would it be possible for you to make the commons-httpclient project in gump be 2.0, and start a commons-httpclient-21 project for those brave enough to gump against it during alpha phase? When 2.1 is stable you could switch the main project to 2.1. I know Gump wants to integrate the latest/greatest, but when that isn't stable that isn't practical. What if folks (say VFS) tried to change their code to mend breaks on gump, and then you changed things again, that is a lot of busy work. I am not sure if there is a Gump Guideline for doing things the way I am request, but I've seen others do it. Thanks in advance for any consideration you can give this. regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VFS|HttpClient] Re: [VFS] Crashes in getContent()
A few more details/thoughts/questions: 1) The FSM appears to be using UrlFileObject although I have HttpClient in my path. (This was when run from inside Eclipse and not command line, with Eclipse project dependency upon HttpClient. With command line I get the right one. Could this be some issue w/ a difference of class loading inside Eclipse?) Is there any way I can get inside and dump/display an FSM's providers? (Unfortunately commons-logging seems to chose log4j in this environment not jdk1.4 logging, and I don't have that configured, so I am loosing the warnings. 2) I tested an exists call on a bad (non-existent) URL -- and it didn't return false when used with the UrlFileObject. I've not figured out why, but it seem like that problem has slipped back in. [If I can figure out where to add it I'll submit a patch w/ a test for this.] 3) When I test on the command line, w/ latest HttpClient from CVS, I do get a similar looking crash (see bottom) which looks like an HttpClient issue (hence the shared subject.) 4) When I attempt to run all the unit tests for commons-vfs I get numerous NullPtr crashes in the tests. Isthis somehow environmental, or are they failing? The NullPtrs don't look like HttpClient only, so perhaps there are two sets of problems. 5) Given all this, would it be possible for the two teams (VFS and HttpClient) to add test projects to gump to augment the compile projects? Meaning commons-httpclient-test and commons-vfs-test that depend upon their parents, and run unit tests. That way projects like krysalis-ruper could chose to depend upon a successful unit test run, and not propagate crashes. regards, Adam - F:\Krysalis\Testingjava org.krysalis.ruper.util.VfsUtils Aug 21, 2003 8:24:09 AM org.apache.commons.vfs.impl.StandardFileSystemManager addProvider WARNING: Skipping provider org.apache.commons.vfs.provider.ftp.FtpFileProvider because required cl ass org.apache.commons.net.ftp.FTPFile is not available. Aug 21, 2003 8:24:09 AM org.apache.commons.vfs.impl.StandardFileSystemManager addProvider WARNING: Skipping provider org.apache.commons.vfs.provider.smb.SmbFileProvider because required cl ass jcifs.smb.SmbFile is not available. Aug 21, 2003 8:24:09 AM org.apache.commons.vfs.impl.StandardFileSystemManager addProvider WARNING: Skipping provider org.apache.commons.vfs.provider.webdav.WebdavFileProvider because requi red class org.apache.webdav.lib.WebdavResource is not available. Aug 21, 2003 8:24:09 AM org.apache.commons.vfs.impl.StandardFileSystemManager addProvider WARNING: Skipping provider org.apache.commons.vfs.provider.sftp.SftpFileProvider because required class com.jcraft.jsch.JSch is not available. Exception in thread main java.lang.NullPointerException at org.apache.commons.httpclient.HttpMethodDirector.processRedirectResponse(Htt pMethodDirect or.java:454) at org.apache.commons.httpclient.HttpMethodDirector.isRetryNeeded(HttpMethodDir ector.java:63 9) at org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDir ector.java:14 5) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:378) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:268) at org.apache.commons.vfs.provider.http.HttpFileObject.doGetType(HttpFileObject .java:114) at org.apache.commons.vfs.provider.AbstractFileObject.attach(AbstractFileObject .java:919) at org.apache.commons.vfs.provider.AbstractFileObject.exists(AbstractFileObject .java:372) at org.krysalis.ruper.util.VfsUtils.main(VfsUtils.java:413) regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VFS|HttpClient] Re: [VFS] Crashes in getContent()
Thanks for the offer. For me, I downloaded the latest HttpClient and the latest VFS from CVS, built them using Eclipse, and tried a folder exists on a non-existent URL or a URL that does a redirect (to add a / for a 'directory'). Also, I found a lot of the unit test cases crash -- just run the set. regards Adam - Original Message - From: Jeff Barrett [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Thursday, August 21, 2003 9:50 AM Subject: RE: [VFS|HttpClient] Re: [VFS] Crashes in getContent() Do you have a test case I can try out? I'll see if I can reproduce the error and help sniff out a solution. +jeff -Original Message- From: Adam R. B. Jack [mailto:[EMAIL PROTECTED] Sent: Thursday, August 21, 2003 7:47 AM To: [EMAIL PROTECTED] Subject: [VFS|HttpClient] Re: [VFS] Crashes in getContent() A few more details/thoughts/questions: 1) The FSM appears to be using UrlFileObject although I have HttpClient in my path. (This was when run from inside Eclipse and not command line, with Eclipse project dependency upon HttpClient. With command line I get the right one. Could this be some issue w/ a difference of class loading inside Eclipse?) Is there any way I can get inside and dump/display an FSM's providers? (Unfortunately commons-logging seems to chose log4j in this environment not jdk1.4 logging, and I don't have that configured, so I am loosing the warnings. 2) I tested an exists call on a bad (non-existent) URL -- and it didn't return false when used with the UrlFileObject. I've not figured out why, but it seem like that problem has slipped back in. [If I can figure out where to add it I'll submit a patch w/ a test for this.] 3) When I test on the command line, w/ latest HttpClient from CVS, I do get a similar looking crash (see bottom) which looks like an HttpClient issue (hence the shared subject.) 4) When I attempt to run all the unit tests for commons-vfs I get numerous NullPtr crashes in the tests. Isthis somehow environmental, or are they failing? The NullPtrs don't look like HttpClient only, so perhaps there are two sets of problems. 5) Given all this, would it be possible for the two teams (VFS and HttpClient) to add test projects to gump to augment the compile projects? Meaning commons-httpclient-test and commons-vfs-test that depend upon their parents, and run unit tests. That way projects like krysalis-ruper could chose to depend upon a successful unit test run, and not propagate crashes. regards, Adam -- -- - F:\Krysalis\Testingjava org.krysalis.ruper.util.VfsUtils Aug 21, 2003 8:24:09 AM org.apache.commons.vfs.impl.StandardFileSystemManager addProvider WARNING: Skipping provider org.apache.commons.vfs.provider.ftp.FtpFileProvider because required cl ass org.apache.commons.net.ftp.FTPFile is not available. Aug 21, 2003 8:24:09 AM org.apache.commons.vfs.impl.StandardFileSystemManager addProvider WARNING: Skipping provider org.apache.commons.vfs.provider.smb.SmbFileProvider because required cl ass jcifs.smb.SmbFile is not available. Aug 21, 2003 8:24:09 AM org.apache.commons.vfs.impl.StandardFileSystemManager addProvider WARNING: Skipping provider org.apache.commons.vfs.provider.webdav.WebdavFileProvider because requi red class org.apache.webdav.lib.WebdavResource is not available. Aug 21, 2003 8:24:09 AM org.apache.commons.vfs.impl.StandardFileSystemManager addProvider WARNING: Skipping provider org.apache.commons.vfs.provider.sftp.SftpFileProvider because required class com.jcraft.jsch.JSch is not available. Exception in thread main java.lang.NullPointerException at org.apache.commons.httpclient.HttpMethodDirector.processRedire ctResponse(Htt pMethodDirect or.java:454) at org.apache.commons.httpclient.HttpMethodDirector.isRetryNeeded (HttpMethodDir ector.java:63 9) at org.apache.commons.httpclient.HttpMethodDirector.executeMethod (HttpMethodDir ector.java:14 5) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpCli ent.java:378) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpCli ent.java:268) at org.apache.commons.vfs.provider.http.HttpFileObject.doGetType( HttpFileObject .java:114) at org.apache.commons.vfs.provider.AbstractFileObject.attach(Abst ractFileObject .java:919) at org.apache.commons.vfs.provider.AbstractFileObject.exists(Abst ractFileObject .java:372) at org.krysalis.ruper.util.VfsUtils.main(VfsUtils.java:413) regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED
Re: [VFS|HttpClient] Re: [VFS] Crashes in getContent()
Thanks for that information, some project have separate test suite projects, so I wondered. If it could be replace that'd be great 'cos I'd like to see tests succeed on Gump (on latest stack below) not only on developers machines. It is Gump where things are failing for me. Also, usage of VFS on top of HttpClient seems broken right now, at least in my environment/usage on Gump, and the primary crash I found was in HttpClient code. I can't be sure it isn't VFS (or even Ruper on top of VFS) but the stack here seems to point to HttpClient (see below). There seems to be no test here: http://cvs.apache.org/builds/gump/2003-08-20/commons-httpclient.html The target test: here seems blank: http://cvs.apache.org/builds/gump/2003-08-20/commons-vfs.html As such Ruper and above crash. Now, I ought put my unit (I guess integration) tests into Ruper (I have some started, http://cvs.apache.org/builds/gump/2003-08-20/krysalis-ruper-ant-test.html, need 24 hours to get further) but I'd appreciate help from below. If at all possible nightly gump runs of unit tests (specifically VFS on top of HttpClient) would be greatly appreciated. Exception in thread main java.lang.NullPointerException at org.apache.commons.httpclient.HttpMethodDirector.processRedire ctResponse(Htt pMethodDirect or.java:454) at org.apache.commons.httpclient.HttpMethodDirector.isRetryNeeded (HttpMethodDir ector.java:63 9) at org.apache.commons.httpclient.HttpMethodDirector.executeMethod (HttpMethodDir ector.java:14 5) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpCli ent.java:378) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpCli ent.java:268) at org.apache.commons.vfs.provider.http.HttpFileObject.doGetType( HttpFileObject .java:114) at org.apache.commons.vfs.provider.AbstractFileObject.attach(Abst ractFileObject .java:919) at org.apache.commons.vfs.provider.AbstractFileObject.exists(Abst ractFileObject .java:372) at org.krysalis.ruper.util.VfsUtils.main(VfsUtils.java:413) regards Adam - Original Message - From: Ortwin Glück [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Cc: Commons HttpClient Project [EMAIL PROTECTED] Sent: Thursday, August 21, 2003 9:31 AM Subject: Re: [VFS|HttpClient] Re: [VFS] Crashes in getContent() Adam, I think HttpClient used to perform unit tests after compiling. However this seems to have changed somehow? Still, be assured that the HttpClient repository is usually (modulo checkin mistakes) in a state where all tests succeed. All committers are told to run all unit test before checking in. Regards Ortwin Glück Adam R. B. Jack wrote: 5) Given all this, would it be possible for the two teams (VFS and HttpClient) to add test projects to gump to augment the compile projects? Meaning commons-httpclient-test and commons-vfs-test that depend upon their parents, and run unit tests. That way projects like krysalis-ruper could chose to depend upon a successful unit test run, and not propagate crashes. -- _ NOSE applied intelligence ag ortwin glück [www] http://www.nose.ch software engineer [email] [EMAIL PROTECTED] hardturmstrasse 171 [pgp key] 0x81CF3416 8005 zurich [office] +41-1-277 57 35 switzerland [fax] +41-1-277 57 12 - 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|HttpClient] Re: [VFS] Crashes in getContent()
Thanks for that information, some project have separate test suite projects, so I wondered. If it could be replace that'd be great 'cos I'd like to see tests succeed on Gump (on latest stack below) not only on developers machines. It is Gump where things are failing for me. Also, usage of VFS on top of HttpClient seems broken right now, at least in my environment/usage on Gump, and the primary crash I found was in HttpClient code. I can't be sure it isn't VFS (or even Ruper on top of VFS) but the stack here seems to point to HttpClient (see below). There seems to be no test here: http://cvs.apache.org/builds/gump/2003-08-20/commons-httpclient.html The target test: here seems blank: http://cvs.apache.org/builds/gump/2003-08-20/commons-vfs.html As such Ruper and above crash. Now, I ought put my unit (I guess integration) tests into Ruper (I have some started, http://cvs.apache.org/builds/gump/2003-08-20/krysalis-ruper-ant-test.html, need 24 hours to get further) but I'd appreciate help from below. If at all possible nightly gump runs of unit tests (specifically VFS on top of HttpClient) would be greatly appreciated. Exception in thread main java.lang.NullPointerException at org.apache.commons.httpclient.HttpMethodDirector.processRedire ctResponse(Htt pMethodDirect or.java:454) at org.apache.commons.httpclient.HttpMethodDirector.isRetryNeeded (HttpMethodDir ector.java:63 9) at org.apache.commons.httpclient.HttpMethodDirector.executeMethod (HttpMethodDir ector.java:14 5) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpCli ent.java:378) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpCli ent.java:268) at org.apache.commons.vfs.provider.http.HttpFileObject.doGetType( HttpFileObject .java:114) at org.apache.commons.vfs.provider.AbstractFileObject.attach(Abst ractFileObject .java:919) at org.apache.commons.vfs.provider.AbstractFileObject.exists(Abst ractFileObject .java:372) at org.krysalis.ruper.util.VfsUtils.main(VfsUtils.java:413) regards Adam - Original Message - From: Ortwin Glück [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Cc: Commons HttpClient Project [EMAIL PROTECTED] Sent: Thursday, August 21, 2003 9:31 AM Subject: Re: [VFS|HttpClient] Re: [VFS] Crashes in getContent() Adam, I think HttpClient used to perform unit tests after compiling. However this seems to have changed somehow? Still, be assured that the HttpClient repository is usually (modulo checkin mistakes) in a state where all tests succeed. All committers are told to run all unit test before checking in. Regards Ortwin Glück Adam R. B. Jack wrote: 5) Given all this, would it be possible for the two teams (VFS and HttpClient) to add test projects to gump to augment the compile projects? Meaning commons-httpclient-test and commons-vfs-test that depend upon their parents, and run unit tests. That way projects like krysalis-ruper could chose to depend upon a successful unit test run, and not propagate crashes. -- _ NOSE applied intelligence ag ortwin glück [www] http://www.nose.ch software engineer [email] [EMAIL PROTECTED] hardturmstrasse 171 [pgp key] 0x81CF3416 8005 zurich [office] +41-1-277 57 35 switzerland [fax] +41-1-277 57 12 - 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]
[VFS] Crashes in getContent()
Over the last few days we've started to see runtime failures due to a crash
inside VFS.
An example is on the public gump (so using nightly from CVS) and it has
happened two nights in a row (at least).
http://cvs.apache.org/builds/gump/2003-08-20/krysalis-centipede-site.html
The crash is at:
java.lang.NullPointerException at
org.apache.commons.vfs.provider.AbstractFileObject.getInputStream
(AbstractFileObject.java:821)
at org.apache.commons.vfs.provider.DefaultFileContent.getInputStream
(DefaultFileContent.java:289)
at org.krysalis.ruper.util.VfsUtils.getChildren(VfsUtils.java:176)
at
We have a helper method which we use to try to sniff children for a
directory listing url -- since current VFS has no sense of folder (or
children) for HTTP 'files'. The code has been working for a long time, but
recently stopped working.
I don't know if this is using HTTPClient or java.net.URL, but I assume the
former.
Can anybody help?
regards
Adam
public static FileObject[] getChildren(FileObject folder)
throws IOException, MalformedURLException, FileSystemException {
FileObject[] result = null;
if (folder.getFileSystem().hasCapability(Capability.LIST_CHILDREN)) {
if (folder.getType() == FileType.FILE) {
result = new FileObject[] { folder };
}
else {
result = folder.getChildren();
}
}
else if (http.equals(folder.getURL().getProtocol())) {
ArrayList list = new ArrayList();
// try opening the URL
InputStream urlStream = folder.getContent().getInputStream();
String type = URLConnection.guessContentTypeFromStream(urlStream);
if ((type == null) || (type.compareTo(text/html) != 0)) {
--
ExperienceSybase Technology...
http://www.try.sybase.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VFS][patch] rename plus various others
--- Jeff Barrett [EMAIL PROTECTED] wrote: [...] - FileSystemException prints nested exceptions instead of hiding them Is this safe for JDK's earlier that JDK1.4? A quick eyeball of the diff.txt makes me think otherwise. regards, Adam = -- Adam R. B. Jack - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VFS][patch] rename plus various others
Should be. I'm using jdk 1.3.1. What did you see that made you suspicious? I assumes the inherited throwable member data was part of JDK1.4 'cause' stuff. If you've tested it on JDK 1.3.1 great, and obviously not, so my bad. regards Adam = -- Adam R. B. Jack - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VFS] Warning Verbosity
Hi, Can I ask (again) for some sort of help for the verbosity problem we have with our ant tasks that use dynamic VFS configuration? Basically we get way too many reports... http://gump.chalko.com/krysalis-version-antlib.html BTW: We can't use a single VFS FileSystem 'cos these are separate tasks. regards Adam = -- Adam R. B. Jack - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
