You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@tuscany.apache.org by js...@apache.org on 2007/04/11 19:14:44 UTC
svn commit: r527581 - in /incubator/tuscany/java/sca/modules/host-embedded:
pom.xml src/main/java/org/apache/tuscany/host/embedded/SimpleRuntimeImpl.java
Author: jsdelfino
Date: Wed Apr 11 10:14:43 2007
New Revision: 527581
URL: http://svn.apache.org/viewvc?view=rev&rev=527581
Log:
Added missing processors for Java and WSDL interfaces.
Modified:
incubator/tuscany/java/sca/modules/host-embedded/pom.xml
incubator/tuscany/java/sca/modules/host-embedded/src/main/java/org/apache/tuscany/host/embedded/SimpleRuntimeImpl.java
Modified: incubator/tuscany/java/sca/modules/host-embedded/pom.xml
URL: http://svn.apache.org/viewvc/incubator/tuscany/java/sca/modules/host-embedded/pom.xml?view=diff&rev=527581&r1=527580&r2=527581
==============================================================================
--- incubator/tuscany/java/sca/modules/host-embedded/pom.xml (original)
+++ incubator/tuscany/java/sca/modules/host-embedded/pom.xml Wed Apr 11 10:14:43 2007
@@ -43,6 +43,18 @@
<dependency>
<groupId>org.apache.tuscany.sca</groupId>
+ <artifactId>tuscany-interface-java-xml</artifactId>
+ <version>1.0-incubating-SNAPSHOT</version>
+ </dependency>
+
+ <dependency>
+ <groupId>org.apache.tuscany.sca</groupId>
+ <artifactId>tuscany-interface-wsdl-xml</artifactId>
+ <version>1.0-incubating-SNAPSHOT</version>
+ </dependency>
+
+ <dependency>
+ <groupId>org.apache.tuscany.sca</groupId>
<artifactId>tuscany-contribution-impl</artifactId>
<version>1.0-incubating-SNAPSHOT</version>
</dependency>
Modified: incubator/tuscany/java/sca/modules/host-embedded/src/main/java/org/apache/tuscany/host/embedded/SimpleRuntimeImpl.java
URL: http://svn.apache.org/viewvc/incubator/tuscany/java/sca/modules/host-embedded/src/main/java/org/apache/tuscany/host/embedded/SimpleRuntimeImpl.java?view=diff&rev=527581&r1=527580&r2=527581
==============================================================================
--- incubator/tuscany/java/sca/modules/host-embedded/src/main/java/org/apache/tuscany/host/embedded/SimpleRuntimeImpl.java (original)
+++ incubator/tuscany/java/sca/modules/host-embedded/src/main/java/org/apache/tuscany/host/embedded/SimpleRuntimeImpl.java Wed Apr 11 10:14:43 2007
@@ -38,6 +38,9 @@
import org.apache.tuscany.core.component.SimpleWorkContext;
import org.apache.tuscany.core.runtime.AbstractRuntime;
import org.apache.tuscany.host.runtime.InitializationException;
+import org.apache.tuscany.interfacedef.java.xml.JavaInterfaceProcessor;
+import org.apache.tuscany.interfacedef.wsdl.xml.WSDLDocumentProcessor;
+import org.apache.tuscany.interfacedef.wsdl.xml.WSDLInterfaceProcessor;
import org.apache.tuscany.services.contribution.ContributionPackageProcessorRegistryImpl;
import org.apache.tuscany.services.contribution.ContributionRepositoryImpl;
import org.apache.tuscany.services.contribution.ContributionServiceImpl;
@@ -45,7 +48,6 @@
import org.apache.tuscany.services.contribution.processor.FolderContributionProcessor;
import org.apache.tuscany.services.contribution.processor.JarContributionProcessor;
import org.apache.tuscany.services.contribution.util.FileHelper;
-import org.apache.tuscany.services.spi.contribution.ArtifactResolverRegistry;
import org.apache.tuscany.services.spi.contribution.ContributionPackageProcessorRegistry;
import org.apache.tuscany.services.spi.contribution.ContributionRepository;
import org.apache.tuscany.services.spi.contribution.ContributionService;
@@ -53,6 +55,7 @@
import org.apache.tuscany.services.spi.contribution.DefaultStAXArtifactProcessorRegistry;
import org.apache.tuscany.services.spi.contribution.DefaultURLArtifactProcessorRegistry;
import org.apache.tuscany.services.spi.contribution.StAXArtifactProcessorRegistry;
+import org.apache.tuscany.services.spi.contribution.URLArtifactProcessorRegistry;
import org.apache.tuscany.spi.Scope;
import org.apache.tuscany.spi.bootstrap.ExtensionPointRegistry;
import org.apache.tuscany.spi.component.AtomicComponent;
@@ -112,21 +115,21 @@
public Component start() throws Exception {
ExtensionPointRegistry extensionRegistry = new ExtensionPointRegistryImpl();
ContributionRepository repository = new ContributionRepositoryImpl("target");
- DefaultStAXArtifactProcessorRegistry registry = new DefaultStAXArtifactProcessorRegistry();
- registry.addArtifactProcessor(new CompositeProcessor(registry));
- registry.addArtifactProcessor(new ComponentTypeProcessor(registry));
- registry.addArtifactProcessor(new ConstrainingTypeProcessor(registry));
-
- extensionRegistry.addExtensionPoint(StAXArtifactProcessorRegistry.class, registry);
-
- DefaultURLArtifactProcessorRegistry artifactRegistry = new DefaultURLArtifactProcessorRegistry();
- CompositeDocumentProcessor compositeProcessor = new CompositeDocumentProcessor(registry);
- ComponentTypeDocumentProcessor componentTypeProcessor = new ComponentTypeDocumentProcessor(registry);
- ConstrainingTypeDocumentProcessor constrainingTypeProcessor = new ConstrainingTypeDocumentProcessor(registry);
-
- artifactRegistry.addArtifactProcessor(compositeProcessor);
- artifactRegistry.addArtifactProcessor(componentTypeProcessor);
- artifactRegistry.addArtifactProcessor(constrainingTypeProcessor);
+
+ DefaultStAXArtifactProcessorRegistry staxExtensionPoint = new DefaultStAXArtifactProcessorRegistry();
+ staxExtensionPoint.addArtifactProcessor(new CompositeProcessor(staxExtensionPoint));
+ staxExtensionPoint.addArtifactProcessor(new ComponentTypeProcessor(staxExtensionPoint));
+ staxExtensionPoint.addArtifactProcessor(new ConstrainingTypeProcessor(staxExtensionPoint));
+ staxExtensionPoint.addArtifactProcessor(new JavaInterfaceProcessor());
+ staxExtensionPoint.addArtifactProcessor(new WSDLInterfaceProcessor());
+ extensionRegistry.addExtensionPoint(StAXArtifactProcessorRegistry.class, staxExtensionPoint);
+
+ DefaultURLArtifactProcessorRegistry documentExtensionPoint = new DefaultURLArtifactProcessorRegistry();
+ documentExtensionPoint.addArtifactProcessor(new CompositeDocumentProcessor(staxExtensionPoint));
+ documentExtensionPoint.addArtifactProcessor(new ComponentTypeDocumentProcessor(staxExtensionPoint));
+ documentExtensionPoint.addArtifactProcessor(new ConstrainingTypeDocumentProcessor(staxExtensionPoint));
+ documentExtensionPoint.addArtifactProcessor(new WSDLDocumentProcessor());
+ extensionRegistry.addExtensionPoint(URLArtifactProcessorRegistry.class, documentExtensionPoint);
PackageTypeDescriberImpl describer = new PackageTypeDescriberImpl();
ContributionPackageProcessorRegistry pkgRegistry = new ContributionPackageProcessorRegistryImpl(describer);
@@ -136,7 +139,7 @@
DefaultArtifactResolver artifactResolver = new DefaultArtifactResolver();
ContributionService contributionService =
- new ContributionServiceImpl(repository, pkgRegistry, artifactRegistry, artifactResolver);
+ new ContributionServiceImpl(repository, pkgRegistry, documentExtensionPoint, artifactResolver);
extensionRegistry.addExtensionPoint(ContributionService.class, contributionService);
initialize(extensionRegistry, contributionService);
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-commits-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-commits-help@ws.apache.org
Re: svn commit: r527581 - in /incubator/tuscany/java/sca/modules/host-embedded:
pom.xml src/main/java/org/apache/tuscany/host/embedded/SimpleRuntimeImpl.java
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Comments inline.
Luciano Resende wrote:
> Raymond,
>
> So, for extensions, I'm actually using the module activator extension
> mechanism to register processors. But for system processors, should we
> also
> use this mechanism ? Wouldn't this cause issues if we start adding
> dependencies to higher level components on low level components
> (e.gcontribution-impl requeire core-spi for ModuleActivator ? )
>
Yes, adding these dependencies will cause circular dependencies. We
basically have 3 layers here:
1. Model extenions, e.g. implementation-java
2. Artifact processor extensions, like implementation-java-xml
3. Runtime extensions, like implementation-java-runtime
We can't contribute a runtime extension (layer 3) through a module in
layer 1 or 2, but we can contribute a runtime extension in a module in
layer 3. So, we can add these "layer 3" modules for contribution,
assembly, interface-java, interface-wsdl if we wanted to, or just
register them in host-embedded, which is what we do at the moment. It's
just a matter of drawing the line between the base function and the
optional extensions.
> Thoughts ?
>
> On 4/11/07, Raymond Feng <en...@gmail.com> wrote:
>>
>> Hi,
>>
>> I think we should start to leverage the extensibility story (see the
>> thread
>> titled "The pluggability for Tuscany runtime extensions") instead of
>> hard-coding all the processors into the SimpleRuntimeImpl.
>>
>> Thanks,
>> Raymond
>>
>> ----- Original Message -----
>> From: <js...@apache.org>
>> To: <tu...@ws.apache.org>
>> Sent: Wednesday, April 11, 2007 10:14 AM
>> Subject: svn commit: r527581 - in
>> /incubator/tuscany/java/sca/modules/host-embedded: pom.xml
>> src/main/java/org/apache/tuscany/host/embedded/SimpleRuntimeImpl.java
>>
>>
>> > Author: jsdelfino
>> > Date: Wed Apr 11 10:14:43 2007
>> > New Revision: 527581
>> >
>> > URL: http://svn.apache.org/viewvc?view=rev&rev=527581
>> > Log:
>> > Added missing processors for Java and WSDL interfaces.
>> >
>> > Modified:
>> > incubator/tuscany/java/sca/modules/host-embedded/pom.xml
>> >
>> >
>> incubator/tuscany/java/sca/modules/host-embedded/src/main/java/org/apache/tuscany/host/embedded/SimpleRuntimeImpl.java
>>
>> >
>> > Modified: incubator/tuscany/java/sca/modules/host-embedded/pom.xml
>> > URL:
>> >
>> http://svn.apache.org/viewvc/incubator/tuscany/java/sca/modules/host-embedded/pom.xml?view=diff&rev=527581&r1=527580&r2=527581
>>
>> >
>> ==============================================================================
>>
>> > --- incubator/tuscany/java/sca/modules/host-embedded/pom.xml
>> (original)
>> > +++ incubator/tuscany/java/sca/modules/host-embedded/pom.xml Wed
>> Apr 11
>> > 10:14:43 2007
>> > @@ -43,6 +43,18 @@
>> >
>> > <dependency>
>> > <groupId>org.apache.tuscany.sca</groupId>
>> > + <artifactId>tuscany-interface-java-xml</artifactId>
>> > + <version>1.0-incubating-SNAPSHOT</version>
>> > + </dependency>
>> > +
>> > + <dependency>
>> > + <groupId>org.apache.tuscany.sca</groupId>
>> > + <artifactId>tuscany-interface-wsdl-xml</artifactId>
>> > + <version>1.0-incubating-SNAPSHOT</version>
>> > + </dependency>
>> > +
>> > + <dependency>
>> > + <groupId>org.apache.tuscany.sca</groupId>
>> > <artifactId>tuscany-contribution-impl</artifactId>
>> > <version>1.0-incubating-SNAPSHOT</version>
>> > </dependency>
>> >
>> > Modified:
>> >
>> incubator/tuscany/java/sca/modules/host-embedded/src/main/java/org/apache/tuscany/host/embedded/SimpleRuntimeImpl.java
>>
>> > URL:
>> >
>> http://svn.apache.org/viewvc/incubator/tuscany/java/sca/modules/host-embedded/src/main/java/org/apache/tuscany/host/embedded/SimpleRuntimeImpl.java?view=diff&rev=527581&r1=527580&r2=527581
>>
>> >
>> ==============================================================================
>>
>> > ---
>> >
>> incubator/tuscany/java/sca/modules/host-embedded/src/main/java/org/apache/tuscany/host/embedded/SimpleRuntimeImpl.java
>>
>> > (original)
>> > +++
>> >
>> incubator/tuscany/java/sca/modules/host-embedded/src/main/java/org/apache/tuscany/host/embedded/SimpleRuntimeImpl.java
>>
>> > Wed Apr 11 10:14:43 2007
>> > @@ -38,6 +38,9 @@
>> > import org.apache.tuscany.core.component.SimpleWorkContext;
>> > import org.apache.tuscany.core.runtime.AbstractRuntime;
>> > import org.apache.tuscany.host.runtime.InitializationException;
>> > +import
>> org.apache.tuscany.interfacedef.java.xml.JavaInterfaceProcessor;
>> > +import
>> org.apache.tuscany.interfacedef.wsdl.xml.WSDLDocumentProcessor;
>> > +import
>> org.apache.tuscany.interfacedef.wsdl.xml.WSDLInterfaceProcessor;
>> > import
>> >
>> org.apache.tuscany.services.contribution.ContributionPackageProcessorRegistryImpl
>>
>> ;
>> > import
>> > org.apache.tuscany.services.contribution.ContributionRepositoryImpl;
>> > import
>> org.apache.tuscany.services.contribution.ContributionServiceImpl;
>> > @@ -45,7 +48,6 @@
>> > import
>> >
>> org.apache.tuscany.services.contribution.processor.FolderContributionProcessor
>>
>> ;
>> > import
>> >
>> org.apache.tuscany.services.contribution.processor.JarContributionProcessor
>>
>> ;
>> > import org.apache.tuscany.services.contribution.util.FileHelper;
>> > -import
>> > org.apache.tuscany.services.spi.contribution.ArtifactResolverRegistry;
>> > import
>> >
>> org.apache.tuscany.services.spi.contribution.ContributionPackageProcessorRegistry
>>
>> ;
>> > import
>> > org.apache.tuscany.services.spi.contribution.ContributionRepository;
>> > import
>> org.apache.tuscany.services.spi.contribution.ContributionService;
>> > @@ -53,6 +55,7 @@
>> > import
>> >
>> org.apache.tuscany.services.spi.contribution.DefaultStAXArtifactProcessorRegistry
>>
>> ;
>> > import
>> >
>> org.apache.tuscany.services.spi.contribution.DefaultURLArtifactProcessorRegistry
>>
>> ;
>> > import
>> >
>> org.apache.tuscany.services.spi.contribution.StAXArtifactProcessorRegistry
>>
>> ;
>> > +import
>> >
>> org.apache.tuscany.services.spi.contribution.URLArtifactProcessorRegistry;
>>
>> > import org.apache.tuscany.spi.Scope;
>> > import org.apache.tuscany.spi.bootstrap.ExtensionPointRegistry;
>> > import org.apache.tuscany.spi.component.AtomicComponent;
>> > @@ -112,21 +115,21 @@
>> > public Component start() throws Exception {
>> > ExtensionPointRegistry extensionRegistry = new
>> > ExtensionPointRegistryImpl();
>> > ContributionRepository repository = new
>> > ContributionRepositoryImpl("target");
>> > - DefaultStAXArtifactProcessorRegistry registry = new
>> > DefaultStAXArtifactProcessorRegistry();
>> > - registry.addArtifactProcessor(new
>> CompositeProcessor(registry));
>> > - registry.addArtifactProcessor(new
>> > ComponentTypeProcessor(registry));
>> > - registry.addArtifactProcessor(new
>> > ConstrainingTypeProcessor(registry));
>> > -
>> > -
>> >
>> extensionRegistry.addExtensionPoint(StAXArtifactProcessorRegistry.class,
>> > registry);
>> > -
>> > - DefaultURLArtifactProcessorRegistry artifactRegistry = new
>> > DefaultURLArtifactProcessorRegistry();
>> > - CompositeDocumentProcessor compositeProcessor = new
>> > CompositeDocumentProcessor(registry);
>> > - ComponentTypeDocumentProcessor componentTypeProcessor = new
>> > ComponentTypeDocumentProcessor(registry);
>> > - ConstrainingTypeDocumentProcessor constrainingTypeProcessor =
>> new
>> > ConstrainingTypeDocumentProcessor(registry);
>> > -
>> > - artifactRegistry.addArtifactProcessor(compositeProcessor);
>> > -
>> artifactRegistry.addArtifactProcessor(componentTypeProcessor);
>> > - artifactRegistry.addArtifactProcessor
>> (constrainingTypeProcessor);
>> > +
>> > + DefaultStAXArtifactProcessorRegistry staxExtensionPoint = new
>> > DefaultStAXArtifactProcessorRegistry();
>> > + staxExtensionPoint.addArtifactProcessor(new
>> > CompositeProcessor(staxExtensionPoint));
>> > + staxExtensionPoint.addArtifactProcessor(new
>> > ComponentTypeProcessor(staxExtensionPoint));
>> > + staxExtensionPoint.addArtifactProcessor(new
>> > ConstrainingTypeProcessor(staxExtensionPoint));
>> > + staxExtensionPoint.addArtifactProcessor(new
>> > JavaInterfaceProcessor());
>> > + staxExtensionPoint.addArtifactProcessor(new
>> > WSDLInterfaceProcessor());
>> > +
>> >
>> extensionRegistry.addExtensionPoint(StAXArtifactProcessorRegistry.class,
>> > staxExtensionPoint);
>> > +
>> > + DefaultURLArtifactProcessorRegistry documentExtensionPoint =
>> new
>> > DefaultURLArtifactProcessorRegistry();
>> > + documentExtensionPoint.addArtifactProcessor(new
>> > CompositeDocumentProcessor(staxExtensionPoint));
>> > + documentExtensionPoint.addArtifactProcessor(new
>> > ComponentTypeDocumentProcessor(staxExtensionPoint));
>> > + documentExtensionPoint.addArtifactProcessor(new
>> > ConstrainingTypeDocumentProcessor(staxExtensionPoint));
>> > + documentExtensionPoint.addArtifactProcessor(new
>> > WSDLDocumentProcessor());
>> > +
>> >
>> extensionRegistry.addExtensionPoint(URLArtifactProcessorRegistry.class,
>> > documentExtensionPoint);
>> >
>> > PackageTypeDescriberImpl describer = new
>> > PackageTypeDescriberImpl();
>> > ContributionPackageProcessorRegistry pkgRegistry = new
>> > ContributionPackageProcessorRegistryImpl(describer);
>> > @@ -136,7 +139,7 @@
>> > DefaultArtifactResolver artifactResolver = new
>> > DefaultArtifactResolver();
>> >
>> > ContributionService contributionService =
>> > - new ContributionServiceImpl(repository, pkgRegistry,
>> > artifactRegistry, artifactResolver);
>> > + new ContributionServiceImpl(repository, pkgRegistry,
>> > documentExtensionPoint, artifactResolver);
>> >
>> > extensionRegistry.addExtensionPoint(ContributionService.class,
>> > contributionService);
>> > initialize(extensionRegistry, contributionService);
>> >
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: tuscany-commits-unsubscribe@ws.apache.org
>> > For additional commands, e-mail: tuscany-commits-help@ws.apache.org
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
>
>
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: svn commit: r527581 - in /incubator/tuscany/java/sca/modules/host-embedded: pom.xml src/main/java/org/apache/tuscany/host/embedded/SimpleRuntimeImpl.java
Posted by Luciano Resende <lu...@gmail.com>.
Raymond,
So, for extensions, I'm actually using the module activator extension
mechanism to register processors. But for system processors, should we also
use this mechanism ? Wouldn't this cause issues if we start adding
dependencies to higher level components on low level components
(e.gcontribution-impl requeire core-spi for ModuleActivator ? )
Thoughts ?
On 4/11/07, Raymond Feng <en...@gmail.com> wrote:
>
> Hi,
>
> I think we should start to leverage the extensibility story (see the
> thread
> titled "The pluggability for Tuscany runtime extensions") instead of
> hard-coding all the processors into the SimpleRuntimeImpl.
>
> Thanks,
> Raymond
>
> ----- Original Message -----
> From: <js...@apache.org>
> To: <tu...@ws.apache.org>
> Sent: Wednesday, April 11, 2007 10:14 AM
> Subject: svn commit: r527581 - in
> /incubator/tuscany/java/sca/modules/host-embedded: pom.xml
> src/main/java/org/apache/tuscany/host/embedded/SimpleRuntimeImpl.java
>
>
> > Author: jsdelfino
> > Date: Wed Apr 11 10:14:43 2007
> > New Revision: 527581
> >
> > URL: http://svn.apache.org/viewvc?view=rev&rev=527581
> > Log:
> > Added missing processors for Java and WSDL interfaces.
> >
> > Modified:
> > incubator/tuscany/java/sca/modules/host-embedded/pom.xml
> >
> >
> incubator/tuscany/java/sca/modules/host-embedded/src/main/java/org/apache/tuscany/host/embedded/SimpleRuntimeImpl.java
> >
> > Modified: incubator/tuscany/java/sca/modules/host-embedded/pom.xml
> > URL:
> >
> http://svn.apache.org/viewvc/incubator/tuscany/java/sca/modules/host-embedded/pom.xml?view=diff&rev=527581&r1=527580&r2=527581
> >
> ==============================================================================
> > --- incubator/tuscany/java/sca/modules/host-embedded/pom.xml (original)
> > +++ incubator/tuscany/java/sca/modules/host-embedded/pom.xml Wed Apr 11
> > 10:14:43 2007
> > @@ -43,6 +43,18 @@
> >
> > <dependency>
> > <groupId>org.apache.tuscany.sca</groupId>
> > + <artifactId>tuscany-interface-java-xml</artifactId>
> > + <version>1.0-incubating-SNAPSHOT</version>
> > + </dependency>
> > +
> > + <dependency>
> > + <groupId>org.apache.tuscany.sca</groupId>
> > + <artifactId>tuscany-interface-wsdl-xml</artifactId>
> > + <version>1.0-incubating-SNAPSHOT</version>
> > + </dependency>
> > +
> > + <dependency>
> > + <groupId>org.apache.tuscany.sca</groupId>
> > <artifactId>tuscany-contribution-impl</artifactId>
> > <version>1.0-incubating-SNAPSHOT</version>
> > </dependency>
> >
> > Modified:
> >
> incubator/tuscany/java/sca/modules/host-embedded/src/main/java/org/apache/tuscany/host/embedded/SimpleRuntimeImpl.java
> > URL:
> >
> http://svn.apache.org/viewvc/incubator/tuscany/java/sca/modules/host-embedded/src/main/java/org/apache/tuscany/host/embedded/SimpleRuntimeImpl.java?view=diff&rev=527581&r1=527580&r2=527581
> >
> ==============================================================================
> > ---
> >
> incubator/tuscany/java/sca/modules/host-embedded/src/main/java/org/apache/tuscany/host/embedded/SimpleRuntimeImpl.java
> > (original)
> > +++
> >
> incubator/tuscany/java/sca/modules/host-embedded/src/main/java/org/apache/tuscany/host/embedded/SimpleRuntimeImpl.java
> > Wed Apr 11 10:14:43 2007
> > @@ -38,6 +38,9 @@
> > import org.apache.tuscany.core.component.SimpleWorkContext;
> > import org.apache.tuscany.core.runtime.AbstractRuntime;
> > import org.apache.tuscany.host.runtime.InitializationException;
> > +import org.apache.tuscany.interfacedef.java.xml.JavaInterfaceProcessor;
> > +import org.apache.tuscany.interfacedef.wsdl.xml.WSDLDocumentProcessor;
> > +import org.apache.tuscany.interfacedef.wsdl.xml.WSDLInterfaceProcessor;
> > import
> >
> org.apache.tuscany.services.contribution.ContributionPackageProcessorRegistryImpl
> ;
> > import
> > org.apache.tuscany.services.contribution.ContributionRepositoryImpl;
> > import org.apache.tuscany.services.contribution.ContributionServiceImpl;
> > @@ -45,7 +48,6 @@
> > import
> >
> org.apache.tuscany.services.contribution.processor.FolderContributionProcessor
> ;
> > import
> >
> org.apache.tuscany.services.contribution.processor.JarContributionProcessor
> ;
> > import org.apache.tuscany.services.contribution.util.FileHelper;
> > -import
> > org.apache.tuscany.services.spi.contribution.ArtifactResolverRegistry;
> > import
> >
> org.apache.tuscany.services.spi.contribution.ContributionPackageProcessorRegistry
> ;
> > import
> > org.apache.tuscany.services.spi.contribution.ContributionRepository;
> > import org.apache.tuscany.services.spi.contribution.ContributionService;
> > @@ -53,6 +55,7 @@
> > import
> >
> org.apache.tuscany.services.spi.contribution.DefaultStAXArtifactProcessorRegistry
> ;
> > import
> >
> org.apache.tuscany.services.spi.contribution.DefaultURLArtifactProcessorRegistry
> ;
> > import
> >
> org.apache.tuscany.services.spi.contribution.StAXArtifactProcessorRegistry
> ;
> > +import
> >
> org.apache.tuscany.services.spi.contribution.URLArtifactProcessorRegistry;
> > import org.apache.tuscany.spi.Scope;
> > import org.apache.tuscany.spi.bootstrap.ExtensionPointRegistry;
> > import org.apache.tuscany.spi.component.AtomicComponent;
> > @@ -112,21 +115,21 @@
> > public Component start() throws Exception {
> > ExtensionPointRegistry extensionRegistry = new
> > ExtensionPointRegistryImpl();
> > ContributionRepository repository = new
> > ContributionRepositoryImpl("target");
> > - DefaultStAXArtifactProcessorRegistry registry = new
> > DefaultStAXArtifactProcessorRegistry();
> > - registry.addArtifactProcessor(new
> CompositeProcessor(registry));
> > - registry.addArtifactProcessor(new
> > ComponentTypeProcessor(registry));
> > - registry.addArtifactProcessor(new
> > ConstrainingTypeProcessor(registry));
> > -
> > -
> > extensionRegistry.addExtensionPoint(StAXArtifactProcessorRegistry.class,
> > registry);
> > -
> > - DefaultURLArtifactProcessorRegistry artifactRegistry = new
> > DefaultURLArtifactProcessorRegistry();
> > - CompositeDocumentProcessor compositeProcessor = new
> > CompositeDocumentProcessor(registry);
> > - ComponentTypeDocumentProcessor componentTypeProcessor = new
> > ComponentTypeDocumentProcessor(registry);
> > - ConstrainingTypeDocumentProcessor constrainingTypeProcessor =
> new
> > ConstrainingTypeDocumentProcessor(registry);
> > -
> > - artifactRegistry.addArtifactProcessor(compositeProcessor);
> > - artifactRegistry.addArtifactProcessor(componentTypeProcessor);
> > - artifactRegistry.addArtifactProcessor
> (constrainingTypeProcessor);
> > +
> > + DefaultStAXArtifactProcessorRegistry staxExtensionPoint = new
> > DefaultStAXArtifactProcessorRegistry();
> > + staxExtensionPoint.addArtifactProcessor(new
> > CompositeProcessor(staxExtensionPoint));
> > + staxExtensionPoint.addArtifactProcessor(new
> > ComponentTypeProcessor(staxExtensionPoint));
> > + staxExtensionPoint.addArtifactProcessor(new
> > ConstrainingTypeProcessor(staxExtensionPoint));
> > + staxExtensionPoint.addArtifactProcessor(new
> > JavaInterfaceProcessor());
> > + staxExtensionPoint.addArtifactProcessor(new
> > WSDLInterfaceProcessor());
> > +
> > extensionRegistry.addExtensionPoint(StAXArtifactProcessorRegistry.class,
> > staxExtensionPoint);
> > +
> > + DefaultURLArtifactProcessorRegistry documentExtensionPoint =
> new
> > DefaultURLArtifactProcessorRegistry();
> > + documentExtensionPoint.addArtifactProcessor(new
> > CompositeDocumentProcessor(staxExtensionPoint));
> > + documentExtensionPoint.addArtifactProcessor(new
> > ComponentTypeDocumentProcessor(staxExtensionPoint));
> > + documentExtensionPoint.addArtifactProcessor(new
> > ConstrainingTypeDocumentProcessor(staxExtensionPoint));
> > + documentExtensionPoint.addArtifactProcessor(new
> > WSDLDocumentProcessor());
> > +
> > extensionRegistry.addExtensionPoint(URLArtifactProcessorRegistry.class,
> > documentExtensionPoint);
> >
> > PackageTypeDescriberImpl describer = new
> > PackageTypeDescriberImpl();
> > ContributionPackageProcessorRegistry pkgRegistry = new
> > ContributionPackageProcessorRegistryImpl(describer);
> > @@ -136,7 +139,7 @@
> > DefaultArtifactResolver artifactResolver = new
> > DefaultArtifactResolver();
> >
> > ContributionService contributionService =
> > - new ContributionServiceImpl(repository, pkgRegistry,
> > artifactRegistry, artifactResolver);
> > + new ContributionServiceImpl(repository, pkgRegistry,
> > documentExtensionPoint, artifactResolver);
> >
> > extensionRegistry.addExtensionPoint(ContributionService.class,
> > contributionService);
> > initialize(extensionRegistry, contributionService);
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-commits-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-commits-help@ws.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
--
Luciano Resende
http://people.apache.org/~lresende
Re: Should host-embedded depend on the WSDL and Java interface support? was: svn commit: r527581
Posted by Luciano Resende <lu...@gmail.com>.
I just sent a similar answer to Raymond's original e-mail.
On 4/11/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>
> Raymond Feng wrote:
> > Hi,
> >
> > I think we should start to leverage the extensibility story (see the
> > thread titled "The pluggability for Tuscany runtime extensions")
> > instead of hard-coding all the processors into the SimpleRuntimeImpl.
> >
> > Thanks,
> > Raymond
> >
> > ----- Original Message ----- From: <js...@apache.org>
> > To: <tu...@ws.apache.org>
> > Sent: Wednesday, April 11, 2007 10:14 AM
> > Subject: svn commit: r527581 - in
> > /incubator/tuscany/java/sca/modules/host-embedded: pom.xml
> > src/main/java/org/apache/tuscany/host/embedded/SimpleRuntimeImpl.java
> >
> >
>
> Raymond,
>
> I agree that we need to leverage the runtime extensibility story, for
> runtime extensions :)
>
> But are the WSDL and Java interface support really extensions or part of
> the base SCA assembly support?
>
> On one hand, no, they are not real extensions as they are part of the
> base SCA assembly spec. So we don't need to handle them as extensions,
> SimpleRuntimeImpl can depend on them the same way as it depends on the
> assembly-xml module.
>
> On the other hand, we could consider them as extensions, as Java and
> WSDL are just two of many programming languages that can be used to
> define service interfaces. To do this we just need two new Maven modules
> hosting their ModuleActivators. Going further, we could even consider
> assembly-xml as an extension, and have a ModuleActivator for it as well.
>
> So, our new modularized kernel structure allows for both approaches.
> It's a matter of where we want to draw the line between core SCA and
> extensions. At the moment, I'm tempted to follow the structure of the
> SCA specifications to draw these lines. What's in the SCA assembly spec
> is part of the base, what's not in the SCA assembly spec is extensions.
> But I could be convinced otherwise...
>
> Thoughts?
>
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
--
Luciano Resende
http://people.apache.org/~lresende
Re: Should host-embedded depend on the WSDL and Java interface support?
was: svn commit: r527581
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Jean-Sebastien Delfino wrote:
> ant elder wrote:
>> On 4/11/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>>>
>>> Raymond Feng wrote:
>>> > Hi,
>>> >
>>> > I think we should start to leverage the extensibility story (see the
>>> > thread titled "The pluggability for Tuscany runtime extensions")
>>> > instead of hard-coding all the processors into the SimpleRuntimeImpl.
>>> >
>>> > Thanks,
>>> > Raymond
>>> >
>>> > ----- Original Message ----- From: <js...@apache.org>
>>> > To: <tu...@ws.apache.org>
>>> > Sent: Wednesday, April 11, 2007 10:14 AM
>>> > Subject: svn commit: r527581 - in
>>> > /incubator/tuscany/java/sca/modules/host-embedded: pom.xml
>>> > src/main/java/org/apache/tuscany/host/embedded/SimpleRuntimeImpl.java
>>> >
>>> >
>>>
>>> Raymond,
>>>
>>> I agree that we need to leverage the runtime extensibility story, for
>>> runtime extensions :)
>>>
>>> But are the WSDL and Java interface support really extensions or
>>> part of
>>> the base SCA assembly support?
>>>
>>> On one hand, no, they are not real extensions as they are part of the
>>> base SCA assembly spec. So we don't need to handle them as extensions,
>>> SimpleRuntimeImpl can depend on them the same way as it depends on the
>>> assembly-xml module.
>>>
>>> On the other hand, we could consider them as extensions, as Java and
>>> WSDL are just two of many programming languages that can be used to
>>> define service interfaces. To do this we just need two new Maven
>>> modules
>>> hosting their ModuleActivators. Going further, we could even consider
>>> assembly-xml as an extension, and have a ModuleActivator for it as
>>> well.
>>>
>>> So, our new modularized kernel structure allows for both approaches.
>>> It's a matter of where we want to draw the line between core SCA and
>>> extensions. At the moment, I'm tempted to follow the structure of the
>>> SCA specifications to draw these lines. What's in the SCA assembly spec
>>> is part of the base, what's not in the SCA assembly spec is extensions.
>>> But I could be convinced otherwise...
>>>
>>> Thoughts?
>>
>>
>> I'd be leaning to making them proper extensions unless it makes the code
>> significantly more complicated.
>>
>> One of the problems we've had in the past is that by not making
>> things like
>> Java 1st class extensions then when it comes to adding something else
>> as a
>> real extension various issues get exposed. Another thing is that the SCA
>> assembly spec also says that the WS binding MUST be supported by an SCA
>> runtime so following the argument above our Axis2 binding could be
>> hardcoded
>> into the runtime which doesn't seem right.
>>
>> ...ant
>>
>
> Ok, good points. Like I said above I could be convinced... both
> Raymond and you seem to favor that direction so, if anybody has time
> to create the two new Maven modules (interface-java-runtime and
> interface-wsdl-runtime) contributing the corresponding
> ModuleActivators then let's just do that as it's cleaner. If nobody
> else gets to it before tomorrow then I'll try to do it tomorrow.
>
I have created the two Maven modules contributing the ModuleActivators
for interface-java and interface-wsdl:
- modules/interface-java-runtime, registers the StAX artifact processor
for <interface.java>
- modules/interface-wsdl-runtime, registers the StAX artifact processor
for <interface.wsdl> and the URL artifact processor for WSDL documents
For now I have kept a dependency on these two modules in host-embedded
(with <scope>runtime</scope>) to avoid having to touch all the samples
and integration tests that use Java and WSDL interfaces and have to add
these 2 modules to them individually. Once they all have the correct
dependencies we can remove the dependency in host-embedded.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Should host-embedded depend on the WSDL and Java interface support?
was: svn commit: r527581
Posted by Jean-Sebastien Delfino <js...@apache.org>.
ant elder wrote:
> On 4/11/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>>
>> Raymond Feng wrote:
>> > Hi,
>> >
>> > I think we should start to leverage the extensibility story (see the
>> > thread titled "The pluggability for Tuscany runtime extensions")
>> > instead of hard-coding all the processors into the SimpleRuntimeImpl.
>> >
>> > Thanks,
>> > Raymond
>> >
>> > ----- Original Message ----- From: <js...@apache.org>
>> > To: <tu...@ws.apache.org>
>> > Sent: Wednesday, April 11, 2007 10:14 AM
>> > Subject: svn commit: r527581 - in
>> > /incubator/tuscany/java/sca/modules/host-embedded: pom.xml
>> > src/main/java/org/apache/tuscany/host/embedded/SimpleRuntimeImpl.java
>> >
>> >
>>
>> Raymond,
>>
>> I agree that we need to leverage the runtime extensibility story, for
>> runtime extensions :)
>>
>> But are the WSDL and Java interface support really extensions or part of
>> the base SCA assembly support?
>>
>> On one hand, no, they are not real extensions as they are part of the
>> base SCA assembly spec. So we don't need to handle them as extensions,
>> SimpleRuntimeImpl can depend on them the same way as it depends on the
>> assembly-xml module.
>>
>> On the other hand, we could consider them as extensions, as Java and
>> WSDL are just two of many programming languages that can be used to
>> define service interfaces. To do this we just need two new Maven modules
>> hosting their ModuleActivators. Going further, we could even consider
>> assembly-xml as an extension, and have a ModuleActivator for it as well.
>>
>> So, our new modularized kernel structure allows for both approaches.
>> It's a matter of where we want to draw the line between core SCA and
>> extensions. At the moment, I'm tempted to follow the structure of the
>> SCA specifications to draw these lines. What's in the SCA assembly spec
>> is part of the base, what's not in the SCA assembly spec is extensions.
>> But I could be convinced otherwise...
>>
>> Thoughts?
>
>
> I'd be leaning to making them proper extensions unless it makes the code
> significantly more complicated.
>
> One of the problems we've had in the past is that by not making things
> like
> Java 1st class extensions then when it comes to adding something else
> as a
> real extension various issues get exposed. Another thing is that the SCA
> assembly spec also says that the WS binding MUST be supported by an SCA
> runtime so following the argument above our Axis2 binding could be
> hardcoded
> into the runtime which doesn't seem right.
>
> ...ant
>
Ok, good points. Like I said above I could be convinced... both Raymond
and you seem to favor that direction so, if anybody has time to create
the two new Maven modules (interface-java-runtime and
interface-wsdl-runtime) contributing the corresponding ModuleActivators
then let's just do that as it's cleaner. If nobody else gets to it
before tomorrow then I'll try to do it tomorrow.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Should host-embedded depend on the WSDL and Java interface support? was: svn commit: r527581
Posted by ant elder <an...@gmail.com>.
On 4/11/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>
> Raymond Feng wrote:
> > Hi,
> >
> > I think we should start to leverage the extensibility story (see the
> > thread titled "The pluggability for Tuscany runtime extensions")
> > instead of hard-coding all the processors into the SimpleRuntimeImpl.
> >
> > Thanks,
> > Raymond
> >
> > ----- Original Message ----- From: <js...@apache.org>
> > To: <tu...@ws.apache.org>
> > Sent: Wednesday, April 11, 2007 10:14 AM
> > Subject: svn commit: r527581 - in
> > /incubator/tuscany/java/sca/modules/host-embedded: pom.xml
> > src/main/java/org/apache/tuscany/host/embedded/SimpleRuntimeImpl.java
> >
> >
>
> Raymond,
>
> I agree that we need to leverage the runtime extensibility story, for
> runtime extensions :)
>
> But are the WSDL and Java interface support really extensions or part of
> the base SCA assembly support?
>
> On one hand, no, they are not real extensions as they are part of the
> base SCA assembly spec. So we don't need to handle them as extensions,
> SimpleRuntimeImpl can depend on them the same way as it depends on the
> assembly-xml module.
>
> On the other hand, we could consider them as extensions, as Java and
> WSDL are just two of many programming languages that can be used to
> define service interfaces. To do this we just need two new Maven modules
> hosting their ModuleActivators. Going further, we could even consider
> assembly-xml as an extension, and have a ModuleActivator for it as well.
>
> So, our new modularized kernel structure allows for both approaches.
> It's a matter of where we want to draw the line between core SCA and
> extensions. At the moment, I'm tempted to follow the structure of the
> SCA specifications to draw these lines. What's in the SCA assembly spec
> is part of the base, what's not in the SCA assembly spec is extensions.
> But I could be convinced otherwise...
>
> Thoughts?
I'd be leaning to making them proper extensions unless it makes the code
significantly more complicated.
One of the problems we've had in the past is that by not making things like
Java 1st class extensions then when it comes to adding something else as a
real extension various issues get exposed. Another thing is that the SCA
assembly spec also says that the WS binding MUST be supported by an SCA
runtime so following the argument above our Axis2 binding could be hardcoded
into the runtime which doesn't seem right.
...ant
Re: Should host-embedded depend on the WSDL and Java interface support? was: svn commit: r527581
Posted by Raymond Feng <en...@gmail.com>.
Hi,
I think we're talking about two different things:
1) Should Java and WSDL interface support part of the Tuscany kernel?
I agree with Sebastien that we can go either way with the modulized kernel
amd I don't have any preferences.
2) How do we get a set of built-in processors registered with the
ArtifactProcessorExtensionPoint?
We have three options to provide the registration logic:
a. in the embedded host
b. in a system-level ModuleActivator impl which can be packaged into a
runtime module that integrates other modules with the core.
c. in a ModuleActivator impl by the owning module that provides the
processor
I prefer option b.
Option a is not flexible because it forces all hosting environments to
duplicate the logic.
Option c addes compile-time dependency to core-spi.
Option b is the middle ground.
Thanks,
Raymond
----- Original Message -----
From: "Jean-Sebastien Delfino" <js...@apache.org>
To: <tu...@ws.apache.org>
Sent: Wednesday, April 11, 2007 11:17 AM
Subject: Should host-embedded depend on the WSDL and Java interface support?
was: svn commit: r527581
> Raymond Feng wrote:
>> Hi,
>>
>> I think we should start to leverage the extensibility story (see the
>> thread titled "The pluggability for Tuscany runtime extensions") instead
>> of hard-coding all the processors into the SimpleRuntimeImpl.
>>
>> Thanks,
>> Raymond
>>
>> ----- Original Message ----- From: <js...@apache.org>
>> To: <tu...@ws.apache.org>
>> Sent: Wednesday, April 11, 2007 10:14 AM
>> Subject: svn commit: r527581 - in
>> /incubator/tuscany/java/sca/modules/host-embedded: pom.xml
>> src/main/java/org/apache/tuscany/host/embedded/SimpleRuntimeImpl.java
>>
>>
>
> Raymond,
>
> I agree that we need to leverage the runtime extensibility story, for
> runtime extensions :)
>
> But are the WSDL and Java interface support really extensions or part of
> the base SCA assembly support?
>
> On one hand, no, they are not real extensions as they are part of the base
> SCA assembly spec. So we don't need to handle them as extensions,
> SimpleRuntimeImpl can depend on them the same way as it depends on the
> assembly-xml module.
>
> On the other hand, we could consider them as extensions, as Java and WSDL
> are just two of many programming languages that can be used to define
> service interfaces. To do this we just need two new Maven modules hosting
> their ModuleActivators. Going further, we could even consider assembly-xml
> as an extension, and have a ModuleActivator for it as well.
>
> So, our new modularized kernel structure allows for both approaches. It's
> a matter of where we want to draw the line between core SCA and
> extensions. At the moment, I'm tempted to follow the structure of the SCA
> specifications to draw these lines. What's in the SCA assembly spec is
> part of the base, what's not in the SCA assembly spec is extensions. But I
> could be convinced otherwise...
>
> Thoughts?
>
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Should host-embedded depend on the WSDL and Java interface support?
was: svn commit: r527581
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Raymond Feng wrote:
> Hi,
>
> I think we should start to leverage the extensibility story (see the
> thread titled "The pluggability for Tuscany runtime extensions")
> instead of hard-coding all the processors into the SimpleRuntimeImpl.
>
> Thanks,
> Raymond
>
> ----- Original Message ----- From: <js...@apache.org>
> To: <tu...@ws.apache.org>
> Sent: Wednesday, April 11, 2007 10:14 AM
> Subject: svn commit: r527581 - in
> /incubator/tuscany/java/sca/modules/host-embedded: pom.xml
> src/main/java/org/apache/tuscany/host/embedded/SimpleRuntimeImpl.java
>
>
Raymond,
I agree that we need to leverage the runtime extensibility story, for
runtime extensions :)
But are the WSDL and Java interface support really extensions or part of
the base SCA assembly support?
On one hand, no, they are not real extensions as they are part of the
base SCA assembly spec. So we don't need to handle them as extensions,
SimpleRuntimeImpl can depend on them the same way as it depends on the
assembly-xml module.
On the other hand, we could consider them as extensions, as Java and
WSDL are just two of many programming languages that can be used to
define service interfaces. To do this we just need two new Maven modules
hosting their ModuleActivators. Going further, we could even consider
assembly-xml as an extension, and have a ModuleActivator for it as well.
So, our new modularized kernel structure allows for both approaches.
It's a matter of where we want to draw the line between core SCA and
extensions. At the moment, I'm tempted to follow the structure of the
SCA specifications to draw these lines. What's in the SCA assembly spec
is part of the base, what's not in the SCA assembly spec is extensions.
But I could be convinced otherwise...
Thoughts?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: svn commit: r527581 - in /incubator/tuscany/java/sca/modules/host-embedded: pom.xml src/main/java/org/apache/tuscany/host/embedded/SimpleRuntimeImpl.java
Posted by Raymond Feng <en...@gmail.com>.
Hi,
I think we should start to leverage the extensibility story (see the thread
titled "The pluggability for Tuscany runtime extensions") instead of
hard-coding all the processors into the SimpleRuntimeImpl.
Thanks,
Raymond
----- Original Message -----
From: <js...@apache.org>
To: <tu...@ws.apache.org>
Sent: Wednesday, April 11, 2007 10:14 AM
Subject: svn commit: r527581 - in
/incubator/tuscany/java/sca/modules/host-embedded: pom.xml
src/main/java/org/apache/tuscany/host/embedded/SimpleRuntimeImpl.java
> Author: jsdelfino
> Date: Wed Apr 11 10:14:43 2007
> New Revision: 527581
>
> URL: http://svn.apache.org/viewvc?view=rev&rev=527581
> Log:
> Added missing processors for Java and WSDL interfaces.
>
> Modified:
> incubator/tuscany/java/sca/modules/host-embedded/pom.xml
>
> incubator/tuscany/java/sca/modules/host-embedded/src/main/java/org/apache/tuscany/host/embedded/SimpleRuntimeImpl.java
>
> Modified: incubator/tuscany/java/sca/modules/host-embedded/pom.xml
> URL:
> http://svn.apache.org/viewvc/incubator/tuscany/java/sca/modules/host-embedded/pom.xml?view=diff&rev=527581&r1=527580&r2=527581
> ==============================================================================
> --- incubator/tuscany/java/sca/modules/host-embedded/pom.xml (original)
> +++ incubator/tuscany/java/sca/modules/host-embedded/pom.xml Wed Apr 11
> 10:14:43 2007
> @@ -43,6 +43,18 @@
>
> <dependency>
> <groupId>org.apache.tuscany.sca</groupId>
> + <artifactId>tuscany-interface-java-xml</artifactId>
> + <version>1.0-incubating-SNAPSHOT</version>
> + </dependency>
> +
> + <dependency>
> + <groupId>org.apache.tuscany.sca</groupId>
> + <artifactId>tuscany-interface-wsdl-xml</artifactId>
> + <version>1.0-incubating-SNAPSHOT</version>
> + </dependency>
> +
> + <dependency>
> + <groupId>org.apache.tuscany.sca</groupId>
> <artifactId>tuscany-contribution-impl</artifactId>
> <version>1.0-incubating-SNAPSHOT</version>
> </dependency>
>
> Modified:
> incubator/tuscany/java/sca/modules/host-embedded/src/main/java/org/apache/tuscany/host/embedded/SimpleRuntimeImpl.java
> URL:
> http://svn.apache.org/viewvc/incubator/tuscany/java/sca/modules/host-embedded/src/main/java/org/apache/tuscany/host/embedded/SimpleRuntimeImpl.java?view=diff&rev=527581&r1=527580&r2=527581
> ==============================================================================
> ---
> incubator/tuscany/java/sca/modules/host-embedded/src/main/java/org/apache/tuscany/host/embedded/SimpleRuntimeImpl.java
> (original)
> +++
> incubator/tuscany/java/sca/modules/host-embedded/src/main/java/org/apache/tuscany/host/embedded/SimpleRuntimeImpl.java
> Wed Apr 11 10:14:43 2007
> @@ -38,6 +38,9 @@
> import org.apache.tuscany.core.component.SimpleWorkContext;
> import org.apache.tuscany.core.runtime.AbstractRuntime;
> import org.apache.tuscany.host.runtime.InitializationException;
> +import org.apache.tuscany.interfacedef.java.xml.JavaInterfaceProcessor;
> +import org.apache.tuscany.interfacedef.wsdl.xml.WSDLDocumentProcessor;
> +import org.apache.tuscany.interfacedef.wsdl.xml.WSDLInterfaceProcessor;
> import
> org.apache.tuscany.services.contribution.ContributionPackageProcessorRegistryImpl;
> import
> org.apache.tuscany.services.contribution.ContributionRepositoryImpl;
> import org.apache.tuscany.services.contribution.ContributionServiceImpl;
> @@ -45,7 +48,6 @@
> import
> org.apache.tuscany.services.contribution.processor.FolderContributionProcessor;
> import
> org.apache.tuscany.services.contribution.processor.JarContributionProcessor;
> import org.apache.tuscany.services.contribution.util.FileHelper;
> -import
> org.apache.tuscany.services.spi.contribution.ArtifactResolverRegistry;
> import
> org.apache.tuscany.services.spi.contribution.ContributionPackageProcessorRegistry;
> import
> org.apache.tuscany.services.spi.contribution.ContributionRepository;
> import org.apache.tuscany.services.spi.contribution.ContributionService;
> @@ -53,6 +55,7 @@
> import
> org.apache.tuscany.services.spi.contribution.DefaultStAXArtifactProcessorRegistry;
> import
> org.apache.tuscany.services.spi.contribution.DefaultURLArtifactProcessorRegistry;
> import
> org.apache.tuscany.services.spi.contribution.StAXArtifactProcessorRegistry;
> +import
> org.apache.tuscany.services.spi.contribution.URLArtifactProcessorRegistry;
> import org.apache.tuscany.spi.Scope;
> import org.apache.tuscany.spi.bootstrap.ExtensionPointRegistry;
> import org.apache.tuscany.spi.component.AtomicComponent;
> @@ -112,21 +115,21 @@
> public Component start() throws Exception {
> ExtensionPointRegistry extensionRegistry = new
> ExtensionPointRegistryImpl();
> ContributionRepository repository = new
> ContributionRepositoryImpl("target");
> - DefaultStAXArtifactProcessorRegistry registry = new
> DefaultStAXArtifactProcessorRegistry();
> - registry.addArtifactProcessor(new CompositeProcessor(registry));
> - registry.addArtifactProcessor(new
> ComponentTypeProcessor(registry));
> - registry.addArtifactProcessor(new
> ConstrainingTypeProcessor(registry));
> -
> -
> extensionRegistry.addExtensionPoint(StAXArtifactProcessorRegistry.class,
> registry);
> -
> - DefaultURLArtifactProcessorRegistry artifactRegistry = new
> DefaultURLArtifactProcessorRegistry();
> - CompositeDocumentProcessor compositeProcessor = new
> CompositeDocumentProcessor(registry);
> - ComponentTypeDocumentProcessor componentTypeProcessor = new
> ComponentTypeDocumentProcessor(registry);
> - ConstrainingTypeDocumentProcessor constrainingTypeProcessor = new
> ConstrainingTypeDocumentProcessor(registry);
> -
> - artifactRegistry.addArtifactProcessor(compositeProcessor);
> - artifactRegistry.addArtifactProcessor(componentTypeProcessor);
> - artifactRegistry.addArtifactProcessor(constrainingTypeProcessor);
> +
> + DefaultStAXArtifactProcessorRegistry staxExtensionPoint = new
> DefaultStAXArtifactProcessorRegistry();
> + staxExtensionPoint.addArtifactProcessor(new
> CompositeProcessor(staxExtensionPoint));
> + staxExtensionPoint.addArtifactProcessor(new
> ComponentTypeProcessor(staxExtensionPoint));
> + staxExtensionPoint.addArtifactProcessor(new
> ConstrainingTypeProcessor(staxExtensionPoint));
> + staxExtensionPoint.addArtifactProcessor(new
> JavaInterfaceProcessor());
> + staxExtensionPoint.addArtifactProcessor(new
> WSDLInterfaceProcessor());
> +
> extensionRegistry.addExtensionPoint(StAXArtifactProcessorRegistry.class,
> staxExtensionPoint);
> +
> + DefaultURLArtifactProcessorRegistry documentExtensionPoint = new
> DefaultURLArtifactProcessorRegistry();
> + documentExtensionPoint.addArtifactProcessor(new
> CompositeDocumentProcessor(staxExtensionPoint));
> + documentExtensionPoint.addArtifactProcessor(new
> ComponentTypeDocumentProcessor(staxExtensionPoint));
> + documentExtensionPoint.addArtifactProcessor(new
> ConstrainingTypeDocumentProcessor(staxExtensionPoint));
> + documentExtensionPoint.addArtifactProcessor(new
> WSDLDocumentProcessor());
> +
> extensionRegistry.addExtensionPoint(URLArtifactProcessorRegistry.class,
> documentExtensionPoint);
>
> PackageTypeDescriberImpl describer = new
> PackageTypeDescriberImpl();
> ContributionPackageProcessorRegistry pkgRegistry = new
> ContributionPackageProcessorRegistryImpl(describer);
> @@ -136,7 +139,7 @@
> DefaultArtifactResolver artifactResolver = new
> DefaultArtifactResolver();
>
> ContributionService contributionService =
> - new ContributionServiceImpl(repository, pkgRegistry,
> artifactRegistry, artifactResolver);
> + new ContributionServiceImpl(repository, pkgRegistry,
> documentExtensionPoint, artifactResolver);
>
> extensionRegistry.addExtensionPoint(ContributionService.class,
> contributionService);
> initialize(extensionRegistry, contributionService);
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-commits-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-commits-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org