Re: [jira] Closed: (TUSCANY-1382) Minor fixes to OSGi declarative services support and additional tests

[Rajini Sivaram]

Ant,

Thank you for applying the patches.

I will submit a patch for the exception in implementation-osgi. The OSGi
implementation is no longer resolving the component type file correctly.
Tuscany is now using a relative path name for the component type file URI
(it used to store an absolute path before). I will fix the OSGi
implementation to use relative path so that it resolves the file correctly.

Thank you...

Regards,

Rajini


On 7/2/07, ant elder <[EMAIL PROTECTED]> wrote:


Thanks for these patches, I've applied them.

There is a problem now with the implementation-osgi extension, it doesn't
work with the latest trunk code with tests failing with a class cast
exception,  thats with or without the latest patches, and it works fine when
using the 0.90 release of the runtime. It looks like something to do with
the recent changes to how componentType's are handled and
implementation-osgi extending a ComponentTypeImpl class, but I'm not sure
exactly what the problem is. Anyone have any ideas or want to take a look?
If this can be fixed I'll add to the main build so this type of problem
doesn't happen.

   ...ant

[jira] Updated: (TUSCANY-1406) Component type file not resolved correctly in implementation.osgi

[Rajini Sivaram (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rajini Sivaram updated TUSCANY-1406:


Attachment: tuscany-implementation-osgi-patch.txt

> Component type file not resolved correctly in implementation.osgi
> -
>
> Key: TUSCANY-1406
> URL: https://issues.apache.org/jira/browse/TUSCANY-1406
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA OSGi Integration
>Reporter: Rajini Sivaram
>Priority: Minor
> Attachments: tuscany-implementation-osgi-patch.txt
>
>
> The OSGi implementation is no longer resolving the component type file 
> correctly. Tuscany is now using a relative path name for the component type 
> file URI (it used to store an absolute path before). The OSGi implementation 
> should also use a relative path so that it resolves the file correctly. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Created: (TUSCANY-1406) Component type file not resolved correctly in implementation.osgi

[Rajini Sivaram (JIRA)]

Component type file not resolved correctly in implementation.osgi
-

 Key: TUSCANY-1406
 URL: https://issues.apache.org/jira/browse/TUSCANY-1406
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA OSGi Integration
Reporter: Rajini Sivaram
Priority: Minor
 Attachments: tuscany-implementation-osgi-patch.txt

The OSGi implementation is no longer resolving the component type file 
correctly. Tuscany is now using a relative path name for the component type 
file URI (it used to store an absolute path before). The OSGi implementation 
should also use a relative path so that it resolves the file correctly. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Commented: (TUSCANY-1404) Detail DAS samples' readme

[Adriano Crestani (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-1404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12509784
 ] 

Adriano Crestani commented on TUSCANY-1404:
---

Created the readme that summarizes all samples

> Detail DAS samples' readme
> --
>
> Key: TUSCANY-1404
> URL: https://issues.apache.org/jira/browse/TUSCANY-1404
> Project: Tuscany
>  Issue Type: Improvement
>  Components: Java DAS RDB
>Affects Versions: Java-DAS-beta1
>Reporter: Adriano Crestani
>Assignee: Adriano Crestani
>Priority: Critical
> Fix For: Java-DAS-beta1
>
>
> - Create a readme on DAS samples' top level dir that summarizes all DAS 
> samples
> - Detail how to run and use customer sample on its readme

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

Re: How does one specify a Property as containment property in XML Schema?

[kelvin goodson]

Hi Pinaki,
I meant to say please "paste" your test code,  as attachments get stripped
from this list.
Regards,Kelvin.


On 03/07/07, kelvin goodson <[EMAIL PROTECTED]> wrote:


Hi Pinaki,
  can you please post your test code?
Regards, Kelvin.


 On 03/07/07, Pinaki Poddar <[EMAIL PROTECTED]> wrote:
>
> Hi Fuhwei,
>   The types are parsed and registered OK. The part of the test that
> verfies it, passes alright. The test fails while the registered types
> are used to create instances.
>
>   Please find attached JUnitTest, the XML Schema model and the stack
> trace.
>
> java.lang.IllegalArgumentException: The property 'shipTo' of
> 'PurchaseOrderType' isn't a containment
>at
> org.apache.tuscany.sdo.util.DataObjectUtil.createDataObject(DataObjectUt
> il.java:421)
>at
> org.apache.tuscany.sdo.util.DataObjectUtil.createDataObject(DataObjectUt
> il.java:467)
>at
> org.apache.tuscany.sdo.impl.DataObjectImpl.createDataObject(DataObjectIm
> pl.java:1195)
>at test.TestSDO.testCreateModel(TestSDO.java:57)
>
>
>
> Pinaki Poddar
> 972.834.2865
>
> -Original Message-
> From: Fuhwei Lwo [mailto:[EMAIL PROTECTED]
> Sent: Monday, July 02, 2007 4:32 PM
> To: tuscany-dev@ws.apache.org
> Subject: RE: How does one specify a Property as containment property in
> XML Schema?
>
> Hi Pinaki,
>
> I think your XSDHelper.define() failed to register types for some
> reason. Can you try this to see whether any types were registered?
>
> java.util.List types = XSDHelper.INSTANCE.define (fis, null);
>for (int i=0; iSystem.out.println("Type defined: " + types.get(i));
>}
>
> Normally, you should see PurchaseOrderType, USAddress, etc registered.
>
> Fuhwei
>
> Pinaki Poddar <[EMAIL PROTECTED]> wrote: Hello Fuhwei,
> I am following your footstep! It is the same po.xsd I copied from your
> very readable post
>
> http://www.ibm.com/developerworks/webservices/library/ws-sdoxmlschema/in
> dex.html
>
> except that it was missing a closing
>
> Thanks for your help.
>
>
> Pinaki Poddar
> 972.834.2865
>
> -Original Message-
> From: Fuhwei Lwo [mailto:[EMAIL PROTECTED]
> Sent: Monday, July 02, 2007 3:35 PM
> To: tuscany-dev@ws.apache.org
> Subject: Re: How does one specify a Property as containment property in
> XML Schema?
>
> Hi Pinaki,
>
> What is the type of "shipTo" property? It needs to be a complex type.
> Can you post your XSD? Thanks.
>
> Fuhwei
>
>
> Pinaki Poddar
> wrote: Hello,
>
> How does one specify a Property as containment property in XML Schema?
>
>
> I was trying a simple example with a XML Schema ( po.xsd) that had the
> following snippet:
>
>
>
>
>
> XSDHelper.INSTANCE.define(...) works fine to construct the types from
> po.xsd.
>
> However when the following is executed:
>
> 01: DataObject purchaseOrder =
> DataFactory.INSTANCE.create("http://www.example.com/PO";,
> "PurchaseOrderType");
> 02: DataObject shipTo = purchaseOrder.createDataObject("shipTo");
>
> It fails with
> java.lang.IllegalArgumentException: The property 'shipTo' of
> 'PurchaseOrderType' isn't a containment  at
> org.apache.tuscany.sdo.util.DataObjectUtil.createDataObject(DataObjectUt
>
> il.java:421)
> at
> org.apache.tuscany.sdo.util.DataObjectUtil.createDataObject(DataObjectUt
> il.java:467)
> at
> org.apache.tuscany.sdo.impl.DataObjectImpl.createDataObject(DataObjectIm
> pl.java:1195)
> at test.TestModel.testInstance (TestModel.java:41)
>
> I am using tuscany-sdo-impl-1.0-incubating-beta1.jar.
>
>
> Pinaki Poddar
> 972.834.2865
>
>
> Notice:  This email message, together with any attachments, may contain
> information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
> entities,  that may be confidential,  proprietary,  copyrighted  and/or
> legally privileged, and is intended solely for the use of the individual
> or entity named in this message. If you are not the intended recipient,
> and have received this message in error, please immediately return this
> by email and then delete it.
>
> Notice:  This email message, together with any attachments, may contain
> information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
> entities,  that may be confidential,  proprietary,  copyrighted  and/or
> legally privileged, and is intended solely for the use of the individual
> or entity named in this message. If you are not the intended recipient,
> and have received this message in error, please immediately return this
> by email and then delete it.
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
> Notice:  This email message, together with any attachments, may contain
> information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
> entities,  that may be confidential,  proprietary,  copyrighted  and/or
> legally privileged, and is intended solely for the use of the individual or
> entity named in this message. If you are not th

Re: How does one specify a Property as containment property in XML Schema?

[kelvin goodson]

Pinaki,
 perfect, thanks (yes, the attachments are stripped by the list),  will try
them out soon.
Kelvin

On 03/07/07, Pinaki Poddar <[EMAIL PROTECTED]> wrote:


Are you not seeing the e-mail attachements TestSDO.java and po.xsd?

In any case, here they are
= TestSDO.java
==

package test;

import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;
import java.util.List;

import javax.persistence.EntityManager;
import javax.persistence.EntityManagerFactory;
import javax.persistence.Persistence;

import org.apache.tuscany.sdo.helper.HelperProviderImpl;

import com.bea.jpa.SDOEntityManager;
import com.bea.jpa.SDOEntityManagerFactory;

import commonj.sdo.DataObject;
import commonj.sdo.helper.DataFactory;
import commonj.sdo.helper.XMLHelper;
import commonj.sdo.helper.XSDHelper;
import commonj.sdo.impl.HelperProvider;

import junit.framework.TestCase;

/**
* JUnit Tests to read a meta-model from XML Schema and create instances
* according to the meta-model.
*
* @author ppoddar
*
*/
public class TestSDO extends TestCase {
private static final String RESOURCE_SDO_MODEL  = "po.xsd";
private static final String SDO_MODEL_NAMESPACE =
"http://www.example.com/PO";;

/**
 * Create a SDO MetaData Model from a XML Schema and populate
instances.
 * Assumes 'po.xsd' be available in classpath as resource.
 *
 */
public void testCreateModel() {
InputStream xsdInputStream =
this.getClass().getClassLoader()

.getResourceAsStream(RESOURCE_SDO_MODEL);
assertNotNull(xsdInputStream);

String schemaLocation = null;
List/*  */types =
XSDHelper.INSTANCE.define(xsdInputStream,
schemaLocation);
assertTrue(types != null && !types.isEmpty());
assertTrue(types.size() >= 2);

DataObject purchaseOrder = DataFactory.INSTANCE.create(
SDO_MODEL_NAMESPACE,
"PurchaseOrderType");

purchaseOrder.setString("orderDate", "1999-10-20");

DataObject shipTo =
purchaseOrder.createDataObject("shipTo");
shipTo.set("country", "US");
shipTo.set("name", "Alice Smith");
shipTo.set("street", "123 Maple Street");
shipTo.set("city", "Mill Valley");
shipTo.set("state", "CA");
shipTo.setString("zip", "90952");
DataObject billTo =
purchaseOrder.createDataObject("billTo");
billTo.set("country", "US");
billTo.set("name", "Robert Smith");
billTo.set("street", "8 Oak Avenue");
billTo.set("city", "Mill Valley");
billTo.set("state", "PA");
billTo.setString("zip", "95819");
purchaseOrder.set("comment", "Hurry, my lawn is going
wild!");

DataObject items =
purchaseOrder.createDataObject("items");

DataObject item1 = items.createDataObject("item");
item1.set("partNum", "872-AA");
item1.set("productName", "Lawnmower");
item1.setInt("quantity", 1);
item1.setString("USPrice", "148.95");
item1.set("comment", "Confirm this is electric");

DataObject item2 = items.createDataObject("item");
item2.set("partNum", "926-AA");
item2.set("productName", "Baby Monitor");
item2.setInt("quantity", 1);
item2.setString("USPrice", "39.98");
item2.setString("shipDate", "1999-05-21");

try {
OutputStream stream = System.err;
XMLHelper.INSTANCE.save(purchaseOrder,
SDO_MODEL_NAMESPACE,
"purchaseOrder", stream);
} catch (IOException e) {
e.printStackTrace();
fail();
}
}

}


===
XML Schema Definition: po.xsd

===
http://www.w3.org/2001/XMLSchema";
xmlns:po="http://www.example.com/PO";
targetNamespace="http://www.example.com/PO";>

RE: How does one specify a Property as containment property in XML Schema?

[Pinaki Poddar]

Are you not seeing the e-mail attachements TestSDO.java and po.xsd?

In any case, here they are
= TestSDO.java
==

package test;

import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;
import java.util.List;

import javax.persistence.EntityManager;
import javax.persistence.EntityManagerFactory;
import javax.persistence.Persistence;

import org.apache.tuscany.sdo.helper.HelperProviderImpl;

import com.bea.jpa.SDOEntityManager;
import com.bea.jpa.SDOEntityManagerFactory;

import commonj.sdo.DataObject;
import commonj.sdo.helper.DataFactory;
import commonj.sdo.helper.XMLHelper;
import commonj.sdo.helper.XSDHelper;
import commonj.sdo.impl.HelperProvider;

import junit.framework.TestCase;

/**
 * JUnit Tests to read a meta-model from XML Schema and create instances
 * according to the meta-model.
 * 
 * @author ppoddar
 *
 */
public class TestSDO extends TestCase {
private static final String RESOURCE_SDO_MODEL  = "po.xsd";
private static final String SDO_MODEL_NAMESPACE =
"http://www.example.com/PO";;

/**
 * Create a SDO MetaData Model from a XML Schema and populate
instances.
 * Assumes 'po.xsd' be available in classpath as resource.
 * 
 */
public void testCreateModel() {
InputStream xsdInputStream =
this.getClass().getClassLoader()

.getResourceAsStream(RESOURCE_SDO_MODEL);
assertNotNull(xsdInputStream);

String schemaLocation = null; 
List/*  */types =
XSDHelper.INSTANCE.define(xsdInputStream,
schemaLocation);
assertTrue(types != null && !types.isEmpty());
assertTrue(types.size() >= 2);

DataObject purchaseOrder = DataFactory.INSTANCE.create(
SDO_MODEL_NAMESPACE,
"PurchaseOrderType");

purchaseOrder.setString("orderDate", "1999-10-20");

DataObject shipTo =
purchaseOrder.createDataObject("shipTo");
shipTo.set("country", "US");
shipTo.set("name", "Alice Smith");
shipTo.set("street", "123 Maple Street");
shipTo.set("city", "Mill Valley");
shipTo.set("state", "CA");
shipTo.setString("zip", "90952");
DataObject billTo =
purchaseOrder.createDataObject("billTo");
billTo.set("country", "US");
billTo.set("name", "Robert Smith");
billTo.set("street", "8 Oak Avenue");
billTo.set("city", "Mill Valley");
billTo.set("state", "PA");
billTo.setString("zip", "95819");
purchaseOrder.set("comment", "Hurry, my lawn is going
wild!");

DataObject items =
purchaseOrder.createDataObject("items");

DataObject item1 = items.createDataObject("item");
item1.set("partNum", "872-AA");
item1.set("productName", "Lawnmower");
item1.setInt("quantity", 1);
item1.setString("USPrice", "148.95");
item1.set("comment", "Confirm this is electric");

DataObject item2 = items.createDataObject("item");
item2.set("partNum", "926-AA");
item2.set("productName", "Baby Monitor");
item2.setInt("quantity", 1);
item2.setString("USPrice", "39.98");
item2.setString("shipDate", "1999-05-21");

try {
OutputStream stream = System.err;
XMLHelper.INSTANCE.save(purchaseOrder,
SDO_MODEL_NAMESPACE,
"purchaseOrder", stream);
} catch (IOException e) {
e.printStackTrace();
fail();
}
}

}


===
XML Schema Definition: po.xsd

===
http://www.w3.org/2001/XMLSchema";
xmlns:po="http://www.example.com/PO";
targetNamespace="http://www.example.com/PO";>











































  

RE: How does one specify a Property as containment property in XML Schema?

[Pinaki Poddar]

Hello Kelvin,
  I did it to 'tuscany-dev@ws.apache.org'. In case the mailserver is
eating it up (our OpenJPA mailserver does), here it is again. Running
TestSDO with po.xsd causes the following:
  

java.lang.IllegalArgumentException: The property 'shipTo' of
'PurchaseOrderType' isn't a containment
at
org.apache.tuscany.sdo.util.DataObjectUtil.createDataObject(DataObjectUt
il.java:421)
at
org.apache.tuscany.sdo.util.DataObjectUtil.createDataObject(DataObjectUt
il.java:467)
at
org.apache.tuscany.sdo.impl.DataObjectImpl.createDataObject(DataObjectIm
pl.java:1195)
at test.TestSDO.testCreateModel(TestSDO.java:57)

Good news is I have continued with a workaround by constructing
USAddress instances via DataFactory and setting that to PurchaseOrder
property 'shipTo'/'billTo'. This does not imply containment but with
that workaround I can proceed to persist a DataObject into a database
via JPA. That is working.


Pinaki Poddar
972.834.2865

-Original Message-
From: kelvin goodson [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, July 03, 2007 3:23 AM
To: tuscany-dev@ws.apache.org
Subject: Re: How does one specify a Property as containment property in
XML Schema?

Hi Pinaki,
  can you please post your test code?
Regards, Kelvin.


On 03/07/07, Pinaki Poddar <[EMAIL PROTECTED]> wrote:
>
> Hi Fuhwei,
>   The types are parsed and registered OK. The part of the test that 
> verfies it, passes alright. The test fails while the registered types 
> are used to create instances.
>
>   Please find attached JUnitTest, the XML Schema model and the stack 
> trace.
>
> java.lang.IllegalArgumentException: The property 'shipTo' of 
> 'PurchaseOrderType' isn't a containment
>at
> org.apache.tuscany.sdo.util.DataObjectUtil.createDataObject(DataObject
> Ut
> il.java:421)
>at
> org.apache.tuscany.sdo.util.DataObjectUtil.createDataObject(DataObject
> Ut
> il.java:467)
>at
> org.apache.tuscany.sdo.impl.DataObjectImpl.createDataObject(DataObject
> Im
> pl.java:1195)
>at test.TestSDO.testCreateModel(TestSDO.java:57)
>
>
>
> Pinaki Poddar
> 972.834.2865
>
> -Original Message-
> From: Fuhwei Lwo [mailto:[EMAIL PROTECTED]
> Sent: Monday, July 02, 2007 4:32 PM
> To: tuscany-dev@ws.apache.org
> Subject: RE: How does one specify a Property as containment property 
> in XML Schema?
>
> Hi Pinaki,
>
> I think your XSDHelper.define() failed to register types for some 
> reason. Can you try this to see whether any types were registered?
>
> java.util.List types = XSDHelper.INSTANCE.define(fis, null);
>for (int i=0; iSystem.out.println("Type defined: " + types.get(i));
>}
>
> Normally, you should see PurchaseOrderType, USAddress, etc registered.
>
> Fuhwei
>
> Pinaki Poddar <[EMAIL PROTECTED]> wrote: Hello Fuhwei, I am following 
> your footstep! It is the same po.xsd I copied from your very readable 
> post
>
> http://www.ibm.com/developerworks/webservices/library/ws-sdoxmlschema/
> in
> dex.html
>
> except that it was missing a closing
>
> Thanks for your help.
>
>
> Pinaki Poddar
> 972.834.2865
>
> -Original Message-
> From: Fuhwei Lwo [mailto:[EMAIL PROTECTED]
> Sent: Monday, July 02, 2007 3:35 PM
> To: tuscany-dev@ws.apache.org
> Subject: Re: How does one specify a Property as containment property 
> in XML Schema?
>
> Hi Pinaki,
>
> What is the type of "shipTo" property? It needs to be a complex type.
> Can you post your XSD? Thanks.
>
> Fuhwei
>
>
> Pinaki Poddar
> wrote: Hello,
>
> How does one specify a Property as containment property in XML Schema?
>
>
> I was trying a simple example with a XML Schema (po.xsd) that had the 
> following snippet:
>
>
>
>
>
> XSDHelper.INSTANCE.define(...) works fine to construct the types from 
> po.xsd.
>
> However when the following is executed:
>
> 01: DataObject purchaseOrder =
> DataFactory.INSTANCE.create("http://www.example.com/PO";,
> "PurchaseOrderType");
> 02: DataObject shipTo = purchaseOrder.createDataObject("shipTo");
>
> It fails with
> java.lang.IllegalArgumentException: The property 'shipTo' of 
> 'PurchaseOrderType' isn't a containment  at 
> org.apache.tuscany.sdo.util.DataObjectUtil.createDataObject(DataObject
> Ut
> il.java:421)
> at
> org.apache.tuscany.sdo.util.DataObjectUtil.createDataObject(DataObject
> Ut
> il.java:467)
> at
> org.apache.tuscany.sdo.impl.DataObjectImpl.createDataObject(DataObject
> Im
> pl.java:1195)
> at test.TestModel.testInstance(TestModel.java:41)
>
> I am using tuscany-sdo-impl-1.0-incubating-beta1.jar.
>
>
> Pinaki Poddar
> 972.834.2865
>
>
> Notice:  This email message, together with any attachments, may 
> contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  
> affiliated entities,  that may be confidential,  proprietary,  
> copyrighted  and/or legally privileged, and is intended solely for the

> use of the individual or entity named in this message. If you are not 
> the intended recipient, and have received this message in error, 

Re: How does one specify a Property as containment property in XML Schema?

[kelvin goodson]

Hi Pinaki,
I'm not sure if we are not understanding each other here,  or whether
technology is conspiring against us,  but what I'd like to do is to execute
the test code you are running myself, so please could you paste the code of
your test program.
Regards,Kelvin.

On 03/07/07, Pinaki Poddar <[EMAIL PROTECTED]> wrote:


Hello Kelvin,
  I did it to 'tuscany-dev@ws.apache.org'. In case the mailserver is
eating it up (our OpenJPA mailserver does), here it is again. Running
TestSDO with po.xsd causes the following:


java.lang.IllegalArgumentException: The property 'shipTo' of
'PurchaseOrderType' isn't a containment
at
org.apache.tuscany.sdo.util.DataObjectUtil.createDataObject(DataObjectUt
il.java:421)
at
org.apache.tuscany.sdo.util.DataObjectUtil.createDataObject(DataObjectUt
il.java:467)
at
org.apache.tuscany.sdo.impl.DataObjectImpl.createDataObject(DataObjectIm
pl.java:1195)
at test.TestSDO.testCreateModel(TestSDO.java:57)

Good news is I have continued with a workaround by constructing
USAddress instances via DataFactory and setting that to PurchaseOrder
property 'shipTo'/'billTo'. This does not imply containment but with
that workaround I can proceed to persist a DataObject into a database
via JPA. That is working.


Pinaki Poddar
972.834.2865

-Original Message-
From: kelvin goodson [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 03, 2007 3:23 AM
To: tuscany-dev@ws.apache.org
Subject: Re: How does one specify a Property as containment property in
XML Schema?

Hi Pinaki,
  can you please post your test code?
Regards, Kelvin.


On 03/07/07, Pinaki Poddar <[EMAIL PROTECTED]> wrote:
>
> Hi Fuhwei,
>   The types are parsed and registered OK. The part of the test that
> verfies it, passes alright. The test fails while the registered types
> are used to create instances.
>
>   Please find attached JUnitTest, the XML Schema model and the stack
> trace.
>
> java.lang.IllegalArgumentException: The property 'shipTo' of
> 'PurchaseOrderType' isn't a containment
>at
> org.apache.tuscany.sdo.util.DataObjectUtil.createDataObject(DataObject
> Ut
> il.java:421)
>at
> org.apache.tuscany.sdo.util.DataObjectUtil.createDataObject(DataObject
> Ut
> il.java:467)
>at
> org.apache.tuscany.sdo.impl.DataObjectImpl.createDataObject(DataObject
> Im
> pl.java:1195)
>at test.TestSDO.testCreateModel(TestSDO.java:57)
>
>
>
> Pinaki Poddar
> 972.834.2865
>
> -Original Message-
> From: Fuhwei Lwo [mailto:[EMAIL PROTECTED]
> Sent: Monday, July 02, 2007 4:32 PM
> To: tuscany-dev@ws.apache.org
> Subject: RE: How does one specify a Property as containment property
> in XML Schema?
>
> Hi Pinaki,
>
> I think your XSDHelper.define() failed to register types for some
> reason. Can you try this to see whether any types were registered?
>
> java.util.List types = XSDHelper.INSTANCE.define(fis, null);
>for (int i=0; iSystem.out.println("Type defined: " + types.get(i));
>}
>
> Normally, you should see PurchaseOrderType, USAddress, etc registered.
>
> Fuhwei
>
> Pinaki Poddar <[EMAIL PROTECTED]> wrote: Hello Fuhwei, I am following
> your footstep! It is the same po.xsd I copied from your very readable
> post
>
> http://www.ibm.com/developerworks/webservices/library/ws-sdoxmlschema/
> in
> dex.html
>
> except that it was missing a closing
>
> Thanks for your help.
>
>
> Pinaki Poddar
> 972.834.2865
>
> -Original Message-
> From: Fuhwei Lwo [mailto:[EMAIL PROTECTED]
> Sent: Monday, July 02, 2007 3:35 PM
> To: tuscany-dev@ws.apache.org
> Subject: Re: How does one specify a Property as containment property
> in XML Schema?
>
> Hi Pinaki,
>
> What is the type of "shipTo" property? It needs to be a complex type.
> Can you post your XSD? Thanks.
>
> Fuhwei
>
>
> Pinaki Poddar
> wrote: Hello,
>
> How does one specify a Property as containment property in XML Schema?
>
>
> I was trying a simple example with a XML Schema (po.xsd) that had the
> following snippet:
>
>
>
>
>
> XSDHelper.INSTANCE.define(...) works fine to construct the types from
> po.xsd.
>
> However when the following is executed:
>
> 01: DataObject purchaseOrder =
> DataFactory.INSTANCE.create("http://www.example.com/PO";,
> "PurchaseOrderType");
> 02: DataObject shipTo = purchaseOrder.createDataObject("shipTo");
>
> It fails with
> java.lang.IllegalArgumentException: The property 'shipTo' of
> 'PurchaseOrderType' isn't a containment  at
> org.apache.tuscany.sdo.util.DataObjectUtil.createDataObject(DataObject
> Ut
> il.java:421)
> at
> org.apache.tuscany.sdo.util.DataObjectUtil.createDataObject(DataObject
> Ut
> il.java:467)
> at
> org.apache.tuscany.sdo.impl.DataObjectImpl.createDataObject(DataObject
> Im
> pl.java:1195)
> at test.TestModel.testInstance(TestModel.java:41)
>
> I am using tuscany-sdo-impl-1.0-incubating-beta1.jar.
>
>
> Pinaki Poddar
> 972.834.2865
>
>
> Notice:  This email message, together with any attachments, may
> contain information  of  BEA Systems,  Inc

RE: How does one specify a Property as containment property in XML Schema?

[Pinaki Poddar]

I switched to EMF core API. The same error. Looks like Tuscany SDO is
wrapping EMF core -- is that right?
 


Pinaki Poddar
972.834.2865

-Original Message-
From: kelvin goodson [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, July 03, 2007 3:54 AM
To: tuscany-dev@ws.apache.org
Subject: Re: How does one specify a Property as containment property in
XML Schema?

Pinaki,
  perfect, thanks (yes, the attachments are stripped by the list),  will
try them out soon.
Kelvin

On 03/07/07, Pinaki Poddar <[EMAIL PROTECTED]> wrote:
>
> Are you not seeing the e-mail attachements TestSDO.java and po.xsd?
>
> In any case, here they are
> = TestSDO.java 
> ==
>
> package test;
>
> import java.io.IOException;
> import java.io.InputStream;
> import java.io.OutputStream;
> import java.util.List;
>
> import javax.persistence.EntityManager; import 
> javax.persistence.EntityManagerFactory;
> import javax.persistence.Persistence;
>
> import org.apache.tuscany.sdo.helper.HelperProviderImpl;
>
> import com.bea.jpa.SDOEntityManager;
> import com.bea.jpa.SDOEntityManagerFactory;
>
> import commonj.sdo.DataObject;
> import commonj.sdo.helper.DataFactory; import 
> commonj.sdo.helper.XMLHelper; import commonj.sdo.helper.XSDHelper; 
> import commonj.sdo.impl.HelperProvider;
>
> import junit.framework.TestCase;
>
> /**
> * JUnit Tests to read a meta-model from XML Schema and create 
> instances
> * according to the meta-model.
> *
> * @author ppoddar
> *
> */
> public class TestSDO extends TestCase {
> private static final String RESOURCE_SDO_MODEL  = "po.xsd";
> private static final String SDO_MODEL_NAMESPACE = 
> "http://www.example.com/PO";;
>
> /**
>  * Create a SDO MetaData Model from a XML Schema and populate 
> instances.
>  * Assumes 'po.xsd' be available in classpath as resource.
>  *
>  */
> public void testCreateModel() {
> InputStream xsdInputStream =
> this.getClass().getClassLoader()
>
> .getResourceAsStream(RESOURCE_SDO_MODEL);
> assertNotNull(xsdInputStream);
>
> String schemaLocation = null;
> List/*  */types = 
> XSDHelper.INSTANCE.define(xsdInputStream,
> schemaLocation);
> assertTrue(types != null && !types.isEmpty());
> assertTrue(types.size() >= 2);
>
> DataObject purchaseOrder =
DataFactory.INSTANCE.create(
> SDO_MODEL_NAMESPACE, 
> "PurchaseOrderType");
>
> purchaseOrder.setString("orderDate", "1999-10-20");
>
> DataObject shipTo =
> purchaseOrder.createDataObject("shipTo");
> shipTo.set("country", "US");
> shipTo.set("name", "Alice Smith");
> shipTo.set("street", "123 Maple Street");
> shipTo.set("city", "Mill Valley");
> shipTo.set("state", "CA");
> shipTo.setString("zip", "90952");
> DataObject billTo =
> purchaseOrder.createDataObject("billTo");
> billTo.set("country", "US");
> billTo.set("name", "Robert Smith");
> billTo.set("street", "8 Oak Avenue");
> billTo.set("city", "Mill Valley");
> billTo.set("state", "PA");
> billTo.setString("zip", "95819");
> purchaseOrder.set("comment", "Hurry, my lawn is going 
> wild!");
>
> DataObject items =
> purchaseOrder.createDataObject("items");
>
> DataObject item1 = items.createDataObject("item");
> item1.set("partNum", "872-AA");
> item1.set("productName", "Lawnmower");
> item1.setInt("quantity", 1);
> item1.setString("USPrice", "148.95");
> item1.set("comment", "Confirm this is electric");
>
> DataObject item2 = items.createDataObject("item");
> item2.set("partNum", "926-AA");
> item2.set("productName", "Baby Monitor");
> item2.setInt("quantity", 1);
> item2.setString("USPrice", "39.98");
> item2.setString("shipDate", "1999-05-21");
>
> try {
> OutputStream stream = System.err;
> XMLHelper.INSTANCE.save(purchaseOrder,
> SDO_MODEL_NAMESPACE,
> "purchaseOrder", stream);
> } catch (IOException e) {
> e.printStackTrace();
> fail();
> }
> }
>
> }
>
> ==
> ==
> ===
> XML Schema Definition: po.xsd
> ==
> ==
> ===
> http://www.w3.org/2001/

Re: How does one specify a Property as containment property in XML Schema?

[kelvin goodson]

Hi Pinaki,
 can you please post your test code?
Regards, Kelvin.


On 03/07/07, Pinaki Poddar <[EMAIL PROTECTED]> wrote:


Hi Fuhwei,
  The types are parsed and registered OK. The part of the test that
verfies it, passes alright. The test fails while the registered types
are used to create instances.

  Please find attached JUnitTest, the XML Schema model and the stack
trace.

java.lang.IllegalArgumentException: The property 'shipTo' of
'PurchaseOrderType' isn't a containment
   at
org.apache.tuscany.sdo.util.DataObjectUtil.createDataObject(DataObjectUt
il.java:421)
   at
org.apache.tuscany.sdo.util.DataObjectUtil.createDataObject(DataObjectUt
il.java:467)
   at
org.apache.tuscany.sdo.impl.DataObjectImpl.createDataObject(DataObjectIm
pl.java:1195)
   at test.TestSDO.testCreateModel(TestSDO.java:57)



Pinaki Poddar
972.834.2865

-Original Message-
From: Fuhwei Lwo [mailto:[EMAIL PROTECTED]
Sent: Monday, July 02, 2007 4:32 PM
To: tuscany-dev@ws.apache.org
Subject: RE: How does one specify a Property as containment property in
XML Schema?

Hi Pinaki,

I think your XSDHelper.define() failed to register types for some
reason. Can you try this to see whether any types were registered?

java.util.List types = XSDHelper.INSTANCE.define(fis, null);
   for (int i=0; i wrote: Hello Fuhwei,
I am following your footstep! It is the same po.xsd I copied from your
very readable post

http://www.ibm.com/developerworks/webservices/library/ws-sdoxmlschema/in
dex.html

except that it was missing a closing

Thanks for your help.


Pinaki Poddar
972.834.2865

-Original Message-
From: Fuhwei Lwo [mailto:[EMAIL PROTECTED]
Sent: Monday, July 02, 2007 3:35 PM
To: tuscany-dev@ws.apache.org
Subject: Re: How does one specify a Property as containment property in
XML Schema?

Hi Pinaki,

What is the type of "shipTo" property? It needs to be a complex type.
Can you post your XSD? Thanks.

Fuhwei


Pinaki Poddar
wrote: Hello,

How does one specify a Property as containment property in XML Schema?


I was trying a simple example with a XML Schema (po.xsd) that had the
following snippet:





XSDHelper.INSTANCE.define(...) works fine to construct the types from
po.xsd.

However when the following is executed:

01: DataObject purchaseOrder =
DataFactory.INSTANCE.create("http://www.example.com/PO";,
"PurchaseOrderType");
02: DataObject shipTo = purchaseOrder.createDataObject("shipTo");

It fails with
java.lang.IllegalArgumentException: The property 'shipTo' of
'PurchaseOrderType' isn't a containment  at
org.apache.tuscany.sdo.util.DataObjectUtil.createDataObject(DataObjectUt
il.java:421)
at
org.apache.tuscany.sdo.util.DataObjectUtil.createDataObject(DataObjectUt
il.java:467)
at
org.apache.tuscany.sdo.impl.DataObjectImpl.createDataObject(DataObjectIm
pl.java:1195)
at test.TestModel.testInstance(TestModel.java:41)

I am using tuscany-sdo-impl-1.0-incubating-beta1.jar.


Pinaki Poddar
972.834.2865


Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.

Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual or
entity named in this message. If you are not the intended recipient, and
have received this message in error, please immediately return this by email
and then delete it.

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

[jira] Closed: (TUSCANY-1406) Component type file not resolved correctly in implementation.osgi

[ant elder (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

ant elder closed TUSCANY-1406.
--

Resolution: Fixed

Applied and has fixed so test and sample work fine now. Thanks for the patch 
Rajini.

> Component type file not resolved correctly in implementation.osgi
> -
>
> Key: TUSCANY-1406
> URL: https://issues.apache.org/jira/browse/TUSCANY-1406
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA OSGi Integration
>Reporter: Rajini Sivaram
>Priority: Minor
> Attachments: tuscany-implementation-osgi-patch.txt
>
>
> The OSGi implementation is no longer resolving the component type file 
> correctly. Tuscany is now using a relative path name for the component type 
> file URI (it used to store an absolute path before). The OSGi implementation 
> should also use a relative path so that it resolves the file correctly. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

Re: [jira] Updated: (TUSCANY-1382) Minor fixes to OSGi declarative services support and additional tests

[ant elder]

The OSGi implementation and sample are building fine now so I've added them
to the main Tuscany build. I've not yet added the itest to the main build as
I'm getting intermittent failures when i run them. Mostly NPE's but its only
sometimes and not always the same itest that fails so I'm not sure whats
going on. Could others try a few times and see if they see any problems?

Failures are things like:

test(supplychain.wiring.DSWiring2TestCase)  Time elapsed: 0.828 sec  <<<
ERROR!
java.lang.NullPointerException
   at
org.apache.tuscany.sca.implementation.osgi.invocation.OSGiInstanceWrapper.getInstance
(OSGiInstanceWrapper.java:73)
   at
org.apache.tuscany.sca.implementation.osgi.invocation.OSGiTargetInvoker.invokeTarget
(OSGiTargetInvoker.java:115)
   at
org.apache.tuscany.sca.implementation.osgi.invocation.OSGiTargetInvoker.invoke
(OSGiTargetInvoker.java:164)
   at
org.apache.tuscany.sca.core.invocation.AbstractInvocationHandler.invoke(
AbstractInvocationHandler.java:84)
   at
org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(
JDKInvocationHandler.java:73)
   at $Proxy9.hasOutstandingOrders(Unknown Source)
   at supplychain.SupplyChainTestCase.test(SupplyChainTestCase.java:66)

  ...ant

On 6/26/07, Rajini Sivaram (JIRA)  wrote:



 [
https://issues.apache.org/jira/browse/TUSCANY-1382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel]

Rajini Sivaram updated TUSCANY-1382:


Attachment: itest-osgi-implementation.zip
sample-osgi-supplychain-patch.txt
tuscany-implementation-osgi-patch.txt

tuscany-implementation-osgi-patch.txt contains patches to
modules/implementation-osgi.

sample-osgi-supplychain-patch.txt contains patches to
samples/osgi-supplychain (modified for declarative services).

itest-osgi-implementation.zip contains integration tests for
osgi-implementation.

> Minor fixes to OSGi declarative services support and additional tests
> -
>
> Key: TUSCANY-1382
> URL: https://issues.apache.org/jira/browse/TUSCANY-1382
> Project: Tuscany
>  Issue Type: Improvement
>  Components: Java SCA OSGi Integration
>Reporter: Rajini Sivaram
> Attachments: itest-osgi-implementation.zip,
sample-osgi-supplychain-patch.txt, tuscany-implementation-osgi-patch.txt
>
>
> Attached are patches to osgi-implementation support.
> Changes include improved support for declarative services and versioning
and changes to the directory structure to make it in line with
implementation-java.
> Integration tests are included in the zip file.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

Re: The complete patch for TUSCANY-1341 is available

[Simon Nash]

Thanks to all who provided feedback.  I plan to go with approach "3"
for all the provider SPI additions.  So there will be new interfaces
ReferenceBindingProvider2 and ServiceBindingProvider2 that extend
ReferenceBindingProvider and ServiceBindingProvider respectively,
and all the new methods that I had previously addded to
ReferenceBindingProvider and ServiceBindingProvider will be part of
ReferenceBindingProvider2 and ServiceBindingProvider2 instead.

If anyone does not think this is the right approach, please speak up
now before I go further down this path.  Thanks.

  Simon

Venkata Krishnan wrote:


Hi,

I really like the approach mentioned under '3'.  While the SPIs might
undergo changes sometime, this is probably too early, especially now 
that we

have promised for its stability from Release 0.90.  Thats just about my
opinion.  Thanks

- Venkat

On 7/2/07, Simon Nash <[EMAIL PROTECTED]> wrote:



I'd like to get some other views on this before I spend a lot of
time reworking this patch.  Please see my comments inline below.

   Simon

ant elder wrote:

> On 7/2/07, Simon Nash <[EMAIL PROTECTED]> wrote:
>
>>
>> I am reconsidering the changes made in stage 2 of this patch, which
>> added two new methods to the Binding SPI interface.
>>
>> I made these changes for the reasons stated in
>>   http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19305.html
>> and
>>   http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19308.html
>> These methods allow bindings to be marked as either callback or
>> forward bindings.  This allows callback binding semantics to be
>> supported correctly with relatively little change to the core runtime.
>>
>> Unfortunately these is a flip side to these benefits.  Adding these
>> methods changes the current published stable Binding SPI, and
>> (probably worse) introduces "pollution" of the Binding SPI to carry
>> information that is there for the convenience of the core runtime,
>> rather than an intrinsic part of the binding semantics.
>>
>> The alternative is to keep the Binding SPI as it was, and make more
>> extensive changes in the core runtime to use the more correct version
>> of the model as proposed in
>>   http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19305.html
>>
>> I will look at the impact to the core runtime of the alternative
>> approach that keeps the Binding SPI unchanged and I will post my
>> findings back to this list.
>>
>> This discussion only affects the Binding SPI changes in stage 2 of
>> the patch.  It does not affect the provider SPI changes in stage 1
>> of the patch.
>>
>> I'd be interested in any comments on the above or on any other aspects
>> of this patch.
>
>
>
> It sounds good the binding SPI can remain unchanged, it also sounded
like
> from the other thread that it should be possible to avoid some of the
other
> SPI changes in "stage 1" as well which would be good.
>
I'm getting on quite well with reworking the code that currently depends
on the changes to the binding SPI.  There's one slightly ugly area, but I
think I'll be able to get around it without too much hackery.

The provider SPI changes can't be avoided, though they can be deferred.
In the short term this may seem attractive because it gets something
working with less new code.  However, the total amount of work will be
greater since my patch already contains all the necessary collateral
changes for code that's impacted by the provider SPI changes.  I would
have to do significant rework on the patch to remove these for now, then
repeat much of this work to recreate a smilar set of collateral changes
when we finally adopt these new SPIs.

> How about trying to get as much as this going with as few changes to 
the

> existing SPI as possible for now even if doing that requires some less
then
> perfect code in the runtime impl and axis2 binding, and then once we
have
> call backs and async working well with axis2 and ws-addressing and
ideally
> at least another extension or two then look at what the best way to
change
> the SPIs might be?
>
I think there's pretty much a straight trade-off between how many of
these SPI changes are deferred and the amount of temporary workaround
code that would be needed in the core to compensate for this.

Let's take the provider SPI changes one by one, in approximate order of
increasing difficulty for working around not having them.

1. Not including the change to remove the redundant isCallback parameter
from ReferenceBindingProvider.createInvoker() doesn't cause any
significant problems in the core.  The core can always pass the
meaningless extra parameter, and the providers can always ignore it.
This does incur the collateral rework costs that I mentioned above
for when we get around to cleaning this one up.

2. Not including the supportsAsyncOneWayInvocation() methods on
ReferenceBindingProvider and ServiceBindingProvider presents a bit
more of a challenge.  One possibility is to create a new mar

Re: SCA 0.92 release?

[Simon Nash]

I'd like to restart the earlier discussion in
 http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19224.html
about whether implementation.das and implementation.data should be
packaged with SCA releases or DAS releases.

I think it's better for these to be packaged with DAS releases as
the code will be more aligned with evolving DAS capabilities than
with evolving SCA capabilities.  This will allow new features to be
added as and when it makes sense for DAS to move up to support them.

  Simon

Luciano Resende wrote:


Now that we are going to have a DAS release out, I'd like to plan to
have implementation.das and implementation.data available for the next
release.

I also like to have some improvements to the Contribution Services,
such as import/export and other scenarios that have been described on
the list recently. I'll update the wiki with these items.

On 7/2/07, haleh mahbod <[EMAIL PROTECTED]> wrote:


Posting to tuscany-user list as well to get input.

Any real world scenarios/samples that can be shared by users? It would be
great if we could start building a library of tips and real usage
examples..  a knowledge base.

Thanks
Haleh

On 7/2/07, Simon Laws <[EMAIL PROTECTED]> wrote:
>
> On 7/2/07, ant elder <[EMAIL PROTECTED]> wrote:
> >
> > On 7/2/07, Simon Laws <[EMAIL PROTECTED]> wrote:
> > >
> > > On 7/2/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
> > > >
> > > > Hi,
> > > >
> > > > I am looking at the Policy Framework and shall update the wiki on
> the
> > > > specifics soon.  Once this is done to some level, I'd also 
like to

> > help
> > > a
> > > > bit with the ws-* things (may be WS-Security to start with) 
that Ant

> > has
> > > > listed on the wiki page.
> > > >
> > > > - Venkat
> > > >
> > > > On 6/30/07, ant elder <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > With the SCA 0.91 release now being voted on how about 
starting on

> > > 0.92?
> > > > >
> > > > > I've already been adding some things I'm interested in getting
> done
> > to
> > > > the
> > > > > next release wiki page -
> > > > >
> > > > >
> > > >
> > >
> >
> 
http://cwiki.apache.org/confluence/display/TUSCANY/Java+SCA+Next+Release+Contents- 


> > > > > so far thats mainly related to improving web services
> functionality.
> > > > >
> > > > > So anyone else interested in helping with an 0.92 release or 
have

> > any
> > > > > function they'd like to suggest or add to the wiki page? How 
does

> > > aiming
> > > > > for
> > > > > getting it done 4 - 6 weeks again sound?
> > > > >
> > > > >...ant
> > > > >
> > >
> > >
> > > The above link has an extrenuous "-" on the end. Taking that off 
gets

> me
> > > to
> > > the page. Can we move this information across the to the new wiki
> space
> > (
> > > http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Home) so 
that

> > > everyone (including non committers) can add to it?
> > >
> > > I'm working on the next phase of the distributed runtime which I 
want

> to
> > > get
> > > into the next release. This involves a few items.
> > >
> > > SCA Binding
> > > Topology model
> > > Distributed domain
> > > Node implementation
> > > Management assembly
> > >
> > > Also I need some of the ws items, in particular the ability to run
> > without
> > > wsdl, so can help out there.
> > >
> > > We need to do something about logging and events to improvide 
runtime

> > > usability. We've talked about it before but not done anything yet.
> Ties
> > > into
> > > the management assembly.
> > >
> > > I'd also like to see the JMS binding in the release but can't 
commit

> to
> > > doing lots more work on including spec features. It's been working
> fine
> > > for
> > > me in my limited synchronous/rpc model. If I get time I'll take 
a look

> > to
> > > see what it will take to add minimum asynch support but if 
anyone else

> > > fancies having a go at this then it's a good way to learn about
> Tuscany
> > > extensions.
> >
> >
> > All these sound good, but its starting to sound a lot to get done in
> just
> > a
> > few weeks. How does the suggesting timeframe of 4 or so weeks sound?
> >
> > We'd talked once about having a release specifically targeting things
> like
> > logging, events, and error handling. I'd still like to do that, if
> anyone
> > wants to start now thats great but I doubt I'd have much time to help
> this
> > release.
> >
> >...ant
> >
> I think 4 weeks is a bit too short. Given that we are getting into 
holday

> season I like the sound of 6 weeks better.
>
> I agree there is a lot there but in the spirit of your WS list I wasn't
> proposing that all of it gets done. I do think we need to make a 
start on
> the logging/errors sooner rather than later though even if it 
doesn't get
> into the next release. I'll offer my effort to help move it along 
once the

> distributed work starts drawing to a close.
>
> Simon
>





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

Extending the runtime and domain models

[Simon Laws]

The runtime classes (ReallySmallRuntime and ReallySmallRuntimeBuilder) and
the EmbeddedSCADomain implementation are pretty well locked down in terms of
overriding their members and functions. I had to make copies of most of this
function to create the distributed runtime and domain. Can we loosen this up
a bit so that these classes can be extended?

Simon

[jira] Resolved: (TUSCANY-1393) ClassCastException saving codegen-based DataGraph with ChangeSummary containing an xsd:int

[Kelvin Goodson (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kelvin Goodson resolved TUSCANY-1393.
-

Resolution: Fixed

Thanks for the fix Ron.

> ClassCastException saving codegen-based DataGraph with ChangeSummary 
> containing an xsd:int
> --
>
> Key: TUSCANY-1393
> URL: https://issues.apache.org/jira/browse/TUSCANY-1393
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Implementation
>Affects Versions: Java-SDO-Next
>Reporter: Ron Gavlin
>Priority: Critical
> Attachments: sdo-TUSCANY-1393.patch
>
>
> Please add the following test case to 
> sdo\tools\src\test\java\org\apache\tuscany\sdo\test\ChangeSummaryGenTestCase.java.
>  The new test method currently generates a ClassCastException when an Integer 
> is expected and a Double is provided. I have listed the stacktrace below:
> 
> public void testChangeSummaryOnDataGraphWithInt() throws Exception {
>   
>   HelperContext hc = HelperProvider.getDefaultContext();
>   CustomerFactory factory = CustomerFactory.INSTANCE;
>   factory.register(hc);
>   Customer customer = factory.createCustomer();
>   Account account = factory.createAccount();
>   customer.setAccount(account);
>   DataObject customerDO = (DataObject) customer; 
>   DataGraph dg = SDOUtil.createDataGraph();
>   SDOUtil.setRootObject(dg, customerDO);
>   dg.getChangeSummary().beginLogging();
>   dg.getRootObject().getDataObject(0).delete();
>   ByteArrayOutputStream baos = new ByteArrayOutputStream();
>   SDOUtil.saveDataGraph(dg, baos, null);
> }
> 
> testChangeSummaryOnDataGraphWithInt(org.apache.tuscany.sdo.test.ChangeSummaryGenTestCase)
> java.lang.ClassCastException: java.lang.Double
>   at 
> org.apache.tuscany.sdo.model.impl.ModelFactoryImpl.convertIntToString(ModelFactoryImpl.java:2079)
>   at 
> org.apache.tuscany.sdo.model.impl.ModelFactoryImpl.convertToString(ModelFactoryImpl.java:321)
>   at 
> org.apache.tuscany.sdo.impl.FactoryBase$SDOEFactoryImpl.convertToString(FactoryBase.java:284)
>   at 
> org.eclipse.emf.ecore.util.EcoreUtil.convertToString(EcoreUtil.java:2994)
>   at 
> org.eclipse.emf.ecore.change.impl.FeatureChangeImpl.getDataValue(FeatureChangeImpl.java:228)
>   at 
> org.eclipse.emf.ecore.change.impl.FeatureChangeImpl.eIsSet(FeatureChangeImpl.java:771)
>   at 
> org.eclipse.emf.ecore.impl.BasicEObjectImpl.eIsSet(BasicEObjectImpl.java:818)
>   at 
> org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveFeatures(XMLSaveImpl.java:1107)
>   at 
> org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElementID(XMLSaveImpl.java:2462)
>   at 
> org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElement(XMLSaveImpl.java:1036)
>   at 
> org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElement(XMLSaveImpl.java:922)
>   at 
> org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveContainedMany(XMLSaveImpl.java:2182)
>   at 
> org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveFeatures(XMLSaveImpl.java:1390)
>   at 
> org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElementID(XMLSaveImpl.java:2462)
>   at 
> org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElement(XMLSaveImpl.java:1036)
>   at 
> org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElement(XMLSaveImpl.java:922)
>   at 
> org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveContainedMany(XMLSaveImpl.java:2182)
>   at 
> org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveFeatures(XMLSaveImpl.java:1390)
>   at 
> org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElementID(XMLSaveImpl.java:2462)
>   at 
> org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.writeTopObject(XMLSaveImpl.java:620)
>   at 
> org.apache.tuscany.sdo.util.DataGraphResourceFactoryImpl$DataGraphResourceImpl$SaveImpl.traverse(DataGraphResourceFactoryImpl.java:382)
>   at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.save(XMLSaveImpl.java:233)
>   at 
> org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.doSave(XMLResourceImpl.java:203)
>   at 
> org.eclipse.emf.ecore.resource.impl.ResourceImpl.save(ResourceImpl.java:993)
>   at 
> org.apache.tuscany.sdo.helper.SDOHelperImpl.saveDataGraph(SDOHelperImpl.java:201)
>   at org.apache.tuscany.sdo.api.SDOUtil.saveDataGraph(SDOUtil.java:158)
>   at 
> org.apache.tuscany.sdo.test.ChangeSummaryGenTestCase.testChangeSummaryOnDataGraphWithInt(ChangeSummaryGenTestCase.java:128)
>   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)
>   a

[jira] Updated: (TUSCANY-1317) Provide a way to set default XML load options to be used during Java deserialization

[Amita Vadhavkar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amita Vadhavkar updated TUSCANY-1317:
-

Attachment: 1317.patch

Attached clean patch for JIRA "1317.patch" dated July 3, this does not have any 
code from JIRA 1391 as well as all commented code removed (which was there due 
to restructuring of HelperContext<->Helpers relationship)

Reason for changes to existing test cases during JIRA 1317 to pass 
XML_LOAD_SCHEMA as FALSE explicitly is - Before this JIRA, when no option was 
passed, default assumed was FALSE, and the existing test cases passed even 
though there were MalFormedURL in the test documents. With default to TRUE 
now, the processSchemaLocation option in EMF is set to TRUE and the 
MalformedURLs are not ignored.

Say, in XMLDocumentTestCase.testSchemaLocation() - if no FALSE is sent, it 
takes path of TRUE as that is the default now. In this, in 
SDOXMLResourceImpl.doLoad() {
...
super.doLoad(inputSource, options);
}

the call to super.doLoad() throws the below exception, as due to default true, 
xmlOptions.setProcessSchemaLocation(true); takes place.


java.net.MalformedURLException
at java.net.URL.(URL.java:601)
at java.net.URL.(URL.java:464)
at java.net.URL.(URL.java:413)
at 
com.sun.org.apache.xerces.internal.impl.XMLEntityManager.setupCurrentEntity(XMLEntityManager.java:968)
at 
com.sun.org.apache.xerces.internal.impl.XMLVersionDetector.determineDocVersion(XMLVersionDetector.java:184)
at 
com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:798)
at 
com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:764)
at 
com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:148)
at 
com.sun.org.apache.xerces.internal.parsers.DOMParser.parse(DOMParser.java:250)
at 
com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl.java:292)
at 
org.eclipse.xsd.util.XSDResourceImpl.getDocument(XSDResourceImpl.java:335)
at 
org.eclipse.xsd.util.XSDResourceImpl.getDocument(XSDResourceImpl.java:372)
at org.eclipse.xsd.util.XSDResourceImpl.doLoad(XSDResourceImpl.java:680)
at org.eclipse.xsd.util.XSDResourceImpl.load(XSDResourceImpl.java:617)
at 
org.apache.tuscany.sdo.helper.XSDHelperImpl.define(XSDHelperImpl.java:296)
at 
org.apache.tuscany.sdo.helper.XSDHelperImpl.define(XSDHelperImpl.java:286)
at 
org.apache.tuscany.sdo.util.resource.SDOXMLResourceImpl$5.generate(SDOXMLResourceImpl.java:532)
at 
org.eclipse.emf.ecore.xmi.impl.XMLHandler.processSchemaLocations(XMLHandler.java:1462)
at 
org.apache.tuscany.sdo.util.resource.SDOXMLResourceImpl$SDOXMLLoadImpl$XmlHandler.handleTopLocations(SDOXMLResourceImpl.java:264)
at 
org.eclipse.emf.ecore.xmi.impl.XMLHandler.createObjectByType(XMLHandler.java:1142)
at 
org.eclipse.emf.ecore.xmi.impl.XMLHandler.createTopObject(XMLHandler.java:1247)
at 
org.eclipse.emf.ecore.xmi.impl.XMLHandler.processElement(XMLHandler.java:883)
at 
org.eclipse.emf.ecore.xmi.impl.XMLHandler.startElement(XMLHandler.java:866)
at 
org.eclipse.emf.ecore.xmi.impl.XMLHandler.startElement(XMLHandler.java:627)
at 
org.apache.tuscany.sdo.util.resource.SDOXMLResourceImpl$SDOXMLLoadImpl$XmlHandler.startElement(SDOXMLResourceImpl.java:364)
at 
com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.startElement(AbstractSAXParser.java:533)
at 
com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.scanStartElement(XMLNSDocumentScannerImpl.java:330)
at 
com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl$NSContentDispatcher.scanRootElementHook(XMLNSDocumentScannerImpl.java:779)
at 
com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(XMLDocumentFragmentScannerImpl.java:1794)
at 
com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:368)
at 
com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:834)
at 
com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:764)
at 
com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:148)
at 
com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1242)
at javax.xml.parsers.SAXParser.parse(SAXParser.java:375)
at org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.load(XMLLoadImpl.java:268)
at 
org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.doLoad(XMLResourceImpl.java:666)
at 
org.apache.tuscany.sdo.util.resource.SDOXMLResourceImpl.doLoad(SDOXMLResourceImpl.java:546)
a

[jira] Commented: (TUSCANY-1342) Component-level not supported

[Scott Kurz (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-1342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12509830
 ] 

Scott Kurz commented on TUSCANY-1342:
-

Is this as simple as modifying method:boolean match(Operation, Method)
to check if the operation is Remotable via  
operation.getInterface().isRemotable()

If it is remotable, matching the method names is enough and if not we can fall 
through to, as before, look at the physical types.

I don't have the latest code building and running or I'd test this out and 
attach a patch.

> Component-level  not supported
> --
>
> Key: TUSCANY-1342
> URL: https://issues.apache.org/jira/browse/TUSCANY-1342
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Core Runtime
>Affects Versions: Java-SCA-0.90
>Reporter: Scott Kurz
>
> See thread:
> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg18780.html
> Something like this does not work:
>  
> 
> 
> 
> < binding.ws wsdlElement="..."/>
> 
>  

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Updated: (TUSCANY-1391) Provide capability to load and save XML with unknown features

[Amita Vadhavkar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amita Vadhavkar updated TUSCANY-1391:
-

Attachment: JIRA1391Design.txt
1391.patch

Attched clean patch "1391.patch" dated July 3, this does not have any code from 
JIRA 1317.


> Provide capability to load and save XML with unknown features
> -
>
> Key: TUSCANY-1391
> URL: https://issues.apache.org/jira/browse/TUSCANY-1391
> Project: Tuscany
>  Issue Type: Improvement
>  Components: Java SDO Implementation
>Affects Versions: Java-SDO-1.0
>Reporter: Amita Vadhavkar
> Attachments: 1391.patch, 1391.patch, JIRA1391Design.txt, 
> JIRA1391Design.txt
>
>
> expose XMLResource.OPTION_RECORD_UNKNOWN_FEATURE through tuscany-sdo-impl

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

Re: How does one specify a Property as containment property in XML Schema?

[kelvin goodson]

Pinaki,

there are errors in the schema you are using.  If you remove the ":po" from
xmlns:po="http://www.example.com/PO"; and remove "po:" from the rest of the
file,  when used in referencing type or element definitions,  then your test
code succeeds.

Regards,Kelvin.


Regards, Kelvin.

On 03/07/07, Pinaki Poddar <[EMAIL PROTECTED]> wrote:


I switched to EMF core API. The same error. Looks like Tuscany SDO is
wrapping EMF core -- is that right?



Pinaki Poddar
972.834.2865

-Original Message-
From: kelvin goodson [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 03, 2007 3:54 AM
To: tuscany-dev@ws.apache.org
Subject: Re: How does one specify a Property as containment property in
XML Schema?

Pinaki,
  perfect, thanks (yes, the attachments are stripped by the list),  will
try them out soon.
Kelvin

On 03/07/07, Pinaki Poddar <[EMAIL PROTECTED]> wrote:
>
> Are you not seeing the e-mail attachements TestSDO.java and po.xsd?
>
> In any case, here they are
> = TestSDO.java
> ==
>
> package test;
>
> import java.io.IOException;
> import java.io.InputStream;
> import java.io.OutputStream;
> import java.util.List;
>
> import javax.persistence.EntityManager; import
> javax.persistence.EntityManagerFactory;
> import javax.persistence.Persistence;
>
> import org.apache.tuscany.sdo.helper.HelperProviderImpl;
>
> import com.bea.jpa.SDOEntityManager;
> import com.bea.jpa.SDOEntityManagerFactory;
>
> import commonj.sdo.DataObject;
> import commonj.sdo.helper.DataFactory; import
> commonj.sdo.helper.XMLHelper; import commonj.sdo.helper.XSDHelper;
> import commonj.sdo.impl.HelperProvider;
>
> import junit.framework.TestCase;
>
> /**
> * JUnit Tests to read a meta-model from XML Schema and create
> instances
> * according to the meta-model.
> *
> * @author ppoddar
> *
> */
> public class TestSDO extends TestCase {
> private static final String RESOURCE_SDO_MODEL  = "po.xsd";
> private static final String SDO_MODEL_NAMESPACE =
> "http://www.example.com/PO";;
>
> /**
>  * Create a SDO MetaData Model from a XML Schema and populate
> instances.
>  * Assumes 'po.xsd' be available in classpath as resource.
>  *
>  */
> public void testCreateModel() {
> InputStream xsdInputStream =
> this.getClass().getClassLoader()
>
> .getResourceAsStream(RESOURCE_SDO_MODEL);
> assertNotNull(xsdInputStream);
>
> String schemaLocation = null;
> List/*  */types =
> XSDHelper.INSTANCE.define(xsdInputStream,
> schemaLocation);
> assertTrue(types != null && !types.isEmpty());
> assertTrue(types.size() >= 2);
>
> DataObject purchaseOrder =
DataFactory.INSTANCE.create(
> SDO_MODEL_NAMESPACE,
> "PurchaseOrderType");
>
> purchaseOrder.setString("orderDate", "1999-10-20");
>
> DataObject shipTo =
> purchaseOrder.createDataObject("shipTo");
> shipTo.set("country", "US");
> shipTo.set("name", "Alice Smith");
> shipTo.set("street", "123 Maple Street");
> shipTo.set("city", "Mill Valley");
> shipTo.set("state", "CA");
> shipTo.setString("zip", "90952");
> DataObject billTo =
> purchaseOrder.createDataObject("billTo");
> billTo.set("country", "US");
> billTo.set("name", "Robert Smith");
> billTo.set("street", "8 Oak Avenue");
> billTo.set("city", "Mill Valley");
> billTo.set("state", "PA");
> billTo.setString("zip", "95819");
> purchaseOrder.set("comment", "Hurry, my lawn is going
> wild!");
>
> DataObject items =
> purchaseOrder.createDataObject("items");
>
> DataObject item1 = items.createDataObject("item");
> item1.set("partNum", "872-AA");
> item1.set("productName", "Lawnmower");
> item1.setInt("quantity", 1);
> item1.setString("USPrice", "148.95");
> item1.set("comment", "Confirm this is electric");
>
> DataObject item2 = items.createDataObject("item");
> item2.set("partNum", "926-AA");
> item2.set("productName", "Baby Monitor");
> item2.setInt("quantity", 1);
> item2.setString("USPrice", "39.98");
> item2.setString("shipDate", "1999-05-21");
>
> try {
> OutputStream stream = System.err;
> XMLHelper.INSTANCE.save(purchaseOrder,
> SDO_MODEL_NAMESPACE,
> "purchaseOrder", stream);
> } catch (IOException e) {
> e.printStackTrace();
>   

Management and Distributed Runtime

[Simon Laws]

It would be good to get the community's thoughts about what management and
distributed runtime scenarios we should support in Tuscany.

There has been quite a bit of discussion on the distributed runtime itself
here. The main focus so far has been on using an SCA assembly to represent
the distributed services that typically comprise an SOA. Are there detailed
scenarios that you look to Tuscany to solve? How do you expect Tuscany to
fit into your existing infrastructure?

Based on the code we have already we could aim to get some level of support
into the next release for people to try out. What features should be
included?

Tuscany runtime management to date has been at the API level, i.e. adding
and removing contributions and composites.  A straightforward management
solution is important particularly when we are distributing the Tuscany
runtime across many nodes. What management functions should be supported?
What management technologies should Tuscany work well with? How do you
expect Tuscany to fit into your existing management infrastructure?

Of course anybody who wants to get involved and help design and implement
any of these features is more than welcome.

Simon

[jira] Commented: (TUSCANY-1395) XSD2JavaGenerator -noUnsettable option is broken for models with xsd:int or xsd:boolean types

[Kelvin Goodson (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-1395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12509832
 ] 

Kelvin Goodson commented on TUSCANY-1395:
-

Ron, The patch available flag is set on this Jira,  but there is no attachment. 
 Do you have a patch for this?
Regards, Kelvin.

> XSD2JavaGenerator -noUnsettable option is broken for models with xsd:int or 
> xsd:boolean types
> -
>
> Key: TUSCANY-1395
> URL: https://issues.apache.org/jira/browse/TUSCANY-1395
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Tools
>Affects Versions: Java-SDO-Next
>Reporter: Ron Gavlin
>Priority: Critical
>
> Classes generated by XSD2JavaGenerator with the -noUnsettable option do not 
> compile if the associated schema has elements/attributes of type xsd:int or 
> xsd:boolean. 
> In order to reproduce the problem, invoke XSD2JavaGenerator with the 
> -noUnsettable flag and the customerAccount.xsd test schema. The following 
> method in the generated com.example.customer.impl.AccountImpl class has a 
> compiler error in its last line [notify(int, int, int, int) is invalid]. 
>   public void setAccountNum(int newAccountNum)
>   {
> int oldAccountNum = accountNum;
> accountNum = newAccountNum;
> if (isNotifying())
>   notify(ChangeKind.SET, ACCOUNT_NUM, oldAccountNum, accountNum); // 
> COMPILER ERROR
>   }
> - Ron

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

Problems using WSDL interfaces together with DataBinding (DB) framework

[Scott Kurz]

Say I use SCDL like (for WS binding):

   
   
   
   http://w2j.sca.soa.ws/test/hw-ws-static-sdo-2parm#wsdl.interface(HelloWorld)
"/>
   http://w2j.sca.soa.ws/test/hw-ws-static-sdo-2parm#wsdl.port(HelloWorldService/HelloWorldSoapPort)
"/>
   
   

If I rely on the DefaultWSDLInterfaceIntrospector to build the Operation
model objects for the Component-level Interface, they will be created with a
null DB, because of the null in:

   WSDLOperation op = new WSDLOperation(wsdlFactory, wsdlOp, inlineSchemas,
null, resolver);

This leads to the following exception as I try to convert between the null
DB at the component level and the AXIOM DB set by the WS binding at the
binding level.

org.apache.tuscany.sca.databinding.TransformationException: No wrapper
handler is provided for databinding: null
   at
org.apache.tuscany.core.databinding.transformers.Input2InputTransformer.getWrapperHandler
(Input2InputTransformer.java:204)
   at
org.apache.tuscany.core.databinding.transformers.Input2InputTransformer.transform
(Input2InputTransformer.java:112)
   at
org.apache.tuscany.core.databinding.transformers.Input2InputTransformer.transform
(Input2InputTransformer.java:53)
   at org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(
MediatorImpl.java:77)
   at
org.apache.tuscany.core.databinding.wire.DataTransformationInteceptor.transform
(DataTransformationInteceptor.java:168)


So I tried setting up the Axiom DB instead from
DefaultWSDLInterfaceIntrospector on the component-level-interface Operation
objects loaded from  definitions.  (Note I had to workaround
JIRA TUSCANY-1342 with the fix I suggested).

This change has the side effect, however, of causing
DataTransformationInteceptor to not get set up when I'm using the WS
binding, since the WS binding uses the Axiom DB and since the
DataBindingRuntimeWireProcessor won't create the interceptor in the case the
DBs match.

Does someone have a better idea of how to make the DataBinding framework do
what I want here?

Looking at this I'm wondering... did we lose a DB "layer" in the move to
1.0-spec code?   Before we had component-level, composite-level and
binding-level.Now we have only component-level and binding-level.

Is a DB Interceptor needed to transform between the impl level and the
component level in a case like this where you have a Java impl w/ SDO DB but
you put  on the component-level service/ref?

(One might ask what is the point of using  at all in a case
like this, since the WS binding can convert between different, compatible
Java interfaces on either side.Well, I'm looking ahead to the time when
we have a wire between a ref w/ WS binding and a service w/ WS binding and <
interface.wsdl> would allow us to easily determine interface compatibility
on the wire.)

Scott

Re: SCA 0.92 release?

[Simon Nash]

I tried to get this page onto TUSCANYWIKI so that I could add to it.
To my great surprise, I don't seem to have edit permission for
TUSCANYWIKI.  Can one of our Wiki adminstrators help me with this,
please?

I'd like to get callbacks and async working properly across the
Web Service and SCA bindings.  I'd also like to complete the sample
cleanup by getting the patch to TUSCANY-1356 applied.

  Simon

Simon Laws wrote:


On 7/2/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:



Hi,

I am looking at the Policy Framework and shall update the wiki on the
specifics soon.  Once this is done to some level, I'd also like to help a
bit with the ws-* things (may be WS-Security to start with) that Ant has
listed on the wiki page.

- Venkat

On 6/30/07, ant elder <[EMAIL PROTECTED]> wrote:
>
> With the SCA 0.91 release now being voted on how about starting on 
0.92?

>
> I've already been adding some things I'm interested in getting done to
the
> next release wiki page -
>
>
http://cwiki.apache.org/confluence/display/TUSCANY/Java+SCA+Next+Release+Contents- 


> so far thats mainly related to improving web services functionality.
>
> So anyone else interested in helping with an 0.92 release or have any
> function they'd like to suggest or add to the wiki page? How does 
aiming

> for
> getting it done 4 - 6 weeks again sound?
>
>...ant
>




The above link has an extrenuous "-" on the end. Taking that off gets me to
the page. Can we move this information across the to the new wiki space (
http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Home) so that
everyone (including non committers) can add to it?

I'm working on the next phase of the distributed runtime which I want to 
get

into the next release. This involves a few items.

SCA Binding
Topology model
Distributed domain
Node implementation
Management assembly

Also I need some of the ws items, in particular the ability to run without
wsdl, so can help out there.

We need to do something about logging and events to improvide runtime
usability. We've talked about it before but not done anything yet. Ties 
into

the management assembly.

I'd also like to see the JMS binding in the release but can't commit to
doing lots more work on including spec features. It's been working fine for
me in my limited synchronous/rpc model. If I get time I'll take a look to
see what it will take to add minimum asynch support but if anyone else
fancies having a go at this then it's a good way to learn about Tuscany
extensions.

I'll add these to the web page.

Simon





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

[jira] Commented: (TUSCANY-1395) XSD2JavaGenerator -noUnsettable option is broken for models with xsd:int or xsd:boolean types

[Ron Gavlin (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-1395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12509837
 ] 

Ron Gavlin commented on TUSCANY-1395:
-

I set the patch available flag to indicate that TUSCANY-1393 had a patch 
available which will resolve this issue. Now that TUSCANY-1393 is fixed, feel 
free to mark this issue as resolved. I didn't want to mark this as a DUPLICATE 
of TUSCANY-1393 because the symptoms are so vastly different. A test should 
really be created to expose this bug and verify its patch. Once TUSCANY-1399 is 
resolved, I think it would be pretty easy to create such a test.

Regards,

- Ron

> XSD2JavaGenerator -noUnsettable option is broken for models with xsd:int or 
> xsd:boolean types
> -
>
> Key: TUSCANY-1395
> URL: https://issues.apache.org/jira/browse/TUSCANY-1395
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Tools
>Affects Versions: Java-SDO-Next
>Reporter: Ron Gavlin
>Priority: Critical
>
> Classes generated by XSD2JavaGenerator with the -noUnsettable option do not 
> compile if the associated schema has elements/attributes of type xsd:int or 
> xsd:boolean. 
> In order to reproduce the problem, invoke XSD2JavaGenerator with the 
> -noUnsettable flag and the customerAccount.xsd test schema. The following 
> method in the generated com.example.customer.impl.AccountImpl class has a 
> compiler error in its last line [notify(int, int, int, int) is invalid]. 
>   public void setAccountNum(int newAccountNum)
>   {
> int oldAccountNum = accountNum;
> accountNum = newAccountNum;
> if (isNotifying())
>   notify(ChangeKind.SET, ACCOUNT_NUM, oldAccountNum, accountNum); // 
> COMPILER ERROR
>   }
> - Ron

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

Re: SCA 0.92 release?

[Simon Nash]

The edit problem turned out to be "finger trouble" on my part.
(Thanks, Mike!)  I have put an editable copy of this page on TUSCANYWIKI at
  
http://cwiki.apache.org/confluence/display/TUSCANYWIKI/SCA+Java+Next+Release+Contents
It's linked under the main page of TUSCANYWIKI.

  Simon

Simon Nash wrote:


I tried to get this page onto TUSCANYWIKI so that I could add to it.
To my great surprise, I don't seem to have edit permission for
TUSCANYWIKI.  Can one of our Wiki adminstrators help me with this,
please?

I'd like to get callbacks and async working properly across the
Web Service and SCA bindings.  I'd also like to complete the sample
cleanup by getting the patch to TUSCANY-1356 applied.

  Simon

Simon Laws wrote:


On 7/2/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:



Hi,

I am looking at the Policy Framework and shall update the wiki on the
specifics soon.  Once this is done to some level, I'd also like to 
help a

bit with the ws-* things (may be WS-Security to start with) that Ant has
listed on the wiki page.

- Venkat

On 6/30/07, ant elder <[EMAIL PROTECTED]> wrote:
>
> With the SCA 0.91 release now being voted on how about starting on 
0.92?

>
> I've already been adding some things I'm interested in getting done to
the
> next release wiki page -
>
>
http://cwiki.apache.org/confluence/display/TUSCANY/Java+SCA+Next+Release+Contents- 


> so far thats mainly related to improving web services functionality.
>
> So anyone else interested in helping with an 0.92 release or have any
> function they'd like to suggest or add to the wiki page? How does 
aiming

> for
> getting it done 4 - 6 weeks again sound?
>
>...ant
>





The above link has an extrenuous "-" on the end. Taking that off gets 
me to

the page. Can we move this information across the to the new wiki space (
http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Home) so that
everyone (including non committers) can add to it?

I'm working on the next phase of the distributed runtime which I want 
to get

into the next release. This involves a few items.

SCA Binding
Topology model
Distributed domain
Node implementation
Management assembly

Also I need some of the ws items, in particular the ability to run 
without

wsdl, so can help out there.

We need to do something about logging and events to improvide runtime
usability. We've talked about it before but not done anything yet. 
Ties into

the management assembly.

I'd also like to see the JMS binding in the release but can't commit to
doing lots more work on including spec features. It's been working 
fine for

me in my limited synchronous/rpc model. If I get time I'll take a look to
see what it will take to add minimum asynch support but if anyone else
fancies having a go at this then it's a good way to learn about Tuscany
extensions.

I'll add these to the web page.

Simon





-
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: SCA 0.92 release?

[ant elder]

On 7/2/07, Simon Laws <[EMAIL PROTECTED]> wrote:



Can we move this information across the to the new wiki space (

http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Home) so that
everyone (including non committers) can add to it?



Is it really so bad having only committers able to update the release plan
and having others needing to post to the mailing list? The committers are
the ones responsible for doing the release (others are still very welcome to
participate and contribute).

  ...ant

Re: SCA 0.92 release?

[Venkata Krishnan]

Hi,

Some time ago, just after the creation go TUSCANYWIKI, I had suggested that
committers and non-committers both use only TUSCANYWIKI.

Things that need to go the website also should get added in TUSCANYWIKI
first, just that committers will take up the responsibility of copying them
over to TUSCANY.

This way, the wiki that all of us use is just one which is TUSCANYWIKI.  The
other space TUSCANY is to be perceived just as a web content hosting space
and anything that happens there is only a selective copy over from
TUSCANYWIKI.

Thoughts ?

- Venkat


On 7/3/07, ant elder <[EMAIL PROTECTED]> wrote:


On 7/2/07, Simon Laws <[EMAIL PROTECTED]> wrote:



Can we move this information across the to the new wiki space (
> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Home) so that
> everyone (including non committers) can add to it?


Is it really so bad having only committers able to update the release plan
and having others needing to post to the mailing list? The committers are
the ones responsible for doing the release (others are still very welcome
to
participate and contribute).

   ...ant

Re: Making the base artifact processor utilities more readily available

[ant elder]

On 7/3/07, Simon Laws <[EMAIL PROTECTED]> wrote:


In writing the Topology mode I had to make a copy of the base artifact
processor as it only has package visibilityIt has lots of useful utilities
alongside the assembly specific bits. How about we separate the utilities
from the assemly specific bits and make the utilities more widely
available.
For example, we could separate the utilites for reading XML elements from
those that read specific assembly elements into a more fundamental base
class.



I think this would be good (but its only fare to note that there's at least
one who's away on holiday right now who may not be so keen). One of the
issues is should the SPI be just interfaces or can it also have abstract or
utility helper classes as well. Some of those type of classes could make
using the existing SPI much easier IMHO and could make things like the
extension helper redundant.

  ...ant

Re: SCA 0.92 release?

[ant elder]

I'm not sure I see the point? If a committer wants to add/update web content
why should they need to do it twice? Its hard enough as it is to motivate
people to document things on the website without making the process even
harder to do.

  ...ant

On 7/3/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:


Hi,

Some time ago, just after the creation go TUSCANYWIKI, I had suggested
that committers and non-committers both use only TUSCANYWIKI.

Things that need to go the website also should get added in TUSCANYWIKI
first, just that committers will take up the responsibility of copying them
over to TUSCANY.

This way, the wiki that all of us use is just one which is TUSCANYWIKI.
The other space TUSCANY is to be perceived just as a web content hosting
space and anything that happens there is only a selective copy over from
TUSCANYWIKI.

Thoughts ?

- Venkat


On 7/3/07, ant elder < [EMAIL PROTECTED]> wrote:
>
> On 7/2/07, Simon Laws <[EMAIL PROTECTED]> wrote:
>
> 
>
> Can we move this information across the to the new wiki space (
> > http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Home) so that
> > everyone (including non committers) can add to it?
>
>
> Is it really so bad having only committers able to update the release
> plan
> and having others needing to post to the mailing list? The committers
> are
> the ones responsible for doing the release (others are still very
> welcome to
> participate and contribute).
>
>...ant
>

SCA binding and wiring

[Simon Laws]

The SCA binding provides the default binding and appears when the user
doesn't explicitly provide a binding against a reference or a service. The
Tuscany runtime can use the SCA binding to implement local wires between
components running in the same VM or remote wires between components running
on different nodes.

There is a simple SCA binding implementation for the distributed runtime (
binding.sca) which uses JMS for remote wires. Initially the intention had
been to hide all of the remote wiring parts of binding.sca behind the
reference and service providers but there are some issues with the way wires
are managed with respect to the SCA binding. Specifically the ones I came
across were:

- The original SCA binding was implemented as part of the assembly model and
there is an amount of code that appears in the process of wiring references
to services that specifically checks for the presence of the SCA binding and
does special things in that case. I would like to ensure that the special
things that are done are a product of the binding itself rather than the
builder and activator code.

- There are a number of issues about how to identify the target of a
reference in various parts of the code. I believe this primarily boils down
to the separation of targets and bindings, i.e. a reference has a set of
targets and a binding held independently. For example,
CompositeActivator.addBindingInterceptor() is creating binding providers but
is not aware of which target is being addressed. This makes it tricky from
within the binding to assess whether a local or remote wire is required.

-  If we want to have the SCA binding provide a facade of the remote binding
that is actually in use then there is an issue with service invokers. The
service side expects to find an invoker based on the binding service
provider for the binding type in use. If SCA binding is acting as a facade
the real binding type doesn't have a wire registered against it.

There may be more issues as I didn't get to the end of trying to make this
work before seeking an alternative.

The solution in place now for these items has been to provide methods on the
SCA Binding model that provide access to the remote binding that the SCA
binding is using for remote wires. During the build phase the SCA Binding is
replaced with the remote binding (JMS currently) and the wire creation
process continues as normal. What I would like to do is look further at how
we can move these features inside the SCA binding itself.

Does anyone have any background on the issues I mention above? Are there any
other features that the SCA binding should be providing?

There as been much work in TUSCANY-1341 [1] relating to how wiring is being
organized to ensure that callbacks work and I expect that this will have a
(positive) impact on the ability to tidy up the SCA binding in this respect.
These changes need to be taken into account also.

Simon

[1] http://issues.apache.org/jira/browse/TUSCANY-1341

Re: Making the base artifact processor utilities more readily available

[Simon Laws]

On 7/3/07, ant elder <[EMAIL PROTECTED]> wrote:


On 7/3/07, Simon Laws <[EMAIL PROTECTED]> wrote:
>
> In writing the Topology mode I had to make a copy of the base artifact
> processor as it only has package visibilityIt has lots of useful
utilities
> alongside the assembly specific bits. How about we separate the
utilities
> from the assemly specific bits and make the utilities more widely
> available.
> For example, we could separate the utilites for reading XML elements
from
> those that read specific assembly elements into a more fundamental base
> class.


I think this would be good (but its only fare to note that there's at
least
one who's away on holiday right now who may not be so keen). One of the
issues is should the SPI be just interfaces or can it also have abstract
or
utility helper classes as well. Some of those type of classes could make
using the existing SPI much easier IMHO and could make things like the
extension helper redundant.

   ...ant


To date the SPI (as described in the 0.90 CHANGES document) has been fairly
consistent in that it has concentrated on interfaces. It's always easy to
find the exception that proves the rule as there are classes in there but
generally it's interfaces.  I think it would be useful to expose those
utilities that we don't expect to change much and allow people access to
them. I am completely happy to wait on this though. As I say I took a copy
at the moment in order to avoid any untoward changes. Not ideal but there
you go. This case is interesting though as the class I want to use is part
of assembly.xml which we didn't declare as being part of the SPI currently.

Simon.

Simon

Re: Update from board regarding our oversight of WS project.

[Davanum Srinivas]

Folks,

The matrix is still sparse :) Please sign up!!!
http://wiki.apache.org/ws/FrontPage/BoardReports

-- dims

On 7/3/07, Kaushalye Kapuruge <[EMAIL PROTECTED]> wrote:

Hi Dims,
I volunteer for Apache Rampart-C project.
Cheers,
Kaushalye

Kaushalye Kapuruge wrote:
> Hi Dims,
> I volunteer for Apache Rampart-C project.
> Cheers,
> Kaushalye
>
> Davanum Srinivas wrote:
>> Team,
>>
>> The board would like WS reports to move towards the style and
>> development that the Jakarta and Incubator reports are done (i.e.,
>> owners for subprojects developing their parts, and the overall chair
>> acting as editor). For Inspiration, See [1]
>>
>> So, Firstly, Please volunteer (take ownership!!) to take charge for
>> reports for your subproject. If i don't hear from anyone on a specific
>> subproject, i will assume that no one is interested in that subproject
>> anymore and we can start the process of pruning that subproject. FYI,
>> the Spring cleaning is done [2]
>>
>> Secondly, If there are folks who are not on the ws pmc, but who should
>> be, then please bring up their nomination on private AT ws.apache.org
>>
>> I really hope the exisiting PMC members and the new ones will
>> rejuvenate our board reporting duty and continued oversight of the
>> "umbrella" WS project. It may be time to do some spring cleaning of
>> the pmc too as there are quite a few folks who are not active anymore.
>> One option is to change them to Emeritus status. If anyone falls into
>> this category, please let chime in.
>>
>> BTW, i was a bit late in submission, we have to do another board
>> report for this month. I've started a page here:
>> http://wiki.apache.org/ws/ReportForJul2007
>>
>> thanks,
>> dims
>>
>> [1] http://wiki.apache.org/incubator/June2007
>> [2]
>> http://mail-archives.apache.org/mod_mbox/ws-general/200703.mbox/[EMAIL 
PROTECTED]
>>
>
>


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





--
Davanum Srinivas :: http://davanum.wordpress.com

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

Re: [DISCUSS] Geronimo-Tuscany integration(Sending to both lists)

[Manu George]

Hi ,
   From Paul's mail I guess a Geronimo plugin would be
the way forward. I am going to list down a few more questions on the
scenarios that Sebastien has explained. The scenarios are given first
and then my understanding, approach and issues. I would be just
listing two of the scenarios and trying to implement them initially.

(a) I develop SCA components, assemble them in a composite, package them
in an SCA contribution. I don't really know what a WAR or an EAR is, I'm
just using the SCA programming model and packaging model. I deploy my
SCA contribution to Geronimo and run it there.

This will require a tuscany specific deployer that is installed as
part of the plugin. Ususally deployers have access to a server
specific deployment plan at some fixed path say
(META-INF/geronimo-tuscany.xml). If this file is found then the
deployer will know that the module that was supplied to it is a
tuscany module. In case I am deploying a tuscany contribution using
the sca packaging model then there will be a .composite file somewhere
in the module and the deployer will have to search in the module for
scdl files.  For now the tuscany  contributions will always be
packaged as jars.

This will mean that if the deployer finds this file then it will
handle the module as a tuscany module and if not found relinquish
control to other deployers.

Now we come to the question of the Domain. This has been a vexing
question for me. I think that going for a single SCADomain for the
entire server would be a good place to start.
All the applications will have an application composite and that
composite will be deployed on the server wide SCADomain. What the
server wide SCADomain should provide is the ability to add and remove
composites at runtime. If I am not mistaken this will be supported by
the EmbeddedSCADomain. Can someone in the know comment on this.

The other logical approach would be to go for different partial
SCADomain instances per contribution. These different instances will
still have information about the other instances and will do the
wiring across the instances that constitute a complete SCADomain.
From what I could find, this type of an SCADomain is not
supported currently. There is work on an SCADomain spanning multiple
runtimes. This would be a simpler case of an SCADomain spanning
multiple classloaders or (configurations in Geronimo).

The reason for not going with the second approach is that it is not
available in tuscany as of today. Please correct me if I am wrong.

(b) This was point (c) in Sebastien's mail.
  I want to use a Web app in my SCA assembly and call SCA components
  from it. I should be able to declare an SCA component representing my
  Web app, wire that component to other SCA components in the assembly,
  and then magically the wired references will be available as proxies for
  use in my JSPs, allowing me to call an SCA component using a simple
  jsp:useBean tag.

In addition to this the J2EE integration whitepaper at the OSOA
site mentions abt being able to annotate Web
artifacts(servlets,filters etc) with the SCA Annotations and get
services injected into servlets/filters etc for usage. The wiring will
be done by the SCA runtime. The whitepaper is here
http://www.osoa.org/pages/viewpage.action?pageId=3980.

The things to be done for achieving this functionality are,

1) Create a new implementation type in Tuscany namely implementation.web.
2) Declare in a .composite file in the war that the war is an
implementation.web type
3) The implementation.web tuscany extension will have functionality
to introspect the web module classes for SCA specific annotations and
build up information. Since there is a single SCADomain instance per
server and all the services that we are going to reference are already
deployed there, the implementation.web extension will take care of
wiring and creating service proxies. These proxies will be bound to
jndi.

The injection into geronimo managed objects cannot be done by tuscany
runtime. I am not 100% sure but I think that if I can populate the
injectionMap in the Holder object in the TomcatWebAppContext GBean for
that war with the right information then the injection will be taken
care of by Geronimo. Can someone confirm this?
This will take care of the integration in these two cases. As of now
we are assuming all the services to of scope stateless. All the stuff
in the second case will be done in a deployment watcher after a war
has been deployed.

This is the approach that myself and Vamsi are planning to use. If
there is any problem with this approach that you can see or a better
way to do things or something in the mail is not clear, please fell
free to point it out.

Regards
Manu

On 6/29/07, Paul McMahan <[EMAIL PROTECTED]> wrote:

On Jun 29, 2007, at 3:11 AM, Manu George wrote:

>> >
>> > Some of the questions we have are:
>> > 1.  Should we use this plugin approach and host the plugin
>> separat

Re: SCA 0.92 release?

[Simon Nash]

The point is to allow non-committers to make and preview proposed
changes to the Web site, just as they can to the code.  If the
published web site gets too far out of sync with what's on
TUSCANYWIKI, then a non-committer who wants to do this would first
have to do a manual sync from TUSCANY to TUSCANYWIKI before making
their proposed change.  They can do this, but it is one more
added overhead for non-commiters who want to participate actively
in Tuscany.  I don't think it would be wise to optimize everything
towards the convenience of committers and overlook the need to
motivate non-committers and new contributors.

  Simon

ant elder wrote:

I'm not sure I see the point? If a committer wants to add/update web 
content

why should they need to do it twice? Its hard enough as it is to motivate
people to document things on the website without making the process even
harder to do.

  ...ant

On 7/3/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:



Hi,

Some time ago, just after the creation go TUSCANYWIKI, I had suggested
that committers and non-committers both use only TUSCANYWIKI.

Things that need to go the website also should get added in TUSCANYWIKI
first, just that committers will take up the responsibility of copying 
them

over to TUSCANY.

This way, the wiki that all of us use is just one which is TUSCANYWIKI.
The other space TUSCANY is to be perceived just as a web content hosting
space and anything that happens there is only a selective copy over from
TUSCANYWIKI.

Thoughts ?

- Venkat


On 7/3/07, ant elder < [EMAIL PROTECTED]> wrote:
>
> On 7/2/07, Simon Laws <[EMAIL PROTECTED]> wrote:
>
> 
>
> Can we move this information across the to the new wiki space (
> > http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Home) so that
> > everyone (including non committers) can add to it?
>
>
> Is it really so bad having only committers able to update the release
> plan
> and having others needing to post to the mailing list? The committers
> are
> the ones responsible for doing the release (others are still very
> welcome to
> participate and contribute).
>
>...ant
>






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

Re: SCA 0.92 release?

[Simon Nash]

I thought this page was a list of suggestions for the 0.92 release.
The phrase "release plan" makes it seem more formal than that.
If it's just suggestions, then it should be open to contributors
as well as committers.

  Simon

ant elder wrote:


On 7/2/07, Simon Laws <[EMAIL PROTECTED]> wrote:



Can we move this information across the to the new wiki space (


http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Home) so that
everyone (including non committers) can add to it?




Is it really so bad having only committers able to update the release plan
and having others needing to post to the mailing list? The committers are
the ones responsible for doing the release (others are still very 
welcome to

participate and contribute).

  ...ant





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

Re: SCA 0.92 release?

[ant elder]

I'm not sure I'm convinced the overhead is going to be that much, its mostly
just copying a single page to get the latest version and making changes
against that isn't it?

What do other projects do who use this dual wiki approach?

We've not had many (any?) contributions for the website done on the 2nd wiki
yet have we? Could we maybe wait just a little to see how it works? If
people do make contributions and it looks harder than necessary we could
change to this new approach (or just make that person a website committer).

  ...ant

On 7/3/07, Simon Nash <[EMAIL PROTECTED]> wrote:


The point is to allow non-committers to make and preview proposed
changes to the Web site, just as they can to the code.  If the
published web site gets too far out of sync with what's on
TUSCANYWIKI, then a non-committer who wants to do this would first
have to do a manual sync from TUSCANY to TUSCANYWIKI before making
their proposed change.  They can do this, but it is one more
added overhead for non-commiters who want to participate actively
in Tuscany.  I don't think it would be wise to optimize everything
towards the convenience of committers and overlook the need to
motivate non-committers and new contributors.

   Simon

ant elder wrote:

> I'm not sure I see the point? If a committer wants to add/update web
> content
> why should they need to do it twice? Its hard enough as it is to
motivate
> people to document things on the website without making the process even
> harder to do.
>
>   ...ant
>
> On 7/3/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
>
>>
>> Hi,
>>
>> Some time ago, just after the creation go TUSCANYWIKI, I had suggested
>> that committers and non-committers both use only TUSCANYWIKI.
>>
>> Things that need to go the website also should get added in TUSCANYWIKI
>> first, just that committers will take up the responsibility of copying
>> them
>> over to TUSCANY.
>>
>> This way, the wiki that all of us use is just one which is TUSCANYWIKI.
>> The other space TUSCANY is to be perceived just as a web content
hosting
>> space and anything that happens there is only a selective copy over
from
>> TUSCANYWIKI.
>>
>> Thoughts ?
>>
>> - Venkat
>>
>>
>> On 7/3/07, ant elder < [EMAIL PROTECTED]> wrote:
>> >
>> > On 7/2/07, Simon Laws <[EMAIL PROTECTED]> wrote:
>> >
>> > 
>> >
>> > Can we move this information across the to the new wiki space (
>> > > http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Home) so
that
>> > > everyone (including non committers) can add to it?
>> >
>> >
>> > Is it really so bad having only committers able to update the release
>> > plan
>> > and having others needing to post to the mailing list? The committers
>> > are
>> > the ones responsible for doing the release (others are still very
>> > welcome to
>> > participate and contribute).
>> >
>> >...ant
>> >
>>
>>



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

RE: TuscanySCA CPP: Enhancements to the WSDLOperation class

[Brady Johnson]

Would there be any objections if I also made the following changes to
the WSDLOperation class: 
Change setInputType() to setInputMessageType()  // same for
output
Change getInputURI()  to getInputMessageURI()   // same for
output
Change getInputName() to getInputMessageName()  // same for
output

Previously these methods set/get the document wrapped message part
details. With the addition of the WSDLMessagePart class that doesn't
make sense anymore. What would be useful is to have access to the actual
input/output message name and URI. This would also be useful in
supporting more than just SOAP document wrapped.

I would also have to change where its used:
runtime/core/src/tuscany/sca/model/WSDLDefinition.cpp

runtime/extensions/rest/service/httpd/src/tuscany/sca/rest/ModREST.cpp

runtime/extensions/ws/reference/axis2c/src/tuscany/sca/ws/Axis2Client.cp
p

Also, how do I make a patch for the entire source tree, as opposed to
having to attach each individual changed file?

Brady


-Original Message-
From: Pete Robbins [mailto:[EMAIL PROTECTED] 
Sent: Monday, July 02, 2007 11:42 PM
To: tuscany-dev@ws.apache.org
Subject: Re: TuscanySCA CPP: Enhancements to the WSDLOperation class

Brady,

These changes look fine to me.

Cheers,

On 03/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
> Currently there is no way to obtain WSDL Operation Message information

> as defined in a WSDL. The WSDLOperation class does have 2 attributes 
> that seem to help serve this purpose, but they are never populated.
>commonj::sdo::DataObjectPtr inputMessage;
>commonj::sdo::DataObjectPtr outputMessage;
>
> I created a JIRA for this:
>https://issues.apache.org/jira/browse/TUSCANY-1402
>
> I would like to propose adding several methods related to the 
> input/output messages as follows:
>
>// Called from WSDLDefinition, populates std::map tuscany::sca::model::WSDLMessagePart> partMap
>// which will map part names to message parts
>void WSDLOperation::setInputMessage( commonj::sdo::DataObjectPtr 
> msg );
>void WSDLOperation::setOutputMessage( commonj::sdo::DataObjectPtr 
> msg );
>
>// Allows you to iterate over the input/output message parts
>// Initially for Document wrapped, there will only be one part
>std::list WSDLOperation::getInputMessagePartNames();
>std::list WSDLOperation::getOutputMessagePartNames();
>
>// Allows you to get the actual input/output message part
>// Initially for Document wrapped, there will only be one part
>tuscany::sca::model::WSDLMessagePart
> WSDLOperation::getInputMessagePart( std::string msgPartName );
>tuscany::sca::model::WSDLMessagePart
> WSDLOperation::getOutputMessagePart( std::string msgPartName );
>
>// Currently WSDLOperation specfies encoding for the entire 
> operation, when actually
>// it should be specified seperately for both the input AND the 
> output message
>void WSDLMessagePart::setInputEncoded( bool ); // replaces 
> setEncoded
>void WSDLMessagePart::setOutputEncoded( bool ); // replaces 
> setEncoded
>bool WSDLMessagePart::isInputEncoded(); // replaces isEncoded
>bool WSDLMessagePart::isOutputEncoded(); // replaces isEncoded
>
> The WSDLMessagePart class would have the following API:
>WSDLMessagePart::WSDLMessagePart( std::string partName, std::string

> partType, std::string partUri );
>
>std::string WSDLMessagePart::getPartName();
>void WSDLMessagePart::setPartName( std::string uri );
>
>std::string WSDLMessagePart::getPartType();
>void WSDLMessagePart::setPartType( std::string name );
>
>std::string WSDLMessagePart::getPartUri();
>void WSDLMessagePart::setPartUri( std::string uri );
>
> This would be a good step towards making Tuscany support both Document

> AND RPC SOAP message binding styles.
>
> If everyone agrees with these changes, I can provide a patch shortly.
>
> 
> Brady Johnson
> Lead Software Developer - HydraSCA
> Rogue Wave Software - [EMAIL PROTECTED]
>
>


--
Pete

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

Closing/Resolving Tuscany JIRA issues

[Brady Johnson]

I have recently created several JIRA issues for which I have issued
patches, which have in turn been submit to the code base (thanks Pete!).
Do I need to do anything to Close or Resolve those JIRA issues? What's
the procedure for doing this?
 
Here are the JIRA issues:
TUSCANY-1383
TUSCANY-1386
TUSCANY-1392
Tuscany-1400
 
Regards
 

Brady Johnson
Lead Software Developer - HydraSCA
Rogue Wave Software - [EMAIL PROTECTED]
 

Re: [VOTE] Release Tuscany Java SCA 0.91-incubating

[Venkata Krishnan]

Hi,

I am working on fixing the points raised by Ant and Simon.  While I am
looking at the others I need help in filling up the following: -

- the missing readmes in the demos
- the missing readmes and ant scipts in the samples

Does anybody have the time to help in this ?  Please let me know.

Thanks

- Venkat

On 7/2/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:


Thanks Simon.  Let me go fix these things.  Will call out for help when
needed.  :)
 - Venkat


On 7/2/07, Simon Laws < [EMAIL PROTECTED]> wrote:
>
> On 6/29/07, ant elder < [EMAIL PROTECTED]> wrote:
> >
> > On 6/28/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
> > >
> > > Hi,
> > >
> > > Please review and vote on the 0.91 release artifacts of Tuscany SCA
> for
> > > Java.
> > >
> > > The artifacts are available for review at:
> > > http://people.apache.org/~svkrish/tuscany/0.91-rc1/
> 
> > >
> > > The SVN tag for the release is:
> > >
> > >
> > 
https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sca/0.91-rc1-incubating/
>
> > >
> > > Seems ok to me, so here is my +1.
> > >
> > > Thanks.
> > >
> > > - Venkat
> > >
> >
> > +1
> >
> > This looks pretty good to me. There's a few things that could be
> improved
> > -
> > missing readme's for demos and some samples, some missing license
> headers
> > have crept in, the rmi calculator client fails for me - none of those
> are
> > blocking problems though. The biggest is for 0.90 we were asked to
> list
> > all
> > the jars under the Apache license just to make the licensing clear but
> > thats
> > missing, again not a blocker but it would be good to show we listen.
> I'll
> > try to fix most of these in the brn in case we do cut another rc, but
> > unless
> > many more problems are discovered this rc gets my vote.
> >
> >...ant
>
>
>
> Apologies for being so late to review the RC. Was away last week.
> Anyhow...
>
> I got a clean build of the source distro.
> I went through the samples in the bind distro. The issues I found are
> attached below. Ant, I'm assuming you have fixed many of these. If you
> let
> me know which ones are outstanding I'll go and provide fixes.
>
> None of these in their own right are blockers but together I think they
> mark
> a backward step in terms of quality from 0.90.  I would like to see
> another
> RC but as I'm so late in doing this have to vote - 0.5.
>
>
> Get rid of svg files from the distribution
>
> Samples/README - overview samples list doesn't match current samples
> list
>
> calculator-rmi-reference
> --
>
> Doesn't run for me from the command line.
>
> C:\simon\tuscany\r0.91-rc1\apache-
> tuscany-sca-0.91-incubating\tuscany-sca-0.91-i
> ncubating\samples\calculator-rmi-reference>ant run
> Buildfile: build.xml
>
> run:
>  [java] Composite assembly problem: No targets for reference:
> addService
>  [java] Composite assembly problem: No targets for reference:
> divideService
>  [java] Composite assembly problem: No targets for reference:
> multiplyServic
> e
>  [java] Composite assembly problem: No targets for reference:
> subtractServic
> e
>  [java] Exception in thread "main" java.lang.NullPointerException
>  [java] at calculator.CalculatorServiceImpl.add(
> CalculatorServiceImpl.ja
> va:54)
>  [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
>  [java] at sun.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAcces
> sorImpl.java:64)
>  [java] at sun.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMet
> hodAccessorImpl.java:43)
>  [java] at java.lang.reflect.Method.invoke(Method.java :615)
>  [java] at
> org.apache.tuscany.sca.implementation.java.invocation.JavaTar
> getInvoker.invokeTarget(JavaTargetInvoker.java:112)
>  [java] at
> org.apache.tuscany.sca.implementation.java.invocation.JavaTar
> getInvoker.invoke(JavaTargetInvoker.java:134)
>  [java] at
> org.apache.tuscany.sca.implementation.java.invocation.TargetI
> nvokerInvoker.invoke(TargetInvokerInvoker.java:46)
>  [java] at
> org.apache.tuscany.sca.core.invocation.AbstractInvocationHand
> ler.invoke(AbstractInvocationHandler.java:84)
>  [java] at
> org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.i
> nvoke(JDKInvocationHandler.java:73)
>  [java] at $Proxy1.add(Unknown Source)
>  [java] at calculator.CalculatorClient.main(
> CalculatorClient.java
> :35)
>  [java] Java Result: 1
>
> Calculator-webapp
> --
>
> The ant file produces a war called sample-calculator-web.war rather than
> sample-calculator-webapp.war
>
> chat-webapp
> --
>
> has no README, diagram or ant build file. Here's the URL you need to use
>
> http://localhost:8080/sample-chat-webapp/
>
> databining-echo
> ---
>
> C:\simon\tuscany\r0.91-rc1\apache-
> tuscany-sca-0.91-incubating\tuscany-sca-0.91-i
> ncubating\s

Re: SCA 0.92 release?

[Luciano Resende]

For the release items being discussed, I think this is more like a
"wiki" page, then a "website" page.

As for :

(or just make that person a website committer).


I think that, from previous e-mail thread to the incubator list, we
could offer edit rights to people that wants to contribute to the
website and have a CLA on file with ASF [1]

[1] http://www.mail-archive.com/general%40incubator.apache.org/msg14391.html


On 7/3/07, ant elder <[EMAIL PROTECTED]> wrote:

I'm not sure I'm convinced the overhead is going to be that much, its mostly
just copying a single page to get the latest version and making changes
against that isn't it?

What do other projects do who use this dual wiki approach?

We've not had many (any?) contributions for the website done on the 2nd wiki
yet have we? Could we maybe wait just a little to see how it works? If
people do make contributions and it looks harder than necessary we could
change to this new approach (or just make that person a website committer).

   ...ant

On 7/3/07, Simon Nash <[EMAIL PROTECTED]> wrote:
>
> The point is to allow non-committers to make and preview proposed
> changes to the Web site, just as they can to the code.  If the
> published web site gets too far out of sync with what's on
> TUSCANYWIKI, then a non-committer who wants to do this would first
> have to do a manual sync from TUSCANY to TUSCANYWIKI before making
> their proposed change.  They can do this, but it is one more
> added overhead for non-commiters who want to participate actively
> in Tuscany.  I don't think it would be wise to optimize everything
> towards the convenience of committers and overlook the need to
> motivate non-committers and new contributors.
>
>Simon
>
> ant elder wrote:
>
> > I'm not sure I see the point? If a committer wants to add/update web
> > content
> > why should they need to do it twice? Its hard enough as it is to
> motivate
> > people to document things on the website without making the process even
> > harder to do.
> >
> >   ...ant
> >
> > On 7/3/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
> >
> >>
> >> Hi,
> >>
> >> Some time ago, just after the creation go TUSCANYWIKI, I had suggested
> >> that committers and non-committers both use only TUSCANYWIKI.
> >>
> >> Things that need to go the website also should get added in TUSCANYWIKI
> >> first, just that committers will take up the responsibility of copying
> >> them
> >> over to TUSCANY.
> >>
> >> This way, the wiki that all of us use is just one which is TUSCANYWIKI.
> >> The other space TUSCANY is to be perceived just as a web content
> hosting
> >> space and anything that happens there is only a selective copy over
> from
> >> TUSCANYWIKI.
> >>
> >> Thoughts ?
> >>
> >> - Venkat
> >>
> >>
> >> On 7/3/07, ant elder < [EMAIL PROTECTED]> wrote:
> >> >
> >> > On 7/2/07, Simon Laws <[EMAIL PROTECTED]> wrote:
> >> >
> >> > 
> >> >
> >> > Can we move this information across the to the new wiki space (
> >> > > http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Home) so
> that
> >> > > everyone (including non committers) can add to it?
> >> >
> >> >
> >> > Is it really so bad having only committers able to update the release
> >> > plan
> >> > and having others needing to post to the mailing list? The committers
> >> > are
> >> > the ones responsible for doing the release (others are still very
> >> > welcome to
> >> > participate and contribute).
> >> >
> >> >...ant
> >> >
> >>
> >>
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>




--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/

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

Re: Making the base artifact processor utilities more readily available

[Raymond Feng]

Hi,

At this moment, we use the term "SPI" to represent all the interfaces and 
classes accessible to the extension developers. I think it can be further 
divided into two categories.


1) The contract interfaces/classes
2) The utility/helper classes

1 is mandatory while 2 is optional to extension developers. I'm fine to 
expose the helper/utility classes as long as the following criteria are 
meet:


a) Make it obvious (for example, using util. as part of the package name) 
for extension developers to understand they are optional helper/utility 
classes which are not part of the contract
b) Only expose the utility/helper classes if they are common and error-prone 
to implement by individual extensions.


Thanks,
Raymond

- Original Message - 
From: "Simon Laws" <[EMAIL PROTECTED]>

To: ; <[EMAIL PROTECTED]>
Sent: Tuesday, July 03, 2007 7:12 AM
Subject: Re: Making the base artifact processor utilities more readily 
available




On 7/3/07, ant elder <[EMAIL PROTECTED]> wrote:


On 7/3/07, Simon Laws <[EMAIL PROTECTED]> wrote:
>
> In writing the Topology mode I had to make a copy of the base artifact
> processor as it only has package visibilityIt has lots of useful
utilities
> alongside the assembly specific bits. How about we separate the
utilities
> from the assemly specific bits and make the utilities more widely
> available.
> For example, we could separate the utilites for reading XML elements
from
> those that read specific assembly elements into a more fundamental base
> class.


I think this would be good (but its only fare to note that there's at
least
one who's away on holiday right now who may not be so keen). One of the
issues is should the SPI be just interfaces or can it also have abstract
or
utility helper classes as well. Some of those type of classes could make
using the existing SPI much easier IMHO and could make things like the
extension helper redundant.

   ...ant

To date the SPI (as described in the 0.90 CHANGES document) has been 
fairly

consistent in that it has concentrated on interfaces. It's always easy to
find the exception that proves the rule as there are classes in there but
generally it's interfaces.  I think it would be useful to expose those
utilities that we don't expect to change much and allow people access to
them. I am completely happy to wait on this though. As I say I took a copy
at the moment in order to avoid any untoward changes. Not ideal but there
you go. This case is interesting though as the class I want to use is part
of assembly.xml which we didn't declare as being part of the SPI 
currently.


Simon.

Simon




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

Re: Closing/Resolving Tuscany JIRA issues

[Luciano Resende]

Brady

  The first two are already marked as resolved/fixed. The other two
are still open.
  If the patches for the other two are already applied, you can
Resolve the JIRAS as fixed.

On 7/3/07, Brady Johnson <[EMAIL PROTECTED]> wrote:

I have recently created several JIRA issues for which I have issued
patches, which have in turn been submit to the code base (thanks Pete!).
Do I need to do anything to Close or Resolve those JIRA issues? What's
the procedure for doing this?

Here are the JIRA issues:
TUSCANY-1383
TUSCANY-1386
TUSCANY-1392
Tuscany-1400

Regards


Brady Johnson
Lead Software Developer - HydraSCA
Rogue Wave Software - [EMAIL PROTECTED]





--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/

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

Re: Making the base artifact processor utilities more readily available

[Luciano Resende]

Would 1 and 2, be on the same maven project ? If a utility is really
useful for others, maybe it could be on it's own maven project to
avoid circular reference in the future when other modules want to
reuse these utilities.

On 7/3/07, Raymond Feng <[EMAIL PROTECTED]> wrote:

Hi,

At this moment, we use the term "SPI" to represent all the interfaces and
classes accessible to the extension developers. I think it can be further
divided into two categories.

1) The contract interfaces/classes
2) The utility/helper classes

1 is mandatory while 2 is optional to extension developers. I'm fine to
expose the helper/utility classes as long as the following criteria are
meet:

a) Make it obvious (for example, using util. as part of the package name)
for extension developers to understand they are optional helper/utility
classes which are not part of the contract
b) Only expose the utility/helper classes if they are common and error-prone
to implement by individual extensions.

Thanks,
Raymond

- Original Message -
From: "Simon Laws" <[EMAIL PROTECTED]>
To: ; <[EMAIL PROTECTED]>
Sent: Tuesday, July 03, 2007 7:12 AM
Subject: Re: Making the base artifact processor utilities more readily
available


> On 7/3/07, ant elder <[EMAIL PROTECTED]> wrote:
>>
>> On 7/3/07, Simon Laws <[EMAIL PROTECTED]> wrote:
>> >
>> > In writing the Topology mode I had to make a copy of the base artifact
>> > processor as it only has package visibilityIt has lots of useful
>> utilities
>> > alongside the assembly specific bits. How about we separate the
>> utilities
>> > from the assemly specific bits and make the utilities more widely
>> > available.
>> > For example, we could separate the utilites for reading XML elements
>> from
>> > those that read specific assembly elements into a more fundamental base
>> > class.
>>
>>
>> I think this would be good (but its only fare to note that there's at
>> least
>> one who's away on holiday right now who may not be so keen). One of the
>> issues is should the SPI be just interfaces or can it also have abstract
>> or
>> utility helper classes as well. Some of those type of classes could make
>> using the existing SPI much easier IMHO and could make things like the
>> extension helper redundant.
>>
>>...ant
>>
> To date the SPI (as described in the 0.90 CHANGES document) has been
> fairly
> consistent in that it has concentrated on interfaces. It's always easy to
> find the exception that proves the rule as there are classes in there but
> generally it's interfaces.  I think it would be useful to expose those
> utilities that we don't expect to change much and allow people access to
> them. I am completely happy to wait on this though. As I say I took a copy
> at the moment in order to avoid any untoward changes. Not ideal but there
> you go. This case is interesting though as the class I want to use is part
> of assembly.xml which we didn't declare as being part of the SPI
> currently.
>
> Simon.
>
> Simon
>


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





--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/

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

NoClassDefFoundError for DefaultContributionPostProcessorExtensionPoint

[Simon Nash]

I'm getting the following error from the new simple-callback-ws sample
when I run a full top-level mvn build against my test codebase that has
the latest incarnation of the fix to TUSCANY-1341.  The problem doesn't
occur when I run mvn from the samples directory, or when I run mvn from
the samples/simple-callback-ws directory.  I haven't made any code
changes that seem like they could cause this error.  Has anyone seen
this before, or are there any suggestions for debugging?

  Simon

---
 T E S T S
---
Running simplecallback.SimpleCallbackTestCase
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.381 sec <<< 
FAILURE!
test(simplecallback.SimpleCallbackTestCase)  Time elapsed: 0.311 sec  <<< ERROR!
java.lang.NoClassDefFoundError: 
org/apache/tuscany/sca/contribution/processor/DefaultContributionPostProcessorExtensionPoint
at 
org.apache.tuscany.sca.host.embedded.impl.ReallySmallRuntimeBuilder.createContributionService(ReallySmallRuntimeBuilder.java:189)
at 
org.apache.tuscany.sca.host.embedded.impl.ReallySmallRuntime.start(ReallySmallRuntime.java:113)
at 
org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.(DefaultSCADomain.java:86)
at 
org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:229)
at 
org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SCADomain.java:68)
at 
simplecallback.SimpleCallbackTestCase.setUp(SimpleCallbackTestCase.java:34)
at junit.framework.TestCase.runBare(TestCase.java:132)
at junit.framework.TestResult$1.protect(TestResult.java:110)
at junit.framework.TestResult.runProtected(TestResult.java:128)
at junit.framework.TestResult.run(TestResult.java:113)
at junit.framework.TestCase.run(TestCase.java:124)
at junit.framework.TestSuite.runTest(TestSuite.java:232)
at junit.framework.TestSuite.run(TestSuite.java:227)
at 
org.junit.internal.runners.OldTestClassRunner.run(OldTestClassRunner.java:35)
at 
org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
at 
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138)
at 
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125)
at org.apache.maven.surefire.Surefire.run(Surefire.java:132)
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.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:290)
at 
org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:818)


Results :

Tests in error:
  test(simplecallback.SimpleCallbackTestCase)



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

[jira] Created: (TUSCANY-1407) wrong parent artifactId in samples/helloworld-ws-service

[Wolfgang Colsman (JIRA)]

wrong parent artifactId in samples/helloworld-ws-service


 Key: TUSCANY-1407
 URL: https://issues.apache.org/jira/browse/TUSCANY-1407
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Samples
Affects Versions: Java-SCA-0.90
Reporter: Wolfgang Colsman
Priority: Trivial


wrong:
tuscany-samples
correct:
tuscany-sca

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Assigned: (TUSCANY-1407) wrong parent artifactId in samples/helloworld-ws-service

[Luciano Resende (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Luciano Resende reassigned TUSCANY-1407:


Assignee: Luciano Resende

> wrong parent artifactId in samples/helloworld-ws-service
> 
>
> Key: TUSCANY-1407
> URL: https://issues.apache.org/jira/browse/TUSCANY-1407
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Samples
>Affects Versions: Java-SCA-0.90
>Reporter: Wolfgang Colsman
>Assignee: Luciano Resende
>Priority: Trivial
>
> wrong:
> tuscany-samples
> correct:
> tuscany-sca

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Commented: (TUSCANY-1407) wrong parent artifactId in samples/helloworld-ws-service

[Luciano Resende (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-1407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12509947
 ] 

Luciano Resende commented on TUSCANY-1407:
--

The following projects have the wrong artifact id:
calculator-distributed
helloworld-ws-service
das-service
das-service-web
feed-agregator

> wrong parent artifactId in samples/helloworld-ws-service
> 
>
> Key: TUSCANY-1407
> URL: https://issues.apache.org/jira/browse/TUSCANY-1407
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Samples
>Affects Versions: Java-SCA-0.90
>Reporter: Wolfgang Colsman
>Priority: Trivial
>
> wrong:
> tuscany-samples
> correct:
> tuscany-sca

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

Specific versions of Redhat

[Kevin Mayer]

This is in reference to minor issue TUSCANY-849 and SCA
GettingStarted.html.  The versions of Linux Redhat identified are Redhat
Enterprise Linux v3, Redhat Enterprise Linux v4.  What are the update
versions of v3 and v4?
 
thank you,
 
Kevin Mayer
Quality Assurance Engineering
Rogue Wave Software
[EMAIL PROTECTED]
303-545-3194
 

Re: SCA binding and wiring

[Raymond Feng]

Hi,

Please see my comments inline.

Thanks,
Raymond

- Original Message - 
From: "Simon Laws" <[EMAIL PROTECTED]>

To: "tuscany-dev" 
Sent: Tuesday, July 03, 2007 6:20 AM
Subject: SCA binding and wiring



The SCA binding provides the default binding and appears when the user
doesn't explicitly provide a binding against a reference or a service. The
Tuscany runtime can use the SCA binding to implement local wires between
components running in the same VM or remote wires between components 
running

on different nodes.

There is a simple SCA binding implementation for the distributed runtime (
binding.sca) which uses JMS for remote wires. Initially the intention had
been to hide all of the remote wiring parts of binding.sca behind the
reference and service providers but there are some issues with the way 
wires

are managed with respect to the SCA binding. Specifically the ones I came
across were:

- The original SCA binding was implemented as part of the assembly model 
and
there is an amount of code that appears in the process of wiring 
references
to services that specifically checks for the presence of the SCA binding 
and

does special things in that case. I would like to ensure that the special
things that are done are a product of the binding itself rather than the
builder and activator code.


By the assembly spec, the SCA binding is "special" in two senses:
1) SCA Binding will be used if no binding element is declared for a service 
or reference
2) SCA Binding behaves differently on whether the interface is local or 
remote




- There are a number of issues about how to identify the target of a
reference in various parts of the code. I believe this primarily boils 
down

to the separation of targets and bindings, i.e. a reference has a set of
targets and a binding held independently. For example,
CompositeActivator.addBindingInterceptor() is creating binding providers 
but

is not aware of which target is being addressed. This makes it tricky from
within the binding to assess whether a local or remote wire is required.


To me, the "target" attribute is just a shortcut to define target URIs for 
bindings that support the addressing by the logical name 
(componentName/serviceName). SCA Binding is one of the bindings. The binding 
itself can use the "uri" attribute to declare the
target if "target" is not present. The assembly spec explicitly makes the 
"target" attribute of a reference element and "uri" attribute

of a binding element exclusive to avoid confusion.

Logically, binding should be holder of the target information. 
Reference/Binding pair is the endpoint.


There were some disucssions on the resolving of targets at:
http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200706.mbox/[EMAIL 
PROTECTED]



-  If we want to have the SCA binding provide a facade of the remote 
binding

that is actually in use then there is an issue with service invokers. The
service side expects to find an invoker based on the binding service
provider for the binding type in use. If SCA binding is acting as a facade
the real binding type doesn't have a wire registered against it.



One option is to have the SCA binding provider to act differently based on 
the interface and co-location. For example, if the interface is local,
the access method for the reference or service is purely java invocation and 
no interceptor/listener is needed.



There may be more issues as I didn't get to the end of trying to make this
work before seeking an alternative.

The solution in place now for these items has been to provide methods on 
the

SCA Binding model that provide access to the remote binding that the SCA
binding is using for remote wires. During the build phase the SCA Binding 
is

replaced with the remote binding (JMS currently) and the wire creation
process continues as normal. What I would like to do is look further at 
how

we can move these features inside the SCA binding itself.



+1 to move these features inside the SCA binding. Mapping SCA binding to an 
existing protocol doesn't mean to replace the binding.sca with binding.xyz.
Potentially, we can map binding.sca to different protocols depending on 
co-location or asynchrony. I think the runtime will need to derive more 
metadata for SCA binding. For example, if we choose to use Web Service 
protocol for SCA binding, we need to calculate the SOAP adddress based on 
the logical

SCA names.

Does anyone have any background on the issues I mention above? Are there 
any

other features that the SCA binding should be providing?

There as been much work in TUSCANY-1341 [1] relating to how wiring is 
being

organized to ensure that callbacks work and I expect that this will have a
(positive) impact on the ability to tidy up the SCA binding in this 
respect.

These changes need to be taken into account also.

Simon

[1] http://issues.apache.org/jira/browse/TUSCANY-1341




-
To unsub

Re: Making the base artifact processor utilities more readily available

[ant elder]

How strict would it be on the error-prone bit be in "Only expose the
utility/helper classes if they are common and error-prone"? For example,
there's an AbstractImplementation class here which I think is useful and
i've used multiple times, but its arguable how error-prone the code is.

https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/extension-helper/src/main/java/org/apache/tuscany/sca/spi/utils/AbstractImplementation.java

How about "not completely trivial" instead of "error-prone"?

  ...ant

On 7/3/07, Raymond Feng <[EMAIL PROTECTED]> wrote:


Hi,

At this moment, we use the term "SPI" to represent all the interfaces and
classes accessible to the extension developers. I think it can be further
divided into two categories.

1) The contract interfaces/classes
2) The utility/helper classes

1 is mandatory while 2 is optional to extension developers. I'm fine to
expose the helper/utility classes as long as the following criteria are
meet:

a) Make it obvious (for example, using util. as part of the package name)
for extension developers to understand they are optional helper/utility
classes which are not part of the contract
b) Only expose the utility/helper classes if they are common and
error-prone
to implement by individual extensions.

Thanks,
Raymond

- Original Message -
From: "Simon Laws" <[EMAIL PROTECTED]>
To: ; <[EMAIL PROTECTED]>
Sent: Tuesday, July 03, 2007 7:12 AM
Subject: Re: Making the base artifact processor utilities more readily
available


> On 7/3/07, ant elder <[EMAIL PROTECTED]> wrote:
>>
>> On 7/3/07, Simon Laws <[EMAIL PROTECTED]> wrote:
>> >
>> > In writing the Topology mode I had to make a copy of the base
artifact
>> > processor as it only has package visibilityIt has lots of useful
>> utilities
>> > alongside the assembly specific bits. How about we separate the
>> utilities
>> > from the assemly specific bits and make the utilities more widely
>> > available.
>> > For example, we could separate the utilites for reading XML elements
>> from
>> > those that read specific assembly elements into a more fundamental
base
>> > class.
>>
>>
>> I think this would be good (but its only fare to note that there's at
>> least
>> one who's away on holiday right now who may not be so keen). One of the
>> issues is should the SPI be just interfaces or can it also have
abstract
>> or
>> utility helper classes as well. Some of those type of classes could
make
>> using the existing SPI much easier IMHO and could make things like the
>> extension helper redundant.
>>
>>...ant
>>
> To date the SPI (as described in the 0.90 CHANGES document) has been
> fairly
> consistent in that it has concentrated on interfaces. It's always easy
to
> find the exception that proves the rule as there are classes in there
but
> generally it's interfaces.  I think it would be useful to expose those
> utilities that we don't expect to change much and allow people access to
> them. I am completely happy to wait on this though. As I say I took a
copy
> at the moment in order to avoid any untoward changes. Not ideal but
there
> you go. This case is interesting though as the class I want to use is
part
> of assembly.xml which we didn't declare as being part of the SPI
> currently.
>
> Simon.
>
> Simon
>


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

Re: Making the base artifact processor utilities more readily available

[Raymond Feng]

"not completely trivial" is definitely a better term :-).

Thanks,
Raymond

- Original Message - 
From: "ant elder" <[EMAIL PROTECTED]>

To: 
Sent: Tuesday, July 03, 2007 10:55 AM
Subject: Re: Making the base artifact processor utilities more readily 
available




How strict would it be on the error-prone bit be in "Only expose the
utility/helper classes if they are common and error-prone"? For example,
there's an AbstractImplementation class here which I think is useful and
i've used multiple times, but its arguable how error-prone the code is.

https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/extension-helper/src/main/java/org/apache/tuscany/sca/spi/utils/AbstractImplementation.java

How about "not completely trivial" instead of "error-prone"?

  ...ant

On 7/3/07, Raymond Feng <[EMAIL PROTECTED]> wrote:


Hi,

At this moment, we use the term "SPI" to represent all the interfaces and
classes accessible to the extension developers. I think it can be further
divided into two categories.

1) The contract interfaces/classes
2) The utility/helper classes

1 is mandatory while 2 is optional to extension developers. I'm fine to
expose the helper/utility classes as long as the following criteria are
meet:

a) Make it obvious (for example, using util. as part of the package name)
for extension developers to understand they are optional helper/utility
classes which are not part of the contract
b) Only expose the utility/helper classes if they are common and
error-prone
to implement by individual extensions.

Thanks,
Raymond

- Original Message -
From: "Simon Laws" <[EMAIL PROTECTED]>
To: ; <[EMAIL PROTECTED]>
Sent: Tuesday, July 03, 2007 7:12 AM
Subject: Re: Making the base artifact processor utilities more readily
available


> On 7/3/07, ant elder <[EMAIL PROTECTED]> wrote:
>>
>> On 7/3/07, Simon Laws <[EMAIL PROTECTED]> wrote:
>> >
>> > In writing the Topology mode I had to make a copy of the base
artifact
>> > processor as it only has package visibilityIt has lots of useful
>> utilities
>> > alongside the assembly specific bits. How about we separate the
>> utilities
>> > from the assemly specific bits and make the utilities more widely
>> > available.
>> > For example, we could separate the utilites for reading XML elements
>> from
>> > those that read specific assembly elements into a more fundamental
base
>> > class.
>>
>>
>> I think this would be good (but its only fare to note that there's at
>> least
>> one who's away on holiday right now who may not be so keen). One of 
>> the

>> issues is should the SPI be just interfaces or can it also have
abstract
>> or
>> utility helper classes as well. Some of those type of classes could
make
>> using the existing SPI much easier IMHO and could make things like the
>> extension helper redundant.
>>
>>...ant
>>
> To date the SPI (as described in the 0.90 CHANGES document) has been
> fairly
> consistent in that it has concentrated on interfaces. It's always easy
to
> find the exception that proves the rule as there are classes in there
but
> generally it's interfaces.  I think it would be useful to expose those
> utilities that we don't expect to change much and allow people access 
> to

> them. I am completely happy to wait on this though. As I say I took a
copy
> at the moment in order to avoid any untoward changes. Not ideal but
there
> you go. This case is interesting though as the class I want to use is
part
> of assembly.xml which we didn't declare as being part of the SPI
> currently.
>
> Simon.
>
> Simon
>


-
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: [VOTE] Release Tuscany Java SCA 0.91-incubating

[Luciano Resende]

Is anyone seeing the following error trying to build 0.91 branch ?

Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 2.547
sec <<< FAILURE!
testTransform(dbecho.EchoDataBindingTestCase)  Time elapsed: 2.5 sec  <<< ERROR!
org.osoa.sca.ServiceRuntimeException: Service not found: ComponentA
   at 
org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.getService(DefaultSCADomain.java:278)
   at 
dbecho.EchoDataBindingTestCase.testTransform(EchoDataBindingTestCase.java:45)
   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 junit.framework.TestCase.runTest(TestCase.java:168)
   at junit.framework.TestCase.runBare(TestCase.java:134)
   at junit.framework.TestResult$1.protect(TestResult.java:110)
   at junit.framework.TestResult.runProtected(TestResult.java:128)
   at junit.framework.TestResult.run(TestResult.java:113)
   at junit.framework.TestCase.run(TestCase.java:124)
   at junit.framework.TestSuite.runTest(TestSuite.java:232)
   at junit.framework.TestSuite.run(TestSuite.java:227)
   at 
org.junit.internal.runners.OldTestClassRunner.run(OldTestClassRunner.java:35)
   at 
org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
   at 
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138)
   at 
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125)
   at org.apache.maven.surefire.Surefire.run(Surefire.java:132)
   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.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:290)
   at 
org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:818)


On 7/3/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:

Hi,

I am working on fixing the points raised by Ant and Simon.  While I am
looking at the others I need help in filling up the following: -

- the missing readmes in the demos
- the missing readmes and ant scipts in the samples

Does anybody have the time to help in this ?  Please let me know.

Thanks

- Venkat

On 7/2/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
>
> Thanks Simon.  Let me go fix these things.  Will call out for help when
> needed.  :)
>  - Venkat
>
>
> On 7/2/07, Simon Laws < [EMAIL PROTECTED]> wrote:
> >
> > On 6/29/07, ant elder < [EMAIL PROTECTED]> wrote:
> > >
> > > On 6/28/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
> > > >
> > > > Hi,
> > > >
> > > > Please review and vote on the 0.91 release artifacts of Tuscany SCA
> > for
> > > > Java.
> > > >
> > > > The artifacts are available for review at:
> > > > http://people.apache.org/~svkrish/tuscany/0.91-rc1/
> > 
> > > >
> > > > The SVN tag for the release is:
> > > >
> > > >
> > > 
https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sca/0.91-rc1-incubating/
> >
> > > >
> > > > Seems ok to me, so here is my +1.
> > > >
> > > > Thanks.
> > > >
> > > > - Venkat
> > > >
> > >
> > > +1
> > >
> > > This looks pretty good to me. There's a few things that could be
> > improved
> > > -
> > > missing readme's for demos and some samples, some missing license
> > headers
> > > have crept in, the rmi calculator client fails for me - none of those
> > are
> > > blocking problems though. The biggest is for 0.90 we were asked to
> > list
> > > all
> > > the jars under the Apache license just to make the licensing clear but
> > > thats
> > > missing, again not a blocker but it would be good to show we listen.
> > I'll
> > > try to fix most of these in the brn in case we do cut another rc, but
> > > unless
> > > many more problems are discovered this rc gets my vote.
> > >
> > >...ant
> >
> >
> >
> > Apologies for being so late to review the RC. Was away last week.
> > Anyhow...
> >
> > I got a clean build of the source distro.
> > I went through the samples in the bind distro. The issues I found are
> > attached below. Ant, I'm assuming you have fixed many of these. If you
> > let
> > me know which ones are outstanding I'll go and provide fixes.
> >
> > None of these in their own right are blockers but together I think they
> > mark
> > a backward step in terms of quality from 0.90.  I would like to see
> > another
> > RC but as I'm so late in doing this have to vote - 0.5.
> >
> >
> > Get rid of svg files from the distribution
> >
> > Samples/README -

[jira] Resolved: (TUSCANY-1407) wrong parent artifactId in samples/helloworld-ws-service

[Luciano Resende (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Luciano Resende resolved TUSCANY-1407.
--

   Resolution: Fixed
Fix Version/s: Java-SCA-Next
   Java-SCA-0.91

Fixed.

> wrong parent artifactId in samples/helloworld-ws-service
> 
>
> Key: TUSCANY-1407
> URL: https://issues.apache.org/jira/browse/TUSCANY-1407
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Samples
>Affects Versions: Java-SCA-0.90
>Reporter: Wolfgang Colsman
>Assignee: Luciano Resende
>Priority: Trivial
> Fix For: Java-SCA-0.91, Java-SCA-Next
>
>
> wrong:
> tuscany-samples
> correct:
> tuscany-sca

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

Re: [VOTE] Release Tuscany Java SCA 0.91-incubating

[Venkata Krishnan]

Hi,

Yes I too see it.  Just trying to figure out the reason.  For now it seems
like a 'self reference' was not created and added to this component.  Need
to figure out why.

- Venkat

On 7/4/07, Luciano Resende <[EMAIL PROTECTED]> wrote:


Is anyone seeing the following error trying to build 0.91 branch ?

Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 2.547
sec <<< FAILURE!
testTransform(dbecho.EchoDataBindingTestCase)  Time elapsed: 2.5 sec  <<<
ERROR!
org.osoa.sca.ServiceRuntimeException: Service not found: ComponentA
at
org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.getService(
DefaultSCADomain.java:278)
at dbecho.EchoDataBindingTestCase.testTransform(
EchoDataBindingTestCase.java:45)
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 junit.framework.TestCase.runTest(TestCase.java:168)
at junit.framework.TestCase.runBare(TestCase.java:134)
at junit.framework.TestResult$1.protect(TestResult.java:110)
at junit.framework.TestResult.runProtected(TestResult.java:128)
at junit.framework.TestResult.run(TestResult.java:113)
at junit.framework.TestCase.run(TestCase.java:124)
at junit.framework.TestSuite.runTest(TestSuite.java:232)
at junit.framework.TestSuite.run(TestSuite.java:227)
at org.junit.internal.runners.OldTestClassRunner.run(
OldTestClassRunner.java:35)
at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(
JUnit4TestSet.java:62)
at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(
AbstractDirectoryTestSuite.java:138)
at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(
AbstractDirectoryTestSuite.java:125)
at org.apache.maven.surefire.Surefire.run(Surefire.java:132)
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.booter.SurefireBooter.runSuitesInProcess(
SurefireBooter.java:290)
at org.apache.maven.surefire.booter.SurefireBooter.main(
SurefireBooter.java:818)


On 7/3/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I am working on fixing the points raised by Ant and Simon.  While I am
> looking at the others I need help in filling up the following: -
>
> - the missing readmes in the demos
> - the missing readmes and ant scipts in the samples
>
> Does anybody have the time to help in this ?  Please let me know.
>
> Thanks
>
> - Venkat
>
> On 7/2/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
> >
> > Thanks Simon.  Let me go fix these things.  Will call out for help
when
> > needed.  :)
> >  - Venkat
> >
> >
> > On 7/2/07, Simon Laws < [EMAIL PROTECTED]> wrote:
> > >
> > > On 6/29/07, ant elder < [EMAIL PROTECTED]> wrote:
> > > >
> > > > On 6/28/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > Please review and vote on the 0.91 release artifacts of Tuscany
SCA
> > > for
> > > > > Java.
> > > > >
> > > > > The artifacts are available for review at:
> > > > > http://people.apache.org/~svkrish/tuscany/0.91-rc1/
> > > 
> > > > >
> > > > > The SVN tag for the release is:
> > > > >
> > > > >
> > > >
https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sca/0.91-rc1-incubating/
> > >
> > > > >
> > > > > Seems ok to me, so here is my +1.
> > > > >
> > > > > Thanks.
> > > > >
> > > > > - Venkat
> > > > >
> > > >
> > > > +1
> > > >
> > > > This looks pretty good to me. There's a few things that could be
> > > improved
> > > > -
> > > > missing readme's for demos and some samples, some missing license
> > > headers
> > > > have crept in, the rmi calculator client fails for me - none of
those
> > > are
> > > > blocking problems though. The biggest is for 0.90 we were asked to
> > > list
> > > > all
> > > > the jars under the Apache license just to make the licensing clear
but
> > > > thats
> > > > missing, again not a blocker but it would be good to show we
listen.
> > > I'll
> > > > try to fix most of these in the brn in case we do cut another rc,
but
> > > > unless
> > > > many more problems are discovered this rc gets my vote.
> > > >
> > > >...ant
> > >
> > >
> > >
> > > Apologies for being so late to review the RC. Was away last week.
> > > Anyhow...
> > >
> > > I got a clean build of the source distro.
> > > I went through the samples in the bind distro. The issues I found
are
> > > attached below. Ant, I'm assuming you h

Re: [DISCUSS] Geronimo-Tuscany integration(Sending to both lists)

[Raymond Feng]

Hi,

Please see my comments inline.

Thanks,
Raymond

- Original Message - 
From: "Manu George" <[EMAIL PROTECTED]>

To: <[EMAIL PROTECTED]>
Cc: 
Sent: Tuesday, July 03, 2007 7:53 AM
Subject: Re: [DISCUSS] Geronimo-Tuscany integration(Sending to both lists)



Hi ,
   From Paul's mail I guess a Geronimo plugin would be
the way forward. I am going to list down a few more questions on the
scenarios that Sebastien has explained. The scenarios are given first
and then my understanding, approach and issues. I would be just
listing two of the scenarios and trying to implement them initially.

(a) I develop SCA components, assemble them in a composite, package them
in an SCA contribution. I don't really know what a WAR or an EAR is, 
I'm

just using the SCA programming model and packaging model. I deploy my
SCA contribution to Geronimo and run it there.

This will require a tuscany specific deployer that is installed as
part of the plugin. Ususally deployers have access to a server
specific deployment plan at some fixed path say
(META-INF/geronimo-tuscany.xml). If this file is found then the
deployer will know that the module that was supplied to it is a
tuscany module. In case I am deploying a tuscany contribution using
the sca packaging model then there will be a .composite file somewhere
in the module and the deployer will have to search in the module for
scdl files.  For now the tuscany  contributions will always be
packaged as jars.


I'm not a geronimo expert. My understanding is that the Tuscany deployer 
needs a way to recognize the archive is a SCA contribution. It could
be an external deployment plan such as genronimo-tuscany.xml. If the 
deployment plan is not present, then a SCA "deployment descriptor" will be
checked. The SCA assembly spec doesn't define a mandatory deployment 
descriptor. We might be able to use "META-INF/sca-contributions.xml" as

a starting point.



This will mean that if the deployer finds this file then it will
handle the module as a tuscany module and if not found relinquish
control to other deployers.



The SCA contribution itself can be an EAR. I assume an archive can be 
processed by multiple deployers.



Now we come to the question of the Domain. This has been a vexing
question for me. I think that going for a single SCADomain for the
entire server would be a good place to start.
All the applications will have an application composite and that
composite will be deployed on the server wide SCADomain. What the
server wide SCADomain should provide is the ability to add and remove
composites at runtime. If I am not mistaken this will be supported by
the EmbeddedSCADomain. Can someone in the know comment on this.


We can start with a local SCA domain for the Geronimo server. 
EmbeddedSCADomain is the right class and it can be extended to support the 
Geronimo host.




The other logical approach would be to go for different partial
SCADomain instances per contribution. These different instances will
still have information about the other instances and will do the
wiring across the instances that constitute a complete SCADomain.
From what I could find, this type of an SCADomain is not
supported currently. There is work on an SCADomain spanning multiple
runtimes. This would be a simpler case of an SCADomain spanning
multiple classloaders or (configurations in Geronimo).



SCADomain can span multiple runtimes. Simon Laws from Tuscany is driving the 
support of distributed SCADomain. I'm a bit confused by the statement

"different partial SCADomain instances per contribution". Can you clarify?


The reason for not going with the second approach is that it is not
available in tuscany as of today. Please correct me if I am wrong.

(b) This was point (c) in Sebastien's mail.
  I want to use a Web app in my SCA assembly and call SCA components
  from it. I should be able to declare an SCA component representing 
my
  Web app, wire that component to other SCA components in the 
assembly,
  and then magically the wired references will be available as proxies 
for

  use in my JSPs, allowing me to call an SCA component using a simple
  jsp:useBean tag.

In addition to this the J2EE integration whitepaper at the OSOA
site mentions abt being able to annotate Web
artifacts(servlets,filters etc) with the SCA Annotations and get
services injected into servlets/filters etc for usage. The wiring will
be done by the SCA runtime. The whitepaper is here
http://www.osoa.org/pages/viewpage.action?pageId=3980.

The things to be done for achieving this functionality are,

1) Create a new implementation type in Tuscany namely implementation.web.
2) Declare in a .composite file in the war that the war is an
implementation.web type
3) The implementation.web tuscany extension will have functionality
to introspect the web module classes for SCA specific annotations and
build up information. Since there is a single SCADomain instance per
se

Re: Specific versions of Redhat

[haleh mahbod]

Is this a question for Native SCA or Java SCA?

On 7/3/07, Kevin Mayer <[EMAIL PROTECTED]> wrote:


This is in reference to minor issue TUSCANY-849 and SCA
GettingStarted.html.  The versions of Linux Redhat identified are Redhat
Enterprise Linux v3, Redhat Enterprise Linux v4.  What are the update
versions of v3 and v4?

thank you,

Kevin Mayer
Quality Assurance Engineering
Rogue Wave Software
[EMAIL PROTECTED]
303-545-3194

Subscription

[Mahboob Hussain]

Hi,

Please add me to this mailing list.

Thanks
Mahboob


 

Never miss an email again!
Yahoo! Toolbar alerts you the instant new Mail arrives.
http://tools.search.yahoo.com/toolbar/features/mail/

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

Re: Subscription

[kelvin goodson]

Hi Mahboob,
 welcome to Tuscany.  You need to subscribe yourself to the list(s) by
following the instructions at
http://incubator.apache.org/tuscany/mailing-lists.html

Regards, Kelvin.


On 03/07/07, Mahboob Hussain <[EMAIL PROTECTED]> wrote:


Hi,

Please add me to this mailing list.

Thanks
Mahboob





Never miss an email again!
Yahoo! Toolbar alerts you the instant new Mail arrives.
http://tools.search.yahoo.com/toolbar/features/mail/

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

Re: [DISCUSS] Geronimo-Tuscany integration(Sending to both lists)

[Simon Laws]

On 7/3/07, Raymond Feng <[EMAIL PROTECTED]> wrote:


Hi,

Please see my comments inline.

Thanks,
Raymond

- Original Message -
From: "Manu George" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: 
Sent: Tuesday, July 03, 2007 7:53 AM
Subject: Re: [DISCUSS] Geronimo-Tuscany integration(Sending to both lists)


> Hi ,
>From Paul's mail I guess a Geronimo plugin would be
> the way forward. I am going to list down a few more questions on the
> scenarios that Sebastien has explained. The scenarios are given first
> and then my understanding, approach and issues. I would be just
> listing two of the scenarios and trying to implement them initially.
>
> (a) I develop SCA components, assemble them in a composite, package them
> in an SCA contribution. I don't really know what a WAR or an EAR is,
> I'm
> just using the SCA programming model and packaging model. I deploy
my
> SCA contribution to Geronimo and run it there.
>
> This will require a tuscany specific deployer that is installed as
> part of the plugin. Ususally deployers have access to a server
> specific deployment plan at some fixed path say
> (META-INF/geronimo-tuscany.xml). If this file is found then the
> deployer will know that the module that was supplied to it is a
> tuscany module. In case I am deploying a tuscany contribution using
> the sca packaging model then there will be a .composite file somewhere
> in the module and the deployer will have to search in the module for
> scdl files.  For now the tuscany  contributions will always be
> packaged as jars.

I'm not a geronimo expert. My understanding is that the Tuscany deployer
needs a way to recognize the archive is a SCA contribution. It could
be an external deployment plan such as genronimo-tuscany.xml. If the
deployment plan is not present, then a SCA "deployment descriptor" will be
checked. The SCA assembly spec doesn't define a mandatory deployment
descriptor. We might be able to use "META-INF/sca-contributions.xml" as
a starting point.

>
> This will mean that if the deployer finds this file then it will
> handle the module as a tuscany module and if not found relinquish
> control to other deployers.
>

The SCA contribution itself can be an EAR. I assume an archive can be
processed by multiple deployers.

> Now we come to the question of the Domain. This has been a vexing
> question for me. I think that going for a single SCADomain for the
> entire server would be a good place to start.
> All the applications will have an application composite and that
> composite will be deployed on the server wide SCADomain. What the
> server wide SCADomain should provide is the ability to add and remove
> composites at runtime. If I am not mistaken this will be supported by
> the EmbeddedSCADomain. Can someone in the know comment on this.

We can start with a local SCA domain for the Geronimo server.
EmbeddedSCADomain is the right class and it can be extended to support the
Geronimo host.

>
> The other logical approach would be to go for different partial
> SCADomain instances per contribution. These different instances will
> still have information about the other instances and will do the
> wiring across the instances that constitute a complete SCADomain.
> From what I could find, this type of an SCADomain is not
> supported currently. There is work on an SCADomain spanning multiple
> runtimes. This would be a simpler case of an SCADomain spanning
> multiple classloaders or (configurations in Geronimo).
>

SCADomain can span multiple runtimes. Simon Laws from Tuscany is driving
the
support of distributed SCADomain. I'm a bit confused by the statement
"different partial SCADomain instances per contribution". Can you clarify?

> The reason for not going with the second approach is that it is not
> available in tuscany as of today. Please correct me if I am wrong.
>
> (b) This was point (c) in Sebastien's mail.
>   I want to use a Web app in my SCA assembly and call SCA components
>   from it. I should be able to declare an SCA component representing
> my
>   Web app, wire that component to other SCA components in the
> assembly,
>   and then magically the wired references will be available as
proxies
> for
>   use in my JSPs, allowing me to call an SCA component using a
simple
>   jsp:useBean tag.
>
> In addition to this the J2EE integration whitepaper at the OSOA
> site mentions abt being able to annotate Web
> artifacts(servlets,filters etc) with the SCA Annotations and get
> services injected into servlets/filters etc for usage. The wiring will
> be done by the SCA runtime. The whitepaper is here
> http://www.osoa.org/pages/viewpage.action?pageId=3980.
>
> The things to be done for achieving this functionality are,
>
> 1) Create a new implementation type in Tuscany namely implementation.web
.
> 2) Declare in a .composite file in the war that the war is an
> implementation.web type
> 3) The implementation.web tuscany extension wil

[jira] Created: (TUSCANY-1408) Cannot programmatically define a SDO property matching to XSD element

[Fuhwei Lwo (JIRA)]

Cannot programmatically define a SDO property matching to XSD element
-

 Key: TUSCANY-1408
 URL: https://issues.apache.org/jira/browse/TUSCANY-1408
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Implementation
Affects Versions: Java-SDO-1.0
 Environment: WinXP
Reporter: Fuhwei Lwo
 Fix For: Java-SDO-1.0


The following code will define XSD attributes for "name" and "address" 
properties. I cannot find a way to define them as XSD elements.

HelperContext hc = HelperProvider.getDefaultContext();
DataFactory dataFactory = hc.getDataFactory();

TypeHelper types = hc.getTypeHelper();
Type stringType = types.getType("commonj.sdo", "String");

DataObject customerType = dataFactory.create("commonj.sdo","Type");
customerType.set("uri", "http://sample.data/customer";);
customerType.set("name", "Customer");

//create customer name property
DataObject custNameProperty = customerType.createDataObject("property");
custNameProperty.set("name", "name");
custNameProperty.set("type", stringType);

//create address property
DataObject addressProperty = customerType.createDataObject("property");
addressProperty.set("name", "address");
addressProperty.set("type", stringType);

//now define the Customer type so that customers can be made
Type typeDefined = types.define(customerType);

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

RE: Specific versions of Redhat

[Brady Johnson]

I would be interested in knowing both.

Thanks


Brady Johnson
Lead Software Developer - HydraSCA
Rogue Wave Software - [EMAIL PROTECTED]
 

-Original Message-
From: haleh mahbod [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, July 03, 2007 1:26 PM
To: tuscany-dev@ws.apache.org
Subject: Re: Specific versions of Redhat

Is this a question for Native SCA or Java SCA?

On 7/3/07, Kevin Mayer <[EMAIL PROTECTED]> wrote:
>
> This is in reference to minor issue TUSCANY-849 and SCA 
> GettingStarted.html.  The versions of Linux Redhat identified are 
> Redhat Enterprise Linux v3, Redhat Enterprise Linux v4.  What are the 
> update versions of v3 and v4?
>
> thank you,
>
> Kevin Mayer
> Quality Assurance Engineering
> Rogue Wave Software
> [EMAIL PROTECTED]
> 303-545-3194
>
>

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

[jira] Commented: (TUSCANY-1408) Cannot programmatically define a SDO property matching to XSD element

[Fuhwei Lwo (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-1408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12510010
 ] 

Fuhwei Lwo commented on TUSCANY-1408:
-

Using SDO client code above, I propose the user can do something like below to 
specify whether the property is an XSD attribute or element.

Property xmlElementProp = 
hc.getXSDHelper().getGlobalProperty("commonj.sdo/xml", "xmlElement", false);
custNameProperty.set(xmlElementProp, true);  // this SDO property is an XSD 
element

The question is without setting xmlElement value, should we treat the property 
as an attribute or element? Current implementation is default to an attribute. 
Should we change to element? The SDO 2.1 spec didn't mention so it's up to us.

Fuhwei

> Cannot programmatically define a SDO property matching to XSD element
> -
>
> Key: TUSCANY-1408
> URL: https://issues.apache.org/jira/browse/TUSCANY-1408
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Implementation
>Affects Versions: Java-SDO-1.0
> Environment: WinXP
>Reporter: Fuhwei Lwo
> Fix For: Java-SDO-1.0
>
>
> The following code will define XSD attributes for "name" and "address" 
> properties. I cannot find a way to define them as XSD elements.
> HelperContext hc = HelperProvider.getDefaultContext();
> DataFactory dataFactory = hc.getDataFactory();
> TypeHelper types = hc.getTypeHelper();
> Type stringType = types.getType("commonj.sdo", "String");
> 
> DataObject customerType = dataFactory.create("commonj.sdo","Type");
> customerType.set("uri", "http://sample.data/customer";);
> customerType.set("name", "Customer");
> //create customer name property
> DataObject custNameProperty = customerType.createDataObject("property");
> custNameProperty.set("name", "name");
> custNameProperty.set("type", stringType);
> //create address property
> DataObject addressProperty = customerType.createDataObject("property");
> addressProperty.set("name", "address");
> addressProperty.set("type", stringType);
> //now define the Customer type so that customers can be made
> Type typeDefined = types.define(customerType);

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

Re: Specific versions of Redhat

[Pete Robbins]

RHEL3 is what my linux claims to be! I assume RHEL4 is a later
version? Early milestone releases of Tuscany C++ provided a binary
release which was probably built on one of these platforms. From M3 we
only provide a source release for linux/Mac OSX.

Cheers,

On 03/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:


I would be interested in knowing both.

Thanks


Brady Johnson
Lead Software Developer - HydraSCA
Rogue Wave Software - [EMAIL PROTECTED]


-Original Message-
From: haleh mahbod [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 03, 2007 1:26 PM
To: tuscany-dev@ws.apache.org
Subject: Re: Specific versions of Redhat

Is this a question for Native SCA or Java SCA?

On 7/3/07, Kevin Mayer <[EMAIL PROTECTED]> wrote:
>
> This is in reference to minor issue TUSCANY-849 and SCA
> GettingStarted.html.  The versions of Linux Redhat identified are
> Redhat Enterprise Linux v3, Redhat Enterprise Linux v4.  What are the
> update versions of v3 and v4?
>
> thank you,
>
> Kevin Mayer
> Quality Assurance Engineering
> Rogue Wave Software
> [EMAIL PROTECTED]
> 303-545-3194
>
>

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





--
Pete

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

Re: Specific versions of Redhat

[Pete Robbins]

of course Java is write-once-run-anywhere so should be independent of
platforrm ;-)

On 03/07/07, Pete Robbins <[EMAIL PROTECTED]> wrote:

RHEL3 is what my linux claims to be! I assume RHEL4 is a later
version? Early milestone releases of Tuscany C++ provided a binary
release which was probably built on one of these platforms. From M3 we
only provide a source release for linux/Mac OSX.

Cheers,

On 03/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
>
> I would be interested in knowing both.
>
> Thanks
>
> 
> Brady Johnson
> Lead Software Developer - HydraSCA
> Rogue Wave Software - [EMAIL PROTECTED]
>
>
> -Original Message-
> From: haleh mahbod [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, July 03, 2007 1:26 PM
> To: tuscany-dev@ws.apache.org
> Subject: Re: Specific versions of Redhat
>
> Is this a question for Native SCA or Java SCA?
>
> On 7/3/07, Kevin Mayer <[EMAIL PROTECTED]> wrote:
> >
> > This is in reference to minor issue TUSCANY-849 and SCA
> > GettingStarted.html.  The versions of Linux Redhat identified are
> > Redhat Enterprise Linux v3, Redhat Enterprise Linux v4.  What are the
> > update versions of v3 and v4?
> >
> > thank you,
> >
> > Kevin Mayer
> > Quality Assurance Engineering
> > Rogue Wave Software
> > [EMAIL PROTECTED]
> > 303-545-3194
> >
> >
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


--
Pete




--
Pete

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

RE: Specific versions of Redhat

[Brady Johnson]

Ya, I realized that about Java once I read it. :)

Regarding the versions for C++, I was also curious the update version,
if you guys went into that much detail.

For RHEL3, we use Redhat 3 update 6. For RHEL4, we have seen some subtle
differences between Redhat 4 update 2 and update 4.

Brady

-Original Message-
From: Pete Robbins [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, July 03, 2007 4:13 PM
To: tuscany-dev@ws.apache.org
Subject: Re: Specific versions of Redhat

of course Java is write-once-run-anywhere so should be independent of
platforrm ;-)

On 03/07/07, Pete Robbins <[EMAIL PROTECTED]> wrote:
> RHEL3 is what my linux claims to be! I assume RHEL4 is a later 
> version? Early milestone releases of Tuscany C++ provided a binary 
> release which was probably built on one of these platforms. From M3 we

> only provide a source release for linux/Mac OSX.
>
> Cheers,
>
> On 03/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
> >
> > I would be interested in knowing both.
> >
> > Thanks
> >
> > 
> > Brady Johnson
> > Lead Software Developer - HydraSCA
> > Rogue Wave Software - [EMAIL PROTECTED]
> >
> >
> > -Original Message-
> > From: haleh mahbod [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, July 03, 2007 1:26 PM
> > To: tuscany-dev@ws.apache.org
> > Subject: Re: Specific versions of Redhat
> >
> > Is this a question for Native SCA or Java SCA?
> >
> > On 7/3/07, Kevin Mayer <[EMAIL PROTECTED]> wrote:
> > >
> > > This is in reference to minor issue TUSCANY-849 and SCA 
> > > GettingStarted.html.  The versions of Linux Redhat identified are 
> > > Redhat Enterprise Linux v3, Redhat Enterprise Linux v4.  What are 
> > > the update versions of v3 and v4?
> > >
> > > thank you,
> > >
> > > Kevin Mayer
> > > Quality Assurance Engineering
> > > Rogue Wave Software
> > > [EMAIL PROTECTED]
> > > 303-545-3194
> > >
> > >
> >
> > 
> > - To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
> --
> Pete
>


--
Pete

-
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: Specific versions of Redhat

[Pete Robbins]

That was one reason why we only distribute source for linux now. It
always works best with the "local" compiler/libraries! Also the number
of distribution packages could get out of hand if we add in binary
distros for different Linuxes and Mac.

Cheers,

On 03/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:


Ya, I realized that about Java once I read it. :)

Regarding the versions for C++, I was also curious the update version,
if you guys went into that much detail.

For RHEL3, we use Redhat 3 update 6. For RHEL4, we have seen some subtle
differences between Redhat 4 update 2 and update 4.

Brady

-Original Message-
From: Pete Robbins [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 03, 2007 4:13 PM
To: tuscany-dev@ws.apache.org
Subject: Re: Specific versions of Redhat

of course Java is write-once-run-anywhere so should be independent of
platforrm ;-)

On 03/07/07, Pete Robbins <[EMAIL PROTECTED]> wrote:
> RHEL3 is what my linux claims to be! I assume RHEL4 is a later
> version? Early milestone releases of Tuscany C++ provided a binary
> release which was probably built on one of these platforms. From M3 we

> only provide a source release for linux/Mac OSX.
>
> Cheers,
>
> On 03/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
> >
> > I would be interested in knowing both.
> >
> > Thanks
> >
> > 
> > Brady Johnson
> > Lead Software Developer - HydraSCA
> > Rogue Wave Software - [EMAIL PROTECTED]
> >
> >
> > -Original Message-
> > From: haleh mahbod [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, July 03, 2007 1:26 PM
> > To: tuscany-dev@ws.apache.org
> > Subject: Re: Specific versions of Redhat
> >
> > Is this a question for Native SCA or Java SCA?
> >
> > On 7/3/07, Kevin Mayer <[EMAIL PROTECTED]> wrote:
> > >
> > > This is in reference to minor issue TUSCANY-849 and SCA
> > > GettingStarted.html.  The versions of Linux Redhat identified are
> > > Redhat Enterprise Linux v3, Redhat Enterprise Linux v4.  What are
> > > the update versions of v3 and v4?
> > >
> > > thank you,
> > >
> > > Kevin Mayer
> > > Quality Assurance Engineering
> > > Rogue Wave Software
> > > [EMAIL PROTECTED]
> > > 303-545-3194
> > >
> > >
> >
> > 
> > - To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
> --
> Pete
>


--
Pete

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





--
Pete

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

Re: NoClassDefFoundError for DefaultContributionPostProcessorExtensionPoint

[Simon Nash]

I found the problem eventually.  There's a bad pom.xml file in
samples/simple-callback-ws.  Everywhere that
  0.90-incubating
appears in this file, it needs to be changed to
  1.0-incubating-SNAPSHOT

  Simon

Simon Nash wrote:

I'm getting the following error from the new simple-callback-ws sample
when I run a full top-level mvn build against my test codebase that has
the latest incarnation of the fix to TUSCANY-1341.  The problem doesn't
occur when I run mvn from the samples directory, or when I run mvn from
the samples/simple-callback-ws directory.  I haven't made any code
changes that seem like they could cause this error.  Has anyone seen
this before, or are there any suggestions for debugging?

  Simon

---
 T E S T S
---
Running simplecallback.SimpleCallbackTestCase
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.381 
sec <<< FAILURE!
test(simplecallback.SimpleCallbackTestCase)  Time elapsed: 0.311 sec  
<<< ERROR!
java.lang.NoClassDefFoundError: 
org/apache/tuscany/sca/contribution/processor/DefaultContributionPostProcessorExtensionPoint 

at 
org.apache.tuscany.sca.host.embedded.impl.ReallySmallRuntimeBuilder.createContributionService(ReallySmallRuntimeBuilder.java:189) 

at 
org.apache.tuscany.sca.host.embedded.impl.ReallySmallRuntime.start(ReallySmallRuntime.java:113) 

at 
org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.(DefaultSCADomain.java:86) 

at 
org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:229) 

at 
org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SCADomain.java:68) 

at 
simplecallback.SimpleCallbackTestCase.setUp(SimpleCallbackTestCase.java:34)

at junit.framework.TestCase.runBare(TestCase.java:132)
at junit.framework.TestResult$1.protect(TestResult.java:110)
at junit.framework.TestResult.runProtected(TestResult.java:128)
at junit.framework.TestResult.run(TestResult.java:113)
at junit.framework.TestCase.run(TestCase.java:124)
at junit.framework.TestSuite.runTest(TestSuite.java:232)
at junit.framework.TestSuite.run(TestSuite.java:227)
at 
org.junit.internal.runners.OldTestClassRunner.run(OldTestClassRunner.java:35) 

at 
org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62) 

at 
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138) 

at 
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125) 


at org.apache.maven.surefire.Surefire.run(Surefire.java:132)
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.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:290) 

at 
org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:818) 




Results :

Tests in error:
  test(simplecallback.SimpleCallbackTestCase)



-
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: SCA binding and wiring

[Simon Nash]

I am deep into reworking my patch for TUSCANY-1341.  It contains
some changes that should help with this.  When I emerge later this
week with the new patch and we can get the patch applied, I'd like
to help with the second stage of this work as described by SimonL.
I think my patch will be a step in the right direction, and we
can take things forward from there.

  Simon

Raymond Feng wrote:


Hi,

Please see my comments inline.

Thanks,
Raymond

- Original Message - From: "Simon Laws" <[EMAIL PROTECTED]>
To: "tuscany-dev" 
Sent: Tuesday, July 03, 2007 6:20 AM
Subject: SCA binding and wiring



The SCA binding provides the default binding and appears when the user
doesn't explicitly provide a binding against a reference or a service. 
The

Tuscany runtime can use the SCA binding to implement local wires between
components running in the same VM or remote wires between components 
running

on different nodes.

There is a simple SCA binding implementation for the distributed 
runtime (

binding.sca) which uses JMS for remote wires. Initially the intention had
been to hide all of the remote wiring parts of binding.sca behind the
reference and service providers but there are some issues with the way 
wires

are managed with respect to the SCA binding. Specifically the ones I came
across were:

- The original SCA binding was implemented as part of the assembly 
model and
there is an amount of code that appears in the process of wiring 
references
to services that specifically checks for the presence of the SCA 
binding and

does special things in that case. I would like to ensure that the special
things that are done are a product of the binding itself rather than the
builder and activator code.



By the assembly spec, the SCA binding is "special" in two senses:
1) SCA Binding will be used if no binding element is declared for a 
service or reference
2) SCA Binding behaves differently on whether the interface is local or 
remote




- There are a number of issues about how to identify the target of a
reference in various parts of the code. I believe this primarily boils 
down

to the separation of targets and bindings, i.e. a reference has a set of
targets and a binding held independently. For example,
CompositeActivator.addBindingInterceptor() is creating binding 
providers but
is not aware of which target is being addressed. This makes it tricky 
from

within the binding to assess whether a local or remote wire is required.



To me, the "target" attribute is just a shortcut to define target URIs 
for bindings that support the addressing by the logical name 
(componentName/serviceName). SCA Binding is one of the bindings. The 
binding itself can use the "uri" attribute to declare the
target if "target" is not present. The assembly spec explicitly makes 
the "target" attribute of a reference element and "uri" attribute

of a binding element exclusive to avoid confusion.

Logically, binding should be holder of the target information. 
Reference/Binding pair is the endpoint.


There were some disucssions on the resolving of targets at:
http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200706.mbox/[EMAIL PROTECTED] 





-  If we want to have the SCA binding provide a facade of the remote 
binding

that is actually in use then there is an issue with service invokers. The
service side expects to find an invoker based on the binding service
provider for the binding type in use. If SCA binding is acting as a 
facade

the real binding type doesn't have a wire registered against it.



One option is to have the SCA binding provider to act differently based 
on the interface and co-location. For example, if the interface is local,
the access method for the reference or service is purely java invocation 
and no interceptor/listener is needed.


There may be more issues as I didn't get to the end of trying to make 
this

work before seeking an alternative.

The solution in place now for these items has been to provide methods 
on the

SCA Binding model that provide access to the remote binding that the SCA
binding is using for remote wires. During the build phase the SCA 
Binding is

replaced with the remote binding (JMS currently) and the wire creation
process continues as normal. What I would like to do is look further 
at how

we can move these features inside the SCA binding itself.



+1 to move these features inside the SCA binding. Mapping SCA binding to 
an existing protocol doesn't mean to replace the binding.sca with 
binding.xyz.
Potentially, we can map binding.sca to different protocols depending on 
co-location or asynchrony. I think the runtime will need to derive more 
metadata for SCA binding. For example, if we choose to use Web Service 
protocol for SCA binding, we need to calculate the SOAP adddress based 
on the logical

SCA names.

Does anyone have any background on the issues I mention above? Are 
there any

other features that the SCA binding should be providing?

There as been much

Re: NoClassDefFoundError for DefaultContributionPostProcessorExtensionPoint

[Luciano Resende]

I have already changed that under revision #552945 as part of the fix
for tuscany-1407

On 7/3/07, Simon Nash <[EMAIL PROTECTED]> wrote:

I found the problem eventually.  There's a bad pom.xml file in
samples/simple-callback-ws.  Everywhere that
   0.90-incubating
appears in this file, it needs to be changed to
   1.0-incubating-SNAPSHOT

   Simon

Simon Nash wrote:
> I'm getting the following error from the new simple-callback-ws sample
> when I run a full top-level mvn build against my test codebase that has
> the latest incarnation of the fix to TUSCANY-1341.  The problem doesn't
> occur when I run mvn from the samples directory, or when I run mvn from
> the samples/simple-callback-ws directory.  I haven't made any code
> changes that seem like they could cause this error.  Has anyone seen
> this before, or are there any suggestions for debugging?
>
>   Simon
>
> ---
>  T E S T S
> ---
> Running simplecallback.SimpleCallbackTestCase
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.381
> sec <<< FAILURE!
> test(simplecallback.SimpleCallbackTestCase)  Time elapsed: 0.311 sec
> <<< ERROR!
> java.lang.NoClassDefFoundError:
> 
org/apache/tuscany/sca/contribution/processor/DefaultContributionPostProcessorExtensionPoint
>
> at
> 
org.apache.tuscany.sca.host.embedded.impl.ReallySmallRuntimeBuilder.createContributionService(ReallySmallRuntimeBuilder.java:189)
>
> at
> 
org.apache.tuscany.sca.host.embedded.impl.ReallySmallRuntime.start(ReallySmallRuntime.java:113)
>
> at
> 
org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.(DefaultSCADomain.java:86)
>
> at
> 
org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:229)
>
> at
> org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SCADomain.java:68)
>
> at
> simplecallback.SimpleCallbackTestCase.setUp(SimpleCallbackTestCase.java:34)
> at junit.framework.TestCase.runBare(TestCase.java:132)
> at junit.framework.TestResult$1.protect(TestResult.java:110)
> at junit.framework.TestResult.runProtected(TestResult.java:128)
> at junit.framework.TestResult.run(TestResult.java:113)
> at junit.framework.TestCase.run(TestCase.java:124)
> at junit.framework.TestSuite.runTest(TestSuite.java:232)
> at junit.framework.TestSuite.run(TestSuite.java:227)
> at
> org.junit.internal.runners.OldTestClassRunner.run(OldTestClassRunner.java:35)
>
> at
> org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
>
> at
> 
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138)
>
> at
> 
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125)
>
> at org.apache.maven.surefire.Surefire.run(Surefire.java:132)
> 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.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:290)
>
> at
> org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:818)
>
>
>
> Results :
>
> Tests in error:
>   test(simplecallback.SimpleCallbackTestCase)
>
>
>
> -
> 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]





--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/

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

RE: Specific versions of Redhat

[Kevin Mayer]

Native SCA

-Original Message-
From: haleh mahbod [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 03, 2007 1:26 PM
To: tuscany-dev@ws.apache.org
Subject: Re: Specific versions of Redhat

Is this a question for Native SCA or Java SCA?

On 7/3/07, Kevin Mayer <[EMAIL PROTECTED]> wrote:
>
> This is in reference to minor issue TUSCANY-849 and SCA 
> GettingStarted.html.  The versions of Linux Redhat identified are 
> Redhat Enterprise Linux v3, Redhat Enterprise Linux v4.  What are the 
> update versions of v3 and v4?
>
> thank you,
>
> Kevin Mayer
> Quality Assurance Engineering
> Rogue Wave Software
> [EMAIL PROTECTED]
> 303-545-3194
>
>

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

[jira] Resolved: (TUSCANY-1403) DAS Source distribution extract to same directory as Binary distribution

[Luciano Resende (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Luciano Resende resolved TUSCANY-1403.
--

Resolution: Fixed

Fixed both in trunk and beta1 branch

> DAS Source distribution extract to same directory as Binary distribution
> 
>
> Key: TUSCANY-1403
> URL: https://issues.apache.org/jira/browse/TUSCANY-1403
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java DAS RDB
>Affects Versions: Java-DAS-beta1
>Reporter: Luciano Resende
>Assignee: Luciano Resende
>Priority: Minor
> Fix For: Java-DAS-beta1
>
>


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Resolved: (TUSCANY-1401) Incompatible SDO code being generated if different version of tuscany-sdo-plugin is already available

[Luciano Resende (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Luciano Resende resolved TUSCANY-1401.
--

Resolution: Fixed

Fixed both in trunk and beta1 branch

> Incompatible SDO code being generated if different version of 
> tuscany-sdo-plugin is already available
> -
>
> Key: TUSCANY-1401
> URL: https://issues.apache.org/jira/browse/TUSCANY-1401
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java DAS RDB
>Affects Versions: Java-DAS-beta1
>Reporter: Luciano Resende
>Assignee: Luciano Resende
>Priority: Critical
> Fix For: Java-DAS-beta1
>
>
> The das\rcb\pom.xml does not specify a sdo-plugin version and this causes 
> different issues if a different version of the plugin is already available 
> (e.g if you build from trunk before building from DAS beta1 source.)
> This is what is causing the issue reported by Simon Laws [1]
> [1] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg19491.html

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Commented: (TUSCANY-1404) Detail DAS samples' readme

[Adriano Crestani (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-1404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12510073
 ] 

Adriano Crestani commented on TUSCANY-1404:
---

detailed customer sample's readme

> Detail DAS samples' readme
> --
>
> Key: TUSCANY-1404
> URL: https://issues.apache.org/jira/browse/TUSCANY-1404
> Project: Tuscany
>  Issue Type: Improvement
>  Components: Java DAS RDB
>Affects Versions: Java-DAS-beta1
>Reporter: Adriano Crestani
>Assignee: Adriano Crestani
>Priority: Critical
> Fix For: Java-DAS-beta1
>
>
> - Create a readme on DAS samples' top level dir that summarizes all DAS 
> samples
> - Detail how to run and use customer sample on its readme

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Resolved: (TUSCANY-1404) Detail DAS samples' readme

[Adriano Crestani (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Adriano Crestani resolved TUSCANY-1404.
---

Resolution: Fixed

> Detail DAS samples' readme
> --
>
> Key: TUSCANY-1404
> URL: https://issues.apache.org/jira/browse/TUSCANY-1404
> Project: Tuscany
>  Issue Type: Improvement
>  Components: Java DAS RDB
>Affects Versions: Java-DAS-beta1
>Reporter: Adriano Crestani
>Assignee: Adriano Crestani
>Priority: Critical
> Fix For: Java-DAS-beta1
>
>
> - Create a readme on DAS samples' top level dir that summarizes all DAS 
> samples
> - Detail how to run and use customer sample on its readme

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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