Ricardo Rocha wrote:
> I propose we define a new (Avalon?) interface that generalizes
> RoleUtils:
>
> public interface RoleInfo {
> public String lookup(String shorthandName);
> public Iterator shorthandNames();
> public String defaultClass(String role);
> }
>
> of which today's RoleUtils would be but a specific implementation.
>
> Thus, any new framework wishing to reuse these terrific meta-components
> would simply need supply its own RoleInfo to leverage this
> infrastructure.
Berin Loritsch wrote:
> That sounds like a good plan. I will try to see where it would fit in the
> Avalon Framework. It would be perfect for replacing the
> DefaultComponentManager implementation in Avalon--but the Handler and
> Factory implementations may need a subpackage. I am copying this message
> to the Avalon List.
Cool!
I know the following is pertinent to Avalon more than to C2, but much of the
C2 infrastructure is so generic that parts of it could be eventually moved to
Avalon or even become separate subdistributions (e.g. the XML compiler,
some of the org.apache.cocoon.xml interfaces/abstract classes, etc)
Thinking bigger, "RoleInfo" actually embodies the notion of "Avalon-based
framework", a concept that might well deserve first-class citizen status in
the Avalon set of abstractions.
The collection of roles defined by an Avalon-based framework is simmetrical
to the notion of an OO interface: for the same framework, there could be one
or more "implementations", each differing by the actual role-implementing
classes and their respective configurations.
Using this metaphor, we could say that each C2's sitemap configuration is
actually an "implementation" of the C2 framework interface (as currently
defined in RoleUtils)
If we had a "framework management" framework in Avalon, things like sitemap
compilation could be seen as _services_ provided by the metaframework (along
with configuring component managers/selectors via role info as discussed)
A bit off-topic:
This brings to mind a technology that I've found intriguing
in regard to component-oriented programming: supercompilation
(http://www.supercompilers.com/scpj.htm)
The basic idea behind supercompilation is avoiding the runtime overhead of
object composition by optimizing the composition configuration, generating
it as source code and then using the language's standard compiler (with its
own optimizations).
This is pretty close to what C2 does with sitemap compilation!
Granted, we're not using the aggressive compisition pattern analysis and
optimization techniques advocated by Turchin, but we're headed in the right
direction. In particular, the addition of code generation capabilities to"
costly" components like selectors and matchers is a powerful step.
Ricardo (wbfb)
PS: I'm inlining Bibop's default implementation of RoleInfo which can be
populated by hand (a la RoleUtils) or by means of a configuration.
================================================================
import java.util.Map;
import java.util.Iterator;
import java.util.Hashtable;
import java.util.Collections;
import org.apache.avalon.configuration.Configurable;
import org.apache.avalon.configuration.Configuration;
import org.apache.avalon.configuration.ConfigurationException;
public class DefaultRoleInfo implements RoleInfo, Configurable {
private Map shorthands = new Hashtable();
private Map classNames = new Hashtable();
public String lookup(String shorthandName) {
return (String) this.shorthands.get(shorthandName);
}
public Iterator shorthandNames() {
return Collections.unmodifiableMap(this.shorthands).keySet().iterator();
}
public String defaultClass(String role) {
return (String) this.classNames.get(role);
}
public void addRole(String name, String shorthand, String defaultClassName)
{
this.shorthands.put(shorthand, name);
if (defaultClassName != null) {
this.classNames.put(name, defaultClassName);
}
}
public void configure(Configuration conf) throws ConfigurationException {
Configuration[] roles = conf.getChildren("role");
for (int i = 0; i < roles.length; i++) {
String name = roles[i].getAttribute("name");
String shorthand = roles[i].getAttribute("shorthand");
String defaultClassName = roles[i].getAttribute("default-class", null);
this.addRole(name, shorthand, defaultClassName);
}
}
}
================================================================
On Monday 19 March 2001 20:37, Berin Loritsch wrote:
> Ricardo Rocha wrote:
> > Great work, Berin!
> >
> > I've been using these component manager in a different Avalon-based
> > project and your improvements came at the right time, thanks!
> >
> > These components are so well thought out and generic that I think they
> > should be moved to Avalon: Almost nothing in them is C2-specific.
> >
> > The _only_ C2 dependencies are the use of the RoleUtils and ClassUtil
> > classes.
> >
> > ClassUtils.loadClass just does a Class.forName, so this dependency can be
> > easily counted out if we want to generalize the components.
> >
> > RoleUtils, on the other hand, is used to pass the manager/selector info
> > about the Cocoon-specific roles.
> >
> > This is cool if Cocoon was the only environment where these highly
> > generic components are used, but what if we want to use them for another
> > framework (as we're doing at Bibop Research)?
> >
> > I propose we define a new interface (Avalon?) that generalizes RoleUtils:
> >
> > public interface RoleInfo {
> > public String lookup(String shorthandName);
> > public Iterator shorthandNames();
> > public String defaultClass(String role);
> > }
> >
> > of which today's RoleUtils would be but a specific implementation.
> >
> > Thus, any new framework wishing to reuse these terrific meta-components
> > would simply need supply its own RoleInfo to leverage this
> > infrastructure.
> >
> > This is what we're doing for Bibop's components and a new test XSP
> > framework.
> >
> > What do you think?
>
> That sounds like a good plan. I will try to see where it would fit in the
> Avalon Framework. It would be perfect for replacing the
> DefaultComponentManager implementation in Avalon--but the Handler and
> Factory implementations may need a subpackage. I am copying this message
> to the Avalon List.
>
> > Ricardo
> >
> > On Monday 19 March 2001 15:13, Berin Loritsch wrote:
> > > I believe I fixed the issues with Cocoon reusing Parser objects in a
> > > high transaction environment. The result was a serious rearchitecture
> > > of the ComponentManager and Selector objects so that they use
> > > ComponentFactories to create and prepare objects. Also, with some
> > > inventive approaches, I made sure that the Component is always returned
> > > to the correct pool. That way we can have multiple instances of say,
> > > the SVG serializers with different configurations, and the Components
> > > will be returned to the propper pools.
> > >
> > > This also greatly reduced the complexity of the Component Management
> > > Infrastructure, and reduced the amount of duplicate code. As a result
> > > of the reduction in complexity, there is a real increase in speed when
> > > accessing Components. This translates to an additional 1-5
> > > milliseconds per call.
> > >
> > > Also, thanks to the hard work of Dims, Scott, and Santiago, Cocoon2 has
> > > a truly stable pipeline with real thread safety. For simple
> > > transformations like the "forms/add-department" URL in the Cocoon
> > > samples you are looking at response times as low as 90 to 250 ms under
> > > heavy load. For more complex transformations with 5 TraxTransformer
> > > stages, you are looking at 350 to 575 ms under heavy load. NOTE: All
> > > times specified are on an Athlon 750 w/256MB RAM running W2K and Sun
> > > JDK 1.3.0_01 and JVM memmory set to 256MB.
> > >
> > > All in all, I think we have an incredible piece of work here--with
> > > speeds that rival commercial offerings. Doing the same type of
> > > componentized pages in a markup based scripting language (like
> > > ColdFusion), results in 900 to 1250 ms--and is much more difficult to
> > > maintain the code.
> > >
> > > With Content Aggregation and Caching (which on my machine may not be
> > > necessary...) we will have truly Insanely Great (TM) software
> > > (appologies to Steve Jobs for ripping off his slogan). We still have
> > > Garbage Collection cycles (there are alot of Strings created and
> > > destroyed), but there impact is lessened do to the objects being
> > > smaller and us being wiser with pooled and thread-safe resources.
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, email: [EMAIL PROTECTED]
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, email: [EMAIL PROTECTED]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
