Hi Knut,
Hi Achim,
Caching the module descriptors by serializing them as a Java class
similar to what you describe is also a solution I've thought about.
And that is then of course very closely related to what you're working
on. Given my findings about the relatively low overhead of parsing the
XML module descriptors when constructing a registry I think I will let
that idea rest for a while. So I'll rather try to help you out in your
effort.
I've taken a first look at what you've done in your branch and think
it's shaping up really well. It's very much like what I had in mind. I
understand that this is a work in progress but here are a few
questions and comments I have:
- I see that you're using the concept of natures on modules,
extenstion points and extenstions, where XML would be an example of
such a nature. That looks like a very interesting idea. As you don't
have a defined interface for these natures it seems to me that they're
more like adapters.
I was inspired by the eclipse natures (for example a tomcat nature)
which provide
additional information to a project. The adapter pattern usually deals
with conversion of
incompatible interfaces which is not the case here.
- The configuration points also seem to declare a constructor which is
responsible for constructing the container object. Is here the idea
that a configuration can have multiple containers (as currently with
Map and List) and thus constructors?
No, I decided to break backward compatibility here. A configuration must
have exactly
one type. IMO the support for mappable configurations in hivemind 1.x is
simply a concession
to the need for different configuration types. If you need a
configuration as map and list,
then define and inject it as map and call map.values(). Migration is
quite easy.
- In the org.apache.hivemind.definiton package the concrete
ExtensionDefinition objects are not owned by the *ModuleDefinition*
object but instead directly to the respective ExtensionPointDefinition
object. I get the impression that this couples modules in such a way
that it isn't possible to define them independently. IMO it would be
better to keep the ExtensionDefinition objects under the
*ModuleDefinition* object and have a reference by ID to the
ExtensionPointDefinition.
Both is possible. The direct addition to the extension point is the most
comfortable way
if you define a complete module. Additionally it is possible to define
"unresolved" extensions that
reference the points by id. The corresponding methods are defined in
RegistryDefinition
in the moment and here you are right, they should be moved to
ModuleDefinition.
- IMHO defining the *Definition objects as interfaces would have some
advantages.
Ok, but I would introduce interfaces when the api is stable.
Anyway I think this is looking very good. Let me know if there's
anything I can help you with.
A most welcome addition would be a refactoring of the dependency injection.
It's coupled with the xml specific BuilderFactory in the moment, which makes
it difficult to reuse with pure java or annotated java modules.
Achim
--knut
On 6/22/06, Achim Hügen <achim.huegen <at> gmx.de> wrote:
> Knut,
>
> it would be great to have an fast and comfortable way of loading
> serialized or preprocessed registries.
> Though I personally would like to shift these efforts to hivemind 2
> or at least to what I think hivemind 2 could be.
> Like I mentioned here
> http://article.gmane.org/gmane.comp.jakarta.hivemind.devel/2333
> some weeks ago, I'm working at a prototype, that features
> a programmatic way of defining registries. The data structures are
> based on your ideas in the wiki:
> http://wiki.apache.org/jakarta-hivemind/DescriptorApiRevampProposal
> Have a look here for the current status:
>
https://svn.apache.org/repos/asf/jakarta/hivemind/branches/branch-2-0-annot/framework/src/java/org/apache/hivemind/definition/
>
> This results in a nice xml independent object graph and a straight forward
> registry building which might be a good starting point for serialization.
> Wait ... probably the fastest way to load a registry is the use of the
> programmatic registry api. One could transform the xml module to a
> java class that contains a sequence of api calls. Example:
>
> <module id="hivemind.tests.serviceByInterface" version="1.0.0">
> <service-point id="uniqueService"
> interface="hivemind.test.IUniqueService">
> <create-instance class="hivemind.test.UniqueServiceImpl"/>
> </service-point>
> </module>
>
> would be transformed to:
>
> class ServiceByInterfaceModule {
>
> process(RegistryDefinition registry)
> {
> *ModuleDefinition* module = new
> *ModuleDefinition*("hivemind.tests.serviceByInterface");
>
> ServicePointDefinition sp = new
> ServicePointDefinition("uniqueService", Visibility.PUBLIC,
> IUniqueService.class);
> module.addServicePoint(sp);
>
> ServiceImplementationDefinition impl = new
> ServiceImplementationDefinition(
> new CreateClassServiceConstructor("module",
> UniqueServiceImpl.class),
> "singleton", true);
> sp.addImplementation(impl);
>
> registry.addModule(module);
> }
> }
>
> What do you think?
>
> Achim
>
>
>
> Knut Wannheden schrieb:
> > All,
> >
> > I've been experimenting with XML module descriptor caching as a means
> > to reduce the registry construction phase. I intended to implement
> > this as a specialized ModuleDescriptorProvider which can save and load
> > a ModuleDescriptor object to / from a file.
> >
> > My first attempt at this was to just have all the affected classes
> > (*Descriptor, *Rule classes, etc.) implement java.io.Serializable and
> > then serialize the ModuleDescriptor object to a file using standard
> > Java object serialization. Alas this didn't result in any significant
> > performance gain.
> >
> > By implementing java.io.Externalizable I am sure some performance
> > could be gained. But at the cost of some complexity. Also I'm
> > wondering how much performance there is to gain by doing this.
> >
> > I was wondering if any of you had any other ideas on how to approach
> > this. E.g. use Javassist?
> >
> > Further, once we find a feasible caching technique I think we should
> > also deliver this serialized form inside the jar files. E.g. a
> > META-INF/hivemodule.xml.ser file. What do you think about that?
> >
> > Cheers,
> >
> > --knut
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: hivemind-dev-unsubscribe <at> jakarta.apache.org
> > For additional commands, e-mail: hivemind-dev-help <at> jakarta.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: hivemind-dev-unsubscribe <at> jakarta.apache.org
> For additional commands, e-mail: hivemind-dev-help <at> jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
