from:"kelvin goodson"


[ 
https://issues.apache.org/jira/browse/TUSCANY-2080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12578643#action_12578643
 ] 

Kelvin Goodson commented on TUSCANY-2080:
-

This symptom is seen when there is a mismatch between the input XML and the 
registered metadata;  usually because the metadata isn't registered.  Here you 
have registered the metadata,  so we need to see the XML that is being 
delivered by the DOMSource,  and the metadata that is being used to generate 
the static classes.   In particular the namespace URI and root element name of 
the input document must match a global element in the defining schema,  or the 
type of the root element must be defined by an xsi:type attribute.  Please can 
you post the input doc and schema,  or create a simulation if you are not able 
to post those?

I suspect this is not a bug in Tuscany.   It may be better to continue this 
discussion on the tuscany-user mailing list if you didn't mind,  with a link to 
the JIRA,  then the user community will find it easier to benefit from this 
discussion.

 XML Helper Load method fails to return SDO generated class when using the 
 method that takes a java.xml.transform.Source
 ---

 Key: TUSCANY-2080
 URL: https://issues.apache.org/jira/browse/TUSCANY-2080
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Implementation
Affects Versions: Java-SDO-1.0
 Environment: Windows XP
Reporter: Jason Dixon

 When trying to go from a Document object to a Generated Object using the XML 
 helper only AnyTypeDataObject is being returned. The other SDO operations 
 function propperly. For exampl if I marshall the Document to String and then 
 use the XML load method that takes a string, the correct generated sdo 
 instance is return. Please see the source code example below.
 Thanks in advance!
   try {
   DocumentBuilderFactory factory = 
 DocumentBuilderFactory.newInstance();
   factory.setNamespaceAware(true);
   
   DocumentBuilder builder = factory.newDocumentBuilder();
   System.out.println(Builder is namespace aware  + 
 builder.isNamespaceAware());
   
   Document dom = builder.parse(new File(results.xml));  
 
   
   //Create a scope and register
   HelperContext scope = 
 HelperProvider.getDefaultContext();
   DomainFactoryImpl.INSTANCE.register(scope);
   //Now load from dom to object
   DOMSource source = new DOMSource(dom);
   XMLDocument xml = scope.getXMLHelper().load(source, 
 null, null);
   Object clazz = xml.getRootObject();
   System.out.println(clazz);
   
   } catch (FactoryConfigurationError e) {
   // TODO Auto-generated catch block
   e.printStackTrace();
   } catch (ParserConfigurationException e) {
   // TODO Auto-generated catch block
   e.printStackTrace();
   } catch (SAXException e) {
   // TODO Auto-generated catch block
   e.printStackTrace();
   } catch (IOException e) {
   // TODO Auto-generated catch block
   e.printStackTrace();
   }

-- 
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-2080) XML Helper Load method fails to return SDO generated class when using the method that takes a java.xml.transform.Source


[ 
https://issues.apache.org/jira/browse/TUSCANY-2080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12578666#action_12578666
 ] 

Kelvin Goodson commented on TUSCANY-2080:
-

I just re-read your report,  and see that I had misunderstood a detail, 
apologies.  So if you go via string,  the correct class is generated for the 
root object.  This does sound more like a bug.  We need to create a test case,  
so if you can post your schema and results.xml file that would be great.

 XML Helper Load method fails to return SDO generated class when using the 
 method that takes a java.xml.transform.Source
 ---

 Key: TUSCANY-2080
 URL: https://issues.apache.org/jira/browse/TUSCANY-2080
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Implementation
Affects Versions: Java-SDO-1.0
 Environment: Windows XP
Reporter: Jason Dixon

 When trying to go from a Document object to a Generated Object using the XML 
 helper only AnyTypeDataObject is being returned. The other SDO operations 
 function propperly. For exampl if I marshall the Document to String and then 
 use the XML load method that takes a string, the correct generated sdo 
 instance is return. Please see the source code example below.
 Thanks in advance!
   try {
   DocumentBuilderFactory factory = 
 DocumentBuilderFactory.newInstance();
   factory.setNamespaceAware(true);
   
   DocumentBuilder builder = factory.newDocumentBuilder();
   System.out.println(Builder is namespace aware  + 
 builder.isNamespaceAware());
   
   Document dom = builder.parse(new File(results.xml));  
 
   
   //Create a scope and register
   HelperContext scope = 
 HelperProvider.getDefaultContext();
   DomainFactoryImpl.INSTANCE.register(scope);
   //Now load from dom to object
   DOMSource source = new DOMSource(dom);
   XMLDocument xml = scope.getXMLHelper().load(source, 
 null, null);
   Object clazz = xml.getRootObject();
   System.out.println(clazz);
   
   } catch (FactoryConfigurationError e) {
   // TODO Auto-generated catch block
   e.printStackTrace();
   } catch (ParserConfigurationException e) {
   // TODO Auto-generated catch block
   e.printStackTrace();
   } catch (SAXException e) {
   // TODO Auto-generated catch block
   e.printStackTrace();
   } catch (IOException e) {
   // TODO Auto-generated catch block
   e.printStackTrace();
   }

-- 
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-2080) XML Helper Load method fails to return SDO generated class when using the method that takes a java.xml.transform.Source


[ 
https://issues.apache.org/jira/browse/TUSCANY-2080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12578674#action_12578674
 ] 

Kelvin Goodson commented on TUSCANY-2080:
-

I knocked up a quick test for this which does not fail,  see the commit on the 
commits tab of this jira

https://issues.apache.org/jira/browse/TUSCANY-2080?page=com.atlassian.jira.plugin.ext.subversion:subversion-commits-tabpanel


 XML Helper Load method fails to return SDO generated class when using the 
 method that takes a java.xml.transform.Source
 ---

 Key: TUSCANY-2080
 URL: https://issues.apache.org/jira/browse/TUSCANY-2080
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Implementation
Affects Versions: Java-SDO-1.0
 Environment: Windows XP
Reporter: Jason Dixon

 When trying to go from a Document object to a Generated Object using the XML 
 helper only AnyTypeDataObject is being returned. The other SDO operations 
 function propperly. For exampl if I marshall the Document to String and then 
 use the XML load method that takes a string, the correct generated sdo 
 instance is return. Please see the source code example below.
 Thanks in advance!
   try {
   DocumentBuilderFactory factory = 
 DocumentBuilderFactory.newInstance();
   factory.setNamespaceAware(true);
   
   DocumentBuilder builder = factory.newDocumentBuilder();
   System.out.println(Builder is namespace aware  + 
 builder.isNamespaceAware());
   
   Document dom = builder.parse(new File(results.xml));  
 
   
   //Create a scope and register
   HelperContext scope = 
 HelperProvider.getDefaultContext();
   DomainFactoryImpl.INSTANCE.register(scope);
   //Now load from dom to object
   DOMSource source = new DOMSource(dom);
   XMLDocument xml = scope.getXMLHelper().load(source, 
 null, null);
   Object clazz = xml.getRootObject();
   System.out.println(clazz);
   
   } catch (FactoryConfigurationError e) {
   // TODO Auto-generated catch block
   e.printStackTrace();
   } catch (ParserConfigurationException e) {
   // TODO Auto-generated catch block
   e.printStackTrace();
   } catch (SAXException e) {
   // TODO Auto-generated catch block
   e.printStackTrace();
   } catch (IOException e) {
   // TODO Auto-generated catch block
   e.printStackTrace();
   }

-- 
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-2080) XML Helper Load method fails to return SDO generated class when using the method that takes a java.xml.transform.Source


[ 
https://issues.apache.org/jira/browse/TUSCANY-2080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12578823#action_12578823
 ] 

Kelvin Goodson commented on TUSCANY-2080:
-

This issue seems to be restricted to the conditions of creating the graph via a 
DOMSource AND the prefix  is bound to the namespace. Any other prefix seems 
fine.  If you parse a document direct from an inputstream  that has the  
prefix, then all is well, but going via a DOMSource brings out the problem.  So 
far I have trapped this down to the EMF XMLHelperImpl$NamespaceSupport having 
no table entry for the  prefix.  Here's the stack 
(I have to do other things for a while,  if you can follow up at all that would 
be great)

XMLHelperImpl$NamespaceSupport.getURI(String) line: 1419
SDOXMLResourceImpl$SDOXMLHelperImpl(XMLHelperImpl).getURI(String) line: 1253
SDOXMLResourceImpl$SDOXMLLoadImpl$XmlHandler(XMLHandler).getFeature(EObject, 
String, String, boolean) line: 2707
SDOXMLResourceImpl$SDOXMLLoadImpl$XmlHandler(XMLHandler).handleFeature(String, 
String) line: 1541   
SDOXMLResourceImpl$SDOXMLLoadImpl$XmlHandler(XMLHandler).createDocumentRoot(String,
 String, String, EFactory, boolean) line: 1237   
SDOXMLResourceImpl$SDOXMLLoadImpl$XmlHandler(XMLHandler).createObjectByType(String,
 String, boolean) line: 1165 
SDOXMLResourceImpl$SDOXMLLoadImpl$XmlHandler(XMLHandler).createTopObject(String,
 String) line: 1247 
SDOXMLResourceImpl$SDOXMLLoadImpl$XmlHandler(XMLHandler).processElement(String, 
String, String) line: 883   
SDOXMLResourceImpl$SDOXMLLoadImpl$XmlHandler(XMLHandler).startElement(String, 
String, String) line: 866 
SDOXMLResourceImpl$SDOXMLLoadImpl$XmlHandler(XMLHandler).startElement(String, 
String, String, Attributes) line: 627 
SDOXMLResourceImpl$SDOXMLLoadImpl$XmlHandler.startElement(String, String, 
String, Attributes) line: 405 
SDOXMLResourceImpl$SDOXMLLoadImpl(XMLLoadImpl).traverse(Node, 
XMLLoadImpl$AttributesProxy, DefaultHandler, LexicalHandler) line: 566
SDOXMLResourceImpl$SDOXMLLoadImpl(XMLLoadImpl).traverse(Node, 
XMLLoadImpl$AttributesProxy, DefaultHandler, LexicalHandler) line: 538
SDOXMLResourceImpl$SDOXMLLoadImpl(XMLLoadImpl).load(XMLResource, Node, Map) 
line: 409   
SDOXMLResourceImpl(XMLResourceImpl).doLoad(Node, Map) line: 606 
SDOXMLResourceImpl(XMLResourceImpl).load(Node, Map) line: 570   
XMLDocumentImpl.load(Node, Object) line: 249
XMLHelperImpl.load(Source, String, Object) line: 113
SimpleStaticTestCase.testSimpleStaticViaDomSource2() line: 114  




 XML Helper Load method fails to return SDO generated class when using the 
 method that takes a java.xml.transform.Source
 ---

 Key: TUSCANY-2080
 URL: https://issues.apache.org/jira/browse/TUSCANY-2080
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Implementation
Affects Versions: Java-SDO-1.0
 Environment: Windows XP
Reporter: Jason Dixon
 Attachments: tuscany_example.zip


 When trying to go from a Document object to a Generated Object using the XML 
 helper only AnyTypeDataObject is being returned. The other SDO operations 
 function propperly. For exampl if I marshall the Document to String and then 
 use the XML load method that takes a string, the correct generated sdo 
 instance is return. Please see the source code example below.
 Thanks in advance!
   try {
   DocumentBuilderFactory factory = 
 DocumentBuilderFactory.newInstance();
   factory.setNamespaceAware(true);
   
   DocumentBuilder builder = factory.newDocumentBuilder();
   System.out.println(Builder is namespace aware  + 
 builder.isNamespaceAware());
   
   Document dom = builder.parse(new File(results.xml));  
 
   
   //Create a scope and register
   HelperContext scope = 
 HelperProvider.getDefaultContext();
   DomainFactoryImpl.INSTANCE.register(scope);
   //Now load from dom to object
   DOMSource source = new DOMSource(dom);
   XMLDocument xml = scope.getXMLHelper().load(source, 
 null, null);
   Object clazz = xml.getRootObject();
   System.out.println(clazz);
   
   } catch (FactoryConfigurationError e) {
   // TODO Auto-generated catch block
   e.printStackTrace();
   } catch (ParserConfigurationException e) {
   // TODO Auto-generated catch block

[jira] Issue Comment Edited: (TUSCANY-2080) XML Helper Load method fails to return SDO generated class when using the method that takes a java.xml.transform.Source


[ 
https://issues.apache.org/jira/browse/TUSCANY-2080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12578823#action_12578823
 ] 

kgoodson edited comment on TUSCANY-2080 at 3/14/08 8:59 AM:
--

This issue seems to be restricted to the conditions of creating the graph via a 
DOMSource AND the prefix  is bound to the namespace. Any other prefix seems 
fine.  If you parse a document direct from an inputstream  that has the  
prefix, then all is well, but going via a DOMSource brings out the problem.  So 
far I have trapped this down to the EMF XMLHelperImpl$NamespaceSupport having 
no table entry for the  prefix.  Here's the stack 
(I have to do other things for a while,  if you are in a position to follow up 
at all that would be great)

XMLHelperImpl$NamespaceSupport.getURI(String) line: 1419
SDOXMLResourceImpl$SDOXMLHelperImpl(XMLHelperImpl).getURI(String) line: 1253
SDOXMLResourceImpl$SDOXMLLoadImpl$XmlHandler(XMLHandler).getFeature(EObject, 
String, String, boolean) line: 2707
SDOXMLResourceImpl$SDOXMLLoadImpl$XmlHandler(XMLHandler).handleFeature(String, 
String) line: 1541   
SDOXMLResourceImpl$SDOXMLLoadImpl$XmlHandler(XMLHandler).createDocumentRoot(String,
 String, String, EFactory, boolean) line: 1237   
SDOXMLResourceImpl$SDOXMLLoadImpl$XmlHandler(XMLHandler).createObjectByType(String,
 String, boolean) line: 1165 
SDOXMLResourceImpl$SDOXMLLoadImpl$XmlHandler(XMLHandler).createTopObject(String,
 String) line: 1247 
SDOXMLResourceImpl$SDOXMLLoadImpl$XmlHandler(XMLHandler).processElement(String, 
String, String) line: 883   
SDOXMLResourceImpl$SDOXMLLoadImpl$XmlHandler(XMLHandler).startElement(String, 
String, String) line: 866 
SDOXMLResourceImpl$SDOXMLLoadImpl$XmlHandler(XMLHandler).startElement(String, 
String, String, Attributes) line: 627 
SDOXMLResourceImpl$SDOXMLLoadImpl$XmlHandler.startElement(String, String, 
String, Attributes) line: 405 
SDOXMLResourceImpl$SDOXMLLoadImpl(XMLLoadImpl).traverse(Node, 
XMLLoadImpl$AttributesProxy, DefaultHandler, LexicalHandler) line: 566
SDOXMLResourceImpl$SDOXMLLoadImpl(XMLLoadImpl).traverse(Node, 
XMLLoadImpl$AttributesProxy, DefaultHandler, LexicalHandler) line: 538
SDOXMLResourceImpl$SDOXMLLoadImpl(XMLLoadImpl).load(XMLResource, Node, Map) 
line: 409   
SDOXMLResourceImpl(XMLResourceImpl).doLoad(Node, Map) line: 606 
SDOXMLResourceImpl(XMLResourceImpl).load(Node, Map) line: 570   
XMLDocumentImpl.load(Node, Object) line: 249
XMLHelperImpl.load(Source, String, Object) line: 113
SimpleStaticTestCase.testSimpleStaticViaDomSource2() line: 114  




  was (Author: kgoodson):
This issue seems to be restricted to the conditions of creating the graph 
via a DOMSource AND the prefix  is bound to the namespace. Any other prefix 
seems fine.  If you parse a document direct from an inputstream  that has the 
 prefix, then all is well, but going via a DOMSource brings out the problem.  
So far I have trapped this down to the EMF XMLHelperImpl$NamespaceSupport 
having no table entry for the  prefix.  Here's the stack 
(I have to do other things for a while,  if you can follow up at all that would 
be great)

XMLHelperImpl$NamespaceSupport.getURI(String) line: 1419
SDOXMLResourceImpl$SDOXMLHelperImpl(XMLHelperImpl).getURI(String) line: 1253
SDOXMLResourceImpl$SDOXMLLoadImpl$XmlHandler(XMLHandler).getFeature(EObject, 
String, String, boolean) line: 2707
SDOXMLResourceImpl$SDOXMLLoadImpl$XmlHandler(XMLHandler).handleFeature(String, 
String) line: 1541   
SDOXMLResourceImpl$SDOXMLLoadImpl$XmlHandler(XMLHandler).createDocumentRoot(String,
 String, String, EFactory, boolean) line: 1237   
SDOXMLResourceImpl$SDOXMLLoadImpl$XmlHandler(XMLHandler).createObjectByType(String,
 String, boolean) line: 1165 
SDOXMLResourceImpl$SDOXMLLoadImpl$XmlHandler(XMLHandler).createTopObject(String,
 String) line: 1247 
SDOXMLResourceImpl$SDOXMLLoadImpl$XmlHandler(XMLHandler).processElement(String, 
String, String) line: 883   
SDOXMLResourceImpl$SDOXMLLoadImpl$XmlHandler(XMLHandler).startElement(String, 
String, String) line: 866 
SDOXMLResourceImpl$SDOXMLLoadImpl$XmlHandler(XMLHandler).startElement(String, 
String, String, Attributes) line: 627 
SDOXMLResourceImpl$SDOXMLLoadImpl$XmlHandler.startElement(String, String, 
String, Attributes) line: 405 
SDOXMLResourceImpl$SDOXMLLoadImpl(XMLLoadImpl).traverse(Node, 
XMLLoadImpl$AttributesProxy, DefaultHandler, LexicalHandler) line: 566
SDOXMLResourceImpl$SDOXMLLoadImpl(XMLLoadImpl).traverse(Node, 
XMLLoadImpl$AttributesProxy, DefaultHandler, LexicalHandler) line: 538
SDOXMLResourceImpl$SDOXMLLoadImpl(XMLLoadImpl).load(XMLResource, Node, Map) 
line: 409   
SDOXMLResourceImpl(XMLResourceImpl).doLoad(Node, Map) line: 606 
SDOXMLResourceImpl(XMLResourceImpl).load(Node, Map) line: 570   
XMLDocumentImpl.load(Node, Object)

[jira] Commented: (TUSCANY-2058) The method XSDHelper.isXSD(Type) is returning invalid information

2008-03-07 Thread Kelvin Goodson (JIRA)


[ 
https://issues.apache.org/jira/browse/TUSCANY-2058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12576145#action_12576145
 ] 

Kelvin Goodson commented on TUSCANY-2058:
-

Having consulted,  it seems that the intention is that only the xsd helper 
belonging to the scope in which the type was defined should be able to provide 
information on XSD metadata,  so we need to check that the supplied instance of 
the Type is known to the this xsdHelper before examining the annotations we 
keep on the Type impl class.

 The method XSDHelper.isXSD(Type) is returning invalid information
 -

 Key: TUSCANY-2058
 URL: https://issues.apache.org/jira/browse/TUSCANY-2058
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Implementation
Affects Versions: Java-SDO-1.0
 Environment: n/a
Reporter: David T. Adcox
 Fix For: Java-SDO-Next

 Attachments: Test2058.java


 Based on my understanding, XSDHelper.isXSD(Type) should return 'true' if the 
 supplied Type object has been defined in the Scope from which the XSDHelper 
 was constructed.  In turn, I expect that 'false' will be returned, for a Type 
 object NOT defined in the Scope.  In some testing I have performed, I'm 
 seeing that 'true' is always returned, even if the Type is defined outside 
 the Scope being questioned.  I will attach a sample.

-- 
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: Why there are two different ways for tuscany generating WSDL from java (java2wsdl)

2008-03-06 Thread kelvin goodson

On 05/03/2008, Scott Kurz [EMAIL PROTECTED] wrote:


 I didn't follow all of the discussion about removing SDO from the Tuscany
 charter... but if SDO is no
 longer a special part of the Tuscany project then what would happen to the
 W2J/J2W tools built around
 SDO support?


The WSDL/WSDL tools are currently in the SCA code base, so I don't imagine
that would change as a result of the creation of a SDO specific project.

Kelvin.

Re: Tuscany participation at Google Summer of Code (GSoC) 2008

2008-03-06 Thread kelvin goodson

One possibility in the SDO domain that I have heard a request for recently
from more than one source is an ECMAScript/JavaScript implementation of
SDO.  This could be started by a GSoC activity.  I opened a Wish List item
for it a few days ago as TUSCANY-2065. I don't have deep skills in this
area,  and the concept is therefore somewhat nebulous to me,  but I'd like
to see it happen.

Kelvin.

On 01/03/2008, Luciano Resende [EMAIL PROTECTED] wrote:

 Apache Software Foundation is participating in Google Summer of Code
 program [1] as a mentoring organization. I think this is a good
 opportunity for us and I'd like to use this thread to discuss possible
 innovative and challenging projects that could attract the students
 participating on the program. Maybe we could start be defining some
 themes, and then projects around this themes, then, once we have a
 couple of projects, we could use wiki to create a small description of
 the project.

 Possible themes :

Tuscany Extensions (new bindings and implementations)
Web 2.0

 Thoughts ?

 [1] http://code.google.com/soc/2008/
 [2] http://wiki.apache.org/general/SummerOfCode2008

 --
 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: [VOTE] Community is more important than code

2008-03-05 Thread kelvin goodson

I believe it's important when entering a community to try as best you can to
adopt its culture.  I believe both things are important.  I can't say in
general I've deliberated long enough to come to a personal conclusion about
which is more important,  but in no light hearted fashion I am happy to
salute the Apache flag and give my ...

+1

Kelvin

On 03/03/2008, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:

 ant elder wrote:
  After all this time in incubation we've all learnt to understand this
 but I
  think it may be useful reaffirm it now with a vote. So please all vote
 to
  show you understand and agree with the long standing Apache motto that
  community is more important than code.
 
  +1 from me.
 
 ...ant
 


 I agree with the Apache motto that community is more important than
 code but why are we asked to vote on a motto out of the blue? Can you
 give more context?

 --

 Jean-Sebastien


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

[jira] Updated: (TUSCANY-2062) WSDL2Java code generation fails on WSDL with multiple namespace imports

2008-03-05 Thread Kelvin Goodson (JIRA)


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

Kelvin Goodson updated TUSCANY-2062:


Component/s: (was: Java SDO Tools)
 Java SCA Tools

 WSDL2Java code generation fails on WSDL with multiple namespace imports
 ---

 Key: TUSCANY-2062
 URL: https://issues.apache.org/jira/browse/TUSCANY-2062
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Tools
Affects Versions: Java-SCA-1.0.1
 Environment: Runtime Deployment is Solaris/Websphere 6.1 however this 
 is a code generation bug
Reporter: David Woolley
Assignee: Raymond Feng
 Attachments: AdminServiceV2.wsdl, AuthenticationServiceV2.wsdl, 
 ServiceV2Common.xsd, TUSCANY-2062.zip


 As per summary. WSDLs and associated schemas will be attached.

-- 
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-2065) An ECMAScript version of SDO

2008-03-05 Thread Kelvin Goodson (JIRA)

An ECMAScript version of SDO


 Key: TUSCANY-2065
 URL: https://issues.apache.org/jira/browse/TUSCANY-2065
 Project: Tuscany
  Issue Type: Wish
Reporter: Kelvin Goodson




-- 
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-2065) An ECMAScript version of SDO

2008-03-05 Thread Kelvin Goodson (JIRA)


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

Kelvin Goodson updated TUSCANY-2065:


Component/s: Java SDO Implementation

 An ECMAScript version of SDO
 

 Key: TUSCANY-2065
 URL: https://issues.apache.org/jira/browse/TUSCANY-2065
 Project: Tuscany
  Issue Type: Wish
  Components: Java SDO Implementation
Reporter: Kelvin Goodson



-- 
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-2031) Error encountered when trying to use dynamic Data APIs and SDO code-generated APIs at the same time

2008-03-04 Thread Kelvin Goodson (JIRA)


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

Kelvin Goodson resolved TUSCANY-2031.
-

Resolution: Invalid

Suspect user error as per comment above.

 Error encountered when trying to use dynamic Data APIs and SDO code-generated 
 APIs at the same time
 ---

 Key: TUSCANY-2031
 URL: https://issues.apache.org/jira/browse/TUSCANY-2031
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Implementation
Affects Versions: Java-SDO-beta1
 Environment: Windows XP, JDK 1.6
Reporter: Joseph Nguyen
 Fix For: Java-SDO-Next

   Original Estimate: 96h
  Remaining Estimate: 96h

 Can use generated codes from SDO generator to create DataObject(s) and XML 
 data.  Once the data has been created, error encountered when trying to use 
 dynamic Data APIs to read in to create DataObject(s).  Below shows the 
 details of error.
 Exception in thread main java.lang.ClassCastException: 
 org.eclipse.emf.ecore.xml.type.impl.AnyTypeImpl
 at 
 org.apache.tuscany.sdo.helper.XMLDocumentImpl.getRootObject(XMLDocumentImpl.java:320)
 at tbd.TBD.getRootObjectFromXMLDoc(TBD.java:73)
 at tbd.TBD.main(TBD.java:497)

-- 
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-2031) Error encountered when trying to use dynamic Data APIs and SDO code-generated APIs at the same time

2008-03-04 Thread Kelvin Goodson (JIRA)

[
https://issues.apache.org/jira/browse/TUSCANY-2031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12575008#action_12575008
]

Kelvin Goodson commented on TUSCANY-2031:
-

Hello Joseph. I'm sorry that I didn't spot this one before. I need to see a
bit more of your code. I don't have the beta1 source to hand at the moment to
check in detail, but the first thing that seems clear is that any occurrence
of AnyTypeImpl indicates that the Type system for the document that is being
read is not registered. You'll need to have registered your type system in
some way. It's not clear whether you want to use the dynamic API on instances
of DataObject, or to use the dynamic API on instances of your generated
classes. Either is possible. In the first case you will need to use the
schema that you used for generating the static classes, and provide it as an
InputStream to helperContext.getTypeHelper().define(...) and in the second case
you would need to do something like
MyGenFactory.INSTANCE.register(helperContext). This makes the Types available
so that when you do helperContext.getXMLHelper().load(...) the load operation
can look up the Types referenced in the XML document's elements, and create
instances of the appropriate classes. I suspect this is user error. So I am
going to close this JIRA as such. If you are still having troubles please mail
the tuscany-user mailing list where we'll be able to help you out.

Error encountered when trying to use dynamic Data APIs and SDO code-generated
APIs at the same time
---

Key: TUSCANY-2031
URL: https://issues.apache.org/jira/browse/TUSCANY-2031
Project: Tuscany
Issue Type: Bug
Components: Java SDO Implementation
Affects Versions: Java-SDO-beta1
Environment: Windows XP, JDK 1.6
Reporter: Joseph Nguyen
Fix For: Java-SDO-Next

Original Estimate: 96h
Remaining Estimate: 96h

Can use generated codes from SDO generator to create DataObject(s) and XML
data. Once the data has been created, error encountered when trying to use
dynamic Data APIs to read in to create DataObject(s). Below shows the
details of error.
Exception in thread main java.lang.ClassCastException:
org.eclipse.emf.ecore.xml.type.impl.AnyTypeImpl
at
org.apache.tuscany.sdo.helper.XMLDocumentImpl.getRootObject(XMLDocumentImpl.java:320)
at tbd.TBD.getRootObjectFromXMLDoc(TBD.java:73)
at tbd.TBD.main(TBD.java:497)

--
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-2058) The method XSDHelper.isXSD(Type) is returning invalid information

2008-03-04 Thread Kelvin Goodson (JIRA)

[
https://issues.apache.org/jira/browse/TUSCANY-2058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12575016#action_12575016
]

Kelvin Goodson commented on TUSCANY-2058:
-

This makes me wonder whether the spec has been a bit loose in its wording here
and missed an opportunity. We keep our annotations that carry this extra
metadata on the Type instance itself, so every xsdHelper would have access to
the infomation. I think it's worth opening this up as a spec issue.

the actual contents of the Spec do not completely preclude the behaviour we are
seeing ...

IsXSD() can be used to tell if the XSDHelper has information about a Type. --
and, for the duration of the isXSD(method), it does, by virtue of the
supplied argument.

It's the JavaDoc that's the main issue. It says ...

Indicates if this helper contains XSD information for the specified type.

Which again is very loose, and probably wrong, since a set of helpers
congregate around a scope for Types, so an xsdHelper would have access to
types that had been defined by itself, and by the TypeHelper belonging to that
scope. Hence the fact that is has information about that type is not the
discriminator that determines the return value.

I would suggest the behaviour we are seeing is the logical behaviour.

The method XSDHelper.isXSD(Type) is returning invalid information
-

Key: TUSCANY-2058
URL: https://issues.apache.org/jira/browse/TUSCANY-2058
Project: Tuscany
Issue Type: Bug
Components: Java SDO Implementation
Affects Versions: Java-SDO-1.0
Environment: n/a
Reporter: David T. Adcox
Fix For: Java-SDO-Next

Attachments: Test2058.java

Based on my understanding, XSDHelper.isXSD(Type) should return 'true' if the
supplied Type object has been defined in the Scope from which the XSDHelper
was constructed. In turn, I expect that 'false' will be returned, for a Type
object NOT defined in the Scope. In some testing I have performed, I'm
seeing that 'true' is always returned, even if the Type is defined outside
the Scope being questioned. I will attach a sample.

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

[VOTE] (Restarting the vote to ...) Change Tuscany Charter to remove SDO reference

2008-03-03 Thread kelvin goodson

As requested in [1] I am restarting this vote 

Please vote to alter the wording of the existing draft Tuscany charter as
discussed in

http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200802.mbox/[EMAIL 
PROTECTED]

to the following 


WHEREAS, the Board of Directors deems it to be in the best
 interests of the Foundation and consistent with the Foundation's
 purpose to establish a Projectt Management Committee charged with the
creation
 and maintenance of open-source software for distribution at no charge
 to the public, that simplifies the development, deployment and management
 of distributed applications built as compositions of service components.
 These components may be implemented with a range of technologies and
 connected using a variety of communication protocols. This software will
 implement relevant open standards including, but not limited to, the
 SCA standard defined by the OASIS OpenCSA member section, and related
 technologies.

NOW, THEREFORE, BE IT RESOLVED, that a Project Management
 Committee (PMC), to be known as the Apache Tuscany Project,
 be and hereby is established pursuant to Bylaws of the
 Foundation; and be it further

RESOLVED, that the Apache Tuscany Project be and hereby is
 responsible for the creation and maintenance of software
 related to Apache Tuscany;
 and be it further

RESOLVED, that the office of Vice President, Apache Tuscany be
 and hereby is created, the person holding such office to
 serve at the direction of the Board of Directors as the chair
 of the Apache Tuscany Project, and to have primary responsibility
 for management of the projects within the scope of
 responsibility of the Apache Tuscany Project; and be it further

RESOLVED, that the persons listed immediately below be and
 hereby are appointed to serve as the initial members of the
 Apache Tuscany Project:

 Adriano Crestaniadrianocrestani at apache dot org
 Andy Grove   agrove at apache dot org
 Andrew Borley   ajborley at apache dot org
 ant elder   antelder at apache dot org
 Brady Johnson  bjohnson at apache dot org
 Frank Budinsky frankb at apache dot org
 Ignacio Silva-Lepe  isilval at apache dot org
 Jean-Sebastien Delfino   jsdelfino at apache dot org
 kelvin goodson   kelvingoodson at apache dot org
 Luciano Resende   lresende at apache dot org
 Mike Edwards   edwardsmj at apache dot org
 Pete Robbinsrobbinspg at apache dot org
 Raymond Feng  rfeng at apache dot org
 Simon Laws  slaws at apache dot org
 Simon Nash  nash at apache dot org
 Venkata Krishnan  svkrish at apache dot org

NOW, THEREFORE, BE IT FURTHER RESOLVED, that Ant Elder
 be appointed to the office of Vice President, Apache Tuscany, to
 serve in accordance with and subject to the direction of the
 Board of Directors and the Bylaws of the Foundation until
 death, resignation, retirement, removal or disqualification,
 or until a successor is appointed; and be it further

RESOLVED, that the Apache Tuscany Project be and hereby
 is tasked with the migration and rationalization of the Apache
 Incubator Tuscany podling; and be it further

RESOLVED, that all responsibilities pertaining to the Apache
 Incubator Tuscany podling encumbered upon the Apache Incubator
 Project are hereafter discharged.




=

The wording of the existing draft charter was taken from
http://mail-archives.apache.org/mod_mbox/incubator-general/200710.mbox/[EMAIL 
PROTECTED]

Be sure to note when looking at that posting that it consists of a previous
version + a modification at the end of the posting.

The changes are ...
This software will implement relevant open standards including, but not
limited to, the SCA and SDO standards defined by the OASIS OpenCSA member
section.
becomes ...
This software will implement relevant open standards including, but not
limited to, the SCA standard defined by the OASIS OpenCSA member section,
and related technologies.

[1]
http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200802.mbox/[EMAIL 
PROTECTED]

Re: [VOTE] Change Tuscany Charter to remove SDO reference

2008-03-03 Thread kelvin goodson

I have restarted this vote as requested.

Kelvin.


On 29/02/2008, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:

 kelvin goodson wrote:
  Please vote to alter the wording of the existing draft Tuscany charter
 as
  discussed in
 
 
 http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200802.mbox/[EMAIL 
 PROTECTED]
 
  to the following 
 
  WHEREAS, the Board of Directors deems it to be in the best
   interests of the Foundation and consistent with the Foundation's
   purpose to establish a Projectt Management Committee charged with the
  creation
   and maintenance of open-source software for distribution at no charge
   to the public, that simplifies the development, deployment and
 management
   of distributed applications built as compositions of service
 components.
   These components may be implemented with a range of technologies and
   connected using a variety of communication protocols. This software
 will
   implement relevant open standards including, but not limited to, the
   SCA standard defined by the OASIS OpenCSA member section, and related
   technologies.
 
  NOW, THEREFORE, BE IT RESOLVED, that a Project Management
   Committee (PMC), to be known as the Apache Tuscany Project,
   be and hereby is established pursuant to Bylaws of the
   Foundation; and be it further
 
  RESOLVED, that the Apache Tuscany Project be and hereby is
   responsible for the creation and maintenance of software
   related to Apache Tuscany;
   and be it further
 
  RESOLVED, that the office of Vice President, Apache Tuscany be
   and hereby is created, the person holding such office to
   serve at the direction of the Board of Directors as the chair
   of the Apache Tuscany Project, and to have primary responsibility
   for management of the projects within the scope of
   responsibility of the Apache Tuscany Project; and be it further
 
  RESOLVED, that the persons listed immediately below be and
   hereby are appointed to serve as the initial members of the
   Apache Tuscany Project:
 
   Adriano Crestaniadrianocrestani at apache dot org
   Andrew Borley   ajborley at apache dot org
   ant elder   antelder at apache dot org
   Brady Johnson  bjohnson at apache dot org
   Frank Budinsky frankb at apache dot org
   Ignacio Silva-Lepe  isilval at apache dot org
   Jean-Sebastien Delfino   jsdelfino at apache dot org
   kelvin goodson   kelvingoodson at apache dot org
   Luciano Resende   lresende at apache dot org
   Mike Edwards   edwardsmj at apache dot org
   Pete Robbinsrobbinspg at apache dot org
   Raymond Feng  rfeng at apache dot org
   Simon Laws  slaws at apache dot org
   Simon Nash  nash at apache dot org
   Venkata Krishnan  svkrish at apache dot org
   Mark Combellack   mcombellack at apache dot org
 
  NOW, THEREFORE, BE IT FURTHER RESOLVED, that Ant Elder
   be appointed to the office of Vice President, Apache Tuscany, to
   serve in accordance with and subject to the direction of the
   Board of Directors and the Bylaws of the Foundation until
   death, resignation, retirement, removal or disqualification,
   or until a successor is appointed; and be it further
 
  RESOLVED, that the Apache Tuscany Project be and hereby
   is tasked with the migration and rationalization of the Apache
   Incubator Tuscany podling; and be it further
 
  RESOLVED, that all responsibilities pertaining to the Apache
   Incubator Tuscany podling encumbered upon the Apache Incubator
   Project are hereafter discharged.
 


 +1 from me to remove the SDO reference (and Thanks for your answers and
 clarifications in the related DISCUSS thread [1]).

 However, this VOTE thread introduces other unrelated changes to the
 charter. Would you mind restarting a new VOTE thread for the SDO change
 alone? I think it'll be easier to track things if we vote on individual
 changes separately.

 Thanks.

 [1] http://marc.info/?t=12036982511r=1w=2
 --

 Jean-Sebastien


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

Re: [DISCUSS] altering the Tuscany Charter in relation to SDO Java

2008-03-03 Thread kelvin goodson

Sorry Venkat,  I didn't explicitly respond to your posting,  but I hope the
answers I gave to Sebastien's similar line of questioning makes it clear.
Please let me know if not.

Kelvin.

On 28/02/2008, Venkata Krishnan [EMAIL PROTECTED] wrote:

 This software will implement relevant open standards including, but not
 limited to, the
   SCA standard defined by the OASIS OpenCSA member section, and related
   technologies.


 When we say including but not limited to I understand that it would very
 well contain SDO and others implicitly.  Or, does this have a different
 interprettation ?

 - Venkat


 On Thu, Feb 28, 2008 at 10:00 PM, Jean-Sebastien Delfino 
 [EMAIL PROTECTED] wrote:

  kelvin goodson wrote:
   Implicit in this rewording is the understanding within the Tuscany
  community
   that there would be one Apache home for SDO Java development.   When
  this
   thread is referenced in proposal for the new project, or discussions
  around
   it,  it must be clear to the wider Apache community that the Tuscany
   community accepts that.  Without this clear acceptance I fear the new
   project will face further periods of delay whilst questions are asked
  about
   the Tuscany communities intentions with regards to SDO Java
 development.
  
   So the answer to your question is conditional.
   If the new project is accepted an an incubator 
  
   - does not require Tuscany to implement SDO anymore --- yes
   - and still allows Tuscany to implement SDO   --- no
   - and still allows Tuscany to use SDO or any other related technology?
  ---
   yes
  
   if the project is not accepted as an incubator ...
  
   - does not require Tuscany to implement SDO anymore --- yes
   - and still allows Tuscany to implement SDO   --- yes
   - and still allows Tuscany to use SDO or any other related technology?
  ---
   yes
  
 
  I'm trying to understand how to vote, or if I should vote, on your other
  thread. Maybe I'm missing something. There is an SDO implementation in
  Tuscany at the moment. SDO is a related technology worked on in
  OpenCSA too. Why would we want to remove it from the charter?
 
  --
  Jean-Sebastien
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Java SDO] Need help in completing release management for SDO 1.1-incubating

2008-02-29 Thread kelvin goodson

Amita,
   such a shame when you are so nearly there,  however,  I am happy to pick
it up from here.  Many thanks for  getting it so far.
Kelvin.

On 29/02/2008, Amita Vadhavkar [EMAIL PROTECTED] wrote:

 Hi All,
 I will not be able to continue doing the release management activities
 from
 now on for the ongoing SDO release.
 It will be really great if somebody can pick the thread and complete what
 is
 remaining in the release.

 Regards,

 Amita

Re: [VOTE] Change Tuscany Charter to remove SDO reference

2008-02-28 Thread kelvin goodson

The wording of the existing draft charter was taken from
http://mail-archives.apache.org/mod_mbox/incubator-general/200710.mbox/[EMAIL 
PROTECTED]

Be sure to note when looking at that posting that it consists of a previous
version + a modification at the end of the posting.

The changes are ...
1) This software will implement relevant open standards including, but not
limited to, the SCA and SDO standards defined by the OASIS OpenCSA member
section.
becomes ...
This software will implement relevant open standards including, but not
limited to, the SCA standard defined by the OASIS OpenCSA member section,
and related technologies.

2) Andy Grove removed as initial member as per his request to step down from
PPMC
3) Mark Combellack added as member by virtue of PPMC membership

Kelvin.


On 28/02/2008, Simon Nash [EMAIL PROTECTED] wrote:

 kelvin goodson wrote:
  Please vote to alter the wording of the existing draft Tuscany charter
 as
  discussed in
 
 
 http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200802.mbox/[EMAIL 
 PROTECTED]
 
  to the following 
 
  WHEREAS, the Board of Directors deems it to be in the best
   interests of the Foundation and consistent with the Foundation's
   purpose to establish a Projectt Management Committee charged with the
  creation
   and maintenance of open-source software for distribution at no charge
   to the public, that simplifies the development, deployment and
 management
   of distributed applications built as compositions of service
 components.
   These components may be implemented with a range of technologies and
   connected using a variety of communication protocols. This software
 will
   implement relevant open standards including, but not limited to, the
   SCA standard defined by the OASIS OpenCSA member section, and related
   technologies.
 
  NOW, THEREFORE, BE IT RESOLVED, that a Project Management
   Committee (PMC), to be known as the Apache Tuscany Project,
   be and hereby is established pursuant to Bylaws of the
   Foundation; and be it further
 
  RESOLVED, that the Apache Tuscany Project be and hereby is
   responsible for the creation and maintenance of software
   related to Apache Tuscany;
   and be it further
 
  RESOLVED, that the office of Vice President, Apache Tuscany be
   and hereby is created, the person holding such office to
   serve at the direction of the Board of Directors as the chair
   of the Apache Tuscany Project, and to have primary responsibility
   for management of the projects within the scope of
   responsibility of the Apache Tuscany Project; and be it further
 
  RESOLVED, that the persons listed immediately below be and
   hereby are appointed to serve as the initial members of the
   Apache Tuscany Project:
 
   Adriano Crestaniadrianocrestani at apache dot org
   Andrew Borley   ajborley at apache dot org
   ant elder   antelder at apache dot org
   Brady Johnson  bjohnson at apache dot org
   Frank Budinsky frankb at apache dot org
   Ignacio Silva-Lepe  isilval at apache dot org
   Jean-Sebastien Delfino   jsdelfino at apache dot org
   kelvin goodson   kelvingoodson at apache dot org
   Luciano Resende   lresende at apache dot org
   Mike Edwards   edwardsmj at apache dot org
   Pete Robbinsrobbinspg at apache dot org
   Raymond Feng  rfeng at apache dot org
   Simon Laws  slaws at apache dot org
   Simon Nash  nash at apache dot org
   Venkata Krishnan  svkrish at apache dot org
   Mark Combellack   mcombellack at apache dot org
 
  NOW, THEREFORE, BE IT FURTHER RESOLVED, that Ant Elder
   be appointed to the office of Vice President, Apache Tuscany, to
   serve in accordance with and subject to the direction of the
   Board of Directors and the Bylaws of the Foundation until
   death, resignation, retirement, removal or disqualification,
   or until a successor is appointed; and be it further
 
  RESOLVED, that the Apache Tuscany Project be and hereby
   is tasked with the migration and rationalization of the Apache
   Incubator Tuscany podling; and be it further
 
  RESOLVED, that all responsibilities pertaining to the Apache
   Incubator Tuscany podling encumbered upon the Apache Incubator
   Project are hereafter discharged.
 

 Please can you highlight all the changes that are in this proposed
 new text, or point to the current version so that I can do a
 comparison.  Thanks.

Simon


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

Re: [DISCUSS] altering the Tuscany Charter in relation to SDO Java

2008-02-28 Thread kelvin goodson

This is about creating the healthiest Apache environment for fostering
creative ongoing SDO Java development.

The feedback from Apache members to the proposal I put forward for a new
project, was that it was too tightly scoped around JSR 235.

In order to broaden the scope of the new project proposal, and yet not split
the pool of potential Apache contributors to this technology, I am asking
the Tuscany community if it is prepared to drop the explicit reference to
SDO.  This would seem to be a necessary step before going back to the Apache
community with a broader scoped proposal for the new project,  since it is
clear that we would get objections on the basis that the pool of potential
contributors would be split across the two Apache projects.

So as I mentioned before,  implicit in this change to the charter is the
understanding that if another Apache other project is established with an
explicit remit for SDO Java development,  then we would work towards
ensuring that new  development happened in that new project.

I believe I need to be able to point to the changed draft charter, and to
point to discussions that demonstrate a willingness on the part of the
Tuscany community to be prepared to act in the spirit of these discussions,
if the new project is to stand a chance of being accepted into incubation.

Kelvin.


On 28/02/2008, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:

 kelvin goodson wrote:
  Implicit in this rewording is the understanding within the Tuscany
 community
  that there would be one Apache home for SDO Java development.   When
 this
  thread is referenced in proposal for the new project, or discussions
 around
  it,  it must be clear to the wider Apache community that the Tuscany
  community accepts that.  Without this clear acceptance I fear the new
  project will face further periods of delay whilst questions are asked
 about
  the Tuscany communities intentions with regards to SDO Java development.
 
  So the answer to your question is conditional.
  If the new project is accepted an an incubator 
 
  - does not require Tuscany to implement SDO anymore --- yes
  - and still allows Tuscany to implement SDO   --- no
  - and still allows Tuscany to use SDO or any other related technology?
 ---
  yes
 
  if the project is not accepted as an incubator ...
 
  - does not require Tuscany to implement SDO anymore --- yes
  - and still allows Tuscany to implement SDO   --- yes
  - and still allows Tuscany to use SDO or any other related technology?
 ---
  yes
 


 I'm trying to understand how to vote, or if I should vote, on your other
 thread. Maybe I'm missing something. There is an SDO implementation in
 Tuscany at the moment. SDO is a related technology worked on in
 OpenCSA too. Why would we want to remove it from the charter?


 --

 Jean-Sebastien

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

Re: [DISCUSS] altering the Tuscany Charter in relation to SDO Java

2008-02-26 Thread kelvin goodson

Implicit in this rewording is the understanding within the Tuscany community
that there would be one Apache home for SDO Java development.   When this
thread is referenced in proposal for the new project, or discussions around
it,  it must be clear to the wider Apache community that the Tuscany
community accepts that.  Without this clear acceptance I fear the new
project will face further periods of delay whilst questions are asked about
the Tuscany communities intentions with regards to SDO Java development.

So the answer to your question is conditional.
If the new project is accepted an an incubator 

- does not require Tuscany to implement SDO anymore --- yes
- and still allows Tuscany to implement SDO   --- no
- and still allows Tuscany to use SDO or any other related technology?   ---
yes

if the project is not accepted as an incubator ...

- does not require Tuscany to implement SDO anymore --- yes
- and still allows Tuscany to implement SDO   --- yes
- and still allows Tuscany to use SDO or any other related technology?   ---
yes

Kelvin.

On 25/02/2008, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:

 kelvin goodson wrote:
  There's been a discussion thread going for a while [1] in the Tuscany
  community with regards to shifting the Apache home for SDO Java work to
 a
  new project.  This has been going on in parallel to the discussion on
 the
  incubator general list on establishing a new project,  originally aimed
 to
  be tightly scoped to JSR 235  (see [2] to jump into that thread at a
  location particularly relevant for this posting).
 
  I'd like to try to move the Tuscany side of the discussion along to some
  kind of conclusion.   In view of that aim,  I'd like to suggest that we
 take
  a fresh look at the current state of the wording for the Tuscany
 charter,
  if that's what it's known as, that we arrived at during the graduation
 vote
  [3].
 
  I suggest 
 
   ...establish a Project Management Committee charged with the creation
   and maintenance of open-source software for distribution at no charge
   to the public, that simplifies the development, deployment and
 management
   of distributed applications built as compositions of service
 components.
   These components may be implemented with a range of technologies and
   connected using a variety of communication protocols. This software
 will
   implement relevant open standards including, but not limited to, the
   SCA standard defined by the OASIS OpenCSA member section, and related
   technologies.
 
  The only edit here is that the current blessed version ends with ...
  but not limited to, the SCA and SDO standards defined by the OASIS
 OpenCSA
  member section
 
  I urge you to give your attention to this in the near future please;
 making
  this alteration would seem to be a necessary,  but not sufficient,
 element
  for altering the proposal for the new project.
 
  Kelvin.
 
  [1]
 
 http://mail-archives.apache.org/mod_mbox/ws-tuscany-user/200802.mbox/browser
  [2]
 
 http://mail-archives.apache.org/mod_mbox/incubator-general/200802.mbox/[EMAIL 
 PROTECTED]
  [3]
 
 http://mail-archives.apache.org/mod_mbox/incubator-general/200710.mbox/[EMAIL 
 PROTECTED]
 


 Trying to make sure I understand. Does that mean that the new charter:
 - does not require Tuscany to implement SDO anymore
 - and still allows Tuscany to implement SDO
 - and still allows Tuscany to use SDO or any other related technology?

 --

 Jean-Sebastien


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

[VOTE] Change Tuscany Charter to remove SDO reference

2008-02-26 Thread kelvin goodson

Please vote to alter the wording of the existing draft Tuscany charter as
discussed in

http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200802.mbox/[EMAIL 
PROTECTED]

to the following 

WHEREAS, the Board of Directors deems it to be in the best
 interests of the Foundation and consistent with the Foundation's
 purpose to establish a Projectt Management Committee charged with the
creation
 and maintenance of open-source software for distribution at no charge
 to the public, that simplifies the development, deployment and management
 of distributed applications built as compositions of service components.
 These components may be implemented with a range of technologies and
 connected using a variety of communication protocols. This software will
 implement relevant open standards including, but not limited to, the
 SCA standard defined by the OASIS OpenCSA member section, and related
 technologies.

NOW, THEREFORE, BE IT RESOLVED, that a Project Management
 Committee (PMC), to be known as the Apache Tuscany Project,
 be and hereby is established pursuant to Bylaws of the
 Foundation; and be it further

RESOLVED, that the Apache Tuscany Project be and hereby is
 responsible for the creation and maintenance of software
 related to Apache Tuscany;
 and be it further

RESOLVED, that the office of Vice President, Apache Tuscany be
 and hereby is created, the person holding such office to
 serve at the direction of the Board of Directors as the chair
 of the Apache Tuscany Project, and to have primary responsibility
 for management of the projects within the scope of
 responsibility of the Apache Tuscany Project; and be it further

RESOLVED, that the persons listed immediately below be and
 hereby are appointed to serve as the initial members of the
 Apache Tuscany Project:

 Adriano Crestaniadrianocrestani at apache dot org
 Andrew Borley   ajborley at apache dot org
 ant elder   antelder at apache dot org
 Brady Johnson  bjohnson at apache dot org
 Frank Budinsky frankb at apache dot org
 Ignacio Silva-Lepe  isilval at apache dot org
 Jean-Sebastien Delfino   jsdelfino at apache dot org
 kelvin goodson   kelvingoodson at apache dot org
 Luciano Resende   lresende at apache dot org
 Mike Edwards   edwardsmj at apache dot org
 Pete Robbinsrobbinspg at apache dot org
 Raymond Feng  rfeng at apache dot org
 Simon Laws  slaws at apache dot org
 Simon Nash  nash at apache dot org
 Venkata Krishnan  svkrish at apache dot org
 Mark Combellack   mcombellack at apache dot org

NOW, THEREFORE, BE IT FURTHER RESOLVED, that Ant Elder
 be appointed to the office of Vice President, Apache Tuscany, to
 serve in accordance with and subject to the direction of the
 Board of Directors and the Bylaws of the Foundation until
 death, resignation, retirement, removal or disqualification,
 or until a successor is appointed; and be it further

RESOLVED, that the Apache Tuscany Project be and hereby
 is tasked with the migration and rationalization of the Apache
 Incubator Tuscany podling; and be it further

RESOLVED, that all responsibilities pertaining to the Apache
 Incubator Tuscany podling encumbered upon the Apache Incubator
 Project are hereafter discharged.

[DISCUSS] altering the Tuscany Charter in relation to SDO Java

2008-02-22 Thread kelvin goodson

There's been a discussion thread going for a while [1] in the Tuscany
community with regards to shifting the Apache home for SDO Java work to a
new project.  This has been going on in parallel to the discussion on the
incubator general list on establishing a new project,  originally aimed to
be tightly scoped to JSR 235  (see [2] to jump into that thread at a
location particularly relevant for this posting).

I'd like to try to move the Tuscany side of the discussion along to some
kind of conclusion.   In view of that aim,  I'd like to suggest that we take
a fresh look at the current state of the wording for the Tuscany charter,
if that's what it's known as, that we arrived at during the graduation vote
[3].

I suggest 

 ...establish a Project Management Committee charged with the creation
 and maintenance of open-source software for distribution at no charge
 to the public, that simplifies the development, deployment and management
 of distributed applications built as compositions of service components.
 These components may be implemented with a range of technologies and
 connected using a variety of communication protocols. This software will
 implement relevant open standards including, but not limited to, the
 SCA standard defined by the OASIS OpenCSA member section, and related
 technologies.

The only edit here is that the current blessed version ends with ...
but not limited to, the SCA and SDO standards defined by the OASIS OpenCSA
member section

I urge you to give your attention to this in the near future please; making
this alteration would seem to be a necessary,  but not sufficient, element
for altering the proposal for the new project.

Kelvin.

[1]
http://mail-archives.apache.org/mod_mbox/ws-tuscany-user/200802.mbox/browser
[2]
http://mail-archives.apache.org/mod_mbox/incubator-general/200802.mbox/[EMAIL 
PROTECTED]
[3]
http://mail-archives.apache.org/mod_mbox/incubator-general/200710.mbox/[EMAIL 
PROTECTED]

Re: How to use SDO in tuscany sca?

2008-02-20 Thread kelvin goodson

There has been a few occasions in the SDO spec meetings where issues
associated with raising exceptions have been resolved in favour of not
requiring the implementer to incur the performance overhead of exception
translation or decoration. There are no exceptions defined by the SDO API,
and only runtime exceptions can surface through the interface.

In this situation the schema has been written in error such that the type
was specified incorrectly, and therefore when assigning an instance of the
intended SDO Type to a Property of the erroneous Type then the expected
result is a ClassCastException.

We can discuss the merits of catching and rethrowing decorated or translated
exceptions in general,  but this is widespread through Tuscany's SDO (and I
would imagine also through other implementations given the spec
discussions), and would result I am sure in performance degradation.

Regards, Kelvin.

On 20/02/2008, Simon Nash [EMAIL PROTECTED] wrote:

 See inline.

   Simon

 wang feng wrote:
  It's OK,Thanks Raymond.
 
  Thanks,
  wangfeng
 
 
  On 2008-02-20, Raymond Feng [EMAIL PROTECTED] wrote:
 
  Hi,
 
  I debugged your test case and it turned out the problem is in your test
 case. There is a dangling type reference in helloworld.wsdl:
 
  wsdl:types
 schema elementFormDefault=qualified targetNamespace=
 http://helloworld; xmlns=http://www.w3.org/2001/XMLSchema;
 
 element name=getGreetings
 
 complexType
 
 sequence
 
 element name=name type=xsd:Name/
 
 /sequence
 
 /complexType
 
  /element
 
  It should be: element name=name type=tns:Name/.
 
  After fixing the issue, I can run it successfully with the 
  import.sdostatement.
 
 Can we track this as a JIRA?  A simple user error like this should not
 produce a ClassCastException deep in EMF.

   Simon

  Thanks,
 
  Raymond
 
  - Original Message -
  From: wang feng [EMAIL PROTECTED]
  To: tuscany-dev@ws.apache.org
  Sent: Tuesday, February 19, 2008 5:04 PM
  Subject: Re: Re: How to use SDO in tuscany sca?
 
 
  I add the element 'import.sdo' in the composite,but the sample throws
 another exception.
 
  Exception in thread main java.lang.ClassCastException: The value of
 type 'class org.apache.tuscany.sdo.impl.DynamicDataObjectImpl' must be of
 type 'class java.lang.String'
  at
 org.eclipse.emf.ecore.impl.EStructuralFeatureImpl$InternalSettingDelegateSingleDataUnsettableStatic.validate
 (EStructuralFeatureImpl.java:2195)
  at
 org.eclipse.emf.ecore.impl.EStructuralFeatureImpl$InternalSettingDelegateSingleDataUnsettable.dynamicSet
 (EStructuralFeatureImpl.java:2116)
  at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eDynamicSet(
 BasicEObjectImpl.java:709)
  at org.apache.tuscany.sdo.impl.DynamicDataObjectImpl.eDynamicSet(
 DynamicDataObjectImpl.java:160)
  at org.apache.tuscany.sdo.impl.DataObjectImpl.eSet(DataObjectImpl.java
 :1468)
  at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eSet(
 BasicEObjectImpl.java:654)
  at org.apache.tuscany.sdo.impl.DataObjectImpl.set(DataObjectImpl.java
 :146)
  at org.apache.tuscany.sdo.impl.DataObjectImpl.set(DataObjectImpl.java
 :106)
  at org.apache.tuscany.sca.databinding.sdo.SDOWrapperHandler.setChild(
 SDOWrapperHandler.java:71)
  at
 org.apache.tuscany.sca.core.databinding.transformers.Input2InputTransformer.transform
 (Input2InputTransformer.java:131)
  at
 org.apache.tuscany.sca.core.databinding.transformers.Input2InputTransformer.transform
 (Input2InputTransformer.java:1)
  at org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(
 MediatorImpl.java:73)
  at
 org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.transform
 (DataTransformationInterceptor.java:175)
  at
 org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.invoke
 (DataTransformationInterceptor.java:72)
  at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(
 JDKInvocationHandler.java:261)
  at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(
 JDKInvocationHandler.java:149)
  at $Proxy5.getGreetings(Unknown Source)
  at helloworld.HelloWorldClient.test(HelloWorldClient.java:53)
  at helloworld.HelloWorldClient.main(HelloWorldClient.java:39)
 
  Is something wrong? Where can I found a sample whith dynamic SDO?
 
  Thanks,
  wangfeng
 
 
  On 2008-02-19, Scott Kurz [EMAIL PROTECTED] wrote:
 
  Wang,
 
  I'm guessing the problem is probably that you need to register your
  app types with the appropriate context established by the Tuscany
  runtime.
 
  Tuscany typically does this automatically, now, for static SDO.  For
  dynamic SDO (i.e. DataObject), you would currently put something like
  this in your SCDL ( *.composite) file:
 
  composite ...
xmlns:dbsdo=
 http://tuscany.apache.org/xmlns/sca/databinding/sdo/1.0;

 
 dbsdo:import.sdo location=wsdl/helloworld.wsdl/
 
  (I looked in your zip and you don't seem to use the types in the XSD,
  so I pointed to the WSDL

[jira] Updated: (TUSCANY-1079) Possible error in XSDSerialization tests

2008-02-20 Thread Kelvin Goodson (JIRA)


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

Kelvin Goodson updated TUSCANY-1079:


Fix Version/s: (was: Java-SDO-1.1)
   Java-SDO-CTS-Next

 Possible error in XSDSerialization tests
 

 Key: TUSCANY-1079
 URL: https://issues.apache.org/jira/browse/TUSCANY-1079
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Community Test Suite
Affects Versions: Java-SDO-Next
Reporter: Andy Grove
 Fix For: Java-SDO-CTS-Next


 The current test cases are expecting 2 types to be created from the following 
 schema but does not contain assertions about what those types should look 
 like. I would expect this schema to create only one type 
 (http://www.example.com/simple#Quote) and one open content property 
 (stockQuote) of that type. What other type should be created?
 Thanks,
 Andy.
 xsd:schema 
   targetNamespace=http://www.example.com/simple;
   xmlns:xsd=http://www.w3.org/2001/XMLSchema; 
   xmlns:simple=http://www.example.com/simple; 
   
xsd:element name=stockQuote type=simple:Quote/
xsd:complexType name=Quote
xsd:sequence
   xsd:element name=symbol type=xsd:string/
   xsd:element name=companyName type=xsd:string/
   xsd:element name=price type=xsd:decimal/
   xsd:element name=open1 type=xsd:decimal/
   xsd:element name=high type=xsd:decimal/
   xsd:element name=low type=xsd:decimal/
   xsd:element name=volume type=xsd:double/
   xsd:element name=change1 type=xsd:double/
   xsd:element name=quotes type=simple:Quote minOccurs=0 
 maxOccurs=unbounded/
/xsd:sequence
/xsd:complexType
 /xsd:schema

-- 
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-829) Investigate integration of RogueWave tests

2008-02-20 Thread Kelvin Goodson (JIRA)


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

Kelvin Goodson updated TUSCANY-829:
---

Fix Version/s: (was: Java-SDO-1.1)
   Java-SDO-CTS-Next

 Investigate integration of RogueWave tests
 --

 Key: TUSCANY-829
 URL: https://issues.apache.org/jira/browse/TUSCANY-829
 Project: Tuscany
  Issue Type: Test
  Components: Java SDO Community Test Suite
Reporter: Kelvin Goodson
 Fix For: Java-SDO-CTS-Next

 Attachments: jira-829.zip, sdo.zip, testdata.zip


 Investigation of bringing RogueWave tests into the SDO Compliance Test Suite 
 environment.

-- 
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: r629397 - /incubator/tuscany/branches/sdo-1.1-incubating/distribution/src/main/release/RELEASE_NOTES

2008-02-20 Thread kelvin goodson

oops,  I see you have removed them from the notes,  sorry,  however,  it's
better that they are now tidied up in JIRA too   ;-)

On 20/02/2008, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:

 Author: amita
 Date: Wed Feb 20 01:49:40 2008
 New Revision: 629397

 URL: http://svn.apache.org/viewvc?rev=629397view=rev
 Log:
 remove any CTS JIRA

 Modified:
 incubator/tuscany/branches/sdo-1.1-incubating
 /distribution/src/main/release/RELEASE_NOTES

 Modified: incubator/tuscany/branches/sdo-1.1-incubating
 /distribution/src/main/release/RELEASE_NOTES
 URL:
 http://svn.apache.org/viewvc/incubator/tuscany/branches/sdo-1.1-incubating/distribution/src/main/release/RELEASE_NOTES?rev=629397r1=629396r2=629397view=diff

 ==
 --- 
 incubator/tuscany/branches/sdo-1.1-incubating/distribution/src/main/release/RELEASE_NOTES
 (original)
 +++ 
 incubator/tuscany/branches/sdo-1.1-incubating/distribution/src/main/release/RELEASE_NOTES
 Wed Feb 20 01:49:40 2008
 @@ -56,7 +56,6 @@
 TUSCANY-1527Allow for custom data binding of DataObjects in a
 Swing UI
 Improvement
 TUSCANY-193 Fix eclipse warnings for sdo/tools
 -   TUSCANY-1048SDO CTS. Contribute Paramatized Test Cases, and
 application server test harness
 TUSCANY-1063Improve diagnostics running XSD2JavaGenerator
 against bad schema
 TUSCANY-1283Better organization of the interfaces and classes
 in the SDO Java project
 TUSCANY-1399Generate SDO test classes using maven-sdo-plugin



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

[jira] Updated: (TUSCANY-1272) CrudWithChangeHistory test case fails as it's not finding the deleted object in the changeSummary

2008-02-20 Thread Kelvin Goodson (JIRA)


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

Kelvin Goodson updated TUSCANY-1272:


Component/s: (was: Java DAS RDB)
 Java SDO Implementation

Was assigned to wrong component

 CrudWithChangeHistory test case fails as it's not finding the deleted object 
 in the changeSummary
 -

 Key: TUSCANY-1272
 URL: https://issues.apache.org/jira/browse/TUSCANY-1272
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Implementation
Affects Versions: Java-DAS-Next
Reporter: Luciano Resende
Assignee: Luciano Resende
 Fix For: Java-SDO-1.1


 Looks like DAS is not finding the deleted object in the changeSummary to 
 remove from the DB
 testDeleteAndCreate(org.apache.tuscany.das.rdb.test.CrudWithChangeHistory)  
 Time elapsed: 0.266 sec   FAILURE!
 junit.framework.AssertionFailedError
 at junit.framework.Assert.fail(Assert.java:47)
 at junit.framework.Assert.assertTrue(Assert.java:20)
 at junit.framework.Assert.assertFalse(Assert.java:34)
 at junit.framework.Assert.assertFalse(Assert.java:41)
 at 
 org.apache.tuscany.das.rdb.test.CrudWithChangeHistory.testDeleteAndCreate(CrudWithChangeHistory.java:83)
 at 
 org.apache.tuscany.das.rdb.test.CrudWithChangeHistory.testDeleteAndCreate(CrudWithChangeHistory.java:83)
 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: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 junit.framework.TestSuite.runTest(TestSuite.java:208)
 at junit.framework.TestSuite.run(TestSuite.java:203)
 at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
 at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
 at junit.framework.TestResult.runProtected(TestResult.java:124)
 at junit.extensions.TestSetup.run(TestSetup.java:23)
 at junit.framework.TestSuite.runTest(TestSuite.java:208)
 at junit.framework.TestSuite.run(TestSuite.java:203)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:585)
 at 
 org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:213)
 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)

-- 
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-1063) Improve diagnostics running XSD2JavaGenerator against bad schema

2008-02-14 Thread Kelvin Goodson (JIRA)


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

Kelvin Goodson resolved TUSCANY-1063.
-

Resolution: Fixed

Added print stack trace for any Exception (note one mod for this JIRA was 
inadvertently committed under TUSCANY-1293)
Also added error report for case where input file results in no metadata (not 
easy to catch case where some metadata is in error).

 Improve diagnostics running XSD2JavaGenerator against bad schema
 

 Key: TUSCANY-1063
 URL: https://issues.apache.org/jira/browse/TUSCANY-1063
 Project: Tuscany
  Issue Type: Improvement
  Components: Java SDO Tools
Affects Versions: Java-SCA-M2
Reporter: Scott Kurz
Priority: Minor
 Fix For: Java-SDO-Next


 I gave an invalid XSD file to the XSD2JavaGenerator and had to use the 
 debugger to figure out the problem.
 It might be nice to do a printStackTrace() on any exception before throwing 
 out of main().
 Also it might be good to print out simple error messages in the cases that:
  a) the usage was correct but the specified file can't be read
  b) the file can be read but there is no valid schema found
 As a sample of the latter here is my invalid schema 
 xsd:schema xmlns:tns=http://helloworld; 
 xmlns:xsd=http://www.w3.org/2001/XMLSchema; elementFormDefault=qualified 
 targetNamespace=http://helloworld;
  complexType name=Person
 sequence
 element name=firstName type=string/
 element name=lastName type=string/
 /sequence
  /complexType
 /xsd:schema

-- 
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-1293) SDO does not work with OSGi

2008-02-13 Thread Kelvin Goodson (JIRA)


[ 
https://issues.apache.org/jira/browse/TUSCANY-1293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12568499#action_12568499
 ] 

Kelvin Goodson commented on TUSCANY-1293:
-

The patch seems to have fixed the continuum build issues.   
http://vmbuild.apache.org/continuum/buildResult.action?buildId=49832projectId=37

Amita,  please can you confirm you see the build as fixed.

 SDO does not work with OSGi
 ---

 Key: TUSCANY-1293
 URL: https://issues.apache.org/jira/browse/TUSCANY-1293
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Implementation
Affects Versions: Java-SDO-beta1
 Environment: OS X Eclipse 3.3 M7
Reporter: Bryan Hunt
Priority: Blocker
 Fix For: Java-SDO-Next

 Attachments: sdo-osgi-export-patch.txt, sdo-osgi.txt


 When I execute:
 XSDHelper.INSTANCE.define(schema, null);
 I end up with a NullPointerException.  I've tracked down root cause ...
 The static initializer of the HelperProvider executes this code:
   provider = getInstance(HelperProvider.class.getClassLoader());
 which ends up calling:
   HelperProvider provider = loadImplementation(cl, implName);
 implName is null so
 if (implName == null) {
 implName = getImplementationName(cl);
 }
 ends up calling
   implName = getImplementationName(cl);
 which ends up calling:
   InputStream is = cl.getResourceAsStream(SERVICE_RESOURCE_NAME);
 where SERVICE_RESORUCE_NAME = 
 META-INF/services/commonj.sdo.impl.HelperProvider
 getResourceAsStream() return null because META-INF/services does not exist in 
 the API bundle.  It exists in the IMPL bundle and since you are using the 
 class loader from the API bundle, it won't work.  
 You can set
 -Dcommonj.sdo.impl.HelperProvider=org.apache.tuscany.sdo.helper.HelperProviderImpl
 to get around the above problem, but as soon as 
   return (HelperProvider) cl.loadClass(implName).newInstance();
 executes, you get a CalssNotFoundException.  Again, this is because you are 
 trying to load a class outside the bundle with the wrong class loader.
  tried modifying the API manifest by hand to add
 Eclipse-BuddyPolicy: dependent
 and
 Eclipse-BuddyPolicy: global
 Either of those buddy policies will get past the class loader problem 
 (although I believe this is specific to eclipse and won't work for OSGi in 
 general), but when HelperProvider is initializing, you get the following 
 exception:
 java.lang.ExceptionInInitializerError
 at org.apache.tuscany.sdo.impl.AttributeImpl.clinit(AttributeImpl.java:126)
 at 
 org.apache.tuscany.sdo.impl.SDOFactoryImpl.createAttribute(SDOFactoryImpl.java:239)
 at org.apache.tuscany.sdo.impl.ClassImpl.clinit(ClassImpl.java:68)
 at 
 org.apache.tuscany.sdo.impl.SDOFactoryImpl$SDOEcoreFactory.createEClass(SDOFactoryImpl.java:76)
 at 
 org.apache.tuscany.sdo.impl.SDOPackageImpl.createEClass(SDOPackageImpl.java:622)
 at 
 org.apache.tuscany.sdo.impl.SDOPackageImpl.createPackageContents(SDOPackageImpl.java:550)
 at org.apache.tuscany.sdo.impl.SDOPackageImpl.init(SDOPackageImpl.java:259)
 at org.apache.tuscany.sdo.SDOPackage.clinit(SDOPackage.java:76)
 at sun.misc.Unsafe.ensureClassInitialized(Native Method)
 at 
 sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:25)
 at sun.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:122)
 at java.lang.reflect.Field.acquireFieldAccessor(Field.java:917)
 at java.lang.reflect.Field.getFieldAccessor(Field.java:898)
 at java.lang.reflect.Field.get(Field.java:357)
 at org.apache.tuscany.sdo.util.SDOUtil.registerStaticTypes(SDOUtil.java:196)
 at 
 org.apache.tuscany.sdo.model.impl.ModelFactoryImpl.init(ModelFactoryImpl.java:731)
 at org.apache.tuscany.sdo.model.ModelFactory.clinit(ModelFactory.java:41)
 at 
 org.apache.tuscany.sdo.helper.TypeHelperImpl.getBuiltInModels(TypeHelperImpl.java:61)
 at org.apache.tuscany.sdo.helper.TypeHelperImpl.init(TypeHelperImpl.java:79)
 at 
 org.apache.tuscany.sdo.helper.HelperContextImpl.init(HelperContextImpl.java:46)
 at 
 org.apache.tuscany.sdo.helper.HelperProviderImpl.createDefaultHelpers(HelperProviderImpl.java:38)
 at 
 org.apache.tuscany.sdo.rtlib.helper.HelperProviderBase.init(HelperProviderBase.java:78)
 at 
 org.apache.tuscany.sdo.helper.HelperProviderImpl.init(HelperProviderImpl.java:31)
 at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
 at 
 sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
 at 
 sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
 at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
 at java.lang.Class.newInstance0(Class.java:350)
 at java.lang.Class.newInstance(Class.java:303)
 at commonj.sdo.impl.HelperProvider.loadImplementation

[jira] Commented: (TUSCANY-1293) SDO does not work with OSGi


[ 
https://issues.apache.org/jira/browse/TUSCANY-1293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12568126#action_12568126
 ] 

Kelvin Goodson commented on TUSCANY-1293:
-

I have applied your 2nd patch,  after seeing a clean build in my own 
environment.  I will now seek a continuum build

 SDO does not work with OSGi
 ---

 Key: TUSCANY-1293
 URL: https://issues.apache.org/jira/browse/TUSCANY-1293
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Implementation
Affects Versions: Java-SDO-beta1
 Environment: OS X Eclipse 3.3 M7
Reporter: Bryan Hunt
Priority: Blocker
 Fix For: Java-SDO-Next

 Attachments: sdo-osgi-export-patch.txt, sdo-osgi.txt


 When I execute:
 XSDHelper.INSTANCE.define(schema, null);
 I end up with a NullPointerException.  I've tracked down root cause ...
 The static initializer of the HelperProvider executes this code:
   provider = getInstance(HelperProvider.class.getClassLoader());
 which ends up calling:
   HelperProvider provider = loadImplementation(cl, implName);
 implName is null so
 if (implName == null) {
 implName = getImplementationName(cl);
 }
 ends up calling
   implName = getImplementationName(cl);
 which ends up calling:
   InputStream is = cl.getResourceAsStream(SERVICE_RESOURCE_NAME);
 where SERVICE_RESORUCE_NAME = 
 META-INF/services/commonj.sdo.impl.HelperProvider
 getResourceAsStream() return null because META-INF/services does not exist in 
 the API bundle.  It exists in the IMPL bundle and since you are using the 
 class loader from the API bundle, it won't work.  
 You can set
 -Dcommonj.sdo.impl.HelperProvider=org.apache.tuscany.sdo.helper.HelperProviderImpl
 to get around the above problem, but as soon as 
   return (HelperProvider) cl.loadClass(implName).newInstance();
 executes, you get a CalssNotFoundException.  Again, this is because you are 
 trying to load a class outside the bundle with the wrong class loader.
  tried modifying the API manifest by hand to add
 Eclipse-BuddyPolicy: dependent
 and
 Eclipse-BuddyPolicy: global
 Either of those buddy policies will get past the class loader problem 
 (although I believe this is specific to eclipse and won't work for OSGi in 
 general), but when HelperProvider is initializing, you get the following 
 exception:
 java.lang.ExceptionInInitializerError
 at org.apache.tuscany.sdo.impl.AttributeImpl.clinit(AttributeImpl.java:126)
 at 
 org.apache.tuscany.sdo.impl.SDOFactoryImpl.createAttribute(SDOFactoryImpl.java:239)
 at org.apache.tuscany.sdo.impl.ClassImpl.clinit(ClassImpl.java:68)
 at 
 org.apache.tuscany.sdo.impl.SDOFactoryImpl$SDOEcoreFactory.createEClass(SDOFactoryImpl.java:76)
 at 
 org.apache.tuscany.sdo.impl.SDOPackageImpl.createEClass(SDOPackageImpl.java:622)
 at 
 org.apache.tuscany.sdo.impl.SDOPackageImpl.createPackageContents(SDOPackageImpl.java:550)
 at org.apache.tuscany.sdo.impl.SDOPackageImpl.init(SDOPackageImpl.java:259)
 at org.apache.tuscany.sdo.SDOPackage.clinit(SDOPackage.java:76)
 at sun.misc.Unsafe.ensureClassInitialized(Native Method)
 at 
 sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:25)
 at sun.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:122)
 at java.lang.reflect.Field.acquireFieldAccessor(Field.java:917)
 at java.lang.reflect.Field.getFieldAccessor(Field.java:898)
 at java.lang.reflect.Field.get(Field.java:357)
 at org.apache.tuscany.sdo.util.SDOUtil.registerStaticTypes(SDOUtil.java:196)
 at 
 org.apache.tuscany.sdo.model.impl.ModelFactoryImpl.init(ModelFactoryImpl.java:731)
 at org.apache.tuscany.sdo.model.ModelFactory.clinit(ModelFactory.java:41)
 at 
 org.apache.tuscany.sdo.helper.TypeHelperImpl.getBuiltInModels(TypeHelperImpl.java:61)
 at org.apache.tuscany.sdo.helper.TypeHelperImpl.init(TypeHelperImpl.java:79)
 at 
 org.apache.tuscany.sdo.helper.HelperContextImpl.init(HelperContextImpl.java:46)
 at 
 org.apache.tuscany.sdo.helper.HelperProviderImpl.createDefaultHelpers(HelperProviderImpl.java:38)
 at 
 org.apache.tuscany.sdo.rtlib.helper.HelperProviderBase.init(HelperProviderBase.java:78)
 at 
 org.apache.tuscany.sdo.helper.HelperProviderImpl.init(HelperProviderImpl.java:31)
 at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
 at 
 sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
 at 
 sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
 at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
 at java.lang.Class.newInstance0(Class.java:350)
 at java.lang.Class.newInstance(Class.java:303)
 at commonj.sdo.impl.HelperProvider.loadImplementation(HelperProvider.java:157)
 at commonj.sdo.impl.HelperProvider.getInstance(HelperProvider.java

Re: svn commit: r620763 - in /incubator/tuscany/java/sdo: impl/ impl/src/main/java/org/apache/tuscany/sdo/osgi/ impl/src/main/resources/META-INF/ impl/src/test/java/org/apache/tuscany/sdo/test/osgi/ i

2008-02-12 Thread kelvin goodson

This commit seems to be causing problems in continuum and elsewhere,  but
not in my env.  See comments in the JIRA (1293) Investigating.


On 12/02/2008, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:

 Author: kelvingoodson
 Date: Tue Feb 12 03:13:53 2008
 New Revision: 620763

 URL: http://svn.apache.org/viewvc?rev=620763view=rev
 Log:
 Fix for TUSCANY-1293

 Added:

 incubator/tuscany/java/sdo/impl/src/main/java/org/apache/tuscany/sdo/osgi/
 
 incubator/tuscany/java/sdo/impl/src/main/java/org/apache/tuscany/sdo/osgi/SdoBundleActivator.java
 (with props)

 
 incubator/tuscany/java/sdo/impl/src/test/java/org/apache/tuscany/sdo/test/osgi/
 
 incubator/tuscany/java/sdo/impl/src/test/java/org/apache/tuscany/sdo/test/osgi/ClassLoaderTestCase.java
 (with props)
 
 incubator/tuscany/java/sdo/impl/src/test/java/org/apache/tuscany/sdo/test/osgi/OSGiTestCase.java
 (with props)
 
 incubator/tuscany/java/sdo/impl/src/test/java/org/apache/tuscany/sdo/test/osgi/TestBundleActivator.java
 (with props)
 incubator/tuscany/java/sdo/impl/src/test/resources/osgi/
 incubator/tuscany/java/sdo/impl/src/test/resources/osgi/sdo.impl.mf

 incubator/tuscany/java/sdo/impl/src/test/resources/osgi/sdo.osgi.test.mf
 Modified:
 incubator/tuscany/java/sdo/impl/pom.xml

 incubator/tuscany/java/sdo/impl/src/main/resources/META-INF/MANIFEST.MF
 incubator/tuscany/java/sdo/lib/src/main/resources/META-INF/MANIFEST.MF
 incubator/tuscany/java/sdo/sdo-api/pom.xml

 
 incubator/tuscany/java/sdo/sdo-api/src/main/java/commonj/sdo/impl/HelperProvider.java

 Modified: incubator/tuscany/java/sdo/impl/pom.xml
 URL:
 http://svn.apache.org/viewvc/incubator/tuscany/java/sdo/impl/pom.xml?rev=620763r1=620762r2=620763view=diff

 ==
 --- incubator/tuscany/java/sdo/impl/pom.xml (original)
 +++ incubator/tuscany/java/sdo/impl/pom.xml Tue Feb 12 03:13:53 2008
 @@ -103,6 +103,13 @@
  version3.2.1/version
  /dependency

 +!-- dependencies for OSGi support --
 +dependency
 +groupIdorg.apache.felix/groupId
 +artifactIdorg.apache.felix.main/artifactId
 +version1.0.1/version
 +/dependency
 +
 !-- dependencies for test cases --
  dependency
  groupIdjunit/groupId

 Added:
 incubator/tuscany/java/sdo/impl/src/main/java/org/apache/tuscany/sdo/osgi/SdoBundleActivator.java
 URL:
 http://svn.apache.org/viewvc/incubator/tuscany/java/sdo/impl/src/main/java/org/apache/tuscany/sdo/osgi/SdoBundleActivator.java?rev=620763view=auto

 ==
 ---
 incubator/tuscany/java/sdo/impl/src/main/java/org/apache/tuscany/sdo/osgi/SdoBundleActivator.java
 (added)
 +++
 incubator/tuscany/java/sdo/impl/src/main/java/org/apache/tuscany/sdo/osgi/SdoBundleActivator.java
 Tue Feb 12 03:13:53 2008
 @@ -0,0 +1,22 @@
 +package org.apache.tuscany.sdo.osgi;
 +
 +import org.osgi.framework.BundleActivator;
 +import org.osgi.framework.BundleContext;
 +
 +import commonj.sdo.impl.HelperProvider;
 +
 +public class SdoBundleActivator implements BundleActivator {
 +
 +
 +   public void start(BundleContext bundleContext) throws Exception {
 +
 +   HelperProvider.setDefaultInstance(this.getClass
 ().getClassLoader());
 +
 +   }
 +
 +   public void stop(BundleContext bundleContext) throws Exception {
 +
 +   }
 +
 +
 +}

 Propchange:
 incubator/tuscany/java/sdo/impl/src/main/java/org/apache/tuscany/sdo/osgi/SdoBundleActivator.java

 --
 svn:eol-style = native

 Propchange:
 incubator/tuscany/java/sdo/impl/src/main/java/org/apache/tuscany/sdo/osgi/SdoBundleActivator.java

 --
 svn:keywords = Rev Date

 Modified:
 incubator/tuscany/java/sdo/impl/src/main/resources/META-INF/MANIFEST.MF
 URL:
 http://svn.apache.org/viewvc/incubator/tuscany/java/sdo/impl/src/main/resources/META-INF/MANIFEST.MF?rev=620763r1=620762r2=620763view=diff

 ==
 ---
 incubator/tuscany/java/sdo/impl/src/main/resources/META-INF/MANIFEST.MF
 (original)
 +++
 incubator/tuscany/java/sdo/impl/src/main/resources/META-INF/MANIFEST.MF Tue
 Feb 12 03:13:53 2008
 @@ -11,15 +11,19 @@
 Bundle-SymbolicName: org.apache.tuscany.sdo.impl
 Bundle-Version: 1.0.0
 Bundle-Vendor: Apache Software Foundation
 -Require-Bundle: org.eclipse.emf.common,
 +Require-Bundle-FIXME: org.eclipse.emf.common,
   org.eclipse.emf.ecore,
   org.eclipse.emf.ecore.change,
   org.eclipse.emf.ecore.xmi,
   org.eclipse.xsd,
   org.apache.tuscany.sdo.spec;visibility:=reexport
 +Import-Package: org.osgi.framework
 Export-Package: commonj.sdo.impl,
   org.apache.tuscany.sdo,
   org.apache.tuscany.sdo.helper,

[jira] Commented: (TUSCANY-257) recently added file Interface2JavaGenerator.java is not compatible with JDK 1.4


[ 
https://issues.apache.org/jira/browse/TUSCANY-257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12568064#action_12568064
 ] 

Kelvin Goodson commented on TUSCANY-257:


Thanks Amita,  I took a scan of the patch file and it appears good.  The only 
thing I spotted is that we need a new java_1_4 maven profile that does not 
include the new project.

 recently added file Interface2JavaGenerator.java is not compatible with JDK 
 1.4
 ---

 Key: TUSCANY-257
 URL: https://issues.apache.org/jira/browse/TUSCANY-257
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Tools
 Environment: all
Reporter: Paul Golick
 Fix For: Java-SDO-Next

 Attachments: 257.patch, newFiles.jar, 
 patchInterface2JavaGenerator.txt, patchUpdated.txt


 Interface2JavaGenerator.java uses java.lang.reflect.ParameterizedType and 
 java.lang.reflect.Type that were added in Java 5 for generics.  It appears 
 that the portion of Interface2JavaGenerator that uses ParameterizedType and 
 Type is not needed for Java 1.4 classes.

-- 
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-1293) SDO does not work with OSGi


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

Kelvin Goodson resolved TUSCANY-1293.
-

Resolution: Fixed

Thanks for the patch Rajini.

 SDO does not work with OSGi
 ---

 Key: TUSCANY-1293
 URL: https://issues.apache.org/jira/browse/TUSCANY-1293
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Implementation
Affects Versions: Java-SDO-beta1
 Environment: OS X Eclipse 3.3 M7
Reporter: Bryan Hunt
Priority: Blocker
 Fix For: Java-SDO-Next

 Attachments: sdo-osgi.txt


 When I execute:
 XSDHelper.INSTANCE.define(schema, null);
 I end up with a NullPointerException.  I've tracked down root cause ...
 The static initializer of the HelperProvider executes this code:
   provider = getInstance(HelperProvider.class.getClassLoader());
 which ends up calling:
   HelperProvider provider = loadImplementation(cl, implName);
 implName is null so
 if (implName == null) {
 implName = getImplementationName(cl);
 }
 ends up calling
   implName = getImplementationName(cl);
 which ends up calling:
   InputStream is = cl.getResourceAsStream(SERVICE_RESOURCE_NAME);
 where SERVICE_RESORUCE_NAME = 
 META-INF/services/commonj.sdo.impl.HelperProvider
 getResourceAsStream() return null because META-INF/services does not exist in 
 the API bundle.  It exists in the IMPL bundle and since you are using the 
 class loader from the API bundle, it won't work.  
 You can set
 -Dcommonj.sdo.impl.HelperProvider=org.apache.tuscany.sdo.helper.HelperProviderImpl
 to get around the above problem, but as soon as 
   return (HelperProvider) cl.loadClass(implName).newInstance();
 executes, you get a CalssNotFoundException.  Again, this is because you are 
 trying to load a class outside the bundle with the wrong class loader.
  tried modifying the API manifest by hand to add
 Eclipse-BuddyPolicy: dependent
 and
 Eclipse-BuddyPolicy: global
 Either of those buddy policies will get past the class loader problem 
 (although I believe this is specific to eclipse and won't work for OSGi in 
 general), but when HelperProvider is initializing, you get the following 
 exception:
 java.lang.ExceptionInInitializerError
 at org.apache.tuscany.sdo.impl.AttributeImpl.clinit(AttributeImpl.java:126)
 at 
 org.apache.tuscany.sdo.impl.SDOFactoryImpl.createAttribute(SDOFactoryImpl.java:239)
 at org.apache.tuscany.sdo.impl.ClassImpl.clinit(ClassImpl.java:68)
 at 
 org.apache.tuscany.sdo.impl.SDOFactoryImpl$SDOEcoreFactory.createEClass(SDOFactoryImpl.java:76)
 at 
 org.apache.tuscany.sdo.impl.SDOPackageImpl.createEClass(SDOPackageImpl.java:622)
 at 
 org.apache.tuscany.sdo.impl.SDOPackageImpl.createPackageContents(SDOPackageImpl.java:550)
 at org.apache.tuscany.sdo.impl.SDOPackageImpl.init(SDOPackageImpl.java:259)
 at org.apache.tuscany.sdo.SDOPackage.clinit(SDOPackage.java:76)
 at sun.misc.Unsafe.ensureClassInitialized(Native Method)
 at 
 sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:25)
 at sun.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:122)
 at java.lang.reflect.Field.acquireFieldAccessor(Field.java:917)
 at java.lang.reflect.Field.getFieldAccessor(Field.java:898)
 at java.lang.reflect.Field.get(Field.java:357)
 at org.apache.tuscany.sdo.util.SDOUtil.registerStaticTypes(SDOUtil.java:196)
 at 
 org.apache.tuscany.sdo.model.impl.ModelFactoryImpl.init(ModelFactoryImpl.java:731)
 at org.apache.tuscany.sdo.model.ModelFactory.clinit(ModelFactory.java:41)
 at 
 org.apache.tuscany.sdo.helper.TypeHelperImpl.getBuiltInModels(TypeHelperImpl.java:61)
 at org.apache.tuscany.sdo.helper.TypeHelperImpl.init(TypeHelperImpl.java:79)
 at 
 org.apache.tuscany.sdo.helper.HelperContextImpl.init(HelperContextImpl.java:46)
 at 
 org.apache.tuscany.sdo.helper.HelperProviderImpl.createDefaultHelpers(HelperProviderImpl.java:38)
 at 
 org.apache.tuscany.sdo.rtlib.helper.HelperProviderBase.init(HelperProviderBase.java:78)
 at 
 org.apache.tuscany.sdo.helper.HelperProviderImpl.init(HelperProviderImpl.java:31)
 at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
 at 
 sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
 at 
 sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
 at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
 at java.lang.Class.newInstance0(Class.java:350)
 at java.lang.Class.newInstance(Class.java:303)
 at commonj.sdo.impl.HelperProvider.loadImplementation(HelperProvider.java:157)
 at commonj.sdo.impl.HelperProvider.getInstance(HelperProvider.java:126)
 at commonj.sdo.impl.HelperProvider.clinit(HelperProvider.java:69)
 at commonj.sdo.helper.XSDHelper.clinit(XSDHelper.java:195

[jira] Commented: (TUSCANY-1293) SDO does not work with OSGi


[ 
https://issues.apache.org/jira/browse/TUSCANY-1293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12568083#action_12568083
 ] 

Kelvin Goodson commented on TUSCANY-1293:
-

Amita,   I get clean build from a clean extraction.  Looking at runSDOTests()  
for your run there ought to be 106 outputs to system.out of TestFalluire 
instances.  Can you take a look at these, and attach to the JIRA please?

 SDO does not work with OSGi
 ---

 Key: TUSCANY-1293
 URL: https://issues.apache.org/jira/browse/TUSCANY-1293
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Implementation
Affects Versions: Java-SDO-beta1
 Environment: OS X Eclipse 3.3 M7
Reporter: Bryan Hunt
Priority: Blocker
 Fix For: Java-SDO-Next

 Attachments: sdo-osgi.txt


 When I execute:
 XSDHelper.INSTANCE.define(schema, null);
 I end up with a NullPointerException.  I've tracked down root cause ...
 The static initializer of the HelperProvider executes this code:
   provider = getInstance(HelperProvider.class.getClassLoader());
 which ends up calling:
   HelperProvider provider = loadImplementation(cl, implName);
 implName is null so
 if (implName == null) {
 implName = getImplementationName(cl);
 }
 ends up calling
   implName = getImplementationName(cl);
 which ends up calling:
   InputStream is = cl.getResourceAsStream(SERVICE_RESOURCE_NAME);
 where SERVICE_RESORUCE_NAME = 
 META-INF/services/commonj.sdo.impl.HelperProvider
 getResourceAsStream() return null because META-INF/services does not exist in 
 the API bundle.  It exists in the IMPL bundle and since you are using the 
 class loader from the API bundle, it won't work.  
 You can set
 -Dcommonj.sdo.impl.HelperProvider=org.apache.tuscany.sdo.helper.HelperProviderImpl
 to get around the above problem, but as soon as 
   return (HelperProvider) cl.loadClass(implName).newInstance();
 executes, you get a CalssNotFoundException.  Again, this is because you are 
 trying to load a class outside the bundle with the wrong class loader.
  tried modifying the API manifest by hand to add
 Eclipse-BuddyPolicy: dependent
 and
 Eclipse-BuddyPolicy: global
 Either of those buddy policies will get past the class loader problem 
 (although I believe this is specific to eclipse and won't work for OSGi in 
 general), but when HelperProvider is initializing, you get the following 
 exception:
 java.lang.ExceptionInInitializerError
 at org.apache.tuscany.sdo.impl.AttributeImpl.clinit(AttributeImpl.java:126)
 at 
 org.apache.tuscany.sdo.impl.SDOFactoryImpl.createAttribute(SDOFactoryImpl.java:239)
 at org.apache.tuscany.sdo.impl.ClassImpl.clinit(ClassImpl.java:68)
 at 
 org.apache.tuscany.sdo.impl.SDOFactoryImpl$SDOEcoreFactory.createEClass(SDOFactoryImpl.java:76)
 at 
 org.apache.tuscany.sdo.impl.SDOPackageImpl.createEClass(SDOPackageImpl.java:622)
 at 
 org.apache.tuscany.sdo.impl.SDOPackageImpl.createPackageContents(SDOPackageImpl.java:550)
 at org.apache.tuscany.sdo.impl.SDOPackageImpl.init(SDOPackageImpl.java:259)
 at org.apache.tuscany.sdo.SDOPackage.clinit(SDOPackage.java:76)
 at sun.misc.Unsafe.ensureClassInitialized(Native Method)
 at 
 sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:25)
 at sun.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:122)
 at java.lang.reflect.Field.acquireFieldAccessor(Field.java:917)
 at java.lang.reflect.Field.getFieldAccessor(Field.java:898)
 at java.lang.reflect.Field.get(Field.java:357)
 at org.apache.tuscany.sdo.util.SDOUtil.registerStaticTypes(SDOUtil.java:196)
 at 
 org.apache.tuscany.sdo.model.impl.ModelFactoryImpl.init(ModelFactoryImpl.java:731)
 at org.apache.tuscany.sdo.model.ModelFactory.clinit(ModelFactory.java:41)
 at 
 org.apache.tuscany.sdo.helper.TypeHelperImpl.getBuiltInModels(TypeHelperImpl.java:61)
 at org.apache.tuscany.sdo.helper.TypeHelperImpl.init(TypeHelperImpl.java:79)
 at 
 org.apache.tuscany.sdo.helper.HelperContextImpl.init(HelperContextImpl.java:46)
 at 
 org.apache.tuscany.sdo.helper.HelperProviderImpl.createDefaultHelpers(HelperProviderImpl.java:38)
 at 
 org.apache.tuscany.sdo.rtlib.helper.HelperProviderBase.init(HelperProviderBase.java:78)
 at 
 org.apache.tuscany.sdo.helper.HelperProviderImpl.init(HelperProviderImpl.java:31)
 at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
 at 
 sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
 at 
 sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
 at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
 at java.lang.Class.newInstance0(Class.java:350)
 at java.lang.Class.newInstance(Class.java:303)
 at commonj.sdo.impl.HelperProvider.loadImplementation

[jira] Commented: (TUSCANY-1293) SDO does not work with OSGi


[ 
https://issues.apache.org/jira/browse/TUSCANY-1293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12567667#action_12567667
 ] 

Kelvin Goodson commented on TUSCANY-1293:
-

Rajini,
  sorry to take so long to get to this,  and thanks for the patch.  I'm working 
towards getting thsi in for the next release.  I note a couple of occasions in 
the tests where an exception is caught,  and then either output is made to the 
System.out,  or the exception is ignored.  Could you help me understand if in 
either of these cases the symptom is truly benign please?  If so i will add a 
comment to the code.  If not then I'll change to let the exception surface 
through the test infrastructure.

First is on OSGITestCase ...

 // Start all the installed bundles
 for (int i = 0; i  bundles.size(); i++) {
 Bundle bundle = (Bundle)bundles.get(i);
 try {
bundle.start();
} catch (Exception e) {
e.printStackTrace();
System.out.println(Could not start bundle  + 
bundle);
}
 }


second is in ClassLoaderTestCase  (I think I can see this is benign,  but could 
do with confirmation)

for (int i = 0; i  parentLoaders.length; i++) {
try {
return 
parentLoaders[i].loadClass(className);   
} catch (Exception e) {
}
}


 SDO does not work with OSGi
 ---

 Key: TUSCANY-1293
 URL: https://issues.apache.org/jira/browse/TUSCANY-1293
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Implementation
Affects Versions: Java-SDO-beta1
 Environment: OS X Eclipse 3.3 M7
Reporter: Bryan Hunt
Priority: Blocker
 Fix For: Java-SDO-Next

 Attachments: sdo-osgi.txt


 When I execute:
 XSDHelper.INSTANCE.define(schema, null);
 I end up with a NullPointerException.  I've tracked down root cause ...
 The static initializer of the HelperProvider executes this code:
   provider = getInstance(HelperProvider.class.getClassLoader());
 which ends up calling:
   HelperProvider provider = loadImplementation(cl, implName);
 implName is null so
 if (implName == null) {
 implName = getImplementationName(cl);
 }
 ends up calling
   implName = getImplementationName(cl);
 which ends up calling:
   InputStream is = cl.getResourceAsStream(SERVICE_RESOURCE_NAME);
 where SERVICE_RESORUCE_NAME = 
 META-INF/services/commonj.sdo.impl.HelperProvider
 getResourceAsStream() return null because META-INF/services does not exist in 
 the API bundle.  It exists in the IMPL bundle and since you are using the 
 class loader from the API bundle, it won't work.  
 You can set
 -Dcommonj.sdo.impl.HelperProvider=org.apache.tuscany.sdo.helper.HelperProviderImpl
 to get around the above problem, but as soon as 
   return (HelperProvider) cl.loadClass(implName).newInstance();
 executes, you get a CalssNotFoundException.  Again, this is because you are 
 trying to load a class outside the bundle with the wrong class loader.
  tried modifying the API manifest by hand to add
 Eclipse-BuddyPolicy: dependent
 and
 Eclipse-BuddyPolicy: global
 Either of those buddy policies will get past the class loader problem 
 (although I believe this is specific to eclipse and won't work for OSGi in 
 general), but when HelperProvider is initializing, you get the following 
 exception:
 java.lang.ExceptionInInitializerError
 at org.apache.tuscany.sdo.impl.AttributeImpl.clinit(AttributeImpl.java:126)
 at 
 org.apache.tuscany.sdo.impl.SDOFactoryImpl.createAttribute(SDOFactoryImpl.java:239)
 at org.apache.tuscany.sdo.impl.ClassImpl.clinit(ClassImpl.java:68)
 at 
 org.apache.tuscany.sdo.impl.SDOFactoryImpl$SDOEcoreFactory.createEClass(SDOFactoryImpl.java:76)
 at 
 org.apache.tuscany.sdo.impl.SDOPackageImpl.createEClass(SDOPackageImpl.java:622)
 at 
 org.apache.tuscany.sdo.impl.SDOPackageImpl.createPackageContents(SDOPackageImpl.java:550)
 at org.apache.tuscany.sdo.impl.SDOPackageImpl.init(SDOPackageImpl.java:259)
 at org.apache.tuscany.sdo.SDOPackage.clinit(SDOPackage.java:76)
 at sun.misc.Unsafe.ensureClassInitialized(Native Method)
 at 
 sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:25)
 at sun.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:122)
 at java.lang.reflect.Field.acquireFieldAccessor(Field.java:917)
 at java.lang.reflect.Field.getFieldAccessor(Field.java:898)
 at java.lang.reflect.Field.get(Field.java:357

[jira] Updated: (TUSCANY-1688) XSD2JavaGenerator throws IOException:Access is denied with complexType named Con


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

Kelvin Goodson updated TUSCANY-1688:



I did a check for EMF bugs raised for this issue,  but couldn't find one.  Do 
you know if this issue has been addressed in EMF?

 XSD2JavaGenerator throws IOException:Access is denied with complexType named 
 Con
 --

 Key: TUSCANY-1688
 URL: https://issues.apache.org/jira/browse/TUSCANY-1688
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Tools
Affects Versions: Java-SDO-Next
 Environment: Windows XP SP2 w/Sun JDK 1.4.2_11
Reporter: Ron Gavlin
 Fix For: Java-SDO-Next


 I have an XML Schema that contains a complexType named Con. The following 
 error output is displayed to stdout:
  Generating Con
  Generating Java interface test.Con
  Generating /TargetProject/test/Con.java
  Examining old /TargetProject/test/Con.java
 org.eclipse.emf.common.util.WrappedException: java.io.IOException: Access is 
 denied
 at 
 org.eclipse.emf.codegen.ecore.generator.AbstractGeneratorAdapter.generateJava 
 (AbstractGeneratorAdapter.java:1046)
 at 
 org.eclipse.emf.codegen.ecore.genmodel.generator.GenClassGeneratorAdapter.generateInterface
  (GenClassGeneratorAdapter.java:123)
 at 
 org.eclipse.emf.codegen.ecore.genmodel.generator.GenClassGeneratorAdapter.generateModel
  (GenClassGeneratorAdapter.java:106)
 at 
 org.eclipse.emf.codegen.ecore.genmodel.generator.GenBaseGeneratorAdapter.doGenerate
  (GenBaseGeneratorAdapter.java:214)
 at org.eclipse.emf.codegen.ecore.generator.AbstractGeneratorAdapter.generate 
 (AbstractGeneratorAdapter.java:275)
 at org.eclipse.emf.codegen.ecore.generator.Generator.generate 
 (Generator.java:600)
 at org.eclipse.emf.codegen.ecore.generator.Generator.generate 
 (Generator.java:512)
 at org.apache.tuscany.sdo.generate.JavaGenerator.generateFromGenModel 
 (JavaGenerator.java:515)
 ...
 It seems as if the type name 'Con' conflicts with the operating system's 
 console device named 'Con'. The code first checks to see if the file exists 
 to decide if a merge is required. The code seems to incorrectly find the 
 file/device named 'Con' and then tries to access it in error. I suspect this 
 is an Eclipse EMF problem.

-- 
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-1689) XSD2JavaGenerator generates non-compilable FactoryImpl class with complexType named Descriptor


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

Kelvin Goodson updated TUSCANY-1689:



I did a check for EMF bugs raised for this issue,  but couldn't find one.  Do 
you know if this issue has been addressed in EMF?

 XSD2JavaGenerator generates non-compilable FactoryImpl class with complexType 
 named Descriptor
 

 Key: TUSCANY-1689
 URL: https://issues.apache.org/jira/browse/TUSCANY-1689
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Tools
 Environment: Windows XP SP2 w/Sun JDK 1.4.2_11
Reporter: Ron Gavlin
 Fix For: Java-SDO-Next


 I have a schema with a complexType named Descriptor. 
 The generated FactoryImpl.java class includes the following code which does 
 not compile because the return type 
 org.eclipse.emf.ecore.EPackage.Descriptor is not compatible with 
 Factory.createDescriptor() with return type myNamespace.Descriptor:
 public Descriptor createDescriptor()
 {
   DescriptorImpl descriptor = new DescriptorImpl();
   return descriptor;
 }
 I suspect this is an EMF bug but I am reporting it here.

-- 
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-1831) Make SDOPackageRegistryDelegator pluggable