Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Message-ID: <3C48A03C.6060305@apache.org>
Date: Fri, 18 Jan 2002 17:22:52 -0500
From: Berin Loritsch <bloritsch@apache.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:0.9.7) Gecko/20011221
MIME-Version: 1.0
To: "avalon-dev@jakarta.apache.org" <avalon-dev@jakarta.apache.org>,
        "cocoon-dev@xml.apache.org" <cocoon-dev@xml.apache.org>
Subject: Source Resolver Classes And JaxpParser
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

I looked into the SourceResolver code in Excalibur as I wanted to incorporate
its use into my Container abstraction code.  I believe that these components are indicative
of a greater issue in Cocoon.  It is the fact that these components are so intertwined
I have to have several support Components in my initial ComponentManager for the system.
I find this is not optimal.

Let's look for ways of optimizing its use, and out of this will come practical use tips
and other such things.

The Container abstraction code is designed to have a simple single point of entry for
a Container.  A Container has the concept of a context directory (so the "context:"
protocol can be easily merged), and each Container manages its components.  This
can help in simplifying Cocoon's code, as there is really a container hierarchy.
This is in practice as well as in theory.  There is the root Container (Cocoon)
that implements the Processor interface.  Each Sitemap represents a new Container
that implements the Processor interface.  Each Container can have a unique mapping
of Components, etc.  This provides a mechanism to keep each context directory
distinct for the sitmaps.

The issues I see in SourceResolver are these:

1) SourceResolver and SourceFactory are full fledged Components.  The SourceFactory is
    used strictly by the Resolver.  Therefore, the SourceFactory should not be a full
    component.  It is only a helper class to the SourceResolver.

2) The Source interface only permits one-way communication.  In Excalibur, there is more
    than only reading the "Source".  This is why the Resource object is better.

The issues I see in Parser are these:

3) The Parser interface is fine, but the two implementations are not.  They each implement
    the ErrorHandler interface directly.  The actions of those ErrorHandlers are not only
    constant, the are essentially the same.  It would be better to have an outside
    ErrorHandler object that both of those implementations used.  The same instance of
    the ErrorHandler object can be used accross as many threads as is necessary.

4) There is no EntityResolver implementation available


As a general comment, when I see Role names like this:

org.apache.cocoon.components.hsqldb.Server, I immediately recoil.  My friends, this is not
a component.

When you are writing a Component's interface, don't take the easy road and slap a wrapper
on whatever code you want.  Take some time and consider how a Component is meant to interact
with other components in a system.  As much as possible, write components that do not have
to maintain conversational state.  Sometimes this is not possible, but really try to think
about it.

BTW, Don't implement Configurable if you aren't going to use the Configuration object!

Cocoon does need to inventory their components, and if Configurable is only being used as
a wrapper for a Parameters object, implement Parameterizable.  I don't like seeing this:

     public void configure(Configuration config)
     throws ConfigurationException
     {
         // set the base URL to the current directory
         try
         {
             this.userDirectory = new File(System.getProperty("user.dir")).toURL();
             if ( this.getLogger().isDebugEnabled() )
             {
                 this.getLogger().debug("SourceResolver: Using base directory: " + this.userDirectory);
             }
         }
         catch (MalformedURLException mue)
         {
             throw new ConfigurationException("Malformed URL for user.dir", mue);
         }
         this.baseURL = this.userDirectory;
     }

If you don't need a configuration object, but need to perform some initialization,
use Initializable.


If I am going to use the SourceResolver or JaxpParser in the managed Container code (which
handles the management of config files and everything), I need to use ThreadSafe components.
I am going to change these components even more to make them ThreadSafe.  In the case of
SourceResolver, that means changing it's interface, and removing ResourceFactory as a component.
We also need a "context:" uri handler as it has meaning even outside the Servlet context.

Avalon needs the "context:" and "resource:" uri handlers, so if there are any takers, lets
get it implemented (I couldn't see where it was done already).


-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin


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