Re: [C++] Interface descriptions and type conversions
On 2/5/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Simon Laws wrote: On 2/2/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Simon Laws wrote: On 2/1/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Simon Laws wrote: I notice in implementing the PHP extension (yes - believe it or not I'm nearly ready to make a patch for the next version ;-) that, given the way that I have implemented the PHP extension there is insufficient information available in the SCA runtime in order to do correct type conversions when passing messages between components. I imagine this has been raised before but I looked at the archive and couldn't find a relevant thread. Imagine the scenario: C++ Component (ComponentA) ---WireA--- PHP Component (ComponentB) ---WireB C++ Component (ComponentC) Currently the build process looks at the header files described in the component type files and generates wrappers and proxies for the C++ components. I have currently implemented the PHP Extension to use generic wrappers and proxies, i.e. it doesn't use those generated based on the interface descriptions, so they need to dynamically manage the type conversions for data coming in and going out of a PHP component. WireA. This is OK because the C++ SCA operation object that appears at Component B has a set of data/types based on the generated proxy. The PHP extension can look at this and effect the right type conversions. WireB This is problematic. The dynamic PHP proxy has to generate an operation object to pass to the the wrapper of ComponentC. The issue is that there is, as far as I can tell, no dynamic way of getting at the list of types that are expected for any particular operation. There is of course a static C++ proxy/wrapper combination that has been generated but I can't inspect it at runtime. I'm not keen on generating PHP specific interface classes. PHP is a dynamic environment and it's a whole stack of extra files we could do without having to manage particularly if we have to adapt the generator for every extension that's constructed. Can we extend the wrapper/proxy mechanism to encapsulate a runtime list of required types alongside the static method descriptions that are already generated? We would need this to work for script to script calls as well as for the script/C++ combination so maybe we need something that hangs off the interface description part of the model. I'm not that familiar with how that part of the model is used so a little investigation is required. Thoughts? Simon Simon, It's an interesting issue. To explore it let's walk through the wiring scenario you describe and assume the following: - ComponentA (C++) - WireA - ComponentB (PHP) - WireB - ComponentC (C++) - ComponentA (C++) passes a short int to ComponentB (PHP) - ComponentB executes a PHP script which in turn passes a number to ComponentC (C++) - ComponentC expects that number to be given as a long int. Here's what I think should happen in the runtime: 1. At the source of WireA, a generated C++ CPPServiceProxy adds to our Operation object a Parameter of a type decided by the C++ client code: a C++ short int, with type == ParameterType::SHORT. 2. At the end of WireA, a PHPServiceWrapper converts that parameter to what the PHP script expects, for the sake of simplicity now I am going to assume that it needs to convert it to a C++ std::string. 3. The PHP script executes, now passes an std::string containing a number to the PHPServiceProxy at the source of WireB. 4. The PHPServiceProxy does not have much type info about that std::string parameter and can only add it to the Operation object as a std::string with type == ParameterType::STRING. 5. The CPPServiceWrapper at the end of WireB (actually the C++ ServiceWrapper generated for ComponentC) receives the std::string and should convert it to what ComponentC expects: a long int. The general idea is that a ServiceProxy sends what it is given (or picks the most natural type out of the ParameterTypes that we have defined and converts the data to it). A ServiceWrapper converts what it receives to the type expected by the code it wraps. I think that the CPPServiceWrapper code and the generated C++ ServiceWrappers are simply missing the logic to convert data to what the target expects. At the moment this limitation also prevents a C++ method getCustomer(long customerID) to be exposed as a REST service for example, as the generated C++ ServiceWrapper is missing the logic to convert the customerID received in string form from the REST query string to the expected C++ long int. So we just need to add the missing type conversion logic to the C++ ServiceWrappers :)
[jira] Resolved: (TUSCANY-1083) Shorter NameSpace prefix to speed up XML processing and reduce communication bandwidth
[ https://issues.apache.org/jira/browse/TUSCANY-1083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson resolved TUSCANY-1083. - Resolution: Fixed Shorter NameSpace prefix to speed up XML processing and reduce communication bandwidth -- Key: TUSCANY-1083 URL: https://issues.apache.org/jira/browse/TUSCANY-1083 Project: Tuscany Issue Type: Improvement Components: Java SDO Implementation Affects Versions: Java-SDO-Mx Reporter: Yang ZHONG Fix For: Java-SDO-Mx Attachments: prefix.xsd, ShortPrefix Given XSD: schema xmlns=http://www.w3.org/2001/XMLSchema; targetNamespace=http://soaassureservice.soabench.ibm.com; xmlns:as=http://soaassureservice.soabench.ibm.com; element name=requestInfo type=string/ element name=createClaim ... SDO generates NameSpace prefix too long: soaassureservice:createClaim xmlns:soaassureservice=http://soaassureservice.soabench.ibm.com; soaassureservice:requestInfo.../soaassureservice:requestInfo ... -- 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-1083) Shorter NameSpace prefix to speed up XML processing and reduce communication bandwidth
[ https://issues.apache.org/jira/browse/TUSCANY-1083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12470557 ] Kelvin Goodson commented on TUSCANY-1083: - I applied the patch for this after taking a good look at the SDOXSDEcoreBuilder override of getEPackage. I was trying to figure out whether we could avoid the maintenance issue of copying the whole of the superclass' method's logic into the subclass in order to tweak the behaviour, rather than a guarded call to super.getEPackage() with some subclass fixup logic applied after, but I wasn't able to make this assertion by inspection due to the early logic in the superclass method that is not guarded by the if(ePackage == null) condition. I'd be interested to know if you thought about that approach and discounted it, as the way it stands, if ever there's a fix to the superclass getEPackage method, we won't get it without copying it. Shorter NameSpace prefix to speed up XML processing and reduce communication bandwidth -- Key: TUSCANY-1083 URL: https://issues.apache.org/jira/browse/TUSCANY-1083 Project: Tuscany Issue Type: Improvement Components: Java SDO Implementation Affects Versions: Java-SDO-Mx Reporter: Yang ZHONG Fix For: Java-SDO-Mx Attachments: prefix.xsd, ShortPrefix Given XSD: schema xmlns=http://www.w3.org/2001/XMLSchema; targetNamespace=http://soaassureservice.soabench.ibm.com; xmlns:as=http://soaassureservice.soabench.ibm.com; element name=requestInfo type=string/ element name=createClaim ... SDO generates NameSpace prefix too long: soaassureservice:createClaim xmlns:soaassureservice=http://soaassureservice.soabench.ibm.com; soaassureservice:requestInfo.../soaassureservice:requestInfo ... -- 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-1096) Exception thrown when reference with many multiplicity to the element of anyType
Exception thrown when reference with many multiplicity to the element of anyType Key: TUSCANY-1096 URL: https://issues.apache.org/jira/browse/TUSCANY-1096 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-SDO-Mx Reporter: Fuhwei Lwo Fix For: Java-SDO-Mx In the XSD, a reference is defined like xsd:element ref=simple:stockQuote2 maxOccurs=unbounded/ to reference a global element defined like xsd:element name=stockQuote2 type=xsd:anyType/. If the global element type is a fixed type or reference doesn't have many multiplicity, it's working. Only the case like above will throw the following exception. java.lang.ArrayStoreException at org.eclipse.emf.common.util.BasicEList.assign(BasicEList.java:188) at org.eclipse.emf.common.util.BasicEList.addAllUnique(BasicEList.java:774) at org.eclipse.emf.common.notify.impl.NotifyingListImpl.doAddAllUnique(NotifyingListImpl.java:494) at org.eclipse.emf.common.notify.impl.NotifyingListImpl.addAllUnique(NotifyingListImpl.java:467) at org.eclipse.emf.common.notify.impl.NotifyingListImpl.addAllUnique(NotifyingListImpl.java:396) at org.eclipse.emf.common.util.BasicEList.addAll(BasicEList.java:688) at org.eclipse.emf.ecore.util.EcoreEList.set(EcoreEList.java:448) at org.eclipse.emf.ecore.impl.EStructuralFeatureImpl$InternalSettingDelegateMany.dynamicSet(EStructuralFeatureImpl.java:1647) at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eDynamicSet(BasicEObjectImpl.java:709) at org.apache.tuscany.sdo.impl.DynamicDataObjectImpl.eDynamicSet(DynamicDataObjectImpl.java:159) at org.apache.tuscany.sdo.impl.DataObjectImpl.eSet(DataObjectImpl.java:1450) at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eSet(BasicEObjectImpl.java:654) at org.apache.tuscany.sdo.impl.DataObjectImpl.set(DataObjectImpl.java:143) at org.apache.tuscany.sdo.util.DataObjectUtil.set(DataObjectUtil.java:744) at org.apache.tuscany.sdo.impl.DataObjectImpl.setList(DataObjectImpl.java:536) at org.apache.tuscany.sdo.test.ReferenceTestCase.testDynamic(ReferenceTestCase.java:77) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at junit.framework.TestCase.runTest(TestCase.java:154) at junit.framework.TestCase.runBare(TestCase.java:127) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:128) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196) -- 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-1096) Exception thrown when reference with many multiplicity to the element of anyType
[ https://issues.apache.org/jira/browse/TUSCANY-1096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fuhwei Lwo updated TUSCANY-1096: Attachment: ReferenceTestCase.java reftest.xsd Attached 2 files to demonstrate the scenario. Exception thrown when reference with many multiplicity to the element of anyType Key: TUSCANY-1096 URL: https://issues.apache.org/jira/browse/TUSCANY-1096 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-SDO-Mx Reporter: Fuhwei Lwo Fix For: Java-SDO-Mx Attachments: ReferenceTestCase.java, reftest.xsd In the XSD, a reference is defined like xsd:element ref=simple:stockQuote2 maxOccurs=unbounded/ to reference a global element defined like xsd:element name=stockQuote2 type=xsd:anyType/. If the global element type is a fixed type or reference doesn't have many multiplicity, it's working. Only the case like above will throw the following exception. java.lang.ArrayStoreException at org.eclipse.emf.common.util.BasicEList.assign(BasicEList.java:188) at org.eclipse.emf.common.util.BasicEList.addAllUnique(BasicEList.java:774) at org.eclipse.emf.common.notify.impl.NotifyingListImpl.doAddAllUnique(NotifyingListImpl.java:494) at org.eclipse.emf.common.notify.impl.NotifyingListImpl.addAllUnique(NotifyingListImpl.java:467) at org.eclipse.emf.common.notify.impl.NotifyingListImpl.addAllUnique(NotifyingListImpl.java:396) at org.eclipse.emf.common.util.BasicEList.addAll(BasicEList.java:688) at org.eclipse.emf.ecore.util.EcoreEList.set(EcoreEList.java:448) at org.eclipse.emf.ecore.impl.EStructuralFeatureImpl$InternalSettingDelegateMany.dynamicSet(EStructuralFeatureImpl.java:1647) at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eDynamicSet(BasicEObjectImpl.java:709) at org.apache.tuscany.sdo.impl.DynamicDataObjectImpl.eDynamicSet(DynamicDataObjectImpl.java:159) at org.apache.tuscany.sdo.impl.DataObjectImpl.eSet(DataObjectImpl.java:1450) at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eSet(BasicEObjectImpl.java:654) at org.apache.tuscany.sdo.impl.DataObjectImpl.set(DataObjectImpl.java:143) at org.apache.tuscany.sdo.util.DataObjectUtil.set(DataObjectUtil.java:744) at org.apache.tuscany.sdo.impl.DataObjectImpl.setList(DataObjectImpl.java:536) at org.apache.tuscany.sdo.test.ReferenceTestCase.testDynamic(ReferenceTestCase.java:77) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at junit.framework.TestCase.runTest(TestCase.java:154) at junit.framework.TestCase.runBare(TestCase.java:127) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:128) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196) -- 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-713) Discover and regiester new SDO types during the time of loading the XML instance document
[ https://issues.apache.org/jira/browse/TUSCANY-713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12470572 ] Kelvin Goodson commented on TUSCANY-713: Yang, I'll do this as soon as possible after we have resolved the patch issue in TUSCANY-928 Kelvin. Discover and regiester new SDO types during the time of loading the XML instance document - Key: TUSCANY-713 URL: https://issues.apache.org/jira/browse/TUSCANY-713 Project: Tuscany Issue Type: New Feature Components: Java SDO Implementation Affects Versions: Wish list Reporter: Fuhwei Lwo Fix For: Wish list Attachments: ProcessSchemaLocations.713, SchemaLocationTestCase.java, SchemaLocationTestCase.java, SchemaLocationTestCase.xml, SDOUtil.java Current SDO implementation requires one to register the SDO types before loading their instances from XML document. The new scenario is to load the XML document before registering the types. The SDO may require the XML document to provide some information to locate its schema or metadata location. Annotation may be one way to do it. The schemaLocation attribute is not sufficient because it's only a hint not necessarily a physical location. -- 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-1091) DataObjectXMLStreamReader doesn't have to repeat NameSpace declaration which impacts performance
[ https://issues.apache.org/jira/browse/TUSCANY-1091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12470579 ] Kelvin Goodson commented on TUSCANY-1091: - Hi Yang, just a quick question before I apply this. I'm not sure I'm happy about having a public setParent method that ignores the input argument and returns. It feels like we are setting a trap here. What should we be doing here? I feel this at minimum deserves a comment. Cheers, Kelvin. DataObjectXMLStreamReader doesn't have to repeat NameSpace declaration which impacts performance Key: TUSCANY-1091 URL: https://issues.apache.org/jira/browse/TUSCANY-1091 Project: Tuscany Issue Type: Improvement Components: Java SDO Implementation Affects Versions: Java-SDO-Mx Reporter: Yang ZHONG Fix For: Java-SDO-Mx Attachments: bindLessNS, simple3.xsd, XMLStreamHelper.xsd, XMLStreamHelperPerformanceTestCase.java p0:quotes3 p1:symbol3 xmlns:p1=http://www.example.com/simple3;IBM/p1:symbol3 p1:company3 xmlns:p1=http://www.example.com/simple3;IBM Corp./p1:company3 /p0:quotes3 can be optimized as p0:quotes3 xmlns:p1=http://www.example.com/simple3; p1:symbol3IBM/p1:symbol3 p1:company3IBM Corp./p1:company3 /p0:quotes3 Thanks to Fuhwei Lwo for prototyping the Test Case. I've made small changes to make use of HelperContext so that it will neither interfere nor be interfereed by other build test(s). -- 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-1093) isSet returning false when boolean set to false, or int set to 0
[
https://issues.apache.org/jira/browse/TUSCANY-1093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12470606
]
Robbie Minshall commented on TUSCANY-1093:
--
I updated my tuscany version and it seems that some changes were made to modify
this behavior. Setting boolean attribute when the type is defined in an XSD is
now working. Setting dynamically defined Boolean property still seems to fail.
Can you see anything wrong with the following test case ?
public void testIsSet_DynamicTypeDef_commonjSdoBoolean_false() throws Exception
{
// define a type with two properties
DataObject typeDef = DataFactory.INSTANCE.create(commonj.sdo, Type);
typeDef.set(uri, );
typeDef.set(name, myBooleanType);
typeDef.set(open, true);
DataObject propertyDef = typeDef.createDataObject(property);
propertyDef.set(name, b1);
Type propertyType = TypeHelper.INSTANCE.getType(commonj.sdo,
Boolean);
propertyDef.set(type,propertyType );
propertyDef.set(many, false);
propertyDef.set(containment, false);
TypeHelper.INSTANCE.define( typeDef );
// create a DataObject that uses this type
DataObject testDO = DataFactory.INSTANCE.create( , myBooleanType );
Property p = testDO.getProperty(b1);
System.out.println(testIsSet_DynamicTypeDef_Boolean_false: sdoBoolean
field type : + p.getType());
testDO.unset(p);
assertFalse(testing that property is unset after unset is called,
testDO.isSet(p));
testDO.set(p, false);
System.out.println(Set booleanField via property: + testDO.get(p) +
, isSet + testDO.isSet(p) + default + p.getDefault());
assertTrue(
testing that property is set after setting to false, value
of property is
+ testDO.get(p), testDO.isSet(p));
}
isSet returning false when boolean set to false, or int set to 0
Key: TUSCANY-1093
URL: https://issues.apache.org/jira/browse/TUSCANY-1093
Project: Tuscany
Issue Type: Bug
Components: Java SDO Implementation
Reporter: Robbie Minshall
Priority: Critical
when boolean property is set to false a call to isSet returns false ( should
return true ).
when an int property is set to 0 a call to isSet returns false ( should
return true ).
This causes DataObject serialization ( our scenario involves using the sca ws
binding ) to be missing values that have been set.
--
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]
Queries related in the Trunk
Hi Jeremy, Jim, Meeraj, I assume that runtime/standalone/assembly is going to be the way a SCA Runtime will be started. Is this right? Is there any test or sample in the trunk that can be used to understand how to program a sca client for example things like how to get hold of a ComponentContext and use methods over it. Could you please help with some pointers? Thanks - Venkat
[jira] Commented: (TUSCANY-1095) baseType properties on DataObjects are using the wrong base EMF list class
[ https://issues.apache.org/jira/browse/TUSCANY-1095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12470617 ] Frank Budinsky commented on TUSCANY-1095: - This is a bug in the new generator template (SDOClass.javajet). Since we regenerated sdoModel.xsd with the new noEMF pattern, it now uses containment-type lists (EObjectContainmentEList) for all List-type properties. The baseType property should be using EObjectEList (actually probably EObjectResolvingEList - whatever it used to be with the old EMF-style template). Because it's erroneously generating a containment list, it's having the side effect described above. List property generation seems to be completely broken in general. The template isn't handling bi-directional (e.g., EObjectWithInverseEList), proxy resolving, unsettable, etc. Every flavor of list other than basic containment is broken with the new template. This part of the template should not always be calling createPropertyList with the containment list kind: %=genFeature.getSafeName()% = createPropertyList(ListKind.CONTAINMENT, %=genFeature.getListItemType()%.class, ... It needs to pass a correct kind indicator, which createPropertyList() would use to create the correct kind of EMF List. It used to just new up the right kind of EList, but createPropertyList() was added as the indirect way to do it without having an EMF dependency in the generated code. The new noEMF template should have all the same logic as before, but just using createPropertyList(some kind, ...) instead of new Esome kindList(...). Note that the implementation of createPropertyList() in class FactoryBase, also needs to be completed. baseType properties on DataObjects are using the wrong base EMF list class Key: TUSCANY-1095 URL: https://issues.apache.org/jira/browse/TUSCANY-1095 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-SCA-M3, Java-SCA-Mx, Java-SDO-Mx Environment: n/a Reporter: David T. Adcox Fix For: Java-SDO-Mx There is a problem when setting the baseType property on a DataObject. Specifically, if a new Type is being dynamically created, when a parent type is specified in the baseType property, upon setting that property, the parent type is taken out of the ePackage to which it belongs. It seems the list type being used checks for containment. That should not be a consideration in this case. I'll attach a sample of code demonstrate this behavior. -- 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: Move Tuscany wiki to Apache CWIKI?
As I'm updating a page on our old wiki, I'm wondering where we are with this and whether I should be migrating the content? Kelvin. On 24/01/07, Raymond Feng [EMAIL PROTECTED] wrote: Hi, FYI, I have added edit permissions to all registered users. Thanks, Raymond - Original Message - From: ant elder [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Wednesday, January 24, 2007 4:59 AM Subject: Re: Move Tuscany wiki to Apache CWIKI? On 1/23/07, Raymond Feng [EMAIL PROTECTED] wrote: snip 2) I'm not proposing to change the edit policy. The http://cwiki.apache.org/CWIKI/ page also provides some guidances for cases that we use it as a sandbox (open to all registered users) or documentation site (open to folks with CLA on file). I also think all our content should be open to any registered user. We want everyone to help maintain it and thats going be more likely to happen if we make it easy for them. Its harder for users to send in patches for the wiki :) Can we get update emails sent to the dev list so we all can monitor the changes? ...ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Queries related in the Trunk
This isn't answering your question; but I'd like to see a version of the iTest framework running against the trunk as discussed in the last IRC. This would allow bring up whole user scenarios and provide a means to quickly (automatically) validate they're still working as discussed in the last IRC chat. Creating a sample is always a manual setup and validation. Venkata Krishnan wrote: Hi Jeremy, Jim, Meeraj, br brI assume that runtime/standalone/assembly is going to be the way a SCA brRuntime will be started.nbsp; Is this right? br brIs there any test or sample in the trunk that can be used to understand how brto program a sca client for example things like how to get hold of a brComponentContext and use methods over it.nbsp; Could you please help with some brpointers? br brThanks br br- Venkat br br/body /html /html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Move Tuscany wiki to Apache CWIKI?
Hi Kelvin, In my perception, we are moving over to the Confluence wiki - CWIKI. Infact some of the recent updates such as things we aspire to do for SCA M3, some documentation on SCA Deployment and FAQs have already found place there. Thanks - Venkat On 2/6/07, kelvin goodson [EMAIL PROTECTED] wrote: As I'm updating a page on our old wiki, I'm wondering where we are with this and whether I should be migrating the content? Kelvin. On 24/01/07, Raymond Feng [EMAIL PROTECTED] wrote: Hi, FYI, I have added edit permissions to all registered users. Thanks, Raymond - Original Message - From: ant elder [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Wednesday, January 24, 2007 4:59 AM Subject: Re: Move Tuscany wiki to Apache CWIKI? On 1/23/07, Raymond Feng [EMAIL PROTECTED] wrote: snip 2) I'm not proposing to change the edit policy. The http://cwiki.apache.org/CWIKI/ page also provides some guidances for cases that we use it as a sandbox (open to all registered users) or documentation site (open to folks with CLA on file). I also think all our content should be open to any registered user. We want everyone to help maintain it and thats going be more likely to happen if we make it easy for them. Its harder for users to send in patches for the wiki :) Can we get update emails sent to the dev list so we all can monitor the changes? ...ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1093) isSet returning false when boolean set to false, or int set to 0
[ https://issues.apache.org/jira/browse/TUSCANY-1093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12470631 ] Fuhwei Lwo commented on TUSCANY-1093: - It seems the DataObject created from the type defined by the DataObject still has EMF behavior instead of SDO 2.1 spec. isSet returning false when boolean set to false, or int set to 0 Key: TUSCANY-1093 URL: https://issues.apache.org/jira/browse/TUSCANY-1093 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Reporter: Robbie Minshall Priority: Critical when boolean property is set to false a call to isSet returns false ( should return true ). when an int property is set to 0 a call to isSet returns false ( should return true ). This causes DataObject serialization ( our scenario involves using the sca ws binding ) to be missing values that have been set. -- 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-1093) isSet returning false when boolean set to false, or int set to 0
[ https://issues.apache.org/jira/browse/TUSCANY-1093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12470636 ] Robbie Minshall commented on TUSCANY-1093: -- I am guessing that this code path for creating the EStructuralFeature for the property does not have the attribute unsettable equal to true . . . but that is just a guess. isSet returning false when boolean set to false, or int set to 0 Key: TUSCANY-1093 URL: https://issues.apache.org/jira/browse/TUSCANY-1093 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Reporter: Robbie Minshall Priority: Critical when boolean property is set to false a call to isSet returns false ( should return true ). when an int property is set to 0 a call to isSet returns false ( should return true ). This causes DataObject serialization ( our scenario involves using the sca ws binding ) to be missing values that have been set. -- 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]
Hello Community!
Hello Community! I am a Computer Science student at UFMT (University of Mato Grosso) in Brazil. There is a small group of people here in UFMT that are working on Tuscany project, and after read more about the project I have decided to join in. Initially, I am interested in helping DAS C++ project. Although I am a beginner in big projects, like Tuscany, I hope I could help. Thanks, Douglas Siqueira Leite
[jira] Commented: (TUSCANY-1065) Coexistence problem between EMF and Tuscany SDO
[ https://issues.apache.org/jira/browse/TUSCANY-1065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12470641 ] Dan Murphy commented on TUSCANY-1065: - Hi Fuhwei, Do you have multiple EMF jars, or is this even when using the EMF jars declared by Tuscany ? Do you have a one liner example of initialising EMF ? Cheers, Coexistence problem between EMF and Tuscany SDO --- Key: TUSCANY-1065 URL: https://issues.apache.org/jira/browse/TUSCANY-1065 Project: Tuscany Issue Type: Improvement Components: Java SDO Implementation Affects Versions: Java-SDO-Mx Reporter: Fuhwei Lwo Fix For: Java-SDO-Mx When EMF and Tuscany SDO are running in the same JVM, Tuscany SDO is completely not working when EMF was run and initialized before SDO. -- 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: Queries related in the Trunk
What IRC? -- Jeremy On Feb 6, 2007, at 8:06 AM, Rick Rineholt wrote: This isn't answering your question; but I'd like to see a version of the iTest framework running against the trunk as discussed in the last IRC. This would allow bring up whole user scenarios and provide a means to quickly (automatically) validate they're still working as discussed in the last IRC chat. Creating a sample is always a manual setup and validation. Venkata Krishnan wrote: Hi Jeremy, Jim, Meeraj, br brI assume that runtime/standalone/assembly is going to be the way a SCA brRuntime will be started.nbsp; Is this right? br brIs there any test or sample in the trunk that can be used to understand how brto program a sca client for example things like how to get hold of a brComponentContext and use methods over it.nbsp; Could you please help with some brpointers? br brThanks br br- Venkat br br/body /html /html - 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]
Tuscany IRC weekly chats. Feb 5 2007
[11:38] cr22rc is there something general to talk about? [11:39] rfeng venkat might have a few questions about how to run samples with pre-spec or trunk kernel [11:40] cr22rc I'm not sure either ... still really fuzzy. I appended some questions on the ML but I don't think I got replies [11:40] * jsdelfino has joined #tuscany [11:41] lresende i sent a link with some steps that might be usefull for venkat [11:41] lresende not sure if it need to be updated to reflect pre-spec trunk branch [11:42] rfeng AFAIK, the trunk kernel is not fully ready yet to run samples [11:42] cr22rc am I correct that the itests, samples use only pre-spec ? [11:43] rfeng I assume so [11:43] * Venkat has joined #tuscany [11:43] Venkat Hi... [11:43] cr22rc so the plan is to continue to drive functionality in snapshot to pre-spec [11:44] rfeng I'm not sure if I understand your point [11:45] cr22rc you work on snap-shot kernel when something is stable you update the pre-spec branch and republish ? [11:45] jsdelfino hi, not sure what you guys are discussing now, but I'd like to add a question to the queue: what can we test with itest at the moment? [11:46] cr22rc pre-spec branch AFAIK [11:47] rfeng yes, the itest suite has test cases to cover SCA spec API, property, callback conversation, ws binding and a few other things [11:47] jsdelfino are all the test passing? [11:47] rfeng no [11:47] cr22rc YMMV :-) [11:47] jsdelfino that was my question :) what is passing? what is not passing? [11:48] rfeng A few spec tests were failing [11:48] cr22rc Personally, I need to be able to work on Itest for the business excepton ... I'll only figure out what I need to do by driving an example. [11:48] cr22rc at least the details of what needs to be done [11:48] Venkat cr22rc... isn't the itest stuff using the spec 0.95 [11:49] cr22rc think so [11:49] rfeng ATM, yes [11:49] Venkat I am eager to know about running samples and debugging them out the current kernel in the Trunk [11:49] * meerajk has joined #tuscany [11:50] rfeng I'm not sure if the kernel in trunk is ready for running samples [11:50] rfeng I didn't try [11:50] Venkat then can somebody help with an alternative... [11:50] Venkat in the earlier case with SCATestcase... [11:51] Venkat i used find it very convenient to walk thro the kernel and figure out things.. [11:51] Venkat debugging from Eclipse.. [11:51] * halehM has joined #tuscany [11:51] Venkat now am really struggling to move on... [11:52] jsdelfino venkat are you working with the trunk? or the pre-spec branch? [11:52] Venkat Trunk... [11:53] jsdelfino would it make sense to have a version of itest driving tests with the trunk instead of the pre-spec branch? [11:53] cr22rc I guess but then what the value of iTest in pre-spec .. who is really using it ? [11:54] rfeng +1, but maybe wait a bit until the kernel gets stable [11:54] rfeng cr22rc, we should add them to a daily build :-) [11:55] jsdelfino could we copy the itest stuff depending on the pre-spec branch to pre-spec, and change itest in trunk to depend on the kernel from trunk? like raymond is doing for the databinding? [11:56] * Amita has joined #tuscany [11:57] jsdelfino so this way, people who want to work on the pre-spec level can continue to do it, people who want to work with the trunk have an itest environment to work with [11:57] rfeng +1 [11:57] Venkat +1 [11:57] murphdg I was just playing with a similar thought / issue around building and testing in eclipse but I got stuck on how to build myself an installable version - since as I understand it, you can no longer be assured that sca will build cleanly... any thoughts, or have I misunderstood ? [11:58] cr22rc we can do this ... but not sure if this is what Jeremy was thinking ... my understanding was the kernel incubator-snapshot would not be made to stay working. [11:59] cr22rc just to be clear not opposing ... just point that out [11:59] jsdelfino cr22rc, you said you're working on exception handling right? [11:59] cr22rc yes trying to ... starting to write a testcase to help me [11:59] cr22rc I know where you're going. :-) [12:00] jsdelfino ok, do you want to do this work in the trunk? I'm assuming yes... [12:00] cr22rc yes [12:01] jsdelfino so I guess you'll need to coordinate with the other people working on the trunk, unit test cases working with the trunk, and I think that it'll be helpful to have itest working with the trunk as well, to test your exception handling end to end between two pojos wired together and a client for example [12:02] cr22rc but I'm *just* pointing out a catch... the expectation from jeremy and jim I understood was that they could check something in at that kernel that *could* break things for a while. [12:02] cr22rc i.e. the trunk is unstable [12:03] rfeng I guess that's fine but we need to have the itest in place for the trunk to really understand how broken it is [12:03] jsdelfino ah, then I guess we need to find out from
Re: Queries related in the Trunk
Sorry Jeremy, I had thought I saw someone sent the log on the mailing list, but it wasn't. . I just did. Jeremy Boynes wrote: What IRC? -- Jeremy On Feb 6, 2007, at 8:06 AM, Rick Rineholt wrote: This isn't answering your question; but I'd like to see a version of the iTest framework running against the trunk as discussed in the last IRC. This would allow bring up whole user scenarios and provide a means to quickly (automatically) validate they're still working as discussed in the last IRC chat. Creating a sample is always a manual setup and validation. Venkata Krishnan wrote: Hi Jeremy, Jim, Meeraj, br brI assume that runtime/standalone/assembly is going to be the way a SCA brRuntime will be started.nbsp; Is this right? br brIs there any test or sample in the trunk that can be used to understand how brto program a sca client for example things like how to get hold of a brComponentContext and use methods over it.nbsp; Could you please help with some brpointers? br brThanks br br- Venkat br br/body /html /html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1091) DataObjectXMLStreamReader doesn't have to repeat NameSpace declaration which impacts performance
[ https://issues.apache.org/jira/browse/TUSCANY-1091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12470678 ] Yang ZHONG commented on TUSCANY-1091: - We can have a comment such as: We used to have a NameSpaceContext at each DataObject level, delegating to parent DataObject NameSpaceContext. setParent was used to configure the parent NameSpaceContext. This improvement optimizes that and uses one global NameSpaceContext not delegating to any other one. Therefore setParent is ignored. Thanks. DataObjectXMLStreamReader doesn't have to repeat NameSpace declaration which impacts performance Key: TUSCANY-1091 URL: https://issues.apache.org/jira/browse/TUSCANY-1091 Project: Tuscany Issue Type: Improvement Components: Java SDO Implementation Affects Versions: Java-SDO-Mx Reporter: Yang ZHONG Fix For: Java-SDO-Mx Attachments: bindLessNS, simple3.xsd, XMLStreamHelper.xsd, XMLStreamHelperPerformanceTestCase.java p0:quotes3 p1:symbol3 xmlns:p1=http://www.example.com/simple3;IBM/p1:symbol3 p1:company3 xmlns:p1=http://www.example.com/simple3;IBM Corp./p1:company3 /p0:quotes3 can be optimized as p0:quotes3 xmlns:p1=http://www.example.com/simple3; p1:symbol3IBM/p1:symbol3 p1:company3IBM Corp./p1:company3 /p0:quotes3 Thanks to Fuhwei Lwo for prototyping the Test Case. I've made small changes to make use of HelperContext so that it will neither interfere nor be interfereed by other build test(s). -- 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-928) Define Tuscany SDO options for XMLHelper load and save operations
[ https://issues.apache.org/jira/browse/TUSCANY-928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yang ZHONG updated TUSCANY-928: --- Attachment: SDOXMLResourceImpl.928 Thanks to Frank for committing http://issues.apache.org/jira/browse/TUSCANY-1082 now I can generate the patch SDOXMLResourceImpl.928 Define Tuscany SDO options for XMLHelper load and save operations - Key: TUSCANY-928 URL: https://issues.apache.org/jira/browse/TUSCANY-928 Project: Tuscany Issue Type: Improvement Components: Java SDO Implementation Affects Versions: Java-SDO-Mx Reporter: Kelvin Goodson Fix For: Java-SDO-Mx Attachments: options.928, SDOXMLResourceImpl.928, SDOXMLResourceImpl.java XMLHelper's load and save operations take an Object argument options, which is currently cast to a Map and forwarded to EMF. Anyone wishing to influence the behaviour of the save/load operations must understand this aspect of EMF and use EMF artifacts in their programs. We need to design and implement an SDO approach to passing options, hiding the implementation details completely. -- 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-1083) Shorter NameSpace prefix to speed up XML processing and reduce communication bandwidth
[
https://issues.apache.org/jira/browse/TUSCANY-1083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12470697
]
Yang ZHONG commented on TUSCANY-1083:
-
With a little performance tradeoff (double queries to create an EPackage), it
can be simplified as
public EPackage getEPackage(XSDNamedComponent xsdNamedComponent)
{
XSDSchema containingXSDSchema = xsdNamedComponent.getSchema();
String targetNamespace =
containingXSDSchema == null ?
xsdNamedComponent.getTargetNamespace() :
containingXSDSchema.getTargetNamespace();
EPackage ePackage =
(EPackage)targetNamespaceToEPackageMap.get(targetNamespace);
if (ePackage != null)
return ePackage;
ePackage = super.getEPackage(xsdNamedComponent);
String nsPrefix =
xsdNamedComponent.getElement().lookupPrefix(targetNamespace);
if (nsPrefix != null)
ePackage.setNsPrefix(nsPrefix);
return ePackage;
}
Shorter NameSpace prefix to speed up XML processing and reduce communication
bandwidth
--
Key: TUSCANY-1083
URL: https://issues.apache.org/jira/browse/TUSCANY-1083
Project: Tuscany
Issue Type: Improvement
Components: Java SDO Implementation
Affects Versions: Java-SDO-Mx
Reporter: Yang ZHONG
Fix For: Java-SDO-Mx
Attachments: prefix.xsd, ShortPrefix
Given XSD:
schema xmlns=http://www.w3.org/2001/XMLSchema;
targetNamespace=http://soaassureservice.soabench.ibm.com;
xmlns:as=http://soaassureservice.soabench.ibm.com;
element name=requestInfo type=string/
element name=createClaim
...
SDO generates NameSpace prefix too long:
soaassureservice:createClaim
xmlns:soaassureservice=http://soaassureservice.soabench.ibm.com;
soaassureservice:requestInfo.../soaassureservice:requestInfo
...
--
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-1065) Coexistence problem between EMF and Tuscany SDO
[
https://issues.apache.org/jira/browse/TUSCANY-1065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12470719
]
Fuhwei Lwo commented on TUSCANY-1065:
-
Hi Dan,
Tuscany SDO is currently built on top of the EMF. The scenario is 1 EMF and 1
SDO in the env.
The problem lies who EMF or Tuscany SDO initializes the EcoreFactory eINSTANCE
= org.eclipse.emf.ecore.impl.EcoreFactoryImpl.init(); first. In order for SDO
to work, the implementation of eINSTANCE must be the SDOEcoreFactory class
defined in the SDOFactoryImpl.java. When EMF was init first, the EcoreFactory
eINSTANCE will be EMF's EcoreFactoryImpl and SDO will be broken.
To initialize EMF first, you can modify SimpleDynamicTestCase.setUp() method to
add an extra line - EcoreFactory.eINSTANCE.getEcorePackage(); and everything
would break.
protected void setUp() throws Exception {
super.setUp();
EcoreFactory.eINSTANCE.getEcorePackage();
// Populate the meta data for the test (Stock Quote) model
URL url = getClass().getResource(TEST_MODEL);
InputStream inputStream = url.openStream();
XSDHelper.INSTANCE.define(inputStream, url.toString());
inputStream.close();
}
Coexistence problem between EMF and Tuscany SDO
---
Key: TUSCANY-1065
URL: https://issues.apache.org/jira/browse/TUSCANY-1065
Project: Tuscany
Issue Type: Improvement
Components: Java SDO Implementation
Affects Versions: Java-SDO-Mx
Reporter: Fuhwei Lwo
Fix For: Java-SDO-Mx
When EMF and Tuscany SDO are running in the same JVM, Tuscany SDO is
completely not working when EMF was run and initialized before SDO.
--
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: Queries related in the Trunk
One of the things that is changing in the spec is the way in which user code outside SCA can access SCA resources. The CompositeContext and CurrentCompositeContext classes have been replaced with ComponentContext. You can see a prototype of this in the spec/sca-api- r1.0 module. This has a direct impact on user code including all our samples and SCATestCase. The old way using CurrentCompositeContext is no longer available and so we need to define alternatives. There are many ways in which a Tuscany runtime can be started, including: * from application code, using an installed distribution * from a Maven plugin like the itest one * using a command line wrapper like the launcher and startServer commands * in a web-application using a ServletContextListener and so forth. For the web-app case, I think the easiest solution for users is to automatically make the ComponentContext, Property values, and References available as ServletContext attributes. They would supply the URI for a component whose implementation type is tuscany:webapp as a context parameter and the listener would do the rest. Application code (servlets and jsps) would typically get properties and references from the servlet context. The same could be used for the launcher. Instead of passing in a jar file on the command line, the would supply the URI for a component whose implementation is tuscany:launched which would reference a class that implemented Runnable. The launcher would boot the runtime and invoke the component's run() method. The itest plugin would need a harness composite defined which would either include the composite-under-test or use it to implement a component. The harness composite would also contain a component whose references would target services from the composite-under-test. We can use a implementation of tuscany:junit to define the test class and introspection to run the tests it contains (probably through surefire); this can automatically inject property and reference values into the TestCase instance. For API code we can add ComponentContext getComponentContext(URI componentId) } to the TuscanyRuntime interface. Code that is using an installed standalone distribution can use the helpers in o.a.t.runtime.standalone to instantiate a StandaloneRuntime and from that get the ComponentContext for a component. -- Jeremy On Feb 6, 2007, at 7:46 AM, Venkata Krishnan wrote: Hi Jeremy, Jim, Meeraj, I assume that runtime/standalone/assembly is going to be the way a SCA Runtime will be started. Is this right? Is there any test or sample in the trunk that can be used to understand how to program a sca client for example things like how to get hold of a ComponentContext and use methods over it. Could you please help with some pointers? Thanks - Venkat - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Hello Community!
Welcome Douglas !!! -- Luciano Resende http://people.apache.org/~lresende On 2/6/07, Douglas Leite [EMAIL PROTECTED] wrote: Hello Community! I am a Computer Science student at UFMT (University of Mato Grosso) in Brazil. There is a small group of people here in UFMT that are working on Tuscany project, and after read more about the project I have decided to join in. Initially, I am interested in helping DAS C++ project. Although I am a beginner in big projects, like Tuscany, I hope I could help. Thanks, Douglas Siqueira Leite
[jira] Created: (TUSCANY-1097) DataObjectXMLStreamReader shouldn't have ignored (transient Properties in) Sequence
DataObjectXMLStreamReader shouldn't have ignored (transient Properties in) Sequence --- Key: TUSCANY-1097 URL: https://issues.apache.org/jira/browse/TUSCANY-1097 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-SDO-Mx Reporter: Yang ZHONG Fix For: Java-SDO-Mx DataObjectXMLStreamReader shouldn't have outputed nothing for Sequenced DataObject. -- 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-1097) DataObjectXMLStreamReader shouldn't have ignored (transient Properties in) Sequence
[ https://issues.apache.org/jira/browse/TUSCANY-1097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yang ZHONG updated TUSCANY-1097: Attachment: XMLStreamHelperTestCase.1097 DataObjectXMLStreamReader.java DataObjectXMLStreamReader.java is pending update in http://issues.apache.org/jira/browse/TUSCANY-1091 so the whole file is attached here. All build tests have passed. DataObjectXMLStreamReader shouldn't have ignored (transient Properties in) Sequence --- Key: TUSCANY-1097 URL: https://issues.apache.org/jira/browse/TUSCANY-1097 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-SDO-Mx Reporter: Yang ZHONG Fix For: Java-SDO-Mx Attachments: DataObjectXMLStreamReader.java, XMLStreamHelperTestCase.1097 DataObjectXMLStreamReader shouldn't have outputed nothing for Sequenced DataObject. -- 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: svn commit: r504366 - /incubator/tuscany/java/sca/kernel/spi/src/main/java/org/apache/tuscany/spi/deployer/ArtifactResolver.java
What is DeploymentContext used for?
--
Jeremy
On Feb 6, 2007, at 3:32 PM, [EMAIL PROTECTED] wrote:
Author: rfeng
Date: Tue Feb 6 15:32:03 2007
New Revision: 504366
URL: http://svn.apache.org/viewvc?view=revrev=504366
Log:
Add the ArtifactResolver SPI
Added:
incubator/tuscany/java/sca/kernel/spi/src/main/java/org/apache/
tuscany/spi/deployer/ArtifactResolver.java (with props)
Added: incubator/tuscany/java/sca/kernel/spi/src/main/java/org/
apache/tuscany/spi/deployer/ArtifactResolver.java
URL: http://svn.apache.org/viewvc/incubator/tuscany/java/sca/kernel/
spi/src/main/java/org/apache/tuscany/spi/deployer/
ArtifactResolver.java?view=autorev=504366
==
--- incubator/tuscany/java/sca/kernel/spi/src/main/java/org/apache/
tuscany/spi/deployer/ArtifactResolver.java (added)
+++ incubator/tuscany/java/sca/kernel/spi/src/main/java/org/apache/
tuscany/spi/deployer/ArtifactResolver.java Tue Feb 6 15:32:03 2007
@@ -0,0 +1,82 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * License); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+package org.apache.tuscany.spi.deployer;
+
+import java.net.URI;
+import java.util.Map;
+
+
+/**
+ * SCA Assemblies reference many artifacts of a wide variety of
types. These
+ * include:
+ * ul
+ * li Reference from one SCA composite to another SCA composite
+ * li Reference to PolicySet files
+ * li Reference to interface definition files, either WSDL or
Java interfaces
+ * li Reference to XSD files
+ * li Reference to any of a wide variety of implementation
artifact files,
+ * including Java classes, BPEL scripts, C++ DLLs and classes, PHP
scripts
+ * /ul
+ * In the SCA assemblies, these various artifacts are referenced
using either
+ * QNames or URIs that do not point to a specific entity.
Resolution of these
+ * references to concrete artifacts is necessary as part of the
operation of the
+ * SCA domain.
+ *
+ * @version $Rev$ $Date$
+ */
+public interface ArtifactResolver {
+/**
+ * Resolve an artifact by the qualified name
+ *
+ * @param contribution the URI of the contribution
+ * @param modelClass The java type of the artifact
+ * @param namespace The namespace of the artifact
+ * @param name The name of the artifact
+ * @param attributes Additional attributes that can be used to
constrain the
+ *resolution
+ * @param context The deployment context
+ * @return The resolved artifact
+ */
+T T resolve(URI contribution,
+ ClassT modelClass,
+ String namespace,
+ String name,
+ Map attributes,
+ DeploymentContext context);
+
+/**
+ * Resolve an artifact by the URI. Some typical use cases are:
+ * ul
+ * liReference a XML schema using
+ * {http://www.w3.org/2001/XMLSchema-instance}schemaLocation or
+ * liReference a list of WSDLs using
+ * {http://www.w3.org/2004/08/wsdl-instance}wsdlLocation
+ * /ul
+ *
+ * @param targetNamespace The target namespace of the
referenced artifact,
+ *if the targetNamespace is null, then it's not
specified
+ * @param location The URI of the referenced artifact, it can
be absolute or
+ *relative
+ * @param baseURI The URI of the owning artifact
+ * @return The URI of the resolved artifact
+ */
+URI resolve(URI contribution, String targetNamespace, String
location, String baseURI, DeploymentContext context);
+
+}
Propchange: incubator/tuscany/java/sca/kernel/spi/src/main/java/org/
apache/tuscany/spi/deployer/ArtifactResolver.java
--
svn:eol-style = native
Propchange: incubator/tuscany/java/sca/kernel/spi/src/main/java/org/
apache/tuscany/spi/deployer/ArtifactResolver.java
--
svn:keywords = Rev Date
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Content for next milestone
Jim Marino wrote: Sebastien, I'm a little surprised that you have not referenced the previous release discussion thread or any of the work that has been ongoing in core over the past month and a half: http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg12291.html http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg13445.html http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg12238.html Most of the work in core during this period has been aimed at getting a release of kernel out that supports features outlined in the first referenced thread. How does your proposal relate to that release? I'm happy to have two simultaneous release processes going at once and think it could even be beneficial. However, it would be helpful if you put your proposal in context so others such as myself can understand it a bit better. Jim On Feb 5, 2007, at 5:19 PM, Jean-Sebastien Delfino wrote: Now that we have a list of requirements on our Wiki at http://cwiki.apache.org/confluence/display/TUSCANY/Feature+areas+and+what+folks+are+working+on, and a number of people are signing up for some of the corresponding work, I'd like to start a discussion on the content of our next milestone. Given that our last milestone was in December, I'd like to have another milestone soon, by March. Here's the function that people have already signed up for on the Wiki page + what I'm interested in for this milestone: - Support for complex properties and multi valued properties - Support for SCA deployment-contributions, and in particular support for JAR based deployment contributions - Ability to reference and resolve composites in an SCA domain (would be nice to support recursive composition but I'm not particularly interested in it) - Ability to configure and override the configuration of References, Services and Properties (again here I'd be happy if this works with just one or two levels of composition) - Support for wiring inside an SCA domain references to services with bindings and have the wiring decide the endpoints to use - Support for business exceptions in end to end interactions - Support for promoting services and references out of a composite (without having to wire a reference to a reference or a service to a service) - Support for defining and configuring services and references directly on components - Interchangeability / mapping between Java and WSDL interfaces - Ability to use, alter and write an SCDL model at deployment - WSDL2Java and Java2WSDL support using the SDO databinding - Core support for non-blocking invocations playing nicely with bindings, and without having to send complete routing paths to the services/references - Databinding framework with support for conversions between JAXB and SDO - Working and modular build allowing to build subsets of the project - Services to add(/remove/query) compositions to an SCA domain - Services to add(/remove/query) SCA deployment contributions to an SCA domain - Core support for addressing, resolving, loading artifacts from SCA deployment contributions Thoughts? --Jean-Sebastien Jim, The idea is to bring together a number of pieces from the core runtime, extensions like databinding and WSDL support, tools like WSDL2Java and Java2WSDL etc. and stabilize them to get some of the basic function that I listed in my earlier email working in end to end scenarios. As a first step, we probably need a very small subset of the new deployment story that is being built in the trunk, starting with the ability to work with one SCA composite and one JAR contribution. To have a stable integration by March, I think we need to start this effort now. In order to not disrupt the wider and more innovative work going on in the trunk I'd like to do the integration/stabilization work in a branch, starting with the kernel from the pre-spec-changes branch or a stable level from last week. This will allow the trunk to continue to evolve in parallel and at a faster pace to support things like federated deployment, new management services, JMX support, multiparent classloading, and the latest changes to the Java CI APIs. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r504366 - /incubator/tuscany/java/sca/kernel/spi/src/main/java/org/apache/tuscany/spi/deployer/ArtifactResolver.java
Hi,
I was thinking of getting some context from the DeploymentContext, such as
the classloader, to help resolve the artifacts.
Thanks,
Raymond
- Original Message -
From: Jeremy Boynes [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Tuesday, February 06, 2007 3:50 PM
Subject: Re: svn commit: r504366 -
/incubator/tuscany/java/sca/kernel/spi/src/main/java/org/apache/tuscany/spi/deployer/ArtifactResolver.java
What is DeploymentContext used for?
--
Jeremy
On Feb 6, 2007, at 3:32 PM, [EMAIL PROTECTED] wrote:
Author: rfeng
Date: Tue Feb 6 15:32:03 2007
New Revision: 504366
URL: http://svn.apache.org/viewvc?view=revrev=504366
Log:
Add the ArtifactResolver SPI
Added:
incubator/tuscany/java/sca/kernel/spi/src/main/java/org/apache/
tuscany/spi/deployer/ArtifactResolver.java (with props)
Added: incubator/tuscany/java/sca/kernel/spi/src/main/java/org/
apache/tuscany/spi/deployer/ArtifactResolver.java
URL: http://svn.apache.org/viewvc/incubator/tuscany/java/sca/kernel/
spi/src/main/java/org/apache/tuscany/spi/deployer/
ArtifactResolver.java?view=autorev=504366
==
--- incubator/tuscany/java/sca/kernel/spi/src/main/java/org/apache/
tuscany/spi/deployer/ArtifactResolver.java (added)
+++ incubator/tuscany/java/sca/kernel/spi/src/main/java/org/apache/
tuscany/spi/deployer/ArtifactResolver.java Tue Feb 6 15:32:03 2007
@@ -0,0 +1,82 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * License); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+package org.apache.tuscany.spi.deployer;
+
+import java.net.URI;
+import java.util.Map;
+
+
+/**
+ * SCA Assemblies reference many artifacts of a wide variety of types.
These
+ * include:
+ * ul
+ * li Reference from one SCA composite to another SCA composite
+ * li Reference to PolicySet files
+ * li Reference to interface definition files, either WSDL or Java
interfaces
+ * li Reference to XSD files
+ * li Reference to any of a wide variety of implementation artifact
files,
+ * including Java classes, BPEL scripts, C++ DLLs and classes, PHP
scripts
+ * /ul
+ * In the SCA assemblies, these various artifacts are referenced using
either
+ * QNames or URIs that do not point to a specific entity. Resolution of
these
+ * references to concrete artifacts is necessary as part of the
operation of the
+ * SCA domain.
+ *
+ * @version $Rev$ $Date$
+ */
+public interface ArtifactResolver {
+/**
+ * Resolve an artifact by the qualified name
+ *
+ * @param contribution the URI of the contribution
+ * @param modelClass The java type of the artifact
+ * @param namespace The namespace of the artifact
+ * @param name The name of the artifact
+ * @param attributes Additional attributes that can be used to
constrain the
+ *resolution
+ * @param context The deployment context
+ * @return The resolved artifact
+ */
+T T resolve(URI contribution,
+ ClassT modelClass,
+ String namespace,
+ String name,
+ Map attributes,
+ DeploymentContext context);
+
+/**
+ * Resolve an artifact by the URI. Some typical use cases are:
+ * ul
+ * liReference a XML schema using
+ * {http://www.w3.org/2001/XMLSchema-instance}schemaLocation or
+ * liReference a list of WSDLs using
+ * {http://www.w3.org/2004/08/wsdl-instance}wsdlLocation
+ * /ul
+ *
+ * @param targetNamespace The target namespace of the referenced
artifact,
+ *if the targetNamespace is null, then it's not
specified
+ * @param location The URI of the referenced artifact, it can be
absolute or
+ *relative
+ * @param baseURI The URI of the owning artifact
+ * @return The URI of the resolved artifact
+ */
+URI resolve(URI contribution, String targetNamespace, String
location, String baseURI, DeploymentContext context);
+
+}
Propchange: incubator/tuscany/java/sca/kernel/spi/src/main/java/org/
apache/tuscany/spi/deployer/ArtifactResolver.java
--
svn:eol-style = native
Propchange:
Re: Content for next milestone
Guys, I'm a little confused here - so far we seem to have 3 different people volunteering to manage 3 different releases. We now have a very very long list of requirements many of which have not been discussed on the list and most of which do not have names against them or really relate to the coding that is actually going on; they also don't seem to apply to two out of the three releases. Version numbers are being assigned to milestones, we have stabilization branches and end-to-end scenarios, all without meaningful discussion on this list. I think we need to stop and figure out what we are doing as a community. Here, on this list, with everyone involved. -- Jeremy On Feb 6, 2007, at 3:58 PM, Jean-Sebastien Delfino wrote: Jim Marino wrote: Sebastien, I'm a little surprised that you have not referenced the previous release discussion thread or any of the work that has been ongoing in core over the past month and a half: http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg12291.html http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg13445.html http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg12238.html Most of the work in core during this period has been aimed at getting a release of kernel out that supports features outlined in the first referenced thread. How does your proposal relate to that release? I'm happy to have two simultaneous release processes going at once and think it could even be beneficial. However, it would be helpful if you put your proposal in context so others such as myself can understand it a bit better. Jim On Feb 5, 2007, at 5:19 PM, Jean-Sebastien Delfino wrote: Now that we have a list of requirements on our Wiki at http:// cwiki.apache.org/confluence/display/TUSCANY/Feature+areas+and+what +folks+are+working+on, and a number of people are signing up for some of the corresponding work, I'd like to start a discussion on the content of our next milestone. Given that our last milestone was in December, I'd like to have another milestone soon, by March. Here's the function that people have already signed up for on the Wiki page + what I'm interested in for this milestone: - Support for complex properties and multi valued properties - Support for SCA deployment-contributions, and in particular support for JAR based deployment contributions - Ability to reference and resolve composites in an SCA domain (would be nice to support recursive composition but I'm not particularly interested in it) - Ability to configure and override the configuration of References, Services and Properties (again here I'd be happy if this works with just one or two levels of composition) - Support for wiring inside an SCA domain references to services with bindings and have the wiring decide the endpoints to use - Support for business exceptions in end to end interactions - Support for promoting services and references out of a composite (without having to wire a reference to a reference or a service to a service) - Support for defining and configuring services and references directly on components - Interchangeability / mapping between Java and WSDL interfaces - Ability to use, alter and write an SCDL model at deployment - WSDL2Java and Java2WSDL support using the SDO databinding - Core support for non-blocking invocations playing nicely with bindings, and without having to send complete routing paths to the services/references - Databinding framework with support for conversions between JAXB and SDO - Working and modular build allowing to build subsets of the project - Services to add(/remove/query) compositions to an SCA domain - Services to add(/remove/query) SCA deployment contributions to an SCA domain - Core support for addressing, resolving, loading artifacts from SCA deployment contributions Thoughts? --Jean-Sebastien Jim, The idea is to bring together a number of pieces from the core runtime, extensions like databinding and WSDL support, tools like WSDL2Java and Java2WSDL etc. and stabilize them to get some of the basic function that I listed in my earlier email working in end to end scenarios. As a first step, we probably need a very small subset of the new deployment story that is being built in the trunk, starting with the ability to work with one SCA composite and one JAR contribution. To have a stable integration by March, I think we need to start this effort now. In order to not disrupt the wider and more innovative work going on in the trunk I'd like to do the integration/stabilization work in a branch, starting with the kernel from the pre-spec-changes branch or a stable level from last week. This will allow the trunk to continue to evolve in parallel and at a faster pace to support things like federated deployment, new management services, JMX support, multiparent classloading, and the latest changes to the Java CI APIs. --
SDO release?
As part of the recent flurry of release plans, there's been no discussion of an SDO release. Is that something we should do? -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r504392 - /incubator/tuscany/java/sca/kernel/spi/src/main/java/org/apache/tuscany/spi/util/MultiParentClassLoader.java
How does this relate to the existing CompositeClassLoader?
--
Jeremy
On Feb 6, 2007, at 4:48 PM, [EMAIL PROTECTED] wrote:
Author: rfeng
Date: Tue Feb 6 16:48:21 2007
New Revision: 504392
URL: http://svn.apache.org/viewvc?view=revrev=504392
Log:
Copy the MultiParentClassLoader from Axis2
Added:
incubator/tuscany/java/sca/kernel/spi/src/main/java/org/apache/
tuscany/spi/util/MultiParentClassLoader.java (with props)
Added: incubator/tuscany/java/sca/kernel/spi/src/main/java/org/
apache/tuscany/spi/util/MultiParentClassLoader.java
URL: http://svn.apache.org/viewvc/incubator/tuscany/java/sca/kernel/
spi/src/main/java/org/apache/tuscany/spi/util/
MultiParentClassLoader.java?view=autorev=504392
==
--- incubator/tuscany/java/sca/kernel/spi/src/main/java/org/apache/
tuscany/spi/util/MultiParentClassLoader.java (added)
+++ incubator/tuscany/java/sca/kernel/spi/src/main/java/org/apache/
tuscany/spi/util/MultiParentClassLoader.java Tue Feb 6 16:48:21 2007
@@ -0,0 +1,402 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * License); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.tuscany.spi.util;
+
+import java.beans.Introspector;
+import java.io.IOException;
+import java.net.URL;
+import java.net.URLClassLoader;
+import java.net.URLStreamHandlerFactory;
+import java.util.ArrayList;
+import java.util.Collection;
+import java.util.Collections;
+import java.util.Enumeration;
+import java.util.List;
+import java.util.Set;
+
+/**
+ * A MultiParentClassLoader is a simple extension of the
URLClassLoader that
+ * simply changes the single parent class loader model to support
a list of
+ * parent class loaders. Each operation that accesses a parent,
has been
+ * replaced with a operation that checks each parent in order.
This getParent
+ * method of this class will always return null, which may be
interpreted by the
+ * calling code to mean that this class loader is a direct child
of the system
+ * class loader.
+ *
+ * @version $Rev$ $Date$
+ */
+public class MultiParentClassLoader extends URLClassLoader {
+private boolean destroyed;
+private final String[] hiddenClasses;
+private final String[] hiddenResources;
+private final boolean inverseClassLoading;
+private final String[] nonOverridableClasses;
+private final String[] nonOverridableResources;
+
+private final ClassLoader[] parents;
+
+/**
+ * Creates a named class loader with no parents.
+ *
+ * @param urls the urls from which this class loader will
classes and
+ *resources
+ */
+public MultiParentClassLoader(URL[] urls) {
+super(urls);
+parents = new ClassLoader[]
{ClassLoader.getSystemClassLoader()};
+inverseClassLoading = false;
+hiddenClasses = new String[0];
+nonOverridableClasses = new String[0];
+hiddenResources = new String[0];
+nonOverridableResources = new String[0];
+}
+
+/**
+ * Creates a named class loader as a child of the specified
parent.
+ *
+ * @param urls the urls from which this class loader will
classes and
+ *resources
+ * @param parent the parent of this class loader
+ */
+public MultiParentClassLoader(URL[] urls, ClassLoader parent) {
+this(urls, new ClassLoader[] {parent});
+}
+
+public MultiParentClassLoader(URL[] urls,
+ ClassLoader parent,
+ boolean inverseClassLoading,
+ String[] hiddenClasses,
+ String[] nonOverridableClasses) {
+this(urls, new ClassLoader[] {parent},
inverseClassLoading, hiddenClasses, nonOverridableClasses);
+}
+
+/**
+ * Creates a named class loader as a child of the specified
parent and using
+ * the specified URLStreamHandlerFactory for accessing the urls..
+ *
+ * @param urls the urls from which this class loader will
classes and
+ *resources
+ * @param parent the parent of this class loader
+ * @param factory the URLStreamHandlerFactory used to access
the urls
+ */
+public
Re: svn commit: r504392 - /incubator/tuscany/java/sca/kernel/spi/src/main/java/org/apache/tuscany/spi/util/MultiParentClassLoader.java
Hi,
We can subclass MultiParentClassLoader to implement the
CompositeClassLoader. The parents can be derived from the dependencies as
described by import/export in the contributions.
Thanks,
Raymond
- Original Message -
From: Jeremy Boynes [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Tuesday, February 06, 2007 7:14 PM
Subject: Re: svn commit: r504392 -
/incubator/tuscany/java/sca/kernel/spi/src/main/java/org/apache/tuscany/spi/util/MultiParentClassLoader.java
How does this relate to the existing CompositeClassLoader?
--
Jeremy
On Feb 6, 2007, at 4:48 PM, [EMAIL PROTECTED] wrote:
Author: rfeng
Date: Tue Feb 6 16:48:21 2007
New Revision: 504392
URL: http://svn.apache.org/viewvc?view=revrev=504392
Log:
Copy the MultiParentClassLoader from Axis2
Added:
incubator/tuscany/java/sca/kernel/spi/src/main/java/org/apache/
tuscany/spi/util/MultiParentClassLoader.java (with props)
Added: incubator/tuscany/java/sca/kernel/spi/src/main/java/org/
apache/tuscany/spi/util/MultiParentClassLoader.java
URL: http://svn.apache.org/viewvc/incubator/tuscany/java/sca/kernel/
spi/src/main/java/org/apache/tuscany/spi/util/
MultiParentClassLoader.java?view=autorev=504392
==
--- incubator/tuscany/java/sca/kernel/spi/src/main/java/org/apache/
tuscany/spi/util/MultiParentClassLoader.java (added)
+++ incubator/tuscany/java/sca/kernel/spi/src/main/java/org/apache/
tuscany/spi/util/MultiParentClassLoader.java Tue Feb 6 16:48:21 2007
@@ -0,0 +1,402 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * License); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.tuscany.spi.util;
+
+import java.beans.Introspector;
+import java.io.IOException;
+import java.net.URL;
+import java.net.URLClassLoader;
+import java.net.URLStreamHandlerFactory;
+import java.util.ArrayList;
+import java.util.Collection;
+import java.util.Collections;
+import java.util.Enumeration;
+import java.util.List;
+import java.util.Set;
+
+/**
+ * A MultiParentClassLoader is a simple extension of the URLClassLoader
that
+ * simply changes the single parent class loader model to support a
list of
+ * parent class loaders. Each operation that accesses a parent, has
been
+ * replaced with a operation that checks each parent in order. This
getParent
+ * method of this class will always return null, which may be
interpreted by the
+ * calling code to mean that this class loader is a direct child of the
system
+ * class loader.
+ *
+ * @version $Rev$ $Date$
+ */
+public class MultiParentClassLoader extends URLClassLoader {
+private boolean destroyed;
+private final String[] hiddenClasses;
+private final String[] hiddenResources;
+private final boolean inverseClassLoading;
+private final String[] nonOverridableClasses;
+private final String[] nonOverridableResources;
+
+private final ClassLoader[] parents;
+
+/**
+ * Creates a named class loader with no parents.
+ *
+ * @param urls the urls from which this class loader will classes
and
+ *resources
+ */
+public MultiParentClassLoader(URL[] urls) {
+super(urls);
+parents = new ClassLoader[]
{ClassLoader.getSystemClassLoader()};
+inverseClassLoading = false;
+hiddenClasses = new String[0];
+nonOverridableClasses = new String[0];
+hiddenResources = new String[0];
+nonOverridableResources = new String[0];
+}
+
+/**
+ * Creates a named class loader as a child of the specified parent.
+ *
+ * @param urls the urls from which this class loader will classes
and
+ *resources
+ * @param parent the parent of this class loader
+ */
+public MultiParentClassLoader(URL[] urls, ClassLoader parent) {
+this(urls, new ClassLoader[] {parent});
+}
+
+public MultiParentClassLoader(URL[] urls,
+ ClassLoader parent,
+ boolean inverseClassLoading,
+ String[] hiddenClasses,
+ String[] nonOverridableClasses) {
+this(urls, new ClassLoader[] {parent}, inverseClassLoading,
Re: What to do with the WSDL tools
Hi, With respect to the Java2WSDL tool I wish to trim quite of bit of it as most of what we need has now been incorporated into the Axis2 tool over which ours has just been a wrapper providing only the missing things. So AFAICT, the only thing that our Java2WSDL wrapper could add over the current version of Axis2 Java2WSDL is the support for SDOs. I hope to get to this as soon as I am done with somethings that I currently tied up with. - Venkat On 2/7/07, Jeremy Boynes [EMAIL PROTECTED] wrote: Sebastien mentioned stabilizing tools like WSDL2Java and Java2WSDL etc. recently and Kelvin and I were previously discussing moving those tools out of SCA and into SDO on the basis that they actually don't have any dependency on SCA but do on SDO and EMF. Ant has now moved them to the axis2 extension, which makes sense given the dependency on axis2-codegen, but they don't have a dependency on the other modules in there. If there is interest in stabilizing these, then let's move them out to a separate module and release them when they are done. I assume that will require a release of SDO first. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1093) isSet returning false when boolean set to false, or int set to 0
[ https://issues.apache.org/jira/browse/TUSCANY-1093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yang ZHONG updated TUSCANY-1093: Attachment: patch The attached patch has passed all build tests. isSet returning false when boolean set to false, or int set to 0 Key: TUSCANY-1093 URL: https://issues.apache.org/jira/browse/TUSCANY-1093 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Reporter: Robbie Minshall Priority: Critical Attachments: patch when boolean property is set to false a call to isSet returns false ( should return true ). when an int property is set to 0 a call to isSet returns false ( should return true ). This causes DataObject serialization ( our scenario involves using the sca ws binding ) to be missing values that have been set. -- 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-1086) Scope defined java serialiazation/deserialization of SDO
[ https://issues.apache.org/jira/browse/TUSCANY-1086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hasan Muhammad updated TUSCANY-1086: Attachment: JavaSerDeserialize_NewFiles_TestCase.zip JavaSerDeserialization.patch I have attached the following: 1. JavaSerDeserialization.patch: This is a patch file containing the changes i made to existing SDO code. This patch file has been created from the Tuscany/java directory. 2. JavaSerDeserialize_NewFiles_TestCase.zip: This zip file contains the two new classes (SDOObjectInputStream and SDOObjectOutputStream) and a JUnit Test case. This zip file has been created from the Tuscany/java directory. You can simply unzip it there, and the source files will be restored in the proper directory. So far, when i directly serialize the DataObject, it works with the changes i have made. The method in the testcase to test this is testScopeDefinedSerializeDeserializeOfDataObject() The deserialization when a DataGraph has been serialized fails because it cant find the type. Again this happens because for a DataGraph, it is delegated to the readExternal() of the EDataGraphExternalizable class, where currently i could not find a way to pass on the scope information and hence it cant find the type. The testcase method for this test is testScopeDefinedSerializeDeserializeOfDataGraph(). Although the class SDOObjectOutputStream is not neccessary for this, i included for total symmetry Scope defined java serialiazation/deserialization of SDO Key: TUSCANY-1086 URL: https://issues.apache.org/jira/browse/TUSCANY-1086 Project: Tuscany Issue Type: Improvement Components: Java SDO Implementation Affects Versions: Java-M2 Environment: All Reporter: Hasan Muhammad Fix For: Java-SDO-Mx Attachments: JavaSerDeserialization.patch, JavaSerDeserialize_NewFiles_TestCase.zip Need to have a scope defined java serialization/deserialization of SDO's. Currently it can be done only in the Global/default scope. Have to fix this by using helperContext as the scope for creating ObjectInputStream and ObjectOutputStream. -- 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-1040) DAS C++
[ https://issues.apache.org/jira/browse/TUSCANY-1040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adriano Crestani updated TUSCANY-1040: -- Attachment: tuscany1040.crestani.20070207.patch DAS C++ --- Key: TUSCANY-1040 URL: https://issues.apache.org/jira/browse/TUSCANY-1040 Project: Tuscany Issue Type: New Feature Components: C++ SDO Affects Versions: Wish list Reporter: Luciano Resende Fix For: Wish list Attachments: DAS_CPP.zip, DAS_CPP_01_11_2007.zip, DAS_CPP_01_11_2007.zip, tuscany1040.crestani.20070117.txt, tuscany1040.crestani.20070207.patch Create a version of DAS in C++ integrating with SDO C++ -- 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]
