Re: [Propose] A Tuscany Native release with SCA, SDO and DAS
Cool, So I created a new release on JIRA: Cpp-M4( not sure if it's the best name, suggestions? ). We could start to set the JIRAs that are supposed to be fixed before this release to Cpp-M4 and leave the others to Cpp-next. Suggestions? Adriano Crestani On 10/23/07, Simon Nash [EMAIL PROTECTED] wrote: +1 for this. Simon ant elder wrote: That would be really good. I'm can't help so much with coding but i'd be happy to help out in any other way. ...ant On 10/23/07, Adriano Crestani [EMAIL PROTECTED] wrote: Hi, How about a Tuscany Native release with all native projects: SCA, SDO and DAS? The 3 projects have an Apache Ant build system that is a good point for a release containing all of them. SCA next release is being discussed on [1]. DAS is ready for its first release, all necessary operations as CRUD it's already performing. What about SDO, is it ready for a next release? Thoughts? Suggestions? [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg25052.html Adriano Crestani http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg25052.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r587397 - in /incubator/tuscany/java/das/rdb/src: main/java/org/apache/tuscany/das/rdb/ main/java/org/apache/tuscany/das/rdb/config/wrapper/ test/java/org/apache/tuscany/das/rdb/test/
Thank you Raymond, just now did that. I will ensure this for all next
commits.
Regards,
Amita
On 10/24/07, Raymond Feng [EMAIL PROTECTED] wrote:
Hi,
A gentle reminder for your first commit: Adding some text as the commit
log
will help us understand what the changes are about.
Thanks,
Raymond
- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, October 22, 2007 10:42 PM
Subject: svn commit: r587397 - in /incubator/tuscany/java/das/rdb/src:
main/java/org/apache/tuscany/das/rdb/
main/java/org/apache/tuscany/das/rdb/config/wrapper/
test/java/org/apache/tuscany/das/rdb/test/
Author: amita
Date: Mon Oct 22 22:42:42 2007
New Revision: 587397
URL: http://svn.apache.org/viewvc?rev=587397view=rev
Log: (empty)
Modified:
incubator/tuscany/java/das/rdb/src/main/java/org/apache/tuscany/das/rdb/ConfigHelper.java
incubator/tuscany/java/das/rdb/src/main/java/org/apache/tuscany/das/rdb/config/wrapper/MappingWrapper.java
incubator/tuscany/java/das/rdb/src/test/java/org/apache/tuscany/das/rdb/test/ProgrammaticConfigTests.java
Modified:
incubator/tuscany/java/das/rdb/src/main/java/org/apache/tuscany/das/rdb/ConfigHelper.java
URL:
http://svn.apache.org/viewvc/incubator/tuscany/java/das/rdb/src/main/java/org/apache/tuscany/das/rdb/ConfigHelper.java?rev=587397r1=587396r2=587397view=diff
==
---
incubator/tuscany/java/das/rdb/src/main/java/org/apache/tuscany/das/rdb/ConfigHelper.java
(original)
+++
incubator/tuscany/java/das/rdb/src/main/java/org/apache/tuscany/das/rdb/ConfigHelper.java
Mon Oct 22 22:42:42 2007
@@ -97,7 +97,18 @@
* @return
*/
public Relationship addRelationship(String parentName, String
childName) {
-return configWrapper.addRelationship(parentName, childName);
+return addRelationship(parentName, childName, null);
+}
+
+/**
+ * Add relationship information
+ * @param parentName
+ * @param childName
+ * @param relationshipName
+ * @return
+ */
+public Relationship addRelationship(String parentName, String
childName, String relationshipName) {
+return configWrapper.addRelationship(parentName, childName,
relationshipName);
}
/**
@@ -107,9 +118,20 @@
* @return
*/
public Relationship addRelationship(Vector parentNames, Vector
childNames) {
-return configWrapper.addRelationship(parentNames, childNames);
+return addRelationship(parentNames, childNames, null);
}
+/**
+ * Add relationship information
+ * @param parentNames
+ * @param childNames
+ * @param relationshipName
+ * @return
+ */
+public Relationship addRelationship(Vector parentNames, Vector
childNames, String relationshipName) {
+return configWrapper.addRelationship(parentNames, childNames,
relationshipName);
+}
+
/**
* Add table information
* @param name
Modified:
incubator/tuscany/java/das/rdb/src/main/java/org/apache/tuscany/das/rdb/config/wrapper/MappingWrapper.java
URL:
http://svn.apache.org/viewvc/incubator/tuscany/java/das/rdb/src/main/java/org/apache/tuscany/das/rdb/config/wrapper/MappingWrapper.java?rev=587397r1=587396r2=587397view=diff
==
---
incubator/tuscany/java/das/rdb/src/main/java/org/apache/tuscany/das/rdb/config/wrapper/MappingWrapper.java
(original)
+++
incubator/tuscany/java/das/rdb/src/main/java/org/apache/tuscany/das/rdb/config/wrapper/MappingWrapper.java
Mon Oct 22 22:42:42 2007
@@ -162,6 +162,10 @@
}
public Relationship addRelationship(String parentName, String
childName) {
+return addRelationship(parentName, childName, null);
+}
+
+public Relationship addRelationship(String parentName, String
childName, String relationshipName) {
//JIRA-952
QualifiedColumn parent = null;
@@ -179,14 +183,22 @@
Relationship r = FACTORY.createRelationship();
//JIRA-952
if(this.config.isDatabaseSchemaNameSupported()){
-r.setName(child.getSchemaName()+.+child.getTableName());
+if(relationshipName == null)
+r.setName(child.getSchemaName()+.+child.getTableName());
+else
+r.setName(relationshipName);
+
r.setPrimaryKeyTable(parent.getSchemaName()+.+parent.getTableName());
r.setForeignKeyTable(child.getSchemaName()+.+child.getTableName());
}
else{
-r.setName(child.getTableName());
-r.setPrimaryKeyTable(parent.getTableName());
-r.setForeignKeyTable(child.getTableName());
+if(relationshipName == null)
+r.setName(child.getTableName());
+else
+r.setName(relationshipName);
[jira] Created: (TUSCANY-1866) Create documentantion for Native DAS on Tuscany web site
Create documentantion for Native DAS on Tuscany web site Key: TUSCANY-1866 URL: https://issues.apache.org/jira/browse/TUSCANY-1866 Project: Tuscany Issue Type: Task Components: C++ DAS Reporter: Adriano Crestani Assignee: Adriano Crestani Fix For: Cpp-M4 Documentation is necessary to attract more users and vonlunteers to Tuscany, so before the first release containing DAS C++, it's necessary to add at least an architecture, user, and getting started guide to DAS C++ section on Tuscany web site. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [SCA Native] next release content [was: Tuscany roadmap]
My comment was based on what Sam Ruby told us last time we went round this loop. Unfortunately my trawl through mail archives can't find anything. I'm no legal expert. I believe using cxxtest would be OK but we need to check before using it. Cheers, On 23/10/2007, Adriano Crestani [EMAIL PROTECTED] wrote: Oh, sorry Simon, my mistake, it was really Pete who said it ; ) Adriano Crestani On 10/23/07, Simon Nash [EMAIL PROTECTED] wrote: Adriano Crestani wrote: Hi Haleh, This way we would be using the Cxxtest api, and according to Simon it's considered derived work, so we couldn't distribute it, right Simon? This comment came from Pete, not from me. I'm not familiar with the stdcxx license so I'll defer to Pete to explain why it's a concern. Simon Adriano Crestani On 10/23/07, haleh mahbod [EMAIL PROTECTED] wrote: But if you go with what Simon suggested, you leave the tests and test tool outside of distribution. Wouldn't that work? On 10/23/07, Adriano Crestani [EMAIL PROTECTED] wrote: I think this is one for the legal discuss list. This has been discussed before and I think the conclusion was that because you code to the cxxtest apis to write your test code it could be considered a derivative work. So, does it mean we cannot distribute a code using a api that we cannot distribute? Then we should start looking for another unit test. I was looking on the web site I commented before, most of them are GPL : (, but I found this 2: http://unittest-cpp.sourceforge.net/ http://tut-framework.sourceforge.net/ Their license seems to have almost no restriction, but I cannot tell for sure if they are compatible with ASF license. Regards, Adriano Crestani On 10/23/07, Pete Robbins [EMAIL PROTECTED] wrote: I think this is one for the legal discuss list. This has been discussed before and I think the conclusion was that because you code to the cxxtest apis to write your test code it could be considered a derivative work. Cheers, On 23/10/2007, Simon Nash [EMAIL PROTECTED] wrote: I think it's fine to distribute unit test source and tell people what tool they need to build and run the tests. And I agree that having a list of suitable unit test tools on the Web site is helpful. Simon Adriano Crestani wrote: Hi Simon, Yes, you are right, I forgot this option, there is no problem to distribute the unit test source code :P. But anyway, the list contained on the web site I could be helpful :) Regards, Adriano Crestani On 10/22/07, Simon Nash [EMAIL PROTECTED] wrote: Why does the test tool need to be distributed with a Tuscany release? If the build depends on having the tool available, then I can see some justification for this, but even then it would be possible for people who build the source to download the tool separately. Simon Adriano Crestani wrote: Hi, Brady suggested to use CxxTest only on development process and don't distribute it with the released source. However, whoever wants to modify the code from a release would want to test it, to check if the modifications does not compromise the software. So, I suggest to look for another text unit tool that could be distributed with the released source. I really dont know any other, but searching on web I found a list of open source C/C++ unit test tools on [1]. [1] http://www.opensourcetesting.org/unit_c.php Regards, Adriano Crestani On 8/10/07, Brady Johnson [EMAIL PROTECTED] wrote: Good idea, I always prefer to see plenty of documentation. I updated the wiki with a documentation feature. http://cwiki.apache.org/confluence/display/TUSCANYWIKI/SCA+Native+Next+R elease+Contents What sort of help do you think I'll have with these features? Brady Johnson Lead Software Developer - HydraSCA Rogue Wave Software - [EMAIL PROTECTED] -Original Message- From: haleh mahbod [mailto:[EMAIL PROTECTED] Sent: Friday, August 10, 2007 3:36 PM To: tuscany-dev@ws.apache.org Subject: Re: [SCA Native] next release content [was: Tuscany roadmap] How about enhancing the documentation (architecture, get started and user doc) to help new people come on board faster? Another thought might be to have an integration story between Native and Java. Some of this work started for OSCon, for example a sample of a composite which include C++ and Java components. On 7/26/07, Pete Robbins [EMAIL PROTECTED] wrote: That looks good. I think there is more than enough in that list to justify a release. My priorities would be: 1)
[NOTICE] Michael Yoder voted as Tuscany committer
The Tuscany PPMC and Incubator PMC have voted for Michael to become a Tuscany committer. Congratulations and welcome! I look forward to your continued excellent contributions to Tuscany. Cheers, -- Pete - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Adding dynamically references
2007/10/23, Simon Nash [EMAIL PROTECTED]: There is something in the assembly spec for this (WiredByImpl) but it didn't make it into the Java language binding. Do you need to dynamically rewire a reference that was previously statically wired in the SCDL, or would you be OK with being able to wire (and rewire) a reference that was described as WiredByImpl in the SCDL? Ok. I have a component with a reference to another one, i need to add a new reference to another component. So I need to do by myself.. I give you an example: Suppose just only jfor a moment, that I create a component manager service for a node (i know it already exists). I wanna ask to this component manager: take components x in a node, load a component y and wire x to y. In this way i can load dynamically worker components and binding to my workpool in order to balance load between nodes. So i think that's the second one (WiredByImpl). Cheers, Giorgio. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [NOTICE] Michael Yoder voted as Tuscany committer
Welcome Michael, thanks for helping! ...ant On 10/24/07, Pete Robbins [EMAIL PROTECTED] wrote: The Tuscany PPMC and Incubator PMC have voted for Michael to become a Tuscany committer. Congratulations and welcome! I look forward to your continued excellent contributions to Tuscany. Cheers, -- Pete - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSONRPC Enhancements
On 10/22/07, Luciano Resende [EMAIL PROTECTED] wrote: The upgrade process is very harmless, two line of code, one for the js reference and another for the reference declaration. Also, seems like there are some bugs on the scaDomain.js [1] that would not happen while using the manual reference. I also think that, having the two very similar bindings will make confusion and other maintenance headaches. Have said that, and as I'm working towards getting the web2.0 References working soon, I'd like to keep this as one binding, but I'm open if the community feels otherwise. Doesn't look like Mr Community is answering...Trying to maintain backward compatibility where possible is important. It doesn't matter that its a harmless two line change, if some guy upgrades from Tuscany 1.0 to 1.1 and his applications don't work any more then that is a bad user experience which we should try hard to avoid. Is there a reason the scaDoamin.js can't work anymore? If there is a reason then a separate new binding seems better to me just so we can avoid breaking anyone. ...ant
Re: [NOTICE] Michael Yoder voted as Tuscany committer
Congratulations and Welcome Michael! - Venkat On 10/24/07, Pete Robbins [EMAIL PROTECTED] wrote: The Tuscany PPMC and Incubator PMC have voted for Michael to become a Tuscany committer. Congratulations and welcome! I look forward to your continued excellent contributions to Tuscany. Cheers, -- Pete - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DAS] incomplete implementation of Relationships and so errors
Thanks Adriano, as you have mentioned, there is a mapping available for
Table-Type and Column-Property in
Table element in DAS Config. So there is no need to duplicate it in
Relationship and KeyPair and it
can be referenced from Table when available. The logic used to fix the
issue, such that, in case a Table entry is
found in Config, it is used for the above mapping, else default behavior
(typeName=tableName and propName=colName)
is assumed.
Based on this, I have modified:-
1) MappingWrapper.getRelationshipsByChildTable(name - SDO prop name) and
2) DatabaseObject.initialize() and get(parameter - SDO prop name)
Also, added 2 test cases to
RelationshipTests - testRelationshipTypesAndProperties() and
testRelationshipWithProgrammaticConfig()
The relevant JIRA is TUSCANY-1865.
Regards,
Amita
On 10/23/07, Adriano Crestani [EMAIL PROTECTED] wrote:
Hi Amita,
On DAS C++ when a relationship is found, for example, between table A and
table B, it looks for their Table object in the Config, then, it it's
defined on the Config their type name can be retrieved using
tableA.getTypeName(). The same happens for the Column. It only assumes the
type name to be the table name if it's not defined on the Config.
If you are saying that the methods below are always assuming the type name
being the table name, so I think they should be corrected.
MappingWrapper-
getRelationshipByReference()
getRelationshipsByChildTable()
DatabaseObject-
initialize()
Regards,
Adriano Crestani
On 10/23/07, Amita Vadhavkar [EMAIL PROTECTED] wrote:
In RDB DAS, the config model has relationship definition as below:-
xsd:complexType name=Relationship
xsd:sequence
xsd:element maxOccurs=unbounded minOccurs=0
name=KeyPair
type=config:KeyPair/
/xsd:sequence
xsd:attribute name=name type=xsd:string/
xsd:attribute name=primaryKeyTable type=xsd:string/
xsd:attribute name=foreignKeyTable type=xsd:string/
xsd:attribute name=many type=xsd:boolean/
xsd:attribute name=keyRestricted type=xsd:boolean/
/xsd:complexType
xsd:complexType name=KeyPair
xsd:attribute name=primaryKeyColumn type=xsd:string/
xsd:attribute name=foreignKeyColumn type=xsd:string/
/xsd:complexType
So, it does not have a place to store Table-Type and Column-Property
mapping.
Also some methods below show that,they are always assuming TableName
same
as
TypeName and ColumnName same as PropertyName.
e.g.
MappingWrapper-
getRelationshipByReference()
getRelationshipsByChildTable()
DatabaseObject-
initialize()
Thus, in case the das config xml has defined different table/type and
column/property names and the tables have relationship,
the CUD operations based on relationship is not succeeding.
e.g. When a das config has -
_
Table tableName=CUSTOMER typeName=Customer
Column columnName=ID propertyName=ID primaryKey=true/
Column columnName=LASTNAME propertyName=lastName/
Column columnName=ADDRESS propertyName=address/
/Table
Table tableName=ANORDER typeName=AnOrder
Column columnName=ID propertyName=OrderId
primaryKey=true/
/Table
Relationship name=orders primaryKeyTable=CUSTOMER
foreignKeyTable=ANORDER many=true
KeyPair primaryKeyColumn=ID foreignKeyColumn=CUSTOMER_ID/
/Relationship
_
The below test case results in AnOrder record in DB with CUSTOMER_ID
null,
as the relationship is not properly picked.
_
public void testRelationshipTypesAndProperties1() throws Exception {
//existing records
DAS das = DAS.FACTORY.createDAS(getConfig(
CustomersOrdersConfigProps.xml), getConnection());
Command cmd = das.getCommand(customer and orders);
cmd.setParameter(ID, new Integer(1));
DataObject root = cmd.executeQuery();
DataObject firstCustomer = root.getDataObject(Customer[ID=1]);
System.out.println(XMLHelper.INSTANCE.save(firstCustomer,
beforeInsertInDG, beforeInsertInDG));
DataObject newOrder = root.createDataObject(AnOrder);
newOrder.setInt(OrderId, 100);
newOrder.setString(PRODUCT, MyProd);
firstCustomer.getList(orders).add(newOrder);
System.out.println(XMLHelper.INSTANCE.save(firstCustomer,
afterInsertInDG, afterInsertInDG));
das.applyChanges(root);
root = cmd.executeQuery();
firstCustomer = root.getDataObject(Customer[ID=1]);
System.out.println(XMLHelper.INSTANCE.save(firstCustomer,
fromDB,
fromDB));
}
[jira] Updated: (TUSCANY-1865) relationships in DAS need to consider table-property and column-type mapping
[ https://issues.apache.org/jira/browse/TUSCANY-1865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amita Vadhavkar updated TUSCANY-1865: - Attachment: 1865.patch changed files:- MappingWrapper, DatabaseObject, RelationshipTests and added CustomersOrdersRelationship.xml relationships in DAS need to consider table-property and column-type mapping Key: TUSCANY-1865 URL: https://issues.apache.org/jira/browse/TUSCANY-1865 Project: Tuscany Issue Type: Bug Components: Java DAS RDB Affects Versions: Java-DAS-Next Reporter: Amita Vadhavkar Assignee: Amita Vadhavkar Fix For: Java-DAS-Next Attachments: 1865.patch http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg25092.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [NOTICE] Michael Yoder voted as Tuscany committer
Congratulations and Welcome Michael! -Amita On 10/24/07, Pete Robbins [EMAIL PROTECTED] wrote: The Tuscany PPMC and Incubator PMC have voted for Michael to become a Tuscany committer. Congratulations and welcome! I look forward to your continued excellent contributions to Tuscany. Cheers, -- Pete - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[DAS] Extend static model support beyond read - for CUD with relationships
Old thread - http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg24861.html If static model is used in RDB DAS for all the inputs it is providing, RDB DAS will be able to form relationship information using it. So, RDB DAS Config file can be completely replaced using - 1) static model 2) dynamic command formation - das.createCommand() 3) if same Type/PropertyNames-table/columnNames (i.e. no mapping required in these) Without this feature, RDB DAS supports static model only as input at present for - 1) single table CRUD 2) multi table - Read only 3) mutli table CRUD only with a supporting DAS Config file Suggestions? Usability? Regards, Amita
Re: Shopping Store Tutorial, work in progress
Jean-Sebastien Delfino wrote: Antollini, Mario wrote: Jean-Sebastien, Raymond, Thanks for the feedback. I modified the figure accordingly. What do you both think now? Regards, Mario Thanks Mario. I guess we should work on the various parts of the application: - the catalog component with a hardcoded list of items - the catalog component backed by a database - the catalog component talking to the Amazon catalog - the catalog component talking to the eBay catalog We need to define a single business interface that they'll all implement. Also I'd like to add a currency converter component that can run on a different Tuscany node I started to work on the build structure and a build.xml file with the right dependencies. BTW I'm going to temporarily move the tutorial directory from java/sca/demos/tutorial to java/sca/tutorial to make it easier to reuse existing samples and their build.xml files on top of the Tuscany distribution. We can move the directory again later if people want. I'm making some progress on the new Shopping Store tutorial. I have organized the modules under java/sca/tutorial as follows: * store - the simple getting started store sample as we had it before in samples/store * store-domain - a mini launcher for the domain controller that can be used to manage Tuscany nodes Then the various parts of the tutorial also in separate modules to allow them to run on different Tuscany nodes * store-ui - the UI component, with references to the catalog and shoppingcart * store-catalog - the catalog component alone * store-catalog-database - an implementation of the catalog backed by a database * store-catalog-amazon - currently empty, will represent the amazon catalog * store-catalog-ebay - currently empty, will represent the ebay catalog * store-cart - the shopping cart component * store-currency - the currency converter component I'm thinking that this kind of structure will allow us to exercise interesting scenarios: 1. How to get started and build a simple store (similar to the getting started sample). 2. Wire your catalog with other external catalogs running on different nodes (because you're expanding your store business or merge it with other businesses). 3. Provide your new aggregated catalog service as a Web Service for example. 3. Another instantiation of the store reusing the same components but configured and wired differently (maybe a different currency and a currency conversion service running on a different node), maybe with a slightly different UI too. I'm mostly working on the store-ui, store-catalog, store-domain modules at the moment. I won't touch much the store-cart, store-catalog-database, store-amazon and store-ebay for the next few days, as I believe others are working on them. I'll probably have to make a few fixes to the runtime as I go. I've already run into a few issues with the WS, Atom and Jsonrpc bindings and the Domain+Node code. Hopefully this won't disturb the 1.0.1 release as I believe that most of the changes from trunk have already been merged into the release branch. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [SCA Native] next release content [was: Tuscany roadmap]
So who do we have to check with? Brady -Original Message- From: Pete Robbins [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 24, 2007 12:54 AM To: tuscany-dev@ws.apache.org Subject: Re: [SCA Native] next release content [was: Tuscany roadmap] My comment was based on what Sam Ruby told us last time we went round this loop. Unfortunately my trawl through mail archives can't find anything. I'm no legal expert. I believe using cxxtest would be OK but we need to check before using it. Cheers, On 23/10/2007, Adriano Crestani [EMAIL PROTECTED] wrote: Oh, sorry Simon, my mistake, it was really Pete who said it ; ) Adriano Crestani On 10/23/07, Simon Nash [EMAIL PROTECTED] wrote: Adriano Crestani wrote: Hi Haleh, This way we would be using the Cxxtest api, and according to Simon it's considered derived work, so we couldn't distribute it, right Simon? This comment came from Pete, not from me. I'm not familiar with the stdcxx license so I'll defer to Pete to explain why it's a concern. Simon Adriano Crestani On 10/23/07, haleh mahbod [EMAIL PROTECTED] wrote: But if you go with what Simon suggested, you leave the tests and test tool outside of distribution. Wouldn't that work? On 10/23/07, Adriano Crestani [EMAIL PROTECTED] wrote: I think this is one for the legal discuss list. This has been discussed before and I think the conclusion was that because you code to the cxxtest apis to write your test code it could be considered a derivative work. So, does it mean we cannot distribute a code using a api that we cannot distribute? Then we should start looking for another unit test. I was looking on the web site I commented before, most of them are GPL : (, but I found this 2: http://unittest-cpp.sourceforge.net/ http://tut-framework.sourceforge.net/ Their license seems to have almost no restriction, but I cannot tell for sure if they are compatible with ASF license. Regards, Adriano Crestani On 10/23/07, Pete Robbins [EMAIL PROTECTED] wrote: I think this is one for the legal discuss list. This has been discussed before and I think the conclusion was that because you code to the cxxtest apis to write your test code it could be considered a derivative work. Cheers, On 23/10/2007, Simon Nash [EMAIL PROTECTED] wrote: I think it's fine to distribute unit test source and tell people what tool they need to build and run the tests. And I agree that having a list of suitable unit test tools on the Web site is helpful. Simon Adriano Crestani wrote: Hi Simon, Yes, you are right, I forgot this option, there is no problem to distribute the unit test source code :P. But anyway, the list contained on the web site I could be helpful :) Regards, Adriano Crestani On 10/22/07, Simon Nash [EMAIL PROTECTED] wrote: Why does the test tool need to be distributed with a Tuscany release? If the build depends on having the tool available, then I can see some justification for this, but even then it would be possible for people who build the source to download the tool separately. Simon Adriano Crestani wrote: Hi, Brady suggested to use CxxTest only on development process and don't distribute it with the released source. However, whoever wants to modify the code from a release would want to test it, to check if the modifications does not compromise the software. So, I suggest to look for another text unit tool that could be distributed with the released source. I really dont know any other, but searching on web I found a list of open source C/C++ unit test tools on [1]. [1] http://www.opensourcetesting.org/unit_c.php Regards, Adriano Crestani On 8/10/07, Brady Johnson [EMAIL PROTECTED] wrote: Good idea, I always prefer to see plenty of documentation. I updated the wiki with a documentation feature. http://cwiki.apache.org/confluence/display/TUSCANYWIKI/SCA+Native+ Next+R elease+Contents What sort of help do you think I'll have with these features? Brady Johnson Lead Software Developer - HydraSCA Rogue Wave Software - [EMAIL PROTECTED] -Original Message- From: haleh mahbod [mailto:[EMAIL PROTECTED] Sent: Friday, August 10, 2007 3:36 PM To: tuscany-dev@ws.apache.org Subject: Re: [SCA Native] next release content [was: Tuscany roadmap] How about enhancing the documentation (architecture, get started and user doc) to help new people come on board faster? Another thought might be to have an integration story between Native and Java.
Re: [SCA Native] next release content [was: Tuscany roadmap]
CxxTest (http://cxxtest.sourceforge.net/) is LGPL which is an excluded license (http://www.apache.org/legal/3party.html) so it cant be used. Doesn't matter that its only tests so CxxTest wont be distributed in a distro, we can't use anything LGPL. ...ant On 10/24/07, Brady Johnson [EMAIL PROTECTED] wrote: So who do we have to check with? Brady -Original Message- From: Pete Robbins [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 24, 2007 12:54 AM To: tuscany-dev@ws.apache.org Subject: Re: [SCA Native] next release content [was: Tuscany roadmap] My comment was based on what Sam Ruby told us last time we went round this loop. Unfortunately my trawl through mail archives can't find anything. I'm no legal expert. I believe using cxxtest would be OK but we need to check before using it. Cheers, On 23/10/2007, Adriano Crestani [EMAIL PROTECTED] wrote: Oh, sorry Simon, my mistake, it was really Pete who said it ; ) Adriano Crestani On 10/23/07, Simon Nash [EMAIL PROTECTED] wrote: Adriano Crestani wrote: Hi Haleh, This way we would be using the Cxxtest api, and according to Simon it's considered derived work, so we couldn't distribute it, right Simon? This comment came from Pete, not from me. I'm not familiar with the stdcxx license so I'll defer to Pete to explain why it's a concern. Simon Adriano Crestani On 10/23/07, haleh mahbod [EMAIL PROTECTED] wrote: But if you go with what Simon suggested, you leave the tests and test tool outside of distribution. Wouldn't that work? On 10/23/07, Adriano Crestani [EMAIL PROTECTED] wrote: I think this is one for the legal discuss list. This has been discussed before and I think the conclusion was that because you code to the cxxtest apis to write your test code it could be considered a derivative work. So, does it mean we cannot distribute a code using a api that we cannot distribute? Then we should start looking for another unit test. I was looking on the web site I commented before, most of them are GPL : (, but I found this 2: http://unittest-cpp.sourceforge.net/ http://tut-framework.sourceforge.net/ Their license seems to have almost no restriction, but I cannot tell for sure if they are compatible with ASF license. Regards, Adriano Crestani On 10/23/07, Pete Robbins [EMAIL PROTECTED] wrote: I think this is one for the legal discuss list. This has been discussed before and I think the conclusion was that because you code to the cxxtest apis to write your test code it could be considered a derivative work. Cheers, On 23/10/2007, Simon Nash [EMAIL PROTECTED] wrote: I think it's fine to distribute unit test source and tell people what tool they need to build and run the tests. And I agree that having a list of suitable unit test tools on the Web site is helpful. Simon Adriano Crestani wrote: Hi Simon, Yes, you are right, I forgot this option, there is no problem to distribute the unit test source code :P. But anyway, the list contained on the web site I could be helpful :) Regards, Adriano Crestani On 10/22/07, Simon Nash [EMAIL PROTECTED] wrote: Why does the test tool need to be distributed with a Tuscany release? If the build depends on having the tool available, then I can see some justification for this, but even then it would be possible for people who build the source to download the tool separately. Simon Adriano Crestani wrote: Hi, Brady suggested to use CxxTest only on development process and don't distribute it with the released source. However, whoever wants to modify the code from a release would want to test it, to check if the modifications does not compromise the software. So, I suggest to look for another text unit tool that could be distributed with the released source. I really dont know any other, but searching on web I found a list of open source C/C++ unit test tools on [1]. [1] http://www.opensourcetesting.org/unit_c.php Regards, Adriano Crestani On 8/10/07, Brady Johnson [EMAIL PROTECTED] wrote: Good idea, I always prefer to see plenty of documentation. I updated the wiki with a documentation feature. http://cwiki.apache.org/confluence/display/TUSCANYWIKI/SCA+Native+ Next+R elease+Contents What sort of help do you think I'll have with these features? Brady Johnson Lead Software Developer - HydraSCA Rogue Wave
Re: [DAS] incomplete implementation of Relationships and so errors
Great ; )
Adriano Crestani
On 10/24/07, Amita Vadhavkar [EMAIL PROTECTED] wrote:
Thanks Adriano, as you have mentioned, there is a mapping available for
Table-Type and Column-Property in
Table element in DAS Config. So there is no need to duplicate it in
Relationship and KeyPair and it
can be referenced from Table when available. The logic used to fix the
issue, such that, in case a Table entry is
found in Config, it is used for the above mapping, else default behavior
(typeName=tableName and propName=colName)
is assumed.
Based on this, I have modified:-
1) MappingWrapper.getRelationshipsByChildTable(name - SDO prop name) and
2) DatabaseObject.initialize() and get(parameter - SDO prop name)
Also, added 2 test cases to
RelationshipTests - testRelationshipTypesAndProperties() and
testRelationshipWithProgrammaticConfig()
The relevant JIRA is TUSCANY-1865.
Regards,
Amita
On 10/23/07, Adriano Crestani [EMAIL PROTECTED] wrote:
Hi Amita,
On DAS C++ when a relationship is found, for example, between table
A and
table B, it looks for their Table object in the Config, then, it it's
defined on the Config their type name can be retrieved using
tableA.getTypeName(). The same happens for the Column. It only assumes
the
type name to be the table name if it's not defined on the Config.
If you are saying that the methods below are always assuming the type
name
being the table name, so I think they should be corrected.
MappingWrapper-
getRelationshipByReference()
getRelationshipsByChildTable()
DatabaseObject-
initialize()
Regards,
Adriano Crestani
On 10/23/07, Amita Vadhavkar [EMAIL PROTECTED] wrote:
In RDB DAS, the config model has relationship definition as below:-
xsd:complexType name=Relationship
xsd:sequence
xsd:element maxOccurs=unbounded minOccurs=0
name=KeyPair
type=config:KeyPair/
/xsd:sequence
xsd:attribute name=name type=xsd:string/
xsd:attribute name=primaryKeyTable type=xsd:string/
xsd:attribute name=foreignKeyTable type=xsd:string/
xsd:attribute name=many type=xsd:boolean/
xsd:attribute name=keyRestricted type=xsd:boolean/
/xsd:complexType
xsd:complexType name=KeyPair
xsd:attribute name=primaryKeyColumn type=xsd:string/
xsd:attribute name=foreignKeyColumn type=xsd:string/
/xsd:complexType
So, it does not have a place to store Table-Type and
Column-Property
mapping.
Also some methods below show that,they are always assuming TableName
same
as
TypeName and ColumnName same as PropertyName.
e.g.
MappingWrapper-
getRelationshipByReference()
getRelationshipsByChildTable()
DatabaseObject-
initialize()
Thus, in case the das config xml has defined different table/type and
column/property names and the tables have relationship,
the CUD operations based on relationship is not succeeding.
e.g. When a das config has -
_
Table tableName=CUSTOMER typeName=Customer
Column columnName=ID propertyName=ID primaryKey=true/
Column columnName=LASTNAME propertyName=lastName/
Column columnName=ADDRESS propertyName=address/
/Table
Table tableName=ANORDER typeName=AnOrder
Column columnName=ID propertyName=OrderId
primaryKey=true/
/Table
Relationship name=orders primaryKeyTable=CUSTOMER
foreignKeyTable=ANORDER many=true
KeyPair primaryKeyColumn=ID
foreignKeyColumn=CUSTOMER_ID/
/Relationship
_
The below test case results in AnOrder record in DB with CUSTOMER_ID
null,
as the relationship is not properly picked.
_
public void testRelationshipTypesAndProperties1() throws Exception
{
//existing records
DAS das = DAS.FACTORY.createDAS(getConfig(
CustomersOrdersConfigProps.xml), getConnection());
Command cmd = das.getCommand(customer and orders);
cmd.setParameter(ID, new Integer(1));
DataObject root = cmd.executeQuery();
DataObject firstCustomer = root.getDataObject
(Customer[ID=1]);
System.out.println(XMLHelper.INSTANCE.save(firstCustomer,
beforeInsertInDG, beforeInsertInDG));
DataObject newOrder = root.createDataObject(AnOrder);
newOrder.setInt(OrderId, 100);
newOrder.setString(PRODUCT, MyProd);
firstCustomer.getList(orders).add(newOrder);
System.out.println(XMLHelper.INSTANCE.save(firstCustomer,
afterInsertInDG, afterInsertInDG));
das.applyChanges(root);
root = cmd.executeQuery();
Re: [SCA Native] next release content [was: Tuscany roadmap]
Thanks ant, As ant confirmed, we cannot use CxxText even on unit test source code, then we should definitely look for another tool or leave it the way it is. SCA unit tests - I never tested SDO unit tests(sdo_test project) - It needs some maintenance and does not use any unit test tool DAS unit tests(das_test project) - working fine and does not use any unit test tool Regards, Adriano Crestani On 10/24/07, ant elder [EMAIL PROTECTED] wrote: CxxTest (http://cxxtest.sourceforge.net/) is LGPL which is an excluded license (http://www.apache.org/legal/3party.html) so it cant be used. Doesn't matter that its only tests so CxxTest wont be distributed in a distro, we can't use anything LGPL. ...ant On 10/24/07, Brady Johnson [EMAIL PROTECTED] wrote: So who do we have to check with? Brady -Original Message- From: Pete Robbins [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 24, 2007 12:54 AM To: tuscany-dev@ws.apache.org Subject: Re: [SCA Native] next release content [was: Tuscany roadmap] My comment was based on what Sam Ruby told us last time we went round this loop. Unfortunately my trawl through mail archives can't find anything. I'm no legal expert. I believe using cxxtest would be OK but we need to check before using it. Cheers, On 23/10/2007, Adriano Crestani [EMAIL PROTECTED] wrote: Oh, sorry Simon, my mistake, it was really Pete who said it ; ) Adriano Crestani On 10/23/07, Simon Nash [EMAIL PROTECTED] wrote: Adriano Crestani wrote: Hi Haleh, This way we would be using the Cxxtest api, and according to Simon it's considered derived work, so we couldn't distribute it, right Simon? This comment came from Pete, not from me. I'm not familiar with the stdcxx license so I'll defer to Pete to explain why it's a concern. Simon Adriano Crestani On 10/23/07, haleh mahbod [EMAIL PROTECTED] wrote: But if you go with what Simon suggested, you leave the tests and test tool outside of distribution. Wouldn't that work? On 10/23/07, Adriano Crestani [EMAIL PROTECTED] wrote: I think this is one for the legal discuss list. This has been discussed before and I think the conclusion was that because you code to the cxxtest apis to write your test code it could be considered a derivative work. So, does it mean we cannot distribute a code using a api that we cannot distribute? Then we should start looking for another unit test. I was looking on the web site I commented before, most of them are GPL : (, but I found this 2: http://unittest-cpp.sourceforge.net/ http://tut-framework.sourceforge.net/ Their license seems to have almost no restriction, but I cannot tell for sure if they are compatible with ASF license. Regards, Adriano Crestani On 10/23/07, Pete Robbins [EMAIL PROTECTED] wrote: I think this is one for the legal discuss list. This has been discussed before and I think the conclusion was that because you code to the cxxtest apis to write your test code it could be considered a derivative work. Cheers, On 23/10/2007, Simon Nash [EMAIL PROTECTED] wrote: I think it's fine to distribute unit test source and tell people what tool they need to build and run the tests. And I agree that having a list of suitable unit test tools on the Web site is helpful. Simon Adriano Crestani wrote: Hi Simon, Yes, you are right, I forgot this option, there is no problem to distribute the unit test source code :P. But anyway, the list contained on the web site I could be helpful :) Regards, Adriano Crestani On 10/22/07, Simon Nash [EMAIL PROTECTED] wrote: Why does the test tool need to be distributed with a Tuscany release? If the build depends on having the tool available, then I can see some justification for this, but even then it would be possible for people who build the source to download the tool separately. Simon Adriano Crestani wrote: Hi, Brady suggested to use CxxTest only on development process and don't distribute it with the released source. However, whoever wants to modify the code from a release would want to test it, to check if the modifications does not compromise the software. So, I suggest to look for another text unit tool that could be distributed with the released source. I really dont know any other, but searching on web I found a list
RE: [NOTICE] Michael Yoder voted as Tuscany committer
Thanks All! -Original Message- From: Amita Vadhavkar [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 24, 2007 4:50 AM To: tuscany-dev@ws.apache.org Subject: Re: [NOTICE] Michael Yoder voted as Tuscany committer Congratulations and Welcome Michael! -Amita On 10/24/07, Pete Robbins [EMAIL PROTECTED] wrote: The Tuscany PPMC and Incubator PMC have voted for Michael to become a Tuscany committer. Congratulations and welcome! I look forward to your continued excellent contributions to Tuscany. Cheers, -- Pete - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Propose] A Tuscany Native release with SCA, SDO and DAS
Adriano, I think CPP-M4 is just fine. I started a Next Release Contents WIKI page [1] sometime back for this exact purpose. Maybe we could Add the SDO and DAS items here. The items listed for SCA are rather extensive and should possibly be reduced unless we can get some additional help. [1] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/SCA+Native+Next+R elease+Contents Brady Johnson Lead Software Developer - HydraSCA Rogue Wave Software - [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adriano Crestani Sent: Wednesday, October 24, 2007 12:19 AM To: tuscany-dev@ws.apache.org Subject: Re: [Propose] A Tuscany Native release with SCA, SDO and DAS Cool, So I created a new release on JIRA: Cpp-M4( not sure if it's the best name, suggestions? ). We could start to set the JIRAs that are supposed to be fixed before this release to Cpp-M4 and leave the others to Cpp-next. Suggestions? Adriano Crestani On 10/23/07, Simon Nash [EMAIL PROTECTED] wrote: +1 for this. Simon ant elder wrote: That would be really good. I'm can't help so much with coding but i'd be happy to help out in any other way. ...ant On 10/23/07, Adriano Crestani [EMAIL PROTECTED] wrote: Hi, How about a Tuscany Native release with all native projects: SCA, SDO and DAS? The 3 projects have an Apache Ant build system that is a good point for a release containing all of them. SCA next release is being discussed on [1]. DAS is ready for its first release, all necessary operations as CRUD it's already performing. What about SDO, is it ready for a next release? Thoughts? Suggestions? [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg25052.html Adriano Crestani http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg25052.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [SCA Native] next release content [was: Tuscany roadmap]
Well then, if we cant use CxxTest, and if DAS/SDO Native already have a unit testing infrastructure in place, then I vote we just use/copy that infrastructure for SCA Native. Brady Johnson Lead Software Developer - HydraSCA Rogue Wave Software - [EMAIL PROTECTED] PS: SCA Native used to have a unit test suite, but it was WAY out of date and didn't even compile, so I asked for it to be removed. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adriano Crestani Sent: Wednesday, October 24, 2007 10:46 AM To: tuscany-dev@ws.apache.org; [EMAIL PROTECTED] Subject: Re: [SCA Native] next release content [was: Tuscany roadmap] Thanks ant, As ant confirmed, we cannot use CxxText even on unit test source code, then we should definitely look for another tool or leave it the way it is. SCA unit tests - I never tested SDO unit tests(sdo_test project) - It needs some maintenance and does not use any unit test tool DAS unit tests(das_test project) - working fine and does not use any unit test tool Regards, Adriano Crestani On 10/24/07, ant elder [EMAIL PROTECTED] wrote: CxxTest (http://cxxtest.sourceforge.net/) is LGPL which is an excluded license (http://www.apache.org/legal/3party.html) so it cant be used. Doesn't matter that its only tests so CxxTest wont be distributed in a distro, we can't use anything LGPL. ...ant On 10/24/07, Brady Johnson [EMAIL PROTECTED] wrote: So who do we have to check with? Brady -Original Message- From: Pete Robbins [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 24, 2007 12:54 AM To: tuscany-dev@ws.apache.org Subject: Re: [SCA Native] next release content [was: Tuscany roadmap] My comment was based on what Sam Ruby told us last time we went round this loop. Unfortunately my trawl through mail archives can't find anything. I'm no legal expert. I believe using cxxtest would be OK but we need to check before using it. Cheers, On 23/10/2007, Adriano Crestani [EMAIL PROTECTED] wrote: Oh, sorry Simon, my mistake, it was really Pete who said it ; ) Adriano Crestani On 10/23/07, Simon Nash [EMAIL PROTECTED] wrote: Adriano Crestani wrote: Hi Haleh, This way we would be using the Cxxtest api, and according to Simon it's considered derived work, so we couldn't distribute it, right Simon? This comment came from Pete, not from me. I'm not familiar with the stdcxx license so I'll defer to Pete to explain why it's a concern. Simon Adriano Crestani On 10/23/07, haleh mahbod [EMAIL PROTECTED] wrote: But if you go with what Simon suggested, you leave the tests and test tool outside of distribution. Wouldn't that work? On 10/23/07, Adriano Crestani [EMAIL PROTECTED] wrote: I think this is one for the legal discuss list. This has been discussed before and I think the conclusion was that because you code to the cxxtest apis to write your test code it could be considered a derivative work. So, does it mean we cannot distribute a code using a api that we cannot distribute? Then we should start looking for another unit test. I was looking on the web site I commented before, most of them are GPL : (, but I found this 2: http://unittest-cpp.sourceforge.net/ http://tut-framework.sourceforge.net/ Their license seems to have almost no restriction, but I cannot tell for sure if they are compatible with ASF license. Regards, Adriano Crestani On 10/23/07, Pete Robbins [EMAIL PROTECTED] wrote: I think this is one for the legal discuss list. This has been discussed before and I think the conclusion was that because you code to the cxxtest apis to write your test code it could be considered a derivative work. Cheers, On 23/10/2007, Simon Nash [EMAIL PROTECTED] wrote: I think it's fine to distribute unit test source and tell people what tool they need to build and run the tests. And I agree that having a list of suitable unit test tools on the Web site is helpful. Simon Adriano Crestani wrote: Hi Simon, Yes, you are right, I forgot this option, there is no problem to distribute the unit test source code :P. But anyway, the list contained on the web site I could be helpful :) Regards, Adriano Crestani On 10/22/07, Simon Nash [EMAIL PROTECTED] wrote: Why does the test tool need to be distributed with a Tuscany release? If the build depends on having the tool available, then I can see some justification for this, but even then it
[jira] Created: (TUSCANY-1867) @OneWay with String return type causes NullPointerException
@OneWay with String return type causes NullPointerException --- Key: TUSCANY-1867 URL: https://issues.apache.org/jira/browse/TUSCANY-1867 Project: Tuscany Issue Type: Bug Components: Java SCA Axis Binding Extension Affects Versions: Java-SCA-1.0 Environment: Windows XP Reporter: Simon Nash Fix For: Java-SCA-Next I tried using @OneWay on a method with a String return type and I got a NullPointerException, like this: Exception in thread Axis2 Task java.lang.NullPointerException at org.apache.axis2.description.OutInAxisOperationClient$NonBlockingInvocationWorker.run(OutInAxisOperation.java:444) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690) at java.lang.Thread.run(Thread.java:595) We should produce a better exception to tell the user what he/she has done wrong. -- 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: [NOTICE] Michael Yoder voted as Tuscany committer
Welcome, Michael! Simon Michael Yoder wrote: Thanks All! -Original Message- From: Amita Vadhavkar [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 24, 2007 4:50 AM To: tuscany-dev@ws.apache.org Subject: Re: [NOTICE] Michael Yoder voted as Tuscany committer Congratulations and Welcome Michael! -Amita On 10/24/07, Pete Robbins [EMAIL PROTECTED] wrote: The Tuscany PPMC and Incubator PMC have voted for Michael to become a Tuscany committer. Congratulations and welcome! I look forward to your continued excellent contributions to Tuscany. Cheers, -- Pete - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [SCA Native] next release content [was: Tuscany roadmap]
Hi Brady, Agreed, I think SDO unit testing infrastructure is enough. However, SDO test cases are not passing successfully, and I'm not sure if it's out of date or not. I think before each commit we should run the project_test to check if everything is alright and add new tests for new implemented features, but I'm not sure it's was being done for SDO. Regards, Adriano Crestani On 10/24/07, Brady Johnson [EMAIL PROTECTED] wrote: Well then, if we cant use CxxTest, and if DAS/SDO Native already have a unit testing infrastructure in place, then I vote we just use/copy that infrastructure for SCA Native. Brady Johnson Lead Software Developer - HydraSCA Rogue Wave Software - [EMAIL PROTECTED] PS: SCA Native used to have a unit test suite, but it was WAY out of date and didn't even compile, so I asked for it to be removed. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adriano Crestani Sent: Wednesday, October 24, 2007 10:46 AM To: tuscany-dev@ws.apache.org; [EMAIL PROTECTED] Subject: Re: [SCA Native] next release content [was: Tuscany roadmap] Thanks ant, As ant confirmed, we cannot use CxxText even on unit test source code, then we should definitely look for another tool or leave it the way it is. SCA unit tests - I never tested SDO unit tests(sdo_test project) - It needs some maintenance and does not use any unit test tool DAS unit tests(das_test project) - working fine and does not use any unit test tool Regards, Adriano Crestani On 10/24/07, ant elder [EMAIL PROTECTED] wrote: CxxTest (http://cxxtest.sourceforge.net/) is LGPL which is an excluded license (http://www.apache.org/legal/3party.html) so it cant be used. Doesn't matter that its only tests so CxxTest wont be distributed in a distro, we can't use anything LGPL. ...ant On 10/24/07, Brady Johnson [EMAIL PROTECTED] wrote: So who do we have to check with? Brady -Original Message- From: Pete Robbins [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 24, 2007 12:54 AM To: tuscany-dev@ws.apache.org Subject: Re: [SCA Native] next release content [was: Tuscany roadmap] My comment was based on what Sam Ruby told us last time we went round this loop. Unfortunately my trawl through mail archives can't find anything. I'm no legal expert. I believe using cxxtest would be OK but we need to check before using it. Cheers, On 23/10/2007, Adriano Crestani [EMAIL PROTECTED] wrote: Oh, sorry Simon, my mistake, it was really Pete who said it ; ) Adriano Crestani On 10/23/07, Simon Nash [EMAIL PROTECTED] wrote: Adriano Crestani wrote: Hi Haleh, This way we would be using the Cxxtest api, and according to Simon it's considered derived work, so we couldn't distribute it, right Simon? This comment came from Pete, not from me. I'm not familiar with the stdcxx license so I'll defer to Pete to explain why it's a concern. Simon Adriano Crestani On 10/23/07, haleh mahbod [EMAIL PROTECTED] wrote: But if you go with what Simon suggested, you leave the tests and test tool outside of distribution. Wouldn't that work? On 10/23/07, Adriano Crestani [EMAIL PROTECTED] wrote: I think this is one for the legal discuss list. This has been discussed before and I think the conclusion was that because you code to the cxxtest apis to write your test code it could be considered a derivative work. So, does it mean we cannot distribute a code using a api that we cannot distribute? Then we should start looking for another unit test. I was looking on the web site I commented before, most of them are GPL : (, but I found this 2: http://unittest-cpp.sourceforge.net/ http://tut-framework.sourceforge.net/ Their license seems to have almost no restriction, but I cannot tell for sure if they are compatible with ASF license. Regards, Adriano Crestani On 10/23/07, Pete Robbins [EMAIL PROTECTED] wrote: I think this is one for the legal discuss list. This has been discussed before and I think the conclusion was that because you code to the cxxtest apis to write your test code it could be considered a derivative work. Cheers, On 23/10/2007, Simon Nash [EMAIL PROTECTED] wrote: I think it's fine to distribute unit test source and tell people what tool they need to build and run the tests. And I agree that having a list of suitable unit test tools on the Web site is helpful. Simon Adriano Crestani wrote: Hi Simon,
RE: [SCA Native] next release content [was: Tuscany roadmap]
Adriano, We should definitely get the SDO test suite passing at 100% on all platforms. I'll try to look at it today/tomorrow. I think your suggestion of test then submit should definitely be standard procedure. Otherwise its impossible to track errors, etc. It should be pretty simple to get the SDO test suite passing. As for SCA, since we have zero tests right now, we really need to get something in place. It's a rather daunting task though. :( Brady Johnson Lead Software Developer - HydraSCA Rogue Wave Software - [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adriano Crestani Sent: Wednesday, October 24, 2007 12:42 PM To: tuscany-dev@ws.apache.org Subject: Re: [SCA Native] next release content [was: Tuscany roadmap] Hi Brady, Agreed, I think SDO unit testing infrastructure is enough. However, SDO test cases are not passing successfully, and I'm not sure if it's out of date or not. I think before each commit we should run the project_test to check if everything is alright and add new tests for new implemented features, but I'm not sure it's was being done for SDO. Regards, Adriano Crestani On 10/24/07, Brady Johnson [EMAIL PROTECTED] wrote: Well then, if we cant use CxxTest, and if DAS/SDO Native already have a unit testing infrastructure in place, then I vote we just use/copy that infrastructure for SCA Native. Brady Johnson Lead Software Developer - HydraSCA Rogue Wave Software - [EMAIL PROTECTED] PS: SCA Native used to have a unit test suite, but it was WAY out of date and didn't even compile, so I asked for it to be removed. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adriano Crestani Sent: Wednesday, October 24, 2007 10:46 AM To: tuscany-dev@ws.apache.org; [EMAIL PROTECTED] Subject: Re: [SCA Native] next release content [was: Tuscany roadmap] Thanks ant, As ant confirmed, we cannot use CxxText even on unit test source code, then we should definitely look for another tool or leave it the way it is. SCA unit tests - I never tested SDO unit tests(sdo_test project) - It needs some maintenance and does not use any unit test tool DAS unit tests(das_test project) - working fine and does not use any unit test tool Regards, Adriano Crestani On 10/24/07, ant elder [EMAIL PROTECTED] wrote: CxxTest (http://cxxtest.sourceforge.net/) is LGPL which is an excluded license (http://www.apache.org/legal/3party.html) so it cant be used. Doesn't matter that its only tests so CxxTest wont be distributed in a distro, we can't use anything LGPL. ...ant On 10/24/07, Brady Johnson [EMAIL PROTECTED] wrote: So who do we have to check with? Brady -Original Message- From: Pete Robbins [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 24, 2007 12:54 AM To: tuscany-dev@ws.apache.org Subject: Re: [SCA Native] next release content [was: Tuscany roadmap] My comment was based on what Sam Ruby told us last time we went round this loop. Unfortunately my trawl through mail archives can't find anything. I'm no legal expert. I believe using cxxtest would be OK but we need to check before using it. Cheers, On 23/10/2007, Adriano Crestani [EMAIL PROTECTED] wrote: Oh, sorry Simon, my mistake, it was really Pete who said it ; ) Adriano Crestani On 10/23/07, Simon Nash [EMAIL PROTECTED] wrote: Adriano Crestani wrote: Hi Haleh, This way we would be using the Cxxtest api, and according to Simon it's considered derived work, so we couldn't distribute it, right Simon? This comment came from Pete, not from me. I'm not familiar with the stdcxx license so I'll defer to Pete to explain why it's a concern. Simon Adriano Crestani On 10/23/07, haleh mahbod [EMAIL PROTECTED] wrote: But if you go with what Simon suggested, you leave the tests and test tool outside of distribution. Wouldn't that work? On 10/23/07, Adriano Crestani [EMAIL PROTECTED] wrote: I think this is one for the legal discuss list. This has been discussed before and I think the conclusion was that because you code to the cxxtest apis to write your test code it could be considered a derivative work. So, does it mean we cannot distribute a code using a api that we cannot distribute? Then we should start looking for another unit test. I was looking on the web site I commented before, most of them are GPL : (, but I found this 2: http://unittest-cpp.sourceforge.net/ http://tut-framework.sourceforge.net/ Their license seems to have almost no restriction, but I
[jira] Created: (TUSCANY-1868) Schema imports not working in multiple class-loader environment
Schema imports not working in multiple class-loader environment --- Key: TUSCANY-1868 URL: https://issues.apache.org/jira/browse/TUSCANY-1868 Project: Tuscany Issue Type: Bug Affects Versions: Java-SDO-1.0 Environment: n/a Reporter: David T. Adcox Fix For: Java-SDO-Next There is a problem with loading schemas that import an additional namespace when in a multiple class-loader environment. The problem exists due to a design flaw in how the EcoreBuilder and package registries interact under a specific circumstance. That circumstance exists when the default helper context is used to load a schema model using the XSDHelper.define() method in two different, peer class-loaders. These peer class-loaders must share the same parentage. --- | CL parent | --- /\ / \ /\ / \ --- --- | CL1 || CL2 | --- --- In this scenario, the same EcoreBuilder is used on both passes of XSDHelper.define(), because the EcoreBuilder is associated with the CL Parent. A unique registry is created for CL1 and another for CL2. During the processing for CL1, the target namespace and all imported namespaces are properly parsed and the models stored in the associated registry, but during the processing for CL2, because the same EcoreBuilder is used, only the target namespace is processed. So, any imported models are missing from the CL2 registry. I've attached an example that will demonstrate this issue. -- 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-1868) Schema imports not working in multiple class-loader environment
[ https://issues.apache.org/jira/browse/TUSCANY-1868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David T. Adcox updated TUSCANY-1868: Attachment: Test1868.java Schema imports not working in multiple class-loader environment --- Key: TUSCANY-1868 URL: https://issues.apache.org/jira/browse/TUSCANY-1868 Project: Tuscany Issue Type: Bug Affects Versions: Java-SDO-1.0 Environment: n/a Reporter: David T. Adcox Fix For: Java-SDO-Next Attachments: Test1868.java There is a problem with loading schemas that import an additional namespace when in a multiple class-loader environment. The problem exists due to a design flaw in how the EcoreBuilder and package registries interact under a specific circumstance. That circumstance exists when the default helper context is used to load a schema model using the XSDHelper.define() method in two different, peer class-loaders. These peer class-loaders must share the same parentage. --- | CL parent | --- /\ / \ /\ / \ --- --- | CL1 || CL2 | --- --- In this scenario, the same EcoreBuilder is used on both passes of XSDHelper.define(), because the EcoreBuilder is associated with the CL Parent. A unique registry is created for CL1 and another for CL2. During the processing for CL1, the target namespace and all imported namespaces are properly parsed and the models stored in the associated registry, but during the processing for CL2, because the same EcoreBuilder is used, only the target namespace is processed. So, any imported models are missing from the CL2 registry. I've attached an example that will demonstrate this issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [SCA Native] next release content [was: Tuscany roadmap]
Hi Brady, Thanks for volunteering to fix sdo test cases, I'm not the right person to try to fix SDO test cases, but I can help with that. But, unfortunatelly, I think I will not be able to help with SCA, I'm not aware enough about SCA infrastructure to help with that. Who else could help you with SCA test cases? Regards, Adriano Crestani On 10/24/07, Brady Johnson [EMAIL PROTECTED] wrote: Adriano, We should definitely get the SDO test suite passing at 100% on all platforms. I'll try to look at it today/tomorrow. I think your suggestion of test then submit should definitely be standard procedure. Otherwise its impossible to track errors, etc. It should be pretty simple to get the SDO test suite passing. As for SCA, since we have zero tests right now, we really need to get something in place. It's a rather daunting task though. :( Brady Johnson Lead Software Developer - HydraSCA Rogue Wave Software - [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adriano Crestani Sent: Wednesday, October 24, 2007 12:42 PM To: tuscany-dev@ws.apache.org Subject: Re: [SCA Native] next release content [was: Tuscany roadmap] Hi Brady, Agreed, I think SDO unit testing infrastructure is enough. However, SDO test cases are not passing successfully, and I'm not sure if it's out of date or not. I think before each commit we should run the project_test to check if everything is alright and add new tests for new implemented features, but I'm not sure it's was being done for SDO. Regards, Adriano Crestani On 10/24/07, Brady Johnson [EMAIL PROTECTED] wrote: Well then, if we cant use CxxTest, and if DAS/SDO Native already have a unit testing infrastructure in place, then I vote we just use/copy that infrastructure for SCA Native. Brady Johnson Lead Software Developer - HydraSCA Rogue Wave Software - [EMAIL PROTECTED] PS: SCA Native used to have a unit test suite, but it was WAY out of date and didn't even compile, so I asked for it to be removed. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adriano Crestani Sent: Wednesday, October 24, 2007 10:46 AM To: tuscany-dev@ws.apache.org; [EMAIL PROTECTED] Subject: Re: [SCA Native] next release content [was: Tuscany roadmap] Thanks ant, As ant confirmed, we cannot use CxxText even on unit test source code, then we should definitely look for another tool or leave it the way it is. SCA unit tests - I never tested SDO unit tests(sdo_test project) - It needs some maintenance and does not use any unit test tool DAS unit tests(das_test project) - working fine and does not use any unit test tool Regards, Adriano Crestani On 10/24/07, ant elder [EMAIL PROTECTED] wrote: CxxTest (http://cxxtest.sourceforge.net/) is LGPL which is an excluded license (http://www.apache.org/legal/3party.html) so it cant be used. Doesn't matter that its only tests so CxxTest wont be distributed in a distro, we can't use anything LGPL. ...ant On 10/24/07, Brady Johnson [EMAIL PROTECTED] wrote: So who do we have to check with? Brady -Original Message- From: Pete Robbins [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 24, 2007 12:54 AM To: tuscany-dev@ws.apache.org Subject: Re: [SCA Native] next release content [was: Tuscany roadmap] My comment was based on what Sam Ruby told us last time we went round this loop. Unfortunately my trawl through mail archives can't find anything. I'm no legal expert. I believe using cxxtest would be OK but we need to check before using it. Cheers, On 23/10/2007, Adriano Crestani [EMAIL PROTECTED] wrote: Oh, sorry Simon, my mistake, it was really Pete who said it ; ) Adriano Crestani On 10/23/07, Simon Nash [EMAIL PROTECTED] wrote: Adriano Crestani wrote: Hi Haleh, This way we would be using the Cxxtest api, and according to Simon it's considered derived work, so we couldn't distribute it, right Simon? This comment came from Pete, not from me. I'm not familiar with the stdcxx license so I'll defer to Pete to explain why it's a concern. Simon Adriano Crestani On 10/23/07, haleh mahbod [EMAIL PROTECTED] wrote: But if you go with what Simon suggested, you leave the tests and test tool outside of distribution. Wouldn't that work? On 10/23/07, Adriano Crestani [EMAIL PROTECTED] wrote: I think this is one for the legal discuss list. This has been discussed before and I think the conclusion was that because you code to the cxxtest apis to
Re: [NOTICE] Michael Yoder voted as Tuscany committer
Welcome, Michael !!! On 10/24/07, Simon Nash [EMAIL PROTECTED] wrote: Welcome, Michael! Simon Michael Yoder wrote: Thanks All! -Original Message- From: Amita Vadhavkar [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 24, 2007 4:50 AM To: tuscany-dev@ws.apache.org Subject: Re: [NOTICE] Michael Yoder voted as Tuscany committer Congratulations and Welcome Michael! -Amita On 10/24/07, Pete Robbins [EMAIL PROTECTED] wrote: The Tuscany PPMC and Incubator PMC have voted for Michael to become a Tuscany committer. Congratulations and welcome! I look forward to your continued excellent contributions to Tuscany. Cheers, -- Pete - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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: [DISCUSS] Evolving Implementation-data
With the data being manipulated like a XmlStreamReader, I suppose that a good way to implement the update operator is use a stream that contains the modifications. Something like that: int update(XmlStreamReader modifications); Therefore, the 'modifications' stream will cotain all the modifications made in the stream retrieved from the get operator. However, in the scenary where we have a simple java developer, how is he supposed to manipulate the stream reader ? What about a XmlStreamReader that allow some sets methods? On 10/12/07, Douglas Leite [EMAIL PROTECTED] wrote: As suggested, I've made some improvements in the sample store. Now the catalog data is accessed by JDBC instead of a hardcoded table in memory. (https://issues.apache.org/jira/browse/TUSCANY-1844 ) After running the sample with the property currencyCode configured as 'EUR', in the store.composite, I got an float parse error in the getTotal method in the ShoppingCartImpl. Because of that, I've changed a little the way of get the price of each product. Suggestion? On 10/12/07, Raymond Feng [EMAIL PROTECTED] wrote: Hi, To better support the XML streaming from the database and other source such as SDO or DOM, I added a prototype to create XMLStreamReader from a tree structure. You can find the code in tuscany-databinding module (org.apache.tuscany.sca.databinding.xml.XmlTreeStreamReaderImpl.java). I'm trying to implement the XMLStreamReader from the DOM tree based on this new class and will keep you updated. Luciano, can you take a brief look to see if you can use it to stream the records? Thanks, Raymond - Original Message - From: Luciano Resende [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Thursday, October 11, 2007 6:45 PM Subject: Re: [DISCUSS] Evolving Implementation-data I have finished a strawman for implementation.data going in the directions discussed here (revision #584019) : - One component per database - One service per table - Tables are introspected from database metadata - Fixed service interface, right now supporting get and get(id) only - Implemented using JDBC - The results are now streamed directly from the database using a JDBCResultSetStreamReader I've took the following conventions to produce the Table XML Elements : Root : [table_name]_table element Records : [table_name] element Columns : column name Column values: column value as element text Next todos... - Expand the interface to support all CRUD Operations - Enhance JDBCResultSetStreamReader as needed - Filter system tables from available services (or not ???) - Integrate and test with databinding - Integrate with samples (store, xmlquery) Please, take a look and provide your comments... Thinking a little bit in the future, and how they data services would be exposed as web-services, what do you guys think about integrating it with wsdl-less webservices feature we have, to allow wsdl generation by introspecting the database schema ? Thoughts ? On 10/8/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Luciano Resende wrote: Hey Douglas Thanks for volunteering, maybe you could start by prototyping the JDBC version of implementation-data that would return a XMLStreamReader. Once we flush out the design details, then we could think about the other CUD operations. Sebastien, and others... Thoughts ? It might be even better to start from a sample, without even using implementation-data at the beginning. I'd suggest the Online Store sample under samples/store, try to change CatalogImpl.java component to get the Catalog from a database using JDBC (instead of a hardcoded table in memory), and return either an XMLStreamReader or the current Item objects. Then try the same thing with the ShoppingCartImpl component, this will help us understand what to do for updates, deletes etc. Then once we've been through that sample we'll probably have a clearer idea of what implementation-data needs to do... basically automate what we wrote by hand in the sample. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresendehttp://people.apache.org/%7Elresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-1853) XSD2JavaGenerator generates Java identifier with dots
[
https://issues.apache.org/jira/browse/TUSCANY-1853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cezary Tkaczyk closed TUSCANY-1853.
---
Resolution: Fixed
Fix Version/s: Java-SDO-Next
The snapshot version works fine. Sorry, I haven't checked it out, before
creating a bug. I had trouble building a snapshot - sdo-tools tests failure.
Omission of these tests leads to successful build.
XSD2JavaGenerator generates Java identifier with dots
-
Key: TUSCANY-1853
URL: https://issues.apache.org/jira/browse/TUSCANY-1853
Project: Tuscany
Issue Type: Bug
Components: Java SDO Tools
Affects Versions: Java-SDO-1.0
Environment: Windows XP, jre 1.5
Reporter: Cezary Tkaczyk
Fix For: Java-SDO-Next
Hello,
While I'm trying to compile generated by XSD2JavaGenerator Java classes, I've
got such an error:
[javac]
C:\projekty\eclipse-workspace-rbpl-sdo-1.0\REB-Catalog-SDO-Java\src-autogen\pl\esb\impl\EsbFactoryImpl.java:169:
';' expected
[javac] pl.esb.blm.adapter.AdapterFactory
pl.esb.blm.adapter.AdapterFactoryInstance =
pl.esb.blm.adapter.AdapterFactory.INSTANCE;
[javac]^
The problem is: variable identifier cannot contain dots.
The place, where this error appears looks like this:
public static EsbFactoryImpl init()
{
if (instance != null ) return instance;
instance = new EsbFactoryImpl();
// Initialize dependent packages
AdapterFactory AdapterFactoryInstance = AdapterFactory.INSTANCE;
RebFactory RebFactoryInstance = RebFactory.INSTANCE;
pl.raiffeisen.esb.blm.adapter.AdapterFactory
pl.raiffeisen.esb.blm.adapter.AdapterFactoryInstance =
pl.raiffeisen.esb.blm.adapter.AdapterFactory.INSTANCE;
// Create package meta-data objects
instance.createMetaData();
// Initialize created meta-data
instance.initializeMetaData();
// Mark meta-data to indicate it can't be changed
//theEsbFactoryImpl.freeze(); //FB do we need to freeze / should we
freeze
return instance;
}
I think the problem is that I have two namespaces of the same suffix:
http://www.esb.pl/blm/adapter
http://www.esb.pl/ods1/adapter
So, generator is trying to avoid the problem creating unique variable name:
pl.esb.blm.adapter.AdapterFactoryInstance
Unfortunately, this is not valid identifier.
Kind Regards,
Czarek
--
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] Issue Comment Edited: (TUSCANY-1853) XSD2JavaGenerator generates Java identifier with dots
[
https://issues.apache.org/jira/browse/TUSCANY-1853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12537416
]
ctkaczyk edited comment on TUSCANY-1853 at 10/24/07 1:58 PM:
---
The snapshot version (from
https://svn.apache.org/repos/asf/incubator/tuscany/java/sdo) works fine. Sorry,
I haven't checked it out, before opening an issue. I had trouble building a
snapshot - sdo-tools tests failure. Fortunately, omission of these tests leads
to successful build.
was (Author: ctkaczyk):
The snapshot version works fine. Sorry, I haven't checked it out, before
creating a bug. I had trouble building a snapshot - sdo-tools tests failure.
Omission of these tests leads to successful build.
XSD2JavaGenerator generates Java identifier with dots
-
Key: TUSCANY-1853
URL: https://issues.apache.org/jira/browse/TUSCANY-1853
Project: Tuscany
Issue Type: Bug
Components: Java SDO Tools
Affects Versions: Java-SDO-1.0
Environment: Windows XP, jre 1.5
Reporter: Cezary Tkaczyk
Fix For: Java-SDO-Next
Hello,
While I'm trying to compile generated by XSD2JavaGenerator Java classes, I've
got such an error:
[javac]
C:\projekty\eclipse-workspace-rbpl-sdo-1.0\REB-Catalog-SDO-Java\src-autogen\pl\esb\impl\EsbFactoryImpl.java:169:
';' expected
[javac] pl.esb.blm.adapter.AdapterFactory
pl.esb.blm.adapter.AdapterFactoryInstance =
pl.esb.blm.adapter.AdapterFactory.INSTANCE;
[javac]^
The problem is: variable identifier cannot contain dots.
The place, where this error appears looks like this:
public static EsbFactoryImpl init()
{
if (instance != null ) return instance;
instance = new EsbFactoryImpl();
// Initialize dependent packages
AdapterFactory AdapterFactoryInstance = AdapterFactory.INSTANCE;
RebFactory RebFactoryInstance = RebFactory.INSTANCE;
pl.raiffeisen.esb.blm.adapter.AdapterFactory
pl.raiffeisen.esb.blm.adapter.AdapterFactoryInstance =
pl.raiffeisen.esb.blm.adapter.AdapterFactory.INSTANCE;
// Create package meta-data objects
instance.createMetaData();
// Initialize created meta-data
instance.initializeMetaData();
// Mark meta-data to indicate it can't be changed
//theEsbFactoryImpl.freeze(); //FB do we need to freeze / should we
freeze
return instance;
}
I think the problem is that I have two namespaces of the same suffix:
http://www.esb.pl/blm/adapter
http://www.esb.pl/ods1/adapter
So, generator is trying to avoid the problem creating unique variable name:
pl.esb.blm.adapter.AdapterFactoryInstance
Unfortunately, this is not valid identifier.
Kind Regards,
Czarek
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [SCA Native] next release content [was: Tuscany roadmap]
Adriano, I fixed the SDO tests. Actually there was nothing wrong with the tests themselves, but instead it was a path issue in the ant build.xml file. The SDO test suite can be run either from the SDO root dir (ant test), or from the runtime/core/test dir (ant) Brady Johnson Lead Software Developer - HydraSCA Rogue Wave Software - [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adriano Crestani Sent: Wednesday, October 24, 2007 1:56 PM To: tuscany-dev@ws.apache.org Subject: Re: [SCA Native] next release content [was: Tuscany roadmap] Hi Brady, Thanks for volunteering to fix sdo test cases, I'm not the right person to try to fix SDO test cases, but I can help with that. But, unfortunatelly, I think I will not be able to help with SCA, I'm not aware enough about SCA infrastructure to help with that. Who else could help you with SCA test cases? Regards, Adriano Crestani On 10/24/07, Brady Johnson [EMAIL PROTECTED] wrote: Adriano, We should definitely get the SDO test suite passing at 100% on all platforms. I'll try to look at it today/tomorrow. I think your suggestion of test then submit should definitely be standard procedure. Otherwise its impossible to track errors, etc. It should be pretty simple to get the SDO test suite passing. As for SCA, since we have zero tests right now, we really need to get something in place. It's a rather daunting task though. :( Brady Johnson Lead Software Developer - HydraSCA Rogue Wave Software - [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adriano Crestani Sent: Wednesday, October 24, 2007 12:42 PM To: tuscany-dev@ws.apache.org Subject: Re: [SCA Native] next release content [was: Tuscany roadmap] Hi Brady, Agreed, I think SDO unit testing infrastructure is enough. However, SDO test cases are not passing successfully, and I'm not sure if it's out of date or not. I think before each commit we should run the project_test to check if everything is alright and add new tests for new implemented features, but I'm not sure it's was being done for SDO. Regards, Adriano Crestani On 10/24/07, Brady Johnson [EMAIL PROTECTED] wrote: Well then, if we cant use CxxTest, and if DAS/SDO Native already have a unit testing infrastructure in place, then I vote we just use/copy that infrastructure for SCA Native. Brady Johnson Lead Software Developer - HydraSCA Rogue Wave Software - [EMAIL PROTECTED] PS: SCA Native used to have a unit test suite, but it was WAY out of date and didn't even compile, so I asked for it to be removed. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adriano Crestani Sent: Wednesday, October 24, 2007 10:46 AM To: tuscany-dev@ws.apache.org; [EMAIL PROTECTED] Subject: Re: [SCA Native] next release content [was: Tuscany roadmap] Thanks ant, As ant confirmed, we cannot use CxxText even on unit test source code, then we should definitely look for another tool or leave it the way it is. SCA unit tests - I never tested SDO unit tests(sdo_test project) - It needs some maintenance and does not use any unit test tool DAS unit tests(das_test project) - working fine and does not use any unit test tool Regards, Adriano Crestani On 10/24/07, ant elder [EMAIL PROTECTED] wrote: CxxTest (http://cxxtest.sourceforge.net/) is LGPL which is an excluded license (http://www.apache.org/legal/3party.html) so it cant be used. Doesn't matter that its only tests so CxxTest wont be distributed in a distro, we can't use anything LGPL. ...ant On 10/24/07, Brady Johnson [EMAIL PROTECTED] wrote: So who do we have to check with? Brady -Original Message- From: Pete Robbins [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 24, 2007 12:54 AM To: tuscany-dev@ws.apache.org Subject: Re: [SCA Native] next release content [was: Tuscany roadmap] My comment was based on what Sam Ruby told us last time we went round this loop. Unfortunately my trawl through mail archives can't find anything. I'm no legal expert. I believe using cxxtest would be OK but we need to check before using it. Cheers, On 23/10/2007, Adriano Crestani [EMAIL PROTECTED] wrote: Oh, sorry Simon, my mistake, it was really Pete who said it ; ) Adriano Crestani On 10/23/07, Simon Nash [EMAIL PROTECTED] wrote: Adriano Crestani wrote: Hi Haleh, This way we would be using the Cxxtest api, and according to Simon it's considered derived work, so we couldn't distribute it, right Simon? This comment
Classloading in Tuscany
Some comments and use cases. Rajini Sivaram wrote: The bundles that I have at the moment are: 1. org.apache.tuscany.sca.api.jar 14,942 bytes 2. org.apache.tuscany.sca.tuscany.corespi.jar 370,228 bytes 3. org.apache.tuscany.sca.tuscany.runtime.jar 571,159 bytes 4. org.apache.tuscany.sca.tuscany.extensions.jar 996,238 bytes 5. org.apache.tuscany.sca.tuscany.dependencies.jar 43,928,926 bytes The dependencies bundle seems pretty big :) From a packaging point of view, it doesn't make sense to split Tuscany, Why doesn't it make sense? (more below about scenarios and requirements) and it makes a lot more sense to split the 3rd party code. Did you mean split the 3rd party code from the rest of Tuscany as one monster 40Mb bundle? or split that monster bundle in a set of smaller bundles? I dont want to sound like I am doing a sales pitch for OSGi, but I am not sure there is a cleaner or easier way to sort out versioning issues that Tuscany would face if different versions of 3rd party libraries were used, compared to running Tuscany under OSGi. An OSGi runtime would enable different versions of 3rd party libraries, different versions of Tuscany runtime and different versions of Tuscany extensions to coexist in a single VM with very little extra effort. Implementing something similar with a classloader architecture outside of OSGi would be significantly more complex (and will eventually reinvent OSGi). OK, I like OSGi too :) My previous question about requirements was an attempt to step back from the technology details and generate some discussion around the bundle use cases. Let me try to help and list the use cases I can think of, and how they relate to the bundles you've listed. - I develop a business application, and I'm using the SCA APIs, I don't want any dependency on a particular runtime or whatever version of it. -- happy with oat.sca.api! - I developing an extension, using the Tuscany SPI, and running with the Tuscany runtime -- happy with oat.corespi -- would be happy too if oat.core.spi and oat.runtime were a single bundle as long as the runtime packages are not exported. I guess any single project that wants to run something is going to have a dependency on oat.runtime anyway to be able to start the runtime, right? - I'm developing an extension which depends on a 3rd party dependency from oat.dependencies -- not happy with a 40Mb bundle -- what'll happen if I have two copies of Axis2's Axiom in 2 bundles? can I still pass an axiom element between 2 extensions using these 2 copies? I guess not... - I just developed version v4.0.3 of implementation-java, which requires xml-api v47.12, unfortunately incompatible with the xml-api version in Tuscany v4.0.2. -- can we walk through the steps to upgrade my bundle-ized Tuscany v4.0.2 working with my implementation-java v4.0.3? - I'm an application developer and I'm developing and deploying a Web application that uses a Java component and a JSONRPC binding -- not happy with having to package the 900K bundle in my webapp -- and I'm not even thinking about deploying the 40Mb bundle in it... :) Thoughts? It would be good if others could jump-in with the use cases they have in mind for an bundle-ized Tuscany. The bundle structure that has been discussed so far seems to go in the right direction, I'm sure that more use cases will help come up with a useful structure. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [NOTICE] Michael Yoder voted as Tuscany committer
Pete Robbins wrote: The Tuscany PPMC and Incubator PMC have voted for Michael to become a Tuscany committer. Congratulations and welcome! I look forward to your continued excellent contributions to Tuscany. Cheers, Congratulations Michael! -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
testing moderation - ignore this
testing for -allow in CC -- Joe Schaefer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Implementation.script module is broken due to a change in grovy-all-1.0 POM
Hi, Starting from today, the implementation.script module is broken due to a change of grovy-all-1.0 POM in the maven repo. Please see the similar report at: http://permalink.gmane.org/gmane.comp.lang.groovy.user/25859 It's unfortunate that they could change the POM after the 1.0 release was published for a long time. I tried to use newer version of groovy but bsf is not happy. Thanks, Raymond - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-1865) relationships in DAS need to consider table-property and column-type mapping
[ https://issues.apache.org/jira/browse/TUSCANY-1865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amita Vadhavkar resolved TUSCANY-1865. -- Resolution: Fixed changes committed at revision 588146. relationships in DAS need to consider table-property and column-type mapping Key: TUSCANY-1865 URL: https://issues.apache.org/jira/browse/TUSCANY-1865 Project: Tuscany Issue Type: Bug Components: Java DAS RDB Affects Versions: Java-DAS-Next Reporter: Amita Vadhavkar Assignee: Amita Vadhavkar Fix For: Java-DAS-Next Attachments: 1865.patch http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg25092.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
