Re: Issue faced in creating a subset of Tuscany runtime using domain-management sample

[Greg Dritschler <gr...@gmail.com>]

Sebastien,

The UtilitityExtensionPoint looks good.  You mentioned the ProxyFactory as
an example of a utility but I don't see that it is being registered with the
UtilityExtensionPoint.  Could you register it?

The reason I'm interested is because of this bit of code is
RequestContextObjectFactory:

    public RequestContext getInstance() throws ObjectCreationException {
        if (factory != null) {
            return factory.createRequestContext();
        } else {
            return new RequestContextImpl(proxyFactory);
        }
    }

If the RequestContextFactory extension point is active, then it is called to
create the request context but it isn't passed the proxyFactory as the
default implementation is.  Making the proxy factory available in the
utility registry would solve this.

Greg


On Thu, Jun 12, 2008 at 11:59 PM, Jean-Sebastien Delfino <
jsdelfino@apache.org> wrote:

> 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 just fixed these issues (which were caused by mis-uses of the extension
> point registry). CustomCompositeBuilder now works without having to run that
> setup code.
>
> --
> Jean-Sebastien
>

Re: Issue faced in creating a subset of Tuscany runtime using domain-management sample

[Jean-Sebastien Delfino <js...@apache.org>]

Greg Dritschler wrote:
> Sebastien,
> 
> The UtilitityExtensionPoint looks good.  You mentioned the ProxyFactory 
> as an example of a utility but I don't see that it is being registered 
> with the UtilityExtensionPoint.  Could you register it?
> 
> The reason I'm interested is because of this bit of code is 
> RequestContextObjectFactory:
> 
>     public RequestContext getInstance() throws ObjectCreationException {
>         if (factory != null) {
>             return factory.createRequestContext();
>         } else {
>             return new RequestContextImpl(proxyFactory);
>         }
>     }
> 
> If the RequestContextFactory extension point is active, then it is 
> called to create the request context but it isn't passed the 
> proxyFactory as the default implementation is.  Making the proxy factory 
> available in the utility registry would solve this.
> 
> Greg
> 

Yes, there's about 5 or 6 utilities that need to be registered like 
that. I'll do a pass at that in the next few days.

-- 
Jean-Sebastien