You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Berin Loritsch <bl...@apache.org> on 2002/01/18 23:22:52 UTC
Source Resolver Classes And JaxpParser
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
Re: Source Resolver Classes And JaxpParser
Posted by Berin Loritsch <bl...@apache.org>.
Michael McKibben wrote:
> I can see the use of the "resource:" protocol in Avalon, but how would the
> "context:" protocol be interpreted? In Cocoon, this would load a resource
> relative to the WAR context path (well, actually however the environment
> implementation of Context.getResource was written.) How would the
> "context:" protocol be implemented outside of Cocoon and the environment.*
> interfaces?
A Container is set up with the concept of a context and work directory
(at least in the stuff I am writing). That directory is passed to the
ContainerManager, which in turns gives it to the Container.
If no context directory is given to the container, the the context
directory defaults to the current directory.
----------------------------------------------------
Sign Up for NetZero Platinum Today
Only $9.95 per month!
http://my.netzero.net/s/signup?r=platinum&refcd=PT97
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Source Resolver Classes And JaxpParser
Posted by Michael McKibben <mi...@hihat.net>.
I can see the use of the "resource:" protocol in Avalon, but how would the
"context:" protocol be interpreted? In Cocoon, this would load a resource
relative to the WAR context path (well, actually however the environment
implementation of Context.getResource was written.) How would the
"context:" protocol be implemented outside of Cocoon and the environment.*
interfaces?
Regards,
--mike
On Fri, 18 Jan 2002, 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.
>
> 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: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Source Resolver Classes And JaxpParser
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>