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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
