You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Niclas Hedhman <ni...@hedhman.org> on 2004/03/12 16:14:04 UTC

[Alert!] Major break in Excalibur!

Gang,

We have a big problem with Excalibur in combination with LogKit, and it has 
been completely hidden by Maven!!!!


avalon-axcalibur/logger/src/java/org/apache/avalon/excalibur/logger/factory/PriorityFilterTargetFactory.java

contains

import org.apache.log.filter.PriorityFilter;

and uses it later.

However, the PriorityFilter does NO LONGER exist in LogKit !!!

Yet, it builds... Why?

Because of the way Maven will download and use old versions of LogKit when 
compiling excalibur-logger.


Why was PriorityFilter removed?
What shall we do to restore buildability?

This is far outside my territory, but GUMP has detected this, and it should be 
rectified.

Cheers
Niclas

-- 
+---------//-------------------+
|   http://www.bali.ac         |
|  http://niclas.hedhman.org   |
+------//----------------------+

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


Re: GUMP Early Warning System requires timely fixes

Posted by Stefan Bodewig <bo...@apache.org>.
On Sat, 13 Mar 2004, Noel J. Bergman <no...@devtech.com> wrote:

> What ideas has the GUMP team come up?

Search a bit back for a [RT] thread initiated by Stefano.

We really want to do more than just report that something is broken.
We will need to keep information about "last good builds" so that we
can go back to them and start to replace dependencies from the good
set with last nights versions to identify the culprit.

> Is the plan the aforementioned use of an earlier build combined with
> notification to all downstream users about the build failure?

We haven't gone that far yet.  This should probably happen if the
situation doesn't get fixed fast enough.

Right now the focus has more been on how to identify the dependency
that is responsible for a build failure and less on how to help the
projects that cannot build because of pre-req failures.

We certainly need to address both and backtracking to a known good
state will help with both.

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org


GUMP Early Warning System requires timely fixes

Posted by "Noel J. Bergman" <no...@devtech.com>.
> FWIIW: Gump has been trying to raise awareness of [the compile
> problem in Excalibur]. It shows this error in the compile output.

Adam,

The problem for a project like James is when something is broken early in
the dependency chain, nothing after that gets the benefits.  So by the time
we get notification of a problem, it could be, and has been, 6 months or
more of API, and other, changes in code that we're dependent upon.

Not sure what the answer is, since if GUMP just switches to building against
previously successful builds, we don't get the warnings related to the code
that is changing and broken.  On the other hand, if the chain is
A->B->C->D->E-F-G, we can see that if B is broken, and F is changing, it
might be helpful to go ahead and use B' on the hope that C will still build
with it, and G can see that it is getting F'ed.  If C still doesn't build,
try D against C', etc.  It is intended for GUMP to run on a dedicated
server, so compute cycles should be available.

What ideas has the GUMP team come up?  Is the plan the aforementioned use of
an earlier build combined with notification to all downstream users about
the build failure?  At the least, if dependencies don't build for a
sufficient period of time, you should start periodically notifying
downstream users.

Any other ideas?

	--- Noel


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


GUMP Early Warning System requires timely fixes

Posted by "Noel J. Bergman" <no...@devtech.com>.
> FWIIW: Gump has been trying to raise awareness of [the compile
> problem in Excalibur]. It shows this error in the compile output.

Adam,

The problem for a project like James is when something is broken early in
the dependency chain, nothing after that gets the benefits.  So by the time
we get notification of a problem, it could be, and has been, 6 months or
more of API, and other, changes in code that we're dependent upon.

Not sure what the answer is, since if GUMP just switches to building against
previously successful builds, we don't get the warnings related to the code
that is changing and broken.  On the other hand, if the chain is
A->B->C->D->E-F-G, we can see that if B is broken, and F is changing, it
might be helpful to go ahead and use B' on the hope that C will still build
with it, and G can see that it is getting F'ed.  If C still doesn't build,
try D against C', etc.  It is intended for GUMP to run on a dedicated
server, so compute cycles should be available.

What ideas has the GUMP team come up?  Is the plan the aforementioned use of
an earlier build combined with notification to all downstream users about
the build failure?  At the least, if dependencies don't build for a
sufficient period of time, you should start periodically notifying
downstream users.

Any other ideas?

	--- Noel


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org


Re: [Alert!] Major break in Excalibur!

Posted by "Adam R. B. Jack" <aj...@trysybase.com>.
> We have a big problem with Excalibur in combination with LogKit, and it
has
> been completely hidden by Maven!!!!

FWIIW: Gump has been trying to raise awareness of it. It shows this error in
the compile output.

http://lsd.student.utwente.nl/gump/avalon-excalibur/gump_work/build_avalon-excalibur_excalibur-logger.html#Output

BTW: Because this project has been in a bad state for a number of runs, Gump
has turned on ant -debug [in case the problem to not be one of source code,
but a build failure] which makes it overly verbose. If/when we get to
compiling again, the build will revert to non-debug.

Hopefully Gump can get to a point of not being the boy who cried wolf to
Avalon, so that it can give earlier warnings to folks.

regards,

Adam


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


Re: [Alert!] Major break in Excalibur!

Posted by "Adam R. B. Jack" <aj...@trysybase.com>.
> We have a big problem with Excalibur in combination with LogKit, and it
has
> been completely hidden by Maven!!!!

FWIIW: Gump has been trying to raise awareness of it. It shows this error in
the compile output.

http://lsd.student.utwente.nl/gump/avalon-excalibur/gump_work/build_avalon-excalibur_excalibur-logger.html#Output

BTW: Because this project has been in a bad state for a number of runs, Gump
has turned on ant -debug [in case the problem to not be one of source code,
but a build failure] which makes it overly verbose. If/when we get to
compiling again, the build will revert to non-debug.

Hopefully Gump can get to a point of not being the boy who cried wolf to
Avalon, so that it can give earlier warnings to folks.

regards,

Adam


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org


RE: [Alert!] Major break in Excalibur!

Posted by Carsten Ziegeler <cz...@s-und-n.de>.
I fixed a bug in the new PriorityFilteringTarget in Logkit.
Apart from that everything seems to work ok with using
the latest logkit and logger versions. So from my side a big
+1 for starting the release procedure.

Thanks
Carsten 

> -----Original Message-----
> From: Carsten Ziegeler [mailto:cziegeler@s-und-n.de] 
> Sent: Saturday, March 13, 2004 2:25 PM
> To: 'Avalon Developers List'
> Subject: RE: [Alert!] Major break in Excalibur!
> 
> Great work, Niclas.
> 
> Thanks!
> 
> Yes, I will try the latest versions in the next days and report then.
> 
> Carsten
>  
> 
> > -----Original Message-----
> > From: Niclas Hedhman [mailto:niclas@hedhman.org]
> > Sent: Saturday, March 13, 2004 5:15 AM
> > To: Avalon Developers List
> > Subject: Re: [Alert!] Major break in Excalibur!
> > 
> > On Friday 12 March 2004 23:25, Carsten Ziegeler wrote:
> > 
> > I have fixed the Testcase problems in Avalon LogKit, comprising of;
> >   1.  NullPointerException in ContextMap.get( key ), if 
> key==null. Fix 
> > is;
> >         if( key == null ) return null;
> > 
> >   2. Formatting output different, due to the ContextMap is 
> part of the 
> > output
> >      if printContext==true in the XMLFormatter. This is by 
> default set 
> > to
> >      true, hence breaking the testcase. I just made 
> printContext=false 
> > by
> >      default, expecially since the ContextMap doesn't have a nice 
> > formatting
> >      anyway (class@hashCode).
> > 
> >   3. Added a getFormatter() method, since I think the 
> m_formatter has 
> > gone
> >      from protected to private. Method is made protected, 
> but should 
> > perhaps
> >      be public.
> > 
> >   4. Bumped Avalon-LogKit to 2.0 from 2.0-dev.
> > 
> >   5. Bumped Excalibur Logger to 1.2 from 1.1.1.
> > 
> >   6. Update Excalibur Logger to depend on LogKit 2.0
> > 
> >   7. Fixed the LogKit plugin in avalon/logging to use the
> > getFormatter()
> >      method instead of m_formatter.
> > 
> >   8. Updated avalon/logging to depend on LogKit 2.0
> > 
> > 
> > Carsten (and others who are concerned), can you verify that 
> this works 
> > as expected, and then we move on with a Proposal of a release of 
> > Avalon LogKit 2.0 as well as a Excalibur Logger 1.2  ?
> > 
> > Thanks
> > Niclas
> > --
> > +---------//-------------------+
> > |   http://www.bali.ac         |
> > |  http://niclas.hedhman.org   |
> > +------//----------------------+
> > 
> > 
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org For 
> > additional commands, e-mail: dev-help@avalon.apache.org
> > 
> > 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org For 
> additional commands, e-mail: dev-help@avalon.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


RE: [Alert!] Major break in Excalibur!

Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Great work, Niclas.

Thanks!

Yes, I will try the latest versions in the next days and report then.

Carsten
 

> -----Original Message-----
> From: Niclas Hedhman [mailto:niclas@hedhman.org] 
> Sent: Saturday, March 13, 2004 5:15 AM
> To: Avalon Developers List
> Subject: Re: [Alert!] Major break in Excalibur!
> 
> On Friday 12 March 2004 23:25, Carsten Ziegeler wrote:
> 
> I have fixed the Testcase problems in Avalon LogKit, comprising of;
>   1.  NullPointerException in ContextMap.get( key ), if 
> key==null. Fix is;
>         if( key == null ) return null;
> 
>   2. Formatting output different, due to the ContextMap is 
> part of the output
>      if printContext==true in the XMLFormatter. This is by 
> default set to
>      true, hence breaking the testcase. I just made 
> printContext=false by
>      default, expecially since the ContextMap doesn't have a 
> nice formatting
>      anyway (class@hashCode).
> 
>   3. Added a getFormatter() method, since I think the 
> m_formatter has gone
>      from protected to private. Method is made protected, but 
> should perhaps
>      be public.
> 
>   4. Bumped Avalon-LogKit to 2.0 from 2.0-dev.
> 
>   5. Bumped Excalibur Logger to 1.2 from 1.1.1.
> 
>   6. Update Excalibur Logger to depend on LogKit 2.0
> 
>   7. Fixed the LogKit plugin in avalon/logging to use the 
> getFormatter()
>      method instead of m_formatter.
> 
>   8. Updated avalon/logging to depend on LogKit 2.0
> 
> 
> Carsten (and others who are concerned), can you verify that 
> this works as expected, and then we move on with a Proposal 
> of a release of Avalon LogKit 2.0 as well as a Excalibur Logger 1.2  ?
> 
> Thanks
> Niclas
> -- 
> +---------//-------------------+
> |   http://www.bali.ac         |
> |  http://niclas.hedhman.org   |
> +------//----------------------+
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org For 
> additional commands, e-mail: dev-help@avalon.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


Re: [Alert!] Major break in Excalibur!

Posted by Niclas Hedhman <ni...@hedhman.org>.
On Friday 12 March 2004 23:25, Carsten Ziegeler wrote:

I have fixed the Testcase problems in Avalon LogKit, comprising of;
  1.  NullPointerException in ContextMap.get( key ), if key==null. Fix is;
        if( key == null ) return null;

  2. Formatting output different, due to the ContextMap is part of the output
     if printContext==true in the XMLFormatter. This is by default set to
     true, hence breaking the testcase. I just made printContext=false by
     default, expecially since the ContextMap doesn't have a nice formatting
     anyway (class@hashCode).

  3. Added a getFormatter() method, since I think the m_formatter has gone
     from protected to private. Method is made protected, but should perhaps
     be public.

  4. Bumped Avalon-LogKit to 2.0 from 2.0-dev.

  5. Bumped Excalibur Logger to 1.2 from 1.1.1.

  6. Update Excalibur Logger to depend on LogKit 2.0

  7. Fixed the LogKit plugin in avalon/logging to use the getFormatter()
     method instead of m_formatter.

  8. Updated avalon/logging to depend on LogKit 2.0


Carsten (and others who are concerned), can you verify that this works as 
expected, and then we move on with a Proposal of a release of Avalon LogKit 
2.0 as well as a Excalibur Logger 1.2  ?

Thanks
Niclas
-- 
+---------//-------------------+
|   http://www.bali.ac         |
|  http://niclas.hedhman.org   |
+------//----------------------+

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


RE: [Alert!] Major break in Excalibur!

Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Niclas Hedhman wrote:
> 
> Gang,
> 
> We have a big problem with Excalibur in combination with 
> LogKit, and it has been completely hidden by Maven!!!!
> 
> 
> avalon-axcalibur/logger/src/java/org/apache/avalon/excalibur/l
ogger/factory/PriorityFilterTargetFactory.java
> 
> contains
> 
> import org.apache.log.filter.PriorityFilter;
> 
> and uses it later.
> 
> However, the PriorityFilter does NO LONGER exist in LogKit !!!
> 
> Yet, it builds... Why?
> 
> Because of the way Maven will download and use old versions 
> of LogKit when 
> compiling excalibur-logger.
> 
> 
> Why was PriorityFilter removed?
It has been deprecated and we decided some weeks ago to remove all
deprecated code from LogKit :)


> What shall we do to restore buildability?
The LogKit has now a PriorityFilteringTarget that can be used instead. So
it's a simple renaming :)
However I avoided checking this in as this will break the maven build,
because the new LogKit version can't be downloaded.

I can commit the change if you want.

Carsten


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org