Thank very much for all this answers.

[...]

[...]

You're right. But I'm still wondering if it may be a good solution in
a peculiar context... I explain this (perhaps not so) peculiar context

- I am using chained SAX Filter.

- Each filter I design to inherit from
 org.xml.sax.helpers.XMLFilterImpl.

- The XMLFilterImpl super-class is the only one to hold a reference to
 the next filter in the pipeline, so that the subclass didn't need to
 deal with it. When my sub-class want to throw a SAX callback to the
 next filter, I just need to call the callback on the superclass. For
 instance, let's say I am in the subclass and I want to throw to the
 next filter all the start element with local name = "foo" :

 public void startElement (String uri,
               String localName,
               String qName,
               Attributes atts)
   throws SAXException {
       if (localName.equals("foo") {
         super.startElement(uri, localName, qName, atts);
       }
 }

So the whole pipeline look like :

            |----------|       |----------|        |----------|
            |XMLFilter |\      |XMLFilter |\       |XMLFilter |\      
            |----------| \     |----------| \      |----------| \      
                  |       \          |       \                   \        
sax stream   |----------|   \   |----------|   \    |----------|   \    
------------>|MyFilter1 |    -->|MyFilter1 |    --> |MyFilter1 |    -->etc...
            |----------|       |----------|        |----------|        

(nice, isn't it ?)

- Moreover, what is greatly useful with this design, is that the
 subclass need only to implement the callbacks it want to modify --
 all the callbacks not implemented in the subclass are received by
 the XMLFilter superclass and, then, thrown to the next filter in the
 pipeline. This allows a very economic way of writing filters.

- I want to "reverse" the /default behaviour/ of the superclass. I
 want that, by default, that the superclass do /not/ throw the
 callbacks to the next filter, and that the subclass explicitly
 request for it when it want a callback to be thrown. This is more
 economic in the kind of situations of much callbacks are to be
 discarded, but few of them.

So I plan to write an abstract class sitting between the XMLFilterImpl
and my subclass :

----------------------------------------

public abstract class *AbstractBaseFilter*
 extends *XMLFilterImpl*
 implements [other stuff] {

 private boolean *discardCallbacks* = false;

 /**
  * @param discardCallbacks
  * When a subclass has turn this property to <code>false</code>
  * it needs to reach directly the XMLFilter on top of this class for
  * throwing callbacks further in the pipeline. If it sends the events
  * to its direct superclass (this), they will be silently discarted,
  * according to the requested behaviour. For reaching this
  * XMLFilter, it may ask for a reference using {@link
  * #???}, which return the reference of the superclass.
  *
  * <code>true</code> the received callback are thrown to the
  * super class.
  *
  * <code>false</code> (default) the received callback are not
  * thrown to the super class.
  */
 protected AbstractBaseFilter(boolean discardCallbacks) {
   this.discardCallbacks = discardCallbacks;
 }

 // Overriding ContentHander callback

 public void *startDocument* () throws SAXException {
   if (!discardCallbacks) {
     super.startDocument ();
   }
 }

}

----------------------------------------

The subclass may turn *discardCallbacks* to true or false according to
the wished default behaviour of its superclass.

Now I need, in this subclass, a method allowing the subclass to reach
directly the XMLFilterImpl superclass, in ordre when it set
*discardCallbacks* to true to throw events in the pipeline. That's why
I tried :

 protected XMLFilter getXMLFilter () {
   return (XMLFilter) this;
 }

I may call, from the subclass, the getContentHandler() of the
XMLFilterImpl, for reaching the next filter in the pipeline, but it
breaks the principle, in this design, that the subclass must not deal
directly with the next filter (if I understand correctly).

Do you think this is poorly designed ?

According to the various answer to my original post, should I rather
implement in AbstractBaseFilter new methods throwing /anyway/ the
content, like :

----

 public void *startDocument* () throws SAXException {
   if (!discardCallbacks) {
     super.startDocument ();
   }
 }

 public void forceStartDocument* () throws SAXException {
     super.startDocument ();
 }

----

But I looks poorly designed to, since all methods are duplicated.

I may imagine too that the sublcass directly deal with
discardCallbacks, if I declare the variable protected; for instance,
when it want to throw something :

discardCallbacks = false;
super.startDocument();
discardCallbacks = true;

But it seems to me very error prone to frequently change the value of
*discardCallbacks*.

Thanks for your advice.

SL