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
communication.
> 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.
>
+1
> 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.
Carsten
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
