[jira] Assigned: (TUSCANY-642) Composite references and services - model and runtime representations

[Jim Marino (JIRA)]

 [ http://issues.apache.org/jira/browse/TUSCANY-642?page=all ]

Jim Marino reassigned TUSCANY-642:
--

Assignee: Jim Marino  (was: Ignacio Silva-Lepe)

> Composite references and services - model and runtime representations
> -
>
> Key: TUSCANY-642
> URL: http://issues.apache.org/jira/browse/TUSCANY-642
> Project: Tuscany
>  Issue Type: New Feature
>  Components: Java SCA Core
>Affects Versions: Java-Mx
>Reporter: Ignacio Silva-Lepe
> Assigned To: Jim Marino
> Fix For: Java-Mx
>
> Attachments: CompositeRefsAndSvcs.txt, CompositeRefsAndSvcs2.txt, 
> InnerComposite.patch, InnerCompositeCallback.patch, 
> InnerCompositeCallback2.patch
>
>
> Support is added to represent composite references and services (those in a 
> composite and without a binding) in the model and runtime. The 
> CompositeBuilder is updated to build a composite component that includes 
> composite references and services without bindings.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] Closed: (TUSCANY-352) Improve the error message given when sca.modules is not found.

[Jim Marino (JIRA)]

 [ http://issues.apache.org/jira/browse/TUSCANY-352?page=all ]

Jim Marino closed TUSCANY-352.
--

Resolution: Fixed

> Improve the error message given when sca.modules is not found.
> --
>
> Key: TUSCANY-352
> URL: http://issues.apache.org/jira/browse/TUSCANY-352
> Project: Tuscany
>  Issue Type: Improvement
>  Components: Java SCA Core
>Affects Versions: Java-Mx
> Environment: all
>Reporter: Simon Laws
> Assigned To: Jim Marino
>Priority: Minor
> Fix For: Java-Mx
>
>
> Currently you get the following when sca.modules is not picked up.
> Exception in thread "main"
> org.apache.tuscany.core.config.ConfigurationLoadException: sca.module at
> org.apache.tuscany.core.config.impl.AbstractModuleComponentConfigurationLoader.loadModuleComponent
>  
> (AbstractModuleComponentConfigurationLoader.java:116)  at
> org.apache.tuscany.core.config.impl.AbstractModuleComponentConfigurationLoader.loadModuleComponent
>  
> (AbstractModuleComponentConfigurationLoader.java:100)   at
> org.apache.tuscany.core.client.TuscanyRuntime.(TuscanyRuntime.java:102) 
>   at
> org.apache.tuscany.core.client.TuscanyRuntime.(TuscanyRuntime.java:67)  
> at org.sample.helloworld.HelloWorldClient.main(HelloWorldClient.java:17)
> This should probably be a FAQ entry as well ponting out that a bit of fidling 
> with the classpath will fix it. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] Closed: (TUSCANY-52) AggregrateContext.getAggregate() should be removed

[Jim Marino (JIRA)]

 [ http://issues.apache.org/jira/browse/TUSCANY-52?page=all ]

Jim Marino closed TUSCANY-52.
-

Resolution: Fixed

> AggregrateContext.getAggregate() should be removed
> --
>
> Key: TUSCANY-52
> URL: http://issues.apache.org/jira/browse/TUSCANY-52
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Core
>Affects Versions: Java-Mx
>Reporter: Jeremy Boynes
> Assigned To: Jim Marino
>Priority: Minor
> Fix For: Java-Mx
>
>
> This method provides a way for applications to obtain access to the logical 
> configuration model from the runtime. This violates the IoC contract with the 
> runtime and requires that the logical model remain active in a running system.
> This method is currently only used by the Axis1 integration. On first 
> request, the servlet uses it to obtain a list of entry points from the 
> logical model and then configures the Axis1 engine appropriately; this 
> configuration can be determined during the build of the module context by a 
> builder with full access to the logical model.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] Closed: (TUSCANY-398) Ability to save sca assembly model object to XML

[Jim Marino (JIRA)]

 [ http://issues.apache.org/jira/browse/TUSCANY-398?page=all ]

Jim Marino closed TUSCANY-398.
--

Resolution: Won't Fix

This is by design.

> Ability to save sca assembly model object to XML
> 
>
> Key: TUSCANY-398
> URL: http://issues.apache.org/jira/browse/TUSCANY-398
> Project: Tuscany
>  Issue Type: New Feature
>  Components: Java SCA Core
>Affects Versions: Java-Mx
> Environment: Win2000
>Reporter: Yang Lei
> Fix For: Java-Mx
>
>
> Current Tuscany contains the Loader framework to load sca assembly model from 
> XML . Need a reverse operation to store the assembly model back to XML.
> Thanks.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] Closed: (TUSCANY-200) Default scope for system components should be MODULE not INSTANCE

[Jim Marino (JIRA)]

 [ http://issues.apache.org/jira/browse/TUSCANY-200?page=all ]

Jim Marino closed TUSCANY-200.
--

Resolution: Fixed

> Default scope for system components should be MODULE not INSTANCE
> -
>
> Key: TUSCANY-200
> URL: http://issues.apache.org/jira/browse/TUSCANY-200
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Core
>Affects Versions: Java-Mx
>Reporter: Jeremy Boynes
> Assigned To: Jim Marino
>Priority: Minor
> Fix For: Java-Mx
>
>
> The default scope for system components is currently INSTANCE but the typical 
> usage is module

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] Closed: (TUSCANY-321) Injection of references into a simple POJO without annotations does not work

[Jim Marino (JIRA)]

 [ http://issues.apache.org/jira/browse/TUSCANY-321?page=all ]

Jim Marino closed TUSCANY-321.
--

Resolution: Fixed

> Injection of references into a simple POJO without annotations does not work
> 
>
> Key: TUSCANY-321
> URL: http://issues.apache.org/jira/browse/TUSCANY-321
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Core, Java SCA POJO Container
>Affects Versions: Java-Mx
>Reporter: Jean-Sebastien Delfino
> Assigned To: Jim Marino
>Priority: Minor
> Fix For: Java-Mx
>
> Attachments: undefreference.zip
>
>
> Injection of references into a simple POJO without annotations does not work.
> Create a simple POJO component without any SCA annotations. On the POJO 
> declare public fields or public setters for the component's references. Wire 
> the references in sca.module. When the module starts you will get the 
> following exception:
> [surefire] Running calculator.CalculatorTestCase
> [surefire] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 1.015 sec
> [surefire]
> [surefire] testCalculator(calculator.CalculatorTestCase)  Time elapsed: 0.999 
> sec  <<< ERROR!
> org.apache.tuscany.model.assembly.AssemblyInitializationException: Undefined 
> reference [addService]
> at 
> org.apache.tuscany.model.assembly.impl.ComponentImpl.initialize(ComponentImpl.java:162)
> at 
> org.apache.tuscany.model.assembly.impl.CompositeImpl.initialize(CompositeImpl.java:194)
> at 
> org.apache.tuscany.model.assembly.impl.ModuleImpl.initialize(ModuleImpl.java:85)
> at 
> org.apache.tuscany.model.assembly.impl.ComponentImpl.initialize(ComponentImpl.java:135)
> at 
> org.apache.tuscany.core.config.impl.AbstractModuleComponentConfigurationLoader.loadModuleComponent(AbstractModuleComponentConfigurationLoader.java:156)
> at 
> org.apache.tuscany.core.config.impl.AbstractModuleComponentConfigurationLoader.loadModuleComponent(AbstractModuleComponentConfigurationLoader.java:132)
> at 
> org.apache.tuscany.core.config.impl.AbstractModuleComponentConfigurationLoader.loadModuleComponent(AbstractModuleComponentConfigurationLoader.java:100)
> at 
> org.apache.tuscany.core.client.TuscanyRuntime.(TuscanyRuntime.java:103)
> at 
> org.apache.tuscany.core.client.TuscanyRuntime.(TuscanyRuntime.java:67)
> at calculator.CalculatorTestCase.setUp(CalculatorTestCase.java:36)
> at junit.framework.TestCase.runBare(TestCase.java:125)
> at junit.framework.TestResult$1.protect(TestResult.java:106)
> at junit.framework.TestResult.runProtected(TestResult.java:124)
> at junit.framework.TestResult.run(TestResult.java:109)
> at junit.framework.TestCase.run(TestCase.java:118)
> at junit.framework.TestSuite.runTest(TestSuite.java:208)
> at junit.framework.TestSuite.run(TestSuite.java:203)
> 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.maven.surefire.battery.JUnitBattery.executeJUnit(JUnitBattery.java:242)
> at 
> org.apache.maven.surefire.battery.JUnitBattery.execute(JUnitBattery.java:216)
> at 
> org.apache.maven.surefire.Surefire.executeBattery(Surefire.java:215)
> at org.apache.maven.surefire.Surefire.run(Surefire.java:163)
> at org.apache.maven.surefire.Surefire.run(Surefire.java:87)
> 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.maven.surefire.SurefireBooter.runTestsInProcess(SurefireBooter.java:285)
> at 
> org.apache.maven.surefire.SurefireBooter.run(SurefireBooter.java:201)
> at 
> org.apache.maven.test.SurefirePlugin.execute(SurefirePlugin.java:366)
> at 
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:432)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:530)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:472)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:451)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecu

[jira] Closed: (TUSCANY-54) WireBuilders should be registered with a central registry

[Jim Marino (JIRA)]

 [ http://issues.apache.org/jira/browse/TUSCANY-54?page=all ]

Jim Marino closed TUSCANY-54.
-

Resolution: Won't Fix

> WireBuilders should be registered with a central registry
> -
>
> Key: TUSCANY-54
> URL: http://issues.apache.org/jira/browse/TUSCANY-54
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Core
>Affects Versions: Java-Mx
>Reporter: Jeremy Boynes
>Priority: Minor
> Fix For: Java-Mx
>
>
> WireBuilders should register with a system service rather than the 
> RuntimeContext itself

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

Re: Optiional Autowire

[Jim Marino]

Rick,

I realized I need to take a look at Ignacio's patch since I'm sure it  
won't apply cleanly with the SPI changes in place.  So, if you don't  
mind, could you take a look at adding optional autowires?


Here is what needs to be done:

1. Change the autowire annotation to default to required true (obvious)

2. The implementation processing framework needs to be updated to  
introspect autowire annotations and update  
ReferenceDefinition.setRequired(). ReferenceDefinition is used to  
represent references in general, and autowires in particular, which  
are treated as a type. There are several processors which may need  
updating. One is ImplementationProcessorServiceImpl.


3. SystemComponentBuilder needs to be modified to deal with  
ReferenceDefinition.isRequired() for autowires and pass that to the  
SystemOutboundAutowire constructor (which will need to be modified to  
add a required field) as it creates system wires.


4. SystemOutboundAutowire when it resolves the autowire will throw an  
exception if its required field is true.


Let me know if I can help out.

Jim



On Aug 30, 2006, at 2:06 PM, Jim Marino wrote:



On Aug 30, 2006, at 1:41 PM, Rick wrote:


Sure why meddle with the master! :-)
I'd actually not mind avoiding doing it myself but I prefer that to  
having to reconcile changes
Seriously, the only request I would have is if convenient could  
you make it a separate svn checkin? Just like to review what you  
did for just this.

Yep. That's what I intend to do
The autowire information as far as I see is lost in the connection  
building phase, unless I missed it.  Was wondering if it could not  
be added directly to the ServiceContract.
It shouldn't be on the service contract since it is part of the  
component type (autowire is really a type of reference).  
ReferenceDefinition already contains the information needed and can  
be accessed from the system component builder.


Jim






-
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: build breaks (and how to fix them)

[Jeremy Boynes]

I have updated the POMs for the spec projects and buildtools so that  
we are ready to publish snapshot builds for them.


This will allow us to build and publish SCA and SDO as standalone  
projects. Once SDO is published, we should be able to build and  
publish DAS.


To tackle 3), I will move the projects under a new subdirectory in  
sca called (for want of a better name as core is taken) "kernel".


--
Jeremy


On Aug 29, 2006, at 5:24 PM, Jeremy Boynes wrote:

Sounds good to me. I will start to publish unstable builds to the  
apache snapshot repo to help stabilize things.

--
Jeremy

On Aug 25, 2006, at 5:20 PM, Jim Marino wrote:

Many of us have experienced build breaks over the past several  
weeks, particularly in the Java SCA project. I believe the root of  
the problem to be not having the correct level of modularity. I  
would like to start with a general approach on how to fix this and  
once we gain consensus, move to creating a proposal for changing  
the current build structure.


1. The source tree should be independently built from individual   
projects under /java, sca, sdo, and das. Currently it is not since  
buildtools is required. I would like to get to the point where  
people can check out individual sub projects only and build from  
there.


2. For SCA Java, as Ant proposed, the samples dealing with  
extensions would move to their appropriate extension projects.  
Samples that used multiple extensions (e.g. BigBank with Celtix  
and Axis) would stay under samples/sca


3. API, SPI, core, hostutil, host-api would be built independently  
under a subdirectory of /sca


4. Runtime host projects would be build independently under a  
subdirectory of /sca


5. Extensions would move into into a subdirectory of /sca (they  
could still be organized according to type) and be built  
individually against a particular version of the core "jars". This  
would mean that extensions are not built together and are not  
built with the core. This would shield the entire build process  
from breaking when an extension breaks (e.g. Axis and Axiom not  
being in sync). It would also mean changes to the core could be  
vetted and not impact work being done on extensions.


Thoughts?

Jim



-
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]




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

svn commit: r438785: move to ServiceContract/Operation

[Jim Marino]

I have committed the changes to use ServiceContract/Operation in  
place of Java Interface/Method. This entailed modifications in SPI,  
particularly the signatures for classes in the wire package (e.g.  
RuntimeWire, InvocationChain), WireService, and Component  
(createTargetInvoker).


ServiceContracts are created by an introspection registry for a given  
IDL. These registries may use the same pattern as registries for  
loaders and builders. For example, Java IDL has a  
JavaInterfaceProcessorRegistryImpl that delegates to  
JavaInterfaceProcessor implementations to populate a ServiceContract  
reflected from a Java interface. JavaInterfaceProcessor  
implementations may be system services which register with a  
JavaInterfaceProcessorRegistry, thereby adding support for metadata  
extensions (such as information specific to a databinding type).


ServiceContract metadata is used to decorate wires.   RuntimeWire has  
a new method getServiceContract() which will return the service  
contract associated with an inbound or outbound wire. Similarly,  
Invocation chains are decorated with an Operation. This metadata will  
be used by a new system service responsible for "optimizing/ 
mediating" wires as they are connected by the wiring infrastructure.  
This system service will be another registry with a set of builders.  
It will be different than the policy builder registry since policy  
builders only operate on one side of a wire (source or target).  
Raymond's databinding framework will use these facilities to  
introspect the outbound and inbounds parts of a wire and add  
appropriate interceptors.


Currently, Operation and ServiceContract do not have facilities for  
runtime extensibility metadata; I will be adding these along with the  
new type of "optimizing/mediating" registry (probably) tomorrow.


One outstanding work item is to provide a performant replacement for  
JDK proxies (JDKWireService). I suspect we will see significant  
performance penalties for local invocations, particularly callbacks,  
as several map lookups are done. If anyone is interested in creating  
an implementation of WireService based on a bytecode generation  
library such as ASM, please let me know and I will try and provide  
pointers.


Jim


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

RE: Returning DynamicDataObjectImpl from web service call produces TargetException leads to ClassCastException

[Li Shen]

Hi, Raymond,

Can this be caused by the error reported in the mail " tuscany-sdo-plugin 
produces NPE".

Looks like this code which is responsible for registering static type SDO 
simply calls into static init of PackageImpl generated by the SDO plugin. Will 
PackageImpl register the types and then the TypeHelper used by Celtix could see 
them? Could the code generation error break down this?

public static void registerStaticTypes(Class factoryClass)
  {
//TODO this implementation is temporary, until the SDO generated factory 
pattern is decided
//
String temp = factoryClass.getName().replaceFirst("Factory$", 
"PackageImpl");
int lastDot = temp.lastIndexOf('.');
String packageName = temp.substring(0, lastDot) + ".impl" + 
temp.substring(lastDot);
try // this case handles the current default generator pattern
{
  Class javaClass = getPackageClass(factoryClass, packageName);
  Field field = javaClass.getField("eINSTANCE");
  field.get(null); 
}
catch (Exception e1)
{
  ...
}
  }

Thanks,
Li

-Original Message-
From: Chris Wall [mailto:[EMAIL PROTECTED] 
Sent: 2006年8月31日 8:27
To: tuscany-dev@ws.apache.org
Subject: Re: Returning DynamicDataObjectImpl from web service call produces 
TargetException leads to ClassCastException

Hi Raymond.  Thanks for your patience.

With the factory declaraion I'm getting the same thing...

org.apache.tuscany.spi.wire.InvocationRuntimeException: Type '{
http://www.bea.com/medrec}getString' not found in registered SDO types.
at org.apache.tuscany.binding.celtix.io.NodeDataWriter.toXMLDocument(
NodeDataWriter.java:142)
at org.apache.tuscany.binding.celtix.io.NodeDataWriter.writeWrapper(
NodeDataWriter.java:84)
at org.apache.tuscany.binding.celtix.io.NodeDataWriter.writeWrapper(
NodeDataWriter.java:47)
at org.objectweb.celtix.bus.bindings.soap.SOAPBindingImpl.addParts(
SOAPBindingImpl.java:567)
at org.objectweb.celtix.bus.bindings.soap.SOAPBindingImpl.marshal(
SOAPBindingImpl.java:119)
at org.objectweb.celtix.bindings.Request.process(Request.java:91)


org.apache.tuscany.spi.wire.InvocationRuntimeException: Type '{
http://www.bea.com/medrec}getPatient' not found in registered SDO types.

Updated scdl:

E:/sca/tuscany/java/samples/sca/medrec 190$ cat
target/classes/META-INF/sca/default.scdl

http://www.osoa.org/xmlns/sca/1.0";
   xmlns:system="http://tuscany.apache.org/xmlns/system/1.0-SNAPSHOT
"
   name="tuscanyWS2WLS">

  

  

  


  MedRecWebServicesService

  

  

http://www.bea.com/medrec#wsdl.endpoint(MedRecWebServices/MedRecWebServicesPort)
"
location="wsdl/MedRecWebServices.wsdl" />
  




On 8/30/06, Raymond Feng <[EMAIL PROTECTED]> wrote:
>
> Hi, Chris.
>
> You probably need to use the following "import.sdo":
>
> 
>
> Thanks,
> Raymond
>
> - Original Message -
> From: "Chris Wall" <[EMAIL PROTECTED]>
> To: 
> Sent: Wednesday, August 30, 2006 4:24 PM
> Subject: Re: Returning DynamicDataObjectImpl from web service call
> produces
> TargetException leads to ClassCastException
>
>
> > Hey.  Comments inline...
> >
> >
> > On 8/30/06, Raymond Feng <[EMAIL PROTECTED]> wrote:
> >>
> >> Hi, Chris.
> >>
> >> If you have , it
> >> means
> >> that you prefer to use the dynamic SDO model derived from the WSDL/XSD.
> I
> >> have two questions:
> >
> >
> > CW:  Ahh, I did not know.  Yet, if I remove the import the following
> line
> > throws an exception:
> >
> > [NodeDataWriter}
> > Property property = xsdHelper.getGlobalProperty(
> >elementQName.getNamespaceURI(), elementQName.getLocalPart(),
> > true);
> >
> > org.apache.tuscany.spi.wire.InvocationRuntimeException: Type '{
> > http://www.bea.com/medrec}getString' not found in registered SDO types.
> >
> > With import.sdo, this web service call returns successfully.
> >
> > 1) Is the exception from client side or server side?
> >
> >
> > CW:  Client.  Occurs within Proxy.getPatient(...).
> >
> > 2) What's our business interface expecting? The strongly-typed java
> >> class/interface generated by SDO or the dynamic DataObject?
> >
> >
> > CW: Strongly-typed:
> >
> > com.bea.proto.webservice.Patient
> > getPatient(com.bea.proto.webservice.PatientpPatient) throws Exception;
> >
> >
> > Basically, the "import.sdo" needs to be consistent with your business
> >> interface signature.
> >>
> >> Thanks,
> >> Raymond
> >>
> >> - Original Message -
> >> From: Chris Wall
> >> To: Raymond Feng
> >> Sent: Wednesday, August 30, 2006 4:05 PM
> >> Subject: Re: Returning DynamicDataObjectImpl from web service call
> >> produces
> >> TargetException leads to ClassCastException
> >>
> >>
> >> Hey Raymond.
> >>
> >> Our *client* scdl has:
> >> .
> >>
> >> Deserialized into the dynamic SDO makes
> >> sense.  XMLStreamReader2XMLDocument
> >> parses the stream and creates a DynamicDataObjectImpl as it's root
> >> object.
> >> DynamicDataObjectImpl is aware of it's Patient context -
> >> nam

Re: SDO spec jar manifest

[Jeremy Boynes]

This includes the spec version number in the manifest as well - do we  
want to do the same with the artifact id (as we do with sca)?


This would make the jar name:
sdo-api-r${specVersion}-${tuscanyVersion}.jar
e.g.
sdo-api-r2.01-1.0.jar

(you want to allow for multiple versions of the spec jar in case some  
implementation in there changes).

--
Jeremy

On Aug 30, 2006, at 7:35 PM, Jeremy Boynes wrote:

I committed a version of this by accident in r438750 - rather than  
back that out, I'm going to assume consensus and finish it up.


--
Jeremy

On Aug 30, 2006, at 4:39 PM, Jeremy Boynes wrote:

This is currently located in the source tree and out of date -  
should I update to use the OSGi plugin like the SCA one does?

--
Jeremy

-
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]




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

Re: SDO spec jar manifest

[Jeremy Boynes]

I committed a version of this by accident in r438750 - rather than  
back that out, I'm going to assume consensus and finish it up.


--
Jeremy

On Aug 30, 2006, at 4:39 PM, Jeremy Boynes wrote:

This is currently located in the source tree and out of date -  
should I update to use the OSGi plugin like the SCA one does?

--
Jeremy

-
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]

[jira] Closed: (TUSCANY-679) InterfaceWSDLLoader mismatch btw. @Constructor annot. and actual Constructor parms

[Jeremy Boynes (JIRA)]

 [ http://issues.apache.org/jira/browse/TUSCANY-679?page=all ]

Jeremy Boynes closed TUSCANY-679.
-

Resolution: Fixed

Patch applied fine - thanks

> InterfaceWSDLLoader mismatch btw.  @Constructor annot. and actual Constructor 
> parms
> ---
>
> Key: TUSCANY-679
> URL: http://issues.apache.org/jira/browse/TUSCANY-679
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Axis Binding
>Affects Versions: Java-M2
>Reporter: Scott Kurz
> Attachments: InterfaceWSDLLoader.ConstructorFix.patch
>
>
> PROBLEM:
> Mismatch btw. annotation:
> @Constructor({"registry"})
> and Constructor:
> public InterfaceWSDLLoader(@Autowire LoaderRegistry registry,
>@Autowire WSDLDefinitionRegistry wsdlRegistry) 
> {
> 
> SYMPTOM:
> org.apache.tuscany.core.implementation.processor.InvalidAutowireException: 
> Names in @Constructor and autowire parameter do not match at 2 [public 
> org.apache.tuscany.idl.wsdl.InterfaceWSDLLoader(org.apache.tuscany.spi.loader.LoaderRegistry,org.apache.tuscany.idl.wsdl.WSDLDefinitionRegistry)]
> Context stack trace: [tuscany.system][intf.wsdl.loader]
>   at 
> org.apache.tuscany.core.implementation.processor.ImplementationProcessorServiceImpl.processAutowire(ImplementationProcessorServiceImpl.java:186)
>   at 
> org.apache.tuscany.core.implementation.processor.ImplementationProcessorServiceImpl.processParam(ImplementationProcessorServiceImpl.java:113)
>   at 
> org.apache.tuscany.core.implementation.processor.ConstructorProcessor.visitConstructor(ConstructorProcessor.java:94)
>   at 
> org.apache.tuscany.core.implementation.IntrospectionRegistryImpl.introspect(IntrospectionRegistryImpl.java:83)
>   at 
> org.apache.tuscany.core.implementation.system.loader.SystemComponentTypeLoader.loadByIntrospection(SystemComponentTypeLoader.java:85)
>   at 
> org.apache.tuscany.core.implementation.system.loader.SystemComponentTypeLoader.load(SystemComponentTypeLoader.java:69)
>   at 
> org.apache.tuscany.core.implementation.system.loader.SystemComponentTypeLoader.load(SystemComponentTypeLoader.java:42)
>   at 
> org.apache.tuscany.core.loader.LoaderRegistryImpl.loadComponentType(LoaderRegistryImpl.java:159)
> 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] Commented: (TUSCANY-679) InterfaceWSDLLoader mismatch btw. @Constructor annot. and actual Constructor parms

[Jim Marino (JIRA)]

[ 
http://issues.apache.org/jira/browse/TUSCANY-679?page=comments#action_12431764 
] 

Jim Marino commented on TUSCANY-679:


oops didn't see the patch. Yes this will work or just delete the @Constructor

> InterfaceWSDLLoader mismatch btw.  @Constructor annot. and actual Constructor 
> parms
> ---
>
> Key: TUSCANY-679
> URL: http://issues.apache.org/jira/browse/TUSCANY-679
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Axis Binding
>Affects Versions: Java-M2
>Reporter: Scott Kurz
> Attachments: InterfaceWSDLLoader.ConstructorFix.patch
>
>
> PROBLEM:
> Mismatch btw. annotation:
> @Constructor({"registry"})
> and Constructor:
> public InterfaceWSDLLoader(@Autowire LoaderRegistry registry,
>@Autowire WSDLDefinitionRegistry wsdlRegistry) 
> {
> 
> SYMPTOM:
> org.apache.tuscany.core.implementation.processor.InvalidAutowireException: 
> Names in @Constructor and autowire parameter do not match at 2 [public 
> org.apache.tuscany.idl.wsdl.InterfaceWSDLLoader(org.apache.tuscany.spi.loader.LoaderRegistry,org.apache.tuscany.idl.wsdl.WSDLDefinitionRegistry)]
> Context stack trace: [tuscany.system][intf.wsdl.loader]
>   at 
> org.apache.tuscany.core.implementation.processor.ImplementationProcessorServiceImpl.processAutowire(ImplementationProcessorServiceImpl.java:186)
>   at 
> org.apache.tuscany.core.implementation.processor.ImplementationProcessorServiceImpl.processParam(ImplementationProcessorServiceImpl.java:113)
>   at 
> org.apache.tuscany.core.implementation.processor.ConstructorProcessor.visitConstructor(ConstructorProcessor.java:94)
>   at 
> org.apache.tuscany.core.implementation.IntrospectionRegistryImpl.introspect(IntrospectionRegistryImpl.java:83)
>   at 
> org.apache.tuscany.core.implementation.system.loader.SystemComponentTypeLoader.loadByIntrospection(SystemComponentTypeLoader.java:85)
>   at 
> org.apache.tuscany.core.implementation.system.loader.SystemComponentTypeLoader.load(SystemComponentTypeLoader.java:69)
>   at 
> org.apache.tuscany.core.implementation.system.loader.SystemComponentTypeLoader.load(SystemComponentTypeLoader.java:42)
>   at 
> org.apache.tuscany.core.loader.LoaderRegistryImpl.loadComponentType(LoaderRegistryImpl.java:159)
> 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] Commented: (TUSCANY-679) InterfaceWSDLLoader mismatch btw. @Constructor annot. and actual Constructor parms

[Jim Marino (JIRA)]

[ 
http://issues.apache.org/jira/browse/TUSCANY-679?page=comments#action_12431763 
] 

Jim Marino commented on TUSCANY-679:


The issue is in the definition of InterfaceWSDLLoader. Either the @Constructor 
annotation should include names for all constructor params, none, or just be 
eliminated. I would just eliminate the @Constructor since the implementation 
processor will deduce the constructor from the @Autowire annotations.

> InterfaceWSDLLoader mismatch btw.  @Constructor annot. and actual Constructor 
> parms
> ---
>
> Key: TUSCANY-679
> URL: http://issues.apache.org/jira/browse/TUSCANY-679
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Axis Binding
>Affects Versions: Java-M2
>Reporter: Scott Kurz
> Attachments: InterfaceWSDLLoader.ConstructorFix.patch
>
>
> PROBLEM:
> Mismatch btw. annotation:
> @Constructor({"registry"})
> and Constructor:
> public InterfaceWSDLLoader(@Autowire LoaderRegistry registry,
>@Autowire WSDLDefinitionRegistry wsdlRegistry) 
> {
> 
> SYMPTOM:
> org.apache.tuscany.core.implementation.processor.InvalidAutowireException: 
> Names in @Constructor and autowire parameter do not match at 2 [public 
> org.apache.tuscany.idl.wsdl.InterfaceWSDLLoader(org.apache.tuscany.spi.loader.LoaderRegistry,org.apache.tuscany.idl.wsdl.WSDLDefinitionRegistry)]
> Context stack trace: [tuscany.system][intf.wsdl.loader]
>   at 
> org.apache.tuscany.core.implementation.processor.ImplementationProcessorServiceImpl.processAutowire(ImplementationProcessorServiceImpl.java:186)
>   at 
> org.apache.tuscany.core.implementation.processor.ImplementationProcessorServiceImpl.processParam(ImplementationProcessorServiceImpl.java:113)
>   at 
> org.apache.tuscany.core.implementation.processor.ConstructorProcessor.visitConstructor(ConstructorProcessor.java:94)
>   at 
> org.apache.tuscany.core.implementation.IntrospectionRegistryImpl.introspect(IntrospectionRegistryImpl.java:83)
>   at 
> org.apache.tuscany.core.implementation.system.loader.SystemComponentTypeLoader.loadByIntrospection(SystemComponentTypeLoader.java:85)
>   at 
> org.apache.tuscany.core.implementation.system.loader.SystemComponentTypeLoader.load(SystemComponentTypeLoader.java:69)
>   at 
> org.apache.tuscany.core.implementation.system.loader.SystemComponentTypeLoader.load(SystemComponentTypeLoader.java:42)
>   at 
> org.apache.tuscany.core.loader.LoaderRegistryImpl.loadComponentType(LoaderRegistryImpl.java:159)
> 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] Updated: (TUSCANY-679) InterfaceWSDLLoader mismatch btw. @Constructor annot. and actual Constructor parms

[Scott Kurz (JIRA)]

 [ http://issues.apache.org/jira/browse/TUSCANY-679?page=all ]

Scott Kurz updated TUSCANY-679:
---

Attachment: InterfaceWSDLLoader.ConstructorFix.patch

Hopefully this is the right patch format (this is my first patch here)

> InterfaceWSDLLoader mismatch btw.  @Constructor annot. and actual Constructor 
> parms
> ---
>
> Key: TUSCANY-679
> URL: http://issues.apache.org/jira/browse/TUSCANY-679
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Axis Binding
>Affects Versions: Java-M2
>Reporter: Scott Kurz
> Attachments: InterfaceWSDLLoader.ConstructorFix.patch
>
>
> PROBLEM:
> Mismatch btw. annotation:
> @Constructor({"registry"})
> and Constructor:
> public InterfaceWSDLLoader(@Autowire LoaderRegistry registry,
>@Autowire WSDLDefinitionRegistry wsdlRegistry) 
> {
> 
> SYMPTOM:
> org.apache.tuscany.core.implementation.processor.InvalidAutowireException: 
> Names in @Constructor and autowire parameter do not match at 2 [public 
> org.apache.tuscany.idl.wsdl.InterfaceWSDLLoader(org.apache.tuscany.spi.loader.LoaderRegistry,org.apache.tuscany.idl.wsdl.WSDLDefinitionRegistry)]
> Context stack trace: [tuscany.system][intf.wsdl.loader]
>   at 
> org.apache.tuscany.core.implementation.processor.ImplementationProcessorServiceImpl.processAutowire(ImplementationProcessorServiceImpl.java:186)
>   at 
> org.apache.tuscany.core.implementation.processor.ImplementationProcessorServiceImpl.processParam(ImplementationProcessorServiceImpl.java:113)
>   at 
> org.apache.tuscany.core.implementation.processor.ConstructorProcessor.visitConstructor(ConstructorProcessor.java:94)
>   at 
> org.apache.tuscany.core.implementation.IntrospectionRegistryImpl.introspect(IntrospectionRegistryImpl.java:83)
>   at 
> org.apache.tuscany.core.implementation.system.loader.SystemComponentTypeLoader.loadByIntrospection(SystemComponentTypeLoader.java:85)
>   at 
> org.apache.tuscany.core.implementation.system.loader.SystemComponentTypeLoader.load(SystemComponentTypeLoader.java:69)
>   at 
> org.apache.tuscany.core.implementation.system.loader.SystemComponentTypeLoader.load(SystemComponentTypeLoader.java:42)
>   at 
> org.apache.tuscany.core.loader.LoaderRegistryImpl.loadComponentType(LoaderRegistryImpl.java:159)
> 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

Including schemas in SCA API jar?

[Jeremy Boynes]

We currently include the SCA schema's in the sca-api jar in the  
location /schemas/* - two questions:

1) should we continue to do this?
2) if we do, should we move them to a better place e.g. org/osoa/sca/ 
schema ?


--
Jeremy


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

[jira] Created: (TUSCANY-679) InterfaceWSDLLoader mismatch btw. @Constructor annot. and actual Constructor parms

[Scott Kurz (JIRA)]

InterfaceWSDLLoader mismatch btw.  @Constructor annot. and actual Constructor 
parms
---

 Key: TUSCANY-679
 URL: http://issues.apache.org/jira/browse/TUSCANY-679
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Axis Binding
Affects Versions: Java-M2
Reporter: Scott Kurz


PROBLEM:

Mismatch btw. annotation:

@Constructor({"registry"})

and Constructor:

public InterfaceWSDLLoader(@Autowire LoaderRegistry registry,
   @Autowire WSDLDefinitionRegistry wsdlRegistry) {


SYMPTOM:

org.apache.tuscany.core.implementation.processor.InvalidAutowireException: 
Names in @Constructor and autowire parameter do not match at 2 [public 
org.apache.tuscany.idl.wsdl.InterfaceWSDLLoader(org.apache.tuscany.spi.loader.LoaderRegistry,org.apache.tuscany.idl.wsdl.WSDLDefinitionRegistry)]
Context stack trace: [tuscany.system][intf.wsdl.loader]

at 
org.apache.tuscany.core.implementation.processor.ImplementationProcessorServiceImpl.processAutowire(ImplementationProcessorServiceImpl.java:186)

at 
org.apache.tuscany.core.implementation.processor.ImplementationProcessorServiceImpl.processParam(ImplementationProcessorServiceImpl.java:113)

at 
org.apache.tuscany.core.implementation.processor.ConstructorProcessor.visitConstructor(ConstructorProcessor.java:94)

at 
org.apache.tuscany.core.implementation.IntrospectionRegistryImpl.introspect(IntrospectionRegistryImpl.java:83)

at 
org.apache.tuscany.core.implementation.system.loader.SystemComponentTypeLoader.loadByIntrospection(SystemComponentTypeLoader.java:85)

at 
org.apache.tuscany.core.implementation.system.loader.SystemComponentTypeLoader.load(SystemComponentTypeLoader.java:69)

at 
org.apache.tuscany.core.implementation.system.loader.SystemComponentTypeLoader.load(SystemComponentTypeLoader.java:42)

at 
org.apache.tuscany.core.loader.LoaderRegistryImpl.loadComponentType(LoaderRegistryImpl.java:159)



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

Re: Returning DynamicDataObjectImpl from web service call produces TargetException leads to ClassCastException

[Chris Wall]

Hi Raymond.  Thanks for your patience.

With the factory declaraion I'm getting the same thing...

org.apache.tuscany.spi.wire.InvocationRuntimeException: Type '{
http://www.bea.com/medrec}getString' not found in registered SDO types.
   at org.apache.tuscany.binding.celtix.io.NodeDataWriter.toXMLDocument(
NodeDataWriter.java:142)
   at org.apache.tuscany.binding.celtix.io.NodeDataWriter.writeWrapper(
NodeDataWriter.java:84)
   at org.apache.tuscany.binding.celtix.io.NodeDataWriter.writeWrapper(
NodeDataWriter.java:47)
   at org.objectweb.celtix.bus.bindings.soap.SOAPBindingImpl.addParts(
SOAPBindingImpl.java:567)
   at org.objectweb.celtix.bus.bindings.soap.SOAPBindingImpl.marshal(
SOAPBindingImpl.java:119)
   at org.objectweb.celtix.bindings.Request.process(Request.java:91)


org.apache.tuscany.spi.wire.InvocationRuntimeException: Type '{
http://www.bea.com/medrec}getPatient' not found in registered SDO types.

Updated scdl:

E:/sca/tuscany/java/samples/sca/medrec 190$ cat
target/classes/META-INF/sca/default.scdl

http://www.osoa.org/xmlns/sca/1.0";
  xmlns:system="http://tuscany.apache.org/xmlns/system/1.0-SNAPSHOT
"
  name="tuscanyWS2WLS">

 

 

 
   
   
 MedRecWebServicesService
   
 

 
   
   http://www.bea.com/medrec#wsdl.endpoint(MedRecWebServices/MedRecWebServicesPort)
"
   location="wsdl/MedRecWebServices.wsdl" />
 




On 8/30/06, Raymond Feng <[EMAIL PROTECTED]> wrote:


Hi, Chris.

You probably need to use the following "import.sdo":



Thanks,
Raymond

- Original Message -
From: "Chris Wall" <[EMAIL PROTECTED]>
To: 
Sent: Wednesday, August 30, 2006 4:24 PM
Subject: Re: Returning DynamicDataObjectImpl from web service call
produces
TargetException leads to ClassCastException


> Hey.  Comments inline...
>
>
> On 8/30/06, Raymond Feng <[EMAIL PROTECTED]> wrote:
>>
>> Hi, Chris.
>>
>> If you have , it
>> means
>> that you prefer to use the dynamic SDO model derived from the WSDL/XSD.
I
>> have two questions:
>
>
> CW:  Ahh, I did not know.  Yet, if I remove the import the following
line
> throws an exception:
>
> [NodeDataWriter}
> Property property = xsdHelper.getGlobalProperty(
>elementQName.getNamespaceURI(), elementQName.getLocalPart(),
> true);
>
> org.apache.tuscany.spi.wire.InvocationRuntimeException: Type '{
> http://www.bea.com/medrec}getString' not found in registered SDO types.
>
> With import.sdo, this web service call returns successfully.
>
> 1) Is the exception from client side or server side?
>
>
> CW:  Client.  Occurs within Proxy.getPatient(...).
>
> 2) What's our business interface expecting? The strongly-typed java
>> class/interface generated by SDO or the dynamic DataObject?
>
>
> CW: Strongly-typed:
>
> com.bea.proto.webservice.Patient
> getPatient(com.bea.proto.webservice.PatientpPatient) throws Exception;
>
>
> Basically, the "import.sdo" needs to be consistent with your business
>> interface signature.
>>
>> Thanks,
>> Raymond
>>
>> - Original Message -
>> From: Chris Wall
>> To: Raymond Feng
>> Sent: Wednesday, August 30, 2006 4:05 PM
>> Subject: Re: Returning DynamicDataObjectImpl from web service call
>> produces
>> TargetException leads to ClassCastException
>>
>>
>> Hey Raymond.
>>
>> Our *client* scdl has:
>> .
>>
>> Deserialized into the dynamic SDO makes
>> sense.  XMLStreamReader2XMLDocument
>> parses the stream and creates a DynamicDataObjectImpl as it's root
>> object.
>> DynamicDataObjectImpl is aware of it's Patient context -
>> name=getPatientResponse, package=java: com.bea.proto.webservice, and
>> attributes.  It's the root object that is returned from the binding.
>>
>> Shouldn't there be an intermediate step that generates a Patient
object?
>>
>> -Chris
>>
>>
>>
>> On 8/30/06, Raymond Feng <[EMAIL PROTECTED]> wrote:
>> Hi,
>>
>> It seems that the exception is thrown from the target component and
it's
>> related to the static/dynamic SDO (The incoming XML got deserialized
into
>> the dynamic SDO instead of the generated static class which your
>> component
>> implementation code expects).
>>
>> What does the "import.sdo" look like on the server side? Using "<
>> import.sdo
>> factory="..."/>"?
>>
>> Thanks,
>> Raymond
>> - Original Message -
>> From: Chris Wall
>> To: tuscany-dev@ws.apache.org ; [EMAIL PROTECTED]
>> Sent: Wednesday, August 30, 2006 2:37 PM
>> Subject: Returning DynamicDataObjectImpl from web service call produces
>> TargetException leads to ClassCastException
>>
>>
>> Hi.  After a successful invocation of a web service, a TargetException
>> occurs ("Cannot evaulate $Proxy35.toString()") after body is returned
>> from
>> JDKOutboundInvocationHandler.  This eventually leads to a
>> ClassCastException:
>>
>> java.lang.ClassCastException:
>> org.apache.tuscany.sdo.impl.DynamicDataObjectImpl
>> at $Proxy35.getPatient(Unknown Source)
>> at
>>
>>
com.bea.proto.webservice.client.MedRecWebServicesServiceComponent.getPatient
>> (
>> MedRecWebServicesServiceComponent.java:26)
>

Re: Returning DynamicDataObjectImpl from web service call produces TargetException leads to ClassCastException

[Raymond Feng]

Hi, Chris.

You probably need to use the following "import.sdo":



Thanks,
Raymond

- Original Message - 
From: "Chris Wall" <[EMAIL PROTECTED]>

To: 
Sent: Wednesday, August 30, 2006 4:24 PM
Subject: Re: Returning DynamicDataObjectImpl from web service call produces 
TargetException leads to ClassCastException




Hey.  Comments inline...


On 8/30/06, Raymond Feng <[EMAIL PROTECTED]> wrote:


Hi, Chris.

If you have , it 
means

that you prefer to use the dynamic SDO model derived from the WSDL/XSD. I
have two questions:



CW:  Ahh, I did not know.  Yet, if I remove the import the following line
throws an exception:

[NodeDataWriter}
Property property = xsdHelper.getGlobalProperty(
   elementQName.getNamespaceURI(), elementQName.getLocalPart(),
true);

org.apache.tuscany.spi.wire.InvocationRuntimeException: Type '{
http://www.bea.com/medrec}getString' not found in registered SDO types.

With import.sdo, this web service call returns successfully.

1) Is the exception from client side or server side?


CW:  Client.  Occurs within Proxy.getPatient(...).

2) What's our business interface expecting? The strongly-typed java

class/interface generated by SDO or the dynamic DataObject?



CW: Strongly-typed:

com.bea.proto.webservice.Patient
getPatient(com.bea.proto.webservice.PatientpPatient) throws Exception;


Basically, the "import.sdo" needs to be consistent with your business

interface signature.

Thanks,
Raymond

- Original Message -
From: Chris Wall
To: Raymond Feng
Sent: Wednesday, August 30, 2006 4:05 PM
Subject: Re: Returning DynamicDataObjectImpl from web service call
produces
TargetException leads to ClassCastException


Hey Raymond.

Our *client* scdl has: 
.


Deserialized into the dynamic SDO makes
sense.  XMLStreamReader2XMLDocument
parses the stream and creates a DynamicDataObjectImpl as it's root 
object.

DynamicDataObjectImpl is aware of it's Patient context -
name=getPatientResponse, package=java: com.bea.proto.webservice, and
attributes.  It's the root object that is returned from the binding.

Shouldn't there be an intermediate step that generates a Patient object?

-Chris



On 8/30/06, Raymond Feng <[EMAIL PROTECTED]> wrote:
Hi,

It seems that the exception is thrown from the target component and it's
related to the static/dynamic SDO (The incoming XML got deserialized into
the dynamic SDO instead of the generated static class which your 
component

implementation code expects).

What does the "import.sdo" look like on the server side? Using "<
import.sdo
factory="..."/>"?

Thanks,
Raymond
- Original Message -
From: Chris Wall
To: tuscany-dev@ws.apache.org ; [EMAIL PROTECTED]
Sent: Wednesday, August 30, 2006 2:37 PM
Subject: Returning DynamicDataObjectImpl from web service call produces
TargetException leads to ClassCastException


Hi.  After a successful invocation of a web service, a TargetException
occurs ("Cannot evaulate $Proxy35.toString()") after body is returned 
from

JDKOutboundInvocationHandler.  This eventually leads to a
ClassCastException:

java.lang.ClassCastException:
org.apache.tuscany.sdo.impl.DynamicDataObjectImpl
at $Proxy35.getPatient(Unknown Source)
at

com.bea.proto.webservice.client.MedRecWebServicesServiceComponent.getPatient
(
MedRecWebServicesServiceComponent.java:26)

Unfortunately I couldn't figure out how to get the full stacktrace from
TargetException.

Admittedly, this one has me confused.  My first question is why is this
happening?  My second question is when, if ever, does the SDO layer
convert
the DynamicDataObjectImpl back to the intended return object (in this 
case

a
Patient object).

Thanks.

-Chris


-
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]

SDO spec jar manifest

[Jeremy Boynes]

This is currently located in the source tree and out of date - should  
I update to use the OSGi plugin like the SCA one does?

--
Jeremy

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

[jira] Commented: (TUSCANY-676) ImportSDOLoader: DataTypeImpl not found in XSDEcoreBuilder.typeToTypeObjectMap causes NPE (surfaced as IllegalArgumentException)

[Fuhwei Lwo (JIRA)]

[ 
http://issues.apache.org/jira/browse/TUSCANY-676?page=comments#action_12431744 
] 

Fuhwei Lwo commented on TUSCANY-676:


Hi Frank B.,

Please review and consider committing the attached tuscany-676.patch.  It seems 
to fix Chris' NPE.  Thanks.

Fuhwei Lwo

> ImportSDOLoader: DataTypeImpl not found in 
> XSDEcoreBuilder.typeToTypeObjectMap causes NPE (surfaced as 
> IllegalArgumentException)
> 
>
> Key: TUSCANY-676
> URL: http://issues.apache.org/jira/browse/TUSCANY-676
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Implementation
>Reporter: Chris Wall
> Attachments: medrec.zip, MedRecWebServices.wsdl, tuscany-676.patch, 
> xsdecorebuilder_npe.zip
>
>
> During SDO import of WSDL, elements of the following complex type are not 
> found when validated against available SDO datatypes within the XSD layer 
> (XSDEcoreBuilder).  Downstream this causes an NPE.  It could be that the 
> comparison between the type and the key is not properly implemented.  See the 
> attached zip containing debug screenshots.
>  targetNamespace="java:com.bea.proto.webservice" xmlns:xs=" 
> http://www.w3.org/2001/XMLSchema";>
>   
> 
>   
>type="xs:dateTime"/>
>type="xs:string"/>
>type="xs:string"/>
>type="xs:string"/>
>type="xs:string"/>
>type="xs:string"/>
>   
> 
>   
> 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

Re: Returning DynamicDataObjectImpl from web service call produces TargetException leads to ClassCastException

[Chris Wall]

Hey.  Comments inline...


On 8/30/06, Raymond Feng <[EMAIL PROTECTED]> wrote:


Hi, Chris.

If you have , it means
that you prefer to use the dynamic SDO model derived from the WSDL/XSD. I
have two questions:



CW:  Ahh, I did not know.  Yet, if I remove the import the following line
throws an exception:

[NodeDataWriter}
Property property = xsdHelper.getGlobalProperty(
   elementQName.getNamespaceURI(), elementQName.getLocalPart(),
true);

org.apache.tuscany.spi.wire.InvocationRuntimeException: Type '{
http://www.bea.com/medrec}getString' not found in registered SDO types.

With import.sdo, this web service call returns successfully.

1) Is the exception from client side or server side?


CW:  Client.  Occurs within Proxy.getPatient(...).

2) What's our business interface expecting? The strongly-typed java

class/interface generated by SDO or the dynamic DataObject?



CW: Strongly-typed:

com.bea.proto.webservice.Patient
getPatient(com.bea.proto.webservice.PatientpPatient) throws Exception;


Basically, the "import.sdo" needs to be consistent with your business

interface signature.

Thanks,
Raymond

- Original Message -
From: Chris Wall
To: Raymond Feng
Sent: Wednesday, August 30, 2006 4:05 PM
Subject: Re: Returning DynamicDataObjectImpl from web service call
produces
TargetException leads to ClassCastException


Hey Raymond.

Our *client* scdl has: .

Deserialized into the dynamic SDO makes
sense.  XMLStreamReader2XMLDocument
parses the stream and creates a DynamicDataObjectImpl as it's root object.
DynamicDataObjectImpl is aware of it's Patient context -
name=getPatientResponse, package=java: com.bea.proto.webservice, and
attributes.  It's the root object that is returned from the binding.

Shouldn't there be an intermediate step that generates a Patient object?

-Chris



On 8/30/06, Raymond Feng <[EMAIL PROTECTED]> wrote:
Hi,

It seems that the exception is thrown from the target component and it's
related to the static/dynamic SDO (The incoming XML got deserialized into
the dynamic SDO instead of the generated static class which your component
implementation code expects).

What does the "import.sdo" look like on the server side? Using "<
import.sdo
factory="..."/>"?

Thanks,
Raymond
- Original Message -
From: Chris Wall
To: tuscany-dev@ws.apache.org ; [EMAIL PROTECTED]
Sent: Wednesday, August 30, 2006 2:37 PM
Subject: Returning DynamicDataObjectImpl from web service call produces
TargetException leads to ClassCastException


Hi.  After a successful invocation of a web service, a TargetException
occurs ("Cannot evaulate $Proxy35.toString()") after body is returned from
JDKOutboundInvocationHandler.  This eventually leads to a
ClassCastException:

java.lang.ClassCastException:
org.apache.tuscany.sdo.impl.DynamicDataObjectImpl
at $Proxy35.getPatient(Unknown Source)
at

com.bea.proto.webservice.client.MedRecWebServicesServiceComponent.getPatient
(
MedRecWebServicesServiceComponent.java:26)

Unfortunately I couldn't figure out how to get the full stacktrace from
TargetException.

Admittedly, this one has me confused.  My first question is why is this
happening?  My second question is when, if ever, does the SDO layer
convert
the DynamicDataObjectImpl back to the intended return object (in this case
a
Patient object).

Thanks.

-Chris


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

Re: Returning DynamicDataObjectImpl from web service call produces TargetException leads to ClassCastException

[Raymond Feng]

Hi, Chris.

If you have , it means 
that you prefer to use the dynamic SDO model derived from the WSDL/XSD. I 
have two questions:


1) Is the exception from client side or server side?
2) What's our business interface expecting? The strongly-typed java 
class/interface generated by SDO or the dynamic DataObject?


Basically, the "import.sdo" needs to be consistent with your business 
interface signature.


Thanks,
Raymond

- Original Message - 
From: Chris Wall

To: Raymond Feng
Sent: Wednesday, August 30, 2006 4:05 PM
Subject: Re: Returning DynamicDataObjectImpl from web service call produces 
TargetException leads to ClassCastException



Hey Raymond.

Our *client* scdl has: .

Deserialized into the dynamic SDO makes sense.  XMLStreamReader2XMLDocument 
parses the stream and creates a DynamicDataObjectImpl as it's root object. 
DynamicDataObjectImpl is aware of it's Patient context - 
name=getPatientResponse, package=java: com.bea.proto.webservice, and 
attributes.  It's the root object that is returned from the binding.


Shouldn't there be an intermediate step that generates a Patient object?

-Chris



On 8/30/06, Raymond Feng <[EMAIL PROTECTED]> wrote:
Hi,

It seems that the exception is thrown from the target component and it's 
related to the static/dynamic SDO (The incoming XML got deserialized into 
the dynamic SDO instead of the generated static class which your component 
implementation code expects).


What does the "import.sdo" look like on the server side? Using "factory="..."/>"?


Thanks,
Raymond
- Original Message - 
From: Chris Wall

To: tuscany-dev@ws.apache.org ; [EMAIL PROTECTED]
Sent: Wednesday, August 30, 2006 2:37 PM
Subject: Returning DynamicDataObjectImpl from web service call produces 
TargetException leads to ClassCastException



Hi.  After a successful invocation of a web service, a TargetException 
occurs ("Cannot evaulate $Proxy35.toString()") after body is returned from 
JDKOutboundInvocationHandler.  This eventually leads to a 
ClassCastException:


java.lang.ClassCastException: 
org.apache.tuscany.sdo.impl.DynamicDataObjectImpl

   at $Proxy35.getPatient(Unknown Source)
   at 
com.bea.proto.webservice.client.MedRecWebServicesServiceComponent.getPatient( 
MedRecWebServicesServiceComponent.java:26)


Unfortunately I couldn't figure out how to get the full stacktrace from 
TargetException.


Admittedly, this one has me confused.  My first question is why is this 
happening?  My second question is when, if ever, does the SDO layer convert 
the DynamicDataObjectImpl back to the intended return object (in this case a 
Patient object).


Thanks.

-Chris 



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

Re: Returning DynamicDataObjectImpl from web service call produces TargetException leads to ClassCastException

[Chris Wall]

Hi Frank.  I manually edited the init() method to bypass the NPE.

So SDO doesn't default to creating a dynamic reference?  Where within the
SDO layer is the static lookup performed?

What's interesting is that outbound SDO succesfully converts the Patient SDO
object to XML.  This makes me think that the SDO layer is aware of the
static objects.  Here's what the service received from Celtix (via SDO):

http://schemas.xmlsoap.org/soap/envelope/"; xmln
s:xs="http://www.w3.org/2001/XMLSchema"; xmlns:xsi="
http://www.w3.org/2001/XMLSchema-instance";>http://www.bea.com/medrec";>LiShen<
/SOAP-ENV:Envelope>

-Chris

On 8/30/06, Frank Budinsky <[EMAIL PROTECTED]> wrote:


Hi Chris,

I can't answer the question of why it's happing (is it maybe related to
the NPE problem in the init method?), but I can say that the SDO layer
won't ever convert a DynamicDataObjectImpl back to a static instance. I
would guess that you got the dynamic instance because something is wrong
... it didn't find the static class and instantiated a dynamic SDO
instead.

Frank.

"Chris Wall" <[EMAIL PROTECTED]> wrote on 08/30/2006 05:37:37 PM:

> Hi.  After a successful invocation of a web service, a TargetException
> occurs ("Cannot evaulate $Proxy35.toString()") after body is returned
from
> JDKOutboundInvocationHandler.  This eventually leads to a
> ClassCastException:
>
> java.lang.ClassCastException:
> org.apache.tuscany.sdo.impl.DynamicDataObjectImpl
> at $Proxy35.getPatient(Unknown Source)
> at
>

com.bea.proto.webservice.client.MedRecWebServicesServiceComponent.getPatient
> (MedRecWebServicesServiceComponent.java:26)
>
> Unfortunately I couldn't figure out how to get the full stacktrace from
> TargetException.
>
> Admittedly, this one has me confused.  My first question is why is this
> happening?  My second question is when, if ever, does the SDO layer
convert
> the DynamicDataObjectImpl back to the intended return object (in this
case a
> Patient object).
>
> Thanks.
>
> -Chris


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

Re: svn commit: r438568 - /incubator/tuscany/java/spec/sca/pom.xml

[Jeremy Boynes]

Agreed - on [EMAIL PROTECTED] I've proposed a POM that can be used  
for podlings and if that is accepted I'll switch over.

--
Jeremy

On Aug 30, 2006, at 1:21 PM, Daniel Kulp wrote:



Jeremy,

Careful with this   Tuscany is an incubator project.   Thus,  
releases
(like milestone releases) are not allowed to go the the rsync  
repositories

that are defined in the apache pom:
http://www.apache.org/dev/repository-faq.html
snapshot are OK to go to that repository (providing the Tuscany  
PMC's are OK
with them), but when you go to deploy a release, you'll NOT have  
happy PMC's

if they end up going to ibiblio.


Dan


On Wednesday August 30 2006 2:03 pm, [EMAIL PROTECTED] wrote:

Author: jboynes
Date: Wed Aug 30 11:03:19 2006
New Revision: 438568

URL: http://svn.apache.org/viewvc?rev=438568&view=rev
Log:
inherit settings from Apache POM
centralize the spec version

Modified:
incubator/tuscany/java/spec/sca/pom.xml

Modified: incubator/tuscany/java/spec/sca/pom.xml
URL:
http://svn.apache.org/viewvc/incubator/tuscany/java/spec/sca/ 
pom.xml?rev=43

8568&r1=438567&r2=438568&view=diff
= 
==

=== --- incubator/tuscany/java/spec/sca/pom.xml (original)
+++ incubator/tuscany/java/spec/sca/pom.xml Wed Aug 30 11:03:19 2006
@@ -19,46 +19,29 @@
 -->
 
 4.0.0
+
+org.apache
+apache
+3
+
 org.osoa
-sca-api-r0.95
+sca-api-r${specVersion}
 SCA API
 API classes for the Service Component
Architecture 1.0-SNAPSHOT
-jar
+osgi-bundle

+
+0.95
+
 
 2.0.4
 

-
-The Apache Software Foundation
-http://www.apache.org
-
-
-
-The Apache Software License, Version 2.0
-http://www.apache.org/licenses/LICENSE-2.0.txturl>

-repo
-
-
-
-
-
-apache-incubator-repository
-Apache Incubator Repository
-
scp:///www/people.apache.org/repo/m2-snapshot-repository -
 
-
-apache-snapshot-repository
-Apache SNAPSHOT Repository
-
scp:///www/people.apache.org/repo/m2-snapshot-repository -
 
-
-
 
-
scm:svn:http://svn.apache.org/repos/asf/incubator/ 
tuscany/java/

spec -
scm:svn:https://svn.apache.org/repos/asf/ 
incubator/tus

cany/java/spec -
http://svn.apache.org/viewvc/incubator/tuscany/java/spec +

scm:svn:http://svn.apache.org/repos/asf/incubator/ 
tuscany/java/

spec/sca +
scm:svn:https://svn.apache.org/repos/asf/ 
incubator/tus

cany/java/spec/sca +
http://svn.apache.org/viewvc/incubator/tuscany/java/spec/scaurl>



 
@@ -98,7 +81,7 @@

${pom.organization.name}
plugin
org.osoa.sca -
   org.osoa.sca;version="0.95",
org.osoa.sca.annotations;version="0.95" +
 org.osoa.sca;version="${specVersion}",
org.osoa.sca.annotations;version="${specVersion}"

 
 



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


--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727C: 508-380-7194   F:781-902-8001
[EMAIL PROTECTED]

-
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: Returning DynamicDataObjectImpl from web service call produces TargetException leads to ClassCastException

[Frank Budinsky]

Hi Chris,

I can't answer the question of why it's happing (is it maybe related to 
the NPE problem in the init method?), but I can say that the SDO layer 
won't ever convert a DynamicDataObjectImpl back to a static instance. I 
would guess that you got the dynamic instance because something is wrong 
... it didn't find the static class and instantiated a dynamic SDO 
instead.

Frank.

"Chris Wall" <[EMAIL PROTECTED]> wrote on 08/30/2006 05:37:37 PM:

> Hi.  After a successful invocation of a web service, a TargetException
> occurs ("Cannot evaulate $Proxy35.toString()") after body is returned 
from
> JDKOutboundInvocationHandler.  This eventually leads to a
> ClassCastException:
> 
> java.lang.ClassCastException:
> org.apache.tuscany.sdo.impl.DynamicDataObjectImpl
> at $Proxy35.getPatient(Unknown Source)
> at
> 
com.bea.proto.webservice.client.MedRecWebServicesServiceComponent.getPatient
> (MedRecWebServicesServiceComponent.java:26)
> 
> Unfortunately I couldn't figure out how to get the full stacktrace from
> TargetException.
> 
> Admittedly, this one has me confused.  My first question is why is this
> happening?  My second question is when, if ever, does the SDO layer 
convert
> the DynamicDataObjectImpl back to the intended return object (in this 
case a
> Patient object).
> 
> Thanks.
> 
> -Chris


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

Re: Returning DynamicDataObjectImpl from web service call produces TargetException leads to ClassCastException

[Raymond Feng]

Hi,

It seems that the exception is thrown from the target component and it's 
related to the static/dynamic SDO (The incoming XML got deserialized into the 
dynamic SDO instead of the generated static class which your component 
implementation code expects).

What does the "import.sdo" look like on the server side? Using ""?

Thanks,
Raymond
  - Original Message - 
  From: Chris Wall 
  To: tuscany-dev@ws.apache.org ; [EMAIL PROTECTED] 
  Sent: Wednesday, August 30, 2006 2:37 PM
  Subject: Returning DynamicDataObjectImpl from web service call produces 
TargetException leads to ClassCastException


  Hi.  After a successful invocation of a web service, a TargetException occurs 
("Cannot evaulate $Proxy35.toString()") after body is returned from 
JDKOutboundInvocationHandler.  This eventually leads to a ClassCastException: 

  java.lang.ClassCastException: 
org.apache.tuscany.sdo.impl.DynamicDataObjectImpl
  at $Proxy35.getPatient(Unknown Source)
  at 
com.bea.proto.webservice.client.MedRecWebServicesServiceComponent.getPatient( 
MedRecWebServicesServiceComponent.java:26)

  Unfortunately I couldn't figure out how to get the full stacktrace from 
TargetException.

  Admittedly, this one has me confused.  My first question is why is this 
happening?  My second question is when, if ever, does the SDO layer convert the 
DynamicDataObjectImpl back to the intended return object (in this case a 
Patient object). 

  Thanks.

  -Chris

Re: tuscany-sdo-plugin produces NPE

[Frank Budinsky]

Hi Chris,

This does look quite strange. My guess is that either the schema that this 
is generated from is invalid, causing the generator to generate this weird 
init method, or there's a subtle bug in the generator that the schema is 
bringing out. Either way, it would be good if you could provide us with 
the schema, or a test schema that has the same effect on the init method.

Thanks,
Frank.

"Raymond Feng" <[EMAIL PROTECTED]> wrote on 08/30/2006 05:40:13 PM:

> Hi, Chris,
> 
> Usually MedRecWebServicesPackageImpl.eINSTANCE.eClass() should not be 
called 
> in MedRecWebServicesPackageImpl.init() method. It seems to be a 
> code-generation issue. Frank, Fuwei or Yang, any idea?
> 
> Thanks,
> Raymond
> 
> - Original Message - 
> From: "Chris Wall" <[EMAIL PROTECTED]>
> To: 
> Sent: Wednesday, August 30, 2006 2:12 PM
> Subject: tuscany-sdo-plugin produces NPE
> 
> 
> > Hi.  Within the EPackageImpl implementing class generated by
> > tuscany-sdo-plugin, the init() method calls a method on an instance of
> > itself before the instance is initialized.  For example:
> >
> > 
> >
> >  public static MedRecWebServicesPackageImpl init()
> >  {
> >if (isInited) return
> > (MedRecWebServicesPackageImpl)EPackage.Registry.INSTANCE.getEPackage(
> > MedRecWebServicesPackageImpl.eNS_URI);
> >
> >// Obtain or create and register package
> >MedRecWebServicesPackageImpl theMedRecWebServicesPackageImpl =
> > (MedRecWebServicesPackageImpl)(EPackage.Registry.INSTANCE.
> getEPackage(eNS_URI)
> > instanceof MedRecWebServicesPackageImpl ?
> > EPackage.Registry.INSTANCE.getEPackage(eNS_URI) : new
> > MedRecWebServicesPackageImpl());
> >
> >isInited = true;
> >
> >// Initialize simple dependencies
> >MedRecWebServicesPackageImpl.eINSTANCE.eClass();  < P R O D U C 
E
> > S   N P E
> >SDOPackageImpl.eINSTANCE.eClass();
> >ModelPackageImpl.eINSTANCE.eClass();
> >
> > 
> >
> > The eClass() method needs to be called on 
theMedRecWebServicesPackageImpl,
> > called later in the process once eINSTANCE is initialized, or 
eINSTANCE
> > needs to not be declared final.
> >
> > Thanks.
> >
> > -Chris
> > 
> 
> 
> -
> 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: Call for Eclipse tools work items

[Jean-Sebastien Delfino]

Oisin Hurley wrote:

Hi all,
Over at STP we are putting together work items for our next milestone and
beyond. Obviously Tuscany and STP have (should have!) close links - so 
what
do you Tuscany developers think we should provide in terms of tooling 
support

for developing Tuscany-based services and assemblies?

cheers
--oh

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




Oisin,

I recently spent some time developing SCA sample applications for 
Tuscany (working on the WS-I supply-chain scenario, plus some more 
changes to BigBank that I'll probably drop next week). I have been 
happily using the Eclipse WTP tools for XSDs and WSDLs but I could have 
used some good SCA tools to help me write all the SCA artifacts :) so 
here's my wish list for your STP SCA tooling:


- Get the SCA XSDs registered in the Eclipse XML catalog to get XSD 
based validation of SCDL files and content assist in the XML editor. 
That's what I did by hand in my environment and I found it very useful.

- Support for the SCA 0.96 assembly model in the STP core model.
- Introspection of Java and C++ components and Web services to type 
properties, services and references.
- An eclipse validator that provides further validation of my SCDLs 
(checks SCA wires for example) and provides nice error reporting.
- An SCDL editor with more SCA content assist (which will list all 
interfaces available to you when you create a service or reference or 
potential targets of a reference for example).
- An Eclipse project structure that will allow me to create SCA 
composites and assemble them... somehow.
- A magic button that takes one or more of my projects to the Tuscany 
runtime, or something that does it in the background without me having 
to think about it.


When is your next Milestone? When you have something that works with the 
latest SCA spec level I'll be interested in trying it for my SCA 
application development and helping test it.


--
Jean-Sebastien


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

[jira] Created: (TUSCANY-678) Java XSD files cannot be used to validate SCA Model

[Kapish Aggarwal (JIRA)]

Java XSD files cannot be used to validate SCA Model
---

 Key: TUSCANY-678
 URL: http://issues.apache.org/jira/browse/TUSCANY-678
 Project: Tuscany
  Issue Type: Task
Reporter: Kapish Aggarwal
Priority: Minor


The XSD schema files that are packaged in the tuscany java project are out of 
date with the current SCA model and cannot be used to validate any SCDL files. 
It appears that the C++ is the one being worked on, but the dates of edit do 
not correspond with one C++ being more uptodate than Java. The two sets of XSD 
files need to be synchronized so that both sets reflect the current SCA Model.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] Commented: (TUSCANY-676) ImportSDOLoader: DataTypeImpl not found in XSDEcoreBuilder.typeToTypeObjectMap causes NPE (surfaced as IllegalArgumentException)

[Chris Wall (JIRA)]

[ 
http://issues.apache.org/jira/browse/TUSCANY-676?page=comments#action_12431717 
] 

Chris Wall commented on TUSCANY-676:


Thank Fuhwei.  You were right.  I updated the WSDL and applied the patch 
locally.  The WSDL was successfully loaded.  Thanks!!

> ImportSDOLoader: DataTypeImpl not found in 
> XSDEcoreBuilder.typeToTypeObjectMap causes NPE (surfaced as 
> IllegalArgumentException)
> 
>
> Key: TUSCANY-676
> URL: http://issues.apache.org/jira/browse/TUSCANY-676
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Implementation
>Reporter: Chris Wall
> Attachments: medrec.zip, MedRecWebServices.wsdl, tuscany-676.patch, 
> xsdecorebuilder_npe.zip
>
>
> During SDO import of WSDL, elements of the following complex type are not 
> found when validated against available SDO datatypes within the XSD layer 
> (XSDEcoreBuilder).  Downstream this causes an NPE.  It could be that the 
> comparison between the type and the key is not properly implemented.  See the 
> attached zip containing debug screenshots.
>  targetNamespace="java:com.bea.proto.webservice" xmlns:xs=" 
> http://www.w3.org/2001/XMLSchema";>
>   
> 
>   
>type="xs:dateTime"/>
>type="xs:string"/>
>type="xs:string"/>
>type="xs:string"/>
>type="xs:string"/>
>type="xs:string"/>
>   
> 
>   
> 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

Re: Returning DynamicDataObjectImpl from web service call produces TargetException leads to ClassCastException

[Jim Marino]

Can you send the Target exception stacktrace? It sounds as if  
something is getting swallowed.


Jim


On Aug 30, 2006, at 2:37 PM, Chris Wall wrote:


Hi.  After a successful invocation of a web service, a TargetException
occurs ("Cannot evaulate $Proxy35.toString()") after body is  
returned from

JDKOutboundInvocationHandler.  This eventually leads to a
ClassCastException:

java.lang.ClassCastException:
org.apache.tuscany.sdo.impl.DynamicDataObjectImpl
   at $Proxy35.getPatient(Unknown Source)
   at
com.bea.proto.webservice.client.MedRecWebServicesServiceComponent.getP 
atient

(MedRecWebServicesServiceComponent.java:26)

Unfortunately I couldn't figure out how to get the full stacktrace  
from

TargetException.

Admittedly, this one has me confused.  My first question is why is  
this
happening?  My second question is when, if ever, does the SDO layer  
convert
the DynamicDataObjectImpl back to the intended return object (in  
this case a

Patient object).

Thanks.

-Chris



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

Re: tuscany-sdo-plugin produces NPE

[Raymond Feng]

Hi, Chris,

Usually MedRecWebServicesPackageImpl.eINSTANCE.eClass() should not be called 
in MedRecWebServicesPackageImpl.init() method. It seems to be a 
code-generation issue. Frank, Fuwei or Yang, any idea?


Thanks,
Raymond

- Original Message - 
From: "Chris Wall" <[EMAIL PROTECTED]>

To: 
Sent: Wednesday, August 30, 2006 2:12 PM
Subject: tuscany-sdo-plugin produces NPE



Hi.  Within the EPackageImpl implementing class generated by
tuscany-sdo-plugin, the init() method calls a method on an instance of
itself before the instance is initialized.  For example:



 public static MedRecWebServicesPackageImpl init()
 {
   if (isInited) return
(MedRecWebServicesPackageImpl)EPackage.Registry.INSTANCE.getEPackage(
MedRecWebServicesPackageImpl.eNS_URI);

   // Obtain or create and register package
   MedRecWebServicesPackageImpl theMedRecWebServicesPackageImpl =
(MedRecWebServicesPackageImpl)(EPackage.Registry.INSTANCE.getEPackage(eNS_URI)
instanceof MedRecWebServicesPackageImpl ?
EPackage.Registry.INSTANCE.getEPackage(eNS_URI) : new
MedRecWebServicesPackageImpl());

   isInited = true;

   // Initialize simple dependencies
   MedRecWebServicesPackageImpl.eINSTANCE.eClass();  < P R O D U C E
S   N P E
   SDOPackageImpl.eINSTANCE.eClass();
   ModelPackageImpl.eINSTANCE.eClass();



The eClass() method needs to be called on theMedRecWebServicesPackageImpl,
called later in the process once eINSTANCE is initialized, or eINSTANCE
needs to not be declared final.

Thanks.

-Chris




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

Re: Process and content for next release?

[Jim Marino]

Joel,

If you need any help, ping me.

Jim


On Aug 30, 2006, at 8:51 AM, Hawkins, Joel wrote:


Thanks - that gives me some dates to shoot for.

-Original Message-
From: Jeremy Boynes [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 30, 2006 11:48 AM
To: tuscany-dev@ws.apache.org
Subject: Re: Process and content for next release?

Basically, when it's done :-) Having said that, see below for the
estimates I would make for the separate stages. If they are anywhere
near accurate then I think we're looking towards the end of September
(which seems like a good time just before ApacheCon).

By publish, I mean having a stable but unreleased artifact in the
snapshot maven repo.
--
Jeremy

On Aug 30, 2006, at 8:23 AM, Hawkins, Joel wrote:


Jeremy, when is your target date for this next release? I hope to get
back to the OSGi binding/hosting code within the next week and I'd
really like to try and get something into the release.



... snip ...



1) Specs (sdo-api, sca-api, commonj)
   These should be stable now as the specifications have been
published.


I think these are ready and we can publish a stable version now.


2) SCA Core (spi, core, hostutil, test, plus apis once that
refactor is done)
   Features I would like to see complete before we consider this
stable are:
  Class loading changes
  Integration of databinding framework
  Support for async callbacks
  Support for complex properties
  Transitive dependency support


I hope that we can get this wrapped and published by 9/11


3) Baseline extensions - ones we think are essential for users
   idl.wsdl9/11
   binding.axis9/18 (depends on Axis 1.1 release)
   binding.celtix  9/18
   binding.rmi 9/11
   databinding.axiom   9/11
   databinding.sdo 9/11 (depends on a SDO release)
   databinding.jaxb9/11
   container.javascript
   container.spring


I am assuming the axiom, sdo and jaxb databindings sync with the
framework as we need something there to test it out.
I don't have a good feeling for how long it will take to get the
containers working.


4) Optional extensions - nice to have but which may not be ready to
bundle
   binding.jsonrpc
   binding.osgi
   databinding.xmlbeans
   databinding.castor
   container.groovy

5) Host distributions - host environments that each form the basis
for each bundle
   Standalone (with axis, celtix, rmi, spring)
   Web-app (with axis, celtix, rmi, json, spring, javascript)


Based on Jim's feedback I don't think we would be doing a Web-app
distribution; instead there would be a web-app maven plugin to
package a war with a suitably configured war inside it. See 7) for  
that.



6) Sample applications
   Technology sample framework (subject of another mail)
   BigBank application if ready


 7) Tools
Web-app maven plugin   9/4


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

The contents of this e-mail are intended for the named addressee  
only. It contains information that may be confidential. Unless you  
are the named addressee or an authorized designee, you may not copy  
or use it, or disclose it to anyone else. If you received it in  
error please notify us immediately and then destroy it.


-
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]

Returning DynamicDataObjectImpl from web service call produces TargetException leads to ClassCastException

[Chris Wall]

Hi.  After a successful invocation of a web service, a TargetException
occurs ("Cannot evaulate $Proxy35.toString()") after body is returned from
JDKOutboundInvocationHandler.  This eventually leads to a
ClassCastException:

java.lang.ClassCastException:
org.apache.tuscany.sdo.impl.DynamicDataObjectImpl
   at $Proxy35.getPatient(Unknown Source)
   at
com.bea.proto.webservice.client.MedRecWebServicesServiceComponent.getPatient
(MedRecWebServicesServiceComponent.java:26)

Unfortunately I couldn't figure out how to get the full stacktrace from
TargetException.

Admittedly, this one has me confused.  My first question is why is this
happening?  My second question is when, if ever, does the SDO layer convert
the DynamicDataObjectImpl back to the intended return object (in this case a
Patient object).

Thanks.

-Chris

tuscany-sdo-plugin produces NPE

[Chris Wall]

Hi.  Within the EPackageImpl implementing class generated by
tuscany-sdo-plugin, the init() method calls a method on an instance of
itself before the instance is initialized.  For example:



 public static MedRecWebServicesPackageImpl init()
 {
   if (isInited) return
(MedRecWebServicesPackageImpl)EPackage.Registry.INSTANCE.getEPackage(
MedRecWebServicesPackageImpl.eNS_URI);

   // Obtain or create and register package
   MedRecWebServicesPackageImpl theMedRecWebServicesPackageImpl =
(MedRecWebServicesPackageImpl)(EPackage.Registry.INSTANCE.getEPackage(eNS_URI)
instanceof MedRecWebServicesPackageImpl ?
EPackage.Registry.INSTANCE.getEPackage(eNS_URI) : new
MedRecWebServicesPackageImpl());

   isInited = true;

   // Initialize simple dependencies
   MedRecWebServicesPackageImpl.eINSTANCE.eClass();  < P R O D U C E
S   N P E
   SDOPackageImpl.eINSTANCE.eClass();
   ModelPackageImpl.eINSTANCE.eClass();



The eClass() method needs to be called on theMedRecWebServicesPackageImpl,
called later in the process once eINSTANCE is initialized, or eINSTANCE
needs to not be declared final.

Thanks.

-Chris

Re: Optiional Autowire

[Jim Marino]

On Aug 30, 2006, at 1:41 PM, Rick wrote:


Sure why meddle with the master! :-)
I'd actually not mind avoiding doing it myself but I prefer that to  
having to reconcile changes
Seriously, the only request I would have is if convenient could you  
make it a separate svn checkin? Just like to review what you did  
for just this.

Yep. That's what I intend to do
The autowire information as far as I see is lost in the connection  
building phase, unless I missed it.  Was wondering if it could not  
be added directly to the ServiceContract.
It shouldn't be on the service contract since it is part of the  
component type (autowire is really a type of reference).  
ReferenceDefinition already contains the information needed and can  
be accessed from the system component builder.


Jim






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

Re: Optiional Autowire

[Rick]

Sure why meddle with the master! :-)  Seriously, the only request I would have 
is if convenient could you make it a separate svn checkin? Just like to review 
what you did for just this.  The autowire information as far as I see is lost in 
the connection building phase, unless I missed it.  Was wondering if it could 
not be added directly to the ServiceContract.


Jim Marino wrote:
Yes. System outbound autowire needs to be configured to either throw or 
not throw an exception based on the resolution strategy. Since I am in 
the midst of the service contract and operation changes, can you let me 
make this change after my commit tonight so as not to cause conflicts?


Jim


On Aug 30, 2006, at 1:17 PM, Rick wrote:

For webservices binding in the J2SE client case there is an autowire 
for ServletHost being called, but the jars for this deployment do not 
include an implementation for this so you receive the following
org.apache.tuscany.spi.component.TargetNotFoundException: Autowire 
target not found [org.apache.tuscany.spi.host.ServletHost]


Some discussion on the IRC seems to lead that that the preferred 
solution is  required/optional option on the autowire annotation.  
I've looked into this and seen where to add it  to 
(ReferenceDefinition) , but where the exception is 
invoked(SystemOutboundAutowire)  I have not been able to pick up where 
that is passed along.


Is this where we could just not throw this exception to have the 
autowired just ignored?

Thanks

-
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]




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

Auto-config for collision column

[Kevin Williams]

Currently, in the absence of otherwise conflicting, explicit 
configuration, we assume that any DO property named "id" will map to a 
primary key column in the database.  Likewise a property name of the 
form "x_id" maps to a foreign key column that references some row in 
table "x". 

I would like to add another "auto configuration" convention for the RDB 
DAS for "collision" properties.  So, any DO property with the name 
"occ_count" will be assumed to map to an integer table column that is 
used for optimistic concurrency control.  This column will then be used 
to overqualify any related UPDATE statements for that table.  In the 
future, we may want to add support for "occ_timestamp", etc.


Any comments?

Thanks,

--Kevin


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

Re: Optiional Autowire

[Jim Marino]

Yes. System outbound autowire needs to be configured to either throw  
or not throw an exception based on the resolution strategy. Since I  
am in the midst of the service contract and operation changes, can  
you let me make this change after my commit tonight so as not to  
cause conflicts?


Jim


On Aug 30, 2006, at 1:17 PM, Rick wrote:

For webservices binding in the J2SE client case there is an  
autowire for ServletHost being called, but the jars for this  
deployment do not include an implementation for this so you receive  
the following
org.apache.tuscany.spi.component.TargetNotFoundException: Autowire  
target not found [org.apache.tuscany.spi.host.ServletHost]


Some discussion on the IRC seems to lead that that the preferred  
solution is  required/optional option on the autowire annotation.   
I've looked into this and seen where to add it  to  
(ReferenceDefinition) , but where the exception is invoked 
(SystemOutboundAutowire)  I have not been able to pick up where  
that is passed along.


Is this where we could just not throw this exception to have the  
autowired just ignored?

Thanks

-
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: svn commit: r438568 - /incubator/tuscany/java/spec/sca/pom.xml

[Daniel Kulp]

Jeremy,

Careful with this   Tuscany is an incubator project.   Thus, releases 
(like milestone releases) are not allowed to go the the rsync repositories 
that are defined in the apache pom:
http://www.apache.org/dev/repository-faq.html
snapshot are OK to go to that repository (providing the Tuscany PMC's are OK 
with them), but when you go to deploy a release, you'll NOT have happy PMC's 
if they end up going to ibiblio.


Dan


On Wednesday August 30 2006 2:03 pm, [EMAIL PROTECTED] wrote:
> Author: jboynes
> Date: Wed Aug 30 11:03:19 2006
> New Revision: 438568
>
> URL: http://svn.apache.org/viewvc?rev=438568&view=rev
> Log:
> inherit settings from Apache POM
> centralize the spec version
>
> Modified:
> incubator/tuscany/java/spec/sca/pom.xml
>
> Modified: incubator/tuscany/java/spec/sca/pom.xml
> URL:
> http://svn.apache.org/viewvc/incubator/tuscany/java/spec/sca/pom.xml?rev=43
>8568&r1=438567&r2=438568&view=diff
> ===
>=== --- incubator/tuscany/java/spec/sca/pom.xml (original)
> +++ incubator/tuscany/java/spec/sca/pom.xml Wed Aug 30 11:03:19 2006
> @@ -19,46 +19,29 @@
>  -->
>  
>  4.0.0
> +
> +org.apache
> +apache
> +3
> +
>  org.osoa
> -sca-api-r0.95
> +sca-api-r${specVersion}
>  SCA API
>  API classes for the Service Component
> Architecture 1.0-SNAPSHOT
> -jar
> +osgi-bundle
>
> +
> +0.95
> +
>  
>  2.0.4
>  
>
> -
> -The Apache Software Foundation
> -http://www.apache.org
> -
> -
> -
> -The Apache Software License, Version 2.0
> -http://www.apache.org/licenses/LICENSE-2.0.txt
> -repo
> -
> -
> -
> -
> -
> -apache-incubator-repository
> -Apache Incubator Repository
> -   
> scp:///www/people.apache.org/repo/m2-snapshot-repository -  
>  
> -
> -apache-snapshot-repository
> -Apache SNAPSHOT Repository
> -   
> scp:///www/people.apache.org/repo/m2-snapshot-repository -  
>  
> -
> -
>  
> -   
> scm:svn:http://svn.apache.org/repos/asf/incubator/tuscany/java/
>spec -   
> scm:svn:https://svn.apache.org/repos/asf/incubator/tus
>cany/java/spec -   
> http://svn.apache.org/viewvc/incubator/tuscany/java/spec +  
> 
> scm:svn:http://svn.apache.org/repos/asf/incubator/tuscany/java/
>spec/sca +   
> scm:svn:https://svn.apache.org/repos/asf/incubator/tus
>cany/java/spec/sca +   
> http://svn.apache.org/viewvc/incubator/tuscany/java/spec/sca
> 
>
>  
> @@ -98,7 +81,7 @@
> 
> ${pom.organization.name}
> plugin
> org.osoa.sca -
>org.osoa.sca;version="0.95",
> org.osoa.sca.annotations;version="0.95" +  
>  org.osoa.sca;version="${specVersion}",
> org.osoa.sca.annotations;version="${specVersion}"
> 
>  
>  
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]

-- 
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727C: 508-380-7194   F:781-902-8001
[EMAIL PROTECTED]

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

Optiional Autowire

[Rick]

For webservices binding in the J2SE client case there is an autowire for 
ServletHost being called, but the jars for this deployment do not 
include an implementation for this so you receive the following
org.apache.tuscany.spi.component.TargetNotFoundException: Autowire 
target not found [org.apache.tuscany.spi.host.ServletHost]


Some discussion on the IRC seems to lead that that the preferred 
solution is  required/optional option on the autowire annotation.  I've 
looked into this and seen where to add it  to (ReferenceDefinition) , 
but where the exception is invoked(SystemOutboundAutowire)  I have not 
been able to pick up where that is passed along.


Is this where we could just not throw this exception to have the 
autowired just ignored?

Thanks

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

SPI changes to support ServiceContract and Operation

[Jim Marino]

I plan on making changes to the SPI to move from the use of  
specifying service contracts with Java interfaces to the use of  
ServiceContract/Operation. If you have outstanding checkins, please  
get them in ASAP. I plan to start the conversion tonight (with a more  
detailed description of changes) unless there are objections.


Jim


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

Re: Registry proposal, was: Delivery Status Notification (Failure)

[Jeremy Boynes]

On Aug 30, 2006, at 12:20 PM, Yang ZHONG wrote:


No problem, consider them removed in API.

Sorry, what's the WSDL model used in SCA again please?


We don't really model WSDL. We do parse it using WSDL4J for now but  
need something to support WSDL2.0 (probably Woden when it can support  
1.1).

--
Jeremy

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

Re: Registry proposal, was: Delivery Status Notification (Failure)

[Yang ZHONG]

No problem, consider them removed in API.

Sorry, what's the WSDL model used in SCA again please?


On 8/30/06, Jim Marino <[EMAIL PROTECTED]> wrote:



On Aug 30, 2006, at 11:59 AM, Yang ZHONG wrote:

> Thank Ant so much for details, that's very helpful!
>
> I'll update the API:
> 2-1. remove INSTANCE
> 2-2. demonstrate the SCA way to get SymbolSpace.Registry
> implementation in
> JavaDoc
>
Why do we have the "inner" interface? I agree with Jeremy that it
doesn't seem very intuitive.

> SymbolSpace.Registry is the generic registry interface, it doesn't
> prevent
> us from having SCA specific interface(s).
> I can come up with a WSDL Registry interface proposal. Can someone
> tell me
> which model is used by SCA: WST, WSDL4J, EMF, home grown or
> anything else?
>
> On 8/30/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote:
>>
>> I'm having trouble parsing this. Are you talking about an SCA
>> registry, or a WSDL registry, or the mechanism for locating it (via
>> IoC as Ant described or something else)?
>>
>> I was saying that in an IoC world there is /no/ provider part of the
>> API - a user never locates anything, they declare dependencies and
>> the container resolves them. The dependency would be on the actual
>> client interface (SymbolSpace.Registry I guess but I've already
>> admitted to not grokking the interfaces).
>>
>> --
>> Jeremy
>>
>> On Aug 30, 2006, at 11:28 AM, Yang ZHONG wrote:
>>
>> > Can someone propose a SCA specific API mentioned by Jeremy please?
>> > Something like
>> >  interface ScaRegistry
>> >  {
>> >Definition getDefinition (String nameSpace);
>> >Message getMessage (QName);
>> >  }
>> > I don't know the SCA requirement much enough to make such proposal.
>> >
>> > At the same time, we can practise IoC in ScaRegistry service
>> locating.
>> > I hope I can learn from that practice and update the registry
>> > generic API
>> > accordingly.
>> >
>> > Thanks for pointing out a nice mechanism.
>> >
>> > On 8/30/06, Jim Marino <[EMAIL PROTECTED]> wrote:
>> >>
>> >>
>> >> On Aug 30, 2006, at 10:49 AM, Jeremy Boynes wrote:
>> >>
>> >> > As part of Tuscany there should not be any mechanism in a API
>> for
>> >> > "service location" - that is the responsibility of the IoC
>> >> container.
>> >> >
>> >> +1 (which nicely avoids external dependencies on some locator
>> >> implementation and evil Singletons)
>> >>
>> >> > --
>> >> > Jeremy
>> >> >
>> >>
>> >>
>> >>
>> -
>> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> >> For additional commands, e-mail: [EMAIL PROTECTED]
>> >>
>> >>
>> >
>> >
>> > --
>> >
>> > Yang ZHONG
>>
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
>
> --
>
> Yang ZHONG


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





--

Yang ZHONG

Re: Registry proposal, was: Delivery Status Notification (Failure)

[Jim Marino]

On Aug 30, 2006, at 11:59 AM, Yang ZHONG wrote:


Thank Ant so much for details, that's very helpful!

I'll update the API:
2-1. remove INSTANCE
2-2. demonstrate the SCA way to get SymbolSpace.Registry  
implementation in

JavaDoc

Why do we have the "inner" interface? I agree with Jeremy that it  
doesn't seem very intuitive.


SymbolSpace.Registry is the generic registry interface, it doesn't  
prevent

us from having SCA specific interface(s).
I can come up with a WSDL Registry interface proposal. Can someone  
tell me
which model is used by SCA: WST, WSDL4J, EMF, home grown or  
anything else?


On 8/30/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote:


I'm having trouble parsing this. Are you talking about an SCA
registry, or a WSDL registry, or the mechanism for locating it (via
IoC as Ant described or something else)?

I was saying that in an IoC world there is /no/ provider part of the
API - a user never locates anything, they declare dependencies and
the container resolves them. The dependency would be on the actual
client interface (SymbolSpace.Registry I guess but I've already
admitted to not grokking the interfaces).

--
Jeremy

On Aug 30, 2006, at 11:28 AM, Yang ZHONG wrote:

> Can someone propose a SCA specific API mentioned by Jeremy please?
> Something like
>  interface ScaRegistry
>  {
>Definition getDefinition (String nameSpace);
>Message getMessage (QName);
>  }
> I don't know the SCA requirement much enough to make such proposal.
>
> At the same time, we can practise IoC in ScaRegistry service  
locating.

> I hope I can learn from that practice and update the registry
> generic API
> accordingly.
>
> Thanks for pointing out a nice mechanism.
>
> On 8/30/06, Jim Marino <[EMAIL PROTECTED]> wrote:
>>
>>
>> On Aug 30, 2006, at 10:49 AM, Jeremy Boynes wrote:
>>
>> > As part of Tuscany there should not be any mechanism in a API  
for

>> > "service location" - that is the responsibility of the IoC
>> container.
>> >
>> +1 (which nicely avoids external dependencies on some locator
>> implementation and evil Singletons)
>>
>> > --
>> > Jeremy
>> >
>>
>>
>>  
-

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


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





--

Yang ZHONG



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

Re: Registry proposal, was: Delivery Status Notification (Failure)

[Yang ZHONG]

Thank Ant so much for details, that's very helpful!

I'll update the API:
2-1. remove INSTANCE
2-2. demonstrate the SCA way to get SymbolSpace.Registry implementation in
JavaDoc

SymbolSpace.Registry is the generic registry interface, it doesn't prevent
us from having SCA specific interface(s).
I can come up with a WSDL Registry interface proposal. Can someone tell me
which model is used by SCA: WST, WSDL4J, EMF, home grown or anything else?

On 8/30/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote:


I'm having trouble parsing this. Are you talking about an SCA
registry, or a WSDL registry, or the mechanism for locating it (via
IoC as Ant described or something else)?

I was saying that in an IoC world there is /no/ provider part of the
API - a user never locates anything, they declare dependencies and
the container resolves them. The dependency would be on the actual
client interface (SymbolSpace.Registry I guess but I've already
admitted to not grokking the interfaces).

--
Jeremy

On Aug 30, 2006, at 11:28 AM, Yang ZHONG wrote:

> Can someone propose a SCA specific API mentioned by Jeremy please?
> Something like
>  interface ScaRegistry
>  {
>Definition getDefinition (String nameSpace);
>Message getMessage (QName);
>  }
> I don't know the SCA requirement much enough to make such proposal.
>
> At the same time, we can practise IoC in ScaRegistry service locating.
> I hope I can learn from that practice and update the registry
> generic API
> accordingly.
>
> Thanks for pointing out a nice mechanism.
>
> On 8/30/06, Jim Marino <[EMAIL PROTECTED]> wrote:
>>
>>
>> On Aug 30, 2006, at 10:49 AM, Jeremy Boynes wrote:
>>
>> > As part of Tuscany there should not be any mechanism in a API for
>> > "service location" - that is the responsibility of the IoC
>> container.
>> >
>> +1 (which nicely avoids external dependencies on some locator
>> implementation and evil Singletons)
>>
>> > --
>> > Jeremy
>> >
>>
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
>
> --
>
> Yang ZHONG


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





--

Yang ZHONG

Re: Registry proposal, was: Delivery Status Notification (Failure)

[Jeremy Boynes]

I'm having trouble parsing this. Are you talking about an SCA  
registry, or a WSDL registry, or the mechanism for locating it (via  
IoC as Ant described or something else)?


I was saying that in an IoC world there is /no/ provider part of the  
API - a user never locates anything, they declare dependencies and  
the container resolves them. The dependency would be on the actual  
client interface (SymbolSpace.Registry I guess but I've already  
admitted to not grokking the interfaces).


--
Jeremy

On Aug 30, 2006, at 11:28 AM, Yang ZHONG wrote:


Can someone propose a SCA specific API mentioned by Jeremy please?
Something like
 interface ScaRegistry
 {
   Definition getDefinition (String nameSpace);
   Message getMessage (QName);
 }
I don't know the SCA requirement much enough to make such proposal.

At the same time, we can practise IoC in ScaRegistry service locating.
I hope I can learn from that practice and update the registry  
generic API

accordingly.

Thanks for pointing out a nice mechanism.

On 8/30/06, Jim Marino <[EMAIL PROTECTED]> wrote:



On Aug 30, 2006, at 10:49 AM, Jeremy Boynes wrote:

> As part of Tuscany there should not be any mechanism in a API for
> "service location" - that is the responsibility of the IoC  
container.

>
+1 (which nicely avoids external dependencies on some locator
implementation and evil Singletons)

> --
> Jeremy
>


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





--

Yang ZHONG



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

Re: Registry proposal, was: Delivery Status Notification (Failure)

[ant elder]

In case its not completely clear from Jeremy and Jim's emails what to do:
you could define a client interface for the registry, write an
implementation of that and define that impl class name in some scdl. We can
then include the scdl in the runtime and things could use autowire to get
hold of the registry instance. As and example of this you can look at our
ServletHost, ServletHostImpl, how thats defined in the web app scdl, and
then how thats used by the Axis2 binding:

http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/spi/src/main/java/org/apache/tuscany/spi/host/ServletHost.java
http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/runtime/webapp-host/src/main/java/org/apache/tuscany/runtime/webapp/ServletHostImpl.java
http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/runtime/webapp-host/src/main/resources/META-INF/sca/webapp.system.scdl
http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/bindings/binding.axis2/src/main/java/org/apache/tuscany/binding/axis2/Axis2BindingBuilder.java

  ...ant

On 8/30/06, Jim Marino <[EMAIL PROTECTED]> wrote:



On Aug 30, 2006, at 10:49 AM, Jeremy Boynes wrote:

> As part of Tuscany there should not be any mechanism in a API for
> "service location" - that is the responsibility of the IoC container.
>
+1 (which nicely avoids external dependencies on some locator
implementation and evil Singletons)

> --
> Jeremy
>


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

Re: Registry proposal, was: Delivery Status Notification (Failure)

[Yang ZHONG]

Can someone propose a SCA specific API mentioned by Jeremy please?
Something like
 interface ScaRegistry
 {
   Definition getDefinition (String nameSpace);
   Message getMessage (QName);
 }
I don't know the SCA requirement much enough to make such proposal.

At the same time, we can practise IoC in ScaRegistry service locating.
I hope I can learn from that practice and update the registry generic API
accordingly.

Thanks for pointing out a nice mechanism.

On 8/30/06, Jim Marino <[EMAIL PROTECTED]> wrote:



On Aug 30, 2006, at 10:49 AM, Jeremy Boynes wrote:

> As part of Tuscany there should not be any mechanism in a API for
> "service location" - that is the responsibility of the IoC container.
>
+1 (which nicely avoids external dependencies on some locator
implementation and evil Singletons)

> --
> Jeremy
>


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





--

Yang ZHONG

Re: Registry proposal, was: Delivery Status Notification (Failure)

[Jim Marino]

On Aug 30, 2006, at 10:49 AM, Jeremy Boynes wrote:

As part of Tuscany there should not be any mechanism in a API for  
"service location" - that is the responsibility of the IoC container.


+1 (which nicely avoids external dependencies on some locator  
implementation and evil Singletons)



--
Jeremy




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

Re: Registry proposal, was: Delivery Status Notification (Failure)

[Jeremy Boynes]

As part of Tuscany there should not be any mechanism in a API for  
"service location" - that is the responsibility of the IoC container.

--
Jeremy

On Aug 30, 2006, at 10:43 AM, Yang ZHONG wrote:

I'm fine with other service locating mechanisms, please name one  
and I'll

update.

Please keep little dependency. If the other mechanism(s) has  
dependency more

than just J2SE such as SCA, JNDI repository,
may be we can have several mechanism coexisted target various  
requirement...


Thanks again for comments.

On 8/30/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote:


I don't think we need "Provider" at all.
--
Jeremy

On Aug 30, 2006, at 9:59 AM, Jim Marino wrote:

> I had one additional comment: is there a reason we have to use the
> ".INSTANCE" approach to locating the default Provider?
>
> Jim
>
> On Aug 30, 2006, at 9:39 AM, Yang ZHONG wrote:
>
>> Raymond guessed right that it's an API/SPI review, so no impl/
>> tests attached
>> yet although I have some impl already.
>>
>> Ant guessed right too that I forgot to grant license, I must be
>> not thinking
>> straight working late :-)
>> I don't see any link to post-grant, I'll remember to do that for
>> following
>> attachments. Thank Ant.
>>
>> There's "neither* EMF *nor* Eclipse dependency. impl/EMF and impl/
>> Eclipse
>> are just subproject targeting certain usage.
>> Please take a look at ReadMe.txt for more details, it also have
>> info to find
>> Class Diagram and others.
>>
>> I agree with Jeremy that strongly-typed Maps/interfaces are  
sometimes

>> preferred.
>> Actually, generalization and extensibility is exactly the selling
>> point of
>> this generic registry.
>> Tailoring can be done based on the framework/infrastructure/
>> fundation (as
>> Raymond commented).
>> There're at least two ways to provide strong interfaces over this
>> registry.
>> 2-1. Delegating
>> new StrongInterface()
>> {
>>  public MySymbol getMySymbol (QName qName)
>>  {
>>return mySymbolSpace.resolve( qName);
>>  }
>> }
>> 2-2. Extending
>>  class StrongInterfaceImpl extends SymbolSpaceImpl implement
>> StrongInterface
>>
>> Thank everyone for all comments.
>>
>> On 8/30/06, Raymond Feng <[EMAIL PROTECTED]> wrote:
>>>
>>> Hi,
>>>
>>> Please see my comments in line.
>>>
>>> Thanks,
>>> Raymond
>>>
>>> - Original Message -
>>> From: "Jeremy Boynes" <[EMAIL PROTECTED]>
>>> To: 
>>> Sent: Wednesday, August 30, 2006 8:19 AM
>>> Subject: Registry proposal, was: Delivery Status Notification
>>> (Failure)
>>>
>>>
>>> >I might be missing something as well but I didn't see any code
>>> under  impl
>>> >at all
>>>
>>> I guess it's for the API/SPI review first.
>>>
>>> >
>>> > I'm also with Ant in thinking we should not have a dependency
>>> on EMF.
>>> >
>>>
>>> From the javadoc, I don't see the EMF dependencies.
>>>
>>> > I'd also add that I found it difficult to grok the
>>> relationships  between
>>> > all the interfaces and inner-interfaces and how the behaviour
>>> would
>>> > integrate with Map semantics - for example, how does this
>>> differ from
>>> > just using strongly-typed Maps?
>>>
>>> I agree. If the interface is designed for public API/SPI, it
>>> should be
>>> first-class interface instead of being inner.
>>>
>>> I'm also seeing a lot of naming conflicts among API and SPI
>>> interfaces/classes/parameterized types. This seems to be very
>>> problematic
>>> to
>>> me. When we run out of names, it means to me we don't model it
>>> correctly.
>>>
>>> A class diagram would be of great help for us.
>>>
>>> >
>>> > I'm also not convinced that throwing everything (all types of
>>> stuff)  into
>>> > one central registry model is a good way to go. I can see a
>>> lot  of
>>> > benefit in having more specialized interfaces tailored for
>>> each  type of
>>> > stuff.
>>>
>>> I guess we can reuse the same infrastrcture backed by the generic
>>> registry
>>> but provide more specialized interfaces on top of it. And we can
>>> also
>>> choose
>>> to have separate instances of registries for specific domains.
>>>
>>> >
>>> > --
>>> > Jeremy
>>> >
>>> > On Aug 30, 2006, at 4:10 AM, ant elder wrote:
>>> >
>>> >> Having this attached to a JIRA is fine, thats preferred over
>>> sending
>>> >> attachments to the dev list.
>>> >>
>>> >> Thanks for all this, I've only just started looking but it
>>> looks very
>>> >> comprehensive, a lot more than I was expecting 8-). I've a
>>> few  questions
>>> >> so
>>> >> far. Firstly you didn't click the button granting license of
>>> the  code
>>> to
>>> >> the
>>> >> ASF, was that an oversight? The readme talks about some test
>>> examples
>>> >> and
>>> >> samples showing how to use the registry but the test folders
>>> don't  seem
>>> >> to
>>> >> be included in the zip? From the brief look it wasn't clear to
>>> me  if
>>> the
>>> >> registry will require EMF, hopefully it doesn't?
>>> >>
>>> >> Thanks,
>>> >>
>>> >>   ...ant
>>> >>
>>> >> On 8/30/06, Yang ZHONG <[EMAIL PROTECTED]> wrote:
>>> >>>
>>> >>> Neither tuscany-dev nor

Re: Registry proposal, was: Delivery Status Notification (Failure)

[Yang ZHONG]

I'm fine with other service locating mechanisms, please name one and I'll
update.

Please keep little dependency. If the other mechanism(s) has dependency more
than just J2SE such as SCA, JNDI repository,
may be we can have several mechanism coexisted target various requirement...

Thanks again for comments.

On 8/30/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote:


I don't think we need "Provider" at all.
--
Jeremy

On Aug 30, 2006, at 9:59 AM, Jim Marino wrote:

> I had one additional comment: is there a reason we have to use the
> ".INSTANCE" approach to locating the default Provider?
>
> Jim
>
> On Aug 30, 2006, at 9:39 AM, Yang ZHONG wrote:
>
>> Raymond guessed right that it's an API/SPI review, so no impl/
>> tests attached
>> yet although I have some impl already.
>>
>> Ant guessed right too that I forgot to grant license, I must be
>> not thinking
>> straight working late :-)
>> I don't see any link to post-grant, I'll remember to do that for
>> following
>> attachments. Thank Ant.
>>
>> There's "neither* EMF *nor* Eclipse dependency. impl/EMF and impl/
>> Eclipse
>> are just subproject targeting certain usage.
>> Please take a look at ReadMe.txt for more details, it also have
>> info to find
>> Class Diagram and others.
>>
>> I agree with Jeremy that strongly-typed Maps/interfaces are sometimes
>> preferred.
>> Actually, generalization and extensibility is exactly the selling
>> point of
>> this generic registry.
>> Tailoring can be done based on the framework/infrastructure/
>> fundation (as
>> Raymond commented).
>> There're at least two ways to provide strong interfaces over this
>> registry.
>> 2-1. Delegating
>> new StrongInterface()
>> {
>>  public MySymbol getMySymbol (QName qName)
>>  {
>>return mySymbolSpace.resolve( qName);
>>  }
>> }
>> 2-2. Extending
>>  class StrongInterfaceImpl extends SymbolSpaceImpl implement
>> StrongInterface
>>
>> Thank everyone for all comments.
>>
>> On 8/30/06, Raymond Feng <[EMAIL PROTECTED]> wrote:
>>>
>>> Hi,
>>>
>>> Please see my comments in line.
>>>
>>> Thanks,
>>> Raymond
>>>
>>> - Original Message -
>>> From: "Jeremy Boynes" <[EMAIL PROTECTED]>
>>> To: 
>>> Sent: Wednesday, August 30, 2006 8:19 AM
>>> Subject: Registry proposal, was: Delivery Status Notification
>>> (Failure)
>>>
>>>
>>> >I might be missing something as well but I didn't see any code
>>> under  impl
>>> >at all
>>>
>>> I guess it's for the API/SPI review first.
>>>
>>> >
>>> > I'm also with Ant in thinking we should not have a dependency
>>> on EMF.
>>> >
>>>
>>> From the javadoc, I don't see the EMF dependencies.
>>>
>>> > I'd also add that I found it difficult to grok the
>>> relationships  between
>>> > all the interfaces and inner-interfaces and how the behaviour
>>> would
>>> > integrate with Map semantics - for example, how does this
>>> differ from
>>> > just using strongly-typed Maps?
>>>
>>> I agree. If the interface is designed for public API/SPI, it
>>> should be
>>> first-class interface instead of being inner.
>>>
>>> I'm also seeing a lot of naming conflicts among API and SPI
>>> interfaces/classes/parameterized types. This seems to be very
>>> problematic
>>> to
>>> me. When we run out of names, it means to me we don't model it
>>> correctly.
>>>
>>> A class diagram would be of great help for us.
>>>
>>> >
>>> > I'm also not convinced that throwing everything (all types of
>>> stuff)  into
>>> > one central registry model is a good way to go. I can see a
>>> lot  of
>>> > benefit in having more specialized interfaces tailored for
>>> each  type of
>>> > stuff.
>>>
>>> I guess we can reuse the same infrastrcture backed by the generic
>>> registry
>>> but provide more specialized interfaces on top of it. And we can
>>> also
>>> choose
>>> to have separate instances of registries for specific domains.
>>>
>>> >
>>> > --
>>> > Jeremy
>>> >
>>> > On Aug 30, 2006, at 4:10 AM, ant elder wrote:
>>> >
>>> >> Having this attached to a JIRA is fine, thats preferred over
>>> sending
>>> >> attachments to the dev list.
>>> >>
>>> >> Thanks for all this, I've only just started looking but it
>>> looks very
>>> >> comprehensive, a lot more than I was expecting 8-). I've a
>>> few  questions
>>> >> so
>>> >> far. Firstly you didn't click the button granting license of
>>> the  code
>>> to
>>> >> the
>>> >> ASF, was that an oversight? The readme talks about some test
>>> examples
>>> >> and
>>> >> samples showing how to use the registry but the test folders
>>> don't  seem
>>> >> to
>>> >> be included in the zip? From the brief look it wasn't clear to
>>> me  if
>>> the
>>> >> registry will require EMF, hopefully it doesn't?
>>> >>
>>> >> Thanks,
>>> >>
>>> >>   ...ant
>>> >>
>>> >> On 8/30/06, Yang ZHONG <[EMAIL PROTECTED]> wrote:
>>> >>>
>>> >>> Neither tuscany-dev nor infra takes my email with attachment,
>>> so I've
>>> >>> attached file for review into
>>> >>> http://issues.apache.org/jira/browse/TUSCANY-677
>>> >>>
>>> >>> Sorry for the inconvenience and thanks for any c

[jira] Updated: (TUSCANY-676) ImportSDOLoader: DataTypeImpl not found in XSDEcoreBuilder.typeToTypeObjectMap causes NPE (surfaced as IllegalArgumentException)

[Fuhwei Lwo (JIRA)]

 [ http://issues.apache.org/jira/browse/TUSCANY-676?page=all ]

Fuhwei Lwo updated TUSCANY-676:
---

Attachment: tuscany-676.patch
MedRecWebServices.wsdl

Hi Chris,

Can you apply the patch and rebuild sdo/impl and test with the new wsdl file I 
attached?  Your original wsdl file is not valid because you are trying to 
reference type from different namespace.  I have added  and verified 
the wsdl file is valid.

Please let me know if this solves your null pointer exception.  Thanks.

Fuhwei Lwo

> ImportSDOLoader: DataTypeImpl not found in 
> XSDEcoreBuilder.typeToTypeObjectMap causes NPE (surfaced as 
> IllegalArgumentException)
> 
>
> Key: TUSCANY-676
> URL: http://issues.apache.org/jira/browse/TUSCANY-676
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Implementation
>Reporter: Chris Wall
> Attachments: medrec.zip, MedRecWebServices.wsdl, tuscany-676.patch, 
> xsdecorebuilder_npe.zip
>
>
> During SDO import of WSDL, elements of the following complex type are not 
> found when validated against available SDO datatypes within the XSD layer 
> (XSDEcoreBuilder).  Downstream this causes an NPE.  It could be that the 
> comparison between the type and the key is not properly implemented.  See the 
> attached zip containing debug screenshots.
>  targetNamespace="java:com.bea.proto.webservice" xmlns:xs=" 
> http://www.w3.org/2001/XMLSchema";>
>   
> 
>   
>type="xs:dateTime"/>
>type="xs:string"/>
>type="xs:string"/>
>type="xs:string"/>
>type="xs:string"/>
>type="xs:string"/>
>   
> 
>   
> 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

Re: Registry proposal, was: Delivery Status Notification (Failure)

[Jeremy Boynes]

I don't think we need "Provider" at all.
--
Jeremy

On Aug 30, 2006, at 9:59 AM, Jim Marino wrote:

I had one additional comment: is there a reason we have to use the  
".INSTANCE" approach to locating the default Provider?


Jim

On Aug 30, 2006, at 9:39 AM, Yang ZHONG wrote:

Raymond guessed right that it's an API/SPI review, so no impl/ 
tests attached

yet although I have some impl already.

Ant guessed right too that I forgot to grant license, I must be  
not thinking

straight working late :-)
I don't see any link to post-grant, I'll remember to do that for  
following

attachments. Thank Ant.

There's "neither* EMF *nor* Eclipse dependency. impl/EMF and impl/ 
Eclipse

are just subproject targeting certain usage.
Please take a look at ReadMe.txt for more details, it also have  
info to find

Class Diagram and others.

I agree with Jeremy that strongly-typed Maps/interfaces are sometimes
preferred.
Actually, generalization and extensibility is exactly the selling  
point of

this generic registry.
Tailoring can be done based on the framework/infrastructure/ 
fundation (as

Raymond commented).
There're at least two ways to provide strong interfaces over this  
registry.

2-1. Delegating
new StrongInterface()
{
 public MySymbol getMySymbol (QName qName)
 {
   return mySymbolSpace.resolve( qName);
 }
}
2-2. Extending
 class StrongInterfaceImpl extends SymbolSpaceImpl implement
StrongInterface

Thank everyone for all comments.

On 8/30/06, Raymond Feng <[EMAIL PROTECTED]> wrote:


Hi,

Please see my comments in line.

Thanks,
Raymond

- Original Message -
From: "Jeremy Boynes" <[EMAIL PROTECTED]>
To: 
Sent: Wednesday, August 30, 2006 8:19 AM
Subject: Registry proposal, was: Delivery Status Notification  
(Failure)



>I might be missing something as well but I didn't see any code
under  impl
>at all

I guess it's for the API/SPI review first.

>
> I'm also with Ant in thinking we should not have a dependency  
on EMF.

>

From the javadoc, I don't see the EMF dependencies.

> I'd also add that I found it difficult to grok the
relationships  between
> all the interfaces and inner-interfaces and how the behaviour   
would
> integrate with Map semantics - for example, how does this   
differ from

> just using strongly-typed Maps?

I agree. If the interface is designed for public API/SPI, it  
should be

first-class interface instead of being inner.

I'm also seeing a lot of naming conflicts among API and SPI
interfaces/classes/parameterized types. This seems to be very  
problematic

to
me. When we run out of names, it means to me we don't model it  
correctly.


A class diagram would be of great help for us.

>
> I'm also not convinced that throwing everything (all types of
stuff)  into
> one central registry model is a good way to go. I can see a  
lot  of
> benefit in having more specialized interfaces tailored for  
each  type of

> stuff.

I guess we can reuse the same infrastrcture backed by the generic  
registry
but provide more specialized interfaces on top of it. And we can  
also

choose
to have separate instances of registries for specific domains.

>
> --
> Jeremy
>
> On Aug 30, 2006, at 4:10 AM, ant elder wrote:
>
>> Having this attached to a JIRA is fine, thats preferred over  
sending

>> attachments to the dev list.
>>
>> Thanks for all this, I've only just started looking but it  
looks very

>> comprehensive, a lot more than I was expecting 8-). I've a
few  questions
>> so
>> far. Firstly you didn't click the button granting license of  
the  code

to
>> the
>> ASF, was that an oversight? The readme talks about some test   
examples

>> and
>> samples showing how to use the registry but the test folders
don't  seem
>> to
>> be included in the zip? From the brief look it wasn't clear to  
me  if

the
>> registry will require EMF, hopefully it doesn't?
>>
>> Thanks,
>>
>>   ...ant
>>
>> On 8/30/06, Yang ZHONG <[EMAIL PROTECTED]> wrote:
>>>
>>> Neither tuscany-dev nor infra takes my email with attachment,  
so I've

>>> attached file for review into
>>> http://issues.apache.org/jira/browse/TUSCANY-677
>>>
>>> Sorry for the inconvenience and thanks for any comment.
>>>
>>> On 8/30/06, Mail Delivery Subsystem [EMAIL PROTECTED]>

>>> wrote:
>>> >
>>> > This is an automatically generated Delivery Status  
Notification

>>> >
>>> > Delivery to the following recipient failed permanently:
>>> >
>>> > [EMAIL PROTECTED]
>>> >
>>> > Technical details of permanent failure:
>>> > PERM_FAILURE: SMTP Error (state 12): 552 Message rejected  
as it

>>> is spam
>>> > (body)
>>> >
>>> >   - Original message -
>>> >
>>> > Received: by 10.35.31.14 with SMTP id i14mr634348pyj;
>>> >Wed, 30 Aug 2006 03:06:43 -0700 (PDT)
>>> > Received: by 10.35.103.13 with HTTP; Wed, 30 Aug 2006 03:06:41
>>> -0700
>>> (PDT)
>>> > Message-ID:
>>> <[EMAIL PROTECTED]
>>> >
>>> > Date: Wed, 30 Aug 2006 03:06:41 -0700
>>> > From: "Yang ZHONG" <[EMAIL PROTECTED]>
>>> > To: tuscany-dev@ws.apache.org
>>> > 

Re: REST bindings for Tuscany SCA runtime

[Jean-Sebastien Delfino]

Oisin Hurley wrote:



What do you think about the following approach:
a) If you put no annotations in your code then you have to stick to 
the fixed pattern with fixed method names, and you write the side 
SCDL file that turns your code into a component and publishes the 
REST endpoint.


b) If you want more flexibility to map state changes to nicer method 
names then you use annotations as your were proposing earlier in this 
thread. The annotations also allow you to completely avoid writing 
SCDL and specify the details of the binding like the base URI for the 
resources...


Thoughts?


These sound like good approaches to me - the one thing
that I'm scratching my head about a bit is the create-resource
and delete-resource support. The read-resource and update-resource
ops are fine, because we have a resource (i.e. the thing that
has just been coded). What's implicit here, though, is that
there is always a fixed set of resources - the ones that you
have just 'deployed'. So the create/delete ops can never be
used because things are just set up that way.

BTW, this is probably ok and it does match nicely with the
accepted admin practice of disabling PUT and DEL in real
webservers (as observed previously in this thread).

I would be happy enough to leave off the create/delete support
for the immediate future :)



Oisin,

I am not sure I understand the issue with create/delete (except if PUT 
and DEL are disabled). Posting/putting to a URL that doesn't exist yet 
to create that resource can be troubling. Is that the issue? Are you 
looking for some kind of factory service pattern to create resources?


Or am I completely mis-understanding the issue you're describing here? :)


You have .put and .get in the client example, maybe the .post should be
something like

customers.post(uri, state-diff)


Ah! interesting, I never thought about that before, looks like there 
could be a pretty good fit with SDO with the following:


customers.post(uri, state-diff-in-an-SDO-change-summary-graph) ...

This would be an interesting usage of SDO change summaries IMO, 
obviously just as an option as you should be able to format your 
state diff in any format you want as long as it's understood by your 
application.


What do you think?


This sounds like a nifty fit for sure. But now I have to
go and read that SDO spec in more detail, because I know
too little about it :)

I like the general approach of going down the diff route
because if you do it right then you can undo/redo changes
to the data, which is neat feature, provided you are willing
to store all of the diffs in a timeline.

I'll go off and read that spec again. I just love reading
specs ;)



I don't think that we would mandate the use of SDO change summaries to 
implement this, support for diffs cannot be SDO specific (IMO the 
application developer decides what a diff looks like and what he does 
with it) but we would describe how application code could use SDO to 
simply implement that approach. Does that make sense?



Are we close enough to condense a summary on the topic of
REST and SCA? This would be good white paper material BTW.



Yes I think it would be great if we could condense this and post it to 
our Wiki maybe.



cheers
--oh


-
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: Registry proposal, was: Delivery Status Notification (Failure)

[Jim Marino]

I had one additional comment: is there a reason we have to use the  
".INSTANCE" approach to locating the default Provider?


Jim

On Aug 30, 2006, at 9:39 AM, Yang ZHONG wrote:

Raymond guessed right that it's an API/SPI review, so no impl/tests  
attached

yet although I have some impl already.

Ant guessed right too that I forgot to grant license, I must be not  
thinking

straight working late :-)
I don't see any link to post-grant, I'll remember to do that for  
following

attachments. Thank Ant.

There's "neither* EMF *nor* Eclipse dependency. impl/EMF and impl/ 
Eclipse

are just subproject targeting certain usage.
Please take a look at ReadMe.txt for more details, it also have  
info to find

Class Diagram and others.

I agree with Jeremy that strongly-typed Maps/interfaces are sometimes
preferred.
Actually, generalization and extensibility is exactly the selling  
point of

this generic registry.
Tailoring can be done based on the framework/infrastructure/ 
fundation (as

Raymond commented).
There're at least two ways to provide strong interfaces over this  
registry.

2-1. Delegating
new StrongInterface()
{
 public MySymbol getMySymbol (QName qName)
 {
   return mySymbolSpace.resolve( qName);
 }
}
2-2. Extending
 class StrongInterfaceImpl extends SymbolSpaceImpl implement
StrongInterface

Thank everyone for all comments.

On 8/30/06, Raymond Feng <[EMAIL PROTECTED]> wrote:


Hi,

Please see my comments in line.

Thanks,
Raymond

- Original Message -
From: "Jeremy Boynes" <[EMAIL PROTECTED]>
To: 
Sent: Wednesday, August 30, 2006 8:19 AM
Subject: Registry proposal, was: Delivery Status Notification  
(Failure)



>I might be missing something as well but I didn't see any code
under  impl
>at all

I guess it's for the API/SPI review first.

>
> I'm also with Ant in thinking we should not have a dependency on  
EMF.

>

From the javadoc, I don't see the EMF dependencies.

> I'd also add that I found it difficult to grok the
relationships  between
> all the interfaces and inner-interfaces and how the behaviour   
would
> integrate with Map semantics - for example, how does this   
differ from

> just using strongly-typed Maps?

I agree. If the interface is designed for public API/SPI, it  
should be

first-class interface instead of being inner.

I'm also seeing a lot of naming conflicts among API and SPI
interfaces/classes/parameterized types. This seems to be very  
problematic

to
me. When we run out of names, it means to me we don't model it  
correctly.


A class diagram would be of great help for us.

>
> I'm also not convinced that throwing everything (all types of
stuff)  into
> one central registry model is a good way to go. I can see a lot  of
> benefit in having more specialized interfaces tailored for each   
type of

> stuff.

I guess we can reuse the same infrastrcture backed by the generic  
registry

but provide more specialized interfaces on top of it. And we can also
choose
to have separate instances of registries for specific domains.

>
> --
> Jeremy
>
> On Aug 30, 2006, at 4:10 AM, ant elder wrote:
>
>> Having this attached to a JIRA is fine, thats preferred over  
sending

>> attachments to the dev list.
>>
>> Thanks for all this, I've only just started looking but it  
looks very

>> comprehensive, a lot more than I was expecting 8-). I've a
few  questions
>> so
>> far. Firstly you didn't click the button granting license of  
the  code

to
>> the
>> ASF, was that an oversight? The readme talks about some test   
examples

>> and
>> samples showing how to use the registry but the test folders
don't  seem
>> to
>> be included in the zip? From the brief look it wasn't clear to  
me  if

the
>> registry will require EMF, hopefully it doesn't?
>>
>> Thanks,
>>
>>   ...ant
>>
>> On 8/30/06, Yang ZHONG <[EMAIL PROTECTED]> wrote:
>>>
>>> Neither tuscany-dev nor infra takes my email with attachment,  
so I've

>>> attached file for review into
>>> http://issues.apache.org/jira/browse/TUSCANY-677
>>>
>>> Sorry for the inconvenience and thanks for any comment.
>>>
>>> On 8/30/06, Mail Delivery Subsystem [EMAIL PROTECTED]>

>>> wrote:
>>> >
>>> > This is an automatically generated Delivery Status Notification
>>> >
>>> > Delivery to the following recipient failed permanently:
>>> >
>>> > [EMAIL PROTECTED]
>>> >
>>> > Technical details of permanent failure:
>>> > PERM_FAILURE: SMTP Error (state 12): 552 Message rejected as it
>>> is spam
>>> > (body)
>>> >
>>> >   - Original message -
>>> >
>>> > Received: by 10.35.31.14 with SMTP id i14mr634348pyj;
>>> >Wed, 30 Aug 2006 03:06:43 -0700 (PDT)
>>> > Received: by 10.35.103.13 with HTTP; Wed, 30 Aug 2006 03:06:41
>>> -0700
>>> (PDT)
>>> > Message-ID:
>>> <[EMAIL PROTECTED]
>>> >
>>> > Date: Wed, 30 Aug 2006 03:06:41 -0700
>>> > From: "Yang ZHONG" <[EMAIL PROTECTED]>
>>> > To: tuscany-dev@ws.apache.org
>>> > Subject: Re: Auto discovering WSDL
>>> > Cc: [EMAIL PROTECTED]
>>> > In-Reply-To:
>>> <[EMAIL PROTECTED]
>>> >

[jira] Updated: (TUSCANY-667) New website ready to publish

[David Wheeler (JIRA)]

 [ http://issues.apache.org/jira/browse/TUSCANY-667?page=all ]

David Wheeler updated TUSCANY-667:
--

Attachment: site(8-30-06).zip

Fixed some links that still pointed to index.php
removed index.php from the archive.

> New website ready to publish
> 
>
> Key: TUSCANY-667
> URL: http://issues.apache.org/jira/browse/TUSCANY-667
> Project: Tuscany
>  Issue Type: New Feature
>  Components: Website
>Reporter: David Wheeler
> Attachments: site(8-29-06).zip, site(8-30-06).zip, Tuscany Site.zip
>
>
> The new website is ready to go live. There are still a few pages TBD, but all 
> the content that is currently up is included in the new site.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] Commented: (TUSCANY-667) New website ready to publish

[David Wheeler (JIRA)]

[ 
http://issues.apache.org/jira/browse/TUSCANY-667?page=comments#action_12431621 
] 

David Wheeler commented on TUSCANY-667:
---

Posted by Rick (cr22rc)
"It looks to me there are many links to "index.php?page" is this right?
There are changes scattered about with respect to links that don't seem right
Example site-author\get-involved.xml FAQ link
  Contribute to the FAQ or to
  FAQ or to
Also links changed from  href="./java-projects.html"  to href="java-projects"
for the anakia processor it seems to make a difference.
The zip file contains index.php is this needed now?"

index.php is no longer needed and was only included in the zip for reference.
All the links that go to "index.php?page=pageTitle" should have been changed to 
"./pageTitle.html".  I went back and checked again, looks like I missed a 
couple links in news.xml and java-projects.xml

I am posting a version without index.php and with the last of the links fixed.

> New website ready to publish
> 
>
> Key: TUSCANY-667
> URL: http://issues.apache.org/jira/browse/TUSCANY-667
> Project: Tuscany
>  Issue Type: New Feature
>  Components: Website
>Reporter: David Wheeler
> Attachments: site(8-29-06).zip, Tuscany Site.zip
>
>
> The new website is ready to go live. There are still a few pages TBD, but all 
> the content that is currently up is included in the new site.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

Re: Registry proposal, was: Delivery Status Notification (Failure)

[Yang ZHONG]

Raymond guessed right that it's an API/SPI review, so no impl/tests attached
yet although I have some impl already.

Ant guessed right too that I forgot to grant license, I must be not thinking
straight working late :-)
I don't see any link to post-grant, I'll remember to do that for following
attachments. Thank Ant.

There's "neither* EMF *nor* Eclipse dependency. impl/EMF and impl/Eclipse
are just subproject targeting certain usage.
Please take a look at ReadMe.txt for more details, it also have info to find
Class Diagram and others.

I agree with Jeremy that strongly-typed Maps/interfaces are sometimes
preferred.
Actually, generalization and extensibility is exactly the selling point of
this generic registry.
Tailoring can be done based on the framework/infrastructure/fundation (as
Raymond commented).
There're at least two ways to provide strong interfaces over this registry.
2-1. Delegating
new StrongInterface()
{
 public MySymbol getMySymbol (QName qName)
 {
   return mySymbolSpace.resolve( qName);
 }
}
2-2. Extending
 class StrongInterfaceImpl extends SymbolSpaceImpl implement
StrongInterface

Thank everyone for all comments.

On 8/30/06, Raymond Feng <[EMAIL PROTECTED]> wrote:


Hi,

Please see my comments in line.

Thanks,
Raymond

- Original Message -
From: "Jeremy Boynes" <[EMAIL PROTECTED]>
To: 
Sent: Wednesday, August 30, 2006 8:19 AM
Subject: Registry proposal, was: Delivery Status Notification (Failure)


>I might be missing something as well but I didn't see any code
under  impl
>at all

I guess it's for the API/SPI review first.

>
> I'm also with Ant in thinking we should not have a dependency on EMF.
>

From the javadoc, I don't see the EMF dependencies.

> I'd also add that I found it difficult to grok the
relationships  between
> all the interfaces and inner-interfaces and how the behaviour  would
> integrate with Map semantics - for example, how does this  differ from
> just using strongly-typed Maps?

I agree. If the interface is designed for public API/SPI, it should be
first-class interface instead of being inner.

I'm also seeing a lot of naming conflicts among API and SPI
interfaces/classes/parameterized types. This seems to be very problematic
to
me. When we run out of names, it means to me we don't model it correctly.

A class diagram would be of great help for us.

>
> I'm also not convinced that throwing everything (all types of
stuff)  into
> one central registry model is a good way to go. I can see a lot  of
> benefit in having more specialized interfaces tailored for each  type of
> stuff.

I guess we can reuse the same infrastrcture backed by the generic registry
but provide more specialized interfaces on top of it. And we can also
choose
to have separate instances of registries for specific domains.

>
> --
> Jeremy
>
> On Aug 30, 2006, at 4:10 AM, ant elder wrote:
>
>> Having this attached to a JIRA is fine, thats preferred over sending
>> attachments to the dev list.
>>
>> Thanks for all this, I've only just started looking but it looks very
>> comprehensive, a lot more than I was expecting 8-). I've a
few  questions
>> so
>> far. Firstly you didn't click the button granting license of the  code
to
>> the
>> ASF, was that an oversight? The readme talks about some test  examples
>> and
>> samples showing how to use the registry but the test folders
don't  seem
>> to
>> be included in the zip? From the brief look it wasn't clear to me  if
the
>> registry will require EMF, hopefully it doesn't?
>>
>> Thanks,
>>
>>   ...ant
>>
>> On 8/30/06, Yang ZHONG <[EMAIL PROTECTED]> wrote:
>>>
>>> Neither tuscany-dev nor infra takes my email with attachment, so I've
>>> attached file for review into
>>> http://issues.apache.org/jira/browse/TUSCANY-677
>>>
>>> Sorry for the inconvenience and thanks for any comment.
>>>
>>> On 8/30/06, Mail Delivery Subsystem <[EMAIL PROTECTED]>
>>> wrote:
>>> >
>>> > This is an automatically generated Delivery Status Notification
>>> >
>>> > Delivery to the following recipient failed permanently:
>>> >
>>> > [EMAIL PROTECTED]
>>> >
>>> > Technical details of permanent failure:
>>> > PERM_FAILURE: SMTP Error (state 12): 552 Message rejected as it
>>> is spam
>>> > (body)
>>> >
>>> >   - Original message -
>>> >
>>> > Received: by 10.35.31.14 with SMTP id i14mr634348pyj;
>>> >Wed, 30 Aug 2006 03:06:43 -0700 (PDT)
>>> > Received: by 10.35.103.13 with HTTP; Wed, 30 Aug 2006 03:06:41
>>> -0700
>>> (PDT)
>>> > Message-ID:
>>> <[EMAIL PROTECTED]
>>> >
>>> > Date: Wed, 30 Aug 2006 03:06:41 -0700
>>> > From: "Yang ZHONG" <[EMAIL PROTECTED]>
>>> > To: tuscany-dev@ws.apache.org
>>> > Subject: Re: Auto discovering WSDL
>>> > Cc: [EMAIL PROTECTED]
>>> > In-Reply-To:
>>> <[EMAIL PROTECTED]
>>> >
>>> > MIME-Version: 1.0
>>> > Content-Type: multipart/mixed;
>>> >boundary="=_Part_28704_31437365.1156932401933"
>>> > References: <
>>> > [EMAIL PROTECTED]
>>> ems2.IONAGLOBAL.COM>
>>> >
>>> <[EMAIL PROTECTED]>
>>> >
>>> <[EMAIL PROT

Re: Registry proposal, was: Delivery Status Notification (Failure)

[Raymond Feng]

Hi,

Please see my comments in line.

Thanks,
Raymond

- Original Message - 
From: "Jeremy Boynes" <[EMAIL PROTECTED]>

To: 
Sent: Wednesday, August 30, 2006 8:19 AM
Subject: Registry proposal, was: Delivery Status Notification (Failure)


I might be missing something as well but I didn't see any code under  impl 
at all


I guess it's for the API/SPI review first.



I'm also with Ant in thinking we should not have a dependency on EMF.




From the javadoc, I don't see the EMF dependencies.


I'd also add that I found it difficult to grok the relationships  between 
all the interfaces and inner-interfaces and how the behaviour  would 
integrate with Map semantics - for example, how does this  differ from 
just using strongly-typed Maps?


I agree. If the interface is designed for public API/SPI, it should be 
first-class interface instead of being inner.


I'm also seeing a lot of naming conflicts among API and SPI 
interfaces/classes/parameterized types. This seems to be very problematic to 
me. When we run out of names, it means to me we don't model it correctly.


A class diagram would be of great help for us.



I'm also not convinced that throwing everything (all types of stuff)  into 
one central registry model is a good way to go. I can see a lot  of 
benefit in having more specialized interfaces tailored for each  type of 
stuff.


I guess we can reuse the same infrastrcture backed by the generic registry 
but provide more specialized interfaces on top of it. And we can also choose 
to have separate instances of registries for specific domains.




--
Jeremy

On Aug 30, 2006, at 4:10 AM, ant elder wrote:


Having this attached to a JIRA is fine, thats preferred over sending
attachments to the dev list.

Thanks for all this, I've only just started looking but it looks very
comprehensive, a lot more than I was expecting 8-). I've a few  questions 
so
far. Firstly you didn't click the button granting license of the  code to 
the
ASF, was that an oversight? The readme talks about some test  examples 
and
samples showing how to use the registry but the test folders don't  seem 
to

be included in the zip? From the brief look it wasn't clear to me  if the
registry will require EMF, hopefully it doesn't?

Thanks,

  ...ant

On 8/30/06, Yang ZHONG <[EMAIL PROTECTED]> wrote:


Neither tuscany-dev nor infra takes my email with attachment, so I've
attached file for review into
http://issues.apache.org/jira/browse/TUSCANY-677

Sorry for the inconvenience and thanks for any comment.

On 8/30/06, Mail Delivery Subsystem <[EMAIL PROTECTED]> 
wrote:

>
> This is an automatically generated Delivery Status Notification
>
> Delivery to the following recipient failed permanently:
>
> [EMAIL PROTECTED]
>
> Technical details of permanent failure:
> PERM_FAILURE: SMTP Error (state 12): 552 Message rejected as it
is spam
> (body)
>
>   - Original message -
>
> Received: by 10.35.31.14 with SMTP id i14mr634348pyj;
>Wed, 30 Aug 2006 03:06:43 -0700 (PDT)
> Received: by 10.35.103.13 with HTTP; Wed, 30 Aug 2006 03:06:41
-0700
(PDT)
> Message-ID:
<[EMAIL PROTECTED]
>
> Date: Wed, 30 Aug 2006 03:06:41 -0700
> From: "Yang ZHONG" <[EMAIL PROTECTED]>
> To: tuscany-dev@ws.apache.org
> Subject: Re: Auto discovering WSDL
> Cc: [EMAIL PROTECTED]
> In-Reply-To:
<[EMAIL PROTECTED]
>
> MIME-Version: 1.0
> Content-Type: multipart/mixed;
>boundary="=_Part_28704_31437365.1156932401933"
> References: <
> [EMAIL PROTECTED]
ems2.IONAGLOBAL.COM>
>
<[EMAIL PROTECTED]>
>
<[EMAIL PROTECTED]>
>
<[EMAIL PROTECTED]>
>
<[EMAIL PROTECTED]>
>
> --=_Part_28704_31437365.1156932401933
> Content-Type: multipart/alternative;
>boundary="=_Part_28705_19724073.1156932401933"
>
> --=_Part_28705_19724073.1156932401933
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
>
> Could you please review the registry API and SPI?
>
>   - Message truncated -
>
>


--

Yang ZHONG





-
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: Process and content for next release?

[Hawkins, Joel]

Thanks - that gives me some dates to shoot for. 

-Original Message-
From: Jeremy Boynes [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, August 30, 2006 11:48 AM
To: tuscany-dev@ws.apache.org
Subject: Re: Process and content for next release?

Basically, when it's done :-) Having said that, see below for the  
estimates I would make for the separate stages. If they are anywhere  
near accurate then I think we're looking towards the end of September  
(which seems like a good time just before ApacheCon).

By publish, I mean having a stable but unreleased artifact in the  
snapshot maven repo.
--
Jeremy

On Aug 30, 2006, at 8:23 AM, Hawkins, Joel wrote:

> Jeremy, when is your target date for this next release? I hope to get
> back to the OSGi binding/hosting code within the next week and I'd
> really like to try and get something into the release.
>

... snip ...

>>
>> 1) Specs (sdo-api, sca-api, commonj)
>>These should be stable now as the specifications have been
>> published.

I think these are ready and we can publish a stable version now.

>> 2) SCA Core (spi, core, hostutil, test, plus apis once that
>> refactor is done)
>>Features I would like to see complete before we consider this
>> stable are:
>>   Class loading changes
>>   Integration of databinding framework
>>   Support for async callbacks
>>   Support for complex properties
>>   Transitive dependency support

I hope that we can get this wrapped and published by 9/11

>> 3) Baseline extensions - ones we think are essential for users
>>idl.wsdl9/11
>>binding.axis9/18 (depends on Axis 1.1 release)
>>binding.celtix  9/18
>>binding.rmi 9/11
>>databinding.axiom   9/11
>>databinding.sdo 9/11 (depends on a SDO release)
>>databinding.jaxb9/11
>>container.javascript
>>container.spring

I am assuming the axiom, sdo and jaxb databindings sync with the  
framework as we need something there to test it out.
I don't have a good feeling for how long it will take to get the  
containers working.

>> 4) Optional extensions - nice to have but which may not be ready to
>> bundle
>>binding.jsonrpc
>>binding.osgi
>>databinding.xmlbeans
>>databinding.castor
>>container.groovy
>>
>> 5) Host distributions - host environments that each form the basis
>> for each bundle
>>Standalone (with axis, celtix, rmi, spring)
>>Web-app (with axis, celtix, rmi, json, spring, javascript)

Based on Jim's feedback I don't think we would be doing a Web-app  
distribution; instead there would be a web-app maven plugin to  
package a war with a suitably configured war inside it. See 7) for that.

>> 6) Sample applications
>>Technology sample framework (subject of another mail)
>>BigBank application if ready

 7) Tools
Web-app maven plugin   9/4


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

The contents of this e-mail are intended for the named addressee only. It 
contains information that may be confidential. Unless you are the named 
addressee or an authorized designee, you may not copy or use it, or disclose it 
to anyone else. If you received it in error please notify us immediately and 
then destroy it. 

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

Re: Process and content for next release?

[Jeremy Boynes]

Basically, when it's done :-) Having said that, see below for the  
estimates I would make for the separate stages. If they are anywhere  
near accurate then I think we're looking towards the end of September  
(which seems like a good time just before ApacheCon).


By publish, I mean having a stable but unreleased artifact in the  
snapshot maven repo.

--
Jeremy

On Aug 30, 2006, at 8:23 AM, Hawkins, Joel wrote:


Jeremy, when is your target date for this next release? I hope to get
back to the OSGi binding/hosting code within the next week and I'd
really like to try and get something into the release.



... snip ...



1) Specs (sdo-api, sca-api, commonj)
   These should be stable now as the specifications have been
published.


I think these are ready and we can publish a stable version now.


2) SCA Core (spi, core, hostutil, test, plus apis once that
refactor is done)
   Features I would like to see complete before we consider this
stable are:
  Class loading changes
  Integration of databinding framework
  Support for async callbacks
  Support for complex properties
  Transitive dependency support


I hope that we can get this wrapped and published by 9/11


3) Baseline extensions - ones we think are essential for users
   idl.wsdl9/11
   binding.axis9/18 (depends on Axis 1.1 release)
   binding.celtix  9/18
   binding.rmi 9/11
   databinding.axiom   9/11
   databinding.sdo 9/11 (depends on a SDO release)
   databinding.jaxb9/11
   container.javascript
   container.spring


I am assuming the axiom, sdo and jaxb databindings sync with the  
framework as we need something there to test it out.
I don't have a good feeling for how long it will take to get the  
containers working.



4) Optional extensions - nice to have but which may not be ready to
bundle
   binding.jsonrpc
   binding.osgi
   databinding.xmlbeans
   databinding.castor
   container.groovy

5) Host distributions - host environments that each form the basis
for each bundle
   Standalone (with axis, celtix, rmi, spring)
   Web-app (with axis, celtix, rmi, json, spring, javascript)


Based on Jim's feedback I don't think we would be doing a Web-app  
distribution; instead there would be a web-app maven plugin to  
package a war with a suitably configured war inside it. See 7) for that.



6) Sample applications
   Technology sample framework (subject of another mail)
   BigBank application if ready


7) Tools
   Web-app maven plugin   9/4


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

RE: Process and content for next release?

[Hawkins, Joel]

Jeremy, when is your target date for this next release? I hope to get
back to the OSGi binding/hosting code within the next week and I'd
really like to try and get something into the release.

Thanks,
Joel

-Original Message-
From: Jeremy Boynes [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, August 30, 2006 11:04 AM
To: tuscany-dev@ws.apache.org
Subject: Re: Process and content for next release?

We have had a rush of build problems recently which have stopped  
people from being able to contribute effectively. Some of those have  
come from the size of the build leading to Jim's proposal to go ahead  
with the build refactors we have been talking about. For those to  
work we need some way to publish unstable artifacts and that meshes  
nicely with this release thread.

There have been no comments on this thread since the original burst  
so I plan to start pulling together a release based on the approach  
described here (factoring in those comments).
--
Jeremy

On Aug 16, 2006, at 1:58 PM, Jeremy Boynes wrote:

> Our discussions on modularity have gone quiet and Kelvin and  
> Luciano have started to build distributions for SDO and DAS. I'd  
> like to open the discussion up about what should be in our next  
> release, how we should approach it and when we think it might be  
> ready. As the person opening this thread, I guess I'm also  
> volunteering to be Release Manager unless someone else would prefer  
> to do it :-)
>
> One of the things we're achieved with the modularization is the  
> ability to decompose what we have into separately releasable  
> modules - we don't have to pull everything together at the same  
> time. We also have the ability to release artifacts individually  
> through various maven repositories, publishing specific jars rather  
> than than entire distribution.
>
> This allows us to structure a release differently from what we did  
> in M1. Instead of publishing one bundle and then pulling libraries  
> from it to distribute through Maven, I suggest we focus on the  
> individual components then group them together into bundled  
> distributions.
>
> Taking SDO as an example, this would mean that we would decide at  
> some point that we wanted to release the sdo-impl library (that  
> being the executable part of SDO). We would cut and vote on a  
> version of that jar and that could then be published through Maven.  
> We could also bundle that jar in a distribution containing  
> dependencies (e.g. EMF), samples, documentation, ... The two don't  
> need to be in permanent lock-step (although alignment is good) -  
> for example, we could release an updated impl jar with some  
> bugfixes without respinning the bundle.
>
> SCA provides a much more complex picture as it contains not just  
> libraries but also host environments, multiple extensions,  
> potentially multiple extensions providing alternative  
> implementations of the same function (e.g. the axis and celtix  
> bindings). To handle this I think we should stage the release  
> process, stabilizing the core first, then whatever set of  
> extensions we define as a bundle, finally voting to release the  
> bundle. During the stabilization process we can published dated  
> unstable builds to the SNAPSHOT repo so that extensions can rely on  
> those rather than trunk all the time.
>
> So, having said all that, I would like to propose we start working  
> toward getting the next release out with the following stages:
>
> 1) Specs (sdo-api, sca-api, commonj)
>These should be stable now as the specifications have been  
> published.
>
> 2) SCA Core (spi, core, hostutil, test, plus apis once that  
> refactor is done)
>Features I would like to see complete before we consider this  
> stable are:
>   Class loading changes
>   Integration of databinding framework
>   Support for async callbacks
>   Support for complex properties
>   Transitive dependency support
>
> 3) Baseline extensions - ones we think are essential for users
>idl.wsdl
>binding.axis
>binding.celtix
>binding.rmi
>databinding.axiom
>databinding.sdo
>databinding.jaxb
>container.javascript
>container.spring
>
> 4) Optional extensions - nice to have but which may not be ready to  
> bundle
>binding.jsonrpc
>binding.osgi
>databinding.xmlbeans
>databinding.castor
>container.groovy
>
> 5) Host distributions - host environments that each form the basis  
> for each bundle
>Standalone (with axis, celtix, rmi, spring)
>Web-app (with axis, celtix, rmi, json, spring, javascript)
>
> 6) Sample applications
>Technology sample framework (subject of another mail)
>BigBank application if ready
>
> This is an initial strawman of how I think we can pull this  
> together. We can certainly move things around depending on what's  
> ready and what we think are essential modules. If this seems  
> reasonable I will transfer it to the wiki.
>
> Cheers
> --
> Jerem

Registry proposal, was: Delivery Status Notification (Failure)

[Jeremy Boynes]

I might be missing something as well but I didn't see any code under  
impl at all


I'm also with Ant in thinking we should not have a dependency on EMF.

I'd also add that I found it difficult to grok the relationships  
between all the interfaces and inner-interfaces and how the behaviour  
would integrate with Map semantics - for example, how does this  
differ from just using strongly-typed Maps?


I'm also not convinced that throwing everything (all types of stuff)  
into one central registry model is a good way to go. I can see a lot  
of benefit in having more specialized interfaces tailored for each  
type of stuff.


--
Jeremy

On Aug 30, 2006, at 4:10 AM, ant elder wrote:


Having this attached to a JIRA is fine, thats preferred over sending
attachments to the dev list.

Thanks for all this, I've only just started looking but it looks very
comprehensive, a lot more than I was expecting 8-). I've a few  
questions so
far. Firstly you didn't click the button granting license of the  
code to the
ASF, was that an oversight? The readme talks about some test  
examples and
samples showing how to use the registry but the test folders don't  
seem to
be included in the zip? From the brief look it wasn't clear to me  
if the

registry will require EMF, hopefully it doesn't?

Thanks,

  ...ant

On 8/30/06, Yang ZHONG <[EMAIL PROTECTED]> wrote:


Neither tuscany-dev nor infra takes my email with attachment, so I've
attached file for review into
http://issues.apache.org/jira/browse/TUSCANY-677

Sorry for the inconvenience and thanks for any comment.

On 8/30/06, Mail Delivery Subsystem <[EMAIL PROTECTED]>  
wrote:

>
> This is an automatically generated Delivery Status Notification
>
> Delivery to the following recipient failed permanently:
>
> [EMAIL PROTECTED]
>
> Technical details of permanent failure:
> PERM_FAILURE: SMTP Error (state 12): 552 Message rejected as it  
is spam

> (body)
>
>   - Original message -
>
> Received: by 10.35.31.14 with SMTP id i14mr634348pyj;
>Wed, 30 Aug 2006 03:06:43 -0700 (PDT)
> Received: by 10.35.103.13 with HTTP; Wed, 30 Aug 2006 03:06:41  
-0700

(PDT)
> Message-ID:  
<[EMAIL PROTECTED]

>
> Date: Wed, 30 Aug 2006 03:06:41 -0700
> From: "Yang ZHONG" <[EMAIL PROTECTED]>
> To: tuscany-dev@ws.apache.org
> Subject: Re: Auto discovering WSDL
> Cc: [EMAIL PROTECTED]
> In-Reply-To:  
<[EMAIL PROTECTED]

>
> MIME-Version: 1.0
> Content-Type: multipart/mixed;
>boundary="=_Part_28704_31437365.1156932401933"
> References: <
> [EMAIL PROTECTED] 
ems2.IONAGLOBAL.COM>
>  
<[EMAIL PROTECTED]>
>  
<[EMAIL PROTECTED]>
>  
<[EMAIL PROTECTED]>
>  
<[EMAIL PROTECTED]>

>
> --=_Part_28704_31437365.1156932401933
> Content-Type: multipart/alternative;
>boundary="=_Part_28705_19724073.1156932401933"
>
> --=_Part_28705_19724073.1156932401933
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
>
> Could you please review the registry API and SPI?
>
>   - Message truncated -
>
>


--

Yang ZHONG





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

Meaningful subjects, was: Delivery Status Notification (Failure)

[Jeremy Boynes]

Can people please make sure that messages have subjects that have  
some relationship to their content.

--
Jeremy

On Aug 30, 2006, at 3:20 AM, Yang ZHONG wrote:


Neither tuscany-dev nor infra takes my email with attachment, so I've
attached file for review into
http://issues.apache.org/jira/browse/TUSCANY-677

Sorry for the inconvenience and thanks for any comment.

On 8/30/06, Mail Delivery Subsystem <[EMAIL PROTECTED]>  
wrote:


This is an automatically generated Delivery Status Notification

Delivery to the following recipient failed permanently:

[EMAIL PROTECTED]

Technical details of permanent failure:
PERM_FAILURE: SMTP Error (state 12): 552 Message rejected as it is  
spam

(body)

  - Original message -

Received: by 10.35.31.14 with SMTP id i14mr634348pyj;
   Wed, 30 Aug 2006 03:06:43 -0700 (PDT)
Received: by 10.35.103.13 with HTTP; Wed, 30 Aug 2006 03:06:41  
-0700 (PDT)
Message-ID:  
<[EMAIL PROTECTED]>

Date: Wed, 30 Aug 2006 03:06:41 -0700
From: "Yang ZHONG" <[EMAIL PROTECTED]>
To: tuscany-dev@ws.apache.org
Subject: Re: Auto discovering WSDL
Cc: [EMAIL PROTECTED]
In-Reply-To:  
<[EMAIL PROTECTED]>

MIME-Version: 1.0
Content-Type: multipart/mixed;
   boundary="=_Part_28704_31437365.1156932401933"
References: <
[EMAIL PROTECTED] 
ems2.IONAGLOBAL.COM>

<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>

--=_Part_28704_31437365.1156932401933
Content-Type: multipart/alternative;
   boundary="=_Part_28705_19724073.1156932401933"

--=_Part_28705_19724073.1156932401933
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Could you please review the registry API and SPI?

  - Message truncated -





--

Yang ZHONG



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

Re: Process and content for next release?

[Jeremy Boynes]

We have had a rush of build problems recently which have stopped  
people from being able to contribute effectively. Some of those have  
come from the size of the build leading to Jim's proposal to go ahead  
with the build refactors we have been talking about. For those to  
work we need some way to publish unstable artifacts and that meshes  
nicely with this release thread.


There have been no comments on this thread since the original burst  
so I plan to start pulling together a release based on the approach  
described here (factoring in those comments).

--
Jeremy

On Aug 16, 2006, at 1:58 PM, Jeremy Boynes wrote:

Our discussions on modularity have gone quiet and Kelvin and  
Luciano have started to build distributions for SDO and DAS. I'd  
like to open the discussion up about what should be in our next  
release, how we should approach it and when we think it might be  
ready. As the person opening this thread, I guess I'm also  
volunteering to be Release Manager unless someone else would prefer  
to do it :-)


One of the things we're achieved with the modularization is the  
ability to decompose what we have into separately releasable  
modules - we don't have to pull everything together at the same  
time. We also have the ability to release artifacts individually  
through various maven repositories, publishing specific jars rather  
than than entire distribution.


This allows us to structure a release differently from what we did  
in M1. Instead of publishing one bundle and then pulling libraries  
from it to distribute through Maven, I suggest we focus on the  
individual components then group them together into bundled  
distributions.


Taking SDO as an example, this would mean that we would decide at  
some point that we wanted to release the sdo-impl library (that  
being the executable part of SDO). We would cut and vote on a  
version of that jar and that could then be published through Maven.  
We could also bundle that jar in a distribution containing  
dependencies (e.g. EMF), samples, documentation, ... The two don't  
need to be in permanent lock-step (although alignment is good) -  
for example, we could release an updated impl jar with some  
bugfixes without respinning the bundle.


SCA provides a much more complex picture as it contains not just  
libraries but also host environments, multiple extensions,  
potentially multiple extensions providing alternative  
implementations of the same function (e.g. the axis and celtix  
bindings). To handle this I think we should stage the release  
process, stabilizing the core first, then whatever set of  
extensions we define as a bundle, finally voting to release the  
bundle. During the stabilization process we can published dated  
unstable builds to the SNAPSHOT repo so that extensions can rely on  
those rather than trunk all the time.


So, having said all that, I would like to propose we start working  
toward getting the next release out with the following stages:


1) Specs (sdo-api, sca-api, commonj)
   These should be stable now as the specifications have been  
published.


2) SCA Core (spi, core, hostutil, test, plus apis once that  
refactor is done)
   Features I would like to see complete before we consider this  
stable are:

  Class loading changes
  Integration of databinding framework
  Support for async callbacks
  Support for complex properties
  Transitive dependency support

3) Baseline extensions - ones we think are essential for users
   idl.wsdl
   binding.axis
   binding.celtix
   binding.rmi
   databinding.axiom
   databinding.sdo
   databinding.jaxb
   container.javascript
   container.spring

4) Optional extensions - nice to have but which may not be ready to  
bundle

   binding.jsonrpc
   binding.osgi
   databinding.xmlbeans
   databinding.castor
   container.groovy

5) Host distributions - host environments that each form the basis  
for each bundle

   Standalone (with axis, celtix, rmi, spring)
   Web-app (with axis, celtix, rmi, json, spring, javascript)

6) Sample applications
   Technology sample framework (subject of another mail)
   BigBank application if ready

This is an initial strawman of how I think we can pull this  
together. We can certainly move things around depending on what's  
ready and what we think are essential modules. If this seems  
reasonable I will transfer it to the wiki.


Cheers
--
Jeremy

-
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: svn commit: r438000

[Jeremy Boynes]

One request I would have is to turn off automatic line wrapping in  
Eclipse. Having nicely wrapped at meaningful places (in a checkstyle  
compliwant way), I find it very frustrating that Eclipse rewraps  
those lines based on "first whitespace before the margin" losing my  
changes.


--
Jeremy

On Aug 30, 2006, at 7:54 AM, Jim Marino wrote:

Then we shuld make sure the two are aligned. I believe other than  
line length the two are aligned (no pun intended) since the IDEA  
template works fine for me. The only other mismatch brought up was  
the idents on cases, which was voted in favor of the current  
checkstyle. Maybe there are some other mismatches I missed. Could  
you please highlight them and we can discuss?


Jim

On Aug 30, 2006, at 1:37 AM, ant elder wrote:

From past discussions there may also be other mismatches and  
Raymond said

the line length was just one example of a difference. I think the IDE
template should be the authority, its the 21st century, we should  
be able to

use IDE code formatting.

  ...ant

On 8/30/06, Jim Marino <[EMAIL PROTECTED]> wrote:


I think it should be the checkstyle. The widest we ever went was 140
and we had a discussion on several occasions where some wanted it
smaller (e.g. 80), some larger, and some didn't care. 120 seems  
to be

a reasonable length. Do you want to update the Eclipse one?

Jim

On Aug 29, 2006, at 5:03 PM, Raymond Feng wrote:

> Hi,
>
> The rules from checkstlye are quite different than the IDE code
> formatter templates we were recommending. For example, the  
template

> for Eclipse sets the maximum characters per line to 150 while the
> checkstyle complains at 120.
>
> Which one should we follow? If it's the checkstyle, then we should
> update the IDE templates so that we are not confused.
>
> Thanks,
> Raymond
>
> - Original Message - From: "Jim Marino"
> <[EMAIL PROTECTED]>
> To: 
> Sent: Tuesday, August 29, 2006 1:12 AM
> Subject: Fwd: svn commit: r438000
>
>
>> Hi Raymond,
>>
>> Could you please make sure you format this code: mvn -
>> Psourcecheck?  It breaks Checkstyle.
>>
>> Thanks,
>> Jim
>>
>> Begin forwarded message:
>>
>>> From: [EMAIL PROTECTED]
>>> Date: August 29, 2006 1:00:16 AM PDT
>>> To: tuscany-commits@ws.apache.org
>>> Subject: svn commit: r438000 - in /incubator/tuscany/java/sca/
>>> core/ src: main/java/org/apache/tuscany/core/loader/
>>> ComponentLoader.java test/java/org/apache/tuscany/core/loader/
>>> ComponentLoaderTestCase.java
>>> Reply-To: tuscany-dev@ws.apache.org
>>>
>>> Author: rfeng
>>> Date: Tue Aug 29 01:00:16 2006
>>> New Revision: 438000
>>>
>>> URL: http://svn.apache.org/viewvc?rev=438000&view=rev
>>> Log:
>>> Make sure the StAX loading only ends upon 
>>>
>>> Modified:
>>> incubator/tuscany/java/sca/core/src/main/java/org/apache/
>>> tuscany/core/loader/ComponentLoader.java
>>> incubator/tuscany/java/sca/core/src/test/java/org/apache/
>>> tuscany/core/loader/ComponentLoaderTestCase.java
>>>
>>> Modified: incubator/tuscany/java/sca/core/src/main/java/org/
>>> apache/ tuscany/core/loader/ComponentLoader.java
>>> URL: http://svn.apache.org/viewvc/incubator/tuscany/java/sca/
>>> core/ src/main/java/org/apache/tuscany/core/loader/
>>> ComponentLoader.java? rev=438000&r1=437999&r2=438000&view=diff
>>>  


>>> == 
>>> --- incubator/tuscany/java/sca/core/src/main/java/org/apache/
>>> tuscany/core/loader/ComponentLoader.java (original)
>>> +++ incubator/tuscany/java/sca/core/src/main/java/org/apache/
>>> tuscany/core/loader/ComponentLoader.java Tue Aug 29 01:00:16  
2006

>>> @@ -113,7 +113,8 @@
>>>  reader.next();
>>>  break;
>>>  case END_ELEMENT:
>>> -return componentDefinition;
>>> +if(reader.getName().equals(COMPONENT))
>>> +return componentDefinition;
>>>  }
>>>  }
>>>  } catch (LoaderException e) {
>>>
>>> Modified: incubator/tuscany/java/sca/core/src/test/java/org/
>>> apache/ tuscany/core/loader/ComponentLoaderTestCase.java
>>> URL: http://svn.apache.org/viewvc/incubator/tuscany/java/sca/
>>> core/ src/test/java/org/apache/tuscany/core/loader/
>>> ComponentLoaderTestCase.java?
>>> rev=438000&r1=437999&r2=438000&view=diff
>>>  


>>> == 
>>> --- incubator/tuscany/java/sca/core/src/test/java/org/apache/
>>> tuscany/core/loader/ComponentLoaderTestCase.java (original)
>>> +++ incubator/tuscany/java/sca/core/src/test/java/org/apache/
>>> tuscany/core/loader/ComponentLoaderTestCase.java Tue Aug 29
>>> 01:00:16 2006
>>> @@ -57,7 +57,7 @@
>>>  private ComponentLoader loader;
>>>
>>>  public void testEmptyComponent() throws LoaderException,
>>> XMLStreamException {
>>> -mockReader.expects(once()).method("getName").will
>>> (returnValue(COMPONENT)

Re: svn commit: r438000

[Jim Marino]

Then we shuld make sure the two are aligned. I believe other than  
line length the two are aligned (no pun intended) since the IDEA  
template works fine for me. The only other mismatch brought up was  
the idents on cases, which was voted in favor of the current  
checkstyle. Maybe there are some other mismatches I missed. Could you  
please highlight them and we can discuss?


Jim

On Aug 30, 2006, at 1:37 AM, ant elder wrote:

From past discussions there may also be other mismatches and  
Raymond said

the line length was just one example of a difference. I think the IDE
template should be the authority, its the 21st century, we should  
be able to

use IDE code formatting.

  ...ant

On 8/30/06, Jim Marino <[EMAIL PROTECTED]> wrote:


I think it should be the checkstyle. The widest we ever went was 140
and we had a discussion on several occasions where some wanted it
smaller (e.g. 80), some larger, and some didn't care. 120 seems to be
a reasonable length. Do you want to update the Eclipse one?

Jim

On Aug 29, 2006, at 5:03 PM, Raymond Feng wrote:

> Hi,
>
> The rules from checkstlye are quite different than the IDE code
> formatter templates we were recommending. For example, the template
> for Eclipse sets the maximum characters per line to 150 while the
> checkstyle complains at 120.
>
> Which one should we follow? If it's the checkstyle, then we should
> update the IDE templates so that we are not confused.
>
> Thanks,
> Raymond
>
> - Original Message - From: "Jim Marino"
> <[EMAIL PROTECTED]>
> To: 
> Sent: Tuesday, August 29, 2006 1:12 AM
> Subject: Fwd: svn commit: r438000
>
>
>> Hi Raymond,
>>
>> Could you please make sure you format this code: mvn -
>> Psourcecheck?  It breaks Checkstyle.
>>
>> Thanks,
>> Jim
>>
>> Begin forwarded message:
>>
>>> From: [EMAIL PROTECTED]
>>> Date: August 29, 2006 1:00:16 AM PDT
>>> To: tuscany-commits@ws.apache.org
>>> Subject: svn commit: r438000 - in /incubator/tuscany/java/sca/
>>> core/ src: main/java/org/apache/tuscany/core/loader/
>>> ComponentLoader.java test/java/org/apache/tuscany/core/loader/
>>> ComponentLoaderTestCase.java
>>> Reply-To: tuscany-dev@ws.apache.org
>>>
>>> Author: rfeng
>>> Date: Tue Aug 29 01:00:16 2006
>>> New Revision: 438000
>>>
>>> URL: http://svn.apache.org/viewvc?rev=438000&view=rev
>>> Log:
>>> Make sure the StAX loading only ends upon 
>>>
>>> Modified:
>>> incubator/tuscany/java/sca/core/src/main/java/org/apache/
>>> tuscany/core/loader/ComponentLoader.java
>>> incubator/tuscany/java/sca/core/src/test/java/org/apache/
>>> tuscany/core/loader/ComponentLoaderTestCase.java
>>>
>>> Modified: incubator/tuscany/java/sca/core/src/main/java/org/
>>> apache/ tuscany/core/loader/ComponentLoader.java
>>> URL: http://svn.apache.org/viewvc/incubator/tuscany/java/sca/
>>> core/ src/main/java/org/apache/tuscany/core/loader/
>>> ComponentLoader.java? rev=438000&r1=437999&r2=438000&view=diff
>>>  


>>> == 
>>> --- incubator/tuscany/java/sca/core/src/main/java/org/apache/
>>> tuscany/core/loader/ComponentLoader.java (original)
>>> +++ incubator/tuscany/java/sca/core/src/main/java/org/apache/
>>> tuscany/core/loader/ComponentLoader.java Tue Aug 29 01:00:16 2006
>>> @@ -113,7 +113,8 @@
>>>  reader.next();
>>>  break;
>>>  case END_ELEMENT:
>>> -return componentDefinition;
>>> +if(reader.getName().equals(COMPONENT))
>>> +return componentDefinition;
>>>  }
>>>  }
>>>  } catch (LoaderException e) {
>>>
>>> Modified: incubator/tuscany/java/sca/core/src/test/java/org/
>>> apache/ tuscany/core/loader/ComponentLoaderTestCase.java
>>> URL: http://svn.apache.org/viewvc/incubator/tuscany/java/sca/
>>> core/ src/test/java/org/apache/tuscany/core/loader/
>>> ComponentLoaderTestCase.java?
>>> rev=438000&r1=437999&r2=438000&view=diff
>>>  


>>> == 
>>> --- incubator/tuscany/java/sca/core/src/test/java/org/apache/
>>> tuscany/core/loader/ComponentLoaderTestCase.java (original)
>>> +++ incubator/tuscany/java/sca/core/src/test/java/org/apache/
>>> tuscany/core/loader/ComponentLoaderTestCase.java Tue Aug 29
>>> 01:00:16 2006
>>> @@ -57,7 +57,7 @@
>>>  private ComponentLoader loader;
>>>
>>>  public void testEmptyComponent() throws LoaderException,
>>> XMLStreamException {
>>> -mockReader.expects(once()).method("getName").will
>>> (returnValue(COMPONENT));
>>> +mockReader.expects(atLeastOnce()).method("getName").will
>>> (returnValue(COMPONENT));
>>>  mockReader.expects(atLeastOnce()).method
>>> ("getAttributeValue")
>>>  .with(ANYTHING, ANYTHING)
>>>  .will(onConsecutiveCalls(returnValue(NAME),
>>> returnValue (null)));
>>> @@ -71,7 +71,7 @@
>>>  }
>>>
>>>   

[jira] Updated: (TUSCANY-474) substitutionGroup is serialized as parent name. Should be substitute name.

[Geoff Winn (JIRA)]

 [ http://issues.apache.org/jira/browse/TUSCANY-474?page=all ]

Geoff Winn updated TUSCANY-474:
---

Attachment: TUSCANY-474-recreate.patch

> substitutionGroup is serialized as parent name. Should be substitute name.
> --
>
> Key: TUSCANY-474
> URL: http://issues.apache.org/jira/browse/TUSCANY-474
> Project: Tuscany
>  Issue Type: Bug
>  Components: C++ SDO
>Affects Versions: Cpp-current
>Reporter: Pete Robbins
> Fix For: Cpp-current
>
> Attachments: TUSCANY-474-recreate.patch
>
>
> loading an instance document that uses substitution groups (such as 
> sca.module) then saving the document results in an invalid document.
> For example this snippet:
>   
>header="MyValueImpl.h"> implementation.cpp is a substitute for implementation. When serialised the 
> result is:
>   
>header="MyValueImpl.h">

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] Commented: (TUSCANY-474) substitutionGroup is serialized as parent name. Should be substitute name.

[Geoff Winn (JIRA)]

[ 
http://issues.apache.org/jira/browse/TUSCANY-474?page=comments#action_12431589 
] 

Geoff Winn commented on TUSCANY-474:



Looking at the example in the oriinal description it appears that the tag of 
the head element is being placed in the output document rather than the tag of 
the actual element from the input document. I created a small test to recreate 
this situation (see the attached patch file) and I think the problem is more 
serious. For example, given an input document like









where "substituteA" is a substitute for an element with tag "head", the result 
of serialising is


http://www.w3.org/2001/XMLSchema-instance";>



So not only is the head of the substitution group being written out rather than 
the actual element, but the contents of the element have been lost too.

Note to committers: The attached patch is not a fix. It just provides an easy 
way to recreate the problem. Please do not apply this, it is a convenience for 
anyone working on this issue.

> substitutionGroup is serialized as parent name. Should be substitute name.
> --
>
> Key: TUSCANY-474
> URL: http://issues.apache.org/jira/browse/TUSCANY-474
> Project: Tuscany
>  Issue Type: Bug
>  Components: C++ SDO
>Affects Versions: Cpp-current
>Reporter: Pete Robbins
> Fix For: Cpp-current
>
> Attachments: TUSCANY-474-recreate.patch
>
>
> loading an instance document that uses substitution groups (such as 
> sca.module) then saving the document results in an invalid document.
> For example this snippet:
>   
>header="MyValueImpl.h"> implementation.cpp is a substitute for implementation. When serialised the 
> result is:
>   
>header="MyValueImpl.h">

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

Re: [SDO for C++] Opinions Requested: Adopting stdcxx as C++ library

[Jean-Sebastien Delfino]

Simon Laws wrote:

On 8/30/06, Pete Robbins <[EMAIL PROTECTED]> wrote:


On 30/08/06, Andrew Borley <[EMAIL PROTECTED]> wrote:
>
> On 8/30/06, Geoffrey Winn <[EMAIL PROTECTED]> wrote:
> . Using the Apache stdcxx library instead would provide
>
> > us with a number of benefits
>
>
> Agreed. +1 for this.


yup!

The one difficulty is that once SDO links against the stdcxx library 
then

> > all users of SDO must also do so. I think this gives us two options
> >
> > 1. Just do it, and live with the consequences. In this case we will
(one
> > way
> > or another) pre-req stdcxx on all platforms, and all users of SDO 
for

> C++
> > will be required to use stdcxx as their C++ standard library.
> >
> > 2. Create a build time switch that chooses between whatever the
platform
> > offers (ie the current arrangement) and stdcxx. Presumably 
defaulting

to
> > the
> > current arrangement.
> >
> > I prefer option 2 but obviously it somewhat complicates our build
> process
> > and perhaps more seriously adds another complication to our test
cases.
> >
> > What does the team think?


My preference is also for option 2 as it gives our users more choice.
> However, we may find ourselves #ifdef-ing chunks of code out to get
around
> the aforementioned differences in libraries (see Pete's map problem on
> Windows yesterday..) which will make code less readable, etc. I think
> starting this with the SDO codebase is a good idea, as this is a
> relatively
> standalone set of code, and will give us a good idea what the 
issues are

> with this approach.


Defintiely option 2!

A side question - SDO has a couple of pre-reqs (libxml2, etc) - will 
these

> need to be rebuilt against stdcxx as well?


libxml2 is C rather than c++ so I don't think this is an issue. Same for
Axis2C for the sdo_axiom utility.

Cheers,

--
Pete




Generall I +1 the move to stdcxx and specifically to option 2 because...

In PHP SDO land, which of course uses Tuscany SDO, we tend to have faily
autonomous builds, i.e. we expect our users to be able to download the 
SDO

package and build it without having to download too much other stuff. At
least other stuff that isn't already known to the PHP build system . We
already depend on libxml2, iconv & zlib but these are generally 
available in

linux at stable versions. If we add a mandatory dependency on the apache
incubator version of stdxx then we have added another barrier to entry as
there is another packge to download that people may not be familiar 
with and
may cause clashes with other extensions that use other solutions. We 
won't
know until we try it. It may also cause problems for the automatic 
windows
build that takes place on the PECL servers outside of our control. I 
don't

really know the details of this though so would have to look into it.

Simon



+1 for option 2 as well.

--
Jean-Sebastien


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

Re: [C++] Extension mechanism for implementations and bindings

[Jean-Sebastien Delfino]

Pete Robbins wrote:
I've now finished this refactor. All checked in. Seems to work fine so 
I'm

going to go on holiday for a couple of weeks ;-)

Have fun folks!



Pete, everything works fine for me on Linux with the SVN head. The new 
folder structure and the extensibility story now look very good IMO. 
Have a good vacation!!


--
Jean-Sebastien


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

RE: How to invoke a web service with complex types? Java object / SDO conversion?

[Li Shen]

Hi folks,

As Chris's previous mail, it seems like when sending SOAP message, Celtix
binding delegates the java2xml conversion to SDO binding, and the SDO
binding converts SDO object to xml using Object.toString() (to our
surprise). 

Therefore, the resulting SOAP message is something like:

http://schemas.xmlsoap.org/soap/envelope/";
xmlns:xs="http://www.w3.org/2001/XMLSchema";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>

  http://www.foo.com/bar";>

  [EMAIL PROTECTED] (Id: 0, Dob:
null, FirstName: Li, Gender: null, LastName: Shen, MiddleName: null, Phone:
null, Ssn: null)

  



The content inside  is the string generated from
Patient.toString(), but the expected elements inside  should
conform to the schema in WSDL:



  
  
  
  
  
  
  
  

  

I found the toString conversion is done at SDOUtil. convertToString(Type
dataType, Object value) which eventually calls into ModelFactoryImpl.
convertToString(EDataType eDataType, Object instanceValue), and then object.
toString() gets called. Finally the string is returned to
DataObjectXMLStreamReader and Celtix binding gets the string using
getText().  

This might be caused by misusage of SDO binding, wrong SDO objects generated
by tool, or something else? Sounds like in celtix/axis binding, the
parameter of service method is added to DataObject using dataObject.set(i,
methodParameters[i]), which means the parameter such as Patient object
becomes a common object property of the DataObject and then is convert to
xml simply using toString()? 

Could someone familiar with SDO binding provide help on this? Thanks!

Regards,
Li

-Original Message-
From: Liu, Jervis [mailto:[EMAIL PROTECTED] 
Sent: 2006年8月30日 12:12
To: tuscany-dev@ws.apache.org
Subject: RE: How to invoke a web service with complex types? Java object /
SDO conversion?

Hi Chris, see comments in-line.

Cheers,
Jervis

> -Original Message-
> From: Chris Wall [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, August 30, 2006 6:01 AM
> To: tuscany-dev@ws.apache.org
> Subject: Re: How to invoke a web service with complex types? 
> Java object
> / SDO conversion?
> 
> 
> Hi Raymond.
> 
> In our case, the client is privy to the domain objects - Java objects
> (interfaces/classes) - used by the web service.  For example, 
> locally the
> client uses org.client.Patient throughout the application.  
> Before invoking
> a web service the client converts org.client.Patient to
> org.service.Patient(provided by service provider), and then invokes
> the web service passing
> org.service.Patient.
> 
> Migrating this code to Tuscany we're finding that SDO handles 
> the outbound
> by converting the Patient object to a String (I think).  The 
> inbound doesn't
> convert at all, but instead sends back null.
> 
I am not sure whether or not you are talking about the Celtix binding. It
looks like you are referring to the Celtix binding code from last week, I am
afraid it was not complete at that stage. But the latest version should
allow both inbound and outbound working, I have tested helloworldwsclient
sample, it works fine. 

Please note there is a hack currently in Celtix binding
NodeDataReader/NodeDataWriter code. I have to convert SDO object to stream
first, then stream to XML Node. This is because Celtix 1.0 does not have a
direct support to stax. Problem can be fixed once we move Celtix binding to
be based on the latest CeltixFire code base. CeltixFire repository is
already available  from apache incubator. 

As Raymond has mentioned, a pluggable databinding framework is under
construction at the moment. Before this happens, if you are keen to use
other databindings such as JAXB or xmlbeans, you can do so by implementing
your own NodeDataReader/NodeDataWriter. Let me know if you need any helps.


> It would be cool if the binding layer was able to dynamically 
> convert a Java
> object to a schema type matching the package name and class 
> name in the
> WSDL.  This is the ultimate non-invasive approach.
> 
> It sounds as if the WS binding layer for both Axis2 and 
> Celtix support only
> SDO as of today.  If this is true, what are the steps to 
> communicate with a
> complex type web service?  My guess is:
> 
> 1.) Generate SDO objects from WSDL using tuscany-sdo-plugin.
> 
> 2.) Create a service component (@Service) that matches the 
> web service's
> method signatures.
> 
> 3.) In the application scdl, import the WSDL into SDO
> ().  Although, I'm not sure exactly what
> this does.
> 
> 4.) In the application scdl, configure the service component with the
> binding.ws.
> 
> 5.) Within the client application, convert local Java objects 
> to SDO object
> using the Factory created in #1.
> 
> 6.) Within the client application, locate the service via 
> Tuscany context
> and invoke web service proxy method passing in the SDO object.
> 
> How does that sound?
> 
> -Ch

[jira] Commented: (TUSCANY-675) XPATH doesnt support dots in names (treats them as indices) in Java Implementation

[Frank Budinsky (JIRA)]

[ 
http://issues.apache.org/jira/browse/TUSCANY-675?page=comments#action_12431586 
] 

Frank Budinsky commented on TUSCANY-675:


This is a well known, but unfortunate "feature" of SDO 2.01. The "." character 
is a reserved character in SDO paths, so you can't access properties with names 
that include "." in a path expression. For now, you would need to do something 
like this instead:

DataObject comp = scaObj.getDataObject("component[1]");
DataObject impJava = 
comp.getDataObject(comp.getInstanceProperty("implentation.java"));

Another possiblity is that we could add alias names for properties with "." in 
their name. For example "implementation_java". Then clients could access it 
like this:

DataObject impJava = scaObj.getDataObject("component[1]/implementation_java");

Hopefully the SDO 2.1 spec , which is attempting to fix some of the problems in 
the 2.01 spec, will provide a good "standard" way to handle this relatively 
common problem when working with XSD based models.



> XPATH doesnt support dots in names (treats them as indices) in Java 
> Implementation
> --
>
> Key: TUSCANY-675
> URL: http://issues.apache.org/jira/browse/TUSCANY-675
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Implementation
>Affects Versions: Java-M2
> Environment: All
>Reporter: Hasan Muhammad
>
> When you try to do the following:
> DataObject impJava = scaObj.getDataObject("component[1]/implementation.java");
> It results in the following exception:
> java.lang.NumberFormatException: For input string: "java"
> at 
> java.lang.NumberFormatException.forInputString(NumberFormatException.java:63)
> at java.lang.Integer.parseInt(Integer.java:481)
> at java.lang.Integer.parseInt(Integer.java:531)
> at 
> org.apache.tuscany.sdo.util.DataObjectUtil$Accessor.process(DataObjectUtil.java:2097)
> at 
> org.apache.tuscany.sdo.util.DataObjectUtil$Accessor.init(DataObjectUtil.java:1918)
> at 
> org.apache.tuscany.sdo.util.DataObjectUtil$Accessor.create(DataObjectUtil.java:1838)
> at 
> org.apache.tuscany.sdo.util.DataObjectUtil.get(DataObjectUtil.java:738)
> at 
> org.apache.tuscany.sdo.impl.DataObjectImpl.get(DataObjectImpl.java:213)
> at 
> org.apache.tuscany.sdo.impl.DataObjectImpl.getDataObject(DataObjectImpl.java:323)
> at 
> com.ibm.ws.sca2.module.loader.test.SDOLoaderTest.main(SDOLoaderTest.java:60)
> It is clear that it is trying to treat the string after "." as an index..

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] Updated: (TUSCANY-642) Composite references and services - model and runtime representations

[Ignacio Silva-Lepe (JIRA)]

 [ http://issues.apache.org/jira/browse/TUSCANY-642?page=all ]

Ignacio Silva-Lepe updated TUSCANY-642:
---

Attachment: InnerCompositeCallback2.patch

This patch subsumes InnerCompositeCallback.patch. It incorporates local 
invocations and callbacks over composite services. The same approach is used to 
provide the callback invocation handler with the outbound wire that is 
connected to the composite service's inbound wire.
In addition, since bound services do not need a target invoker, there is no 
method to set it (or a callback target invoker) in the spi. It seems like at 
least a callback target invoker will be needed for bound services and since 
both are needed for bindless services, we may want to define them in the spi. 
This can be done as part of a callbacks over ws (axis2) binding patch.

> Composite references and services - model and runtime representations
> -
>
> Key: TUSCANY-642
> URL: http://issues.apache.org/jira/browse/TUSCANY-642
> Project: Tuscany
>  Issue Type: New Feature
>  Components: Java SCA Core
>Affects Versions: Java-Mx
>Reporter: Ignacio Silva-Lepe
> Assigned To: Ignacio Silva-Lepe
> Fix For: Java-Mx
>
> Attachments: CompositeRefsAndSvcs.txt, CompositeRefsAndSvcs2.txt, 
> InnerComposite.patch, InnerCompositeCallback.patch, 
> InnerCompositeCallback2.patch
>
>
> Support is added to represent composite references and services (those in a 
> composite and without a binding) in the model and runtime. The 
> CompositeBuilder is updated to build a composite component that includes 
> composite references and services without bindings.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

Re: [jira] Created: (TUSCANY-676) ImportSDOLoader: DataTypeImpl not found in XSDEcoreBuilder.typeToTypeObjectMap causes NPE (surfaced as IllegalArgumentException)

[Fuhwei Lwo]

Chris,
  
  I can reproduce your problem in pure SDO env without going thru the  
ImportSDOLoader in SCA.  Let me take a look and get back to you.
  
  Fuhwei Lwo

"Chris Wall (JIRA)"  wrote:  ImportSDOLoader: 
DataTypeImpl not found in XSDEcoreBuilder.typeToTypeObjectMap causes NPE 
(surfaced as IllegalArgumentException)


 Key: TUSCANY-676
 URL: http://issues.apache.org/jira/browse/TUSCANY-676
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Implementation
Reporter: Chris Wall
 Attachments: medrec.zip, xsdecorebuilder_npe.zip

During  SDO import of WSDL, elements of the following complex type are not  
found when validated against available SDO datatypes within the XSD  layer 
(XSDEcoreBuilder). Downstream this causes an NPE. It could be  that the 
comparison between the type and the key is not properly  implemented. See the 
attached zip containing debug screenshots.


  

  
  
  
  
  
  
  
  

  


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] Commented: (TUSCANY-667) New website ready to publish

[Venkatakrishnan (JIRA)]

[ 
http://issues.apache.org/jira/browse/TUSCANY-667?page=comments#action_12431575 
] 

Venkatakrishnan commented on TUSCANY-667:
-

Dave, here are some comments with whatever I have managed to observe.  

General
---
1) Can the width of the tabs (SCA, SDO and DAS) be increased a bit.  Also could 
we change the background color for the tabs to something dark so that it stands 
out and also when a tab is selected is it possible to show it in a different 
background.

2) In the page sdo_index.html, 
i) the caption for the second picture says...
 "SDO is a natural format for representing data on the wire in an SOA 
environment."  Could we add "Here is a perspective of that in an SCA Assembly 
Model"

ii) There is a line about DAS at the end of that page.  I find that out of 
place in the context of this page.

Let this patch be committed for a baseline and I can help you with fixing up 
things with appropriate patches subsequently PROVIDED the community also feels 
the same as I have with these.

- Venkat

> New website ready to publish
> 
>
> Key: TUSCANY-667
> URL: http://issues.apache.org/jira/browse/TUSCANY-667
> Project: Tuscany
>  Issue Type: New Feature
>  Components: Website
>Reporter: David Wheeler
> Attachments: site(8-29-06).zip, Tuscany Site.zip
>
>
> The new website is ready to go live. There are still a few pages TBD, but all 
> the content that is currently up is included in the new site.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

Re: Proposed Final Site

[Venkata Krishnan]

Hi David,

First thanks.

Can we comment on this in the JIRA itself so that all things to be addressed
can be tracked there?

I've just started to look into it and am going to log my opinions in the
JIRA unless you folks are going to ask me not to do so and instead use the
ML.

Thanks

- Venkat



On 8/30/06, Rick <[EMAIL PROTECTED]> wrote:


Something I noticed is with the flow. On all the images where I can click
on
something I get there and once I'm through with that page how do I get
back to
the initial diagram to explore something else?  I know there is the
browser
back, but I don't think that's a good practice. BTW I know this was not
part of
your changes.

David Wheeler wrote:
> Hi,
>
> I went ahead and re-made the site around Anakia, so that it can be built
> and
> published without php. Running build.bat will produce the files in
> site-publish for you.
> The zip is attached to JIRA issue here:
> http://issues.apache.org/jira/browse/TUSCANY-667
>
> -David W
>
> On 8/25/06, David Wheeler <[EMAIL PROTECTED]> wrote:
>>
>> You don't "build" the website
>> Simple changing the XML files changes the website. Deploying the
website
>> is simply putting all the files in the "site" folder into the root of
the
>> site on incubator.apache.org/tuscany
>> I will try and clarify that in the readme. as well as post it under the
>> development section.
>>
>> .svg files are Scalable Vector Graphics files
>> (http://www.w3.org/Graphics/SVG/).
>> Inkscape uses svg as its native file format.
>>
>> -David
>>
>>
>>
>> On 8/25/06, haleh mahbod < [EMAIL PROTECTED]> wrote:
>> >
>> > David,
>> >
>> > Thank you for your effort on this. Site prototype is much more user
>> > friendly
>> > and easier to follow.
>> >
>> > I looked through the readme. It is not clear to me how to
deploy/build
>> > the
>> > site changes.
>> > Can you please add those steps to the read me?
>> >
>> > We used to have a link on the website that explained how to modify
the
>> > website. It would be good to have that information under development
>> > box.
>> >
>> > What are the .svg files?
>> >
>> > Haleh
>> >
>> >
>> > On 8/25/06, David Wheeler <[EMAIL PROTECTED] > wrote:
>> > >
>> > > I think the new site is ready to go live. There are still a few
pages
>> > tbd,
>> > > but all the content that is on the current site is in the new one.
>> > >
>> > > I have created a JIRA issue with the site source attached.
>> > > http://issues.apache.org/jira/browse/TUSCANY-667
>> > > The Zip also contains a readme with instuctions on how to modify
the
>> > site
>> > > and craete new pages.
>> > >
>> > > -David Wheeler
>> > >
>> > >
>> >
>> >
>>
>

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

Re: [C++] Extension mechanism for implementations and bindings

[Pete Robbins]

I've now finished this refactor. All checked in. Seems to work fine so I'm
going to go on holiday for a couple of weeks ;-)

Have fun folks!


On 30/08/06, Pete Robbins <[EMAIL PROTECTED]> wrote:


 I'm going to restructure the source tree and deployment for the ws
binding. I think it will be better as:

extensions/
  ws/
reference/
service/
xsd

 as the scema is common to both reference and service

and deployed as
/extensions/
   ws/
   reference/
 lib ... etc
   service/
   xsd/

--
Pete





--
Pete

Re: Proposed Final Site

[Rick]

Something I noticed is with the flow. On all the images where I can click on 
something I get there and once I'm through with that page how do I get back to 
the initial diagram to explore something else?  I know there is the browser 
back, but I don't think that's a good practice. BTW I know this was not part of 
your changes.


David Wheeler wrote:

Hi,

I went ahead and re-made the site around Anakia, so that it can be built 
and

published without php. Running build.bat will produce the files in
site-publish for you.
The zip is attached to JIRA issue here:
http://issues.apache.org/jira/browse/TUSCANY-667

-David W

On 8/25/06, David Wheeler <[EMAIL PROTECTED]> wrote:


You don't "build" the website
Simple changing the XML files changes the website. Deploying the website
is simply putting all the files in the "site" folder into the root of the
site on incubator.apache.org/tuscany
I will try and clarify that in the readme. as well as post it under the
development section.

.svg files are Scalable Vector Graphics files 
(http://www.w3.org/Graphics/SVG/).

Inkscape uses svg as its native file format.

-David



On 8/25/06, haleh mahbod < [EMAIL PROTECTED]> wrote:
>
> David,
>
> Thank you for your effort on this. Site prototype is much more user
> friendly
> and easier to follow.
>
> I looked through the readme. It is not clear to me how to deploy/build
> the
> site changes.
> Can you please add those steps to the read me?
>
> We used to have a link on the website that explained how to modify the
> website. It would be good to have that information under development
> box.
>
> What are the .svg files?
>
> Haleh
>
>
> On 8/25/06, David Wheeler <[EMAIL PROTECTED] > wrote:
> >
> > I think the new site is ready to go live. There are still a few pages
> tbd,
> > but all the content that is on the current site is in the new one.
> >
> > I have created a JIRA issue with the site source attached.
> > http://issues.apache.org/jira/browse/TUSCANY-667
> > The Zip also contains a readme with instuctions on how to modify the
> site
> > and craete new pages.
> >
> > -David Wheeler
> >
> >
>
>





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

Re: Delivery Status Notification (Failure)

[ant elder]

Having this attached to a JIRA is fine, thats preferred over sending
attachments to the dev list.

Thanks for all this, I've only just started looking but it looks very
comprehensive, a lot more than I was expecting 8-). I've a few questions so
far. Firstly you didn't click the button granting license of the code to the
ASF, was that an oversight? The readme talks about some test examples and
samples showing how to use the registry but the test folders don't seem to
be included in the zip? From the brief look it wasn't clear to me if the
registry will require EMF, hopefully it doesn't?

Thanks,

  ...ant

On 8/30/06, Yang ZHONG <[EMAIL PROTECTED]> wrote:


Neither tuscany-dev nor infra takes my email with attachment, so I've
attached file for review into
http://issues.apache.org/jira/browse/TUSCANY-677

Sorry for the inconvenience and thanks for any comment.

On 8/30/06, Mail Delivery Subsystem <[EMAIL PROTECTED]> wrote:
>
> This is an automatically generated Delivery Status Notification
>
> Delivery to the following recipient failed permanently:
>
> [EMAIL PROTECTED]
>
> Technical details of permanent failure:
> PERM_FAILURE: SMTP Error (state 12): 552 Message rejected as it is spam
> (body)
>
>   - Original message -
>
> Received: by 10.35.31.14 with SMTP id i14mr634348pyj;
>Wed, 30 Aug 2006 03:06:43 -0700 (PDT)
> Received: by 10.35.103.13 with HTTP; Wed, 30 Aug 2006 03:06:41 -0700
(PDT)
> Message-ID: <[EMAIL PROTECTED]
>
> Date: Wed, 30 Aug 2006 03:06:41 -0700
> From: "Yang ZHONG" <[EMAIL PROTECTED]>
> To: tuscany-dev@ws.apache.org
> Subject: Re: Auto discovering WSDL
> Cc: [EMAIL PROTECTED]
> In-Reply-To: <[EMAIL PROTECTED]
>
> MIME-Version: 1.0
> Content-Type: multipart/mixed;
>boundary="=_Part_28704_31437365.1156932401933"
> References: <
> [EMAIL PROTECTED]>
> <[EMAIL PROTECTED]>
> <[EMAIL PROTECTED]>
> <[EMAIL PROTECTED]>
> <[EMAIL PROTECTED]>
>
> --=_Part_28704_31437365.1156932401933
> Content-Type: multipart/alternative;
>boundary="=_Part_28705_19724073.1156932401933"
>
> --=_Part_28705_19724073.1156932401933
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
>
> Could you please review the registry API and SPI?
>
>   - Message truncated -
>
>


--

Yang ZHONG

Re: Proposed Final Site

[Rick]

Dave:
It looks to me there are many links to "index.php?page" is this right?
There are changes scattered about with respect to links that don't seem right
Example site-author\get-involved.xml FAQ link
  Contribute to the FAQ or to
   Contribute to the FAQ or to



Also links changed from  href="./java-projects.html"  to href="java-projects" 
for the anakia processor it seems to make a difference.

The zip file contains index.php is this needed now?

Thanks

David Wheeler wrote:

Hi,

I went ahead and re-made the site around Anakia, so that it can be built 
and

published without php. Running build.bat will produce the files in
site-publish for you.
The zip is attached to JIRA issue here:
http://issues.apache.org/jira/browse/TUSCANY-667

-David W

On 8/25/06, David Wheeler <[EMAIL PROTECTED]> wrote:


You don't "build" the website
Simple changing the XML files changes the website. Deploying the website
is simply putting all the files in the "site" folder into the root of the
site on incubator.apache.org/tuscany
I will try and clarify that in the readme. as well as post it under the
development section.

.svg files are Scalable Vector Graphics files 
(http://www.w3.org/Graphics/SVG/).

Inkscape uses svg as its native file format.

-David



On 8/25/06, haleh mahbod < [EMAIL PROTECTED]> wrote:
>
> David,
>
> Thank you for your effort on this. Site prototype is much more user
> friendly
> and easier to follow.
>
> I looked through the readme. It is not clear to me how to deploy/build
> the
> site changes.
> Can you please add those steps to the read me?
>
> We used to have a link on the website that explained how to modify the
> website. It would be good to have that information under development
> box.
>
> What are the .svg files?
>
> Haleh
>
>
> On 8/25/06, David Wheeler <[EMAIL PROTECTED] > wrote:
> >
> > I think the new site is ready to go live. There are still a few pages
> tbd,
> > but all the content that is on the current site is in the new one.
> >
> > I have created a JIRA issue with the site source attached.
> > http://issues.apache.org/jira/browse/TUSCANY-667
> > The Zip also contains a readme with instuctions on how to modify the
> site
> > and craete new pages.
> >
> > -David Wheeler
> >
> >
>
>





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

Re: Delivery Status Notification (Failure)

[Yang ZHONG]

Neither tuscany-dev nor infra takes my email with attachment, so I've
attached file for review into
http://issues.apache.org/jira/browse/TUSCANY-677

Sorry for the inconvenience and thanks for any comment.

On 8/30/06, Mail Delivery Subsystem <[EMAIL PROTECTED]> wrote:


This is an automatically generated Delivery Status Notification

Delivery to the following recipient failed permanently:

[EMAIL PROTECTED]

Technical details of permanent failure:
PERM_FAILURE: SMTP Error (state 12): 552 Message rejected as it is spam
(body)

  - Original message -

Received: by 10.35.31.14 with SMTP id i14mr634348pyj;
   Wed, 30 Aug 2006 03:06:43 -0700 (PDT)
Received: by 10.35.103.13 with HTTP; Wed, 30 Aug 2006 03:06:41 -0700 (PDT)
Message-ID: <[EMAIL PROTECTED]>
Date: Wed, 30 Aug 2006 03:06:41 -0700
From: "Yang ZHONG" <[EMAIL PROTECTED]>
To: tuscany-dev@ws.apache.org
Subject: Re: Auto discovering WSDL
Cc: [EMAIL PROTECTED]
In-Reply-To: <[EMAIL PROTECTED]>
MIME-Version: 1.0
Content-Type: multipart/mixed;
   boundary="=_Part_28704_31437365.1156932401933"
References: <
[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>

--=_Part_28704_31437365.1156932401933
Content-Type: multipart/alternative;
   boundary="=_Part_28705_19724073.1156932401933"

--=_Part_28705_19724073.1156932401933
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Could you please review the registry API and SPI?

  - Message truncated -





--

Yang ZHONG

[jira] Created: (TUSCANY-677) Registry API & SPI

[Yang ZHONG (JIRA)]

Registry API & SPI
--

 Key: TUSCANY-677
 URL: http://issues.apache.org/jira/browse/TUSCANY-677
 Project: Tuscany
  Issue Type: New Feature
  Components: Java SCA Common
Affects Versions: Java-M2
Reporter: Yang ZHONG
 Attachments: registry.zip

Could you please review the registry API and SPI?
 
Please start with ReadMe.txt, it describes content including
  API\src\main\java\overview.HTML for API overview
and
  API\src\main\java\org\apache\tuscany\registry\package.html for API design and 
example
They're also available as JavaDoc at
  API\doc\index.html
 
The API usage can be as simple as
  MySymbol mySymbol = mySymbolSpace.resolve( javax_xml_namespace_QName);
 
As for SPI,

  SPI\src\main\java\overview.HTML is for SPI overview
and
  SPI\src\main\java\org\apache\tuscany\registry\spi\package.html is for SPI 
design and sample
They're also available as JavaDoc at
  SPI\doc\index.html

Thanks.

(Neither  tuscany-dev nor infra takes my email with attachment, so I attach 
file here, the history can be found at
http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg06781.html)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

Re: [SDO for C++] Opinions Requested: Adopting stdcxx as C++ library

[Simon Laws]

On 8/30/06, Pete Robbins <[EMAIL PROTECTED]> wrote:


On 30/08/06, Andrew Borley <[EMAIL PROTECTED]> wrote:
>
> On 8/30/06, Geoffrey Winn <[EMAIL PROTECTED]> wrote:
> . Using the Apache stdcxx library instead would provide
>
> > us with a number of benefits
>
>
> Agreed. +1 for this.


yup!

The one difficulty is that once SDO links against the stdcxx library then
> > all users of SDO must also do so. I think this gives us two options
> >
> > 1. Just do it, and live with the consequences. In this case we will
(one
> > way
> > or another) pre-req stdcxx on all platforms, and all users of SDO for
> C++
> > will be required to use stdcxx as their C++ standard library.
> >
> > 2. Create a build time switch that chooses between whatever the
platform
> > offers (ie the current arrangement) and stdcxx. Presumably defaulting
to
> > the
> > current arrangement.
> >
> > I prefer option 2 but obviously it somewhat complicates our build
> process
> > and perhaps more seriously adds another complication to our test
cases.
> >
> > What does the team think?


My preference is also for option 2 as it gives our users more choice.
> However, we may find ourselves #ifdef-ing chunks of code out to get
around
> the aforementioned differences in libraries (see Pete's map problem on
> Windows yesterday..) which will make code less readable, etc. I think
> starting this with the SDO codebase is a good idea, as this is a
> relatively
> standalone set of code, and will give us a good idea what the issues are
> with this approach.


Defintiely option 2!

A side question - SDO has a couple of pre-reqs (libxml2, etc) - will these
> need to be rebuilt against stdcxx as well?


libxml2 is C rather than c++ so I don't think this is an issue. Same for
Axis2C for the sdo_axiom utility.

Cheers,

--
Pete




Generall I +1 the move to stdcxx and specifically to option 2 because...

In PHP SDO land, which of course uses Tuscany SDO, we tend to have faily
autonomous builds, i.e. we expect our users to be able to download the SDO
package and build it without having to download too much other stuff. At
least other stuff that isn't already known to the PHP build system . We
already depend on libxml2, iconv & zlib but these are generally available in
linux at stable versions. If we add a mandatory dependency on the apache
incubator version of stdxx then we have added another barrier to entry as
there is another packge to download that people may not be familiar with and
may cause clashes with other extensions that use other solutions. We won't
know until we try it. It may also cause problems for the automatic windows
build that takes place on the PECL servers outside of our control. I don't
really know the details of this though so would have to look into it.

Simon

Re: [SDO for C++] Opinions Requested: Adopting stdcxx as C++ library

[Pete Robbins]

On 30/08/06, Andrew Borley <[EMAIL PROTECTED]> wrote:


On 8/30/06, Geoffrey Winn <[EMAIL PROTECTED]> wrote:
. Using the Apache stdcxx library instead would provide

> us with a number of benefits


Agreed. +1 for this.



yup!

The one difficulty is that once SDO links against the stdcxx library then

> all users of SDO must also do so. I think this gives us two options
>
> 1. Just do it, and live with the consequences. In this case we will (one
> way
> or another) pre-req stdcxx on all platforms, and all users of SDO for
C++
> will be required to use stdcxx as their C++ standard library.
>
> 2. Create a build time switch that chooses between whatever the platform
> offers (ie the current arrangement) and stdcxx. Presumably defaulting to
> the
> current arrangement.
>
> I prefer option 2 but obviously it somewhat complicates our build
process
> and perhaps more seriously adds another complication to our test cases.
>
> What does the team think?



My preference is also for option 2 as it gives our users more choice.

However, we may find ourselves #ifdef-ing chunks of code out to get around
the aforementioned differences in libraries (see Pete's map problem on
Windows yesterday..) which will make code less readable, etc. I think
starting this with the SDO codebase is a good idea, as this is a
relatively
standalone set of code, and will give us a good idea what the issues are
with this approach.



Defintiely option 2!

A side question - SDO has a couple of pre-reqs (libxml2, etc) - will these

need to be rebuilt against stdcxx as well?



libxml2 is C rather than c++ so I don't think this is an issue. Same for
Axis2C for the sdo_axiom utility.

Cheers,

--
Pete

Re: [SDO for C++] Opinions Requested: Adopting stdcxx as C++ library

[Andrew Borley]

On 8/30/06, Geoffrey Winn <[EMAIL PROTECTED]> wrote:
. Using the Apache stdcxx library instead would provide


us with a number of benefits



Agreed. +1 for this.

The one difficulty is that once SDO links against the stdcxx library then

all users of SDO must also do so. I think this gives us two options

1. Just do it, and live with the consequences. In this case we will (one
way
or another) pre-req stdcxx on all platforms, and all users of SDO for C++
will be required to use stdcxx as their C++ standard library.

2. Create a build time switch that chooses between whatever the platform
offers (ie the current arrangement) and stdcxx. Presumably defaulting to
the
current arrangement.

I prefer option 2 but obviously it somewhat complicates our build process
and perhaps more seriously adds another complication to our test cases.

What does the team think?



My preference is also for option 2 as it gives our users more choice.
However, we may find ourselves #ifdef-ing chunks of code out to get around
the aforementioned differences in libraries (see Pete's map problem on
Windows yesterday..) which will make code less readable, etc. I think
starting this with the SDO codebase is a good idea, as this is a relatively
standalone set of code, and will give us a good idea what the issues are
with this approach.

A side question - SDO has a couple of pre-reqs (libxml2, etc) - will these
need to be rebuilt against stdcxx as well?

Cheers
Andy

[jira] Assigned: (TUSCANY-671) Port JSON-RPC binding from M1

[ant elder (JIRA)]

 [ http://issues.apache.org/jira/browse/TUSCANY-671?page=all ]

ant elder reassigned TUSCANY-671:
-

Assignee: ant elder

> Port JSON-RPC binding from M1
> -
>
> Key: TUSCANY-671
> URL: http://issues.apache.org/jira/browse/TUSCANY-671
> Project: Tuscany
>  Issue Type: Improvement
>  Components: Java SCA JsonRpc Binding
>Affects Versions: Java-M2
>Reporter: Bert Lamb
> Assigned To: ant elder
>Priority: Minor
> Attachments: json-rpc-binding.zip
>
>
> Port the JSON-RPC binding from M1 into the new binding format.  I've been 
> working on this, so I should be able to post a patch soon.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[SDO for C++] Opinions Requested: Adopting stdcxx as C++ library

[Geoffrey Winn]

There is an Apache incubator project to develop an implementation of the
standard C++ library (their web site is here
http://incubator.apache.org/stdcxx).
Currently, in SDO for C++, we use the library provided by whichever platform
we happen to run on. Using the Apache stdcxx library instead would provide
us with a number of benefits

- It is available on a wide range of platforms
- It is the same implementation on all of them (so avoids obscure bugs from
slight differences in C++ libraries)
- It is open source so we can contribute fixes rather than writing around
problems.
- We become better citizens of the Apache community

The one difficulty is that once SDO links against the stdcxx library then
all users of SDO must also do so. I think this gives us two options

1. Just do it, and live with the consequences. In this case we will (one way
or another) pre-req stdcxx on all platforms, and all users of SDO for C++
will be required to use stdcxx as their C++ standard library.

2. Create a build time switch that chooses between whatever the platform
offers (ie the current arrangement) and stdcxx. Presumably defaulting to the
current arrangement.

I prefer option 2 but obviously it somewhat complicates our build process
and perhaps more seriously adds another complication to our test cases.

What does the team think?

Geoff.

Re: svn commit: r438000

[ant elder]

From past discussions there may also be other mismatches and Raymond said

the line length was just one example of a difference. I think the IDE
template should be the authority, its the 21st century, we should be able to
use IDE code formatting.

  ...ant

On 8/30/06, Jim Marino <[EMAIL PROTECTED]> wrote:


I think it should be the checkstyle. The widest we ever went was 140
and we had a discussion on several occasions where some wanted it
smaller (e.g. 80), some larger, and some didn't care. 120 seems to be
a reasonable length. Do you want to update the Eclipse one?

Jim

On Aug 29, 2006, at 5:03 PM, Raymond Feng wrote:

> Hi,
>
> The rules from checkstlye are quite different than the IDE code
> formatter templates we were recommending. For example, the template
> for Eclipse sets the maximum characters per line to 150 while the
> checkstyle complains at 120.
>
> Which one should we follow? If it's the checkstyle, then we should
> update the IDE templates so that we are not confused.
>
> Thanks,
> Raymond
>
> - Original Message - From: "Jim Marino"
> <[EMAIL PROTECTED]>
> To: 
> Sent: Tuesday, August 29, 2006 1:12 AM
> Subject: Fwd: svn commit: r438000
>
>
>> Hi Raymond,
>>
>> Could you please make sure you format this code: mvn -
>> Psourcecheck?  It breaks Checkstyle.
>>
>> Thanks,
>> Jim
>>
>> Begin forwarded message:
>>
>>> From: [EMAIL PROTECTED]
>>> Date: August 29, 2006 1:00:16 AM PDT
>>> To: tuscany-commits@ws.apache.org
>>> Subject: svn commit: r438000 - in /incubator/tuscany/java/sca/
>>> core/ src: main/java/org/apache/tuscany/core/loader/
>>> ComponentLoader.java test/java/org/apache/tuscany/core/loader/
>>> ComponentLoaderTestCase.java
>>> Reply-To: tuscany-dev@ws.apache.org
>>>
>>> Author: rfeng
>>> Date: Tue Aug 29 01:00:16 2006
>>> New Revision: 438000
>>>
>>> URL: http://svn.apache.org/viewvc?rev=438000&view=rev
>>> Log:
>>> Make sure the StAX loading only ends upon 
>>>
>>> Modified:
>>> incubator/tuscany/java/sca/core/src/main/java/org/apache/
>>> tuscany/core/loader/ComponentLoader.java
>>> incubator/tuscany/java/sca/core/src/test/java/org/apache/
>>> tuscany/core/loader/ComponentLoaderTestCase.java
>>>
>>> Modified: incubator/tuscany/java/sca/core/src/main/java/org/
>>> apache/ tuscany/core/loader/ComponentLoader.java
>>> URL: http://svn.apache.org/viewvc/incubator/tuscany/java/sca/
>>> core/ src/main/java/org/apache/tuscany/core/loader/
>>> ComponentLoader.java? rev=438000&r1=437999&r2=438000&view=diff
>>> 
>>> == 
>>> --- incubator/tuscany/java/sca/core/src/main/java/org/apache/
>>> tuscany/core/loader/ComponentLoader.java (original)
>>> +++ incubator/tuscany/java/sca/core/src/main/java/org/apache/
>>> tuscany/core/loader/ComponentLoader.java Tue Aug 29 01:00:16 2006
>>> @@ -113,7 +113,8 @@
>>>  reader.next();
>>>  break;
>>>  case END_ELEMENT:
>>> -return componentDefinition;
>>> +if(reader.getName().equals(COMPONENT))
>>> +return componentDefinition;
>>>  }
>>>  }
>>>  } catch (LoaderException e) {
>>>
>>> Modified: incubator/tuscany/java/sca/core/src/test/java/org/
>>> apache/ tuscany/core/loader/ComponentLoaderTestCase.java
>>> URL: http://svn.apache.org/viewvc/incubator/tuscany/java/sca/
>>> core/ src/test/java/org/apache/tuscany/core/loader/
>>> ComponentLoaderTestCase.java?
>>> rev=438000&r1=437999&r2=438000&view=diff
>>> 
>>> == 
>>> --- incubator/tuscany/java/sca/core/src/test/java/org/apache/
>>> tuscany/core/loader/ComponentLoaderTestCase.java (original)
>>> +++ incubator/tuscany/java/sca/core/src/test/java/org/apache/
>>> tuscany/core/loader/ComponentLoaderTestCase.java Tue Aug 29
>>> 01:00:16 2006
>>> @@ -57,7 +57,7 @@
>>>  private ComponentLoader loader;
>>>
>>>  public void testEmptyComponent() throws LoaderException,
>>> XMLStreamException {
>>> -mockReader.expects(once()).method("getName").will
>>> (returnValue(COMPONENT));
>>> +mockReader.expects(atLeastOnce()).method("getName").will
>>> (returnValue(COMPONENT));
>>>  mockReader.expects(atLeastOnce()).method
>>> ("getAttributeValue")
>>>  .with(ANYTHING, ANYTHING)
>>>  .will(onConsecutiveCalls(returnValue(NAME),
>>> returnValue (null)));
>>> @@ -71,7 +71,7 @@
>>>  }
>>>
>>>  public void testInitValue20() throws LoaderException,
>>> XMLStreamException {
>>> -mockReader.expects(once()).method("getName").will
>>> (returnValue(COMPONENT));
>>> +mockReader.expects(atLeastOnce()).method("getName").will
>>> (returnValue(COMPONENT));
>>>  mockReader.expects(atLeastOnce()).method
>>> ("getAttributeValue")
>>>  .with(ANYTHING, ANYTHING)
>>>  .will(onConsecutiveCalls(retur

Re: [C++] Extension mechanism for implementations and bindings

[Pete Robbins]

I'm going to restructure the source tree and deployment for the ws binding.
I think it will be better as:

extensions/
 ws/
   reference/
   service/
   xsd

as the scema is common to both reference and service

and deployed as
/extensions/
  ws/
  reference/
lib ... etc
  service/
  xsd/

--
Pete

Re: svn commit: r438000

[Venkata Krishnan]

Hi,

I faced the same problem and configured my eclipse.  But then when you
reduce this you might also want to take care of how the line wrapping is
done.  For example the method signatures get wrapped without any alignment
and looked a bit clumsy.  I then set alignment of arguments and it looked a
little better after that.

- Venkat

On 8/30/06, Jim Marino <[EMAIL PROTECTED]> wrote:


I think it should be the checkstyle. The widest we ever went was 140
and we had a discussion on several occasions where some wanted it
smaller (e.g. 80), some larger, and some didn't care. 120 seems to be
a reasonable length. Do you want to update the Eclipse one?

Jim

On Aug 29, 2006, at 5:03 PM, Raymond Feng wrote:

> Hi,
>
> The rules from checkstlye are quite different than the IDE code
> formatter templates we were recommending. For example, the template
> for Eclipse sets the maximum characters per line to 150 while the
> checkstyle complains at 120.
>
> Which one should we follow? If it's the checkstyle, then we should
> update the IDE templates so that we are not confused.
>
> Thanks,
> Raymond
>
> - Original Message - From: "Jim Marino"
> <[EMAIL PROTECTED]>
> To: 
> Sent: Tuesday, August 29, 2006 1:12 AM
> Subject: Fwd: svn commit: r438000
>
>
>> Hi Raymond,
>>
>> Could you please make sure you format this code: mvn -
>> Psourcecheck?  It breaks Checkstyle.
>>
>> Thanks,
>> Jim
>>
>> Begin forwarded message:
>>
>>> From: [EMAIL PROTECTED]
>>> Date: August 29, 2006 1:00:16 AM PDT
>>> To: tuscany-commits@ws.apache.org
>>> Subject: svn commit: r438000 - in /incubator/tuscany/java/sca/
>>> core/ src: main/java/org/apache/tuscany/core/loader/
>>> ComponentLoader.java test/java/org/apache/tuscany/core/loader/
>>> ComponentLoaderTestCase.java
>>> Reply-To: tuscany-dev@ws.apache.org
>>>
>>> Author: rfeng
>>> Date: Tue Aug 29 01:00:16 2006
>>> New Revision: 438000
>>>
>>> URL: http://svn.apache.org/viewvc?rev=438000&view=rev
>>> Log:
>>> Make sure the StAX loading only ends upon 
>>>
>>> Modified:
>>> incubator/tuscany/java/sca/core/src/main/java/org/apache/
>>> tuscany/core/loader/ComponentLoader.java
>>> incubator/tuscany/java/sca/core/src/test/java/org/apache/
>>> tuscany/core/loader/ComponentLoaderTestCase.java
>>>
>>> Modified: incubator/tuscany/java/sca/core/src/main/java/org/
>>> apache/ tuscany/core/loader/ComponentLoader.java
>>> URL: http://svn.apache.org/viewvc/incubator/tuscany/java/sca/
>>> core/ src/main/java/org/apache/tuscany/core/loader/
>>> ComponentLoader.java? rev=438000&r1=437999&r2=438000&view=diff
>>> 
>>> == 
>>> --- incubator/tuscany/java/sca/core/src/main/java/org/apache/
>>> tuscany/core/loader/ComponentLoader.java (original)
>>> +++ incubator/tuscany/java/sca/core/src/main/java/org/apache/
>>> tuscany/core/loader/ComponentLoader.java Tue Aug 29 01:00:16 2006
>>> @@ -113,7 +113,8 @@
>>>  reader.next();
>>>  break;
>>>  case END_ELEMENT:
>>> -return componentDefinition;
>>> +if(reader.getName().equals(COMPONENT))
>>> +return componentDefinition;
>>>  }
>>>  }
>>>  } catch (LoaderException e) {
>>>
>>> Modified: incubator/tuscany/java/sca/core/src/test/java/org/
>>> apache/ tuscany/core/loader/ComponentLoaderTestCase.java
>>> URL: http://svn.apache.org/viewvc/incubator/tuscany/java/sca/
>>> core/ src/test/java/org/apache/tuscany/core/loader/
>>> ComponentLoaderTestCase.java?
>>> rev=438000&r1=437999&r2=438000&view=diff
>>> 
>>> == 
>>> --- incubator/tuscany/java/sca/core/src/test/java/org/apache/
>>> tuscany/core/loader/ComponentLoaderTestCase.java (original)
>>> +++ incubator/tuscany/java/sca/core/src/test/java/org/apache/
>>> tuscany/core/loader/ComponentLoaderTestCase.java Tue Aug 29
>>> 01:00:16 2006
>>> @@ -57,7 +57,7 @@
>>>  private ComponentLoader loader;
>>>
>>>  public void testEmptyComponent() throws LoaderException,
>>> XMLStreamException {
>>> -mockReader.expects(once()).method("getName").will
>>> (returnValue(COMPONENT));
>>> +mockReader.expects(atLeastOnce()).method("getName").will
>>> (returnValue(COMPONENT));
>>>  mockReader.expects(atLeastOnce()).method
>>> ("getAttributeValue")
>>>  .with(ANYTHING, ANYTHING)
>>>  .will(onConsecutiveCalls(returnValue(NAME),
>>> returnValue (null)));
>>> @@ -71,7 +71,7 @@
>>>  }
>>>
>>>  public void testInitValue20() throws LoaderException,
>>> XMLStreamException {
>>> -mockReader.expects(once()).method("getName").will
>>> (returnValue(COMPONENT));
>>> +mockReader.expects(atLeastOnce()).method("getName").will
>>> (returnValue(COMPONENT));
>>>  mockReader.expects(atLeastOnce()).method
>>> ("getAttributeValue")
>>>