You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Jean-Sebastien Delfino <js...@apache.org> on 2008/05/02 17:13:15 UTC

Re: Some questions for workspace module in Tuscany

Jean-Sebastien Delfino wrote:
> Jean-Sebastien Delfino wrote:
>> Jean-Sebastien Delfino wrote:
>>> - Started to create sample tasks showing how to bootstrap a subset of 
>>> Tuscany to work with the various models [1], see 
>>> ListDeployables.java, ListDependencies.java, ListComponents.java, and 
>>> WireComponents.java.
>> ...
>>>
>>> The init() methods in the sample programs are there to help explore 
>>> the various Tuscany bootstrap patterns required for these common 
>>> tasks, candidate to become generic utility methods if people want that.
>>>

Looking at these init methods, a lot of the setup code is about setting 
up XML and document artifact processors, which we shouldn't have to 
write if all the necessary processors were correctly registered under 
META-INF/services.

I noticed that some of the base processors (CompositeProcessor, 
ComponentTypeProcessor, ConstrainingType etc) are missing from 
META-INF/services so I'm going to try to fix that and register them 
dynamically like all the other ones.

That should help simplify that setup code.

-- 
Jean-Sebastien

Re: Some questions for workspace module in Tuscany

Posted by Jean-Sebastien Delfino <js...@apache.org>.
Jean-Sebastien Delfino wrote:
> Jean-Sebastien Delfino wrote:
>> Jean-Sebastien Delfino wrote:
>>> Jean-Sebastien Delfino wrote:
>>>> - Started to create sample tasks showing how to bootstrap a subset 
>>>> of Tuscany to work with the various models [1], see 
>>>> ListDeployables.java, ListDependencies.java, ListComponents.java, 
>>>> and WireComponents.java.
>>> ...
>>>>
>>>> The init() methods in the sample programs are there to help explore 
>>>> the various Tuscany bootstrap patterns required for these common 
>>>> tasks, candidate to become generic utility methods if people want that.
>>>>
> 
> Looking at these init methods, a lot of the setup code is about setting 
> up XML and document artifact processors, which we shouldn't have to 
> write if all the necessary processors were correctly registered under 
> META-INF/services.
> 
> I noticed that some of the base processors (CompositeProcessor, 
> ComponentTypeProcessor, ConstrainingType etc) are missing from 
> META-INF/services so I'm going to try to fix that and register them 
> dynamically like all the other ones.
> 
> That should help simplify that setup code.
> 

I've done a first pass through all the artifact processors and declared 
them under META-INF/services. I had to make minor changes or add the 
expected constructors to some of them to follow the pattern that was 
already in place to support lazy / automatic loading and initialization.

The following methods:
StAXArtifactProcessorExtensionPoint.getProcessor(modelClass)
StAXArtifactProcessorExtensionPoint.getProcessor(qname)
URLArtifactProcessorExtensionPoint.getProcess(modelClass)
URLArtifactProcessorExtensionPoint.getProcess(artifactType)
should now work for all artifact processors, hoping that I didn't miss any.

With these changes I was able to simplify the bootstrapping code, as it 
doesn't need to create all these artifact processors manually anymore.

It was a little tedious but I also went through most artifact processor 
unit test cases and was able to simplify their setup method as well.

I'll try to go through the remaining test cases and samples in the next 
day or two.
-- 
Jean-Sebastien