hivemind-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Jakarta-hivemind Wiki] Update of "DescriptorApiRevampProposal" by KnutWannheden
Date Wed, 22 Jun 2005 12:42:36 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Jakarta-hivemind Wiki" for change
notification.

The following page has been changed by KnutWannheden:
http://wiki.apache.org/jakarta-hivemind/DescriptorApiRevampProposal

New page:
This proposal is far from complete, but I was hoping to get a discussion going before I put
too much effort into a proof of concept (or proof of failure).  The input should help me complete
this proposal.

= Problem Description =

It is currently (!HiveMind 1.1 beta 1) quite difficult and cumbersome to provide module descriptors
in formats other than XML, e.g. plain Java code.  There is of course the Groovy support, but
it has a one-to-one correspondance with the XML format, as it is implemented as a thin wrapper
(a ''Builder'' in Groovy lingua) on top of the XML processing.

The biggest problem is the many constructs in the current API which are specific to the XML
syntax.  Thus providing a different module descriptor format requires the processing implementation
to be expressed in terms of these XML specific constructs.  This task is both overly complex
and potentially forfeits implementing the processing using constructs better suited to the
job.

It is for instance currently not easy to express a module descriptor using plain Java code.

= Proposed Solution =

The approach of the proposed solution is to move to a more abstract '''Descriptor API''' and
factor the XML specifics into an XML implementation (based on this API).  Apart from the XML
shorthand notations reflected in the current API it is primarily the ''schema processing''
which I consider as XML specific.  Factoring that out will in turn also affect parts of the
'''Runtime API''' and implementation.

== Descriptor API ==
Here is an overview of the proposed Descriptor API.

{{{
public interface Module
{
    public String getId();
    public String getVersion();
}
}}}

{{{
public interface ExtensionPoint
{
    public String getId();
    public Visibility getVisibility();
    public String getSchemaId();
}
}}}

{{{
public interface Extension
{
    public String getExtensionPointId();
}
}}}

{{{
public interface ServicePoint extends ExtensionPoint
{
    public String getInterfaceName();
}
}}}

{{{
public interface Implementation extends Extension
{
    public String getServiceModel();
    public ServiceImplementationConstructor getConstructor();
}
}}}

{{{
public interface Interceptor extends Extension
{
    public String getName();
    public ServiceInterceptorConstructor getConstructor();
}
}}}

{{{
public interface ConfigurationPoint extends ExtensionPoint
{
    public Occurances getCount();
    public boolean canElementsBeMapped();
}
}}}

{{{
public interface Contribution extends Extension
{
    public ConfigurationContributionConstructor getConstructor();
}
}}}

Some important notes:
 * The described interfaces are all part of a package {{{org.apache.hivemind.descriptor}}}.
 Possibly they should all have a ''Descriptor'' suffix to avoid confusion with existing internal
interfaces.
 * The link between a module and its constituents (i.e. extension points and extensions) is
established using a visitor pattern.  For reasons of brevity the {{{public void accept(DescriptorVisitor
visitor)}}} method on the various interfaces is not shown.
 * The ''!RegistryBuilder'' part of the Descriptor API has been left out, as it should remain
the same.
 * The ordering of interceptors (and eventually configuration contributions) is here not explicitly
addressed but could be realized by letting an implementation also implement the !HiveMind
{{{Orderable}}} interface.
 * The {{{getConstructor()}}} methods in ''Implementation'', ''Interceptor'', and ''Contribution''
establish the link to the Runtime API.  The returned objects will be used at runtime to lazily
instantiate the actual objects.  The referenced interfaces are described in the following.

== Runtime API ==
As mentioned the {{{getConstructor()}}} methods on the ''Extension'' subtypes establish the
link to the Runtime API.  Here are the referenced interfaces thereof.  Note that the types
of the method arguments in these interfaces are the internal interfaces and '''not''' the
just described Descriptor API interfaces.

{{{
public interface ServiceImplementationConstructor
{
    public Object constructCoreServiceImplementation(ServicePoint servicePoint,
            Module contributingModule);
}
}}}

{{{
public interface ServiceInterceptorConstructor
{
    public Object constructServiceInterceptor(InterceptorStack interceptorStack,
            Module contributingModule);
}
}}}

{{{
public interface ConfigurationContributionConstructor
{
    public Object constructContributionKey(ConfigurationPoint configurationPoint,
            Module contributingModule);

    public Object constructContributionElement(ConfigurationPoint configurationPoint,
            Module contributingModule);
}
}}}

= Discussion =

---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-cvs-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-cvs-help@jakarta.apache.org


Mime
View raw message