Ramkumar R wrote:
For creating an itests for the validation messages, it was a requirement to
create a subset of tuscany runtime to read contribution metadata, analyze
and resolve contribution dependencies. To achieve this i just took the code
from sample-domain-management to create a CustomDomainBuilder [source:
itest-validation/src/test/java/domain/CustomDomainBuilder.java] which only
reads and resolves the contribution and finally report what user-input
errors are detected in the contribution.
The code was working fine, untill i introduced the
JavaRuntimeModuleActivator into the ModuleActivators and allowed it to
start. NPE was thrown when CustomDomainBuilder tried to start the
JavaRuntimeModuleActivator at line 61, basically because it failed to read
the ProxyFactoryExtensionPoint.
To make the code work, i just included the below part of the code before the
ModuleActivators are started...
// Create an interface contract mapper
InterfaceContractMapper mapper = new InterfaceContractMapperImpl();
extensionPoints.addExtensionPoint(mapper);
// Create Message factory
MessageFactory messageFactory = new MessageFactoryImpl();
// Create Proxy factory
ProxyFactory proxyFactory = new
DefaultProxyFactoryExtensionPoint(messageFactory, mapper);
extensionPoints.addExtensionPoint(proxyFactory);
// Create context factory extension point
ContextFactoryExtensionPoint contextFactories = new
DefaultContextFactoryExtensionPoint(extensionPoints);
extensionPoints.addExtensionPoint(contextFactories);
Thought this piece of information would be useful, for whose who try to
create a custom subset of Tuscany runtime using the new domain-management
code base.
Another thought is that, should we include this piece of the code in the
sample-domain-management code too.
Please let me know if any one has thoughts on this.
I can see at least two issues here:
- You shouldn't have to introduce JavaRuntimeModuleActivator to "read
contribution metadata, analyze and resolve contribution dependencies".
JavRuntimeModuleActivator is responsible for setting up the Java
component implementation runtime, allowing you to activate Java
component instances and dispatch to invocations from/to them. In theory
it should be possible to initialize the model, XML reader, and
introspection layers without bringing up the runtime layer.
Unfortunately it's probably not possible at the moment as the
implementation-java-* modules do not follow a clean layering... and mash
everything up starting in JavaRuntimeModuleActivator.
- Another flaw of the current setup is that the InterfaceContractMapper
and ProxyFactory are not extension points at all, and should not be
registered as such. An extension point is a plug-point for (multiple)
extensions, allowing a generic piece of core runtime to delegate
processing of particular extensions (e.g. SCA bindings, implementations,
databindings, model factories, XML processors) to extension code which
implements an SPI interface defining the nature of the extension point.
That InterfaceContractMapper and ProxyFactory are just common/global
utilities, and if they are registered as extension points at the moment,
that's just a huge hack where people wanted to share disguised globals
in the extension point registry without defining a proper mechanism to
share them.
I've created a UtilityExtensionPoint interface which could be a starting
point for a clean mechanism to share these global Utilities across the
components of a runtime.
So to summarize:
- JavaRuntimeModuleActivator mashes way too much together and should be
modularized
- InterfaceContractMapper and ProxyFactory are not extension points and
should be made available to the runtime in a cleaner way.
Basically you've hit two nasty hacks in the current runtime. I'd suggest
to get the team to clean up these hacks instead of continuing to expose
them further in samples :)
--
Jean-Sebastien
