date:20070411


Raymond,

I think this is good and simple to understand, but have some further 
comments inline :)


Raymond Feng wrote:

Hi,

As the core moves away from using SCA composite to compose the Tuscany 
system, we have been working on a simple way to extend the Tuscany 
system.


1) Define an ExtensionPointRegistry [1]

public interface ExtensionPointRegistry {
   T void addExtensionPoint(ClassT extensionPointType, T 
extensionPoint);

   T T getExtensionPoint(ClassT extensionPointType);
   void removeExtensionPoint(Class extensionPoint);
}


The extension point is identified by the interface. It can be defined 
by the Tuscany system or runtime modules. For example, 
BuilderRegistry, IntrospectionRegistry are two extension points.


I would suggest to rename these BuilderExtensionPoint and 
IntrospectionExtensionPoint. Also it would be good adopt a consistent 
pattern for these ExtensionPoints. I already started with some of these 
which now have addExtension / removeExtension methods.




2) The pluggability is contracted by the following interface: [2]

public interface ModuleActivator {
   MapClass, Object getExtensionPoints();
   void start(ExtensionPointRegistry registry);
   void stop(ExtensionPointRegistry registry);
}


Do we really need a Map? or can this just be an array?



The ModuleActivator represents a module that plugs into the Tuscany 
system. Each module should provide an implementation [3] of this 
interface and registry the implementation class by defining a file 
named as 
META-INF/services/org.apache.tuscany.spi.bootstrp.ModuleActivator 
[4]. The content of the file is the class name of the implementation. 
The implementation class must have a no-arg constructor. The same 
instance will be used to invoke all the methods during different 
phases of the module activation.




Can we rename this package to org.apache.tuscany.bootstrap. I think that 
we are currently using *.spi.* inconsistently, for example 
ModuleActivator is in an *.spi.* package, but BuilderRegistry is not, 
and both are SPIs, and finally all model interfaces are part of the SPIs 
too. Since pretty much all these interfaces are SPIs anyway, could we 
just remove the *.spi.* fragment?



During bootstraping, the following sequence will happen:

1) All the module activators will be discovered by the presence of 
META-INF/services/org.apache.tuscany.spi.bootstrp.ModuleActivator

2) The activator class is instantiated using the no-arg constructor.
3) ModuleActivator.getExtensionPoints() is invoked for all modules and 
the extension points contributed by each module are added to the 
ExtensionRegistry.
4) ModuleActivator.start(ExtensionRegistry) is invoked for all the 
modules. The module can then get interested extension points and 
contribute extensions to them. The contract bwteen the extension and 
extension point is private to the extension point. The extension point 
can follow similar patterns such as Registry. If it happens that one 
extension point has a dependency on another extension point, they can 
linked at this phase.


During shutting down, the stop() method is invoked for all the modules 
to perform cleanups. A module can choose to unregister the extension 
from the extension points.


Feedbacks are welcome.

Thanks,
Raymond

[1] 
http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/core-spi/src/main/java/org/apache/tuscany/spi/bootstrap/ExtensionPointRegistry.java 



[2] 
http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/core-spi/src/main/java/org/apache/tuscany/spi/bootstrap/ModuleActivator.java 



[3] 
http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/host-embedded/src/test/java/org/apache/tuscany/container/crud/CRUDModuleActivator.java 



[4] 
http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/host-embedded/src/test/resources/META-INF/services/org.apache.tuscany.spi.bootstrap.ModuleActivator 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
Jean-Sebastien


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Component types and loading them

I'm attempting the same thing just now for script components see [1].
Doesn't work yet, the .componentType file doesn't seem to get picked up.
Comments welcome...

...ant

[1]
https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/implementation-script/src/main/java/org/apache/tuscany/implementation/script/ScriptArtifactProcessor.java

On 4/11/07, Ignacio Silva-Lepe [EMAIL PROTECTED] wrote:

This sounds reasonable, except for a couple of errors I get. Details
inline.

On 4/11/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:

Jean-Sebastien Delfino wrote:
Ignacio Silva-Lepe wrote:
Ok, so to try to answer my own question, it looks like the
implementation
loader can use a ComponentTypeDocumentProcessor (passing itself in
the constructor) and then calling read with the URL of the component
type side file. Does this sound ok?

This can work, but there is probably a better way to do it, see my
comments below.

On 4/10/07, Ignacio Silva-Lepe [EMAIL PROTECTED] wrote:

How is this supposed to work now? Previously, an implementation
loader had the option of asking the loader registry to load a
component
type from a side file, and then it was able to downcast the returned
component type to an extension-specific component type.
Previously, an implementation Loader had to take care of the loading
the optional .componentType side file. However, I'm not sure what you
mean downcast the returned component type to an extension-specific
component type, how would you downcast it?

We are using ArtifactProcessors instead of Loaders now, and the
ArtifactProcessor for a particular extension does not need to load the
.componentType side file itself. Your ArtifactProcessor can do the
following:
1. In the read method, read the implementation artifact and turn it
into the relevant Implementation model object
2. In the resolve method, call ArtifactResolver.resolve() to resolve
the corresponding .componentType, and for example save a pointer to it
in your Implementation model
3. Then, in the wire() method, implement the logic to merge the info
from the .componentType and the info derived from the Implementation
artifact, for example in the case of a java component we may need to
reconcile references defined in the .componentType and the references
resulting from the introspection of the Java component implementation
class. This logic is really specific to your particular component
Implementation type.

I think that I need to make a small fix to
o.a.t.assembly.ComponentType and add a URI string to it for step (2)
to actually work correctly :) I'll send an update email describing how
to resolve the ComponentType once I commit that small fix.

Since a component type's file is a separate stream, how does an
implementation loader (as a StAXArtifactProcessor that it is) kick
off
a separate stream read? Is there a pattern for this, and is there an
exisiting component type reader that can be invoked? Or is this all
left as an exercise to the developer? Or perhaps this is coming but
not complete yet?

Thanks

Ignacio,

Under revision 527384, I added a URI field to ComponentType and
implemented ComponentTypeImpl.equals() to allow ComponentTypes to be
resolved by URI. This will allow you to do the following:

- in ArtifactProcessor.read(...):
YourImplementation implementation;
// Read your implementation object

// Form the URI of the expected .componentType file;
String uri = ...;

// Create a ComponentType and mark it unresolved
ComponentType componentType = assemblyFactory.createComponentType();

Where do I get assemblyFactory? Right now, my artifact processor
implements
StAXArtifactProcessorMyImplementation and does not extend any class, so
it cannot inherit assemblyFactory. Should it be extending anything. I am
using
CRUDImplementationLoader as a model, though I realize that the CRUD sample
does not use a separate component type.

componentType.setURI(uri);
componentType.setUnresolved(true);
implementation.setComponentType(componentType);

return implementation;

- in ArtifactProcessor.resolve(YourImplementation implementation,
ArtifactResolver resolver)
ComponentType componentType =
resolver.resolve(implementation.getComponentType());

ArtifactResolver.resolve does not seem to take a ComponentType and
so I get a compilation error here.

if (!componentType.isUnresolved()) {
// You got a .componentType file!
}

Hope this helps.

--
Jean-Sebastien

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Getting started with Tuscany databinding

2007-04-11 Thread Scott Kurz


Raymond,

Thanks for producing those documents.   They are helpful in learning the
concepts in this DB framework.

What I think would be really helpful in addition is to document some of the
API calls needed to make use of the framework, say as an implementor of a
binding on which you wish to establish a certain DB. In the past,
personally, I've failed any time I tried to do anything other than copy the
Axis2 binding's use of DB exactly.

How would you, for example, set a DOM Node type of DB on a new binding impl
such that an app using either SDO or JAXB could transform to XML?   If we
had a WSDL we could follow the Axis2 binding example exactly... but how
would you exploit the DB framework without one?

In trying this I did learn that the InterfaceWSDLIntrospectorImpl and
JavaInterfaceProcessorRegistryImpl are key in establishing the
o.a.t.spi.model.DataType-related objects.But every time I tried
something something would fail:   e.g. the post-processor wouldn't think it
needed to build a DBInterceptor at Composite-start or the DBInterceptor
wouldn't think it needed to do a transform at invocation time.


Scott





On 4/11/07, Raymond Feng [EMAIL PROTECTED] wrote:


Hi,

There is a slide at

http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/doc/tuscany.databinding.ppt
.
It's not up-to-date but it will provide you some basic ideas.

I have started a document-in-progress @
http://cwiki.apache.org/confluence/display/~rfeng/Tuscany+Databinding.

Thanks,
Raymond

- Original Message -
From: Pamela Fong [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Tuesday, April 10, 2007 3:52 PM
Subject: Getting started with Tuscany databinding


 Hi,

 Can someone provide some pointers on Tuscany databinding. It's not
 mentioned
 in the WIKI site and searching in the email archive doesn't seem to
yield
 anything. Is there any writeup, sample code that could help people new
in
 this area to get up-to-speed quickly? Thanks.

 -pam



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Which samples work?


Ok, so back in from Easter hols and I've debugged through the Calculator
sample with the newly organized trunk. You guys have been busy! I'd like to
get some more of the samples on line and hence learn more about how it
works. I was thinking of having a crack at composite-impl because this looks
like it doesn't have complicated bindings. Is this a good one to pick? Is
someone else working on it?

Regards

Simon

Re: Component types and loading them


Answers inline.

Ignacio Silva-Lepe wrote:
This sounds reasonable, except for a couple of errors I get. Details 
inline.


On 4/11/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:


Jean-Sebastien Delfino wrote:
 Ignacio Silva-Lepe wrote:
 Ok, so to try to answer my own question, it looks like the
 implementation
 loader can use a ComponentTypeDocumentProcessor (passing itself in
 the constructor) and then calling read with the URL of the component
 type side file. Does this sound ok?


 This can work, but there is probably a better way to do it, see my
 comments below.


 On 4/10/07, Ignacio Silva-Lepe [EMAIL PROTECTED] wrote:

 How is this supposed to work now? Previously, an implementation
 loader had the option of asking the loader registry to load a
component
 type from a side file, and then it was able to downcast the returned
 component type to an extension-specific component type.
 Previously, an implementation Loader had to take care of the loading
 the optional .componentType side file.  However, I'm not sure what you
 mean downcast the returned component type to an extension-specific
 component type, how would you downcast it?

 We are using ArtifactProcessors instead of Loaders now, and the
 ArtifactProcessor for a particular extension does not need to load the
 .componentType side file itself. Your ArtifactProcessor can do the
 following:
 1. In the read method, read the implementation artifact and turn it
 into the relevant Implementation model object
 2. In the resolve method, call ArtifactResolver.resolve() to resolve
 the corresponding .componentType, and for example save a pointer to it
 in your Implementation model
 3. Then, in the wire() method, implement the logic to merge the info
 from the .componentType and the info derived from the Implementation
 artifact, for example in the case of a java component we may need to
 reconcile references defined in the .componentType and the references
 resulting from the introspection of the Java component implementation
 class. This logic is really specific to your particular component
 Implementation type.

 I think that I need to make a small fix to
 o.a.t.assembly.ComponentType and add a URI string to it for step (2)
 to actually work correctly :) I'll send an update email describing how
 to resolve the ComponentType once I commit that small fix.


 Since a component type's file is a separate stream, how does an
 implementation loader (as a StAXArtifactProcessor that it is) 
kick off

 a separate stream read? Is there a pattern for this, and is there an
 exisiting component type reader that can be invoked? Or is this all
 left as an exercise to the developer? Or perhaps this is coming but
 not complete yet?

 Thanks






Ignacio,

Under revision 527384, I added a URI field to ComponentType and
implemented ComponentTypeImpl.equals() to allow ComponentTypes to be
resolved by URI. This will allow you to do the following:

- in ArtifactProcessor.read(...):
   YourImplementation implementation;
   // Read your implementation object
   

   // Form the URI of the expected .componentType file;
   String uri = ...;

   // Create a ComponentType and mark it unresolved
   ComponentType componentType = assemblyFactory.createComponentType();



Where do I get assemblyFactory? Right now, my artifact processor 
implements

StAXArtifactProcessorMyImplementation and does not extend any class, so
it cannot inherit assemblyFactory. Should it be extending anything. I am
using
CRUDImplementationLoader as a model, though I realize that the CRUD 
sample

does not use a separate component type.


It does not need to extend anything. Can you just pass the factory that 
you want to use to your ArtifactProcessor's constructor?


Also, you don't have to use the factory, it's up to you to choose to use 
a factory and then isolate yourself from a particular implementation of 
the model interfaces.




  componentType.setURI(uri);

   componentType.setUnresolved(true);
   implementation.setComponentType(componentType);

   return implementation;

- in ArtifactProcessor.resolve(YourImplementation implementation,
ArtifactResolver resolver)
   ComponentType componentType =
resolver.resolve(implementation.getComponentType());



ArtifactResolver.resolve does not seem to take a ComponentType and
so I get a compilation error here.


Sorry I forgot the first parameter :)
try resolver.resolve(ComponentType.class, implementation.getComponentType())



  if (!componentType.isUnresolved()) {

   // You got a .componentType file!
   }

Hope this helps.

--
Jean-Sebastien


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]







--
Jean-Sebastien


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Getting started with Tuscany databinding


Hi, Scott.

Thank you for the feedback. I think what's missing in the document is how 
the databinding framework works with the Tuscany core, especially the 
various interaction paths between component, composite service and composite 
reference.


I'll try to add more information as I port the databinding support to the 
latest code base.


Thanks,
Raymond

- Original Message - 
From: Scott Kurz [EMAIL PROTECTED]

To: tuscany-dev@ws.apache.org
Sent: Wednesday, April 11, 2007 8:15 AM
Subject: Re: Getting started with Tuscany databinding



Raymond,

Thanks for producing those documents.   They are helpful in learning the
concepts in this DB framework.

What I think would be really helpful in addition is to document some of 
the

API calls needed to make use of the framework, say as an implementor of a
binding on which you wish to establish a certain DB. In the past,
personally, I've failed any time I tried to do anything other than copy 
the

Axis2 binding's use of DB exactly.

How would you, for example, set a DOM Node type of DB on a new binding 
impl

such that an app using either SDO or JAXB could transform to XML?   If we
had a WSDL we could follow the Axis2 binding example exactly... but how
would you exploit the DB framework without one?

In trying this I did learn that the InterfaceWSDLIntrospectorImpl and
JavaInterfaceProcessorRegistryImpl are key in establishing the
o.a.t.spi.model.DataType-related objects.But every time I tried
something something would fail:   e.g. the post-processor wouldn't think 
it

needed to build a DBInterceptor at Composite-start or the DBInterceptor
wouldn't think it needed to do a transform at invocation time.


Scott





On 4/11/07, Raymond Feng [EMAIL PROTECTED] wrote:


Hi,

There is a slide at

http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/doc/tuscany.databinding.ppt
.
It's not up-to-date but it will provide you some basic ideas.

I have started a document-in-progress @
http://cwiki.apache.org/confluence/display/~rfeng/Tuscany+Databinding.

Thanks,
Raymond

- Original Message -
From: Pamela Fong [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Tuesday, April 10, 2007 3:52 PM
Subject: Getting started with Tuscany databinding


 Hi,

 Can someone provide some pointers on Tuscany databinding. It's not
 mentioned
 in the WIKI site and searching in the email archive doesn't seem to
yield
 anything. Is there any writeup, sample code that could help people new
in
 this area to get up-to-speed quickly? Thanks.

 -pam



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]







-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Component types and loading them


ant elder wrote:

I'm attempting the same thing just now for script components see [1].
Doesn't work yet, the .componentType file doesn't seem to get picked up.
Comments welcome...

 ...ant

[1]
https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/implementation-script/src/main/java/org/apache/tuscany/implementation/script/ScriptArtifactProcessor.java 





Can you see a .componentType being loaded at all? Is 
ComponentTypeDocumentProcessor called to process .componentType 
documents in your SCA contribution? If not then maybe Luciano can jump 
in here and take a look as the processors are triggered by the 
Contribution service...


--
Jean-Sebastien


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Can tuscany M2 support hierarchy structure?


Hi,

Yes, we do support recursive composites in M2.

As you use jarLocation to reference another jar, the code tries to create 
a URL based on the URL of the current SCDL:


jarUrl = new URL(deploymentContext.getScdlLocation(), jarLocation);
impl.setScdlLocation(new URL(jar: + jarUrl.toExternalForm() + 
!/META-INF/sca/default.scdl));


Would it be possible that you can debug to dump out the malformed URL? If 
so, we can better understand what went wrong.


Thanks,
Raymond

- Original Message - 
From: Hu hao [EMAIL PROTECTED]

To: tuscany-dev@ws.apache.org
Sent: Tuesday, April 10, 2007 1:45 AM
Subject: Can tuscany M2 support hierarchy structure?



Hi ,

The default.scdl in the application:

?xml version=1.0 encoding=ASCII?
composite xmlns=http://www.osoa.org/xmlns/sca/1.0; 
name=SCAImplHello

   component name=TestComponent
   implementation.composite  jarLocation=lib/HelloComposite1.jar
   name=HelloComposite1 /
   service name=helloService1 /
   /component
/composite

default.scdl in HelloComposite1.jar
?xml version=1.0 encoding=ASCII?
composite xmlns=http://www.osoa.org/xmlns/sca/1.0;
   name=HelloComposite1
   service multiplicity=0..1 name=helloService1
   referenceHelloComponent1/reference
   interface.java conversational=false
   interface=com.ibm.crl.sca.Hello remotable=false /
   /service
   component name=HelloComponent1
   implementation.composite jarLocation=lib/HelloComposite.jar
   name=HelloComposite /
   service name=helloCompositeService /
   /component
/composite

default.scdl in HelloComposite.jar
?xml version=1.0 encoding=ASCII?
composite xmlns=http://www.osoa.org/xmlns/sca/1.0;
   name=HelloComposite
   service multiplicity=0..1 name=helloCompositeService
   referenceHelloComponent/reference
   interface.java conversational=false
   interface=com.ibm.crl.sca.Hello remotable=false /
   /service
   component name=HelloComponent
   implementation.java class=com.ibm.crl.sca.HelloImpl /
   service name=helloService /
   /component
/composite

this is the exception throws by tuscany:

org.apache.tuscany.spi.loader.LoaderException:
java.net.MalformedURLException: no !/ in spec
Context stack trace: [Web Application -
SCAImplHello][TestComponent][HelloComponent1]
org.apache.tuscany.runtime.webapp.ServletLauncherInitException:
org.apache.tuscany.spi.loader.LoaderException:
java.net.MalformedURLException: no !/ in spec
Context stack trace: [Web Application -
SCAImplHello][TestComponent][HelloComponent1]
   at org.apache.tuscany.runtime.webapp.WebappRuntimeImpl.initialize(
WebappRuntimeImpl.java:147)
   at
org.apache.tuscany.runtime.webapp.TuscanyContextListener.contextInitialized(
TuscanyContextListener.java:74)
   at org.apache.catalina.core.StandardContext.listenerStart(
StandardContext.java:3729)
   at org.apache.catalina.core.StandardContext.start(StandardContext.java
:4187)
   at 
org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1013)

   at org.apache.catalina.core.StandardHost.start(StandardHost.java:718)
   at 
org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1013)

   at org.apache.catalina.core.StandardEngine.start(StandardEngine.java
:442)
   at org.apache.catalina.core.StandardService.start(StandardService.java
:450)
   at org.apache.catalina.core.StandardServer.start(StandardServer.java
:709)
   at org.apache.catalina.startup.Catalina.start(Catalina.java:551)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at sun.reflect.NativeMethodAccessorImpl.invoke(
NativeMethodAccessorImpl.java:39)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(
DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:294)
   at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:432)
Caused by: org.apache.tuscany.spi.loader.LoaderException:
java.net.MalformedURLException: no !/ in spec
Context stack trace: [Web Application -
SCAImplHello][TestComponent][HelloComponent1]
   at org.apache.tuscany.core.loader.LoaderRegistryImpl.load(
LoaderRegistryImpl.java:132)
   at
org.apache.tuscany.core.implementation.composite.CompositeComponentTypeLoader.loadFromSidefile
(CompositeComponentTypeLoader.java:65)
   at
org.apache.tuscany.core.implementation.composite.CompositeComponentTypeLoader.load
(CompositeComponentTypeLoader.java:57)
   at
org.apache.tuscany.core.implementation.composite.CompositeComponentTypeLoader.load
(CompositeComponentTypeLoader.java:39)
   at org.apache.tuscany.core.loader.LoaderRegistryImpl.loadComponentType(
LoaderRegistryImpl.java:159)
   at org.apache.tuscany.core.loader.ComponentLoader.load(
ComponentLoader.java:128)
   at org.apache.tuscany.core.loader.ComponentLoader.load(
ComponentLoader.java:70)
   at org.apache.tuscany.core.loader.LoaderRegistryImpl.load(
LoaderRegistryImpl.java:92)
   at

Re: Which samples work?


Simon Laws wrote:

Ok, so back in from Easter hols and I've debugged through the Calculator
sample with the newly organized trunk. You guys have been busy! I'd 
like to

get some more of the samples on line and hence learn more about how it
works. I was thinking of having a crack at composite-impl because this 
looks

like it doesn't have complicated bindings. Is this a good one to pick? Is
someone else working on it?

Regards

Simon



Yes, it looks like a good one to me. Once bindings have been brought 
back up then we'll be able to run many more samples, but for now it's 
probably best to start with the samples that only exercise composition 
and Java components.


--
Jean-Sebastien


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Which samples work?


On 4/11/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:


Simon Laws wrote:
 Ok, so back in from Easter hols and I've debugged through the Calculator
 sample with the newly organized trunk. You guys have been busy! I'd
 like to
 get some more of the samples on line and hence learn more about how it
 works. I was thinking of having a crack at composite-impl because this
 looks
 like it doesn't have complicated bindings. Is this a good one to pick?
Is
 someone else working on it?

 Regards

 Simon


Yes, it looks like a good one to me. Once bindings have been brought
back up then we'll be able to run many more samples, but for now it's
probably best to start with the samples that only exercise composition
and Java components.

--
Jean-Sebastien


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

great - thanks jean-sebastien. I'll give it a go.


Simon

Please review WSDL introspection code, Re: svn commit: r527397

Could somebody familiar with the Databinding framework and the DataType 
support in particular review how I ported the WSDLIntrospector and 
WSDLOperation to the new SPIs?


I had to remove some usage of generics since OperationDataType has 
changed to Operation.


Also I am not sure if I am setting the inputType and outputType 
correctly on the operation, in particular if the WSDL is a 
doc-literal-wrapped style WSDL, do we need to unwrap the wrapper like I 
did or not?


And finally how is the DataBinding field on an inputType used? is 
DataBinding == idl:input correct?


Thanks...

[EMAIL PROTECTED] wrote:

Author: jsdelfino
Date: Tue Apr 10 23:26:26 2007
New Revision: 527397

URL: http://svn.apache.org/viewvc?view=revrev=527397
Log:
Ported WSDL interface introspector to the latest SPIs and integrated it with 
the WSDLInterfaceProcessor.

Added:

incubator/tuscany/java/sca/modules/interface-wsdl-xml/src/main/java/org/apache/tuscany/interfacedef/wsdl/introspect/

incubator/tuscany/java/sca/modules/interface-wsdl-xml/src/main/java/org/apache/tuscany/interfacedef/wsdl/introspect/DefaultWSDLInterfaceIntrospector.java
   (with props)

incubator/tuscany/java/sca/modules/interface-wsdl-xml/src/main/java/org/apache/tuscany/interfacedef/wsdl/introspect/DefaultXMLSchemaRegistry.java
   (with props)

incubator/tuscany/java/sca/modules/interface-wsdl-xml/src/main/java/org/apache/tuscany/interfacedef/wsdl/introspect/InvalidWSDLException.java
   (with props)

incubator/tuscany/java/sca/modules/interface-wsdl-xml/src/main/java/org/apache/tuscany/interfacedef/wsdl/introspect/WSDLInterfaceIntrospector.java
   (with props)

incubator/tuscany/java/sca/modules/interface-wsdl-xml/src/main/java/org/apache/tuscany/interfacedef/wsdl/introspect/WSDLOperation.java
   (with props)

incubator/tuscany/java/sca/modules/interface-wsdl-xml/src/main/java/org/apache/tuscany/interfacedef/wsdl/introspect/XMLSchemaRegistry.java
   (with props)
Modified:

incubator/tuscany/java/sca/modules/interface-wsdl-xml/src/main/java/org/apache/tuscany/interfacedef/wsdl/xml/WSDLInterfaceProcessor.java
incubator/tuscany/java/sca/modules/interface-wsdl/pom.xml

incubator/tuscany/java/sca/modules/interface/src/main/java/org/apache/tuscany/interfacedef/util/WrapperInfo.java

Added: 
incubator/tuscany/java/sca/modules/interface-wsdl-xml/src/main/java/org/apache/tuscany/interfacedef/wsdl/introspect/DefaultWSDLInterfaceIntrospector.java
URL: 
http://svn.apache.org/viewvc/incubator/tuscany/java/sca/modules/interface-wsdl-xml/src/main/java/org/apache/tuscany/interfacedef/wsdl/introspect/DefaultWSDLInterfaceIntrospector.java?view=autorev=527397
==
--- 
incubator/tuscany/java/sca/modules/interface-wsdl-xml/src/main/java/org/apache/tuscany/interfacedef/wsdl/introspect/DefaultWSDLInterfaceIntrospector.java
 (added)
+++ 
incubator/tuscany/java/sca/modules/interface-wsdl-xml/src/main/java/org/apache/tuscany/interfacedef/wsdl/introspect/DefaultWSDLInterfaceIntrospector.java
 Tue Apr 10 23:26:26 2007
@@ -0,0 +1,69 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements.  See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership.  The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * License); you may not use this file except in compliance
+ * with the License.  You may obtain a copy of the License at
+ * 
+ *   http://www.apache.org/licenses/LICENSE-2.0
+ * 
+ * Unless required by applicable law or agreed to in writing,

+ * software distributed under the License is distributed on an
+ * AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied.  See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */

+
+package org.apache.tuscany.interfacedef.wsdl.introspect;
+
+import java.util.ArrayList;
+import java.util.List;
+
+import javax.wsdl.PortType;
+
+import org.apache.tuscany.interfacedef.InvalidInterfaceException;
+import org.apache.tuscany.interfacedef.Operation;
+import org.apache.tuscany.interfacedef.wsdl.WSDLInterface;
+import org.apache.tuscany.interfacedef.wsdl.impl.WSDLInterfaceImpl;
+
+/**
+ * Introspector for creating WSDLInterface definitions from WSDL PortTypes.
+ */
+public class DefaultWSDLInterfaceIntrospector implements 
WSDLInterfaceIntrospector {
+
+private XMLSchemaRegistry schemaRegistry;

+
+public DefaultWSDLInterfaceIntrospector(XMLSchemaRegistry schemaRegistry) {
+super();
+this.schemaRegistry = schemaRegistry;
+}
+
+// FIXME: Do we want to deal with document-literal wrapped style based on 
the JAX-WS spec?
+protected ListOperation introspectOperations(PortType portType) throws 
InvalidInterfaceException {
+ListOperation operations = new

Re: Component types and loading them


On 4/11/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:


ant elder wrote:
 I'm attempting the same thing just now for script components see [1].
 Doesn't work yet, the .componentType file doesn't seem to get picked up.
 Comments welcome...

  ...ant

 [1]

https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/implementation-script/src/main/java/org/apache/tuscany/implementation/script/ScriptArtifactProcessor.java



Can you see a .componentType being loaded at all? Is
ComponentTypeDocumentProcessor called to process .componentType
documents in your SCA contribution? If not then maybe Luciano can jump
in here and take a look as the processors are triggered by the
Contribution service...



I'm still debugging and trying to understand how this should work so can't
articulate well whats going on yet..but so far it looks like in the
SimpleRuntimeImpl start method there are two artifact processor registries
created, and the one where the ComponentTypeProcessor is added to is not the
one that processes the contribution so the .componentType side file is
ignored. Does that make any sense?

  ...ant

Re: Component types and loading them


Yes, I think you are right about the registry where the
componentTypeProcessor is being ignored and not passed to the
contributionService. Let me see if I can find a quick solution...

On 4/11/07, ant elder [EMAIL PROTECTED] wrote:


On 4/11/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:

 ant elder wrote:
  I'm attempting the same thing just now for script components see [1].
  Doesn't work yet, the .componentType file doesn't seem to get picked
up.
  Comments welcome...
 
   ...ant
 
  [1]
 

https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/implementation-script/src/main/java/org/apache/tuscany/implementation/script/ScriptArtifactProcessor.java
 
 

 Can you see a .componentType being loaded at all? Is
 ComponentTypeDocumentProcessor called to process .componentType
 documents in your SCA contribution? If not then maybe Luciano can jump
 in here and take a look as the processors are triggered by the
 Contribution service...


I'm still debugging and trying to understand how this should work so can't
articulate well whats going on yet..but so far it looks like in the
SimpleRuntimeImpl start method there are two artifact processor registries
created, and the one where the ComponentTypeProcessor is added to is not
the
one that processes the contribution so the .componentType side file is
ignored. Does that make any sense?

   ...ant





--
Luciano Resende
http://people.apache.org/~lresende

Re: Component types and loading them


ant elder wrote:

On 4/11/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:


ant elder wrote:
 I'm attempting the same thing just now for script components see [1].
 Doesn't work yet, the .componentType file doesn't seem to get 
picked up.

 Comments welcome...

  ...ant

 [1]

https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/implementation-script/src/main/java/org/apache/tuscany/implementation/script/ScriptArtifactProcessor.java 





Can you see a .componentType being loaded at all? Is
ComponentTypeDocumentProcessor called to process .componentType
documents in your SCA contribution? If not then maybe Luciano can jump
in here and take a look as the processors are triggered by the
Contribution service...



I'm still debugging and trying to understand how this should work so 
can't

articulate well whats going on yet..but so far it looks like in the
SimpleRuntimeImpl start method there are two artifact processor 
registries
created, and the one where the ComponentTypeProcessor is added to is 
not the

one that processes the contribution so the .componentType side file is
ignored. Does that make any sense?

  ...ant



Yes it makes sense, the SimpleRuntimeImpl is missing the registration of 
the ComponentTypeDocumentProcessor, I added it under revision r527566. 
Can you update and try again? Thanks.


--
Jean-Sebastien


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Please review WSDL introspection code, Re: svn commit: r527397


Hi,

Please see my comments inline.

Thanks,
Raymond

- Original Message - 
From: Jean-Sebastien Delfino [EMAIL PROTECTED]

To: tuscany-dev@ws.apache.org
Sent: Wednesday, April 11, 2007 9:09 AM
Subject: Please review WSDL introspection code, Re: svn commit: r527397


Could somebody familiar with the Databinding framework and the DataType 
support in particular review how I ported the WSDLIntrospector and 
WSDLOperation to the new SPIs?


I had to remove some usage of generics since OperationDataType has 
changed to Operation.




Yes.

Also I am not sure if I am setting the inputType and outputType correctly 
on the operation, in particular if the WSDL is a doc-literal-wrapped style 
WSDL, do we need to unwrap the wrapper like I did or not?




We don't need to unwrap the wrapper for the operation model. The signature 
of the operation should be the same as defined by the IDL. I'll fix it.


And finally how is the DataBinding field on an inputType used? is 
DataBinding == idl:input correct?




Yes.


Thanks...

[EMAIL PROTECTED] wrote:

Author: jsdelfino
Date: Tue Apr 10 23:26:26 2007
New Revision: 527397

URL: http://svn.apache.org/viewvc?view=revrev=527397
Log:
Ported WSDL interface introspector to the latest SPIs and integrated it 
with the WSDLInterfaceProcessor.


Added:

incubator/tuscany/java/sca/modules/interface-wsdl-xml/src/main/java/org/apache/tuscany/interfacedef/wsdl/introspect/

incubator/tuscany/java/sca/modules/interface-wsdl-xml/src/main/java/org/apache/tuscany/interfacedef/wsdl/introspect/DefaultWSDLInterfaceIntrospector.java 
(with props)


incubator/tuscany/java/sca/modules/interface-wsdl-xml/src/main/java/org/apache/tuscany/interfacedef/wsdl/introspect/DefaultXMLSchemaRegistry.java 
(with props)


incubator/tuscany/java/sca/modules/interface-wsdl-xml/src/main/java/org/apache/tuscany/interfacedef/wsdl/introspect/InvalidWSDLException.java 
(with props)


incubator/tuscany/java/sca/modules/interface-wsdl-xml/src/main/java/org/apache/tuscany/interfacedef/wsdl/introspect/WSDLInterfaceIntrospector.java 
(with props)


incubator/tuscany/java/sca/modules/interface-wsdl-xml/src/main/java/org/apache/tuscany/interfacedef/wsdl/introspect/WSDLOperation.java 
(with props)


incubator/tuscany/java/sca/modules/interface-wsdl-xml/src/main/java/org/apache/tuscany/interfacedef/wsdl/introspect/XMLSchemaRegistry.java 
(with props)

Modified:

incubator/tuscany/java/sca/modules/interface-wsdl-xml/src/main/java/org/apache/tuscany/interfacedef/wsdl/xml/WSDLInterfaceProcessor.java
incubator/tuscany/java/sca/modules/interface-wsdl/pom.xml

incubator/tuscany/java/sca/modules/interface/src/main/java/org/apache/tuscany/interfacedef/util/WrapperInfo.java

Added: 
incubator/tuscany/java/sca/modules/interface-wsdl-xml/src/main/java/org/apache/tuscany/interfacedef/wsdl/introspect/DefaultWSDLInterfaceIntrospector.java
URL: 
http://svn.apache.org/viewvc/incubator/tuscany/java/sca/modules/interface-wsdl-xml/src/main/java/org/apache/tuscany/interfacedef/wsdl/introspect/DefaultWSDLInterfaceIntrospector.java?view=autorev=527397

==
---  
incubator/tuscany/java/sca/modules/interface-wsdl-xml/src/main/java/org/apache/tuscany/interfacedef/wsdl/introspect/DefaultWSDLInterfaceIntrospector.java 
(added)
+++ 
incubator/tuscany/java/sca/modules/interface-wsdl-xml/src/main/java/org/apache/tuscany/interfacedef/wsdl/introspect/DefaultWSDLInterfaceIntrospector.java 
Tue Apr 10 23:26:26 2007

@@ -0,0 +1,69 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements.  See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership.  The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * License); you may not use this file except in compliance
+ * with the License.  You may obtain a copy of the License at
+ * + *   http://www.apache.org/licenses/LICENSE-2.0
+ * + * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied.  See the License for the
+ * specific language governing permissions and limitations
+ * under the License.+ */
+
+package org.apache.tuscany.interfacedef.wsdl.introspect;
+
+import java.util.ArrayList;
+import java.util.List;
+
+import javax.wsdl.PortType;
+
+import org.apache.tuscany.interfacedef.InvalidInterfaceException;
+import org.apache.tuscany.interfacedef.Operation;
+import org.apache.tuscany.interfacedef.wsdl.WSDLInterface;
+import org.apache.tuscany.interfacedef.wsdl.impl.WSDLInterfaceImpl;
+
+/**
+ * Introspector for creating WSDLInterface definitions from WSDL 
PortTypes.

+ */
+public class DefaultWSDLInterfaceIntrospector implements 
WSDLInterfaceIntrospector {

++private XMLSchemaRegistry schemaRegistry;
+
+public

Re: svn commit: r527581 - in /incubator/tuscany/java/sca/modules/host-embedded: pom.xml src/main/java/org/apache/tuscany/host/embedded/SimpleRuntimeImpl.java


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: [EMAIL PROTECTED]

To: tuscany-commits@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=revrev=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=diffrev=527581r1=527580r2=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
groupIdorg.apache.tuscany.sca/groupId
+artifactIdtuscany-interface-java-xml/artifactId
+version1.0-incubating-SNAPSHOT/version
+/dependency
+
+dependency
+groupIdorg.apache.tuscany.sca/groupId
+artifactIdtuscany-interface-wsdl-xml/artifactId
+version1.0-incubating-SNAPSHOT/version
+/dependency
+
+dependency
+groupIdorg.apache.tuscany.sca/groupId
artifactIdtuscany-contribution-impl/artifactId
version1.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=diffrev=527581r1=527580r2=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

Eclipse project generation


To debug the calculator sample I did a mvn -Peclipse eclipse:eclipse in
java/sca and imported the calculator sample project and all dependecy
projects, into eclipse.  Is there a way of generating the workspace
automatically to avoid the import step? Looking at the eclipse plugin
documentation there doesn't seem to be an option.

Regards

Simon

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: [EMAIL PROTECTED]
To: tuscany-commits@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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: svn commit: r527581 - in /incubator/tuscany/java/sca/modules/host-embedded: pom.xml src/main/java/org/apache/tuscany/host/embedded/SimpleRuntimeImpl.java


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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED]
To: tuscany-commits@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=revrev=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=diffrev=527581r1=527580r2=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
 groupIdorg.apache.tuscany.sca/groupId
 +artifactIdtuscany-interface-java-xml/artifactId
 +version1.0-incubating-SNAPSHOT/version
 +/dependency
 +
 +dependency
 +groupIdorg.apache.tuscany.sca/groupId
 +artifactIdtuscany-interface-wsdl-xml/artifactId
 +version1.0-incubating-SNAPSHOT/version
 +/dependency
 +
 +dependency
 +groupIdorg.apache.tuscany.sca/groupId
 artifactIdtuscany-contribution-impl/artifactId
 version1.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=diffrev=527581r1=527580r2=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 {

Re: Should host-embedded depend on the WSDL and Java interface support? was: svn commit: r527581


I just sent a similar answer to Raymond's original e-mail.

On 4/11/07, Jean-Sebastien Delfino [EMAIL PROTECTED] 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: [EMAIL PROTECTED]
 To: tuscany-commits@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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
Luciano Resende
http://people.apache.org/~lresende

Re: Eclipse project generation


Look at how people is doing in Apache Abdera
https://svn.apache.org/repos/asf/incubator/abdera/java/trunk/BUILDING

I think you can use :

mvn -Declipse.workspace=/path/to/workspace eclipse:eclipse



On 4/11/07, Simon Laws [EMAIL PROTECTED] wrote:


To debug the calculator sample I did a mvn -Peclipse eclipse:eclipse in
java/sca and imported the calculator sample project and all dependecy
projects, into eclipse.  Is there a way of generating the workspace
automatically to avoid the import step? Looking at the eclipse plugin
documentation there doesn't seem to be an option.

Regards

Simon





--
Luciano Resende
http://people.apache.org/~lresende

Re: svn commit: r527581 - in /incubator/tuscany/java/sca/modules/host-embedded: pom.xml src/main/java/org/apache/tuscany/host/embedded/SimpleRuntimeImpl.java


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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED]
To: tuscany-commits@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=revrev=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=diffrev=527581r1=527580r2=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
 groupIdorg.apache.tuscany.sca/groupId
 +artifactIdtuscany-interface-java-xml/artifactId
 +version1.0-incubating-SNAPSHOT/version
 +/dependency
 +
 +dependency
 +groupIdorg.apache.tuscany.sca/groupId
 +artifactIdtuscany-interface-wsdl-xml/artifactId
 +version1.0-incubating-SNAPSHOT/version
 +/dependency
 +
 +dependency
 +groupIdorg.apache.tuscany.sca/groupId
 artifactIdtuscany-contribution-impl/artifactId
 version1.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=diffrev=527581r1=527580r2=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

JAVA_SCA_M2 slides

2007-04-11 Thread Salvucci, Sebastian

Hello,

I uploaded a document to
http://cwiki.apache.org/confluence/download/attachments/47512/TuscanyJAV
ASCA.pdf which contains some slides about Java SCA Runtime. They are
based on M2 but perhaps some graphics could serve to be reused for the
web site or future documentation.

Regards,

 

Sebastian Salvucci

Re: Eclipse project generation


On 4/11/07, Luciano Resende [EMAIL PROTECTED] wrote:


Look at how people is doing in Apache Abdera
https://svn.apache.org/repos/asf/incubator/abdera/java/trunk/BUILDING

I think you can use :

mvn -Declipse.workspace=/path/to/workspace eclipse:eclipse



On 4/11/07, Simon Laws [EMAIL PROTECTED] wrote:

 To debug the calculator sample I did a mvn -Peclipse eclipse:eclipse in
 java/sca and imported the calculator sample project and all dependecy
 projects, into eclipse.  Is there a way of generating the workspace
 automatically to avoid the import step? Looking at the eclipse plugin
 documentation there doesn't seem to be an option.

 Regards

 Simon




--
Luciano Resende
http://people.apache.org/~lresende


Thanks Luciano for pointing that out. I tried it and it seems to be tryting
to do the right sort of thing but not quite getting all the way, i.e. the
resulting workspace doesn't load with projects in it. As their advice is to
start with the manual import I'll stick with what I have for now and
investigate alternatives in the future.

Regards

Simon

Re: Should host-embedded depend on the WSDL and Java interface support? was: svn commit: r527581


On 4/11/07, Jean-Sebastien Delfino [EMAIL PROTECTED] 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: [EMAIL PROTECTED]
 To: tuscany-commits@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


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 [EMAIL PROTECTED]

To: tuscany-dev@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: [EMAIL PROTECTED]
To: tuscany-commits@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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Should host-embedded depend on the WSDL and Java interface support? was: svn commit: r527581


ant elder wrote:

On 4/11/07, Jean-Sebastien Delfino [EMAIL PROTECTED] 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: [EMAIL PROTECTED]
 To: tuscany-commits@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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DAS rdb - BUILD ERROR - missing org.apache.tuscany.das:tuscany-das-rdb:jar:1.0-incubator-SNAPSHOT

2007-04-11 Thread Paulo Henrique Trecenti


Hello,

I try build the last version of tuscany java and I have the message on the
build processing. I knot solve that:

Downloading:
http://ws.zones.apache.org/repository/org.apache.tuscany.das/jars/t
uscany-das-rdb-1.0-incubator-SNAPSHOT.jar
[INFO]

[ERROR] BUILD ERROR
[INFO]

[INFO] Failed to resolve artifact.

Missing:
--
1) org.apache.tuscany.das:tuscany-das-rdb:jar:1.0-incubator-SNAPSHOT

 Try downloading the file manually from the project website.

 Then, install it using the command:
 mvn install:install-file -DgroupId=org.apache.tuscany.das-DartifactId=tus
cany-das-rdb \
 -Dversion=1.0-incubator-SNAPSHOT -Dpackaging=jar
-Dfile=/path/to/file

 Path to dependency:
   1)
org.apache.tuscany.das.samples:sample-companyweb:war:1.0-incubator-SN
APSHOT
   2) org.apache.tuscany.das:tuscany-das-rdb:jar:1.0-incubator-SNAPSHOT

--
1 required artifact is missing.

for artifact:

org.apache.tuscany.das.samples:sample-companyweb:war:1.0-incubator-SNAPSHOT

from the specified remote repositories:
 central (http://repo1.maven.org/maven2),
 apache.incubator (http://people.apache.org/repo/m2-incubating-repository/
),
 apache.ws.m1.snapshots (http://ws.zones.apache.org/repository),
 apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository)

--
Paulo Henrique Trecenti

Sorry about the bad English.

Re: DAS rdb - BUILD ERROR - missing org.apache.tuscany.das:tuscany-das-rdb:jar:1.0-incubator-SNAPSHOT


I'm still investigating this problem, it goes away if you actually build
from inside java/das, then everything goes back to normal.

On 4/11/07, Paulo Henrique Trecenti [EMAIL PROTECTED] wrote:


Hello,

I try build the last version of tuscany java and I have the message on the
build processing. I knot solve that:

Downloading:
http://ws.zones.apache.org/repository/org.apache.tuscany.das/jars/t
uscany-das-rdb-1.0-incubator-SNAPSHOT.jar
[INFO]

[ERROR] BUILD ERROR
[INFO]

[INFO] Failed to resolve artifact.

Missing:
--
1) org.apache.tuscany.das:tuscany-das-rdb:jar:1.0-incubator-SNAPSHOT

  Try downloading the file manually from the project website.

  Then, install it using the command:
  mvn install:install-file -DgroupId=
org.apache.tuscany.das-DartifactId=tus
cany-das-rdb \
  -Dversion=1.0-incubator-SNAPSHOT -Dpackaging=jar
-Dfile=/path/to/file

  Path to dependency:
1)
org.apache.tuscany.das.samples:sample-companyweb:war:1.0-incubator-SN
APSHOT
2)
org.apache.tuscany.das:tuscany-das-rdb:jar:1.0-incubator-SNAPSHOT

--
1 required artifact is missing.

for artifact:


org.apache.tuscany.das.samples:sample-companyweb:war:1.0-incubator-SNAPSHOT

from the specified remote repositories:
  central (http://repo1.maven.org/maven2),
  apache.incubator (
http://people.apache.org/repo/m2-incubating-repository/
),
  apache.ws.m1.snapshots (http://ws.zones.apache.org/repository),
  apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository)

--
Paulo Henrique Trecenti

Sorry about the bad English.





--
Luciano Resende
http://people.apache.org/~lresende

Re: DAS rdb - BUILD ERROR - missing org.apache.tuscany.das:tuscany-das-rdb:jar:1.0-incubator-SNAPSHOT

2007-04-11 Thread Paulo Henrique Trecenti


Inside java/das I first run mvn clean then I run mvn and the message is:

[INFO] [surefire:test]
[INFO] Surefire report directory:
C:\Ambiente\lib\tuscany\java\das\rdb\target\su
refire-reports
[INFO]

[ERROR] FATAL ERROR
[INFO]

[INFO] null
[INFO]

[INFO] Trace
java.lang.IllegalArgumentException
   at java.lang.ProcessImpl.init(ProcessImpl.java:69)
   at java.lang.ProcessImpl.start(ProcessImpl.java:30)
   at java.lang.ProcessBuilder.start(ProcessBuilder.java:451)
   at java.lang.Runtime.exec(Runtime.java:591)
   at org.codehaus.plexus.util.cli.Commandline.execute(Commandline.java
:653
)
   at org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine
(Comm
andLineUtils.java:102)
   at org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine
(Comm
andLineUtils.java:89)
   at org.apache.maven.surefire.booter.SurefireBooter.fork(
SurefireBooter.j
ava:554)
   at org.apache.maven.surefire.booter.SurefireBooter.forkSuites
(SurefireBo
oter.java:413)
   at org.apache.maven.surefire.booter.SurefireBooter.runSuitesForkOnce
(Sur
efireBooter.java:313)
   at org.apache.maven.surefire.booter.SurefireBooter.run(
SurefireBooter.ja
va:203)
   at org.apache.maven.plugin.surefire.SurefirePlugin.execute
(SurefirePlugi
n.java:398)
   at org.apache.maven.plugin.DefaultPluginManager.executeMojo
(DefaultPlugi
nManager.java:443)
   at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals
(Defa
ultLifecycleExecutor.java:539)
   at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLi
fecycle(DefaultLifecycleExecutor.java:480)
   at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal
(Defau
ltLifecycleExecutor.java:459)
   at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan
dleFailures(DefaultLifecycleExecutor.java:311)
   at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen
ts(DefaultLifecycleExecutor.java:278)
   at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute
(DefaultLi
fecycleExecutor.java:143)
   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334)
   at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125)
   at org.apache.maven.cli.MavenCli.main(MavenCli.java:272)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.
java:39)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAcces
sorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java
:315)
   at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
   at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java
:430)

   at org.codehaus.classworlds.Launcher.main(Launcher.java:375)

2007/4/11, Luciano Resende [EMAIL PROTECTED]:


I'm still investigating this problem, it goes away if you actually build
from inside java/das, then everything goes back to normal.

On 4/11/07, Paulo Henrique Trecenti [EMAIL PROTECTED] wrote:

 Hello,

 I try build the last version of tuscany java and I have the message on
the
 build processing. I knot solve that:

 Downloading:
 http://ws.zones.apache.org/repository/org.apache.tuscany.das/jars/t
 uscany-das-rdb-1.0-incubator-SNAPSHOT.jar
 [INFO]
 
 [ERROR] BUILD ERROR
 [INFO]
 
 [INFO] Failed to resolve artifact.

 Missing:
 --
 1) org.apache.tuscany.das:tuscany-das-rdb:jar:1.0-incubator-SNAPSHOT

   Try downloading the file manually from the project website.

   Then, install it using the command:
   mvn install:install-file -DgroupId=
 org.apache.tuscany.das-DartifactId=tus
 cany-das-rdb \
   -Dversion=1.0-incubator-SNAPSHOT -Dpackaging=jar
 -Dfile=/path/to/file

   Path to dependency:
 1)
 org.apache.tuscany.das.samples:sample-companyweb:war:1.0-incubator-SN
 APSHOT
 2)
 org.apache.tuscany.das:tuscany-das-rdb:jar:1.0-incubator-SNAPSHOT

 --
 1 required artifact is missing.

 for artifact:



org.apache.tuscany.das.samples:sample-companyweb:war:1.0-incubator-SNAPSHOT

 from the specified remote repositories:
   central (http://repo1.maven.org/maven2),
   apache.incubator (
 http://people.apache.org/repo/m2-incubating-repository/
 ),
   apache.ws.m1.snapshots (http://ws.zones.apache.org/repository),
   apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository
)

 --
 Paulo Henrique Trecenti

 Sorry about the bad English.




--
Luciano Resende
http://people.apache.org/~lresende





--

tuscany asynchronous web service call

2007-04-11 Thread muhwas

Hi guys,

I have a quick question. If i put a
@Callback(CallBackInterface.class) on my bussiness
interface then all method in that interface has to be
asynchronous or i can use synchronous method too?

thanks,
muhwas

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Wiring of Services and References ?


I'm trying to run the echo-binding testcases after updating the binding
implementation, but I'm getting the exception below.
Are we actually wiring services and references  ?

java.lang.IllegalStateException: java.lang.NullPointerExceptionat
org.apache.tuscany.api.SCARuntime.start(SCARuntime.java:170)at
org.apache.tuscany.binding.echo.EchoBindingTestCase.setUp(
EchoBindingTestCase.java:35)at junit.framework.TestCase.runBare(
TestCase.java:132)at junit.framework.TestResult$1.protect(
TestResult.java:110)at junit.framework.TestResult.runProtected(
TestResult.java:128)at
junit.framework.TestResult.run(TestResult.java:113)
at junit.framework.TestCase.run(TestCase.java:124)at
junit.framework.TestSuite.runTest(TestSuite.java:232)at
junit.framework.TestSuite.run(TestSuite.java:227)at
org.junit.internal.runners.OldTestClassRunner.run(OldTestClassRunner.java:35)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(
JUnit4TestReference.java:38)at
org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(
RemoteTestRunner.java:460)at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(
RemoteTestRunner.java:673)at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(
RemoteTestRunner.java:386)at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(
RemoteTestRunner.java:196)Caused by: java.lang.NullPointerExceptionat
org.apache.tuscany.core.implementation.PojoAtomicComponent.start(
PojoAtomicComponent.java:217)at
org.apache.tuscany.host.embedded.SimpleRuntimeImpl.start(
SimpleRuntimeImpl.java:158)at
org.apache.tuscany.host.embedded.DefaultSCARuntime.startup(
DefaultSCARuntime.java:50)at org.apache.tuscany.api.SCARuntime.start(
SCARuntime.java:168)... 15 more

--
Luciano Resende
http://people.apache.org/~lresende

Re: Component types and loading them


On 4/11/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:


ant elder wrote:
 On 4/11/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:

 ant elder wrote:
  I'm attempting the same thing just now for script components see [1].
  Doesn't work yet, the .componentType file doesn't seem to get
 picked up.
  Comments welcome...
 
   ...ant
 
  [1]
 

https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/implementation-script/src/main/java/org/apache/tuscany/implementation/script/ScriptArtifactProcessor.java

 
 

 Can you see a .componentType being loaded at all? Is
 ComponentTypeDocumentProcessor called to process .componentType
 documents in your SCA contribution? If not then maybe Luciano can jump
 in here and take a look as the processors are triggered by the
 Contribution service...


 I'm still debugging and trying to understand how this should work so
 can't
 articulate well whats going on yet..but so far it looks like in the
 SimpleRuntimeImpl start method there are two artifact processor
 registries
 created, and the one where the ComponentTypeProcessor is added to is
 not the
 one that processes the contribution so the .componentType side file is
 ignored. Does that make any sense?

   ...ant


Yes it makes sense, the SimpleRuntimeImpl is missing the registration of
the ComponentTypeDocumentProcessor, I added it under revision r527566.
Can you update and try again? Thanks.



Yes thanks thats better, gets past this for now.

  ...ant

Re: Project conventions


[snip]
Simon Laws wrote:



3/ package names within the modules don't always match the module name
which makes it trick to find classes sometimes. I don't have loads of
examples here  but the problem I have was trying to find
 o.a.t.api.SCARuntime
   This is in the host-embedded module. Is it practical to suggest that
package names to at least contain the module name?



I'm planning to start fixing some of these package names later this 
evening. For example the packages in implementation-java-runtime 
currenty start with o.a.t.core, I'll rename them to 
o.a.t.implementation.java


--
Jean-Sebastien


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Tuscany DAS M3 Release Plans


Hey Ron

  We have talked about it in the past in some threads, and i think we need
to bring the subject back now that we have more content available for a DAS
release. I think we could start by looking into our wiki [1] and
review/update the list of things we want for DAS M3, and also use [2] to
document our release process.

  I'll kick-off the process on the dev-list sometime by end of the week,
and ask for volunteers for Release Manager.

[1] - http://cwiki.apache.org/confluence/display/TUSCANY/RDB+DAS+-+Releases
[2] - http://cwiki.apache.org/confluence/display/TUSCANY/Release+Process

On 4/10/07, Ron Gavlin [EMAIL PROTECTED] wrote:


Java DAS folks,

Are there plans for a Tuscany DAS M3 release to coincide with the upcoming
SDO M3 release? If so, how long after the SDO release do you anticipate the
DAS release will appear? I suspect the DAS M2 release will be incompatible
with the SDO M3 release, correct?

Thanks in advance for your assistance.

- Ron

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
Luciano Resende
http://people.apache.org/~lresende

PojoWorkContextTunnel.getThreadWorkContext() returning null


Can any one see why the HelloWorldTestCase in implementation-script is
failing as JDKInvocationHandler.invoke is getting a null returned from
PojoWorkContextTunnel.getThreadWorkContext()? It is getting set in
SimpleRuntimeImpl.start but it seems to get lost somewhere before it gets to
JDKInvocationHandler.invoke.

  ...ant

Re: PojoWorkContextTunnel.getThreadWorkContext() returning null