You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@gump.apache.org by Steve Loughran <st...@iseran.com> on 2004/05/17 16:26:58 UTC
Re: [GUMP@lsd]: ws-axis/ws-axis failed
Tom Jordahl wrote:
> So, do we know why the build is failing all the time?
>
> Now there seems to be at least 2 gump machines telling us that it is
> failing...
see
http://brutus.apache.org/gump/public/ws-axis/ws-axis/gump_work/build_ws-axis_ws-axis.txt
:-
"Error while processing WSDL in Wsdl2javaAntTask for
/usr/local/gump/public/workspace/ws-axis/java/samples/addr/AddressBook.wsdl"
-this points to Axis.
-But look further, look at line 1185 of JavaUtils:
log.debug(Messages.getMessage("attachEnabled") + " " +
attachmentSupportEnabled);
-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.
I am escalating this to Those Who Know.
[java] [foreach] java.lang.NoSuchMethodError:
org.apache.log4j.Logger.log(Ljava/lang/String;Lorg/apache/log4j/Priority;Ljava/lang/Object;Ljava/lang/Throwable;)V
[java] [foreach] at
org.apache.commons.logging.impl.Log4JLogger.debug(Log4JLogger.java:98)
[java] [foreach] at
org.apache.axis.i18n.ProjectResourceBundle$Context.loadBundle(ProjectResourceBundle.java:423)
[java] [foreach] at
org.apache.axis.i18n.ProjectResourceBundle.getBundle(ProjectResourceBundle.java:311)
[java] [foreach] at
org.apache.axis.i18n.ProjectResourceBundle.access$300(ProjectResourceBundle.java:52)
[java] [foreach] at
org.apache.axis.i18n.ProjectResourceBundle$Context.getParentBundle(ProjectResourceBundle.java:432)
[java] [foreach] at
org.apache.axis.i18n.ProjectResourceBundle.getBundle(ProjectResourceBundle.java:312)
[java] [foreach] at
org.apache.axis.i18n.ProjectResourceBundle.getBundle(ProjectResourceBundle.java:281)
[java] [foreach] at
org.apache.axis.i18n.MessagesConstants.<clinit>(MessagesConstants.java:32)
[java] [foreach] at
org.apache.axis.utils.Messages.<clinit>(Messages.java:36)
[java] [foreach] at
org.apache.axis.utils.JavaUtils.isAttachmentSupported(JavaUtils.java:1185)
[java] [foreach] at
org.apache.axis.encoding.DefaultTypeMappingImpl.<init>(DefaultTypeMappingImpl.java:110)
[java] [foreach] at
org.apache.axis.encoding.DefaultSOAPEncodingTypeMappingImpl.<init>(DefaultSOAPEncodingTypeMappingImpl.java:49)
[java] [foreach] at
org.apache.axis.encoding.DefaultSOAPEncodingTypeMappingImpl.createWithDelegate(DefaultSOAPEncodingTypeMappingImpl.java:44)
[java] [foreach] at
org.apache.axis.wsdl.toJava.Emitter$1.<init>(Emitter.java:702)
[java] [foreach] at
org.apache.axis.wsdl.toJava.Emitter.setTypeMappingVersion(Emitter.java:700)
[java] [foreach] at
org.apache.axis.tools.ant.wsdl.Wsdl2javaAntTask.execute(Wsdl2javaAntTask.java:232)
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: [GUMP@lsd]: ws-axis/ws-axis failed
Posted by Tomasz Pik <pi...@ais.pl>.
Steve Loughran 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.
Maybe this will help in tracking problem:
http://www.mail-archive.com/commons-dev%40jakarta.apache.org/msg40338.html
Regards,
Tomek
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: [GUMP@lsd]: ws-axis/ws-axis failed
Posted by Ceki Gülcü <ce...@qos.ch>.
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: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: [GUMP@lsd]: ws-axis/ws-axis failed
Posted by robert burrell donkin <rd...@apache.org>.
sorry, if i came over too strongly. it was the point i was trying to
emphasis (rather than take pot shots at anyone).
gump's certainly proved it's worth (once again) in this case. thanks
for all the hard work that you (and the rest of the gump community)
have put into raising gump back from the dead.
BTW gump now runs on that mandrake box (but not till completion, i
still need some more libraries). hopefully i'll be able to sort out
both logging but also beanutils, digester and struts this week.
(and then i'll hopefully be able to get back to help out on the stuff
i'd promised to look at this week :(
- robert
On 18 May 2004, at 23:18, Adam R. B. Jack wrote:
>>> Gump isn't just a build script, it is that plus the effects/outcomes
>>> of
>>> communities trying to get/stay aligned. We can't expect folks to drop
>>> what they are doing the second something comes up, it just doesn't
>>> work
>>> that way in the OSS world. Much as I might think that the C-L folks
> ought find
>>> it easy to apply the patch (and perhaps should have done the fix a
>>> year
>>> plus ago) I am not aware of the factors impacting that project, nor
>>> do I
>>> wish to judge.
>>
>> <sigh>
>
> Hey, you must've missed me saying this. ;-)
>
> "I am not aware of the factors impacting that project, nor do I
> wish to
> judge."
>
> BTW: At time of writting the above I was under the impression it was
> binary
> compatible. That has since been disproven. It might've been nice if a
> smooth
> transition had been found in the last couple of years of 'pseudo
> deprecation', but then again I return to :
>
> "I am not aware of the factors impacting that project, nor do I
> wish to
> judge."
>
> :-)
>
>> i'm not willing to apply a patch that makes common-logging
>> incompatible
> [...]
>> i make no apologies for putting the needs of the downstream users of
>> commons-logging higher than the need to fix this problem hastily.
>
> Good, 'cos if I had a vote I'd veto is also. Gump has no purpose in
> life
> other than to try to help detect and allow smoothing of API
> discontinuities
> prior to release, to reduce Jar Hell. Sure, the more Gump coverage we
> get,
> the more we can detect (hence my desire to get back to Gumping C-L
> dependencies) but users come first...
>
> regards,
>
> Adam
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
> For additional commands, e-mail: general-help@gump.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: [GUMP@lsd]: ws-axis/ws-axis failed
Posted by "Adam R. B. Jack" <aj...@trysybase.com>.
> > Gump isn't just a build script, it is that plus the effects/outcomes of
> > communities trying to get/stay aligned. We can't expect folks to drop
> > what they are doing the second something comes up, it just doesn't work
> > that way in the OSS world. Much as I might think that the C-L folks
ought find
> > it easy to apply the patch (and perhaps should have done the fix a year
> > plus ago) I am not aware of the factors impacting that project, nor do I
> > wish to judge.
>
> <sigh>
Hey, you must've missed me saying this. ;-)
"I am not aware of the factors impacting that project, nor do I wish to
judge."
BTW: At time of writting the above I was under the impression it was binary
compatible. That has since been disproven. It might've been nice if a smooth
transition had been found in the last couple of years of 'pseudo
deprecation', but then again I return to :
"I am not aware of the factors impacting that project, nor do I wish to
judge."
:-)
> i'm not willing to apply a patch that makes common-logging incompatible
[...]
> i make no apologies for putting the needs of the downstream users of
> commons-logging higher than the need to fix this problem hastily.
Good, 'cos if I had a vote I'd veto is also. Gump has no purpose in life
other than to try to help detect and allow smoothing of API discontinuities
prior to release, to reduce Jar Hell. Sure, the more Gump coverage we get,
the more we can detect (hence my desire to get back to Gumping C-L
dependencies) but users come first...
regards,
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: [GUMP@lsd]: ws-axis/ws-axis failed
Posted by robert burrell donkin <rd...@apache.org>.
On 17 May 2004, at 17:20, Adam R. B. Jack wrote:
>> 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?
>
> It isn't quite that simple, although your comments make me smile. ;-)
>
> Gump isn't just a build script, it is that plus the effects/outcomes of
> communities trying to get/stay aligned. We can't expect folks to drop
> what
> they are doing the second something comes up, it just doesn't work
> that way
> in the OSS world. Much as I might think that the C-L folks ought find
> it
> easy to apply the patch (and perhaps should have done the fix a year
> plus
> ago) I am not aware of the factors impacting that project, nor do I
> wish to
> judge.
<sigh>
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 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.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: [GUMP@lsd]: ws-axis/ws-axis failed
Posted by "Adam R. B. Jack" <aj...@trysybase.com>.
> 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?
It isn't quite that simple, although your comments make me smile. ;-)
Gump isn't just a build script, it is that plus the effects/outcomes of
communities trying to get/stay aligned. We can't expect folks to drop what
they are doing the second something comes up, it just doesn't work that way
in the OSS world. Much as I might think that the C-L folks ought find it
easy to apply the patch (and perhaps should have done the fix a year plus
ago) I am not aware of the factors impacting that project, nor do I wish to
judge.
Until the day you commit this change some folks high atop the Gump stack
were seeing activity for the first time in (perhaps) a year. This was
exciting, and good for them/us all. I waited (impatiently, 'cos good
progress was being made) a day or so for C-L to commit, but then decided
that we were loosing good momentum, for no (visally) good reason.
We don't have a way (right now) to both fail/nag C-L plus allow folks atop
to build, so I decided that the patch was in Bugzilla, the mail in archives,
the C-L folks would get to it w/o nagging. Wise long term? No. Short term, I
made the choice.
BTW: My comments on dependencies were for long run, we ought have C-L set
it's runtime dependencies (I think), to reduce metadata management issues.
We've learned something here.
> 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.
Gump is a work in progress. API changes occur. Good practices (like yours
with a two year deprecation before removal) is nicely behaved & ought fit
smoothly into Gump. That it didn't, and that we are dependent upon folks, is
both good and bad. Good, it get's attention. Bad -- that we have a
sequential problem (and folks don't get Gumped for a year).
I see a few things here I'd like to improve for Gump.
Thanks for paying attention & contributing input. I'll revert the C-L log4j
dependency on CVS HEAD log4j shortly.
regards,
Adam
Re: [GUMP@lsd]: ws-axis/ws-axis failed
Posted by Steve Loughran <st...@iseran.com>.
Ceki Gülcü wrote:
>
> 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.
>
Yes, the best action is to fix it, not to hide from it.
How about removing the workaround for gump so that commons-logging
explicitly won't build, thus raising the schedule pressure for whoever
looks after commons-logging?
-Steve
Re: [GUMP@lsd]: ws-axis/ws-axis failed
Posted by "Adam R. B. Jack" <aj...@trysybase.com>.
> 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?
It isn't quite that simple, although your comments make me smile. ;-)
Gump isn't just a build script, it is that plus the effects/outcomes of
communities trying to get/stay aligned. We can't expect folks to drop what
they are doing the second something comes up, it just doesn't work that way
in the OSS world. Much as I might think that the C-L folks ought find it
easy to apply the patch (and perhaps should have done the fix a year plus
ago) I am not aware of the factors impacting that project, nor do I wish to
judge.
Until the day you commit this change some folks high atop the Gump stack
were seeing activity for the first time in (perhaps) a year. This was
exciting, and good for them/us all. I waited (impatiently, 'cos good
progress was being made) a day or so for C-L to commit, but then decided
that we were loosing good momentum, for no (visally) good reason.
We don't have a way (right now) to both fail/nag C-L plus allow folks atop
to build, so I decided that the patch was in Bugzilla, the mail in archives,
the C-L folks would get to it w/o nagging. Wise long term? No. Short term, I
made the choice.
BTW: My comments on dependencies were for long run, we ought have C-L set
it's runtime dependencies (I think), to reduce metadata management issues.
We've learned something here.
> 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.
Gump is a work in progress. API changes occur. Good practices (like yours
with a two year deprecation before removal) is nicely behaved & ought fit
smoothly into Gump. That it didn't, and that we are dependent upon folks, is
both good and bad. Good, it get's attention. Bad -- that we have a
sequential problem (and folks don't get Gumped for a year).
I see a few things here I'd like to improve for Gump.
Thanks for paying attention & contributing input. I'll revert the C-L log4j
dependency on CVS HEAD log4j shortly.
regards,
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: [GUMP@lsd]: ws-axis/ws-axis failed
Posted by Steve Loughran <st...@iseran.com>.
Ceki Gülcü wrote:
>
> 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.
>
Yes, the best action is to fix it, not to hide from it.
How about removing the workaround for gump so that commons-logging
explicitly won't build, thus raising the schedule pressure for whoever
looks after commons-logging?
-Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: [GUMP@lsd]: ws-axis/ws-axis failed
Posted by Ceki Gülcü <ce...@qos.ch>.
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: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: [GUMP@lsd]: ws-axis/ws-axis failed
Posted by "Adam R. B. Jack" <aj...@trysybase.com>.
> -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
Re: [GUMP@lsd]: ws-axis/ws-axis failed
Posted by Tomasz Pik <pi...@ais.pl>.
Steve Loughran 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.
Maybe this will help in tracking problem:
http://www.mail-archive.com/commons-dev%40jakarta.apache.org/msg40338.html
Regards,
Tomek
Re: [GUMP@lsd]: ws-axis/ws-axis failed
Posted by "Adam R. B. Jack" <aj...@trysybase.com>.
> -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
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org