avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <cziege...@s-und-n.de>
Subject RE: Source Resolver Classes And JaxpParser
Date Mon, 21 Jan 2002 07:46:24 GMT

Berin Loritsch wrote:
> 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.

Hm, I don't agree here completly. The SourceFactory is a componet
which can theoretically live on its own without a SourceResolver.
But the real intention behind making the SourceFactory a component
is the lifecycle configuration. There are some protocols (or
SourceFactories) which need a configuration, a SourceFactory needs
a Logger, it may be ThreadSafe or Poolable etc.
To avoid reimplementing all this in the SourceResolver, I thought
of making the SourceFactory an own component. Have a look at the
Cocoon code of the SourceResolver. It reimplements many things
the component manager does already. So why reinventing the wheel?

> 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.

Well, as I stated some weeks ago, the Resource object is very heavy
and not suitable for some cases like a cvs protocol etc.
I agree that the Source object is one-way but as soon as it is
established we can think of a good way for doing the two-way

> 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

Yes, but as soon as the entity resolver of the scratchpad is finished,
it can be used as an implementation.

> <snip>
> 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.

+1, the code above is my fault - as the first implementation was actually
really configurable, but than I didn't need the configuration anymore
but forgot to change the code.
(Hey, it's scratchpad code anyway...just a joke here).
I will change this.

> 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.
+1 for the context: factory.
Why do you need a thread safe source resolver?  I thought the client
code of a component shouldn't make any assumptions about the lifetime
of a component.
And even if the source resolver is thread safe why can't the ResourceFactory
not be a component?

> 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).

When the 2.0.1 of cocoon is out, I will start to incorporate the
avalon scratchpad code into cocoon and will try to fix all the
points mentioned above.


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

View raw message