Adding Jira components
How do I create new Components in Jira for Tuscany. I'd like: cpp Build cpp SCA cpp SDO Pete
Re: How to gen the generated EMF code?
I think i'm working this out with the help of the tutorial at: http://www.eclipse.org/emf/docs.php?doc=tutorials/xlibmod/xlibmod.html Based on that i've been able to recreate the gen'd code for the Java component type and have the tests pass. One problem though is that the generated package name is wrong - o.a.t.container.java.assembly.java.assembly instead of o.a.t.container.java.assembly.java.assembly.sdo, and the class names are all AssemblyXxx instead of JavaAssemblyXxx. Thats fixed with a bit of refactoring but its quite hard as there are so many similar class names. So any pointers on how to get the gen'd code come out with the correct class and package names? Thanks, ...ant On 1/17/06, ant elder [EMAIL PROTECTED] wrote: I'm trying to create a new component type based on the info from the last page in the subsytem.proposal.ppt and looking at the existing code for the Java component type, but I'm struggling a bit with all the generate code, for example, the classes in: http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/container.java/src/main/java/org/apache/tuscany/container/java/assembly/sdo/ Is there any doc on this or could anyone outline the basic steps required to generate these, for someone who isn't very familiar with emf? Thanks, ...ant
Re: Adding Jira components
Pete Robbins wrote: How do I create new Components in Jira for Tuscany. I'd like: cpp Build cpp SCA cpp SDO Created. I used C++ instead of cpp as there are no issues with characters. -- Jeremy
[jira] Assigned: (TUSCANY-13) Change C++ build to use Autoconf/Automake
[ http://issues.apache.org/jira/browse/TUSCANY-13?page=all ] Pete Robbins reassigned TUSCANY-13: --- Assign To: Pete Robbins Change C++ build to use Autoconf/Automake - Key: TUSCANY-13 URL: http://issues.apache.org/jira/browse/TUSCANY-13 Project: Tuscany Type: Improvement Components: C++ Build Reporter: Pete Robbins Assignee: Pete Robbins The current command line build of SDO and SCA C++ uses makefiles generated via eclipse CDT. These are difficult to maintain. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: How to gen the generated EMF code?
The package name and prefix can be customized as follows: 1) Open the xxx.genmodel in Eclipse 2) Under the Property view, change the settings Base Package: org.apache.tuscany.container.java (the model package name like assembly will be appended to form the java package) Prefix: JavaAssembly - Original Message - From: ant elder [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Wednesday, January 18, 2006 4:47 AM Subject: Re: How to gen the generated EMF code? I think i'm working this out with the help of the tutorial at: http://www.eclipse.org/emf/docs.php?doc=tutorials/xlibmod/xlibmod.html Based on that i've been able to recreate the gen'd code for the Java component type and have the tests pass. One problem though is that the generated package name is wrong - o.a.t.container.java.assembly.java.assembly instead of o.a.t.container.java.assembly.java.assembly.sdo, and the class names are all AssemblyXxx instead of JavaAssemblyXxx. Thats fixed with a bit of refactoring but its quite hard as there are so many similar class names. So any pointers on how to get the gen'd code come out with the correct class and package names? Thanks, ...ant On 1/17/06, ant elder [EMAIL PROTECTED] wrote: I'm trying to create a new component type based on the info from the last page in the subsytem.proposal.ppt and looking at the existing code for the Java component type, but I'm struggling a bit with all the generate code, for example, the classes in: http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/container.java/src/main/java/org/apache/tuscany/container/java/assembly/sdo/ Is there any doc on this or could anyone outline the basic steps required to generate these, for someone who isn't very familiar with emf? Thanks, ...ant
[jira] Updated: (TUSCANY-9) CastClassException from SimpleDynamicTestCase when run from mvn
[ http://issues.apache.org/jira/browse/TUSCANY-9?page=all ] Fuhwei Lwo updated TUSCANY-9: - Attachment: XSDHelperImpl.java The reason XSDHelper.define() would fail is that it cannot be called twice. There are more than one test cases loading simple.xsd to define its type. If you run one test case at one time, you would be fine. But if you run all test cases in maven env, the define() method will be called more than one time. In order to pass test cases in maven env, I have changed the define() to return existing defined type so test cases won't fail. Frank B., please review the attached file with my changes and commit the change if they make sense. Thanks. CastClassException from SimpleDynamicTestCase when run from mvn --- Key: TUSCANY-9 URL: http://issues.apache.org/jira/browse/TUSCANY-9 Project: Tuscany Type: Bug Components: Java SDO Implementation Reporter: Jeremy Boynes Attachments: XSDHelperImpl.java, org.apache.tuscany.sdo.test.SimpleDynamicTestCase.txt A ClassCastException is raised inside EMF when this test goes to save the DataObject to XML. The same test runs OK from Idea. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (TUSCANY-9) CastClassException from SimpleDynamicTestCase when run from mvn
[ http://issues.apache.org/jira/browse/TUSCANY-9?page=comments#action_12363130 ] Fuhwei Lwo commented on TUSCANY-9: -- By the way, this new XSDHelperImpl.java would also resolve the issue reported in TUSCANY-12. CastClassException from SimpleDynamicTestCase when run from mvn --- Key: TUSCANY-9 URL: http://issues.apache.org/jira/browse/TUSCANY-9 Project: Tuscany Type: Bug Components: Java SDO Implementation Reporter: Jeremy Boynes Attachments: XSDHelperImpl.java, org.apache.tuscany.sdo.test.SimpleDynamicTestCase.txt A ClassCastException is raised inside EMF when this test goes to save the DataObject to XML. The same test runs OK from Idea. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (TUSCANY-9) CastClassException from SimpleDynamicTestCase when run from mvn
[ http://issues.apache.org/jira/browse/TUSCANY-9?page=comments#action_12363139 ] Jeremy Boynes commented on TUSCANY-9: - Applied patch: Sending impl/src/main/java/org/apache/tuscany/sdo/helper/XSDHelperImpl.java Sending impl/src/test/java/org/apache/tuscany/sdo/test/XSDHelperTestCase.java Transmitting file data .. Committed revision 370220. CastClassException from SimpleDynamicTestCase when run from mvn --- Key: TUSCANY-9 URL: http://issues.apache.org/jira/browse/TUSCANY-9 Project: Tuscany Type: Bug Components: Java SDO Implementation Reporter: Jeremy Boynes Attachments: XSDHelperImpl.java, org.apache.tuscany.sdo.test.SimpleDynamicTestCase.txt A ClassCastException is raised inside EMF when this test goes to save the DataObject to XML. The same test runs OK from Idea. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (TUSCANY-11) XSDHelper.define() throws NPE if schemaLocation is null
[ http://issues.apache.org/jira/browse/TUSCANY-11?page=all ] Frank Budinsky reassigned TUSCANY-11: - Assign To: Frank Budinsky XSDHelper.define() throws NPE if schemaLocation is null --- Key: TUSCANY-11 URL: http://issues.apache.org/jira/browse/TUSCANY-11 Project: Tuscany Type: Bug Components: Java SDO Implementation Reporter: Jeremy Boynes Assignee: Frank Budinsky The API JavaDoc says: * @param schemaLocation the URI of the location of the schema, used * for processing relative imports and includes. May be null if not used. but if null is passed then a NPE is thrown -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Setting up SDO2 factories
Jeremy,
I think this should work, but you need to register the statically
generated model by calling SDOUtil.registerStaticTypes().
You need to first generate the classes (if you already have SDO 1
generated classes, it may also work, but I'd recommend regening with the
SDO 2 generator).
Then, you need to make sure to add a call like this (somewhere early
during startup):
SDOUtil.registerStaticTypes(MyFactory.class);
Frank.
Jeremy Boynes [EMAIL PROTECTED] wrote on 01/18/2006 12:52:26 PM:
I'm trying to convert the account sample over to using just the SDO2
APIs.
I tried using the XSDHelper to define the XSD for the account service
but it does not map up to the Java interfaces we have. Apparently the
XSDHelper can only be used to define dynamic types.
The implementations of the services use SDO2 helpers (e.g. DataFactory)
to create instances of the data interfaces. If I can't use XSDHelper,
how do I set up the SDO2 factories to be able to do this?
This is the simple testcase I am trying to get running:
public class AccountServiceTestCase extends TestCase {
private AccountService service;
public void testAccountReport() {
AccountReport report = service.getAccountReport(BOB);
}
protected void setUp() throws Exception {
super.setUp();
service = new AccountServiceImpl(
DataFactory.INSTANCE,
USD,
new AccountDataServiceImpl(),
new StockQuoteServiceImpl()
);
}
}
which fails when the AccountServiceImpl does:
AccountReport accountReport =
(AccountReport) dataFactory.create(AccountReport.class);
--
Jeremy
[jira] Updated: (TUSCANY-14) Some WSDLs used by the test cases don't conform to the WSDL schema
[ http://issues.apache.org/jira/browse/TUSCANY-14?page=all ] Raymond Feng updated TUSCANY-14: Attachment: AccountService.wsdl Fixed the missing required location attribute for soap:address element Some WSDLs used by the test cases don't conform to the WSDL schema -- Key: TUSCANY-14 URL: http://issues.apache.org/jira/browse/TUSCANY-14 Project: Tuscany Type: Bug Components: Java SCA Axis Integration Reporter: Raymond Feng Priority: Minor Attachments: AccountService.wsdl I noticed those problems with the WTP1.0. It seems that they're WSDL validation related issues. I observed the following cases. 1) The name attribute wsdl:definition is illegal (name=). (schema for the attribute: attribute name=name type=NMTOKEN use=optional/). 2) the location attribute is missing from soap:address. (schema for the attibute: attribute name=location type=uriReference use=required/) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TUSCANY-14) Some WSDLs used by the test cases don't conform to the WSDL schema
[ http://issues.apache.org/jira/browse/TUSCANY-14?page=all ] Raymond Feng updated TUSCANY-14: Attachment: StockQuoteWebService.wsdl change name= to name=stockquoteservice for wsdl:definition element Some WSDLs used by the test cases don't conform to the WSDL schema -- Key: TUSCANY-14 URL: http://issues.apache.org/jira/browse/TUSCANY-14 Project: Tuscany Type: Bug Components: Java SCA Axis Integration Reporter: Raymond Feng Priority: Minor Attachments: AccountService.wsdl, StockQuoteWebService.wsdl I noticed those problems with the WTP1.0. It seems that they're WSDL validation related issues. I observed the following cases. 1) The name attribute wsdl:definition is illegal (name=). (schema for the attribute: attribute name=name type=NMTOKEN use=optional/). 2) the location attribute is missing from soap:address. (schema for the attibute: attribute name=location type=uriReference use=required/) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TUSCANY-8) NPE in ExternalWebServiceHandler.getSOAPAction when Java interface method name doesn't match WSDL operation name
[ http://issues.apache.org/jira/browse/TUSCANY-8?page=all ] Raymond Feng updated TUSCANY-8: --- Attachment: ExternalWebServiceHandler.java Here's a patch for the NPE: throw ServiceRuntimeException instead java\sca\binding.axis\src\main\java\org\apache\tuscany\binding\axis\handler\ExternalWebServiceHandler.java NPE in ExternalWebServiceHandler.getSOAPAction when Java interface method name doesn't match WSDL operation name Key: TUSCANY-8 URL: http://issues.apache.org/jira/browse/TUSCANY-8 Project: Tuscany Type: Bug Components: Java SCA Axis Integration Reporter: ant elder Priority: Minor Attachments: ExternalWebServiceHandler.java If a WSDL portType has operation name that starts with a capital letter (common with .Net WSDL) but a component uses a Java interface which has the method name start with a lower case character then there's a null pointer exception at org.apache.tuscany.binding.axis.handler.ExternalWebServiceHandler.getSOAPAction(ExternalWebServiceHandler.java:427). Eg, this WSDL has an operation GetQuote for which the usual Java method name would be getQuote: http://www.webservicex.net/stockquote.asmx?WSDL Thia is a common problem with Java WS stacks making invocations without using mapping meta data. One solution is to change the Java interface to capitalize the method name to match the WSDL, but thats not standard Java naming practice and looks a bit ugly. Another solution could be to fix the Tuscany code to check for both un-capitalized and capitalized names when trying to find the correct operation. There's two places that would need changing for that: line 83 in org.apache.tuscany.binding.axis.handler.ExternalWebServiceConfigurationHandler line 140 in org.apache.tuscany.binding.axis.handler.ExternalWebServiceHandler Some people are quite dogmatic about this and say it should fail, others are more pragmatic and think its better to cope with this special case for users. What do you guys think? I can send in a patch for this if you agree. Either way, the NPE in getSOAPAction isn't the most helpful error. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (TUSCANY-8) NPE in ExternalWebServiceHandler.getSOAPAction when Java interface method name doesn't match WSDL operation name
[ http://issues.apache.org/jira/browse/TUSCANY-8?page=comments#action_12363181 ] Raymond Feng commented on TUSCANY-8: I think it's related to the WSDL operation -- Java method name mangling strategy. It's not only about the upper case/lower case convention but also the case that the operation name happens to be a java keyword. The fix will at least report the problem clearly until the mapping rule is agreed. NPE in ExternalWebServiceHandler.getSOAPAction when Java interface method name doesn't match WSDL operation name Key: TUSCANY-8 URL: http://issues.apache.org/jira/browse/TUSCANY-8 Project: Tuscany Type: Bug Components: Java SCA Axis Integration Reporter: ant elder Priority: Minor Attachments: ExternalWebServiceHandler.java If a WSDL portType has operation name that starts with a capital letter (common with .Net WSDL) but a component uses a Java interface which has the method name start with a lower case character then there's a null pointer exception at org.apache.tuscany.binding.axis.handler.ExternalWebServiceHandler.getSOAPAction(ExternalWebServiceHandler.java:427). Eg, this WSDL has an operation GetQuote for which the usual Java method name would be getQuote: http://www.webservicex.net/stockquote.asmx?WSDL Thia is a common problem with Java WS stacks making invocations without using mapping meta data. One solution is to change the Java interface to capitalize the method name to match the WSDL, but thats not standard Java naming practice and looks a bit ugly. Another solution could be to fix the Tuscany code to check for both un-capitalized and capitalized names when trying to find the correct operation. There's two places that would need changing for that: line 83 in org.apache.tuscany.binding.axis.handler.ExternalWebServiceConfigurationHandler line 140 in org.apache.tuscany.binding.axis.handler.ExternalWebServiceHandler Some people are quite dogmatic about this and say it should fail, others are more pragmatic and think its better to cope with this special case for users. What do you guys think? I can send in a patch for this if you agree. Either way, the NPE in getSOAPAction isn't the most helpful error. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Setting up SDO2 factories
Frank Budinsky wrote: Ultimately though it would be good if people could use SDO2 without needed to generate any code at all. Wouldn't it be possible to provide implementations of user interfaces using Java Proxies (perhaps with codegen using ASM or something to boost performance)? Well, a big part of SDO is the DataObject (reflective API). Dynamic SDO already provides a full implementation for that, so I suspect that what you're asking for would be to 1) dynamically load the metadata given a Java interface, and then 2) Bind a Java Proxy for the interface to the dynamic impl. It all sounds possible, but isn't currently part of the spec we're implementing. Something like that - have the proxy implement the user's interface and DataObject and delegate invocations to the dynamic SDO implementation. If the performance of dynamic SDO is acceptable the the proxy overhead is easy to fix. The spec talks a lot about the generation of Java interfaces but nothing about the associated implementation beyond it having to implement DataObject. It does, however, describe the compatibility for applications used to using JavaBeans. It may help build adoption if we provide ways that make it easy for people coming from that environment to migrate without having to regenerate their code. There are lots of things we should be doing that are not part of the specifications - this value add is what makes the difference between a useful implementation and an RI, or between a successful project and one that fades to obscurity. are there directions some place for using the command line tool? It's described in contrib/java/trunk/docs/SDO_Java_Project_Overview.doc. I'll check it out,thanks -- Jeremy
Re: Setting up SDO2 factories
On Jan 18, 2006, at 3:14 PM, Jeremy Boynes wrote: Frank Budinsky wrote: Ultimately though it would be good if people could use SDO2 without needed to generate any code at all. Wouldn't it be possible to provide implementations of user interfaces using Java Proxies (perhaps with codegen using ASM or something to boost performance)? Well, a big part of SDO is the DataObject (reflective API). Dynamic SDO already provides a full implementation for that, so I suspect that what you're asking for would be to 1) dynamically load the metadata given a Java interface, and then 2) Bind a Java Proxy for the interface to the dynamic impl. It all sounds possible, but isn't currently part of the spec we're implementing. Something like that - have the proxy implement the user's interface and DataObject and delegate invocations to the dynamic SDO implementation. If the performance of dynamic SDO is acceptable the the proxy overhead is easy to fix. That would be helpful. An further step would be to allow for full POJO support where people could provide their own implementations which could be turned into SDOs (through subclassing or some other mechanism with the caveat this would only work for non-final classes). Perhaps there are some corner cases which limit this but it seems like it would be a very useful capability. The spec talks a lot about the generation of Java interfaces but nothing about the associated implementation beyond it having to implement DataObject. It does, however, describe the compatibility for applications used to using JavaBeans. It may help build adoption if we provide ways that make it easy for people coming from that environment to migrate without having to regenerate their code. There are lots of things we should be doing that are not part of the specifications - this value add is what makes the difference between a useful implementation and an RI, or between a successful project and one that fades to obscurity. are there directions some place for using the command line tool? It's described in contrib/java/trunk/docs/ SDO_Java_Project_Overview.doc. I'll check it out,thanks -- Jeremy
