Fwd: [GUMP@brutus]: Project logging-log4j-12 (in module logging-log4j-12) failed
-log4j-12_logging-log4j-12.html Work Name: build_logging-log4j-12_logging-log4j-12 (Type: Build) Work ended in a state of : Failed Elapsed: Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar org.apache.tools.ant.Main -Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dversion=29042005 jar [Working Directory: /usr/local/gump/public/workspace/logging-log4j-12] CLASSPATH: /opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/logging-log4j-12/dist/classes:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/packages/jms1.1/lib/jms.jar:/usr/local/gump/packages/jmx-1_2-ri/lib/jmxri.jar:/usr/local/gump/packages/jmx-1_2-ri/lib/jmxtools.jar:/usr/local/gump/packages/javamail-1.3.2/mail.jar:/usr/local/gump/packages/javamail-1.3.2/lib/mailapi.jar - Buildfile: build.xml init: slf4jCheck: BUILD FAILED /home/gump/workspaces2/public/workspace/logging-log4j-12/build.xml:168: Missing src/java/org/slf4j/*.java source files. Just run the refresh-slf4j target with the command: ant refresh-slf4j Total time: 0 seconds - To subscribe to this information via syndicated feeds: - RSS: http://brutus.apache.org/gump/public/logging-log4j-12/logging-log4j-12/rss.xml - Atom: http://brutus.apache.org/gump/public/logging-log4j-12/logging-log4j-12/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 2729042005, brutus:brutus-public:2729042005 Gump E-mail Identifier (unique within run) #10. -- Apache Gump http://gump.apache.org/ [Instance: brutus] -- Ceki Gülcü The complete log4j manual: http://www.qos.ch/log4j/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [GUMP] cocoon and related failures
At 07:11 PM 1/20/2005, Curt Arnold wrote: This looks like an unintentional (or at least undiscussed) break due to the packaging of log4j. I would discourage Cocoon from redirecting to logging-log4j-12 until the log4j project has had a chance to discuss the issue. It was an unintentional breakage which was fixed even before we became aware of its effect on Cocoon. In the next gump run the problem should disappear. Cheers, -- Ceki Gülcü The complete log4j manual: http://www.qos.ch/log4j/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: logging-log4j/src/java/org/apache/log4j/net SMTPAppender.java
Niclas et al., IMHO, the kind of urgent pleas as the one by Niclas (quoted below) are quite inappropriate. We, the log4j developers, have the right to occasionally fuck up like every one else. The fact that a small typo affects 200 projects should tell you that something is wrong with Gump's current approach. When a totally silly problem attains such cataclysmic proportions, it puts us (log4j developers) under unnecessary and useless pressure. Please revise your model so that a silly mistake can be sidestepped without affecting 200 projects. For example, just alerting log4j-dev and having the 200 affected projects to use yesterday's version of log4j would have been much better. I am pleased to see that the problem on our side was corrected promptly. I am much less so with nature of the social interaction that led to it. At 07:37 AM 12/14/2004, Niclas Hedhman wrote: May I suggest a revert of the change first, and then think about how it should be done?? :o) (only 200 projects are affected...) Cheers Niclas -- -- Ceki Gülcü The complete log4j manual: https://www.qos.ch/shop/products/log4j/log4j-Manual.jsp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Picking up the ball from Niclas (ugh!) on Velocity
On 2004-11-30 11:19:33, Eric Pugh wrote: Now, partly that may be a communication thing.. If Log4j fails, they get emailed. If log4j breaks every body else, they don't... Without active involvement by a group, the prospect of keeping things working becomes a thankless task (witness Niclas's frustration). I thought hey, I'll try and help and ran into, in an hour, the same frustration Niclas sees.. I am not a committer (or even involved beyond the occasional email) with Log4j or Velocity, so who do I got to prod for action? This reminds me of a joke. A bloke with rather unusual sexual abilities is invited to give a public demonstration. A large crowd gathers in an arena while the bloke does it with 1, then 2, then 3 consenting adults of the opposite sex. The crowd begins to chant 10, 11, .., 95. At the 96th the bloke gets tired. He makes a last ditch effort, 97 ... 98. The crowd falls silent, and he makes it to 99. The 100th is too much for our bloke, who gives up. The crowd erupts yelling Homosexual, Homesexual. If at the slightest sign of breakage you are going to blame people for being unfriendly or obtuse, Gump will not succeed in bringing people closer together. -- Ceki Gülcü The complete log4j manual: http://qos.ch/eclm Professional log4j support: http://qos.ch/log4jSupport - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] turning off nagging until we feel gump is solid enough for that
At 03:44 PM 12/1/2004, Stefano Mazzocchi wrote: I think it's better if we start to nag ourselves first and see how we can increase the signal/noise ratio before we go back public. It's not only about gump's signal/noise ratio but the attitude adopted when things break. Allowing unaware developers to become aware that things broke (or may brake) offers tangible benefits. Once the dialog is triggered, it should go both ways. Depicting gump offenders as morons won't get us anywhere. In the past, the social algorithm for gump has been: 1) Gump checks for dependency issues. 2) If gump detects problems, social pressure is applied on the offender until the offenders yield. Otherwise, the offender is depicted as an insensitive moron. I suggest you review this social algorithm. -- Stefano. -- Ceki Gülcü The complete log4j manual: http://qos.ch/eclm Professional log4j support: http://qos.ch/log4jSupport - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] turning off nagging until we feel gump is solid enough for that
At 05:27 PM 12/1/2004, Stefano Mazzocchi wrote: If you have a better social algorithm that would stop you from feeling insulted, let us know what it is. It's not about me, log4j or velocity, but coming to the realization that 100% backward compatibility is not always possible. It seems that gump is based on the premise that an item can be removed in version n, if it has been deprecated on version k, where k n. Although most reasonable, this policy cannot always be followed, for legitimate reasons. Don't understand me wrong, I very much appreciate Gump as a service. For example, log4j developers would like to be notified of changes in log4j CVS head that affect dependents. However, many dependents do not need to be aware of these changes, only log4j developers need to know about them. Before releasing the next version, we will publish a step-by-step migration document. Detecting that project V broke because of changes in project L, and then notifying only L, is a lot more complicated than what gump does currently. Surely that's asking too much out of Gump. Our goal is not to insult people or to create trouble. Ditto here. -- Stefano. -- Ceki Gülcü The complete log4j manual: http://qos.ch/eclm Professional log4j support: http://qos.ch/log4jSupport - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: failure notice
At 02:58 PM 11/30/2004, Geir Magnusson Jr wrote: On Nov 30, 2004, at 8:32 AM, Ceki Gülcü wrote: At 03:39 AM 11/30/2004, Geir Magnusson Jr wrote: some lists choose to moderate... Hello Geir, We currently don't but may switch back to moderated list. Sorry about the hassle. anyway, the interesting thing is the problem I have fixing Velocity so Gump is happy ... Niclas Hedhman informed us of this problem. There was a conscious choice to remove the old RollingAppender and replace with something better. That's all well and good, but why not deprecate for a version? Because the old RollingAppender has bugs. Consequently, we don't want to make it available to Mrs. Piggy in the next version of log4j 1.3. But what gump has done here is given us early warning that if one of us doesn't do something, Velocity users [and every other log4j user using RollingFileAppender] are *screwed* if they try to upgrade a minor version number of log4j, to 1.3. What I want is that existing velocity users can upgrade to log4j 1.3 w/o hassle. Log4j 1.3 is currently in alpha. Ignore 1.3 until it goes RC. When it goes RC, switch to 1.3. It should be trivial to do so. But forgetting Gump, in general, what do you want me and other users to do? have to modify our code to update to 1.3? Wait, don't do anything for the time being. Velocity ships with a copy log4j doesn't it? Continue to ship log4j 1.2.9 until you decide to switch to 1.3, for example when it goes RC. Switching velocity to use log4j 1.3 instead of 1.2 should be pretty easy to do. How does that sound? geir -- Ceki Gülcü The complete log4j manual: http://qos.ch/eclm Professional log4j support: http://qos.ch/log4jSupport - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [GUMP@brutus]: Project logging-log4j (in module logging-log4j) failed
Forgot to check in two modified files. Should be fixed now. At 07:17 AM 11/18/2004, [EMAIL PROTECTED] wrote: To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project logging-log4j has an issue affecting its community integration. This issue affects 212 projects. Full details are available at: http://brutus.apache.org/gump/public/logging-log4j/logging-log4j/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -INFO- Failed with reason build failed -DEBUG- Extracted fallback artifacts from Gump Repository [javac] ^ [javac] /home/gump/workspaces2/public/workspace/logging-log4j/src/java/org/apache/log4j/xml/examples/XMLSample.java:50: cannot resolve symbol [javac] symbol : method logErrors () [javac] location: class org.apache.log4j.joran.JoranConfigurator [javac] jc.logErrors(); [javac] ^ [javac] /home/gump/workspaces2/public/workspace/logging-log4j/src/java/org/apache/log4j/xml/test/DOMTest.java:56: cannot resolve symbol [javac] symbol : method logErrors () [javac] location: class org.apache.log4j.joran.JoranConfigurator [javac] jc.logErrors(); [javac] ^ [javac] 2 errors [javac] 50 warnings BUILD FAILED /home/gump/workspaces2/public/workspace/logging-log4j/build.xml:291: Compile failed; see the compiler error output for details. Total time: 8 seconds - -- Ceki Gülcü The complete log4j manual: http://qos.ch/eclm Professional log4j support: http://qos.ch/log4jSupport - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Gump Failure
Hi Niclas, The error is due to a silly bug in o.a.l.config.PropertySetter. It was fixed a few minutes ago, independently of your message. :-) At 04:09 PM 11/18/2004, Niclas Hedhman wrote: Gang, I think the following Gump failure could be related to recent Log4J changes... http://brutus.apache.org/gump/public/ws-axis/ws-axis/gump_work/build_ws-axis_ws-axis.html Any input is appreciated. Cheers Niclas -- -- Ceki Gülcü The complete log4j manual: http://qos.ch/eclm Professional log4j support: http://qos.ch/log4jSupport - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [human-assisted gump] log4j back incompatible change
Hello Stefano, We have been trying to shed the Category class for over 3 years. It has been and still is an excruciatingly difficult and long process. As long as source code does not directly refer to the Category class but uses Logger instead, it should be compatible with both existing log4j versions, in particular 1.2.x, and future log4j versions, and in particular log4j 1.3.x. Rest of my response below. At 07:07 AM 10/29/2004, Stefano Mazzocchi wrote: Ceki, your action http://cvs.apache.org/viewcvs.cgi/logging-log4j/src/java/org/apache/log4j/Category.java?r1=1.88r2=1.89diff_format=h caused a compilation failure of the following projects: - commons-logging - velocity - ant and, as a result, caused a drop in the gump's success from 83% to 53%, for more info see: http://brutus.apache.org/gump/public/project_todos.html Now, since this is a back incompatible change, we (the gumpmeisters) would like to know: 1) if you might be willing to revert the change if you did not intend to cause such effect 2) if not, if you are willing to move the previous version of the tree into a branch so that we can migrate the dependencies to that Changes that do not allow existing client code to be compatible with both 1.2.x and 1.3.x will be reverted. However, existing client code should also make an effort not to use or refer to the Category class. I believe that as long as client code does not refer to the Category class but uses Logger instead, then both backward and forward compatibility should be achievable. 3) if not, if you are willing to work with the offended dependees to restore their success status. That goes without saying. Allow me to look more closely at the specific failures so that I can compile a precise recipe for restoring success. I think it is important that we do not panic and address each error individually. (This is an appeal to myself as much as the rest of the bunch.) 4) if not, if you have any alternative suggestion on how to move forward. please understand that we have no preference in which road the log4j project decides to go, we are only interested in giving a chance to those 322 projects that were affected by this to keep having build information. Thank you very much in advance for your cooperation. -- Stefano, doing by hand what gump should be able to do in the future. -- Ceki Gülcü For log4j documentation consider The complete log4j manual http://www.qos.ch/shop/products/eclm/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [human-assisted gump] log4j back incompatible change
Hi Craig, Apparently, since you removed the Log4JCategoryLog class, commons-logging builds fine today. Do you have a copy of yesterday's errors for commons-logging? If you do, could I please have a look at them? Thanks in advance, At 07:40 AM 10/29/2004, Craig McClanahan wrote: I can help out with over half of the gump failures. Commons Logging deprecated Log4JCategoryLog a long time ago, when Log4J deprecated Category in favor of Logger. C-L itself hasn't used Log4JCategoryLog for several releases, so this change will be transparent to the vast majority of Commons Logging users. Craig McClanahan On Fri, 29 Oct 2004 01:07:38 -0400, Stefano Mazzocchi [EMAIL PROTECTED] wrote: Ceki, your action http://cvs.apache.org/viewcvs.cgi/logging-log4j/src/java/org/apache/log4j/Category.java?r1=1.88r2=1.89diff_format=h caused a compilation failure of the following projects: - commons-logging - velocity - ant and, as a result, caused a drop in the gump's success from 83% to 53%, for more info see: http://brutus.apache.org/gump/public/project_todos.html Now, since this is a back incompatible change, we (the gumpmeisters) would like to know: 1) if you might be willing to revert the change if you did not intend to cause such effect 2) if not, if you are willing to move the previous version of the tree into a branch so that we can migrate the dependencies to that 3) if not, if you are willing to work with the offended dependees to restore their success status. 4) if not, if you have any alternative suggestion on how to move forward. please understand that we have no preference in which road the log4j project decides to go, we are only interested in giving a chance to those 322 projects that were affected by this to keep having build information. Thank you very much in advance for your cooperation. -- Stefano, doing by hand what gump should be able to do in the future. -- Ceki Gülcü For log4j documentation consider The complete log4j manual http://www.qos.ch/shop/products/eclm/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: BATCH: All dressed up, with nowhere to go...
At 11:45 AM 8/23/2004, you wrote: Dear Gumpmeisters, The following 13 notifys should have been sent *** G U M P [snip] [EMAIL PROTECTED]: jetty/jetty-plus failed *** G U M P [snip] Regarding the jetty-plus build failure, I would like to note that as far as log4j tests are concerned, we are not interested in the jetty API but its ability to act as a web-server with JNDI support. From our perspective, it would be sufficient to link to jetty-plus.jar without building jetty afresh each day. In other words, we are more interested in gumps ability to run test scripts regularly on different platforms rather then its ability to track API changes and resolve compatibility issues. These are related but distinct goals. Just my 2c. -- Ceki Gülcü - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jetty plus required
That was awfully quick! Thanks. At 03:50 PM 8/18/2004, you wrote: On Wed, 18 Aug 2004, Ceki [iso-8859-1] Gülcü wrote: Would it be possible to tell gump to build jetty plus? I've modified the jetty.xml module to describe jetty-plus. Soon Gump will start attempting to build a jetty-plus project. Hopefully, soon after that, we'll get a sense of what our success will be. regards Adam -- Ceki Gülcü For log4j documentation consider The complete log4j manual ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [GUMP@brutus]: logging-log4j/logging-log4j failed
Problem solved. It appears that the org.xml.sax classes included in
the JDK differ from those of the original.
Dancing around the discrepancy is not too difficult once you know that
it exists. Thanks to gump for pointing out the difference.
How inconsiderate on the part of Sun to modify an existing API and
bundle the modified version with the JDK.
At 10:22 AM 5/27/2004, Ceki Gülcü wrote:
Hello all,
It appears that log4j is failing to compile on brutus. It compiles
fine on my side using JDK 1.4, 1.3 or 1.2. The problem appears to be
linked to the signature of the resolveEntity() method in
org.xml.sax.helpers.DefaultHandler. Contrary to what is declared by
the resolveEntity method in EntityResolver interface, the
resolveEntity method in the DefaultHandler is not declared as throwing
an IOException. (It masks the IOException.)
Here is the code from the org.apache.joran.Interpreter class which
fails to compile on Brutus.
// Joran builds as part of log4j.
package org.apache.joran;
public class Interpreter extends DefaultHandler {
/**
* If a specific entityResolver is set for this Interpreter instance, then
* we use it to resolve entities. Otherwise, we use the default
implementation
* offered by the super class.
*/
public InputSource resolveEntity(String publicId, String systemId)
throws SAXException {
if(entityResolver == null) {
return super.resolveEntity(publicId, systemId);
} else {
try {
return entityResolver.resolveEntity(publicId, systemId);
} catch(IOException ioe) {
// fall back to the default implementation
return super.resolveEntity(publicId, systemId);
}
}
}
}
Which version of the org.xml.sax package is used on brutus? I am a bit
at a loss here.
Thanks in advance for shedding some light on to the matter.
At 10:38 PM 5/26/2004, [EMAIL PROTECTED] wrote:
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact folk at [EMAIL PROTECTED]
Project logging-log4j has an issue affecting its community integration.
This issue affects 213 projects.
Project State : 'Failed', Reason 'Build Failed'
The following are affected:
- ant-embed-optional : Java based build tool
- avalon : Avalon's main repository.
[snip]
Full details are available at:
http://brutus.apache.org:8080/gump/logging-log4j/logging-log4j/index.html
That said, some snippets follow:
The following annotations were provided:
-INFO- Failed with reason build failed
-INFO- Enable debug output, due to build failure.
The following work was performed:
http://brutus.apache.org:8080/gump/logging-log4j/logging-log4j/gump_work/build_logging-log4j_logging-log4j.html
Work Name: build_logging-log4j_logging-log4j (Type: Build)
State: Failed
Elapsed: 0 hours, 0 minutes, 4 seconds
Command Line: java -Djava.awt.headless=true
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xml-apis.jar
org.apache.tools.ant.Main
-Dgump.merge=/usr/local/gump/public/gump/work/merge.xml
-Dbuild.sysclasspath=only -Dversion=20040526 jar
[Working Directory: /usr/local/gump/public/workspace/logging-log4j]
CLASSPATH :
/usr/local/j2sdk1.4.2_04/lib/tools.jar:/usr/local/gump/public/workspace/logging-log4j/dist/classes:/usr/local/gump/public/workspace/ant/dist/lib/ant-stylebook.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-xalan2.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-servletapi-4/lib/servlet.jar:/usr/local/gump/packages/jms1.0.2/lib/jms.jar:/usr/local/gump/packages/jmx-1_2-ri/lib/jmxri.jar:/usr/local/gump/packages/jmx-1_2-ri/lib/jmxtools.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/packages/javamail-1.3/mail.jar--
---
Buildfile: build.xml
init:
jndiCheck:
build.core:
[mkdir] Created dir:
/usr/local/gump/public/workspace/logging-log4j/dist/classes
[javac] Compiling 220 source files to
/usr/local/gump/public/workspace/logging-log4j/dist/classes
[javac]
/usr/local/gump/public/workspace/logging-log4j/src/java/org/apache/joran/Interpreter.java:301:
unreported exception java.io.IOException; must be caught or declared to
be thrown
[javac] return super.resolveEntity(publicId, systemId);
[javac] ^
[javac]
/usr/local/gump/public/workspace/logging-log4j/src/java/org/apache/joran/Interpreter.java:307:
unreported exception java.io.IOException
Re: [GUMP@brutus]: logging-log4j/logging-log4j failed
The solution to this curious problem was to directly implement the
DefaultHandler.resolveEntity functionality which is simply to return
null. Trying to be OO and calling DefaultHandler.resolveEntity can
quickly develop to become a monstrous headache as the signature of
DefaultHandler.resolveEntity is variable.
At 10:52 AM 5/27/2004, Ceki Gülcü wrote:
Problem solved. It appears that the org.xml.sax classes included in
the JDK differ from those of the original.
Dancing around the discrepancy is not too difficult once you know that
it exists. Thanks to gump for pointing out the difference.
How inconsiderate on the part of Sun to modify an existing API and
bundle the modified version with the JDK.
At 10:22 AM 5/27/2004, Ceki Gülcü wrote:
Hello all,
It appears that log4j is failing to compile on brutus. It compiles
fine on my side using JDK 1.4, 1.3 or 1.2. The problem appears to be
linked to the signature of the resolveEntity() method in
org.xml.sax.helpers.DefaultHandler. Contrary to what is declared by
the resolveEntity method in EntityResolver interface, the
resolveEntity method in the DefaultHandler is not declared as throwing
an IOException. (It masks the IOException.)
Here is the code from the org.apache.joran.Interpreter class which
fails to compile on Brutus.
// Joran builds as part of log4j.
package org.apache.joran;
public class Interpreter extends DefaultHandler {
/**
* If a specific entityResolver is set for this Interpreter instance, then
* we use it to resolve entities. Otherwise, we use the default
implementation
* offered by the super class.
*/
public InputSource resolveEntity(String publicId, String systemId)
throws SAXException {
if(entityResolver == null) {
return super.resolveEntity(publicId, systemId);
} else {
try {
return entityResolver.resolveEntity(publicId, systemId);
} catch(IOException ioe) {
// fall back to the default implementation
return super.resolveEntity(publicId, systemId);
}
}
}
}
Which version of the org.xml.sax package is used on brutus? I am a bit
at a loss here.
Thanks in advance for shedding some light on to the matter.
At 10:38 PM 5/26/2004, [EMAIL PROTECTED] wrote:
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact folk at [EMAIL PROTECTED]
Project logging-log4j has an issue affecting its community integration.
This issue affects 213 projects.
Project State : 'Failed', Reason 'Build Failed'
The following are affected:
- ant-embed-optional : Java based build tool
- avalon : Avalon's main repository.
[snip]
Full details are available at:
http://brutus.apache.org:8080/gump/logging-log4j/logging-log4j/index.html
That said, some snippets follow:
The following annotations were provided:
-INFO- Failed with reason build failed
-INFO- Enable debug output, due to build failure.
The following work was performed:
http://brutus.apache.org:8080/gump/logging-log4j/logging-log4j/gump_work/build_logging-log4j_logging-log4j.html
Work Name: build_logging-log4j_logging-log4j (Type: Build)
State: Failed
Elapsed: 0 hours, 0 minutes, 4 seconds
Command Line: java -Djava.awt.headless=true
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xml-apis.jar
org.apache.tools.ant.Main
-Dgump.merge=/usr/local/gump/public/gump/work/merge.xml
-Dbuild.sysclasspath=only -Dversion=20040526 jar
[Working Directory: /usr/local/gump/public/workspace/logging-log4j]
CLASSPATH :
/usr/local/j2sdk1.4.2_04/lib/tools.jar:/usr/local/gump/public/workspace/logging-log4j/dist/classes:/usr/local/gump/public/workspace/ant/dist/lib/ant-stylebook.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-xalan2.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-servletapi-4/lib/servlet.jar:/usr/local/gump/packages/jms1.0.2/lib/jms.jar:/usr/local/gump/packages/jmx-1_2-ri/lib/jmxri.jar:/usr/local/gump/packages/jmx-1_2-ri/lib/jmxtools.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/packages/javamail-1.3/mail.jar--
---
Buildfile: build.xml
init:
jndiCheck:
build.core:
[mkdir] Created dir:
/usr/local/gump/public/workspace/logging-log4j/dist/classes
[javac] Compiling 220 source files to
/usr/local/gump/public/workspace/logging-log4j/dist/classes
[javac]
/usr/local/gump/public/workspace/logging-log4j/src/java/org/apache/joran
Re: [GUMP@brutus]: avalon-excalibur/excalibur-logger failed
At 10:50 PM 5/18/2004, Niclas Hedhman wrote: On Wednesday 19 May 2004 03:19, Adam R. B. Jack wrote: I posted to avalon-dev as you posted here. Log4j changed underneath you, I suspect... [javac] import org.apache.log4j.spi.RootCategory; [javac] location: class org.apache.avalon.excalibur.logger.log4j.Log4JConfAdapter [javac] super( new Hierarchy( new RootCategory( Level.ALL ) ) ); As of some weeks ago, this class was not marked deprecated :o( And the replacement doesn't exist in the 1.2.8 distro. What are we supposed to do? Ceki, isn't this a bit 'sudden' ??? You are absolutely right. My bad. I am looking into this right now. Cheers Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ -- Ceki Gülcü For log4j documentation consider The complete log4j manual ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [GUMP@lsd]: ws-axis/ws-axis failed
At 12:04 AM 5/19/2004, robert burrell donkin wrote: if the upcoming commons-logging release contained this patch then the impact on all those downstream projects would be huge. log4j CVS HEAD is no longer binary compatible with the last release version. everyone using the existing release of log4j with the next commons-logging release (which is coming soon) would find that their logging was broken. i'm not willing to apply a patch that makes common-logging incompatible with the last released version of log4j. i'd also be willing to veto any one who commits such a change. there are other ways around this issue but it's going to take a little time. I think there is a slight misunderstanding here. Mario's proposed patch in itself will not break backward compatibility with log4j 1.2.8 (the last official release). However, applying it will not ensure runtime compatibility with future log4j versions, although will result in compile time compatibility. IMHO, you could safely apply the patch. I am currently working on keeping runtime compatibility as well. i make no apologies for putting the needs of the downstream users of commons-logging higher than the need to fix this problem hastily. i have been looking into this tonight and i've posted a proposal solution to the mailing list. if no one can find a hole in it, i'll probably have something in place tomorrow. Your proposal is reasonable although it might be unnecessary depending on the results of work on our side. - robert -- Ceki Gülcü For log4j documentation consider The complete log4j manual ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Existence of a database?
Thanks everyone for answering. At 01:27 PM 5/19/2004, Eric Pugh wrote: I find that depending on an external database makes the unit tests very brittle.. Unless you are specifically testing something that requires a specific type of database, I find that using hsqldb or axion works fine.. I agree that having tests run all several databases makes things complicated and brittle. We currently have tests unit tests that work on mysql and postgres. The Junit test case plus the related log4j config files import a DB specific property file at runtime if it is available on the local system, otherwise the test for that db are skipped. Adding tests for other databases should be easy, except that it would result in duplication of targets in the Ant build file. The build file is available here: http://cvs.apache.org/viewcvs.cgi/logging-log4j/tests/build.xml?rev=1.54 The relevant part is reproduced below. !-- = -- !-- = DB Tests === -- !-- = -- !-- These tests follow the same pattern. They will be run if a property file defining access as well as necessary class files are available. Otherwise, the test is skipped. -- target name=mysqlCheck condition property=mysql-present and available file=./input/db/mysql.properties / available classname=com.mysql.jdbc.Driver classpath refid=tests.classpath/ /available /and /condition /target target name=mysql depends=mysqlCheck, build if=mysql-present delete file=./input/db/db.properties/ echo message=MySQL available/ copy file=./input/db/mysql.properties tofile=./input/db/db.properties/ junit printsummary=yes fork=no haltonfailure=yes sysproperty key=runLen value=100/ classpath refid=tests.classpath/ formatter type=plain usefile=false/ test name=org.apache.log4j.db.FullCycleDBTest / /junit /target target name=postgresqlCheck condition property=postgresql-present and available file=./input/db/postgresql.properties / available classname=org.postgresql.Driver classpath refid=tests.classpath/ /available /and /condition /target target name=postgresql depends=postgresqlCheck, build if=postgresql-present delete file=./input/db/db.properties/ echo message=PostgreSQL available/ copy file=./input/db/postgresql.properties tofile=./input/db/db.properties/ junit printsummary=yes fork=no haltonfailure=yes sysproperty key=runLen value=100/ classpath refid=tests.classpath/ formatter type=plain usefile=false/ test name=org.apache.log4j.db.FullCycleDBTest / /junit /target As you can see there is almost complete duplication of the tasks for mysql and postgresql. I wonder if it possible to group tasks and invoke them as a function or a method call. Anyway, I am digressing. Thanks for your help. Eric -Original Message- From: Stefan Bodewig [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 19, 2004 9:24 AM To: [EMAIL PROTECTED] Subject: Re: Existence of a database? On Sat, 15 May 2004, Ceki Gülc [EMAIL PROTECTED] wrote: Could we assume that gump machines have a database that these test cases can connect to? You can savely assume that hsqldb is around[1] but not installed in any way. I.e. you could make your tests depend on hsqldb and they'd work in Gump. Even if some Gump machine may use some kind of DB in the future (to gather historical data or whatever else we come up with), there'll be no guarantee that all machines have one. Stefan Footnotes: [1] http://brutus.apache.org/gump/public/hsqldb/hsqldb/index.html - 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] -- Ceki Gülcü For log4j documentation consider The complete log4j manual ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging][PROPOSAL] a solution to incompatibility between log4j versions
At 07:08 PM 5/19/2004, Adam R. B. Jack wrote: 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? As far as I am aware, no. regards, Adam -- Ceki Gülcü For log4j documentation consider The complete log4j manual ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [GUMP@lsd]: ws-axis/ws-axis failed
Adam,
Given that you have supplied a corrective patch 5 days ago, and that
no commons-logging developer has picked it up, do you think pretending
the problem does not exist is the wisest approach?
Gump has proved itself by catching the problem. We may be able to fool
gump but the problem is going to surface at runtime, unless of course
it gets fixed before.
At 05:06 PM 5/17/2004, Adam R. B. Jack wrote:
-the issue is not that we have broken something, but that commons logger
and log4j are no longer compatible at run time in Gump, at least for us.
Maybe its a classpath thing, maybe it's something else.
Interesting, I hadn't expected this, but it is interesting.
Gump noticed (a week ago?) that a change to log4j (a final removal after a 2
year deprecation) cause C-L no longer to compile. This was reported, and
even a patch added to Bugzilla for C-L, however this patch wasn't added (I
need to check if it has yet).
Anyhow to try to get past this we let C-L temporarily depend upon log4j-1.2
(also Gumped) and this seemed to work. Unfortunately your environment
explicitly states log4j ('cos it had to, see next) so you get the runtime
problem. [Jar Hell I'd like to work on via depot-version, but that is a
separate topic.]
So we have a few courses of action, the best being C-L committing the patch
to become compatible w/ log4j today up to two years ago (as I read it).
Also, I think we ought look at C-L setting it's optional dependencies as
runtime, and you no longer explicitly depending upon log4j, but depending
upon commons-logging inherit=runtime. Hopefully that will Gump you on the
correct C-L dependency.
Stefan, anything to add?
regards,
Adam
--
Ceki Gülcü
For log4j documentation consider The complete log4j manual
ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Existence of a database?
Hello, In log4j we have components which write or read from a DB with accompanying test cases. Could we assume that gump machines have a database that these test cases can connect to? I am just curious... -- Ceki Gülcü For log4j documentation consider The complete log4j manual ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [GUMP@lsd]: logging-log4j/logging-log4j failed
Hello folks,
We have just received this very recent log4j failure. It is due to a new
dependency on the servlet-api i.e. servlet-api.jar. What should/can we do
to fix this?
Thanks in advance for your help,
At 03:22 AM 3/31/2004 +, [EMAIL PROTECTED] wrote:
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 logging-log4j has an issue affecting its community integration.
This issue affects 1099 projects. The current state is 'Failed', for
reason 'Build Failed'
Full details are available at:
http://lsd.student.utwente.nl/gump/logging-log4j/logging-log4j.html,
however some snippets follow:
- - - - - -- -- G U M P
Gump provided these annotations:
- Error - Failed with reason build failed
- Info - Enable debug output, due to build failure.
- - - - - -- -- G U M P
Gump performed this work:
Work Name: build_logging-log4j_logging-log4j (Type: Build)
State: Failed
Elapsed: 0 hours, 0 minutes, 9 seconds
Command Line: java
-Xbootclasspath/p:/data3/gump/xml-xerces2/java/build/xercesImpl.jar:/data3/gump/xml-xerces2/java/build/xml-apis.jar
org.apache.tools.ant.Main
-Dgump.merge=/data3/gump/gump-install/work/merge.xml
-Dbuild.sysclasspath=only -Dversion=20040331 jar
[Working Directory: /data3/gump/logging-log4j]
-
Buildfile: build.xml
[property] dropping /data3/gump/logging-log4j/dist/classes from path as
it doesn't exist
init:
build.core:
[mkdir] Created dir: /data3/gump/logging-log4j/dist/classes
[javac] Compiling 211 source files to
/data3/gump/logging-log4j/dist/classes
[javac]
/data3/gump/logging-log4j/src/java/org/apache/log4j/selector/servlet/ContextDetachingSCL.java:29:
package javax.servlet does not exist
[javac] import javax.servlet.ServletContext;
[javac] ^
[javac]
/data3/gump/logging-log4j/src/java/org/apache/log4j/selector/servlet/ContextDetachingSCL.java:30:
package javax.servlet does not exist
[javac] import javax.servlet.ServletContextEvent;
[javac] ^
[javac]
/data3/gump/logging-log4j/src/java/org/apache/log4j/selector/servlet/ContextDetachingSCL.java:31:
package javax.servlet does not exist
[javac] import javax.servlet.ServletContextListener;
[javac] ^
[javac]
/data3/gump/logging-log4j/src/java/org/apache/log4j/selector/servlet/ContextDetachingSCL.java:46:
cannot resolve symbol
[javac] symbol : class ServletContextListener
[javac] location: class
org.apache.log4j.selector.servlet.ContextDetachingSCL
[javac] public class ContextDetachingSCL implements
ServletContextListener {
[javac] ^
[javac]
/data3/gump/logging-log4j/src/java/org/apache/log4j/selector/servlet/ContextDetachingSCL.java:55:
cannot resolve symbol
[javac] symbol : class ServletContextEvent
[javac] location: class
org.apache.log4j.selector.servlet.ContextDetachingSCL
[javac] public void contextDestroyed(ServletContextEvent sce) {
[javac]^
[javac]
/data3/gump/logging-log4j/src/java/org/apache/log4j/selector/servlet/ContextDetachingSCL.java:83:
cannot resolve symbol
[javac] symbol : class ServletContextEvent
[javac] location: class
org.apache.log4j.selector.servlet.ContextDetachingSCL
[javac] public void contextInitialized(ServletContextEvent sce) {
[javac] ^
[javac]
/data3/gump/logging-log4j/src/java/org/apache/log4j/selector/servlet/ContextDetachingSCL.java:84:
cannot resolve symbol
[javac] symbol : class ServletContext
[javac] location: class
org.apache.log4j.selector.servlet.ContextDetachingSCL
[javac] ServletContext sc = sce.getServletContext();
[javac] ^
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -deprecation for details.
[javac] 7 errors
BUILD FAILED
/data3/gump/logging-log4j/build.xml:214: Compile failed; see the compiler
error output for details.
Total time: 7 seconds
-
To subscribe to this information via syndicated feeds:
RSS: http://lsd.student.utwente.nl/gump/logging-log4j/logging-log4j.rss |
Atom: http://lsd.student.utwente.nl/gump/logging-log4j/logging-log4j.atom
--
Gump http://gump.apache.org/
[lsd]
--
Ceki Gülcü
For log4j documentation consider The complete log4j manual
ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
